Полезняшка выходного дня 🧠⌨️
Нашла (и уже активно пользуюсь) штуку, которая внезапно сильно упростила жизнь — приложение с AI по горячим клавишам, которое работает прямо поверх любых программ.
Без переключений между окнами. Без «ой, тут нет встроенного AI». Вызвал хоткей → применил свой привычный промпт → получил результат.
Где мне зашло больше всего:
— переводы в Slack и Telegram (греческий, привет 🇬🇷)
— быстрые форматирования текста в Confluence
— работа с определениями и формулировками (да, тот самый промт под определения)
— любые повторяющиеся промпты (написать, переписать, структурировать)
Фактически это AI как системная функция, а не как отдельный чат.
Отдельное ❤️ — потому что сделал это человек, с которым мы когда-то вместе работали в Яндексе. Миша Степанов сейчас живет в Эстонии и уже много лет учит маленьких роботов кататься, а параллельно пилит такие удобные тулзы.
Не реклама — реально пользуюсь и кайфую.
Если вы, как и я, уже не представляете рабочий день без своих промптов — очень советую попробовать:
🔗 https://www.producthunt.com/products/ai-hotkeys
И да — мир бывших яндексоидов все еще регулярно поставляет что-то очень классное 🙂
А вот линк Миши, если хотите к нему с ОС или посмотреть что он еще придумал!
Нашла (и уже активно пользуюсь) штуку, которая внезапно сильно упростила жизнь — приложение с AI по горячим клавишам, которое работает прямо поверх любых программ.
Без переключений между окнами. Без «ой, тут нет встроенного AI». Вызвал хоткей → применил свой привычный промпт → получил результат.
Где мне зашло больше всего:
— переводы в Slack и Telegram (греческий, привет 🇬🇷)
— быстрые форматирования текста в Confluence
— работа с определениями и формулировками (да, тот самый промт под определения)
— любые повторяющиеся промпты (написать, переписать, структурировать)
Фактически это AI как системная функция, а не как отдельный чат.
Отдельное ❤️ — потому что сделал это человек, с которым мы когда-то вместе работали в Яндексе. Миша Степанов сейчас живет в Эстонии и уже много лет учит маленьких роботов кататься, а параллельно пилит такие удобные тулзы.
Не реклама — реально пользуюсь и кайфую.
Если вы, как и я, уже не представляете рабочий день без своих промптов — очень советую попробовать:
🔗 https://www.producthunt.com/products/ai-hotkeys
И да — мир бывших яндексоидов все еще регулярно поставляет что-то очень классное 🙂
А вот линк Миши, если хотите к нему с ОС или посмотреть что он еще придумал!
Product Hunt
AI Hotkeys: Use a hotkey to quickly summon ChatGPT | Product Hunt
You Cmd+Tab to ChatGPT 50 times a day. Paste text in, wait, copy result back. AI Shortcuts kills that loop: select text, press a hotkey, get the result right where you are. Translate, rewrite, summarize - or run any custom prompt.
👍4❤3🔥2
Аргументы против мультиков!
Продолжем тему прошлой недели. Когда предлагаешь разрешить мультики, почти сразу слышишь набор аргументов «почему так нельзя».
Вот самые частые — и что с ними делать, если вы все-таки хотите жить «честно»!
🚓 «Это фрод»
Мультиаккаунт ≠ мошенничество. Фрод — это поведение.
Решение: считать риск на уровне человека, а не аккаунта.
Мультик — сигнал. Фрод — вывод.
💸 «Лимиты разъедутся»
Разъедутся, если они считаются на аккаунт! Это архитектурная задача, а не запретительная.
Решение:
— лимиты на сущность человека
— явная агрегация
— разделение продуктовых и юридических ограничений
🤔 «Антифрод и AML не поймут»
Не поймут, если вы скрываете логику/связи/сущности.
Решение:
— хранить связь аккаунтов явно
— строить профиль риска на человека
— не делать вид, что это независимые сущности
😓 «Слоооожнааа и дорого»
На старте — сложнее.
Но модель «один аккаунт = один человек» плохо масштабируется.
Решение с контролем почти всегда выигрывает в долгую.
🚫 «Регулятор не разрешит»
Регулятору важно:
— кто человек
— как считаются лимиты
— есть ли аудит
Решение: разделите домены, очистите сущности и сдавайте регулятору то, что он хочет и как написано в документах, а не то, как прочитали.
Если принять, что мультики:
— неизбежны
— легитимны
— будут всегда
вопрос меняется.
Не «как запретить?», а «как безопасно с этим жить?».
И это уже честная архитектура, а если порыться на просторах интернета или взять консультации, то выяснится, что еще и практически все проблемы уже решены и они не проблемы, а паттерны!
💬 А вы какие «против» встречали или почему «против» сами?
Продолжем тему прошлой недели. Когда предлагаешь разрешить мультики, почти сразу слышишь набор аргументов «почему так нельзя».
Вот самые частые — и что с ними делать, если вы все-таки хотите жить «честно»!
🚓 «Это фрод»
Мультиаккаунт ≠ мошенничество. Фрод — это поведение.
Решение: считать риск на уровне человека, а не аккаунта.
Мультик — сигнал. Фрод — вывод.
💸 «Лимиты разъедутся»
Разъедутся, если они считаются на аккаунт! Это архитектурная задача, а не запретительная.
Решение:
— лимиты на сущность человека
— явная агрегация
— разделение продуктовых и юридических ограничений
🤔 «Антифрод и AML не поймут»
Не поймут, если вы скрываете логику/связи/сущности.
Решение:
— хранить связь аккаунтов явно
— строить профиль риска на человека
— не делать вид, что это независимые сущности
😓 «Слоооожнааа и дорого»
На старте — сложнее.
Но модель «один аккаунт = один человек» плохо масштабируется.
Решение с контролем почти всегда выигрывает в долгую.
🚫 «Регулятор не разрешит»
Регулятору важно:
— кто человек
— как считаются лимиты
— есть ли аудит
Решение: разделите домены, очистите сущности и сдавайте регулятору то, что он хочет и как написано в документах, а не то, как прочитали.
Если принять, что мультики:
— неизбежны
— легитимны
— будут всегда
вопрос меняется.
Не «как запретить?», а «как безопасно с этим жить?».
И это уже честная архитектура, а если порыться на просторах интернета или взять консультации, то выяснится, что еще и практически все проблемы уже решены и они не проблемы, а паттерны!
💬 А вы какие «против» встречали или почему «против» сами?
Telegram
ITKatya: культурные паттерны в IT
Мультиаккаунтинг — за и против.
Тема, вокруг которой обычно сразу начинается спор!
Мультиаккаунтинг — это когда один и тот же человек легитимно или фактически имеет несколько аккаунтов в одной системе.
Самый банальный пример — аккаунты Google.
Личный.…
Тема, вокруг которой обычно сразу начинается спор!
Мультиаккаунтинг — это когда один и тот же человек легитимно или фактически имеет несколько аккаунтов в одной системе.
Самый банальный пример — аккаунты Google.
Личный.…
👍6❤1
Завтра позвали на прямой эфир!
Присоединяйтесь! Давно не говорили «словами через рот»!
Присоединяйтесь! Давно не говорили «словами через рот»!
🔥2
Forwarded from Эмоции успеха | Елена Логачева
26 февраля, 18:00 ч. (мск)
Приглашаю вас на новый эфир:
«Когда коммуникации решают: эффективность команд в эпоху ИИ»
Сегодня AI-инструменты становятся умнее, а скорости — выше. Но эффективность команд по-прежнему ломается не в коде, а в коммуникациях. И об этом крайне важно говорить!
У меня в гостях:
Обсудим:
Эфир уже завтра — значит, самое время пройти РЕГИСТРАЦИЮ, чтобы получить свою ссылку на участие в zoom-встрече.
«Эмоции успеха» | Елена Логачева
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6❤2👍1
Новый рекорд или пробила дно! 🕳
На днях я, кажется, либо пробила дно, либо поставила личный рекорд.
⚠️15 встреч за 10 часов.⚠️
И это были не те созвоны, где можно тихо «присутствовать» фоном.
Каждая — с включенной головой, с решениями, с ответственностью.
Пятнадцать переключений контекста подряд.
Я не уверена, что такая акробатика вообще совместима с понятием «результативность».
Потому что после какого-то N-го переключения мозг уже не работает в режиме deep, он работает в режиме «следующая вкладка».
И ровно в этот момент мне попадается письмо Маска про:
— убирайте большие встречи
— убирайте частые встречи
— уходите, если не добавляете ценности
— общайтесь напрямую
— руководствуйтесь здравым смыслом
И самое ироничное — часть моих текущих правил хождения на встречи с этим почти совпадает.
Если хотите — отдельно расскажу.
Но есть нюанс.
В больших нетехнологических компаниях (где продукт в "реальной" сфере, а не космические технологи и тп) почти всегда огромный разрыв между бизнесом и разработкой даже на уровне понимания продукта (и это нормально).
Чтобы команда могла работать и не жила в календаре, менеджерский слой ходит на встречи вместо нее — собирает контекст, договаривается, снимает зависимости!
Поэтому иногда 15 встреч — это не про неэффективность, а про попытку защитить фокус команды.
Но вопрос остается:
— мы синхронизируемся
— или уничтожаем друг другу рабочий день?
💬 Какой у вас был самый безумный рекорд по встречам за день — и зачем?
И да — сегодня будет прямой эфир, где в том числе поговорим про эффективность и коммуникации в реальной календарной жизни.
😂 👍 👍 ❤️ 👌 😅 😊 😊 😍 😘
26 февраля, 18:00 ч. (мск)
Регистрация тут
На днях я, кажется, либо пробила дно, либо поставила личный рекорд.
⚠️15 встреч за 10 часов.⚠️
И это были не те созвоны, где можно тихо «присутствовать» фоном.
Каждая — с включенной головой, с решениями, с ответственностью.
Пятнадцать переключений контекста подряд.
Я не уверена, что такая акробатика вообще совместима с понятием «результативность».
Потому что после какого-то N-го переключения мозг уже не работает в режиме deep, он работает в режиме «следующая вкладка».
И ровно в этот момент мне попадается письмо Маска про:
— убирайте большие встречи
— убирайте частые встречи
— уходите, если не добавляете ценности
— общайтесь напрямую
— руководствуйтесь здравым смыслом
И самое ироничное — часть моих текущих правил хождения на встречи с этим почти совпадает.
Если хотите — отдельно расскажу.
Но есть нюанс.
В больших нетехнологических компаниях (где продукт в "реальной" сфере, а не космические технологи и тп) почти всегда огромный разрыв между бизнесом и разработкой даже на уровне понимания продукта (и это нормально).
Чтобы команда могла работать и не жила в календаре, менеджерский слой ходит на встречи вместо нее — собирает контекст, договаривается, снимает зависимости!
Поэтому иногда 15 встреч — это не про неэффективность, а про попытку защитить фокус команды.
Но вопрос остается:
— мы синхронизируемся
— или уничтожаем друг другу рабочий день?
💬 Какой у вас был самый безумный рекорд по встречам за день — и зачем?
И да — сегодня будет прямой эфир, где в том числе поговорим про эффективность и коммуникации в реальной календарной жизни.
26 февраля, 18:00 ч. (мск)
Регистрация тут
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9❤3
Помощь тем, кто хо стать спикером! 🤍
Каждый раз, когда я готовлюсь к конференции, во мне просыпается один и тот же человек. Маленький, противный, очень убедительный! Он садится рядом и начинает тихо спрашивать...
И самое забавное — это никак не зависит от количества выступлений, текстов, проектов, менторинга и всего остального. Можно сколько угодно раз выходить на сцену, регулярно консультировать компании и людей, можно получать хорошие отзывы — этот внутренний диалог все равно запускается по кругу.
Иногда это похоже на идиотские вопросы. Иногда — на очень честные и очень болезненные.
И я вдруг поняла, что пишу этот пост не потому, что нашла универсальный способ это починить.
Но я знаю одну важную вещь. Я знаю людей, которых сама считаю невероятными спикерами — и они проживают ровно то же самое. Каждый год. Перед каждым докладом. Это не исчезает. Это просто становится частью процесса.
Поэтому если вы в этом году думаете:
— то вот вам честный ответ изнутри: да, будет страшно. И это нормально. Бояться — нормально. Быть неуверенным — нормально. Даже хотеть все бросить — тоже нормально.
И при этом именно живые люди, с реальными кейсами и настоящими объяснениями, — это самое ценное, что у нас есть. Не идеальные презентации. Не вылизанные тексты. А возможность прийти к кому-то, кто разбирается, задать точный вопрос и услышать живой ответ. Унести с собой мысль, которой у тебя не было, и побежать дальше работать. Никакой AI пока не заменяет это ощущение.
Поэтому если вам нужна поддержка — приходите. Правда. Я готова помогать с темами, со структурой, с первыми шагами — просто потому, что спикеров должно становиться больше. Новых. Разных. Своих.
И Паша Гертман @zarazum , кстати, тоже сейчас этим занимается — помогает готовить выступления.
А еще мне очень хочется сделать из этого не мой монолог, а что-то большее. Если вы тоже готовы помогать начинающим — со статьями, с докладами, с блогами, с подачами — напишите об этом в комментариях. Давайте соберем живой список людей, к которым можно прийти за поддержкой.
Потому что чем шире этот круг — тем больше в нем света.
И тем меньше каждый из нас остается наедине со своим внутренним самозванцем! 💛
Каждый раз, когда я готовлюсь к конференции, во мне просыпается один и тот же человек. Маленький, противный, очень убедительный! Он садится рядом и начинает тихо спрашивать...
а это кому-нибудь вообще нужно?
а ты точно не капитан очевидность?
а вдруг ты сейчас выйдешь и будешь рассказывать какую-то странную, никому не понятную штуку?
а может, вообще не надо?
И самое забавное — это никак не зависит от количества выступлений, текстов, проектов, менторинга и всего остального. Можно сколько угодно раз выходить на сцену, регулярно консультировать компании и людей, можно получать хорошие отзывы — этот внутренний диалог все равно запускается по кругу.
Иногда это похоже на идиотские вопросы. Иногда — на очень честные и очень болезненные.
И я вдруг поняла, что пишу этот пост не потому, что нашла универсальный способ это починить.
Но я знаю одну важную вещь. Я знаю людей, которых сама считаю невероятными спикерами — и они проживают ровно то же самое. Каждый год. Перед каждым докладом. Это не исчезает. Это просто становится частью процесса.
Поэтому если вы в этом году думаете:
«а не начать ли мне выступать»,
«а не написать ли первый пост»,
«а не податься ли на конференцию»
— то вот вам честный ответ изнутри: да, будет страшно. И это нормально. Бояться — нормально. Быть неуверенным — нормально. Даже хотеть все бросить — тоже нормально.
И при этом именно живые люди, с реальными кейсами и настоящими объяснениями, — это самое ценное, что у нас есть. Не идеальные презентации. Не вылизанные тексты. А возможность прийти к кому-то, кто разбирается, задать точный вопрос и услышать живой ответ. Унести с собой мысль, которой у тебя не было, и побежать дальше работать. Никакой AI пока не заменяет это ощущение.
Поэтому если вам нужна поддержка — приходите. Правда. Я готова помогать с темами, со структурой, с первыми шагами — просто потому, что спикеров должно становиться больше. Новых. Разных. Своих.
И Паша Гертман @zarazum , кстати, тоже сейчас этим занимается — помогает готовить выступления.
А еще мне очень хочется сделать из этого не мой монолог, а что-то большее. Если вы тоже готовы помогать начинающим — со статьями, с докладами, с блогами, с подачами — напишите об этом в комментариях. Давайте соберем живой список людей, к которым можно прийти за поддержкой.
Потому что чем шире этот круг — тем больше в нем света.
И тем меньше каждый из нас остается наедине со своим внутренним самозванцем! 💛
Please open Telegram to view this post
VIEW IN TELEGRAM
❤14
Не очень сложное, но пугающее с выходных (и я не про политические конфликты) 😱
Я видела много. Очень много. Разные формулировки, странные процессы, вакансии «и швец, и жнец», компании с культом переработок и стартапы с зарплатой «зато идея».
Но такую вакансию — впервые.
Я сейчас даже не про вилку, не про формат оформления и не про «ненормированный рабочий день». Меня искренне интересует другой продуктовый артефакт.
Мудборд в Pinterest.
Серьезно?
И только после этого с тобой готовы поговорить.
Я пытаюсь понять продуктовую гипотезу этого решения.
Если цель —
👉 отсеять людей, которые не готовы тратить несколько часов жизни в никуда — окей, это честный фильтр.
Тут логика есть.
Но если это попытка
— оценить продакт-мышление
— понять культурный фит
— привлечь сильных кандидатов
— или, прости господи, увидеть «вайб»
…то у меня не сходится модель.
Потому что все, что там действительно проверяет профессию, — лежит в относительно нормальном кейсе в Notion.
А Pinterest — это что?
Отдельно меня восхищает формулировка:
То есть воронка найма начинается с многочасового неоплачиваемого задания без какого-либо контакта с компанией.
Ребята, я правда пытаюсь понять.
Это:
🟡 новые реалии российского рынка
🟡 специфика конкретного стартапа
🟡 способ найти very specific type of people
🟡 или просто случайный артефакт, который вывалился в ленту
Потому что пока моя единственная продуктовая интерпретация звучит так:
И вот это уже честная ценностная гипотеза 🙂
💬 Что думаете?
Я видела много. Очень много. Разные формулировки, странные процессы, вакансии «и швец, и жнец», компании с культом переработок и стартапы с зарплатой «зато идея».
Но такую вакансию — впервые.
Я сейчас даже не про вилку, не про формат оформления и не про «ненормированный рабочий день». Меня искренне интересует другой продуктовый артефакт.
Мудборд в Pinterest.
Серьезно?
Сделай доску с тем, что тебе нравится.
Сделай доску с тем, что тебе не нравится.
И только после этого с тобой готовы поговорить.
Я пытаюсь понять продуктовую гипотезу этого решения.
Если цель —
👉 отсеять людей, которые не готовы тратить несколько часов жизни в никуда — окей, это честный фильтр.
Тут логика есть.
Но если это попытка
— оценить продакт-мышление
— понять культурный фит
— привлечь сильных кандидатов
— или, прости господи, увидеть «вайб»
…то у меня не сходится модель.
Потому что все, что там действительно проверяет профессию, — лежит в относительно нормальном кейсе в Notion.
А Pinterest — это что?
Отдельно меня восхищает формулировка:
заявки без артефактов будут удаляться без рассмотрения.
То есть воронка найма начинается с многочасового неоплачиваемого задания без какого-либо контакта с компанией.
Ребята, я правда пытаюсь понять.
Это:
🟡 новые реалии российского рынка
🟡 специфика конкретного стартапа
🟡 способ найти very specific type of people
🟡 или просто случайный артефакт, который вывалился в ленту
Потому что пока моя единственная продуктовая интерпретация звучит так:
«Мы ищем не продакта.
Мы ищем человека, которому норм».
И вот это уже честная ценностная гипотеза 🙂
💬 Что думаете?
😁6🤔2🤡2
Большой материал про ОНБОРДИНГ! 👋
В свете последних постов и прямого эфира, поделюсь циклом материалов про онбординг, которые вышли Хабре! Финальная часть - только вчера (02/03/2026)!
Это три части одной большой статьи, которая выросла из моего мастер-класса (того самого, что попал в шорт-лист лучших на DevOpsConf), а потом мы еще серьезно перерабатывали и сокращали текст вдвое, чтоб хоть 3 части, а не 6 получить!
Внутри материала:
— как выстраивать системный онбординг,
— где ломаются процессы,
— почему «выйти на работу» ≠ «встроиться в команду»,
— и что с этим делать на уровне продукта и культуры.
вот весь цикл:
Часть 1:
https://habr.com/ru/companies/oleg-bunin/articles/987298/
Часть 2:
https://habr.com/ru/companies/oleg-bunin/articles/987308/
Часть 3:
https://habr.com/ru/companies/oleg-bunin/articles/987314/
Это не пересказ МК, а полноценный разбор с логикой, структурой и акцентами, которые обычно не помещаются в тайминг конференции.
💬 Будете читать — напишите потом, как вам. Так как это мой первый опыт переделки материалов МК в текст! Можно в комментариях на Хабре или мне в личку.
В свете последних постов и прямого эфира, поделюсь циклом материалов про онбординг, которые вышли Хабре! Финальная часть - только вчера (02/03/2026)!
Это три части одной большой статьи, которая выросла из моего мастер-класса (того самого, что попал в шорт-лист лучших на DevOpsConf), а потом мы еще серьезно перерабатывали и сокращали текст вдвое, чтоб хоть 3 части, а не 6 получить!
Внутри материала:
— как выстраивать системный онбординг,
— где ломаются процессы,
— почему «выйти на работу» ≠ «встроиться в команду»,
— и что с этим делать на уровне продукта и культуры.
вот весь цикл:
Часть 1:
https://habr.com/ru/companies/oleg-bunin/articles/987298/
Часть 2:
https://habr.com/ru/companies/oleg-bunin/articles/987308/
Часть 3:
https://habr.com/ru/companies/oleg-bunin/articles/987314/
Это не пересказ МК, а полноценный разбор с логикой, структурой и акцентами, которые обычно не помещаются в тайминг конференции.
💬 Будете читать — напишите потом, как вам. Так как это мой первый опыт переделки материалов МК в текст! Можно в комментариях на Хабре или мне в личку.
Хабр
Полгода на включение: как мы построили онбординг в команде не по инструкции. Часть 1: от хаоса до осмысленной системы
Возможно, я проклята. Иначе как объяснить, что снова и снова мне приходится собирать команды? Интервью — привычная часть моей работы, даже если прямо сейчас своей команды нет. Такая уж роль —...
❤9❤🔥5👍2🔥2
Раз уж неделя у меня пошла по линии «археология собственного прошлого», держите еще один артефакт.
Прекрасная Аня Афонина принесла запись моего доклада с летнего ProIT Fest V.
Это тот самый доклад в формате почти стендапа — для тех, кто хотя бы раз «нюхал» процессинг и понимает, почему некоторые вещи в финтехе одновременно смешные и трагические.
YouTube: https://youtu.be/mTgxAY_bja0?si=xUItSK9CPcBmudMM
VK: https://vkvideo.ru/video-214863425_456239162
К интеллектуальному контенту вернемся уже на следующей неделе.
А пока можно просто полюбоваться на меня прекрасную🙂
Прекрасная Аня Афонина принесла запись моего доклада с летнего ProIT Fest V.
Это тот самый доклад в формате почти стендапа — для тех, кто хотя бы раз «нюхал» процессинг и понимает, почему некоторые вещи в финтехе одновременно смешные и трагические.
YouTube: https://youtu.be/mTgxAY_bja0?si=xUItSK9CPcBmudMM
VK: https://vkvideo.ru/video-214863425_456239162
К интеллектуальному контенту вернемся уже на следующей неделе.
А пока можно просто полюбоваться на меня прекрасную
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
ProIT Fest V: Екатерина Лысенко - Бескультурные паттерны ФинТеха...
Проектирование в финтехе — это как Groundhog Day: все по правилам, но результат снова «мимо». Вместе пройдем поэтапно путь создания ядра любого финтех-продукта — процессинга.
Будем проектировать, выбирать архитектуру, отвечать на «невинные» вопросы бизнеса…
Будем проектировать, выбирать архитектуру, отвечать на «невинные» вопросы бизнеса…
❤8😁2
Иногда большие технологические прорывы происходят не в лабораториях.
А потому что одна женщина просто садится и едет.
В 1888 году Bertha Benz без ведома мужа взяла автомобиль, который изобрел Karl Benz, посадила в него двух сыновей и отправилась навестить свою маму.
Сегодня это звучит как обычная семейная поездка.
Но есть одна деталь:
это был первый автомобиль в мире — Benz Patent-Motorwagen.
Она проехала около 106 километров по маршруту из Mannheim в Pforzheim.
По дороге:
• покупала топливо в аптеке (так появилась первая в истории «заправка»),
• прочищала топливную систему шпилькой для шляпы,
• изолировала провод подвязкой,
• а тормоза ей помог усилить местный сапожник.
Эта поездка стала первой демонстрацией того, что автомобиль — это не эксперимент, а реальный транспорт.
Сегодня этот маршрут официально признан памятником технической истории Германии и известен как Bertha Benz Memorial Route.
И мне кажется, в этом есть очень важный символ 8 марта.
В истории технологий мы часто помним имена изобретателей.
Но рядом с ними были женщины, которые: поддерживали, верили, проверяли идеи на практике и иногда просто брали и делали, когда остальные сомневались.
Иногда именно это и превращает изобретение — в реальность.
И маленькая деталь — про матерей и силу любви.
Фильм, который напоминает, что любовь и вера преодолевает любые препятствия, даже те, которые не способна преодолеть физика:
Обещание на рассвете.
История о том, как далеко может зайти человек, если рядом есть кто-то, кто в него верит.
С Международным женским днем. 🌷
Пусть у нас всегда будет смелость садиться и ехать первыми. А если вы захотите поддерживать и любить, пусть это ценят!
А потому что одна женщина просто садится и едет.
В 1888 году Bertha Benz без ведома мужа взяла автомобиль, который изобрел Karl Benz, посадила в него двух сыновей и отправилась навестить свою маму.
Сегодня это звучит как обычная семейная поездка.
Но есть одна деталь:
это был первый автомобиль в мире — Benz Patent-Motorwagen.
Она проехала около 106 километров по маршруту из Mannheim в Pforzheim.
По дороге:
• покупала топливо в аптеке (так появилась первая в истории «заправка»),
• прочищала топливную систему шпилькой для шляпы,
• изолировала провод подвязкой,
• а тормоза ей помог усилить местный сапожник.
Эта поездка стала первой демонстрацией того, что автомобиль — это не эксперимент, а реальный транспорт.
Сегодня этот маршрут официально признан памятником технической истории Германии и известен как Bertha Benz Memorial Route.
И мне кажется, в этом есть очень важный символ 8 марта.
В истории технологий мы часто помним имена изобретателей.
Но рядом с ними были женщины, которые: поддерживали, верили, проверяли идеи на практике и иногда просто брали и делали, когда остальные сомневались.
Иногда именно это и превращает изобретение — в реальность.
И маленькая деталь — про матерей и силу любви.
Фильм, который напоминает, что любовь и вера преодолевает любые препятствия, даже те, которые не способна преодолеть физика:
Обещание на рассвете.
История о том, как далеко может зайти человек, если рядом есть кто-то, кто в него верит.
С Международным женским днем. 🌷
Пусть у нас всегда будет смелость садиться и ехать первыми. А если вы захотите поддерживать и любить, пусть это ценят!
❤24🔥4👍2
Полезняшка про AI 🤖
На днях LinkedIn порекомендовал мне — Евгения Брензовича. И я быстро провалилась в его посты про AI и особенно один про целую образовательную платформу. Вначале решила что это платный хайп: «5 видео и вы все знаете», но на деле!
Женя создал большой, структурированный ресурс про AI-агентов, который, на мой взгляд, лучше воспринимать не как курс, а как базу знаний.
Тут собрана очень большая и аккуратно разложенная по темам информация:
— что такое AI-агенты и как они устроены
— как с ними работать и экспериментировать
— подборки материалов и статей (многие переведены)
— практические инструкции и разборы
— инфраструктурные вещи, включая то, где и как поднимать сервера
По сути, это end-to-end учебник, который объясняет не только теорию, но и то, как реально начать что-то делать руками.
Это не реклама!!! Я сама написала Жене и предложила рассказать про этот ресурс, потому что, на мой взгляд, он проделал действительно большую работу, которая может быть полезна многим!
Важно: ресурс полностью бесплатный.
Ссылки оставлю ниже:
Учебник: https://ai.arckep.ru/
Канал Жени в Tg: https://t.me/brenzovich_ai
На днях LinkedIn порекомендовал мне — Евгения Брензовича. И я быстро провалилась в его посты про AI и особенно один про целую образовательную платформу. Вначале решила что это платный хайп: «5 видео и вы все знаете», но на деле!
Женя создал большой, структурированный ресурс про AI-агентов, который, на мой взгляд, лучше воспринимать не как курс, а как базу знаний.
Тут собрана очень большая и аккуратно разложенная по темам информация:
— что такое AI-агенты и как они устроены
— как с ними работать и экспериментировать
— подборки материалов и статей (многие переведены)
— практические инструкции и разборы
— инфраструктурные вещи, включая то, где и как поднимать сервера
По сути, это end-to-end учебник, который объясняет не только теорию, но и то, как реально начать что-то делать руками.
Это не реклама!!! Я сама написала Жене и предложила рассказать про этот ресурс, потому что, на мой взгляд, он проделал действительно большую работу, которая может быть полезна многим!
Важно: ресурс полностью бесплатный.
Ссылки оставлю ниже:
Учебник: https://ai.arckep.ru/
Канал Жени в Tg: https://t.me/brenzovich_ai
Telegram
Evgenii Brenzovich
Рабочие заметки.
- arckep.ru
- naidiyogu.ru
И тд
Пишу когда есть что записать.
- arckep.ru
- naidiyogu.ru
И тд
Пишу когда есть что записать.
🔥10❤5👍3
Я наконец-то понимаю зачем мне Miro 🤣
В пятницу у нас на работе хакатон. И одна из тем — AI-инструменты внутри компании.
И я поймала себя на мысли, что сейчас вокруг AI есть два параллельных мира.
1️⃣ Первый — маркетинговый.
Когда в продукт просто добавляют слово AI, потому что так легче продавать.
2️⃣ А второй — когда AI действительно начинает менять рабочие инструменты.
И на днях я внезапно поняла, как пользоваться Miro!
Я работаю с ним давно — доски, воркшопы, стратегические сессии, брейнштормы.
Но то, что они начали добавлять AI прямо в рабочий процесс — оказалось реально полезно.
Что сейчас умеет AI в Miro:
1️⃣ Генерировать идеи
Можно задать тему — и Miro создает набор стикеров для брейншторма.
2️⃣ Разбирать хаос после мозгового штурма
AI автоматически кластеризует стикеры по темам или ключевым словам.
3️⃣ Делать саммари обсуждений
Можно выделить группу стикеров — и AI сделает краткое резюме идей и ключевых тем.
4️⃣ Строить диаграммы и схемы
Достаточно описать процесс текстом — Miro может сгенерировать flowchart или mind-map.
5️⃣ Превращать хаос в структуру
AI может преобразовать набор заметок в документ, план или таблицу.
6️⃣ Прототипировать UI
К сожалению, пока не попробовала, так как не включен add-on. Но, надеюсь, что в ближайшее время смогу и тут потыкаться!
📌И вот что для меня оказалось самым ценным.
После любого воркшопа в Miro обычно остается стена из стикеров.
Красиво, но дальше начинается ручная работа.
AI впервые реально помогает быстро превратить этот хаос в структуру.
И, да, мы на хакатон тащим AI-инструмент! Уже после хакатона, расскажу, чем закончилось!
💬 А вы уже "потыкали" AI Miro? И как вам?
В пятницу у нас на работе хакатон. И одна из тем — AI-инструменты внутри компании.
И я поймала себя на мысли, что сейчас вокруг AI есть два параллельных мира.
1️⃣ Первый — маркетинговый.
Когда в продукт просто добавляют слово AI, потому что так легче продавать.
2️⃣ А второй — когда AI действительно начинает менять рабочие инструменты.
И на днях я внезапно поняла, как пользоваться Miro!
Я работаю с ним давно — доски, воркшопы, стратегические сессии, брейнштормы.
Но то, что они начали добавлять AI прямо в рабочий процесс — оказалось реально полезно.
Что сейчас умеет AI в Miro:
1️⃣ Генерировать идеи
Можно задать тему — и Miro создает набор стикеров для брейншторма.
2️⃣ Разбирать хаос после мозгового штурма
AI автоматически кластеризует стикеры по темам или ключевым словам.
3️⃣ Делать саммари обсуждений
Можно выделить группу стикеров — и AI сделает краткое резюме идей и ключевых тем.
4️⃣ Строить диаграммы и схемы
Достаточно описать процесс текстом — Miro может сгенерировать flowchart или mind-map.
5️⃣ Превращать хаос в структуру
AI может преобразовать набор заметок в документ, план или таблицу.
6️⃣ Прототипировать UI
К сожалению, пока не попробовала, так как не включен add-on. Но, надеюсь, что в ближайшее время смогу и тут потыкаться!
📌И вот что для меня оказалось самым ценным.
После любого воркшопа в Miro обычно остается стена из стикеров.
Красиво, но дальше начинается ручная работа.
AI впервые реально помогает быстро превратить этот хаос в структуру.
И, да, мы на хакатон тащим AI-инструмент! Уже после хакатона, расскажу, чем закончилось!
💬 А вы уже "потыкали" AI Miro? И как вам?
Miro
AI Platform for Teams | The Innovation Workspace | Miro
Transform teamwork with Miro's AI platform built for teams. See how our innovation workspace understands context, accelerates collaboration, and drives real outcomes fast.
🔥12👍2
Бухгалтерская "полторашка" 🍷
Вернемся к финтеху...
В классическом учете действует двойная запись: дебет одного счета = кредит другого счета.
А вот термин полуторная запись я услышала недавно — оказалось, что сам паттерн я использую давно, просто не называла его так 🙂
В прикладном банковском смысле под ней обычно понимают ситуацию, когда:
Простой пример: выдана гарантия клиенту.
Денежные средства в момент выдачи не движутся, но обязательство банка возникает.
Поэтому сумма отражается на внебалансовых счетах — внутри них запись двойная, но на баланс она не влияет.
Вот эта "дополнительная фиксация рядом с балансом" в практике и дала ощущение "половинки”.
📌Где тот же самый паттерн встречается в финтех-архитектуре?
Реализуют его обычно двумя способами.
1️⃣ Через отдельную техническую сущность (аналог счета холдов)
2000 € — основной остаток
300 € — сумма в HOLD
Балансовый счет при этом один — мы просто отдельно учитываем часть средств, которой нельзя пользоваться.
Это классика карточных авторизаций.
2️⃣ Через “окрашенные деньги”
Счет один — 2000 €
Но внутри:
— 1700 € свободные
— 300 € с меткой HOLD (или с идентификатором операции)
Никакой дополнительной балансовой проводки — только расчет доступного остатка.
❓Зачем это вообще нужно
Потому что в реальной жизни между:
почти всегда есть промежуточное состояние.
И если его не моделировать — начинаются:
— «красненькие» сальдо
— гонки списаний
— магия с доступными средствами
— сложная логика в каждом сервисе
А вот почему я раньше не задумывалась про “полторашку”, расскажу в следующем посте.
Спойлер: на уровне процессинга можно жить вообще без бухгалтерских категорий — там все операции целые 🙂
💬 А вы этот термин используете? Слышали?
Вернемся к финтеху...
В классическом учете действует двойная запись: дебет одного счета = кредит другого счета.
А вот термин полуторная запись я услышала недавно — оказалось, что сам паттерн я использую давно, просто не называла его так 🙂
В прикладном банковском смысле под ней обычно понимают ситуацию, когда:
— делается обычная балансовая двойная проводкаесть баланс не меняется, но нужная нам величина в учете появляется.
— и параллельно фиксируется дополнительная сумма вне этой проводки — без влияния на баланс
То
Простой пример: выдана гарантия клиенту.
Денежные средства в момент выдачи не движутся, но обязательство банка возникает.
Поэтому сумма отражается на внебалансовых счетах — внутри них запись двойная, но на баланс она не влияет.
Вот эта "дополнительная фиксация рядом с балансом" в практике и дала ощущение "половинки”.
📌Где тот же самый паттерн встречается в финтех-архитектуре?
Реализуют его обычно двумя способами.
1️⃣ Через отдельную техническую сущность (аналог счета холдов)
2000 € — основной остаток
300 € — сумма в HOLD
Балансовый счет при этом один — мы просто отдельно учитываем часть средств, которой нельзя пользоваться.
Это классика карточных авторизаций.
2️⃣ Через “окрашенные деньги”
Счет один — 2000 €
Но внутри:
— 1700 € свободные
— 300 € с меткой HOLD (или с идентификатором операции)
Никакой дополнительной балансовой проводки — только расчет доступного остатка.
❓Зачем это вообще нужно
Потому что в реальной жизни между:
“деньги есть”
и
“деньгами можно пользоваться”
почти всегда есть промежуточное состояние.
И если его не моделировать — начинаются:
— «красненькие» сальдо
— гонки списаний
— магия с доступными средствами
— сложная логика в каждом сервисе
А вот почему я раньше не задумывалась про “полторашку”, расскажу в следующем посте.
Спойлер: на уровне процессинга можно жить вообще без бухгалтерских категорий — там все операции целые 🙂
💬 А вы этот термин используете? Слышали?
😁4🔥2👍1
Старое доброе... 👵👨🦳
Иногда, когда в IT обсуждают API, кажется, что все началось с REST, RPC, JSON и микросервисов. Но в финансовой индустрии есть пример куда более старого и при этом до сих пор живого интерфейса.
Речь про ISO 8583.
Этот стандарт появился в 1987 году (меня еще не было) и описывает формат сообщений для операций по банковским картам. По сути это API, через которое системы общаются друг с другом при каждой оплате картой.
Каждый раз, когда вы:
— платите картой в магазине
— снимаете деньги в банкомате
— оплачиваете что-то через POS-терминал
где-то в инфраструктуре проходит сообщение по ISO 8583.
И это не «музейный экспонат», который просто оставили работать. Стандарт обновляется, поддерживается и используется огромным количеством банков, процессингов и платежных сетей.
Причем устроен он довольно необычно по современным меркам:
— бинарные сообщения
— bitmap-структура полей
— фиксированные форматы данных
Вместо привычного JSON сообщение выглядит как набор полей, где часть из них определяется специальной битовой картой — она говорит системе, какие поля вообще присутствуют.
С архитектурной точки зрения это один из самых долгоживущих индустриальных API-протоколов. И одновременно хороший пример того, как техническое решение может прожить десятилетия, если оно оказалось достаточно устойчивым для своей задачи. (Про удобство, как можете догадаться, или про "читаемость" речь не идет)
Но это "фигня" по сравнению с тем, что в некоторых крупных банках часть core banking до сих пор написана на COBOL (1959) (еще даже мамы не было)!
💬 А знаете в какой отралсли есть еще более страые и более "увлекательные" протоколы? И, нет, речь не про передачу данных 🙂
Иногда, когда в IT обсуждают API, кажется, что все началось с REST, RPC, JSON и микросервисов. Но в финансовой индустрии есть пример куда более старого и при этом до сих пор живого интерфейса.
Речь про ISO 8583.
Этот стандарт появился в 1987 году (меня еще не было) и описывает формат сообщений для операций по банковским картам. По сути это API, через которое системы общаются друг с другом при каждой оплате картой.
Каждый раз, когда вы:
— платите картой в магазине
— снимаете деньги в банкомате
— оплачиваете что-то через POS-терминал
где-то в инфраструктуре проходит сообщение по ISO 8583.
И это не «музейный экспонат», который просто оставили работать. Стандарт обновляется, поддерживается и используется огромным количеством банков, процессингов и платежных сетей.
Причем устроен он довольно необычно по современным меркам:
— бинарные сообщения
— bitmap-структура полей
— фиксированные форматы данных
Вместо привычного JSON сообщение выглядит как набор полей, где часть из них определяется специальной битовой картой — она говорит системе, какие поля вообще присутствуют.
С архитектурной точки зрения это один из самых долгоживущих индустриальных API-протоколов. И одновременно хороший пример того, как техническое решение может прожить десятилетия, если оно оказалось достаточно устойчивым для своей задачи. (Про удобство, как можете догадаться, или про "читаемость" речь не идет)
Но это "фигня" по сравнению с тем, что в некоторых крупных банках часть core banking до сих пор написана на COBOL (1959) (еще даже мамы не было)!
💬 А знаете в какой отралсли есть еще более страые и более "увлекательные" протоколы? И, нет, речь не про передачу данных 🙂
👍6
Пропала на прошлой неделе — потому что у нас в компании был хакатон.
И мы запилили продукт AIAjɯ.
Ajɯ (Айыы) — это светлые божества в якутской мифологии. Обитатели Верхнего мира, покровители людей, воплощение доброго начала.
А у нас получились AI-духи, которые помогают.
В основу легла идея продукта от Миши, про которую я рассказывала тут:
https://t.me/ValueGoalsDDD/782
Но на хакатоне мы ее прокачали и добавили:
• авторизацию
• корпоративную библиотеку промтов
• корпоративные AI тулзы
• работу не только с текстом, но и с картинками
Главная идея — демократизировать AI внутри компании и постепенно уходить от “теневых” сервисов в ежедневных задачах. Например, банального перевода сообщений в Slack через chatGPT, тк корпоративный Gemini!
Мы не выиграли 😣
Но получили невероятный кайф и сделали штуку, которой сами пользуемся теперь каждый день!
Спасибо моей прекрасной команде ❤️
С которыми мы обычно работаем в разных командах и доменах — а тут наконец собрались вместе и сделали корпоративную полезняшку.
Это был мой первый хакатон, и вот что я вынесла:
1️⃣ Команду надо выбирать из людей, которые тебя драйвят.
И которых ты любишь работать рядом.
2️⃣ Самый большой кайф — сделать за короткое время то, что реально работает и нужно тебе самому.
В этот момент уже не важно, выиграл ты или нет.
3️⃣ И да, у меня есть профессиональная деформация:
я постоянно думаю, как из текущих “кубиков” собрать что-то новое.
Хакатон — идеальное место, чтобы быстро “закостылять” систему так, чтобы она не падала и давала новую ценность.
4️⃣ Самое важное личное: я готова выступать на английском.
Даже с небольшими докладами минут на 15. Я очень боялась, но оказалось — вполне реально. Просто требует чуть больше подготовки.
На видео — наши первые пользователи.
А на фото — наше чудесное трио AIAjɯ как раз в процессе работы ✨
И мы запилили продукт AIAjɯ.
Ajɯ (Айыы) — это светлые божества в якутской мифологии. Обитатели Верхнего мира, покровители людей, воплощение доброго начала.
А у нас получились AI-духи, которые помогают.
В основу легла идея продукта от Миши, про которую я рассказывала тут:
https://t.me/ValueGoalsDDD/782
Но на хакатоне мы ее прокачали и добавили:
• авторизацию
• корпоративную библиотеку промтов
• корпоративные AI тулзы
• работу не только с текстом, но и с картинками
Главная идея — демократизировать AI внутри компании и постепенно уходить от “теневых” сервисов в ежедневных задачах. Например, банального перевода сообщений в Slack через chatGPT, тк корпоративный Gemini!
Мы не выиграли 😣
Но получили невероятный кайф и сделали штуку, которой сами пользуемся теперь каждый день!
Спасибо моей прекрасной команде ❤️
С которыми мы обычно работаем в разных командах и доменах — а тут наконец собрались вместе и сделали корпоративную полезняшку.
Это был мой первый хакатон, и вот что я вынесла:
1️⃣ Команду надо выбирать из людей, которые тебя драйвят.
И которых ты любишь работать рядом.
2️⃣ Самый большой кайф — сделать за короткое время то, что реально работает и нужно тебе самому.
В этот момент уже не важно, выиграл ты или нет.
3️⃣ И да, у меня есть профессиональная деформация:
я постоянно думаю, как из текущих “кубиков” собрать что-то новое.
Хакатон — идеальное место, чтобы быстро “закостылять” систему так, чтобы она не падала и давала новую ценность.
4️⃣ Самое важное личное: я готова выступать на английском.
Даже с небольшими докладами минут на 15. Я очень боялась, но оказалось — вполне реально. Просто требует чуть больше подготовки.
На видео — наши первые пользователи.
А на фото — наше чудесное трио AIAjɯ как раз в процессе работы ✨
❤17🔥7
Подделка взаимодействия!
Есть два подхода, которые почти всегда вызывают споры:
👯♀️💃 синхронка поверх асинхронки
💃 👯♀️ асинхронка поверх синхронки
И каждый раз ощущение странное: то ли тебя обманывают, то ли это нормальная инженерная практика, просто неочевидная.
Давайте разберем любимое — асинхронка на синхронке.
Как это выглядит на практике:
1️⃣ система X отправляет синхронный запрос
2️⃣ система Y синхронно отвечает: «принял, вот id»
3️⃣ система X:
- либо ждет
- либо ходит опрашивать статус
4️⃣ когда что-то изменилось — Y шлет webhook
Снаружи — синхронный API.
По факту — распределенный асинхронный процесс.
Когда это нужно
🤖Интеграционные гейты и мерчанты.
У вас есть N клиентов, которым нужно:
- понимать, что произошло
- получать однозначные ответы
- не разбираться в очередях и событиях
А внутри вы хотите:
- строить очередь
- ретраить
- управлять нагрузкой
В итоге вы даете им синхронный контракт, но живете в асинхронной модели.
🤺Саги и каскадирование.
Процесс стартует в одном сервисе → уходит в другой → дальше цепочка шагов, ретраев, откатов.
Но у первого сервиса:
- свои таймауты
- свои SLA
- необходимость понимать, что произошло
Поэтому:
- снаружи он делает «синхронный» вызов
- внутри запускается асинхронная сага
🤔 Пользовательские сценарии (UI).
Есть запрос из:
- мобильного приложения
- веба
И где-то в цепочке появляется прокси-сервис, который:
- агрегирует
- модифицирует
- маршрутизирует
Но при этом:
- жесткие таймауты
- нельзя держать соединение долго
- пользователь ждет ответ «сейчас»
Решение:
- быстро принять запрос
- отдать «синхронный» результат
- остальное доделать асинхронно
❓Что еще сюда попадает
Если посмотреть шире, таких сценариев больше:
⏱️ Долгие внешние интеграции
Когда вы ходите во внешние системы с непредсказуемой латентностью и не хотите держать открытое соединение
⛓️💥 Нестабильные провайдеры
Когда нужны ретраи, фолбэки, каскадирование, но клиенту это показывать нельзя
🎛️ Регуляторные процессы
Когда важно зафиксировать факт «запрос принят» даже если обработка займет часы
🛟 Буферизация нагрузки
Когда входящий поток нужно сгладить очередью
но API при этом остается синхронным
Почему это вызывает споры?
Потому что это компромисс.
Мы:
- упрощаем контракт снаружи
- усложняем систему внутри
И создаем риск:
- «ответ уже был, а результат еще меняется»
- рассинхронизации статусов
- сложного дебага
Но при этом без этого паттерна:
- не живут платежные гейты
- не строятся интеграционные слои с внешними мерчантами
💬 А теперь вопрос:
если мы умеем делать асинхронку на синхронке…
зачем тогда делают наоборот?
Про синхронку поверх асинхронки — в следующем посте.
Есть два подхода, которые почти всегда вызывают споры:
👯♀️
И каждый раз ощущение странное: то ли тебя обманывают, то ли это нормальная инженерная практика, просто неочевидная.
Давайте разберем любимое — асинхронка на синхронке.
Как это выглядит на практике:
1️⃣ система X отправляет синхронный запрос
2️⃣ система Y синхронно отвечает: «принял, вот id»
3️⃣ система X:
- либо ждет
- либо ходит опрашивать статус
4️⃣ когда что-то изменилось — Y шлет webhook
Снаружи — синхронный API.
По факту — распределенный асинхронный процесс.
Когда это нужно
🤖Интеграционные гейты и мерчанты.
У вас есть N клиентов, которым нужно:
- понимать, что произошло
- получать однозначные ответы
- не разбираться в очередях и событиях
А внутри вы хотите:
- строить очередь
- ретраить
- управлять нагрузкой
В итоге вы даете им синхронный контракт, но живете в асинхронной модели.
🤺Саги и каскадирование.
Процесс стартует в одном сервисе → уходит в другой → дальше цепочка шагов, ретраев, откатов.
Но у первого сервиса:
- свои таймауты
- свои SLA
- необходимость понимать, что произошло
Поэтому:
- снаружи он делает «синхронный» вызов
- внутри запускается асинхронная сага
🤔 Пользовательские сценарии (UI).
Есть запрос из:
- мобильного приложения
- веба
И где-то в цепочке появляется прокси-сервис, который:
- агрегирует
- модифицирует
- маршрутизирует
Но при этом:
- жесткие таймауты
- нельзя держать соединение долго
- пользователь ждет ответ «сейчас»
Решение:
- быстро принять запрос
- отдать «синхронный» результат
- остальное доделать асинхронно
❓Что еще сюда попадает
Если посмотреть шире, таких сценариев больше:
⏱️ Долгие внешние интеграции
Когда вы ходите во внешние системы с непредсказуемой латентностью и не хотите держать открытое соединение
⛓️💥 Нестабильные провайдеры
Когда нужны ретраи, фолбэки, каскадирование, но клиенту это показывать нельзя
🎛️ Регуляторные процессы
Когда важно зафиксировать факт «запрос принят» даже если обработка займет часы
🛟 Буферизация нагрузки
Когда входящий поток нужно сгладить очередью
но API при этом остается синхронным
Почему это вызывает споры?
Потому что это компромисс.
Мы:
- упрощаем контракт снаружи
- усложняем систему внутри
И создаем риск:
- «ответ уже был, а результат еще меняется»
- рассинхронизации статусов
- сложного дебага
Но при этом без этого паттерна:
- не живут платежные гейты
- не строятся интеграционные слои с внешними мерчантами
💬 А теперь вопрос:
если мы умеем делать асинхронку на синхронке…
зачем тогда делают наоборот?
Про синхронку поверх асинхронки — в следующем посте.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥4
Продолжаем про подделку взаимодействия.
Если в прошлый раз мы притворялись, что все синхронно,
то теперь наоборот — делаем синхронку на асинхронке.
И тут ощущение еще страннее: вроде очередь… но ведет себя как API.
Как это выглядит:
— X отправляет сообщение в очередь
— Y его обрабатывает и ответ возвращается тоже через очередь
— X сидит и ждет как ни в чем не бывало
И в голове у X:
Зачем так жить?
1️⃣ Изоляция сервисов
Нет прямых вызовов — только брокер.
Но бизнесу все равно нужен «запрос → ответ».
2️⃣ Надежность
Очереди умеют ретраи и доставку.
HTTP — умеет падать.
3️⃣ Контроль нагрузки
Очередь — это буфер.
Можно не ловить пики лицом.
4️⃣ Саги и процессы
Все общается событиями, но отдельные шаги хочется мыслить как вызовы.
Что по факту происходит?
Мы берем асинхронную инфраструктуру и начинаем использовать ее как синхронную.
Немного против природы. Но работает.
Почему это больно?
— ответ может прийти «когда-нибудь»
— correlation id становится вашим лучшим другом
— дебаг выглядит как археология сообщений
Когда это нормально?
— event-driven архитектура
— нет прямых соединений
— важнее надежность, чем скорость
Когда не надо?
— если можно просто сделать HTTP-запрос
— если важны миллисекунды, а не «дойдёт точно»
В итоге картина симметричная:
💃 👯♀️асинхронка на синхронке — чтобы упростить жизнь клиенту
👯♀️💃 синхронка на асинхронке — чтобы выжить внутри системы
Мы либо притворяемся, что все просто, либо притворяемся, что все надежно.
Иногда — одновременно 😅 Да, такое тоже бывает!
Если в прошлый раз мы притворялись, что все синхронно,
то теперь наоборот — делаем синхронку на асинхронке.
И тут ощущение еще страннее: вроде очередь… но ведет себя как API.
Как это выглядит:
— X отправляет сообщение в очередь
— Y его обрабатывает и ответ возвращается тоже через очередь
— X сидит и ждет как ни в чем не бывало
И в голове у X:
"я сделал запрос и получил ответ и не финальный. Хотя ни одного HTTP-вызова не было."
Зачем так жить?
1️⃣ Изоляция сервисов
Нет прямых вызовов — только брокер.
Но бизнесу все равно нужен «запрос → ответ».
2️⃣ Надежность
Очереди умеют ретраи и доставку.
HTTP — умеет падать.
3️⃣ Контроль нагрузки
Очередь — это буфер.
Можно не ловить пики лицом.
4️⃣ Саги и процессы
Все общается событиями, но отдельные шаги хочется мыслить как вызовы.
Что по факту происходит?
Мы берем асинхронную инфраструктуру и начинаем использовать ее как синхронную.
Немного против природы. Но работает.
Почему это больно?
— ответ может прийти «когда-нибудь»
— correlation id становится вашим лучшим другом
— дебаг выглядит как археология сообщений
Когда это нормально?
— event-driven архитектура
— нет прямых соединений
— важнее надежность, чем скорость
Когда не надо?
— если можно просто сделать HTTP-запрос
— если важны миллисекунды, а не «дойдёт точно»
В итоге картина симметричная:
👯♀️
Мы либо притворяемся, что все просто, либо притворяемся, что все надежно.
Иногда — одновременно 😅 Да, такое тоже бывает!
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍5
Сегодня запускаю розыгрыш бесплатного билета на конференцию
Аналитический марафон #17.
Тема — прям очень в сердечко: «Технологии и коммуникации в работе системного аналитика»
Если коротко — это не про “писать ТЗ”, а про то, как аналитик:
— работает с архитектурой
— использует AI в задачах
— ускоряет процессы и снижает хаос
И программа там прям жирная:
🔹 ADR & Agent Skills — как готовить архитектурные решения с помощью LLM
🔹 AI-ассистент на коде компании — live-demo RAG-системы
🔹 Стандартизация API — от хаоса к метрикам
🔹 От промпта к прототипу — проверяем требования до разработки
И это не теория, а реальные практики, которые можно забирать и применять.
Теперь к самому приятному:
🎁 Разыгрываю 1 бесплатный билет
Чтобы поучаствовать — просто напишите в комментариях:
«Я хочу»
⏰ Итоги подведу в понедельник
Если давно смотрели в сторону таких тем — это прям хороший шанс зайти.
(А если не повезет — все равно рекомендую посмотреть программу, она правда клевая, и будет дополнительная скидка, котороую можно применить до подорожания билетиков!!!)
Аналитический марафон #17.
Тема — прям очень в сердечко: «Технологии и коммуникации в работе системного аналитика»
Если коротко — это не про “писать ТЗ”, а про то, как аналитик:
— работает с архитектурой
— использует AI в задачах
— ускоряет процессы и снижает хаос
И программа там прям жирная:
🔹 ADR & Agent Skills — как готовить архитектурные решения с помощью LLM
🔹 AI-ассистент на коде компании — live-demo RAG-системы
🔹 Стандартизация API — от хаоса к метрикам
🔹 От промпта к прототипу — проверяем требования до разработки
И это не теория, а реальные практики, которые можно забирать и применять.
Теперь к самому приятному:
🎁 Разыгрываю 1 бесплатный билет
Чтобы поучаствовать — просто напишите в комментариях:
«Я хочу»
⏰ Итоги подведу в понедельник
Если давно смотрели в сторону таких тем — это прям хороший шанс зайти.
(А если не повезет — все равно рекомендую посмотреть программу, она правда клевая, и будет дополнительная скидка, котороую можно применить до подорожания билетиков!!!)
❤11👍4🔥4
🕵️♀️ Продуктовые подмены (технического толка)
Как продакт, я прихожу в восторг, когда вижу, как сложные технические и алгоритмические задачи решаются не «в лоб», а через изящный пользовательский опыт. Когда юзер делает то, что ему нужно, а бизнес при этом получает бесценный ресурс.
Меня до мурашек пробирают две истории, где под видом игры или безопасности корпорации выстроили идеальные системы сбора данных.
1. Капча: Как мы все стали бесплатными разметчиками данных 📚
Вы задумывались, почему раньше мы вводили кривые слова, а теперь ищем на фото гидранты?
В 2000 году Луис фон Ан придумал CAPTCHA для защиты от спама. Но как настоящий визионер, он осознал: человечество тратит 500 000 часов в день на ввод этой чепухи! И он превратил это в reCAPTCHA.
— В чем продуктовый кайф: Вам давали два слова. Одно — проверочное, а второе — фрагмент из старой книги, который сканер Google не распознал. Когда 6+ человек вводили его одинаково, слово считалось оцифрованным.
— Результат: К 2018 году более 1 миллиарда людей бесплатно оцифровали архивы The New York Times и Google Books.
— Сейчас: Когда вы кликаете на «пешеходные переходы», вы размечаете данные для обучения автопилотов. Это идеальный «невидимый» онбординг в процесс обучения ИИ.
Пруф: Статья в NYT о том, как человечество цифровало историю.
2. Pokemon GO: Как геймификация создала лучшую карту мира 📱
Помните безумие 2016-го? Пока все ловили покемонов, компания Niantic решала сложнейшую задачу картографии.
— Гипотеза: Чтобы создать AR-карту будущего, нужны фото и маршруты там, куда не заедет машина Google Street View.
— Реализация: Вместо того чтобы нанимать армию картографов, они создали игру. Редкие покемоны появлялись у «покестопов» — памятников, граффити, скрытых уголков.
— Продуктовый профит: Игроки сами фотографировали объекты с разных ракурсов и прокладывали пешеходные маршруты. Niantic получила самую детализированную карту планеты с привязкой к местности, созданную руками (и ногами) пользователей.
Пруф: Исследование о том, как данные игры используются для картографии и интервью из MIT Technology Review
Почему я об этом пишу?
Для меня эти кейсы — эталон того, как нужно подходить к разработке. Когда продукт решает проблему пользователя (защита от ботов или фан), но параллельно генерит огромную ценность для развития технологий. Это просто «Гениально, блин!».
💬А какие скрытые смыслы в привычных сервисах замечали вы?
Пишите в комментариях, обсудим! 👇
Как продакт, я прихожу в восторг, когда вижу, как сложные технические и алгоритмические задачи решаются не «в лоб», а через изящный пользовательский опыт. Когда юзер делает то, что ему нужно, а бизнес при этом получает бесценный ресурс.
Меня до мурашек пробирают две истории, где под видом игры или безопасности корпорации выстроили идеальные системы сбора данных.
1. Капча: Как мы все стали бесплатными разметчиками данных 📚
Вы задумывались, почему раньше мы вводили кривые слова, а теперь ищем на фото гидранты?
В 2000 году Луис фон Ан придумал CAPTCHA для защиты от спама. Но как настоящий визионер, он осознал: человечество тратит 500 000 часов в день на ввод этой чепухи! И он превратил это в reCAPTCHA.
— В чем продуктовый кайф: Вам давали два слова. Одно — проверочное, а второе — фрагмент из старой книги, который сканер Google не распознал. Когда 6+ человек вводили его одинаково, слово считалось оцифрованным.
— Результат: К 2018 году более 1 миллиарда людей бесплатно оцифровали архивы The New York Times и Google Books.
— Сейчас: Когда вы кликаете на «пешеходные переходы», вы размечаете данные для обучения автопилотов. Это идеальный «невидимый» онбординг в процесс обучения ИИ.
Пруф: Статья в NYT о том, как человечество цифровало историю.
2. Pokemon GO: Как геймификация создала лучшую карту мира 📱
Помните безумие 2016-го? Пока все ловили покемонов, компания Niantic решала сложнейшую задачу картографии.
— Гипотеза: Чтобы создать AR-карту будущего, нужны фото и маршруты там, куда не заедет машина Google Street View.
— Реализация: Вместо того чтобы нанимать армию картографов, они создали игру. Редкие покемоны появлялись у «покестопов» — памятников, граффити, скрытых уголков.
— Продуктовый профит: Игроки сами фотографировали объекты с разных ракурсов и прокладывали пешеходные маршруты. Niantic получила самую детализированную карту планеты с привязкой к местности, созданную руками (и ногами) пользователей.
Пруф: Исследование о том, как данные игры используются для картографии и интервью из MIT Technology Review
Почему я об этом пишу?
Для меня эти кейсы — эталон того, как нужно подходить к разработке. Когда продукт решает проблему пользователя (защита от ботов или фан), но параллельно генерит огромную ценность для развития технологий. Это просто «Гениально, блин!».
💬А какие скрытые смыслы в привычных сервисах замечали вы?
Пишите в комментариях, обсудим! 👇
NY Times
Deciphering Old Texts, One Woozy, Curvy Word at a Time (Published 2011)
A Web site security measure is also a project to transform old books, magazines, newspapers or pamphlets into accurate, searchable and easily sortable computer text files.
👍16❤🔥12🔥12