PHP *

Новый фреймворк тестирования Testo готов к испытаниям.

В статье: причины появления Testo; его фичи в краткой форме и в примерах; быстрый старт; что дальше.

Всем привет!

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

Что получилось

От базовой версии получилось ускориться в 4 раза, отставание от wplake/typed сократилось до "всего лишь" x2, если вам критична скорость вам к wplake/typed, если вам критична читаемость выбирайте sbwerewolf/language-specific.

В предыдущей статье мы подключали OpenGL. Но подключали его без уважения… Давайте сделаем это как надо!

А ещё признаем неприятный факт: мы тратим непозволительно много времени на бойлерплейт. Подключаем функции, прописываем константы, копируем typedef’ы и в целом занимаемся тем, что хочется автоматизировать уже на второй минуте.

Давайте разбираться, как с этим жить.

DI-контейнер — сердечко Symfony. Контроллеры, сервисы, слушатели событий, консольные команды, Voter, нормалайзеры — всё это сервисы, которые живут в контейнере и получают зависимости через него.

Разберём три уровня глубины: autowiring для повседневной работы, теги для расширяемых архитектур, compiler passes для магии уровня фреймворка.

UseCase - как организовать своё приложение с точки зрения бизнес-процессов, чтобы не погрязнуть в хаосе сервисов, контроллеров и разрозненной логики.

Всем доброго дня! На связи Валевич Артем, тимлид в AGIMA. Рано или поздно каждый разработчик сталкивается с необходимостью изучить принципы SOLID. Интернет полон теоретических статей с абстрактными примерами — треугольниками, фигурами и системами заказов. В таких примерах всё выглядит красиво. Но когда дело доходит до продакшен-кода, возникает логичный вопрос: как применять эти принципы на практике и не превратить проект в архитектурный космолет? Разбираемся.

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

PSA (Project Specific Autocomplete) — плагин для продуктов IntelliJ

Хочу представить Вашему вниманию плагин для продуктов IntelliJ, который позволяет создавать:

Автокомплит на основе кода Вашего проекта

Переходы к определению элемента синтаксического дерева (на основе кода Вашего проекта)

Шаблоны кода, состоящие из одного файла (на основе кода Вашего проекта)

Шаблоны кода. состоящие из нескольких файлов (на основе кода Вашего проекта)//

Ссылка на репорзиторий здесь. Для подробностей, прошу под кат.

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

В каждом проекте рано или поздно появляется логика вида «этот пользователь может редактировать этот пост, а тот нет». И начинается: 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 и чуть не уронил кружку.)

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

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