ITKatya: культурные паттерны в IT

Полезняшка выходного дня (на Кипре сегодня День независимости Греции) - фемтех стартап yessaХочу поделиться проектом, который очень откликнулся — Yessa. Это фемтех-стартап, который помогает женщинам исследовать свою сексуальность — безопасно, без стыда и без чужих ожиданий.Почему это важно!Женская сексуальность до сих пор:— замалчивается и табуируется— описывается «снаружи» (да еще и через призму маскулинных фантазий)— редко становится пространством для собственного индивидуального исследованияИ в итоге женщина часто знает, «как надо», но не знает, как ей нравится, что ее возбуждает.Что делает команда Yessa?Они создают формат, где можно:— исследовать свои ощущения— лучше понять себя и свое тело— и все это в безопасной и поддерживающей средеИ это не про контент. Это про возвращение контроля над своим опытом.Как я узнала про этот стартап?LinkedIn подробсил статью! А дальше я была в шоке! Это кыргызский стартап-феномен! 2 девушки создали очень важное и прекрасное приложение!Да, мне сложно писать без множества восклицательных знаков :)Причина проста: Для меня как для женщины этот проект очень личный. Где-то ближе к 40 легко поймать себя на мысли, что «я уже все про себя знаю», и обесценить любое желание что-то исследовать — как будто это уже не про меня. Но это обманчивое чувство: иногда кажется, что ты в курсе, кто ты и про что ты, а на деле просто рядом есть человек, с которым тебе безопасно быть собой. И это разные вещи. Путь к себе вообще непростой и неочевидный, и его нельзя считать «пройденным» один раз. Изучать себя — это не про любопытство, это в том числе про безопасность: только понимая, что ты чувствуешь, где твои границы и желания, ты можешь адекватно распознать, кто и что перед тобой.Почему хочется поддержать?Потому что такие проекты меняют не интерфейсы — а способ, которым женщины вообще могут говорить о себе.А еще это платформа для авторок и для актеров речевого жанра!Кстати, они всегда ищут прекрасные мужские голоса, так что господа и дамы айтишнечки -

📌 Почему «сеньор» может положить KYC-систему одной цифрой❓На Хабре вышла, пожалуй, лучшая статья для инженеров в доменах Compliance, KYC и Fintech. Автор (Данил Емельянов, @MrTheFirst) поднял тему, которая кажется базовой, но на которой «срезаются» не то, что 80% кандидатов, а более 50% компаний (и далеко не самых «мелких» и «будничных»)?🔎 Суть проблемыЕсли вы храните паспорт как INTEGER, вы — потенциальный создатель багов на миллионы в вашей валюте!Пример: Серия паспорта 0306.База говорит: «О, это число! Зачем нам ноль впереди?»Итог: В базе сохраняется 306.Для системы KYC этот документ больше не существует. Человек не пройдет проверку, заявка упадет, а поддержка будет неделями искать, почему «данные не совпадают».🤯 Феноменология комментариев: Пути «Логики»Но самое интересное — в комментариях. Это настоящий заповедник неисповедимой логики, где люди готовы строить адронные коллайдеры из костылей, лишь бы не признать семантику данных! И тут как всегда 3 основные кагорты:1️⃣«Экономисты на спичках»: Люди всерьез спорят о 2–4 байтах разницы между INT и CHAR, забывая, что одна ошибка в данных в домене комплаенса стоит дороже, чем все жесткие диски в серверной.2️⃣ «Адепты фронтенд-костылей»: Советуют «доклеивать нули при выводе». Это классический путь к катастрофе: стоит любому другому сервису постучаться в БД напрямую — и он получит инвалидные данные.3️⃣ «Свидетели производительности»: Упорно верят, что поиск по строке CHAR(4) уронит базу, хотя современные индексы на таких объемах работают идентично.🛡 Почему это критично для Compliance & KYC?В нашем домене данные — это не просто значения, это юридически значимые идентификаторы.— Номера документов могут начинаться с 01-09, тут и регионы, и даты и еще много каких правил.— Ведущие нули — норма. А кроме этого еще и форматы номеров меняются вместе с версиями документов! И тогда вместо привых [1..9] прилетает 00**— Удаление «лишних» занков: тут +, -, —. А в итоге равенство там где его не должно быть!Золотое правило из стать

🕵️‍♀️ Продуктовые подмены (технического толка)Как продакт, я прихожу в восторг, когда вижу, как сложные технические и алгоритмические задачи решаются не «в лоб», а через изящный пользовательский опыт. Когда юзер делает то, что ему нужно, а бизнес при этом получает бесценный ресурс.Меня до мурашек пробирают две истории, где под видом игры или безопасности корпорации выстроили идеальные системы сбора данных.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 получила самую детализированную карту планеты с привязкой к местности, созданную руками (и ногами) пользователей. Пруф: Исследова

@KrrrrOlya поздравляю 🥳 Для всех скидка 20% на билеты:ITK20_AM17

Сегодня запускаю розыгрыш бесплатного билета на конференциюАналитический марафон #17.Тема — прям очень в сердечко: «Технологии и коммуникации в работе системного аналитика»Если коротко — это не про “писать ТЗ”, а про то, как аналитик:— работает с архитектурой— использует AI в задачах— ускоряет процессы и снижает хаосИ программа там прям жирная:🔹 ADR & Agent Skills — как готовить архитектурные решения с помощью LLM🔹 AI-ассистент на коде компании — live-demo RAG-системы🔹 Стандартизация API — от хаоса к метрикам🔹 От промпта к прототипу — проверяем требования до разработкиИ это не теория, а реальные практики, которые можно забирать и применять.Теперь к самому приятному:🎁 Разыгрываю 1 бесплатный билетЧтобы поучаствовать — просто напишите в комментариях:«Я хочу»⏰ Итоги подведу в понедельникЕсли давно смотрели в сторону таких тем — это прям хороший шанс зайти.(А если не повезет — все равно рекомендую посмотреть программу, она правда клевая, и будет дополнительная скидка, котороую можно применить до подорожания билетиков!!!)

Продолжаем про подделку взаимодействия.Если в прошлый раз мы притворялись, что все синхронно,то теперь наоборот — делаем синхронку на асинхронке.И тут ощущение еще страннее: вроде очередь… но ведет себя как API.Как это выглядит:— X отправляет сообщение в очередь— Y его обрабатывает и ответ возвращается тоже через очередь— X сидит и ждет как ни в чем не бывалоИ в голове у X: "я сделал запрос и получил ответ и не финальный. Хотя ни одного HTTP-вызова не было."Зачем так жить?1️⃣ Изоляция сервисовНет прямых вызовов — только брокер.Но бизнесу все равно нужен «запрос → ответ».2️⃣ НадежностьОчереди умеют ретраи и доставку.HTTP — умеет падать.3️⃣ Контроль нагрузкиОчередь — это буфер.Можно не ловить пики лицом.4️⃣ Саги и процессыВсе общается событиями, но отдельные шаги хочется мыслить как вызовы.Что по факту происходит?Мы берем асинхронную инфраструктуру и начинаем использовать ее как синхронную.Немного против природы. Но работает.Почему это больно?— ответ может прийти «когда-нибудь»— correlation id становится вашим лучшим другом— дебаг выглядит как археология сообщенийКогда это нормально?— event-driven архитектура— нет прямых соединений— важнее надежность, чем скоростьКогда не надо?— если можно просто сделать HTTP-запрос— если важны миллисекунды, а не «дойдёт точно»В итоге картина симметричная:💃👯‍♀️асинхронка на синхронке — чтобы упростить жизнь клиенту👯‍♀️💃 синхронка на асинхронке — чтобы выжить внутри системыМы либо притворяемся, что все просто, либо притворяемся, что все надежно.Иногда — одновременно 😅 Да, такое тоже бывает!

Подделка взаимодействия!Есть два подхода, которые почти всегда вызывают споры:👯‍♀️💃 синхронка поверх асинхронки💃👯‍♀️ асинхронка поверх синхронкиИ каждый раз ощущение странное: то ли тебя обманывают, то ли это нормальная инженерная практика, просто неочевидная.Давайте разберем любимое — асинхронка на синхронке.Как это выглядит на практике:1️⃣ система X отправляет синхронный запрос2️⃣ система Y синхронно отвечает: «принял, вот id»3️⃣ система X:- либо ждет- либо ходит опрашивать статус4️⃣ когда что-то изменилось — Y шлет webhookСнаружи — синхронный API.По факту — распределенный асинхронный процесс.Когда это нужно🤖Интеграционные гейты и мерчанты.У вас есть N клиентов, которым нужно:- понимать, что произошло- получать однозначные ответы- не разбираться в очередях и событияхА внутри вы хотите:- строить очередь- ретраить- управлять нагрузкойВ итоге вы даете им синхронный контракт, но живете в асинхронной модели.🤺Саги и каскадирование.Процесс стартует в одном сервисе → уходит в другой → дальше цепочка шагов, ретраев, откатов.Но у первого сервиса:- свои таймауты- свои SLA- необходимость понимать, что произошлоПоэтому:- снаружи он делает «синхронный» вызов- внутри запускается асинхронная сага🤔 Пользовательские сценарии (UI).Есть запрос из:- мобильного приложения- вебаИ где-то в цепочке появляется прокси-сервис, который:- агрегирует- модифицирует- маршрутизируетНо при этом:- жесткие таймауты- нельзя держать соединение долго- пользователь ждет ответ «сейчас»Решение:- быстро принять запрос- отдать «синхронный» результат- остальное доделать асинхронно❓Что еще сюда попадаетЕсли посмотреть шире, таких сценариев больше:⏱️ Долгие внешние интеграцииКогда вы ходите во внешние системы с непредсказуемой латентностью и не хотите держать открытое соединение⛓️‍💥 Нестабильные провайдерыКогда нужны ретраи, фолбэки, каскадирование, но клиенту это показывать нельзя🎛️ Регуляторные процессыКогда важно зафиксировать факт «запрос принят» даже если обработка займет часы🛟 Буферизация нагруз

Пропала на прошлой неделе — потому что у нас в компании был хакатон.И мы запилили продукт AIAjɯ.Ajɯ (Айыы) — это светлые божества в якутской мифологии. Обитатели Верхнего мира, покровители людей, воплощение доброго начала.А у нас получились AI-духи, которые помогают.В основу легла идея продукта от Миши, про которую я рассказывала тут: https://t.me/ValueGoalsDDD/782Но на хакатоне мы ее прокачали и добавили:• авторизацию • корпоративную библиотеку промтов • корпоративные AI тулзы• работу не только с текстом, но и с картинками Главная идея — демократизировать AI внутри компании и постепенно уходить от “теневых” сервисов в ежедневных задачах. Например, банального перевода сообщений в Slack через chatGPT, тк корпоративный Gemini!Мы не выиграли 😣Но получили невероятный кайф и сделали штуку, которой сами пользуемся теперь каждый день!Спасибо моей прекрасной команде ❤️ С которыми мы обычно работаем в разных командах и доменах — а тут наконец собрались вместе и сделали корпоративную полезняшку.Это был мой первый хакатон, и вот что я вынесла:1️⃣ Команду надо выбирать из людей, которые тебя драйвят. И которых ты любишь работать рядом.2️⃣ Самый большой кайф — сделать за короткое время то, что реально работает и нужно тебе самому. В этот момент уже не важно, выиграл ты или нет.3️⃣ И да, у меня есть профессиональная деформация: я постоянно думаю, как из текущих “кубиков” собрать что-то новое. Хакатон — идеальное место, чтобы быстро “закостылять” систему так, чтобы она не падала и давала новую ценность.4️⃣ Самое важное личное: я готова выступать на английском. Даже с небольшими докладами минут на 15. Я очень боялась, но оказалось — вполне реально. Просто требует чуть больше подготовки.На видео — наши первые пользователи. А на фото — наше чудесное трио AIAjɯ как раз в процессе работы ✨Пропала на прошлой неделе — потому что у нас в компании был хакатон.И мы запилили продукт AIAjɯ.Ajɯ (Айыы) — это светлые божества в якутской мифологии. Обитатели Верхнего мира, покровители

Старое доброе... 👵👨‍🦳Иногда, когда в IT обсуждают API, кажется, что все началось с REST, RPC, JSON и микросервисов. Но в финансовой индустрии есть пример куда более старого и при этом до сих пор живого интерфейса.Речь про ISO 8583.Этот стандарт появился в 1987 году (меня еще не было) и описывает формат сообщений для операций по банковским картам. По сути это API, через которое системы общаются друг с другом при каждой оплате картой.Каждый раз, когда вы:— платите картой в магазине— снимаете деньги в банкомате— оплачиваете что-то через POS-терминалгде-то в инфраструктуре проходит сообщение по ISO 8583.И это не «музейный экспонат», который просто оставили работать. Стандарт обновляется, поддерживается и используется огромным количеством банков, процессингов и платежных сетей.Причем устроен он довольно необычно по современным меркам:— бинарные сообщения— bitmap-структура полей— фиксированные форматы данныхВместо привычного JSON сообщение выглядит как набор полей, где часть из них определяется специальной битовой картой — она говорит системе, какие поля вообще присутствуют.С архитектурной точки зрения это один из самых долгоживущих индустриальных API-протоколов. И одновременно хороший пример того, как техническое решение может прожить десятилетия, если оно оказалось достаточно устойчивым для своей задачи. (Про удобство, как можете догадаться, или про "читаемость" речь не идет)Но это "фигня" по сравнению с тем, что в некоторых крупных банках часть core banking до сих пор написана на COBOL (1959) (еще даже мамы не было)!💬 А знаете в какой отралсли есть еще более страые и более "увлекательные" протоколы? И, нет, речь не про передачу данных 🙂

Бухгалтерская "полторашка" 🍷Вернемся к финтеху...В классическом учете действует двойная запись: дебет одного счета = кредит другого счета.А вот термин полуторная запись я услышала недавно — оказалось, что сам паттерн я использую давно, просто не называла его так 🙂В прикладном банковском смысле под ней обычно понимают ситуацию, когда:— делается обычная балансовая двойная проводка— и параллельно фиксируется дополнительная сумма вне этой проводки — без влияния на балансТо есть баланс не меняется, но нужная нам величина в учете появляется.Простой пример: выдана гарантия клиенту.Денежные средства в момент выдачи не движутся, но обязательство банка возникает.Поэтому сумма отражается на внебалансовых счетах — внутри них запись двойная, но на баланс она не влияет.Вот эта "дополнительная фиксация рядом с балансом" в практике и дала ощущение "половинки”.📌Где тот же самый паттерн встречается в финтех-архитектуре?Реализуют его обычно двумя способами.1️⃣ Через отдельную техническую сущность (аналог счета холдов)2000 € — основной остаток300 € — сумма в HOLDБалансовый счет при этом один — мы просто отдельно учитываем часть средств, которой нельзя пользоваться.Это классика карточных авторизаций.2️⃣ Через “окрашенные деньги”Счет один — 2000 €Но внутри:— 1700 € свободные— 300 € с меткой HOLD (или с идентификатором операции)Никакой дополнительной балансовой проводки — только расчет доступного остатка.❓Зачем это вообще нужноПотому что в реальной жизни между:“деньги есть”и“деньгами можно пользоваться”почти всегда есть промежуточное состояние.И если его не моделировать — начинаются:— «красненькие» сальдо— гонки списаний— магия с доступными средствами— сложная логика в каждом сервисеА вот почему я раньше не задумывалась про “полторашку”, расскажу в следующем посте.Спойлер: на уровне процессинга можно жить вообще без бухгалтерских категорий — там все операции целые 🙂💬 А вы этот термин используете? Слышали?