#highload #common

1. [article] Trillions of Indexes: How Uber’s LedgerStore Supports Such Massive Scale.

Статья в блоге ByteByteGo про LedgerStore Uber.
LedgerStore -- это кастомное хранилище Uber для работы с финансовыми данными (в основном транзакциями). В статье рассказывается
- как верхнеуровнево работают различные компоненты (индексы: strongly consistent indexes, eventually consistent indexes и time ranged indexes)
- детали общих инструментов над ними
- и как происходила миграция данных о транзакциях из DynamoDB на LedgerStore.

2. [article] How To Survive Your Project's First 100,000 Lines.

Автор рассказывает про уроки, вынесенные спустя 100k строк компилятора Vale.
Если кратко, то поинты такие:
- не стесняться херачить ассерты
- как можно больше полагаться на систему типов, а там где этого сделать нельзя, пофиксить и полагаться
- оставлять качественные комментарии
- избегать отсутствия детерменизма в коде
- а где не получается избежать, научиться с ним работать
- ТЕСТИТЬ
- и не забывать про скорость разработки.

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

3. [article] Six Degrees of Kevin Bacon - Postgres Style.

Небольшая статья про студенческую игру 90х (видимо, где-то в USA), в которой надо было назвать цепочку от актёра Kevin Bacon до любого другого актёра в Hollywood.
Автор решает эту задачу с помощью открытой базы данных от IMDB с помощью:
- обычной рекурсивной CTE
- расширения Postgres под названием pgRouting, которое применяется для решения графовых задач.

Смысловой нагрузки особо нет. Просто лёгкая забавная статейка.

4. [post] Небольшой пост про то, как бы сократить uuid.

Комментов не будет. Просто фан.

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

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

#common

1. [article] Higher RAII, and the Seven Arcane Uses of Linear Types.

Всё тот же автор языка Vale (на испанском читаем как бале) вводит новую концепцию Higher RAII. Тлдр такой:
- деструкторы в C++ это про вызов одного конкретного метода без параметров, что не всегда удобно.
- higher RAII в Vale позволяет делать сколько угодно таких методов с любыми параметрами и всё равно быть уверенным, что ничего не потеряется.

И в конце накинул примеров, когда это может быть полезно.

2. [article] How Discord reduced websocket traffic by 40%.

Произошло это примерно так:
- перешли на ZSTD. Получилось, конечно, не сразу. Ребята поприседали. Если быть более честным, то на EZSTD для поддержания стриминга.
- перестали отправлять сообщения, которые пользователю сейчас-то и не нужны.

Но это моя вольная трактовка. В статье сильно больше деталей.

3. [article] Understanding Zero-knowledge proofs through illustrated examples.

Zero-knowledge proofs -- концепция доказательства владения информацией, не раскрывая саму информацию.

В статье есть 3 простых примера того, как для абстрактных игр Алиса и Боб могут доказывать друг другу победу в игре без раскрытия самого результата.

Интересно. И обложка у статьи прикольная.

4. [article] Zombie Menace, Vampire Peril.

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

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

============================
В vas3k.club намутили опрос (ссылка в самом начале поста) про то, как расти на позиции выше и с какими проблемами можно столкнуться. Это потенциально касается любого из вас: если вы уже каким-то образом CTO или только задумываетесь о росте в руководители (особенно если так), ваши ответы могут быть Лизе очень полезны.
Я с ней довольно продуктивно пересекался пару раз за последний год и очень хочется помочь.

#cpp #common

0. [article] Полезные фичи С++ на примере организации пайплайна.

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

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

2. [article] Здоровье кодовой базы.

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

Я в последнее время часто про такое думаю, т.к. недавно встретил у студентов на курсе по Java скрины с ошибкой вида:

function 'F' has cognitive complexity of 57 (threshold 25)

Про то, как это в Java считается, верхнеуровнево можно почитать тут.

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

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

#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. Там ещё тыща тыща постов, докладов и настоящих статей.

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