День шестьсот шестьдесят пятый.
Экзамены Microsoft онлайн: чего ожидать и как подготовиться
Довольно много вопросов мне задавали по процедуре сдачи экзамена. Я сдавал экзамен онлайн под наблюдением. Также это можно сделать очно в центре тестирования, но сейчас не об этом.

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

1. Прочитайте описание и посмотрите видео в документации. Хотя некоторые требования могут показаться чрезмерными, на это есть веские причины. Главная цель экзаменаторов – обеспечить максимально равные условия для всех сдающих. Поэтому вы должны находиться в максимально изолированном помещении. Также необходимо обеспечить безопасность и целостность процесса сдачи там, где экзаменаторы не могут контролировать оборудование, запущенное на нём ПО, скорость интернета и т.п.

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

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

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

4. Потренируйтесь на бесплатном экзамене. Я уже писал ранее про экзамен AZ-900 и про то, что его можно сдать бесплатно, посетив вебинар. Кстати, вот сессия на русском 14-15 декабря.

Источник: https://techcommunity.microsoft.com/t5/microsoft-learn-blog/online-proctored-exams-what-to-expect-and-how-to-prepare/ba-p/1469424

День шестьсот шестьдесят шестой. #ЗаметкиНаПолях #CSharp9
Атрибуты для Свойств Записей в C# 9
Записи обеспечивают простое создание неизменяемых объектов, особенно при использовании первичного конструктора:

public record User(string Name, DateTime DOB);

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

{"User":"Jon Smith","DateOfBirth":"1970-01-01T00:00:00"}

Заметьте, что ключи не совпадают с именами свойств записи. Обычно это потребовало бы добавления к свойствам записи атрибута JsonPropertyAttribute. То есть в полной записи это выглядело бы так:

public record User {  
  [JsonProperty("User")]  
  public string Name{get;init;}  
  
  [JsonProperty("DateOfBirth")]  
  public DateTime DOB{get;init;}  
} 

При использовании первичного конструктора есть соблазн сделать аналогично:

public record User(
  [JsonProperty("User")]
  string Name,
  [JsonProperty("DateOfBirth")]
  DateTime DOB
);

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

Решение заключается в указании цели, к которой применяется атрибут. Как сказано в документации Microsoft:
Атрибуты могут быть применены к синтезированному автоматическому свойству или его вспомогательному полю, используя указатель цели атрибута property: или field: соответственно для атрибутов, синтаксически применяемых к соответствующему параметру записи.

В итоге мы получим следующую запись:

public record User(
  [property:JsonProperty("User")]
  string Name,
  [property:JsonProperty("DateOfBirth")]
  DateTime DOB
);

Теперь можно сериализовать нашу запись и получить желаемый результат:

var data = new User("Jon Smith",new DateTime(1970,1,1));  
var serializedData = JsonConvert.SerializeObject(data);  

// Вывод
{"User":"Jon Smith","DateOfBirth":"1970-01-01T00:00:00"}

Источник: https://www.c-sharpcorner.com/blogs/attributes-for-record-properties-in-c-sharp-9

День шестьсот шестьдесят седьмой. #ЧтоНовенького
Повышение продуктивности в Visual Studio
Сегодня расскажу вам о некоторых новых фишках в Visual Studio.

Улучшения инструментов
Начиная с .NET 5.0, анализаторы Roslyn включены в .NET SDK. Анализаторы Roslyn включены по умолчанию для проектов, предназначенных для .NET 5.0 или более поздних версий. Вы можете использовать свойства проекта для включения/отключения анализаторов .NET. Щёлкните правой кнопкой мыши на проекте в проводнике решения и выберите Properties (Свойства). Затем выберите вкладку Code Analysis (Анализ кода), где вы можете установить или снять флажок Enable .NET analyzers (Включить анализаторы .NET). См. картинку 1 ниже.

Ещё одна интересная особенность - встроенные подсказки имён параметров, а также типов неявно объявленных переменных, аргументов методов и параметров лямбда-выражений. Включить эту опцию можно в меню Tools > Options > Text Editor > C# > Advanced (Инструменты > Параметры > Текстовый редактор > C# > Дополнительно) и выбрать Display inline parameter name hints (Отображать подсказки имён параметров) и Display inline type hints (Отображать подсказки типов). Вы также можете использовать сочетание клавиш Ctrl+Alt для краткого показа подсказок. См. картинку 2 ниже.

Добавление аккаунта GitHub
Вы можете добавить аккаунт GitHub в Visual Studio наряду с аккаунтом Microsoft в диалоговом окне Account Settings (Настройки учетной записи) - File > Account Settings… (Файл > Настройки учетной записи…). Кроме того, его можно добавить, например, при создании нового репозитория Git. См. картинку 3 ниже. Зачем нужно глобальное добавление аккаунта Git в Visual Studio, пока не понятно. Возможно, в будущем будет добавлен какой-то функционал.

Источники:
- https://devblogs.microsoft.com/dotnet/whats-new-in-net-productivity/
- https://devblogs.microsoft.com/visualstudio/github-accounts-are-now-integrated-into-visual-studio-2019/

День шестьсот шестьдесят восьмой.
dotnet-outdated устарел

dotnet-outdated – довольно полезный инструмент командной строки для проверки устаревших зависимостей в вашем проекте. Но теперь он… устарел. Хотя это не проблема, просто нужно его заменить. Если он уже был у вас установлен, выполните:

dotnet tool uninstall --global dotnet-outdated

А для установки:

dotnet tool install --global dotnet-outdated-tool

Да, название изменилось, но инструмент остался прежним, и его по-прежнему можно вызвать через dotnet outdated из папки решения.

На картинке выше результат работы dotnet outdated на недавно созданном проекте. Заметьте, что разным цветом показаны обновления основной версии, и более младших. Надо будет обновиться. Что, кстати, можно сделать там же, вызвав инструмент с параметром -u.

Источник: https://www.hanselman.com/blog/your-dotnet-outdated-is-outdated-update-and-help-keep-your-net-projects-up-to-date

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

Помимо вопроса про (как это сейчас принято говорить) вознаграждение, можно задать и менее очевидные.

1. Чем конкретно вы будете заниматься?
*** тут должна быть шутка про то, что на собеседовании просят развернуть бинарное дерево, а потом на работе сделать кнопочку побольше ***
Хотя это и некоторое преувеличение, но стек технологий компании, перечисленный в вакансии, вовсе не значит, что лично вы будете этим заниматься.

2. Где конкретно вы будете работать? Это отдельный офис (чего всем желаю), коворкинг или полуподвальная комнатка без окон, под завязку набитая людьми?

3. С кем вы будете работать? Собеседовать вас могут милые, приятные люди, а вот непосредственные коллеги могут от них сильно отличаться. Конечно, узнать коллег по описанию или по первому впечатлению невозможно. Это как раз тот случай, когда оправдано уйти на испытательном сроке. Но не молча, а объяснив руководителю, в чём причина.

4. Переработки. Все мы (я надеюсь) занимаемся любимым делом не по принуждению. «Если нам перестанут платить за работу, мы готовы доплачивать, лишь бы программировать». Да, да, да, всё это понятно. Но постоянные переработки приводят к быстрому эмоциональному выгоранию. Вам оно надо?

5. Карьерный рост. Канонический вопрос, который задают кандидатам: «Кем вы видите себя через Х лет?» - может быть задан и в обратную сторону. Кем меня видит компания через Х лет? Возможны ли повышения? Как этого добиться? Как высоко можно подняться?

Ну и так далее обо всём, что для вас важно? Многозадачность (переброски с проекта на проект), командировки, возможность удалённой работы и т.п.

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

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

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

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

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

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

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

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

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

День шестьсот семьдесят первый. #DeveloperPath
Новости проекта «Путь Разработчика»
О проекте

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

1. Исходный код
Во-первых, и в главных, хочу обратить внимание, что исходный код проекта находится в GitHub https://github.com/sbzenenko/DeveloperPath

Изначально планировалось импортировать код прямо в проект в Azure DevOps, однако, как оказалось, при этом создаётся не ссылка на GitHub, а клон репозитория в Azure. Привязать исходный репозиторий на GitHub, видимо, нельзя. В принципе, это не страшно, я убрал раздел репозиториев из проекта, чтобы они не вводили в заблуждение. Настроить пайплайны, тесты и релизы всё равно можно будет, используя репозиторий на GitHub.

2. Проблемы с доступом
У некоторых возникли проблемы с доступом на проект https://dev.azure.com/sbenzenko/DeveloperPath/ (ошибка 401). Пока эту проблему решить не удаётся. Написал об этом в саппорт https://developercommunity.visualstudio.com/content/problem/1268521/some-invited-members-get-401-error.html. Там выложили несколько вариантов, что можно попробовать, но не похоже, что они помогают. Будем решать.

В любом случае, даже если у вас не получается присоединиться к проекту на Azure, вы можете:
- просматривать его в режиме только для чтения (проект открытый),
- клонировать репозиторий https://github.com/sbzenenko/DeveloperPath с GitHub, следить за изменениями и вносить свои через Pull requests,
- оставлять предложения и замечания в GitHub Issues https://github.com/sbzenenko/DeveloperPath/issues.

3. Что сделано за неделю
Я скопировал шаблон Clean Architecture, обновил его до .NET 5 и начал работу над сущностями домена https://dev.azure.com/sbenzenko/DeveloperPath/_workitems/edit/6/.

Решение собирается и запускается. Только для этого вам потребуется поставить Node.js (если у вас его нет), т.к. на данный момент клиентская часть там на Angular. В будущем она будет переписана на Blazor.

Описывать собственно структуру и работу шаблона можно очень долго. Вот здесь внизу есть полезные ссылки для изучения https://dev.azure.com/sbenzenko/DeveloperPath/_wiki/wikis/DeveloperPath.wiki/3/Architecture Извините, только на английском. Если кто найдёт русскоязычные источники, с удовольствием добавлю.

Несколько комментариев для тех, кто захочет запустить проект у себя. То, с чем столкнулся сам:
1) Для запуска потребуется Visual Studio 2019 (v16.8) с модулем разработки Node.js и .NET 5 SDK.
2) По умолчанию в проекте используется InMemory база. Это можно изменить, установив UseInMemoryDatabase в false в src/WebUI/appsettings.json
3) Если кто-то захочет перейти на реальную базу, имейте в виду, что миграции и изменения в базу нужно запускать из проекта src/Infrastructure/, указывая при этом стартовый проект /WebUI/:

dotnet ef --startup-project ..\WebUI\ migrations add <NAME>
dotnet ef --startup-project ..\WebUI\ database update
Не знаю, зачем сделано так, если кто знает, подскажите.
4) Клиентская часть пока работает только с сущностями из шаблона (TodoItems и TodoLists). На их основе создаются сущности проекта. Сущности проекта можно посмотреть в Swagger https://localhost:5001/api/ Он их генерирует автоматически по созданным контроллерам и моделям. С ним у меня мало опыта работы. Знаю, что он позволяет документировать и тестировать API, автоматически выводит комментарии к конечным точкам и параметрам. Немножко его поковырял и добавил некоторые комментарии. По мере разработки буду изучать и описывать на канале.
5) На сайте есть шаблон Identity. Данные для входа находятся в файле src/Infrastructure/ApplicationDbContextSeed.cs

Если у кого-то возникнут вопросы, пишите в чат или в личку.

День шестьсот семьдесят второй. #ЗаметкиНаПолях
Ваш API и Модели Представления не Должны Использовать Модели Домена
Вы должны быть осторожны с тем, что вы раскрываете в своих клиентских моделях. Модели, предоставляемые клиенту, обычно находятся на уровне пользовательского интерфейса как ViewModels или ApiModels. Их также можно назвать DTO (Domain Transfer Objects - Объекты Передачи Данных). В любом случае они не должны напрямую ссылаться на типы из модели предметной области.

Чтобы понять, почему, давайте посмотрим, почему мы вообще используем DTO и ViewModels/ApiModels. Зачем несколько типов для описания того, что в системе, скорее всего, представляет одно и то же? Допустим, у меня есть веб-сайт, где пользователи могут проходить тесты. У каждого теста есть название, описание и набор вопросов. Моя модель предметной области для теста включает в себя некоторую бизнес-логику чтобы удостовериться, что в тесте есть хотя бы один вопрос, вопросы не повторяются и т.п.

Мне нужно, чтобы администратор мог добавить новый тест или обновить существующий. Я не хочу предоставлять доступ ко всем свойствам теста. Например, чтобы тест можно было создать с любым названием. А у созданного теста нельзя было изменить название, но можно менять описание или вопросы. Я создам типы ViewModel или ApiModel для конкретной операции, которую выполняет пользователь. Для создания теста может использоваться такой класс:

public class CreateTestViewModel {
  public string Name {get;set;}
  public string Description {get;set;}
}



А реальная сущность домена для теста могла бы выглядеть так:

// BaseEntity<T> определяет тип поля Id
public class Test : BaseEntity<Guid> {
  public string Name { get; set; }
  public string Description { get; set; }
  public ApplicationUser Author { get; set; }
  public List<Exercise> Exercises { get; set; }
}



Если бы вместо CreateTestViewModel использовался тип Test, конечные пользователи потенциально могли бы получить доступ к полному состоянию объекта Test. Привязка модели сопоставит все данные JSON или формы с данными модели. В документации к API может быть сказано, что должны передаваться только название и описание, но злоумышленник может угадать другие свойства сущности домена и изменять их, передавая значения. Если серверный код написан небрежно, он молча примет всё, что отправляет пользователь, и сохранит данные в хранилище с помощью простых команд EF, таких как Add() и SaveChanges().

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

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

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

public class TestDTO {
  //…
  public List<Exercise> Exercises { get; set; }
}



Убедитесь, что типы свойств сами являются DTO. Следите за тем, чтобы пространство имён домена не использовалось в определениях классов DTO. Можно следить за этим вручную или создать правило в таком инструменте, как NDepend.

Источник: https://www.c-sharpcorner.com/blogs/attributes-for-record-properties-in-c-sharp-9

День шестьсот семьдесят третий. #ЧтоНовенького
Microsoft Запускает Сервис Q&A для .NET

Microsoft Q&A для .NET - это сервис для технических вопросов и ответов о продуктах Microsoft. Здесь вы найдёте широкий спектр тем по .NET, включая рантайм, разработку настольных и веб приложений, вопросы по языкам, данным и многое другое.

Задавайте вопросы, следите за темами или выберите вопрос, на который вы знаете ответ. Ваш профиль Microsoft Q&A связан с вашей учетной записью в Microsoft Learn, и вы можете получать очки репутации, проявляя активность (см. картинку выше).

Существует множество форумов по темам .NET, включая MSDN, ASP.NET, IIS.NET и Xamarin. Со временем все они будут полностью перенесены на платформу Microsoft Q&A. На каждом из форумов будет вывешено отдельное уведомление о том, когда он будет перенесён.

Источник: https://devblogs.microsoft.com/dotnet/announcing-microsoft-q-and-a-for-dotnet/

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

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

Вот пример из реальной жизни: я чистил один устаревший код и наткнулся на «интересный» метод. Он был разработан для проверки того, что строка содержит допустимое время, используя формат hh:mm:ss xx, где xx – AM или PM. В методе использовался следующий код для преобразования двух символов (представляющих час) в число и проверки его соответствия допустимому диапазону:

try {
  int.Parse(time.Substring(0,2));
}
catch (Exception x) {
  return false;
}
if (int.Parse(time.Substring(0,2)) > 12) {
  return false;
}

Далее тот же самый код встречался ещё дважды с соответствующими сдвигами по строке, для проверки минут и секунд. А заканчивался метод следующим блоком для проверки AM и PM:

if (!time.Substring(9,2).Equals("AM") &
    !time.Substring(9,2).Equals("PM")) {
  return false;
}

Если ни одно из этих сравнений не завершилось неудачей и не вернуло false, метод возвращал true.

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

Когда я закончил, я был доволен результатами. Новая версия была удобной для чтения, вдвое короче и более точной.

Когда я готовился к работе на следующий день, мне в голову пришла идея: почему бы не проверить строку с помощью регулярного выражения? Через пару минут у меня была рабочая реализация всего в одной строке кода:

public static bool ValidateTime(string time) {
  return new Regex(
    "(0[1-9]|1[0-2]):[0-5][0-9]:[0-5][0-9] ([AP]M)")
    .IsMatch(time);
}

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

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

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

День шестьсот семьдесят пятый. #ЗаметкиНаПолях
Давненько я вам не рекомендовал видео. Примерно неделю назад команда DotNext выложила в открытый доступ доклады с конференции в Питере, проходившей в июне этого года. Сегодня хочу вам предложить одно из выступлений. Джон Скит (автор знаменитой книги «C# in Depth») «Dates and times: Hard, but not impossible» (Дата и время: трудно, но не невозможно).

В основном он рассказывает о своём инструменте Noda Time, созданном для работы с датой и временем в .NET. Однако доклад будет полезен и тем, кто не собирается его использовать. Например, Джон рассказывает, почему в вашем коде не должно использоваться DateTime.Now.

Хорошие новости для англонеговорящих, на Хабре предоставлена расшифровка выступления на русском.

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

Кто такой сеньор?
Начало.

Замечание: Сразу оговорюсь, что многое из нижеследующего описывает «сферического сеньора в вакууме». И, наверное, часть из этих характеристик невозможно дать самому себе, их должны дать вам ваши коллеги.

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

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

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

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

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

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

Источник: https://dev.to/themarcba/what-is-a-senior-developer-really-59dg
Автор оригинала – Burk Hufnagel

День шестьсот семьдесят седьмой. #Оффтоп #КакСтатьСеньором
Кто такой сеньор? Окончание.
Начало

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

От начала до конца
Старший разработчик способен выполнить каждый шаг на пути создания программного обеспечения:
1. Проанализировать проблему
2. Понять проблему
3. Сформировать жизнеспособное решение проблемы
4. Реализовать решение
5. Проверить решение
6. Интегрировать решение
7. Развернуть решение

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

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

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

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

Источник: https://dev.to/themarcba/what-is-a-senior-developer-really-59dg
Автор оригинала – Burk Hufnagel

День шестьсот семьдесят девятый. #ЧтоНовенького
Повышаем Продуктивность в Visual Studio 2019 v16.9 Preview 2
Под новый год разработчики Visual Studio подкинули нам действительно важных новинок. Как мы раньше без всего этого жили? Вы только оцените:
1. Автодобавление пространств имён
При копировании и вставке типов в новый файл Visual Studio 2019 теперь будет автоматически добавлять в файл недостающие директивы using. Чтобы попробовать эту опцию, включите её в меню Tools > Options > Text Editor > C# > Advanced (Инструменты > Параметры > Текстовый Редактор > C# > Дополнительно). Затем выберите Add missing using directives on paste (Добавлять недостающие директивы using при вставке).

2. Автодобавление точки с запятой
IntelliSense теперь при автозаполнении нового объекта или вызова метода будет добавлять точку с запятой в конце.

3. Новая цветовая схема для записей
В меню Tools > Options > Environment > Fonts and Colors (Инструменты > Параметры > Среда > Шрифты и Цвета) можно найти раздел User Types – Records (Пользовательские Типы – Записи) и выбрать для них особую цветовую схему.

4. Избавление от символа discard
В C#9 символ _ (discard) в некоторых случаях сопоставления с образцом не требуется. Теперь появится специальная подсказка в меню Quick Actions and Refactorings (Быстрые Действия и Рефакторинг), советующая его удалить.

Источник: https://devblogs.microsoft.com/visualstudio/visual-studio-2019-v16-9-preview-2/

День шестьсот восьмидесятый. #ЧтоНовенького #CSharp9
Ещё Раз про Сопоставления с Образцом
Я уже писал об изменениях в сопоставлении с образцом в C#9. Здесь же хочу привести некое саммари всех изменений с примерами:

1. Шаблоны типа используются для сопоставления с типом. Если тип входных данных соответствует типу, указанному в шаблоне, совпадение считается успешным.

object checkType = new int();
var getType = checkType switch {
  string => "string",
  int => "int",
  _ => "obj"
};
Console.WriteLine(getType); 
// Вывод: int

2. Реляционные шаблоны позволяют сопоставить входные данные с константами, используя знаки >, < или = (a также >= или <=):

var person = new Person("John", 42);
var person2 = new Person("Jane", 8);
var ageInRange = person switch {
  //тип Person указан явно
  Person(_, < 18) => "меньше 18",
  //тип выводится компилятором
  (_, > 18) => "больше 18",
  (_, 18) => "18!"
};
Console.WriteLine(ageInRange);
// Вывод: больше 18

3. Комбинаторные шаблоны позволяют комбинировать несколько шаблонов в одной строке:

var person = new Person("John", 42);

- Конъюнктивные представляют собой логическое «и» двух подшаблонов:

var ageInRange = person switch {
  (_, < 18) => "меньше 18",
  ("John", _) and (_, > 18) => "Джону больше 18"
};
Console.WriteLine(ageInRange);
// Вывод: Джону больше 18

- Дизъюнктивные представляют собой логическое «или» двух подшаблонов:

var ageInRange = person switch {
  (_, < 18) => "меньше 18",
  (_, 18) or (_, > 18) => "18 или больше"
};
Console.WriteLine(ageInRange);
// Вывод: 18 или больше

- Отрицательные требуют несовпадения с заданным шаблоном:

var isJohn = person switch {
  not ("John", 42) => "не Джон!",
  _ => "Джон :)"
};
Console.WriteLine(isJohn);
// Вывод: Джон :)

4. В шаблонах допустимо использовать скобки:

public record IsNumber(bool IsValid, int Number);
var num = new IsNumber(true, 10);
var zeroToTen = num switch {  
  ((_, >= 0 and <= 5) or (_, > 5 and <= 9))
    or (_, 10) => "от 0 до 10",  
  _ => "больше 10"
};  
Console.WriteLine(zeroToTen);
// Вывод: от 0 до 10

Источник: https://www.c-sharpcorner.com/article/c-sharp-9-cheatsheet/

День шестьсот восемьдесят первый. #ЧтоНовенького
Критические Изменения в .NET5. Библиотека Базовых Классов (BCL)
В .NET5 внесено несколько критических изменений. Подавляющее большинство из них связано с редкими случаями использования или некорректным поведением в прошлом. Но некоторые могут застать разработчиков врасплох. В первой части этой серии, рассмотрим изменения в BCL.

1. Информация о версии .NET
Некоторые разработчики используют строковое представление версии, а не числовую форму. В случае .NET у разработчиков не было выбора. Отчасти из-за путаницы в нумерации приходилось полагаться на строковое представление, вроде «.NET Framework #.#» или «.NET Core #.#».
В .NET5 моникер представляет из себя просто «.NET #.#». Приложения и библиотеки, зависящие от определения версии среды выполнения, необходимо обновить.

2. Информация о версии ОС
Раньше Environment.OSVersion могла лгать. Вместо возврата фактической версии ОС могла возвращаться эмулируемая ОС на основе настроек режима совместимости Windows. Теперь будет возвращаться фактическая версия, что больше соответствует ожиданиям разработчиков.

3. Расположение файлов в однофайловых приложениях
Когда приложение собрано в один файл вместе с его зависимостями, поведение некоторых API рефлексии перестаёт быть очевидным. В .NET5 все зависимости загружаются прямо из памяти, то есть физического файла сборки не существует. Ниже представлены новые варианты поведения для связанных сборок:
Assembly.Location - возвращает пустую строку,
Assembly.CodeBase - выбрасывает исключение,
Assembly.GetFile(String) - выбрасывает исключение,
Environment.GetCommandLineArgs()[0] - возвращает имя исполняемого файла,
AppContext.BaseDirectory - возвращает каталог, в котором находится исполняемый файл.

4. Логи
Следующие параметры ConsoleLoggerOptions отмечены как устаревшие: DisableColors, IncludeScopes, TimestampFormat, UseUtcTimestamp, Format. Они заменяются одним из нескольких подклассов ConsoleFormatterOptions.

5. Сериализация через BinaryFormatter заблокирована
BinaryFormatter в .NET существует с самого начала. Предполагалось, что он будет быстрее и компактнее, чем SoapFormatter, основанный на XML. К сожалению, в нём есть ряд проблем, самая важная из которых - невозможность безопасного использования. В .NET 5 BinaryFormatter по умолчанию отключен в приложениях ASP.NET и выдает предупреждение компилятора в других платформах. Если вам нужно его использовать, можно включить его с помощью флага EnableUnsafeBinaryFormatterSerialization.

6. UTF-7 заблокирована
Этот формат уже запрещён многими стандартами, такими как HTML5, потому что легко вставить вредоносные строки в приложение, заставив часть приложения думать, что данные находятся в формате UTF-8, в то время как другие части будут обрабатывать данные как UTF-7. Если необходима обработка устаревших данных, UTF-7 можно включить с помощью флага EnableUnsafeUTF7Encoding.

7. Пакет Microsoft.DotNet.PlatformAbstractions устарел
Разработчикам настоятельно рекомендуется прекратить использование пакета Microsoft.DotNet.PlatformAbstractions для получения информации об операционной системе. Ниже показаны устаревшие методы и их альтернативы:

ApplicationEnvironment.ApplicationBasePath

=> AppContext.BaseDirectory


HashCodeCombiner

=> System.HashCode


RuntimeEnvironment.GetRuntimeIdentifier

=> RuntimeInformation.RuntimeIdentifier


RuntimeEnvironment.OperatingSystemPlatform

=> RuntimeInformation.IsOSPlatform(OSPlatform)


RuntimeEnvironment.RuntimeArchitecture

=> RuntimeInformation.ProcessArchitecture


RuntimeEnvironment.OperatingSystem

=> RuntimeInformation.OSDescription
RuntimeEnvironment.OperatingSystemVersion
=> RuntimeInformation.OSDescription
и Environment.OSVersion

Источник: https://www.infoq.com/news/2020/12/net-5-breaking-changes/

День шестьсот восемьдесят второй. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
69. Читайте код
Мы, программисты, - странные создания. Мы любим писать код. Но когда дело доходит до чтения кода, мы обычно стесняемся и уклоняемся от этого. В конце концов, писать код намного веселее, а читать код сложно, а иногда почти невозможно. Особенно сложно читать чужой код. Не обязательно потому, что этот код плохой, а потому, что они, вероятно, думают и решают проблемы иначе, чем вы. Но задумывались ли вы когда-нибудь о том, что чтение чужого кода может улучшить ваш собственный код?

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

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

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

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

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