#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, и иногда распознать базовые случаи, в которые стоит поступить ровно так, как написано, сложно. Или иногда сложно понять, а как правильно сейчас поступить.
В моей голове эти пунктики очень хороши для вашего роста, если вы хотите расти быстро. Но ещё важно не забывать, что иногда надо не расти, а учиться. И что эти вещи не всегда в моменте совместимы. Вдолгую да, но не всегда сейчас.

#common

Сегодня 1 апреля, потому можно позволить себе некоторую вольность в материале.

Меня всегда занимали разные парадоксы. Не все, конечно. Только некоторые. Например, парадокс горки (я не знаю, как он называется в оригинале). Давайте проведём мысленный эксперимент. Вот есть у вас песчинка. Одна маленькая песчинка. Вы добавляете к ней вторую. Теперь это 2 песчинки. Вы добавляете по одной песчинке и в какой-то момент у вас уже не просто много отдельных песчинок. У вас уже что-то вроде горки. Такая небольшая, насыпанная вами сущность-композиция. Если вы продолжите добавлять по одной песчинке, то на бесконечности у вас образуется гора. Огромная такая гора песка. А теперь вопрос: в какой момент она стала из горки горой? Вы теоретически можете добавлять по одной песчинке, считая их, и наверное сможете сказать, что вот эта, n-я песчинка всё меняет. Она перешла черту. Она всё изменила. На практике же такого момента не будет.

Это заставляет меня регулярно задумываться о том, как вообще разграничивать размеры.

Вот есть эти наши микросервисы. У них в названии есть МИКРО. Типа маленький. Сервис на 10^(-6). Но что такое микросервис на самом деле? Вы можете активно его развивать, регулярно дописывать код и в какой-то момент понять, что теперь компилируется он слишком долго, изменения занимают всё больше времени. Деплоится тоже долго -- команда во время релиза успевает сделать три другие задачи. Но в какой момент надо было остановиться и сделать что-то в другом месте?
Может ваш микросервис сам по себе даже и небольшой. Кода в нём не так много. Зато внутри у него 5 слоёв абстракции, 13 библиотек, бдшка и задачи в 3 очереди кладутся. Там может хорошая декомпозиция и нет огромных файликов, с другой стороны по 40 хедеров на директорию, 6 из которых уже несколько лет отключены в проде, но всё ещё лежат, ведь никто просто давно на них не обращал внимания.

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

Есть ещё такие сервисы, которые называют микромонолиты. Типа микросервис, который уже большеват. Что-то типа 10^6 * 10^(-6). Микромонолит такой же опасный, как микролит в почке. Он сейчас вроде есть и никому не мешает, но в один момент резко стрельнет и будем всей разработкой пищать.

Ещё у вас может быть монолит в микросервисе. Это когда из 20к строк половина -- один файл. Я даже видел чуть более интересные случаи: полный готовый коммерческий продукт с графикой и сложной математикой в одном файлике на 10к строк. Чем не монолит? Такое тоже наверное надо распиливать.

Или вот это, популярное в Clickhouse small update на +1000 -700 строк. Декомпозицию на задачи мы тоже не забываем.

Или вот эта небольшая задачка от продукта. Где надо 5 кнопок из места в место перенести и это выливается в 1.5 месяца разработки. Небольшое изменение вроде, а вы там какие-то схемы сидите рисуете.

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

Или моё любимое: two-pizza team -- команда, которую можно двумя пиццами накормить. Типа маленькая. Никогда не понимал, что это за объём такой странный. 2 пиццы это нам с девушкой на двоих, причём 1.5 съем я. Мы конечно отличная команда, но наверное это не то, что имеется в виду. Делает ли моя возможность съесть 1.5 пиццы меня командой на 0.75? А если я голодный, то я и целой командой себя назвать могу? Может 10X инженеры на самом деле просто голодные?

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

У вас спина белая.

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

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

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

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

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

#cpp

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

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

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

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

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

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

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

4. [article] The Best Programmers I Know.

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

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

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

#common #pub

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

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

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

#books #highload

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

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

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

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

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

500 RPS из 1000.

#highload

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

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

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

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

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

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

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

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

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

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

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

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

#common #math

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

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

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

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

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

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

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

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

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

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

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

#db #common

0. [article/news] Yambda.

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

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

Статья на habr.

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

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

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

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

#highload

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

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

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