Пятиминутка PHP

Слушал подкаст про DDD. Ведущий рассказал пример неудачного проектирования, когда в таблице "Заказы" оказалось 150+ полей (очень много). На этом моменте мне захотелось сказать Hold my beer... Открываю инспектор БД и смотрю таблицу shipment в своём проекте: 482 колонки, 46 foreign keys! В одной таблице все виды перевозок: • авто • авиа • море • Ж/Д • мультимодальные (несколько видов транспорта) • и даже таможенное оформление как отдельный вид перевозки! От такого "DDD" даже у нейросети контекст отвис 😂

🔥 4 RFC в истории PHP, которые провалились буквально из-за пары голосов В языке PHP многие фичи, которые сегодня кажутся очевидными, сначала не проходили голосование RFC. Иногда не хватало буквально нескольких голосов. Вот несколько показательных примеров. --- 1️⃣ Typed Properties (2016) Сегодня это нормальная часть языка:

class User {
    public int $id;
}

Но первая версия RFC провалилась. Результат голосования:

Yes: 24
No: 17

На первый взгляд — победа. Но для этого RFC требовалось 2/3 голосов. Через несколько лет предложение переработали — и Typed Properties появились в PHP 7.4. Сегодня это одна из самых используемых возможностей языка. --- 2️⃣ Scalar Type Hints До PHP 7 нельзя было писать:

function sum(int $a, int $b)

Можно было типизировать только: * array * callable * классы Первая версия RFC по scalar types провалилась буквально на грани. Типичный результат одного из голосований:

Yes: 31
No: 25

До порога 2/3 голосов опять немного не дотянули. В итоге появился компромисс:

declare(strict_types=1);

И scalar types всё-таки попали в PHP 7.0. --- 3️⃣ Generics Одна из самых ожидаемых фич PHP до сих пор. Идея:

class Collection<T> {
    public function add(T $item) {}
}

Generics дают: • сильную типизацию • безопасные коллекции • лучшее автодополнение IDE Главная проблема — сложность реализации. Generics требуют серьёзных изменений: • type system • runtime • reflection • opcache Поэтому обсуждение этой фичи продолжается уже много лет. --- 4️⃣ Named Arguments Сегодня можно писать так:

setcookie(
    name: "test",
    expires: time() + 3600
);

Но первая версия RFC была отклонена. Разработчики опасались: • ломать старые API • сложности в call stack • несовместимости с variadic функциями После переработки RFC всё-таки приняли, и Named Arguments появились в PHP 8.0. --- 💡 Интересный факт В internals есть шутка: > RFC не умирает — он просто уходит на переписывание. Большинство крупных фич PHP проходят примерно такой путь: 1️⃣ первая версия RFC проваливается 2️⃣ идею перерабатывают 3️⃣ через несколько лет она всё-таки попадает в язык

В начале марта открыто голосование по RFC ValueError Conversions для PHP 8.6, которое предлагает заменить множество предупреждений (E_WARNING) на ValueError, когда функции получают некорректные значения. Пример:

<?php
 
// Current behavior (may hang on some systems, e.g. macOS)
var_dump(copy("source.txt", "")); // bool(false)
 
// After (proposed behavior)
try {
    copy("source.txt", "");
} catch (ValueError $e) {
    echo $e->getMessage();
    // copy(): Argument #2 ($to) must be a non-empty valid path
}
 
// PHP ≤ 8.5: return false
// PHP 8.6 (proposed): ValueError exception
 
?>

https://discourse.thephp.foundation/t/php-dev-rfc-vote-valueerror-conversions-for-php-8-6/5206 Голосование открыли — но сразу нашли нарушения правил. • нет обязательной опции Abstain (воздержаться) • не было “Intent to Vote” объявления • RFC обсуждали меньше минимального cooldown-периода (14 дней) • markdown-разметка голосования в wiki была сломана, из-за неправильных отступов варианты голосования не отображались

«Новая флагманская модель …» Флагманская модель, которую мы заслужили:

Laracon EU 2-3 марта 2026. Сейчас Live на YouTube панельная дискуссия о направлении развития Laravel и экосистемы: https://www.youtube.com/live/YJmuKPk3d9M?feature=shared

Оказывается в апреле 2026 заканчивается поддержка MySQL 8.0 Хорошие новости: перейти на следующую LTS версию MySQL 8.4 должно быть достаточно просто, несовместимых изменений очень мало: https://dev.mysql.com/doc/refman/8.4/en/upgrading-from-previous-series.html 🆕 Я сделал краткую выжимку «что нового» через Perpelxity: Ключевые улучшения в 8.4 (относительно 8.0) Производительность InnoDB • innodb_io_capacity: 200 → 10000 (учёт SSD).[percona] •ется поддержка MySQL 8.0 16MB → 64MB. •преле 2026 заканчиваетс fsync → O_DIRECT. • 2026 заканчивается поддерж all → none (быстрее на флэш). • Автообновление гистограмм (`ANALYZE TABLE` работает автоматически).[opennet +1] • innodb_buffer_pool_in_core_file: ON → OFF (меньше дампов). Репликация и GTID • GTID-теги: можно метить группы транзакций для аудита/отслеживания.[percona] • SOURCE_RETRY_COUNT: 60 → 10 (быстрее failover). • Новые колонки вжка MySQL 8.0 Хорошие Оказывается в аОказывается в апрОказывается в апреле 2026 з • Репликатор всегда используетчивается поддержка MySQL(убраны старые варианты).[mysql] Безопасность и дефолты •.0 Хорошие новости: переустарел, по умолчанию2026 заканчивается поддер(как в 8.0, но строже).[spec-zone] •тся поддержка MySQL 8 1GB → 3% от RAM (1-4GB). • Убраны legacy-опции репликации (`log_bin_use_v1_events`, `--relay-log-info-file`). Ставь лайк, если используешь MySQL. Ставь дизлайк, если на PostgreSQL. Fight❗️

PHP-линч Yii3 В эту среду в 19 состоится долгожданный PHP-линч Yii3! В прямом эфире установлю новоиспечённый фреймворк и поделюсь первыми впечатлениями. Всех жду! 📹 YouTube 📹 VK Видео

Раньше были похожие мемы про бесполезную автоматизацию одноразовых простых задач 😀

Сегодня наконец-то PHP-линч #29! Я открываю новый сезон знаменитой рубрики PHP-линч! Сам по ней невероятно соскучился. Хотелось бы сразу посмотреть на Yii3, но лучше мы в этот раз разогреемся чем-то поменьше, а, например, в следующую среду весь стрим посвятим Yii. Залетайте в 19:00 на 📹 YouTube и 📹 VK Видео. #php_линч

Заметка по HTTP клиент. Иногда надо сделать http запросы к сервисам (REST и не только). Посмотреть ответы, заголовки, поиграться с параметрами запроса. Ещё хотелось бы коллекцию типовых запросов хранить где-то в проекте под git контролем. В разные годы пользовался разными инструментами, везде есть свои плюсы и минусы: • curl - неудобно • httpie - лучше чем curl, но неудобно • PhpStrom HTTP Client - были баги в разные периоды, сейчас надо смотреть свежим взглядом (лень) • Postman - само приложение тормозит (электрон?), работает через облако (я не разобрался как работать без облака) • Insomia - очень много багов интерфейса (электрон!), очень плохо. Последний раз пользовался 3 года назад, может всё стало лучше. • RapidAPI - всё аккуратно и удобно, багов не замечено. Платный инструмен. Формат хранения коллекции запросов бинарный (не удобно для хранения в git) • Bruno - мой выбор текущего дня! 🏆 Bruno: https://www.usebruno.com/ • OpenSource • Бесплатный • Коллекции запросов хранятся в текстовых файлах (удобно для версионирования в git) • Интерфейс примерно как у всех оконных клиентов, всё на своих местах, привычно (аля Postman, Insomnia, RapodAPI)

Начали стрим!

🐘 Знакомство с новыми авторами PHPeople В PHPeople пополнение! К нам присоединились пять новых экспертов: • 🐘 Александр Макаров — всемирно известный лидер команды Yii • 🐘 Петр Мязин — автор Пятиминутки, перешёл с PHP на ИИ • 🐘 Павел Бучнев — фартанист и вайб-кодер • 🐘 Вадим Дворовенко — знает Laravel как Тейлор, но ещё не лысый • 🐘 Edmond Dantes — разрабатывает асинхронный PHP будущего 3 февраля в 19:00 приходите на стрим, где авторы расскажут что будет в их блогах на PHPeople. https://www.youtube.com/live/WovfLIMJn6A?si=grudZYFg_NRT0sef По многочисленным просьбам на PHPeople запустили тариф, который позволяет подписаться на всех авторов сразу со скидкой 33%. 🐘 Основная группа + 11 авторских = 1800 1200₽/месяц. Удобно, если хочешь следить за всеми темами сразу: от Laravel и архитектуры до AI и карьеры. Основная группа: 150₽/мес Авторская группа: 150₽/мес Полный доступ: 1800 1200₽/мес Подписаться 👉 🐘 @phpeople_bot

Я прошел опрос PHP сообщества: https://forms.yandex.ru/u/6950cd6895add530eba7b290/ Пруф видео:

🚀 Большой ежегодный опрос по PHP 🐘 🤘 Присоединяйся и помогай комьюнити становиться только лучше! Мы запускаем очередной ежегодный опрос, чтобы выяснить, на каких технологиях мы работаем, чем живём и в каком направлении движемся. На этот раз командой Live PHP подготовили для вас улучшенную версию опроса, чтобы собрать самые актуальные данные и взглянуть на развитие PHP в 2025 году. В прошлом году 1207 разработчиков поделились информацией о своих предпочтениях: какие версии PHP они используют, какие фреймворки любят и как относятся к ИИ. 📊 На этот раз мы посмотрели на опрос под другим углом и постарались сделать его ещё лучше! Присоединяйся к нашему анонимному опросу и дай знать, в каком направлении было бы интересно развиваться! А ещё мы традиционно разыгрываем слонов. Хотя опрос анонимный, но если ты оставишь свой email, то сможешь поучаствовать в розыгрыше слона от канала Пых. ✍️ Проходи опрос и помоги собрать аналитику для русскоязычной PHP-тусовки! По итогам сделаем подборки статей, докладов, каналов по PHP. Все результаты опубликуем на phpcommunity.ru Сделай свой вклад уже сегодня!

В это трудно поверить, но Yii3 вышел а прошлом году! Как быстро летит время 🎅

#Новости 🚀 Yii3 готов! • Страница Yii3 • Официальный анонс • Документация • Шаблоны приложений: Web, API, Console • Демо-приложения: Блог (DDD со слоями), Дневник (вертикальные срезы, Active Record) Спасибо за вашу поддержку и терпение! Мы сделали это вместе — команда разработчиков, участники сообщества и спонсоры 🤝 Мы уверены, что кодовая база Yii3 будет служить нам как минимум в течение следующих 10 лет, а возможно и дольше. С Новым годом! 🎉

Они до сих пор не поняли… 😩

Крутой промо-ролик к подкасту про Go!

📈 Экономика кодирования Из чего складывается совокупная стоимость кодирования: 1. Стоимость написания кода 2. Стоимость добавления новых фич в существующий проект (вариация п1) 3. Стоимость поддержки 4. Стоимость вывода из эксплуатации Оставим за скобками продактов, ТЗ и бесконечные согласования с бизнесом, говорим только про инженерию. Стоимость написания - это единоразовый платёж. Стоимость поддержки - это кредит, который оплачивается годами. С хорошим кодом проценты по кредиту маленькие, с плохим кодом обслуживание технического долга выходит очень дорогим. Мы пишем чистый код, применяем SOLID принципы и т.п. чтобы бороться со сложностью и на этапе написания, и на этапе дальнейшей поддержки и развития проекта. Отдельно хочется отметить стоимость вывода из эксплуатации, о чём иногда забывают. Если модуль А жестко привязан к модулю Б, вы не можете просто удалить Б, когда он устареет. Вам придется переписывать А - это налог на выход. High Coupling: хотите выбросить старый диван, но он приварен к несущей стене дома. Приходится оставлять диван и строить комнату вокруг него. Так рождается легаси. 💡 Код, который легко удалить - это самый чистый код. 🤖 И вот к нам приходят LLM и разработка с помощью ИИ-агентов. Экономические стимулы остаются: мы всё ещё хотим получить минимальную совокупную стоимость, но коэффициенты в этом уравнении драматически поменялись. 📉 П1. Стоимость написания кода – сильно сократилась. Вместо кодирования мы теперь занимаемся «контекст инжинирингом» и code review – это кратно быстрее и дешевле ручного труда. 📉П2/П3: С поддержкой и добавлением новых фич у ИИ-агентов, кажется, всё немного сложнее. ИИ-агенты - это рычаг или множитель. Если в проекте консистентный код, следующий определённой логике, шаблонам, архитектуре - то ИИ-агент будет повторять принятые в проекте подходы. Если в коде бардак - то с ИИ добавит ещё больше бардака и хаоса. Я в ежедневной практике вижу, как ИИ-агенты отлично справляются и с поддержкой и с добавлением новых фич в хорошо структурированной кодовой базе. За человеком остаётся «контекст инжиниринг» и code review. 📉П4: вывод из эксплуатации при наличии ИИ-агентов тоже заиграл новыми красками. Раньше была дилемма: продолжаем поддерживать текущий код или выкидываем и переписываем. В рамках целого проекта «переписать с нуля» - чаще утопическая идея. Но полностью переписать функцию, класс, набор классов, объединённых в некий модуль или переписать микросервис на другом языке - это нормально, это мы любим! С ИИ-агентом подход «напишу весь класс заново с сохранением интерфейса» или «напишу весь микросервис заново с сохранением контракта» становится максимально дешевым! Всё чаще вижу упоминание термина «Disposable Code» (одноразовый код). Итого по всем 4 пунктам заметно снижается стоимость кодирования. Процесс написание кода заменяется на написание промптов и сбор контекста - для многих задач это быстрее, это дешевле и это позволяет больше времени уделить важным архитектурным моментам, повышает уровень абстракции. Но, справедливости ради, может повыситься и стоимость Code Review. Тут определённо сказать нельзя, смотря с чем сравнивать. Если у вас была слабая команда разработчиков, то Code Review «человеческого кода» определённо требовал много внимания и сил. С другой стороны, читать код, написанный нечеловеческим интеллектом, который может галлюцинировать очень правдоподобно – тоже требует особого внимания. 💸 Вывод: если вы НЕ используете разработку с помощью ИИ-агентов, вы выбрасываете деньги на ветер. Написание кода «руками» может быть приятно лично вам, но это дорогой hand-made, как костюм индивидуального пошива. Переплатить за работу программиста, который пишет код руками без ИИ - это должен быть сознательный выбор заказчика.