PHP *

Доброго времени суток уважаемые читатели хабра. С каждым годом в веб разработке появляется все больше разнообразных решений которые используют модульный подход и упрощают разработку и редактирование кода. В данной статье я предлагаю вам свой взгляд на то, какими могут быть переиспользуемые front-end блоки (для проектов с бэкендом на php) и предлагаю пройти все шаги от идеи до реализации вместе со мной. Звучит интересно? Тогда добро пожаловать под кат.

Привет, сообщество!

С вами Александр Макаров, samdark и этой второй выпуск в этом году. Я попросил членов команды написать что-то для вступления, но, похоже, они предпочитают писать код :)

Есть новости по важным обновлениям Yii 3 и набор релизов Yii 2. Также упомянем некоторые интересные проекты, не связанные напрямую с кодом.

Не писал на Хабре еще о том, как я пришел к мысли формирования компонентов для своих будущих проектов или текущий вместо прямого написания кода. Если очень коротко сказать про это, то было все примерно так... Много писал разных проектов, придумывал псевдо компоненты и каждый раз натыкался на то, что в одном проекте ужасно удобно это использовать, а в другом ужасно не удобно. Попробовал перенести "удобные" компоненты в проект и стало все еще более не удобно... Короче, руки не из того места, голова слишком амбициозная... Со временем я дошел до другой мысли: "Надо делать репозитории на GitHub с отдельными компонентами, которые не будут иметь зависимость от других компонентов"... Все шло хорошо, но дошел я до того самого компонента, которые хочет работать с другим компонентом... В итоге на помощь пришли интерфейсы с методами. И вот теперь поговорим о компоненте SQL миграций в том ключе, как я его вижу.

Итак, большинство людей, а также моих коллег, уверенны, что миграции служат не только для того, чтобы актуализировать базу данных между разработчиками, а так же для операций с файлами, папки и прочему. Например, создать у всех разработчиков директорию или что-то там еще для чего-то там...

Возможно я могу ошибаться, но лично я уверен для себя, что миграции необходимы исключительно для SQL операций с базами данных. Для актуализации файлов можно использовать тот же самый git или центральный init файл, как это есть в Yii2.

В нашей славной компании есть очень хорошая, стимулирующая система т.н. грейдов: раз в полгода, любой разработчик может повысить свой грейд, что влечет за собой увеличение зарплаты. Другими словами, грейд — это аттестация. Хочешь увеличить зарплату? Раз в полгода можешь аттестоваться на следующую ступень, и расти от джуна до сеньора (за один раз можно перепрыгнуть не более, чем на две ступени). Аттестация проходит в дружелюбной форме, вопросы выложены в базе знаний, никакой бюрократической волокиты нет. Условием для допуска к аттестации служит решение алгоритмической задачи.

И вот я аттестовываюсь, и мне дают задачу: вычислить арифметическое выражение в виде строки. Да фигня вопрос, скажете вы (как и я в начале). Все это давно описано, и ничего сложного здесь нет. Вы будете одновременно правы и неправы. Вопрос то, конечно фигня, но это алгоритмическая задача. Готовые библиотеки использовать нельзя, нужно написать именно алгоритмическое решение. И окунулся я в мир операндов, операторов, как бинарных, так и унарных. И как все это красиво распарсить, как не запутаться со скобками, и… самым коварным оказался унарный минус.

Решение писать будем на php.

Генри Форд чуть не прогорел на своей фразе про пятьдесят оттенков черного. General Motors стала предлагать разноцветные модели Chevrolet, Pontiac, Buick, Oldsmobile и Cadillac — и не прогадала. Глядя на это, даже упрямый Форд изменил свое мышление  — и разработал новый Ford A, вернувший его на автомобильный Олимп. Бывают времена, когда парадигма мышления должна стать новой — ибо человек умирает тогда, когда перестаёт меняться ©Генри Форд. 

Пришло время и для разработчиков. Command Query Responsibility Segregation (CQRS) и Event Sourcing (ES) уже не миф — они реально работают. Конечно, не для всех задач — как и классический черный цвет Форда, PHP никуда не исчез и нужен по-прежнему. Но теперь уже есть задачи, где мы встречаемся с CQRS и ES чаще, чем нам кажется. Антон Шабовта на PHP Russia 2021 расскажет, как смена парадигмы и взгляд с другой стороны помогают разработчикам. А перед конференцией мы расспросили Антона подробнее о его новых взглядах на разработку, PHP и, конечно, о CQRS и ES.

В digital-агентстве Convergent, где я работаю, в потоке множество проектов, и у каждого из них может быть собственная админка. Есть несколько окружений (дев, стейдж, лайв). А ещё есть разные внутрикорпоративные сервисы (как собственной разработки, так и сторонние вроде Redmine или Mattermost), которыми ежедневно пользуются сотрудники. 

Наша команда всегда была распределённой между несколькими офисами, но с учётом событий последнего года все сотрудники перешли на удалёнку. Так мы столкнулись с необходимостью организовать всё многообразие внутренних и клиентских сервисов в единой системе.

Новый тип never будет в PHP 8.1, на обсуждении частичные функции, а также другие предложения и новости из PHP Internals. PHP доступен на Google Cloud Functions, о взломе git.php.net, Laravel Octane, PhpStorm 2021.1 и другие релизы, порция инструментов, видео, подкасты, статьи.

Приятного чтения!

Привет! 15 мая мы проведем митап в смешанном формате: ты сможешь подключиться к ютуб-трансляции и задать вопрос текстом или голосом, а если ты в Казани или рядом - приходи в “Штаб”. Ребята из Skyeng расскажут, как и зачем допиливать Codeception, чтобы больше радоваться. Ребята из VK - как превратить PHP-скрипты в статические бинарники. Ребята из iSpring - как внедряли DevOps без Docker и Kubernetes. Ребята из FindMyKids - как переписали нагруженный сервис. Ну а автор Laravel Idea Адель Файзрахманов поднимет холиварную тему про трейты.  

Мы попросили докладчиков оценить темы друг друга и чуть больше рассказать о своем опыте.

В этом году должен выйти PHPUnit 10 (релиз планировался на 2 апреля 2021 года, но был отложен). Если посмотреть на список изменений, то бросается в глаза большое количество удалений устаревшего кода. Одним из таких изменений является удаление метода MockBuilder::setMethods(), который активно использовался при работе с частичными моками. Этот метод не рекомендуется использовать с версии 8.0, но тем не менее он описан в документации без каких-либо альтернатив и упоминания о его нежелательности. Если почитать исходники PHPUnit, issues и пул-реквесты на GitHub, то станет понятно, почему так и какие есть альтернативы.

В этой статье я освещу этот нюанс для тех, кто не обращал на него внимания раньше: расскажу про частичные моки, проблемы, возникающие при работе с setMethods, пути их решения, а также затрону вопрос миграции тестов на PHPUnit 10.

Не секрет, что чем больше проект, тем с большим количеством проблем он сталкивается даже в самых элементарных аспектах.  В продукте Plesk, над которым я работаю, PHP является одним из основных языков, и количество кода на нем превышает 1 миллион строк. Соответственно, мы активно используем PHPUnit для тестирования. Кроме большого объема кода, поддержка двух платформ (Linux и Windows) доставляет нюансы, как и тот факт, что поддерживается несколько бранчей с приличной разницей возраста (крупные релизы), а активно вносят правки несколько десятков инженеров. В статье я хочу поделиться некоторыми практиками, которые мы используем при работе с PHPUnit.

Прим. переводчика: само правило достаточно старое, да и пример, приведенный в статье - на мой взгляд самый простой. Поэтому статья подойдет скорее для новичков, люди с хорошим опытом написания автотестов, возможно, не найдут для себя ничего нового.

От версии 8 к 8.1

Многие современные языки программирования поддерживают различные способы использования различных символов, таких как обычные английские латинские буквы, числа, символы, эмодзи и различные специальные символы, такие как символ новой строки или символ табуляции.

Большинство символов можно просто набрать с клавиатуры и использовать в коде PHP в их исходном виде. Например, $string = "php.watch" - это полностью допустимая строка в PHP, а $num = 42 - допустимое число. Также можно использовать многобайтные символы (для хранения которых требуется более одного байта), например, этот совершенно допустимый эмодзи: $emoji = "?".

PHP, наряду со многими другими языками программирования, поддерживает определенное количество escape-последовательностей для использования различных символов, которые не могут быть набраны с обычной клавиатуры, не могут быть представлены в текстовой форме (например, невидимые символы или различные управляющие символы) или иным образом не считываются. Эти символы используют escape-последовательности, которые распознает PHP.

Что касается чисел, PHP поддерживает стандартные десятичные числа, но также может использовать и другие нотиции, такие как двоичное, восьмеричное, шестнадцатеричное и даже научное (scientific) представление. Они могут сделать код более читаемым и понятным в зависимости от контекста.

На написание этой статьи меня подтолкнуло обсуждение докладов с Heisenbug 2021 в нашем корпоративном чате. Причиной является тот факт, что достаточно много внимания уделяется «правильному» написанию тестов. В кавычках — потому что на бумаге все действительно логично и аргументированно, однако на практике такие тесты получаются достаточно медленными.

Эта статья ориентирована скорее на новичков в программировании, но возможно кто-то сможет вдохновиться одним из описанных далее подходов.

Привет, сегодня я хочу поговорить об ужасной кодовой базе, с которой вы скорее всего прямо сейчас имеете дело. Есть проект и вы нужны, чтобы добавлять новые фичи и фиксить баги. Но вы открываете IDЕ, делаете пул репозитория с проектом — хочется плакать. Кажется, что с этим кодом невозможно работать.

Давайте отбросим эмоции. И посмотрим, что можно быстро предпринять, чтобы облегчить страдания.

В последнее время было достаточно много обсуждений производительности в PHP. И даже несмотря на то, что у нас есть PHP8, JIT и куча других улучшений, многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный". Что PHP - это язык, подходящий только для модели запрос-ответ. Что PHP слишком медленный и его не нужно использовать для высоконагруженных систем. С одной стороны от части всё это правда. Если мы строим какую-то систему, для которой вопрос производительности критичен, то использовать классический блокирующий PHP явно не стОит. Большая часть функций и библиотек PHP созданы для работы в традиционном блокирующем окружении, что уже подразумевает собой не самую высокую производительность. Однако PHP может работать быстро, более того, он может работать очень быстро. Как? Обычно у нас может быть две причины, из-за чего будет проседать производительность: мы либо совершаем какие-то сложные вычисления, либо у нас есть блокирующй ввод-вывод. Первое к сожалению (или к счастью) мы не можем решить в PHP. Но блокирующий ввод-вывод для PHP совсем не проблема. В PHP-сообществе есть люди, которые пишут асинхронный код уже на протяжении несколько лет. Конечно одновременно с этим бОльшая часть сообщества по-прежнему считает асинхронный PHP - дикостью. Я часто слышал: "Ты наверно совсем отчаянный, если собираешься писать что-то асинхронное на PHP". По правде говоря, у нас у всех есть это предубеждение, что PHP не подходит для подобного рода задач. И в большинстве случаев это предубеждение основано на неверных представлениях о самой "асинхронности". Неверные предубеждения в свою очередь ведут к неправильным ожиданиям, что в свою очередь приводит к разочарованию и обвинениям в том, что PHP "не по-настоящему асинхронный".