#Article

Тоже не смог пройти стороной PHP дженерики.
Читайте на хабре.

#ТоксикСреда

Помните такой журнальчик "В мире PHP"? В выпуске №2 я в шутку писал следующее:

RoadRunner скоро будет не нужен, т.к. будет переписан с этого медленного Golang на PHP. Наконец то! Встречаем PHPStreamServer. Здесь пока только HTTP плагин, но, надеюсь, всё будет.

Я думал, что он просто умрёт тихой смертью, особенно на фоне втаскивания FrankenPHP в кор... но нет! Пару дней назад вышел PHPStreamServer 0.7.0, а сегодня он уже собирает овер дохера лайков на Reddit.

Автор пишет:

Для меня сейчас это попытка создать полностью (на 100%) асинхронное приложение на Symfony... Вероятно, можно было бы интегрировать и Laravel, но я так не думаю.

Ну, что тут сказать... удачи и земля пухом! Впереди чувака ждёт самое интересное, т.к. сейчас в бандле IO операции пока что блокирующие.
Как раз сегодня смотрел на Symfony HTTP Kernel и прифигел с этого лютого говнокода.
Я, значит, что-то там пытаюсь улучшить в бенчах TechEmpower: смотрю на говно в официальных бандлах и костыли в неофициальных, и везде то лишняя конвертация в PSR-7, то просто лишний код, то какая-то херня с рефлексией, то ещё какие-то навороты в цикле запросов.

И всё это из-за того, что весь HTTP Foundation написан через жопу. Вызовы echo захардкожены в приватных методах, всё негибко и максимально всрато.

Главное в симфони пакетах не смотреть код! Если читать доку исключительно, то симфа отличная.
Кирилл Несмеянов

Если и любить фрейморк только за доку, то есть и более достойные альтернативы.

Не знаю, как у вас, но у меня с каждым заходом в код симфы или RFC от симфонистов укрепляется мнение, что FrankenPHP активно зафорсился разработчиками Symfony только для того, чтобы их говнокод смог нормально работать в современном мире. И чтобы никто не сказал, что франкен на самом деле – говно, они специально не рефакторят код фреймворка, замедляя этим другие рантаймы.

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

Сегодня бороздил просторы LinkedIn и наткнулся на вопрос:

Can you spot the issue in this snippet?

$users = User::where('status', 'active')->get();

if ($users->count() > 0) {
 $users = $users->where('role', 'admin');
}

return view('users.index', compact('users'));


The code runs without errors, and the output even looks fine.
But there’s a hidden conceptual problem here that could cause serious trouble in real-world projects.

Question:
Where exactly is the problem, why is this approach risky, and what would be the correct way to fix it?

Автор радуется, что код работает без ошибок и даже «выглядит нормально», но на там есть ловушка. (Кстати найдете ли вы ее?. Можете в коментах рассказать)

> ❗️ Проблема в том, что после ->get() мы уже получаем Collection и фильтруем данные в памяти (Collection::where()), а не в базе (Builder::where()).
На маленьком датасете всё выглядит красиво, а на проде с тысячами пользователей — вываливается лишняя нагрузка, лишнее потребление памяти и потеря ожидаемого поведения.

И вот что интересно.
С одной стороны, охуенный «тест на внимательность». Готов ли ты за джунами такую хуйню искать?
С другой — не демонстрация ли это проблем в Eloquent и Collection?

Фреймворк гордится тем, что «очень простой и интуитивный», но именно эта простота рождает ситуации, где:

- джун легко спутает QueryBuilder и Collection
- визуально одинаковые методы (where) на самом деле делают принципиально разное

ошибка не выдаст exception, а тихо превратится в баг производительности.

Вопрос к вам: А для вас #Laravel все еще говно?

#ТоксикСреда, фартаны.

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

1. symfony/mcp-bundle — бридж на symfony/mcp-sdk (бывший php-llm/mcp-sdk).
Здесь тулзы описываются дедовскими методами: типа JSON-schema через PHP-массивы. Кто-то скажет "низкоуровнево", я скажу "всрато". Не ведитесь на бренд, там всё из говна и палок.
Кстати, если вы всё ещё верите в Symfony и хотите как-то исправить этот AI Platform, то записывайтесь на хакатон, а то они уже совсем отчаялись.

2. logiscape/mcp-sdk-php — использовался на практике в CTX. HTTP Transport нормальный (портирован с Python SDK), но роутер — говно: RegisterHandler руками, угадываешь параметры, никаких мидлварей. Пришлось много переписывать. Архитектура не хорошая и не плохая (никакая). Такое бывает, когда бездумно переписываешь с Python.

3. pronskiy/mcp — от Романа Пронского.
По доке выглядит удобно и минималистично, но не для сложных задач.
Рома хайпнул, разработка заморожена. Сделано поверх logiscape/mcp-sdk-php 👆

4. laravel/mcp — кажется, Laravel подсмотрели решение у Ромы, но что-то пошло не так и у них получилась хуйня неюзабельная.
Схемы создаются через громоздкий билдер, где необходимо руками описывать каждое поле. LLM возвращает массив, и дальше сам разбирайся: никаких DTO, никакой валидации.
Подходит только для Hello World проектов. Можно сразу скипать.

5. php-mcp/server — MCP из Нигерии.
Выглядит прилично: схемы генерируются из аргументов методов с атрибутами, есть invocable классы. Но дьявол в деталях: DTO превращает в "type object", собственный JSON-schema валидатор строже стандарта, handler фильтрует аргументы и теряет данные.
Чтобы это заработало нормально, пришлось экстендить половину internal классов. Интеграция на пороховой бочке 👇

6. spiral/mcp-server — обвязка над php-mcp/server от инженера Spiral Scout 😎, сделанная с умом .
Решены ключевые проблемы базовой и других библиотек из подборки: вместо громоздких функций с десятками аргументов или всратых массивов используются DTO с атрибутами. По ним обнаруживаются тулзы и из них же генерируется JSON-схема через spiral/json-schema-generator. Входящие данные маппятся через Valinor с валидацией.
Подключается одним bootloader'ом, легко настраивается и интегрируется с любым сервисом.


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

Берёшь такую херню для интеграции с Task manager, где надо создавать задачи с подзадачами (~10 полей с вложенными DTO и валидацией), понимаешь что нужно что-то другое. Это не тот кейс из доки типа "тут пара аргументов $a и $b, оба строки, а JSON-схему ебани массивом". И вот уже сам сидишь и переписываешь пол пакета.

В общем, спасибо всем пацанам, которые тащат нормальные пакеты, и тем, кто им помогает ❤️

Жетончик н-н-надо? Как в баталфилд 3!

В прошлый раз я организовывал сбор на именованные жетоны на PHPRussia 2024.
Жетонами я остался доволен, поэтому давайте повторим, но уже для ПЫХ.КОНФ'25.

Условия простые:
- Вот копилка: https://www.tbank.ru/cf/1UjzHHet5aH (знаю, описание всратое, спасибо ТБанку)
- Закидывайте туда сумму от 500р с указанием никнейма в комментарии.
- Этот никнейм будет нанесён на обратную сторону жетона. Если укажете с собачкой, то и нанесено будет с собачкой @nickname.
- Если что-то не так (забыли комментарий или накосячили в написании), то всё решим в чате.
- Сбор продлится минимум неделю.
- Жетоны будут уникальными и получить их можно будет только на Пыхконфе (включая пре/афтепати).
- Цена на жетоны немного выше себестоимости. Разница пойдёт на покрытие стоковых неименованных жетонов (необработанных односторонних).

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

На фотке жетоны с PHPRussia: сверху две стороны именованных с ошкуренной поверхностью, снизу два варианта стоковых. Пыхконфовые будут отличаться.