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

Статья: https://buff.ly/4jUlnBi

👉 @KodBlog

dotNET 11 Preview 3 уже доступен — улучшения в JIT, доработки асинхронности, обновления WebCIL, поддержка Zstandard повсеместно, апдейты карт в MAUI, упрощение SQL в EFCore и подписанные контейнерные образы.

Если важны скорость, чистота и современный стек — есть на что посмотреть.

👉 @KodBlog

GitHub Quick Review (ghqr)

Бесплатный CLI с открытым исходным кодом, который сканирует организации и репозитории GitHub на соответствие лучшим практикам.

Одна команда — полный отчёт по состоянию.

https://github.com/microsoft/ghqr

👉 @KodBlog

Не знаю, сколько из вас знают про этот репозиторий на GitHub по веб-сокетам.

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

(Это курируемый список инструментов, библиотек и материалов по веб-сокетам, сгруппированный по языкам и темам)

https://github.com/facundofarias/awesome-websockets

👉 @KodBlog

Минимальные API и версионирование API — это бардак.

Если только не сделать это правильно.

Вместо того чтобы вешать ApiVersionSet на каждый эндпоинт, можно определить группу маршрутов.

Версия задаётся один раз и применяется ко всем эндпоинтам внутри группы.

Маршруты становятся чище, дублирования меньше. Плюс удобно для префиксов вроде /v1.

Хочешь посмотреть, как это работает (и с Minimal API, и с контроллерами)?

Вот гайд: https://milanjovanovic.tech/blog/api-versioning-in-aspnetcore

👉 @KodBlog

Ответы об ошибках в API обычно выглядят как мусор. ProblemDetails это исправляет.

Вот типичный ответ при ошибке:

"Object reference not set to an instance of an object."

Пользы ноль.

А вот что даёт ProblemDetails:

{
  "title": "Product not found",
  "status": 404,
  "detail": "No product with ID 42.",
  "instance": "/products/42"
}

Структурировано. Читаемо. Соответствует стандарту (RFC 9457).

В .NET 10 настройка стала удобнее.

Нужно три вещи:

→ AddProblemDetails() — регистрирует встроенные сервисы ProblemDetails
→ IExceptionHandler — современный способ обработки исключений (вместо кастомного посредника)
→ StatusCodeSelector — автоматически мапит типы исключений на HTTP-статусы

Изменение в .NET 10:

Если IExceptionHandler возвращает true, посредник больше не пишет диагностику (логи, метрики) по умолчанию.

Теперь обработчик сам отвечает за логирование.

Если нужно старое поведение — используй SuppressDiagnosticsCallback.

Базовая настройка в Program.cs занимает несколько строк:

- AddProblemDetails()
- AddExceptionHandler<YourHandler>()
- UseExceptionHandler()
- UseStatusCodePages()

Без сторонних пакетов. Без самописных посредников. Всё встроено в .NET.

👉 @KodBlog

Разработчик сделал то, что у Google не получалось годами.

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

Проект уже набрал более 5k звёзд на GitHub, он бесплатный и с открытым исходным кодом.

👉 @KodBlog

Как правильно структурировать фичу в формате вертикального среза?

Вот простая структура вертикального среза, которую можно смело брать на вооружение:

🔸Объект запроса/ответа
🔸Определение эндпоинта
🔸Бизнес-логика

Всё, что относится к одной фиче, находится в одном месте.

Почему это круто — объяснено здесь

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

👉 @KodBlog

Это изменит работу с вашими API:

(начиная с .NET 9)

Начиная с .NET 9, Swagger больше не входит в стартовый шаблон Web API.

Microsoft убрали Swashbuckle.AspNetCore, так как он больше не поддерживается активно.

Вместо этого из коробки доступен Microsoft.AspNetCore.OpenApi для генерации OpenAPI-документов.

Но это означает, что встроенного UI для отображения эндпоинтов API больше нет.

Поэтому можно вручную вернуть Swashbuckle.

Либо использовать альтернативы, например Scalar.

Некоторые возможности Scalar:

- Встроенный API-клиент / playground
- Интерактивная документация API
- Тёмная тема из коробки
- Лёгкий деплой
- Интеграции с фреймворками

.NET мог отказаться от Swagger.
Но это может привести к более качественной документации API.

👉 @KodBlog

Что не нужно на старте:

- Kubernetes
- Микросервисы
- Раздельные базы для чтения/записи

Что нужно:

- Юнит-тесты
- Конвейер CI/CD
- Здоровые кодовые привычки
- Монолитная архитектура на старте

«А что, если монолит перерастёт сам себя?»

В этом и идея. Монолит — не навсегда.

Начинаешь с простого.
Дальше эволюционируешь осознанно по мере изменения требований.

Это называется Эволюционная архитектура, и лучше всего это понимается на практике.

4 репозитория на GitHub:

1. Evolutionary Architecture by Example:
https://github.com/evolutionary-architecture/evolutionary-architecture-by-example

2. Booking to Cloud Architecture — монолит:
https://github.com/meysamhadeli/booking-monolith

3. Booking to Cloud Architecture — модульный монолит:
https://github.com/meysamhadeli/booking-modular-monolith

4. Booking to Cloud Architecture — микросервисы:
https://github.com/meysamhadeli/booking-microservices

Отсутствие простоты, а не времени — основной враг в любом проекте.

👉 @KodBlog

State и Strategy в C#: ключевые отличия

Сравнение паттернов State и Strategy в C# с примерами кода бок о бок, ключевыми различиями в поведении и рекомендациями, когда какой использовать.

Читать статью здесь: https://bgh.st/3cce96

👉 @KodBlog

Как использовать enum в C#: объявление, значения и лучшие практики

Разбор использования перечислений в C# с нуля: объявление, задание значений, приведение типов, сравнение, перебор и практики, которые стоит применять в продакшене.

Читать статью здесь: https://bgh.st/djmghy

👉 @KodBlog

required string и string? в EF Core — это не просто разница в синтаксисе, это семантика модели и контракт с базой.

- required string → обязательная инициализация в модели + колонка NOT NULL в БД
- string? → допускает null + колонка с NULL в БД

EF Core использует nullable-аннотации и контекст компилятора, чтобы выводить ограничение целостности схемы. Это напрямую влияет на миграции и поведение трекинга изменений.

Важно: доменную модель нужно задавать явно, а бизнес-ограничения дублировать через Fluent API, чтобы исключить расхождения между кодом и схемой базы.

👉 @KodBlog

Node.js аддоны… на C#? Да.

Native AOT позволяет собирать нативные shared-библиотеки, которые подключаются напрямую через N-API — без node-gyp, без установки Python, без C++-обвязок.

Получается чистая межъязыковая связка через:

* UnmanagedCallersOnly
* LibraryImport
* Span<T>
* zero-alloc UTF-8 маршалинг

Идея — минимальный оверхед между Node.js и нативным кодом при сохранении управляемого кода на C#.

Блог: https://ift.tt/2mz8B1E

👉 @KodBlog

Идемпотентность — одна из тех вещей, о которых не думаешь, пока один и тот же запрос не выполняется дважды.

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

Для этого используется идемпотентность.

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

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

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

Повторы останавливать не нужно. Нужно исключить повторное выполнение одной и той же операции.

👉 @KodBlog

CQS и CQRS — это одно и то же?

Не совсем.

CQS (разделение команд и запросов) — это принцип:

команды изменяют состояние, ничего не возвращают

запросы возвращают данные, не изменяют состояние

он применяется на уровне методов и относится к намерению, а не к жёстким правилам.

CQRS строится на этой идее уже на архитектурном уровне. Он разделяет модели чтения и записи ради масштабируемости, ясности и гибкости.

Хочешь посмотреть, как реализовать CQRS на практике?

Вот как: читать

Большинство приложений уже делают это, даже без прямого упоминания CQRS.

👉 @KodBlog

𝟭𝟱𝟬 вопросов для подготовки к .NET-интервью

ASP .NET Core, EF Core, C# вопросы

👉 @KodBlog

Хочешь уверенно работать с Azure как бэкенд-разработчик на .NET?

Кристи потратил 20+ часов, чтобы собрать «Алфавит Azure для тебя:

• Разобраться в 26 ключевых сервисах и концепциях Azure (без воды)
• Понимать, что делает каждый сервис, когда его использовать и зачем он нужен
• Стартовать путь разработки в Azure

Я его скачал и делюсь с вами! ❤️❤️

👉 @KodBlog

Самый простой способ генерировать PDF-отчёты

Первый выбор — конвертация HTML → PDF.

В большинстве коммерческих проектов используется IronPDF.

Нужен бесплатный вариант:

- Puppeteer Sharp
- headless-версия Chrome

Но ключевая идея важнее конкретного инструмента.

Если есть HTML-шаблон, появляется полный контроль над форматированием.

Можно использовать современный CSS для стилизации HTML-разметки.

Общая схема реализации:

1. MVC-представления и Razor-синтаксис
2. Рендер динамического HTML-контента
3. Передача HTML в PDF-рендерер

Такой подход использовался в нескольких проектах с хорошими результатами.

Нужен пример реализации гибкой PDF-генерации?

Гайд: тут

👉 @KodBlog