<rmcreative>

Involta приготовили видео доклада по безопасности образца 2019 в Иваново .

• Смотрим на YouTube
• Листаем слайды

На днях тестировал Yii 3 под RoadRunner. Завёлся почти без проблем. Время ответа в среднем в 1-2 миллисекунды очень порадовало.

Но Yii 3 ещё не готов, а производительности хочется. К счастью, Charles R. Portwood II, написавший когда-то пару неплохих книг по Yii приготовил шаблон приложения для запуска под RoadRunner.

Запускается так:

1. Клонируем https://github.com/charlesportwoodii/yii2-app-basic-psr7
2. composer install
3. Ставим RoadRunner одним из описанных способов
4. ./rr.exe serve -d -v -c ./rr.yaml
5. Открываем http://localhost:8080

Приложение открывается и работает. В продакшне я, правда, поведение пока не проверял.

Темы выгорания я уже касался в 2017-м, оно почти настигло меня в Skyeng и я посвятил ему часть постов в твиттере Backend Secret.

Неплохая статья про выгорание с довольно ценными комментариями была опубликована на хабре Лерой Лисичкиной из Gett.

Читаем

Мой личный опыт во многом совпадает с описанным там я последствия выгорающих для компании я вижу примерно так же.

PSR-12 приняли. Работали мы над ним мы очень долго, хоть и не так активно, как могли бы. В итоге получился достойный наследник PSR-2. Некоторые конструкции из PHP 7.4 не описаны, но это нормально: сначала нужно посмотреть, как они используются, а потом уже пытаться это закрепить.

Знакомимся

Стас Цыганов и Егор Толстой составили дерево навыков и обязанностей тимлида. Получилось очень похоже.

• Репозиторий на GitHub
• Вводная на хабре

В самых тяжелых случаях в компании лид занимается всем или почти всем. Так было в Skyeng. Если команда большая — это не очень хорошо. Создаёт слишком сильную нагрузку, тянуть которую в течение длительного времени могут единицы и заставляет работать с жутким дефицитом времени, из за чего страдают результаты.

В обычных случаях лид занимается лишь частью, а другие ветки выделяются в отдельные роли. Например, в CleverTech я занимался исключительно ветками Technical Lead и Resource Manager.

Отдельный набор «Personal Skills» полезен, но смысл большинства пунктов понимается только когда без этого никак. Оно и понятно: зачем учиться управлению временем если времени с избытком? Зачем управлять конфликтами если их нет?

Насколько протестирован ваш код? 100% code coverage не гарантирует что правильно проверены все кейсы. Эта метрика показывает лишь то, что при выполнении тестов выполнился весь код.

К счастью, есть придуманный ещё в семидесятых способ выяснить, насколько хороши тесты. Называется он «мутационное тестирование».

Читаем

27 июля 2019 в 15:00 расскажу про безопасность в Иваново на митапе Involta.

БЦ "Мегаполис", ул. Парижской Коммуны, 3А, 4-й этаж.

Регистрация обязательна, вход бесплатный

В прошлом году в пакете cebe/markdown, занимающимся переводом markdown в HTML, завели тикет о том, что обработка пропускает XSS. Я думал, случай непонимания единичный, но нет. Оказалось что ещё и CVE завели, так что на всякий случай:

Markdown не обязан быть безопасным. По задумке в нём допускается использование HTML, что автоматически означает что и XSS туда тоже можно засунуть.

Если используете markdown для пользовательского ввода, не забудьте прогнать вывод санитайзером вроде HTML Purifier. Конфиг для него в случае cebe/markdown может быть таким.

Дыры в Wordpress находят часто, а обновлять его лениво. К счастью, автоматизировать обновления достаточно легко.

1. Ставим WP-CLI так чтобы запускался как wp.

2. Создаём небольшой шелл-скрипт update_wordpress.sh:

   cd /var/www/путь_до_wordpress/www/
   sudo -u www-data wp core update
   sudo -u www-data wp theme update --all
   sudo -u www-data wp plugin update --all
   

3. Запускаем раз в неделю. crontab -e:

   0 0 * * 0 /полный_путь/update_wordpress.sh > /полный_путь/update_wordpress.log 2>&1
   

UPD: при этом отпадает необходимость обновления через wp-cron, так что её можно отключить через wp-config.php:

define('AUTOMATIC_UPDATER_DISABLED', true);

DevConf в этом году радуют быстрой обработкой видео. Выложили мой доклад «Теория программирования: пакетные принципы и метрики».

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

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

Пакетные метрики позволяют формально оценить, подходит ли сторонний пакет для использования в вашем проекте или пакете, как он повлияет на общую стабильность.

Пакетные принципы, изначально озвученные Робертом Мартином в дополнение к SOLID, показывают путь достижения оптимального соотношения поддерживаемости и гибкости.

Смотрим