#common

A/B-тестирование 1/2.

A/B-тесты это когда вы сравниваете поведение пользователей при различных условиях. Например вы запускаете новую фичу и хотите понять, как она влияет на пользователей и влияет ли вообще. В данном случае вы можете поделить пользователей на две группы: тестовую с фичой и контрольную, у которой новой фичи нет. После какого-то времени смотрим на метрики и понимаем, отличаются ли значения у этих двух групп (прокрасились ли метрики и как они это сделали). Если результаты положительные, фичу можно принимать (в общем случае). Можно конечно принимать решения на ощущениях, но это опасный путь, который в долгосроке засадит ваш продукт в глубокую яму (если им злоупотреблять конечно).
Ну это ладно. Концептуально, я думаю, вы всё это знаете. Хочется осветить несколько связанных моментов.

1. Про разделение пользователей на группы😎

Это вообще довольно широкая тема, но концептуально тут существует всего пару подходов:
- берём всех пользователей и делим на k групп. При запуске нового эксперимента (экспа) берём две свободные группы из общего пула. Как только группы заканчиваются, приходится ждать, пока какой-нибудь эксп завершится, чтобы можно было начать новый;
- второй способ это перекрывать пользователей. Например пользователь может находиться сразу в нескольких тестовых группах и таким образом попадать под несколько экспериментов сразу (какие-то могут быть вкл, какие-то выкл). Реализовать это можно так: брать user_id и хешировать его с некоторой уникальной для эксперимента солью (seed для нашего хеша). Если сделать всё аккуратно, получится равномерное распределение пользователей на группы.
Однако в таком подходе стоит следить за тем, являются ли экспы независимыми, чтобы не похерить себе результаты.
Можно подходы в разных видах комбинировать.

Иногда у продуктов бывает своя специфика, из-за которой проводить аб-тесты над отдельными пользователями некорректно. Например в социальных сетях иногда проводят эксперименты над кластерами пользователей (link).

2. Важно правильно задизайнить эксперимент🤔

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

#common

A/B-тестирование 2/2.

3. AA(B)-тесты🥳

Иногда вы хотите быть уверенным, что поведение пользователей и соответственно результаты эксперимента будут корректными, потому делите пользователей не на две группы, а на три (A, A и B). Таким образом вы смотрите, что ваши A-группы ведут себя одинаково и что B-группа приносит. Если же обе A показывают разные результаты, то у вас что-то не так с дизайном эксперимента (ну или чем-то другим). Соответстственно иногда даже проводят AA-тесты, чтобы понять, всё ли ок с точки зрения разбиения/поведения пользователей.

4. Ухудшающие тесты😍

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

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

5. Просадка метрик не всегда плохо😁

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

Ну а может ваша фича крутая, просто снаружи в мире произошло что-то, что массово повлияло на пользователей? Причём это может влиять как в хорошую, так и в плохую сторону. Такие вещи важно отслеживать.

6. Жгущие эксперименты☺️

Иногда новая функциональность начинает приносить огромный профит сразу с запуска. Чтобы не терять профит во время проведения теста, можно после включения 50/50 зафиксировать результаты, включить фичу на 80% пользователей и продолжить эксперимент на 10/10 (все доли конечно индивидуальны).
Подобный подход даже иногда автоматизируют, когда, например, раз в сутки самый успешный вариант раскатывается автоматически на бОльшую долю пользователей. В итоге можно получить автоматически раскатанный лучший вариант к концу аб-тестирования.

UPD 7. Обратные эксперименты🥴

Обратный эксп это когда вы отключаете фичу вместо её включения.

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

Получилось, что мы включили функционал и получили рост метрик, а потом отключили функционал и получили ещё больший рост : )

Тут ссылочки на два доклада:
- Какие архитектурные решения в Яндекс Go позволяют запускать десятки продукт.экспериментов;
- Без A/B — результат XЗ, или Как мы построили платформу A/B-тестов в Ozon / Евгений Пак (Ozon).

#cpp

Наткнулся случайно на доку gcc, где описаны всякие штуки, которые поддерживает компилятор, и при просмотре увидел разные интересные (и не очень) штуки (и стандартные, и специфические для конкретного компилятора). Расскажу про несколько из них.

1. Тут в п.6 я писал про new_handler. Аналогичные штуки есть для std::terminate и std::unexpected.

2. Есть целый пак контейнеров, которые расширяют то, что есть в стандартной библиотеке. Некоторые концептуально повторяют уже существующие, некоторые нет:
- какая-то реализация для красно-чёрного дерева;
- реализация rope;
- реализация slist, что, кажется, просто forward list;
- какая-то ещё одна реализация строк под названием __versa_string;
- dynamic_bitset. Хотя конечно лучше брать такое в boost;

- думаю, многим известный valarray;
- gslice, являющийся подмножеством valarray;
- indirect_array, которые тоже подмножество valarray, но зададётся множеством индексов элементов;
- mask_array, задающий подмножество битовой маской.

- mini_vector, являющийся урезанной версией std::vector и работающий только для built-in и POD типов. А ещё он память не чистит🤪
- gp_hash_table — общий класс для hash-based ассоциативных контейнеров. Из интересного тут можно задавать свою resize policy (думал про такое для вектора когда-то).


3. Разные алгоритмы:
- subtractive_rng — генератор случайных чисел, основанный на каком-то там алгоритме;
- функция для нахождения медианы. Интересно, как это нормально делать сейчас стандартной библиотекой, чтобы не складывать числа в контейнер и не юзать nth_element. Пропозалов на это не видел.

4. Всякие utils:
- реализация decimal;
- bitmap_allocator;
- freelist (про него и чувака выше можно почитать тут);
- пак утилит для дебага.

5. Type traits:
- реализации is_detected и detected_or;
- is_fast_hash, который реализован как угар имхо: для всех типов он fast, а для long double нет😏
Но вообще тут поинт в том, что вы как юзер можете написать специализацию, которая говорит, что для вашего типа хеш считается долго. Контейнер при этом будет кешировать значения хешей.

Короч накодили и живут себе.

#cpp

C++ Zero Cost Conf 2023.

Трек в Москве (link на трансляцию).

Был доклад про устройство компиляторов (я базово писал про это) и зачем в VK свой.

> Тут докладчик сказал, что они написали свой compiler и ускорили бекенд в 10 раз. Подумал, что очень хороший план писать на чём-то вроде php, чтобы потом переписать или накрутить трансляцию в плюсы и говорить, что всё очень сильно ускорили😂
> Оказалось, что доклад реально про KPHP, про который они уже рассказывали мильён раз в других местах🤯

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

У Ильи Шишкова был доклад под названием “Не с первого раза: упрощаем С++ код с помощью DSL”. Доклад примерно про то, как ребята решали какую-то бизнесовую задачу (я такое очень люблю). Я не прям понял всю специфику задачи, но солв интересный, не прям тривиальный C++ (всё понятно, но не циклы с ифами), процесс движения по задаче знаком (я думаю) каждому, рассказывает он хорошо. Можно смотреть.

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

Доклад про корутины скипнул.

Антон Полухин рассказал новости от рабочей группы 21. Я делал выжимку в феврале. Докину про C++26:
- можно будет использовать плейсхолдер _ для неиспользуемых переменных (много раз в рамках области видимости). Теперь читы с макросами для получения анонимных имён не нужны (3й пункт). Тут Антон несколько раз говорил, что комитет смотрел на несколько крупных кодовых баз, чтобы реальные юзкейсы для каких-то фич и делал из этого какие-то выводы. С одной стороны круто. С другой стороны имхо параша какая-то. Словил вайб подгонки некоторых фичей под существующий у кого-то говнокод🤯;
- нормальный std::to_string для floating_point;
- hazard pointer и rcu;
- native_handle какой-то для получения дескрипторов файлов;
- std::function_ref;
- ещё больше constexpr (для комплексных чисел например);
- std::submdspan — подмножество std::mdspan из C++23 (код какой-то оч неприятный конечно с этими штуками);
- хеширование для типов из std::chrono;
- рефлексия пока не готова. Мб повезёт и будет в 26м стандарте (мб нет);
- контракты могут к 26ому стандарту доехать;
и всякое разное ещё.

Ощущается, что на некоторые вопросы Антон не пытался отвечать и просто съезжал👀

Что-то московский трек не очень порадовал. Есть ощущение, что конфа делается чтобы делать конфу. Завтра расскажу про белградскую часть.

#common #cpp

0. Это вообще довольно известная штука, но я о ней не писал, так что поделюсь.

Когда вы учите C++, вам говорят, что возвращаемое значение на перегрузку не влияет. Но это не значит, что нельзя использовать силу рук, чтобы намутить такое. Мы же всё-таки на C++ пишем☺️

Пусть есть две функции, которые отличаются только возвращаемым значением:

int process(std::string s);
bool process(std::string s);

Мы хотим, чтобы следующий код заработал:

int i = process(some_string);
bool b = process(some_string);

Нам поможет вот такая замечательная структура:

struct converter {
std::string s;

operator int() const;
operator bool() const;
};

у которой операторы приведения типа как раз совершают необходимую логику, соответствующую функциям process. Тогда наш код превращается в

int i = converter{some_string};
bool b = converter{some_string};

Ну или можно сделать немножко аккуратнее и написать общую функцию, чтобы детали реализации не висели наружу:

converter process(std::string s) {
return converter{s};
}

int i = process(some_string);
bool b = process(some_string);

И ссылочки.

1. Unexpected downsides of UUID keys in PostgreSQL.

2. Big Data is Dead. Статья прикольная, потому что идёт вразрез с моим мироощущением, где данных очень много и рано или поздно это начнёт приносить проблемы.

3. Goodbye, Clean Code.