C# (C Sharp) programming

Microsoft выпустила бесплатный курс по модернизации старого .NET .NET Modernization for Beginners показывает, как перенести legacy ASP.NET-приложение на .NET 10 с помощью GitHub Copilot modernization agent. Внутри: - анализ старого кода и зависимостей; - генерация плана миграции; - пошаговый upgrade приложения; - деплой обновлённой версии в Azure App Service. Интересно, что агент сначала создаёт assessment.md, plan.md и tasks.md, а разработчик может проверить план до изменения кода. Сам курс бесплатный и open source. Для практики понадобится GitHub Copilot. https://devblogs.microsoft.com/dotnet/announcing-dotnet-modernization-for-beginners/

Каждый год в середине лета мы с друзьями собираемся на E-CODE. Ещё относительно молодая конфа Ozon Tech стала уже своего рода легендой. Не удивительно: хардовость официальной части здесь не уступает громкости афтерпати. На E-CODE 2026 нас по части бэкэнда ждут: • Runtime Async с его + и – • трассировка с eBPF • ускорение на SIMD • построение кастомной real-time системы видеоаналитики • сравнительный анализ алгоритмов сборки мусора Фишка этого года — брейнринг разработчиков и ИИ. Эксперты разберут сложные кейсы и сравнят свои подходы с тем, что предложит машина. Победителя выберет зал. Регистрируйтесь сейчас, чтобы услышать это всё вживую: https://ecode.ozon.tech/ 12 и 13 сентября, Москва. До встречи на E-CODE!

😨 Opus 5 собрал онлайн-шутер в духе Call of Duty практически с одного промпта Автор попросил модель сделать FPS на Three.js с AAA-графикой, физикой и детализацией, а работу разбить между несколькими субагентами. Отдельным агентам поручили: • реализовывать разные части игры • проверять результат визуально • жёстко критиковать качество • повторять итерации, пока результат не станет максимально близок к Call of Duty Fвтор выложил репозиторий и исходный промпт, поэтому результат можно проверить самому. промпт:

I want you to build a first-person shooter at the level of the most recent Call of Duty games. It should be utterly perfect, visually beautiful, with every single thing done at AAA quality—from textures to physics to anything you could think of. Fan out sub-agents and have sub-agents tackle each one individually so that the game is utterly perfect. You should /loop on each item and have a separate sub-agent check it visually to ensure it looks triple A. That separate sub-agent should be a really harsh critic, and if it doesn't look triple A, it should keep going. Don't stop until each sub-agent is utterly wowed with the quality when compared with the actual Call of Duty game. It should literally compare them side by side blind and say which one looks better. Do this in ThreeJS. /loop until it's utterly perfect. Fan out sub-agents and ultracode.

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

#ПятничныйКвиз

⚡️ Почему Repository поверх EF Core часто превращается в лишний слой Многие .NET-проекты начинают с отдельных репозиториев:

GetPostsByUser(...)
GetPopularPosts(...)
GetPostsByCategory(...)
GetRecentViralPosts(...)

Сначала всё выглядит аккуратно. Затем появляются новые фильтры, сортировки и бизнес-правила, а репозиторий разрастается до десятков похожих методов. Проблема в том, что DbContext уже предоставляет возможности, близкие к Repository и Unit of Work. Дополнительный слой часто усложняет запросы, скрывает возможности EF Core и создаёт абстракцию поверх абстракции. Один из вариантов решения — Specification Pattern. Каждая спецификация описывает отдельное условие выборки:

var specification =
    new ViralPostSpecification(minLikesCount: 150);

var posts = await dbContext.Posts
    .ApplySpecification(specification)
    .Select(post => post.ToDto())
    .ToListAsync(cancellationToken);

Спецификации можно переиспользовать и комбинировать:

var combinedSpec =
    recentSpec.And(highEngagementSpec);

Что это даёт: - фильтры не размножаются по репозиториям - запросы остаются рядом с бизнес-правилами - спецификации проще тестировать - условия можно комбинировать - IQueryable продолжает переводиться в SQL Repository Pattern полезен, когда действительно изолирует сложную инфраструктуру или несколько источников данных. Но создавать отдельный репозиторий для каждой сущности только ради шаблона часто означает лишнее усложнение архитектуры. #dotnet #csharp #efcore #architecture

Unity представила Unity CLI - инструмент, который позволяет ИИ-агентам напрямую работать с игровыми проектами. Агент может: - изменять объекты и компоненты в сценах; - искать причины ошибок; - исправлять баги; - запускать сборку проекта; - проверять, действительно ли исправление сработало. В одном из демо агент получил баг-репорт о персонаже, проваливающемся сквозь пол. Он самостоятельно нашёл отключённый коллайдер, активировал его, запустил проверку и убедился, что проблема исчезла. Получается почти полноценный ИИ-разработчик: получил задачу, изучил проект, внёс изменения и протестировал результат — всё через терминал. Инструмент доступен бесплатно. Подробнее: https://unity.com/blog/meet-the-unity-cli #unity #gamedev #ai #vibecoding

Microsoft показала Microsoft.UI.Reactor - экспериментальный open-source проект, который переосмысляет разработку WinUI 3-приложений. Инструмент позволяет писать нативные Windows-приложения декларативно на C#, без привычной связки XAML + code-behind + view models. UI описывается как функция состояния, а Reactor сам синхронизирует экран с изменениями. Что это даёт: * меньше split между разметкой и логикой * проще управлять state * компоненты выглядят ближе к React-подходу * вся структура приложения остаётся в C# * можно быстрее собирать и менять UI Проект пока экспериментальный. В README он описан как набор расширений для WinUI 3, а публичный preview-пакет уже доступен через NuGet; шаблон проекта пока ставится из исходников. На фоне того, что WinUI 3 остаётся рекомендуемым нативным UI-фреймворком для новых Windows desktop-приложений, Reactor выглядит как попытка сделать Windows-разработку более современной и менее тяжёлой. Это интересный эксперимент: каким мог бы быть WinUI, если бы его проектировали под декларативный C# и component-driven разработку. build.microsoft.com/en-US/sessions/OD854?source=sessions

#ПятничныйКвиз

🔥 Вышел .NET 11 Preview 6. Это уже шестой превью-релиз .NET 11, и он выглядит не как “пара мелких фиксов”, а как большой проход по всему стеку: Runtime, SDK, Libraries, ASP.NET Core, MAUI, C#, EF Core, F#, контейнеры. Microsoft прямо перечисляет улучшения во всех этих направлениях. Самое интересное для backend-разработчиков: * улучшения JIT и runtime async performance * in-process crash report logging * faster interface dispatch для NativeAOT * новые SIMD API * dotnet test получает новые опции и улучшенный вывод * container publishing теперь поддерживает multi-arch builds с Podman В C# продолжают двигать union types: System.Text.Json уже умеет сериализовать C# union types, а support types для unions теперь идут “из коробки”. Ещё появился пункт про extension indexers. В ASP.NET Core тоже много практичных вещей: async validation для minimal APIs, автоматическая CSRF-защита для cross-origin сценариев, OpenAPI 3.2 по умолчанию, unions в ASP.NET Core, обновления SignalR и short-circuit endpoints через attribute. EF Core получил улучшения LINQ query translation, migrations, Cosmos DB provider и поддержку ключей/индексов через complex-type properties. Для меня главный сигнал Preview 6 такой: .NET 11 явно допиливают не только как runtime, а как цельную платформу для production-разработки: performance, NativeAOT, контейнеры, web API, тесты и tooling двигаются вместе. Ставить в прод пока рано, но смотреть и пробовать уже есть что. https://devblogs.microsoft.com/dotnet/dotnet-11-preview-6/

Vertical Slice Architecture хороша тем, что перестаёт заставлять код жить “по этажам”. В классической слоистой архитектуре фича часто размазана по всему проекту: endpoint в одном месте, request/response в другом, validator где-то рядом, handler отдельно, репозиторий ещё ниже. Чтобы понять одну бизнес-операцию, приходится прыгать по папкам как по квесту. В vertical slice подход другой: одна фича — один самостоятельный срез. Например, CreateProduct может хранить рядом всё, что нужно именно для создания продукта: request, response, validator, endpoint и handler с бизнес-логикой. Не потому что “так модно”, а потому что это проще сопровождать. Открыл срез - сразу видишь, что принимает API, что возвращает, как валидирует входные данные и что реально делает. Меньше магии, меньше лишней навигации, меньше риска случайно сломать соседнюю фичу. Для больших проектов это очень удобно: код начинает группироваться не вокруг технических слоёв, а вокруг бизнес-сценариев. И это, кажется, главный плюс VSA. Архитектура становится ближе к тому, как продукт реально работает.

TIME_WAIT в Linux годами объясняют неправильно Я полез в исходники Linux TCP и снова наткнулся на старый сетевой миф. В коде TIME_WAIT фактически зафиксирован на 60 секунд: #define TCP_TIMEWAIT_LEN (60 * HZ) Его нельзя настроить отдельно для сокета. И да, tcp_fin_timeout, который часто советуют крутить в блогах, не управляет TIME_WAIT. Он относится к состоянию FIN_WAIT2. TIME_WAIT задан в исходниках ядра и не вынесен в отдельный sysctl. Вот так появляются мифы: один параметр звучит похоже, его копируют из статьи в статью, а потом годами лечат не то состояние TCP.

G# — новый язык для .NET с синтаксисом ближе к Go, Kotlin и Swift. Идея не в том, чтобы заменить C#, а в том, чтобы дать более компактный язык поверх той же CLR. Что обещают: • компиляция в обычные managed .NET assemblies • совместимость с BCL, NuGet, MSBuild и dotnet tooling • interop с C#-кодом • null-safety через T?, nil, ?., ??, if let и guard let • data classes со structural equality, copy-with и deconstruction • async/await поверх Task и Task[T] • опциональные Go-подобные go, chan, select • REPL / script runner через gsi • C# → G# мигратор через cs2gs Самая интересная часть — G# не пытается строить новый рантайм. Он просто использует существующую .NET-экосистему и меняет язык входа: меньше исторического багажа C#, больше предсказуемой синтаксической поверхности. Но важно: проект пока pre-1.0. Версия 0.3 — это скорее milestone по реализации и interop, а не гарантия стабильности языка. Для продакшена рано. Для тех, кто следит за экспериментами вокруг .NET-языков, очень любопытно. Статья: https://www.linkedin.com/pulse/meet-g-modern-net-language-go-kotlin-swift-ergonomics-david-obando-lwofc/

Ты не твой стек Зачем учиться новому, когда по самое колено в практике? Не страшно, что всё больше джунов работают наравне с сеньёрами? Уже нельзя уметь только фреймворк, надо понимать что стоит за этим и в твоём опыте огромное преимущество, не хватает лишь малого - знаний об том как утроен мир и формула принятия решений. Метафизика? Нет - математика. Языки и фреймворки устаревают за 5–10 лет, стеки обновляются радикально. А способ мышления, которым ты пользуешься, чтобы разложить сложную задачу на части, остаётся с тобой навсегда. Именно об этом курс: "Философия, математика и компьютерные науки" Не про конкретный стек, а про то, как в принципе думать о сложных системах с опорой на философию, математику и системную инженерию. Формат: 9 месяцев, 10 модулей, теория и практика, несколько очных сессий в Петербурге. Кураторы: - Андрей Родин — доктор философских наук, философ науки и математики - Илья Егорычев — доктор философских наук, математик и логик, Soulmaths - Вячеслав Шириков — системный архитектор, техдиректор ГК «Лартех» До 21 июля действует скидка за раннюю регистрацию. Программа и условия

⚡️ GPT-5.6 РЕЛИЗ OpenAI выкатили сразу три новые модели. • Sol - заявлено, что модель мощнее Mythos. Доступ для платных пользователей обещают в течение 24 часов. На Terminal Bench 2.1 с настройкой Ultra модель выбивает рекордные 91,9%. Первые тестеры отдельно отмечают сильную работу с интерфейсами: она уверенно собирает UI для приложений и сайтов, а не просто генерирует сырой код. • Terra - уровень Fable 5. Будет доступна бесплатно. • Luna - еще одна бесплатная модель для всех. Помимо самой модели, показали 3 крупных продуктовых обновления: 1. ChatGPT Work 2. новое desktop-приложение ChatGPT 3. hosted sites, то есть размещение сайтов прямо через Chatgpt https://openai.com/ru-RU/live/

#ПятничныйКвиз

AI-инструменты стали стандартной частью стека C#/.NET-разработчиков: ассистенты в IDE, генерация кода и тестов, помощь с документацией и ревью. По данным отраслевых отчётов, 80–90% инженеров уже используют AI-сервисы, а 97% компаний встроили AI в SDLC. Однако разрыв сегодня проходит не по доступу к моделям. У одних команд AI встроен в мультиагентные пайплайны, SDD подход и метрики качества. У других остаётся локальным помощником без влияния на метрики, скорость релизов и риск-профиль. Именно для интеграции AI в процессы команда Naition запускает 12‑недельную программу по AI-driven разработке. Программу собрали инженеры и техлиды из Яндекс Cloud, Сбера, Google и других продуктовых команд с опытом более 15 лет. Что внутри:

• создание AI-окружения под ваш стек • контекст-инжиниринг - от создания и подключения кастомных MCP до RAG под вашу кодовую базу • решение продуктовых задач, spec-driven разработка и контроль качества с evals • разработка агентов, сабагентов с выходом в практики оркестрации • практики работы с легаси-проектами и крупными кодовыми базами при ограниченном бюджете

Форматы участия: Командный - для C#/.NET-команд от 3–5 человек. Заходите в общий поток и получаете отдельный трек: разбор текущих процессов, выделение узких мест, план внедрения AI-практик и фиксация метрик до и после изменений. Индивидуальный формат - для архитекторов, техлидов, middle/senior‑разработчиков и руководителей, которые хотят собрать язык и паттерны AI‑ориентированной разработки, чтобы затем использовать их как основу изменений внутри своих команд. 95% участников прошлого потока дошли до конца. Первые изменения в процессах команды вносили уже после второго модуля. Новый поток AI‑DRIVEN стартует 21 июля. Если вы отвечаете за архитектуру и метрики разработки в C#/.NET‑проектах, вы можете оставить заявку на сайте и до 13 июля получить индивидуальные условия участия для команды или для себя как индивидуального участника. Подробности на сайте: naition.ai Реклама: ИП Крутов Дмитрий Валерьевич ИНН: 772973192199 Erid: 2VtzqxRqZmC

Godot фактически запрещает vibe coding в контрибуциях. Причина простая: PR стало легче генерировать, но не легче проверять. Для open-source движка каждый патч всё равно должен разобрать мейнтейнер, который понимает архитектуру, риски и последствия изменений. Теперь автономные агенты, крупные AI-сгенерированные куски кода и сгенерированный текст в issues, proposals и PR-дискуссиях запрещены. Разрешены только мелкие помощники вроде автодополнения, regex и find/replace. Помощь AI в коде нужно раскрывать. На практике правило будет сложно применять: почти невозможно наверняка доказать, где был vibe coding, а где обычная работа разработчика. Godot защищает не стиль разработки, а время ревьюеров. Код можно сгенерировать за минуты, но ответственность за него всё равно остаётся на людях. godotengine.org/article/contribution-policy-2026/

#ПятничныйКвиз

⚡️ Idempotency: важная вещь в REST API В распределённых системах запрос может не дойти, ответ может потеряться, клиент может словить timeout и отправить тот же запрос ещё раз. Если API не готов к такому сценарию, начинаются дубли: два платежа, два заказа, две записи в базе. Idempotency решает эту проблему. Идемпотентная операция может быть вызвана несколько раз, но состояние системы после первого успешного запроса уже не меняется. Типичный пример: клиент создаёт уникальный ключ операции и отправляет его в заголовке, например:

Idempotency-Key: 8f7a2c9e-12a4-4f8b-91c2

Сервер проверяет этот ключ. Если ключ новый, он выполняет операцию и сохраняет результат. Если ключ уже был, сервер не запускает операцию повторно, а возвращает сохранённый ответ. Так API нормально переживает повторы, сетевые сбои и retries без случайных дублей. Особенно важно для платежей, создания заказов, бронирований и любых операций, где повторный запрос может стоить денег.

# C# record: что выведет код? На собеседованиях record часто объясняют как «сравнение по значению». Но есть нюанс, который легко пропустить.

public record User(string Name, List<string> Roles);

var u1 = new User("Alice", new List<string> { "admin" });

var u2 = u1 with { };

u2.Roles.Add("owner");

Console.WriteLine(u1 == u2);
Console.WriteLine(string.Join(", ", u1.Roles));
Console.WriteLine(ReferenceEquals(u1.Roles, u2.Roles));

Что будет в консоли?

True
admin, owner
True

Почему так? with для record делает не глубокую копию, а поверхностную. Сам объект User скопировался, но List<string> внутри остался тем же самым объектом в памяти. Поэтому изменение u2.Roles меняет и u1.Roles. И сравнение тоже остаётся True, потому что оба record указывают на один и тот же список. Вот почему record не делает модель автоматически immutable. Он только упрощает синтаксис и даёт value-based equality. Если внутри лежат изменяемые reference-типы, их всё равно можно случайно протащить в состояние. Более безопасный вариант:

public record User(string Name, IReadOnlyList<string> Roles);

А для строгой неизменяемости лучше смотреть в сторону immutable collections.