C# (C Sharp) programming

⚡️ Один 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/

🖥 Unity 6 заходит в эпоху AI-геймдева: ИИ-агент теперь прямо в редакторе Unity выкатила в открытую бету AI-помощника, который работает не как «чатик сбоку», а как полноценный агент внутри проекта. Он видит контекст сцены, понимает структуру кода и может сам вносить изменения. Что умеет: — Plan Mode: разбивает задачу на шаги, пишет код, ищет ошибки и помогает выстроить архитектуру — Figma-интеграция: можно дать ссылку на макет, а Unity попробует собрать по нему интерфейс — Генерация ассетов: текстуры, звуки и 3D-объекты можно создавать по текстовому описанию — Откат изменений: если агент накосячил, правки можно быстро вернуть назад Для Pro и Enterprise функции уже доступны. В Personal-версии бету можно попробовать через trial. Геймдев постепенно превращается в работу не только с кодом и сценами, но и с агентами, которые собирают часть проекта по описанию. А вместе с этим, похоже, нас ждёт новая волна нейрослоп-игр в Steam. https://unity.com/ru/features/ai?utm_campaign=unity-ai-beta

В C# 15 появились union types. И это не косметика, это смена подхода к обработке ошибок. Вы можете явно описать результат как “либо значение, либо ошибка”, прямо на уровне языка. Без самодельных Result-классов, без лишних обёрток, без попыток использовать исключения там, где они неуместны. Раньше, ты либо городишь свой Result и работаешь с лишним бойлерплейтом. Либо тащишь сторонние библиотеки. Либо кидаешь исключения и теряешь контроль над потоком. С union types эта проблема решается . Pattern matching начинает работать так, как и должен. Ты не гадаешь, что вернул метод, а явно разбираешь все варианты. Код становится проще читать, проще тестировать и сложнее сломать.

Представь обычную ситуацию. Пользователь заходит в корзину, добавляет товары, что-то удаляет, меняет количество и оформляет заказ. В базе у тебя остаётся только финальное состояние. Просто запись “как есть сейчас”. Всё, что происходило до этого, исчезает. Ты не увидишь, какие товары удаляли, где пользователь сомневался, на каком шаге что-то пошло не так. Для отладки, аналитики и аудита это слепая зона. Пока у тебя простой CRUD на ASP.NET Core и Entity Framework Core, это может не мешать. Но как только появляются бизнес-процессы посложнее, начинаются проблемы. Нет истории - нет понимания. Здесь пригодится Event Sourcing. Вместо того чтобы перезаписывать состояние, ты сохраняешь каждое изменение как отдельное событие. Не “корзина сейчас такая”, а “в корзину добавили товар”, “товар удалили”, “оформили заказ”. События неизменяемые. Ты их не редактируешь и не удаляешь. Только добавляешь новые. Каждая сущность превращается в поток событий. У корзины своя последовательность: создали, добавили товар, удалили, оформили заказ. Текущее состояние собирается из этих событий. В C# это обычно выглядит как агрегат, который проигрывает события и восстанавливает состояние в памяти. Плюс там же проверяются бизнес-правила перед добавлением новых событий. Для чтения строятся отдельные модели. Например, через Marten или тот же PostgreSQL. Они обновляются сразу или асинхронно и отдают данные в API. В итоге у тебя не просто таблица с текущими значениями, а полная история системы. Можно откатиться на любой момент, разобрать баг, посмотреть реальные действия пользователя. CRUD отвечает на вопрос “что сейчас в базе”. Event Sourcing отвечает на вопрос “что реально происходило”. И для сложных систем это уже не архитектурный стиль, а вопрос выживания проекта. Гайд по эвент-сорсингу

⚡️ Версионирование API в Minimal APIs без лишней магии Если вы пишете API на ASP.NET Core и планируете жить с ним дольше одного релиза, версионирование лучше заложить сразу. Minimal APIs отлично дружат с ApiVersionSet: можно явно объявить поддерживаемые версии, включить репортинг доступных версий и привязать конкретный endpoint к нужной версии. В примере создается набор версий API: v1 - текущая стабильная версия v2 - новая версия для развития контракта После этого endpoint /api/v{version:apiVersion}/workouts/{workoutId} получает привязку через .WithApiVersionSet(apiVersionSet) и явно мапится на .MapToApiVersion(1). Главная идея простая: версия становится частью маршрута, а не скрытой договоренностью между клиентом и backend. Это особенно важно, когда API уже используют мобильные приложения, внешние интеграции или несколько фронтендов. Вы можете развивать v2, не ломая клиентов, которые все еще сидят на v1. Для C# backend-разработчика это один из тех паттернов, который выглядит мелочью на старте, но сильно экономит нервы на проде.

🖥 Что выведет код?

public decimal CalculateTotal(Order order)
{
    decimal total = 0;

    if (order != null)
    {
        if (order.Items != null)
        {
            foreach (var item in order.Items)
            {
                if (item != null)
                {
                    if (item.IsActive)
                    {
                        if (item.Price > 0)
                        {
                            if (item.Quantity > 0)
                            {
                                total += item.Price * item.Quantity;
                            }
                        }
                    }
                }
            }
        }

        if (order.Customer != null)
        {
            if (order.Customer.IsVip)
            {
                total = total * 0.9m;
            }
        }
    }

    return total;
}

Как бы ты почистил этот код? A - Заменить вложенные if на guard clauses B - Использовать LINQ для фильтрации и суммы C - Вынести скидку VIP в отдельный метод D - Все варианты выше @csharp_ci

🖥 На 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/

✔️ Rate Limiting по пользователю это must have для любого нормального API. Если ты до сих пор ограничиваешь по IP, у тебя уже есть проблема. Один шумный клиент может легко положить сервис для всех. Правильный подход это лимиты по User ID. Ты берёшь идентификатор пользователя из контекста и используешь его как partition key. В итоге каждый пользователь получает свой собственный лимит, нет конфликтов между клиентами, нет ложных блокировок, и API остаётся стабильным даже под нагрузкой. Плюс это честно, потому что один агрессивный пользователь не влияет на остальных. В ASP.NET Core это настраивается буквально в пару строк через AddRateLimiter с FixedWindow или SlidingWindow стратегией. Главная мысль в том, что rate limiting это не только про защиту от атак, это про контроль ресурсов и предсказуемость системы. Если у тебя есть публичный API и нет нормальных лимитов, это не вопрос если упадёт, это вопрос когда.

Никогда не возвращай null для коллекций в C# Спорное мнение, но на практике это один из самых частых источников багов. Когда метод возвращает null вместо списка, ты заставляешь каждого, кто его вызывает, писать дополнительную проверку. Иначе всё ломается на самом банальном месте:

foreach (var transaction in GetTransactions(userId))
{
    // boom, если null
}

В итоге получаешь: • лишние null-проверки повсюду • более громоздкий код • ошибки в рантайме, если кто-то забыл проверить Всегда этого возвращай пустую коллекцию:

Enumerable.Empty<T>()
new List<T>()
[] в C# 12
var transactions = GetTransactions(userId) 
                   ?? Enumerable.Empty<TransactionDto>();

Теперь код становится чище и понятнее. Ты всегда можешь итерироваться и не думаешь о null каждый раз. Хороший API - это тот, в работе с которым ошибиться почти невозможно.

⚡️ Вы слышали про Rust. Знаете, что он быстрый, безопасный и что за ним будущее. Осталось одно: сесть и выучить. Этот курс со Stepik- кратчайший путь от «знаю что такое Rust» до «пишу на нём». 6 модулей, 50 уроков, 143 теста. Ownership, borrowing, traits, async, Tokio, Axum, макросы, WASM — всё разложено по полочкам и закреплено практикой. Никакого видео на 40 минут ради одной мысли. Подробный текст, много кода, реальные задачи после каждого урока. На выходе — портфолио из 10+ проектов: от CLI-утилит до REST API с базой данных. 48 часов действует скидка 55 процентов: stepik.org/course/269250

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

👩‍💻 Приглашаем на открытый урок «Производительность кода на примере алгоритмов сортировки» 🗓 21 апреля в 20:00 МСК 🆓 На этом открытом уроке мы разберёмся, как скорость работы программы зависит от выбранного способа решения задачи - на понятном примере сортировки данных. 🔍 Что вы узнаете на вебинаре: – Почему существует несколько способов выполнить одну и ту же задачу. – Как разные подходы к сортировке данных влияют на скорость работы программы. – Почему одни решения подходят для маленьких объёмов данных, а другие — для больших. – Что происходит с программой, когда данных становится в 10, 100 или 1000 раз больше. – Как разработчики заранее прогнозируют производительность. 🔗 Ссылка на регистрацию: https://otus.pw/QZB5/?erid=2W5zFGs2tAd Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576 Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963.

🚨 Тихий убийца производительности в EF Core, о котором забывают почти все. Запрос выглядит идеально - пока у тебя мало данных. Потом начинается ад. Ты пишешь обычный Include, потом ещё один на ту же сущность… и не замечаешь, как EF Core превращает это в монструозный SQL с кучей JOIN’ов. Что происходит под капотом: EF делает несколько JOIN’ов → получается cross product → строки начинают дублироваться Итог: • данных в ответе становится в разы больше • память улетает • запросы резко тормозят И всё это без единой ошибки в коде. Решение есть и оно банально простое - Query Splitting. Вместо одного жирного запроса EF разбивает его на несколько аккуратных. Без дублирования, без раздувания результата, без боли. Одна настройка - и ты экономишь кучу ресурсов на проде. P.S. Если работаешь с EF Core - такие нюансы решают, будет ли твой сервис летать или умирать под нагрузкой.