День семьсот девяносто девятый. #ЗадачиНаСобеседовании
Сегодня предложу вам к просмотру ещё один минисериал от Nick Chapsas на тему заданий на собеседовании. На этот раз Ник разбирает задачу интеграции API сервиса.

Смысл задачи в том, что вам дан REST API (в данном случае API сети ресторанов), вам нужно создать клиента этого API, отвечающего определённым требованиям.

Все подробности задачи Ник объясняет в видео, поэтому не буду их пересказывать.

В первой части https://youtu.be/_Pjjk4fOh8s довольно подробно описывается создание консольного клиента API. Что хотелось бы отметить из решения – это пакеты, которые Ник использует (помимо стандартных):
1. RefitClient – пакет, который создаёт код клиента API на основе интерфейса.
2. CommandLineParser – о нём я уже писал.
3. OneOf – пакет для объединения различных типов в один тип OneOf<T0,T1,…Tn>. Ник использует его для возврата из метода обобщённого объекта с результатом либо ошибкой. Вызывающий код может использовать методы Match() или Switch(), чтобы выполнять действия в зависимости от типа ответа. Не могу сказать, что мне нравится такой подход, но упоминания он заслуживает.
4. Microsoft.Extensions.Http.Polly – Polly на канале уже тоже упоминался, и не раз. Это, насколько я понимаю, версия от Mirosoft, доступная в .NET 5.

Вторая часть https://youtu.be/NPAK94ZCxD4 посвящена тестированию. И помимо обычных модульных тестов Ник описывает приёмочное (acceptance) тестирование: близкое к человеческому языку описание теста, которое парсится в коде и проверяется автоматически. «Ничего не понятно, но очень интересно»))) Кстати, подробно о приёмочном тестировании есть и третье видео https://youtu.be/qWEDkHGNhvk

День восьмисотый.
Как Измерить Время Исполнения Программ в PowerShell
Командная строка используется всё чаще для запуска сценариев, сборки и других задач, вроде docker и docker-compose. Когда вы запускаете команду, например, dotnet build или dotnet test, она обычно сообщает вам о том, сколько времени потребовалось для выполнения. Но когда у вас есть сценарий, состоящий из нескольких шагов, часто хочется проверить, сколько времени он выполняется. Чтобы оптимизировать его или сравнить время на разных машинах.

Вы можете это сделать с помощью команды Measure-Command:

Measure-Command { ./SomeScript.ps1 }

Она запустит скрипт и предоставит отчет о том, сколько времени он занял. Также можно запускать произвольные команды CLI:

Measure-Command { dotnet build }

Но по умолчанию вы не получаете никакого вывода от выполняемой команды. Чтобы видеть его, нужно добавить параметр вывода (см. картинку):

Measure-Command { dotnet build | Out-Default }

Источник: https://ardalis.com/measure-command-line-script-time-elapsed/

День восемьсот первый.
Как Улучшить Свои Навыки Отладки. Начало
Независимо от того новичок вы или опытный разработчик, время от времени в вашем коде появляются ошибки. Все мы иногда делаем ошибки. В конце концов, невозможно перестать быть человеком. Есть три основных способа борьбы с ошибками:
1. Пред-отладка: снижение вероятности возникновения ошибок.
2. Отладка: выявление, исправление и удаление ошибок после их обнаружения.
3. Пост-отладка: анализ исправленных ошибок и отслеживание непредвиденных ошибок.

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

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

3. Учитесь печатать без ошибок
Да, многие редакторы и компиляторы укажут вам на опечатку, но случаи бывают разные. Да и исправление опечаток – просто ненужная трата времени.
‌
4. Подтяните английский
Знание английского сильно поможет, как в работе с инструментами и понимании сообщений об ошибках, так и в поиске ответа в сети. В англоязычном сегменте интернета информации гораздо больше, и она намного актуальнее.

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

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

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

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

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

Источник: https://www.freecodecamp.org/news/how-to-improve-your-debugging-skills/

День восемьсот второй.
Как Улучшить Свои Навыки Отладки. Окончание
Начало

Что такое отладка?
Отладка лежит в основе программирования, и при кодировании она занимает большую часть вашего времени. Отладка включает три основных этапа:
1. Поиск ошибки
Поиск ошибок начинается с понимания сообщений об ошибках, которые вы видите. Сообщение об ошибке - это указатель на ошибку. Если вы его понимаете, вы можете точно определить местонахождение ошибки.

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

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

3. Исправление ошибки
После обнаружения и понимания причины ошибки мы должны исправить её. Иногда, если вы понимаете, в чём ошибка, вы быстро найдёте решение. Однако бывают случаи, когда даже понимание не даёт решения, как бы мы ни старались. Не тратьте слишком много времени на раздумья, поищите подходящее решение в интернете по коду или сообщению об ошибке или другому подходящему запросу. Также можно спросить коллегу, или задать вопрос на форуме, на StackOverflow, в чате, где-угодно (но только после того, как вы самостоятельно обдумали проблему!). Люди склонны видеть вещи по-разному, взгляд на проблему со стороны может помочь. Иногда даже само объяснение проблемы другому человеку помогает найти решение.

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

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

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

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

Источник: https://www.freecodecamp.org/news/how-to-improve-your-debugging-skills/

День восемьсот третий. #ВопросыНаСобеседовании
Попробую новый вид постов на тему вопросов на собеседовании. Подписчик прислал набор вопросов, которые ему недавно задали на собеседовании и попросил оценить. Попробую сам ответить и прокомментировать, а также жду комментариев от вас. Как по поводу ответов, так и по поводу, как вам вопросы и как вообще такой формат.

Поехали!

Дисклеймер: вопросы буду приводить в том виде, как они мне были присланы. Я постараюсь не гуглить правильные ответы, а приведу свои мысли. Поэтому мои ответы не обязательно будут правильными. Если что, поправляйте в комментариях.

Внутренности .NET
1) Есть класс Object. У него определенны Equals и GetHashCode. Если вы переопределите Equals, но не переопределите GetHashCode для какого-нибудь класса, компилятор выдаст вам Warning. Почему?
Методы Equals и GetHashCode связаны в том смысле, что GetHashCode должен выдавать одинаковый результат у объектов, для которых Equals выдаёт true. Поэтому переопределение Equals скорее всего потребует и переопределения GetHashCode.
Подробнее об Equals
Подробнее о GetHashCode

2) В классе Dictionary, когда происходит поиск по ключу. Какая сложность? А в List при вызове FirstOrDefault()?
В Dictionary поиск по ключу происходит со сложностью O(1) из-за хеширования ключей. В List – первый элемент выберется за O(1), но если до этого будет поиск по индексу, то O(n).
Подробнее

3) Есть конструкция async/await. Как она работает? Когда добавляю async и await, что там меняется относительно того, если бы я не добавлял.
Создаётся конечный автомат для сохранения состояния. Все инструкции после строки с await добавляются в функцию продолжения, которая вызывается после завершения ожидания инструкции, следующей за await.
Подробнее

4) У меня была операция File.ReadAll(), я заменил ее на File.ReadAllAsync() какая из этих операций будет быстрее?
Странный вопрос, на мой взгляд, о сферическом быстродействии в вакууме. Тут столько неизвестных, что определённо ответить на этот вопрос просто невозможно. Скорее всего разницы в быстродействии не будет заметно, т.к. время на чтение файла будет на порядок превышать затраты на асинхронность.

5) Если синхронные методы работают быстрее чем асинхронные, зачем нам нужная асинхронная модель?
Опять какое-то теоретизирование о быстродействии синхронных и асинхронных методов. Быстродействие надо измерять в каждом конкретном случае. А вообще асинхронные методы используются для исключения блокировки UI потока, а также для операций, не использующих процессор, вроде чтения/записи файлов, обращения к БД или сетевых вызовов.

6) Есть I/O Bound потоки и CPU Bound потоки. Какая разница между ними?
Эти потоки различаются по типу нагрузки на ресурсы компьютера. I/O Bound поток больше нагружает диск (чтение/запись файлов), CPU Bound поток больше нагружает процессор (вычислительные операции).

7) File.ReadAllAsync() какого типа поток?
Совсем не понял вопроса. Начнём с того, что нет метода ReadAllAsync(), есть ReadAllBytesAsync(), возвращающий Task<byte[]>, и ReadAllTextAsync(), возвращающий Task<string>.

8) Task.Run(t => File.ReadAll()) и File.ReadAllAsync() это эквивалентные вызовы? Объясните.
Отвлечёмся от того, что снова указаны несуществующие методы. Здесь, если выполнить так, как написано, то, насколько я понимаю, Task.Run не возвратит результата.

9) Есть строковая переменная, в ней написано название типа, я хочу создать объект этого типа. Как мне это сделать? Корректировка: Тип ты не знаешь в Compile Time.
Использовать Activator.CreateInstance(). Подробности на память не помню, надо гуглить.

Как вам вопросы? Что скажете о моих ответах? Стоит ли продолжать выпускать такие посты?

День восемьсот четвёртый. #ЗаметкиНаПолях
Что такое Debugger.Launch?
Допустим, вы запускаете приложение (например, веб-приложение или службу Windows), в котором есть startup метод, который вы хотите отладить. Часто это может быть настройка внедрения зависимостей, раннее чтение файла конфигурации или что-то подобное. Допустим, вы не можете просто нажать F5 в Visual Studio и начать отладку. Вам нужно запустить приложение, а потом подключить отладчик. Для веб-приложений это иногда связано с тем, что вы используете IIS и переходите по URL-адресу своего приложения. А службу Windows, вы хотите отладить, когда она на самом деле исполняется как служба Windows.

Можно добавить в нужное место кода Thread.Sleep(10000); и попытаться подключить отладчик, в течение этого времени. Но гораздо проще это сделать с помощью:
System.Diagnostics.Debugger.Launch();

Тогда, если вы запустите приложение (не через отладку из Visual Studio), то, когда исполнение дойдёт до этой строчки, появится диалоговое окно, где вам будет предложено выбрать отладчик для этого приложения. Можно выбрать Visual Studio, и приложение откроется в режиме отладки.

А что насчёт Debugger.Break()?
Этот метод также использовался для начала отладки. Но, как говорится в документации Microsoft, начиная с .NET Framework 4, если не выбран отладчик, то не гарантируется, что метод Break приведёт к вызову окна выбора отладчика. Вместо этого в систему отчётов об ошибках Windows (WER) направляется сообщение об ошибке. Таким образом, документация советует для старта отладчика использовать Debugger.Launch.

Если же отладчик уже подключен, Debugger.Break заставляет код останавливать выполнение так же, как и точка останова. Так что в некотором смысле это похоже на точку останова, которую могут использовать разработчики на разных машинах вместо ручной инструкции: «Поместите точку останова в строку XX файла YYY…». Это может показаться не очень полезным, кроме случая, который мы рассмотрим далее.

Когда Debugger.Launch не работает
В очень редких случаях Debugger.Launch не предлагает пользователю отладить код. Либо требуется отладка в приложении, не представленном во всплывающем окне. Тогда есть простое решение:

// Ждём подключения отладчика.
while(!System.Diagnostics.Debugger.IsAttached)
{
  Thread.Sleep(100); //либо Task.Delay()
}
System.Diagnostics.Debugger.Break();

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

#if DEBUG
…
#endif

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

Источник: https://dotnetcoretutorials.com/2021/04/03/i-wish-i-knew-about-debugger-launch-earlier/

День восемьсот пятый.
Microsoft Azure Virtual Training Day: DevOps with GitHub
Рекомендую посетить очередной бесплатный вебинар из серии Microsoft Azure Virtual Training Day. На нём расскажут, как использовать GitHub для управления рабочими процессами и сокращения цикла разработки. Пошаговые инструкции по добавлению элементов управления качеством и безопасностью в процесс сборки, а также по улучшению уведомлений и ответов для обеспечения согласованной и повторяемой автоматизации.

Темы мероприятия:
- Использование GitHub для улучшения совместной работы и производительности команды.
- Интеграция средств контроля безопасности и качества в конвейеры автоматизации, непрерывной интеграции и непрерывной доставки (CI/CD) и среды выполнения.
- Внедрение передовых методов, чтобы помочь удаленным командам разработчиков повысить отказоустойчивость программного обеспечения.

Вебинар пройдёт в 2 дня:
Среда, 21 апреля 2021, 11:00-13:55 Мск.
Четверг, 22 апреля 2021, 11:00-13:10 Мск.
Язык: Английский, доступны русские субтитры.

Регистрация по ссылке: https://mktoevents.com/microsoft+event/247969/157-gqe-382

Большая техническая конференция о .NET-разработке начинается уже на следующей неделе.

DotNext 2021 — 20-23 апреля, онлайн.

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

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

✅ Посмотреть всю программу и купить билет со скидкой можно на https://bit.ly/3dYUGJk

Промокод на Personal-Standard билет: netdevdiary2021JRGpc
Промокод на Full Pass билет: JugRuCommunityBonus – это если решите посмотреть все конференции сезона 😉

День восемьсот седьмой.
FluentValidation
Сегодня предлагаю вам посмотреть полезное видео - запись вебинара «OSS Power-Ups: FluentValidation». Это первый вебинар из серии Open-Source Power-Ups про популярные проекты с открытым исходным кодом в сообществе .NET.

FluentValidation - это библиотека для создания строго типизированных правил валидации, пользующаяся огромной популярностью и имеющая более 50 миллионов загрузок на NuGet. Джереми Скиннер, поддерживающий проект, поможет нам начать работу с некоторыми базовыми примерами, написанием пользовательских валидаторов, локализацией сообщений об ошибках и интеграцией валидации в ASP.NET Core.

День восемьсот восьмой. #ЗаметкиНаПолях
Как Посмотреть Параметры Конфигурации в ASP.NET
Существует простой способ раскрыть конфигурацию приложения как конечную точку в вашем приложении ASP.NET Core.

GetDebugView() - это метод расширения IConfigurationRoot, который возвращает строку, описывающую конфигурацию приложения. В этой строке отображаются все ключи конфигурации в вашем приложении, связанное значение и источник значения.

Рассмотрим пример «стандартного» вывода метода GetDebugView():

AllowedHosts=* (JsonConfigurationProvider for 'appsettings.json' (Optional))
applicationName=temp (Microsoft.Extensions.Configuration.ChainedConfigurationProvider)
ASPNETCORE_ENVIRONMENT=Development (EnvironmentVariablesConfigurationProvider)
ASPNETCORE_URLS=https://localhost:5001;https://localhost:5000 (EnvironmentVariablesConfigurationProvider)
Logging:
  LogLevel:
    Default=Information (JsonConfigurationProvider for 'appsettings.json' (Optional))
MySecretValue=TOPSECRET (JsonConfigurationProvider for 'secrets.json' (Optional))
…

Некоторые особенности вывода:
1. Параметры конфигурации выдаются в алфавитном порядке ключей.
2. Формат строки:

Ключ=значение (источник значения)

Например:
- Ключ AllowedHosts имеет значение * и предоставлен из файла appsettings.json провайдером JsonConfigurationProvider.
- Ключ MySecretValue имеет значение TOPSECRET и предоставлен из файла пользовательских секретов secrets.json.
3. Строка отформатирована по разделам, что видно по ключу Logging, содержащему раздел LogLevel, в котором находится ключ Default.
4. Прочие провайдеры конфигурации:
- ChainedConfigurationProvider – первоначальные значения конфигурации, задаются хостом,
- EnvironmentVariablesConfigurationProvider – переменные среды,
- CommandLineConfigurationProvider – параметры командной строки.

Заметьте, что значения одного провайдера могут переписывать значения другого (например, значения из appsettings.json заменяются значениями из секретных данных или переменных среды). В выводе GetDebugView() будет присутствовать только конечное значение.

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

Один из очевидных подходов - предоставить конечную точку в приложении ASP.NET Core, где вы можете запросить это представление. В следующем примере использован метод MapGet для предоставления простой конечной точки:

app.UseEndpoints(endpoints => {
  if(env.IsDevelopment()) {
    endpoints.MapGet("/debug-config", ctx => {
      var config = 
        (Configuration as IConfigurationRoot)
        .GetDebugView();
      return ctx.Response.WriteAsync(config);
    });
  }
});

Источник: https://andrewlock.net/debugging-configuration-values-in-aspnetcore/

День восемьсот девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
84. Мыслите Состояниями
У людей в реальном мире странные понятия состояний. Утром я зашёл в кофейню, чтобы подготовиться к очередному дню преобразования кофеина в код (купить латте). Но девушка ответила: "Извините, у нас вообще, совсем нет никакого молока, ни капли."

С точки зрения программиста это странное заявление. Когда дело доходит до наличия или отсутствия молока, это нельзя измерить. Молоко либо закончилось, либо нет. Возможно, она пыталась сказать мне, что у них не будет молока всю неделю, но результат был бы тот же – сегодня я пью эспрессо.

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

Рассмотрим простой интернет-магазин, который работает только по предоплате. Класс заказа, может содержать такой метод:

public bool IsComplete() => IsPaid() && HasShipped();

Вроде логично. Но, даже если это выражение аккуратно извлечено в метод, а не продублировано повсюду, такого выражения не должно существовать вообще. Тот факт, что оно существует, говорит о проблеме. Почему? Потому что заказ не может быть отправлен до оплаты. Таким образом, HasShipped() не может быть true, если IsPaid() не true, что делает эту часть выражения избыточной. Возможно, вам всё равно нужен метод IsComplete() для ясности кода, но тогда он должен выглядеть так:

public bool IsComplete() => HasShipped();

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

Эти состояния важны, т.к. нужно убедиться, что:
1. вы находитесь в ожидаемом состоянии, прежде чем выполнять операции,
2. вы можете перейти только в одно из доступных состояний.
То есть, вы должны тщательно защитить свои объекты в нужных местах.

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

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

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

День восемьсот десятый. #ЧтоНовенького
.NET 6: Новые Структуры Даты и Времени
Давняя проблема библиотеки базовых классов .NET заключается в невозможности раздельного представления значений даты и времени. Новые структуры .NET 6 DateOnly и TimeOnly призваны исправить это упущение.

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

Исходное имя структуры DateTime было просто Date. Это всё ещё справедливо для VB, где ключевое слово Date продолжает ссылаться на DateTime. Таким образом, название DateOnly было выбрано, чтобы избежать путаницы. Другая причина заключается в том, что DateTime.Date возвращает значение DateTime. Это уже нельзя изменить, но новички часто ожидают, что это свойство возвращает только дату. Поэтому новое свойство, возвращающее DateOnly, можно назвать DateTime.DateOnly.

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

Сериализация
DateOnly и TimeOnly не будут реализовывать атрибут Serializable. В .NET Core и более поздних версиях этот атрибут считается устаревшим, как и библиотеки сериализации, которые на него полагаются.

Был запрос на атрибут IXmlSerializable и его эквивалент в для JSON. Однако DateOnly и TimeOnly должны быть помещены в одну из библиотек нижнего уровня NET, где такие атрибуты недоступны. Таким образом, сериализаторам необходимо будет включить собственную обработку этих новых типов. Такое же изменение придётся сделать и в драйверах баз данных.

Это может привести к тому, что после выпуска .NET 6 в течение какого-то времени нельзя будет использовать DateOnly и TimeOnly в некоторых сценариях, пока сериализаторы не подстроятся.

DateTimeOnly

Пытаясь решить проблему часового пояса, .NET 2 представила свойство DateTime.Kind. Разработчики имели возможность аннотировать свои значения даты и времени с помощью флага, указывающего, представляет ли значение местный часовой пояс, всемирное координированное время или неуказанный часовой пояс. На самом деле это привело к тому, что разработчики были вынуждены указывать эту информацию или сталкиваться с неожиданными ошибками.

Что еще хуже, свойство Kind использовалось непоследовательно. Например, многие сериализаторы, видя его, добавляли смещение при экспорте значения. Это приводило к трудно диагностируемым ошибкам, поскольку только некоторые даты (например, полученные из DateTime.Now) сериализовывались со смещением. А операторы сравнения полностью игнорировали Kind. Предполагалось, что разработчик сам проверит свойство Kind и при необходимости выполнит преобразование часового пояса.

Чтобы устранить эти проблемы, есть запрос на новую структуру DateTimeOnly, которая в основном работает так же, как DateTime в .NET 1 (т.е. дата и время без указания часового пояса).

Источник: https://www.infoq.com/news/2021/04/Net6-Date-Time/

День восемьсот одиннадцатый.
5 Советов по Снижению Затрат в Azure
Давненько я не рекомендовал видео от Тима Кори. Вот вчера он выпустил довольно интересный ролик «5 Cost-Saving Tips for Azure»

Как разместить полноценный сайт на Azure всего за 1 цент в месяц? Как снизить стоимость MSSQL с тысяч долларов в месяц до нескольких десятков долларов? Как найти и убрать ненужные сервисы или установить лимит месячного бюджета? В видео нет особых откровений. В принципе, большинство материала упоминается в курсе Microsoft Learn по Azure, но есть и некоторые нюансы, который могут быть полезны.

День восемьсот двенадцатый. #ЧтоНовенького
Visual Studio 2022
Этим летом выйдет первая предварительная версия Visual Studio 2022. Её обещают сделать более быстрой, доступной, легкой и впервые в истории 64-разрядной. Пользовательский интерфейс будет более чистым, интеллектуальным и ориентированным на продуктивность.

64-битная VS 2022 больше не будет ограничена 4ГБ памяти для основного процесса devenv.exe. Теперь вы сможете открывать, редактировать, запускать и отлаживать даже самые большие и сложные решения, не исчерпывая памяти. Хотя Visual Studio переходит на 64-разрядную версию, это не меняет типа или разрядности приложений, которые вы создаёте с её помощью.

Разработка современных приложений
Azure
VS 2022 позволит быстро и легко создавать современные облачные приложения в Azure. Для начала работы вы сможете использовать большое количество репозиториев, описывающих общие шаблоны, используемые в современных приложениях. Эти репозитории состоят из проверенного кода, показывающего эти шаблоны в действии, ресурсов Azure, а также предварительно настроенных рабочих процессов и действий GitHub, подготавливающих для вас полноценное решение CI/CD сразу при создании проекта. Кроме того, в репозитории будет определена необходимая среда разработки, чтобы вы могли сразу приступить к кодированию и отладке.

.NET
Visual Studio 2022 будет иметь полную поддержку .NET 6 и его единой платформы разработки веб-, клиентских и мобильных приложений как для Windows, так и для Mac. Это включает в себя .NET MAUI для кроссплатформенных клиентских приложений в Windows, Android, macOS и iOS. Вы также можете использовать веб-технологии ASP.NET Blazor для написания настольных приложений через .NET MAUI. Кроме того, для большинства типов приложений вы сможете использовать .NET Hot Reload для применения изменений кода без необходимости перезапуска и без потери состояния приложения.

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

Сотрудничество в реальном времени
Live Share представит интегрированный текстовый чат, чтобы вы могли быстро обсуждать свой код без переключений контекста. У вас будет возможность запланировать повторяющиеся сеансы с повторным использованием одной и той же ссылки, что упростит совместную работу с вашими частыми контактами. Чтобы лучше поддерживать Live Share в организациях, также появятся политики сеансов, содержащие любые требования для совместной работы.
VS 2022 также будет включать новую мощную поддержку Git и GitHub. Появится много встроенной логики и контрольных точек, которые помогут вам эффективно пройти процесс слияния и проверки.

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

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

Источник: https://devblogs.microsoft.com/visualstudio/visual-studio-2022/

День восемьсот тринадцатый. #МоиИнструменты
Обработка Изображений в Вашем Репозитории GitHub
ImgBot - удобный бот, который вы можете добавить в свой репозиторий GitHub. Он бесплатный для проектов с открытым исходным кодом. Его задача - сжимать изображения, чтобы они были оптимизированы для отображения в интернете (то есть ваш сверхширокий снимок экрана размером 8МБ, который должен отобраться на странице блога с разрешением 600x200, не сожрёт много трафика).

Каждый раз, когда вы делаете коммит в основной репозиторий, ImgBot действует как CI-процесс и проверяет, есть ли в коммите изображения, которые он может обработать. Если изображения есть, он их сожмёт и сделает пул реквест с оптимизированными изображениями.

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

Настройка
Добавьте ImgBot в свой GitHub репозиторий, используя GitHub Marketplace и настройте план (бесплатный для проектов с открытым исходным кодом). Как только вы предоставите ImgBot доступ к своему репозиторию, он просканирует его и отправит вам серию пул реквестов. По умолчанию он использует сжатие без потерь, поэтому не беспокойтесь, что он испортит ваши красивые изображения.

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

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

Источник: https://ardalis.com/add-imgbot-to-github-repository/

День восемьсот четырнадцатый. #ЗаметкиНаПолях #GC
Топ Вопросов о Памяти в .NET. Начало 1-4
Вчера в нашем чате поделились интересной ссылкой на тест по организации памяти в .NET. Кому интересно попробовать свои силы перед тем, как читать дальше - https://quiz.dotnetmemoryexpert.com/

1. Что чаще всего вызывает сборку мусора в приложении .NET?
Наиболее распространённой причиной является случай, когда вы выделяете объект, и (грубо говоря) для него не хватает места. Таким образом, если приложение не выделяет новых объектов, есть небольшая вероятность, что сборки мусора вообще произойдёт. Вот почему вы могли слышать о zero-allocation коде. Такой код имеет хорошую производительность не только потому, что он не использует аллокации, но также значительно снижает вероятность сборки мусора и связанных с этим накладных расходов. А знать о том, когда происходит выделение памяти и избегать ненужных выделений - один из наиболее важных навыков при написании требовательного к памяти и производительности кода.

Другой, менее распространенный триггер сборки мусора - когда операционная система замечает нехватку доступной памяти. Она передаёт так называемое «уведомление о нехватке памяти», и различные программы могут реагировать на него (или игнорировать его). Среда выполнения .NET реагирует запуском сборки мусора, а также переключением в «режим низкого потребления памяти», что приводит к более агрессивному освобождению памяти.

Очевидно, что вызов GC.Collect может (или не может, в зависимости от его параметров) запускать сборку мусора. Но такие вызовы довольно редки, как и другие, менее распространённые триггеры.

2. В .NET 5 и Blazor (WebAssembly) одинаковые алгоритмы сборки мусора?
Blazor WebAssembly, начиная с .NET 5, работает на Mono (изначально написанном на C), но компилируется в WebAssembly. Таким образом, поскольку среда выполнения совершенно другая, она имеет и другой сборщик мусора. Хотя в будущем всё может измениться, потому что Mono интенсивно развивается и активно экспериментирует (например, в использовании «основного сборщика мусора» .NET).

3. Что означает так называемая «полная» сборка мусора?
При полной сборке мусора сборщик обрабатывает все поколения в SOH, а также LOH и POH (добавленной в .NET 5). Поэтому такую сборку следует воспринимать как самую «дорогую» с точки зрения загрузки памяти и процессора. В хорошо работающем приложении это должно происходить заметно реже, чем сборка в поколениях 0 и 1.

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

4. Что такое «кризис среднего возраста»?
Под «кризисом среднего возраста» мы понимаем нарушение так называемых гипотез поколений, на которых построены все «поколенческие» сборщики мусора (в том числе и .NET). Они подразумевают, что большинство объектов умирают молодыми, и что существует небольшая группа объектов, живущих долго. «Если объект молодой, он, вероятно, скоро умрёт. Если он живет долго, он, вероятно, проживет ещё дольше».

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

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

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

День восемьсот пятнадцатый. #ЧтоНовенького
.NET 6: Улучшения в Асинхронности
Из более, чем сотни изменений, предложенных для выпуска в .NET 6 сегодня рассмотрим наиболее существенные, относящиеся к асинхронному программированию.

Новые методы WaitAsync
Хотя в идеале все асинхронные функции подразумевают возможность отмены операции, иногда эта возможность не предоставляется. Для этих случаев в классы Task и Task<TResult> были добавлены три новых метода WaitAsync:

public Task WaitAsync(CancellationToken cancellationToken);
public Task WaitAsync(TimeSpan timeout);
public Task WaitAsync(TimeSpan timeout, CancellationToken cancellationToken);

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

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

Многоразовый CancellationTokenSource
Когда запускается операция, инициируемая извне, например веб-запрос, часто требуется создать CancellationTokenSource. Это позволяет обработчику запросов прерываться, если запрашивающая сторона отменяет запрос, разрывается соединение и т. д. Однако в большинстве случаев запрос не отменяется, то есть CancellationTokenSource не используется.

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

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

Название TryReset использовано из-за того, что повторно использовать можно будет только неиспользованный объект CancellationTokenSource. То есть, если на этом объекте уже была вызвана отмена операции, придётся создать новый. Использование будет примерно таким:

if (!cts.TryReset())
  cts = new CancellationTokenSource();

События отмены
Один из способов определить, что была запрошена отмена, - зарегистрировать делегат через CancellationToken.Register. Он будет выполнен при отмене, либо немедленно, если к моменту регистрации токен уже в состоянии отмены. Иногда этому делегату требуется доступ к используемому токену. Новая перегрузка CancellationToken.Register предложит эту возможность:

public CancellationTokenRegistration Register<T>(Action<T, CancellationToken> callback, T state);
public CancellationTokenRegistration UnsafeRegister<T>(Action<T, CancellationToken> callback, T state);

UnsafeRegister отличается тем, что не захватывает контекст исполнения.

Источник: https://www.infoq.com/news/2021/04/Net6-Async/

День восемьсот шестнадцатый.
FluentAssertions
Сегодня предлагаю вам посмотреть второе видео из серии Open-Source Power-Ups про популярные проекты с открытым исходным кодом в сообществе .NET.
Запись вебинара «OSS Power-Ups: FluentAssertions».

FluentAssertions - это обширный набор методов расширения, который позволяет более естественно описывать ожидаемый результат модульных тестов в стиле TDD или BDD. Деннис Думен, создатель этой библиотеки, поможет вам начать работать с FluentAssertions, а также расскажет о некоторых не самых известных нюансах использования.

День восемьсот семнадцатый. #ЗаметкиНаПолях
Тестирование Исключений с Помощью xUnit и Action
Когда вы пишете модульные тесты для метода, рекомендуется тестировать различные условия отказа («печальные пути») в дополнение к проверке того, что всё работает («счастливого пути»). В частности, если у вас есть метод, который может генерировать исключения, особенно если это пользовательские типы исключений, специфичные для вашего домена, вы должны быть уверены, что тестируете это поведение. Другой распространённый источник исключений - это защитные предложения, которые используются для поддержания чистоты вашего метода и обеспечения того, чтобы входные данные соответствовали ожиданиям метода.

В отличие от NUnit и MSTest, которые в основном используют атрибуты для ожидаемых исключений, xUnit предоставляет метод Assert.Throws<T>, который используется для проверки ожидаемых исключений (в NUnit3 также появился аналогичный метод):

Customer customer = null;
Assert.Throws<NullReferenceException>(
   () => customer.LastName);

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

var ex = Assert.Throws<NameRequiredException>(
   () => customer.UpdateName("", ""));
Assert.Equal("Имя не задано", ex.Message);

Arrange, Act, Assert и Исключения
Многие тесты используют шаблон тестирования AAA (Arrange, Act, Assert – Настройка, Действие, Утверждение). Проблема с предыдущим примером в том, что перехват исключения метода относится как к блоку Act, так и к блоку Assert. Кроме того, эта строка получается слишком длинной.

В этом случае для строгого следования шаблону AAA делегат для Assert.Throws можно выделить в отдельную переменную типа Action:

[Fact]
public void ThrowsExceptionGivenInvalidName {
  // Arrange
  var customer = new Customer();
  // Act
  Action act = () => customer.UpdateName("", "");
  // Assert
  var ex = Assert.Throws<NameRequiredException>(act);
  Assert.Equal("Имя не задано", ex.Message);
}

Теперь блок Действие явно содержит нужную операцию, а строка Assert.Throws гораздо короче и понятнее.

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

FluentAssertions
Об этой библиотеке подробно было рассказано во вчерашнем видео. Если вы используете её, то код утверждения будет выглядеть примерно так:
[Fact]
public void ThrowsExceptionGivenInvalidName {
// …

// Assert
action.Should()
.Throw<NameRequiredException>()
.WithMessage("Имя не задано");
}

Источник: https://ardalis.com/testing-exceptions-with-xunit-and-actions/