⚡️ Fleet В С Ё

JetBrains убивает Fleet как продукт, но не как технологию: с 22 декабря 2025 его перестанут распространять и команда переезжает в новый инструмент для «агентной разработки» — среды, где код пишут в основном AI‑агенты, а разработчик управляет задачами и ревьюит патчи.

Fleet создавали как эксперимент: лёгкая архитектура, современный UI, свобода от легаси IntelliJ-платформы, и технически он реально удался — его компоненты и UX‑решения уже раскатаны по другим IDE от JetBrains.

➡️ Оригинальный анонс

🐸Библиотека шарписта

#async_news

🌐 Контроллеры без мусора

Пишете API, и в каждом контроллере приходится проверять if (!ModelState.IsValid) return BadRequest(). Скучно копипастить одно и то же. А если контроллеры станут реально чистыми — только маршрутизация и вызов сервиса?

[ApiController] автоматически подключает механизм валидации. Он ищет в DI IValidator<T> для ваших DTO/команд и запускает их до входа в метод контроллера.

FluentValidation делает так, что все ваши AbstractValidator<T> автоматически регистрируются как IValidator<T>.

Настройка за 5 секунд:

// Program.cs
builder.Services.AddControllers()
    .AddJsonOptions(o => o.JsonSerializerOptions.PropertyNamingPolicy = JsonNamingPolicy.CamelCase);

builder.Services.AddValidatorsFromAssembly(typeof(CreateUserValidator).Assembly);

Теперь все ваши AbstractValidator<T> автоматически работают.

Вот так пишется валидатор:

public class CreateUserValidator : AbstractValidator<CreateUserCommand>
{
    public CreateUserValidator()
    {
        RuleFor(x => x.Email).NotEmpty().EmailAddress().MaximumLength(256);
        RuleFor(x => x.DisplayName).NotEmpty().MaximumLength(100);
        RuleFor(x => x.Password).NotEmpty().MinimumLength(8);
    }
}

Итоговый эндпоинт:

[ApiController]
[Route("users")]
public class UsersController : ControllerBase
{
    [HttpPost]
    public async Task<IActionResult> Create(CreateUserCommand cmd)
    {
        var user = await _mediator.Send(cmd);
        return CreatedAtAction(nameof(Get), new { id = user.Id }, user);
    }
}

Один раз настроили — наслаждаетесь чистотой контроллеров и валидацией.

🐸Библиотека шарписта

#il_люминатор

👨‍💻 Чистые стектрейсы в .NET с помощью StackTraceHiddenAttribute

В .NET есть простой способ скрыть внутреннюю кухню и оставить только то, что важно потребителю API. Атрибут StackTraceHiddenAttribute помечает методы, которые не должны попадать в публичный стектрейс, при этом логика выполнения не меняется.

Пример:

public static class UserService
{
    [StackTraceHidden]
    private static void ValidateName(string name)
    {
        if (string.IsNullOrWhiteSpace(name))
            throw new ArgumentException("Name cannot be empty");
    }

    public static void CreateUser(string name)
    {
        ValidateName(name);
        Console.WriteLine("Created user " + name);
    }
}

В этом примере при исключении из ValidateName в стектрейсе вы увидите только вызов UserService.CreateUser. Валидационный хелпер скрыт атрибутом, поэтому внешний разработчик не видит внутренний слой проверки.

🐸Библиотека шарписта

#sharp_view

🔄 WSL 2.7.0: обновление с новым ядром

Windows Subsystem for Linux это встроенный слой совместимости, который позволяет запускать Linux и его приложения напрямую без виртуальной машины.

В WSL 2.7.0 ядро обновили до ветки Linux 6.6.114. Параллельно подтянули новые версии WSLg .NET и связанных NuGet пакетов.

Список поддерживаемых дистрибутивов пополнился свежими релизами: Debian 13, Ubuntu 25.10, Fedora 43, а также Kali 2025.3 и декабрьская сборка Arch Linux.

➡️ Релиз на GitHub

🐸Библиотека шарписта

#async_news

🆕 Дайджест недели

Собрали в один пост всё, что произошло за неделю.

— Первое сервисное обновление .NET 10

— Кроссплатформенная SharpIDE

— Fleet В С Ё

Почитать:

— Карьерная «страховка» для IT‑шника

— Как вуз влияет на карьеру

— Закон Брукса в разработке

🐸Библиотека шарписта

#async_news

📊 Рейтинг постов

Вы всю неделю ставили нам лайки, а мы выбрали топ по реакциям:

• 100 RPS Rate Limiting
• Закон Брукса в разработке
• Антиспам в .NET
• FluentValidation в API
• StackTraceHiddenAttribute

Давайте выберем самый лучший пост в голосовании.

Что добавить в следующий спринт? Пишите! 👇

🐸Библиотека шарписта

#entry_point

⚙️ Один обработчик вместо сотни try catch

Когда в проекте десятки эндпоинтов, разъезжающий по коду try catch быстро превращается в свалку. Гораздо проще один раз настроить глобальный маппинг исключений в HTTP статус и возвращать нормальные ProblemDetails для всех ошибок.

ASP.NET уже умеет работать с ProblemDetails из коробки, нужно только включить службу и повесить обработчик ошибок.

В примере вся логика перевода исключений в HTTP ответы живет в одном месте:

builder.Services.AddProblemDetails();

var app = builder.Build();

app.UseExceptionHandler(appErr =>
{
    appErr.Run(async ctx =>
    {
        var ex = ctx.Features.Get<IExceptionHandlerFeature>()?.Error;

        var (status, noscript) = ex switch
        {
            ConcurrencyException => (StatusCodes.Status409Conflict, "Concurrency conflict"),
            NotFoundException    => (StatusCodes.Status404NotFound, "Resource not found"),
            _                    => (StatusCodes.Status500InternalServerError, "Server error")
        };

        ctx.Response.StatusCode = status;

        await ctx.Response.WriteAsJsonAsync(new ProblemDetails
        {
            Status   = status,
            Title    = noscript,
            Detail   = app.Environment.IsDevelopment() ? ex?.Message : null,
            Instance = ctx.Request.Path
        });
    });
});

Любые новые исключения добавляются через одну запись в switch, без походов по контроллерам, а все ответы об ошибках приходят в едином формате application/problem+json, что упрощает жизнь фронту и интеграциям.

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#sharp_view

👨‍💻 Не хватает комментария «Создаёт переменную x равную 10»

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#garbage_collector

🚦 SemaphoreSlim в проде — не просто «асинхронный lock»

SemaphoreSlim часто кидают в код как самое простое решение и успокаиваются. В проде этого мало, ведь малейшая ошибка с Release, областью блокировки или per-key словарем легко превращается в дедлок, гонку или утечку памяти.

Самый частый фейл — банальное «забыли Release». Исключение между WaitAsync и finally и семафор навсегда занят поэтому все будущие вызовы повисают. Помогает только жесткое правило всегда оборачивать WaitAsync в try finally и не вставлять лишний код между ними особенно никакой логики которая может бросить исключение.

Вторая классика — блокировки внутри async кода. Варианты вроде _lock.Wait() или .Result внутри секции под SemaphoreSlim открывают прямую дорогу к дедлокам, потому что блокирующий вызов держит поток, а продолжение ждет этот же поток.

Общий принцип не блокировать внутри асинхронной критической секции если нужно синхронное API выносить его в Task.Run до входа в lock.

Поэтому в проде почти всегда лучше прятать SemaphoreSlim за абстракцией AsyncLock. Обертка с LockAsync() возвращающей IDisposable снимает часть рисков.

📍 Навигация: Вакансии • Задачи • Собесы

🐸Библиотека шарписта

#il_люминатор