День 1440. #ЗаметкиНаПолях
Особенность Использования Необязательных Параметров
Мы все любим необязательные параметры методов. Их так просто и удобно использовать. Но есть один момент, при использовании их в отельной библиотеке классов, о котором стоит помнить.

Рассмотрим пример. Сразу скажу, он немного искусственный, но от этого, если вы вдруг столкнётесь с такой ошибкой, она будет казаться ещё более невероятной.

Допустим, мы сделали библиотеку классов для калькулятора:

namespace ThirdPartyLibrary;

public static class Calculator
{
   public static int Add(int a = 0, int b = 0)
   {
     Console.WriteLine($"{a}+{b}");
     return a + b;
   }
 }
}

Простой метод с необязательными параметрами. И код, который её использует:

using ThirdPartyLibrary;

int add = Calculator.Add();
add = Calculator.Add(2);
add = Calculator.Add(2, 3);

Console.ReadLine();

//Вывод:
0+0
2+0
2+3

Пока всё хорошо.
Теперь сделаем небольшое изменение в классе Calculator: изменим значения параметров по умолчанию с 0 на 10.
Соберём проект библиотеки (только его, а не всё решение) и скопируем получившиеся файлы библиотеки ThirdPartyLibrary.dll и ThirdPartyLibrary.pdb из папки \bin\Debug библиотеки в папку \bin\Debug консольного приложения. То есть мы обновили библиотеку и хотим, чтобы наше приложение работало с новой версией.

Теперь из той же папки \bin\Debug консольного приложения запустим приложение (exe файл). Мы ожидаем, что оно будет использовать новую версию библиотеки, и будут использоваться новые значения по умолчанию (10), так?

Но результаты не изменились!

0+0
2+0
2+3

Теперь попробуем пересобрать весь проект и запустить его. Получаем то, чего ожидали:

10+10
2+10
2+3

Дело в том, что, когда вы вызываете метод с необязательными параметрами и не передаете значения для этих необязательных параметров, будут использоваться значения по умолчанию, определённые методом. Но это не всё. Эти значения по умолчанию будут жёстко записаны в скомпилированный код вызывающей стороны! Т.е. когда значения по умолчанию обновятся в определении метода, это не будет отражено в вызывающем объекте до тех пор, пока клиентский код не будет пересобран вместе с новой версией библиотеки.

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

Источник: https://levelup.gitconnected.com/dangers-of-using-optional-parameters-in-net-c-a953315672fb

День 1441. #ЧтоНовенького
Миграция Проекта с ASP.NET на ASP.NET Core
Я уже писал про возможность миграции проекта ASP.NET Framework на ASP.NET Core с помощью расширения Visual Studio Microsoft Project Migrations. Сегодня расскажу о последних новинках в этом процессе.

Напомню, что процесс можно начать, просто нажав правой кнопкой на проекте и выбрав в контекстном меню Migrate project (Перенести проект). Появится мастер миграции, в котором вы можете выбрать перенести контроллер, класс или представление. Подробнее об этом в предыдущих постах. Сегодня о новинках.

1. Добавлен Обозреватель Конечных Точек (Endpoints Explorer), позволяющий просматривать, какие конечные точки или маршруты были перенесены (в списке справа), а какие ещё предстоит перенести (слева). Вы можете щелкнуть правой кнопкой мыши маршрут и выбрать Open in editor (Открыть в редакторе), чтобы исходный код этого маршрута.

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

3. Добавлена поддержка областей (Area). Теперь, когда вы переносите содержимое в область ASP.NET, при необходимости область будет создана в целевом проекте миграции. Это должно уменьшить объём работы, которую необходимо выполнить при переносе содержимого в области ASP.NET.

4. Также улучшено качество существующих функций и добавлено больше преобразователей, чтобы уменьшить объём кода, который необходимо исправить вручную после процесса миграции.

5. Пакеты адаптеров для System.Web позволяют переносить проекты с зависимостями от System.Web в .NET Standard, .NET 6 или .NET 7, предоставляя общие API System.Web через адаптеры, совместимые с .NET Standard. Это позволяет переносить библиотеки классов с зависимостями от System.Web в .NET Standard, чтобы их можно было использовать вызывающими объектами ASP.NET и ASP.NET Core в сценариях поэтапной миграции. Доступные API включают множество часто используемых элементов из HttpRequest, HttpResponse, HttpContext и других распространённых типов.
Также адаптеры для System.Web включают новые функции для улучшения поэтапной миграции. При поэтапной миграции решения части веб-приложения будут обслуживаться исходным проектом ASP.NET, а части — новым проектом ASP.NET Core. Для простых конечных точек это работает хорошо. Но когда сеанс пользователя включает в себя состояние — будь то элементы сессии или аутентификацию — необходимо совместно использовать это состояние между двумя приложениями, чтобы вход в одно из приложений также входил в другое, и чтобы элементы сессии, записанные конечной точкой одного приложения, могли быть прочитаны другим приложением. Адаптеры System.Web включают функции, позволяющие совместно использовать такое состояние через соединения между приложениями ASP.NET Core и ASP.NET.

6. Была улучшена и обновлена документация, которая сейчас доступна здесь. Документация включает советы по началу работы, описание адаптеров для
System.Web, а также руководство о совместном использовании сессии между приложениями ASP.NET и ASP.NET Core.

Источник: https://devblogs.microsoft.com/dotnet/migrating-from-asp-net-to-asp-net-core-part-5/

День 1442. #МоиИнструменты
Процессор JSON, Который Вам Пригодится
Обработка JSON — обычная задача в повседневной работе разработчиков. Мы привыкли работать с JSON, но иногда нам нужно что-то более динамичное и эффективное, чем System.Text.Json и Newtonsoft.Json. JMESPath — это мощный язык запросов, который позволяет вам выполнять задачи Map/Reduce декларативным и интуитивно понятным способом. Его можно использовать в .NET, см. JmesPath.Net.

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

Например, Azure CLI использует параметр –query для выполнения запроса JMESPath к результатам выполнения команд.

Допустим, у нас есть какие-то данные в JSON в строковой переменной source:

{
  "balance": "$2,285.51",
  "name": "Eva Sharpe",
  "email": "[email protected]",
  "latitude": 46.325291,
  "friends": [
    {
      "id": 0,
      "name": "Nielsen Casey",
      "age": 19
    },
    {
      "id": 1,
      "name": "Carlene Long",
      "age": 38
    }
  ]
}

Следующий код содержит запрос для его обработки. Он демонстрирует различные концепции, такие как проекция, фильтрация, агрегация, преобразование типов и т.д. Думаю, что синтаксис достаточно интуитивно понятен и не нуждается в объяснении:

var expressions = new (string, string)[]
{
 ("scalar", "balance"),
 ("projection", "{email: email, name: name}"),
 ("functions", "to_string(latitude)"),
 ("arrays", "friends[*].name"),
 ("filtering", "friends[?age > `20`].name"),
 ("aggregation", "{sum: sum(friends[*].age)}"),
};

var parser = new JmesPath();
foreach (var (name, expression) in expressions)
{
  var result = parser.Transform(source, expression);
  Console.WriteLine($"{name}: {result}");
}

Вывод

scalar: "$2,285.51"
projection: {"email":"[email protected]","name":"Eva Sharpe"}
functions: "46.325291"
arrays: ["Nielsen Casey","Carlene Long"]
filtering: ["Carlene Long"]
aggregation: {"sum":57}

Итого
Как видите, JMESPath неплохо решает проблемы динамической обработки JSON на основе пользовательского ввода. Он также имеет модель расширяемости (возможность писать свои функции), которая открывает массу возможностей.

Источник: https://dev.to/nikiforovall/introduction-to-jmespath-json-processor-you-should-definitely-know-2dpb

День 1443. #Карьера
Улучшаем Эмоциональный Интеллект. Часть 4
Эмоциональный интеллект – это способность понимать эмоции и управлять ими, бесценное качество, которое поможет стать более продуктивными и улучшить отношения с другими. Вот простые правила, которые помогут развить ваш эмоциональный интеллект.

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

Итак, как правило Майи Анжелу проявляется в реальной жизни?

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

А вот время, которое они потратили, чтобы выслушать вас. Их готовность засучить рукава и помочь вам выполнить работу. Все благодарности, слова похвалы, или просто дружеские звонки или разговоры чтобы узнать, как у вас дела.

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

Итак, что вы можете сделать для своих коллег?

Если вы занимаете руководящую должность, будь то менеджер, руководитель группы (или даже родитель), задайте себе и своей команде следующие вопросы:
- Как мне заставить людей чувствовать себя хорошо?
- Могу ли я выслушать? Услышать об их проблемах, трудностях и успехах?
- Предлагаю ли я поддержку для решения этих задач? Замечаю ли я их достижения?
- Благодарю ли я их? Просто потому, что это правильно, но также и потому, что так я побуждаю их продолжать делать то, что они делают.
- Я заставляю их чувствовать себя в безопасности? Чувствовать, что о них заботятся, их ценят, им доверяют? Что они тоже могут рассчитывать на меня?

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

Источник: https://www.inc.com/justin-bariso/how-to-increase-emotional-intelligence.html

День 1444. #МоиИнструменты
Тестовые Контейнеры в C#/.NET
Многие приложения сильно зависят от реляционной базы данных. Ваше приложение использует сложные запросы, ограничения на данные и другие возможности реляционной базы данных. Это означает, что многое в поведении ваших приложений зависит от того, как действует база данных. Поэтому важно проводить тесты на реальной базе. Сегодня это легко сделать с помощью TestContainers.

TestContainers — это библиотека, которая запускает контейнеры Docker для ваших тестов и предоставляет множество настроек для баз данных.

Попробуем настроить тестовый контейнер с Microsoft SqlServer:

// настройка БД
var dbConfig = new MsSqlTestcontainerConfiguration
{
  Password = "Test1234",
  Database = "TestDB"
};

// создание контейнера
var сontainer = 
 new TestcontainersBuilder<MsSqlTestcontainer>()
  .WithDatabase(dbConfig)
  .WithImage("mcr.microsoft.com/mssql/server:2022-latest")
  .Build();

// и запуск
container.StartAsync().Wait();

Этот код загрузит образ докера MS Server и запустит контейнер. Затем запросит строку подключения для этого контейнера и запустит тесты для него. Если не указать путь к образу, будет использован образ по умолчанию. Если предварительно настроенные контейнеры вам не подходят, вы можете запустить произвольный образ с базовым тестовым контейнером.

Посмотрим пример теста:

record Dog (string Name, DateTime BirthDate);

using (var db = new SqlConnection(
  container.ConnectionString))
{ 
  db.Execute(@"CREATE TABLE Dogs(
    BirthDate DATETIME NOT NULL,
    Name VARCHAR(MAX) NOT NULL
  )");

  var born = new DateTime(2022, 12, 22);
  db.Execute(@"
   INSERT Dogs(BirthDate,Name)
   VALUES(@BirthDate, @Name)",
   new {
    BirthDate = born,
    Name = "Joe"
   });

  var dog = db.Query<Dog>(
    @"SELECT * FROM Dogs")
   .First();
  Assert.AreEqual(born, dog.BirthDate);
}

// очищаем контейнер
container.DisposeAsync();

Что если убить процесс, который запускает тесты? Что произойдёт с контейнерами, которые он создал? На самом деле при запуске тестового контейнера создаётся два контейнера. Помимо запущенного вами, создаётся контейнер testcontainers/ryuk, который управляет всеми тестовыми контейнерами и выполняет очистку при сбоях.

В TestContainers встроена поддержка многих баз данных в наследниках класса TestcontainerDatabase. То же самое касается систем сообщений, которые являются наследниками TestcontainerMessageBroker. Всё это можно найти в документации.

Источник: https://www.gamlor.info/posts-output/2022-12-22-test-containers/en/

День 1445. #МоиИнструменты
Используем Новинки Языка на Старых Платформах
Сегодня порекомендую вам интересное видео от Ника Чапсаса об использовании новейших функций языка C# в старых версиях платформы, например, в .NET Framework.

На самом деле, все функции можно использовать практически «из коробки», просто изменив версию языка на 11. Да, Visual Studio не даст вам этого сделать так просто, потому что она автоматом определяет версию языка по версии фреймворка. Но можно вручную отредактировать файл .csproj, указав нужную версию языка в блоке компиляции:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <PlatformTarget>AnyCPU</PlatformTarget>
  …
  <LangVersion>11.0</LangVersion>
</PropertyGroup>

Только одно это действие уже позволит вам писать, например, top-level statements (т.е. обойтись без класса Program).

Добавить другие функции чуть сложнее. Например, чтобы использовать init-свойства, нужно добавить пустой класс IsExternalInit:

namespace System.Runtime.CompilerServices
{
  public static class IsExternalInit { }
}

Однако и эту работу можно облегчить, просто добавив NuGet-пакет PolySharp.

Все подробности в новом видео Ника https://youtu.be/RgKa-tjnUMA

День 1446. #Оффтоп
Закон Дырявых Абстракций
В основе Интернета лежит ключевой элемент магии, на который вы полагаетесь каждый день. Протокол TCP — это надёжный способ передачи данных. Т.е., если вы отправляете сообщение по сети с использованием TCP, оно будет доставлено, и не будет искажено или повреждено.
Для сравнения, есть ненадежный метод передачи данных, называемый IP. Никто не обещает, что ваши данные дойдут до адресата, и они могут испортиться по ходу.
Магия в том, что TCP построен поверх IP. Т.е. TCP обязан каким-то образом надёжно отправлять данные, используя только ненадёжный инструмент.

Но 100%-ной гарантии не даёт даже TCP. Если ваша кошка перегрызла сетевой кабель, и никакие IP-пакеты не могут пройти, то TCP ничего не сможет с этим поделать. Если у вас нестабильное соединение, то только часть ваших IP-пакетов будет проходить. TCP будет работать, но очень медленно.

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

Все нетривиальные абстракции в той или иной степени негерметичны:
- Такая простая вещь, как итерация по большой коллекции может иметь совершенно разную производительность в зависимости от выбранного метода итерации.
- SQL предназначен для того, чтобы абстрагироваться от процедурных шагов, необходимых для запроса к базе данных, позволяя вам просто описать, что вы хотите, и дать базе данных определить, что сделать для выполнения запроса. Но в некоторых случаях определённые SQL-запросы выполняются в тысячи раз медленнее, чем другие логически эквивалентные запросы. Вы не должны заботиться о процедуре, только о спецификации. Но иногда абстракция «протекает» и приводит к ужасной производительности, и вам приходится анализировать план запроса, чтобы выяснить, что не так.
- Класс string позволяет вам притвориться, что строки являются скалярными типами и работать с ними так же, как с целыми числами, например, используя оператор +. Но даже джуны знают, что чрезмерное его употребление ни к чему хорошему не приведёт. Абстракция имеет дыру, которую язык не позволяет заткнуть.

Одной из проблем дырявых абстракций является то, что абстракции на самом деле не упрощают нашу жизнь так сильно, как должны были бы. Мы могли бы учить новичков полностью доверять описанным выше абстракциям, но рано или поздно они столкнутся с проблемой при использовании их «в лоб».

Miscrosoft в ASP.NET Web Forms попробовали сделать абстракцию, позволяющую работать с веб-страницами так же, как если бы они были формами настольного приложения. Абстракция задумывалась как способ скрыть всё взаимодействие по HTTP и сделать нажатие на кнопку веб-страницы таким же, как нажатие на кнопку формы настольного приложения. И эта идея с треском провалилась. Сейчас идут попытки сделать наоборот: показывать веб-страницы внутри локального приложения. Посмотрим, что получится из этого.

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

Источник: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

День 1447. #CSharp11
Обзор Новых Функций C# 11. Начало
Я уже ранее кратко описывал, какие новинки должны были появиться, а потом и появились в C# 11. В этой серии подведём итоги. Что же появилось, а что нет.

1. Необработанные (raw) строковые литералы (включено в релиз)
С обычными строками в C# бывает трудно работать, потому что нужно экранировать кавычки ("), обратную косую черту (\) и разрывы строк (\n). В предыдущих версиях C# уже было решение — дословные (verbatim) строки, которые начинаются с @ и допускают использование специальных символов.
Вместо:

string path = "c:\\myfilepath\\with-backslashes";

будет:

string path = @"c:\myfilepath\with-backslashes";

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

C# 11 вводит необработанные строковые литералы, чтобы обойти проблему экранирования. Используется новый разделитель — ряд кавычек, за которыми следует разрыв строки (в начале), и разрыв строки, за которым следует такое же количество кавычек (в конце). Вы просто вставляете свой блок кода или разметку между ними:

string xml = """
  <part number="1976">
    <name>Windscreen Wiper</name>
    <description>The Windscreen wiper automatically removes
       rain from your windscreen. It has a rubber
       <ref part="1977">blade</ref>, which can be ordered
       separately.
    </description>
  </part>
  """;

Если вы обеспокоены тем, что внутри вашей строки может появиться последовательность из трёх двойных кавычек, можно изменить разделитель и использовать столько кавычек, сколько нужно, только одинаковое количество в начале и в конце:

string xml = """" 
    Теперь можно использовать """ в строке.
    """";

Как и в случае с дословными строками, в необработанной строке сохраняются разрывы строк и пробелы. Но есть одно исключение. Общие пробелы — количество, которое используется для выравнивания всего текста — обрезаются. Это означает, что в первом примере обрежутся первые 2 пробела во всех строках.

Необработанные строки не предназначены для замены дословных строк. Они предназначены для особого случая, когда вам нужно вставить блок произвольного кода или разметки.

Также можно использовать интерполяцию с помощью знака $. Количество знаков $ в разделителе должно быть равно количеству фигурных скобок, необходимых для ссылки на переменную:

int number = 1;
string json =
  $$"""
  {
    "number": "{{number}}"
  }
  """;

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

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1448. #ЗаметкиНаПолях
Обзор Новых Функций C# 11. Продолжение
Начало
Продолжим обзор функциональности работы со строками.

2. Разрывы строк во встроенных выражениях (включено в релиз)
В C# 11 добавлено небольшое усовершенствование в способ обработки разрывов строк во встроенных выражениях при интерполяции. В C# 10 вы не могли разрывать строку внутри фигурных скобок:

var text =
  $"Всего {people.Count} человек";

Это ограничение было просто побочным эффектом предыдущей реализации компилятора. В нём не было строгой необходимости. Выражения с разрывами строк компилируются без ошибок в C# 11:

var text =
  $"Всего {students.Count 
    + teachers.Count} человек";

3. Строки UTF-8 (включено в упрощённом виде)
C# 11 дает нам новый суффикс переменной u8, который указывает использовать кодировку UTF-8 для строкового литерала:

var utf8 = "HEAD/HTTP/1.1"u8;

Важно понимать, что этот код не создаёт строку. Строки C# используют кодировку UTF-16, и создание совершенно нового пользовательского строкового типа данных UTF-8 было бы излишним. Вместо этого создаётся экземпляр объекта ReadOnlySpan<byte>. Это в основном пригодится, если вы взаимодействуете с веб-протоколом (он почти всегда использует UTF-8) и хотите избежать накладных расходов на написание такого кода:

string utf16 = "HEAD / HTTP/1.1";
byte[] utf8 = Encoding.UTF8.GetBytes(utf16);

Кроме того, вы должны получить ошибку времени компиляции при попытке присвоить u8 строке символы, которые не представлены в UTF8:

var utf8data = "Special chars:\uD801\uD802"u8;

Этот код выдаст ошибку CS9026: The input string cannot be converted into the equivalent UTF-8 byte representation. Unable to translate Unicode character \uD801 at index 14 to specified code page. (Входная строка не может быть преобразована в эквивалентное байтовое представление UTF-8. Невозможно преобразовать символ Unicode \uD801 на позиции 14 в указанную кодовую страницу.)

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

byte[] utf8data = "HEAD / HTTP/1.1";

Но это не было включено в релиз.

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1449. #ЗаметкиНаПолях
Обзор Новых Функций C# 11. Продолжение
Начало 1
Продолжение 2-3

4. Шаблоны списков (включено в релиз)
Тренд современного C# - растущее использование методов функционального программирования. В частности, использование выражений, которые позволяют разработчикам заменить императивный код декларативным кодом.

В C# 11 добавлено отличное расширение для синтаксиса выражения switch, позволяющее тестировать массивы. Оно называется выражениями списка, вот тривиальный пример:

int[] numbers = {24, 320, 700};
string test = numbers switch
{
  [24, 320, 700] => "Это нужный массив!",
  _ => "Не подходит" 
};

Этот код использует выражение switch для проверки массива. Если выражение соответствует первому массиву (а оно соответствует), переменной test присваивается строка «Это нужный массив!», в противном случае - строка «Не подходит».

Шаблоны списков становятся намного интереснее, когда вы используете операторы .. или _ для создания срезов:

int[] numbers = {24, 320, 700};
string test = numbers switch
{
  [24, 32, 700] => "Это нужный массив!",
  [24, _, 700] => "2й элемент может быть любым",
  [24, .., 700] => "1й элемент 24, последний 700",
  [< 25, ..] => "1й элемент меньше 25",
  _ => "Не подходит"
};

Оператор .. представляет серию элементов (любое количество), а _ представляет один любой элемент. Таким образом, [24, .., 700] соответствует таким массивам, как [24, 200, 700] или [24, 324, 254, 525, 4, -4, 700]. Кроме того, можно использовать выражения и вместо самих элементов. Шаблон [< 25, ..] предполагает, что первый элемент массива меньше 25, а количество элементов не ограничено.

Заметьте, что, как и в других вариантах использования сопоставления по шаблону в выражениях switch, в случае, когда входящему элементу соответствуют несколько шаблонов, будет использован первый подходящий шаблон. В данном случае - [24, _, 700], хотя [24, .., 700] и [< 25, ..] тоже подходят. Поэтому необходимо располагать шаблоны в switch выражении от частных к более общим. Если вы нарушите это правило, компилятор выдаст ошибку CS8510: The pattern is unreachable. It has already been handled by a previous arm of the switch expression or it is impossible to match. (Шаблон недостижим. Он уже был обработан предыдущим вариантом выражения switch или с ним невозможно сопоставиться.)

Шаблоны списков работают не только с явно определёнными массивами. Любой тип с индексатором и свойствами Length и Count работает для фиксированных совпадений. Шаблоны срезов работают, если у типа есть индексатор, принимающий аргумент Range, или метод Slice с двумя параметрами типа int.

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1450. #ЗаметкиНаПолях
Обзор Новых Функций C# 11. Продолжение
Предыдущие части: 1, 2-3, 4

5. Обязательные члены (включено в релиз)
Раньше вы полагались практически исключительно на конструкторы классов, чтобы убедиться, что объекты созданы в правильном состоянии. Сегодня мы часто работаем с более легкими конструкциями, такими как автоматически реализуемые свойства в записях:

public record Employee
{
  public string Name { get; init; }
  public decimal Salary { get; init; }
  public DateTime Hired { get; init; }
}

И когда мы создаём экземпляры таких легковесных объектов, нам нравится использовать инициализаторы:

var newGuy = new Employee
{
  Name = "Dave Bowman",
  Salary = 100000m,
  Hired = DateTime.Now()
};

Но что, если объект не имеет смысла, когда не заданы определённые свойства? Вы можете добавить конструктор, как обычно, но придётся заплатить за эту формализацию большим количеством шаблонного кода. И ошибки при копировании значений из параметров в свойства, конечно, глупы, но их часто совершают. Ключевое слово required решает эту проблему:

public record Employee
{
  public required string Name { get; init; }
  public decimal Salary { get; init; }
  public DateTime Hired { get; init; }
}

Теперь компилятор не позволит вам написать код, который создаёт Employee без задания свойства Name.

См. также: Подробнее об Обязательных Членах Класса в C#11

6. Параметры с проверкой на null (удалено из релиза)
Как и многие удалённые функции C#, автоматическая проверка параметра на null предлагалась и раньше, но её недостатки так и не были полностью устранены. Идея состояла в том, чтобы избавить методы от многословной проверки параметров и выброса ArgumentNullException с помощью оператора !!. И программисты тут же разделились на тех, кто был от неё в восторге, и тех, кто сразу её возненавидел. Возник вопрос: стоит ли создавать новый оператор только ради одного маленького удобства?

Идея была представлена ещё во времена C# 8. И изначально казалась прекрасной, хотя .NET 6 добавил удобный метод ArgumentNullException.ThrowIfNull(), который тоже хорошо справляется со своей задачей. Т.е. вместо:

public UpdateAddress(int id, Address address)
{
  if (address == null)
  {
    throw new ArgumentNullException("address");
  }
  ...
}

Вы можете написать:

public UpdateAddress(int id, Address address)
{
  ArgumentNullException.ThrowIfNull(address);
  ...
}

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

Окончание следует…

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1451. #ЗаметкиНаПолях
Обзор Новых Функций C# 11. Окончание
Предыдущие части: 1, 2-3, 4, 5-6

7. Статические абстракции в интерфейсах (официально включено в язык)
Реализация уже была в C#10 в виде превью. Но в C# 11 она реализована официально как часть языка. В C# 8 добавлена возможность помещать статические элементы в интерфейс, но интерфейс должен был включать код реализации. В C#10 статические члены могут быть абстрактными, поэтому реализующий их класс может предоставить собственную реализацию. Звучит красиво, но немного сложно, пока вы не рассмотрите некоторые потенциальные варианты использования. Одним из наиболее востребованных является обобщённая математика, которая позволяет использовать операторы (реализованные как статические методы) для обобщённых типов.

8. Типы, ограниченные файлом (включено в релиз)
Добавлен новый модификатор доступа file. Вы можете использовать его в классе или другом типе так же, как вы используете private или public:

file class CanvasUtils { … }
public class Canvas { … }

file делает тип доступным для кода в том же файле, но больше нигде. В примере выше класс Canvas может использовать CanvasUtils, если они находятся в одном файле.

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

9. Полуавтоматически реализуемые свойства (отложено)
Ключевое слово field изначально планировалось для C#10, и даже было продемонстрировано на нескольких докладах Microsoft. Но эта функция не вошла в C#10, а теперь проблемы с реализацией не позволили ей попасть в C#11.

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

public class Employee
{
  public string Name
  { 
    get; 
    set => field = value.Trim();
  }
}

Т.е. вы можете продолжать использовать автоматически реализуемые свойства, даже если вам приходится иметь дело с валидацией, уведомлениями о событиях и т.п. Следить за обсуждением этой функции можно на GitHub.

10. Первичные конструкторы (отложено)
Первичные конструкторы — это функция, которая автоматически генерирует базовый конструктор, принимающий параметры и устанавливающий соответствующие приватные поля. Ещё один пример стремления сократить количество шаблонного кода. Разработчики языка экспериментировали с различными реализациями первичных конструкторов по крайней мере в двух последних версиях. Но это не то изменение, которое мы хотели бы видеть в языке реализованным наполовину. Поэтому пока ждём финальной имплементации.

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

Источник: https://medium.com/young-coder/a-mostly-complete-guide-to-c-11s-final-features-d43e6c9aa727

День 1452. #юмор
А как вы оцениваете?
Кстати, про стори-пойнты есть вот тут.

День 1453. #Карьера
Улучшаем Эмоциональный Интеллект. Часть 5
Эмоциональный интеллект – это способность понимать эмоции и управлять ими, бесценное качество, которое поможет стать более продуктивными и улучшить отношения с другими. Вот простые правила, которые помогут развить ваш эмоциональный интеллект.

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

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

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

Здесь мы сосредоточимся на доброжелательности.

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

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

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

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

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

Независимо от того, склонны вы больше к доброжелательности или меньше, вы должны стараться использовать свои сильные стороны и смягчать свои слабости. Если вы это сделаете, люди оценят то, что вы говорите не только потому, что вы говорите искренне, но и потому, что вы говорите правильные вещи.

Источники:
- https://www.inc.com/justin-bariso/how-to-increase-emotional-intelligence.html
- https://www.inc.com/justin-bariso/emotional-intelligence-personality-big-5-how-to-be-authentic.html

День 1454. #TipsAndTricks
Короткие Советы и Трюки в C#
1. Регистронезависимый Словарь
Указав StringComparer в конструкторе словаря, вы можете использовать регистронезависимые ключи для доступа к значениям:

var dict = new Dictionary<string, object>
 (StringComparer.CurrentCultureIgnoreCase)
{
  ["home"] = "casa",
  ["BRIDGE"] = "ponte"
};

Console.WriteLine(dict["Home"]);
Console.WriteLine(dict["bridge"]);

2. Sort() или OrderBy()
Оба метода сортируют элементы списка. Но есть различия.
Sort()
- сортировка «на месте» (пока, иммутабельность);
- сортировка по умолчанию.

OrderBy()
- создаёт новый список;
- можно использовать правило сортировки.

List<int> list = new() { 3, 1, 6, 2, 8};
list.Sort();
var sortedList = 
 list.OrderByDescending(_ => _);

3. String.IsNullOrEmpty или String.IsNullOrWhiteSpace
Если вам нужно проверить строку, введённую пользователем, имейте в виду, что пользователь может ввести символы, которые не будут «пойманы» методом String.IsNullOrEmpty():

        NOE NOWS
"hi"    ❌  ❌
null    ✅  ✅
""      ✅  ✅
"    "  ❌  ✅
"\n"    ❌  ✅
"\t"    ❌  ✅
"\t \n" ❌  ✅

4. Интерполяция строк с помощью FormattableString
Если вы используете интерполяцию для обработки случаев, когда значение изменяется в зависимости от культуры:
- храните строку как FormattableString;
- форматируйте её, используя IFormatterProvider (или CultureInfo).

var dt = DateTime.Now;
FormattableString fs = $"{dt:dddd}";
fs.ToString();
//Monday
fs.ToString(new CultureInfo("es-ES");
// lunes
fs.ToString(new CultureInfo("ru-RU");
// понедельник

Источник: https://twitter.com/BelloneDavide/

День 1455. #ЧтоНовенького
EF8: Необработанные SQL-Запросы на Несвязанные Типы
На прошлой неделе мы подробно рассматривали новые функции C#11, появившиеся прошедшей осенью. Пора уже заглянуть в будущее. Сегодня посмотрим, что нас ждёт в следующей версии Entity Framework.

Следующая, восьмая, версия Entity Framework должна получить новую интересную функцию: поддержку необработанных SQL-запросов без предварительного определения типа объекта результата в DbContext.

Это означает меньше шаблонного кода!

До сих пор приходилось создавать сопоставление для типов, возвращаемых из SqlQueryRaw. В Entity Framework 8 это будет выглядеть немного иначе, с чем нам поможет новая функция:

context.Database.SqlQueryRaw<MyUnmappedType>
 (@"SELECT * FROM SomeTableOrView");

Это особенно удобно, если вы работаете с большим количеством SQL-представлений или чистого SQL. До сих пор вам приходилось внутри DbContext правильно сопоставлять типы CLR с типом результата SQL-выражения. Теперь это должно происходить по соглашению.

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

Обсуждение этой функции на GitHub началось ровно 5 лет назад. Наконец, она добралась до кандидата.

Источник: https://steven-giesel.com/blogPost/d1f069fb-7f6d-4f80-a98f-734755474ae1

День 1456. #ЗаметкиНаПолях
Используем Асинхронные Потоки в .NET Framework
Хотя IAsyncEnumerable доступен только в C#8 и поддерживается в .NET Core 3.x и .NET Standard 2.1, это вовсе не означает, что вы не можете использовать эту функцию в .NET Core 2.x или .NET Framework.

Рассмотрим следующий (не компилирующийся) код в проекте .NET 4.7 и попробуем заставить его работать:

async IAsyncEnumerable<string> GetAsync()
{
  for (var i = 0; i < 20; i++)
  {
    var item = await ReadAsync(i);
    yield return item;
  }
}

async Task<string> ReadAsync(int i)
{
  await Task.Delay(100);
  return $"Count {i}";
}

Проект .NET Standard 2.0 не знает об интерфейсе IAsyncEnumerable. Поэтому первое, что нам нужно сделать, это установить NuGet-пакет Microsoft.Bcl.AsyncInterfaces.

Теперь компилятор находит интерфейс IAsyncEnumerable, но Visual Studio по-прежнему жалуется, потому что выбранная версия языка C#7.3, а асинхронные потоки — это функция C#8.

Мы можем это исправить, обновив файл .csproj проекта и указав компилятору использовать C#8 в качестве версии языка:

<PropertyGroup>
  <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
  <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
  <TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
  …
  <LangVersion>8</LangVersion>
</PropertyGroup>

Подробнее об использовании новых функций языка C# на старых платформах в этом посте.

Источник: https://bartwullems.blogspot.com/2020/01/asynchronous-streams-using.html

День 1457. #МоиИнструменты
Мониторинг Сайтов в UptimeRobot
Полезно знать, когда сайты, которые вы поддерживаете, не работают. Несмотря на то, что в ASP.NET Core есть встроенные способы проверки работоспособности, иногда нужно простое решение, которое требовало бы меньше кода, работало для произвольного количества сайтов, и просто уведомляло бы, когда сайт недоступен, и когда он снова онлайн.

UptimeRobot - полезный сервис мониторинга, который можно использовать бесплатно для 50 мониторов и при условии, что вам подойдёт 5-минутный интервал между проверками. Этого более чем достаточно для личных нужд. Кроме того, можно создать публичную страницу статуса (в бесплатной версии – на домене сервиса, в платной – на собственном), которой можно поделиться со всеми заинтересованными лицами (в отличие от стандартной панели мониторинга, которая доступна только при входе в систему). На этой странице можно выбрать мониторы, которые будут отображаться, внешний вид, задать логотип и т.п.

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

Начать довольно просто. Вы создаёте учетную запись, а затем настраиваете свой первый монитор. Помимо обычной проверки статуса ответа HTTP можно использовать пинг, проверку определённого порта или ключевого слова - любого слова, которое должно (или не должно) присутствовать на странице сайта. Последний вариант полезен, если вы не просто хотите знать, что сервер ответил каким-то кодом успеха, а что вернулось фактическое содержимое страницы (или хотя бы какая-то важная его часть).

Каждый монитор может уведомлять одного или нескольких членов команды по электронной почте о недоступности сайта или когда он снова становится доступен.

У сервиса также есть приложения под Android и iOS, так что следить можно и с телефона. А если вы хотите отображать статус сайтов вашей команды на экране ТВ, даже в бесплатном варианте есть опция "TV Mode" (на картинке ниже).

Источник: https://ardalis.com/monitor-sites-with-uptime-robot-or-your-own-process/

День 1458. #Книги
Сегодня порекомендую ещё одну книгу по PostgreSQL.

«PostgreSQL изнутри» (Рогов Е.В. — М.: ДМК Пресс, 2022).

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

Пока я её ещё не дочитал (всё-таки, 660 страниц), но уже могу порекомендовать тем, кто хочет во всех деталях познакомиться с принципами работы и тонкой настройкой СУБД PostgreSQL. Сразу оговорюсь, книга не для новичков. Необходимы знания принципов работы реляционных баз данных на хорошем уровне.

По структуре книга напомнила «CLR via C#» Рихтера. Первые 300 (!!!) страниц – внутреннее устройство. И они мне дались очень тяжело. По нескольку раз приходилось возвращаться к предыдущим главам, потому что понятия и принципы забывались. Дальше уже идёт рассказ о практическом использовании: выполнении запросов, планы выполнения, разные типы индексов и т.п.