#highload #common

Я сначала думал "ух нафигачу пост", а потом оказалось, что самое интересное на поверхности, а дальше муторные детали. Ну и ладно.

Ещё и в телеграф фотки тяжковато стало заливать. Пора свой сайтик заводить.

Geospatial indexing.

https://telegra.ph/Geospatial-indexing-11-05

#common #cpp

0. [fact]

Недавно обнаружил, что, когда делаешь throw Response200 из ручки в userver, ты получаешь честный 499. Это в моменте было не очень удобно, потому что пришлось городить лишний try-catch/проверку на успешность выполнения логики, что не давало красиво спрятать детали внутрь функции. Но зато это напомнило важный принцип про то, что exceptions for exceptional. Я в моменте про это забыл, хотя сам когда-то писал про такое.

1. [little book] Продуманная оптимизация.

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

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

2. [post] Founder mode.

Я наткнулся на Ваню Чернова через в одном из его докладов на Highload. Доклад был хорош. Канал тоже приятный. Он иногда пишет про какие-то технические вещи. Иногда про что-то более абстрактное. И пишет интересно.

Тут у него три статьи про т.н. founder mode:
- эссе от Paul Graham про само явление
- статья с критикой эссе выше
- и сбоку, но в дополнение статья про Goodhart's law.

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

3. [talk] Peering Forward - C++’s Next Decade.

Это первый из сотни докладов на CppCon 2024.
Herb Sutter пускается в пространные рассуждения о том, насколько круче становятся плюсы в следующих стандартах, концентрируясь на рефлексии и безопасности. Иногда с конкретными примерами. Полезно и слушать приятно.

#common #cpp #highload

Сегодня 3 ссылки на знакомых.

0. [article] Саша написал огромнющий пост про юникод.

Комментов не будет. Идите читать)

1. [article] Грязные трюки C++ из userver и Boost.

Антон Полухин выкатил пак плюсовых читов из userver. Пост написан по мотивам доклада на C++ Russia в этом году, так что можете почитать и не смотреть его через 3 месяца, когда наконец выложат.

2. [talk] История развития цикла заказа в Яндекс Лавке.

[Довольно близкий ко мне] коллега на FoodTech туре в Москве рассказывал про то, как в Лавке работает цикл заказа и про то, как его переписывали. Во-первых, мне очень нравится концепция. Там реально сто миллионов проблем ребята решили. Во-вторых, я читал код, и он опупенный. Это просто ещё придумать такое надо было!

#highload

Вот уже год я жду, пока выложат доклады с Highload++ 2023. И вот они наконец появились.

Я насчитал 26 докладов, которые начинаются со слова Как. Богатый русский язык. Решил, что никогда не буду так обзывать свои, даже если очень сильно захочется.

Держите конфеты.

1. [talk] Как выйти в опенсорс и не сойти с ума: опыт YTsaurus.

В основном доклад понравился тем, что Андрей Ривкин рассказал про вещи, о которых я даже не думал. Оказывается, столько всего надо сделать, а не просто исходники на github загрузить.

2. [talk] Опенсорс для компаний и разработчиков на примере Boost, C++, userver.

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

3. [talk] Транзакционная репликация в YTsaurus.

Емнип это первый публичный доклад Руслана. И он хорош. Я слушал его сто миллионов раз в различных внутренних штуках. Жутко заходит.

4. [talk] Архитектура бесконечной персональной ленты Яндекс Маркета.

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

5. [talk] Как создается Java.

Было интересно посмотреть на "процессы" у соседей.

6. [talk] Поиск по образцу на последовательностях строк в БД.

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

7. [talk] Как эффективно ранжировать весь товарный Рунет.

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

8. [talk] Математический хайлоад: большие, очень большие и немыслимо большие числа.

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

==========================
Доклады выложили 2 недели назад и всё это время я каждый день заходил посмотреть, а когда же остальная часть (ведь выложили-то всего несколько). Спустя 1.5 недели таких блужданий я понял, что долблюсь в глаза и что на самом деле уже всё на месте давным давно. А мог бы вам это всё сильно раньше показать..

#cpp #common

0. [talk] Message Handling with Boolean Algebra.

Возвращаясь к прошедшему CppCon.
Ben Deane рассказывает про какую-то свою либу для работы с пакетами данных. Выглядит интересно, но самая прикольная часть про реализацию булевой алгебры в либе и некоторых операций с ней. Вспомнил молодость.

1. [article] Around the World in C++: Exploring Time Zones with std::chrono.

Пояснять тут нечего. Bartlomiej Filipek рассказывает про то, как работает с таймзонами в C++20.

2. [article] Don't Break the Bank: Smart Spending on Software Architecture.

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

3. [article] A list of ternary operators.

Наш любимый ? : из плюсов называется тернарным оператором, потому что он принимает 3 аргумента. И т.к. других таких нет, общее имя было оккупировано.
В небольшой статье выше несколько примеров других тернарных операторов в разных языках.

4. [article] Falsehoods Programmers Believe About Job Applicants.

Это даже не статья, а скорее список того, какие некорректные предположения делаются в формах подачи application на работу. Есть пару забавных, например "A job is legal".

5. [article] IMG_0416.

Когда-то на iphone была возможность загрузить видео сразу на youtube, что породило огромное количество видосов вида IMG_XXXX. Статья рассказывает про это.
Можно найти видосик с датой своего дня рождения. Я хотел оставить тут ссылочку на один из своих, но не смог выбрать. Всё забавное попалось.

#cpp

0. [post] Почитайте пост про баг, который у нас был когда-то.

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

Т.к. это std::unordered_map, то понятно, что порядок не гарантируется. И вот почему-то по ночам всё работало идеально. Порядок каждый раз был корректным. После k походов в /products-data мы получали полное множество всех товаров. По утрам что-то ломалось и подобное перекладывание товаров из std::unordered_map в std::vector и последующий слайс из вектора приводил к тому, что некоторые товары повторялись в разных батчах, а некоторые вообще до клиента не доезжали. Никаких релизов/изменений конфигов, которые могли по утрам приводить к изменению порядка обхода мапки, а вечером снова заставлять работать как надо, не было! Вот уж действительно жирнейшая загадка в моём плюсовом опыте.

1. [article] I've Built My First Successful Side Project, and I Hate It.

Интересный пост про прелести продажи пет-проектов. Он почти совсем не технический, а скорее про интересные ситуации, с которыми столкнулся автор в процессе продажи своего софта. Местами вкусно.

2. [little article] A Shiny New Programming Language.

Небольшая статья про новый ЯП, на котором не нужно явно писать код. Схема такая:
- вы пишете сигнатуру функции
- даёте несколько примеров того, как она должна работать
- на основании этого генерируется js код.

Так сказать example driven development.

В статье есть ссылка на github репозиторий, который можно склонить и со своим OpenAI API ключом запустить штуку локально. Я хотел потыкаться на предмет мощности генерации, но жизнь в Беларуси не позволяет мне это сделать, так что может кто-то заинтересуется и покидает в комменты, что смогло нагенерить, а что нет : )

=================
Пост получится маленький. Почти наверняка до конца года я закину ещё только запись своего выступления со вчерашнего foodtech tour в Минске и ссылочки за весь год, чтобы напомнить про посты этого года. Хочется уже немножко выдохнуть и отдохнуть какое-то время.
А может придёт вдохновение и ещё чего-нибудь да закину.

#common #pub

Выложили запись моего выступления на foodtech tour.

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

Впечатления такие:
- круто не ездить на митапы в Москву, а делать это всё в родном месте. После митапчика дома отдыхать в кайфик.
- чувствую дифф даже с последним выступлением, но точки роста маячат. Надо качаться дальше.

Запись тут: https://www.youtube.com/watch?v=efIvao0bqlg

#common

0. [talk] Истории Лавки про ускорение работы в дарксторах.

Коллеги из Лавки на foodtech tour в Казани рассказывали про то, как работают у нас склады и как пробовали ускорять доставку заказов. Нравится мне такое, когда про лавочку снаружи говорят и есть что вам показать.
Костя кстати жоска в кикер ещё катает.

1. [talk] С той же серии митапов foodtech tour коллеги из Еды рассказывали про то, как ускоряли главную. Вроде конечно и ничего такого, но всё же интересно и напоминает про основные действия для оптимизации продукта.

2. [article] Новые динтаблицы: вторичные индексы, web assembly и ещё много улучшений к версии YTsaurus 24.1.0.

Месяц назад коллеги выпустили новую версию YTsaurus. В статье рассказали про основные значимые улучшения и доработки.

3. [article] Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges).

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

4. [article] Netflix’s Distributed Counter Abstraction.

Чуваки из Netflix рассказывают, как выглядит их системы для поддержки распределённых счётчиков. Начинают с постановки задачи (правда почти ничего не сказали про конкретные продуктовые кейсы); показывают требования к кейсам, которые у них есть; смотрят на несколько базовых подходов к реализации подобной системы и в конце рассказывают, как сделали они (там велосипедище) с рассматриванием отдельных аспектов решения.

Собрал посты за этот год.

2022: link.
2023: link.

Посты:
- CRTP;
- рейтлимитинг;
- bimap;
- как мы переписывали репликацию корзин в Лавке;
- какая-то комбинаторная задача;
- про суммирование чисел с плавающей запятой;
- про UUID;
- снова про пагинацию;
- про ценность конференций;
- про читаемость кода;
- про устройство codesearch;
- полнотекстовый поиск с Postgres;
- geospatial indexing;
- пачки ссылок/фактов: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24;

Сборники с конференций:
- доклады с SaintHighload++ 2023;
- доклады с C++ Russia 2023;
- доклады с C++ Zero Cost Conf 2024;
- доклады в Highload++ 2023;

Две статьи:
- разреженные структуры данных;
- многообразие связных списков.

Два с половиной выступления (их было три, но записи две; утверждаю, что их достаточно):
- про NRVO на C++ Zero Cost Conf 2024 (на C++ Russia 2024 была урезанная версия).
- про оптимизацию разработки в Лавке на foodtech tour в Минске.

Одно нетехническое:
- про марафон и не только.

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

И про остальное. Фулл тут: t.me/dzikart/64

Написал 46 постов против 51 в прошлом году.

Вы выросли в 2 раза за год.

За рекламой приходили 9 раз. Зачем-то 1 раз предложили порекламить меня. Звали на конференцию выступать. А на другую позвали быть инфопартнёром за билеты. Ох уж эта слава. Я [пока] не соглашаюсь, но кто знает..

Ушёл в EM.

Почти не преподавал.

Иногда пишу в @dzikart, редко пощу в @memesfromhole и потиху занимаюсь @khdocs.

Много-много читал.

Съехался с любимой женщиной.

Вместе начали учить новый язык.

Вместе набили по новой татухе (нет, они не одинаковые и не парные).

Регулярно стриг бороду и уже давно не стриг голову.

Опять вернулся никотинить и пока не понял, как отвернуться обратно.

Посмотрел 263 доклада для себя и для вас.

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

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

Угнал на длинные каникулы. Не болейте.

Начнём год с напоминания.

Разработка это не только про код.
(почти всегда)

Если вы сильный individual contributor, это круто.
Может вы умеете одной левой нафигачить скрипт на brainfuck, чтобы запустить его прямо в проде, правой запуская сложнейшие миграции на очередной postgre, и всё это за O(1) для вашей мудрой головы. Или может вы оперируете simd-операциями прямо над шаблонами в очередной библиотеке для рефлексии на плюсах, одновременно дочитывая последнюю версию стандарта для развлечения. А вечером идёте обучать chatgpt o228, давно обогнав openai в качестве.

И хотя качество кода, несомненно, важно, это не всё.

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

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

Хороший разработчик багает, но редко. А когда набагал, метко и красиво исправляет проблему.

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

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

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

Хороший разработчик принимает конструктивный фидбек и учитывает его в своём развитии. ХР даёт такой фидбек коллегам.

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

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

Хороший разработчик понимает ту самую the bigger picture. ХР понимает, зачем решать очередную задачу, что она даст компании и как это повлияет на пользователя.

Хороший разработчик не лох.

В новом году будьте хорошими разработчиками.

#common

Принёс доклады с Saint TeamLead Conf 2024.

1. [talk] Принятие сложных решений в условиях неопределенности. Марина Самойлова.

Выдвинули базу про то, как разбирать неопределённость. Но интересно не это. Интересно было послушать 2 кейса про то, как что-то летело в тартарары и как это спасали. Люблю про чужой опыт слушать.

2. [talk] Менеджерский путь: вверх или вширь. Виктор Корейша.

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

3. [talk] Как пасти котят, или Проекция опыта работы с дошкольниками на команду. Лилия Герасименко.

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

4. [talk] Единственная ответственность. Роман Хаимов.

Рассуждения про принцип единой ответственности. База, зато про код!

Прикиньте, да. Всего 4 доклада из всей огромной тучи, хотя посмотрел я примерно половину. И всё равно вот эти тоже ну не прям. Просто прикольно местами.

Вот такие вот они абстрактные конференции. Абы поговорить.

#cpp #common #math

1. [talk] C++ Reflection Is Not Contemplation.

Доклад Andrei Alexandrescu с CppCon 2024 про рефлексию. Чуть-чуть посмотрели на базу, посмотрели на несколько последних пропозалов и ушли в сторону в какие-то абстрактные рассуждения. В классической свободной заводной манере. Лайкнул.

2. [talk] Building Cppcheck - What We Learned from 17 Years of Development.

Автор cppcheck рассказывает про то, как развивался проект и про разные вехи на этом пути. Не прям технический доклад. Интересно посмотреть на историю известной тулзы.

3. [article] Preferring throwaway code over design docs.

Автор предлагает почаще кодить прототипы перед тем, как писать дизайн доки/писать финальное решение. Так вы получаете некоторые знания о потенциальных проблемах заранее. А ещё позиционирует смерженные pull request'ы как хорошую "документацию", т.к. они всегда актуальны для какой-то точки в истории. Со вторым я согласен. Но с первым нет. В условиях постоянной гонки и нехватки ресурсов нет времени садиться писать код для большинства фичей. А там, где ошибка стоит дороже всего (большие проекты с жёсткими дедлайнами) такой подход может сильно скушать время, т.к. для большой фичи -- большой прототип.

4. [article] Probability and Games: Damage Rolls.

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

В дополнение закину вам баянистую таску с собеседований в тему (правда не знаю, куда конкретно; мне её рассказывали много-много лет назад).
У вас есть функция rand6(), которая равновероятно возращает целое число из отрезка [0; 5]. Как из неё сделать:
- rand2?
- rand36?
- rand5?
- rand10?
Все они должны строиться поверх rand6 и производных и должны возращать числа равновероятно.

#math #cpp #highload #common

0. [talk] YouTube Scalability.

Доклад про то, как скейлился youtube. Чувак рассказывает про основные проблемы, с которыми столкнулась [тогда ещё] небольшая команда, вплоть до невозможности загружать видео на платформу. Между делом бывают забавные вставки. Несмотря на то, что информация не везде знакомая, рассказывают очень понятно.

Доклад довольно старый. 2007-ого года. Я в школу в том году пошёл.

1. [article] 2D Visibility.

Статья рассказывает базу про то, как работает видимость в 2D пространствах. Хотя контента прям тут не прям много, внутри очень много ссылок на разные доп материалы, так что если вам такое интересно, можно зависнуть.

2. [article] Cognitive load is what matters.

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

3. [article] End-to-end Шифрование.

Вастрик написал пост про End-to-end шифрование. В своём классикал стиле и как для тупых.

4. [article] 4 billion if statements.

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

#common #highload

Принёс доклады с Saint Highload++ 2024.

1. [talk] Как работать с поставщиками на примере поиска доступных отелей. Иван Чернов.

Люблю доклады про поиск в любом виде. С лета как раз из-за этого доклада Ваню и читаю (@chernov_sharit).

2. [talk] Про UUID v.7. Андрей Бородин.

Хороший доклад про технические детали реализации uuidv7 в БД. После него как раз пошёл писать пост про uuid'ы.

3. [talk] Регламент для работы с ошибками в Go. Илья Сергунин.

Люблю доклады, которые пытаются систему дать. Конечно, если кто-то после таких рассказов начинает душнить, что надо делать только так а не эдак, то пошёл в жопу, но забирать себе разумные поинты никто не мешает.

4. [talk] Геораспределенные системы. Евгений Кузовлев.

Хороший доклад про базу геораспределённых систем. С примерами ещё. И Евгений рассказывает приятно.

5. [talk] Enterprise deploy: почему это больно. Филипп Дельгядо.

Системно и подробно про деплой как концепцию.

6. [talk] Механизм пререндера в браузерах. Алексей Кузнецов.

Было прикольно погрузиться в область, в которой я совсем ничего не понимаю. Хороший понятный рассказ про что-то новое.

7. [talk] «А так можно было?» — обзор нестандартной криптографии. Сергей Прилуцкий.

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

#common #highload

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

0. [article] Taking a Look at Compression Algorithms.

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

1. [article] SQL as API.

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

2. [article] Don't make these feature flag mistakes.

Автор рассказывает про потенциальные проблемы, связанные с использованием feature flag'ов, и их решения. Среди прочего есть маленькая история про то, как компания чуть не обанкротилась из-за проблем с этим инструментом. Но, что важно, в конце напоминает, что полностью отказываться от этого инструмента нельзя, т.к. он всё же жутко полезный.

#common #highload

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

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

Что впитать по CRDT.

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

А теперь ссылочки.

[*articles] Можно начать с нескольких статей Matthew Weidner:
- Introduction
- Semantic Techniques
- Algorithmic Techniques
- Further Topics
Они немного душноватые, но если посидеть и подумать, а не смотреть тикток параллельно с чтением, можно что-нибудь понять.
[*articles] Если у вас много-много времени, то можно почитать 12 статей от Bartosz Sypytkowski. Каждая из них поменьше, так что может пойдёт легче.
Если прочитаете и то, и это, будете совсем большими молодцами и, много всего поймёте.
[*talk] Или может вам больше нравится видеоформат, так что можете послушать ликбез по основным структурам данных в CRDT концепции: CRDT: Datatype for the Apocalypse. Правда сумейте вовремя остановиться, а то с какого-то момента начинаются Elixir-специфичные вещи, а мы всё-таки с вами на C++ пишем.

[talk] Теперь слушаем рассказал Martin Kleppman: CRDTs and the Quest for Distributed Consistency. Тут он рассказывает и про Operational Transformation (OT), и про CRDT, и про очень важный в этой сфере Automerge. Есть много примеров, которые сильно качают понималку.

[*talk] Дальше можно посмотреть старенький доклад про зачатки Google Docs и увидеть (если внимательно присмотреться) некоторые проблемы OT. Примерно так гуглодоки сейчас и реализованы.
[*article] Ну и тут вы можете почитать про то, как потенциально могут работать Google Sheets: Conflict-free Replicated Spread Sheets.

Дальше можно посмотреть отличный доклад того же Martin Kleppman: CRDTs: The Hard Parts. Тут вы узнаете, почему из "Hello Alice!" и "Hello Charlie!" может получится "Hello Al Ciharcliee!", про [открытые] проблемы перемещения элементов/символов/поддеревьев.

[*article] Интересно, что в докладе выше Kleppman говорит, что у LSeq есть проблемы, т.к. этот подход interleaving. А вот Bartosz Sypytkowski писал про non-interleaving версию. Что-то там проапдейтил, лис.

[*article] Опять же в докладе Kleppman рассказывал про проблемы оверхеда CRDT. И это то, из-за чего CRDT иногда недолюбливают. Тут статья оптимизацию частных случаев: Making CRDTs 98% More Efficient.

[*article] Тут есть очень прикольная (и жирная) статья про то, как в каком-то Loro реализовывали свой очереднярский CRDT алгоритм для текста. Понравилось, потому что в начале есть интерактивная штука потыкаться и очень много букав. Прям фундаментально тему осветили.

[talk] Ещё есть вот такой несложный докладик про то, как работает delta -- коллаборативный сервис для ведения заметок в Яндексе. Я вот им прям каждый день пользуюсь и очень довольный.

[*site] И если вдруг вам не хватило контента, идите на crdt.tech. Там ещё тыща тыща постов, докладов и настоящих статей.

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

Антон Полухин выложил статью про новинки в C++26: C++26 — встреча ISO в Хагенберге.

Из новых фич к нам подъехали:
- std::hive (пейпер P0447 пережил 28 ревизий и наконец сложился)
- constexpr all the things (покрыли ещё пару кусков стандартной либы)
- #embed
- контракты и другие движения в сторону увеличения безопасности нашего кода
- честный relocate для некоторых типов
- и другое: simd, новые алгоритмы и другие приколюхи.

Осталось дождаться это счастье в компиляторах👉👈

А ещё 25 марта пройдёт встреча РГ21 по C++. Встречу проведёт Антон. Можно обсудить новости последней встречи комитета по стандартизации, задать вопросы и получить на них ответы и потусоваться на афтерпати после : )

Онлайн и оффлайн, Москва.

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

#highload #cpp #common

0. У меня на днях встретилась абсолютно простая задача (прям как на собесе, а вы говорите, что не нужны эти алгоритмы в жизни): в векторе чисел переместить все нули в конец. Недолго думая я делаю

std::remove(vec.begin(), vec.end(), 0);

И для примера

vec = {1, 4, 0, 2, 0, 0}

получаю

{1, 4, 2, 2, 0, 0}

Где-то есть баг.

Очевидно, что баг был в моей интерпретации алгоритма. Вот как выглядит стандартное использование std::remove до C++20:

vec.erase(std::remove(vec.begin(), vec.end(), 0), v.end());

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

И в первом пункте уже ошибка. Ведь нули не ушли в конец. Наоборот, в начало ушли все не нули. Что там в конце, меня ебать волновать вообще не должно. Оно всё равно будет удалено.

То есть мы имеем на текущий C++20-й момент:
- удаляем элементы мы с std::erase/std::erase_if
- если я хочу все нули в конец, то мне нужен std::partition
- std::remove/std::remove_if нужен только ради обратной совместимости, т.к. никакой уникальной задачи он уже не решает. Жаль братка.

1. [talk] Как развивалось прогнозирование в Яндекс Погоде.

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

2. [article] Accelerating LinkedIn’s My Network tab by reducing latency and improving UX.

Суть статьи в названии.
У нас есть какая-то похожая задача, потому было интересно почитать. Жаль только, что они всё же различаются достаточно, чтобы не суметь перенять подход.

3. [article] Your business value.

Очень хорошая статья, которая в каждом предложении напоминает про то, зачем профессия программиста существует. Она, так сказать, постоянно cycle on a subject о вашей личной полезности для бизнеса и разбирает кейсы роста/увольнений в зависимости от разных факторов.
Будьте профитными.

#cpp

Наконец выложили все интересные мне доклады с C++ Russia 2024. Чекаем:

1. [talk] О денотации: разрешение имен и его пересмотр в C++23. Константин Владимиров.

Надо думать, да. Но кайф.

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

2. [talk] Обзор C++26. Александр Фокин.

Местами кайф. Дай бог дожить до всего этого счастья в проде.

3. [talk] Контракты для С++. Тимур Думлер.

От кого ещё слушать про контракты, если не от одного из авторов пропозала.

4. [talk] LeakSanitizer и менеджмент памяти. Алексей Веселовский.

Немного хардкорчика и внутрянки санитайзеров.

5. [talk] Pets, cattle and automatic operations with code. Святослав Фельдшеров.

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

6. [talk] Дерево смещений: работаем с динамически изменяемыми сегментированными массивами. Роман Панов.

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

7. [talk] Грязные C++ трюки из userver и Boost. Антон Полухин.
Или можно почитать текстовую версию на habr.

Последние доклады Антона мне нравятся, потому что от технопиара userver он вернулся в технический хардкорчик. Получилось интересно.

8. [talk] Улучшенные версии STL-контейнеров из библиотеки Boost. Илья Мещерин.

Несложно и интересно. Мне вообще вот такое всё интересно. Про контейнеры и штуки около. Думаю, что надо бы вылить своё понимание этой всей мишуры в вас когда-нибудь.

9. [talk] Полезные трюки С++ на примере организации пайплайна. Павел Сухов.

Я уже кидал ссылку на текстовую версию доклада коллег из Доставки.
Понравилось, что речь про реальную задачу и что в этой реальной задаче получилось поюзать нетривиальные возможности плюсов. Всё то, чего мы так сильно хотим, но так редко можем.

10. [talk] JSON в C++: проектируем тип для работы с JSON-значениями. Павел Новиков.

Забавно, что Павел придумал себе проблему и сражается с ней.
У Павла ещё была вторая часть этой эпопеи на C++ Zero Cost Conf, но она мне меньше зашла. Оставлю тут для полной картинки.

11. [talk] Опасность устарела, неопределенность недопустима: undefined behavior в С++20/23/26. Сергей Талантов.

Хороший доклад про undefined behaviour. Имхо этого никогда не бывает много. Мы ж не хотим сегфолтики в проде ловить??

12. [talk] constexpr-аллокатор для контейнеров стандартной библиотеки. Сергей Добычин.

Я люблю контейнеры, люблю аллокаторы (пруфы раз два) и люблю constexpr. Тут всё разом. Доклад немного напряжный. Надо думать. Но имхо резы у чувака крутые.

13. [masterclass] Выше вилки от Ильи @imhired Шишкова.

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

Онлайн часть C++ Russia 2025 начинается уже завтра. Туда вы можете зарегаться бесплатно в рамках комунити дня.
Я планирую выступать на следующей неделе с, кажется, единственным лайтнингом в этом году и заодно у Паши Сухова на докладе про шаблоны поторчу экспертом. Можете меня где-нибудь найти поболтать, если интересно : )

#cpp #highload #common

0. [talk] The Beman Project: Bringing C++ Standard Libraries to the Next Level.

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

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

1. [article] The billion docs JSON Challenge: ClickHouse vs. MongoDB, Elasticsearch, and more.

Чуваки из ClickHouse сделали бенчмарк, в котором обрабатывали 5 агрегационных запросов на датасете из 1 млрд реальных JSON. Сравнение было с MongoDB, Elasticsearch, DuckDB и PostgreSQL (думаю, вы уже поняли, кто показал себя лучше всего).
Во-первых, имхо очень хороший пример того, как надо бенчмарки описывать. Во-вторых, я не прям уверен, что сравнение всё-таки корректное, т.к. все рассматриваемые бдшки (кроме DuckDB, это хз что такое) концентрируются на не совсем тех же задачах (в моей голове), так что могут спокойно на конкретных сценариях проигрывать. И это нормально.
В-третьих, тем удивительнее, что эластик не пальцем деланый и результаты по перфу на этой задаче у него уходят недалеко. Новое открытие для меня.

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

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