<rmcreative>

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

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

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

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

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

Читаем

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

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

Было: Каталог товаров с фасетами и хитрой сортировкой на MySQL.

A: Переписали на SphinxSearch. После деплоя упёрлись в max_matches.

B: Быстро повысили max_matches, но слишком сильно.

C: Вернули max_matches в допустимые границы.

Стало: Ответ сверера в два раза быстрее. Уменьшилась общая загрузка CPU и потребление памяти сервера.

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

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

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

Распишу по каждому 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-пакет с фиксированными требованиями не требует.

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

Читаем

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

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

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

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

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

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