⌨️ Топ-вакансий по PHP за неделю

Middle PHP-разработчик (Fullstack) — от 200 000 до 250 000 ₽, Удалёнка/Офис (Москва)

PHP Developer — 200 000 —‍ 400 000 ₽, Удаленка (Москва)

Middle PHP-разработчик, Symfony (SaaS, b2b) — Договорная, Удалёнка (Москва)

➡️ Еще больше топовых вакансий — в нашем канале PHP Jobs

«Как я ускорил установку 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
• флагами можно управлять поведением

Это честный технический компромисс.

👉 Хабр

Библиотека пхпшника

🧠 Оптимизируйте автозагрузку в 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 в 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-сообщество, третий мажорный релиз на подходе.

🔗 Ссылка на статью

Библиотека пхпшника

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

Библиотека пхпшника

#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. Обновление ориентировано на совместимость и минимальные риски при апгрейде.

Библиотека пхпшника

#свежак

💡Совет по Laravel: Eager Loading с конкретными столбцами

Знаете ли вы, что при использовании eager loading с отношениями вы можете указать именно те столбцы, которые вам нужны? Это уменьшит использование памяти 🚀

Библиотека пхпшника

#vardump

⚙️ PHP JIT: почему PHP уже не «медленный»

Фразу «PHP простой, но небыстрый» пора отправлять в архив. С выходом PHP 8.0 в язык пришёл JIT — Just-In-Time компиляция.

Суть простая: PHP во время выполнения замечает часто используемый код и компилирует его прямо в машинные инструкции. Меньше работы для Zend Engine, больше — напрямую для CPU.
Важно понимать: JIT не ускоряет всё подряд. В типичных веб-приложениях на Laravel узкие места — это база данных, сеть и I/O. Там JIT почти бесполезен.

Зато в очередях, воркерах, аналитике и массовой обработке данных прирост в 2–5× — реальность.

👉 Подробнее с примерами и бенчмарками — на Medium

Библиотека пхпшника

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

🧠 DSL vs паттерны: что выбрать в проекте

В разработке часто встаёт вопрос: использовать ли DSL (Domain Specific Language) или опираться на дизайн-паттерны. Оба подхода помогают структурировать работу с данными и бизнес-логикой, но дают разный результат.

🔍 В чём разница

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

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

⚠️ Ограничения DSL

🔸 Создание DSL требует серьёзной подготовки: язык должен быть достаточно гибким, чтобы покрывать текущие и будущие сценарии.
🔸 Поддержка DSL может быть трудозатратной, особенно если доменные действия часто меняются.
🔸 Строковые DSL работают как «фронтенд кода» — за ними скрывается движок, который тоже нужно развивать.

✅ Когда что выбрать
Если предметная область хорошо понятна и устойчива — стоит строить DSL.
Если действия ещё уточняются, а изменения происходят часто — лучше опираться на паттерны.
В сложных проектах возможен гибрид: паттерны для структуры и расширяемости, DSL для выражения бизнес-логики.

💬 А как у вас в проектах? Чаще используете паттерны или внедряете DSL?

👉 Читать статью

Библиотека пхпшника

#элементарный_выбор

🛠️regexpbuilderphp — регулярные выражения, понятные человеку

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

🔗Github

#инструменты

How to: масштабировать до миллиарда документов в Symfony

Цены на бензин меняются по несколько раз в день. В итоге получается адский датасет: десятки гигабайт CSV и сотни тысяч записей цен за сутки. Если грузить это «как в SQL» (по документу на каждую цену), MongoDB быстро превращается в кладбище индексов и медленных агрегаций.

Как делают по-взрослому: сначала разбираем структуру данных (станции отдельно, цены отдельно), потом проектируем схему под запросы. Главный трюк — bucket pattern: складывать цены не по одной записи, а «ведрами» по станция + тип топлива + день, внутри хранить массив цен за день. Так документов становится в разы меньше, а дневные графики и «последнюю цену» можно доставать быстро.

Дальше — импорт не через «всё в память», а по дням: читаем CSV → временная коллекция → агрегация в bucket-документы → добавляем экстремумы (min/max) и предагрегаты (средние) → подтягиваем данные станции и денормализуем только то, что реально нужно.

👉 Читать статью

🧠 Rate Limiting — защита от перегрузки и злоупотреблений

🔹 Rate Limiting — это ограничение количества запросов, которое клиент может сделать за определённый период. Он предотвращает DoS-атаки, brute-force, резкий рост нагрузки и аварийные ситуации.

📌 В Laravel
Laravel имеет встроенную поддержку через middleware throttle, а также гибкий API для кастомных правил:
✔️ ограничение на количество запросов за минуту/час;
✔️ разные лимиты для разных пользователей (по ID, API-ключу или IP);
✔️ кастомные сообщения об ошибке.
Пример стандартного ограничения:

Route::middleware(['throttle:60,1'])->group(function () {
 Route::get('/posts', [PostController::class, 'index']);
});

🧾 Это ограничит пользова­теля до 60 запросов в минуту.
Для более гибкого контроля можно определить лимитер в App\Providers\RouteServiceProvider:

RateLimiter::for('api', function ($request) {
return Limit::perMinute(100)->by($request->user()?->id ?: $request->ip());
});
```

🧾 Такой подход позволяет задавать разные лимиты для аутентифицированных и анонимных пользователей.

📌 В Symfony
Symfony тоже имеет встроенный Rate Limiter с разными алгоритмами (фиксированное окно, sliding window, token bucket). Он может быть применён к маршрутам через сервисы и конфигурацию.

⚠️ Но для защиты от реальных DoS-атак лучше комбинировать приложение с ограничением на уровне веб-сервера или прокси (NGINX, Cloudflare), поскольку встроенный rate limiter требует загрузки Symfony для каждого запроса.

Библиотека пхпшника

Service Tags в Symfony: не про ивенты, а про архитектуру

Service tags в Symfony часто воспринимают как утилиту для Event Listener’ов и Twig-расширений. Это правда — но лишь малая часть картины. На практике tags — один из самых мощных архитектурных инструментов Symfony, если использовать их осознанно.

Статья как раз про это: не «как повесить тег», а как построить расширяемую систему без правок YAML и без условной логики — строго по Open-Closed Principle.

Ключевая идея
Мы собираем модульный Document Processing Pipeline:
PDF, CSV, JSON и любые новые форматы
добавление нового процессора = новый класс, без конфигов
Symfony 7.4, PHP 8.3+, атрибуты вместо YAML

Что здесь действительно важно
1. AutoconfigureTag на интерфейсе
Любая реализация автоматически попадает в систему. Никаких services.yaml.
2. TaggedIterator = современный Strategy
Типизированная коллекция сервисов, с ключами и приоритетами, без Compiler Pass’ов «по старинке».
3. defaultIndexMethod вместо магии
Ключ коллекции определяет сам сервис. Контейнер не знает доменной логики — и это правильно.
4. Кастомные атрибуты поверх тегов
Доменные метаданные (type, priority) живут в атрибуте, а не в конфиге. Код становится декларативным и читаемым.
5. TaggedLocator для ленивой загрузки
Ни один процессор не создаётся, пока он реально не нужен. Это критично для больших систем.
6. Compiler Pass как архитектурный guardrail
Контейнер валидирует систему на этапе сборки:
— дубли типов
— архитектурные инварианты
— ошибки ловятся до runtime
7. Абсолютный уровень декомпозиции
Даже чистые PHP-атрибуты без зависимости от Symfony можно «подключить» через registerAttributeForAutoconfiguration.
Домен остаётся чистым. Инфраструктура — умной.

Почему это ценно
✔️ расширение без модификации
✔️ ноль условной логики
✔️ высокая тестируемость
✔️ архитектурные ошибки ловятся на этапе сборки контейнера

👉 Читать статью

Библиотека пхпшника

В Laravel с версии 10.7 появилась поддержка конвейера для процессов, который легко позволяет связывать вывод одного процесса с входными данными для другого.

Библиотека пхпшника

#vardump