CodeWay — Путь кода
17 subscribers
30 photos
22 videos
8 files
16 links
Здесь пишут о разработке на PHP, Laravel и всём, что с этим связано.
Автор канала — веб-разработчик Алексей Васильев.
Download Telegram
Когда пригодятся типы-перечисления

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

Вот пример перечисления для цветов светофора. Кроме как "красный" (TrafficLightColor::Red), "жёлтый" (TrafficLightColor::Yellow), "зелёный" (TrafficLightColor::Green), ничего выбрать невозможно. Это может быть очень удобно.

<?php
enum TrafficLightColor
{
case Red;
case Yellow;
case Green;
}
?>

Теперь поясню подробнее.
В разработке то и дело приходится иметь дело с такими специфическими данными, типа статусов. Каково может быть состояние письма, например? "Подготовлено", "Отправлено", "Не удалось отправить". Четвёртого не дано. Или, как вариант, источники данных для приходящих картинок. Вряд ли их будет даже десять. И вот что со всем этим делать?

Глобальных проблем тут две: валидация и понимание происходящего.

По поводу валидации. Если мы храним значения перечислимого типа как строки или числа, мы вынуждены каждое приходящее в соответствующую переменную значение проверять — укладывается ли оно в наше перечисление? А что, если просто случайно совпало, а строка/число означает совсем другое? Обычная проблема использования скалярных типов не по назначению. В таких случаях переходят к ValueObject-ам (в которых и пишется валидация), но Enum-ы куда удобнее для работы с перечислениями.

Что же касается понимания, то трудности здесь схожие. Мы не можем круглосуточно помнить, что эта строка (или число) соответствуют элементам ограниченного множества, и в один прекрасный момент туда обязательно попадёт что-то не то — хотя бы из-за опечатки.

<?php
const MAIL_STATUSES = ['prepared', 'sent', 'sending_failed'];
//...
$result = Mail::send($letter);
if($result->status == 'send') { // Всего одна буква разницы, а условие уже работает неправильно
return response()->json(['message'=>'Письмо отправлено']);
} else {
return response()->json(['message'=>'Ошибки при отправке']);
}

И вот, почта уходит, а сообщение говорит об обратном. Были бы эти статусы вариантами Enum, то даже редактор уже ткнул бы разработчика в ошибку, указав, что такого варианта нет.

Вместо вывода: если вы уже перешли на PHP 8.1 и работаете с подобными значениями из ограниченного списка, присмотритесь к Enum.
К вопросу о доступе

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

В конечном счёте, мы должны уметь отвечать на такой вопрос: может ли пользователь с такими-то данными сеанса выполнить такое-то действие? Что делать в случае отрицательного ответа — вопрос вторичный и зависит от требований заказчика. Чаще всего либо ставится редирект на другую страницу (главную, например), либо отдаётся 403 статус/страница ошибки с указанием, что не так.

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

1. Авторизован ли пользователь.
Самая простая и понятная тема. Такая проверка присутствует если не на всех сайтах, то на 99% точно. Например, может быть закрыта страница профиля или возможность комментировать без авторизации.

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

3. Относится ли пользователь к определённой группе (имеет определённую роль).
Такое применяется на более сложных сайтах, где много пользователей с разными правами (user, manager, admin). Подобная система требует заведения дополнительных таблиц в БД и модуля контроля/изменения принадлежности пользователя к группе. Возможно, его придётся написать. Даже если этот модуль берётся готовым, он требует настройки путём указания ответов на такие вопросы:
- Может ли быть у пользователя больше одной роли?
- Как именно назначаются первые роли?
- Кто вправе менять/добавлять роль пользователя и по каким правилам?
- Какая логика должна выполняться при изменении/добавлении роли?

4. Имеет ли пользователь определённое разрешение?
Это ещё более сложная история. Разрешения делаются максимально дробными (буквально, отдельное на каждое возможное действие) и заводятся в виде отдельных сущностей. Чаще всего система разрешений соседствует с системой групп. Например, разрешения привязываются к группам, и список тех разрешений, которые есть у пользователя, получаются на основе списка групп, в которых он состоит. Но встречаются такие случаи, когда сверх разрешений по группам пользователю могут выдаваться ещё какие-то персональные, и их тоже надо учитывать при контроле доступа.

5. Соответствуют ли данные запроса некоторым требованиям?
Я здесь имею в виду метаданные — IP-адрес, заголовки, куки и тому подобное. Например, определять страну или регион по IP-адресу и редиректить на соответствующий раздел (ну или показывать, что в тех местах мы пока не работаем).

Если вы знаете ещё о каких-то проверяемых при контроле доступа условиях, напишите об этом в комментариях.
👍1
ArchDays Recap: впечатления от митапа

Митап прошёл в очном формате 27 июля в БЦ "Академик" на проспекте Вернадского. Я присутствовал там лично и хочу поделиться впечатлениями.

Финальная программа митапа выглядела примерно так:

1. Алексей Маликов. О чём я не думал три года назад. (в докладе о распиле монолита)
2. Сергей Баранов. Многоликий DDD.
3. Евгений Пешков. Про агрегаты.

Митап был задуман как нечто, идущее "по следам" прошедших конференций по архитектуре ArchDays. Собственно, это было заложено в самом названии: Recap означает "резюме, краткое повторение". И замысел этот очень сказался на двух докладах из трёх (1-м и 3-м), что в моём случае было скорее к худшему. Ведь конференций я в глаза не видел, а просто заинтересовался мероприятием самим по себе. Потому ценность третьего выступления, на мой взгляд, была сильно ниже — Евгений только ответил на частый вопрос из поступавших ему после прошлого выступления (про границы агрегатов — я бы назвал их классами сущностей), после чего предложил задавать новые. Хотя мысль о том, что в классе-агрегате в первую очередь надо обращать внимание на консистентность данных, потом на читаемость кода, и лишь потом на производительность, прозвучала очень ясно и я отметил её для себя.

Первое выступление, несмотря на его "производность" от другого, трёхлетней давности, вышло более целостным. Красной нитью в нём прошла главная идея: архитектура кода (и вообще IT-системы) — это не вещь в себе, она должна помогать бизнесу решать его задачи. Притом она ещё и имеет обыкновение быстро устаревать.

Доклад Сергея Баранова на фоне других выглядел подлинным "основным блюдом" и мог бы украсить любую подходящую конференцию. Докладчику удалось полноценно погрузить аудиторию в одну из практик DDD (Domain Driven Design) — ивент-шторминг. Про DDD мои представления пока довольно поверхностны и ограничиваются минимальной теорией, так что мне было интересно лучше узнать детали этой концепции. Если вкратце, то ивент-шторминг — это некое собрание бизнес-экспертов с техническими с целью выработки общего понимания бизнес-процессов компании. Максимально простым и понятным способом, буквально на стикерах. События, команды и правила пишутся на стикерах разных цветов, образовывается большая карта деятельности бизнеса, которая затем делится на ряд ограниченных контекстов (термин DDD). Хорошее понимание системы приносит пользу буквально каждому участнику IT-процессов, от тестировщика до CIO (IT-директора). Сергей отдельно остановился на том, в чём именно эта польза заключается для того или иного специалиста.

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

#code_way #archdays_recap #ddd
Ряд фотографий с ArchDays Recap
Зачем писать консольные команды

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

Этот пост я разделю на две части: собственно, "зачем" и "как". Для начала поговорим про "зачем". В части "как" (в следующем посте) будет пример написания простой консольной команды для Laravel — как вы помните, я специализируюсь именно на этом фреймворке. Общие идеи будут вам полезны в любом случае, за деталями обратитесь к документации своего фреймворка.

https://telegra.ph/Zachem-pisat-konsolnye-komandy-08-16

#php #laravel #консоль
Как писать консольные команды

Зачем всё это нужно, мы рассмотрели в предыдущем посте, теперь перейдём к техническим деталям.
Разумеется, вам пригодится документация по консольным командам для вашего фреймворка. Например, для Laravel её можно найти тут:
https://laravel.com/docs/9.x/artisan.

Начну с общих замечаний, которые могут быть вам полезны в любом случае.
1. Консольная команда — это класс, а выполняться будет определённый метод этого класса. Соответственно, применимы все принципы ООП, о которых вы только могли подумать. Например, можно вынести отдельные части функционала в другие методы и вызывать из основного. Зависимости, определённые в контейнере, тоже вполне можно интегрировать привычным способом.
2. Всё, относящееся к специфике консольной команды, описывается в ней же. Я имею в виду, текстовое описание, аргументы и тому подобное.
3. Никакие специфически браузерные вещи (определение каких-то параметров через куки или заголовки) не будут доступны.

Теперь приступим к написанию примерной консольной команды. Для генерации начального кода в Laravel понадобится выполнить такую команду:
php artisan make:command {имяКлассаКоманды}
после чего в папке app/Console появится файл примерно следующего вида:
https://github.com/codewayblog/console1/blob/df4f9d0181f320c4d586f9dc000085d625724b8a/SomeCommand.php

Естественно, мы должны знать, какую цель преследует наша консольная команда, и назвать её соответственным образом. SomeCommand я выбрал просто для примера. Предположим, мы хотим собирать некоторую статистику сделок данного пользователя и посылать её ему на почту. Предположим также, что такой функционал у нас уже есть, но вызывается самим пользователем из графического интерфейса. Вот наш примерный файл с операцией:
https://github.com/codewayblog/console1/blob/main/SendUserOrderStats.php
Всё, что ему нужно — наличие действительного пользователя. Отлично, теперь можем заняться классом команды.

Для начала укажем описание в свойстве $description
Отправляет сводные данные по последним сделкам пользователя
и заголовок команды в свойстве $signature
send:order_stats {user}
Первая часть до пробела — то, как мы хотим вызывать команду, затем в фигурных скобках — параметр, данные пользователя, которые нам нужны. Не будем мудрствовать лукаво и станем исходить из email — как-никак, самое универсальное поле.

В конструктор ничего не будем добавлять, наше внимание сосредоточится на методе handle(), который и будет в конечном счёте вызываться.
Когда у нас будет e-mail, то останется только написать:
$user = User::where('email', $email)->first();
if($user instanceof User) {
$action = new SendUserOrderStats($user);
$action->execute();
}
... и дело в шляпе. Ну ладно, надо будет добавить пару информационных сообщений — об успешности операции или об отсутствии пользователя, но идея такая. Добавим этот код в handle().
IDE начинает ругаться на то, что $email не инициализирован. Разумеется, мы должны получить его из аргумента команды.
$email = $this->argument('user');
Вот в таком виде
https://github.com/codewayblog/console1/blob/c5f8b9aec83437c4502d732d8b1cf7732c2f1ace/SomeCommand.php
код уже будет работать. Осталось его немного облагородить.

Добавляем необходимые сообщения, и наша консольная команда готова.
https://github.com/codewayblog/console1/blob/main/SomeCommand.php

Запускать её надо будет примерно так:
php artisan send:order_stats test@test.com

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

#php #laravel #консоль
👍1
Некоторые особенности MongoDB

На одном из проектов, с которыми я работаю, основной базой данных стала MongoDB. Я хочу поделиться некоторыми наблюдениями, они будут полезны для тех разработчиков, которые пока не имели дела с Монго.

1. Коллекции.
Базы данных в MongoDB делятся не на таблицы, а на коллекции — по сути дела, одномерные массивы данных, состоящие из отдельных записей.

2. Формат данных.
Каждая запись в коллекции — это JSON-документ. Формально его формат называется BSON, но с точки зрения работы с ним разницы никакой, можете считать, что это JSON. Со всеми вытекающими из этого последствиями — совершенно произвольный набор полей (что положите, то и будет) и произвольной же вложенностью. Подчинённые данные для элементов удобно хранить как раз в таких вложенных наборах — к примеру, ссылки на посты, связанные с текущим.

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

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

5. Поиск.
В поиске тоже есть своя специфика. Например, запрос на выборку, обращённый напрямую к БД, тоже задаётся в виде JSON. Например, такая запись
{post_id: 4},
или в полном виде
db.comments.find({post_id: 4}),
равносильна SQL-запросу типа
SELECT * FROM `comments` WHERE `post_id` = '4'.
Также MongoDB по умолчанию не делает никакой разницы между полем со значением NULL и отсутствующим в этой записи вовсе, потому запрос
{category: null}
отбёрет не только те, у которых поле category содержит null, но и те, в которых нет такого поля. Различить их можно, применяя специальные операторы.
Так, запрос
{category: {$type: 'null'}}
выберет только category = null,
а запрос на существование
{category: {$exists: false}}
вернёт все записи, где нет поля category.

Вообще, MongoDB — это довольно интересная система, советую поизучать её практически. А я на сегодня закончу, оставив напоследок ссылку на документацию по БД: https://www.mongodb.com/docs/.
👍2
Как работают очереди в Laravel

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

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

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

Как произвести первоначальную настройку проекта
Для начала нам нужен драйвер очередей, он указывается в файле config/queue.php (пример моего файла тут: https://github.com/codewayblog/laravel-queues-how/blob/master/queue.php), также в .env-файле стоит указать дефолтный драйвер (ключ QUEUE_CONNECTION). Вот мой env-файл: https://github.com/codewayblog/laravel-queues-how/blob/master/.env. Как видите, я использовал RabbitMQ. Он нуждается в отдельной настройке, но для пробы можно обойтись базой данных (драйвер database).
Подробнее о настройке драйверов очередей можно почитать в документации Laravel: https://laravel.com/docs/9.x/queues#driver-prerequisites.

Как создать класс задания
Выполним консольную команду php artisan make:job {имя-класса}. В папке app/Jobs создатся шаблонный класс с указанным именем и методом handle(). В конструкторе привязываем в класс данные, которые нужны для выполнения задания, в методе handle() — ту логику, которая нужна для собственно выполнения. Стоит учесть, что выполняться задача будет в консольном режиме, поэтому всякие браузерные штуки будут ей недоступны — их надо зашить ещё в момент создания.
Пример класса задания: https://github.com/codewayblog/laravel-queues-how/blob/master/SomeJob.php

Как вызвать задание в нужном месте
Обращаемся к статическому методу dispatch() класса команды. Передаём туда все те же аргументы, которые требуются в конструкторе — они будут туда проброшены внутри dispatch().
Пример вызова: https://github.com/codewayblog/laravel-queues-how/blob/dfeae6f24ce66a7aad1e99562e987b9c17aef376/MainController.php#L17

Как работает процесс обработки заданий
Во время вызова класс задания создаётся, сохраняет нужные данные и сериализуется. В таком упакованном виде задание помещается в очередь (как именно, зависит от драйвера очередей) и там ждёт своего часа.
Обработка заданий запускается с помощью команды php artisan queue:work. В цикле обработчик забирает задание, распаковывает его обратно в экземпляр класса, и вызывает метод handle().

Так в общих чертах устроены очереди в Laravel. Интересный и нужный функционал, на мой взгляд.
👍1
Выступаю на PHP Russia 2022

Про выступление
Мой доклад называется "Модульный Laravel, или как собрать фичу в кучу". Он принят в секцию "Митап" и по предварительным данным выступать я буду 25 ноября с 17 часов. Сама конференция будет на сей раз совмещена с Highload++ (просто в разных залах выступления планируются) и назначена на два дня: 24 и 25 ноября. Цены, к сожалению, уже кусаются. 60 тысяч за очное участие. Но лично я считаю, что посетить конференцию будет крайне полезно.

Тезисы доклада
1. Структура файлов, генерируемая при создании Laravel-проекта, проблематична для проектов сложнее набора CRUD-ов. Файлы складываются по типам, и при работе с одной фичей приходится перелопатить несколько папок. Необходимость частичного выделения функционала в отдельный сервис превращается в головную боль.
2. Предлагается новый feature-based подход, основывающийся на группировке кода и шаблонов по фичам. Изначально это про структуру хранения вашего кода.
3. Для реализации этого подхода создана библиотека, о которой речь также пойдёт в выступлении. Это как раз та самая, которую я упоминал в предыдущих постах (https://packagist.org/packages/garmonic/laravel-features-arch, а пост про создание composer-пакета тут: https://t.me/code_way/10).
4. Приведя в порядок структуру файлов, можно пойти дальше и реализовать на базе той же библиотеки полноценную функциональную модульность — такую возможность она тоже даёт.

Есть шанс, что видеозапись будет, но гарантии нет. Так что лучше приходите живьём.

Полезные ссылки
Весь список докладов: https://highload.ru/moscow/2022/abstracts
Билеты: https://highload.ru/moscow/2022#prices
Расписание конференции в текущем виде: https://docs.google.com/spreadsheets/d/1-S-wRL2xMQOTpmOvY9kHuzYq-Gaj33Z-UVrSf9mqRyA/edit#gid=6132978

#php #laravel #конференция #митап #phprussia #phprussia2022
Forwarded from PHP Russia Channel
Про модульный Laravel, или как собрать фичу в кучу расскажет Алексей Васильев

📋 https://bx.vc/h9k0pd

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

Предлагается новый feature-based-подход, основывающийся на группировке кода и шаблонов по фичам.

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

Приведя в порядок структуру файлов, можно пойти дальше и реализовать на базе той же библиотеки полноценную функциональную модульность — такую возможность она тоже даёт.

🖐 Ждем вас 24 и 25 ноября в Москве

Программа конференции и билеты здесь - https://bx.vc/wsgiyp
По горячим следам PHP Russia

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

Ждите обновлений — будут по крайней мере краткие отзывы на все доклады, где я был и рассказ о моём собственном выступлении.

#phprussia #phprussia2022
Доклады первого дня конференции
(по следам PHP Russia 2022)

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

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

2. Доклад Александра Лисаченко
"Виртуализируй меня... полностью!"
Пока недостаточно разбираюсь в Docker/Kubernetes, но было любопытно. Стоит покопаться в этой теме. В основном речь шла о тонкой настройке Docker и Kubernetes с использованием специального синтаксиса.

3. Доклад Валентина Удальцова
"ID-баттл: UUID vs автоинкремент"
Понятная проблема, полезное сравнение разных вариантов идентификаторов. В итоге получилось, что в зависимости от задачи можно использовать UUID v.7 или автоинкремент (который не так плох, как может показаться. Я пока UUID толком не использовал, может, и зря.

4. Доклад Александра Володина
"Апгрейд и рефакторинг PHP-проектов — теперь это просто"
Получилось очень харизматично и весело 😀 Докладчик — адепт Rector и активно продвигал использование этого инструмента (пожалуй, даже слишком активно). Но даже если отбросить фанатизм, Rector — реально полезная вещь.

5. Доклад Александра Кирсанова
"Честные модули внутри монолита, или Когда Composer не подходит"
Классный доклад про новое решение команды VK — Modulite. Средства PHP не позволяют изолировать отдельные классы, Modulite помогает это реализовать (путём добавления плагина для PHPStorm и новых инструментов в CI/CD). Полезная вещь для многих разработчиков.

6. Доклад Валерия Горбачёва
"Хождение по граблям PDO"
Захватывающее повествование о неочевидных особенностях работы PDO с разными движками БД (при всей универсальности PDO они таки есть). Очень разнообразный опыт докладчика, интересно было прикоснуться к нему.

7. Доклад Петра Мязина
"Интеграция PHP-проекта с 1С"
Познавательное выступление, особенно в связи с обращениями к 1С по Rest API и HTTP-сервисам стороны 1С. У нас на проекте тоже есть синхронизация с 1С, но работает она по старинке, через XML-файлики. Кстати было узнать, что можно и по-другому.

Далее будет про второй день PHP Russia, как и обещал. Скорее всего, пост выйдет сегодня или завтра.

#php #phprussia #phprussia2022 #HighLoadMoscow2022
1
🗓 Доклады второго дня конференции
(по следам PHP Russia 2022)

1. Доклад Сергея Тарасова
"Как мы приготовили массу блюд с помощью одного ингредиента: GraphQL"
GraphQL — интересная технология, стал немного лучше понимать её и для чего она нужна. И рассказано было хорошо, довольно легко для восприятия.

2. Доклад Рамазана Рамазанова
"Почему PHP такой дырявый"
Многие уязвимости, упомянутые в выступлении, и советы по избежанию их очевидные, но всё-таки важно поднимать тему безопасности — об этом в пылу разработки часто забывают. И правильно спикер отметил, что фреймворки — тоже не панацея.

3. Круглый стол
"Domain Driven Design и PHP: идеальная пара или натягивание совы на глобус?"
Краткое, но содержательное погружение в тему DDD. Шутки про отсутствующий собственно стол тоже очень оживили обстановку. Отдельно отмечу присутствие эксперта из мира C# Алексея Мерсона — это расширило контекст обсуждаемых проблем.

4. Доклад Ивана Красникова
"Безболезненная подгрузка миллионов товаров с сотен интернет-магазинов на PHP"
Интересный опыт спикера, уверен, что доклад был полезен всем, кто работает с различными большими выгрузками, товарными в особенностями. Если будем заводить ElasticSearch, точно стоит вспомнить основные положения.

5. Доклад Ивана Лещёва
"Фича — это объект! Сокращаем диффы, снижаем каплинг, продлеваем жизнь"
Свежий и довольно бескомпромиссный взгляд на фичу и организацию кода. Есть, о чём задуматься с точки зрения архитектуры кода.

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

#php #phprussia #phprussia2022 #HighLoadMoscow2022
👍2
Мой доклад на PHP Russia: как это было

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

Сам же текст получился большим, милости прошу в Telegraph: https://telegra.ph/Moj-doklad-na-PHP-Russia-kak-ehto-bylo-12-03