this->notes.

#cpp

Сегодня только один доклад. Зато какой!

Using Floating-point in C++: What Works, What Breaks, and Why. Egor Suvorov.

Егор рассказывает про устройство чисел с плавающей запятой. Миллион возможных проблем с ними в рамках спецификации, корнеров и C++. С примерами, как и что может пойти не так (некоторые примеры на мой взгляд достойны @cpp_durka Паши Сухова).

Я смотрел другие доклады Егора. Они всегда стройне, полные. От начала до конца. Но после этого доклада огромная гора уважения автору (вторая). Это ж сколько информации надо было перелопатить, чтобы прийти и рассказать потом про эту необъёмную яму, в которой закопаться и потеряться в любой случайный момент не составляет никакого труда. Сколько усидчивости и терпения надо иметь, чтобы родить один доклад. Очень красивый и подробный.

Потрясающе.

Один из докладов Егора уже упоминал тут: пункт 3 в t.me/thisnotes/285.

Другой его доклад (lightning) тоже недавно выложили: ⁠Do Not Compare Integers and Floats in C++: Sorting Pitfalls, UB & Type Conversion Explained.
Тут про проблему сортировки целочисленных типов вместе с числами с плавающей запятой.
Может надо как Амазон. Посадить 1000 человек. Пусть на глаз сравнивают. Долго, зато не ошибёмся!
Тема упоминается и в полном докладе, но вдруг вам только это интересно.

Что-то про сложение чисел с плавающей точкой уже упоминалось: t.me/thisnotes/288

Там же в комментах накидывали пачку статей, на которую и Егор, судя по всему, опирался: https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

И тут под названием «What Every Computer Scientist Should Know About Floating-Point Arithmetic» есть жирная статья (хотя я привык её видеть в виде 100страничной пдфки) про то, что надо знать про floating point numbers: https://floating-point-gui.de/references/
Я долго думал, что когда-нибудь прочитаю, но наверное докладом Егора тему для себя можно закрыть.

Наслаждайтесь.

#cpp

Пост небольшой, но с картинками. Даже не пост, а заметка.

Heap pinning: https://github.com/dasfex/articles/blob/trunk/heap_pinning.md

#list

0. [videos]

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

• The Fall of Minecraft's 2b2t.
• RANDAR: Minecraft's Most DANGEROUS Exploit.

1. [article] Debugging an evil Go runtime bug.

Автор рассказывает про мощнейшее расследование краша в Go-туле.

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

2. [article] Uber’s Rate Limiting System.

Uber рассказали про свой Global Rate Limiter. Пару интересных хайлайтов:
- описывают парк проблем из-за зоопарка решений
- целились сделать процесс понимания «пора ли лимитить» как можно более простым, что логично
- конечно же там жирная нагрузка
- научились автоматически подстраивать лимиты, исходя из истории нагрузки.

Старый пост про рейтлимитинг: https://t.me/thisnotes/271

3. [article] In defence of swap: common misconceptions.

Автор рассказывает про то, зачем на самом деле нужен swap, в каком месте люди заблуждаются и как его потюнить при необходимости.
Я даже заблудиться в понимании ещё особо не успел, так что good for me!

4. [article] Вспомним старый пост про geospatial indexing.

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

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

#books #highload

Масштабирование систем. Ian Gorton.

Ещё одна книжка про то, как делать бэкенд. Причём такой бэкенд. Крепкий. Устойчивый.

Содержание:
1️⃣ глава рассказывает про скорость масштабирования систем сегодня и насколько мы можем недооценивать темпы роста. В основном на основе исторических данных вида "а вот эти челы выросли очень быстро, никто даже не ожидал".
И даётся обещание рассматривать до конца книги две основные концепции: увеличение ресурсов и оптимизацию их использования.
Это в целом разумно, но в этот момент я не понимал, как растянуть это всё на фулл книгу.

2️⃣ разбирает базовые концепции: горизонтальное/вертикальное масштабирование, кеширование для уменьшения нагрузки на БД и другие подходы. Про нам известные metastable failures и даунсайды глубоко не говориться, хотя я в последнее время всё чаще думаю про подобные проблемы и про то, как мало внимания им уделяется.

В 3️⃣ начинается разбор всего вокруг: база про сети, grpc, частичные отказы, консенсус, время.
С этого момента я начал что-то подозревать о контенте книги.

4️⃣ пытается рассказать про конкурентность (???).
Имхо пытаться обсудить concurrency в одной главе книги опасно. Причём там не то чтобы база, а по верхам с попыткой залезть чуть глубже базовых понятий.

5️⃣ рассказывает про основы бэкенда, API, балансировку нагрузки.

6️⃣ про распределённое кеширование.

7️⃣ — асинхронный обмен сообщениями.

8️⃣ про serverless. Честно говоря, единственная полезная для меня глава, т.к. я в теме не шарю и тут были какие-то интересные поинты для хоть какого-то понимания. Но мне всё равно не хватило.
Отдельно понравилось, что обсуждается тема денег в рамках парадигмы и то, как реконфигурация может денюжку сэкономить. Очень жаль, что контента про экономику в программировании не прям много. Мне кажется это интересным.

9️⃣ Микросервисы, переход к ним от монолита. Почему-то ещё про функциональную деградацию и некоторые паттерны. Имхо в тему зашли, но сказано почти ничего.

1️⃣0 — про масштабирование БД.

1️⃣1️⃣ про согласованность в конечном счёте.

1️⃣2️⃣ про high consistency.

1️⃣3️⃣ — разные имплементации БД. В частности тут про Redis, MongoDB и Amazon DynamoDB.

1️⃣4️⃣ аналогичная глава про Kafka.

В 1️⃣5️⃣ про Apache Flink как систему потоковой обработки данных.

И в последней 1️⃣6️⃣ несколько отдельных тем: автоматизация, observability, data lakes.

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

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

Почитайте лучше кабанчика. Тем более второе издание как раз вышло.

На эту лучше тратить не стоит. Я уже это сделал за вас.

3 окуня из 10.

#list

0. [talk] Быстрее быстрой или Как обогнать std::sort с помощью поразрядной сортировки.

Дмитрий Изволов рассказывает про поразрядную сортировку, как она пишется, как её надо проектировать по уму и, что самый жир, как он закоммитил ускорение std::stable_sort с её помощью в llvm.

Дима кстати был моим первым руководителем в Лавке. Ровно тем, кто меня нанял в команду. Правда довольно быстро он из Лавки убежал, так что поработать вместе мы успели дай бог 3 месяца.

Мне очень понравилась финалка. В то время, когда другие нанимающие менеджеры просто задавали и отвечали на вопросы (причём не всегда успешно), Дима в том числе просто открыл мой github и спросил, что я хотел бы ему показать. У меня была какая-то простенькая реализация вычисления n-ого числа Фибоначчи возведением матрицы в степень на компиляции, чем я с ним и поделился. Мы обсудили. Он предложил, как код упростить.
Не зря писал. Пригодилось. Понравилось.

Я тоже иногда такой формат иногда практиковал, но, к сожалению, у кандидатов не очень часто на github что-то есть.

1. [article] Unconventional PostgreSQL Optimizations.

Автор рассказывает про три небаянистые оптимизации, которые вы, возможно, можете применить в своих проектах.

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

2. [article] Why Senior Engineers Let Bad Projects Fail.

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

3. [article] How I estimate work as a staff software engineer.

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

4. [article] Scaling PostgreSQL to power 800M ChatGPT users.

Статью прилагаю как антипаттерн.

Тема у чуваков отличная. Огромная нагрузка. Сто процентов сложнейшие инженерные задачи.

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

А так выглядит как набор топиков на ресёрч.

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

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

#highload

Инциденты Ч.1.

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

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

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

Knight Capital 2012

Когда-то это была одна из крупнейших трейдинговых фирм на американском рынке.

Что случилось:
- реализовали новую фичу под флагом (флаг взяли от старой фичи, а не сделали новый)
- раскатка нового бинарника происходила руками. На один из 8 подов сервиса забыли положить новый бинарник
- включили фичу
- с началом торгового дня заработала новая логика на 7/8 подов. На восьмом включилась старая логика (на самом деле даже не старая, а частично отпиленная старая).

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

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

Через 45 минут проблему починили, но за это время всадили >400kk$, что фактически обанкротило компанию.

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

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

Link: https://specbranch.com/posts/knight-capital/

British Airways 2017

Проблема британской авиакомпании -- подрядчик неаккуратно отключил питание в основном ДЦ.

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

Последствия: 75k пассажиров не улетели куда планировали, 1000 рейсов отменены.

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

Link: https://www.theguardian.com/business/2017/jun/05/ba-inquiry-it-meltdown-airline-willie-walsh-passengers

Azure 2012

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

А вот в Azure ребята рофланули мощнейше.

Создавали они значит где-то в коде у себя какие-то сертификаты на доступность. Код был примерно таким:

DateTime issuedAt = DateTime.UtcNow;
DateTime expiresAt = issuedAt.AddYears(1);

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

Это ж надо было такую либу написать, которая +1 год делает буквально +1 год.

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

Link: https://www.wired.com/2012/03/azure-leap-year-bug/

Следующая порция когда-нибудь!

Ещё позже расскажу про мои любимые инциденты из личного опыта.

#common

Одна из зон ответственности моей [бывшей] команды в Лавке -- локализация (т.к. сервис существует в нескольких странах).

Там мы понимали под локализацией всё сразу, но вообще есть некоторое разделение:
- internationalization (i18n) -- техническая возможность работать с разными языками.

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

Иногда вы можете по качеству озвучки фильма сказать, был ли он локализован или просто переведён. Когда я услышал в очередном голливудском произведении «встречусь с бесконечно вечным», мысленно снял шляпу.

- globalization (g10n) -- это что-то бизнесовое про координацию усилий везде вкупе.

Технически наиболее интересным является i18n.

Фактически это про возможность корректно работать с переводами.

Когда в коде уже не используются строки, а только ключи, по которым переводы получаются из какого-то kv-хранилища.
Сюда же включаем направление письма (иврит, например, пишется right-to-left). Форматирование чисел (точка/запятая для дробных). Форматирование дат (порядок день/месяц/год в любой комбинации). Форматирование валют. Поддержка множественного числа объектов (1 собака, но 5 собак). Поддержка склонений.
По-хорошему вот это всё ваша библиотека должна уметь поддерживать.
Конечно, реализовать подобное == примерно поддержать инфру для задачи + разобрать миллион кейсов.

Переводить в идеале не кусками, а целыми предложениями/фразами:
чёрный кот на английском -- black cat
чёрный кот на испанском -- el gato negro

Переводить по слову получится грамматически неверно.

Аналогично про согласование различных слов. В русском/испанском/французском языках прилагательные могут меняться в зависимости от рода объекта, к которому они относятся. Тогда в идеале перевести всё заранее и никак не параметризировать строки. Будет меньше проблем.

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

Если нужна либа для i18n под плюсы, можно взять icu4c. Я честно видел её в коммерческой разработке. Правда, мне не оч понравилось с ней работать.

Конечно, для поддержания нормального решения нужно слишком много. Всегда можно просто сходить по API в переводчик и получить ответ. Но может получиться что-то такое:

#list

0. [talk] How to Tame Packs, std::tuple, and the Wily std::integer_sequence.

Andrei Alexandrescu рассказывает всякие приколюхи, идиомные идиомы и тРюКи в реализации удобных утилиток для работы с туплами и штуками рядом.
Как обычно, потрясающе забавный доклад. С философскими рассуждениями про AI между делом.

1. [article] Gallery of Processor Cache Effects.

Статья про некоторые факты о работе процессоров. Есть как базовая база типа «кеш линии влияют на обход контейнеров больше кол-ва итераций», так и «переменные, объявленные не подряд инкрементируются быстрее».

2. [article] The challenges of soft delete.

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

3. [article] Three ways to solve problems.

Мне понравилась ментальная модель. Запомнил.

4. [wtf...] The creator of Clawd: "I ship code I don't read".

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

Но я не согласен, что этим надо гордиться. Я не согласен, что так должно быть. Это не ок.

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

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

#books

Так как игры делать собсна?

Я не знаю! Но я читал!

«Классические» (все) источники про паттерны даются мне сложновато. Нужно хорошо понимать контекст, прям чувствовать его, чтобы действительно принять необходимость какого-то структурированного решения. Этого можно достичь применением паттерна в понятном вам домене. Домен будет вам понятен, если вы много с ним сталкиваетесь. Значит осознать можно либо на практике на работе или в любом другом проекте, где вы много задействованы.

А можно в играх, т.к. их мы обычно чувствуем «по умолчанию», просто потому что в той или иной степени играют все.

Game Programming Patterns. Robert Nystrom.

English, russian (перевод не оч аккуратный с т.з. грамматики, пунктуации и чрезмерной локализации).

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

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

Примеры в книге на простеньком C++. Потому автор заодно рассказывает про потенциальные проблемы, которые могут возникнуть, если вы реализуете паттерны неаккуратно.

Понравилось, что рассматриваются не только проблемы, связанные с C++. Или поддержанием кода. Но иногда и дебага и использования IDE при злоупотреблении паттерном. Например, большая часть главы про Синглтон была про то, как его реализовывать не надо и когда пользоваться и не стоит (это особенность синглтона).

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

В конце книги есть 4 главы про оптимизацию в различных ситуациях. Если местами базовая концепция передана хорошо, то глава про локализацию данных имхо какая-то поверхностная и может даже вредная. Тема глубокая, а по факту ничего не сказано, хотя букав достаточно.
С другой стороны, про пул объектов и freelist'ы получилось неплохо.

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

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

4 паттерна из 6.

#common

Фаново рассказываю, как мы в универе писали игры!

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

#highload

Функциональная деградация.

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

#list

0. [talk] Unlocking Modern CPU Power - Next-Gen C++ Optimization Techniques.

Fedor G Pikus рассказывает про скорость работы процессоров, их устройство и оптимизации, в которые они умеют. Довольно сложно и непонятно.

1. [talk] Руководство по поимке и обезвреживанию проблемных запросов.

TLDR про то, как же искать проблемы с перфом в ваших запросах в pg.
Вообще конечно этот огромный неизведанный мир расширений pg это что-то интересное.

2. [article] Binary Search Vs. Prolly Search.

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

3. [article] How to Hash Objects Without Repetition: std::hash can be DRY.

Вот неудобно людям стандартной библиотекой пользоваться. Языком там. Они такие статьи пишут..

4. [article] Когда-то писал про интересную комбинаторную задачу.

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

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

this->notes. pinned «# 2025 2024, 2023, 2022. Посты: - про хорошего разработчика; - CRDT premier; - первоапрельский пост про размеры; - мои фавориты из шортлиста Технотекст 7; - про балансировку трафика; - микрогайд по type traits; - пишем make_index_sequence; - про стандартную…»

#list

0. [talk] Could C++ Developers Handle an ABI Break Today?

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

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

1. [article] How to contribute to Abseil with a visible performance gain.

Danila Kutenin рассказывал, как он оптимизировал флаги в abseil.
Красиво блин.

2. [article] Как построить прогноз спроса и не потерять голову.

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

3. [article] Why speed matters.

Паша @cpp_durka Сухóв подкинул важную базу.

4. [fact] MFA fatigue.

Multi factor authentication fatigue атака -- это когда злодеи-анонимусы узнали ваши логин и пароль и пытаются взять вас на лоха, задудосив попытками войти в аккаунт. Вам придёт много-много уведомлений (ведь у вас как минимум 2fa), будете отвлекаться и тыкнете «Разрешить», чтобы не мешало. Ну или случайно кликните и дадите доступ.
Вот, например, Uber так на самом деле взламывали.

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

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

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

#cpp

System Level Meetup 2025

🌼 Первым докладом был «Корутинные оптимизации в компиляторах» от глыбы Константина Владимирова и коллеги глыбы Юлия Тарасова.

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

🌼 Далее Сергей Чеботарёв рассказывал «Модули С++20 в существующий проект: лёгкая прогулка или прыжок в бездну?».

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

🌼 «LRU-кеш: от решения с собеседования до production-уровня» Ильи Шишкова.
Кеш у Ильи не базовый бэкендерский. Он хранит какие-то артефакты в шареной между различными процессами памяти.
Имхо крутая история про полезность правильного трейдофа. На самом деле иногда нам достаточно приблизительное решение, что позволяет упрощать/экономить. Надо учиться такое подмечать и вовремя использовать.
Код конечно у ребят глаз не радует. Может я привередливый.

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

Круто #2: Илья несколько раз говорит, что к чему-то не дошёл в процессе решения задачи.
Важно уметь вовремя остановиться. Мы можем улучшать что-то бесконечно, но если вы начинаете тратить больше, чем в итоге получаете, скажите себе хватит. Это про взрослое отношение к задачам.

🌼 «Когда действительно нужны алгоритмы: опыт оптимизации kd-tree» Саши Голубева.

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

С Сашей мы год вместе занимались С++ community в Яндексе. Вот такой мужик👍

Ещё на C++ Russia 2024 я Сашу вином облил. Не специально.

🌼 Анастасия Черникова рассказывала «Анатомия чекеров в clang-tidy».
Доклад буквально про то, как он называется.
Анастасия рассказывает про разные способы проверять качество кода. Глубже уходит в статический анализ. Рассказывает про AST, разные классы чекеров и сами чекеры из LLVM инфраструктуры.
А дальше рассказывает, как она дорабатывала один из чекеров и как это вообще делается.

🌼 Заканчивал C++ трек доклад «Строки, строки, строки и initializer_list» Антона Полухина.
Антон рассказывал про разные проблемы со строками, их лайфтаймом, std::string_view, кастомную поделку для литералов (чтобы быть уверенными в их времени жизни), а ещё, конечно же, про то, как избегать лишних аллокаций там, где мы можем случайно их словить.

Мне понравилось.

#list

0. [2026]

Начинается очередной год. Здравствуйте.

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

Хочется делать сложные вещи.

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

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

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

Успехов и вам.

1. [talk] Implement the C++ Standard Library: Design, Optimisations, Testing while Implementing Libc++.

Hui Xie рассказывает про точечные оптимизации и связанные с ними проблемы в libc++.
Например, как экономят память в std::expected, почему for_each работает быстрее цикла для std::deque, как правильно входить в хату вставлять в std::flat_map и всякое другое.
А в конце рассказывается про тестирование стд либы. Как оно всё там непросто у ребят.

2. [article] Logging sucks.

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

3. [article] Simplify hashing in C++.

Автор справедливо замечает, что пользоваться std::hash не очень приятно и что это надо поправить. Немудрыми улучшениями он решает эту проблему.
Опустим момент, что выбрать хороший hash_combine сложно.

4. [article] The Math of Why You Can't Focus at Work.

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

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

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

К сожалению, я был немного неосторожен и невнимателен.

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

Что важного хочется подчеркнуть:
- как оно в этом Лондоне я ещё сам хз. Мы тут всего пару дней. Напишу через год.
- same про новое место.

Расписал инфу про год вот тут: https://github.com/dasfex/articles/blob/trunk/2025.md
(фотки большие, поправлю попозже!)

Пожелание на следующий год через пару дней.

Напомню, что есть ещё @memesfromhole, @dzikart и @khdocs.

С Наступающим Вас!

# 2025

2024, 2023, 2022.

Посты:
- про хорошего разработчика;
- CRDT premier;
- первоапрельский пост про размеры;
- мои фавориты из шортлиста Технотекст 7;
- про балансировку трафика;
- микрогайд по type traits;
- пишем make_index_sequence;
- про стандартную библиотеку;
- speculative execution;
- проблемы с shared database подходом;
- про читаемость кода 2;
- опять ub моими руками;
- про найм;
- про бинарный поиск;
- про флаги оптимизаций (O);
- новости от РГ21++;
- контент на праздники;
- пачки ссылок: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25;

Люди и контент:
- Андрей Гейн и string matching premier;
- Лёша Быков и metastable failures;
- Саша Федькин и мысли про микросервисы;
- Паша Сухов и военный синус;

Сборники с конференций:
- Saint TeamLead Conf 2024;
- Saint Highload++ 2024;
- С++ Russia 2024;
- Яндекс Day&Night;
- C++ Zero Cost Conf 2025;
- Highload++ 2024 first, second;
- Яндекс Tech Tour 2025;

Книги:
- Искусство планирования мощностей. Джон Оллспоу;
- API. Сергей Константинов;
- Мама, я тимлид! Марина Перескокова;
- Вредные советы для C++ программистов. Андрей Карпов;
- System Design. Машинное обучение. Подготовка к сложному интервью. Алекс Сюй, Али Аминиан;
- Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон;

Светился:
- в гостях у ребят из Выше Вилки;
- был с лайтнингом на C++ Russia 2025, рассказывал как мы в Лавке упрощали разработку. Записи нет, материалов не будет;
- C++ Zero Cost Conf 2025: i, j, k и шаблоны: вспоминаем линейную алгебру. Записи нет.

Самый зашареный пост: Микросервисы. Паттерны разработки и рефакторинга. Крис Ричардсон (>110 шеров).

Вас стало в 2 раза больше (на 2400 примерно).

Звали выступать на конфу, но я не ходил.

Суммарно 2 месяца из 12 провёл вне страны проживания.

7 раз приходили за рекламой.

Не понял, лишился четверти мудрости (удалил восьмёрку) или стал мудрее (на год).

Уже 10 месяцев чист от никотина. Планирую так ещё лет 50-70.

С любимой женщиной взяли собаку.

Любимая женщина стала любимой женой.

Уволился из Яндекса. Устроился в Bloomberg.

Семьёй из троих сменили Минск на Лондон.

Не умер, что особенно приятно.

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

#list

Т.к. впереди намечается солидное количество выходных, можно покайфовать под что-то интересное.

Контент будет нетехническим для разнообразия. Но в тему айтишечки и вот этого всего. Предлагаю вам ощутить напряжённейшую жизнь стартапов и их естественного развития. Иногда успешного. Иногда не очень.

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

👉 Сериал На взводе: Битва за Uber.

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

Состоит из одного сезона в 7 серий примерно по часу.

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

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

👉 Книга Миллиард за мечту, или Как дерзость и непомерные амбиции Адама Неймана построить новое общество обернулись крахом империи WeWork. Ривз Видеман.

Adam Neumann придумал новый формат коворкингов, который превратился в честный стартап-единорог. Правда потом всё зафакапилось. Жаль братка.

👉 Книга Дурная кровь. Тайны и ложь одного стартапа Кремниевой долины. Джон Каррейру.

А эта книга про компанию Theranos и её основательницу Elizabeth Holmes, которая хотела изменить мир, дав людям возможность делать быстрые и качественные анализы в любой момент.
Амбиция крутая, а методы достижения цели не очень. Внутри солидное количество надувалова со стороны топ-менеджеров и непомерно токсичное руководство.
Штош!

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

Опять же, есть аналог, если не хочется читать фул книгу: Изобретатель: Жажда крови в Силиконовой долине, -- документалка про всё то же.

Если вы знаете что-то похожее, поделитесь!

А с меня останутся только итоги года : )