День 1152. #ЧтоНовенького
Автосохранение Кода в VS 2022
IDE — это инструмент, который объединяет множество систем, необходимых разработчику для создания приложения. Однако, это всё равно не единственный инструмент в наборе разработчика.

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

Начиная с 17.2 Preview 1 в этом поможет новая функция автосохранения. Она находится в меню Tools > Options > Environment > Documents (Инструменты > Параметры > Cреда > Документы).

Если установлен флажок Automatically save files when Visual Studio is in the background (Автоматически сохранять файлы, когда Visual Studio находится в фоновом режиме), то каждый раз, когда VS теряет фокус (обычно при переключении на другое приложение), VS будет пытаться сохранить все несохранённые документы в IDE: файлы проекта, файлы решения и даже прочие файлы, которые не являются частью проекта или решения. Если по какой-либо причине сохранить файл не удастся (например, файл доступен только для чтения), VS сохранит ваши изменения в редакторе и просто оставит файл «грязным».

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

Стоит отметить, что люди, которые используют функцию Code Cleanup on Save (Очистка кода при сохранении), обнаружат, что автосохранение не запускает очистку кода. Разработчики утилиты решили, что это будет слишком затратно, если будет происходить слишком часто. Очистка кода при сохранении срабатывает только в том случае, если вы явно сохраняете файл через Ctrl+S, либо неявно в процессе сборки проекта.

Источник: https://devblogs.microsoft.com/visualstudio/suffer-from-ctrls-fatigue-we-have-a-feature-for-you/

День 1153.
30 и 31 марта 2022 пройдёт онлайн конференция .NET Beyond.
На ней вы посмотрите, как некоторые из самых умных людей в сообществе .NET используют его для разработки для предприятия — и в масштабе.
Независимо от того, в какой области .NET вы работаете, вы гарантированно научитесь чему-то, чего ещё не знаете.

Вот программа конференции (время московское):
30 марта
18:00 The History of .NET (Richard Campbell)
19:00 Scalability and Security with K8s and Azure Active Directory (Christos Matskas)
20:00 Getting to DDD: Pragmatic or Principled? (Julie Lerman)
21:00 Why F# Works in the Enterprise (Phillip Carter)
22:00 Introducing MongoDB and .NET: SQL is Not the Only Way (Luce Carter)
23:00 Kubernetes Made Easy with VMware Tanzu Application Platform (John Bush)
00:00 Mobile DevOps at Scale (Rodney Littles II)

31 марта
12:00 REST, GraphQL, and gRPC: A Comparison (Poornima Nayar)
13:00 Messaging for .NET Developers (Ian Cooper)
14:00 The Hand That Feeds: How to Misuse Kubernetes (Lewis Denham-Parry)
15:00 From Monolith to Service Orientated and Beyond (Stacy Cashmore)
16:00 ASP.NET Basics for Experts (Jakub Pilimon, Layla Porter)
17:00 Observability for .NET Applications (Hananiel Sarella)
18:00 Simplifying Microservice Security with YARP (Andrew Stakhov)
19:00 Your Enterprise Open Source Journey (Jeff Fritz)

Трансляция на YouTube

Источник: https://tanzu.vmware.com/developer/tv/dotnet-beyond

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

Чтобы повысить осведомленность об этой проблеме и предоставить некоторые рекомендации по аспектам, на которых следует сосредоточиться, представляю вам «Пирамиду Обзора Кода». Она призвана помочь сосредоточить внимание на тех частях обзора, которые наиболее важны, а также отметить, какие части могут и должны быть автоматизированы.

Основной принцип: Нижние части пирамиды должны лежать в основе код-ревью и занимать его большую часть.

Источник: https://www.morling.dev/blog/the-code-review-pyramid/

День 1155. #ЗаметкиНаПолях
Тип .NET для Персональных Данных. Начало
Персональные данные (Personally identifiable information - PII) — это любая информация, относящаяся к идентифицированному или идентифицируемому физическому лицу (т.е. позволяющая идентифицировать лицо прямо или косвенно, в частности, через имя, идентификационный номер, email, дату рождения, данные о местоположении и т.п.).

Проблема
Согласно законодательству многих стран, вы должны обращаться с PII особым образом. Например:
1. Шифровать или анонимизировать везде, где это возможно.
Для этого данные PII должны отображаться по-разному в зависимости от варианта использования. Например:
- обычный текст в UI;
- псевдоним в логах;
- зашифрованы в файле экспорта CSV.

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

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

На первый взгляд очевидно использование string для PII:

public class User
{
  public Guid Id { get; set; }
  public string Name { get; set; }
  public string Email { get; set; }
  public string Location { get; set; }
}

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

Решение
Ввести явный тип, например, PiiString. Он должен быть как можно более взаимозаменяемым со string, чтобы упростить рефакторинг существующего кода, использующего string. В приложении он должен вести себя как обычная строка, однако вне приложения, он должен быть закодирован/зашифрован/хеширован.
Заметьте, что ниже приведена упрощённая версия класса. Полная тут:

public class PiiString
{
  private readonly string _string;

  public PiiString(string str)
    => _string = str ??
      throw new ArgumentNullException(nameof(str));

  public override string ToString()
    => _string;
}

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

Источник: https://gaevoy.com/2022/03/18/personally-identifiable-information-data-types.html

День 1156. #ЗаметкиНаПолях
Тип .NET для Персональных Данных. Окончание
Начало

Проверим PiiString на соответствие требованиям.

1. Шифрование или анонимизация PII
Значение PiiString может быть преобразовано в зависимости от используемой логики кодирования.

public interface IPiiEncoder
{
  string ToSystemString(PiiString pii);
  PiiString ToPiiString(string str);
}

PiiString как обычный текст:

public class PiiAsPlainText : IPiiEncoder
{
  public string ToSystemString(PiiString pii)
    => pii.ToString();

  public PiiString ToPiiString(string str)
    => new PiiString(str);
}

Анонимизированная PiiString через хэш SHA256:

public class PiiAsSha256 : IPiiEncoder
{
  public string ToSystemString(PiiString pii)
  {
    var data = Encoding.UTF8.GetBytes(pii.ToString());
    using var sha = SHA256.Create();
    var hash = sha.ComputeHash(data);
    return Convert.ToBase64String(hash);
  }

  public PiiString ToPiiString(string str)
    => throw new NotSupportedException();
}

PiiString в Entity Framework Core

public class PiiConverter 
 : ValueConverter<PiiString, string>
{
  public PiiConverter(IPiiEncoder encoder) 
   : base(
    v => encoder.ToSystemString(v),
    v => encoder.ToPiiString(v))
  {}
}

2. Соглашение об обработке данных с третьими лицами
Обычно это сводится к тому, чтобы найти все места в исходном коде, где используется PII, а затем обработать эту информацию для юристов. В Visual Studio есть команда Find All References (Найти все ссылки), которая должна упростить задачу.

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

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

Полный код классов с примерами шифрования Aes128, использования в System.Text.Json, Newtonsoft.Json, Nlog, Serilog и EFCore здесь.

Источник: https://gaevoy.com/2022/03/18/personally-identifiable-information-data-types.html

День 1157. #юмор
Сегодня порекомендую просто уморительное видео. Это доклад «The Worst Programming Language Ever» от Марка Рендла с конференции NDC Oslo 2021.

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

Поэтому особенно доклад оценят те, кому приходилось работать на разных языках, и кто прочувствовал всю боль работы с ними. От нестрогой типизации и неочевидной логики в JavaScript до обязательного обозначения переменных с $ и обращения к свойствам через => в PHP, от обратной логики исключений в Ruby до табов и пробелов в Python, ну и куда же без макросов и ручного управления памятью в С/С++.

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

День 1158. #ЧтоНовенького
GitHub Copilot Доступен в Visual Studio 2022
С тех пор, как в прошлом году была запущена предварительная версия GitHub Copilot, команда изучала полученные отзывы, а также расширяла охват как людей, имеющих доступ к ней, так и мест, где вы можете её использовать. Теперь она добавлена и в Visual Studio 2022.

Установка
Прежде всего, вам необходимо зарегистрироваться в списке ожидания, чтобы получить доступ к технической предварительной версии GitHub Copilot. Когда вы получите письмо от GitHub, подтверждающее, что у вас есть доступ, в Visual Studio 2022 перейдите в раздел Extensions > Manage Extensions (Расширения > Управление расширениями), найдите GitHub Copilot и установите его.

После установки снова откройте VS. Вам будет предложено авторизовать VS в сервисе GitHub Copilot. В открывшемся браузере вставьте код авторизации. Как только вы увидите сообщение, подтверждающее подключение, вы можете закрыть окно браузера и вернуться в Visual Studio. Теперь вы должны принять условия отправки телеметрии в GitHub Copilot.

Использование
По мере ввода кода GitHub Copilot автоматически предложит код, который, по его мнению, вам может понадобиться. Вы можете нажать клавишу Tab, чтобы принять его, или просто продолжать печатать, чтобы игнорировать, тогда Copilot предложит другие варианты, основываясь на том, что, по его мнению, вы делаете. Нажмите Esc, чтобы полностью удалить предложение, если оно вам мешает.

Хотя Copilot всегда будет показывать наилучшие рекомендации, вы можете использовать Ctrl+Alt+] и Ctrl+Alt+[ для навигации по вариантам, которые он сгенерирует.

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

Команда GitHub Copilot ждёт ваших отзывов тут.

Источник: https://github.blog/2022-03-29-github-copilot-now-available-for-visual-studio-2022/

UPD: Меня одобрили в программе предварительной оценки буквально вчера вечером. Сегодня с утра немножко поковырял фичу. Почему-то добиться эффекта полного решения по комментарию (как на картинке) не удалось, но вот более простые вещи выдаёт довольно быстро и точно.

День 1159. #Карьера
Как Превратить Синдром Самозванца в Преимущество
Прошли оценки эффективности, пришло время встретиться с менеджером. Я знал, что он скажет. Как ещё оценить программиста, который не пишет код?

Мой разум постоянно возвращался к последней ошибке, которую я должен был исправить. Я потратил целый день, в конце концов сдался и попросил помощи у коллеги. Он нашел её за 10 минут. Я явно не дотягивал.

Мой босс, похоже, заметил это и наверняка поэтому поручил мне помогать аудиторам анализировать наш код. Помогать? Я сам еле его понимал! Но это был сторонний проект. Если что-то не требует написания кода, зачем тратить время настоящих программистов? Я едва справлялся, постоянно спрашивал что-то у менеджера и как мог пытался объяснять это аудиторам. Короче, я был обречён.

«Поздравляю, вы получили повышение. Продолжайте в том же духе!»

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

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

Но всё же… это моя команда. Будут ли другие компании думать так же? Только один способ узнать: я стал ходить на собеседования. Я не мог поверить, когда получил несколько предложений о работе, в том числе от Google!

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

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

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

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

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

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

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

Источник: https://www.zainrizvi.io/blog/the-impostors-advantage/
Автор оригинала: Zain Rizvi

День 1160. #ЗаметкиНаПолях
Автоматическое Обновление Времени Создания/Обновления/Удаления в Entity Framework.
В любой схеме базы данных очень часто встречаются поля Created, Updated и Deleted для сущностей. Они полезны для отладки, а поле Deleted позволяет реализовать «мягкое удаление». Есть довольно простой метод, заключающийся в переопределении поведения сохранения Entity Framework.

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

public abstract class Auditable
{
  public DateTimeOffset Created { get; set; }
  public DateTimeOffset? Updated { get; set; }
  public DateTimeOffset? Deleted { get; set; }
}

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

Далее, мы наследуем сущности от этого класса:

public class Customer : Auditable
{
  public int Id { get; set; }
  public string Name { get; set; }
}

Теперь нужно, чтоб EF обновляла эти значения при сохранении. Есть несколько способов это сделать, но самый простой — переопределить метод сохранения SaveChangesAsync в классе контекста:

public override Task<int> 
 SaveChangesAsync(CancellationToken ct = default)
{
  foreach (var e in 
   ChangeTracker.Entries<Auditable>())
  {
    switch (e.State)
    {
      case EntityState.Added:
        e.Entity.Created = DateTimeOffset.UtcNow;
        break;
      case EntityState.Modified:
        e.Entity.Updated = DateTimeOffset.UtcNow;
        break;
      case EntityState.Deleted:
        e.Entity.Deleted = DateTimeOffset.UtcNow;
        e.State = EntityState.Modified;
        break;
    }
  }

  return base.SaveChangesAsync(ct);    
}

Процесс использует обобщённый метод ChangeTracker.Entries<T>(), который получает все добавляемые сущности типа Auditable (и унаследованные от них), и в зависимости от состояния устанавливает дату создания, обновления или удаления. Также заметьте, что для удаляемых сущностей состояние изменяется на Modified. Наконец, вызывается базовый метод SaveChanges, который фактически выполняет сохранение.

Примечание: Начиная с EF Core 5.0, вместо переопределения SaveChanges можно использовать класс SaveChangesInterceptor.

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

Источник: https://dotnetcoretutorials.com/2022/03/16/auto-updating-created-updated-and-deleted-timestamps-in-entity-framework/

День 1161. #ЗаметкиНаПолях
Мягкое удаление в Entity Framework
При использовании мягкого удаления возникает проблема, что во всех запросах приходится отфильтровывать удалённые объекты:

dbSet.Where(x => x.Deleted == null);

И об этом нужно постоянно помнить.

Есть отличный способ решить эту проблему с помощью так называемых «глобальных фильтров запросов». В документации даже есть пример: https://docs.microsoft.com/en-us/ef/core/querying/filters.

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

protected override void
 OnModelCreating(ModelBuilder builder)
{
  // остальные настройки

  var entities = builder.Model
    .GetEntityTypes()
    .Where(e => e.ClrType.BaseType == typeof(Auditable))
    .Select(e => e.ClrType);

  Expression<Func<Auditable, bool>> 
    expression = del => del.Deleted == null;

  foreach (var e in entities)
  {
    var p = Expression.Parameter(e);
    var body = 
     ReplacingExpressionVisitor
      .Replace(expression.Parameters.Single(), 
        p, expression.Body);

    builder.Entity(entity)
      .HasQueryFilter(
        Expression.Lambda(body, p));
    }

    base.OnModelCreating(builder);
  }
}

Сначала мы выбираем все сущности, которые наследуют от Auditable (см. предыдущий пост). Затем создаём выражение expression для фильтрации. Далее перебираем все выбранные сущности и создаём для каждого типа своё выражение путём замены параметра выражения expression на тип конкретной сущности. И наконец с помощью метода HasQueryFilter() добавляем глобальный фильтр.

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

Источник: https://dotnetcoretutorials.com/2022/03/17/using-ef-core-global-query-filters-to-ignore-soft-deleted-entities/

День 1162. #Testing
Шпаргалка по Тестированию Кода
Сегодня поделюсь с вами прекрасной шпаргалкой по тестированию кода от Yoan Thirion. Шпаргалка основана на книге Владимира Хорикова «Принципы юнит-тестирования».– СПб.: Питер, 2022.

Источник: https://twitter.com/yot88/status/1450435942460928000

День 1163. #ЗаметкиНаПолях
Const, Readonly и Static Readonly в C#
Static, Readonly и Const — наиболее распространенные ключевые слова, используемые для объявления переменных. Рассмотрим их сходства и различия на примерах.

1. Константы
Значение const определяется во время компиляции. Основная особенность в том, что константа должна иметь значение при объявлении. Поэтому только примитивные типы (int, string, double и т.п.) можно использовать в качестве констант. Кроме того, константы по умолчанию являются статическими, т.е. не нужно использовать экземпляр класса для доступа к открытой константе.

public class Constant
{
  public const string myVar = "Constant";
}

Console.WriteLine(Constant.myVar);

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

2. Readonly
Ключевое слово readonly означает, что переменной может быть присвоено значение во время выполнения либо при инициализации, либо через нестатический конструктор.

public class Readonly
{
  public readonly string var1 = "Readonly1";
  public readonly string var2;

  public Readonly()
  {
    var2= "Readonly2";
  }
}

var obj = new Readonly();
Console.WriteLine(obj.var2);

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

Когда использовать
Когда нужно инициализировать переменную во время построения класса, а затем она никогда не будет изменена.

3. Static Readonly
Ключевое слово static используется для объявления статических членов. Значение переменной static readonly может быть присвоено во время выполнения либо при инициализации, либо через статический конструктор.

public class StaticReadonly
{
  public static readonly string var1 = "First";
  public static readonly string var2;

  static StaticReadonly()
  {
    var2 = "Second";
  }  
}

Console.WriteLine(StaticReadonly.var2);

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

Источник: https://enlear.academy/const-vs-readonly-vs-static-readonly-in-c-755c20aa0b57

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

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

Решение
Список — структура данных общего назначения, которая может использоваться для хранения разнообразных данных состояния приложения. Неизменяемые списки поддерживают индексирование, однако вы должны учитывать их характеристики быстродействия. Они не должны рассматриваться как тривиальная замена для List<T>.

ImmutableList<T> из пространства имён System.Collections.Immutable поддерживает примерно те же методы, что и List<T>:

var list = ImmutableList<int>.Empty;
list = list.Insert(0, 13);
list = list.Insert(0, 7);
// Выводит "7", затем "13".
foreach (int item in list)
  Console.WriteLine(item);
list = list.RemoveAt(1);

ImmutableList<T> не имеет открытого конструктора; вы начинаете с извлечения пустого ImmutableList<T> с помощью ImmutableList<T>.Empty. Затем можете вызвать методы, такие как Add и AddRange, для заполнения коллекции. Обратите внимание, что эти методы возвращают новый объект. Когда вы добавляете или удаляете элементы из неизменяемого списка, создается копия исходного списка с добавленными или удаленными элементами, а исходный список не изменяется.

Во внутренней реализации неизменяемого списка используется двоичное дерево, чтобы экземпляры могли максимизировать объем памяти, используемый совместно с другими экземплярами. В результате для некоторых распространенных операций существуют различия в быстродействии.
Быстродействие List<T>:
Add ~ O(1)
Insert - O(N)
RemoveAt - O(N)
Item[индекс] - O(1)

Быстродействие ImmutableList<T> - O(log N) для всех операций, а не O(1), как можно было бы ожидать. Если вы замените List<T> на ImmutableList<T> в существующем коде, следует учесть, как ваши алгоритмы обращаются к элементам коллекции.

Например, следует использовать foreach вместо for там, где это возможно. Цикл foreach по ImmutableList<T> выполняется за время O(N), тогда как цикл for по той же коллекции выполняется за время O(N * log N).

ImmutableList<T> — хорошая структура данных общего назначения, но из-за различий в быстродействии вы не можете бездумно заменить ей все List<T>. List<T> часто используется по умолчанию — именно эту структуру данных следует использовать, если только у вас нет веских причин для выбора другой коллекции. Коллекция ImmutableList<T> не настолько распространена; следует тщательно проанализировать другие неизменяемые коллекции и выбрать ту, которая лучше всего подходит для вашей ситуации.

В документации ImmutableList<T>.Builder в MSDN рассматривается эффективный способ заполнения неизменяемых списков.

См. также Неизменяемые стеки и очереди

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

День 1165. #ЧтоНовенького
Темпоральные Таблицы SQL Server в EF Core 6.0
Темпоральные таблицы SQL Server автоматически отслеживают все данные, когда-либо хранившиеся в таблице, даже после того, как эти данные были обновлены или удалены. Это достигается за счёт создания параллельной «таблицы истории», в которой сохраняются исторические данные с временными метками всякий раз, когда в основную таблицу вносятся изменения. Это позволяет запрашивать исторические данные, например, для аудита, или восстанавливать их, например, после случайного изменения или удаления.

EF Core 6.0 поддерживает:
- Создание темпоральных таблиц с помощью миграций EF Core
- Преобразование существующих таблиц во темпоральные таблицы, опять же с использованием миграций
- Запросы исторических данных
- Восстановление данных с какого-то момента в прошлом

Пример использования темпоральных таблиц можно найти на GitHub.

Настройка темпоральной таблицы
Типы сущностей сопоставляются с темпоральными таблицами в OnModelCreating с помощью метода IsTemporal:

protected override void OnModelCreating(ModelBuilder builder)
{
  builder
    .Entity<Product>()
    .ToTable("Products", b => b.IsTemporal());
}

Затем миграции EF Core либо создадут эти таблицы как темпоральные, либо, если таблицы уже существуют, они будут преобразованы в темпоральные. Миграция добавляет два скрытых столбца datetime2 с именами PeriodStart и PeriodEnd. Они представляют диапазон времени, в течение которого существовали эти данные в строке. Эти столбцы сопоставляются с теневыми свойствами в модели EF Core, что позволяет использовать их в запросах.

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

EF Core поддерживает несколько операторов запросов к темпоральным таблицам:
- TemporalAsOf: возвращает строки, которые были активны в указанное время UTC. Это одна строка из таблицы истории для данного первичного ключа.
- TemporalAll: возвращает все строки в исторических данных. Обычно это много строк из таблицы истории для данного первичного ключа.
- TemporalFromTo: возвращает все строки, которые были активны между двумя заданными значениями времени UTC. Это может быть много строк из таблицы истории для данного первичного ключа.
- TemporalBetween: то же, что и TemporalFromTo, за исключением того, что включаются только строки, которые стали активными с начала периода.
- TemporalContainedIn: возвращает все строки, которые начали быть активными и закончили быть активными между двумя заданными значениями времени UTC. Это может быть много строк из таблицы истории для данного первичного ключа.

Например, следующий запрос вернёт цены продукта между двумя датами from и to:

var prices = context.Products
  .TemporalBetween(from, to)
  .OrderBy(p =>
    EF.Property<DateTime>(p, "PeriodStart"))
  .Where(p => p.Name == name)
  .Select(p =>
    new {
      Product = p,
      PeriodStart = 
       EF.Property<DateTime>(p, "PeriodStart"),
      PeriodEnd = 
       EF.Property<DateTime>(p, "PeriodEnd")
    })
  .ToList();

Источник: https://devblogs.microsoft.com/dotnet/prime-your-flux-capacitor-sql-server-temporal-tables-in-ef-core-6-0/

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

1. Знайте свою IDE
IDE предоставляет инструменты, необходимые для написания и тестирования ПО. Лучшие IDE предоставляют интерфейс со всеми необходимыми функциями, включая редактор кода, компилятор, отладчик и средства автоматизации.
«Узнайте, как использовать вашу IDE. Обратите внимание на рефакторинг, который она предоставляет, изучите кнопки, навигацию, горячие клавиши и другие её возможности». — Adam Skinner

2. Изучите командную строку
Интерфейс командной строки (CLI) — это текстовый интерфейс, используемый для запуска программ, управления файлами и взаимодействия с компьютером. CLI позволяет пользователям взаимодействовать с системой или другими приложениями с помощью текстовых команд.
«Изучите команды CLI для поиска, замены и редактирования на лету». – Joseph

3. Никогда не спешите писать код
Разработчики спешат писать код, как только получают спецификации. Но на самом деле наспех написанный код, скорее всего, потребует рефакторинга или очистки.
«Обдумайте всё (и обсудите это с пользователем или клиентом, если возможно), прежде чем писать какой-либо код». – leob

«Мои старшие коллеги научили меня: сначала планируй. Спланируйте реализацию в своей голове. Чтобы записать окончательный вариант, требуется очень мало времени. Разобраться что надо сделать, - вот что требует умения и терпения». – Aman Jaiswal

«Когда я только начинал, мне всегда не терпелось погрузиться в код и потеряться в нем. Десятки ошибок спустя, я могу сказать, что стал немного мудрее». – Raphael Jambalos

4. Избегайте Золотого Молотка
Антипаттерн «золотой молоток» — это когнитивное искажение, которое включает в себя чрезмерную зависимость от знакомых инструментов, языков и платформ. Такой подход ограничивает ваш потенциал в учёбе и приобретении опыта, а также снижает качество вашей работы. Нет универсального размера, который подошёл бы всем.
«Избегай золотого молотка. Нет одного способа сделать что-то. Нужно научиться придумывать варианты, рассматривать их плюсы и минусы и выбирать тот, который сработает в конкретной ситуации». – Melvyn Sopacua

5. Просматривайте свои коммиты
Обзоры кода имеют много преимуществ: она помогает разработчикам получать своевременную обратную связь, выявлять ошибки и неудачные решения, а также учиться у коллег-разработчиков. Проверка своего кода перед коммитом позволит вам найти некоторые очевидные ошибки на самой ранней стадии.
«Всегда просматривайте свои коммиты, прежде чем отправлять их, вы будете поражены тем, сколько ошибок вы поймаете сами, прежде чем код попадёт на глаза другим людям. Лучше потратить 10 минут своего времени, чем час работы коллеги». – Victor A. Barzana

6. Изучайте узкоспециализированные вещи
Существует большой спор о том, должны ли разработчики специализироваться. С одной стороны, чем шире ваши знания, тем больше возможностей вам будет доступно. С другой стороны, вы сильно рискуете стать «мастером на все руки, но не профессионалом ни в чем», страдать от синдрома самозванца и выгорания.
«Не пытайтесь выучить «всё», это пустая трата времени. Изучите основы, затем один или два языка и фреймворка, и всё — не прыгайте на каждую новую игрушку, о которой все говорят». – leob

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

Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc

День 1168. #Карьера
Советы о Продуктивности от Разработчиков для Разработчиков. Продолжение
Начало

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

«Практика в проектах или сторонних проектах — лучший способ изучить технологию» – Adrian Matei

8. Пишите читаемый код
Читаемый код — одно из важнейших качеств хорошего разработчика. Читаемый код экономит время и усилия разработчика, сокращая время отладки и сохраняя его удобным для сопровождения и простым для понимания.

«Пишите читаемый код, не комментируйте его, если код говорит сам за себя. Поэтому используйте чёткие имена переменных/методов». – Victor A. Barzana

«Пишите читаемый, а не сложный/причудливый код. Потом вы скажете себе за это спасибо». – Adrian Matei

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

«Разработчики часто чувствуют, что они недостаточно продуктивны. В большинстве случаев это неправда. Используйте трекер времени, чтобы записывать время, которое вы потратили на свои задачи, и документировать важные действия и вехи». – Jane

10. Используйте буферное время
Agile-команды измеряют несколько показателей продуктивности разработчиков, в том числе скорость команды — объем работы, которую команда может выполнить за один спринт. Чтобы понять свои личные пределы и ограничения рабочей нагрузки, вы можете рассчитать свою индивидуальную скорость, добавить к ней небольшие временные буферы при оценке рабочих действий и наслаждаться работой в более спокойном темпе.

«Постарайтесь оценить и отследить реальное количество времени, которое вы потратили на задачу. После того, как вы найдёте личную скорость, вы сможете контролировать давление, которое компания пытается оказать на вас. Например, если вы знаете, что выполните задачу за 3 часа, вы можете оценить её в 4 часа, и у вас будет время подумать и отдохнуть». – Ihor Klymenok

«Одна действительно важная вещь, в которой я хотел бы быть лучше, когда я получил свою первую работу, — это оценка времени, необходимого для того, чтобы что-то сделать. Не уверен, была ли это моя чрезмерная уверенность в своих способностях, наличие чёткого плана выполнения задачи у меня в голове (обычно мешают неожиданные ошибки) или и то, и другое. Но это заставляло меня обычно называть сроки меньше, чем на самом деле требовалось. Я разочаровывал и себя, и своих товарищей по команде, до тех пор, пока сеньор не помог мне с этим процессом. Если кратко, когда вас спрашивают, сколько времени потребуется для выполнения той или иной задачи, всегда добавляйте буферное время». – Anam.DevDes

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

«В настоящее время рабочие места разработчиков перемещаются на удалённую работу, поэтому становится важно иметь отличные навыки совместной и командной работы. Навык публичных выступлений даст вам преимущество». – Atharva Shirdhankar

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

Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc

#Оффтоп
В чате спрашивали не думаю ли я к каналу донатилку прикрутить. Так сейчас модно вроде. И вот наконец дошли руки. Не могу сказать, чтоб я прям сильно в донатах нуждался. И конечно, посты будут тут выходить в любом случае, пока мне это интересно. Но если вдруг, кому хочется поддержать канал, то буду премного благодарен: https://pay.cloudtips.ru/p/70df3b3b

День 1169. #Карьера
Советы о Продуктивности от Разработчиков для Разработчиков. Продолжение
Начало 1-6
Продолжение 7-11

12. Автоматизируйте всё, что можете
В своей книге «The Passionate Programmer» Чад Фаулер рассказывает о построении блестящей карьеры инженера-программиста, и автоматизация — один из советов, которые он даёт. Многие аспекты работы разработчика можно автоматизировать. Вы можете внедрить инструменты автоматизации для тестирования, проверки кода, документации или для начала внимательно изучить свой редактор кода.

«Автоматизируйте повторяющиеся задачи; всё, что вы делаете, может быть автоматизировано». – DarkWiiPlayer

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

«Выберите инструмент, который сначала может замедлить вас, но поможет позже. Гиперболизированный пример: сегодня можно добиться большего, если использовать блокнот вместо IDE. Но даже если вам понадобится месяц, чтобы изучить основы IDE, следующий месяц с повышенной продуктивностью компенсирует всё потерянное время». – DarkWiiPlayer

14. Инвестируйте в удобные вещи
Точно так же, как разработчики тратят время на изучение новых языков и инструментов, они также должны серьезно относиться к своим офисным принадлежностям. Если вы работаете в опенспейсе и шум вокруг вас отвлекает, не раздумывая, купите себе хорошие наушники! Если вы работаете из дома, вы также должны убедиться, что инструменты, которые вы используете для работы, удобны и надёжны.

«Инвестируйте в наушники с шумоподавлением. Независимо от того, работаете ли вы в офисе или дома, вам нужно сконцентрироваться, чтобы работать в потоке». – Stasy Barns

«Используйте удобный стол и инвестируйте в эргономичное кресло» – sudarshan

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

«Научитесь определять, когда вы выгорели. Перестаньте работать в течение дня, или вздремните или что-то в этом роде. Если вы этого не сделаете, вы зря потратите время и, возможно, создадите новые проблемы на завтра». – Adam Skinner

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

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

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

Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc

День 1170. #Карьера
Советы о Продуктивности от Разработчиков для Разработчиков. Окончание
Начало 1-6
Продолжение 7-11
Продолжение 11-16

17. Делайте перерывы
Наш мозг менее продуктивен без отдыха, и это особенно верно для работников умственного труда. «Наш мозг похож на губку», — говорит доктор Би, психолог. - «Она может впитать конечное количество воды до того, как насытится, а затем должна немного подсохнуть». Поэтому не забывайте планировать время для отдыха и расслабления.

«Даже если вы работаете по 12 часов в день, вы, вероятно, продуктивны всего около трёх часов. Что вам действительно нужно, так это 4 часа упорной работы с регулярными перерывами. Делайте небольшой перерыв после работы в течение 45-60 минут». – Sachin N

См. также «помидорный график»

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

«Записывайте то, что вы сделали каждый день перед сном». – Sachin N

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

«Младшие разработчики, не могут писать (тем более понимать) сложные шаблоны кода и синтаксис, и это нормально. Их решение проблемы не будет таким элегантным и эффективным, как у разработчика с 20-летним стажем, и это нормально. Главное – учиться на ошибках и расти». – Dan Walsh

«Ошибки будут случаться. Они не определяют вашу уровень или компетентность, однако заставляют вас чувствовать себя хуже, когда случаются в вашем коде. Не корите себя, признайте ошибки, проанализируйте их (попросите помощи у старших, если вы застряли) и учитесь». – Melvyn Sopacua

Подробнее о том, как относиться к своим ошибкам

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

«Так постоянно делают все программисты, включая меня: мы пропускаем чтение документации и пытаемся работать с новой технологией самостоятельно. Мы просто переходим в пользовательский интерфейс или API и начинаем его использовать.
Однако, как говорится «вы можете сэкономить много часов отладки, если потратите 10 минут на чтение документации». Если вы не читаете документацию, возможно, вы черпаете информацию из ненадёжных или устаревших источников (да, ответы на Stackoverflow тоже устаревают). Если документация доступна, почему бы просто не прочитать её?
Это не значит, что нельзя получать информацию из руководств или видеоуроков. Но следите за тем, что сказано в официальной документации». – Rajkumar Thangavel

Источник: https://dev.to/actitime/20-productivity-tips-from-developers-to-developers-3bnc