День 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

День 1171. #Карьера
Раз уж вся неделя прошла под тегом #Карьера, давайте и закончим её обсуждением на тему. Ниже привожу подборку видео от известных ИТ блогеров на общую тему «Будущее ИТ в России». Понимаю, что могу тут разжечь, но также считаю рассуждения в духе «мы тут #внеполитики, обсуждение только по теме» несусветной глупостью. Жить в пузыре и игнорировать происходящее вокруг невозможно.

Однако всё-таки важное пояснение:
Здесь все всё понимают, все в интернете и умеют гуглить. Мы тут собрались обсуждать .NET, наши карьеры и будущее. Кроме того, мы все делаем общее дело и стараемся помогать друг другу вне зависимости от политических предпочтений, вероисповедания и географического местоположения. Поэтому прошу вас общаться уважительно и придерживаться (хотя бы косвенно) ИТ темы.

Итак, вот вам 3 ролика о будущем ИТ в России, Украине и Беларуси.

Начну с, на мой взгляд, самого острого и мрачного. Сергей Немчинский «Что будет с IT в Украине, России и Беларуси? Программисты еще нужны?»

Второй ролик от АйТиБороды «Русская айтишка ВСЁ? / ЧТО БУДЕТ ДАЛЬШЕ В IT / НЕ позитивный прогноз.»

Ну и третий, как мне показалось, самый позитивный, от Романа Сакутина «Гибель IT в России. Программисты больше никому не нужны. Что будет дальше?»

Предлагаю обсудить. Что думаете? Про рынок, про отдельные компании, про себя (если не секрет).

Пожалуйста, ещё раз прочитайте пояснение выше.

День 1173. #ЧтоНовенького
Релиз-кандидат .NET MAUI
Выпущен релиз-кандидат .NET Multi-platform App UI (.NET MAUI). Теперь Microsoft поддерживает .NET MAUI для ваших производственных приложений.

Чтобы приобрести .NET MAUI RC1, установите или обновите Visual Studio 2022 до версии 17.2 Preview 3. В установщике убедитесь, что .NET MAUI (preview) отмечен в разделе Mobile Development with .NET workload (Разработка мобильных приложений с рабочей нагрузкой .NET).

Попробовать .NET MAUI можно на тестовом приложении .NET Podcasts, которое работает на Android, iOS, macOS и Windows и демонстрирует как нативный пользовательский интерфейс приложения, так и Blazor Hybrid.
Кроме того, доступно руководство по началу работы с .NET MAUI, где вы создадите приложение от начала до конца и интегрируете нативные функции.

Поддержка Xamarin по-прежнему действует в течение 2 лет после первоначального выпуска, т.е. до ноября 2023 года.

Источник: https://devblogs.microsoft.com/dotnet/dotnet-maui-rc-1/

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

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

Решение
Существует два типа неизменяемых множеств: ImmutableHashSet<T> — коллекция уникальных элементов и ImmutableSortedSet<T> — отсортированная коллекция уникальных элементов. Эти типы из пространства имён System.Collections.Immutable обладают похожим интерфейсом:

var hs = ImmutableHashSet<int>.Empty;
hs = hs.Add(13);
hs = hs.Add(7);
// Выводит "7" и "13" в непредсказуемом порядке

foreach (int item in hs)
  Console.WriteLine(item);

hs = hs.Remove(7);

Отсортированное множество допускает индексирование по аналогии со списком:

var shs = ImmutableSortedSet<int>.Empty;
shs = shs.Add(13);
shs = shs.Add(7);
// Выводит "7", затем "13"

foreach (int item in shs)
  Console.WriteLine(item);

int smallest = shs[0]; // 7
shs = shs.Remove(7);

Несортированные и отсортированные множества обладают схожим быстродействием: O(log N) для добавления, удаления. Важное примечание: обращение по индексу в сортированном множестве также выполняется за время O(log N), а не O(1), как и у ImmutableList<T>. Это означает, что в данной ситуации действует та же рекомендация: используйте foreach вместо for там, где это возможно.

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

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

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

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

День 1175. #Юмор
Сегодня порекомендую вам юморное видео «HR x IT» от makelove agency. Это пилотное видео из серии «Мы вас перезвоним», в котором ребята сталкивают лбами разных представителей айтишечки. И они сразу решили зайти с козырей. HR против разработчика. Их претензии друг другу и разбор самых распространённых мифов об их профессиях. Некоторые требования айтишников даже меня удивили)))

В комментариях на девушку HRа накинулись за грубость 18+, но лично мне показалось, она вполне соответствовала образу.

В общем, веселый дружеский срачик. Мне понравилось.

https://youtu.be/Yyp4VVPylLg

День 1176. #ЗаметкиНаПолях
GraphQL или REST API. Что Использовать? Начало
REST и GraphQL — это стандартные способы разработки серверных API. В последнее десятилетие REST API доминировали, и многие компании и разработчики активно используют его в своих проектах.
Но у REST есть некоторые ограничения, и есть другая доступная альтернатива — GraphQL.

GraphQL был разработан Facebook в 2012 году для внутреннего использования и обнародован в 2015 году. Это язык запросов для API и среда исполнения для выполнения этих запросов к вашим существующим данным. Цитата с официального сайта:
«GraphQL предоставляет полное и понятное описание данных в вашем API, дает клиентам возможность запрашивать именно то, что им нужно, и ничего больше, упрощает развитие API с течением времени и предоставляет мощные инструменты разработчика.»

Проблемы с REST API
1. Запрос нескольких конечных точек
2. Получение лишних данных
3. Неполная выборка и проблема n+1 запроса
4. Медленный отклик на меняющиеся требованиями клиента
5. Высокая связанность между внутренними контроллерами и внешними представлениями

Предположим, что нам нужно показать краткую информацию о пользователе: имя, должность и текст «о себе». С REST запрос будет GET по адресу /users/1. Проблема в том, что сервер возвращает фиксированную структуру данных с множеством ненужной информации. Например:

{
  "id": 1,
  "name": "John Smith",
  "username": "jsmith",
  "email": "[email protected]",
  "title": "Software Engineer",
  "phone": "9876543210",
  "about": "As a software engineer my daily routine revolves around writing cleancode, maintaining infrastructure, and building scalable software systems.",
  "website": "https://www.jsmith.tech",
  "gender": "MALE",
  "city": "Denver",
  "state": "Colorado",
  "country": "US",
  …
}

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

GraphQL позволяет отправить запрос только нужных данных, который будет выглядеть примерно так:

{
  user(id: 1){
    name
    title
    about
  }
}

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

Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/

День 1177. #ЗаметкиНаПолях
GraphQL или REST API. Что Использовать? Окончание
Начало

Теперь предположим, что нам нужно отобразить в списке имена пользователей и их «опыт» на текущем месте работы. В REST, учитывая, что «опыт» - это таблица с внешним ключом user_id, есть три возможных варианта:
1) Создать структуру со всеми внешними связями таблицы users и получать все данные в неё. Но это приведёт к очень дорогостоящим запросам и возвращает много данных из всех внешних таблиц, которые в большинстве случаев не требуются.

2) Делать несколько запросов на сервер:

GET /users 
GET users/1/experience 

Это пример неполной выборки, так как у одной конечной точки недостаточно данных. Но множественные сетевые вызовы замедляют процесс и влияют на работу пользователя. Кроме того, в случае списка неполная выборка усугубляется тем, что нам нужно сделать запрос опыта для каждого пользователя в списке, и мы сталкиваемся с проблемой n+1 запроса.

GET /users
GET users/1/experience
GET users/2/experience
…
GET users/n/experience

3) Создать специальный контроллер, который возвращает структуру данных, соответствующую требованиям клиента на данный момент времени.

GET /user-experience

Это и делается в большинстве реальных случаев в REST API.

С другой стороны, простой запрос GraphQL будет без проблем работать без каких-либо дополнительных изменений на стороне сервера. Запрос будет выглядеть примерно так:

{
  users{
    name
    experience{
     organization
     title
     duration
    }
  }
}

Да, можно использовать REST, создавать контроллеры (методы) под требования клиента. Но есть большой недостаток. Мы сформировали тесную связь клиентского представления с внутренними контроллерами API, поэтому потребуется больше усилий, чтобы обрабатывать запросы клиентов. Пользовательский контроллер возвращает данные в зависимости от того, что хочет отобразить представление, поэтому, когда требования изменятся, придётся менять как представление, так и контроллер.

Например, по прошествии времени в списке потребовалось выводить не опыт, а последнюю транзакцию пользователя. С REST нужно будет внести соответствующие изменения в представление, но также придётся изменить и контроллер (добавить метод), и путь. То есть изменение требований клиента сильно влияет на то, что должно быть возвращено сервером.

С GraphQL нам не нужно будет вносить какие-либо изменения на стороне сервера. Изменение внешнего запроса будет минимальным:

{
  users{
    name
    transactions{
     amount
     type
    }
  }
}

Никакого рефакторинга серверного API, развертывания и тестирования — это означает экономию времени и усилий!

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

Источник: https://www.freecodecamp.org/news/graphql-vs-rest-api/

День 1178. #Юмор
Вытащу на пятничную болталку очередной твит. Kim Maida предложила следующее задание:
«Расскажите, сколько вам лет в «годах разработчика» одним предложением, не называя фактической цифры.»

Вот некоторые ответы:

«Разработчики на jQuery не *настоящие* JavaScript разработчики»

«Поддержка IE6»

«Использовал картинки с четвертью круга для скругления углов таблиц»

«Моих нынешней и предыдущей профессий не существовало»

«Начинал в классическом ASP, когда он ещё был просто ASP»

«autoexec.bat»

«Javascript поддерживается только в Netscape Navigator»

«Пожалуйста, не используй телефон, у меня загружается огромный файл в 50Мб»

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

«Не используй mov, просто сделай XOR регистра с самим собой, это сэкономит память»

«Через несколько лет после того, как я начал программировать, я перешёл с кассет на флоппи-диски. Они намного быстрее!»

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

Добавлю от себя:
«Самые современные компьютеры на корпусе, помимо кнопки включения, имели кнопки Reset и Turbo»

Оставляйте ваши варианты в комментариях.

Источник: https://twitter.com/KimMaida/status/1514652490683367438

День 1179. #ЗаметкиНаПолях
Выделяем Подмассивы. Начало
Сегодня рассмотрим, различные способы выделения подмассива в C#.

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

Допустим, у нас есть массив строк:

var posts = new string[] { "post1", "post2", "post3", "post4", "post5", "post6", "post7", "post8", "post9", "post10" };

1. Использование LINQ
В LINQ есть методы Skip() и Take():

var sliced = posts.Skip(0).Take(5);
// Элементы с post1 до post5

Мы передаем количество элементов, которые хотим пропустить, методу Skip() - начальный индекс, и количество элементов, которые хотим включить, в метод Take(). Операция возвращает новый IEnumerable, который мы можем перечислить.

2. Использование метода Copy()
Тот же сценарий, но помощью метода массива Copy():

var sliced = new string[5];
Array.Copy(posts, 0, sliced, 0, 5);

Здесь мы инициализируем целевой массив, затем мы вызываем метод Copy(), который принимает исходный массив, начальный индекс, целевой массив, начальный целевой индекс (ноль, потому что мы копируем в новый массив) и количество элементов, которые мы хотим скопировать. Метод возвращает новый массив, содержащий скопированные элементы.

3. Оператор диапазона (x..y) в C# 8.0+
Начиная с C#8 появился новый оператор диапазона, который сделал выделение подмассива синтаксически очень простым. Он позволяет выделить элементы между индексом «x» и индексом «y», не включая элемент с индексом «y»:

var s1 = posts[2..]; // co 2го до конца
var s2 = posts[..2]; // с начала до 1го
var s3 = posts[1..3]; // с 1го до 2го
var s4 = posts[..]; // весь массив
var s5 = posts[3..^0]; // с 3го до предпоследнего

Оператор диапазона также выделяет новый массив.

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

Источник: https://code-maze.com/csharp-array-slicing/

День 1180. #ЗаметкиНаПолях
Выделяем Подмассивы. Окончание
Начало

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

var data = new (int, bool)[] {
  (20, true),
  (50, true),
  (35, false),
  (55, true),
  (16, false)
};

Заметьте, что в примере у нас всего 5 элементов. В реальной же модели обучения их могут быть миллионы, поэтому выделять новый массив будет очень затратно.

4. Использование ArraySegment<T>

var train = new ArraySegment<(int, bool)>(data, 0, 3);
var test = new ArraySegment<(int, bool)>(data, 3, 2);

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

То же самое можно сделать с помощью метода ArraySegment<T>.Slice():

var all = new ArraySegment<(int, bool)>(data);
var train = all.Slice(0, 3);
var test = all.Slice(3, 2);

Мы создаем ArraySegment, который охватывает весь массив, затем вызываем метод Slice(), который создает ещё один ArraySegment с указанными границами.

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

5. Использование ReadOnlySpan<T> и Span<T>
ReadOnlySpan<T> предоставляет оболочку, которая позволяет только чтение из массива:

var train = new ReadOnlySpan<(int, bool)>(data, 0, 3);
var test = new ReadOnlySpan<(int, bool)>(data, 3, 2);

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

Код, использующий Span<T> и его поведение аналогичны коду с ArraySegment<T>. Их отличие в том, что Span<T> можно использовать не только для массивов. Кроме того, ArraySegment<T> реализует IEnumerable<T> таким образом позволяет вернуть результат как IEnumerable<T>, тогда как ReadOnlySpan<T> и Span<T> возвращают соответствующие типы, хотя оба имеют метод GetEnumerator(), поэтому их также можно перечислить через foreach.

Сравнение быстродействия
На массиве из 10 строк быстродействие выделения подмассива из 5 элементов и их перечисления. Общий вид методов:

public int <Метод>()
{
  // получение подмассива указанным методом
  var slice = <подмассив>;
  var cnt = 0;
  foreach (var item in slice)
    cnt++;

  return cnt;
}

Результаты на картинке ниже.

Источник: https://code-maze.com/csharp-array-slicing/