C# *

«Это написал Клод» — комментарий из-за рубежа, и почему идее хранилища больше двадцати лет (даже если так было бы, то клод выпивая тонные кофе это всё родил ...)

Под англоязычной версией статьи про SQLite-провайдер на dev.to появился комментарий в духе «даже без "load-bearing" и тире через всё предложение видно, что это писал Клод». Не первый раз слышу что-то подобное, так что решил ответить не в комментариях, а отдельным постом заодно расскажу то, что давно собирался: откуда вообще взялась идея хранилища, на котором всё это стоит.

Сначала честно про долю ИИ

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

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

А теперь откуда это всё вообще взялось

Основная идея хранилища не изобретение последних месяцев. Первая версия появилась в 2004 году, когда я писал на Delphi за двадцать с лишним лет до того, как Клод вообще начал существовать.

Задача была дать объекту динамические поля на ходу, не фиксируя их жёстким классом заранее. Delphi для этого уже нёс нужный кусок RTTI (Run-Time Type Information): каждый класс несёт метаданные о своих полях и свойствах, доступные в рантайме, не только на этапе компиляции. Поверх этого интерфейс IDispatch из COM: GetIDsOfNames резолвит имя поля в DISPID, Invoke вызывает по этому DISPID, передавая значение через VARIANT. Вместе это давало то, чего не даёт обычный жёсткий класс: объект мог обзавестись полем, которого не существовало на момент компиляции, а вызывающая сторона спросить о нём по имени и получить настоящий типизированный ответ.

Система прожила у меня внутри собственных проектов много лет, никуда не публикуясь. За это время она полностью пережила Delphi и COM переехала на .NET, механизм сменился до неузнаваемости (никакого VARIANT, никакого DISPID сейчас это типизированные колонки в Postgres/MSSQL/SQLite, которые я уже разбирал построчно в статье про 13 таблиц), а вопрос остался ровно тем же: как дать объекту гибкий набор полей, не потеряв возможность спросить "а какого оно вообще типа".

Отсюда, кстати, и название RTTI-based storage, не маркетинговый термин, а прямое родство с тем самым механизмом Delphi. И не EAV там никогда не было обезличенной колонки "значение", RTTI всегда знало настоящий тип.

Клод помогал полировать это перед тем, как это увидело свет публично. Сама идея и её первое воплощение старше Клода на десятилетия.

Цикл про redb:

• redb — типизированное хранилище для .NET поверх Postgres/MSSQL: без миграций, без Include, с полным LINQ

• REDB изнутри, статья 1: 13 таблиц, на которых работает всё

• Анатомия SQLite-провайдера: уходим от EF Core — статья, под которой появился тот самый комментарий

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

Как redb хранит сложные объекты: не бесхемная свалка, а RTTI

Про redb (RedBase) есть два зеркальных заблуждения. Первое: раз объект пишется «как документ», внутри лежит сериализованный JSON или блоб. Второе, противоположное: раз всё падает в общую таблицу значений — значит это плоский мешок пар «ключ-значение» без схемы.

Оба мимо. То, что внутри — это RTTI, полноценная система типов, живущая в самой базе. И устроена она заметно сложнее, чем и блоб, и «атрибут-значение». Разбор архитектуры я подробно давал в отдельной статье на Хабре: «redb: реляционное хранилище объектов» — ниже сжатая суть.

Слой типов: база знает настоящий тип каждого поля

redb хранит не только данные, но и их описание типов — три связанных уровня:

• types — реальные дескрипторы типов (db_type и соответствие .NET-типу);

• _schemes — сами типы (классы), с поддержкой наследования через self-reference;

• structures — типизированные поля схемы: имя (name), тип (_id_type, FK на types), признак коллекции (collection_type) и вложенность (_id_parent).

Значения в values всегда привязаны к конкретной структуре (id_structure, FK на structures). Поэтому строка values — это не безымянная пара «атрибут-значение»: это значение известного, именованного, типизированного, возможно вложенного поля известного класса. База в рантайме знает, что перед ней — decimal Salary в схеме Employee, а не абстрактный «атрибут №42». Это и есть RTTI.

Хранение коллекций: построчно, реляционно

Вложенные массивы, словари и глубокие иерархии redb раскладывает в _values построчно, а не строкой:

• Никаких JSON-блобов на диске. Каждый элемент коллекции — отдельная строка с типизированными колонками (_value_long, valuestring, valuedatetime, valueguid, …), внешними ключами и обычными индексами.

• Связь и порядок — реляционные. Вложенность собирается self-reference колонкой arrayparent_id (FK на values.id, ON DELETE CASCADE). Порядок массива и ключи словаря — в arrayindex (text: '0','1','2' для массивов, строковый ключ — для словарей).

• Один элемент — одна строка. List<OrderItem> внутри класса не превращается ни в JSON-поле, ни в десяток физических таблиц, которые вы заводите руками.

Что это даёт на практике

1. Честный LINQ на уровне СУБД. Данные лежат в типизированных колонках, а метаданные структур позволяют движку собрать нативный SQL: Where / OrderBy / GroupBy / оконные функции идут по реальным индексам базы, а не перебором JSON в памяти бэкенда.

2. Загрузка за один запрос без каскада JOIN-ов. Чтобы поднять объект со всей глубиной вложенности (пусть там 20–30 списков), не нужен каскад JOIN, как у EF с .Include(). Плоская структура забирается из _values одним запросом и собирается в объект в памяти.

3. Точечный Change Tracking (Pro). При сохранении Pro-версия строит деревья ValueTreeNode (память против БД), сравнивает их (ValueTreeBuilder / ValueTreeDiff) и шлёт UPDATE только по изменившимся узлам — граф целиком не перезаписывается.

Итог: redb совмещает удобство работы с объектами «как с документами» и фундамент реляционной СУБД — типизацию, индексы, FK и запросы, которые исполняет база, а не бэкенд. Ключ к этому — не блоб и не плоский мешок атрибутов, а persisted-RTTI: types → schemes → structures → values.

Ссылки

• Разбор архитектуры на Хабре:  Локальная база на клиенте · redb — типизированное хранилище

• Архитектура: redbase.app/architecture · Зачем redb: redbase.app/why-redbase

Прямо сейчас я заметил, что моя статья получила дизлайк, и карма упала на два пункта.

На Хабре немало публикаций в духе: «Я попал в Яндекс, смотрите какой я крутой».
В них - ноль пользы и никакой информации.
Другие материалы поражают скомканностью и поверхностностью.

Я заметил любопытную закономерность: чем больше пустых слов и ерунды выливает автор, тем больше лайков он получает. Для примера: свою статью об опыте работы я написал наспех, без особого старания - и она спокойно прошла по показателям. А когда действительно стараешься, вкладываешь силы, результатом становится минус карма.

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

И вот я думаю: стоит ли вообще делиться знаниями на этой площадке, если здесь хватает людей, которые портят атмосферу? Может, есть достойные альтернативы Хабру?

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

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

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

Хочу осветить эту проблему хотя бы пока есть карма.
Уже видно, как работает эта система.

Ты, читатель, знаешь, сколько труда стоит такой материал?
Сколько сил уходит на его подготовку?
И если ты думаешь, что это сгенерировано ИИ - то ошибаешься.
Настоящая работа всегда отличается от «сырых» статей без структуры.

Если считаешь себя крутым рецензентом - напиши свою статью.
Покажи, что можешь лучше, а я посмеюсь, как ты ни строчки сделать не сможешь.

Бенчмаркая CSE: подстава на uint — деление считается дважды

Уважаемые читатели, в этом посте я хочу разобраться, что компилятор делает с парой / и %, и представить свои выводы.

Возьмём число 47 и делитель 10. Деление даёт 4, остаток — 7. Компилятор деление не выполняет: он умножает 47 на подобранное число и сдвигает, получая 4. Дальше для остатка хватает вычитания: 47 − 4 × 10 = 7. Одно умножение на оба ответа.

Так на int. На uint компилятор получает 4, умножает на 10, вычитает — а потом заново считает те же 4 из 47, вторым умножением.

Ответ верный и там, и там. CSE, common subexpression elimination, находит повторяющиеся вычисления и считает их один раз. Оба умножения в паре считают одно и то же, и на int проход их склеивает. На uint не склеивает — отсюда и обращение в трекер.

int value = ints[i];
total += value / 10 + value % 10;    // одно умножение

uint value = uints[i];
total += value / 10 + value % 10;    // три умножения

Замер на 1 024 значениях, .NET 10, три машины. Значения положительные: у знакового деления отрицательные идут другой веткой.

Из таблицы можно сделать выводы:

• на int пара занимает столько же времени, сколько одно деление, на uint — вдвое больше;

• беззнаковое деление быстрее знакового в 1,54–1,60 раза: знаковому нужна коррекция для отрицательных значений;

• проседает не тип, а пара операций.

Вот как это выглядит в машинном коде, Xeon W-2255. У int одно умножение на всю пару:

mov      edx, 0xD1FFAB1E      ; подобранное число
imul     edx:eax, r9d         ; единственное умножение, вышло 4
sar      edx, 2               ; деление готово
lea      edx, [rax+4*rax]     ; 4 x 5
add      edx, edx             ; ещё x2, вышло 40
sub      r9d, edx             ; 47 - 40 = 7, остаток

У uint то же самое, но в конце деление идёт второй раз:

mov      r10d, 0xD1FFAB1E     ; то же число
imul     r10, r9              ; первое умножение, вышло 4
shr      r10, 35              ; деление готово
imul     r10d, r10d, 10       ; второе: 4 x 10 = 40
sub      r9d, r10d            ; 47 - 40 = 7, остаток
mov      r10d, 0xD1FFAB1E     ; снова оно
imul     r8, r10              ; третье: те же 4 заново
shr      r8, 35               ; и тот же сдвиг

Были проверены ещё три случая, разницы между int и uint в них нет. Делитель 16, степень двойки: деление сводится к сдвигу, остаток берётся из младших битов, умножений ноль у обоих. Делитель в переменной: работает машинная команда деления, она выдаёт оба ответа разом, 2 714 против 2 716 нс. Тип ulong: на .NET 8 и .NET 9 было три умножения, на .NET 10 осталось одно, а у uint три.

Что делать на практике:

• в горячих циклах вроде разбора числа по цифрам, форматирования и хэшей пара идёт на каждом витке, а с ней и лишнее умножение;

• Math.DivRem возвращает к одному умножению: быстрее пары в 1,13–1,76 раза. Внутри для uint то же вычитание:

// dotnet/runtime, Math.cs

public static (uint Quotient, uint Remainder) DivRem(uint left, uint right)
{
    uint quotient = left / right;
    return (quotient, left - (quotient * right));
}

• вычитание, записанное явно, value - value / 10 * 10, быстрее пары в 1,23–1,80 раза — для тех, кому не нужен кортеж из Math.DivRem;

• на int менять нечего: там деление с остатком уже собрано в одно умножение;

• лишнее умножение забирает часть того, что uint даёт на делении, но не всё: на разборе числа по цифрам он остаётся быстрее int — 0,81–0,86.

Проход описан в документации: Common Subexpression Elimination, код в optcse.cpp, реализация Math.DivRem — в Math.cs. Обращение открыто с августа 2025, help wanted: dotnet/runtime#119131. Замеры, отчёты и листинги: DivRemProof.

Всем удачи и до новых встреч!

Добавил "галерею фишек" и документацию для акбуры, разумеется галерею написал на самом кастомном dsl

• Репозиторий

• Документация

• Галерея

Первая версия генератора кода готова. Сделал я его через IIncrementalGenerator и она очень сильно не оптимизирована, но да ладно он мне все ровно нужен был только ради следующей статьи про диагностику dsl

Прогнал официальный conformance suite OpenID Foundation против redb.Identity.

Basic OP: 35 модулей, 0 failures. Config OP: 0 failures.

Что нашли и исправили:

• PII утечка: scope-derived claims (phone, email) попадали в id_token — они должны быть только в UserInfo

• UserInfo возвращал внутренности OpenIddict через deny-list

• Отсутствовал Cache-Control: no-store на token endpoint (RFC 6749 §5.1)

• prompt=login / max_age ре-аутентификация была сломана

Одно WARNING осталось намеренно — два приватных claim в id_token с обоснованием.

Полный отчёт

Cтaтья «BotSharp изнyтpи: ищeм cлaбыe мecтa в кoдe ИИ‑плaтфopмы нa.NET»

Пpинятo cчитaть, чтo в AI и ML бeз Python никyдa, a.NET — этo иcключитeльнo иcтopия пpo enterprise, вeб‑paзpaбoткy и гeймдeв. Ho пpoeкт BotSharp гoтoв пocпopить c этим cтepeoтипoм, пpeдлaгaя ИИ‑плaтфopмy нa экocиcтeмe Microsoft.

Mы peшили зaглянyть пoд кaпoт BotSharp и пpoвepить, какие ошибки есть в его иcxoдном кoде.

Облачный сервис с безграничными возможностями: Бот или не бот - вот в чем вопрос.

Друзьям и коллегам, привет!

Недавно опубликовал на Хабр новую статью с разбором моего Web3-мессенджера. В ней описал личный кейс: как внедрить децентрализованные Web3 технологии и монетизировать внутренние функции приложения без подключения классических платежных систем. Почитать можно здесь: https://habr.com/ru/articles/1052088/

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

Создав так называемых "юзер-ботов" (user-bots), я снабдил платформу дополнительными функциями. В моей реализации такой "Бот" - это полноценный внешний сервис, который имеет точку входа - Endpoint на стороннем облаке и строгий протокол взаимодействия через его API.

В таких популярных приложениях как Telegram или WhatsApp, боты представляют собой отдельные сущности, которые привязываются к основному аккаунту пользователя. Кстати, вопреки расхожему мнению, один аккаунт в Telegram может создать через BotFather не безграничное число ботов, а строго до 20 штук (до 40 для Premium-пользователей).

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

Хотя при таком методе не получится создать «армию ботов» на один аккаунт. На каждого бота придется заводить новый. Но с точки зрения безопасности и чистоты архитектуры плюсы очевидны:

• Полный контроль и безопасность окружения: бот изолирован и работает строго в рамках правил реального пользователя.

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

• Готовая монетизация: в профиле каждого пользователя уже прописаны платежные данные в виде Web3-кошелька. Соответственно, они автоматически доступны и боту, если тот реализует платные услуги.

РЕАЛИЗАЦИЯ НА БЭКЕНДЕ

Ниже упрощенный код класса реализующий передачу сообщений на Endpoint:

public async Task<string> ExecuteCommand(string cmd, string uid, string token, string url)
{
    using var client = new HttpClient();
    client.DefaultRequestHeaders.Authorization = new ("Bearer", token);
    
    var body = new StringContent(JsonConvert.SerializeObject(new { data = cmd, user_id = uid }), Encoding.UTF8, "application/json");
    var res = await client.PostAsync(url, body);
    var json = JObject.Parse(await res.Content.ReadAsStringAsync());

    return json["success"]?.Value<bool>() == true 
        ? json["data"]?.ToString() 
        : $"Error: {json["error"]}";
}  

Рабочий шаблон внешнего Endpoint сервиса:

<?php
session_start();
header('Content-Type: text/html; charset=utf-8');

//AUTHENTICATION BEGIN

$allowedToken   = 'super-secret-token';
$providedToken  = '';

if (isset($_SERVER['HTTP_AUTHORIZATION'])) {
    if (preg_match('/Bearer\s+(.+)/i', $_SERVER['HTTP_AUTHORIZATION'], $m)) {
        $providedToken = trim($m[1]);
    }
}

if (empty($providedToken) || $providedToken !== $allowedToken) {
    echo json_encode(['success' => false, 'error' => 'error token']);
    exit;
}

//AUTHENTICATION END

$rawInput = file_get_contents('php://input');
$userData = json_decode($rawInput, true); 

echo json_encode(['success' => true, 'data' => 'Bot answer: ' . $userData['data'] ?? null]);

?>

ВЫВОД

Используя описанную концепцию, можно в теории реализовать любой сервис не изменяя при этом основное приложение. Всё что нужно сделать, построить бот!

Очевидно, что для практического применения такого подхода необходимо обеспечить высокий уровень безопасности: внедрить защиту от SSRF (через валидацию URL и фильтрацию локальных хостов), настроить лимиты для предотвращения DoS-атак (проверяя размер заголовков и длину полученной строки), и так далее.

Всем успехов в разработке!

Благодарю за внимание.

Великий потоп приближается
Раннее демо мобильной GPS-игры «Великий потоп» (The Great Flood) от студии Александра Кубора. Игра основана на реальной карте мира.

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

Одна из игровых механик — аномальные пузыри. Это области с нестабильным GPS-сигналом, способные повредить судно игрока, но именно в них можно найти редкие артефакты.

Некоторые технологические особенности проекта:

• Собственный картографический движок и формат геоданных, оптимизированные для мобильных устройств. Участок карты размером около 2 км занимает примерно 50 КБ и подгружается с сервера по мере перемещения игрока.

• Процедурная генерация геометрии в Unity. Вдохновившись подходами Houdini, мы разработали систему визуальных нод, которая позволяет автоматически преобразовывать дороги и элементы окружения в стилизованную игровую геометрию.

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

Следи за весточкой, путник. Пророчество только начинается...

Мой ТГ канал: https://t.me/cuborlive/55

SQLite-провайдер для RedBase — скоро.

Тот же API что PostgreSQL и MSSQL. Без миграций, полный LINQ, типизированные колонки.

Free: нативное расширение (.so / .dll / .dylib).
Pro: чистый C# — работает в Blazor WASM.

Минимальная версия SQLite 3.44.0+.

Всем привет.

У меня два вопросах к подобным мне разработчикам open source, живущим в России.

1. Как вы осуществляете поддержку своих проектов?

   Я - через github и свой дискордик. Не похоже, чтобы блокировка последнего нанесла сильный удар по русскоязычной аудитории. Я наблюдаю целые русскоязычные сервера, которые никуда не делись. И даже не похоже, чтобы поубавили в активности.
   Впрочем, справедливости ради, один человек обратился ко мне за саппортом через steam, поскольку через дискорд не мог.
   В общем, переформулируя вопрос: добавили ли вы новые каналы поддержки после официальной блокировки дискорда?

2. Как вы принимаете донаты?

   Я - через бусти и telegram wallet. Интересно, какие есть ещё простые пути?

Паттерны проектирования еще актуальны?

Вокруг все чаще говорят, что ИИ скоро будет писать код за нас. Логичный вопрос — нужны ли тогда паттерны? Зачем разбираться в паттернах GoF, если нейросеть и так сгенерирует рабочий код по описанию?

У меня ощущение обратное.

Я плотно вошел в разработку в 2019 году. Переходил из 1С в .NET. Книги по паттернам GoF у меня были, но долго лежали как «книга на полке». Казалось, они оторваны от повседневных задач. Теорию вроде понимал, но не видел, где это реально применяется.

Все поменялось, когда я стал использовать ИИ как инструмент для обучения. Просил давать задачи, искать проблемы в решениях, объяснять, почему в одном месте уместен Strategy, а в другом лучше Mediator. Через практику и обсуждение паттерны перестали быть абстракцией.

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

Из этого и вырос мой pet-project gofinsights.com. Я делаю его тренажером по паттернам проектирования. Не просто «прочитал и забыл», а через практику, сравнение решений и постепенное распознавание типовых архитектурных ходов.

Сейчас там есть интерактивный квиз, где можно проверить базу и не перепутать Factory Method с Abstract Factory. Дальше хочу развивать проект в сторону более глубокого ИИ-разбора. Чтобы можно было не только узнавать паттерн, но и разбирать кодовые запахи, причины проблем и возможную эволюцию решений.

Как вы это видите? Паттерны проектирования все еще рабочая база для разработчика? Или с появлением ИИ они станут менее важны?

ИИ что? Проверяем Semantic Kernel

Проекты, связанные с интеграцией искусственного интеллекта, всё чаще становятся частью повседневной разработки. Один из таких проектов — Semantic Kernel. Он представляет собой SDK для построения AI-агентов и оркестрации LLM-сценариев и активно развивается компанией Microsoft.

Однако под капотом даже самых современных решений скрывается вполне обычный C# код со всеми присущими ему проблемами. Поэтому мы проверили проект и написали статью о самых интересных ошибках в коде Semantic Kernel.

Представлен открытый проект Winhance. Это приложение на C#, предназначенное для удаления лишних программ, оптимизации и настройки работы с Windows 10/11 - от управления программным обеспечением до оптимизации и настройки системы,

Winhance включает в себя большинство тех же улучшений, что и UnattendedWinstall, но без необходимости чистой установки Windows.

Всё, что нужно знать для начала работы в PVS-Studio

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

🚀 Бесплатный курс для разработчиков: создаём свой язык программирования!

Приглашаем вас пройти наш курс и разобраться, как устроены языки программирования изнутри.

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

Этот курс подойдёт разработчикам, которые хотят выйти за рамки повседневной разработки и глубже понять фундаментальные принципы работы кода. Да, примеры будут на C++, но сам материал гораздо шире и будет полезен программистам с любым стеком. Независимо от того, пишете вы на C++, C#, Java или любом другом языке, понимание внутренней архитектуры языков сделает вас сильнее как инженера.

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

Вы увидите, как текст программы превращается в структуру, понятную машине, и поймёте, какие решения стоят за этим процессом.

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

Мы постарались сделать материал одновременно понятным и практико-ориентированным: минимум абстракции ради абстракции — максимум смысла.

Если вы хотите лучше понимать, что происходит "под капотом" программирования и прокачать инженерное мышление — этот курс для вас.

👉 Подробности и доступ к курсу по ссылке.

Присоединяйтесь и изучайте программирование глубже — бесплатно!

Статический анализ генерируемой OpenApi-разметки и .NET 10

Привет, Хабр! 👋 На связи Саша Кузнецов, ведущий инженер-программист в Контуре.

Начиная с версии .NET 10 Microsoft решила поломать обратную совместимость в отношении статических анализаторов генерируемой OpenApi-разметки.

[HttpGet("{id}")]
[ProducesResponseType<User>(StatusCodes.Status200OK)]
[ProducesResponseType(StatusCodes.Status404NotFound)]
public async Task<IActionResult> GetUser(int id)
{
    var user = users.FirstOrDefault(p => p.Id == id);
    if (user == null)
        return NotFound();

    return Ok(user);
}

Раньше можно было возвращать IActionResult, или ActionResult, размечая типы ответов специальными атрибутами типа ProducesResponseType (см. код 1). Это позволяло включить потом статический анализатор добавлением в настройки проекта специального атрибута IncludeOpenAPIAnalyzers (см. код 2) и получать предупреждения на этапе компиляции, или статического анализа кода (см. код 3).

<PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <IncludeOpenAPIAnalyzers>true</IncludeOpenAPIAnalyzers>
  </PropertyGroup>

Увы, но с выходом .NET 10 этот подход был объявлен устаревшим (см.: https://learn.microsoft.com/ru-ru/aspnet/core/breaking-changes/10/openapi-analyzers-deprecated и https://github.com/aspnet/Announcements/issues/521). Microsoft решила сосредоточиться на работе через Results (см. код 4), которые появились в .NET 7. В них статический анализ поддерживается "из коробки" из-за строгой типизации.

[HttpGet("{id}")]
public async Task<Results<Ok<User>, NotFound>> GetUser(int id)
{
    var user = users.FirstOrDefault(p => p.Id == id);
    if (user == null)
        return TypedResults.NotFound();

    return TypedResults.Ok(user);
}

Сама тенденция не сильно радует. В старых проектах IActionResult и ActionResult (их пока не объявили устаревшими, но без статического анализа ошибок разметки они начнут терять привлекательность) используются много где.

Приветствую, Хабравчане!

Задумывались ли вы, насколько высок современный налог на железо в разработке ПО?

У меня в руках настоящий «старичок» из 2002-го: сокет 478, матплата GA-8IR2003, Celeron 1700 МГц (по силам как Pentium III на 1 ГГц, но с поддержкой SSE2), 2 Гб ОЗУ, GeForce 4 MX и верный HDD на 40 Гб.

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

На борт успешно встают Windows 7 и Debian 11, что открывает доступ к актуальному софту, IDE и библиотекам. Хочется понять: реально ли на таком непотребстве поднять бэкенд на C# или собрать что-то серьезное на C++?

Запасной вариант, если основному ПК не хватит инструкций.

В запасе ПК: Athlon x4 640, 8гб ОЗУ, ssd 256.

На нем, отключая ядра и понижая частоту можно добиться симуляции ПК начиная с 2000-ого по 2010 год. Думаю этот вариант будет предпочтительнее. Но начну конечно с celeron'а.

Что планирую потестить:

1. C# под Linux: Запустить бэкенд и посмотреть, не «умрет» ли система.

2. Базы данных: Погонять PostgreSQL 9.4 (она еще дружит с 32-битными процессорами).

3. C++: Сравнить скорость сборки проекта с модулями и без них.

4. Безумный челлендж: Попробовать собрать userver. В чате разработчиков сказали "вряд ли взлетит", а мне тем более интересно проверить.

5. IDE: Какая версия Visual Studio оживет и можно ли в ней работать без боли.

Прошу совета у сообщества: накидайте идей! Какие бенчмарки прогнать? Какой софт или специфические проекты попробовать собрать, чтобы нащупать предел возможностей?

Будет интересно сделать вывод: пригоден ли древний ПК хоть для какой-то разработки сегодня, или «налог на железо» стал неподъемным. Жду ваши предложения!

Update: Поправил текст, ошибки и очепятки.

Добавил поддержку типов System.UInt128 и System.Int128 в основную web3-библиотеку для шарпистов/дотнетчиков,— Nethereum. Уже ушло в master, так что если активно используете Nethereum для работы с протоколами, где широко представлены 128-битные типы в событиях/параметрах/результатах вызова функции и страдаете от избыточного потребления памяти BigInteger, то можно уже переключаться на версию из master (для сборки необходим nuget.exe). Особенно это актуально для AAVE, Balancer и Velodrome/Aerodrome (в последних не забывайте использовать packed-кодирование при работе с роутером).

Сейчас обсуждаем с мейнтейнером Хуаном Бланко повышение производительности и снижение потребления памяти при кодировании/декодировании целых чисел в Nethereum, после чего я подготовлю ещё один Pull Request с реализацией и ориентировочно всё эти изменения войдут в следующий релиз.

Если есть идеи, что ещё можно было бы сделать/улучшить, присоединяйтесь к обсуждению в Discord проекта (на английском/испанском) или в issues в репозитории на github.