Доверяй, но сверяйся с реальностью

Сейчас будет много саморефлексии, обещаю что про технологи посты пойдут дальше.

Есть один урок, который я периодически переучиваю заново. Казалось бы, простая истина, но почему-то каждый раз приходится набивать шишку. Доверие штука хорошая. Без него невозможно строить команду, делегировать, расти. Но есть тонкая грань между "я тебе доверяю" и "я закрыл глаза и надеюсь на лучшее". Первое - это осознанный выбор. Второе - это лень проверять свои ощущения фактами.

Горящие глаза, правильные слова, энтузиазм на старте? всё это здорово. Но единственное, что реально показывает человека - это результаты. Не обещания, не объяснения, не "вот-вот разберусь". Результаты.

Если их нет месяц - это повод задать вопросы. Если их нет три месяца - это уже ответ.

Мысль-напоминание самому себе: Вера в человека - это аванс. Но любой аванс рано или поздно нужно закрывать делами.

Как и обещал, пишу пост технический. Надеюсь лично для тебя полезный. Сначала хотел коротко описать в ТГ как это реализовать, но в итоге все так раздулось, что пришлось выложить в качестве статьи. Ну так вот, написал статью на Хабр о том, как организую SQL-запросы в Go-проектах.

Если коротко: все запросы одной сущности храню в одном .sql файле с маркерами -- name: QueryName. Загружаю через go:embed, получаю по имени через геттер. Репозиторий остаётся чистым, SQL с нормальной подсветкой в IDE.

В статье разобрал:
* Реализацию парсера на регулярках
* Сравнение с Query Builder, inline SQL и подходом "файл на запрос"
* Когда этот паттерн уместен, а когда лучше взять что-то другое

Это не претензия на серебрянную пулю, просто один из подходов, который хорошо работает для типовых CRUD-операций. Для динамических отчётов по-прежнему беру squirrel или другой sql билдер.

https://habr.com/ru/articles/978974/

В пятницу на круговой тренировке снова чуть не выплюнул сердце. Тренер гоняет жёстко, думал просто адаптация, потерпеть надо. Но в какой-то момент вспомнил: на руке же часы, они что-то там меряют. Глянул, а там пульс 190 :-)

Сегодня подошёл умнее: перед каждым кругом опускал пульс до 130-135, после круга пульс поднимался до 170-180. Совсем другие ощущения. Тренировка прошла нормально, без предсмертных переживаний.

И тут накрыло осознание: мы же в работе точно так же делаем. Обмазываемся логами, настраиваем метрики, разворачиваем мониторинг, рисуем красивые дашборды… а потом месяцами на них не смотрим. Пока прод не начнёт "выплёвывать сердце" :-)

P.S. Берегите себя. И настройте алерты наконец.

В дополнение к посту, автор сделал веб версию карты покрытия тестами.

Вы туда можете скормить в неё свой coverage.out или посмотреть пример предзагруженных hugo, chi или gin.

https://nikolaydubina.github.io/go-cover-treemap/

Сегодня у меня такой сетап ))

Недавно начал писать unit-тесты для storage слоёв.

PostgreSQL, Redis, всякие внешние хранилища. То, что обычно остаётся без покрытия, потому что "ну там же база, как это тестировать без базы?", ну или интеграционные/e2e тесты.

Сегодня напишу про PostgreSQL. Использую github.com/pashagolub/pgxmock/v4. 500+ звезд, мокает интерфейс pgx, репозиторий думает что работает с базой.

Выглядит все просто:

mock, _ := pgxmock.NewPool()

// SELECT
rows := mock.NewRows([]string{"id", "name"}).
    AddRow(1, "Дима")
mock.ExpectQuery("SELECT").WillReturnRows(rows)

// INSERT
mock.ExpectExec("INSERT INTO users").
    WithArgs("Дима", "dima@mail.com").
    WillReturnResult(pgxmock.NewResult("INSERT", 1))

// Ошибка
mock.ExpectQuery("SELECT").
    WillReturnError(errors.New("connection refused"))

Что проверяем: SQL запросы, параметры, обработку ошибок, маппинг в структуры.

Что НЕ проверим: реальную работу SQL, совместимость с версией PG, производительность. Для этого нужны интеграционные или e2e тесты.

https://github.com/pashagolub/pgxmock

Поставьте автору звездочку на github, если моки вам полезны. Ему будет приятно 😊

А как вы работаете с дисциплиной?

2025 год стал для меня временем баланса между масштабными инженерными вызовами и личным развитием.

В профессиональной сфере ключевым вектором была цифровизация медицины Узбекистана во главе команды UZINFOCOM.
Год прошел под знаком внедрения стандартов FHIR и HL7, включая обучение у мировых экспертов и признание со стороны создателя FHIR Грэма Грива.

Технические итоги канала:
• Активное развитие в экосистеме Go: разбор релиза 1.25, публикация статьи на Хабре об организации SQL-запросов и использование инструментов визуализации покрытия тестами.
• Рассказ подхода к обучению: отказ от быстро устаревающих книг в пользу изучения исходного кода, документации и профильных подкастов.
• Анонс бесплатного YouTube-курса по разработке сервиса на Go, который я в итоге захолдил, чтобы сдать текущие проекты.

Личное и дисциплина:
• Запуск Telegram-блога как инструмента саморефлексии.
• Ставка на самодисциплину и энергетический менеджмент: внедрение силовых тренировок в 7 утра и переход на гибридный формат работы.
• Личные вехи: 35-летие, радикальная смена имиджа и сборка мощного рабочего ПК на Linux.

Главный вывод года: дисциплина важнее мотивации, и доверие к людям должно быть заслуженно действиями, а не привязанностью к ним.

P.S. Постер сгенерирован ЭйАй, с событиями канала.

Всем привет!
Первый пост в этом году будет посвещен выходу Go 1.26!

Официальные релизноты довольно скудны на детализацию и приходится изучать глубже. Я в процессе последних правок статьи для habr к которой шел несколько месяцев! Изменения затрагивают runtime, компилятор, стандартную библиотеку и поддержку платформ. Команда Go сосредоточилась на производительности и удобстве разработки.

Главное изменение: Green Tea становится сборщиком мусора по умолчанию. Алгоритм разрабатывался с 2018 года и прошёл обкатку в Go 1.25. Благодаря этому улучшается работа с кэшем процессора, а нагрузка на CPU при сборке мусора снижается от 10% до 40% на реальных задачах.

На уровне языка функция new() теперь теперь принимает произвольные выражения. Это означает, что больше не нужны вспомогательные функции вроде StringPtr() для создания указателей на примитивы.

В стандартной библиотеке появились новые пакеты. Пакет crypto/hpke реализует Hybrid Public Key Encryption по RFC 9180 с поддержкой постквантовых алгоритмов. Экспериментальный simd/archsimd открывает доступ к SIMD-инструкциям процессора. А runtime/secret обеспечивает гарантированное затирание секретных данных из памяти, что важно для безопасной работы с ключами и паролями.

Криптографические пакеты также обновлены. Постквантовые key exchanges включены по умолчанию в TLS. Добавлены интерфейсы Encapsulator и Decapsulator для работы с KEM-алгоритмами. Многие функции теперь используют детерминированную генерацию случайных чисел, что упрощает тестирование.

Есть изменения, влияющие на совместимость. Удалён 32-битный порт Windows ARM, FreeBSD riscv64 помечен как broken, macOS 12 Monterey поддерживается последний раз. Кроме того, несколько GODEBUG-настроек будут удалены в Go 1.27, поэтому стоит проверить код на использование устаревших флагов.

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

К этой статье я шел несколько месяцев, по этому надеюсь проделанный труд будет полезен сообществу. Выложу я её уже на этой неделе и в ТГ дам анонс!

Релиз ноты: https://go.dev/doc/go1.26

Статья готова!

Официальные релизноты Go традиционно скупы на детали. Читаешь и думаешь: "ну ок, что-то поменяли", а в итоге оказывается что изменений много.

Решил сделать работу за тебя. Сел (на 2 месяца), раскопал каждое изменение, написал примеры и прогнал бенчмарки на своём железе.

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

Что лично меня зацепило больше всего:

- Green Tea GC стал дефолтным. Разрабатывался с 2018 года, обкатывался в проде у Google, и теперь просто работает из коробки. На моих бенчмарках прирост от 28% до 46% в зависимости от нагрузки. Без единого изменения в коде.

- new(42) вместо пляски с промежуточными переменными. Четыре года обсуждений proposal от Rob Pike, и наконец можно писать Age: new(30) вместо трёх строк с &age. Мелочь, а кодовая база скажет спасибо.

- Экспериментальный профиль утечек горутин. Вот это я ждал. Основан на исследовании из Uber на 75 миллионах строк кода. GC сам находит горутины, заблокированные на недостижимых каналах. Включается через GOEXPERIMENT, но уже рабочий.

- В статье ещё SIMD-инструкции из Go, постквантовая криптография, ускорение cgo на 30%, затирание секретов из памяти и куча изменений в стандартной библиотеке.

https://habr.com/ru/articles/995906

Статья на 127 минут сдана. Два месяца раскопок Go 1.26 позади, можно выдохнуть.

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

В Go 1.26 он стал сборщиком мусора по умолчанию. Разрабатывался с 2018 года, прошел обкатку в 1.25 как эксперимент, а теперь просто включен из коробки. На моих бенчмарках прирост от 28% до 46%. Без единого изменения в коде.

Сажусь за новую статью. План такой:
- как Green Tea работает изнутри
- чем отличается от предыдущего GC
- реальный код runtime: go1.25 vs go1.26, что конкретно поменялось
- и блок с вопросами, которые могут прилететь на собесе про GC

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

Если есть вопросы про GC, которые мучают - пишите, постараюсь закрыть в статье.

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

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

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

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

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

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

https://github.com/twpayne/chezmoi

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начинаю серию постов про 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

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 🔗

Ну пи**ец!