День семьсот шестьдесят седьмой. #Оффтоп #ЗадачиНаСобеседовании
Давненько у нас не было задач.

Допустим, вы ищете квартиру. Для простоты представим улицу в виде одномерного массива кварталов. Пусть у нас будет только одна улица в городе, идеально прямая, а расстояния между кварталами одинаковы и равны 1.
В каждом квартале есть подходящая вам квартира. Кроме того, в кварталах случайным образом расположены важные для вас объекты: магазин, тренажёрный зал, школа для ребёнка и т.п. Допустим, что они одинаково для вас важны. Идеальная для вас квартира находится квартале с наименьшим расстоянием до самого дальнего важного объекта. Обратите внимание: не с минимальной суммой расстояний до всех объектов, а с минимальным наибольшим расстоянием! Задача – найти такой квартал.

Кварталы даны в виде массива словарей (не пугайтесь, это для наглядности, и чтобы не создавать кучи сущностей 😊). В словаре ключ – строковое название объекта, и логическое значение есть он в квартале или нет. Например, вот так:

[
 {{"gym",false},{"school",false},{"store",true}},
 {{"gym",true },{"school",false},{"store",false}},
 {{"gym",true },{"school",false},{"store",true}},
 {{"gym",false },{"school",false},{"store",false}},
 {{"gym",false },{"school",true},{"store",true}}
]

То есть, в первом квартале нет тренажёрного зала и школы, но есть магазин. Во втором есть только тренажёрный зал. В третьем – зал и магазин. И т.д.

Таким образом, в первом квартале дальше всего идти до школы - 4. А победителем получается квартал №4. Хотя там ничего нет, но из него до всех объектов расстояние 1.

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

На этот раз у меня для вас есть даже шаблон проекта с тестами: https://github.com/sbzenenko/NetDeveloper/tree/main/ApartmentFinder
Всё, что вам надо сделать – реализовать метод Find(), принимающий массив кварталов и возвращающий индекс идеального квартала.

Вопросы и предложения оставляйте в комментариях. Через пару дней выложу решение с объяснением.

День семьсот шестьдесят восьмой. #ЗаметкиНаПолях
Обнуляемый null
Рассмотрим следующий код:

public class Person {
  public string FirstName { get; }
  public string LastName { get; } = null!;
  public string? MiddleName {get; } = null;

  public Person (string first, 
      string last, string? middle) {
    FirstName = first;
    LastName = last;
    MiddleName = middle;
  }
}

Что значит null! ?
Раньше оператор ! означал отрицание в логических выражениях. Но начиная с C#8 в языке допустимо использование обнуляемых ссылочных типов. Поэтому оператор ! приобрёл другое значение и стал называться null-снисходительным (null-forgiving).

Свойство MiddleName обнуляемое (string?), т.к. у человека может не быть отчества. Тогда:

Console.WriteLine(person.MiddleName.Length);

выдаст предупреждение, что MiddleName может быть null, а

Console.WriteLine(person.MiddleName!.Length);

не выдаст предупреждения из-за null-снисходительного оператора.

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

Можно рассматривать операторы ? и ! как приведение типов
? = из необнуляемого в обнуляемый
! = из обнуляемого в необнуляемый

Например:

string? x;

? делает из необнуляемого string обнуляемый тип, поэтому можно использовать x = null.

string y;

Здесь y = null приводит к предупреждению компилятора, из-за присваивания null необнуляемому типу. Аналогично y = x приведёт к предупреждению, т.к. x может быть null. Однако y = x! не вызовет предупреждения, т.к. мы «гарантируем», что x не null.

ВНИМАНИЕ: оператор ! отключает только проверку компилятора на уровне системы типов. Во время выполнения значение может быть null. Поэтому использование null-снисходительного оператора может быть признаком плохого дизайна системы, поскольку он сводит на нет все усилия проверки на null-безопасность, которую выполняет компилятор.

Использование оператора ! может создать очень трудные для поиска ошибки. Если у вас есть свойство, помеченное как необнуляемое, предполагается, что его можно использовать безопасно. Но во время выполнения вы можете неожиданно столкнуться с исключением NullReferenceException, поскольку значение фактически стало null из-за обхода проверок компилятора с помощью оператора !.

Зачем тогда он нужен?
Существуют допустимые варианты использования, в которых использование является целесообразным:
- В некоторых (редких) случаях компилятор не может определить, что обнуляемое значение на самом деле не может быть null.
- Для упрощения миграции старого кода, не использовавшего обнуляемые ссылочные типы.
- В некоторых случаях вас просто не волнует, что что-то будет null.
- В тестах для проверки поведения кода при получении null.

Так что же такое null! ?
null! сообщает компилятору, что null не допускает значения null. Странно, правда? Но это то же самое, что и x! из примера выше. Литерал null допускает значение null по определению. Но, как мы узнали, обнуляемость любого типа можно переопределить с помощью оператора !.

Систему типов не волнует фактическое значении переменной во время выполнения. Её заботит только тип переменной времени компиляции. И в исходном примере свойство LastName (null!) не допускает значения null, что допустимо для системы типов.

Источник: https://stackoverflow.com/questions/54724304/what-does-null-statement-mean

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

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

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

Более сложные инструменты, такие как Splint для C, Pylint для Python или анализаторы Roslyn для .NET настраиваются. То есть вы можете выбрать, какие ошибки и предупреждения будет выдавать инструмент, с помощью файла конфигурации, в командной строке или в вашей IDE. В некоторых случаях можно писать аннотации для анализатора прямо в коде.

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

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

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

День семьсот семидесятый. #Оффтоп #ЗадачиНаСобеседовании
Ответ на задачу про поиск квартиры.

Создадим двумерный массив для хранения расстояний. В строках будут кварталы, в столбцах объекты. При этом, если объект присутствует в квартале, отметим соответствующее расстояние как 0, если нет, для начала отметим его недостижимо большим значением, например, 999999 (ниже буду использовать *). Таким образом, для примера из задачи:

[
 {{"gym",false},{"school",false},{"store",true}},
 {{"gym",true },{"school",false},{"store",false}},
 {{"gym",true },{"school",false},{"store",true}},
 {{"gym",false },{"school",false},{"store",false}},
 {{"gym",false },{"school",true},{"store",true}}
]

Первый квартал будет

1: * * 0

Теперь проходим вдоль массива кварталов. Если соответствующий объект есть, заполняем ячейку нулём, в противном случае заполняем её значением на 1 больше, чем в предыдущем квартале. Например, во втором квартале объект "store" будет иметь значение 1. Большие значения нас пока не интересуют, там будет значение <очень много>+1 (оставим их как *). Тогда второй квартал будет:

2: 0 * 1

И так далее:

3: 0 * 0
4: 1 * 1
5: 2 0 0

Теперь проходим массив кварталов обратно. На этом этапе:
1. Задаём значение расстояния как минимальное между существующим значением и значением на 1 больше, чем в предыдущем квартале. То есть, если, проходя в одну сторону, мы получили расстояние до объекта в 3 квартала, но он находится в следующем квартале, то, проходя в обратную сторону, мы зададим минимальное расстояние между 3 и 1 – 1. Аналогичным образом мы заменим все большие значение, обозначенные *.
2. Кроме того, рассчитав все расстояния в квартале, считаем максимальное из них.

5: 2 0 0 (макс: 2)
4: 1 1 1 (макс: 1)
3: 0 2 0 (макс: 2)
2: 0 3 1 (макс: 3)
1: 1 4 0 (макс: 4)

И, наконец, из максимальных значений выбираем наименьшее – 1 в 4м квартале.

Таким образом, нам нужно дважды пройти массив кварталов, в каждом перебрать все объекты. Если количество кварталов взять за M, количество объектов – за N, то сложность решения по времени O(2*M*N), сложность по памяти – O(M*(N+1)).

Код решения с тестами: https://github.com/sbzenenko/NetDeveloper/tree/main/ApartmentFinderSolution

PS: есть ещё нахождение максимума по N и минимума по M, которые сами по себе добавляют O(logM) и O(logN) по времени, но их можно находить параллельно с обратным прохождением массива.

Источник: https://youtu.be/rw4s4M3hFfs

День семьсот семьдесят первый. #ЧтоНовенького
Что Нового в EF Core 6 Preview 1
Ниже описаны некоторые из основных нововведений в предварительной версии EF Core 6.

1. Атрибут Unicode
Строковое свойство теперь можно сопоставить со столбцом, не поддерживающим Юникод:

[Unicode(false)]
public string Isbn { get; set; }

Поскольку номер ISBN не может содержать не-юникод символы, атрибут сообщит СУБД, что можно использовать не-юникод строку. Например, в SQL Server будет использован varchar вместо nvarchar.

2. Атрибут Precision
Теперь можно задать точность поля базы данных, указав количество цифр всего и после запятой, не используя непосредственно тип данных, поддерживаемый СУБД:

[Precision(precision: 10, scale: 2)]
public decimal Price { get; set; }

3. Атрибут EntityTypeConfiguration
Атрибут позволяет определять класс конфигурации сущности, позволяя вынести конфигурацию в отдельный класс, а не помещать её всю в OnModelCreating.

[EntityTypeConfiguration(typeof(BookConfiguration))]
public class Book {…}

При этом класс конфигурации должен реализовывать IEntityTypeConfiguration<T>:

public class BookConfiguration : 
 IEntityTypeConfiguration<Book> {…}

ПРИМЕЧАНИЕ. Типы, помеченные атрибутом EntityTypeConfiguration не будут автоматически обнаруживаться в сборке. Типы сущностей должны быть явно добавлены в контекст EF.

4. EF.Functions.Random
EF.Functions.Random соответствует функции СУБД, возвращающей псевдо-случайное число от 0 до 1. Реализации уже готовы для SQL Server, SQLite, и Cosmos.

5. Проверка на null обязательных полей в in-memory базе
In-memory база данных теперь будет выбрасывать исключение при попытке сохранить null в свойстве, помеченном, как обязательное (например, атрибутом Required).
Эта проверка может быть отключена при необходимости:

….UseInMemoryDatabase("…")
 .EnableNullabilityCheck(false);

Источник: https://devblogs.microsoft.com/dotnet/announcing-entity-framework-core-6-0-preview-1/

День семьсот семьдесят второй. #ЗаметкиНаПолях
Автоматическая Жадная Загрузка Навигационных Свойств в EF Core
Обычно при загрузке навигационных свойств в EF Core вы вынуждены использовать метод Include, чтобы указать, какие навигационные свойства нужно вернуть в запрос. Это очень хорошая практика явно указывать, какие данные вам на самом деле нужны.

Например, допустим, что у нас есть есть два класса: контакт и его email адреса.

class Contact {
  public int Id { get; set; }
  public string Name { get; set; }
  public ICollection ContactEmails { get; set; }
}
class ContactEmail {
  public int ContactId { get; set; }
  public Contact Contact { get; set; }
  public string Email { get; set; }
}

При использовании подхода Code First это навигационное свойство будет без проблем обработано на основе соглашений. При запросе контактов, если бы мы хотим сразу получить и ContactEmails, нам пришлось бы написать что-то вроде этого:

_context.Contact.Include(x => x.ContactEmails)
  .FirstOrDefault(x => x.Id == myContactId);

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

Но что, если мы уверены, что каждый раз, когда мы загружаем контакты, нам сразу нужны их email адреса? Мы уверены, что никогда не будем использовать контакты без email адресов. Часто это характерно для навигационных свойств один-к-одному. Но даже в этом примере, возможно, везде, где мы показываем контакт, нам также нужно показать и его email’ы, поскольку они являются неотъемлемой частью модели.

Настройка AutoInclude
До EF Core 5 у вас действительно не было выбора, кроме как постоянно использовать Include. Однако сейчас ситуация поменялась, появилась функция AutoInclude:

builder.Navigation(x => x.ContactEmails).AutoInclude();

Строитель навигации используется довольно редко, поэтому не все знают о его возможностях. И стоит упомянуть, что AutoInclude() нельзя использовать на конфигурациях вроде HasOne() или HasMany(), он должен быть настроен обособленно, как в примере выше.

Вот и всё. Теперь каждый раз при получении данных Contacts их свойство ContactEmails будет заполнено без использования Include.

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

_context.Contact.IgnoreAutoIncludes()
  .FirstOrDefault(x => x.Id == myContactId);

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

Источник: https://dotnetcoretutorials.com/2021/03/07/eager-load-navigation-properties-by-default-in-ef-core/

День семьсот семьдесят третий. #ЧтоНовенького
Прекращение Поддержки .NET Core 2.1
Поддержка .NET Core 2.1 будет прекращена 21 августа 2021 года. После этой даты Microsoft прекратит обновления (включая исправления безопасности) и поддержку этой версии. Необходимо обновить вашу версию .NET Core до поддерживаемой (.NET Core 3.1 или .NET 5.0) до этой даты.

Когда поддержка .NET Core 2.1 прекратится, приложения, использующие эту версию, продолжат работу. При этом обновления безопасности для .NET Core 2.1 начиная с сентября 2021 года выпускаться не будут, в отличие от .NET Core 3.1 и .NET 5.0. То есть .NET Core 2.1 может стать потенциально небезопасной средой.

Обновление приложений
Если ваше приложение использует NET Core 2.1, Microsoft настоятельно рекомендует перенести его на поддерживаемую версию - .NET 3.1 или более позднюю, которые можно скачать с веб-сайта .NET.

Обновление до .NET Core 3.1
Откройте файл проекта (файл *.csproj, *.vbproj или *.fsproj).
Измените значение целевой платформы с netcoreapp2.1 на netcoreapp3.1. Целевая платформа определяется элементом <TargetFramework> или <TargetFrameworks>.
Например, измените

<TargetFramework>netcoreapp2.1</TargetFramework>

На

<TargetFramework>netcoreapp3.1</TargetFramework>.

Проверить установленные на компьютере версии .NET можно, выполнив команду:

dotnet --list-runtimes

Если вы используете Visual Studio 2017 15.9, то у вас также может быть установлен .NET Core 2.1 в качестве обязательного компонента (см. рисунок ниже). Начиная с обновления 15.9.34 в марте 2021 года, компонент .NET Core 2.1 в Visual Studio будет изменен с обязательного на рекомендуемый. Когда поддержка .NET Core 2.1 прекратится, Visual Studio 2017 15.9 будет обновлена и .NET Core 2.1 станет необязательным. То есть различные рабочие нагрузки (Workload) в Visual Studio можно будет установить без установки .NET Core 2.1. При этом существующие установки не будут затронуты. Рабочие нагрузки и компоненты останутся установленными до тех пор, пока не будут явно удалены в установщике Visual Studio. Хотя у вас сохранится возможность установить компонент .NET Core 2.1, настоятельно рекомендуется использовать .NET Core 3.1 или .NET 5.0 с Visual Studio 2019 для создания приложений.

Источник: https://devblogs.microsoft.com/dotnet/net-core-2-1-will-reach-end-of-support-on-august-21-2021/

День семьсот семьдесят четвёртый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
80. Проверяйте Требуемое, а не Случайное Поведение
Распространённая проблема тестирования - предположение, что реализация делает именно то, на что вы хотите проверить. На первый взгляд, это скорее хорошо, чем плохо. Однако проблема становится очевидной, если перефразировать это предложение: распространённая ошибка при тестировании заключается в привязке тестов к особенностям реализации, когда эти особенности являются случайными и не имеют отношения к желаемой функциональности.

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

Например, для метода CompareTo(object obj) интерфейса IComparable, требования к результату заключаются в том, что:
- он отрицательный, если экземпляр класса стоит по порядку раньше, чем объект, переданный в аргументе метода,
- он положительный, если экземпляр класса стоит позже,
- он равен нулю если объекты считаются равными.
Этот стиль сравнения используется во многих API, включая компаратор для функций сортировки. И хотя конкретные значения –1 и +1 обычно используются в реализациях для обозначения отрицательного и положительного результатов, соответственно, программисты часто ошибочно предполагают, что эти значения и представляют фактическое требование, и, следовательно, пишут тесты, которые публично подтверждают это предположение.

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

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

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

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

День семьсот семьдесят пятый. #ЧтоНовенького
Новое Динамическое Инструментальное Профилирование для .NET
С выпуском Visual Studio версии 16.9 инструменты профилирования в Visual Studio стали ещё лучше. Новый инструмент динамического инструментального профилирования показывает точное количество вызовов ваших функций и работает быстрее, чем его предшественники. Он также поддерживает инструментарий .NET Core без использования файлов PDB.

Вы можете получить доступ к инструменту динамического профилирования, запустив профилировщик производительности для проекта .NET в Visual Studio (Debug > Performance Profiler или Alt+F2). В открывшейся вкладке отметьте флажок рядом с блоком Instrumentation. См. видео.

В профилировании существует два метода сбора данных: instrumentation (инструментальный) и sampling (метод выборки). В инструментальном профилировании каждый вызов функции в вашем приложении аннотируется, поэтому при вызове метод добавляется в трассировку вместе с информацией о вызывающем коде. При методе выборки текущий стек выполнения извлекается из ЦП в определённые интервалы времени, а затем каждый такой «кадр» добавляется к трассировке.

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

Новый сценарий динамического инструментального профилирования даёт ещё несколько преимуществ.

Во-первых, заметное улучшение скорости работы инструмента профилирования из-за отказа от использования VSInstr.

Во-вторых, теперь поддерживаются проекты .NET Core без PDB. Раньше, чтобы использовать инструментарий профилирования, сборку приходилось модифицировать для создания полноценных PDB файлов. Теперь вы можете запускать свои проекты «как есть», не выполняя никаких дополнительных действий.
Справка: PDB – это файлы базы данных программы, также называются файлами символов, которые используются для сопоставления идентификаторов и инструкций в исходном коде вашего проекта с соответствующими идентификаторами и инструкциями в скомпилированных приложениях. С помощью этих файлов отладчик связывается с исходным кодом, что позволяет выполнять его отладку.

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

Источник: https://devblogs.microsoft.com/visualstudio/new-dynamic-instrumentation-profiling/

День семьсот семьдесят шестой.
Будни программиста
Сегодня будет не совсем про программирование. Сегодня история личной боли (или тупости, вам решать). Я уже писал в нашем чате пару дней назад, что винда предложила под угрозой прекращения поддержки обновиться до версии 20H2. Что в этой версии такого революционного, я так и не понял. Но в выходные потратил 3,5 часа на обновление домашнего ноута. Наивный я думал, что вечером в понедельник быстренько обновлю новенький рабочий ноут, а потом подготовлю статью для канала.

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

Гораздо больше радости доставил отвалившийся Microsoft Loopback Adapter, к которому были подключены 2 виртуальные машины VirtualBox (машина для разработки и машина чисто с оракловской базой). Они через этот адаптер ноута по VirtualBox Bridged Adapter были связаны друг с другом.
- Не беда, - подумал я, - сейчас переустановлю Loopback адаптер, и всё ок.
- А вот хрен там, - ответила винда.

Для начала сам Loopback адаптер стал показывать «Undefined network». Я в принципе редко в него лазил, и не представлял, что он должен в нормальном состоянии показывать. Всё-таки, он тестовый, может неопределённая сеть для него – это нормально. Однако машины наотрез отказывались соединяться хоть с чем-нибудь, поэтому пришлось гуглить. Нашёл вот такое решение. Оооо… ручная правка реестра, как я по ней скучал!

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

После трёх часов тыкания в разные настройки машин, хоста и VirtualBox, ближе к 10 вечера, решил написать начальнику (благо, у него в штатах день только начинался). У него ровно те же виртуалки и почти такой же рабочий ноут. Скопировали все его настройки до запятой – нифига. Стали пробовать пинговать по IPv6 – нифига. Тут, кстати, стоит оговориться, что ораклу для подключения нужна сеть 10.x.x.x, поэтому все адаптеры были настроены на статические IPv4 и отдельную подсеть только для этих двух виртуалок. У виртуалки для разработки есть отдельное подключение для интернета, оракловой виртуалке интернет не нужен, поэтому у неё только одно подключение по мосту к другой виртуалке.

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

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

Вот теперь вопрос, ибо мне самому интересно. Это я настолько туп (хотя, повторюсь, не сисадмин совсем)? Может вы сразу поняли, в чём было дело?

Напомню вкратце:
Рабочий ноут, в нём 2 виртуалки VirtualBox, соединённые по Bridged Adapter между собой, используя Microsoft Loopback Adapter ноута. До обновления винды на ноуте всё работало, потом перестало. Соединения в виртуалках настроены на статические IP в сети 10.x.x.x. Одна виртуалка с базой данных видит вторую, но не видит ноут. Вторая видит ноут, но не видит виртуалку с базой (а именно это соединение и требуется).

UPD: Видимо, всё же я тупой, т.к. в комментариях уже через 15 минут предложили правильный вариант. Да, чудил файрвол в оракловой виртуалке. Каким-то макаром после всех манипуляций с Loopback адаптером на ноуте, сеть в оракловой виртуалке из приватной стала публичной. А для публичных сетей файрвол блокировал все попытки внешних подключений. Вот, кстати, вдруг кому пригодится, как изменить тип сети обратно на приватную.

День семьсот семьдесят седьмой. #юмор
Да, очень похоже на правду.
А ещё вдогонку вам на сегодня свежее видео от ExtremeCode на смежную тему)))

День семьсот семьдесят восьмой. #DeveloperPath
Новости проекта «Путь Разработчика»
О проекте

Наивно полагал, что новости проекта буду писать каждую неделю. Но немножко задержался (почти на 4 месяца). Однако за это время проект не только не умер, но и вполне себе развивался.

1. UI проект заменён на Blazor. Никаких больше node модулей! Всё собирается и запускается гораздо быстрее.
2. Основная часть API допилена и работает (можно потестить через Swagger UI).
3. Сергей Трофимов @trofimov_serhii разрабатывает Identity в отдельном проекте.
4. Проект «выложен» на Azure, и сайт даже можно открыть здесь https://developerpath.azurewebsites.net Правда, ничего полезного вы там всё равно не увидите)))

С выкладыванием возникла проблема. Поскольку опыта в развёртывании у меня примерно никакого, я пошёл самым простым путём. В Deployment Center можно было просто привязать репозиторий GitHub, и Azure через GitHub Actions как-то автоматом мог сайт развернуть. Оказалось, что не всё так просто. Решение вроде как даже скомпилировалось в dll-ки и выложилось. Но по ссылке показывается только стандартная страница. В общем, срочно нужен девопс помочь правильно «развернуться».

Однако задачи найдутся для самых разных специалистов. Если кто-то хочет поковыряться в .NET 5, C#9, Blazor, паттерне CQRS, или даже веб-дизайне, милости просим.

Проект всё также на Azure DevOps:
https://dev.azure.com/sbenzenko/DeveloperPath/
Он открытый, поэтому посмотреть, почитать можно и без регистрации. Авторизованные через аккаунт Microsoft или GitHub могут оставлять комментарии или добавиться в команду. Если вы ещё не в команде, пишите в личку или в комментарии свой e-mail, я вас приглашу.

Я добавил «парочку» тасок, которые можно посмотреть здесь. Все они делятся на:
- Epic (с короной) - глобальные задачи.
- Task (с жёлтой галочкой) – простые задачи на разработку.
- Issue (с зелёной планшеткой) – по задумке должны быть чем-то средним между Epic и Task. Пока особо не используются, считайте их теми же, что Task.

Задачи Epic представляют глобальные направления в разработке проекта: Архитектура, API, UI, Развёртывание, Документация, Тесты и т.п. Они «содержат» в себе задачи Task и Issue. Поэтому, кому интересно поучаствовать, можете присмотреть задачу по душе из тех, что в статусе «To Do» и взять её на себя.

Задачи помечены тегами по направлениям:
- Architecture – разработка проектов и модулей,
- Development – разработка отдельных фич,
- Design – разработка пользовательского интерфейса,
- Deployment – всё, что связано с развёртыванием,
- Bug – исправление ошибок или недоделок,
- Testing – все вопросы тестирования,
- Documentation – создание документации (как описание проекта, так и заметки по особенностям установки или работы).

Помимо этого, вы, конечно, можете просто взять код проекта на GitHub и предложить что-то своё.

По всем вопросам добро пожаловать в комментaрии сюда, либо в проект на Azure DevOps.

День семьсот семьдесят девятый. #ЗаметкиНаПолях #SQL
Выражение WITH и Сложные Запросы
В разработке ПО обычной практикой является инкапсуляция инструкций в небольшие и легко понятные единицы - функции или методы. В SQL мы оперируем не инструкциями, а запросами. Чтобы сделать запросы многоразовыми, в SQL-92 были введены представления (view). После создания представление получает имя в схеме базы данных, чтобы другие запросы могли использовать его как таблицу. В SQL-99 добавлено предложение WITH для определения «представлений в области действия оператора». Они не хранятся в схеме базы данных, а живут только в рамках текущего запроса. Это позволяет улучшить структуру запроса, не загрязняя глобальное пространство имен. Предложение WITH также известно как общее табличное выражение (CTE).

Синтаксис

WITH query1 (column1, …) AS
  (SELECT … FROM table …)
SELECT * FROM query1;

WITH не является самостоятельной командой, за ним должен следовать SELECT. Запрос SELECT (и содержащиеся в нем подзапросы) могут ссылаться в своём блоке FROM на определённое в предложении WITH имя подзапроса.

Одно предложение WITH может определять несколько имён подзапросов, разделяя их запятыми. Каждый из этих подзапросов может ссылаться на ранее определённые имена подзапросов:

WITH 
  query1 AS (SELECT …), 
  query2 AS (SELECT … FROM query1 …)
SELECT …

ВАЖНО! Имена подзапросов, определённые в предложении WITH скрывают таблицы или представления с тем же именем.

СУБД
Базовая функциональность предложения WITH доступна во всех современных СУБД.

Производительность
- Большинство баз данных обрабатывают WITH-запросы так же, как и представления: они заменяют ссылку на запрос его определением и оптимизируют общий запрос.
*PostgreSQL до версии 12 оптимизировала каждый подзапрос и главный запрос независимо друг от друга.
- Если WITH-запрос упоминается несколько раз, некоторые базы данных кешируют его результат, чтобы предотвратить двойное выполнение.

Полезные расширения
1. WITH как префикс DML запроса (PostgreSQL, SQL Server, SQLite)
Некоторые СУБД позволяют использовать WITH не только с запросами SELECT, но и с запросами на манипуляцию с данными (INSERT, UPDATE, DELETE).

2. WITH как цель DML (SQL Server)
SQL Server также позволяет использовать WITH-запрос как цель DML запроса, то есть создавать обновляемые представления.

3. Функции в WITH (Oracle)
Oracle, начиная с версии 12cR1 позволяет определять функции и процедуры в предложении WITH.

4. DML в WITH (PostgreSQL)
Начиная с версии 9.1 PostgreSQL поддерживает использование DML запросов внутри предложения WITH. А при использовании выражения RETURNING, предложение WITH возвращает данные в основной запрос. Таким образом, например, можно сделать запрос к только что вставленным в таблицу записям:

WITH added AS (
  INSERT INTO table1 …
  RETURNING *
)
SELECT * FROM added;

Источник: https://modern-sql.com/feature/with

День семьсот восьмидесятый. #Оффтоп #ЗадачиНаСобеседовании
Доброй субботы, дорогие друзья. Новая задачка вам на выходной день. На этот раз никаких Big O, никаких сложных алгоритмов и оптимизаций. Просто на смекалку.

Задача максимально короткая:
С помощью генератора случайных чисел, выдающего значения от 0 до 1, вычислите число пи.

Внезапно?)))

Попытайтесь решить самостоятельно, а ответ и разбор в этом видео.

День семьсот восемьдесят первый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
81. Тестируйте Точно и Конкретно
Важно проверять желаемое, существенное поведение кода, а не случайное поведение конкретной реализации. Но, помимо этого, тесты должны быть точными и конкретными.

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

Когда программистов спрашивают: «Что бы вы тут протестировали?», - наиболее частым ответом является что-то вроде: «Что в результате сортировки получается отсортированная последовательность элементов». Хотя это правда, это не вся правда. Если спросить, что ещё, то многие программисты добавят, что результирующая последовательность должна быть той же длины, что и исходная. И это тоже правильно, но всё равно недостаточно. Например, если взять последовательность:

3 1 4 1 5 9

То ответ ниже удовлетворяет обоим условиям (результат отсортирован и той же длины):

3 3 3 3 3 3

Хотя это соответствует спецификации, это определенно не то, что имелось в виду! Более того, этот пример основан на ошибке, взятой из реального производственного кода (к счастью, обнаруженной до того, как он был выпущен). Простое неверное нажатие клавиши или кратковременная невнимательность привели к тому, что результат заполнился первым элементом.

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

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

Как заметил Тони Хоар: «Есть два варианта проектирования ПО: сделать его настолько простым, чтобы в нём очевидно не было недостатков, либо сделать его настолько сложным, чтобы в нём не было очевидных недостатков.»

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

3 1 4 1 5 9

Результат сортировки будет:

1 1 3 4 5 9

Никакой другой ответ не годится!

Конкретные примеры помогают проиллюстрировать общее поведение доступным и однозначным образом. Результатом добавления элемента в пустую коллекцию является не просто то, что она не пуста: теперь в коллекции есть единственный элемент, и этот элемент является добавленным элементом. Два или более элементов будут удовлетворять условию непустой коллекции, но этот тест будет неверен. Один элемент с другим значением – тоже. Результатом добавления строки в таблицу заключается не просто то, что в таблице становится на одну строку больше. Нужно также проверить, что первичный ключ этой строки совпадает с первичным ключом строки, которую мы добавили. И так далее.

При определении поведения тесты должны быть не просто правильными: они также должны быть точными.

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

День семьсот восемьдесят второй.
Инструменты и для Создания .NET HTTP API. Начало
В этой серии постов опишу набор инструментов для создания полноценных приложений HTTP API в .NET.
Начнём с наиболее распространённых NuGet пакетов.

OpenAPI
Хорошо спроектированный API должен быть «обнаруживаемым». То есть службы, представленные в API должны быть легко доступны. Возможно, правильнее будет назвать такие API хорошо описанными. Описывая API с использованием спецификации OpenAPI (ранее называвшейся Swagger), разработчики открывают для себя различные возможности генерации кода и интеграции. Для создания и поддержки автоматически сгенерированной спецификации API на основе кода у вас есть два основных варианта: NSwag и Swashbuckle. Оба этих проекта почти полностью поддерживаются отдельными людьми с небольшими группами контрибуторов, и оба оказали значительное влияние на экосистему .NET HTTP API.

NSwag
Наиболее популярным сценарием использования NSwag является создание спецификации OpenAPI из проектов WebAPI-контроллеров с помощью пакета NSwag.AspNetCore. Однако NSwag предлагает целый ряд других функций:
- Генерация кода строго типизированных клиентов HTTP API на C#, кода WebAPI-контроллеров из OpenAPI и кода клиентов на TypeScript.
- Создание спецификации OpenAPI из существующих сборок .NET (из двоичных файлов, а не исходного кода).
- Настольное приложение NSwagStudio, которое позволяет использовать большинство функций NSwag без написания кода.

Swashbuckle
Swashbuckle использовался миллионами проектов веб-API и также используется в шаблонах .NET с выпуска .NET 5 RC. Он включен по умолчанию, но может быть выключен в диалоговом окне нового проекта в Visual Studio (или с помощью параметра --no-openapi в команде dotnet new webapi).
Swashbuckle также имеет инструмент командной строки Swashbuckle.CLI, который можно использовать для генерации спецификаций OpenAPI во время публикации в MSBuild или dotnet publish.

Microsoft.OpenAPI
Microsoft.OpenAPI включён в большинство проектов, поддерживающих OpenAPI, в сообществе .NET и Azure и отвечает за различные функции:
- Переход между версиями Swagger и OpenAPI, YAML или JSON.
- Предоставление единой общей объектной модели в .NET для описаний OpenAPI.
- Чтение и запись описаний OpenAPI.
Если вы создаёте приложение или пакет NuGet для разработчиков .NET HTTP API с помощью OpenAPI, попробуйте использовать пакет Microsoft.OpenAPI. Это значительно облегчит задачу синтаксического анализа или написания документов и описаний OpenAPI.

API Versioning
При работе с WebAPI рано или поздно вам придётся столкнуться с необходимостью внесения критических (breaking) изменений. Тогда на помощь придёт пакет API Versioning. Он позволяет декорировать API контроллеры атрибутами, указывающими, в каких версиях API какие контроллеры или методы должны появляться.
Пример совместного использования API Versioning и Swashbuckle.

Refit
Refit позволяет легко создавать REST клиентов для существующих API. Он предоставляет упрощённый способ создания HTTP клиентов, абстрагируясь от всех нюансов семантики HttpClient.

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

Источник: https://devblogs.microsoft.com/aspnet/open-source-http-api-packages-and-tools/

День семьсот восемьдесят третий.
Инструменты и для Создания .NET HTTP API. Продолжение
Начало

Инструменты разработки и тестирования HTTP API.

HttpRepl
HttpRepl это глобальный инструмент .NET CLI, который предоставляет способ просмотра API, описанного спецификацией OpenAPI, в виде каталога. После установки вы можете использовать команду httprepl -o <openapi-url>, чтобы подключиться к любому проекту веб-API, описанному по OpenAPI, и изучить его, используя знакомые команды, такие как ls или dir, и перемещаться по структуре API так же, как по дереву каталогов.

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

REST Client для Visual Studio Code
Есть несколько впечатляющих инструментов, которые поставляются как расширения для Visual Studio Code. Один из них, REST Client, предлагает тестирование запросов HTTP API внутри IDE. Создав файл .http, содержащий ваши тестовые запросы, вы можете запустить REST Client и отправлять эти запросы по отдельности, просматривая результаты в новом окне.

Postman
Конечно, нельзя не упомянуть один из самых популярных инструментов тестирования HTTP-запросов в целом и REST API в частности – Postman. Это отдельное приложение с богатым набором функций осуществления и автоматического тестирования HTTP-запросов (например, можно проверять код ответа или наличие в результате нужных данных). Также возможно сохранять запросы в коллекции или плейлисты тестирования.

Network Console
В Edge DevTools недавно включили экспериментальную функцию под названием Network Console. Она предлагает пользователям Edge функции тестирования HTTP API в браузере. Чтобы попробовать её, сначала нужно включить Network Console в экспериментальных функциях Edge DevTools (DevTools Settings > Experiments > Enable Network Console).

После этого на вкладке Network вы сможете щелкнуть правой кнопкой мыши на любом ранее сделанном HTTP-запросе и выбрать пункт меню «Изменить и повторно отправить» (Edit and Resend). Откроется инструмент тестирования HTTP запросов прямо в браузере.

Редактор OpenAPI
Редактирование или создание документов OpenAPI вручную может быть сложной задачей. Расширение для VS Code OpenAPI Editor поможет в этом. Оно включает такие функции, как:
- Предпросмотр для SwaggerUI и ReDoc
- IntelliSense для редактирования содержимого JSON/YAML в спецификации OpenAPI,
- Навигацию в виде раскрывающегося списка. Её можно использовать, чтобы найти отдельную операцию в спецификации, вместо того чтобы пролистывать огромный файл JSON.

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

Источник: https://devblogs.microsoft.com/aspnet/open-source-http-api-packages-and-tools/

День семьсот восемьдесят четвёртый.
Инструменты и для Создания .NET HTTP API. Окончание
Начало
Продолжение

Фреймворки на основе ASP.NET Core
В таком активном сообществе многие проекты с открытым кодом расширяют платформу ASP.NET и даже находят новые интересные направления развития веб-API. Два следующих проекта - отличные примеры того, как сообщество развивает новые направления ASP.NET и веб-API.

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

[HttpPost("/authors")]
[SwaggerOperation(
  Summary = "New Author",
  Description = "Creates a new Author",
  OperationId = "Author.Create",
  Tags = new[] { "AuthorEndpoint" })
]
public override async 
   Task<ActionResult<CreateResult>>
   HandleAsync([FromBody] CreateCommand req)
{
  var author = new Author();
  _mapper.Map(req, author);
  await _repository.AddAsync(author);

  var result = 
    _mapper.Map<CreateResult>(author);
  return Ok(req);
}

Поскольку API Endpoints – это абстракция над веб-API, вы можете использовать Swashbuckle, NSwag или любое другое расширение веб-API вместе с конечными точками API и пользоваться всеми преимуществами стека веб-API, но с более модульным подходом, чем на основе MVC.

Проект Carter
Проект Carter привносит ещё большую модульность в ваши приложения ASP.NET Core. Он предлагает ориентированный на конечные точки подход к созданию HTTP API с помощью ASP.NET Core. Синтаксис Carter отлично подходит для разработчиков, которые ценят подход к маршрутизации конечных точек, и предлагает набор чистых интерфейсов для быстрого начала работы.

public class HomeModule : CarterModule {
  public HomeModule() {
    Get("/", async (req, res) => 
      await res.WriteAsync("Hello Carter!"));
  }
}

Благодаря многочисленным примерам и документации проект легко изучить и поэкспериментировать, а также он предлагает интересный подход к созданию HTTP-приложений. OpenAPI встроен в Carter по умолчанию, поэтому создаваемые вами конечные точки могут автоматически отображаться в спецификации OpenAPI. Проект Carter также может быть объединён с традиционным веб-API и структурой приложения ASP.NET Core, поэтому вы можете использовать его вместе со знакомым промежуточным ПО и службами ASP.NET Core.

Источник: https://devblogs.microsoft.com/aspnet/open-source-http-api-packages-and-tools/