Июль 2025:

ключевые события

✔️ Успешно прошел 6-ой перф-ревью в компании. За последние 6 месяцев много перформил и устал - сейчас это ощущается. Но получил отличный результат и фидбек от коллег. Отдельно планирую порефлексировать на этот счет и подробнее рассказать про прошедшее ревью.

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

✔️ Попрактиковался в функциональной композиции, избавлении от stateful в проекте и организации модульности.

✔️ Решил углубиться в дизайн программ: правильно думать про разделение реализации и спецификации, доказывать корректность программы через Триплы Хоара и пр.

✔️ Не могу не отметить очередной забег (на этот раз айтишный) на 10 км по 30-градусной жаре. Почти уложился в 50'... Подобные события серьезно помогают восстанавливаться после работы. Ментальная усталость замещается физической.

посты

⭐️ Сколько нужно людей, чтобы поменять лампочку в Биг Техе -> читать

🔖 Документация лжет вам. Можно ли сохранить свежесть? -> читать

🔖 Атомарные изменения лучше -> читать

#дайджест

@time2code

⏳ Сколько времени нужно, чтобы стать Senior? — Соединяю точки.

В декабре 2022 я предположил, что мне потребуется около трех лет, чтобы дорасти до 5-го грейда (senior по меркам Авито).

Прошло 2.5 года и вот я здесь...

Для меня это очень крупная веха. Возможно, самая крупная на этом карьерном треке.

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

Интересно, но в 2020 году у меня не было образа конечного результата, а только долгий и непонятный путь.

Знаменитая цитата очередной раз обрела смысл:

You can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future.

Еще два года назад я рисовал дорожную карту с привязкой к грейдам и планированием на несколько лет вперед.

Был ли я уверен, что смогу ей соответствовать? — Отнюдь. Слишком много переменных, но очень хотелось.

> Желание, системность и дисциплина - ключевые игроки, когда речь идет о реализации поставленных планов.

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

Что дальше?

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

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

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

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

Также важно пересмотреть долгосрочные планы на 2-3 года и, конечно, навалиться на последние 4 месяца 2025-го, чтобы постараться закрыть поставленные цели.

Планов много, энергии мало — впрочем, редко было иначе. Если вдруг есть рабочие рецепты по глубокой работе, а затем и полному восстановлению, то буду рад что-то перенять!

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

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

@time2code

Цель, которая работает на вас: умная практика для инженера и менеджера

В качестве ментора провожу регулярные встречи с менти.

Работаем с запросом: "составить структурированный индивидуальный план развития (ИПР) и получить понимание о том, как развивать сильные стороны".

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

Если декомпозировать запрос, то на выходе получаем два фокуса:

1. Составить ИПР
2. Получить новое знание

И, если с ИПР относительно все понятно, так как нет ничего более конкретного чем наличие материального артефакта или его отсутствие (за исключением: какой ИПР нам нужен, для чего и когда), то с получением знаний всегда есть сложность, так как это очень абстрактная история.

Как можно оценить "получение знание", какую метрику применить? — Очевидно, что это очень субъективно, если, конечно, мы не захотим использовать какую-то методику оценки полученного знания, которая добавляет дополнительных действий и обозначает, тот факт, что непосредственно знания — не конечная точка, а лишь определенный момент перед условной аттестацией, которая впоследствии и сможет служить метрикой для оценки результата.

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

Наводящие вопросы:

- Является ли составленный ИПР конечной точкой при работе с ментором или это лишь одна из составляющей чего-то большего?
- С какой целью мы хотим получить новые знания или развить сильные стороны?

Нам важно сформировать точку Б, к которой хотим прийти, а чтобы понимать, что мы туда пришли нам важно уметь правильно формировать цели.

Вероятно, самый популярный фреймворк для этого - SMART.

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

Конечно, к идеальной модели, которую предполагает фреймворк бывает прийти сложно, так как некоторые нюансы могут быть спорными или неочевидными, но сам по себе SMART "вытягивает" любую абстрактную цель в более конкретную, с которой легко работать.

Например, переформулируем составление ИПР:

Конкретная (Specific): Разработать индивидуальный план развития (ИПР) для собственного профессионального роста в текущей должности.

Измеримая (Measurable): ИПР должен включать как минимум 3 конкретные цели развития (например, "пройти курс X", "освоить навык Y до уровня Z", "реализовать проект А"), 2 ключевых показателя успеха (KPI) для оценки прогресса по каждой цели и список необходимых ресурсов/действий.

Достижимая (Achievable): Цели в ИПР должны быть реалистичными с учетом текущей нагрузки и доступных ресурсов (время, бюджет на обучение).

Актуальная (Relevant): Разработка ИПР напрямую связана с повышением моей эффективности в текущей роли и подготовкой к будущим задачам/продвижению.

Ограниченная по времени (Time-bound): Завершить разработку и согласовать ИПР с моим руководителем к, например, 28 августа 2025 года.

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

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

@time2code

Вы знаете, где живет ваш код?

Мы живем в мире высоких технологий и скоростного интернета.

Проводить за компьютером весь день, а результатом своей работы иметь какой-нибудь цифровой актив — стало нормой.

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

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

Немало детей разбирают (или просто ломают) свои игрушки с этой же целью.

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

Сюда отлично ляжет шутка: “Backend / Frontend”...

Как будто стремление разбираться в деталях реализации и подтолкнуло меня к выбору в пользу работы с бэкендом.

И, если с бытовыми устройствами, машинами, механизмами все относительно просто. То, когда речь идет о цифровых активах и их управлении, многое может быть не таким очевидным.

Идея

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

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

Стоит ли говорить, что порядка ста коллег тоже захотели принять участие? Это показатель неудовлетворенного спроса.

Конечно, не стоит из этого делать атракцион, все-таки это DC — узел с максимальной ответственностью за работоспособность платформы.

Но какая-то активность, которая будет цифровых специалистов "заземлять" (например, через посещение DC), мне кажется очень полезной.

Выводы

— Инженерам важно видеть всю "внутрянку" системы, с которой они работают.

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

Обращение к менеджерам (знаю, что меня читают): давайте возможность своим инженерам время от времени погружаться в такие истории — это идет на пользу.

Что еще быстрый поиск предлагает почитать по теме:

- Авито Тех в 2022-м рассказал для чего нужны датацентры и где у них хранится железо.

- 2013 год, видимо, задавал тренд на экскурсии по DC, поэтому нашел сразу от двух компаний: VK и Yandex (с реальными фотографиями, несмотря на режимность объектов).

А вы были в датацентре? Было бы интересно посмотреть, где работает ваш код?

@time2code

Ваш главный инструмент в отладке

Есть множество разных техник как отлаживать свой код. Я всегда был сторонником двух подходов: метод пристального взгляда (МПВ) и использование дебагера.

МПВ

Обычно МПВ используется для грубой оценки, помогает далеко не всегда, но способен сэкономить очень много времени. Он прост и всегда доступен: не нужно ничего запускать, нужен только исходник кода, изучить который можно даже в общественном транспорте, скомпилировав в голове.

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

Дебагер

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

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

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

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

Для VS Code существует документация, предлагающая несколько интересных возможностей.

Умные точки останова

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

Например, удобно в циклах задавать условие равенства переменной значению. Я раньше про такую возможность не знал и "костылил" условие прямо в коде с пустышкой в виде "print", на который вешал брейк.

Debug Console

Кто работает с VSC отлично знаком со вкладкой VARIABLES, где можно изучить состояние всех переменных, но мало кто использует вкладку Debug Console.

На этой вкладке можно производить элементарные операции с переменными:

- вывести состояние в консоль;
- произвести преобразование типа;
- получить значение по ключу из словаря и пр.

Значение переменой получается через простой ввод, например:

x

При этом можно получать доступ к приватным полям структуры:

x.private

Кроме того и это, вероятно, самое приятное мы можем вызывать различные функции, используя ключевое слово call.

Например, если обращаемся к интерфейсу, у которого есть метод получения имени:

call in.Name()

К сожалению, каких-то изощренных действий и сложных функций использовать нельзя.

Я тщетно пытался получить конкретное значение массива по определенным правилам, но консоль ругалась, что такое не реализовано.

Если знаете более крутые техники в отладке или есть что-то, что вам очень помогает, то делитесь — интересно обсудить.

@time2code

Что выведет программа?

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

Программирование во многом — про внимательность, которая может дорого обходиться при работе с большими нагрузками.

Итак, задача:

package main

import "fmt"

func main() {
  fmt.Println(len(IntArray()))
}

func IntArray() []int64 {
  return []int64{
    2302481, // one
    2302482, // two
    2302483: // three
    2302484, // four
  }
}

Попробуйте дать 2 ответа: первый, который придет сразу в голову (проголосуйте в опросе ниже) и второй, который будет обдуман и обоснован (можно прямо в реплаи).

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

@time2code

Август 2025:

ключевые события

✔️ Закрыл P0 ОКР на текущий год!

✔️ Решил, что пора делиться опытом, поэтому продолжаю менторить коллегу из другой команды, а также запланировал принять участие во внутренней программе развития инженеров в качестве ментора (год назад принимал участие в программе, как участник).

✔️ Прошел курс по "незримым механизмам логики", учась правильно думать о программе, разделяя спецификацию от реализации, а также курс по ФП.

✔️ Принял участие в двух забегах: на 10K и 21K. Уложился в 50 мин и 2 часа соответственно.

посты

⭐️ Сколько времени нужно, чтобы стать Senior? — Соединяю точки -> читать

🔖 Цель, которая работает на вас: умная практика для инженера и менеджера -> читать

🔖 Вы знаете, где живет ваш код? -> читать

🔖 Ваш главный инструмент в отладке -> читать

#дайджест

@time2code

Контракт лжет вам. Виноват ли DI?

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

Нашел подходящую RPC-ручку, которая принимает на вход список ID, и возвращает нужный ответ.

Тестирую со значением [123456789] — все отлично. Радуюсь.

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

Подаю на вход [123456789, 987654321] и получаю пустой ответ.

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

Убираю фильтрацию — результат такой же.

Когда все базовые сценарии проверил, исчерпав очевидные идеи, иду к владельцам сервиса за помощью.

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

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

Оказывается, что данный запрос может корректно работать только с одним ID, несмотря на то, что на вход принимается массив.

Под капотом сервиса зашит клиент, который обращается к шардированной БД. Номер шарда определяется по ID, вот так и получается, что при указании массива, вероятность, что значения окажутся на одном шарде, крайне мала.

В результате получили явное нарушение семантики контракта.

При этом за счет того, что соответствующий handler реализует DI, то, вероятно, раньше (N лет назад), все действительно нормально работало, когда не было шардов или клиент, обращающийся к БД, был другой.

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

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

Конечно, проблема не в самом DI, а в том, что за счет бесшовной и незаметной возможности замены клиента мы кардинально изменили логику работы, никак не уведомив об этом потребителей.

За мощью абстракций также могут скрываться подобные сюрпризы. Учитывайте это при проектировании.

@time2code

Эффект бабочки

Сложно обуздывать перфекционизм и в очередной раз, залезая в какой-нибудь неидеальный код, что-нибудь взять да и не поправить.

Кажется — это же основное правило цифрового бойскаута: "Оставь после себя код лучше, чем был до".

Но это работает не всегда. Особенно в Биг Техах.

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

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

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

Это как зацепка на новом свитере: попытался незаметно вытянуть маленькую нитку, как вот уже весь свитер начинает распускаться.

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

Очень легко отвлечься мыслями и уйти в серьезный рефакторинг.

Тема плотно перекликается с атомарными ПР-ами, про которые рассуждал в другом посте.

Конечно, бывает так, что задача плохо описана, или вы нашли очевидную проблему, которую нужно править ASAP. На такой случай есть несколько рекомендаций:

1. Атомарные коммиты — в случае проблем это поможет сделать легкий реверт изменений.

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

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

Интересно, как много кейсов, когда "минорные" правки приводили к чему-то серьезному и непредсказуемому?

@time2code

Default Mode Network: дар и проклятие

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

С одной стороны это хорошо и даже здорово. Но с другой — это поглощает, и без контроля в этом запросто утонуть.

Default mode network

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

На практике же это работает иначе.

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

Этакая мысленная жвачка, которая может идти как на пользу, так и во вред.

Из жизни

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

Мысль возникла из ниоткуда. Я не думал про задачу, не думал про работу, размышлял о чем-то отвлеченном.

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

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

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

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

Что делать?

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

На выходе: более быстрое восстановление и способность ясно мыслить.

Очевидная рекомендация — сделать медитацию и физ. нагрузки рутиной, которая поможет поддерживать ежедневную эффективность, усмиряя DMN и позволяя быстрее восстанавливаться.

В этом году решил сфокусироваться на построении прочной системы тренировок:

> Бассейн 1 раз в неделю (уже стало привычкой)
> Постепенно добавляю большой теннис в таком же количестве
> Несколько беговых тренировок, совмещенных с силовыми (целевая регулярность — минимум 3 раза в неделю)
> Медитация (пока в планах, но цель — от 5 минут в день)

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

@time2code

LLM и тесты

На днях Федя Борщёв написал пост про генерацию тестов при помощи LLM.

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

Львиная доля аудитории в комментариях, очевидно, встала на защиту LLM и тезиса, что, если у вас ничего не получается, значит, вы ее неправильно готовите :)

Когда это работает

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

Из опыта

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

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

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

Таким образом, код может начать быстро превращаться в легаси, обрастая различными конструкциями, которые становится сложно поддерживать.

Это начинает явно проявляться в тестах.

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

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

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

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

Это растягивается на несколько итераций...

Польза ручного написания тестов

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

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

❗️ Да, LLM может тоже это все подсказать, если опять же подготовить хороший промт, но когнитивная нагрузка, затраченная на проверку всего сгенеренного окупит ли автоматизацию?

Еще один консерн у меня был как у ревьюера.

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

А вот если тесты есть, их много, но их сгенерировала LLM, то как их реально проверить? Попросить другую LLM это сделать?

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

Хотя возможно, я тоже не умею правильно готовить AI для тестов и у меня есть свои причины, чтобы это не делать, подтвержденные опытом.

Не исключаю, что это со временем поменяется, постоянно экспериментирую и даю второй (третий и т.д.) шанс, но пока так.

@time2code

Transactional outbox — опыт других

О паттерне

Разбирая 3 главу книги "Микросервисы", уже упоминал этот паттерн.

Описание от Криса Ричардсона здесь.

Паттерн довольно распространенный. В Авито, например, используется самописный коннектор для решения этой проблемы.

Для PostgreSQL можно использовать pgq.

Что использует финтех

Вчера сходил на первый митап, проводимый Т-банком в их новом "ИТ-хабе" в Петербурге.

Рассказали две темы: как готовить контроллеры для K8S и про свою реализацию Transactional Outbox.

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

Доклад про Outbox вышел неплохим. Реальный опыт, итерационная разработка с несколькими реализациями паттерна и множество шишок с последствиями для пользователей.

В сухом остатке предлагаю посмотреть на схему БД, к которой пришли ребята, и производительный (по их бенчмаркам) запрос из таблички "outbox", который выполняется за 20ms+-.

Таблица outbox:

CREATE TABLE kafka_outbox (
    "offset" BIGSERIAL,
    transaction_id XID8 NOT NULL,
    event_id UUID NOT NULL,
    topic TEXT NOT NULL,
    key TEXT NOT NULL,
    payload JSONB NOT NULL,
    headers JSONB,
    created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
    
    PRIMARY KEY (transaction_id, "offset", created_at)
)  PARTITION BY RANGE (created_at);

Выборка из outbox:

SELECT * FROM (

    SELECT "offset", transaction_id, key, topic, payload, headers FROM kafka_outbox
    WHERE transaction_id = $1 AND "offset" > $2
    AND transaction_id < pg_snapshot_xmin(pg_current_snapshot())

    UNION ALL

    SELECT "offset", transaction_id, key, topic, payload, headers FROM kafka_outbox
    WHERE transaction_id > $1
    AND transaction_id < pg_snapshot_xmin(pg_current_snapshot())

) AS messages

ORDER BY transaction_id, "offset"
LIMIT $3;

Из интересного в последнем запросе — использование UNION'а. Такой подход предложил собственный AI. До этого использовался один SELECT со сложными условиями, который выполнялся очень долго (порядка 12 секунд).

Наверняка, что-то еще здесь можно оптимизировать, но перепробовав 3-4 варианта, в конечном итоге остановились на этом.

Переход от одного варианта к другому сопровождался неприятной в поддержке миграцией. Учитывайте это при проектировании.

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

@time2code

Сентябрь 2025:

ключевые события

✔️ Полноправно вступил в должность «Старшего инженера».

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

✔️ Записался на курс “Системный дизайн высоконагруженных проектов” и уже приступил к нему. Позже будет пост сравнение с курсом «Анализ систем», который проходил в прошлом году.

✔️ Принял участие в командной Гонке Героев URBAN. Крутой формат, где совместная работа важнее индивидуальных достижений.

✔️ Количество внешних запросов на менторство выросло (самый популярный — составление ИПР), настало время делиться опытом, чувствую, что могу быть полезным. В этом году больше не набираю, если вдруг у вас есть запрос, то напишите в лс, попробую асинхронно что-то предложить или записать на следующий год.

посты

⭐️ Transactional outbox — опыт других -> читать

🔖 LLM и тесты -> читать

🔖 Default Mode Network: дар и проклятие -> читать

🔖 Загружаем ключевые идеи V5 -> читать

🔖 Контракт лжет вам. Виноват ли DI? -> читать

🔖 Эффект бабочки -> читать

#дайджест

@time2code

Боль при переезде на новое железо осталась в прошлом?

Всегда пугал переезд: на новый ноутбук, ОС, телефон и т.д.

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

Но сейчас про бытовое.

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

Возможно, если бы 5 лет назад не пересел бы на MacOS, то пост вышел бы другим, но здесь оказалось все тривиально: есть ассистент миграции, который поможет все перенести на новую машину AS IS.

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

Мне же потребовалось чуть больше приседаний, так как решил пойти через бэкап на HDD и дальнейшее восстановление из него.

Все прошло гладко, но по времени это заняло порядка 5 часов (400GB данных):
- бэкап на HDD занял несколько часов;
- восстановление из HDD еще несколько часов.

Возможно, при использовании хорошего SSD с подключением через type-c заняло бы гораздо меньше времени (я использовал простой советский HDD с usb 3.0 и адаптером под type-c), но это для меня было и не так важно.

Из приятного

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

2. Переезд прошел бесшовно (даже многие браузерные сессии не были сброшены), поэтому ощущение было, что просто произошло штатное обновление системы.

Что могло быть лучше?

Со времен прожига двухстороннего вербатима для Xbox360 остались неприятные воспоминания, что многочасовое ожидание записи данных легко может быть прервано на 99%.

Это означало, что диск идет в утиль и все предстоит проделывать заново. Поэтому успешный перенос данных уже расцениваю как ультимативный успех.

Конечно, хотелось бы, чтобы подобные миграции происходили в пределах 10-15 минут, но, вероятно, тут упираемся в производительность железа.

Так или иначе, но что у Apple хорошо — это бесшовный переезд со старых устройств на новые. Это крайне ценный UX.

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

@time2code

Лучшее, чем можно заняться в отпуске*

*Конечно, кроме полноценного отдыха.

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

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

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

Как?

Я придумал простой алгоритм, который на удивление, во многом совпадает с популярным Getting Things Done, поэтому почему бы не использовать оригинальный GTD, раз ему уже больше 20 лет (смотреть диаграмму).

Базово это выглядит так:

1️⃣ Очищаем голову и наполняем INBOX

Все, что беспокоит: проекты, заметки или давно откладываемые дела — помещаются во входящие.

2️⃣ Сортируем

Действие требует менее 2-х минут? — Делаем сразу. Иначе размечаем и организуем по другим категориям.

3️⃣ Выполняем

Делаем задачи в порядке приоритетов и срочности.

4️⃣ Обзор

Еженедельно сверяемся с текущими задачами и проектами.

Инструменты

Что для этих целей использовать, решать вам. Сперва я думал, что начну с бумажного блокнота, но, когда увидел объем мыслей, которые накопились всего за 5 минут, то отбросил эту идею, так как сортировать это потом будет неудобно.

Думаю, начну наполнять INBOX в Obsidian + медитативный фон и 2 таймера по 50 минут с перерывом 10.

Посмотрим, что из этого выйдет.

@time2code

Собираем требования

На курсе по System Design, про который писал ранее, первым заданием стал выбор проекта, который будет держать 100M DAU (daily active users).

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

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

Но иногда учебный проект — это всего лишь проект и нужно быть проще :)

Так или иначе, я смог определиться с темой, которая мне потенциально интересна, только спустя несколько недель.

И это: сервис по поиску событий и активностей, с календарем, новостями и общением!

Определившись, мне теперь предстоит проработать его "предизайн", как на реальной секции SD:

1. Продумать базовые сценарии и роли.
2. Собрать вместе функциональные и нефункциональные требования.
3. Оценить необходимые ресурсы для обслуживания 100M DAU.
4. Презентовать.

Планирую сделать серию постов про ход проекта. Если вдруг тема откликнется, постараюсь делать это подробнее.

@time2code

Highload. Инструкция по выживанию

Прошло 2 года с посещения конференции для разработчиков высоконагруженных систем Highload++ 2023, которая для меня стала первой в статусе Go-разработчика.

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

Ценник для личного участия я бы назвал заградительным,(убежден, что есть более полезное приложение для 100K), поэтому основная аудитория — корпорации, для которых не составит никакого труда отправить вас на конференцию за счет бюджета на обучение или как выступающего с докладом.

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

Выбрать цель

Без цели на конференции можно легко праздно провести время.

Полезными могут быть:

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

Самая полезная конференция (и первая в карьере) случилась в 2017 году, у меня было 2 цели:

1. Поиск возможного решения по использованию информационного моделирования в эксплуатации (задача компании).
2. Материал для написания магистерской диссертации (+поиск наставника).

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

В этом году я еду с комбинированной целью: прощупать пульс IT-индустрии, найти новые практики, которые можно внедрить в процессы компании, и нетворкинг.

Спланировать

Планирую план посещения конференции формировать с учетом описанных целей выше. Лучше подготовиться заранее, накануне, чтобы не пытаться планировать в центре многотысячной толпы (пробовал, неудобно).

Активно участвовать

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

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

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

А вы видите пользу от профильных конференций? Принимаете очное участие или онлайн?

> Если тоже будете на Хайлоаде 6-7 ноября и готовы встретиться, то пишите — попьем кофе.

@time2code