День четыреста восемьдесят пятый. #PerformanceTips
Лучшие Практики по Производительности в C#. Начало
Недавно нашёл статью со списком «шаблонов кода, которых следует избегать, потому что они плохо работают в смысле производительности». Автор пишет, что все пункты в списке так или иначе вызывали проблемы с производительностью. Хотя, стоит оговориться, что не все советы могут работать во всех случаях.

1. Синхронное ожидание асинхронного кода
Не ожидайте синхронно незавершённых задач. Включая, но не ограничиваясь: Task.Wait, Task.Result, Task.GetAwaiter().GetResult(), Task.WaitAny, Task.WaitAll. Более общий совет: любая синхронная зависимость между двумя потоками пула может вызвать истощение пула потоков.

2. ConfigureAwait
Если ваш код может быть исполнен без захвата контекста синхронизации, используйте ConfigureAwait(false) для каждого вызова await. Однако обратите внимание, что ConfigureAwait имеет смысл только при использовании ключевого слова await. Например, этот код не имеет смысла:

var result = ProcessAsync().ConfigureAwait(false).GetAwaiter().GetResult();

Подробнее о ConfigureAwait в серии постов с тегом #AsyncAwaitFAQ

3. async void
Никогда не используйте async void. Исключение, выброшенное в таком методе, распространяется в контекст синхронизации и обычно приводит к сбою всего приложения. Если вы не можете вернуть задачу в свой метод (например, потому что вы реализуете интерфейс), переместите асинхронный код метод-обёртку и вызовите его:

interface IInterface {
  void DoSomething();
}
class Implementation : IInterface {
  public void DoSomething() {
    _ = DoSomethingAsync();
  }
  private async Task DoSomethingAsync() {
    await Task.Delay(100);
  }
}

4. По возможности избегайте слова async
По привычке вы можете написать:

public async Task CallAsync() {
  var client = new Client();
  return await client.GetAsync();
}

Хотя код семантически корректен, использование ключевого слова async здесь не требуется и может привести к значительным накладным расходам в «горячих путях». Попробуйте удалить его, если это возможно:

public Task CallAsync() {
  var client = new Client();
  return client.GetAsync();
}

Однако имейте в виду, что вы не можете использовать эту оптимизацию, когда ваш код упакован в блоки (например, try/catch или using):

public async Task Correct() {
  using (var client = new Client()) {
    return await client.GetAsync();
  }
}
public Task Incorrect() {
  using (var client = new Client()) {
    return client.GetAsync();
  }
}

В методе Incorrect, поскольку задача не ожидается внутри блока using, клиент может быть удален до завершения вызова GetAsync.

Продолжение следует…

Источник: https://medium.com/@kevingosse/performance-best-practices-in-c-b85a47bdd93a

День четыреста восемьдесят шестой. #PerformanceTips
Лучшие Практики по Производительности в C#. Продолжение
5. Сравнения Строк Чувствительные к Культуре
Если у вас нет причин использовать чувствительные к культуре сравнения строк, всегда используйте нечувствительные сравнения (с параметром StringComparison.Ordinal). Хотя это и не имеет большого значения для латиницы из-за внутренних оптимизаций, сравнение происходит на порядок медленнее для других культур (до 2 порядков в Linux). Поскольку сравнение строк является частой операцией в большинстве приложений, такие мелкие задержки быстро накапливаются.

6. ConcurrentBag<T>
Не используйте ConcurrentBag<T> без тестирования производительности. Эта коллекция была разработана для очень специфических случаев использования (когда большую часть времени элемент извлекается из контейнера добавившим его потоком) и страдает от проблем с производительностью, если используется иначе. Если вам нужна конкурентная коллекция, рассмотрите ConcurrentQueue<T>. Подробнее о потокобезопасных коллекциях.

7. ReaderWriterLock<T>/ReaderWriterLockSlim<T>
Не используйте ReaderWriterLock<T>/ReaderWriterLockSlim<T> без тестирования производительности. Стоимость их использования намного выше, чем у простого монитора (используемого с ключевым словом lock). Если количество читателей критического блока не очень велико, уровня параллелизма будет недостаточно для амортизации возросших издержек, и код будет работать хуже.

8. Используйте Лямбда-Выражения Вместо Чистого Предиката
Рассмотрим следующий код:

private static bool Filter(int i) {
  return i % 2 == 0;
}

И два варианта вызова:

list.Where(i => Filter(i));

и

list.Where(Filter);

Второй вариант приводит к выделению памяти в куче при каждом вызове, компилируясь в следующую конструкцию:

list.Where(new Func<int,bool>(Filter));

Лямбда-выражение использует оптимизацию компилятора и кэширует делегат в статическое поле.
*Примечание: я быстренько протестировал оба варианта в консольном приложении на предмет быстродействия и использования памяти и не нашёл никаких отличий ни в Framework, ни в Core. Поэтому есть подозрение, что оптимизация происходит в любом случае, а этот совет либо устарел, либо не проверялся автором.

Продолжение следует…

Источник: https://medium.com/@kevingosse/performance-best-practices-in-c-b85a47bdd93a

День четыреста восемьдесят седьмой. #PerformanceTips
Лучшие Практики по Производительности в C#. Продолжение
9. Преобразование Перечислений в Строку
Вызов Enum.ToString в .Net является дорогостоящим, поскольку для преобразования используется рефлексия, а вызов виртуального метода структуры приводит к боксингу. Этого следует по возможности избегать. Часто перечисления могут быть заменены константами:

public enum Numbers {
  One, Two, …
}
public static class Numbers {
  public const string One = "One";
  public const string Two = "Two";
  …
}

В обоих случаях можно использовать Numbers.One, Numbers.Two,…

10. Сравнения Перечислений
Примечание: это поведение оптимизировано, начиная с .Net Core 2.1
При использовании перечислений в качестве флагов может возникнуть соблазн использовать метод Enum.HasFlag:

[Flags]
public enum Options {
  Opt1 = 1, Opt2 = 2, Opt3 = 4
}
…
private Options option;
public bool IsOpt2() => option.HasFlag(Options.Opt2);

Этот код приводит к боксингу для преобразования Options.Opt2 в Enum и для виртуального вызова HasFlag на структуре, делает код необоснованно дорогим. Вместо этого можно использовать бинарные операторы:

public bool IsOpt2() => (option & Options.Opt2 == Options.Opt2);

Подробнее про битовые флаги

11. Реализуйте Проверку на Равенство для Структур
При использовании struct в сравнениях (например, при использовании в качестве ключа для словаря) необходимо переопределить методы Equals и GetHashCode. Реализация по умолчанию использует рефлексию и очень медленная. Подробнее

12. Избегайте Ненужного Боксинга при Использовании Структур с Интерфейсами
Рассмотрим следующий код:

public class IntValue : IValue {}

public void SendValue(IValue value) {…}
public void LogValue(IValue value) {…}

public void DoStuff() {
  var value = new IntValue();
  LogValue(value);
  SendValue(value);
}

Соблазнительно сделать IntValue структурой, чтобы избежать выделения памяти в куче. Но поскольку AddValue и SendValue принимают интерфейс, а интерфейсы имеют ссылочную семантику, значение будет упаковываться при каждом вызове, сводя на нет преимущества «оптимизации». На самом деле, производительность может быть даже хуже, чем если бы IntValue был классом. Если же вы создаёте API, которому может быть передана структура, попробуйте использовать обобщённые методы:

public void SendValue<T>(T value) where T : IValue {…}
public void LogValue<T>(T value) where T : IValue {…}

Хотя на первый взгляд создание таких методов выглядит бесполезным, на самом деле это позволяет избежать боксинга, когда IntValue является структурой.

Продолжение следует…

Источник: https://medium.com/@kevingosse/performance-best-practices-in-c-b85a47bdd93a

День четыреста восемьдесят восьмой. #PerformanceTips
Лучшие Практики по Производительности в C#. Окончание
13. Код Подписчиков CancellationToken Всегда Встраивается
Когда вы отменяете задачу через CancellationTokenSource, код всех подписчиков будет выполняться в текущем потоке. Это может привести к незапланированным паузам или даже неочевидным взаимным блокировкам:

var cts = new CancellationTokenSource ();
cts.Token.Register (() => Thread.Sleep (5000));
cts.Cancel (); // Это вызов заблокируется на 5 секунд

Вы не можете отказаться от этого поведения. Поэтому, при отмене через CancellationTokenSource, спросите себя, можете ли вы позволить текущему потоку исполнять другой код. Если нет, оберните вызов Cancel в Task.Run, чтобы выполнить его в пуле потоков. Подробнее о CancellationToken.

14. Код Продолжений TaskCompletionSource Часто Встраивается
Код продолжений TaskCompletionSource также часто встраивается. Это хорошая оптимизация, но она может быть причиной неочевидных ошибок. Их можно избежать, передав параметру TaskCompletionSource параметр TaskCreationOptions.RunContinuationsAsynchronously.
Если у вас нет веских причин этого не делать, всегда используйте этот параметр при создании TaskCompletionSource.
Внимание: код также скомпилируется, если вы используете TaskContinuationOptions.RunContinuationsAsynchronously. Но этот параметр будет проигнорирован, и продолжения будут оставаться встроенными. Это удивительно распространенная ошибка, потому что TaskContinuationOptions предшествует TaskCreationOptions при автозаполнении.

15. Task.Run / Task.Factory.StartNew
Если у вас нет причин использовать Task.Factory.StartNew, отдавайте предпочтение Task.Run для запуска фоновой задачи. Task.Run использует более безопасные значения по умолчанию, и, что более важно автоматически разворачивает возвращаемую задачу, что может предотвратить ошибки в асинхронных методах:

class Program {
  public static async Task ProcessAsync() {
    await Task.Delay(2000);
    Console.WriteLine("Processing done");
  }
  static async Task Main(string[] args) {
    await Task.Factory.StartNew(ProcessAsync);
    Console.WriteLine("End of program");
    Console.ReadLine();
  }
}

Из кода это не очевидно, но "End of program" будет выведено раньше, чем "Processing done", потому что Task.Factory.StartNew вернёт Task<Task>, а код ожидает завершения только внешней задачи. Исправить это можно, используя либо

await Task.Factory.StartNew(ProcessAsync).Unwrap();

либо

await Task.Run(ProcessAsync);

Task.Factory.StartNew лучше использовать в следующих случаях:
- Запуск задачи в другом планировщике
- Выполнение задачи в выделенном потоке (с помощью TaskCreationOptions.LongRunning)
- Постановка задачи в глобальную очередь пула потоков (с помощью TaskCreationOptions.PreferFairness)

Источник: https://medium.com/@kevingosse/performance-best-practices-in-c-b85a47bdd93a

День четыреста восемьдесят девятый.
Давненько на канале не было ссылок на видосики. Вот наткнулся на канал Raw Coding и посмотрел видео In/Out Middleware Explained соответственно про Middleware (Промежуточное ПО). Немножко путано, но вполне толково автор объясняет суть пайплайна обработки, который используется как в Asp.net Core, так и в Angular и т.п.
И что хотелось бы отметить, начинает он с самых азов, создавая пайплайн с нуля и объясняя и решая проблемы, которые встречаются на пути, а только потом переходит к тому, как пайплайн используется.
Не сильно заморачивайтесь насчёт кода, там в качестве примера автор использует редактор LinqPad и некоторый его внутренний функционал, вроде функции Dump(). Важно понять общую концепцию, чтобы потом видеть паттерн в самых разных системах (что автор объясняет в конце).

День четыреста девяностый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
43. Знайте, Как Использовать Инструменты Командной Строки
Сегодня многие инструменты разработки ПО реализованы в виде интегрированных сред разработки (IDE). Microsoft Visual Studio и Eclipse - два популярных примера, хотя есть и много других. В IDE много приятных вещей. Они не только просты в использовании, но и помогают программисту не заботиться о мелких деталях, связанных с процессом сборки.

Но простота использования имеет свои недостатки. Как правило, когда инструмент прост в использовании, это потому, что инструмент принимает решения за вас и делает много всего автоматически, за кулисами. Таким образом, если IDE является единственной средой программирования, которую вы используете, вы никогда не сможете полностью понять, что на самом деле делают ваши инструменты. Вы нажимаете кнопку, происходит какое-то волшебство, и исполняемый файл появляется в папке проекта.

Работая с инструментами сборки из командной строки, вы узнаете намного больше о том, что делают инструменты во время сборки вашего проекта. Написание собственных настроек сборки поможет вам понять все этапы (компиляция, сборка, компоновка и т.д.), которые используются для создания исполняемого файла. Экспериментировать с множеством параметров командной строки также полезно в образовательных целях. Вы можете использовать инструменты командной строки, такие как msbuild, GCC или те, которые поставляются с вашей IDE. В конце концов, хорошо разработанная IDE - это просто графическая оболочка для набора инструментов командной строки.

Помимо улучшения понимания процесса сборки, есть некоторые задачи, которые можно выполнить проще или эффективнее с помощью инструментов командной строки, чем с помощью IDE. Например, возможности поиска и замены, предоставляемые утилитами grep и sed, часто более мощные, чем в IDE. Инструменты командной строки поддерживают сценарии, что позволяет автоматизировать такие задачи, как создание запланированных ежедневных сборок, создание нескольких версий проекта и запуск набора тестов. В IDE этот вид автоматизации может быть более сложным (если не невозможным), поскольку параметры сборки обычно задаются с помощью диалоговых окон GUI, а процесс сборки вызывается щелчком мыши. Если вы никогда не выходили за пределы IDE, вы можете даже не осознавать, что такие виды автоматических задач возможны.

Но подождите. Разве IDE не существуют для облегчения разработки и повышения производительности труда программиста? Да. Этот совет не означает, что вам следует прекратить использование IDE. Совет в том, что нужно «заглянуть под капот» и понять, что ваша IDE делает для вас. Лучший способ сделать это - научиться использовать инструменты командной строки. Затем, когда вы вернётесь к использованию IDE, у вас будет гораздо лучшее понимание того, что делает IDE и как вы можете контролировать процесс сборки. С другой стороны, как только вы освоите использование инструментов командной строки и почувствуете мощь и гибкость, которые они предлагают, вы можете обнаружить, что в некоторых случаях командная строка предпочтительнее IDE.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Carroll Robinson

День четыреста девяносто первый. #ЧтоНовенького
Ещё одно интересное видео. Я уже писал на канале о новых функциях языка:
- Обнуляемые Ссылочные Типы в C#8
- Номинальное создание объектов и записи в C#9.
Но вряд ли кто-то лучше может рассказать об этом, чем непосредственно создатель языка. Mads Torgersen на конференции NDC Conferences рассказал о будущем языка C# https://www.youtube.com/watch?v=WBos6gH-Opk.
В моих постах эти функции описаны довольно кратко (ограничивает размер поста), а Mads рассказывает, как создатели языка пришли к идее реализации каждой из этих функций.
В двух словах: язык движется в сторону широкой поддержки использования неизменяемых типов. Записи (records) – это не какая-то функция в вакууме, а скорее совокупность изменений (аналогично LINQ):
- Введение init-only свойств позволит использовать инициализаторы для создания неизменяемых объектов.
- Метод/оператор with позволит создавать копии объектов с несколькими изменёнными свойствами.
- Планируется ввести некоторое обозначение обязательности инициализации свойства (пока инициализатор не проверяет этого).
- Предполагается ввести новую конструкцию - «валидатор»:

public class Person {
  public string FirstName { get; init; }
  public string LastName { get; init; }
  Person {
    if (FirstName.Length + LastName.Length > 32)
      throw new Exception(“Name too long”);
  }
}

Это блок кода, проверяющий целостность данных всего класса (нескольких свойств) на этапе после выполнения инициализатора, но до присваивания созданного объекта переменной (аналогично валидации в конструкторе).

Записи будут по умолчанию реализовывать все эти функции. Также предполагается, что они будут реализовывать равенство по значению. То есть оператор равенства двух записей будет проверять не равенство ссылок, а равенство значений полей двух записей, как у структур.
Это пока на стадии обсуждения, но рассматривается возможность «сокращённой записи» создания записей:

public record class Person { string FirstName; string LastName };

или даже

public record class Person(string FirstName, string LastName);

При этом будут созданы два открытых init-only свойства.

Помимо вышеупомянутых функций Mads рассказывает о проектах функций “десятой” версии языка:
- Статические члены интерфейса позволят обобщённым интерфейсам описывать статические члены для реализующих их типов (обязать тип реализовать статический метод или переопределять оператор).
- Роли позволят рассматривать элементы типа как имеющие дополнительные члены или как другие типы, не изменяя их представления во время выполнения.
- Расширения типов позволят рассматривать типы как имеющие дополнительные члены внутри области определения расширения.
Фактически последние две функции - это методы расширения на стеройдах.

День четыреста девяносто второй. #ЧтоНовенького
Превью 2 Visual Studio 2019 v16.7
В превью новой версии Visual Studio 2019 улучшена работа с Git в части разрешения конфликтов. Новая жёлтая панель вверху сообщит о конфликтах слияния, которые необходимо разрешить вручную. Нажатие на ней откроет улучшенный редактор слияния. Различия стало легче анализировать, т.к. редактор автоматически выравнивает совпадающие строки, можно включать/отключать выделение различий и различия в пробелах. Также вы можете отключить неконфликтующие различия, чтобы сосредоточиться только на конфликтах. Также добавлены флажки рядом с отличиями, чтобы в один клик выбрать ту или иную строку.
Попробовать новые функции можно, включив функцию Предварительного Просмотра для обновлённого Git в меню Инструменты > Параметры (Tools > Options > Preview Features).

День четыреста девяносто третий.
Blazor
В настоящее время JavaScript является наиболее популярным языком для одностраничных браузерных приложений (Single Page Application), а до недавнего времени это был единственный язык, работавший внутри браузера. Blazor - новая технология Microsoft, которая позволяет разработчикам писать клиентский код на C#.

Blazor - это основанная на .NET инфраструктура SPA для веб и мобильных приложений, а также часть веб-инфраструктуры ASP.NET Core. Blazor использует существующую объектную модель документа HTML (Document Object Model) и CSS для представления и обработки компонентов UI. Однако вместо JavaScript Blazor использует C#, поэтому разработчики могут иметь общий код между платформами.

Обработка происходит в среде выполнения .NET на сервере или на стороне клиента. В первом случае HTML DOM генерируется на сервере, а затем отправляется в браузер с помощью Signal-R (используется полноценный .NET Core). На стороне клиента в браузере используется WebAssembly и Mono. Mono в WebAssembly скоро будет обновлён до .NET 5. WebAssembly открывает все возможности .NET без необходимости рендеринга на стороне сервера или дополнительных плагинов для браузера.

Особенности Blazor
- Создание веб-интерфейсов на C# вместо JavaScript или TypeScript
- Создание прогрессивных веб-приложений (PWA)
- Создание повторно используемых компонентов на C#
- Поддержка отладки на стороне сервера (полная) и на стороне клиента (с некоторыми ограничениями)
- Двусторонняя привязка данных к HTML DOM (с ограничениями)
- Совместное использование кода C# между клиентом и сервером
- Работает во всех современных веб-браузерах, включая мобильные
- Та же песочница безопасности, что и у JavaScript
- Возможность взаимодействия с JavaScript для вызова фреймворков и библиотек

WebAssembly
WebAssembly (сокращенно WASM) — это новый открытый формат байт-кода, исполняемого современными браузерами. Он позволяет переносить код, написанный на таких языках как C, C++, Rust, Go, C# и других в низкоуровневые ассемблерные инструкции и использовать его в сети. Формат имеет компактные размеры, высокую производительность, близкую к нативной, и может работать совместно с JavaScript.

По сути, WASM позволяет компилировать код для веб-браузера. В прошлом такие технологии, как Adobe Flash или Microsoft Silverlight, достигали этого, заставляя пользователя устанавливать плагины. Этого больше не требуется, и среды выполнения, такие как .NET, теперь могут работать поверх WebAssembly.

Продолжение следует…

Источник: https://christianfindlay.com/2020/06/04/blazor-vs-react-angular-vue-js/

День четыреста девяносто четвёртый.
Blazor vs React vs Angular vs Vue.js
1. React
React - это основанная на JavaScript UI-библиотека, принадлежащая и поддерживаемая Facebook. React не пытается предоставить разработчику все инструменты, необходимые для создания современного веб-приложения. Вместо этого он фокусируется на пользовательском интерфейсе и позволяет разработчикам выбирать лучшие компоненты для других аспектов разработки.

Особенности React
- Создание веб UI с помощью JavaScript или TypeScript
- Создание прогрессивных веб-приложений (PWA)
- Поддержка отладки в IDE, таких как VS Code

Blazor или React
JavaScript непрост для изучения C#-разработчиками и не является статически типизированным языком. Часто приходится нанимать отдельных разработчиков для бэкэнда и фронтэнда. Blazor лишён этого недостатка, но он ещё не так совершенен, как React. Пока главным недостатком является отсутствие полноценной отладки на стороне клиента. Поэтому, если готовое SPA нужно прямо сейчас, то React будет лучшим выбором. Но, если в команде в основном C# разработчики, есть большая вероятность, что Blazor будет более удобен для поддержки с течением времени.

2. Angular
Angular - это популярная веб-платформа на основе TypeScript и мобильный SPA-фреймворк, написанный и поддерживаемый Google. TypeScript является статически типизированным языком и транслируется в JavaScript. Более поздние версии Angular также поддерживают рендеринг на стороне сервера аналогично Blazor. Шаблонный синтаксис позволяет разработчикам объявлять компоненты UI с привязкой данных аналогично синтаксису Razor.

Особенности
- Создание веб-интерфейсов с помощью TypeScript
- Создание прогрессивных веб-приложений (PWA)
- Двустороннее связывание данных с HTML DOM
- Поддержка отладки в IDE, таких как VS Code
- Полный набор встроенных API для стандартных задач приложения

Blazor или Angular
Многие из сказанного о React верно и для Angular. Однако Angular реализует парадигму TypeScript, которая более естественна для C# разработчиков, чем для JavaScript. Angular гораздо более всеобъемлющий, чем React, и не просто предоставляет компоненты UI. Он побуждает разработчиков использовать компоненты «из коробки», поэтому код становится более единообразным.

3. Vue.js
Vue – это что-то среднее между React и Angular. Разработчики могут использовать TypeScript, но основное внимание уделяется JavaScript.

Особенности
- Создание веб-интерфейсов с помощью JavaScript или TypeScript
- Создание прогрессивных веб-приложений (PWA)
- Двустороннее связывание данных с HTML DOM
- Поддержка отладки в IDE, таких как VS Code
- Полный набор встроенных API для стандартных задач приложения

Blazor или Vue.js
Vue.js может быть удачным компромиссом для разработчиков, которые хотят больше, чем просто UI-библиотеку, но без тяжести полноценной платформы Angular. Vue.js может быть ещё одним хорошим выбором для команд, которым необходимо разработать SPA прямо сейчас.

Итого
Blazor переносит знакомый HTML DOM на C# и предоставляет веб-разработчикам возможность использовать C# на стороне клиента. У него есть потенциал для создания полноценных настольных и мобильных приложений, и он пользуется популярностью в сообществе разработчиков Microsoft. Рассмотрите его при выборе технологии для вашего следующего SPA.

Источник: https://christianfindlay.com/2020/06/04/blazor-vs-react-angular-vue-js/

День четыреста девяносто пятый.
Я недавно выкладывал ссылку на видео канала Raw Coding про Middleware, и в нашем чате посоветовали посмотреть другие их видео. На этот раз пост не про одно видео, а про целый плейлист ASP.NET Core - Authentication & Authorization Tutorial https://www.youtube.com/playlist?list=PLOeFnOV9YBa7dnrjpOG6lMpcyd7Wn7E8V
Подробнейший рассказ про аутентификацию и авторизацию в ASP.NET Core, чего, кстати, очень не хватает той же книге Фримена (там вся огромная система коротко и скомкано описана в паре глав).

Мне понравился подход автора. Обычно рассказ начинают с простой авторизации, потом переходят к ролям, а потом к заявкам (утверждениям, клеймам, объектам claim, - куча названий в разных источниках). На самом деле, тут можно понять путаницу в названиях, потому что одним словом перевести слово claim на русский невозможно. Наверное, утверждение, будет лучшим вариантом, хотя, я бы в контексте авторизации назвал это «притязанием» (предъявлением своих прав на что-нибудь). Если смотрели Игру Престолов, то там все постоянно спорили, у кого бОльшие притязания на трон (по праву рождения, по старшинству и т.п). Вот это именно claims – набор утверждений о пользователе, дающий или не дающий ему право на что-либо.

Так вот, автор начинает рассказ именно с описания утверждений: где они находятся в системе авторизации и как они выдаются той или иной службой авторизации (на примере бабушки, рассказывающей о том, что её внук хороший)) ). И, удивительно, но, если вот так «начать с конца», а не с ролей, как обычно, всё прекрасно встаёт на свои места:
1. приложение определяет политику,
2. политика содержит требования,
3. требования проверяют наличие необходимых утверждений/притязаний.
А при авторизации с помощью ролей, роль – это просто частный случай утверждения.

Дальше там и про OAuth, и про Identity Server, я пока до туда не дошёл)))

В общем, не пожалейте 14,5 часов (да, я посчитал общую продолжительность плейлиста) на просмотр. Оно того несомненно стоит.

День четыреста девяносто шестой. #юмор

День четыреста девяносто седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
44. Знай Больше Двух Языков Программирования
Уже довольно давно известно, что уровень мастерства программиста прямо пропорционален количеству различных парадигм программирования, которыми он владеет. То есть не количеством тех, которые он знает или о которых слышал, а тех, которые действительно может использовать.

Любой программист начинает с изучения одного языка программирования. Этот язык оказывает доминирующее влияние на то, как программист видит разработку ПО. Независимо от того, сколько лет программист использует этот язык, если он остаётся в этом языке, он будет знать только этот язык и «думать» только на этом языке.

Программист, который изучает второй язык, будет испытывать трудности, особенно если этот язык имеет другую модель вычислений. C, Паскаль, Фортран - все имеют одну и ту же фундаментальную модель вычислений. Переключение с Фортрана на С не составит большого труда. Переход с C на C++ приводит к фундаментальным проблемам в понимании поведения программ. Переход с C++ на Haskell потребует ещё большего изменения взглядов и, как следствие, будет ещё более сложен. А переход от С к Prolog будет представлять сложности почти наверняка.

Мы можем перечислить ряд парадигм вычислений: процедурная, объектно-ориентированная, функциональная, логическая, потоков данных и т. д. Переход между этими парадигмами наиболее сложная задача для программиста.

Почему эти сложности хороши? Это связано с тем, как мы представляем себе реализацию алгоритмов, идиом и шаблонов, которые мы применяем. В основе мастерства лежит «перекрёстное опыление». Идиомы для решения проблем в одном языке, могут быть недоступны в другом. Попытка перенести идиомы с одного языка на другой учит нас как обоим языкам, так и способам решения проблемы.

«Перекрестное опыление» в программировании имеет огромную эффективность. Возможно, наиболее очевидным является всё более широкое использование декларативных выражений в системах, реализованных на императивных языках. Любой, кто разбирается в функциональном программировании, может легко применить декларативный подход даже при использовании языка, такого как C. Использование декларативных подходов обычно приводит к более коротким и более понятным программам. Например, C++, безусловно, принимает это во внимание благодаря поддержке обобщённого программирования, что требует декларативного способа выражения.

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

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Russel Winder

День четыреста девяносто восьмой. #ЗаметкиНаПолях
Dotnet User-Secrets
Посмотрите на этот код файла appsettings.json. Видите что-нибудь необычное?

{
  "ConnectionStrings": {
    "default": "Server=server;Database=MyDB;User ID=user;Password=password"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Warning"
    }
  }
}

Третья строка содержит секретную информацию, которую вы бы не хотели отправлять в открытый репозиторий кода. Но такой пример описан во многих книгах и руководствах по ASP.NET Core. Понятно, почему так происходит – это просто. Тем не менее, это огромная дыра в безопасности. Никогда не храните конфиденциальные данные в исходном коде.

Более опытный разработчик, вероятно, добавит файл appsettings.Development.json, но ещё лучше будет включить его в .gitignore.

К счастью, эту проблему легко исправить. Не нужно делать дополнительных файлов appsettings.SomeEnvironment.json. Вместо этого просто используйте appsettings.json по умолчанию в качестве шаблона для того, что требуется для работы приложения.

Используйте dotnet user-secrets для безопасного хранения конфиденциальных данных. Уберём данные строки подключения из открытого доступа:

"ConnectionStrings": {
    "default": ""
}

Теперь нужно определить место хранения конфиденциальной информации пользователя с помощью команды

dotnet user-secrets init

Её нужно выполнить из папки проекта. В результате появится строка:

Set UserSecretsId to '…' for MSBuild project <путь_к_проекту>

А в файл .csproj добавится блок

<UserSecretsId>…</UserSecretsId>

После этого можно добавлять значения конфиденциальных данных с помощью команды:

dotnet user-secrets set

Первым параметром будет путь к элементу файла конфигурации с разделителями двоеточиями, а вторым параметром – значение. Например, для строки подключения выше команда будет выглядеть так:

dotnet user-secrets set "ConnectionStrings:default" 
"Server=server;Database=MyDB;User ID=user;Password=password"

Теперь, несмотря на то, что в самом файле appsettings.json значение не указано, оно будет использоваться в проекте из секретного хранилища.

Источник: https://levelup.gitconnected.com/never-store-secrets-in-appsettings-json-3a7404ea50d0

День четыреста девяносто девятый.
Книга Адама Фримена «Entity Framework Core 2 для ASP.NET Core MVC»
Отзыв на ещё одну книгу Адама Фримена. Эта книга, можно сказать, приложение к «ASP.NET Core MVC 2», о которой я писал раньше. Несмотря на то, что по структуре обе книги схожи, и в обеих даже расписан пример приложения SportsStore, но читать их можно независимо. Да, поскольку Entity Framework рассматривается в контексте ASP.NET MVC, какие-то минимальные представления о системе иметь надо, но в принципе, можно обойтись и без этого - необходимый минимум описан.

Во-первых, всё, что было сказано про «ASP.NET Core MVC 2», справедливо и для этой книги: .Net Core 2.1, какая-то чуть более новая версия устаревшего bower для управления клиентскими библиотеками (см. решение в посте про «ASP.NET Core MVC 2»). Ну и «гениальный» перевод от «Диалектики». Не могу не поделиться парочкой перлов:
1. «Посадочная страница».
Имеется в виду «landing page» - целевая страница, хотя в контексте речь идёт просто про представление для главной страницы сайта.
2. «Применение инфраструктуры Entity Framework Core для сохранения и извлечения данных прямолинейно после того, как основные средства на месте».
Итак, дословно последняя фраза «… is straightforward once fixed assets in place». Сразу два устойчивых оборота в одном предложении. Понимаю, что сложно))) На русский это можно перевести как: «Применение инфраструктуры EF … не представляет проблем после настройки основных параметров». Но ребята из Диалектики, видимо, торопились или им просто лень было разбираться с тем, что выдал гугл-переводчик.

При всём этом, книга довольно полезна. Подробно объясняется, как EF создаёт миграции и объекты в БД, как переводит выражения C# в команды SQL, какие частые ошибки использования возникают нужно и как их избегать. Ну и конечно продвинутое использование EF: индексы, отношения, database first и т.п. Приложение SportsStore (если вы, как и я, создавали его по примеру книги «ASP.NET Core MVC 2») можно доработать примером из этой - он больше относится к административной части приложения. Кроме того, что мне очень понравилось, в конце каждой главы приводится список распространённых проблем с описанием их решения. Рассказано всё довольно подробно, иногда с повторами, что лично для меня, хорошо знающего SQL, чересчур, но новичкам наоборот будет проще разобраться.

День пятисотый.
Вот и добрались мы с вами до небольшого юбилея. 500 дней подряд я выкладываю посты о том, что мне показалось интересным в мире изучения .NET. Большое спасибо, что читаете и огромное спасибо всем, кто комментирует, предлагает темы, исправляет неточности в постах.

В данный момент я продолжаю подготовку к экзамену 70-486 для получения сертификата MCSA: Web Applications, поэтому большая часть времени (помимо работы и подбора материала для постов) занята этим. Дальше я планирую поглубже окунуться в .NET5, Blazor и WebAssembly. Я недавно публиковал пост на эту тему.

У меня возникла одна идея, но прежде хочу узнать ваше мнение. Осенью выходит .NET5. Нет лучше способа опробовать его, чем практика. У меня есть идея создания полноценного веб приложения на .NET5, Blazor (возможно добавить API) и развёртывания в сервисах Azure (раз уж мы тут про Microsoft, то надо идти до конца))). Приложение будет касаться изучения .NET и программирования вообще. В двух словах – это организованный справочник источников для изучения программирования. Пока не буду вдаваться в детали, я сам ещё полноценную концепцию не продумал.

Собственно, поэтому у меня к вам такой вопрос. Есть ли среди моих подписчиков те, кому в образовательных целях было бы интересно поучаствовать в опенсорс проекте? Понимаю, что это звучит, типа, я ищу бесплатную рабочую силу. Но давайте объясню, как я это вижу. Мы как разработчики постоянно учимся. Это одно из требований профессии. Однако на работе не всегда удаётся учиться и практиковать то, что тебе интересно. Часто в корпоративных системах используются не самые новые версии языка и фреймворков. Часто отдельный разработчик отвечает только за что-то одно: написание модулей, тестирование, фронтенд, - и иногда эти области не пересекаются. Я предлагаю (только тем, кому это интересно) вместе создать приложение с нуля (продумывание функционала, проектирование подсистем, модулей, написание кода, тестов, CI/CD, вотэтовсё) на передовой на данный момент технологии. При этом каждый сможет заняться тем, что ему интересно, поделиться опытом или получить опыт в процессе. Никаких сроков, дедлайнов или обязаловок, всё исключительно по желанию и в свободное от основной деятельности время.

Да, понимаю, что звучит несколько утопично. В принципе, идея взята вот из этого совета. В общем, подумайте на досуге))) Подробности ближе к осени. А пока я хотел бы узнать, в принципе эта идея кому-нибудь интересна, и, если да, в чём вы можете поделиться опытом. Обсудить можем в чате.

День пятьсот первый. #MoreEffectiveCSharp
13. Предпочитайте Реализацию Интерфейсов Наследованию
Абстрактные базовые классы предоставляют общего предка для иерархии классов. Интерфейс описывает группу связанных методов, содержащих функционал, который должен быть реализован типом. У каждого подхода своё применение, и они не взаимозаменяемы. Интерфейсы - это способ объявления контракта. Абстрактные базовые классы предоставляют общую абстракцию для набора связанных типов. Наследование означает «является» (описывает, что такое объект), а интерфейс означает «ведёт себя как» (описание одного из поведений объекта).

Особенности интерфейсов:
1. Определяют многократно используемое поведение.
2. Могут быть параметром или возвращаемым значением.
3. Могут быть реализованы несвязанными типами.
4. Другим разработчикам легче реализовать интерфейс, чем наследовать от созданного вами базового класса.
5. Вы не можете обеспечить реализацию методов в интерфейсе. Однако можно создать методы расширения для него. Они будут частью любого типа, который реализует интерфейс.
6. Добавление нового члена к интерфейсу сломает все классы, которые его реализуют. Каждый разработчик должен будет обновить тип, чтобы включить новый член. В C#8 в интерфейсе можно определить реализацию по умолчанию, но этот приём нужно использовать с осторожностью. Если вы обнаружите, что вам нужно добавить функциональность в интерфейс, создайте новый и наследуйте от существующего интерфейса.

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

Интерфейсы как параметры методов
Рассмотрим два метода:

public static void Print<T>(IEnumerable<T> col) {
  foreach (T o in col)
    Console.WriteLine(o);
}
public static void Print(MyCollection col) {
  foreach (var o in col)
    Console.WriteLine(o);
}

Любой тип, который поддерживает IEnumerable<T> (List<T>, SortedList<T>, любой массив и результаты любого запроса LINQ), может использовать первый метод. Второй метод гораздо менее пригоден для повторного использования. Использование интерфейсов в качестве типов параметров метода гораздо более универсально и намного проще для повторного использования.

Интерфейсы как возвращаемые значения
Допустим, ваш класс имеет открытый метод, который возвращает коллекцию объектов:

public List<SomeClass> DataSequence => sequence;
private List<SomeClass> sequence = new List<SomeClass>();

Это создаёт сразу две проблемы:
1. Если вы захотите изменить тип возвращаемого значения со списка на массив или сортированный список, это нарушит код, т.к. это изменит открытый интерфейс вашего класса. Такое изменение заставляет вас делать гораздо больше изменений в системе, чем необходимо: вам нужно будет поменять все места, где происходит обращение к этому методу.
2. Вторая проблема в том, что List<T> предоставляет множество методов для изменения содержащихся в нём данных. Клиенты вашего класса смогут удалять, изменять или даже заменять элементы списка. Почти наверняка вы этого не хотите. К счастью, вы можете ограничить их возможности, вернув вместо ссылки на некоторый внутренний объект интерфейс IEnumerable<SomeClass>. Используя интерфейсы в качестве типа возвращаемого значения, вы можете выбирать, какие методы и свойства для работы с предоставляемыми данными вы хотите открыть для клиентов класса.

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 14.

День пятьсот второй. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
45. Знай Свою IDE
В 1980-х наши среды разработки были, в лучшем случае, немногим полезнее, обычных текстовых редакторов. Подсветка синтаксиса, которую мы сейчас считаем само собой разумеющейся, была не всем доступной роскошью. Инструменты форматирования кода обычно были сторонними продуктами, которые нужно было запускать, чтобы исправить отступы. Отладчики были также отдельными программами, запускаемыми для пошагового выполнения кода со множеством загадочных нажатий клавиш.

В 1990-х компании начали осознавать потенциальную пользу, которую они могли бы извлечь, предоставляя программистам лучшие и более полезные инструменты. Интегрированная среда разработки (IDE) объединила функции редактирования кода с компилятором, отладчиком, инструментами форматирования и другими полезными функциями. К тому времени выпадающие меню и мышь также стали популярными, что означало, что разработчикам больше не нужно было изучать загадочные комбинации клавиш, чтобы использовать редактор. Они могли просто выбрать команду из меню.

В 21-м веке IDE стали настолько обычным явлением, что их бесплатно раздают компании, желающие получить долю рынка в других областях. Современная IDE оснащена удивительным набором функций. Мой любимый инструмент - автоматический рефакторинг, особенно извлечение в метод, когда я могу выделить часть кода и преобразовывать его в метод. Инструмент рефакторинга подберёт все параметры, которые необходимо передать, что делает его использование чрезвычайно простым. IDE даже обнаружит другие похожие фрагменты кода, которые также могут быть заменены этим методом, и спросит меня, не хочу ли я их заменить.

Еще одна удивительная особенность современных IDE - возможность применять правила корпоративного стиля. Табы или пробелы, открывающая фигурная скобка в конце объявления или на новой строке… Каков бы ни был принятый стиль в компании, всё, что мне нужно сделать, чтобы следовать ему, это настроить его в моей IDE. Правила стиля также могут использоваться для поиска возможных ошибок.

К сожалению, современные IDE не требуют от нас усилий, чтобы научиться их использовать. Когда я впервые программировал в C на Unix, мне пришлось потратить немало времени на изучение работы редактора vi. Это потраченное время окупилось за годы использования. Я даже набираю черновик этой статьи с помощью vi. Современные IDE имеют очень плавную кривую обучения, что может привести к тому, что мы никогда не выйдем за рамки самого простого использования инструмента.

Мой первый шаг в изучении IDE - запоминание сочетаний клавиш. Так как мои пальцы находятся на клавиатуре, когда я набираю код, нажатие сочетания клавиш не прерывает хода работы, тогда использование мыши заставляет отвлечься, найти мышь, навести курсор, найти нужный пункт меню… Эти отвлечения приводят к ненужным переключениям контекста, снижая производительность. То же правило относится и к навыкам печатания: научитесь слепой печати - вы не пожалеете о потраченном времени. Наконец, у нас много инструментов манипуляции кодом: инструменты рефакторинга, поиска и замены по шаблону, и т.п.

Мы ожидаем, что сантехник, приходящий в наш дом, сможет использовать свой разводной ключ и отвёртки, и знает, как с ними обращаться. Давайте потратим немного времени на изучение того, как повысить эффективность в нашей IDE.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Heinz Kabutz

День пятьсот третий. #ЧтоНовенького
В Microsoft объявили о выходе .NET 5.0 Preview 5. Эта предварительная версия описана как «небольшой набор новых функций и улучшений производительности», так как большая часть функционала, запланированного под .NET 5, была выпущена в Preview 4 в прошлом месяце. Из особенностей Preview 5 можно выделить обновления в ASP.NET и Entity Framework.

В ASP.NET Core:
- Обновляемые конечные точки в конфигурации Kestrel
Kestrel теперь имеет возможность отслеживать изменения в конфигурации, передаваемой через KestrelServerOptions.Configure и применять изменения к конечным точкам без необходимости перезапуска приложения.

В Entity Framework Core 5.0
1. Параметры сортировки (collations) базы данных
Параметры сортировки теперь можно указать в модели EF, и они будут указаны в миграции.
- Для всей базы данных:

modelBuilder.UseCollation("German_PhoneBook_CI_AS");

Это приведёт к следующему коду для SQL Server:

CREATE DATABASE [Test]
COLLATE German_PhoneBook_CI_AS;

- Для отдельных столбцов:

modelBuilder
  .Entity<User>()
  .Property(e => e.Name)
  .UseCollation("German_PhoneBook_CI_AS");

- EF.Functions.Collate для отдельных запросов (с осторожностью, т.к. это может негативно сказаться на производительности):

context.Users.Single(e => EF.Functions.Collate(e.Name, "French_CI_AS") == "Jean-Michel Jarre");

2. Аргументы управления потоком в IDesignTimeDbContextFactory
Теперь из командной строки в метод CreateDbContext объекта IDesignTimeDbContextFactory можно передавать пользовательские аргументы. Например, указать, что сборка для разработки, в командной строке можно передать пользовательский аргумент (например, dev):

dotnet ef migrations add two --verbose --dev

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

3. Сохраняемые вычисляемые столбцы
Большинство баз данных позволяют хранить вычисляемые значения в столбцах. Хотя это занимает место на диске, вычисляемый столбец вычисляется только один раз при обновлении, а не каждый раз, когда извлекается его значение. Это также позволяет индексировать столбец в некоторых базах данных. EF Core 5.0 позволяет конфигурировать вычисляемые столбцы как сохраняемые:

modelBuilder
  .Entity<User>()
  .Property(e => e.SomethingComputed)
  .HasComputedColumnSql("my sql", stored: true);

4. Запросы без отслеживания с разрешением идентификатора
Запросы без отслеживания теперь можно настроить для разрешения идентификатора. Например, следующий запрос создаст новый экземпляр Blog для каждой записи из Posts, даже при том, что экземпляры будут иметь одинаковые первичные ключи:

context.Posts.AsNoTracking().Include(e => e.Blog).ToList();

Этот запрос можно изменить, чтобы обеспечить создание только одного экземпляра Blog:

context.Posts.AsNoTracking().PerformIdentityResolution().Include(e => e.Blog).ToList();

Обратите внимание, что это полезно только для запросов без отслеживания (AsNoTracking).

Источники:
- https://devblogs.microsoft.com/aspnet/asp-net-core-updates-in-net-5-preview-5/
- https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-5-0-preview-5/