<rmcreative>

Написал свежий выпуск новостей Yii. Долго их не было, но прогресс, в общем, радует.

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

Писать буду, в основном, на английском. Темы не только технические, а вообще обо всём подряд.

Подписывайтесь

Дмитрий Дерепко из команды Yii выпустил две части Yii overview — серии постов про Yii3.

• Yii3 Overview 1. Вступление
• Yii3 Overview 2. Вспомогательные инструменты разработки

В этом году конференцию сделать было особенно сложно, но мы справились. Получилось не так, как планировали. Наверное, немного лучше:

1. Два зала и два дня вместе с Highload.
2. Несколько раз сменившийся набор тем и докладчиков. Не всё на 100% гладко, но очень и очень достойно. Темы действительно интересные и практически все очень хорошо проработаны.

Приходите послушать 24 и 25 ноября

p.s. промокод на скидку 7% phpspeakers

Вспомнил что давно не обновлял slides.rmcreative.ru.

Добавлены:

• Докладов: 6
• Стримов: 7
• Подкаст: 1

Какие именно можно посмотреть в diff на GitHub

Адель, автор плагина по 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.