День пятьсот тридцать второй. #ЧтоНовенького
Стивен Тауб (Stephen Toub) из Майкрософт выкатил целую «Войну и Мир» на тему производительности выходящего в ноябре .NET 5. И, судя по его подробному анализу, новая версия должна порадовать нас в этом смысле. Стивен сравнил .NET Framework 4.8, .NET Core 3.1 и .NET 5 (превью 8).
В общем, тесты он описал довольно подробно, всё можно перепроверить на своей машине. По его тестам выходит, что .NET 5 будет работать гораздо быстрее:
- сортировка чисел почти в 2 раза быстрее, чем Core 3.1,
- сортировка строк - на 15%,
- ToString – в 2 раза,
- ToUpperInvariant – в 2,5 раза
- в RegularExpressions получились совсем какие-то космические улучшения, почти на порядок.
И т.п.

В общем, почитайте, довольно интересно https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-5/

Ждём ноября.

День пятьсот тридцать третий.
Сертификат Microsoft. Экзамен 70-486. Шаг третий
Сегодня немного необычный пост. Я продолжаю подготовку к экзамену 70-486 Developing ASP.NET MVC Web Applications.
Microsoft предлагают список оцениваемых навыков. Его довольно сложно читать, т.к. всё в кучу с вычёркиваниями, добавлениями, исправлениями… Поэтому я решил отформатировать его и начал подбирать источники для подготовки.

Весь список я выложил на GitHub в виде readme документа: https://github.com/sbzenenko/ASP.NET-MVC-Exam-70-486

Я постепенно буду его дополнять источниками. Тут акцент будет не на книги, которые стоит почитать в общем, а на то, где найти информацию по конкретной узкой теме: глава или страницы книги, ссылка на статью, туториал, видео и т.п. Проблема в том, что рекомендуемое Microsoft руководство для подготовки («Exam Ref 70-486 Developing ASP.NET MVC 4 Web») датируется 2013м годом, т.е. содержит крайне устаревшую информацию.

Поэтому у меня большая просьба к сообществу. Если кто-то знает, где найти информацию по предложенным темам (особенно интересует всё, что касается Azure), пожалуйста, советуйте:
- в личке или в чате (в этом случае лучше указывайте пункт, например, 5.1.4.
- в issues на github (я могу добавить в контрибьюторы, если вам будет удобнее сам документ редактировать).

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

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

Заранее всем спасибо.

День пятьсот тридцать четвёртый. #DevOps
Как Убить Производительность Разработчиков. Начало
Немного нестандартная серия постов не совсем про кодинг, а про DevOps. Генеральный директор Humanitec Каспар фон Грюнберг делится некоторыми мыслями о производительности труда разработчиков и о том, как её улучшить.

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

Проблемы начинаются, когда команды увлекаются микросервисами и воспринимают «микро» слишком серьезно. С точки зрения инструментария вам теперь придется иметь дело с гораздо бОльшим количеством yml-файлов, docker-файлов, с зависимостями между переменными этих сервисов, проблемами маршрутизации и т.д. Микросервисы должны поддерживаться, обновляться и обслуживаться. Ваши настройки CI/CD, а также ваша организационная структура и, возможно, численность персонала нуждаются в обновлении.

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

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

Самая распространенная ошибка - это встраивание ваших файлов конфигурации или переменных среды в контейнер. Основная идея контейнеризации - мобильность. При жёсткой конфигурации вам придётся писать настройки для каждой отдельной среды. Вы хотите изменить URL? Хорошо, измените его в 20 разных местах, а затем пересоберите проект.

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

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

Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec

День пятьсот тридцать пятый. #DevOps
Как Убить Производительность Разработчиков. Продолжение
Убийца №3: Неправильное Использование Kubernetes
Все крутые ребята расхваливают Kubernetes. Тем не менее, его трудно поддерживать и трудно интегрировать в ваш поток разработки, сохраняя при этом высокую производительность. Многое может пойти не так.

Худший случай использования Kubernetes: Коллега X очень хотел его попробовать и нашёл руководство для начинающих онлайн. Они создали кластер с нуля, и он отлично работал с тестовым приложением. Затем они начали миграцию первого приложения и попросили своих коллег начать взаимодействие с кластером с помощью kubectl. Половина команды теперь была занята изучением этой новой технологии. Человек, который обслуживает кластер, теперь будет занят этим постоянно, как только кластер получит первую рабочую нагрузку. Конфигурация CI/CD совершенно не подготовлена ​​для решения этой проблемы, и общая производительность снижается, поскольку вся команда пытается сбалансировать Kubernetes.

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

Лучшие практики:
1. Там, где это возможно, команды не должны сами устанавливать и запускать barebone кластер, а должны использовать управляемую службу Kubernetes. Прочитайте отзывы о том, какой управляемый кластер Kubernetes лучше всего соответствует вашим потребностям. На данный момент Google Kubernetes Engine (GKE) является лучшим с чисто технической точки зрения. За ним следуют службы Azure Kubernetes (AKS) и Amazon Elastic Kubernetes Service.
2. Используйте платформы автоматизации или API непрерывной доставки. Они позволяют запускать вашу рабочую нагрузку на K8 вне поля зрения разработчиков. Практически не имеет смысла посвящать всех в сложности процесса конфигурации.
3. Если команда действительно хочет, чтобы разработчики сами управляли кластером Kubernetes, нужно дать им достаточно времени, чтобы по-настоящему понять архитектуру, шаблоны проектирования, kubectl и т.д. и действительно сосредоточиться на этом.

Убийца №4: Игнорирование постоянной доставки
Существует распространенное заблуждение, что работа выполнена хорошо, если настроена непрерывная интеграция. Но вам всё ещё не хватает непрерывной доставки! Многие из тех, кто использует термин «инструмент CI/CD» думают, что добились непрерывной доставки, если у них есть Jenkins, CircleCI и т.д. Но это не так.

Тщательная настройка Continuous Delivery, с использованием собственных сценариев или «как услуга», является гораздо более важным «связующим звеном»:
1. Она позволяет интегрировать все различные компоненты, от системы управления исходным кодом до CI-Pipeline, от базы данных до кластера и от настройки DNS до IaC, в удобную среду для разработчиков.
2. Это способ структурировать, поддерживать и управлять растущим количеством сценариев yml и конфигурации. Если всё сделано правильно, это позволит вашим разработчикам динамически разворачивать среды с помощью артефактов, созданных CI-Pipeline с полной настройкой и подготовкой базы данных.
3. Она может выступать в качестве системы контроля версий для состояний конфигурации с подтверждённой записью о том, что, где, в какой конфигурации развернуто, и позволяет выполнять откат назад и вперед, а также управлять развёртываниями.
4. Хорошо продуманные настройки CD оказывают кардинальное влияние на производительность труда разработчиков. Они делают разработчиков самодостаточными, уменьшают количество зависимостей в команде, повышая удобство обслуживания вашей конфигурации.
5. Команды, использующие эти методы, делают релизы чаще, быстрее, демонстрируют в целом более высокую производительность и удовлетворённость от работы.

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

Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec

День пятьсот тридцать шестой. #DevOps
Как Убить Производительность Разработчиков. Окончание
Убийца №5: Неуправляемая автоматизация тестирования в ограниченной конфигурации тестов
Эффективное тестирование невозможно без автоматизации. С непрерывной доставкой приходит непрерывная ответственность, чтобы ничего не сломать.
Вы должны постоянно следить за тем, чтобы не попасть в ловушку инвертирования тестовой пирамиды. Для этого вам нужно иметь возможность запускать правильные тесты в нужной точке жизненного цикла разработки.

Достаточный инструментарий CI поможет вам правильно разместить модульные и интеграционные тесты в нужном месте, а инструментарий CD с управлением конфигурацией и средой поможет вам надёжно выполнять автоматизированные сквозные тесты.

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

Убийца №6: Самостоятельное управление базами данных
Товарищ по команде, который только что ушел, отвечал за настройку MongoDB для клиентского проекта и, конечно, использовал проект с открытым исходным кодом, в котором размещалась база. И, естественно, передача дел была «безупречной», база данных не была должным образом защищена, и однажды вечером случилось то, что должно было: «Ваша база данных была сохранена и архивирована. У вас есть 7 дней, чтобы её восстановить. Пришлите 0.1 BTC …»
И конечно:
- Вы проверяете резервные копии.
- В коде резервного копирования обнаружилась ошибка.
- Теперь вам нужно восстанавливать все данные.

Это реальный пример, который часто случается. Самоуправляемые БД представляют собой операционный риск и угрозу безопасности. Используйте Cloud SQL или другие предложения и спите спокойно. Эти сервисы предлагают большинство баз данных на всех крупных облачных провайдерах, и они являются более многофункциональными, зрелыми и защищёнными. Кроме того, они часто дешевле и доставляют минимум неудобств для разработчика.

Убийца №7: Использование нескольких облаков без причины
Есть разница между переходом на несколько облаков и попыткой сделать ваши системы независимыми от облачных вычислений и переносимыми. Последнее имеет много различных преимуществ, таких как динамические среды, и имеет больше смысла, чем переход на несколько облаков. Конечно, есть наследие: одни команды использовали GCP, другой отдел начал с AWS, а третьим нужны специальные условия - и вуаля. Можно спорить, что одни сервисы работают лучше или дешевле, чем другие. Но чтобы эти эффекты действительно имели значение, вам нужен достаточный объём. Несложные многооблачные установки требуют высокой степени автоматизации и защиты разработчиков от задач их настройки и поддержки. В противном случае человек попадает в ад сценариев.
Как правило: не используйте несколько облаков, если в этом нет необходимости.

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

Источник: https://dzone.com/articles/how-to-kill-your-developer-productivity-humanitec

День пятьсот тридцать седьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
51. Не Забывайте про "Hello World!"
Пол Ли, более известный как Хоппи, имел в компании репутацию эксперта по вопросам программирования. Мне нужна была помощь, я подошёл к столу Хоппи и спросил, может ли он взглянуть на один кусок кода.

«Конечно», - сказал он, - «тащи стул». Я аккуратно, чтобы не опрокинуть пустые банки от колы, сложенные в пирамиду позади него, присел рядом.

- Что за код код?
- В функции XXX в файле YYY, - сказал я.
- Так, давай посмотрим на эту функцию, - Хоппи свернул свой код и пододвинул свою клавиатуру ко мне.
- А где IDE?

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

«Что тут произойдёт, если х отрицательный?» - спросил я. - «Здесь явно ошибка.»

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

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

csc tryit.cs

И вот его программа, придуманная всего пару минут назад, уже работала. Мы попробовали несколько значений и подтвердили мои подозрения (ну хоть в чём-то я оказался прав!). Затем он перепроверил соответствующий код в проекте уже в IDE. Я поблагодарил Хоппи и ушёл, снова стараясь не разрушить его пирамиду из колы.

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

using System;
class Program {
  static void Main(string[] args) {
    Console.WriteLine("Hello World!");
  }
}

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Thomas Guest (в оригинале был код на C).

День пятьсот тридцать восьмой. #DotNetAZ
Dotnet A-Z. 3
В этой серии постов рассмотрим наиболее распространённые понятия в .NET в алфавитном порядке.

Ecosystem (Экосистема)
Всё ПО среды исполнения, средства разработки и ресурсы сообщества, которые используются для создания и запуска приложений для данной технологии. Термин «экосистема .NET» отличается от аналогичных терминов, таких как «стек .NET», т.к. включает сторонние приложения и библиотеки.

Framework (Фреймворк)
В общем случае - это комплексная коллекция API, которая облегчает разработку и развёртывание приложений, основанных на конкретной технологии. В этом смысле ASP.NET Core или Windows Forms являются примерами фреймворков приложений. Слово «фреймворк» имеет более конкретное значение в следующих терминах:
- .NET Framework - Реализация .NET, которая работает только в Windows.
- целевой фреймворк – Конкретная коллекция API, на которую опирается приложение или библиотека .NET.
- TFM (Моникер целевого фреймворка) – Стандартизированный токен имени фреймворка (например, net462 для .NET Framework версии 4.6.2).
В существующей документации Майкрософт термин «фреймворк» используется как для обозначения .NET Framework, так и иногда может относиться к другой реализации .NET. Например, .NET Core может называться фреймворком в некоторых статьях.

GC (Garbage collector – Сборщик мусора)
Сборщик мусора - это реализация автоматического управления памятью. GC освобождает память, занятую объектами, которые больше не используются.
Подробнее…

IL (Intermediate language - Промежуточный язык)
Языки высокого уровня, такие как C#, в .NET компилируются в аппаратно-независимый набор команд, который называется промежуточным языком (IL), иногда MSIL (Microsoft IL) или CIL (Common IL).
Подробнее…

JIT (Just-in-time компилятор)
Подобно AOT, этот компилятор переводит IL в машинный код, который понимает процессор. Но в отличие от AOT, JIT-компиляция происходит по требованию и выполняется на той же машине, на которой должен выполняться код. Поскольку JIT-компиляция происходит во время выполнения приложения, время компиляции является частью времени выполнения. Таким образом, JIT-компиляторы должны находить баланс между временем, потраченным на оптимизацию кода, и выигрышем, который эта оптимизация даёт. Преимуществом JIT-компилятора является то, что он знает конфигурацию оборудования, на котором выполняется код, поэтому может применять соответствующие процессорные оптимизации, что освобождает разработчиков от необходимости поставлять различные реализации кода для разных машин.
Подробнее…

Источник: https://docs.microsoft.com/en-us/dotnet/standard/glossary

День пятьсот тридцать девятый. #ЧтоНовенького #CSharp9
C#9: Новые Ключевые слова and, or и not для Сопоставления по Шаблону
Хотя это может звучать как первоапрельская шутка, в C#9 хотят добавить and, or и not в список ключевых слов для использования в сопоставлении по шаблону.

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

В этом и проблема. Если вы работаете с логическими значениями, то операторы && и || будут неоднозначными. Компилятор не сможет определить, относятся они к значениям или к шаблонам. Чтобы проиллюстрировать эту идею, рассмотрим дизъюнктивный шаблон:

if (myBool is true or false)

Это будет интерпретировано как «истина, если myBool равно true или если myBool равно false».

Если бы мы использовали операторы && и || для объединения шаблонов, получился бы следующий код:

if (myBool is true || false)

Но это буквально означает «истина, если myBool равняется результату логического выражения (true или false)», что можно упростить до «истина, если myBool равняется true». А это совершенно не то, что мы хотели бы получить в дизъюнктивном шаблоне.

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

Источник: https://www.infoq.com/news/2020/07/CSharp-And-Or-Not/

День пятьсот сороковой. #MoreEffectiveCSharp
14. Различайте Интерфейсные и Абстрактные Методы
На первый взгляд реализация интерфейса выглядит так же, как и переопределение абстрактной функции. Но есть различия:
- Реализация абстрактного члена базового класса должна быть виртуальной; реализация члена интерфейса – не обязательно.
- Интерфейсы могут быть реализованы явно, что скроет их реализацию от открытого интерфейса класса.

Рассмотрим варианты реализации простого интерфейса в иерархии классов:

interface IMessage {
  void Message();
}
public class MyClass : IMessage {
  public void Message() => WriteLine(nameof(MyClass));
}

Метод Message() является частью публичного интерфейса MyClass, а также может быть вызван через приведение к IMessage. Теперь добавим производный класс:

public class MyDerivedClass : MyClass {
  public new void Message() =>
    WriteLine(nameof(MyDerivedClass));
}

Нам пришлось добавить ключевое слово new. MyClass.Message() не является виртуальным, его нельзя переопределить. Класс MyDerived создаёт новый метод Message, который не переопределяет MyClass.Message, а скрывает его. Однако MyClass.Message по-прежнему доступен через IMessage:

MyDerivedClass d = new MyDerivedClass();
d.Message(); // выведет "MyDerivedClass"
IMessage m = d as IMessage;
m.Message(); // выведет "MyClass"

Приведение к IMessage вызывает базовую реализацию. Если доступа к базовому классу нет, можно реализовать интерфейс и в производном классе:

public class MyDerivedClass : MyClass, IMessage {…}

Тогда поведение изменится:

m.Message(); // выведет "MyDerivedClass"

Ключевое слово new всё равно придётся использовать. Базовая реализация будет доступна через апкаст:

MyClass b = d;
b.Message(); // выведет "MyClass"

Если доступ к базовому классу есть, объявите интерфейсный метод виртуальным, а в производных классах используйте ключевое слово override. Тогда переопределённая версия метода будет вызываться всегда: и из производного класса, и после приведения как к базовому классу, так и к интерфейсу.

Также можно реализовать интерфейс без фактической реализации его методов:

public abstract class MyClass : IMessage {
  public abstract void Message();
}

Тогда все конкретные производные типы должны переопределить и предоставить собственную реализацию Message(). Интерфейс IMessage является частью объявления MyClass, но реализация методов откладывается до каждого конкретного производного класса.

Можно реализовать паттерн Шаблонный метод:

public class MyClass : IMessage {
  protected virtual void OnMessage() {}
  public void Message() {
    OnMessage();
    WriteLine(nameof(MyClass));
  }
}

Любой производный класс может переопределить OnMessage() и добавить свой код в реализацию контракта IMessage.

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

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

День пятьсот сорок первый. #Оффтоп
Сегодня расскажу про классную серию видео на ютуб от Shawn Wildermuth. Серия называется Maintainers (Сопровождающие). Это видео о людях, которые сделали внушительный вклад в развитие открытого кода. В первом видео серии Jimmy Bogard описывает историю создания знаменитого AutoMapper. Как он создавался, почему было принято решение сделать его открытым, как появлялись первые контрибьюторы и почему довольно сложно сразу применять изменения сделанные контрибьюторами.

А поскольку это видео всего на 9 минут, вот вам ещё одно от Jimmy Bogard. Это его выступление на онлайн конференции NDC в апреле, где он рассказывает про «Архитектуру Вертикальных Слоёв» (Vertical Slice Architecture).

Проблема стандартной n-слойной архитектуры приложений, состоящей из UI, домена, бизнес-логики и слоя доступа к данным, в том, что чтобы сделать даже небольшое изменение (например, добавить поле в форму), приходится изменять огромное количество файлов и классов во всех слоях приложения.

Почему бы не разделить приложение по слоям вариантов использования. Фактически вариантов использования веб-приложения всего два:
GET:

 Запрос (Query) – Обработчик (Handler) – Ответ (Response)

POST:

 Команда (Command) – Обработчик (Handler) – Ответ (Response)

Тогда можно использовать принцип CQRS и разделить приложение на соответствующие слои. Если совсем упрощённо, то в MVC, Модель – это Запрос/Команда, логика Контроллера помещается в Обработчик, а Ответ передаётся в Представление, либо в качестве ответа API.

В общем, гораздо более подробно это описано в видео. Энджой)))

День пятьсот сорок второй. #ЧтоНовенького #CSharp9
C#9: Операторы Диапазона в Конструкциях Switch и Сопоставлениях по Шаблону
С момента первого выхода C# разработчики жаловались на отсутствие операторов диапазона в конструкциях switch. Как часть улучшений сопоставлений по шаблону в C#9, это ограничение было устранено.
Следующие шаблоны будут разрешены после ключевых слов case или is:
- < константа
- > константа
- <= константа
- >= константа

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

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

Мариуш Павельски отвечает, почему ограничение может стать проблемой:
«Я просто думаю, что будет много людей, которые захотят использовать ключевые слова is, and и or просто как ещё один способ написания логических выражений. Ещё одна небольшая функция C#, которая делает код более лаконичным. Они не будут знать, что это часть большой функциональности сопоставления по шаблону, которая «была разработана для работы с константами». Они будут просто сбиты с толку, когда вместо константы будут использовать имя переменной и получат ошибку «CS0150: A constant value is expected» (Ожидается константное значение).»

Как бы то ни было, операторы and, or и not также могут быть использованы в сочетании с диапазонами. Например,
bool IsLetter(char c) =>
c is >= 'a' and <= 'z' or >= 'A' and <= 'Z';

Это немного трудно читать, поэтому в выражениях можно использовать круглые скобки:
bool IsLetter(char c) =>
c is (>= 'a' and <= 'z') or (>= 'A' and <= 'Z');

Источник: https://www.infoq.com/news/2020/07/CSharp-9-Range-Patterns/

День пятьсот сорок третий. #DotNetAZ
Dotnet A-Z. 4
В этой серии постов рассмотрим наиболее распространённые понятия в .NET в алфавитном порядке.

implementation of .NET (реализация .NET)
Реализация .NET включает в себя:
- Одну или несколько сред исполнения: CLR, CoreCLR, CoreRT.
- Библиотеку классов, которая реализует версию .NET Standard и может включать дополнительные API: .NET Framework Base Class Library, .NET Core Base Class Library.
- Необязательно: один или несколько фреймворков приложений: ASP.NET, Windows Forms и WPF включены в .NET Framework.
- Необязательно: инструменты разработки. Некоторые инструменты разработки используются несколькими реализациями.
Примеры реализаций .NET:
- .NET Framework – Реализация .NET, которая работает только в Windows.
- .NET Core – Кроссплатформенная, высокопроизводительная реализация .NET с открытым исходным кодом.
- Universal Windows Platform (UWP) – Реализация .NET, которая используется для создания современных приложений с сенсорным управлением и для ПО Интернета вещей (IoT).

Library (библиотека)
Коллекция API, которая может быть вызвана из приложений или других библиотек. Библиотека .NET состоит из одной или нескольких сборок.
Термины библиотека и фреймворк часто используются взаимозаменяемо.

Metapackage (метапакет)
Пакет NuGet, это пакет, который не содержит сборок, но содержит список зависимостей. Используется для лёгкого добавления заданного набора библиотек в проект, т.к. достаточно установить только метапакет и все его зависимости будут автоматически загружены и подключены.
Например, метапакет Microsoft.AspNetCore.App предоставляет набор API по умолчанию для создания приложения ASP.NET Core.

Источник: https://docs.microsoft.com/en-us/dotnet/standard/glossary

День пятьсот сорок четвёртый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
52. Дайте Проекту Голос
Ваш проект скорее всего использует систему контроля версий. Возможно, он подключен к серверу непрерывной интеграции, который проверяет правильность кода с помощью автоматических тестов. Это замечательно.

Вы можете добавить инструменты статического анализа кода на сервере непрерывной интеграции для сбора метрик кода. Эти метрики предоставляют обратную связь о конкретных аспектах вашего кода, а также об их изменении с течением времени. Если вы устанавливаете метрики кода, всегда будет некоторая граница, которую вы не захотите пересекать. Предположим, вы начали с 20% покрытия тестами и никогда не хотите падать ниже 15%. Непрерывная интеграция помогает отслеживать все эти цифры, но вам всё равно придётся регулярно их проверять. Но представьте, что вы могли бы делегировать эту задачу самому проекту, позволив ему сообщать, когда метрики ухудшаются.

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

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

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

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

Устройства XFD играют роль голосовых связок вашего проекта. С его помощью проект критикует или хвалит разработчиков в соответствии с правилами, выбранными командой. Вы можете пойти дальше, применив ПО для синтеза речи и пару динамиков. Тогда ваш проект действительно станет говорить.

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

День пятьсот сорок пятый. #ЧтоНовенького #CSharp9
C#9: Незначительные Улучшения в Лямбдах
В C#9 лямбда-функции получат два обновления. Ни одно из них не изменит способ написания кода, но они помогут разработчику прояснить свои намерения.

Дискард-Параметры Лямбда Функций
Позволят разработчикам явно указать, что некоторые параметры не нужны, что предотвратит ошибочные предупреждения компилятора о неиспользуемых параметрах. Это может быть полезно, например, в обработчиках событий, когда не нужны параметры sender и eventArgs:

button1.Click += (s, e) => ShowDialog();

Замена параметров, как показано ниже, позволит явно указать, что они не используются:

button1.Click += (_, _) => ShowDialog();

При необходимости могут быть использованы типы:

var handler = (object _, EventArgs _) => ShowDialog();

Статические Анонимные Функции
Будут использоваться, чтобы обозначить, что лямбда или анонимная функция не может захватывать локальные переменные (включая параметры). Вот пример из оригинального предложения функционала:

int y = 10;
someMethod(x => x + y); 
//захватывает 'y', приводя к неявному выделению памяти

Проблема в том, что это неявно приводит к увеличению времени жизни локальной переменной, т.к. анонимная функция может существовать дольше, чем окружающий её метод.
Чтобы избежать случайного захвата любого локального состояния при предоставлении лямбда-функций в качестве аргумента метода, предлагается добавить к лямбда-объявлению ключевое слово static. Это сделает лямбда-функцию похожей на статический метод, который не может захватывать локальные объекты и не имеет доступа к this или base:

int y = 10;
someMethod(static x => x + y); //ошибка!

Чтобы исправить эту ошибку, переменная y должна быть изменена на константу или статическое поле:

const int y = 10;
someMethod(static x => x + y);

Вот основные правила для статических анонимных функций:
- может ссылаться на статические члены из окружающего кода;
- может ссылаться на определения констант из окружающего кода;
- не может захватывать состояние из окружающего кода, т.е. локальные объекты, параметры и this из окружающего кода недоступны;
- не может ссылаться на экземплярные члены окружающего её класса;
- nameof() внутри статической анонимной функции может ссылаться на локальные объекты, параметры, this или base из окружающего кода.

Источник: https://www.infoq.com/news/2020/07/CSharp-Lambdas/

День пятьсот сорок шестой.
7 Опасных Ошибок, Которые Легко Совершить в C#/.NET. Начало 1-2
В каждом языке есть ловушки, в которые легко попасть и ошибочные представления об ожидаемом поведении языка. Вот некоторые из них.

1. Непонимание Отложенного Исполнения
Опытные разработчики хорошо осведомлены об этой функции .NET, но она может испортить жизнь тем, кто о ней не знает. Если коротко, методы/операторы, возвращающие IEnumerable<T> через yield, выполняются не на строке вызова метода/оператора, а когда к результирующей коллекции обращаются каким-либо образом. То же относится к большинству методов LINQ.

Рассмотрим следующее выдуманное модульное тестирование:

[TestMethod]
[ExpectedException(typeof(ArgumentNullException))]
public void Ensure_Null_Exception_Is_Thrown() {
  var result = RepeatString5Times(null);
}
[TestMethod]
[ExpectedException(typeof(InvalidOperationException))]
public void Ensure_Invalid_Operation_Exception_Is_Thrown() {
  var result = RepeatString5Times("test");
  var firstItem = result.First();
}

private IEnumerable<string> RepeatString5Times(string toRepeat) {
  if (toRepeat == null)
    throw new ArgumentNullException(nameof(toRepeat));
  for (int i = 0; i < 5; i++) {
    if (i == 3)
      throw new InvalidOperationException("3 ужасное число");
    yield return $"{toRepeat} - {i}";
  }
}

Оба теста не пройдут. Первый, потому что к result ни разу не обращаются и тело метода не вызывается. Второй, т.к. механизм отложенного выполнения выйдет из метода, когда это необходимо (т.е. после выдачи первого элемента), поэтому i == 3 никогда не выполнится.

2. Предположение о Порядке Элементов в Словаре
Элементы в List<T> сохраняются в том же порядке, в котором вы их добавляете. Но иногда нужно иметь объект, связанный с элементом списка, и очевидным ответом является использование Dictionary<TKey, TValue>, который позволяет указать связанное значение для ключа. Вы можете выполнить итерацию по словарю, используя foreach, и большую часть времени он будет вести себя так, как ожидалось: вы будете получать доступ к элементам в порядке их добавления. Однако порядок элементов словаря не определён, т.е. это счастливое совпадение, и на это поведение не стоит полагаться. Это объясняется в документации Microsoft, но кто ж её читает))) Следующий код:

var dict = new Dictionary<string, object>();        
dict.Add("first", new object());
dict.Add("second", new object());
dict.Remove("first");
dict.Add("third", new object());
foreach (var entry in dict)
  Console.WriteLine(entry.Key);

Выведет:

third
second

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

Источник: https://chrisstclair.co.uk/7-dangerous-mistakes-in-c-net-that-are-easy-to-make/

День пятьсот сорок седьмой.
7 Опасных Ошибок, Которые Легко Совершить в C#/.NET. Продолжение 3-4
В каждом языке есть ловушки, в которые легко попасть и ошибочные представления об ожидаемом поведении языка. Вот некоторые из них.
Начало 1-2.

3. Игнорирование Безопасности Потоков
Многопоточность великолепна. При правильной реализации может произойти значительное улучшение производительности вашего приложения. Однако вы должны быть осторожны с объектами, которые вы изменяете, потому что могут возникать, на первый взгляд, случайные ошибки.

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

В качестве примера возьмем этот блок кода, который использует простой, но не потокобезопасный List<T>:

var items = new List<int>();
var tasks = new List<Task>();
for (int i = 0; i < 5; i++) {
  tasks.Add(Task.Run(() => {
    for (int k = 0; k < 10000; k++)
      items.Add(i);
  }));
}
Task.WaitAll(tasks.ToArray());
Console.WriteLine(items.Count);

Мы добавляем числа от 0 до 4 в список по 10000 раз каждое, т.е. мы должны получить список в 50000 элементов, верно? Ну, есть небольшой шанс, что так и получится, но ниже мои результаты 5 выполнений:

28191
23536
44346
40007
40476

Попробуйте сами

Так получается, потому что метод Add не является атомарным, т.е. поток может «прервать» исполнение метода. То есть размер массива может измениться, в то время как другой поток находится в процессе добавления элемента, либо два потока могут добавлять элементы с одним индексом. Иногда могут возникать исключения IndexOutOfRange или ArgumentException, вероятно, потому что размер массива изменился во время добавления к нему элемента. Что делать? Мы могли бы использовать ключевое слово lock, чтобы гарантировать, что только один поток может добавлять элемент в список одновременно, но это может значительно повлиять на производительность. Microsoft любезно предоставляет несколько потрясающих коллекций, которые безопасны для потоков и оптимизированы для производительности.

4. Неправильное Округление
Теперь о чём-то более простом. .NET имеет прекрасный статический метод Round в классе Math, который принимает числовое значение и округляет до заданного десятичного знака. Работает обычно идеально, но что делать, когда вам нужно округлить 2.25 до десятых?

Math.Round(2.25, 1);

Вероятно, вы ожидаете, что это округлится до 2.3 – ведь нас так учили в школе. Однако, похоже, .NET использует «округление банкиров» и округляет приведенный пример до 2.2! Банкиры в таком случае округляют до ближайшей чётной цифры. К счастью, это можно легко переопределить в методе Math.Round:

Math.Round(2.25, 1, MidpointRounding.AwayFromZero);

По умолчанию используется MidpointRounding.ToEven.

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

Источник: https://chrisstclair.co.uk/7-dangerous-mistakes-in-c-net-that-are-easy-to-make/