DEV Community: Oleksandr Martyniuk

7 проблем в автотестах

Oleksandr Martyniuk — Mon, 01 Mar 2021 12:19:45 +0000

В своїй практиці я зустрічав проєкти з різними підходами до тестування: деякі мали 99% покриттям юніт-тестами, а в інших автоматичне тестування було відсутнє взагалі. В цій статті я хочу звернути увагу на характерні проблеми з автоматичними тестами, що мені зустрічались, і як їх вирішити.

Кожен хороший програміст переймається якістю власного коду, тому писати тести - це частина нашої роботи. Далі мова піде саме про тести, які створюються програмістами під час написання коду і проблеми в цих тестах. Це стосується як системних тестів, так і інтеграційних та модульних.

Проблема №1. Тести залежать від випадкових даних.

Важливою властивістю тестів є їх контрольованість. Тести повинні повертати однаковий результат в незалежності від пори року та температури в приміщенні. Якщо ваші тести випадково зазнають невдачі, ви не можете на них покладатись. Є великий ризик, що такі тести будуть тимчасово відключені або зовсім видалені.

Я пам'ятаю випадок, коли деякі тести почали падати в перший день місяця. Програміст розраховував, що в місяці завжди буде як мінімум 30 днів. У лютому його припущення не справдилося.

Також згадується випадок, коли системні тести розраховували на наявність певних записів в базі даних. На великий подив, в цьому ж оточенні відбувалося ручне тестування програми, тому в один момент необхідні дані були видалені. І так як тест очікував знайти запис за унікальним ID, який генерувався автоматично, відновити дані було складно. Довелося виправляти декілька десятків тестів.

Що робити?

Якщо тести залежать від випадкових величин на вході, ви рано чи пізно отримаєте проблеми. Краще попередьте їх, замінивши всі випадкові дані константами. До випадкових даних належать:

дата і час
дані специфічні для оточення (змінні оточення, назва комп'ютера, символ розмежування каталогів і т.ін.)
файлова система
мережа і бази даних

Якщо ви звертаєтесь до зовнішніх залежностей напряму у коді, розгляньте можливість заміни їх на обгортки, які пізніше можна буде замінити стабами в автотестах. Наприклад, замість DateTime.Now оголосіть власний інтерфейс з методом Now, наприклад IDateTimeService.Now. В тесті замініть його реалізацію на константу new DateTime(2021, 2, 27) і отримаєте контрольовані вхідні дані. В реальному коді метод Now буде викликати DateTime.Now і нічого не зміниться.

Досвідчені програмісти бачать наперед, чи можливо протестувати їх код. Якщо при написанні тестів ви переймаєтесь тим, як ваш код буде тестуватись далі, це свідчить про те, що практика тестування стала вашим надійним помічником і ви правильно користуєтесь цим інструментом.

Якщо ви розраховуєте на наявність певних даних в зовнішніх, по відношенню до вашого коду, системах, розгляньте можливість створення цих даних перед початком тесту і видалення їх після його завершення.

Проблема №2. Тести дублюють логіку коду.

Припустимо, у нас є математична формула, яку ми намагаємося реалізувати в коді. Наприклад, обчислення площі трикутника за його сторонами:

public double CalculateAreaOfTriangle(double a, double b, double c)
{
    var p = (a + b + c) / 2;
    return Math.Sqrt(p * (p - a) * (p - b) * (p - c));
}

При її тестування інтуїтивним підходом буде повторити формулу в тесті, щоб не обчислювати площу самостійно в калькуляторі. Але це не вірний підхід, бо програміст може допустити помилку, яка буде продубльована в тесті, особливо якщо один програміст пише і код, і тест до нього. Крім того, використання складних алгоритмів в тестах ускладнює їх підтримку.

Кращим підходом буде розрахувати значення самостійно і використовувати в тесті константу. Також непоганим підходом може бути використання еталонної реалізації. Для прикладу вище, якщо ви маєте бібліотеку для роботи з геометрією, вона добре відома і протестована, то можна порівняти результати виконання функції CalculateAreaOfTriangle з аналогічною функцією з цієї бібліотеки.

Варто додати, що такого роду помилку я зустрічав раз чи двічі. В більшості проєктів, які я бачив, тести реалізовані вірно: константи використовуються як на вході, так і при перевірці тверджень.

Проблема №3. Тести не запускаються автоматично.

Ця помилка теж не дуже поширена. Інколи буває, що програмісти тримають тести до коду, який вони написали, лише на своєму ПК, або тести знаходяться в репозиторії але їх необхідно запускати вручну. Або запуск тестів автоматизовано, але тригером є певна подія, ініційована людиною: наприклад, лідер команди QA натискає кнопку у веб-інтерфейсі.

Загальним правилом є автоматичний запуск тестів при зміні коду: якщо змінився модуль А, то повинні бути запущені всі тести, що тестують модуль А (модульні тести), або тестують модулі А, Б і В як єдине ціле (інтеграційні тести). Інколи цю процедуру спрощують і запускають всі тести при будь-яких змінах в коді. Також можливий варіант, коли певні тести запускаються періодично зі сталим інтервалом. Результати таких тестів у випадку невдачі повинні доноситись певним чином до автора змін (обов'язково) і до всіх зацікавлених осіб (за бажанням).

Але приховувати тести, або запускати їх вручну - поганий підхід. Відповідальна за це людина може відкласти це на декілька днів, а то й тижнів. Весь цей час невдалий тест буде чекати, щоб повідомити про знайдену помилку. А чим раніше помилку виявлено, тим легше її виправити.

Проблема №4. Тести залежать від інших тестів.

При розробці системних (end-to-end) тестів виникає бажання їх спростити, перевикориставши результати, отримані з попередніх тестів.

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

Якщо у вас вже є готові тести для створення користувача і для додавання товару, а також тест для логіну, то виникає жагуче бажання в тестах для кошику використати результат роботи тестів реєстрації користувача і додавання товару. В такому разі програміст створює скрипт, в якому тести запускаються послідовно:

Реєстрація користувача
Додавання товару
Вхід на сайт
Перехід на сторінку товару
Додавання товару в кошик

Тобто, наш тест залежить від даних, створених в результаті роботи інших 4 тестів. І ще добре, коли в документації вказано, які саме дані потрібні нашому тесту і як вони мають бути створені.

Ви можете сказати, що це неправильно і так ніхто не робить! Адже, будь-яка помилка в попередніх тестах зробить неможливою перевірку кошику. Для прикладу, якщо не працює реєстрація, ми, насправді, не знаємо, чи можуть вже зареєстровані користувачі придбати щось в нашому магазині. Так, все вірно. Але я бачив такі тести досить часто в своїй практиці, в тому числі у всесвітньо відомих продуктах.

Програміст, що написав такий код, може вам зауважити, що це економить час прогону тестів, адже для кожного нового тесту можна перевикористати вже доступні дані і не створювати/видаляти користувачів і товари кожен раз. Якщо врахувати, що дані зберігаються в досить повільних базах даних, це дійсно може суттєво економити час.

Такий підхід може працювати, але не довго. Поки тестів мало і ними займається декілька людей, які добре контактують і слідкують за станом тестів, проблем може не виникати. Але, як тільки з'являються сотні тестів і їх підтримкою починають займатися декілька команд, ви гарантовано отримаєте безлад і затримки з постачанням продукту.

Що робити?

Намагайтеся не писати автоматичних тестів, що залежать один від одного. Такі неочевидні залежності можуть коштувати дорого в майбутньому, коли тестів стає багато. Натомість, ви можете підготувати необхідні тестові дані у вигляді скрипту і перед кожним прогоном розгортати нову базу даних. Після того, як тести відпрацювали, ці дані повинні видалятись. Сьогодні доступні технології віртуалізації, що спрощують цей процес. Запуск docker контейнерів займає секунди. Тобто, декілька секунд часу і ви маєте БД з підготовленими для тестів даними. Наслідком цього є те, що вам необхідно підтримувати цей скрипт. Він повинен стати частиною репозиторію і змінюватись разом зі зміною структури даних.

До того ж, незалежні тести можуть виконуватись паралельно і таким чином працювати навіть швидше, ніж тести, що виконуються один за одним в чіткій послідовності.

Проблема №5. Тести неповні.

При написанні модульних тестів, зазвичай, задаються вхідні дані і перевіряються вихідні. Якщо ми тестуємо складні класи, що мають безліч залежностей, не завжди очевидно, що є результатом виконання системи під тестом.

Уявіть, що у нас є метод, що видаляє файл. Він перевіряє права доступу, далі звертається до сервісу файлів і логує результат операції. Всі сервіси, використані в цьому методі, є зовнішніми залежностями, функціонал яких ми не будемо тестувати. В коді тесту вони будуть існувати у вигляді моків.

public void DeleteFile(string fileName)
{
    _permissionService.CheckPermissions(Operation.DeleteFile);
    _fileService.DeleteFile(fileName);
    _logger.LogInformation($"File '{fileName}' was successfully deleted.");
}

Вхідними даними для цього методу будуть:

параметр fileName
успішність виконання методу CheckPermissions
успішність виконання методу DeleteFile
успішність виконання методу LogInformation

Вихідними даними для методу будуть:

факт виклику методу CheckPermissions і назва операції, для якої перевіряються права
факт виклику методу DeleteFile та ім'я файлу, що видаляється
факт виклику методу LogInformation і рядок тексту, що логується
скільки разів викликались зазначені вище методи
чи викликались будь які інші методи будь яких сервісів

Тобто, вищенаведений код залежить не тільки від вхідних параметрів, але також від успішності виконання всіх методів. При тестуванні ми повинні задати всі вхідні дані і перевірити всі вихідні. Тільки у такому разі наш тест буде повним.

Марк Сіманн у своїй статті Dependency rejection називає ці данні непрямий вхід і вихід (indirect input and output). Але це такі самі вхідні та вихідні дані, як і параметри методу та його результат. Не можна їх ігнорувати, інакше не можна гарантувати, що код працює як належить.

Я часто бачив, як навіть досвідчені колеги ігнорували і не перевіряли частину вихідних даних, або не переймалися над тим, щоб задати частину вхідних даних. Пояснень я чув декілька: "тест повинен тестувати лише одну річ" і "ми не перевіряємо те, що не важливо для логіки програми".

З першим твердженням я погоджуюсь, тестувати потрібно лише одну річ за раз. Але "одна річ" значить не один Assert в кінці тесту. Одна річ - це один виклик тестуємого методу, або, іншими словами, один набір вхідних даних. Перевіряючи лише частинку вихідних даних, ми не гарантуємо коректність роботи методу для даного випадку.

Якщо програміст каже, що не тестує те, що не важливо, можна запитати, для чого він додав неважливий код взагалі? Часто програмісти ігнорують перевірку запису логів. Логи програми, можливо, не важливі для програміста зараз і їх навряд чи можна назвати частиною бізнес логіки. Але логи точно стають важливими, коли код не працює у користувача. Коли аналіз логів - єдиний спосіб знаходження дефекту, вони надзвичайно важливі.

Не варто плутати "неповні тести" і "неповне покриття тестами". Неповне покриття означає, що деякі ділянки коду не задіяні в тестах. Це може бути припустимим, якщо це якісь унікальні випадки, кількість можливих тестових сценаріїв завелика і ваша команда не прагне до 100 % покриття.

Що робити?

Зважаючи на все це, можна зробити висновок, що код тесту буде об'ємнішим і складнішим, ніж код методу, що тестується. Часто так і є, особливо, коли клас має багато зовнішніх залежностей. Але це ціна, яку ми платимо за використання механізму ін'єкції залежностей (DI). Ви можете спростити собі життя, використовуючи бібліотеки для моків і фейків, наприклад Moq або NSubstitude. Але інколи все ж дисципліни в програмістів не вистачає і тоді ми приходимо до наступної, ще більшої проблеми з тестами.

Проблема №6. Тести написані неохайно.

Під неохайністю я маю на увазі, що код тестів написаний нашвидкоруч, без належної уваги. Дехто вважає, що код тестів - це щось другорядне і не варто йому приділяти багато уваги. Я з цим не згоден. Тести - це те, що забезпечує якість вашого коду. Якщо вам не важлива якість, тоді так, тести - другорядна річ і не варто витрачати зусилля, підтримуючи їх в належній формі. Але якщо ви вирішили писати тести і якість продукту для вас має значення, то варто підтримувати їх в такому ж стані, як і основний код. Це значить, що тести мають легко читатися, не мають містити дубльованого коду і, взагалі, підхід повинен бути точно такий як і до основного коду вашого продукту.

Я бачив ситуації, коли погано організовані тести потрапили в руки нової людини і та, замість того щоб розібратись і покращити їх, просто закоментувала код (також це можна зробити завдяки атрибутам типу [Ignore]). Далі такий тест може бути просто забутий і контроль якості буде ослаблений.

Що робити?

Не варто зневажливо ставитись до тестів. Якщо їх проблематично змінювати, проведіть рефакторинг, точно так, як ви б зробили в основному коді. Закладайте час на написання тестів (модульних чи інтеграційних) при плануванні задач. Якщо ваш керівник просить знехтувати тестами, щоб пришвидшити розробку, запитайте, чи готовий він пожертвувати якістю продукту і темпом розробки в майбутньому, адже код без тестів змінювати страшно.

Проблема №7. Тести відсутні.

Можливо, для вас це звучить, як щось неймовірне? Впевнений, що для більшості це так. Але й досі існують софтверні компанії, які ігнорують тестування, що проводиться програмістами. Зазвичай, вони мають відокремлений підрозділ тестувальників, і відповідальність за якість продукту покладається на нього.

В таких компаніях, зазвичай, пишуть неякісний код і продукт випускається з безліччю дефектів. Задачі по розробці нових функції багато разів кочують з робочого столу програміста до робочого столу QA і назад. Випуск продукту здійснюється максимум раз в рік, а відділи тестувальників і програмістів часто в стані конфлікту.

Інколи мови програмування або фреймворки не полегшують можливості модульного тестування. Наприклад, мови Delphi або C++ мають дуже обмежені можливості рефлексії, створення фейків, моків і стабів. В цих мовах створення тестів для складного коду з безліччю залежностей може бути вкрай витратним процесом, тому модульного тестування уникають.

Крім того, часто програмісти не тестують свій код в компаніях, де історично склалась така культура. Інколи такі компанії були засновані не програмістами, а, наприклад, бухгалтерами або інженерами-електронщиками.

Що робити?

Ми, як професіонали своєї справи, маємо переживати за результат своєї праці. Тестування забезпечує якість і надійність, тож не ігноруйте його. Не треба розраховувати, що ваш колега QA знайде всі дефекти. Такий підхід веде до неохайного коду і програміст з часом деградує.

Спонукайте вашого керівника до переходу на інші, сучасні мови програмування, попросіть його знайти час на впровадження фреймворків тестування, які б полегшили вам роботу. Якщо ваш безпосередній начальник не реагує, зверніться безпосередньо до керівництва компанії. В сучасному світі продукт, що тестується поверхово, не має майбутнього і може призвести до репутаційних та матеріальних втрат компанією.

Оригінал статті на моєму сайті.

Транзакції в DynamoDB

Oleksandr Martyniuk — Sat, 03 Oct 2020 09:40:42 +0000

Протягом багатьох років в розробці програмного забезпечення домінували реляційні бази даних. Мова SQL стала однією з найпоширеніших мов програмування. Але на початку 21 століття розвиток WEB 2.0 і потреби таких компаній як Google і Facebook спричинили революцію в збереженні даних.

Сувора узгодженість і внутрішнє об'єднання даних стали менш важливими за високу доступність, швидкість та можливість горизонтального масштабування. З часом сформувалась стійка думка, що NoSQL бази даних - це для не впорядкованих даних великих розмірів, що необхідно зберігати в кластері та швидко отримувати. Тоді як SQL - це для структурованих даних, які пов'язані відношеннями і повинні бути суворо узгодженими завдяки механізму транзакцій та зовнішніх ключів.

Перед проектування систем програмісти почали запитувати себе: що важливіше - ACID чи висока доступність та швидкість? Така ситуація тривала деякий час, аж поки в NoSQL не з'явились транзакції.

В цій статті я розкажу про транзакції в одній з перших NoSQL баз даних - Amazon DynamoDB. Подивимось чим вони відрізняються від транзакцій в SQL, в яких випадках варто будувати програми з їх використанням і як працювати з ними в C# та .NET Core.

DynamoDB

DynamoDB - документна база даних без схеми. Вона зберігає дані в таблицях, кожна з яких може розміщуватись на декількох серверах, розподіляючи таким чином навантаження. Це дозволяє DynamoDB обробляти мільйони запитів за секунду в пікові періоди.

Для представлення документів DynamoDB використовує формат JSON. Створення таблиці вимагає лише трьох аргументів: імені таблиці, ключа та списку атрибутів, серед яких повинен бути атрибут, що використовується як ключ секції.

Ключ секції (Partition Key) використовується для визначення фактичного розміщення запису. Застосовуючи HASH-функцію до ключа секції DynamoDB знаходить фізичний сервер в кластері і місце на сервері куди дані будуть записані. Ключ секції разом з необов'язковим ключем сортування (Sort Key) створюють первісний ключ, що дозволяє унікально ідентифікувати запис в таблиці DynamoDB.

Тоді як реляційні бази даних пропонують для запитів досить потужну мову SQL, DynamoDB пропонує лише операції Put, Get, Update та Delete на одиночних таблицях і взагалі не пропонує можливості об'єднання таблиць. Зате через цю простоту DynamoDB добре масштабується і має високу пропускну здатність.

Ще однією особливістю БД є те, що її використання тарифікується не за місцем, яке займають дані, а за пропускною здатністю, що вимірюється так званими RCU та WCU.

RCU (read capacity unit) - це одиниця, що відповідає одному запиту на читання до 4 Kb даних. WCU (write capacity unit) - аналогічно для запису, тільки ліміт даних - 1 Kb.

Локальна DynamoDB

Давайте спробуємо запустити DynamoDB локально і виконати прості запити для створення таблиці і запису даних.

Для роботи нам знадобляться Docker та .NET Core SDK.

Amazon пропонує локальну версію DynamoDB у вигляді Docker образу. Вона повністю підтримує транзакції, тому акаунт AWS нам не потрібен, далі все будемо робити на локальному комп'ютері.

Відкриємо консоль і запустимо DynamoDB:

docker run -p 8000:8000 amazon/dynamodb-local

...
Initializing DynamoDB Local with the following configuration:
Port:           8000
InMemory:       true
DbPath:         null
SharedDb:       false
shouldDelayTransientStatuses:   false
CorsParams:     *

Docker завантажив образ dynamodb-local і запустив сервіс на порту 8000. Тепер ми можемо звернутися до бази даних за адресою http://localhost:8000.

Дані будуть збережені в пам'яті, про що свідчить параметр InMemory: true, тому DbPath (шлях до файлу даних) порожній. Якщо ви бажаєте зберігати дані на диску між запусками контейнеру вам необхідно вказати параметри -sharedDB та -dbPath.

Система замовлення таксі

Перед тим як створити першу таблицю, опишемо предметну область, яку ми будемо моделювати.

Припустимо у нас є система замовлення таксі. Є клієнт, водій і, власне, замовлення. Опишемо деякі вимоги до нашої системи.

Коли клієнт замовляє поїздку створюється замовлення.
Водій автомобіля приймає замовлення до роботи.
Водій не може прийняти замовлення, яке вже в роботі.
Водій не може прийняти замовлення, якщо він виконує інше замовлення.

Це дуже спрощена схема роботи таких сервісів, як Uber або Uklon. Звісно, можна придумати набагато більше вимог до такої системи, але для нас зараз вони не важливі. Нам важливо продемонструвати ідемпотентність, узгодженність та атомарність операцій з DynamoDB.

Отже, які таблиці нам знадобляться в базі даних?

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

У водія все схоже, тільки як унікальний ідентифікатор візьмемо номер машини. Так як модель водія дуже схожа на модель клієнта, то чому б нам не записати їх в одну таблицю? Назвемо її Taxi.

В замовленні будуть міститись ідентифікатори водія, клієнта і статус замовлення: Pending, InProgress, Done. Замовлення також будемо зберігати в таблиці Taxi.

Уявімо, що в системі існує клієнт, водій та замовлення, яке вже знаходиться в статусі очікування.

Для розробників, які багато працювали з SQL така загальна таблиця може здатись дивною. Їм відразу захочеться розділити її та провести нормалізацію. Але у світі NoSQL це абсолютно звична річ. Такі таблиці називаються гомогенними. DynamoDB не буде марнувати місце на диску для збереження порожніх полів записів, адже вона збергіає документи, або колекції атрибутів. Amazon радить використовувати саме гомогенні таблиці в DynamoDB. Їх рекомендація - тримати пов'язані дані якомога ближче і мати мінімальну кількість таблиць.

AWS SDK та .NET Core

Створимо консольну програму в .NET Core та додамо пакет для роботи з DynamoDB API - AWSSDK.DynamoDBv2

dotnet new console

...
Restore succeeded.

dotnet add package AWSSDK.DynamoDBv2

info : PackageReference for package 'AWSSDK.DynamoDBv2' version '3.5.0.22' added ...
...

У файлі Program.cs створимо клієнта для роботи з локальною базою даних і додамо метод для створення таблиці:


private static readonly AmazonDynamoDBClient client =
    new AmazonDynamoDBClient(new AmazonDynamoDBConfig {ServiceURL = "http://localhost:8000"});

private const string orderId = "{3e80b07d-e2e6-4310-8fda-851296a17a10}";
private const string driverId = "АК9265АК";
private const string clientId = "0993832478";
private const string tableName = "Taxi";

private static async Task CreateTable()
{
    await client.CreateTableAsync(new CreateTableRequest
    {
        TableName = tableName,
        AttributeDefinitions = new List<AttributeDefinition>
        {
            new AttributeDefinition
            {
                AttributeName = "Id",
                AttributeType = "S"
            }
        },
        KeySchema = new List<KeySchemaElement>
        {
            new KeySchemaElement
            {
                AttributeName = "Id",
                KeyType = "HASH"
            }
        },
        ProvisionedThroughput = new ProvisionedThroughput
        {
            ReadCapacityUnits = 5,
            WriteCapacityUnits = 5
        }
    });
}

Код проекту можна знайти на Github

Єдиним атрибутом який ми визначили є Id типу String. В схемі вказано, що поле Id буде ключем секції. Також необхідно вказати очікувану пропускну здатність, щоб DynamoDB знала як правильно масштабуватись. Для нас це не суттєво, нехай буде 5 одиниць за секунду для читання і запису.

Додамо клієнта, водія та замовлення як показано в таблиці вище. Використаємо нетранзакційний метод PutItem.

private static async Task AddClientDriverAndOrder()
{
    await client.PutItemAsync(new PutItemRequest
    {
        TableName = tableName,
        Item = new Dictionary<string, AttributeValue>()
        {
            { "Id", new AttributeValue { S = clientId }},
            { "OrderId", new AttributeValue { S = orderId }}
        }
    });

    await client.PutItemAsync(new PutItemRequest
    {
        TableName = tableName,
        Item = new Dictionary<string, AttributeValue>()
        {
            { "Id", new AttributeValue { S = driverId }}
        }
    });

    await client.PutItemAsync(new PutItemRequest
    {
        TableName = tableName,
        Item = new Dictionary<string, AttributeValue>()
        {
            { "Id", new AttributeValue { S = orderId }},
            { "ClientId", new AttributeValue { S = clientId }},
            { "OrderStatus", new AttributeValue {S = "Pending"}}
        }
    });
}

Транзакція в дії

Спробуймо реалізувати якусь більш складну операцію, наприклад, водій бере замовлення у роботу. Для того, щоб водій взяв замовлення нам необхідно:

оновити рядок замовлення:
- записати номер машини водія в поле DriverId, якщо воно порожнє (водій не може взяти замовлення, яке вже виконується)
- записати InProgress в поле OrderStatus, якщо воно було Pending (водій не може взяти замовлення в будь якому іншому статусі окрім "Очікує виконання")
оновити рядок водія:
- записати номер замовлення в поле OrderId, якщо воно порожнє (водій не може взяти одночасно два замовлення)

Тобто, кінцевий результат повинен виглядати так:

Тут нам знадобиться ACID транзакція, адже оновити записи замовлення і водія потрібно одночасно. Якщо будь яка з перелічених вище умов не виконається, жодних змін в базі не має відбутися.

private static async Task Main(string[] args)
{
    await CreateTable();
    await AddClientDriverAndOrder();
    await AssignOrderToDriver();
}

private static async Task AssignOrderToDriver()
{
    await client.TransactWriteItemsAsync(new TransactWriteItemsRequest
    {
        TransactItems = new List<TransactWriteItem>
        {
            new TransactWriteItem
            {
                Update = new Update
                {
                    TableName = tableName,
                    Key = new Dictionary<string, AttributeValue>
                    {
                        { "Id", new AttributeValue { S = driverId }}
                    },
                    UpdateExpression = "set OrderId = :OrderId",
                    ConditionExpression = "attribute_not_exists(OrderId)",
                    ExpressionAttributeValues = new Dictionary<string, AttributeValue>()
                    {
                        {":OrderId", new AttributeValue { S = orderId}}
                    }
                }
            },
            new TransactWriteItem
            {
                Update = new Update
                {
                    TableName = tableName,
                    Key = new Dictionary<string, AttributeValue>
                    {
                        { "Id", new AttributeValue { S = orderId }}
                    },
                    UpdateExpression = "set DriverId = :DriverId, OrderStatus = :NewStatus",
                    ConditionExpression = "attribute_not_exists(DriverId) AND OrderStatus=:OldStatus",
                    ExpressionAttributeValues = new Dictionary<string, AttributeValue>()
                    {
                        {":DriverId", new AttributeValue { S = driverId}},
                        {":OldStatus", new AttributeValue { S = "Pending"}},
                        {":NewStatus", new AttributeValue { S = "InProgress"}}
                    }
                }
            }
        },
        ClientRequestToken = "IdempotencyToken",

    });
}

В цьому коді ми виконуємо транзакцію, що складається з двох елементів TransactWriteItem. Якщо умова в ConditionExpression виконується, буде виконано вираз UpdateExpression.

Для запису водія ми оновлюємо номер замовлення, якщо воно порожнє:

    UpdateExpression = "set OrderId = :OrderId",
    ConditionExpression = "attribute_not_exists(OrderId)",

Для запису замовлення ми оновлюємо поле водія та статус, якщо водій ще не був призначений, а статус дорівнює Pending:

    UpdateExpression = "set DriverId = :DriverId, OrderStatus = :NewStatus",
    ConditionExpression = "attribute_not_exists(DriverId) AND OrderStatus=:OldStatus",

Операція, що дозволяє водієві взяти замовлення, відповідає нашим трьом вимогам:

Вона ідемпотентна. Повторне виконання методу не змінить стан бази даних і не викличе помилку. За це відповідає атрибут ClientRequestToken, який по суті є токеном ідемпотентності. Всі наступні запити до БД з тим самим ClientRequestToken будуть проігноровані. Це дозволяє, наприклад, водієві помилково натиснути два рази на кнопку прийняття замовлення.
Вона узгоджена. Записи замовлення та водія змінюються синхронно таким чином, що водій не може взяти замовлення в іншому статусі окрім Pending. Замовлення в статусі Pending завжди буде мати пов'язаного водія.
Вона атомарна. Запит або буде виконано повністю, або жодних змін до бази даних застосовуватись не буде.

Причини невдачі транзакцій

Якщо виконати даний метод але з некоректними даними (наприклад, водій намагається взяти в роботу чуже замовлення) він викличе помилку:

Amazon.DynamoDBv2.Model.TransactionCanceledException: 
'Transaction cancelled, please refer cancellation reasons for specific reasons...'

Транзакція може бути відмінена з декількох причин:

не виконується умова в ConditionExpression
одночасно виконується інша транзакція з тим самим записом
недостатня пропускна здатність (в нашому випадку це більше 5 викликів на секунду)
недостатньо прав для виконання запиту (це стосується лише DynamoDB в AWS)

Що робити, коли ви отримали помилку виконання транзакції? Варто спробувати виконати операцію повторно. Переконайтесь, що ви встановили токен ідемпотентності (поле ClientRequestToken), тоді SDK може спробувати самостійно повторити запит.

Якщо ж ваша транзакція після автоматичних спроб не вдалась, необхідно виконати повторну спробу на рівні логіки програми. Для цього необхідно перебудувати вихідний стан вашої програми і спробувати повторити транзакцію з новими умовами і новим бажаним кінцевим станом БД.

Для отримання нового вихідного стану вашої програми (синхронізація з базою даних) можна обрати один з трьох методів:

ReturnValuesOnConditionCheckFailure = ReturnValuesOnConditionCheckFailure.ALL_OLD - встановленя цього поля дозволяє при виконанні транзакції повернути значення атрибутів, якщо умова транзакції не була виконана.
Виконати TransactionGetItems, тобто транзакційно отримати всі необхідні дані самостійно.
Працювати далі за умови, що узгодженість даних буде врешті-решт досягнута, можливо, після виконання повторного запиту.

Порівняння з SQL

В SQL і деяких інших NoSQL рішеннях, таких як MongoDB, транзакції реалізовані в розмовному стилі. Першим викликом транзакція відкривається (BEGIN TRANSACTION), потім окремими викликами здійснюється модифікація даних (INSERT, UPDATE, DELETE). В кінці транзакція закривається (COMMIT TRANSACTION).

Такий розподіл координації між клієнтом і сервером накладає деякі обмеження на транзакції і робить їх реалізацію більш складною, а виконання - повільнішим.

Транзакції DynamoDB реалізовані в рамках одного виклику API.

Транзакції DynamoDB працюють виключно на сервері і у клієнта немає контролю за початком транзакції, її підтвердженням або відміною. Це робить транзакції DynamoDB дуже швидкими і розробнику не потрібно обирати між транзакційною БД і БД, яка масштабується горизонтально.

Також, з транзакціями DynamoDB неможливі взаємні блокування, оскільки використовується оптимістичний контроль одночасності. Завдяки цьому забезпечується низька затримка та висока доступність.

Недоліки транзакцій

Але в транзакцій DynamoDB є ряд обмежень, які варто врахувати:

Транзакції працюють лише в рамках одного регіону і одного акаунту AWS.
Транзакції можуть містити до десяти елементів, тобто можна оновити або додати не більше 10 записів за раз.
Транзакції споживають в два рази більше RCU або WCU, так як всередині використовуюється двофазний механізм: після виконання транзакції дані зчитуються ще раз для підтвердження їх коректності. Через це транзакційні виклики будуть в два рази дорожчими для споживача.

Висновок

Транзакції в DynamoDB допомагають розробникам:

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

Транзакції DynamoDB повністю підтримують ACID і в той же час можуть необмежено масштабуватись для забезпечення низької затримки та високої доступності даних.

Для .NET розробників Amazon пропонує низькорівневий SDK для доступу до DynamoDB, який повністю підтримує транзакції. Його використання дещо багатослівне і може заплутати новачка, але якщо ви плануєте працювати з великими навантаженнями на базу даних і в той же час не хочете позбавляти себе ACID транзакцій, DynamoDB може бути хорошим вибором.

Всі приклади коду можна знайти на Github

Оригінальна стаття на моєму сайті

Безкоштовна БД для програми ASP.NET Core

Oleksandr Martyniuk — Wed, 29 Jul 2020 18:17:02 +0000

В цій статті я розкажу про додатки Heroku, ми створимо базу даних PostgreSQL і налаштуємо її для підтримки процесу аутентифікації у веб-програмі ASP.NET Core. Це друга стаття циклу, тому варто ознайомитись з попередньою, в якій проєкт було створено і розгорнуто. Створена база даних не буде вимагати жодних фінансових витрат і гарно підходить для власного невеликого проєкту.

Передумови

Для успішного виконання наступних кроків вам необхідно зареєструвати акаунт в Heroku, якщо ви цього ще не зробили, та встановити такі інструменти:

Вся робота буде відбуватись в командному рядку. У якості редактору коду можна використовувати будь-який на ваш вибір.

У попередній статті ми створили просту програму ASP.NET Core, налаштували її для роботи в Heroku і розгорнули у хмарі. В цій статті ми модифікуємо створений код: додамо аутентифікацію та базу даних для зберігання інформації про користувачів. Готовий код можна знайти на Github.

Додатки Heroku

Heroku має безліч готових інструментів та сервісів, які називаються Add-ons (додатки). На сторінці з додатками можна знайти біля 150 сервісів, згрупованих по категоріям: Data Stores, Monitoring, Logging, Caching і т.д. Наприклад, тут є бази даних MySQL, Redis або MongoDB, сервіси повнотекстового пошуку Elasticsearch, стримінгу повідомлень Kafka, генерації PDF, обробки відео і багато іншого.

Ми будемо використовувати сервіс бази даних, який називається Heroku Postgres. Він доступний в декількох планах: від найпростішого Hobby Dev, який обмежений 20-ти одночасними з'єднаннями і 10000-ми рядками, до найбільш потужного Shield 8, який надає 488 GB оперативної пам'яті і 3TB сховища.

Масштабування Heroku Postgres

Heroku Postgres легко масштабується вертикально. Є можливість збільшувати розмір сховища і оперативної пам'яті, в якій знаходиться так званий hot-data-set, для швидшої оброки запитів. Для вертикального масштабування необхідно просто змінити план використання на вищий. Горизонтальне масштабування в Heroku Postgres можливе завдяки спеціальній конфігурації leader-follower. Вона дозволяє створювати декілька копій вашої бази даних, доступних лише для читання, які називаються follower. Дані в цих БД синхронізуються в реальному часі із основною базою, яка в термінології Heroku називається leader. Heroku забезпечує розташування баз даних follower та leader в різних дата-центрах, що підвищує їх надійність і дає можливість продовжити роботу вашій програмі у випадку виходу з ладу частини інфраструктури Heroku.

Нам цілком підйде план Hobby Dev, адже 10000 рядків - це більше ніж достатньо для демострації аутентифікації у веб-програмі. Для даного плану Heroku забезпечує доступність БД на рівні 99.5%. Для вищих планів доступність вища і сягає 99.95%.

Варто додати, що Heroku Postgres доступна у двох регіонах - Північній Америці та Європі. Ми створимо БД у Європі, так як наша веб-програма також розміщена на сервері у Європі.

Створення бази даних

Перейдіть в каталог з проєктом dotnet-app-heroku, що був створений в попередній статті. Перш за все, необхідно увійти в акаунт Heroku:

> heroku login

heroku: Press any key to open up the browser to login or q to exit: 
Opening browser to https://cli-auth.heroku.com/auth/cli/browser/9e58d2b7-dd08-4dca-968e-5ef0ddaf399d
Logging in... done
Logged in as elexander+heroku@ukr.net

Створимо базу даних, вказавши хобі план та ім'я нашої програми в Heroku

> heroku addons:create heroku-postgresql:hobby-dev --app dotnet-app-heroku

Creating heroku-postgresql:hobby-dev on ⬢ dotnet-app-heroku... free
Database has been created and is available
...
Created postgresql-horizontal-81849 as DATABASE_URL
Use heroku addons:docs heroku-postgresql to view documentation

Heroku записав інформацію про підключення до БД в змінну оточення DATABASE_URL. Пізніше ми зчитаємо її під час виконання програми і таким чином отримаємо інформацію про адресу серверу, ім'я користувача, його пароль і назву бази даних на сервері Postgres.

Ви не можете самостійно визначити параметри підключення, як ім'я користувача чи пароль, адже Heroku не надає вам окремий сервер бази даних, а дозволяє використовувати сервер спільно з іншими користувачами. До того ж, Heroku може змінити дані підключення, наприклад, адресу серверу, але в такому разі змінна оточення DATABASE_URL також буде оновлена. Враховуючи це, не варто зберігати рядок підключення в якомусь іншому місці, а тим більше у вихідному коді програми.

Перевіримо стан нашої бази даних і переконаймося, що план підключення дійсно не вимагає жодних витрат (Price = free):

> heroku addons

Owning App         Add-on                       Plan                         Price  State  
─────────────────  ───────────────────────────  ───────────────────────────  ─────  ───────
dotnet-app-heroku  postgresql-horizontal-81849  heroku-postgresql:hobby-dev  free   created

Налаштування програми для роботи з БД

Тепер, коли база даних створена, необхідно додати аутентифікацію в нашу програму ASP.NET Core. Нам знадобляться додаткові пакети для роботи з Microsoft Identity та EntityFramework Core. Їх можна додати командою dotnet add package:

> dotnet add package Microsoft.AspNetCore.Identity.EntityFrameworkCore
> dotnet add package Microsoft.AspNetCore.Identity.UI     
> dotnet add package Microsoft.EntityFrameworkCore.Design
> dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL

info : PackageReference for package 'Microsoft.AspNetCore.Identity.EntityFrameworkCore' version '3.1.6' added
info : PackageReference for package 'Microsoft.AspNetCore.Identity.UI' version '3.1.6' added
info : PackageReference for package 'Microsoft.EntityFrameworkCore.Design' version '3.1.6' added
info : PackageReference for package 'Npgsql.EntityFrameworkCore.PostgreSQL' version '3.1.4' added

Тепер додамо клас ApplicationDbContext, це вкрай важлива частина при роботі з EntityFramework і точка доступу до нашої бази даних. Цей клас повинен наслідуватись від IdentityDbContext, тому що ми хочемо, щоб Microsoft Identity був прив'язаний до нашого контексту, а отже дані користувачів зберігались у створеній нами базі даних.

Створіть новий файл ApplicationDbContext.cs з таким вмістом:

using Microsoft.AspNetCore.Identity.EntityFrameworkCore;
using Microsoft.EntityFrameworkCore;

namespace DotnetAppHeroku
{
    public class ApplicationDbContext : IdentityDbContext
    {
        public ApplicationDbContext(DbContextOptions<ApplicationDbContext> options)
            : base(options)
        {
        }
    }
}

Наразі EntityFramework не знає як працювати з конкретною базою даних, адже це універсальний фреймворк, що надає функції маппінгу об'єктів C# в записи бази даних. Тож нам необхідно використати відповідний драйвер. Для Postgres найбільш популярним є пакет Npgsql. В цьому дописі ви можете подивитись як підключити базу даних PostgreSQL з EntityFramework Core до вашої програми. Як ви бачите, для конфігурації драйверу необхідно передати рядок з'єднання у форматі Host=my_host;Database=my_db;Username=my_user;Password=my_pw. Де взяти ці данні? Запитаємо конфігурацію нашої програми у Heroku.

> heroku config --app dotnet-app-heroku

=== dotnet-app-heroku Config Vars
DATABASE_URL: postgres://zevxwvnofzdqgh:6fbfa85e483c547461d8dd1b1cdb5c3889ee11016ac278626056d317f20eb590@ec2-52-22-216-69.compute-1.amazonaws.com:5432/d67ogunajtekdt

Як бачите, Heroku створив змінну оточення DATABASE_URL, але формат рядка з'єднання дещо відрізняється від того, що очікує драйвер Npgsql. PostgreSQL використовує загальноприйнятий стандарт URL для підключення до БД. Цей формат описаний в документації:

postgresql://[user[:password]@][netloc][:port][,...][/dbname]

Нам необхідно додати трохи коду, щоб перетворити URL, який пропонує Heroku, в конфігурацію з'єднання, яку вимагає EntityFramework.

Додайте файл ConfigurationExtensions.cs з наступним вмістом:

using System;
using Microsoft.Extensions.Configuration;

namespace DotnetAppHeroku
{
    public static class ConfigurationExtensions
    {
        public static string GetConnectionString(this IConfiguration configuration)
        {
            var uri = new UriBuilder(configuration["DATABASE_URL"]);
            return $"Host={uri.Host};" + 
                   $"Database={uri.Path.Remove(0,1)};" + 
                   $"Username={uri.UserName};" + 
                   $"Password={uri.Password};" + 
                    "sslmode=Require;" + 
                    "Trust Server Certificate=true;";
        }
    }
}

Два останні параметри sslmode=Require та Trust Server Certificate=true; необхідні, адже Heroku підтримує тільки з'єднання, що захищені через SSL.

Маючи метод розширення, що повертає рядок для з'єднання, можемо налаштувати контекст бази даних та сервіси Identity:

Змініть метод ConfigureServices у файлі Startup.cs, щоб він містив дану конфігурацію:

public void ConfigureServices(IServiceCollection services)
{
    services.AddDbContext<ApplicationDbContext>(options =>
        options.UseNpgsql(
            Configuration.GetConnectionString()));
    services.AddDefaultIdentity<IdentityUser>(options =>
        options.SignIn.RequireConfirmedAccount = true)
            .AddEntityFrameworkStores<ApplicationDbContext>();

    services.AddRazorPages();
}

Також додайте аутентифікацію в методі Configure:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
...
    app.UseAuthentication();
    app.UseAuthorization();
...

Тепер підключення до бази даних налаштоване і ми можемо згенерувати таблиці, індекси та інші об'єкти БД, що потребує Identity:

> dotnet ef migrations add InitialMigration

Build started...
Build succeeded.
Done. To undo this action, use 'ef migrations remove'

Застосуємо створену міграцію до бази даних:

> dotnet ef database update

Build started...
Build succeeded.
Done.

Після цього можемо переконатись, що база даних була успішно створена та містить всі необхідні таблиці. Для цього я підключився до бази даних через менеджер HeidiSQL:

Налаштування інтерфейсу аутентифікації

Нам залишилось змінити інтерфейс веб-програми, аби зробити можливою реєстрацію користувача і його наступний вхід:

Додати новий шаблон для сторінки реєстрації та входу.
Підключити доданий шаблон до головної сторінки.
Додати Identity UI до нашої програми.

Тож додамо в папку Pages/Shared файл _LoginPartial.cshtml:

@using Microsoft.AspNetCore.Identity
@inject SignInManager<IdentityUser> SignInManager
@inject UserManager<IdentityUser> UserManager

<ul class="navbar-nav">
@if (SignInManager.IsSignedIn(User))
{
    <li class="nav-item">
        <a  class="nav-link text-dark" asp-area="Identity" asp-page="/Account/Manage/Index" title="Manage">Hello @User.Identity.Name!</a>
    </li>
    <li class="nav-item">
        <form class="form-inline" asp-area="Identity" asp-page="/Account/Logout" asp-route-returnUrl="@Url.Page("/", new { area = "" })" method="post" >
            <button  type="submit" class="nav-link btn btn-link text-dark">Logout</button>
        </form>
    </li>
}
else
{
    <li class="nav-item">
        <a class="nav-link text-dark" asp-area="Identity" asp-page="/Account/Register">Register</a>
    </li>
    <li class="nav-item">
        <a class="nav-link text-dark" asp-area="Identity" asp-page="/Account/Login">Login</a>
    </li>
}
</ul>

У файлі _Layout.cshtml знайдіть елемент div з класом "navbar-collapse" і додайте рядок відразу за ним:

<partial name="_LoginPartial" />

Створіть папку Areas\Identity\Pages\ і в ній файл _ViewStart.cshtml:

@{
    Layout = "/Pages/Shared/_Layout.cshtml";
}

Додайте до файлу імпорту _ViewImports.cshtml простір імен для Microsoft Identity:

@using Microsoft.AspNetCore.Identity

Тепер можна виконати build проєкту і переконатись, що все працює. Зробіть коміт і пуш у репозиторій Heroku. Ваша програма буде автоматично розгорнута (адже ми сконфігурували це в першій статті) і через деякий час доступна за адресою http://dotnet-app-heroku.herokuapp.com/. Спробуйте зареєструвати нового користувача і потім увійти від його імені:

Статистика використання БД

Давайте переглянемо деяку статистику по базі даних, що дасть нам уявлення про те, як вона використовується і які обмеження порушені:

> heroku pg:info

=== DATABASE_URL
Plan:                  Hobby-dev
Status:                Available
Connections:           1/20
PG Version:            12.3
Created:               2020-07-28 16:28 UTC
Data Size:             8.5 MB
Tables:                8
Rows:                  2/10000 (In compliance)
Fork/Follow:           Unsupported
Rollback:              Unsupported
Continuous Protection: Off
Add-on:                postgresql-horizontal-81849

Як бачимо, на даний момент є одне з'єднання і використано 8.5 MB сховища. Також створено 8 таблиць і 2 рядки: перший рядок для новоствореного користувача і другий - це запис в таблиці з міграціями EntityFramework Core.

Висновок

Ми побачили, як:

Створити базу даних PostgreSQL в Heroku.
Налаштувати EntityFramework Core та Microsoft Identity для роботи з базою даних.
Додати елементи інтерфейсу для реєстрації та входу користувача.
Переглянути статистику використання бази даних.

Репозиторій на Github

Більш детальну інформацію про Heroku Postgres ви можете знайти в офіційній документації.

Оригінальна стаття на моєму сайті.

Зустрічайте C# 9.0

Oleksandr Martyniuk — Sun, 14 Jun 2020 13:51:24 +0000

Це переклад статті "Welcome to C# 9.0" Медса Тоерсена - працівника Microsoft і головного дизайнера мови C#.

C# 9.0 набуває форм і я хочу поділитись нашим баченням найбільш важливих можливостей, які ми додаємо в наступну версію мови.

З кожною новою версією ми прагнемо зробити мову більш ясною і простою для загальних сценаріїв використання і C# 9.0 не є винятком. Цього разу нашим фокусом є забезпечення лаконічності в представленні даних та підтримка механізмів їх незмінності.

Ну що ж, поїхали!

Властивості з ініціалізацією

Ініціалізатори об'єктів надзвичайно корисні: вони дають програмісту дуже гнучку і, водночас, зрозумілу форму створення об'єктів. Вони особливо зручні для створення вкладених об'єктів, коли ціла ієрархія створюється однією командою. Ось приклад:

new Person
{
    FirstName = "Scott",
    LastName = "Hunter"
}

Ініціалізатори об'єктів також звільняють автора класу від написання шаблонного коду конструкторів. Все, що потрібно, - лише створити певні властивості!

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

Проте сьогодні є одне велике обмеження: щоб ініціалізатори працювали, властивості повинні бути змінюваними (mutable). Ініціалізатори працюють завдяки виклику конструктора (без параметрів в даному випадку) і наступному присвоєнню значень через виклик сетерів властивостей.

Властивості з ініціалізацією виправлять це! Вони визначають init аксесор який дуже схожий на set аксесор, але може викликатись лише під час ініціалізації об'єкту:

public class Person
{
    public string FirstName { get; init; }
    public string LastName { get; init; }
}

З таким підходом код, написаний вище, все ще коректний, але всі наступні присвоєння значень властивостям FirstName і LastName викличуть помилку.

Init аксесори та поля лише для читання

Так як init аксесори можуть викликатись лише під час ініціалізації, їм дозволено змінювати поля для читання того ж класу, точно так, як ви зараз можете зробити це у конструкторі.

public class Person
{
    private readonly string firstName;
    private readonly string lastName;

    public string FirstName 
    { 
        get => firstName; 
        init => firstName = (value ?? throw new ArgumentNullException(nameof(FirstName)));
    }
    public string LastName 
    { 
        get => lastName; 
        init => lastName = (value ?? throw new ArgumentNullException(nameof(LastName)));
    }
}

Класи даних (record)

Властивості з ініціалізацією чудово підходять, якщо ви хочете зробити певну властивість об'єкту незмінною. Якщо ж ви хочете зробити незмінним весь об'єкт, щоб він поводив себе як екземпляр типу-значення, вам необхідно визначити його як клас даних (record):

public data class Person
{
    public string FirstName { get; init; }
    public string LastName { get; init; }
}

Ключове слово data у визначенні позначає його як клас даних. Це додає йому певної поведінки характерної для типу-значення, яку ми розглянемо далі. Загалом, класи даних краще розглядати як "значення" (дані), а не як об'єкти. Вони не створені, щоб мати змінюваний стан. Натомість, ви виражаєте зміни у часі, створюючи нові екземпляри класу даних, що відображують новий стан. Класи даних визначаються не унікальністю посилання, а тотожністю вмісту.

Вираз `with`

При роботі з незмінними даними, загальний підхід полягає у створенні копії для відображення нового стану об'єкту. Для прикладу, якщо наша особа захоче змінити своє прізвище, ми реалізуємо це через створення нового об'єкту, що буде копією старого окрім зміненого прізвища. Цю техніку часто називають неруйнівною мутацією. Замість того, щоб змінювати особу з часом клас даних відображує стан особи в конкретний момент часу.

Щоб програмувати в такому стилі було легше, класи даних підтримують новий тип виразу - with:

var otherPerson = person with { LastName = "Hanselman" };

With-вирази використовують синтаксис ініціалізаторів, щоб визначити, чим будуть відрізнятись новий і старий об'єкти. Ви можете задати відразу декілька властивостей.

Клас даних неявно включає захищений "конструктор копіювання" - це конструктор, який бере об'єкт класу даних, що існує, і копіює його поля одне за одним в новий об'єкт:

protected Person(Person original) { /* копіює всі поля */ } // автозгенерований

Вираз with викликає конструктор копіювання і потім застосовує ініціалізатор для перевизначених властивостей, але вже до проініціалізованих раніше даних.

Якщо вас не влаштовує згенерований конструктор копіювання, ви можете визначити свій власний і він так само буде використовуватись виразом with.

Порівняння за значенням

Всі об'єкти наслідують віртуальний метод Equals(object) від класу object. Він використовується статичним методом Object.Equals(object, object) коли обидва параметри не дорівнюють null.

Структури перевизначають його, щоб отримати "порівняння за значенням". Це коли поля структури порівнюються рекурсивно через виклик Equals. Класи даних роблять так само.

Це означає те, що згідно з їхньою "значеністю", два об'єкти класу даних можуть бути рівними, будучи різними екземплярами одного типу. Для прикладу, якщо ми повернемо назад прізвище у раніше зміненої особи:

var originalPerson = otherPerson with { LastName = "Hunter" };

Тепер ми мали б ReferenceEquals(person, originalPerson) = false (це різні екземпляри), але Equals(person, originalPerson) = true (вони містять однакові дані).

Якщо вам не підходить порівняння по полях, що визначається початково, ви можете написати своє. Але треба бути обережним і розуміти, як працює порівняння за значеннями в структурах, особливо якщо є наслідування (до якого ми ще повернемося нижче).

Поряд з перевизначенням Equals перевизначається також GetHashCode(), бо вони працюють у парі.

Поля класів даних

Класи даних задумувались незмінюваними і такими, що містять лише публічні властивості з ініціалізаторами. Класи даних можуть змінюватись в не деструктивний спосіб завдяки with-виразам. Для того, щоб спростити визначення класів даних для цього поширеного випадку, синтаксис класу даних змінює семантику, що несе string FirstName. Замість неявного приватного поля, як це було б у визначенні класу чи структури, в синтаксисі класу даних це означає публічну автовластивість з ініціалізатором! Таким чином, визначення:

public data class Person { string FirstName; string LastName; }

Означає в точності те ж, що ми мали раніше:

public data class Person
{
    public string FirstName { get; init; }
    public string LastName { get; init; }
}

Ми вважаємо, це дозволяє зробити визначення класу даних чистим і красивим. Якщо вам дійсно потрібне приватне поле, ви завжди можете додати модифікатор private явно:

private string firstName;

Позиційні класи даних

Інколи зручно використовувати більш позиційний підхід до класів даних, при якому дані передаються через аргументи конструктора і можуть бути отримані назад завдяки позиційному деконструюванню.

Абсолютно допустимим є визначення власного конструктора і деконструктора класу даних:

public data class Person 
{ 
    string FirstName; 
    string LastName; 
    public Person(string firstName, string lastName) 
      => (FirstName, LastName) = (firstName, lastName);
    public void Deconstruct(out string firstName, out string lastName) 
      => (firstName, lastName) = (FirstName, LastName);
}

Але існує набагато коротший синтаксис для вираження того самого (зверніть увагу на регістр імен параметрів):

public data class Person(string FirstName, string LastName);

Цей запис визначає публічні автовластивості і конструктор з деконструктором, тож ви можете написати:

var person = new Person("Scott", "Hunter"); // позиціне конструювання
var (f, l) = person;                        // позиціне деконструювання

Якщо вам не подобається згенерована автовластивіть, ви можете натомість визначити свою власну з тим же іменем, і згенеровані конструктор та деконструктор будуть її використовувати.

Класи даних і змінюваний стан

Семантика значення не дуже добре поєднується зі змінюваним станом. Уявіть, ми помістили об'єкт класу даних в словник. Його подальший пошук залежить від Equals та (інколи) GethashCode. Але, якщо клас даних змінює свій стан, він також змінює свою еквівалентність! Ми можемо не знайти його знову! В реалізації хеш таблиці це може пошкодити структуру даних, бо розміщення об'єкту грунтується на хеш коді, який він має в момент запису у таблицю.

Напевно, є допустимі приклади використання змінюваного стану класів даних, зокрема для кешування. Але щоб перевизначити поведінку так, щоб ігнорувати цей стан, доведеться докласти значних зусиль.

With-вираз та наслідування

Порівняння за значенням та недеструктивна мутація значно ускладнюються, коли поєднуються з наслідуванням. Давайте додамо похідний клас даних Student до раніше розглянутого прикладу:

public data class Person { string FirstName; string LastName; }
public data class Student : Person { int ID; }

Почнемо наш приклад зі створення екземпляру Student, але збережемо його у змінній типу Person:

Person person = new Student { FirstName = "Scott", LastName = "Hunter", ID = GetNewId() };
otherPerson = person with { LastName = "Hanselman" };

В останньому рядку з with-виразом компілятор не знає, що person фактично містить екземпляр Student. Тим не менш, новий екземпляр otherPerson не був би коректною копією, якби він не був екземпляром Student і не містив той самий ID, що і оригінальний об'єкт.

C# робить це за нас. Класи даних містять прихований віртуальний метод, якому доручено клонування цілого об'єкту. Кожен похідний тип класу даних перевизначає цей метод і викликає конструктор копіювання для цього типу. Цей конструктор викликає аналогічний конструктор базового типу. With-вираз просто викликає цей прихований метод клонування і застосовує ініціалізатор об'єкту до результату.

Порівняння за значенням і наслідування

Подібно до реалізації with-виразів, порівняння за значенням також повинно бути "віртуальним" в тому сенсі, що для порівняння двох екземплярів типу Student повинні бути порівняні всі поля типу Student, навіть якщо тип посилання на момент порівняння - це базовий тип, наприклад, Person. Цього легко досягти, перевизначивши метод Equals, що наразі вже є віртуальним.

Проте, є ще одна проблема з еквівалентністю. Що, як ви порівнюєте два різних підтипи базового типу Person? Ми не можемо дозволити вибирати метод Equal якого типу використовувати: еквівалентність повинна бути симетричною. Тож результат не повинен залежати від порядку об'єктів. Іншими словами, вони повинні самі узгодити, чию еквівалентність застосовувати.

Цей приклад ілюструє проблему:

Person person1 = new Person { FirstName = "Scott", LastName = "Hunter" };
Person person2 = new Student { FirstName = "Scott", LastName = "Hunter", ID = GetNewId() };

Чи рівні ці два об'єкти? person1 може думати, що так, адже person2 має всі поля типу Person з тими ж значеннями. Але person2 з цим не погодиться! Ми повинні бути впевненими, що вони обоє розуміють, що вони все ж різні об'єкти.

І знову, C# подбав про це. Спосіб, в який це реалізовано: класи даних мають віртуальну захищену властивість EqualityContract. Кожен похідний клас даних перевизначає її і для того, щоб два класи даних були однаковими, вони повинні мати один і той самий EqualityContract.

Програми найвищого рівня

Написання простої програми на C# вимагає значної кількості шаблонного коду:

using System;
class Program
{
    static void Main()
    {
        Console.WriteLine("Hello World!");
    }
}

Це не тільки важко сприймати тим, хто тільки починає вивчати мову, а ще й захаращує код та додає зайві рівні відступів.

Натомість, в C# 9.0 ви можете просто писати вашу програму на найвищому рівні:

using System;

Console.WriteLine("Hello World!");

Будь-які вирази дозволені. Програма може початися відразу після списку using і перед визначенням будь якого типу чи простору імен. Але ви можете так робити тільки в одному файлі, точно так як зараз ви можете мати лише один метод Main.

Якщо ви хочете повернути код статусу, ви можете це зробити. Якщо ви хочете очікувати задачу з await, ви можете це зробити. І якщо ви хочете отримати доступ до аргументів командного рядку, вони доступні як "магічний" параметр args.

Локальні функції - це також вирази і вони так само дозволені на найвищому рівні. Але, у разі виклику їх поза областю програми найвищого рівня, буде згенеровано помилку.

Вдосконалене співставлення за шаблоном

Декілька нових типів шаблонів порівняння були додані в C# 9.0. Давайте подивимось на них в контексті цього фрагменту коду з навчального посібника:

public static decimal CalculateToll(object vehicle) =>
    vehicle switch
    {
       ...

        DeliveryTruck t when t.GrossWeightClass > 5000 => 10.00m + 5.00m,
        DeliveryTruck t when t.GrossWeightClass < 3000 => 10.00m - 2.00m,
        DeliveryTruck _ => 10.00m,

        _ => throw new ArgumentException("Not a known vehicle type", nameof(vehicle))
    };

Спрощений шаблон типу

Наразі, шаблон типу вимагає визначення змінної, навіть якщо ця змінна ігнорується, як у випадку з _. У прикладі вище це DeliveryTruck _. Але тепер ви можете просто написати тип:

DeliveryTruck => 10.00m,

Шаблони порівняння

C# 9.0 вводить шаблони на основі операторів порівняння <, <= і т.ін. Тож тепер ви можете написати чатину з DeliveryTruck з наведеного вище шаблону як вкладений switch вираз:

DeliveryTruck t when t.GrossWeightClass switch
{
    > 5000 => 10.00m + 5.00m,
    < 3000 => 10.00m - 2.00m,
    _ => 10.00m,
},

Тут > 5000 і < 3000 - це шаблони порівняння.

Логічні шаблони

Нарешті ви можете поєднувати шаблони з логічними операторами and, or і not. Вони записані словами, щоб уникнути плутанини з операторами у виразах. Для прикладу, випадок з вкладеним switch виразом вище можна переписати розташувавши діапазони по зростанню, як наведено нижче:

DeliveryTruck t when t.GrossWeightClass switch
{
    < 3000 => 10.00m - 2.00m,
    >= 3000 and <= 5000 => 10.00m,
    > 5000 => 10.00m + 5.00m,
},

Середній вираз тут використовує and, щоб поєднати два шаблони порівняння в єдиний шаблон, що відображує діапазон.

Шаблон not може використовуватись спільно з констатним шаблоном null, як not null. Для прикладу, ми можемо розділити обробку невідомого випадку в залежності від того, чи дорівнює він null:

not null => throw new ArgumentException($"Not a known vehicle type: {vehicle}", nameof(vehicle)),
null => throw new ArgumentNullException(nameof(vehicle))

Також not може бути корисним з оператором if, умова якого містить вираз is замість потворних подвійних дужок:

if (!(e is Customer)) { ... }

Ви можете просто написати

if (e is not Customer) { ... }

Вдосконалене приведення до цільового типу

"Приведенням до цільового типу" ми називаємо ситуацію, коли вираз отримує свій тип з контексту, в якому він використовується. Для прикладу null чи лямбда-вирази завжди використовують приведення до цільового типу.

В C# 9.0 деякі вирази, які до цього не використовували приведення до цільового типу, отримали можливість визначати тип з контексту.

Приведення у виразі `new`

Вираз new у C# завжди вимагав вказування типу (за винятком неявно типізованих масивів). Тепер ви можете пропустити тип, якщо змінна, якій присвоюється вираз, вже його має.

Point p = new (3, 5);

Приведення у виразах `??` та `?:`

Інколи умовні вирази ?? та ?: не мають явного спільного типу між різними гілками виконання. Такі випадки зараз не компілюються, але C# 9.0 буде дозволяти їх, якщо існує цільовий тип, до якого обидва результати можуть бути приведені.

Person person = student ?? customer; // спільний базовий тип
int? result = b ? 0 : null; // значений nullable тип

Коваріантні результати

Інколи корисно якось виразити те, що перевизначений метод похідного класу повертає більш конкретний тип, ніж визначено у базовому класі. C# 9.0 дозволяє таке:

abstract class Animal
{
    public abstract Food GetFood();
    ...
}
class Tiger : Animal
{
    public override Meat GetFood() => ...;
}

І навіть більше…

Найкраще місце, щоб ознайомитися з повним переліком майбутніх можливостей в C# 9.0 і слідкувати за їх реалізацією - це сторінка Статус реалізації нових можливостей мови в репозиторії Roslyn (C#/VB Compiler) на GitHub.

Приємного кодування!

Оригінал перекладу на моєму сайті.

Обмеження одночасних потоків в C#

Oleksandr Martyniuk — Fri, 29 May 2020 15:29:58 +0000

Це переклад допису Constraining Concurrent Threads in C# Марка Хіта - Microsoft MVP, Software Architect в NICE Systems і автора кількох бібліотек з відкритим кодом.

Припустимо, в C# ми маємо виконати певну кількість задач, які наразі виконуються послідовно і які ми хочемо прискорити, запустивши їх паралельно. Для прикладу, уявіть, що ми завантажуємо купу веб сторінок:

var urls = new [] { 
        "https://github.com/naudio/NAudio", 
        "https://twitter.com/mark_heath", 
        "https://github.com/markheath/azure-functions-links",
        "https://pluralsight.com/authors/mark-heath",
        "https://github.com/markheath/advent-of-code-js",
        "http://stackoverflow.com/users/7532/mark-heath",
        "https://mvp.microsoft.com/en-us/mvp/Mark%20%20Heath-5002551",
        "https://github.com/markheath/func-todo-backend",
        "https://github.com/markheath/typescript-tetris",
};
var client = new HttpClient();
foreach(var url in urls)
{
    var html = await client.GetStringAsync(url);
    Console.WriteLine($"retrieved {html.Length} characters from {url}");
}

Щоб запустити їх паралельно, ми могли б запустити для кожного завантаження Task через Task.Run і очікувати, поки вони всі завершаться. Але як бути, якщо ми хочемо обмежити кількість одночасних завантажень? Припустимо, ми хочемо обмежити їх чотирма.

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

В цьому дописі я хочу розглянути чотири різні способи вирішення цієї проблеми.

Спосіб 1 - ConcurrentQueue

Перший спосіб був для мене звичним підходом протягом багатьох років. Основна ідея - поставити всі завдання в чергу і обробляти їх декількома потоками, які читають з черги послідовно. Це непоганий і доволі простий підхід, який, проте, вимагає блокування черги, так як вона буде використовуватись декількома потоками одночасно. В цьому прикладі я використовую ConcurrentQueue, щоб зробити це потокобезпечно.

Ми заповнюємо чергу адресами сторінок для завантаження і запускаємо одну задачу для кожного потоку, які в циклі намагаються читати з черги. Потоки закінчуються, коли не лишається елементів в черзі. Ми створюємо список таких задач і потім використовуємо Task.WhenAll, щоб дочекатись їх завершення. Вони всі завершаться, коли завершиться останнє завантаження.

var maxThreads = 4;
var q = new ConcurrentQueue<string>(urls);
var tasks = new List<Task>();
for(int n = 0; n < maxThreads; n++)
{
    tasks.Add(Task.Run(async () => {
        while(q.TryDequeue(out string url)) 
        {
            var html = await client.GetStringAsync(url);
            Console.WriteLine($"retrieved {html.Length} characters from {url}");
        }
    }));
}
await Task.WhenAll(tasks);

Мені досі подобається цей підхід, адже він концептуально простий. Проте, можуть бути певні незручності, якщо продовжувати додавати нові завдання після того, як ми почали їх обробку. Причина в тому, що потоки, що читають з черги, можуть завершитись зарано.

Спосіб 2 - SemaphoreSlim

Інший підхід (на який мене надихнула ця відповідь зі StackOverflow) - це скористатись SemaphoreSlim з initialCount рівним максимальному числу потоків. Потім ми використовуємо WaitAsync для очікування моменту, коли можна буде запустити наступну задачу. Таким чином, ми відразу стартуємо чотири задачі, але далі повинні дочекатись, поки якась з них завершиться перед тим, як виконається WaitAsync і з'явиться можливість додати наступну.

var allTasks = new List<Task>();
var throttler = new SemaphoreSlim(initialCount: maxThreads);
foreach (var url in urls)
{
    await throttler.WaitAsync();
    allTasks.Add(
        Task.Run(async () =>
        {
            try
            {
                var html = await client.GetStringAsync(url);
                Console.WriteLine($"retrieved {html.Length} characters from {url}");
            }
            finally
            {
                throttler.Release();
            }
        }));
}
await Task.WhenAll(allTasks);

Цей код трішки наочніший, ніж підхід з ConcurrentQueue. Також він призводить до ситуації, коли ми отримаємо список з потенційно великою кількістю вже завершених задач. Але цей підхід має перевагу, якщо під час виконання задач ви генеруєте нові.

Для прикладу, для передачі великого файлу до Azure Blob Storage ви можете послідовно читати порціями в 1MB, але бажаєте завантажувати їх по чотири одночасно. Ви не хочете читати всі порції файлу до моменту поки їх не потрібно буде відправити, оскільки це потребує багато часу і пам'яті. З даним підходом ми можемо створювати задачу саме в той момент, коли потік звільнився і готовий завантажувати наступну порцію. Це набагато ефективніше.

Спосіб 3 - Parallel.ForEach

Метод Parallel.ForEach, на перший погляд, ідеальне вирішення цієї проблеми. Ви можете просто вказати MaxDegreeOfParallelism і визначити Action, що буде виконуватись для кожного елементу у вашому IEnumerable:

var options = new ParallelOptions() { MaxDegreeOfParallelism = maxThreads };
Parallel.ForEach(urls, options, url =>
    {
        var html = client.GetStringAsync(url).Result;
        Console.WriteLine($"retrieved {html.Length} characters from {url}");
    });

Виглядає гарно і просто, чи не так? Проте, тут є приховані граблі. Так як Parallel.ForEach приймає Action, а не Func<T>, його можна використовувати лише зі синхронними функціями. Ви могли помітити, що ми викрутились, додавши .Result після GetStringAsync, але це небезпечний прийом, який використовувати не рекомендується.

Тож, на жаль, цей підхід можна задіяти, якщо у вас є синхронні методи, які необхідно виконати паралельно. Існує Nuget пакет, що реалізує асинхронну версію Parallel.ForEach, тож ви можете спробувати його, якщо бажаєте отримати щось на кшталт:

await uris.ParallelForEachAsync(
    async url =>
    {
        var html = await httpClient.GetStringAsync(url);
        Console.WriteLine($"retrieved {html.Length} characters from {url}");
    },
    maxDegreeOfParalellism: maxThreads);

Спосіб 4 - політика "Перемичка" бібліотеки Polly

Останій варіант - скористатись політикою ізоляції Перемичка (Bulkhead) бібліотеки Polly. Ця політика обмежує кількість одночасних викликів і, за бажанням, дозволяє ставити в чергу виклики, що потрапили під обмеження.

Нижче ми налаштовуємо політику перемички з обмеженням на число одночасних викликів та без обмеження на кількість задач, що очікують свого запуску в черзі. Далі ми просто викликаємо метод ExecuteAsync в циклі, дозволяючи або негайно стартувати задачу, або поставити її в чергу, якщо задач забагато.

var bulkhead = Policy.BulkheadAsync(maxThreads, Int32.MaxValue);
var tasks = new List<Task>();
foreach (var url in urls)
{
    var t = bulkhead.ExecuteAsync(async () =>
    {
        var html = await client.GetStringAsync(url);
        Console.WriteLine($"retrieved {html.Length} characters from {url}");
    });
    tasks.Add(t);
}
await Task.WhenAll(tasks);

Аналогічно до інших згаданих способів ми зберігаємо задачі до списку і використовуємо Task.WhenAll для очікування їх завершення. Варто зазначити, що даний шаблон насправді створений для ситуацій, в яких одночасні завдання генеруються декількома потоками (для прикладу, з контролерів ASP.NET). Вони можуть просто використовувати спільну політику перемички і ви лише запускаєте задачу з await bulkhead.ExecuteAsync(...). Тож цей підхід дуже простий і добре підходить для тих ситуацій, для яких він був спроєктований.

Висновок

Паралелізація може значно прискорити виконання вашої програми. Але, якщо вона використовується неправильно, то може сама створити більше проблем, аніж розв'язує. Ці шаблони дозволяють вам використовувати обмежену кількість потоків для обробки групи задач. Єдине, з чим необхідно визначитись, - це спосіб, у який завдання створюються. Вони наявні з самого початку, чи створюються в процесі, в момент, коли вже відбувається обробка попередніх завдань? Також питання: ви генеруєте ці задачі послідовно з одного потоку чи декілька потоків мають можливість додавати задачі?

Звичайно, я впевнений, що існують інші красиві способи розв'язання цієї проблеми, тож дайте знати в коментарях, який ваш улюблений.

Коментар Стівена Клірі

Від перекладача:

В обговорення цього допису завітав Стівен Клірі - автор відомої книги Concurrency in C# Cookbook. Я думаю, його коментар варто перекласти також.

Я думаю, важливо розрізняти синхронну та асинхронну конкурентність. Синхронна конкурентність (паралелізм) це використання декількох потоків, і це правильний вибір, якщо ви маєте код, що інтенсивно використовує центральний процесор (CPU-bound). Асинхронна конкурентність - це форма виконання, що не вимагає додаткових потоків, і це правильний вибір, коли ви маєте код, що працює з введенням-виведенням (I/O-bound).

Наведений приклад (завантаження веб сторінок) - це введення-виведення, а отже, тут краще підходить асинхронна конкурентність. Ось чому способи з Parallel / ConcurrentQueue / BlockingCollection врешті виглядають незграбно: блокування потоків і т.ін. Вони справді незамінні у світі синхронної конкуренції і з ними, звісно, можна ров'язати дану проблему, але цей розв'язок буде менш ефективним.

Для завантаження більше підходять методи асинхронної конкурентності. Вони включають використання SemaphoreSlim з Task.WhenAll (але без необов'язкового Task.Run), і TPL ActionBlock / BufferBlock (працюють як асинхронна ConcurrentQueue).

Наприклад, підхід з SempahoreSlim може бути спрощений до такого:

var throttler = new SemaphoreSlim(initialCount: maxThreads);
var tasks = urls.Select(async url =>
{
    await throttler.WaitAsync();
    try
    {
        var html = await client.GetStringAsync(url);
        Console.WriteLine($"retrieved {html.Length} characters from {url}");
    }
    finally
    {
        throttler.Release();
    }
});
await Task.WhenAll(tasks);

І його навіть можна спростити ще більше, якщо визначити метод розширення LockAsync для SemaphoreSlim.

Оригінальний допис на моєму сайті

Безкоштовна публікація ASP.NET Core програми

Oleksandr Martyniuk — Fri, 22 May 2020 19:03:47 +0000

В багатьох програмістів є власні проєкти на .NET Core, які в певний момент хочеться показати іншим. Бажано, щоб розгортання відбувалось просто і швидко, а хостинг був безкоштовним. В цій замітці я розкажу, як розгортати проєкти на .NET Core в Heroku з безперервною доставкою, не вкладаючи в це ні копійки.

Передумови

Для роботи нам потрібні будуть .NET Core SDK (у мене встановлено версію 3.1), Git для роботи з репозиторієм та Heroku CLI для роботи з Heroku. Сподіваюсь, ви вже маєте .NET Core та Git. Як встановити Heroku CLI я розкажу далі.

Heroku та безкоштовний dyno

Heroku - хмарний провайдер, що дозволяє запускати веб програми і сервіси написані на мовах Java, Node.JS, Scala, Python, PHP, Ruby, Go та Clojure. Heroku була однією з перших хмарних платформ. В її основі лежить система віртуалізації побудована на ізольованих Linux контейнерах, які в Heroku називаються dyno. Тобто, dyno - це ніби окремий віртуальний комп'ютер, що виконує вашу програму на серверах Heroku.

Безкоштовно Heroku надає один dyno з наступними характеристиками:

512 MB оперативної пам'яті
550 годин виконання кожного місяця

Dyno бувають двох типів:

web - для програм що очікують вхідних HTTP запитів
worker - для програм, що виконують операції у фоні

Якщо ви використовуєте лише безкоштовний dyno, варто зауважити, що Heroku призупиняє виконання dyno після 30 хв бездіяльності. Тобто, якщо за останні 30 хв. до вашого web dyno не надійшло жодного запиту, він буде поставлений на паузу. Прокинеться він при наступному запиті. Для користувача це може виглядадти так, ніби сайт в браузері перший раз відкривається довго. В той час, поки ваш dyno спить, він НЕ споживає вільні години. Іншими словами, якщо ваш тестовий проєкт досить навантажений і обслуговує користувачів 24 години на добу вам вистачить вільних хвилин лише на 23 дні в місяць.

Heroku дає можливість розширити кількість вільних хвилин до 1000 просто вказавши реквізити банківської карти в налаштуваннях, без жодних списань коштів. Це дає можливість працювати одному free dyno без зупинки 24/7 або двом-трьом free dyno, якщо навантаження на сайт не постійне.

Налаштування Heroku CLI

Давайте створимо безкоштовний акаунт Heroku і розгорнемо в ньому просту ASP.NET Core програму. Після реєстрації і підтвердження поштової адреси завантажте Heroku CLI. Це консольна утиліта, що спростить створення і розгортання веб програми без відвідування сайту. Далі ми будемо все робити через командний рядок, тому важливо, щоб вона була встановлена.

Перевірте, чи ви маєте все необхідне для роботи. Версії програм можуть відрізнятись, це не принципово. Головне, що .NET, Git and Heroku CLI встановлені коректно.

> dotnet --version
3.1.300-preview-015115

> git --version
git version 2.24.1.windows.

> heroku --version
heroku/7.30.0 win32-x64 node-v11.14.0

Створення програми ASP.NET Core

Створимо ASP.NET Core веб програму в каталозі dotnet-app-heroku.

Вам не варто використовувати ту саму назву для програми. Змініть її на щось унікальне, наприклад %USERNAME%-dotnet-app-heroku. Це дасть змогу уникнути конфліктів адрес з моєю програмою, яка може бути в цей момент розгорнута в Інтернет.

> dotnet new webapp --name DotnetAppHeroku --output dotnet-app-heroku       
The template "ASP.NET Core Web App" was created successfully.
...
Restore succeeded.

Тепер створимо програму в Heroku, але перед цим необхідно пройти процедуру логіну.

> cd dotnet-app-heroku

> heroku login   
heroku: Press any key to open up the browser to login or q to exit:
Opening browser to https://cli-auth.heroku.com/auth/cli/browser/12b5558d-f062-4dbb-a055-1c7e9f0f84c5
Logging in... done
Logged in as elexander+heroku@ukr.net

> heroku create dotnet-app-heroku
Creating ⬢ dotnet-app-heroku... done
https://dotnet-app-heroku.herokuapp.com/ | https://git.heroku.com/dotnet-app-heroku.git

В результаті команди create ми отримали дві URL адреси, що знадобляться нам пізніше. Перша - це адреса нашого майбутнього сайту в Інтернет, а друга - адреса Git репозиторію, в який нам необхідно проштовхнути наш код, щоб розгорнути веб програму.

Створимо git репозиторій в каталозі проєкту, додамо всі файли і спробуємо проштовхнути код у репозиторій.

> git init
Initialized empty Git repository in ./dotnet-app-heroku/.git/

> git remote add origin https://git.heroku.com/dotnet-app-heroku.git

> git add .

> git commit --message "Initial add"      
[master (root-commit) f471c3c] Initial add
 57 files changed, 39806 insertions(+)
 create mode 100644 DotnetAppHeroku.csproj
 create mode 100644 Pages/Error.cshtml
 ...

 > git push origin master
 Enumerating objects: 76, done.
...
Total 76 (delta 12), reused 0 (delta 0)
remote: Compressing source files... done.
remote: Building source:
remote:
remote:  !     No default language could be detected for this app.
remote:  HINT: This occurs when Heroku cannot detect the buildpack to use for this application

Команда git push звершилась з помилкою No default language could be detected for this app. Причина в тому, що Heroku не підтримує .NET проєкти, тобто не знає, як зкомпілювати та запустити ASP.NET веб програму. Давайте допоможемо йому.

Контейнер в якості стеку

Всі dyno за умовчанням запускаються на Linux Ubuntu 18:

Але Heroku має можливість запустити будь-який Docker контейнер і таким чином дозволяє самостійно вирішувати, яка операційна система і фреймворк потрібні програмісту.

Для цього нам необхідно:

Змінити стек програми на container
Створити Dockerfile
Вказати Heroku де цей Dockerfile знаходиться

> heroku stack:set container
Stack set. Next release on ⬢ dotnet-app-heroku will use container.
Run git push heroku master to create a new release on ⬢ dotnet-app-heroku.

Тепер dyno буде використовувати для запуску контейнер, який ми зараз побудуємо. Створіть файл Dockerfile в каталозі проєкту з таким вмістом.

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build-env
WORKDIR /app
COPY *.csproj ./
RUN dotnet restore
COPY . ./
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/core/aspnet:3.1
WORKDIR /app
COPY --from=build-env /app/out .

CMD dotnet DotnetAppHeroku.dll

Ми не будемо зупинятись на детальному розборі даного файлу. Якщо коротко, то він компілює проєкт з релізною конфігурацією і запускає його на виконання командою dotnet DotnetAppHeroku.dll.

Якщо ім'я вашого проєкту відрізняється від DotnetAppHeroku вам необхідно змінити останній рядоку файлу.

Також необхідно створити в корні проєкту файл heroku.yml, де вказати шлях до Dockerfile, який Heroku буде використовувати для побудови образу.

build:
  docker:
    web: Dockerfile

Тепер можна додати новостворені файли до репозиторію і знову зробити push.

> git add .  

> git status                              
On branch master
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)        
        new file:   Dockerfile
        new file:   heroku.yml

> git commit --message "Added Dockerfile" 
[master 1f184b8] Added Dockerfile
 2 files changed, 15 insertions(+)
 create mode 100644 Dockerfile
 create mode 100644 heroku.yml

> git push origin master
Enumerating objects: 80, done.
...
remote: === Building web (Dockerfile)
remote: Sending build context to Docker daemon  4.404MB    
...
remote: Verifying deploy... done.
To https://git.heroku.com/dotnet-app-heroku.git
 * [new branch]      master -> master

Змінна оточення PORT

Якщо зараз відкрити сайт https://dotnet-app-heroku.herokuapp.com/ в браузері ми побачимо помилку.

Щоб розібратись, чому це сталося, переглянемо логи нашої програми:

> heroku logs
...
app[web.1]: Unhandled exception. System.Net.Sockets.SocketException (13): Permission denied
...
app[web.1]: at Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets.SocketTransportFactory.BindAsync(EndPoint endpoint, CancellationToken cancellationToken)

Як бачимо, сталася помилка Permission denied під час відкриття порту на прослуховування. Механізми безпеки Linux працюють таким чином, що для прослуховування стандартного для HTTP порту 80 процесу необхідні права супер-користувача. В документації до Heroku можна знайти вирішення проблеми. Heroku очікує, що кожна програма буде стартувати не з довільним портом, а з портом заданим у змінній оточення PORT. Внутрішні механізми Heroku будуть відправляти на цей порт весь трафік із зовнішнього порту 80, на якому сайт буде доступний в Інтернет.

Виправимо це в нашому проєкті і додамо відповідну конфігурацію для Kestrel серверу у файлі Startup.cs:

webBuilder
    .UseStartup<Startup>()
    .UseKestrel((context, options) =>
    {
        var port = Environment.GetEnvironmentVariable("PORT");
        if (!string.IsNullOrEmpty(port))
        {
            options.ListenAnyIP(int.Parse(port));
        }
    });

Тепер можна зберегти зміни і зробити пуш в репозиторій. Пуш займе близько хвилини, поки створиться Docker образ. Відкрийте https://dotnet-app-heroku.herokuapp.com/. Тепер все працює.

Висновок

Ми побачили, як:

Створити безкоштовний акаунт в Heroku та інсталювати Heroku CLI.
Створити проєкт ASP.NET Core та додати Dockerfile для компіляції проєкту в образ.
Розгорнути образ в Heroku завдяки команді git push.
Переглянути логи програми у разі помилки.
Використовувати змінні оточення Heroku для успішного старту програми.

Репозиторій на Github

Наступні кроки

В наступних дописах я планую розглянути використання аддонів Heroku, які дають можливість підключати сервіси бази даних, кешування, логування, повнотекстового пошуку і багато чого іншого. Вони також мають безкоштовні версії, яких може бути цілком достатньо для вашого PET-проєкту.

Також може бути цікавою документація по Heroku CLI, яка дозволяє моніторити виконання ваших програм, переглядати кількість використаних годин, додавати інших співробітників до вашого проєкту і т.ін.

Оригінальна стаття на моєму сайті.

Жадібні алгоритми

Oleksandr Martyniuk — Sun, 10 May 2020 18:55:05 +0000

Жадібний алгоритм - інтуїтивний та ефективний спосіб розв'язання задач оптимізації. І хоча його реалізація приваблює своєю очевидністю, він не завжди оптимальний. Необхідно точно розуміти, коли застосовувати жадібний підхід, а коли його варто уникати. В статті пропоную познайомитись з жадібними алгоритмами та потренуватись його застосовувати на задачі зі сайту codility.com.

Жадібний підхід

Жадібні алгоритми - це ціле сімейство алгоритмів (інколи ще говорять про жадібний підхід або жадібне програмування), тому немає якогось конкретного жадібного алгоритму, який можна закодувати. Проте, всі жадібні алгоритми побудовані згідно одного принципу - обирати оптимальне вирішення на кожному кроці, не зважаючи на кроки, які були зроблені до або будуть зроблені після. Іншими словами, жадібний алгоритм робить локально оптимальний вибір у сподіванні, що він приведе до глобально оптимального ровз'язку.

Задача про монети

Розглянемо популярний приклад з монетками. Нехай у нас є монети номіналом 1, 2 і 5 копійок і нам необхідно відрахувати 10 копійок таким чином, щоб кількість монет була мінімальною.

За логікою жадібного підходу на кожному кроці необхідно обирати монету з найбільшим номіналом і це приведе до мінімальної їх кількості в результаті. Візьмемо 5 копійок, тепер можемо взяти ще одну монету в 5 копійок, не вийшовши за обмеження у 10. В результаті 10 коп. = 5 коп. + 5 коп. Кількість монет - 2 і це, дійсно, мінімально можлива їх кількість за даних умов.

Але якщо в задачу додати монету номіналом 6 копійок, це зробить застосування жадібного підходу не оптимальним. Дійсно, на першому кроці нам необхідно обрати 6, як монету з найбільшим номіналом, але далі ми не можемо обрати ні 6, ні 5, так як це перевищить ліміт у 10 копійок. Залишається дві монети по 2 коп. В результаті, ми маємо 10 як суму 6 + 2 + 2. В той час, як оптимальний розв'язок буде все ті ж 2 монети по 5.

В залежності від проблеми яку ми розв'язуємо, жадібний метод може бути оптимальним, а може і не бути. Якщо він дає не оптимальний розв'язок, часто, він дозволяє знайти рішення близьке до оптимального. В такому випадку необхідно скористатись іншим підходом, наприклад, повним перебором або динамічним програмуванням. Але, якщо жадібний підхід все ж працює коректно, час виконання алгоритму буде значно меншим за час виконання повного перебору чи при динамічному програмуванні.

Переваги і недоліки

Жадібний підхід легкий для розуміння і кодування. На кожному кроці алгоритму ми можемо абстрагуватись від попередніх і наступних кроків і думати лише про оптимальний розв'язок на даному етапі. Жадібний підхід не передбачає відміну вже зробленого вибору (повернення на попередні кроки) і не прогнозує нічого на майбутнє.
Швидкість виконання програми при жадібному підході легко передбачити, тому що складність алогритму очевидна. Найчастіше, вона лінійна, тобто, час виконання програми лінійно залежить від кількості вхідних даних. З іншими алгоритмічними підходами, такими як, наприклад, Розділяй і володарюй, це не завжди так.
Але у підходу є і великий недолік. У більшості випадків жадібний алгоритм працює некоректно. Необхідно дуже добре розуміти, коли його можна використовувати, а коли - ні. І навіть якщо жадібний алгоритм дає оптимальне вирішення в певних випадках, важко довести, що підхід буде працювати у всіх іншим можливих випадках.

В наведеному прикладі з монетами жадібний алгоритм добре працює для монет номіналом 1, 2, 5 але вже не працює для номіналів 1, 2, 5, 6. Варто зазаначити, що всі відомі мені грошові системи спроєктовані таким чином, що жадібний алгоритм працює для них коректно. Оскільки він простий і швидкий, люди легко знаходять потрібну суму для розрахунку в супермаркеті.

Правило застосування

Існує евристичне правило для розуміння застосовності жадібного підходу. Якщо обидві властивості наведені нижче справджуються, жадібний алгоритм може бути застосований до розв'язання задачі.

Принцип жадібного вибору. Послідовність оптимальних виборів на кожному кроці приводить до оптимального рішення в кінці.
Оптимальна підструктура. Задача має оптимальну підструктуру, якщо оптимальний розв'язок цілої задачі містить оптимальний розв'язок для будь якої підзадачі. Іншими словами, після заврешення певного кроку алгоритму залишається розв'язати задачу, для якої жадібний підхід також працює.

Спробуємо застосувати ці правила на прикладі Задачі про рюкзак.

Злодій проник на склад, де знаходяться три товари.

Товар	Ціна	Вага
Товар А	60 грн	10 кг
Товар Б	100 грн	20 кг
Товар В	120 грн	30 кг

Але у злодія є рюкзак лише на 50 кг. Яким чином він має вирішити, що взяти, щоб максимізувати свій прибуток?

Не важко побачити, що оптимальним рішенням буде взяти товари Б і В, що в сумі дасть 220 грн. Але, якби злодій застосував жадібний підхід, він би почав обирати товари з найбільшою питомою вартістю (відношенням ціни до ваги товару). Найдорожчим товаром є А, оскільки він коштує 6 грн/кг, тоді як Б і В коштують 5 і 4 грн/кг відповідно. Тобто, жадібний злодій обрав би товари А і Б, як найдорожчі і таким чином зміг би забрати з собою лише 160 грн, так як товар В вже не вліз би у рюкзак.

Повернемося до правила. Вибір першим товару А протирічить принципу жадібного відбору, адже не веде до оптимального рішення, яким є Б + В. Таким чином, жадібний алгоритм не може бути застосований в загальному випадку до Задачі про рюкзак.

Існує формальне доведення можливості або неможливості застосування жадібного алгоритму. Для цього необхідно звернутись до теорії Матроїдів.
Якщо довести, що множина можливих розв'язків є матроїдом, згідно теореми Радо-Едмондса, до неї може бути успішно застосований жідібний підхід.

Використання на практиці

Жадібні алгоритми мають багато застосуваннь. Одним з найвідоміших є алгоритм Дейкстри для пошуку найкоротшого шляху у графі.

Алгоритм працює з невідвіданими вузлами і обчислює орієнтовну відстань від даного вузла до іншого. Якщо алгоритм знаходить коротший спосіб дістатися до заданого вузла, шлях оновлюється з урахуванням коротшої відстані. Ця задача має оптимальну підструктуру, оскільки, якщо вузел A пов'язаний з B, а B пов'язаний з C, і шлях повинен пройти через A і B, щоб дістатися до пункту призначення C, то найкоротший шлях від A до B і найкоротший шлях від B до C має бути частиною найкоротшого шляху від A до C. Таким чином, оптимальне рішення підзадачі приводить до оптимального вирішення вцілому.

Кодування Гаффмана - інший відомий приклад успішного застосування жадібного підходу. Алгоритм Гаффмана аналізує деякий текст і присвоює кожному символу код змінної довжини на основі частоти, з якою він зустрічається. Символи, що зустрічаються найчастіше будуть мати коротші коди, символи, що зустрічаються рідко будуть мати довгі коди. Таким чином можна значно зменшити (інколи до 80%) кількість інформації необхідної для передачі або зберігання тексту.

Задача про розклад також може бути розв'язана жадібно. Нехай у нас є кількість завдань, кожне з яких має певний дедлайн і винагороду. Виконання кожного завдання займає фіксований час. Винагорода буде виплачена, якщо завдання виконане до дедлайну. Необхідно обрати список завдань, щоб максимізувати свій прибуток.

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

Задача з Codility

На сайті codility.com є досить багато матеріалів по алгоритмам і, що добре для нас, тестові задачі, які допоможуть закріпити знання.

Розв'яжемо задачу про відрізки, що не перетинаються, з уроку про жадібні алгоритми - MaxNonoverlappingSegments.

Отже, на координатній осі є відрізки, що задаються двома масивами A і B. Масив А містить координати початків, а B - координати кінців відрізків. Тобто, відрізок номер 1 починається в точці A[1] і закінчується в точці B[1].

Розглянемо такий приклад.

A[0] = 1    B[0] = 5
A[1] = 3    B[1] = 6
A[2] = 7    B[2] = 8
A[3] = 9    B[3] = 9
A[4] = 9    B[4] = 10

Відрізки показані на малюнку нижче.

Необхідно знайти максимальну кількість відрізків, які не перетинаються. Перетинаються ті відрізки, які мають хоча б одну спільну точку.

Для прикладу вище максимальною кількістю відрізків, що не перетинаються, є 3. Можливі варіанти: {0, 2, 3}, {0, 2, 4}, {1, 2, 3} або {1, 2, 4}. Якщо взяти будь які 4 відрізки, то хоча б два з них обов'язково перетнуться.

Задача містить додаткову умову, яка впливає на її розв'язання - відрізки відсортовані за координатою кінця. Іншими словами, масив B впорядкований по зростанню.

Почнемо зі створення проєкту xunit на C#.

> dotnet new xunit -n MaxNonoverlappingSegments
The template "xUnit Test Project" was created successfully.

Я обрав саме проєкт з юніт тестами, так як ми спробуємо написати спочатку тест і тільки потім реалізацію алгортиму.

Скопіюємо заготовку класу з сайту і самостійно створимо клас з тестом.

class Solution
{
    public int solution(int[] A, int[] B)
    {
        throw new NotImplementedException();
    }
}

public class UnitTest1
{
    [Theory]
    [InlineData(
        new int[] { }, 
        new int[] { }, 
        0)]
    public void Test(int[] a, int[] b, int result) 
    {
        Assert.Equal(result, new Solution().solution(a, b));
    }
}

Через атрибут InlineData задаються тестові дані. В даному випадку для порожнього списку очікується 0 відрізків, що не перетинаються.

Зпустимо тест. Він завершився з помилкою NotImplementedException, адже клас Solution не реалізований. Давайте, на першому етапі як повернемо просто загальну кількість відрізків. Це повинно спрацювати.

public int solution(int[] A, int[] B)
{
    return A.Length;
}

Тепер тест завершився успішно.

Додамо також тест для одного відрізку і для двох відрізків, які не перетинаються.

[InlineData(
    new int[] { 1 }, 
    new int[] { 1 }, 
    1)]
[InlineData(
    new int[] { 1, 2 }, 
    new int[] { 1, 3 }, 
    2)]

Наш код все ще задовольняє цим тестам!

Але для ситуації двох відрізків, які перетинаються, алгоритм вже не працює.

MaxNonoverlappingSegments.UnitTest1.Test(a: [1, 2], b: [2, 3], result: 1) [FAIL]
[xUnit.net 00:00:00.63]       Assert.Equal() Failure
[xUnit.net 00:00:00.63]       Expected: 1
[xUnit.net 00:00:00.63]       Actual:   2

Тепер, власне, настав час реалізувати жадібний алгоритм вибору відрізків. Ідея, яка першою приходить в голову - рухаючись з права на ліво обирати перший доступний відрізок і запам'ятовувати його. Якщо наступний відрізок перетинається з поточним пропустимо його, якщо ж не перетинається, то збільшимо лічильник відрізків. Після цього необхідно запам'ятати наступний відрізок як поточний і рухатись далі.

Даний алгоритм можна застосувати, адже відрізки за умовою відсортовані за координатою кінця.

В коді це можна виразити наступним чином:

public int solution(int[] A, int[] B)
{
    var result = 0;
    var N = A.Length;
    var position = int.MaxValue;

    for (int i = N - 1; i >= 0; i--)
    {
        if (B[i] < position)
        {
            result++;
            position = A[i];
        }
    }

    return result;
}

Якщо бути точним, тут не запам'ятовується поточний відрізок, а лише координата його початку (змінна position), адже цього достатньо, щоб перевірити, чи наступний відрізок може бути включений у розв'язок. Якщо координата кінця поточного відрізку менша за position, він додається до результату і position змінюється на його початок.

Чудово, тепер всі тести проходять! Додамо ще випадок описаний на сайті:

[InlineData(
    new int[] { 1, 3, 7, 9, 9 }, 
    new int[] { 5, 6, 8, 9, 10 }, 
    3)]

Він теж виконується успішно, але не поспішаймо відправляти результат. Наш алгоритм дозволяє зменшити проміжки між відрізками, але він не бере до уваги довжину відрізків. Якщо перший відрізок, який нам потрапить буде займати всю координатну вісь, алгоритм проігнорує всі інші відрізки. А серед них можуть бути декілька таких, що не перетинаються між собою. Тому наш алгоритм явно НЕ оптимальний. Цей тест описує такий випадок:

[InlineData(
    new int[] { 1, 3, 1 }, 
    new int[] { 2, 4, 5 }, 
    3)]

Є три відрізки. Відрізок 1-5 найдовший і перекриває всі інші відрізки. Так як його кінець розташований найдалі, при жадібному підході він буде обраний першим і не дасть змоги включити інші відрізки в розв'язок. Замість правильного результату 2 (відрізки 1-2, 3-4) ми отримаємо в результаті 1 (відрізок 1-5).

Якщо ми відсортуємо відрізки по координаті початку і спробуємо йти від початку до кінця, то отримаємо ту ж саму проблему, але з іншого боку. Тому це не варіант.

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

public int solution(int[] A, int[] B)
{
    var result = 0;
    var N = A.Length;
    var position = int.MaxValue;

    for (int i = N - 1; i >= 0; i--)
    {
        if (B[i] < position)
        {
            result++;
            position = A[i];
            continue;
        }

        if (A[i] > position)
        {
            position = A[i];
            continue;
        }
    }

    return result;
}

Перша частина алгоритму залишилась незмінною, якщо ми натрапляємо на відрізок, що може бути включений у розв'язок, інкрементуємо result і переходимо до наступного відрізку.

Якщо ми натрапили на відрізок, що повністю перекривається поточним (if (A[i] > position)), замінимо поточний відрізок на коротший.

Total tests: 6. Passed: 6. Failed: 0. Skipped: 0

Всі тести завершились успішно. Тепер можемо відправити даний код на перевірку.

Як бачите, наш алгоритм не тільки коректний, він ще й оптимальний за часом. Його складність лінійна O(n).

Тестові приклади, які пропонує сайт codility.com не завжди покривають всі випадки, тому навіть якщо ваш код добре працює для пропонованих тестових даних спробуйте проаналізувати ваш розв'язок і уявити ситуації, в яких алгоритм може не спрацювати і створіть такі додаткові тести.

Висновок

Жадібний підхід - чудовий інтуїтивний і ефективний спосіб розв'язання багатьох популярних задач програмування. Його найбільшим недоліком є необхідність добре розуміти, коли він може бути застосований, а коли необхідно звернутись до іншого підходу. Але навіть в ситуаціях, коли жадібний алгоритм не дає оптимального рішення, його результат може бути близьким до оптимального і він точно буде ефективнішим за метод повного перебору або динамічне програмування.

Оригінальна стаття на моєму сайті.

LINQ в C#. Огляд

Oleksandr Martyniuk — Fri, 01 May 2020 16:59:34 +0000

В цій статті пропоную розглянути LINQ як важливий компонент .NET фреймворку, його історію та роль. Чому він був створений і як врешті користуватись цим інструментом. В кінці розглянемо приклади на мові C#, які дадуть уявлення про те, що таке LINQ.

LINQ - (анг. language integrated query) - мова запитів до структурованих даних, що інтегрована в C#. Такими структурованими даними можуть бути колекції об'єктів в пам'яті, XML файли, таблиці баз даних, веб-сервіси і т.ін. Але для чого нам потрібен ще один інструмент в мові C#, яка і так дозволяє працювати з даними? Вся справа у легкості розуміння і сприйняття. Для того, щоб пояснити в чому саме полягає легкість LINQ, необхідно розглянути відмінність між декларативним та імперативним програмуванням.

Імперативне та декларативне програмування

Перші мови програмування задавали чіткий порядок команд. Це дуже зручно, коли ви маєте справу з регістрами процесору і прямим доступом до пам'яті. В таких мовах, як C та Assembler широко використовуються оператори виділення пам'яті, присвоєння, умовні оператори та підпрограми. Все це ознаки імперативного підходу. Слово імператив з англійської перекладається як наказ і це досить точне вмзначення для подібного підходу, тому що при імперативному підході програма є послідовністю чітких команд і комп'ютер виконує ці команди одна за одною.

До імперативних мов програмування відносяться:

C#
Python
JavaScript
Go

Всі ці мови базуються на змінних, операторах присвоєння і підпрограмах. Такий підхід близький до того як працює комп'ютер, але далекий від людської мови, звичної всім нам. Людині зручніше декларувати те, чого вона хоче, ніж описувати чіткий алгоритм досягнення цієї мети.

Тому імперативному підходу протиставляється декларативний. Його головною ознакою є те, що покроковий алгоритм не задається. Натомість задається джерело даних, описується бажаний результат і набір правил, завдяки яким цей результат буде досягнуто. Виконання запиту доручається інтерпретатору, який вміє перевести його у форму зручну для комп'ютера, тобто в імперативну форму.

До декларативних мов відносяться:

SQL
Regular Expressions
XSLT Transformation
Gremlin

Саме введення декларативного підходу до обробки даних в .NET і було головною метою створення LINQ.

Порівняння підходів

Розглянемо на прикладі два підходи, спочатку імперативний з використанням циклу, а потім декларативний з використанням LINQ.

Як тестовий набір даних візьмемо список супергероїв, кожен з яких має ім'я, рік народження (або першої згадки у коміксах) та назву серії, де він вперше з'явився.

Отже, створимо нову консольну програму в .NET Core:

> dotnet new console -n  LinqTestApp
The template "Console Application" was created successfully.

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

private class Hero
{
    public string Name { get; set; }
    public int YearOfBirth { get; set; }
    public string Comics { get; set; }
}

private static readonly List<Hero> _heroes = new List<Hero> 
{
    new Hero
    {
        Name = "Superman",
        YearOfBirth = 1938,
        Comics = "Action Comics"
    },
    new Hero
    {
        Name = "Batman",
        YearOfBirth = 1938,
        Comics = "Detective Comics"
    },
    new Hero
    {
        Name = "Captain America",
        YearOfBirth = 1941,
        Comics = "Captain America Comics"
    },
    new Hero
    {
        Name = "Ironman",
        YearOfBirth = 1963,
        Comics = "Tales of Suspense"
    },
    new Hero
    {
        Name = "Spiderman",
        YearOfBirth = 1963,
        Comics = "Amazing Fantasy"
    }
};

Нехай, наша задача полягатиме в тому, щоб відібрати тих супергероїв, які мають слово "man" в імені та вивести їх імена на екран у алфавітному порядку. Тобто, ми повинні отримати імена всіх героїв (окрім Капітана Америки) у відсортованому вигляді.

Batman
Ironman
Spiderman
Superman

При імперативному підході нам необхідно створити список в який ми будемо заносити імена відфільтрованих героїв, потім пройтись по списку героїв і додати до створеного списку лише тих, чиї імена містять слово "man". Після цього необхідно відсортувати отриманий список і вивести на екран:

static void Main(string[] args)
{
    var heroNames = new List<string>();
    foreach (var hero in _heroes)
    {
        if (hero.Name.Contains("man"))
        {
            heroNames.Add(hero.Name);
        }
    }
    heroNames.Sort();

    foreach (var heroName in heroNames)
    {
        Console.WriteLine(heroName);
    }
}

Тепер давайте розв'яжемо ту ж задачу, але за допомогою LINQ.

Не забудьте піключити простір імен System.Linq

using System.Linq;
...
static void Main(string[] args)
{
    var heroNames =
        from hero in _heroes
        where hero.Name.Contains("man")
        orderby hero.Name
        select hero.Name;

    foreach (var hero in heroNames)
    {
        Console.WriteLine(hero.Name);
    }
}

Програма стала на 5 рядків коротшою і легшою для розуміння, адже вибірка даних здійснюється мовою дуже схожою на англійську: From heroes where heroName contains "man" ordered by name select name, що можна перекласти як "З колекції героїв обери імена тих героїв які містять слово "man" в імені і відсортуй їх за ім'ям".

Розберемо, що робить даний код.

from hero in _heroes задає джерело даних. У нас це константний список _heroes. До кожного елементу списку ми будемо звертатися у виразі через змінну hero. І хоча ми ніде не вказували її тип, вираз залишається строго типізованим, адже компілятор має змогу вивести тип з типу колекції _heroes.

where hero.Name.Contains задає умову фільтрації вхідного списку. Якщо елемент відповідає умові, він передається далі. Таким чином, всі подальші оператори у виразі будуть працювати вже з відфільтрованим списком. Оператор where ще називають оператором фільтрації.

orderby hero.Name задає поле і спосіб сортування.

select hero.Name задає значення, що потрапить у результуючу вибірку. Оскільки нас цікавлять лише імена героїв, ми вказуємо тут поле Name. Саме цей оператор задає тип результату, тому у нашому випадку це буде IEnumerable<string>. Даний оператор ще називають оператором проекції, оскільки він перетворює дані, що містить джерело у вигляд необхідний нам для конкретної задачі.

Методи розширення

Варто зазначити, що хоча синтаксис LINQ значно відрізняється від синтаксису C#, все ж під капотом LINQ використовує методи розширення C#, тож наведений вище запит можна переписати в більш звичному об'єктному стилі:

var heroNames = _heroes
    .Where(hero => hero.Name.Contains("man"))
    .OrderBy(hero => hero.Name)
    .Select(hero => hero.Name);

Такий синтаксис називається синтаксисом методів розширення (або лямбда синтаксисом) і він може застосовуватись разом з синтаксисом запитів LINQ. Часто, коли говорять про LINQ мають на увазі методи розширення, тому що вони реалізовані в просторі імен System.Linq і є частиною LINQ як компоненту .NET. У своїй більшості ці методи розширюють інтерфейс IEnumerable і є базою для реалізації LINQ. Це може спочатку збивати з пантелику, але LINQ це не лише синтаксис from ... in ... select, але також і синтаксис методів розширення.

Так як методи розширення є базою для реалізації LINQ, вони більш потужні ніж синтаксис запитів. Наприклад, метод Where має перевантажену версію, в якій при фільтрації доступний індекс елементу у вихідній колекції. Цей індекс може бути використаний при формуванні логічного виразу (предикату).

    ...
    .Where((hero, index) => hero.Name.Contains("man") && index > 2)

Нажаль, даний індекс недоступний, якщо ми використовуємо синтаксис запиту from ... in ... select.

При використанні синтаксису запиту також недоступні скалярні функції Count, Max, Sum та інші методи (наприклад, Intersect).

Також, з методами розширення ми можемо розбити LINQ вираз на декілька частин і сформувати його згідно певної умови, що для синтаксису запиту неможливо. Наприклад:

var query = _heroes.Where((hero, index) => hero.Name.Contains("man"));

if (shouldBeSorted)
    query = query.OrderBy(hero => hero.Name);

var heroNames = query
    .Select(hero => hero.Name);

Ми додаємо сортування тільки якщо вхідний параметр shouldBeSorted дорівнює true. Використовуючи синтаксис запиту нам необхідно записати вираз двічі в залежності від умови: в першому випадку зі сортуванням, а в другому - без нього.

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

Трохи історії

У 2007 році мова C# мала версію 2.0 і не мала LINQ. Обробка даних відбувалась в імперативному стилі. В той час вже існували Python 2.4 та JavaScript 1.6, які мали потужні вбудовані засоби роботи з колекціями, такі як filter, map і reduce. C# значно програвав їм у зручності коли йшлося про роботу з колекціями, і це не могло продовжуватись довго.

Восени 2007 року компанія Microsoft випустила .NET Framework 3.5 в якому були значні нововведення. Ці зміни дали можливість створити LINQ та підняти версію мови C# до 3.0 Серед нововведень були:

Лямбда вирази зробили можливим просте визначення предикатів для методів типу Where, Select у вигляді () => {...}.
Анонімні типи дозволили створювати об'єкти довільної структури на льоту і прибрали необхідність оголошувати тип для результату LINQ виразу.
Дерева виразів зробили можливим збереження предикатів у вигляді об'єктів, на основі яких різні провайдери даних могли сформувати власний оптимізований запит. Це стосується LINQ to SQL або LINQ to XPath.
Методи розширення дозволили розширяти вже існуючі типи без їх модифікації і наслідування. Це дозволило застосовувати LINQ до великої кількості сторонніх типів, що підтримують IEnumerable або IQueryable.
Ініціалізатори об’єктів та колекцій довзолили створювати об'єкти та ініціалізувати їх поля без використання конструкторів, що значно спростило синтаксис для методів проекції LINQ, коли нові об'єкти створюються як частина виразу.
Оголошення змінних через var значно спростило визначення типу результату запиту і зробило можливим повернення даних анонімних типів з LINQ виразу.

Всі ці можливості вивели C# і платформу .NET на якісно новий рівень і довзолили створити LINQ. З моменту випуску він став невід'ємною частиною .NET фреймворку і як бібліотека для роботи з даними не поступається, а багато в чому і перевершує, вбудовані засоби інших мов, таких як Java, Python, Go і JavaScript.

В наступних статтях розглянемо детальніше всі основні аспекти роботи з LINQ. Ви переконаєтесь, що це не тільки зручний, але й доволі ефективний та зрілий інструмент.

Оригінальна стаття на моєму сайті.

DEV Community: Oleksandr Martyniuk

7 проблем в автотестах

Проблема №1. Тести залежать від випадкових даних.

Що робити?

Проблема №2. Тести дублюють логіку коду.

Проблема №3. Тести не запускаються автоматично.

Проблема №4. Тести залежать від інших тестів.

Що робити?

Проблема №5. Тести неповні.

Що робити?

Проблема №6. Тести написані неохайно.

Що робити?

Проблема №7. Тести відсутні.

Що робити?

Транзакції в DynamoDB

DynamoDB

Локальна DynamoDB

Система замовлення таксі

AWS SDK та .NET Core

Транзакція в дії

Причини невдачі транзакцій

Порівняння з SQL

Недоліки транзакцій

Висновок

Безкоштовна БД для програми ASP.NET Core

Передумови

Додатки Heroku

Масштабування Heroku Postgres

Створення бази даних

Налаштування програми для роботи з БД

Налаштування інтерфейсу аутентифікації

Статистика використання БД

Висновок

Зустрічайте C# 9.0

Властивості з ініціалізацією

Init аксесори та поля лише для читання

Класи даних (record)

Вираз with

Порівняння за значенням

Поля класів даних

Позиційні класи даних

Класи даних і змінюваний стан

With-вираз та наслідування

Порівняння за значенням і наслідування

Програми найвищого рівня

Вдосконалене співставлення за шаблоном

Спрощений шаблон типу

Шаблони порівняння

Логічні шаблони

Вдосконалене приведення до цільового типу

Приведення у виразі new

Приведення у виразах ?? та ?:

Коваріантні результати

І навіть більше…

Обмеження одночасних потоків в C#

Спосіб 1 - ConcurrentQueue

Спосіб 2 - SemaphoreSlim

Спосіб 3 - Parallel.ForEach

Спосіб 4 - політика "Перемичка" бібліотеки Polly

Висновок

Коментар Стівена Клірі

Безкоштовна публікація ASP.NET Core програми

Передумови

Heroku та безкоштовний dyno

Налаштування Heroku CLI

Створення програми ASP.NET Core

Контейнер в якості стеку

Змінна оточення PORT

Висновок

Наступні кроки

Жадібні алгоритми

Жадібний підхід

Задача про монети

Переваги і недоліки

Правило застосування

Використання на практиці

Задача з Codility

Висновок

LINQ в C#. Огляд

Імперативне та декларативне програмування

Вираз `with`

Приведення у виразі `new`

Приведення у виразах `??` та `?:`