Профессор Си

C# 12 and .NET 8 – Modern Cross-Platform Development Fundamentals Автор: Mark J. Price Дата выхода: 2023 #csharp #en #2O23 Скачать книгу

🔔Новые вакансии по C# за последние 14 дней 1️⃣ C# Developer Hunter Bond Hybrid · London, UK · 💰 от 8 333 £ 2️⃣ C# Developer (gamedev) Middle · Remote 3️⃣ C# Ontwikkelaar Macee Middle · Remote · Remote, Netherlands 4️⃣ Фулстек Разработчик c# (forex, crypto разработка программ для трейдинга) Westernpips Lead · Remote · 💰 150 000 – 180 000 ₽ 5️⃣ Senior Техлид C# Цифровые привычки Senior · Remote · 💰 300 000 – 350 000 ₽ 6️⃣ Cтарший Backend-разработчик VK (MAX) Remote · Москва 7️⃣ .NET C# Technical Lead Jalasoft Senior · Remote · Remote, Colombia 8️⃣ C# разработчик (WPF) Антереал Томск 9️⃣ Backend C# Junior+ Разработчик ФинТех Junior · Remote · 💰 100 000 – 150 000 ₽ 1️⃣0️⃣ SDET C# (UIS) Kaspersky Москва 1️⃣1️⃣ Автотестировщик (C#) ИТ-компания «Лоция» Middle · Remote 1️⃣2️⃣ Senior C# Developer Bell Integrator Senior · Москва ✈️ Talanto | #вакансии #csharp

⚙️ Гибридное кэширование Гибридный кэш это баланс между скоростью и масштабируемостью. Он объединяет два уровня хранения данных: 1️⃣ Кэш в памяти. Хранит часто используемые данные локально, обеспечивая моментальный доступ. 2️⃣ Распределенный кэш: Redis, SQL Server Cache. Используется для хранения данных, доступных нескольким серверам. То есть это метод, при котором данные сначала проверяются в локальном кэше, а если их там нет, запрашиваются из распределенного кэша, например, Redis. Настройка гибридного кэша в .NET Чтобы реализовать гибридное кэширование можно использовать HybridCache, который сочетает кэш в памяти и Redis. 1️⃣ Настроить локальный кэш 2️⃣ Добавить Redis как распределенный кэш 3️⃣ Реализовать логику работы с кэшем, используя стратегию «сначала память, потом Redis» ➡️ Подробнее о реализации HybridCache 🤔 Книги для шарписта

Один и тот же код может работать быстро или медленно — разница не в языке, а в том, как вы решаете задачу. Когда данных мало, это незаметно. Но как только объём растёт, ошибки в выборе алгоритма начинают стоить времени и ресурсов. 👩‍💻 Приглашаем на открытый урок «Производительность кода на примере алгоритмов сортировки» 🗓 21 апреля в 20:00 МСК 🆓 На этом открытом уроке мы разберёмся, как скорость работы программы зависит от выбранного способа решения задачи - на понятном примере сортировки данных. 🔍 Что вы узнаете на вебинаре: – Почему существует несколько способов выполнить одну и ту же задачу. – Как разные подходы к сортировке данных влияют на скорость работы программы. – Почему одни решения подходят для маленьких объёмов данных, а другие — для больших. – Что происходит с программой, когда данных становится в 10, 100 или 1000 раз больше. – Как разработчики заранее прогнозируют производительность. 🎯 Кому будет полезно: – Тем, кто только присматривается к профессии разработчика на C#. – Новичкам, которые начали изучать C# и хотят понимать, как писать «быстрый» код. – Всем, кто хочет разобраться, от чего зависит скорость работы приложений. – Тем, кто рассматривает обучение на курсе «Разработчик на C# с нуля» и хочет познакомиться с подходом к обучению. 🔗 Ссылка на регистрацию: https://vk.cc/cWFwrK Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

👀 Сортировать все ради одного значения — это дорогая привычка В продакшене до сих пор встречается LINQ паттерн, где коллекцию сначала сортируют, а потом берут первый элемент:

var youngest = people
    .OrderBy(p => p.Age)
    .First();

На вид код нормальный, но по факту он платит за сортировку, хотя нужна всего одна крайняя точка. Правильнее выразить намерение напрямую через MinBy:

var youngest = people.MinBy(p => p.Age);

MinBy возвращает элемент с минимальным ключом и не требует полной сортировки последовательности. Если в коде встречается OrderBy().First() или OrderByDescending().First(), это повод остановиться и проверить, не ищется ли просто минимум или максимум. Профессор Си

Основы протокола HTTP. Бесплатный урок курса «Проектирование API» API невозможно проектировать хорошо, если HTTP воспринимается как «просто способ отправить запрос». Ошибки в методах, заголовках, кодах ответа и семантике запросов быстро превращаются в неудобные интеграции, неочевидное поведение клиентов и лишние переделки уже после запуска. 📅 На открытом уроке 15 апреля 2026 в 20:00: — Разберём основы протокола HTTP с точки зрения проектирования API. — Поговорим о том, как устроено взаимодействие клиент–сервер, зачем нужны методы, заголовки, коды ответа и какие решения в дизайне интерфейсов напрямую зависят от понимания HTTP. — Это тот фундамент, без которого невозможно осознанно проектировать предсказуемые, удобные и устойчивые интерфейсы. Урок не для тех, кто хочет выучить пару кодов ответа и считать тему закрытой, или продолжает относиться к HTTP как к набору случайных соглашений без логики и правил. 👉 Записаться: https://vk.cc/cWnc5D Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

C# .NET Разработчик ЗП: 180 000 - 240 000 ₽ Гибрид https://talento.works/jobs/86b65e0f-3f51-4a94-9413-67ef7a2195bd

👩‍💻 Открытый урок «Облегчённые (Slim) примитивы синхронизации» 🗓 16 апреля в 20:00 МСК 🆓 На открытом уроке рассмотрим: ✔️ Проблему синхронизации доступа к общему ресурсу в многопоточном приложении в рамках внутрипроцессного взаимодействия; ✔️ Разберём классическую задачу читателей–писателей и её реализацию с использованием примитивов синхронизации из пространства имён System.Threading; ✔️ Отдельно обсудим, в каких случаях облегчённые версии примитивов (например, SemaphoreSlim и ReaderWriterLockSlim) оказываются эффективнее стандартных решений, таких как Monitor, Mutex и конструкция lock. Для кого: Вебинар будет полезен разработчикам, которые уже знакомы с базовыми механизмами синхронизации в .NET и хотят углубить понимание инструментов, предоставляемых стандартной библиотекой для построения безопасных и производительных многопоточных приложений. 🔗 Ссылка на регистрацию: https://vk.cc/cVMWrb Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

👩‍💻 Открытый урок «Производительность кода на примере алгоритмов сортировки» 🗓 21 апреля в 20:00 МСК 🆓 На этом открытом уроке мы разберёмся, как скорость работы программы зависит от выбранного способа решения задачи - на понятном примере сортировки данных. 🔍 Что вы узнаете на вебинаре: - Почему существует несколько способов выполнить одну и ту же задачу. - Как разные подходы к сортировке данных влияют на скорость работы программы. - Почему одни решения подходят для маленьких объёмов данных, а другие — для больших. - Что происходит с программой, когда данных становится в 10, 100 или 1000 раз больше. - Как разработчики заранее прогнозируют производительность. 🎯 Кому будет полезно: - Тем, кто только присматривается к профессии разработчика на C#. - Новичкам, которые начали изучать C# и хотят понимать, как писать «быстрый» код. - Всем, кто хочет разобраться, от чего зависит скорость работы приложений. - Тем, кто рассматривает обучение на курсе «Разработчик на C# с нуля» и хочет познакомиться с подходом к обучению. 🔗 Ссылка на регистрацию: https://vk.cc/cVDYi9 Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

Как Microsoft задушил Delphi, создав .NET: история одного программиста и одного чемодана Личный взгляд программиста с стажем на то, как Microsoft переманил Хейлсберга, создал .NET и вытеснил Delphi с технологической сцены. История предательства, перехода эпох и чемодана, который до сих пор скрипит в углу. https://habr.com/ru/articles/902476/

👩‍💻 Открытый урок «Как работают структуры данных C# "под капотом"» 🗓 13 апреля в 20:00 МСК 🆓 На этом открытом уроке мы простым и понятным языком разберём структуры данных, что происходит внутри программы, когда она хранит и обрабатывает данные. Что рассмотрим на вебинаре: ✔️ Внутреннее устройство ключевых коллекций ✔️ Принципы работы и алгоритмическую сложность операций ✔️ Особенности реализации, влияющие на производительность Кому будет полезно: ✔️ Начинающим разработчикам - чтобы углубить понимание платформы .NET и писать эффективный, надёжный код. ✔️ Тем, кто готовится к техническим собеседованиям (вопросы о внутреннем устройстве коллекций и сложности операций - классика интервью). ✔️ Всем, кто хочет осознанно выбирать структуры данных - избегать типичных ошибок, понимать компромиссы и узкие места. 🔗 Ссылка на регистрацию: https://vk.cc/cVx2Fg Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

⭐️ ValueTask в C# Мы уже разбирали ValueTask раньше, но сейчас напомним ключевые моменты. ValueTask это структура, которая может хранить либо готовый результат, либо Task, чтобы избежать аллокаций в простых случаях. Особенности использования ValueTask: • Повторное ожидание запрещено Вызывать await несколько раз для одного и того же ValueTask нельзя, так как это может привести к неожиданным результатам:

ValueTask<int> task = GetValueAsync();
int value1 = await task;
int value2 = await task; // Ошибка

• Конвертация в Task Eсли требуется передать ValueTask в API, которое ожидает Task, можно вызвать метод .AsTask():

Task<int> task = GetValueAsync().AsTask();

• Когда использовать ValueTask: + Операция часто завершается синхронно. + Создание объекта Task может быть слишком накладным. + Вы пишете библиотеку с высокой производительностью. • Когда НЕ использовать ValueTask: - Операция всегда асинхронна. - Производительность не является критически важной. - Приложение не оптимизировано под работу с ValueTask. Профессор Си

✏️ Не копируйте gitignore, генерируйте Мы раньше кидали эту команду. dotnet new gitignore делает все за вас. В ней уже прописаны все типичные исключения: каталоги bin/, obj/, кэш NuGet, файлы публикаций, временные артефакты IDE и прочие служебные данные, которые не должны попадать в репозиторий. Не нужно искать шаблон на GitHub или копировать его вручную — всё доступно из коробки. Профессор Си

⚡️ Apache Camel в архитектуре решений бэкенда 📅 4 февраля | 20:00 мск | бесплатно Хотите строить надёжные и гибкие интеграции между сервисами без лишней сложности?                                            На вебинаре разберём: - Роль Apache Camel в современной backend-архитектуре - Enterprise Integration Patterns и их практическое применение - Типовые сценарии: синхронные и асинхронные интеграции - Camel как связующее звено между микросервисами, брокерами сообщений и внешними системами - Архитектурные преимущества и реальные ограничения использования Apache Camel ✅ После вебинара вы сможете: - Определять, когда Apache Camel — правильный архитектурный выбор - Проектировать интеграционные потоки на основе проверенных паттернов - Строить устойчивые и слабо связанные backend-решения - Принимать осознанные архитектурные решения в области интеграций 👉 Регистрируйтесь https://otus.pw/ObyWM/ Занятие приурочено к старту курса "Software Architect", обучение на котором позволит освоить компетенции архитектора по моделированию и построению отказоустойчивых, масштабируемых и хорошо интегрируемых информационных систем. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

👀 Сортировать все ради одного значения — это дорогая привычка В продакшене до сих пор встречается LINQ паттерн, где коллекцию сначала сортируют, а потом берут первый элемент:

var youngest = people
    .OrderBy(p => p.Age)
    .First();

На вид код нормальный, но по факту он платит за сортировку, хотя нужна всего одна крайняя точка. Правильнее выразить намерение напрямую через MinBy:

var youngest = people.MinBy(p => p.Age);

MinBy возвращает элемент с минимальным ключом и не требует полной сортировки последовательности. Если в коде встречается OrderBy().First() или OrderByDescending().First(), это повод остановиться и проверить, не ищется ли просто минимум или максимум. Профессор Си

📎 Когда хочется коротко, но выходит долго GroupBy в LINQ удобный и выразительный, поэтому его часто тянут в любой код, где надо что то посчитать по ключу. Проблема в том, что GroupBy решает задачу группировки, а агрегация это частный случай, и за него иногда приходится платить лишним. Типичный паттерн выглядит так:

var totals = orders
    .GroupBy(o => o.CustomerId)
    .Select(g => new
    {
        CustomerId = g.Key,
        Total = g.Sum(o => o.Amount)
    })
    .ToList();

Выглядит читабельно, но GroupBy внутри строит структуру групп, а значит элементы буферизуются и создаются объекты группировок, даже если в итоге нужен только итоговый Total. Если нужна именно аккумуляция, проще и дешевле сделать один проход и складывать суммы в словарь:

var totals = new Dictionary<int, decimal>();
foreach (var order in orders)
{
    if (totals.TryGetValue(order.CustomerId, out var current))
        totals[order.CustomerId] = current + order.Amount;
    else
        totals[order.CustomerId] = order.Amount;
}

Это скучно, зато алгоритм читается буквально, один проход, явные обновления, без сюрпризов с материализацией групп. Профессор Си

⚡️ Готовые решения и лучшие практики для надёжной защиты API в архитектуре бэкенда 📅 26 января | 20:00 мск | бесплатно Хотите, чтобы ваши API были надёжно защищены без потери производительности? На вебинаре разберём: - Типовые угрозы и уязвимости API - Аутентификация и авторизация - Защита на уровне архитектуры - Роль API Gateway и прокси в обеспечении безопасности - Лучшие практики проектирования защищённых API и контрактов ✅ После вебинара вы сможете: - Проектировать API с учётом безопасности на уровне архитектуры - Применять готовые решения для защиты API - Осознанно балансировать между безопасностью, сложностью и производительностью 👉 Регистрация https://otus.pw/NvH2/ Занятие приурочено к старту курса "Software Architect" в OTUS. Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

👨‍💻 Когда if начинает распухать Паттерн стратегия подходит, когда один и тот же сценарий можно выполнить несколькими способами, и выбор зависит от условий. Вместо большого switch внутри сервиса разные варианты выносятся в отдельные классы с общим интерфейсом, а контекст просто делегирует работу выбранной реализации. Типовая схема такая. Есть интерфейс Strategy, есть несколько конкретных стратегий, и есть контекст, который держит ссылку на стратегию и вызывает ее метод, не зная деталей реализации. Это снижает связность и позволяет добавлять новые варианты без переписывания старого кода. Мини пример на C#:

public interface IDiscountStrategy
{
    decimal Apply(decimal total);
}

public sealed class RegularDiscount : IDiscountStrategy
{
    public decimal Apply(decimal total) => total;
}

public sealed class VipDiscount : IDiscountStrategy
{
    public decimal Apply(decimal total) => total * 0.9m;
}

public sealed class Checkout
{
    private readonly IDiscountStrategy _discount;

    public Checkout(IDiscountStrategy discount) => _discount = discount;

    public decimal TotalWithDiscount(decimal total) => _discount.Apply(total);
}

Если стратегия выбирается по условиям, условие должно выбирать объект, а не ветку кода:

var checkout = serviceProvider.GetRequiredService<Checkout>();
var total = checkout.TotalWithDiscount(100m);

Выбор стратегии лучше делать на границе приложения, например в фабрике или при конфигурации через DI, потому что прямое создание зависимостей внутри сервиса жестко привязывает код к конкретной реализации. Профессор Си