.NET *

У нас уже подходит к концу лето 2026 года. AI‑агенты, вайб-кодинг, Docker и тонны фреймворков, библиотек и примеров для всех современных платформ. Микросервисы — цель, икона и грааль как в разговорах, так и в требованиях к кандидатам. В одиночку можно быстро поднять работающий проект, подключить к нему ИИ и выложить для использования.

Наконец-то закончилась волна «входа в IT» с бесконечными полусырыми курсами и инфоцыганскими каналами для вайтишников. Как-то поуспокоилось.

Но есть ряд вопросов: Не тратит ли разработчик больше времени, сражаясь с настройками контейнеров для разработки или с тем же Webpack, чем на написание самого кода? Сколько нужно изучить, чтобы написать простое веб-приложение? Каково минимальное количество библиотек и фреймворков для этого? Всегда ли нужны микросервисы?

Именно такие вопросы давно и регулярно всплывали в разговорах с коллегами и для ответа на них был сделан небольшой проект — чисто эксперимента ради. О нём я и хочу рассказать. Что-то будет разбираться очень подробно, а что-то пройдём мимо — это не обучение, это результат эксперимента.

Это конспект-статья по итогам построения рекомендательной системы в .NET.

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

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

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

День выдался долгий и по‑настоящему безрадостный. Сегодня произошло то, чего мы больше всего не любим: Туннельный Котик перестал помогать многим людям, и мы, вероятно, потеряли изрядную долю доверия.Больнее всего это ударило по самым старым и лояльным пользователям — тем, кто был с нами практически с самого начала. Брешь всё ещё приходится латать, и заниматься этим придётся не один день.

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

Но раз уж вечер располагает к разговору — самое время ответить на вопрос, который нам регулярно задают: зачем вообще нужен ещё один проект, если есть множество готовых VPN‑сервисов и решений вроде AmneziaWG? Можно в конце концов поднять свой собственный VPN, а кто не умеет — тот, в общем, сам виноват.

В целом всё это верно. За исключением того, что мы решаем совершенно другую задачу.

Интуитивно любой разработчик понимает: чтобы выпуски проходили спокойно, нужно написать автоматизированные тесты. Чем больше тестов, тем спокойнее проходят выпуски. Или нет?)) В этой статье я поделюсь нашим опытом построения пирамиды тестирования. Надеюсь, что она понравится читателям и станет первой из цикла статей об автоматизированном тестировании. Нам есть что рассказать!

Отчёт пользователя вскрыл утечку между диалогами в query-провайдере ядра — 6 из 6. Что ещё в 3.6.0: AS2/EDI, общий Kestrel, Camel-паритет.

Год стек рос на наших собственных задачах: мы писали то, что нужно было нам, и проверяли на своей проде. С весны им начали пользоваться посторонние люди — и характер входящих сообщений изменился. Вместо «а поддерживаете ли вы X» приходят разборы: воспроизведение, номера строк в наших исходниках, обходные пути, которые человек уже написал у себя, пока ждал ответа.

Это самое ценное, что может ...

В этот раз я пришёл с двухчастным текстом про F#, тайппровайдеры, скрипты, спортивное программирование, MVU, консольные интерфейсы в стиле FarManager, низкоуровневый интероп с виндой, некоторое количество хаков ХМ и, внезапно, живопись. Причём только консольные интерфейсы с некоторой натяжкой можно назвать центральным элементом повествования, поэтому я понятия не имею, как должен выглядеть потенциальный читатель этой статьи. Будем исходить из предположения, что он либо достаточно опытен, либо у него достаточно времени и усердия, чтобы расковырять всё, что я не счёл должным разобрать детально (я могу, но только за 16 глав).

Сегодня мы изучим небольшой .fsx-скрипт, который я ежедневно запускаю, чтобы получить очередную порцию задачек из архива codeforces.com. Необычно то, что скрипт функционирует как полноценное GUI-приложение, пусть и очень страшное старое. Кажется, что до меня так никто не делал, так что с осторожностью назову это авторской инновацией.

Если вы поставляете товар в крупную розницу, возите грузы для 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 выигрывает у отдельного шлюза.

Однажды в проде контейнеры одного из сервисов начали падать по OutOfMemory. Контейнерам было выделено по 4 ГБ оперативной памяти, нагрузка была вполне обычной: десятки страниц в секунду.

Расследование показало, что проблема была в JSON-конфиге.

Схема была стандартная. В базе данных хранился JSON. При запросе приложение доставало его из базы, выполняло дополнительную обработку — заполнение вычисляемых полей, обогащение справочниками — и сохраняло результат в Redis. Подавляющее большинство пользователей запрашивало один и тот же JSON и ходило за ним в Redis.

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

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

Но всё оказалось интереснее…

Выходит обновление плагина, он дописывает свои ключи в ваш конфиг и заодно меняет порядок остальных. Через сутки в дискорде жалобы, вы открываете бэкап и текущий конфиг в diff — а он красный целиком. Разбираемся, почему текстовый diff врёт на JSON, и что с этим можно сделать: сравнение с игнором порядка ключей, структурный дифф по путям, до шести файлов сразу и экспорт в JSON Patch.

Офлайн-хранилище со сложным графом и outbox: быстрый старт в MAUI и в браузере, базовые операции и почему в этой роли EF Core только мешает.

Курьер спустился в подвал склада — связи нет. Кладовщик третий час принимает поставку в зоне, где вайфай добивает через раз. Пользователь заполнил форму на четыре экрана и нажал «Сохранить» в момент, когда сервер уехал на деплой.

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

И вот тут начинается знакомое.

Если в современных реалиях у разработчика возникает необходимость собрать надежное решение для обработки 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. Причина видна в машинном коде, память замерена отдельно.