День семьсот тридцатый. #ЗаметкиНаПолях
Как Работает Git. Окончание
Начало
Версии
Ветки
Rebase

Распределённость
Мы наконец добрались до верхнего слоя определения Git (распределённая система контроля версий). Допустим, мы создали репозиторий на GitHub. Получить копию его на локальном компьютере можно с помощью команды

git clone <адрес репозитория>

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

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

При клонировании репозитория через git clone добавляется несколько строк в конфигурацию нашего репозитория (файл .git/config):

[remote "origin"]
  url = https://github.com/user/repo
  fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
  remote = origin
  merge = refs/heads/main

Каждый репозиторий Git может запоминать информацию о других копиях, которые называются удалёнными (remote). Копия по умолчанию называется origin. В конфигурации сохраняется url удалённого репозитория, а также связь локальной ветки main с веткой main из origin. Вы можете настроить эту конфигурацию, чтобы изменить политику синхронизации.

Git также требуется сохранять состояние локального и удалённого репозиториев. Для состояния удалённого репозитория используется папка .git/refs/remotes/origin. Здесь мы можем видеть знакомые нам файлы HEAD и main, предназначение которых такое же, как и у их локальных копий: main хранит ссылку на последний коммит, HEAD – ссылку на текущую ветку.
Иногда из-за внутренних оптимизаций файл main может отсутствовать, и тогда информация о состоянии репозиториев будет храниться в файле .git/packed-refs. Посмотреть состояние локального и удалённого репозиториев можно с помощью команды git show-ref.

Синхронизация
Команда git push сохраняет локальные изменения и коммиты в удалённый репозиторий. Это просто, когда репозитории изначально были синхронизированы (см. красный коммит в левой части рисунка ниже). Тогда ваши изменения (фиолетовый коммит) будут сохранены, ссылка main в удалённом репозитории и origin/main в локальном перейдут на новый коммит.

Однако, если кто-то другой добавил коммит в удалённый репозиторий, возникает конфликт. Решить его можно двумя способами:
1. Принудительный push
Команда git push -f принудит внести ваши изменения в удалённый репозиторий (см. в средней части рисунка ниже). Тогда указатель ветки main перейдёт на ваш коммит (фиолетовый), а коммит, сделанный другим человеком (зелёный), со временем будет удалён сборщиком мусора, как будто его и не было.
2. Разрешение конфликта
Сначала выполняется команда git fetch, которая получит данные из удалённого репозитория в ваш локальный (см. в правой части рисунка ниже). Далее командой git merge origin/main удалённая ветка сливается с вашей локальной в новый коммит (розовый). Это настолько частый случай, что для этих операций есть отдельная команда git pull. После этого команда git push сохранит все получившиеся изменения в удалённом репозитории.

Источник: https://app.pluralsight.com/library/courses/how-git-works

День семьсот тридцать первый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
75. Боритесь со Стрессом
Каждый из нас, будь то начинающий или опытный программист, когда-нибудь попадал в ситуацию, когда всё бесит. Задача не решается, мелкий пакостный баг никак не получается отловить, компоненты или фреймворки отказываются работать друг с другом, IDE тормозит, кто-то постоянно отвлекает… Такие большие и мелкие неприятности постепенно выводят из душевного равновесия, и ваша производительность катастрофически снижается. Что сделать, чтобы этого не случалось?

1. Рабочий стол
Приберитесь на рабочем столе (как реальном, так и виртуальном). Уберите отвлекающие вещи, вроде телефона. Поставьте рядом вещи, которые вас успокаивают, с которыми вам уютно. Это может быть фото семьи, ваша детская игрушка, чётки или эспандер, чтобы повертеть в руке. Найдите комфортное положение в кресле. Вам удобнее сидеть прямо или откинувшись на спинку?

2. Внутренний цикл разработчика
Обычный цикл разработчики состоит в повторении трёх шагов:
- написание кода
- запуск
- отладка
Убедитесь, что переход по шагам этого цикла максимально быстр и прост. Как мы пишем веб-сайт? Пишем код, собираем проект, запускаем сайт, обновляем браузер, останавливаем сайт, делаем изменение, собираем проект… При этом каждый раз мы переключаемся между окнами, убираем руку с клавиатуры, чтобы взять мышку и наоборот. Это очень муторно.
Как ускорить этот процесс?
Во-первых, с помощью клавиш Win+стрелки можно расположить окна на экране так, чтобы не приходилось каждый раз их скрывать и разворачивать. Кстати, а вы знаете, что в Windows можно сделать несколько рабочих столов с независимыми наборами программ в каждом? Нажмите Win+Tab, и в верхней плашке вы увидите свой рабочий стол и кнопку «Новый рабочий стол» (New desktop). Туда вы можете переместить любые окна, которые вам в данный момент не нужны. Переключаться между рабочими столами можно с помощью Ctrl+Win+стрелки. Кроме того, существуют программы, позволяющие вам разделить экран на зоны (например, в треть высоты или по четвертям) окна, помещённые в зону, автоматически примут её размер.

Во-вторых, в .NET есть монитор файлов dotnet-watch. Например, команда dotnet watch run, выполненная в папке сайта, заставит dotnet следить за изменениями в папке, и как только вы сохраняете файл, будет пересобирать и перезапускать веб-приложение. Также можно настроить выполнение тестов, выбрать отслеживаемые типы файлов и т.п. И таких мелких утилит тысячи. Мы не задумываемся о таких вещах, погружённые в процесс, автоматически выполняем набор действий. Но иногда полезно последить, можно ли автоматизировать какие-то повторяющиеся процессы.

3. Навыки редактора
Изучите IDE и горячие клавиши для наиболее часто повторяемых операций. Поищите информацию о том, что вообще умеет IDE (например, см. посты по тэгу #TipsAndTricks).

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

Что вам помогает выйти из стрессовой ситуации? Оставляйте комментарии.

Источник: https://www.hanselman.com/blog/the-art-of-rubber-ducking-or-rubber-duck-debugging/
Автор оригинала – Scott Hanselman

День семьсот тридцать второй. #ЧтоНовенького
Планы на EF Core 6.0
EF Core 6.0 является следующим релизом после EF Core 5.0 и в настоящее время запланирован на ноябрь 2021 года одновременно с .NET 6. EF Core 6.0 будет соответствовать .NET 6 в качестве выпуска с долгосрочной поддержкой (LTS). Он не будет работать в .NET Framework и маловероятно, что будет поддерживать какую-либо версию .NET Standard. Приведённые ниже планы – это пока лишь предложения от сообщества, и они не обязательно будут реализованы. Кроме того, может появиться и что-то другое.

Самые востребованные функции
1. Темпоральные таблицы SQL Server
Создание темпоральных таблиц с помощью миграции, а также доступ к историческим данным с помощью запросов LINQ.

2. Столбцы типа JSON
Общие шаблоны для поддержки JSON, которые могут быть реализованы любым поставщиком базы данных. Поддержка столбцов JSON будет реализована для SQL Server и SQLite (PostgreSQL и MySQL уже их поддерживают).

3. ColumnAttribute.Order
Произвольный порядок столбцов при создании таблицы с помощью Migrations или EnsureCreated.

Производительность
1. Инфраструктура производительности и новые тесты
Улучшение инфраструктуры для тестов производительности, а также добавление новых тестов и исправление ошибок.

2. Скомпилированные модели
Скомпилированные модели улучшат производительность запуска, а также в целом улучшат производительность при доступе к модели.

3. TechEmpower Fortunes
Планируется сравниться по производительности Dapper на тесте TechEmpower Fortunes.

4. Компоновщики/AOT
Продолжатся исследования по улучшению работы EF Core с компоновщиками и AOT.

Миграции и развертывание
1. Пакеты миграций
Пакеты миграции предоставят простой и надежный механизм для развертывания миграций EF Core.

2. Управление миграциями
Планируется улучшить инструменты и управление проектами/сборками для миграций EF Core.

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

Источник: https://devblogs.microsoft.com/dotnet/the-plan-for-entity-framework-core-6-0/

День семьсот тридцать третий. #Оффтоп #КакСтатьСеньором
Что Я Узнал, Чтобы Стать Сеньором
Работник Bloomberg, пришедший туда джуниор-разработчиком, описывает свой опыт роста в компании.

7. Об Управлении
В Bloomberg у нас есть три команды, и мы используем Jenkins для автоматического тестирования. Предстояла большая задача по обслуживанию Jenkins, и я решил взять её на себя. Задача подразумевала выяснение того, как реализовать изменения, организацию встреч для обсуждения улучшений и альтернатив и, наконец, координацию релиза. Однако, когда я брал задачу на себя, я и не знал, что именно я буду делать всё это. Я просто подумал, что это будет интересно.

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

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

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

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

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

Источник: https://medium.com/better-programming/the-things-i-learned-to-become-a-senior-software-engineer-1083686d70cd
Автор оригинала – Neil Kakkar

День семьсот тридцать четвёртый. #ЧтоНовенького
Новинки в Visual Studio 2019 v16.9 Preview 3

Использование звуковых сигналов в тестах
Я считаю, что ничего лучше в VS уже не придумают. Обозреватель тестов теперь может воспроизводить настраиваемый звук после завершения прогона тестов. Вы можете выбрать два разных звука:
- после успешного прохождения тестов,
- после того, как хотя бы один тест завершится неудачей.
Настроить звуки можно в стандартных настройках звука Windows (наряду со звуками удачной/неудачной сборки, или звуком достижения точки останова). Посмотрите видео, разве это не прекрасно? https://youtu.be/VwIMIJgY3wk

Улучшение контрастной темы
IDE может определять, включены ли в Windows настройки высокой контрастности. Если эти параметры включены, Visual Studio 2019 будет учитывать эти параметры. Чтобы активировать эту функцию, перейдите в Инструменты > Параметры (Tools > Options). Обратите внимание на новый параметр «Использовать настройки высокой контрастности Windows» (Use Windows High Contrast Settings). Когда этот флажок отмечен, настройка по умолчанию будет соответствовать обнаруженным настройкам высокой контрастности Windows. Если этот флажок не установлен, вы можете выбрать любую из тем, включённых в Visual Studio 2019.

Повышение Продуктивности в .NET
1. IntelliSense теперь может выдавать подсказки для директив препроцессора. Чтобы увидеть это в действии, начните вводить директиву #if, и вы увидите доступные варианты завершения команды, определённые в настоящее время в области видимости.

2. В Обозревателе решений теперь будут отображаться новые генераторы исходного кода .NET 5.0 внутри группы Анализатор (Analyzer). Это позволит вам легко находить и просматривать сгенерированный код.

3. Функция Go To All (Ctrl+T) больше не будет отображать повторяющиеся результаты для netcoreapp3.1 и netcoreapp2.0, а также результаты для partial типов. Это поможет упорядочить результаты, чтобы вы могли легче находить код и перемещаться по нему. Результаты теперь также включают имена файлов.

Новый редактор Razor
В настройках среды найдите Предварительный просмотр (Preview Features) и отметьте флажок «Включить экспериментальный редактор Razor» (Enable experimental Razor editor).
В новом редакторе Razor есть улучшенный механизм форматирования, который более консервативен, чем старый, а также намного умнее в том, как он обрабатывает ваш код. Некоторые быстрые действия теперь также доступны в файлах Razor:
- добавление директивы @using или полного имени типа,
- добавление проверки на null,
- переименование компонентов Blazor из тегов (файл компонента будет изменён автоматически),
- создание компонента Blazor из неизвестного тега,
- извлечение блока @code в файл отделённого кода,
- переход к определению компонента Blazor по F12.

Источники:
- https://devblogs.microsoft.com/dotnet/the-plan-for-entity-framework-core-6-0/
- https://devblogs.microsoft.com/aspnet/improvements-to-the-new-razor-editor-in-visual-studio/

День семьсот тридцать шестой. #TypesAndLanguages
3. Finally при Прекращении Работы
Рассмотрим следующий код:

try {
  throw new Exception("Exception 1");
}finally{
  // очистка
}

Допустим, в этом потоке исполнения нет блока catch. Что произойдёт? Это зависит от платформы. Например, в документации C# по finally говорится:
Внутри обработанного исключения гарантируется выполнение связанного блока finally. Однако если исключение не обработано, то выполнение блока finally зависит от того, как запускается операция развертывания исключения. Это, в свою очередь, зависит от способа настройки компьютера.

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

Дальше больше, потому что всё может зависеть от типа исключения. Например, в .NET есть атрибут HandleProcessCorruptedStateExceptions:
Исключения повреждённого состояния процесса - это исключения, которые указывают, что состояние процесса было повреждено. Дальнейшее выполнение приложения в этом состоянии не рекомендуется.
По умолчанию среда CLR не передаёт эти исключения управляемому коду, и блоки try-catch (или другие способы обработки исключений) для них не вызываются. Если вы абсолютно уверены, что хотите самостоятельно обрабатывать такие исключения, вы должны применить атрибут HandleProcessCorruptedStateExceptions к методу, в котором вы хотите выполнять блоки обработки таких исключений. CLR предоставляет исключения повреждённого состояния процесса в применимые блоки обработки исключений только в методах, которые имеют атрибуты HandleProcessCorruptedStateExceptions или SecurityCritical.

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

Аналогичный вопрос возникает, когда вместо создания исключения вы выходите из приложения, вызывая Application.Exit(). Будет ли исполнен блок finally?
Зачем это нужно? Потому что мы обычно освобождаем ресурсы в блоке finally. Если эти ресурсы являются локальными для процесса, тогда это не имеет большого значения, но как только вы начнете использовать межпроцессные вещи (например, общесистемные мьютексы), важно освободить их, иначе другой пользователь может не знать, повреждено защищённое состояние или нет.

Это уже не говоря о том, что необработанное исключение может (.NET) или не может (JVM) привести к остановке всего приложения.

Вывод
Всегда помещайте в поток исполнения глобальный обработчик try-catch.

Источник: https://blog.adamfurmanek.pl/2021/01/23/types-and-programming-languages-part-3/

День семьсот тридцать седьмой. #ЗаметкиНаПолях
10 Советов по Работе с JavaScript Console
Да, сегодня про ненавистный JS. Но не поленитесь, почитайте, мне показалось полезным.
1. console.clear()
Используется для «очистки» консоли, т.е. удаляет весь предыдущий вывод. После этого появится текст «Console was cleared».

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

for(let i = 0; i < 3; i++) {  
  console.count('cnt')  
}

выведет:

cnt: 1
cnt: 2
cnt: 3

Также можно использовать метод countReset() для сброса счётчика.

3. console.table()
Используется для отображения массива в формате таблицы. Можно использовать массив объектов, тогда поля объектов будут колонками таблицы:

const users = [
  { name: 'John', age: 20 },
  { name: 'Mike', age: 22 }
];
console.table(users);

4. console.group() и console.groupEnd()
Методы используются для создания сворачиваемых групп. Принимает необязательный параметр названия группы.

console.group('Countries');
console.log('India');
console.log('Russia');
console.groupEnd();

Также можно создавать вложенные группы.

5. console.assert()
Используется для условного отображения ошибки. Первым параметром является утверждение, а вторым - сообщение или объект, который необходимо отобразить в консоли, если утверждение не выполняется. Если результат утверждения верен, в консоль ничего не выводится. В противном случае будет выведено сообщение в виде ошибки.

for (let num = 0; num <= 5; num++) {  
  console.assert(num % 2 === 0, 'Число ${num} нечётное');  
}

6. console.time() и console.timeEnd()
time() запускает таймер, а timeEnd() останавливает и выводит истекшее время.

7. console.memory
Свойство memory хранит размер кучи памяти. Может оказаться полезным при отладке проблем с производительностью.

8. console.trace()
Можно использовать для отслеживания стека функций. При вызове выводит полное дерево стека в консоль браузера.

9. console.dir()
Принимает объект и отображает список его свойств в иерархическом формате. Это может быть полезно, если вы пытаетесь исследовать элемент HTML в консоли.

10. console.log() и CSS
Можно применять стили CSS к выводу в консоли. Для этого используется модификатор %c в начале строки вывода. Вторым параметром передаётся строка свойств:

let rules = [
  'color: #ff0000',
  'background: #000000',
  'font-size: 30px',
  'padding: 100px'
].join(';');
console.log('%c Hello World', rules);  

Источник: https://www.c-sharpcorner.com/article/10-javascript-console-tricks-that-you-may-not-know/

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

CommandLineParser
Это библиотека с открытым исходным кодом, созданная Эриком Ньютоном и членами сообщества .NET. Он существует с 2005 года и его скачали более 26 миллионов раз! CommandLineParser «предлагает приложениям CLR чистый и лаконичный API для управления аргументами командной строки и связанными с этим задачами, такими как определение переключателей, обязательных и необязательных параметров и команд».

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

using CommandLine;
public class CmdLineOpts {
  [Value(index: 0, Required = true,
    HelpText = "File path.")]
  public string Path { get; set; }

  [Option(shortName: 'c', 
    longName: "confidence", Required = false,
    HelpText = "Minimum confidence.", Default = 0.9f)]
  public float Confidence { get; set; }
}

Это практически всё, что требуется для использования этой библиотеки. ValueAttribute и OptionAttribute предоставляются пакетом. Здесь первый параметр обязательный, а второй необязательный, который можно передать через короткое -с или длинное --confidence имя. Использование:

using CommandLine;
static async Task<int> Main(string[] args) {
  return await Parser.Default
    .ParseArguments<CmdLineOpts>(args)
    .MapResult(async (CmdLineOpts opts) => {
      try {
        //аргументы разобраны, используем их
        return await AnalyzeFileAsync(
          opts.Path, opts.Confidence);
      }
      catch {
        Console.WriteLine("Error!");
        return -1;
      }
    },
    errs => Task.FromResult(-1));
}

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

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

Источник: https://devblogs.microsoft.com/pax-windows/command-line-parser-on-net5/

День семьсот тридцать девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
76. Приложение не Существует в Вакууме
Никакое приложение не существует в вакууме; каждое приложение - это кусочек экосистемы, часть чего-то большего.

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

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

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

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

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

Если нас, разработчиков ПО, раздражает плохая работа приложений, представьте, что чувствует «нормальный» человек?

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

Источник: http://dontcodetired.com/blog/post/No-App-Is-An-Island

День семьсот сороковой. #ЗаметкиНаПолях
API Endpoints как Замена Контроллерам MVC
Контроллеры в MVC по сути являются антипаттерном. Это наборы методов, которые никогда не вызывают друг друга и редко работают с одним и тем же состоянием. Они не связаны, имеют тенденцию раздуваться и выходить из-под контроля. Их приватные методы, если они вообще есть, обычно вызываются только одним публичным методом. Большинство разработчиков признают, что контроллеры должны быть как можно тоньше, но это единственное решение, предлагаемое «из коробки», так что это инструмент, который используют 99% разработчиков ASP.NET Core.

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

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

Вы, конечно, можете сами создавать контроллеры, соответствующие принципу SRP, но давайте честно, вы не будете этого делать. Например, практически все согласны с тем, что прямое изменение глобального состояния из множества различных функций, классов и модулей - плохая практика. Поэтому большинство языков предлагают области видимости для локальных переменных и аргументов, а большинство ОО-языков предлагают множество способов защиты и инкапсуляции переменных с использованием таких ключевых слов, как private, protected и internal. «Но нам не нужны эти ограничения - мы можем просто использовать соглашение об именах для наших глобальных переменных, чтобы сделать то же самое!» Да, да… Дайте знать, когда это заработает.

Хорошо, как начать работать с API Endpoints?
Для начала прочитайте файл README этого репозитория. В репозитории также есть образец проекта, который вы можете просмотреть, чтобы увидеть, как использовать паттерн Request-EndPoint-Response (REPR). Другие проекты с этим подходом: шаблон Clean Architecture и справочное приложение eShopOnWeb от Microsoft.

Если у вас уже есть проект и вы просто хотите начать использовать API Endpoints вместо контроллеров, просто добавьте пакет NuGet Ardalis.ApiEndpoints, а затем создавайте конечные точки, наследуя от типов BaseEndpoint или BaseAsyncEndpoint.

Паттерн REPR
Model-View-Controller (MVC) предназначен для работы с пользовательскими интерфейсами. Если вы создаёте API, представлений нет, поэтому в лучшем случае вы используете паттерн MC или его можно назвать Model-Action-Controller. То есть вы уже не используете MVC для API, поэтому можно подумать о более подходящем паттерне.

Конечные точки в API довольно самодостаточны, и каждую из них можно описать с помощью трёх компонентов:
1. Запрос - данные, ожидаемые конечной точкой.
2. Конечная точка - логика, которую конечная точка выполняет при получении запроса.
3. Ответ - ответ, который конечная точка возвращает вызывающей стороне.
Так получается паттерн Request-EndPoint-Response или REPR.

Не всем конечным точкам требуются данные в запросе или ответе. Но пустой запрос или ответ допустим, так же как некоторые действия MVC не требуют модели.

Использование библиотеки API Endpoints позволяет сгруппировать классы запроса, конечной точки и ответа в одном месте, чтобы вам не приходилось копаться в папках типа ViewModels или DTOs в поисках нужного класса. Библиотека значительно упрощает работу с отдельными конечными точками.

Источник: https://ardalis.com/mvc-controllers-are-dinosaurs-embrace-api-endpoints/

День семьсот сорок первый. #ЗаметкиНаПолях #Blazor
10 Функций Blazor, о Которых Вы Вероятно не Знали. Начало
Хотя Blazor приобрел значительную популярность в последние месяцы, до сих пор существует много неправильных представлений о том, на что он способен. В этой серии постов мы рассмотрим некоторые из неочевидных, но не менее важных функций платформы Blazor.

1. Blazor может делать все, что могут делать HTML и CSS
Один из часто задаваемых вопросов при работе Blazor, касается использования какой-либо структуры пользовательского интерфейса, библиотеки CSS или конкретной функции CSS. Ответ однозначный: ДА, вы можете это использовать. Хотя Blazor использует шаблоны Razor для создания компонентов, результатом является HTML-код, отображаемый в браузере. HTML и CSS, сгенерированные Blazor, ничем не отличаются от любого другого HTML или CSS для браузера. Это означает, что весь допустимый HTML и CSS действителен в приложении Blazor. То есть вы можете использовать все функции CSS, включая медиа-запросы для адаптивного дизайна, настраиваемые свойства (переменные) CSS и даже препроцессоры, такие как Sass.

Компоненты формы
Blazor имеет дополнительные функции, помогающие с генерацией HTML, такие как встроенные компоненты Form и Input. Это необязательные компоненты, которые абстрагируют распространённую задачу создания формы с проверкой. В итоге компоненты отображают стандартный HTML. Эти компоненты могут полноценно использовать стандартные атрибуты HTML, такие как class, id и aria-.

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

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

2. Blazor может делать все, что умеет JavaScript
Тот факт, что Blazor использует .NET и WebAssembly, не означает, что он ограничен при работе с браузером. Платформа Blazor упрощает выполнение распространённых задач, таких как работа с DOM (рендеринг компоненты и HTML), выборка данных по HTTP и маршрутизация на стороне клиента. Хотя Blazor работает на платформах .NET и WebAssembly, он ими не ограничивается. Blazor также имеет полный доступ к API-интерфейсам JavaScript браузера благодаря взаимодействию с JavaScript (JS interop). Приложение Blazor может вызывать функции JavaScript из методов .NET и методы .NET из функций JavaScript. Взаимодействие с JavaScript используется, когда в платформе Blazor отсутствует API или компонент для желаемой функции, или когда разработчики хотели бы использовать экосистему JavaScript.

Blazor не умеет делать то, чего не умеет JavaScript
Веб-стандарты и возможности браузера эволюционировали в многофункциональную и безопасную среду. Стандартные веб-технологии, такие как WebAssembly, не только позволяют работать Blazor, но и ограничивают его теми же критериями, что и JavaScript. Просто тот факт, что Blazor работает на .NET и WebAssembly, не предоставляет ему особых возможностей, выходящих за пределы изолированной песочницы браузера (JavaScript). Это означает, что код Blazor и .NET не может читать реестр, определять текущего пользователя Windows или получать доступ к учетным записям Outlook.

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

Источник: https://www.telerik.com/blogs/10-blazor-features-you-probably-didnt-know

День семьсот сорок второй. #ЗаметкиНаПолях #Blazor
10 Функций Blazor, о Которых Вы Вероятно не Знали. Продолжение
Начало

3. Объединение MVC и Blazor в одном проекте
Есть ли способ использовать MVC и Blazor (на стороне клиента) в одном проекте?

Если вы уже работаете над приложением ASP.NET Core MVC или Razor Pages, вы всё равно можете использовать Blazor. Поскольку Blazor является частью ASP.NET Core, он довольно хорошо интегрируется с существующими приложениями. Он может как предоставить путь миграции к Blazor, так и просто добавить дополнительную гибкость вашей кодовой базе. Чтобы использовать эту функцию воспользуйтесь тег-хелпером component для рендеринга желаемого компонента в приложении MVC:

<component type="typeof(MyComponent)" render-mode="ServerPrerendered" param-Name="Value" />

В этом видео обсуждается тег-хелпер component и использование его с Blazor.

Пре-рендеринг и аутентификация
Вы можете использовать Blazor не только в приложении MVC или Razor Pages, но для серверного пре-рендеринга, а также аутентификации через Microsoft Identity. При использовании Blazor Server или Blazor WebAssembly с включенным пре-рендерингом приложение будет использовать страницы Blazor для начальной загрузки приложения. В типичном приложении Blazor Server файл _host.cshtml инициализирует клиента Blazor с помощью тег-хелпера component:

<component type="typeof(App)" render-mode="ServerPrerendered" />

Также страницы аутентификации Identity пишутся в cshtml и генерируются на сервере даже в приложении Blazor.

4. SignalR без JavaScript
Когда Blazor был впервые выпущен, SignalR можно было использовать только через библиотеки JavaScript. Теперь у Blazor есть пакет NuGet, который включает SignalR без использования JavaScript. Пакет Microsoft.AspNetCore.SignalR.Client - это всё, что вам нужно для подключения приложения Blazor к хабу SignalR, и самое главное, вы можете сделать всё это на C#. С помощью класса SignalR HubConnection приложение Blazor может подключаться к хабу, отправлять и получать команды:

// создание подключения
var hubConnection = new HubConnectionBuilder()
  .WithUrl(NavigationManager.ToAbsoluteUri("/chathub"))
  .Build();

// запуск
await hubConnection.StartAsync();
// действие при получении команды
hubConnection.On<string, string>(
  "ReceiveMessage", (user, message) => {
    var encodedMsg = $"{user}: {message}";
    messages.Add(new Message 
      { Text = encodedMsg });
});

// вызываем хаб
Task Send() => hubConnection
  .SendAsync("SendMessage", 
    userInput, messageInput);

С помощью всего нескольких строк кода можно создать приложение чата в реальном времени с использованием ASP.NET Core и Blazor WebAssembly.

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

Источник: https://www.telerik.com/blogs/10-blazor-features-you-probably-didnt-know

День семьсот сорок третий. #Оффтоп #Курсы
Сегодня расскажу паре предстоящих онлайн конференций в рамках Microsoft Azure Virtual Training Day.

1. DevOps with GitHub
Четверг, 18 февраля 2021 с 12:00 до 14:55 по Москве
Пятница, 19 февраля 2021 с 12:00 до 14:10 по Москве
Язык: английский, доступны русские субтитры

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

Темы вебинара:
- Использование GitHub для улучшения совместной работы и производительности команды.
- Интеграция средств контроля безопасности и качества в процессы автоматизации, конвейеры CI/CD и среду выполнения.
- Внедрение передовых методов для помощи удалённым командам разработчиков в повышении отказоустойчивости ПО.

2. Modernize .NET Apps
Вторник, 23 февраля 2021 с 21:00 до 00:00 по Москве
Среда, 24 февраля 2021 с 21:00 до 23:15 по Москве
Язык: английский

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

Темы вебинара:
- Оценка вариантов миграции в облако.
- Перенос приложений .NET и действующих баз данных, поддерживающих эти приложения.
- Мониторинг работоспособности и производительности перенесенных приложений в Azure.

Зарегистрироваться на вебинары можно по соответствующим ссылкам.

PS: Ну и вдруг кому будет интересно.

3. Machine Learning
С 12 апреля 2021 по 20 июня 2021.
Язык: английский
Онлайн курс от Стенфордского университета. В этом курсе представлены учебные видеоролики и задания, адаптированные из курса для выпускников специальности CS229, проведенного в кампусе Стэнфорда осенью 2018 года и осенью 2019 года. Темы курса:
- Линейная и логистическая регрессия,
- Обобщённые линейные модели (GLM),
- Гауссовский дискриминантный анализ (GDA),
- Нейронные сети,
- Максимизация ожидания и т.п.

По завершении этого курса вы получите Сертификат о прохождении курса Машинного Обучения от Стэнфордского центра профессионального развития.

Очень круто! Пара незначительных нюансов:
- преподавание и задания ведутся на Python (но до апреля есть время подучить),
- 10-недельный курс стоит $1595.

День семьсот сорок четвёртый. #ЗаметкиНаПолях #Blazor
10 Функций Blazor, о Которых Вы Вероятно не Знали. Продолжение
Начало 1-2
Продолжение 3-4

5. gRPC и Protobuf
.NET полностью поддерживает gRPC, современную высокопроизводительную среду для удалённого вызова процедур с открытым исходным кодом. С выпуском .NET 5.0 и ASP.NET Core, и Blazor получили интегрированную поддержку gRPC. Поддержка включает библиотеку для создания сервера gRPC в ASP.NET и клиента gRPC в Blazor WebAssembly. Приложения gRPC обмениваются данными между клиентом и службой через бинарный канал. Инструментарий автоматически генерирует частичные классы .NET из файлов protobuf (.proto), которые представляют конкретных клиентов и службы (см. рисунок ниже). Использование частичных классов помогает разработчикам легко их расширять при необходимости.

Клиент gRPC создаётся с использованием канала, который представляет собой долгоживущее соединение с сервисом gRPC. Канал разрешается посредством внедрения зависимостей с использованием объекта GrpcChannel.

@inject GrpcChannel Channel
<SampleGrid Data="forecasts" AutoGenerateColumns="true"></SampleGrid>

@code {
  private IList<WeatherForecast>? forecasts;
  protected override async Task
      OnInitializedAsync() {
    // Создаём клиента канала
    var client = new WeatherForecasts
      .WeatherForecastsClient(Channel);

    // Вызываем метод GetWeatherForecast
    var emptyRequest = new Google
      .Protobuf.WellKnownTypes.Empty();
    var response = await client
      .GetWeatherForecastsAsync(emptyRequest);
    forecasts = response.Forecasts;
  }
}

Этот новый протокол позволяет разработчикам выбирать между REST API c JSON, веб-сокетами с SignalR и передачей двоичных данных с использованием gRPC.

6. Используйте уже существующие библиотеки .NET
Есть большая вероятность, что существующий код .NET будет работать в Blazor без каких-либо изменений. Поскольку Blazor выполняет стандартный код .NET, это означает, что ваше приложение может использовать библиотеки DLL .NET и пакеты NuGet, которые были написаны до выпуска Blazor. Библиотеки, которые поддерживают .NET Standard или .NET Core и не ориентированы на API-интерфейсы конкретной платформы (например, Xamarin или Desktop), скорее всего, будут работать и в Blazor. Вот несколько отличных примеров библиотек:
- Markdig для преобразования строк markdown-разметки в HTML,
- FluentValidation для создания правил проверки на уровне приложения.

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

Источник: https://www.telerik.com/blogs/10-blazor-features-you-probably-didnt-know

День семьсот сорок пятый. #Оффтоп
Фарша вам в ленту. Вчера у АйТиБороды вышло интервью с Chief Software Engineer из EPAM Сергеем Тихоном. Функциональщина, F#, ML, Akka, Blazor, акторы, вот это всё. Если интересно, выделите 3 часа, устройтесь по удобнее и приятного просмотра.
https://youtu.be/t7iP7AVRNnI

День семьсот сорок шестой. #ЗаметкиНаПолях #Blazor
10 Функций Blazor, о Которых Вы Вероятно не Знали. Продолжение
Начало 1-2
Продолжение 3-4
Продолжение 5-6

7. Библиотеки классов Razor: маршрутизация и сервисы
В Blazor не только легко использовать общий код с библиотеками классов .NET, но также легко использовать общие компоненты Razor и веб-ресурсы с помощью библиотек классов Razor. Библиотеки классов Razor (RCL) могут включать CSS, JavaScript, статические файлы, такие как изображения, а также компоненты. Компоненты в RCL могут содержать директивы маршрута, и эти маршруты легко добавляются в любое приложение Blazor, которое хочет их использовать.

Настройка общей маршрутизации
В корневом компоненте приложения Blazor, App.razor, маршрутизация настраивается при помощи компонента Router. Компонент Router имеет необязательный параметр AdditionalAssemblies, который используется для поиска маршрутов из других сборок. Просто укажите сборку, и Blazor найдёт любые маршруты и добавит их в приложение. Повторяющиеся маршруты вызовут ошибку компилятора, поэтому используйте их с осторожностью.

<Router
  AppAssembly="@typeof(Program).Assembly"
  AdditionalAssemblies="new[] 
    { typeof(MyComponent).Assembly }">
  ...
</Router>

Сервисные интерфейсы для библиотек классов Razor
Компоненты в RCL также могут использовать интерфейсы для совместного использования сервисов. В зависимости от типа проекта Blazor, приложения могут запускаться на стороне клиента в WebAssembly или на сервере. Основное различие между компонентами, работающими в WebAssembly, и на стороне сервера заключается в том, как они получают данные. WebAssembly-приложению потребуется HTTP-запрос для получения данных, а серверное приложение может взаимодействовать со службами напрямую без HTTP.
На рисунке ниже мы видим схему того, как два приложения могут использовать общий компонент при делегировании сервиса данных через интерфейс.

8. Полноценное тестирование и контроль качества
Blazor - это новый фреймворк для веб-приложений, который обещает предоставить нативные возможности веб-клиента без необходимости написания кода JavaScript. Разработчики могут легко создавать полнофункциональные веб-приложения с помощью платформы и инструментов .NET. Многие выделяют этот упор на .NET как сильную сторону Blazor, однако наибольший потенциал у Blazor может быть в тестировании.
Два распространенных подхода к тестированию компонентов Blazor — это сквозное (end-to-end, E2E) и модульное тестирование:
1. Модульные тесты пишутся с помощью библиотеки модульного тестирования, и покрывают:
- рендеринг компонентов,
- проверку вывода и состояния компонентов,
- запуск обработчиков событий и методов жизненного цикла,
- утверждения, что поведение компонента правильное.
bUnit - пример библиотеки, которая позволяет выполнять модульное тестирование компонентов Razor.

2. При E2E тестировании средство выполнения тестов запускает приложение Blazor и проверяет тестируемую систему, взаимодействуя с ней через браузер. Selenium - пример среды тестирования E2E, которую можно использовать с приложениями Blazor.

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

Источники:
- https://www.telerik.com/blogs/10-blazor-features-you-probably-didnt-know
- https://docs.microsoft.com/ru-ru/aspnet/core/blazor/test