🦄 Новый выпуск GoGetPodcast уже на канале

https://youtu.be/8vdBg8jlx2M

Скажу снова: кажется, это один из лучших эпизодов подкаста (ну а что, выпуски действительно становятся всё лучше).

У Арсения были очень интересные вопросы и свежий взгляд. А Глеб и Дима отлично отвечали и дополняли друг друга: глубокая экспертиза Димы в языке + огромный опыт Глеба в разработке в целом.

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

💁‍♀️ Вот тот самый доклад Арсения на GoWest, который мы упоминали в начале выпуска.

🟠Напоминаю, что у подкаста теперь отдельный канал на YouTube. Ему очень нужна ваша поддержка. Если любите GoGetPodcast — подписывайтесь, ставьте лайки и досматривайте эпизоды до конца. Это сильно помогает алгоритмам.

————

Этот выпуск вышел при поддержке AvitoTech 💙

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

Только благодаря им выпуски теперь будут выходить стабильно и регулярно. Больше никакого ожидания по полгода! 👍

AvitoTech также ведут свой блог на хабре и проводят митапы. Недавно я делился их отличной статьей про обработку ошибок в Go.

#gogetpodcast

Так, один попался! 👮

На оранжевой ветке

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

Спешите досматривать, пока тоже не попались 🌚

🖥 UUID: Как создать уникальный ID без центрального сервера?

Начало 1980-х. Вы — разработчик в Apollo Computer. Ваша команда работает над NCS — одной из первых систем для распределённых вычислений.

Вам поручили решить важную проблему:

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

На одной машине всё просто — даём каждому объекту порядковый номер: 1, 2, 3... Но если два сервера независимо дадут номер 1 своим объектам — получим коллизию

Начинаем думать.

————

Попытка 1: Центральный сервер со счётчиком

Самое очевидное решение — один сервер раздаёт ID всем остальным:

Машина A → Центр: "Дай ID"
Центр → Машина A: "Держи ID=1"

Машина B → Центр: "Дай ID"  
Центр → Машина B: "Держи ID=2"

Выкатываем в прод. Работает идеально! Гарантированно уникальные ID, никаких коллизий.

Но через неделю начинаются проблемы:

- Центральный сервер упал — вся система встала
- Каждый запрос ID требует сетевого обращения — медленно
- При росте нагрузки центр становится узким местом

Для распределённой системы, где важна автономность узлов, это не подходит. Переделываем.

————

Попытка 2: Диапазоны для каждой машины

Хорошо, давайте заранее раздадим каждой машине свой диапазон ID:

Машина A: ID от 1 до 1,000,000
Машина B: ID от 1,000,001 до 2,000,000
Машина C: ID от 2,000,001 до 3,000,000

Это уже лучше — каждая машина действительно автономна!

Выкатываем. На первый взгляд работает.
Но потом выясняется:

- Машина A исчерпала свой диапазон, нужно запрашивать новый → опять зависимость от центра
- Машина B создала только 10 объектов из миллиона, остальные ID потрачены впустую
- Добавление новых машин требует центральной координации для выдачи диапазонов

Опять возвращаемся к центральной точке отказа. Это не то.

————

Попытка 3: Составные ключи

Может использовать комбинацию machine_id + local_counter?
Для machine_id можно взять MAC-адрес сетевой карты — он уникален глобально.

Машина A, объект 1: "A-1"
Машина A, объект 2: "A-2"  
Машина B, объект 1: "B-1"

Это уже лучше — каждая машина действительно автономна!

Выкатываем.. И получаем пачку новых проблем:

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

Попытка 4: Время + ID машины

А что если вместо счётчика использовать текущее время?

timestamp + MAC-адрес

- Время монотонно растёт — коллизий на одной машине не будет
- MAC-адрес уникален глобально — коллизий между машинами не будет
- Не нужно хранить счётчик!

🟢Это уже очень близко к рабочему решению. Примерно так и работали ранние UID в Apollo

Но проблемы ещё остались: что если часы на машине сбросились? Или две операции произошли в одну микросекунду? На нагруженных системах это не редкость — при тысячах запросов в секунду коллизии по времени станут регулярным явлением.

————

Как же сложно! 😩
Вы сидите, смотрите на свои наброски и думаете: может проблема в самом подходе?

И тут к вам подходит коллега из команды криптографии 🎩

Вы излагаете ему свою боль, после чего он пожимает плечами и задумчиво произносит:

— Слушай, а зачем тебе гарантировать уникальность на 100%? Может, сделать вероятность коллизии настолько малой, что ей можно пренебречь?

...
...
???

Интересная мысль, давайте посчитаем!

Возьмём для ID 128 бит — это немного, в память влезет.

Сколько это вариантов?

2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456

Это 340 ундециллионов. Число настолько огромное, что его сложно осознать.

Коллега-математик, с которым вы ходите вместе обедать помогает с прочувствовать масштаб:

— Представь: 10 триллионов компьютеров (это больше, чем людей на Земле) генерируют по миллиарду UUID каждую секунду. Непрерывно. В течение 100 лет. Даже в этом сценарии мы истратим меньше одной миллионной доли всех возможных комбинаций.

Впечатляет! Но как быть с парадоксом дней рождения?
Обсудим это далее

#guide #uuid

🌀 Сгустки Вакуума

Олды поплачут, а молодые посмеются

Будте осторожны, не сломайте свои дорогие аккуратно смазанные клавиатуры, когда будете писать слово "БОЯН!!!1", потому что я вам такое древнее зло раскопал, что это уже просто за гранью добра и зла 🧙

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

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

Русскоязычный оригинал тут, а главный оригинал-оригинал тут

Дальше цитирую историю как есть, без изменений

————

О, господи.

Сейчас я расскажу вам один Абсолютно Величайший Эпизод из жизни Реальной, но Слегка Долбанутой, Физики.

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

Важно, потому что для начала эксплуатации проекта, требовалось его утверждение в местном Гестапо Безопасности. Ну, вы знаете этих типов из "охраны труда и безопасности жизнедеятельности" - у них всегда есть список, нет, целый гроссбух списков с условиями и требованиями. Один из списков касался "Закрытых Объёмов". Камера достаточно велика, чтобы свободно ходить внутри? Есть! Она герметична? Есть! Может быть наполнена удушающим газом? Ну, учитывая что в официальном справочнике по опасным свойствам материалов "вакуум" проходит как "вызывающий удушье"- очевидно, есть. А значит, это Замкнутый Объём, и должны быть удовлетворены все требования, предъявляемые к Замкнутым Объёмам.

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

Проблема номер два: когда камера заново заполняется воздухом при атмосферном давлении, куда уходит вакуум? Если камера открывается случайно (см. выше, и обратите внимание на дословную цитату Гестаповца Безопасности: "ладно, допустим вы Супермен и открыли дверь"), куда уходит вакуум?

Проблема номер три: как обеспечивается то, что при заполнении камеры воздухом, в камере оказывается достаточный процент кислорода? Нет, полагаться на законы статистической газодинамики, дающие оценку вероятности заполнения камеры воздухом с недостаточным для дыхания процентом кислорода, порядка единицы на 10^10^17 (не опечатка) - очень, очень большая ошибка.

Проблема номер четыре - и клянусь, я ничего не придумываю - опять точная цитата Гестаповца Безопасности: "как вы можете быть уверены, что после заполнения камеры воздухом нигде не осталось "карманов" с вакуумом, в которые кто-нибудь может засунуть голову?"

И, в дополнение к проблеме номер два - при выпуске вакуума могут образовываться смертельные сгустки вакуума, плавающие в воздухе лаборатории! Аааааааа!!! Спасайся кто может!!!

Понадобилось всего три недели, чтобы найти кого-то, обладающего одновременно здравым смыслом и достаточной властью, чтобы победить Гестаповцев Безопасности в этом вопросе. Но ГБ-шники до сих пор воспринимают как оскорбление, когда кто-нибудь упоминает ЭТО в их присутствии.

Сгустки Вакуума.

#копипаста #история #баян

😩 UUID: А они ТОЧНО не закончатся? Математика коллизий

Итак, парадокс дней рождения: в группе из 23 человек вероятность совпадения дней рождения уже 50%. Может с ID так же?

Математик качает головой:

— Там всего 365 вариантов. У тебя 2^128. Совсем другой масштаб.

Он пишет формулу для вероятности коллизии при случайной генерации:

p ≈ n² / (2 × 2^128)

Где n — количество сгенерированных ID.

— Чтобы вероятность достигла хотя бы 50%, нужно сгенерировать примерно 2.6 × 10^18 идентификаторов. Это 2.6 квинтиллиона.

Вы прикидываете в уме:
— Если генерировать миллиард ID в секунду... это 85 лет непрерывной работы до 50% вероятности коллизии?

— Именно! А у тебя в системе будет что, миллионы объектов максимум? Можешь забыть о коллизиях.

————

Итак, решение: случайная генерация

Алгоритм простой:

1. Берём 128 бит
2. Резервируем несколько бит для служебной информации (версия, вариант)
3. Остальные заполняем случайными данными
...
...
PROFIT!!!

Получаем строки вот такого вида: 870bca25-7bff-499f-92c3-be78f41d681c

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

Выкатываем.. И оно работает! Система легко масштабируется, машины полностью автономны. Задача решена 🥂

————

🟢Это решение оказалось настолько удачным, что используется до сих пор — спустя 40+ лет.

Позже Microsoft позаимствовали эту идею для COM/DCOM под названием GUID (технически то же самое). В 2005 году вышел RFC 4122, который стандартизировал UUID, и сейчас это индустриальный стандарт.

Таким образом инженеры Apollo Computer элегантно решили фундаментальную проблему распределённых систем.

В следующем посте разберём, как UUID эволюционировали, какие версии появились и где всё это применяется на практике.

#guide #uuid

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

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

UUID — эволюция версий

Итак, мы изобрели UUID — случайные 128 бит, и это работает отлично. Проблема решена, можно расходиться?

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

————

UUID v1: Когда случайности не хватает

Вернёмся в 1980-90-е годы. Вы смотрите на свою реализацию UUID и думаете: а что если на какой-то машине плохой генератор случайных чисел? В те времена криптографически стойкая случайность была роскошью — не везде были качественные источники энтропии.

Вы решаете перестраховаться. Вместо полной случайности комбинируете несколько источников уникальности:

- Timestamp (60 бит) — время с точностью до 100 наносекунд
- Clock sequence (14 бит) — счётчик на случай откатов времени
- Node ID (48 бит) — ID машины (обычно MAC-адрес сетевой карты)

Логика железная: одна машина не выдаст два одинаковых timestamp, а разные машины не выдадут два одинаковых MAC-адреса. Гарантия уникальности даже без качественного генератора случайных чисел!

Выкатываем в прод. Работает. Но со временем замечаете проблемы.

- Privacy: MAC-адрес в UUID — утечка информации о железе.
- Предсказуемость: можно примерно определить когда и где создан объект. Злоумышленник может угадать ID других объектов.
- Невозможность сортировки: казалось бы, мы ведь вшили в UUID timestamp, значит по нему можно отсортировать? Увы, нет — мы думали только об уникальности, но не подумали, что может понадобиться сортировка. Поэтому мы закодировали timestamp не самым удобным образом, и UUID нельзя просто отсортировать как строки.

Из-за этого v1 используется редко. Но идея с timestamp ещё пригодится.

————

UUID v4: Эра хорошей случайности

Начало 2000-х. Хорошие генераторы случайных чисел стали стандартом. Тогда зачем усложнять? Делаем UUID полностью случайным!

Плюсы:
- Генерация тривиальна
- Невозможно угадать следующий UUID
- Не раскрывает информацию
- Нет зависимостей

Минусы:
- Случайный порядок убивает производительность индексов в БД
- Нельзя сортировать по времени

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

————

UUID v7: Возвращение timestamp

Прошло 20 лет. Ваша система выросла, нагрузка увеличилась в сотни раз, и теперь вставка записей с UUID v4 в БД стала узким местом.

При вставке с UUID v4 как primary key запись попадает в случайное место B-tree индекса — random I/O, фрагментация, медленно 😩

И тут вы вспоминаете про timestamp из v1 — идея была правильная, просто реализация хромала. Что ж, возвращаемся к истокам и размещаем в начале UUID timestamp. Теперь UUID можно сортировать хронологически!

Новые записи всегда в конце индекса — sequential I/O, быстрая вставка, меньше фрагментации. При этом 74 бита случайности — достаточно для уникальности. UUID v7 вобрал в себя лучшее из обоих миров.

🟠Но! Вместе с тем возвращается одна из проблем v1 — раскрытие информации, ведь в v7 вшито время создания. Если это проблема, то нужно возвращаться к v4.

————

😐 Так. А куда делись остальные версии?

- v2 (DCE Security) — специфичная версия для систем DCE. Настолько узкоспециализированная, что про неё почти никто не знает

- v3 и v5 (Name-based) — генерируются не случайно, а через хеширование имени (v3 использует MD5, v5 — SHA-1). Детерминированные: одинаковое имя всегда даёт одинаковый UUID. Используются редко, когда нужна воспроизводимость — например, генерация UUID из URL.

- v6 — попытка исправить v1 (переупорядочить timestamp правильно). Но появился почти одновременно с v7, который оказался лучше продуман.

А ещё есть v8 — это "custom" версия. Формат оставили открытым для экспериментов: можете закодировать данные как хотите, главное соблюдать общую структуру UUID.
По сути, нам сказали — мы больше не будем заниматься версионированием, справитесь сами 👍

Поэтому в реальной жизни вы встретите в основном v1, v4 и v7

————

Итого

Выбор версии зависит от задачи:
- Нужна максимальная случайность? → v4
- Производительность БД и сортировка? → v7
- Легаси? 🙃 → v1

#guide #uuid

🇯🇵Подкаст про айтишников из СНГ в Японии — GoGetPodcast

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

- Как айтишнику найти работу и переехать? (спойлер — гораздо проще, чем вы думаете)

- Рабочая культура: что на самом деле происходит в японских IT-компаниях

- Зарплаты vs стоимость жизни — честные цифры

- Как тут живётся, хорошее и плохое: жильё, быт, интеграция в общество, какие есть проблемы. Можно ли обойтись без японского языка?

- Культурные особенности, влияющие на работу и быт (и почему всё именно так)

Гости:

- Арсен Афунц — профессор японского университета, крутой специалист по Японии и великолепный гид. Знает местную культуру и историю лучше многих японцев — без преувеличений. Живёт в Японии с 2013 года.

- Алекс Каманин — DevOps-инженер в японской компании. Уже ~2,5 года в Токио. Такой же обычный работяга, как мы с вами: устроился, переехал и успешно освоился.

✨ Это идеальный дуэт: Алекс поделится личным опытом, а Арсен объяснит, почему здесь именно так — исторические и культурные причины и как с этим жить.

————

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

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

#gogetpodcast #japan

😐 К сожалению, запись этого выпуска с треском провалилась

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

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

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

К слову, завтра у меня будет ещё одна попытка записать выпуск оффлайн, но в этот раз в Астане и на другую тему. В этот раз точно получится! 👍

(об этом новом выпуске подкаста напишу в следующем посте).

🦄 LLM на практике — GoGetPodcast №19

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

К тому же прошлые разговоры были скорее «вширь»: про будущее, страхи и общие подходы. А в этот раз — вглубь. Суровая практика, мясо, конкретные инструменты и рабочие подходы.
Да и вообще — о чём сейчас говорить, если не про LLM? Я, кажется, уже и подкасты смотрю только про них.

Чтобы максимально раскрыть эту тему, я пригласил в гости Савву (контента в его канале пока нет, но я его заставлю, не сомневайтесь 🙂).
Мы познакомились с ним на встрече гоферов в Астане, где он поделился своим опытом работы с LLM.

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

Савва выжимает из AI-инструментов максимум и продвинулся в этом несравнимо дальше меня: запускает десятки автономных агентов (включая пайплайны и деплой), работает с целым зоопарком моделей — от тяжёлой артиллерии вроде Opus 4.5 до китайской GLM-4.6 (x15 к скорости генерации при качестве на уровне Sonnet 4.5, что реально меняет паттерны разработки).

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

Что обсудим:

- Инструментарий: как мы работаем с Claude Code и другими AI-инструментами

- Зоопарк моделей: когда использовать Opus, когда другие модели (включая китайские)

- Практические кейсы: рабочие задачи, кодогенерация, рефакторинг, документация, тестирование

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

- Китайские модели: стоит ли на них смотреть и что там интересного (спойлер — интересного много)

Если останется время, обсудим последние новости и куда всё движется. Куда ж без этого.

————

Это снова оффлайн запись, поэтому стрима не будет.

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

#gogetpodcast #анонс

🧠 Как учиться разработчику — разбираем методы обучения

Завтра будем записывать GoGetPodcat №20 — юбилейный выпуск. Я давно откладывал эту самую вкусную тему для такого случая 👍

🎞 Запись выложу на ютуб через пару дней. По поводу трансляции напишу в отдельном посте.

Состав:

- Глеб Яльчик
- Алексей Акулович

О чём поговорим?

Когда я встречаю очень умных людей, до которых мне как до Луны, меня всегда мучает вопрос — а как он учится? Что он читает? Как читает? А читает ли вообще? Как устроены его мозги??

Глеб и Лёша как раз такие люди, у них огромный багаж знаний и очень крутая экспертиза. Поэтому мы будем буквально вскрывать их мозги и выяснять, как они к этому пришли, перенимая полезный механизмы.
Будем учиться учитсья у лучших! 🤡

В разных выпусках мы не раз слышали советы от Глеба (и не только от него), пора бы уже собрать их воедино и обсудить подробнее, более структурировано.

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

————

Примерный план выпуска:

- Протокол погружения: как разбираться в новой сложной теме за 48 часов? Гугл? Дока? Ютуб с индусами? Звонок другу?

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

- Золотой фонд ресурсов: не просто список книг, а что конкретно они меняют в голове. От Language Spec до "книги с кабанчиком" — на каком этапе карьеры что читать?

- Обсудим культовые хиты — nand2tetris, "Код" Петцольда, Deadlock Empire и др.

- Алгоритмы: положа руку на сердце — как ВЫ их учили? В универе, на LeetCode или по Кнуту перед сном?

————

🟠Это не холивар на тему "нужна ли база" и "нужно ли учиться". Это попытка найти отличие в мышлении эксперта от новичка и вытащить конкретные алгоритмы.

Пишите ваши вопросы в комментах — самые интересные возьмём в выпуск.

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

#gogetpodcast #обучение

🎞 А стрим будет?

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

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

Но! Я буду транслировать запись для подписчиков моего закрытого ТГ-канала и моего бусти. Так что, если хотите посмотреть на нас вживую, задать свои вопросы, либо просто поддержать моё творчество и наш подкаст, милости просим.

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

————

Оно может и навредит алгоритмам продвижения, но зато будет компенсация 👍

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

#gogetpodcast

Выпуск про LLM всё ещё монтируется 😩

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

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

Будет готово примерно 25-26 декабря.

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

В любом случае, до Нового года надо точно успеть 🎄

#gogetpodcast

Как разработчику эффективно работать с AI в 2026 году?

— Преодолевать галлюцинации ИИ и экономить токены;
— Ускорять разработку в Cursor, Claude Code, Codex;
— Работать с большими объёмами информации и сводить разрозненные данные в единое решение.

Обо всем этом и не только расскажут ребята из Interview Hustlers на AI интенсиве, после которого при работе с нейронками у вас не возникнет мысли:

«потратил полдня на фигню, лучше бы сразу сам всё написал»

Потому что дело не в ИИ, а в подходе 🙌

Что будет на AI Интенсиве?

📍1 день (23 декабря): База по ИИ — как выглядит работа с нейронками, вводная теория по LLM, как преодолевать галлюцинации, как экономить токены при запросах и как задавать «контекст» для задач и выстраивать работу с агентами.

📍2 день (24 декабря): 8 рабочих лайфхаков по ускорению разработки в Cursor, Claude Code, Codex. И обзор AI-инструментов для работы и жизни: умный терминал, запись звонков, код-ревью и др.

📍3 день (25 декабря): Разберем практические кейсы для бэкендеров, фронтендеров и т.д, как писать код в новом проекте, решать любой баг без единой строчки кода и делать код-ревью с AI

Спикеры:
▪️Максим Аверин — основатель школы Interview Hustlers
▪️Максим Карась — Senior Golang Dev, ex-Tinkoff (LLM команда)

Регистрируйся на бесплатный AI Интенсив ссылке: http://t.me/hustlers_aibootcamp_bot?start=int_tgrekl

📎 После регистрации ты получишь БОНУС — «Как разобрать неудачное собеседование без фидбека за 3 шага с AI?»

#промо #текст_прислан

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

Как говорит классик — это оригинальный монтаж. И так весь выпуск.

Если у вас возникает вопрос — "а что здесь не так?", ты вы счастливые люди, я даже немного завидую.

Оператор, он же владелец студии, справился шикарно, картинка мне очень понравилась. Но я подозреваю, что монтажёра он удерживает в подвале насильно.

#gogetpodcast

😩 Да зачем нужна эта ваша база?

Представим, что у нас есть мусорное ведро, встроенное в пол. Видим только отверстие сверху — «интерфейс». Кидаем мусор, он пропадает. Работает? Работает.

Зачем вообще разбираться, как оно там устроено внутри? Если встретим проблемы — разберёмся по ходу дела. Главное, что свою задачу оно решает. Правильно?

1. Но вот пытаемся выкинуть длинную трубу — не влезает. Гуглим (либо спрашиваем у ChatGPT): «как выкинуть длинную трубу в ведро». Находим: «длинные трубы пихать нельзя». Ок, запомнили.

2. Выкидываем тысячу мячиков для гольфа — не влезают. Снова Гугл. Ответ: «В ведро влезает только 100 мячиков». Записали.

3. Высыпаем сахар — через минуту смотрим, а его там нет. Куда делся? Гуглим, получаем ответ: «сахар медленно высыпается из ведра».

...

999. Льём воду — она исчезает почти мгновенно. «Почему вода пропала сразу?» — «Потому что вода жидкая и выливается быстрее».

————

И таких кейсов тысячи. Можно запоминать их все, собирать коллекцию решений как покемонов и «копить знания».

А можно просто достать это чёртово ведро и посмотреть на него. И сразу всё становится очевидно:

- Труба не влезет — она длиннее любого измерения ведра
- Понимаем объём — знаем сколько туда насыпать мячиков
- Видим, что ведро сетчатое — сахар будет медленно высыпаться, вода быстро

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

Это и есть разница между «знанием интерфейса» и «знанием базы».

Первое — это коллекция рецептов: «если X, то делай Y». Работает, пока не встретим ситуацию, которую не гуглили.

Второе — это понимание устройства. Оно переносит нас на новый уровень: мы перестаём воспринимать ограничения как «ошибки» или «магию». Просто знаем, почему оно так работает.

Именно поэтому разработчикам важно понимать, как устроены под капотом технологии, которые они используют. File descriptors, TCP backlog, буферизация I/O — всё то же самое ведро, только сложнее.

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

#guide

👴 Знание базы — практические примеры

Теперь давайте перейдём от абстрактных примеров с вёдрами к более реалистичным

File Descriptors

Веб-сервер под нагрузкой падает с Too many open files. Гуглим, находим ulimit -n 65535. Вбиваем, вроде заработало.

А можно понять, что каждое открытое TCP-соединение в Unix-системах — это file descriptor. Да, в Unix «всё есть файл», и сетевое соединение — не исключение.

Дескриптор же — это просто индекс в массиве указателей, который ядро ОС хранит для каждого процесса. Когда делаешь socket() или open(), ядро ищет первую свободную ячейку в этом массиве и возвращает её номер.

И тогда сразу ясно:

- Почему дескрипторы заканчиваются (массив конечный)
- Что делает ulimit (увеличивает размер этого массива)
- Почему важно делать close() на соединениях (освобождать ячейки)
- Почему просто увеличить лимит — это костыль, а не решение утечки ресурсов
- Почему при 10000 одновременных соединений нужно ~10000 дескрипторов

TCP Backlog

Сервис падает с Connection Refused, хотя CPU не нагружен. Гуглим ошибку, находим что-то про net.core.somaxconn и listen backlog. Увеличиваем, вроде помогло (а может и не помогло).

А можно понимать, что у ядра есть две очереди для входящих соединений:
- SYN Queue (для начавших хэндшэйк)
- Accept Queue (для завершивших, но ещё не обработанных приложением)

Если приложение тормозит на записи в БД и медленно вызывает accept(), Accept Queue переполняется. Новые клиенты получают отлуп, хотя сам сервер свободен.

Понимая это, мы не тупо увеличиваем net.core.somaxconn, а смотрим — почему приложение медленно разбирает очередь.

Буферизация I/O

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

А можно понимать, что стандартные библиотеки логирования используют буфер в user-space (обычно 4-8 KB). Данные не уходят в write() сразу — только при заполнении буфера или явном flush().

При краше процесса буфер в RAM теряется. Поэтому при отладке критичных мест используем flush() после каждой записи или пишем в stderr (он не буферизируется).

(И даже write() не гарантирует запись на диск — данные сначала идут в page cache ядра, для гарантии нужен fsync(), но это уже другая история)

Float и деньги...

А теперь вы работаете с деньгами — обрабатываете платежи, храните информацию о счетах пользователей. Какой тип использовать? Очевидно — Float. И тут вы.. Ладно, забудьте всё вышесказанное, базу знать не надо 🌚

#guide