.NET *

Если в современных реалиях у разработчика возникает необходимость собрать надежное решение для обработки G‑кода, он обычно смотрит в сторону готовых вариантов (GRBL/FluidNC/Linux‑CNC), либо пишет свой кастомный парсер на С/С++ или Rust и для таких проектов вариант реализации на.NET даже не рассматривается ввиду того, что платформа является управляемой и потому недостаточно надежной (заслуженно или нет — разберем далее).

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

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

Chunk делит коллекцию на массивы — одна строка кода. Но есть размер чанка, после которого он замедляется в разы при тех же данных и той же памяти. А на массиве и на List<int> внутри разный код, и в самой строке этого не видно.

StringBuilder делит текст на чанки по 8000 символов — вчетверо ниже порога кучи больших объектов. Запас такой, что попасть туда невозможно.

Но чанк на 400 КБ в этой куче возможен и получить его можно разными способами.

Привет, Хабр! Эта статья — часть проекта «20 в 20», в котором мы рассказываем о региональных ИТ-хабах Т-Банка и о том, как в них растут команды и инженерные практики.

Я Дима Фирстов, инженер core-команды Т-Бизнеса из томского ИТ-хаба. Мы занимаемся разработкой общих библиотек и инструментов, которые помогают продуктовым командам работать эффективнее и не изобретать велосипеды. 

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

В статье расскажу о техническом устройстве нашего шаблона — базы для большинства backend-решений на .NET в компании.

Создаю собственный DSL на C#: в этой части добавим инструменты диагностики. Построим инспектор дерева компонентов, научимся изменять состояния и параметры прямо во время работы приложения, подключим метрики через System.Diagnostics и настроим #line, чтобы исключения указывали на исходный .akbura-файл, а не на сгенерированный C#.

Большинство разработчиков привыкли работать с базами данных через специализированные инструменты: кто-то сидит в SQL Server Management Studio (SSMS), кто-то в DBeaver или PgAdmin. Rider же у многих ассоциируется исключительно с написанием кода на .NET, и мало кто задумывается, что в нем можно полноценно закрывать и задачи по работе с хранилищами на уровне бэкенд-разработчика.

ArrayPool используют ради экономии на аллокациях. Но есть размеры, где он делает обратное: массив уходит в LOH, а через new остаётся в нулевом поколении.

Один такой размер зашит в .NET по умолчанию — им копируются потоки. Проверил на четырёх машинах и трёх рантаймах.

ZLinq — замена LINQ без аллокаций. На .NET 8 и .NET 9 время одинаковое. На .NET 10 иначе: массив тот же, но если параметр объявлен как IEnumerable, foreach перебирает его в 2,58–3,89 раза быстрее ZLinq. Причина видна в машинном коде, память замерена отдельно.

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

Коротко о предмете. Заказы приезжают из SAP, под них подбираются водитель и машина с учётом требований к транспорту и к точкам. Рейс идёт по точкам с временными окнами, на точках чек-листы, при выдаче и возврате машины составляются акты с фиксацией повреждений. Сверху — поток GPS-координат, отслеживание рейсов и мест, мобильное приложение водителя и публичный контур, где клиент видит свою доставку.

Пятнадцать модулей, три ноды за балансировщиком, RabbitMQ и Kafka по три ноды, PostgreSQL, Redis из шести.

В документации к PropertyNameCaseInsensitive есть предупреждение про накладные расходы, но не сказано, когда они появятся. Замерил на четырёх машинах, трёх рантаймах и трёх размерах входного JSON: пока через настройки идёт один регистр ключей, флаг не добавляет ничего — 0,92–1,09. Политика именования camelCase тоже.

Разницу до ×4,3 даёт другое: какие ещё написания этих ключей прошли через настройки раньше. Два экземпляра JsonSerializerOptions, созданные через new с одинаковыми полями, делят один кеш имён.

Внутри: пять историй с таблицами по четырём машинам, листинги из dotnet/runtime, предел кеша в 64 записи и веб-настройки, на которых эта разница не видна.

.NET Matrix — это новый открытый проект, который сравнивает .NET-библиотеки внутри одной категории по трём аспектам: возможности, скорость и использование памяти. Все сравнения воспроизводимы: сценарии, тесты сценариев, отчёты и параметры окружения лежат в репозитории, а полный прогон запускается одной командой.

Разбираем систему управления транспортом — TMS. Заказы приезжают из SAP, под них подбираются водитель и машина с учётом требований, рейс идёт по точкам с временными окнами, на точках чек-листы, при выдаче и возврате машины — акты с фиксацией повреждений. Сверху поток GPS в партиционированные таблицы, отслеживание рейсов и мест, мобильное приложение водителя и публичный контур, где клиент видит свою доставку. Пятнадцать модулей, три ноды за балансировщиком, RabbitMQ и Kafka по три ноды, Redis, PostgreSQL, отдельный сервер идентичности.

Систему стали писать, когда TMS покупали как услугу у внешних поставщиков и риски выросли: собственная разработка оказалась способом вернуть управляемость ключевым процессом. И написали быстро — системе год и четыре месяца, первый коммит в апреле 2025-го. Это не легаси из нулевых, а молодой проект, который уже успел обзавестись инфраструктурным слоем и уже начал его разбирать.

Команда была ....

Разбираем систему управления транспортом — TMS. Не игрушечную и не с конференции: заказы приезжают из SAP, под них подбираются водитель и машина с учётом требований к транспорту и к точкам, рейс идёт по точкам с временными окнами, на точках — чек-листы, при выдаче и возврате машины составляются акты с фиксацией повреждений. Сверху — поток GPS-координат в партиционированные таблицы, отслеживание рейсов, мест и контрагентов, определение присутствия по WiFi. Плюс мобильное приложение водителя и публичный контур, где клиент видит, где его доставка.

Пятнадцать модулей, три ноды за балансировщиком, RabbitMQ и Kafka по три ноды, Redis, PostgreSQL, отдельный сервер идентичности.

Зачем её вообще стали писать. TMS покупали как услугу у внешних поставщиков, и риски выросли.

Это стоит развернуть, потому что решение принималось не по техническим мотивам. Когда ключевой процесс компании работает на внешнем сервисе, риск считается деньгами: простой, на который вы не влияете; сроки исправлений, которые определяет не ваш приоритет; зависимость от одного поставщика при смене условий. Пока риск невелик, покупать дешевле, чем строить. Когда он вырастает — арифметика переворачивается, и собственная разработка становится способом вернуть управляемость, а не способом сэкономить.

Систему забрали себе.

И вот главное ...

Сегодня про background jobs в .NET: Hangfire, Quartz.NET, Worker Service и тот неловкий момент, когда job “почти точно выполнилась”, но система не уверена.

Снаружи все выглядит спокойно: задача ушла в фон, worker что-то сделал, retry настроен, lock вроде есть. А внутри остается неприятный вопрос: внешний эффект уже произошел или job просто упала до записи статуса?

Разберем без магии: почему retry не равен идемпотентности, чем lock отличается от dedup, зачем нужен operationId и что делать, когда повторный запуск может превратиться во второй счет, второе письмо или повторное изменение статуса.

В прошлой статье я разбирал платёжную платформу с точки зрения сметы: три слоя, где уходят человеко‑годы, что можно не писать. Главный вопрос, который она честно оставляла открытым, звучал так: окей, а как это собрать?

Эта статья — ответ. Референсная архитектура: модель учёта, границы транзакций, разбиение на модули, топология кластера, маршруты интеграций и точки восстановления. С кодом и схемами.

Оговорка сразу: это референс‑модель, а не выгрузка из конкретного прода. Код показывает реальный API и рабочие приёмы, но ваша модель учёта будет отличаться — и должна отличаться, об этом ниже отдельно.

Стек: типизированное хранилище redb поверх PostgreSQL, интеграционный движок redb.Route, рантайм redb.Tsak и сервер идентичности redb.Identity. Всё Pro, всё бесплатно на линейке 3.x.

Разговор про финтех‑платформу почти всегда начинается не с той стороны. Обсуждают выбор брокера сообщений, спорят про микросервисы против монолита, рисуют схему БД. А через полтора года выясняется, что команда из двенадцати человек написала полтора миллиона строк, из которых бизнес‑логики — тысяч двести, а остальное это транспорт, ретраи, дашборды, деплой и попытки понять, где ночью застрял платёж.

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

Мы четыре года строим экосистему redb — типизированное хранилище поверх PostgreSQL, MS SQL и SQLite, интеграционный движок, рантайм с кластером и дашбордом, и сервер идентичности с поддержкой OAuth 2.1 и OpenID Connect. Всё это работает в проде, публикуется пакетами и образами, и — важное для этой статьи — все Pro‑возможности бесплатны на всей линейке 3.x, без ключей и лицензионного сервера.

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

История о том, как поиск инструмента для исследования торговых стратегий неожиданно превратился в разработку собственного продукта. Рассказываю, чего мне не хватило в существующих решениях, как устроена идея платформы и с какими вопросами я столкнулся уже в первые дни разработки

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

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

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