Я стараюсь регулярно изучать новое и периодически пишу про разные курсы/платформы

Сегодня обзор Cloud Skills Boost oт Google. Это платформа для изучения Google Cloud Platform: различные стораджи, k8s, AI-ML и все остальное.

Есть курсы по темам, курсы объединены в Learning Paths по различным направлениям (Developer, SRE, Data Engineer, Architect, etc).

Курс – набор роликов, заданий, тестов и лабораторок. Все лабораторки проходят на предподготовленных учетках в GCP. Очень удобно и полезно, что это не просто какой-то урезанный тренажер, а полноценная учетка, которую можно использовать как через интерфейс, так и через их CLI gcloud.

Качество роликов среднее, по мне их слишком уж мелко нарезали. Тесты и задания адекватные.

Есть бесплатный доступ, но есть и подписка ($300 в год).
В подписку входит доступ к платформе со всеми лабораторками, ваучер на сертификат, $1000 на поиграться в GCP. Ваучер был успешно конвертирован в сертификат😎

Тест на сертификат проходит онлайн (есть опция и оффлайн). Используется специальный софт, который лочит лишние приложения и следит за поведением. Обмануть наверное можно, но там много что контролируется. 50 вопросов, надо выбрать единственный правильный ответ, писать ничего не надо. Сложность средняя, частично можно отвечать просто на общем опыте или путем исключения заведомо неподходящих вариантов, но, кажется, просто сходу не сдашь, нужен именно опыт использования – заучить это все крайне сложно. При успешном прохождении не раскрывают ничего про правильность ответов, так что я не знаю где я насколько я оказался хорош.

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

И да, минутка хвастовства: теперь я Клауд Архитектор https://www.credly.com/badges/b5d2acdc-9170-41e4-8f35-bbdf49190e68/public_url

#обучение

Попалась статья про концепцию The Synchrony Budget. Основной посыл: взаимодействие между сервисами
должно быть настолько асинхронным, насколько это возможно, и настолько синхронным, насколько это необходимо.
И вроде бы да: мир в котором мы живем в большинстве случаев асинхронный: мы асинхронно заказываем такси, асинхронно получаем аппрув на наше заявление об отпуске, асинхронно торгуем на бирже, асинхронно переводим деньги. И в целом strong consistency переоценена и редко где нужна.
Но как всегда everything is a tradeoff! Как монолит намного проще микросервисной архитектуры (рекомендую ознакомиться с fallacies distributed system), так и синхронное взаимодействие намного проще асинхронного.

Вот моя версия fallacies asynchronous communication:

Заблуждения об асинхронной коммуникации
Часто встречающиеся ошибки, из-за которых распределённые системы становятся хрупкими и непредсказуемыми

1. Инфраструктура надёжна, поэтому о согласованности можно не думать
Полагаться на то, что платформа “всё сделает правильно”, опасно
→ Реальность: Сеть может моргнуть, сервисы — упасть, сообщения — потеряться. Согласованность должна быть заложена в архитектуру.

2. Сообщения будут обрабатываться в том порядке, в котором были отправлены
Опираться на порядок событий — прямой путь к скрытым багам и несогласованному состоянию
→ Реальность: Порядок доставки не гарантируется — используйте ключи сортировки или обрабатывайте события с учётом возможной перестановки.

3. Каждое сообщение будет обработано ровно один раз (exactly once)
Ожидание, что каждое сообщение придёт ровно один раз, может привести к логическим ошибкам из-за повторной обработки.
→ Реальность: Почти все системы доставляют сообщения по меньшей мере один раз (at least once) — логика обработки должна быть идемпотентной.

4. В асинхронных системах нет гонок (race condition)
Асинхронность не избавляет от проблем с параллелизмом
→ Реальность: Задержки, повторы и параллельная обработка могут приводить к состоянию гонки. Требуется защита общего состояния и продуманная архитектура.

5. Консьюмер обработает сообщение быстро и предсказуемо
Расчёт на стабильное время обработки приводит к неправильным архитектурным решениям
→ Реальность: Обработка может занять секунды или минуты — в зависимости от нагрузки, состояния системы или внешних зависимостей. Нужно заранее определить: как долго ждать, когда реагировать, что делать при задержке.

6. Поддерживать контракты сообщений и отслеживать кто что продюсит и консьюмит просто
Игнорирование связей между компонентами приводит к неожиданным сбоям
→ Реальность: В асинхронных системах компоненты слабо связаны — используйте реестры схем, определяйте владельцев и версионируйте контракты.

7. Асинхронность снижает связанность (coupling), значит менять контракты легко
Считать, что слабая связанность позволяет менять сообщения без последствий — опасное заблуждение
→ Реальность: Форматы сообщений — это публичные API. Изменения должны быть обратимо совместимыми, задокументированными и согласованными.

8. Достаточно просто отправить сообщение — оно обработается
Игнорирование доставки приводит к потерянным данным и бесшумным ошибкам
→ Реальность: Без гарантии доставки и мониторинга невозможно быть уверенным, что сообщение дошло — используйте dead-letter очереди, логгирование и метрики доставки.

9. Повторить попытку — значит решить проблему
Безграничные повторы создают нагрузку, дубли и повторяющиеся ошибки
→ Реальность: Нужны ограничения на повторы, экспоненциальные задержки, таймауты и dead-letter очереди — повтор сам по себе проблему не решает.


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

Обсудим? Что добавили бы? Какой выбор по умолчанию у вас?

Очень полезная и практичная статья про то как развивать принятие архитектурных решений в компании https://martinfowler.com/articles/scaling-architecture-conversationally.html

Если коротко, то есть правило: любой человек может принять архитектурное решение.

Но перед принятием решения лицо, принимающее решение, должно проконсультироваться с двумя группами: Первая - это все, на кого решение окажет существенное влияние. Вторая - люди, обладающие опытом в той области, в которой принимается решение.

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

1. АДР - про них уже много писали и обсуждали в чате, можно почитать здесь https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records

2. The Architecture Advisory Forum - архитектурный советю По сути централизованное место для изначального ПРАВИЛА.

3. Общие архитектурные принципы. И это должны быть не просто лозунги типа KISS, DRY и прочего.

4. Свой техрадар https://www.thoughtworks.com/radar/byor


Подробнее как зачем и что читайте в статье

Есть отличная книга https://jacquiread.com/books/communication-patterns/

Джеки Рид пишет (и рассказывает на конфах) как правильно и нашем мире разработки и не только доносить свою мысль до целевой аудитории.

Сложно выделить какие-то отдельные поинты, это скорее сборник паттернов, рецептов и советов.

Книгу рекомендую как минимум полистать, а еще попалась шикарная преза, где эти паттерны собраны и красиво визуализированы

Не чекал полностью, ео вот и видео к презе https://www.youtube.com/watch?v=JUqrNWKPMYA

Можно использовать для быстрого погружения новичков или при подготовке к собесу, если вы не очень знаете DDD 🙈

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

В Португалии и части Испании глобальное отключение электричества. Света не было примерно 9 часов. Не было инета, мобильная связь работала местами и с перебоями. Кассы в Ашане пока работали, но не долго.

А как ваши системы пережили бы такое?

Дядюшка Боб ака Роберт Мартин неплохо вчера накинул на sql. Основной тезис в том, что зря мы взяли текстовый контракт для взаимодействия и нам нужно полноценное апи

Недавно дискутировал с коллегой про виды двойников (aka test doubles). Я отстаивал право на существования фейков, он топил за то что есть моки, а остальное и не надо вовсе. Этому спору лет 20 на самом деле, и там сломано столько копий, что уж и не сосчитать. И конечно, я не собираюсь сейчас объяснять какой подход лучше. Всем и так очевидно, что тот где тестируется состояние с использованием фейков, Object Mother и прочего.

Но мне стало интересно, что говорят наши Лучшие Лидеры Мнений (то есть LLM).

Подготовил максимально нейтральный промпт:

Provide an example unit test for methods that involve interfaces in .NET 8, using any public libraries.

и прогнал его через несколько моделей (sonnet, gemini, grok, gpt, deepseek...):

Все модели в своих примерах использовали xunit и moq (самая популярная библиотека в дотнет мире для мокирования). Думаю, что подход с моками сейчас в лидерах и дальше он будет набирать все большую долю, так как новички и кодогенерация будут использовать моки все чаще и чаще. Ведь если либа-утилита используется в ответе без явного упоминания – это хороший знак! Ее начинают использовать, новый код опять подтверждает приверженность этой либе и еще чаще попадает в ответы.

Кажется, что технопиар должен быть сейчас направлен на то, чтоб либа попала в кодогенерацию, этакое новое SEO. Может даже появятся профессия вроде Prompt Evangelist или LLMRel – человек, который убеждает модели выбирать правильную либу.

Как-то я привык, что про DDD говорят и пишут преимущественно разработчики. Поэтому особенно рад поделиться этой статьей от продакта/аналитика Иннокентия Бодрова. Возможно, опытные завсегдатаи и не найдут много нового в статье, но можно взять в закладки, чтобы кидать своим продактам или аналитикам.

https://habr.com/ru/articles/908782/

Плюсики на хабр, вопросы и комментарии – сюда, @InnokentyB с нами

Можно по-разному относиться к вайб-кодингу и кодинг ассистентам, но так или иначе подход к разработке уже поменялся и будет меняться дальше. И надо знать не только сильные стороны, но и уязвимые места. В блоге у Фаулера вышла новая статья с обзором некоторых возможностей потенциальных проблем. https://martinfowler.com/articles/exploring-gen-ai/software-supply-chain-attack-surface.html

Ого, JetBrains выпустили решарпер для VSCode. А значит пользоваться курсором/виндсерфом станет чуточку удобнее!

https://marketplace.visualstudio.com/items?itemName=jetbrains.resharper-code

На днях рефлексировал свой и индустриальный опыт внедрения DDD (BDD, Pair Programming, допишите свое). Выводы не утешительны: почти всегда, а особенно при давлении сроков, легаси, окружения разработчик выберет то что привычно. Как говорил Макс Дорофеев:

наша обезьянка между важным и срочным выбирает... Простое и понятное!

Так и в разработке (и любой другой деятельности) все новое и непонятное отторгается.
Новое требует больше энергозатрат твоего мозга!
Новое снижает твою экспертность, только что ты был синьором, а тут какой-то агрегат надо выделить!
Новое опасно, вдруг сроки поедут и начальник заругает.

И если это так страшно и затратно, то зачем? Не жили богато, нечего начинать.

Что же делать? Искать единомышленников!

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

Если вы обычный гребец разработчик, то все сложнее, но вот что можно попробовать:

1. Рассказывайте! На кухне, в слаке, на внутренних митапах, на больших конференциях. Подкидывайте твиты, видеоролики. Возможно в компании есть единомышленники, но вы друг про друга даже не знаете.
2. Если у вас принято приглашать на внутренние митапы внешних экспертов, то попробуйте сами договориться с кем-то кто продвигает нужную вам повестку. Люди доверяют внешним экспертам.
3. Если в компании используется нужная вам практика, но не в вашей, а в других командах, можно договориться об интро или даже о полноценном погружении внутри той команды или позвать к себе представителя команды.
4. Договоритесь о небольших экспериментах внутри команды, если тиммейты вас поддержат – можно будет регулярно практиковать на живых задачах, набирать уверенности, экспертности, кейсов для демонстрации профита и прочего.

Поделитесь вашим опытом – что сработало, а что оказалось бесполезным?

Продолжаю придерживаться принципа life long learning — считаю, что техническому лидеру важно не останавливаться в развитии и стараться смотреть шире своей текущей зоны ответственности. Поэтому начал новое обучение: на этот раз в «Школе СТО» от Стратоплана. В среду прошла установочная сессия. Впереди пять месяцев интенсивной учебы.

Процесс "поступления" простой, но не бесполезный. Есть вступительное задание (в том числе разбор кейса), есть интервью с тренером. Основная цель – сформировать ожидания и убедиться, что обучение закрывает эти ожидания (хотя бы большую часть).

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

Задача со звездочкой для меня - подсмотреть как организован процесс обучения. Где-то пылится https://dddcourse.ru/ и ждет своего звездного часа.

Если у вас есть опыт прохождения подобных программ или рекомендации по обучению для технических лидеров — делитесь, интересно услышать чужой опыт.

#обучение

Коллеги из Virtual Domain-Driven Design проводят митап с Владом Хононовым.

Тема встречи — модель Balanced Coupling.

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

Balanced Coupling — подход к оценке связности компонентов по трём измерениям:
- Сила интеграции (Integration Strength) — насколько сильно модули “знают” друг о друге.
- Дистанция (Distance) — как далеко друг от друга расположены компоненты в системе.
- Изменчивость (Volatility) — как часто компоненты подвергаются изменениям.

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

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

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

Забавно, что раскрывают тему с разных, зачастую противоположных, точек зрения: один говорят, работай, солнце еще высоко и тебе воздастся, другой, что это рабство и надо избегать (или бежать, раз вляпался). Обсуждения тоже достаточно поляризованные, кто-то поддерживает одного из спикеров, кто-то наоборот.

Правда в том, что истина где-то рядом посередине (или как здесь принято говорить everything is a trade-off). С одной стороны убегать при первых же трудностях и несовершенствах — признак слабости и непрофессионализма. С другой — надо беречь себя и время и уметь отказываться от минусовых (на дистанции) проектов.

В одном из обсуждений я узнал про такую концепцию как

Кюль-де-сак (от франц. "тупик"). Это ситуация, когда вы трудитесь, трудитесь, трудитесь, и ничего особенно не меняется. Не становится гораздо лучше, как и не становится намного хуже. Все остается как обычно. Подобные занятия называются бесперспективными. Цитата из книги Сета Година Яма.

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

Важно понимать следующее.

1. Изнутри кюль-де-сака сложно понять насколько глубока пропасть. Здесь можно взять на вооружение трейдинговые стратегии: установить для себя “тайм-стоп” или “стоп-лосс” — заранее определить, сколько времени/усилий ты готов вложить в проект, прежде чем он начнёт приносить отдачу. Иногда лучший ход — это выйти из позиции, зафиксировать моральный убыток и направить энергию в актив с лучшей потенциальной доходностью.
2. Кюль-де-сак субъективен. Что одному нераспутываемый спагетти-легаси-худший-код-все-тлен, для другого пройденный этап и возможность полирнуть свои навыки внедрения инженерных практик, использования паттерна Strangler Fig и проведения сессий Ивент Шторминга. Выбирай епанчу по плечу!
3. Иногда кюль-де-сак видно на входе. И это отличный способ сделать левел-ап. У меня есть опыт, когда я понимал, что шансы невелики, но очень хотел получить тот опыт. Цели не достиг, но ни о чем не жалею и сейчас поступил бы так же.
4. Не забывайте, что в нашей индустрии непрерывное развитие критически важно. Бывает так, что вроде ничего вокруг не меняется, все тухло, но понимаешь, что сам растешь (об коллег, новый стек, новые подходы, новую проблематику). И это не самый плохой вариант. Желательно в таком случае иметь большую насмотренность, чтобы не перенять все стремные практики как оптимальные и единственно возможные.

Сейчас практически все компании внедрили практику System Design Interview. Наверное большинство так или иначе сталкивались с такими собесами. Если коротко: дают задачу, надо спроектировать примерно как будет выглядеть система для решения задачи.

В сети много мануалов, видео, мок-интервью и прочих материалов. Обычно советы сводятся к следующему:
1. Не бросайтесь сразу что-то делать, осмотритесь, разметьте территорию.
2. Проясните неясные моменты или сами явно проговорите какие-то допущения-предположения. Какая нагрузка, что можете, а что не можете использовать, какие ожидания по консистенси и тп. Что-то неясное можно припарковать (тоже явно сказав об этом).
3. Опишите какие блоки вы видите.

Лучше все это делать с шаренным экраном и фиксировать в miro/unidraw — так и вы не забудете, что о чем-то договорились, и интервьювер лучше поймет куда и как вы идете.

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

1. Event Storming — куда без него. На одном из интервью я провел миништорминг сессию: прям накидал перед собой события которые есть в системе, отметил системы, людей, наметил границы. Собственно этой сессией я закрыл перечисленные выше пункты. не обязательно упарываться, можно начать просто с событий, это уже даст некоторую базу.
2. Домены. Если вы видите, что задача включает в себя generic и supporting домены, то можно сразу сказать, что вы не планируете это проектировать в рамках интервью, вы возьмете готовый продукт или известную реализация и просто заиспользуете. Например вы не будете писать свою аутентификацию. Повторюсь еще раз — важно все проговаривать вслух, возможно вы не заметили какое-то особенное требование и то что вы считали генерик доменом, на самом деле кор. Нормальный интервьювер вам подсветит, что ваше допущение не ок.
3. Все усилия на core. После того как мы отсекли генерик домены, остался кор — его и будем проектировать. Возможно вы заметите два кор домена, контексты и прочее, что вас подтолкнет к созданию распределенной системы (ака микросервисы).

Где и когда использовать:
Если в компании практикуют DDD (или хотя бы в описании вакансии были эти буковки), то такой подход может вам набрать дополнительные плюсики. Будет понятно, что вы написали про Domain-Driven design в резюме не просто так, а регулярно используете в реальной жизни.

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

А какой у вас опыт использования DDD на собеседованиях? Спрашиваете ли вы сами как интервьюеры? Как относитесь к кандидатам с DDD бекграундом?

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

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

Сразу оговорюсь, что для разных компаний, разных этапов, разных конфигураций могут требоваться разные компетенции. Но если брать СТО средней компании, то ребята топят за сильную техническую составляющую. ТО есть важно нее просто знать какие-то вещи, но и уметь их готовить. И среди прочего в список необходимого попал Domain-driven design.

Так что ждем светлого будущего, когда СТО будут всячески провоцировать внедрение и использование DDD в компаниях.

Как ваш СТО относится к DDD и прочему technical excellence? Топит за такое или наоборот считает баловством?

#обучение

Очередной модуль Стратоплана идеально лег по таймингу на инфоповод от Аэрофлота: обсуждали ИБ. Без особой глубины и в целом с этой областью я знаком (даже как-то вел инфобез в региональном вузе 🥸). Синтезируя стратоплановские знания и мои хотел бы выделить заблуждения и важные моменты:

Частые заблуждения (например их можно встретить в постах людей, никак несвязанных с ИБ)

1. Взлом — значит безопасники недоработали/неквалифицированные!

Конечно же это не так в общем случае. Безопасность это всегда трейдофф: бюджет, удобство, регуляторка и прочее.

2. Можно построить 100% защиту! 

Нет, нельзя. Всегда остаются учтенные и неучтенные риски.

3. У нас в компании меняют пароль 300к раз в секунду, а у них три года не меняли: вот он руткоз!

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


Что важно знать разработчику/менеджеру про ИБ:

1. Это отдельная область в которой много интересного, но и надо многое знать. Нормально, если лично вам интереснее другое.

2. Почитайте owasp, хотя бы топ 10 https://owasp.org/www-project-top-ten/) Если занимаетесь использованием ЛЛМ — вам отдельный топ https://owasp.org/www-project-top-10-for-large-language-model-applications/

3. Про книги: читал только одну https://www.ozon.ru/product/zashchishchennyy-kod-1387492. Ей больше 20 лет, но базовые вещи хорошо раскрыты. Еще буквально только что попалась на глаза рекомендация этой книги https://www.manning.com/books/software-security-for-developers. Если у вас есть рекомендации — велком в комменты.

4. Развивайте комьюнити. Безопасность — это не сторонняя активность, а скорее майндсет. Это должно быть вплетено в процесс разработки от проработки фичи до конечной реализации и эксплуатации.

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

6. Если у вас есть баунти программа и внешний аудит — делитесь результатами (если, конечно, с предыдущим пунктом нет проблем. На одном из прошлых мест наш верховный инфобезопасник (Саше привет 👋) делал пятничный дайджест задетекченных атак, находок сканнеров и баунти — разработчики очень включались.

7. Обучение, обмен опытом — мастхев. Достаточно динамичная область, постоянно выходит новый тулинг (как для атаки, так и для защиты), новые атаки, новые уязвимости. Кому-то надо держать руку на пульсе и опылять остальных.

#обучение

Двойная концентрация Кириллов в эфире! https://www.youtube.com/watch?v=03FnrgYLkV8

@mokevnin и @kirill_vet обсудили DDD, Event Storming и все вокруг

Когда-нибудь у меня будет пара часов посмотреть внимательно выступление и походить по ссылкам и референсам. А пока просто прикопаю это здесь https://www.youtube.com/watch?v=wo84LFzx5nI