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

🧅 Onion: Механизм многоуровневой обработки для PHP-приложений

Onion — это легкий пакет, предназначенный для облегчения многоуровневой обработки данных в приложениях. Он обеспечивает чистый и эффективный способ укладки слоев функциональности, позволяя разработчикам создавать гибкие и многократно используемые компоненты, которые легко компоновать и управлять ими. Каждый слой может выполнять определенную операцию над передаваемыми данными, что упрощает построение сложных рабочих процессов, сохраняя при этом четкое разделение задач.

Хотя whereHas в Laravel отлично подходит для поиска записей на основе заданных отношений и дополнительных ограничений запроса, существует сокращение под названием whereRelation, которое решает ту же задачу 🚀.

Ленивые объекты в PHP 8.4: новая эра эффективной работы с объектами

В PHP 8.4 появилась новая возможность — ленивые объекты. Эта функция позволяет откладывать создание объекта до момента, когда он действительно потребуется. Это особенно полезно для объектов с тяжелой инициализацией, которые могут не понадобиться во время выполнения программы.

Чем ленивые объекты отличаются от обычных?
Обычные объекты создаются сразу, и их конструкторы вызываются при создании. Ленивые объекты работают иначе: вместо создания объекта сразу, они используют прокси, который имитирует исходный класс. Настоящий объект создается только при доступе к его методам или свойствам. Для этого используется рефлексия.

Преимущества ленивых объектов
🔸Улучшение производительности: Объекты создаются только при необходимости, что снижает нагрузку на память.
🔸Простота использования: Ленивые объекты работают как обычные, не требуя изменений в коде.
🔸Оптимизация ресурсов: Особенно полезно в системах, где создание объектов может быть отложено, например, в DI-контейнерах, ORM или при работе с API.

Ограничения
❗️Сериализация: Работа с ленивыми объектами при сериализации может быть сложнее из-за их отложенного состояния.
❗️Усложнение отладки: Прокси-слои могут запутывать стеки вызовов и затруднять анализ проблем.

👀 Кто бы мог подумать, но WinRAR продаёт 10тыс. лицензий в месяц

WinRAR — легендарный условно-бесплатный архиватор, известный своей бесконечной «ознакомительной» лицензией, которая уже давно стала поводом для десятков мемов.

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

Привет, друзья! 👋

2024-й год подходит к концу, и пока LLM не написали за нас все программы, а квантовые компьютеры не взломали все пароли, самое время подвести итоги.

Какие технологии действительно «выстрелили», а какие не оправдали ожиданий? Что изменилось в работе разработчиков, и какие навыки оказались самыми востребованными?

💻 Поделитесь своим мнением, и самое важное и интересное войдет в нашу статью. 🏆

Улучшения библиотеки мониторинга Symfony

За последние несколько месяцев была проведена серьезная работа по обновлению системы мониторинга для разработчиков Symfony. Библиотека мониторинга Symfony занимает второе место по популярности среди клиентов Inspector, уступая только пакету для Laravel.

Поддержка Doctrine 3.x
Новая версия Doctrine, выпущенная в начале года, перешла с SQL-логгеров на новую архитектуру Middleware. Для совместимости в библиотеке был добавлен механизм, который определяет используемую версию Doctrine и автоматически подключает подходящий инструмент: SQL-логгер или middleware.

Сбор шаблонов маршрутов вместо их имен
Ранее библиотека использовала имена маршрутов для мониторинга HTTP-трафика в приложении Symfony. Однако такой подход имел ряд недостатков:

Имя маршрута не является обязательным, что приводило к сбору данных с разнородным форматом.
Игнорирование маршрутов на основе имен было сложным из-за отсутствия четкой структуры.
В случае отсутствия имени маршрута использовался полный URL, включая динамические параметры, что создавало лишний «шум» в данных.
Для решения этих проблем теперь собираются шаблоны маршрутов, такие как /users/{id}/profile, вместо реальных URL. Это позволяет:

🔸избежать дублирования данных при изменении параметров маршрута;
🔸удобно игнорировать определенные сегменты приложения, например, /admin*, используя символы подстановки в конфигурации.

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

Бесплатное использование Inspector
Inspector — инструмент мониторинга выполнения кода, созданный для разработчиков. Установив пакет Symfony, вы сможете отслеживать HTTP-запросы, анализировать работу базы данных и получать уведомления. Сервис доступен бесплатно, и зарегистрироваться можно на сайте Inspector.

Расскажите об автоматических анализаторах кода PHP

Автоматические анализаторы кода PHP представляют собой инструменты, которые помогают разработчикам обнаруживать потенциальные проблемы, ошибки и несоответствия стандартам кодирования в их PHP-проектах. Они облегчают процесс разработки, улучшают качество кода и делают его более поддерживаемым. Roundcube — это веб-почтовый клиент с открытым исходным кодом, написанный на PHP, поэтому использование анализаторов кода для PHP критически важно для его разработки и поддержки.

Вот некоторые из популярных автоматических анализаторов кода PHP:

PHP_CodeSniffer: Это один из наиболее широко используемых инструментов для проверки соответствия кода стандартам. Он может анализировать код на соответствие различным стандартам кодирования, таким как PSR (PHP Standards Recommendations), PEAR, Zend, и пользовательские стандарты.

PHPMD (PHP Mess Detector): Этот инструмент анализирует код на предмет потенциальных проблем, таких как дублирование кода, сложные условия, избыточная сложность функций и т. д.

PHPStan: Это инструмент статического анализа кода, который помогает выявить ошибки в коде на этапе разработки. Он проверяет типы данных, используемые в коде, и обнаруживает потенциальные ошибки, такие как вызов несуществующих методов или свойств объектов.

SonarQube: Это мощный инструмент для анализа качества кода на множестве языков программирования, включая PHP. Он предоставляет широкий спектр анализов, включая статический анализ, анализ цикломатической сложности, анализ уязвимостей безопасности и т. д.

#вопросы_с_собеседований

#memes

Laravel под капотом — расширение стандартных возможностей фреймворка

Проблема
FakerPHP поддерживает модификаторы valid() и unique(), но их нельзя использовать одновременно (например, fake()->unique()->valid()). Появилась необходимость добавить такую функциональность, не нарушая работы Laravel и не создавая сложностей при обновлении фреймворка.

Изучение механизма
Функция fake() в Laravel возвращает объект \Faker\Generator, который создаётся через фабрику и привязывается к контейнеру как синглтон. Это усложняет задачу: нельзя просто заменить объект через наследование, так как это потребует повторной реализации логики фабрики.

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

🔸Создание класса-декоратора
Был создан класс FakerGenerator, принимающий базовый объект \Faker\Generator и добавляющий метод uniqueAndValid(). Этот класс также использует трейт Laravel ForwardsCalls, чтобы проксировать вызовы отсутствующих методов к оригинальному объекту.

🔸Интеграция в Laravel
Класс FakerGenerator был зарегистрирован в контейнере через метод extend() в провайдере AppServiceProvider. Это позволяет Laravel использовать новый декоратор вместо стандартного генератора при вызове fake()

Результат
Теперь вызовы fake()->uniqueAndValid()->randomElement() работают корректно, а все остальные методы генератора по-прежнему доступны благодаря механизму проксирования.

💬 Как часто вы размышляете о работе в нерабочее время?

❤️ — достаточно часто
👍 — иногда приходят мысли
🌚 — стараюсь отключаться
🥱 — никогда не думаю

#дайджест #PHPdevjob

Вакансии PHP разработчиков уровня Junior

▪️ Junior PHP-разработчик / Web-программист (стажер), офис
Офис (Москва), РосБизнесСофт
Подробнее

▪️ Программист PHP (Bitrix)
Офис (Йошкар-Ола), Цитрус
Подробнее

Вакансии PHP разработчиков уровня Middle

▪️ PHP developer
Удалёнка (РФ), Jivo
Подробнее

▪️ PHP-разработчик (на проект E-commerce)
Удалёнка, Fix Price
Подробнее

Вакансии PHP разработчиков уровня Senior

▪️ Senior php developer
Гибрид (Москва), Brand Analytics
Подробнее

▪️ Team Lead РНР
Удалёнка, ВиаМоби
Подробнее

Понравились вакансии?
❤️ — да
🤔 — нет

Оптимизация производительности в PHP: ключевые техники и рекомендации

Управление памятью и обработка ресурсов
Эффективное управление памятью помогает избежать утечек и снизить нагрузку на сервер. Для работы с большими файлами можно использовать генераторы (yield), которые позволяют обрабатывать данные по частям, не загружая весь файл в память. Например:

🔸Использование генераторов: метод yield позволяет обрабатывать строки файла построчно.
🔸Закрытие ресурсов: блок finally гарантирует освобождение ресурсов, даже при возникновении исключений.
🔸Очистка переменных: после использования данных их можно явно удалять с помощью unset.
Эти приемы помогают минимизировать использование памяти при работе с большими файлами.

Оптимизация структур данных и кэширование
Эффективные структуры данных и грамотное кэширование сокращают повторяющиеся вычисления и обращения к базе данных:

Временной таймаут (TTL): данные в кэше автоматически удаляются после заданного времени.
Стратегия LRU (Least Recently Used): старые записи кэша удаляются при достижении лимита.
Предварительная очистка кэша: перед добавлением новых данных проверяется текущий объем.

Оптимизация операций со строками
Строковые операции могут потреблять много памяти. Рекомендуется:

🔸Использовать implode вместо конкатенации для объединения строк.
🔸Применять буферизацию вывода (ob_start) при создании больших строк, например, HTML-кода.
🔸Заменять str_replace на более эффективный strtr для множественных замен.
🔸Предварительно компилировать регулярные выражения для повышения скорости поиска.

Оптимизация запросов к базе данных
Для повышения производительности взаимодействия с базой данных:

Подготовка запросов: повторно используйте кэшированные подготовленные запросы.
Массовая вставка: вместо множества отдельных запросов используйте пакетную вставку данных.
Выборочные поля: извлекайте только нужные столбцы, чтобы уменьшить объем передаваемых данных.
Эти подходы позволяют сократить время выполнения запросов и снизить нагрузку на сервер.

Оптимизация работы с массивами и циклами
При работе с массивами стоит учитывать:

🔸Предварительное выделение памяти: создавайте массивы с заранее известным размером.
🔸Обработка данных по частям: используйте array_chunk, чтобы снизить использование памяти.
🔸Эффективный поиск: применяйте isset или array_flip для быстрого поиска.

Обработка ошибок и логирование
Корректное управление ошибками помогает поддерживать стабильность приложения:

🔸Ротация логов: управление объемом файлов с логами помогает избежать переполнения диска.
🔸Многоуровневая система логов: для разных типов сообщений применяются разные уровни логирования (например, DEBUG, ERROR).
🔸Уведомления администраторов: критические ошибки могут автоматически отправляться в системы мониторинга.

Иногда вам может потребоваться убедиться, что строка заканчивается определенным символом, например косой чертой или точкой. Laravel поставляется с помощником finish, который позволяет сделать это 🚀.

Безопасная миграция базы данных: Преобразование MySQL Enum в строку в Laravel

В работе с базами данных иногда возникает необходимость изменить тип столбца. Одна из сложных задач — преобразование столбца типа enum в строковый формат, при этом сохраняя все данные. Здесь предложен надежный способ решения этой задачи с использованием миграций Laravel.

Что такое полнотекстовый поиск в MySQL? Как он реализуется?

Полнотекстовый поиск в MySQL — это механизм поиска, который используется для быстрого нахождения текстовой информации в текстовых данных, таких как столбцы CHAR, VARCHAR или TEXT. Он предоставляет более сложные возможности поиска по сравнению с традиционным оператором LIKE, позволяя находить строки, содержащие релевантные ключевые слова, с учетом таких факторов, как вес слов, совпадение формы слова и т. д.

Основные особенности полнотекстового поиска

🔸Работает с индексами, что обеспечивает высокую скорость поиска.
🔸Предлагает возможность использовать булевые операции (AND, OR, NOT) и ранжирование результатов по релевантности.
🔸Использует специальные индексы типа FULLTEXT.
🔸Поддерживается для таблиц с механизмом хранения InnoDB (начиная с MySQL 5.6) и MyISAM.

Реализация полнотекстового поиска

1. Создание индекса Чтобы использовать полнотекстовый поиск, необходимо создать индекс типа FULLTEXT для одного или нескольких текстовых столбцов таблицы.

2. Использование оператора MATCH() ... AGAINST() Для поиска используется функция MATCH() вместе с AGAINST().

Особенности настройки
🔸Стоп-слова: Полнотекстовый поиск игнорирует часто встречающиеся слова (например, предлоги или союзы). Эти слова можно настроить или отключить.
🔸Минимальная длина слова: По умолчанию MySQL не индексирует слова короче 4 символов (настраивается параметром ft_min_word_len).
🔸Языковые настройки: Для работы с морфологией и лексикой используется список стоп-слов и настройки языка.

#memes

Laravel Safe Dispatcher для очередей

Бывает такое, что Queue не может отправить задание, и SafeDispatcher призван, чтобы помочь в этой ситуации и:

✔️Сохранить сообщение, которое не удалось отправить.

✔️Повторить его по требованию.

и многое другое!

Кодогенерация моделей и миграций в Laravel

Да, вместо того, чтобы ручками писать все эти скрипты миграций и в особенности классы моделей их лучше просто генерить в одно мгновение, а ни сидеть, копипастить туда‑сюда названия полей и т. п. Называется всё это термином database reverse engineering, который, как и технология судя по всему не очень то прижился, а совершенно напрасно. Под reverse engineering'ом обычно понимается генерация моделей/сущностей на основе таблиц БД. Но для Laravel есть ещё и кодогенераторы миграций.

Альтернативный способ структурировать проект Symfony

Архитектура MVC + Services давно стала стандартом в проектах Symfony. Она проста, знакома и обычно эффективна, но с ростом сложности проекта начинают проявляться слабые места: бизнес-логика оказывается разрозненной, поведение приложения становится неочевидным, а поддержка кода превращается в проблему. Хотя Symfony не ограничивает вас этой архитектурой, многие разработчики воспринимают её как единственный вариант.

Проблемы MVC + Services в больших проектах
🔸Разрозненная бизнес-логика
По мере роста проекта бизнес-логика распределяется между контроллерами, сервисами, формами, сущностями и другими слоями. Это усложняет работу с кодом, поскольку каждый слой содержит лишь часть общей модели.

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

🔸Неявное поведение приложения
Структура кода в MVC + Services не даёт ясного понимания, что именно делает приложение. Сложно выявить ключевые действия проекта без анализа множества файлов и зависимостей.

🔸Смешанные жизненные циклы
Бизнес-логика обычно живёт дольше, чем реализации, такие как API, базы данных или фреймворки. Смешение логики с деталями реализации приводит к тому, что даже небольшие изменения требуют переработки большого объёма кода.

Альтернативный подход: архитектура с выделением бизнес-логики
1. Изоляция бизнес-логики
Первый шаг — выделение бизнес-логики в отдельную папку Domain, которая становится ядром проекта. Эта папка содержит чистые PHP-объекты, не зависящие от фреймворков или библиотек. Внутри папки файлы группируются по логическим функциям, а не техническим слоям.

2. Определение «входной двери» проекта
Создайте папку Application, которая явно описывает все действия и возможности приложения. Это поможет новым разработчикам быстро понять, что может проект.

3. Работа с внешними системами
Реализация интеграции с фреймворками, базами данных и другими системами выносится в папку Infrastructure. Она зависит от файлов в папках App и Domain, но не наоборот.

4. Выявление и разделение контекстов
Если понятия, такие как «Продукт», имеют разные значения в разных частях проекта (например, товар на складе и товар в магазине), их нужно разделить на отдельные контексты с независимой бизнес-логикой.

Эволюция архитектуры

🟢Модульность и границы
Если какой-то модуль проекта разрастается, его можно выделить в отдельный деплоймент. Но это стоит делать только при необходимости, например, если команды сталкиваются с трудностями совместной работы.

🟢Систематизация кода
Архитектуры, такие как Hexagonal, Onion, и Clean, помогают изолировать бизнес-логику от деталей реализации. Это делает тестирование проще и код более устойчивым к изменениям.

🟢«Говорящая» структура проекта
Структура файлов должна «кричать» о том, что делает приложение. Организация кода должна быть интуитивно понятной и отражать функциональность проекта.