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

🤩 Фоновые задачи без лишних зависимостей Если вы запускаете фоновые задачи через Task.Run или городите велосипед поверх IHostedService, знакомьтесь с BusyBee. Это небольшая библиотека для in-memory обработки фоновых задач в .NET, которая построена на нативных каналах (System.Threading.Channels). Какую проблему решает Хочется просто поставить задачу в очередь и не думать об управлении потоками, таймаутах и наблюдаемости. Стандартные средства .NET это умеют, но требуют немало бойлерплейта. Hangfire или Quartz — тяжеловато, если нужно только in-memory без персистентности. Что умеет BusyBee Ограниченные и неограниченные очереди с настройкой поведения при переполнении: можно выбросить исключение, подождать, отбросить самую старую или новую задачу. Параллельное выполнение задач с настраиваемым пулом слотов. Глобальные и per-job таймауты. Интеграция с OpenTelemetry для трассировки и метрик. Полная поддержка DI и CancellationToken. Как подключить:

    
        dotnet add package BusyBee{}
    

Регистрация в DI:

    
        builder.Services
    .AddBusyBee()
    .WithUnboundedQueue()
    .WithGlobalJobTimeout(TimeSpan.FromSeconds(30))
    .WithLevelOfParallelism(10);{}
    

Поставить задачу в очередь:

    
        await queue.Enqueue(async (services, context, cancellationToken) =>
{
    var logger = services.GetRequiredService<ILogger<Program>>();
    logger.LogInformation("Обрабатываем задачу {JobId}", context.JobId);
    await Task.Delay(1000, cancellationToken);
}, cancellationToken);{}
    

Каждая задача получает контекст с JobId, временем постановки в очередь и временем старта. Через services доступны любые зарегистрированные сервисы. Ограниченная очередь:

    
        builder.Services
    .AddBusyBee()
    .WithBoundedQueue(capacity: 1000, OverflowStrategy.DropOldest);{}
    

Подключение OpenTelemetry:

    
        builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource(BusyBee.Observability.TracingConstants.TraceSourceName)
        .AddConsoleExporter())
    .WithMetrics(metrics => metrics
        .AddMeter(BusyBee.Observability.MetricsConstants.MeterName)
        .AddPrometheusExporter());{}
    

Обработка ошибок Можно подключить собственные обработчики для сбоев, таймаутов и ручной отмены задач через реализацию интерфейсов IJobFailureHandler, IJobTimeoutHandler и IManualCancellationHandler:

    
        services.AddBusyBee()
    .WithJobFailureHandler<MyCustomJobFailureHandler>();{}
    

BusyBee подойдёт, когда нужен простой in-memory обработчик в фоне без внешних зависимостей и баз данных. ➡️ Репозиторий 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

🏃‍♀️ Уже завтра стартует курс по разработке AI-агентов. Про AI-агентов часто думают, что это просто модная обертка над джпт для пет-проектов. Кажется, прикрутил API к скрипту и типа готово. А вот и нет! Когда дело доходит до прода, начинаются настоящие проблемы.

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

Эту инженерную часть мы и будем разбирать на курсе. Будем учиться интегрировать внешние API, работать с RAG, LangGraph, CrewAI и деплоить всё это так, чтобы работало как часы. Стартуем завтра. Для участия и доступа к программе переходите по ссылке.

📰 Новостной дайджест Свежая газетка у вас на пороге — Хирургия над контекстным меню Windows 11 — Фриланс для разработчиков — Не фриланс для разработчиков — .NET 11 Preview 3 — Обновления безопасности 2026 .NET 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

🔍 ILSpy 10.0: поддержка C# 14, API diff и переход на .NET 10 Вышел крупный релиз ILSpy. Релиз собран на .NET 10, так что перед обновлением убедитесь, что он у вас установлен. Новые языковые возможности Декомпилятор теперь понимает конструкции C# 13 и C# 14. Добавлена поддержка ограничения allows ref struct из C# 13 и extension-членов из C# 14. Также подтянули поддержку InlineArray из C# 12 — на удивление поздно, но лучше поздно чем никогда. Детекция паттернов обновлена до Roslyn 5.0 RTM. Новое в интерфейсе Появился выделенный UI для работы с C# 14 extension-членами. Добавлена навигация по видимой истории — теперь можно перемещаться по посещённым узлам в дереве сборок. Из поставки убрали переводы интерфейса — проект сосредоточился на английском. API diff Одна из самых интересных новинок. ILSpy теперь умеет сравнивать публичное API двух сборок и показывать разницу. Полезно при анализе изменений между версиями библиотек, когда исходников нет. Улучшения декомпилятора Исправлена корректная декомпиляция pre-increment операторов, unmanaged function pointers и локальных функций с параметрами по умолчанию. Улучшено определение record-типов и primary constructors. CSharpConversions получил общие улучшения для правил C# вплоть до версии 9. Дизассемблер теперь поддерживает формат ildasm /caverbal. Пакетная генерация PDB Новый метод GeneratePdbForAssemblies заменил старый GeneratePdbForAssembly — теперь можно генерировать PDB для нескольких сборок за один вызов. Чистка API Удалены устаревшие типы: UnresolvedUsingScope, ToTypeReference, ITypeReference. ResolvedUsingScope переименован в UsingScope. Если вы используете ICSharpCode.Decompiler как NuGet-пакет в своих инструментах — стоит проверить совместимость. Производительность Убрана XML-сериализация из DecompilerSettings — настройки теперь сохраняются быстрее. Важное предупреждение Команда отдельно предупреждает: домен ilspy.org им не принадлежит. Скачивать ILSpy нужно только с GitHub Releases. ➡️ Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

🦾 Надоело чинить «упавших» ИИ-агентов после каждого микросбоя внешних сервисов? Анонсируем старт продаж большого курса по AgentOps. Мы собрали опыт десятков разработчиков и сделали программу, которая учит выводить ИИ в стабильный прод. 🗓 Ждем вас 28 апреля в 19:00 МСК на эфире: «Как эффективно управлять контекстным окном LLM в мультиагентных системах и не сливать бюджет на токены». 👉 Кто вещает и в чем польза? Спикер Кирилл Кухарев (Senior AI Engineer в Raft, спикер AI Conf и Highload++). Он реализовал более 50 коммерческих проектов в GenAI и на вебинаре покажет, как взять под контроль работу нескольких агентов, чтобы они не перекидывали друг другу лишний контекст и не сжигали ваши деньги. В прямом эфире разберем: • Как формируется контекст в LLM при маршрутизации между агентами; • Куда утекают лишние токены и возникает перерасход; • Практические методы: как сжимать историю, грамотно делить задачи, лимитировать передачу контекста и собирать промпты прямо в процессе запроса пользователя. 🔥 Два способа получить максимум: 1. Приходите на вебинар 28 апреля. Дарим участникам промокод на 5.000 ₽ (работает 3 дня после эфира - это шанс забрать курс по самому низу рынка). 2. Выбирайте Инженерный трек. В подарок к нему идет полный доступ к записям и автопроверкам завершенного курса «Разработка ИИ-агентов». 👉 Занять место на вебинаре и стать профи в AgentOps

📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #garbage_collector

👨‍💻 Не показывайте технические ошибки пользователям Когда приложение падает с необработанным исключением, стандартное поведение многих фреймворков — вывести стек вызовов прямо в ответ. Пользователь видит внутренние пути файлов, названия классов, фрагменты кода. Для злоумышленника это готовая карта уязвимостей. Что происходит на практике Допустим, в ASP.NET приложении возникает необработанное исключение. Без явной настройки middleware фреймворк вернёт подробный ExceptionDetails с именем метода, строкой кода и трассировкой стека. Атакующий получает информацию о структуре проекта, версиях библиотек и логике работы приложения без каких-либо усилий. Как это закрыть Правильный подход это перехват всех необработанныъ исключений. Нужно логировать их внутри системы и возвращать пользователю только нейтральное сообщение. В ASP.NET это делается через UseExceptionHandler:

    
        app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var exceptionHandlerPathFeature =
            context.Features.Get<IExceptionHandlerPathFeature>();

        var logger = context.RequestServices
            .GetRequiredService<ILogger<Program>>();

        logger.LogError(exceptionHandlerPathFeature?.Error,
            "Unhandled exception");

        context.Response.StatusCode = 500;

        await context.Response.WriteAsJsonAsync(new
        {
            message = "Something went wrong. Please try again later."
        });
    });
});{}
    

Что здесь происходит: middleware перехватывает исключение, передаёт его в ILogger — туда, где его увидит только команда разработки — и возвращает клиенту простой JSON с универсальным сообщением об ошибке. Никаких деталей реализации наружу не уходит. ILogger пишет в вашу систему мониторинга — будь то Application Insights, Seq, Serilog или любой другой инструмент. Вы по-прежнему видите полный стек вызовов и можете разобраться в причине ошибки. Пользователь при этом получает понятное сообщение, а не технический мусор. Это базовая практика защиты приложений. Она не требует сложной архитектуры, достаточно одного middleware, настроенного в точке входа приложения. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

👀 Смотрим внутрь любой .NET-сборки Бывает, что нужно понять, что делает библиотека без исходников, разобраться в чужом коде или проверить, что именно скомпилировал компилятор. ILSpy решает эту задачу это открытый декомпилятор .NET-сборок, который превращает IL-байткод обратно в читаемый C#. ILSpy открывает любой .dll или .exe и показывает декомпилированный C#-код с навигацией по типам, методам и свойствам. Поддерживает поиск по всей сборке, переходы по гиперссылкам между типами и историю навигации. Visual Studio 2022 и 2026 используют движок ILSpy внутри для F12-навигации по декомпилированным источникам, так что если вы нажимали «Go to Definition» на тип из NuGet-пакета, вы уже работали с ILSpy. CLI-инструмент для Linux, Mac и Windows:

    
        dotnet tool install -g ilspycmd{}
    

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

    
        ilspycmd MyLibrary.dll{}
    

Использование как библиотеки Движок декомпилятора доступен отдельным NuGet-пакетом ICSharpCode.Decompiler. Его можно встроить в собственные инструменты:

    
        var decompiler = new CSharpDecompiler("MyLibrary.dll", new DecompilerSettings());
var code = decompiler.DecompileWholeModuleAsString();
Console.WriteLine(code);{}
    

➡️ Репозиторий 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

❓ Что выведет код с картинки 💡 Подсказка: обратите внимание на конструкцию when. Это не просто синтаксический сахар. ➡️ А ответ тут 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #dotnet_challenge

👨‍💻 Singleton vs Service Locator в Unity Когда проект перерастает пару сцен, рано или поздно встаёт вопрос: как организовать доступ к общим сервисам: звуку, аналитике, данным игрока? Два самых распространённых ответа это Singleton и Service Locator. Разберём, чем они отличаются и когда какой уместен. Singleton Паттерн знаком почти каждому Unity-разработчику. Один экземпляр класса на всё приложение, доступный из любой точки кода:

    
        public class AudioManager : MonoBehaviour
{
    public static AudioManager Instance { get; private set; }

    private void Awake()
    {
        if (Instance != null)
        {
            Destroy(gameObject);
            return;
        }
        Instance = this;
        DontDestroyOnLoad(gameObject);
    }

    public void PlaySound(AudioClip clip) { /* ... */ }
}{}
    

Плюсы: + Просто реализовать + Мгновенный доступ без регистрации + Подходит для небольших проектов Минусы: - Жёсткая связность: классы напрямую зависят от конкретной реализации - Тестировать сложно — нельзя подменить AudioManager на заглушку - При разрастании проекта Instance начинают тянуть отовсюду, и следить за зависимостями становится тяжело Service Locator Service Locator это реестр сервисов. Вместо того чтобы обращаться к конкретному классу, код запрашивает нужный интерфейс у локатора. Сначала создаём интерфейс:

    
        public interface IAudioService
{
    void PlaySound(AudioClip clip);
}{}
    

Реализация сервиса:

    
        public class AudioManager : MonoBehaviour, IAudioService
{
    public void PlaySound(AudioClip clip) { /* ... */ }
}{}
    

Сам локатор:

    
        public static class ServiceLocator
{
    private static readonly Dictionary<Type, object> services = new();

    public static void Register<T>(T service)
    {
        services[typeof(T)] = service;
    }

    public static T Get<T>()
    {
        if (services.TryGetValue(typeof(T), out var service))
            return (T)service;

        throw new Exception($"Сервис {typeof(T)} не зарегистрирован");
    }
}{}
    

Плюсы: + Код зависит от интерфейса, а не от реализации + Легко подменить сервис на заглушку в тестах + Зависимости явно регистрируются в одном месте Минусы: - Если забыть зарегистрировать сервис, то получим исключение в рантайме, а не ошибку компиляции - Чуть больше кода на старте - Без дисциплины реестр может превратиться в свалку Когда что выбирать Singleton оправдан в небольших проектах, где скорость разработки важнее архитектурной чистоты. Прототип, геймджем, или небольшая мобильная игра. Service Locator стоит рассмотреть, когда проект планируется развивать: появляются юнит-тесты, несколько платформ, команда из нескольких человек. Возможность подменить реализацию без изменения потребителей сервиса окупается уже при первом рефакторинге. Оба паттерна решают одну задачу — глобальный доступ к сервисам. Разница в том, насколько легко потом менять и тестировать код. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор