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

👨‍💻 Где читаете про новые фичи и лучшие практики Официальные доки — это хорошо. Но давайте честно: половину знаний мы получаем из случайных статей, чьих-то каналов и обсуждений в комментариях. Интересно узнать: 📌 Какие телеграм-каналы или блоги вы читаете регулярно? 📌 Есть ли YouTube-каналы, которые реально помогли разобраться в сложных темах? 📌 В каких комьюнити задаёте вопросы, когда застряли? 📌 Кто из авторов объясняет так, что всё сразу становится понятно? 🎈 Может быть, вы сами ведёте блог или делитесь опытом — расскажите об этом тоже, пришло ваше время! Соберём список реально полезных мест для разработчиков. Пишите в комментариях ⬇️ 🐸 Библиотека пхпшника

🐘 PHP для начинающих: Маршрутизация в Laravel В Laravel маршруты — это каркас вашего приложения. Web-маршруты живут в routes/web.php, API — в routes/api.php, а каналы трансляций — в routes/channels.php (появляются после install:api или install:broadcast). Если говорить практично, ключевые вещи, которые должен помнить каждый разработчик: • Базовые маршруты легко описывать замыканиями — удобно для простых страниц. • Вербы маршрутов (get, post, put, delete, match, any) позволяют тонко управлять поведением приложения. • Контроллеры лучше использовать, когда логика разрастается — код становится чище и масштабируемее. • Параметры маршрутов могут быть обязательными, опциональными и ограниченными по regex. • Именованные маршруты дают стабильные ссылки и избавляют от жёстких URL в шаблонах. Кому важна архитектурная чистота, удобная навигация и качественная API-структура — разбор в статье ниже будет особенно полезен. 👉 Подробнее в статье — разбор всех примеров и нюансов маршрутизации Laravel. Библиотека пхпшника

🧠 Лайфхак: Активное использование консоли ⚡ Зачем активно использовать консоль ✅ Консоль даёт быстрый доступ к внутренним инструментам фреймворка: генерация кода, миграции, очистка кешей, тестирование, выполнение скриптов — всё через одну команду. ✅ Это экономит время: часто операции, которые вручную занимают несколько минут (создание модели + контроллера + миграции + сидера), превращаются в одну строку. ✅ Понижает рутинную нагрузку и человеческий фактор — меньше шансов допустить ошибку вручную при копи-пейсте, при генерации boilerplate-кода, при очистке кеша и т.п. ✅ Консоль позволяет быстро экспериментировать — запускать куски кода, тестировать модели, делать запросы к БД, без необходимости писать контроллеры или временные скрипты. 🔧 Что даёт консоль во Laravel & Symfony 🛠️ Основные возможности Artisan (в Laravel) — набор встроенных CLI-команд для генерации моделей, контроллеров, миграций, фабрик, сидеров и др Tinker — интерактивная REPL-консоль, позволяющая напрямую взаимодействовать с приложением: работать с моделями, делать запросы, проверять логику, не создавая маршруты/контроллеры. Возможность создавать свои консольные команды — для автоматизации задач, которые повторяются: очистка кешей, рассылки, миграции, бэкапы, отчёты и др. Планировщик задач (scheduler) — можно запускать команды по расписанию, автоматизируя фоновые процессы. 🧠 Примеры, как консоль ускоряет вашу работу ➤ Быстрая генерация структуры Вместо ручного создания файла модели, миграции, контроллера, фабрики — просто: php artisan make:model Post -mfc (модель + миграция + фабрика + контроллер) — буквально за секунды. ➤ Эксперименты «на лету» Открыл консоль через php artisan tinker, написал пару строк: запросил модель, проверил данные, протестировал логику — без лишнего кода, без запуска браузера. ➤ Автоматизация рутинных задач Например, можно сделать команду для очистки кешей, логов, старых данных — и запускать её вручную или по расписанию, без лишних усилий. ➤ Быстрый деплой / обслуживание Через CLI можно прогнать миграции, сброс кешей, подготовить окружение, выполнить задачи перед деплоем — удобно и надёжно. ✅ Когда и как лучше использовать 🔸 Используйте консоль, когда делаете рутинные или повторяющиеся действия: генерация кода, миграции, очистка кешей, сидинг, бэкапы. 🔸 В момент разработки — для быстрых тестов, прототипирования, проверки моделей, структур данных. 🔸 В продакшн/CI/CD — для автоматизации задач, миграций, задач обслуживания. 🔸 Создавайте собственные console-команды для специфичных задач: отчётов, задач очистки, миграций, операций над БД, фоновых job-ов. Библиотека пхпшника

🐇 Publish без подтверждений в RabbitMQ: почему так работает и что с этим делать Сегодня разберём один практический кейс. Тема старая, но до сих пор вызывающая недопонимание: почему basic.publish в RabbitMQ по умолчанию не гарантирует доставку сообщения, и как правильно работать с подтверждениями. 🔸 Почему basic.publish не надёжен из коробки Метод basic.publish в AMQP 0-9-1 не имеет возвратной части. То есть он работает в режиме fire-and-forget — семантика at most once. RabbitMQ базируется именно на AMQP 0-9-1 (AMQP 1.0 добавлен с версии 4.0, но это в основном надстройки, а не новое поведение). 📌 В отличие от других методов AMQP, у basic.publish нет пары some-method-ok. Это значит, что отправитель не знает, дошло ли сообщение до брокера. И да — в 99.999% случаев всё будет хорошо. Но если вам нужна гарантированная доставка, на одном только basic.publish далеко не уедешь. 🔸 Зачем так сделано AMQP создавали в JPMorgan — под задачи финансового сектора. Там есть сценарии, где огромные потоки данных (например, котировки с частотой 10k+ событий/сек) допускают потерю части сообщений. Для таких задач fire-and-forget — нормальное поведение. Для строгой гарантированной доставки в спецификации AMQP предусмотрены транзакции.

В AMQP 2.2.3 прямо сказано: «Success is silent, and failure is noisy. When applications need explicit tracking of success and failure, they should use transactions.»

Но: 🟢 транзакции в RabbitMQ замедляют publish до 250 раз (по данным официальной документации), 🟢 в RabbitMQ транзакции — лишь «простая форма батчинга», без ACID, 🟢 под каждый publish транзакцию заводить бессмысленно. Итог: транзакции — рудимент, использовать их в RMQ почти никогда не стоит. 🔸 Как это исправили в RabbitMQ Команда RabbitMQ расширила протокол AMQP и добавила механизм Publisher Confirms — подтверждения на уровне basic.publish. Это не часть стандарта AMQP, а собственное расширение RabbitMQ. Но именно оно стало де-факто стандартом для гарантированной доставки сообщений. 🔸 Как работает Publisher Confirms Канал переводится в режим подтверждений методом: $channel->confirm_select(); После этого RabbitMQ: считает каждое опубликованное сообщение, отправляет ack или nack после обработки, гарантирует, что отправитель узнает результат. Главное — вызывать: $channel->wait_for_pending_acks(); Он блокирует выполнение, пока брокер не даст ответы по всем сообщениям. 🔗 Хабр Библиотека пхпшника

🔥 How to: Упростить сложные запросы в репозитории с помощью Specification Pattern Когда метод репозитория разрастается до сотен строк с подзапросами, условными блоками и повторяющимися правилами, поддержка кода становится дорогой и рискованной. Частые ошибки, сложность тестирования и высокий порог входа — типичные последствия. Specification Pattern позволяет разложить такую логику на небольшие независимые компоненты. Каждый класс отвечает за одно правило фильтрации, а общий запрос строится путем композиции этих правил. Архитектура становится чище, поведение — прозрачнее, тестирование — проще. Что даёт подход: 🔸 разбиение огромных методов на компактные блоки; 🔸 минимизацию дублирования логики; 🔸 предсказуемость и лёгкую расширяемость; 🔸 существенное снижение сложности и рост покрытия тестами. 👉 Читать статью Библиотека пхпшника

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

Opis/closure Это библиотека для PHP, которая даёт возможность сериализовать (преобразовать в строку/байты) замыкания (closures / анонимные функции), а также анонимные классы и произвольные данные. По умолчанию PHP не поддерживает сериализацию замыканий: попытка вызвать serialize() на Closure приводит к ошибке. Opis/closure обходит это ограничение, обёртывая замыкание — и благодаря этому Вы можете сериализовать, передавать, хранить, а потом восстанавливать функцию и её контекст. ✅ Основные возможности 🔸 Поддержка PHP 8.0+ (включая 8.5) — современный синтаксис, типы, readonly-свойства, атрибуты и пр. 🔸 Сериализация замыканий, анонимных классов, сложных объектов, включая структуры с круговыми ссылками. 🔸 Возможность «безопасного» сериализования: есть поддержка подписанных (signed) данных. 🔸 Не требуется каких-либо расширений PHP (например, FFI) — всё реализовано «на чистом PHP». 🔸 Универсальность: не просто для замыканий — можно сериализовать «любой сложный объект», что даёт гибкость. 📦 Где это используется — и зачем Вам может пригодиться Фреймворки и библиотеки, которым нужно отложенно сохранять/восстанавливать функции — например, очередь задач, jobs, callback-хранение. Если хотите передавать анонимные функции между процессами, сохранять их в БД, передавать через очереди — без описания «класса + метод». При необходимости сериализовать объекты с нестандартным состоянием, содержащие функции или анонимные классы. Для систем, где нужно «сохранить и восстановить» произвольное состояние (функции, контекст, данные), несмотря на ограничение PHP на сериализацию замыканий. ⚠️ Что важно учитывать 🔹 Библиотека поддерживает PHP 8.0+; если проект на более старой версии — могут быть ограничения. 🔹 Бывают нюансы с «безопасностью»: если используются подписанные сериализованные данные и разные ключи — при десериализации может быть ошибка. 🔹 Как и с любой подобной техникой — злоумелое использование (например, unserialize от данных из ненадёжного источника) — может быть рискованным. 🔗 Github Библиотека пхпшника

PostgreSQL vs MongoDB — что выбрать? В разработке часто сталкиваешься с вопросом: какую СУБД выбрать — реляционную или документо-ориентированную? Но правильный вопрос не «какая база лучше», а «какая подходит под ваши задачи». Обе технологии заслужили доверие и популярность — просто они решают разные задачи. 🔎 Основные отличия 🛡️ PostgreSQL — реляционная СУБД с таблицами, строгими схемами и SQL, хорошо подходит для надёжных, структурированных моделей. 🌐 MongoDB — документно-ориентированная NoSQL-СУБД, хранит данные как JSON-/BSON-документы без жёсткой схемы — больше гибкости для меняющихся, динамических данных. PostgreSQL обеспечивает ACID-транзакции, целостность, сложные связи и надёжность. MongoDB даёт гибкость, масштабируемость и простоту схемы, особенно когда структура данных может изменяться. ✅ Когда PostgreSQL — ваш выбор 🟦 Структурированные данные, чёткие связи между сущностями. 🟦 Необходимы транзакции, консистентность, строгие ограничения (финансы, учёт, бухгалтерия, критичные операции). 🟦 Сложные запросы, отчёты, JOIN-ы, аналитика, отчётность. 🟦 Долгосрочное хранение, стабильность, предсказуемость схемы и данных. ✅ Когда MongoDB — лучший вариант 🟩 Данные меняются часто; структура может эволюционировать, добавляются новые поля, типы записей. 🟩 Необходима гибкость: документы, JSON-объекты, агрегации, неструктурированные или полуструктурированные данные. 🟩 Требуется горизонтальное масштабирование, распределённое хранилище, высокая нагрузка на запись/чтение. 🟩 Быстрая разработка, прототипы, MVP, где хочется избежать долгих миграций схем. 👉 Полная статья с примерами и различными сценариями Библиотека пхпшника

Что выведет код?

📈 Почему память в PHP-воркерах только растёт — и это нормально Если вы переходите с PHP-FPM на RoadRunner, Laravel Queue или Symfony Messenger — вы увидите один и тот же эффект: Память растёт ступеньками и никогда не падает. 40 → 200 → 350 МБ… и так до перезапуска. Unset, GC, collect_cycles() — не помогают. Это не утечка. Это архитектура PHP. 🧬 Почему так происходит PHP использует Zend Memory Manager: он выделяет память крупными чанками (2–4 МБ) и не отдаёт их ОС назад, даже если внутри всё освобождено. Каждый пик — новый baseline. Обработали 100k записей → память выросла → процесс будет держать этот объём до конца жизни. 🔥 Что вызывает «разбухание» ORM ->all() или ->get() на десятки тысяч записей большой файл в file_get_contents() накопление массивов сложные eager-loading графы ORM 🛠 Как проектировать правильно ✔️ Стриминг вместо коллекций:

User::lazy()->each(fn($u) => processUser($u));

или:

Record::chunk(100, function ($rows) {
    foreach ($rows as $r) processRecord($r);
});

✔️ Doctrine:

foreach ($q->toIterable() as $u) {
    process($u);
    $em->detach($u);
}

✔️ Изоляция тяжёлых операций в функцию — память освобождается при выходе из scope. ✔️ Ротация воркеров — обязательна: Laravel:

php artisan queue:work --max-jobs=1000

RoadRunner:

pool:
  max_jobs: 1000

Messenger:

messenger:consume --limit=1000

📌 Выводы 🔸 Память в долгоживущем PHP-процессе не уменьшится сама по себе. 🔸 Проектируйте под пиковое потребление. 🔸Используйте стриминг, чанки, detach(). 🔸 Регулярно перезапускайте воркеры. 🔗 Medium 🐸 Библиотека пхпшника

💡Совет по Laravel: Привязка моделей в Form Request Привязка моделей к маршрутам позволяет вставлять экземпляры моделей непосредственно в маршруты. Обычно она используется в контроллере, но знаете ли вы, что можно получить доступ к экземпляру модели и в запросе формы? Библиотека пхпшника #vardump

💻 Подборка новостей по PHP за неделю:​ 🔹 Laravel 12.40.2 — очередь теперь можно приостанавливать на заданное число секунд. Это развитие функции из 12.40, где появилась возможность ставить очередь на паузу и возобновлять её без ограничения по времени. 🔹 Mailviews (Early Access) — запущен ранний доступ к инструменту для создания адаптивных, стабильных e-mail-шаблонов без мучительной ручной верстки и бесконечных проверок в разных клиентах. 🔹 Symfony 7.4.0 — релиз новой стабильной версии с заметными улучшениями. В серии «New in Symfony 7.4» доступны разборы ключевых возможностей. 🔹 Symfony 24–30 ноября — выпущены финальные Symfony 7.4.0 и 8.0.0. Прошла SymfonyCon Amsterdam 2025, опубликованы Black Friday-скидки экосистемы. Библиотека пхпшника #свежак

💬 Ежемесячная ветка PHP-разработчиков — декабрьское обновление Продолжаем традицию — открываем новую декабрьскую ветку 👇 Что можно приносить сюда сейчас: 🧩 свежие фрагменты кода, которые вызывают вопросы или гордость 🔍 кейсы из продакшена: узкие места, memory leaks, странности с очередями 🛠️ pet-projects, библиотеки, пакеты: покажите, что сделали за месяц 🧠 вопросы по DDD, микросервисам, тестированию, CI/CD ⚙️ опыт миграции на PHP 8.3/8.4, проблемы совместимости, нюансы производительности Вы можете прийти с сырым прототипом или сложной продакшен-архитектурой — здесь всегда найдётся человек, который подскажет, куда копать. Пусть эта ветка остаётся местом для профессионального диалога, где ценят практику, инженерное мышление и точные решения ❤️ 👇 Делитесь вашими обновлениями, задачами и победами за последний месяц! Библиотека пхпшника

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

PHP жив, а твоя карьера? Шутка. PHP будет жить вечно. Но расширять кругозор полезно всегда. Математика и ML — это то, что отличает инженера от кодера. Залетай на наш курс с живыми вебинарами. Мы объясняем сложные вещи просто. Что будет: — Матрицы и векторы (это как массивы, только с суперсилой); — Линейная регрессия (научимся предсказывать данные); — SVD-разложение (сделаем свою рекомендалку). Практика на Python, но математика везде одинаковая. Успевай до 9 декабря: 👉 https://clc.to/LojFzw

💬Знаете ли вы, что вы можете использовать scan в Laravel для разбора строки, введенной в коллекцию, в соответствии с форматом, поддерживаемым встроенной функцией PHP sscanf? 🚀 Библиотека пхпшника #vardump

🤖 ChatGPT выключен, а работа идёт как обычно В мире разработки всё чаще говорят про AI, который помогает писать код быстрее и качественнее. Однако, встречаются примеры, когда выключение Copilot не приводит к заметным потерям в работе. Возможно, скиллы и понимание задач дают больше, чем автодополнение от AI. 💬 Как думаете не отвлекают ли эти ИИ? Или всё-таки с ними куда лучше? 🔸 AI-агенты для DS-специалистов 🔸 Получить консультацию менеджера 🔸 Сайт Академии 🔸 Сайт Proglib 🐸 Библиотека пхпшника

🧠 Лайфхак: кешируйте config и routes в Laravel для максимальной скорости ⚙️ Что даёт кеширование 🔄 При кешировании конфигурации — все файлы из config/ (и .env) объединяются в один — Laravel не читает и не парсит множество отдельных файлов при каждом запросе. 🚀 При кешировании маршрутов — все определения роутов компилируются в один файл. При запросе Laravel сразу загружает этот кеш, вместо повторного парсинга маршрутов. Это значительно снижает накладные расходы на загрузку конфигураций и роутов, ускоряя старт приложения и уменьшая время обработки запросов. 🧰 Как включить кеш

php artisan config:cache #кеширует конфигурацию

php artisan route:cache #кеширует маршруты

Если вы внесли изменения в конфиги или роуты — перед новым запуском надо очистить и пересоздать кеш:

php artisan config:clear
php artisan route:clear

И потом снова:

php artisan config:cache
php artisan route:cache

✅ Когда это разумно использовать - ✅ В production или staging-средах, когда структура проекта стабильна, конфиги и маршруты уже настроены. - ✅ В проектах с большим количеством конфигураций и маршрутов — там выигрыш по скорости особенно заметен. ⚠️ На что нужно обратить внимание - ❗ Если вы используете closure-роуты (анонимные функции) — кеш маршрутов не будет работать корректно. Для кеша маршрутов нужно, чтобы все роуты были описаны через контроллеры. - ❗ После изменений в конфигурациях или .env — не забудьте пересоздать кеш: иначе Laravel может продолжить использовать старые значения. - ⚙️ В рабочем (dev) окружении: кеш может мешать быстрому тестированию изменений, поэтому часто кеш отключают на время разработки. 🔄 Как включить кеширование в процесс деплоя / CI/CD - Добавьте команды config:cache и route:cache в скрипт деплоя — при выкладке на production они будут выполняться автоматически. - После деплоя — проверьте, что кеш актуален, особенно если были изменения конфигов или роутов Библиотека пхпшника

Сбор и отправка APM-трейсов из разных сервисов В больших продуктах архитектура редко бывает однородной. У Sports.ru за 25+ лет под капотом оказались десятки Go-микросервисов рядом с крупными Perl- и PHP-монолитами. Всё это нужно мониторить, искать узкие места, собирать метрики — и делать это стабильно. Официальных APM-агентов хватает не для всех языков, а существующие для PHP/Perl оказались слишком ограниченными. Поэтому команда решила построить собственный APM-прокси — единый сервис для сбора, буферизации и отправки трейсов. Разбираем, зачем он понадобился и как устроен. 🧩 Проблема: разные агенты → разные ограничения Elastic APM даёт мощный трейсинг, но: Go-агент умеет батчить события в фоне — очередь, буфер, воркеры. PHP-агент живёт только в рамках запроса. Один запрос = одна отправка → тысячи мелких HTTP-пакетов → нагрузка на APM-сервер. Perl-агента нет вообще — монолит остаётся слепым. В PHP и Perl невозможно получить внутренние метрики агента: переполнение очередей, потерянные события, время отправки. Поддерживать кастомные агенты под каждый язык стало дорого и непрозрачно. Требовался единый, прогнозируемый механизм. 🚀 Решение: APM-прокси как универсальная точка сбора Команда спроектировала отдельный сервис apm-sender на Go: принимает NDJSON-пейлоады от любых клиентов (монолиты/микросервисы); валидирует и складывает их в канал; отвечает клиенту сразу — без ожидания обработки; в фоне батчит и отправляет данные в APM-сервер. Это дало главное: клиентские сервисы больше не занимаются отправкой, очередями и оптимизацией трафика — логика вынесена в один компонент. ⚙️ Что внутри: каналы, воркеры и Circuit Breaker 1) Два уровня воркеров Первый канал всегда доступен для записи — нагрузка клиентов не блокируется. Второй канал — накопитель, откуда воркеры отправляют данные в APM. 2) Circuit Breaker Когда APM-сервер начинает тормозить или отвечает ошибками: отправка автоматически блокируется на несколько секунд; сообщения копятся в буфере; сервер «прощупывается» периодически; когда он оклемался — отправка возобновляется. Так прокси не штурмует APM-сервер лишними запросами и не теряет трейсы. 📊 Метрики и контроль APM-прокси собирает то, чего не умели агенты Perl/PHP: 🔸 размер буфера; 🔸 время блокировок; 🔸 объём входящего/исходящего трафика; 🔸 статистику ошибок APM-сервера; 🔸 нагрузку в разрезе клиентов. Это позволило: найти клиентов, отправлявших гигантские payload’ы с лишними спанами; оптимально настроить воркеры и размеры буферов; корректно сконфигурировать сам APM-сервер. 🏁 Результат После переключения монолитов и сервисов на APM-прокси: отправка трейсов стала стабильной и управляемой; нагрузка на APM-сервер снизилась и стала прогнозируемой; исчезла необходимость поддерживать разрозненные агенты; появилось единое место для анализа, расширения и оптимизации трейсинга; команда получила прозрачность потоков и быстро нашла проблемы, которые раньше были невидимы. 🔗 Хабр Библиотека пхпшника