День семьсот двенадцатый.
Используйте 2021й с Умом
Вот и настал первый рабочий день 2021го года. Судя по всему, он вряд ли будет сильно лучше 2020го. Как сделать так, чтобы по итогам года можно было сказать, что он не прошёл зря? Недавно вышло отличное видео на эту тему от Tim Corey. Подробности по ссылке в конце, а в посте приведу краткий перевод.

1. Задайте себе цель. Не призрачную, типа «хочу в будущем стать крутым разработчиком и получать много денег». Какую-то конкретную, достижимую к концу года: повысить свою квалификацию как разработчика в ХХХ. Для этого надо изучить сначала вот это, потом это, а затем вон то. Допустим, на первое вам потребуется 2 месяца, на второе ещё три, и т.п. Главное держать в уме цель и план движения к этой цели.

2. Пишите код. Неважно, сколько материала вы прочитаете, посмотрите или услышите. Пока вы это не попробуете, не столкнётесь с проблемами, и не решите их, материал не усвоится. Кроме того, вы ОБЯЗАТЕЛЬНО что-то упустите или неверно поймёте. И только практикой получится найти, что вы упустили, и исправить это.

Что Изучать .NET Разработчику в 2021м
Понятно, что для каждого индивидуально список может варьироваться, но далее будут 4 общих темы, которые подойдут всем.
1. C#
Как бы это банально ни звучало, стоит подтянуть базис. В какой бы сфере разработки вы ни были заняты, C# лежит в основе всего. И хорошее знание языка поможет всегда. Повторите темы, с которыми вы редко работаете. Подучите то, что давно откладывали.

2. Веб
Изучите основы HTML, CSS и Javascript, если ещё не сделали этого. Затем ASP.NET Core. Сюда входят все 5 основных типов проектов: MVC, Razor Pages, Web API, Blazor Server и Blazor WebAssembly. Изучите типы проектов, с которыми не работали.

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

4. Azure
Или другой облачный сервис, например, AWS. Всё больше компаний переходят в облако. А сами облачные провайдеры предлагают всё больше и больше различных полезных сервисов, которые могут использовать не только крупные компании, но и отдельные разработчики. Поэтому знания о том, как они работают, будут ценными в любой области разработки.

Что НЕ СТОИТ Изучать .NET Разработчику в 2021м
Со следующими темами нужно быть аккуратными. Вокруг них в последнее время много хайпа, но там могут оказаться серьёзные подводные камни.
1. Machine Learning
Этим уже прожужжали все уши. «Запишитесь на наши курсы, и всего за пару месяцев вы измените свою жизнь. Вас ждёт интересная работа, гарантии трудоустройства, а зарплаты специалистов машинного обучения начинаются со 100 тысяч рублей». Да, это очень интересно и круто. Только никто не говорит, что обычному человеку без серьёзного математического образования стать хорошим специалистом в машинном обучении будет довольно сложно.

2. Javascript Фреймворки для Фронтэнда
Angular, React, Vue – все очень интересные вещи. Но C# разработчику углублённо их изучать по принципу «чтоб было» не стоит. Эти фреймворки появляются, развиваются и исчезают очень быстро. И поддерживать актуальные знания о них – значит учиться постоянно, то есть уйти с головой во фронтэнд. Если вы уже хорошо знаете основы работы веб (см. выше), и только если вы посчитаете, что какой-то из этих фреймворков вам поможет в работе, тогда стоит его изучить.

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

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

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

День семьсот тринадцатый. #Оффтоп #РазговорыПоВторникам
Эмоциональное Выгорание
Первый рабочий вторник, первый разговор по вторникам в этом году. И снова тему дал Сергей Немчинский. Эмоциональное выгорание. Что это и как с этим бороться.

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

Жду ваших комментариев.

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

День семьсот четырнадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
73. Простота от Сокращения
«Переделай это…», - сказал мне босс, нажимая и удерживая клавишу Delete. Я смотрел на экран компьютера со знакомым многим ощущением стыда и безысходности, поскольку мой код - строка за строкой - исчезал в небытии.

Мой босс, Стефан, не отличался красноречием, но он мог опознать плохой код, когда видел его. И он точно знал, что с ним делать.

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

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

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

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

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

Конечно, если реорганизация не помогает, просто удалите всё и напишите код заново. Такое воссоздание с нуля часто помогает избавить код от значительной части лишнего мусора.

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

День семьсот пятнадцатый. #TypesAndLanguages
Довольно интересной показалась серия статей Types and Programming Languages от Adam Furmanek. Интересные наблюдения и тонкости языков программирования. Сегодня первая часть.

1. Не используйте return в блоке finally
Многие языки предоставляют конструкцию обработки исключений, обычно в виде блоков try и catch, хотя детали реализации различаются. Программисты обычно предполагают, что эти конструкции работают одинаково для разных языков. К сожалению, это неправда, и нюансы часто бывают сложны для понимания, когда дело доходит до крайних случаев.

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

Некоторые языки позволяют возвращать результат из блока finally. В следующем примере на Java последний return «побеждает» другие:

public static void main (String[] args)
    throws java.lang.Exception {
  System.out.println(foo());
}
public static int foo(){
  try{
    return 5;
  }finally{
    return 42;
  }
}

Результат - 42, потому что это последнее возвращаемое значение. Такое же поведение можно видеть в Python, JS, возможно, и на других платформах. Примечательным исключением здесь является C#, который не позволяет использовать return в блоке finally, просто чтобы избежать этой путаницы.

Результат кажется простым и логичным. Но что произойдет, если вы выбросите исключение, а затем используете return? Например, в Java:

public static void main (String[] args)
    throws java.lang.Exception {
  System.out.println(foo());
}
public static int foo() {
  try {
    throw new RuntimeException(
      "Это сообщение пропадает");
  }finally{
    return 42;
  }
}

Результат – всё равно 42. Исключение «проглатывается». То же самое в JS:

function foo(){
  try{
    throw "Это сообщение пропадает";
  }finally{
    return 42;
  }
}
console.log(foo());

Python:

def foo():
  try:
    raise Exception("Это сообщение пропадает")
  finally:
    return 42
 
print(foo())

В общем случае, никогда не используйте return в блоке finally. Это ломает механизм обработки исключений.

Источник: https://blog.adamfurmanek.pl/2021/01/09/types-and-programming-languages-part-1/

День семьсот шестнадцатый.
10 Библиотек C#, Которые Сохранят Ваше Время и Энергию
Интересная подборка от Tim Corey библиотек и инструментов, которые серьёзно упростят вашу жизнь.

1. SharpZipLib http://icsharpcode.github.io/SharpZipLib/
NuGet пакет для архивации на C#, который может быть использован в ваших проектах. Поддерживает zip, gzip, bzip2 и tar форматы. Может создавать архивы, читать, извлекать файлы из них и т.п.

2. FluentEmail https://github.com/lukencode/FluentEmail
Простой пакет для отправки email из .NET и .NET Core. Использует Razor для шаблонов email и может отправлять письма через SendGrid, MailGun, SMTP и т.д. Слово «простой» здесь не следует путать с «примитивный». Инструмент достаточно мощный. Но в общем случае, если вам нужно просто отправлять email из вашего приложения на C#, FluentEmail - то, что вам нужно.

3. MailKit https://github.com/jstedfast/MailKit
А вот когда нужна тонкая настройка отправки (аутентификация, прокси, настройка SMTP/POP3/IMAP клиентов и т.п.), вам поможет MailKit.

4. Papercut SMTP https://github.com/ChangemakerStudios/Papercut-SMTP
Ещё один инструмент для работы с электронной почтой. Это простой локальный SMTP сервер для тестирования отправки почты. С помощью Papercut SMTP вы можете просматривать и инспектировать всю почту, которую отправляет ваше приложение, включая просмотр заголовков и исходного кода письма.

5. EPPlus https://github.com/EPPlusSoftware/EPPlus
Пакет для чтения и записи файлов Excel из вашего кода C#. Требует лицензии для коммерческого использования, но для разработки можно использовать бесплатно.

6. Hangfire https://www.hangfire.io/
Инструмент, помогающий вам запускать фоновые задания в .NET. В бесплатной версии поддерживает обычный запуск фоновой задачи, отложенный запуск, выполнение по расписанию, выполнение задачи в продолжение другой задачи. В платной версии можно запускать пакеты задач. Кроме того, у Hangfire есть удобная панель мониторинга выполнения задач.

7. MassTransit https://masstransit-project.com/
Слой абстракции для использования инструментов очередей, вроде Azure Service Bus или RabbitMQ.

Следующие пакеты уже упоминались на канале, но на всякий случай повторю.

8. Polly https://github.com/App-vNext/Polly
Пакет предназначен для осуществления повторных попыток. Если у вас есть API, который может быть недоступен какое-то время, вам необходимо реализовать механизм повторения запросов, и Polly очень облегчит вам жизнь.

9. Serilog https://serilog.net/
Пакет, практически ставший стандартом де-факто для ведения структурированных логов в .NET.

10. Seq https://datalust.co/seq
Этот инструмент поможет вам разобраться в логах, созданных, например, тем же Serilog. Он предоставляет панель управления для визуализации и быстрой фильтрации информации, сохранённой в логах. С помощью Seq вы можете посмотреть, как часто возникает то или иное событие, найти все записи в логах по заданным параметрам и т.п.

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

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

7. Станьте Мультипликатором Силы
В один прекрасный спринт я случайно почувствовал мощь Силы.
«Сила — это то, что даёт джедаю его могущество. Это энергетическое поле, создаваемое всеми живыми существами. Она окружает и пронизывает нас. Она связывает Вселенную воедино».
– Оби-Ван Кеноби, «Звездные войны»

Я думаю, что Оби-Ван Кеноби познал истину, хотя и не в той области. Это то, что я могу использовать в разработке программного обеспечения: стать мультипликатором силы.

В том спринте я сам многого не добился. Я написал совсем чуть-чуть кода. Зато я координировал, какие изменения должны выйти, когда (это был сложный спринт), тестировал изменения, делал много обзоров кода, вносил альтернативные предложения по дизайну и программировал в паре, когда это требовалось, и когда кто-то застревал, чтобы двигать весь процесс вперёд. Мы всё сделали, и в этом случае отход от деталей и более общий взгляд на проект помог мне легче принимать управленческие решения. Это был один из наших самых продуктивных спринтов.

«Сила — это то, что даёт разработчику его могущество. Это энергетическое поле, создаваемое всеми разработчиками и их инструментами. Она окружает и пронизывает нас. Она связывает код воедино».

Ладно, хватит про «Звёздные войны».

Разобраться в том, как стать мультипликатором силы, для меня важнее, чем взять в команду ещё 10 разработчиков. На практике хорошим множителем (или разделителем) силы является командная культура. Точно так же, как я могу создать привычки для улучшения моих результатов, так может сделать и вся команда. Это происходит из командной культуры. Ретроспективы, обзоры кода и эксперименты - это всё команда делает для формирования своей культуры. Культура постоянно меняется, поскольку члены команды приходят и уходят, добавляя свои личные штрихи.

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

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

День семьсот восемнадцатый. #ЗаметкиНаПолях
Делаем Заглавными Первые Буквы Слов
Работа над презентацией – значительная часть разработки ПО. Мы тратим на форматирование строк больше времени, чем хотелось бы.

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

Большинство элементов отображения текста не универсальны для .NET, а управляются экземплярами типа CultureInfo, хранящими настройки языка и региональных параметров. Экземпляры CultureInfo определяют стили даты, валюты и т.п. В CultureInfo также вложен класс TextInfo, который определяет систему написания слов в культуре. Его метод ToTitleCase можно использовать для преобразования текста в регистр заголовка.

using static System.Console;
using static System.Globalization.CultureInfo;

var сulture = GetCultureInfo("en-gb");
var info = сulture.TextInfo;

var name = ".NET is aWESome";

WriteLine(info.ToTitleCase(name));
//Вывод: .NET Is Awesome

Заметьте, что аббревиатура .NET оставлена в изначальном виде, тогда как прописные буквы в слове "aWESome" заменены строчными.

Остаётся одна проблема. По правилам английского написания слово «is» не должно начинаться с заглавной буквы. Аналогично в других языках предлоги и союзы должны оставаться строчными. Например:
Немецкий
Исходная строка: Per anhalter durch die galaxis
Ожидаемый результат: Per Anhalter durch die Galaxis
Реальный результат: Per Anhalter Durch Die Galaxis

Французский
Исходная строка: les naufragés d'ythaq
Ожидаемый результат: Les Naufragés d'Ythaq
Реальный результат: Les Naufragés D'ythaq

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

Источник: https://khalidabuhakmeh.com/capitalize-first-letter-of-words-with-csharp

День семьсот двадцатый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
74. Принцип Единственной Ответственности
Вспомним SOLID. Один из основных принципов хорошего дизайна ПО гласит:
Соберите вместе то, что меняется по одной и той же причине, и разделите то, что меняется по разным причинам.

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

public class Employee {
  public double CalculatePay() …
  public string ReportHours() …
  public void Save() …
}

На первый взгляд объединение этих трёх методов в одном классе совершенно уместно. В конце концов, классы и должны быть наборами функций, которые работают с общими данными. Однако проблема в том, что эти три метода меняются по совершенно разным причинам. Метод CalculatePay будет меняться всякий раз, когда меняются бизнес-правила расчёта оплаты. Метод ReportHours будет меняться, когда кто-то захочет изменить формат отчёта. Метод Save будет изменяться всякий раз, когда администраторы баз данных изменяют схему базы данных. Эти три причины для изменений в совокупности делают класс Employee очень нестабильным. Он будет изменяться по любой из этих причин. Что ещё более важно, эти изменения повлияют на любые классы, которые зависят от Employee.

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

public class Employee {
  public double CalculatePay()…
}
public class EmployeeReporter {
  public string ReportHours(Employee e)…
}
public class EmployeeRepository {
  public void Save(Employee e)…
}

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

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

Тщательное применение SRP, разделение вещей, которые меняются по разным причинам, является одним из ключей к созданию проектов, которые имеют независимо развёртываемую структуру компонентов.

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

День семьсот двадцать первый. #TypesAndLanguages
2. Исключение при Обработке Исключения
В прошлый раз мы рассмотрели, что не стоит использовать return в блоке finally. Сегодня исследуем аналогичный случай исключения при обработке исключения:

try{
  try{
    throw new Exception("Exception 1");
  }finally{
    throw new Exception("Exception 2");
  }
}catch(Exception e){
  Console.WriteLine(e);
}

Что будет выведено? Этот вопрос с подвохом. Во-первых, есть два исключения, и мы знаем, что некоторые языки (включая платформу .NET) реализуют двухпроходную систему обработки исключений. Первый проход по стеку ищет обработчик, способный обработать исключение, затем второй проход раскручивает стек и выполняет все блоки finally. Но что, если мы выбросим исключение во втором проходе?

Результат различается в разных языках. Например, C# теряет исключение, что указано в спецификации:
Если блок finally выбрасывает другое исключение, обработка текущего исключения прекращается.

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

Это важно при работе с ресурсами. Некоторые языки предоставляют конструкцию типа using в C#:

using(var resource = new Resource()){
  //…
}

Концептуально это аналогично следующему коду:

var resource = new Resource();
try{
  //…
} finally{
  if(resource != null) resource.Dispose();
}

Кажется довольно просто. Но что если Dispose выбросит исключение:

public class Resource : IDisposable {
  public void Dispose(){
    Console.WriteLine("Disposing");
    throw new Exception("Disposing failed");
  }
}

Тогда следующий код:

try{
  using(var resource = new Resource()){
    Console.WriteLine("Using");
    throw new Exception("Using failed");
  }
}catch(Exception e){
  Console.WriteLine("Exception: " + e);
}

выведет

Using
Disposing
Exception: System.Exception: Disposing failed
   at Resource.Dispose()
   at Program.Main()

Мы теряем исключение "Using failed" из-за нового исключения "Disposing failed" в блоке finally. Кстати, в Java это реализовано правильно, и сохраняет оба исключения.

Источники:
- https://blog.adamfurmanek.pl/2021/01/16/types-and-programming-languages-part-2/
- https://blog.adamfurmanek.pl/2020/07/25/net-inside-out-part-21/

День семьсот двадцать второй. #Оффтоп
Вытащу несколько вещей из чата. Во-первых, чтобы самому не забыть, а во-вторых, для тех, кто не следит за чатом. Сегодня вещь первая.

Интересное видео – очередная серия подкаста Solo on .NET от Дмитрия Нестерука о языках программирования. Хотел написать, что подойдёт новичкам для выбора языка. Но потом вспомнил количество технологий и узкоспециализированных терминов, о которых говорит Дмитрий, и понял, что новичок послушает, ужаснётся и вообще откажется от затеи связать свою жизнь с программированием)))

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

День семьсот двадцать третий. #Оффтоп
Вытащу несколько вещей из чата. Во-первых, чтобы самому не забыть, а во-вторых, для тех, кто не следит за чатом. Сегодня вещь вторая. См. вещь первая.

Разговор зашёл о вопросах на собеседовании и, в частности, про TAP (Task-based Asynchronous Pattern), про которую очень любят спрашивать, например, в Epam. Поскольку тема обширная и запутанная, или, цитируя один из источников ниже: «При попытках понять асинхронность наблюдается чередование состояний "теперь понятно" и "теперь снова непонятно".», - в этом посте сохраню несколько источников для изучения темы.

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

2. «The Task-based Asynchronous Pattern» Stephen Toub, Microsoft, 2012
Статья около 35 страниц. Довольно старая, но концептуально ничего не поменялось.

3. «Async/await в C#: концепция, внутреннее устройство, полезные приемы»
Полезная статья, возможно немного сумбурная, потому что сжато. Мне показалось, что это вольный пересказ 5й главы книги «С# In Depth» Джона Скита. Для любителей читать в печатном варианте, см. вложение ниже.

4. Также скромно порекомендую полистать посты на канале, например, по тегу #AsyncAwaitFAQ.

День семьсот двадцать четвёртый. #MoreEffectiveCSharp
20. Учитывайте, Что События Усиливают Связанность Объектов во Время Выполнения
Кажется, что события предоставляют способ полностью отделить ваш класс от классов, которые он должен уведомлять. Вы определяете тип события и позволяете подписываться на него. Внутри вашего класса вы вызываете событие. Ваш класс ничего не знает о подписчиках и не налагает ограничений на них. Код можно расширить, создавая любое необходимое поведение при возникновении этих событий. Однако не всё так просто.

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

public class WorkerEngine {
  public event
   EventHandler<WorkerEventArgs> OnProgress;
  public void DoLotsOfStuff() {
    for (int i = 0; i < 100; i++) {
      SomeWork();
      var args = new WorkerEventArgs();
      args.Percent = i;
      OnProgress?.Invoke(this, args);
      if (args.Cancel) return;
    }
  }
  private void SomeWork(){…}
}

Теперь все подписчики на это событие связаны. Если один подписчик запросит отмену операции, установив Cancel в true, другой может отменить это. Таким образом, последний подписчик в цепочке может переопределить действие любого предыдущего. Невозможно заставить иметь только одного подписчика, и нет способа гарантировать, что делегат какого-то из подписчиков будет выполнен последним. Вы можете изменить аргументы события, чтобы гарантировать, что после установки флага отмены ни один подписчик не сможет его выключить:

public class WorkerEventArgs : EventArgs {
  public int Percent { get; set; }
  public bool Cancel { get; private set; }
  public void RequestCancel() {
    Cancel = true;
  }
}

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

Во время выполнения возникает ещё одна форма связи между источником события и подписчиками. Источник содержит ссылку на делегат, который предоставляет подписчик. Время жизни объекта подписчика теперь будет соответствовать времени жизни объекта источника. Источник будет вызывать обработчик подписчика всякий раз, когда происходит событие. Но это не должно продолжаться после удаления подписчика. То есть подписчикам на события необходимо реализовать паттерн Disposable и отписываться от события в методе Dispose(). В противном случае подписчики продолжат существовать, поскольку в источнике будут ссылки на их делегаты.

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

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

Источник: Bill Wagner “More Effective C#”. – 2nd ed. Глава 20.

День семьсот двадцать пятый. #Оффтоп
Вы Всё Ещё не Пишете Тесты?
Редкий пост с моими собственными мыслями, без источника. Мысли предельно примитивные, поэтому не ругайте строго.

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

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

1. Тесты помогают найти ошибки
У нас на сайте есть общедоступная статистика. Некоторые отчёты доступны года с 2003го, другие появились позже. Есть несколько предустановленных периодов, которые пользователь может выбрать для удобства, чтобы не устанавливать даты вручную: предыдущая неделя, предыдущий месяц, квартал, год, год-до-текущей-даты и т.п. Собственно, написан метод (не мной), которому передаётся выбранный период (например, предыдущий месяц) и сроки доступности отчёта, а выдаётся дата начала и дата окончания периода. Однако период передаётся в виде 2х параметров: тип периода (день, неделя, месяц, квартал, год) и количество периодов. То есть используется метод всегда с количеством 1 (предыдущий), но теоретически можно передавать и другое число. Кроме того, результирующие даты ограничиваются сроком доступности отчёта. Например, если запрошен отчёт за предыдущие 2 года, а доступен он только за год, то дата начала берётся как первый день доступности отчёта. Аналогично с датой окончания.

Получил тикет, что неверно выбирается предыдущий квартал. Метод написан осенью, а сейчас вылезло, что 4й квартал 2020го начинается не с октября, а с сентября. Простейшая опечатка. В логике поставлен не 10й месяц, а 9й. Остальная логика на первый взгляд казалась правильной, но какой-то странной. Поэтому я решил всё-таки написать серию тестов. Так вот, поскольку метод использовался с количеством периодов равным 1, он чуть ли не в половине случаев неверно рассчитывал даты, если задать другое количество периодов. Я в итоге нашёл 3 или 4 ошибки в расчётах. Даже в такой вроде бы не самой сложной логике!

2. Покрытие тестами реально повышает уверенность в коде
У вас бывало так, что перед релизом вроде всё работает, но всё равно терзает какое-то странное чувство, что что-то не так? Тесты позволяют избавиться от этого чувства. В методе, который я описал выше, я, конечно, изменил не только 9й месяц на 10й. Я исправил примерно четверть его кода. Но из-за наличия тестов я на 100 (хорошо, на 99) процентов уверен, что теперь он работает правильно.

День семьсот двадцать шестой. #ЗаметкиНаПолях
Как Работает Git. Начало
Определение Git в Википедии - распределённая система контроля версий. То есть мало того, что Git делает то, что делают другие системы контроля версий (такие как Subversion), он делает это распределённым способом.

Это довольно сложно понять сразу, поэтому уберём один слой – распределённость. Представим, что в мире есть только один компьютер и на нём есть репозиторий. Таким образом, Git становится просто системой контроля версий. Однако это тоже сложное понятие. Оно включает в себя такие вещи, как история, ветки, слияния… Упрощаем дальше. Забудем про ветки, историю и т.п. Теперь это можно назвать примитивным трекером контента (stupid content tracker – определение Git из документации). Потому что это всё, что он делает - отслеживает контент, файлы или каталоги. Но давайте забудем и об отслеживании контента. Посмотрим на самую суть, основную идею. И на самом деле Git – это просто карта, которая сопоставляет ключи со значениями.

Значения - это просто любая последовательность байт, например, содержимое текстового или даже двоичного файла. Для ключа Git вычисляет хэш значения с помощью алгоритма SHA‑1. У каждого объекта в репозитории есть собственный хэш-ключ. SHA‑1 представляет собой последовательность из 40 шестнадцатеричных цифр, например, 239982efa3b9bb5cf84e1b8a9f188025432e789e. Для получения хэша значения используется команда git hash-object.

Хранение
Теперь посмотрите в папку с любым репозиторием Git. В ней есть скрытая папка .git, которая и хранит репозиторий. Зайдите в папку .git/objects. Пока не обращайте внимания на папки init и pack. Заметьте, что остальные папки содержат первые 2 символа хэша, а файлы внутри этих папок названы оставшимися 38 символами. Для объекта выше это будет папка 23, файл 9982efa3b9bb5cf84e1b8a9f188025432e789e. Этот файл содержит сжатое значение. Значение можно посмотреть с помощью команды git cat-file, передав ей хэш. Параметр -t выдаст нам тип объекта (в данном случае blob), а параметр -p распакует и выдаст содержимое файла.

И точно так же хранятся все коммиты. Коммит – это просто текстовый файл, хранящийся в репозитории. Его так же можно посмотреть через git cat-file. Только, если передать параметр -t, то результатом будет commit.

git cat-file 1177e23 -p
tree be4d42cd6ecc95e9fa5bc3e029bf28bb263104c0
author S.Benzenko <…> 1606106642 +0300
committer S.Benzenko <…> 1606106642 +0300
Initial commit

Помимо данных об авторе, времени и сообщении лога, коммит содержит хэш ещё одного объекта типа tree. В Git blob представляет файл, а tree - папку. Коммит указывает на корень проекта. Так же, как и всё остальное, tree – это текстовый файл, который содержит список хэшей файлов и папок, их имена, а также цифровое представление прав доступа к ним.

git cat-file be4d42cd -p
100644 tree 3ee7d56f… folder1
100644 blob 239982ef… file1.txt

При этом Git хранит только содержимое файла. Если несколько файлов имеют одинаковое содержимое (т.е. одинаковый хэш), реально храниться в репозитории содержимое будет только один раз в объекте blob с этим хэшем, но несколько объектов tree будут ссылаться этот объект blob и хранить разные имена этих файлов. Например, посмотрим содержимое папки folder1:

git cat-file 3ee7d56 -p
100644 blob 361ad437… README.md
100644 blob 239982ef… samefile1.txt

Здесь два файла file1.txt и samefile1.txt имеют одинаковое содержимое, поэтому хранятся, как один blob объект с хэшем 239982ef…. Имена файлов хранятся в объектах tree be4d42cd (корень) и 3ee7d56 (папка folder1).

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

Источник: https://app.pluralsight.com/library/courses/how-git-works

День семьсот двадцать седьмой. #ЗаметкиНаПолях
Как Работает Git. Продолжение
Начало

Версии
Посмотрим, что же из себя представляют версии. Любой коммит, кроме первого, помимо ссылки на tree (хэша) содержит ссылку parent – предыдущий коммит.

git cat-file 25087999 -p
tree 6ee02ade…
parent 1177e235…
author S. Benzenko <…> 1606107663 +0300
committer S. Benzenko <…> 1606107663 +0300
Second commit

Новый коммит хранит ссылку на предыдущий (1177e23), а также ссылку на новый корень проекта (tree) - 6ee02ade (см. рисунок ниже). Однако, если посмотреть, что хранит новый корень, то там будут ссылки на изменённые в этом коммите файлы, а также ссылка на объект tree из предыдущего коммита, поскольку эти объекты не менялись. Таким образом, каждый коммит содержит только изменения относительно предыдущего. А если вы храните огромный файл, и меняете в нём лишь небольшую часть, Git может выполнить несколько оптимизаций, чтобы не хранить этот большой файл дважды. Вы можете посмотреть размер репозитория с помощью команды git count-objects.

Посмотрим на упрощённую объектную модель Git (см. рисунок ниже). Итак, у нас есть структура, в которой одни объекты содержат данные (blob) – аналоги файлов в файловой системе, другие объекты (tree) – аналоги папок – содержат ссылки на объекты blob и tree. Получается древовидная структура, причём имена объектов blob и tree не хранятся в самих объектах. Вместо этого они хранятся в содержащем их объекте tree. Таким образом, у вас может быть один и тот же объект blob или tree, на который указывают разные объекты tree, хранящие разные имена. Это очень похоже на файловую систему. Ну и поверх этого наложены объекты commit, позволяющие управлять версиями.

В нашем проекте есть файл file1.txt и папка folder1 с файлами samefile1.txt и README.md. Файлы file1.txt и samefile1.txt имеют одинаковое содержимое. В файловой системе file1.txt находится в корне, а samefile1.txt находится в папке folder1. Однако в Git оба файла ссылаются на один объект blob с хэшем 2399.

Во втором коммите 2508 изменилось только содержимое файла file1.txt. Поэтому новый корень 6ee0 ссылается на новый объект blob - f1fe. Другие файлы не менялись, поэтому корни обоих коммитов ссылаются на один и тот же объект tree (3ee7), представляющий собой папку folder1. Таким образом текущая версия файлов получается простым проходом по ссылкам из коммита. Из коммита 2508 можно «найти» только изменившуюся версию файла file1.txt (f1fe), но нельзя «дойти» до версии 2399 (на неё ссылается только файл samefile1.txt). Аналогично из коммита 1177 нельзя получить доступ к изменённой версии file1.txt. Однако все объекты внутри папки folder1 доступны из обоих коммитов, поскольку они не изменялись.

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

Источник: https://app.pluralsight.com/library/courses/how-git-works

День семьсот двадцать восьмой. #ЗаметкиНаПолях
Как Работает Git. Продолжение
Начало
Версии

Ветки
Мы еще не создавали веток, но одна у нас уже есть. Это ветка master (main в последних версиях Git). Список веток можно посмотреть с помощью команды git branch:

* main

Обычно ветки размещаются в каталоге .git/refs/heads, и действительно, мы видим там файл main с SHA-1 хэшем, который соответствует последнему коммиту в ветке. То есть ветка – это просто ссылка на коммит. Если у нас несколько веток, все они будут размещены здесь в виде файлов со ссылками. Какая ветка является текущей? Это определяется в файле .git/HEAD:

ref: refs/heads/main

То есть HEAD – это просто ссылка на текущую ветку. Когда мы делаем коммит, файл refs/heads/main меняется и получает ссылку на новый коммит. Когда мы создаём новую ветку, например:

git branch new

или переключаемся на существующую ветку,
git checkout new
меняется файл HEAD, он получает ссылку на новую ветку, например, refs/heads/new.

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

После смены ветки git branch выведет:

main
* new

Здесь звёздочка указывает на текущую ветку (на которую ссылается файл HEAD).

Что же происходит, когда мы сливаем ветки (git merge).
1. Создаётся новый коммит. Он будет отличаться тем, что у него будет два родительских коммита (2 записи parent, см. предыдущий пост).
2. Ссылка текущей ветки перемещается на новый коммит.
3. Ссылка ветки, которую мы слили с текущей, остаётся на её последнем коммите (см. рисунок ниже).
4. Обновляются файлы в рабочей папке.

Два главных вывода:
1. Не бойтесь обилия объектов tree и blob. Перемещаться по истории в Git довольно просто. Сосредоточьтесь на коммитах, и том как они связаны друг с другом, а Git сам разберётся с объектами репозитория.
2. На самом деле Git не заботится о вашей рабочей папке. При перемещении по истории Git просто заменяет содержимое рабочей папки данными из репозитория. Объекты в репозитории неизменяемы и постоянны, а файлы в вашей рабочей папке временны. Да, Git предупредит при возможной потере изменений в изменённых файлах (например, если попытаться выполнить git checkout), но не более того.

Отделённая голова
Помимо перехода на другую ветку, можно перейти и к любому доступному коммиту, например:

git checkout ecbebe660

Эта ситуация называется «отделённая голова» (detached head). Вы можете продолжить работу и добавлять коммиты, HEAD будет ссылаться на последний добавленный вами коммит (см. рисунок ниже). Однако, если вы решите перейти на одну из веток, больше ничто не будет ссылаться на коммиты, добавленные в режиме detached head, и рано или поздно они будут удалены сборщиком мусора (да, он тут тоже есть). Чтобы «спасти» их, просто нужно создать новую ветку. Этот приём используется в случаях, когда вы хотите попробовать какие-то изменения, но не уверены, нужно ли сохранять их в репозитории.

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

Источник: https://app.pluralsight.com/library/courses/how-git-works