Библиотека шарписта | C#, F#, .NET, ASP.NET

🤓 Группировка данных без лишних действий 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

🗑 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_люминатор

🙂 Подборка вакансий для шарпистов C# Developer — удалёнка в Ростиксе. .NET разработчик — долларовая удалёнка. Senior Unity Developer Teamlead — до 400 000 ₽ на гибрид в Москву. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта

Интеграция LLM в .NET: подходы RAG и Fine-tuning 23 января в 19:00 обсудим создание интеллектуальных ассистентов на открытом уроке к курсу «Разработка ИИ агентов». Разберём, как реализовать контекстный поиск по вашим документам и когда стоит прибегать к дообучению моделей. Спикер — Игорь Стурейко, тимлид в «Газпроме» и эксперт с 20-летним опытом в ML. Игорь подготовил видеосообщение, в котором рассказывает о переходе от чат-ботов к автономным агентам и архитектуре будущей программы. Ключевые темы: — использование RAG для ответов по внутренней документации; — фреймворки уровня LangChain и LlamaIndex в Enterprise-среде; — работа с хранилищами векторных эмбеддингов (FAISS, Chroma). 📅 Когда: 23.01 в 19:00 МСК Узнать подробности

🔄 NBomber 6.2.0: фильтрация метрик, OpenTelemetry и улучшенные отчёты NBomber — это фреймворк для распределённого нагрузочного тестирования в .NET. Вы пишете сценарии на обычном C# или F#, тестируете любые системы независимо от протокола и модели взаимодействия. Что нового в версии 6.2.0: Теперь можно фильтровать метрики по имени — полезно, когда у вас десятки показателей. На графике Throughput отображается Fail RPS, так что проблемы видны сразу. Кластерный режим теперь настраивается через CLI без JSON-конфига. Можно указать целевые сценарии, а группы агентов стали опциональными. Реализована интеграция с OpenTelemetry — теперь метрики можно отправлять в стандартные системы мониторинга. ➡️ Релиз на GitHub 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #async_news

🧬 Мутационное тестирование Вы пишете unit-тесты, coverage показывает 80-90%, но уверены ли вы, что эти тесты реально ловят баги? Мутационное тестирование помогает проверить качество самих тестов. Суть подхода Инструмент автоматически вносит небольшие изменения в ваш код: меняет операторы, условия, константы. Если тесты проходят с «поломанным» кодом — значит, они недостаточно строгие. Stryker.NET в действии Установка занимает пару минут через dotnet tool. После запуска Stryker анализирует код, создаёт мутантов и прогоняет по ним тесты. В отчёте вы видите: • Какие мутации выжили • Mutation Score — процент убитых мутантов • Конкретные строки кода, где тесты слабые Практический пример Допустим, у вас метод проверяет возраст пользователя. Stryker меняет age >= 18 на age > 18. Если тест с граничным значением 18 отсутствует — мутант выживает, и вы понимаете, где дописать проверку. Stryker умеет работать с xUnit, NUnit, MSTest. Настраивается через JSON-файл, где можно указать пороговые значения mutation score, исключить файлы из анализа, настроить уровни логирования. Процесс требует времени — каждая мутация прогоняет весь набор тестов. Но результат того стоит: вы находите слепые зоны в тестовом покрытии, которые обычный coverage не показывает. ➡️ Репозиторий 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #il_люминатор

📎 Преобразование Excel в JSON Сделаем минимальный код для чтения таблиц для конвертации в JSON. Подключите NuGet-пакеты FreeSpire.XLS и Newtonsoft.Json. Первая читает .xlsx без зависимостей, вторая формирует JSON. Код начинается с загрузки файла в поток. Библиотека преобразует лист в DataSet, где строки становятся объектами. Первая строка служит заголовками полей. Чтение и конвертация данных:

using Spire.Xls;
using Newtonsoft.Json;

Workbook wb = new Workbook();
wb.LoadFromFile("данные.xlsx");
DataTable таблица = wb.Worksheets.ExportDataTable();

JsonSerializerSettings опции = new JsonSerializerSettings
{
Formatting = Formatting.Indented,
NullValueHandling = NullValueHandling.Ignore
};

string результат = JsonConvert.SerializeObject(таблица, опции);
File.WriteAllText("выход.json", результат);

Игнорируйте null для компактности. Форматируйте даты единообразно. Тестируйте на реальных данных — библиотека FreeSpire.XLS ограничена объемом, но достаточна для большинства случаев. 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #sharp_view

👍 JIT .NET 10 убирает абстракции почти бесплатно В .NET 10 Microsoft сильно доработали JIT компилятор. Цель простая сделать так, чтобы привычный высокоуровневый С# код работал почти как вручную вылизанный низкоуровневый. Главная идея обновления JIT убрать лишнюю цену за высокоуровневые конструкции. Раньше интерфейсы, делегаты, итераторы легко приносили дополнительные аллокации и лишнюю индирекцию, сейчас JIT старается пробиться сквозь них к конкретным типам и генерировать более плотный машинный код. Ключевой механизм это улучшенный escape analysis. Если JIT может доказать, что объект живет только внутри метода не передается наружу и не сохраняется в поля, он размещает его на стеке. Пример:

[Benchmark]
[Arguments(42)]
public int SumWithOffset(int offset)
{
    Func<int, int> addOffset = value => value + offset;
    return ApplyTwice(addOffset, offset);
}

В старой версии платформы такой код почти гарантировал лишнюю аллокацию делегата и замыкания в куче. По сути JIT делает за разработчика ту оптимизацию которую раньше приходилось реализовывать вручную через отказ от лямбд и делегатов на горячем пути. 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #il_люминатор

🛠 Parallel.For — когда циклы работают параллельно Представьте: у вас есть массив из миллиона элементов, и каждый нужно обработать. Обычный цикл for будет делать это последовательно — один элемент за другим. А что если задействовать все ядра процессора? Базовое использование:

// Было
for (int i = 0; i < 1000; i++)
{
    ProcessImage(images[i]);
}

// Стало
Parallel.For(0, 1000, i =>
{
    ProcessImage(images[i]);
});

Вот и всё. Task Parallel Library сам распределит работу по потокам, сам управляет ThreadPool, сам балансирует нагрузку. Когда это имеет смысл: + Обработка изображений, видео + Математические вычисления + Парсинг больших объёмов данных + Криптографические операции Не подходит: - Обработка меньше 100 элементов - Операции с базой данных или API - Быстрые операции вроде i * 2 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #sharp_view

🚀 Одна строка кода для ускорения EF Core Когда EF Core загружает связанные сущности через Include(), он генерирует один огромный SQL-запрос с множеством JOIN. Результат? Тысячи дублирующихся строк, гигабайты трафика и медленная работа. Пример:

var posts = await context.Posts
    .Include(p => p.Comments)
        .ThenInclude(c => c.Reactions)
    .ToListAsync();

При 100 постах, у каждого по 10 комментариев, в каждом по 10 реакций — вместо 11 100 записей получаем результирующий набор на 10 000 строк. Добавьте .AsSplitQuery() — и EF Core разобьёт один большой запрос на несколько маленьких:

var posts = await context.Posts
    .AsSplitQuery() // ← магия здесь
    .Include(p => p.Comments)
        .ThenInclude(c => c.Reactions)
    .ToListAsync();

Query Splitting — это не хак и не костыль. Это правильный способ работы с EF Core в read-heavy сценариях. 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #il_люминатор

public const Price = OldPrice; // до 20.01 Мы меняем значение константы: завтра обучение станет дороже. Успейте пробросить заказ сегодня, чтобы зафиксировать текущую стоимость в своём стеке. Инициализировать рост компетенций

📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #garbage_collector

👼 Дайджест первой недели Прошла первая рабочая неделя 2026 года. Собираем яркие материалы и новости в один пост. — Microsoft показали как делать виджеты — Удаляем хлам из браузера — Новая база корпоративной культуры — Январские обновления .NET — Скоро будет домен .meow 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #async_news

🧑‍💻 Исключения — не для обычного управления потоком Исключения во флоу — это не просто дорогие операции. Они дороги когнитивно: затуманивают логику программы и размывают границу между ошибкой и нормальным поведением. Антипаттерн, который всё ещё встречается:

{
    var value = dictionary[key];
    Process(value);
}
catch (KeyNotFoundException)
{
    // ignore
}

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

if (dictionary.TryGetValue(key, out var value))
{
    Process(value);
}

Этот код читается понятно, работает быстрее и сохраняет исключения значимыми. 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #sharp_view

🔄 .NET: январские обновления Microsoft выпустила очередную порцию сервисных обновлений для платформы .NET. Вышли новые версии для трёх поддерживаемых веток: .NET 10.0.2 — самая свежая версия платформы .NET 9.0.12 — актуальная LTS-версия .NET 8.0.23 — предыдущая LTS-версия ➡️ Блог разработчиков 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #async_news

👨‍💻 Когда if начинает распухать Паттерн стратегия подходит, когда один и тот же сценарий можно выполнить несколькими способами, и выбор зависит от условий. Вместо большого switch внутри сервиса разные варианты выносятся в отдельные классы с общим интерфейсом, а контекст просто делегирует работу выбранной реализации. Типовая схема такая. Есть интерфейс Strategy, есть несколько конкретных стратегий, и есть контекст, который держит ссылку на стратегию и вызывает ее метод, не зная деталей реализации. Это снижает связность и позволяет добавлять новые варианты без переписывания старого кода. Мини пример на C#:

public interface IDiscountStrategy
{
    decimal Apply(decimal total);
}

public sealed class RegularDiscount : IDiscountStrategy
{
    public decimal Apply(decimal total) => total;
}

public sealed class VipDiscount : IDiscountStrategy
{
    public decimal Apply(decimal total) => total * 0.9m;
}

public sealed class Checkout
{
    private readonly IDiscountStrategy _discount;

    public Checkout(IDiscountStrategy discount) => _discount = discount;

    public decimal TotalWithDiscount(decimal total) => _discount.Apply(total);
}

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

var checkout = serviceProvider.GetRequiredService<Checkout>();
var total = checkout.TotalWithDiscount(100m);

Выбор стратегии лучше делать на границе приложения, например в фабрике или при конфигурации через DI, потому что прямое создание зависимостей внутри сервиса жестко привязывает код к конкретной реализации. 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #sharp_view

«Этот манёвр будет стоить нам 51 год...» Для .NET разработчика архитектура и алгоритмы — это база. Если вы хотите проектировать сложные системы или внедрять ИИ в свои энтерпрайз-решения, сейчас лучший момент для старта. В Proglib Academy поднимаются цены. Успейте забрать курс по старой стоимости: — Разработка ИИ-агентов — Математика для разработки AI-моделей — ML для старта в Data Science — Математика для Data Science — Специалист по ИИ — Алгоритмы и структуры данных — Программирование на Python — Основы IT для непрограммистов — Архитектуры и шаблоны проектирования Забрать по старой цене ⚠️ Повышение уже 19 января

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

var allItems = orders
    .SelectMany(o => o.Items)
    .Where(i => i.IsActive)
    .ToList();

Цикл часто дает больше ясности и предсказуемости:

var allItems = new List<Item>();

foreach (var order in orders)
{
    foreach (var item in order.Items)
    {
        if (!item.IsActive)
            continue;
        allItems.Add(item);
    }
}

Плюс тут легко вставить break, continue, счетчики, ограничения, и не гадать как они сложатся с отложенным выполнением. 📍 Навигация: Вакансии • Задачи • Собесы 🐸Библиотека шарписта #sharp_view