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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

🔥Для всех

Библиотека программиста — новости, статьи, досуг, фундаментальные темы
Книги для программистов
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 запрещена на территории РФ

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

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

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

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

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

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

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

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

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

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

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

Паттерн Aggregate Outside

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

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

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

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

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

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

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

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

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

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

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

Cookie:

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

Session:

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

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

Подготовка 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 для обнуления состояния сервисов между запросами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Coolify

Это open-source альтернатива Heroku / NetLify / Vercel / и т. д.

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

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

В начале описывается привычная схема работы сервера: он выполняет задачу по запросу клиента и завершает свою работу после отправки ответа. Однако, когда количество одновременных запросов становится значительным, сервер может столкнуться с проблемой ограниченности производительности, особенно в случае выполнения медленных задач ввода-вывода (I/O), таких как обращение к базе данных.

Затем вводится понятие ReactPHP — библиотеки, позволяющей выполнять PHP-код асинхронно, подобно Go или Node.js. Эта библиотека не требует сложной установки и позволяет решить проблему блокировки сервера на медленных операциях I/O.

Здесь объясняется архитектура на основе событий, которая лежит в основе ReactPHP. Она предполагает создание бесконечного цикла, который ожидает событий и обрабатывает их. Затем приводится примеры использования таймеров, потоков (streams), обещаний (promises) и дочерних процессов (child processes) в ReactPHP для выполнения различных асинхронных задач, таких как чтение файлов, обработка HTTP-запросов и выполнение внешних команд.

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

Анемичная модель предметной области и логика в сервисах

Анемичная модель предметной области (Anemic domain model) это такая модель, где сущности содержат только свойства, а бизнес-логика находится в сервисах. Ее противоположность это богатая модель предметной области (Rich domain model), где логика находится в сущностях, а cервиcы рекомендуют писать только в редких случаях.

В этой статье показано, почему логика в сервисах является более правильным подходом. Рассмотрим пример бизнес-требований и их реализацию с Anemic domain model.