.NET Разработчик

День 1576. #ЗаметкиНаПолях
Загрузка Больших Файлов в ASP.NET Core. Начало
Недавно мы рассмотрели, как создавать большие файлы для тестов, сегодня посмотрим, как обрабатывать загрузку больших файлов в ASP.NET Core.

Потоки, как правило, лучше, чем использование byte[] или MemoryStream при обработке больших файлов по нескольким причинам:
- Потоки могут значительно сократить использование памяти, т.к. обрабатывают файл блоками, обеспечивая более эффективное управление памятью.
- Использование потоков также может повысить скорость обработки, позволяя одновременно читать и записывать файл.

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

1. Настройка Kestrel
Нужно настроить Kestrel в файле Program.cs, чтобы разрешить загрузку больших файлов:

builder.WebHost.ConfigureKestrel(opts =>
{
  opts.Limits.MaxRequestBodySize 
   = long.MaxValue;
});

Здесь long.MaxValue приведено для примера и позволяет загружать файлы практически любого размера. В реальности задайте значение, которое нужно вам. Также можно использовать атрибут RequestSizeLimit на отдельном методе действия.

2. Атрибуты валидации
Определим 2 атрибута фильтров действия для валидации контента.
1) MultipartFormDataAttribute проверит, что способом отправки является "multipart/form-data":

public class MultipartFormDataAttribute 
 : ActionFilterAttribute
{
  public override void 
   OnActionExecuting(
    ActionExecutingContext ctx)
  {
    var r = ctx.HttpContext.Request;
    if (r.HasFormContentType 
       && r.ContentType
        .StartsWith("multipart/form-data"))
      return;
 
    ctx.Result = new 
     StatusCodeResult(
      StatusCodes.Status415UnsupportedMediaType);
  }
}

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

public class DisableModelBindingAttribute : 
  Attribute, IResourceFilter
{
  public void OnResourceExecuting(
   ResourceExecutingContext ctx)
  {
    var f = ctx.ValueProviderFactories;
    f.RemoveType<FormValueProviderFactory>();
    f.RemoveType<FormFileValueProviderFactory>();
    f.RemoveType<JQueryFormValueProviderFactory>();
  }
}

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

Источник: https://code-maze.com/aspnetcore-upload-large-files/

День 1575. #DevOps #ProjectManagement
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Окончание
Начало

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

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

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

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

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

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

Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/

День 1574. #DevOps #ProjectManagement
Без Паники! Пособие по Управлению Любым Инцидентом в Продакшене. Начало
Независимо от того, насколько сильна ваша организация, насколько тщательно планирование и развертывание… всё когда-нибудь ломается. Системы выходят из строя, ключевые функции перестают работать, и в какой-то момент карьеры каждого разработчика возникает проблема.

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

Шаг 1. Не паникуйте и определите проблему
В один прекрасный день базовая функциональность приложения перестаёт работать. Команда разработчиков собирается в совещательной комнате, чтобы найти решение проблемы. Инстинктивная реакция: «Быстрее, откатывай всё назад!» Это понятное чувство, мы создали проблемы, и, естественно, есть желание от них избавиться. Но с быстрыми действиями приходят и быстрые ошибки, и более опытные разработчики здесь резонно зададут вопрос: «А почему не работает?». Да, вашей реакцией может быть: «Кого это волнует? Наша ошибка видна всему миру!» Но спокойный характер и аналитическая манера поведения успокоят команду и убедят, что то, что происходит в этой комнате, правильно: надо задавать вопросы и исследовать.

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

Также важно найти кого-то, кто займётся техническими вопросами и сможет помочь координировать усилия по исправлению (обычно это более старший разработчик), и кого-то, кто будет отвечать за «пиар для внешней среды» и «прикрытие с воздуха» тех, кто может захотеть потратить время на изучение ошибки (обычно это директор или технический руководитель). Это делается для защиты самого ценного ресурса во время кризиса: времени и внимания тех, кто действительно может реализовать план исправления.
Более технический специалист нужен, чтобы помочь разбить решение на этапы и делегировать или разделить работу, которую необходимо выполнить. А лидер инцидента (как его часто иронически называют) должен помогать, но не диктовать. Лучшие лидеры инцидентов задают два вопроса: «На каком этапе мы находимся?» и «Что вам нужно?», а также могут держать рассерженных пользователей подальше от специалистов, решающих проблему.

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

Источник: https://stackoverflow.blog/2023/05/03/dont-panic-a-playbook-for-managing-any-production-incident/

День 1573. #ЗаметкиНаПолях
Генерация Больших Файлов с Помощью PowerShell
Сегодня очень короткая заметка, которую захотел сохранить, чтобы найти её в ленте, когда понадобится.

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

# Здесь $pwd – текущий путь
$path = Join-Path $pwd "test.txt"
$size = 1GB
$content = New-Object byte[] $size
(New-Object System.Random).NextBytes($content)
# Set-Content очень медленный, поэтому
# используем метод .NET напрямую
[System.IO.File]::WriteAllBytes($path, $content)

Если вам нужен пустой файл (заполненный нулями), то в Windows можно просто использовать fsutil, что намного быстрее:

$size = 1GB
fsutil file createNew test.txt $size

Источник: https://www.meziantou.net/generate-large-files-using-powershell.htm

День 1572. #Карьера
3 Фразы, Которые Помогут Справиться с Эмоциями и Улучшить Отношения
Эмоциональные моменты могут заставить вас сказать или сделать то, о чём вы потом пожалеете. Сегодня рассмотрим три фразы, которые могут помочь.

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

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

1. Как противостоять пассивно-агрессивному поведению
Пассивная агрессия — это проявление негативных чувств, обиды и агрессии в неуверенной или «пассивной» манере. Это может проявляться в том, что человек заявляет, что с ним всё в порядке (когда очевидно, что это не так), начинает «играть в молчанку» или избегает конфронтации только для того, чтобы позже втихую саботировать планы. Необходимо противостоять пассивно-агрессивному поведению. С этим поможет фраза «Атакуйте проблему, а не человека.»

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

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

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

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

Чтобы справиться с этой проблемой, вы должны напомнить себе: «Проведите эксперимент.»
Это включает следующие шаги:
1. Исследуйте тему. Найдите разумное время, чтобы изучить ситуацию. Стремитесь рассмотреть вещи с разных сторон и познакомиться с разными точками зрения.
2. Определите основную проблему. Это то, что вы контролируете? Если нет, идите дальше. Если да, составьте список вариантов решения.
3. Сузьте список. Три варианта — хорошо, два - лучше.
4. Взвесьте все за и против. Составьте список положительных и отрицательных сторон, если это поможет увидеть вещи более ясно.
5. Установите дедлайн.
6. Выберите вариант и запустите эксперимент. Рассматривая это как эксперимент, вы напоминаете себе, что это не окончательное решение. Это выбор двигаться вперёд, а не стоять на месте.

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

Эмоции – это то, делает нас людьми. Ключ к эмоциональному интеллекту — заставить эмоции работать на вас, а не против вас.

Источник: https://www.inc.com/justin-bariso/emotional-intelligence-how-to-cope-communicate-improve-relationships.html

День 1571. #ЧтоНовенького
Новинки для Разработки API в .NET 8
В .NET 8 превью 4 представлены несколько новинок, которые могут упростить жизнь при разработке API.

1. Расширена поддержка привязки форм в минимальных API
Параметры отправленной формы выводятся без необходимости использования атрибута FromForm. Поддержка включает: IFormCollection, IFormFile и IFormFileCollection. Метаданные OpenAPI для параметров формы также выводятся автоматически для поддержки интеграции со Swagger UI.

В приведённом ниже примере кода демонстрируется реализация минимального API, который обрабатывает загрузку файлов, используя выведение параметра типа IFormFile:

var app = WebApplication.Create();

string GetPath(
 string fileName,
 string dir = "uploads")
{
  var dirPath = Path.Combine(
   app.Environment.ContentRootPath, 
   dir);
  Directory.CreateDirectory(dirPath);
  return Path.Combine(dirPath, fileName);
}

async Task Upload(
 IFormFile file,
 string fileName)
{
  var filePath = GetPath(fileName);
  await using var stream = 
   new FileStream(filePath, FileMode.Create);
  await file.CopyToAsync(stream);
}

app.MapPost("/upload", async (IFormFile file) => 
{
  var fileName = Guid.NewGuid().ToString("N") 
   + Path.GetExtension(file.FileName);

  await Upload(file, fileName);
  return TypedResults.Ok("Uploaded successfully!");
});

app.Run();

Эта функция поддерживается как в минимальных API, использующих генерацию кода во время выполнения, так и в минимальных API, использующих новую генерацию кода во время компиляции для сценариев Native AOT.

Примечание: При реализации форм в приложении важно защищаться от XSRF-атак. В этом расширенном примере показано, как использовать сервисы ASP.NET для создания и проверки маркеров защиты от подделки межсайтовых запросов в минимальных API.

2. Шаблон проекта API включает файл .http
Шаблон проекта API (созданный с помощью dotnet new api) теперь включает файл .http, который можно использовать для отправки запросов на конечные точки, определённые в приложении, из нового редактора HTTP в Visual Studio.

@MyApi_HostAddress = http://localhost:5233

GET {{MyApi_HostAddress}}/todos/
Accept: application/json

###

GET {{MyApi_HostAddress}}/todos/1
Accept: application/json

###

Коротко про редактор HTTP в Visual Studio рассказывается в этом видео.

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

День 1570. #ЗаметкиНаПолях
Избегайте Распространения DbContext или IQueryable в Приложениях. Окончание
Начало

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

Более того, код за пределами уровня данных может даже не знать, что он имеет дело с IQueryable, потому что IQueryable наследует IEnumerable. Методы могут работать с IEnumerable, ожидая поведения только в памяти, но на самом деле манипулируя деревом выражений IQueryable. Это может привести к неожиданным исключениям во время выполнения, особенно если результаты фильтруются с использованием кода, который EF не может преобразовать в SQL (например, пользовательской функции). Страдает понимание кода, а также отладка, устранение неполадок и тестирование. Место IQueryable - на уровне данных. В репозитории допустимо использование IQueryable, при условии, что он не является частью абстракции или публичного интерфейса типа.

Поскольку DbContext или DbSet<T> можно использовать для получения IQueryable в любое время, передача их за пределы уровня данных имеет такое же (негативное) влияние на разделение ответственности и инкапсуляцию, что и передача IQueryable<T>.

Какая есть альтернатива?
Во-первых, вы можно передавать дерево выражений в сервис данных и использовать его:

public IOrderRepository
{
  List<Order> List(
   Expression<Func<Order,bool>> filter);
}

Вы создаёте фильтр заранее, он исполняется в сервисе данных, а возвращаемый результат – данные в памяти.

Ещё лучше использовать паттерн Спецификация. В этом случае вместо передачи LINQ-выражения вы передаёте экземпляр спецификации, а выражение строится в ней:

public IOrderRepository
{
  List<Order> List(
   Specification<Order> spec);
}

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

public class ShippedOrdersForUserSpec :
 Specification<Order>
{
  public ShippedOrdersForUserSpec(
   string username)
  {
    Query.Where(o => !o.Canceled &&
      o.CreatedBy == username &&
      o.Shipped);
  }
}

// в контроллере/на странице
var spec = new ShippedOrdersForUserSpec(username);
var viewModel = await _repo.ListAsync(spec);

Таким образом запрос по-прежнему выполняется в базе данных, но IQueryable больше не используется нигде за пределами реализации репозитория. Вы можете посмотреть на использование этого паттерна в примере eShopOnWeb (см. папку /src/ApplicationCore/Specifications/).

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

Источник: https://ardalis.com/avoid-dbcontext-iqueryable-proliferation/

День 1569. #ЗаметкиНаПолях
Избегайте Распространения DbContext или IQueryable в Приложениях. Начало
Большинство приложений .NET используют EF Core и DbContext для доступа к данным, но удобство сопровождения может пострадать, если использование DbContext или производного от него IQueryable распространяется по всему приложению.

Интерфейсы IQueryable и IQueryable<T> в .NET позволяют описывать запросы в виде деревьев выражений, которые при выполнении преобразуются провайдером в запросы к БД. В EF IQueryable используется, чтобы создавать динамические SQL-запросы, что позволяет выполнять детальные и эффективные запросы к базе данных, а не извлекать больше данных, чем необходимо, в память приложения, а затем фильтровать результат в памяти.

Ниже создаётся набор заказов, отфильтрованных по дате. В первом примере все заказы из БД передаются в приложение, а затем фильтруются. Во втором используется динамический SQL-запрос, позволяющий БД возвращать только совпадающие записи:

var since = new DateTime(2023,1,1);

// фильтрация в памяти
var all = dbContext.Orders.ToList();
var recent1 = all
  .Where(o.Date > since)
  .ToList();

// фильтрация в БД
var recent2 = dbContext.Orders
  .Where(o.Date > since)
  .ToList();

Очевидно, что скорость и эффективность второго подхода почти всегда делают его предпочтительным методом.

Можно создать выражение IQueryable с помощью серии операторов, даже в разных функциях, классах или проектах. Когда об этом было впервые объявлено, в Microsoft высоко оценили эту возможность, т.к. разработчики могли создавать нужный запрос «по требованию», где бы им это ни требовалось, гарантируя, что при окончательном выполнении запроса будут возвращены только необходимые данные. У вас может быть сервис, возвращающий «чистые» данные:

public class DataService
{
  public async 
   Task<IQueryable<Order>> List()
  {
    return await 
     _dbContext.Orders.AsQueryable();
  }
}

Сервис бизнес-логики, который накладывает некоторые ограничения на выборку:

public class OrderService
{
  // сервис данных внедряется в _dataService
  public async 
   Task<IQueryable<Order>> ActiveOrders()
  {
    var all = await _dataService.List();
    return await all
      .Where(o => !o.Canceled)
      .AsQueryable();
  }
}

Затем в контроллере добавляется фильтр текущего пользователя:

var viewModel =
  await _orderSvc.ActiveOrders()
    .Where(o => o.CreatedBy = username)
    .AsQueryable();

Наконец, на странице в коде Razor мы генерируем окончательный список:

foreach(var ord in
 model.Orders.Where(o => o.Shipped()))
{
  // список в HTML
}

В итоге у нас получается следующий запрос, который будет выполнен:

_dbContext.Orders
  .Where(o => !o.Canceled &&
    o.CreatedBy == username &&
    o.Shipped);

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

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

Источник: https://ardalis.com/avoid-dbcontext-iqueryable-proliferation/

День 1568. #Книги
Сегодня мне пришла книга, над переводом которой я работал совместно с сообществом DotNetRu. Кристиан Венц «Безопасность ASP.NET Core» — М.: ДМК Пресс, 2023.

Я уже участвовал в переводе нескольких книг, эта стала третьей. В этот раз, к сожалению, не получилось вычитать всё, как в случае с книгой "Entity Framework Core в действии", поэтому отложил её в очередь для чтения.

День 1567. #ЗаметкиНаПолях
Проверяем Правильность Архитектуры ПО с Помощью Тестов
Архитектура ПО — это план того, как структурировать систему. Вы можете строго или не очень строго следовать ему. Но когда сроки поджимают, и вы начинаете срезать углы, созданная вами прекрасная программная архитектура рассыпается, как карточный домик.

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

Архитектурные тесты пишутся так же, как и любой модульный тест. Есть отличная библиотека для создания архитектурных тестов, в которой уже реализован шаблонный код - NetArchTest.Rules.

Отправной точкой для написания архитектурных тестов является статический класс Types, который можно использовать для загрузки набора типов. После этого их можно дополнительно отфильтровать. Некоторые из доступных методов фильтрации:
- ResideInNamespace
- AreClasses
- AreInterfaces
- HaveNameStartingWith
- HaveNameEndingWith

Наконец, вы можете написать правило, которое хотите применить, вызвав Should или ShouldNot и применив условие, которое хотите проверить. Вот пример проверки того, что все классы домена запечатаны:

var result = Types
  .InAssembly(DomainAssembly)
  .That()
  .AreClasses()
  .Should()
  .BeSealed()
  .GetResult();
Assert.True(result.IsSuccessful);

Архитектурные тесты особенно полезны для проверки соблюдения правил архитектуры ПО в многоуровневой архитектуре или модульном монолите.
- Домен не должен иметь никаких зависимостей:

var result = Types
  .InAssembly(DomainAssembly)
  .ShouldNot()
  .HaveDependencyOnAny("Application", "Infrastructure")
  .GetResult();
Assert.True(result.IsSuccessful);

- Приложение не должно зависеть от Инфраструктуры:

var result = Types
  .InAssembly(AplicationAssembly)
  .Should()
  .NotHaveDependencyOn("Infrastructure")
  .GetResult();
Assert.True(result.IsSuccessful);

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

var result = Types
  .InAssembly(InfrastructureAssembly)
  .HaveNameEndingWith("Repository")
  .Should()
  .HaveDependencyOn("Domain")
  .GetResult();
Assert.True(result.IsSuccessful);

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

var result = Types
  .InAssembly(ApiAssembly)
  .That()
  .HaveNameEndingWith("Controller")
  .ShouldNot()
  .HaveDependencyOn("Infrastructure.Repositories")
  .GetResult();
Assert.True(result.IsSuccessful);

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

Источник: https://www.milanjovanovic.tech/blog/enforcing-software-architecture-with-architecture-tests

День 1566.
Мониторинг и Производительность Entity Framework. Вопросы и Ответы.
Окончание
Начало

4. Профилирование взаимодействий с базой данных с помощью EF: что нужно и как это помогает?
В зависимости от вашей платформы и среды существует ряд бесплатных и коммерческих инструментов профилирования. От SQL Profiler (или соответствующего расширения для Azure Data Studio), Intellitrace и Application Insights до сторонних модулей, таких как EPFrof, OrmProfiler и MiniProfiler.
В некоторых случаях поддержка инструментов может быть добавлена без изменения кода вашего приложения, в других случаях требуется разместить в приложении небольшие хуки для перехвата. Кроме того, некоторые из более поздних инструментов облегчают нахождение строки кода, вызывающей запрос. Это может быть неоценимо при попытке выяснить, откуда взялся надоедливый плохо выполняющийся запрос.

5. Каковы плюсы и минусы работы без хранимых процедур?
Многие сторонники хранимых процедур рекламируют возможности, которые они привносят с точки зрения компиляции и кэширования запросов, а также параметризации. При этом они создавали динамические запросы внутри хранимых процедур, полностью нивелируя эти преимущества. EF генерирует запросы, которые можно кэшировать и которые гарантированно будут параметризованы (если только вы не используете FromSqlRaw). В результате использование EF может быть столь же эффективным и безопасным, как и хранимые процедуры.
Кроме того, вы получаете возможность менять провайдера базы данных, не переписывая все запросы. Или при добавлении столбца в таблицу, с EF вы добавляете только свойство в модель объекта. Для хранимых процедур также потребуется управление изменениями схемы таблиц и несколько изменений хранимых процедур (для операций CRUD).
Иногда необходимо использовать хранимые процедуры. Некоторые платформы предлагают определённые функции, которые LINQ может не поддерживать (подсказки запросов, иерархии, геопространственные данные, массовое копирование и т. д.), и для них может потребоваться нативный код. В более новых версиях EF устранены некоторые из этих пробелов. Если вы будете следовать правилу 80/20, используя EF, где это возможно, а где необходимо - хранимые процедуры или другие функции, специфичные для платформы, вы часто сможете найти подход, который хорошо работает для всех сценариев приложений.

6. С какими проблемами сталкиваются организации или команды при начале работы с EF?
Проблема чаще всего не технологическая, а человеческая. Для новых приложений внедрение новых технологий часто проще. Для существующих, которые создавались годами, часто приходится полагаться на то, что универсальная среда может быть такой же хорошей (или лучше), чем созданная командой за эти годы. Некоторые из таких приложений были специально созданы для передачи таких структур ADO, как DataSets и DataTables, в пользовательский интерфейс. Попытка обосновать рентабельность инвестиций в модернизацию уровня данных в таких обстоятельствах часто может быть затруднена.
Другая типичная проблема также сводится к доверию между инженерными командами и группами поддержки (часто между разработчиками и администраторами баз данных). Группы поддержки вызываются в 3 часа ночи, когда система даёт сбой из-за плохо выполняющегося запроса, который загружает ЦП сервера базы данных. Аргумент здесь в том, что, если бы запрос был абстрагирован в хранимую процедуру, они имели бы контроль над его изменением, а не заставляли разработчиков вносить изменения в код. Это можно смягчить, используя наборы тестов производительности с соответствующим охватом и просматривая сгенерированные запросы в течение циклов разработки. Этот подход требует общения между командами для установления большего доверия с течением времени.

Источник: https://visualstudiomagazine.com/articles/2023/04/05/ef-performance.aspx

День 1565.
Мониторинг и Производительность Entity Framework. Вопросы и Ответы. Начало
ORM-технологии, такие как Entity Framework, могут значительно упростить модель программирования для баз данных, но при небрежном исполнении может пострадать производительность. Чтобы этого не произошло, разработчики используют мониторинг, профилирование взаимодействия с БД и тонкую настройку запросов. Джим Вули, архитектор решений в Slalom Consulting делится своими знаниями о том, как максимально эффективно использовать EF.

1. Как ORM могут упростить модель программирования для баз данных?
Инструменты ORM, такие как EF, избавляют разработчиков от необходимости беспокоиться об управлении коммуникациями между приложением и базой данных и позволяют им сосредоточиться на добавлении ценности для бизнеса безопасным для типов способом (через LINQ). Разработчикам не нужно беспокоиться об управлении подключениями к базе данных, обновлении хранимых процедур для каждой операции или изучении тонких различий между различными диалектами SQL (TSQL, PLSQL, pgSQL и т. д.). Пока необходимо извлечь объект или граф объектов, внести изменения в эту структуру и обновить ее, инструменты OR/M могут легко обрабатывать 80-90% вариантов использования, не вызывая проблем с производительностью. Кроме того, по мере развития платформы находятся всё новые средства оптимизации производительности, и разработчики могут ими воспользоваться, просто обновив версию.

2. Какие распространённые ошибки допускают разработчики при использовании EF?
Инструменты ORM уменьшают потребность в ручном управлении, но по-прежнему необходимо следить за утечками, которые могут вызвать серьёзные проблемы в будущем. Однажды у меня был клиент, который столкнулся с проблемой производительности. Как оказалось, проблема была вызвана ленивой загрузкой дочерних записей на четыре уровня ниже во вложенных циклах. Помните о действиях, вызывающих запросы к базе, таких как foreach, First, Any, Sum, Count. С другой стороны, применяя дополнительную фильтрацию к возвращённому IEnumerable, надо понимать, что она выполняется в памяти, а не в базе данных.
Также нужно немного знать о настройке и индексировании базы данных, а также о влиянии ваших запросов на индексы. Например, если вы используете метод .Include() для выборки связанных дочерних записей, он будет включать все дочерние столбцы как часть запроса и, таким образом, будет игнорировать покрывающие индексы, то есть выполняться неоптимально.
Более тонкие проблемы могут возникнуть, когда разработчики пытаются применить вычисления дат в предложениях Where или не сопоставляют строки ANSI с типами данных varchar. В обоих случаях индексирование, которое, как вы думали, вы используете, может быть недоступно, и в результате вы получаете медленное полное сканирование таблицы.
Во всех этих случаях внимание, выявление плохо работающих запросов и их профилирование для определения необходимых изменений — это первый шаг к обеспечению хорошей работы приложения.

3. Как мониторинг производительности и настройка могут улучшить ситуацию?
Наличие набора тестов, который вы можете использовать для мониторинга производительности, — это первый шаг. Так вы сможете идентифицировать запросы или участки кода, которые плохо работают и нуждаются в настройке. Настройка без мониторинга часто приводит к преждевременной оптимизации. Даже с EF в .Net Framework, хотя запросы, сгенерированные EF, могли выглядеть довольно неприятно, планы выполнения, сгенерированные базой данных, могли генерировать такие же хорошие или, в некоторых случаях, лучшие запросы, чем вы могли бы написать сами.
Только после выявления проблемных запросов вы можете настроить или, в некоторых случаях, переосмыслить задачу для достижения той же конечной цели. Настройка производительности приложений во многом является искусством, и редко существует универсальный подход, который решит эту проблему. Вы должны попробовать несколько стратегий, чтобы выяснить, что лучше всего подходит для данного случая.

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

Источник: https://visualstudiomagazine.com/articles/2023/04/05/ef-performance.aspx

День 1564. #ЗаметкиНаПолях
Утечки Памяти в C#
Утечка памяти в C# происходит, когда приложение неоднократно выделяет память, но не освобождает её даже после того, как память выполнила своё предназначение. В результате приложение постепенно использует всё больше памяти с течением времени, что в итоге может привести к сбою приложения или прекращению его работы. Ошибки программирования включают в себя неспособность освободить объекты, которые больше не нужны, или хранение ссылок дольше, чем необходимо, что может привести к утечке памяти. Циклические ссылки на объекты, неправильное использование структур данных, таких как списки и словари, а также неправильная обработка исключений — вот лишь некоторые из причин этих ошибок.
Сегодня рассмотрим различные ситуации утечки памяти.

1. Использование статических объектов.
Когда мы используем статический класс, переменные будут доступны на протяжении всего жизненного цикла приложения. Мы должны быть очень осторожны, когда используем статические переменные/классы. Это связано с тем, что сборщик мусора не собирает статические объекты и всё, на что они ссылаются. Не используйте ключевое слово static, если в этом нет необходимости.

2. Длительный поток.
Если мы работаем с долго выполняющимся потоком или бесконечным циклом в потоке, поток будет удерживать объект в течение длительного времени. Если объект хранится долгое время, сборщик мусора думает, что объект используется, и не будет очищать память. Всегда устанавливайте условие выхода из цикла.

3. Кэширование.
Это очень хорошая стратегия для повышения производительности приложения. Но если мы используем кэширование во всех областях приложения, это приведёт к избыточному кэшированию и нехватке памяти. Всегда полезно кэшировать только часто используемые объекты.

4. Использование неуправляемых объектов.
Работа с файловой системой ОС — один из лучших примеров неуправляемых объектов. Если мы собираемся использовать файловую систему, мы должны правильно избавляться от всех объектов после завершения работы. В противном случае, поскольку сборщик мусора не очищает их, это приведёт к утечке памяти.

5. Ручная реализация шаблона IDisposable.
Всегда используйте метод Dispose в классе, который реализует интерфейс IDisposable. В противном случае может произойти утечка памяти. Конструкция using, которая вызывает метод Dispose для каждого экземпляра, является лучшим подходом для достижения этой цели. Если вы не можете использовать оператор using, не забудьте сделать это вручную и подавить метод finalize, так как он не требуется.

GC.SuppressFinalize();

Если мы используем интерфейс IDisposable, мы вручную освобождаем объект с помощью метода Dispose. Finalize — это метод автоматического управления памятью, вызываемый сборщиком мусора для удаления неиспользуемых объектов. Поэтому при ручной очистке он не требуется.

Источник: https://dev.to/arunkumar2331996/memory-leaks-in-c-3koj

День 1563. #Карьера
Совещания Делают Вас Менее Продуктивными?
Согласно исследованию SurveyMonkey, 32% людей считают, что то, что было на совещании, могли бы прислать в e-mail. Скорее всего, где бы вы ни работали, вы не устраивались в эту компанию ради совещаний. Вы хотели создавать ПО. Но митинги стали частью процесса, и чем выше ваша позиция, тем больше встреч вас, вероятно, приглашают посетить. Сегодня рассмотрим влияние совещаний на продуктивность и способы сделать их лучше (или вообще избежать их).

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

Все эти недостатки совещаний могут заставить вас задаться вопросом, зачем вообще их проводить?

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

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

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

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

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

Необходимы перерывы между совещаниями, если их несколько в день. Также исследование Human Factors Lab в Microsoft обнаружило, что дни без совещаний улучшают общую коммуникацию, а продуктивность снижается, если разработчик проводит более двух совещаний в день.

Все исследования свидетельствуют в пользу того, чтобы проводить меньше встреч. Хотя они по-прежнему иногда необходимы. Dropbox использует систему 3D: решения (decisions), дебаты (debates) и обсуждение (discussion). Это действия, для выполнения которых люди должны сотрудничать. Всё остальное можно подать другими способами.

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

Источник: https://stackoverflow.blog/2023/04/12/are-meetings-making-you-less-productive/

День 1562. #BestPractices
Лучшие Практики Безопасного Развёртывания и Масштабирования Приложений. Окончание
Начало
Продолжение

7. Добавьте эксперименты и A/B-тестирование
При добавлении каких-либо изменений, таких как новая функция или изменение UX, отлично подходит A/B-тест, чтобы убедиться, что изменение является положительным и не создаёт никаких проблем. Добавьте механизм для разделения ваших пользователей на 2 или более групп и запускайте для них разный код. Контролируйте обе группы эксперимента: контрольную и экспериментальную (группу A и группу B). Есть ли увеличение в журналах ошибок? Как насчёт всплесков жалоб от клиентов? Проверьте информационные панели, есть ли аномалии?
Такие эксперименты отлично подходят для выявления проблемных изменений, если у вас есть хороший способ сопоставить телеметрию с экспериментальными группами. Нужно просто при запуске сессии регистрировать все сессии экспериментальной группы, а затем сопоставлять их с проблемными сессиями.

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

9. Тестируйте
Тесты оставлены напоследок, потому это вроде бы и очевидно, но тем не менее важно и о них нужно упомянуть.
Одним из самых важных механизмов, позволяющих убедиться, что следующее развёртывание не сломает ничего существенного, является набор тестов. Это должно быть стандартной практикой в наши дни, но множество проектов даже сейчас всё ещё существуют без них. Когда у вас есть тесты, обязательно применяйте их, что обычно означает добавление политики в пулл-реквесты, которая гарантирует, что все тесты пройдены.
Когда у вас есть непрерывный процесс интеграции, пришло время рассмотреть стратегию тестирования. Вы стремитесь к определённому уровню покрытия кода? Все ли новые функции требуют некоторого количества тестов? Автоматически применять такие правила сложно, но всё же полезно определить политику для команды и попытаться следовать ей самостоятельно и при обзорах кода.
Помимо модульных тестов, хорошо иметь приличное количество интеграционных и сквозных тестов. Они не определят основную причину, если тест не пройдёт, но отлично подойдут для обнаружения ошибок и проверки работоспособности вашей системы в целом. Модульные тесты, как правило, легко ломаются при рефакторинге или изменении поведения, даже если система работает так, как ожидалось, в то время как сквозные тесты обычно остаются нетронутыми, если вы не вносите ошибки. Можно даже удалить некоторые или большинство модульных тестов после завершения разработки и оставить только интеграционные и E2E-тесты. Или, по крайней мере, будьте гибкими, чтобы со временем отказаться от модульных тестов в пользу более глобальных.

Источник: https://michaelscodingspot.com/safe-application-deployment/

День 1561. #BestPractices
Лучшие Практики Безопасного Развёртывания и Масштабирования Приложений. Продолжение
Начало

3. Добавьте оповещения телеметрии, когда что-то идёт не так
Добавление журналов и информационных панелей — это здорово, но полагаться на то, что кто-то всегда будет их просматривать, обречено на провал. Лучший способ обеспечить наблюдаемость — автоматизировать аномалии. Автоматизируйте информационные панели, чтобы отправлять оповещения, когда что-то идёт не так. Если есть серьёзное замедление продолжительности запросов, вы захотите узнать об этом как можно скорее. То же касается роста количества записей в журналах ошибок и сбоев процессов. Практически всё, за чем вы стараетесь следить, стоит автоматизировать для уведомлений в случае возникновения проблемы. Большинство инструментов, предоставляющих отчеты и визуализацию информационных панелей, также имеют функции оповещения, включая Kibana, Azure Monitor и Datadog.

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

5. Дежурные инженеры
Добавление телеметрии, отзывов клиентов и информационных панелей не очень полезно, если за ними никто не следит. На определённом этапе роста компании обычно вводят какую-либо политику ротации дежурств. Это так же просто, как назначить еженедельные или ежемесячные смены среди ваших инженеров. Во время смены дежурный отвечает за любые соответствующие оповещения и уведомления, активно просматривает информационные панели работоспособности приложений и реагирует на аномалии. Обычно дежурный инженер не решает проблему, а только назначает её соответствующему разработчику или устраняет её, отключая некоторые функции или, возможно, перезапуская какой-либо сервер.
Вы можете выбрать альтернативный путь - иметь постоянных инженеров по надёжности (Site Reliability Engineer, SRE). Подход с ротацией предпочтительнее в том, что разработчики лучше знают, что происходит в коде, и одни и те же люди следят за работоспособностью приложения и устраняют проблемы. Это может усилить их чувство ответственности.

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

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

Источник: https://michaelscodingspot.com/safe-application-deployment/

День 1560. #BestPractices
Лучшие Практики Безопасного Развёртывания и Масштабирования Приложений. Начало
Кодовая база приложения — живой объект. Она растёт, меняется и приспосабливается. Всегда есть новая функция, которую нужно добавить, ошибки, которые нужно исправить и которые создаются в результате. По мере роста проекта код меняется чаще, появляется все больше функций, больше проблем и больше ошибок. Ручное тестирование становится невозможным. Как убедиться, что приложение остаётся работоспособным, что развёртывание ничего не сломало? Автоматизировать. Вот лучшие практики, позволяющие быстро развёртывать изменения и поддерживать высокое качество приложения.

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

if (IsFeatureFlagEnabled(
  "MyNewFeature",
  defaultValue: false))
{
 //…
}

Фактические значения флагов функций могут находиться в какой-либо удалённой БД или сервисе, которым вы можете управлять. Можно разработать их самостоятельно или использовать инструмент вроде LaunchDarkly, который сохраняет значения флагов функций, предоставляет API для их получения и UI, позволяющий легко их изменять.
Функция может быть защищена флагом «высокого уровня», который отключает всё, и флагами «низкого уровня», которые контролируют более мелкие части функции. Можно ввести политику, согласно которой каждое изменение кода должно быть защищено флагом функции.
Флаги функций упрощают разработку. Вместо того, чтобы иметь побочную ветку, которую команда разработчиков хранит отдельно в течение нескольких месяцев, можно работать в «основной» ветке, но отключить функциональность с помощью флага функции.
Кстати, со временем не забывайте удалять флаги устоявшихся функций, прежде чем код станет нагромождением условных операторов.

2. Добавьте телеметрию для обнаружения регрессий
Ключевой частью понимания того, что приложение работает должным образом, является возможность наблюдать за тем, что происходит. Вы хотите узнать как можно скорее, когда что-то пойдёт не так. Этот вид мониторинга проявляется во многих формах:
- Журналы ошибок. Добавляйте их во все приложения. Если есть исключение или неожиданное поведение регистрируйте его. Всплеск числа ошибок в журнале быстро указывает на наличие проблемы и определяет ее основную причину.
- Телеметрия времени выполнения. Это может быть время выполнения операции, время выполнения запроса или что-либо ещё, что вы можете измерить. Его легко отслеживать, и вы можете быстро обнаруживать аномалии, такие как зависшие запросы и низкая производительность. Кстати, уменьшение времени выполнения также может указывать на то, что что-то пошло не так. Можно регистрировать время выполнения самостоятельно с помощью журналов приложений или использовать счетчики производительности или инструменты вроде Azure Monitor.
- Телеметрия сбоев. Сбои — это плохо, и вы хотите узнавать о них как можно скорее. Надёжная система сообщения о сбоях будет иметь большое значение. Можно разработать собственные или использовать инструменты для создания отчетов о сбоях, такие как Raygun.
- Панели мониторинга приложений. Информационные панели хороши тем, что картинка стоит тысячи слов. Простая информационная панель может быстро показать, что что-то пошло не так. Вы можете отображать время выполнения запроса, использование ЦП и памяти, частоту сбоев и т. д. Чем больше, тем лучше. Если вы можете визуально увидеть всплеск или падение, вы быстро обнаружите проблему, которую можете исправить, прежде чем она серьёзно повлияет на бизнес. Существуют отличные инструменты для создания панелей мониторинга, включая Azure Data Explorer, Grafana и DataDog.

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

Источник: https://michaelscodingspot.com/safe-application-deployment/

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

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

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

3. Карьерные планы, не связанные с текущей вакансией
В продолжение предыдущего пункта. Если вас спросят, где вы видите себя через пять лет, отвечать, что вы хотите сменить сферу деятельности либо открыть собственный бизнес – не лучшая идея. Работодателю нужен ресурс, на который можно рассчитывать в долгосрочной перспективе. А ваше желание в скором времени сменить карьерный путь может означать, что вы не полностью будете отдаваться работе.

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

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

6. Сколько вы собираетесь отработать на этом месте
Этот пункт в некотором роде связан с п.3. Не стоит сообщать, что вы собираетесь отработать Х лет и уйти на заслуженный отдых (даже если это так). Многие работодатели ищут кандидатов с потенциалом роста либо на более долгий срок, чем вы рассчитываете, поэтому раскрытие того, что кандидат собирается «отбыть срок» и уйти, может сильно навредить.

7. Проблемы со здоровьем
Понятно, что, если проблема со здоровьем мешает вам выполнять ваши обязанности, о ней стоит сообщить. Об остальном, если вас напрямую не спрашивают, лучше не распространяться, чтобы опять же не вызывать ненужную предвзятость у интервьюера.

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

Источник: https://www.youtube.com/watch?v=eza-l-kBK40

День 1558. #МоиИнструменты
WireMock.NET
Я как-то рассказывал про библиотеку Alba, которая позволяет проводить интеграционное тестирование API. Сегодня же расскажу вам про утилиту, позволяющую тестировать клиентов API и имитировать HTTP-запросы.

WireMock.NET — это .NET-версия WireMock, библиотеки для заглушек и имитации HTTP-сервисов. С WireMock.NET вы можете определить ожидаемые ответы для конкретных запросов, а библиотека будет перехватывать и управлять этими запросами для вас. Это позволяет легко тестировать код, выполняющий HTTP-запросы, не полагаясь на фактическую доступность внешнего сервиса и не взламывая HttpClient.

После установки nuget-пакета вы можете начать использовать WireMock.NET, создав экземпляр класса WireMockServer и настроив его на желаемое поведение. Это можно легко сделать, вызвав метод WireMockServer.Start или WireMockServer.StartWithAdminInterface:

using var wireMock = 
 WireMockServer.Start(port: 1080, ssl: false);

Теперь можно начать определять моки для внешних HTTP-запросов, в том числе, используя Fluent API:

wireMock
 .Given(
   Request.Create()
    .WithPath("/foo")
    .UsingGet()
 )
 .RespondWith(
   Response.Create()
    .WithStatusCode(200)
    .WithHeader("Content-Type", 
      "application/json; charset=utf-8")
    .WithBodyAsJson(new 
      { msg = "Hello world!" })
 );

В тестах легко написать проверку результатов HTTP-запроса:

[Fact]
public async Task sample_test()
{
  var response = await new HttpClient()
   .GetAsync($"{_wireMock.Urls[0]}/foo");

  Assert.Equal(HttpStatusCode.OK,
   response.StatusCode);
  Assert.Equal(
   """{"msg":"Hello world!"}""", 
   await response.Content.ReadAsStringAsync());
}

Замечание: в реальном приложении, конечно, тестироваться будут не собственно HTTP-ответы, а код, обрабатывающий эти ответы.

WireMock.NET предлагает множество функций, помимо базовых заглушек и имитаций HTTP-запросов:
1. Прокси-запросы к реальному сервису и захват ответов в виде маппинга. Вы можете использовать их в качестве основы для своих заглушек, устраняя необходимость в ручном определении ответов.
2. Чтение маппингов и определение заглушек из статических файлов, вместо того, чтобы определять их программно. Это может быть полезно для совместного использования заглушек в разных тестах или проектах.
3. Создание динамических шаблонов ответов, которые включают данные из запроса. Это позволяет создавать ответы, которые различаются в зависимости от данных запроса, что может быть полезно для тестирования пограничных случаев или моделирования поведения реального сервиса.
4. Моделирование поведения сервиса с помощью сценариев и состояний. Вы можете легко имитировать различные состояния сервиса и переключаться между ними. Это может быть полезно для проверки того, как ваш код обрабатывает различные типы сбоев или ответов от сервиса.

Узнать больше о возможностях WireMock.NET можно на странице WireMock Wiki.

Источник: https://cezarypiatek.github.io/post/mocking-outgoing-http-requests-p1/