День 1288. #TypesAndLanguages
6. Запрещать или Разрешать при Разработке ПО
Дискуссии в области разработки ПО довольно часто касаются личных предпочтений. Несмотря на то, что все участники дебатов спорят, основываясь на своих знаниях, навыках или опыте, их дискуссии довольно часто сводятся к вопросу вкуса и цвета.

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

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

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

То же самое относится и к разработке ПО. Допустим, вы нашли ошибку в длинной функции, меняющей состояние приложения. Что вы сделаете? Варианты:
1. Вы решаете, что вы и ваша команда больше не будете так писать. Вы делаете акцент на обзорах кода, чтобы не пропускать такие функции.
2. Вы решаете, что такие функции вообще нельзя разрешать. Вы меняете свой стек на использование чистых функций (например, на F# или Haskell).
3. Вы просто улучшаете свои навыки, чтобы лучше поддерживать длинные функции, меняющие состояние приложения.

Похоже, что индустрия обычно выбирает первый вариант. В сети можно много прочитать о «чистом коде». Такие принципы, как «метод должен иметь не более двух параметров», подкрепляются такими утверждениями, как «Я работаю в отрасли уже 30 лет, поэтому я знаю лучше». Однако в итоге это просто вопрос личных предпочтений. На предпочтение могут влиять когнитивные навыки, окружающая среда, опыт, мастерство, риск, стоимость и, возможно, многие другие причины. Однако нет метрик, показывающих, что «контейнеры DI — это плохо» (как говорят Java-программисты, в то время как .NET-программисты получают поддержку DI «из коробки» в .NET Core), «функции должны иметь длину не более 10 строк» ​​(а затем вы видите, что пул реквесты в коде ядра Linux делают совершенно по-другому), или «чистые функции лучше, чем нечистые» (а затем вы заворачиваете свой код в морской узел, чтобы создать конечный автомат без состояния в нём).

Должны ли мы запрещать или разрешать? Я склоняюсь к последнему. Но опять же, это вопрос предпочтений.

Источник: https://blog.adamfurmanek.pl/2022/07/16/types-and-programming-languages-part-15/

День 1289. #ЗаметкиНаПолях
Хранение Динамических Данных с Помощью EF Core. Начало
Рассмотрим, как можно хранить «динамические» пользовательские данные с помощью Entity Framework Core. Динамические в том смысле, что вы можете не знать, какими будут пары данных ключ/значение, но их по-прежнему важно сохранить. На ум приходят два способа, каждый со своими преимуществами и недостатками. Сегодня рассмотрим первый.

1. Использование сериализации/десериализации JSON
В Entity Framework Core вы можете использовать методы преобразования для сериализации данных при записи в базу данных и десериализации данных при чтении из таблицы.

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

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

Настройка
Во-первых, определим объект для хранения:

public class Entity
{
  public int Id { get; set; }
  public DateTime CreatedAt { get; set; }
   = DateTime.UtcNow;
  public Dictionary<string, string> 
   Values { get; set; } = new();
}

Dictionary<string,string> выбран ради простоты использования с System.Text.Json, в котором нет конвертера для Dictionary<string,object>. Хотя конвертер можно написать, как это сделал Йозеф Оттоссон в своем блоге.

Следующий шаг — настроить преобразование как часть конфигурации EF Core. Здесь используется SQLite, но это должно работать с любой реляционной базой данных, которая может хранить текст в столбце.

public class Database : DbContext
{
  public DbSet<Entity> Entity { get; set; }

  protected override void 
   OnModelCreating(ModelBuilder mb)
  {
    var opts = new JsonSerializerOptions(
     JsonSerializerDefaults.General);

    mb.Entity<Entity>()
      .Property(x => x.Values)
      .HasColumnName("Values")
      .HasColumnType("BLOB")
      .HasConversion(
       v => JsonSerializer.Serialize(v, options),
       s => JsonSerializer
         .Deserialize<Dictionary<string, string>>(s, options),
       ValueComparer.CreateDefault(
         typeof(Dictionary<string, string>), true)
      );
  }
}

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

var json = new Entity
{
  Values = new()
  {
    {"Name", "Dotnet"},
    {"Status", "Awesome"}
  }
};

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

Источник: https://khalidabuhakmeh.com/storing-dynamic-user-data-with-ef-core

День 1290. #ЗаметкиНаПолях
Хранение Динамических Данных с Помощью EF Core. Окончание
Начало

2. Хранение пользовательских данных в инвертированной таблице
Инвертированные таблицы — это когда мы храним пары ключ/значение в отдельных строках. В этом случае ключи и значения становятся столбцами, что обеспечивает гибкость.

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

Недостатки:
- Столбцы значений должны иметь строгий тип, скорее всего строковый тип.
- Эти таблицы могут быстро расти в зависимости от объема пользовательских данных.

Настройка
Настройка инвертированной таблицы не отличается от типичных отношений «один ко многим».

public class Entity
{
  public int Id { get; set; }
  public DateTime CreatedAt { get; set; }
    = DateTime.UtcNow;
  public ICollection<Values> Values { get; set; }
    = new List<Values>();

  public Entity AddValue(string name, string value)
  {
    var existing = Values?.
      FirstOrDefault(v => v.Name.Equals(name));

    if (existing is { })
      existing.Value = value;
    else
      Values?.Add(
       new Values {Name = name, Value = value}
      );

    return this;
  }
}

public class Values
{
  public int Id { get; set; }
  public int EntityId { get; set; }
  public string Name { get; set; }
  public string Value { get; set; }
}

Метод AddValue в типе Entity будет работать с оговоркой, что у вас есть все значения из связанной таблицы Values в памяти. Если нет, вы получите повторяющиеся пары ключ/значение в своей коллекции.

Посмотрим, как сохранить эти пользовательские значения:

var invertedTable = new Entity()
  .AddValue("Name", "Dotnet")
  .AddValue("Status", "Awesome");

Разница с первым методом в том, что подход с инвертированной таблицей требует включения значений при чтении сущностей из базы данных:

var invertedTable = db
  .EntityWithInvertedTables
  .OrderByDescending(o => o.CreatedAt)
  .Include(x => x.Values)
  .First();

Вызов Include загрузит все значения из связанной таблицы. Хотя, вы можете загрузить только нужные значения (но помните, что в этом случае метод сущности AddValue перестанет корректно работать):

…
  .Include(x => x.Values.Where(v => v.Name == "Name"))
  .First();

Источник: https://khalidabuhakmeh.com/storing-dynamic-user-data-with-ef-core

День 1291. #ЧтоНовенького
Миграция из ASP.NET в ASP.NET Core в Visual Studio
Я уже писал про экспериментальное расширение для Visual Studio Microsoft Project Migrations, которое позволяет обновить ваши проекты ASP.NET на ASP.NET Core. Сегодня подробнее про процесс обновления.

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

В Visual Studio после установки расширения щёлкните правой кнопкой на проект и выберите Migrate Project. При этом
- Новый проект ASP.NET Core создаётся и добавляется в решение.
- Проект ASP.NET Core уже настроен с помощью YARP как прокси для передачи запросов исходному проекту ASP.NET.
- Оба проекта будут настроены как стартовые проекты.

Процесс создания нового проекта показан в видео ниже.

Теперь вы можете начать перенос отдельных элементов из проекта ASP.NET в проект ASP.NET Core. В настоящее время расширение поддерживает миграцию: контроллеров, представлений и классов. Для этого щелкните на элементе правой кнопкой и выберите команду Migrate. Расширение проанализирует выбранный элемент, чтобы определить, от каких элементов он зависит, и также попытается перенести их. Попутно могут обнаружиться элементы, которые невозможно перенести автоматически, их необходимо будет перенести вручную. При этом вы можете снять галочки с зависимостей, если хотите пропустить их миграцию. Позже можно повторно запустить миграцию элемента, чтобы перенести дополнительные или ранее пропущенные зависимости. При повторном запуске миграции будут пропущены все элементы, которые уже были перенесены.

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

Известные проблемы
Расширение всё ещё на раннем этапе разработки, и в текущей версии существуют различные известные проблемы и ограничения. Вот что на данный момент не поддерживается:
- Файлы веб-контента (например, CSS/JS и т. д.) не переносятся.
- Классы, использующие Entity Framework.
- Файлы, связанные с .NET Identity.
- Проекты библиотек классов .NET Framework.
- Представления веб-форм ASP.NET.
- Миграция представлений Razor в настоящее время очень ограничена; в настоящее время нет поддержки частичных представлений или файлов layout.
- Области ASP.NET MVC.

Источник: https://devblogs.microsoft.com/dotnet/introducing-project-migrations-visual-studio-extension/

День 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 июня.

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

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

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