I hate overtime
868 subscribers
129 photos
4 videos
54 files
961 links
Some DevOps, SRE and IT development stuff
Download Telegram
#cqrs #eda
Ох, как же я сочувствую автору поста, ведь в свое время мы прошли через похожий ад. Пожалуй даже добавлю еще 3 граблины:
0. Если хочешь запилить свой CQRS фреймворк... пожалуйста, не надо. Мало того, что этого шлака и так полно на гитхабе, так еще самопальный комбайн(а там писать так-то не мало, вот пруф) обязательно взорвет прод.
1. Спорим, что можно жить без CQRS?
2. Когда Вернон писал , что границы strong consistency ограничены агрегатом он имел в виду "агрегат должен быть согласован", а не "да пофигу что там за границами агрегата". Если бизнесу нужна консистентность ты спрашиваешь насколько высоко делаешь консистентность
Спасибо за внимание, не овертаймьте 😉
Forwarded from DevOps&SRE Library
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
Forwarded from AvitoTech
Завтра в 12:30 начинаем прямую трансляцию с митапа Backend United: Шаурма

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

Если не получится прийти на встречу, подключайтесь к эфиру 👇🏻
https://youtu.be/5-5mpnX-qgI
Forwarded from Scala Nishtyaki Channel
pfp-scala.pdf
968.8 KB
Practical FP in Scala a hands-on approach by Gabriel Volpe, версия для ознакомления (и готово только 75%), поддрежите автора, если вам она зашла. Пдфка от 5го декабря. Поддерживать здесь: https://leanpub.com/pfp-scala
Forwarded from kamyshev.code
Джуность

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

#рост
Forwarded from Enterprise Containers
Добрался описать наш 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)
Выложили видео с 46-ой встречи MocscowJS: https://meetup.tinkoff.ru/events/moscowjs-46
Мой доклад: https://www.youtube.com/watch?v=MD49vFaQ4QA
dd if=/dev/stuff of=/dev/tg
Выложили видео с 46-ой встречи MocscowJS: https://meetup.tinkoff.ru/events/moscowjs-46 Мой доклад: https://www.youtube.com/watch?v=MD49vFaQ4QA
#fp
А вот ссылка на упомянутую в докладе статью.
BTW бомбический весь сайт Maarten Fokkinga т.к. там у него пдфки всех его работ
Forwarded from DevOps&SRE Library
Are_you_ready_for_production.pdf
1.5 MB
Are you ready for production?

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

Видео: https://youtu.be/YptJ2rrGAYY
Forwarded from oleg_log (Oleg Kovalov)
68 постов и докладов о том, когда микросервисы не взлетели https://microservices.fail/

Бегло глядя вижу некоторые посты ни о чём, но некоторые хорошие и основаны на болезненном опыте. Советую полистать.

или просто ссыль на ехель док https://docs.google.com/spreadsheets/d/1vjnjAII_8TZBv2XhFHra7kEQzQpOHSZpFIWDjynYYf0/edit#gid=0

UPD: хах, зоопарк анонимных зрителей(вверху там аватарки с животными) взорвался после поста :D
I hate overtime
tapl.pdf
Вот, тащем-то, цитата-ответ на вопрос "зачем в ЯП вообще нужны типы":

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

To protect their frontiers from raids by neighboring nomadic warrior tribes, the early Chinese built the Great Wall. It was not an impenetrable barrier, but it allowed a regulated commerce with neighbors while providing an impediment to invasion and other unwanted influence. For two thousand years it defined a boundary that helped the Chinese agricultural civilization to define itself with less disruption from the chaos outside.
Although China might not have become so distinct a culture without the Great Wall, the Wall's construction was immensely expensive and bankrupted at least one dynasty, probably contributing to its fall. The benefits of isolation strategies must be balanced against their costs. There is a time to be pragmatic and make measured revisions to the model, so that it can fit more smoothly with foreign ones.
Forwarded from AvitoTech
Опубликована запись доклада Владимира Алёшина про хранимки с предновогоднего Постгрес-митапа

Хранимые процедуры рассмотрели с разных сторон: глазами DBA-инженера, разработчика баз данных и разработчика серверной части. Посмотрите, если интересуетесь темой → https://youtu.be/bZcwROoaqfs