🔄 NBomber 6.2.0: фильтрация метрик, OpenTelemetry и улучшенные отчёты

NBomber — это фреймворк для распределённого нагрузочного тестирования в .NET. Вы пишете сценарии на обычном C# или F#, тестируете любые системы независимо от протокола и модели взаимодействия.

Что нового в версии 6.2.0:

Теперь можно фильтровать метрики по имени — полезно, когда у вас десятки показателей. На графике Throughput отображается Fail RPS, так что проблемы видны сразу.

Кластерный режим теперь настраивается через CLI без JSON-конфига. Можно указать целевые сценарии, а группы агентов стали опциональными.

Реализована интеграция с OpenTelemetry — теперь метрики можно отправлять в стандартные системы мониторинга.

➡️ Релиз на GitHub

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#async_news

🙂 Подборка вакансий для шарпистов

C# Developer — удалёнка в Ростиксе.

.NET разработчик — долларовая удалёнка.

Senior Unity Developer Teamlead — до 400 000 ₽ на гибрид в Москву.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

🗑 Soft Delete в базах данных

Многие проекты добавляют в таблицы колонку deleted или archived_at, чтобы не удалять данные окончательно. Звучит удобно: пользователь случайно что-то удалил — можно восстановить. Но на практике это создаёт массу проблем.

Основные проблемы классического подхода

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

Каждый запрос должен фильтровать WHERE archived_at IS NULL. Индексы раздуваются. Миграции данных становятся сложнее — надо ли обрабатывать записи двухлетней давности? Всегда есть риск, что архивные данные случайно попадут туда, где их быть не должно.

Создание записи затрагивает внешние системы. Восстановление может требовать сложной логики, которая всегда будет неполной копией API создания. Старые данные могут не пройти новые правила валидации.

Альтернативные подходы

• Архивирование на уровне приложения

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

Плюсы: основная БД остаётся простой, удаление асинхронное (быстрее и надёжнее), данные можно сериализовать в удобном формате.

Минусы: легко допустить баг и потерять архивные данные, больше инфраструктуры, сложнее искать записи для восстановления.

• Триггеры PostgreSQL

Создаём универсальную таблицу archive, которая хранит JSON-представление удалённых записей:

CREATE TABLE archive (
    id UUID PRIMARY KEY,
    table_name TEXT NOT NULL,
    record_id TEXT NOT NULL,
    data JSONB NOT NULL,
    archived_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);

Триггер автоматически копирует удаляемую строку в архив. Можно даже отслеживать каскадные удаления через session variables.

• Реплика без DELETE

Держать логическую реплику, которая игнорирует DELETE-запросы или превращает их в archived_at.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#il_люминатор

🤓 Группировка данных без лишних действий

ToLookup — это метод LINQ, который группирует элементы коллекции по ключу. Похож на GroupBy, но есть важные отличия, которые делают его удобным в определённых ситуациях.

— Как работает ToLookup

Метод создаёт структуру данных ILookup<TKey, TElement> — это неизменяемая коллекция групп. Каждая группа содержит элементы с одинаковым ключом.

var users = new[]
{
    new { Name = "Anna", Department = "Dev" },
    new { Name = "Boris", Department = "Dev" },
    new { Name = "Clara", Department = "QA" }
};

var lookup = users.ToLookup(u => u.Department);

foreach (var user in lookup["Dev"])
{
    Console.WriteLine(user.Name); // Anna, Boris
}

Обращение к группе происходит через индексатор lookup["Dev"]. Если ключа нет — вернётся пустая последовательность, а не исключение.

— ToLookup vs GroupBy

GroupBy возвращает IEnumerable<IGrouping<TKey, TElement>> — это отложенное выполнение. Группировка происходит при каждой итерации.

ToLookup выполняется немедленно и возвращает готовую структуру в памяти. Это значит:

• Данные группируются один раз при вызове метода
• Повторные обращения к группам не пересчитывают результат
• Потребляет память под всю структуру сразу

— Когда использовать ToLookup

Подходит, если вам нужно:

+ Многократно обращаться к одним и тем же группам
+ Избежать повторных вычислений группировки
+ Получать пустые последовательности вместо исключений для отсутствующих ключей
+ Неизменяемую структуру данных

Не подходит, если:

- Данные большие и в памяти не поместятся
- Нужна отложенная обработка
- Группировка нужна один раз — тогда GroupBy эффективнее

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#sharp_view

Почему так сложно просто принять оплату❓

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#garbage_collector

💡 Старый трюк Windows 95 с Shift

В Windows 95 был странный эффект: если перезагружать систему с зажатым Shift, появлялась надпись «Windows is restarting», и перезапуск занимал заметно меньше времени. Для многих это выглядело как полумистический хак, хотя на самом деле там работала вполне конкретная логика в старом 16-битном коде.

При обычном перезапуске Windows 95 инициировала полноценный холодный ребут — то есть машина проходила полный цикл начальной инициализации BIOS и заново загружала систему с нуля.

При перезапуске с зажатым Shift вместо этого вызывался старый 16-битный ExitWindows со специальным EW-флагом, который говорил ядру не перезагружать железо, а только выгрузить саму Windows и вернуться.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#async_news

👨‍💻 ToLookup для поиска дубликатов

ToLookup — это не только группировка данных. Метод создаёт индексированную структуру, что делает его быстрой альтернативой GroupBy в некоторых сценариях.

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

Стандартный подход через GroupBy:

public static IEnumerable<int> FindDuplicates_GroupBy(List<int> data)
{
    return data.GroupBy(x => x)
               .Where(g => g.Count() > 1)
               .Select(g => g.Key);
}

Работает, но GroupBy выполняется лениво — при каждой итерации происходит перегруппировка.

Решение через ToLookup:

public static IEnumerable<int> FindDuplicates_Lookup(List<int> data)
{
    var lookup = data.ToLookup(x => x);
    return lookup.Where(g => g.Count() > 1)
                 .Select(g => g.Key);
}

ToLookup создаёт индекс сразу и дальнейшие операции работают с готовой структурой в памяти.

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#sharp_view

❓ Что выведет код

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

Посмотреть ответ 👉 в нашем канале

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#dotnet_challenge

📄 Забытое искусство XML

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

XML был отвергнут не из-за технической неполноценности, а потому что победил JavaScript.

Что мы потеряли, отказавшись от XML:

• Схемы и валидация — XSD позволяет проверять типы и структуру данных на уровне документа, до парсинга. JSON Schema существует, но это сторонняя надстройка, которая так и не стала стандартом.

• Пространства имён — можно комбинировать документы из разных схем без конфликтов. В JSON приходится импровизировать с префиксами.

• Комментарии — в XML они есть изначально. JSON их запрещает, потому что они усложняют парсинг.

• Самодокументирование — XML-документ содержит или явно ссылается на свою схему. В JSON приходится гадать, что значит "status": 1.

Вместо того чтобы использовать XML, мы потратили миллиарды на создание библиотек валидации, TypeScript, генераторов API-клиентов — по сути, воссоздавая то, что уже было в XML.

Microsoft, несмотря на все критику, продолжали использовать XML для MSBuild, WPF, и системы конфигурации .NET Framework. Переход на JSON в .NET Core случился не потому что XML был плох, а под давлением модных трендов.

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#il_люминатор

⭐️ Нестандартные форматы резюме для шарписта

Рынок IT вакансий в 2026 году переполнен кандидатами с похожими PDF резюме. Рекрутеры тратят на просмотр отклика секунды, и стандартный формат часто теряется в потоке.

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

➡️ Все 6 форматов в статье

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#garbage_collector

🟥 Новостной дайджест

Выходные выходными, но новости должны быть по расписанию.

— Быстрая загрузка Windows 95

— NBomber 6.2.0

— Ghostty почти запретил ИИ-генерированный код

Разработчик терминала Ghostty Митчелл Хашимото ужесточил правила: теперь любой PR с кодом от ИИ вроде Claude или Cursor требует раскрытия использования модели, полного тестирования человеком и предварительного одобрения issues, а нарушителей грозит бан и публичное осмеивание.

— Microsoft выпустили WinApp

Новый открытый инструмент WinApp CLI упрощает жизнь разработчикам на кросс-платформенных фреймворках вроде Electron, Rust или Dart, избавляя от ручной настройки SDK, манифестов, сертификатов и упаковки в MSIX.

— Chrome в Windows 11 скоро позволит перетаскивать несколько файлов из веб-приложений в Проводник

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#async_news

⚡️ Урок про боксинг в C#

Разбираем типичную ошибку, которая встречается даже в коде крупных проектов.

Код с подвохом:

struct StackValue
{
  public override bool Equals(object obj)
  {
    if (Object.ReferenceEquals(this, obj))
      return true;

    if (!(obj is StackValue))
      return false;

    var value = (StackValue)obj;
    return this.Kind == value.Kind 
        && this.Flags == value.Flags 
        && this.Type == value.Type;
  }
}

На первый взгляд всё логично: сначала быстрая проверка через ReferenceEquals, если не сработала — сравниваем по полям.

В чём подвох

ReferenceEquals принимает параметры типа object. Когда вы передаёте структуру, происходит боксинг: значение копируется в хип и оборачивается объектом.

Что происходит при вызове Equals:

• this упаковывается в новый объект
• Создаётся уникальная ссылка в heap
• Сравниваются две разные ссылки
• Результат всегда false

В современных версиях .NET есть правило CA2013, которое отлавливает подобные случаи.

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#il_люминатор

👨‍💻 Паттерны проектирования — не для облачных систем

Классические design patterns из Банды четырёх часто вредят cloud-native приложениям.

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

Но в 2026 году всё ещё встречаются облачные системы, построенные на репозиториях повсюду, синглтонах как кеше и фасаде, оборачивающем HTTP-вызовы.

Классические паттерны из книги Банды Четырёх предполагают общую память, быстрые вызовы методов, стабильные процессы, редкие сбои и единый блок развёртывания. Облачные системы предполагают противоположное: распределённую память, сетевые вызовы с задержками, временные процессы, постоянные частичные сбои и множество независимых сервисов.

Синглтон: самый опасный паттерн

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

Репозиторий тормозит запросы

Репозиторий абстрагирует данные, чтобы домен оставался чистым. В распределённых системах это плодит лишние вызовы через сеть, N+1 проблемы и перерасход ресурсов БД. Каждый запрос добавляет задержку и траты.

Лучше ориентироваться на запросы: оптимизировать чтение, использовать CQRS для доминирующего чтения и принимать форму данных как часть дизайна. Доступ к БД становится ключевой частью архитектуры, а не скрытой деталью.

Фабрика усложняет жизнь

Фабрики прячут создание объектов и типы. В облаке они дублируют DI-контейнеры, маскируют жизненный цикл и ломают трассировку. Если код полон фабрик, локаторов и инъекций, ясность теряется.

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

Обдумывайте контекст перед копипастой паттернов. Это спасёт от боли при росте нагрузки.

💬 Был у вас шаблон, который подставил вас в облаке?

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#sharp_view