Another Tech Product
6.36K subscribers
35 photos
1 file
288 links
Анализ, архитектура, менеджмент в IT

Вопросы сюда: @and_burakov
Download Telegram
Завтра делаем стрим с создателями той самой AI IDE для аналитиков.

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

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

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

🔗 Ссыль для входа
🔥17💩6👍1
#интеграция

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

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

Вот тут еще пара статей про кейсы с SSE.
👍92
Сегодня день анонсов

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

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

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

Пишите, приходите на чаек.
🔥51
#интеграции

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

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

На самом деле задача выбора технологий в природе почти не встречается, если только вы не CTO стартапа или архитектор новой системы. Но об этом спрашивают на собесах, и вообще модно рассуждать, так чем мы хуже?
👍8
28 августа, в четверг вечером, Андрей Бураков поделится опытом как ограничения и нефункциональные требования влияют на выбор технологии интеграции и что нужно знать и уметь аналитику, чтобы осмысленно подходить к проектированию интеграционной архитектуры.
Ссылка на регистрацию
👍135👀1
#интеграции #архитектура

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

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

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

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

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

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

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

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

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


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

Приходите, будет больно, но весело.
7❤‍🔥2👍1🤮1💩1🙏1
#продуктовое

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

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

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

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

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

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

Интересно, разрабы в курсе такого юз кейса?
😁36🔥7👍2🤔2👀2
Немного диванной Ванги

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

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

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

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

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

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

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

Делайте ваши ставки, дамы и господа, скидывайте в комменты.
🤔1613💯11👎4👍3🙏1
#интеграция #API

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

https://nextway.timepad.ru/event/3552697
🔥11👍3🥰21
Календарь намекает, что надо написать что-нибудь на тему образования .

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

Как-то в канале Дорофеева попался пост: https://xn--r1a.website/mnogosdelal/696

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

…проблема проста - человеку не понятно, как выполнить упражнение без ошибок. Почему не понятно? Потому что он этого раньше никогда не делал (он же приходит к нам учиться делать то, что раньше не делал). Так, может, для того, чтобы появилось понимание надо... начать делать?...


Как-то среди фидбека на очередное занятие курса, который вел, нашел два отзыва:

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


Опять дают задачу без объяснений и примера - копаемся как слепые котята.


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

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

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

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

Тут должен быть какой-то призыв, но придумайте сами. А всех причастных с праздником 🎓
Please open Telegram to view this post
VIEW IN TELEGRAM
👍241🔥1💯1
🍃 Пока календарь не перевернули, приходите вечером в 18 мск порассуждать о несовершенстве рестов. Буду вещать, почему правильное REST API - почти всегда неудачное решение, как полечить его болячки за счет снижения уровня зрелости, и что делать, чтобы ваше апи первого уровня не превратилось в кровавое месиво через несколько итераций доработок. Заваривайте чаек, оборачивайтесь пледом, будем говорить о вечном.
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍132
#интеграция #API

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

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

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

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

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

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

https://systemsdesign.online/2025-ai
👍17😁3
#конференции

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

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

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

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

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

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

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

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

Плохо, что ли? Хорошо!
🔥11
#AI

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

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

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

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

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

От вас хотели AI на собесах? Поделитесь в комментах, как это было.
🔥126💩4😱3👎2😭2😁1
#архитектура

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

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

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

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

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


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

Ребят, у вас там все хорошо в медтехе?
😁42🔥3👎1
#AI

10-15 лет назад энтерпрайзом правила SOA, в рамках которой огромные команды и отделы постоянно пилили и дорабатывали компоненты под интеграционный слой: роутеры, адаптеры, агрегаторы, канонические сервисы - все прелести ESB. Обычно это строилось на базе монструозных решений от IBM и Oracle, но более сообразительные уже пытались слезть с иглы на Camel и подобное. Кстати, до сих пор не все слезли.

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

К чему это я?
Процентов 80% всей этой работы можно было бы делать через вайбкодинг при наличии ревью и грамотной стандартизации/шаблонизации. И что-то подсказывает, что сегодня в глубинах корпоративных бэков полно подобных задач, которые можно так же решать. Но кто ж признается.
👍15💩5🤬3🤡3