PHP жив, а твоя карьера?
Шутка. PHP будет жить вечно. Но расширять кругозор полезно всегда. Математика и ML — это то, что отличает инженера от кодера.
Залетай на наш курс с живыми вебинарами. Мы объясняем сложные вещи просто.
Что будет:
— Матрицы и векторы (это как массивы, только с суперсилой);
— Линейная регрессия (научимся предсказывать данные);
— SVD-разложение (сделаем свою рекомендалку).
Практика на Python, но математика везде одинаковая.
Успевай до 9 декабря:
👉 https://clc.to/LojFzw
Шутка. PHP будет жить вечно. Но расширять кругозор полезно всегда. Математика и ML — это то, что отличает инженера от кодера.
Залетай на наш курс с живыми вебинарами. Мы объясняем сложные вещи просто.
Что будет:
— Матрицы и векторы (это как массивы, только с суперсилой);
— Линейная регрессия (научимся предсказывать данные);
— SVD-разложение (сделаем свою рекомендалку).
Практика на Python, но математика везде одинаковая.
Успевай до 9 декабря:
👉 https://clc.to/LojFzw
🥱5👍1
💬 Ежемесячная ветка PHP-разработчиков — декабрьское обновление
Продолжаем традицию — открываем новую декабрьскую ветку 👇
Что можно приносить сюда сейчас:
🧩 свежие фрагменты кода, которые вызывают вопросы или гордость
🔍 кейсы из продакшена: узкие места, memory leaks, странности с очередями
🛠️ pet-projects, библиотеки, пакеты: покажите, что сделали за месяц
🧠 вопросы по DDD, микросервисам, тестированию, CI/CD
⚙️ опыт миграции на PHP 8.3/8.4, проблемы совместимости, нюансы производительности
Вы можете прийти с сырым прототипом или сложной продакшен-архитектурой — здесь всегда найдётся человек, который подскажет, куда копать.
Пусть эта ветка остаётся местом для профессионального диалога, где ценят практику, инженерное мышление и точные решения ❤️
👇 Делитесь вашими обновлениями, задачами и победами за последний месяц!
Библиотека пхпшника
Продолжаем традицию — открываем новую декабрьскую ветку 👇
Что можно приносить сюда сейчас:
🧩 свежие фрагменты кода, которые вызывают вопросы или гордость
🔍 кейсы из продакшена: узкие места, memory leaks, странности с очередями
🛠️ pet-projects, библиотеки, пакеты: покажите, что сделали за месяц
🧠 вопросы по DDD, микросервисам, тестированию, CI/CD
⚙️ опыт миграции на PHP 8.3/8.4, проблемы совместимости, нюансы производительности
Вы можете прийти с сырым прототипом или сложной продакшен-архитектурой — здесь всегда найдётся человек, который подскажет, куда копать.
Пусть эта ветка остаётся местом для профессионального диалога, где ценят практику, инженерное мышление и точные решения ❤️
👇 Делитесь вашими обновлениями, задачами и победами за последний месяц!
Библиотека пхпшника
💻 Подборка новостей по 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-скидки экосистемы.
Библиотека пхпшника
#свежак
🔹 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-скидки экосистемы.
Библиотека пхпшника
#свежак
👍1
💡Совет по Laravel: Привязка моделей в Form Request
Привязка моделей к маршрутам позволяет вставлять экземпляры моделей непосредственно в маршруты. Обычно она используется в контроллере, но знаете ли вы, что можно получить доступ к экземпляру модели и в запросе формы?
Библиотека пхпшника
#vardump
Привязка моделей к маршрутам позволяет вставлять экземпляры моделей непосредственно в маршруты. Обычно она используется в контроллере, но знаете ли вы, что можно получить доступ к экземпляру модели и в запросе формы?
Библиотека пхпшника
#vardump
👍1
📈 Почему память в 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
большой файл в
накопление массивов
сложные eager-loading графы ORM
🛠 Как проектировать правильно
✔️ Стриминг вместо коллекций:
или:
✔️ Doctrine:
✔️ Изоляция тяжёлых операций в функцию — память освобождается при выходе из scope.
✔️ Ротация воркеров — обязательна:
Laravel:
RoadRunner:
Messenger:
📌 Выводы
🔸 Память в долгоживущем PHP-процессе не уменьшится сама по себе.
🔸 Проектируйте под пиковое потребление.
🔸Используйте стриминг, чанки, detach().
🔸 Регулярно перезапускайте воркеры.
🔗 Medium
🐸 Библиотека пхпшника
Если вы переходите с 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().
🔸 Регулярно перезапускайте воркеры.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12❤4
Forwarded from Библиотека задач по PHP | тесты, код, задания
🤔5❤4
PostgreSQL vs MongoDB — что выбрать?
В разработке часто сталкиваешься с вопросом: какую СУБД выбрать — реляционную или документо-ориентированную?
Но правильный вопрос не «какая база лучше», а «какая подходит под ваши задачи». Обе технологии заслужили доверие и популярность — просто они решают разные задачи.
🔎 Основные отличия
🛡️ PostgreSQL — реляционная СУБД с таблицами, строгими схемами и SQL, хорошо подходит для надёжных, структурированных моделей.
🌐 MongoDB — документно-ориентированная NoSQL-СУБД, хранит данные как JSON-/BSON-документы без жёсткой схемы — больше гибкости для меняющихся, динамических данных.
PostgreSQL обеспечивает ACID-транзакции, целостность, сложные связи и надёжность.
MongoDB даёт гибкость, масштабируемость и простоту схемы, особенно когда структура данных может изменяться.
✅ Когда PostgreSQL — ваш выбор
🟦 Структурированные данные, чёткие связи между сущностями.
🟦 Необходимы транзакции, консистентность, строгие ограничения (финансы, учёт, бухгалтерия, критичные операции).
🟦 Сложные запросы, отчёты, JOIN-ы, аналитика, отчётность.
🟦 Долгосрочное хранение, стабильность, предсказуемость схемы и данных.
✅ Когда MongoDB — лучший вариант
🟩 Данные меняются часто; структура может эволюционировать, добавляются новые поля, типы записей.
🟩 Необходима гибкость: документы, JSON-объекты, агрегации, неструктурированные или полуструктурированные данные.
🟩 Требуется горизонтальное масштабирование, распределённое хранилище, высокая нагрузка на запись/чтение.
🟩 Быстрая разработка, прототипы, MVP, где хочется избежать долгих миграций схем.
👉 Полная статья с примерами и различными сценариями
Библиотека пхпшника
В разработке часто сталкиваешься с вопросом: какую СУБД выбрать — реляционную или документо-ориентированную?
Но правильный вопрос не «какая база лучше», а «какая подходит под ваши задачи». Обе технологии заслужили доверие и популярность — просто они решают разные задачи.
🔎 Основные отличия
🛡️ PostgreSQL — реляционная СУБД с таблицами, строгими схемами и SQL, хорошо подходит для надёжных, структурированных моделей.
🌐 MongoDB — документно-ориентированная NoSQL-СУБД, хранит данные как JSON-/BSON-документы без жёсткой схемы — больше гибкости для меняющихся, динамических данных.
PostgreSQL обеспечивает ACID-транзакции, целостность, сложные связи и надёжность.
MongoDB даёт гибкость, масштабируемость и простоту схемы, особенно когда структура данных может изменяться.
✅ Когда PostgreSQL — ваш выбор
🟦 Структурированные данные, чёткие связи между сущностями.
🟦 Необходимы транзакции, консистентность, строгие ограничения (финансы, учёт, бухгалтерия, критичные операции).
🟦 Сложные запросы, отчёты, JOIN-ы, аналитика, отчётность.
🟦 Долгосрочное хранение, стабильность, предсказуемость схемы и данных.
✅ Когда MongoDB — лучший вариант
🟩 Данные меняются часто; структура может эволюционировать, добавляются новые поля, типы записей.
🟩 Необходима гибкость: документы, JSON-объекты, агрегации, неструктурированные или полуструктурированные данные.
🟩 Требуется горизонтальное масштабирование, распределённое хранилище, высокая нагрузка на запись/чтение.
🟩 Быстрая разработка, прототипы, MVP, где хочется избежать долгих миграций схем.
👉 Полная статья с примерами и различными сценариями
Библиотека пхпшника
❤3
Opis/closure
Это библиотека для PHP, которая даёт возможность сериализовать (преобразовать в строку/байты) замыкания (closures / анонимные функции), а также анонимные классы и произвольные данные.
По умолчанию PHP не поддерживает сериализацию замыканий: попытка вызвать
Opis/closure обходит это ограничение, обёртывая замыкание — и благодаря этому Вы можете сериализовать, передавать, хранить, а потом восстанавливать функцию и её контекст.
✅ Основные возможности
🔸 Поддержка PHP 8.0+ (включая 8.5) — современный синтаксис, типы, readonly-свойства, атрибуты и пр.
🔸 Сериализация замыканий, анонимных классов, сложных объектов, включая структуры с круговыми ссылками.
🔸 Возможность «безопасного» сериализования: есть поддержка подписанных (signed) данных.
🔸 Не требуется каких-либо расширений PHP (например, FFI) — всё реализовано «на чистом PHP».
🔸 Универсальность: не просто для замыканий — можно сериализовать «любой сложный объект», что даёт гибкость.
📦 Где это используется — и зачем Вам может пригодиться
Фреймворки и библиотеки, которым нужно отложенно сохранять/восстанавливать функции — например, очередь задач, jobs, callback-хранение.
Если хотите передавать анонимные функции между процессами, сохранять их в БД, передавать через очереди — без описания «класса + метод».
При необходимости сериализовать объекты с нестандартным состоянием, содержащие функции или анонимные классы.
Для систем, где нужно «сохранить и восстановить» произвольное состояние (функции, контекст, данные), несмотря на ограничение PHP на сериализацию замыканий.
⚠️ Что важно учитывать
🔹 Библиотека поддерживает PHP 8.0+; если проект на более старой версии — могут быть ограничения.
🔹 Бывают нюансы с «безопасностью»: если используются подписанные сериализованные данные и разные ключи — при десериализации может быть ошибка.
🔹 Как и с любой подобной техникой — злоумелое использование (например, unserialize от данных из ненадёжного источника) — может быть рискованным.
🔗 Github
Библиотека пхпшника
Это библиотека для 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
Библиотека пхпшника
🔥 How to: Упростить сложные запросы в репозитории с помощью Specification Pattern
Когда метод репозитория разрастается до сотен строк с подзапросами, условными блоками и повторяющимися правилами, поддержка кода становится дорогой и рискованной. Частые ошибки, сложность тестирования и высокий порог входа — типичные последствия.
Specification Pattern позволяет разложить такую логику на небольшие независимые компоненты. Каждый класс отвечает за одно правило фильтрации, а общий запрос строится путем композиции этих правил. Архитектура становится чище, поведение — прозрачнее, тестирование — проще.
Что даёт подход:
🔸 разбиение огромных методов на компактные блоки;
🔸 минимизацию дублирования логики;
🔸 предсказуемость и лёгкую расширяемость;
🔸 существенное снижение сложности и рост покрытия тестами.
👉 Читать статью
Библиотека пхпшника
Когда метод репозитория разрастается до сотен строк с подзапросами, условными блоками и повторяющимися правилами, поддержка кода становится дорогой и рискованной. Частые ошибки, сложность тестирования и высокий порог входа — типичные последствия.
Specification Pattern позволяет разложить такую логику на небольшие независимые компоненты. Каждый класс отвечает за одно правило фильтрации, а общий запрос строится путем композиции этих правил. Архитектура становится чище, поведение — прозрачнее, тестирование — проще.
Что даёт подход:
🔸 разбиение огромных методов на компактные блоки;
🔸 минимизацию дублирования логики;
🔸 предсказуемость и лёгкую расширяемость;
🔸 существенное снижение сложности и рост покрытия тестами.
👉 Читать статью
Библиотека пхпшника
👍2