Yet Another Burakov

Знакомый поделился прекрасным. Однажды он обнаружил сервис с методом:

GET /api/getClientInfo?clientId=123

Попробуйте угадать, что он делает:
1. Если клиент не существует
2. Если клиент существует

Дада, вы все правильно поняли:
1. Сервис создает клиента
2. Сервис открывает клиенту счет

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

А вы какие шедевры встречали в практике?

Кажется, что-то интересное намечается

https://mts-digital.ru/events/details?id=742631

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

Проблемы, варианты решения, акторная модель поверх Кафки. Читать вдумчиво, статья не смузишная.

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

Только потом нужно объяснить, что из этого никак не следует, что “В реальности сроков не существует”.

Мало кто знает, но просить от сотрудника оценку задачи, которую ты ему поручил, нужно не чтобы оценить сроки, он все равно ошибется и все сроки просрет, тут поможет только статистика и sla. Дело не в этом. Просто наличие оценки - это отличная метрика того, что была произведена декомпозиция. А декомпозиция говорит о том, что над задачей уже размышляли, планировали, думали о результате. Поэтому просто узнать число недостаточно, придется самому вникнуть и понять, почему это число именно такое, а главное, самому стоит представлять результат задачи, а не фантазировать его на ходу, принимая работу.

Я тут продал душу вписался в историю с папками. Здесь собрали 20 каналов про системный анализ. Не знаю, зачем столько, но можете найти интересное.

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

https://youtu.be/7oIXcJo56rE

Еще про мышление

Обратил внимание, что наиболее эффективно работаю над сложными задачами, когда использую три механики:

Визуализация
Чтобы увидеть элементы системы и отношения между ними. Обычно нахожу неявные связи, о которых не подумал или не знал.

Текстовое описание
Важно описать продукт, систему или процесс так, чтобы читатель осилил текст и правильно понял его. Лаконично, содержательно и доступно для разных ролей. Позволяет проработать детали, выявить корнеры, покрутить разные point of view. Максимально больно в мозг.

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

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

Поэтому холивар “Давайте соберемся обсудим” vs “Мы отправили документ, пришлите вопросы к обсуждению” никогда не закончится. И это нормально. А вот доверять решениям, если использовали только один инструмент - не очень.

#мышление

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

Люблю рассказы в духе: “Возьмите фреймворк XXX для задачи NNN, и будет вам счастье”. Дальше обычно начинается холивар: “Мы попробовали, и получилась какая-то хрень”.

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

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

Зато в процессе возникнут вопросы:

• Какие сегменты охватывает фича? Сколько там клиентов? Как они платят?

• Какой профит получим? Это оптимистично или пессимистично?

• Как оценивали? Есть данные, результаты исследований, или это чье-то мнение?

• Есть зависимости от других команд и отделов?

Если потратить время на аргументированные ответы, то уже это даст уйму полезной инфы для принятия решений. Без магии чисел и функций.

Или Use Cases
Как самостоятельный способ передачи требований - ужас ужасный.
Обычная реакция после прочтения: “Кулл стори, бро, но объясни нормально, что сделать нужно?”

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

Если смотреть на все это как на инструменты мышления, то получается интересно - не так важно, какой артефакт мы получили в итоге; важнее, какие выводы, информацию и идеи мы получили в процессе.

#мышление

Осторожно, реклама

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

Кому будет полезно:

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

◽️Вы развиваетесь в сторону проектирования систем и хотите получить дополнительную практику.

◽️Вам просто интересна архитектура.

Самое ценное по версии участников:

◽️Инструменты масштабирования: балансировка, шардирование, кеширование

◽️Работа с хранилищами: выбор под задачу, RDBMS, NoSQL, DWH, индексы

◽️Спикер и подача материала: понятно, последовательно, незанудно, с юмором

◽️Общение со спикером в режиме открытого микрофона: можно обсудить интересующую тему, получить подробные ответы, разобрать кейсы из практики

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

📆 Запрыгивайте, ждем 7-8 сентября в 10:00-14:00 (UTC +3)

🔗 Регаться тут

OWASP для LLM приложений. Список уязвимостей с интересными примерами атак.

Для меня некоторые оказались совсем неочевидными. Здравствуй, дивный новый мир.

NextWayConf

Когда-нибудь я научусь сначала пиарить, а потом делать что-то, но не в этот раз.

В субботу традиционно проводим летнюю конфу для аналитиков. Поговорим об архитектурно-техническом, документировании и жизни в этом суровом мире.

Будет два стрима: доклады и воршкопы. Что из технического:

◽️Научимся расчитывать сайзинг data-платформы на примере Flink на воркшопе Дарьи Колесовой

◽️Познакомимся с техникой EventModeling для проектирования систем вместе с Анной Сретинской. Не путать с EventStorming

◽️Пощупаем ручками RabbitMQ и построим взаимодействия с его помощью под руководством Анны Вичуговой

◽️Роман Цирульников расскажет о базовых понятиях архитектуры сисем и предприятий, и чем это полезно для аналитика

◽️Виктор Семак поделиться опытом обеспечения Observability систем и полезными практическими рекомендациями

Программа максимально прикладная, никакой записи и доплаты за воркшопы нет - запрыгивайте, всех ждем.

12 сентября Miro будет лочить аккаунты из РФ и РБ. Вычислять обещают по IP. Говорят, и на платные, и набесплатные акки приходят письма с оповещением. Успейте забекапиться

https://habr.com/ru/news/836016/

#манагерское

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

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

Особенно опасно заливать людьми проблемы в новых командах. Ну и закон Брукса никто не отменял.

#архитектура
На митапе ЮMoney был огонь-доклад про моделирование архитектуры всего на графе.

Кратко идея:

Собрали доступную документацию (спеки, оргструктуру, процессы), распарсили ее в сущности и связи между ними: сервисы, продукты, команды - и положили все это в графовую базу.

Теперь при анализе зависимостей можно вбить запрос и на выходе получить граф связей между командами и сервисами. Например, какие команды могут затронуть доработки, если я решил запилить фичу МегаРеклама в продукте МногоДенег.

Выглядит как black fucking magic. Шли к этому 10 лет, но слона можно резать на части.

Тут Авито что-то интересное делает 20 июля, программа хороша. Пойдет кто вживую?

Ссыль

Что-то давно у нас стримов не было. Завтра с Глебом Шипиловым, тимлидом команды процессинга данных в Exness, погрузимся в дивный мир потоковых данных.

Говорить будем про Kafka и Flink, а если точнее:

• Чем отличются Event-Driven и Request-Response взаимодействия, и как их реализовать

• Как устроена архитектура Apache Kafka

• Как загружать данные в Kafka и выгружать из нее — без программирования

• Как работать с потоковыми данными при помощи SQL

⏰ Все случится 2 июля в 18:30 мск

🔗 Встречаемся в прямом эфире — приходите пообщаться и вопросов накидать.

Говорят, осталось меньше месяца до очередного ЛАФ. Кто не в курсе, это такой пионер лагерь для взрослых, где аналитики на природе рассказывают всякое друг другу.

Буду развивать тему "Как аналитику (не) выбрать технологию интеграции", в этот раз в формате воркшопа.
Спроектируем с участниками интеграционную архитектуру и попробуем унести с собой полезные выводы.

Все случится 13-14 июля в Москве в гостинице Sheraton Skypoint Luxe.

В прошрамме 40+ докладов, мастер-классов, дискуссий и деловых игр с упором на практику и интерактив.

А еще орги проводят у себя в канале конкурс, в котором можно выиграть скидки на билеты 15%, 10%, 5% или эксклюзивный мерч ЛАФ 2024.