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

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

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

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

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

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

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

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

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

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

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

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

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

#мышление

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

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

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

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

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

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

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

#мышление

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

https://youtu.be/7oIXcJo56rE

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

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

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

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

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

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

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

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

GET /api/getClientInfo?clientId=123

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

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

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

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

Интересный, пусть и поверхностный рассказ, как делают реальные приложения на основе LLM.

https://youtu.be/sNwgkLniGqQ?si=bPOB88QLDL3HH2SS

Статья (нужен vpn) о ретраях и защите от дублирования транзакций из недр Airbnb. В том числе разбирают проблемы реализации идемпотентности, и почему это не просто ключик в запрос положить. В том числе, использование распределенных хранилищ.

Заодно вспомним историю Васи и его борьбе с идемпотентностью в Яндекс.Такси, тоже полезно

AI-продукты для разрабов пошли дальше всяких копайлотов. Replit предлагают вроде уже стандартную связку IDE + репа + AI-ассистент. А еще их агент по текстовому описанию пишет код, поднимает БД и разворачивает приложение. Все под ключ для ленивого разраба.

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

Ссыль: https://replit.com

Прошлогодний рассказ, как Сбер делает копайлота для юристов. Никакой магии, только эксперименты с RAG и пайплайнами + формирование базы знаний. Характерно, что для формирования базы знаний понадобилась ручная разметка базы знаний силами 30 юристов - обыватель без экспертизы в домене не подойдет.

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

Хозяйке на заметку:
- Про RAG совсем на бизнесовом
- Совсем кратко про построение боевых LLM-приложений

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

- Как закладывать надежность на старте проектирования

- Где искать надежность при взаимодействии сервисов

- Latency based Congestion Control - не буду это переводить

- Архитектурная ката для участников

Если соберетесь подключиться, то орги скидос подогнали - techlead_crew_7_BsrEcL

Не могу не репостнуть

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

Многобукв для тех, кто хочет окунуться в тему:

- Балансировка, и зачем это нужно
- Функции балансеров
- L7 / L4 балансеры и зоны применения
- Типовые топологии и способы масштабирования

P.S. Нашел перевод на русский

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

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

Народ устроил хакатон по разработке с помощью Replit AI, писал о нем недавно.

Впечатления авторов:

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

Но на более-менее больших и серьёзных проектах всё бесповоротно ломается. Выбрать технологии или язык – целая проблема.

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

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

Replit же скорее тратит нервные клетки разработчиков (и не только), а не облегчает их труд.

Интересно, Replit AI - это обертка вокруг популярных моделей без серьезного тюнинга, или просто сырая технология?

Выглядит, что для прототипов эффективнее использовать no/low code платформы, а Replit - это онлайн IDE с инфрой для деплоя и агентом для экспеиментов. Но это сегодня. А вот что будет с приходом рассуждающих LLM типа o1 и их потомков - увидим в следующих сериях.

Как правильно выбрать хранилище под задачу

Пытаюсь понять, как у людей (команды) в рамках одной активности одновременно уживаются понятия «заказчик» и «продукт».

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