Отличная подборка книг 📚

Robert Laszczak поделился данными о продажах своего кнового курса Go Event-Driven. Такая история успеха безумно мотивирует, но когда осознаешь сколько труда под капотом, ловишь себя на мысли “может ну его”)

Друзья, наверняка, кто-нибудь уже вовсю экспериментируют с chat gpt. Поделитесь интересными находками с точки зрения помощи разработчику)

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

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

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

Enjoy! https://www.youtube.com/watch?v=1ZyR_tgGTp8

Новый радар вышел. Посмотрим что интересного https://www.thoughtworks.com/radar

Для затравки три блипа
1. https://www.thoughtworks.com/radar/tools/eventcatalog каталог событий. Интересная задумка, надо покопать.
2. https://www.thoughtworks.com/radar/techniques/run-cost-as-architecture-fitness-function Все так или иначе начинают думать про стоимость работы кода.
3. https://www.thoughtworks.com/radar/techniques/zero-trust-security-for-ci-cd весь апрель никому не верь, а ci\cd - не верь никогда)

https://habr.com/en/companies/flant/articles/732152/

Отличный дайджест для #k8s от коллег из Фланта

Всегда интересно почитать про DDD за пределами моего информационного пузыря 🤓

Domain Driven Design

Domain Driven Design (DDD) – на первый взгляд, что-то такое сложное. Да и на второй тоже сложное. Не очень понятно, с чего начинать.

Начать можно со статьи Domain-driven design: рецепт для прагматика.

Автор на примерах проходится по основным концептам DDD:
– ubiquitous language – всё обсуждение происходит в терминах единого языка
– domain model – некий набор сущностей и сценариев, связанных с предметной областью
– bounded context – некие рамочки, в которых существует доменная модель и единый язык

Основная идея DDD – борьба со сложностью бизнес-процессов, их автоматизации и реализации в коде. Domain – предметная область и от неё нужно отталкиваться при проектировании и разработке.
Бороться со сложностью – звучит многообещающе, но "прежде чем начать бороться со сложностью с помощью Domain-Driven Design, нужно научиться бороться со сложностью самого Domain-Driven Design".

Не факт, что будете применять, но знать что это за зверь – стоит. К тому же, можно перенять некоторые полезные практики, например, ubiquitous languge – единый язык общения. На эту тему написан занимательный комментарий, что пример, приведённый в статье из мира продаж всем понятен, тривиален и нет смысла для него составлять ubiquitous languge. На что ему приводят такие термины из мира продаж: ретроскидка, скидка по фактуре, ценовое соглашение, отличное от базового и др. Кажется, не всем понятно. Это я к тому, что использование ubiquitous languge в любой области облегчит взаимодействие.

Можете посоветовать что-то толковое на тему DDD?

#skills

Кстати про нейминг, пропустил отличную статью от коллег из Додо https://habr.com/en/companies/dododev/articles/714512/

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

Продолжаем тему нейминга. Неплохой и местами капитанский доклад https://youtu.be/KHgftXIlGsY

Вы обсчитываете свои изменения по скарфу? Тогда мы идем к вам!)

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

К сожалению или к счастью, эволюция нашего мозга такова, что всю новую информацию он классифицирует либо как угрозу, либо как вознаграждение. При этом, проявлять интерес к чему-то новому он способен только будучи в безопасности. Почему это важно учитывать? Давайте на примере:

Петя, из-за тебя релиз вышел на три дня позже срока и всем пришлось работать до ночи. Заказчик был очень недоволен. Разве сложно написать три строчки кода, чтобы покрыть изменения после фикса бага?

Петин мозг в данном случае воспримет эту ситуацию как прямую угрозу жизни. Он, конечно, постарается сделать все, чтобы ее исправить, но осадочек, что называется, останется. И в тот момент, когда вы будете ему рассказывать про tdd, подсознательно его больше будет волновать тот факт, что если он опять накосячит с тестами, то его вышвырнут на улицу, а попробовать что-то новое без косяков невозможно, поэтому да ну его.

Как это исправить? Для этого умные люди придумали SCARF-модель, которая построена на удовлетворении 5 критически важных для мозга социальных потребностях: статус, определенность, автономность, принадлежность и справедливость.

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

Опустим закадровое желание побить Петю и посмотрим, что дает такая формулировка:
🔹+2 к статусу ("без тебя не смогли", "нам важна твоя работа")
🔹+1 к определенности (ты, конечно, налажал, но мы тебя не выгоняем)
🔹0 про автономность (увы)
🔹+1 к принадлежности ("команда")
🔹+1 к справедливости (ты что-то сделал, оно привело к таким-то последствиям, вот что тебе нужно сделать, чтобы исправить ситуацию).
Итого: 5 баллов.

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

Захотел загуглить какую-нибудь статью про System Design. Правктически вся выдача про System Design Interview. Такое ощущение, что данный термин стал использоваться только в контексте собесов 😅

Читал вчера статью Маттиаса Верраеса про Segregated Event Layers и внезапно узнал, что это серия статей о паттернах в контексте DDD и Messaging Architecture

https://verraes.net/2019/05/ddd-msg-arch/ Enjoy!

Kenny Baas-Schwegler и Virtual DDD приглашают на встречу с Udi Dahan. Крайне рекомендую послушать. Также есть возможность заранее задать свои вопросы

https://www.meetup.com/virtual-domain-driven-design-meetup/events/294468728/

Хорошая новость: ACM опять договорился с O’Reilly, а заодно с Pluralsight и Skillsoft Percipio. И у них по-прежнему есть скидка для России (стоимость подписки $40 в год).

Плохая новость: Теперь это дополнительная платная опция (+$75 в год), да и курс с тех пор немного вырос.

Предложение теперь не такое заманчивое как раньше, но 1000р в месяц не выглядят такими уж безумными за пакет из 4 подписок (сам АСМ + три сторонних). Одна годовая подписка O’Reilly стоит в пять раз больше.

https://learning.acm.org/skills-bundle

Неплохая подборка видео про DDD и около.

https://x.com/mjovanovictech/status/1695752490069762490?s=46&t=ExJM-wcqikMl9I7JeOzofA

P.S. Из очевидных плюсов – очень понятный по произношению английский 😅

Event Sourcing — это паттерн проектирования в информационных системах, который заключается в сохранении состояния системы путем сохранения истории всех событий, происходящих в системе.

Вместо того, чтобы сохранять текущее состояние объекта, система сохраняет все события, произошедшие с объектом, и воссоздает текущее состояние, используя эти события.

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

➖Хотите узнать подробнее, что такое event sourcing и какие преимущества и недостатки он имеет?
➖Хотите понять, какие трудности могут возникнуть при использовании этой технологии?

Тогда присоединяйтесь к нашему вебинару «Плюсы, минусы и подводные камни Event Sourcing», который состоится 28 cентября в 19:00 МСК

На вебинаре Станислав Щетинников из Сбера подробно расскажет о том, как на самом деле работает event sourcing, какие задачи он решает и какие преимущества он имеет. Мы также рассмотрим недостатки этой технологии и поделимся опытом в использовании event sourcing в реальных проектах.

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

✔️Подробности и регистрация