.NET Разработчик

День шестьсот семидесятый. #Оффтоп #97Вещей 97 Вещей, Которые Должен Знать Каждый Программист 67. Профессиональный программист Самая важная черта профессионального программиста - это личная ответственность. Профессиональные программисты берут на себя ответственность за свою карьеру, свои предположения, обязательства по срокам, свои ошибки и своё мастерство. Профессиональный программист не перекладывает эту ответственность на других. Если вы профессионал, то вы несёте ответственность за свою карьеру. Вы несёте ответственность за чтение и обучение. Вы несёте ответственность за то, чтобы быть в курсе событий отрасли и технологий. Слишком многие программисты считают, что обучать их - это забота их работодателя. Извините, это абсолютно неверно. Вы думаете, врачи так себя ведут? Юристы так себя ведут? Нет, они повышают квалификацию в свободное время и за свои деньги. Они проводят большую часть своего нерабочего времени за чтением журналов и статей. Они идут в ногу со временем. И мы тоже должны. Отношения между вами и вашим работодателем чётко прописаны в вашем трудовом договоре. Вкратце: ваш работодатель обещает вам платить, а вы обещаете хорошо выполнять свою работу. Профессионалы берут на себя ответственность за код, который они пишут. Они не выпускают код, если не уверены, что он работает. Подумайте об этом минутку. Как вы можете считать себя профессионалом, если хотите выложить код, в котором не уверены? Профессиональные программисты ожидают, что QA ничего не найдёт, потому что они не выкладывают свой код, пока он не будет тщательно протестирован. Конечно, QA найдёт некоторые проблемы, потому что никто не идеален. Но, как профессионалы, мы должны быть уверены, что не оставим ничего для QA. Профессионалы - командные игроки. Они берут на себя ответственность за результат работы всей команды, а не только за свою работу. Они помогают друг другу, учат друг друга, учатся друг у друга и даже при необходимости прикрывают друг друга. Когда у одного из команды возникают проблемы, другие вмешиваются, зная, что однажды они будут нуждаться в помощи. Профессионалы не устраивают беспорядок. Они гордятся своим мастерством. Они сохраняют свой код чистым, хорошо структурированным и легко читаемым. Они следуют согласованным стандартам и передовой практике. Они никогда не торопятся. Представьте, что вы покинули своё тело и наблюдаете, как врач делает вам операцию на открытом сердце. У этого врача есть дедлайн (в прямом смысле). Он должен закончить, прежде чем аппарат искусственного кровообращения повредит слишком много ваших кровяных телец. Как вы хотите, чтобы он вёл себя? Вы же не хотите, чтобы он вел себя как типичный разработчик ПО, торопясь и создавая беспорядок? Вы же не хотите, чтобы он сказал: «Я к этому вернусь и исправлю попозже»? Вы ожидаете, что он не станет торопиться, а уверенно выберет тот подход, который ему кажется лучшим в данной ситуации, и будет строго ему следовать. Хотите беспорядка или профессионализма? Профессионалы несут ответственность. Они берут на себя ответственность за свою карьеру. Они берут на себя ответственность за правильную работу своего кода. Они берут на себя ответственность за качество своей работы. Они не отказываются от своих принципов, когда приближается дедлайн. Наоборот, когда давление нарастает, профессионалы ещё строже придерживаются правил, зная, что именно так будет правильно. Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/ Автор оригинала – Robert C. Martin

День шестьсот шестьдесят девятый. #Оффтоп IT собеседование. Как понять, что компания Вам не подходит? Продолжим разговоры по воскресеньям. В основу сегодняшней темы лёг очередной ролик от Сергея Немчинского. Я всегда говорю, что собеседование на то и собеседование, что задавать вопросы могут обе стороны. Как компания хочет что-то узнать о вас, так и вам лучше узнать побольше о месте, где вам предстоит работать. Просто чтобы не тратить ни своё время, ни время и деньги работодателя. Конечно, есть испытательный срок, и можно просто встать и уйти в любой момент, если что-то не устраивает. Но не делайте так. Лучше по максимуму исключить для себя неприятные сюрпризы ещё на стадии собеседования. Несколько вопросов, кстати, лучше подготовить заранее и ранжировать по важности лично для вас. От того, с чем вы категорически отказываетесь мириться до просто интересующих вас деталей. Помимо вопроса про (как это сейчас принято говорить) вознаграждение, можно задать и менее очевидные. 1. Чем конкретно вы будете заниматься? *** тут должна быть шутка про то, что на собеседовании просят развернуть бинарное дерево, а потом на работе сделать кнопочку побольше *** Хотя это и некоторое преувеличение, но стек технологий компании, перечисленный в вакансии, вовсе не значит, что лично вы будете этим заниматься. 2. Где конкретно вы будете работать? Это отдельный офис (чего всем желаю), коворкинг или полуподвальная комнатка без окон, под завязку набитая людьми? 3. С кем вы будете работать? Собеседовать вас могут милые, приятные люди, а вот непосредственные коллеги могут от них сильно отличаться. Конечно, узнать коллег по описанию или по первому впечатлению невозможно. Это как раз тот случай, когда оправдано уйти на испытательном сроке. Но не молча, а объяснив руководителю, в чём причина. 4. Переработки. Все мы (я надеюсь) занимаемся любимым делом не по принуждению. «Если нам перестанут платить за работу, мы готовы доплачивать, лишь бы программировать». Да, да, да, всё это понятно. Но постоянные переработки приводят к быстрому эмоциональному выгоранию. Вам оно надо? 5. Карьерный рост. Канонический вопрос, который задают кандидатам: «Кем вы видите себя через Х лет?» - может быть задан и в обратную сторону. Кем меня видит компания через Х лет? Возможны ли повышения? Как этого добиться? Как высоко можно подняться? Ну и так далее обо всём, что для вас важно? Многозадачность (переброски с проекта на проект), командировки, возможность удалённой работы и т.п. О чём вы спрашивали на собеседовании? Что для вас является наиболее важным критерием, таким, что вы готовы отказаться от места, если этого нет? От какой работы отказывались прямо на собеседовании? Кстати, там в комментариях к видео Сергея есть несколько интересных историй. Давайте обсудим. Жду ваших комментариев.

День шестьсот шестьдесят восьмой. 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

День шестьсот шестьдесят седьмой. #ЧтоНовенького Повышение продуктивности в 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/

День шестьсот шестьдесят шестой. #ЗаметкиНаПолях #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

День шестьсот шестьдесят пятый. Экзамены 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

День шестьсот шестьдесят четвёртый. #юмор Как раз в тему стартовавшего проекта.

День шестьсот шестьдесят третий. #DeveloperPath Проект «Путь Разработчика» Наконец-то! Я добрался до разработки проекта, обещанного ещё летом. Теперь официально объявляю о запуске! Периодически буду выпускать на канале новости проекта. Краткое описание идеи можно прочитать здесь. Поскольку стоит задача параллельно изучить Azure и всё, что с этим связано (борды, пайплайны, и т.п.), я решил попробовать вести проект в Azure DevOps. Поэтому все желающие, добро пожаловать! https://dev.azure.com/sbenzenko/DeveloperPath Проект открытый, посмотреть его могут все желающие, даже без авторизации. Авторизованные через аккаунт Microsoft или GitHub могут оставлять комментарии или добавиться в команду. Пока не знаю, как это делается, буду изучать по ходу))) Надеюсь, там для вас будет специальная кнопка. Если нет, пишите сюда, будем разбираться, как вас добавить. Описание проекта есть на главной странице. В разделе Boards я создал пока 3 задачи (они же обсуждения): - Description and UX/UI - описание того, что будет собой представлять сайт с точки зрения пользователя. - Domain design - создание сущностей домена. - Architecture design - разработка архитектуры. Советую для начала ознакомиться с описанием на главной и с описанием в Description and UX/UI, чтобы примерно представлять, что будем создавать. За основу взят шаблон «Clean Architecture» (ссылка на шаблон и ресурсы с информацией о нём в задаче Architecture design). В проект добавлен репозиторий, но в нём пока только «голый» шаблон и Readme с описанием проекта. В общем, как уже писал раньше, приглашаются все желающие: архитекторы, разработчики, тестировщики, дизайнеры… Все, кто хочет изучить что-то новое или внести вклад в развитие сообщества. Особого уровня подготовки и навыков не требуется (это всё-таки учебный проект, все будем учиться потихоньку). Единственное, желательно бы немного знать английский. Общаться будем на русском, но подавляющее большинство источников информации (об архитектуре, .NET5, Azure и т.п.) англоязычные. Жду вас на проекте! UPD: Добавиться в команду, судя по всему, можно только по приглашению. Пишите email, по которому авторизуетесь в комментарии или в личку, я вас добавлю.

День шестьсот шестьдесят второй. Сертификат Microsoft. Экзамен AZ-900 Сдал на досуге экзамен AZ-900. Потому что, почему бы и нет. Чтобы сдать бесплатно нужно посетить вебинар (очередной 1 и 2 декабря). Это основные основы Azure. На вебинаре говорили, что он якобы требуется для получения других сертификатов, но в требованиях на сертификаты разработчика AZ-204, AZ-304, AZ-400 его нет. Зачем сдавать? Просто узнать о сервисах и структуре Azure, что там, как и зачем. Ещё вариант для тех, кто ни разу не сдавал экзамен Microsoft, но собирается - бесплатно попробовать, как он проходит. Подготовиться можно - в Microsoft Learn довольно сжато и сухо. Без опыта использования просто прочитать будет недостаточно. Надо как минимум залезть в Azure и потыкать каждый из сервисов (многие из которых платные), - на Pluralsight есть сертификационный путь, где разбирают всё на примерах, - плейлист на Youtube, - или вот такая книжка.

День шестьсот шестьдесят первый. #ЗаметкиНаПолях Как разрешить загрузку исполняемых файлов .exe с помощью UseStaticFiles в ASP.NET Core Иногда требуется возвращать клиенту небезопасные файлы, вроде исполняемых .exe. ASP.NET Core по умолчанию очень сильно ограничен в целях безопасности, поэтому необходимо конкретно указывать, что разрешается возвращать. Простое включение в метод Configure() файла Startup.cs промежуточного ПО статических файлов:

app.UseStaticFiles();

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

private StaticFileOptions GetStaticFileOptions()
{
  var p = new FileExtensionContentTypeProvider();
  p.Mappings[".exe"] = "application/octet-stream";

  return new StaticFileOptions { 
      ContentTypeProvider = p 
    };
}

Затем её можно передать в UseStaticFiles:

app.UseStaticFiles(GetStaticFileOptions());

Ещё один вариант – разрешить возвращать файлы с незнакомым расширением, задав для неизвестных файлов mime-тип по умолчанию:

app.UseStaticFiles(new StaticFileOptions
{
  // разрешаем возвращать неизвестные типы файлов
  ServeUnknownFileTypes = true,
  // задаём mime-тип для неизвестных файлов
  DefaultContentType = "plain/text"
}

Источники: - https://www.hanselman.com/blog/how-to-allow-executable-exe-files-to-be-downloaded-with-aspnet-core-and-usestaticfiles-middleware - https://stackoverflow.com/questions/42831645/asp-net-core-download-exe-returns-404-error

День шестьсот шестидесятый. #ЧтоНовенького #EFCore5 Вместе с .NET 5 выпущено множество обновлений. Про новшества в C#9 я писал в постах с тегом #CSharp9. Теперь рассмотрим, что нового в Entity Framework Core 5.0. Отношение многие-ко-многим EF Core 5.0 поддерживает отношения многие-ко-многим без явной привязки вспомогательной таблицы. Рассмотрим следующие сущности постов в блоге и тегов:

public class Post {
  public int Id { get; set; }
  public string Name { get; set; }
  public ICollection<Tag> Tags { get; set; }
}
public class Tag {
  public int Id { get; set; }
  public string Text { get; set; }
  public ICollection<Post> Posts { get; set; }
}

Заметьте, что Post содержит коллекцию элементов Tag и наоборот. EF Core 5.0 по соглашению распознает это как отношение многие-ко-многим. То есть добавлять специальный код в OnModelCreating не требуется. Когда для создания базы данных используются миграции (или EnsureCreated), EF Core автоматически создаст вспомогательную таблицу. Например, в SQL Server для этой модели EF Core сгенерирует:

CREATE TABLE [Posts] (
  [Id] int NOT NULL IDENTITY,
  [Name] nvarchar(max) NULL,
  CONSTRAINT [PK_Posts] PRIMARY KEY ([Id])
);
CREATE TABLE [Tag] (
  [Id] int NOT NULL IDENTITY,
  [Text] nvarchar(max) NULL,
  CONSTRAINT [PK_Tag] PRIMARY KEY ([Id])
);
CREATE TABLE [PostTag] (
  [PostsId] int NOT NULL,
  [TagsId] int NOT NULL,
  …
);

Создание и связывание экземпляров объектов Tag и Post приведёт к автоматическому обновлению вспомогательной таблицы. После вставки сообщений и тегов EF автоматически создаст строки во вспомогательной таблице. Для запросов Include и другие операции будут работать так же, как и для любых других отношений. В отличие от EF6, EF Core также позволяет полностью настраивать вспомогательную таблицу. Например, приведенный ниже код настраивает отношение «многие-ко-многим» через вспомогательный объект, в котором вспомогательный объект также содержит свойство с полезными данными (PublicationDate):

protected override void OnModelCreating(ModelBuilder modelBuilder) {
  modelBuilder
    .Entity<Post>()
    .HasMany(p => p.Tags)
    .WithMany(p => p.Posts)
    .UsingEntity<PostTag>(
      j => j
       .HasOne(pt => pt.Tag)
       .WithMany()
       .HasForeignKey(pt => pt.TagId),
      j => j
       .HasOne(pt => pt.Post)
       .WithMany()
       .HasForeignKey(pt => pt.PostId),
      j => {
        j.Property(pt => pt.PublicationDate)
         .HasDefaultValueSql("CURRENT_TIMESTAMP");
      j.HasKey(t => new { t.PostId, t.TagId });
  });
}

Источник: https://docs.microsoft.com/ru-ru/ef/core/what-is-new/ef-core-5.0/whatsnew#many-to-many

День шестьсот пятьдесят девятый. #юмор Прекрасна ведь?)))

День шестьсот пятьдесят восьмой. #ЗаметкиНаПолях Вернемся к основам C#: Разница Между => и {get;} = для Свойств Судя по примерам кода, которые я встречал несколько раз, оказывается, не все понимают разницу между => и { get; } = для свойств. Вот пример кода:

public class C
{
  public Foo A { get; } = new Foo();
  public Foo B => new Foo();
}

Это одно и то же или нет? Ответ: нет, это не одно и то же. A - это свойство только с аксессором get (также известное как свойство только для чтения или неизменяемое свойство). Когда создаётся экземпляр класса C, это свойство инициализируется новым экземпляром класса Foo, ссылка на который будет возвращаться с этого момента при обращении к свойству A. Свойство B также определяет только аксессор, но на этот раз аксессор get содержит new Foo(); в теле. Иначе говоря, свойство B возвращает новый экземпляр Foo каждый раз, когда вы обращаетесь к нему. В ранних версиях C# это выглядело бы так:

public class C
{
  readonly Foo _a = new Foo();
  
  public Foo A
  {
    get { return _a; }
  }

  public Foo B
  {
    get { return new Foo(); }
  }
}

Источник: https://www.tabsoverspaces.com/233844-back-to-csharp-basics-difference-between-and-get-for-properties

День шестьсот пятьдесят седьмой. #ЧтоНовенького Новый Опыт Работы с Git в Visual Studio Git стал встроенной системой контроля версий в Visual Studio 2019, начиная с версии 16.8. Вот некоторые нововведения, которые помогут упростить работу с Git в Visual Studio. Создание репозитория Чтобы начать работу с Git, Visual Studio позволяет вам одним щелчком мыши добавить локальный код в Git и GitHub. Диалоговое окно «Создание репозитория Git» (см. картинку 1 ниже) содержит новый интегрированный процесс входа в GitHub, аналогичный тому, что существует для учётных записей Microsoft. Вы можете сделать репозиторий общедоступным или приватным. Также вы можете создать локальный репозиторий или отправить свой код в существующий удаленный репозиторий в Azure DevOps или у любого другого поставщика. Меню Git верхнего уровня Теперь вы можете получить доступ к функциям Git, используя меню Git верхнего уровня, либо по Alt+G. Здесь также есть подменю Локальные репозитории (Local Repositories), с помощью которого вы можете легко переключаться между локальными репозиториями Git, которые вы ранее открывали в Visual Studio. Просмотр файлов в Проводнике Решения После того, как вы открыли или клонировали репозиторий, Visual Studio поможет вам сразу перейти к вашему коду. Проводник решения загружает корень репозитория и просматривает каталог на наличие нужных файлов. Visual Studio автоматически найдёт и загрузит решение из файла .sln. Если файлов .sln несколько, вам будет предложен список доступных решений на выбор. Впоследствии вы можете переключаться между текущим открытым решением и списком решений с помощью кнопки «Переключить представление» (Switch Views) на панели инструментов проводника решений (см. картинку 2 ниже). Оптимизировано окно Git Changes Новое окно Git Changes предназначено для обеспечения быстрого доступа к часто используемым операциям Git. Вы можете создавать новые ветки, выполнять stash, stage, вносить правки и фиксировать изменения в одном месте, не теряя контекста. В верхней части окна кнопки fetch, pull и push позволяют синхронизировать коммиты и теги с удалёнными репозиториями. В окне Git Changes также есть индикатор, отображающий количество исходящих и входящих коммитов. Он работает как ссылка для перехода в окно репозитория Git. Оттуда вы можете просмотреть сводку исходящих и входящих коммитов перед синхронизацией (см. картинку 3 ниже). Окно репозитория Git Окно репозитория Git позволяет легко визуализировать всю историю вашего репозитория. Вы можете щёлкнуть правой кнопкой мыши по ветке, чтобы выполнить различные операции над ревизиями (см. картинку 4 ниже). Улучшено разрешение конфликтов В окне Git Changes перечислены неподтверждённые или неслитые изменения. Золотистая панель в конфликтующем файле предлагает вам открыть Редактор Слияния (Merge Editor). Три панели редактора помогут вам визуально разрешить каждый конфликт в файле. Вы также можете принять локальные или входящие изменения одним щелчком мыши (см. картинку 5 ниже). Источник: https://devblogs.microsoft.com/visualstudio/announcing-the-release-of-the-git-experience-in-visual-studio/

День шестьсот пятьдесят шестой. #Оффтоп #97Вещей 97 Вещей, Которые Должен Знать Каждый Программист 66. Архитектура не Завершена без Документации Создание хорошей архитектуры - только половина дела. Необходимо описать её для всех, кто будет её использовать: инженерам, тестировщикам, владельцам продукта, аналитикам и менеджерам. Стоит потратить время на чёткое документирование архитектуры, так как это может упростить разработку. Документация даёт всем понимание, как будет работать система, определяет общий язык, упрощает обучение новичков. Но как должна выглядеть документация, как сделать её полезной и избежать превращения документирования в обузу? 1. Ориентируйтесь на аудиторию, а не на методологию Основной целью документации является обмен информацией, а значит любая документация должна быть написана для целевой аудитории – её читателей. Представлений архитектуры очень много: от неформальных прямоугольников и стрелок до UML или Archimate. Правильный формат может оказаться сложной задачей, особенно если вы ориентируетесь на нетехническую аудиторию. 2. Учитывайте разные взгляды Вы вряд ли найдёте универсальный подход к документации. Разным аудиториям потребуются разные взгляды на архитектуру. План архитектуры для разработчиков будет отличаться от более абстрактного представления для менеджеров. Это хорошо. Предоставление описаний одной и той же архитектуры с разных сторон может стать проверкой прочности вашего дизайна. 3. Определите общий язык Каждая система содержит свои абстракции, шаблоны и термины. Этот общий язык должен быть где-то чётко определён, иначе каждая аудитория начнёт придумывать свои противоречащие остальным определения. 4. Краткость – сестра таланта Способность выражать сложные проекты в простой и доступной форме чрезвычайно важна. Длинные сложные документы могут быть пугающими и содержать неактуальный материал, затрудняющий понимание. Стремитесь к тому, чтобы документации было ровно столько, сколько нужно. Если вы не можете описать систему ясно и кратко, вы либо слишком усложняете решение, либо не понимаете его полностью. Отбрасывайте несущественные детали. Архитектурная документация должна объяснять основные концепции и шаблоны, лежащие в основе проекта, а не представлять собой сборник деталей реализации. 5. Схемы переоценены Во многих случаях документальное оформление проекта приносит пользу архитектору больше, чем кому-либо. Схема - это возможность систематизировать свои мысли, разобраться в решении и научиться ясно его описывать. Просто имейте в виду, что не каждый сможет понять сложную схему. Стремитесь поддерживать согласованный уровень абстракции, контролировать сложность, определять чёткую область видимости и следить за тем, чтобы всё было последовательно помечено. 6. Создайте централизованный репозиторий Архитектурная документация должна быть легко доступной для широкой аудитории. Подойдет простая вики, желательно с возможностью поиска, управлением версиями и комментариями. Также кто-то должен взять на себя ответственность за организацию структуры, удаление оставленных черновиков и обновление контента. Неформальные договорённости о поддержке актуальности документации обычно приводят к хаосу. 7. Стремитесь к независимой оценке документации Документация также допускает обзоры, как и код. Рецензирование должно быть совместным процессом. Есть соблазн держать идеи при себе, пока вы не доведёте их до ума. Но чтобы по-настоящему оценить их состоятельность, требуется немного смелости. Нужно опубликовать черновики и ждать отзывов. Это поможет привлечь людей, а также упростит изменение курса разработки, если это необходимо. Источник: https://www.ben-morris.com/architecture-without-documentation-is-incomplete/

День шестьсот пятьдесят пятый. #ЗаметкиНаПолях Жизненный цикл запроса в ASP.NET Core MVC 3. Окончание Начало Промежуточное ПО Маршрутизация Инициализация контроллера Выполнение метода действия Выполнение результата действия и Отображение представления Результаты действий отвечают за отображение результата метода действия в ответ, отправляемый клиенту. Результаты действий реализуют интерфейс IActionResult, который определяет метод ExecuteResultAsync, принимающий контекст действия (ActionContext). Этот метод реализуется различными типами результатов действий для отображения различных типов ответов. Допустим, у нас есть метод действия, отвечающий за отправку сообщения «Hello world» клиенту. Метод действия может представить результат по-разному, например: - ContentResult выведет просто строку "Hello world", - JsonResult выведет JSON {result: "Hello world"}, - ViewResult выведет HTML страницу с разметкой из соответствующего представления, - FileResult выведет файл. Выбрать тип результата можно с помощью вспомогательных методов контроллера, например: - return View("Hello world") для ViewResult, - return Content("Hello world") для ContentResult, и т.п. Отображение представления Отображение представлений в MVC управляется механизмом представлений Razor (View Engine), который отвечает за поиск и отрисовку представлений, выбранных методами действий. Существует три основных класса управляющих этим процессом: 1. View Engine - управляет процессом поиска представления. Класс реализует IViewEngine, определяющий два метода: GetView и FindView. GetView вызывается первым и пытается найти представление, используя его имя прямой путь к нему. Если представление не найдено, вызывается метод FindView, который использует дополнительную информацию из контекста метода действия. 2. View Engine Result - содержит свойства, представляющие результаты поиска представления: - IEnumerable<string> SearchedLocations – места, где производился поиск, - bool Success – успешность поиска, - IView View – экземпляр найденного представления, - string ViewName – имя представления. Соответствующие свойства заполняются двумя методами класса: - Found() – вызывается при обнаружении представления, - NotFound() – если представление не найдено. 3. View - фактически отображает разметку Razor и HTML, а также любые данные, предоставленные методом действия. Класс реализует IView, определяющий свойство Path (путь к представлению) и метод визуализации представления RenderAsync. RenderAsync используется MVC для фактического создания ответа, который отправляется клиенту. Разметка Razor и код HTML конвертируются в класс C#, содержащий метод ExecuteAsync (о нём ниже). Процесс визуализации представления в MVC начинается с вызова вспомогательного метода представления в методе действия контроллера (см. рисунок ниже). За кулисами этот метод генерирует экземпляр ViewResult, который будет выполнен инициатором ресурсов, как и любой другой результат действия. ViewResult просит у механизма представлений Razor найти представление. Механизм возвращает экземпляр класса View Engine Result. Если представление было найдено, экземпляр содержит обнаруженное представление. В противном случае предоставляется список мест, где осуществлялся поиск. Если представление было найдено, вызывается метод ExecuteAsync класса View для отображения ответа на запрос. Источник: https://app.pluralsight.com/library/courses/aspnet-core-3-mvc-request-life-cycle/

День шестьсот пятьдесят четвёртый. #Оффтоп Отвлечёмся ненадолго от жизненного цикла запроса в ASP.NET Core. Вчера в нашем чате завязалась дискуссия про базы данных, прелести и недостатки SQL и хранимых процедур. Вот решил вам на выходные дать задачку из собственной практики. Можно рассматривать её как из цикла #ЗадачиНаСобеседовании. Допустим, у нас есть интернет-магазин (или любой аналогичный каталог товаров и их производителей/поставщиков, скажем, Алиэкспресс). Количество товаров очень большое. Пользователь ищет товар по названию или по категории, и ему выдаётся некоторый набор товаров с их характеристиками и производителем/поставщиком. Предположим для простоты, что из-за большого количества товаров, вся информация в рамках одного поискового запроса собирается в хранимой процедуре и кэшируется во временную таблицу в БД. То есть, если пользователь изменил сортировку или фильтры в текущем поиске, нам не нужно каждый раз извлекать данные из нескольких таблиц, все они уже кэшированы. Пользователю нужно выдать только определённое количество результатов (разбив на страницы или просто выдавать только ТопХХХ). Пользователь может сортировать результаты (по цене, релевантности, рейтингу и т.п.), применять фильтры или переходить по страницам. Все эти запросы в рамках одного поискового запроса идут к временной таблице, которая создана ранее. Теперь собственно задача. Производители хотят знать, сколько раз, по каким поисковым запросам и с какими товарами они появлялись на страницах сайта. То есть, если был запрос на «смартфон», который вернул 20000 результатов во временную таблицу, пользователю из них показали 1000 на первой странице и 1000 на второй, а дальше он смотреть не стал. Нам нужно сохранить для статистики данные только тех производителей, которые реально были показаны пользователю (попали в 2000 из 20000). (Да, я специально взял большие числа, а не стандартные 10 на страницу, потому что с 10 товарами решение вполне очевидно и не затратно). Вопрос: как вы это реализуете? Оцените преимущества и недостатки каждого варианта. Поскольку я сам с этим столкнулся, мне будет очень интересно узнать ваши версии в комментариях. Как такового правильного ответа тут, наверное, нет. Жду ваших комментариев. Свою реализацию тоже опишу в комментариях позже.