¡Ya disponible! Investigación de Telegram 2025 — los principales insights del año 
C# (C Sharp) programming
Ir al canal en Telegram
По всем вопросам- @notxxx1 Реестр РКН: https://clck.ru/3Fk3kb #VRHSZ
Mostrar más📈 Análisis del canal de Telegram C# (C Sharp) programming
El canal C# (C Sharp) programming (@csharp_ci) en el segmento lingüístico de Ruso es un actor destacado. Actualmente la comunidad reúne a 18 299 suscriptores, ocupando la posición 7 324 en la categoría Tecnologías y Aplicaciones y el puesto 36 848 en la región Rusia.
📊 Métricas de audiencia y dinámica
Desde su creación el невідомо, el proyecto ha mostrado un crecimiento acelerado, reuniendo a 18 299 suscriptores.
Según los últimos datos del 17 junio, 2026, el canal mantiene una actividad estable. En los últimos 30 días la variación de miembros fue de -4, y en las últimas 24 horas de 3, conservando un alto alcance.
- Estado de verificación: No verificado
- Tasa de interacción (ER): El promedio de interacción de la audiencia es 20.04%. Durante las primeras 24 horas tras publicar, el contenido suele obtener 7.25% de reacciones respecto al total de suscriptores.
- Alcance de las publicaciones: Cada publicación recibe en promedio 3 669 visualizaciones. En el primer día suele acumular 1 328 visualizaciones.
- Reacciones e interacción: La audiencia responde de forma activa: el promedio de reacciones por publicación es 0.
- Intereses temáticos: El contenido se centra en temas clave como .net, api, логика, архитектура, string.
📝 Descripción y política de contenido
El autor describe el recurso como un espacio para expresar opiniones subjetivas:
“По всем вопросам- @notxxx1
Реестр РКН: https://clck.ru/3Fk3kb
#VRHSZ”
Gracias a la alta frecuencia de actualizaciones (últimos datos recibidos el 18 junio, 2026), el canal mantiene la vigencia y un amplio alcance. La analítica demuestra que la audiencia interactúa activamente con el contenido, lo que lo convierte en un punto de referencia dentro de la categoría Tecnologías y Aplicaciones.
18 299
Suscriptores
+324 horas
+107 días
-430 días
Archivo de publicaciones
18 301
🎯 Открытый урок «Сетевой чат на C#».
🗓 22 января в 20:00 МСК
🆓 Бесплатно. Урок в рамках старта курса «C# Developer».
На вебинаре:
✔️ Рассмотрим написание сетевого приложения на C#.
✔️ Мы реализуем простые клиент и сервер с помощью одного из сетевых протоколов.
✔️Также затронем темы многопточности и асинхронности
Кому будет полезно:
• Вебинар будет полезен начинающим разработчикам, желающим разобраться в сетевом и многопочном\асинхронном программировании.
Что вы получите:
• По итогам вебинара смогут проектировать сетевые приложения.
• Получат представление о работе сетевых протоколов, и многопоточности\асинхронности в приложениях.
• На практике попробуют разработать такое приложение.
🔗 Ссылка на регистрацию: https://otus.pw/zifo/?erid=2W5zFJaPXHA
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
18 301
Не все стратегии балансировки нагрузки одинаково полезны.
Если ты используешь YARP (Yet Another Reverse Proxy) в .NET - у него есть 5 встроенных способов распределять трафик между серверами. Но какой выбрать?
Вот понятный разбор:
1) RoundRobin (по кругу)
Классика: запросы равномерно идут по очереди на каждый сервер.
✅ просто
❌ плохо работает, если сервера/запросы не одинаковые по скорости
2) LeastRequests (минимум активных запросов)
Самый “умный” вариант: отправляет запрос туда, где сейчас меньше всего работы.
✅ отлично при разном времени обработки запросов
✅ помогает снизить задержки на “хвосте” (tail latency)
3) Random (случайно)
Сервер выбирается случайно.
✅ неожиданно хорошо работает при большом потоке однотипных запросов
❌ может иногда “не повезти” и нагрузить один сервер сильнее
4) PowerOfTwoChoices (2 случайных - выбираем лучший)
Баланс между качеством и стоимостью: берём 2 случайных сервера и выбираем тот, где меньше активных запросов.
✅ почти как LeastRequests, но дешевле по логике
✅ не надо проверять все сервера каждый раз
5) FirstAlphabetical (первый доступный)
Всегда выбирает “первый” сервер из списка (условно самый верхний/раньше по имени).
✅ хорошо для failover (есть основной сервер, остальные - запасные)
❌ плохо распределяет нагрузку (по сути почти без балансировки)
Большинство по привычке ставят RoundRobin, но если время обработки запросов разное - переход на LeastRequests часто заметно улучшает tail latency.
Разбор с примерами, как масштабировать ASP.NET Core API через YARP:
https://milanjovanovic.tech/blog/horizontally-scaling-aspnetcore-apis-with-yarp-load-balancing?utm_source=X&utm_medium=social&utm_campaign=05.01.2026
А какая стратегия у тебя стоит по умолчанию?
18 301
.NET 9 стал гораздо устойчивее к сбоям 💪
В .NET 9 появились официальные пакеты для отказоустойчивости:
-
Microsoft.Extensions.Resilience
- Microsoft.Extensions.Http.Resilience
Они построены поверх Polly, поэтому API знакомый - легко описывать политики:
- retry
- circuit-breaker
- fallback
- timeout
- hedging
- rate limiter
Подключаете и ваши HTTP-клиенты и сервисы автоматически восстанавливаются при сетевых ошибках и таймаутах.
Итог: меньше падений и больше стабильности. Отлично для продакшена 🚀18 301
⚡️ Какие строки выведутся и в каком порядке(override + overload + dynamic)
using System;
class Base
{
public virtual void Foo(object o) => Console.WriteLine("Base.Foo(object)");
}
class Derived : Base
{
public override void Foo(object o) => Console.WriteLine("Derived.Foo(object)");
public void Foo(string s) => Console.WriteLine("Derived.Foo(string)");
}
class Program
{
static void Main()
{
Base b = new Derived();
b.Foo("A");
((Derived)b).Foo("A");
dynamic d = b;
d.Foo("A");
object x = "A";
d.Foo(x);
d.Foo(null);
}
}
18 301
🔥 Как просто добавить multi-tenant в .NET через заголовок запроса
Иногда нужно понимать, какому клиенту (tenant) принадлежит запрос.
Самый простой вариант - передавать
X-TenantId в HTTP-заголовке и читать его в сервисе.
Пример сервиса:
public sealed class TenantProvider
{
private const string TenantIdHeaderName = "X-TenantId";
private readonly IHttpContextAccessor _httpContextAccessor;
public TenantProvider(IHttpContextAccessor httpContextAccessor)
=> _httpContextAccessor = httpContextAccessor;
public string TenantId =>
_httpContextAccessor.HttpContext.Request.Headers[TenantIdHeaderName];
}18 301
💻Полный перебор выглядит простым решением, пока не сталкивается с реальностью. Как только задача усложняется, перебор становится неприемлемо медленным — и именно здесь начинаются настоящие алгоритмы.
📆На открытом уроке вы напишете алгоритм Dancing Links Дональда Кнута — один из самых элегантных способов решения задач точного покрытия. Мы разберём, почему классический перебор не работает, и как четырёхсвязный список позволяет добавлять и удалять элементы практически без затрат.
Вы увидите, как несколько десятков строк кода решают задачи, которые выглядят непосильными для brute force. Реализуете алгоритм полностью, разберёте его внутреннюю механику и примените к задаче пентамино.
👉Встречаемся 12 января в 20:00 МСК в преддверие старта курса «Алгоритмы и структуры данных». Регистрация открыта: https://tglink.io/cb04fae31111?erid=2W5zFHHfYCx
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
18 301
✔️ C# стал языком 2025 года по версии TIOBE.
Индекс TIOBE подвел итоги года: звание «Язык 2025 года» досталось C#, который показал рекордный рост популярности (+2.94%)? однако в общем зачете он по-прежнему занимает 5-ю строчку. Абсолютным лидером остается Python с 22.61% долей рынка.
В первой пятерке произошли перестановки: язык C поднялся на 2 место, сместив C++ на 4-ю позицию; 3 место досталось Java, а R вернулся в топ-10. Провал года - Go, который неожиданно сдал позиции, опустившись сразу на 16-е место.
Индекс оценивает популярность технологий на основе поисковых запросов, активности комьюнити и количества обучающих материалов.
https://www.tiobe.com/tiobe-index/
18 301
💡 В EF Core есть штука, о которой многие забывают: CompileAsyncQuery.
С её помощью можно заранее скомпилировать LINQ-запрос,а потом выполнять его асинхронно: быстрее и без лишнего overhead’а.
И важный еще момент:
вам не нужно писать отдельную “async-версию” самого LINQ-запроса.
EF сам оборачивает выполнение в асинхронный пайплайн. Немного странно, но работает.
Пример:
private static Func<AppDbContext, string, Task<Newsletter?>> GetByTitle =
EF.CompileAsyncQuery(
(AppDbContext context, string title) =>
context.Set<Newsletter>()
.FirstOrDefault(c => c.Title == title)
);
public async Task<Newsletter?> GetNewsletterByTitleAsync(string title)
{
return await GetByTitle(this, title);
}
18 301
🔍 Как делать code review, которые находят реальные баги, а не только придираются к стилю
Большинство code review застревают на форматировании, нейминге и мелочах. В итоге реальные проблемы - логические ошибки, гонки, неправильные инварианты - проходят мимо.
Идея правильного code review:
— Проверять поведение кода, а не его внешний вид
— Искать сценарии отказа, а не соответствие линтеру
— Думать как система, а не как форматтер
Что реально стоит смотреть на ревью:
• Граничные случаи и ошибки в бизнес-логике
• Null / empty сценарии и некорректные состояния
• Побочные эффекты и порядок операций
• Работа с асинхронностью, транзакциями и ресурсами
• Соответствие инвариантам доменной модели
Инструменты с AI-ассистентами для code review помогают сместить фокус:
— меньше шума про стиль
— больше внимания к логике и потенциальным багам
— автоматические подсказки прямо в PR
Хороший code review — это не «код красивый»,
а «код не сломается в проде».
18 301
Интеграционные тесты прямо в CI/CD - максимум уверенности в коде 🚀
Я запускаю интеграционные тесты прямо внутри CI/CD пайплайна.
Так я проверяю не абстракции и моки, а реальное поведение системы.
Всё это возможно благодаря:
- Docker
- Testcontainers
Идея простая:
ты поднимаешь реальные внешние сервисы как контейнеры и используешь их прямо в тестах.
В примере поднимаются:
- PostgreSQL
- Redis
- Keycloak
Контейнеры:
- автоматически стартуют перед тестами
- доступны из кода приложения
- уничтожаются после выполнения тестов
Почему это работает лучше моков:
- тесты максимально близки к продакшену
- одинаковое поведение локально и в CI
- сразу ловятся проблемы с конфигурацией, миграциями, auth
- меньше сюрпризов после деплоя
Особенно полезно для:
- backend-сервисов
- микросервисной архитектуры
- систем с авторизацией и внешними зависимостями
- .NET-приложений с серьёзной бизнес-логикой
Если хочешь вывести интеграционное тестирование в .NET на новый уровень — Testcontainers стоит попробовать обязательно.
#dotnet, #testing
18 301
⚡️ В мире #dotnet есть куда больше вариантов для messaging, чем RabbitMQ и Kafka.
И для real-time систем эти инструменты часто избыточны.
Большинство брокеров сообщений заточены под надёжность, сложную маршрутизацию и enterprise-сценарии.
Это отлично, когда нужны гарантии доставки и сложные пайплайны.
Но если система живёт на частых событиях, минимальной задержке и мгновенной реакции, этот вес начинает мешать.
Здесь идеально заходит NATS.
NATS - лёгкая и сверхбыстрая система обмена сообщениями, спроектированная именно для real-time:
- минимальная латентность
- простая модель
- высокая масштабируемость
Отлично подходит для:
- телеметрии и sensor data
- live-обновлений
- edge-систем
- сценариев, где важно «сейчас», а не «через секунду»
В статье подробно разобрано:
- когда NATS имеет смысл (а когда нет)
- сравнение с RabbitMQ и Kafka
- использование NATS в .NET с понятными примерами кода
- Pub/Sub, queue groups и request–reply
https://thecodeman.net/posts/introduction-to-nats-real-time-messaging
18 301
3 простые оптимизации, которые реально ускоряют код
1️⃣ Забирай данные пачкой
Меньше запросов — меньше сетевых задержек.
Вместо десятков запросов — один
IN (...).
2️⃣ Делай больше параллельно
Если задачи не зависят друг от друга — выполняй их одновременно.
Асинхронность часто даёт бесплатный прирост скорости.
3️⃣ Кэшируй результаты
Если данные не меняются — не пересчитывай и не запрашивай их заново.
Память дешевле времени.
Никакой магии и сложных алгоритмов — просто базовые приёмы, которые в реальных проектах дают самый заметный эффект.18 301
🚦 Feature Flags в .NET - как управлять релизами без redeploy
Feature flags (фиче-флаги) позволяют включать и выключать функциональность на лету, без повторного деплоя и риска для продакшена.
Идея простая:
код задеплоен → поведение управляется конфигурацией.
Что это даёт на практике:
— Постепенные релизы
Можно включить новую фичу сначала для 1%, 10% или конкретной группы пользователей.
— Быстрый rollback
Если что-то пошло не так — просто выключаете флаг. Без откатов и срочных хотфиксов.
— A/B тесты
Разные пользователи получают разное поведение одного и того же кода.
— Targeting пользователей
Фичи можно включать:
• по user id
• по роли
• по региону
• по environment (dev / staging / prod)
— Меньше фиче-веток
Код живёт в main, а не за флагами в git.
В .NET обычно используют:
- Microsoft.FeatureManagement
- Azure App Configuration
- LaunchDarkly / Unleash / ConfigCat
Где это особенно полезно:
- публичные API
- high-traffic сервисы
- SaaS-продукты
- экспериментальные и рискованные фичи
Коротко:
Feature flags превращают релиз из «одного опасного момента» в управляемый процесс.
Это один из самых мощных инструментов для зрелой backend-архитектуры.
👉 Подробнее
18 301
🔍 Как делать code review, которые находят реальные баги, а не только придираются к стилю
Большинство code review застревают на форматировании, нейминге и мелочах. В итоге реальные проблемы - логические ошибки, гонки, неправильные инварианты - проходят мимо.
Идея правильного code review:
— Проверять поведение кода, а не его внешний вид
— Искать сценарии отказа, а не соответствие линтеру
— Думать как система, а не как форматтер
Что реально стоит смотреть на ревью:
• Граничные случаи и ошибки в бизнес-логике
• Null / empty сценарии и некорректные состояния
• Побочные эффекты и порядок операций
• Работа с асинхронностью, транзакциями и ресурсами
• Соответствие инвариантам доменной модели
Инструменты с AI-ассистентами для code review помогают сместить фокус:
— меньше шума про стиль
— больше внимания к логике и потенциальным багам
— автоматические подсказки прямо в PR
Хороший code review — это не «код красивый»,
а «код не сломается в проде».
