Про выгорание, с усталым видом и без пафоса.

Да, об этом говорят часто. И правильно делают... Умалчивание не работает!

Для меня выгорание это не "слабость", а естественный результат, если долго жить только задачами. У любого ресурса есть предел.

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

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

По этому пишу пост, как один из способов саморефлексии.

Сейчас мы делаем рефакторинг SSO системы, и утром меня посетила мысль "В коде мы регулярно делаем рефакторинг. Почему бы с собой поступать так же?".

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

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

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

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

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

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

Как и обещал, пишу пост технический. Надеюсь лично для тебя полезный. Сначала хотел коротко описать в ТГ как это реализовать, но в итоге все так раздулось, что пришлось выложить в качестве статьи. Ну так вот, написал статью на Хабр о том, как организую 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 отработано! Посмотрим...