PHP *

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

В каждом проекте рано или поздно появляется логика вида «этот пользователь может редактировать этот пост, а тот нет». И начинается: if ($post->getAuthor() === $currentUser) в контроллерах, в сервисах, в шаблонах. Копипаста расползается, а потом приходит новое требование — «модератор тоже может редактировать, но только в своей категории» — и вы бегаете по двадцати файлам, молясь, что ничего не забыли.

Symfony Voters — механизм, который выносит всю логику авторизации в одно место. Не аутентификации (тип кто ты?), а именно авторизации (что тебе можно?). Разберём, как это работает.

Привет, хабровчане!

Мы команда «Исходного кода» и уже полгода системно занимаемся нагрузочным тестированием (НТ). Раньше такие проверки были от случая к случаю - оттуда и взяли базу знаний. Сегодня хотим поделиться историей одного показательного фейла, который заставил нас пересмотреть весь подход и прийти к системе, которая показала себя, как работающая. 

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

Главный толчок был простой и жизненный: уже на стадии рассмотрения сервиса мы понимаем, какая нагрузка на него ляжет, поэтому мы выводили правило: «Сервис должен стабильно держать N запросов в секунду», и мы берем эту планку и начинаем работу.

Я почти никогда не использовал switch. Мне всегда казалось, что он ведёт себя непредсказуемо - без break код молча проваливается в следующую ветку. Нестрогое сравнение добавляет сюрпризов. В общем, я писал if/else и не парился.

Но однажды, когда-то давно, мне стало интересно: а что, если switch не просто «другой синтаксис», а реально работает иначе под капотом? Я полез в opcodes и обнаружил кое-что, что изменило моё отношение ко всем конструкциям.

Зачем нужны covers метки? Почему их так хочется сломать? Как это сделать? Рассказ будет извилист, но идея проста: улучшить навигацию, не задев покрытие.

В предыдущей статье мы открыли окно. Теперь давайте его не просто игнорировать.

Как на счёт вкорячить в него поддержку OpenGL?

Это ведь когда-то должно было произойти...

В мире уже есть примерно бесконечное количество туториалов формата "OpenGL Tutorial" (раз, двас).

Возникает логичный вопрос: Зачем ещё один?

Ответ: Чтобы наконец перевести их!

Так что я просто их решил перевести с С/С++ на PHP. А вы что подумали? Я с английского их переводить собрался?

Очередной релиз фреймворка с акцентом на нативные AI-воркфлоу, дефолтная безопасность и более выразительные API. Основные нововведения: встроенные AI-инструменты, JSON:API ресурсы, семантический/векторный поиск, улучшения очередей и кэша. Обновление через AI.

Проблема N+1 стара как мир. Инструментов много: Debugbar хорош локально, Telescope тяжеловат для продакшена. Мне хотелось решения, которое будет «стучать» в Slack или Telegram именно тогда, когда проблема случилась на проде, и при этом сразу показывать пальцем на виновную строку кода.

Текст в ленту: AI-агент пишет код. Другой AI-агент его ревьюит. Первый фиксит замечания. Ревьюер проверяет фикс. 9 параллельных субагентов, 18 000 токенов в минуту каждый, и вопрос, который никто не задаёт: а кто проверяет ревьюера?

Это перевод статьи Брайана Тимана (Brian Teeman) о переопределении макета материала Joomla, с разделением блока вводного текста и полного текста материала. С примером возможного оформления.

Сайт Словарус 2.0 – это вторая улучшенная версия сайта с русской заменой иностранных слов, который я ранее делал по заказу Love Media и лично господина Маркелова.

Задача. Восстановить сайт из веб-архива и сделать его лучше.

словарус.рф

Это первая часть цикла статей о разработке системы публикации структурированных интерактивных постов через Telegram Bot API. В следующих частях — архитектура, рендеринг шаблонов и управление доступом к закрытым чатам.

С чего всё начинается

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

На первый взгляд — ничего сложного. Telegram Bot API умеет отправлять текст, прикреплять медиа, рисовать inline-кнопки. Но именно в этот момент начинается то, что разработчики называют «дьявол в деталях».

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

Привет, Хабр! (И тебе, страдалец, который три недели смотрит на мёртвого бота в Битриксе. И тебе, админ, который уже устал объяснять руководству, почему «оно перестало работать». И тебе, безопасник, который узнал, что данные компании летают через какой-то curator.pro и чуть не уронил кружку.)

Помните мою прошлую статью про разработку Битрикс-бота? Ту самую, где я рассказывал, как документация врала, облака смеялись, а трафик зачем-то летел через сторонние сервера? Так вот - продолжение банкета.

Спойлер: стало хуже. Но мы справились.

REST API на Symfony писать удобно, но есть одна скучная особенность: контроллеры быстро начинают обрастать повторяющимся кодом. Парсинг запроса, валидация, однотипная JSON‑обёртка, try/catch с преобразованием исключений в HTTP‑ответы. Всё это несложно, но со временем размазывается по десяткам эндпоинтов и отвлекает от основной задачи.

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

Брент Роуз, партийный функционер говорящая голова сообщества РНР и автор очередного конкурирующего стандарта фреймворка Tempest, объявил конкурс, весьма вторичный, после эпичного One billion row challenge (который и сам по себе уже был вторичен, по отношению к оригинальному 1brc), но кто ж считает, когда на кону такие призы, как плюшевый слон от JetBrains!

Каждый раз, когда хотелось быстро попробовать что‑то на Symfony, начиналась одна и та же история: поднять контейнер с PHP‑FPM или FrankenPHP, провалиться в контейнер, поставить symfony/skeleton, настроить Nginx или Caddyfile, прописать переменные окружения... И всё это до того, как написана хоть одна строчка кода.

DI‑контейнер, консольные команды, компонентная архитектура... Ни для кого не секрет, Symfony заметно ориентируется на Java‑экосистему. Почему бы не попробовать сделать что‑то подобии start.spring.io подумал я.

Так появился пет-проект symfony-init.dev

Scedel - это language- и protocol-agnostic язык для описания схем данных и контрактов. В статье я опишу сам язык, а также расскажу, зачем я его создал

RAG на PHP - звучит непривычно. Делюсь опытом построения чат-бота для поиска по внутренней базе документов: Symfony, Qdrant с гибридным поиском, YandexGPT для embedding и генерации ответов. Внутри — готовый код, подводные камни чанкинга и советы, которые сэкономят вам время.

У меня была привычка. Вижу классную статью про архитектуру —-сохраняю. Репозиторий с примерами DDD - в закладки. Видео про CQRS - в плейлист «Посмотреть потом».

Вы знаете, чем кончаются плейлисты «Посмотреть потом».

В какой-то момент закладок стало 300+. Половина ссылок битые, треть дублируют друг друга, остальное - статьи, которые казались гениальными в два часа ночи. Я сел и вычистил всё до 106 ресурсов. Собрал их в awesome-list на GitHub.

Но статья не про список. Статья про три вещи, которые я для себя открыл в процессе и которые почему-то мало обсуждают.

В комментариях к моей предыдущей статье про Waypoint прозвучало: «это стандартный алгоритм, ничего уникального». Trie — стандартный. Хеш-таблица — стандартная. Всё так. Но покажите мне PHP-роутер, который каскадирует O(1) хеш-таблицу, посегментный prefix-trie и prefix-grouped fallback в три уровня матчинга, генерирует именованный PHP-класс с immutable const для OPcache shared memory, а при диспатче не делает ни одного вызова Reflection. В этой статье — не маркетинг, а код и алгоритмы: разбираю каждое архитектурное решение и сравниваю с FastRoute и Symfony Routing.