متاح الآن! بحث تيليغرام 2025 — أهم رؤى العام 
C# (C Sharp) programming
الذهاب إلى القناة على Telegram
По всем вопросам- @notxxx1 Реестр РКН: https://clck.ru/3Fk3kb #VRHSZ
إظهار المزيد📈 نظرة تحليلية على قناة تيليجرام C# (C Sharp) programming
تُعد قناة C# (C Sharp) programming (@csharp_ci) في القطاع اللغوي الروسية لاعباً نشطاً. يضم المجتمع حالياً 18 306 مشتركاً، محتلاً المرتبة 7 332 في فئة التكنولوجيات والتطبيقات والمرتبة 36 865 في منطقة روسيا.
📊 مؤشرات الجمهور والحراك
منذ تأسيسه في невідомо، حقق المشروع نمواً سريعاً وجمع 18 306 مشتركاً.
بحسب آخر البيانات بتاريخ 16 يونيو, 2026، تحافظ القناة على نشاط مستقر. خلال آخر 30 يوماً تغيّر عدد الأعضاء بمقدار -7، وفي آخر 24 ساعة بمقدار -4، مع بقاء الوصول العام مرتفعاً.
- حالة التحقق: غير موثّقة
- معدل التفاعل (ER): يبلغ متوسط تفاعل الجمهور 19.58%. وخلال أول 24 ساعة من النشر يحصد المحتوى عادةً 7.47% من ردود الفعل نسبةً إلى إجمالي المشتركين.
- وصول المنشورات: يحصل كل منشور على متوسط 3 584 مشاهدة. وخلال اليوم الأول يجمع عادةً 1 368 مشاهدة.
- التفاعلات والاستجابة: يتفاعل الجمهور بانتظام؛ متوسط التفاعلات لكل منشور يبلغ 0.
- الاهتمامات الموضوعية: يركز المحتوى على مواضيع رئيسية مثل .net, api, логика, архитектура, string.
📝 الوصف وسياسة المحتوى
يصف المؤلف القناة بأنها مساحة للتعبير عن الآراء الذاتية:
“По всем вопросам- @notxxx1
Реестр РКН: https://clck.ru/3Fk3kb
#VRHSZ”
بفضل وتيرة التحديث المرتفعة (أحدث البيانات بتاريخ 17 يونيو, 2026) تحافظ القناة على حداثتها ومستوى وصول مرتفع. وتُظهر التحليلات تفاعلاً نشطاً من الجمهور، ما يجعلها نقطة تأثير مهمة ضمن فئة التكنولوجيات والتطبيقات.
18 306
المشتركون
-424 ساعات
+137 أيام
-730 أيام
أرشيف المشاركات
18 306
Не все стратегии балансировки нагрузки одинаково полезны.
Если ты используешь 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 306
.NET 9 стал гораздо устойчивее к сбоям 💪
В .NET 9 появились официальные пакеты для отказоустойчивости:
-
Microsoft.Extensions.Resilience
- Microsoft.Extensions.Http.Resilience
Они построены поверх Polly, поэтому API знакомый - легко описывать политики:
- retry
- circuit-breaker
- fallback
- timeout
- hedging
- rate limiter
Подключаете и ваши HTTP-клиенты и сервисы автоматически восстанавливаются при сетевых ошибках и таймаутах.
Итог: меньше падений и больше стабильности. Отлично для продакшена 🚀18 306
⚡️ Какие строки выведутся и в каком порядке(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 306
🔥 Как просто добавить 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 306
💻Полный перебор выглядит простым решением, пока не сталкивается с реальностью. Как только задача усложняется, перебор становится неприемлемо медленным — и именно здесь начинаются настоящие алгоритмы.
📆На открытом уроке вы напишете алгоритм Dancing Links Дональда Кнута — один из самых элегантных способов решения задач точного покрытия. Мы разберём, почему классический перебор не работает, и как четырёхсвязный список позволяет добавлять и удалять элементы практически без затрат.
Вы увидите, как несколько десятков строк кода решают задачи, которые выглядят непосильными для brute force. Реализуете алгоритм полностью, разберёте его внутреннюю механику и примените к задаче пентамино.
👉Встречаемся 12 января в 20:00 МСК в преддверие старта курса «Алгоритмы и структуры данных». Регистрация открыта: https://tglink.io/cb04fae31111?erid=2W5zFHHfYCx
Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.
18 306
✔️ 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 306
💡 В 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 306
🔍 Как делать code review, которые находят реальные баги, а не только придираются к стилю
Большинство code review застревают на форматировании, нейминге и мелочах. В итоге реальные проблемы - логические ошибки, гонки, неправильные инварианты - проходят мимо.
Идея правильного code review:
— Проверять поведение кода, а не его внешний вид
— Искать сценарии отказа, а не соответствие линтеру
— Думать как система, а не как форматтер
Что реально стоит смотреть на ревью:
• Граничные случаи и ошибки в бизнес-логике
• Null / empty сценарии и некорректные состояния
• Побочные эффекты и порядок операций
• Работа с асинхронностью, транзакциями и ресурсами
• Соответствие инвариантам доменной модели
Инструменты с AI-ассистентами для code review помогают сместить фокус:
— меньше шума про стиль
— больше внимания к логике и потенциальным багам
— автоматические подсказки прямо в PR
Хороший code review — это не «код красивый»,
а «код не сломается в проде».
18 306
Интеграционные тесты прямо в CI/CD - максимум уверенности в коде 🚀
Я запускаю интеграционные тесты прямо внутри CI/CD пайплайна.
Так я проверяю не абстракции и моки, а реальное поведение системы.
Всё это возможно благодаря:
- Docker
- Testcontainers
Идея простая:
ты поднимаешь реальные внешние сервисы как контейнеры и используешь их прямо в тестах.
В примере поднимаются:
- PostgreSQL
- Redis
- Keycloak
Контейнеры:
- автоматически стартуют перед тестами
- доступны из кода приложения
- уничтожаются после выполнения тестов
Почему это работает лучше моков:
- тесты максимально близки к продакшену
- одинаковое поведение локально и в CI
- сразу ловятся проблемы с конфигурацией, миграциями, auth
- меньше сюрпризов после деплоя
Особенно полезно для:
- backend-сервисов
- микросервисной архитектуры
- систем с авторизацией и внешними зависимостями
- .NET-приложений с серьёзной бизнес-логикой
Если хочешь вывести интеграционное тестирование в .NET на новый уровень — Testcontainers стоит попробовать обязательно.
#dotnet, #testing
18 306
⚡️ В мире #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 306
3 простые оптимизации, которые реально ускоряют код
1️⃣ Забирай данные пачкой
Меньше запросов — меньше сетевых задержек.
Вместо десятков запросов — один
IN (...).
2️⃣ Делай больше параллельно
Если задачи не зависят друг от друга — выполняй их одновременно.
Асинхронность часто даёт бесплатный прирост скорости.
3️⃣ Кэшируй результаты
Если данные не меняются — не пересчитывай и не запрашивай их заново.
Память дешевле времени.
Никакой магии и сложных алгоритмов — просто базовые приёмы, которые в реальных проектах дают самый заметный эффект.18 306
🚦 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 306
🔍 Как делать code review, которые находят реальные баги, а не только придираются к стилю
Большинство code review застревают на форматировании, нейминге и мелочах. В итоге реальные проблемы - логические ошибки, гонки, неправильные инварианты - проходят мимо.
Идея правильного code review:
— Проверять поведение кода, а не его внешний вид
— Искать сценарии отказа, а не соответствие линтеру
— Думать как система, а не как форматтер
Что реально стоит смотреть на ревью:
• Граничные случаи и ошибки в бизнес-логике
• Null / empty сценарии и некорректные состояния
• Побочные эффекты и порядок операций
• Работа с асинхронностью, транзакциями и ресурсами
• Соответствие инвариантам доменной модели
Инструменты с AI-ассистентами для code review помогают сместить фокус:
— меньше шума про стиль
— больше внимания к логике и потенциальным багам
— автоматические подсказки прямо в PR
Хороший code review — это не «код красивый»,
а «код не сломается в проде».
