en
Feedback

Don't get caught by a cheater! Telemetrio finds and tags such channels 👉 If you want to see the tag, subscribe

C# (C Sharp) programming

C# (C Sharp) programming

Open in Telegram

По всем вопросам- @notxxx1 Реестр РКН: https://clck.ru/3Fk3kb #VRHSZ

Show more

📈 Analytical overview of Telegram channel C# (C Sharp) programming

Channel C# (C Sharp) programming (@csharp_ci) in the Russian language segment is an active participant. Currently, the community unites 18 042 subscribers, ranking 7 244 in the Technologies & Applications category and 36 510 in the Russia region.

📊 Audience metrics and dynamics

Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 18 042 subscribers.

According to the latest data from 27 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by -40 over the last 30 days and by -15 over the last 24 hours, overall reach remains high.

  • Verification status: Not verified
  • Engagement rate (ER): The average audience engagement rate is 15.81%. Within the first 24 hours after publication, content typically collects 8.23% reactions from the total number of subscribers.
  • Post reach: On average, each post receives 2 853 views. Within the first day, a publication typically gains 1 486 views.
  • Reactions and interaction: The audience actively supports content: the average number of reactions per post is 0.
  • Thematic interests: Content is focused on key topics such as .net, api, логика, архитектура, string.

📝 Description and content policy

The author describes the resource as a platform for expressing subjective opinions:
“По всем вопросам- @notxxx1 Реестр РКН: https://clck.ru/3Fk3kb #VRHSZ”

Thanks to the high frequency of updates (latest data received on 28 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.

18 042
Subscribers
-1524 hours
-277 days
-4030 days
Posts Archive
Перестань падать из-за одного внешнего API - добавь Fallback в .NET через Resilience Pipeline 🛡️ Вместо того чтобы приложени
Перестань падать из-за одного внешнего API - добавь Fallback в .NET через Resilience Pipeline 🛡️ Вместо того чтобы приложение валилось, когда GitHub (или любой сервис) не отвечает, ты можешь вернуть безопасный дефолт и продолжить работу. Идея простая: Ты добавляешь fallback-стратегию в pipeline, и если запрос падает — система вернёт запасной результат. Что происходит в примере: — В DI регистрируется Resilience Pipeline — Добавляется FallbackStrategy — Если вызов неудачный, возвращается GitHubUser.Empty вместо исключения Дальше в endpoint ты не вызываешь HttpClient напрямую — ты запускаешь его через pipeline: pipeline.ExecuteAsync(...) И если API: ❌ упало ❌ вернуло ошибку ❌ словило таймаут Пользователь не увидит 500. Он получит контролируемый ответ. Это особенно важно для: - внешних API - микросервисов - нестабильных сетей - интеграций с SaaS Fallback — это не про «скрыть ошибку». Это про graceful degradation, когда система продолжает жить даже при частичных сбоях. Надёжность — это архитектура, а не try/catch в каждом методе. #dotnet #backend #architecture

⚙️ Вы настраиваете ASP.NET Core «по наитию» и тратите время на поиск, почему приложение ведет себя по-разному в продакшене и локально? 📆 29 января в 20:00 OTUS проводит открытый урок «Конфигурирование приложения ASP.NET Core» в преддверии старта курса «C# ASP.NET Core разработчик». На занятии разберем, как выстроить прозрачную и управляемую систему настроек: appsettings.json, провайдеры конфигурации, приоритет применения конфигураций, настройки специфичные для среды и шаблон Options для работы с настройками. Вы поймете, как проектировать конфигурации так, чтобы приложения были стабильными и предсказуемыми. ❗️Урок будет полезен разработчикам ASP.NET Core начального и среднего уровня, которые хотят систематизировать знания и работать по индустриальным стандартам. ➡️ Регистрируйтесь на бесплатный урок: https://tglink.io/f0de1b0a6e87?erid=2W5zFH3PFGL 🎁 Все участники открытого урока получат скидку на обучение. #реклама О рекламодателе

🖥 Как обычные Linux-пользователи смотрят файлы: $ ls -a А как смотрю я: $ echo */ *. * Этот трюк выводит всё “простым” спосо
🖥 Как обычные Linux-пользователи смотрят файлы:

$ ls -a
А как смотрю я:

$ echo */ *. *
Этот трюк выводит всё “простым” способом через glob-расширение:

- */   покажет папки
- *    покажет обычные файлы
- .*   покажет скрытые файлы
Плюс это удобно тем, что результат можно сразу передавать дальше в команды, не парся вывод ls.

📦 Всё ещё не используешь Central Package Management в .NET? Открой свой .csproj прямо сейчас. Пакеты обычно выглядят так: И
📦 Всё ещё не используешь Central Package Management в .NET? Открой свой .csproj прямо сейчас. Пакеты обычно выглядят так: <PackageReference Include="Serilog" Version="4.3.0" /> <PackageReference Include="WolverineFx" Version="5.6.0" /> И в итоге проект превращается в мусорку из версий. А теперь представь, что это будет так: <PackageReference Include="Serilog" /> <PackageReference Include="WolverineFx" /> Вот в этом и кайф Central Package Management. Что он даёт: ✅ .csproj становится чистым и читаемым ✅ никто случайно не поставит “левую” версию пакета ✅ вся команда работает на одинаковых версиях библиотек ✅ сборка становится предсказуемой и детерминированной Как работает: Ты управляешь версиями централизованно через файл Directory.Packages.props в корне репозитория. То есть версии пакетов задаются в одном месте, а проекты просто подключают зависимости без указания version. Если у тебя монорепа или несколько проектов - это must-have.

🖥 Многопоточность в .NET часто сводят к lock. Но в реальных системах этого недостаточно — особенно под нагрузкой, в легаси-коде и распределённых сценариях. 📕 На открытом уроке разберём, какие инструменты действительно есть в .NET и как выбирать подходящий примитив под конкретную задачу. Рассмотрим Monitor, Mutex, Semaphore, а также другие примитивы из System.Threading: ReaderWriterLockSlim, Barrier, ManualResetEventSlim, SpinLock. ❗️ Вы увидите практические примеры, типовые ошибки и узнаете, где блокировки становятся узким местом. Урок будет полезен разработчикам, работающим с высоконагруженными системами и легаси-кодом, а также тимлидам, которые проектируют архитектуру и отвечают за производительность. 📣 Встречаемся 27 января в 20:00 МСК в преддверии старта курса «C# Developer. Professional». Регистрация открыта: https://otus.pw/t6Xj/

Что выведет на экран этот код?
Anonymous voting

#ПятничныйКвиз #ДляСамыхМаленьких
#ПятничныйКвиз #ДляСамыхМаленьких

⚡️ Автоматическая регистрация Minimal APIs в .NET - без ручного маппинга Если в проекте 20+ endpoint’ов, app.MapGet/MapPost п
⚡️ Автоматическая регистрация Minimal APIs в .NET - без ручного маппинга Если в проекте 20+ endpoint’ов, app.MapGet/MapPost превращается в ад. Решение - авторегистрировать endpoints через DI. Идея: 1) Делаешь общий интерфейс IEndpoint 2) Каждый endpoint реализует его 3) На старте приложения сканируешь сборку, регистрируешь все реализации в DI 4) Достаёшь их из DI и вызываешь MapEndpoints() Плюсы: ✅ чистый Program.cs ✅ каждый endpoint в отдельном файле ✅ масштабируется без хаоса ✅ легко тестировать и поддерживать Пример паттерна:

builder.Services.AddEndpoints(typeof(Program).Assembly);

public interface IEndpoint
{
    void Map(IEndpointRouteBuilder app);
}

public static class EndpointExtensions
{
    public static IServiceCollection AddEndpoints(this IServiceCollection services, Assembly assembly)
    {
        var endpoints = assembly.DefinedTypes
            .Where(t => !t.IsAbstract && !t.IsInterface && typeof(IEndpoint).IsAssignableFrom(t))
            .Select(t => ServiceDescriptor.Transient(typeof(IEndpoint), t))
            .ToArray();

        services.TryAddEnumerable(endpoints);
        return services;
    }

    public static void MapEndpoints(this WebApplication app)
    {
        foreach (var endpoint in app.Services.GetServices<IEndpoint>())
            endpoint.Map(app);
    }
}

🚀 Опасен баг, который вылазит через 3 дня после релиза. И это ровно тот риск, который прячется в стандартном Options Pattern
+2
🚀 Опасен баг, который вылазит через 3 дня после релиза. И это ровно тот риск, который прячется в стандартном Options Pattern в .NET. Ты спокойно делаешь так: - биндишь appsettings.json в класс - инжектишь настройки через DI - приложение стартует без проблем ✅ А потом внезапно… В прод падает , потому что: ❌ не задан обязательный ApiKey ❌ RetryCount = 0 ❌ строка подключения пустая И ты узнаёшь об этом только тогда, когда кто-то нажмёт нужную кнопку в твоем приложении. Вот почему принцип Fail Fast критичен для конфигов: если конфигурация невалидна - приложение не должно запускаться вообще. Как это сделать правильно: используй расширение Options Pattern через IValidateOptions. Суть подхода: 1) задаём правила (например: ApiKey не null, `RetryCount > 0`) 2) регистрируем валидатор 3) если условия нарушены - DI кидает исключение сразу при старте ✅ Можно прйти дальше и подключиит FluentValidation, чтобы условия были: - чище - читабельнее - удобнее расширять Полная реализация: https://milanjovanovic.tech/blog/options-pattern-validation-in-aspnetcore-with-fluentvalidation?utm_source=X&utm_medium=social&utm_campaign=05.01.2026

⚡️ В .NET кэш - это всегда выбор: максимальная скорость или единые данные между серверами. IMemoryCache ✅ Очень быстрый ❌ Раб
⚡️ В .NET кэш - это всегда выбор: максимальная скорость или единые данные между серверами. IMemoryCache ✅ Очень быстрый ❌ Работает только внутри одной ноды (в кластере из 10 серверов у вас 10 разных кэшей) Redis / IDistributedCache ✅ Один общий кэш на все ноды - данные одинаковые ❌ Медленнее: сеть + сериализация + лишние накладные расходы Правильный подход - Hybrid Cache. Он не заставляет выбирать - он комбинирует оба мира: - L1 (Local / RAM) - сначала читаем из памяти приложения (самый быстрый слой) - L2 (Distributed / Redis) - если локально нет, идём в общий кэш - Source (DB/API) - если нет и там, берём из источника и прогреваем оба уровня 🚀 скорость как у MemoryCache 🔒 данные согласованы между нодами как в Redis 📉 меньше нагрузки на БД и меньше «холодных» запросов Microsoft делает нативный HybridCache, но если нужно решение уже сейчас - FusionCache остаётся самым надёжным и реально продакшн-готовым вариантом. 📌 Гайд

🎯 Открытый урок «Сетевой чат на C#». 🗓 22 января в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «C# Developer». На ве
🎯 Открытый урок «Сетевой чат на C#». 🗓 22 января в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «C# Developer». На вебинаре: ✔️ Рассмотрим написание сетевого приложения на C#. ✔️ Мы реализуем простые клиент и сервер с помощью одного из сетевых протоколов. ✔️Также затронем темы многопточности и асинхронности Кому будет полезно: • Вебинар будет полезен начинающим разработчикам, желающим разобраться в сетевом и многопочном\асинхронном программировании. Что вы получите: • По итогам вебинара смогут проектировать сетевые приложения. • Получат представление о работе сетевых протоколов, и многопоточности\асинхронности в приложениях. • На практике попробуют разработать такое приложение. 🔗 Ссылка на регистрацию: https://otus.pw/zifo/?erid=2W5zFJaPXHA Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

Что выведет на экран это код?
Anonymous voting

#ПятничныйКвиз
#ПятничныйКвиз

Не все стратегии балансировки нагрузки одинаково полезны. Если ты используешь YARP (Yet Another Reverse Proxy) в .NET - у нег
Не все стратегии балансировки нагрузки одинаково полезны. Если ты используешь 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 А какая стратегия у тебя стоит по умолчанию?

Обещанного 3 года ...
Обещанного 3 года ...

.NET 9 стал гораздо устойчивее к сбоям 💪 В .NET 9 появились официальные пакеты для отказоустойчивости: - Microsoft.Extension
.NET 9 стал гораздо устойчивее к сбоям 💪 В .NET 9 появились официальные пакеты для отказоустойчивости: - Microsoft.Extensions.Resilience - Microsoft.Extensions.Http.Resilience Они построены поверх Polly, поэтому API знакомый - легко описывать политики: - retry - circuit-breaker - fallback - timeout - hedging - rate limiter Подключаете и ваши HTTP-клиенты и сервисы автоматически восстанавливаются при сетевых ошибках и таймаутах. Итог: меньше падений и больше стабильности. Отлично для продакшена 🚀

⚡️ Какие строки выведутся и в каком порядке(override + overload + dynamic) using System; class Base { public virtual void Foo
⚡️ Какие строки выведутся и в каком порядке(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);
    }
}
📌 Ответ: Derived.Foo(object) Derived.Foo(string) Derived.Foo(string) Derived.Foo(string) Derived.Foo(string) Пояснение: 1) b.Foo("A") Статический тип переменной - Base. Компилятор видит только Foo(object). Вызов виртуальный, поэтому выполняется override: Derived.Foo(object) 2) ((Derived)b).Foo("A") Статический тип - Derived. Есть перегрузка Foo(string), она точнее для string: Derived.Foo(string) 3) dynamic d = b; d.Foo("A") dynamic откладывает выбор метода до runtime. Реальный тип объекта - Derived. Реальный тип аргумента - string: Derived.Foo(string) 4) object x = "A"; d.Foo(x) Для dynamic учитывается реальный тип аргумента. x содержит string: Derived.Foo(string) 5) d.Foo(null) null подходит и для object, и для string. string - более специфичный тип: Derived.Foo(string)

🔥 Как просто добавить multi-tenant в .NET через заголовок запроса Иногда нужно понимать, какому клиенту (tenant) принадлежит
🔥 Как просто добавить 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];
}

💻Полный перебор выглядит простым решением, пока не сталкивается с реальностью. Как только задача усложняется, перебор станов
💻Полный перебор выглядит простым решением, пока не сталкивается с реальностью. Как только задача усложняется, перебор становится неприемлемо медленным — и именно здесь начинаются настоящие алгоритмы. 📆На открытом уроке вы напишете алгоритм Dancing Links Дональда Кнута — один из самых элегантных способов решения задач точного покрытия. Мы разберём, почему классический перебор не работает, и как четырёхсвязный список позволяет добавлять и удалять элементы практически без затрат. Вы увидите, как несколько десятков строк кода решают задачи, которые выглядят непосильными для brute force. Реализуете алгоритм полностью, разберёте его внутреннюю механику и примените к задаче пентамино. 👉Встречаемся 12 января в 20:00 МСК в преддверие старта курса «Алгоритмы и структуры данных». Регистрация открыта: https://tglink.io/cb04fae31111?erid=2W5zFHHfYCx Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

✔️ C# стал языком 2025 года по версии TIOBE. Индекс TIOBE подвел итоги года: звание «Язык 2025 года» досталось C#, который по
✔️ 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/