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

Как называется группа программистов?
Сборка

Какой лучший префикс для глобальных переменных?
//

Я люблю мой кофе таким же, какой я люблю мои IDE…
Темным и бесплатным.

Как лучше назвать фронтенд разработчиков?
<div>елоперы

Какой любимый фильм ужасов у программиста?
XORцист

Как вы называете людей, которые пользовались интернетом до того, как он стал крутым?
Httpстеры

Чем занимался Питер Паркер после того, как потерял работу фотографа в Daily Bugle?
Он перешел в веб-разработку.

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

Как пираты общались до Интернета?
По сети пир-ту-пир

Молчи…
Молчи…
Молчи…
Молчи…
«Но это работает на моей машине»
Блин!

Почему среди SQL-разработчиков один из самых высоких показателей разводов?
Потому что у них отношения один-ко-многим.

Как называется группа из восьми ваххабитов?
Ваххабайт

UI – это как шутка.
Если приходится объяснять, он скорее всего не очень хороший.

Новый запрос к базе данных заходит в бар.
А сервер говорит: «Извините, только кэш».

Почему программисты – плохие марафонцы?
Они специализируются на спринтах.

Девушки похожи на доменные имена.
Те, которые вам нравятся, уже заняты.

У меня есть…
У меня есть шутка про документацию, но она ещё не готова.
У меня есть шутка по поводу моего кода, но она работает только на моей машине.
У меня есть анекдот про UDP. Но до вас вряд ли дойдёт.

Как у вас с английским?
Как .NET разработчик назвал свою лодку?
Sea Sharp

Я: забыл } в JSON
Компилятор: YOU SHALL NOT PARSE 🧙‍♂️

Do British websites use cookies or biscuits?

The plural of regex is regrets.

You know how a hacker escapes the FBI?
\FBI

My team had a debate on what the best looping variable name is.
i won.

Never ask a SQL dev to help you move furniture.
They drop tables.

A GET request was reluctant to go to the party.
It had no body to go with.

Roses are red,
Violets are blue,
Unexpected ‘{‘ on line 32.

Roses are red’);
DROP TABLE rhyme;
You better sanitize your inputs next time

Errors are red,
My screen is blue.
I think I deleted system32

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

День 1231. #ЗаметкиНаПолях #AsyncTips
Блокирующие Стеки и Множества

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

Решение
Тип .NET BlockingCollection<T> по умолчанию работает как блокирующая очередь, но он также может работать как любая другая коллекция «производитель/потребитель». По сути, это обёртка для потокобезопасной коллекции, реализующей IProducerConsumerCollection<T>.

Таким образом, вы можете создать BlockingCollection<T> с семантикой LIFO или семантикой неупорядоченного множества:

var blockStack = new BlockingCollection<int>(
  new ConcurrentStack<int>());
var blockBag = new BlockingCollection<int>(
  new ConcurrentBag<int>());

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

// Код-производитель
blockStack.Add(7);
blockStack.Add(13);
blockStack.CompleteAdding();

// Код-потребитель
// Выводит "13", затем "7".
foreach (int item in blockStack.GetConsumingEnumerable())
Console.WriteLine(item);

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

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

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

Подробнее о потокобезопасных коллекциях см. 1, 2, 3

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

День 1232. #МоиИнструменты
DataGrip
Мы в нашем чате частенько шутим на тему Visual Studio или Rider. В принципе, здесь предпочтения делятся почти поровну, и каждый пользуется тем, что ему больше нравится. Но вот относительно этого инструмента от JetBrains я должен сказать, что не видел ничего, даже близко похожего по функционалу!

Речь идёт об IDE DataGrip, предназначенной для работы с базами данных.

Вот в этом видео краткое (на 40 минут) описание того, что может эта IDE, и, я вам должен сказать, что 80% моих повседневных задач она намного упростит. Автозаполнение кода, поиск ошибок в запросах (например, отсутствующих объектов, неоднозначно указанных колонок или условий, которые всегда истины), рефакторинг запросов, автоматическое форматирование кода (которое можно экспортировать для создания стиля кодирования в команде). Помимо этого, есть какие-то уж совсем сумасшедшие вещи, типа, визуального сравнения (diff) результатов двух запросов, экспорта выделенных результатов в другую БД или локальной история изменений файлов и папок. Осталось запомнить, что она всё это умеет и применять)))

Есть один минус. 30-дневный триал доступен. А вот дальше, если вы в РФ, могут возникнуть проблемы с покупкой.

День 1233. #Курсы
GitHub Skills
GitHub представил GitHub Skills – новую платформу для изучения GitHub.

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

GitHub Skills основан на GitHub Actions и поможет вам развить новые навыки, а также сделать разработку на GitHub более эффективной. Например, если вы хотите настроить сайт для своего проекта или создать личный блог, вы можете пройти курс «GitHub Pages» и опубликовать свой сайт.

Сейчас доступны курсы по некоторым из самых популярных тем:

Introduction to GitHub
Начните использовать GitHub меньше, чем за час.

Communicate using Markdown
Упорядочивайте идеи и общайтесь с коллегами с помощью Markdown, облегчённого языка форматирования текста.

GitHub Pages
Создайте сайт или блог из своих репозиториев GitHub с помощью GitHub Pages.

Review pull requests
Сотрудничайте и работайте вместе на GitHub.

Resolve merge conflicts
Узнайте, почему возникают конфликты и как их разрешать.

Hello GitHub Actions
Создайте действие GitHub и используйте его в рабочем процессе.

Continuous integration
Создавайте рабочие процессы, позволяющие использовать непрерывную интеграцию (CI) для ваших проектов.

Publish packages
Используйте GitHub Actions, чтобы опубликовать свой проект в образе Docker.

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

Поскольку GitHub Skills работает на GitHub Actions, пройти курс GitHub Skills можно бесплатно в публичных репозиториях. Если вы хотите использовать GitHub Skills в закрытом репозитории, это бесплатно, пока вы не израсходуете ежемесячные бесплатные минуты GitHub Actions в своей учетной записи.

В связи с переходом на GitHub Skills, Learning Lab прекратит работу 1 сентября 2022 года.

Источник: https://github.blog/2022-06-06-introducing-github-skills/

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