this->notes.

#highload

Старожилы канала могли заметить, что фокус потихоньку сместился с C++ на бэкенд и архитектуру. Это логично: я профессионально расту, больше вещей меня увлекают, интересы становятся шире и глубже. Ограничивать себя только плюсами уже не хочется. Хочется писать про что угодно. Может через год это будет каналом про PHP. Я не знаю. Вряд ли конечно. Но запрещать себе такое я не буду.

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

Где-то далеко в дереве моих коллег есть Саша Федькин. Он руководит сектором клиентского бэкенда в Crowd. У нас уже в этом месте матчится рабочая зона ответственности, а отсюда вытекают знакомые проблемы, задачи и специфика.

Лично я с Сашей не знаком, но за его активностью уже некоторое время слежу. Активничает он у себя на канале: @MicroservicesThoughts.

Пишет про архитектуру, бэкенд и всё что рядом. Вот вам несколько из множества постов, которые мне зашли:
- про circuit breaker
- tail latency и hedged запросы
- прикольная загадка про postgres
- snapshot isolation
- про bloat в postgres

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

#list

0. [talk] The Power of C++ Templates With mp-units: Lessons Learned & a New Library Design.

Mateusz Pusz рассказывает про проблемы mp-units v1 (вообще-то v0), не user-friendly проблемы и новые решения библиотеки (v2). Довольно сочный доклад с точки зрения проектирования хорошей крепкой библиотеки и фундаментального к её проектированию подхода.
Из интересного: автор не хочет жоска поддерживать обратную совместимость и топит за то, что необходимо максимально использовать новые фичи языка, т.к. они делают либу более приятной в использовании. Звучит хорошо, но всё же. Обновиться на новую версию либы теперь означает обновить себе компилятор, обновить стандартную библиотеку и только потом обновить либу. На первых двух шагах ломаются большинство заряженных челов. Особенно если под это нет отдельной команды.
Доклад 2023его, если вдруг. И будьте готовы. Он 1:22.

1. [article] Controlling the Rollout of Large-Scale Monorepo Changes.

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

2. [article] Do the simplest thing that could possibly work.

3. [bonus article] Algorithms for making interesting organic simulations.

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

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

4 октября в Москве будет митап про бэкенд и ML, который делают довольно близкие ко мне коллеги. В программе доклады про рекомендательные системы, ллмки, YDB, поиск и автономный транспорт. Всё вкусное.
Можно приехать офлайн. Можно смотреть трансляцию. Нужно только зарегистрироваться.
Если сомневаетесь, надо ли вам это, то вот напоминание, зачем вообще на подобные мероприятия ходить. Ну и за контентом, конечно же.

#highload

Хочу сказать пару слов про деструктивный паттерн, который можно обнаружить в книжках о подготовке к сисдизу. В большей степени этим страдает Grokking the system design interview, в меньшей System design interview by Alex Xu. Уверен, ещё и много других (несколько случайных скринов для пруфов).

Одна из проблем таких книг в том, что они концентрируются на "сделать, чтобы работало". И для прохождения собеседования на middle этого будет часто достаточно. Но если ваша секция на роли посерьёзнее, "просто работает" не катит. Надо детальнее объяснять выбор технологий, иногда посчитать бабки и (!!!) как решение будет поддерживаться.

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

Перед описанием проблемы, кратко посмотрим на то, почему shared database подход вообще может возникнуть:
1️⃣ Если вы молодой стартап и торопитесь сделать хоть что-то работающее, то не заморачиваться с поднятием отдельной БД может быть сильным срезанием в сроках.
В т.ч. не нужно делать API и учиться в него ходить.
2️⃣ Если вы в процессе распила монолита (strangler паттерн), это может быть естественным шагом развития вашей системы.
3️⃣ Если у вас уже есть одна фулл настроенная БД, то иметь желание сократить ресурс на администрирование второй вполне естественно (актуально для команд с небольшой экспертизой и слабой инфрой). Также можно экономить на лицензиях и железе в целом.

Это всё конечно хорошо, но скорее от бедности. Понятно, что какое-то время жить с таким решением ок и даже необходимо. Но если вы крепкая уверенная компания, которая беспокоится о своей доступности, то надо не ковыряться в носу и идти править. Потому что
1️⃣ У сервисов с общей БД связность (или coupling) мгновенно возрастает до небес.
- Хотите изменить схему? На здоровье. Делаем это в сервисе А. Забываем в сервисе Б. Получаем отвалившийся Б, не готовый к подобным изменениям.
Здорово, если Б не является критическим для ваших пользователей сервиса. Всего-то фича какая-нибудь сломается. Но бабки вы можете потерять.
- Не забыли сделать изменения и во втором сервисе? Молодцы! Но потратили время на эти изменения -> ТТМ задач выше возможного. Так что тут ещё посчитать надо, больше ли мы экономим, чем тратим.
- Забыть поддержать изменения в другом сервисе всё-таки довольно просто. Часто это какое-то тайное знание. Про которое не знает любой новый разработчик. Если ему(ей) не скажут, то он(а) узнает только на опыте. Первые пару раз можно и не вспомнить, даже если знаешь. Можно забыть кому-то подсказать в моменты рабочей душноты. В CI особо такое не проверишь.
Всё против вас.
2️⃣ Нарушаем инкапсуляцию.
Если в сервисе А набагали (а это eventually произойдёт), данные для двух сервисов могут быть битыми. А если ещё и А не критичен, а Б критичен, то вот вам неприятный инцидент и потеря денюжек.
И ответственность размывается. Надо помнить, чья это БД на самом деле, а кто просто рядом стоит. Чтобы случайно не сделать удаление данных в Б, хотя за все остальные операции отвечает А.
3️⃣ Масштабироваться сложно.
У сервисов могут быть разные паттерны работы с данными. Например А обрабатывает онлайн запросы пользователей, а Б -- аналитические запросы аналитиков. Тяжёлый аналитический запрос со сложной агрегацией и большой read нагрузкой может просто приложить вам БД или хотя бы просадить перф -> вы проиграли в деньги.
Было бы здорово иметь отдельные инсталляции, которые можно масштабировать отдельно под задачу, в т.ч. выбирая подходящие технологии для конкретного типа нагрузки.

Отдельно ещё отмечу про картинку 2, где существует отдельный сервис для очистки данных (cleanup). Он тут абсолютно не нужен по причинам выше. Можно смело сделать отдельную компоненту в изначальном Key generation сервисе, которая раз в какое-то время (может по ночам) будет чистить БД от лишних данных. Это даже и разрабатывать проще. А если на собесе хочется показать, что вы про это не забыли, так напишите рядом в ответственности сервиса с бизнес-логикой, что он будет делать. И не делите на сервисы без необходимости. Чем меньше квадратиков вы нарисуете, тем проще будет.

#list

0. [article] Structured bindings in C++17, 8 years later. С++26 Updates.

Наш польский коллега рассказывает TLDR истории structure bindings. Интересен последний кусочек про C++26 апдейты. Это и использование фичи в if, и введение паков, и атрибуты для неё, и constexpr.

1. [article] Лёша @it_tldr написал пост про кеширование в Uber.

Жир.

2. [article] The Hidden Cost of Slow Feedback Loops.

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

3. [article] Figma’s $300k Daily AWS Bill Isn’t the Scandal You Think It Is.

Недавно Figma разгласила, что они тратят огромные суммы на AWS. И в интернете проснулись диванные аналитики, утверждающие, что это кринж тратить такие суммы.
Профессионал экономии на AWS поясняет, почему они не правы (спойлер: потому что это нормально).

4. [article] OpenFreeMap survived 100,000 requests per second.

Такая миленькая статья от автора OpenFreeMap про то, как он обнаружил жирного клиента, высокую нагрузку и чувство удовлетворения от проделанной работы.
Там ещё есть ссылка на neal.fun. Я в очередной раз завис.

#highload

Есть такой паттерн speculative execution (для любителей нативного русского💪💪💪 C2 -- спекулятивное исполнение). Паттерн заключается в том, чтобы делать префетч данных ещё до того, как пользователь захочет что-то увидеть, чтобы в момент, когда он всё-таки это захочет, показать ему готовый результат.

Идея довольно простая и логичная. Ниже пару примеров.

💪 В instagram мне когда-то давно-давно попадался reels, в котором один из топов того же instagram рассказывал, что в какой-то момент они стали предзагружать фотографии с устройства к себе на сервер, если пользователь зашёл в таббаре во вкладку про выкладывание фотографий. Таким образом, пока юзер сделает подпись и отметит кого-нибудь, у вас уже загружена фотка и пост создаётся почти мгновенно. Юзер в шоке.
👉 Трейдоф: сколько фотографий с локального устройства загружать. Понятно, что чем больше, тем дороже это обходится по ресурсам, но тем вероятнее юзер впечатлится.

💪 Хороший продукт умеет угадывать, что дальше будет делать юзер.
Например, если пользователь листает ленту в вашей социальной сети, то почти наверняка он и продолжит её листать. Потому можно предзагрузить следующие 10 постов, чтобы отобразить их мгновенно и юзер не успел подумать, что хватит сидеть в тиктоке.
Или, например, сидит ваш юзер и смотрит на красивый товар. И из поведения пользователей вы знаете, что с этим товаром часто смотрят похожие/аксессуары к нему/товары того же бренда. Можно предзагрузить эти товары заранее.
👉 Количество запросов конечно же растёт.

💪 Представим, что вы хотите ускорить ваше приложение, но в самом начале какой-нибудь важной ручки торчит синхронный поход в другой сервис, без которого ну никак нельзя. Пусть это будет поход в антифрод, который говорит вам, надо вообще этому юзеру отдавать контент или заблокировать его нафек. Или может контент так и так отдать надо, но в разном виде: со скидками или без них.
Делаем поход в антифрод асинхронным и запускаем две ветки в коде: которая считает, что наш юзер лапочка, и которая считает, что он злодей и его надо наказать. Когда ответ от антифрода готов, отбрасываем ненужную таску/результат и оставляем нужное.
👉 Можно знатно нагрузить и себя, и другие сервисы, от которых зависит ваша логика.

💪 Может у вас есть какие-то фильтры в приложении. Например, как в любых картах "Заведение открыто", "Заведение близко", "Заведение с пивом". Можно предпосчитать результаты для самых популярных комбинаций фильтров, чтобы отобразить их юзеру мгновенно.
👉Тратим ресурсики на то, что может и не понадобится.

💪 Делаете вы поиск. Взяли да посчитали выдачу для самых популярных запросов. Да положили её в кеш. Теперь на самые крутые топовые запросы вы отдаёте ответ жоска мгновенно.
Или вводит пользователь запрос, а мы у себя его уже продолжили и для топ-5 саджестов уже и выдачу подгрузили, чтобы при клике побыстрее её отобразить.
👉Разменялись на память/ресурсы.

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

Примеров можем насобирать ещё тыщу, но суть вы уже поняли.

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

И сперва стоит сначала попробовать честно пооптимизировать. А то может у вас там валенки какие базовые. Лишние походы по сети или копируете что-нибудь жирное, а тут начнёте трейдофы трейдофить. Да код станет сложнее поддерживать.

### Остальное

Часть 2/2.

1. Развивать B2C-сервис или сделать SaaS? Мы решили не выбирать. Павел Подколзин.

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

2. Особенности обработки большого потока данных с камер. Дмитрий Баринов.

На кост конф я уже постил доклад Арсентия про разработку роботов в Яндексе. Тут Дмитрий рассказывает про задачу рядом: распознавание меток теми же роботами на складах.
Понятно, что внутри всё оч сложно и потому работает, но выглядит всё ещё как магия.

3. Точный адрес — вечная боль! Михаил Колосов.

Приятный доклад про проблемы работы с адресами. Мой опыт говорит, что это постоянные проблемы. Докладчик тему раскрывает неплохо (на примере РФ).
Ещё напишу про это как-нибудь.

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

Вот и всё. Приятного просмотра.

#highload

Часть 1/2.

Недавно выложили доклады с Highload++ 2024. Я так понимаю, в его рамках ещё проходил Golang Conf 2024 и PHP Russia 2024. На первом я хотел послушать пару докладов по интересным сверху темам, но их качество не зашло, а в пхп я в целом не интересуюсь.

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

### Поиск и рекомендации

1. Гибридный поиск на базе OpenSearch и Qdrant. Егор Прохоренко.

Докладчик из жёлтого банка рассказывает про то, как делали гибридный поиск: в случае ребят это когда есть полнотекстовый поиск (OpenSearch) и векторный (Qdrant) для некоторых документов, и хочется уметь матчить выдачу их двух флоу. Точнее про внедрение векторного поиска к основному и как их матчили.
Задача в общем случае прикольная. Таска мержа выдачи не самая тривиальная, если делать её адекватно. У движков разные релевантности, и подгонять под одну шкалу можно, но сложно. И модель-мержилка должна как-то учитывать релевантности от источников, а не просто по своему какому-то признаку отранжировать кандидатов. Надо думать короче.
Хотя доклад больше бэкендерский и архитектурный, чем мльный.

2. Поиск в видеоконтенте при помощи AI. Александр Соколов.

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

3. Ускорение индекса в поиске по VK-видео. Федор Петряйкин.

Интересная история про ускорение поиска в VK видео.
Там примерно математика и какой-то новый алгоритм из какой-то там статьи. Понравилось.

4. Как мы сделали рекомендации, отказались от подрядчика и заработали денег. Данила Федюкин.

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

### Инфраструктура

1. Как на самом деле работает Apache Iceberg. Владимир Озеров.

Я знал слова вроде Data Lake, но концепция не была уложена. После этого доклада осознал чуть больше, появилась картинка в голове. И название Apache Iceberg получило какой-то смысл.

2. Почтовые приключения с PostgreSQL: как приручить 650+ шардов и выжить. Кирилл Григорьев.

История про шардирование постгри. Задача важная и нужная. Решение интересное. Впитал.

3. AppHost: как Яндекс организует взаимодействие сотен микросервисов. Константин Вуколов.

Я руками AppHost никогда не трогал, но со стороны и из отзывов коллег выглядит прикольно. Доклад раскрывает детали, что же это такое.
Если кратко -- штука, которая позволяет управлять графами походов между сервисами.

4. Динтаблицы YTsaurus — и ещё одна СУБД от Яндекса. Руслан Савченко.

YTsaurus это крута. Динтаблицы в нём ещё круче. Руслан Савченко -- прекрасный докладчик.

5. Как объединять данные из разных СУБД и делать это эффективно. Виталий Исаев.

Я не оч шарю за федеративные СУБД. Тут не рассказывается про их базу, но какие-то вещи осознал. Плюс саму задачу про объединение раскрыли.

Илья @imhired Шишков проводит опрос про ваши проблемы в карьере, что вас тревожит, ваши ощущения от рынка и связанные вещи. Знание ваших ответов поможет ему понять актуальные сложности для всех нас и подумать, как же можно помочь их преодолеть.

Анкета минут на 10-15, не самая короткая.
Зато ваша помощь и участие -- неоценимы.

Ссылка на анкету тут.

#list

1. [article] The Evolution of Uber’s Search Platform.

Из интересного про первую итерацию в виде Elasticsearch сказано совсем чуть-чуть, пусть она и существовала довольно долгий промежуток времени. Ситуация примерно "использовали как чёрный ящик и были скорее SRE". Мой небольшой опыт наблюдения за развитием поиска говорит, что это хорошо какое-то время, но рано или поздно вам придётся делать что-то своё с нуля. Тогда больше контроля и возможности выжимать качество. Можете строить любой сложности пайплайны и системы, не ограничиваясь возможностями условного Elastic'а.
Вот и в Uber в итоге упёрлись в ограничения и пошли пилить свой более real time движок. А потом всё свелось к опенсорсу.

2. [article] Did you mean "Galene"?

Статья от LinkedIn про свой новый (ну как, 2014ого года) поиск, на который ссылаются авторы статьи про поиск Uber выше. Чуваки решили, что Galene выглядит хорошо и для своего Uber-поиска забрали некоторые решения.

3. [article] Reflecting JSON into C++ Objects.

Рефлексия это жоска.
В статье чувак рассказывает про то, как можно взять простой JSON и сгенерить из него структуру с помощью рефлексии, которая нет нет да и примерно уже есть в C++26.
Ну жир.

4. [article] Так ли плох Go в глазах C++ разработчика: пишем микросервис и учимся на ошибках.

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

5. [article] Naming Software Teams.

Вроде какая-то базовая штука. Ну какая разница, как вы команду назовёте. Но это реально может решить сто миллионов проблем и убрать некоторый объём нерелевантной нагрузки.
Хотя иметь тупое смешное название прикольно. У нас вот чатик команды до сих пор называется так, как в момент моего прихода 4 года назад. А имя мы меняли уже раза 3.

#cpp

Немного про стандартную библиотеку.

https://graph.org/Standartnaya-biblioteka-07-26

#books #em

Мама, я тимлид! Марина Перескокова. (2022г).

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

Содержание примерно такое:
1️⃣ часть рассказывает про первые моменты становления руководителем: ожидания от других, приоритеты, потенциальную потерю компетенций и отношение к этому, как крутиться при непонимании ситуации и подготовке к новой роли.
2️⃣ часть про взаимодействие с начальником. Не то чтобы прям managing up, но как не быть херовым подчинённым.
3️⃣ про наиболее важный кусок в руководительстве -- команду: цели, текучка, делегирование, рост, микроменеджмент и ответственность.
4️⃣ концентрируется на работе с отдельными подчинёнными. Тут обсуждается как мотивация и рост, так и найм и увольнение.
5️⃣ про то, как создавать и укомплектовывать команду. Что важно при развитии команды как системы.
6️⃣-8️⃣ -- небольшие части про заботу, целеполагание и творчество (и как это всё можно использовать на благо себе и команде).
Последняя 9️⃣ часть обсуждает вопрос работы в распределённой географически команде. При этом авторка концентрируется не на ситуации, когда у вас отличия в 8 часов и коммуникация сложная, а когда один чувак может грустить в другом городе. Т.е. базовая версия распределённой команды.

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

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

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

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

6 подчинённых из 7.

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

#list

0. [fact] Вот мы пользуемся std::optional<bool>. Или std::optional<SomePtrType>, когда хотим разграничивать три стейта: осознанный true, осознанный false и отсутствие значения (аналогично с указателями). И очень легко попадаемся на тупейшие баги:

if (value) {...}

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

Имхо вот это хорошее место, где язык мог бы подпушить писать более хороший код. Сейчас уже к сожалению такой пропозал отклонят, т.к. он ломает огромное кол-во кода.
Мы у себя рекомендуем не использовать неявный каст опшионала и operator*. Вы скажете, что альтернатива .value() это лишняя проверка. А я отвечу, что
- эта проверка нам и нужна: скорость дебага гораздо важнее потерянных наносекунд в рантайме, т.к. падение сервиса -- денюжки
- какой смысл микрооптимизировать if, если рядом сетевой поход на 500мс
- никто не мешает написать аналогичный метод без проверки. Зато защищаемся от потенциальных проблем в логике.

1. [article] You should delete tests.

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

2. [article] Making Postgres 42,000x slower because I am unemployed.

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

3. [article] Would you like an IDOR with that? Leaking 64 million McDonald’s job applications.

Даже у больших компаний масштаба world бывают базовые проблемы с секурити. Штош. Хорошо, что это нашли.

4. [lightning talk] :

Без комментариев.

#cpp

Напишем make_index_sequence.

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

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

#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++. Илья Кокорин. Кирилл Гарманов.
Тут ребята рассказывали про что-то вроде формального автоматизированного способа проверять корректность СД. Звучит как концепция оч прикольно, но, конечно, узко.

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

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

#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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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