C# (C Sharp) programming

🚀 Git Pro совет

Хотите быстро узнать, какие файлы менялись чаще всего в репозитории?
Используйте встроенные возможности git log:

# Топ-10 самых часто меняемых файлов
git log --pretty=format: --name-only | \
  sort | uniq -c | sort -nr | head -10

💡 Отличный способ найти "проблемные" файлы:
именно они чаще всего требуют правок и могут быть источником багов.

📝 TodoList gRPC: Упрощённый бэкенд для собеседований

Этот репозиторий представляет собой облегчённый форк проекта, созданного для проверки навыков кандидатов на собеседованиях. Он предоставляет чистый и компактный бэкенд на основе gRPC и ASP.NET, который используется для создания простого фронтенда, взаимодействующего с API.

🚀 Основные моменты:
- Легковесный бэкенд на C# и ASP.NET Core.
- Использует gRPC для взаимодействия с фронтендом.
- Поддерживает различные клиентские фреймворки.
- Идеален для технических собеседований и оценки навыков.

📌 GitHub: https://github.com/Steffen70/todolist-grpc

@csharp_ci

Serilog.Sinks.XUnit3 👩‍💻

Пришло время рассказывать про свои библиотеки!

Если вы пишете тесты на xUnit.v3 и логгируете через Serilog, то моё решение для вас!

Каждый на работе сталкивался с непонятным багом. Смотришь в код и видишь фигу)

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

Логгирование призвано помочь разрабу справиться со страданиями, но вот незадача! При запуске интеграционного теста с воспроизведением бага логи никуда не выводятся.

Поэтому я написал Serilog.Sinks.XUnit3!
Чтобы не выходя из IDE разработчик понимал, что происходит!

Призываю вас делится этой библиотекой и внедрять в свои тесты!

👩‍💻 GitHub: https://github.com/Stepami/serilog-sinks-xunit-v3
👩‍💻 NuGet: https://www.nuget.org/packages/Serilog.Sinks.XUnit3

🚫 EF Core + «репозитории» = лишний слой

Часто советуют заворачивать EF Core в Repository Pattern.
Но на практике это делает код только сложнее:

- DbContext уже реализует Repository и Unit of Work
- Репозитории со временем превращаются в «монстров» с десятками методов
- Каждый новый фильтр = новая копипаста

В итоге — абстракция над абстракцией и трудности с поддержкой.

---

✅ Что вместо этого? Specification Pattern

Specification = маленький класс, описывающий правило или фильтр.
Вы комбинируете их и получаете сложные запросы без раздутых репозиториев.

Плюсы:
- 🧩 Простая композиция правил
- 🔍 Ясный и читаемый код
- ♻️ Повторное использование условий
- 🧪 Лёгкое тестирование

📌 Пример

// Бизнес-правило: активные клиенты с заказами за последние 30 дней
public sealed class ActiveCustomersSpec : Specification<Customer>
{
    public ActiveCustomersSpec(DateTime since)
    {
        Criteria = c => c.IsActive && c.Orders.Any(o => o.CreatedAt >= since);
        AddInclude(c => c.Orders);
    }
}

// Применение
var spec = new ActiveCustomersSpec(DateTime.UtcNow.AddDays(-30));
var customers = await db.Set<Customer>().Apply(spec).ToListAsync();

💡 Итог:

EF Core = уже Repository + UoW

Репозитории поверх EF Core → лишняя абстракция

Specification Pattern → гибкость и читаемость без «метод-монстров»

🐧 Часто новички в Linux путаются в терминах: Terminal, Shell, Prompt, Command line.
Разберёмся по порядку 👇

- Terminal — это программа, которая запускает shell. Примеры: Terminator, Konsole.
- Shell — сам интерпретатор команд (bash, zsh, fish и др.).
- Prompt — строка перед тем, как вы начинаете вводить команду (обычно с именем пользователя, директории и т.д.).
- Command line — общее понятие: интерфейс, где можно вводить команды (есть в любой ОС).

🔑 Обычно вы открываете Terminal, видите Prompt, пишете команду — её обрабатывает Shell. Всё просто 😉

❗️C# вопрос с собеседования: Middle–Senior level

Вопрос: почему возникает предупреждение о возможном null, если ProductStock здесь явно не равен null?

Код:

private static IEnumerable<Error> VerifyProductQuantities(
    List<ProductStock> products,
    Dictionary<string, Domain.Entities.ProductStock> stocks)
{
    foreach (var product in products)
    {
        if (!stocks.TryGetValue(product.ProductName, out var stock))
        {
            yield return StockErrors.ProductNotFound(product.ProductName);
        }

        if (stock.AvailableQuantity < product.Quantity)
        {
            yield return StockErrors.InsufficientStocks(
                product.ProductName, product.Quantity, stock.AvailableQuantity);
        }
    }
}

Компилятор выдет: «Dereference of a possibly null reference» для переменной stock.

Почему так происходит?
• Метод TryGetValue возвращает false, и тогда stock остаётся равным null.
• Даже если мы отфильтровали это через if (!TryGetValue(...)), компилятор не гарантирует, что в блоке после условия stock точно не null.
• В результате в строке if (stock.AvailableQuantity < product.Quantity) возникает предупреждение.

Как исправить?
1. Добавить continue после yield return внутри блока if (!TryGetValue(...)). Тогда компилятор поймёт, что кода после этой ветки для null не будет.
2. Либо использовать оператор !:
if (stock!.AvailableQuantity < product.Quantity) — но это безопасно только если мы уверены, что значение точно не null.
3. Более читаемый вариант — переписать логику так, чтобы работа с stock была строго в ветке, где оно гарантированно задано.

Вопрос для проверки понимания nullable reference types и поведения компилятора при анализе путей выполнения кода.

🚀 Микросервисная платформа для страхования

Yosef — это открытая микросервисная платформа для финансовой страховой отрасли, разработанная на .NET, Python, TypeScript и Golang. Она обеспечивает масштабируемость, гибкость и высокую наблюдаемость для современных страховых приложений.

🚀 Основные моменты:
- Микросервисная архитектура для легкости масштабирования
- Централизованное управление идентификацией и доступом
- Полный цикл страхования от оценки до создания полиса
- Высокая наблюдаемость с использованием Grafana и Prometheus
- Интеграция с современными инструментами безопасности

📌 GitHub: https://github.com/elyosemite/Yosef

#csharp

🚀 SQL Ultimate Course — бесплатный полный курс по SQL на GitHub

Если хочешь освоить SQL с нуля и дойти до продвинутого уровня — бери готовый репозиторий:

📂 Что внутри:
- datasets/ — реальные данные из ERP и CRM
- scripts/ — готовые SQL-скрипты для практики
- docs/ — документация и материалы курса

✅ MIT-лицензия — можно использовать и менять свободно
🌍 Подходит для всех СУБД (PostgreSQL, MySQL и др.)
🎥 К курсу прилагаются видео и гайды от автора

Автор: Data With Baraa — практик и ютубер, собравший в одном месте полный SQL-путь от простого SELECT до оптимизации запросов и реальных кейсов.

🔗 Репозиторий здесь: https://github.com/DataWithBaraa/sql-ultimate-course

Сохраняй, проходи и прокачивай SQL 💡

🎮 Клад для геймдева — Kenney Assets

Бесплатная библиотека 2D и 3D-ассетов: спрайты, текстуры, звуки, шрифты и даже модели для VR/AR. Всё под лицензией CC0 — можно использовать где угодно, включая коммерческие проекты.

📌 Плюсы:
- Регулярные обновления и новые пакеты
- Идеально для прототипов, обучения и инди-игр
- Никаких ограничений по использованию

🔥 Забирай здесь: https://kenney.nl/assets

#ПятничныйКвиз #ДляСамыхМаленьких

⚡ Как выбор структур данных влияет на скорость .NET приложений

Недавно я оптимизировал 12 крупных систем на ASP .NET Core и каждый раз сталкивался с одной и той же проблемой.
Разработчики тратят много времени на оптимизацию запросов, индексов и кэша, но забывают про базу — правильный выбор коллекций.

Ошибка в выборе структуры данных может замедлить приложение в 10 раз.
Вот простые примеры:

1. Поиск по ключу
- List<T>.Find() → O(n) — медленно на больших объёмах
- ✅ Dictionary<K,V> → O(1) — быстрый доступ

2. Вставка в начало списка
- List<T>.Insert(0, item) → O(n) — сдвигает все элементы
- ✅ LinkedList<T> → O(1) — мгновенная вставка

3. Уникальные элементы
- List<T> + Contains() → O(n) на каждую проверку
- ✅ HashSet<T> → O(1) — уникальность проверяется сразу

4. Упорядоченные данные
- List<T> + Sort() → O(n log n) и нужен свой поиск
- ✅ SortedDictionary<K,V> → встроенный порядок и быстрый поиск

5. Кэширование API-ответов
- Static Dictionary → риск утечек памяти и «зависших» данных
- ✅ MemoryCache → встроенная очистка и управление временем жизни

💡 Итог: чаще всего не нужны «хитрые оптимизации». Достаточно выбрать правильную коллекцию — и производительность вырастет кратно.

👉 Вопрос к вам: какая самая серьёзная проблема с производительностью у вас решилась заменой структуры данных?

🖥 Notepads — легковесный и функциональный текстовый редактор для Windows, который является альтернативой стандартному блокноту!

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

🔍 Основные особенности Notepads:

🌟 Минималистичный интерфейс с возможностью использования вкладок для работы с несколькими документами.

🌟 Поддержка синтаксической подсветки для популярных языков программирования (например, Python, JavaScript, HTML и другие).
Возможность использования темной и светлой темы.

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

🌟 Поддержка Unicode и работы с многоязычными текстами.
Интеграция с Windows 10 API, что позволяет использовать функциональные возможности операционной системы, такие как улучшенные окна и взаимодействие с пользовательским интерфейсом.

🔐 Лицензия: MIT

🖥 Github

@csharp_ci

⚡ .NET 9 — самая быстрая платформа 2025 года

Microsoft прокачала .NET так, что он обгоняет почти все популярные фреймворки: Java, Go, Node.js, Python и даже PHP.

🚀 Что сделали:
- Мусорщик (GC) стал адаптивным → меньше пауз даже при высоких нагрузках.
- JIT-компилятор быстрее разогревает код и оптимизирует горячие участки.
- Векторизация через AVX10 и Arm SVE ускоряет циклы в несколько раз.
- Native AOT уменьшает размер бинарников и ускоряет запуск (контейнеры, IoT, edge).
- Сеть (сокеты, HTTP/3) стала работать быстрее с низкой задержкой.
- JSON обрабатывается через System.Text.Json максимально эффективно.
- Меньше аллокаций → меньше нагрузка на память и GC.
- Thread-pool и многопоточность лучше распределяют задачи по ядрам.
- Минимальные API и оптимизация исключений дали ещё +15% к скорости.

📊 Бенчмарки показывают:
- Java (Spring) — медленнее в 2.5 раза
- Go (Fiber) — в 1.3 раза
- Node.js (Fastify) — в 4 раза
- Python (FastAPI) — в 10 раз
- PHP (Laravel) — в 15 раз
- Ruby (Rails) — в 20 раз

💡 Итог: .NET 9 — быстрый старт, низкая задержка и топ-производительность. Отличный выбор для веба, микросервисов и облака.

#dotnet #performance #benchmark #backend

#ПятничныйКвиз
#ОсеньВремяЗаготавливатьОгурцы

🚀 Docker + .NET pro tip

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

# Этап сборки
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY *.csproj .
RUN dotnet restore
COPY . .
RUN dotnet publish -c Release -o /app/publish

# Этап финального образа
FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MyApp.dll"]

💡 Преимущества:

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

@csharp_ci

⚡ ASP.NET Core: Глобальный обработчик исключений

Красивый и лаконичный пример реализации IExceptionHandler в .NET 8+ через switch`-выражение и сервис `IProblemDetailsService.

internal sealed class GlobalExceptionHandler(
    IProblemDetailsService problemDetailsService,
    ILogger<GlobalExceptionHandler> logger) : IExceptionHandler
{
    public async ValueTask<bool> TryHandleAsync(
        HttpContext httpContext,
        Exception exception,
        CancellationToken cancellationToken)
    {
        logger.LogError(exception, "Unhandled exception occurred");

        httpContext.Response.StatusCode = exception switch
        {
            ApplicationException => StatusCodes.Status400BadRequest,
            _ => StatusCodes.Status500InternalServerError
        };

        return await problemDetailsService.TryWriteAsync(new ProblemDetailsContext
        {
            HttpContext = httpContext,
            Exception = exception,
            ProblemDetails = new ProblemDetails
            {
                Type = exception.GetType().Name,
                Title = "An error occured",
                Detail = exception.Message
            }
        });
    }
}

📌 Что тут важно:

- switch по типу исключения для назначения статуса ответа
- IProblemDetailsService для единообразного формирования ответа
- Логгирование всех необработанных ошибок

🔥 Такой подход делает код чище, централизует обработку ошибок и избавляет от дублирования в middleware.