Как генерировать осмысленные коммиты. Применяем стандарт Conventional Commits

Нет, не диктует. Но так принято в любом скрам тиме иначе как потом искать таск в жире или любом другом багтрекере?

Как генерировать осмысленные коммиты. Применяем стандарт Conventional Commits

Если вы делаете agile/scrum в команде, то любая story/задача/баг whatever, должна быть на канбан борде с уникальным номером. Как правило, мы в команде указываем номер story с тайтлом при коммите. Так что никаких вопросов не возникает у членов команды. А если же у вас каждый разраб делает комиты и никто потом не может понять что именно правилось и для чего, то здесь пару проблем. 1-ая — вы не делаете agile и каждый разраб получает задачи индивидуально, 2-ая — вы не делает pair programming/mobbing/code review в команде. И как результат, очень слабая коммуникация внутри команды.

REST-сервисы на ASP.NET Core под Linux в продакшене

Мне статья понравилась. Как раз сейчас смотрю в сторону контейнеров, сравниваю Azure Service Fabric vs Azure Containers Service.

Есть вопрос по поводу этого кода.

var data =
  await _remoteService.IOBoundOperationAsync(timeoutInSec: 1);
var result = new string[data.Count];
var tasks = data.Select(
  async (item, index) =>
    {
      var detailed =
        await _remoteService.IOBoundOperationAsync(timeoutInSec: 5);
      result[index] = string.Join(", ", detailed)
    });
  await Task.WhenAll(tasks);

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

Здесь мы делаем практически то же самое, но запускаем запросы к API уже параллельно, причем еще и асинхронно.

На сколько я понимаю, Вы запускаете этот код асинхронно (конкурентно) в одном потоке, но не параллельно (не много пототочно, если хотите). Так как метод IOBoundOperationAsync говорит сам за себя, что он IO bound, а не CPU bound. Соотвественно, он не создает новых потоков. Так же Task.WhenAll не создает новых потоков.

Я бы еще добавил throttling, таким образом распределив нагрузку CPU context switching при конкурентной обработке запросов к сервису. Иначе есть риск спайков под 100%, что CPU будет настолько загружен при обработке определенных запросов, что просто не сможет обрабатывать другие новые запросы пришедшие позже.