“Ідеальний програміст” Роберта Мартіна давно став керівництвом з професіоналізму у сфері IT та однією з основоположних праць у сучасній розробці, нарівні з “Чистим кодом”, “Чистою архітектурою” та “Чистим еджайлом”.
Професіоналом ми називаємо того, хто працює швидко, але без поспіху, хто розумно оцінює ситуацію та виконує свої зобов’язання. Професіонал знає, коли треба говорити “ні”, але чесно намагається сказати “так”.
Непрофесіонали не несуть відповідальності за роботу, що виконується — вони залишають відповідальність своїм роботодавцям. Якщо непрофесіонал робить помилку, то сміття за ним прибирає роботодавець. Але якщо помилка відбувається професіоналом, то усувати наслідки доводиться йому самому .
Фахівці часто роблять героїчні справи, але не тому, що хочуть бути героями. Професіонали стають героями, коли вони добре виконують свою роботу, без порушення термінів та бюджету.
Професіоналізм передається від однієї людини до іншої. Старші навчають молодших. Колеги обмінюються між собою. Старші, спостерігаючи за молодшими, бачать його збоку та навчаються заново. Професіоналізм поширюється наче свого роду інтелектуальний вірус. Не можна переконати людей бути фахівцями. Прийняття професійного ставлення не так раціональним, скільки емоційним рішенням. Стати зразком для наслідування. Ви стаєте професіоналом самі та показуєте свій професіоналізм іншим. А потім нехай концепція сама зробить усю роботу.
Деякі фахівці використовують службу контролю якості для виявлення помилок. Вони розраховують на те, що контроль якості виявить помилки та поверне їх список розробникам. Передавати на контроль якості код, працездатність якого ви не можете гарантувати непрофесійно. Напишіть модульні тести, які можна виконати будь-якої миті, і запускайте їх якнайчастіше. Кожен написаний вами рядок коду має бути протестований. Крапка.
Група розробки повинна прагнути до того, щоб контроль якості не виявляв жодних дефектів. Щоразу, коли служба контролю якості щось виявляє, це має стати тривожним сигналом для розробників. Вони повинні запитати себе, як це сталося, і вжити заходів для запобігання таким інцидентам у майбутньому.
Час налагодження обходиться фірмі рівно таку ж суму, що час написання коду. Ви як фахівець повинні прагнути по можливості наблизити час налагодження до нуля.
Витрати на проведення автоматизованих тестів настільки малі в порівнянні з витратами на ручне тестування, що написання сценаріїв, що запускаються вручну, не має жодного економічного сенсу. Професійні розробники вважають за свій обов’язок простежити за тим, щоб приймальні тести проводилися в автоматизованому режимі. Не варто розглядати ці тести як зайву роботу – краще розглядайте їх як значну економію часу та грошей. Тести запобігають помилкам у реалізації системи та допоможуть дізнатися, коли ваша робота закінчена.
Три закони TDD:
TDD – вибір професіоналів. Ця методологія підвищує впевненість, надає сміливості розробникам, знижує кількість дефектів, формує документацію та покращує архітектуру.
TDD – не релігія і не панацея. Виконання трьох законів не гарантує жодної з перерахованих переваг. Поганий код можна написати навіть за попереднього написання тестів.
Ніщо не має більш ґрунтовного та довгострокового негативного ефекту на продуктивність групи програмістів, ніж бруд у програмному коді. Рух вперед по багнюці (коли ви знаєте, що це бруд) є найгіршим з різновидів інверсії пріоритетів. Рухаючись вперед, ви обманюєте себе, обманюєте вашу групу, обманюєте свою компанію та замовників. Ви кажете їм, що все буде гаразд, хоча насправді ви ведете їх до загальної катастрофи. Професіонал не піддається спокусі влаштувати бруд у коді, щоб швидко рухатися вперед. Брудно – завжди означає повільно!
Чистий код простіше зрозуміти, простіше змінювати та простіше розширювати. Зі спрощенням коду ймовірність дефектів стає ще нижчою. Відбувається стабільне покращення кодової бази — замість «загнивання коду», такого звичного для нашої галузі.
Щоразу під час роботи з модулем слід потроху удосконалювати його структуру. Кожне читання коду має призводити до доопрацювання структури.
Додавання функціональності на шкоду структурі – остання справа. Структура коду забезпечує його гнучкість. Порушуючи структуру, ви руйнуєте майбутнє коду. Усі програмні проекти базуються на фундаментальному припущенні про простоту змін. Якщо ви порушуєте це припущення, створюючи негнучкі структури, то ви тим самим підриваєте економічну модель, закладену в основу всієї галузі.
Щоб зрозуміти, у що ви по-справжньому вірите, спостерігайте за собою у кризовій ситуації. Якщо під час кризи ви не відхиляєтеся від своїх робочих методів, ви дійсно переконані в їх ефективності. Якщо ваш код залишається чистим у звичайний час, а в кризу ви розводите в ньому бруд, значить ви не вірите, що бруд уповільнює вашу роботу.
Виберіть методи, з якими ви комфортно відчуваєте себе в кризовій ситуації. А потім використовуйте їх постійно. Не змінюйте свою поведінку у напруженій ситуації. Якщо ваші методи дійсно оптимальні, то вони повинні дотримуватися навіть у найважчі часи. Якщо ви потрапили у скрутну ситуацію, довіряйте своїм методам.
За свою кар’єру ви відповідаєте самі. Ваш роботодавець не повинен піклуватися про вашу популярність на ринку праці. Він не повинен навчати вас, відправляти вас на конференції або купувати книги. Всім цим повинні займатися ви самі .
Читайте книги, статті, блоги, твіти. Відвідуйте конференції та збори власних груп. Беріть участь у дослідницьких групах. Вивчайте те, що лежить за межами звичної зони. Якщо ви програміст .NET – вивчайте Java. Якщо ви програмуєте на Java, вивчайте Ruby. Якщо ви програмуєте на C – вивчайте Lisp. А якщо вам захочеться серйозно попрацювати мізками, вивчайте Prolog та Forth!
Якщо ви не подбаєте про розширення власного кругозору, це може призвести до небажаного звуження резюме та менталітету.
Виконуйте громадсько-корисну роботу, беручи участь у проекті з відкритим кодом. Професійні програмісти тренуються особисто. Ваш роботодавець не зобов’язаний піклуватися про підтримку вашої кваліфікації або розширення вашого резюме.
Професійні розробники навмисно намагаються разом програмувати, разом тренуватись, разом проектувати та планувати. Найкращий спосіб чогось навчитися — вивчати інших. Факти запам’ятовуються найшвидше тоді, коли ви повинні їх повідомити іншим людям, за яких ви відповідаєте. Таким чином, основну користь від викладання отримує передусім викладач.
Відповідальність за навчання менш кваліфікованих програмістів покладається на їхніх досвідчених колег. Навчальних курсів недостатньо. Книг недостатньо. Ніщо не приведе молодого розробника до високої продуктивності швидше, ніж його власне бажання у поєднанні з ефективним навчанням старших товаришів.
Перший обов’язок професійного програміста – дбати про інтереси своїх роботодавців. Це означає, що ви повинні спілкуватися з вашими начальниками, бізнес-аналітиками, тестерами та іншими учасниками групи, щоб глибоко розуміти комерційні цілі проекту. Професійний програміст повинен виділити час вивчення комерційної боку справи.
Професіонал завжди допомагає бізнесу знайти спосіб досягнення його цілей, але він не завжди приймає він зобов’язання, прийняті за нього.
Професіонали не беруть на себе зобов’язань, якщо вони не впевнені в можливості їх виконання. Зобов’язанням властива визначеність. Інші люди приймають ваші зобов’язання та використовують їх як основу для побудови власних планів. Порушення зобов’язань обернеться величезним збитком для вашої репутації; це прояв непорядності, лише трохи кращий за відкриту брехню.
Професіонали проводять чітку різницю між оцінками та зобов’язаннями. Вони не беруть на себе зобов’язань, доки не будуть твердо впевнені в успіху. Також вони стежать за уникненням неявних зобов’язань. Вони наскільки можна чітко обумовлюють ймовірнісний розподіл своїх оцінок, щоб керівники могли будувати відповідні плани.
Професіонал зобов’язаний допомогти своїй групі створити програму настільки якісну, наскільки це можливо. А це означає, що всі повинні приділяти увагу можливим помилкам та промахам колег та спільно працювати над їх виправленням.
Кожен професіонал повинен розуміти предметну область програмованих ним рішень. Бути експертом не обов’язково, але до вивчення теми необхідно ставитись відповідально. Найгірший різновид непрофесіоналізму — просто програмувати за специфікацією, не розуміючи, чому ця специфікація підходить для вирішення свого завдання. Ви повинні мати достатні знання в предметній області для того, щоб розпізнати та виправити можливі помилки у специфікації.
Ретельно вибирайте формулювання, які ви використовуєте у своїх обіцянках, тому що, за словами, часто можна судити про подальший перебіг подій. Якщо вам не вдається підібрати потрібні слова, швидше за все, ви недостатньо відповідально ставитеся до сказаного або не вірите у його здійсненність.
Обіцяйте тільки те, що знаходиться під повним контролем. Якщо кінцева мета залежить від когось іншого, обіцяйте лише конкретні дії, які сприяють досягненню кінцевої мети. Якщо ви не можете виконати свою обіцянку, дуже важливо якнайшвидше повідомити про це того, кому ви обіцяли.
Професіонали говорять правду наділеним владою. У них достатньо сміливості, щоби сказати «ні» своїм начальникам.
Як сказати «ні» начальнику? Це ж ваш начальник! Хіба ви не повинні робити те, що каже начальник? Ні! Говоріть “ні”, якщо ви професіонал. Рабам забороняється говорити “ні”. Наймані працівники неохоче кажуть «ні». Але професіоналу належить говорити «ні». Більше того, добрим керівникам дуже потрібні люди, у яких вистачає сміливості сказати «ні». Тільки так можна справді чогось досягти.
Професіонал не повинен відповідати «так» на все, що від нього вимагають. Проте він має докласти максимум зусиль до того, щоб це так стало можливим. Коли професіонали говорять так, вони використовують такі формулювання, щоб у співрозмовника не виникало сумнівів у надійності їхніх обіцянок.
Професійні розробники мають лише одне визначення: виконано — значить виконано. Зроблено — це означає, що весь код написаний, всі тести пройдені, служба контролю якості та ключові учасники прийняли результат. Зроблено.
Найгірший із усіх видів непрофесіоналізму з боку програміста — це спроба видати недоробку за готовий продукт. Іноді це просто відкрита брехня, що досить погано. Але набагато небезпечніша інша ситуація — спроби підвести раціональну основу під нове визначення «готовності».
Ця хвороба заразна. Якщо одному програмісту така поведінка сходить з рук, інші бачать і наслідують його приклад. Один з них розширює визначення «готовності» ще далі, і всі інші наслідують його приклад. Коли група потрапляє до цієї пастки, начальство чує, що все йде нормально. Усі звіти про хід робіт показують, що роботу буде завершено до терміну. Ситуація нагадує пікнік сліпих на залізничних рейках: ніхто не бачить вантажний склад незавершеної роботи, що наближається, поки не буде занадто пізно.
Проблема хибної готовності вирішується створенням незалежного визначення готовності. Для цього слід доручити бізнес-аналітикам та фахівцям із тестування створити автоматизовані приймальні тести, без проходження яких продукт не може вважатися готовим. Тести мають бути зрозумілими для бізнесменів та ключових учасників проекту, не пов’язаних з технічною стороною.
Поспіх безглуздий. Ви не змусите програмувати себе швидше. Ви не змусите швидше вирішувати завдання. А якщо спробуєте — ви тільки уповільните роботу та влаштуєте хаос, який уповільнить роботу інших.
Щоб звести до мінімуму проблеми, пов’язані з відставанням, пам’ятайте про два найважливіші аспекти: раннє виявлення та прозорість. Найгірше, коли ви до останнього моменту запевняєте оточуючих, що роботу буде завершено вчасно, а потім підводьте всіх. Не робіть цього. Регулярно перевіряйте хід проекту по відношенню до кінцевої мети та уявіть три обґрунтовані кінцеві дати: найкращу, номінальну та гіршу.
На понаднормову роботу можна погоджуватися лише за виконання деяких умов: 1 — особисто ви можете її собі дозволити; 2 – аврал триватиме недовго, не більше двох тижнів, і 3 – у керівництва є резервний план на випадок, якщо ваші зусилля завершаться невдачею.
Професійні розробники навчаються керувати своїм часом так, щоб повною мірою використати свою ману концентрації. Ми пишемо код, коли резерв мани високий, а коли її залишається мало – займаємось іншими, менш творчими справами. Якщо ви витратите всю ману концентрації на зустрічі, то у вас залишиться менше ресурсів для програмування.
Професійні розробники управляють своїм графіком сну те щоб резерв мани концентрації досягав максимуму на той час, що вони вранці приходять працювати.
Після того, як мана піде, зберігати концентрацію силою волі неможливо. Ви можете писати код, але вам майже напевно доведеться переписувати його наступного дня.
Фізична концентрація допомагає відновити розумову, причому це більше, ніж проста перезарядка. Регулярні фізичні вправи підвищують потенціал інтелектуальної концентрації.
Якщо ви не можете достатньо зосередитися на своїй роботі, у вас вийде поганий код. У ньому буде багато помилок. Він матиме неправильну структуру. Він вийде заплутаним та непрозорим. Він не буде відповідати справжнім потребам замовника. Якщо ви втомилися або не можете зосередитися, не пишіть код.
Обов’язково стежте за сном, здоров’ям і способом життя, щоб ви могли щодня присвятити роботі вісім хороших годин.
Зустрічі коштують приблизно $200 на годину на кожного учасника. Тут враховуються зарплати, премії, витрати використання приміщення тощо.
Професіонали знають, що зустрічі коштують дорого. Ви не повинні відвідувати кожну зустріч, на яку вас запрошують. Більше того, відвідувати дуже багато зустрічей непрофесійно. Отримавши запрошення, не приймайте його, якщо ваша участь не пояснюється негайною і значною необхідністю для поточної роботи.
Один із найважливіших обов’язків вашого керівника — утримувати вас від участі в зайвих зустрічах. Хороший керівник більш ніж охоче захистить вашу відмову від участі, тому що ваш час представляє для нього таку ж цінність, як і для вас.
Ви повинні ефективно управляти своїм часом. Якщо ви застрягли на зустрічі, яка лише марно витрачає ваш час, знайдіть спосіб ввічливо покинути цю зустріч. Якщо вас просять прийти на зустріч, переконайтеся, що ви знаєте, які теми будуть обговорюватися, скільки часу на них виділено і яка мета має бути досягнута. Якщо вам не вдається отримати чітких відповідей на ці запитання, ввічливо відмовтеся від участі.
Зустріч має відбуватися досить швидко: коротке обговорення щодо кожного елементу списку реалізації, після чого елемент або вибирається, або відхиляється. На жодний елемент не повинно йти більше 5 або 10 хвилин. Якщо буде потрібне докладніше обговорення, заплануйте його на інший час з частиною групи.
Остерігайтеся зустрічей, які проводяться лише для придушення розбіжностей та підтримки однієї зі сторін. Також уникайте зустрічей, на яких присутня лише одна зі сторін, що сперечаються.
Одна з найгірших ознак неправильно функціонуючої команди — коли кожен програміст зводить стіну навколо свого коду і забороняє іншим програмістам торкатися його. Професійні розробники не забороняють колегам працювати зі своїм кодом. Працюючи з інших частин системи, вони вчаться друг в друга.
Професіонали поєднуються в пари, тому що це найкращий спосіб рецензування коду. Найефективніший і найдієвіший спосіб рецензування коду — участь у його написанні. Фахівці працюють разом.
Професіонали також поєднуються в пари, тому що це найкращий спосіб обміну знаннями. Професіонали не створюють «банки знань» — натомість вони вивчають різні аспекти системи та бізнесу, поєднуючись у пари.
Групи формуються не відразу. Між учасниками поступово налагоджуються стосунки. Вони вчаться працювати один з одним, дізнаються дивацтва, сильні та слабкі сторони своїх колег. Згодом учасники «притираються» один до одного.
У «притертій» групі є щось чарівне: вона здатна творити чудеса. Учасники розуміють один одного, підтримують та вимагають максимальної віддачі. Завдяки їхній взаємодії досягаються результати.
«Притерта» група разом планує, разом вирішує завдання, разом розбирається з проблемами та досягає результатів. Професійні фірми-розробники доручають проекти існуючим «притертим» групам, а чи не формують групи конкретного проекту.
“Притерта” група зазвичай містить близько дюжини учасників. До групи повинні входити програмісти, тестери та аналітики. І в неї має бути керівник проекту. Добре «притерта» група з 12 осіб може складатися із семи програмістів, двох тестерів, двох аналітиків та керівника проекту.
Створити добру групу складніше, ніж створити проект. Відповідно, краще формувати групи з постійним складом, які переходять від одного проекту до іншого і можуть займатися кількома проектами одночасно.
Штучний інтелект на 15% успішніше справляються із проходженням CAPTCHA, ніж живі люди. Такого висновку дійшли автори дослідження , на яке звернув увагу Quartz .
Експеримент був проведений групою фахівців із Microsoft, Швейцарської вищої технічної школи Цюріха, Каліфорнійського університету в Ірвайні та Ліверморської національної лабораторії.
У дослідженні взяли участь 1400 осіб, яким було запропоновано пройти тести на захист від роботів, які використовуються на 120 популярних ресурсах. Результати фахівці порівняли з показниками, які продемонстрували різноманітні роботи.
«Точність роботів коливається в межах 85-100%, причому у більшості вона перевищує 96%. Це істотно краще за показник, що спостерігається у людини (50–85%)», — йдеться у статті, опублікованій за підсумками експерименту.
Живі люди, за даними дослідників, можуть конкурувати з ШІ лише за проходження reCAPTCHA. Середньостатистичний користувач справляється із цим завданням за 18 секунд. У роботів на це йде 17,5 секунди.
В інтерв’ю для New Scientist результати дослідження прокоментував один із його авторів Джин Цудік. На його думку, вони свідчать, що технологія захисту від роботів перестала справлятися зі своїми завданнями і тепер приносить лише незручності.
“Всі ми знаємо, що ніхто не любить подібні тести. Для цього не потрібно проводити дослідження. Але не всі знають, чи варті зусилля, які ми прикладаємо для проходження CAPTCHA щодня, місяць, рік», — нарік учений.
Нагадаємо, в липні аналітики Стенфорда та Каліфорнійського університету опублікували дослідження, в якому стверджується, що новітні моделі чат-бота ChatGPT стали працювати гірше після спілкування з живими користувачам. Зокрема ще в березні цього року остання версія штучного інтелекту ідентифікувала прості числа з точністю 97,6%. До червня цей показник упав до 2,4%.
Можливо, ви вже чули про де які технології CSS, але не використовували їх, бо думали, що вони не підтримуються браузерами. Тепер можете сміливо брати їх у всеозброєння та застосовувати у своїх проектах!
Я вирішив в одному місці зібрати інформацію про кілька нових фічів, якими почав користуватися сам і вам раджу.
Інструменти, що надаються CSS, постійно розвиваються, з’являється багато нових фіч, але головною проблемою використання новинок залишається підтримка браузерами. Іноді доводиться чекати по кілька років, перш ніж те чи інше оновлення отримає достатню підтримку, і його можна буде використовувати.
Найпоширеніша проблема на мобільних пристроях при використанні vh – при розрахунку висоти не враховується висота навігаційної панелі, яка динамічно з’являється і зникає. Одиниці виміру svh, lvh, dvh вирішують цю проблему, дозволяючи позбутися непотрібного скролла.
Почнемо зі Svh (Small viewport height). Ця одиниця виміру задає найменший розмір viewport, коли відображається панель навігації.
Lvh (large viewport height) задає розміри найбільшого розміру viewport, коли панель навігації прихована.
І нарешті Dvh (Dynamic viewport height) динамічно змінює значення висоти щодо того, чи відкрита панель з навігацією чи ні.
Ці одиниці виміру можна використовувати прямо зараз, згідно сайту “Сan I use” , вони підтримуються у всіх сучасних браузерах.
Про них знає дуже багато, оскільки контейнерні запити з’явилися кілька років тому. Нині їхня підтримка стала достатньою, щоб використати в реальних проектах.
Контейнерні запити дозволяють змінювати стилі, спираючись розмір блоку, а чи не всього екрану на відміну від min-width, max-width.
Розглянемо найочевидніший приклад. У нас є список із 4 карток, у рядку міститься лише 3. Остання картка повинна розтягуватися на всю ширину, але при такому великому розмірі картинка та текст мають бути на одному рядку.
Щоб цього домогтися контейнера картки (.card) потрібно визначити властивість container-type у значенні inline-size. Тепер можна ставити стилі безпосередньо для дочірніх елементів. Поки картка більше 400px, до неї додаватимуться властивість display flex.
.card {
container-type: inline-size;
}
@container (min-width: 400px) {
.card__container {
display: flex;
align-items: center;
}
}Ось що вийшло.
Це лише невеликий приклад варіацій застосування контейнерних запитів безліч. Нині вони отримали широку підтримку, і їх можна використовувати.
Це невелика, але приємна зміна, що дозволяє використовувати більш зрозумілий синтаксис у медіазапитах. Звичайний синтаксис медіазапитів виглядав так:
@media (max-width: 1000px) {
/* ... */
}
@media (min-width: 1000px) and (max-width: 1400px) {
/* ... */
}З новим можна зробити цей запис коротшим і зрозумілішим для розуміння.
@media (width <= 1000px) {
/* ... */
}
@media (1000px <= width <= 1400px) {
/* ... */
}Крім цього доступні такі оператори порівняння:
Ці функції дозволяють розраховувати розміри елементів. Усередині них можна проводити обчислення так само, як і в calc.
Функція min приймає значення, вибираючи найменше. Передавати можна безліч значень. Наприклад, якщо задати 50vw і 500, при розмірі viewport 1400px, застосовується 500px, тому що 1400/2 = 700, 500 < 700. Але коли розмір viewport стане менше 1000px, буде використано значення 50vw.
Також у даних функціях можна порівнювати між собою та відносні значення. Функція max працює так само, як min, тільки повертає максимальне значення.
.element {
width: min(50vw, 500px);
}
.element {
width: min(10em, 30%, 30px);
}Та нарешті clamp. Функція приймає 3 параметри і задає значення між верхнім та нижнім кордоном.
.element {
width: clamp(250px, 100% / 3, 900px);
}Доки елемент не буде менше 250px і не більше 900px, його ширина буде розраховуватися за формулою 100% / 3.
Остання новинка CSS, що розглядається, є найспірнішою серед усіх описаних вище, тому що не підтримується в Safari і Mozilla. Але навіть якщо text-wrap: balance не застосовується, властивість нічого не зламає, тому можна використовувати. З цією властивістю браузер намагається збалансувати кількість символів у рядку, щоб вони були приблизно рівні за шириною.
Важливо: text-wrap: balance у своїй поточній реалізації дозволяє балансувати текст до 4 рядків. Якщо текст більше, воно не працюватиме.
Ми розглянули 5 нових фіч CSS, які допоможуть в адаптивній верстці. Якщо вам було корисно, підписуйтесь, я ділитися нововведеннями в CSS, доступних для застосування вже сьогодні.
У цій статті розберемо ще одну маловідому, але не менш корисну можливість@reduxjs/toolkit
Для початку розберемо варіанти та можливості типізаціїcreateAsyncThunk
Санки можна типізувати як за допомогою дженериків,
createAsyncThunk<Returned, ThunkArg, ThunkApiConfig>()
так і за допомогою безпосередньо аргументів
createAsyncThunk(
'asyncThunkTypePrefix',
(arg: ThunkArg, apiConfig: ThunkApiConfig) => {}
)
де:
– Returned– тип значення, що повертається санком значення
– ThunkArg– тип аргументу санка
– ThunkApiConfig– тип конфіга, його розберемо нижче
Я віддаю перевагу і раджу використовувати другий метод, оскільки немає необхідності вручну описувати тип значення, що повертається, особливо, коли ваш санк може повернути кілька видів помилок крім даних. Набагато простіше надати це Typescript‘у, він чудово аналізує всі виходи з санка і показує, наприклад, що повернутися може Data | Error | AxiosError, і ви не потопатимете у величезних повідомленнях про помилки типізації через те, що типізація в дженериках відрізняється від тієї, що бачитьTypescript
Тепер подивимося докладніше ThunkApiConfig:
Звернемося до документації thunkApi в@reduxjs/toolkit
Тут описані всі можливі поля та пояснення до них. Однак на практиці в основному використовується лише половина з них:
type Store = typeof store
type RootState = ReturnType<Store['getState']>
type AppDispatch = Store['dispatch']
type ThunkApiConfig = {
state: RootState
dispatch: AppDispatch
rejectValue: AnyErrorType
extra: AnyExtraArgumentType
}де:
– state: RootState– Тип вашого кореневого стейту. Значення такого типу повернеgetState
– rejectValue: AnyErrorType– Тип значення, яке ви будете використовувати вrejectWithValue
– extra: AnyExtraArgumentType– Тип будь-якого екстра аргументу, який ви опціонально використовуватимете у ваших санчатах
Оскільки нікому не хочеться щоразу описувати цей тип для кожного нового санка, часто використовуються функції-обгортки, що допомагають лише один раз описати тип ThunkApiConfig
export const createAppnAsyncThunk = <Returned, ThunkArg>(
type: string,
thunkPayloadCreator: AsyncThunkPayloadCreator<Returned, ThunkArg>,
): AsyncThunk<Returned, ThunkArg, ThunkApiConfig> =>
createAsyncThunk<Returned, ThunkArg, ThunkApiConfig>(type, thunkPayloadCreator)А тепер заглянемо в глибини документації, куди дістаються небагато людей і подивимося на спосіб, який нам пропонує бібліотека з коробки. createAsyncThunk.withTypes()
const createAppAsyncThunk = createAsyncThunk.withTypes<ThunkApiConfig>()
Як бачимо перший метод у порівнянні з другим вимагає написання більшої кількості і, що важливо, зрозуміти і розібратися з типами, що надаються @reduxjs/toolkit для типізації санків, що для новачків Typescriptможе бути зовсім не просто.
Ідея Network State викладена в однойменній книзі підприємця, інвестора та колишнього CTO криптовалютної біржі Coinbase Баладжі Срінівасана. У цій роботі бізнесмен пропонує алгоритм створення мережевих держав — альтернативних політичних утворень, що ґрунтуються на блокчейн-технологіях та інших інноваціях.
Згідно з Срінівасаном, соціальні та політичні зміни відбуваються повільніше, ніж технологічні. Це, на його думку, пов’язане із глобальним домінуванням національних держав. У такій ситуації реформи та експерименти з новими засобами громадської організації обмежені: політична кар’єра недоступна більшості і пов’язана з необхідністю інтеграції до існуючих інститутів влади.
На відміну від чиновників, підприємці не зобов’язані вбудовуватись у корпорації, щоб організувати свою справу; ринкова конкуренція збільшує різноманітність та якість товарів, генеруючи загальне благо та рухаючи прогрес. За формулюванням Срінівасана, «потрапити до списку Forbes значно простіше, ніж до списку президентів США».
Проект Network State пропонує використовувати динамізм ринку для прискорення соціального прогресу — будь-який бажаючий, використовуючи сучасні засоби комунікації та криптовалюти, може заснувати своє стартап-суспільство, подібно до того, як фаундер відкриває новий бізнес.
Засновник не скований спадщиною минулого і може вільно експериментувати з параметрами ком’юніті, яке згодом може стати мережевою державою.
За визначенням Срінівасана, Network State — це «соціальна мережа, що пропонує моральну інновацію, має почуття колективної самосвідомості, яка має визнаний засновник, здатність до колективної дії, певний рівень коректності в міжособистісній взаємодії, інтегрована криптовалюта, уряд, заснований на консенсусі смарт-контрактами, що має у розпорядженні архіпелаг фізичних територій, віртуальний капітал, що проводить ончейн-перепис населення, який показує, що мережева держава має достатню кількість людей, землі та достатку, щоб досягти певного дипломатичного визнання».
Під ключовими пунктами цього визначення автор має на увазі наступне:
Також Срінівасан розрізняє поняття «стартап-суспільства», «мережевого союзу», «мережевого архіпелагу» та «мережевої держави».
Стартап-суспільству не обов’язково еволюціонувати у повноцінну мережеву державу, подібно до того, як новий бізнес може не мати амбіцій перетворитися на глобальну корпорацію.
Моральна інновація — базовий пункт, навколо якого будуються всі перелічені об’єднання. Вона згуртовує членів спільноти, дає їм загальну ідентичність та мету для колективних дій. «Одна заповідь» може стосуватися бажаного способу життя, наприклад: «Віганство — найбільш корисна та етично прийнятна дієта для людини», або ціннісних положень: «Культура скасування шкодить суспільству».
Члени ком’юніті скоординовано діють як онлайн, так і офлайн, виходячи з «Однієї заповіді». Наприклад, учасники веганського стартап-товариства можуть розповсюджувати матеріали про користь відмови від продуктів тваринного походження або відкрити свій ресторан, а члени товариства проти культури відміни — шукати роботу людям, звільненим внаслідок травлення.
Cloud first, land next (but not land never) — принцип, згідно з яким стартап-товариства, перш ніж купувати землю та інші нецифрові активи, повинні організуватися онлайн. З мережевих комунікацій та колективної практики вони зможуть виробити етичні правила та самосвідомість приналежності до спільноти, а також розробити блокчейн-архітектуру для самоврядування та прийняття рішень.
Придбання землі потрібне для спільного проживання та відкриття бізнесів. На першому етапі Срінівасан рекомендує купувати ділянки поза великими містами у місцях, якими не зацікавлені корпорації та держави.
Придбані стартап-товариством території об’єднуються в архіпелаг за допомогою мережі.
Блокчейн – основна інфраструктура мережевої держави, що дозволяє учасникам засвідчувати особистість, володіти та обмінюватися цифровими активами, приймати управлінські рішення, реєструвати право власності, вступати у правові відносини з іншими громадянами, укладати шлюби тощо.
Усі взаємодії netizens, записані в блокчейн, дозволять завжди мати актуальні статистичні дані про стан держави. Роль законів у Network State гратимуть консенсуально прийняті смарт-контракти.
Срінівасан допускає появу інституту множинного громадянства: використовуючи Web3 -логін, людина зможе брати участь у житті відразу кількох мережевих держав.
Одна з найважливіших ідей Network State — ончейн-запис усіх значних верифікованих подій (the ledger of record — реєстр запису), історія, що «доводиться», яка дозволить уникнути маніпуляції минулим, а також бачити траєкторію розвитку держави.
За словами соціолога Павла Степанцова, гіпотетичний проект Баладжі Срінівасана можна поставити в низку сучасних техноутопій — способу проблематизації суспільних відносин, що виникає з уваги до нових технологій організації, спостереження та роблення видимими членами спільноти.
На відміну від великих проектів XX століття — анархізму та комунізму, в яких технології відіграють роль інструмента для досягнення політичної мети, у цих утопіях техніка розуміється як «форма життя». Соціальні відносини для них похідні від інновацій. Техніка формує нові форми суспільних взаємодій.
«Часто Срінівасана вважають послідовником лібертаріанства, але це не зовсім так. Лібертаріанство засноване на філософії утилітаризму: якщо ми досягнемо оптимального економічного стану, то соціальна складова піде за нею. Проект Срінівасана підкреслює важливість норм комунікації та морального підґрунтя людських спільностей. Він більш соціологічний і нагадує теоретизування соціолога Норберта Еліаса, який припускав, що надіндивідуальні структури утворюються із взаємодії людей і відтворюють себе за рахунок створення моральних і цінностей», — пояснює експерт.
Співзасновник Ethereum Віталік Бутерін у статті «Що я думаю про мережеву державу» виділив кілька пунктів, «з якими має проблеми»:
Бібліотеки reduxабо@reduxjs/toolkit надають велику кількість корисних утиліт, у цій статті я розповім про одну з них – bindActionCreators
Одна з проблем, що переслідує майже всіх, хто використовує вищезгадані бібліотеки – неможливість використання action(), попередньо не обернувши його в dispatch(). Це породжує велику кількість безглуздого коду:
const dispatch = useDispatch()
const handleReset = (id: number) => dispatch(actionReset(id))Спочатку розберемося з аргументами:bindActionCreators(actionCreators, dispatch)
actionCreators– об’єкт виду{ actionName: ActionDefinition }dispatch– відповідно dispatchз useDispatch()абоstoreДалі розберемо два способи використання за вищезгаданими методами одержанняdispatch
const useDispatchedActions = (actionCreators) => {
const dispatch = useDispatch()
return bindActionCreators(actionCreators, dispatch)
}Або в один рядок:
const useDispatchedActions = (actionCreators) => bindActionCreators(actionsCreators, useDispatch())Також приклад цього хук на TypeScript з прикладом типів
type Store = typeof store
type AppDispatch = typeof Store['dispatch']
type BoundAsyncThunk<Actionы extends ActionCreator<any>> = (
...args: Parameters<Action>
) => ReturnType<ReturnType<Action>>
type BoundActions<Actions extends ActionCreatorsMapObject> = {
[key in keyof Actions]: Actions[key] extends AsyncThunk<any, any, any>
? BoundAsyncThunk<Actions[key]>
: Actions[key]
}
const useDispatchedActions = <Actions extends ActionCreatorsMapObject = ActionCreatorsMapObject> (
actions: Actions,
): BoundActions<Actions> => {
const dispatch = useDispatch<AppDispatch>()
return bindActionCreators(actions, dispatch), [actions, dispatch]
}const getDispatchedActions = (actionsCreators) => bindActionCreators(actionsCreators, store.dispatch)Результат же – той самий об’єкт, який ми передавали в аргумент з однією відзнакою – ці екшени ми можемо використовувати без необхідності обертати їх викликdispatch()
Я б рекомендував вам використовувати другий метод використання bindActionCreatorsз двох причин:
useDispatchedActions, вам необхідно враховувати, що екшени, які ви отримуватимете з хука і використовуватимете в компонентах, eslintвимагатиме додати їх залежно від інших Reactхуків. А це може призвести до несподіваних помилок (наприклад, до нескінченних викликів useEffect).
Абстракція облікового запису – це метод налаштування блокчейн-мережі, при якому активи користувачів зберігаються виключно у смарт-контрактах, а не у зовнішніх облікових записах (External Owned Accounts, EOA). При використанні цього підходу криптогаманець перетворюється на унікальний смарт-контракт, який можна програмувати для різних цілей.
У березні 2023 року розробники Ethereum через смарт-контракт під назвою EntryPoint активували стандарт ERC-4337, який реалізує концепцію абстракції облікового запису та сумісний з усіма EVM-мережами на кшталт Polygon, Optimism, Arbitrum, BNB Smart Chain, Avalanche та Gnosis Chain. Рішення пройшло аудит Open Zeppelin.
ERC-4337 дозволяє перетворювати гаманці користувачів на облікові записи смарт-контрактів, щоб зробити адреси Ethereum зручнішими і запобігти втраті ключів.
Цей стандарт працює над наявною системою, для його повноцінного використання не потрібні суттєві зміни блокчейн-інфраструктури.
У криптоспільноті переконані, що система EOA обмежує можливості взаємодії користувачів із Ethereum. Зокрема, зовнішні облікові записи ускладнюють батчинг транзакцій. Також учасникам екосистеми необхідно зберігати на гаманці деяку кількість ETH для покриття витрат на газ при здійсненні транзакцій.
АОЗ – шлях до вирішення цих та багатьох інших проблем. Даний метод підвищує безпеку облікових записів користувачів, покращує користувальницький досвід і відкриває багато нових опцій для розробників.
Згідно з документацією до ERC-4337, ключовими елементами АОЗ є:
Всі ці елементи взаємодіють між собою, відкриваючи можливість Web3-розробникам створювати гаманці на основі смарт-контрактів та сумісні з новою системою dapps.
UserOperation – структура, яка характеризує операцію, що здійснюється користувачем. Так само, як і звичайна транзакція, вона містить параметри: sender, to, calldata, maxFeePerGas, maxPriorityFee, signature, nonce. Але є й додаткові елементи на зразок EntryPoint, Bundler та Aggregator.
Крім того, UserOperations відправляються в окремий мемпул. Там пакувальники можуть «загортати» їх у транзакції перед наступним включенням до блоку.
Ще одна “фішка” UserOperations – програмована автентифікація транзакцій.
Пакувальник моніторить альтернативний мемпул, спеціально створений для UserOperations. Він об’єднує кілька операцій користувача в одну транзакцію і відправляє її в контракт EntryPoint. Bundlers отримують винагороду за це, стягуючи частину плати за газ.
Пакувальники є критично важливим елементом інфраструктури в контексті ERC-4337. У заснованій на АОЗ екосистемі вони єдині учасники, яким необхідні зовнішні облікові записи.
EntryPoint — спеціальний контракт для верифікації та подальшої обробки UserOperations, що одержуються від пакувальників.
В ході процесу верифікації EntryPoint перевіряє, чи достатньо гаманця коштів для оплати газу. У процесі виконання операції контракт звертається до облікового запису через дані calldata, які визначені за допомогою UserOperation. Також EntryPoint стягує кошти з облікового запису на базі смарт-контрактів, щоб виділити Пакувальнику коректну кількість ETH для оплати газу.
Скарбник – смарт-контракт на основі ERC-4337, який реалізує різні підходи до використання газу. Він надає гнучкість використанню ресурсів, усуваючи необхідність зберігання нативних токенів на оплату транзакційних комісій.
Наприклад, учасники екосистеми можуть покривати витрати на газ не за допомогою ETH, а стейблкоінами на кшталт USDC або USDT. Крім того, з’являється можливість спонсорування оплати трансакційних комісій користувачів.
Агрегатор – Допоміжний контракт, призначений для валідації агрегованих підписів. Оптимізована обробка безлічі «пакетованих» UserOperations допомагає заощадити ресурси при взаємодії з даними calldata.
ERC-4337 створено на основі попередніх EIP – 2938 і 3074 . У першому сформульовано ідею про те, щоб смарт-контракти функціонували як «аккаунт вищого рівня, який оплачує комісії та ініціює виконання транзакції». Один із авторів EIP-2938 – співзасновник Ethereum Віталік Бутерін.
У EIP-3074 представлено ідею «делегування контролю над EOA смарт-контракту».
EIP-4337 поєднує основні тези попередніх EIP, але з додаванням альтернативного мемпулу. Використання нового стандарту не потребує внесення змін до рівня консенсусу.
Віталік Бутерін бачить в абстракції облікового запису каталізатор, який може залучити мільярд користувачів до мережі Ethereum.
За його словами, інтеграція технології дасть змогу оплачувати комісії не лише за допомогою ETH, а й іншими монетами, які перекладає користувач. Крім того, розширення дозволить децентралізованим програмам «спонсувати» транзакції для своїх клієнтів.
Завдяки технології «абстракції сигнатур» розробники роліпів зможуть компілювати підписи, що значно зменшить витрати на газ.
Інші переваги:
Однак є деякі труднощі на шляху реалізації АОЗ. Так, після перетворення всіх облікових записів користувачів на смарт-контракти функція повинна справно працювати в мережах другого рівня. Бутерин також допустив виникнення проблем при інтеграції з біометричними технологіями та гаманцями.
В даний час збереження коштів залежить від надійності зберігання приватних ключів і тісно пов’язаних з ними сид-фраз. Будь-хто, хто отримує доступ до цих цінних даних, по суті стає власником криптоактивів.
Це означає, що у разі втрати приватного ключа назавжди втрачається контроль над цифровими активами — вони або переходять до іншого, або заморожуються назавжди. Не дивно, що в мережі поширений фішинг, націлений на чужі сід-фрази.
Абстракція облікового запису вирішує цю проблему за допомогою використання смарт-контрактів для зберігання активів та авторизації транзакцій, також покращуючи користувальницький досвід.
Наприклад, з’являється можливість створення резервних ключів у разі втрати основних. Крім того, зберігання даних гаманця можна делегувати довіреним особам. При такому підході потенційному зловмиснику набагато складніше отримати повний контроль над засобами користувача.
Завдяки АОЗ можна зробити і так, щоб невеликі транзакції верифікувалися одним підписом, а великі — кількома.
Також смарт-гаманці надають можливості:
Абстракція облікового запису передбачає підтримку гаманців на основі смарт-контрактів на рівні протоколу. Це відкриває розробникам простір для експериментів з досвідом користувача (UX).
Одне з найбільш очевидних покращень UX – групування транзакцій для підвищення швидкості та ефективності операцій. Завдяки цьому обмін токенів на DEX можна буде робити в один клік разом зі схваленням витрачання активів.
Користувачам не потрібно турбуватися про достатню кількість ETH для оплати газу. При потребі сам смарт-контракт обміняє токени на ефір, використовуючи останній для оплати транзакційних комісій.
АОЗ також відкриває можливість довірених сесій. Це може стати в нагоді в ігрових додатках, де доцільно схвалення великої кількості дрібних транзакцій на короткий час.
Абстракція облікового запису може оптимізувати процес купівлі різних товарів, зробивши його подібною до взаємодії з традиційними маркетплейсами. Користувач зможе заповнити «кошик» потрібними предметами та придбати все одразу в один клік — проміжні транзакції та схвалення опрацює смарт-контракт.
В даний час активно розробляються гаманці на базі смарт-контрактів. У нових рішеннях зроблено акцент на безпеці та поліпшенні користувальницького досвіду.
На початку березня розробники платформи для управління цифровими активами Safe (раніше Gnosis Safe) представили SDK, яка вже доступна для використання в різних мережах.
Розробка під назвою Safe{Core} дозволяє використовувати АОЗ як альтернативу традиційним криптогаманцям із закритим та відкритим ключами.
Інструмент створений у співпраці з платіжним гігантом Stripe, а також провайдерами Web3-інфраструктури Gelato та Web3Auth.
«Абстракція облікового запису є ключем до залучення мільйонів нових користувачів. Вона покликана зробити використання Web3 таким самим зручним, як і Web 2.0», — заявив співзасновник Safe Річард Мейснер.
У липні проект інтегрував ERC-4337 у стек абстракції облікових записів для розробників Safe{Core} версії 1.4.1.
«ERC-4337 пропонує більш простий інтерфейс користувача, включаючи такі можливості, як вхід до системи без заповнення, соціальне відновлення, пакетні транзакції, налаштування гібридного зберігання та багато іншого», — зазначили представники Safe.
У TypeScript 5.2 з’явиться нове ключове слово ‘using’, яке можна буде використовувати для утилізації чогось за допомогою функції Symbol.dispose, коли воно залишає область видимості.
{
const getResource = () => {
return {
[Symbol.dispose]: () => {
console.log('Hooray!')
}
}
}
using resource = getResource();
} // 'Hooray!Він заснований на пропозиції TC39, яка нещодавно досягла третьої стадії (з чотирьох) у своєму просуванні до JavaScript. Це означає, що воно готове для тестування ранніми користувачами.
usingбуде надзвичайно корисним для управління такими ресурсами, як обробник файлів, з’єднання з базами даних і т.д.
Symbol.dispose – це новий глобальний символ JavaScript. Все, що має функцію, призначену Symbol.dispose, буде вважатися “ресурсом” – ” об’єктом з певним часом життя ” – і може бути використане з ключовим словом using.
const resource = {
[Symbol.dispose]: () => {
console.log("Hooray!");
},
};Для роботи з ресурсами, які необхідно утилізувати асинхронно, також можна використовувати Symbol.asyncDisposeі await.
const getResource = () => ({
[Symbol.asyncDispose]: async () => {
await someAsyncFunc();
},
});
{
await using resource = getResource();
}В результаті перед продовженням програми очікується функція Symbol.asyncDispose.
Це буде корисним для таких ресурсів, як з’єднання з базами даних, коли необхідно переконатися, що з’єднання закрито до продовження роботи програми.
Доступ до файлової системи через файлові обробники в node може бути значно простіше using.
Без using:
import { open } from "node:fs/promises";
let filehandle;
try {
filehandle = await open("thefile.txt", "r");
} finally {
await filehandle?.close();
}З використанням using:
import { open } from "node:fs/promises";
const getFileHandle = async (path: string) => {
const filehandle = await open(path, "r");
return {
filehandle,
[Symbol.asyncDispose]: async () => {
await filehandle.close();
},
};
};
{
await using file = await getFileHandle("thefile.txt");
// щось робим з file.filehandle
} // автоматично утілізован!Управління з’єднаннями з базами даних – один із найпоширеніших варіантів використання в C#.
Без using:
const connection = await getDb();
try {
// щось робим з connections
} finally {
await connection.close();
}З використанням using:
const getConnection = async () => {
const connection = await getDb();
return {
connection,
[Symbol.asyncDispose]: async () => {
await connection.close();
},
};
};
{
await using db = await getConnection();
// щось робим з db.connection
} // автоматично закрито!Переклад статті TypeScript 5.2’s New Keyword: ‘using’
Вирішив зробити невеличке прибирання в салоні мого малого (BMW X5 e53) 🙂
А також виправити невеличкі косяки на ляді. Попиловисив, повитирав шкіру серветками.
Потім ще поїхав на мийку самообслуговування.
Дуже цікаво провів час зі своєю улюбленою машинкою.
Тест Хауї (англ. Howey Test) — це перелік критеріїв, які допомагають визначити, чи має актив ознаки цінних паперів і чи є «інвестиційним контрактом».
Інструмент може також застосовуватися до проектів, комерційних угод та інших операцій.
Згідно з тестом Хауї, інвестиційний контракт існує, якщо є «вкладення грошей у спільне підприємство з розумним очікуванням прибутку, який можна отримати від інших зусиль».
У SEC переконані, що деякі криптоактиви та більшість ICO можуть кваліфікуватись як інвестиційні контракти.
Тест Хауї розробили та вперше задіяли на практиці у 1946 році. Приводом для його створення став розгляд SEC із фірмами WJ Howey Co. та Howey-in-the-Hills Service з Флориди.
Підприємства продали населенню ділянки цитрусової плантації. Інвестори домовились із представниками фірм про здачу ділянок в оренду. В результаті WJ Howey Co. з’явилася можливість вирощувати та збирати врожай на чужих землях, займатися маркетингом та ділити зі стейкхолдерами прибуток від продажу. При цьому більшість покупців не мали досвіду в землеробстві і не планували освоювати цю діяльність.
Верховний суд США дійшов висновку, що продані ділянки, по суті, були пропозицією незареєстрованих цінних паперів. Відповідно до закону, угоди мали ознаки інвестиційного контракту — учасникам потрібно було лише вкласти кошти для отримання джерела пасивного доходу.
На основі кейсу SEC vs. WJ Howey Co. з’явилися чотири критерії, що стали основними складовими Тесту Хауї:
Підхід прижився, і з тих пір критерії тесту Хау застосовуються для визначення приналежності різних активів до цінних паперів.
З розвитком ринку криптовалют, а особливо після буму первинних пропозицій монет 2017-2018 років, регулятори по всьому світу задалися питанням, чи мають нові активи властивості цінних паперів. З цією метою у деяких випадках американська SEC застосовує Тест Хауї.
Комісія з цінних паперів та бірж США випустила керівництво з використання вищезгаданого фреймворку щодо криптовалют та інших активів на базі блокчейну.
«Термін „цінний папір“ включає „інвестиційний контракт“, так само як і інші інструменти на кшталт акцій, облігацій та передані частки [в капіталі компаній]. Цифровий актив має бути проаналізований для визначення того, чи має він характеристики будь-якого продукту, що відповідає визначенню цінного паперу відповідно до федерального законодавства», — йдеться в документі SEC.
Один із яскравих прикладів застосування Тесту Хауї в контексті криптоіндустрії – кейс із токенсейлом Telegram. Проект TON залучив $1,7 млрд завдяки продажу монет Gram кваліфікованим інвесторам у США та за їх межами, проте так і не запустився через конфлікт із Комісією з цінних паперів та бірж США.
Інший приклад – позов SEC проти Ripple, поданий у 2020 році. Регулятор звинуватив компанію у поширенні незареєстрованих цінних паперів на суму близько $1,3 млрд. у вигляді нативних токенів платформи.
Однак справа, що тривала кілька років, набула несподіваного для багатьох учасників криптоспільства повороту. 13 липня 2023 року Суд Південного округу Нью-Йорка дійшов висновку, що програмні продажі та інші розподіли токена XRP від Ripple не є пропозицією та реалізацією інвестиційних контрактів.
У червні SEC подала до суду на біржу Binance та її CEO Чанпен Чжао, а також на американську компанію Coinbase. В обох випадках претензії стосуються незареєстрованих пропозицій токенів та сервісів для отримання пасивного доходу.
Нинішній глава Комісії Гері Генслер твердо переконаний, що криптовалюти – інвестиційні контракти. Отже, відповідальним за емісію монет платформ необхідно зареєструватися в SEC.
Криптоіндустрія, що багато в чому орієнтується на США, змушена зважати на Тест Хауї. Чимало проектів позиціонують цифрові активи, що випускаються, як токени управління (governance-токени), оскільки ті використовуються в голосуваннях в рамках ДАТ. Однак через правову невизначеність безліч проектів і, відповідно, активів можуть привернути увагу регуляторів.
У червні 2018 року діючий тоді глава SEC Джей Клейтон заявив, що біткоін не є «інвестиційним контрактом».
«Криптовалюти – це замінники суверенних грошей. Біткоїн може замінити долар, євро, ієну. Цей тип валюти не є цінним папером», – сказав він.
За словами Клейтона, до цінних паперів можна віднести токени, оскільки вони виконують роль цифрових активів і фінрегулятор США контролює цю сферу.
«Якщо я даю вам гроші, а ви створюєте підприємство і передаєте мені право на частку від спільного капіталу, то ми говоримо про цінні папери. Комісія регулює пропозиції подібних цінних паперів та торгівлю ними», – прокоментував він.
Також влітку 2018 року директор з корпоративних фінансів SEC Вільям Хінман заявив, що біткоїну та Ethereum більш властиві характеристики товару, що передбачає компетенцію Комісії з термінової біржової торгівлі США (CFTC).
“Якщо мережа криптовалюти досить децентралізована, а покупці не покладаються на третій бік у питанні управління, монета не є цінним папером”, – наголосив чиновник.
Практика показала, що схема першої половини минулого століття не враховує специфічних особливостей криптовалюту.
У цьому переконана і комісарка SEC Хестер Пірс. Вона підкреслила, що багато стартапів залучали фінансування під обіцянку побудувати мережу. Це створювало підстави для визнання токенів, що випускаються, як «інвестиційні контракти» по Тесту Хауї.
На думку Пірс, існування інвестиційного контракту залежить не тільки від активу, а й від обіцянок, що з ним асоціюються. Ці два компоненти не пов’язані один з одним, зазначила вона.
«Те, що я продала вам апельсиновий гай у рамках інвестиційного контракту, не перетворює його на цінний папір. Апельсинова гай плюс обіцянки про те, як я збираюся доглядати її і приносити вам прибуток, — це пропозиція цінних паперів», — пояснила Пірс.
Представниця SEC упевнена, що Тест Хауї сам по собі не дає однозначної відповіді на питання відповідності криптовалюти статусу інвестиційного контракту у відриві від самого процесу їх розміщення, в якому можна виявити подібні ознаки.
Відкрийте криптовалютну картку Trustee за кілька хвилин! Оплачуйте ваші покупки миттєво з автоматичною конвертацією