flagger

Kubernetes оператор от компании weaveworks для организации canary деплоя.

https://github.com/weaveworks/flagger

HTTPS-PORTAL

Готовая к работе связка Nginx + Let's Encrypt + Docker для автоматизации доступа через https к вашим веб ресурсам.

https://github.com/SteveLTN/https-portal

#testing
Интересная статья про то как допустимый уровень качества перекликается с CMMI. Опять же, можно найти себя и понять куда двигаться: https://m.habr.com/ru/company/provectus/blog/448458/
С другой стороны, не совсем согласен с практикой автора "перескакивать" через maturity level: вряд-ли есть смысл строить у себя model-based testing, если тут стартап в фазе роста и т.п.

Котаны, со времен первой версии SUnit и изобретения юнит-тестирования как такового(а это конец 80х годов, на секундочку) не утихают холивары из серии "TDD-only vs юнит-тесты нинужны". И вот, пока ничего интересного не происходит, я тоже слегка наброшу на вентилятор. Сразу скажу, что все это мое субъективное мнение, которое, надеюсь, будет кому-то полезным.
Вдохновением я обязан вот этой вот статье: https://clck.ru/FgVCL. Вкратце, автор утопал в регрессии после каждого релиза, а тут, хоба, тдд пришло и всех спасло. Скажу сразу, во-первых, я очень рад за автора, что он нашел средство от своих болей, во-вторых я не знаю стека, но по тематике блога делаю предположение, что это фронтенд, а по симптомам, опять же предполагаю, что фронтенд старый + профессиональное тестирование у автора отсутствовало.
Ну так вот, основная идея юнит тестирования базируется на разбиении программы на изолированные модули и написании тестов, которые проверяют, что модуль правильно выполняет свою функцию. Обратимся чутка к теории. В 1969 году дяденька Хоар предложил формальную систему для доказательства корректности программ через т.н. триады Хоара. Идея следующая:любая программа может быть описана тройкой P(ограничения входных данных), Q(ограничения на результат выполнения), C(сами инструкции программы). Если с P и Q все более-менее понятно, то в C нам, как приверженцам ООП(да и для ФП, хоть и в меньшей степени) интересны даже не столько инструкции, сколько внутреннее состояние программы, которое Бертран Мейер называет инвариантом. Далее, мы разбиваем программу на подпрограммы(те самые юниты) и с удивлением(нет) обнаруживаем, что для них тоже можно написать тройки Хоара. "Ну и че?", спросите вы! А вот че: юнит тесты, по-сути, проверяют из всей тройки только Q! Т.е., выражаясь человеческим языком, вы проверите, что при вызове getFullName(name, surname) вы получите surname + ' '+ name, но в боевых условиях никто не гарантирует что в a не прилетит null\undefined\время жизни вселенной или даже картинка котика в виде битмапы, хотя создатель foo ожидал там строку с именем вызывающего. Бекендеры работающие с распределенными архитектурами\разрабатывающие апи не дадут соврать, на вход может прилететь все что угодно. Вот на вход вашего метода тоже может влететь любая хрень, сводящая пользу тестирования модуля в изоляции примерно к нулю. Нет, юнит тесты полезны, но только(!) в связке с интеграционными и e2e тестами, при чем польза юнит тестов уверенно растет при увеличении "строгости" ЯП и используемых фреймворков(дело в том, что строгая система типов сильно ограничивает вас в возможностях, тем самым неявно проверяя контракт на P, а, например, гарантированная чистота функций, неявно гарантирует сохранность инварианта). Т.о, возвращаясь к исходной статье, если мои предположения верны, то автора на том этапе юнит-тесты бы не спасли. Потому что вот: https://clck.ru/FgVDm
Так зачем же все-таки нужны юнит тесты?
Во-первых, юниты — отличная "подушка безопасности" при рефакторинге. Выше я кидал книжку Фаулера про рефакторинг, там несколько раз, начиная с введения, написано, что перед рефаторингом написание тестов — маст хев. Причем, в зависимости от того, что рефакторите(модуль или целый флоу) можно или ограничиться юнитами или страдать за написанием интергационных тестов
Во-вторых, TDD сильно помогает при написании модуля со сложной логикой. Было у вас когда-нибудь такое, что надо написать какой-то алгоритм, но как написать — хз? Вот тут TDD решает. Берем тесткейсы от QA или примеры от аналитика, зашиваем в тест, и поехали, прям как Кент Бек завещал. Результат шикарный, а главное, быстрый(гораздо быстрее чем долго думать и потом что-то родить).
В-третьих, если вы все-таки решили программировать сложный алгоритм без TDD(обычно актуально для сложных маппингов), то пожалейте и QA и себя, напишите тесты. Багов найдете вагон, инфа сотка.
В заключении, вот статья коллеги про unit vs integration: https://clck.ru/FgVGN и полезные статьи про контрактное программирование и триады Хоара:
http://sergeyteplyakov.blogspot.com/search/label/Design%20by%20Contract

Пример организации CI/CD от Qlector https://medium.freecodecamp.org/speed-is-all-you-need-how-we-set-up-continuous-delivery-e4d8010cb1c5 #cicd

Евгений Потапов дополнил свой доклад про мониторинг в 2019 году и опубликовал статью. Очень удобно: и торопиться не приходится и вопросы можно вдумчиво задать.
https://habr.com/ru/company/itsumma/blog/448602/

Кмк, очень странная доклад. Закрывая глаза на технические неточности, очень странный рассказ про изнасилованного админа, который настраивает мониторинг приложений в 2019 году. На фоне всех хайповых трендов типа девопс и sre достаточно забавно наблюдать админов пытающихся замейнтейнить кучу микросервисов. Вроде как даже в ынтерпрайзе разработчики уже сами мониторят свои сервисы и добавляют пайплайны, а тот самый админ отвечает за core-инфраструктуру. Вот и все, вот и все)

И, раз уж, пятница и зашла тема про людей в мыле, то вот вам крутой комикс про дедлайн(by KODA)

Вот и амазоновская статья на ту же тему: https://aws.amazon.com/devops/what-is-devops/

Управление состоянием с помощью React Hooks — без Redux или Context API

https://medium.com/javanoscript-in-plain-english/state-management-with-react-hooks-no-redux-or-context-api-8b3035ceecf8

Dashboard Design Guide

Отличные практические советы по созданию дашбордов для мониторинга.

Part 1: Structure and Layout in System Dashboard Design
http://onemogin.com/observability/dashboards/practitioners-guide-to-system-dashboard-design.html

Part 2: Presentation and Accessibility in System Dashboard Design
http://onemogin.com/observability/dashboards/practitioners-guide-to-system-dashboard-design-p2.html

Part 3: What Charts To Use in System Dashboard Design
http://onemogin.com/observability/dashboards/practitioners-guide-to-system-dashboard-design-p3.html

Part 4: Context Improvement in System Dashboard Design
http://onemogin.com/observability/dashboards/practitioners-guide-to-system-dashboard-design-p4.html

Essential Guide to keep up with AI/ML/CV

These fields are booming these days. In order not to become rusty, one has to constantly follow the updates. Here is the essential guide on how to keep up with the important news/papers/discussions/tutorials. This guide is by no means an exhaustive one so contributions are truly welcome.

Link: https://github.com/BAILOOL/DoYouEvenLearn

#ML #datascience
Прикольный видос https://www.infoq.com/presentations/automated-ml-assistant-ds чувак интересно готовит ансамбли

#ML #datascience
Интрадакшн в рандомные леса для самых маленьких: https://victorzhou.com/blog/intro-to-random-forests/ (там же ссылки на туториалы по другим методам)

​​Друзья!

📆 26 апреля в Москве состоится большой Frontend MeetUp, который компания ManyChat организовывает совместно с PiterJS🔥 Это будет первый выездной митап от питерского сообщества. MeetUp будет посвящен SSR React, WebGL и семантике в программировании.

☝️В программе 3 доклада:

🔸 Выступление Евгения Кувшинова, front-end tech lead ManyChat. Он расскажет о том, как объединить два мира — WebGL и React/Redux, взяв лучше из каждого: производительность WebGL и декларативный компонентный подход React.

🔸Доклад от Николая Говорова, старший фронтендер в CoffeeTeam, который расскажет, как строить изоморфные приложения, поддерживать множественные сборки и почему SSR делает архитектуру лучше.

🔸 Выступление Артёма Арутюняна, CSSSR frontend web developer. Артём расскажет на практических примерах о том, как писать понятный, дешевый код в независимости от технологического стека.

Участие бесплатное, регистрация по ссылке: https://medium.com/piterjs/tour-1-b4a4bf911f56