📝 Ну и вот вам мемас в тему менеджерства, раз уж первый день лета

🥈 DevForum в массы 2

Периодически приглашаем на DevForum в Додо ребят из других компаний. У спикеров есть возможность рассказать что-то нам, а у нас есть возможность спросить что-то у них. Сложно посчитать пользу от такого действия, как в принципе пользу от конференций, обучения и прочего нетворкинга.

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

🏓 То есть работает по такому принципу. Сидит себе разработчик, пилит таски. Вдруг, бац, вспоминает: “А на девфоруме же недавно вот такое рассказывали, может я это сейчас заюзаю?” Ну или скорее “Чет, я где-то слышал, что вот так делают, правда не помню где. Но надо попробовать!”

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

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

🅰️ Итого: Приходите глянуть в 16:00 МСК, у Валеры есть стремительно растущий канал с анонсом предстоящего девфорума и всяким про разработку и жизнь марафонца-футболлиста)))

UPD: полумарафонца-футболлиста!

🧙‍♀️ Импакт от Геншина: Часть 1

Тут у нас в внутреннем канале написали про то как офигенно коллаба c Геншином повлияла на продажи в Турции. Там с Додо Пиццей мало кто знаком, а вот с аниме-дрочильнями знакомы почти все! Но теперь, все со всеми знакомы и повышают продажи додстеров 🎁 (Вдарили аниме-дрочильнями по бездодстерью!)

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

Что мы там вообще сделали

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

1️⃣На время коллабы, каждый день открывается скрытая где-то в интерфейсе приложухи картинка с вот этим чувачком из игры.
2️⃣Игра длится семь дней
3️⃣Первая стока открывших все семь пасхалок за неделю получает охуеннуюю мягкую игрушку

Я такие игры видел на куче сайтов и мне всегда было интересно, как такие штуки реализуют? Как справляются с нагрузкой? Как на бэке там все реализовано?

🐇Оказалось все не так сложно, но есть пара интересных нюансов, которые нужно учитывать при проектировании таких штук:

1️⃣У нас новая доступная для клика пасхалка открывалась каждый день.
2️⃣Игра стартовала каждую неделю в течение четырех недель подряд.
3️⃣Ну и наше любимое – в разных странах свое количество призов и разное количество игровых недель.

👍 Мы сделали три эндпоинта для работы с этой логикой через мобилку:
1️⃣Стартовать игру
2️⃣Получить список доступных пасхалок
3️⃣Открыть пасхалку по которой кликнули.

Был большой соблазн объединить 1 и 3 пункты, ну типа кликнул по пасхалке первый раз – вот и стартовал. Но в итоге оставили их раздельными и это довольно неплохо упростило тестирование. В старте игры были свои корнер кейсы, а в открытии пасхалок свои.

Тут бывалый взгляд наверняка отметит, что "Ну чуваки SRP – понятно, что так нужно было делать сразу!"

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

Это вообще было для меня некоторым открытием после веб-разработки. В вебе тебе добавлять-удалять новые эндпоинты – как два пальца обоссать. Но для мобилок – это боль. Ибо каждая версия приложения живет довольно долго и может еще год-два запрашивать уже давно неиспользуемую логику.

🅰️ Итого Хочется какой-то итог первой части подвести, но для меня он тут в том, что разработка бэка под мобилки может сильно отличаься от разработки бэка под веб. Ибо веб – гибкий, а мобилки супер-неповоротливые. Из-за этого привычные нам принципы разработки могут не подходить под ситуацию и приходится искать компромиссы.

Ой, но вы бы знали, как мы про всю эту хрень спорили, порой просто жесть 🙏

🧙‍♀️ Импакт от Геншина: Часть 2

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

⏳ Когда вы проектируете времязависимую логику, то будет не лишним просовывать в эндпоинты параметр utcNow на время тестирования. То есть возможность передавать текущее время, чтобы можно было эмулироать начало недели, конец недели и разные врменные промежутки.

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

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

🅰️ Кстати, рекомендую во всей времязависимой логике юзать эту штуку!

Юзается просто

public class MyService
{
private readonly TimeProvider _timeProvider;

public MyService(TimeProvider timeProvider)
{
_timeProvider = timeProvider ?? throw new ArgumentNullException(nameof(timeProvider));
}

public DateTimeOffset GetCurrentTime()
{
return _timeProvider.GetUtcNow();
}
}

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

⚔️ Импакт от Геншина: Часть 3

Еще одна вещица, про которую хочу рассказать. Это про то что я наконец пощупал на этом проекте монгу.

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

Представьте себе такой домен, в котором:

1️⃣ Логика и хранимые данные часто меняются – добавляются новые таблицы, в самих структурах могут добавляться новые поля.

2️⃣ К примеру это какие-то временные акции, конкурсы итп.

3️⃣ Хранить такие данные нужно ограниченное время (год-два максимум, но может и больше).

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

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

У нас это реализовано вот как:

🏓 Есть огромная таблица OperationalData. Она хранит в себе вот такой дженериковый тип данных:

public class OperationalData<T>
{
 string ShardKey {get; set;}
 T Payload {get; set;}
 int LifeTime {get; set;}
}

public class PromotionStatus
{
 string UserName {get; set;}
 Promotion CurrentPromotionType {get; set;}
 DateTime NextPromotion {get; set;}
}

public class Discount
{
 Guid Id {get; set;}
 DateTime AvailableFrom {get; set;}
 DateTime AvailableTo {get; set;}
}

И вот в такой приятной хранилке ты можешь делать вот такие штуки:

var userPromotionStatus = db.Collection.Find(x => x.ShardKey == $"PromotionStatus_{UserId}").ToPromotionStatus();

var userDiscount = db.Collection.Find(x => x.ShardKey == $"Discount_{UserId}").ToDiscount();

➕ Если вам нужно добавить новые данные, то никаких проблем, просто добавляете и пишете новые данные! Находтся такой объект супер-быстро. По одному шард-кею вы можете хранить и не только одну запись.

➕ Если нужно добавить новое поле, то просто добавляете его в модель и маппинг. На этом все. Никаких тебе миграций и болей с переписыванием запросов.

➖ Но есть минус, что делать селекты таких данных между пользователями вот так невозможно.

Я это очень удобно заюзал. Правда мне вот это как раз стрельнуло в ногу чутка. 🍌

Посмотрел на эту картинку, и такой: “Да ну!” А потом присмотрелся и осознал, что все-таки, “Ну да”.
Там прям реально все все кейсы прописаны и задачи комьюнити и встречи с другой команды.

Я пол часа пыхтел, пытаясь выдумать кейс, который бы не попадал в эту табличку и потерпел глубочайший крахЪ

Завтра точно буду юзать 🙏

🎱Прыгни с разбега в ObjectPool!

Не так давно прочитал книгу ✅ Высокопроизводительный код на .Net. И теперь осознал, что память не бесконечная и тратится очень быстро с каждым вызовом new. В мученических своих поисках о том как этого всего избегать, наткнулся на прикольный класс ObjectPool.

Идея простая:

1️⃣ Создаете сколько-то пустых объектов в памяти заранее

2️⃣ Потом достаете их, заполняетете нужными данными, юзаете это дельце как не в себя

3️⃣ А в конце просто сбрасываете состояние этого объекта к нулю и потом переиспользуете, если нужно.

Долго думал, как же эту крутотень использовать. И что-то никак не мог найти практического применения. А потом чет поскреб по сусекам и осознал, что в кэшах же!

Для примера. Есть самый простой в реализации кэш со словарем в качестве хранилища:

public class ExpensiveObject
{
    public int Data { get; set; }
    
    public ExpensiveObject()
    {
        Data = new Random().Next();
    }
}

public class SimpleCache
{
    private readonly Dictionary<string, ExpensiveObject> _cache = new Dictionary<string, ExpensiveObject>();

    public ExpensiveObject Get(string key)
    {
        if (!_cache.TryGetValue(key, out var obj))
        {
            // Если объекта по ключу нет, создаём новый
            obj = new ExpensiveObject();
            _cache[key] = obj;
        }
        return obj;
    }
}

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

Поэтому на первый план выходит идея – а что если заранее создать кучу пустых объектов и по очереди их заполнять нужными данными на время использования. Делаем то же самое на ObjectPool.

Сначала добавим немного сервисных штук:

using Microsoft.Extensions.ObjectPool;

public class ExpensiveObject
{
    public int Data { get; set; }
    
    public ExpensiveObject()
    {
        Data = new Random().Next();
    }
    
    // Добавляем метод сброса состояния для нашего класса
    public void Reset()
    {
        Data = 0;
    }
}

// Создаем политику работы с БАССЕЙНОМ для нашего объекта
public class ExpensiveObjectPooledPolicy : PooledObjectPolicy<ExpensiveObject>
{
 // то бишь говорим, как создать
    public override ExpensiveObject Create() => new ExpensiveObject();

 // и как очистить состояние, после того как поюзали
    public override bool Return(ExpensiveObject obj)
    {
        obj.Reset();
        return true;
    }
}

В этой части главное – не забыть модифицировать метод Return(ExpensiveObject obj), если добавили новое поле.

Если все сделали, то потом используем в пулле

using Microsoft.Extensions.ObjectPool;

public class OptimizedCache
{
    private readonly ObjectPool<ExpensiveObject> _objectPool;
    private readonly Dictionary<string, ExpensiveObject> _cache = new Dictionary<string, ExpensiveObject>();

    public OptimizedCache(int maximumRetained = 20)
    {
        var policy = new ExpensiveObjectPooledPolicy();
        _objectPool = new DefaultObjectPool<ExpensiveObject>(policy, maximumRetained);
    }

    public ExpensiveObject Get(string key)
    {
        if (!_cache.TryGetValue(key, out var obj))
        {
            obj = _objectPool.Get();
            _cache[key] = obj;
        }
        return obj;
    }

    // Когда поюзали объект, можем его удалить.
    public void Remove(string key)
    {
        if (_cache.TryGetValue(key, out var obj))
        {
            _cache.Remove(key);
            _objectPool.Return(obj);
        }
    }
}

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

Придется чутка подзаморочитсья. Но идею думаю вы уловили.

🎱 ObjectPool бенчмарки 1

В комментах Валера Никитин @nvikv попросил бенчмарки, я сегодня посидел, помозговал и сделал вот такую штуку:

1️⃣ Делаем запрос

2️⃣ Кладем в кэш значение

3️⃣ “Пользуемся” этим значением

4️⃣ Удаляем из кэша

Сделал два эндпоинта. Один с простым кэшем, один с пулловым, побомбил 💣 это все через k6 примерно 4500 запросов за 20 минуты и вот ожидаемый результат.

В простом кэше managed memory доходила до 84 Мб, потом приходил GC и все собирал. Получилось три сборки мусора за 4500 тысячи запросов

ObjectPool бенчмарки 2

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

То есть 0️⃣ сборок мусора за 4500 запросов против 3️⃣!

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

Вот тут код. Можете посмотреть, как все устроено. Я там для большей показаетльности сделал ExpensiveObject более экспансивным, что он стал весить 80 Кб, и заюзал ConcurrentDictionary чтобы можно было кучу запросов параллельно делать. Но суть примерно та же что и в примере выше.

P.S.: Спасибо большое Валере за идею! Валера получает от меня сотку лайкосов 💯 👍

🥰🧙‍♀️ Импакт от Геншина: Часть ♾

Сегодня 14 февраля. И это традиционный день с повышенной нагрузкой в Додо. Для бизнеса это значит много потраченных клиентами деняк 🪙, а для инженеров – потраченных инженерами НЕРВОВ.

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

Могу вам однозначно сказать, что разрабатывать коллабу для анимешников очень страшно. Я уже писал, что боюсь школьников. Так вот анимешников я боюсь еще больше, чем школьников. А школьников-анимешников боюсь до усрачки.

И не потому, что ощущаю в них социальную неустроенность. А скорее потому, что они дохуя умные и пронырливые. А еще они сплоченые, когда надо. И это тоже пиздец.

🌙 Короче, в сентябре в первый день коллабы, нам в 12 часов ночи (НОЧИ БЛЯТЬ) чуваки устроили пик заказов, какой наша система видала только в самый оживленный день и то в обед!

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

Систему в целом готовили к нагрузкам. Мы вообще много времени на это тратим. Очень много… Но как оказалось недостаточно чтобы сдержать то что шло дальше.

Днем закономерно нам положили систему попытками заказать коллабную пиццу. 📉 Упало все так, что в чувство приводили несколько часов.

🌜 Наша игра запускалась на пару недель позже. И такое ошеломительное фиаско заставляло думать примерно так: “Ну, если они за кусок пластика сделали вот так, то за мягкую игрушку нас порвут. Будут ДДосить сервера, будут искать баги, сто процентов что-то там заинджектят. Короче, нам пиздец!”

Было такое ощущение, как будто ты на экзамен идешь, и перед тобой не сдал самый умный чел на потоке, а ты следующий.

И вот подходит наше время и… За четыре недели ничего такого не случилось и все прошло довольно гладко. Это были нервные 4 недели в которые ничего не произошло.

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

🔥 Блин, а еще не могу не поделиться клевыми валентинками от наших дизайнеров! 🔥🔥🔥🔥

Круто, что у нас чуваки делают смело такие штуки. С кем еще вы можете попердеть на макеты вместе? А вот у нас с дизайнерами можете!

P.S: Мне только мальца странной показалась валентинка, про “Глядя на тебя, мой прод падает”. Даешь стоящий как кол прод! Особенно сегодня это актуально.