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

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

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

Почитать можно здесь: https://dburov.com/ru/research/go-ternary

А вам не хватает тернарного оператора или нет?

Кто я | Навигация | Спасибо

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

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

На странице митапа можно посмотреть, как прошла наша встреча в Ростове-на-Дону в прошлом году - там есть фотографии и атмосфера, чтобы понять, чего ожидать: https://vladimir-balun.timepad.ru/event/3922777/ (количество билетов ограничено, записаться уже можно сейчас)

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

Кто я | Навигация | Спасибо

🧩 Lock contention - вещь, о которой почти никто не думает… пока все не начинает тормозить

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

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

Простой пример на Go:

type Counter struct {
mtx sync.Mutex
value int
}

func (c *Counter) Inc() {
c.mtx.Lock()
defer c.mtx.Unlock()
c.value++
}

Выглядит корректно! Но если у тебя 500-1000+ горутин дергают Inc() - начинаются проблемы: все ждут мьютекс, а также растут задержки и падает пропускная способность.

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

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

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

Кто я | Навигация | Спасибо

💭 Есть довольно популярное мнение в разработке: system design нужен только сеньорам и архитекторам, а мидлу он, по сути, не нужен - достаточно хорошо писать код

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

И действительно, middle-разработчик редко проектирует систему с нуля. Но это не означает, что он не сталкивается с архитектурой в работе. На практике почти каждый день мидл: добавляет новые фичи в существующую систему, меняет поведение сервисов и работает с базами данных, кешем, очередями, API.

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

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

Еще один важный момент - коммуникация. На технических обсуждениях часто звучат вопросы вроде: это синхронный или асинхронный процесс, что будет при пиковой нагрузке, где потенциальная точка отказа, лучше ли решать это на уровне сервиса или базы данных. Без понимания System Design в таких обсуждениях ты чаще просто слушаешь. С пониманием - можешь задавать осмысленные вопросы, подсвечивать риски, предлагать альтернативы. Даже если финальное решение принимает кто-то другой, ты уже участвуешь в проектировании, а не просто выполняешь задачи.

📌 У меня был похожий опыт, когда я работал в Тинькофф на позиции middle-разработчика. Я ходил на командные архитектурные встречи, где обсуждали изменения в системе. И в какой-то момент поймал себя на ощущении, что мне нечего добавить. Я понимал отдельные куски, но не видел общей картины, из-за чего разговоры про архитектуру проходили мимо меня как наблюдателя.

Это довольно типичная ситуация для мидлов: код пишется уверенно, но при обсуждении системы возникает непонимание. Разница между middle и senior часто не в качестве кода, а в уровне мышления. Middle думает задачей и реализацией. Senior думает системой и последствиями решений. И даже если цель не стать сеньором прямо сейчас, оставаться только на уровне реализации задач - это ограничение роста.

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

Кто я | Навигация | Спасибо

🧩 В Go select устроен так, что при одновременной готовности нескольких каналов он не пытается как-то честно распределять выполнение.

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

Например, в простом цикле с двумя каналами это может выглядеть так:

for {
    select {
    case msg := <-ch1:
        fmt.Println(msg)
    case msg := <-ch2:
        fmt.Println(msg)
    }
}

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

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

for {
    select {
    case msg := <-highPriority:
        handleHigh(msg)
    case msg := <-lowPriority:
        select {
        case msg := <-highPriority:
            handleHigh(msg)
        default:
            handleLow(msg)
        }
    }
}

Здесь логика простая: если есть highPriority - берем его сразу, если нет - работаем с lowPriority, но перед обработкой ему дают второй шанс проверить highPriority (при это сообщение из lowPriority будет получено). Это уже дает довольно жесткий приоритет, но ценой того, что нижний уровень может иногда простаивать дольше.

Есть вариант чуть мягче, когда приоритет не фиксируется настолько строго, а скорее “подсвечивается” через вероятность. Например, можно повторять ветку несколько раз:

for {
    select {
    case msg := <-highPriority:
        handleHigh(msg)
    case msg := <-highPriority:
        handleHigh(msg)
    case msg := <-lowPriority:
        handleLow(msg)
    }
}

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

Третий способ - использовать дополнительный select с default перед основным. Сначала делается неблокирующая проверка приоритетного канала.

for {
    select {
    case msg := <-highPriority:
        handleHigh(msg)
    default:
    }

    select {
    case msg := <-highPriority:
        handleHigh(msg)
    case msg := <-lowPriority:
        handleLow(msg)
    }
}

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

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

Кто я | Навигация | Спасибо

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

Разобрал в статье:
- базовые алгоритмы и структуры данных, которые реально встречаются на интервью
- как подходить к решению задач, а не просто решать их по шаблону
- типовые ошибки кандидатов на алгоритмических собеседованиях
- как готовиться так, чтобы уверенно проходить интервью в BigTech

🔗 Ссылка на статью: https://balun.courses/blog/algorithmic_interview/

Ещё в ближайшее время буду рассказывать про алгоритмы и подготовку к собеседованиям на конференциях:
- 13 мая, Москва - конференция Mobius
- 16 мая, Чебоксары - конференция IT-Link
- 30 мая, Ростов-на-Дону - митап по программированию

Если будете на этих мероприятиях - приходите на доклады, буду рад пообщаться вживую!

Кто я | Навигация | Спасибо

ИИ уже стал частью нашей жизни и работы. И именно поэтому о нем стоит говорить и говорить

В мае совместно с Центральным Университетом пройдет митап, посвященный разработке, внутреннему устройству ИИ и работе с ним!

В программе 3 доклада и один круглый стол, на которых:
• подумаем над разворачиванием LLM-моделей на своих телефонах для приватных ассистентов
• узнаем про Agent Client Protocol, который помогает интегрировать модели прямо в плагины для IDE
• поговорим о том, как заставить агентов выдавать качественный код
• и конечно поспорим о том, какую дорогу стоит выбирать компаниям: покупать готовые модели или разворачивать open source решения

Спикеры из Ozon, OpenIDE, H3llo Cloud и BlackHub Games! Митап пройдет в кампусе Центрального Университета 21 мая в 18:30 🚀

Зарегистрироватсья можно по ссылке: https://cu.ru/career/events/good-bad-ai?utm_source=partners&utm_campaign=allo_ada

Кто я | Навигация | Спасибо

💭 Есть известная шутка: "There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors"

И сначала кажется, что насчет кеша это просто мем. Ну реально - что сложного? Обновил данные в БД, очистил кеш и все. А потом появляется баг: данные уже обновились, но пользователь все еще видит старое значение. Проблема в том, что кеш - это почти всегда еще одна копия данных. Есть оригинал в БД, а есть копия, например в Redis, локальном кеше, CDN или браузере. И теперь все это нужно держать синхронным.

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

Причем даже такой простой код уже может создавать проблемы:

db.UpdateUser(user)
redis.Del("user:123")

Потому что БД могла обновиться успешно, а сервис упал до удаления ключа. И устаревшие данные останутся жить дальше. Если сделать наоборот - тоже можно поймать баг. Удалили данные в кеше, но БД еще не обновилась, а другой запрос сходил в базу, прочитал старые данные и снова положил их в кеш (то есть сами восстановили устаревшие данные).

Именно поэтому вокруг кеширования столько паттернов: например cache aside, write through, write behind и так далее. Но ни один из них не решает проблему полностью. Они просто по-разному влияют на задержки, консистентность или сложность системы.

Отдельная боль - многоуровневый кеш. Когда у вас одновременно: in-memory cache, Redis, CDN, кеш браузера или кеш на фронте. И теперь инвалидировать нужно не один слой, а сразу всю цепочку. Особенно весело, когда в одном месте данные уже обновились, а в другом еще нет. И система начинает сама себе противоречить.

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

Кто я | Навигация | Спасибо

💭 Периодически провожу бесплатные консультации в формате Q&A-встреч, где можно задать вопросы про программирование, карьеру, собеседования, развитие в IT и просто обсудить разные рабочие ситуации

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

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

Следующие встречи пройдут 26 и 28 мая.

Участие бесплатное, но записи не делаем - только онлайн присутствие вживую. Если интересно, можно присоединиться по ссылке: balun.courses/open_lessons/qa

Кто я | Навигация | Спасибо

📹 Сняли новое видео, где разбираем тестовые задания по программированию

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

Посмотреть можно по ссылке: https://www.youtube.com/watch?v=gcG_YhYZUWI

Кто я | Навигация | Спасибо

📹 Записал отдельное видео про lock contention - проблему, которая может незаметно съедать производительность даже в хорошо написанном многопоточном коде

В видео разобрал: что такое lock contention и почему он возникает и какие подходы помогают снизить contention и улучшить производительность.

Посмотреть можно по ссылке: https://youtu.be/ANQJPn6WAZA

Кто я | Навигация | Спасибо