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

Задача
Имеется коллекция «ключ/значение» (например, кэш в памяти), которая должна поддерживаться в синхронизированном состоянии, даже если несколько потоков выполняют с ней операции чтения и записи.

Решение
Тип ConcurrentDictionary<TKey, TValue> является потокобезопасным гарантирует быстрый доступ в подавляющем большинстве сценариев. Его API сильно отличается от стандартного типа Dictionary<TKey, TValue>, поскольку он должен иметь дело с конкурентным доступом из многих потоков.

Запись
Чтобы задать значение для ключа, используйте метод AddOrUpdate:

var d = new ConcurrentDictionary<int, string>();
string newValue = d.AddOrUpdate(
  0,
  key => "Zero",
  (key, oldValue) => "Zero"
 );

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

Чтобы конкурентный словарь работал правильно, может оказаться, что метод AddOrUpdate должен вызвать один (или оба) делегата несколько раз. Такое бывает очень редко, но это возможно. А значит, делегаты должны быть простыми и быстрыми и не должны иметь побочных эффектов, т.е. должны только создавать значение, не изменяя никакие другие переменные в приложении.

Добавить значение в словарь можно и через индекс:

// Добавляет (или обновляет) ключ 0, 
// связывая с ним значение "Zero".
d[0] = "Zero";

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

Чтение

bool keyExists = d.TryGetValue(0, out string current);

TryGetValue вернёт true и задаст значение current, если ключ был найден в словаре. Если ключ не найден, TryGetValue вернет false. Прочитать значение можно и через индекс, но при отсутствии ключа будет выдано исключение.

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

Удаление
Аналогично чтению:

bool keyExisted = d.TryRemove(0, out string removed);

Хотя ConcurrentDictionary<TKey, TValue> является потокобезопасным, это не означает атомарности его операций. Если несколько потоков вызывают AddOrUpdate конкурентно, может оказаться, что два потока обнаружат отсутствие ключа, а затем оба одновременно выполнят своего делегата, создающего новое значение.

ConcurrentDictionary<TKey, TValue> хорошо работает при чтении и записи со стороны нескольких потоков в общую коллекцию.
Если обновления относительно редки, возможно, ImmutableDictionary<TKey, TValue> будет более подходящим вариантом.

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

День 1213. #Карьера
7 Полезных Негласных Правил Собеседования
Кандидат после окончания собеседования часто остаётся в неведении. Насколько хорошо вы справились? Что означает, если вам не отвечают после интервью? Несколько HR-специалистов раскрыли известные им негласные правила собеседования, которые должен знать каждый.

1. Интервьюеры хотят саммари, а не список всего, что вы делали
Кандидатов гарантированно спросят «Рассказать о себе» и «Почему вас интересует наша компания?». Возникает соблазн просто повторить, что написано в резюме. Но интервьюеры ожидают, что вы кратко расскажете о своей карьере.
Вопрос «Расскажите нам о времени, когда…?» - о вашей компетентности: «Выполняли ли вы подобную работу раньше?» и «Есть ли у вас голова на плечах?»
Вопрос «Есть ли у вас какие-либо вопросы?» - о серьёзности ваших намерений: «Так ли вам нужно это место, что вы поискали информацию о компании, и имеете вопросы, которых не смогли найти в Google?»

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

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

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

5. Последующие звонки не ускорят найм
Когда интервью прошло, а работодатель молчит, это неприятно. Хорошая новость, что зачастую ничего личного, и это связано с другими интервью или внутренней бюрократией.
Но не стоит перезванивать или слать email с вопросами. Это не изменит мнение интервьюеров об их решении. Никому не нравится это получать. Ещё никого не принимали после повторного email. Если прошло слишком много времени, просто примите это и двигайтесь дальше. Лучше иметь вариант в запасе.

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

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

Источник: https://www.huffpost.com/entry/unspoken-job-interview-rules-everyone-needs-know_l_627aaa57e4b00fbab634c2bd

День 1214. #Юмор
10 Стереотипных Типов Программистов
Согласно стереотипам, все программисты делятся на 10 типов:

1. Техногик
Всегда в тренде. У него последний мак, огромный кривой монитор, умный дом, которым он управляет со смартфона, и он использует только самый модный на данный момент язык программирования. На его книжной полке руководства по всем бывшим модным языкам, но про них он вспоминать не любит.

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

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

4. Брограммист
Этот вид появился сравнительно недавно. У него айтишное образование, полученное в перерывах между тусовками, куча друзей, и он душа компании. Он выдаёт тонны нетестируемого говнокода (потому что тесты для слабаков). В итоге он вырождается в вашего менеджера и достаёт команду обзорами кода и занятиями по тимбилдингу.

5. Женщина
Редкий вид, особенно учитывая, что на заре программирования женщины доминировали. Кэтлин Бут создала первый ассемблер, Грейс Хоппер – первый компилятор, а Маргарет Хемильтон возглавляла команду, написавшую код посадки Апполона на Луну. Код настолько безупречный, что некоторые приводят это как доказательство фейковости лунной миссии. Этот код был вершиной программирования, с тех пор всё полетело в …

6. Кодфлюенсер
Основное место обитания этого вида – не IDE, а соцсеть (чаще всего твиттер). После того, как кодфлюенсер узнаёт, как написать «Hello World» на PHP, его ЧСВ взлетает до небес, и он спешит поделиться с миром этим сокровенным знанием. Так он делает мир чуточку лучше. А поскольку он профи в умении себя продать, его должность лучше, а ЗП выше, чем у вас. Смиритесь.

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

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

9. Ленивый Богатей
Если вы последите за его работой, то кажется, что всё, что он делает, это копирует код со Stackoverflow. На самом деле он создаёт ПО для многомилионного стартапа, чтобы выйти на пенсию к 30. А ещё у него есть подработка с ЗП в 300КК. При этом он питается дошираком и живёт в однушке с четырьмя такими же как он. Весь его гардероб – футболки с конференций, и то, что ему купила мама.

10. Усталый Старик
Его вы узнаете по седой бороде. Он пишет на C (не C++), и уж точно не использует весь этот ваш хипстерский новомодный мусор. На самом деле, он скорее всего написал компилятор для этого вашего модного игрушечного языка. Глубина его знаний выходит за границы понимания обычных приматов. С помощью психоделиков он узнал, что на самом деле мы все – одна большая сущность, разделённая на множество тел для познания вселенной. А компьютеры – инструмент, который поможет нам снова воссоединиться.

Узнали себя? Давайте посмотрим, кого среди нас больше. Только честно. Не беспокойтесь, опрос ниже анонимный.

Источник: https://youtu.be/_k-F-MMvQV4

День 1215. #ЧтоНовенького
Закрытый Превью Туннелирования Портов в Visual Studio
В Visual Studio 2022 17.3 Preview 1.1 добавлена поддержка туннелирования (переадресации) портов для веб-проектов ASP.NET Core.

Туннелирование портов обеспечивает соединения между машинами, которые не могут напрямую подключаться друг к другу. Вот некоторые варианты использования:
- Разработка API, используемого Power Platform.
- Разработка веб-хука для внешнего сервиса.
- Тестирование веб-приложения на внешнем устройстве.

Чтобы попробовать эту функциональность, выполните следующие действия:
1. Подпишитесь на закрытый превью
Чтобы начать работу, зарегистрируйтесь на превью здесь. Вы должны войти в систему с той же учетной записью, которую вы используете в Visual Studio. Пока туннелирование портов не будет работать без подписки на превью.

2. Загрузите обновление Visual Studio 17.3 Превью 1.1
Вы можете скачать его здесь.

3. Включите предварительный просмотр в Visual Studio
В Visual Studio выберите Инструменты > Параметры > Предварительный просмотр функций (Tools > Options > Preview Features) и установите флажок Включить туннелирование портов для веб-приложений (Enable port tunneling for Web Applications).

4. Настройте свой проект
При разработке проектов ASP.NET Core в Visual Studio параметры запуска приложения хранятся в файле launchSettings.json. Этот файл содержит один или несколько профилей запуска для вашего веб-приложения. Чтобы разрешить создание или подключение туннеля при запуске приложения, добавьте свойство createTunnel: true в профиль запуска. Например:

{
  …
  "profiles": {
    "MyWebApp": {
      "commandName": "Project",
      "dotnetRunMessages": true,
      "launchBrowser": true,
      "applicationUrl": "https://localhost:7130",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "createTunnel": true
    }
  }
}

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

Когда веб-приложение запущено, браузер переходит не на URL локального хоста, а использует URL общедоступного туннеля вида https://<…>tunnels.api.visualstudio.com. Доступ к этому URL возможен извне вашей локальной среды. Вы можете поделиться URL с другом или коллегой, либо перейти на него с внешнего устройства (телефона или планшета). Чтобы упростить это, вы можете сгенерировать QR-код для URL-адреса в браузере Edge (если встать в поле URL в Edge, справа появится иконка для генерации QR-кода) и отсканировать код с телефона или планшета.

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

Среди известных проблем:
- Пока не поддерживаются аккаунты GitHub.
- Если у вас несколько аккаунтов в VS, доступ будет дан первому из них.
- Пока поддерживаются туннели только с анонимной аутентификацией.
- Иногда, когда клиент не следует перенаправлениям, могут возникать ошибки 302.

Источник: https://devblogs.microsoft.com/visualstudio/introducing-private-preview-port-tunneling-visual-studio-for-asp-net-core-projects/

День 1216. #ЗаметкиНаПолях #DesignPatterns
Абстракции в Разработке ПО. Начало
Разработчики ПО имеют дело с абстракциями каждый день. Но что такое абстракция?

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

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

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

Абстракции в C# и .NET
Многие языки программирования, такие как C#, определяют абстракцию как часть своей системы типов. В рекомендациях по проектированию .NET Framework есть несколько полезных рекомендаций по правильному использованию абстракций (абстрактных типов и интерфейсов), которые включают очень простое определение:
Абстракция — это тип, описывающий контракт, но не обеспечивающий полную реализацию контракта. Абстракции обычно реализуются как абстрактные классы или интерфейсы...

Альтернативой абстракции в C# является конкретный тип. В C# можно изучить любой тип и, на основании возможности создания его непосредственного экземпляра, определить, является ли этот тип абстрактным или конкретным.

Качества абстракций
Некоторые абстракции более полезны, чем другие. Согласно цитате статистика Джорджа Бокса: «Все модели ошибочны, но некоторые из них полезны.» Мы можем посмотреть на тип в C# и определить, является ли он абстрактным, но он всё равно может быть не очень полезной абстракцией. Хорошие абстракции обладают определёнными свойствами, многие из которых описаны принципами SOLID.

Хорошие абстракции не зависят от деталей
Принцип инверсии зависимостей (DIP) гласит: «Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций».

Обычно мы можем посмотреть на абстракцию изолированно и определить, следует ли она этому принципу:

public interface IOrderDataAccess
{
  SqlDataReader ListOrders();
}

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

Хороший интерфейс не должен ограничивать детали своей реализации. Интерфейсы определяют, что должно произойти; реализации определяют, как это сделать.

Мы можем заменить эту плохую абстракцию, следуя DIP, устранив зависимость от низкоуровневых деталей в определении интерфейса:

public interface IOrderDataAccess
{
  IEnumerable<Order> ListOrders();
}

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

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

Источник: https://ardalis.com/what-are-abstractions-in-software-development/
Автор оригинала: Steve “Ardalis” Smith

День 1217. #ЗаметкиНаПолях #DesignPatterns
Абстракции в Разработке ПО. Продолжение
Начало

Хорошие абстракции сфокусированы
Ещё два принципа SOLID помогают нам писать более качественные абстракции:
- Единственной обязанности (SRP)
- Разделения интерфейса (ISP)
SRP обычно применяется к классам, но помните, что когда класс реализует интерфейс, он должен реализовать его весь (если он этого не делает, то он нарушает другой принцип SOLID, принцип подстановки Лисков). Таким образом, абстракции, не соответствующие SRP, приводят к классам, не соответствующим SRP.

Один из способов «сфокусировать» интерфейс — посмотреть, как он потребляется. ISP говорит, что классы «не должны зависеть от методов, которые они не используют». Если у вас есть большие интерфейсы с множеством методов, вполне вероятно, что некоторым клиентам потребуется только их подмножество, и, таким образом, нарушится ISP.

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

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

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

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

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

Также стоит отметить, что эти принципы не являются чисто субъективными. Для пакета можно рассчитать такие вещи, как стабильность и абстрактность. Нестабильность (Instability) определяется на основании входящих (или «афферентных» Ca) и исходящих («эфферентных» Ce) зависимостей:

I = (Ce / (Ca + Ce))

Компонент, у которого нет исходящих зависимостей (он ни от чего не зависит), полностью стабилен; нестабильность = 0. Компонент, который зависит от многих других компонентов (и, возможно, не имеет компонентов, зависящих от него, что характерно, например, для многих точек входа приложений), будет иметь нестабильность, равную 1 или близкую к ней.

Абстрактность пакета можно рассчитать, используя аналогичное соотношение абстрактных и конкретных классов:

A = Сумма(абстрактные классы)/Сумма(абстрактные + конкретные классы)

В C# к абстрактным классам надо добавить и интерфейсы.

Такие инструменты, как NDepend, могут быстро рассчитать стабильность и абстрактность для любого приложения .NET.

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

Источник: https://ardalis.com/what-are-abstractions-in-software-development/
Автор оригинала: Steve “Ardalis” Smith

День 1218. #ЗаметкиНаПолях #DesignPatterns
Абстракции в Разработке ПО. Окончание
Начало
Продолжение

Запутанные (или откровенно ложные) правила абстракций
Есть некоторые «правила» абстракций, которые могут привести к путанице, если их вырвать из контекста, хотя изначальный их посыл правильный.

1. Интерфейсы — это не абстракции
Это правило Марка Симэна, автора книги «Внедрение зависимостей на платформе .NET». Марк описывает множество причин, по которым интерфейс может быть плохой абстракцией. Однако согласно всем определениям, которые мы рассмотрели в первой части, интерфейсы таки являются абстракциями. Просто некоторые из них - плохие абстракции. Значит правило стоит уточнить:
«Интерфейсы не всегда являются хорошими абстракциями»

2. Интерфейсы с одной реализацией не являются абстракциями
Это утверждение Владимира Хорикова, автора книги «Принципы юнит-тестирования» и курсов на Pluralsight. Аналогично сказанному выше, это правило стоит уточнить:
«Интерфейсы с одной реализацией не являются хорошими абстракциями».

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

Вот отрывок из книги Хорикова:
«Настоящие абстракции обнаруживаются, а не изобретаются. Открытие по определению происходит постфактум, когда абстракция уже существует, но не имеет чёткого определения в коде».

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

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

В лучшем случае мы можем сказать:
Интерфейсы с единственной реализацией в рабочем коде — это код с запашком (code smell), потому что они могут быть плохими абстракциями из-за слишком тесной связи с их единственной реализацией.

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

Итого
Существует несколько определений абстракций. Некоторые аспекты могут оцениваться как истинные/ложные, например, является ли тип в C# абстрактным или конкретным. Другим может потребоваться некоторая субъективная оценка, чтобы определить, является ли данная абстракция хорошей, подлинной, полезной и т. д. А некоторые правила, претендующие на оценку того, является ли что-то абстракцией или нет, на самом деле просто говорят о том, является ли эта вещь хорошей абстракцией (или нет).

Источник: https://ardalis.com/what-are-abstractions-in-software-development/
Автор оригинала: Steve “Ardalis” Smith

День 1219. #ЧтоНовенького
Транскодинг JSON в gRPC для .NET
gRPC — это современный способ связи между приложениями. gRPC использует HTTP/2, потоковую передачу, двоичную сериализацию и контракты сообщений для создания высокопроизводительных сервисов реального времени. .NET поддерживает создание приложений gRPC.

Однако, как и при выборе большинства технологий, при выборе gRPC по сравнению с альтернативой, такой как REST + JSON, есть компромиссы. К сильным сторонам gRPC относятся производительность и продуктивность разработчиков. Между тем, REST+JSON можно использовать везде, а его удобочитаемые сообщения JSON легко отлаживать.

Транскодинг JSON в gRPC — это расширение для ASP.NET Core, которое создаёт RESTful API для служб gRPC. После настройки транскодинг JSON позволяет вызывать методы gRPC со знакомыми HTTP концепциями:
- HTTP-глаголы
- Привязка параметров URL
- Запросы/ответы в JSON

Начало работы
1. Создайте службу gRPC. Вот здесь руководство.
2. Добавьте на сервер ссылку на пакет Microsoft.AspNetCore.Grpc.JsonTranscoding и зарегистрируйте его в коде запуска. Например:

services.AddGrpc().AddJsonTranscoding();

3. Добавьте аннотации файла .proto для привязки и маршрутов HTTP. Для этого сохраните себе файлы annotations.proto и http.proto в папку google/api вашего проекта и добавьте в ваш файл .proto строку

syntax = "proto3";

import "google/api/annotations.proto";

package greet;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply) {
    option (google.api.http) = {
      get: "/v1/greeter/{name}"
    };
  }
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

Транскодинг JSON или gRPC-Web
Оба варианта позволяют вызывать службы gRPC из браузера. Различаются способы достижения этого:
- gRPC-Web позволяет браузерным приложениям вызывать службы gRPC из браузера с помощью клиента gRPC-Web и Protobuf. Он требует, чтобы приложение создавало клиент gRPC, и имеет преимущество в отправке небольших и быстрых сообщений Protobuf.
- Транскодинг JSON позволяет приложениям вызывать службы gRPC как RESTful API с JSON. Приложению не нужно создавать клиент gRPC или знать что-либо о gRPC.

Реализация
Транскодинг JSON не является новой концепцией. grpc-gateway — это еще одна технология для создания RESTful JSON API из служб gRPC. Он использует те же аннотации .proto для сопоставления концепций HTTP со службами gRPC. Однако grpc-gateway использует генерацию кода для создания обратного прокси-сервера, который переводит вызовы RESTful в gRPC+Protobuf и отправляет их через HTTP/2 в службу gRPC. Преимущество этого подхода заключается в том, что служба gRPC не знает о RESTful API. Любой сервер gRPC может использовать grpc-gateway.

Транскодинг JSON выполняется внутри приложения ASP.NET Core. Он десериализует JSON в сообщения Protobuf, а затем напрямую вызывает службу gRPC. Это даёт преимущества для разработчиков приложений .NET:
- И службы gRPC, и сопоставленный RESTful JSON API выполняются из одного приложения ASP.NET Core.
- Транскодинг JSON десериализует сообщения JSON в Protobuf и напрямую вызывает службу gRPC. Выполнение этого в процессе даёт значительные преимущества в производительности по сравнению с новым gRPC-вызовом на другой сервер.

Что дальше
Транскодинг JSON в gRPC доступен в .NET 7 Превью 4. Это первый выпуск. Будущие версии .NET 7 будут сосредоточены на повышении производительности и поддержке OpenAPI.

Подробная информация доступна в документации. Также можно посмотреть пример приложения или видео с демонстрацией функционала.

Источник: https://devblogs.microsoft.com/dotnet/announcing-grpc-json-transcoding-for-dotnet/

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

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

Понимание эффекта Зейгарник и того, как он работает, даёт вам возможность повысить свою продуктивность.

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

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

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

4. Завершайте день списком дел
Чрезмерное беспокойство о незавершённых задачах приводит к бессонным ночам. Составьте четкий план того, что вам осталось сделать. Важно, чтобы план был конкретным. Мысль «мне следует заняться спортом» беспокоит подсознание, потому что привлекает внимание к неудовлетворенным целям и оставляет подсознание в неуверенности, как действовать дальше. Мысль «Я пойду на пробежку завтра утром перед работой» позволяет подсознанию точно знать, как действовать дальше, и ему больше не нужно беспокоить сознание навязчивыми мыслями о занятиях спортом. Чтобы отключить мысли о незавершённой работе, посвящайте некоторое время в конце каждого дня обзору достижений за день, и плану, что ещё нужно сделать и как. Ваше подсознание любит, когда план складывается воедино. Хоть как-нибудь.

Источник: https://scitechdaily.com/boost-your-productivity-with-the-zeigarnik-effect/

День 1221. #ЗаметкиНаПолях
Добавляем Startup.cs в Минимальные API
С минимальными API в .NET 6 просто начать, но по мере роста проекта какие-то части из Program.cs лучше всё-таки вынести. Рассмотрим, как вернуть файл Startup.cs в проект минимальных API.

Вот пример файла Program.cs с использованием минимальных API:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

if (!app.Environment.IsDevelopment()) {
  app.UseExceptionHandler("/Error");
  app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthorization();
app.MapRazorPages();
app.Run();

Здесь всё написано в одном классе Program.cs. Мы создаём построитель приложения, регистрируем зависимости, строим приложение и добавляем промежуточное ПО.
Startup.cs содержит 2 метода: ConfigureServices() для регистрации зависимостей и вызова промежуточного ПО в методе Configure().

Соответственно, всё, что идёт до строки

var app = builder.Build();

должно попасть в ConfigureServices. А всё, что после – в Configure.

public class Startup {
  public IConfiguration configRoot { get; }
  public Startup(IConfiguration configuration) {
    configRoot = configuration;
  }

  public void ConfigureServices(IServiceCollection services) {
    services.AddRazorPages();
  }

  public void Configure(WebApplication app, IWebHostEnvironment env) {
    if (!app.Environment.IsDevelopment()) {
      app.UseExceptionHandler("/Error");
      app.UseHsts();
    }
    app.UseHttpsRedirection();
    app.UseStaticFiles();
    app.UseRouting();
    app.UseAuthorization();
    app.MapRazorPages();
    app.Run();
  }
}

Теперь нужно вызвать класс Startup из Program.cs:

var builder = WebApplication.CreateBuilder(args);
var startup = new Startup(builder.Configuration);
startup.ConfigureServices(builder.Services);
var app = builder.Build();
startup.Configure(app, builder.Environment);

Заметьте, что называть методы именами ConfigureServices и Configure вовсе не обязательно. Тем более, что они похожи и часто путают (особенно новичков). Вы можете задать любые имена.

Источник: https://www.c-sharpcorner.com/article/how-to-add-startup-cs-class-in-asp-net-core-6-project/

День 1222. #ЗаметкиНаПолях #AsyncTips
Блокирующие очереди

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

Решение
Тип .NET BlockingCollection<T> проектировался для создания таких коммуникационных каналов. По умолчанию BlockingCollection<T> работает в режиме блокирующей очереди и предоставляет поведение «первым зашел, первым вышел».

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

private readonly BlockingCollection<int> _bq =
new BlockingCollection<int>();

Обычно поток делает что-то одно: либо добавляет элементы в коллекцию, либо удаляет элементы. Потоки, добавляющие элементы, называются потоками-производителями, а потоки, удаляющие элементы, называются потоками-потребителями.

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

_bq.Add(7);
_bq.Add(13);
_bq.CompleteAdding();

Потоки-потребители обычно выполняются в цикле, ожидая следующего элемента и выполняя его последующую обработку. Если выделить код производителя в отдельный поток (например, вызовом Task.Run), то эти элементы можно будет потреблять следующим образом:

// Выводит "7", затем "13".
foreach (int item in _bq.GetConsumingEnumerable())
Console.WriteLine(item);

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

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

Блокирующие очереди хорошо работают при наличии отдельного потока (например, из пула потоков), действующего как производитель или потребитель. Они не настолько хороши, если вы хотите обращаться к коммуникационному каналу асинхронно — например, если UI-поток должен действовать в режиме потребителя. Если вы вводите в своё приложение подобный коммуникационный канал, подумайте о переходе на библиотеку TPL Dataflow. Во многих случаях решение с использованием TPL Dataflow проще самостоятельного построения коммуникационных каналов и фоновых потоков.
Тип BufferBlock<T> из TPL Dataflow может работать как блокирующая очередь, к тому же TPL Dataflow позволяет построить конвейер или сеть для обработки. Впрочем, во многих простых случаях обычные блокирующие очереди (например, BlockingCollection<T>) станут более подходящим вариантом при проектировании.

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

День 1223. #МоиИнструменты
VoidTools "Everything"
Сегодня расскажу об очень полезной утилите, которую мне посоветовал коллега.

VoidTools "Everything"
"Everything" — это поисковая система для Windows, которая мгновенно находит файлы и папки по имени. В отличие от поиска Windows, "Everything" при открытии отображает все файлы и папки на вашем компьютере (отсюда и название). Вы вводите фильтр поиска, чтобы отфильтровать отображаемые файлы и папки.

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

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

И ещё парочка «хаков» для улучшения работы.

Смотрим содержимое нестандартных файлов
Хотя "Everything" позволяет посмотреть содержимое множества разных типов файлов, в том числе текстовых, Microsoft Office, картинок, .cs файлов и т.п., некоторые могут не поддерживаться. Например, файлы .csproj, как показано на картинке ниже. Чтобы это исправить, нужно внести небольшое изменение в реестр. Создайте файл <имя>.reg и добавьте в него следующее содержимое:

REGEDIT4

[HKEY_CLASSES_ROOT\.CSPROJ]   
"Content Type"="text/plain"  
"PerceivedType"="text"

Сохраните файл. Затем двойным щелчком на файле внесите изменения в реестр. После этого этот тип файлов можно будет посмотреть в виде текста. Понятно, что это глобальная настройка отображения для Windows. "Everything" просто использует эти значения.

Горячая клавиша с использованием клавиши Windows
Можно назначить для нового поиска в "Everything" (да и для чего угодно ещё) горячую клавишу с кнопкой Windows, например, Win+S. Поэтому его можно отключить, добавив значение в реестр. Аналогично предыдущей, это глобальная настройка.
Зайдите в Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced и добавьте новое значение Expandable String Value с именем DisabledHotKeys и значением S.
Перезагрузите Windows. После этого сочетание Win+S перестанет работать (если что, это глобальный поиск, его также можно открыть по Win+Q). После этого в "Everything" зайдите в Tools > Options > General > Keyboard и задайте для File | New Search Window значение Win+S. Некоторые сочетания с клавишей Windows сработают и без изменений в реестре (например, Win+Y или Win+J). Однако, возможно, в будущем им в Windows будет назначено какое-нибудь действие, тогда они работать перестанут.

День 1224. #ЗаметкиНаПолях
Несколько Папок для Статических Файлов в ASP.NET Core
Если вам по какой-то причине нужно разделить ваши статические файлы (к примеру, JS/CSS/картинки в одной папке, и файлы, которые могут скачивать пользователи – в другой), наивным – но неправильным - решением будет использовать UseStaticFiles дважды:

app.UseStaticFiles();

app.UseStaticFiles(new StaticFileOptions()
{
  // Добавляем ещё папку
  FileProvider = new PhysicalFileProvider(
    Path.Combine(
      builder.Environment.ContentRootPath, 
      "Docs"
    ))
});

На первый взгляд, это работает. Промежуточное ПО будет искать файлы в обычной папке wwwroot, а затем в папке Docs и возвращать их. Проблема возникает, если вы попытаетесь использовать что-нибудь, типа asp-append-version в представлениях для файлов из Docs. Версия просто не будет добавляться. Добавление версии в URL зависит от контрольной суммы файла. В этом случае система не может её найти, и этот атрибут просто будет проигнорирован.

StaticFiles на самом деле используют не просто промежуточное ПО для поиска файла, а полагаются на WebRootFileProvider. Но что такое FileProvider?

В документации есть хорошая статья об этом. Если коротко, это сервис, который знает, как находить файлы разными способами. Платформа имеет несколько реализаций, включая PhysicalFileProvider или ManifestEmbeddedFileProvider. В нашем плохом примере выше используется PhysicalFileProvider. А на самом деле UseStaticFiles использует WebRootFileProvider для поиска статических файлов (и этот провайдер просто ищет в wwwroot). Таким образом, реальный способ справиться с проблемой — изменить WebRootFileProvider приложения.

Итак, нам нужен способ использовать оба провайдера сразу. Сначала создадим нужные нам провайдеры (в данном примере два):

var webRootProvider = 
  new PhysicalFileProvider(
    builder.Environment.WebRootPath
  );

var docPathProvider = 
  new PhysicalFileProvider(
   Path.Combine(
    builder.Environment.ContentRootPath, 
    "Docs"
   ));

Теперь нам нужен третий тип, который позволит объединить наши провайдеры. Этот провайдер называется CompositeFileProvider:

var compositeProvider = 
  new CompositeFileProvider(
    webRootProvider,
    docPathProvider
  );

И наконец, заменяем WebRootFileProvider нашим новым CompositeFileProvider:

app.Environment.WebRootFileProvider = compositeProvider;
app.UseStaticFiles();

Источник: https://wildermuth.com/2022/04/25/multiple-directories-for-static-files-in-aspnetcore/

День 1226. #ЧтоНовенького
Критическое Изменение: Удаление Привязки HTTPS по Умолчанию в Kestrel
Привязка адреса и порта HTTPS по умолчанию удалена в Kestrel в превью версии 6 .NET 7.

Предыдущее поведение
Раньше, если значения для адреса и порта не указывались явно, но был доступен локальный сертификат для разработки, Kestrel по умолчанию привязывался как к https://localhost:5000, так и к https://localhost:5001.

Теперь пользователи должны вручную привязываться к HTTPS и явно указывать адрес и порт одним из следующих вариантов:
- в файле launchSettings.json,
- в переменной среды ASPNETCORE_URLS,
- в аргументе командной строки --urls,
- в конфигурации хоста по ключу urls,
- с помощью метода расширения UseUrls.

Привязка HTTP не изменилась.

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

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

Рекомендованное действие
Если вы не использовали привязку https://localhost:5001 по умолчанию, никаких изменений не требуется. Однако, если вы использовали эту привязку, ознакомьтесь с этим руководством где описано, как вы можете обновить свой сервер, чтобы включить HTTPS.

Источник: https://github.com/aspnet/Announcements/issues/486