😂 Помните Semantic Kernel? Можете выкинуть. Тащите Agent Framework 1.0

Помните я писал про Semantic Kernel? Про то как можно за пару строчек кода собрать мини-агента с тулами, который сам решает что вызывать? Так вот — можете его выкинуть. 3 апреля Microsoft выкатили Agent Framework 1.0. Это не очередной превью — это стаблильнейший релиз от тех же людей, что делали SK. Фактически они взяли всё хорошее из SK, выкинули всё что бесило, и в итог переписали все с нуля.

Как говорится, устранили фатальный недостаток.

Главная боль SK была в том, что для всего нужен был объект Kernel. Хочешь тул зарегать — оберни в KernelPlugin, навесь [KernelFunction], добавь в Kernel.Plugins. Хочешь другого провайдера — отдельный класс агента (ChatCompletionAgent, OpenAIAssistantAgent, AzureAIAgent). Много обвязки.

В Agent Framework всё это выкинули. Вот что поменялось:

1️⃣ Один тип агента на всех провайдеров. ChatClientAgent работает с любым IChatClient — OpenAI, Azure, Anthropic, Ollama. Никаких отдельных классов.

2️⃣ Тулы без атрибутов. Не нужен [KernelFunction]. Берёшь любой C# метод, оборачиваешь в AIFunctionFactory.Create() — и готово. Description по-прежнему важен (как я и говорил — мусор на входе, мусор на выходе), но обвязки стало меньше.

3️⃣ Сессии из коробки. Не надо руками таскать ChatHistory. Вызвал agent.CreateSessionAsync() — и агент сам хранит историю переписки между вызовами.

4️⃣ Middleware pipeline. Вместо фильтров SK — полноценный пайплайн как в ASP.NET. Три уровня: перехват на уровне агента, на уровне вызова функций, на уровне IChatClient.

Покажу на примере. На пояснительном дикпике 1 — агент с тулами для работы с GitHub. Обратите внимание: никакого [KernelFunction], никакого Kernel.Plugins. Просто метод с [Description] и AIFunctionFactory.Create(). Минус целый один атрибут! 😳

А на дикпике 2 — сравнение старого SK и нового Agent Framework бок о бок. Тот же функционал, вдвое меньше кода.

А ещё там есть мультиагентные воркфлоу. На дикпике 3 — цепочка из трёх агентов: один исследует, второй пишет, третий редактирует. И всё это собирается в одного workflowAgent. Я вот тут чуток попробовал. Мне понраивлось в целом

А что с Semantic Kernel, кстати где он?

Ну вот тут кек. ☺️ Мы буквально только-только затащили SK в проект. 😀 Написали плагины, настроили агентный цикл, я даже посты про это написал!!! — и тут Microsoft такие: "а мы тут новый фреймворк сделали, старый в maintenance mode". Классика AI. А помните как мы угорали над фронтентдными фреймворками? Я вот сейчас плчу по тем временам. 😭

SK официально переходит в maintenance mode. Это значит: баг-фиксы и секьюрити патчи будут, но новых фич не будет — всё новое только в Agent Framework. Microsoft рекомендует мигрировать в течение 6–12 месяцев.
Гайд по миграции. 🫠

🅰️ Итого: Agent Framework — это то, чем SK хотел быть, но не мог из-за легаси. Выбрасывайте SK и срочно переходите на Agent Framework! Ладно, это шутка. Если уже используете SK — не паника, он ещё поддерживается, но мигрировать стоит. Если только начинаете — начинайте сразу с Agent Framework.

#csharp #dotnet #ai #agents #microsoft

👽 Как защититься от космических лучей? Часть 2

Итак, как нам дешево защититься от космических лучей? Возьмём 11 бит данных:

1️⃣ 1️⃣ 0️⃣ 0️⃣ 1️⃣ 0️⃣ 1️⃣ 1️⃣ 0️⃣ 1️⃣ 1️⃣

Космический луч может испортить один бит. Как найти и исправить конкретный бит?

Первое что приходит в голову — разбить на группы и проверить чётность каждой. Но тогда мы знаем только в какой группе сбой, а не какой бит флипнулся. КПД те же 50%.

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

🟢 Решение — сетка 4×4

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

Но как это сделать? Во первых нашу линейку битов мы расположим в виде матрицы:


❓ ❓ ❓ 1️⃣

❓ 1️⃣ 0️⃣ 0️⃣

❓ 1️⃣ 0️⃣ 1️⃣

1️⃣ 0️⃣ 1️⃣ 1️⃣

Вопросики — контрольные биты на позициях-степенях двойки. Работают так же они будут позволять проверять четность. Но алгоритм тут чуть хитрее. Ибо каждыйц проверочный бит будет отвечать не за один столбец или одну строку, а сразу за две! Как это показано на пояснительном дикпике 1.

Теперь вычислим значения вопросиков:

К1: 1+1+0+1+0+1+1 = 5, нечётное → К1 = 1
К2: 1+0+0+1+1+1 = 4, чётное → К2 = 0
К4: 1+0+0+1+0+1+1 = 4, чётное → К4 = 0
К8: 1+0+1+1+0+1+1 = 5, нечётное → К8 = 1

Получилось что нам нужно хранить 16 бит вместо 11. КПД — 69%. Но на самом деле, чем больше бит нам нужно проверить, тем эффективнее будет этот алгоритм!

Готово! Защищённая последовательность:

1️⃣ 1️⃣ 0️⃣ 1️⃣

0️⃣ 1️⃣ 0️⃣ 0️⃣

1️⃣ 1️⃣ 0️⃣ 1️⃣

1️⃣ 0️⃣ 1️⃣ 1️⃣

☄️ Космический луч бьёт в позицию 3

Бит в правом верхнем углу переворачивается:
1 → 0.

1️⃣ 1️⃣ 0️⃣ 0️⃣

0️⃣ 1️⃣ 0️⃣ 0️⃣

1️⃣ 1️⃣ 0️⃣ 1️⃣

1️⃣ 0️⃣ 1️⃣ 1️⃣

Как найти нужный бит?

Прогоняем 4 проверки:

🟨 К1 (столбцы 1,3): сумма 5, нечётное → сбой!
🟦 К2 (столбцы 2,3): сумма 3, нечётное → тоже сбой!

Обе группы указывают на столбец 3. Ошибка одна — значит она там. Столбцы 1 и 2 чистые ✓

🟩 К4 (строки 1,3): сумма 4, чётное → ок ✓
🟧 К8 (строки 2,3): сумма 6, чётное → ок ✓

Строка 0, столбец 3 → позиция 3! Переворачиваем бит. Починено.

💡 Можно ещё проще: складываем номера сбойных групп. 1 + 2 = 3. Номер битого бита.

⁉️ Интерактивная визуализация:

Короче, на мощностях тележного редактора такие визуальные штуки объяснять довольно сложно. Но я заморочился и потратил вечерок на вайбкодинг визуализации. Поглядите ее. Там это все прям по шажочкам разложено и можно потыкать в разные биты и поиграться с космическими лучами. ГДЕ ЕЩЕ ВАМ ДАДУТ ПОИГРАТЬСЯ С КОСМИЧЕСКИМИ ЛУЧАМИ???

➡️ОТКРОЙ МЕНЯ ⬅️

Ну а в следующем посте, расскажу, как это работает применительно к нам и почему именно до 2021 года мы могли с уверенностью все валить на космические лучи. А сейчас уже не с такой уверенностью

#инженерныештучки #кодхэмминга #помехоустойчивость

В жизни каждого шарписта наступает момент, когда надо разобраться, наконец, как работает СУБД, которой он каждый день пользуется.
Прежде чем написать этот короткий пост, я погрузился в тему баз данных и в какой-то степени они стали для меня открытой книгой, буквально, потому что в них слишком много аналогий с книгами. Оказывается, что концепция, на которой стоит вообще всё хранение данных, одна и та же что в PostgreSQL, в MySQL, и даже в MongoDB — страницы 📄

📖 Что такое страница и зачем она
Когда ты делаешь INSERT INTO users (...), в голове картина обычно простая: «строчка просто легла куда-то в таблицу». Физически — нет. Ни одна нормальная СУБД (что реляционная, что документная) не пишет каждую строку или документ отдельно. Вместо этого данные складываются в страницы (pages) — блоки фиксированного размера.
У PostgreSQL и SQL Server страница — 8 KB, у MySQL/InnoDB — 16 KB, у MongoDB через WiredTiger — настраивается, но того же порядка. Любая операция чтения или записи — это работа с целой страницей, а не с одной строкой.
Почему так? Потому что диск и RAM физически работают блоками, а не байтами. Один поход на диск всё равно вытаскивает целый блок килобайт на восемь — хочешь ты того или нет. СУБД этим пользуется: складывает в одну страницу столько строк или документов, сколько влезет. Берёшь одну строку — получаешь рядом «соседей» бесплатно 💋

🔬 Давай потрогаем руками
Самое классное — это всё можно пощупать, если поднять, например, PostgreSQL в Docker. Полный список команд для последовательного выполнения сможешь найти 👉вот здесь👈 (а то пост получится уже не таким коротким) 🥖

На пояснительном дикпике 1 можно увидеть, где физически лежит созданная таблица и сколько весит: файл занимает ровно 409600 байт = 50 × 8192, то есть страницы ровно по 8 KB. И таких страниц в одном файле подряд — 50 штук, это и есть вся таблица.

На дикпике 2 можно увидеть, как заглянуть внутрь файла прямо из контейнера и что записи лежат сырыми байтами в одной из 50 страниц.

📍 Где какая строка лежит
В Postgres у каждой строки есть служебный «адрес» — ctid, пара (номер страницы, номер слота на странице).

На дикпике 3 запрос, который покажет адреса выбранных строк, и там же видно, что в нулевую страницу 8 KB у нас влезла 121 строка, в первую — следующие 120, и так далее. На 6000 строк ушло 50 страниц — ровно то, что мы видели по размеру файла. Когда СУБД хочет прочитать запись с id = 5999, она не «ищет в таблице» — она поднимает с диска страницу №49 и достаёт из неё нужный слот.

🧑‍💻 Что с этим знанием делать в работе
1. Чтение одной строки = чтение целой страницы. Запросом за одной строчкой ты всё равно поднимаешь с диска 8 (или 16) KB. Если в WHERE id IN (...) много значений и они физически рядом — это почти бесплатно. Если разбросаны по таблице — каждое чтение отдельная страница.
2. Узкие таблицы — это не только про место. Чем шире строка, тем меньше их влезает в страницу. Большое поле text на килобайт-другой может уронить плотность в 20 раз — и для того же количества строк понадобится в 20 раз больше страниц.
3. shared_buffers / buffer pool — это кэш страниц, не строк. Когда тюнят память под СУБД, имеют в виду «сколько страниц влезет в RAM». И именно поэтому случайные чтения по большой таблице болят: каждая страница приходит с диска заново.
4. В Postgres UPDATE — это DELETE + INSERT. Старая версия строки помечается мёртвой и продолжает лежать на той же странице, новая дописывается рядом. Поэтому после массовых апдейтов файл таблицы пухнет, пока не пройдёт VACUUM. Та же логика — ctid после UPDATE меняется, потому что физически это уже другая запись на другом слоте.

А если в таблице миллионы записей, как БД так быстро находит нужную? Для этого нужны индексы, но о них — в другом посте👉

🧑‍💻dp 🥁
#бд #postgresql #инженерныештучки #heavywednesday

👈 В прошлый раз мы выяснили, что обычно данные в СУБД лежат в страницах фиксированного размера. А как по этим страницам что-то быстро найти?

🔍 Если искать в лоб
Представь, что ты хочешь найти в толстой книге по базам данных упоминание слова «дерево». Если в конце нет предметного указателя — придётся листать страницу за страницей и глазами выискивать нужное слово.
СУБД без индекса делает ровно то же самое: она прочитает все страницы таблицы подряд, проверит на каждой, есть ли подходящая строка, и оставит то, что нашла. Этот режим работы называется Sequential Scan, или просто Seq Scan — последовательное чтение.
Увидеть, что СУБД делает именно так, можно через EXPLAIN — команду, которая покажет, как планируется выполнить запрос. Видишь в плане Seq Scan — значит СУБД проходит таблицу целиком.
На таблице в 10 млн строк это будет довольно долго, потому что на каждый запрос будут выполняться сотни тысяч чтений страниц с диска ради одной нужной строки 💽

📖 Предметный указатель
В книге это решается просто: там есть предметный указатель — отсортированный по алфавиту список слов с номерами страниц. Открываешь, ищешь слово, прыгаешь на нужную страницу.
В СУБД роль такого указателя играет индекс. Это отдельная структура на диске, в которой ключи (например, значения id) лежат отсортированно, а рядом с каждым — указатель на конкретную страницу таблицы 🧿
Чаще всего первый индекс появляется в таблице автоматически: когда ты добавляешь, например, в свою таблицу users PRIMARY KEY на колонку id, Postgres под капотом создаёт уникальный индекс по этой колонке — users_pkey; в psql его видно через метакоманду \d users как btree (id).

🌳 Что такое btree
В большинстве СУБД (PostgreSQL, MySQL/InnoDB, SQL Server, MongoDB через WiredTiger) индекс по умолчанию — не просто отсортированный список, а B-дерево (точнее, его вариант B+tree).
Почему не список? Главное — число чтений с диска. Бинарный поиск по отсортированному списку из миллиона страниц — это около 20 чтений. И если ключ не монотонный (email, uuid, имя автора), любая вставка в середину означает переписать целый хвост.
B-дерево — это обычное дерево из корня сверху, внутренних узлов в середине и листьев снизу. Оно устроено так:

🟢 В каждом узле много ключей — не один-два, а сотни.
🟢 Все листья на одной глубине. Любой путь от корня до листа одинаковой длины.
🟢 За счёт большого ветвления глубина дерева смешная. Для индекса по сотне миллионов записей это 3–4 уровня. Найти строку = 3–4 чтения. Не миллионы, не тысячи. Три-четыре 🎉
🟢 Листья связаны в список. Поэтому Range-запросы (>, <, BETWEEN) тоже летают: спустился до начала диапазона и пробежал листья подряд.
Аналогия — толстая энциклопедия: тома → главы → разделы. Три шага, и ты на месте 👍

📦 Как это лежит в Postgres (см. дикпик 3)
Структура B-tree один в один ложится на структуру страниц из прошлого поста:
⚪️ Один узел дерева = одна страница 8 KB.
⚪️ Внутренние узлы хранят пары (ключ, ссылка на дочернюю страницу). В одну страницу таких пар влезают сотни.
⚪️ Листья хранят пары (ключ, ctid). Помнишь ctid из прошлого поста? Это указатель «страница такая-то, позиция такая-то» — он ведёт прямо на нужную строку в куче.
⚪️ Индекс лежит отдельным файлом со своим pg_relation_filepath — это не часть таблицы, это самостоятельная сущность.

🔬 Пощупаем (см. дикпики 1 и 2)
Берём таблицу users из прошлого поста (6000 строк, без PRIMARY KEY) и ищем по id. Seq Scan ... Rows Removed by Filter: 5999: прочитали всё, отбросили 5999, оставили одну.

Добавляем первичный ключ. Тот же запрос — план сменился на Index Scan using users_pkey. Сначала Postgres прошёл по B-дереву от корня до листа, там нашёл ctid, по нему сходил в нужную страницу таблицы и достал строку.

🅰️ Что с этим знанием делать
Индекс — это отдельные страницы на диске. Каждый INSERT/UPDATE/DELETE правит и таблицу, и все её индексы. Поэтому вешать их «на всякий случай» на каждое поле — плохая идея: платишь местом на диске, замедлением записи, обслуживанием дерева. При хорошо выбранном индексе взамен этих накладных расходов получаешь быстрый поиск⚡️
dp
#бд #postgresql #инженерныештучки #heavywednesday

🗞 Что было за последний месяц для ASP.NETёра

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

1️⃣ HybridCache + Postgres вместо Redis

В .NET 10 HybridCache наконец релизнулась. Главная фишка — встроенный stampede-protection (про который есть отличная серия постов и статья на моем любимом шарповом канальчике) и L1-memory (в процессе) + L2-distributed (в базе или редисе) одним API.

В этой статье MS показывает связку HybridCache с пакетом Microsoft.Extensions.Caching.Postgres — то есть L2 живёт в Postgres-таблице с UNLOGGED-флагом для скорости записи. Сейчас стало хайпово заменять все на постгресс. Ну по крайней мере в моем инфопузыре эта тема встречается регулярно. И вот и в майрософтовый блог просочилось.

Кажется скоро мы в постгрессе и рилсы с тиктоками сможем посмотреть, и даже катку в доту скатать.

2️⃣ Union types в C# 15

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

Главный профит — если завтра в union добавится Refunded, все switch-выражения посыпятся в Build Output с ошибкой про неполноту, и ты гарантированно эти места найдёшь. Сегодня без помощи компилятора такие тихие «_ => throw» живут месяцами и ловят тебя за жопу в неподходящий момент. Хотя в целом можно тестами такое покрывать раньше было. Но теперь можно будет на компилятор положиться.

3️⃣ Node.js addons на C# через Native AOT

История: У команды C# Dev Kit был нативный Node.js аддон на C++

Что их бесило:

node-gyp требует Python — каждый разработчик в команде должен был ставить Python 3.x на свою машину, хотя в коде Python нет ни строчки.

Онбординг новых разработчиков — нужно настроить кучу тулзов, которые ты в работе никогда не трогаешь напрямую: C++ компилятор (MSVC / clang / gcc — у каждой ОС свой), node-gyp, Python, плюс ещё CMake местами.

CI/CD — пайплайны вынуждены провижнить и поддерживать в свежем состоянии тот же зоопарк: Python, C++ тулчейн, node-gyp.

Билды медленные — C++ компиляция аддона тормозила пайплайн, плюс надо ещё дёрнуть Python скрипты для генерации проектов.

Чуваки все переписали никогда не угадаете на Rust Go C# Native AOT!

В итоге:
- ❌ Питон — выпилили
- ❌ node-gyp — выпилили
- ❌ C++ тулчейн — выпилили
- ✅ Осталось dotnet publish → готовый .node файл

Статья из серии для общего развития. Мне оно не надо. Но где-то на подкорке мне хочется знать, что такая возможность у меня есть.

Такие вот у нас пироги. 🥧 В июне постараюсь продолжить эту серию.

#dotnet #aspnet #performance