Стачка
Это первая конференция осеннего сезона. Она впечатляет масштабностью мероприятия буквально с первых минут: вечером накануне ты приходишь за бейджиком и оказываешься свидетелем монтажа большого числа стендов. Для меня это стало отличной возможностью выйти за пределы круга знакомых аналитиков и познакомиться с представителями разных специальностей, ведь в повседневной работе редко удается выбраться из аналитической среды. Эта встреча помогла мне накопить интересный материал для собственной статистики, касающейся вопросов IT-мира в целом. Так что, если вам любопытно узнать, какие вопросы я задаю представителям ИТ-отрасли вне зависимости от их должностей, отметьтесь реакцией 😁. Достигнем отметки хотя бы в 10 таких знаков — поговорим подробнее!

Что касается моего собственного выступления, стоит сказать, что я впервые была на "сборной солянке", когда разные специальности встречаются на одной площадке. Такая разнородность имеет плюсы и минусы одновременно. Плюс заключается в возможности послушать доклады абсолютно разных направлений, будь то архитектура или управление проектами. Минус — градус сложности тем снижается, поскольку востребованными становились темы, понятные широкой аудитории. В результате я осознала, что моя роль — скорее отраслевого эксперта, чьи доклады наиболее интересны коллегам-аналитикам или архитекторам, тогда как другим специалистам мои рассказы могут показаться менее релевантными. Одним словом, главная характеристика Стачки — универсальность.

Flow

Это была отраслевая конференция, менее масштабная, но покорившая меня своей особой атмосферой. Если у вас накопились вопросы по специальности, то здесь легко удается оперативно познакомиться с людьми, которым можно задать интересующие вас вопросы. Мне особенно запомнился скрупулёзный подход организаторов ко всем деталям мероприятия: начиная от зон для обсуждений возле залов и заканчивая наличием гримёра прямо на площадке. Важнейший критерий оценки любой конференции — уровень выступлений, и тут он оказался безупречным. Общаясь с организатором, человеком глубоко погружённым в сферу ИТ, поняла, почему мероприятие получилось таким уютным и комфортным для участников: оно создано именно айтишниками для айтишников, где не соскучишься ни на официальных секциях, ни на развлекательной программе.
Главное слово, характеризующее для меня эту конференцию, — «уют».

Не могла не прислать. Что думаете: "совсем поехавшие" или "жиза"?

Хочу поговорить с вами об асинхронности. Разговор предстоит длинный, и прежде чем мы начнем, предлагаю четко разграничить 2 понятия: очередь и брокер.
Возможно, для большинства присутствующих мое предложение покажется странным, потому что всё и так понятно, зачем говорить очевидное...
Но многократно на собеседованиях кандидаты встают в тупик, когда я спрашиваю: очередь и брокер - это одно и то же? Цель такого вопроса не завалить человека, а понять, любит ли он свою профессию, чтобы вникать в вопросы чуть глубже, чем иногда требуется. Как относитесь к такой позиции? Расскажите в комментариях, по какому нестандартному принципу вы отличаете подходящего кандидата?

⛓️‍💥 Очередь

Очереди используются для хранения сообщений в порядке поступления и обработки их последовательно: первый пришел - первый вышел.

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

⛓️ Брокер сообщений

Брокеры сообщений обеспечивают передачу сообщений между различными приложениями или компонентами системы. Иными словами - транспорт и маршрутизатор.

Особенности
- Поддерживает модели "publish-subscribe" (pub/sub), позволяя множеству потребителей получать одно сообщение одновременно.
- Является частью асинхронного мира
- Работает на протоколах передачи сообщений (AMQP, MQTT и тд)

Недавно нашла вот такой полезный доклад о стоп-словах аналитика. Показался очень полезным, поэтому показываю вам

кто интересуется архитектурой ИИ, тому полезно будет узнать о митапе Сбера
16 декабря с 11.00

Приступим к асинхронности. Она, конечно же, скрывает много подводных камней, которые мы и начнем поднимать со дна :)
Асинхронные системы давно стали модным архитектурным выбором. «Поставим Rabbit/Kafka — и всё взлетит» звучит примерно как «перепишем на микросервисы — и станет быстрее» 😆😆😆.
На практике же асинхронность — это не инструмент, а архитектурное мировоззрение, которое меняет буквально всё: от того, как устроена модель данных, до того, как работает команда разработки и как взаимодействуют с системой пользователи.

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

🪝 Скрытая синхронность: RPC поверх брокера и его ловушки

Первая ошибка, в которую попадают команды: пытаясь уйти от синхронного REST, они переносят те же паттерны поверх брокера сообщений. Возникают решения вида RPC over MQ, где:
— сервис A кладёт сообщение в очередь
— сервис B обрабатывает его и отправляет ответ в «reply queue»
— сервис A продолжает выполнение после получения ответа
На бумаге — асинхронность. На практике — тот же синхронный вызов, только скрытый в очередях и callback’ах.
Чем это опасно?

1. А смысл?
Команда думает: «Мы же используем брокер, всё асинхронно». На деле — они не избавились от синхронности, а просто спрятали её глубже, добавив ещё больше точек отказа.

2. Хрупкость цепочки
Теперь между клиентом и исполнителем не один сетевой хоп, а два, три или четыре: публикация, маршрутизация, обработка, обратная публикация. Любой сбой превращает ответ в «висит, но непонятно где».

3. Возврат к блокирующей модели
Треды всё равно ждут ответа. В результате система одновременно не получает преимуществ асинхронности и тащит всю связанную сложность.

🗼Итог: RPC поверх брокера ломает саму идею асинхронной архитектуры, превращая её в более сложный вариант привычного синхронного вызова.

Merge Baltic

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

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

Теперь поговорим непосредственно о самом событии.

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

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

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

Если охарактеризовать конфу одним словом — это дух «small talk»: непринужденные беседы и диалоги, формирующие живую интеллектуальную среду для всех участников.

Переходим к следующему мифу.

⚓️ Когда eventual consistency — это не про данные, а про бизнес-процессы

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

Асинхронность часто связана с eventual consistency: данные рано или поздно синхронизируются. Это звучит безобидно — пока не проявляется в пользовательских сценариях...

Пример: заказ создан, но платёж «где-то едет»

Пусть пользователь оформляет заказ. Фронтенд получает успешный ответ: «Заказ создан». Через секунду он открывает историю заказов — а там заказа нет, потому что поток обработки платежей задержался, и сервис заказа пока не обновил статус.
Что думает пользователь?
«Сайт сломался, надо оформлять заново». Даже если бизнес-процесс формально корректен, пользователь все равно идет оформлять повторно.

Вот что стоит помнить:
🎲 Eventual consistency — это не только про репликацию данных.
Это про рассинхронизацию реальности и того, что видит пользователь!! Поэтому асинхронность вынуждает продумывать UX иначе.

🎲 Нужно объяснять пользователю, что происходит: «Платеж обрабатывается…». А это означает изменения интерфейса, API, состояния в БД, SLA на задержки.

🎲 Асинхронная архитектура = асинхронный бизнес.

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


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

Analyst Days
Финальная конференция сезона и знаковое событие в мире аналитики — AnalystDays. Давно мечтала посетить её лично, и вот, наконец, моя мечта сбылась именно в этот год!

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

Несмотря на масштаб, атмосфера остаётся дружелюбной и располагающей к нетворкингу. Можно легко найти собеседника по любой интересующей теме, включая идеи будущих докладов с программным комитетом.

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

Уже сейчас начинаю подготовку к новому сезону и активно собираю свежие мысли и идеи. Очень надеюсь на вашу помощь и поддержку: расскажите о направлениях, которые вам интересны.
Как вызнаете, я люблю практические кейсы и конкретные решения конкретных проблем, поэтому сухие мотивационные лекции вроде "как оставаться в ресурсе" меня ещё не зацепили. Если у вас есть интересные задачки, буду рада ознакомиться с вашими мыслями.

А у меня вышла статья про мифы REST. го читать!

Привет всем! 👋

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

Встречайте — Его Величество Цифровой Детокс. Что-то новое? Нет, конечно. Но мы, вечно спешащие и уставшие жители мегаполисов, его силу явно недооцениваем. Давайте я вас немного подтолкну в эту сторону. 😉

А для понимания масштаба катастрофы, расскажу, с чем я подошла к старту (работу в список не включаю — это и так понятно):

1. Шёл третий год материнства. На этом список можно было бы и закончить, но я продолжу.
2. Материнство — это четверть «беды». Активная мама — ещё четверть. Я таскала ребёнка везде с собой, а когда она подросла и заинтересовалась — мы ходим на все детские мероприятия города. Контроль над их количеством был безвозвратно утерян.
3. Летом ребёнок научился оставаться без меня больше суток, и тут Остапа понесло... Я так рьяно бросилась навёрстывать три года «упущенной свободы», что окружающих мой график начал пугать сразу, а меня — только к концу года. Сначала было 10 событий в квартал, потом — за два месяца, а в декабре я насчитала 17 мероприятий (из них 9 детских!),где требовалось моё участие и подготовка!. Семья шептала: «Остановись!», а съезжающая кукуха сыпала предложениями: «А давай ещё вот это придумаем!».
4. Еще четверть "беды" - это проекты, в которые я иногда вписываюсь просто потому что мне интересно. Это тоже время и затрачиваемая энергия, хоть и "по любви"
5. Кажется, четыре четверти — это уже целое, а значит пятого пункта уже быть не должно. Но я перевалила даже за него и добавила профессиональное развитие, в которое погрузилась с головой. Тянет на добрую треть, не меньше.

Итог: 1 целая и 1/3 «беды». Голова дымится, усталость накапливается, а концентрация — где-то потерялась и не хочет возвращаться.

Планируемое лечение

30 декабря, когда я закрыла рабочий ноутбук, в голове щёлкнуло: впереди не просто праздники. Впереди 12 дней, когда гарантированно отдыхают абсолютно все. А это волшебное окно, когда ни одна из моих «четвертей беды» не станет меня искать. Это ключевое отличие от обычного отпуска, когда что-то где-то случается и нужно «просто на минутку» подключиться, убивая весь эффект отдыха.

Решение созрело: полный цифровой детокс. Отрекаюсь от соцсетей, маркетплейсов и любых напрягающих контактов. Общение — только с самыми близкими. Телефон — только по делу.

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

Реализация замысла

Дни 1-3: Палец на автопилоте трижды тянулся к иконке соцсети и успевал тапнуть, прежде чем мозг протестовал. Я сразу выходила, так что не считается! 😅
Книги! Я и так читаю перед сном, но тут... 2 большие книги за 12 дней! (Разумеется, ребёнок был у бабушки — без этого чуда бы не случилось). Это было восхитительное погружение, как в доматеринские времена.
«Потом почитать»: В браузерах накопилась гигантская (штук 20, для меня это много!) коллекция вкладок, покрытых цифровой пылью. И знаете что? Я до них добралась. Просто потому, что больше не было, куда спешить.

Итог

1. Я счастлива. Без лишних слов.
2. Голова не просто очистилась — она замедлилась. С моим темпом жизни это ощущается как ледяной душ посреди жаркого дня. Невероятная ясность.
3. Исчезло «рваное внимание». Помню из курса по ОС, что переключение контекста для процессора часто дороже самой операции. Наш мозг — та же система. Когда его не дёргают каждые пять минут, он начинает работать качественнее.

Что теперь (или главный инсайт)

Вернувшись в рабочие будни, я не почувствовала того привычного ужаса перед шквалом задач. Дело в другом: я теперь внимательнее отношусь к тому, что именно беру в голову. Прежде чем вписать новую активность в график, я на секунду задумываюсь: «А какой урон это нанесёт тому хрупкому спокойствию, которое сейчас царит у меня внутри?». И это, пожалуй, самый ценный вывод из всего эксперимента.

Что хочу порекомендовать

1. Если в отпуске есть возможность отключить телефон или соцсети — сделайте это! Рука тянется только первые три дня. Перетерпите, и уже через неделю вы себе скажете спасибо.
2. Даже если возможности нет — зафиксируйте в памяти это состояние «обнуления» после отдыха. Когда на вас обрушится шквал задач по возвращении, это чувство поможет продлить эффект отдохнувшей головы.
3. Замедляйтесь. Искусственно, нарочно, по принуждению. Просто попробуйте. У меня на этот счёт ещё много мыслей, но об этом — в следующих сериях. Не переключайтесь! 😉

А вы практикуете цифровой детокс? Или, может, боитесь даже попробовать?