Библиотека шарписта | C#, F#, .NET, ASP.NET 🕘 история названий (1)

Перенос MiniJinja с Rust на Go силами Opus и Codex Около десяти часов работы агента и примерно 45 минут активного участия автора. Так Армин Ронахер оценивает основной перенос MiniJinja с Rust на Go. MiniJinja собирает текст по шаблонам. Он начал с Opus 4.5 внутри Pi, а оставшиеся исправления тестов передал GPT-5.2 Codex. Рабочая среда оставалась той же; Go-реализацию сверяли с сохранёнными результатами тестов Rust-версии. По ходу работы агент отказался от проверок, в которых программа должна завершаться ошибкой: текст сообщений не совпадал дословно. Ронахер вмешался и сохранил эти тесты, изменив способ сравнения сообщений. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека Go-разработчика

Альфа-Банк ищет скиллового коллегу QA Fullstack на C# Полная удалёнка или гибрид в Москве, Питере и Екатеринбурге. Что нужно делать: — Разрабатывать автотесты на C#; — Запускать функциональные, регрессионные и интеграционные тесты, включая API; — Снижать количество дефектов в диалоге с разработкой и бизнесом. Навыки: — Опыт автоматизации на C# и ручного тестирования от года; — Знание API (SOAP, REST), SQL, основ клиент-серверной архитектуры и тест-дизайна. Условия и развитие: — Сильное сообщество QA и C#-разработчиков: можно получить совет и поделиться опытом на митапе и в блоге на Хабре: — Реальная перспектива роста: технический трек развития, в том числе до C#-лида. Оставляйте отклик по ссылке.

🦈 Открытое собеседование на Middle C# | 6 октября, 19:00 МСК Приглашаем на открытое собеседование: Senior C# разработчик проведёт его в прямом эфире. Можно посмотреть, как всё устроено изнутри, и понять, насколько ты готов к такому интервью. Как это будет: 📂 Собеседует Александр Моргунов — Senior C# разработчик, 7+ лет в европейских высоконагруженных сервисах. Отвечает разработчик-доброволец; 📂 Всё как на настоящем собесе: Александр задаёт те вопросы и задачи, которые даёт кандидатам на своих интервью. Заранее их никто не знает; 📂 После каждого ответа Александр даст обратную связь: что прозвучало сильно, а что стоило раскрыть иначе. Так станет понятнее, на что обращают внимание на собесе; 📂 В конце можно задать любой вопрос. Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для C# разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир -> @shortcut_csharp_bot Реклама. О рекламодателе.

📝 Логирование со строковой интерполяцией Логирование c интерполяцией строк один из самых распространённых источников лишних аллокаций в .NET-приложениях. Особенность в том, что код выглядит абсолютно нормально и работает правильно — просто дорого. ⏬ Что происходит с интерполяцией:

logger.LogInformation($"User {userId} logged in at {time}");

⏬ Компилятор разворачивает это примерно в:

logger.LogInformation(string.Format("User {0} logged in at {1}", userId, time));

Строка формируется до вызова метода. Если уровень логирования Information отключён, строка всё равно создаётся, занимает память и тут же выбрасывается сборщиком мусора. ⏬ Структурное логирование решает проблему:

logger.LogInformation("User {UserId} logged in at {Time}", userId, time);

Здесь строка — это шаблон. Аргументы передаются отдельно. Логгер сначала проверяет, активен ли уровень, и только потом форматирует сообщение. Если уровень выключен — аллокации нет вообще. Бонус: структурное логирование позволяет индексировать поля в системах вроде Seq, Elasticsearch, Datadog — вы сможете искать по UserId как по полю, а не парсить текст. ⏬ Начиная с .NET 6 есть ещё лучший вариант через compile-time source generators:

// Генерирует оптимальный код на этапе компиляции:
[LoggerMessage(Level = LogLevel.Information, Message = "User {UserId} logged in at {Time}")]
partial void LogUserLogin(int userId, DateTime time);

Никаких аллокаций, никакого боксинга, максимальная производительность — и всё это без изменения читаемости кода. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

👨‍💻 Не показывайте технические ошибки пользователям Когда приложение падает с необработанным исключением, стандартное поведение многих фреймворков — вывести стек вызовов прямо в ответ. Пользователь видит внутренние пути файлов, названия классов, фрагменты кода. Для злоумышленника это готовая карта уязвимостей. ⏬ Что происходит на практике Допустим, в 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

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

🔐 NuGet: Microsoft меняет сертификат подписи С 23 сентября Microsoft использует новый сертификат для подписи NuGet-пакетов. Если у вас настроен allowlist доверенных сертификатов, сборки могут начать падать с NU3034. Что сделать:

dotnet nuget trust author Microsoft \
9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \
--algorithm SHA256

Старые сертификаты удалять не нужно — они нужны для уже опубликованных пакетов. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news

🤩 Как поймать зависший .NET-сервис Приложение начинает тормозить, запросы зависают, а в логах — ничего полезного? Можно автоматически снять memory dump в момент проблемы и потом разобрать состояние процесса. ➡️ Идея простая:

var task = Task.Run(() => { });

if (!task.Wait(3000))
{
    // ThreadPool, вероятно, перегружен
    // → создаём memory dump
}

➡️ Dump позволяет посмотреть: — какие потоки зависли; — где стоят Task; — что происходит в ThreadPool; — какие объекты находятся в памяти. На Windows для создания dump можно использовать MiniDumpWriteDump, а в Linux — встроенный в .NET createdump. А дальше .dmp открывается в Visual Studio — можно исследовать call stacks, переменные и состояние потоков. 💡 Особенно полезно для production-проблем, которые невозможно нормально воспроизвести локально. 🔗 Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view

⚙️ yield return не бесплатный Итераторы выглядят просто, но работают иначе:

IEnumerable<int> GetIds()
{
    foreach (var item in _items)
        yield return item.Id;
}

Читается как обычный цикл. Но компилятор превращает такой метод в конечный автомат со вспомогательными классами и состоянием. Именно поэтому итераторы такие выразительные — но и именно поэтому они не бесплатны. ❓ Где это становится проблемой На большинстве путей yield return это правильный выбор. Код чище, API удобнее, читаемость выше. Но на горячих путях, где метод вызывается тысячи раз в секунду, повторное создание объектов итератора и дополнительные слои абстракции начинают влиять на производительность. Не катастрофически, но измеримо. ❓ Что делать на критичных участках Если профилировщик показал, что итератор узкое место, есть несколько альтернатив. 🟡 Заполнение буфера, переданного вызывающей стороной:

void FillIds(Span<int> buffer)
{
    for (int i = 0; i < _items.Count; i++)
        buffer[i] = _items[i].Id;
}

🟡 Возврат конкретной коллекции:

List<int> GetIds()
{
    var result = new List<int>(_items.Count);
    foreach (var item in _items)
        result.Add(item.Id);
    return result;
}

🟡 Прямой цикл внутри горячего кода без промежуточных перечислений:

for (int i = 0; i < _items.Count; i++)
    Process(_items[i].Id);

yield return стоит использовать тогда, когда он делает API лучше и код понятнее. Но не стоит считать его нулевым по стоимости. Если участок горячий, то сначала замерьте, потом решайте. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор

💡 Replace, Regex или StringBuilder? Для замены текста в C# есть несколько инструментов. И выбирать их лучше не по принципу «что быстрее», а по задаче. 🔜 string.Replace() — когда ищем конкретный текст:

var result = text.Replace("cat", "dog");

🔜 Regex.Replace() — когда нужен шаблон:

var result = Regex.Replace(
    text,
    @"\d+",
    "#");

Например, заменить все числа на #. 🔜 StringBuilder.Replace() — когда последовательно изменяем большой текст:

var sb = new StringBuilder(text);

sb.Replace("cat", "dog");
sb.Replace("foo", "bar");

var result = sb.ToString();

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