BASCODE

Рубрика «Гикуем».

Немного доработал прошивку сплита. Теперь радуюсь кастомной анимацией :-)

Сегодня в команде была дискуссия про конфиги.

У нас несколько сервисов, и rate limit на каждом настраивается отдельно. Сейчас их немного, но через год будет в разы больше, и крутить лимиты руками в десяти местах это боль. Проблема настоящая.

Один из предложенных вариантов - единая админка: одно место, где хранится конфиг всех сервисов, оттуда всё и рулим. Звучит удобно. Но так делать нельзя.

Главная причина вот в чём. С rate limit ещё понятно, он у всех плюс-минус одинаковый. Но у каждого сервиса свой набор конфигурации, и в общую админку всё не перенесёшь. А раз так, то половина настроек живёт в админке, половина в самом сервисе. Размазать конфигурацию одного сервиса по двум платформам это настоящий ужас. Конфиг сервиса должен лежать в одном месте, а не делиться по принципу «это успели вынести, а это нет».

Сверху ещё пара рисков. Кривой конфиг, разосланный из центра, кладёт все сервисы разом: так положили 8.5 млн машин в CrowdStrike в 2024, не баг в коде, а плохой конфиг из одной точки. Плюс единая панель стирает границы доступа: кто крутит настройки одного сервиса, технически дотянется до всех.

С самой целью всё в порядке. Проблема в реализации.

Решение: централизуй не рантайм, а управление. Конфиг лежит как код в гите рядом со своим сервисом, меняется через PR с ревью и валидацией схемы, катится пайплайном. Одно место правок на сервис, полный аудит, откат одним revert. Enforcement остаётся локально с fallback. Упал "центр", сервис живёт на последнем валидном конфиге.

Хочешь спокойно дорасти до десяти сервисов? Дай им общий стандарт конфигурации, а не общее хранилище. Стандарт масштабируется, общая база только копит проблемы.

Читаемость UUID, миф или реальность?

Смотрю на UUID в URL и морщусь: 36 символов с дефисами, красота и уродство.

/orders/550e8400-e29b-41d4-a716-446655440000

В феврале услышал в подкасте про Base32 и залип на пару вечеров. Думал, дело на пять минут: перекодировал те же 128 бит в другой алфавит, и вот тебе короткий id. Те же 16 байт, ничего не сжимается, коллизии те же. Просто другое представление.

И правда красиво выходит, 26 символов вместо 36:

/orders/AM788072KD0X99RP8HK5AH0000

Берешь Crockford-алфавит (автор который придумал JSON), а он выкинул I L O U, чтобы не путать с единицей и нулем и не собирать случайные матерные слова. Такой ID не стыдно продиктовать по телефону.

А дальше я наступил на грабли. Думал, Base32 он и есть Base32. Ага... Конечно...

Взял стандартный RFC4648 (A-Z2-7) и сломал сортировку. Значение 25 это Z, 26 это 2, а в ASCII 2 идет раньше Z. Для UUIDv7, где время в старших битах, это больно: вроде сортируешь по времени, а строки разъезжаются как попало.

Лечится сменой алфавита: Crockford или base32hex (0-9A-V), и порядок строк снова совпадает с хронологией.
Собственно, в ULID ровно так и сделано: 128 бит, 26 символов, Crockford, сортировка по времени из коробки.

Что в итоге: в стандартной либе Go этого нет, нужен свой кодек, и БД такой ID за UUID не примет. Так что либо берешь готовый ULID, либо пишешь Encode/Decode сам и не путаешь алфавиты, как я :-)

Ответ на заданный в заголовке вопрос: Скорее миф, чем реальность...

В прошлом году я был на Испае. Этой весной решил повторить. Только в этот раз я со своей командой.

В общем и целом было также сложно, может даже сложнее. Но в этот раз я уже не плакал.

Наверное это прогресс…

Поварская книга по Кафке... Несколько подписчиков написали, что папки на github читать неудобно, попросили сделать сайт.

Как тут отказать. В век AI это вечер-два работы и пара долларов на токены.

https://dsbasko.github.io/kafka-cookbook

Внутри всё то же: продьюсеры, консьюмеры, группы, партиции, идемпотентность, exactly-once, транзакции, retry, DLQ. Просто открыл, выбрал тему, читаешь.

Пользуйтесь :-)

В прошлом году я писал, что больше не читаю книги по программированию. Пока книгу пишут, технология успевает устареть. Учусь иначе: исходники, подкасты, документация.

С какихто пор практикую ещё один способ - Claude собирает мне полноценный курс с примерами кода на Go, которые можно запустить и потрогать.

Сейчас мы внедряем в проект кафку, собрал для команды такой курс. Давно ничего не писал, по этому решил выложить в опенсорс и написать об этом пост.

https://github.com/dsbasko/kafka-cookbook

Внутри основные темы: продьюсеры, консьюмеры, группы, партиции, оффсеты, идемпотентность, exactly-once, транзакции, retry, dead letter queue. Каждая тема это отдельная папка с рабочим Go-кодом, README и docker-compose.

Запускаешь, открываешь нужную папку, читаешь код, гоняешь сценарии. За пару вечеров проходишь то, на что в книге уйдёт месяц.

Главное, что материал получается под твой уровень и твой стек. Книга пишется для всех, AI пишет для тебя.

Я часто пишу про то, что за AI-агентом нужно проверять. Кто закоммитил - тот и отвечает...

Окей, а как именно проверять?

Первый вариант: принимать каждое изменение вручную. Читать каждый кусок, задавать вопросы, разбираться на лету. Работает, но убивает весь смысл делегирования. Ты тратишь столько же времени, сколько писал бы сам.

Второй: дать агенту закончить задачу целиком, а потом сесть и провалидировать результат. Это эффективнее. Но тут возникает вопрос: через что смотреть?

IDE покажет diff. Но я работаю в консоли. Claude Code, терминал, клавиатура. Переключаться в IDE ради ревью - это разрыв потока.

Нашёл revdiff. TUI-тулза на Go, открываешь прямо в терминале. Показывает diff с подсветкой синтаксиса, word-level изменения внутри строк, навигация по хункам. Главное можно аннотировать любую строку прямо в процессе. Нажал a на подозрительной строке, написал комментарий, пошёл дальше.

На выходе структурированный список замечаний в stdout. Его можно скормить обратно агенту как инструкцию на доработку.

revdiff HEAD~1

Одна команда и ты в ревью. Без IDE, без переключения контекста.

https://github.com/umputun/revdiff

Разработчиков заменит AI? Нет. Заменят тех, кто отказывается с ним работать.

Перед инженером никогда не стояла задача "написать код". Задача была запустить продукт, который работает быстро, надёжно и решает реальную проблему бизнеса (что бы мы не называли бизнесом). Код - один из инструментов.

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

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

Ещё бонус: пока AI берёт на себя рутину, у тебя появляется время копать глубже в технологии, быстрее становясь профессионалом.

P.S. Бояться стоит другого - инженера, который копирует ответы из ChatGPT не читая. Вот это деградация. Но такие были и во времена Stack Overflow.

Теория против практики

Пост пролежал в черновиках с прошлого лета. Все же решился выложить. В тот период у меня случился конфликт с новым коллегой. В команде уже был устоявшийся стиль написания кода, проверенная архитектура и паттерны. Он пришел и решил все сделать по-своему.

На ревью спорил до упора. Ссылался на книги, доклады, рассказывал что это "best practices" и "так принято в командах у больших игроков". Шаг за шагом выводил меня из себя. В какой-то момент я сорвался и повысил тон. Да, проявил слабость, но эмоции прорываются - я ведь не робот.

Его аргументация строилась не на пользе для проекта, а на "так пишут" и "так делают в других компаниях". Но у каждой команды свои вводные: технологии, сроки, опыт инженеров, специфика бизнеса. То, что сработало где-то, может не подойти в конкретной реальности. То что было эффективно в Google или Amazon, у нас может навредить.

Я за изменения, если они несут реальную пользу. Но аргумент должен звучать как "это поможет нам решать задачи лучше, потому что ...", а не как "так написано в книге".

Теория без поправки на практику - красивая, но бесполезная догма.

Вибро-кодирование у большинства выглядит так: скормил промпт, получил код, запустил, сломалось, починил руками, повторил. Хаос с AI-обёрткой.

Get Shit Done (GSD) - фреймворк, который превращает это в конвейер. Ставишь как скилл в Claude Code, и вместо "напиши мне фичу" получаешь полный цикл: обсуждение -> планирование -> исполнение -> верификация.

Под капотом 16 специализированных агентов. Один исследует кодовую базу, другой пишет план, третий выполняет задачи параллельными волнами, четвёртый проверяет результат. Каждый запускается с чистым контекстом, а это значит что на сотой задаче модель работает так же, как на первой.

Но меня зацепило другое. GSD учит тебя собой пользоваться прямо через Claude Code. Пишешь /gsd:help - получаешь гайд, дока с которой можно пообщаться. Пишешь /gsd:next - он сам определяет следующий шаг. Не нужно читать доку на 40 страниц, CLI сам ведёт по процессу. Мета-подход: AI-инструмент, который объясняет как им пользоваться через AI.

Про GSD рассказал мой хороший друг - shakhzodme.

https://github.com/gsd-build/get-shit-done 🔗

Продолжаем...

Dialectic проверяет решения. Brainstorm помогает их спроектировать. Оба дают на выходе план. А дальше нужно сесть и написать код.

Задач в плане набралось на 5-6 часов. Контекст Claude деградирует достаточно быстро, ты устаёшь контролировать каждый шаг. Нужен инструмент, который возьмёт готовый план и выполнит задачи сам.

Ralphex - standalone CLI от того же umputun. Не плагин, отдельный тул для тех у кого большие лимиты.

Пишешь план в markdown со списком задач с чекбоксами. Запускаешь ralphex, указываешь файл. Дальше он сам: берёт задачу, запускает Claude Code в свежей сессии, выполняет, коммитит, берёт следующую. Каждая итерация - чистый контекст. На пятидесятой задаче модель работает так же чётко, как на первой.

Тул не простой, есть четыре фазы. Сначала выполнение, ralphex читает план, находит незакрытые чекбоксы, делает по одной задаче за итерацию. Потом ревью, Claude в отдельной сессии смотрит весь код, цикл повторяется пока есть замечания. Дальше внешний ревью через codex или кастомный инструмент. И финализация rebase, squash, тесты.

Запускал на текущем пет-проекте (Пилю аналог литкода для задач по тонкостям Go. Скоро выложу в опенсорс, бесплатно без регистрации и смс), прошел через 8 часов автономной работы.

Для потоковой кодогенерации, когда задач много и план детальный - лучший инструмент из тех, что пробовал.

Ставится через brew или go install. Детали в репозитории.

https://github.com/umputun/ralphex 🔗

Ну пи**ец!

Dialectic проверяет решения после того, как ты их принял. Brainstorm работает до - помогает принять правильное.

Второй инструмент из cc-thingz.

"Надо добавить кеширование." Открываешь редактор, пишешь Redis-обёртку. Через два дня понимаешь, что надо было кешировать на другом уровне. Или что кеширование вообще не нужно, а тормозит кривой запрос.

Brainstorm не даёт сразу кодить. Сначала читает код проекта, потом задаёт вопросы. По одному. "Что именно тормозит?", "Какой паттерн инвалидации?", "А замеры делал?". Те вопросы, которые ты сам себе не задал.

Четыре фазы: собирает контекст, предлагает 2-3 подхода с trade-offs, валидирует дизайн по частям, выводит на план или реализацию. На каждом шаге спрашивает, не улетел ли в сторону.

Поставить:

/plugin marketplace add umputun/cc-thingz
/plugin install brainstorm@umputun-cc-thingz

Дальше: /brainstorm:do <твоя идея>

github.com/umputun/cc-thingz 🔗

Начинаю серию постов про AI-инструменты, которые реально использую в работе. Без маркетинга, только то, что прижилось.

Первый - dialectic из cc-thingz (моего краша umputun) для claude code.

Проблема, которую замечал за собой: принимаешь архитектурное решение и начинаешь неосознанно искать аргументы в его пользу. Confirmation bias в чистом виде.

Dialectic решает это в лоб. Даёшь утверждение, например: "нам стоит перейти на event-driven архитектуру". Запускаются два параллельных агента: один ищет всё, что подтверждает, второй всё, что опровергает. Потом собирает вывод и проверяет по коду - конкретные файлы и строки.

Перестаёшь защищать идею и начинаешь проверять.

Использую для архитектурных решений и оценки рефакторинга.

Поставить себе просто. Введи в claude code:

/plugin marketplace add umputun/cc-thingz
/plugin install thinking-tools@umputun-cc-thingz

Дальше: /thinking-tools:dialectic <твоё утверждение>

https://github.com/umputun/cc-thingz

Рубрика - лысая мудрость!

Есть настольная игра Go. Одна из древнейших стратегий. Правила простые: захватывай территории, окружай камни.

Лучшие игроки намеренно жертвуют своими камнями. Видят, что группа не спасётся, и вместо того чтобы тратить ходы на безнадёжное - отдают часть доски. И выигрывают в другом месте.

В 2016 AlphaGo обыграл чемпиона мира. Аналитики разбирали партии и удивлялись: ИИ отдавал территории так, как ни один человек не решился бы.

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

P.S. Про все это услышал сегодня в подкасте. Не перестаю удивляться как подкасты вовремя подкидывают темы и метафоры...

Коллеги начали открыто пользоваться AI-инструментами для написания кода.

Мне кажется что есть два типа лидов:

Первый - запретитель. "это не твой код", "ты не понимаешь что он делает", "за что тебе платят?". Страх потери контроля, замаскированный под заботу о качестве.

Второй - наставник. Не запрещает, а помогает использовать эффективнее. Объясняет, на что смотреть в сгенерированном коде. Подстраивает ревью под то, как код теперь пишется.

Недавно стал замечать, что от коллеги начали приходить MR с вылизанным кодом, покрытием тестами и описанием, которое наконец отвечает на три вопроса: что сделано, почему, как тестировать. Код доставляется быстрее. В багах разбираться проще. Это результат развития, а не угроза.

Мне кажется что чистый вайб-кодинг с промптом "сделай хорошо" все еще невозможен. Умение работать инструментами с AI тоже нужно развивать, и развивается оно не быстро. Человек учится на своих ошибках, а AI совершает одни и те же ошибки. Нужно расти самостоятельно и наращивать экспертизу своих AI тулов.

Единственное что я повторяю: инструмент не пишет объяснительную за сломанный прод. Кто закоммитил - тот и отвечает. AI написал код - ты его принял, ты за него в ответе.

На улице веснеет.

Птички, солнце, хочется открыть окно. Окно я конечно не открыл, но...

Дальше буду выебываться так, будто я инфлюенсер.

Проснулся в 6 утра, выпил витамины и пошел на тренировку. Встал на беговую, смотрю в даль, а там мало что видно.

IQAir на Юнусабаде показал выше 200. Жаль не успел заскринить. К восьми уже упал до 160.

На календаре зима, на улице весна. А воздух такой грязный, что его можно потрогать...

Сборщик мусора не собирает мусор.

Парадокс прямо в названии. Он определяет, какие объекты ещё нужны, и сохраняет их. Всё остальное - стирает.

Наверное стоит так дома шкаф разобрать. Не мучиться выбором а вдруг надену. Просто отложить то, что точно носишь, а остальное на удаление...

Конец прошлого года сломал мне многие привычки. Те самые, которые выстраивал месяцами. Утренние тренировки, режим, ритм - всё посыпалось.

С января пытаюсь собрать себя обратно. Начинал, бросал, начинал снова. Каждый раз хватало на пару дней.

Летом я писал, что дисциплина важнее мотивации. Красиво звучит, когда всё идёт по плану. А когда план разваливается - остаёшься один на один с собой, без привычки и без мотивации.

Сегодня снова пришёл в зал. Первая тренировка после почти месяца прогула. Прошла хорошо.

Это не первая попытка в этом году. Но первая публичная. Раньше начинал молча и так же молча сливался. В этот раз решил написать сюда. В конце концов этот блог и задумывался как инструмент саморефлексии - может, если проговорить вслух, будет сложнее слить в тишине.

День первый. 07:00 - 08:00 отработано! Посмотрим...

У меня два мака и Linux. На каждом fish, neovim, kitty, aerospace и т.д. И каждый раз при настройке новой машины один и тот же ритуал: открываешь старый мак, ищешь конфиг, копируешь, адаптируешь. В общем и целом это боль...

Можно конечно решить это симлинками и гитом, но адаптировать всеровно придется...

Недавно наткнулся на chezmoi и за вечер перетащил туда всё. Добавляешь конфиги, они хранятся в git-репозитории. На новой машине две команды и всё на месте.

Отдельно порадовали шаблоны. Один файл конфига, но с условиями под разную ОС. На маке один путь, на Linux другой. Не надо хранить три копии одного файла и помнить чем они отличаются.

Написан на Go, кстати. Один бинарник, ноль зависимостей. Установил и работаешь.

Рекомендую как минимум для ознакомления.

https://github.com/twpayne/chezmoi