#scala
Камрад написал крутой пост что такое этот ваш ZIO и зачем. Пост 2й в серии(будет еще). В результате должно получиться цельное приложение

📺 Периодически пишут ребята из Dino Systems, и просят анонсировать их митапы. Мне, к сожалению, никак удаётся сделать это во время, но и совсем не рассказать о них я не могу.

У ребят есть небольшой, но весьма уютный youtube канал, на котором записи этих самых митапов выкладываются - заглядите туда, между делом, там есть на что посмотреть (много чего по разработке, по обслуживанию и сопровождению, про сервисы, про aws, devops и много чего ещё). А вот здесь, достуны анонсы их дальнейших мероприятий, если уже опубликованные ролики заинтересуют вас, камрады.

Ознакомьтесь вобщем, как появится свободная минута. 😉

#рекомендация

From Graphite To Prometheus — Things I’ve Learned

Подробное сравнение Graphite и Prometheus

https://engineering.nanit.com/from-graphite-to-prometheus-things-ive-learned-e1d1e4b97fc

Кстати рекомендую! У IBM обычно оч крутые митапы👇

На этой неделе в офисе IBM пройдет очередной митап. Архитекторы IBM, RedHat и наши знакомые из бизнеса расскажут о своем опыте построения масштабируемых систем на Kubernetes. Количество мест ограничено - регистрация по ссылке https://ibm.biz/k8smoscow

#cqrs #eda
Ох, как же я сочувствую автору поста, ведь в свое время мы прошли через похожий ад. Пожалуй даже добавлю еще 3 граблины:
0. Если хочешь запилить свой CQRS фреймворк... пожалуйста, не надо. Мало того, что этого шлака и так полно на гитхабе, так еще самопальный комбайн(а там писать так-то не мало, вот пруф) обязательно взорвет прод.
1. Спорим, что можно жить без CQRS?
2. Когда Вернон писал , что границы strong consistency ограничены агрегатом он имел в виду "агрегат должен быть согласован", а не "да пофигу что там за границами агрегата". Если бизнесу нужна консистентность ты спрашиваешь насколько высоко делаешь консистентность
Спасибо за внимание, не овертаймьте 😉

https://dbdb.io

Отличный сайт с кратким описание особенностей почти всех существующих баз данных.

Несколько примеров:

etcd: https://dbdb.io/db/etcd
postgresql: https://dbdb.io/db/postgresql
mysql: https://dbdb.io/db/mysql
redis: https://dbdb.io/db/redis
memcached: https://dbdb.io/db/memcached
mongodb: https://dbdb.io/db/mongodb
cassandra: https://dbdb.io/db/cassandra

Крутой инструмент для нагрузочного тестирования https://medium.com/swlh/beginners-guide-to-load-testing-with-k6-85ec614d2f0d #loadtesting

#perf
И в догонку годный генератор нагрузки

Завтра в 12:30 начинаем прямую трансляцию с митапа Backend United: Шаурма

На митапе инженеры из Авито, Мэничата и Severstal Digital расскажут про реальный опыт переезда на микросервисы, способы синхронного и асинхронного взаимодействия, организацию потоков данных и роль Кафки в микросервисной архитектуре.

Если не получится прийти на встречу, подключайтесь к эфиру 👇🏻
https://youtu.be/5-5mpnX-qgI

Practical FP in Scala a hands-on approach by Gabriel Volpe, версия для ознакомления (и готово только 75%), поддрежите автора, если вам она зашла. Пдфка от 5го декабря. Поддерживать здесь: https://leanpub.com/pfp-scala

Джуность

Самое сложное в изучении программирования — знать, что изучать. Ребята из Anmedio. запустили клевый проект — Джуность. Это простая таблица, которая показывает какие знания они ожидают увидеть у специалиста того или иного уровня. Не нужно воспринимать эти пункты как непогрешимую истину, но обратить на них внимания при составлении индивидуального плана обучения определенно стоит.

#рост

Добрался описать наш IBM Managed Kubernetes и Managed OpenShiift. Статья скорее с техническим уклоном, а не маркетинговым. Как строили, что использовали и к чему стремились. Будут пожелания по раскрытию каких-либо тем - пишите вопросы под статьей. https://habr.com/ru/company/ibm/blog/479664/

#docs
Недавно тут случилось зарамсить по поводу документации. Мой поинт был в том, что чем больший процент документации генерится из кода, тем лучше, ибо эта штука всегда актуальная и бла-бла.
Поинт более опытных коллег заключался в том, что сгенерированные доки конечно актуальные, но чуть менее чем полностью бесполезные. Все, конечно, остались при своем, но вот тут вот внезапно натыкаюсь на пост и прямо вот сложилось.
Раньше я думал, что часть доков надо генерить, а остальное писать(генерим апи доки сваггером, датафлоу и деплоймент схему из dt/service mesh DAG'a и кубера ну и кейсы Cucumber'ом + рисуем руками фичи, и интеграции с 3rdparty)
Щас же пришел инсайт, что надо не генерить ИЛИ рисовать, а генерить И дорисовывать. Т.е. взяв, для примера, схему апи, надо в шапку сваггера руками положить пример хеппифлоу в каком-то виде(сикуенс диаграммы или еще как-то), с человеческим описанием что делает апи и для чего нужно + возможно указать акторов.
Кароч вот такие мысли, котаны. Что думаете?

Если бы SMART-цели придумали в России:
В – время (time bound)
О – оцениваемость (mesurable)
Д – достижимость (achievable)
К – конкретность (specific)
А – адекватность (relevant)

#datascience
Интересная статья от коллеги из holistics.io про очередной расцвет SQLя.

Статья о том как анализировать большой объем данных с помощью библиотеки vaex

https://towardsdatascience.com/how-to-analyse-100s-of-gbs-of-data-on-your-laptop-with-python-f83363dda94

Выложили видео с 46-ой встречи MocscowJS: https://meetup.tinkoff.ru/events/moscowjs-46
Мой доклад: https://www.youtube.com/watch?v=MD49vFaQ4QA

#fp
А вот ссылка на упомянутую в докладе статью.
BTW бомбический весь сайт Maarten Fokkinga т.к. там у него пдфки всех его работ

Are you ready for production?

Презентация про то, как должен выглядеть production launch checklist от Jaana Dogan (Google).

Видео: https://youtu.be/YptJ2rrGAYY