Добавление поддержки Криптопро 5.0 в PHP 7.4 в Docker

На практике столкнулся с задачей переноса одного из проектов (приложение на php) в другую ВМ под Red OS.

Но т.к я привык по возможности использовать докер контейнеры, и на этот раз не обошлось без них.

После переноса этого проекта из обычной ВМ на Centos в ВМ на Red OS, не имея широкой экспертизы в приложении выяснилось что там используется Криптопро и нужно внести поддержку в php как модуль php.

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

Читать далее Добавление поддержки Криптопро 5.0 в PHP 7.4 в Docker

Loading

Атрибуты в PHP простое объяснение

Попробуем разобраться в:
Что из себя представляют атрибуты
Какие преимущества от использования атрибутов
Напишем парочку примеров.

Читать далее Атрибуты в PHP простое объяснение

Loading

Настройка xDebug php Docker — PhpStorm (2021)

Каждый раз когда нужно заняться качественным дебагом, каждый раз вспоминаю, как настроить xdebug. Но в этот раз нужно было настроить его через «внешний» интерпретатор PHP, который находился внутри контейнера Docker. Читать далее Настройка xDebug php Docker — PhpStorm (2021)

Loading

Пример асинхронного выполнения блока кода на PHP

Снова заметка с тупым и самым простейшим примером

Читать далее Пример асинхронного выполнения блока кода на PHP

Loading

EventDispatcher

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

Читать далее EventDispatcher

Loading

Пятая буква D в SOLID

Ну и этот принцип, называемый Dependency Inversion приказывает нам зависеть от абстракции, а не от конкретной реализации. Обратимся снова к первой букве, и посмотрим на класс InstagramParser. В конструкторе класса легко видеть, что там нет требования к конкретным реализациям, есть только требование абстракции, то есть реализации данного интерфейса.

Поэтому на вход может подойди любой класс который реализует интерфейс, как например в первом аргументе конструктора InstagramParser с типом IResource.

Как нарушить данный принцип? Укажем в конструкторе InstagramParser конкретную реализацию, например наследника InstagramResource класс ByHastagResource. Вот и все, зависимость получится очень жесткой, как бы опять прибили гвоздями.

Loading

Четвертая буква I из SOLID

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

То есть, допустим, если опять же рассматривать
первую букву из SOLID то мы увидим что мы не создали интерфейс который заставил бы класс,  реализовать как getResource() так и метод handle(). А конкретно разбили зоны ответственности + к нему интерфейс, получилось — ничего лишнего.

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

Много где можно заметить нарушение этого принципа, где вместо реализации метода интерфейса остаются заглушки, метод с пустым телом либо возвращающий null, false, true чисто для заглушки. Вот это и есть немного плохой пример. Но рефакторинг никто не отменял

Loading