День 1292. #юмор
Кстати о E2E тестах.

День 1293. #Оффтоп #МоиИнструменты
Notebook Editor для Visual Studio
Сегодня посоветую вам видео Скотта Хенсельмана https://youtu.be/WfozTizHMlM, в котором он рассказывает про расширение Jupiter Notebooks для Visual Studio.

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

Скотт рассказывает про инструмент на примере обучающих курсов от Microsoft по C# и Machine Learning.

На GitHub есть репозиторий с примерами использования https://github.com/dotnet/csharp-notebooks/

Источник: https://techcommunity.microsoft.com/t5/educator-developer-blog/using-visual-studio-notebooks-for-learning-c/ba-p/3580015

День 1294. #ЗаметкиНаПолях #AsyncTips
Отмена по тайм-ауту
Тайм-аут — всего лишь одна из разновидностей запроса на отмену. Код, который необходимо отменить, просто отслеживает токен отмены, как и при любой другой отмене; ему не нужно знать, что источником отмены является таймер. У источников токенов отмены существуют вспомогательные методы, которые автоматически выдают запрос на отмену по тайм-ауту:

using var cts = new CancellationTokenSource();
cts.CancelAfter(TimeSpan.FromSeconds(5));

Кроме того, тайм-аут можно передать конструктору:

async Task IssueTimeoutAsync()
{
  using var cts = new CancellationTokenSource(
   TimeSpan.FromSeconds(5));
  
  var token = cts.Token;
  await Task.Delay(TimeSpan.FromSeconds(10), token);
}

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

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

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

Отмена параллельного кода
Простейший способ поддержки отмены — передача CancellationToken параллельному коду через ParallelOptions:

void Rotate(
  IEnumerable<Matrix> matrices, 
  float degrees,
  CancellationToken ct)
{
  Parallel.ForEach(matrices,
   new ParallelOptions { CancellationToken = ct },
   m => m.Rotate(degrees));
}

В Parallel LINQ (PLINQ) также предусмотрена встроенная поддержка отмены с оператором WithCancellation:

IEnumerable<int> MultiplyBy2(
 IEnumerable<int> values,
 CancellationToken ct)
{
  return values.AsParallel()
    .WithCancellation(ct)
    .Select(item => item * 2);
}

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

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

День 1295. #ЧтоНовенького #CSharp11
Обзор Новинок C# 11. Начало
C# 11 должен выйти ноябре 2022 года вместе с .NET 7. Рассмотрим новые функции, которые обещают выпустить в новой версии языка.
Эти функции все ещё находятся в стадии превью и, возможно, не все войдут в окончательный выпуск C# 11.

Попробовать новые функции можно в Visual Studio 2022 (версия 17.3.0 или выше). Также необходимо загрузить .NET 7 SDK (версия 7.0.0 preview 6 или выше). Кроме того, в функциях предварительного просмотра IDE нужно включить Use previews of the .NET SDK (Предварительный просмотр .NET SDK).

1. Обязательные члены
Модификатор required можно использовать для свойства, чтобы убедиться, что мы явно устанавливаем значение при инициализации объекта.

public class RequiredMember
{
  public required string Name { get; set; }
}

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

var requiredMember = new RequiredMember { Name = "Dave" };

Также возможно установить обязательный член внутри конструктора объекта. Однако мы должны добавить атрибут. Если мы просто установим требуемое свойство через параметр, это вызовет ошибку компиляции при вызове такого конструктора. Нужно установить атрибут [SetsRequiredMembers] над конструктором. Это сообщает компилятору, что мы устанавливаем необходимые элементы внутри конструктора:

public class RequiredMember
{
  public required string Name { get; set; }
  
  [SetsRequiredMembers]
  public RequiredMember(string name)
  {
    Name = name;
  }    
}

Что интересно, установка атрибута отменяет требование собственно установки значения свойства, и ошибки при этом не возникнет.

2. Структуры со значениями по умолчанию
В C# 10 нам приходилось явно устанавливать значения по умолчанию для каждого из его членов при добавлении в структуру конструктора:

public struct AutoDefaultStruct
{
  public int Number { get; set; }
  public AutoDefaultStruct()
  {
    Number = 0;
  }
}

Если бы мы не установили свойство Number в конструкторе, это вызвало бы ошибку компиляции. В C# 11 если эти элементы не заданы в конструкторе, для них будут установлены значения по умолчанию. В данном случае для Number будет установлено значение 0.

3. Необработанные строковые литералы
Использование строк, содержащих кавычки, или ссылки на фрагменты кода, такие как JSON, стало намного проще. Раньше приходилось экранировать кавычки обратной косой чертой.

Необработанные строковые литералы начинаются и заканчиваются тремя кавычками """...""". Теперь кавычки теперь будут рассматриваться как часть строки.

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

public class RawStringLiteral
{
  public static int MyNumber = 1;
 
  public string MyJsonString =
   $$"""
   {
     "number": "{{MyNumber}}"
   }
   """;            
}

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

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

Источник: https://www.roundthecode.com/dotnet/c-sharp-11-preview-features-dotnet-7

День 1296. #ЧтоНовенького #CSharp11
Обзор Новинок C# 11. Окончание
Начало

4. Обобщённые атрибуты
До C# 11 передача типа в атрибут требовала параметра типа Type и передачи значения через typeof

[MyAttr(typeof(string))] 

Теперь можно делать обобщённые атрибуты:

public class MyAttr<T> : Attribute { } 
…
[MyAttr<string>] 

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

public class MyAttr<T> : Attribute { }

public class MyClass<T>
{
  [MyAttr<T>] // Ошибка компиляции
  public MyClass()
  {
  }
}

5. Шаблоны списков
Шаблоны списков позволяют сопоставлять шаблоны для элементов массива или списка. Здесь у нас есть несколько вариантов.

При явном указании значений массив должен будет строго соответствовать шаблону:

public bool Is_1_3_5(int[] numbers)
{
  return numbers is [1, 3, 5]; 
  // numbers должен быть длиной 3
  // и иметь элементы 1, 3 и 5
}

Символ пустой переменной _ соответствует единичному элементу с любым значением:

numbers is [1, _, 5]; 
// numbers должен быть длиной 3
// и иметь элементы 1, <любое целое число> и 5

Две точки .. будут соответствовать 0 или более элементов:

numbers is [1, .., 5]; 
// numbers может быть любой длины
// должен начинаться с 1 и заканчиваться 5

Также можно указать, что значение может быть больше или меньше определённого:

numbers is [1, .., >=5]; 
// numbers может быть любой длины
// должен начинаться с 1 
// и заканчиваться числом не меньше 5

Как видите, шаблоны дают нам множество вариантов проверки элементов списка или массива.

Источник: https://www.roundthecode.com/dotnet/c-sharp-11-preview-features-dotnet-7

День 1297. #Юмор #CodeReview
Обзор Кода: Как Нажить Себе Врагов
Иногда люди на работе раздражают вас, и вы чувствуете, что нужно отыграться. Если вы разрабатываете ПО, то способ есть – обзор кода! Это фантастический способ отомстить с помощью пассивно-агрессивных действий.

Проверяющий
1. Комментарии о стиле кода
У большинства компаний есть рекомендации по стилю кода. Изучите их! А затем начните просить об изменениях, которые явно не упомянуты. Если в рекомендациях по стилю кода что-то не упоминается, то это отличный шанс попросить внести бессмысленные изменения, которые просто заставят вашу жертву поработать:
- Правильно ли названы методы в классе модульного теста?
- Не слишком ли многословно названа переменная?
- Не используется синтаксис Йоды? Попросите изменить условия на противоположные.

2. Попросите об изменениях, которые не имеют смысла
Шаг 1 раздражает, но сам по себе он не смертелен. Нужно продолжать давление. Далее идут бессмысленные запросы изменений.
Если есть два способа сделать что-то, потребуйте, чтобы код был изменён, чтобы сделать по-вашему. Не слушайте доказательств о недостатках вашего варианта. Включитесь в длинный спор почему это следует изменить.
Если не хватает аргументов заставьте соперника сомневаться в своих знаниях с помощью фраз вроде: «Я не знаю, почему вы так в штыки воспринимаете эту просьбу. Так, как я сказал, будет работать. Пожалуйста измените. Спасибо.»
Заставьте соперника потратить время на переписывание кода, который отлично работает.

3. Долгие задержки
Не торопитесь отвечать. Выждите как минимум 24 часа перед проверкой кода. Говорите, что заняты другими делами. Цель здесь состоит в том, чтобы сделать пулл-реквест (PR) устаревшим. Открытые PR считаются техническим долгом, потому что они требуют работы для поддержания. Это утомительная работа. Таким образом, вам нужно заставить PR провисеть как можно дольше, чтобы человеку приходилось тратить время на исправление конфликтов слияния.
Хороший способ сделать это — отказаться работать с PR, в котором есть конфликты слияния, потому что код может выглядеть по-другому после исправления, и вы не хотите тратить время на его просмотр, чтобы затем снова просматривать его после разрешения конфликтов. Это отличная тактика. Если сопернику не пришлось исправлять конфликты слияния хотя бы 2-3 раза, вы слишком быстро ему отвечаете!

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

Проверяемый
1. Измените стиль кода в PR
Каждый PR, который вы отправляете на рассмотрение своему врагу, должен включать хотя бы 50% ненужных изменений стиля кода. Это сделает поиск фактических функциональных изменений настолько трудным, что он просто не глядя примет все ваши изменения.

2. Создавайте огромные PR
Ваша задача - заставить людей бояться обозревать ваш код. Это значит, что все PR должны содержать от 1000 изменений в как минимум 10 файлах.
Требуйте быстрого ответа. Это технический долг, и вы не хотите самостоятельно устранять конфликты слияния. Так что изводите всех, пока ваш PR не будет принят.

3. Игнорируйте комментарии
Отличный способ избежать негативных отзывов во время проверки кода — просто игнорировать их. Получили негативный комментарий? Попросите приятеля одобрить PR и слить его, не разбираясь с этим комментарием.

Итого
Если эти шаги повторять неоднократно и последовательно в течение нескольких месяцев, ваш враг пожалеет о том, что связался с вами!

Источник: https://repohealth.io/blog/code-review-how-to-make-enemies/

День 1298. #Подкаст #Карьера
Сегодня предлагаю послушать эпизод подкаста Скотта Хансельмана Hanselminutes: Mark Thompson wants you to win.

Марк Томпсон, старший инженер по связям с разработчиками в Google, хочет, чтобы вы выиграли. Они со Скоттом поговорили том, почему «дефицит мест» это неправильный способ думать о карьере в сфере технологий. Ваш успех не означает неудачи кого-то другого, и наоборот. Аналогично, передача знаний вашим ученикам или младшим коллегам (помимо того, что приносит удовлетворение) не означает, что они однажды займут ваше место. Места хватит всем.

Также Марк и Скотт обсудили вариацию синдрома самозванца при взгляде на более успешных коллег. Некоторые люди генетически предрасположены добиваться успеха в определённых сферах. Но то, что существует Леброн Джеймс вовсе не означает, что остальным 600 игрокам нечего делать в НБА. Выиграть могут все. Точно проиграет лишь тот, кто не будет участвовать.

Эти и другие советы относительно карьеры в новой серии подкаста.

Источник

День 1300. #ЧтоНовенького
Транзитивные Зависимости в Visual Studio
Чтобы помочь отслеживать транзитивные зависимости и быстро устранять уязвимости в Visual Studio 17.3 добавлена экспериментальная функция, которая поможет вам просматривать и принимать меры в отношении транзитивных зависимостей.

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

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

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

Подробнее о том, как важно отслеживать зависимости в вашем проекте см. Рекомендации по Обеспечению Безопасности Проектов на GitHub

Источник: https://devblogs.microsoft.com/nuget/introducing-transitive-dependencies-in-visual-studio/

День 1301. #ЗаметкиНаПолях #AsyncTips
Внедрение Запросов на Отмену

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

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

Следующий пример выполняет асинхронный запрос HTTP. Токен, переданный методу GetWithTimeoutAsync, представляет отмену, запрошенную конечным пользователем, а метод GetWithTimeoutAsync также применяет тайм-аут к запросу:

async Task<HttpResponseMessage> 
 GetWithTimeoutAsync(
  HttpClient client,
  string url, 
  CancellationToken ct)
{
  using var cts = CancellationTokenSource
   .CreateLinkedTokenSource(ct);
  cts.CancelAfter(TimeSpan.FromSeconds(2));

  var combined = cts.Token;
  return await client.GetAsync(url, combined);
}

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

Хотя в предыдущем примере используется только один источник CancellationToken, метод CreateLinkedTokenSource может получать любое количество токенов отмены в своих параметрах. Это позволяет создавать один объединённый токен, на базе которого можно реализовать собственную логическую отмену. Например, ASP.NET предоставляет токен отмены, представляющий отключение пользователя (HttpContext.RequestAborted); код обработчика может создать связанный токен, который реагирует либо на отключение пользователя, либо на свои причины отмены (например, тайм-аут).

Помните о сроке существования источника связанного токена отмены. Предыдущий пример является наиболее типичным: один или несколько токенов отмены передаются методу, который связывает их и передает как комбинированный токен. Также обратите внимание на то, что в примере используется команда using, которая гарантирует, что источник связанного токена отмены будет освобожден, когда операция будет завершена (а комбинированный токен перестанет использоваться). Подумайте, что произойдет, если код не освободит источник связанного токена отмены: может оказаться, что метод GetWithTimeoutAsync будет вызван несколько раз с одним (долгосрочным) существующим токеном; в этом случае код будет связывать новый источник токена при каждом вызове метода. Даже после того, как запросы HTTP завершатся (и ничто не будет использовать комбинированный токен), этот связанный источник всё ещё останется присоединённым к существующему токену. Чтобы предотвратить подобные утечки памяти, освобождайте источник связанного токена отмены, когда комбинированный токен перестаёт быть нужным.

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

День 1302. #ЗаметкиНаПолях
Выполнение Скриптов на C# и .NET Core
Вы, вероятно, знаете, что в .NET Core очень легко создать новое приложение «Hello World» и начать писать код. Просто установите .NET Core, затем выполните dotnet new console, что сгенерирует файл проекта и базовое приложение, затем dotnet run скомпилирует и запустит его. Команда new создаст весь вспомогательный код, папки obj, bin и т. д. Когда вы выполняете dotnet run, на самом деле это комбинация команд dotnet build и dotnet exec myapp.dll.

Что может быть проще? А что насчёт сценариев в .NET Core?

На помощь придёт инструмент сценариев dotnet-script.
Для начала установим инструмент:

>dotnet tool install -g dotnet-script

Создадим файл скрипта helloworld.csx со следующим содержимым:

Console.WriteLine("Hello world!");

Теперь его можно выполнить:

>dotnet script helloworld.csx
Hello world!

Замечание: Если вы будете это делать в Linux или OSX, вам нужно будет указать в первой строке стандартный заголовок, говорящий о том, какая программа может исполнять этот скрипт:

#!/usr/bin/env dotnet-script

Заголовок аналогичен файлам bash, python и т.п.

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

using System.Collections.Generic;
using System.Linq;

foreach (var i in Fibonacci().Take(20))
{
  Console.WriteLine(i);
}

private IEnumerable<int> Fibonacci()
{
  int current = 1, next = 1;

  while (true) 
  {
    yield return current;
    next = current + (current = next);
  }
}

Если нужно, вы можете обратиться к NuGet пакету внутри скрипта, используя синтаксис #r от Roslyn:

#r "nuget: AutoMapper, 6.1.0"
Console.WriteLine("Hello AutoMapper!");

Но и это ещё не всё. Имея dotnet-script, установленный как глобальная утилита, как мы сделали выше, вы можете использовать его как REPL (интерактивную среду) прямо в консоли!

>dotnet script
> 2+2
4
> var x = "dotnet script";
> x.ToUpper()
"DOTNET SCRIPT"

Источник: https://www.hanselman.com/blog/c-and-net-core-scripting-with-the-dotnetscript-global-tool

День 1303. #ЧтоНовенького
Построчный Git Stage в Visual Studio 17.3
Я уже писал про эту функцию в обзоре новых функций превью версии 17.2. Напомню, построчный или интерактивный Git Stage, позволяет разделить изменённые строки в одном файле в разные коммиты. Его также можно использовать для проверки ваших изменений перед их фиксацией. Отметьте изменённые строки или разделы кода как проверенные, поместив их в Stage, и зафиксируйте эти изменения, когда закончите проверку.
Теперь этот функционал выпущен в VS версии 17.3, а Microsoft выпустили видео с пошаговой инструкцией по использованию. По-моему, очень удобно.

Источник: https://devblogs.microsoft.com/visualstudio/git-line-staging-released/

День 1304. #Карьера
Как Разработчику ПО Развить Навыки Решения Проблем
Общеизвестно, что решение проблем является важным навыком для инженеров-программистов. Хорошие навыки решения проблем включают в себя способность мыслить творчески и аналитически, разбивая проблемы на более мелкие части и используя системный подход для поиска решений. Сильные навыки решения проблем необходимы для успешной карьеры в разработке ПО.

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

Разделяй и властвуй
Другой подход заключается в использовании более системного метода.
Метод «Разделяй и властвуй» подходит для решения сложных проблем путём их разбиения на более мелкие, управляемые части. Это позволяет более эффективно и действенно решать проблемы. Как только эти подзадачи решены, их можно объединить для решения более крупной и сложной проблемы.
Среди распространённых примеров «разделяй и властвуй»: рекурсия или алгоритм сортировки слиянием, который разбивает массив на более мелкие части, сортирует каждую часть, а затем объединяет их.

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

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

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

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

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

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

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

Источник: https://dev.to/nathan20/how-to-develop-strong-problem-solving-skills-as-a-software-developer-25nb

День 1305. #Оффтоп #Юмор
Сегодня порекомендую вам крайне познавательный и, в то же время, уморительный доклад Марка Рендла “Programming’s Greatest Mistakes” (Величайшие ошибки в программировании) https://youtu.be/qC_ioJQpv4E с конференции NDC Copenhagen 2022, прошедшей с 30 мая по 2 июня.

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

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

Кстати, если вы допустили серьёзную ошибку, и не знаете, как теперь быть, прочитайте этот пост.

День 1306. #TypesAndLanguages
7. Инкапсуляция или Публичное Всё
Сейчас немного разожгу:
Всё должно быть публичным. Не используйте модификатор private вообще.

А теперь давайте обсудим это немного подробнее.

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

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

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

class Foo {
  public void Bar() { … }
  private void BarInternals() { … }
}

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

interface IFoo {
  void Bar();
}
class Foo : IFoo {
  public void Bar() { … }
  public void BarInternals() { … }
}

Теперь любой «порядочный» клиент, вызывающий объект, должен использовать Foo через интерфейс IFoo, поэтому метод BarInternals останется недоступным. Дело не в том, что он приватный или доступ заблокирован контроллером политик. Метода просто нет! Однако, если кому-то нужно схитрить, он может привести IFoo к Foo и получить поддержку компилятора, чтобы убедиться, что BarInternals существует.

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

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

Что скажете?

Источник: https://blog.adamfurmanek.pl/2022/07/23/types-and-programming-languages-part-16/
Автор оригинала: Adam Furmanek

День 1307. #Книги
Прочитал книгу «Принципы юнит-тестирования» (Владимир Хориков — СПб.: Питер, 2022).

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

В книге довольно подробно описана теория: что такое тесты, какие они бывают, из чего состоят, зачем их делать и какие правила стоит соблюдать, а чего лучше не делать (например, что не стоит гнаться за метриками покрытия кода). Вообще, на канале отрывков из книги приводилось уже довольно много. Их можно найти по тегу #Testing. А вот здесь есть даже шпаргалка по юнит-тестам, по мотивам книги.

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

В чём я лично вижу проблему с переупрощёнными примерами. Требуется опыт, чтобы придумать, где это будет применено в реальности. А это нужно, чтобы кусочек пазла встал на своё место. У меня с этим проблем не возникло, потому что я в последнее время всерьёз занялся внедрением тестов на своей основной работе (собственно, поэтому и книгу приобрёл). Я уже столкнулся с большинством описанных препятствий, поэтому у меня они «легли в контекст», и я довольно часто ловил себя на мысли «а, так вот как это надо было делать». Или же я легко представлял, где я смогу это использовать.

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

День 1308. #ЗаметкиНаПолях
Принудительный HTTPS в Приложениях ASP.NET Core. Начало
Как заставить ваше приложение ASP.NET Core использовать только HTTPS? Изучаем лучшие практики для различных сценариев.

1. Использовать перенаправление HTTPS
Если клиент вызывает приложение, используя HTTP, приложение перенаправляет его на тот же URL-адрес, начинающийся с HTTPS. Перенаправление URL — хорошо известный подход. Веб-приложение создает ответ HTTP с кодом состояния, начинающимся с 3, и заголовком Location, как в следующем примере:

HTTP/1.1 301 Moved Permanently
Location: https://...

Этот подход не устраняет все риски безопасности, но является хорошей отправной точкой. К счастью, в ASP.NET Core есть несколько других вариантов.

2. Атрибут RequireHttps
Его можно использовать в приложениях, чтобы заставить страницу требовать HTTPS. В Razor Pages RequireHttps можно применять только к классам, страниц, либо к методам класса:

[RequireHttps]
public class PrivacyModel : PageModel 
{ … }

В ASP.NET Core MVC можно применить атрибут RequireHttps к классам, контроллеров или к их методам действия:

[RequireHttps]
public class HomeController : Controller
{ … }

Есть соблазн применять атрибут выборочно к определённым страницам или представлениям, таким образом ограничить HTTPS только страницами с конфиденциальным содержимым. Но смешивание страниц HTTP и HTTPS — очень плохая идея! Ваше приложение так подвергается атакам с понижением протокола. Это разновидность атак man-in-the-middle, когда HTTP запрос перехватывается атакующим, и таким образом компрометируется вся безопасность последующей коммуникации между клиентом и сервером.
Можно применить RequireHttps ко всем страницам, но есть и более простые способы.

3. Промежуточное ПО перенаправления на HTTPS
При создании веб-приложения с использованием одного из стандартных шаблонов проектов ASP.NET файл Program.cs (Startup.cs) содержит вызов метода UseHttpsRedirection() в конвейере промежуточного ПО:

…
app.UseHttpsRedirection();
app.UseStaticFiles();

app.UseRouting();
…

Вызов метода UseHttpsRedirection() означает, что каждый запрос к вашему приложению будет проверен и, возможно, перенаправлен промежуточным ПО. Все страницы вашего приложения будут требовать HTTPS.

4. Промежуточное ПО HSTS
К сожалению, принудительного переключения клиента с HTTP на HTTPS при каждом запросе может быть недостаточно для предотвращения атак с понижением протокола. Злоумышленник может перехватить HTTP-запрос клиента до того, как он переключится на соответствующий HTTPS-запрос.
Нужен способ указать браузеру обязательно использовать HTTPS для запроса любого ресурса веб-приложения. Это заголовок HTTP Strict-Transport-Security (HSTS). Имея заголовок HSTS, браузер будет вызывать ваше приложение с использованием HTTP только в самый первый раз. Последующие запросы к тому же домену будут выполняться через HTTPS, даже если в адресе будет HTTP. Включить HSTS можно с помощью метода UseHsts(). Этот вызов также уже включён в шаблоны веб-приложений ASP.NET Core:

if (!app.Environment.IsDevelopment())
{
  app.UseExceptionHandler("/Error");
  app.UseHsts();
}

По умолчанию поддержка HSTS отключена в вашей среде разработки. Скорее всего, вы используете localhost в качестве домена. Если вы используете HSTS, любой запрос, сделанный вашим браузером к локальному хосту, будет использовать HTTPS. Это является хорошей практикой. Но при этом браузер будет делать HTTPS-запросы к любому приложению, размещённому на локальном хосте. Это может вызвать проблемы, например с Angular приложениями.

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

Источник: https://auth0.com/blog/force-https-in-aspnet-core-apps/

День 1309. #ЗаметкиНаПолях
Принудительный HTTPS в Приложениях ASP.NET Core. Окончание
Начало

Перенаправление HTTPS и API
Подход с перенаправлением HTTPS основан на отправке обратно клиенту кода состояния 301 или другого 30* HTTP, независимо от того, используете ли вы атрибут RequireHttps или ПО промежуточного слоя для перенаправления HTTPS. Подход HSTS основан на отправке заголовка Strict-Transport-Security.

Оба подхода хорошо понимаются стандартными браузерами. Таким образом, на эти подходы могут полагаться типы приложений, клиентами которых являются браузеры, например приложения ASP.NET Core MVC, Razor Pages и Blazor Server.

Однако эти подходы обычно игнорируются небраузерными клиентами, такими как клиенты API. Мобильное приложение или SPA крайне редко заботятся о кодах состояния 301 или заголовках HSTS. В этом случае есть два альтернативных способа работы с клиентами, которые делают HTTP-запросы:

1. Игнорировать HTTP-запросы
Один из самых простых способов — использовать флаг --urls команды запуска dotnet, как показано ниже:

dotnet run --urls "https://localhost:7123"

Это переопределит настройки URL в файле Properties/launchSettings.json проекта ASP.NET Core.

В производственной среде можно задать переменную окружения ASPNETCORE_URLS.
PowerShell:

$Env: ASPNETCORE_URLS = "https://localhost:7123"

Bash:

export ASPNETCORE_URLS=https://localhost:7123

2. Выдавать на HTTP-запросы код ответа Bad Request
Для этого потребуется собственное промежуточное ПО вместо UseHttpsRedirection() и UseHsts():

//app.UseHttpsRedirection();
app.Use(async (context, next) => {
  if (!context.Request.IsHttps) {
    context.Response.StatusCode =
     StatusCodes.Status400BadRequest;
    
    await context
     .Response
     .WriteAsync("HTTPS required!");
  } 
  else {
    await next(context);
  }
});

Код выше просто проверяет, использует ли текущий запрос HTTPS. Если это не так, он отвечает кодом состояния 400 Bad Request и сообщением, предупреждающим, что требуется HTTPS.

Перенаправление HTTPS и обратные прокси
Все вышеизложенное имеет смысл, если ваше приложение ASP.NET Core напрямую подключено к Интернету. Если ваше приложение развернуто в среде с обратным прокси-сервером, который обеспечивает безопасность подключения, нет необходимости использовать перенаправление HTTPS или промежуточное ПО HSTS. В этом случае вы можете просто удалить вызовы методов UseHttpsRedirection() и UseHsts() из веб-приложений или собственное промежуточное ПО из примера выше для веб-API. Вы делегируете переключение с HTTP на HTTPS и управление ответами обратному прокси-серверу.

Источник: https://auth0.com/blog/force-https-in-aspnet-core-apps/