День 1234. #ЧтоНовенького
Новый Профилировщик Ввода-Вывода в Visual Studio
В Visual Studio 17.2 появился новый профилировщик, который поможет вам понять, как оптимизировать операции файлового ввода-вывода для повышения производительности ваших приложений. Если вы пытаетесь исследовать и диагностировать медленное время загрузки, новый инструмент File IO может помочь понять, на какие операции ввода-вывода тратится много времени.

- Нажмите Alt+F2, чтобы открыть профилировщик производительности в Visual Studio.
- Установите флажок рядом с инструментом File IO и любыми другими инструментами, которые могут вам понадобиться.
- Нажмите Start, чтобы запустить профилирование.

После запуска выполните сценарий, который вы хотите профилировать в своём приложении. Затем нажмите «Stop collection» или закройте приложение, чтобы увидеть результаты.

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

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

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

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

Источник: https://devblogs.microsoft.com/visualstudio/new-profiler-feature-in-visual-studio/

День 1235. #ЗаметкиНаПолях
Создание Объектов без Вызова Конструктора
Вам когда-нибудь требовались результаты экземплярного метода, когда у вас не было необходимых зависимостей для создания экземпляра объекта? Если вы ответили «да», то начнём с того, что вы странный человек. По-хорошему странный, но всё же странный. Несмотря на это, решение есть. Рассмотрим малоизвестную функцию служб компилятора .NET, которая позволит вам создать «неинициализированный» экземпляр объекта без вызова каких-либо его конструкторов или инициализаторов свойств.

Во-первых, вам нужно будет сослаться на пространство имён System.Runtime.CompilerServices. Оно содержит класс RuntimeHelpers со статическим методом GetUnitializedObject. Посмотрим, как это работает на практике.

using System;
using System.Runtime.CompilerServices;

var o = RuntimeHelpers
  .GetUninitializedObject(typeof(Something));

if (o is Something smth)
{
  Console.WriteLine(smth.GetName());
  Console.WriteLine(smth.Name ?? "(null)");
}

public class Something
{
  public string? Name { get; } = "John";

  public Something(string? name)
  {
    this.Name = name;
  }

  public string GetName() => Name ?? "Jane";
}

Этот код, как и ожидается, выведет:

Jane
(null)

В приведённом выше примере создаётся экземпляр Something без вызова конструктора объекта. Инициализатор свойства также не вызывается, поэтому свойство Name по-прежнему имеет значение null. Однако, возможно вызвать как метод GetName, так и обратиться к свойству Name.

Что это значит?
Этот подход открывает возможность для разработчиков фреймворков использовать наследование и реализацию интерфейса для настройки элементов во фреймворке. Например, он используется в Fast Endpoints, который позволяет создавать конечные точки веб-сайтов или API в виде классов, а не методов контроллеров. Для внедрения зависимостей в класс конечной точки, создаётся неинициализированный экземпляр класса, а затем вызывается общий метод Configure, который обнаруживает необходимые зависимости и внедряет их.

Тем не менее, этот подход может привести к ошибкам, которые может быть трудно диагностировать. Например, приведённый выше код класса инициализирует свойство Name, но эта инициализация никогда не происходит, что приводит к результату (null) на выходе.

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

Источник: https://khalidabuhakmeh.com/create-dotnet-objects-without-calling-the-constructor

День 1236. #Юмор #СписокШуток
Большой Список Бородатых Программистских Шуток - 2
Часть 1

Самые большие сторонники того, что «компьютеры не заменят людей», — каннибалы.

Программист, не комментирующий код – это как водитель, не использующий поворотники.

У вас не будет ошибок времени выполнения, если ваш код не компилируется.

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

Так, если я пишу исключительный код, это хорошо или плохо?

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

git commit -m "точка сохранения, пока я всё нахер не испортил"

Зачем быть альфа-самцом, если можно быть самцом-"стабильным релизом"?

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

«Ложись спать, утро вечера мудренее» — это человеческий эквивалент «Попробуйте выключить и снова включить».

Сломайте продакшен с утра, и до конца дня хуже уже ничего не случится.

Писать код в блокноте – это как заниматься йогой на входном коврике.

Хороший программист смотрит в обе стороны, прежде чем перейти улицу с односторонним движением.

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

Из-за ковида все приложения TCP были переделаны на UDP, чтобы избежать рукопожатий.

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

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

Никто не лжёт больше, чем разработчики ПО, когда они говорят: «Да, это легко исправить».

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

Просить разработчика ПО исправить вашу аппаратную проблему — всё равно, что просить Тома Круза починить ваш телевизор.

Люк, переходи на тёмную сторону, у нас лучше темы для IDE.

Как вывести из себя разработчика ПО, рассказав о проблеме?
«Уже не важно, я сам разобрался.»

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

Чак Норрис не использует отладчик.
Он просто смотрит на код, пока код не признается, где ошибка.

Учителя старших классов: в реальном мире нельзя просто загуглить всё на свете для выполнения работы.
Программисты: 😂😂😂

Босс: ты опять опоздал
Я: трафик
Босс: но ты работаешь из дома
Я: сетевой трафик

Клиент: а вы могли бы вы внести некоторые изменения?
Разработчик: нет, я написал это в перманентном коде.

Что говорю я: я инженер-программист.
Что слышат родственники: я могу починить интернет, настроить принтер, починить ваш iPhone, создать приложение на миллиард долларов и взломать что угодно. Всё бесплатно.

Родственник: Я слышал, ты хорошо разбираешься в компьютерах.
Я с дипломом инженера-программиста: Нет.

Мама: сможешь починить мой компьютер?
Я: *откидываясь на кресле* так, так, так. Кто это у нас тут? Обладательница титула Миссис «Отлепись от компьютера, сходи погуляй» с 2004 по 2013 годы…

- О, ты программист? Значит, у тебя должна быть дорогая механическая клавиатура и 3 монитора, верно?
- Вы только что оскорбили всех программистов мира… но да.

Законы программирования:
1. Ошибка всегда будет в последнем месте, которое вы проверите.
2. Место с ошибкой всегда будет первым, куда зайдёт пользователь.
3. Чем сложнее найти ошибку, тем легче её исправить — и наоборот.
4. Нет ничего более постоянного, чем временный костыль.
5. Не все замечают ошибки, которые вы исправляете, но все замечают ошибки, которые вы создаёте.

Шаги отладки:
1. Выполнить код
2. Внести небольшое изменение
3. Принести кровавую жертву богам кода
4. Выполнить код
5. Повторить

9 стадий отладки:
🤔😕😫🤔🤬😲🤦‍♂️😅😎

Источник: https://carlanotarobot.iss.onedium.com/ultimate-list-of-programmer-jokes-puns-and-other-funnies-75264f29baa3

День 1237. #ЗаметкиНаПолях #DDD
Сущности и Объекты-Значения: Полный Список Различий. Начало
Тема не новая, тем не менее, здесь все различия сведены вместе.

1. Типы равенства
Для начала рассмотрим 3 типа равенства, которые имеют значение, когда нам нужно сравнивать объекты друг с другом.

- Ссылочное равенство: два объекта считаются равными, если они ссылаются на один и тот же адрес в памяти.
Вот как мы можем проверить это в коде:

var obj1 = new object();
var obj2 = obj1;
bool areEqual = object.ReferenceEquals(obj1, obj2);

- Равенство идентификаторов подразумевает, что у класса есть поле id. Два экземпляра такого класса будут равны, если они имеют одинаковые идентификаторы.

- Структурное равенство: два объекта считаются равными, если все их члены равны.

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

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

2. Время жизни
Сущности живут долго, у них есть история (даже если она не хранится) о том, что с ними произошло и как они изменялись за свою жизнь. Объекты-значения, напротив, имеют нулевую продолжительность жизни. Они легко создаются и уничтожаются. Это следствие их взаимозаменяемости.

Таким образом, объекты-значения не могут жить сами по себе, они всегда должны принадлежать одной или нескольким сущностям. Данные, которые представляет объект-значение, имеют смысл только в контексте объекта, который на них ссылается. В примере выше вопрос "Сколько денег?" не имеет смысла, потому что не передаёт надлежащего контекста. Тогда как, вопросы "Сколько денег у пользователя X?" или "Сколько денег у всех пользователей?" совершенно валидны.

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

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

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

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

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

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

Источник: https://enterprisecraftsmanship.com/posts/entity-vs-value-object-the-ultimate-list-of-differences

День 1238. #ЗаметкиНаПолях #DDD
Сущности и Объекты-Значения: Полный Список Различий. Окончание
Начало

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

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

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

Как хранить объекты-значения в БД?
Допустим, у нас есть два класса в нашей модели предметной области: сущность Person и объект значения Address:

// Сущность
public class Person
{
  public int Id { get; set; }
  public string Name { get; set; }
  public Address Address { get; set; }
}
 
// Объект-значение
public class Address
{
  public string City { get; set; }
  public string ZipCode { get; set; }
}

Один из вариантов хранения: добавить в Address поле Id и хранить в отдельной таблице. Это правильно с точки зрения БД, но имеет два недостатка:
1) Address содержит идентификатор, т.е. мы предоставляем классу Address некоторую идентичность. И это нарушает определение объекта-значения.
2) Мы потенциально можем отделить объекты-значения от сущностей. Address теперь может жить сам по себе, потому что мы можем удалить строку Person, не удаляя соответствующую строку Address. Кроме того, вы можете выбрать объект Address из таблицы отдельно от объекта Person. Это нарушило бы другое правило, согласно которому время жизни объектов-значений должно полностью зависеть от времени жизни их родительских сущностей. Получается, лучшее решение* — встроить поля из таблицы Address в таблицу Person.
*Здесь надо заметить, что ORM системы, вроде Entity Framework, позволяют сохранять объекты-значения в отдельные таблицы, сохраняя при этом абстракцию объекта-значения.

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

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

Итого
- Сущности имеют свою внутреннюю идентичность, а объекты-значения — нет.
- Понятие равенства идентификаторов относится к сущностям; понятие структурного равенства относится к объекты-значениям; понятие ссылочного равенства относится к обоим.
- Сущности имеют историю; объекты-значения имеют нулевую продолжительность жизни.
- Объект-значение всегда должен принадлежать одной или нескольким сущностям, он не может жить сам по себе.
- Объекты-значения должны быть неизменяемыми; сущности почти всегда изменяемы.
- Чтобы распознать объект-значение в модели предметной области, мысленно замените его числом.
- Всегда отдавайте предпочтение объектам-значениям, а не сущностям в вашей модели предметной области.

Источник: https://enterprisecraftsmanship.com/posts/entity-vs-value-object-the-ultimate-list-of-differences

День 1239. #ЗаметкиНаПолях
Привязка Модели из Нескольких Источников в Один Класс в ASP.NET Core
Допустим, у нас есть следующий метод действия в ASP.NET API:

public IActionResult Post(
 [FromBody] 
 RequestBody body,
 [FromHeader(Name = "Accept")]
 string accept,
 [FromHeader(Name = "X-Correlation-Id")]
 string correlationId,
 [FromQuery(Name = "filter")]
 string filter)
{
  // какая-то обработка
  return Ok();
}

Мы хотели бы объединить все параметры в один класс, PostRequest, вместо того чтобы использовать кучу разных. Создадим класс, который будет хранить все наши данные:

public class PostRequest
{
  [FromBody]
  public RequestBody Body { get; set; };

  [FromHeader(Name = "Accept")]
  public string Accept { get; set; };

  [FromHeader(Name = "X-Correlation-Id")]
  public string CorrelationId { get; set; };

  [FromQuery(Name = "filter")]
  public string Filter { get; set; };
}

public class RequestBody
{
  public string SomeString { get; set; };
  public bool SomeBool { get; set; }
}

Изменим наш метод действия, чтобы он принимал наш тип:

[HttpPost]
public IActionResult Post(PostRequest req)
{
  // просто возвращаем объект
  return new OkObjectResult(req);
}

Теперь, если мы попытаемся вызвать наш метод действия:

POST
Accept: application/json
X-Correlation-Id: my-correlation-id

https://localhost:7001/home?filter=one

{"someString": "Some string", "someBool": true}

Мы получим следующее сообщение об ошибке:

{
 …
  "title": "One or more validation errors occurred.",
  "status": 400,
  "errors": {
    "Body": ["The Body field is required."],
    "Accept": ["The Accept field is required."],
    "filter": ["The Filter field is required."],
    "X-Correlation-Id": ["The CorrelationId field is required."]
  }
}

По умолчанию ASP.NET Core не осуществляет привязку модели из различных источников к одному классу. Чтобы изменить это поведение, нужно настроить ApiBehaviourOptions в методе ConfigureServices:

services.Configure<ApiBehaviorOptions>(options =>
{
  options.SuppressInferBindingSourcesForParameters = true;
});

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

{
  "body": {
    "someString": "Some string",
    "someBool": true
  },
  "accept": "application/json",
  "correlationId": "my-correlation-id",
  "filter": "one"
}

Источник: https://josef.codes/model-bind-multiple-sources-to-a-single-class-in-asp-net-core/

День 1240. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Начало
Защита приложений — непростая задача. Приложение состоит из множества компонентов: серверная логика, клиентская логика, хранилище и передача данных и многое другое. Поэтому создание безопасного приложения может показаться действительно сложной задачей. К счастью, большинство реальных уязвимостей имеют одни и те же основные причины. Первый шаг к их устранению— знать, что искать. Вот список распространённых уязвимостей, которые могут встретиться в C# приложениях.

1. Атаки на внешние сущности XML (XML External Entity - XXE)
При XXE-атаках злоумышленники используют синтаксический анализатор XML для чтения произвольных файлов на вашем сервере. Используя XXE, злоумышленники также могут получить информацию о пользователе, файлы конфигурации или другую конфиденциальную информацию, например учетные данные AWS.

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

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file://D:/XXETarget.txt">
]>
<foo>&xxe;</foo>

Здесь определена сущность '&xxe;'. При обработке этого XML-документа парсер подставит вместо '&xxe;' содержимое файла 'D:\XXETarget.txt'.

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

2. Небезопасная десериализация
Небезопасная десериализация возникает, когда злоумышленник может манипулировать сериализованным объектом и вызывать непредвиденные последствия в ходе выполнения программы. Ошибка небезопасной десериализации часто приводит к обходу аутентификации, отказу в обслуживании или даже к выполнению произвольного кода.
Чтобы предотвратить небезопасную десериализацию, нужно следить за исправлениями и поддерживать зависимости в актуальном состоянии. Многие уязвимости десериализации возникают из-за зависимостей, поэтому убедитесь, что ваш сторонний код безопасен. Также помогает отказ от использования сериализованных объектов и использование вместо них простых типов данных.

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

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

4. Атаки на отказ в обслуживании (Denial of service – DoS)
DoS-атаки нарушают работу целевой машины, так что законные пользователи не могут получить доступ к её сервисам. Злоумышленники могут запускать DoS-атаки, истощая все ресурсы сервера, вызывая сбои процессов или выполняя одновременно слишком много длительных HTTP-запросов.
От этого типа атак трудно защититься, но есть способы минимизировать риск, максимально усложнив задачу для злоумышленников. Например, вы можете развернуть брандмауэр, обеспечивающий защиту от DoS-атак, установить ограничения на размер файлов или запретить определенные типы файлов.

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

Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet

День 1241. #Курсы
Давно не предлагал никаких видео. И вот в очередной раз неведомые алгоритмы ютуба подкинули годноты. Канал Coding Tutorials с большим количеством, на мой взгляд, прекрасного контента на тему C#, Angular и Blazor от Джаспера Кента, эксперта с более чем 30-летним стажем в разработке ПО и преподавании. У канала с таким контентом почему-то просто преступно мало подписчиков и просмотров.

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

Кроме этого, целые плейлисты про
- SOLID
- Паттерны проектирования
- Внедрение зависимостей
- Entity Framework
- Angular
- Blazor
и про многое другое.

В общем, категорически советую.

День 1242. #ЧтоНовенького
Пошаговый Переход с ASP.NET на ASP.NET Core
В конце мая Microsoft представили превью инструментов для пошаговой миграции приложений ASP.NET Framework на ASP.NET Core. Инструментарий состоит из двух компонентов:
- расширения для Visual Studio, которое создаёт новое приложение ASP.NET Core наряду с существующим приложением, чтобы конечные точки можно было постепенно перемещать из одного приложения в другое,
- библиотеки System.Web с адаптерами, позволяющими коду ссылаться на общий API, ориентированный на .NET Standard 2.0 и пригодный для использования как в контексте ASP.NET, так и в контексте ASP.NET Core.

Недавно вышла вторая превью версия этого средства миграции. Обновленный инструментарий включает в себя улучшения кода, сгенерированного расширением Visual Studio, дополнения в адаптерах System.Web и возможность совместного использования аутентификации между приложениями ASP.NET и ASP.NET Core.

Установите (или обновите, если использовали раньше) расширение Microsoft Project Migrations для Visual Studio. Оно автоматически будет ссылаться на обновлённую версию адаптеров System.Web.

Пошаговая миграция
Многие крупные проекты используются постоянно в критически важных бизнес-приложениях. Они должны продолжать функционировать и не могут быть приостановлены из-за потенциально длительного перехода на ASP.NET Core. Это означает, что во время миграции приложение должно продолжать работать, а новые функции могут добавляться и развёртываться как обычно. Паттерн Душитель используется для замены существующей устаревшей системы по частям, пока вся система не будет обновлена, а старая система не будет выведена из эксплуатации.

Мы имеем приложение ASP.NET, размещённое в IIS и включающее набор процессов для развёртывания и обслуживания. Процесс миграции направлен на переход к ASP.NET Core без ущерба для текущего развёртывания.

Первый шаг — представить новое приложение на основе ASP.NET Core, которое станет точкой входа. Трафик будет поступать в приложение ASP.NET Core, и, если приложение не сможет сопоставить маршрут, оно передаст запрос в приложение ASP.NET через YARP. Большая часть кода по-прежнему будет находиться в приложении ASP.NET, но приложение ASP.NET Core теперь получает первоначальный трафик и управляет маршрутизацией.

Чтобы начать миграцию бизнес-логики, использующей HttpContext, должны быть созданы библиотеки на основе Microsoft.AspNetCore.SystemWebAdapters. Это позволяет библиотекам, использующим API System.Web, ориентироваться на .NET Framework, .NET Core или .NET Standard 2.0.

Теперь можно начать перемещать маршруты по одному в приложение ASP.NET Core. Это могут быть контроллеры MVC или веб-API (или даже один метод из контроллера), страницы веб-форм, обработчики HTTP или какие-либо другие реализации маршрута. Как только маршрут станет доступен в приложении ASP.NET Core, он будет сопоставляться и обслуживаться оттуда. Со временем основное приложение начнёт обрабатывать всё больше маршрутов.
По ходу миграции у вас может быть маршрут как в приложении ASP.NET Core, так и в приложении ASP.NET Framework. Здесь возможно выполнить A/B-тестирование, чтобы убедиться, что функциональность соответствует ожиданиям.

Когда приложение .NET Framework больше не нужно, его можно удалить. При этом приложение ASP.NET Core по-прежнему будет использовать адаптеры. Последним шагом будет отказаться от использования адаптеров, полностью переведя приложение на платформу ASP.NET Core, чтобы полноценно использовать производительность и новые функции ASP.NET Core, которые могут быть недоступны через адаптеры.

В этом видео показан пример миграции https://youtu.be/P96l0pDNVpM

Источники:
- https://devblogs.microsoft.com/dotnet/incremental-asp-net-to-asp-net-core-migration/
- https://devblogs.microsoft.com/dotnet/incremental-asp-net-migration-tooling-preview-2/

День 1243. #Юмор

День 1244. #Оффтоп
Закон Конвея, DDD и Микросервисы
Закон Конвея гласит, что «любая организация, проектирующая систему, создаст проект, структура которого является копией коммуникационной структуры организации». Это оказывает существенное влияние на то, как создаётся ПО, особенно если применяются микросервисы и/или предметно-ориентированное проектирование (DDD).

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

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

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

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

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

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

Классический комикс ниже иллюстрирует некоторые крупные компании и их (предполагаемые) проблемы с организационной структурой.

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

Источник: https://ardalis.com/conways-law-ddd-and-microservices/

Некоторые крупные компании и их (предполагаемые) проблемы с организационной структурой.

День 1245. #Безопасность #СписокУязвимостей
Памятка по Уязвимостям в C# Приложениях. Продолжение
Начало

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

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

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

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

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

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

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

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

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

Источник: https://dzone.com/articles/c-applications-vulnerability-cheatsheet

День 1246. #ЗаметкиНаПолях #AsyncTips
Асинхронные очереди

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

Решение
Требуется очередь с асинхронным API. В базовом фреймворке .NET такого типа нет, но в NuGet есть пара возможных решений.

1. System.Threading.Channels
Библиотека для асинхронных коллекций «производитель/потребитель» с акцентом на быстродействие. Производители записывают элементы в канал вызовом WriteAsync, а когда завершают производство элементов, один из них вызывает Complete для уведомления канала о том, что в дальнейшем элементов больше не будет:

var queue = Channel.CreateUnbounded<int>();
// Код-производитель
var writer = queue.Writer;
await writer.WriteAsync(7);
await writer.WriteAsync(13);
writer.Complete();

// Код-потребитель
// Выводит "7", затем "13".
var reader = queue.Reader;
await foreach (int value in reader.ReadAllAsync())
  Console.WriteLine(value);

Код-потребитель использует асинхронные потоки.

2. System.Threading.Tasks.Dataflow
BufferBlock<T> из библиотеки TPL Dataflow имеет много общего с каналом:

var queue = new BufferBlock<int>();
// Код-производитель
await queue.SendAsync(7);
await queue.SendAsync(13);
queue.Complete();

// Код-потребитель.
// Выводит "7", затем "13".
while (await queue.OutputAvailableAsync())
  Console.WriteLine(await queue.ReceiveAsync());

Код-потребитель использует метод OutputAvailableAsync, который на самом деле полезен только с одним потребителем. Если потребителей несколько, может случиться, что OutputAvailableAsync вернет true для нескольких потребителей, хотя элемент только один. Если очередь завершена, то ReceiveAsync выдаст исключение InvalidOperationException. Таким образом, для нескольких потребителей код будет выглядеть так:

while (true)
{
  int item;
  try
  {
    item = await queue.ReceiveAsync();
  }
  catch (InvalidOperationException)
  {
    break;
  }
  Console.WriteLine(item);
}

Библиотека Channels больше подходит для асинхронных очередей «производитель/потребитель» там, где это возможно. Помимо регулировки для случаев, когда производители работают быстрее потребителей, поддерживаются несколько режимов выборки (об этом в следующих постах). Однако, если логика вашего приложения может быть выражена в виде «конвейера», через который проходят данные, TPL Dataflow может быть более логичным кандидатом.

См. также
- очереди «производитель/потребитель» с блокирующей семантикой вместо асинхронной.

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

День 1247. #Карьера #ВопросыНаСобеседовании
Самые Распространённые Вопросы на Поведенческом Собеседовании. Начало
Вот топ вопросов на поведенческом собеседовании, на которые вы должны быть готовы ответить при приёме на работу.

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

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

1. «Какая у вас самая большая слабость?»
Один из самых распространённых вопросов, и тот, на котором чаще всего спотыкаются. Лучший ответ — назвать слабость, которая применима только к конкретным ситуациям, например: «Не терплю, когда коллеги не выполняют обещания, особенно когда это относится к критически важным задачам». Ключ в том, чтобы закончить ответ тем, как вы планируете избавиться от этой слабости. Это яркий пример того, как использовать метод STAR (Situation, Task, Action, Result - Ситуация, Задача, Действие, Результат).

Ситуация: опишите ситуацию, в которой всё произошло.
Задача: опишите задачу, которую вы должны были выполнить, чтобы решить проблему.
Действие: объясните, какие действия вы предприняли для выполнения задачи.
Результат: расскажите о результатах своих действий и постарайтесь быть как можно более подробным. Как ваши действия помогли компании или организации работать лучше?

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

«Расскажите о ситуации, когда вам пришлось сотрудничать с кем-то, чей характер сильно отличался от вашего.»
«Опишите ситуацию, когда вам пришлось проявить инициативу и продемонстрировать лидерские качества.»
«Расскажите о случае, когда вам нужно было получить информацию от человека, который не очень реагировал. Что вы сделали?»
«Расскажите о случае, когда вы неверно отреагировали на ситуацию с коллегой.»

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

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

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

Источник: https://www.fastcompany.com/90756503/your-ultimate-guide-to-ace-the-most-common-interview-questions

День 1248. #Карьера #ВопросыНаСобеседовании
Самые Распространённые Вопросы на Поведенческом Собеседовании. Продолжение
Начало

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

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

Эти вопросы будут вашим шансом доказать, что вы можете обращаться с трудными клиентами. Обязательно объясните:
- контекст вашего взаимодействия;
- тип клиента, с которым вы имели дело;
- урок, который вы извлекли из этого опыта.

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

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

«Расскажите о случае завала на работе. Что вы сделали?»
«Расскажите о случае, когда непредвиденная проблема сорвала ваши планы. Как вы отреагировали?»
«Как вы ставите цели и как добиваетесь их достижения?»

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

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

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

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

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

Источник: https://www.fastcompany.com/90756503/your-ultimate-guide-to-ace-the-most-common-interview-questions

День 1249. #Карьера #ВопросыНаСобеседовании
Самые Распространённые Вопросы на Поведенческом Собеседовании. Окончание
Начало
Продолжение

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

«Расскажите о случае, когда вы находились под сильным давлением и как вы это пережили.»
«Расскажите, как вы устроились на предыдущую работу и адаптировались там.»
«Расскажите о вашей неудаче. Как вы справились с ситуацией?»

Используйте вопросы об адаптации, чтобы рассказать о:
- том, как вы ставите цели и придерживаетесь их;
- методах борьбы со стрессом, которые используете.

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

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

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

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

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

Итого
Существует бесконечное количество способов ответить на вопросы поведенческого интервью. Самое главное, что нужно помнить:
1) Будьте честным.
2) Заранее изучите возможные вопросы.
3) Запишите кратко истории, которые, по вашему мнению, будут хорошими ответами на вопросы.
4) Запишите опыт, который вы извлекли из каждой истории.

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

Источник: https://www.fastcompany.com/90756503/your-ultimate-guide-to-ace-the-most-common-interview-questions