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

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