День семьсот восьмидесятый. #Оффтоп #ЗадачиНаСобеседовании
Доброй субботы, дорогие друзья. Новая задачка вам на выходной день. На этот раз никаких 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/

День семьсот восемьдесят пятый.
Элегантный Способ Создания URL с Помощью Flurl
Распространенной задачей при вызове веб-API или ресурсов из кода является создание URL-адреса и добавление необходимых параметров строки запроса. Обычно мы пишем что-то вроде этого:

var userId = 1;
var completed = true;
var someParamValue = "abc";

Uri baseAddress = new Uri("https://example.com/");
Uri apiUrl = new Uri(
  $"/todos?userId={userId}&completed={completed}" +
  $"&someParamValue={someParamValue}",
  UriKind.Relative);

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

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

using Flurl;
string url = "https://example.com/"
  .AppendPathSegment("todos")
  .SetQueryParam("userId", userId)
  .SetQueryParam("completed", completed)
  .SetQueryParam("someParam", someParamValue);

Помимо метода SetQueryParam, существует и SetQueryParams, который принимает объект, любую коллекцию пар ключ-значение, кортеж или словарь. Методы расширения Flurl доступны как для String, так и для System.Uri. В любом случае результат легко конвертировать туда и обратно с помощью методов ToString() и ToUri():

using Flurl;
Uri url = "https://example.com/"
  .AppendPathSegment("todos")
  .SetQueryParams(new {
    userId = userId,
    completed = completed,
    someParam = someParamValue
  })
  .ToUri();

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

Источник: https://kumarashwinhubert.com/flurl-the-elegant-way-to-build-urls-and-set-query-params-in-net

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

Начало работы
Если вы новичок, начните с создания простого микросервиса с помощью веб-API ASP.NET, Docker и разверните их в Azure Kubernetes Services (AKS).
1. Hello World Microservice - пошаговая инструкция по установке .NET и созданию вашего первого микросервиса в Docker.
2. Deploy a microservice to Azure – инструкция по равзвёртыванию .NET микросервиса в Azure Kubernetes Service (AKS).
3. Плейлист .NET and Docker 101 – расскажет об инструментах работы с .NET и Docker в Visual Studio.
4. Сегодня, 26 марта в 18:00 мск. смотрите двухчасовой курс Let’s Learn .NET: Microservices. Там вы узнаете, что такое микросервисы, зачем они вам и как их создавать с помощью C# и .NET.

Бесплатные электронные книги по архитектуре
1. Dapr for .NET Developers
Руководство для разработчиков .NET по пониманию и использованию Dapr, который помогает решать проблемы, возникающие при создании микросервисов, и делает ваш код независимым от платформы.

2. Architecting Cloud-native .NET Apps for Azure
В этом руководстве описана разработка приложений для облачных вычислений и рассматриваются темы, общие для большинства облачных приложений.

3. .NET Microservices: Architecture for Containerized .NET Applications
Это руководство для разработчиков и архитекторов решений, которые плохо знакомы с разработкой приложений на основе Docker и архитектурой на основе микросервисов. В нём рассматриваются такие шаблоны архитектуры, как DDD, CQRS, база данных для каждой службы, композиция API и т.д.

4. Serverless apps: Architecture, patterns, and Azure implementation
В этом руководстве основное внимание уделяется разработке бессерверных приложений, описаны их преимущества и недостатки, а также даётся обзор бессерверных архитектур.

5. Containerized Docker Application Lifecycle
Это руководство содержит общие сведения о Azure DevOps для реализации конвейеров CI/CD, описывает Реестр Контейнеров Azure (ACR) и службы Azure Kubernetes (AKS) для развёртывания.

Модернизация существующих приложений .NET
1. gRPC for WCF developers
Это руководство для разработчиков, которые ранее использовали WCF и хотят перенести свои приложения в современную среду RPC для .NET 5.

2. Modernize existing .NET applications with Azure cloud and Windows Containers
В этом руководстве основное внимание уделяется начальной модернизации существующих веб-приложений .NET Framework. Т.е. перенос рабочей нагрузки в новую или более современную среду без значительного изменения кода приложения и базовой архитектуры. Также обозначены преимущества переноса ваших приложений в облако и частичной модернизации приложений с использованием новых технологий и подходов, таких как контейнеры и вычислительные платформы в Azure.

3. Porting existing ASP.NET Apps to .NET Core
В этом руководстве представлены высокоуровневые стратегии миграции существующих приложений, написанных для ASP.NET MVC и веб-API (.NET Framework 4.x), в .NET Core. В нём также рассматриваются стратегии миграции больших решений на примере проекта.

Источник: https://devblogs.microsoft.com/dotnet/cloud-native-learning-resources-for-net-developers/

День семьсот восемьдесят седьмой.
6 Бесплатных Онлайн Инструментов для .NET Разработчиков
Сегодня представлю вам несколько бесплатных онлайн утилит, которые могут пригодиться в повседневной работе, поэтому добавляйте в закладки.

1. Stack Trace Formatter
Плохо отформатированные трассировки стека в блогах и на StackOverflow должны уйти в прошлое. Stack Trace Formatter позволяет легко отформатировать трассировку стека .NET и подсветит ключевые элементы. Также утилита позволяет скачать результат в виде текста, файла .md или картинки. Кроме этого, приводится справка о том, как понимать трассировку.


2. Appsettings.json Validator
С помощью этого валидатора файла appsettings.json вы можете легко проверить файлы конфигурации для .NET Core. Валидатор успешно находит ошибки в распространённых случаях, вроде неверного значения LogLevel.

3. Multiline String Converter
Всегда раздражает копировать откуда-нибудь длинную строку и вставлять её в строковый литерал в коде, экранируя кавычки и другие спецсимволы. Этот конвертер строк сделает для вас дословный строковый литерал из любого введённого текста.

4. JSON Formatter
Этот инструмент проверит правильность вашего кода JSON и преобразует его в отформатированный иерархический объект с возможностью сворачивания/разворачивания вложенных элементов. Очень полезно для разбора больших JSON-объектов, вроде данных, пришедших от API.

На закуску две утилитки для олдфагов 😉

5. Web.config Validator
Написание правильных файлов Web.config может быть довольно сложной задачей. К счастью, Visual Studio предоставляет IntelliSense, но иногда проще проверить файл web.config онлайн.

6. Web.config Transformation Tester
Хотя преобразования web.config сейчас используется не так часто, они по-прежнему являются частью многих легаси проектов. Web.config Transformation Tester наглядно покажет вам разницу между двумя файлами, которую вы можете упустить на первый взгляд.

Источник: https://blog.elmah.io/6-free-tools-for-net-developers/

День семьсот восемьдесят восьмой. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
82. Тестируйте во Сне и в Выходные
Расслабьтесь. Я не говорю о рабском труде или даже о сверхурочной работе по выходным или ночью. Скорее, я хочу обратить ваше внимание на то, сколько вычислительных мощностей имеется в вашем распоряжении. В частности, как много всего мы не используем, чтобы немного облегчить свою программистскую жизнь. Вам постоянно не хватает времени или вычислительных ресурсов в течение рабочего дня? Если да, то почему бы не запускать тесты в нерабочее время?

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

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

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

Слишком много вариантов для проверки вручную? Во многих случаях ваш продукт предназначен для работы на различных платформах. Например, как в 32-, так и в 64-битных системах Linux, MacOS или Windows, или просто в разных версиях одной и той же операционной системы. Что ещё хуже, многие современные приложения используют множество различных транспортных механизмов и протоколов (HTTP, gRPC, SOAP и т.п.). Ручное тестирование всех этих вариантов занимает очень много времени и, скорее всего, выполняется незадолго до выпуска продукта из-за нехватки ресурсов. Увы, это может быть слишком поздно, чтобы отловить и исправить некоторые неприятные ошибки. Автоматизированные тесты, выполняемые в ночное время или в выходные дни, гарантируют, что все эти варианты будут проверяться чаще. Немного разобравшись в сценариях, вы можете запланировать несколько назначенных заданий, чтобы начать тестирование ночью и на выходных. Есть также много инструментов для тестирования, которые могут помочь. Некоторые организации создают матрицы серверов, объединяющие сервера различных отделов и команд в общий пул для более эффективного их использования. Если это доступно в вашей организации, вы можете отправлять туда наборы тестов для выполнения ночью или в выходные дни.

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

День семьсот восемьдесят девятый. #ЗаметкиНаПолях
Мои любимые ошибки с IDisposable. 1/3
System.IDisposable - фундаментальный интерфейс, используемый в большинстве программ .NET. Его основная цель - предоставить механизм для высвобождения «неуправляемых» ресурсов: файловых потоков, подключений к базам данных, сетевых сокетов и т.д.

public interface IDisposable {
  void Dispose();
}

Что может быть проще? Кроме того, для него есть специальный синтаксис - оператор using:

using(var stream=File.OpenText("…")) {
  // неуправляемый ресурс stream
  // живёт внутри этого блока
}
// здесь stream удаляется

Красиво и просто!

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

1. IDisposable вам врёт
Кажется, интерфейс легко реализовать: всего один метод void, и готово! Но IDisposable обманывает. К нему предъявляются некоторые требования, которые нельзя выразить посредством простого объявления интерфейса:
- взаимодействие со сборщиком мусора через финализаторы,
- взаимодействие с подклассами,
- обработка повторных вызовов Dispose.
Для решения всех этих проблем мы используем паттерн Dispose. Это настолько распространенная проблема, что IDE и статические анализаторы могут подсказывать вам, как правильно реализовать IDisposable.

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

К сожалению, это обычное дело. Например:
- В IEquatable<T>, вы также должны переопределить базовые реализации Equals(Object) и GetHashCode().
- В IComparable<T>, вы должны перегрузить op_GreaterThan, op_GreaterThanOrEqual и т.п.
- Класс, реализующий IFormattable, должен поддерживать формат «G» (общий)…

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

2. Разработчики IDisposable могут вам врать
Мы уже знаем, что нам нужно использовать шаблон Dispose для наших реализаций IDisposable. А что насчёт использования чужих реализаций? Например, правильно ли SqlConnection использует шаблон Dispose? У нас нет другого способа узнать это, кроме как читать документацию.

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

using(var client = new HttpClient()) {
  // выполняем запрос
}

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

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

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

Источник: https://www.lazy-electron.com/2021/03/06/favorite-idisposable-bugs.html
Автор оригинала - Ryan Davis

День семьсот девяностый. #ЗаметкиНаПолях
Мои любимые ошибки с IDisposable. 2/3
Начало

3. Проблемы using и yield
IDisposable и using дают нам инструменты для управления очисткой наших ресурсов, но это может противоречить ленивой оценке, которую мы получаем от ключевого слова yield.

Давайте возьмём простой пример и воспользуемся Console.WriteLine, чтобы увидеть, как проявляется ошибка. Нам понадобится реализация IDisposable и несколько вспомогательных функций, чтобы реализовать неявный вызов. Сначала рассмотрим рабочий код:
https://dotnetfiddle.net/WwiN0r

Когда мы выполняем этот код, мы получаем ожидаемый результат:

start
connected
querying
dispose
result: 1
done

Все операции расположены в правильном порядке, и мы очищаем наши ресурсы сразу после использования. Заменим вывод метода Query в строке 17 на yield return:
https://dotnetfiddle.net/sfF1Au

Теперь результат довольно странный:

start
connected
dispose
querying
result: 1
done

Наш запрос выполняется ПОСЛЕ очистки ресурсов! Заметьте, что в реальном приложении вы получите ошибку при обращении к несуществующему ресурсу. Что происходит?

Мы просто добавили yield return, но компилятор «под капотом» проделал намного больше работы. Он создал класс с уникальным именем, реализующий IEnumerable<int>. Наш запрос к FakeResource возвращает экземпляр этого класса, но мы не выполняем собственно запроса, пока не начнёт исполняться цикл foreach. У Джона Скита есть отличный разбор всех внутренностей реализации. А подробнее про особенности выражения yield return, вы можете почитать на канале. Поищите посты по строке "Выражение yield return".

Главное отличие здесь в том, что мы перешли от немедленного оценивания выражения к ленивому, и это изменило реальный порядок действий: мы покинули блок using перед запуском нашего кода в Query(FakeResource).

Эта ошибка замечательна, потому что yield return и using могут быть в совершенно разных частях проекта. А чтобы столкнуться с этой ошибкой, нам достаточно хотя бы одного уровня косвенного доступа, и это довольно распространённое явление. При этом изменение на yield return само по себе выглядит невинно, и компилятор всем доволен.

Этот вид ошибки также может быть создан с помощью async и await; мы можем покинуть блок using, пока задача всё ещё хочет использовать наш IDisposable (см. этот пост).

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

Источник: https://www.lazy-electron.com/2021/03/06/favorite-idisposable-bugs.html
Автор оригинала - Ryan Davis

День семьсот девяносто первый. #ЗаметкиНаПолях
Мои любимые ошибки с IDisposable. 3/3
Начало
Продолжение

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

Совет на этот случай: если вы вызываете new, вы должны вызывать и Dispose. Если вы не вызывали new, вы не обязаны вызывать Dispose.

Рассмотрим эту функцию:

void Save(IDbConnection conn) {
  using(conn) {
   //…
  }
}

Разработчик пытается поступить правильно и очистить ресурсы после использования. Но теперь вызов Save имеет побочный эффект закрытия соединения. Это может привести к ошибке в другом месте:

using(var cn = new SqlConnection("…")) {
  Save(cn);
  Update(cn); // ошибка
}

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

Эта ошибка также может быть выражена объектно-ориентированным образом, и отладка становится ещё более мутной, когда мы получаем наш IDisposable через внедрение зависимости (DI):

public class Saver : IDisposable {
  readonly IDbConnection _conn;

  public Saver(IDbConnection conn) {
    _conn = conn;
  }
  public void Save() {…}
  public void Dispose() {
    _conn.Dispose();
  }
}

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

using(var cn = new SqlConnection("…")) {
  using(var sv = new Saver(cn)) {
    sv.Save();
  }
  using(var upd = new Updater(cn)) {
    upd.Update(); // ошибка
  }
}

И опять трассировка стека приведет нас в Update. А если здесь ещё использовать контейнер DI для внедрения IDbConnection, то найти связь между методами сохранения и обновления может быть почти невозможно.

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

Итого
На первый взгляд IDisposable выглядит просто, но, как и большинство других вещей в жизни, дьявол в деталях. Мы можем защитить себя и свои программы:
- почаще читая документацию,
- подключая анализаторы кода для отслеживания вещей, которые компилятор не может уловить,
- следуя политике очистки, в которой тот, кто вызвал new, должен вызвать и Dispose.

Источник: https://www.lazy-electron.com/2021/03/06/favorite-idisposable-bugs.html
Автор оригинала - Ryan Davis

День семьсот девяносто третий.
Как Просканировать NuGet Пакеты на Наличие Уязвимостей
Открытый исходный код есть везде. Для организаций и частных лиц вопрос сегодня не в том, используете ли вы открытый код или нет, а в том, какой открытый код вы используете и в каком объёме.

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

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

Что такое CVE/GHSA?
NuGet получает информацию об уязвимостях непосредственно из централизованной базы данных GitHub Advisory. База данных предоставляет два основных списка уязвимостей:
1. CVE (Common Vulnerabilities and Exposures) - список публично раскрытых общих уязвимостей и недостатков.
2. GHSA (GitHub Security Advisory) - это рекомендации по безопасности от GitHub. Подробности можно почитать тут.

Описания пакетов на NuGet.org
Вы можете видеть любые известные уязвимости прямо на NuGet.org. NuGet.org покажет баннер, сообщающий об обнаружении уязвимости с определенной степенью серьёзности и действиях, которые вы можете предпринять, чтобы защитить себя.

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

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

dotnet CLI
Вы можете вывести список всех известных уязвимостей в зависимостях ваших проектов и решений с помощью команды

dotnet list package --vulnerable

Команда выдаст список уязвимостей в пакетах верхнего уровня, версию пакета, в которой она исправлена и ссылку на рекомендации. Если вы хотите увидеть уязвимости в дочерних пакетах, используйте параметр --include-transitive.

Чтобы найти уязвимости в своих проектах, загрузите .NET SDK 5.0.200, Visual Studio 2019 16.9 или Visual Studio 2019 для Mac 8.8, который включает .NET SDK.

Источник: https://devblogs.microsoft.com/nuget/how-to-scan-nuget-packages-for-security-vulnerabilities/

День семьсот девяносто четвёртый. #ЧтоНовенького #CSharp10
3 Потенциальных Новинки в C# 10
10я версия языка не за горами, пора потихоньку знакомиться с тем, что нас ждёт. Сразу дисклеймер: следующие функции пока только в списке на включение в новую версию языка, но не факт, что они появятся и именно в описанном виде.

1. Пространства имён на уровне файла
Пространства имён – удобная вещь для логического разделения ваших классов. Единственный их недостаток – лишний уровень отступов и лишние фигурные скобки вокруг их содержимого. Предлагается объявлять пространство имён в начале файла, чтобы оно действовало на весь файл.
namespace HelloWorld;
public class Hello {
…
}
Можно иметь только одно пространство имён уровня файла, однако ничего не мешает вам создать вложенное пространство имён, заключив его код, как обычно, в фигурные скобки.

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

2. Обобщённые атрибуты
Этому предложению уже несколько лет, но, похоже, сейчас за него решили-таки взяться. И действительно, IL позволяет их использовать, почему бы не добавить эту функциональность в C#. Например, вместо:
[TypeConverter(typeof(X))]
использовать
[TypeConverter<X>]

3. «Необработанные» строки
Обычно использовать строковые литералы в коде, особенно длинные, - довольно муторное занятие. Нужно экранировать все кавычки, слеши и переводы строки. дословные (verbatim) строки серьёзно упростили жизнь при использовании URL или регулярных выражений, но всё равно приходится экранировать кавычки, которые в некоторых случаях, например, в коде XML или JSON, используются довольно часто.

Необработанные (raw) строки предлагают вам использовать строковые литералы «как есть». Они используют новый маркер начала и конца строки – несколько кавычек и новая строка в начале, новая строка и столько же кавычек в конце. Между ними просто вставляйте блок текста, который будет трактоваться как одна строка. Проще показать на примере:
string xml = """
<part number="1976">
<name>Windscreen Wiper</name>
<description>The "Windscreen wiper" automatically removes rain from your windscreen. It has a rubber <ref part="1977">blade</ref>, which can be ordered separately.</description>
</part>
""";
Если вам нужно использовать в тексте тройные кавычки, можете обозначить начало и конец строки четырьмя кавычками и т.д.

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

Источник: https://medium.com/young-coder/c-10-3-candidate-features-that-could-make-the-final-cut-3b46f4a62284

День семьсот девяносто пятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
83. Тестирование – Это Строгость в Разработке Программного Обеспечения
И снова о тестировании.

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

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

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

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

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

День семьсот девяносто шестой. #ЗаметкиНаПолях #SQL
Ограничение Результатов с Помощью Оконных Функций
Оконные (window) аналитические функции давно присутствуют в SQL, однако многие до сих пор не умеют их применять.

Окно (window) - это набор строк таблицы, которые можно анализировать или применить к ним функцию. Строки должны быть как-то связаны. Иногда они связаны с конкретной строкой, т.е. строки могут быть выше или ниже друг друга или в пределах заданного диапазона. Либо связь может быть основана на отдельных группах данных в наборе.

Все оконные функции следуют определенному синтаксису.

<название функции>(<выражение>) OVER (
  <окно>
  <сортировка>
)

Сначала идёт название функции, а за ним следует предложение OVER. Оно определяет область действия окна, указывая набор строк, к которым будет применяться функция. Предложение OVER является обязательной частью оконной функции. Остальной синтаксис является необязательным, и зависит от желаемой области действия:
- Выражение PARTITION BY можно использовать для разделения набора данных на отдельные группы (аналогично GROUP BY).
- Выражение ORDER BY используется для упорядочивания строк в каждой группе.

В качестве оконных можно использовать простые агрегатные функции, вроде SUM(), COUNT(), AVG() и т.п. Но есть и несколько специальных.

Номера и ранг строк
Простейший вариант применения оконной функции – вывести номера строк результата (см. пример 1 на картинке ниже). Здесь «окном» является весь набор, а функция ROW_NUMBER() выводит номер строки по порядку.
Мы можем разделить набор данных на группы, используя PARTITION BY. В примере 2 на картинке ниже тот же набор разделён по полю name, а внутри каждой такой группы упорядочен по полю course.

Кроме этого две функции RANK() и DENSE_RANK() выводят ранг строки. Они отличаются от ROW_NUMBER() тем, что при равенстве результатов задают строкам одинаковые значения. При этом DENSE_RANK() продолжает нумерацию, например, 1,1,2,2,3. А RANK() использует следующий номер строки по порядку, оставляя разрывы в нумерации: 1,1,3,3,5. В примере 3 на картинке ниже приводится сравнение этих функций на том же наборе данных. Здесь использована сортировка всего набора по полю name, без разбиения на группы.

Заметьте, что выражение ORDER BY внутри оконной функции никак не связано с выражением ORDER BY всего запроса. Оно влияет только на результаты оконной функции. В предыдущем примере мы могли бы добавить ORDER BY ко всему запросу и изменить порядок строк в запросе, но результаты функций ROW_NUMBER(), RANK() и DENSE_RANK() в строках не изменились бы.

Первое и последнее значение
Эти функции позволяют вывести первое или последнее соответственно значение столбца в группе. В отличие от функций, описанных выше, для каждой группы будет выведена только одна строка. Например, если использовать LAST_VALUE(course) на наборе данных из примера 2(последний по алфавиту курс для каждого студента), то будет выведено 3 строки:
Jason Economics
Lucy Health Science
Martha Biology.

Предыдущие и последующие строки
Часто бывает полезно сравнивать строки с предыдущими или последующими, особенно если данные упорядочены (например, хронологически). Для этого используются функции LAG(), которая извлекает значения из предыдущих строк, и LEAD(), которая извлекает значения из последующих строк. В примере 4 на картинке ниже мы получаем значение суммы из предыдущего месяца с помощью функции LAG(sales,1). В функцию, помимо названия столбца, передаётся целое число, означающее количество строк, которые нужно отсчитать от текущей (в нашем случае 1). Для первой строки, очевидно, нет предыдущего значения, поэтому функция возвращает NULL.

Источник: https://app.pluralsight.com/library/courses/combining-filtering-data-postgresql

День семьсот девяносто седьмой. #Шпаргалка
20 Команд Git, Которые Надо Знать
Git был выпущен в 2005 году. Несмотря на то, что сейчас появилось много программ с графическим интерфейсом для управления репозиторием, труЪ программеры используют консоль. Поэтому ловите 20 наиболее полезных команд Git, которые понадобятся любому разработчику. Подробности о работе Git см. начиная с этого поста.

1. Вывести конфигурацию

git config -l

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

2. Изменить ваше имя пользователя

git config --global user.name "<ваше имя>"

3. Изменить ваш email

git config --global user.email "[email protected]"

4. Создать репозиторий

git init

Эта команда инициализирует репозиторий в текущей папке.

5. Добавить файл в staging

git add my_file

6. Добавить все файлы в staging

git add .

7. Проверить статус

git status

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

8. Commit

git commit

Эта команда создаст коммит. В этом варианте откроется текстовый редактор, куда вам нужно будет записать сообщение коммита.

9. Commit с сообщением

git commit -m "Ваше сообщение"

10. Просмотр истории

git log

11. Список веток

git branch

12. Создание ветки

git branch my_branch

Заметьте, что Git не переключится на эту ветку автоматом. Для этого см. пункт 14.

13. Удаление ветки

git branch -d my_branch

Обратите внимание на флаг -d.

14. Переключение между ветками

git checkout my_branch

15. Создание ветки и переключение на неё
Пункты 12 и 14 можно объединить в одну команду:

git checkout -b branch_name

16. Добавление удалённого репозитория

git add remote https://repo_url

17. Публикация в удалённый репозиторий

git push

18. Обновление из удалённого репозитория

git pull

19. Временное сохранение изменений

git stash

Эта команда временно сохранит неподтверждённые изменения и вернёт ваш репозиторий в состояние последнего коммита.

20. Получение временно сохранённых изменений

git stash pop

Эта команда применит сохранённые ранее изменения обратно к вашему репозиторию.

Источник: https://www.c-sharpcorner.com/article/20-git-commands-you-should-know/

День семьсот девяносто восьмой. #юмор
Ооо, это про меня.

День семьсот девяносто девятый. #ЗадачиНаСобеседовании
Сегодня предложу вам к просмотру ещё один минисериал от 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