#highload

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

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

#common

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

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

#books

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

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

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

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

Game Programming Patterns. Robert Nystrom.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#common

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#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. Там сто процентов есть крутые детали.

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

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

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

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

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

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

#cpp

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

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

#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

The worst programming language of all time.

Или нет?

Возможно вам уже попадалось видео: youtube.com/watch?v=7fGB-hjc2Gc, рассказывающее, почему C++ — самый ужасный язык программирования. Разберём автором рассказанное.

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

[Пост появился раньше на пару дней на] Patreon и Boosty.

Спасибо Artyom Garkavy за поддержку.

Доброе апреля.

1. Коллега точно подметил, что -Wall это wall of text.

2. Помните, я писал про книгу про API от Сергея Константинова?
У Сергея ещё книга про пиво есть. Мне недавно метко подсказали, что

API + пиво = IPA

Не знаю, как вам это поможет, но в этом что-то есть.

3. Если пропустили контент, то у Miyagi & Эндшпиль вышел трек про std::vector. Так и называется — Vector.

Доброе понедельничное утро.

Два прошлых года я выступал на C++ Zero Cost Conf. Eсли вас тут не было, то в 2024 я рассказывал про NRVO, а в прошлом году всякие приколы про шаблоны и математику.

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

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

И мы принимаем доклады!
У вас есть возможность податься до 11 мая.

Детали тут: https://cppzerocostconf.yandex.ru/

Вот картиночка. Не зря ж её кто-то рисовал.

#books #cpp

C++17 - Iterating Problems.

Я бы сказал, что это не книга, а книжка. Возможно мегабуклет. Просто из-за размера. Но пусть будет книга.

Автор поставил себе задачу исследовать возможности C++17 (да, сегодня это уже немного outdated увлечение).

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

Фичи языка, которые рассматриваются в книге, покрывают (но не ограничиваются): итераторы, type traits, SFINAE, вычисления на компиляции, fold expressions, std::variant, std::any.

Понятно, что код в итоге смотрится ужасно. Вот, например, для Hello world:

template <typename I, typename O>
auto
hello_world(I first, I last, O out) {
    return std::copy(first, last, out);
}

int
main(int, char *[]) {
    auto hello = std::array{"Hello", "World!"};
    auto out = os_iterator<std::string>{std::cout, ", "};
    hello_world(hello.begin(), hello.end(), out);
    return 0;
}

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

Причём это самая простая задача. С самым сжатым кодом. Дальше начинается полный разнос с нечитаемыми решениями.

Но!

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

Из минусов: с какого-то момента книга становится монотонной. Ну штош.

3 итератора из 7.

Спасибо Artyom Garkavy и niki4smirn.
Patreon, Boosty.

#list

0. [talk] "Just switch the compiler", they said. Arne Mertz.

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

С примерами разных проблем. Делится знанием, как пострадать от процесса минимально.

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

1. [quiz] John Regehr's Integers in C quiz.

И это только про С! Хех!

Не справился с двумя вопросами (на самом деле с тремя, но там не считается, вы поймёте). Расскажите про ваши успехи в комментариях!

2. [article] the hidden compile-time cost of C++26 reflection.

Vittorio Romeo рассказывает про [предварительные] замеры скорости компиляции разного кода с рефлексией. Статья называется как-то с намёком на то, что всё плохо, но вроде сам говорит, что не прям.

3. [article] Code is run more than read.

4. В одной из статей (которой делиться я не буду, так как у меня к ней много вопросов) я увидел вот такую фразу:

we needed a tool that fit our engineering culture

Я надеюсь, у вас тоже возникло ощущение беспросветного булшита.

Patreon, Boosty.

#cpp

Принёс доклады с C++ Russia 2025.

В хронологическом порядке.

0. LLVM MemProf и методы профилирования памяти.
Алексей Веселовский.

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

1. [Не]очевидные оптимизации и паттерны из userver. Антон Полухин.

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

На youtube есть смешной комментарий:
> ты ему слово, а он тебе трюки из userver

2. Как компиляторы на основе LLVM моделируют неопределенное поведение и извлекают из него пользу. Макс Казанцев.

Доклад про некоторую внутрянку работы с UB в компиляторах, как они детектят проблемные случаи и что делают с этой информацией. Имхо довольно свежо.

3. Замеряем производительность для высоконагруженных проектов с Google Benchmark. Савва Лебедев.

Введение в gbench. Что важно, там и базовое что-то есть, и что-то, что может вам пригодиться, если вы вроде какие-то бенчмарки писали, но в перф глубоко не погружены. Для становления perf-person.

4. Уроки кодогенерации JSON Schema. Василий Куликов.

Вася — один из основных контрибьюторов userver.
Снаружи (вне Яндекса), в отличие от опенсорсной версии фреймворка, userver изначально имел кодген, который по OpenAPI спецификации позволял генерить готовый код для ручек, внутренних классов и работы с ними. Не нужно было раскладывать JSON в плюсовую структуру самому, например.

Вася рассказывал про новую кодогенерацию в фреймворке.

Я так понимаю, что в итоге именно она в опенсорсе и появилась.

5. Как мы работаем над производительностью мобильного приложения в 2ГИС. Дмитрий Ястребков.

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

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

6. Лицензии ПО: теория, которая спасает от финансовых катастроф. Ольга Кузмичева, Георгий Панюшкин.

Ребята рассказывали про то, что и заявлено в заголовке.

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

7. Ржавеющие плюсы: как внедрять современные проверки С++ в промышленных масштабах. Винсент Амбо.

Винсент рассказывал про харденинг и его внедрение в Яндексе.

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

8. Как заставить шаблоны компилироваться быстро и выглядеть опрятно. Павел Сухов.

Пашу вы должны уже знать.
Меня тоже (я рядом стоял).

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

9. [не доклад, а болталка] Чему C++ может научиться? Антон Полухин. Павел Новиков.

Люблю послушать некоторую внутрянку комитета по стандартизации. Тут Антон как раз рассказал пару небольших историй. Зашло.
.

Я выступал на offline only активности с лайтнингом. Рассказывал про оптимизацию разработки. Это была вариация этого доклада с некоторым уходом в сторону плюсов.

#highload

Redis license stuff.

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

Спасибо Artyom Garkavy и niki4smirn.

Patreon, Boosty.