C# *

WireMock.Net умеет мокать gRPC. Но для этого он заставляет разработчика таскать .proto файлы и поддерживать лишнюю конфигурацию. Я контрибьютил в проект несколько месяцев, разобрался в кишках и написал своё расширение WireMock.Grpc.Protobuf

Пакет предлагает gRPC моки через типизированные контракты Google.Protobuf. Получилось короче, надёжнее и заметно удобнее. В статье покажу, почему мой способ удобнее стандартного, как всё устроено под капотом и зачем вашему проекту пакет WireMock.Grpc.Protobuf

Кстати, подобные инженерные разборы, open-source и внутренности .NET я регулярно публикую в Telegram-канале StepOne. Если статья зайдёт — заглядывайте.

Понадобилось научить десктопную программу принимать лицензионные ключи: строка из письма вставляется руками и проверяется без интернета. Во что это вылилось?

Написать систему и эксплуатировать систему — две очень разные инженерные задачи. Первая заканчивается на «работает под нагрузкой». Вторая начинается с вопросов, которые задаёт человек на дежурстве: что упало ночью и как это переиграть? кто нажал force‑stop? можно ли выкатить патч библиотеки, не пересобирая весь рантайм? почему пароль сервис‑аккаунта видно на странице дашборда?

Прошлые релизы нашей экосистемы отвечали на первый вопрос. 3.4.0 — целиком про второй.

Напомню, из чего экосистема состоит: типизированное хранилище redb поверх Postgres/MSSQL/SQLite, интеграционный движок redb.Route (наш ответ Apache Camel под.NET, 30+ коннекторов), рантайм redb.Tsak с дашбордом, hot‑reload и кластером, и сервер идентичности redb.Identity (OIDC/OAuth 2.1). Всё это работает у нас в проде и публикуется пакетами, образами и standalone‑архивами.

В 3.4.0 появились четыре вещи, каждая из которых — про день после деплоя:

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

В статье разберём, как строить конвейеры на System.Threading.Channels: настраивать обратное давление, корректно завершать обработку, не терять исключения и безопасно использовать каналы в ASP.NET Core.

Для своего пет-проекта мне понадобилась удобная система фильтрации, плюс я хотел попрактиковаться в кодогенерации Roslyn. В этой статье продолжаю рассказывать о гибкой фильтрации данных в EF Core на Exression. Расскажу как мне удалось реализовать новые фичи (строгий контракт с фронтом, операторы сравнения, автоматический null-guard) выиграв при этом в производительности в рантайме.

У меня долгое время лежал без дела старый ipad 2. Я захотел его использовать для отображения данных от некоторых датчиков из моего Home Assistant сервера. Но увы, приложение на ipad 2 поставить нельзя, а браузер такой старый, что даже страницу авторизации Home Assistant отобразить уже не может. Я так и не смог найти ни одного удобного варианта решения этой проблемы (вариант удалённого запуска браузера и использования VNC я за удобный не считаю). И тогда я решил это решение создать. Так появился сервис HASFOB (Home Assistant Service for Old Browsers), исходный код которого я выложил на GitHub: https://github.com/FaceHoof/HASFOB Так же я выложил уже собранные версии для Windows и Linux: https://github.com/FaceHoof/HASFOB/releases

Итак, как же работает этот сервис? Сервис авторизуется на указанном Home Assistant сервере с помощью токена, собирает информацию от указанных в конфигурационном файле датчиков и предоставляет простую веб страницу с этими данными.

Вложенный JSON-объект при импорте в таблицу расплющивался в колонку robot.point.x — и вся структура терялась безвозвратно. Разобрался, как сделать это осознанным выбором, а не побочным эффектом. Заодно переписал редактор сырого текста — теперь с подсветкой синтаксиса и поиском.

Каждый день я использую qBittorrent. Это отличный торрент-клиент, стабильный и кроссплатформенный. Наверное, работает лучше чем любой другой торрент клиент. Но интерфейс у него на Qt Widgets, и на Windows 11 он выглядит не нативно(+ лично для меня не хватает некоторых вещей, о которых расскажу в статье)

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

Так, день за днём, через месяц получился WinBitTorrent

В прошлой статье я рассказывал, как мы делаем онлайн IDE для .NET — дизайн, компиляция и запуск приложений происходят прямо в браузере, без сервера. Проект живёт по адресу xaml.io. С тех пор мы много чего добавили, и в какой-то момент у нас стало получаться загружать в IDE довольно крупные .NET проекты — десятки XAML, сотни C# файлов, несколько референсных проектов и пакетов NuGet.

Одна из главных возможностей — это визуальный UI-дизайнер пользовательских приложений. И у него есть особенность: чтобы дизайнер вообще что-то показывал, приложение должно быть скомпилировано, причём в актуальном состоянии. Не «когда-нибудь», а после каждой правки.

Открыли как-то в IDE один реальный проект (FamilyShow — классическое демонстрационное WPF-приложение), поправили одну строку в .cs и 84 секунды наблюдали за анимацией прогресса. С таким UX никакой интерактивный дизайн невозможен.

Сейчас та же правка занимает 5 секунд, а правка XAML-разметки на типичной странице — меньше секунды. В этой статье — как мы к этому пришли, и какие сюрпризы нам приготовили по дороге Roslyn, OpenSilver, WASM и наш собственный код.

Проверить строку регулярным выражением в .NET можно по-разному, но совет всегда один: включите RegexOptions.Compiled или возьмите генератор. Замеры это подтверждают.

А вот подготовка выражения оказалась не там, где её меряют: конструктор занимает 10 микросекунд, а первая же проверка на этом объекте — ещё 1307. Разобрался, куда уходит разница, и заодно нашёл границу, на которой статический Regex.IsMatch резко замедляется.

FrozenDictionary сделан под словари, которые заполняют один раз при старте, а дальше только читают. Замерил на четырёх машинах и трёх рантаймах — разброс вышел от ×0,76 до ×1,9, и зависит он не от версии .NET, а от того, сколько ключей и как они устроены.

Разобрал, куда уходит время в поиске по строке, вытащил из рантайма имена реализаций, которые он подбирает под конкретный набор ключей, и посмотрел в дизасме, за счёт чего Frozen выигрывает — и почему на маленьких наборах проигрывает.

Совместная разработка, и как найти лентяя в команде. История о том как я пришёл к созданию плагина для OpenSource.

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

А чтобы не читать всю статью инструменты можно быстро посмотреть

JETBRAINS MARKETPLACE

VISUAL STUDIO MARKETPLACE

Структура в роли ключа Dictionary — частый случай. Забыл IEquatable — и каждый TryGetValue в 4,4–5,7 раза медленнее, плюс 96 байт в куче на каждый поиск.

Проверил на четырёх машинах и трёх рантаймах, снял дизасм FindValue и разобрал, откуда берутся ровно три упаковки, почему override Equals не спасает и при чём тут хэш record struct. Сам рантайм этот разрыв не закроет — и это не баг.

Всем привет. Я много лет играю в Counter-Strike и тренируюсь, как большинство: захожу в Deathmatch «размяться», играю три катки, тильтую, выхожу. Сервисы статистики при этом исправно сообщают, что у меня просела точность и выросло время реакции. Спасибо, а делать-то что?

Весной я решил собрать себе тренера сам. Сразу пара слов для контекста: я самоучка, в команде никогда не работал, основной опыт — десктопные утилиты и автоматизация, из веба до этого были только админки под собственные инструменты. В CS тоже звёзд с неба не хватаю, Premier в районе трёх тысяч, на FACEIT вообще первый уровень. Так что история будет не про успешный успех, а про то, где я наступил на грабли и что из этого вынес.

Сам сайт делает вот что: подтягивает историю матчей, отдаёт агрегированную статистику LLM, а та разбирает сильные и слабые места и составляет недельный план тренировок, с конкретными картами, режимами и минутами. Отметил выполненное, сыграл новые матчи — план подстроился.

Проект мой, ссылка будет одна и в конце. Статья состоит из трёх частей: сколько это всё стоит в токенах, где модель выдумывает и как я это ловлю кодом, ну и подводные камни DeepSeek API и связки EF Core + SQLite.

Если искать в интернете «мощный DI-контейнер для .NET», почти в каждом списке встретится Autofac. У него заслуженная репутация зрелого и функционального контейнера. На этом фоне Pure.DI иногда воспринимают как узкоспециализированный генератор, который выигрывает в скорости, но должен уступать классическому DI-контейнеру по возможностям.

Сегодня про EF Core migrations и один очень удобный вызов, который локально экономит время, а в production может связать старт приложения, DDL-блокировки и rollback в одну неприятную историю.

В прошлой статье мы разбирали, как сделать работу ИИ-агента предсказуемее: зафиксировать требования в спецификации с помощью Specification-Driven Development (SDD), до реализации описать ожидаемое поведение тестами по Test-Driven Development (TDD), а готовый результат проверить и передать отдельному субагенту на ревью.

У такого подхода есть цена.

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

Полагаться только на свои ощущения в таких вопросах очень опрометчиво. В одном из экспериментов разработчики считали, что ИИ ускорил их примерно на 20%. Замеры показали обратное: с ИИ они работали на 19% медленнее.

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

Что показывают эксперименты, если читать их целиком

Заголовки об ИИ в разработке противоречат друг другу: «на 55% быстрее», «на 19% медленнее», «на 26% продуктивнее». Результаты расходятся, потому что исследования проводились в разных условиях и измеряли разные показатели.

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

Есть таблица GPS-точек. Транспорт шлёт координаты каждые несколько секунд, за сутки набегают миллионы строк, и таблица секционирована по времени. Значит, кто-то должен заранее создавать партицию на завтра и отцеплять партиции старше девяноста дней. Иначе в одну прекрасную ночь вставка упадёт с no partition of relation "gps_points" found for row, и это будет ровно в тот момент, когда никто не смотрит.

Каждый C#‑разработчик писал numbers.Where(x => x > 10).Select(x => x * 2) — и удивлялся, узнав, что эта строчка ничего не вычисляет. Цепочка спит, пока мы не начнём перебирать результат.

За этим стоит конкретный механизм — отложенные вычисления, а в его основе лежит обычная фича языка: yield. Разбираем, как устроены ленивые методы LINQ изнутри — от ручной реализации Where без yield до того, во что этот yield разворачивается компилятором.

А вы точно знаете, что происходит под капотом каждый раз, когда пишете .Where(...).Select(...)?

К статье приложен репозиторий с полной реализацией.

Автор объясняет, как он использовал скрипты Roslyn и режим сокетов Slack для проверки и отладки запущенного приложения и взаимодействия с ним.