C# 1001 notes

Один навык сделает вас ценным в любой команде — умение находить и устранять узкие места производительности. Скорость приложения — это не просто «хорошо иметь». Это деньги, стабильность и доверие пользователей. И чем больше система, тем больнее становятся проблемы с производительностью. В микросервисной архитектуре это особенно заметно: запросы ходят между сервисами, сетевые задержки накапливаются, логика размазана — и понять, где именно тормозит, становится значительно труднее. Почему так происходит? - распределённая архитектура усложняет путь запроса - один медленный сервис замедляет десяток других - локально всё работает быстро, а в продакшене исчезает производительность - классические логи дают только фрагменты картины Но есть хороший инструмент, который решает эту проблему — трейсинг с OpenTelemetry. Он позволяет пройти вместе с запросом через всю цепочку сервисов и увидеть, где именно начинается задержка. Это настоящий рентген системы. Если вы хотите внедрить распределённый трейcинг, автор подготовил пошаговый гайд, который можно адаптировать под любой .NET-проект. Вот отличная отправная точка: milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet

⚡ Быстрый совет для Cursor Хочешь, чтобы Cursor писал точнее и в твоём стиле? 🧠 Просто создай файл `.cursorrules` в корне проекта и опиши в нём: - правила кодстайла, которые ты используешь - предпочтения по структуре, форматированию, именованию Чем конкретнее, тем лучше работает автогенерация. 🔥 Это помогает избежать «галлюцинаций» и потери контекста при создании кода.

⚡️ Когда стоит применять паттерн Idempotent Consumer? В распределённых системах всё непредсказуемо: сообщения могут прийти поздно, в неправильном порядке или продублироваться. Если надеяться, что каждое сообщение обработается «строго один раз», рано или поздно появятся тихие ошибки в данных. Производитель может частично решить проблему: многие брокеры (Azure Service Bus, Amazon SQS) сами отбрасывают дубликаты, если у сообщения есть уникальный MessageId. Но у потребителя ответственность больше. Паттерн Idempotent Consumer предотвращает повторные побочные эффекты: 1. Перед обработкой проверяем локальную таблицу с ключом (MessageId, ConsumerName). 2. Если записи нет - выполняем логику, коммитим транзакцию и записываем факт обработки. 3. Если запись уже есть - сообщение повторное, просто выходим. Что делать с внешними сервисами? Некоторые поддерживают idempotency key (например, email-сервисы), и тогда повторный запрос просто игнорируется. Если сервис это не умеет, можно сохранять намерение локально и выполнять действие отдельным надёжным процессом. Важно: не все обработчики нуждаются в этом паттерне. Если операция сама по себе безопасна при повторе (обновить статус, пересобрать кэш) — дополнительные проверки не нужны. Используйте Idempotent Consumer там, где повторное выполнение может привести к деньгам, ошибкам или сбоям в бизнес-логике. milanjovanovic.tech/blog/the-idempotent-consumer-pattern-in-dotnet-and-why-you-need-it

Управление зависимостями в ASP.NET Core: меньше рутины, больше автоматизации. Ручное добавление сервисов через AddScoped и AddSingleton превращает Program.cs в бесконечный список регистраций. Но есть способ проще — библиотека Scrutor. На открытом вебинаре курса OTUS C# ASP.NET Core разработчик Михаил Дмитриев покажет, как автоматизировать регистрацию сервисов и расширить стандартный IoC контейнер. 📌 18 ноября, 20:00 Управление зависимостями в ASP.NET Core с помощью Scrutor — массовая регистрация сервисов по правилам — использование паттерна декоратор — добавление кэширования без переписывания кода — реальные примеры для продакшн-проектов Вебинар бесплатный и будет полезен ASP.NET Core-разработчикам, которые хотят упростить настройку зависимостей и сделать код чище. 👉 Регистрируйтесь: https://otus.pw/HpwY/?erid=2W5zFJ5eURW Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🖥 Полезный Совет по Visual Studio: Когда вы создаете метод, который возвращает JSON через raw string literal, добавьте /* lang=json*/ Этот момент нигде не задокументирован. Если в JSON будет синтаксическая ошибка вроде пропущенной запятой, Visual Studio подсветит её.

Основы обобщений (Generics) в C#: классы, интерфейсы, методы и делегаты Generics — это фундамент гибкого и переиспользуемого кода в C#. На открытом вебинаре курса OTUS C# Developer. Professional Павел Нилов объяснит, как работают обобщения, зачем они нужны и как с их помощью писать код, который не боится масштабирования. 📌 18 ноября, 20:00 Основы обобщений (Generics) в C# — классы, интерфейсы, методы и делегаты — ковариантность, контравариантность и ограничения — эффективное использование List и Dictionary — примеры и разбор типичных ошибок Вебинар бесплатный и подойдёт начинающим .NET-разработчикам, студентам и джунам, готовящимся к собеседованиям, а также тем, кто хочет систематизировать знания по Generics. 👉 Регистрируйтесь: https://otus.pw/SjQq/?erid=2W5zFH97jxt Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Что выведет код? Пишите ответ в комментариях

Гид по Redis в C# ASP.NET: ускоряем приложения и снижаем нагрузку на базу данных. Redis — быстрая база данных в памяти, которая помогает масштабировать системы и ускорять доступ к данным. На открытом вебинаре курса OTUS C# ASP.NET Core разработчик Андрей Сорокин покажет, как интегрировать Redis в ASP.NET Core 8 и внедрить кэширование в реальных проектах. 📌 12 ноября, 20:00 Гид по Redis в C# ASP.NET — настройка Redis в Docker — кэширование ответов API — хранение данных для быстрого доступа — ускорение обработки запросов и снижение нагрузки на БД Вебинар бесплатный и будет полезен C#-разработчикам, архитекторам и тимлидам, которые хотят повысить производительность приложений и упростить масштабирование. 👉 Регистрируйтесь: https://otus.pw/7CFj/?erid=2W5zFHZ3J6k Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.