.NET *

redb.Identity получил WS-Trust фасад: Issue, Validate, Cancel, Renew на тех же маршрутах ядра. Тот же JWT, тот же реестр клиентов, WSDL для генератора.

Когда мы делали gRPC-фасад, тезис был такой: логика redb.Identity живёт в ядре за адресами direct-vm://identity-*, а транспорт это тонкий переводчик поверх них. Второй фасад тезис подтвердил. Но два транспорта, оба современные, оба построенные примерно на одних представлениях о мире, проверяют утверждение мягко. По-настоящему проверяет третий, устроенный принципиально иначе.

Теперь он есть. Рядом с HTTP и gRPC встал WS-Trust: Issue, Validate, Cancel, Renew по SOAP, на те же маршруты ядра, с тем же издателем и тем же хранилищем токенов. Токен, выданный по SOAP, принимается по HTTP и получает там тот же вердикт.

Восемь новых пакетов и REST DSL вокруг прежних 56 глаголов маршрута; из ядра ушёл Newtonsoft.Json. Что ломает мажор и как мигрировать за десять минут.

Готовится четвёртая версия redb.Route, интеграционного движка для .NET в духе Apache Camel. В 3.x была закрыта ширина по паттернам: 56 глаголов DSL, тридцать с лишним коннекторов, свой язык выражений, скомпилированный в IL (в 4.0 он качественно переработан, об этом ниже). 4.0 закрывает то, что вокруг паттернов: как протестировать маршрут без брокеров, как собрать тело сообщения, как читать CSV и Avro, как выставить REST-фасад, как кэшировать ответ сервиса. Восемь новых пакетов, REST DSL внутри HTTP-коннектора, переработанный язык выражений и ядро, которое стало легче, а не тяжелее. За год это первый мажор такого масштаба: не смена номера под несколько ломающих правок, а качественное расширение функционала, и ломающих изменений в нём как раз немного.

Анонс четвёртой версии redb.Core: ссылки грузятся по обращению, уникальность на любом поле, схема обновляется сама. Бесплатно, три СУБД, Free и Pro одинаково.

Готовится redb.Core 4.0. За год это первый мажор такого масштаба: не смена номера, а качественное расширение функционала. Он про три вещи, которые чаще всего просили: ленивая загрузка ссылок между объектами, уникальные ключи на любом поле и обновление схемы базы без ручных действий администратора. Всё вместе, на трёх СУБД сразу и без разделения на «в Free так, в Pro иначе».

Коротко, что изменится для приложения.

Один и тот же артефакт разворачивается монолитом и кластером микросервисов. Те же модули, один дашборд на все воркеры, горячая замена без рестарта контейнера.

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

Обычно эту плоскость собирают заново: Prometheus, Grafana, самописный health-контроллер, скрипт деплоя, чат-бот для рестартов. Времени уходит столько же, сколько на сам распил.

redb.Tsak предлагает другой обмен: плоскость эксплуатации живёт в рантайме, и она одна и та же независимо от того, запущен у вас один воркер или девять. Кластер, дашборд, REST API, CLI, пробы, метрики и трассировка не зависят от выбранной топологии. Вы решаете, как нарезать процессы, а не как их потом обслуживать.

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

JSON, который считает сам себя. Ставишь = в ячейку — и она становится формулой. На диске при этом остаётся обычный JSON, который откроет кто угодно.

Всем привет!

В мае я опубликовал на Хабре первую статью о MarkMello (легкий MD-просмотрщик). Изначальная задача была простой: сделать лёгкое приложение, которое быстро открывает локальный Markdown-файл сразу в режиме чтения.

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

Я сделал этот сайт, потому что исчез другой, который мне нравился. Пять лет спустя у него горстка пользователей, один платящий клиент — и он научил меня большему, чем любой туториал.

В 2017 году я готовился к IELTS, и мне дали совет, который дают всем: смотрите фильмы с субтитрами.

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

Он ничего у себя не хранил. Он собирал встроенные плееры с видеохостингов и делал их доступными для поиска. Это различие имело значение и технически, и юридически, и тогда я особо не задумывался ни о том, ни о другом — мне просто показалось, что это остроумно.

Потом сайт закрылся. Без объявлений, без объяснений. Я несколько лет искал замену и не нашёл.

В 2021 году я решил сделать свой.

В шестой части цикла про создание DSL на C# добавляем Akbura полноценную поддержку IDE.

Разберём Language Server Protocol, синхронизацию документов, immutable snapshots, MSBuild и semantic tokens. Затем посмотрим, почему для Visual Studio я выбрал нативную интеграцию через MEF и Visual Studio SDK, какие проекты помогли разобраться в Editor API и какие полезные возможности Roslyn неожиданно оказались internal.

В конце немного про публикацию расширений в Visual Studio Marketplace и приключения с Azure.

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

Я сделал Location King — игру на спутниковых снимках. Показывается участок съёмки сверху, без подписей, границ и координат. Надо понять, где это, и поставить точку на карте мира. Чем ближе к цели, тем больше очков, максимум пять тысяч за раунд.

Меня зовут Илья Краснопольский, я занимаюсь разработкой в области геоинформатики и градостроительства. Идея простая: сверху местность опознаётся не хуже, чем с земли, просто признаки другие.

Свой gRPC-wire в Route, отсечение props до агрегата в redb.Core, Tsak закрыт по умолчанию, второй фасад у Identity. И 3.7.0, отозванный через день.

За три дня у экосистемы сменилось три номера: 3.7.0, 3.7.1 и 3.7.2. Первый отозван, живой номер 3.7.2. Ниже разбор того, что в этой линии вышло, в порядке зависимостей: интеграционный движок redb.Route, хранилище redb.Core, рантайм redb.Tsak и OpenID-сервер redb.Identity. Все четыре продукта идут на одном номере, 66 пакетов.

Начну с того, почему номеров три.

SOAP никуда не делся. Продаёте авиабилеты, значит ходите в Amadeus, Sabre и Travelport по SOAP. Интегрируетесь с банком, госпорталом, страховым бэкендом, биллингом оператора или почти любым корпоративным продуктом, купленным до 2015-го: там контракт это WSDL, а на проводе <soap:Envelope>. Подписи WS-Security, вложения MTOM, SOAP 1.1 рядом с 1.2, soap:Fault при ошибке: этот мир жив, он приносит деньги и не переезжает на REST по вашей вежливой просьбе.

В .NET вызывать его стало неудобно. WCF как полноценный фреймворк ушёл. CoreWCF есть, но во всех опубликованных версиях висит незакрытая крипто-уязвимость, так что затащить его значит поменять одну проблему на другую. dotnet-svcutil генерит клиент из WSDL на этапе сборки, но это кодогенерация, приклеенная сбоку, а не шаг интеграции. А хостинг SOAP-эндпоинта, WS-Security руками или проводка MTOM обычно заканчиваются кучей конфигурации System.ServiceModel, которую никто не хочет держать.

redb.Route.Soap идёт другим путём. SOAP становится обычным шагом пайплайна в вашем же .NET-процессе. Вызвал сервис, получил типизированный ответ. Поднял эндпоинт, отдал тело маршруту, вернул ответ. Всё in-box: HttpClient, общий Kestrel-хост и System.Security.Cryptography.Xml для WS-Security. Ни WCF, ни рантайма System.ServiceModel, ни уязвимой зависимости, ни отдельного шлюза. Разберём, как это используется и почему нативный коннектор внутри ESB бьёт codegen-клиента или отдельную коробку.

Есть у меня довольно простой автомобильный сценарий. Я сажусь в машину, телефон автоматически соединяется по Bluetooth с магнитолой, а самой магнитоле для навигации, пробок и прочих радостей нужен интернет через Wi‑Fi. Каждый раз доставать телефон, открывать шторку и вручную включать точку доступа мне в какой-то момент окончательно надоело.

Казалось бы, задача на пять минут: поймали подключение нужного Bluetooth-устройства и вызвали системную функцию включения hotspot. Но с недавних пор эту лавочку в Android прикрыли. Обычному стороннему приложению прямого доступа к управлению tethering уже не дают, даже если пользователь сам этого хочет.

В итоге получилось небольшое приложение BlueSpot на C#/.NET, которое делает ровно одну вещь: при подключении к выбранному Bluetooth-устройству включает системную Wi‑Fi-точку и присылает уведомление. Root не требуется, но без небольшого легального извращения в виде Shizuku не обошлось.

В первой части мы успешно вскрыли чёрный ящик LINQ: написали Where вручную, разобрались, как компилятор превращает yield return в конечные автоматы, и посмотрели на методы с частичной буферизацией. Но LINQ был бы не собой, если бы на этом всё закончилось.

Во второй части переходим к «тяжёлой артиллерии» — OrderBy, GroupBy и Join. Эти методы вынуждены нарушить главный завет ленивых вычислений: они материализуют данные в памяти, прежде чем отдать хоть один элемент. Но как именно?

После этой статьи LINQ перестанет быть чёрным ящиком: вы будете точно понимать, сколько памяти съест каждая цепочка методов и в каком порядке следует вызывать эту цепочку.

redb.Identity получил gRPC-фасад: те же маршруты ядра, тот же реестр клиентов, один токен на оба транспорта. Что внутри, как включить, что померить.

Про redb.Identity мы не раз говорили, что он транспортно-агностичен: вся логика живёт в ядре за адресами direct-vm://identity-*, а HTTP это всего лишь фасад поверх них. Звучало убедительно, но проверить это утверждение было нечем. Фасад был ровно один, и «агностичность» оставалась обещанием архитектуры, а не наблюдаемым фактом.

Теперь фасадов два. Рядом с HTTP встал gRPC: те же маршруты ядра, тот же издатель, тот же реестр клиентов, то же хранилище токенов. Один и тот же токен принимается обоими транспортами и получает от них одинаковый вердикт. Про это и статья: что именно появилось, как это включить, и почему оно особенно уместно там, где gRPC уже стал ...

Сортировка строк без компаратора работает не так, как кажется, и заметно дольше.

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

У меня есть несколько статей, в которых я рассказываю о различных особенностях работы коллекций в .NET, например эта и эта. Мы с вами разбирали, как лучше искать в коллекциях, спорили о преимуществах Any и Count в борьбе за тысячные доли секунды. Но все усилия, затраченные на эти микрооптимизации, могут пойти крахом из-за одного неудачного запроса в базу или другой сервис.

На этот раз я предлагаю рассмотреть проблему N+1 запроса.

Стенд работает, а исходников программы ПЛК нет — ни архива, ни резервной копии, ни у эксплуатанта. Есть 4 900 страниц бумаги: распечатка проекта, экспорт экранов, руководство по эксплуатации, сканы схем. Задача — восстановить поведение один в один. Эталоном я сделал руководство, а не распечатку кода, и на этом нашёлся таймер, который держал максимальный ток 5 минут вместо разрешённых 10 секунд. Ниже — как читаются пять тысяч страниц, как выглядит data-driven программа ПЛК (с кусками настоящих файлов) и все 7 расхождений с честной пометкой, чем каждое найдено.

Цена запроса не зависела от того, что ищешь: фильтр стоял над GROUP BY. Теперь отсечение идёт до агрегата, на трёх движках, без единой правки в коде приложения. До 100 раз на диапазоне по дате и в 5,3 раза на полной выборке в MS SQL Server.

Есть класс проблем производительности, который не видно на маленьких данных и невозможно не заметить на больших. Наш выглядел так: запрос искал один редкий номер заказа среди сотни тысяч объектов ровно столько же, сколько поиск, не находящий ничего. Избирательность условия не влияла на время. Совсем.

Причина оказалась в форме сгенерированного SQL. Значения props живут построчно, и запрос сначала сворачивает их в широкую строку через GROUP BY, а уже потом применяет фильтр. Условие стояло над агрегатом, то есть фильтровало результат свёртки, а не колонку. Индексу там зацепиться не за что: к моменту проверки движок уже прочитал и свернул все значения всех объектов схемы. Триграммный индекс по строкам лежал без дела.

В 3.7.1 появился шаг, который ...

Управляйте маршрутами в рантайме сообщением: start, stop, suspend, restart, плюс консюмер, превращающий события жизненного цикла маршрута в сообщения.

Работающая интеграция это не статичная штука. Деплою нужно слить очередь и остановить маршрут, прежде чем новая сборка перехватит управление. Нижестоящий сервис падает, и маршрут, который его долбит, должен отступить, а не громоздить ретраи. Оператору нужно приостановить одну ветку потока, не перезапуская весь процесс. Что-то ломается в три ночи, и дашборд дежурного должен загореться сам, а не потому что кто-то тейлил логи.

Apache Camel решил операционную половину этого давно, паттерном Control Bus: маршрутами управляют, отправляя сообщение на специальный эндпоинт, ровно так же, как двигают любое другое сообщение. redb.Route приносит этот паттерн в .NET, с набором команд Camel, и добавляет то, чего у Camel нет: консюмер, превращающий события жизненного цикла маршрута обратно в сообщения, которые можно роутить.

То есть направлений тут два...

Опрос каталога, ожидание дописи файла, идемпотентность и атомарная запись через temp+rename: файловый обмен как обычный шаг маршрута.

Спросите у любого интегратора, через что реально ходят деньги, и он назовёт файлы. Банк кладёт выписку в каталог на шаре. 1С выгружает заказы в XML по расписанию. Партнёр по EDI шлёт .edi на FTP. Биллинг ночью роняет CDR-файлы на пару гигабайт. Розничная сеть присылает остатки в CSV, потому что так было в 2009-м и никто не собирается это менять. Файловый обмен не «легаси, которое скоро уйдёт», это работающий транспорт, у которого есть ровно одно свойство: он выглядит проще, чем есть.

Проще он выглядит потому, что первая ....