Yet Another Analyst

#интеграция Есть у меня любимое задание на курсах по интеграции: выбрать технологию или протокол для взаимодействия и обосновать выбор. Каждый раз, случается диалог вида: — Мы выбрали gRPC для внутренних взаимодействий, потому это быстрее, чем REST — А на сколько быстрее? — Что вы называете REST’ом? А если это REST API поверх HTTP/2, будет ли gRPC быстрее, и на сколько? — Какую долю от времени ответа занимает передача данных? Будет ли разница в скорости между gRPC и REST значимой для нас? — Какая общая нагрузка на систему или продукт? Важна ли нам вообще скорость внутренних взаимодействий? После этих вопросов приходится идти считать текущую и прогнозируемую нагрузку, изучать производительность сервисов, смотреть бенчмарки, делать нагрузочное тестирование. Вполне вероятно, что летенси ваших сервисов определяется совсем не скоростью передачи по сети. И я не перестану говорить, что все эти чек-листы и универсальные критерии выбора — полный буллшит. Если человек не может собрать контекст задачи, выделить значимые критерии и приоритезировать их, он остается жалким подобием чатгпт. Поэтому для желающих стать человеком мыслящим в мае проведем несколько активностей в Tech Analyst Club: • 23.05, сбт — воркшоп по тестированию и документированию нестандартных API (GraphQL, gRPC, WebSocket) в Postman • 28.05, чтв — вебинар про иерархию и устройство протоколов и технологий взаимодействий • 30.05, сбт — воркшоп про выделение и приоритезацию критериев выбора способа интеграции Кстати, о производительности gRPC у нас был стрим с Алексеем Романовым.

Выше писал, что мало какой руководитель станет уменьшать свою команду на фоне ии-оптимизаций, даже если это экономически оправдано. С другой стороны, общался с несколькими техдирами про внедрение ии в разработку, и они почти прямо транслируют мысль: — Если люди не готовы использовать AI в работе, то нужно задуматься, стоит ли им работать у нас И это ни разу не про стартапы. Всем хорошей недели ☕️

#архитектура Пока готовили AI Dev Conf, записали пару подкастов про AI в архитектуре. Лот №1 Поговорили с Максимом Смирновым и Русланом Сафиным, как LLM уже помогает при проектировании, с чем не справляется, почему AI-мире ADR становятся особенно ценными, что не так с SDD, и зачем нужно активно осваивать agent skills. Смотреть тут: 😉 YouTube | 📺 VK Видео Лот №2 Сергей Баранов и Александр Поломодов обсуждали, как LLM и мультиагентные системы меняют софт-архитектуру и инженерные процессы. C одной стороны — демократизация разработки, с другой — жесткая необходимость в инженерном фундаменте для масштабирования. Сам пока не слушал, но точно буду. Смотреть тут: 😉 YouTube | 📺 VK Видео

#AI Послушал подкаст Маши Серегиной про иллюзию эффективности при внедрении нейросетей с Сергеем Путятинским. Судя по всему, выпуск планировался как некий срыв покровов с хайпа AI, но по мне получилось ровно наоборот – адекватный план внедрения иишечки с аргументацией, почему и где оно вам нужно. Возможно, это мой лютый bias. В любом случае, советую послушать как фанатикам, так и атеистам – каждый что-то найдет. Вытащил несколько мыслей (вольные цитаты):

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

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

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

Все так, об этом последнее время много и хорошо пишет Александр Поломодов. Бигтехи и стартапы уже активно двигаются в этом направлении.

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

А вот здесь популярное заблуждение, что иишечка в разработке – это вайбкодинг, где ты с 2-3 промптов получаешь красивое приложение, но не более. Копилоты, код-агенты, ревью-агенты, SDD и т.п. уже используют в промышленных масштабах. Да, допиливать АБС или телеком-биллинг, я бы так не стал, но определить необходимые изменения в нужных сервисах и последовательно реализовать их вполне реально. С AI-driven инженерией в массах еще незнакомы. Именно поэтому 21 мая мы с джугами делаем вторую AI Dev Conf. Там спикеры из бигтехов расскажут, как AI меняет процессы в кровавом энтерпрайзе, с кейсами, метриками и вот этим всем.

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

Самое важное, хотя говорить об этом никто не любит. Принято считать, что процессы и оргструктуры строятся так, чтобы они были максимально эффективными. Хотя строят их конкретные люди так, чтобы им это было выгодно. Об этом я писал тут. Причем выгода не только в бюджетах и влиянии. У каждого руководителя есть команда, которую он либо нанимал, либо в доверительных отношениях. Такие связи бывают очень полезны при смене проектов, компаний и вообще изменениях. Этот тот самый человеческий капитал. Компании меняются, люди остаются. Что произойдет с капиталом, если начать оптимизировать команду?

Я уже видел много революций, которые обещали изменить мир: SOA, BPM, микросервисы, RPA, блокчейн – и где они теперь?

Вообще-то они все на своих местах, где есть реальное применение. Да, те же SOA, MSA, BPM не стали концом истории, но дали огромное развитие инженерной и манагерской мысли. Это все равно, что ругать REST Филдинга за его бесполезность в 2026 году. Так будет с AI. Пока пробудившейся Skynet не очистит эту землю от двуногих.

Кстати, смотреть на синк-асинк можно не только с точки зрения общего процесса, а еще через согласованность состояний между акторами. Если согласованность особо не интересует, то можно кидать сообщения всяких без гарантий через какие-нибудь in-memory Redis или NATS, или вообще по UDP. Если согласованность нужна, но не вотпрямщас, то кидаем события в одностороннем порядке (one way) в кафку, кролика или еще кого Хотим убедиться, что до получателя событие долетело – делаем вебхук или request-response поверх очередей. Если нужна более строгая согласованность, берем поллинг или коллбек. В общем, из типа согласованности следует требование к синхронности или асинхронности взаимодействия, а под него уже берем более удобную и доступную технологию.

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

Sync-async, часть 3. Бытовое безумие Продолжаем самую безумную серию канала. В предыдущих сериях мы говорили, что у сетевых протоколов нет свойства синхронности / асинхронности: раз, два. Принято считать Polling, Callback, Webhook асинхронными паттернами. А в чем их асинхронность? Я пользуюсь таким определением sync-async:

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

Что такое (Short) Polling? Формально, его можно назвать асинхронным паттерном, т.к. после первого вызова соединение закрывается и технический процесс на клиенте не блокируется. Дальше просто добиваем статус регулярными запросами. Но на уровне бизнес / интеграционной логики, мы не можем продолжить глобальный процесс — иначе мы бы не долбились за результатом. Псевдо асинхронность приходится строить по двум банальным причинам: каждое подвешенное соединение жрет ресурсы чем дольше висит соединение, тем выше вероятность разрыва Что такое Callback? Если говорить о “классическом” коллбеке с двумя акторами, то здесь примерно та же история. Формально это можно обозвать асихнронщиной, но фактически нам нужно дождаться результата, чтобы продолжить бизнес-процесс. Получается та же история, что и с поллингом. Возможен вариант коллбека, когда запрос кидает Service A, обрабатывает его Service B и отправляет ответ в Service C. Адрес последнего сервиса можно забить в настройки или передавать в исходном запросе. Считать ли это коллбеком — вопрос холиварный. Я буду считать это схемой из двух вебхуков. Что такое Webhook? Выглядит как одиночный синхронный запрос-ответ. Но на уровне общей картины это передача события поверх HTTP, где актор делиться инфой о последних происшествиях с подписанными соседями, не требуя ничего в ответ. Здесь HTTP-response — формальность самого протокола. Выглядит как событийная архитектура, только без очередей. Получается, Polling и Callback — псевдо асинхронные паттерны для реализации сихнронных шагов бизнес-процесса, а невзрачный Webhook — полноценная асинхронщина, да еще и в событийной парадигме? Только не говорите об этом на собесах, и не убеждайте коллег. Совы не всегда то, чем кажутся.

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

Тем временем в большом энтерпрайзе уже возникают вопросы: если джун/миддл с помощью AI стабильно выдает результат уровня сениора, то какой грейд ему давать, и сколько платить?

Меня совсем поглотил DUMP, буду краток. Завтра в Tech Analyst Club делаем первого AI-агента с RAG’ом в n8n. Если вы ждали знака, чтобы начать — вот он. Вчера нас 4 часа гуляли по Екатеринбургу, проникся городом, хочу вернутся. Есть кто из местных? Думаю устроить оффлайн митап тут летом. На выхах выложу материалы сегодняшнего доклада, не теряйтесь.

Зато завтра на DUMP буду снова вещать, почему аналитик должен стать инженером. Как в этом пути помогу лего-сервисы и другие подручные инструменты. Кто еще будет?

Штош, люди все равно спрашивают, поэтому держите неофициальный пресс-релиз. Жизненный путь NextWay (ArchWays) начался 4 года назад с забавной истории, теперь он подошел к логическому завершению. Спасибо всем, с кем делали его, и всем кто доверял свое время, деньги, внимание. Обычно в этом месте выкладывают стату про тренинги, участников и все такое, но мне лень и не вижу смысла. Знаю, что через школу прошло примерно 450-500 человек. Часто в личке и при случайных встречах мы слышали благодарность и истории о том, как после курсов получилось найти интересную работу, стать архитектором, вырасти в лида или хеда. Безусловно, это их заслуга, а не наша. Но хочу верить, что получилось сделать этот путь чуть проще. Если так, то все было не зря. В мае-июне планирую провести последний поток интеграции и архитектуры систем. Дальше буду заниматься Tech Analyst Club, не прощаемся. Если проект как-то помог вам, оставьте пару слов в комментах, плз, приятно будет поностальгировать.

#конференции На следующей неделе иду возвращаться к корням у джугов на JPoint и Heisenbug. Надо узнать, что там случилось в джаве за последние 10 лет, и что со внедрением иишечки в тестирование и разработку. Попытался выбрать самое интересное, куда пойду, чтобы не заспамить ленту. Почти получилось. Heisenbug (27-28 апреля) • LLM'изация тестирования в Яндексе: измеряем эффект от AI в команде из 1000+ QA-инженеров • Как автоматизировать тестирование ИИ-агентов: бенчмарки, метрики, LLM-as-a-Judge • Тестирование LLM-приложений с DeepEval JPoint (29-30 апреля) • История сборщика мусора G1. Часть 1. Java 17-25 • Хайлоад на ровном месте • Кровь, пот и Kafka. Request/reply не больно • ИИ в ревью кода: как перестать тюнить промпты и начать строить систему Кто еще туда собирается? Го по чайку вживую.

#AI #манагерское В продолжение темы, ловите заметки Максима Цепкова из лагеря маркетологов.

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

P.S. Обязательно напишите, почему там все неправы, и вообще

#манагерское Каждый продакт, сейлз, маркетолог и дизайнер знает, как быстро доработать систему: нужно просто добавить пару полей в табличку, немного изменить метод, повесить проверку на кнопку. Работы на пару дней. Хотя никто из них никогда этого не делал и делать не будет. Каждый разраб, аналитик и куа отлично знает, как правильно запустить продукт, какие фичи полетят, как лучше спроектировать UX, и где можно зарабатывать. Хотя никто из них никогда не запускал бизнес или продукт, не отвечал за метрики, не считал деньги. И никогда не будет. Зато каждый живет в абсолютной уверенности, что по ту сторону все тупые и ленивые, а уж мы-то знаем, как надо! И никакие сомнения не тревожат эти дивные миры. Будь у меня сейчас команда, отправил бы технарей ресерчить рынок, анализировать конкурентов, формировать гипотезы и строить роадмап. А продактов, сейлзов, маркетологов вайбкодить все то, что принесли технари - со сроками, техдолгом и падающим продом. Должно годное реалити-шоу получиться. P.S. Расскажите, что у вас все не так, спасите мою верю в людей

Ну что, на марафон отправляется @zy_ana, а остальным достается промик со скидкой 20% — AB20_AM17 Приходите к нам еще.

#AI Мегаинтересный и короткий доклад про от SRE в Яндекс Go про внедрение иишечки. Да, спикер прямо говорит, что собрать такое сейчас могут только бигтехи и около, но все равно круто. Будем подождать. https://youtu.be/2V9h3FYBS_Y?si=n8q83RMW6KAk8k0d&t=1366

Чет я забыл рассказать, что сегодня вечером делаем открытый вебинар про Cursor и SDD. Запись будет только для членов клуба, так что не пропускайте.

Коллеги в Аналист Марафоне делают очень близкую нам движуху. В следующую субботу обещают интересное: • Максим Смирнов расскажет про архитектурные решения и ADR в эпоху иишечки, и чем здесь полезны агентские скиллы • Софья Калинина поделится своим подходом к работе с требованиями и прототипированию с помощью AI. • Елена Шутова покажет, как Event Storming помогает понять бизнес, и что вообще нужно делать. Посмотрю в записи, ибо буду в это время на воркшопе, но вы заходите. Если жаба взяла на удушающий, то можете поучаствовать в розыгрыше — напишите в комментах, какой доклад вам интересен и почему. В четверг рандомно определим, кому достанется халявный билетик.

Сейчас началась конфа от Cloud про ии в облаках, трансляция открытая: https://cloud.ru/gocloud/program