C# (C Sharp) programming

🟥 Утечки данных в .NET-приложениях чаще происходят не из-за хакеров, а из-за неверной работы с ключами, конфигурациями и базовой криптографией. Ошибки на уровне кода быстро превращаются в инциденты. На открытом уроке разберём практическое применение System.Security.Cryptography: AES, RSA, хеширование и цифровые подписи. Поговорим о безопасном хранении и передаче секретов, управлении ключами и принципе наименьших привилегий. ❗️ Вы системно разберёте уязвимости OWASP Top-10 для .NET: инъекции, небезопасную десериализацию, XSS, CSRF — и способы их нейтрализации на уровне кода и архитектуры. Отдельно обсудим шифрование данных в БД, защиту строк подключения и безопасное логирование без утечек токенов. 🟥Встречаемся 10 февраля в 20:00 МСК в преддверии старта курса «C# Developer. Professional». Зарегистрируйтесь, чтобы не пропустить: https://tglink.io/73e7493a7d6ff1?erid=2W5zFGXFxba #реклама О рекламодателе

Если вы не используете OpenTelemetry, вы буквально летите вслепую в продакшене. И хорошая новость — вам не нужно переписывать код, чтобы получить “рентген-зрение” для своих сервисов. Достаточно подключить правильные пакеты авто-инструментирования. Вот базовый стартовый набор для .NET: - AspNetCore — автоматически трейсит все входящие HTTP-запросы - HttpClient — показывает тайминги и статусы всех исходящих API-вызовов - EF Core — логирует реальные SQL-запросы и их длительность - Npgsql — добавляет глубокий трейсинг для PostgreSQL - StackExchange.Redis — помогает увидеть cache hits, misses и скачки латентности После установки вы начинаете видеть полный жизненный цикл запроса через все микросервисы — от входящего HTTP до базы, кэша и внешних API. Это уже не “логи и надежда”. Это наблюдаемость продакшен-уровня. Я разобрал, как всё это подключить к Grafana или Jaeger и получить полноценную визуализацию трейсов. Полный гайд по настройке: https://milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet?utm_source=X&utm_medium=social&utm_campaign=19.01.2026

⚡️ Модульный монолит хорош ровно настолько, насколько хороши его границы. Если Module A может “по-тихому” лезть в базу Module B - у тебя не модули. У тебя хаос, просто внутри одного репозитория. Самое сложное в модульной архитектуре - не “разбить на папки”, а решить, что модуль вообще имеет право показывать наружу. Моё правило для Public API: 1) Начинай с нуля Считай, что любой класс должен быть приватным по умолчанию. 2) Открывай только по необходимости Доступ даётся не “на будущее”, а только если другой модуль реально просит функциональность. 3) Экспортируй возможности, а не данные API должно отражать сценарии (use-cases), а не “вот тебе таблица/репозиторий/DTO”. И главное - просто договориться недостаточно. Границы нужно технически запрещать нарушать: модификаторы, сборки, internal, анализаторы, тесты на зависимости.

⚡️ 10 причин перейти на .NET 10 (чтобы это одобрил руководитель) .NET 10 и C# 14 вышли 11 ноября 2025. Ниже - 10 причин, почему апгрейд реально стоит запланировать. 1) LTS-релиз - .NET 10 - Long-Term Support, поддержка до 14 ноября 2028 - поддержка .NET 8 заканчивается 10 ноября 2026 → лучше не тянуть 2) Быстрее ASP.NET Core - до +15% RPS по сравнению с .NET 8 - до -93% потребления памяти → меньше нагрузка и дешевле инфраструктура 3) Общий прирост производительности .NET - сотни улучшений “из коробки” просто после апгрейда проекта 4) File-Based Apps (один .cs файл) - можно сделать один файл *.cs и запускать напрямую - удобно для CLI, автоматизации и утилит без создания проекта 5) Server-Sent Events (SSE) - лёгкий способ стримить данные на клиента - идеален для real-time обновлений без сложности WebSocket 6) Extension Members в C# 14 - более удобный синтаксис расширений - можно расширять свойства и static members 7) Minimal APIs: Validation + JSON Patch - встроенная валидация для Minimal APIs - JSON Patch доступен из коробки 8) EF 10: LeftJoin / RightJoin в LINQ - наконец-то нормальные LeftJoin/RightJoin - запросы становятся проще и читаемее 9) EF 10: Named Query Filters - можно заводить несколько фильтров на одну сущность - включать/выключать их независимо 10) Улучшения Blazor - Hot Reload для Blazor WASM и .NET on WASM - профилирование производительности + диагностические счётчики Источник/подробности: antondevtips.com/draft/10-reasons-to-upgrade-to-dotnet-10/

#ПятничныйКвиз

🏗️ Пытаться вытаскивать микросервисы из “спагетти-монолита” - почти всегда плохая идея. Вместо красивой архитектуры ты получишь распределённую кашу, ещё больше зависимостей, ошибок и боли при поддержке. Самый безопасный путь миграции - паттерн Strangler Fig: выносить функциональность по кускам, постепенно “замещая” монолит. Но есть важное условие: сначала нужно привести систему к Modular Monolith. То есть: - чётко выделить границы модулей - изолировать данные - оставить только чистые публичные API для общения между модулями И только после этого выбирать, какой модуль выносить первым. Как выбрать правильного кандидата на первый микросервис? Ищи 4 “зелёных флага”: 1) Low Coupling - минимум зависимостей от других модулей 2) High Cohesion - логика внутри модуля максимально связная и цельная 3) Distinct Domain - чёткая бизнес-область (например, “платежи” или “инвойсинг”) 4) Scale Needs - модулю нужны другие ресурсы/масштабирование, чем остальной системе Если модуль соответствует этим критериям - его можно вынести относительно безопасно, не превращая архитектуру в распределённый хаос.

Перестань падать из-за одного внешнего API - добавь Fallback в .NET через Resilience Pipeline 🛡️ Вместо того чтобы приложение валилось, когда GitHub (или любой сервис) не отвечает, ты можешь вернуть безопасный дефолт и продолжить работу. Идея простая: Ты добавляешь fallback-стратегию в pipeline, и если запрос падает — система вернёт запасной результат. Что происходит в примере: — В DI регистрируется Resilience Pipeline — Добавляется FallbackStrategy — Если вызов неудачный, возвращается GitHubUser.Empty вместо исключения Дальше в endpoint ты не вызываешь HttpClient напрямую — ты запускаешь его через pipeline: pipeline.ExecuteAsync(...) И если API: ❌ упало ❌ вернуло ошибку ❌ словило таймаут Пользователь не увидит 500. Он получит контролируемый ответ. Это особенно важно для: - внешних API - микросервисов - нестабильных сетей - интеграций с SaaS Fallback — это не про «скрыть ошибку». Это про graceful degradation, когда система продолжает жить даже при частичных сбоях. Надёжность — это архитектура, а не try/catch в каждом методе. #dotnet #backend #architecture

⚙️ Вы настраиваете ASP.NET Core «по наитию» и тратите время на поиск, почему приложение ведет себя по-разному в продакшене и локально? 📆 29 января в 20:00 OTUS проводит открытый урок «Конфигурирование приложения ASP.NET Core» в преддверии старта курса «C# ASP.NET Core разработчик». На занятии разберем, как выстроить прозрачную и управляемую систему настроек: appsettings.json, провайдеры конфигурации, приоритет применения конфигураций, настройки специфичные для среды и шаблон Options для работы с настройками. Вы поймете, как проектировать конфигурации так, чтобы приложения были стабильными и предсказуемыми. ❗️Урок будет полезен разработчикам ASP.NET Core начального и среднего уровня, которые хотят систематизировать знания и работать по индустриальным стандартам. ➡️ Регистрируйтесь на бесплатный урок: https://tglink.io/f0de1b0a6e87?erid=2W5zFH3PFGL 🎁 Все участники открытого урока получат скидку на обучение. #реклама О рекламодателе

🖥 Как обычные Linux-пользователи смотрят файлы:

$ ls -a

А как смотрю я:

$ echo */ *. *

Этот трюк выводит всё “простым” способом через glob-расширение:

- */   покажет папки
- *    покажет обычные файлы
- .*   покажет скрытые файлы

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

📦 Всё ещё не используешь Central Package Management в .NET? Открой свой .csproj прямо сейчас. Пакеты обычно выглядят так: <PackageReference Include="Serilog" Version="4.3.0" /> <PackageReference Include="WolverineFx" Version="5.6.0" /> И в итоге проект превращается в мусорку из версий. А теперь представь, что это будет так: <PackageReference Include="Serilog" /> <PackageReference Include="WolverineFx" /> Вот в этом и кайф Central Package Management. Что он даёт: ✅ .csproj становится чистым и читаемым ✅ никто случайно не поставит “левую” версию пакета ✅ вся команда работает на одинаковых версиях библиотек ✅ сборка становится предсказуемой и детерминированной Как работает: Ты управляешь версиями централизованно через файл Directory.Packages.props в корне репозитория. То есть версии пакетов задаются в одном месте, а проекты просто подключают зависимости без указания version. Если у тебя монорепа или несколько проектов - это must-have.

🖥 Многопоточность в .NET часто сводят к lock. Но в реальных системах этого недостаточно — особенно под нагрузкой, в легаси-коде и распределённых сценариях. 📕 На открытом уроке разберём, какие инструменты действительно есть в .NET и как выбирать подходящий примитив под конкретную задачу. Рассмотрим Monitor, Mutex, Semaphore, а также другие примитивы из System.Threading: ReaderWriterLockSlim, Barrier, ManualResetEventSlim, SpinLock. ❗️ Вы увидите практические примеры, типовые ошибки и узнаете, где блокировки становятся узким местом. Урок будет полезен разработчикам, работающим с высоконагруженными системами и легаси-кодом, а также тимлидам, которые проектируют архитектуру и отвечают за производительность. 📣 Встречаемся 27 января в 20:00 МСК в преддверии старта курса «C# Developer. Professional». Регистрация открыта: https://otus.pw/t6Xj/

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

⚡️ Автоматическая регистрация Minimal APIs в .NET - без ручного маппинга Если в проекте 20+ endpoint’ов, app.MapGet/MapPost превращается в ад. Решение - авторегистрировать endpoints через DI. Идея: 1) Делаешь общий интерфейс IEndpoint 2) Каждый endpoint реализует его 3) На старте приложения сканируешь сборку, регистрируешь все реализации в DI 4) Достаёшь их из DI и вызываешь MapEndpoints() Плюсы: ✅ чистый Program.cs ✅ каждый endpoint в отдельном файле ✅ масштабируется без хаоса ✅ легко тестировать и поддерживать Пример паттерна:

builder.Services.AddEndpoints(typeof(Program).Assembly);

public interface IEndpoint
{
    void Map(IEndpointRouteBuilder app);
}

public static class EndpointExtensions
{
    public static IServiceCollection AddEndpoints(this IServiceCollection services, Assembly assembly)
    {
        var endpoints = assembly.DefinedTypes
            .Where(t => !t.IsAbstract && !t.IsInterface && typeof(IEndpoint).IsAssignableFrom(t))
            .Select(t => ServiceDescriptor.Transient(typeof(IEndpoint), t))
            .ToArray();

        services.TryAddEnumerable(endpoints);
        return services;
    }

    public static void MapEndpoints(this WebApplication app)
    {
        foreach (var endpoint in app.Services.GetServices<IEndpoint>())
            endpoint.Map(app);
    }
}

🚀 Опасен баг, который вылазит через 3 дня после релиза. И это ровно тот риск, который прячется в стандартном Options Pattern в .NET. Ты спокойно делаешь так: - биндишь appsettings.json в класс - инжектишь настройки через DI - приложение стартует без проблем ✅ А потом внезапно… В прод падает , потому что: ❌ не задан обязательный ApiKey ❌ RetryCount = 0 ❌ строка подключения пустая И ты узнаёшь об этом только тогда, когда кто-то нажмёт нужную кнопку в твоем приложении. Вот почему принцип Fail Fast критичен для конфигов: если конфигурация невалидна - приложение не должно запускаться вообще. Как это сделать правильно: используй расширение Options Pattern через IValidateOptions. Суть подхода: 1) задаём правила (например: ApiKey не null, `RetryCount > 0`) 2) регистрируем валидатор 3) если условия нарушены - DI кидает исключение сразу при старте ✅ Можно прйти дальше и подключиит FluentValidation, чтобы условия были: - чище - читабельнее - удобнее расширять Полная реализация: https://milanjovanovic.tech/blog/options-pattern-validation-in-aspnetcore-with-fluentvalidation?utm_source=X&utm_medium=social&utm_campaign=05.01.2026

⚡️ В .NET кэш - это всегда выбор: максимальная скорость или единые данные между серверами. IMemoryCache ✅ Очень быстрый ❌ Работает только внутри одной ноды (в кластере из 10 серверов у вас 10 разных кэшей) Redis / IDistributedCache ✅ Один общий кэш на все ноды - данные одинаковые ❌ Медленнее: сеть + сериализация + лишние накладные расходы Правильный подход - Hybrid Cache. Он не заставляет выбирать - он комбинирует оба мира: - L1 (Local / RAM) - сначала читаем из памяти приложения (самый быстрый слой) - L2 (Distributed / Redis) - если локально нет, идём в общий кэш - Source (DB/API) - если нет и там, берём из источника и прогреваем оба уровня 🚀 скорость как у MemoryCache 🔒 данные согласованы между нодами как в Redis 📉 меньше нагрузки на БД и меньше «холодных» запросов Microsoft делает нативный HybridCache, но если нужно решение уже сейчас - FusionCache остаётся самым надёжным и реально продакшн-готовым вариантом. 📌 Гайд

🎯 Открытый урок «Сетевой чат на C#». 🗓 22 января в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «C# Developer». На вебинаре: ✔️ Рассмотрим написание сетевого приложения на C#. ✔️ Мы реализуем простые клиент и сервер с помощью одного из сетевых протоколов. ✔️Также затронем темы многопточности и асинхронности Кому будет полезно: • Вебинар будет полезен начинающим разработчикам, желающим разобраться в сетевом и многопочном\асинхронном программировании. Что вы получите: • По итогам вебинара смогут проектировать сетевые приложения. • Получат представление о работе сетевых протоколов, и многопоточности\асинхронности в приложениях. • На практике попробуют разработать такое приложение. 🔗 Ссылка на регистрацию: https://otus.pw/zifo/?erid=2W5zFJaPXHA Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

#ПятничныйКвиз