C# (C Sharp) programming

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

🔥 Вышел .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 июля действует скидка за раннюю регистрацию. Программа и условия

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

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