Вероятно, вы видели один из наших предыдущих туториалов о том, как парсить сайты, например: Ruby, JavaScript или Python и думали: а как же насчёт самого часто-используемого языка для серверного web-программирования, который очень редко используют для этой задачи? Настал этот час — сегодня посмотрим, как парсить сайты на PHP!
Имейте ввиду, что не существует одного лучшего способа это сделать — каждый подход имеет свой сценарий использования в зависимости от того, что вам нужно, как вам нравится что-либо делать и чего вы хотите достичь.
Для примера мы попробуем получить список людей, у которых совпадает день рождения. Если вы хотите повторять примеры кода вместе с нами, удостоверьтесь что у вас установлена последняя версия PHP и composer.
Привет. Сегодня посмотрим, как тестировать Vue-компоненты. На самом деле, немного поработав с NodeJs и Vue, а так же посмотрев на то, как ребята работают с React — могу сказать, что тесты там пишутся на одних и тех же фреймворках/библиотеках, так что эта информация будет полезна не только Vue-разработчикам.
Первым делом, как обычно, смотрим мануал — https://ru.vuejs.org/v2/guide/unit-testing.html. Если мы разворачиваем проект через Vue CLI, то инструменты тестирования у нас уже есть. Нам говорят, что тестировать мы можем посредством двух инструментов — jest и mocha ̶ ̶и̶ ̶н̶и̶ч̶е̶г̶о̶ ̶с̶м̶е̶ш̶н̶о̶г̶о̶!̶ В этой статье мы рассмотрим, как тестировать vue-компоненты с помощью jest. Туториал на vue.org весьма ужат, поэтому я предлагаю разобрать вот этот ман, а потом уже приступить к тестированию нашего компонента. Открывай мануал, параллельно эту статью и поехали.
Самая рутинная и бОльшая часть работы среднестатистического backend-разработчика — написание API, которое потом будут дёргать клиенты. Если, конечно, мы говорим о современной разработке, где front и back пишутся отдельно. Клиентской частью может быть как браузерный фронт — React, Vue, Angular, … ; так и Android, iOS, … — приложения. О том, как правильно писать API — написано много, а сказано ещё больше. Поэтому сегодня я не буду говорить о идеальном REST ̶н̶а̶ ̶с̶а̶м̶о̶м̶ ̶д̶е̶л̶е̶ ̶б̶у̶д̶у̶, о GraphQL (потому что с ним ещё не работал 🙂 ) и о других умных вещах. Сегодня мы поговорим о крайне полезной и простой штуке, которая очень упростит тебе в дальнейшем жизнь и сэкономит много как времени, так и нервов — стандартные Symfony — правила, которые описываются напрямую в сущности и затем проверяются валидатором. Лично я этого, когда устраивался на первую работу, — не знал и это стало для меня приятным открытием. А чтобы было веселей и понятней, мы напишем небольшое приложение, которое будет отдавать и валидировать данные для (та-дааа) обычного todo-листа. Да, ничего лучше я не придумал, потому что это самый простой и наглядный пример.
Я надеюсь, что ты читал мои статьи про запросы, основы работы с Symfony и краткое описание MVC (если нет — ссылки можно найти на канале). Поэтому сегодня мы не будем останавливаться на основах и перейдём сразу к делу.
Первым делом определимся, над какой сущностью будем строить наши запросы. Сущность у нас, на данной итерации, одна — Task, т.е. задача. У нас todo-лист, куда мы будем добавлять задачи. Что можно сделать с задачей? Её можно создать. Раз можно создать — можно и получить из базы. Можно отредактировать — поменять статус (в бэклоге, в процессе, завершена, на тестировании), изменить название, описание или время дедлайна. Ещё её можно удалить.
Получается, у нас есть 4 атомарных операции, а значит — будут 4 контроллера. Теперь нужно грамотно подобрать типы HTTP-запросов. Для создания используем POST, так как именно пост служит для передачи новых данных на сервер. Для получения данных по id используется GET-запрос. Для редактирования данных — используем PUT, так как именно этот тип запроса предназначен для обновления уже существующих данных. Для удаления — DELETE. Я обещал не затрагивать философию REST, но, к слову, мы только «спроектировали» каноничную REST-апиху.
Сейчас на новой работе я вникаю в огромный флоу поверх разработки. Тут нельзя просто запушить в мастер, тут нужно пройти огромную череду этапов: начиная от правильного наименования коммита и тестов (как самописных, так и уже существующих), заканчивая получением одобрений от старших коллег (а это сделать, временами, сложно 🙂 ). И только после этого влить свою ветку в мастер и радоваться успешной правке.
И на фоне этого я понял, насколько важно приучаться себя ещё на моменте обучения разрабатывать правильно. Не мне говорить о правильной разработке — этому я только учусь, но зато сказать что тесты в ней точно участвуют — уже могу.
Сегодня мы обложим тестами тот компонент, который закончили писать на предыдущем уроке. В этой части затронем бэк, в следующей — фронт.
Кстати, компонент (и back,и front-части) я залил на битбакет, чтобы ты сразу мог посмотреть код. Ссылки — фронт, бэк, и в конце статьи.
Нам говорят, что чтобы начать писать тесты, нам нужен компонент, который реализует логику для работы с тестами — symfony/phpunit-bridge, являющийся обвязкой над PHPUnit — фреймворком для тестирования PHP. Ставим:
Сегодня зафиналим наш autoselect-компонент. Но для начала расскажу, где я был: дорабатывал положенные 2 недели на старой работе и готовился к выходу на новую. Больше пока сказать не могу, кроме того, что компания большая, требуют там больше и работать надо будет упорно, чтобы пройти испытательный. Зато буду больше писать о всяком. А теперь к нашим баранам. В первой части мы немного затронули Vue, написали первый компонент и закончили на этом. Сегодня так просто отделаться не получится — будет и бэк, и фронт, и интересные либы и много нового материала.
Для начала нужно мОкнуть данные с бэка. Что такое мокнуть? Это значит подделать (получить фэйковые данные для тестов). С этими данными будет работать наш компонент, написанный в 1-ой части.
Чтобы это сделать, нам нужно некоторое количество записей в какой-либо таблице. Я создам таблицу Product, каждая запись в которой будет состоять из 4-х частей: id, название продукта, дата поступления и количество.
Чтобы всё сделать по науке мы познакомимся такой вещью, как фикстуры — классы, которые автоматизируют создание записей и используется для тестов. Я познакомился с этим понятием относительно недавно в одном из манов от symfonycast. Но обо всём по порядку. Сначала установим свежую копию Symfony. Устанавливать буду пакет symfony/skeleton — без дополнительных библиотек. Как это сделать я описывал в одном из первых уроков на канале, там всё максимально подробно и с картинками 🙂 Привожу только листинг:
Привет, друг. Мой первый компонент, написанный на Vue — это автовыпадашка по поисковому запросу. Чтобы ты понимал, о чём я говорю — вспомни выпадающий список, который появляется, когда ты начинаешь вводить запрос в поисковой строке google:
При каждом нажатии клавиш поисковая выдача подстраивается под тебя, предлагая тебе наиболее релевантные варианты, которые ты возможно ищешь. Примерно тоже самое мне нужно было написать, когда я пару месяцев назад приступил к созданию одной большой и сложной формы, абсолютно ничего не зная о Vue.
Помимо практики и разъяснения того, что недавно понял сам — я опишу некий «журнал разработки»: какими шагами я шёл, чтобы понять ту или иную вещь. В частности, покажу как вообще можно подступиться к Vue и начать что-то делать. Оговорюсь сразу — если среди подписчиков есть люди, знающие Vue и работающие с ним — буду рад любой критике и обратной связи в целом. А теперь поехали.
Первое, что следует открыть — документацию. Она переведена на русский, выстроена в режиме от простого к сложному и местами понятна :). Скажу честно — прочитав первые разделы и дойдя до компонентов я всё ещё мало представлял, как подступиться к созданию и как вообще должна выглядеть структура проекта.
Если теория (даже с отработанными примерами) тебе понятна, но четкой картины не выстраивается (как было у меня), то советую весьма неплохой видос — «Уроки VUE.JS учим за 1 час». Да, звучит как откровенный кликбейт с примесью чего-то в стиле «С++ за 20 минут», но это редкое исключение. Автор, хоть и идёт по стандартной документации, проделал большую работу: чего стоит анимация, которая помогает визуально уяснить материал и примеры, расширяющие стандартную доку.
На второй день, немного поигравшись с атрибутами, событиями, я посмотрел ещё несколько манов, и пробросом пользовательских событий в компоненты-родители (ты же прочитал документация и понимаешь о чём я говорю, да?), наступил момент узнать, как правильно строить архитектуру файлов проекта. Тут есть замечательный видос, где автор описывает такой инструмент, как VUE-cli: «Learn Vue.js (RU) — Vue CLI». Он небольшой и советую его посмотреть, прежде чем идти дальше, потому что через пару минут мы будем его использовать. К слову, это 3-ий или 4-ый ман автора в плейлисте по Vue. Первые 3 — введение и основы, которые стоит глянуть как закрепление документации и видео с часовым разъяснением Vue.js.
Давай развернём пустой проект, прежде чем идти дальше. Открываем IDE и далее по протоколу:
Только что, спустя 40 минут поиска ошибки, сделал открытие: даже если у вас есть константный массив float’ов, хардкодом забитый в шейдер вершин, openGL ничего не отрисует, если не установлен VAO.
