Nocode как тренажер по архитектуре

Решил собрать небольшого бота. Логика сложновата для типичного конструктора, но и кодинг выглядел оверкиллом. Решил пойти к чатгпт, чтобы сделать вместе. Дитя Альтмана предложило мне взять Make (ex-Integromat) для логики + Airtable как хранилище. Мол все просто, за 3-4 часа запустишь, под твою задачу хватит бесплатного тарифа.

Что было дальше?
Убил три дня на первую версию, за время отладки улетели бесплатные лимиты, Airtable даже для экспресс прототипа нельзя рассматривать как хранилище, а Make подходит только для автоматизации простой операционки.

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

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

2. Реализовать хранение и извлечение стейта

3. Make ходит в Airtable через открытые интернеты, поэтому обращение к хранилищу может занимать 0,5-1,5 секунды. В рамках обработки запроса обращений несколько

4. Оптимизировать работу с недохранилищем

5. Организовать какой-то кэш, чтобы реже ходить туда

6. Продумать логику наполнения и инвалидации кэша

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

8. Увидеть, как логирование убивает скорость обработки, т.к. оно тоже идет в таблицу Airtable. Грустить, что нет кафки под рукой

К чему все это?
Если есть тяга к реальному проектированию, то задачка из жизни + сервис-автоматизатор-интегратор типа Make и n8n будет неплохим тренажером, чтобы пощупать реальные проблемы сисдизайна. Особенно из-за ограничений инструментов.

А ты все ищешь чудо-курсы по архитектуре и читаешь Сюй?

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

Завтра делаем стрим с создателями той самой AI IDE для аналитиков.

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

Если полетит, то попробуем собрать прототип по полученным артефактам в каком-нибудь реплите.

📆 Воскресенье, 18:30 мск

🔗 Ссыль для входа

#интеграция

Впервые встретил оправданное использование SSE в жизни. OpenAI позволяет получать ответ модели частями, до того, как она закончит генерить его - можно показывать пользователю результат по мере появления.

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

Вот тут еще пара статей про кейсы с SSE.

Сегодня день анонсов

21 августа, четверг
Провожу воркшоп на конфе аналитиков Контура. Будет сессия систем дизайна, на которой обратим внимание на фейлы, которые обычно случаются у аналитиков при проектировании архитектуры.

30 августа — 4 октября
Курс Интеграция и архитектура систем — разбираем наиболее востребованные паттерны, погружаемся в инфру, учимся обеспечивать отказоустойчивость, проектируем распределенные системы. И да, многим обучение помогло на собесах, хотя делали не для этого.

7–28 сентября
Курс Основы проектирования API — программа, как для начинающих, чтобы разобраться, как правильно использовать POST-PUT-PATCH, что такое правильно, и кто такой этот ваш REST.
Так и для людей с опытом, чтобы углубиться в уровни зрелости REST API, RPC API, что и когда лучше использовать, научиться защищать и аргументировать решения.

Пишите, приходите на чаек.

#интеграции

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

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

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

28 августа, в четверг вечером, Андрей Бураков поделится опытом как ограничения и нефункциональные требования влияют на выбор технологии интеграции и что нужно знать и уметь аналитику, чтобы осмысленно подходить к проектированию интеграционной архитектуры.
Ссылка на регистрацию

#интеграции #архитектура

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

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

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

Что будем делать, если кратко:

— закапываться в сети и инфру

— обеспечивать надежность системы, использовать паттерны отказоустойчивости

— масштабировать решения за счет кеширования, балансировки, репликации

— использовать брокеры и событийную архитектуру

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


Вот некоторые из моих креативов, чтобы составить впечатление о стиле и адекватности:
• Чем полезна CAP-теорема
• Способы передачи событий от фронта к беку
• Что такое шины, и почему они разные
• Почему брокеры сообщений ничего не гарантируют

Приходите, будет больно, но весело.

#продуктовое

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

Недавно мне показали, что на iOS калькуляторе появилась история. Можно не просто посчитать что-то, а посмотреть историю в формате:

2+3 = 5
421х10 = 4210
17^3 / 3 = 1637,6666667

Радости моей не было предела. Угадаете, почему?

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

В идеале это еще записывать, но бесконечный дневник не нужен, хватит недели. А теперь открываю историю, и вижу калькуляции за последние 30 дней. Шах и мат, смузишные стартаперы.

Интересно, разрабы в курсе такого юз кейса?

Немного диванной Ванги

Последняя пятница лета, погода мразь (а у вас как?), гадаю на пуэрной жиже. Дело неблагодарное, но и мы не в гартнере.

Что жду в ближайшие ~3 года от индустрии:

Разрабы будут решать больше задач проектирования и систем дизайна, тупой и бойлерплейт код будет все больше в копайлоты и другие AI-инструменты. Будут расти требования к базовому пониманию продукта и бизнеса, в котором они работают. Люди, которые хотят просто писать кодик, начнут вымирать.

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

Продакты будут больше погружаться в технику, примерно как сисаналисты 2-3 года назад, активнее использовать no-low-vibe code инструменты для прототипирования и гипотез.

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

В целом, роли будут размываться, появятся какие-то новые, AI-first.

Делайте ваши ставки, дамы и господа, скидывайте в комменты.

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

Чет я соскучился по вебинарам, приходите во вторник поговорить об использованни REST API первого уровня, и почему в большинстве случаев оно подходит намного лучше, чем "правильные ресты". Ну и похоливарить не забудем.

https://nextway.timepad.ru/event/3552697

#интеграция

Подвезли запись вебинара и небольшой конспект по нему.

Вообще мораль в том, что не надо изучать технологии по обзорам и чеклистам (вы их все равно выбирать не будете), а копать в детали и изучать матчасть. Но разве будет кто-то слушать?

Вот вам еще пророчеств темного будущего

https://t.iss.one/glebkudr/1393

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

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

• REST, что ты такое? — про архитектурный стиль и терминологию

• REST, почему ты такой? — почему HTTP протокол такой, каким мы его знаем, и причем здесь REST

• REST, что с тобой не так? — о проблемах использования REST API, и как их можно лечить

• Ваше API уже созрело? — как избавиться от ограничений каноничного REST API за счет снижения уровня зрелости до Level 1, чтобы ваше API не превратилось в кровавое месиво

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

Если долго смотреть на идею, можно увидеть, как ее реализует кто-нибудь другой. Я давно хотел провести конфу для сисаналистов в формате подлодки, но как-то все не складывалось. А коллеги из SE сделали, да еще и про AI в архитектуре, да еще и бесплатно. Ну вы поняли, что делать.

https://systemsdesign.online/2025-ai

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

Безумная неделя, как бы разорваться, чтобы везде.

Сегодня на TechFounders запиваю смузи ланвандовым рафом и слушаю всякое про стартапы. Если вы тоже, то го на чаек.

Завтра утром стартует недельная онлайн конфа от SE про использование AI в проектировании систем.
А вечером делаем стрим с Валерием Зубаировым о System Design секциях на собесах сисаналистов.

В среду будет сразу две конфы про AI и около: от Сбера и от Яндекса - еще можно заскочить в онлайн. Собирается кто вживую?

Объявляю сезон открытым.

Есть такое понятие — enabling teams. Это типа такие команды, которые создают общие практики, разрабатывают либы и решения, которые ускоряют всю компанию, повышают её эффективность. Рядом с ними — платформы и платформенные команды.

Но почему нет их антипода, термина disabling teams? Считаю, что это упущение.
Вот несколько лозунгов такой команды:

- Прозрачность важнее автономии
- Единые правила важнее локальной эффективности
- Измеримость важнее доверия
- Контроль важнее экспериментов
- Согласованность важнее скорости

Сначала процесс — потом прогресс! Без метрик нет управления! Каждый шаг под контролем — гарантия успеха! Оптимизация делается через стандартизацию!

Плохо, что ли? Хорошо!

#AI

Привет неверующим и незаменимым!

Последнее время почтовые совы приносят в редакцию интересные новости:

— в одной цветной компании на собесе аналитика появилась секция, где просят спроектировать систему с помощью LLM

— в другой большой компании продактам на собесе предлагают собрать прототип продукта или фичи с помощью AI-инструментов

Пока не на все проекты, на сколько знаю. Пока.

От вас хотели AI на собесах? Поделитесь в комментах, как это было.

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

Чет у меня сегодня в ленте везде про C4.

Кто не в курсе, это модная модель для фиксации архитектуры в схемах, смотрите тут

Недавно по нему на степике появился курс от Ярослава Атрохова.

А вот тут Алексей Рыбак делится мыслями и критикой модели:

Претензия первая: неконкретность контейнеров и компонент. Рабочими слоями для MC4 являются всего два слоя: контейнер и компонент. В MC4 понятия “контейнер” и “компонент” размыты, контейнер это не контейнер в смысле инфры, а компонент это вообще хер пойми что, и в результате часто люди рисуют диаграммы, из которых непонятно вообще нихера. При этом в классическом бигтеховском системном дизайне есть негласное четкое правило: кружочек это всегда четкий сервис (реже подсистема), а стрелочка это всегда запрос с понятным протоколом и пониманием, сколько каких запросов тут повалит и для чего, поскольку нужно оценивать параметры трафика, нагрузки, объема хранимых данных.

Тут частично соглашусь: контейнер и компонент - очень неоднозначные термины в ит вообще, и C4 ясности не добавляет. Сколько фреймворков не изобретай, все равно все стрелочки с квадратиками рисуют как удобно.

#оффтоп

Ребят, у вас там все хорошо в медтехе?