Библиотека пхпшника | PHP, Laravel, Symfony, CodeIgniter
Все самое полезное для пхпшника в одном канале. По рекламе: @tproger_sales_bot Учиться у нас: clc.to/M561SQ Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/67a5d13cd6fa92100ee6f68b
Ko'proq ko'rsatish📈 Telegram kanali Библиотека пхпшника | PHP, Laravel, Symfony, CodeIgniter analitikasi
Библиотека пхпшника | PHP, Laravel, Symfony, CodeIgniter (@phpproglib) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 461 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 11 704-o'rinni va Rossiya mintaqasida 60 791-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 461 obunachiga ega bo‘ldi.
28 Oktabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni -29 ga, so‘nggi 24 soatda esa 4 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 17.02% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 7.68% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 1 781 marta ko‘riladi; birinchi sutkada odatda 804 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 1 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent php, laravel, пхпшника, artisan, api kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Все самое полезное для пхпшника в одном канале.
По рекламе: @tproger_sales_bot
Учиться у нас: clc.to/M561SQ
Для обратной связи: @proglibrary_feeedback_bot
РКН: https://gosuslugi.ru/snet/67a5d13cd6fa92100ee6f68b”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 29 Oktabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
#[MapRequestPayload] в Symfony выглядят отлично.
Но ошибки валидации по умолчанию — шумные, разные по формату и неудобные для фронта.
Из-за этого часто появляются:
🔸 try/catch в контроллерах
🔸 дублирующийся маппинг ошибок
🔸 хаос в API-ответах
✅ Правильный подход
Пусть валидация падает сама, а форматирование ошибок происходит глобально, один раз.
Это решает Symfony Validation Response Bundle:
🔹 перехватывает ошибки из #[MapRequestPayload], #[MapQueryString], #[MapUploadedFile];
🔹 возвращает чистый JSON;
🔹 единый формат для всех эндпоинтов;
🔹 без логики в контроллерах.
🚀 Быстрый старт
composer require soleinjast/symfony-validation-response
Без конфигурации. Есть simple, RFC7807 и кастомные форматтеры.
👉 Подробный разбор и примеры — в статье.
Библиотека пхпшника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() почти всегда выигрывает.
👉 Ссылка на статью
Библиотека пхпшника
#элементарный_выборКорутины не решают 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
Библиотека пхпшникаdot и undot
При работе с коллекциями Laravel может возникнуть необходимость преобразовать многомерную коллекцию в одноуровневую или наоборот. К счастью, для этого существуют два метода: dot() и undot() 🚀.
Библиотека пхпшника
#vardumpafterResponse(), позволяющие обрабатывать ответ после его получения. Также добавлены ассерты заголовков для 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 и другие.
Библиотека пхпшника
#свежакClosure с автоматически выведенной сигнатурой.
🧠 Что это даёт на практике
• 📉 Меньше стрелочных функций ради передачи одного аргумента
• 🧩 Колбэки становятся короче и читаемее
• 🔎 Намерение кода видно сразу, без «обвязки»
• 🔗 Отлично сочетается с pipe-оператором
• 🧪 Упрощает функциональный стиль и композицию
🧱 Ключевая идея
Используются плейсхолдеры:
? — ровно один аргумент
… — все оставшиеся аргументы
PHP не вызывает функцию, а возвращает преднастроенный callable.
⚙️ Где особенно полезно
• array_map, array_filter, usort
• Преднастроенные валидаторы и фильтры
• HTTP-middleware и пайплайны
• Thunk-функции (отложенное выполнение)
• Конфигурация через именованные аргументы
🧩 Реальный сценарий
Преднастроенные операции — например, добавление заголовков, логирование, фильтрация данных — можно оформить один раз и переиспользовать без дублирования логики.
⚠️ Ограничения
• Конструкторы нельзя частично применять
• Для new — только фабрики или статические методы
• Variadic-аргументы можно как «оставить открытыми», так и зафиксировать
Partial Function Application — это не синтаксический сахар, а структурное упрощение колбэков. PHP продолжает двигаться в сторону выразительного и функционального кода, снижая шум и повышая читаемость.
🔗 Читать статью
Библиотека пхпшника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
Эти настройки обеспечат баланс между производительностью и безопасностью, сохраняя ресурсы для других служб.
👉 Поделитесь этим постом с коллегами!
🔗 Ссылка на статью
Библиотека пхпшника
#лучшее2025Laravel и 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
👉 Читать статью
#лучшее2025curl_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 запросов.
🔗 Читать статью
Библиотека пхпшника
#лучшее2025float|int → int
BaseClass → ChildClass
Exportable → Exportable&Cacheable
Можно «сузить» возвращаемый тип в дочернем классе — и это будет валидно.
❌ Контравариантность в return'ах
PHP не позволяет делать возвращаемый тип менее конкретным.
Например, int → float|int — вызовет ошибку.
✅ Контравариантность (параметры)
А вот с параметрами всё наоборот — здесь PHP позволяет делать типы шире:
array → array|Collection
Traversable&Collection → Collection
EloquentCollection → Collection
Такой подход делает методы более гибкими при переопределении.
❌ Ковариантность в параметрах
Нельзя в параметрах делать тип более конкретным, чем у родителя. Это приведёт к ошибке.
🚫 Конструкторы — отдельная история
Ковариантность и контравариантность на конструкторы не влияют. У них своя логика, и они не наследуются как обычные методы.
👉 Читать статью
#лучшее2025