analyst_exe | инженерное мышление в IT

«Откатили хотфикс, на стейдже регресс, и у нас конфликт».

Если вы на дейлике кивнули, а потом пошли гуглить под столом — держите словарь. Я сам в первый год кивал и гуглил. Спорим, не я один)

Никто это специально не объясняет. Разработчики так говорят с первого курса, им в голову не приходит, что «смержить» — не общеизвестное слово.

22 слова с дейлика. Перевожу на наш язык и сразу пишу, чем это вам грозит. Листайте ⬇️

Про код

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

Коммит — сохранённая порция изменений. Ctrl+S с комментарием.

Запушить — отправить коммиты на общий сервер. До пуша код живёт только на ноуте разработчика.

Ревью — другой разработчик проверяет код, прежде чем влить его в общий код проекта. «Висит на ревью» = код написан, ждём коллегу. Пинать автора тут бесполезно. Пинайте ревьюера)

МР / ПР (merge request / pull request) — заявка «гляньте мой код и влейте». «Открыл МР» = задача почти готова, осталось ревью.

Мерж — влить ветку в общий код. «Смержили» = фича в общей кодовой базе. Обычно пользователи её ещё не видят — но если у команды автодеплой, мерж означает «уже на проде». Спросите один раз, как у вас.

Конфликт — два человека поменяли одно и то же место в коде, и система не знает, чей вариант правильный. Никто не поругался. Разбирается обычно за минуты, но иногда съедает день.

Куда оно едет

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

Дев — песочница разработчиков. Тут всё может лежать сломанным, это норма. На баги на деве не жалуйтесь, вас не поймут.

Стейдж — репетиционная копия прода. В маленьких командах test, UAT и препрод — это всё одна среда, в больших — три разные. «Задеплоили на стейдж» = можно тестировать, пользователи ничего не видят.

Прод — боевой сервер, то, что видят реальные пользователи. Услышали «прод» — отложите телефон и слушайте.

Релиз — выкатка готовых фич на прод, обычно пачкой по расписанию. «Едет в ближайший релиз» = скоро у пользователей.

Фриз (code freeze) — заморозка: перед релизом новые изменения в него больше не берут, только критичные фиксы. «Завтра фриз» = что не успели влить — едет в следующий релиз. Ваши сроки это двигает напрямую.

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

Хотфикс — срочная починка прода вне расписания релизов. Слышите «хотфикс» — значит где-то горит) ваша задача сегодня скорее всего подвинется.

Фича-флаг — выключатель фичи на проде. Код выехал, но фича спит, пока флаг не включат. Так что «задеплоили» ещё не значит, что юзеры что-то увидели.

Почему «готово» — это не готово

Баг — программа делает не то, что задумали. Сначала разработчики смотрят логи и код. К вам придут, когда начнётся спор «это баг или так задумано» — тут решают требования.

Регресс — новый код сломал старое, которое работало. «На стейдже регресс» = чинят не вашу фичу, а то, что она зацепила. Релиз подождёт. Но «гоняем регресс» — другое: это проверка, что старое не сломалось. Тут ещё ничего не упало.

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

Флаки тест — тест, который то проходит, то падает сам по себе. Чаще всего с вашей фичей всё ок, просто тест нервный — но бывает, флак ловит реальную плавающую ошибку. Копать или перезапускать — решает разработчик, не вы.

Билд красный / пайплайн упал — автоматическая сборка и проверки кода не прошли. Пока не позеленеет, дальше ничего не едет. Звучит страшно, бывает по три раза на дню.

Блокер — то, из-за чего задача стоит. «У меня блокер на аналитике» = это вам. Бросайте всё и отвечайте.

Завтра на дейлике минимум три слова отсюда прозвучат. Проверьте. И киньте коллеге, который кивает)

@analyst_exe | https://analystexe.ru/articles/daily-standup-dictionary

Когда заказчик говорит «это срочно», он почти никогда не имеет в виду «быстро». Чаще это значит: «если это не сделать — виноват буду не я».

«Срочно», «горит», «приоритет» — слышим в этом оценку времени. А времени там часто нет. Есть способ протащить задачу без очереди и заранее свалить ответственность на того, кто возьмёт. Сделаешь — молодец, так и надо было. Не успеешь — ну тебе же сказали, что горит.

И вот ты уже двигаешь спринт под чужую тревогу.

Проверяю это двумя вопросами. Не «когда надо», а вот этими.

1. Что мы НЕ делаем, если берём это сейчас? Срочное всегда кого-то задвигает. Если задвигать нечего — либо у вас пустой бэклог, либо задача горит не так сильно, как кричат.

2. Что случится, если сделать на неделю позже? Конкретно. Кто пострадает, какой процесс встанет, сколько денег утечёт. Если в ответ «ну… хотелось бы побыстрее» — это не срок, это настроение.

Если на оба вопроса честный ответ «ничего» — задача не срочная, а тревожная. А тревогу спринтом не лечат. А если ответ конкретный — «встанет релиз», «дедлайн регулятора» — отлично, теперь у срочности есть цена, и её видно всем. Этим приёмом вы не отменяете пожары, вы отделяете настоящие от выдуманных.

Дальше — заставьте ранжировать.

Не бывает пяти задач «первого приоритета». Это не приоритеты, это список «всё важное». А когда всё важное — не важно ничего, и порядок за вас выберет тот, кто громче. Положите задачи рядом и попросите пронумеровать. Один, два, три. Без повторов.

И зафиксируйте письменно. Не в голове, не на словах в коридоре. «Берём А, значит B и C уезжают на следующую неделю. Все согласны?» — и в чат. Не чтобы прикрыться, а чтобы тот, кто кричит «горит», увидел цену своего «горит». Обычно на этом месте половина пожаров тухнет сама.

Как только trade-off становится видимым и подписанным, слово «срочно» теряет всю магию. Потому что дело почти никогда не в часах. А в том, чью спину этим словом прикрывают.

🔥 если у вас тоже «горит» через раз без причины

А вам как чаще пытаются протащить задачу — «это срочно» или «это же на пять минут»? Да будет срач в комментариях

@analyst_exe

Нажали «оплатить». Крутится колёсико. Связь моргнула, приложение молчит. И палец сам тянется нажать ещё раз.

Вопрос на сотку: спишут один раз или два?

Зависит от одного занудного слова. Идемпотентность. На деньгах без неё лучше не лезть. Слово пугает, по факту фигня: повторил операцию — и ничего не поменялось. Дёрнул перевод один раз, дёрнул пять раз подряд тем же запросом — деньги уйдут ровно один раз.

Почему вообще ломается. Сеть ненадёжна. Вы отправили запрос, сервер его принял, списал деньги, отправил «ок» — а «ок» потерялся по дороге. С вашей стороны ответа просто нет. Прошло или нет — непонятно. Вы жмёте снова, а сервер видит второй запрос как новенький. И списывает ещё раз.

Так вот, чинят это ключом. Клиент к каждой операции цепляет уникальный код — обычно UUID, длинную случайную строку. Кладёт его в HTTP-заголовок Idempotency-Key. Сервер по нему понимает, видел он эту операцию или нет. Впервые — выполняет и кладёт рядом с ключом результат: тело ответа и статус. Тот же ключ снова — ничего не делает, отдаёт сохранённое.

И вот тут все думают — всё, готово. Ага, щас.

Представьте: два запроса с одним ключом прилетели одновременно. Двойной тап. Или клиент сам ретрайнул по таймауту, пока первый ещё в полёте. Оба лезут в базу, оба видят «ключа нет», оба идут списывать. И вот оно, двойное списание (то самое, из-за которого потом не спишь). А теперь умножьте на чёрную пятницу и тысячи человек. К этому вернёмся.

Спасает атомарная вставка. По-простому: ключ кладут в базу так, что записать его сможет только один запрос из двух. Делает это уникальный индекс — база сама не даёт положить два одинаковых ключа. Кто записал первым, тот и выполняет. Второй обламывается и сразу получает 409 (код ответа «такое уже в обработке»). Дальше повторит тем же ключом и заберёт результат. Или снова словит 409, если первый ещё считается — тогда ждёт и повторяет (повтор — на клиенте). Без этой защиты от гонки идемпотентность не работает, хоть что делай.

Ну и дальше пошли нюансы. На них ТЗ и горят.

Ключ генерит клиент и привязывает к операции, а не к кнопке. Один перевод — один ключ. Шлёте другу второй перевод на ту же сотку — нужен новый ключ, иначе система решит «дубль» и второй платёж тихо проглотит. И ключ уникален в рамках клиента: ваш ключ и чужой с тем же значением — разные операции.

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

Ключ живёт не вечно. У Stripe, например, сутки. Срок жизни надо проставить в спеке, иначе таблица ключей пухнет, а клиент через месяц ретрайнет «старую» операцию и получит сюрприз.

И почему ключ нужен именно на POST. Смотрите: повторный GET просто ещё раз покажет баланс, повторный DELETE снесёт уже снесённое — этим ретрай не страшен, они идемпотентны сами по себе. А POST каждый раз создаёт новое. Вот ему и нужна страховка.

И да, это не только про оплату. Очереди вроде Kafka и RabbitMQ доставляют сообщение «хотя бы один раз» — значит, одно и то же прилетит дважды штатно, без всякой моргнувшей сети. Вебхуки провайдер тоже шлёт с повторами. Везде, где есть ретрай, нужен ключ и дедуп — отсев повторов.

Так вот про чёрную пятницу. Нагрузка, один пропущенный уникальный индекс — и за ночь система дважды списывает с тысяч человек. Прикиньте: по 3000₽ с восьми тысяч — это под 24 миллиона, которые утром надо возвращать. А утром с этим прибегут к вам. Инцидент, разбор, начальство.

Чеклист, проверить контракт за минуту:
— есть Idempotency-Key на всех POST, что двигают деньги или необратимы?
— вставка ключа атомарна (защита от гонки)?
— что сохраняем по ключу и отдаём на повтор?
— что отвечаем на тот же ключ с другим телом?
— сколько ключ живёт?

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

Хоть на один пункт ответа в спеке нет — там дыра. А через дыры утекают деньги.

Гляньте свой контракт. Есть там POST на платёж без ключа? Вот с него и начинайте.

🔥 если разложил по полочкам. А в комментах — ловили двойное списание? Расскажите, как было (без названий).

@analyst_exe

🫡 Понедельник день тяжелый

Но своровать мем из рабочего чата - лучше чашечки кофя

@analyst_exe

Формат, на котором сейчас написан почти весь интернет — порядка 98% страниц — набросали ручкой на салфетке в придорожной закусочной. За ужином. И в ту же ночь запустили.

Сентябрь 1992-го, Нью-Джерси. Кен Томпсон и Роб Пайк (те самые, из Bell Labs, делали Unix и Plan 9) сидят в дайнере. Томпсон берёт подложку из-под тарелки и рисует схему кодирования. Это UTF-8. Ночью дописали в коде — и оно поехало. Салфетку, конечно, никто не догадался сохранить — артефакт на миллиард уехал в мусорку с тарелками.

А теперь зачем это понадобилось.

Что было до

Был ASCII. 128 символов — латиница, цифры, знаки препинания и управляющие (перевод строки, табуляция, тот самый нулевой байт). Влезает в 7 бит, всем хорошо. Ровно до тех пор, пока текст на английском.

Кириллица, японский, греческий — для них в ASCII пусто. Стали лепить свои 8-битные кодировки: KOI-8 и Windows-1251 под русский, Latin-1 под Европу, Shift-JIS под японский. Десятки таблиц. И во всех один и тот же байт значит разную букву.

Открываешь письмо — а там «Ïðèâåò». Это не сломанный файл. Это твой «Привет», записанный в Windows-1251 и прочитанный как западный Latin-1: байты те же, таблица другая. Кракозябры — отсюда. Все мы это ловили: то в письме, то в кривой выгрузке из старой базы.

Попробовали починить — придумали Unicode. Первая версия, UCS-2: дай каждому символу ровно 16 бит (два байта), и хватит на всех. Звучит логично. По факту — три проблемы, одна другой больнее. ASCII перестал работать (латинская буква теперь два байта, старый софт давится). Текст распух вдвое. И 65 536 ячеек кончились — одни китайцы с японцами выбрали их под завязку.

Тупик. Зоопарк кодировок есть, замены нет.

Что придумали на салфетке

UTF-8 зашёл иначе. Вопрос не «сколько бит на символ». Вопрос — как ужиться с тем, что уже написано. Отсюда переменная длина: 1–4 байта на символ.

И вот тут кайф:

🔸 Обратная совместимость. Все 128 символов ASCII кодируются одним байтом, как раньше — байт в байт. Любой ASCII-файл за прошлые 30 лет уже валидный UTF-8. Старый софт ничего не заметил.

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

🔸 Сортировка по байтам = правильный алфавитный порядок. Без приседаний.

🔸 Нет нулевых байтов внутри символов. В C строка кончается на нулевом байте, и весь сишный мир на этом стоит. UTF-8 нулей внутрь не суёт — строки не рвутся.

Сложи всё вместе — он не ломает старое. Просто ложится сверху. Поэтому и расползся: переходить не больно.

Но не бесплатно

Только не подумай, что халява. За переменную длину тоже платишь. «N-й символ» больше не равен «N-й байт» — прыгнуть к 50-му за раз нельзя, идёшь с начала и считаешь.

Дальше — вес. Латиница 1 байт, кириллица 2, иероглифы 3. За совместимость с ASCII по байтам платят все, кто пишет не латиницей.

И исторический грабли — overlong-кодирование: один символ можно было записать длиннее, чем нужно. Казалось мелочью — пока через это не полезли мимо проверок безопасности: закодируешь / хитро, фильтр не увидел, а система прочитала. Позже залатали, объявив такие формы невалидными.

Ну и 16-битная идея не умерла: её подлатали суррогатными парами и назвали UTF-16 — на нём до сих пор сидят Windows и Java. Но это уже костыль поверх, а не победа.

Зачем это аналитику

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

И вы ровно это решаете каждый раз, когда садитесь за новую версию API или схему БД: запилить красиво с нуля и сломать совместимость — или натянуть новое поверх старья. UTF-8 намекает, что второе чаще выживает.

А вы какие кодировки в дикой природе ещё застали? Кто чинил «Ïðèâåò» в выгрузке руками — отзовитесь 🙂

@analyst_exe

JSON никто не придумывал. Его, по словам автора, просто нашли — лежал внутри JavaScript и ждал.

Звучит как понты, но это буквально так. Дуглас Крокфорд в районе 2001-го (компания State Software) не сочинял новый формат. Он взял синтаксис, которым в JS уже описывали объект — фигурные скобки, ключ-значение — и сказал: вот этим и будем обмениваться данными. Зарегистрировал json.org, описал на одной страничке. Всё.

А теперь зачем это вообще понадобилось.

Тогда правил XML

Начало нулевых. Данные между браузером и сервером гоняли в XML. Штука мощная, спору нет: схемы, валидация, namespace'ы. Но для «отдай мне юзера с именем и почтой» это как забивать гвоздь отбойным молотком.

Открывающий тег, закрывающий тег — по два на каждое поле. Половина байтов это </вот\_это\_вот>. Чтобы прочитать — тащи парсер, ковыряй DOM, доставай значения по узлам, не забудь про схему и namespace. Возни много, данных мало. Перебор для простого обмена.

Перелом — AJAX

2005-й, Джесси Джеймс Гарретт вводит слово AJAX. Идея: браузер дёргает сервер в фоне, без перезагрузки страницы. Тогда это была магия — карты, которые тянутся мышкой, подсказки в поиске на лету.

И вот тут XML посыпался. Браузер на JavaScript, сервер ему шлёт XML — а чтобы разобрать, опять DOM, опять руками.

А JSON? Он же синтаксис самого JavaScript. Пришёл ответ — и на выходе сразу готовый объект, разбирать нечего. Родное. (Поначалу его вообще скармливали eval() — да, исполняли как код, дыра жуткая; потом одумались и сделали безопасный JSON.parse().)

С этого момента всё.

Чем взял

Горстка типов, и никаких церемоний. Объект, массив, строка, число, true/false/null. Шесть штук. Человек читает глазами без тулзы, машина парсит влёт. Учить нечего — открыл и понял.

Дальше его просто причесали комитеты: RFC 4627 → ECMA-404 → RFC 8259 / STD 90 (2017, финал). Скучная часть, но без неё формат не стал бы стандартом.

Кстати, забавное. Крокфорд впихнул в лицензию пункт: «The Software shall be used for Good, not Evil» — софт использовать во благо, не во зло. И понеслось: юристы крупных контор хватались за голову, а одна на полном серьёзе попросила письменное разрешение «использовать во зло». Он разрешил.

Но не всё гладко

JSON выехал на минимализме — и тем же местом огребает. Чего в нём нет:

— Комментарии. Никаких. Хочешь пометку в конфиге — а некуда.
— Даты и бинарь. Нет таких типов. Дата едет строкой, и каждый парсит как хочет.
— И главная подстава — числа. Сам стандарт точность не ограничивает, но почти все реализации (привет, JavaScript) суют число в float64. И целый id больше 2^53 (\~9 квадриллионов — туда дорастают банковские счётчики, телеком, 64-битные Snowflake ID) теряет точность молча. Послал 1234567890123456789 — на той стороне прилетело что-то рядом, и никто не ругнулся. Кто-то умеет тянуть аккуратно (BigInt в JS, UseNumber в Go), но самый надёжный межъязыковой костыль — гнать большой id строкой, в кавычках. Кто не знал — ловил баг, который «на моих данных не воспроизводится».

Схема? JSON Schema — вообще сторонняя спека, приехала позже и сбоку, в стандарт не входит. Запятую в конце списка (trailing comma) тоже нельзя — прод падал и не на таком.

Итого

JSON победил XML не потому, что мощнее. Наоборот — он слабее. XML мог всё, но за всё драл. JSON умел мало, зато не выносил мозг.

Короче, выехал не самый мощный, а самый ненапряжный. Как-то так))

Мне тут понравилось копать-ковырять в историю инструментов. Ну, чтобы получше понимать, почему так. Ну кто вам об этом расскажет, если не я?

❤️ - если продолжать исторические справки

@analyst_exe

Среда, my dudes
Работаем в поте лица!

🔥 - работаю сэр да сэр
😢 - хочется спааать

@analyst_exe

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

🔸 Методичка больше не про «что такое API». Почти в каждую статью добавил блок «как это спрашивают на собесе»: реальные вопросы и то, что в ответе отличает джуна от мидла. И там, где раньше было только «как сделать красиво», теперь написано, чем за это платишь — у каждого решения есть цена, и я перестал про неё молчать. По такому реально готовиться к собесу, а не наизусть долбить определения.

🔸 Новая статья — аналитический дата-поток. Давно мозолила дыра: откуда вообще на дашборде берутся цифры. Как клик доезжает до отчёта, почему нельзя гонять аналитику прямо на боевой базе, чем ETL отличается от ELT, почему продуктовая выручка и финансовая вечно не бьются друг с другом. Все этим пользуются каждый день, а объяснить целиком — попробуй.

🔸 И тренажёры — те самые, обещанные. Даже говорить ниче не буду. Идите и смотрите.

Чтоб не на словах: прогнал всё через злых критиков — преподов и практиков. Где наврал или недосказал — переделал. Три статьи вылизал до эталона, остальные (а их под полсотни) тоже крепкие — просто без финального блеска.

Всё открыто и бесплатно:
📚 методичка → analystexe.ru/materials
🎮 тренажёры → analystexe.ru/games

Залетайте, ломайте. Где косяк или какой темы не хватает — пишите в комменты, чиню и дописываю оперативно.

@analyst_exe

Оставили отзыв - я публикую!

Приходите @darkwing_duck101

@analyst_exe

https://www.youtube.com/live/PSHS8BGafw8
ПОШЛА ЖАРА

🔥 ВЕБИНАР STORM MCP+AI
Сегодня. 17:00 МСК

Вас уже почти 2000, поэтому регистрацию закрываем через 15-20 заявок, чтобы не было проблем с трансляцией.

В прямом эфире соберём BPMN-диаграмму за минуты - через MCP+AI прямо в Stormbpmn. ТЗ возьмём прямо у вас: напишите идею в чат вебинара - её и будем моделировать.

⚡Никаких заготовок и «отрепетированных кейсов».
Результат увидите сами.

Боитесь, что ничего не поймёте, если в AI "не шарите"? Зря.

Быстро погрузим в базу: что такое LLM, как она вообще думает, при чём тут MCP и почему это меняет работу аналитика. Доступно объясним и тем, кто уже "игрался" с ChatGPT, и тем, кто впервые услышит слово промпт.

После вебинара спорить будете не «AI или классика», а «какую часть работы доверить ИИ, а что оставить себе». Это другой разговор - и мы хотим, чтобы вы вели его одними из первых.

👉 Зарегистрироваться

До встречи в эфире 👋

К Claude у меня подключены Figma, таск-трекер, база знаний, аналитика канала. Я не написал ни строчки кода для интеграции — просто поставил четыре сервера, и ассистент сам разобрался, что умеет каждый.

Сижу, смотрю на это и думаю: а почему оно вообще работает? Раньше так было нельзя.

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

Вот это и ломает MCP (Model Context Protocol, придумали в Anthropic в конце 2024).

Что это по-простому

Общий разъём между ИИ-приложением и сервисами. Как USB-C: один протокол, втыкаешь что угодно.

Участников трое. Хост — само приложение (Claude, IDE, мой движок канала). Клиент сидит внутри хоста, связь один-на-один с сервером. Сервер — обёртка над сервисом, та самая Figma или трекер. Подробности на схеме.

Что под капотом

Да почти ничего нового. Транспорт: stdio (сервер — отдельная программа рядом, общаются через ввод-вывод) или HTTP, если сервер удалённый. Сообщения — по JSON-RPC. По проводу тот же текст, что у REST-сервиса, только устроен иначе: не «дёрни ресурс по адресу», а «вызови вот этот метод» (RPC, удалённый вызов процедуры). Мелочь, но наш разрабский ревьюер придерётся — говорю как есть.

Сервер отдаёт три типа штук — смотря кто командует вызовом: tools (действия, решает модель), resources (данные на чтение, даёт приложение — у меня та же аналитика канала), prompts (заготовки, зовёт человек). Дальше по делу — только tools.

А теперь самое сочное

Когда клиент цепляется к серверу, он первым делом спрашивает: «ты что умеешь?» И сервер отвечает списком инструментов — с описаниями на человеческом языке. Не в доке для разработчика. Сам, в рантайме. И читает их не человек, а модель.

Вот тут весь фокус. Обычный API писали под код. Код дубовый и предсказуемый: ему один раз зашили доку — и он знает наперёд, какой эндпоинт дёрнуть и в каком порядке. А MCP пишут под модель. А она тупит и решает на ходу. Поэтому ей надо, чтобы сервер сам по-человечески рассказал, что умеет — иначе не сообразит, какой инструмент к месту.

(на картинках это и есть «детерминированный» и «недетерминированный потребитель» — не пугайтесь слов: код знает заранее, модель прикидывает по ситуации)

А теперь посчитаем, в чём кайф. Сто программ, сто сервисов. Раньше — десять тысяч интеграций руками. С MCP — двести: написал сервер раз — поймёт любой клиент, написал клиент — подхватит любой сервер. (В фирме клиентов два-три, но суть та же: складываем, а не умножаем.) Руками под каждую пару клеить не надо.

Но не бесплатно

За то, что потребитель «думает сам», ты платишь. Описания всех инструментов висят в контексте модели: навешал тридцать тулов — половина окна забита, а ты ещё ничего не сделал. Плюс модель может выбрать не тот инструмент или дёрнуть лишнее — а если в данные с сервера подсунули вредный текст, она послушает его, а не тебя (привет, prompt injection). Поэтому на важных действиях — подтверждение, урезанные права, человек в цепочке. И ещё авторизация — отдельная морока: локально серверу всё равно, он под боком, а по HTTP будь добр нормальный OAuth — он же реальные системы дёргать будет.

Итого

MCP — никакой не новый API. Это старый API, которому переписали инструкцию: теперь её читает не кодер, а модель — сама смотрит, что умеет сервер, и сама решает, что дёрнуть.

Провод тот же. Поменялся только тот, кто его читает.

И вот что меня цепляет. Десять лет интеграционные аналитики писали ТЗ под каждый сервис руками — «дёрни GET /orders, поля такие-то». Вот эта часть обнуляется. Не вся: описания инструментов и guardrails (подтверждения, права) всё равно кто-то пишет — мы же. Но «клеить руками под каждую пару» уходит. Вопрос не «учить или нет», а «успеть, пока MCP не стал базой как SQL». Хотя, может, я разогнался — спорьте.

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

@analyst_exe | https://analystexe.ru/articles/mcp-vs-api

Короче, я собрал себе угол интернета.

analystexe.ru

Давно хотел место, которое целиком моё. Тут нет ленты, которая по настроению алгоритма решает, показать тебя сегодня или нет. Просто сайт, куда складываю что делаю и о чём думаю.

Что там сейчас:

Методичка. Бета, прям совсем бета. Учебник аналитика, который пишу по кусочкам — то, что обычно объясняю на встречах по сто раз. Будет расти.

О себе. Кто я, где работал, чем занимаюсь. Чтоб не пересказывать каждый раз.

Статьи. Сюда дублирую посты из канала. Зачем — ну вы сами видели опрос: у 17% телега вообще не открылась, а большинство уже сидит через впн. Если её однажды прикроют, вы знаете, где меня искать. Подстраховка такая.

В планах — тренажёры (хочу, чтоб можно было реально порешать, а не только почитать) и раздел «полезное». Всё, что выкладываю, постепенно переедет туда тоже.

Накодил всё в паре с claude, на любимом янтарном терминале. Да, характер такий, мне нравится 🫡

Залетайте, потыкайте → analystexe.ru

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

@analyst_exe

Честно украденный мем, не опять, а снова

@analyst_exe

Соц опроооос

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

И вывалить вам все фишечки "Никита + компуктер"

Пальчик вверх, если надо

@analyst_exe

Сегодня легкий мем 🙈

Чирикните в комментариях, о чем можно написать?

@analyst_exe

Спрашивают про клиент-серверную архитектуру — и половина начинает про "ну вот сервер в дата-центре, а клиент на компе".

Стоп. Железо ни при чём. Речь про слои логики — кто рисует кнопку, кто проверяет права, кто хранит заказ.

Я сам когда-то на собесе нёс эту дичь про серверную стойку. Мидл ставил галочку "не догоняет архитектуру". Стыдно. Поэтому разложу так, чтобы кивали, а не вздыхали.

Раньше слоёв было два, теперь почти всегда три.

Раньше — двухслойка

Клиент и БД. Между ними ничего.

Клиент тут "толстый" — полноценное приложение на компе со всей логикой внутри. Например Delphi-десктоп в банке году в 2003-м. Знает строку подключения к Oracle, сам пишет SQL, лезет в базу. Часть правил — в коде клиента, часть — в хранимках (код, лежащий внутри БД и исполняемый ею самой).

Так жили 1С, банковские АРМы (Автоматизированные Рабочие Места), заводские учётки.

Бтв двухслойка не умерла. SQL Management Studio, DBeaver, Power BI, Excel с прямым коннектом — всё это она.

Откуда у трёхслойки растут ноги

Двухслойка треснула, как только из локалки полезли в большой интернет.

1. Интернет. Публиковать Oracle наружу — самоубийство. Любой школьник перебирает пароли по протоколу БД.
2. Масштаб. Сто клиентов — сто коннектов. Сто тысяч — БД упирается в max_connections, жрёт память и задыхается до запросов.
3. Обновления. Поменяли формулу скидки — а в полях 5000 АРМов. Половина обновится через месяц, половина никогда. База в один день считает разное. БУХГАЛТЕРИЯ В УЖАСЕ.
4. Безопасность. В коде клиента — пароль от БД. Декомпилировал .exe — забрал всё. Поменять больно: перевыпускай ПО для всех.
5. Платформы. К нулевым стало ясно: одного клиента мало. Веб, мобилка, десктоп. Копировать логику на три стека — путь в ад.

Так и появился бэкенд — отдельный слой логики посередине.

А сейчас — трёхслойка

1. Клиент — рисует интерфейс, держит UI-состояние. Бизнес-правил тут больше нет.
2. Бэкенд (API) — вся логика, валидации, права. Stateless: ничего про тебя не помнит, поэтому любая из ста копий за балансировщиком обслужит. Запросы по контракту (REST/gRPC/GraphQL), кто ты — по токену (JWT либо session id из Redis).
3. БД — в закрытой сети, доступ только из бэкенда. Бэк держит пул соединений (часто через PgBouncer) и переиспользует на тысячи клиентов.

Клиент стал ТУПОВАТЫМ. Хотя SPA на React "тонким" не назовёшь: роутинг, кэш, оптимистичные апдейты (UI обновляется до ответа сервера). Но суть та же: клиент рисует, бэк думает.

В проде слоёв обычно больше: CDN, API gateway, кэш, очереди, аналитика сбоку. Плюс идемпотентность, BFF, контракт-фёрст — это всё отдельные темы. Но снизу всё равно та же трёхслойка.

Браузер vs нативка

Браузерные — HTML/JS, ничего не ставить, обновления мгновенные. Минус: без интернета по умолчанию мёртвые (PWA умеют офлайн, но это отдельная работа), к железу доступ ограничен.

Нативные — iOS, Android, десктоп. Офлайн, камера, GPS, пуши, биометрия. Релиз через сторы, пользователь обновляется когда захочет (а захочет он никогда). Бэк тащит совместимость со старыми API годами.

Гибриды (Electron, React Native, Flutter) — браузер или JS-движок в обёртке. Куда их относить — вечный спор.

У нормального продукта пачка клиентов: веб, iOS, Android, десктоп. Все в один API 🫡

Видишь в требованиях "клиент" — сразу спрашивай: браузерный или нативный. От этого пляшет всё: оффлайн, пуши, релизы, версионирование API. Не уточнишь — будет жопа в спринте.

—————————————————————

И на десерт. Бизнес-логика в хранимках — это fat database. Антипаттерн или норма?

Защитники: "БД быстрее работает с данными, зачем гонять туда-сюда".
Противники: "не тестируется, не версионируется в git, рефакторинг — боль".

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

Зову тех, у кого половина системы в PL/SQL: как живёте? Джунам — спросить команду "у нас бизнес-логика где живёт?". Ответ расскажет про возраст системы.

@analyst_exe

«Они сливаются с ИИ в едином экстазе» — это знакомая тимлид про своих аналитиков. Я ржал минуту. Потом подумал — да блин, я и сам так делаю иногда.

В смысле что. Ставится задача. Юниор открывает ChatGPT. И они там вдвоём её мусолят полтора часа. Модель уносит в сторону — он не замечает. Половину гипотез сгенерила она — он не замечает. На выходе он защищает результат с пеной у рта. Не потому что прав. А потому что сам там сидел, печатал, спорил. Он же УЧАСТВОВАЛ.

Кейс из недавнего. Задача — спроектировать API под несколько продуктов. Парень приходит и приносит одну общую схему на все продукты. На вопрос «а нахуя одну на всё» отвечает: «ну так же удобно, всё в одном месте». Спрашиваю «и как это раскатывать без даунтайма, как версионировать, как ломать схему одного продукта без всех остальных» — а он не знает. И правда, нахуя.

Модель — не напарник. Ей пофиг на твой прод. На юзеров вообще пофиг. Про ваши legacy-таблицы с FK на пол-схемы она и не знает. Она дописывает за тобой. Не знаешь куда вести — она тебе CRUD нарисует и три абзаца обоснования сверху. Красиво. Бесполезно. Схема на пол-экрана, табличка на вторые пол-экрана. Ревьюить эту красоту — неделя.

Сам себя ловлю на «улучши» вместо нормального промта. «Улучши» = «подумай за меня». Ну и подумают. Не твоё.

Закрой чат. Расскажи решение голосом. Не можешь — слился.

🔥 — кто узнал юниора в команде.
🤔 — кто узнал себя.
❤️ — авансом.

@analyst_exe