Один навык сделает вас ценным в любой команде — умение находить и устранять узкие места производительности.

Скорость приложения — это не просто «хорошо иметь».
Это деньги, стабильность и доверие пользователей.

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

Почему так происходит?

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

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

Это настоящий рентген системы.

Если вы хотите внедрить распределённый трейcинг, автор подготовил пошаговый гайд, который можно адаптировать под любой .NET-проект.

Вот отличная отправная точка:
milanjovanovic.tech/blog/introduction-to-distributed-tracing-with-opentelemetry-in-dotnet

ASP .NET 10 получил новую возможность — Server-Sent Events (SSE)

В свежем ASP .NET 10 появилась поддержка Server-Sent Events — современного способа стримить данные в браузер без WebSockets.

Что такое SSE
- Односторонний канал: сервер → браузер
- Идеально подходит для потоковых обновлений, логов, нотификаций, live-данных
- Работает поверх обычного HTTP, без сложной настройки протокола

Почему это круто
- Проще, чем WebSockets
- Легче масштабировать
- Отлично подходит для real-time интерфейсов и hypermedia-приложений
- Встроено прямо в ASP .NET 10, без сторонних библиотек

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

#dotnet #aspnet #csharp #backend #webdev

Так вот как становятся ПМ…

⚡️ Полное руководство по Bash: от основ к продвинутым темам

Bash (Bourne Again SHell) — это одна из самых популярных Unix-оболочек, широко используемая для запуска команд и написания скриптов в Linux и macOS.

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

Данное руководство последовательно познакомит вас с основами Bash (синтаксис, переменные, условия, циклы и т.д.), а затем перейдет к продвинутым возможностям (таким как настройка strict mode, использование trap-обработчиков, планирование задач через cron и др.). Мы рассмотрим практические примеры скриптов, сопровождая их поясняющими комментариями, чтобы у вас сложилось цельное понимание создания надежных Bash-скриптов.

https://uproger.com/polnoe-rukovodstvo-po-bash-ot-osnov-k-prodvinutym-temam/

Видео: https://www.youtube.com/watch?v=ei0a1TT4ukU

«Обзор нововведений в C# 14»

Статья от PVS-Studio на Хабре описывает, что именно добавили в C# 14 и как эти изменения делают код чище и короче.

1. Ключевое слово field
Теперь в сеттере свойства можно обращаться к скрытому полю без его явного объявления.
Это уменьшает шаблонный код и делает свойства компактнее.

Пример было:

private string _email;
public string Email
{
  get => _email;
  set => _email = value.Trim();
}

Пример стало:

public string Email
{
  get;
  set => field = value.Trim();
}

Лямбды с модификаторами без указания типа
Если в параметрах используются ref, out, in, теперь можно не писать тип.
Это улучшает читаемость и уменьшает шум.

Было:

(value, out string error) => ...

Стало:

(value, out error) => ...

Перегрузка операторов составного присваивания (+=, -=, *=, /=)
Теперь такие операторы можно перегружать напрямую, а не через комбинацию бинарного оператора и присваивания.
Это делает пользовательские типы более естественными и управляемыми.

nameof для открытых обобщённых типов
Теперь можно писать:

nameof(List<>)

Это полезно при генерации кода, рефлексии и работе с API, где нужны именно открытые generics.

C# 14 - небольшое, но важное обновление языка, направленное на упрощение синтаксиса и уменьшение шаблонного кода. Наиболее заметные улучшения - field и новые правила для лямбд.

Коллекции .NET: взгляд изнутри

Как устроены стандартные коллекции в .NET и почему понимание их внутренней логики помогает писать более производительный код? На открытом вебинаре курса OTUS «C# Developer. Advanced» Антон Герасименко покажет, что происходит «под капотом» List, Dictionary и других структур данных.

📆 4 декабря, 20:00

Коллекции .NET: взгляд изнутри:
— разберём устройство стандартных коллекций
— заглянем в исходный код и объясним, почему они работают именно так
— обсудим, когда стоит реализовать собственную структуру данных

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

👉Зарегистрируйтесь: https://otus.pw/esShq/?erid=2W5zFGumrxg

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

⚡️ Полезное о блокировках в C#. Многие собеседования заваливаются именно здесь.

Коротко по сути:

lock не работает в `async`-методах.
Причина проста — выполнение может продолжиться на другом потоке, и гарантии взаимного исключения теряются.

Что использовать вместо `lock` в асинхронном коде:

- SemaphoreSlim — основной вариант
- Semaphore
- Mutex
- Monitor (в синхронных сценариях)

Правильный шаблон:

1. Всегда используйте таймаут, чтобы избежать зависаний.
2. Освобождайте ресурс в `finally`, иначе возможна утечка блокировки.

Примерный подход:

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

Почему это важно:
В многопоточном и распределённом окружении неправильная синхронизация приводит к гонкам, дублированию запросов, «штормам» в кеше и нагрузке на внешний API.

Вопрос для практики:
Как реализовать блокировку на уровне базы данных, чтобы синхронизировать несколько инстансов приложения?

Ответ — в разборе по distributed locking:
milanjovanovic.tech/blog/distributed-locking-in-dotnet-coordinating-work-across-multiple-instances