C# Short Posts 🔞

😋 Кормим .NET мусором — GCServer налил, DATAS отжал

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

На первом снепшоте памяти у нас всего три большие кучи. А на втором уже целая толпа — 12 мини-подкуч, по числу ядер процессора, и так для каждого поколения.

Я раньше думал, что это включено по умолчанию, но оказалось, что нет.

Звучит, конечно, многообещающе — теперь вашу кучу разгребает не один поток, а сразу несколько.

Что получилось по метрикам:

1️⃣ 🔽После включения DOTNET_GC_SERVER = 1 память ожидаемо выросла. И выросла прилично — примерно раза в два.

2️⃣ 🔼 Но зато количество сборок мусора сильно сократилось.

Вы, наверное, хотите узнать, как изменились метрики запросов? А вот тут изменений почти нет. Основная нагрузка у меня упирается в базу данных, поэтому по метрикам запросов разницы практически не видно.

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

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

Все контроллеры отвечают двумя наборами данных:

[SubscriptionFilter("Premium")]
[HttpGet("data")]
public IActionResult GetData()
{
    var baseData = GetBaseData();
    var premiumData = GetPremiumData();
    return Ok(new { Base = baseData, Premium = premiumData });
}

На постобработке убираем лишнее после проверки подписки:

public class SubscriptionFilterAttribute : ResultFilterAttribute
{
    private readonly string _requiredLevel;

public SubscriptionFilterAttribute(string requiredLevel)
    {
        _requiredLevel = requiredLevel;
    }

    public override void OnActionExecuted(ActionExecutedContext context)
    {
        var user = context.HttpContext.User;
        if (user.HasSubscription)
        {
            return context.Result;
        }
        else
        {
            return new { Base = context.Result.Base };
        }
    }
}

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

Можно ещё скомбинировать подход – сделать предфильтр, который поймёт, нужно ли применять поиск по премиум-функциям, а потом постфильтр. А сам хэндлер, который всё это будет обрабатывать, обозначить IPremiumFunctionHandler, который будет заставлять реализовывать два разных варианта работы.

Поначалу я, конечно, это всё сделаю попроще на ифчиках. Но, короче, хотел поделиться, вдруг тут есть кто решал похожую проблему и знает, что да как)

Так вот, прилетела задачка – сделать для базы знаний подписочную модель.

В Додо это первый случай, когда мы продаём часть системы как услугу для франчайзи. Стоимость Додо ИС входит в роялти. Но тут как бы мы продаём допфункции в приложении, которые не часть кор-функционала. Так что можно накрутить подписку.

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

Посему встала задача написать какой-то удобный код, который бы проверял подписку и включал/отключал функционал в зависимости от состояния подписки.

Для себя выделил два типа проблемы, которые нужно решить:

1️⃣ Доступ к определённым функциям по подписке. Если подписка есть — то можно дёрнуть эндпоинт, а если нет, то дёргать нельзя.

2️⃣ Модификация какой-то функции в зависимости от состояния подписки. К примеру, если подписка есть, то возвращаем один список сущностей, а если нет, то обрезанный вариант.

С первым флоу всё просто.

Пишем атрибут и миддлварь, которые делают что-то такое:

public class SubscriptionRequirementAttribute : Attribute, IAuthorizationFilter
{
    private readonly string _requiredLevel;

    public SubscriptionRequirementAttribute(string requiredLevel)
    {
        _requiredLevel = requiredLevel;
    }

    public void OnAuthorization(AuthorizationFilterContext context)
    {
        var user = context.HttpContext.User;
        var hasSubscription = user.HasClaim("SubscriptionLevel", _requiredLevel);

        if (!hasSubscription)
        {
            context.Result = new ForbidResult();
        }
    }
}

[SubscriptionRequirement("Premium")]
public IActionResult GetPremiumContent()
{
    // Доступно только для пользователей с подпиской "Premium"
}

И вуаля. Всё закрыто.

А вот со вторым я пока что размышляю, ибо тут есть несколько вариантов:

Во-первых, всё можно просто заифать. Типа прям в коде юзкейса как-то так:

[HttpGet("data")]
public IActionResult GetData()
{
    var baseData = GetBaseData();

    if (_subscriptionService.HasSubscription("Premium"))
    {
        var premiumData = GetPremiumData();
        return Ok(new { Base = baseData, Premium = premiumData });
    }

    return Ok(new { Base = baseData });
}

Ну или сделать какой-то fabric, который выдаёт нужный функционал. Но это уже сорта одного и того же ифинга.

⭐️ Подписки мои подписки

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

Я сейчас делаю базу знаний — это такая внутренняя википедия для сотрудников пиццерий.

С одной стороны, штука вспомогательная (денег напрямую не генерит), с другой стороны, охуенно важная.

Ибо сердце качества продукции — это стандарты. А стандарты — это, по сути, обучение сотрудников тому, как делать свою работу хорошо и как не делать её плохо.

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

Короче, знания — это база!

Я не знал, но вот знаю
Сидристый выпустил свою книгу о там как работает dotnet
Если cli via c# это взгляд снаружи, то .net platform architecture это взгляд изнутри (и актуальный)

Читать бесплатно прям на его гитхаб

Эта книга задумана мной как максимально полное описание работы .NET CLR, и частично - .NET Framework и призвана в первую очередь заставить посмотреть читателя на его внутреннюю структуру под несколько другим углом: не так, как это делается обычно.

О, это очень круто! Я вроде краем сознания слышал про эту книгу, но значения не придавал.

Вообще у Станислава Сидристого супер-крутые доклады про .NET. Из последнего, что я смотрел на ютьюбе lock(_sync): иллюзия идеального выбора.

Звучит сложно, но на деле рассказано просто. Мне конечно кажется, что можно еще проще) Но я на удивление понял примерно все. Короче, доклад горячо рекомендую, а книгу думаю в ближайшее время попробую осилить!

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

🔜 Последнюю неделю потею над докладом на DotNext.

На всякий случай – это такая охренительно крупная конфа по .NET. (на момент написания поста сайт правда лежит 👋 )

Готовлю спидран по куберу. Очень хочу сделать такое выступление, после которого любой джун/миддл (да и синьор) начнут играться с кубером, как с конструктором лего. 🥇 Поэтому над каждым слайдиком и анимацией сижу, как ОРЛИЦА НАД ОРЛЕНКОМ – выверяю, где картинка помогает восприятию, а где тормозит. Где стоит вставить шуточку, чтобы всех взбодрить, а где наоборот это только отвлечет от сути.

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

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

(по традиции пояснительный дикпик прилагается)

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

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

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

💰 Затащил чаевые для курьеров во всех странах

Вот уже месяц работаю в новой команде – делаю базу знаний (эдакий внутренний Notion/Confluence для сотрудников). Состоялось возвращение в родное b2b, где у нас пилят крутотень для ребят и девчат в пиццерии.

За полтора года в b2c попробовал и менеджерить и разрабатывать бэк (один только курьер на карте чего стоит!) под мобилки и позапускать под дебагом код наших Android и iOS приложений. Короче, кажется было вообще все, что только можно!

b2c у нас очень сильно отличается от b2b по вайбу. Это заметно даже по организации процессов. Вокруг релиз-трейнов мобилки выстроена вся логика производства фич:

1️⃣ Постоянно шуршишь, стараешься затащить фичу в срок, потому что иначе поедет она аж через месяц. И все это время не будет собираться обратная связь, нарабатываться опыт, пользователи не получат свои крутые аватарки, а бизнес не получит деняк.

2️⃣ От этого ищешь компромиссы – где расположить логику, на бэке или на платформе?

3️⃣ Иногда логику проще положить как можно ближе к клиенту. Так как только на клиенте мы владеем наиболее актуально инфрмацией, куда пользователь кликнул, что обновил, куда смахнул и так далее. Но тогда цена ошибки выше – откат релиза на мобилке будет стоить дороже обычного передплоя. Иногда все ровно наоборот, нужно класть логику на бэк, так как если платформы разъедутся, то будет неприятно. А иногда что-то вообще нужно класть только на бэк, так как в таком случае вы сможете это все быстро помнять и настроить.

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


Короче, все было интересно и круто! 🐸 Но в душе я так и остался b2b-чуваком, которому в кайф делать штуки для наших чуваков и чувих в пиццерии 🐸. И поэтому моя любимая фича за все это время, которую я делал – это чаевые для курьеров! 💰💰💰

Они у нас уже были и работали исправно, но доступны были только в России. Моя же задачка была – дать возможность оставлять чаевые и в других странах. И вот на той неделе я впервые оставил чаевые в Грузии! (Пояснительный дикпик в пруфы)

Когда только пришел в Додо видел, как один крутой разработчик Женя Биккинин делал эту фичу. И я тогда думал, что “Ну нихрена себе чувак тащит в солянову фичу, которая принесет деняк чувакам, которые везут людям пиццу и в лютый мороз и в палящую жару и даже в комфортную для прогулки погоду! Крутой. Хочу быть как он!”

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

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

https://github.com/Undermove/SimpleMemorySaveToolsExamples/tree/main

Все, заканчиваю спамить 😎

Фффух, затащил ебейший доклад. 🗿

От железа до самой кучи и стека. На пальцах! С картинками! А потом с примером кода.

Две недели читал книги, писал демо-код, и рисовал слайды, как гребаный Уолт Дисней свою Белоснежку и каждого из семи гномов,

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

Но ничо – больше докладов – больше контента.

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

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

Вот доклад

Посмотрите, прокомментируйте, пошарьте. Это наверное самый быстрый спидран по памяти ever. Если найдете быстрее – дайте знать.

А я пойду трогать траву 🌱

🆘️️️️️️ Детективная загадка на субботу с неожиданным финалом: Что будет с адресами в памяти?

Короче, пиздец, чуваки, готовлюсь занять нишу Сидристого для малышей! 🤰

Делаю доклад для самых маленьких про память в дотнете (по карйней мере моя задумка сделать так, чтобы понял ну прям ваще максимально зеленый юнит) и дошел вот до такого примера:

int varInStack = 123456789;
int[] varInHeap = new int[1];
varInHeap[0] = 42;

unsafe
{
    int* p = &varInStack;
    Console.WriteLine(
  $"Address of varInStack: 
0x{(long)p:X}");

    fixed (int* q = varInHeap)
    {
        Console.WriteLine(
  $"Address of varInHeap : 
0x{(long)q:X}");
    }
}

Не пугайтесь ансейфа и фикседа – тут просто выводится адрес в памяти для переменной в стеке и для переменной в куче.

❓ Вопрос: При каждом запуске программы выводимые адреса будут одни и те же, или будут меняться каждый раз?

Короче, я сразу в комментариях ответ напишу

🅰️ 🦆 Практика ADR

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

И это не моя прихоть – движок (meilisearch) закрывает эндпоинт metrics авторизацией и у нашей инфраструктуры пока что нет инструментов подпихивать в сборщики auth-токены для такого дела.

😠 Проблема
Если делаешь вынужденное ебанутое решение, то через годы забываешь, зачем вообще ты такое делал. И когда тебя спрашивают, то потупленно смотришь на свои тапочки и думаешь что-то вроде “Так, а и правда, зачем?”

Потом конечно вспоминаешь, но все же.

Так вот от такой штуки может спасти практика ведения Arhitecture Deceision Records или ADR

🤓 Решение
Короткая записка в папочке adr и в формате md (к примеру adr/adr-002.md в пояснительном дикпике выше показано как это выглядит) спасет вас от любой напасти!

Я про эту практику слышал лет пять назад, но внедрять не приходилось. А тут говорили вчера с нашим ЕМом Женей Васильевым и он вот предложил вести. А я быстро согласился и уже сегодня мне эта штука пригодилась!

Формат очень простой вот шаблончик:

# Заголовок:
Название документа должно быть короткой именной фразой, например, «Развертывание на Ruby on Rails 3.0.10» или «LDAP для многопользовательской интеграции».

## Контекст:
Этот раздел описывает действующие силы (технологические, политические, социальные и локальные для проекта), которые, вероятно, находятся в противоречии друг с другом. Язык должен быть нейтральным, просто описывая факты.

## Решение:
Здесь описывается наш ответ на перечисленные силы, излагаемый полными предложениями в активном залоге («Мы будем …»).

## Статус:
Решение может быть в статусе:
1. Предложено – если ещё не согласовано всеми заинтересованными сторонами
2. Принято – когда оно согласовано
3. Устарело – если позднее ADR изменяет или отменяет решение
4. Заменено – с указанием ссылки на новое решение

## Последствия:
В этом разделе описывается итоговый контекст после принятия решения. Здесь должны быть перечислены все последствия – положительные, отрицательные и нейтральные, так как они влияют на будущую работу команды и проекта.

🅰️ Итого: Если приходится делать ебанутые вещи, то попробуйте залогировать это в вышеприведенном формате. Быстро и потом голова болеть не будет у того, кто все это будет поддерживать. Ну точнее болеть будет, но вас он уже не сможет наругать.

И кстати, это вообще универсальный метод и мобильщикам подойдет! 📞

Оффтоп: Кстати, посмотрите офигенный доклад Жени про Тестирование сервиса через API. Давно считаю эту практику одной из мастхэвных и мне кажется, что она есть уже у всех. Но если у вас нет, то вам точно будет полезно!

🧛 DNS записи и что они делают в тени: Тулинг

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

Поэтому вот моя шпора про то как проверить свой DNS после настройки:

🅰️ Как Проверить A-запись

nslookup superstas93.com

- должен выдать айпишник вашего сервиса

Проверить CNAME-запись

dig www.superstas93.com CNAME +short

– если все зарегано праваильно, то выдаст superstas93.com

Если какие-то записи не появляются, стоит подождать (обычно до 24 часов, но чаще 5-10 минут) или очистить DNS-кэш:

Кажется, что это популярные команды, но все же, пусть будут)

Для Linux

sudo systemctl restart systemd-resolved 

Для Windows

ipconfig /flushdns

🧛 DNS записи и что они делают в тени. Как все это работает внутри?

Короче, я если честно когда-то давно прочитал книгу Танненбаума про сети и там вроде все было понятно. Мы идем сначала в одну табличку, потом в другую, потом в третью, потом в четвертую. Ну и как-то получаем свой IP.

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

Я попробовал это записать в виде, ну не то чтобы но типа сиквенс-диаграмы (по скидке)

Итак, вы заходите на superstas93.com у вас есть

🅰️ ваш компьютер
📍 роутер
🚰 оператор СтримОнлайн
А также куча DNS серверов: Root, TopLevelDomain (TLD), NameServers(NS)

Процесс:

1️⃣ Компьютер «Привет, Роутер! Какой DNS-сервер мне использовать?» → Роутер «Используй DNS-сервер 217.69.144.60.»

2️⃣ Компьютер «Какой IP-адрес соответствует superstas93.com?» → DNS-сервер провайдера «сейчас посмотрю»

3️⃣ DNS-сервер провайдера «К какому TLD-серверу обратиться для домена .com» → Root DNS-сервер «вот адрес TLD-сервера, ответственного за домены .com например 198.41.0.4»

4️⃣ DNS-сервер провайдера «Какой авторитетный DNS-сервер отвечает за домен superstas93.com?» → TLD-сервер .com «сейчас посмотрю свои NS записи, вот адрес NS-сервера для superstas93.com 117.69.0.4»

5️⃣ DNS-сервер провайдера «Какой IP-адрес соответствует superstas93.com?» → NS-сервер superstas93.com «сейчас посмотрю свои A записи, вот адрес NS-сервера для superstas93.com 192.0.2.1»

6️⃣ DNS-сервер провайдера «superstas93.com соответствует IP-адресу 192.0.2.1.» → Компьютер «спасибо DNS-сервер провайдера, ты настоящий друг!»

😭 DNS-сервер провайдера - я не настоящий

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

⏲ TTL
Что плохо – на каждом шаге может быть кэш. И если вы поменяли сервер и запись в кэше живет достаточно долго, то изменения вы увидите не скоро. Это может быть критично, особенно, если у вас резко поменялся адрес сервера, а клиенты еще сутки будут стучаться на старый адрес. Выглядеть это будет так что ваш сервер не работает. А он работает, просто он работает там, куда никто не приходит 🗑

Что хорошо – мы все же можем сами рулить временем кэша и задавать TTL в секундах. Вот список ориентировочного времени жизни для записи в DNS

300 секунд = 5 минут = «Очень короткое»
3600 секунд = 1 час = «Короткое»
86 400 секунд = 24 часа = «Длинное»
604 800 секунд = 7 дней = «Абсолютный максимум»
Отсюда спизжено

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

Время тестирования правда уже прошло, но это уже другой вопрос.

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

🧛 DNS записи и что они делают в тени. Прикладная часть
Спасибо ребята, за классные комменты 1 и 2 к прошлому посту! Кажется, есть вариант еще покомментировать, потому что я разобрался с тем
как добавить субдомен? 🏗 🐸

К примеру хотим сделать development.superstas93.com. в дополнение к продовому стасу93

Что приятно – денег платить не нужно 🛍

Тут есть два варианта:

1️⃣ Вы хотите перевести запросы на новый сервак.
Добавляем A-запись:

development.superstas93.com.  IN A  192.0.2.100

Теперь запросы к development.superstas93.com пойдут на этот IP.

2️⃣ Вы хотите перевести запросы на тот же сервер

Используем CNAME:

 
development.superstas93.com.  IN CNAME  superstas93.com.

Теперь development.superstas93.com автоматически указывает на IP-адрес основного домена.

Я еще сделал себе короткую памятку, как внутри работает DNS резолв, но она все равно получилась длинной… 📏

💃️️ Всех с днем борьбы за права женщин!

В этот день просто хочу напомнить, что разрыв в оплате труда между мужчинами и женщинами составляет в среднем >30%

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

Короче – это неравенство. А 8 марта, как праздник, придуман не для того, чтобы подарить тюльпанов, а для того чтобы неравенство убирать. Тюлпанчики тоже ничо так, но ИМХО хорошая зарплата будет получше 🐸

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

А еще подблагодарю каждую компанию, где это неравенство полностью побеждено! Вы действительно делаете мир лучше ❤️

Всех с праздником!

🧛 DNS записи и что они делают в тени

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

Может и вам будет полезно.

Буду идти не от типа записи, а от юзкейсов:
К примеру вы купили домен superstas93.com (кстати, пока не занят, так что торопитесь)

Какой минимальный набор записей нам нужно создать:

1. NS (Name Server) – Самая важная запись

👉 Указывает, какие серверы хранят DNS-записи домена.
⛔ Ручками не создаём — их задаёт регистратор.
Но знать, что есть такая штука важно.
📌 Пример:
superstas93.com. IN NS ns1.dnsprovider.com.

2. A (Address) – Вторая самая важная запись

👉 Указывает IP-адрес, на который ведёт домен (IPv4).
📌 Пример:
superstas93.com. IN A 192.0.2.1

3. AAAA (IPv6 Address) – Это уже не обязательная запись, но очень желательная

👉 То же самое, но для IPv6.
📌 Пример:
superstas93.com. IN AAAA 2001:db8::1

4. CNAME (Canonical Name) – Эта запись не обязательная, но есть НО

👉 Псевдоним, который указывает на другой домен.
📌 Пример (редирект с www на основной домен.

⚠️ ВАЖНО: CNAME нужен, если кто-то остался в 2007ом и до сих пор начинает вводить название сайта с www

www.superstas93.com. IN CNAME superstas93.

P.S.: Есть еще одна важная запись – CAA, но она в резолве не участвует, поэтому про нее отдельно.
P.P.S.: Всего типов записей 15 штук (включая обсолетные и экспериментальные) – можно глянуть их тут

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

Будет смешно, если и тут каким-то образом победит Анора

🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸
Миллион лайков и благодарностей от меня всем, кто поучаствовал в этом невероятном демократическом процессе! 💗
🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸🐸