Скоро браузеры будут заметно подвисать при загрузке новости об очередном минорном релизе Symfony 😅

Встречаем 5.1.0-beta1 🎊

Что можно делать с beta-релизом?

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

Во-вторых, если у вас есть проект на 5.0 и немного свободного времени, можете обновить его в отдельной ветке, прогнать тесты, составить баг-репорты и предложить фиксы. К сожалению, Symfony не пользуется инструментами статического анализа, поэтому иногда можно напороться на что-то вроде Call to a member function X on null и прочую дичь. Также можно встретить нарушения обратной совместимости, их обязательно поправят перед релизом. Перед созданием issue желательно убедиться, что её ещё не зарепортили и не пофиксили, но при прочих равных лучше создать дубликат, чем не написать вообще.

Поговорим про удаление.

В общем случае я рекомендую придерживаться совета Udi Dahan и ничего не удалять. В слабосвязных системах, где сущности ссылаются друг на друга по идентификатору, удаление нарушает связи и историю, усложняет восстановление в случае ошибки. В сильносвязных системах, где сущности явно ссылаются друг на друга (например, через @ORM\One|Many...), удаление ещё и ставит под вопрос глубину каскадных операций в различных сценариях. Например, при удалении автора можно стереть все его блоги и посты, но при удалении поста в блоге вряд ли вы ожидаете исчезновение автора.

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

Альтернатива? Пользуйтесь техникой мягкого удаления, флагом "в архиве", датами активности и т.д. Да, придется добавить соответствующие условия в некоторые запросы, скорректировать индексы (см. PostgreSQL Partial Index). Да, вырастут в объеме хранилища, хотя в наше время это копейки. Но всё это не сравнится с болью восстановления данных, удалённых по ошибке.

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

Про удаление в системах с Event Sourcing рекомендую посмотреть фрагмент доклада David Schmitz.
Про чистку в распределённых системах можно почитать в статье инженера Twitter.
Обе ссылки из чата @symfony_php.

Проект Happy Job, где я занимаюсь проектированием и разработкой бэкенда,  — это в первую очередь аналитика.
А какая аналитика без выгрузок в Excel 😉

Раньше я всегда использовал библиотеку PHPOffice/PhpSpreadsheet (бывший PHPOffice/PHPExcel). Она предоставляет почти полный инструментарий для работы с таблицами, но есть один большой минус — формирование листа по умолчанию происходит в памяти. Одна ячейка вместе с метаданными весит примерно 1 Кбайт, поэтому выгрузка лишь 400 000 строк в три колонки уже обойдется более чем в 1 Гбайт памяти. В библиотеке предусмотрена возможность кэшировать ячейки на базе PSR-16, но это значительно снижает скорость записи.

Для нашего кейса я нашёл решение получше. Куда менее популярная библиотека box/spout позволяет читать Excel-файлы и писать в них построчно и очень быстро. Расход памяти константный из коробки, без всяких плясок с кэшем (по факту она, конечно, создает какие-то временные файлы в sys_get_temp_dir()). Пакет тоже поддерживает листы и типы данных, но не умеет в автоширину, объединение ячеек и продвинутое форматирование. Я уверен, что как и для нас, для большинства проектов это приемлемый компромисс.

Stay tuned! В следующем посте я расскажу, как удобно стримить данные в браузер в формате Excel средствами Symfony HttpFoundation.

Писал-писал я про интеграцию вышеупомянутой Box Spout в Symfony и написал целую статью 📰🤓

Из неё вы узнаете, как стримить Excel напрямую в браузер и как вынести повторяющийся код в сервис, чтобы получить лаконичный экшн следующего вида:

return $factory->createResponse('report.xlsx', static function (Writer $writer) use ($report): void {
    $writer->getCurrentSheet()->setName('Степени чисел');
    $writer->addRow(WriterEntityFactory::createRowFromArray(['Число', 'В квадрате', 'В кубе']));

    foreach ($report as $values) {
        $writer->addRow(WriterEntityFactory::createRowFromArray($values));
    }
});

В Psalm версии 3.11.0 и выше можно использовать @psalm-trace $var для отладки типа переменной.

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

Очень классный канал с маленькими тестами по PHP для поддержания тонуса 🥭

https://t.iss.one/phpquiz

Аргумент "непустой индексный массив строк" на чистом PHP и с использованием Psalm:

function native(string $name, string ...$names): void
{
    foreach ([$name, ...$names] as $name) {
        // ...
    }
}

/**
 * @psalm-param non-empty-list<string> $names
 */
function psalm(array $names): void
{
    foreach ($names as $name) {
        // ...
    }
}

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

Если аргументы объявляются при вызове, я советую использовать оператор ... Например, в билдере SQL запросов колонки удобнее передавать аргументами:

$db
    ->select('respondent_id', 'value')
    ->from('evaluation')

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

​В эту субботу в 11:00 пройдёт 3-й виртуальный PHP-митап.

Представлены 5 интересных докладов, в том числе "Psalm не предлагать: малоизвестные инструменты статического анализа кода" от Александра Новикова из Spiral Scout.

Сразу после выступления мы с Кириллом Несмеяновым встретим вас в дискуссионной Zoom-комнате для обсуждения нюансов статического анализа и предложим вам Psalm.

Всех ждём 😉

https://meetups-online.ru/php-may-2020

Если вы используете PostgreSQL и Doctrine DBAL на чтение и вам нужно получить text[] как массив PHP, то не стоит писать свой PgTextArrayType.

Проблема в том, что select array['a', 'b'] PostgreSQL возвращает как '{a,b}', а select array['a', 'b c'] как '{a,"b c"}'. Очевидно, что explode(',', trim($value, '{}')) тут не работает. Более-менее корректный парсинг выглядит монструозно и стоит дорого. При этом от массивов в запросах отказываться тоже не хочется, так как работать с ними зачастую очень удобно.

Предлагаю простое и эффективное решение: select array_to_json(array['a', 'b c']). Мудрёный парсинг тут не нужен, PgTextArrayType тоже писать не надо — можно использовать родной JsonType.

Слайды Никиты Попова What's new in PHP 8.0? с конференции PHP fwdays 2020.

https://twitter.com/nikita_ppv/status/1269706258300506114

Приглашаю обсудить в нашем чате.

Подведу итоги прений.

Однозначного ответа конечно же нет, есть ±, компромиссы и предпочтения 🤪

Вариант с передачей по ссылке:
➕ немногословный;
➕ менее затратный по ресурсам;
➖ вызов $this->processByReference($value1, $value2) при чтении не выглядит как мутация переменных, это затрудняет ревью и поддержку;
➖ передача по ссылке — побочный эффект для контекста вызывающей функции.

Вариант с возвращением кортежа:
➖ более многословный (хотя выглядит все равно опрятно);
➖ потребует дополнительную память на массив (но разговоры про это пахнут нанооптимизацией);
➕ строка [$value1, $value2] = $this->processAndReturnTuplet($value1, $value2) говорит сама за себя — я преобразую значения этих переменных;
➕ передача значений копированием оставляет нам шанс написать чистый (pure) метод.

Ещё было предложено возвращать объект, но это, по сути, частный случай второго варианта. Персональный тип для результата приватного метода избыточен, с @psam-return array{string, int} Psalm и без него отловит все ошибки.

Всем спасибо за обсуждение!
Я выбираю второй вариант с кортежем, так как поддерживаемость и прозрачный control flow перевешивают 😉

Если кто-то вдруг пропустил, вчера команда JetBrains запустила информативный и красивый таймлайн развития PHP в честь 25-летия языка.

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

Интересно пронаблюдать, как соотносятся во времени различные события. Например, Дмитрий Стогов присоединился к Zend незадолго до запуска Facebook, а Composer появился гораздо позже, чем большая часть фреймворков.

Ну и конечно не забывайте про скидку 50% на PhpStorm, она действует ещё целый день 😉

https://www.jetbrains.com/lp/php-25/

Задачка от меня на канале PHP задачи с собеседований с пояснением к решению.

https://t.iss.one/phpquiz/222

Однажды я услышал, что геттеры — это плохо.

И прошел все этапы реакции по Кюблер-Росс: отрицание, злость, торг, депрессию, принятие 😂
Надеюсь, этот пост поможет пропустить несколько стадий.

DTO. Если тело геттера return $this->privateProperty, заменяем его публичным свойством с аннотацией @psalm-readonly-allow-private-mutation или @psalm-readonly или объявляем весь класс @psalm-immutable. Так мы обеспечиваем инкапсуляцию да ещё и нанооптимизируем код (-N вызовов геттеров). Метод без каких-либо манипуляций не имеет смысла — это 4 строки визуального долга и 1 строка для покрытия тестами.

Кстати, я тут заметил, что геттер — это трюк. К существительному добавили глагол, чтобы удовлетворить фомуле subject.actionVerb(?object). Вот только get — это не предоставить, а получить. То есть мы не просим объект поделиться состоянием, мы его отбираем.

Value Object. Если метод представляет собой query по CQS и возвращает некоторое представление (проекцию) объекта, то его название не должно быть шаблонным, оно должно отражать семантику. Например, Birthday::format(string $format): string, Color::toHex(): string.

Entity. Стараемся применять принцип Tell-Don't-Ask. Попробую сформулировать по-своему. Объект — это состояние + поведение. Если мы программируем объектно-ориентированно, мы должны просить объект совершить действие над принадлежащим ему состоянием, а не отбирать у него состояние и выполнять действие за пределами этого объекта. Если программируем не объектно-ориентированно (что тоже ок), то объекты по определению не используем и геттеры, соответственно, тоже.

---

Итак, в DTO вместо геттеров используем публичные свойства. В Value Object — семантические query методы, и то, если не добавлять "на всякий случай", их будет немного. В Aggregate Root оставляем только command методы.

Как тогда вывести состояние модели? Рассудим логически. Для вывода состояния поведение не нужно, нужно только состояние. Значит и сама модель для этой задачи не нужна. В простом случае состояние можно запросить напрямую из хранилища и выдать сразу без всяких ORM: echo json_encode($pdo->query('select x1, x2 from y where z = ?')->fetch()). В более сложном случае можно посмотреть в сторону Event Sourcing, но про это как-нибудь в другой раз 😉

Открытое собеседование — ищем участников

Бывало, засидишься на одном месте и не знаешь, актуален ли ты еще на рынке... Хотя бы какие там тренды? Что спрашивают-то сейчас вообще на собеседованиях?

Вот и решили с Романом Пронским провести публичное онлайн-собеседование с вопросами на актуальные темы мира PHP.

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

Собеседование будет проходить в режиме стрима в теплой обстановке, примерно как на видео, только я буду без усов 😂

Требования для участия:
• уровень middle/senior;
• PHP 7.x, Composer, PSR;
• ООП, SOLID, coupling/cohesion, вот это все;
• тестирование, PHPUnit;
• желателен опыт с Symfony 4/5;
• SQL, желательно PostgreSQL;
• представление о современных трендах в архитектуре приложений.

Заявки на участие можно отправить до 8 июля через форму: https://forms.gle/ES3nXiwf4ycosGEy9.

Вопросы в личку: @vudaltsov, @pronskiy.

Эффективное проектирование агрегатов

Эссе Вона Вернона в трёх коротких частях, которое поможет с пониманием паттерна агрегат.

Прочитав его, вы получите ответы на следующие вопросы:
• как и зачем проектировать маленькие агрегаты;
• что такое истинные инварианты и как их искать;
• почему Value Object предпочтительнее, чем Entity;
• когда нужна мгновенная (immediate), а когда конечная (eventual) согласованность;
• когда позволительно изменять несколько агрегатов в одной транзакции.

По сути, это квинтэссенция нескольких важных глав из синей и красной книги по DDD.

https://dddcommunity.org/library/vernon_2011/

Иерархические структуры в реляционных СУБД

На этой неделе разгребаю в проекте разные тудушки, поэтому больше читаю и обдумываю, чем пишу код 😂

Вот вам цикл из двух статей, в которых автор сравнивает три подхода к хранению иерархических структур в реляционках:
• список смежных вершин (adjacency list),
• материализованный путь (materialized path),
• вложенное множество (nested set).

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

В конце первой статьи есть раздел про комбинирование подходов. Особенно удобно комбинировать на проектах с CQRS: списки смежных вершин на запись и списки + материализованные пути на чтение.

https://habr.com/ru/post/46659/
https://habr.com/ru/post/47280/

Забавно. В первой статье есть примеры на Doctrine 1, и они безбожно устарели. Но основной материал будет актуален ещё долго...