C# *

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 не обошлось.

Меня зовут Дарья Беляева, я — Tech Lead и архитектор решений на стыке BIM, CDE и Revit API. Мы с коллегой, Андреем Прохоровым, за два месяца с нуля сделали AGR.Checker — плагин для Revit, который проверяет ЦИМ на соответствие требованиям IDS перед сдачей в составе АГР. В этой статье — конкретные инженерные решения, которые легли в основу плагина, и то, с чем мы разобрались при регистрации прав на программу в Роспатенте.

В первой части мы успешно вскрыли чёрный ящик 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 запроса.

Всем привет! Сегодня я расскажу вам свой путь к написанию демона для работы с видеокартами (пока только с Nvidia).

Для начала немного предысториио себе, для меня линукс не новинка, но и не та ОС, с которой я долго взаимодействовал. Я разработчик с коммерческим стажем в финтехе, и с линуксом знаком был ранее только как с очень практичной ОС для серверов. И вот однажды я стал полноценным «линуксоидом», решив перейти к более практичной для кастомизации и гибкой настройки ОС. Выбрал я дистрибутив на основе Арча, а именно CachyOS, как и многие (наверное) я люблю при наличии свободного времени поиграть в игры.

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

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

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

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

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

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

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

В этой статье я покажу, как использовать IAsyncEnumerable в WPF‑приложении для асинхронных операций. Код полностью рабочий, его можно скопировать и запустить.
Для команд используется библиотека Prism (NuGet: Prism.WPF). Если у вас нет Prism, команды можно реализовать вручную, но в примере используется стандартный подход из Prism.

Предположим нам нужно выполнить поиск устройств по протоколу Modbus RTU или любую другую операцию с результатами.

Часто первым решением становится использовать асинхронную операцию или поток в совокупности с событиями для проброса данных. Но тогда нам необходимо будет управлять подписками на события, пробрасывать данные из внешнего потока в основной UI через Dispatcher.Invoke.

В начале пути я, как и многие, использовал асинхронные операции с событиями, методами‑обработчиками и Dispatcher.Invoke для проброса данных в основной поток. Но если данных много и\или они часто меняются, это создает дополнительные сложности. Так же куча событий, делает код более запутанным и менее масштабируемым.

Начиная с C# 8, появилась возможность использовать IAsyncEnumerable, позволяющие реализовать код профессионального уровня с линейной сигнатурой и преимуществами такими как:

Доброго времени суток.

Интерпретатор ESPB временно пока отложил, интерес к нему оказался скромным. Но подошел к глобальной задаче с другой стороны и на этот раз все крутится вокруг Zerotier. Давно обратил внимание на данную платформу, когда то ковырял libzt - sockets поверх сети Zerotier. Это удобно для приложений, которые находятся вне единой локальной сети и должны общаться сквозь NAT. Думаю, многие хотели бы использовать микроконтроллеры (например, ESP32) для IoT-задач, не заморачиваясь со способами доставки информации на сервер и не завися от того, спрятан ли этот сервер за NAT.

Из этой идеи выросли три связанных проекта:

Одни вызовы после OrderBy проходят набор один раз, другие приводят к полной сортировке. По коду разницы не видно.

Давайте проверим счётчиком обращений к компаратору — на четырёх машинах и четырёх рантаймах.

Я работаю в офисе (вспоминается песня "Ленинграда") и моим основным рабочим инструментом уже очень долгое время является Excel. Рискую показаться предвзятым, но на мой взгляд Excel - это лучший продукт Microsoft. И вообще электронные таблицы, как класс приложений, - это абсолютно гениальное изобретение человечества. Наверное многие считают из злом, но давайте пройдемся по фактам:

Перегрузка Span.Sort с компаратором-структурой должна была работать быстрее обычной. Замер показал обратное: памяти она расходует больше всех, а времени тратит больше, чем компаратор-класс — на .NET 8, 9 и 10.

В .NET 11 результат меняется, но не везде.

Прогон OIDF conformance-suite по redb.Identity: как настроить сьют, почему кликали вручную, и какие реальные баги он нашёл, включая утечку телефона в id_token.

Мы были уверены, что profile-claims в нашем OpenID-сервере отдаются правильно. Юнит-тесты зелёные, демо-прогон зелёный, ручная проверка через curl показывала name, family_name, email, всё на месте. Потом мы прогнали сервер через официальный conformance-suite OpenID Foundation, и он показал, что телефон и адрес пользователя лежат в id_token. А id_token уходит третьим сторонам и пишется в логи как доказательство входа. То есть номер телефона пользователя ездил гораздо дальше, чем клиент вообще запрашивал. Это утечка PII, и никакой наш тест её не ловил, потому что мы не знали, что искать.

Про это и статья: как устроен ...

Референсная архитектура движка подбора билетов на redb: канонная модель, Scatter-Gather по трём GDS и ж/д, дерево-маршрут и saga-переоформление в дороге.

Сотруднику нужно долететь до одного города, доехать поездом до другого и вернуться тем же путём. Одна командировка, билеты из разных систем бронирования. А потом он уже в дороге пишет в телеграм: «планы изменились, летим не туда, перебронируй».

Три системы под самолёты (Amadeus, Sabre, Travelport) исторически несовместимы: разные XML-диалекты одного и того же понятия перелёта, выросшие из мейнфреймов 60–80-х, каждый со своими причудами и полями, которых нет у соседа. Плюс отдельная, никак не связанная с ними система бронирования под железную дорогу: свой формат, своя логика мест и классов, ничего общего по структуре с авиационными GDS. Запросить всё это параллельно, свести разноформатные ответы в одно и собрать валидный маршрут по стыковкам уже само по себе задача не для россыпи if и ручных мапперов.

А дальше человек в дороге меняет ...

Слушал подкаст Code of Leadership, выпуск про AI-assisted engineering. Полтора часа про то, как правильно встроить ИИ в разработку: копайлоты, MCP, метрики, место ИИ в SDLC. Разговор хороший, по делу. И где-то в середине проскочил термин, за который я зацепился и с которым хожу уже неделю — shadow AI. Проскочил сноской, в ряду прочих ИБ-рисков, между утечками и комплаенсом.

А я на этой сноске завис. Потому что мне кажется, что она интереснее основного разговора...

Один try/finally внутри метода — и он работает в разы медленнее. Сам блок тут ни при чём, он не выполняет ни одной лишней инструкции.

Причина в решении JIT. В .NET 10 его поменяли — но не для всех методов и не при любых настройках.

Если вы поставляете товар в крупную розницу, возите грузы для 3PL-оператора, шлёте платёжные извещения банку или обмениваетесь медицинскими транзакциями X12 — вы почти наверняка обмениваетесь этими документами по AS2. Заказ (EDI 850), счёт (810), уведомление об отгрузке (856), платёжное авизо (820) уходят партнёру не почтой и не через REST, а как подписанный и зашифрованный S/MIME-конверт поверх HTTP, с подписанной квиткой-распиской в ответ. Так работает регламентированный B2B-документооборот в рознице, логистике, финансах, производстве и здравоохранении уже двадцать лет: Walmart, Amazon и их сети поставщиков, банки с host-to-host каналом, автопром, дистрибьюторы — все требуют AS2.

В .NET до сих пор было два пути. Либо коммерческий AS2-шлюз — Cleo, Seeburger, BizTalk — отдельная коробка, отдельная лицензия, отдельная команда сопровождения. Либо Java-сервер с открытым кодом — OpenAS2, Mendelson Community — отдельный JVM-процесс рядом с вашим .NET-бэкендом, со своим inbox-каталогом, откуда документы надо ещё забирать джобой. В обоих случаях AS2 живёт сбоку от вашей интеграции, а не внутри неё.

redb.Route.AS2закрывает этот разрыв: AS2 становится обычным шагом маршрута в вашем .NET-процессе. Приняли конверт от партнёра, расшифровали, проверили подпись, отдали документ в pipeline — провалидировали, трансформировали, положили в Kafka или SQL — и вернули партнёру подписанную расписку. Один процесс, один деплой, одна панель наблюдаемости. Разберём, как это выглядит в коде, где применяется и почему нативный коннектор в ESB выигрывает у отдельного шлюза.