День 1196. #ЗаметкиНаПолях
Правила Кода
Roslyn имеет очень большой набор анализаторов для проверки качества вашего кода, но вы должны включить эти анализаторы, прежде чем они начнут что-то делать. Сегодня рассмотрим краткую информацию о том, почему важно включать эти анализаторы в ваши проекты C#, как это сделать и как их настроить.

Правила кода — это правила, которые компилятор или инструмент анализа кода применяет на уровне сборки. Они обеспечивают соблюдение соглашений о кодировании, выявляют ошибки и предоставляют инструменты для исправлений. Roslyn и другие инструменты .NET/C# используют статический анализ кода, чтобы проверить, где в вашем коде есть нарушения. Rider и Resharper предоставляют инструменты статического анализа кода поверх существующего анализа кода от Roslyn.

У команд, которые используют правила кода, возникает меньше проблем. Вот некоторые из преимуществ использования анализа кода:
- Уменьшает количество ошибок
- Уменьшает количество претензий к вашему коду в пул-реквестах
- Заставляет использовать новые конструкции кода вместо старых
- Изменяет вредные привычки
- Одинаковый стиль кода уменьшает количество несущественных различий в Git
- Удаляет ненужный код
- Уменьшает количество ненужных путей кода

Без правил кода этот код компилируется нормально:

public static class Program
{
  public static void Main() => 
    Console.WriteLine(
      string.Format(new CultureInfo("en-US"), 
      "Hello {0}{1}!", "World")
    );
}

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

Правила кода включаются на уровне csproj, а затем можно изменить файл editorconfig для отдельных правил. Нужно добавить Nuget пакет Microsoft.CodeAnalysis.NetAnalyzers (Roslyn Analysers). Это самый распространённый набор анализаторов. Они работают на всех IDE и платформах и внутри конвейеров CI/CD. Вы также можете добавить другие пакеты Nuget для дополнительных анализаторов.

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

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

Рекомендуется включить все правила кода и постепенно исправлять ошибки, с которыми вы сталкиваетесь в своём решении. Существуют инструменты массового исправления, которые помогут вам решить многие проблемы. Команда CLI dotnet format применит множество исправлений, но чаще бывает безопаснее применять исправления для правил по одному вручную. Устранение всех проблем может занять некоторое время. Однако не нужно исправлять все нарушения правил кода за один раз.

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

Источник: https://christianfindlay.com/2022/04/24/code-rules/

День 1197. #юмор
Шпаргалка по кодам ответов HTTP.

День 1198. #ЧтоНовенького
Обновления ASP.NET Core в .NET 7 Превью 4. Начало
Недавно вышедший превью 4 .NET 7 включает много отличных обновлений в ASP.NET Core.

1. Улучшения производительности HTTP/2
Значительно переработана обработка сервером Kestrel запросов HTTP/2. HTTP/2 позволяет параллельно выполнять до 100 запросов по TCP-соединению. Это называется мультиплексированием. До превью 4 мультиплексирование HTTP/2 в Kestrel основывалось на блокировке через ключевое слово lock для управления тем, какой запрос может записывать в TCP-соединение. Хотя блокировка — это простое решение для написания безопасного многопоточного кода, она неэффективна при высокой конкуренции потоков.

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

Решение состоит в том, чтобы переписать, как запросы HTTP/2 в Kestrel получают доступ к TCP-соединению. Потокобезопасная очередь заменяет блокировку записи. Вместо того, чтобы бороться за то, кто может использовать блокировку записи, теперь запросы выстраиваются в очередь, и их обрабатывает выделенный потребитель. Ресурсы ЦП, которые ранее тратились впустую, теперь доступны остальной части приложения.

Эти улучшения видны в gRPC, популярной среде RPC, использующей HTTP/2.

2. Типизированные результаты для минимальных API
В .NET 6 представили интерфейс IResult для предоставления значений, возвращаемых из минимальных API, которые не используют неявную поддержку сериализации JSON возвращённого объекта в ответ HTTP. Статический класс Results используется для создания различных объектов IResult, представляющих различные типы ответов, от простой установки кода ответа до перенаправления на другой URL-адрес. Однако типы инфраструктуры, реализующие IResult, возвращаемые этими методами, были внутренними, что затрудняло проверку конкретного типа IResult, возвращаемого методами API, в модульных тестах.

В .NET 7 типы, реализующие IResult в ASP.NET Core, стали общедоступными, что позволяет использовать простые утверждения при тестировании. Пусть у нас есть следующий метод API:

public async Task<IResult> GetTodos(TodoDb db)
{
  return Results.Ok(
    await db.Todos.ToArrayAsync()
   );
}

Тогда проверить результат метода можно следующим образом:

var db = CreateDbContext();
var result = await api.GetTodos(db);
Assert.IsType<Ok<object>>(result);

Обратите внимание, что тип результата — Ok<object>, поскольку метод Results.Ok(object? value = null) принимает значение как объект, а не как исходный тип. Чтобы решить эту проблему, введён новый фабричный класс для создания «типизированных» результатов.

Новый статический класс Microsoft.AspNetCore.Http.TypedResults является «типизированным» эквивалентом существующего класса Microsoft.AspNetCore.Http.Results. Вы можете использовать TypedResults в минимальных API для создания экземпляров типов, реализующих IResult, c сохранением информации о конкретном типе.

Тогда пример выше можно переписать с использованием TypedResults:

public async Task<IResult> GetTodos(TodoDb db)
{
  return TypedResults.Ok(
    await db.Todos.ToArrayAsync()
   );
}

И протестировать уже типизированный результат:

var db = CreateDbContext();
var result = await todosApi.GetTodos(db);
Assert.IsType<Ok<Todo[]>>(result);

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

Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-4/

День 1199. #Testing
Тестирование в Реальной Жизни. Начало
Коротко о различных нестандартных типах тестов и о том, что нужно иметь в виду при их использовании.

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

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

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

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

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

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

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

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

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

Источник: https://blog.adamfurmanek.pl/2022/02/19/types-and-programming-languages-part-9/

День 1200. #Testing
Тестирование в Реальной Жизни. Окончание
Коротко о различных нестандартных типах тестов и о том, что нужно иметь в виду при их использовании.

Начало

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

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

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

Третий подход заключается в использовании A/B-тестов или любых переключателей. Вы просто реализуете условие if в своем коде, которым вы можете управлять с помощью некоторого переключателя после развертывания. Таким образом, сначала парк работает только с кодом A. Затем развёртывается приложение с кодом A и B и запускается только код A, потому что переключатель выключен. После развёртывания можно выборочно включить код B на нескольких хостах. Это хорошо, потому что можно контролировать, сколько клиентов получат новое поведение, и легко откатить его. Однако, помимо недостатков предыдущего решения, это также создаёт риск возникновения ошибки в условии if. Не говоря уже о том, что, если у вас несколько переключателей, может быть сложно отследить, что происходит.

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

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

Источник: https://blog.adamfurmanek.pl/2022/02/19/types-and-programming-languages-part-9/

День 1201. #Курсы
Челлендж Microsoft Build Cloud Skills
Выполните задание и получите бесплатный пропуск на сертификационный экзамен Microsoft.

На выбор доступно 8 испытаний, выберите то, что подходит именно вам. После того, как вы выполните задание, вы получите бесплатный пропуск на сертификационный экзамен Microsoft, который может быть применён для любого из следующих экзаменов:
- AI-102: Designing and Implementing a Microsoft Azure AI Solution
- AZ-204: Developing Solutions for Microsoft Azure
- AZ-220: Microsoft Azure IoT Developer
- AZ-400: Designing and Implementing Microsoft DevOps Solutions
- DP-420: Designing and Implementing Cloud - Native Applications Using Microsoft Azure Cosmos DB
- MS-600: Building Applications and Solutions
- PL-100: Microsoft Power Platform App Maker
- PL-200: Microsoft Power Platform Functional Consultant
- PL-300: Microsoft Power of BI Data Analyst
- SC-200: Microsoft Security Operations Analyst
- SC-300: Microsoft Identity and Access Administrator

Челлендж начинается 24 мая 2022 г. в 16:00 UTC и заканчивается 21 июня 2022 г. в 16:00 UTC. Убедитесь, что все модули вашего задания завершены, прежде чем истечёт время.

Если вы выполните задание до истечения срока, в вашем профиле Microsoft Learn 30 июня 2022 г появится пропуск на один сертификационный экзамен Microsoft.

Правила
- Вы можете претендовать только на один пропуск на человека, независимо от количества выполненных испытаний.
- Пропуск может быть использован для сдачи одного сертификационного экзамена Microsoft, который проводится в авторизованном центре тестирования Pearson Vue или на сайте Pearson Vue до 31 декабря 2022 г.

Подпишитесь на рассылку, чтобы получить уведомление, когда начнётся челлендж: https://www.microsoft.com/en-us/cloudskillschallenge/build/registration/2022

День 1202. #ЗаметкиНаПолях
Список Всех Маршрутов в ASP.NET Core
Когда ваше приложение ASP.NET Core станет достаточно большим, вам может понадобиться полное представление обо всех маршрутах. Существует несколько способов объявления маршрутов. Вы можете использовать минимальные API, контроллеры, Razor Pages, gRPC, HealthCheck и т. д. Но все они используют одну и ту же систему маршрутизации под капотом.

Коллекция маршрутов может быть указана путем извлечения коллекции EndpointDataSource из DI.

Пример для минимальных API:

if (app.Environment.IsDevelopment())
{
  app.MapGet("/debug/routes", 
   (IEnumerable<EndpointDataSource> sources) =>
    string.Join("\n", sources.SelectMany(s => s.Endpoints)));
}

Добавление этого блока в пример приложения из документации выведет следующие маршруты:

HTTP: GET /
HTTP: GET /todoitems
HTTP: GET /todoitems/complete
HTTP: GET /todoitems/{id}
HTTP: POST /todoitems
HTTP: PUT /todoitems/{id}
HTTP: DELETE /todoitems/{id}
HTTP: GET /debug/routes

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

public string Get([FromServices] 
 IEnumerable<EndpointDataSource> sources)
{
  var sb = new StringBuilder();
  var endpoints = 
    sources.SelectMany(s => s.Endpoints);
  foreach (var e in endpoints)
  {
    sb.AppendLine(e.DisplayName);
 
    if (e is RouteEndpoint re)
      sb.AppendLine(re.RoutePattern.RawText); 
  }

  return sb.ToString();
}

Источник: https://www.meziantou.net/list-all-routes-in-an-asp-net-core-application.htm

День 1203. #ЧтоНовенького
Превью 4 Обновлений ASP.NET Core в .NET 7. Продолжение
Продолжаем рассматривать обновления ASP.NET Core в превью 4 .NET 7.
Начало

3. Возврат нескольких типов результатов из минимальных API
Новые обобщённые объединяющие типы Results<TResult1, TResult2, TResultN> вместе с классом TypesResults можно использовать для объявления того, что обработчик маршрута возвращает несколько конкретных типов, реализующих IResult. Любые из этих типов, реализующие IEndpointMetadataProvider, добавят метаданные для конечной точки, позволяя платформе автоматически добавлять описания типов HTTP-результатов для API в OpenAPI/Swagger:

app.MapGet("/todos/{id}", 
  async Results<Ok<Todo>, NotFound> (int id, TodoDb db)
{
  return await db.Todos.FindAsync(id) is Todo todo
    ? TypedResults.Ok(todo)
    : TypedResults.NotFound();
});

В этом случае в описании OpenAPI/Swagger этот метод будет иметь 2 типа типов HTTP-результата: HTTP 200 OK и HTTP 404 NotFound.

Объединяющие типы Results<TResult1, TResultN> реализуют операторы неявного приведения, чтобы компилятор мог автоматически преобразовывать типы, указанные в обобщённых аргументах, в экземпляр объединяющего типа. Это даёт дополнительное преимущество. Во время компиляции проверяется, что обработчик маршрута на самом деле возвращает только те результаты, которые он декларирует. Попытка вернуть тип, который не объявлен как один из обобщённых аргументов в Results<>, приведет к ошибке компиляции.

4. Промежуточное ПО для ограничений
Предоставляет удобный способ задания ограничений для входящих HTTP-запросов. Например, ConcurrencyLimiter позволяет ограничить количество одновременных входящих запросов:

app.UseRateLimiter(new RateLimiterOptions
{
  Limiter = PartitionedRateLimiter
   .Create<HttpContext, string>(resource =>
  {
    return RateLimitPartition
     .CreateConcurrencyLimiter("MyLimiter",
       _ => new ConcurrencyLimiterOptions(
        2, QueueProcessingOrder.NewestFirst, 3));
  })
});

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

В этом примере используется ConcurrencyLimiter с ограничением в 2 одновременных доступа, параметром, указывающим, что запросы должны обрабатываться по очереди по мере поступления и параметром, задающим размер очереди в 3 запроса.

На данный момент RateLimitPartition содержит методы для создания ConcurrencyLimiter, TokenBucketRateLimiter и NoopLimiter, которые используются аналогично примеру выше.

Подробнее про возможности ограничителя рассказывает Ник Чапсас в своём недавнем видео.

Реализация ограничений в превью 4 .NET 7 пока минимальна и не поддерживает раздельные конечные точки. В будущем планируется это реализовать, а также добавить дополнительные параметры конфигурации. Пока можно использовать System.Threading.RateLimiting для создания PartitionedRateLimiter, который может применять различные ограничения к различным конечным точкам.

Источник: https://devblogs.microsoft.com/dotnet/asp-net-core-updates-in-dotnet-7-preview-4/

День 1204.
В очередной раз неведомые алгоритмы ютуба подкинули мне интересное видео.
Sergei Calabonga рассказывает о собственном фреймворке Nimble Framework, предназначенном для быстрого создания микросервисов.

https://youtu.be/xijBGwMEL8E

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

Недавно Сергей выпустил версию 6.1 фреймворка, о которой и рассказывает в этом видео.

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

День 1205. #ЗаметкиНаПолях
Профессиональное Документирование Кода
Все мы (надеюсь) документируем свои классы и методы с помощью XML комментариев <summary>, которые можно добавить с помощью тройного слеша (///) над заголовком метода/класса. Однако далеко не все используют все возможности этой документации, редко выходя за описание собственно элемента, параметров в <param> и возврата в <returns>. Вот некоторые полезные теги, позволяющие сделать подсказки более информативными.

1. Секция <remarks>
Добавит новый абзац текста после текста описания в summary, в котором можно указать дополнительную информацию. Кстати, можно добавить только один блок <remarks>, остальные просто игнорируются. Однако можно разделить текст внутри <remarks> на параграфы с помощью тега <para>.

2. Секция <exception>
Позволяет описать исключения, которые может выбросить метод:

<exception cref="класс">описание</exception>

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

3. Тег <inheritdoc/>
Позволяет унаследовать описание из другого элемента (класса, интерфейса или метода).
- <inheritdoc/> для класса наследует все описания всех членов.
- <inheritdoc cref="сигнатура"/> - позволяет указать, из какого члена унаследовать описание. Существующие теги на текущем члене не будут перезаписаны.
- <inheritdoc [cref=""] path="путь"/> - позволяет указать путь XPath к тегам, которые нужно унаследовать. Таким образом можно отфильтровывать ненужные или только нужные теги.

4. Тег <paramref/>
Позволяет в описании сослаться на параметр метода, выделив его в тексте: <paramref name="параметр"/>.

5. Тег <see/>
Позволяет добавить ссылку на другой объект или внешний источник в тексте.
- <see cref="сигнатура"/> - ссылка на член или поле, доступное для вызова из текущей среды компиляции.
- <see href="ссылка" /> - кликабельная ссылка на указанный URL. Например, <see href="https://github.com">GitHub</see> создаёт кликабельную ссылку с текстом GitHub, которая ссылается на https://github.com.
- <see langword="слово" /> - ключевое слово языка, например true или одно из других допустимых ключевых слов. Кроме того, правильно отображает ключевое слово в подсказке (например, true в C# и True в VB).

6. Тег <seealso/>
Аналогично тегу <see/> позволяет добавлять кликабельные ссылки на другой объект или внешний источник в секции «См. также». Нельзя использовать внутри <summary>.

7. Тег <include/>
Позволяет ссылаться на комментарии в отдельном файле, описывающие типы и элементы в исходном коде:

<include file='путь к файлу' path='путь к элементу' />

Использование внешнего файла является альтернативой размещению документации непосредственно в файле исходного кода. Это позволяет применять систему управления версиями к документации отдельно от исходного кода. Один человек может менять файл исходного кода, а другой — файл документации.

Источник: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/xmldoc/recommended-tags

День 1206. #ЗаметкиНаПолях
Упрощаем Работу с Данными
Если вы работаете с двоичными данными и используете byte[], можно упростить себе жизнь, используя класс BinaryData, который представляет собой облегчённую абстракцию для работы с двоичными данными, поддерживающую преобразование между строкой, потоком, JSON и байтами.

Замечание: Чтобы работать с классом BinaryData, нужно установить NuGet пакет System.Memory.Data.

Допустим, у нас есть следующий объект:

record Person(string FirstName, string LastName);
var person = new Person("John", "Smith");

Преобразуем в JSON-строку:

var personData = new BinaryData(person);
Console.WriteLine(personData.ToString());
// Вывод:
// {"FirstName":"John","LastName":"Smith"}

Преобразуем JSON в объект:

var person2 = personData.ToObjectFromJson<Person>();
Console.WriteLine(person2.ToString());
// Вывод (стандартный ToString для типа record):
// Person { FirstName = John, LastName = Smith }

Теперь рассмотрим работу со строками и двоичными данными:

var stringData = new BinaryData("Hello World!");

Преобразуем строку в массив байт:

byte[] bytes = stringData.ToArray();
var bytesData = new BinaryData(bytes);

Преобразуем массив байт в поток:

Stream stream = bytesData.ToStream();

Читаем из потока:

var streamData = BinaryData.FromStream(stream);
Console.WriteLine(streamData.ToString());
// Вывод:
// Hello World!

Источник: https://twitter.com/MarusykRoman/status/1521256457630535680

День 1207. #Карьера
Как Выработать Привычки и Сохранять Мотивацию. Начало
Вам бывало сложно работать над проектом? Бывали моменты, когда ничто не кажется захватывающим? В этом посте обсудим, что делать, когда у вас нет мотивации, и как справиться с прокрастинацией.

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

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

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

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

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

Как разработчик, подумайте, какие цели вы перед собой поставили? Например:
- На этой неделе: создать функционал для проекта.
- В этом месяце: изучить Blazor.
- В этом квартале: релиз проекта.
- В этом году: овладеть MAUI, выступить на конференции и писать в блог по одному посту каждый месяц.

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

Например:
Цель: создать функционал для проекта.
Срок: 1 неделя с сегодняшнего дня.
Шаги:
1. Исследовать, что необходимо: зависимости, активы, вовлечённые люди.
2. Разбить создание функционала на этапы.
3. Какие есть нерешённые вопросы?
4. Кто может помочь?
График:
День 1: Исследования
Дни 2-3: Разработка + тестирование
День 4: Сквозное тестирование + исправление ошибок.
День 5: Развёртывание в тестовой среде и подготовка к презентации.

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

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

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

Источник: https://www.freecodecamp.org/news/create-a-habit-system-and-stay-motivated-as-a-developer/
Автор оригинала: Shruti Kapoor

День 1208. #Карьера
Как Выработать Привычки и Сохранять Мотивацию. Продолжение
Начало

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

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

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

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

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

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

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

Источник: https://www.freecodecamp.org/news/create-a-habit-system-and-stay-motivated-as-a-developer/
Автор оригинала: Shruti Kapoor

День 1209. #ЗаметкиНаПолях
Полиморфизм в C#: Override и New
В чём разница между созданием виртуального/переопределяемого метода и простым сокрытием метода с помощью ключевого слова new в C#?

Во-первых, в отличие от переопределения, при использовании ключевого слова new вы можете изменить тип возвращаемого значения. Однако, это ещё не всё.

Допустим, у нас есть родительский класс и два потомка. Один потомок использует override, другой – new:

class Parent
{
  public virtual void WhoAmI() =>
    Console.WriteLine("Parent");
}

class Child : Parent
{
  public override void WhoAmI() =>
    Console.WriteLine("Child");
}

class ChildNew : Parent
{
  public new void WhoAmI() =>
    Console.WriteLine("ChildNew");
}

Тогда что выведет следующий код?

Parent child = new Child();
child.WhoAmI();

Parent childNew = new ChildNew();
childNew.WhoAmI();

На первый взгляд кажется, что в обоих случаях случае он выведет одно и то же. В конце концов, в обоих случаях производный тип приводится к родительскому. При таком кастинге важно учитывать, что объект «всегда помнит, кто он». То есть Child можно привести к Parent или даже к object, и он всё равно помнит, что он Child. Так что же выведет код выше?

Child
Parent

Итак, Child с переопределённым методом запомнил, кто он есть, и, следовательно, был вызван тот же метод WhoAmI(), но переопределённый. В случае с ChildNew… это не совсем так. На самом деле, если подумать, объяснение довольно простое. Когда вы используете ключевое слово override, оно переопределяет базовый класс, и между двумя методами существует своего рода «связь». То есть известно, что дочерний член является переопределением базового.

Когда вы используете ключевое слово new, вы говорите, что эти два метода никак не связаны между собой. И что ваш новый метод существует только в дочернем классе, но не в родительском. Между ними нет «связи». Поэтому при приведении к родительскому классу переопределённый метод известен, а «новый» метод — нет.

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

Источник: https://dotnetcoretutorials.com/2022/05/13/override-vs-new-polymorphism-in-c-net/

День 1210. #ЧтоНовенького
Централизованное Управление Пакетами
Управление зависимостями — основная функция NuGet. В одном проекте это может быть просто, а в многопроектных решениях могут возникать трудности. Если вы управляете общими зависимостями для нескольких различных проектов, теперь можно использовать функции централизованного управления пакетами NuGet.

Исторически зависимости пакетов NuGet управлялись в двух основных местах:
- packages.config – XML-файл, используемый в старых типах проектов для хранения списка пакетов, на которые ссылается проект,
- <PackageReference /> — элемент XML, используемый в новых типах проектов, который управляет зависимостями NuGet непосредственно в файлах проекта.

Начиная с NuGet 6.2, вы можете централизованно управлять своими зависимостями в своих проектах, добавив файл Directory.Packages.props. Функционал доступен во всех последних версиях инструментов разработки.

Создайте файл Directory.Packages.props в корне решения и установите ManagePackageVersionsCentrally в true. Далее вы можете определять версии пакетов, необходимых для вашего решения:

<Project>
  <PropertyGroup>
    <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>
  </PropertyGroup>
  <ItemGroup>
    <PackageVersion Include="Newtonsoft.Json" Version="13.0.1" />
  </ItemGroup>
</Project>

В проектах решения используйте тот же синтаксис <PackageReference /> для ссылок на пакеты, но без атрибута Version (можно переопределить версию в конкретном проекте с помощью атрибута VersionOverride):

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" />
  </ItemGroup>
</Project>

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

Предупреждение
При использовании централизованного управления пакетами вы увидите предупреждение NU1507, если в вашей конфигурации определено более одного источника пакетов. Чтобы это исправить, добавьте файл nuget.config в корень проекта с сопоставлением источников пакетов:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" />
  </packageSources>

  <packageSourceMapping>
    <packageSource key="nuget.org">
      <package pattern="*" />
    </packageSource>
  </packageSourceMapping>
</configuration>

Можно добавить дополнительные источники и конфигурацию при необходимости. См. подробнее тут

Замечание
В Visual Studio 2022 возникает проблема при обновлении пакетов через NuGet Package Manager. После обновления меняется версия пакета в файле .csproj проекта (добавляется атрибут Version="…", вместо обновления его в файле Directory.Packages.props), что приводит к ошибке компиляции. Приходится исправлять это, вручную редактируя оба файла. Надеюсь, в будущем это исправят. Ишью им отправил :)

Источник: https://devblogs.microsoft.com/nuget/introducing-central-package-management/

День 1211. #ЗаметкиНаПолях
SQL Последовательности для Создания Уникальных Значений
Для создания уникального номера, например заказа в системе продаж, вы можете:
- использовать автогенерацию первичного ключа из базы данных,
- выбирать максимальный номер заказа из базы и добавлять единицу,
- использовать свой код, генерирующий уникальные числа.
– использовать SQL-последовательность.

Последовательность (sequence) - простой и эффективный способ создания уникальных упорядоченных значений потокобезопасным способом.

SQL код для создания очень прост:

CREATE SEQUENCE TestSeq
START WITH 1
INCREMENT BY 1

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

SELECT NEXT VALUE FOR TestSeq

Entity Framework также поддерживает последовательности… ну, более-менее. Создать последовательность можно в OnModelCreating вашего DbContext:

protected override void OnModelCreating(ModelBuilder mb)
{
  mb.HasSequence("TestSeq",
   x => x.StartsAt(1000).IncrementsBy(2));
  …

А вот простого метода получения следующего значения нет. Большинство документации сводится к использованию значения по умолчанию через вот такую конструкцию:

mb.Entity<Order>()
  .Property(o => o.OrderNo)
  .HasDefaultValueSql("NEXT VALUE FOR TestSeq");

Ограничения
При принятии решения об использовании последовательностей, необходимо иметь в виду некоторые их ограничения:
1. Когда вы запрашиваете число, независимо от того, что происходит с этого момента, последовательность увеличивается. Последовательности не являются частью транзакций. Если вы откатите транзакцию с выбранным числом последовательности, это число «потеряется».

2. Последовательности не могут быть «разделены» каким-либо образом. Если вам требуется генерировать уникальные номера в течение года, а с 1 января «сбрасывать» нумерацию, вы не сможете создать заказ «задним числом». 1 января последовательность сбросится, и получить номер для заказа от 31 декабря прошлого года не удастся. Вариант решения – иметь несколько последовательностей на текущий год и несколько предыдущих, в которых ещё требуется продолжать нумерацию.

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

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

Источник: https://dotnetcoretutorials.com/2022/03/22/using-sql-server-sequences-to-generate-unique-values/