Кейс-вопрос на пятницу 🤔
Пока получаю и жду обратную связь по открытому уроку «Вайбкодим прототип за 1 час», подкину реальную задачку на архитектурные трейдоффы:
Нужно закрыть админку на статичном сайте паролем, но бэкенд-сервиса для авторизации нет (и поднимать его ради этого не планируется).
Есть ли у кого-нибудь опыт реализации такого через клиентское шифрование?
Просто кейс на порассуждать и поделиться практикой: какие грабли ловили, какие библиотеки крутили и жизнеспособно ли это вообще? Делитесь опытом, подсказывайте в комментариях 👇
Пока получаю и жду обратную связь по открытому уроку «Вайбкодим прототип за 1 час», подкину реальную задачку на архитектурные трейдоффы:
Нужно закрыть админку на статичном сайте паролем, но бэкенд-сервиса для авторизации нет (и поднимать его ради этого не планируется).
Есть ли у кого-нибудь опыт реализации такого через клиентское шифрование?
Просто кейс на порассуждать и поделиться практикой: какие грабли ловили, какие библиотеки крутили и жизнеспособно ли это вообще? Делитесь опытом, подсказывайте в комментариях 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
Дайджест: лучшее и самое полезное за прошлый месяц💥
Для тех, кто недавно присоединился к каналу или пропустил посты в рабочем цейтноте: собрал подборку материалов, которые в прошлом месяце вызвали максимальный отклик, улетали в репосты и собирали сотни комментариев.
👑 Абсолютный чемпион месяца (в топе по реакциям, репостам и комментам) - [Подкаст «Системных аналитиков не станет?» - разбираем будущее IT-проектирования без хайпа и иллюзий!]
Большой и честный разговор про будущее профессии, ИИ-инструменты, изменение рынка и то, за какими навыками аналитикам стоит бежать прямо сейчас, чтобы оставаться востребованными.
🔄 ТОП-2 по репостам (практика, которую уносили в рабочие чаты)
[Почему кривой JSON Schema ломает и разработку, и ИИ-агентов] - микро-урок по типичным ошибкам контрактов: почему синтаксически валидная схема может парализовать команду и как правильно описывать ограничения.
[Как один REST-запрос может положить банковскую систему] - разбор реального архитектурного факапа: каскадные падения, отсутствие таймаутов и почему «простой синхронный вызов» в проде опасен.
💬 ТОП по комментариям (где ярче всего кипели дискуссии) - [Тест на инженерное мышление]
Кейс-задачка, в комментариях к которой аналитики и разработчики спорили о логике проектирования и граничных сценариях. Пицца конечно имела значение 😁
📌 Сохраняйте подборку в «Избранное», чтобы изучить на досуге, и пересылайте коллегам-аналитикам и разработчикам, кому актуальна тема интеграций и архитектуры.
Для тех, кто недавно присоединился к каналу или пропустил посты в рабочем цейтноте: собрал подборку материалов, которые в прошлом месяце вызвали максимальный отклик, улетали в репосты и собирали сотни комментариев.
👑 Абсолютный чемпион месяца (в топе по реакциям, репостам и комментам) - [Подкаст «Системных аналитиков не станет?» - разбираем будущее IT-проектирования без хайпа и иллюзий!]
Большой и честный разговор про будущее профессии, ИИ-инструменты, изменение рынка и то, за какими навыками аналитикам стоит бежать прямо сейчас, чтобы оставаться востребованными.
🔄 ТОП-2 по репостам (практика, которую уносили в рабочие чаты)
[Почему кривой JSON Schema ломает и разработку, и ИИ-агентов] - микро-урок по типичным ошибкам контрактов: почему синтаксически валидная схема может парализовать команду и как правильно описывать ограничения.
[Как один REST-запрос может положить банковскую систему] - разбор реального архитектурного факапа: каскадные падения, отсутствие таймаутов и почему «простой синхронный вызов» в проде опасен.
💬 ТОП по комментариям (где ярче всего кипели дискуссии) - [Тест на инженерное мышление]
Кейс-задачка, в комментариях к которой аналитики и разработчики спорили о логике проектирования и граничных сценариях. Пицца конечно имела значение 😁
📌 Сохраняйте подборку в «Избранное», чтобы изучить на досуге, и пересылайте коллегам-аналитикам и разработчикам, кому актуальна тема интеграций и архитектуры.
🔥1
Media is too big
VIEW IN TELEGRAM
Хей! А не собраться ли нам в оффлайне? 👀
На работе мы только и делаем, что «минимизируем человеческий фактор и всё оцифровываем» (на видео как раз на серьезных щах рассуждаю об этом 👆).
Но в жизни этого самого человеческого фактора стало не хватать. Всё онлайн да онлайн: чаты, вебинары, войсы и созвоны.
Есть мысль развиртуализироваться и провести ламповый оффлайн-эвент в Москве (по датам ориентируемся на октябрь–ноябрь).
Какой формат планируем:
👉 Никаких душных презентаций на 2 часа и корпоративной «воды».
👉 Живой нетворкинг, открытый микрофон и ответы на любые вопросы без купюр.
👉 Из спикеров: буду я + как минимум тимлид разработки с плотным сеньорским бэкграундом.
👉Вход сделаем чисто символическим — буквально по цене поездки на такси субботним утром из клуба 🚕 (чисто чтобы отсечь случайных людей и оплатить аренду уютной площадки).
А вот о чем именно говорить — хотим решить вместе с вами, а не придумывать темы из головы.
Проголосуйте в опросе ниже (можно выбрать несколько вариантов или накидать своих идей в комментариях) 👇
На работе мы только и делаем, что «минимизируем человеческий фактор и всё оцифровываем» (на видео как раз на серьезных щах рассуждаю об этом 👆).
Но в жизни этого самого человеческого фактора стало не хватать. Всё онлайн да онлайн: чаты, вебинары, войсы и созвоны.
Есть мысль развиртуализироваться и провести ламповый оффлайн-эвент в Москве (по датам ориентируемся на октябрь–ноябрь).
Какой формат планируем:
👉 Никаких душных презентаций на 2 часа и корпоративной «воды».
👉 Живой нетворкинг, открытый микрофон и ответы на любые вопросы без купюр.
👉 Из спикеров: буду я + как минимум тимлид разработки с плотным сеньорским бэкграундом.
👉Вход сделаем чисто символическим — буквально по цене поездки на такси субботним утром из клуба 🚕 (чисто чтобы отсечь случайных людей и оплатить аренду уютной площадки).
А вот о чем именно говорить — хотим решить вместе с вами, а не придумывать темы из головы.
Проголосуйте в опросе ниже (можно выбрать несколько вариантов или накидать своих идей в комментариях) 👇
🔥3
Please open Telegram to view this post
VIEW IN TELEGRAM
«Я просто подниму пару ИИ-агентов, и они сделают всю работу за меня»
• 1 стадия: «Вау, нейросеть написала мне OpenAPI-схему и регулярку!»
• 2 стадия: «Промпт на 5 экранов, почему ты опять игнорируешь системную инструкцию?!»
• 3 стадия: Агенты зациклились, сожгли $150 на токенах за 10 минут, поругались между собой и задеплоили пустой README в прод.
Признавайтесь, на какой стадии находитесь прямо сейчас? 👇
(И перешлите коллеге, который на этой неделе собирался автоматизировать весь отдел)
• 1 стадия: «Вау, нейросеть написала мне OpenAPI-схему и регулярку!»
• 2 стадия: «Промпт на 5 экранов, почему ты опять игнорируешь системную инструкцию?!»
• 3 стадия: Агенты зациклились, сожгли $150 на токенах за 10 минут, поругались между собой и задеплоили пустой README в прод.
Признавайтесь, на какой стадии находитесь прямо сейчас? 👇
(И перешлите коллеге, который на этой неделе собирался автоматизировать весь отдел)
😁6
«Писала пользовательские требования, но не знала технику»: как наша ученица за 2 недели нашла работу системным аналитиком в процессе курса
#ученикиговорят
Классическая ситуация для многих ребят в IT: ты приходишь в анализ со стороны бизнеса, отлично общаешься с заказчиками, пишешь User Stories и регламенты. Но как только дело доходит до реализации, разработка начинает сыпать вопросами: «где контракт эндпоинта?», «а как обрабатываем таймауты?», «что летит в payload?».
В этот момент наступает ступор. В российских реалиях чистый бизнес-анализ часто упирается в карьерный и зарплатный потолок, а системный анализ требует твердого понимания техники.
Именно с такой ситуацией к нам пришла наша ученица (отзыв прикрепил выше 👆):
🔹 Точка А: с 2021 года работала в международной компании на позиции бизнес-аналитика. Фокус был исключительно на бизнес-требованиях - без погружения в технику и без опыта проектирования интеграций. Со временем поняла, что системный анализ намного перспективнее.
🔹 Действие: в конце 2023 года зашла на курс по проектированию интеграций, чтобы получить структурированную базу по архитектуре сервисов и контрактам.
🔹 Результат: не стала ждать «идеального момента», когда весь курс будет пройден от корки до корки. Спустя пару месяцев обучения, набравшись технической уверенности, она открыла резюме — и всего за 2 недели получила оффер системным аналитиком. И успешно работает в этой роли по сей день.
Главный вывод этой истории: вам не нужно годами зубрить код или читать неподъемные талмуды по архитектуре. Достаточно один раз по полочкам разложить базовую механику: как сервисы общаются между собой (REST, брокеры сообщений), как грамотно составить спецификацию OpenAPI и спроектировать структуры данных. Когда этот фундамент есть, страх перед техническими собеседованиями уходит сам собой.
Если вы сейчас тоже работаете на стыке бизнеса и разработки и хотите уверенно закрыть технический пробел 👉 Пройдите бесплатные вводные уроки на Stepik - оцените глубину практики и формат подачи материала перед стартом + небольшой персональный бонус по ссылке.
📌 Что еще полезного почитать в канале:
• Подкаст «Системных аналитиков не станет?» - большой разбор про будущее профессии, смену стека и навыки, которые рынок требует прямо сейчас
• Микро-урок по частым ошибкам в JSON Schema - наглядный пример того, как криво составленный контракт парализует разработку
• Свежий урок из закрытого модуля по ИИ «Вайбкодим прототип за 1 час и деплоим в сеть за 1 ₽» (Бесплатный доступ)
Мы в МАХ
#ученикиговорят
Классическая ситуация для многих ребят в IT: ты приходишь в анализ со стороны бизнеса, отлично общаешься с заказчиками, пишешь User Stories и регламенты. Но как только дело доходит до реализации, разработка начинает сыпать вопросами: «где контракт эндпоинта?», «а как обрабатываем таймауты?», «что летит в payload?».
В этот момент наступает ступор. В российских реалиях чистый бизнес-анализ часто упирается в карьерный и зарплатный потолок, а системный анализ требует твердого понимания техники.
Именно с такой ситуацией к нам пришла наша ученица (отзыв прикрепил выше 👆):
🔹 Точка А: с 2021 года работала в международной компании на позиции бизнес-аналитика. Фокус был исключительно на бизнес-требованиях - без погружения в технику и без опыта проектирования интеграций. Со временем поняла, что системный анализ намного перспективнее.
🔹 Действие: в конце 2023 года зашла на курс по проектированию интеграций, чтобы получить структурированную базу по архитектуре сервисов и контрактам.
🔹 Результат: не стала ждать «идеального момента», когда весь курс будет пройден от корки до корки. Спустя пару месяцев обучения, набравшись технической уверенности, она открыла резюме — и всего за 2 недели получила оффер системным аналитиком. И успешно работает в этой роли по сей день.
Главный вывод этой истории: вам не нужно годами зубрить код или читать неподъемные талмуды по архитектуре. Достаточно один раз по полочкам разложить базовую механику: как сервисы общаются между собой (REST, брокеры сообщений), как грамотно составить спецификацию OpenAPI и спроектировать структуры данных. Когда этот фундамент есть, страх перед техническими собеседованиями уходит сам собой.
Если вы сейчас тоже работаете на стыке бизнеса и разработки и хотите уверенно закрыть технический пробел 👉 Пройдите бесплатные вводные уроки на Stepik - оцените глубину практики и формат подачи материала перед стартом + небольшой персональный бонус по ссылке.
📌 Что еще полезного почитать в канале:
• Подкаст «Системных аналитиков не станет?» - большой разбор про будущее профессии, смену стека и навыки, которые рынок требует прямо сейчас
• Микро-урок по частым ошибкам в JSON Schema - наглядный пример того, как криво составленный контракт парализует разработку
• Свежий урок из закрытого модуля по ИИ «Вайбкодим прототип за 1 час и деплоим в сеть за 1 ₽» (Бесплатный доступ)
Мы в МАХ
🔥4
Когда микросервисы — это ошибка: как команды плодят «распределенные монолиты»
Регулярно вижу на архитектурных созвонах одну и ту же картину: систему распилили на 30 сервисов не потому, что этого требовал бизнес, а просто «потому что так модно и написано в статьях».
В итоге вместо гибкой архитектуры команда получает распределенный монолит:
• Сервис А синхронно дергает Б, тот идет в В, а В ждет ответ от сервиса Г.
• Задержка растет на ровном месте: вместо прямого вызова метода внутри процесса гоняем JSON по сети туда и обратно.
• Затаймаутил один узел в цепочке — посыпался весь пользовательский сценарий.
• Простая транзакция в базе превратилась в головную боль: теперь нужны распределенные компенсационные транзакции, очереди сообщений и строгая идемпотентность на каждом шаге.
• Независимых релизов нет: чтобы выкатить одну фичу, приходится согласованно деплоить пачку сервисов в три часа ночи.
Получаются все минусы монолита, только теперь с сетевыми сбоями и оверинжинирингом.
В чем корень проблемы?
Систему порезали не по изолированным бизнес-контекстам (`Bounded Context`), а механически — по таблицам в базе данных.
Что держать в голове системному аналитику:
1. Модульный монолит — это нормально. Пока проект не уперся в организационные ограничения, один сервис с четкой модульной структурой надежнее, быстрее и кратно дешевле в поддержке.
2. Каждый синхронный HTTP-вызов — точка отказа. Если сервисам нужно постоянно общаться синхронно, скорее всего, они должны жить в одном сервисе.
3. Микросервисы нужны людям, а не коду. Разделение оправдано в первую очередь организационно: когда за разные части системы отвечают полностью независимые команды со своими релизными циклами, либо когда нужно изолировать специфическую тяжелую нагрузку.
Регулярно вижу на архитектурных созвонах одну и ту же картину: систему распилили на 30 сервисов не потому, что этого требовал бизнес, а просто «потому что так модно и написано в статьях».
В итоге вместо гибкой архитектуры команда получает распределенный монолит:
• Сервис А синхронно дергает Б, тот идет в В, а В ждет ответ от сервиса Г.
• Задержка растет на ровном месте: вместо прямого вызова метода внутри процесса гоняем JSON по сети туда и обратно.
• Затаймаутил один узел в цепочке — посыпался весь пользовательский сценарий.
• Простая транзакция в базе превратилась в головную боль: теперь нужны распределенные компенсационные транзакции, очереди сообщений и строгая идемпотентность на каждом шаге.
• Независимых релизов нет: чтобы выкатить одну фичу, приходится согласованно деплоить пачку сервисов в три часа ночи.
Получаются все минусы монолита, только теперь с сетевыми сбоями и оверинжинирингом.
В чем корень проблемы?
Систему порезали не по изолированным бизнес-контекстам (`Bounded Context`), а механически — по таблицам в базе данных.
Что держать в голове системному аналитику:
1. Модульный монолит — это нормально. Пока проект не уперся в организационные ограничения, один сервис с четкой модульной структурой надежнее, быстрее и кратно дешевле в поддержке.
2. Каждый синхронный HTTP-вызов — точка отказа. Если сервисам нужно постоянно общаться синхронно, скорее всего, они должны жить в одном сервисе.
3. Микросервисы нужны людям, а не коду. Разделение оправдано в первую очередь организационно: когда за разные части системы отвечают полностью независимые команды со своими релизными циклами, либо когда нужно изолировать специфическую тяжелую нагрузку.
👍3
Синдром «Да я примерно понимаю, как этот ваш gRPC работает»: кейс нашего ученика Федора
#ученикиговорят
Признайтесь, у кого хоть раз было: на созвоне с умным лицом киваешь разработчикам, сыплешь терминами gRPC, REST и SOAP, а внутри одна мысль «Господи, только бы не спросили, как это реально устроено, а то придется делать вид, что звук залагал»😅
С этим сталкивается почти каждый практикующий специалист. В резюме написано красиво, а в реальности знания собраны по кусочкам из чужих спецификаций, правок от бэкендеров и ночного гуглежа.
Именно с такой ситуацией на курс пришел Фёдор (отзыв со Stepik на скрине 👆):
📍 Точка А:
• Было «примерное понимание», как работают интеграции. Задачи как-то закрывались (местами на опыте, местами на молитвах).
• Не хватало системности: вроде протоколы на слуху, но в деталях плаваешь.
• Постоянное ощущение, что ходишь по минному полю чужих архитектурных решений.
📍 Точка Б:
• Разложил по полочкам матчасть: глубоко разобрался в различиях и тонкостях REST, JSON-RPC, gRPC и SOAP. Теперь выбор архитектурного стиля — это осознанный расчет, а не лотерея.
• Закрыл главную дыру большинства специалистов — модули по безопасности, оптимизации и отказоустойчивости. Написать эндпоинт может каждый, а сделать так, чтобы он не положил прод при первом сбое уже инженерное искусство.
• Знания превратились в четкую структуру, которую Фёдор сразу пошел внедрять в практику (и поставил курсу 5 звезд ⭐).
«Примерное понимание» - штука удобная, пока система не упрется в первый боевой факап. Но куда приятнее спать по ночам, точно зная, как поведет себя твоя архитектура под нагрузкой.
Если хотите навести такой же железный порядок в интеграциях 👉 [Тариф с проверкой преподавателя на Stepik]- ручное код-ревью ваших схем и контрактов от практикующих экспертов.
📌 Кем еще вдохновиться по теме:
• С 30-40к до Ведущего системного аналитика в Финтехе на 300к+: История Павла
• Как наша ученица за 2 недели нашла работу системным аналитиком в процессе курса
#ученикиговорят
Признайтесь, у кого хоть раз было: на созвоне с умным лицом киваешь разработчикам, сыплешь терминами gRPC, REST и SOAP, а внутри одна мысль «Господи, только бы не спросили, как это реально устроено, а то придется делать вид, что звук залагал»😅
С этим сталкивается почти каждый практикующий специалист. В резюме написано красиво, а в реальности знания собраны по кусочкам из чужих спецификаций, правок от бэкендеров и ночного гуглежа.
Именно с такой ситуацией на курс пришел Фёдор (отзыв со Stepik на скрине 👆):
📍 Точка А:
• Было «примерное понимание», как работают интеграции. Задачи как-то закрывались (местами на опыте, местами на молитвах).
• Не хватало системности: вроде протоколы на слуху, но в деталях плаваешь.
• Постоянное ощущение, что ходишь по минному полю чужих архитектурных решений.
📍 Точка Б:
• Разложил по полочкам матчасть: глубоко разобрался в различиях и тонкостях REST, JSON-RPC, gRPC и SOAP. Теперь выбор архитектурного стиля — это осознанный расчет, а не лотерея.
• Закрыл главную дыру большинства специалистов — модули по безопасности, оптимизации и отказоустойчивости. Написать эндпоинт может каждый, а сделать так, чтобы он не положил прод при первом сбое уже инженерное искусство.
• Знания превратились в четкую структуру, которую Фёдор сразу пошел внедрять в практику (и поставил курсу 5 звезд ⭐).
«Примерное понимание» - штука удобная, пока система не упрется в первый боевой факап. Но куда приятнее спать по ночам, точно зная, как поведет себя твоя архитектура под нагрузкой.
Если хотите навести такой же железный порядок в интеграциях 👉 [Тариф с проверкой преподавателя на Stepik]- ручное код-ревью ваших схем и контрактов от практикующих экспертов.
*На Stepik доступна беспроцентная рассрочка — от 2 100 руб./мес без переплат. Кому нужны промокоды - пишите в лс https://t.me/glebteach_bot
📌 Кем еще вдохновиться по теме:
• С 30-40к до Ведущего системного аналитика в Финтехе на 300к+: История Павла
• Как наша ученица за 2 недели нашла работу системным аналитиком в процессе курса
🔥1
В честь вчерашнего дня системного аналитика пятничный архитектурный холивар: как не положить прод на миллионной рассылке ⚡️
Коллеги, с прошедшим! Желаю, чтобы требования были однозначными, интеграции — документированными, а вопросы от бизнеса хотя бы иногда появлялись до, а не после выхода в прод 😄
Обсудим сегодня классический вопрос с собеседований на сеньора: в системе происходит массовое событие (старт распродажи или ночной сбой), и нужно отправить пуши 1 000 000 пользователей.
Если делать наивно - база захлебывается в коннектах, воркеры падают по памяти, а внешние шлюзы заваливают сервис таймаутами.
Вопрос: через какой инструмент вы бы пропустили эту очередь в своем проекте? 👇
Коллеги, с прошедшим! Желаю, чтобы требования были однозначными, интеграции — документированными, а вопросы от бизнеса хотя бы иногда появлялись до, а не после выхода в прод 😄
Обсудим сегодня классический вопрос с собеседований на сеньора: в системе происходит массовое событие (старт распродажи или ночной сбой), и нужно отправить пуши 1 000 000 пользователей.
Если делать наивно - база захлебывается в коннектах, воркеры падают по памяти, а внешние шлюзы заваливают сервис таймаутами.
Вопрос: через какой инструмент вы бы пропустили эту очередь в своем проекте? 👇
Please open Telegram to view this post
VIEW IN TELEGRAM