C# (C Sharp) programming

Алгоритму почти 70 лет, а он до сих пор живёт в ядре Linux. В 1957 году Wilkes, Wheeler и Gill описали быстрый способ считать количество установленных битов в числе. Не циклом по одному биту, а через маски и арифметику сразу над группами битов. Идея простая: - сначала считаем биты парами - потом группами по 4 - потом по байтам - в конце умножение собирает сумму в старший байт Если в процессоре нет инструкции POPCNT, Linux использует похожий подход в __sw_hweight64. Красивый пример того, как старый битовый трюк пережил десятилетия и всё ещё работает в современном системном коде.

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

✔️ Одна строчка .Result роняет ваш ASP.NET Core при CPU 8 %: разбор hill-climbing в .NET 9 TL;DR. Один foo.GetAsync().Result внутри middleware превращает ASP.NET Core, державший 50k RPS на p99 = 40 мс, в сервис на 12k RPS с p99 = 4 с при CPU 8 %. Виноват не блокирующий вызов сам по себе. Виноват hill-climbing: фидбэк-луп в ThreadPool, внутри которого живёт дискретное преобразование Фурье. Разбираемся по исходникам CoreCLR, как это работает, воспроизводим эффект на ~80 строках кода и показываем, почему SetMinThreads это не лечение, а анестезия. https://habr.com/ru/articles/1040804/

🖥 C# задачка с подвохом Что выведет код?

using System;
using System.Collections.Generic;

var list = new List<Func<int>>();

for (int i = 0; i < 3; i++)
{
    int x = i;
    list.Add(() => x);
    x = 100;
}

foreach (var f in list)
{
    Console.Write(f() + " ");
}

A) 0 1 2 😎 100 100 100 C) 3 3 3 D) 0 100 100 Правильный ответ: 😎 100 100 100 Почему так: Внутри каждой итерации создаётся новая локальная переменная x, и именно её захватывает лямбда. Кажется, что ответы должны быть 0 1 2, потому что x получает значение i. Но после добавления лямбды переменная x всё ещё та же самая захваченная переменная. Потом мы меняем её на 100. В итоге каждая лямбда хранит свою отдельную x, но каждая из этих x была изменена на 100.

🖥 Сервисы крутятся. Прод вроде живой. Но когда тимлид спрашивает: «почему здесь лучше ValueTask, а не Task?» или «как GC поведёт себя под нагрузкой?» - ты начинаешь плыть. И дело не в том, что ты плохо пишешь код. Просто большинство курсов заканчиваются ровно там, где начинается настоящий .NET. Этот курс про то, что обычно остаётся под капотом: - CLR - JIT - GC - Span - async state machine - Source Generators - lock-free подходы - OpenTelemetry - дампы в проде На практике разбираем, как .NET реально работает внутри: что происходит с кодом после компиляции, как память живёт под нагрузкой, почему async иногда помогает, а иногда ломает производительность, как читать проблемы по дампам и метрикам, а не гадать по логам. Если хочешь дойти до уровня, где система для тебя не чёрный ящик, а инструмент, который ты понимаешь до IL, - велкам. Сейчас на stepik доступна скидка 55%: https://stepik.org/a/288694

Полезная находка для геймдевов: большая коллекция open-source игр в одном месте. В репозитории собраны десятки проектов разных жанров. Всё разложено по категориям, у каждой игры есть краткое описание и ссылка на исходники. Можно смотреть, как устроены реальные игровые проекты, разбирать архитектуру, контрибьютить или просто запускать и играть. Для тех, кто учится геймдеву, это почти готовая база примеров из живого кода. https://github.com/bobeff/open-source-games

📌 OpenAI показала редкий для ИИ результат: внутренняя модель самостоятельно нашла контрпример к известной задаче из дискретной геометрии, которую Пал Эрдёш сформулировал ещё в 1946 году. Суть задачи простая: есть n точек на плоскости. Нужно понять, сколько пар точек могут находиться ровно на расстоянии 1 друг от друга. Долгое время считалось, что почти оптимальный ответ дают конструкции, похожие на квадратную решётку. Модель OpenAI показала, что это неверно. Она построила бесконечное семейство конфигураций, где таких пар получается заметно больше, чем ожидалось. То есть была опровергнута не мелкая техническая деталь, а известная гипотеза, вокруг которой десятилетиями строились оценки. Модель связала задачу о точках на плоскости с алгебраической теорией чисел. В доказательстве используются решётки Минковского (способ превратить числа из алгебраической теории чисел в точки в обычном евклидовом пространстве), элементы нормы один и pro-3 башни числовых полей. Это инструменты из другой части математики, и именно их перенос в геометрию дал результат. Нога Алон из Принстона отметил, что ответ оказался неожиданным, а применённые методы выглядят элегантно и нетривиально. При этом доказательство не даёт нового «чисто геометрического» метода, на который многие надеялись. Гипотеза опровергнута, но сама структура задачи стала ещё интереснее. Задачу сформулировал ИИ, решение сгенерировала внутренняя модель OpenAI, первичная проверка тоже прошла через автоматический ИИ-пайплайн. После этого люди проверили детали, улучшили изложение и довели работу до публикации. Модель сама нашла неочевидную связь между разными областями математики и получила результат по открытой задаче высокого уровня. Оригинал: https://openai.com/index/model-disproves-discrete-geometry-conjecture/ @ai_machinelearning_big_data

Форма логина и JWT-токен — ещё не безопасность приложения. На практике ошибки в аутентификации и авторизации становятся причиной утечек данных, проблем с доступом и уязвимостей, которые сложно обнаружить до выхода системы в production. 26 мая в 20:00 МСК приглашаем вас на открытый урок курса «C# ASP.NET Core-разработчик». На занятии разберём, как в ASP.NET Core устроены pipeline, middleware и схемы аутентификации. Покажем, как правильно использовать JWT, cookies, claims, роли и policy-based авторизацию для гибкого и безопасного контроля доступа. Отдельно обсудим типичные ошибки, которые встречаются в production: небезопасное хранение токенов, ошибки настройки схем и проблемы в логике авторизации. Урок будет полезен .NET-разработчикам, которые хотят систематизировать знания по безопасности веб-приложений и увереннее работать с ASP.NET Core в реальных проектах. Регистрация уже открыта: https://otus.pw/6I5f/?erid=2W5zFGd7RPP Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

15 проезный .NET-библиотек, которые используют senior-разработчики Open-source библиотеки, которые делают код чище, тесты надёжнее, а разработку быстрее. **HTTP, устойчивость и DI** **1. Refit** Превращает REST API в типизированные C# интерфейсы. Меньше boilerplate вокруг HttpClient. GitHub: https://github.com/reactiveui/refit 2. Polly Retry, circuit breaker, timeout и resilience-политики для исходящих вызовов. GitHub: https://github.com/App-vNext/Polly 3. Scrutor Автосканирование и регистрация сервисов в DI по конвенциям. GitHub: https://github.com/khellang/Scrutor Тестирование 4. Bogus Генератор реалистичных fake-данных для тестов и сидинга. GitHub: https://github.com/bchavez/Bogus 5. Verify Snapshot-тесты для .NET: один раз утвердил вывод, дальше ловишь регрессии. GitHub: https://github.com/VerifyTests/Verify 6. Testcontainers for .NET Поднимает реальный PostgreSQL, SQL Server, Redis и другие сервисы в Docker для интеграционных тестов. GitHub: https://github.com/testcontainers/testcontainers-dotnet API и фоновые задачи 7. FastEndpoints Быстрые Minimal API по паттерну REPR без раздутых контроллеров. Сайт: https://fast-endpoints.com GitHub: https://github.com/FastEndpoints/FastEndpoints 8. TickerQ Нативный планировщик фоновых задач без Hangfire, Quartz и лишнего оверхеда. GitHub: https://github.com/Arcenox-co/TickerQ 9. HotChocolate Мощный GraphQL-сервер для .NET, когда один гибкий endpoint удобнее десятков REST-маршрутов. Сайт: https://chillicream.com/docs/hotchocolate GitHub: https://github.com/ChilliCream/graphql-platform Микросервисы и messaging 10. Dapr Service discovery, pub/sub и state management для микросервисов без лишней инфраструктурной сантехники. Сайт: https://dapr.io GitHub: https://github.com/dapr/dotnet-sdk 11. Wolverine Mediator и messaging в одном фреймворке. Как MediatR, только шире по возможностям. Сайт: https://wolverinefx.net GitHub: https://github.com/JasperFx/wolverine Утилиты и работа с данными 12. UnitsNet Безопасная работа с единицами измерения вместо сырых double для температуры, скорости и расстояний. GitHub: https://github.com/angularsen/UnitsNet 13. Humanizer Превращает строки, даты, числа и enum-ы в читаемый вид одной строкой кода. GitHub: https://github.com/Humanizr/Humanizer 14. ImageSharp Обработка, ресайз и конвертация изображений в .NET. Кросс-платформенно, без GDI+. Сайт: https://sixlabors.com/products/imagesharp GitHub: https://github.com/SixLabors/ImageSharp Архитектура 15. ArchUnitNET Тесты для архитектурных правил. Нарушения слоёв и Clean Architecture падают прямо в CI. GitHub: https://github.com/TNG/ArchUnitNET

🖥 C# Roadmap: с нуля до профи Практическое руководство по росту в C#-разработке. Материал собран для тех, кто хочет получить инженерную глубину, а не просто накликать CRUD по туториалам. Здесь последовательность изучения, лучшие практики, ресурсы и трезвый разбор того, как работать с ИИ-инструментами и оставаться востребованным. https://github.com/Develp10/Csharp_Roadmap/

#ПятничныйКвиз #МыЗнаемТолкВИзвращениях

⚡️ Один SQL-запрос выполнялся за 298 мс. Почти такой же - за 0,66 мс. Разница в 451 раз из-за одной строки. Ситуация обычная: cursor pagination, сортировка по date DESC, id DESC, лимит на 1000 записей и composite index по (date, id). На первый взгляд, все должно работать быстро. Но EXPLAIN ANALYZE показывает другое: Postgres вроде бы использует Index Scan, но после этого выкидывает 900 000 строк через Filter. То есть индекс есть, но запрос все равно тащит слишком много лишнего. Проблема в условии: `date < @date OR (date = @date AND id <= @lastId)` Для разработчика это выглядит логично: сначала сравниваем дату, потом id. Но для оптимизатора такой OR плохо ложится на composite index. В итоге база не может сразу пойти по нужному диапазону и вынуждена фильтровать огромный кусок данных. Правильнее записать условие через tuple comparison: `(date, id) <= (@date, @lastId)` Смысл тот же, но для Postgres это уже понятный диапазон по составному индексу. И результат: 298 мс превращаются в 0,66 мс. Индекс сам по себе ничего не гарантирует. Важно не только создать индекс, но и написать запрос так, чтобы оптимизатор реально смог его использовать.

📌 UUID v7 - это почти ULID, только нативно в .NET Раньше в .NET для идентификаторов чаще всего использовали обычный Guid.NewGuid(). Проблема в том, что классический UUID случайный. Для уникальности это удобно, но для базы данных - не всегда. Когда значения генерируются хаотично, новые записи вставляются в разные части индекса. Отсюда: - больше фрагментации - дороже вставки - чаще перестраиваются страницы индекса - хуже поведение на больших таблицах Поэтому многие разработчики начали использовать ULID. ULID состоит из двух частей: - timestamp - random За счет timestamp такие ID сортируются по времени, а значит база может вставлять новые записи более последовательно. Но начиная с .NET 9 появился встроенный вариант: Guid.CreateVersion7() UUID v7 тоже содержит временную часть, поэтому лучше подходит для индексируемых ключей, чем полностью случайный UUID. Главное отличие: ULID - отдельный формат и часто сторонняя библиотека. UUID v7 - обычный Guid, который уже поддерживается в .NET. Для новых проектов это выглядит как более разумный дефолт: - не Guid.NewGuid() - не отдельный ULID-пакет - а Guid.CreateVersion7() Особенно если Guid используется как primary key в базе.

🖥 На Stepik обновили курс «C# с нуля до профи» Представьте: через четыре месяца вы открываете чужой .NET-проект и читаете его как книгу. IServiceCollection не вызывает ступора. async Task<IActionResult> пишется на автомате. Вы точно знаете, почему EF Core сгенерировал именно такой SQL - и как переписать запрос, чтобы он летал. Это не фантазия. Это результат после 16 модулей, в которых каждая концепция объясняется через код и закрепляется практикой. ООП, SOLID, LINQ, async/await, DI, EF Core, ASP.NET Core, Docker, Kubernetes - всё, что казалось магией, станет рабочим инструментом. А бонусом - портфолио проектов: от CLI-утилит и REST API до собственного SaaS с multi-tenancy, JWT и деплоем в Kubernetes под TLS. Скидка - 58% доступна 48 часов: https://stepik.org/a/282984/

Одна функция в C однажды положила заметную часть раннего интернета. В 1988 году в стандартной библиотеке C была функция `gets()`. Она читала ввод пользователя в буфер, но не проверяла его размер. Если данных приходило больше, чем помещалось, они просто начинали затирать соседнюю память. Именно это использовал Robert Morris в знаменитом Morris Worm. Червь атаковал `fingerd`, переполнял буфер и заставлял систему выполнять чужой код. Итог: около 6000 машин были заражены за считанные часы. По оценкам того времени, это была примерно десятая часть всего интернета. Самое безумное здесь не сам червь, а то, насколько маленькой была причина. Один небезопасный вызов. Один буфер без проверки. Одна функция, которую годами использовали как обычный инструмент. Позже `gets()` признали настолько опасной, что её фактически выкинули из современного C. Урок простой: в системном программировании безопасность часто ломается не на сложной криптографии, а на банальном «а что будет, если ввод окажется длиннее, чем мы ожидали?» #history

Хватит копировать один и тот же unit test Если тест отличается только входными данными, не нужно плодить десятки одинаковых методов. В xUnit для этого есть parameterized tests, они же data-driven tests. Вы пишете один тест, а потом прогоняете его на разных наборах данных. Самый простой вариант - [InlineData(...)], когда параметры можно прямо указать над тестом. Если данных больше или нужна нормальная типизация, можно вынести их в TheoryData<T> и подключить через [ClassData(typeof(...))]. Смысл простой: меньше копипасты, чище тесты, проще добавлять новые кейсы. Вместо пяти почти одинаковых тестов - один понятный сценарий и набор входных данных. Для xUnit это один из тех приемов, который быстро окупается в любом C# проекте.

🖥 Курс «Git Pro: от первого коммита до уровня senior» - на Stepik project_final_v2_FINAL_truly_final - знакомо? Значит, пора. Большинство разработчиков знают 5 команд Git и боятся шестую. Коммитят в main, гуглят «how to undo» и копируют папку «на всякий случай». Это не работа - это выживание. После курса вы: — делаете rebase, не задерживая дыхание; — разбираете конфликт на 200 файлов по алгоритму; — возвращаете «потерянные навсегда» коммиты за 30 секунд через reflog; — пишете историю, которую не стыдно показать на code review. Git Flow, trunk-based, Pull Request, защита веток, CI/CD-хуки — всё, что отличает джуна от senior в командной работе. Скидка 53%, 48 часов: https://stepik.org/course/284799/