День шестьсот семьдесят седьмой. #Оффтоп #КакСтатьСеньором
Кто такой сеньор? Окончание.
Начало

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

От начала до конца
Старший разработчик способен выполнить каждый шаг на пути создания программного обеспечения:
1. Проанализировать проблему
2. Понять проблему
3. Сформировать жизнеспособное решение проблемы
4. Реализовать решение
5. Проверить решение
6. Интегрировать решение
7. Развернуть решение

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

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

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

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

Источник: https://dev.to/themarcba/what-is-a-senior-developer-really-59dg
Автор оригинала – Burk Hufnagel

День шестьсот семьдесят девятый. #ЧтоНовенького
Повышаем Продуктивность в Visual Studio 2019 v16.9 Preview 2
Под новый год разработчики Visual Studio подкинули нам действительно важных новинок. Как мы раньше без всего этого жили? Вы только оцените:
1. Автодобавление пространств имён
При копировании и вставке типов в новый файл Visual Studio 2019 теперь будет автоматически добавлять в файл недостающие директивы using. Чтобы попробовать эту опцию, включите её в меню Tools > Options > Text Editor > C# > Advanced (Инструменты > Параметры > Текстовый Редактор > C# > Дополнительно). Затем выберите Add missing using directives on paste (Добавлять недостающие директивы using при вставке).

2. Автодобавление точки с запятой
IntelliSense теперь при автозаполнении нового объекта или вызова метода будет добавлять точку с запятой в конце.

3. Новая цветовая схема для записей
В меню Tools > Options > Environment > Fonts and Colors (Инструменты > Параметры > Среда > Шрифты и Цвета) можно найти раздел User Types – Records (Пользовательские Типы – Записи) и выбрать для них особую цветовую схему.

4. Избавление от символа discard
В C#9 символ _ (discard) в некоторых случаях сопоставления с образцом не требуется. Теперь появится специальная подсказка в меню Quick Actions and Refactorings (Быстрые Действия и Рефакторинг), советующая его удалить.

Источник: https://devblogs.microsoft.com/visualstudio/visual-studio-2019-v16-9-preview-2/

День шестьсот восьмидесятый. #ЧтоНовенького #CSharp9
Ещё Раз про Сопоставления с Образцом
Я уже писал об изменениях в сопоставлении с образцом в C#9. Здесь же хочу привести некое саммари всех изменений с примерами:

1. Шаблоны типа используются для сопоставления с типом. Если тип входных данных соответствует типу, указанному в шаблоне, совпадение считается успешным.

object checkType = new int();
var getType = checkType switch {
  string => "string",
  int => "int",
  _ => "obj"
};
Console.WriteLine(getType); 
// Вывод: int

2. Реляционные шаблоны позволяют сопоставить входные данные с константами, используя знаки >, < или = (a также >= или <=):

var person = new Person("John", 42);
var person2 = new Person("Jane", 8);
var ageInRange = person switch {
  //тип Person указан явно
  Person(_, < 18) => "меньше 18",
  //тип выводится компилятором
  (_, > 18) => "больше 18",
  (_, 18) => "18!"
};
Console.WriteLine(ageInRange);
// Вывод: больше 18

3. Комбинаторные шаблоны позволяют комбинировать несколько шаблонов в одной строке:

var person = new Person("John", 42);

- Конъюнктивные представляют собой логическое «и» двух подшаблонов:

var ageInRange = person switch {
  (_, < 18) => "меньше 18",
  ("John", _) and (_, > 18) => "Джону больше 18"
};
Console.WriteLine(ageInRange);
// Вывод: Джону больше 18

- Дизъюнктивные представляют собой логическое «или» двух подшаблонов:

var ageInRange = person switch {
  (_, < 18) => "меньше 18",
  (_, 18) or (_, > 18) => "18 или больше"
};
Console.WriteLine(ageInRange);
// Вывод: 18 или больше

- Отрицательные требуют несовпадения с заданным шаблоном:

var isJohn = person switch {
  not ("John", 42) => "не Джон!",
  _ => "Джон :)"
};
Console.WriteLine(isJohn);
// Вывод: Джон :)

4. В шаблонах допустимо использовать скобки:

public record IsNumber(bool IsValid, int Number);
var num = new IsNumber(true, 10);
var zeroToTen = num switch {  
  ((_, >= 0 and <= 5) or (_, > 5 and <= 9))
    or (_, 10) => "от 0 до 10",  
  _ => "больше 10"
};  
Console.WriteLine(zeroToTen);
// Вывод: от 0 до 10

Источник: https://www.c-sharpcorner.com/article/c-sharp-9-cheatsheet/

День шестьсот восемьдесят первый. #ЧтоНовенького
Критические Изменения в .NET5. Библиотека Базовых Классов (BCL)
В .NET5 внесено несколько критических изменений. Подавляющее большинство из них связано с редкими случаями использования или некорректным поведением в прошлом. Но некоторые могут застать разработчиков врасплох. В первой части этой серии, рассмотрим изменения в BCL.

1. Информация о версии .NET
Некоторые разработчики используют строковое представление версии, а не числовую форму. В случае .NET у разработчиков не было выбора. Отчасти из-за путаницы в нумерации приходилось полагаться на строковое представление, вроде «.NET Framework #.#» или «.NET Core #.#».
В .NET5 моникер представляет из себя просто «.NET #.#». Приложения и библиотеки, зависящие от определения версии среды выполнения, необходимо обновить.

2. Информация о версии ОС
Раньше Environment.OSVersion могла лгать. Вместо возврата фактической версии ОС могла возвращаться эмулируемая ОС на основе настроек режима совместимости Windows. Теперь будет возвращаться фактическая версия, что больше соответствует ожиданиям разработчиков.

3. Расположение файлов в однофайловых приложениях
Когда приложение собрано в один файл вместе с его зависимостями, поведение некоторых API рефлексии перестаёт быть очевидным. В .NET5 все зависимости загружаются прямо из памяти, то есть физического файла сборки не существует. Ниже представлены новые варианты поведения для связанных сборок:
Assembly.Location - возвращает пустую строку,
Assembly.CodeBase - выбрасывает исключение,
Assembly.GetFile(String) - выбрасывает исключение,
Environment.GetCommandLineArgs()[0] - возвращает имя исполняемого файла,
AppContext.BaseDirectory - возвращает каталог, в котором находится исполняемый файл.

4. Логи
Следующие параметры ConsoleLoggerOptions отмечены как устаревшие: DisableColors, IncludeScopes, TimestampFormat, UseUtcTimestamp, Format. Они заменяются одним из нескольких подклассов ConsoleFormatterOptions.

5. Сериализация через BinaryFormatter заблокирована
BinaryFormatter в .NET существует с самого начала. Предполагалось, что он будет быстрее и компактнее, чем SoapFormatter, основанный на XML. К сожалению, в нём есть ряд проблем, самая важная из которых - невозможность безопасного использования. В .NET 5 BinaryFormatter по умолчанию отключен в приложениях ASP.NET и выдает предупреждение компилятора в других платформах. Если вам нужно его использовать, можно включить его с помощью флага EnableUnsafeBinaryFormatterSerialization.

6. UTF-7 заблокирована
Этот формат уже запрещён многими стандартами, такими как HTML5, потому что легко вставить вредоносные строки в приложение, заставив часть приложения думать, что данные находятся в формате UTF-8, в то время как другие части будут обрабатывать данные как UTF-7. Если необходима обработка устаревших данных, UTF-7 можно включить с помощью флага EnableUnsafeUTF7Encoding.

7. Пакет Microsoft.DotNet.PlatformAbstractions устарел
Разработчикам настоятельно рекомендуется прекратить использование пакета Microsoft.DotNet.PlatformAbstractions для получения информации об операционной системе. Ниже показаны устаревшие методы и их альтернативы:

ApplicationEnvironment.ApplicationBasePath

=> AppContext.BaseDirectory


HashCodeCombiner

=> System.HashCode


RuntimeEnvironment.GetRuntimeIdentifier

=> RuntimeInformation.RuntimeIdentifier


RuntimeEnvironment.OperatingSystemPlatform

=> RuntimeInformation.IsOSPlatform(OSPlatform)


RuntimeEnvironment.RuntimeArchitecture

=> RuntimeInformation.ProcessArchitecture


RuntimeEnvironment.OperatingSystem

=> RuntimeInformation.OSDescription
RuntimeEnvironment.OperatingSystemVersion
=> RuntimeInformation.OSDescription
и Environment.OSVersion

Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes/

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

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

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

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

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

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Karianne Berg

День шестьсот восемьдесят третий. #ЧтоНовенького
Критические Изменения в .NET5. Исторические Технологии
Начало. BCL
Во второй части нашего обзора .NET 5 рассмотрим исторические технологии .NET, которые не были перенесены в .NET Core.

Глобальный кэш сборок
Теория, лежащая в основе глобального кэша сборок (GAC), заключалась в том, чтобы все библиотеки .NET могли храниться в одном централизованном месте с возможностью хранить несколько версий каждой библиотеки, что позволило избавиться от «ада DLL». Но проблемы с версиями остались. К моменту выпуска .NET 4.5 лишь несколько приложений использовали GAC для библиотек сторонних разработчиков. Поэтому неудивительно, что в .NET Core все зависимости развёртываются вместе с приложением, что позволяет изолировать приложение от других. Тем не менее частично API GAC по-прежнему существуют в .NET Core. Они мало полезны, например, свойство, указывающее, содержится ли сборка в GAC, всегда возвращает false. Теперь все API GAC помечены как устаревшие.

Удалённое взаимодействие
Основная идея .NET Remoting в том, что одно приложение могло использовать прокси-объект для управления реальным объектом, запущенным внутри другого приложения. Хотя технически это работало, .NET Remoting никогда не пользовался популярностью из-за трудностей с его правильным использованием и нестабильности. В .NET Core API .NET Remoting не были реализованы. Как и API GAC, они имели только неработающие заполнители. Они также помечены устаревшими и будут в итоге удалены.

Защита доступа к коду
Code Access Security - ещё одна технология .NET Framework, API которой помечены как устаревшие. CAS была создана в эпоху до изолированных контейнеров, таких как Docker. В .NET Framework несколько приложений размещались в одном экземпляре IIS. Теоретически каждое из них изолировано в отдельном домене приложения, но вырваться из него и помешать работе других приложений, работающих в IIS, несложно.

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

Также CAS использовался для браузерных приложений. Задолго до Silverlight можно было запускать приложения Windows Forms в Internet Explorer. Уровень доверия к приложению частично определялся тем, откуда оно было загружено, при этом сайты интрасети предоставляли более высокие привилегии. Но, как и многие ранние технологии .NET, правильно реализовать CAS было сложно. У вредоносных приложений было множество способов обойти ограничения CAS, в то время как безобидные приложения часто сталкивались с трудностями. Браузерные приложения оказывались заблокированы, а уровни доверия CAS для IIS зачастую игнорировались.

Thread.Abort
Может показаться неожиданным, что Thread.Abort никогда не был реализован в .NET Core. Несмотря на то, что это считалось опасным, но оно было и неизбежным. Простой тайм-аут запроса или отключение клиента в ASP.NET приводило к вызову Thread.Abort. И если код не был тщательно написан для обработки этого события, это могло привести к утечкам ресурсов, таким как блокировки или открытые транзакции базы данных.

К моменту создания ASP.NET Core CancellationToken стал безопасной и широко распространенной альтернативой Thread.Abort, поэтому не было необходимости реализовывать его в первой версии .NET Core. И хотя .NET Core расширился за пределы веба, ни одна из других основных платформ приложений не нуждалась в Thread.Abort, поэтому этот вызов генерировал исключение PlatformNotSupportedException. В .NET 5 этот метод помечен как устаревший.

Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-2/

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

1. Разносторонний Рост
Ко второму году работы я уже знал все основы. Я собрал все низко висящие плоды, и мой рост замедлился. Возник большой вопрос: «Как расти дальше?» Я мало что мог сделать, чтобы улучшить свои навыки программирования. Большинство статей и блогов про методы написания более чистого кода, KISS, DRY, YAGNI и т.д. - являются микрооптимизациями. Почти ничего из этого не приносит большой пользы для роста (хотя это не значит, что их не стоит изучать совсем).

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

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

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

2) Тренировка правильных мыслительных привычек
Разработка ПО требует правильного мышления и принятия правильных решений. Написание кода — это реализация этих решений. Мыслительная привычка — это то, что ваш мозг делает регулярно. Это может быть размышление о X всякий раз, когда случается Y, или применение инструмента X к проблеме Y. Короче говоря, мыслительные привычки помогают размышлению. Я предположил, что, если изучить общие принципы, их можно будет применить и в разработке ПО.

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

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

День шестьсот восемьдесят пятый. #Оффтоп
Перенесём разговоры по воскресеньям на разговоры по вторникам))) Судя по всему, на неделе обсуждения получаются активнее. Действительно, что ещё делать в течение дня, работать что ли?

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

В двух словах, в компании есть «On Call»-инженеры (инженеры на вызове), которым могут позвонить в середине ночи в случае, если случается что-то серьёзное. Насколько я понял, эта роль передаётся по очереди всем разработчикам. Давайте обсудим. Есть ли такое в вашей компании? Случалось ли это с вами, что было (если не секрет), и что было за это вам?)))

День шестьсот восемьдесят шестой. #Оффтоп
The API Book
Случайно наткнулся на довольно занятную книгу. Ну как книгу, она пока в стадии написания, но значительная часть её уже готова. "The API Book" за авторством Сергея Константинова. Найти её можно на гитхабе автора как в английском, так и в русском варианте.

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

«Ключевой вопрос, который вы должны задать себе <при проектировании API>, выглядит так: какую проблему мы решаем? Задать его следует четыре раза с ударением на каждом из четырёх слов.»

Подробности в книге по ссылке выше.

День шестьсот восемьдесят седьмой. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Начало 1/3
В третьей части нашего обзора .NET 5 рассмотрим ASP.NET.
- BCL
- Исторические технологии

1. Сериализация
Числа, которые отображаются как строки в кавычках { "Number": "5" }, теперь могут быть десериализованы с помощью стандартного инструмента System.Text.Json.JsonSerializer в числовые свойства, как если бы они были обычными числами в JSON. Раньше это вызвало исключение JsonException.

2. Заменённые пакеты
Были переименованы или заменены различные пакеты:

AzureAD.UI

=> Microsoft.Identity.Web,
API AzureADB2C.UI
=> Microsoft.Identity.Web,

Microsoft.AspNetCore.DataProtection
  .AzureKeyVault

=> Azure.Extensions.AspNetCore
.DataProtection.Keys,

Microsoft.AspNetCore.DataProtection
  .AzureStorage

=> Azure.Extensions.AspNetCore
.DataProtection.Blobs,

Microsoft.Extensions
  .Configuration.AzureKeyVault

=> Azure.Extensions.AspNetCore
.Configuration.Secrets

3. Изменения в Blazor для производительности
- Незначащие пробелы будут удаляться из файлов .razor во время компиляции. Это может привести к устранению сотен пустых узлов, которые потребляют память и пропускную способность сети несмотря на то, что не влияют на отображаемый HTML. Тестирование Microsoft показало улучшение времени рендеринга до 40%.

- В структуре RenderTreeFrame различные публичные поля только для чтения, были заменены публичными свойствами только для чтения. Это изменение нарушает двоичный код, но не нарушает исходный код. То есть код не нужно будет изменять, но нужно будет перекомпилировать для работы с новой версией.

- Авторам библиотек, поддерживающих как .NET Core 3.x, так и .NET 5, потребуется использовать условную ссылку на пакет Microsoft.AspNetCore.Components для учёта обеих версий:

<PackageReference Include="Microsoft.AspNetCore.Components" Version="3.0.0" Condition="'$(TargetFramework)' == 'netstandard2.0'" />

<PackageReference Include="Microsoft.AspNetCore.Components" Version="5.0.0-rc.1.*" Condition="'$(TargetFramework)' != 'netstandard2.0'" />

4. Blazor прекращает поддержку IE и Edge Legacy
Blazor в .NET 5 требует дополнительных функций, которые недоступны в старых браузерах. Internet Explorer не будет поддерживаться вообще. Ранее IE 11 мог получить доступ к веб-сайтам на основе Blazor через polyfills и asm.js. Но, по словам Дэниела Рота, с этим «было много проблем, и опыт использования был не очень хорош», поэтому в Microsoft отказались от asm.js и сосредоточились на WebAssembly.
Никакой конкретной причины относительно Edge Legacy не было указано, но, похоже, это сделано потому, что браузер больше не будет поддерживаться с 9 марта 2021 года. Edge Legacy был официально заменён браузером на основе Chromium.

5. Логи в HttpClient
В .NET Core логи HttpClient записывались с именами кодов ответа HTTP:

Received HTTP response after 56.0044ms - OK
End processing HTTP request after 70.0862ms – OK

Для большей согласованности с другими частями .NET это поведение было изменено на использование числовых кодов:

Received HTTP response after 56.0044ms - 200
End processing HTTP request after 70.0862ms – 200

Целью изменения было устранение несоответствия, из-за которого «затруднялось выполнение запросов через структурированные системы ведения логов, такие как Elasticsearch». Если вам нужно сохранить старое поведение, Microsoft рекомендует взять исходный код классов логирования для версии .NET Core 3.1 и включить их в свой проект. Возможно, это впервые, когда Microsoft используют открытый исходный код для решения проблемы обратной совместимости.

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

Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/

День шестьсот восемьдесят восьмой. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Продолжение 2/3
Продолжаем рассматривать изменения в ASP.NET в .NET5.
- BCL
- Исторические технологии
- ASP.NET. Начало

6. Исключение BadHttpRequestException заменено на BadHttpRequestException
Это странное изменение является результатом наличия в .NET трех классов BadHttpRequestException. Их полные имена:
- Microsoft.AspNetCore.Server
.Kestrel.BadHttpRequestException,
- Microsoft.AspNetCore.Server
.IIS.BadHttpRequestException и
- Microsoft.AspNetCore
.Http.BadHttpRequestException.
Поскольку все они означают одно и то же, это сочли избыточным. Теперь используется только версия Http, другие были отмечены как устаревшие. Для некоторой обратной совместимости они будут унаследованы от версии Http.

7. Повторное согласование сертификата HttpSys отключено
Чтобы повысить производительность, предотвратить взаимоблокировки и поддерживать совместимость с HTTP/2, HttpSys по умолчанию не будет повторно согласовывать сертификаты клиентов. Несмотря на то, что его можно включить, Microsoft не рекомендует этого делать.

8. MVC: ObjectModelValidator вызывает новую перегрузку ValidationVisitor.Validate
Исходная сигнатура этого метода:

public virtual bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel)

Разработчики могут перегружать его для выполнения своей логики проверки. Затем этот метод вызывается объектом ObjectModelValidator.

В .NET 5 введена новая виртуальная перегрузка, и ObjectModelValidator теперь вызывает её:

public virtual bool Validate(ModelMetadata metadata, string key, object model, bool alwaysValidateAtTopLevel, object container)

При этом старая версия оставлена, и просто вызывает новую, передавая null в последний параметр. Если разработчик переопределит исходный метод Validate, то в .NET5 это переопределение будет проигнорировано. Код будет компилироваться, но ObjectModelValidator вместо переопределённого разработчиком метода вызовет новую перегрузку, и переопределённая версия просто не будет работать без каких-либо объяснений. Если вы посчитали, что это редко используемый функционал, то заметьте, что переопределяет этот метод, например, пакет FluentValidation (хотя, его код уже, похоже, исправили)

9. Отменена кодировка имени файла cookie
В стандарте HTTP имена файлов cookie представляют собой ограниченный набор символов ASCII. Для удобства разработчиков многие платформы, включая ASP.NET Core, позволяют включать дополнительные символы и просто кодируют их. Эта возможность была удалена по соображениям безопасности. Если в имени есть не-ASCII символ, может возникнуть исключение. Значения файлов cookie будут по-прежнему кодироваться/декодироваться как обычно.

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

Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/

День шестьсот восемьдесят девятый. #ЧтоНовенького
Критические Изменения в .NET5. ASP.NET. Окончание 3/3
В этом посте завершим обзор важных изменений в ASP.NET, введённых в .NET 5.
Предыдущие посты:
- BCL
- Исторические технологии
- ASP.NET Core. Начало
- ASP.NET Core. Продолжение

10. SignalR: протокол хаба MessagePack теперь использует MessagePackSerializerOptions
Ранее SignalR использовал MessagePack 1 для сериализации сообщений. В .NET 5 он был обновлен для использования MessagePack 2. Поскольку в MessagePack 2 было сделано критическое изменение (переход от IFormatterResolver к MessagePackSerializerOptions), в SignalR потребовалось внести аналогичное изменение в процесс обработки конфигурации. Это изменение повлияет только на тех, кто изменяет MessagePackHubProtocolOptions для SignalR.

11. SignalR теперь требует маршрутизации конечных точек
Маршрутизация конечных точек появилась в ASP.NET Core 3. Подробнее о том, зачем она была введена, я писал в этом посте. SignalR в это же время добавил возможность использовать маршрутизацию конечных точек, но это было необязательно. Старый механизм настраиваемой маршрутизации все ещё был доступен, хотя и отмечен как устаревший. В .NET 5 старый метод был полностью удалён, и теперь необходимо использовать конечную точку. К счастью, изменения в коде минимальны. Вместо:

app.UseSignalR(routes =>
{
  routes.MapHub<SomeHub>("/path");
});

надо использовать

app.UseEndpoints(endpoints =>
{
  endpoints.MapHub<SomeHub>("/path");
});

12. Статические файлы: тип содержимого CSV изменен на соответствующий стандартам
Последнее изменение, которое мы обсудим в этом блоке - это соответствие стандартам для файлов CSV. По странному недосмотру предыдущие версии ASP.NET Core обслуживали статические файлы CSV как application/octet-stream, вместо text/csv. Это может повлиять на то, как браузеры обрабатывают эти файлы, что раньше заставляло разработчиков использовать FileExtensionContentTypeProvider для переопределения этого поведения. Теперь будет использоваться правильный тип содержимого. Если же разработчикам, использующим ASP.NET Core 5, потребуется старое поведение, они могут использовать всё тот же FileExtensionContentTypeProvider, чтобы вернуться к application/octet-stream.

Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes-aspnet/

День шестьсот девяностый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
70. Изучайте Гуманитарные Науки
Практически в любом проекте разработки ПО, кроме самых маленьких, люди работают с другими людьми. Во всех областях исследований, кроме самых абстрактных, люди пишут для людей ПО, которое поможет им в достижении какой-либо цели. Люди пишут программы вместе с людьми для людей. Этот бизнес связан с людьми. К сожалению, в процессе обучения программистов очень мало внимания уделяется аспекту взаимодействия с людьми, с которыми они работают. К счастью, есть целая область исследований, которая может помочь.

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

Лакофф и Джонсон представляют нам сборник «Метафоры, которыми мы живем» (Дж. Лакофф, М. Джонсон - ЛКИ, 2008) предполагая, что язык в значительной степени метафоричен, и что эти метафоры дают представление о том, как мы воспринимаем мир. Даже такие, казалось бы, конкретные термины, как «денежный поток» (cash flow), используемый в разговоре о финансовой системе, можно рассматривать как метафору: «деньги как вода». Как эта метафора влияет на наше восприятие систем, работающих с деньгами? Или же часто используется метафора слоёв в стеке протоколов, где пользовательские слои «вверху», а детали технологии «внизу». Это влияет на то, как мы представляем структуру систем, которые мы строим. Это также может указывать на стремление мыслить шаблонно, от чего время от времени бывает полезно отказываться.

Мартин Хайдеггер внимательно изучил, как люди пользуются инструментами. Программисты создают, меняют, дорабатывают и используют инструменты. Инструменты – постоянный объект интереса программистов. Но для пользователей, как показывает Хайддегер в книге «Бытие и время», инструмент невидим, и понять его можно только при использовании. Для пользователей инструменты становятся объектами изучения только тогда, когда они не работают. Это различие в акцентах стоит иметь в виду всякий раз, когда обсуждается удобство использования.

Элеонора Рош пересмотрела модель категорий Аристотеля, согласно которой мы выстраиваем своё понимание мира. Когда программисты спрашивают пользователей об их желаниях относительно системы, они, как правило, просят дать определения на основе предикатов (некоторых утверждений о субъекте разговора). Например, делать что-то, если случаются события A, B или C. Для программистов это очень удобно. Предикаты могут легко стать атрибутами класса или столбцами в таблице. Эти категории чёткие, непересекающиеся и аккуратные. К сожалению, как показала Рош в работе «Естественные категории» ("Natural categories", Rosch, E. H. - Cognitive Psychology, 1973) и более поздних работах, обычные люди понимают мир иначе. Они постигают его на примерах. Некоторые примеры, так называемые прототипы, лучше других. Поэтому результаты могут получаться нечёткими, перекрываться с другими и иметь сложную внутреннюю структуру. Поскольку мы настаиваем на аристотелевских ответах, мы не можем задать пользователям правильных вопросов, отсюда и сложности в достижении взаимопонимания.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Keith Braithwaite

День шестьсот девяносто первый. #ЧтоНовенького
Нововведения в GitHub

Ручные Подтверждения в GitHub Actions
В GitHub Actions в бета версии появились функции развёртывания. Теперь вы можете:
1. Визуализировать пайплайн
2. Создавать среды, в которых можно устанавливать
- Рецензентов, которые подтверждают развёртывание вручную
- Время ожидания перед запуском развёртывания
- Секреты специфичные для каждой среды

Перейдите в Settings > Environments и создайте новую среду. Задайте имя среды и нажмите Configure environment. Добавьте требуемых рецензентов, установив флажок Required reviewers (вы можете добавить список людей и/или команд). После этого не забудьте нажать Save protection rules (см. картинку 1 ниже).
Теперь можно отредактировать файл YAML. В него нужно добавить блок:

environment:
  name: <имя среды>
  url: <url развёрнутого в среде сайта>

Обратите внимание, что имя среды в YAML файле должно совпадать с именем среды, заданной в параметрах GitHub выше.

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

Обсуждения
До сих пор GitHub предлагал только Issues и Pull Requests в качестве площадки для обсуждений. Проблема в том, что они имеют линейный формат и хорошо подходят для обсуждения изменений в коде, но не для создания базы знаний сообщества. Беседам нужно отдельное место - для этого и созданы GitHub Discussions.

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

Источники:
- https://devblogs.microsoft.com/devops/i-need-manual-approvers-for-github-actions-and-i-got-them-now/
- https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/

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

2. Ищите новые способы мышления и ментальные модели
Новые ментальные модели помогают мыслить вообще, но они также помогают лучше решать конкретные инженерные проблемы. Я придерживаюсь подхода just-in-time («всему своё время»). Я ищу новые подходы к проблеме, только когда зацикливаюсь на чём-то или когда обнаруживаю, что мои абстракции и решения не работают.

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

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

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

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

Вы решаете, что делать, а затем это входит у вас в привычку, и работает автоматически, освобождая мозг для обдумывания более интересных вещей. Я заметил несколько хороших привычек:
- Никогда не покидайте встречу, не приняв решения о дальнейших действиях. Решите, кто это сделает. Задачи без исполнителя редко выполняются.
- Документируйте решения, принятые в ходе разработки проекта.
- Выделите время (пусть это будет час в неделю) на настройку рабочей среды: обновите тормозящую утилиту или найдите ей замену, напишите макрос для рутинных действий, изучите горячие клавиши вашей IDE.
В будущем всё это позволит вам работать эффективнее и получать больше удовольствия от работы, а значит, затраченное время окупится.

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

День шестьсот девяносто третий.
Nuget Пакеты, с Которыми Должен Быть Знаком Каждый .NET разработчик
1. xUnit и NUnit
Пакеты для юнит-тестов. Ничего необычного.

2. Moq и NSubstitute
Также для написания юнит-тестов – пакеты для создания фиктивных объектов в тестах.

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

4. FluentAssertions
Снова вернёмся к юнит-тестам. Этот пакет позволяет создавать утверждения, вызывая цепочку методов, что делает выражение близким к обычному английскому языку, например: actual.Should().Contain("EF").And.HaveLength(6)…

5. BenchmarkDotNet
Один из самых известных пакетов вообще и для теста производительности вашего кода в частности.

6. Serilog
Пакет для ведения журналов. Хотя, здесь можно назвать и ещё несколько похожих. Да и логгер по умолчанию от Майкрософт в последнее время переписан и усовершенствован.

7. Autofixture и Bogus
Эти пакеты позволяют вам сгенерировать тестовые данные для вашей базы данных на стадии разработки, либо для тестов. По умолчанию Autofixture создаст случайные данные, тогда как Bogus больше ориентирован на домен, и создаст данные близкие к реальности.

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

9. Automapper
Очень широко используемый пакет для связи объектов передачи данных (DTO) с объектами бизнес-логики.

10. Dapper и Entity Framework Core
Описание ORM пакетов потянет на целую книгу. Здесь стоит отметить, что эти 2 пакета можно использовать совместно. Например, Dapper для чтения из БД из-за его скорости, а EF Core – для записи, поскольку он хорошо справляется со сложными запросами на модификацию данных.

11. MediatR
Очень широко используемый пакет для реализации паттерна CQRS.

12. FluentValidation
Аналогично FluentAssertions предоставляет интерфейс цепочки методов для валидации объектов.

13. Swagger, Refit и RestSharp
Пакеты, позволяющие вам создавать клиентов для ваших REST API. Первые два больше полагаются на созданные вами объекты модели, последний предоставляет fluent-интерфейс.

14. Json.NET
Пакет от Newtonsoft для сериализации/десериализации в JSON. Майкрософт довольно неплохо усовершенствовали стандартную сериализацию, но Json.NET всё ещё превосходит её во многих аспектах.

Какие полезные NuGet пакеты вы используете? Оставляйте варианты в комментариях.

Источник: https://www.youtube.com/watch?v=qapJwFY9y2Y

День шестьсот девяносто четвёртый.
Microsoft вводит бесплатное продление сертификатов
За последний год в Microsoft Azure добавили более 1000 новых возможностей. Быстрые темпы технологических изменений меняют и картину востребованных навыков в цифровом мире.

В Microsoft Learn создали набор тренингов и сертификатов, призванных помочь техническим специалистам оставаться в курсе событий. В 2021 году вводится несколько обновлений в программы сертификации.

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

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

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

Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/stay-current-with-in-demand-skills-through-free-certification/ba-p/1489678