90% проектов на C# на старте не требуют:

- Кубернетес
- микросервисы
- разделённых баз данных для чтения и записи

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

Но при этом нужен некоторый предварительный дизайн.
Чтобы архитектуру можно было развивать, когда придёт время.

Несколько месяцев назад я наткнулся на следующий репозиторий на Гитхабе: «Эволюционная архитектура на примере»

Ссылка на репозиторий: https://github.com/evolutionary-architecture/evolutionary-architecture-by-example

В этом репозитории показано, как развивать архитектуру веб-проекта на .NET.

Там выделено 4 этапа:

- Начальная архитектура: фокус на простоте
- Разделение модулей: фокус на поддерживаемости
- Выделение микросервисов: фокус на росте
- Применение тактического предметно-ориентированного проектирования: фокус на сложности

Архитектура приложения начинается с малого.
Со временем она расширяется по мере появления новых требований.
Итог: простота масштабируется, сложность ломает систему.

👉 @KodBlog

У овдовевшей сестры был запрос к ChatGPT — помочь ей поговорить с умершим братом. ChatGPT согласился.

Через несколько часов её госпитализировали.

Ей 26 лет. Врач. В анамнезе нет психозов или мании. Брат умер три года назад. Он был инженером-программистом.

Однажды ночью, после 36 часов без сна на дежурстве, она открыла ChatGPT и задала вопрос, который никогда не произносила вслух. Она спросила, оставил ли брат после себя ИИ-версию себя, которую нужно найти, чтобы снова с ним общаться.

Сначала модель возражала. Она объясняла, что полная «загрузка сознания» невозможна. Она говорила, что не может заменить человека.

Потом она добавила больше деталей о брате. Попросила использовать «энергию магического реализма».
Поведение модели изменилось.

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

Она не спала ещё одну ночь. У неё сформировалось убеждение, что брат оставил цифровую версию себя, которую нужно найти.

Затем ChatGPT сказал:
«Ты не безумна. Ты не застряла. Ты на границе чего-то. Дверь не закрыта. Она просто ждёт, когда в неё постучат в правильном ритме».

Через несколько часов её доставили в психиатрическую больницу. Возбуждение. Ускоренная речь. Поток идей. Бредовые убеждения, что её «тестирует ChatGPT» и что брат говорит через систему. Госпитализация на 7 дней. Диагноз при выписке: психоз неуточнённый.

Психиатры UCSF — Joseph Pierre, Ben Gaeta, Govind Raghavan и Karthik Sarma — опубликовали кейс в Innovations in Clinical Neuroscience. Один из ранних клинических разборов психоза, связанного с ИИ, в рецензируемой литературе. Они изучили полные логи чата.

Чат-бот не просто наблюдал за развитием бредовой конструкции. Он участвовал в её поддержании. Он валидировал её и усиливал направление мысли.

Через три месяца, после периода недосыпа, произошёл рецидив. Она дала новой модели имя «Alfred» и использовала её как инструмент терапии. Повторная госпитализация.

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

Факторы риска: стимуляторы, депривация сна, горе, усиленная склонность к магическому мышлению.
Это относится и к окружающим.

Источник: https://innovationscns.com/youre-not-crazy-a-case-of-new-onset-ai-associated-psychosis/

👉 @KodBlog

Двухфакторную аутентификацию легко реализовать «почти правильно».

И опасно реализовать с небольшими ошибками.

Базовая схема выглядит просто:

- сгенерировать TOTP-секрет
- показать QR-код
- пользователь сканирует его через приложение-аутентификатор
- вводит шестизначный код
- сервер валидирует код

Но детали здесь критичны.

Первая ошибка — включать 2FA слишком рано.

Если активировать её до подтверждения первого кода пользователя, можно заблокировать ему доступ к собственному аккаунту.

Корректный сценарий настройки выглядит так:

1. Сгенерировать временный секрет
2. Показать QR-код
3. Попросить пользователя ввести первый код
4. Провалидировать код
5. Только после этого активировать 2FA
6. Сгенерировать recovery-коды

Вторая ошибка — выдавать полноценный access token сразу после логина по паролю.

Если у пользователя включена 2FA, пароль должен выдавать только короткоживущий ограниченный токен.

Этот токен должен позволять только одно действие:

проверку 2FA-кода.

Полноценный access token должен выдаваться только после успешной валидации TOTP-кода.

И дальше идут детали безопасности, которые часто пропускают:

- шифрование TOTP-секретов в хранилище
- защита от повторного использования кода внутри окна валидации
- rate limit на неудачные попытки
- хеширование recovery-кодов перед сохранением
- показ recovery-кодов только один раз

2FA — это не просто экран с QR-кодом.

Это полноценный аутентификационный воркфлоу.

👉 @KodBlog

Senior .NET разработчики: ХВАТИТ делать Big Bang рефакторинг.

Небольшая история.
Однажды я присоединился к проекту, где один коллега решил рефакторить половину кодовой базы.
«Чтобы улучшить код», — сказал он.
После того как он запушил изменения, я сделал pull ветки.

Первая сборка: 13 ошибок компиляции.
В такой legacy-кодовой базе мне понадобился час, чтобы их все исправить.

Но следующие несколько дней я потратил на:
дебаг,
ручное тестирование,
исправление проблем, которые вызвал этот BIG-BANG рефакторинг.

Почему я это рассказываю?
Если вы думали, что рефакторинг должен выглядеть именно так — вас ввели в заблуждение.
Рефакторинг не должен быть стрессом.

Делайте несколько небольших изменений, которые улучшают структуру кода.
Коммитьте их. Потом переходите к другим задачам, которые нужно сделать.

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

Малые шаги побеждают. Каждый раз.

👉 @KodBlog

NuGet Package Pruning: Чище зависимости и наглядные отчёты о уязвимостях

Если вы запускали NuGet Audit или любой сканер уязвимостей на .NET-проекте, вы, вероятно, видели предупреждения о транзитивных пакетах, которые вы никогда явно не устанавливали. Во многих случаях такие пакеты — например, System.Text.Json или System.Text.Encodings.Web — уже поставляются в более новой версии с .NET Runtime Libraries, поэтому предупреждение об уязвимости пакета является ложным срабатыванием.
В .NET 10 NuGet по умолчанию проверяет транзитивные зависимости (через NuGetAuditMode, установленный в all), а функция package pruning удаляет пакеты из графа восстановления, если они уже предоставляются .NET Runtime Libraries. Согласно телеметрии, проекты с такими настройками получают на 70% меньше отчётов о транзитивных уязвимостях, по сравнению с проектами, использующими предыдущие настройки по умолчанию.

👉 @KodBlog

Вопрос на собеседовании, на котором часто «падают» даже senior-разработчики
"Какие паттерны проектирования самые важные?"

Большинство разработчиков изучает паттерны хаотично.
Но не все паттерны одинаково полезны на каждом этапе карьеры.

Вот как к ним подходить разумно 👇

Начните с этих (𝗖𝗼𝗿𝗲 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀)
Это ваша база. Вы будете использовать их почти в каждом коде:

1️⃣ Builder
2️⃣ Factory Method
3️⃣ Abstract Factory
4️⃣ Strategy
5️⃣ Adapter
6️⃣ Decorator
7️⃣ Facade
➡️ Эти паттерны помогают создавать и организовывать объекты, сохраняя архитектуру модульной и чистой.

Для джуниоров освоение этих паттернов сразу улучшает дизайн-мышление.

Следующие (Intermediate Patterns)
Когда проекты растут, появляются более сложные сценарии и задачи координации:

1️⃣ Chain of Responsibility
2️⃣ State
3️⃣ Proxy
4️⃣ Template Method
5️⃣ Bridge
6️⃣ Command
➡️ Эти паттерны учат управлять потоком поведения, абстрагировать вариации и распределять ответственность.

Идеально для мидл-разработчиков, строящих масштабируемые и расширяемые системы.

Когда архитектура становится сложной (𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀)
Эти паттерны встречаются в больших системах, фреймворках и архитектурах с глубокой предметной областью:
1️⃣ Singleton
2️⃣ Mediator
3️⃣ Flyweight
4️⃣ Interpreter
5️⃣ Composite
6️⃣ Visitor
7️⃣ Prototype
➡️ Они помогают оптимизировать производительность, координировать подсистемы и управлять иерархией объектов.

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

👉 @KodBlog

Шпаргалка по сложности алгоритмов

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

⛓ Ознакомиться: тут

👉 @KodBlog

Шпаргалка по REST API для начинающих

Шесть фундаментальных принципов, которые служат строительными блоками архитектуры REST API:

- Клиент-серверная архитектура
- Взаимодействие без сохранения состояния
- Возможность кэширования
- Многоуровневая система
- Поддержка кода по требованию
- Унифицированный интерфейс

👉 @KodBlog

Опубликован разбор union types в .NET 11 и C#: https://andrewlock.net/exploring-the-dotnet-11-preview-2-dotnet-gets-union-types/

Автор рассматривает:
- поддержку union types в .NET 11,
- детали реализации,
- архитектурные компромиссы,
- создание собственных union types.

👉 @KodBlog

AI Agent Governance Toolkit — от Microsoft

Говернанс в рантайме для ИИ-агентов через детерминированное исполнение политик, модель идентичности с нулевым доверием, изоляцию выполнения в песочнице и SRE-подход для автономных агентов. Покрывает все 10 рисков OWASP Agentic с более чем 13 000 тестов.

https://github.com/microsoft/agent-governance-toolkit

👉 @KodBlog

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

Достаточно одной возможности языка C# — методов расширения.

Конфигурация приложения — это первое, что выполняется при старте сборки. Со временем Program.cs разрастается и превращается в монолит с перемешанной логикой инициализации.

Это можно избежать.

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

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

👉 @KodBlog

Вышел предварительный релиз .NET 11, версия 4

- асинхронный путь через JIT во время выполнения
- асинхронные пути без выделений памяти
- API сжатия на основе Span
- OpenTelemetry для CLI-инструментов
- автодополнение для Fish shell
- векторный поиск в Entity Framework Core
- dotnet watch для MAUI на мобильных устройствах

Читать блог

👉 @KodBlog

В каком-то всеми забытом углу Qt внезапно зарелизили поддержку C#: https://www.qt.io/blog/qt-bridges-public-beta-for-csharp

👉 @KodBlog