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

10 повседневных ошибок PHP

Здесь рассказывается о важности обработки ошибок в PHP и предлагает подробный обзор наиболее распространенных типов ошибок и способов их обработки. Описаны такие типы ошибок, как PHP ParseError, DivisionByZeroError, TypeError, UnexpectedValueException, PDOException, RuntimeException, InvalidArgumentException, LogicException, ArithmeticError и Exceptions, а также предоставлены практические советы и методы их обработки.

Далее статья рассказывает о преимуществах использования инструментов для мониторинга и отладки ошибок в PHP, таких как Zipy, и предоставляет рекомендации по интеграции таких инструментов в разработку.

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

«Мы пилили монолит — много нас, а он один». Полезные советы от команды Яндекс Еды

Рассказ начинается с краткой истории сервиса, подчеркивая ее эволюцию от стартапа в 2015 году до крупного монолита к 2023 году. Решение отказаться от монолита было обусловлено различными проблемами, такими как отсутствие экспертизы, проблемы с релизами, сложность кода, размытые ответственности и трудности с локальным развертыванием.

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

Для обеспечения успешного перехода команда реализовала различные меры. Они включали написание модульных и приемочных тестов, использование строгих линтеров, создание клиентов на основе файлов YAML, создание инструментов для контролируемого переключения и настройку панелей логирования и метрик для мониторинга производительности.

Затем автор подробно рассматривает конкретные инструменты и подходы, используемые во время перехода:

1️⃣Auth-proxy: Сервис шлюза API, ответственный за авторизацию пользователей и маршрутизацию запросов к соответствующим микросервисам. Он позволяет постепенно перенаправлять трафик от монолита к новым сервисам.

2️⃣API-proxy: Фасадный сервис для интеграции микросервисов. Применяются различные варианты переключения трафика, включая постепенное перенаправление трафика от монолита к новым сервисам при обеспечении идентичных ответов.

3️⃣Сервис экспериментов: Сервис, который делит пользовательские запросы на группы на основе параметров запроса, позволяя контролируемо экспериментировать с новой функциональностью.

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

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

Подготовка Symfony-приложения для Swoole, RoadRunner, and FrankenPHP (без использования ИИ)

📝 Проблема:
🔄 Модели разделения памяти:

Модель «Shared Nothing» и модель «Shared Memory». Обычно в PHP-приложениях используется модель «Shared Nothing», где каждый запрос обрабатывается отдельным PHP-процессом, и между запросами не происходит обмена памятью.

⚠️ Непредвиденные эффекты:
С появлением решений типа Swoole, RoadRunner и FrankenPHP, которые используют модель «Shared Memory», возникают некоторые непредвиденные проблемы. Эти решения позволяют разделять память между различными запросами внутри одного рабочего процесса, что приводит к улучшению производительности, но может вызывать неожиданные побочные эффекты, так как состояние между запросами сохраняется.

🔧 Решение:
Представлен пример кода на Symfony 7.0, где демонстрируется проблема с сохранением состояния между запросами. Это приводит к неправильному поведению при использовании модели «Shared Memory». Для исправления проблемы предлагается использовать инструмент статического анализа кода phanalist, который проверяет, являются ли сервисы в приложении состояний или неизменяемыми. Также предлагается использовать интерфейс ResetInterface в Symfony для обнуления состояния сервисов между запросами.

Какова разница между «cookie» и «session»?

В PHP «cookie» и «session» — это механизмы управления состоянием в веб-приложениях, но они служат немного разным целям:

Cookie:

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

Session:

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

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

#memes

При использовании конструкторов в Artisan-командах, каждый раз при вызове любой команды через php artisan, происходит конструирование экземпляра каждой команды, что приводит к автоматическому разрешению зависимостей через сервис-контейнер. Это может быть неожиданным и иметь нежелательные последствия, особенно в крупных проектах с большим количеством команд.

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

Паттерн Aggregate Outside

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

Приведен пример вымышленного кейса, связанного с сервисом обмена валют. В этом кейсе агрегат представляет заявку на обмен валюты (Bid), и для выполнения его бизнес-правил требуются данные, находящиеся вне агрегата. Рассмотрены следующие бизнес-правила:

🟠Пользователь не может обменять более 1000 долларов в сутки.
🟠Если сумма обмена менее 100 долларов, курс берется из банка A, иначе из банка Б.
🟠Лимит и минимальная сумма могут изменяться в зависимости от дня недели.

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

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

Поэтому предлагается альтернативный подход, основанный на понятии «внешнего интерфейса» (outside interface). Вместо внедрения всех зависимостей напрямую в агрегат, они внедряются в отдельный враппер, который предоставляет данные в формате, удобном для агрегата. Это упрощает код агрегата и уменьшает его зависимость от внешних сервисов. Кроме того, разработку можно разделить на этапы: сначала реализуется бизнес-логика, затем подключается агрегат к инфраструктуре через внешний интерфейс, и в конце реализуется инфраструктура.

Такой подход позволяет разделить доменную логику от инфраструктурных аспектов, уменьшить зависимости агрегата и упростить его тестирование.

Retry-механизмы в Laravel

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

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

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

Механизмы повторных попыток предоставлены в Laravel в нескольких контекстах:

1️⃣Повтор в транзакциях базы данных: Обсуждается возможность повтора транзакций в Laravel в случае возникновения дедлоков при выполнении операций с базой данных.

2️⃣Повтор при вызове HTTP: Рассматривается использование HTTP-клиента Laravel для автоматического повтора запросов к сторонним API в случае неудачи.

3️⃣Повтор при выполнении задач в очереди: Обсуждается возможность повтора выполнения задач в очереди в случае возникновения ошибок.

4️⃣Повтор выполнения неудачных задач: Рассматривается методика повторного выполнения неудачных задач после их исправления.

5️⃣Повтор в режиме обслуживания: Описывается использование опции повтора при переводе приложения в режим обслуживания.

6️⃣Помощник retry: Приводится пример использования встроенного метода retry Laravel для повтора выполнения произвольного кода.

Самые полезные каналы для программистов в одной подборке!

Сохраняйте себе, чтобы не потерять 💾

🔥Для всех

Библиотека программиста — новости, статьи, досуг, фундаментальные темы
Книги для программистов
IT-мемы
Proglib Academy — тут мы рассказываем про обучение и курсы

#️⃣C#

Книги для шарпистов | C#, .NET, F#
Библиотека шарписта — полезные статьи, новости и обучающие материалы по C#
Библиотека задач по C# — код, квизы и тесты
Библиотека собеса по C# — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Вакансии по C#, .NET, Unity Вакансии по PHP, Symfony, Laravel

☁️DevOps

Библиотека devops’а — полезные статьи, новости и обучающие материалы по DevOps
Вакансии по DevOps & SRE
Библиотека задач по DevOps — код, квизы и тесты
Библиотека собеса по DevOps — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования

🐘PHP

Библиотека пхпшника — полезные статьи, новости и обучающие материалы по PHP
Вакансии по PHP, Symfony, Laravel
Библиотека PHP для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по PHP — код, квизы и тесты

🐍Python

Библиотека питониста — полезные статьи, новости и обучающие материалы по Python
Вакансии по питону, Django, Flask
Библиотека Python для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по Python — код, квизы и тесты

☕Java

Библиотека джависта — полезные статьи по Java, новости и обучающие материалы
Библиотека Java для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по Java — код, квизы и тесты
Вакансии для java-разработчиков

👾Data Science

Книги для дата сайентистов | Data Science
Библиотека Data Science — полезные статьи, новости и обучающие материалы по Data Science
Библиотека Data Science для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по Data Science — код, квизы и тесты
Вакансии по Data Science, анализу данных, аналитике, искусственному интеллекту

🦫Go

Книги для Go разработчиков
Библиотека Go разработчика — полезные статьи, новости и обучающие материалы по Go
Библиотека Go для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по Go — код, квизы и тесты
Вакансии по Go

🧠C++

Книги для C/C++ разработчиков
Библиотека C/C++ разработчика — полезные статьи, новости и обучающие материалы по C++
Библиотека C++ для собеса — тренируемся отвечать на каверзные вопросы во время интервью и технического собеседования
Библиотека задач по C++ — код, квизы и тесты
Вакансии по C++

💻Другие профильные каналы

Библиотека фронтендера
Библиотека мобильного разработчика
Библиотека хакера
Библиотека тестировщика

💼Каналы с вакансиями

Вакансии по фронтенду, джаваскрипт, React, Angular, Vue
Вакансии для мобильных разработчиков
Вакансии по QA тестированию
InfoSec Jobs — вакансии по информационной безопасности

📁Чтобы добавить папку с нашими каналами, нажмите 👉сюда👈

🤖Также у нас есть боты:
Бот с IT-вакансиями
Бот с мероприятиями в сфере IT

Мы в других соцсетях:
🔸VK
🔸YouTube
🔸Дзен
🔸Facebook *
🔸Instagram *

* Организация Meta запрещена на территории РФ

⚡️Итоги недели в мире ИИ и обзоры новых сервисов

У нас вышла очередная статья на 📰 по мотивам еженедельной рассылки про последние новости и тенденции в мире ИИ.

Ниже — небольшая выдержка из статьи, а целиком читайте здесь 👈

💬Новости

▫️ Создан новый тест для ИИ — WMDP (Weapons of Mass Destruction Proxy), который будет проверять модели на знание:
- способов создания и применения всех видов оружия массового поражения;
- методов взлома систем кибербезопасности.
▫️Глава OpenAI Сэм Альтман обнародовал переписку с Илоном Маском, в которой последний указывает на то, что ожидает от OpenAI прибыли. Это противоречит недавним заявлениям Маска.

🛠 Инструменты

▫️Corgea — находит и автоматически исправляет уязвимости в коде.
▫️GenWebBilder — делает полнофункциональные веб-сайты по скетчам и скриншотам.
▫️Framedrop AI — автоматически конвертирует длинные видео, влоги и стримы в рилсы и короткие клипы для X и TikTok.
▫️Vocalo AI — личный репетитор, который научит свободно говорить по-английски.

👍 Робототехника

Профессор Кен Голдберг из Университета Беркли поделился соображениями по поводу технических, этических и экономических проблем, которые препятствуют широкому внедрению ИИ-роботов на данном этапе.

➡️ Вы можете подписаться на email-рассылку здесь

9 Правил написания лучшего кода

Здесь описаны девять правил, известных как «Calisthenics Object». Эти правила направлены на улучшение качества кода, его читаемости и поддерживаемости, предоставляя рекомендации по написанию более чистого и эффективного кода:

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

Не использовать ключевое слово else: Это правило поощряет использование ранних возвратов или инициализации заранее, чтобы избежать вложенных структур кода и улучшить ясность.

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

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

Только один -> в строке (за исключением Fluent interface): Это правило поощряет соблюдение Закона Деметры, ограничивая цепочку методов одним уровнем на строку для улучшения читаемости кода.

Не использовать аббревиатуры: Избегание аббревиатур улучшает ясность кода и его поддерживаемость, облегчая понимание для разработчиков.

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

В классах не должно быть более пяти переменных экземпляра: Ограничение числа переменных экземпляра на класс уменьшает зависимости и облегчает тестирование и поддержку классов.

Без геттеров/сеттеров: Предпочтительно инкапсулировать действия вместо прямого доступа к свойствам объекта, поощряя принцип «Говори, не спрашивай».

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

#хочу_спросить

Задавайте любые вопросы о программировании и получайте ответы от пользователей. В комментариях под постом укажите #язык, #стек и/или #библиотеку, по которым задаете вопрос.

Обработка одного миллиарда строк в PHP

Здесь описывается опыт оптимизации обработки большого объема данных в PHP. Автор начинает с наивной реализации, используя функцию fgetcsv(), и постепенно оптимизирует код, улучшая производительность на каждом этапе.

Далее описывается использование инструментов профилирования для выявления узких мест в коде и принимается решение о замене fgetcsv() на более простые функции, такие как fgets() и ручное разделение строк. Далее автор применяет оптимизации, такие как использование ссылок, использование явных типов данных и включение JIT (just-in-time компиляции) через расширение OPCache. Каждая оптимизация приводит к улучшению производительности.

Затем автор рассматривает многопоточное программирование в PHP с использованием расширения parallel. Он разбивает обработку данных на несколько потоков для параллельной обработки, что приводит к дальнейшему значительному улучшению производительности.

🕹️ Композиция против Наследования:

Проводится аналогия между тем, как в Тетрисе составляются фигуры, чтобы создать линии, и тем, как объекты комбинируются в разработке программного обеспечения.
Объясняется, как композиция способствует гибкости и модульности, в то время как наследование может привести к Проблеме Хрупкого Базового Класса и сильной связанности.

🔧 Принцип Одной Ответственности (SRP):

В статье подчеркивается важность SRP в создании меньших, поддерживаемых единиц кода.
Утверждается, что разделение кода не должно зависеть исключительно от композиции, а скорее от соблюдения SRP, что делает код более переиспользуемым и поддерживаемым.

💉 Внедрение Зависимостей:

Вместо использования наследования для переиспользования кода предлагается использовать внедрение зависимостей и композицию.
Используя композицию, разработчики могут сократить влияние изменений и избежать Проблемы Хрупкого Базового Класса.

🌟 Принципы SOLID:

Тут также кратко затрагиваются принципы SOLID, упоминая Принцип Одной Ответственности и Внедрение Зависимостей, и намекают на то, что они будут рассмотрены более подробно в будущем контенте.

👀 Взгляд на Наследование:

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

Куда делась 6 версия PHP?

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

11 марта 2010 команда разработчиков приняла решение об отмене выпуска PHP 6 в текущем его виде. В результате транк с PHP 6 был перенесён в бранч, а в транке образовалась новая версия — 5.4, в которую разработчики перенесли все наработки из PHP 6, кроме юникода.

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

#memes

Laravel Setting Pro

Пакет Laravel Setting Pro упрощает управление настройками приложения в Laravel и предоставляет эти ключевые функции:

Гибкое хранилище: выберите между файловым хранилищем или БД в соответствии с потребностями вашего приложения.

Гибкая база данных: выберите между MySQL или MongoDB или создайте собственное соединение DB для настройки.

Кэширование: повышение производительности с помощью автоматического кэширования настроек. Вы можете выбрать между файлом или redis или создать собственный драйвер кэша.

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

Триггеры события: ответ на настройку изменений в режиме реального времени, используя события Laravel.

Глобальная вспомогательная функция и фасад: доступ и манипуляция настройками в любом месте вашего приложения Laravel с простой функцией настройки или настройкой фасада (даже в файлах конфигурации).

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

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

🧨 Из грязи в князи: вкатился с нуля в IT за границей

❗ Мы ищем тех, кто начинал карьеру в IT за границей без опыта и специальной подготовки. Хотим услышать ваши истории успеха и препятствий, с которыми вы столкнулись.

‼️ Если вы готовы рассказать свою историю — напишите нам на hello@proglib.io

🗺️ Где составить дорожную карту: ТОП-10 сервисов

Сервисы, которые подойдут для составления карьерной карты и не только.

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

#гайд

Создание PHP SDK для Replicate AI

Здесь описывается процесс создания SDK (набора инструментов разработки программного обеспечения) на PHP для работы с API Replicate AI. Автор начинает с объяснения, что такое SDK и зачем оно нужно, а затем переходит к анализу документации API Replicate и определению ресурсов, с которыми нужно работать: Models (модели), Versions (версии) и Predictions (предсказания). Далее автор предлагает структуру SDK и предлагает реализацию основного класса «Client» и ресурса «Model». Он подчеркивает важность использования хорошего опыта разработчика при создании SDK и приводит примеры вызовов методов API через SDK. Кроме того, обсуждаются вопросы аутентификации и обработки ошибок. Автор заключает статью обещанием опубликовать репозиторий SDK на GitHub после его завершения и тестирования.