Над одной игрой работает команда: люди правят контент в браузере, ИИ — через тот же сервис, локально разворачивать ничего не нужно. Каждый ассет живёт своим git-репозиторием: это и бэкап, и способ собрать игру из готовых анимаций, карт и библиотек — а перед тем как правки уедут в мир, видно построчно, что именно уйдёт.
Год назад я написал здесь, что собрал на PHP/Laravel AI-агента, который способен рассуждать в циклах, потестил и остановился со словами «работает, но нужны идеи помощнее». Нужно что то необычное, новое.За год прототип оброс несколькими видами памяти, RAG, оркестрацией, зрением, голосом — и слоем, который даёт агенту что-то похожее на внутреннее состояние. Рассказываю, что выросло. Получился DepthNet 1.0
На новогодних каникулах 2026 в одном из чатов Joomla-сообщества коллега по цеху поделился промптом для ИИ-агента и результатом этого промпта. За неделю до этого он впервые попробовал Gemini CLI. Я до этого ИИ пользовался только в веб версиях и в целом меня это устраивало. Увидев простыню текста, запрос в CLI и простыню ответа первое, что меня охватило: "Я НЕ ХОЧУ вот это всё изучать! Опять что-то новое, надоело...".
Потом были стадии проб и ошибок, попыток использовать готовые пакеты community skills с гитхаба с ролевым внушением "ты супер-пупер мега-бэкенд-Joomla разработчик с 40-летним опытом, сделай мне красиво". Где-то в середине этого полугодия я стал формализовать свои процессы (а это не только разработка). Формализация привела к моему пониманию некоторых базисов, которые общие для всех процессов. Об этом чуть ниже.
Теперь я хочу представить на суд уважаемой публике свои наработки по фреймворку для создания формализованных процессов работы для ИИ-агентов - Process Forge (GitHub).
Дисклеймер: Это статья-проверка на прочность. Проект работает на PHP + MySQL + Polling каждые 3 секунды. Если вы кликнули по ссылке, а сервер отдаёт 502 или упорно молчит — значит, поллинг взял своё под нагрузкой Хабра, а я прямо сейчас судорожно оптимизирую запросы и чиню базу!
Привет, Хабр!
Я в одиночку разработал web‑мессенджер Conlink Messenger. Его главная фича — полный отказ от привязки к номеру телефона: только email, пароль и никакого сбора персональных данных.
Я долго откладывал публикацию в ожидании «идеального кода», но понял, что этот момент никогда не наступит. Поэтому выкатываю MVP в том виде, какой он есть — с простой архитектурой, поллингом вместо WebSocket и кучей спорных решений.
Если после этой статьи окажется, что половину backend'а стоит переписать — значит, опубликовал не зря. Приглашаю устроить проекту честный краш‑тест!
Изначально это был монолитный портал на Laravel 8, где user фронт и admin фронт лежали рядом с беком в одной папке.
Проект ставился каждому клиенту на его собственный хостинг, и единого портала «для всех» не существовало, между клиентами отличался и бек, и фронт.
Кому‑то требовался функционал онлайн‑тестирования, кому‑то доработанный модуль оценивания. В итоге получался хаос из разных версий, у одного улучшили обработку заявок, у другого систему оценок, у третьего есть онлайн‑тестирование, но с отсталым модерированием.
Хуже всего это вылезало в поддержке. Приходит баг, лезешь в код и понимаешь, у другого клиента это давно починено, просто фикс так и не доехал до этой копии. Каждая правка жила в своей репе.
Поэтому, когда появилось время, я занялся этим проектом. Сразу поставил рамку, фреймворк не меняю, остаёмся на Laravel 8. Хотелось не переходить на другой язык, не заниматься переписыванием всего огромного бека, отделить всё в модули и переписывать уже поэтапно отдельные куски.
У Битрикса есть официальная обёртка для REST API — класс CRest, который лежит в каждом примере приложения и который все копируют к себе в проект. Он умещается в один файл и работает — ровно до того момента, пока приложение не выходит в реальную эксплуатацию с несколькими порталами и фоновыми воркерами.
Один баг стокового CRest однажды стоил мне шести суток простоя приложения, и причина была в одной строке: file_put_contents без блокировки. При обрыве записи settings.json оставался обрезанным, парсинг JSON падал, и приложение считало себя неустановленным — переставало отвечать на события и затирало валидные токены.
Я переписал CRest с нуля под то, как приложения Bitrix24 работают на самом деле:
— атомарная запись через rename() вместо file_put_contents — читатель видит либо старый файл целиком, либо новый, обрезка невозможна физически; — гонкоустойчивый refresh: одноразовый refresh_token больше не сжигается дважды, когда два воркера одновременно ловят протухший токен; — ключ портала — member_id, а не домен, поэтому переезд портала на другой домен больше не теряет токены; — drop-in совместимость со стоковым CRest: меняется одна строка use, весь остальной код остаётся как есть.
Ноль зависимостей, PHP 8.1, работает на любом шареде и коробке — в отличие от официального b24phpsdk с его symfony-стеком. Разбираю каждую граблю с кодом, показываю, чем это чинится, и честно очерчиваю нишу: типизированные обёртки по методам API — territory официального SDK, у меня их осознанно нет.
Исходный код открыт.
Скопированный шаблон Битрикс24 может годами работать без нареканий, а после очередного обновления оставить раздел с белым экраном.
Разберём три способа кастомизации на одном компоненте и посмотрим, какие доработки переживают обновления, а какие требуют постоянного сопровождения.
Добавить на страницу новые функции, не трогая саму страницу, звучит как противоречие. Но альтернативу мы посчитали командой: полное переписывание заняло бы год, в течение которого страница не получила бы ни одной новой функции. Мост между старым кодом и новым занял два месяца, и строил его уже я один. Расскажу, как этот мост устроен, почему получился несимметричным, где чуть не зациклился и что в нём так и осталось кривым.
В декабре 2016 я запустил доску объявлений. В марте 2017 написал на Спарке статью о том, как пытаюсь притащить на неё трафик. Статья была честная до неприличия: три месяца работы, около 14 тысяч рублей на рекламу, 450 рублей выручки.
Отдельным памятником стоит таргет во ВКонтакте. 515 тысяч показов, 41 переход, два поданных объявления. CTR ноль целых ноль ноль восемь. Восемь тысячных процента. Я тогда пересчитал трижды, потому что решил, что где‑то потерял запятую.
Под статьёй набежали люди и сказали примерно одно и то же: не тягайся с Авито, иди в нишу.
Я поблагодарил за фидбек и пошёл тягаться с Авито дальше.
Прошло девять лет. Сайт теперь называется косплей‑барахолкой, есть фотолента, есть приложение на проверке в Google Play, и есть довольно неловкая история с App Store, из‑за которой у меня спрашивали квитанции за квартиру. Рассказываю всё по порядку, включая места, где я выглядел глупо.
Несмотря на то, что PhpStorm уже несколько лет официально недоступен в России, он по‑прежнему остаётся одним из главных инструментов для PHP‑разработчиков. Недавно вышла новая версия PhpStorm 2026.2.
В релиз вошли новые инструменты для ИИ‑агентов, встроенная интеграция с GitHub Copilot, поддержка собственных моделей для автодополнения и новый атрибут #[FileReference]. Разработчики также добавили отдельное окно для Laravel, поддержку TypeScript 7 и улучшили работу с Git, терминалом, базами данных и Docker.
В статье разберём основные изменения PhpStorm 2026.2, а также расскажем, какие возможности для PHP‑разработки уже доступны в OpenIDE и чего ожидать от её перехода на платформу 2026.2.
Привет, коллеги. Я Евгений Пуляев, разработчик в группе компаний Далее. Имел дело с разными CMS/CMF, но MODX Revolution всегда занимал особое место в моем профессиональном опыте.
Мне стало интересно, какое состояние MODX сейчас и имеет ли смысл разработчикам знать эту технологию в эпоху Битрикса, Вордпресса и вайбкодинга.
Чтобы докопаться до правды, я проанализировал 7 млн доменов Рунета. В статье рассказываю, как проводил исследование и что оно показало.
Третий год по вечерам в одиночку пилю текстовую MMORPG в Telegram. Мрачный остров, выжившие, ресурсы, базы, драки. Проект уже один раз почти умер. Тянуть 188 тысяч строк, 464 миграции и 2401 тест в одиночку я физически не могу, помогает ИИ. Только он умеет уверенным тоном выдать неверный ответ про мой же код, и я трижды на это купился. Рассказываю, что он реально вытащил, как я обжёгся и какие проверки поставил, чтобы это не доезжало до игроков.
Мы добавили кэширование, чтобы ускорить работу бэкэнда.
Затем кэширование нарушило авторизацию.
Поначалу ситуация казалась безобидной. Сервису Symfony требовался JWT-токен для взаимодействия с внешним API. Запрос нового токена перед каждым вызовом был неэффективным, поэтому мы сохранили его в кэше и использовали повторно.
При нормальной нагрузке все работало.
При нагрузочном тестировании токен истекал, и несколько запросов одновременно проходили через один и тот же поток. Каждый из них видел пустой кэш и запрашивал у внешнего API новый JWT. Внешний API аннулировал предыдущий токен каждый раз, когда выдавал новый.
После этого часть приложения начала работать с уже недействительными токенами.
Решение заключалось не только в использовании общего Memcached, ведь проблема была не в хранилище, а в праве на обновление общего состояния.
В статье история о том, как мы с командой обнаружили состояние гонки, что изменил Kubernetes в этой проблеме и почему Symfony Lock с повторной проверкой кэша стал недостающей частью архитектуры.
В прошлой статье я поспешил с публикацией и лишь в общих чертах объяснил, что такое Napominator Home. Сегодня, как и обещал, публикую подробное руководство, которое охватывает все этапы: от установки до ежедневного использования.
В этой статье вы узнаете, как установить систему, настроить её компоненты и пользоваться всеми функциями.
Попробуем использовать инфраструктуру MAX в качестве халявного фотохостинга. Задача, конечно, учебная; в этот раз освоим приём апдейтов методом long polling и их базовую обработку.
Пока я работал над Mini-Bucket, параллельно развивался еще один проект. Именно о нем и пойдет речь в этой статье.
Предыстория: от проблемы к идее Я уже неоднократно сталкивался с одной проблемой. Вернее, даже с кучей мелких, но если их обобщить, получится одна большая. Думаю, родители, читающие эту статью, меня прекрасно поймут.
ДЕТИ… Их вечное: «Забыл!», «Я не слышал!», а в голове — только игры и бесконечное сидение в телефонах.
В очередной раз услышав это «Забыл», у меня просто поднакипело (признаюсь, я и сам порой забываю что-то проверить). Я решил: пусть.....
ИИ сегодня умеет рисовать персонажей и делать для них анимации. Но это только половина задачи. Их ещё нужно встроить в игру: импортировать, связать с игровой логикой, привязать экипировку, разместить в мире и доставить игрокам без обновления клиента. В этой части показываю, как этот конвейер работает у меня.
Для крупной федеральной компании из телеком-сектора наша команда разработала закрытую семейную платформу для сотрудников и их детей. Один родительский аккаунт объединяет несколько детских профилей, а внутри находятся тематические районы, викторины, мини-игры, творческие задания, личный прогресс, баллы и общий рейтинг.
Название заказчика и самой платформы я не раскрываю по NDA. Для этого разбора важнее масштаб задачи: речь идёт не об эксперименте с генерацией картинок, а о production-продукте, где AI-механика должна работать вместе с авторизацией, детскими профилями, расписанием контента, очередями, файловым хранилищем и правилами начисления баллов.
Одной из творческих активностей стала «виртуальная роспись» городского здания. Пользователь выбирал фотографию фасада, загружал собственный рисунок, а система превращала его в изображение на стенах. Здание должно было остаться узнаваемым, а рисунок - стать частью реальной архитектуры, а не потеряться в новой генерации.
На уровне интерфейса всё выглядит просто: выбрать основу, загрузить рисунок, дождаться результата. На уровне production-системы задача быстро перестаёт быть «вызовом AI API». Прямого доступа к OpenAI API с российского сервера нет. Сама операция длительная, работает с приватными файлами и может завершиться сетевой ошибкой, ограничением провайдера или отказом модерации.
Ниже - технический разбор этого конкретного потока: от React и очереди Laravel до небольшого собственного proxy-сервиса, встроенного в архитектуру основной платформы.
За полгода написал ряд интеграций с Битрикс24 в разных архитектурах: приложение для Маркета (PHP, 6 порталов), клиентский расчётный сервис (Node.js + PostgreSQL) и cron-синхронизатор legacy-CRM без UI и без OAuth вообще. Мультитенант везде решён по-разному, и это не случайность, ведь каждая архитектура точно закрывает свою нишу.
Внутри: сравнение трёх способов хранить OAuth-токены под 6+ порталов, разбор пяти неочевидных деталей REST API (oauth.bitrix24.tech-обход, POST vs GET на рефреше, rate limit 2 req/sec, batch на 50, буфер 5 мин), куски кода на PHP и TypeScript.
Отдельная часть — лицензирование через материнский смарт-процесс. У продукта, распределённого по клиентским порталам, нет своего backend’а, поэтому control-plane я вынес на служебный портал агентства: смарт-процесс «Лицензии», бизнес-процесс на изменение счётчика запросов, webhook approve/decline с secret. Такого паттерна в документации Битрикс24 нет — а он работает уже несколько месяцев и не требует ничего сверх штатной функциональности платформы.
Матрица «что выбирать под задачу» в конце.
Пример реализации простого кэширующего прокси для пакетов npm, composer и pip на базе node.js для Windows и Linux.
