Библиотека пхпшника | PHP, Laravel, Symfony, CodeIgniter

🛠️regexpbuilderphp — регулярные выражения, понятные человеку Библиотека упрощает создание и делает их более читаемыми. Она подойдет для разработчиков, которые часто используют регулярки, но сложно ориентируются в их традиционном синтаксисе. 🔗Github #инструменты

🧠 DSL vs паттерны: что выбрать в проекте В разработке часто встаёт вопрос: использовать ли DSL (Domain Specific Language) или опираться на дизайн-паттерны. Оба подхода помогают структурировать работу с данными и бизнес-логикой, но дают разный результат. 🔍 В чём разница Паттерны делают код более гибким и слабо связанным, позволяют легко подменять компоненты. Но вместе с этим усложняют ментальную модель — приходится держать в голове фабрики, адаптеры и репозитории, а сама бизнес-логика может «растворяться» в слоях абстракций. DSL описывает действия напрямую. Язык ближе к предметной области и проще для восприятия, особенно когда задачи сложные или действия цепочкой. Он позволяет выразить логику в явном виде и сократить количество лишних запросов и пост-обработки. ⚠️ Ограничения DSL 🔸 Создание DSL требует серьёзной подготовки: язык должен быть достаточно гибким, чтобы покрывать текущие и будущие сценарии. 🔸 Поддержка DSL может быть трудозатратной, особенно если доменные действия часто меняются. 🔸 Строковые DSL работают как «фронтенд кода» — за ними скрывается движок, который тоже нужно развивать. ✅ Когда что выбрать Если предметная область хорошо понятна и устойчива — стоит строить DSL. Если действия ещё уточняются, а изменения происходят часто — лучше опираться на паттерны. В сложных проектах возможен гибрид: паттерны для структуры и расширяемости, DSL для выражения бизнес-логики. 💬 А как у вас в проектах? Чаще используете паттерны или внедряете DSL? 👉 Читать статью Библиотека пхпшника #элементарный_выбор

Что будет результатом работы кода в 8+?

⚙️ PHP JIT: почему PHP уже не «медленный» Фразу «PHP простой, но небыстрый» пора отправлять в архив. С выходом PHP 8.0 в язык пришёл JIT — Just-In-Time компиляция. Суть простая: PHP во время выполнения замечает часто используемый код и компилирует его прямо в машинные инструкции. Меньше работы для Zend Engine, больше — напрямую для CPU. Важно понимать: JIT не ускоряет всё подряд. В типичных веб-приложениях на Laravel узкие места — это база данных, сеть и I/O. Там JIT почти бесполезен. Зато в очередях, воркерах, аналитике и массовой обработке данных прирост в 2–5× — реальность. 👉 Подробнее с примерами и бенчмарками — на Medium Библиотека пхпшника

💡Совет по Laravel: Eager Loading с конкретными столбцами Знаете ли вы, что при использовании eager loading с отношениями вы можете указать именно те столбцы, которые вам нужны? Это уменьшит использование памяти 🚀 Библиотека пхпшника #vardump

💻 Подборка новостей по PHP за неделю:​ 🔹 Statamic 6 Beta — CMS официально перешёл в beta-стадию после 21 alpha-релиза. Команда уверена в стабильности и обещает скорый выход stable-версии. 🔹 Laravel 12.47.0 — добавлены @includeIsolated для изолированных Blade-инклюдов, Cache::withoutOverlapping() для безопасных операций с блокировками, а также улучшена поддержка enum по всему фреймворку. 🔹 PHP 8.5.2, 8.3.30 и 8.4.17 — багфикс-релизы с улучшением стабильности. Пользователям PHP 8.5 настоятельно рекомендуется обновиться. 🔹 Symfony 12–18 января — улучшен HTTP Cache attribute, доработаны атрибуты событий контроллеров, опубликованы детали SymfonyLive Paris 2026 и представлена сертификация Symfony 8. 🔹 Filament v5 — релиз с поддержкой Livewire v4 и новым инструментом Blueprint. Обновление ориентировано на совместимость и минимальные риски при апгрейде. Библиотека пхпшника #свежак

📚 Think Distributed Systems (2025) Распределённые системы сложные не потому, что «там Kafka и Kubernetes», а потому что время, порядок, сбои и сеть тебе врут. Эта книга учит думать распределёнными системами. Что внутри без воды: 🔵 Корректность, масштабируемость и надёжность 🔵 Отказы: как их ожидать, детектить и переживать 🔵 Доставка и обработка сообщений 🔵 Партиционирование, репликация и консистентность Про что она на самом деле: Не про технологии, а про мышление. Про то, как проектировать системы, которые ломаются предсказуемо, а не внезапно. Про то, как перестать надеяться на сеть, часы и «оно само синхронизируется». Кому читать: ✔️ Бэкенд-разработчикам ✔️ DevOps и SRE ✔️ Всем, кто уже однажды дебажил race condition в проде и не хочет повторять. 🔗 Скачать 🐸 Книги для программистов | Поддержать бустом

#байтовый_юмор

Какая функция используется для сортировки массива в естественном порядке (без учета регистра)? Правильный ответ лежит в канале задач

Если в Laravel у вас есть два очень похожих объекта (например, адрес доставки и адрес оплаты) и вам нужно сделать копию одного из них для другого, вы можете использовать метод replicate() и изменить некоторые свойства после этого. Библиотека пхпшника #vardump

PHP в 2026 Если коротко: PHP не стагнирует. Он аккуратно, но системно взрослеет — и в 2026 это особенно заметно. PHP 8.5 Релиз без «вау-революций», но с полезными доработками: pipe-operator, клонирование объектов с модификацией, улучшения замыканий, нормальные stack trace даже для fatal error. Это не хайп, а качество жизни. Partial Function Application → PHP 8.6 Вот здесь начинается магия. PFA раскрывает pipe-operator по-настоящему: меньше анонимных функций, больше читаемого функционального кода. PHP медленно, но уверенно учится декларативности — и это хороший знак. Pattern Matching (RFC) Пока в обсуждении, но потенциал огромный. Более выразимые match-конструкции и is-проверки — шаг к более строгому и понятному коду. FrankenPHP Кандидат на будущее PHP-рантайма по умолчанию. Drop-in замена PHP-FPM, +10% производительности «из коробки», worker-mode, бинарные сборки, современный HTTP. Без боли — с профитом. Mago Линтер, форматтер и статический анализатор на Rust. Быстро. Строго. Практично. Пример того, как экосистема учится у других языков. Async PHP / TrueAsync Сложно, долго, но перспективно. Пока фокус на CPU-тасках и потоках, но если дойдём до удобного async I/O — PHP сильно выиграет в серверных сценариях. PHPverse — возвращается в 2026 Онлайн-конфа показала, что комьюнити живо и массово. Это важно. Tempest Новый взгляд на PHP-фреймворки: современная архитектура, активное OSS-сообщество, третий мажорный релиз на подходе. 🔗 Ссылка на статью Библиотека пхпшника

🧠 Оптимизируйте автозагрузку в Symfony с помощью Service Container preloading 🚀 Что такое preloading в контексте Symfony Symfony пользуется Service Container, который создаёт множество PHP-классов и зависимостей для каждого запроса. Чтобы снизить накладные расходы на автозагрузку и повторную компиляцию этих классов на каждом запросе, можно включить OPcache-preloading — когда PHP загружает классы один раз на старте процесса и держит их в памяти. Preloading помогает избегать многократного вызова автозагрузчика и снижает I/O-операции, потому что классы уже готовы к использованию до первого запроса. ⚙️ Как это работает в Symfony 1. Symfony может сгенерировать специальный preload-файл, который содержит список нужных классов — часто это файл вроде: var/cache/prod/App_KernelProdContainer.preload.php Этот файл включает в себя наиболее важные классы контейнера и зависимостей. 2. В php.ini нужно указать путь к этому файлу в директиве opcache.preload: opcache.preload=/path/to/project/var/cache/prod/App_KernelProdContainer.preload.php opcache.preload_user=www-data Благодаря этому PHP заранее закеширует эти классы в OPcache ещё до обработки первого запроса. 3. Symfony поддерживает теги container.preload и container.no_preload, чтобы тонко настраивать, какие классы должны (или не должны) попадать в preload. Это даёт контроль над тем, какие части приложения загружаются заранее. 📈 Почему это даёт преимущество 🔹 Меньше автозагрузки: после preload’а PHP не вызывает автолоадер для этих классов, что снижает число системных вызовов и ускоряет отклик. 🔹 Более быстрый контейнер: код контейнера (сервисы, зависимости) часто входит в preload-список — это ускоряет его инициализацию. 🔹 Оптимизация OPcache: preload’енные классы остаются в памяти OPcache между запросами, снижая накладные расходы на парсинг и компиляцію PHP-файлов. В реальных измерениях включение preload помогало снижать количество вызовов автозагрузки и ускорять работу приложения, сокращая время отклика и снижая нагрузку на CPU. 🧠 Когда использовать ✅ Production-среда: preload лучше всего раскрывает себя на стабильно работающем приложении без частых изменений файлов. ✅ Большие проекты: где много сервисов и зависимостей — preload помогает устранить значительный слой задержек. ⚠️ Dev-окружение: preload менее нужен, так как код часто изменяется — потребуется частый рестарт сервера/OPcache при изменениях. 📌 Практические рекомендации ➤ Убедитесь, что файл preload действительно сгенерирован — в некоторых проектах его может не быть по умолчанию. ➤ Настройте OPcache: включите opcache.enable_cli, увеличьте memory_consumption, max_accelerated_files, и установите validate_timestamps=0 на проде для стабильной загрузки. ➤ Используйте теги container.preload и container.no_preload, чтобы включать только действительно нужные классы — это помогает избегать загрузки лишнего. 📌 Итог Оптимизация автозагрузки через OPcache preloading в Symfony — это мощный способ ускорить приложение на уровне PHP-рантайма: ✔️ сокращает работу автозагрузчика, ✔️ уменьшает I/O и время инициализации контейнера, ✔️ даёт заметный прирост производительности без изменения бизнес-логики. Библиотека пхпшника

«Как я ускорил установку PHP-зависимостей в 5 раз с помощью Go» PHP-разработчик решил проверить простую гипотезу: что будет, если убрать PHP-runtime и сделать установку зависимостей по-настоящему параллельной? Результат — go-composer: совместимый (почти) с Composer инструмент, написанный на Go. Почему обычный Composer медленный Коротко и без иллюзий: • интерпретируемый PHP • последовательная загрузка пакетов • тяжёлый runtime даже для простых операций • медленный SAT-resolver зависимостей В CI это превращается в минуты ожидания. Что сделал go-composer Ключевая идея — конкурентная модель Go: • параллельная загрузка всех пакетов (goroutines) • один скомпилированный бинарник (~10 MB) • отсутствие PHP runtime overhead • эффективная работа с памятью Архитектура (упрощённо) Пайплайн выглядит так: 1️⃣ Парсинг composer.json / composer.lock 2️⃣ Resolver строит граф зависимостей 3️⃣ Пакеты загружаются параллельно 4️⃣ Генерируется совместимый autoload 5️⃣ Результат — привычный vendor/ Самое интересное внутри Parallel Installer — сердце ускорения Каждый пакет: • скачивается • проверяется по SHA-256 • распаковывается • добавляется в lock И всё это — одновременно, а не по очереди. Бенчмарки (MacBook M1, 300 Mbps) Результаты выглядят болезненно честно: • Monolog (3 пакета): 3–4× быстрее • Symfony app (36 пакетов): 4–5× быстрее • Laravel app (80+ пакетов): до 5× быстрее Что уже работает ✅ composer.json / composer.lock (чтение) ✅ semver (^, ~, >=, ||, *) ✅ PSR-4 / PSR-0 / classmap ✅ Packagist (P2 API) ✅ проверка хэшей Что не работает (и это важно) ❌ Composer scripts ❌ Composer plugins ❌ VCS-репозитории ❌ Private Packagist ❌ полная совместимость composer.lock 👉 в продакшен — пока нет Почему появился go-composer.lock Полной совместимости с composer.lock пока нет, поэтому: • если lock есть — используется он • если нет — создаётся go-composer.lock • флагами можно управлять поведением Это честный технический компромисс. 👉 Хабр Библиотека пхпшника

⌨️ Топ-вакансий по PHP за неделю Middle PHP-разработчик (Fullstack) — от 200 000 до 250 000 ₽, Удалёнка/Офис (Москва) PHP Developer — 200 000 —‍ 400 000 ₽, Удаленка (Москва) Middle PHP-разработчик, Symfony (SaaS, b2b) — Договорная, Удалёнка (Москва) ➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

⚡️ How-to: serverless Symfony/PHP на AWS без Redis для сессий У serverless есть ловушка: Lambda требует stateless, а PHP-сессии по умолчанию живут в файлах. В AWS Lambda это «песок»: инстанс исчез — сессия исчезла. Частый костыль — Redis/ElastiCache, но это уже VPC, обслуживание и лишние расходы. В статье предлагают более «чистый» вариант: хранить сессии и CSRF-токены в DynamoDB. Идея простая: заменить файловый session handler на DynamoDB-backed, добавить TTL для авто-истечения и использовать Lambda Function URL (без API Gateway). В итоге приложение остаётся действительно serverless: масштабируется само, не требует инфраструктуры под Redis и платит «по факту». Отдельно разбираются single-table паттерны (сессии/CSRF/сущности в одной таблице), нюансы генерации URL в Symfony и честные компромиссы: cold start, стоимость на высоком стабильном трафике и гонки при параллельных вкладках. 🔗 Читать статью Библиотека пхпшника

#байтовый_юмор

Hi.Events Опенсорс платформа для управления мероприятиями и продажи билетов 🔗 Github Библиотека пхпшника #инструменты

От 45 мс до 8 мс: тестирование Symfony 7.4 на FrankenPHP Больше десяти лет PHP-стек выглядел одинаково: Nginx → FastCGI → PHP-FPM. Надёжно, привычно — и технологически застыло. FrankenPHP ломает эту модель полностью. FrankenPHP — это application server, встроенный прямо в Caddy. Без FastCGI, без прокси-прослоек и с ключевой фичей — Worker Mode. В чём суть В классическом PHP-FPM каждый запрос: загружает autoload поднимает Kernel и тут же всё уничтожает Для тяжёлых приложений на Symfony 7.4 это 30–100 мс чистых потерь на каждый запрос. Что меняет FrankenPHP Worker Mode загружает приложение один раз и держит его в памяти. Результат: 🚀 3–4× рост RPS ⚡ P95 latency ~8 мс 🌐 HTTP/3, Early Hints, auto-HTTPS из коробки 🔴 встроенный Mercure без отдельного сервиса Архитектура будущего Один контейнер вместо nginx + php-fpm: 1. Docker 2. FrankenPHP 3. Symfony 7.4 LTS 4. real-time события без Redis и WebSocket-зоопарка Важный нюанс Worker Mode = общая память между запросами. Stateful-сервисы — под строгий контроль. Symfony 7.4 решает это через ResetInterface, но архитектурное мышление придётся обновить. Бенчмарк (AWS t3.medium) Nginx + PHP-FPM: ~1 240 RPS / 45 мс FrankenPHP Worker: ~3 850 RPS / 8 мс PHP-FPM не «плохой» — он просто устарел. Связка Symfony 7.4 + FrankenPHP — это новый дефолт для high-load и API-first проектов. Если начинаете новый проект — выбирайте FrankenPHP сразу. Если поддерживаете легаси — пора планировать миграцию. 👉 Читать статью Библиотека пхпшника