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

Начнем с главного:
Замечательно, если ваш проект написан на bleeding edge технологиях, но все это не будет иметь никакого смысла, если при первом же инциденте вы не сможете провести инвестигейт потому что вы забыли добавить логирование.
Вы молодец, если ваша доменная модель идеально продумана, но все это вам не поможет если копируете сборки на сервер или мигрируете базу руками.
Кароч, вас ожидает фиаско, если в первую очередь вы не позаботитесь об инфраструктуре проекта. Первым же(фигурально) коммитом должно улететь логгирование и мониторинг, а в первом PR обязательно должно присутствовать решение по миграции базы и IaC. Да, возможно, сначала это будет логирование в файл и пачка шеллскриптов(если у вас, конечно, уже нет общего решения, но это отдельная история) Боб Мартин и https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt вам в помощь. Смысл в том, что говнокод можно переписать, но переписывать будет некому если поцоны стерлись от постоянных овертаймов на релизах и инвестигейтах в MSA/SOA где половина сервисов не пишет логи, а вторая половина не прокидывает correlationId

Управление командой: военное и мирное время

Важная метафора в управлении командой — военное и мирное время. Война — это время напряжения всех сил: чаты в телеграме, ежедневные планы, быстрые и грязные фиксы в коде.

В мирное время всё, спокойно — планы больше растянуты по времени, коллеги не отвлекают друг-друга по пустякам. Больше внимания уделяется качеству кода и процессам, происходящим в команде.

Война — не так уж и плохо: она кратковременно ускоряет производство, объединяя команду вокруг одной конкретной задачи. На войне можно быстро получить грязный продукт, который срочно нужен.

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

Воевать хорошо раз в пару месяцев, не чаще. Частые войны выматывают команду и продукт — копится усталость и техдолг.

Важный навык CTO — не начинать войны по пустякам. Если вы собираетесь занять личные ресурсы у участников своей команды (а возможно и у их близких) — уж потрудитесь убедиться, что бизнес получит от этого соответствующую прибыль.

Semantic это такая штука, для парсинга, анализа и сравнения кода на разных языках(Ruby, JS, TS, Python, Go, so on).

И вот они написали оду Хаскеллу, если кратко:

> Why is Semantic written in Haskell?

<...> In Haskell, control flow is not dictated by the language, but by the data structures used. The same syntax is used for nondeterministic and backtracking computations, for concurrency and parallelism, and for traditional imperative blocks: user-defined interpretation functions, rather than built-in language semantics, determine the way that code is executed. This would be nearly impossible to implement in a language like Go, given its limited support for abstraction and polymorphism, and a maintenance nightmare in Java: every single one of our 20k lines of code would need to be rewritten as a data structure rather than a function. This is simply not a realistic task in other languages; even functional languages like OCaml and Swift lack this level of abstraction.

https://github.com/github/semantic/blob/master/docs/why-haskell.md

Очень удачно совпал пост коллеги про войны и мой цикл батхертов)
Войны неизбежны. Они обязательно случаются и, да, они могут быть полезны для понимания поведения коллег в экстренных ситуациях(всегда полезно знать, на кого можно положиться, а кто в 6 встанет и уйдет и хоть трава не расти)
Но! Ни в коем случае на войну не берут новобранцев. В хотфиксах всегда(!) должны участвовать люди знающие кодовую базу и, тем более, понимающие флоу бизнес-процессов. Нет ничего страшнее ньюкамера, который патчит прод в самом хрупком и, по счастливой случайности, бизнес-критикал месте. В итоге вы получите только окончательно поломанный сервис, фрустрирующего сотрудника и недовольных клиентов

Нашел тут на просторах жуйреактора прикольную картинку: http://img0.reactor.cc/pics/post/full/it-%D1%8E%D0%BC%D0%BE%D1%80-geek-5239530.png

CodeFest выложил видео

CodeFest 2019 #Backend
https://www.youtube.com/watch?v=Nkb-cl8oWLg&list=PL8761XQAJnrZrLWgseZEH1PQKSwqh6FQ0

CodeFest 2019 #Frontend
https://www.youtube.com/watch?v=57ghglfohmk&list=PL8761XQAJnrZZ2IB-VIvbuCpQxp890Gns

CodeFest 2019 #QA
https://www.youtube.com/watch?v=yPU7sYMGIgM&list=PL8761XQAJnrYdOtgSsBtUCoBImqBuEyMc

CodeFest 2019 #Projects
https://www.youtube.com/watch?v=eVtFRBTKoPo&list=PL8761XQAJnraw0hWiCxO6bWRpPqBknA8r

CodeFest 2019 #Products
https://www.youtube.com/watch?v=uUg_halSAIs&list=PL8761XQAJnrZwAm6BdJdIIA0noL7-dnmZ

CodeFest 2019 #Teamlead
https://www.youtube.com/watch?v=hUvfjVRNHDs&list=PL8761XQAJnrbquWpwUNLNVitf0sXHse23

CodeFest 2019 #Design
https://www.youtube.com/watch?v=nQ3jgdOOwA8&list=PL8761XQAJnraFjqzGGYvIZDL005X3b5WL

CodeFest 2019 #DataScience
https://www.youtube.com/watch?v=ZljB8aPY4TE&list=PL8761XQAJnrZaezGvMIvOhi3zgd3FDn7B

CodeFest 2019 #Mobile
https://www.youtube.com/watch?v=WfRLSd6qesU&list=PL8761XQAJnrah-rGgkpZ5BkYVJKzNNODw

CodeFest 2019 #Квартирники
https://www.youtube.com/watch?v=h48ycbRFDsU&list=PL8761XQAJnrZfNIn-wFbe5VRW0AvYAAh9

CodeFestest 2019 #Future
https://www.youtube.com/watch?v=jTxqXwHY-ig&list=PL8761XQAJnrYwno51MgjuEWmczp2WL8mH

Привет, котаны! Пятничные мемы будут чуть позже, а пока мы продолжаем КВН.
Вот вы успешно пережили первый релиз и выпустились в прод, тем самым внедрясь в IT-ландшафт вашей компании. Вместе с вами, скорее всего, таких бедолаг еще N и еще M на подходе. И вот этот момент настал! Прилетает первый кросс-сервисный баг. Мы идем в логи(мы же все логируем, да?!) и выясняем, что в наш сервис запрос пришел от сервиса А, а в сервис А пришел от В а в..ну вы поняли. Причем мы-то "нормальные", мы в кассандру логируем с Id пользователя и таймстампом, а вот парни из А пишут в скуль и по имейлу юзера, а поцоны из В ваще в файл и там только урл запроса и время.
И вот прошел час, мы продрались через всю цепочку вызовов и дошли до сервиса Х, где...какой-то п$др решил писать логи в /dev/null.
Кароч, парни, рано или поздно придется стандартизировать инфраструктуру, и лучше это сделать раньше, т.е. при появлении нескольких активно общающихся между собой приложенек. Причем, касательно логирования, "сделать"-- это не значит кинуть эластик на тачку и сказать всем "я сделаль!". Необходимо определить ответственных за core(devOps культура вам в помощь), объявить новую подсистему де-юре стандартом(т.е. сервисы логирующие не так в прод просто не допускаются!) + необходимо сделать использование и подключение новой подсистемы удобной для внедрения и использования. Как минимум, написать(или найти) пакеты для подключения логирования для ваших сервисов, обладающих всем необходимым функционалом (correlationId, например)
В последствии можно сделать еще удобнее, создав сервисный каркас, а, когда ваше IT еще подрастет, то замутить Distributed Tracing, но удобные логи со связями — это мастхев.
P.S. все это справедливо для любой распределенной архитектуры, но, кмк, наиболее актуально для SOA с ее сильной связностью сервисов
P.P.S. где-то на хабре был чеклист, где инженер писал вещи без которых он сервисы в прод не пускает. Найду — поделюсь

Наглядненько

Вот и туториал подъехал: https://m.habr.com/ru/post/452684/

📺 А вы знали что вот здесь, доступно большое количество вебинаров по ansible и его применению? Вот если не знали, загляните между делом: https://www.ansible.com/resources/webinars-training

#видео #ansible

​​Законы хреновых дашбордов -- статья скорее не про мониторинг, а про UX дашбордов вообще. Ясное дело, к мониторинг дашбордам это тоже относится.

Дельный совет из Твиттера: "follow the money" -- отражайте на дашбордах критические пути пользователя, которые приносят вам деньги, а не вообще всю доступную информацию, лишь бы было.

#observability #dashboard #ux

#books
За выходные батхерт немного поутих, но я уверен, что в скором времени будет продолжение цикла😂 А пока немного позитива:
ИМХО каждый разработчик должен если не уверено разрабатывать на языках, то хотя бы понимать различные парадигмы ЯП. Если с ООП и императивщиной в целом, все достаточно ясно, то вход в функциональщину требует небольшого поворота в мозгах. У меня было несколько подходов к ФП на разных ЯП и, естественно, зашло не с первого раза. Фиаско продолжалось до встречи (и любви с первого взгляда) с Haskell. Это наиболее чистое ФП, тут же раскрывающее мощь и красоты функциональщины.
Проблема в Haskell одна: язык построен на теор.кате, поэтому все курсы и туториалы сложнее hello world обычно люто грузят мат. частью. Но все меняется! Ловите туториал хаскеля через геймдев!
P.S. учить матчасть определенно надо, но для первого шага, что бы проникнуться нежными чувствами к ghci книжка определенно хороша

Привет всем… На прощание перед летними каникулами решили порадовать общественность серией митапов!
19 июня в 18:00 в офисе IBM митап по Java технологиям. У нас будет Java Champion, Sebastian Daschner. Будем обсуждать использование Java в новых облачных реалиях. Таймпад для регистрации : https://ibmdbg.timepad.ru/event/998423/
20 июня в 18:00 в офисе IBM митап по Service Mesh - Istio. Давно хотели сделать и тут к нам приезжают основные контрибьюторы проекта. К примеру, Вадим Айзенберг входит в топ-5 людей - контрибьюторов всего проекта. Регистрация по ссылке : http://ibm.biz/IstioMeetUp
И для наших Питерских подписчиков Себастиан Дашнер выступит 20 июня совместно с Денисом Цыплаковым на площадке dataArt по темам Java и микросервисных архитектур : Таймпад для регистрации : https://dataart-spb.timepad.ru/event/998391/

📚 А вот здесь нашлась огромная wiki, с информацией по контейнерам и сопутствующим технологиям (эти ваши докеры, куберы, дев/сек-опсы и прочее). Читать-неперечитать, как говорится.

#напочитать #docker #kubernetes

Вот это номер:
https://www.microsoft.com/ru-ru/sql-server/sql-server-2008
Мелкомягкие прекращают поддержку Sql Server 2008(включая R2).
Ради хохмы вот статистика за 15год по версиям скульсервера(сорян, новее не нашел): https://www.brentozar.com/archive/2015/09/whats-more-popular-sql-server-2014-or-sql-server-2005/ Слазят со старых версий очень неохотно, а 2008R2 — до сих пор одна из самых распространненых инсталяций