#манагерское
Еще одна классная метафора на тему KPI

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

Что общего в этих трагедиях? Страх наказания

Адекватная цель “посадить самолёт безопасно” подменяется ложной “избежать наказания за заход на второй круг”

Бесконечно люблю KPI:
• с точки зрения премирования
• с точки зрения системы
• а вот тут через теорию ограничений любят

Хорошо, что не самолеты строим.

В среду буду снова набрасывать на тему Аналитик vs Интеграция на митапе в Петербурге.

Приходите похоливарить и чаек попить.

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

Аргументация к этой мысли в этой статье.

#API
Год назад вышло RFC с предложением стандартизировать описание ошибок в HTTP, чтобы дополнить status codes.

Интересна мотивация:

HTTP status codes cannot always convey enough information about errors to be helpful. While humans using web browsers can often understand an HTML response content, non-human consumers of HTTP APIs have difficulty doing so.

Т.е. никто уже не стесняется говорить, что честное HTTP API нормально ложится на сайтики, но как еж на кактус натягивается на межсервисные взаимодействия.

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

Вот так это должно выглядеть:

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en

{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/msgs/abc",
"balance": 30,
"accounts": ["/account/12345",
"/account/67890"]
}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
Content-Language: en

{
"type": "https://example.net/validation-error",
"title": "Your request is not valid.",
"errors": [
{
"detail": "must be a positive integer",
"pointer": "#/age"
},
{
"detail": "must be 'green', 'red' or 'blue'",
"pointer": "#/profile/color"
}
]
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ссыль

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

Кратко идея:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#мышление

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

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

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

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

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

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

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

#мышление

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

https://youtu.be/7oIXcJo56rE

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