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

1. Эффективная коммуникация
Умение хорошо объяснять ваши идеи другим.
Создание ПО - командный вид спорта. Команда состоит из людей с разным опытом, убеждениями, предубеждениями и знаниями. Если вы хотите создать хороший продукт, вы должны хорошо работать вместе. Система, которую вы разрабатываете, будет имитировать структуру коммуникации вашей организации: плохое общение между членами команды приведет к плохо спроектированным продуктам.
Лучшие разработчики грамотно доносят сложные технические концепции нетехническим людям или младшим специалистам. Вы далеко пойдёте как разработчик, если сможете эффективно общаться и учить других.

2. Эмпатия
Умение ставить себя на место пользователей.
Разработчик должен руководствоваться предназначением своего продукта. Конечно, интересно изучать новые технологии или копаться в последних инструментах разработки, но как насчёт того, почему именно важна наша работа?
Лучшие разработчики заботятся о цели, ради которой они создают ПО, и стремятся понять людей, которым помогают. Существует распространённое упражнение по управлению продуктом под названием «Сопоставление интересов», которое направлено на чёткое определение того, как пользователь думает, чувствует и взаимодействует с продуктом. Понимая поведение и чувства пользователей, мы можем создать продукт, который они будут действительно использовать по назначению.
Слишком часто продукты создаются без предварительного разговора с пользователями. Даже если вы разработчик в команде, понимание того, как думает ваш пользователь, приведёт к улучшению качества продукта.

3. Креативность
Умение искать решения.
Одна из величайших сверхспособностей любого разработчика - это способность гуглить. Когда появляется нерешаемая проблема, креативный разработчик знает, что решение, вероятно, уже существует. А когда этого не происходит, он не боится провести мозговой штурм по поиску нового решения.
Решение проблем требует обдумывания. Оно не приходит свыше, только чтобы бездумно его закодировать. Вы должны исследовать возможности, взвешивая различные технологии и навыки своей команды. После получения некоторого опыта, позволяющего понять, какие технологии существуют, придумать, как объединить эти решения становится проще.

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

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

Источник: https://betterprogramming.pub/5-soft-skills-you-need-to-succeed-as-a-developer-357f7eac3372
Автор оригинала: Marisa Hoenig

День 1028. #Microservices
Хватит Использовать Микросервисы. Создавайте Монолиты
Микросервисы могут показаться идеальным решением. Теоретически они увеличивают скорость разработки, позволяя независимо масштабировать различные части вашего приложения. Но на самом деле микросервисы сопряжены со скрытыми расходами. Трудно по-настоящему оценить их сложность, не попробовав создать приложение на микросервисах. Вот с чем приходится сталкиваться.

1. Управление данными превращается в кошмар
Синхронизация данных между микросервисами может быть сложной задачей.
База данных на микросервис - рекомендуемый шаблон. Он обеспечивает слабую связь и позволяет командам, специализирующимся на конкретных сервисах, работать независимо. Но что произойдёт, если один из микросервисов выйдет из строя? Например, один микросервис обновляет свою базу данных, а другой - нет. Подобные ситуации приводят к несогласованности данных. Поиск несоответствий данных между сервисами может быть болезненным. Придётся работать с несколькими сервисами, чтобы исправить ошибку. Это сразу сводит на нет одно из преимуществ – разделение на команды. Такую же ситуацию в монолитном приложении можно было бы легко предотвратить, заключив оба вызова БД в одну атомарную транзакцию. Слабая связь микросервисов усложняет задачу.

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

3. Микросервисы лучше всего подходят для больших команд
Хотя это одно из самых разрекламированных преимуществ микросервисов, вохможность выделить команду на микросервис есть только тогда, когда у вас достаточно специалистов, чтобы выделить несколько инженеров для каждого сервиса. Уменьшение объёма кода позволяет разработчикам лучше понимать код и увеличивает скорость разработки. Но у большинства стартапов этого нет. Тогда некоторым инженерам приходится работать со всеми сервисами. Это снижает производительность, из-за постоянного переключения контекста. А поиск ошибок в микросервисах, над которыми давно не работал, очень утомителен.

4. DevOps усложняется
Одна из наиболее веских причин для выбора микросервисов - это возможность запускать разные сервисы на разных типах серверов. Например, React имеет требования к памяти, процессору и времени безотказной работы отличные от сервиса машинного обучения. Это может значительно снизить затраты. Но тут есть свои проблемы. Например, можно потерять данные, просто забыв обновить один из сервисов. Настройка, обслуживание и мониторинг нескольких микросервисов требует больше усилий по сравнению с одним монолитным приложением. Теоретически «слабосвязанные» сервисы позволяют каждому сервису продолжать работу в случае отказа других. Но это принятие желаемого за действительное: истинная слабая связь редко возможна для сложного бизнеса.
В конце концов, архитектура вашего приложения настолько надежна, насколько надежна ее самая слабая часть. Чем больше движущихся частей, тем больше вероятность ошибки.

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

Источник: https://betterprogramming.pub/stop-using-microservices-build-monoliths-instead-9eac180ac908

День 1029. #ЗаметкиНаПолях #AsyncTips
Создание асинхронных потоков

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

Решение
Возвращение нескольких значений из метода может осуществляться командой yield return, а асинхронные методы используют async и await. Асинхронные потоки (асинхронные перечисления) объединяют эти два подхода. Используйте возвращаемый тип IAsyncEnumerable<T>. В следующем примере асинхронно перебираются результаты API, использующего параметры для страничной организации результатов:

async IAsyncEnumerable<string> GetAsync(HttpClient client)
{
  int off = 0;
  const int lim = 10;
  while (true)
  {
    // Получаем текущую страницу результатов
    var result = await client.GetStringAsync(
     $"{apiURL}/values?offset={off}&limit={lim}"
    );
    var values = result.Split('\n');
  
    // Выдаём результаты с этой страницы
    foreach (var value in values)
      yield return value;

    // Если последняя страница, выходим
    if (values.Length != lim)
      break;
    // Переходим к следующей странице
    off += lim;
  }
}

Когда метод GetAsync начинает работу, он асинхронный запрашивает первую страницу данных, после чего производит первый элемент. Второй элемент выдаётся немедленно, потому что он содержится на той же странице данных. И т.д. 10 элементов. При запросе 11-го элемента цикл foreach завершится, выполнение цикла while продолжится. На следующей итерации цикла while выполнится асинхронный запрос второй страницы данных, после чего будет выдан 11-й элемент. И т.д…

В течение многих лет использовать async и await с yield return было невозможно, но асинхронные потоки ввели эту возможность. В примере выше стоит обратить внимание, что асинхронная работа нужна не для всех результатов. Здесь только приблизительно одному из каждых 10 элементов потребуется асинхронная работа. Если размер страницы равен 20, то асинхронная работа потребуется только одному из 20 элементов.
Это обычное поведение с асинхронными потоками. Для многих потоков большинство операций асинхронного перебора на самом деле синхронно; асинхронные потоки только позволяют асинхронно получить любой следующий элемент. Асинхронные потоки проектировались с учетом как асинхронного, так и синхронного кода; вот почему они построены на основе ValueTask<T>.

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

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 3.

День 1030. #ЗаметкиНаПолях #AsyncTips
Потребление асинхронных потоков
Создание асинхронных потоков

Задача: обработать результаты асинхронного потока.

Решение
Потребление асинхронного потока основано на объединении конструкций ожидания и перечисления в await foreach. Например, для асинхронного потока, который потребляет ответы API по страницам, можно организовать вывод элементов в консоль:

public async Task ProcessAsync(HttpClient client)
{
  await foreach (var value in GetAsync(client))
  {
    Console.WriteLine(value);
  }
}

На концептуальном уровне вызывается метод GetAsync, который возвращает IAsyncEnumerable<T>. Цикл foreach затем создаёт асинхронный перечислитель на базе асинхронного потока. Асинхронные перечислители на логическом уровне похожи на обычные перечислители, не считая того, что операция «получить следующий элемент» может быть асинхронной. Таким образом, await foreach будет ожидать поступления следующего элемента или завершения асинхронного перечислителя. Если элемент поступил, то await foreach выполнит тело цикла; если асинхронный перечислитель завершён, происходит выход из цикла.

Также можно выполнить асинхронную обработку каждого элемента:

await foreach (var val in GetAsync(client))
{
  // асинхронная работа
  await Task.Delay(100);
  Console.WriteLine(val);
}

В этом случае await foreach не переходит к следующему элементу до завершения тела цикла. Таким образом, await foreach асинхронно получит первый элемент, после чего асинхронно выполнит тело цикла для первого элемента, затем асинхронно получит второй элемент, асинхронно выполнит тело цикла для второго элемента и т.д.

В await foreach скрыта команда await: к операции «получить следующий элемент» применяется await. С обычной командой await можно обойти захват контекста с помощью ConfigureAwait(false). Асинхронные потоки также это поддерживают:

await foreach (var val in
   GetValuesAsync(client).ConfigureAwait(false))
{
  await Task.Delay(100)
    .ConfigureAwait(false);
  Console.WriteLine(val);
}

Итого
await foreach — самый логичный способ потребления асинхронных потоков. Язык поддерживает ConfigureAwait(false) для предотвращения захвата контекста в await foreach. Также возможен вариант с передачей маркеров отмены. Об этом позже.

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 3.

День 1031. #Карьера
Как Избежать Вредных Привычек, Работая Удалённо
Локдаун поспособствовал переходу многих разработчиков ПО на удалёнку. Но возникла проблема, как сохранить рабочий настрой дома? Ниже приведены пять вредных привычек, которые могут завести работающие дома, и советы, как их избежать.

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

2. Работа круглосуточно
То, что вы можете работать с полуночи до 3 часов ночи, не означает, что вы должны это делать. На самом деле, наиболее продуктивные люди работают в обычное время, без выходных или сверхурочных. Кэл Ньюпорт - профессор вычислительной техники Джорджтаунского университета - в своей книге «В работу с головой» («Deep Work») помогает повысить продуктивность на работе.
Один из примеров - то, что он называет «продуктивностью по графику». Планирование всего рабочего дня по часам, заранее, при этом позволяя себе перемещать блоки при необходимости. По словам Ньюпорта, поддержание регулярного рабочего графика и отключение «домашнего офиса» в конце рабочего дня - это наиболее эффективный способ работы без стресса или выгорания. Если вы ограничиваете свой рабочий день, вам не нужно работать по ночам из-за того, что вы тратили рабочее время на социальные сети.

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

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

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

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

Удалёнщики, какие у вас возникали плохие привычки, и как вы с ними боролись?

Источник: https://www.asme.org/topics-resources/content/five-tips-in-avoiding-bad-habits-when-working-remotely

День 1032. #юмор
А править прямо на проде. Ммм... непередаваемые ощущения.

День 1033. #Карьера
Чему Можно Научиться из Книг «Программист-прагматик» и «Идеальный программист». Часть 1
Вы найдете эти книги почти в каждой подборке «10 лучших книг по разработке ПО». Когда вы разрабатываете ПО, вы можете застрять на том, что видео из YouTube и ответы на StackOverflow не помогают. Вы в итоге обращаетесь к документации или к исходному коду этой технологии, чтобы найти ответ. То же самое происходит, когда вы хотите действительно глубоко понять предмет. Иногда статей может не хватать, и чтение хороших книг - лучший выход. В этих книгах основное внимание уделяется не столько написанию кода, сколько обучению передовым методам разработки и даже полезным жизненным урокам.

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

Программист-прагматик принимает на себя ответственность за свою собственную карьеру и не боится признаваться в незнании или ошибке.
- Программист-прагматик

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

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

Знание и опыт являются самыми важными профессиональными активами.
- Программист-прагматик

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

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

При этом важно смотреть на картину в целом и не упустить главную цель, создавая слишком много тестов.

Есть три способа тестирования: «сначала», «во время» и «никогда». «Сначала» (TDD) - лучший. «Во время» - запасной вариант, когда первый бесполезен. «Никогда» часто называют «протестирую позже», но, к сожалению, в большинстве случаев «позже» означает «никогда».

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

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

Используйте приёмочные тесты, чтобы определить, выполняются ли требования, в сотрудничестве с заинтересованными сторонами.

У разработчиков должна быть цель: «QA не должен ничего находить». Вы можете добиться этого, реализуя различные виды тестов: модульные, компонентные, интеграционные, системные, приёмочные.

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

Источник: https://www.freecodecamp.org/news/lessons-learned-from-the-pragmatic-programmer-and-the-clean-coder/

День 1034.
Асинхронный Обмен Сообщениями. Начало
1. Основы распределённой архитектуры
Это совсем не новая проблема, но в последние несколько лет она становится все более и более распространённой. Кроме того, эту проблему трудно решить быстро - или даже быстро описать решение.

Задача
Проблема обычно проявляется в желании досрочно вернуться из HTTP-запроса. Как только запрос был получен, разработчик хочет, чтобы серверный API не дожидался завершения обработки, а немедленно отправил ответ клиенту. Обычно это называют «запустил и забыл».
Цель состоит в том, чтобы HTTP-вызов просто запускал рабочий процесс. Затем этот рабочий процесс выполнялся бы на стороне сервера без дополнительных действий со стороны клиентского приложения.

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

Решение
Подходящим решением для внешнего запроса является асинхронный обмен сообщениями. Он состоит из двух частей (с необязательной третьей частью):
1) Перманентная очередь
Под «перманентной» подразумевается очередь, которая, по крайней мере, сохраняется на диск при добавлении элемента. Другими словами, сообщения, отправленные в очередь, долговечны. Таким образом, очереди в памяти Queue<T>, BlockingCollection<T> или ChannelWriter<T> не являются «перманентными очередями».
2) Бэкенд-сервис
Это независимый сервис, который читает из этой перманентной очереди и обрабатывает элементы в ней (т.е. выполняет длительную операцию).
3) (необязательно) Какой-либо метод получения результатов.
Если клиенту необходимо знать результат длительной операции, то это та часть, которая предоставляет этот результат клиенту.

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

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

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

Далее мы подробно остановимся на каждой части решения и рассмотрим конкретные подходы.

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

Источник: https://blog.stephencleary.com/2021/01/asynchronous-messaging-1-basic-distributed-architecture.html

День 1035.
Асинхронный Обмен Сообщениями. Продолжение
1. Основы распределённой архитектуры

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

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

Проблема с очередями в памяти
Что же значит фраза «асинхронные сообщения должны выдерживать отключения сервиса»? Легче всего понять это, обдумывая вопрос: «Когда безопасно отключить HTTP-сервис?»

Протокол HTTP используется всеми видами API и веб-сервисов. Однако иногда забывается одна важная деталь: это протокол запроса/ответа. Т.е. на каждый запрос есть ровно один ответ. С точки зрения HTTP-сервиса, поступает запрос, а затем через некоторое время отправляется ответ и этот запрос завершается.

Так когда безопасно отключить HTTP-сервис? Самый простой ответ - когда был отправлен ответ на каждый запрос, т.е. когда больше нет невыполненных запросов. Это настолько естественный ответ, что каждый HTTP-сервер подразумевает его по умолчанию. ASP.NET, Node.js, Ruby on Rails… - каждая среда отслеживает, сколько невыполненных запросов у неё есть, и считает себя «безопасной для завершения», когда это число достигает нуля. Это также верно для балансировщиков нагрузки и прокси-серверов.

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

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

Таким образом разработчик хочет, чтобы их HTTP-приложение работало «бесконечно». И это серьёзное непонимание принципов работы: на самом деле системы более устойчивы, если серверы не работают бесконечно. Отключения - это нормально, и мы должны принимать отключения как нормальную часть жизни.

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

Резонный вывод - отключения - это нормально. Все HTTP-приложения должны работать правильно при завершении работы. Следствие: всё ПО, которое предполагает, что оно никогда не завершится, по своей сути содержит ошибки.
Наконец, вернёмся к тому, что означает «перманентный». Очереди в памяти не выдерживают отключений. Следовательно, «минимально приемлемая надежность» означает, что очередь сообщений выдерживает отключения, которые являются нормальным и обычным явлением.

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

Источник: https://blog.stephencleary.com/2021/01/asynchronous-messaging-2-durable-queues.html

День 1036.
Асинхронный Обмен Сообщениями. Продолжение
1. Основы распределённой архитектуры
2. Перманентные очереди

Примеры перманентных очередей
Наиболее предпочтительным вариантом будут облачные очереди, когда это возможно, потому что облачный провайдер управляет ими, они очень хорошо масштабируются и дают вам настройки, позволяющие контролировать, насколько параноидально надёжной должна быть ваша очередь. Примерами могут быть Azure Storage Queue, Amazon Simple Queue Service (SQS) и Google Cloud Tasks. Все облачные системы очередей предоставляют перманентные очереди, которые можно масштабировать автоматически.

Какими бы прекрасными ни были облачные решения, локальные системы очередей вполне жизнеспособны. Невозможно получить те же возможности масштабирования, что и в облачном решении, но вы можете снизить задержки. Самыми распространёнными локальными перманентными очередями в наши дни являются RabbitMQ и Kafka. Для старых систем Windows обычно использовалась очередь сообщений Microsoft (MSMQ), хотя в наши дни это больше не рекомендуется. Обратите внимание, что некоторые локальные решения для очередей (например, RabbitMQ) не используют постоянные хранилища по умолчанию, поэтому необходима некоторая настройка, чтобы сделать очередь действительно перманентной.
Есть и другие решения как для облачных, так и для локальных сетей.

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

Использование базы данных ACID в качестве перманентной очереди позволяет использовать паттерн исходящих сообщений (Outbox). Когда сервис хочет опубликовать сообщение оно считается успешно записанным тогда и только тогда, когда определённая транзакция базы данных завершается успешно и сообщение записывается в базу данных как часть этой транзакции. Сервис не может сообщить об успехе до обновления базы данных, потому что обновление базы данных может завершиться ошибкой. Также сервер не может сообщить об успехе, пока не завершится обновление базы данных, потому что, если возникнет проблема с попаданием сообщения в постоянную очередь, сообщение будет потеряно. Таким образом, используя непосредственно базу данных в качестве постоянной очереди, сервис гарантирует, что сообщение об успехе будет возвращено тогда и только тогда, когда произойдёт обновление базы данных.

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

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

Источник: https://blog.stephencleary.com/2021/01/asynchronous-messaging-2-durable-queues.html

День 1037.
Асинхронный Обмен Сообщениями. Продолжение
1. Основы распределённой архитектуры
2. Перманентные очереди
Примеры перманентных очередей

3. Бэкенд-сервисы
Назначение фонового сервиса - обработка сообщений очереди. Это другая сторона «трубы». HTTP-приложение - это производитель, помещающий сообщения в очередь, а фоновый сервис - потребитель, извлекающий сообщения из очереди и обрабатывающий их. Обычно рекомендуется, чтобы фоновый сервис был независимым от HTTP-приложения, но это не обязательно.

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

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

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

Примеры бэкенд-сервисов
Основные решения - облачные, в частности, Functions as a Service (FaaS). Основные облачные провайдеры имеют встроенную поддержку для объединения своих перманентных очередей с FaaS: Azure Functions, AWS Lambdas или Google Cloud Functions. Поддержка включает в себя логику масштабирования: каждый облачный провайдер будет автоматически масштабировать FaaS-потребителей на основе объёма сообщений в очереди.

Для локальных решений естественным подходом является служба Win32 (в Windows) или демон в Linux. Эти фоновые службы работают всё время, пока серверная машина включена, независимо от того, вошел ли пользователь в систему, и не допускают прямого взаимодействия с пользователем.
Другое решение - консольное приложение в контейнере Docker, который можно развернуть локально или в облаке. Этот подход имеет лучшую поддержку горизонтального масштабирования.

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

Замечание: в ASP.NET Core используйте IHostedService или IHostApplicationLifetime для обнаружения и блокировки завершения работы приложения HTTP. BackgroundService также можно использовать, но имейте в виду, что работа может быть потеряна, если время завершения работы хоста истечёт.
В ASP.NET Framework используйте HostingEnvironment.QueueBackgroundWorkItem или IRegisteredObject.

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

Источник: https://blog.stephencleary.com/2021/01/asynchronous-messaging-3-backend-processor.html

День 1038.
Асинхронный Обмен Сообщениями. Продолжение
1. Основы распределённой архитектуры
2. Перманентные очереди
Примеры устойчивых очередей
3. Бэкенд-сервисы

4. Получение результатов
Важно отметить, что существует множество сценариев, которые не требуют явной отправки результатов. Например, отправка e-mail. Исходному клиенту не нужно получать уведомление о том, что письмо действительно было отправлено. Другой случай - когда конечный пользователь обновляет страницу. Он рано или поздно увидит результаты. Поэтому первый вопрос, который следует задать: действительно ли получение результатов необходимо?
Рассмотрим варианты получения результатов для REST API.

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

Приложение также должно возвращать информацию, которая позволит клиенту опрашивать статус завершения. Обычно это какой-то URI «статуса». Стандарт требует либо ссылку на монитор статуса, либо примерное время, когда запрос будет выполнен. Это очень нечёткое требование, и именно здесь реализации начинают расходиться. Один из вариантов - вернуть URI статуса в теле 202 Accepted (например, в JSON). Другой вариант - вернуть URI статуса в заголовке ответа Location.

Как только клиент получит URI статуса, он может начать периодически вызывать этот URI для получения статуса асинхронной операции. Опять же, реализации расходятся в деталях. Пока операция не завершена, некоторые реализации возвращают 200 OK с каким-то индикатором «незавершённого статуса» в теле. Другие снова возвращают 202 Accepted. Сервер также может дополнительно включать «процент завершения» в тело ответа и/или заголовок Retry-After, если он имеет предполагаемое время завершения (для предотвращения чрезмерно частых вызовов).

Если операция завершается с ошибкой, то URI статуса может либо вернуть 200 OK с «ошибкой» в теле ответа, либо вернуть соответствующий код ошибки (4xx/5xx) с дополнительными сведениями об ошибке в теле ответа. В случае успеха URI статуса может возвращать 303 See Other с заголовком Location для ресурса, который был обновлён/изменён через асинхронное сообщение. Либо вернуть 200 OK, 201 Created или 204 No Content, чтобы указать на успешное завершение.

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

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

Уведомление
В некоторых случаях клиентам необходимо немедленно знать, когда сообщение было обработано. В этом случае можно использовать систему уведомлений, инициированную сервером. В наши дни это почти всегда WebSockets (или SignalR), хотя старые решения, такие как длинный опрос или даже серверные события (SSE), тоже всё ещё существуют. Все эти решения позволяют приложению отправлять сообщение уже подключённому клиенту. Смысл в том, что бэкенд-сервис подключается к HTTP-приложению через какую-то шину (например, через хаб SignalR), а затем отправляет сообщение по этой шине непосредственно в HTTP-приложение, которое уведомляет клиентов. Есть только одно предостережение: шина должна быть готова к масштабированию. Некоторые системы (например, SignalR) по умолчанию не настроены на масштабирование.

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

Источник: https://blog.stephencleary.com/2021/01/asynchronous-messaging-4-retrieve-results.html

День 1039.
Асинхронный Обмен Сообщениями. Окончание
1. Основы распределённой архитектуры
2. Перманентные очереди
Примеры устойчивых очередей
3. Бэкенд-сервисы
4. Получение результатов

5. Прочее
Здесь собраны различные прочие соображения по поводу асинхронного обмена сообщениями.

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

Управление версиями
Сообщения в очереди можно считать своего рода объектами передачи данных (DTO). Они действуют как мост между двумя процессами: HTTP-приложением и бэкенд-обработчиком. Как и остальная система, DTO со временем будут меняться, и к этому лучше быть готовым. Возможно указывать версии в самом имени очереди, либо в самих DTO. Версии вводятся для того, чтобы старый потребитель не мог обрабатывать новые типы сообщении в очереди.

Сервисы разных провайдеров
Вполне возможно масштабировать, например, функции Azure на основе RabbitMQ или подключить бэкенд-сервис в Docker, размещённый в Google Cloud, к очереди Amazon SQS. Хотя иногда при этом возникают дополнительные расходы, а иногда вам нужно написать плагин, чтобы ваш бэкенд-сервис использовал ваш тип очереди для масштабирования.

Готовые решения
Существуют готовые комплексные решения для асинхронного обмена сообщениями. Примерами являются Hangfire (.NET) и Delayed Job (Ruby). Их универсальность означает, что их легче настроить, но и то, что они менее гибкие. То, что создали разработчики этого решения, может сильно отличаться от того, что нужно вашему приложению. В частности, вам необходимо изучить:

1) Используется ли перманентная очередь? В противном случае лучше даже не рассматривать это. Всё, что использует Redis в его конфигурации по умолчанию, не должно использоваться. Следует настроить Redis на перманентное хранение в файле только для добавления (Append Only File) с синхронизацией этого файла для каждой команды. Hangfire и Delayed Job используют базу данных для очереди, что нормально (при условии, что у вас уже есть база данных), но не идеально (теперь ваш сервер базы данных должен иметь дело с сообщениями очереди, помимо обычных данных).

2) Как сериализуются сообщения: будет ли сериализация обратно совместима при обновлении библиотеки? До недавнего времени Hangfire не поддерживал скользящие обновления из-за способа сериализации заданий. Приложения должны были полностью отключаться перед развёртыванием обновления Hangfire, а если требовался откат, они также должны были полностью отключаться перед выполнением отката.

3) Как сериализуются задания: как может изменяться код? Например, .NET довольно специфичен в сериализации делегатов методов, и даже добавление параметра (со значением по умолчанию) может вызвать сбой. Любое подобное изменение потребует двух обновлений вместо одного: первое добавит новую перегрузку, а после завершения всех старых заданий можно развернуть второе обновление, чтобы удалить старую перегрузку.

4) Как обрабатываются ошибки? Большинство универсальных решений автоматически повторяют попытку. По умолчанию Hangfire оставляет эти сообщения в состоянии «failed» (и вы должны создать какое-то уведомление об этом), тогда как Delayed Job удаляет их!

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

Источник: https://blog.stephencleary.com/2021/02/asynchronous-messaging-5-miscellaneous-considerations.html

День 1041. #ЧтоНовенького
Новый редактор Razor в Visual Studio 2022
С выпуском Visual Studio 2022 версии 17.0.2 вы можете использовать новый редактор Razor.

Преимущества перехода на Language Server Protocol
Новый редактор Razor для проектов ASP.NET Core основан на протоколе языкового сервера (LSP). Это протокол с открытым исходным кодом, который определяет стандартный способ включения функций редактором или IDE. Модель LSP позволила добавить в Razor гораздо больше функций редактирования C# и другие функции для повышения продуктивности, специфичные для Razor.

Что доступно в новом редакторе Razor?
1. В редакторе Razor теперь поддерживается наиболее часто используемый рефакторинг Add missing usings (Добавить недостающие директивы using).

2. Также добавлено несколько функций, специфичных для Razor. Например, Extract block to code behind (Извлечь блок в файл кода) позволяет вам извлечь блок кода в отдельный файл кода, если вы не хотите держать его в одном файле с разметкой. Другие добавленные функции включают:
- Add usings for component (Добавить директивы using для компонента),
- Fully qualify component (Полностью определить компонент),
- Create component (Создать компонент).

2. Улучшена навигация. Одной из наиболее часто используемых функций навигации в Visual Studio является Go to Definition (Перейти к определению). Она помогает быстро перемещаться по файлам и лучше понимать код. Например, нажатие F12 на теге компонента теперь переместит вас прямо в код компонента.

3. Опыт горячей перезагрузки также улучшен, благодаря LSP.

4. В новом редакторе Razor обновлены цвета по умолчанию. Основным отличием является то, что код больше не подсвечивается серым фоном, как это было в предыдущих версиях.

5. Новый редактор обеспечивает улучшенное форматирование, которое лучше справляется с изменениями, помогая коду оставаться визуально согласованным. Поддерживаются более умные дополнения синтаксиса Razor, такие как завершение <text> и автозаполнение. Новый редактор также изменяет способ диагностики, чтобы гарантировать отображение только наиболее важных диагностических сообщений.

6. Razor теперь полностью поддерживает Visual Studio Live Share.

Известные проблемы и дорожная карта
Razor накопил большое количество запросов на добавление функций и исправлений ошибок. Решение этих проблем в устаревшем редакторе Razor было трудным и дорогостоящим. Новый редактор позволит быстрее предоставлять исправления ошибок и новые функции. Есть ещё несколько функциональных пробелов, которые необходимо устранить в следующих выпусках:
- Поддержка сниппетов (с помощью Tab)
- Горячая клавиша «Обернуть в div» - Shift+Alt+W
- Ctrl+щелчок мыши для перехода к определению
- Сворачивание кода в #region
- Встроенное форматирование JavaScript
- Поддержка перетаскивания файлов HTML, CSS и JavaScript
- Улучшения производительности и надёжности
- Поддержка горячей перезагрузки для проектов Blazor Web Assembly при отладке

Следить за дорожной картой вы можете на GitHub.

Если вы обнаружите, что ваша продуктивность в новом редакторе ограничена, вы можете вернуться к предыдущей версии редактора, перейдя в Tools > Options > Text Editor > HTML > Advanced (Инструменты > Параметры > Текстовый редактор > HTML > Дополнительно) и выбрав True в раскрывающемся списке рядом с пунктом Use legacy Razor editor for ASP.NET Core (Использовать устаревший редактор Razor для ASP.NET Core). Имейте в виду, что старый редактор Razor будет иметь ограниченную функциональность и не будет включать улучшения, описанные выше.

Источник: https://devblogs.microsoft.com/visualstudio/introducing-the-new-razor-editor-in-visual-studio-2022/

День 1042. #Карьера
Чему Можно Научиться из Книг «Программист-прагматик» и «Идеальный программист». Часть 2
Часть 1

3. Командная Работа – Работа Мечты
Работая в команде, вы должны быть «командным игроком», часто общаться, следить за своими товарищами по команде и максимально эффективно выполнять свои обязанности.

Команды должны быть небольшими, не более 10-12 человек, где все знают и доверяют друг другу. Такую командную среду сложно создать, поэтому, как только вы её получите, вам придётся заботиться о ней, изменяя проекты, над которыми работает команда, а не её участников.

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

Формировать команды под каждый проект неверно в принципе: группы просто не успеют «притереться». Люди участвуют в проекте только короткое время и поэтому никогда не узнают, как взаимодействовать друг с другом. Команды строить сложнее, чем проекты. Слаженная команда может вести сразу несколько проектов и распределять работу в соответствии со своими предпочтениями, квалификацией и способностями участников.
- Идеальный программист

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

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

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

4. Разработка методом трассирующих пуль
Трассирующие пули отмечают пройденный путь, чтобы стрелок мог лучше прицелиться в следующий раз. Таким образом, основная цель разработки методом трассирующих пуль - «добавить» основные функции в проект и получить быструю обратную связь, чтобы лучше «нацелиться» на следующие изменения.

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

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

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

Этот подход не следует путать с прототипированием. Код прототипов не должен быть частью проекта, а код «трассирующих пуль» не выбрасывается. Он работает и улучшается с каждой итерацией.

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

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

Источник: https://www.freecodecamp.org/news/lessons-learned-from-the-pragmatic-programmer-and-the-clean-coder/

День 1043. #ЗаметкиНаПолях #AsyncTips
Использование LINQ с асинхронными потоками
Создание асинхронных потоков
Потребление асинхронных потоков

Задача: обработать асинхронный поток с использованием чётко определенных и хорошо протестированных операторов. Либо использовать LINQ, когда предикат является асинхронным, например, необходимо провести поиск каждого элемента в базе данных или API, чтобы узнать, должен ли он быть включен в итоговую последовательность.

Решение
Допустим, у нас есть метод, производящий асинхронную последовательность:

async IAsyncEnumerable<int> GetAsyncRange()
{
  for (int i = 0; i < 10; i++)
  {
    await Task.Delay(100);
    yield return i;
  }
}

IAsyncEnumerable<T> включает поддержку LINQ в NuGet-пакете System.Linq.Async. Заметьте, что при этом в коде нужно использовать

using static System.Linq.AsyncEnumerable;

Операторы LINQ можно применять к асинхронным потокам. Доступны все знакомые операторы: Where, Select, SelectMany, Join и т.д. Результат представляет собой асинхронный поток:

IAsyncEnumerable<int> values =
  GetAsyncRange().Where(value => value % 2 == 0);

await foreach (int result in values) {
  Console.WriteLine(result);
}

Но что, если нам нужно передать в Where асинхронный предикат? Where их не поддерживает. Но есть подходящий оператор WhereAwait:

IAsyncEnumerable<int> values = 
  GetAsyncRange().WhereAwait(
    async value => {
     // Асинхронная работа для определения,
     // должен ли элемент быть включён в результат
     await Task.Delay(10);
     return value % 2 == 0;
  });

Методы LINQ для асинхронных потоков можно использовать и для обычных перечисляемых объектов, вызвав ToAsyncEnumerable() для любого IEnumerable<T>. Результат можно использовать с WhereAwait, SelectAwait и другими операторами, принимающими асинхронные делегаты.

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

Пример WhereAwait был приведёт выше.

Суффикс Async применяется только к операторам терминации (termination operators), которые извлекают некоторое значение или выполняют некоторые вычисления и возвращают асинхронное скалярное значение. Пример такого оператора — CountAsync, версия Count для асинхронного потока, которая может подсчитать количество элементов, соответствующих некоторому предикату:

int count = await GetAsyncRange()
  .CountAsync(value => value % 2 == 0);

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

int count = await GetAsyncRange().CountAwaitAsync(
  async value => {
   await Task.Delay(10);
   return value % 2 == 0;
  });

Итого
- Операторы без суффиксов (Where, Select) получают синхронные делегаты и выдают асинхронную последовательность.
- Операторы, которые получают асинхронные делегаты, имеют суффикс Await (WhereAwait, SelectAwait), и выдают асинхронную последовательность.
- Операторы, возвращающие терминальное значение, имеют суффикс Async (CountAsync), а также могут иметь суффикс Await, если получают асинхронный делегат (CountAwaitAsync).

Источник: Стивен Клири “Конкурентность в C#”. 2-е межд. изд. — СПб.: Питер, 2020. Глава 3.

День 1044. #ЗаметкиНаПолях #ExploringNET6
Исследуем .NET 6. Часть 1
В этой серии статей рассмотрим подробно некоторые из новых функций, которые появились в .NET 6.

Заглянем в ConfigurationManager
ConfigurationManager был добавлен для поддержки новой модели WebApplication в ASP.NET. Однако он во многом является деталью реализации.

В .NET5 двумя основными типами конфигурации:
- IConfigurationBuilder - для добавления источников конфигурации. Вызов Build() считывает каждый из источников конфигурации и строит окончательную конфигурацию.
- IConfigurationRoot - представляет собой окончательную «построенную» конфигурацию.

Поставщики конфигурации обычно включают методы расширения (например, AddJsonFile() и AddAzureKeyVault()), которые добавляют источник конфигурации в список источников. IConfigurationRoot в свою очередь объединяет все значения из каждого источника конфигурации, чтобы дать окончательное представление всех значений.

Проблема "частичной сборки конфигурации" в .NET 5
Основная проблема с этим подходом проявляется, когда вам нужно построить конфигурацию «частично». Это распространённая проблема, когда вы храните свою конфигурацию в таком сервисе, как Azure Key Vault, или в базе данных. Рекомендуемый подход состоит в следующем:
- Добавить «начальные» значения конфигурации.
- Создать «частичный» результат конфигурации, вызвав IConfigurationBuilder.Build()
- Получить необходимые значения конфигурации из построенного IConfigurationRoot
- Использовать эти значения, чтобы добавить оставшиеся источники конфигурации
- Фреймворк неявно вызывает IConfigurationBuilder.Build(), генерируя окончательный IConfigurationRoot и используя его для окончательной конфигурации приложения.

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

Менеджер Конфигурации в .NET 6
В .NET 6 добавлен новый тип конфигурации, ConfigurationManager. Он реализует как IConfigurationBuilder, так и IConfigurationRoot, позволяя оптимизировать сценарий, описанный выше.
В ConfigurationManager, когда добавляется IConfigurationSource (например, когда вы вызываете AddJsonFile()), поставщик сразу загружается, и конфигурация обновляется. Это позволяет избежать загрузки источников конфигурации более одного раза в сценарии частичной сборки.

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

Стоит ли вам беспокоиться о том, используете ли вы ConfigurationManager или ConfigurationBuilder? Скорее нет.

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

Однако WebHostBuilder или HostBuilder, представленные в более ранних версиях ASP.NET, по-прежнему поддерживаются в .NET 6, и они по-прежнему «за кулисами» используют типы ConfigurationBuilder и ConfigurationRoot.

Подробнее перевод статьи с примерами кода размещён на Хабре.

Источник: https://andrewlock.net/exploring-dotnet-6-part-1-looking-inside-configurationmanager-in-dotnet-6/

День 1045. #ЧтоНовенького
Сервис Azure Load Testing
Недавно Microsoft анонсировали превью сервиса Azure Load Testing. Он позволяет пользователям имитировать полноценную нагрузку на приложение с помощью сценариев Apache JMeter и получать полезные сведения, позволяющие выявлять и устранять узкие места производительности.

Ранее компания предлагала возможности нагрузочного тестирования в Visual Studio 2019 через функции веб-производительности и нагрузочного тестирования. Кроме того, также предлагался соответствующий облачный сервис нагрузочного тестирования в Azure DevOps. Ни то, ни другое больше не поддерживается, и теперь преемник Azure Load Testing с поддержкой Apache JMeter с открытым исходным кодом доступен в превью.

Azure Load Testing позволяет пользователям создавать крупномасштабные нагрузки без необходимости управления сложной инфраструктурой. Он интегрируется с Azure Monitor, включая Application insights и Container insights, для сбора метрик из сервисов Azure (см. картинку ниже). Кроме того, пользователи могут включать нагрузочное тестирование в свои рабочие процессы непрерывной интеграции и доставки (CI/CD) и потенциально находить проблемы с производительностью до того, как они появятся в производственной среде.

В Azure Marketplace пользователи могут найти сервис Azure Load Testing, который можно использовать для интеграции в конвейер CI/CD в значимых точках жизненного цикла разработки. Эти конвейеры могут быть либо GitHub Actions, либо Azure Pipelines. Впоследствии в настройках тестов можно указать правила прохождения и отказа, чтобы отловить снижение производительности. И, наконец, при запуске конвейера сервис может автоматически прерывать запуск нагрузочных тестов в случае определённых условий (ошибок), что помогает защититься от выполнения ненужных нагрузочных тестов и дополнительных расходов.

Наряду с нагрузочным тестированием в Marketplace пользователи также могут создать ресурс Azure Load Testing на портале Azure в качестве централизованного места для просмотра планов и результатов тестирования и других связанных артефактов, а также для управления ими. После подготовки ресурса Azure Load Testing можно настроить роли идентификации и доступа для тестов, загрузить пользовательские сценарии JMeter и создать нагрузочные тесты.

Подробности и руководство доступны на этой странице.

Источник: https://www.infoq.com/news/2021/12/azure-load-testing-preview/