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

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

PHP разработчик — от 170 000 до 240 000 ₽, Удалёнка (Москва)

Middle+ / Senior Laravel разработчик — от 2200 до 3000 $, Удаленка (Москва)

Веб-программист PHP — 200 000 до 300 000 ₽, Удаленка (Москва)

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

How to: правильно обрабатывать ошибки валидации в Symfony

DTO + #[MapRequestPayload] в Symfony выглядят отлично.
Но ошибки валидации по умолчанию — шумные, разные по формату и неудобные для фронта.
Из-за этого часто появляются:
🔸 try/catch в контроллерах
🔸 дублирующийся маппинг ошибок
🔸 хаос в API-ответах

✅ Правильный подход
Пусть валидация падает сама, а форматирование ошибок происходит глобально, один раз.
Это решает Symfony Validation Response Bundle:
🔹 перехватывает ошибки из #[MapRequestPayload], #[MapQueryString], #[MapUploadedFile];
🔹 возвращает чистый JSON;
🔹 единый формат для всех эндпоинтов;
🔹 без логики в контроллерах.

🚀 Быстрый старт

composer require soleinjast/symfony-validation-response

Без конфигурации. Есть simple, RFC7807 и кастомные форматтеры.

👉 Подробный разбор и примеры — в статье.

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

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

🔍 Can I PHP: проверяем доступность фичи налету

Расширение позволяет проверить доступность определенной функции/метода в различных версиях PHP и получить краткое описание возможностей.

👉 Сайт

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

⚖️ whereHas() vs whereRelation() в Laravel

короче — не значит понятнее

Laravel-разработчики любят шорткаты. Меньше кода, меньше шума — приятно.
Но в реальных проектах с командой и постоянно меняющимися требованиями выигрывает ясность, а не длина строки.

Часто советуют заменить whereHas() на whereRelation():

// было
User::whereHas('profile', function ($q) {
    $q->where('is_verified', false);
})->get();

// стало
User::whereRelation('profile', 'is_verified', false)->get();

Формально — да, код короче.
Практически — не всё так радужно.

🧠 В чём реальная разница
whereHas() — явно про отношения

User::query()
    ->whereHas('profile', fn ($q) => $q->where('is_verified', false))
    ->get();

С первого взгляда понятно:

🔸фильтрация по relation

🔸логика живёт внутри профиля

🔸условия легко расширяются

🔸запрос честно отражает намерение

whereRelation() — скрывает сложность

User::whereRelation('profile', 'is_verified', false)->get();

Читается как фильтр по колонке users.
Но на деле — это подзапрос к связанной таблице.

❗️ Это вводит в заблуждение, особенно при чтении чужого кода.

🧩 Масштабирование условий

С whereHas() — естественно и прозрачно:

->whereHas('profile', fn ($q) => $q
    ->where('is_verified', false)
    ->whereNotNull('phone')
    ->where('age', '>', 18)
)

С whereRelation():

🔸либо цепочка вызовов

🔸либо возврат к whereHas()

🔸либо каша из стилей

🔍 Поиск и поддержка кода

Реальный кейс:

«Эндпоинт тормозит, ищем фильтрацию по отношениям»

whereHas() — легко найти поиском

whereRelation() — прячется среди обычных where

Для поддержки и отладки это критично.

⚙️ Производительность — миф

whereRelation() не быстрее.
Под капотом — тот же whereHas() и почти идентичный SQL.

Если медленно:

🔸нет индексов

🔸не тот подход к запросу

Метод тут ни при чём.

🧱 Проблема консистентности

Что происходит в проектах:

1. Сначала whereRelation() — «быстро и красиво»

2. Потом требования растут

3. Появляется whereHas()

4. В коде — два стиля без причины

5. В ревью — споры

Если сразу использовать whereHas():

🔸один паттерн

🔸единый стиль

🔸код готов к росту

🧠 Внутренности Laravel

Без магии:
whereRelation() — это обёртка над whereHas().
Не умнее. Не быстрее. Просто без closure.

📌 Правило на практике

Можно whereRelation(), если:

🔸один простой фильтр

🔸скрипт, отчёт, админка

🔸логика точно не вырастет

Лучше whereHas(), если:

🔸бизнес-логика

🔸командная разработка

🔸код придётся читать и менять

Экономия пары символов — плохой аргумент.
Пишите код для того, кто откроет файл через полгода.
В реальных проектах честный whereHas() почти всегда выигрывает.

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

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

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

Что будет выведено на экран?

🧵 PHP и многопоточность: куда всё реально движется (TrueAsync)

Статья — не про «давайте добавим async». Она отвечает на более жёсткий вопрос: способен ли PHP вообще эволюционировать к настоящему параллелизму — и какой ценой.
Коротко и без иллюзий 👇

❓ Зачем эта статья
RFC TrueAsync 1.7 упирается в будущее PHP Core. Асинхронность нельзя проектировать в вакууме — нужно понимать:
где у PHP фундаментальные ограничения,
можно ли выйти за рамки корутин,
возможна ли реальная многопоточность без слома экосистемы.

🧪 Эксперимент, который всё прояснил
Попытка обрабатывать CPU-тяжёлую телеметрию через корутины (Swoole):
I/O — отлично
CPU (сжатие, сериализация) — просадка throughput ×2

Вывод жёсткий, но честный:

Корутины не решают CPU-bound задачи.

Решение с выносом вычислений в отдельные процессы оказалось быстрее, несмотря на IPC.

🧠 Базовая модель: Single-threaded + offload
Рабочая архитектура, уже доказавшая эффективность:
Event Loop (1 поток)
I/O, сеть, БД, ожидание
Workers (несколько потоков / процессов)
сжатие, криптография, парсинг, ML
Так работают:
🔸Node.js (Worker Threads)
🔸Python (asyncio + executors)
🔸 PHP (Swoole Request Workers + Task Workers)

✅ Плюсы модели
🔹 тысячи I/O-операций без mutex’ов
🔹 простота reasoning’а (нет гонок)
🔹 минимум требований к компилятору
🔹 контроль над нагрузкой
❌ Минусы
🔻 ручное разделение задач
🔻 легко ошибиться и положить event loop
🔻 плохо подходит для вычислительных систем

🧱 Почему PHP не готов к потокам «из коробки»
Главная проблема — память и GC:
🔸глобальный object_store
🔸refcount + stop-the-world GC
🔸память одного VM нельзя освобождать из другого потока
🔸ZTS ≠ настоящая многопоточность
PHP — строго single-VM модель.

🧠 Ключевая идея: не делить память, а передавать владение
Вместо shared mutable state:
🔸move-семантика объектов
🔸если refcount = 1 → перенос без копии
🔸иначе → deep copy с сохранением идентичности
Это:
🔸безопасно
🔸без сериализации
🔸прозрачно для разработчика

🧵 Что реально нужно в core
🔸многопоточный memory manager
🔸адаптация GC под параллельный режим
🔸поддержка shared immutable объектов (GC_SHARE)
🔸исследование region-based memory

Это не «хотелки», а необходимые условия.

🧩 Корутины + потоки вместе

Поток = Awaitable.

🔸корутина не блокируется
🔸CPU-задача уходит в thread pool
🔸event loop остаётся отзывчивым
Код выглядит последовательно, но работает параллельно.

🎭 Самая сильная абстракция — Actors
Actors дают:
🔸изолированное состояние
🔸последовательную обработку сообщений
🔸отсутствие mutex’ов
естественное OOP-мышление

Каждый actor:
🔸может жить в своём потоке
🔸имеет собственный регион памяти
🔸безопасно масштабируется

Это реальный путь к безопасной многопоточности в PHP.

🔗 Medium

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

💡Совет по Laravel: методы dot и undot

При работе с коллекциями Laravel может возникнуть необходимость преобразовать многомерную коллекцию в одноуровневую или наоборот. К счастью, для этого существуют два метода: dot() и undot() 🚀.

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

#vardump

💻 Первый дайджест новостей в этом году:​

🔹 Laravel 12.44 — в HTTP-клиенте появились колбэки afterResponse(), позволяющие обрабатывать ответ после его получения. Также добавлены ассерты заголовков для TestResponse, новые fluent-методы валидации дат и другие улучшения.

🔹 Laravel News: итоги 2025 — редакция подвела итоги года, отметив ключевые события экосистемы: релиз Laravel 12, запуск Laravel Cloud, крупные обновления инструментов и рост сообщества.

🔹 Symfony: итоги 2025 года — команда Symfony рассказала о главных достижениях проекта за год, поблагодарив сообщество за вклад в развитие фреймворка.

🔹 Symfony 29 декабря 2025 — 4 января 2026 — выпущены maintenance-версии Symfony 6.4.31, 7.3.9, 7.4.3 и 8.0.3, а также опубликован официальный годовой обзор Symfony за 2025 год.

🔹 Symfony UX 2.32.0 — представлен новый Toolkit Package с настраиваемыми UI-компонентами (на базе Shadcn UI): Button, Dialog, Card, Table, Pagination и другие.

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

#свежак

🚀 PHP 8.6: Partial Function Application (PFA)

Меньше шаблонного кода. Больше смысла в колбэках.

В PHP 8.6 появляется Partial Function Application — механизм, который позволяет частично вызывать функцию, фиксируя одни аргументы и оставляя «дырки» для остальных. В результате возвращается готовый Closure с автоматически выведенной сигнатурой.

🧠 Что это даёт на практике

• 📉 Меньше стрелочных функций ради передачи одного аргумента
• 🧩 Колбэки становятся короче и читаемее
• 🔎 Намерение кода видно сразу, без «обвязки»
• 🔗 Отлично сочетается с pipe-оператором
• 🧪 Упрощает функциональный стиль и композицию

🧱 Ключевая идея

Используются плейсхолдеры:

? — ровно один аргумент

… — все оставшиеся аргументы

PHP не вызывает функцию, а возвращает преднастроенный callable.

⚙️ Где особенно полезно

• array_map, array_filter, usort
• Преднастроенные валидаторы и фильтры
• HTTP-middleware и пайплайны
• Thunk-функции (отложенное выполнение)
• Конфигурация через именованные аргументы

🧩 Реальный сценарий

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

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

• Конструкторы нельзя частично применять
• Для new — только фабрики или статические методы
• Variadic-аргументы можно как «оставить открытыми», так и зафиксировать

Partial Function Application — это не синтаксический сахар, а структурное упрощение колбэков. PHP продолжает двигаться в сторону выразительного и функционального кода, снижая шум и повышая читаемость.

🔗 Читать статью

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

🚀 Тюнинг производительности PHP-FPM

Правильная настройка PHP-FPM имеет решающее значение для эффективного использования ресурсов сервера. Вот несколько ключевых параметров для оптимизации производительности:

🔧 Основные параметры:
pm = dynamic
Управляет количеством рабочих процессов. В режиме dynamic количество процессов изменяется в зависимости от нагрузки сервера.
pm.max_children = 1000
Максимальное количество рабочих процессов. Высокие значения могут привести к ошибкам из-за нехватки памяти. Пример: для 1000 процессов × 100MB/процесс потребуется 100GB RAM.
pm.start_servers = 80
Количество процессов, которое будет запущено при старте PHP-FPM для быстрой обработки начальной нагрузки.
pm.min_spare_servers = 40
Минимальное количество «запасных» процессов, которые должны оставаться в ожидании.
pm.max_spare_servers = 120
Максимальное количество неактивных процессов. Если их больше, лишние процессы будут завершаться.
request_terminate_timeout = 300s
Ограничение времени для запроса — если выполнение длится более 5 минут, процесс будет завершен.
request_slowlog_timeout = 5s
Все запросы, которые выполняются более 5 секунд, записываются в лог для анализа производительности.

📊 Рекомендации:
Для серверов с меньшим объёмом памяти, например 8GB RAM, настройте:

pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20

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

👉 Поделитесь этим постом с коллегами!

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

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

#лучшее2025

Запуск PHP 1.0

Как выглядел код 30 лет назад?

💻 Смотреть видео

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

#лучшее2025

PHP и AI-агенты: сделайте ваш бэкенд умнее в 2026-м

Кто сказал, что PHP не для ИИ? В новом году мы учим пхпшников встраивать автономных агентов в Laravel и Symfony проекты. Пусть боты разгребают почту, модерируют контент и пишут API-документацию за вас.

На курсе вы узнаете:

— как работают ReAct-агенты;
— как связать n8n с вашим PHP-кодом;
— как использовать протокол MCP для командной работы ботов.

🎄 Успейте до 12 января забрать курс по акции «3 в 1». Это ваш билет в мир современного IT.

Ускорить разработку

🔧 Нужен ли static в замыкании? Да — и вот почему

На первый взгляд, совет заменить обычную анонимную функцию на static в array_map может показаться чисто стилевым. Но за этой рекомендацией скрывается реальный прирост производительности. ⚡

📌 Что происходит:
– static-замыкания не привязаны к $this, а значит, не тащат за собой контекст объекта
– Это позволяет PHP быстрее освобождать память
– И в ряде случаев — существенно ускоряет выполнение кода

💡 Один из PR'ов в Ocramius/GeneratedHydrator показал: просто добавив static, удалось добиться ~15% ускорения. А бенчмарки дали ещё более радикальную разницу:

benchUsingStaticKeyword → 2.10MB / 3.70ms
benchNotUsingStaticKeyword → 71.30MB / 17.17ms

📉 Минус 30x по памяти, минус 4x по времени.
Чтобы внедрить это на постоянной основе, удобно использовать Rector с правилами StaticClosureRector и StaticArrowFunctionRector. Так все замыкания, где не используется $this, становятся static автоматически. 🛠️

✅ Быстрее
✅ Меньше памяти
✅ Автоматическая проверка в CI

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

#лучшее2025

💬В Laravel есть хелпер Number для простого и удобного форматирования цифровых значений.

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

#лучшее2025

📊 FastExcelWriter: Лёгкое и быстрое создание Excel-файлов на PHP

Если вы сталкивались с генерацией больших Excel-файлов на PHP, вы, вероятно, знакомы с PhpSpreadsheet. Хотя она функциональна, при работе с большими данными возможны проблемы с производительностью и потреблением памяти.

👨‍💻 FastExcelWriter — альтернатива PhpSpreadsheet с упором на скорость и экономию ресурсов. Вместо хранения данных в памяти, библиотека пишет строки напрямую в файл, снижая нагрузку на систему.

🔧 Преимущества FastExcelWriter:

🚀 Генерация файлов в 7–9 раз быстрее PhpSpreadsheet
💾 Минимальное потребление памяти благодаря построчной записи
🎨 Поддержка стилей, форматирования, изображений, диаграмм и примечаний
🧩 Простой и лаконичный API для разработчиков

👉 Хабр

#лучшее2025

🚀 Как ускорить массовую отправку HTTP-запросов в PHP

🔍 Постановка задачи:
Есть скрипт на PHP, который должен отправлять множество HTTP-запросов. Нужно сделать это как можно быстрее. Очевидное решение — параллельная отправка.

🔧 Шаг 1: последовательная обработка
Простой цикл с curl_init() и curl_exec() на каждый URL. Результат: 10 запросов выполняются за ~4.4 секунды.

⚙️ Шаг 2: повторное использование curl-хэндла
Инициализируем curl один раз и переиспользуем. Время выполнения снижается до ~1.7 секунды.

⚡ Шаг 3: параллельная отправка с curl_multi_
Используем curl_multi_init() и запускаем запросы одновременно. Итог: всего 0.5 секунды на 10 запросов. Почти в 9 раз быстрее, чем изначально.

📦 Шаг 4: отправка батчами (batching)
Если запросов сотни или тысячи, одновременно всё не потянет даже мощный сервер. Решение — отправка пакетами, например по 3. Это позволяет контролировать нагрузку. В нашем примере — ~0.8 секунды на 10 запросов.

🔗 Читать статью

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

#лучшее2025

🧠 Ковариантность и контравариантность в PHP — кратко и по сути

Эти термины звучат сложно, но суть у них простая. Разработчики используют их идеи постоянно — просто не всегда знают, как это называется. Ниже — простое объяснение с примерами.

🔍 Что это такое?

Ковариантность — когда метод возвращает более конкретный тип, чем у родителя.

Контравариантность — когда метод принимает менее конкретный тип, чем у родителя.

✅ Ковариантность (return types)
PHP поддерживает ковариантность только для возвращаемых значений. Примеры:

float|int → int

BaseClass → ChildClass

Exportable → Exportable&Cacheable

Можно «сузить» возвращаемый тип в дочернем классе — и это будет валидно.

❌ Контравариантность в return'ах
PHP не позволяет делать возвращаемый тип менее конкретным.
Например, int → float|int — вызовет ошибку.

✅ Контравариантность (параметры)
А вот с параметрами всё наоборот — здесь PHP позволяет делать типы шире:

array → array|Collection

Traversable&Collection → Collection

EloquentCollection → Collection

Такой подход делает методы более гибкими при переопределении.

❌ Ковариантность в параметрах
Нельзя в параметрах делать тип более конкретным, чем у родителя. Это приведёт к ошибке.

🚫 Конструкторы — отдельная история
Ковариантность и контравариантность на конструкторы не влияют. У них своя логика, и они не наследуются как обычные методы.

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

#лучшее2025