Отвечаем на самый волнующий вопрос при запуске новых проектов, MVP и стартапов. Приятного просмтра!

YouTube | ВК

Хочется почитать какую-нибудь стоящую книгу по разработке или около-разработческой тематике.
Что можете порекомендовать из относительно новых?

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

Youtube | ВК

Хотите кек? Попалась недавно система, где первичный ключ — это персональные данные (не буду говорить какие, потому что вендор себя опознает). Ну а чё, гениально же! Зато сразу понятно, кто есть кто — никакой анонимности, никаких лишних UUID. Правда, теперь все интеграции должны соблюдать законы о ПДн, проходить аудиты и жить по регламентам. Зато — очень удобно. А главное — персональные данные ведь никогда не меняются, да?

Лайтовый видос про набор паттернов, который мы используем для самообразования и получения максимального выхлопа. Несмотря на кажущуюся простоту и очевидность, бустануться можно очень неплохо. Приятного просмотра!

YouTube | ВК

Недавно наткнулся на codecrafters.io — прикольный сервис, где можно с нуля реализовать всякие штуки вроде Redis, Git, SQLite и прочее непотребство.

По нашей классификации это пет-проекты класса «Минимализм» — когда ты не строишь продукт, а воссоздаёшь готовую технологию, чтобы понять, как она устроена внутри.

Каждое задание там — это разбор под капотом: сетевые протоколы, файловые форматы, системы хранения, парсеры и всё то, что обычно «просто работает».

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

Я юзал с целью "освоить незнакомый язык на реальном проекте", мне понравилось. Из прикольного - все проекты делаются по baby steps (например, Redis начинается с задания "сделайте TCP-сервер, который отвечает PONG на PING на нужном порте), это сильно помогает постепенно въехать в новую технологию. Из не очень прикольного, но по-своему полезного - в заданиях обычно пишут, что делает, но практически не дают пояснений, как; если непонятно, приходится лезть в документацию, в другие решения, которые там же можно посмотреть, или спрашивать у ChatGPT). Бесплатно дают доступ к одному проекту, который меняется каждый месяц, плюс, когда они добавляют новый проект, у него есть период бета-тестирования, когда он тоже бесплатен.

Когда-то давно мне приспичило разобраться как работает Linux. Нашёл Linux From Scratch — проект, где ты буквально собираешь систему с нуля. Но это упоротый вариант.

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

🔧 Немного закулисья нашей разработки

Редко удаётся рассказать — и тем более показать — детали рабочих процессов. Обычно всё покрыто коммерческой тайной. Но сегодня хочу приоткрыть занавес и поделиться тем, над чем мы работаем.

Интеграции — это огромный пласт работы между системами, несмотря на кажущуюся простоту. Постоянное перекладывание данных, развешивание JSON’ов и выпиливание XML’ей лобзиком. Мы пробовали автоматизировать это стандартными агентами, курсорами и другими универсальными инструментами. Фиксировали правила, добавляли ограничения — но идеального результата не получили.

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

Поэтому мы делаем ставку на другое: узкоспециализированную систему, заточенную под конкретный фреймворк и конкретные задачи интеграции. Вот, даже лендос склепали.

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

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

Система у нас состоит из двух ключевых модулей:
1. Генератор кода
2. Фреймворк с четкой структурой, в который этот код встраивается
На вход подается описание желаемого выхлопа, а так же документация целевых систем. На выходе — код, который реализует желаемую интеграцию, встроенную в фреймворк.

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

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

Продолжение следует 👇

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

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.: Если понадобятся дополнительные лайфхаки по созданию говнокода — зовите, всегда рад помочь.

Типичная разработка

Видео vs текст

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

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

Мы тут периодически прокачиваем наши курсы — и настало время небольшой калибровки. Для этого нам нужны примерно 5-10 добровольцев, которые готовы поучаствовать в коротком созвоне (30-40 минут).

Что будет на созвоне:
Мы позадаём несколько простых вопросов о наших продуктах - что актуально прямо сейчас, где болит и т.д. Это помогает нам держать курс в тонусе и развивать его туда, где он действительно полезен.

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

Условия:
1. Вы не проходили наш тренинг «Разработка без боли и сожалений»
2. Вы занимаетесь коммерческой разработкой бекенда 3+ лет

Созвон короткий, формат дружелюбный, польза — взаимная. Если хотите присоединиться — перейдите по ссылке и оставьте контакты с описанием проблемы, мы всё организуем.

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

Тот неловкий момент, когда ты банк с 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, может, и не "звездолет", но у них хотя бы есть телефон, по которому можно наорать на живого человека».

Мы в Satori тоже регулярно сталкиваемся с вендорами ПО. Раньше я как-то не особо обращал на это внимание… но теперь я просто в восхищении от того, как изящно устроен этот рынок. Узнал потрясающие вещи:

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

Вот это я понимаю, бизнес-модель!