🚀 Изучаешь ASP.NET Core?

Репозиторий — это 400+ готовых примеров, от Minimal API до Blazor и SignalR.

Все версии .NET Core — от 2.1 до 10 Preview.
Запуск одним dotnet watch run.

⭐ 10k+ звёзд на GitHub, must-have для практики!

https://github.com/dodyg/practical-aspnetcore

🔐 Refresh Tokens в .NET: зачем они нужны?

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

💡 Как это работает:
1. Пользователь логинится с email и паролем.
2. Система проверяет учетные данные.
3. Генерируется пара токенов:
- Access Token — действует недолго, используется для запросов к API.
- Refresh Token — живет дольше и позволяет получить новый access token без повторного ввода логина и пароля.

📌 Код-пример на C#:

[HttpPost("login")]
public async Task<IActionResult> Login([FromBody] LoginUserDto loginUserDto)
{
    IdentityUser? identityUser = await userManager.FindByEmailAsync(loginUserDto.Email);

    if (identityUser == null || 
        !await userManager.CheckPasswordAsync(identityUser, loginUserDto.Password))
    {
        return Unauthorized();
    }

    User? appUser = await context.Users
        .FirstOrDefaultAsync(u => u.Id == Guid.Parse(identityUser.Id));

    if (appUser == null)
    {
        return NotFound();
    }

    string accessToken = tokenProvider.GenerateAccessToken(appUser);
    string refreshToken = tokenProvider.GenerateRefreshToken();

    return Ok(new AuthResponseDto(accessToken, refreshToken));
}

⚡ 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.

🚀 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

⚡ .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

⚡ Как выбор структур данных влияет на скорость .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 → встроенная очистка и управление временем жизни

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

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

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

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

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

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

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

🚀 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 💡

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

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

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

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

#csharp

❗️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 и поведения компилятора при анализе путей выполнения кода.

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

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

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

🚫 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 → гибкость и читаемость без «метод-монстров»