PHP *

Как-то очень давно наш отдел автоматизации внутренних процессов посетил админ (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.

Эта статья — переработанная версия доклада Отказоустойчивая работа с Redis с прошедшего 17 октября 2020 митапа PHP-разработчиков Йошкар-Олы.

Мы поговорим о подводных камнях использования Redis в системе, где важна отказоустойчивость — на примере хранения сессий в условном веб-сервисе, написанном на PHP, но многие замечания будут справедливы и для других платформ — например для микросервисов на Go. Статья будет полезна, если вы проектируете микросервисы или монолитные приложения с достаточно большой нагрузкой и интенсивно работаете с Redis либо столкнулись с потребностью в перепроектировании механизмов аутентификации и сессий.

ISPConfig - бесплатная панель управления хостингом с открытым исходным кодом c возможностью управлять несколькими серверами из одной панели управления. Это один из лучших вариантов для веб-студий, хостинг-компаний, а так же для всех, кто ищет бесплатную панель управления хостингом с широким функционалом. В данной статье мы рассмотрим как выполнить установку Ispconfig3 с nginx, php-fpm и mysql на ubuntu 20.04.

Когда-то вы кодили на одном большом и могучем серваке, с кучей памяти и кучей процов. Сервер был безграничен, все ваши сервисы были здесь, все ваши Redis’ы и даже зачастую MySQL-и были тут. Все ваши приложения были здесь же: какая-то аналитика, какой-то бэкенд для админки, еще десяток сервисов — все было рядом. 

Но вот вы заехали в Swarm. Все приложения — это набор контейнеров. А контейнеры это, по сути, набор микросерверов со своей файловой системой, своей памятью, своими процами. И они уже не всегда рядом. Соответственно, это тянет за собой некоторые изменения. 

Дмитрий Стогов из Zend by Perforce уже много лет занимается самым сердцем PHP и знает про него много полезного. В том числе о вопросах, связанных с производительностью.

В своем докладе на конференции PHP Russia 2021 Дмитрий расскажет, как продвигается работа над JIT и какие другие идеи, направленные на повышение производительности, были реализованы в PHP 8.0 и готовятся в PHP 8.1. А уже сегодня можно почитать интервью, в котором я задал эксперту PHP вопросы обо всем понемногу: от его истории до обсуждения современных реалий.

Однажды Энтони Феррара (Anthony Ferrara) решил скомпилировать PHP в низкоуровневый код, но результат получился слабым. Главной проблемой, с которой он столкнулся, было отсутствие подходящего бэкенда. К лучшему все изменилось после того, как в дело вступил FFI.

Я советую прочитать статью «A PHP Compiler, aka The FFI Rabbit Hole», перевод который вы найдёте под катом.

"Бенч" дело такое... После нескольких дней бездействия начинается ломка, хочется занять себя чем-нибудь. Иногда я отвлекался на pet-проекты, иногда на чтение литератыры... Сейчас же я расскажу о том что случилось во время последнего "режима ожидания".

Меня многие годы волновала производительность ЯП (в основном интересовал PHP). Список ниже, содержал некоторые мои убеждения, до недавнего времени:

- PHP один из самых медленных языков программирования

- Python быстрее PHP

- Ruby быстрее PHP

- C/C++ намного быстрее Python и PHP вместе взятых

- Assembler на порядок быстрее C/C++

Объективно можно сказать, что в настоящий момент PHP не самый сексуальный и клевый язык программирования. Онлайн-школы не стремятся рекламировать курсы по PHP, мы не видим истории успеха, начинающие с фразы «Я взял в руки учебник по PHP», да и вообще идет мнение, что лучше совсем никак, чем быть PHP-программистом (а если слышим про битрикс, то сразу можно на костер). Тем не менее, я не согласен с этим, и расскажу, почему инвестиция времени в ПХП себя окупает.

Я бекенд-разработчик, в своё время работал на Python и Java, а сейчас работаю на PHP.

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

Ждать долго не пришлось, при обновлении на сервере PHP c 7.2 до 7.4 - мы получили страницу с описанием ошибки, вместо документации. Ошибка найдена в библиотеке, которую мы использовали для рендеринга UI документации. ПР на гитхабе был создан быстро, но провисел в статусе open почти неделю. После этого, тикет насчет документации пошел в работу.

Все главные новости из мира Joomla за осень 2020 и весну 2021, в одной статье.

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

Однажды в процессе производственной деятельности появилась необходимость генерации штрихкода по стандарту code128. Появилась в виду того, что имевшаяся в эксплуатации функция (хранимая процедура в базе Oracle) генерировала клёвый, полосатый штрихкод, который однако, читался не во всех случаях. Разработчики в своё время оттестировали её весьма некачественно, но перерабатывать уже не собирались т.к. проект был давно сдан, а потребности в считывании так и не появились.

Первая мысль — поиск готовых библиотек. Навскидку определили критерии — с pl/sql не связываемся, пусть это будет внешний сервис: возможно кусок на javascript для генерации прямо на страничке, либо обращение за картинкой к ближайшему серверу где имеется php. Беглый поиск в интернете показал что тема истоптана весьма плотно. Есть как наколенные поделки уровня лабораторки по программированию, так и мощные библиотеки для всех вариантов кодирования вплоть до qr-кодов. Варианты с JavaScript пришлось отбросить т.к. они во первых практически все «обфусканы» (даже непонятно, то ли для сокращения объема, то ли стыдно исходники показать), во вторых генерируют строку для отображения определенным шрифтом, наличие которого не всегда можно обеспечить на рабочем месте и требует дополнительных обработок для экранирования спецсимволов. Внимательное рассмотрение библиотек и кусков кода на php тоже произвел тягостное впечатление — на первый взгляд всё вроде бы правильно: и классы написаны на все случаи жизни, комментарии в наличии, украшательства типа выбора цвета и рамочек, примеры подготовлены. Начнёшь вникать — хотят либо php самой распоследней версии (на боевых серверах не всегда это получается добыть), либо внутренняя логика не различима совсем, либо штрихкод на выходе получается длиннее ожидаемого. Вот последнее не дало покоя и подтолкнуло к собственной реализации.