🚀 .NET 8: как сделать микросервисы устойчивыми с Resilience Pipelines + DI

В распределённых системах ошибки — это не исключение, а реальность:

❌ API временно недоступен
❌ сеть дала сбой
❌ сервис перегружен
❌ внешний провайдер отвечает слишком долго

В .NET 8 это стало намного проще благодаря Microsoft.Extensions.Resilience (на базе Polly).

Можно собрать свой ResiliencePipeline и добавить в DI один раз:

✅ Retry — повторить запрос
✅ Timeout — ограничить время ожидания
✅ Circuit Breaker — остановить поток ошибок
✅ Fallback — вернуть запасной результат
✅ Rate Limiter — защитить сервис
✅ Hedging — отправить альтернативный запрос

Главный плюс — не нужно настраивать защиту в каждом месте кода.

Создаёшь pipeline → регистрируешь через DI → используешь где нужно:

var user = await pipeline.ExecuteAsync(
    async token => await httpClient.GetAsync("api/users", token)
);

Чистый код, единая стратегия обработки ошибок и меньше боли при росте микросервисов.

Если пишете на C# и строите production-системы — Resilience Pipelines стоит добавить в свой toolbox. ⚙️

Читать полностью…

⚡️Актуальные темы .NET на DotNext 2026

В .NET одновременно происходит много интересного: C# получает новые возможности, .NET 10 меняет расклад между Native AOT и JIT, а в разработке появляются ИИ-агенты, которые берут на себя часть инженерной работы.
На DotNext 2026 разберем как вещи, которые происходят на уровне машинного кода, так и вполне прикладные вопросы архитектуры и разработки.

📅 25–26 сентября, Москва + online

Выбрали 8 тем из программы, среди которых не только доклады, но и хардкорный воркшоп, чтобы показать этот диапазон:

— как заставить Transactional Outbox одновременно быть строгим и параллельным;
— зачем ASP.NET Core модульный монолит и как собрать его без микросервисов;
— где Native AOT выигрывает у JIT в .NET 10;
— что происходит с циклами, inlining и bounds checks в C# и Go;
— как меняется SDLC, когда в команде появляются ИИ-агенты;
— что принесут discriminated unions в C# 15;
— как проектировать асинхронное взаимодействие в распределенных системах (воркшоп).

Все подробности — в карточках и на сайте конференции.

🌟По промокоду csharpci — персональные билеты дешевле

→ Программа DotNext

→ Купить билет

Читать полностью…

🔥 Хочешь быстрее расти в IT? Хватит учиться в одиночку

Окружение решает больше, чем кажется.

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

AI: t.me/ai_machinelearning_big_data
Python: t.me/pythonl
Linux: t.me/linuxacademiya
Хакинг: t.me/linuxkalii
DevOps: t.me/DevOPSitsec
Docker: /channel/+90Z5TAyfuNU5YmRi
Golang: t.me/Golang_google
Rust: t.me/rust_code
C++: t.me/cpluspluc
C#: t.me/csharp_1001_notes
Java: t.me/javatg
JavaScript: t.me/javascriptv
React: t.me/react_tg
Frontend: t.me/front
PHP: t.me/phpshka
Android: t.me/android_its
Мобильная разработка: t.me/mobdevelop
Базы данных: t.me/sqlhub
Data Science: t.me/data_analysis_ml
Big Data: t.me/bigdatai
Математика: t.me/data_math
Физика: /channel/+S4hinvO3QI43ZjNi
Kubernetes: t.me/kubernetc
GameDev: /channel/gamedev
Haskell: t.me/haskell_tg

Собеседования и карьера:

DS собеседования: t.me/machinelearning_interview
Python собеседования: t.me/python_job_interview

Папка с вакансиями: t.me/addlist/_zyy_jQ_QUsyM2Vi
Папка Go разработчика: t.me/addlist/MUtJEeJSxeY2YTFi
Папка Python разработчика: t.me/addlist/eEPya-HF6mkxMGIy
Папка ML: /channel/addlist/2Ls-snqEeytkMDgy
Папка Frontend: /channel/addlist/mzMMG3RPZhY2M2Iy

Полезное сверху:

ИТ-мемы: t.me/memes_prog
Английский для программистов: t.me/english_forprogrammers
ИИ и технологии: t.me/vistehno
954 ГБ open-source курсов: /channel/+rKBQEMccAA01MTcy
ИТ-книги бесплатно: /channel/addlist/BkskQciUW_FhNjEy

Max Ai: https://max.ru/ai_machinelearning_big_data
Max python: https://max.ru/pythonl
ТЕХНО: https://max.ru/vistehno
Max Go: https://max.ru/Golang_google
Max Linux: https://max.ru/linuxkalii
Devops: https://max.ru/DevOPSitsec
C#: https://max.ru/csharp_ci
C++: https://max.ru/cpluspluc
SQL: https://max.ru/sqlhub
Java: https://max.ru/javatg

Подписывайся на нужные направления и собирай себе ленту, которая реально двигает вперёд.

Читать полностью…

🔥 .NET 11 Preview 7 вышел, и Microsoft заметно прокачала сразу C#, Runtime, ASP.NET Core и SDK

Один из самых интересных апдейтов в C# — labeled break и continue: теперь можно явно указать, из какого цикла выходить или какой цикл продолжать. Ещё появились union patterns и улучшенная проверка исчерпывающих случаев для закрытых иерархий типов.

В Runtime добавили оптимизации async`/`await, включая runtime async tiering и tail-await. Отдельно продолжают развивать NativeAOT и JIT.

В SDK NativeAOT-версия dotnet CLI теперь включена по умолчанию, как и MSBuild Server. У dotnet test появились общий --timeout, ограничение --maximum-failed-tests и поддержка запуска тестов на устройствах .NET MAUI.

ASP.NET Core получил автоматическую приостановку неактивных Blazor circuits, кеширование SSR через CacheView, новые анализаторы Blazor и встроенную локализацию validation-сообщений.

Ещё из приятного: HTTP request compression, API для DNS-записей, парольная защита ZIP, Complex<T>, улучшения LINQ в EF Core и поддержка Half в SQLite.

.NET 11 Preview 7 вышел 11 августа 2026 года и уже доступен для тестирования.

https://devblogs.microsoft.com/dotnet/dotnet-11-preview-7/

Читать полностью…

Запрограммируй робота на Python и поборись за призовой фонд трека 7 500 000 руб на True Tech Champ 2026.

Попробуй себя в треке по программированию роботов. Начать проще, чем кажется: зарегистрируйся, собери команду или объединись с другими участниками на платформе и пройди квалификационный этап до 13 сентября. В онлайн-симуляторе тебе предстоит запрограммировать робособаку и робота-манипулятора для доставки груза через полосу препятствий. Количество попыток не ограничено, а еще тебя будет ждать серия обучающих вебинаров.

Лучшие команды пройдут в финал и будут программировать реальных роботов на офлайн-полигоне 22 октября на большой сцене.
Масштабный финал объединит борьбу за призовой фонд, выступления хедлайнеров, доклады спикеров и активности для всех гостей мероприятия.

Рекомендуемые стеки: Go, Java, Python, C#, C++, JS.

Успей зарегистрироваться и пройти квалификацию до 13 сентября

Реклама. ООО "МВС", ИНН 7707767501, Erid:2VSb5yvnNti

Читать полностью…

🔥 Request-response через брокер сообщений в C#: мощный паттерн, который легко превратить в распределённый дедлок

Один сервис отправляет сообщение в RabbitMQ или NATS и ждёт ответ.

Для вызывающего кода это выглядит почти как обычный await, хотя под капотом работают две независимые очереди:

Requester -> request -> Responder
Requester <- response <- Responder

В RabbitMQ запрос обычно содержит ReplyTo и уникальный CorrelationId, чтобы клиент понял, к какому запросу относится ответ.

В NATS для ответа создаётся отдельный inbox subject.

Упрощённая идея на C#:

var requestId = Guid.NewGuid();

await bus.SendAsync(new PriceRequest(
    RequestId: requestId,
    ProductId: productId
));

var response = await responses
    .WaitForAsync<PriceResponse>(
        requestId,
        timeout: TimeSpan.FromSeconds(2),
        cancellationToken);

Плюсы действительно значительные:

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

Но это не «HTTP, только через RabbitMQ».

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

- таймаут и CancellationToken;
- уникальный CorrelationId;
- обработка поздних и повторных ответов;
- идемпотентность responder;
- ограничение количества одновременных запросов;
- трассировка через обе очереди.

Особенно опасный случай:

Service A ждёт B
Service B ждёт C
Service C ждёт A

Брокер работает, сообщения доставляются, но вся система стоит.

Request-response через messaging полезен, когда нужны location transparency, балансировка обработчиков и единый транспорт между сервисами.

Для простого короткого запроса HTTP или gRPC часто остаются понятнее и быстрее.

Главное правило:

брокер убирает прямую связь между сервисами, но не убирает зависимость от ответа.

Читать полностью…

## В C# появился safe — но это не аналог Rust

В C# 15 тестируется новый контекстный модификатор safe для кода на границе с нативной памятью.

Главная проблема P/Invoke: компилятор видит сигнатуру метода, но не может проверить, насколько безопасно ведёт себя код внутри подключённой библиотеки. Теперь разработчик должен явно зафиксировать решение:

[LibraryImport("libc")]
internal static safe partial int getpid();

[LibraryImport("libc")]
internal static unsafe partial nuint strlen(byte* value);

safe означает, что вызов не требует `unsafe`-контекста со стороны пользователя API.

unsafe предупреждает: безопасность зависит от условий, которые компилятор проверить не может. Такой метод разрешено вызывать только внутри блока:

unsafe
{
    nuint length = strlen(pointer);
}

Та же логика применяется к полям структур с явным расположением памяти:

[StructLayout(LayoutKind.Explicit)]
struct Packet
{
    [FieldOffset(0)]
    public safe long Id;

    [FieldOffset(0)]
    public unsafe nint Pointer;
}

Если не указать ни safe, ни unsafe, компилятор выдаст ошибку при включённых новых правилах безопасности. :contentReference[oaicite:0]{index=0}

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

C# постепенно меняет подход к unsafe: риск должен быть обозначен в контракте метода и локализован в конкретных участках программы, а не спрятан внутри большого `unsafe`-класса.

Пока эта модель находится в preview и может измениться до стабильного выпуска C# 15.

Читать полностью…

🎓 ИТМО продолжает набор на онлайн-магистратуру по разработке и ИИ-решениям 

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

Всего доступно несколько треков для начинающих и опытных специалистов:
- фронтенд на JavaScript;
- бэкенд на Python, Java и C++;
- отдельный по ИИ-решениям в разработке.

На треке по C++ можно прокачать работу с архитектурой, библиотеками, STL, RAII, CMake, Linux, Docker и высокопроизводительными приложениями. Для опытных разработчиков есть отдельный продвинутый уровень.

Блок программы по использованию ИИ в разработке посвящен промпт-инжинирингу, автоматизации рутины, работе с LLM и созданию ИИ-систем — от RAG-пайплайнов до мультиагентных решений.

Что еще внутри:
- диплом магистра ИТМО по направлению «Прикладная информатика»;
- кейсы от команд Яндекса и партнеров;
- возможность собрать портфолио на реальных задачах;
- занятия по вечерам без необходимости менять привычный график.

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

Читать полностью…

Clean Code: сложный `if` лучше превратить в понятное правило

Такой код приходится расшифровывать каждый раз:

if (invoice is not null &&
    invoice.Status == InvoiceStatus.Unpaid &&
    invoice.DueDateUtc < DateTime.UtcNow &&
    invoice.Balance > 0 &&
    !invoice.SilenceWarnings &&
    invoice.Customer.Email is not null)
{
    SendOverdueWarning(invoice);
}

Условие растёт, бизнес-правило теряется среди технических деталей, а изменение одного требования превращается в рискованный рефакторинг.

Вынесем правило в метод с говорящим именем:

if (invoice.ShouldSendOverdueWarning(nowUtc))
{
    SendOverdueWarning(invoice);
}

Само правило:

public bool ShouldSendOverdueWarning(DateTime nowUtc)
{
    return Status == InvoiceStatus.Unpaid
        && DueDateUtc < nowUtc
        && Balance > 0
        && !SilenceWarnings
        && Customer.Email is not null;
}

Теперь вызывающий код отвечает на вопрос что происходит, а метод хранит детали когда это разрешено.

### Почему исходный вариант плохо тестируется

Он напрямую использует DateTime.UtcNow. Результат зависит от реального времени, поэтому тест может вести себя по-разному в разные моменты.

После передачи времени параметром тест становится предсказуемым:

[Fact]
public void Sends_warning_for_overdue_unpaid_invoice()
{
    var invoice = new Invoice
    {
        Status = InvoiceStatus.Unpaid,
        DueDateUtc = new DateTime(2026, 7, 20),
        Balance = 1500,
        SilenceWarnings = false,
        Customer = new Customer { Email = "user@example.com" }
    };

    var nowUtc = new DateTime(2026, 7, 28);

    Assert.True(invoice.ShouldSendOverdueWarning(nowUtc));
}

Для больших проектов вместо DateTime можно внедрить TimeProvider. Главное правило: время, сеть, файловая система и случайность не должны быть скрыты внутри бизнес-логики.

Читать полностью…

AI-инструменты уже умеют быстро писать код, но для C#-разработчика это не отменяет экспертизу, а делает её важнее. Теперь нужно не просто получить подсказку от ассистента, а понять, где она корректна, где скрывает ошибку и какие последствия принесёт в .NET-приложении.

5 августа в 20:00 МСК на открытом вебинаре OTUS разберём, как использовать AI так, чтобы становиться сильнее как C#-разработчик, а не зависеть от автогенерации. Покажем, где AI действительно ускоряет работу Middle/Senior: рефакторинг, генерация тестов, разбор legacy-кода, объяснение стектрейсов и поиск направлений для улучшения.

Отдельно посмотрим на зоны, где ассистенты часто ошибаются: потокобезопасность, работа с IDisposable, производительность LINQ, тонкости DI и конфигурации.

Урок проходит в преддверии старта курса «C#-разработчик. Продвинутый уровень».

👉 Регистрируйтесь: https://otus.pw/Fr6z/?erid=2W5zFHxn4hF


Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Читать полностью…

Каждый год в середине лета мы с друзьями собираемся на E-CODE. Ещё относительно молодая конфа Ozon Tech стала уже своего рода легендой. Не удивительно: хардовость официальной части здесь не уступает громкости афтерпати.

На E-CODE 2026 нас по части бэкэнда ждут:

• Runtime Async с его + и –
• трассировка с eBPF
• ускорение на SIMD
• построение кастомной real-time системы видеоаналитики
• сравнительный анализ алгоритмов сборки мусора

Фишка этого года — брейнринг разработчиков и ИИ. Эксперты разберут сложные кейсы и сравнят свои подходы с тем, что предложит машина. Победителя выберет зал.

Регистрируйтесь сейчас, чтобы услышать это всё вживую: https://ecode.ozon.tech/

12 и 13 сентября, Москва. До встречи на E-CODE!

Читать полностью…

⚡️ Почему Repository поверх EF Core часто превращается в лишний слой

Многие .NET-проекты начинают с отдельных репозиториев:

GetPostsByUser(...)
GetPopularPosts(...)
GetPostsByCategory(...)
GetRecentViralPosts(...)

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

Проблема в том, что DbContext уже предоставляет возможности, близкие к Repository и Unit of Work. Дополнительный слой часто усложняет запросы, скрывает возможности EF Core и создаёт абстракцию поверх абстракции.

Один из вариантов решения — Specification Pattern.

Каждая спецификация описывает отдельное условие выборки:

var specification =
    new ViralPostSpecification(minLikesCount: 150);

var posts = await dbContext.Posts
    .ApplySpecification(specification)
    .Select(post => post.ToDto())
    .ToListAsync(cancellationToken);

Спецификации можно переиспользовать и комбинировать:

var combinedSpec =
    recentSpec.And(highEngagementSpec);

Что это даёт:

- фильтры не размножаются по репозиториям
- запросы остаются рядом с бизнес-правилами
- спецификации проще тестировать
- условия можно комбинировать
- IQueryable продолжает переводиться в SQL

Repository Pattern полезен, когда действительно изолирует сложную инфраструктуру или несколько источников данных. Но создавать отдельный репозиторий для каждой сущности только ради шаблона часто означает лишнее усложнение архитектуры.

#dotnet #csharp #efcore #architecture

Читать полностью…

Microsoft показала Microsoft.UI.Reactor - экспериментальный open-source проект, который переосмысляет разработку WinUI 3-приложений.

Инструмент позволяет писать нативные Windows-приложения декларативно на C#, без привычной связки XAML + code-behind + view models. UI описывается как функция состояния, а Reactor сам синхронизирует экран с изменениями.

Что это даёт:

* меньше split между разметкой и логикой
* проще управлять state
* компоненты выглядят ближе к React-подходу
* вся структура приложения остаётся в C#
* можно быстрее собирать и менять UI

Проект пока экспериментальный. В README он описан как набор расширений для WinUI 3, а публичный preview-пакет уже доступен через NuGet; шаблон проекта пока ставится из исходников.

На фоне того, что WinUI 3 остаётся рекомендуемым нативным UI-фреймворком для новых Windows desktop-приложений, Reactor выглядит как попытка сделать Windows-разработку более современной и менее тяжёлой.

Это интересный эксперимент: каким мог бы быть WinUI, если бы его проектировали под декларативный C# и component-driven разработку.

build.microsoft.com/en-US/sessions/OD854?source=sessions

Читать полностью…

Vertical Slice Architecture хороша тем, что перестаёт заставлять код жить “по этажам”.

В классической слоистой архитектуре фича часто размазана по всему проекту: endpoint в одном месте, request/response в другом, validator где-то рядом, handler отдельно, репозиторий ещё ниже. Чтобы понять одну бизнес-операцию, приходится прыгать по папкам как по квесту.

В vertical slice подход другой: одна фича — один самостоятельный срез.

Например, CreateProduct может хранить рядом всё, что нужно именно для создания продукта:
request, response, validator, endpoint и handler с бизнес-логикой.

Не потому что “так модно”, а потому что это проще сопровождать.

Открыл срез - сразу видишь, что принимает API, что возвращает, как валидирует входные данные и что реально делает. Меньше магии, меньше лишней навигации, меньше риска случайно сломать соседнюю фичу.

Для больших проектов это очень удобно: код начинает группироваться не вокруг технических слоёв, а вокруг бизнес-сценариев.

И это, кажется, главный плюс VSA.

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

Читать полностью…

G# — новый язык для .NET с синтаксисом ближе к Go, Kotlin и Swift.

Идея не в том, чтобы заменить C#, а в том, чтобы дать более компактный язык поверх той же CLR.

Что обещают:

• компиляция в обычные managed .NET assemblies

• совместимость с BCL, NuGet, MSBuild и dotnet tooling

• interop с C#-кодом

• null-safety через T?, nil, ?., ??, if let и guard let

• data classes со structural equality, copy-with и deconstruction

• async/await поверх Task и Task[T]

• опциональные Go-подобные go, chan, select

• REPL / script runner через gsi

• C# → G# мигратор через cs2gs

Самая интересная часть — G# не пытается строить новый рантайм. Он просто использует существующую .NET-экосистему и меняет язык входа: меньше исторического багажа C#, больше предсказуемой синтаксической поверхности.

Но важно: проект пока pre-1.0. Версия 0.3 — это скорее milestone по реализации и interop, а не гарантия стабильности языка.

Для продакшена рано. Для тех, кто следит за экспериментами вокруг .NET-языков, очень любопытно.

Статья: https://www.linkedin.com/pulse/meet-g-modern-net-language-go-kotlin-swift-ergonomics-david-obando-lwofc/

Читать полностью…

Как ограничить количество запросов к API по IP в ASP.NET Core

Встроенный Rate Limiter позволяет сделать это буквально в несколько строк:

builder.Services.AddRateLimiter(options =>
{
    options.AddPolicy("fixed-by-ip", httpContext =>
        RateLimitPartition.GetFixedWindowLimiter(
            partitionKey: httpContext.Connection.RemoteIpAddress?.ToString(),
            factory: _ => new FixedWindowRateLimiterOptions
            {
                PermitLimit = 10,
                Window = TimeSpan.FromMinutes(1)
            }));
});

В этом примере один IP может сделать максимум 10 запросов за минуту.

Но использовать такой подход вслепую не стоит.

Причина простая: реальные пользователи могут находиться за NAT, прокси или корпоративным шлюзом и иметь один внешний IP. В итоге лимит одного человека начнёт влиять на остальных.

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

А rate limit по IP оставлять для анонимных endpoint'ов, защиты от простых ботов или как дополнительный слой защиты.

Читать полностью…

Появился бесплатный open-source PDF-редактор для Windows, который пытается заменить Adobe Acrobat без подписки.

KillerPDF умеет редактировать текст прямо в PDF, добавлять аннотации и изображения, объединять и разделять страницы, заполнять формы, ставить подписи, печатать и делать OCR. Причём распознавание работает локально через Tesseract, без отправки документов в облако.

Есть и более редкие штуки: восстановление повреждённых PDF, открытие файлов с паролем, выравнивание кривых сканов, perspective correction, ночной режим, split view для двух документов и полноценная работа из командной строки.

Весь редактор упакован примерно в 16 МБ, может работать portable, не требует аккаунта, не собирает телеметрию и не делает phone-home. Проект распространяется под GPLv3.

На GitHub уже около 3,4 тыс. звёзд.

https://github.com/SteveTheKiller/KillerPDF

Читать полностью…

⚙️ Service Discovery в .NET через Consul можно подключить без самописного резолва адресов и ручного перебора инстансов.

Рабочая схема выглядит так:

Install-Package Steeltoe.Discovery.Consul

Регистрируем discovery:

builder.Services
    .AddServiceDiscovery(o => o.UseConsul());

В appsettings.json указываем Consul и параметры сервиса:

"Consul": {
  "Host": "localhost",
  "Port": 8500,
  "Discovery": {
    "ServiceName": "reporting-service",
    "Hostname": "reporting-api",
    "Port": 8080
  }
}

А дальше самое полезное:

builder.Services
    .AddHttpClient<ReportingServiceClient>(client =>
    {
        client.BaseAddress = new Uri("http://reporting-service");
    })
    .AddServiceDiscovery()
    .AddRoundRobinLoadBalancer();

То есть HttpClient ходит не на конкретный IP:port, а на логическое имя сервиса.

Steeltoe через Consul получает живые инстансы, а RoundRobinLoadBalancer распределяет запросы между ними.

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

По сути, клиентская часть получает простой pipeline:

service name → Consul → healthy instances → load balancing → HTTP request

Для микросервисов на .NET это намного чище, чем городить собственный discovery layer.

Читать полностью…

🚀 C# РАЗРАБОТЧИКИ: перестаньте создавать зависимости вручную

Одна из самых частых ошибок в архитектуре .NET - создавать зависимости прямо внутри класса.

❌ Плохой подход:
var companyRepository = new CompanyRepository();
var customerRepository = new CustomerRepository();
var creditService = new CustomerCreditServiceClient();
Проблемы:

❌ жёсткая связность компонентов
❌ сложно заменить реализацию
❌ трудно писать unit-тесты
❌ нет удобного контроля времени жизни объектов

✅ Лучше использовать Dependency Injection
public class CustomerService(
CompanyRepository companyRepository,
CustomerRepository customerRepository,
CustomerCreditServiceClient creditService)
{
}
Теперь DI-контейнер сам создаёт и передаёт нужные зависимости.

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

✅ управление временем жизни (Singleton, Scoped, Transient)
✅ лёгкое использование mock-объектов в тестах
✅ decorators для логирования, кэширования и retry
✅ меньше связности между классами
✅ проще масштабировать и рефакторить проект

Dependency Injection - это не просто возможность ASP.NET Core.

Это один из главных принципов создания чистой, гибкой и поддерживаемой архитектуры C#.

🔥 Ещё 5 приёмов рефакторинга C#, которые стоит знать каждому .NET разработчику:
https://milanjovanovic.tech/blog/5-awesome-csharp-refactoring-tips

Читать полностью…

💡 C#: заставьте архитектуру ломать CI, если кто-то нарушил правила

Компилятор C# отлично проверяет типы, но ему всё равно, что Application внезапно начал зависеть от Infrastructure.

Code Review тоже не гарантирует, что такое заметят.

Для этого можно использовать Architecture Tests — тесты, которые проверяют не бизнес-логику, а структуру проекта.

Например, через NetArchTest.Rules:

[Fact]
public void Application_Should_Not_Depend_On_Infrastructure()
{
    var result = Types
        .InAssembly(ApplicationAssembly)
        .ShouldNot()
        .HaveDependencyOn("MyApp.Infrastructure")
        .GetResult();

    Assert.True(result.IsSuccessful);
}

Теперь случайный:

Application → Infrastructure

сломает CI так же, как обычный упавший unit-тест.

Можно зафиксировать и naming convention:

[Fact]
public void Handlers_Should_End_With_Handler()
{
    var result = Types
        .InAssembly(ApplicationAssembly)
        .That()
        .ImplementInterface(typeof(ICommandHandler<>))
        .Should()
        .HaveNameEndingWith("Handler")
        .GetResult();

    Assert.True(result.IsSuccessful);
}

Или заставить сервисы быть sealed:

Types
    .InAssembly(ApplicationAssembly)
    .That()
    .HaveNameEndingWith("Service")
    .Should()
    .BeSealed();

Особенно полезно это становится в больших Clean Architecture / DDD / Modular Monolith проектах.

Вместо документа:

❌ «Application не должен зависеть от Infrastructure»

получаем исполняемое правило:

✅ нарушил архитектуру → тест упал → PR не прошёл

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

#CSharp #DotNet #Architecture #Testing

Читать полностью…

Лето, ИТ-Пикник и музыка известных артистов уже через несколько дней!

8 августа в Коломенском пройдет ИТ-Пикник.

В программе — выступления проекта LAB Антона Беляева, IOWA, Cream Soda, Pompeya, мартина и Совы.

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

Зарегистрироваться и узнать подробности можно на сайте мероприятия.

В билет входит +1 — можно позвать близких и друзей.

До встречи в месте притяжения ИТ.

Читать полностью…

C#-приём: точное сложение `double` через алгоритм Кэхэна

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

Обычный вариант:

double sum = 0;

foreach (double value in values)
{
    sum += value;
}

Более точный вариант:

public static double KahanSum(ReadOnlySpan<double> values)
{
    double sum = 0;
    double compensation = 0;

    foreach (double value in values)
    {
        double adjusted = value - compensation;
        double next = sum + adjusted;

        compensation = (next - sum) - adjusted;
        sum = next;
    }

    return sum;
}

Переменная compensation сохраняет часть числа, потерянную при округлении, и возвращает её в следующее сложение.

Использование:

double[] values = { 0.1, 0.2, 0.3, 0.4 };

double result = KahanSum(values);

Метод полезен для:

- научных расчётов;
- статистики и аналитики;
- обработки сигналов;
- симуляций;
- накопления миллионов небольших значений.

ReadOnlySpan<double> позволяет передавать массивы и участки памяти без дополнительных копирований.

Алгоритм требует нескольких дополнительных операций на каждом шаге, зато заметно уменьшает накопленную погрешность.

Для денежных расчётов по-прежнему лучше использовать decimal. А когда нужна скорость double и повышенная численная устойчивость – пригодится Kahan Summation.

Читать полностью…

C# 15 наконец избавляет вложенные циклы от флагов и `goto`

break и continue могут указывать метку внешнего цикла. Это позволяет сразу выйти из нескольких уровней вложенности или перейти к следующей итерации нужного цикла.

outer: for (int row = 0; row < grid.Height; row++)
{
    for (int column = 0; column < grid.Width; column++)
    {
        if (grid[row, column].IsBlocked)
        {
            continue outer;
        }

        if (grid[row, column].IsGoal)
        {
            break outer;
        }
    }
}

Здесь:

- continue outer прекращает внутренний цикл и запускает следующую итерацию внешнего;
- break outer полностью выходит из обоих циклов.

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

В C# 15 этот код можно записать короче и понятнее.

Особенно удобно при обходе:

- матриц;
- вложенных коллекций;
- игровых карт;
- таблиц;
- сложных структур данных.

Небольшое изменение, которое убирает много лишнего кода из вложенных циклов.

Читать полностью…

Copilot научили разбирать MSBuild-логи прямо в VS Code

Microsoft выпустила MSBuild Binlog Analyzer — расширение, которое превращает сложные .binlog в понятный диалог с GitHub Copilot.

Можно спросить:

почему упала сборка;
какие targets и tasks тормозят;
что изменилось между двумя сборками;
почему сломалась incremental build.

Copilot опирается на реальные данные лога через MCP, умеет находить причину ошибки, предлагать исправление и проверять результат повторной сборкой. Есть сравнение с baseline, поиск регрессий и загрузка логов из GitHub Actions и Azure DevOps.

https://devblogs.microsoft.com/dotnet/msbuild-binlog-analyzer-vscode/

Читать полностью…

Microsoft выпустила бесплатный курс по модернизации старого .NET

.NET Modernization for Beginners показывает, как перенести legacy ASP.NET-приложение на .NET 10 с помощью GitHub Copilot modernization agent.

Внутри:

- анализ старого кода и зависимостей;
- генерация плана миграции;
- пошаговый upgrade приложения;
- деплой обновлённой версии в Azure App Service.

Интересно, что агент сначала создаёт assessment.md, plan.md и tasks.md, а разработчик может проверить план до изменения кода.

Сам курс бесплатный и open source. Для практики понадобится GitHub Copilot.

https://devblogs.microsoft.com/dotnet/announcing-dotnet-modernization-for-beginners/

Читать полностью…

😨 Opus 5 собрал онлайн-шутер в духе Call of Duty практически с одного промпта

Автор попросил модель сделать FPS на Three.js с AAA-графикой, физикой и детализацией, а работу разбить между несколькими субагентами.

Отдельным агентам поручили:
• реализовывать разные части игры
• проверять результат визуально
• жёстко критиковать качество
• повторять итерации, пока результат не станет максимально близок к Call of Duty

Fвтор выложил репозиторий и исходный промпт, поэтому результат можно проверить самому.

промпт:

I want you to build a first-person shooter at the level of the most recent Call of Duty games. It should be utterly perfect, visually beautiful, with every single thing done at AAA quality—from textures to physics to anything you could think of.

Fan out sub-agents and have sub-agents tackle each one individually so that the game is utterly perfect. You should /loop on each item and have a separate sub-agent check it visually to ensure it looks triple A. That separate sub-agent should be a really harsh critic, and if it doesn't look triple A, it should keep going.

Don't stop until each sub-agent is utterly wowed with the quality when compared with the actual Call of Duty game. It should literally compare them side by side blind and say which one looks better. Do this in ThreeJS. /loop until it's utterly perfect. Fan out sub-agents and ultracode.

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

Геймдев меняется быстрее, чем многие ожидали. 😨

Читать полностью…

Unity представила Unity CLI - инструмент, который позволяет ИИ-агентам напрямую работать с игровыми проектами.

Агент может:

- изменять объекты и компоненты в сценах;
- искать причины ошибок;
- исправлять баги;
- запускать сборку проекта;
- проверять, действительно ли исправление сработало.

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

Получается почти полноценный ИИ-разработчик: получил задачу, изучил проект, внёс изменения и протестировал результат — всё через терминал.

Инструмент доступен бесплатно.

Подробнее: https://unity.com/blog/meet-the-unity-cli

#unity #gamedev #ai #vibecoding

Читать полностью…

🔥 Вышел .NET 11 Preview 6.

Это уже шестой превью-релиз .NET 11, и он выглядит не как “пара мелких фиксов”, а как большой проход по всему стеку: Runtime, SDK, Libraries, ASP.NET Core, MAUI, C#, EF Core, F#, контейнеры. Microsoft прямо перечисляет улучшения во всех этих направлениях.

Самое интересное для backend-разработчиков:

* улучшения JIT и runtime async performance
* in-process crash report logging
* faster interface dispatch для NativeAOT
* новые SIMD API
* dotnet test получает новые опции и улучшенный вывод
* container publishing теперь поддерживает multi-arch builds с Podman

В C# продолжают двигать union types: System.Text.Json уже умеет сериализовать C# union types, а support types для unions теперь идут “из коробки”. Ещё появился пункт про extension indexers.

В ASP.NET Core тоже много практичных вещей: async validation для minimal APIs, автоматическая CSRF-защита для cross-origin сценариев, OpenAPI 3.2 по умолчанию, unions в ASP.NET Core, обновления SignalR и short-circuit endpoints через attribute.

EF Core получил улучшения LINQ query translation, migrations, Cosmos DB provider и поддержку ключей/индексов через complex-type properties.

Для меня главный сигнал Preview 6 такой: .NET 11 явно допиливают не только как runtime, а как цельную платформу для production-разработки: performance, NativeAOT, контейнеры, web API, тесты и tooling двигаются вместе.

Ставить в прод пока рано, но смотреть и пробовать уже есть что.

https://devblogs.microsoft.com/dotnet/dotnet-11-preview-6/

Читать полностью…

TIME_WAIT в Linux годами объясняют неправильно

Я полез в исходники Linux TCP и снова наткнулся на старый сетевой миф.

В коде TIME_WAIT фактически зафиксирован на 60 секунд:
#define TCP_TIMEWAIT_LEN (60 * HZ)
Его нельзя настроить отдельно для сокета.

И да, tcp_fin_timeout, который часто советуют крутить в блогах, не управляет TIME_WAIT.

Он относится к состоянию FIN_WAIT2.

TIME_WAIT задан в исходниках ядра и не вынесен в отдельный sysctl.

Вот так появляются мифы: один параметр звучит похоже, его копируют из статьи в статью, а потом годами лечат не то состояние TCP.

Читать полностью…

Ты не твой стек

Зачем учиться новому, когда по самое колено в практике? Не страшно, что всё больше джунов работают наравне с сеньёрами?

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

Метафизика? Нет - математика.

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

Именно об этом курс: "Философия, математика и компьютерные науки"

Не про конкретный стек, а про то, как в принципе думать о сложных системах с опорой на философию, математику и системную инженерию.

Формат:
9 месяцев, 10 модулей, теория и практика, несколько очных сессий в Петербурге.

Кураторы:
- Андрей Родин — доктор философских наук, философ науки и математики
- Илья Егорычев — доктор философских наук, математик и логик, Soulmaths
- Вячеслав Шириков — системный архитектор, техдиректор ГК «Лартех»

До 21 июля действует скидка за раннюю регистрацию.
Программа и условия

Читать полностью…