PHP *

Суровый DIY, легаси, kafka и дизайн-система для дам с собачками.

Несколько дней назад кто-то задал вопрос в твиттере, о том, какой из PHP-сниппетов  лучше других, и есть ли подход лучше.

Чаще всего в сети публикуются материалы по начальному уровню работы с Wordpress. В лучшем случае обсуждаются документированные возможности самого Wordpress и его различных плагинов. Я стою на позиции, что работа с документацией и использованием документированных возможностей — инструментами, которые вам предоставил разработчик — является приоритетной в разработке. Однако иногда документированных возможностей не хватает и как ответ на этот случай появилась эта статья.

Advance Customs Fields (ACF) – один из популярных плагинов Wordpress. Основная задача — создание блоков дополнительной информации к Постам, Страницам и Товарам. Плагин настолько популярен, что вопросы по нему входят в список MustKnow на различных собеседованиях.

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

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

Всем привет! В этой статье хочу поделиться опытом построения системы доменных событий (domain events) в нашем модульном монолите и микросервисах, рассказать о том, как мы гарантируем их доставку, следим за консистентностью в рамках транзакций, используя transactional outbox, чем доменные события отличаются от интеграционных и всё это в рамках multi tenant приложения. Подробнее под катом.

Наверное, многие сталкивались с ситуацией, когда среди проектов работающих на современном ПО, остается пара полузабытых, а держать отдельную машину под них не хочется. Вариантов решения масса, но в службе поддержки хостинг-компании данная проблема не теряет своей актуальности м моими коллегами был разработан скрипт, помогающий добавить нужную версию php в VestaCP буквально за пару минут. Данный метод уже зарекомендовал себя с хорошей стороны и продолжает радовать сотрудников поддержки. Самое время его опубликовать и помочь всем, кто столкнулся с подобной проблемой.

PHP 8.1 выйдет через несколько месяцев и я в восторге от множества нововведений! Хочу поделиться реальным влиянием PHP 8.1 на мой собственный код.

Познакомиться с PHP фреймворком CodeIgniter 4 достаточно просто.

Нужно потратить вечер, выполняя инструкции из раздела  «Build Your First Application» («Создайте свое первое приложение»). Поскольку документация написана хорошим, технически понятным языком, то в процессе ознакомления с этим и другими разделами возможно получить даже некоторое эстетическое удовольствие.

Обычно когда мы хотим сделать внешний запрос мы используем для этих целей cURL. Настройка cURL довольно громоздкая, да и в принципе проблематично держать в голове все необходимые настройки. Также есть сервера без поддержки cURL, а значит Ваш код не будет работать. В этих случаях нужен запасной вариант.

С использованием Joomla довольно легко настроить cURL и все необходимые резервные варианты подключений в одной строчке кода.

В прошлом году GitHub без лишнего шума выпустил новую возможность, которую быстро заметили в сообществе пользователей, — файлы README в профилях. По сути, README-файл профиля представляет собой глобальный файл README, связанный с вашим профилем GitHub. Чтобы он появился, нужно создать публичный репозиторий, имя которого совпадает с вашим именем пользователя на GitHub. Например, мое имя пользователя — osteel, поэтому я создал osteel/osteel в качестве такого репозитория.

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

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

Если вы сделали опечатку, когда вводили имя ветки, вам поможет вот такая команда.

Версия PHP 8.1 находится в активной разработке и будет выпущена 25 ноября 2021 г. Следует иметь в виду, что эта дата может измениться, если основная команда разработчиков решит, например, добавить дополнительный бета-выпуск. Мы уже знаем о новых возможностях, повышении производительности, изменениях и упразднении сомнительной функциональности. Давайте рассмотрим эти новшества по порядку.

Как-то очень давно наш отдел автоматизации внутренних процессов посетил админ (ops) с идеей помочь нашим тестировщикам. Основная идея был упростить деплой т.к. было очень неудобно писать ручные curl запросы к gitlab'у с кучей меняющихся параметров. Так заставили нас наша команда решила помочь дружественному отделу и сделать их работу более приятной.

В статье я постараюсь поделиться тем, как мы разрабатывали GUI для curl'a, а сделали очень крутой сервис автоматизации. А также с какими проблемами столкнулись и как их решили (или нет).

Как по мне достаточно важная, хотя и холиварная тема. Думаю каждый из нас задавал себе вопросы: "можно не дублировать проверки?", "а не усложняю ли я?", "да как же это сделать нормально?!".

Эта статья аккумулирует в себе те практики, которые мне близки и которых я придерживаюсь в разработке.

Текст рассчитан не на новичков, потому нормально, если по ходу чтения какие-то понятия будут вам неизвестны, я постарался коротко раскрыть их здесь, а также указал ссылки на посты в моём телеграм канале Beer::PHP ​, которые могут чуть подробнее раскрыть то или иное понятие.

Начнем мы сразу с доменного слоя нашего приложения, то есть с бизнес логики нашего приложения.

За последние два десятилетия виртуальная машина Zend Engine, лежащая в основе PHP, претерпела определенные улучшения. Значительный скачок производительности произошел с выходом версии PHP 7, в которой ощутимо выросла производительность WordPress и других традиционных веб-приложений. В версии PHP 8, в свою очередь, появился JIT-компилятор, значительно ускоривший выполнение ресурсоемких алгоритмов.

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

Выпуск PHP 8 включает в себя изменения, которые привносят в среду выполнения PHP современный уровень наблюдения. Наша команда совместно с сообществом разработчиков движка PHP разработала и выпустила новый API наблюдателя. Перед выпуском этого API мы, как и другие PHP-разработчики, столкнулись со множеством проблем.

Чтобы лучше понять, как ловушки наблюдения изменяют и ограничивают процесс разработки, рассмотрим ограничения в области наблюдения в версиях, предшествующих PHP 8.

Всем привет.

У меня было несколько публикаций по теме Entity Attribute Value, сокращенно EAV (паттерн программирования для хранения произвольных данных). За прошедшее время я допилил библиотеку для работы с EAV, и хотел бы поделиться с вами своими наработками.

В библиотеке реализован базовый сценарий:

Иногда возникает задача парсинга произвольного DSL для дальнейшей работы с ним на уровне PHP кода. И я хочу поделиться опытом решения этой приблемы с помощью регулярок с примерами.

На мой взгляд, язык php всегда был довольно хорошим решением для создания сложного бекэнда веб-приложений, а в девяностые и нулевые приобрел такую огромную популярность (именно огромную, сопоставимую с IE для веб-серфига того времени) в первую очередь благодаря легкости, скорости разработки и поддержки кода. Но те времена прошли. Сегодня считается, что приложения на php стали монструозны, долго и сложно запускаемы, способны работать только с подтягиванием множества зависимостей в директорию /vendor...

Зачастую все именно так, но я хочу попробовать вам показать, что может быть иначе. Попробуем сделать простое API и приложить не больше усилий чем при использовании Node.js или Go.

Под катом мой пример того, как можно быстро и без лишней головной боли сделать API на php.