PHP *

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

Приложение Bitcord занимает очень мало места. Размер его установочного пакета составляет чуть более 3 мегабайт (3.2 Мб. актуальный релиз). Оно не перегружено сложной графикой и не использует тяжёлые библиотеки или SDK. К примеру, реализованная в мессенджере видеосвязь, построенная по технологии WebRTC (P2P), задействует встроенные компоненты самой операционной системы, что позволяет сократить размер приложения на десятки мегабайт.

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

Поэтому выход Rubix ML 3.x – важное событие для PHP-разработчиков, которые хотят использовать машинное обучение в своих проектах. Это не просто очередная версия библиотеки: обновление затронуло производительность, обучение нейросетей, обработку данных и возможности параллельных вычислений.

Кроме того, у проекта появился официальный сайт с обзором возможностей библиотеки, документацией и примерами. Он помогает увидеть Rubix ML не как набор отдельных алгоритмов, а как полноценный инструментарий для всего цикла машинного обучения – от подготовки данных до применения обученной модели в production.

Разберём, что изменилось и почему это интересно разработчикам, которые работают с PHP каждый день.

Клиент написал: сайты лежат, похоже на DDoS. На сервере около 5 500 сайтов WordPress, nginx, PHP-FPM 8.4, MariaDB, 125 ГБ памяти, Debian 13. Я нашёл сканер, закрыл его в nginx, сайты поднялись. Через два дня клиент написал снова: всё падает каждые пять минут.

Причина оказалась не снаружи. Каждый новый воркер PHP-FPM с первого же запроса весил около 600 МБ, и OOM-killer по очереди убивал базу и nginx. Воркеры раздувал баг в OPcache, который срабатывает на каждом сбросе кеша под нагрузкой. Сбрасывал кеш Yoast SEO при обновлении. Причём не массовое обновление по всем сайтам, а догоняющее, на 467 сайтах, где плановое когда-то не прошло. Всё решил порядок двух команд.

13 октября 2026 года вышла Joomla 6.2. Традиционно мы обозреваем часть самых заметных нововведений релиза. В нём доработали редактор материалов, добавили авторизацию почты через OAuth 2.0, поле Joomla Form enum и обозначение обновлений безопасности расширений, language fallback...

Между нажатием кнопки и результатом у нас проходит от трёх до шестидесяти секунд: очередь, воркер, внешний API, иногда таймаут. А снаружи — пользователь, у которого на счету ровно одна генерация, и палец, который очень хочет нажать ещё раз.

Разбираю двухфазное списание: резерв при постановке в очередь, списание ровно зарезервированного при успехе, удаление строки при провале. Плюс мьютекс на пользователя через UNIQUE-индекс, почему цену нельзя пересчитывать при списании, что делать с резервами от умерших воркеров и зачем суточные лимиты обновлять скользящим окном, а не кроном в полночь.

Летом я сделал сайт, который собирает публичные Telegram‑каналы российских стримеров в одну ленту. Идея была простая: я подписан на десяток таких каналов и устал листать их по очереди, чтобы узнать, будет ли сегодня стрим.

Через три месяца у проекта 260 коммитов, 450 каналов, больше 60 тысяч постов в базе, около 4 тысяч страниц в поиске Яндекса и доход от рекламы — 1–2 рубля в день. Это честная ретроспектива: что сработало, на какие грабли я наступил и что показали данные про то, зачем люди на самом деле приходят на такой сайт. Спойлер: не за тем, для чего я его делал.

В 1969 году психиатр Элизабет Кюблер-Росс выпустила книгу «О смерти и умирании». В ней она описала, как человек переживает неизбежное: отрицание, гнев, торг, депрессия, принятие. Писала она о неизлечимо больных пациентах, но модель оказалась настолько универсальной, что её теперь примеряют на что угодно: от расставания до повышения ставки по ипотеке.

Сама Кюблер-Росс оговаривалась, что стадии не обязаны идти строго по порядку: их можно проскочить, к ним можно вернуться, на них можно застрять. Особенно застрять.

WordPress хоронят не первый год. Сначала казалось, что его вытеснят конструкторы сайтов, затем современные JavaScript-фреймворки, headless-подход и облачные платформы. Теперь к этому списку добавились нейросети: они уже умеют не только писать отдельные фрагменты кода, но и работать с проектом целиком – запускать WP-CLI, подключать плагины, готовить тесты и помогать с деплоем.

Что это меняет для WordPress в 2026 году? Стоит ли новому разработчику изучать его с нуля, если ИИ-агенты и вайб-кодинг берут на себя всё больше рутины? Где WordPress по-прежнему удобен, а где логичнее выбрать Laravel? И насколько сегодня нужны Elementor, Gutenberg, ACF и WooCommerce, если часть задач уже можно поставить обычной фразой?

Я, Александр, автор телеграм-канала «Shulepov Code», поговорил с Александром Сокиркой – разработчиком, который пришел во фриланс еще школьником, начинал с баннера за пять долларов, затем работал с Joomla и WordPress, продавал шаблоны на маркетплейсах, сотрудничал с американскими студиями и сейчас активно экспериментирует с вайб-кодингом и ИИ-инструментами. У Александра также есть YouTube-канал: «Быть Программистом», где он публикует материалы о разработке и своем опыте.

В разговоре мы не ограничились WordPress. Обсудили Laravel, Copilot, Claude, Codex и Qwen, фриланс и зависимость от платформ, Elementor и Gutenberg, ACF и таксономии, Docker и CI/CD, WooCommerce и выгорание. Отдельно поговорили о том, что имеет смысл учить разработчику сегодня, где ИИ действительно экономит время, а где без понимания архитектуры и кода всё равно не обойтись.

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

Привет! Я Паша, участвую в разработке сервиса записи сессий Broux. В этой статье я расскажу, как мы добиваемся соответствия продукта российским законам с точки зрения персональных данных, что в нашей нише не так уж просто. И я не юрист: юридическая часть ниже описывает, как мы это поняли. Проверяйте со своим юристом.

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

Ниже о том, где обычно утекает лишнее, как с этим работать и при чём здесь 152-ФЗ.

В репозитории проекта лежит 146 YAML-файлов с контентом: персонажи, сюжеты, настройки моделей. На каждом деплое они импортируются в базу — прямо там же, где выполняются миграции схемы.

Механизм работает второй год и меня полностью устраивал. Потом я сел писать о нём статью, полез перечитывать собственный код импортёра и нашёл сценарий, при котором опечатка в одном файле удаляет сущность из базы. Не архивирует — удаляет, и деплой при этом остаётся зелёным.

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

Небольшая веб-студия в Тбилиси, множество встреч с клиентами и два года разработки сайтов — с 2016 по 2018 год.

Консьюмер очереди на PHP, который раньше раз в пять-шесть часов падал по OOMKilled. Сообщения при этом не терялись: Kubernetes поднимал под, и консьюмер дочитывал очередь, так что снаружи проблема была почти незаметна. Но регулярное падение по памяти — не норма, и мы решили докопаться до причины...

Я провёл бенчмарки различных серверов и режимов запуска PHP: PHP-FPM + Nginx, FrankenPHP (классический и worker-режим), Rapira (классический, worker, dispatcher), OxPHP (классический, worker), RoadRunner, FreeUnit, Swoole.

Сделал калькулятор налога для самозанятых на Laravel + Inertia + Vue с SSR и выложил на обычный shared-хостинг. Сам калькулятор написал за пару вечеров. Всё остальное время ушло на то, чтобы поисковики увидели сайт так же, как браузер.

За два месяца: SSR-демон падал с EPERM, порт оказывался занят «через раз», главная месяц уходила в кэш пустой страницей, а проверка SSR в CI была зелёной, потому что не могла упасть в принципе. Плюс месяц блокировки хостером, о которой я не знал, и фильтр «малоценных страниц» от Яндекса.

Разбираю грабли по порядку — может, кому-то это сэкономит месяц.

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

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

Год назад выяснилось, что за один проход каждая обслуживает ровно половину тех, кого сама же выбрала. Ошибок при этом нет, лог чистый, метрика отправленных растёт. Виноват chunk(), который листает выборку через OFFSET: обработанная строка из этой выборки выпадает, и окно уезжает.

Разбор на живом проекте с 300 тысячами пользователей в месяц: как chunk() теряет строки и чем его заменить, почему withoutOverlapping() по умолчанию блокирует команду на сутки, откуда берутся дубли рассылки и зачем пришлось переворачивать порядок колонок в составном индексе.

Разбираемся, как дать AI-ассистенту доступ к документации API, не загружая в контекст всю спецификацию. Импортируем Swagger PetStore в PostgreSQL и собираем на официальном пакете laravel/mcp сервер с четырьмя инструментами: поиск по документации, детали операции, именованная схема и список операций по тегу. Проверяем контракт в MCP Inspector и подключаем сервер к Claude Code.

Привет, Хабр! Меня зовут Владимир Аламов, я инженер по информационной безопасности и комьюнити-лидер сообщества Security Champions в  Авито. 

Недавно AvitoTech совместно с SPbCTF организовали соревнование по спортивному хакингу HoneyBadger CTF. Участникам нужно было найти в системе дыру и через неё дотянуться до спрятанных данных. Лиги сделали две: «Медовую» для новых игроков и «Барсучью» для продвинутых.

В этой статье я расскажу про одно из самых сложных заданий «Медовой лиги» — МёдХантер. Это игрушечный сервис для поиска работы. В нём нужно пройти целую цепочку и достать из одной системы сразу три флага. Начинается всё с безобидного импорта резюме по ссылке, а заканчивается запуском своего кода на чужом сервере.

Мы занимаемся веб-разработкой, CRM-системами и интеграциями. В одном из текущих проектов имеем CRM, где Telegram используется не просто для уведомлений, а как один из каналов взаимодействия с пользователем.

Наш telegram бот перестал работать.

Причём перестал весьма интересно: Telegram прекрасно принимал наши исходящие обращения через API, бот мог отправлять сообщения пользователю, но в обратную сторону — Telegram → наш webhook — запросы практически перестали доходить

Каждое нажатие кнопки в телеграм-боте — это HTTP-запрос от Telegram к вам. Около трёхсот тысяч человек в месяц, у каждого в сессии десятки нажатий, и всё это приходит в один POST-эндпоинт, у которого нет ни права на пятисотку, ни права подумать.

Пропускная способность считается до обидного просто: max_connections, делённое на время ответа. Отвечаете за 200 мс при сорока соединениях — двести апдейтов в секунду. Отвечаете за две секунды — двадцать. И ждёт при этом не абстрактный клиент, а конкретный пользователь, у которого следующее нажатие просто не доедет.

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