Yet Another Burakov

Доработать систему или выделить новый сервис? Прилетает задача на новую фичу или процесс, собираемся командой, открываем архитектуру и начинаем холивар: в какую систему запихнуть новую функциональность, не выделить ли её в новый сервис. Было такое? Обычно мы думаем про бизнес-домены, в сложных задачах беремся за Event Storming и DDD. Но можно зайти с другой стороны и посмотреть на задачу через типичные архитектурные свойства: ▫️ требования к нагрузке и масштабируемости ▫️ актуальность и согласованность данных ▫️ используемая инфраструктура и её ограничения ▫️ и другие факторы, которые бывают не менее важными, чем границы домена На практическом вебинаре разберём подход, который позволяет системно подойти к задаче «где реализовать фичу», а не по принципу «кто громче крикнул». Потренируемся аргументировать решение так, чтобы холивар прошёл максимально конструктивно и закончился на первом созвоне. 🥷 Ведущий: Андрей Бураков — разработчик, аналитик, продакт 📆 11 ноября, среда, 18:30 мск Вебинар проходит в поддержку курса «Интеграция и архитектура систем». Новый поток стартует 14 ноября, а до 11 ноября действует ранняя цена. Для участия подпишитесь на каналы: • @techanalyst_club

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

кстати, мы наачинаем

Лысый из Амазона утверждает, что нужно думать не о том, что изменится завтра, а что останется неизменным через 10 лет. На счет 10 лет хз, но уверен, что в ближайшие 3-5 лет не куда не исчезнет и даже усилится потребность в инженерном мышлении. Ибо чем ближе сейчас задачи к коду и реализации, тем лучше с ними справляется иишечка. А вот чтобы грамотно определить контескт и скоуп задачи, выявить значимые ограничения, сформулировать качества подходящего решения все еще нужен человек. Причем человек, который умеет проектировать-анализировать возможные решения и работать с трейдоффами, а не только пихать везде знакомые паттерны и модные технологии. Кто еще не догадался, это приглашение на курс по интеграции и архитектуре систем, который стартует в субботу, 14 ноября. Пересказывать программу не буду, ее можно посмотреть на сайте. Подчеркну три идеи, на которых строится курс: — учимся самостоятельно рассуждать, анализировать незнакомые задачи, развиваем инженерное мышление — мы занимаемся проектированием распределенных систем - можно сколько угодно разбрасываться паттернами и называть это System Design, но с базовой базой придется подружиться — погружение в нюансы технологий: сети, инфра, хранилища - это важнее, чем бесконечно рассуждать "как правильно выбрать Х" Чтобы не продавать кота в мешке, традиционно предлагаю: • посмотреть анонимные отзывы последних трех потоков, без цензуры • заглянуть в среду на вебинар про выделение сервисов под новые фичи • писать любые вопросы в комменты или в личку @and_burakov До среды еще ранняя цена действует, запрыгивайте.

Кстати, все чаще всплывает мнение, что любой харнесс живет от модели до модели. Антропики уже давно рекомендуют каждые 3-6 месяцев сносить всю обвязку и тестить голую модель. Кто-то уже предлагает забить на харнесс и сфокусироваться на грамотном формировании и вызове памяти. Мол с остальным справятся модельки. Тем более странным мне видятся попытки делать универсальный харнесс, который не зависит от модели — как будто это попытка усреднения сильных и слабых.

Сколько же мистики и магии собирается вокруг AI. Интересно, с интернетом так же было 25 лет назад? Сначала были промпты. Берите промпты, у нас лучшие на диком западе, на все случаи жизни. Учитесь промпт-инжинирингу, это профессия будущего. Вроде отпустило, но до сих пор есть отголоски. Потом все помешались на скиллах. Посоветуйте библиотеку скиллов, вот магазины скиллов, нужно больше скиллов. А знаете, чем отличается скилл от промпта? • Скилл — это обычный промпт, который сохранили в файле, дали ему название и добавили описание • Вызывать скилл может не только человек, но и агент, по своему усмотрению, в какой-то И все. Агент — программа, которая в процессе работы обращается к модельке для принятия решений. Субагент — новая сессия агента со стартовым промптом, с возможностью определить другие права, модель, подгрузить что-то еще в контекст. Секонд брейн — помойка из связанных md-файлов, которые регулярно читает и обрабатывает моделька по каким-то правилам. Дримс — джобы, которые регулярно срабатывают и обрабатывают накопленную в проекте инфу по какой-то логике. Ну и дальше харнесс, рой агентов, семантический слой и т.д. Не сказать, что все это не работает, и вообще маркетинговый буллшит, но есть ощущение, что люди все чаще гонятся за модными штуками в надежде, что они волшебны образом решат их задачи и проблемы. Неплохо бы разобраться перед этим, что там под капотом, и как оно работает. Причем в большинстве случаев это намного проще, чем те же распределенные системы.

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

#оффтоп Прастити, ору. Цитата из вакансии:

Роль подойдёт тем, кому комфортна прозрачность, регулярная коммуникация и работа в матрице.

Никогда, вас устроит никогда?

Trade-off analysis как инструмент инженерного мышления, или почему вам не нужны чек-листы В работе или на собеседованиях регулярно возникают вопросы «как выбрать»: ▫️ технологию или протокол взаимодействия ▫️ хранилище данных ▫️ подходящий паттерн ▫️ одно из нескольких решений конкретной задачи Часто в такой ситуации люди ищут ответ в чужих чек-листах, статьях и видео с критериями выбора, историях коллег в духе: «а у нас это (не) работало». Почти всегда такие источники будут бесполезны или вредны, потому что не учитывают контекст вашей задачи и какие характеристики решения вам важны. На вебинаре разберем несколько «инженерных этюдов» с помощью простых инструментов trade-off анализа, которые позволяют формировать свои критерии выбора и анализа решений. Формат: спорим, рассуждаем, рисуем стрелочки-квадратики, рефлексируем. Ведущий: Андрей Бураков — tech product, аналитик, разработчик 📆 3 ноября, вторник, 18:30 мск 🔗️️️️️️ Для участия нужна регистрация в ботике

И напоминаю, что вечером делаю экспериментально-архитектурный воркшоп

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

Правда, часть из них были неплохими инструментами мышления, но так ли важно, почему человек их не использует: из-за отсутствия времени или наличия иишечки?

#AI #анализ Помните классические инструменты requirement engineering времен Вигерса, Коберна, Якобсона, которые использовали для анализа и проверки качества требований? Все эти полотна из требований, сценариев, uml-диаграмм, которые давали очень полную и непротиворечивую картинку, и которые не мог читать ни один человек в здравом уме? После которых разрабы подходили к аналитикам и говорили: "Бро, все круто, только объясни нормально, что сделать нужно?" Интересно, что при грамотной работе с иишечкой они могут быть довольно полезны. Часто инфа в классических артефактах частично или полностью дублируется, плюс они позволяют проверять полноту друг друга. Например, связки: • контекстная диаграмма + DFD + концептуальная ERD • Use Cases Diagram +Use Cases + сиквенс под каждый + портянка ФТ При работе человека, такие комплекты сильно избыточно и скорее всего не окупят затрат. А вот иишечка вполне себе бодро генерит, причем сегодняшние модели неплохо находят противоречия между разными артефактами, проверяют полноту и задают вопросы. Токенов пожжем больше, но это уже поле для оптимизаций и поиска баланса. Можно даже под каждый артефакт запустить несколько агентов, а потом сравнить результаты и выбрать / сформировать лучший управляющим агентом. Дальше делать кросс-валидацию между разными артефактами и актуальной базой знаний. Не то чтобы все это необходимо для разработки, но как только втягиваешься в серьёзную мультиагентность, становится все сложнее остановиться

В предыдущих сериях я изобретал свой подход к анализу трейдоффов и решений (раз, два), потом нашел большие энтерпрайз методы. Хочу пропушить идею в массы, а потом включить в программу по интеграции и архитектуре, поэтому приглашаю пощупать ручками во вторник. Будем спорить, рисовать, рефлексировать. Инструменты простые, а профит должны давать вполне осязаемый. Причем вдолгую, для собственного развития в первую очередь. Если останется время, пофилософствуем о мышлении в AI-мире. Регайтесь в боте и не забывайте спрашивать, будет ли запись.\

Давно пытаюсь затащить тему софтов в инженерный мир, ибо говорить и думать о них не принято, у нас же тут хардкор. Правда рубиться из-за каждой доработки-фичи и искать виноватых после каждого инцидента всем ок. В общем, сегодня вечером проводим совместный вебинар с Soft Skills Lab, даже тему (сами подписчики) выбрали кликбейтную. Все бесплатно, нужна рега.

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

Курс дает в целом хороший базис (мат.часть) и понимание причин. Это наиболее полезно. Учит мыслить самостоятельно, полезно послушать мнение и логику других коллег. Вопросы на занятиях, это капец как заставляло думать. Курс хорошо помогает структурировать уже имеющиеся знания и позволяет посмотреть на процесс построения архитектуры не как простой набор паттернов, а через глубинное понимание этих самых паттернов. Супер!  4 часа просто незаметно прошли💪 Классный формат, максимально вовлекаешься.  Самое главное выделил для себя, что очень ждешь следующую субботу Очень полезный курс, на котором за достаточно быстрое время рассказывается про то как работают технологии, как по отдельности, так и в сборе, какие последствия использования, какие плюсы/минусы. Очень полезные задания по совместной работе и последующим разбором того, что наделали 🙂

Подумалось следом. Если ваш бизнес хорошо понимает технические термины (апи, деплой, коллбек и т.п.), скорее всего: • когда-то он сам был в разработке • он очень любознательный • процессы у вас говно Но у нас таких нет, у нас все нормальные(с)

Sync-async, часть 5. Пока не придумал кликбейт У меня есть серия про понятие синхронности и асинхронности. В первой части я утверждал, что у технологий и протоколов не может быть свойства синк-асинк в принципе. Строго говоря, это некорректное утверждение: каждый сам решает, какие свойства приписывать, ибо все это некоторые технические абстракции, а не вещи в себе. Лучше сказать так: "Я не вижу практического смысла в том, чтобы приписывать технологиям такое свойство". Если видите, то поделитесь, плз. Поэтому предлагаю рассматривать синк-асинк как свойство взаимодействий, которые происходят между системами в рамках некоторого (бизнес) процесса на некотором уровне абстракции. Об этом писал во второй части. Здесь возникает вопрос: что считать процессом и какой уровень абстракции выбирать? Недавно подумал на тренинге, что это можно формализовать через привычные артефакты проектирования: контекстную диаграмму и сиквенс, который отражает технические взаимодействия. Как они участвуют в процессе проектирования, кратко описал тут. Строим обычную контекстную диаграмму, но с важной особенностью: стрелочками показываем не потоки данных или функции, а отношения использования. Т.е. стрелка всегда показывает, зачем одна система или пользователь использует другую. Читаться должно так: — Пользователь Х использует Систему А, чтобы оформить заказ —- Система А использует Систему Б, чтобы провести оплату Получается классическая тройка Субъект → Предикат → Объект с ограничением на допустимые предикаты. Второй вопрос: на сколько детализировать каждое такое отношение? Можно сказать, что мы используем платежный шлюз, чтобы провести оплаты. Можно сказать, что мы используем платежный шлюз, чтобы: • открыть платежную форму • заблокировать средства • разблокировать средства • списать средства • сгенерить чек Можно использовать простое правило: понятно ли данное действие владельцу / заказчику процесса? Платежная форма, блокировка и списание средств, отправка чека - понятные бизнеcу слова. Очереди, коллбеки, статус коды, вебсокеты - нет (я надеюсь). Поэтому детализируем до тех пор, пока наш язык понятен вероятному заказчику. Таким образом получаем взаимодействия между системами, выраженные через отношения использования. Вот теперь каждое взаимодействие рассматриваем с точки зрения синк-асинк: блокирует оно целевой процесс, или нет? На этом уровне свойство синк-асинк имеет смысл. Дальше думаем, какая согласованность нужна между двумя системами, т.к. это тоже влияет на способ реализации, об этом говорили в четвертой серии. И только после смотрим на техрадар, ограничения инфры и архитектуры, выбираем походящие паттерны и технологии. В этот момент уже неважно, считаем ли мы очереди "асинхронными", а HTTP "синхронными" — всю работу мы сделали на предыдущих шагах. Если совсем просто: взаимодействия на уровне контекстной диаграммы имеют свойство синк-асинк, на уровне сиквенс диаграммы — нет. Вот такая асинхронщина, собачка.

Ну вы это, заходите есличо, мы начинаем

Держите лучший промпт для вечера пятницы. Рыдаю, не могу остановиться

Based on everything you know about me, roast and don’t hold back. Say it in Russian slang Just like this, but add way more Russian swear words