#подслушано

Хорошо по процессу работать - не надо париться за сроки и результаты, просто сидишь и задачи клепаешь.

Я смотрю, среди около-аналитических конференций продолжает появляться новое и интересное.

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

Вот такие темы будут:
▪️Лидерство в IT
▪️Кросс-ролевые софт-скиллы
▪️Профессиональная самореализация
▪️Работа и карьера в разрезе полноты жизни
▪️Выход на новый уровень мышления
▪️Использование проф. инструментов в жизни

Сам не попаду из-за пересечения с кодфестом, но если будете в Петербурге, заходите:

🔗 Регаться тут
📆 26 мая, начало в 09:00
📍 Санкт-Петербург, Невский проспект, д.54

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

На выхах 15-16го проводим последний перед летними каникулами тренинг System Design. Основы проектирования архитектуры систем. Будем познавать балансировку, кеширование, CDN и прочие способы масштабирования.

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

Тренинг ведет Даша Колесова - участница моего рейтинга топ-1 по наглядности подачи технических материалов.

#манагерское
Еще одна классная метафора на тему 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",
"noscript": "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",
"noscript": "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
Как самостоятельный способ передачи требований - ужас ужасный.
Обычная реакция после прочтения: “Кулл стори, бро, но объясни нормально, что сделать нужно?”

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

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

#мышление