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

Вот и туториал подъехал: 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 — до сих пор одна из самых распространненых инсталяций

Наконец-то k8s митап в адекватное время: https://corp.mail.ru/ru/press/events/600/ Хороший тамада и доклады интересные)

JSHeroes 2019 , 20 видео

https://www.youtube.com/playlist?list=PLB9NqTp0uKrR8WFXitMvLMGd-kGGZ4RkX

#ML
Еще одна статья из цикла "ml для самых маленьких": https://eldf.ru/top10ml

Что меня всегда вводило в дрожь в незрелом IT — это полнейшее неуважение к времени коллег и, в частности, ужасная организация митингов\совещаний и т.д. Признайтесь, у всех были 15минутные встречи, которые каким-то образом растягивались на 2 часа, когда половина присутствующих зевает, а другая половина лениво кидает птиц в свиней и только 2 молодца рьяно обсуждают какой-то явно кулуарный нюанс.
Что больше всего расстраивает в таком положении дел — так это то, что поправить ситуацию можно за 5 минут. Усилием воли выпускается царский указ, где написано:
1. митинги длятся не больше часа
2. перед митингом ЗАРАНЕЕ расылается повестка
3. на митинг зовутся ТОЛЬКО заинтересованные стороны(никаких Василий Борисовичей, что бы был в курсе). Все участники должны вынести\поделиться чем-то полезным на встрече(Василий Борисович почитает notes)
4. каждый митинг кто-то ведет(читай модерирует).
5. ведущий следит за тем что говорит всегда один
6. ведущий следит за тем что тема не уходит в детали не интересные всем(или большинству) присутствующих. С деталями — в кулуары
7. ведущий следит за тем что идет конструктив, а не "я твой мамка шатал"
8. ведущий рассылает(или заставляет кого-то отослать) notes — краткую выжимку со встречи, где написано что обсудили, что решили, что и кому надо сделать.

Вот и все. И тонны человеко-часов сэкономлены!

#qa
Котаны, за свою карьеру приходилось работать в разных командах и кампаниях, но закономерность всегда следующая: без нормально построенного тестирования продукт рано или поздно загибается, стагнирует и выдавливается с рынка конкурентами. Сразу скажу, я не QA-инженер, и дальше могут быть неточности, но в целом соображения такие:
1. Есть такая штука: уровень зрелости кампании. Если вкратце, то идея такая: сначала кампания -- это стартап, для которого важно набрать аудиторию и выйти на максимально большой рынок. Это стадия роста. Дальше идут стадии связанные с осмыслением процесса, уменьшением churn'а(оттока недовольных клиентов), повышения качества оказания услуг и т.д. Так вот, с каждым из этих уровней связан определенный "допустимый уровень качества". Это QAшное понятие, которое определяет с каким кол-вом дефектов какой важности можно ехать на прод(что-то вроде модного нынче error budget'а).Смысл в том, что чем выше уровень кампании, тем, выше допустимый уровень качества(спасибо кэп). И вот тут вылезает 1я важная компетенция QA -- эти крутые парни и супер-девчонки умеют правильно выставлять приоритеты дефектам(по четким, на секундочку, критериям, а не от балды) и следят за тем что бы качество продукта не пробило дно.
2. Вангую, что каждый разработчик писал тесты. Не важно, интеграционные/юнит/еще какие-то, важно то, что рано или поздно в покрытом тестами функционале все равно находился баг. Причем вылезал в самом странном месте и на входных условиях, которых никто никогда и предположить не мог. Коллеги придумали кучу способов это забороть типа ScalaCheck и т.д., но реально работает только штука придуманная тестировщиками, а именно тест-дизайн. Вдаваться в подробности тут не буду, но это сложная наука, которая учит как писать тест-кейсы так, что бы описанная выше ситуация не происходила. Кароч QA-инженер с молоком матери впитывает умения писать тест кейсы таким образом, что бы будучи протестированным, функционал реально работал согласно ожиданиям
3. QA -- тестируют функционал на корректность и соответствие заявленным требованиям(спасибо, кэп[2]), по этому они лучше всех знают как ДОЛЖЕН работать продукт. Дело в том, что в отсутствии аналитиков и солюшн архитекторов тестировщики -- единственные люди обладающие в должной мере знаниями о продукте и тех. компетенциями что бы адекватно провалидировать требования и высказать при случае свое "фи" продуктологам и/или указать на противоречия в консернах
4. Тесткейсы -- это реально наиболее близкая к боевым условиям спецификация продукта. Что говорить, тесткейсы на Cucumber(нотации Given-When-Then) многие используют как реальную исполняемую спецификацию проекта. И если у вас на проекте вдруг(хе-хе) нет документации, то можно смело просить тест-кейсы и разбираться по ним.

Кароч, котаны, любите и берегите своих тестировщиков. Помогайте им чем можете. И если на Вашем новом проекте нет тестирования, не описаны тесткейсы и ваще "да че тут тестировать, сами как нибудь...", то может не надо в такое влазить?)

#code (from Clean code by Robert C. Martin)

Чет ору: https://m.habr.com/ru/post/456558/ Кто еще не заклеил камеру бумажкой: все, пора)

В тему предыдущего поста: