PHP *

Полгода назад я начал писать пет-проект практически полностью с помощью LLM-агентов. Первые недели это был чистый дофамин: фичи вылетали за вечер, я один успевал столько, сколько раньше делала небольшая команда. А потом всё начало вязнуть — ровно так, как вязнет любой проект с говнокодом: каждая новая фича ломала две старые, агент правил код «на ощупь», а я тратил время не на продукт, а на разгребание.

Под катом — что я понял и что в итоге сработало: почему LLM деградирует на плохой архитектуре точно так же, как команда людей; почему SOLID, DDD и чистая архитектура не устарели, а стали важнее; и как превратить архитектурные договорённости из «пожеланий в CLAUDE.md» в контракт, который машина не может нарушить. С конкретикой: два конфига deptrac для Symfony-бэкенда и пайплайн разработки с субагентом-ревьювером.

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

Я поразмыслил над тем, как сделать современную электронную книгу рецептов, и на выходе получил проект умного холодильника, где на каждый день задаешь меню, а программа сама считает пищевую ценность, содержание полезных веществ, анализирует, насколько питание полноценное и сбалансированное. Таким образом, можно быстро создавать себе меню на неделю, которое может оказаться идеальным для продуктивности в Ваших физических тренеровках. Но далее открывается вообще новый мир: автоматизация покупки продуктов, четкое понимание, что нужно взять в магазине, ясный взгляд, сколько раз стоит питаться, чтобы не было дефицита белка или витаминов, где стоит использовать БАД и так далее. Аппаратная часть – матовый сенсорный дисплей на магнитах, подключенный к старому относительно бесполезному до этого проекта ноутбуку.

Стандартный обмен данными в 1С-Битрикс часто превращается в ночной кошмар: полная выгрузка остатков на больших каталогах может занимать от 1 до 8 часов. Когда бизнес требует обновлять данные каждые 15 минут, штатные методы API и XML-импорт просто перестают справляться.

В этой статье я покажу, как с помощью прямого SQL запроса и временных таблиц в памяти (ENGINE=MEMORY) ускорить импорт в сотни раз. Это реальный кейс с продакшена, который стабильно работает уже 4 года на проекте с миллионом товаров и десятками складов.

Заметил такую особенность во многих учебных статьях и туториалах: в популярных объяснениях паттернов часто не хватает оговорки, что ради упрощения объяснения в примере нарушены принципы SOLID.

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

Особенно часто это происходит с Factory Method. В этой статье мы разберём несколько популярных примеров этого паттерна, посмотрим, где именно возникает проблема, и обсудим альтернативы в реальных проектах.

Сотни тысяч I/O-задач, десятки воркеров и гигабайты памяти на обработку очередей. В какой-то момент мне стало интересно, можно ли решить эту задачу иначе. Так появился Thrun —runtime worker на потоках и сопрограммах. В статье разбираю архитектуру и результаты сравнений с Horizon.

Первая часть. Общие вопросы — https://habr.com/ru/articles/1047336/

Вторая часть. Установка библиотеки и пример работы с ней — https://habr.com/ru/articles/1048882/

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

Под катом делюсь обзором своего самописного PHP-фреймворка Gy — попытки сделать легковесного «убийцу» Битрикса весом 350 Кб. Расскажу, как я реализовал вызов компонентов, зачем написал кастомный SQL-движок на текстовых файлах PhpFileSql.

Костыли, велосипеды, 3 года разработки по выходным, 315 коммитов, 14232 строки кода, поддержка практически всех версий PHP и ровно 0 пользователей.

История о том, как я загнал главную страницу форума с 88 запросов до 15, выяснил, что половину работы делал впустую один невинный аддон, и в конце снял ещё четверть серверного времени строчкой в конфиге — не сломав при этом ничего из того, что работало. А заодно — полная документация на стек из четырёх своих расширений и preload, на которых форум сейчас и держится.

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

Большинству писать свой фреймворк не нужно от слова совсем. Берете Symfony, Laravel, Spiral, [ваш любимый фреймворк], нужный набор библиотек и решаете продуктовую задачу. Это разумный путь.

Зачем тогда этим занялся я? Если кратко, то потому что могу и хочу, если не очень кратко, то мне было интересно написать свой PSR-совместимый фреймворк. Все началось еще в середине десятых. На тот момент недавно вышел PHP 5.6, приняли PSR-7, позже появился PSR-15, и сборка своего велосипеда на этих новомодных абстракциях, с middleware-пайплайном, показалась мне весьма полезным и увлекательным предприятием.

За основу было решено взять nyholm/psr7, PHP-DI, для отправки ответа прикрутил laminas/httphandlerrunner, конфигурация была написана с оглядкой на тот же laminas, а middleware-пайплайн, фабрика для них, мапшрутизация, app-интеграция, провайдер аутентификации, экспорт конфигурации (в том числе экспорт замыканий) и skeleton-пакет были написаны с нуля. На это ушло примерно два или три года, и где-то к 2020 была собрана первая рабочая версия.

Потом я то забрасывал проект, то возвращался к нему вновь, то переписывал куски полностью. В 2025 году решил в очередной раз переделать все. Реализовать это устремление сильно помогло развитие кодинг-агентов. Сначала Claude Code, позже Codex. Большой объем кодовой базы был переписан или написан полностью с нуля.
Если после прочтения последнего предложения ты, дорогой читатель, почувствовал как свербит седалищный нерв, то не торопись писать свое фи или закрывать статью. Текст ниже не о вайб-кодинге и не о том, как можно легко и круто вкатиться в разработку не хуже интерпрайз-уровня, не имея никакой экспертизы в вопросе.
Кодинг-агенты хорошо решают задачу по написанию бойлерплейта, хотя, будем честны, многие другие задачи они тоже решают на достойном уровне.
В моем случае я занимался проектированием интерфейсов, архитектурой, написанием промптов, ревью и вычиткой README, а машина писала код, README, тесты, наводила на нужные мысли, предлагала, где можно посмотреть решения.

Это вторая публикация на тему практики махоботоводства. В первой были рассмотрены общие вопросы создания ботов в MAX, некоторые отличия Bot API от аналогичного у Telegram и Hello, world на чистом PHP. Здесь начнём освоение обещанной в первой части библиотеки. Чтобы не перегружать сегодняшний материал, рассмотрим установку библиотеки, опишем учебную задачу по отправке запросов через Bot API и разберём выполнение её первой части. Остальное оставим на последующие публикации; пока не знаю, сколько даже их всего будет (если, конечно, успею всё здесь опубликовать, пока всякие злобные не заминусовали карму).

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

Рассказываем и показываем, как можно использовать мониторинг за кастомизациями Битрикс24. Для работы используем телеметрическую инфраструктуру на базе OpenTelemetry Collector — проект github.com/bitrix-tools/b24-ai-starter-otel.

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

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

Сразу оговорюсь, что плагин, о котором пойдет речь, рассчитан в первую очередь на разработчиков. Для обычного администратора Вордпресса там функций пока мало.

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

Каждый composer install — это акт доверия: вы запускаете на CI и в проде код, который собрал и опубликовал кто‑то другой, а проверяете обычно лишь хеш в composer.lock. Но хеш отвечает на вопрос «тот же ли это байт, что вчера», а не «кто и из чего его собрал».

Реальные инциденты показывают цену этого доверия: в 2021-м в исходники PHP закоммитили бэкдор от имени Расмуса Лердорфа; в xz вредонос жил в release‑архиве, которого не было в git; у популярного GitHub Action переписали теги и слили секреты из тысяч пайплайнов. Между кодом на ревью и артефактом в вашем vendor/ — длинная цепочка, и атаковать можно любое звено.

В статье сначала разбор: как устроены эти атаки и почему GPG, хеши и composer audit закрывают цепочку лишь частично. Затем ответ индустрии — Sigstore: подпись без управления ключами. И главное — практика на PHP: подписываем релиз в GitHub Actions без единого секрета, проверяем эталонным gh, из CLI и прямо из кода с типизированным SLSA‑провенансом, мониторим журнал Rekor. С рабочим кодом и честной моделью угроз: что подпись ловит, а что нет.

В прошлой статье я уже рассказывал, как однажды устроился на работу и получил пачку «интересных» задач: вручную синхронизировать OpenAPI, оформленный в комментариях к коду, с самим кодом в десятке сервисов.

Тогда это звучало как начало анекдота, но мне было не до смеха.

С тех пор я сменил работу. И, как будто вселенная решила проверить моё чувство юмора, я снова вижу API, где контракт живёт рядом с кодом в ручных #[OA\...] атрибутах.

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

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

Это история про то, как боль из реальной жизни превращается в код. Без стартап-питчей, без «мы дизраптим рынок», без раунда инвестиций. Просто человек, который двадцать лет назад писал на PHP, вернулся к коду — и довёл проект до рабочего состояния, потому что иначе его команда так и продолжала бы путаться на служениях.

Приложение называется Prayer & Worship. Оно бесплатное — и остаётся таким для всего, что нужно команде на служении. Ниже расскажу, как оно появилось, на чём держится и где проходит та единственная граница, за которой бесплатно уже не получится.

Всем привет. Последние несколько месяцев (где-то с февраля-марта) мне пришлось активно взяться за разработку чатботов для MAX. Когда только пытался изучить в прошлом году эту тему, поиск материалов по этим вопросам дал несколько странные результаты: вроде что-то есть и описано, а бота создать «сейчас не получится, попробуйте позже». Эту проблему впоследствии частично решили, но актуальности материалам, на мой взгляд, не то что прибавилось, и тема скорее игнорируется. Поэтому для тех, кому ставятся такие задачи, задумал несколько публикаций по практике создания чатботов в MAX, а также поделиться своей библиотекой для yii2 (она уже есть и вовсю используется в production на нескольких проектах, но пока не в полном объёме, сейчас активно дорабатывается и причёсывается; к следующей публикации надеюсь дописать и выложить).

Как мы превратили панель управления NAS в платформу для расширений, зачем туда Log Manager и для чего Plugin Template.

В новой версии 3.6.4 я добавил возможность устанавливать плагины. Перед реализацией возникло много вопросов. Наша ключевая фишка — мультисеть (позволяет переключать фронтенд на бэкенд другого сервера для его мониторинга и управления). Значит, и модуль плагинов должен уметь переключаться.

И......