<rmcreative>

Адель, автор плагина по PhpStorm для Laravel пишет:

Вообще не понимаю идею генерации changelog из гит коммитов. Она везде проскакивает. Есть даже готовая команда в шаблоне для плагинов от JetBrains. Это для совсем уж ленивых. Текст в коммите - для команды продукта, чтобы было понятно что и как конкретно сделано. Текст changelog - для юзеров. Если юзеры - это такие же php-програмисты, то наверно им будет понятен текст коммитов для юзаемого ими php-пакета.

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

Другой вариант - генерить из тасков багтрекера. Это уже чуть более солидно, так делают сами JetBrains. Пример. Но это тоже для ленивых. Мало кому из юзеров интересно такое читать. Поэтому они делают более user-friendly страницы типа этой - https://www.jetbrains.com/phpstorm/whatsnew/

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

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

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

Именно поэтому в Yii с самого начала писали CHANGELOG руками и просили добавлять строчку для CHANGELOG в pull request. Для повышения осознанности.

Набор принципов GRASP, general responsibility assignment software principles, что переводится как "общие принципы распределения обязанностей", помогает, как следует из названия, правильно выбрать в какой объект или модуль распределить определённую обязанность. Под обязанностью здесь подразумевается знание/хранение информации и/или проведение каких-либо действий.

Принципы сформулированы в 1997 году Крэгом Ларманом в книге "Applying UML and Patterns" (на русском выходила под названием «Применение UML 2.0 и шаблонов проектирования»).

Всего их девять. Четыре основных и пять дополнительных.

Читаем

Что такое PER я уже писал. Если коротко, то это "живой" стандарт, который применяется для постоянно меняющихся тем, на которые всё-таки стандарт какой-то нужен.

Недавно мы тегнули первую версию PER Coding Style. Изначально я был редактором, но из-за февральских событий максимум на что хватило — начать и делать пристальное ревью.

В итоге сейчас стандарт является, по сути, копией PSR-12 с поправленными описками и ошибками. А вот в master-ветке уже есть изменения, учитывающие свежие конструкции PHP, которые войдут во вторую версию.

Нашёл силы составить первый выпуск в этом году.

Несмотря на всё что происходит, разработка фреймворка не остановилась. Мы верим, что OpenSource — это что-то лучшее, что-то что всё ещё может нас объединить, что-то общее. Конечно, темпы разработки сейчас упали, но нам удаётся как разрабатывать Yii3, так и поддерживать Yii2 и Yii1.

Читаем на хабре

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

В этом случае важно:

1. Коммитить в репозиторий composer.lock.
2. Делать только composer install, ни в коем случае не update.
3. Не забывать оптимизировать автозагрузку. Предпочтительней флагом --classmap-authoritative или соответствующей опцией в composer.json.
4. Не забывать флаг --no-dev чтобы не ставить зависимости из require-dev.
5. Указать ту же версию PHP, что используется на сервере, в platform.

Coding Style PER, который заменит PSR-12, официально одобрен PHP-FIG. Работы начаты в https://github.com/php-fig/per-coding-style.

Это первый документ группы согласно PER, то есть «живой» стандарт. Его не будут заменить каждый раз при добавлении нового синтаксиса в PHP. Вместо этого пакет правки будут релизиться по SemVer.

Форсировать линуксовое окончание строк LF вместо CRLF из Windows полезно потому как тот же Docker CRLF очень не любит. Настраивать локально что-то не очень приятно, поэтому просто замечательно что есть возможность форсировать это для всей команды средствами git.

1. В корне репозитория создаём .gitattributes, пишем туда * text=auto eol=lf первой строкой.
2. Делаем коммит с этим изменением, пушим.

Собственно, всё. Осталось локально себе сконвертить всё в LF. В этом также поможет git:

1. git rm --cached -r .
2. git reset --hard

На хабре проскачила неплохая статья, показывающая плюсы работы на «галерах», то есть в аутсорсе и аутстаффе.

Я был и там и там. Да, есть галеры где неплохо, но:

1. Срок жизни «галерного» проекта слишком мал, чтобы увидеть самые фатальные свои косяки. Они достанутся кому-то ещё, а вы будуете думать что решение было норм.
2. Главная метрика любого проекта галеры — клиент доволен. Это сказывается практически на всём.

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

Пожалуй, пора подвести итоги года. Получился он не менее напряжённым, чем 2020-й. Сначала даже хотел написать "выжили и ладненько", но вспомнил что интересного тоже было много.

Читаем

Ура! Релизнулся.

• Почитать про новые фичи можно на красивом лендинге.
• Посмотреть стрим по случаю релиза.