​​Законы хреновых дашбордов -- статья скорее не про мониторинг, а про 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/ Кто еще не заклеил камеру бумажкой: все, пора)

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

Долго тут вынашивал одну мысль, которой в итоге решил поделиться:
Каждый руководитель в определенный час Ч слышит от инженера что-то типа "ну это не поддерживается в текущей архитектуре, надо это переделать, то перенастроить, тут хранилище жопой сделано и ваще все не по феншую. На все про все надо каких-то пол-года и будет прям конфетка." Дальше обычно идет басня про НФТ а-ля нагрузки держать будем и изменения вноситься будут сами и ваще TTM упадет до 1 дня. На вопросы можно ли это имплементить итеративно и/или распараллелить между несколькими инженерами обычно ответ отрицательный.
Так вот, это не так! Все что разрабатывается дольше того самого человекомесяца отлично бьется отдельные стори. Как минимум на MVP и на все остальное(что уже не маловажно, т.к. позволяет оценить продуктовую ценность, проверить идею и т.д. и т.п.). Более того, все что оценено больше чем в человекомесяц отлично параллелится(только не за неделю до релиза, а сразу). Если не параллелится(вот совсем никак), то тут уже должны возникнуть вопросы к реализуемому дизайну и архитектуре.
Почему же инженер так поступает? Нет, он вам не враг и тоже хочет сделать хороший продукт. Дело в том, что у вас с ним совсем разные консерны. Вы хотите получить больше денег, удержать продукт на плаву, занять рвнок и т.д., а вот он хочет совсем другого: он хочет вносить меньше регрессии, хочет не просыпаться по ночам от звонков pagerduty и, конечно, хочет рассказать за кружечкой что его бенчмарки показали результат в 100500rps. И, конечно же, он хочет быть уверен, что все это будет сделано именно так как он этого хочет, потому что он знает и умеет, а вот остальные -- не факт! И для этого ему надо войти в пресловутое состояние потока и не отвлекаться на другие задачи, тем более, что так будет быстрее и эффективнее.
Мораль сей басни такова: 1. товарищи продуктологи, взаимодействуйте с IT как можно чаще! Доносите до них важность и ценность своей работы. Максимально обосновывайте свои консерны и обозначайте цели, стоящие перед вами как перед командой и кампанией. IT -- это не просто инструмент, это люди, со своим мнением, целями и видением. И очень важно, что бы это видение было консистентным
2. Товарищи инженеры, будет очень здорово, если вы постараетесь влезть в шкуру тех самых аналитиков/менеджеров/CTO, которые ставят вам задачи(тем более, что сейчас очередной виток моды на T-shaped😜)

📘 И продолжая тему подписок. Чуть больше месяца назад, Red Hat на своём сайте запустили раздел "Enable SysAdmin" - блог для сисадминов с различными статьями разной степени полезности.

Бывалым админам часть материалов там будет и так знакома, а вот тем, кто приходит к тем же devops практикам из разработки (без админской базы), обратить внимание на эти публикации будет полезно.

#линк #напочитать

#cvdriven
Новые технологии -- это всегда хорошо и круто, но, так же, всегда надо понимать область применения и ограничения этих самых технологий(ваш кэп), что бы не заставлять девопсов поднимать кластер кафки ради 100 сообщений/сек.