День 1075. #ЧтоНовенького
В C #10 появился новый атрибут CallerArgumentExpression. Он позволяет записывать выражение, переданное в качестве параметра, в виде строки (см. рисунок). Как и другие атрибуты CompilerServices, он применяется к необязательному параметру.

Кстати, его использует новый метод

ArgumentNullException.ThrowIfNull(nullArg);

в .NET без явной передачи имени.

Если раньше нам нужно было писать что-то подобное:

public bool DoSomething(string id, string name)
{
  if (id is null)
    throw new ArgumentNullException(nameof(id));
  if (name is null)
    throw new ArgumentNullException(nameof(id));
  // ...
}

Теперь новый метод позволяет писать более чистый код:

public bool DoSomething(string id, string name)
{
  ArgumentNullException.ThrowIfNull(id);
  ArgumentNullException.ThrowIfNull(name);
  // ...
}

Источник: https://twitter.com/Nick_Craver/status/1476929172249448459

День 1076. #NuGet
10 Лучших NuGet Пакетов для Повышения Продуктивности в 2022. Начало
Сегодня мы рассмотрим лучшие NuGet пакеты для повышения продуктивности разработчиков на C#.

1. RestSharp
RestSharp — самая популярная клиентская библиотека HTTP для .NET. Используя эту библиотеку, разработчики C# могут легко вызывать удалённые ресурсы по HTTP. Кроме того она заботится о сериализации тела запроса в JSON или XML и десериализации ответа.
Пакет RestSharp поддерживает:
- синхронные и асинхронные запросы,
- сериализацию и десериализацию,
- различные методы HTTP-запросов (GET, POST, PUT и DELETE),
- разнообразные способы аутентификации.
Всего загрузок: 111,1 млн.

2. Json.NET
Json.NET — это бесплатная библиотека с открытым исходным кодом для .NET, которую скачали более миллиарда раз. Её ключевые особенности включают в себя:
- Сериализацию и десериализацию любого объекта .NET в JSON и текста JSON в объект .NET.
- Преобразование между XML и JSON.
- Создание, анализ, запросы и изменение JSON, используя объекты JObject, JArray и JValue.
- Запросы к JSON с синтаксисом, подобным XPath.
- Высокую производительность.
Всего загрузок: 1,6 млрд.

3. Serilog
Логи — это записи действий, исключений, информации и предупреждений. Ведение журнала — важный фактор в разработке приложений, который помогает разработчикам легко обнаруживать и устранять проблемы. Serilog — это платформа логирования, используемая в .NET. Он записывает пользовательские свойства и данные в формате JSON.
В отличие от других инструментов ведения журналов, Serilog предоставляет структурированные журналы, которые позволяют производить поиск по записанным данным. Он также позволяет разработчикам легко записывать данные о событиях в консоль, в файлы и во все типы систем хранения.
Всего загрузок: 365,1 млн.

4. NUnit
Тестирование играет важную роль в разработке программного обеспечения для обеспечения корректности кода. NUnit — это платформа модульного тестирования с открытым исходным кодом для всех языков .NET, включая C#. С помощью NUnit вы можете легко тестировать большие приложения, разбивая их на небольшие модули. Это помогает нам находить проблемы прямо во время разработки.
Всего загрузок: 153,1 млн.

5. Insight.Database
Insight.Database — это микро-ORM для .NET, который преобразует объекты C# в записи базы данных и наоборот. Это набор методов расширения, упрощающих работу с базами данных в приложении C#.
Основные функции Insight.Database включают в себя:
- Автоматическое открытие/закрытие соединений с базой данных.
- Простое выполнение хранимых процедур.
- Поддержку нескольких наборов результатов.
Всего загрузок: 691,0 тыс.

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

Источник: https://www.syncfusion.com/blogs/post/10-best-c-nuget-packages-to-improve-your-productivity-in-2022.aspx/amp

День 1077. #NuGet
10 Лучших NuGet Пакетов для Повышения Продуктивности в 2022. Продолжение
Начало

6. FluentValidation
FluentValidation — это библиотека .NET для построения строго типизированных правил валидации. Она использует Fluent-интерфейс и лямбда-выражения для создания правил. Правила валидации помогают поддерживать чистоту кода домена, выделяя код проверки в отдельный блок.
FluentValidation имеет множество встроенных правил, таких как проверка на null, на пустую строку, максимальную и минимальную длину и т.п. Библиотека также поддерживает пользовательские валидаторы, настраиваемые сообщения валидации на основе имён свойств, предоставляет локализованные сообщения, асинхронные проверки и т.д.
Всего загрузок: 118,7 млн.

7. Noda Time
Работа с датой, временем и часовыми поясами в .NET очень болезненна. Noda Time заполняет пробел в операциях с датой и временем в .NET и тем самым упрощает жизнь. Пакет предоставляет различные API для обработки UTC, местного времени и часовых поясов. Также предоставляется функционал для простого преобразования местного времени в UTC и обратно, что позволяет избежать серьёзных ошибок, которые могут допустить разработчики, реализуя эту логику самостоятельно.
Всего загрузок: 46,2 млн.

8. FluentEmail
FluentEmail — это библиотека .NET с открытым исходным кодом, которая позволяет внедрить функции отправки электронной почты в ваше приложение .NET за 10 минут. Помимо основных параметров электронного письма, пакет позволяет вложить файл, отправлять почту асинхронно, а также использовать Razor для разработки шаблонов писем и отправлять письма с помощью SendGrid, MailGun, SMTP и т. д.
Всего загрузок: 1,8 млн.

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

10. LazyCache
Кэширование — отличный способ повысить производительность приложения. LazyCache использует формат GetOrAdd для кэширования, когда вы запрашиваете элемент из кэша, предоставляя при этом функциональность для его добавления, если элемент отсутствует.
LazyCache отлично подходит для кэширования вызовов базы данных, процедур построения сложных графов объектов и вызовов веб-сервисов, которые нужно временно сохранить для повышения производительности. Пакет позволяет кэшировать элементы в течение большего или меньшего времени, но по умолчанию он сохраняет кэшированные элементы до 20 минут.
Ключевые особенности LazyCache:
- Потокобезопасен и готов для использования в параллельном коде.
- Совместим с асинхронным кодом: доступна ленивая однократная оценка асинхронных делегатов с использованием метода GetOrAddAsync().
Всего загрузок: 7,3 млн.

Источник: https://www.syncfusion.com/blogs/post/10-best-c-nuget-packages-to-improve-your-productivity-in-2022.aspx/amp

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

Все проблемы в информатике можно решить с помощью ещё одного уровня абстракции… За исключением проблемы слишком большого количества уровней абстракции.
— Батлер Лэмпсон

Мы рассмотрим, как отказ от лишних абстракций может привести к гораздо более чистой кодовой базе со значительно сниженной сложностью, а также повышенной читаемостью и удобством сопровождения. Обсуждаемые вопросы основаны на таких принципах, как «Делай Проще, Тупица» (KISS) и «Вам Этого не Понадобится» (YAGNI), что означает использование абстракции только тогда, когда это даёт значительную и реальную пользу. Давайте рассмотрим некоторые конкретные случаи преждевременных абстракций, которые часто встречаются на практике.

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

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

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

Когда же разделять обязанности? Распространённый случай — когда логику нужно использовать более, чем в одном месте. Если один и тот же HTTP-вызов или запрос к базе требуется в нескольких местах, дублирование логики снижает удобство сопровождения. Тогда будет хорошей идеей перенести код в общий и многократно используемый компонент. Главное не делать этого до того, как это потребуется. Другой допустимый случай — когда логика очень сложна и негативно влияет на читаемость окружающего кода. Если часть логики занимает 300 строк, это как раз тот случай. Но выделение всего нескольких строк в отдельный класс, скорее всего, только ухудшит читаемость и затруднит навигацию по коду. Помните, что разделение обязанностей всегда усложняет структуру кода.

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

Источник: https://www.daveabrock.com/2021/12/08/do-this-not-that-the-net-6-edition/

День 1079.
Избегайте Ненужных Программных Абстракций. Продолжение
Начало

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

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

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

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

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

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

Преждевременная оптимизация — корень всех зол
— Дональд Кнут

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

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

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

Источник: https://www.daveabrock.com/2021/12/08/do-this-not-that-the-net-6-edition/

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

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

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

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

Нужно нам было создать систему оценок. И задумали мы для выставления оценки вместо использовавшегося раньше обычного скучного выпадающего списка, сделать красивый ползунок. Тащишь его слева направо, оценка меняется от 0 до 5. Никаких новомодных фреймворков мы не используем, у нас старый добрый набор HTML+CSS+jQuery. Собственно, и ползунок взяли из jQuery UI. Проблема обнаружилась на мобильных устройствах. Очевидное для каждого действие тыкнуть в ползунок и протащить его пальцем до нужной оценки отказывалось работать. То есть мышкой его можно было таскать, а вот пальцем (или в эмуляторе) – нет.

В итоге к концу для, после настройки основного функционала, погуглив проблему, нашли небольшой плагин для jQuery, который, насколько я понял, и служил костылём для предоставления функционала «Touch & Drag/Drop» в jQuery UI. На следующий день я открыл страницу проекта на GitHub (который, кстати, давно был заброшен), выполнил все нужные действия из 3х простых шагов, два из которых – скачать файл с кодом и подключить его на странице. И – вуаля! – получаю ошибку JS “draggable() is not a function”.

Заметил, что плагин основан на нескольких пакетах из сборки jQuery UI. Поискал draggable в нашей кастомной сборке, и её там не оказалось. Поэтому скачал новую сборку, где всё должно было быть. И ползунок заработал! Правда сломался остальной код JS, причём сразу в нескольких неожиданных местах.

Промучившись с этим около часа, стал искать другие варианты. Нашёл. Есть же специально обученный HTML элемент <input type=”range” /> Проблема в том, что он в разных браузерах выглядит совершенно по-разному. Но и это не беда. Всего какой-то сотней строчек CSS можно было заставить элемент выглядеть так, как тебе надо.

В общем, на всю эту настройку, проверку во всех доступных браузерах, включая IE (не спрашивайте!), переписывание уже готового кода разметки и JS под использование нового элемента и т.п. ушла бОльшая часть дня. Но к приходу коллеги вечером, всё было готово, и выглядело даже почти так же, как изначально одобренный вариант UI. Я молодец! Я решил проблему!

Коллега удивился, что плагин не заработал. Но ещё больше удивился я (хотя, «удивился» тут слишком мягкое слово), когда коллега написал, что у него плагин заработал сразу, и он откатит мои изменения. После пары минут шока я решил разобраться, в чём же дело. И довольно скоро выяснил, что эту самую функцию draggable вообще не надо было вызывать! В шаге 3 на странице документации был пример кода, использующий эту функцию. Но элементы из jQuery UI работали и без неё. Только подключения плагина на страницу было достаточно! Причём всё прекрасно работало сразу и везде, включая эмулятор и реальный телефон. Дел было на 2 минуты в ленивом темпе!

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

День 1081.
Избегайте Ненужных Программных Абстракций. Окончание
Начало
Продолжение

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

Типичным способом достижения слабой связанности является следование принципам инверсии зависимостей и «Открыт-закрыт». На практике это часто делается путем абстрагирования классов за интерфейсами и зависимости других классов от этих интерфейсов, а не от конкретных реализаций.

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

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

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

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

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

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

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

Источник: https://www.daveabrock.com/2021/12/08/do-this-not-that-the-net-6-edition/

День 1082.
Сегодня порекомендую вам вебинар от Конрада Кокосы, который прошёл в понедельник. На канале я уже упоминал тест по работе с памятью в .NET (.NET Memory Quiz), a также коротко разбирал ответы:
- 1-4
- 5-8
- 9-12
- 13-16
- 17-20
- 21-24
- 25-27
- 28-32

В стриме Конрад подробно разбирает 3 наиболее интересных (с его точки зрения) вопроса из теста:
26. Очень хороший разбор на примере того, как использовать Benchmark.NET и профилировщик памяти (в данном случае – JetBrains dotMemory), чтобы определить, сколько памяти выделяется и на что.

25. Разбор того, как работает интернирование строк в .NET (не путать с интерполяцией).

28. Короткий (относительно других вопросов) разбор метода Dispose.

https://youtu.be/U74m6eVYSGs

День 1083. #ЧтоНовенького
Специфичные для платформы API
Новый .NET является кроссплатформенным. Вы можете запустить своё приложение на разных платформах. Однако использование специфичных для конкретных платформ API означает, что с ними нужно быть осторожным. В .NET появились новые API и анализатор совместимости платформ для решения проблем кроссплатформенности. .NET 5 представил новые статические методы в классе OperatingSystem:
- IsAndroid
- IsBrowser
- IsFreeBSD
- IsIOS
- IsLinux
- IsWindows
- и другие.
Полный список находится здесь

Кроме того, представлены новые атрибуты:
- [SupportedOSPlatform] для обозначения, что API специфично для какой-то платформы.
- [UnsupportedOSPlatform] для обозначения, что API не подходит для какой-то платформы.
См. картинку ниже.

Считается, что API без этих атрибутов работают на всех платформах. Анализатор совместимости с платформой включён в список анализаторов качества кода Roslyn. Начиная с .NET 5, он входит в пакет SDK для .NET и включен по умолчанию для .NET 5 и более поздних версий.

Подробнее о том, как анализатор определяет зависимость от платформы

В .NET 6 представлена концепция включения платформ, когда одна платформа может быть подмножеством другой платформы. Новые настраиваемые атрибуты для зависимых от платформы API:
- [SupportedOSPlatformGuard]
- [UnsupportedOSPlatformGuard]

Например, платформа iOS является подмножеством платформы MacCatalyst. Поэтому для [SupportedOSPlatformGuard("MacCatalyst")] метод OperatingSystem.IsIOS(), помеченный этим атрибутом проверит и iOS, и MacCatalyst.

Источник: https://twitter.com/okyrylchuk/status/1481011910195752960

День 1084. #Курсы
Сегодня порекомендую вам пару курсов от Microsoft Learn Live.

1. Создание микросервисов в .NET и ASP.NET (Create microservices with .NET and ASP.NET).
Курс посвящён созданию независимо развертываемых, масштабируемых и отказоустойчивых сервисов на платформе .NET.

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

Предстоящие стримы:
- 18.01.2022. 12:00–13:30 Мск. Создание и развёртывание облачного микросервиса в ASP.NET Core.
- 25.01.2022. Реализация отказоустойчивости.
- 01.02.2022. Инструментарий для облачного микросервиса.
- 08.02.2022. Реализация флагов функций в микросервисном приложении.
- 15.02.2022. Использование хранилищ данных в микросервисном приложении.
- 22.02.2022. Понимание API-шлюзов в микросервисном приложении.
- 01.03.2022. Развёртывание микросервисного приложения с помощью GitHub Actions.

Помимо стримов, для каждой темы доступно и обычное обучение с практическими заданиями на Microsoft Learn. Ссылки на все темы доступны на странице курса.

2. Обучение на сертификацию по Azure Cosmos DB (Azure Cosmos DB Certification Study Hall).
Узнайте, как разрабатывать, внедрять и отслеживать облачные приложения для хранения данных и управления ими, и получите сертификат Azure Cosmos DB Developer Specialty.

Этот курс проходит по средам и также начался 12 января. Первый модуль «Основы Azure Cosmos DB SQL API» можно посмотреть тут.

Предстоящие модули:
- 19.01.2022. 23:00–01:30 Мск. Планирование и реализация Azure Cosmos DB SQL API.
- 26.01.2022. Перемещение данных из и в базу.
- 02.02.2022. Использование SDK.
- 09.02.2022. Конфигурация SDK.
- 16.02.2022. Выполнение операций в базе данных.
- 23.02.2022. Выполнение кросс-документных транзакций.
- 02.03.2022. Обработка больших объемов данных.
- 09.03.2022. Запросы к БД.
- 16.03.2022. Создание сложных запросов.
- 23.03.2022. Определение индексов.
- 30.03.2022. Настройка индексов.
- 06.04.2022. Обработка сообщений об изменениях в SDK.
- 13.04.2022. Обработка событий в Azure Functions.
- 20.04.2022. Поиск по БД с помощью Azure Cognitive Search.

Как и для предыдущего курса, доступно и обычное обучение с практическими заданиями на Microsoft Learn. Ссылки на все темы доступны на странице курса.

День 1085. #ЗаметкиНаПолях
Использовать ли Одинаковые Идентификаторы в Разных Микросервисах
Существует распространённый и довольно интересный вопрос о том, как управлять идентификаторами в архитектуре микросервисов. Этот вопрос лучше всего описать на примере, поэтому, допустим, у нас есть два ограниченных контекста, Sales и Support, которые работают в своих соответствующих микросервисах (см. картинку ниже).

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

Отсюда вопрос: «Должен ли сервис поддержки использовать тот же ID, что и сервис продаж, или нужно назначать собственный ID своей версии клиента?»

Если вы используете UUID(GUID), вы можете легко назначить раздельные ID клиента в обоих сервисах, и идентификаторы в двух ограниченных контекстах не будут пересекаться. Но хорошо ли это?

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

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

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

Стоит ли использовать этот идентификатор Facebook как есть?
Нет, вам нужно создать собственный идентификатор клиента и сохранить идентификатор Facebook как отдельное (необязательное) поле. Разница здесь в том, что у вас нет контроля над идентификаторами, которые предоставляет вам Facebook. Facebook потенциально может изменить эти идентификаторы и испортить вашу систему.

Контракт между вашими микросервисами намного прочнее, чем между вашей системой и Facebook. Вы можете (и должны) поддерживать обратную совместимость между микросервисами в вашей системе. Нет никакой гарантии такой совместимости между вашей системой и Facebook.

Источник: https://enterprisecraftsmanship.com/
Автор оригинала: Владимир Хориков

День 1086. #ЗаметкиНаПолях
Защитите Контейнеры с Помощью Подписи в GitHub Actions
Большинство контейнеров, доступных сегодня, уязвимы для атак цепочки поставок, потому что они могут быть опубликованы только с помощью простого ключа API. В случае утечки этого ключа злоумышленник может легко опубликовать законно выглядящий контейнер, который на самом деле содержит вредоносное ПО. Один из лучших способов защитить пользователей от таких атак — подписать образ во время создания.

GitHub является одним из основателей Open Software Security Foundation (OpenSSF), отраслевой группы, занимающейся созданием решений с открытым исходным кодом для защиты разработчиков от угроз безопасности. Один из проектов, спонсируемых OpenSSF, — это sigstore, который позволяет разработчикам безопасно создавать, распространять и проверять подписанные артефакты ПО.

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

Для подписи контейнеров используется инструмент cosign. Он поддерживает несколько типов ключей подписи, а также добавление аннотаций вида ключ-значение к подписи.

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

cosign generate-key-pair

который вы сохранили в секретах репозитория GitHub Actions под именем SIGNING_SECRET. Подписать контейнер в рабочем процессе можно, выполнив что-то вроде:

...

jobs:
  build:
    steps:
      # ... шаги сборки

- uses: sigstore/cosign-installer@main
- name: Write signing key to disk (only needed for `cosign sign --key`)
  run: echo "${{ secrets.SIGNING_SECRET }}" > cosign.key

- name: Sign container image
  run: |
    cosign sign --key cosign.key \
      -a "repo=${{ github.repository }}" \
      -a "workflow=${{ github.workflow }}" \
      -a "ref=${{ github.sha }}" \
      ghcr.io/your-org/your-repo:some-tag
    env:
      COSIGN_PASSWORD: ""

Заметьте, что в подпись добавлены аннотации репозитория, рабочего процесса и ссылки на коммит. Вот и всё.

Затем проверить подпись после получения образа можно с помощью команды:

cosign verify --key cosign.pub ghcr.io/your-org/your-repo:some-tag

А используя инструменты fulcio и Rekor от sigstore вы можете подписывать свои образы контейнеров с помощью токена OIDC, предоставленного GitHub, без необходимости предоставления и поддержки собственного закрытого ключа.

Источник: https://github.blog/2021-12-06-safeguard-container-signing-capability-actions/

День 1087. #ЗаметкиНаПолях
Зачем Использовать DateTimeOffset
DateTime повсеместно используется как тип свойств сущностей и полей базы данных, но если вас действительно волнует временная часть значения, она часто неоднозначна. В каком часовом поясе указана дата? Она сохраняется как UTC? Всегда? Вы уверены? DateTimeOffset решает эту проблему.

Хранение значений DateTime
Тип DateTime всегда подразумевает время локальной машины. Когда вы запрашиваете .Today или .Now, он использует локальные системные часы. Это может легко вызвать проблемы между машинами с разным временем и/или часовыми поясами:

var now = new DateTime(2022,1,20,18,11,30);
Console.WriteLine(now);
// 1/20/2022 6:11:30 PM

Console.WriteLine(now.ToLocalTime());
// 1/20/2022 9:11:30 PM

Console.WriteLine(now.ToUniversalTime()); 
// 1/20/2022 3:11:30 PM

Изначальное время — 18:11 20 января 2022 года на моем компьютере в московском часовом поясе. Переменная now не содержит данных о часовом поясе. Функции ToLocalTime и ToUniversalTime предполагают, что данные, с которыми они работают, представлены в формате UTC или по местному времени соответственно. В результате время, полученное с помощью ToLocalTime, неверно, так как оно добавляет 3 часа к фактическому времени 18:11.

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

Что произойдёт, когда один и тот же код запустится на машинах разработчиков в разных часовых поясах? Что произойдёт при запуске тестов? А если вы переместите своё облачное приложение из одного региона в другой?

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

DateTimeOffset является типом как в .NET, так и в SQL Server (в других базах данных тоже есть эквиваленты). Основное отличие между ним и более простым DateTime в том, что он включает смещение часового пояса от UTC. Таким образом, при взгляде на DateTimeOffset всегда ясно, какое время имеется в виду, будь то UTC или местное время.

Добавим к примерам выше аналоги с DateTimeOffset:

var nowHere = new DateTimeOffset(now);

Console.WriteLine(nowHere);
// 1/20/2022 6:11:30 PM +03:00

Console.WriteLine(nowHere.ToLocalTime());
// 1/20/2022 6:11:30 PM +03:00

Console.WriteLine(nowHere.ToUniversalTime());
// 1/20/2022 3:11:30 PM +00:00

Мы видим 2 изменения:
- значение ToLocalTime правильное,
- строковые представления даты включают смещение часового пояса.

DateTimeOffset в SQL Server
DateTimeOffset использует переменную точность и поэтому может занимать больше места, чем DateTime. Если вы хотите увидеть разницу, выполните следующие запросы:

select GetDate()
select SYSDATETIME()
select SYSDATETIMEOFFSET()

Результаты (заметьте разницу в точности):

2022-01-20 18:30:18.227
2022-01-20 18:30:18.2292271
2022-01-20 18:30:18.2292271 -05:00

EF Core прекрасно поддерживает DateTimeOffset.

Итого
Значения DateTime не имеют сведений о смещении часового пояса или его отсутствии (в UTC). Если вам нужно знать, когда что-то произошло на самом деле, с большей точностью, чем просто приблизительная дата, и вы не можете быть на 100% уверены, что ваши даты ВСЕГДА хранятся в формате UTC, вам следует рассмотреть возможность использования DateTimeOffset для представления значений даты и времени. Этот тип указывает смещение, таким образом, может устранить множество ошибок, от которых страдают многие системы реального мира.

Источник: https://ardalis.com/why-use-datetimeoffset/

День 1088. #ВопросыНаСобеседовании #Карьера #Юмор
Расскажите, Как Вы Провалили Собеседование
Наткнулся недавно на замечательный тред в Твиттере, который начался с такого текста:
«Давайте расскажем всем, что провал на интервью – это нормально. Это не является желаемым результатом, но это случается. И когда это действительно происходит, охота провалиться сквозь землю.
Расскажите о случае, когда вы реально завалили интервью. Бонус, если вы его завалили, когда уже были сеньором.»

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

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

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

pixelbeat_: «Я провалил предварительное интервью по телефону в Google, где они задавали вопросы по Unix. Я старался изо всех сил и думал, что у меня все хорошо. Обратная связь заключалась в том, что я недостаточно знал о командах Unix, что обидно, учитывая, что я и тогда, и сейчас сопровождаю GNU coreutils.»

b0rk: «Однажды я проходил собеседование на должность разработчика ядра в Apple и описывал, как исправил действительно запутанную ошибку. Интервьюер спросил, как я это диагностировал, и я сказал: «Э-э… я попросил помощи в Твиттере, и кто-то сказал мне, что не так». Они не впечатлились ответом :)»

Bry_larrea: «Я назвала компанию именем их конкурента три раза, пока интервьюер не поправила меня. Умерла внутри и продолжила дальше.
(Все-таки, получила работу. Милостивые интервьюеры)»

DeborahKurata: «Я была менеджером по программному обеспечению более 5 лет. Чтобы лучше управлять, я выучила C++.
Проходила собеседование на должность менеджера в другой компании. Прошла все собеседования, кроме последнего, с командой. Самоучка, я не знала разницы между «свойством» и «методом», поэтому они меня завалили…
После этого я углубилась в эту тему и написала несколько книг по ООП.
Незнание нескольких терминов не должно быть причиной провала собеседования, особенно если вы знаете понятия.
В итоге все получилось… Я открыла свою компанию.»

GameDevMum: «Совсем недавно у меня было интервью, первое за долгое время после того, как я стала матерью во время пандемии. Муж должен был наблюдать за нашим ребёнком, она ускользнула от него, пробежала голой позади меня, вскочила мне на колено и… показала голый зад интервьюеру. Я не получила работу.»

EricFishor: «Помню, первая часть прошла как по маслу, мы поладили, они были впечатлены моими ответами и т. д.
Затем они попросили меня, написать код алгоритма сортировки на доске. Я посыпался на нём. Зачем кодировать что-то встроенное, а доски — ужасные редакторы кода.
Я ушел в нехорошем настроении, а они решили выбрать кого-то другого, кто «лучше справился с технической частью интервью». «Технической частью» был тест на доске. (Я добавил несколько функций и исправлений ошибок в сам фреймворк, на котором они меня тестировали)»

iandouglas736: «Хорошо прошёл все технические части, но мне начали задавать вопросы про американский футбол, о котором я НИЧЕГО не знал. Я из Канады, спросите меня о хоккее, но кому, чёрт возьми, нужен ваш Хайсман трофи?
Команда фентези-футбола из Yahoo – вот кто меня собеседовал.»

JennyMaMTL: «10 лет назад, когда мне было 22, я проходила собеседование с правительством на должность аудитора. Я нашла время, чтобы распечатать дополнительный экземпляр своего резюме, положить его в красивую папку и передать им во время собеседования. Я случайно положила внутрь одобрение ипотеки… не получила работу.»

Источник: https://twitter.com/engineering_bae/status/1395447011902636033

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

Поддержка интеграционных тестов в WebApplicationFactory
В предыдущем посте мы рассмотрели изменения, внесённые в HostBuilder для поддержки HostFactoryResolver, используемого инструментами EF Core. Это было достигнуто за счёт добавления дополнительных событий DiagnosticSource в HostBuilder. Они позволяют HostFactoryResolver получить доступ к HostBuilder без необходимости использовать соглашения предыдущих версий.

Инструментам EF Core просто необходимо получить доступ к построенному IHost, чтобы извлечь из него IServiceProvider, поэтому запущенное фоновое приложение останавливалось. Однако WebApplicationFactory должна иметь возможность модифицировать HostBuilder вашего приложения до вызова Build(). Кроме того, ей требуется, чтобы приложение продолжало работать для отправки в него тестовых запросов.

WebApplicationFactory предоставляет несколько способов настройки вашего приложения в интеграционных тестах, но по своей сути он предоставляет способ запуска экземпляра хоста вашего приложения в памяти. Один из основных методов в этом процессе — EnsureServer(). Он отвечает за создание тестового сервера, предварительно получая экземпляр IHostBuilder. IHostBuilder он пытается получить через Program.CreateHostBuilder(), обычно используемый в ASP.NET Core 3.x/5. Если это не удаётся, он ищет метод Program.CreateWebHostBuilder(), используемый в ASP.NET Core 2.x. Если и это не удается, он прибегает к подходу .NET 6.

В этом подходе используется новый тип DeferredHostBuilder. DeferredHostBuilder предназначен для «захвата» вызываемых в нём методов конфигурации (например, ConfigureServices()), а затем «воспроизведения» их для IHostBuilder реального приложения, как только он станет доступен. Методы «отсрочки» собирают методы конфигурации в виде мультикаст-делегата, а делегаты затем применяются к IHostBuilder, когда вызывается событие HostBuilding экземляра DiagnosticSource.

Затем запускается процесс, описанный в предыдущем посте, в котором приложение выполняется в отдельном потоке, с помощью событий DiagnosticSource вызывается настройка ConfigureHostBuilder() и возвращается экземпляр IHost. При этом приложение в отдельном потоке не перестаёт работать, потому что нам нужно, чтобы остальной код в Program.cs приложения выполнился. DeferredHostBuilder сохраняет IHost в новый тип DefferedHost.

DeferredHost отвечает за ожидание правильного запуска приложения. Ему нужно подождать, пока будут настроены все конечные точки, а также исполнится любой дополнительный стартовый код. Это достигается через существующие события IHostApplicationLifetime, которые вызываются в обычном приложении на универсальном хосте при запуске. В частности, вызов NotifyStarted() вызывает событие ApplicationStarted, которое DeferredHost использует для определения того, что приложение запущено, и можно безопасно запускать тесты. См. рисунок ниже.

После этого WebApplicationFactory создаёт HttpClient, как и в предыдущих версиях, и вы можете выполнять вызовы к приложению в памяти, как и раньше. Стоит знать, что (в отличие от предыдущих версий ASP.NET Core) в ваших тестах будет исполнено всё, что содержится в Program.cs приложения. Но, помимо этого нюанса, всё в вашем тестовом коде останется прежним.

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

Источник: https://andrewlock.net/exploring-dotnet-6-part-4-building-a-middleware-pipeline-with-webapplication/