Объектно-ориентированный язык программирования
Неограниченный канал спокойно работает до первого замедления потребителя, после чего очередь начинает расти, память — заканчиваться, а фоновый воркер может зависнуть при остановке сервиса.
В статье разберём, как строить конвейеры на 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.
Если у Вас закрались в голову мысли, что один из персонажей не работает, я думаю этот инструмент будет для Вас полезен.
А чтобы не читать всю статью инструменты можно быстро посмотреть
Структура в роли ключа 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 для проверки и отладки запущенного приложения и взаимодействия с ним.
Уважаемые читатели, в этой статье я хочу рассказать о проверке обещанного регресса LINQ в .NET 10 — и представить свои выводы.
В dotnet/runtime с лета висит issue #117717: после перехода на .NET 10 метод с First(предикат) просел к девятке — у автора issue на Intel 13-го поколения до 19%, у Энди Эйерса из JIT-команды на Zen 4 порядка 10%. Причину команда назвала сама: связка PGO и инлайнинга, делегат предиката перестал инлайниться.
Решение тоже озвучили: в десятке чинить не будем — сломаем другое, переносим в .NET 11. Был частичный фикс (PR #117816), после которого issue переоткрыли как #119425. Десятка при этом LTS, и в комментах закономерный вопрос: обновляться на десятку или ждать одиннадцатую.
Уважаемые читатели, в этой статье я хочу рассказать о том, что происходит внутри values.Sum() в современном .NET — там нашлись векторные инструкции, контроль переполнения и список процессоров, которым рантайм намеренно ограничивает ширину вектора, — и представить свои выводы.
В прошлых статьях серии самописные циклы уже проигрывали BCL в поиске по строке, JIT сам выкидывал проверки границ, а foreach прятал аллокации. Тут случай интереснее: values.Sum() — это LINQ, который при оптимизации первым делом меняют на цикл.
Pure.DI — это генератор кода для внедрения зависимостей (Dependency Injection), который работает на этапе компиляции. Pure.DI развивает идею «чистого DI»: вместо контейнера и рефлексии вы получаете обычный C#‑код, который создаёт композиции объектов. В этой статье — новые возможности из релизов 2.3.5–2.5.1: от union types в роли DI‑контрактов до сценариев внедрения зависимостей без лишних аллокаций.