PHP *

Я PHP-разработчик с многолетним стажем (от слова "много"). Привык, что мой мир - это веб-приложения, серверный код и бесконечные "фичи" на Laravel или Yii (да... легаси - это мой конёк). В последние пару лет вокруг бушует AI-бум: всюду слышно про нейронки, LLM, про каких-то "агентов", которые сами решают задачи. И, признаться, временами у меня появлялась лёгкая тревога. Не отстану ли я от поезда, если не перейду полностью на Python/NodeJS или не выучу новый фреймворк? Ведь почти все примеры ИИ-интеграций, что я видел, были на Python или JavaScript. PHP в этих разговорах фигурировал редко, если вообще упоминался.

Недавно я наткнулся на упоминание о Neuron - инструменте, который гордо назван "первым enterprise-ready агентным фреймворком на PHP". Мой скептицизм сразу поднял голову: "Агентный фреймворк? На PHP? Серьёзно?" С другой стороны, это заинтриговало. Если всё правда, то вместо того чтобы судорожно перелистывать учебник по Python, возможно, я смогу внедрять ИИ прямо там, где мне комфортно — в PHP-стеке. И вот я решил разобраться, что же такое этот Neuron и насколько он реален.

Привет, Хабр! В мире PHP-разработки роутинг — это основа любого веб-приложения. От простых API до сложных микросервисов, правильный роутер может стать ключом к производительности и масштабируемости. Сегодня я хочу представить вам Cloud Castle HTTP Router — мою библиотеку, которая сочетает скорость, простоту и мощь. Это не просто инструмент, а решение для разработчиков, которые хотят оставить позади громоздкие фреймворки и сосредоточиться на коде. Давайте разберем ее по полочкам: технические фичи, маркетинговый потенциал и архитектурные преимущества. А в конце — сравнение с конкурентами и реальные тесты из документации.

За 6 лет опыта работы в разных IT-компаниях — ни разу не встречал проекты на Laravel, где использовался бы CQRS. Да и погуглив немного, если честно, не нашел ничего стоящего (касательно примеров), поэтому решил сам написать статью на данную тему.

Привет, Хабр! Хочу поделиться историей о том, как столкнулся с проблемой, возможно знакомой многим разработчикам: необходимость внедрить систему рекомендаций в проект, который все еще работает на старой версии php.

Обновление версии php в legacy-проекте — это часто настоящий квест. То времени нет, то бизнес-фичи надо пилить, то еще какие-то причины. И часто бывает, что обновление версии php в командах откладывается на потом.

14 октября 2025 года вышла Joomla 6, а так же минорная версия Joomla 5.4. Что нового в этих релизах, какой релизный цикл, ресурсы для Joomla-разработчиков - в этой статье.

В прошлой статье мы рассказали, почему Compo Soft решила уйти от привычного PHP‑стека и перейти на Java ради выхода в сегмент Enterprise. Но если кто‑то подумал, что за этим решением последовал массовый найм Java‑разработчиков — нет. Мы пошли по куда более хардкорному пути: взяли всю свою PHP‑команду и начали переобучать ее на Java. Полностью c нуля. И без отрыва от производства.

Статья о реализации параллельных SOAP запросов в PHP с использованием кастомного HTTP транспорта и Guzzle promises.

Я PHP-разработчик с восьмилетним коммерческим опытом. Долгое время я не видел смысла в микросервисах — пока не перешёл на Python и не столкнулся с его архитектурными особенностями.

Статья описывает методику миграции приложения, содержащего множество SQL запросов из базы данных Oracle в Postgres. Будет интересна всем, кто собирается мигрировать или уже мигрировал приложение из Oracle в Postgres.

Последние 4 года я занимаюсь реализациейпроектов на PHP по DDD, используя слоистую архитектуру. Каждый раз я сталкиваюсь с одной из самых насущных проблем DDD: определение границ агрегата. Ведя разработку «как удобно», очень легко не заметить, как вся бизнес логика сосредоточилась в один «божий класс».

В этой статье я поделюсь своим опытом, как проектировать и разрабатывать по DDD, не скатываясь в «один агрегат, чтобы править всеми». Поговорю о проблемах определения границ агрегата и цены чтения, гидрации и содержания больших объектов в памяти PHP процесса.

На протяжении многих лет команда Compo Soft успешно создавала eCommerce‑решения, клиентские порталы, PIM‑системы и другие решения малого и среднего бизнеса. Для этих задач было достаточно привычного стека на PHP и связанных с ним технологий. Когда в 2018 компания приняла стратегическое решение о выходе в сегмент Enterprise — встал вопрос о новом стеке. Им стала Java. В этой статье решили поделиться своим пониманием и опытом — почему сделан такой выбор, и почему PHP «не вывозит» Enterprise‑решения.

Enum’ы в PHP с нами уже давно, но вы задумывались, как они реально работают внутри? Давайте разберёмся, что там происходит под капотом.

Привет, Хабр!

Redis Streams давно перестали быть экзотикой для любителей CLI и стали нормальным способом гонять события между сервисами. Но у PHP есть своя специфика: один код — два способа конкурентности. Либо Amp с неблокирующим I/O и семафорами, либо Swoole с корутинами. В обоих случаях хочется одного и того же: устойчивые consumer-группы, ручной ack, автоматический claim зависших сообщений, backpressure, экспоненциальные ретраи и внятный дед-леттер.

Берем два разных больших числа (отличаются на 1) и проверяем равны ли они. Должно быть false – не равны. Но на самом деле – true! Они «равны» 😊

Эта статья для тех, кого удивляет данное поведение.

На одной из конференций по разработке ПО я разговорился с коллегой о современных подходах и архитектурных паттернах. В ходе беседы он задал мне, казалось бы, простой вопрос:

 «Какой архитектурный паттерн используется в твоём текущем проекте?»

Этот вопрос заставил меня задумать и взглянуть на проблему выбора архитектуры под другим углом. Возможно, повлияла атмосфера конференции (всё-таки они должны приносить пользу), но я задумался: почему при разработке приложений мы чаще всего закладываем один архитектурный паттерн, а не комбинацию нескольких? Однако, как показал личный опыт и обсуждения в профессиональном сообществе, этот вопрос часто подразумевает поиск единственного правильного ответа. В реальности же, на практике, мы нередко видим, как команды стремятся придерживаться одного доминирующего подхода — будь то акцент на CQRS, строгое следование Hexagonal Architecture или применение DDD в объеме текущего понимания и опыта команды. Но мало кто пытаеться применить сразу несколько подходов, где каждый паттерн решает свою задачу.

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

Разработка на Laravel становится максимально эффективной, если использовать автоматизацию на каждом этапе: от настройки окружения до проверки кода и тестирования. В этой статье я покажу, как построить процесс разработки, который снижает количество ручной работы, повышает качество кода и ускоряет выпуск функционала.

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

Привет, Хабр! Одна из ключевых задач performance-маркетинга — понять, какая реклама реально приводит клиентов. Для кликов есть Яндекс.Метрика, но когда одно из целевых действий — звонок, анализировать источники сложнее, а значит и понять какой креатив работает лучше.

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

В Rusprofile наш домен — регтех, мы помогаем компаниям оценивать надежность контрагентов. Каждый день сотни скриптов качают данные из официальных открытых источников, парсят и строят кеши.

В какой‑то момент суммарное время работы скриптов стало неподобающим — задача заканчивалась, условно, к обеду следующего дня, в то время, когда нам нужно было к утру.

Эта статья — о том, как «проклятье масштаба» оказалось алгоритмической задачей; решение — получилось благодаря принципам обхода ориентированных графов; а запаса прочности решения хватило, чтобы с момента появления на протяжении лет не требовалось дополнительных ресурсов и каких‑либо доработок.

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

Будут технические детали, теория графов и немного рефлексии.

Доброго времени суток дорогой читатель!

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

Тема изоляции данных клиентов (мультитенантность) в saas или подобных продуктах исторически считается если не самой, то одной из наиболее сложных и требующих архитектурных извращений, тем в веб-разработке.

Существует несколько разных подходов, от банального tenant_id в каждой таблице базы данных, до физического разделения данных на разные сервера под разных тенантнов.

Компромиссным решением является выделение идентичных по содержимому (таблицам) схем для каждого нового клиента в одной базе данных. Таким образом мы получаем относительную защиту от утечек данных между клиентами с минимальными затратами на аренду новых серверов. Именно этот вариант мы и будем рассматривать.

Привет, Хабр! Мы — команда проекта ChameleonLab, и это история о том, как мы начали создавать полномасштабный образовательный центр по стеганографии и криптографии, отправной точкой которого стал наш desktop-инструмент.

По просьбам пользователей мы начали трансформацию в онлайн-сервис. Расскажем, как мы создали сайт на собственном микро-движке, который работает на JSON-файлах, почему отказались от популярных CMS и как планируем переносить сложную логику с Python в веб.