StringConcat - разработка без боли и сожалений

Я тут неожиданно для себя обнаружил, что пора обновить роутер. Не потому что старый плохо работал — нет, он ещё бодр, как Java 8 в проде. А потому что пришёл Wi-Fi 7 и Wi-Fi 6E, а вместе с ними — священный диапазон 6 GHz, который пока не засран соседями. Надо брать, пока можно. Скорости, конечно, обещают чудовищные. Я ещё помню времена, когда от одного провода зависело — будет у тебя 10 или 100 Mbps. А теперь вот это всё, без тени стыда: 11520 Mbps (6 GHz, EHT320) + 5760 Mbps (5 GHz, EHT240) + 1376 Mbps (2.4 GHz, EHT40) Да, мне тоже не совсем понятно где и когда я буду это использовать, но звучит убедительно, а значит — надо. Самый мучительный процесс после покупки роутера — выбор имени Wi-Fi сети. Тут важна архитектура, доменная модель и, конечно, чувство юмора. Мы с ChatGPT, как большие фанаты Star Wars, решили проблему за вас. Теперь мучаться придётся только один раз — при выборе роутера. Готовые имена сетей: • Obi-WAN Kenobi • The LANdalorian • Rogue WAN • Wi-Fi Awakens • Return of the Ping • A New Hop • These Are Not the Droids • R2-D2.4GHz • The Force Is Strong • You Underestimate My Bandwidth • May the Wi-Fi Be With You • LAN Solo Роутер в итоге взял TP-Link EB810v, за 170USD с рук. Цена нового около 500USD (очень люблю когда хорошие роутеры идут в подписке у провайдера. Их можно потом найти по бросовым ценам). Если кому интересно — спрашивайте. Если не интересно — всё равно назовите сеть красиво.

Реальность vs Ожидания: что мы узнали из общения с вами За последние недели мы провели плотные сеанс обратной связи по курсу "Разработка без боли и сожалений". Нам было важно поговорить с двумя разными группами: - С теми, кто только планирует обучение и ищет точки роста. - С выпускниками, кто уже пережил курс и успешно внедрил практики в работу своих команд. Это был не просто разговор, а глубокий разбор полетов. Мы узнали: - Что реально работает в бою, а что — не сработало. - Где ожидания совпали с реальностью, а где были сюрпризы. - С какими вызовами вы сталкиваетесь прямо сейчас. Этот срез реальности помог нам скорректировать фокус, чтобы разбирать не сухую теорию, а живые, актуальные кейсы. 🚀 Что дальше? Следующий поток стартует в феврале. Мы уже обновляем программу с учетом полученных инсайтов. Главная новинка: добавим блок про то, как заставить ИИ реально помогать, а не генерировать рандомные баги. Спойлер: в связке с DDD получается настоящая ИМБА. Если вы рассматриваете участие — мы открыли предзапись. Это ни к чему не обязывает, но вы точно не пропустите старт и получите лучшие условия. 👉 [Ссылка на предзапись] Спасибо всем, кто поделился опытом и помог сделать продукт лучше!

Пост №3. Сухие цифры для Скруджей Макдаков 💰 Сколько стоит стать улиткой? Подбиваем бабки нашего эксперимента с автодомом в Тасмании. Если вы думали, что это дешевый способ путешествовать — у меня для вас плохие новости. Итого за неделю (цены в USD): 📉 Аренда дома: $1000. 📉 Стоянки (чтобы поспать легально): $200. 📉 Топливо: $200 (я ожидал, что этот сарай жрет больше, приятный сюрприз). 📉 Еда, рестораны, вино (много вина) и кофе: $1000. Итого: ~$2400 за неделю на четверых. Вердикт: Смысл брать дом, а не отель + авто? Не собираешь чемоданы. Дети далеко от водителя. Можно проснуться с видом на виноградник и сразу начать... дегустировать. Повторил бы я? Да. Но беруши купил бы заранее.

Пост №2. Быт, дети и алкоголизм как стратегия 🏠 Выживание в автодоме: инструкция по применению Продолжаю рассказ про наш тасманский вояж. Многие думают, что автодом — это про экономию. Ха! Мы почти не сэкономили, зато познали дзен бытовой лени. Главный плюс Вам не нужно каждый день играть в тетрис с чемоданами. Просто сгребаешь в кучу всё, что может кататься по салону и убить кого-то на повороте, загоняешь детей внутрь — и погнали. Личное пространство Оказывается, 5-6 метров дистанции между родителями и детьми творят чудеса. Мы с женой в кабине — приличные люди, обсуждаем высокие материи. Дети сзади валяются на кровати (да, так ехать кайфово, пока не начнешь тормозить). Идиллия. Планирование? Не слышали Project Management остался на работе. Наш метод — «слабоумие и отвага». Был только список мест, а где ночевать — решали по факту. Перспектива остаться ночью в поле не пугает, когда твой дом едет с тобой. А вот стоянки платные. Просто ровная площадка — $12. Хочешь воды, электричества и слить... накопленное? Гони $15–30. Бесплатно стоять нельзя, дальнобойщик Джо должен платить. Комфорт На удивление, это полноценный дом. Две кровати, душ, туалет, холодильник. Жена даже умудрилась пожарить настоящий стейк на микро-плите! Мы пришли к выводу, что могли бы так прожить еще пару недель. Чилить в кемпингах, обсуждать артрит с австралийскими пенсионерами и деградировать. 🍷 Лайфхак для алкоголиков-эстетов: Некоторые винодельни Тасмании разрешают кемперам ночевать на их территории. Тур от винодельни к винокурне с ночевкой на месте дегустации — звучит как идеальный план на старость.

Я проехал 1000 км в автодоме и вынужден поделиться этим экспериенсом с вами Сегодня никакой душноты про DDD. Поделюсь с вами пережитым в отпуске! Решил, что простого отпуска мне мало, и вывез жену с двумя детьми в Тасманию. Чтобы жизнь медом не казалась, мы арендовали автодом. Неделю мы в нем спали, ели и, простите, производили удобрения. Ощущения за рулем За эту неделю я превратился в сурового дальнобойщика Джо. Наш дом на колесах размером с ПАЗик (3.5 метра в высоту!), а дороги в Тасмании строили для хоббитов. Едешь, потеешь: слева 15 см до обрыва, справа 15 см до встречки. А навстречу летит такой же перепуганный Джо, в глазах которого читается молитва и полное непонимание габаритов. Самое смешное, что для управления этой махиной годятся наши обычные права категории B. Видимо, считается, что если ты смог сдать на «Ладе», то и сарай на колесах укротишь. Акустический комфорт (его нет) Автодом — это симфония разрушения. Ощущение, что везешь бабушку на дачу вместе со всем содержимым ее сарая. Где-то сзади ритмично лязгает эмалированное ведро, над ухом скрипит кровать, периодически что-то с грохотом падает. Езда по городам — отдельный тест на стрессоустойчивость. Видел австралийца, который к такому же автодому прицепил сзади легковушку на жесткой сцепке. Правда, они застряли на подъеме. Не уверен, что уровень стресса у них снизился, но попытка засчитана. Есть, конечно, вариант с прицепом-трейлером. Едешь в джипе, кайфуешь, а дом болтается сзади. Но туда нельзя посадить детей. Хотя... если у вас есть парочка запасных, то почему бы и нет? 🔜 В следующем посте расскажу, каково это — жить в коробке вчетвером и не убить друг друга.

Как сделать систему непригодной к использованию и назвать это гибкостью Еще разок про универсальщину. Попался прямо таки каноничный пример как делать не нужно. Итак, есть вендор. В их системе весомая часть действий — это документ (так исторически сложилось). Не важно, что происходит: создаём заявку, выполняем операцию, меняем состояние — всегда создаётся документ. Для всех документов используется универсальный интерфейс: мы указываем тип документа и передаём набор полей, который якобы его описывает. Примерно вот так:

POST /documents
{
  "type": "X",
  "field1": "...",
  "field2": "...",
  "field3": "а может и не нужно"
}

Звучит гибко, но на практике это превращается в проблему: - есть одна универсальная дата-модель, где все поля опциональные; - невозможно понять, какие поля нужно заполнять и как именно; - одно и то же поле может означать совершенно разные вещи в разных типах документов; - без нормальной документации (а её, как правило, нет) пользоваться этим почти невозможно. Ну и вишенка на торте — у документа может быть свой набор состояний или действий. Как результат — целый кабинет аналитиков и разработчиков пытается расшифровать что происходит и как с этим жить. Вывод простой: даже если внутри системы всё построено на документах — не делайте универсальные интерфейсы. Типизированные контракты и явные модели почти всегда выигрывают у гибкости ради гибкости.

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

This project is currently under maintenance and is not accepting new changes. 
For enterprise support and actively maintained versions, please see MinIO AIStor.

А ещё раньше они фактически убрали консоль администрирования (если я правильно понял), объяснив:

Honestly, it is hard to duplicate this work for the community branch…

Без обид — жестокие улицы Сан-Франциско каждый день требуют дозы Enterprise-лицензии. Но с опенсорсом хотя бы остаётся код: можно форкнуть, допилить, поддерживать сами или в сообществе. С коммерческим продуктом всё жестче: если компания закрылась — код ушёл вместе с ней в закат над Golden Gate. Обезопасить себя от всех рисков — задача нетривиальная и не всегда лежит в технической плоскости. Но если есть возможность — подстелите себе солому из исходников

Как я предлагал вернуть Монолит и сэкономить миллионы. Лично мне вариант с Redis понравился больше всего. Быстро, дерзко, молодежно. Но была одна проблема: Redis работает идеально ровно до тех пор, пока данные влезают в оперативку. Как только память заканчивается — карета превращается в тыкву. А постоянное переливание данных в Postgres через стримы выглядело как надежный, но все-таки костыль. И тут меня осенило. Я пришел к нашему Principal Engineer с Гениальным Планом™.

— Слушай, — говорю я с максимально серьезным лицом. — Я тут порылся в закромах Google Cloud. У них есть машина с 5 ТБ оперативной памяти. — И? — Стоит всего $10k в месяц. Я прикинул: туда влезут все наши данные года за три. Вообще всё. И никаких костылей с переливкой.

Диалог вышел коротким: PE:

— А через 3 года, я полагаю, ты уволишься? Я: — Зачем же? Через 3 года у Гугла появится инстанс на 7 ТБ. Просто переедем на него за ночь.

------ Самое смешное в этой машине — это процессор. Там 200+ ядер. А наш любимый Redis, как мы помним, однопоточный. Ему нужно 1.5 ядра: 1 ядро — крутить транзакции. 0.5 ядра — на IO и «на чай» операционной системе. Остальные 198.5 ядер будут простаивать. Хотя, почему простаивать? Можно запустить майнинг Биткоина. Глядишь, и стоимость аренды отобьем, и в финтех-отчетах покажем «альтернативные источники дохода». ------ В теории, на одну такую машину влезет весь наш немаленький банк. Целиком. Если перестать играть в микросервисы, Kubernetes и распределенные системы, а просто собрать честный, старый добрый Монолит. Ну ладно, для отказоустойчивости возьмем две такие машины. Master и Slave. Всё равно экономия на инфраструктуре выйдет раз в 10. Никаких сетевых задержек, никаких проблем с согласованностью, деплой простым копированием бинарника. Звучит как полный бред сумасшедшего. Или всё-таки нет? #Юмор

Финал: Битва баз данных. Кто стал сердцем банка? [В прошлых сериях]: нас отшил дерзкий стартап, мы обиделись и пошли пилить своё решение. Задача была простая, как кирпич: найти хранилище, которое выдержит наши амбиции. 🎯 Цель: — 100 TPS (транзакций в секунду) на один аккаунт (с блокировками). — 1000 TPS на рандомные аккаунты. Мы прогнали всех кандидатов через мясорубку нагрузочного тестирования. И вот результаты, от которых мы то плакали, то смеялись. 1. Postgres (Старый конь борозды не портит) Взяли его чисто как baseline, чтобы было с чем сравнивать. Вся логика строго на хранимках (Stored Procedures), один поход из приложения в базу. Результат: Один аккаунт: 1 300 TPS (В 13 раз больше требуемого! Мы слегка присели). Много аккаунтов: 9 000 TPS. Внезапно «скучный» SQL показал, что списывать его со счетов рановато. 2. Redis + Postgres (Форсаж) Схема: Редис считает математику в памяти, а потом стримами (Streams) скидывает данные в Постгрес на вечное хранение. Результат: Один аккаунт: 23 000 TPS. Много аккаунтов: 23 000 TPS. Ему вообще плевать. Редис однопоточный, ему все равно хоть один аккаунт, хоть много. Скорость света. 3. TigerBeetle (Тот самый стартап) Результат: Один аккаунт: 27 000 TPS. Много аккаунтов: 77 000 TPS. Обещанного миллиона мы не увидели, но цифры всё равно мощные. Правда, прямо посреди теста мы словили эксепшн:

Whoops, there is a bug in SDK…

Мелочь, а неприятно. Представили, как ловим этот «Whoops» в продакшене в «Черную пятницу», и перекрестились. 4. Google Spanner (Боль и унижение) Напомню, Гугл продавал нам это как «Решение Всех Проблем Человечества». Результат: Один аккаунт: 78 TPS. (Нет, я не забыл букву «K». Просто 78). Много аккаунтов: 870 TPS. (Тоже просто 870). Мы протерли глаза. Перезагрузили серверы. Цифры не изменились. Звоним в Гугл: «Ребята, что за фигня? Где обещанная магия?» Нам вежливо посочувствовали и выдали гениальные советы: - «А вы поставьте перед Спаннером Redis». (Спасибо, Кэп! А Спаннер тогда зачем?). - Скинули статью на Medium: «Какие костыли прикрутить, чтобы базы данных хоть как-то работало с hot accounts». - Рассказали вдохновляющую историю, как один банк реализовал на Спаннере... фичу кэшбека. (Кэшбека, Карл! Не леджера). Когда мы наконец прорвались через продажников к суровым технарям, те вздохнули и признались: «Ну да, сотню TPS выжмете, больше — вряд ли. Архитектура такая». Занавес. ------ Итоговое решение Мы выбрали Postgres. Почему: - Запас прочности: Он выдал 1300 TPS на один аккаунт при требовании в 100. Этого нам хватит на годы. - Надежность: Это скучная, предсказуемая технология. Никаких «Whoops» в SDK. - Архитектура: Мы спроектировали систему так, чтобы оставить перед Постгресом «Redis-shaped hole» (дырку в форме Редиса). - Если (или когда) мы вырастем до космических масштабов, мы просто вставим туда Redis, как деталь пазла. А пока — зачем платить сложностью за то, что старый добрый SQL делает бесплатно? А теперь предлагаю погуглить "Spanners British slang". В общем, хорошую штуку Спаннером не назовут

DIY для банка: выбираем базу данных, когда стартап нас отшил В предыдущей серии я рассказывал, как TigerBeetle — стартап нашей мечты — отправил нас во френдзону. Пришлось засучить рукава и делать «сердце» банка самим. Но на чем писать? Чтобы не было мучительно больно за бесцельно прожитые спринты, мы сформулировали требования. Задача: - 1000 TPS (транзакций в секунду) на рандомных аккаунтах. - 100 TPS на одного «жирного» клиента. С первым пунктом всё понятно: если руки растут из плеч, любая современная БД это вывезет. А вот второй пункт — это боль. Нужно заблокировать аккаунт, посчитать баланс, записать проводку и разблокировать. Арифметика беспощадна: 1 секунда / 100 транзакций = 10 мс на всё про всё. Тут уже на Python не попишешь, тут думать надо. В кастинг на роль «сердца» попали четыре кандидата: 1. Postgres (Классика) Старый добрый слон. Чтобы уложиться в 10 мс, всю логику придется зашивать в хранимки (Stored Procedures). Гонять данные туда-сюда между приложением и БД — непозволительная роскошь. Сомнения: Наша текущая система на MySQL выдает жалкие 7 TPS. Вендор клянется мамой, что это предел физики. Мы, конечно, умнее, но сможем ли мы быть умнее на порядок? Вопрос открытый. 2. Redis + Postgres (Безумный Макс) Идея для смелых: ставим Redis перед Постгресом. — «Но это же просто кэш!» — кричат пуристы. — «Подержите мое пиво», — отвечаем мы. Почему это круто: - Single-threaded: Редис однопоточный. Никаких гонок (race conditions). Атомарность из коробки. - Lua scripts: Логику можно исполнять прямо внутри памяти. Быстро, дерзко. - Надежность: У Редиса есть стримы. Можно реализовать Transaction Outbox паттерн без танцев с бубном, Kafka и Debezium. Данные льются в Postgres в фоне. - Персистенс: Да, вся база должна лезть в RAM. Но Редис умеет сбрасывать данные на диск и реплицировать на слейвы. Если настроить прямыми руками — надежно, как швейцарские часы. 3. TigerBeetle (Бывшая) Те самые ребята, которые нас отшили. Заявляют 1 000 000 TPS. Даже на один аккаунт. Звучит как сказка, но проверить надо. Вдруг врут? А если не врут — будем кусать локти (или снова проситься к ним). 4. Google Spanner (Швейцарский нож) Самый загадочный зверь. Спрашиваешь у Гугла, что такое Spanner, и тебе отвечают: «ЭТО ВСЁ». Хочешь SQL? Spanner. Хочешь Key-Value? Spanner. Графы? Spanner. AI? Разумеется, Spanner! Там скоро можно будет писать запросы в духе: «AI, проверь, хватит ли у юзера 123 денег на пиво, и если да — переведи». На презентации меня сдержало только хорошее воспитание, чтобы не спросить: «А блокчейн вы туда еще не впихнули?». Похоже, это единственное, чего там нет. Проблема: Это распределенная БД. Она сама решает, где хранить данные. Скорее всего, она раскидает счета по разным нодам, и каждый перевод превратится в multi-node transaction. А это медленно. Но Гугл так настойчиво поил нас кофе и водил по виски-барам, что мы решили дать Спаннеру шанс. Из вежливости. ------ Результаты эпичной битвы и реальные цифры нагрузочного тестирования — в следующем посте. А пока вангуем в комментариях. В каком порядке тулзы пришли к финишу (от лучшей производительности к худшей). И какую технологию выбрали бы лично вы? Кто будет ближе всех — тот настоящий HighLoad архитектор.

Мы в Satori тоже регулярно сталкиваемся с вендорами ПО. Раньше я как-то не особо обращал на это внимание… но теперь я просто в восхищении от того, как изящно устроен этот рынок. Узнал потрясающие вещи: - Оказывается, API можно смело поставлять без документации — вы же умные, сами разберетесь. - Можно брать деньги за доработки, а потом бодро сообщать: «Ну… не получилось». - На вопрос «почему столько багов и есть ли у вас тесты?» присылать набор юнит-тестов, сгенерированный вчера ИИ, причём таких, что они не проверяют вообще ничего. - Спокойно тестировать прямо на проде клиента — идеально же, всё под рукой. - Игнорировать вопросы даже в платной техпододдержке — бережём энергию. - На срочные запросы отвечать: «Единственный человек, который в теме, у нас сейчас в отпуске». - Требовать оплату за работы, которых в природе не существовало. - На просьбу о функциональности говорить: «Этого нет в нашем беклоге и никогда не появится». - Продавать «коробочное решение», которое по факту — франкенштейн из копролита, костыля и поделия джуна после курсов. - Обвинять заказчика, в том что он нормально задачу не ставит и не проверяет - И главное, абсолютный шедевр: подсадить клиента на «бесплатное решение», а потом элегантно выкручивать ему руки за доработки. Вот это я понимаю, бизнес-модель!

Тот неловкий момент, когда ты банк с 15 млн клиентов, а тебя френдзонит стартап. Операция на открытом сердце: как мы искали движок для банка Дано: Jago Bank. Представьте себе Тинькофф на третьем году жизни, только в Индонезии, в жаре и с дикими амбициями. Приходит к нам бизнес и с порога заявляет: — Ребята, мы тут планируем скромный рост. Было 15 миллионов пользователей, станет 30. Ну вы там подготовьтесь по-быстрому. Мы, как порядочные инженеры, пошли к нашему текущему провайдеру Core-системы: — Сдюжите? — Пфф, легко! — отвечают. — Мы вам просто второй инстанс рядом поставим. А вы уж там сами как-нибудь трафик между ними маршрутизируйте. И отчеты склеивайте руками. И вообще, крутитесь как хотите. В переводе с вендорского на человеческий это означало: «Fuck you». Мы намёк поняли. Осознали, что придется писать свою Core-систему (потому что кто, если не мы?). Самая мякотка там — это Ledger. Место, где живут все бухгалтерские проводки. Нам нужно переваривать около 1000 операций в секунду и не подавиться. Но прежде чем садиться кодить велосипед, решили глянуть на рынок. Вдруг можно что-то укра... кхм, купить? Натыкаемся на TigerBeetle. Это молодой стартап, который запилил не базу данных, а какой-то звездолёт на стероидах. Ребята дистиллировали саму суть финансовых проводок и выдали решение с космической надежностью и скоростью. Читаешь документацию и плачешь от счастья — видно, что люди знают домен лучше, чем свои пять пальцев. Мы загорелись. Пишем им письмо, полное надежды и уважения: «Привет! Мы банк, у нас 15 млн юзеров, растем до 30. Ваше решение — пушка. Мы почти готовы его ставить. Давайте знакомиться и работать!» Ответ от стартапа приходит такой, будто мы у них мелочь у метро попросили: «"Почти готовы" не считается. Вот когда решите на 100% — тогда и пишите. До связи». Мы слегка офигели, но виду не подали. Пишем еще раз: «Ребят, ну скажите хоть сколько стоит? Бюджет-то планировать надо». Ответ: «Сначала поклянитесь на крови, что берете нас, а потом мы вам ценник выкатим». А теперь следите за руками. В это же самое время Google, у которого денег больше, чем у Бога, водит вокруг нас хороводы. Кормит бесплатными обедами, поит спешелти-кофе и присылает десант из Solution Architect’ов, которые в красках расписывают, как их Spanner идеально нам подходит. Google прямым текстом говорит: «Пацаны, мы сделаем всё, лишь бы ваш financial ledger крутился на наших технологиях. Хотите массаж стоп? Только скажите». Выводы делайте сами: То ли у Гугла так много денег, потому что они нанимают толковых продажников. То ли они нанимают толковых инженеров, поэтому у них много денег, и они могут позволить себе унижаться перед клиентом. А может, TigerBeetle просто знают, что их код настолько хорош, что это мы должны водить вокруг них хороводы. З.Ы. «На самом деле, поведение стартапа — это отличный стресс-тест, который они провалили. Если они так ведут себя на этапе продажи, когда все обычно улыбаются и машут, то представьте, что будет, когда у нас в 3 часа ночи ляжет прод? Google, может, и не "звездолет", но у них хотя бы есть телефон, по которому можно наорать на живого человека».

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

Мы тут периодически прокачиваем наши курсы — и настало время небольшой калибровки. Для этого нам нужны примерно 5-10 добровольцев, которые готовы поучаствовать в коротком созвоне (30-40 минут). Что будет на созвоне: Мы позадаём несколько простых вопросов о наших продуктах - что актуально прямо сейчас, где болит и т.д. Это помогает нам держать курс в тонусе и развивать его туда, где он действительно полезен. Что получите вы: После вопросов — ваша очередь. Можете рассказать о своей текущей задаче, проблеме или боли: технической, рабочей, карьерной — любой. Мы внимательно послушаем и дадим рекомендации: что сделать, куда копать, как можно ускориться или вырулить из тупика. Условия: 1. Вы не проходили наш тренинг «Разработка без боли и сожалений» 2. Вы занимаетесь коммерческой разработкой бекенда 3+ лет Созвон короткий, формат дружелюбный, польза — взаимная. Если хотите присоединиться — перейдите по ссылке и оставьте контакты с описанием пробелемы, мы всё организуем.

Видео vs текст Как настоящий дед при разборе душных тем, я обычно выбираю текст — книги, статьи, любые буквы. Удобство быстро прыгать между абзацами, видеть всю картину целиком и благородный шелест страниц для меня всегда были плюсом. Но в последнее время ловлю себя на мысли, что иногда видосы всё же выигрывают. Формат текста ограничен: схемы, которые автору кажутся очевидными, читателю часто выглядят как «угадай что я имел в виду». В видео же можно рассмотреть детали, которые в тексте либо опускают («да это же капитанщина»), либо запихивают в такой формат, что толком ничего не разобрать.

Смотрел код — и заметил прекрасное. Зацените, как там проверяется время:

event.createdAt.truncatedTo(ChronoUnit.SECONDS) shouldBe OffsetDateTime.now().truncatedTo(ChronoUnit.SECONDS)

То есть просто отрезают миллисекунды в надежде, что тест «успеет» в ту же секунду. А если через миллисекунду тикнет новая? Ну да, можно же начать резать минуты… или часы… Так и рождаются моргающие тесты, которые то проходят, то падают — чистое веселье. Что с этим делать? Нормальный путь — зафиксировать время через Clock.fixed() или Clock.offset() и передавать этот Clock внутрь всего, что генерирует OffsetDateTime.now(clock). Красоты мало, зато: • время контролируется снаружи; • тесты становятся предсказуемыми; • и никто больше не бегает от внезапно наступившей секунды. Если же душа просит простых и понятных решений, в JUnit можно тупо повторять тест несколько раз. Прокатило один раз — и ладно, галочка зелёная. Ещё вариант: не сравнивать даты напрямую, а мерить Duration.between(…) и проверять, что разница в пределах пары миллисекунд. А когда CI сервер начнет тормозить и тесты снова станут моргать — добавите еще пару секунд, делов то. Ну и последний способ — попробовать замокать статический метод now(), если сможете конечно. P.S.: Если понадобятся дополнительные лайфхаки по созданию говнокода — зовите, всегда рад помочь.

🔧 Немного закулисья нашей разработки Редко удаётся рассказать — и тем более показать — детали рабочих процессов. Обычно всё покрыто коммерческой тайной. Но сегодня хочу приоткрыть занавес и поделиться тем, над чем мы работаем. Интеграции — это огромный пласт работы между системами, несмотря на кажущуюся простоту. Постоянное перекладывание данных, развешивание JSON’ов и выпиливание XML’ей лобзиком. Мы пробовали автоматизировать это стандартными агентами, курсорами и другими универсальными инструментами. Фиксировали правила, добавляли ограничения — но идеального результата не получили. И честно говоря, я не разделяю всеобщих восторгов по поводу ИИ-тулзов общего назначения: да, в части случаев они экономят время, но количество допилок напильником там порой слишком велико (в последнее время я прям таки заставляю себя ими пользоваться, чтобы понять ограничения). Иногда проще вручную запилить, нежели объяснять электронному болвану что от него требуется. А ещё есть важная проблема — многие из этих агентов отправляют данные непонятно куда, а далеко не каждая компания может позволить себе делиться внутренней информацией с внешними сервисами. Поэтому мы делаем ставку на другое: узкоспециализированную систему, заточенную под конкретный фреймворк и конкретные задачи интеграции. Вот, даже лендос склепали. Наш подход — максимально декомпозировать каждый шаг, а то что можно сделать обычными алгоритмами — сделать ими и не выпендриваться. Так можно выжать максимум даже из относительно слабых моделей, которые легко развернуть на своей инфраструктуре. Но чтобы заставить модель уверенно решать даже узкую задачу, приходится серьёзно повозиться: продумывать промпты, писать на них тесты и т.д. В идеале мы хотим прийти к циклу обратной связи, где модель сама исправляет свои ошибки, а участие человека сводится к минимуму (хотя полностью это невозможно ввиду природы LLM). Система у нас состоит из двух ключевых модулей: 1. Генератор кода 2. Фреймворк с четкой структурой, в который этот код встраивается На вход подается описание желаемого выхлопа, а так же документация целевых систем. На выходе — код, который реализует желаемую интеграцию, встроенную в фреймворк. Сейчас я работаю над промптами, тестирую разные подходы и собираю первые результаты. И — что приятно — кое-что уже начинает работать (по крайней мере мне так кажется). В следующих постах расскажу подробнее, что получилось, какие грабли встретились, и как вы сможете применить эти идеи у себя. Продолжение следует 👇

Когда-то давно мне приспичило разобраться как работает Linux. Нашёл Linux From Scratch — проект, где ты буквально собираешь систему с нуля. Но это упоротый вариант. В итоге я остановился на Arch Linux — почти как Gentoo, только без бесконечной пересборки мира. Поднимал сети вручную, вкорячивал модули ядра, правил grub.cfg, шаманил с udev и драйверами. Естественно, сейчас я уже всё это забыл и зову админа чтобы подключить сетевой кабель. Но тогда, когда я занимался прошивками и разрабатывал под Linux, это дало мне дикий буст к пониманию того, как система устроена изнутри. И вот это как раз пет-проект класса «Минимализм» — когда ты воссоздаёшь базовый слой, чтобы прочувствовать механику. Но есть опасность — после таких экспериментов у вас может прорасти свитер