<rmcreative>

Написал свежий выпуск новостей и выложил на хабр. Дело движется. До релиза дожмём.

Читаем

Уже который год мне среди issue и тикетов встречаются такие, из прочтения которых вообще не ясно, в чём, собственно, проблема. Чтобы вас поняли нужно соблюсти следующие пункты:

1. Что вы делаете? Важно описать точный набор шагов, следуя которым можно воспроизвести проблему. Стоит помнить, что вашего проекта у разбирающего issue нет.
2. Что получаете?
3. Чего ожидаете?
4. Почему это проблема? Важный пункт. Описываем, почему мы ожидаем того что ожидаем и на что это влияет. Здесь важно показать не только что, допустим, из класса BaseService вернётся true вместо false, но и что это значит с точки зрения конечного пользователя.
5. Не предлагать решение. Для этого есть pull request или комментарии.
6. Не пытаться описать более одной проблемы за раз.

В мае я рассказывал про OpenSource и отвечал на вопросы для Вастрик Клуба. Получилось вроде интересно.

Посмотреть на YouTube

И ещё одна новая тема. На этот раз "Code Review". Запись сделана на мипапе компании ЭФКО в Воронеже.

Посмотреть на YouTube

Новая для меня тема выступления, "Тестирование приложений". Запись сделана на мипапе компании ЭФКО в Воронеже.

Посмотреть на YouTube

Совсем недавно Георгий Могелашвил запустил интересный проект, GetMentor. Это открытое сообщество IT-наставников, готовых делиться знаниями и опытом.

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

Оставить заявку можно на специальной странице

// Да, знаю что ценник не совсем гумманный вышел, но по-другому пока никак. Почти всё доступное время занял Yii 3, который я очень и очень хочу выпустить.

Несмотря на то, что Yii 3 релизнут далеко не полностью, уже есть компании, которые его используют в продакшне. Чтобы получить  больше обратной связи и одновременно поддержать уже использующие Yii 3 компании, мы запускаем пред-релизную бесплатную поддержку в форме чатов между компаниями и командой фреймворка. Будем отвечать на любые вопросы по фреймворку, собирать пожелания и критику.

Если хотите для своей компании такой чат — пишите в Telegram @samdark, добавим.

В замечательном чате Валентина Удальцова «Пыхтелка» заметили релиз одной из библиотек Yii 3, Rate limiter и предложили вполне справедливые улучшения. kafkiansky сделал pull request, в который кроме, собственно, улучшений попало одно очень интересное изменение: вместо геттеров-сеттеров сделать свойства класса CounterState публичными и добавить на класс аннотацию @psalm-immutable:

/**
 * @psalm-immutable
 */
final class CounterState
{
    public int $limit;
    public int $remaining;
    public int $resetTime;
    public bool $isLimitReached;

Почему так:

1. Используется статический анализ через Psalm.
2. @psalm-immutable не даст присваивать что-либо этим свойствам, если его добавить в continuous integration.
3. В будущем легче будет мигрировать на read only properties.
4. Никакой логики здесь нет, это plain object. С аннотациями меньше кода.

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

1. Мы не контролируем то, как пакет используется.
2. Мы не можем гарантировать, что будет использоваться именно Psalm, что он будет запускаться в процессе CI, что вообще будет использоваться хоть какой-то статический анализ.

То есть полагаться на статический анализ полностью и выкинуть часть кода в публичных пакетах, к сожалению, не получится.

Фактически завершили формирование программы и большую часть подготовки. Ещё работаем с докладчиками утрясаем отдельные моменты, но основное сделано. Должно получиться как минимум не хуже 2019-го. Может и лучше.

Немного мыслей на тему:

1. Несколько переносов прямо сильно ударили по моральному духу всех причастных. Тут уж ничего не поделать... корона, но я не думал что будет настолько деморализовывать.
2. Делать конференцию в постоянно меняющихся условиях в разы сложнее: нужны резервные докладчики, есть множество ограничений по площадке, границам и так далее.
3. Ограничения - это хорошо. Придумали много всего такого, о чём в нормальных условиях не додумались бы.
4. Русскоязычные докладчики хороши. Да, англоязычные специалисты в 2019-ом привезли крутой контент, но смотрю на текущую программу и понимаю что точно не хуже.
5. Нужно больше общаться с командой организаторов, докладчиками и потенциальными докладчиками. И темы внезапно оказывается крутые есть, и идеи возникают замечательные и проблемы решаются иногда сами собой. Этот пункт справедлив, в общем-то, для любой командной работы.
6. Очень многие не спрашивают своих работодателей на тему купить билет на конференцию и зря. Большинство работодателей с радостью это сделают: тут и мотивация и сотрудник с новыми идеями и про компанию, вероятно, услышат.

Приходите, будет хорошо!

Попробовал Starship, кросс-платформенное приглашение командной строки, написанное на Rust. Подходит к любому шеллу, в том числе к bash или Powershell под Windows.

Отлично настраивается. Из коробки показывает текущего юзера, ветку git, используемую версию того же PHP, всякое про Docker и так далее. Причём всё в зависимости от контекста текущей директории, то есть это не выглядит как бесполезный космолёт.

Ставится удивительно легко.

Пробуем