Я в последнее время начал заниматься всякими конфами и митапами не только со стороны выступающего/участника, но и в каком-то виде организатора. Про внутренние рассказывать не буду, а вот про внешние могу себе позволить. Сейчас, например, я являюсь членом программного комитета самой большой конфы нашей бизнес-группы Яндекс dev day&night.

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

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

Хотя может вам интересно и продакт-менеджеров послушать. Осуждать не буду.

Конфа 19 апреля с обеда до глубокой ночи (поняли? типа day&night). Регистрация уже скоро кончается. Залететь можно по ссылке.

#cpp

1. [talk] Gazing Beyond Reflection for C++26.

Daveed Vandervoorde рассказывает про осенний state рефлексии. В докладе огромное кол-во примеров. В том числе не самых тривиальных. В том числе со ссылками на godbolt. За полгода, прошедших с конференции, видимо, многое поменялось, т.к. часть примеров уже не работают, но всё равно можно потыкаться и попробовать всякое разное.

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

2. [article] Tech Debt doesn't exist, but trade-offs do.

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

3. [article] How Not To Sort By Average Rating.

Статья 2009 (!!) года про то, как правильно ранжировать айтемы при наличии лайков-дизлайков. Имхо оч забавная, потому что говорит "не надо делать 1 и не надо делать 2, вместо этого делайте 998244353".

4. [article] The Best Programmers I Know.

В конце статьи есть такая цитата

don’t trick yourself into thinking that you can skip the hard work. There is no shortcut.

Так что я ничего про содержание не скажу. Читайте сами.

#common #pub

В марте я ходил в гости к ребятам из Выше Вилки (конкретно Илье Шишкову).

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

Смотреть тут: https://youtu.be/6BNH4BNhvxY

#books #highload

Женя иногда пишет обзоры на книги. Хочу быть как Женя. Правда для этого книги надо читать. Но я смирился.

Искусство планирования мощностей. Джон Оллспоу. (2011 г.)

Хотелось мне как-то почитать чего-то такого, что бы мне рассказало, как думать про большие объёмы нагрузок (больше, чем у меня есть). Как учитывать неявный рост ресурсов при развитии продукта. Где взять бабки на всё это и как сэкономить, чтобы не отдавать абстрактному Amazon половину прибыли. Нашёл вот такую книгу от одного из работников Flickr (на тот момент) про планирование мощностей.

Главы в книге примерно такие:
1️⃣ Цели, проблемы и процессы планирования мощностей.
Тут рассматриваются базовые вопросы, связанные с темой: зачем думать про планирование мощностей, какие сложности возникают в процессе, почему это должен быть постоянный, а не разовый процесс. Своего рода глава-предисловаие.
2️⃣ Определение целей.
Во второй главе обсуждаются разные точки зрения на вашу систему: со стороны разработчика, бизнеса или юзера. И как планирование мощностей влияет на сервисоощущение каждой из сторон. Тобишь зачем вообще это всё надо всем, а не только кому-то одному. Между делом упоминаются концепции девяток и базово рассказывается про масштабирование.
3️⃣ Сбор данных: как измеряются мощности.
Это глава освещает вопрос сбора метрик. Призывает подумать о максимально широком сборе данных о вашей системе, дабы вы могли понимать её состояние как можно более чётко. Заодно задевает некоторые конкретные инструменты мониторинга (судя по всему, уже не очень живые, т.к. я встретил их впервые в этой книге). Далее нам подсказывают, что надо найти зависимость от нагрузки на использование ресурсов и так определить, сколько ещё мы можем держать. Приправлена несколькими историями из практики автора во Flickr.
4️⃣ Прогнозирование.
Далее обсуждается вопрос прогнозирования потребления ресурсов, исходя из исторических данных. Предлагается это делать довольно просто: собрать набор исторических данных за какой-то период и построить аппроксимацию в Excel. Заодно поясняют, почему данных не должно быть мало. Ну и пруфают это ещё одним кейсом из практики.
5️⃣ Развертывание.
В последней главе рассказывают про то, как деплоить ваши сервисы. В целом ничего такого.
🅰️ Приложения.

В целом книга скорее оставила ощущение потраченного времени. Нет, не прям плохо. Истории из практики были довольно интересными. Местами поучительными. В голове закрепился очевидный, но важный принцип: "Планировать ресурсы, не надеясь на потенциальную оптимизацию". В Приложении Б есть пару страничек про жутко интересную сейчас для меня тему функциональной деградации. Но возможно я просто ожидал чего-то более масштабного, чтобы про планирование на 2 года, а не 3 недели. Чтобы про миллионы долларов, а не отсутствие экономических факторов. Чтобы не про Excel.
Возможно, поработать пару лет в похожей ситуации будет гораздо полезнее. Но если опыта такого у вас нет, книга может дать базовые понятия.

500 RPS из 1000.

#highload

Я звал вас на Яндекс Day&Night, А теперь предлагаю посмотреть замечательные доклады.

1. [talk] Не «Кафкой» единой. Серёжа Бунатян.

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

2. [talk] Где бы заказать? Ищем доступные рестораны в Яндекс Еде. Серёжа Синягин.

В прошлом году я писал про геоиндексинг, а тут коллега из Еды рассказывает про то, как устроен поиск доступных ресторанов. Практический кейс! План примерно такой:
- постановка задача
- геохеш
- Uber H3
- R-Tree и его применение к решению задачи.

3. [talk] Вы неправильно делаете нагрузочное тестирование. Андрей Матвеев.

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

4. [talk] Платформа для разработчика как продукт. Рома Елизаров.

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

5. [talk] Поиск в Яндекс Маркете: как делать всё и сразу. Даня Яковлев.

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

Красота блин!

#common #math

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

0. [article] Алгоритмы манипуляций с битами.

Удаляю ещё одну идею для статьи из беклога. Потому что надо не хранить её 1.5 года, а брать и писать, а то кто-то это сделает вместо тебя.
Зато работы меньше. И сделано лучше, чем я бы сейчас мог.

1. [article] IoT Geofencing: как мы сократили время определения функциональных зон, используя H3-индексы.

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

2. [article] Нелогичные и зарегулированные города: почему нейросети плохо приживаются в городском проектировании.

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

3. [article] Ловушка бесконечно ленивого бассейна.

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

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

Результаты тут: https://habr.com/ru/companies/habr/articles/911650/

#db #common

0. [article/news] Yambda.

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

Я в тему сильно не погружен, но насколько я понимаю, датасетов подобного формата довольно мало. Те, которые есть, либо маленькие, либо имеют приколы с лицензиями. А вот такое огромное и открытое может сильно бустануть возможность проверять качество своих моделей.
Для доступности есть ещё урезанные версии на 480kk и 48kk событий.

Статья на habr.

1. [article] What I Wish Someone Told Me About Postgres.

Среднего размера сборник полусвязанных друг с другом пунктов о Postgres и различных особенностях этой бд, которые включают:
- будьте осторожны с NULL
- как заполучить гигаpsql
- что-то про индексы
- локи
- и JSONB.

2. [article] Sycophancy is the first LLM "dark pattern".

Тут чувак рассказывает, почему лесть у LLM -- проблема. Поинт довольно простой: это простой способ получить лайк на ответ от юзера. И злоупотребление только создаёт замкнутый круг.
То-то мне попадаются рилсы с промптами вида "как сделать так, чтобы chatgpt перестал с тобой соглашаться". И там вот это "ты интеллектуальный оппонент...".

#highload

Балансируем трафик.

https://telegra.ph/Balansiruem-trafik-06-10

Ещё бы как-то жизнь забалансировать...

#cpp

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

Микрогайд по type traits.

https://telegra.ph/Mikrogajd-po-type-traits-06-14

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

1. [talk] The Economics of Programming Languages.

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

2. [article] Why is Redis So Fast Despite Being Single-Threaded?

Небольшая статья про то, почему Redis, несмотря на однопоточность (со звёздочкой), довольно крепко держит большие нагрузки. Кратко всё сводится к
- качественной реализации неблокирующего I/O
- низкоуровнему всему, что только можно
- подходящим алгоритмам

3. [article] Why Query Caching Is the Most Cost-Effective Way To Scale Databases — and Everyone’s Missing It.

Суть статьи в названии.
Иногда мы, кстати, можем случайно ломать кеширование запросов некрасивым кодом. Самый простой пример из практики, когда у вас есть один и тот же запрос, выполняемый с разными аргументами. Вариантов тут несколько: собираем прямо в коде строку с запросом, делая ToString всем аргументам. Отдаём запрос на исполнение в БД. Или можем один раз отдать запрос в БД (в нашем случае Postgres) с плейсхолдерами для аргументов (так запрос и закешируется), а дальше присылать только сами аргументы, не гоняя по сети запрос. Если запрос большой/часто выполняется, то можно хорошенько сэкономить на трафике между сетью и базой.

4. [lightning talk] Template Meta Music Programming or Contexpr Composition.

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

#books

Сегодня книга про то, как делать API. Кайфуйте.

https://telegra.ph/API-Sergej-Konstantinov-07-01

#list

1. [article] Встреча ISO C++ в Софии: С++26 и рефлексия.

Подъехали новости от коллеги про стейт C++26 и последние апдейты по заехавшему.
Это всё конечно здорово, но вот сижу я в 2025м. Пишу что-то типа на 20м стандарте (типа на 20м, сами понимаете). Из C++23 только недавно std::expected научился трогать. Слежу за новинками новых стандартов.
Чтобы что? К моменту, когда 26й стандарт станет доступным, я бы уже хотел докидывать последние пачки бабок для FIRE.
Хочется менять направление от понятных перекладываний JSON на что-то более низкоуровневое. Параллельно с этим хочется двигаться в более высокие абстракции: не думать про эти par unseq и векторизацию и новое поле в API, а про то, как десятки сервисов в кучу связывать. Хочется какие-то фундаментальные проблемы решать. И неважно на каком языке они потом будут писаться.
Ну может хоть комитет в это всё верит.

2. [article] My DOs and DON’Ts of Software Architecture.

Автор поясняет несколько поинтов. Вот они слева направо с моими комментами:
- помнить, что все коллеги -- люди.
В моём опыте это не всегда так. Для какого-нибудь высокого руководителя/инвесторов конкретные разработчики очень часто являются просто ресурсом, цифрами на бумажке. Я время от времени вижу проблемы в понимании (удивительно, что руководители со временем про это забывают), что нельзя просто взять X дней разработки и сделать проект, т.к. дни разработки у разных людей с разной экспертизой и опытом, с переключением контекстов очень отличаются. И что увольнять хедкаунт, потому что направление закрыли, а хк это просто деньги, тоже не идеальное решение, т.к. этот самый хк -- довольно конкретный Вася, который кормит семью. Благо, до увольнений в моём опыте никогда не доходило.
- прозрачность очень важна.
Факт. Иногда её и правда не хватает.
- решения должны записываться.
Постоянно натыкаемся на это даже в самых мелких вещах вроде незаписанных требований в проекте. Потом ходи ищи, почему мы должны были что-то сделать и как теперь нагонять.
- явно назначать ответственного.
Это особенно важно, если ваш ответственный (сущ.) -- ответственный (прил.). В моём небольшом менеджерском опыте качественное назначение зоны ответственности приводит к огромной разгрузке руководителя. Некачественное -- к её увеличению.
- использовать какие-то архитектурные контракты.
Ну ладно.
- не верить слепо указаниям.
Руководители выше вас тоже, к сожалению, бывают некомпетентными/нежелающими вникать в происходящее. Надо уметь в т.н. managing up.
- не предлагать проблему без решения.
Если вы идёте с готовым решением, вы сильно повышаете свои шансы на быстрый рост. Конечно, не понимать, с какой стороны зайти, тоже нормально. Хороший руководитель поможет придумать направление/решение, но злоупотреблять этим не стоит: кому захочется регулярно решать проблемы за подчинённого?
- не предполагать, что если кто-то жалуется, то он всё понимает.
Даже на себе часто ловлю, что мне не хватает контекста, из-за чего начинает подгорать одно место. Когда кто-то мне этот контекст докидывает, часто становится гораздо проще. Проблема только в том, что иногда доп знания приходит какими-то окольными путями через хорошо налаженные связи, а не от источников изменений.
- не оверинженирить.
Но держать трейдоф между "суперкрутая система" и "костыль на запуск".
Последние три пункта оставлю вам на прочтение, т.к. сказать мне про них нечего.

3. [article] Bruteforcing the phone number of any Google user.

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

4. [repository] The Bitwise Gamedev Challenge.

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

#algo

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

Поиск подстроки в строке.

Есть такой чувак Андрей Гейн. У него есть канал на youtube и канал в тг: @andgein_notes. В конце декабря он написал про 2 текстовые версии о поиске подстроки в строке, которые он выложил в свой блог.

В первой он рассказывает о поиске конкретного паттерна в тексте:
- наивном подходе
- префикс функции и алгоритме Knuth–Morris–Pratt
- далее про Boyer–Moore алгоритм
- и в конце про Two-Way

Сначала прочитайте это замечательное полотно, а потом давайте посмотрим, как использовать продвинутые сёрчеры строк в C++.

В <functional> есть 3 сёрчера, которые вы можете использовать для поиска строк. Первый -- std::default_searcher. Этот сёрчер, как и все другие, должен передаваться третьим аргументом в алгоритм std::search. Сам сёрчер принимает себе pattern, который ищется в тексте:

auto it = std::search(text.begin(), text.end(), std::default_searcher(pattern.begin(), pattern.end()));

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

Не дефолтными сёрчерами могут быть:
- std::boyer_moor_searcher
- std::boyer_moore_horspool_searcher
Пользуемся ими точно так же, как и стандартным.

Если посмотреть на реализацию, например, boyer_moor_search, то можно увидеть ровно описанные Андреем вещи (например, прекомпьют разных табличек).

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

Если приглядеться на дефолтный сёрчер, то можно понять, что там много не надо и при желании можно и свой реализовать. Можно писать и общего вида алгоритмы, которые будут пробрасывать сёрчеры в std::search.

И пока и всё. Двигаемся ко второй лекции, где освещены продвинутые способы:
- Ахо-Корасик
- суффиксный бор
- суффиксное дерево
- суффиксный автомат

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

Прям качественный обучающий материал. Кайфуйте.

Два года назад мы с коллегой выложили статью про то, как в Лавке работает поиск. Тогда это был скорее набор приблуд, которые мы пытались совместить без ML экспертизы (мы == до появления Коли). C того моменты прошло много времени. Ребята (именно они, я тут ни при чём) сделали огромный объём работы. И Коля описал всё это в новой статье: Разбираем на запчасти поисковый сервис в Яндекс Лавке. Причём тут даже не про всё написано.

Посмотрите, как много всего и как вырос уровень материала. Кайфаните от души.

Рядом не совсем в тему, но к месту порекомендую статью от Марка, тоже очень близкого коллеги, про то, как у нас ребята оптимизировали в рекомендациях кандидатогенерацию: Скорим всё: как мы упростили ML-стек рекомендаций в Лавке и отказались от кандидатогенерации.

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

Желаю и вам того же.

2ого августа пройдёт хорошо вам известная C++ Zero Cost Conf.

В этом году я снова буду выступать, но географически в Санкт-Петербурге, который впервые будет площадкой для нашей любимой конференции. Кроме СПБ будут ещё Москва и Белград.

Что важно, в Москве и Белграде будут и трансляция, и записи выступлений, а вот в Питере только офлайн, так что если не доберётесь посмотреть в жизни, упустите 3 отличных доклада!

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

Регистрируемся как всегда, тут.

Приезжаем в СПБ. Ищем меня. Обсуждаем C++ и пьём пиво газировочку.

Сегодня kinda именной пост.

В марте после C++ Russia (когда я говорю после, я имею в виду спустя час после конца второго дня) в баре со спикерами конференции я познакомился с Лёшей Быковым. Забавно, что мы познакомились с ним там, хотя вообще-то Лёша тоже из Яндекса. Работает в Go. Занимается надёжностью сервисов вокруг. Я даже ему когда-то писал, но тогда он был абстрактной аватаркой в тг, а не конкретным человеком.

Тогда за пивом он рассказал мне несколько интересных вещей:
- про разные способы чинить инциденты, не понимая их руткозов. Я на тот момент, пусть это и совсем недавно было, ещё не думал в целом про то, что так стоит делать. Хотя это и очень очевидно. Вот релизы откатывать, а потом разбираться, я умел. Но обобщить это на любую другую проблему ещё не мог.
- реальную историю про то, как у std::optional вызывался деструктор boost::optional. Кек, да?
- про метастабильные состояния. Я тогда не понял, что это такое, но уже подразобрался. И вы спустя пару часов вдумчивого потребления контента осознаете.

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

Про метастабильные состояния есть базированная небольшая статья: Metastable Failures in Distributed Systems. Лёша (а точнее Gemini ему) утверждает, что лучше статьи для введения в тему не найти. Ну вот и почитайте. В ней описывается базовое определение, примеры метастабильных состояний в зависимости от разных причин, способы их как-нибудь хендлить и направления для ресёрча по теме. Статья довольно короткая, так что не пугайтесь. Сядьте на полчасика и вдохните.

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

Можете ещё Лёшин доклад посмотреть: Сложность метастабильных состояний отказа на примере Такси. И вот тут набор ссылочек из его доклада.

Подписывайтесь на Лёшу: @it_tldr. Он пишет редко, но метко.

Лёша ещё работает вместе с Пашей Назаровым. Паша тоже занимается надёжностью в Go. Они вместе координируют инциденты. На том же митапе Паша рассказывал про надёжность и БД: Укрощение строптивых баз данных.
Канала у Паши, насколько я знаю, нет. Только инстаграм. Но его я продвигать не буду (Паш, извини!).

#list

1. [talk] Monads in Modern C++.

Доклад с CppCon 2023 про монады и их удобные удобства. Докладчики идут от базовых понятий и примеров, постепенно усложняя материал и разбирая разные корнеры в применении монад на практике, после чего рассказывают про текущий (на тот момент) стейт стандартной библиотеки, разные пропозалы по теме.
Очень много в докладе про потенциальные проблемы разыменовывания и работы с null объектами и что с ними делать.

2. [article] Запустили векторный поиск в YDB: рассказываем, как он работает.

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

3. [article] Scale Microservices Testing Without Duplicating Environments.

Статья довольно маркетинговая т.к. чуваки сами себя жоска хвалят, но пользы от неё меньше не становится.
Как выглядит самый простой путь к отдельной среде для тестирования? Берёте и разворачиваете изолированный минипрод. Там меньше данных. Меньше ресурсов кушается. Надо отдельно заводить данные, но в целом работает. Катаетет свои изменения в тестинг, смотрите что там как и кайфуете.
Кайфуете до того момента, пока кто-нибудь на набагает и тестинг вам не уронит. В такой момент может встать работа всех QA, части коллег с фронта и бэкенда. Звучит больна.
Потому есть всякие другие варианты, как не оч дорого, но более безопасно тестировать изменения. Например, как в статье, разворачивать личный инстанс только изменившегося микросервиса, который будет ходить в честный тестинг во всех остальных местах. Набагал -- роняешь только свой инстанс. У нас где-то в компании даже такое используется, буквально на днях коллега рассказывал.
В статье чуваки считают, как сильно от этого режутся расходы на ресурсы в условном AWS. Мне нравится это напоминание, что всё упирается в бабки, как бы ни хотелось последний мак и самую мощную виртуалку. Их кто-то должен оплатить...

4. [article] Faster Integer Parsing.

Автор концентрируется на простой задаче: распарсить 16значное число как можно быстрее. И постепенно двигается от STL решений к бит трикам и SIMD. Рядышком есть бенчмарки.

5. [article] There is a std::chrono::high_resolution_clock, but no low_resolution_clock.

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

#cpp

### Москва

1. Hardening: текущий статус и перспективы развития. Роман Русяев и Юрий Грибов.

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

2. Алиасинг памяти в компиляторе и в вашей программе. Константин Владимиров. Владислав Белов.

Рассказывали про новую для меня эпопею с restrict в C и проблемами, которые он призван решать. В плюсах этого счастья нет. Аналогов до сих пор нет. Strict aliasing у нас всё ещё боль. Имхо конечно запомнить в char можно, больше ни во что нельзя, не так сложно. Но я всё-таки в рамках сервисов думаю, а кто-то наверняка в рамках байтов. И там это боль и такого правила недостаточно.

3. Perfomance puzzlers от Сергея Слотина.

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

4. C++20 Модули — практическое внедрение. Антон Полухин.

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

Единственное что хочу сказать после доклада Антона, это что мы ещё не успели затянуть модули вширокую (мы это мы с вами), а уже приходится какие-то нетривиальные хаки запоминать и делать. Кринжа!!!

Держите arewemodulesyet.org.

### Белград

1. Векторизация 2025. Андрей Аксёнов.

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

2. Hot and cold memory optimizations in TCMalloc. Алексей Веселовский.

Довольно приятный рассказ (на английском) про hot cold подсказки для аллокации памяти в TCMalloc. Алексей даёт превью фичи. Рассказывает, как её использовать с PGO. Показывает, как работает. И бенчмарки конечно же.
Я когда-то базово залазил в аллокаторы. Мне понравилось.

3. С++20 vs C в роботах. Битва за ресурсы, абстракции и безопасность. Арсентий Гусев.

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

4. Быстрые и приближённые ответы. Артур Соловьёв.

Приятный доклад про вероятностные структуры данных. Я когда-то писал про них пост (без ссылки, потому что скоро напишу новый) и по теме в меня попало.
Артур оказался довольно приятным докладчиком. Я давно про него знаю, но послушать не доводилось. А тут вот он какой!

### Санкт-Петербург

Тут записей не было.

Доклады ребят меня не оч вдохновили. Скорее потому что я не поклонник копаться в многопоточке и всём рядом. Но кратенько так:
- Мьютексы для лёгких потоков. Тарас Скаженик.
У Тараса есть научный руководитель Виталий Аксёнов, который выступал ровно с тем же докладом, но на английском, в Белграде: Locks for lightweight threads.
- мой доклад выложу текстом в течение пары недель, если ничего не поменяется.
- LTest: верификатор конкурентных структур данных на C++. Илья Кокорин. Кирилл Гарманов.
Тут ребята рассказывали про что-то вроде формального автоматизированного способа проверять корректность СД. Звучит как концепция оч прикольно, но, конечно, узко.

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

Конфа понравилась. Кайфанул.

#cpp

Напишем make_index_sequence.

https://graph.org/index-sequence-08-07

Рядом упомяну пост про type_traits в общем: https://t.iss.one/thisnotes/341