Разработчики на .NET, автоматизируйте работу с документами.

→ Генерация PDF-документов (QuestPDF / iText)
→ Экспорт в Excel без использования Interop (ClosedXML / EPPlus)
→ Объединение и разделение PDF-файлов (PdfSharp)
→ Работа с шаблонами Word (OpenXML / DocX)
→ OCR и извлечение данных из документов (PdfPig / Tesseract / Azure Document Intelligence)

Подробнее: https://buff.ly/65Hrxv4

👉 @KodBlog

50 тем по System Design — от простого к сложному

Идеальная дорожная карта для изучения System Design в 2026 году. Сохраните этот список.

1. Спроектировать Rate Limiter
2. Спроектировать сервис сокращения URL
3. Спроектировать Pastebin
4. Спроектировать генератор уникальных идентификаторов
5. Спроектировать Consistent Hashing
6. Спроектировать балансировщик нагрузки
7. Спроектировать API Gateway
8. Спроектировать простое Key-Value хранилище
9. Спроектировать систему кэширования (например, LRU Cache)
10. Спроектировать систему уведомлений
11. Спроектировать систему автодополнения (Typeahead/Autocomplete)
12. Спроектировать веб-краулер
13. Спроектировать очередь сообщений
14. Спроектировать чат один на один
15. Спроектировать групповой чат
16. Спроектировать ленту новостей
17. Спроектировать сервис определения близости пользователей (например, друзья поблизости)
18. Спроектировать Instagram (обмен фото и видео + лента)
19. Спроектировать Twitter/X (публикации + таймлайн)
20. Спроектировать WhatsApp (обмен сообщениями в реальном времени)
21. Спроектировать Dropbox (хранение и синхронизация файлов)
22. Спроектировать систему бронирования билетов
23. Спроектировать платформу электронной коммерции (каталог + оформление заказа)
24. Спроектировать рекомендательную систему
25. Спроектировать распределённый кэш
26. Спроектировать Uber (поиск и сопоставление водителей и пассажиров)
27. Спроектировать Netflix (платформа потокового видео)
28. Спроектировать YouTube (загрузка и стриминг видео)
29. Спроектировать TikTok (платформа коротких видео)
30. Спроектировать ленту новостей социальной сети уровня Facebook
31. Спроектировать Google Docs (совместное редактирование документов в реальном времени)
32. Спроектировать CDN (Content Delivery Network)
33. Спроектировать поисковую систему (индексация и поиск)
34. Спроектировать Google Maps (маршрутизация и геолокационные сервисы)
35. Спроектировать распределённую базу данных
36. Спроектировать систему аналитики в реальном времени
37. Спроектировать систему показа и отслеживания рекламы
38. Спроектировать систему обнаружения мошенничества
39. Спроектировать торговую платформу или биржу ценных бумаг
40. Спроектировать распределённый планировщик задач
41. Спроектировать архитектуру Event Sourcing + CQRS
42. Спроектировать мультиарендную SaaS-платформу (Multi-tenant SaaS)
43. Спроектировать масштабируемый сервис прямых видеотрансляций
44. Спроектировать высокомасштабируемую NoSQL-базу данных
45. Спроектировать серверную часть многопользовательской игры в реальном времени
46. Спроектировать инфраструктуру обслуживания ML-моделей (Model Serving)
47. Спроектировать геораспределённую систему с низкой задержкой
48. Спроектировать глобальную базу данных со строгой согласованностью
49. Спроектировать платформу для высокочастотной торговли (HFT)
50. Спроектировать распределённую систему планетарного масштаба (миллиарды пользователей, несколько регионов, высокая доступность)

👉 @KodBlog

AddDbContext — вариант по умолчанию. AddDbContextPool — оптимизация. AddDbContextFactory — запасной выход для особых сценариев. Большинство .NET-команд не понимают, когда стоит выбирать каждый из них.
EF Core предоставляет три способа регистрации DbContext. В Program.cs они выглядят похоже. В продакшене они ведут себя совершенно по-разному.

1. AddDbContext
Вариант по умолчанию. Регистрирует DbContext с временем жизни Scoped — новый экземпляр на каждый HTTP-запрос. Фреймворк создаёт его при начале запроса и освобождает после отправки ответа.
Используйте его, если конфигурация контекста меняется от запроса к запросу: разные строки подключения в multi-tenant-приложениях, динамические фильтры логирования и всё, что нужно определять во время обработки запроса.
Цена такого подхода — создание и освобождение объекта на каждом запросе. В API с низкой нагрузкой вы этого не заметите. При 5000 запросах в секунду нагрузка на GC начинает проявляться в трассировках.

2. AddDbContextPool
EF Core поддерживает пул экземпляров DbContext: выдаёт экземпляр на время запроса, а затем возвращает его обратно в пул. Никаких дополнительных аллокаций и затрат на создание объекта.
Используйте этот вариант, если конфигурация стабильна и важна высокая пропускная способность. Он существенно снижает количество аллокаций на горячих эндпоинтах.

Но есть нюанс: экземпляры из пула переиспользуются, а не создаются заново. Если запрос изменяет состояние на уровне контекста — настройки ChangeTracker, savepoint'ы, состояние пользовательских интерсепторов — и логика сброса что-то упустит, следующий запрос унаследует это состояние. Такой баг выглядит случайным. На самом деле он не случайный. Причина — некорректный сброс состояния перед возвратом объекта в пул.
Не используйте пул, если вам нужна конфигурация, зависящая от конкретного запроса. Пул делает такой сценарий невозможным.

3. AddDbContextFactory
Здесь вы сами управляете жизненным циклом контекста. Внедряете IDbContextFactory<T>, вызываете CreateDbContext(), используете контекст внутри блока using и затем освобождаете его.
Используйте этот вариант в фоновых сервисах, worker-задачах, hosted services и любом коде, который выполняется вне HTTP-запроса. Scoped-зависимости там не работают, потому что отсутствует scope запроса. Фабрика позволяет создавать контекст независимо от него.

Цена — ответственность за освобождение ресурсов ложится на вас. Забудете using — получите утечку соединений.

Если конфигурация меняется для каждого запроса — используйте AddDbContext.

Если нужна максимальная производительность при стабильной конфигурации — используйте AddDbContextPool и контролируйте корректный сброс состояния.

Если код выполняется вне HTTP-скоупа (фоновые сервисы, воркеры) — используйте AddDbContextFactory.

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

👉 @KodBlog

dotnet ef поддерживает файловые приложения (file-based apps) в Entity Framework 11.

👉 @KodBlog

Только сейчас наткнулся на полностью переписанный 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