#database #mongodb
Памятка про то как не надо готовить монгу: https://www.infoq.com/articles/Starting-With-MongoDB Все, вобщем-то, очевидно, но для тех кто только знакомится с монгой, может быть полезно

#books #sql
Шикарная книжка, по которой, в свое время, сам учил скуль

#frontend
Прикольный лонгрид про современный фронтенд в целом: https://frontendmasters.com/books/front-end-handbook/2019/

Docker vs LXC/LXD

https://stackshare.io/stackups/docker-vs-lxc-vs-lxd

Как Tinder в контейнеры уходил.

https://medium.com/@tinder.engineering/tinders-move-to-kubernetes-cda2a6372f44?

Визуализация вашего Kubernetes #k8s #visualization https://github.com/spekt8/spekt8

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/