Только сейчас наткнулся на полностью переписанный DesktopManager для .NET и PowerShell.

Штука неожиданно мощная. Из коробки умеет:
• Управлять мониторами и обоями
• Контролировать слайд-шоу рабочего стола
• Менять яркость экрана
• Находить окна и UI-элементы и взаимодействовать с ними
• Эмулировать мышь и клавиатуру
• Работать с буфером обмена
• Делать скриншоты
• Управлять раскладками окон и рабочим столом

По сути, это такой комбайн для автоматизации Windows. Если приходилось писать свои обёртки вокруг WinAPI, UI Automation или PowerShell-скрипты для управления рабочим столом, здесь многое уже собрано в одном месте.
Проект с открытым исходным кодом, доступен бесплатно как NuGet-пакет и PowerShell-модуль.

👉 @KodBlog

Знаешь, как спроецировать вложенную коллекцию?

Вот один из способов:

SelectMany — это LINQ-метод, который работает с коллекциями IEnumerable и IQueryable и разворачивает элементы последовательности в одну коллекцию.

Если разложить весь процесс по шагам:
• Берёт последовательность элементов
• Выполняет преобразование для каждого элемента
• Генерирует новую последовательность элементов для каждого входного элемента
• Объединяет все полученные промежуточные последовательности в одну плоскую последовательность

Если коллекция равна null, выбрасывается ArgumentNullException.

👉 @KodBlog

Приложение работает на вашем ноутбуке. Это ещё не значит, что оно готово к продакшену.
Среди всех production-чеков чаще всего забывают именно эти вещи.

Health Checks
У приложения должен быть эндпоинт, который отвечает примерно так:

Я жив, и база данных доступна.

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

Логирование и мониторинг
Когда что-то ломается в 2 часа ночи, логи становятся единственным источником правды.
Если всё логирование заканчивается консолью на локальной машине разработчика, в продакшене вы работаете вслепую.

Секреты в Vault
API-ключи, connection strings и пароли не должны жить в репозитории или попадать в сборку.
Получайте их из Vault или через переменные окружения во время запуска.
Одна утечка артефакта не должна автоматически означать компрометацию продакшена.

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

Ещё три пункта обычно завершают этот список:
• Миграции базы данных
• Обработка ошибок
• Нагрузочное тестирование

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

👉 @KodBlog

Что такое Sidecar Pattern в микросервисах?

Sidecar — это вспомогательный компонент, который разворачивается рядом с основным сервисом и берёт на себя общую инфраструктурную логику.

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

Преимущества:
- Выносит кросс-функциональные задачи из приложения
логирование
мониторинг
безопасность
трассировка запросов

- Не зависит от языка и фреймворка
одинаково работает с Java, Go, Python, .NET и любым другим стеком

- Обновляется и масштабируется независимо от основного сервиса

- Упрощает код приложения
бизнес-логика не смешивается с инфраструктурным кодом

Когда стоит использовать Sidecar:

нужно добавить новую функциональность без изменений в основном сервисе
требуется единый подход к логированию, мониторингу или безопасности во всех сервисах
приходится работать с legacy-приложениями, которые сложно менять

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

• Логирование и мониторинг
Fluent Bit
Fluentd
OpenTelemetry Collector

• Service Discovery
регистрация сервиса
обнаружение соседних сервисов

• Proxy и Routing
Envoy
Istio Sidecar Proxy

• Безопасность и аутентификация
mTLS
управление сертификатами
проверка токенов

• Управление конфигурацией
получение и обновление конфигурации из внешних систем
Пример:

┌─────────────────┐
│      Pod        │
│                 │
│ ┌─────────────┐ │
│ │ Main App    │ │
│ └─────────────┘ │
│                 │
│ ┌─────────────┐ │
│ │ Envoy       │ │
│ │ Sidecar     │ │
│ └─────────────┘ │
└─────────────────┘

В Kubernetes sidecar чаще всего запускается в том же Pod, что и основное приложение. Именно так работают многие service mesh решения, включая Istio и Linkerd.

👉 @KodBlog

Docker тихо вырастил себе самого серьёзного конкурента.

Он называется Podman.

И всё больше Linux-разработчиков переходят на него.

Почему?

Потому что Podman убирает одну из самых спорных архитектурных особенностей Docker:

демон.

Никакого центрального фонового сервиса.
Никакого постоянно работающего процесса с повышенными привилегиями.
Никакой огромной поверхности атаки из-за привилегированного демона.

Взамен получаешь:

• rootless-контейнеры
• CLI, совместимый с Docker
• интеграцию с Kubernetes
• поддержку OCI
• pods
• интеграцию с systemd
• меньшее потребление ресурсов в простое

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

Самое интересное здесь даже не Podman.

Тренд в том, что разработчики всё чаще выбирают инфраструктурные инструменты, которые:

• легче
• работают без root-прав
• имеют открытый исходный код
• не требуют демона
• проще в защите и сопровождении

Экосистема Linux-инструментов сейчас развивается с очень высокой скоростью.

https://github.com/podman-container-tools/podman

👉 @KodBlog

Появился новый IDE для .NET, написанный на .NET и Godot.

Называется SharpIDE - https://github.com/MattParkerDev/SharpIDE

Проект полностью open source и нацелен на .NET 10. Автор делает ставку на современный интерфейс, кроссплатформенность и быстрый цикл разработки.

Что выделяется:
• написан на .NET + Godot
• работает на Windows, Linux и macOS
• собственный отладчик SharpDbg
• открытый исходный код
• активно развивается перед релизом .NET 10

Недавно автор показал бенчмарк, где путь от Build + Debug до срабатывания breakpoint занимает около 350 мс против 1.28 с у Visual Studio и 9.22 с у Rider.

Любопытно видеть, как кто-то пытается построить полноценную .NET IDE с нуля, а не очередной VS Code-плагин.

👉 @KodBlog

Постмортемы, пожалуй, самый недооценённый способ изучать распределённые системы.

Можно смотреть доклады, читать книги и разбирать архитектурные диаграммы. Но настоящий опыт приходит, когда читаешь, как крупные компании сами уронили продакшен и потом подробно объяснили почему.

5 постмортемов, которые реально стоит прочитать:

1. GitLab — Database Outage of January 31

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

2. Slack — Incident on 2-22-22

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

3. Meta — October 4 Outage

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

4. Cloudflare — Control Plane and Analytics Outage

Хорошо показывает путь от первопричины к восстановлению сервиса и дальнейшим изменениям в архитектуре.

5. AWS — Post-Event Summaries

Целая коллекция разборов инцидентов от одной из крупнейших облачных платформ. Хороший источник для регулярного чтения.

После таких материалов начинаешь смотреть на системы иначе.

👉 @KodBlog

В .NET 11 продолжают тихо выпиливать причины писать unsafe.
Команда накидала пачку оптимизаций в JIT (и Native AOT тоже), которые убирают лишние проверки границ массива. В результате безопасный код всё чаще выдаёт ту же производительность, что и его unsafe аналог.

Если интересно следить за прогрессом, у них даже есть отдельный лейбл: https://github.com/dotnet/runtime/pulls?q=is%3Apr+label%3Areduce-unsafe
Пример: https://github.com/EgorBot/Benchmarks/issues/169

👉 @KodBlog

CQRS на самом деле намного проще, чем его обычно пытаются представить.

Я не делю систему на 15 слоёв, не тащу отдельные базы и не устраиваю культ Event Sourcing.

Просто организую код вокруг use case'ов.
Типичные примеры:
• получить профиль пользователя
• добавить товар в корзину
• оформить возврат средств

Каждый use case живёт в своей папке и отвечает за одну конкретную бизнес-задачу.
Дальше всё сводится к двум вещам:

Command
→ меняет состояние системы
→ пишет в БД
→ отправляет события
→ запускает сайд-эффекты

Query
→ ничего не изменяет
→ просто возвращает данные в том виде, в котором они нужны UI

Вот и весь CQRS.

Каждый раз, когда вижу очередную статью с отдельными read/write базами, Kafka, Event Store и диаграммой на полэкрана, вспоминаю, что CQRS изначально был просто про разделение чтения и записи.

P.S. Нет, CQRS не требует Event Sourcing.
P.P.S. Нет, CQRS не требует двух баз данных.
P.P.P.S. Да, большинство команд, которые внедряют CQRS, в итоге внедряют что-то гораздо сложнее самого CQRS. 😅

👉 @KodBlog

Этот парень уместил RetroPad, свою версию Notepad из Windows XP с полным набором функций, всего в 2686 байт x86-ассемблера.

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

Код: https://github.com/PlummersSoftwareLLC/TinyRetroPad

👉 @KodBlog

Небольшой VS Code трюк для скриншотов и демонстраций.

Откройте Command Palette → Developer: Toggle Developer Tools.
Во вкладке Elements выберите body и добавьте:

filter: blur(5px);

Весь код в редакторе станет размытым, а интерфейс останется узнаваемым.

Удобно, когда нужно показать IDE на скриншоте, записать видео или провести демонстрацию, не раскрывая содержимое проекта.
Чтобы вернуть всё обратно, просто перезагрузите VS Code.

👉 @KodBlog

Что такое API Gateway?

API Gateway — это «входная дверь» для ваших бэкенд-сервисов.
Он принимает запросы от клиентов и маршрутизирует их к нужным сервисам.
При этом клиенту не нужно знать, как устроена внутренняя архитектура бэкенда.
Можно рассматривать это как форму сокрытия деталей реализации.

Что обычно берёт на себя API Gateway:
• маршрутизацию запросов
• аутентификацию
• авторизацию
• балансировку нагрузки
• ограничение частоты запросов (rate limiting)

Если ищете хорошую технологию для построения API Gateway, обратите внимание на YARP. Это высокопроизводительный reverse proxy для .NET.

👉 @KodBlog

Новичкам кажется, что хороший программист пишет быстро.

Быстро печатает. Быстро решает задачи. Быстро отвечает на вопросы.

Потом приходит опыт, и оказывается, что скорость переоценена.

Можно решить 500 задач на LeetCode и всё ещё теряться при первом реальном продакшен-инциденте. Можно знать пять языков и не понимать, почему система разваливается под нагрузкой. Можно наизусть помнить сложности алгоритмов и при этом проектировать хрупкую архитектуру.

Потому что программирование почти никогда не упирается в синтаксис.

Настоящие вопросы выглядят иначе:

• Почему это сломалось?
• Почему это решение не масштабируется?
• Почему этот крайний случай никто не учёл?
• Почему архитектура ощущается неправильной?

Хорошие разработчики отличаются не скоростью набора текста.

Они умеют сидеть с проблемой дольше остальных.

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

Со стороны это выглядит скучно.

На GitHub никто не выкладывает скриншот с подписью:

«Сегодня четыре часа искал одну гонку данных».

Никто не пишет:

«Шесть раз переделал архитектуру, прежде чем она начала нормально масштабироваться».

Хотя именно там и происходит рост.

Языки меняются.

Фреймворки меняются.

Тренды меняются.

Способность ясно мыслить остаётся.

Поэтому вопрос не в том, хорошо ли вы знаете программирование.

Вопрос в другом:

Можете ли вы разобраться в хаосе?

Можете ли вы построить систему из ничего?

Можете ли вы продолжать искать решение, когда ничего не работает?

Потому что программирование давно перестало быть соревнованием по скорости.

Это дисциплина мышления.

👉 @KodBlog

Вот 5 недооценённых методов LINQ, о которых стоит знать:

SequenceEqual
Aggregate
GroupJoin
ToLookup
Intersect

В LINQ есть немало полезных методов, которые помогают писать более чистый и эффективный код.
Какой метод LINQ, по твоему мнению, получает незаслуженно мало внимания?

👉 @KodBlog

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

👉 @KodBlog

Ты не делаешь integration tests, если тестируешь через in-memory database.

В лучшем случае это раздутый unit test.

Я видел кучу примеров с EF Core in-memory provider.

Но это не integration test, потому что настоящей базы данных там нет.

Хуже того, такие тесты не поймают баги в LINQ или SQL.

Лучший подход:

- использовать настоящую базу данных или Docker-контейнер
- подключаться к этой базе из тестов
- писать нормальные integration tests, от которых есть польза

Если хочешь использовать Docker, посмотри в сторону Testcontainers.

Он позволяет поднимать одноразовые контейнеры прямо из тестов.

А какие инструменты или подходы вы используете для integration testing?

👉 @KodBlog

Как устроены логирование и мониторинг в Docker

👉 @KodBlog

Ваш lock в C# работает идеально.

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

В итоге два воркера могут одновременно:
→ запустить одну и ту же scheduled task
→ обновить один и тот же cache entry
→ обработать один shared resource
→ сгенерировать один и тот же отчёт
→ одновременно записать данные

А дальше начинается веселье: дубли, лишняя нагрузка, гонки и иногда сломанные данные.
Для этого и нужны distributed locks.

Они дают нескольким инстансам одно общее правило:
только один из вас делает эту работу прямо сейчас.
Не надо тащить это везде. Но если job должна выполниться один раз, или shared work не должен пересекаться, distributed lock может сэкономить много боли.

Если у вас уже есть PostgreSQL, можно начать с advisory locks.
А если нужен более чистый вариант поверх Postgres, Redis или SQL Server, можно взять готовую distributed locking library.
На одном сервере приложение может выглядеть нормально.
Настоящая проверка начинается со второго инстанса.

👉 @KodBlog

Если вы программируете на Windows, стоит обратить внимание на Windows Developer Config от Microsoft.

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

Что умеет:

✓ Настраивает WSL и Ubuntu
✓ Устанавливает Windows Terminal
✓ Ставит Node.js, Python, Rust, Go, Java, .NET, PHP и другие инструменты
✓ Автоматизирует настройку рабочего окружения

Проект полностью открытый и доступен на GitHub.

Удобный способ поднять новое окружение без ручной установки десятков компонентов.

👉 @KodBlog