this->notes.

#highload

Принёс отдельные доклады с Яндекс Tech Tour (в прошлом году это был foodtech tour, на котором я выступал в Минске).

1️⃣ Как мы переосмыслили поиск лекарств в Яндекс Еде. Сергей Синягин.

Когда вы открываете Еду, ищутся все доступные вам заведения. И бывает, что вам доступны несколько заведений одного бренда. Тогда заведения дедуплицируются и остаётся какое-то одно. Проблема в том, что в этом заведении может не быть нужного вам товара (например конкретных таблеток в конкретной аптеке), а в отброшенным они были!
Серёжа рассказывает, как меняли архитектуру, чтобы уметь чаще удовлетворять пользовательские запросы.

2️⃣ Как мы пересобрали инфраструктуру Маркета и не сломали всё вокруг. Егор Быховцев.

Егор рассказывает про изменение концепции оркестрации в бэкенде Маркета.
Буквально недавно меня убедили, что такое крута. Я верю. После доклада Егора убедился ещё больше.
Внутри и снаружи решение называется apphost. Глядишь, выкатят в опенсорс скоро.

3️⃣ LLM Cache в поиске Лавки. Алексей Щекалев.

Лёша рассказывает тлдр про развитие поиска в Лавке.
Раз у нас ассортимент небольшой, то можно сделать кеш ответов на самые популярные запросы. Вот ребята это и сделали.
Имхо решение бомба. Наикрасивейше. Это не только про качество, но и про тайминги.
Ещё круто, что ребята затащили это в т.ч. в Еду. Круто, когда внутри экосистемы один сервис чуть ли не бесплатно помогает другому крутыми технологиями.

4️⃣ Event-Driven архитектура в Цикле Заказа Яндекс Лавки. Миша Горбушин.

Миша рассказывает про ЦЗ Лавки, зачем его делали event-driven, собсна как это делали. И про разные проблемы по пути.

5️⃣ Как разрабатывают и улучшают алгоритмы логистики в Яндекс Еде. Дима Ефимов.

Дима рассказывает про процесс улучшения алгоритмов доставки в Еде. В целом из чего доставка состоит. На какие метрики смотрят. Про разные уникальности доставки и местные АБ.

#books

Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон. (2021г.)

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

Микросервисы рассматриваются с самых разных сторон. Оглавление такое:
1. Побег из монолитного ада: как жить с монолитом, почему это удобно, pros and cons микросервисов и процессы вокруг. В общем база.
2. Стратегии декомпозиции: как разбить вашу систему на микросервисы в разных плоскостях. Что важно, это не про вынос микросервиса, а про проектирование с нуля.
3. Межпроцессное взаимодействие в микросервисной архитектуры: REST, gRPC, синхронные/асинхронные вызовы.
4. Управление транзакциями с помощью повествований.
5. Проектирование бизнес-логики в микросервисной архитектуре.
6. Разработка бизнес-логики с порождением событий (event driven like системы).
7. Реализация запросов в микросервисной архитектуре.
Про API, CQRS.
8. Шаблоны внешних API.
Про проблемы поддержания внешнего API и api-gateway.
9. Тестирование микросервисов 1.
Общие понятия. Модульные тесты.
10. Тестирование микросервисов 2.
Интеграционные, компонентные и «сквозные» тесты.
11. Разработка сервисов, готовых к промышленному использованию.
Безопасность, конфигурируемость, observability.
12. Развёртывание микросервисов.
Docker, kubernetes, serverless (AWS Lambda).
13. Процесс перехода на микросервисы.
Про то, как взять ваш монолит и распилить его на куски.

Каждая глава сдобрена практическими примерами. В рамках книги сквозной историей разбирается развитие абстрактного ecom приложения FTGO. Можно считать дефолтной доставкой чего-либо. И в каждой главе показывается применение описанных паттернов.

Есть несколько тем, которые мне подарила эта книга. Под «подарила» я понимаю раскрыть базовое понимание, хотя раньше я этого базового понимания насобирать не смог (хотя и не то чтобы пытался, но тут я тоже не пытался, а получилось):
- GraphQL. Выглядит очень прикольно. Прям ощущаю, насколько полезно это может быть в некоторых случаях. Может быть нам пригодилось бы.
- JWT, OAuth.
- Docker, kubernetes. Оказывается, в Яндексе я несколько лет пользовался внутренним аналогом последнего.
- serverless. Честно говоря, я не до конца осознал, но теперь я точно перестану скипать статьи про подобное и дам себе шанс разобраться глубже. Выглядит интересно.

Несколько минусов:
- текст местами без причины сложный.
Бывают предложения, которые можно упростить без потери смысла. Возможно это просто стиль письма у автора. Но материал и так сложный, а когда про него ещё и сложно пишут, становится тяжелее в квадрате. Не надо так.
- [относится к русскому изданию] книга чрезмерно локализована.
Endpoint назван «конечной точкой», а mock в теме тестирования «макетом». Сразу видно руку технического переводчика. REST, gRPC и CQRS не переведены, а вот эти термины да. Хотя имхо стоило бы их оставить как есть. Это мешает пониманию (мне, человеку с опытом, приходится прикладывать усилия для понимания простых предложений с этими терминами).

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

7/10.

#cpp

Сегодня Папа C++ в русскоязычном коммьюнити (Антон Полухин) рассказывал про новости комитета стандартизации. В частности C++26.

Контент:

- новая фича (Антон утверждает, что это полезно для метапроги)

Тут Антон показывал, как можно сделать утилитку sequence<N>, чтобы заработал такой пример:

auto [i1, i2, i3] = sequence<3>{}; // 0 1 2

Теперь такое из коробки работает для std::integer_sequence (C++26).

- compile time std::format, что улучшает читаемость ошибок компиляции

- контракты 🤝 hardening (друзья на век)

- рефлексия:
- в рефлексии доступность к приватным членам класса на месте
- consteval block

- баги всякие
- может быть успеют поправить P3725
- ub в <type_traits>: работа с incomplete типами (не оч корректна)
- basic_string::append/assign принимают std::string (потенциально лишние копии)
- uniform_uint_distribution<uint8_t> == ub
- и ещё много других!

И всякие добавляшки.

Живём!

#list

0. [talk] Cutting C++ Exception Time by 93.4%.

Khalil Estell рассказывает про то, как он срезает косты при использовании икслючений на железках.
Как настоящий сварщик, он взял самые жирные куски и по одному их поускорял. Причём ускорения довольно прикольные. Местами их сложность примерно около нуля. Но это ж надо было додуматься всё равно!
Ещё чувак очень естественно выглядит на сцене. Мегауверенно. Будем у него учиться.

1. [article] C++20 idioms for parameter packs.

Солиднейшая статья про variadic templates.
Первая треть фокусируется на базе: какие бывают, где можно писать, где нельзя (рекомендую вчитаться, даже если разбираетесь; я нашёл для себя несколько интересностей).
Вторая-третья на идиомах, которые сегодня помогают делать красивое полезное.
Местами ту мач формальная, но я давно убеждён, что C++ сообщество -- сборище душных персон, которые за незнание каждой буквы в стандарте готовы публично растерзать (я сам душный, но не настолько, к счастью).

2. [article] How does it work - The Log-Structured Merge (LSM) Tree.

Там немного пролистайте вниз к теме.

3. [talk] Intro to Large Language Models.

Лекция двухлетней давности от Andrej Karpathy про устройство LLM, как они живут, учатся и ломаются.
Кажется, это что-то фундаментальное на года, что можно будет ещё детям показать для общего развития.

4. [fact] std::optional::value

Смотрел Understanding Optimizers: Helping the Compiler Help You, в котором докладчик говорит про то, что код с std::optional вида

if (x) y = x.value()

превращается в

if (x.m_active) {
  if (x.m_active) {
    y = x.m_data;
  } else { throw ...; }
}

И он прав. Это прям хороший наглядный пример лишнего чека и нашего с вами перфа. Но вопрос не только в двойной проверке. Вопрос в исключении. Мы у себя стараемся юзать std::optional::value просто потому что когда проверка вдруг потерялась, вы полусаете адекватное исключение с понятной ошибкой. Да, проблему надо ещё поискать, но по крайней мере понятно, что искать.
Проверку потерять нереально? Конечно это не так. Код бывает разный. Рефакторинги регулярными. Вообще на раз два.
Короче делаем трейдоф перфоманс-скорость дебага проблем в сторону последнего.

Правда я умолчал о важном моменте. Докладчик всё-таки отмечает, что компилятор не делает лишних проверок. Всё там в порядке.

=============================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#cpp

Время -- деньги.

Стандарт говорит [упрощая], что компиляторы должны поддерживать только наблюдаемое поведение. А как он там это делает, это уже его дело.

Есть несколько уровней оптимизаций.

O0 (о ноль)

База. Компилятор делает минимальный анализ и минимальное кол-во оптимизаций. Сохраняется полная семантика программы. Дефолтный вариант. Идеально для дебага.

O1

Компилятор применяет простые оптимизации без сложного анализа: dead code elimination, constant propagation, basic inlining.
У GCC тут уже 48 оптимизаций.
Используется редко, когда не хочется сильно замедлить компиляцию очень больших программ (друг отметил, что это нужно только маргиналам).

O2

Самый народный уровень.
Множество оптимизаций без speed-space трейдофа: unroll loops, vectorization, strict aliasing.

O3

Включаем максимальный перфоманс отдельной программы. Всё ради скорости. Более агрессивно оптимизируем циклы, больше инлайним, больше векторизируем. Из-за сильной векторизации и инлайнинга бинарник может сильно раздуваться. В том числе поэтому перф может падать, так что на практике не всегда является более оптимальным (при небольшом instruction cache вы станете чаще кешмиссить).
Если увлекаетесь, можно включать при компиляции отдельных файлов, код в которых точно в плюсе. Не задевая всё остальное.

Ofast

Как O3, но включаются опасные оптимизации. Например --ffast-math.
Почему опасные? Потому что скорость получается за счёт точности. Про артефакты можно почитать в Beware of fast-math.

Og (оуджи)

Og = O0 + некоторые оптимизации из O1, не ухудшающие debug experience.

Os

Os = оптимизации из O2, не увеличивающие размер кода + некоторые дополнительные, позволяющие сократить размер исполняемого кода. Трейдофим немного, но в меру.

Oz

Когда у вас мощнейшие ограничения по размеру бинарника и использованию памяти, выбираем Oz. Заодно можно просадить и перф. Но иногда в embedded только так.
Может увеличить кол-во исполняемых инструкций, если их можно закодировать меньшим кол-вом байтов.
Дебагать может быть тоже уже нереально больно. Но как есть.

Мы не говорим про LTO (и ThinLTO) и PGO. Мы не говорим про -march=... и другие. Может когда-нибудь потом..

Доклад в тему: What GCC optimization level is best for you?
В докладе про сами оптимизации и много сравнения с LLVM в разных плоскостях по разным оптимизациям. Может быть полезно, если хотите осознать, какой компилятор лучше под ваши конкретные нужды, т.к. трейдофы выбирают разные.

#list

0. [talk] The Evolution of std::optional - From Boost to C++26.

Начинается сезон CppCon2025.

Steve Downey рассказывает про std::optional и, что больше ему свойственно, т.к. он там что-то предлагает по теме в стандарт, std::optional<T&>. Там общие концепции, сложные вопросы "как должны себя вести в ситуациях А Б В". Что делать с такими-то методами.
И местами приятные примеры кода из C++-современного/C++-будущего. Повышаем насмотренность. Набиваем руки.
Что прикольно, докладчик рассказывает про профит от участия в Beman project: нашли багу в потенциальной реализации std::optional<T&>.

1. [article] Итоги встречи ISO C++ на Гавайях: начинаем полировку стандарта С++26.

Антон Полухин рассказывает новости очередной встречи комитета.

2. [article] Metastable Failures in the Wild.

Я вам уже рассказывал про metastable failures и Лёшу Быкова (@it_tldr). Добрался осознанно перечитать некоторые статьи из ссылок в его докладе.
Метастатья про разные найденные на просторах инциденты, связанные как раз с metastable failures. Там общие описания, небольшая статистика (например, в >50% случаев, ретраи были фактором, мещающим системе самовосстановиться) и разбор деталей некоторых инцидентов. Что забавно, есть такой кусок:

While publicly available incident reports provide enough high-level information to identify the metastable failures, they lack the depth and detail to understand the complex interactions between components in large systems. In this case study, we use insider information to describe in detail one specific metastable failure occurring at Twitter, a large internet company, due to garbage collection (GC).

Т.е. кто-то ребятам nda слил, а они и рады это описать. Похехал.

3. [article] Код-гольф в Яндексе: как нерды развлекаются.

Помните, я вам писал про военный синус от Паши Сухова?
Паша весь этот год прикладывал (и продолжает) руку к активностям на митапах и конференциях Яндекса. Делает код-гольф. Не знаете что это? Примеры задач и решений не видели? Ну почитайте его статью!

А ещё, прикиньте, он услышал запросы трудящихся и дропнул канал себе: @cpp_durka. Ничего не обещает, но вы приходите.

4. [book] Корпорация гениев. Как управлять командой творческих людей. Эд Кэтмелл.

Это не обзор в обычном смысле. Просто поделюсь наблюдением.

Книжка рассказывает про молодые годы Pixar, как чуваки искали своё место на рынке, Стива Джобса и процессы в компании.
И хотя Pixar когда-то давно это совсем не айтишечка, там можно увидеть знакомые сегодня штуки.
Например у чуваков был brain trust -- собрание ответственных коллег, которые ревьюили разные решения в производстве мультиков у ответственных. Я, слушая, подумал "Пфф, это ж архитектурное ревью. Мы такое сто лет у себя уже делаем".
Или автор рассказывает про то, как случайно удалили огромный кусок работы, запаниковали, нашли бекап недельной давности у коллеги дома, восстановили и сели думать, как такого больше не допустить. Не винили ответственного. Сделали какие-то action item'ы для неповторения. Тут я подумал "Пфф. Чуваки придумали инцидент менеджмент. Что ж тут такого?".
А потом я осознал, что это мне в 2к25 всё понятно и очевидно. А у них не было примеров. Им некуда было смотреть. Они буквально чуть ли не первые, кто начал делать подобные вещи и сделал из них процессы. А потом уже спустя 10-15-20 лет я считаю это базой.
Сложно воспринимать идеи из прошлого. Надо осознанно заставлять себя возвращаться в то время, в тот контекст. Особенно сложно, когда ты не знаешь контекста. Но если получается, иногда всё-таки можно ощутить прорыв.

================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

=====

Картинка кринж или норм?

#list

0. [talk] What Every Programmer Should Know about How CPUs Work.

Matt Godbolt наваливает баса и рассказывает базу про устройство CPU. Я не очень погружён, потому мне понравилось. Хороший кусок уделяется общему пайплайну, branch predictor'у и ещё немного execute инструкций.

1. [article] The Art of Formatting Code.

Статья про форматирование кода, правда в итоге не кода, а JSON, но поверьте, этого с головой достаточно.
Примеры кстати на Rust. Довольны???

2. [article] Expert Generalists.

Martin Fowler с друзьями рассказывает про концепцию expert generalists: кто такие, какие качества, зачем нужны, как оценить, как растить и ещё пару мелочей.

3. [talk] Анатомия асинхронных движков.

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

Это кстати C++ Zero Cost Conf 2021. Первая.

4. [article] How to Increase Your Luck Surface Area.

Нравится вам это или нет, важно говорить про то, что вы делаете. Современные иерархии в больших компаниях не могут естественным образом привести к тому, что про ваши успехи будут знать все вокруг (а это чаще всего жизненно необходимо для ваших финансовых результатов). Так что надо идти и как-то рассказывать про успехи.
В конце очень хорошая картинка. У вас есть несколько вариантов, но показательнее всего мне кажется такая развилка: можно либо делать достаточно, но правильно и много про это говорить (best), либо делать очень много и почти про это не говорить (тоже best, но другой ценой).
Языком чесать не мешки ворочать, как известно. Так что делитесь время от времени своими успехами (и не только).

================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#algo

Бинарный поиск -- чуть ли не первый алгоритм, который мы узнаем.
Ну я по крайней мере.
Я его увидел когда-то Грокаем алгоритмы, а потом на спор угадывал число одноклассника от 1 до 4kkk за 32 попытки (не получилось: т.к. я считал в уме, погрешность вычислений в голове привела меня к отрезку длиной 8 на последнюю попытку; получил заслуженный фофан).

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

Потом я думал про условный тернарный поиск, чтобы отсекать сразу 2/3 ответов, а не половину. Ничего не придумал.
Он используется, но в других местах.

Недавно попался доклад на P99 про ускорение бинарного поиска, но перед ним надо посмотреть на другой.

Оптимизируем бинарный поиск Сергея Слотина с C++ Zero Cost Conf 2022 (english версия с CppCon того же года; рекомендую её, т.к. в неё чуть больше поместилось).

Оптимизировать бинпоиск по Сергею Слотину это:
👍 избавляться от сложнопредсказуемого бранча
👍 префетчить потенциальные куски памяти
😎 менять memory layout, например с помощью Eytzinger нумерации
🤓 уходить в B-tree like укладывание элементов (S-tree)
🤔 улучшать с помощью B+-tree like оптимизации (S+-tree)

А на P99 был доклад от Ragnar Groot про докручивание решения выше, только на Rust.

Отойдя в сторону, есть вариация бинарного поиска, известная под названием Shar's algorithm, когда вместо поддержания двух границ вы сдвигаете индекс на степень двойки.
Тут прикольная статья про то, как автор генерировал код на D для решения задачи на массивах статического размера.
Некоторое развитие и на C++ есть у другого автора.

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

Как говорил Сергей в докладе, есть и другие варианты.
Например, для маленького множества ключей можно заранее предпосчитать ответ на каждый возможный запрос и хранить их в lookup table (LUT) (для 8-16 байтовых типов это делается быстро и не очень дорого по памяти).
Если типы пошире, можно изменить вид LUT и в старших битах хранить границы более узкого отрезка, что позволяет изначально сокращать задачу бинпоиска на несколько итераций.
Подробнее это описано тут.

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

И не прям про бинпоиск, но под руку попался доклад, на который ссылаются разные бинпоиск статьи, хотя там рассказываются в целом общие идеи и корутины: Gor Nishanov «Nano-coroutines to the Rescue! (Using Coroutines TS, of Course)».

Рядом упомянем и другие вариации:
- exponential search для больших размеров
- fibonacci search для старых архитектур, т.к. там нужно только сложение и вычитание -> выполняется быстрее
- jump search, в котором минимизируется кол-во скачков назад (нужно только мамонтам имхо)
- fractional cascading позволяет оптимизировать задачу нахождения одного числа в нескольких массивах

И раз мы считаем среднее между двумя числами, вот доклад про std::midpoint. Там не всё так просто!

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

Есть что-то добавить по теме?

#list

0. [talk] Modernizing Compiler Design for Carbon Toolchain.

Chandler Carruth рассказывает про базовый дизайн современных компиляторов, который уходит в решения 50летней давности, и делится ограничениями такого подхода, после чего рассказывает про новые подходы и решения, применённые при реализации компилятора для Carbon, что позволило научиться компилировать язык очень эффективно и быстро.
Нормальная такая волына этот доклад.

1. [article] Diff Algorithms.

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

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

2. [article] Life Altering Postgresql Patterns.

Набор рекомендаций, которые могут сильно облегчить жизнь при работе с postgres. Там что-то вида: юзайте uuid, всегда имейте created_at и updated_at, юзайте енамы, используйте схемы и др.
Местами база, местами я ещё не думал и не встречал связанных проблем. Но там где встречал, на сто процентов уверен, что рекомендации к месту и не раз экономили мне кучу времени и нервов.

3. [article] Build Your Own Database.

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

4. [article] 500 Miles.

"We're having a problem sending email out of the department."
"What's the problem?" I asked.
"We can't send mail more than 500 miles," the chairman explained.
I choked on my latte. "Come again?"

===================================

27 ноября в Екатеринбурге будет Pytup от коллег.
Мероприятий в регионах не так много, потому можно и сгонять. Тем более должно быть интересно.
Ссылочка на регистрацию.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

И анонс от друзей.

22 ноября в Москве пройдёт System Level Meetup от YADRO.

Там 2 трека: regular C++ и C/Linux kernel.
Будем честными, второй меня не сильно интересует, но может кому-то из вас подойдёт.
А в первом каждый первый доклад звучит солидно:
- корутинные оптимизации в компиляторах от Константина Владимирова и коллеги
- про затягивание модулей в существующий проект (Антон Полухин про это рассказывал уже на Zero Cost Conf в этом году, но сейчас такое время, что нам нужно больше позитивного опыта внедрения)
- про production-ready LRU-кеш от Ильи Шишкова
- про оптимизацию kd-tree от Саши Голубева
- про чекеры в clang-tidy от Анастасии Черниковой
- и про строки от Антона Полухина.

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

Ссылочка на регистрацию.

#books #ml

System Design. Машинное обучение. Подготовка к сложному интервью. Алекс Сюй, Али Аминиан.

Книга про подготовку к сисдиз интервью в направлении ML.

Структура ожидаемая:
- введение и общие сведения (общая информация про флоу собеседования с пояснениями по каждому этапу)
- 10 глав с разбором различных кейсов по проектированию ML фичей: поиск видео на YouTube, обнаружение вредоносного контента, рекомендации видео/событий/знакомых юзеров и прочее.

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

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

С точки зрения «я не мльщик» мне понравилось. Некоторые вещи объясняются с нуля, что позволяет осознать концепции (большинство), даже если ранее с ними не встречался. Мне понравилось в качестве материала, который позволяет узнать что-нибудь про базовые мльные системы, пусть даже и на спичках.

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

Важно, что мне именно показалось.

Я попросил друга с опытом в сфере прочитать рандомную главу и поделиться впечатлениями (его LinkedIn). Тезисы от него такие:
- для базового понимания топ
- местами есть формулы, но они не объясняются (т.е. иногда с полученными пояснениями сложно вспомнить, что конкретно она делает)
- над картинками не сильно заморачивались (хочу отметить, что мой друг -- эстет)
- модели вроде поясняются, но недостаточно глубоко. Если бы я не знал, то я бы не вспомнил
- на реальных собесах больше углубляются в матчасть и говорят про ML. Тут же книга ориентируется больше на бизнес-сторону задачи, что, конечно, хорошо, если у тебя мало в этом опыта, но недостаточно покрывает реальные интервью.

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

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

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

Резюмируя, хорошая книга по верхам бизнес-куска ML сисдиза. Так сказать, необходимо, но недостаточно.

Много ещё хвалят Alex Xu книжку про подготовку к классическому сисдизу. Я этого мнения не разделяю. Она тоже сильно оторвана от реальности. Гораздо полезнее сидеть на YouTube и смотреть моки реальных собеседований, желательно Senior+ уровня. Смотреть разборы задач с собеседований. Смотреть про самые популярные технологии и их возможности. Просто потому что любой нормальный видос по теме даст вам гораздо больше практической информации, которую в книгах, почему-то, не пишут.
Наверное потому что писать в книге про детали десяти баз данных некачественно нельзя. Лучше и не начинать.

Читается за 5.5 часов.

6 собеседований из 9.

#list

0. [talk] Video Game Hacking using Kotlin/Native.

Не самый профильный для канала доклад, но не менее от этого интересный. Докладчик рассказывает про то, как хакал GTA San Andreas с помощью Kotlin. Жоской специфики Kotlin'а там нет, а выглядит это всё замечательно. Нравица.

1. [article] did u ever read so hard u accidentally wrote?

Интересное расследование про то, что чтения в postgres что-то иногда да пишут. Очень круто, глубоко и непонятно.

2. [article] Hidden Messages in Emojis and Hacking the US Treasury.

В декабре прошлого года был инцидент в казначействе трампосударства. Чувак рассказывает, как базовичковая (или нет?) SQL инъекция сделала своё дело.

3. [article] Some of My Favorite Things – Postgres Queries.

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

4. [post] Как мы переписывали репликацию корзин.

===================================

Год назад я выступал на нашем митапе в Минске с темой про оптимизацию разработки в моей команде. Там была на самом деле серия митапов в разных городах.
В этом году коллеги тоже ездят. На ближайшее время планы такие:
- 15 ноября в Казани:
- про AI-ассистента в Маркете
- про переосмысление поиска лекарств в Еде
- про пересборку инфры Маркета
- !и! про LLM Cache в поиске Лавки
- 22 ноября в Нижнем Новгороде
- про скидки в Еде
- про сохранение консистентности данных о товарах в Маркете (кстати нам сейчас очень релевантно; мы не то чтобы хотим устранять разночтения, но уже движемся в сторону усложнения этого места ради роста гибкости)
- про event-driven цикл заказа в Лавке
- и про алгоритмы логистики в Еде
В обоих городах сверху будут ещё кейслабы, вайбкодинг сессии, код-гольф (обнаружите знакомое лицо тут? :) ) и настолка про разработку.

Регистрация и туда, и сюда по ссылке.

Ну а я принесу вам записи, как только они появятся.

Был кстати в этом году и в Казани, и в Нижнем Новгороде. Понравилось.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#common

Я провёл >100 собеседований. Нанял несколько человек. И что-то понял.

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

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

Вы можете быть бесконечно крутым IC, но если вы хотите сидеть в углу и разговаривать только с руководителем раз в неделю на 1х1, то это не к нам. Ну вот так.

При этом всем хочется иметь адекватных коллег. Адекватность проверяется в первую очередь общением. Когда к тебе приходит приятный(-ая) кандидат(ка) и шутки шутит между решением задачек, это круто. У нас вся команда такая. Мы цитаты из Реальных пацанов на дейликах вспоминаем на скорость. Если все такие и ты такой(ая), будет проще работать. Личные отношения укрепляются. Это позитивно сказывается на качестве работы (вовремя узнаёшь новости, инсайты, чаще обсуждаешь мысли -> быстрее принимаешь решения и делаешь проекты, не упускаешь происходящее).

Важны и харды, конечно же. Они не важнее совместимости с командой, но всё же задачи надо делать.

Есть отличные статьи про процесс собеседований в бигтехи. НА МОЙ ЛИЧНЫЙ ВЗГЛЯД это незрелая точка зрения. Не подкреплённая фактами. Которая разбивается на раз-два в момент, когда внутри ты начинаешь вникать, как и что работает на самом деле. Просто людям нравится толпой кричать, какие большие компании плохие. Такой у них рок.

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

Во-первых, часто кандидаты недовольны скоростью происходящего (много собесов == долго). Мол можно десять раз отсобеседоваться в другие компании уже.
Разумный кандидат убегать за первым же оффером не будет. Я не буду подробно раскрывать.

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

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

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

Самое важное правило, которое я вынес для себя при найме: есть только два ответа: "hell yeah" или "no".

Брать человека только потому что "ну он(а) вроде норм", а мы уже как-то долго ищем кандидата, не надо. Брать надо только когда ты прям хочешь этого конкретного человека в команду.

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

Больше отступать не буду.

#cpp

Сегодня небольшой рассказ про недавний баг.

Опять UB моими руками.

https://github.com/dasfex/articles/blob/trunk/one_more_ub.md

#list

0. [talk] Challenges and Benefits of Upgrading Sea of Thieves From C++14 to C++20.

Ещё одна история про стоимость поддержки больших проектов: как Sea of Thieves переезжали на 2 стандарта вперёд. Довольно жирных.
Внутри конкретные кейсы и проблемы и заодно общие рассуждения про то, насколько нереально делать подобные шаги.

1. [article] Building a web search engine from scratch in two months with 3 billion neural embeddings.

Автор рассказывает про то, как он сделал поисковый движок с нуля. Мотивация: раскачаться + сделать себе норм поиск, который будет выдавать действительно релевантные результаты, а не SEO-optimized контент, и будет отвечать на семантические вопросы, а не просто заниматься keyword матчингом. Типа perplexity на минималках.
Покрывает следующие темы:
- нормализация данных (честно парсит интернет)
- chunking текста, т.к. моделька не может кушать большими кусками (она же не Робин Бобин Барабек)
- crawler
- построение общего пайплайна движка
- хранение всего этого дела
- про решение задачи discovery своих сервисов, и в целом тут чуть больше про стековые/девопс проблемы
- GPU
- шардирование HNSW (не путать с NSFW)
- оптимизацию латенси
- ещё несколько бизнесовых фичей, которые автору просто захотелось
- рассуждения про качество поиска
- 💵💵💵бабки💵💵💵
- заключение.

Текст жирный. Интересный. Местами сложный. Кайфуйте.

2. [article] Expression Templates in C++.

Автор рассказывает про expression templates: где применяются, пишет простую версию для вычисления выражения вида a * b + c и применяет этот механизм для реализации chained comparisons в C++.
Приключение на 20 минут. Не очень сложное, но и не базовичковое. Приятный хороший технический текст.

3. [article] Succinct data structures.

Автор делится своим открытием сжатых структур данных. В статье описание базовых структур, операций и некоторая интуиция, как это работает. Есть ещё и примеры использования.

4. [post] Про время.

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

===================================

Знаю, что вы у меня не только плюсами едины.

1 ноября в Москве будет Я.Субботник по Go. В программе про userspace networking, сборку мусора в Go 1.25, KV-хранилища, трейсы и афтерпати для присутствующих.

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

Регистрация тут.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#common

Про читаемость кода 2.

Я уже писал про метаисследование о читаемости кода. Сейчас попалась ещё статья в тему. Дам тлдр и сверху от себя.

What Makes Code Hard To Read: Visual Patterns of Complexity

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

В начале расматриваются 2 метрики, которые по некоторым причинам автору нравятся:
- Halsted Complexity
- "Cognitive Complexity"
Разбираются их корни, и автор делится мнением о хороших и сомнительных сторонах.

Далее три правила, которые автор считает наиболее важными для хорошей читаемости:
1. Хорошие имена очень важны, variable shadowing осуждаем.
2. Предпочитать более короткое время жизни для переменных.
3. Знакомые паттерны использования переменных лучше новых.
(где он не прав?)

И выделяет свои 8 паттернов для улучшения читаемости.

Статья очень разумная понятная адекватная. Надо почаще показывать коллегам.

Я очень не люблю лишние отступы. Ведь когда вы увеличиваете вложенность, приходится держать в голове всё больше причин нахождения в конкретной точке. Коротко и по делу это показано тут: https://minds.md/zakirullin/cognitive#nested-ifs

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

Очень частый паттерн, который я ловлю на ревью это

if (something) {
    ...
    ...
    ...
    ...
    ...
    ...
}

return var;

хотя можно

if (!something) {
    return var;
}

...
...
...
...
...
...

return var;

И эти отступы аффектят 5-50 строк кода. Невыносимо.

Ещё, насмотревшись кода некоторых продвинутых коллег, мне стал нравится подход написания кода вида:

void Do(...) {
    if (cond) {
        DoOther();
        return;
    }
    
    DoFirst();
    DoSecond();

    for (auto x : container) {
        DoWithX(x);
    }
}

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

Некоторые энтузиасты предлагают использовать fibonacci tabbing для того, чтобы избегать большой вложенности. Вам буквально невозможно будет читать код, который ушёл за экран из-за того, что это 6й вложенный if. Даже расширения для VS Code делают.

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

Вынес я для себя тут несколько моментов:
- в процессе обсуждения люди бывают довольно радикальными, хотя по факту большинству фиолетово, сколько там эта строка или на каком месте скобки. Если вы не делаете что-то из рук вон выходящее, никто может и не почувствовать. Каких бы мнений публика ни придерживалась.
- [obviously but] на масштабе учесть всё невозможно. Иногда нужно принять решение крепкой рукой (или несколькими, но их обязательно должно быть мало)
- иногда заставить clang format что-то сделать так, как вы хотите, бесконечно сложно.

В общем случае пишите как хотите. Только одинаково (чтобы паттерны повторялись, да). И не делайте вот это.

#list

0. [talk] From Mid Size to Major The IT Pitfalls of Rapid Growth.

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

1. [article] How Reddit Delivers Notifications to Tens of Millions of Users.

Прикольная статья в блоге ByteByteGo про архитектуры системы пушей в Reddit. Понравилось, что выглядит всё очень естественно и ни в каком месте не возникает вопроса "зачем это сделано?". По одному предложению понятно, за что кусок отвечает и сразу мысль "ну да, логично, что это нужно". А вся архитектура выстроена слоями, что, во-первых, красиво, а во-вторых, позволяет независимо работать над каждым из них.
Я бы сказал, что это крутой кейс, когда всё как надо.

2. [article] So you want to parse a PDF?

В статье рассказывается про то, как в общих чертах парсить PDF, и когда вы думаете, что вроде всё понятно и адекватно, начинается рассказ про РеАлЬнУю ЖиЗНь, в которой у вас всё не так, как должно быть, да ещё и не в тех местах.

3. [article] Asked to do something illegal at work? Here’s what these software engineers did.

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

4. [post] Про лямбды.

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

Почитайте в этот раз про всякие микроприколы лямбд в C++.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#books #cpp

Вредные советы для C++ программистов. Андрей Карпов. (2023г.)

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

Некоторые советы довольно базовые, например не сравнивать double с double через ==, не расширять пространство std просто так или не пользоваться C-style cast. Ничего нового вы здесь скорее всего не найдёте, если уже пару лет на плюсах пописали.

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

Были отдельные места, в которых я не разбираюсь просто потому что не встречался (конкретно про stdafx.h и precompiled headers). За эту часть спасибо.

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

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

Вредный совет их трёх.

Залинкую заодно более подробный обзор от Константина Владимирова: https://t.me/cpp_lects_rus/288

#list

0. [talk] Programming Vehicles in Games.

Очень прикольный доклад про то, как программировать транспортные средства в играх. Он не только про технические детали (их много), но и про очень упрощённую инженерию в тачках, про математику и про ощущение и опыт игрока. Рассказ широкого профиля. Очень вкусный. Очень завлекающий.

Интересно ещё, что программирование у докладчика -- хобби. А сам он практикующий хирург вообще-то.

Если не хотите смотреть видос, вот текстовая версия.

1. [book] README. Суровые реалии разработчиков. Дмитрий Рябой, Крис Риккомини.

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

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

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

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

Если вы уже поработали осознанно несколько лет, то даже не смейте притрагиваться к ней. Вы прям потратите время.
Если вы только начинаете свой путь, то почти наверняка её КПД будет близко к 100%.

Три README из восьми.

2. [article] Get Excited About Postgres 18.

Небольшой списочек прикольных фич новой 18й постгри.

3. [test] Кто ты из Винкс? Do you know how much your computer can do in a second?

Небольшой тестик на ваши ощущения скорости наших компьютеров на некоторых операциях. У меня 6/18. Совсем не чувствую блин.

===================================

Буду рад вашим предложениям, вопросам и вбросам в личных сообщениях, сообщениях в канал или в форме.

#cpp

Ещё есть такой коллега у меня Паша Сухов. Ну как коллега. Он в Доставке вообще работает, но ведь это всё ещё Яндекс. Так что коллега.

Пашу вы могли видеть на C++ Russia:
- Полезные трюки С++ на примере организации пайплайна
- Как заставить шаблоны компилироваться быстро и выглядеть опрятно

Ещё с Пашей мы вместе [грубо говоря] делали несколько внешних мероприятий. Не грубо говоря, [в составе небольшой группы из нескольких яндексолег] делали ещё несколько внутренних. Вместе занимаемся плюсовым коммьюнити внутри.

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

Паша поделился ещё некоторыми фактами для внешнего читателя, но я их приберегу на будущее.

И Паша подготовил очень интересный доклад на один из наших внутренних C++ митапов. Доклад, с разрешения автора, привожу вам в текстовом формате. Конечно же, не полностью, т.к., во-первых, не хочется делать объёмный материал, а, во-вторых, хочется оставить некоторую загадку.

Всё близко к тексту с минимальным количеством редакции от Пашиного лица.

Военный синус: когда C++ показывает свой характер.

https://github.com/dasfex/articles/blob/trunk/sin.md

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