Скопированный шаблон Битрикс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.
Большинство ORM строятся вокруг естественного предположения: одной таблице соответствует одна entity. Это настолько привычно, что даже не обращаешь внимания.
Это не правило, но вокруг него проектируются почти все остальные механизмы: метаданные принадлежат классу, Unit of Work отслеживает экземпляры этого класса, миграции собираются из его описания, а объектная модель постепенно начинает повторять структуру базы данных.
Но часто в коде не требуется вся таблица, многие поля служат только конкретным процессам и ни читать, ни менять эти поля в других процессах не требуется. В статье посмотрим два подхода работы с сущностями. А также к чему я пришёл, попробовав сделать по‑другому.
Именно так я думал, когда начинал разбираться в этой теме. Но, разобравшись, я с уверенностью могу сказать, что это реально, такая идея имеет место быть и обслуживать такую архитектуру легко.
В данной статье будет описан процесс реализации архитектуры веб‑приложения с удобной системой докер контейнеров. Здесь не будет обсуждаться CI/CD, исключительно development‑side процесса разработки.
Я использую самый свежий на момент написания PHPStorm 2026.1.4 от Jetbrains, но абсолютно не важно какой IDE вы пользуетесь. В теории можно и в блокноте писать хороший код.
На примере PHP хорошо видно, как внутренние оптимизации динамически типизированного языка развиваются и усложняются.
PHP‑массив выглядит универсальным, но внутри него скрыто множество оптимизаций и ветвлений, в их числе оптимизации для хранения и работы с массивами: Packed List & HashTable. Взаимодействие между ними и copy‑on‑write дают иногда неожиданное и непрозрачное поведение с точки зрения PHP программиста.
16 лет назад я написал на Хабре статью «Нетрадиционные животные в доме» – про то, каких экзотов держат дома и с какими проблемами сталкиваются их владельцы. Статья неожиданно собрала довольно живые комментарии и подняла мне карму.
С тех пор мало что поменялось, разе что оборудование, корма, террариумы и животных стало проще находить, в остальном же всё осталось по-прежнему. Есть старые форумы и разрозненные группы во «ВКонтакте». Есть несколько сайтов, часть из которых давно заброшена. Но нет места, где можно собрать «коллекцию» своих животных, вести журнал наблюдений, найти пару для разведения, составить вишлист и просто быть среди своих.
Прошло 16 лет. Проект, наконец, дозрел.
Кто хотя бы раз работал в вебстудии над создаваемыми сайтами, знает, что используемые там универсальные движки очень даже норовистые. Чуть не уследил за правильной кастомизацией кода под требования клиента - на получи тормоза при открытии его страниц.
И ведь не сразу найдёшь, где же в глубинах проекта образовался проблемный фрагмент, начавший поглощать ресурсы сайта.
Для поиска таких мест были созданы разные инструменты профилирования. Этим термином называют всестороннее измерение нагрузки, оказываемой исследуемым скриптом на сервер сайта. Например, для языка PHP наиболее известными профилировщиками кода являются следующие: Blackfire, Xdebug Profiler, Tideways, XHProf/XGHui.
Но что если вам важнее не разноплановый функционал популярных инструментов, сколько возможность в один щелчок побыстрее выполнить основную функцию: замерить нагрузку сразу по всем задействованным файлам CMS и понятно визуализировать результат.
Для решения подобной узкой задачи я разработал очень простой бесплатный профилировщик PHP. Так сказать, студийную версию профайлера, то есть урезанную до объёма, достаточного вебмастеру при работе над проектами в студии. И делюсь этим скриптом с сообществом. Кому интересно, прошу под кат.
Классический мониторинг отвечает на вопрос «открылась ли страница». Магазин со сломанным приёмом заказов отвечает на него уверенное «да»: витрина рендерится, корзина считает, 200 OK, сертификат валиден. Не работает только одно — деньги не проходят. Шлюз остался в тест-режиме после работ, обновление сломало оформление, растёт доля сорвавшихся оплат — снаружи всё зелёное.
Разбираем, как проверять приём заказов изнутри WooCommerce: три сигнала из статистики заказов с порогами, нормированными на собственную норму магазина (чтобы не будить владельца двух заказов в неделю), и суточный smoke-прогон конвейера заказа — создать скрытый виртуальный товар, провести заказ по статусам, удалить всё за собой. Без единого письма, без следов в отчётности, без реальных платежей.
Плюс две грабли, на которых мы посидели: письма WooCommerce не глушатся фильтром woocommerce_email_classes (к моменту cron хуки уже развешаны на init — бить надо в woocommerce_email_enabled_{id}), а finally не спасает от PHP-фатала, из-за чего в чужом магазине остаётся висеть служебный заказ. И почему headless-браузер — это отдельный уровень, а не замена этому.
