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

🧠 Лайфхак: Активное использование консоли

⚡ Зачем активно использовать консоль

✅ Консоль даёт быстрый доступ к внутренним инструментам фреймворка: генерация кода, миграции, очистка кешей, тестирование, выполнение скриптов — всё через одну команду.

✅ Это экономит время: часто операции, которые вручную занимают несколько минут (создание модели + контроллера + миграции + сидера), превращаются в одну строку.

✅ Понижает рутинную нагрузку и человеческий фактор — меньше шансов допустить ошибку вручную при копи-пейсте, при генерации 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-сервер снизилась и стала прогнозируемой;
исчезла необходимость поддерживать разрозненные агенты;
появилось единое место для анализа, расширения и оптимизации трейсинга;
команда получила прозрачность потоков и быстро нашла проблемы, которые раньше были невидимы.

🔗 Хабр

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

PHP и нейросети? Почему бы и нет!

Мир меняется. Сегодня бэкендер, который может внедрить рекомендательную систему или простой ML-сервис, — на вес золота. Не ограничивайте себя CRUD-задачами.

Завтра запускаем курс
«Математика для разработки AI-моделей».

Всего за 28 200 ₽ вы получите ключи к пониманию того, как работает AI.

Сделайте апгрейд карьеры:

👉 Записаться

Бонус: Пройди тест и удивись

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

Senior PHP Developer — до 5 500 €, Удалёнка (Москва)

Backend-разработчик (PHP) — от 200 000 ₽, Удаленка (Москва)

Full-stack PHP Laravel developer / Web-программист — от 200 000 ₽, Удалёнка (Москва)

PHP разработчик Middle / Senior — Удалёнка (Москва)

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