<rmcreative>

RSS
  1. Дебажим остановившийся контейнер Docker

    26 августа

    Бывает что надо понять, почему не поднялся контейнер. Ну то есть он вроде запустился, но сразу остановился. В stdout ничего не написал.

    1. docker ps -a - узнаём ID контейнера.
    2. docker commit ID-контейнера mydebug - делаем из контейнера образ.
    3. docker run -it --rm --entrypoint sh mydebug - мы внутри. Можем смотреть, например, логи в локальной файловой системе.
    4. docker image rm mydebug - чистим за собой.
    Комментировать
  2. Yii 3 и PSR

    21 августа

    На хабре задали интересный вопрос: «зачем пилить свои имплементации шаблонных вещей когда вокруг куча готовых, протестированных, оптимизированных? Не является ли это бутылочным горлышком в процессе реализации фреймворка?»

    Распишу по каждому PSR-у:

    • 1 - Basic Conding Standard. Исплользуем, не переделывали.
    • 3 - Logger Interface. Можно было взять Monolog, но нам нравился концепт логгера из Yii 2 больше, поэтому портировали и почистили. Но можно использовать в своих приложениях и Monolog.
    • 4 - Autoloading Standard. Исплользуем, не переделывали.
    • 6 - Caching Interface. Не используем, см. 16.
    • 7 - HTTP Message Interface. Своё сразу решили не делать. Сначала сравнили всё и выбрали самую лёгкую реализацию Tobias Nyholm. Но потом пришёл Евгений, у которого была ещё более оптимальная реализация. Впоследствии он влился в команду фреймворка.
    • 11 - Container Interface. Контейнер свой потому как стандарт регламентирует только получение зависимостей, а конфигурирование — нет. Сделать удобное конфигруирование как раз задача для фреймворка и то, что его отличает от других. И да, вот эта реализация кушает много времени.
    • 12 - Extended Coding Style Guide. Этот стандарт я координировал в PHP-FIG. Конечно же, используем.
    • 13 - Hypermedia Links. Не используем.
    • 14 - Event Dispatcher. Написали свой, ничего достойного готового на момент выхода стандарта не было, а события уже были нужны.
    • 15 - HTTP Handlers. Тоже центральная часть фреймворка так как определяет, какие Middleware поддерживаются, как задаются и, главное, как вызываются. Поэтому написали свой.
    • 16 - Simple Cache. Написали не PSR-ный yiisoft/cache, который использует любые PSR-16 адаптеры кеша и добавляет сверху всякие классные штуки. Ну а так как с Yii 2 уже был рабочий код адаптеров, портировали в PSR-16.
    • 17 - HTTP Factories. См. 7.
    • 18 - HTTP Client. Не будем реализовывать, будем использовать.

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

    5 комментариев
  3. Новости Yii 2021, выпуск 3

    20 августа

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

    Читаем

    Комментировать
  4. Как описать проблему

    19 августа

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

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

    7 августа

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

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

    Комментировать
  6. Видео с митапа по Code Review

    7 августа

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

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

    Комментировать
  7. Видео с митапа по тестированию приложений

    4 августа

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

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

    Комментировать
  8. Присоединился к GetMentor

    2 августа

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

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

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

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

    5 комментариев
  9. Yii 3: пред-релизная поддержка компаний

    29 июля

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

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

    2 комментария
  10. Границы применимости статического анализа в публичных пакетах

    16 июня

    В замечательном чате Валентина Удальцова «Пыхтелка» заметили релиз одной из библиотек 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, что вообще будет использоваться хоть какой-то статический анализ.

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

    2 комментария