🕑 Метод «times»

Знаете ли вы, что в Laravel есть классный метод коллекций times, который позволяет создавать коллекцию, вызывая замыкание N раз? Это может быть полезно при работе с днями или генерации случайных строк🚀

Что выведет данный код?

🚀 Exceptional Validation — новый подход к валидации данных в Symfony

Теперь валидация бизнес-правил смещается от использования атрибутов и кастомных валидаторов, являющихся частью инфраструктурного кода, к применению бизнес-исключений непосредственно в клиентском коде.​

Преимущества такого подхода:

🔸 Упрощение валидации: Отказ от сложных механизмов, таких как группы валидации и кастомные expressions, делает процесс проверки данных более прозрачным и управляемым.​

🔸 Гибкость в различных контекстах: Возможность легко адаптировать логику валидации в зависимости от конкретного контекста без необходимости создания сложных конструкций.​

🔸 Совместимость: Библиотека интегрируется с Symfony Messenger и amphp, обеспечивая бесшовную работу в существующих проектах.​

🔸 Стандартные сообщения об ошибках: После обработки исключений библиотека возвращает список нарушений ограничений (constraint violations) в формате Symfony Validator.

🔗 Github

Библиотека пхпшника #инструменты

В 2017 году был запущен проект Bref с целью запуска PHP в бессерверной среде на AWS Lambda.

В 2020 году начались замеры количества запросов (или заданий, cron-задач, вызовов и т.д.), которые обрабатываются с его помощью каждый месяц. Это было сделано для того, чтобы показать AWS, что PHP заслуживает большего внимания и поддержки.

Ежемесячно данные добавлялись в электронную таблицу, и их количество постоянно растет. Как упомянуто в заголовке, на сегодняшний день с помощью PHP на Lambda обрабатывается более 40 миллиардов запросов в месяц.

Методика замеров описана в документации.

Кратко: каждые 100 вызовов среды выполнения отправляется несколько байтов данных через UDP. Эти данные полностью анонимны (вот содержимое пакета: Invocations_100:1|c\nLayer_fpm_100:1|c), а использование UDP гарантирует, что передача занимает всего несколько микросекунд (она неблокирующая). Эти байты доходят до небольшого сервера на EC2, который увеличивает счетчик в CloudWatch.

Наличие этой метрики оказалось крайне полезным во взаимодействии с AWS — теперь проект Bref воспринимается ими гораздо серьезнее. Примерно 1 из 1000 вызовов AWS Lambda — это PHP с Bref.

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

Кроме того, удалось интегрировать счётчик метрик в режиме реального времени (почти реального времени, данные кэшируются на несколько минут) на главной странице проекта: bref.sh

⚙️ Улучшаем производительность кода с AI

Обнаружили в профилировщике тормозящий код? Попробуйте этот промпт, чтобы AI помог вам оптимизировать его:

📝 Промпт:

Analyze the following PHP code and suggest optimizations for better performance. Identify bottlenecks, improve memory usage, and recommend alternative approaches.

// Вставьте ваш код здесь

💡 Дополнительные возможности:

— Добавьте Refactor it using modern PHP features (e.g., OPcache, JIT, Fibers), если хотите использовать новейшие возможности PHP.
— Добавьте Optimize it for concurrency using Swoole or ReactPHP, если важна многопоточность и высокая нагрузка.
— Добавьте Suggest a profiling strategy using Xdebug or Blackfire, если нужна диагностика.

💬 Какие инструменты вы используете для профилирования кода?

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

♻️ Переопределение с помощью интерфейса

Атрибут Override проверяет, что метод действительно переопределяет родительское определение того же метода: это подразумевает, что у класса должен быть родитель, чтобы использовать атрибут Override.

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

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

❓ PDO или ORM?

PDO — для тех, кто ценит полный контроль. Пишете SQL вручную, понимаете, что происходит под капотом. Гибкость максимальна, но код засоряется повторениями, а сложные запросы становятся испытанием при развитии проекта.

ORM (Eloquent, Doctrine) — путь удобства. Работаете с объектами вместо SQL, код становится чище, а разработка быстрее. Но магия абстракции может привести к неожиданным SQL-запросам, проблемам с производительностью и сложной отладке.

💬 Вы за прозрачность и контроль или удобство и скорость разработки? Какой путь выбираете вы?

Библиотека пхпшника #междусобойчик

Богатые и анемичные сущности в PHP с Doctrine: как правильно структурировать бизнес-логику

Статья обсуждает концепцию Rich Entities (богатых сущностей) в разработке на PHP, особенно в контексте сложных бизнес-приложений, использующих Doctrine ORM для объектно-реляционного отображения. В статье проводится сравнение Rich Entities с традиционным подходом Anemic Entities (анемичных сущностей) и объясняется, как богатые доменные модели могут привести к лучшей инкапсуляции бизнес-логики и улучшению поддерживаемости.

Анемичные сущности:

🔸 Это сущности, которые служат только контейнерами данных, не содержащими бизнес-логики.

🔸 Логика переносится в сервисные классы, что приводит к фрагментированному коду, трудностям с тестированием и слабой инкапсуляции.

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

Богатые сущности:

🔹 Богатые сущности инкапсулируют как состояние, так и поведение. Они содержат бизнес-логику внутри самой сущности, что делает код более поддерживаемым, выразительным и легким для тестирования.

🔹 Бизнес-правила (например, проверка корректности платежей) проверяются внутри сущности, что помогает поддерживать согласованность модели и её близость к реальному домену.

🔹 Этот подход лучше соответствует принципам SOLID (например, Принцип Единой Ответственности и Принцип Открытости/Закрытости).

Преимущества богатых сущностей:

🔸 Улучшенная тестируемость: Тестирование становится проще, так как бизнес-логика находится внутри сущности, что позволяет создавать более фокусированные тесты, ориентированные на домен, без необходимости в множестве заглушек или сервисных слоях.

🔸 Лучшая читаемость кода: API сущности отражает домен (например, $order->pay() вместо $orderService->payOrder()), что делает код более понятным и легче воспринимаемым.

🔸 Инкапсуляция и целостность домена: Сущность управляет своим состоянием и поведением, гарантируя, что бизнес-ограничения соблюдаются и поддерживаются.

Статические методы create():

В статье рекомендуется использовать статические методы create() для создания сущностей, чтобы гарантировать их создание в валидном состоянии. Это позволяет избежать создания неполных или некорректных объектов и концентрирует логику инициализации в одном месте.

Сервисный слой против логики сущности:

🔹 Часто бизнес-логику переносят в сервисный слой (например, OrderPaymentService), но это может привести к слабой инкапсуляции и дублированию кода.

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

Когда использовать богатые и когда анемичные сущности:

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

Анемичные сущности могут быть полезны в простых приложениях CRUD или в средах, где бизнес-логика минимальна.

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