#интеграция #API

Пережили конфу, в субботу начнем десятый поток курса по проектированию API.

С одной стороны, это Yet Another REST API Course для джунов-миддлов, чего вы там не видели? Люди знакомятся c HTTP, учатся делать типичный REST API, тестить и документировать сервиcы.

С другой - все чаще вижу на занятиях сеньоров и лидов. Зачем им это?

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

“Делать правильно” никому не нужно. Важно спроектировать API, которое не превратится через полгода в нечитаемое месиво, а под каждую доработку не нужно будет втыкать костыли на каждой стороне. Для этого мы разбираем уровни зрелости REST API, их границы применения, и когда стоит использовать RPC API.

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

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

Так что приходите за обязательной базой или расширением горизонтов. 5-23 апреля, рега тут.

План конференций на апрель:

— 11 апреля StormConf, о которой уже писал. Кто вживую собирается?

— 12-13 апреля Systems Design Online с большой секций по архитектуре

— 25 апреля DUMP в Екатеринбурге, буду рассказывать про API как продукт

— 26 апреля открытый Flow в олнайне, там вещаю про фейлы, которые собрали при проектировании этого API

Как бы еще везде успеть и выжить, пожалуйста.

Вот да

🔥 Снижай драматизм: уроки от Slack

Давайте сразу: проект провалился. Все, расходимся, жизнь кончена?! Да хрен там плавал!

Вот история Slack, который вырос из игры Glitch. Если по-простому: ребята несколько лет делали онлайн-игру, вбухали кучу денег и сил, но все никак. Игрушка не взлетела. Что, плакать и расходиться? Нет, они закрыли проект без лишних слез и заметили, что внутри команды круто работают их же внутренние чаты. И сделали пивот в корпоративный мессенджер. Теперь весь мир знает Slack.

Вспомнил себя, когда делали стартап: один релиз отложили — и все, истерика, как будто мир рухнул. Да-да, тоже бил кулаком по столу и вопил, что это «вопрос жизни и смерти». А зачем? Чем выше накал, тем меньше мозгов остается на поиск нормальных решений. Проверено лично.

Где логика в том, чтобы загонять команду в панику и драматически орать «мы горим!»? Это тупик, господа.

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

А у вас бывали пивоты в карьере или проекте, которые внезапно «выстреливали»?

Карьера продакта

Кто о чем, а мы о сисдизайне

Пара ссылок для тех, кто проводит собесы, организует процесс найма, увлекается проектированием.

Стрим с Филом Дельгядо о сисдизайне на интервью

Несколько тезисов:

— Секция сисдизайна не показывает, может ли человек проектировать системы в рамках своих задач - внезапно, да?

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

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

— Единообразие и прозрачность обычно противоречат эффективности. В том числе в найме.

— Отдать найм в команды, может быть намного эффективнее, чем делать его централизованным.

В целом рекомендую его выступления - живое руководство по критическому мышлению.

А вот доклад Александра Поломодова, как и почему проводят сисдизай секции в ТБанке

#архитектура

#архитектура

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

Если конкретнее, мы берем реальные задачи из разных доменов и проходим весь путь проектирования решения: от выявления требований к декомпозиции системы на сервисы, выбору технологий, проектированию апи и модели данных. Никаких книжных ютубов, url-shortner’ов и key-value хранилищ, с которыми вы никогда в жизни не встретитесь.

Вот примеры некоторых кейсов: выпуск и доставка карты, умная лента заказов для маркетплейса, система A/B-тестов, риалтайм доска “миро-заменитель”.

В субботу пилим онлайн-чат со службой поддержки. Фича, которую вы можете встретить почти в любом своем приложении. Будем работать с высокой нагрузкой, думать о масштабировании, выбирать read / write модели и типы хранилищ, сравнивать способы интеграции с точки зрения реализации НФТ.

Суббота, в 10:00 мск, рега тут

#оффтоп

Не пускайте детей в интернет, он от этого тупеет - предупреждали нас в старых злобных рунетах.

Интересно, понимал ли автор, на сколько точно его фраза будет отражать реальность эпохи LLM?

У нас постепенно распространяется роль техпродакта, но пока нет единого мнения, что это за зверь. Поэтому сегодня делаем стрим с Леной Царьковой - техпродактом из Авито, в прошлом СА.

Сегодня в 19:00 мск, рега тут.

И думаю, он будет не последним.

#образование

Галлюцинации LLM - это не баг, а мега фича для образования.

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

Почему этот же паттерн не срабатывает при обучении у других людей?

Есть мировые авторитеты, условные Ричардсон, Ньюман, Фаулер, еще кто. У них большой опыт разработки, огромный в консалтинге, тысячи часов размышлений над темой. Значит ли, что их предпосылки и выводы всегда верны? Значит ли, что их опыт переносим в вашу сферу?

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

За ними идут эксперты с авторскими программами, где они напрямую делятся опытом. Но не такие известные в комьюнити. Значит ли, что их опыт “хуже”? Конечно, нет. Но и споров и челленджей со стороны комьюнити они могли пережить меньше. А могли больше.

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

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

Галлюцинирую - значит, существуют

Сейчас не особо слежу за около аналитическими каналами, но один из тех, что читаю - Системный сдвиг от Юрия Куприянова. Как по мне, самое ценно там - это комплексный взгляд на создание it-решений: от продукта и бизнеса, до архитектуры и технических деталей. Т.е. мышление аналитика здорового человека, а не “дайте требования, я вам апи и сиквенсы нарисую”.

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

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

Примеры интересного:

— инфографика с основными способами интеграции

— чек-лист стандартов в области интеграции и API

— 10 техник проверки полноты требований

— скрытая работа по проектированию систем, которую выполняет системный аналитик

— применение ChatGPT в работе системного аналитика: раз и два

А еще недавно Юрий был у нас в гостях, обсуждали профессию, перспективы, тренды и много всякого.

#конференции

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

С какого-то момента междисциплинарные конференции стали куда интереснее за счет знакомства и общения с людьми из смежных ролей - их боли, проблемы, мысли дают куда больше инсайтов, чем очередной спич на профильной конфе. Поэтому если вы скучающий сеньористый сеньор, то попробуйте сгонять на подобное событие. Где еще вы будете обсуждать с ML-лидом использование ТРИЗ на собесах в 4 утра?

От себя выделю доклады:

 • Наталья Потемина - о противостоянии продукт vs коммерция-маркетинг. Рыдал, когда слушал, ибо вот прям все болячки из доклада собрали на последнем проекте.

 • Александра Брызгалова - еще один взгляд со стороны теории ограничений на “эффективность”, личную и командную. Что это такое, и почему больше и быстрее - не значит лучше.

 • Даниил Смирнов - как продакты убивают бизнес, или почему критично важно участвовать в продажах, если вы работаете в b2b.

Краткая мораль
Если вы избегаете продаж, то вы не продакт, а товаровед (с) Саша Брызгалова

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

Спасибо DUMP и до встречи через год ❤‍🔥

Жертвы Шторма

Есть у технологий ранние последователи, есть и ранние жертвы. У меня такое случилось с Event Storming.

2017 год, зима, летим к заказчику делать интеграцию на микросервисах. Тогда со всех сторон кричали, что MSA - это новый ESB высшая ступень эволюции, DDD познавали по Вернону, а об Event Storming’е перешептывались в углах избранные. Вот и мы наслушались шепотов.

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

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

На выходе осталась некоторая недосказанность:

- Как запихнуть гигантский ватман в самолет, чтобы не отвалились стикеры?

- Что нам теперь с этим делать?

- Как объяснить заказчику, ради чего мы потратили столько времени и денег?

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

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

• Екатерина Пантелей - системный аналитик

• Ольга Бугаева - руководитель продукта

• Евгений Асламов - архитектор

Приходите, сэкономите на ватманах.

📆 13 мая, 18:00 мск, рега тут

Профит Шторма

Справедливости ради, профита Event Storming принес больше, чем боли и страданий. Чем помогал лично мне:

• быстро вкатиться в новый проект или предметку

• познакомиться и наладить контакты со стейкхолдерами и командой

• выявить конфликты и разночтения между бизнес подразделениями - внезапно, представители бизнеса часто имеют разное представление о реальных процессах

• разобраться в работе системы, когда совсем нет документации

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

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

😱 Если хочется просто поговорить о проблемах Event Storming, то приходите сегодня в 18:00 мск на вебинар.

Как же AI может заменить аналитика, если нужно работать с заказчиком, который не знает, чего хочет? Да вот так.

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

Как должно работать:

1. Даете доступ к своей базе знаний

2. Подрубаете сервис ко всем каналам связи с заказчиком

3. На основе встреч и переписки сервис генерит требования и проверяет их на полноту и противоречия. Если что-то не так - сигнализирует об этом

4. Формирует доки: BRD, C4, что-то еще

5. Создает таски и трекает корректность реализации - тут я не понял, как

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

Да, сомнительно с точки зрения безопасности. Да, больше заточено под типовую разработку и внедрение. Уверен, работает раз в 10 хуже, чем обещают. И все равно нужен будет живой эксперт.

Но все это неважно. Пройдет 3-5 лет, ребята дотюнят модели, выпустят on-premise версию, а корпораты начнут экспериментировать со своими ассистентами по требованиям. И вот зачем толпа аналитиков продакту, проджекту или техсейлзу с таким инструментом - большой вопрос.

Кстати, Александра подогнала расшифровку своего доклада. Очень советую почитать: https://bryzgalova.ru/effectiveness

А Катя собрала классную подборку шаблонов для Event Storming

Подборка шаблонов для EventStorming
Если вы планируете сессию или просто хотите разобраться в подходе — вот несколько полезных шаблонов и инструментов:

🔶 Unidraw — инструмент не плохой, но после внимательного изучения шаблона у меня остались вопросы. Интересно, кто пользовался — как вам?
🔶 Miro — классика. Именно с неё я начинала и до сих пор люблю за стабильность и адаптивность.
🔶 Excalidraw — скорее пример, чем шаблон. Но для старта может быть очень полезен — просто, быстро, понятно.
🔶 Figma — забавно, как чётко расписаны первые 4 шага. Но вот когда речь доходит до Process Modeling — тишина. Хотя в целом шаблон зачетный.
🔶 GitHub — настоящая сокровищница. Много полезностей в одном месте, и видно, что автор явно читал ту самую книгу по EventStorming. Советую заглянуть!

💾 Сохраняйте в закладки — даже если сейчас ES вам не нужен, уверена, тренды от международных коллег до нас точно дойдут. А шаблоны пригодятся 😉

Свой шаблон тоже сделала, ими поделюсь немного позже отдельным постом для 3 инструментов)

#eventstorming #шаблоны #аналитика #системныйаналитик #itинструменты

Выложили запись стрима о проблемах ивент шторминга, наслаждайтесь.

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

Начинаю марафон конференций

Analyst Days. Основы криптографии для аналитика - интерактивный доклад / воркшоп, чтобы познакомиться с основами, на которых строятся защищенные протоколы, подписи, сертификаты и прочие слова из лексикона безопасников.

Codefest. CAP-теорема в теории и на практике - доклад-размышление о том, почему ACID, CAP и прочие академизмы куда важнее изучения очередных паттернов и технологий. Навеяно постом.

ЛАФ. Как брокеры не гарантируют доставку сообщений - воркшоп, чтобы разобраться в природе гарантий доставки, и существуют ли они вообще. Развитие идей постов: раз и два.

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

#конференции

#конференции

В субботу провел воркшоп на Analyst Days. Познавали азы криптографии и переизобретали TLS. Участникам спасибо за работу, вроде тема зашла. Мб сделаем продолжение.

Немного ссылочек для закрепления и дальнейшего погружения, как обещал:

• Основные понятия криптографии

• Глубокая статья про шифрование, TLS, сертификаты и вообще все необходимое

• PKI - инфраструктура открытых ключей

При желании закидывайте отзывы, камни и вопросы в комменты.