Багато твердо вірять в потенціал, яким володіє технологія блокчейн. Концепція консенсусу в рамках розподіленої мережі, а не центрального органу є невід’ємною і може принести вигоди для фінансової сфери, систем управління цифровими правами, систем голосування, контролю ланцюжків поставок і багатьох інших областей.
Але є і деякі проблеми блокчейн. Визнання перешкод, які можуть завадити поширенню blockchain, також є важливим аспектом. Чітке уявлення про ці бар’єри полегшить їх вивчення на ранній стадії кривої впровадження блокової ланцюжка і зробить більш імовірним процвітаючу екосистему блокчейн в майбутньому.
Маючи це на увазі, варто відзначити п’ять основних проблем, які слід враховувати при розвитку технології.
Сказати, що навколо блокової технології занадто багато галасу – це нічого не сказати. Незважаючи на те, що деякі експерти стверджують, що блокчейн – це панацея від усіх проблем, насправді існує безліч областей, де замінювати існуючі системи блоковими варіантами не має особливого сенсу.
Чому це так важливо? Тому що надмірне використання цієї технології має свої витрати. Коли яскраві передбачення не реалізуються, то на тлі втрати довіри стає все важче реалізовувати нові рішення в блокової екосистемі. Це стосується, в тому числі і багатьох підприємців, які намагаються уникати надлишку і працюють над тим, щоб запропонувати інвесторам добре продумані пропозиції і спроектовані під конкретний ринок продукти.
Часто кажуть, що блокчейн має абсолютну цілісність і не може бути скомпрометований або змінений. Але це спрощений погляд на технологію. Перш за все, варто відзначити, що в світі існує не один ланцюжок. Є безліч блок-ланцюжків. Деякі з них більш надійні, ніж інші.
По-друге, ланцюжок, яка володіє цілісністю сьогодні, може втратити її в майбутньому. Наприклад, типові системи, засновані на алгоритмі доказ виконання роботи (наприклад, мережа біткоіни), розроблені з припущенням, що жодна одиниця мережі не зможе контролювати більше 50% її потужності.
Мережа вузлів, які спільно керують блокової ланцюжком, може розвиватися з часом. Йдеться, в тому числі про способи, які можуть привести до різких змін. Наприклад, приведуть до того, що ключові припущення, що лежать в основі цілісності системи, більше не будуть виконуватися. З огляду на, що технології blockchain пропагуються для серйозних додатків (реєстри нерухомості або ведення корпоративної документації), які вимагають цілісності, що охоплює роки або навіть десятиліття, необхідно більше думати про механізми, спрямованих на забезпечення того, щоб відповідні бухгалтерські книги залишалися надійними протягом цих тимчасових періодів .
Крім того, потрібно думати і про те, що робити, якщо критично важлива блок-ланцюжок раптово втратить цілісність.
Початкові пропозиції монет (ICO) стали популярним підходом до залучення капіталу в кріптовалютной сфері, так як обходять багато перешкод, які пов’язані з більш традиційним процесом збору коштів шляхом створення венчурного капіталу. Але не всі з них є реально надійними проектами, які здатні забезпечити віддачу від інвестицій.
Ще одна потенційна проблема полягає в тому, що грошові кошти, залучені в ICO, іноді повністю не відповідають фактичним фінансовим потребам компанії. Справа в тому, що занадто багато грошей може вбити стартап так само, як і недолік фінансування. Коли на початковому етапі є занадто багато грошей, фінансова дисципліна має тенденцію виходити за встановлені рамки. Компанії часто наймають занадто багато людей без достатнього старанності з їх відбору, переплачують за деякі послуги і втрачають зосередженість, коли справа доходить до розробки кінцевого продукту.
Компанія-розробник програмного забезпечення не потребує сотнях мільйонів доларів для розробки продукту і випуску його на ринок. ICO, який приносить сотні мільйонів доларів, заснований просто на «Білій книзі», може бути причиною короткочасного тріумфу засновників компанії. Але для інвесторів така ситуація несе в собі туманні перспективи вкладених в проект коштів.
Це не означає, що всі ICO є поганими інвестиціями. Але підходити до цього питання потрібно з належною часткою реалізму. Навіть при всій належної обачності, якої дотримуються засновники проектів, більшість стартапів, що фінансуються через ICO, не стають успішними.
Надмірне регулювання може перешкоджати процесу впровадження інновацій. Але було б нереалістично стверджувати, що блокчейн взагалі не вимагає ніякого регулювання. Зрештою, ця технологія вже використовується для грошових переказів, укладання контрактів і випуску цінних паперів. Це має на увазі широту існуючих правових і нормативних рамок, які часто відстають від прогресу і не відповідають реаліям.
В результаті користувачам блокових ланцюжків важливо розуміти необхідність взаємодії із законодавцями і регулюючими органами, щоб останні могли краще розуміти цю технологію і її перспективи. На основі цього слід застосовувати і оновлювати необхідні закони і положення таким чином, щоб вони підтримували прогрес, а не перешкоджали розвитку інновацій.
Загрози в цифровому середовищі – це виклик в будь-якому сенсі цього слова. Особливо це стає актуальним у зв’язку з розвиваються спектром послуг, які засновані на blockchain. Це пов’язано з тим, що крім традиційної здатності зловмисників пристосовуватися до швидко мінливого цифровому ландшафту, екосистема блокової ланцюжка теж змінюється набагато швидше, ніж технології в інших областях.
В даний час розробляються і розгортаються нові системи, сервіси та підходи до блокчейну, які застосовуються практично щодня. Для людей, що створюють продукти на основі ланцюжка блоків, це означає, що вони не можуть користуватися таким же інформаційним перевагою в порівнянні з хакерами, щоб працювати в більш традиційної і стабільної середовищі.
Переклад статті “Blockchain Technology: Five Obstacles To Mainstream Adoption“
25 липня вийшов Angular 6.1. Даний мінорний реліз фреймворку можна розглядати як заміну Angular 6.0, що включає в себе деякі нововведення і виправлення помилок. Цей матеріал, переклад замітки з блогу Angular, присвячений основним новим можливостям Angular 6.1.
Тепер розробники Angular-додатків можуть скористатися новою можливістю маршрутизатора, яка дозволяє запам’ятовувати і відновлювати розташування користувача на сторінці – позицію прокрутки або скролінгу. При переході на чергову сторінку додатка позиція скролінгу скидається, при цьому запам’ятовується положення користувача на попередній сторінці. Натискання на кнопку «Назад» призводить до відкриття попередньої сторінки з урахуванням збереженої позиції прокрутки.
Для того щоб включити цю можливість, можна скористатися наступною командою:
RouterModule.forRoot(routes, {scrollPositionRestoration: 'enabled'})Очікується, що в майбутньому мажорному релізі платформи маршрутизатор за замовчуванням буде налаштований на відновлення позиції скролінгу.
Існує безліч способів зв’язування CSS-правил з компонентами, в яких визначені ці правила. Це називається View Encapsulation. Інкапсуляцію можна переключити на використання ShadowDOM v1 в Декораторі компонента. Робиться це так:
@Component({
templateUrl: './my-component.html',
encapsulation: ViewEncapsulation.ShadowDom
})
export class MyComponent { }
Тепер застосування значення ViewEncapsulation.Native, яке означає використання Shadow DOM v0, визнано застарілим.
ShadowDOM v1 відрізняється кращою крос-браузерної підтримкою, ніж попередня версія стандарту. Робота над цим стандартом спочатку велася з урахуванням можливості його використання в різних браузерах. Про відмінності Shadow DOM v0 і v1 можна почитати тут.
Нововведення ShadowDOM v1 будуть цікаві, в основному, авторам бібліотеки і просунутим розробникам. Треба відзначити, що застосування Shadow DOM v1 необхідно для використання проектування контенту (content projection) в рамках технології Angular Elements.
У цьому релізі були поліпшені можливості інструменту Schematics, в результаті тепер з існуючого правила можна повертати нове правило. Це дозволяє розробникам більш гнучко визначати набір правил для Schematics.
Тепер Angular, поряд з TypeScript 2.7, підтримує TypeScript 2.8 і 2.9. Одна з важливих можливостей TS 2.9, яка стане в нагоді багатьом розробникам, має відношення до помилок, до таких, як наступна:
Exported variable ‘x’ has or is using name ‘y’ from external module ‘z’ but cannot be namedВ TS внесені зміни, завдяки яким, по-перше, подібні помилки більше не з’являються, а, по-друге, більше не потрібно переписувати код для того, щоб привести його до стану, відповідному подібним шаблонами експорту.
У новому релізі Angular є й інші зміни, наприклад, що стосуються обробки неправильно сформованих URL (malformedUriErrorHandler) і спрямовані на поліпшення роботи з асоціативними масивами і об’єктами (KeyValuePipe). Вийшла і нова версія angular-cli.
Angular 6.1 є останнім запланованим мінорним релізом версії 6.x. Тому, в доступному для огляду майбутньому, можна очікувати виходу бета-версій Angular 7.0 і появи в цьому фреймворку нових цікавих можливостей.
Переклад статті “Angular v6.1 Now Available — TypeScript 2.9, Scroll Positioning, and more“
Одна з найбільш динамічних платформ в світі криптовалюта. BitShares криптовалюта (BTS) вважається сплячим гігантом з багатьох напрямків. Децентралізований обмін, який пропонує безліч інших фінансових послуг, може революціонізувати використання криптовалюта.
Пропонуючи децентралізовану торгівлю, унікальні «смарт-Коін» і звичайні банківські послуги, BitShares сподобався багатьом. З централізованими обмінами, що мають величезні проблеми по відношенню до криптовалюта, які намагаються адаптуватися в реальному світі, BitShares може бути вирішенням усіх питань.
Нові інвестори наповнили ринок криптовалют, коли ті стали популярними в 2017. Але перший набіг багатьох людей в кріптомір завершився вереском, коли вони спробували використовувати виведення грошей через звичайну біржу. Централізовані біржі буквально «засохли».
Відсутність безпеки, висока плата, повільні транзакції, сумнівна етика і так далі. Децентралізовані біржі, які проводять операції на базі блокчейн-технологій не мають таких проблем. А децентралізовані біржі, такі як BitShares, швидше, дешевше і безпечніше, ніж централізовані аналоги.
Mt Gox. BitStamp. Bitfinex. Досвідчені кріптовалютние інвестори знають таких гігантів кріптовалютного ринку, але для крипто-новачків це просто кріптовалютние біржі, які, колись, були зламані і втратили величезні суми грошей.
Mt Gox, наприклад, втратила близько 700 000 біткоіни, віддавши кошти невідомим хакерам, які скористалися проломом в системі. За сьогоднішніми ставками це цілі мільярди. Біржі постійно посилюють безпеку, але факт залишається фактом, що вони є гігантськими плаваючими цілями для хакерів. BitShares може виконувати транзакції за допомогою більш низьких тарифів і без потенційного ризику злому.
Багато централізовані біржі мають складний ринок або великі ліміти, але не BitShares. Це ваші гроші, ваші угоди. Ви можете торгувати будь-якою сумою, в будь-який час і в будь-якому місці, без обмежень на зняття коштів. BitShares також нейтральна по місцю розташування.
Високопоставлені трейдери на Уолл-стріт можуть маніпулювати ринками за допомогою блискавичних угод і сучасного обладнання, гарантуючи, що їх замовлення випередять ваші. BitShares запобігає цьому.
BitShares не можна Майнити. Делеговане доказ частки (DPOS) – це єдиний найоперативніший нарівні з функціоналом децентралізований варіант консенсусного протоколу. DPOS зчитує повноваження зацікавлених осіб для забезпечення чесного і досить демократичного способу вирішення питань, що вимагають консенсусу.
Доказ роботи, що використовується традиційно, є енергоємним. Системи DPOS визначають виробників блоків за допомогою голосування по котируваннях, в той час як системи PoW (англ. Proof-of-Work) визначають наступних виробників блоків за допомогою здатності комп’ютера виконувати роботу.
В системі DPOS в BitShares за виробників блоків голосують люди, які володіють монетами, в той час як блоки в біткоіни виробляються самим учасником мережі, у якого найбільше капіталу, щоб мати можливість займатися Майнінг.
Безпосередньо, за допомогою реальних засобів, будь-то долар, євро або рубль, купити BitShares, на жаль, неможливо. Спочатку необхідно купити, наприклад, Bitcoin або Ethereum, а вже за допомогою них придбати BTS. Нижче представлені найбільш зручні платформи для покупки.
Livecoin – це кріптообменнік, який є одним з найбільш зручних способом покупки і продажу криптовалюта.
Переваги трейдера включають: просту і ясну структуру, яка полегшує легку торгівлю. Гарантію безпеку даних і активів. Щодо більш швидкі депозити і зняття коштів.
Binance – це найбільш швидкозростаюча біржова крипто-платформа для криптовалюта сьогодні. Підвищена популярність може бути обумовлена такими факторами, як: доступність на декількох мовах, можливість обробки замовлень з дуже високою швидкістю, зручний призначений для користувача інтерфейс.
Гаманець BitShares – це мульти-кріптовалютний гаманець, за допомогою якого користувач може контролювати облікові записи, торгові активи і мати можливість відправляти токени по всьому світу.
Відкрита книга з відкритим регістром – перша децентралізована система обміну, яка пропонує шлюз для EURO, CNY, USD і інших мостів, доступних для стабільних і нестійких криптовалюта, таких як Litecoin, Steem, Peercoin, Doge, Ethereum і Bitcoin.
Це дозволяє кожному створювати свою власну монету на одному блокчейне з BitShares. Крім того, у кожного клієнта є обліковий запис, який підходить для роботи з конкретними запасами їх монет.
Існують як гаманці для Android систем, так і для настільних комп’ютерів. Настільні цифрові-гаманці BitShares є найбільш поширеними типами гаманців і являють собою програмні додатки, що встановлюються безпосередньо через оф. сайт BitShares.
Вони вимагають повного завантаження блокчейн-даних. Настільні гаманці найкраще використовувати, коли користувач володіє значним розміром крипто-засобів. Настільний гаманець підходить як для відправки середніх сум на віддалені адреси для покупок в Інтернеті, так і для зберігання певної кількості криптовалюта.
BitShares, швидше за все, спробує вибитися в перші ряди топ-100 криптовалюта в 2018 році. Із загальної досвіду користувачів очевидно, що BitShare може бути в зовсім іншому технологічному поле на тлі інших криптовалюта.
BitShare – це відносно молода розробка, однак вона вже займає свою частку на ринку. Ця кріптовалютная платформа забезпечила таке необхідне початок еволюції в світі криптовалюта.
BitShares можна розглядати як мережу, як банк і валюту. BitShares працює і працює відмінно з 2015 року, але цікавим чином викликала інтерес у дуже небагатьох людей. Власна криптовалюта BitShares (BTS) в даний час входить в число 30 найбільших цифрових активів і має ринковий холдинг в розмірі приблизно 1 126 966 682 доларів США.
В даний час, капіталізація BitShares становить трохи більше 2,6 млрд. BTC в доповнення до 1 млрд. Резервів, що належать BitShares.
Під час свого розпочата, в жовтні 2014 року, BitShares торгувався в діапазоні нижче одного цента, але сьогодні його вартість значно зросла до рекордного піку в $ 0,45. Інвестори вважають, що до кінця 2018 року BitShares може дійти до планки в $ 1,5.
BitShares – одна з кращих реалізацій відкритою, масштабованої і децентралізованої платформи для обміну смарт-Коін, які є новим фінансовим інструментом в крипто-просторі.
Переклад статті “Криптовалюта BitShares“
Біткойн – це чудова інвестиція, якщо ви вклалися в нього рано і вийшли на піку. Більшість людей вірить в технологію блокчейн, на якій заснований біткойнов і яка все ще виглядає багатообіцяюче.
Блокчейн – це персональний комп’ютер 1980-х рр., Інтернет 1990-х рр., Мобільний телефон 2000-х рр. і соціальні мережі 2010-х рр. Вкладетеся вчасно, знайдіть (або створіть) в аналог Apple, Google, Apple (знову) або Facebook і через 10 років ви станете мільйонером / мільярдером.
Як же скористатися цією, здавалося б, безпрограшної можливістю?
По-перше, блокчейн – це не безпрограшна можливість. Блокчейн може виявитися лише еволюційної стадією, попередником більш стійкою і зрозумілою технології, яка стане прибутковою. Блокчейн має властивості, які так необхідні існуючому цифрового світу: ефективністю, конфіденційністю, прозорістю і безпекою. Але це не означає, що блокчейн – ідеальне і безперечне втілення всіх цих концепцій. Я вважаю, що якби не криптовалюта, зокрема біткойнов, який став першим гідним застосуванням блокчейна, ця технологія стала б лише ще однією нудною чимось особливим. Так, легко спокуситися на можливість заробити грошей з повітря, але лише деякі розуміють справжню цінність токенов, що грають роль аутентифікатор для двох кінцевих точок.
Іншими словами, інвестувати в блокчейн ще занадто рано. Але це нікого не зупиняє.
Я не брокер і не буду радити вам, як розміщувати кошти. Я скажу тільки, що незалежно від того, який варіант ви виберете, після прочитання цієї статті необхідно дізнатися ще дуже багато додаткової інформації.
Отже, перед вами чотири способи інвестицій в технологію блокчейн, починаючи з самого ризикованого і закінчуючи найбезпечнішим.
Що я маю на увазі…
Важко посперечатися з доходом в 10 000%, але є один контраргумент – цей дохід повинен бути інвестований 10 000% назад.
Криптовалюта – це не блокчейн, а найбільш прямий спосіб інвестування в застосування цієї технології. Цей спосіб також найбільш ризикований. Тут ставка йде не тільки на технологію блокчейн, яка стає все більш популярна, але і на те, що люди будуть використовувати цю технологію правильно, що їх концепція вірна, що у них є кошерний код і ретельно продуманий спосіб використання, що їх бізнес-модель дійсно буде працювати. Все це типові ризики стартапів.
Роблячи ставку на монети і маркери, ви також ставите на те, що їх автори не вирішили сісти в потяг, що у них гідні моральні принципи, що це не типова схема накачування і скидання або НЕ піраміда, створена навмисно або випадково, а також що компанію не зламають, не обдурять, що не будуть шантажувати і не засудять.
Тут можете придумати будь-який жарт про Уолл-стріт.
Кращим радою щодо інвестування в монети я вважаю наступне: проведіть ретельне комплексну перевірку і потратьте гроші на покупку монет різних платформ. Потім помістіть ці монети в гаманець і вважайте їх втраченими, а через десять років знайдіть їх, як це зробив 50-Cent.
Я б тримався подалі від ICO. Зараз на ринку дуже багато пустушок, щоб визначити, який проект реальний, а який ні. Вкладення величезної суми грошей в один проект одноразово нагадує мені чашку Петрі для жадібності. Я не кажу, що все ICO – це сумнівна схема, я лише кажу, що в 2010-х рр. навіть у IPO були проблеми, які у випадку з ICO лише збільшуються.
Я б теж не інвестував в токени. Токени для мене занадто абстрактним поняттям, щоб вважати їх гідною інвестицією. Токени існували і раніше: покупка предметів у відеоіграх, монети в віртуальному казино. Я б не конвертував долари в токени, якби не хотів відразу їх витратити на покупку світлового меча або місця за віртуальним столом для покеру. Якщо чесно, я і цим не займаюся, тому що отримую те, що мені потрібно, в процесі самої гри.
Висновок з мого попереднього твердження: блокчейн – це не біткойнов і не будь-яка інша монета. Це нова і не зовсім доведена технологія, яка створює нову і не зовсім доведену парадигму транзакцій.
Але все ж блокчейн – це технологія, не застосування технології, і парадигма може вирішити серйозну проблему. А це означає, що інвестувати в блокчейн-стартап менш ризиковано, ніж інвестувати в криптовалюта.
Проблема полягає в тому, що дуже важко знайти або навіть визначити справжній блокчейн-стартап.
Багато блокчейн-стартапи – це просто стартапи, які використовують блокчейн для створення монет, токенов або способу передачі монет або токенів від однієї особи іншій з будь-якою метою.
Це як біткойн, але занадто пізній біткойн.
Інші види стартапів використовують блокчейн, тому що не змогли знайти інших варіантів. Я не хочу їх лаяти, особливо якщо подивитися на відкриті акціонерні товариства, заикающиеся про монетах, токенах і блокчейне і швидко збирають кошти (які зазвичай також швидко випаровуються). Як справи, Kodak?
Але я засуджую стартапи, які пропонують додаткові можливості завдяки блокчейну. Це виглядає як ще один епізод з Кремнієвої долини, де кожна компанія на революційній сцені проголошує себе Со (ціальної), Мо (більной) і Ло (кальной). Дехто називає себе Мосолов, деякі соломи, але в дійсності всі вони Б (ред) С (собачий).
Існує кілька цікавих блокчейн-проектів, які за основу беруть швидше технологію, ніж валюту. Сьогодні такі проекти з’являються в сфері фармацевтики, фінансів, нерухомості, джерел походження продуктів, практично у всіх індустріях, де необхідно відкрите цифрове відстеження у величезних кількостях. Але я не вважаю, що успішне застосування технології вже знайдено. Ще не дуже, але досить рано, і переможці виявляться ще не скоро.
Якщо у вас є кошти і бажання інвестувати в блокчейн-стартап, то, швидше за все, це не перший ваш стартап. Як і у випадку з будь-якою іншою інвестицією, проведіть дослідження, комплексну перевірку, але перш за все переконайтеся, що компанія використовує блокчейн заради блокчейна, що вона намагається знайти рішення існуючої проблеми, а не шукає проблему, для якої може знайти тимчасове, але спокусливе рішення.
Тут ступінь ризику падає з божевільного рівня до повсякденного, крім того, це найпростіший спосіб інвестування. Це досить нова концепція, існує кілька (принаймні чотири на момент написання) фондів, що перебувають в обігу на біржі і дозволяють відстежувати блокчейн-компанії. Це так звана корзина продаються на біржі акцій компаній, що використовують блокчейн або мають відношення до блокчейну і криптовалюта.
Всі вони дуже ясно дають зрозуміти, що не інвестують в криптовалюта безпосередньо, тому цей спосіб в значній мірі більш безпечний.
Проблема полягає в тому, що важко зрозуміти, наскільки компанії дійсно пов’язані з блокчейном.
Я вклав в один з подібних фондів (BLOK) невелику суму, але тільки тому, що мені сподобалася їхня корзина активів і той факт, що фонд веде активну діяльність. Я ставлю на те, що керуюча команда фонду зацікавлена в появі і еволюції блокчейн-додатків, а не в хайп.
Серед провідних активів BLOK присутні такі компанії апаратного забезпечення, як Taiwan Semiconductor, NVidia і AMD. Потім там також беруть участь компанії торгової сфери Overstock і Square. IBM також бере участь у фонді, а значить, це не сама ультрасучасна сфера для вкладень.
У цьому способі інвестицій немає доходу в 10 000%, але і ризики зовсім звичайні.
Прошу не лаяти мене за підприємницький підхід, але все ж це найкращий спосіб інвестування. Низькі ризики, високий потенційний дохід, справжній блокчейн і абсолютний контроль над процесом.
Біткойн був технологічної золотою лихоманкою. Будь-який інженер, який володіє достатнім досвідом у цій сфері, спостерігав кілька золотих лихоманок і навчився цінувати їх за те, що вони собою представляють – двигуни напрямку ринку. На початку статті я вже перерахував «велику четвірку» цих лихоманок. Блокчейн нагадує мені більшість золотих лихоманок додатків початку 2010-х рр.
У той час ми спостерігали схожу ситуацію – з’являлися додатки, які прагнули змінити світ, за ніч виникали тисячі стратап, компанії залучали величезні інвестиції, технології виходили з ніш і ставали повсякденними. Сьогодні, коли туман розвіявся, більшість з цих стартапів давно канули в лету, але не існує людей, які не використовують перші мобільні технології.
Родзинка блокчейна полягає в тому, що ця технологія створює зрушення парадигми. Вона може змінити спосіб обміну інформацією, як це зробив Інтернет, який об’єднав комп’ютери усього світу, а мобільні телефони стали особистими цілодобовими комп’ютерами кожної людини. Це були сміливі ідеї, і блокчейн може забезпечити безпечну і ефективну передачу цінностей між двома комп’ютерами і двома людьми.
Такий спосіб необов’язково повинен грунтуватися на монетах або валюті, але однозначно існують застосування кращі, ніж кріптокотікі. Це величезне поле можливостей для доведеною технології, яка стає все сильніше.
Саме тому я так одержимий блокчейном. Він схожий на шведський стіл в казино, де пропонують різні технічні можливості, а почати можна з будь-хто.
І не кажіть, що ви не можете це зробити. Всього за пару вихідних я створив основу для власної криптовалюта і описав все, що вивчив за цей час, в своєму короткому курсі по блокчейну і криптовалюта.
Почніть. Займіться освітою. Інвестуйте час в вивчення цієї технології. Потім знайдіть велику проблему і вирішите її.
Переклад статті “Four ways to invest in blockchain ranked from riskiest to safest“
У цій статті ми оцінимо базовий бізнес-функціонал основних платформ, орієнтованих на підприємництво, включаючи Ethereum, Hyperledger Fabric і R3 Corda, в плані того, на чому грунтується вплив програмного забезпечення і як система в цілому оптимізована, чи то за допомогою традиційних розподілених систем або на сучасної блокчейн-основі.
Блокчейн Ethereum володіє як подібностями, так і відмінностями в порівнянні з такими технологіями розподіленого реєстру, як Hyperledger Fabric або R3 Corda. Для обґрунтованої оцінки блокчейнов і платформ розподіленого реєстру і їх цінності для підприємств корисно класифікувати платформи на підставі їх базового функціоналу і характеристик. Оскільки блокчейни побудовані на принципах криптографії та конфігурації даних, їхні функції можуть бути відтворені у координованих системах баз даних, тоді як інші можливі тільки в справжньому середовищі блокчейна.
| Hyperledger Fabric | R3 Corda | Ethereum |
| Технологія розподіленого реєстру | Технологія розподіленого реєстру | Блокчейн |
Зокрема, ми зосередимося на трьох ключових областях функціоналу:
Цілі блокчейнов, таких як Ethereum, схожі з цілями розподілених реєстрів. Визначити, чого бізнес сподівається досягти за допомогою технології блокчейна, може бути непросто, тому що, як було у випадку інтернету в 1990-х, бізнеси поки не знають, як концептуалізувати застосування цього потужного інструменту. Сьогодні відомо, що технологія блокчейна здатна реалізувати різні функції, але те, як впровадити ці функції в бізнес-рішення, вимагає більш глибокого розуміння і оцінки базових можливостей.
Три основних досліджуваних осі – обробка та координування даних, довірені і незмінні записи і дигитализация активів – досить широкі, щоб охопити основні області застосування блокчейна і в той же час екстраполювати ці функції на бізнес-сценарії. Обговорення цих трьох аспектів дозволяє відповісти на питання, навіщо бізнесу використовувати цю технологію.
Якщо поліпшена структура розподіленої системи або координування бази даних – єдина мета протоколу або платформи, то не обов’язково потрібен блокчейн. Блокчейн-платформи традиційно просували концепції поліпшеного координування даних і розподілених механізмів консенсусу, де дані передаються і підтримуються технологічною платформою. Незважаючи на їх корисність, значна частина цих бажаних функціональних якостей може бути отримана за допомогою поліпшеного координування централізованої бази даних або поліпшеної структури розподілених систем. В даному дослідженні необхідно визначити, в якій мірі платформи і протоколи намагаються оптимізувати існуючий функціонал координування даних в протиставленні з впровадженням нового функціоналу блокчейна. Блокчейни призначені для більшого.
Початковий тезу про те, навіщо нам потрібні блокчейни, будувався на концепції дигіталізації довіри. Ендрю Кіс з ConsenSys просував наступний мотив: «Точно так само як інтернет привів до дигіталізації інформації, блокчейни ведуть до дигіталізації довіри і угод». Такий змістовний тезу уособлює ідеал того, чого сподіваються досягти блокчейни, в той же час готуючи грунт для подальшого шляху. Додатковою змінної можна вважати дигіталізацію вартості. Коли вартість прив’язана до довіри, впровадженому в систему, певні структури вирівнювання і механізми мотивації будуть стимулювати належну поведінку в системі, що призведе до життєздатної платформі.
Часто незмінюваність при проектуванні системи використовують синонімічно з довірою, т. Е. Якщо система незмінна, то можна довіряти, що погану поведінку не залишиться безкарним. Але в нашому аналізі платформних протоколів важливо також оцінити механізми реалізації довіреної системи, що забезпечують бізнес-модель, яка може бути вигідною для користувачів платформи (подальше дослідження за допомогою кріптоекономікі).
Дигитализация товарів і активів вважається головною метою більшості блокчейнов і платформ розподіленого реєстру. Якщо бізнеси шукають дигіталізації активів, розподілене реєстр або координовані бази даних здатні запропонувати деякі можливості, проте необхідно приділити багато уваги питанню доступності таких цифрових товарів. Оскільки координовані бази даних фактично знаходяться на центральному управлінні або розподілені між групою або підгрупами контрагентів за допомогою старої програмної парадигми, рівень дигіталізації може бути обмеженим у залежності від волі, пропонованої платформою дигіталізації. Хоча концепція дигіталізації товарів може здаватися простим процесом, різні динаміки мотивації і економічні міркування щодо того, як дігіталізіровать такі продукти, як нерухомість,
Записи та регістри, такі як системи прав власності і ланцюжки поставок, також можуть бути реалізовані за допомогою систем розподіленого реєстру, хоча їх рівень взаємодії з шаром економічної мотивації досить обмежений в разі залежності від закритої приватної системи, і проникнення таких активів в цифрову екосистему або на ринок при побудові на закритих системах буде сильно загальмовано. Для сприяння істинним цифрових товарів в постійно розвивається цифровий екосистемі необхідна вільно-ринкова система, в повній мірі використовує різні аспекти, які здатний надати відкритий ринок.
Хоча проводився глибокий аналіз функціоналу цих платформ в контексті таких характеристик, як незмінність, безпеку, масштабованість, керованість і продуктивність, набагато більше дозволяє встановити розуміння основ, на яких побудовані дані архітектури.
Для належного координування даних в розподілених системах винайдено і реалізовано безліч інструментів. Прикладом може служити сильний акцент на таких інструментах, як Hadoop і різні ансамблі в даній екосистемі, включаючи Spark, Hive і ZooKeeper. Використання цих продуктів свідчить про активну інтеграції розподілених системних інструментів і протоколів. Подальші паралелі можна побачити в таких протоколах, як Tendermint, консенсусна машина, вирішальна завдання візантійських генералів, що має схожий функціонал з такими інструментами, як Apache ZooKeeper. Проводилися також дослідження в напрямку баз даних – джерел подій (event sourcing), здатних відтворювати деякі бажані функції координованих систем обміну даними.
За допомогою оцінки таких інструментів, як Apache Kafka, і того, яким чином сервіси потокової передачі даних здатні досягти істотних рівнів пропускної здатності в корпоративному середовищі, можна встановити функціональні відмінності блокчейна і розподіленого реєстру на основі різних рівнів залежно від цих інструментів координування і оптимізації баз даних в плані фундаментальних концепцій. Реалізації Ethereum, включаючи Plasma, використовують такі інструменти, як MapReduce, для поліпшення певного map-функціоналу поверх UTXO і облікового моделі, в той же час звертаючи компоненти в докази Меркле, хоча важливо розуміти, що базовий рівень протоколу і раніше, покладається на Ethereum як на кореневої блокчейн. Розібравши ці деталі, можна отримати розуміння того,
Глибоке занурення в архітектуру Fabric дозволяє визначити, що платформа створила витончену середу розробки, фокусується на наданні поліпшеною пропускної спроможності на основі детальної конфігурації програмної архітектури для оптимальної продуктивності в середовищі розподілених систем. Рух чейнкода (chaincode) між клієнтом і мережею розподілених підтверджують вузлів, поряд з транзакційними механізмами і передачею свідчень, які відповідають політиці підтвердження, реалізовано в закритій системі, тоді як gossip-протокол, що поширює транзакції по приватним каналам, забезпечує координування великих масивів даних. Хоча така інфраструктура стійка і ефективна, необхідно приділити додаткову увагу тому, як архітектура робить можливими багатосторонні координаційні структури,
Основна ідея в тому, що канали надають можливість для переміщення транзакцій всередині платформи. Якщо поглянути на архітектуру, впорядковують сервісні вузли служать для запису транзакцій в впорядковує сервісі Apache Kafka. В екосистемі потокової передачі даних Kafka є потужним інструментом з можливістю додавання транзакцій різних видів в окремі кластери і потім розділи Kafka.
У такій схемі дані можуть розподілятися по кластерам для освіти розподіленої платформи зберігання, здатної записувати структури даних, які іноді називають «блоками» або «станами» в контексті їх конфігурації зберігання ключ / значення. В даному програмному фреймворку заслуговує на визнання та концепція, що всі учасники і структури даних в екосистемі є вбудованими в тому сенсі, що вони функціонують, головним чином, поряд з іншими користувачами даної програмної екосистеми.
Fabric дійсно використовує подструктуру реєстрового типу, що реалізовує певний зберігання даних з хешировать зв’язками, проте слід визнати, що конфігурація хешів не буде наслідувати оригінальним архітектурним дизайном, пов’язаному з блокчейновимі системами, похідними від Bitcoin або Ethereum. Хоча блоки даних об’єднуються в пакети і піддаються подій типу deliver для подальшого створення хешировать зв’язку транзакцій, необхідно розуміти, що даний процес не обов’язково переводить дані в модифікацію стану системи. Швидше блоки конфігурувати так, що інформація зберігається в структурі типу бази даних з різними прикладами хешів.
В екосистемі Fabric deliver -події називаються блоками, тоді як чейнкод проходить через deploy -події, щоб в подальшому убезпечити дані в chain -Розділ впорядкує сервісної структури. Конфігурація структур даних і модулів цієї системи уможливлює трансакціонної пропускну здатність, якої варто очікувати від архітектури розподіленої бази даних, однак слід визнати, що завдання координування активів і коду в екосистемі Fabric все ще повністю не вирішена, тому що активи і значення не обов’язково мають цифрове уявлення, яке можна координувати в реєстрі.
R3 Corda побудована в середовищі, що не претендує на те, щоб називатися блокчейном, але швидше за представляє собою децентралізовану базу даних, яка використовує різні форми структурної реконфігурації для побудови системи, яка, головним чином, використовувалася б банками та іншими інститутами для їх процесів. Платформа багато запозичує у моделі UTXO, використовуваної в транзакціях біткойнов, де стан визначається серією входів і виходів і різні реконфігурації входів можуть диктувати стан виходу.
Архітектурний фреймворк R3 Corda використовує вузлову структуру, належну на підмодулі, звані засвідчувач, які допомагають підтримувати узгодженість мережі, подібно валідаторним структурам інших платформ, абстрагується функцію консенсусу. Вузли доповнюються реляційними базами даних, що дозволяють робити запити за допомогою SQL. Транзакційна комунікація обмежується подпротоколамі, званими потоками.
Ці потоки можна порівняти з архітектурою каналів IBM Fabric, де доступ до інформації мають тільки сторони, причетні до транзакцій. Класи піддаються трансформаціям, результатами яких є машини станів, звані волокнами або співпрограмами. Архітектура покладається на комунікацію потоків з підпотоків і їх взаємодія з бібліотеками потоків, що мають зумовлені функції в межах платформи. Крім того, в Corda є автономний шар ідентичності, що робить можливою різну ступінь контролю доступу в рамках загальної мережі.
Хоча R3 Corda відкрито заявляє, що не претендує на те, щоб називатися блокчейном, варто взяти до відома, що реконфігурація концепції розподіленої бази даних в децентралізовану досить істотно покладається на традиційні системи баз даних. Хоча система спроектована на базі новаторських структур даних і відмінних побудов організації розподіленої системи, платформа дійсно має на увазі розподіл даних і шукає способи оптимізації функцій системи розподілу даних. Необхідно мати на увазі, що оскільки система обмежена певними аспектами координування даних в рамках специфічної архітектури, інтеграція в блокчейн-системи як такі не передбачена, так як в оригінальному дизайні не було реалізовано модулярних і інтероперабельність.
Екосистема Ethereum побудована на комбінації екосистем приватних і публічних блокчейнов. Публічний блокчей не має такої пропускної здатності і таких можливостей обробки даних, які описані в контексті координування даних, а тому не повинен оцінюватися на основі цих можливостей. При оцінці цього аспекту Ethereum найбільш логічно синтезувати різні нюанси мережевий топології приватних реалізацій Ethereum.
Yellow Paper Ethereum чітко декларує набір характеристик, складових Ethereum, а також технічну деталізацію кодової бази. Через таку суворої прихильності проекту даного протоколу Форк Ethereum і корпоративні реалізації дійсно нагадують оригінальний фундамент, на якому побудована технологія. По суті, одні й ті ж характеристики зберігаються в реалізаціях з доказом виконання роботи, доказом повноважень або доказом частки володіння, тому що протоколи вважаються похідними одних і тих же специфікацій Ethereum Virtual Machine (EVM).
Модифіковані архітектури все одно передбачають узгодженість з оригінальною EVM. У числі змін до таких платформах, як Quorum, – зміна консенсусного механізму, модифікація коренів глобальних станів для пристосування до приватним і публічним станів, зміна префіксного дерева «Patricia» і додаткові модулі для управління приватними транзакціями. Архітектура дозволяє цього ПО зберегти спадкоємність і структури даних оригінальної конфігурації Ethereum, в той же час пропонуючи поліпшену трансакціонної пропускну здатність, можливу завдяки модифікаціям. На додаток до пропонованої Quorum оптимізації транзакцій, можливість координування і інтеграції з суспільним середовищем Ethereum за допомогою таких інструментів, як Plasma, TrueBit і Cosmos, дає протоколу додаткову широту
З технічної оцінки таких інструментів, як Plasma і формати досягнення консенсусу в Casper, очевидно, що в Ethereum будуть використовуватися такі інструменти управління базами даних, як MapReduce і абстрактні системи переписування. У Plasma MapReduce є невід’ємною частиною координування облікового системи і структури бітової карти UTXO в мультічейновой схемою.
Парадигма організованою обробки транзакцій з використанням взаємодії рутчейнов, Plasma-Чейні і чайлдчейнов за допомогою комбінації дизайнів механізмів з доказом обману і мотиваційних структур на основі гарантійних зобов’язань допомагає забезпечити динаміку між поверхнями утримання блоківі масового виходу . Це також дозволяє реалізувати додаткові кріптоекономіческіе структури, використовуючи механізми таких систем, як Casper або TrueBit, для відображення концепцій видаляє кодування (erasure coding) в плані поширеною в даному просторі проблеми доступності даних. Що стосується мультічейновой архітектури, то Ethereum повинен бути здатний комбінувати координування баз даних і можливості пропускної здатності розподіленої системи баз даних з можливостями власне блокчейна, сумісними з публічної реалізацією.
Переконливе висновок про спектр можливостей з координування баз даних зводиться до того, що у IBM кращі інструменти управління базами даних завдяки використанню традиційних баз даних і програмної архітектури розподілених систем на основі загального монолітного дизайну та істотно ресурсоємних процесу, який пішов на розробку Fabric. R3 Corda ще більше конкретизує свої можливості, пропонуючи ряд послуг з координування банкам і фінансовим інститутам в приватній реконфігурації нюансів протоколу біткойнов. Ethereum, будучи призначеним для сумісності з публічними блкочейнамі, не має первинних можливостей по обробці баз даних IBM Fabric, але включає деякі схеми координування в контексті масштабованості для застосування на підприємствах, які не мають у Fabric.
Приватні реалізації Ethereum і додаткові клієнти можуть виступати архітектурними цеглинками, на яких можуть будуватися більші системи на основі модульного дизайну, умовно дотримується філософії Unix. Пов’язані з Ethereum кодові бази призначені для того, щоб скласти конкуренцію можливостям по транзакционной пропускної здатності таких платформ баз даних, як Fabric, в той же час роблячи можливим функціонал, якого немає ні в Corda, ні в Fabric, хоча можна також досліджувати комплементарні відносини між платформами. Головні чесноти може додатково прояснити аналіз чинників, про який ми поговоримо в наступній частині дослідження.
Переклад статті “Blockchain vs. Distributed Ledger Technologies“
Я дуже радий оголосити, що корпорація Майкрософт купує GitHub і очікує, що до кінця року ця угода буде закрита. Хоча це ще займе кілька місяців для завершення, ми хотіли поділитися новинами, як тільки змогли.
Коли GitHub вперше запустив десять років тому, я б ніколи не міг уявити цей заголовок. Гіт був потужним, але нішевим інструментом, хмари були просто неба, і Microsoft була дуже іншою компанією. Відкрите джерело та бізнес, люди говорили в той час, змішані, а також нафту та воду.
Ми не погодилися. Як розробники, ми знали, що це була помилкова дихотомія – ми довгий час успішно використовували програмне забезпечення з відкритим кодом у бізнес-середовищі. Нам дійсно було легше працювати з іншими, незалежно від того, чи цей код є загальнодоступним, приватним чи щось іншим. Ми хотіли це зробити, використовуючи Gіt, ми хотіли, щоб хтось у світі міг вступити, і ми не хотіли, щоб він стоїть на нім, якщо він був відкритим вихідним кодом. Тому ми створили GitHub.
Тепер, звичайно, речі різні. Gіt далеко від найпопулярнішої системи контролю версій, хмари в основному є комп’ютерами, а Microsoft є найактивнішою організацією на GitHub у світі. Проект VS Code alone відомий мільйонами розробників, повністю відкритим вихідним кодом і побудований за допомогою платформи GitHub Electron. Крім того, сьогодні великі підприємства регулярно охоплюють відкрите джерело. Світ зрозумів, наскільки важливими є щасливі, продуктивні розробники. А також у людей є смартфони.
Проте, що не змінилося, це наша увага до розробника. З самого початку ми були одержимими створенням продукту для людей, які використовують його. Ми хочемо зробити розробників більш продуктивними, і ми хочемо, щоб дедалі більше людей стали розробниками. Від “Коду до хмари та коду до краю”, місія GitHub полягає в тому, щоб допомогти кожному розробнику – незалежно від рівня досвіду навчання, коду та коду програмного забезпечення.
Оскільки ми дивимося на наступне десятиліття розробки програмного забезпечення та поза ним, ми знаємо, що це все про розробника. І тому, що ми отримали інформацію про команду Microsoft протягом останніх кількох років, співпрацюючи над проектами від Git LFS до Electron, ми дізналися, що вони погоджуються. Їхня робота з відкритим вихідним кодом надихнула нас, успіхи придбань Minecraft та LinkedIn показали нам, що вони серйозно ставляться до того, щоб добре розвивати бізнес, а зростання Azure показало, що вони є інноваційною платформою розвитку.
Але більше того, їхнє бачення майбутнього тісно відповідає нашим власним. Ми обидва вважаємо, що GitHub повинна залишатись відкритою платформою для всіх розробників. Незалежно від вашої мови, стеків, платформ, хмар або ліцензій, GitHub і надалі буде вашим будинком – найкращим місцем для створення програмного забезпечення, співпраці та відкриття.
Ми обидва вважаємо, що розробка програмного забезпечення повинна стати простішою, доступною, розумнішою та більш відкритою, тому більше людей можуть стати розробниками, а існуючі розробники можуть витрачати більше часу, зосередивши увагу на унікальних проблемах, які вони намагаються вирішити.
Ми бачимо зростаючу потребу розробників і зростаючу важливість програмного забезпечення у всіх аспектах нашого життя.
І, головне, ми обидва віримо, що ми можемо робити все більше, ніж самостійно. Співпраця, в кінцевому рахунку, лежить в основі всього, що ми робимо.
У рамках цієї зміни Нат Фрідман займе роль генерального директора GitHub. Ми вже деякий час шукали нового генерального директора та знайшли в Microsoft і Nat партнер, який, на нашу думку, посилить і розвиватиме спільноту та компанію GitHub протягом найближчих років. Нат має багатий досвід роботи з програмним забезпеченням та спільнотою програмного забезпечення з відкритим кодом, згодом заснував Xamarin і працював над численними проектами з відкритим кодом протягом багатьох років, і є ідеальною людиною, яка допомагає GitHub розвиватися і продовжувати вдосконалювати життя для розробників.
Що стосується мене, я буду брати на себе нову роль в Microsoft, тісно співпрацюючи з Nat і командою, і надалі ділиться докладніше.
Я надзвичайно пишаюся тим, що GitHub та наша спільнота здійснили протягом останнього десятиліття, і я не можу чекати, щоб побачити, що буде вперед. Майбутнє розробки програмного забезпечення є яскравим, і я дуже радий приєднатися до сил з Microsoft, щоб допомогти зробити це реальністю.
Генеральний директор @defunkt та співзасновник GitHub
Переклад статті “A bright future for GitHub“
Кілька днів тому ми написали повідомлення про майбутні зміни наших застарілих методів життєвого циклу, включаючи поступові стратегії міграції. У Реакції 16.3.0 ми додаємо кілька нових методів життєвого циклу, щоб допомогти цій міграції. Ми також представляємо нові API для довго запрошених функцій: офіційний API контексту, API пересилання, а також ергономічний API-інтерфейс.
Прочитайте далі, щоб дізнатися більше про випуск.
Протягом багатьох років React пропонував експериментальний API для контексту. Незважаючи на те, що це був потужний інструмент, її використання було затьмарене через невід’ємні проблеми в API, і тому ми завжди мали намір замінити експериментальний API кращим.
Версія 16.3 представляє новий контекстний API, який є більш ефективним і підтримує перевірку статичного типу та глибокі оновлення.
Примітка.
Старий контекстний API продовжуватиме працювати на всіх випусках React 16.x, тому ви матимете час для переміщення.
Ось приклад, який показує, як можна вписати “тему” за допомогою нового контекстного API:
const ThemeContext = React.createContext('light');
class ThemeProvider extends React.Component {
state = {theme: 'light'};
render (){
return (
<ThemeContext.Provider value={this.state.theme}>
{this.props.children}
</ThemeContext.Provider>
);
}
}
class ThemedButton extends React.Component {
render () {
return (
<ThemeContext.Consumer>
{theme => <Button theme = {theme} />}
</ThemeContext.Consumer>
);
}
}
Дізнайтеся більше про новий контекстний API тут.
createRef APIРаніше React пропонував два способи управління refs: застарілою API string ref і API зворотного виклику. Хоча API string ref був більш зручним з двох, він мав кілька недоліків, і тому наша офіційна рекомендація полягала в тому, щоб використовувати замість форми форми зворотного виклику.
Версія 16.3 додає нову опцію для управління рефами, що пропонує зручність рядка без будь-яких недоліків:
class MyComponent extends React.Component {
constructor(props) {
super(props);
this.inputRef = React.createRef();
}
render() {
return <input type="text" ref={this.inputRef} />
}
componentDidMount() {
this.inputRef.current.focus();
}
}
Примітка:
Функція зворотного виклику продовжуватиме підтримуватися на додаток до нового createRef API.
Вам не потрібно замінювати зворотний виклик у ваших компонентах. Вони дещо гнучкі, тому вони залишаться як розширені можливості.
Дізнайтеся більше про новий createRef API тут.
forwardRef APIКомпоненти вищого порядку (або HOCs) є поширеним способом повторного використання коду між компонентами. Розділяючи на прикладі контексту теми згори, ми можемо створити HOC, який вводить поточну “тему” як приклад:
function withTheme(Component) {
return function ThemedComponent(props) {
return (
<ThemeContext.Consumer>
{theme => <Component {...props} theme={theme} />}
</ThemeContext.Consumer>
);
};
}
Ми можемо використовувати вказане вище HOC для компонування проводів до контексту теми без використання ThemeContext безпосередньо. Наприклад:
class FancyButton extends React.Component {
buttonRef = React.createRef();
focus() {
this.buttonRef.current.focus();
}
render() {
const {label, theme, ...rest} = this.props;
return (
<button
{...rest}
className={`${theme}-button`}
ref={this.buttonRef}>
{label}
</button>
);
}
}
const FancyThemedButton = withTheme(FancyButton);
// We can render FancyThemedButton as if it were a FancyButton
// It will automatically receive the current "theme",
// And the HOC will pass through our other props.
<FancyThemedButton
label="Click me!"
onClick={handleClick}
/>
HOCs зазвичай передають реквізити до компонентів, які вони обертають. На жаль, посилання не передаються. Це означає, що ми не можемо прикріпити посилання, FancyButton якщо ми використовуємо FancyThemedButton – так що нам не можна зателефонувати focus().
Новий forwardRef API вирішує цю проблему, надаючи спосіб перехопити ref та переслати його як звичайну підтримку:
function withTheme(Component) {
// Note the second param "ref" provided by React.forwardRef.
// We can attach this to Component directly.
function ThemedComponent(props, ref) {
return (
<ThemeContext.Consumer>
{theme => (
<Component {...props} ref={ref} theme={theme} />
)}
</ThemeContext.Consumer>
);
}
// These next lines are not necessary,
// But they do give the component a better display name in DevTools,
// e.g. "ForwardRef(withTheme(MyComponent))"
const name = Component.displayName || Component.name;
ThemedComponent.displayName = `withTheme(${name})`;
// Tell React to pass the "ref" to ThemedComponent.
return React.forwardRef(ThemedComponent);
}
const fancyButtonRef = React.createRef();
// fancyButtonRef will now point to FancyButton
<FancyThemedButton
label="Click me!"
onClick={handleClick}
ref={fancyButtonRef}
/>;
API-клас компонентів React-у не мав протягом багатьох років великих змін. Однак, оскільки ми додаємо підтримку для більш просунутих функцій (таких як error boundaries і майбутній async rendering mode ), ми розтягуємо цю модель таким чином, що вона не була спочатку призначена.
Наприклад, за допомогою поточного API, занадто легко заблокувати початкове відтворення з несуттєвою логікою. Частково це пов’язано з тим, що занадто багато способів виконувати певне завдання, і це може бути незрозумілим, що є найкращим. Ми помітили, що перериваюча поведінка обробки помилок часто не враховується і може призвести до витоку пам’яті (щось що також вплине на майбутній режим рендеринга асинхронного типу). Поточний компонент API класів також ускладнює інші зусилля, як наша робота над прототипом компілятора React.
Багато з цих проблем поглиблюються підмножина компонентів (життєвий цикл componentWillMount, componentWillReceiveProps і componentWillUpdate). Це також стає життєвими циклами, які викликають найбільше плутанини в спільноті React. З цих причин ми будемо зневажати ці методи на користь кращих альтернатив.
Ми визнаємо, що ця зміна вплине на багато існуючих компонентів. Через це міграційний шлях буде настільки поступовим, як і можливе, і забезпечить втечу. (У Facebook ми підтримуємо більш ніж 50 000 компонентів React. Ми також залежимо від поетапного циклу випуску!)
Примітка:
Попередження попередження буде включено з майбутнім випуском 16.x, але застарілі життєві цикли будуть продовжувати працювати до версії 17.
Навіть у версії 17, вони все одно зможуть їх використовувати, однак вони будуть згладжуватись з префіксом "UNSAFE_", щоб вказати, що вони можуть викликати проблеми. Ми також підготували автоматичний скрипт для перейменування їх у існуючий код.
Окрім того, що ви втрачаєте небезпечні життєві цикли, ми також додаємо пару нових життєвих сюрпризів:
getDerivedStateFromProps додається як більш безпечна альтернатива спадщині componentWillReceiveProps.getSnapshotBeforeUpdate додається для підтримки безпечного читання властивостей, наприклад, DOM, до того, як будуть оновлені.Дізнайтеся більше про ці зміни життєвого циклу тут.
StrictMode КомпонентStrictMode це інструмент для виявлення потенційних проблем у програмі. Любіть Fragment, StrictMode не відображає видимого інтерфейсу. Він активує додаткові перевірки та попередження для своїх нащадків.
Примітка:StrictMode чеки виконуються тільки в режимі розробки; вони не впливають на виробництво.
Хоча для суворого режиму неможливо усунути всі проблеми (наприклад, певні типи мутацій), це може допомогти багатьом. Якщо ви бачите попередження в строгому режимі, ці речі, швидше за все, призведуть до помилок для асинхронного візуалізації.
У версії 16.3 StrictMode допомагає:
Додаткові функціональні можливості будуть додані в майбутніх версіях React.
Дізнайтеся більше про StrictMode компонент тут.
Переклад статті “React v16.3.0: New lifecycles and context API“
Після оригінальних хакв JavaScript, ось деякий новий синтаксичний цукор.
Кодування JavaScript в 2018 році це насправді весело!
Використовуйте Array Destructuring для зміни значень.
let a = 'world', b = 'hello' [a, b] = [b, a] console.log(a) // -> hello console.log(b) // -> world // Yes, it's magic
Ще раз, Array Destructuring чудово поєднується з async/await і обіцяє зробити складний потік – простим.
const [user, account] = await Promise.all([
fetch('/user'),
fetch('/account')
])
Для тих, хто любить налагоджувати використовуючи console.log, ось щось дивовижне (і так, я чув про console.table):
const a = 5, b = 6, c = 7
console.log({ a, b, c })
// outputs this nice object:
// {
// a: 5,
// b: 6,
// c: 7
// }
Синтаксис може бути набагато компактнішим для операцій масиву.
// Find max value const max = (arr) => Math.max(...arr); max([123, 321, 32]) // outputs: 321 // Sum array const sum = (arr) => arr.reduce((a, b) => (a + b), 0) sum([1, 2, 3, 4]) // output: 10
Оператор розповсюдження може використовуватися замість concat:
const one = ['a', 'b', 'c'] const two = ['d', 'e', 'f'] const three = ['g', 'h', 'i'] // Old way #1 const result = one.concat(two, three) // Old way #2 const result = [].concat(one, two, three) // New const result = [...one, ...two, ...three]
Клонувати масиви та об’єкти з легкістю:
const obj = { ...oldObj }
const arr = [ ...oldArr ]
Примітка. Це створює неглибокий клон.
Створення функцій і функціональних викликів більш читабельних при руйнуванні:
const getStuffNotBad = (id, force, verbose) => {
...do stuff
}
const getStuffAwesome = ({ id, name, force, verbose }) => {
...do stuff
}
// Somewhere else in the codebase... WTF is true, true?
getStuffNotBad(150, true, true)
// Somewhere else in the codebase... I ❤ JS!!!
getStuffAwesome({ id: 150, force: true, verbose: true })
Переклад статті “7 Hacks for ES6 Developers“
За допомогою unit тестів ми можемо переконатися, що окремі частини програми працюють саме так, як ми від них очікуємо.
Це в деякій мірі рятує від поломок існуючий код, допомагає прояснити – як він буде працювати в тих чи інших випадках. І, врешті-решт, дозволяє подивитися на код, так скажімо, з боку, щоб побачити його слабкі сторони.
Навіть існує думка, що складно тестований код – претендент на переписування.
Мета даної статті – допомогти в написанні unit тестів для Angular 5+ додатки. Нехай це буде захоплюючий процес, а не головний біль.
Що стосується unit тестування Angular додатки, то можна виділити два види тестів:
При ізольованому підході ми тестуємо сервіс як звичайнісінький клас з методами.
Спочатку створюємо екземпляр класу, а потім перевіряємо, як він працює в різних ситуаціях.
Перш ніж переходити до прикладів, необхідно позначити, що я пишу і запускаю тести за допомогою jest, так як сподобалася його швидкість. Якщо ви віддаєте перевагу karma + jasmine, то приклади для вас також будуть актуальні, оскільки відмінностей в синтаксисі зовсім небагато.
jasmine.createSpy ( 'name') -> jest.fn ()
and.returnValue () -> mockReturnValue ()
spyOn (...). and.callFake (() => {}) -> jest. spyOn (...). mockImplementation (() => {})
Розглянемо приклад сервісу для модального вікна. У нього всього лише два методи, які повинні розсилати певне значення для змінної popupDialog. І зовсім немає залежностей.
import { Injectable } from '@angular/core';
import { ReplaySubject } from 'rxjs/ReplaySubject';
@Injectable()
export class PopupService {
private popupDialog = new ReplaySubject<{popupEvent: string, component?, options?: {}}>();
public popupDialog$ = this.popupDialog.asObservable();
open(component, options?: {}) {
this.popupDialog.next({popupEvent: 'open', component: component, options: options});
}
close() {
this.popupDialog.next({popupEvent: 'close'});
}
}
При написанні тестів не потрібно забувати про порядок виконання коду. Наприклад, дії, які необхідно виконати перед кожним тестом, ми поміщаємо в beforeEach. Так, створений в коді нижче екземпляр сервісу нам знадобиться для кожної перевірки.
import { PopupService } from './popup.service';
import { SignInComponent } from '../components/signin/signin.component';
describe('PopupService', () => {
let service: PopupService;
// создаем экземпляр PopupService
beforeEach(() => { service = new PopupService(); });
// done нужно, чтобы тест не завершился до получения данных
it('subscribe for opening works', (done: DoneFn) => {
// вызываем метод open
service.open(SignInComponent, [{title: 'Попап заголовок', message: 'Успешно'}]);
// при изменении значения popupDialog$ должен сработать subscribe
service.popupDialog$.subscribe((data) => {
expect(data.popupEvent).toBe('open');
done();
});
});
it('subscribe for closing works', (done: DoneFn) => {
service.close();
service.popupDialog$.subscribe((data) => {
expect(data.popupEvent).toBe('close');
done();
});
});
});
А тепер подивимося на всю потужність утиліти TestBed. Як приклад для початку візьмемо найпростіший компонент:
import { Component } from '@angular/core';
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent {
title = 'app';
}
Файл шаблону:
<h1>
Welcome to {{ title }}!
</h1>
Файл тестів розберемо по шматочках. Для початку ставимо TestBed конфігурацію:
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [
AppComponent
],
}).compileComponents();
}));
compileComponents – метод, який робить винесені в окремі файли стилі і шаблон вбудованими.
Цей процес є асинхронним, так як компілятор Angular повинен отримати дані з файлової системи.
Якщо ви використовуєте WebPack, то цей виклик і метод async вам не потрібен. Справа в тому, що WebPack автоматично перед запуском тестів вбудовує зовнішні стилі і шаблон.
Відповідно, і при прописуванні стилів і шаблону всередині файлу компонента компілювати самостійно не треба.
Для тестів необхідно, щоб компоненти скомпілювати до того, як через метод createComponent () будуть створені їх екземпляри.
Тому тіло першого BeforeEach ми помістили в asynс метод, завдяки чому його вміст виконується в спеціальній асинхронної середовищі. І поки не буде виконаний метод compileComponents (), наступний BeforeEach не запуститься:
beforeEach(() => {
fixture = TestBed.createComponent(AppComponent);
comp = fixture.componentInstance;
});
Завдяки винесенню в beforeEach всіх загальних даних, подальший код виходить значно чистіше.
Для початку перевіримо створення екземпляра компонента і його властивість:
it('should create the comp', => {
expect(comp).toBeTruthy();
});
it(`should have as title 'app'`, () => {
expect(comp.title).toEqual('app');
});
Далі ми хочемо перевірити, що змінна компонента title вставляється в DOM. При цьому ми очікуємо, що їй присвоєно значення ‘app’. А це привласнення відбувається при ініціалізації компонента.
Запустивши за допомогою detectChanges CD цикл, ми инициализируем компонент.
До цього виклику зв’язок DOM і даних компонента не відбудеться, а отже тести не пройдуть.
it('should render title in a h1 tag', () => {
fixture.detectChanges();
const compiled = fixture.debugElement.nativeElement;
expect(compiled.querySelector('h1').textContent)
.toContain('Welcome to app!');
});
import { TestBed, async, ComponentFixture } from '@angular/core/testing';
import { AppComponent } from './app.component';
describe('AppComponent', () => {
let comp: AppComponent;
let fixture: ComponentFixture;
beforeEach(async(() => {
TestBed.configureTestingModule({
declarations: [
AppComponent
],
}).compileComponents();
}));
beforeEach(() => {
fixture = TestBed.createComponent(AppComponent);
comp = fixture.componentInstance;
});
it('should create the comp', () => {
expect(comp).toBeTruthy();
});
it(`should have as title 'app'`, () => {
expect(comp.title).toEqual('app');
});
it('should render title in a h1 tag', () => {
fixture.detectChanges();
const compiled = fixture.debugElement.nativeElement;
expect(compiled.querySelector('h1').textContent)
.toContain('Welcome to app!');
});
});
Давайте усложним наш компонент, запровадивши в нього сервіс:
export class AppComponent {
constructor(private popup: PopupService) { }
title = 'app';
}
Начебто поки не особливо ускладнили, але тести вже не пройдуть. Навіть якщо ви не забули додати сервіс в providers AppModule.
Тому що в TestBed ці зміни теж потрібно відобразити:
TestBed.configureTestingModule({
declarations: [
AppComponent
],
providers: [PopupService]
});
Ми можемо вказати сам сервіс, але зазвичай краще замінити його на клас або об’єкт, який описує саме те, що нам необхідно для тестів.
Чому?
А ви уявіть сервіс з купою залежностей і вам все доведеться при тестуванні прописати. Не кажучи вже про те, що ми тестуємо в даному випадку саме компонент. Взагалі, тестувати щось одне – це як раз про unit тести.
Отже, прописуємо стаб наступним чином:
const popupServiceStub = {
open: () => {}
};
Методи задаємо тільки ті, які тестуємо.
class popupServiceStub {
open() {}
}
providers: [{provide: PopupService, useClass: popupServiceStub } ]
У TestBed конфігурацію додаємо providers:
providers: [{provide: PopupService, useValue: popupServiceStub } ]
Не варто плутати PopupService і PopupServiceStab. Це різні об’єкти: перший – клон другого.
Відмінно, але ми ж сервіс впроваджували не просто так, а для використання:
ngOnInit() {
this.popup.open(SignInComponent);
}
Тепер варто переконатися, що метод дійсно викликається. Для цього спочатку отримаємо екземпляр сервісу.
Так як в даному випадку сервіс заданий в providers кореневого модуля, то ми можемо зробити так:
popup = TestBed.get(PopupService);
Якби мова йшла про сервіс, який прописаний в providers компонента, то довелося б отримувати його так:
popup = fixture.debugElement.injector.get(PopupService);
Нарешті сама перевірка:
it('should called open', () => {
const openSpy = jest.spyOn(popup, 'open');
fixture.detectChanges();
expect(openSpy).toHaveBeenCalled();
});
Наші дії:
Зауважте, що перевіряємо ми саме виклик методу сервісу, а не те, що він повертає або інші речі, що стосуються самого сервісу. Їх, щоб зберегти розум, варто тестувати в сервісі.
Зовсім недавно (в Angular 4) файл тестів сервісу з запитами міг виглядати воістину страхітливо.
beforeEach(() => TestBed.configureTestingModule({
imports: [HttpModule],
providers: [
MockBackend,
BaseRequestOptions,
{
provide: Http,
useFactory: (backend, defaultOptions) => new Http(backend, defaultOptions),
deps: [MockBackend, BaseRequestOptions]
},
UserService
]
}));
Втім, і зараз в інтернеті повно статей з цими прикладами.
А між тим розробники Angular не сиділи склавши руки, і ми тепер можемо писати тести набагато простіше. Просто скориставшись HttpClientTestingModule і HttpTestingController.
Розглянемо сервіс:
import { Injectable } from '@angular/core';
import { HttpClient } from '@angular/common/http';
import { Observable } from 'rxjs/Observable';
import { ReplaySubject } from 'rxjs/ReplaySubject';
import { Game } from '../models/gameModel';
import { StatisticsService } from './statistics.service';
@Injectable()
export class GameService {
gameData: Array;
dataChange: ReplaySubject;
gamesUrl = 'https://any.com/games';
constructor(private http: HttpClient, private statisticsService: StatisticsService) {
this.dataChange = new ReplaySubject();
}
getGames() {
this.makeResponse()
.subscribe((games: Array) => {
this.handleGameData(games);
});
}
makeResponse(): Observable {
return this.http.get(this.gamesUrl);
}
handleGameData(games) {
this.gameData = games;
this.doNext(games);
this.statisticsService.send();
}
doNext(value) {
this.dataChange.next(value);
}
}
Для початку описуємо всіх наших глобальних героїв:
let http: HttpTestingController;
let service: GameService;
let statisticsService: StatisticsService;
const statisticsServiceStub = {
send: () => {}
};
Тут з цікавого – стаб statisticsService. Ми за аналогією з компонентом Стабія залежності, так як тісто зараз тільки конкретний сервіс.
Як бачите, я просто прописала саме те, що знадобиться в цьому тесті. Просто уявіть, що в StatisticsService насправді величезна кількість методів і залежностей, а використовуємо в даному сервісі ми тільки один метод.
Далі оголосимо дані, які будемо підкидати у відповідь на запит:
const expectedData = [
{id: '1', name: 'FirstGame', locale: 'ru', type: '2'},
{id: '2', name: 'SecondGame', locale: 'ru', type: '3'},
{id: '3', name: 'LastGame', locale: 'en', type: '1'},
];
У TestBed необхідно імпортувати HttpClientTestingModule і прописати всі сервіси:
TestBed.configureTestingModule({
imports: [
HttpClientTestingModule,
],
providers: [GameService, { provide: StatisticsService, useValue: statisticsServiceStub }]
});
Наступний крок – отримання примірників всіх сервісів, які нам знадобляться:
service = TestBed.get(GameService);
statisticsService = TestBed.get(StatisticsService);
http = TestBed.get(HttpTestingController);
Не завадить відразу ж прописати в afterEach перевірку на те, що немає відкладених запитів:
afterEach(() => {
http.verify();
});
І переходимо до самих тестів. Найпростіше, що ми можемо перевірити – створився чи сервіс. Якщо ви забудете в TestBed вказати будь-яку залежність, то цей тест не пройде:
it('should be created', () => {
expect(service).toBeTruthy();
});
Далі вже цікавіше – перевіряємо, що по очікуваному запитом отримаємо певні дані, які самі ж і підкидає:
it('should have made one request to GET data from expected URL', () => {
service.makeResponse().subscribe((data) => {
expect(data).toEqual(expectedData);
});
const req = http.expectOne(service.gamesUrl);
expect(req.request.method).toEqual('GET');
req.flush(expectedData);
});
Не завадить перевірити ще й як працює ReplaySubject, тобто чи будуть відловлювати у передплатників отримані гри:
it('getGames should emits gameData', () => {
service.getGames();
service.dataChange.subscribe((data) => {
expect(data).toEqual(expectedData);
});
const req = http.expectOne(service.gamesUrl);
req.flush(expectedData);
});
І нарешті останній приклад – перевірка, що statisticsService метод send буде викликаний:
it('statistics should be sent', () => {
const statisticsSpy = jest.spyOn(statisticsService, 'send');
service.handleGameData(expectedData);
expect(statisticsSpy).toHaveBeenCalled();
});
import { TestBed } from '@angular/core/testing';
import { GameService } from './game.service';
import { HttpClientTestingModule, HttpTestingController } from '@angular/common/http/testing';
import { StatisticsService } from './statistics.service';
import 'rxjs/add/observable/of';
describe('GameService', () => {
let http: HttpTestingController;
let service: GameService;
let statisticsService: StatisticsService;
const statisticsServiceStub = {
send: () => {}
};
const expectedData = [
{id: '1', name: 'FirstGame', locale: 'ru', type: '2'},
{id: '2', name: 'SecondGame', locale: 'ru', type: '3'},
{id: '3', name: 'LastGame', locale: 'en', type: '1'},
];
beforeEach(() => {
TestBed.configureTestingModule({
imports: [
HttpClientTestingModule,
],
providers: [GameService, { provide: StatisticsService, useValue: statisticsServiceStub }]
});
service = TestBed.get(GameService);
statisticsService = TestBed.get(StatisticsService);
http = TestBed.get(HttpTestingController);
});
afterEach(() => {
http.verify();
});
it('should be created', () => {
expect(service).toBeTruthy();
});
it('should have made one request to GET data from expected URL', () => {
service.makeResponse().subscribe((data) => {
expect(data).toEqual(expectedData);
});
const req = http.expectOne(service.gamesUrl);
expect(req.request.method).toEqual('GET');
req.flush(expectedData);
});
it('getGames should emits gameData', () => {
service.getGames();
service.dataChange.subscribe((data) => {
expect(data).toEqual(expectedData);
});
const req = http.expectOne(service.gamesUrl);
req.flush(expectedData);
});
it('statistics should be sent', () => {
const statisticsSpy = jest.spyOn(statisticsService, 'send');
service.handleGameData(expectedData);
expect(statisticsSpy).toHaveBeenCalled();
});
});
TestBed.configureTestingModule({
declarations: [ AppComponent ],
schemas: [ NO_ERRORS_SCHEMA ]
})
Переклад статті “Angular 5: Unit тесты“
Команда розробників Webpack цей раз добряче попрацювала над новим поколінням популярного збирача модулів (Бандлера) – webpack 4.
Репозиторій з використовуваним кодом тут.
Ніхто не сперечається: у нього є потужні плюси, велика кількість можливостей і налаштувань, проте головним болем є файл конфігурації.
Написання конфіга не складає проблеми для середніх і великих проектів, без цього їм важко існувати. Проте, невеликі проекти це може дратувати, особливо якщо хочеться створити додаток-іграшку.
Шон і команда webpack поліпшили життя всім нам: webpack 4 більше не вимагає файлу конфігурації за замовчуванням!
Що ж, протестуємо.
Створіть нову директорію і перейдіть туди:
mkdir webpack-4-quickstart && cd $_
Ініціалізуйте package.json:
npm init -y
Тепер пускаємо в бій webpack 4 (Версія зараз знаходиться в стадії beta, тому потрібно додати next):
npm i webpack@next --save-dev
Додамо webpack-cli, що живе своїм життям в окремому пакеті:
npm i webpack-cli --save-dev
Відкриваємо package.json і прописуємо скрипт збірки:
"scripts": {
"build": "webpack"
}
Збережіть файл, закрийте. запустіть:
npm run build
Що ж трапилося?
ERROR in Entry module not found: Error: Can't resolve './src' in '~/webpack-4-quickstart'
Webpack 4 шукає вхідні точку прикладання ./src! Якщо не знаєте, чому так вийшло, то опишу коротко: вхідні точка – це файл, з якого webpack починає збірку. У ранніх версіях потрібно було оголосити її безпосередньо в webpack.config.js.
Але починаючи з 4-ої версії вам не потрібно вказувати вхідні точку. Вона буде взята з ./src/index.js за замовчуванням!
Перевіримо. Створіть ./src/index.js:
console.log('Test');
Знову запустіть збірку:
npm run build
Ви отримаєте файл ~/webpack-4-quickstart/dist/main.js .
Невже нам не потрібно ставити і точку виходу теж? Саме! Ні точку входу, ні виходу. Тим більше, не потрібен файл конфігурації .
Я знаю, що для більшості це не дивно: сила webpack в поділі коду. Але повірте: нуль конфігурації прискорює розробку в рази.
Дуже часто можна зустріти поділу конфіга на кілька файлів.
Типовий проект може мати:
webpack-dev-server і іншими іграшками розробників.UglifyJSPlugin, картами сайту і іншим.Поки великі проекти продовжують використовувати поділ конфігов, ми з webpack 4 зробимо все одним рядком.
Як так? Зустрічайте режими production і development.
Якщо ви звернете увагу на висновок npm run build, то побачите красиву помилку:
Опція ‘mode’ (режим) була задана. Увімкніть режим в ‘development’ або ‘production’, щоб застосувати настройки за замовчуванням.
Що це означає? Будемо розбиратися. Відкрийте package.json і допишіть об’єкт скриптів, як показано нижче:
"scripts": {
"dev": "webpack --mode development",
"build": "webpack --mode production"
}
І тепер спробуємо:
npm run dev
Погляньмо на ./dist/main.js. Що ви бачите? Так, я знаю, нудний бандл … не зменшений. А якщо:
npm run build
Що тепер? Файл зборки був зменшений. Так! Режим 'production' використовує всі види оптимізації самостійно. І там не тільки мінімізація.
З іншого боку режим розробника (development mode) оптимізує швидкість програми і нічого більше.
Таким чином, з 4-х webpack’ом ви можете змінювати всю збірку одним рядком. Просто додайте прапорець --mode і отримаєте результат абсолютно безболісно.
Переклад статті “Webpack 4 tutorial: All You Need to Know, from 0 Conf to Production Mode“
Відкрийте криптовалютну картку Trustee за кілька хвилин! Оплачуйте ваші покупки миттєво з автоматичною конвертацією