Тут у центрі уваги – ціни криптовалют, волатильність і ринкова капіталізація.
Індустрія блокчейна пов’язана з класом активів, цікавим як довгостроковим інвесторам – так званим Ходлер, – так і дей-трейдерам. Даний клас активів включає криптовалюта, токени і токенізіровані реальні активи.
Ціни в кріптопространстві відрізняються волатильністю, але загальний довгостроковий тренд – висхідний. Траєкторія «на Місяць», головним чином, визначалася тим фактом, що більшість кріптоактівів дефляційні, і з поширенням обізнаності зростає попит, що, у свою чергу, штовхає ціни вгору.
Багато хто вважає, що найближчим часом цей тренд не зупиниться. І незважаючи на відсутність зростання цін багатьох кріптоактівів в минулому році, загальноприйняту думку, особливо серед ентузіастів, така, що історичні максимуми цін і ринкових капіталізацій ще попереду.
Деякі робили дуже сміливі прогнози. Наприклад, венчурний капіталіст і інвестор Тім Дрейпер офіційно заявив, що вважає, що ціна біткойнов до 2022 р може досягти позначки $ 250 000 .
Оскільки біткойнов і інші кріптоактіви мають високу позитивну кореляцію, якщо прогнози збудуться, зростання цін в найближче десятиліття буде феноменом всієї індустрії. Це також означає, що індустрія побачить зростання ринкових капіталізацій.
Однак слід проявляти обережність стосовно майбутньої поведінки цін криптовалют. Спрогнозувати його складно.
Хоча першим застосуванням блокчейну, що привернув інтерес багатьох, були криптовалюта і маркери, судячи з усього, фокус зміщується в бік інших можливостей технології. Одне застосування, яке демонструє великий потенціал, – це смарт-контракти, угоди, зафіксовані в коді і здатні самостійно виконуватися в блокчейне.
Багато уваги також зосереджено на використанні блокчейну в якості основи, на якій будуть не тільки виконуватися всілякі додатки, але також безпечно зберігатися дані цих додатків. В цьому відношенні блокчейн пропонує ряд переваг в порівнянні з централізованими серверами. У їх числі поліпшена безпеку, конфіденційність і надійне час безперебійної роботи.
Сьогодні практично у кожній індустрії існують стартапи, які розробляють проривні додатки, які будуть працювати на блокчейне. Також спостерігається інтерес з боку великих технологічних компаній і громадських інститутів по всьому світу.
Зокрема, їх залучення відбувається за допомогою консорціальних протоколів, таких як R3 і Hyperledger. Вони також займаються самостійними дослідженнями і інвестують в блокчейн-проекти.
Значна частина того, що відбувається навколо блокчейна все ще знаходиться в процесі розробки. Повні результати можна буде побачити в найближчі роки. І все вказує на більш активну участь різних зацікавлених сторін в розробці нових рішень на основі блокчейну.
Третій аспект індустрії блокчейну, який зобов’язаний змінитися в найближчі роки, пов’язаний з масштабністю блокчейнов . Виявляється, що збільшити пропускну здатність можна шляхом як створення абсолютно нових блокчейнов, так і удосконалення існуючих за допомогою ончейн-рішень масштабованості, таких як Segregated Witness, і офчейн-рішень, таких як Lightning Network.
Однак незабаром ми також можемо все частіше спостерігати тенденцію щодо створення рішень інтероперабельності. У міру того як буде з’являтися все більше блокчейнів, ми можемо побачити, як індустрія пройде через те, через що пройшов у своєму розвитку інтернет, перш ніж стати таким, яким ми знаємо його сьогодні.
У ранні дні інтернету більшість мереж були локальними (LAN). Спочатку вони не взаємодіяли один з одним, так як були створені на основі різних технологій і протоколів, виконували різні функції і, головне, тоді не було загальноприйнятих галузевих стандартів.
Ситуація змінилася з появою стека протоколів TCP/IP, що дозволив всім мережам інтегруватися і взаємодіяти. Той, хто хотів створити нову систему, міг зробити це, знаючи, як вона буде взаємодіяти з існуючими.
Ми знаходимося на стадії, коли індустрія блокчейна рухається до розробки стандартних протоколів, які будуть гарантувати, що будь-хто зможе створити публічний або приватний блокчейн, який зможе взаємодіяти і обмінюватися даними з тими, що вже існують.
І точно так само як протоколи TCP/IP спростили проходження даних по всьому світу в лічені секунди без необхідності в посередниках, вартість також зможе переміщатися по світу незалежно від задіяних блокчейнів.
Ми вже бачимо проекти, що працюють в напрямку взаємозв’язку блокчейнів. У їх числі Lightning Network, Celer Network і проект Interledger. Так чи інакше, можна сказати, що індустрію блокчейна чекає світле майбутнє.
Переклад статті “Outlook on the Future of the Blockchain Industry“
Приклади git команд з невеликим описом для повсякденного вжитку для програмістів і не тільки.
Створити новий репозиторій:
git init project-name
Якщо ви плануєте клонувати його по ssh з віддаленої машини, також скажіть:
git config --bool core.bare true
… інакше при git push ви будете отримувати дивні помилки на кшталт:
Refusing to update checked out branch: refs / heads / master By default, updating the current branch in a non-bare repository is denied, because it will make the index and work tree inconsistent with what you pushed, and will require 'git reset - -hard 'to match the work tree to HEAD.
Клонувати репозиторій з віддаленої машини:
git clone git @ bitbucket.org:afiskon / hs-textgen.git
Якщо хочемо пушіть один код в кілька репозиторіїв:
git remote add remotename git @ gitlab.example.ru:repo.git
Додати файл в репозиторій:
git add text.txt
Видалити файл:
git rm text.txt
Поточний стан сховища (зміни, невирішені конфлікти і тп):
git status
Зробити Комміт:
git commit -a -m "Commit description"
Зробити Комміт, ввівши його опис за допомогою $ EDITOR:
git commit -a
Замержіть все гілки локального сховища на віддалений репозиторій (аналогічно замість origin можна вказати і remotename, см вище):
git push origin
Аналогічно до попереднього, але робиться пуш тільки гілки master:
git push origin master
Запущено поточну гілку , не вводячи цілком її назва:
git push origin HEAD
Замержіть все гілки з віддаленого сховища:
git pull origin
Аналогічно до попереднього, але накочується тільки гілка master:
git pull origin master
Хильнути поточну гілку, не вводячи її довге ім’я:
git pull origin HEAD
Завантажити все гілки з origin, але не Мержа їх в локальний репозиторій:
git fetch origin
Аналогічно до попереднього, але тільки для однієї заданої гілки:
git fetch origin master
Почати працювати з гілкою some_branch (вже існуючої):
git checkout -b some_branch origin / some_branch
Створити новий бранч (відгалузилося від поточного):
git branch some_branch
Переключитися на іншу гілку (з тих, з якими вже працюємо):
git checkout some_branch
Отримуємо список гілок, з якими працюємо:
git branch # зірочкою відзначена поточна гілка
Переглянути всі існуючі гілки:
git branch -a # | grep something
Замержіть some_branch в поточну гілку:
git merge some_branch
Видалити бранч (після Мержа):
git branch -d some_branch
Просто видалити бранч (тупикова гілка):
git branch -D some_branch
Історія змін:
git log
Історія змін в зворотному порядку:
git log --reverse
Історія конкретного файлу:
git log file.txt
Аналогічно до попереднього, але з переглядом зроблених змін:
git log -p file.txt
Історія з іменами файлів і псевдографічним зображенням бранчів:
git log --stat --graph
Зміни, зроблені в заданому Ком:
git show d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Подивитися, ким востаннє правилася кожен рядок файлу:
git blame file.txt
Видалити бранч зі сховищ на сервері:
git push origin: branch-name
Відкотитися до конкретного коммітов (хеш дивимося в «git log»):
git reset --hard d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Аналогічно до попереднього, але файли на диску залишаються без змін:
git reset --soft d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Спробувати звернути заданий commit (але частіше використовується branch / reset + merge):
git revert d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4
Перегляд змін (сумарних, а не всіх по черзі, як в «git log»):
git diff # подробиці див в "git diff --help"
Використовуємо vimdiff як програми для вирішення конфліктів (mergetool) за замовчуванням:
git config --global merge.tool vimdiff
Відключаємо діалог «який mergetool ви хотіли б використовувати»:
git config --global mergetool.prompt false
Відображаємо таби як 4 пробілу, наприклад, в «git diff»:
git config --global core.pager 'less -x4'
Створення глобального файлу .gitignore :
git config --global core.excludesfile ~ / .gitignore_global
Вирішення конфліктів (коли оні виникають в результаті Мержа):
git mergetool
Створення тега:
git tag some_tag # за тегом можна вказати хеш коммітов
Видалення untracked files:
git clean -f
«Упаковка» сховища для збільшення швидкості роботи з ним:
git gc
Іноді потрібно створити копію сховища або перенести його з однієї машини на іншу. Це робиться приблизно так:
mkdir -p / tmp / git-copy cd / tmp / git-copy git clone --bare git @ example.com:afiskon / cpp-opengl-tutorial1.git cd cpp-opengl-tutorial1.git git push --mirror git @ example.com:afiskon / cpp-opengl-tutorial2.git
Слід зазначити, що Git дозволяє використовувати коротку запис хеш. Замість «d8578edf8458ce06fbc5bb76a58c5ca4a58c5ca4» можна писати «d8578edf» або навіть «d857».
Якщо ви останнім часом стежили за розвитком Angular, ви, мабуть, зіткнулися з словом “Ivy”.
За цим кодовим ім’ям ховається величезна робота для Angular team, і крок у майбутнє. Але важко зрозуміти, що таке Ivy. Давайте дізнаємося.
Ваш JS framework є компілятором. Це вірно для більшості систем JS, але це особливо актуально для Angular.
У Angular, коли ви пишете компонент, ви пишете компонент в TypeScript і його шаблон в HTML, доповнений синтаксисом Angular template ( ngIf, ngForі т.д.).
Те, що багато розробників не знають, це те, що цей HTML ніколи не буде відображатися у браузері. Він буде скомпільований Angular в інструкції JavaScript, щоб створити відповідний DOM, коли компонент з’явиться на сторінці, і оновити компонент при зміні його стану. Ось чому велика частина Angular є її компілятором: він бере весь ваш HTML і генерує необхідний код JS. Цей компілятор (і час виконання) був повністю переписаний за останній рік, і це є Ivy. Це не перший перезапис: Ivy означає “IV”, 4 – римськими числами. Останнє переписання було зроблено в Angular 4.0, і, можливо, ви навіть не помітили його. Але це, безумовно, найглибше переписування внутрішніх пристроїв з моменту першого випуску Angular: Angular команда буквально змінює двигун (раніше називався View Engine) під час руху.
Ivy є дуже важливим ступенем історії Angular. Вона змінює спосіб внутрішньої роботи рамки, не змінюючи способів написання Angular.
Якщо паралель має певний сенс, він дуже схожий на React і “Fiber rewrite”. React Fiber – це повна переписування внутрішніх елементів React, і особливо пропонується більш інтенсивне візуалізація. Перезапис тривав більше року, і відкрив двері для нових можливостей (наприклад, знамениті Hooks, які були випущені в React 16.8 і які спираються на Fiber).
Angular досягає цього ж з цим зусиллям: Ivy – це повна переписування компілятора (і середовища виконання), щоб:
Важливим є те, що нам не потрібно змінювати спосіб написання наших додатків. Ivy прагне бути сумісним з існуючими додатками: це буде просто перемикач для включення для більшості проектів.
Але може статися, що Ivy не має точно такої ж поведінки для деяких випадків. Щоб уникнути порушення додатків, коли ми переходимо до Ivy, команда Angular написала сценарії міграції (схеми оновлення), щоб проаналізувати ваш код і підготувати його до Ivy, якщо це необхідно. Таким чином, коли ви будете оновлювати до Angular 8, схеми будуть працювати і налаштувати кілька речей у вашому коді, щоб бути “Ivy-ready”, коли настане час. План полягає в тому, щоб включити Ivy за замовчуванням в майбутньому, можливо, у V9.
Давайте зануримося в подробиці 🤓.
Для компонента PonyComponentз шаблоном:
<figure>
<img [src]="getPonyImageUrl()">
<figcaption>{{ ponyModel.name }}</figcaption>
</figure>Двигун перегляду, движок попереднього Ivy, згенерований код:
function View_PonyComponent() {
return viewDef([
elementDef(2, 'figure'),
elementDef(0, 'img', ['src']),
elementDef(1, 'figcaption'),
textDef()
], (checkBinding, view) => {
var component = view.component;
const currVal_0 = component.getPonyImageUrl();
checkBinding(view, 1, currVal_0);
const currVal_1 = component.ponyModel.name;
checkBinding(view, 4, currVal_1);
});
}Це те, що називається ng_factory , функція, що визначає визначення подання з двома частинами:
Ivy генерує інший код для одного компонента. Спочатку він більше не генерує ng_factory : він вбудовує сформований код в статичне поле. @DirectiveДекоратора стає поле під назвою ngDirectiveDef. @InjectableДекоратора стає полем під назвою ngInjectableDef. @ComponentДекоратора стає поле під назвою ngComponentDef.
Таким чином, наш компонент стає:
class PonyComponent {
static ngComponentDef = defineComponent({
type: PonyComponent,
selectors: [['ns-pony']],
factory: () => new PonyComponent(),
// number of elements, templates, content, bound texts to allocate...
consts: 4,
vars: 2,
template: (renderFlags: RenderFlags, component: PonyComponent) => {
if (renderFlags & RenderFlags.Create) {
elementStart(0, 'figure');
element(1, 'img');
elementStart(2, 'figcaption');
text(3);
elementEnd();
elementEnd();
}
if (renderFlags & RenderFlags.Update) {
select(1)
property('src', component.getPonyImageUrl());
select(3)
textBinding(3, interpolation1('', component.ponyModel.name, ''));
}
}
});
}Зауважте, що код, створений у templateчастині, має приблизно однакову форму, ніж ng_factory(частина створення та оновлення), але використовує різні інструкції.
Але найбільша різниця – це, мабуть, новий locality principle. Це може мати велике значення при розробці програми Angular та скорочення часу відновлення. Але це також дозволяє відправляти заздалегідь скомпільований код до NPM безпосередньо!
Якщо ви хочете опублікувати Angular бібліотеку на NPM, вам доведеться скомпілювати код TypeScript у JavaScript, а потім запустити компілятор Angular для створення metadata.jsonфайлів.
Потім, коли хтось будував програму з вашою бібліотекою, ng buildбудував ng_factory.jsфайли для ваших компонентів і для компонентів, що надходять з бібліотек. Це означає, що якщо програма використовувала 3 бібліотеки з 10 компонентами кожна, а сама програма мала 50 компонентів, ng buildбуло складено 80 компонентів.
У Ivy, як ви вже зрозуміли, не існує більше ng_factory.jsабо metadata.jsonфайлів. Це означає, що, як автор бібліотеки, ви можете безпосередньо відправити до NPM скомпільований код JS, з результатом компіляції Ivy (зі статичними полями, що генеруються для кожного компонента, директиви, сервісу…).
Потім, коли хтось створює програму з вашою бібліотекою «Ivy-ready», вони не витрачатимуть ресурси на складання компонентів вашої бібліотеки! Це повинно прискорити час відновлення в циклі розробки, коли ми працюємо, ng serveі ми чекаємо перевірки модифікації, яку ми зробили.
Коли бібліотека вже скомпільована, то нам не доведеться перекомпілювати її кожного разу.
Але також виходить, що раніше, коли ви працювали над вашим додатком, Angular довелося перекомпілювати все всередині вашого модуля, щоб дізнатися, що змінилося, оскільки згенерований код компонента міг використовувати внутрішні деталі іншого компонента.
Тепер кожен компонент посилається на директиви та компоненти, які він використовує, тільки їх публічними API. Отже, якщо ви зміните внутрішню деталь компонента або директиви, перекомпілюватимуться лише фактичні компоненти, які його використовують. Це може призвести до величезних переваг у відновленні часу для додатків з десятками компонентів і директив, так як ви перейдете з перекомпіляції всіх з них, щоб перекомпілювати тільки ті, що потрібні.
Візьмемо приклад з нашим, PonyComponentякий оголошує його вхід таким чином:
@Input('pony') ponyModel: PonyModel;Зазвичай, властивість ( this.ponyModel) виводиться як вхід з іншим ім’ям ( pony). Тому, коли компонент використовує PonyComponentу своєму шаблоні, він виглядає так:
<ns-pony [pony]="myPony"></ns-pony>А згенерований код в Ivy, виглядає так:
// ...
if (renderFlags & RenderFlags.Update) {
select(0);
// updates the public `pony` property
property('pony', component.myPony);
}
},
directives: [PonyComponent]Але з видом двигуна виглядав так:
// ...
elementDef(0, 'ns-pony'),
// updates the private `ponyModel` field
directiveDef('PonyComponent', { ponyModel: [0, 'ponyModel'] }
// ...Можливо, це не схоже на велику різницю, але View Engine посилається лише на приватне поле, а не на його загальнодоступне ім’я.
Це принцип місцевості. Щоб скомпілювати AppComponentцей PonyComponentшаблон, Ivy не знає нічого про компонент pony. Висновок компілятора Ivy Appcomponent залежить тільки від коду AppComponent.
Це було невірно в ViewEngine, де код, згенерований для, AppComponent також залежав від коду PonyComponent (в даному прикладі, від імені поля, що ponyModelпідтримує вхід pony).
Це схоже на детальну реалізацію, але має наслідки для часу перебудови, оскільки компілятор Ivy може зробити краще, ніж перекомпілювати все, як це було зроблено в View Engine.
Трохи дрібниць історії Angular: модулі були введені досить недавно в розвитку Angular, всього за кілька місяців до стабільного випуску. Раніше під час бета-фази 2.0 ви повинні були вручну посилатися на кожен компонент і директиву, що використовуються в компоненті, безпосередньо в декораторі. Модулі були введені, щоб уникнути цього, але недоліком було те, що він став найменшою одиницею компіляції: зміна одного елемента модуля призводить до перекомпіляції всіх елементів модуля. Ви можете побачити, як код, згенерований в Ivy, повертає нас до того, що було спочатку розроблено командою Angular, з directivesвластивістю, сформованою в ngComponentDefполі.
Новий набір інструкцій розроблено для досягнення вищезазначених цілей. Більш точно, він був розроблений, щоб бути повністю деревом тремтіння. Це означає, що якщо ви не використовуєте особливу особливість Angular, інструкції, що відповідають цій функції, не будуть у вашому остаточному пакеті. Більше, ніж час виконання Ivy не буде мати коду для запуску цієї інструкції, тоді як View Engine не був деревом, і він завжди містив все.
Ось чому команда очікує великих поліпшень розмірів невеликих додатків, а особливо програми Hello World (яка раніше виробляла великий пакет для Hello World), або для Angular Element .
Для середніх і великих додатків ситуація не повинна сильно змінитися з першим випуском Ivy. Пакети повинні мати приблизно однакові розміри (або навіть трохи більші), як і з View Engine. Команда Angular встигне зосередитися на цьому, коли вони впевнені, що немає регресії з Ivy, і ми можемо сподіватися на менші пачки в кожному випадку в майбутньому.
Ivy не приділяє особливої уваги виставам, принаймні не в першому випуску. Вона була розроблена, щоб бути дуже ефективною пам’яттю, деякі механіки були покращені, і вона все ще розроблена, щоб уникнути мегаморфних викликів, але загалом ви не повинні бачити великих поліпшень або втрат. Якщо ви помітили втрату продуктивності, команда, ймовірно, буде дуже рада почути про це.
Ivy відкриває кілька можливостей для майбутнього. Тепер має бути можливим запускати додаток без zone.js і вручну управляти виявленням змін (подібно до React). Ці API вже існують, але є експериментальними, не задокументованими і, ймовірно, зміниться найближчим часом.
Кутове компілятор має варіант , який часто упускається з виду , на мій погляд: fullTemplateTypeCheck. Якщо увімкнено, компілятор намагається глибше аналізувати шаблони. Я показав деякі приклади того, на що він здатний, коли він був введений в Angular 5 . Ця опція в даний час більш потужна в Ivy, і, ймовірно, буде ще більш потужним в майбутньому.
Наприклад, однією з функцій, які вже доступні в Ivy, є перевірка типу компонентних і директивних входів. Уявіть собі, ImageComponentщо вхід називається sizeтипом number. Якщо інший компонент використовує ImageComponentі намагається передати логічне значення в sizeвласність, ви побачите повідомлення про помилку: Type 'boolean' is not assignable to type 'number'..
Це лише приклад того, на що Ivy буде здатна, і ці функції дуже цікаві для великих додатків.
Я пояснив, що компілятор Ivy приймає декоратори в коді TypeScript, а потім генерує статичне поле в класі. Але поточні бібліотеки, що поставляються на NPM, більше не мають свого декоратора, вони зазвичай відправляють код JavaScript, отриманий в результаті компіляції. А Ivy потрібні ці статичні поля для правильної роботи, так що ми застрягли, поки кожна бібліотека, яку ми використовуємо, не поставила нову версію?
Команда Angular створила компілятор сумісності ngcc. Цей компілятор має одне важливе завдання: він приймає node_modulesвашу програму, шукає кутові бібліотеки, читає їхні metadata.jsonфайли і код JS, і виводить той самий код JS, але з статичними полями, яким потрібно Ivy!
Це справді вражаючий інженерний пристрій, в основному прихований від наших очей, оскільки він безпосередньо вбудований в CLI. Так що в перший раз ви будете працювати ng serveабо ng build, ви помітите, завдання займає більше часу, ніж зазвичай, як ngccі робити свою магію за лаштунками. Але не бійтеся: це треба робити тільки один раз, а потім він знову не запуститься (за винятком випадків, коли ви додаєте до вашої програми іншу бібліотеку Angular).
Angular 8.0 – перший крок для Ivy. Коли він буде достатньо стабільним, він стане типовим. І тоді команда може почати працювати над додаванням інших функцій легше. Як сервіс i18n , можливо, одна з найбільш очікуваних функцій. Або можливість мати метапрограмування або компоненти вищого порядку . Або ліниво-завантажувати один компонент замість модуля. Або мати компоненти JiT і компоненти AoT працювати один з одним. Або створити шаблон вручну, написавши вручну згенеровані інструкції, щоб вичавити найкращі показники. І, мабуть, тонни інших ідей, яких команда має, і про які ще не говорили.
Я сподіваюся, що це трохи роз’яснило, про що Ivy, і що ви спробуєте в наступні місяці!
Переклад статті “What is Angular Ivy?“
Angular 8.0 має трохи більше мій код, ніж інші випуски 😊.
Цей випуск, в основному, стосується Ivy і можливості спробувати, але він також включає в себе кілька особливостей і порушення змін. Сподіваюся, оновлення повинно бути дуже легким, оскільки команда Angular написала купу схем, які будуть робити важку роботу замість вас.
Angular 8.0 тепер підтримує TypeScript 3.4 і навіть вимагає його, тому вам потрібно оновити.
Ви можете перевірити, що надає TypeScript 3.3 і TypeScript 3.4 у блозі Microsoft.
Ivy, очевидно, є величезною частиною цього випуску, і більшість зусиль цієї команди було прийнято за останній місяць. Є стільки, що можна сказати про Ivy, можна почитати у спеціальній статті про нього.
TL; DR: Ivy – новий компілятор / час виконання Angular. В майбутньому він дозволить створити дуже цікаві функції, але наразі він зосереджен на не порушенні існуючих програм.
Angular 8.0 – це перший реліз, який офіційно пропонує перейти до входу в Ivy. Зараз немає реальних переваг для цього, але ви можете дати йому спробу побачити, чи нічого не руйнуеться у вашій програмі. Тому що в певний момент, ймовірно, в v9, Ivy буде за замовчуванням. Отже, команда Angular сподівається, що громада очікує на перемикання та надасть зворотній зв’язок, і що ми розглянемо всі інші питання до v9.
Ми спробували його на декількох наших програмах і вже потрапили до декількох регресій, тому ми настійно рекомендуємо не використовувати його сліпо у виробництві.
Якщо ви відчуваєте пригоди, ви можете додати "enableIvy": trueу свій angularCompilerOptionsі перезапустити програму: вона тепер використовує Ivy! Перегляньте статтю та офіційний довідник для отримання додаткової інформації .
Що стосується Ivyб ми написали спеціальну статтю про те, як створити ваші програми Angular з новою підтримкою Bazel 🛠.
AbstractControlКлас пропонує новий метод markAllAsTouched на додаток до існуючих markAsDirty, markAsTouched, markAsPendingі т.д. AbstractControlє батьківським класом FormGroup, FormControl, FormArray, тому метод доступний на всіх реактивних форм юридичних осіб.
Як markAsTouched, цей новий метод позначає контроль як touched і його нащадків.
form.markAllAsTouched();FormArrayКлас тепер також пропонує clearспосіб, щоб швидко видалити всі елементи управління , які він містить. Раніше вам довелося прокрутити елементи керування, щоб видалити їх по одному.
// `users` is initialized with 2 users
const users = fb.array([user1, user2]);
users.clear();
// users is now emptyНовий синтаксис був введений для оголошення маршрутів import()із зайвим завантаженням, використовуючи синтаксис з TypeScript (введений у TypeScript 2.4 .
Тепер це кращий спосіб оголосити маршрут відвантаження, а строкова форма застаріла. Цей синтаксис подібний до стандарту ECMAScript, і Ivy підтримує лише це.
Таким чином, ви можете змінити свої loadChildrenдекларації з:
loadChildren: './admin/admin.module#AdminModule'до:
loadChildren: () => import('./races/races.module').then(m => m.RacesModule)Схема, запропонована CLI, автоматично мігрує ваші декларації для вас, тому це має бути безболісним, якщо ви запускаєте ng update @angular/cli. Перегляньте нашу статтю про Angular CLI 8.0, щоб дізнатися більше про це.
Щоб допомогти мігрувати з AngularJS, до служб визначення місцезнаходження в Angular було додано купу речей.
PlatformLocationтепер пропонує доступ до hostname, port і protocol, а новий getState()метод дозволяє отримати history.state. MockPlatformLocationТакож доступна для полегшення тестування. Все це дійсно корисно, якщо ви використовуєте ngUpgrade, інакше вам, мабуть, це не знадобиться.
Реєстрація Service worker має новий варіант, який дозволяє уточнити, коли має відбутися реєстрація. Раніше Service worker очікував на стабільність програми для реєстрації, щоб уникнути уповільнення запуску програми. Але якщо ви починали повторювану асинхронну задачу (наприклад, процес опитування) на початковому завантаженні програми, то програма ніколи не була стабільною, оскільки Angular вважає програму стабільною, якщо відсутня завдання. Так що Service worker ніколи не реєструвався, і вам довелося вручну обійти його. За допомогою нової registrationStrategyопції ви можете дозволити Angular впоратися з цим. Можливі кілька значень:
registerWhenStable, за замовчуванням, як описано вищеregisterImmediately, який не чекає, поки програма стане стабільною, і відразу реєструє Service workerregisterDelay:$TIMEOUTз $TIMEOUTчислом мілісекунд очікування перед реєстрацієюНаприклад, якщо ви бажаєте зареєструвати Service worker через 2 секунди:
providers: [
ServiceWorkerModule.register('/ngsw-worker.js', {
enabled: environment.production,
registrationStrategy: 'registerDelay:2000'
}),
// ...
]Тепер можна також обходити Service worker для окремого запиту, додавши ngsw-bypassзаголовок.
this.http.get('api/users', { headers: { 'ngsw-bypass': true } });Раніше було неможливо мати декілька додатків, що використовувалися @angular/service-workerна різних підпрограмах одного і того ж домену, тому що коженService worker перезапише кеші інших… Це тепер виправлено!
Кілька речей змінилися і вимагають певної роботи з вашої сторони. Деякі зміни керуються Ivy, і вони знаходяться там для підготовки наших додатків. Але приємна новина полягає в тому, що Angular команда вже написала схеми, щоб полегшити наше життя.
Просто запустіть ng update @angular/core і схеми оновлять ваш код. Що роблять ці схеми? Давай дізнаємось!
В ViewChildі ContentChildдекоратори повинні тепер мати новий варіант називається static. Дозвольте мені пояснити, чому з дуже простим прикладом ViewChild:
<div *ngIf="true">
<div #dynamicDiv>dynamic</div>
</div>Давайте зробимо цей елемент в нашому компоненті і занотуємо його в гаки життєвого циклу ngOnInit і ngAfterViewInit:
@ViewChild('dynamicDiv') dynamicDiv: ElementRef<HTMLDivElement>;
ngOnInit() {
console.log('init dynamic', this.dynamicDiv); // undefined
}
ngAfterViewInit() {
console.log('after view init dynamic', this.dynamicDiv); // div
}Має сенс, коли AfterViewInit викликається, коли виконується ініціалізація шаблону.
Але насправді, якщо запитуваний елемент є статичним (не загорнутий в ngIfані ngFor), то він доступний ngOnInitтакож:
<h1 #staticDiv>static</h1>дає:
@ViewChild('staticDiv') staticDiv: ElementRef<HTMLDivElement>;
ngOnInit() {
console.log('init static', this.staticDiv); // div
}
ngAfterViewInit() {
console.log('after view init static', this.staticDiv); // div
}Це не було задокументовано або рекомендовано, але саме так він працює.
Хоча з Ivy, поведінка змінюється більш послідовно:
ngOnInit() {
console.log('init static', this.staticDiv); // undefined (changed)
}
ngAfterViewInit() {
console.log('after view init static', this.staticDiv); // div
}Введено новий static прапор, щоб не порушувати існуючі програми, тому, якщо ви хочете зберегти стару поведінку, навіть коли ви перейдете на Ivy, ви можете написати:
@ViewChild('static', { static: true }) static: ElementRef<HTMLDivElement>;і поведінка буде такою ж, як і поточна (елемент також доступний ngOnInit).
Зверніть увагу, що якщо ви додасте static: true на динамічний елемент (загорнутий у стан або цикл), то він не буде доступний ngOnInit ні в, ні в ngAfterViewInit!
static: false буде як Ivy поводиться за замовчуванням.
Щоб не порушувати існуючі програми та полегшити міграцію, команда Angular написала схему, яка автоматично аналізує вашу програму та додає staticпрапор. Він навіть пропонує дві стратегії:
static: false, що буде за замовчуванням у Ivy.Перша стратегія використовується за замовчуванням при запуску, ng updateоскільки вона є найбезпечнішою, але ви можете спробувати використати стратегію використання NG_STATIC_QUERY_USAGE_STRATEGY=true ng update.
Додаткову інформацію можна отримати в офіційному довіднику .
Так виглядає міграція (з помилкою в одному компоненті):
------ Static Query Migration ------
With Angular version 8, developers need to
explicitly specify the timing of ViewChild and
ContentChild queries. Read more about this here:
https://v8.angular.io/guide/static-query-migration
Some queries could not be migrated automatically. Please go
those manually and apply the appropriate timing.
For more info on how to choose a flag, please see:
https://v8.angular.io/guide/static-query-migration
⮑ home/home.component.ts@43:3: undefinedЗауважимо, що це стосується тільки ViewChildі ContentChild, а не ViewChildrenі ContentChildren (яке буде працювати так само в Ivy і View Engine).
Наразі з інструментом “Перегляд” виконуються такі дії:
<button
*ngFor="let option of options"
(click)="option = 'newButtonText'">{{ option }}</button>працює.
У Ivy, це не буде так: більше не буде можливо перепризначити значення змінної шаблону (тут option). Щоб підготувати комутатор до Ivy, схема аналізує ваші шаблони під час оновлення до Angular 8.0 і попереджає вас, якщо це так.
Потім її потрібно вручну виправити:
<button
*ngFor="let option of options; index as index"
(click)="options[index] = 'newButtonText'">{{ option }}</button>DOCUMENTМаркер переміщається від @angular/platform-browserв @angular/common. Ви можете вручну змінити його у вашій програмі, але надана схема буде подбати про неї.
@angular/platform-webworkerПакет включено працює вашому Angular додатоку в Web Worker. Оскільки це виявилося складнішим, ніж очікувалося (для побудови програми, SEO…), і не дуже добре, продукти були застарілими і будуть видалені в майбутньому.
@angular/httpбуло видалено з 8.0, після заміни @angular/common/httpв 4.3 і офіційно застаріло в 5.0 , 18 місяців тому. Ви, напевно, вже перенесли на @angular/common/http, але якщо ви цього не зробили, тепер вам доведеться: надана схема буде лише видалити залежність від вашого package.json.
Ви також можете знайти всі застарілі API у офіційному довіднику знецінення .
Це все для Angular 8.0! Ви можете переглянути наші інші статті про Ivy , випуск CLI 8.0 або нову підтримку Bazel .
Переклад статті “What’s new in Angular 8.0?“
Кілька інструментів, щоб допомогти переконатися, що весь текст на наших веб-сайтах є розбірливим, незалежно від того, який колір фону вони могли б мати.
Спочатку це Accessible Color Generator, який є чудовим інструментом для вибору альтернативних кольорів. Припустимо, ви працюєте над торговою маркою з кольором X. Ви можете створити безліч інших безкоштовних кольорів, наприклад:
Далі йде Contrast, досить великий додаток MacOS, який постійно знаходиться в рядку меню і допомагає визначити доступні сполучення кольорів на основі Керівництва WCAG. Це особливо корисно, якщо ви є дизайнером:
Це нагадує мені чудовий пост про те, як дизайнерська група Lyft знову підійшла до того, як вони використовують колір у своєму додатку. Кевін Арнотт пояснює:
Колір, принаймні на поверхні, здається майже наївно простим, але, коли він масштабується на великих виробах, він стає неймовірно складним. У вас є тисячі людей, що створюють продукти відразу, і всі ці продукти дуже сильно залежать від кольору. Це створює величезний тиск на систему кольорів, щоб гарантувати, що всі продукти створюються послідовно, але дуже важко реалізувати, оскільки дуже легко застосовувати кольори на одноразовій основі.
Потім команда пішла вперед і побудувала ColorBox.io, яка дозволяє систематично вибудовувати тонну кольорів для роботи дизайнерських систем. Це досить здорово!
Плюс люди на GOV.UK зробили свій власний інструмент доступності кольору під назвою Contrast Checker, який (як ви здогадалися за назвою) допомагає перевірити контраст між фоном елемента і самою сторінкою
І, звичайно, є надійний WebAIM contrast checker, який є для багатьох розробників.
Поки що ми розглянули інструменти, які перевіряють контраст. Але є клас інструментів, який може автоматизувати доступні контрасти під час розробки. Джош Бадер написав підхід, який забезпечує високу контрастність, об’єднуючи власні властивості CSS з calc() функцією. Факундо Коррадіні зробив щось подібне, що перемикає колір шрифту на основі фонового кольору за ним.
О! Іми можемо щось з нетерпінням чекати з color-adjustмайном. Він пропонується в специфікації CSS Color Module Level 4 і може дати браузерам більше контролю для налаштування значень кольорів, які оголошені в таблиці стилів. Це насправді не спрямоване на колірний контраст, але є щось цікаве про передачу відповідальності за надання кольорових значень браузеру на основі певних умов.
Переклад статті “Color contrast accessibility tools“
GitHub – відмінний сервіс, яким користуються нехай не всі, але дуже багато програмістів. Після того, як обсяг приватних репозиторіїв став необмеженим, сервіс привернув увагу навіть тих, хто не працював з ним раніше.
Сервіс розроблявся програмістами для програмістів. Його творці додали велику кількість дуже зручних інструментів, які підвищують продуктивність. Але, на жаль, не всі розробники про ці інструменти знають. А хто знає – не завжди використовує.
Це один з найбільш швидких методів пошуку файлів – правда, лише тоді, коли ви знаєте, що шукаєте. Відкрийте будь-який репозиторій і натисніть T. Тепер ви можете шукати файли за назвою, для зручності використовуючи кнопки напрямки своєї клавіатури. Для відкриття файлу натискаємо Enter.
Для pull request передбачена відмінна функція Suggested Changes. Якщо внести свою пропозицію, то автор коду, вирішивши прийняти вашу правку, може це зробити натисканням кнопки, не залишаючи GitHub. Для того, щоб внести свою пропозицію, необхідно обгорнути сниппет з кодом markdown сніпетів і вибрати тег suggestion.
А ось як може внести запропоновані зміни автор коду. При цьому йому не потрібно вручну вносити зміни в файлі.
Тут вже потрібна установка розширення Octotree для Chrome, але нічого складного тут немає. Зате ми отримуємо більш зручну систему навігації.
Особливо корисним Octotree буде, якщо ви вивчаєте масштабний проект з великою кількістю вкладених директорій. Для отримання метаданих використовується GitHub API.
Підтримуються і приватні репозиторії (інструкції по використанню – тут). Крім того, підтримується GitHub Enterprise.
Зазвичай рев’ю коду включає в себе постійні переходи від викликів функцій до їх визначень. В результаті доводиться постійно скролить туди-сюди, що незручно. Але якщо натиснути T, то нічого скролить не потрібно, відразу переходимо до потрібного місця.
Під час перегляду файлу або директорії просто натисніть Y, після чого URL буде перетворений в пермалінк, який ви зможете надавати кому завгодно, розуміючи, що вміст файлу не зміниться.
Якщо ж ви поширюєте звичайне посилання, то після того, як файл, на який вона вказує, буде переміщений, посилання зламається.
При перегляді файлу натисніть B – і побачите Git blame і недавно змінені рядки. Інструмент показує, хто автор змін, також ви отримуєте клікабельним лінк з відсиланням до повного коммітов, частина змін якого переглядаєте.
Приблизно посередині ви бачите колірні позначки (вертикальна смуга). Чим яскравіше ця смуга, тим новіше файл. Тобто ви можете бачити оновлені файли без жодних зусиль, які не плутаючись у всьому різноманітті.
GitHub індексує практично весь код, пропонуючи потужний функціонал пошуку в індексі. Якщо вам потрібно знайти щось в репозиторії, але ви не хочете вносити зміни, то просто натисніть / перед початком шукати по всьому сховища.
Якщо вам потрібно знайти елемент, який містить кілька слів, просто оберніть словосполучення в лапки. Власне, це стандартний метод пошуку майже для всіх сервісів. На GitHub можна шукати по розширенню файлу, його розміру і іншим характеристикам.
Якщо вам не хочеться з разу в раз писати одне і те ж у відповідь на схожі коментарі, – створіть шаблон відповіді. Замість писанини тепер можна буде вибрати потрібний шаблон з меню, що випадає.
Навіть мишею можна не користуватися, просто використовуючи поєднання ctrl + / і ctrl + 1.
GitHub – відмінний інструмент, з часом він стає тільки краще. Розробники сервісу створюють функції, які допомагають користувачам. Є й доповнення, створені ентузіастами. Для оптимізації своєї роботи варто познайомитися хоча б з частиною можливостей, пропонованих GitHub.
Переклад статті “How to be more productive on GitHub“
Схоже, що останнім часом майже кожен день виникає питання на stackoverflow щодо ExpressionChangedAfterItHasBeenCheckedError помилки, що видає Angular. Зазвичай ці питання виникають тому, що розробники Angular не розуміють, як працює виявлення змін і чому необхідна перевірка, яка дає цю помилку. Багато розробників навіть розглядають це як помилку. Але це, звичайно, не так. Це запобіжний механізм, який запобігає невідповідності даних моделей та інтерфейсу користувача, щоб помилкові або старі дані не відображалися користувачеві на сторінці.
Ця стаття пояснює основні причини помилки та механізм її виявлення, надає кілька загальних шаблонів, які можуть призвести до помилки, і пропонує кілька можливих виправлень. Останній розділ пояснює, чому ця перевірка важлива.
Здається, що чим більше посилань на джерела, які я посилаю в цій статті, тим рідше люди рекомендують її. Тому в цій статті не буде посилання на джерела.
Запуск програми Angular – дерево компонентів. Під час виявлення змін Angular виконує перевірку для кожного компонента, який складається з наступних операцій, що виконуються в заданому порядку:
ngOnInit, OnChanges а також ngDoCheck гаки життєвого циклу для всіх дочірніх компонентів / директивngAfterViewInit гачок життєвого циклу для всіх дочірніх компонентів / директивПісля кожної операції Angular запам’ятовує, які значення він використовував для виконання операції. Вони зберігаються у oldValues властивості виду компонента. Після того, як перевірки були виконані для всіх компонентів, Angular розпочинає наступний цикл збірки, але замість виконання перерахованих вище операцій він порівнює поточні значення з тими, які він запам’ятав з попереднього дайджест-циклу:
Зверніть увагу, що ця додаткова перевірка виконується лише в режимі розробки. Я поясню, чому в останньому розділі статті.
Подивимося приклад. Припустимо, що у вас є батьківський компонент A і дочірній компонент B. A Компонент має name і text властивість. У його шаблоні використовується вираз, що посилається на name властивість:
template: '<span> {{name}} </span>'
І він також має B компонент у своєму шаблоні і передає text властивість цьому компоненту через вхідну властивість:
@Component({
selector: 'a-comp',
template: `
<span>{{name}}</span>
<b-comp [text]="text"></b-comp>
`
})
export class AComponent {
name = 'I am A component';
text = 'A message for the child component`;
Так ось що відбувається, коли Angular запускає виявлення змін. Починається перевірка A компонента. Перша операція в списку полягає в оновленні прив’язки, тому вона оцінює text вираз A message for the child component і передає її на B компонент. Він також зберігає це значення в перегляді:
view.oldValues[0] = 'A message for the child component';
Потім він називає гаки життєвого циклу, згадані в списку.
Тепер він виконує третю операцію і порівнює вираз {{name}} та текст I am A component. Він оновлює DOM за допомогою цього значення та додає оцінене значення до oldValues:
view.oldValues[1] = 'I am A component';
Потім Angular виконує наступну операцію і виконує ту ж перевірку на дочірній B компонент. Після перевірки B компонента поточний збірник завершується.
Якщо Angular виконується в режимі розробки, він запускає другий дайджест, виконуючи операції перевірки, перераховані вище. Тепер уявіть собі, що як-то властивість text було оновлено в A компоненті до updated text після Angular передає значення A message for the child component в B компонент і зберігатє його. Таким чином, тепер він запускає перевірку дайджесту і перша операція полягає в тому, щоб перевірити, що властивість text не змінюється:
AComponentView.instance.text === view.oldValues[0]; // false 'A message for the child component' === 'updated text'; // false
І все ж зміна є і тому Angular викидає помилку ExpressionChangedAfterItHasBeenCheckedError.
Те ж саме для третьої операції. Якщо name властивість було оновлено після рендеринга в DOM і збережено, ми отримаємо таку ж помилку:
AComponentView.instance.name === view.oldValues[1]; // false 'I am A component' === 'updated name'; // false
У вас, напевно, виникає запитання, як можна змінити ці значення. Подивимося це.
Винуватцем завжди є дочірній компонент або директива. Давайте зробимо швидку просту демонстрацію. Я буду використовувати найпростіший приклад, як тільки можливо, але після цього я покажу реальні сценарії. Ви, напевно, знаєте, що дочірні компоненти та директиви можуть вводити свої батьківські компоненти. Отже, давайте зробимо наш B компонент ін’єкційним батьківським A компонентом і оновлюємо пов’язану властивість text. Ми оновлюватимемо властивість у ngOnInit гачку життєвого циклу, оскільки вона спрацьовує після обробки прив’язок, яка показана тут:
export class BComponent {
@Input() text;
constructor(private parent: AppComponent) {}
ngOnInit() {
this.parent.text = 'updated text';
}
}
І, як очікується, ми отримаємо помилку:
Error: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'A message for the child component'. Current value: 'updated text'.
Тепер давайте зробимо те ж саме для властивості, name яка використовується у виразі шаблону батьківського A компонента:
ngOnInit() {
this.parent.name = 'updated name';
}
А тепер все працює нормально. Як?
Якщо ви уважно подивитеся на порядок операцій, ви побачите, що ngOnInit гачок життєвого циклу спрацьовує перед операцією оновлення DOM. Тому немає помилок. Нам потрібен гачок, який викликається після операцій оновлення DOM, і ngAfterViewInit це хороший кандидат:
export class BComponent {
@Input() text;
constructor(private parent: AppComponent) {}
ngAfterViewInit() {
this.parent.name = 'updated name';
}
}
І на цей раз ми отримуємо очікувану помилку:
AppComponent.ngfactory.js:8 ERROR Error: ExpressionChangedAfterItHasBeenCheckedError: Expression has changed after it was checked. Previous value: 'I am A component'. Current value: 'updated name'.
Звичайно, реальні приклади набагато складніші та складніші. Оновлення властивостей батьківського компонента або операції, що викликають візуалізацію DOM, зазвичай робляться непрямим шляхом за допомогою служб або спостережувчів. Але корінна причина завжди однакова.
Тепер давайте подивимось деякі реальні загальні шаблони, які призводять до помилки.
Цей зразок ілюструється цим модулем. Програма призначена для надання спільної служби між батьківським і дочірнім компонентом. Дочірній компонент встановлює значення для служби, яка в свою чергу реагує шляхом оновлення властивості батьківського компонента. Я називаю це оновлення властивості батьків непрямим, тому що на відміну від нашого прикладу вище, відразу не видно, що дочірній компонент оновлює властивість батьківського компонента.
Цей зразок ілюструється цим модулем. Програма призначена для того, щоб дочірній компонент, що випромінює подію, і батьківський компонент, який слухав цю подію. Ця подія викликає оновлення деяких батьківських властивостей. І ці властивості використовуються як вхідні прив’язки для дочірнього компонента. Це також непряме оновлення батьківськич властивостей.
Цей шаблон відрізняється тим, що на відміну від попередніх, на які впливали вхідні прив’язки, цей шаблон викликає операцію оновлення DOM, щоб викинути помилку. Цей зразок ілюструється цим модулем. Програма призначена для батьківського компонента, який динамічно додає дочірній компонент у ngAfterViewInit. Оскільки додавання дочірнього компонента вимагає модифікації DOM, а ngAfterViewInit гачок життєвого циклу ініціюється після оновлення DOM, оновлено.
Якщо ви подивитеся на опис помилки, в останньому реченні сказано наступне:
Expression has changed after it was checked. Previous value:… Has it been created in a change detection hook?
Часто виправлення полягає у використанні гачка для виявлення відповідних змін для створення динамічної складової. Наприклад, останній приклад у попередньому розділі з динамічними компонентами можна виправити, перемістивши створення компонента на& ngOnInit гачок. Хоча в документації зазначається, що ViewChild доступна тільки після ngAfterViewInit, вона заповнює дітей при створенні перегляду і тому вони доступні раніше.
Якщо ви використаєте Google, можливо, знайдете два найпоширенішіх виправлення для цієї помилки – асинхронне оновлення властивостей і примусово додатковий цикл виявлення змін. Хоча я показую їх тут і пояснюю, чому вони працюють, я не рекомендую їх використовувати, а переробити свою програму. Я поясню чому в останній главі.
Єдине, що слід зазначити тут, це те, що виявлення змін і перевірки дайджесту виконуються синхронно. Це означає, що якщо ми будемо оновлювати властивості асинхронно, значення не будуть оновлюватися, коли цикл перевірки запущений, і ми не повинні отримувати помилки.
Протестуємо:
export class BComponent {
name = 'I am B component';
@Input() text;
constructor(private parent: AppComponent) {}
ngOnInit() {
setTimeout(() => {
this.parent.text = 'updated text';
});
}
ngAfterViewInit() {
setTimeout(() => {
this.parent.name = 'updated name';
});
}
}
Дійсно, помилка не викидається. У setTimeout розкладі функції а макрозавдання потім буде виконано в наступному VM черзі.
Також можливо виконати оновлення в поточному повороті віртуальної машини, але після того, як поточний синхронний код закінчився, використовуючи then зворотний виклик promise:
Promise.resolve(null).then(() => this.parent.name = 'updated name');
Замість макрозавдання Promise.then створюється мікрзавдання. Черга мікрозавданнь обробляється після завершення поточного синхронного коду, тому оновлення властивості відбудеться після кроку перевірки. Щоб дізнатися більше про мікро- та макро-завданнях у Angular, ви можете прочитати I reverse-engineered Zones (zone.js) and here is what I’ve found.
Якщо ви використовуєте, EventEmitter ви можете передати true опцію асинхронно:
new EventEmitter (true);
Іншим можливим рішенням є запровадження іншого циклу виявлення змін для батьківського A компонента між першим і етапом верифікації. І найкраще це зробити всередині ngAfterViewInit гака життєвого циклу, оскільки він спрацьовує, коли виявлено зміни для всіх дочірніх компонентів, і тому всі вони мали можливість оновити властивість батьківських компонентів:
export class AppComponent {
name = 'I am A component';
text = 'A message for the child component';
constructor(private cd: ChangeDetectorRef) {
}
ngAfterViewInit() {
this.cd.detectChanges();
}
Помилки немає. Так що, здається, працює, але є проблема з цим рішенням. Коли ми запускаємо виявлення змін для батьківського A компонента, Angular також запускатиме виявлення змін для всіх дочірніх компонентів, і тому є можливість оновлення властивості батьків.
Angular накладає так званий ;unidirectional data flow from top to bottom. Жоден компонент нижчий в ієрархії не дозволяється оновлювати властивості батьківського компонента після обробки батьківських змін. Це гарантує, що після першого циклу переривання все дерево компонентів буде стабільним. Дерево нестійке, якщо є зміни властивостей, які потрібно синхронізувати з споживачами, які залежать від цих властивостей. У нашому випадку дочірній B компонент залежить від батьківської text властивості. Всякий раз, коли ці властивості змінюють дерево компонентів, стає нестабільним, поки ця зміна не буде передано до дитини B компоненту. Те ж саме стосується і DOM. Вона є споживачем деяких властивостей компонента і передає їх на інтерфейс користувача. Якщо деякі властивості не синхронізовані, користувач побачить неправильну інформацію на сторінці.
Цей процес синхронізації даних відбувається під час виявлення змін – особливо тих двох операцій, які я перерахував на початку. Так що ж відбувається, якщо ви оновлюєте батьківські властивості з властивостей дочірнього компонента після виконання операції синхронізації? Так, ви залишитися з нестійким деревом і наслідки такого стану неможливо передбачити. У більшості випадків користувач може отримати неправильну інформацію, показану на сторінці. І це буде дуже важко налагоджувати.
Так чому б не запустити виявлення змін, поки дерево компонентів не стабілізується? Відповідь проста – тому що вона ніколи не може стабілізуватися і працюватиме назавжди. Якщо дочірній компонент оновлює властивість батьківського компонента як реакцію на цю зміну властивості, ви отримаєте нескінченний цикл. Звичайно, як я вже говорив раніше, тривіально виявити таку картину з прямим оновленням або залежністю, але в реальному застосуванні як оновлення, так і залежність зазвичай непрямі.
Цікаво, що AngularJS не мав односпрямованого потоку даних, тому він намагався стабілізувати дерево. Але це часто призводило до сумнозвісної 10 $digest() iterations reached. Aborting! помилки. Виконайте цю помилку, і ви будете здивовані кількістю питань, які виникли у цій помилці.
Останнє питання, яке ви можете мати, чому це запускається тільки в режимі розробки? Я думаю, це тому, що нестабільна модель не є такою драматичною проблемою, як помилка під час виконання, яку створює фреймворк. Адже вона може стабілізуватися в наступному запуску. Однак краще отримувати повідомлення про можливу помилку при розробці програми, ніж налагоджувати запущену програму на стороні клієнта.
Переклад статті “Everything you need to know about the `ExpressionChangedAfterItHasBeenCheckedError` error“
Компанія Blockstream, що спеціалізується на блокчейн- і біткойн-розробках, опублікувала початковий код Simplicity – нової мови програмування для створення смарт-контрактів. Мета розробки полягає в створенні ефективної альтернативи існуючим мовам для роботи з блокчейном. Simplicity пропонує більш просунуті комплексні рішення, у порівнянні з Bitcoin Script і велику гнучкість, ніж Solidity Ефіріума.
Одними з основних переваг Simplicity, за заявою творців, є його простота і можливість створювати безпечний, ефективний і функціональний код смарт-контрактів.
Simplicity значно перевершує по функціоналу скриптову мову біткойнов і за можливостями більше нагадує Java або Python. Simplicity також надає можливість змінювати код смарт-контракту, після його активації. Це серйозний прорив, так як основна проблема існуючих смарт-контрактів на Solidity полягає в їх незмінності, навіть в разі виявлення помилки. З новою архітектурою у розробників з’явиться можливість змінювати контракти за умови досягнення консенсусу.
Серед інших важливих особливостей Simplicity можна відзначити:
Про важливість ролі Ходлерів в розвитку мережі біткойнов і інших кріптовалютних мереж.
На початку змін патріоти завжди рідкісні. Їх ненавидять і зневажають. Але коли справа патріотів вдається, боязкі охоче приєднуються до них, тому що тоді їм нічого не варто бути патріотом– Марк Твен.
Сатоши опублікував білу книгу біткойнов 31 жовтня 2008 року – через місяць після того, як банкрутство Lehman Brothers похитнуло всю фінансову систему. Біткойн з’явився тоді, коли він був вкрай необхідний – в той час, коли в світі, побудованому на довірі, можливість довіри виявилася втрачена.
Основна проблема традиційної валюти – це довіра, без якого вона не може існувати. Центральному банку довіряють завдання з підтримки валюти, але в історії фіатних валют є безліч випадків, коли банки не справлялися з цим завданням. Банкам довіряють зберігати наші гроші і проводити електронні платежі, а вони видають позики, не залишаючи в резерві практично нічого, провокуючи виникнення кредитних бульбашок і підживлюючи їх– Сатоши Накамото.
Через втручання центральних банків під час фінансової кризи ринки сильно деформувалися, а співвідношення ризику / прибутку стало самим асиметричним за всю історію. Понад 9 трильйонів облігацій торгуються з негативної кривої прибутковості.
Час, в якому ми живемо, унікален, тому що ніколи ще така кількість країн не існувала так довго без профіциту бюджету. Наприклад, в США дефіцит спостерігається протягом 40 з останніх 44 років (включаючи 2012 рік).
До початку XX століття прості люди завжди могли переключитися на тверду валюту (золото), щоб убезпечити себе від наслідків провальної інфляційної політики центрального банку. Більшість країн світу припинили цю практику у XX столітті. Ніколи раніше така кількість країн не відмовлялася від валюти на базі дорогоцінних металів на такий довгий термін. Закон про золотий стандарт, прийнятий в 1971 році, дозволив створити умови для практично необмеженого потенціалу кредитування і утворення боргу, що для економічної історії було безпрецедентним явищем.
Через 41 рік використання фіатной валюти, з безпрецедентною сумою боргу, який дуже складно погасити, ми вступаємо на незвідану територію.
Біткойн був створений для побудови нової фінансової системи, яка не вимагала б довіри і дотримувалася б принципів стійких грошей. Чому стійкі тверді валюти настільки важливі?
Гроші – це інструмент, який ми використовуємо для позначення переваг споживачів. Маючи таргінг і ефективні засоби для задоволення споживчого попиту, виробники можуть зосередити свої зусилля на товарах і послугах, які найбільше затребувані на ринку. Стійкі гроші прискорюють цей процес. Через нестійкі гроші ринок може втратити здатність сигналізувати виробникам про свої потреби. Ось чому соціалізм і централізована планова економіка – це нежиттєздатні концепти. Механізм «невидимої руки» ринку не можна відтворити штучно – він занадто складний і потужний. Стійкі гроші є каталізатором для максимізації поділу праці за допомогою максимально ефективної фінансової комунікації.
І знову фінансова система була дискредитована … але повстання американської молоді проти культури грошей так і не сталося– Майкл Люіс “Велика гра на пониження. Таємні пружини фінансової катастрофи”.
Сатоши створив біткойнов для тих, хто вірить в необхідність і можливість побудови нової фінансової системи – для Ходлерів, для революціонерів. Для тих, хто розчарувався в існуючій фінансовій системі. Для тих, кого приваблює перспектива раптових і кардинальних змін в їхньому житті.
Це більше схоже на ситуацію з дорогоцінними металами. Замість зміни кількості випущених грошей для підтримки їх вартості, кількість випущених грошей відомо заздалегідь, а їх вартість змінюється. У міру зростання числа користувачів зростає і вартість Койнів. Це створює потенціал для циклу зворотного зв’язку; в міру збільшення кількості користувачів, вартість підвищується, що може привернути більше користувачів, які хочуть отримати вигоду зі зростаючої вартості– Сатоши Накамото.
Сатоши хотів запустити мережу з механізмом заохочення учасників мережі – винагородою за блок. Таке заохочення допомогло б (а) контролювати обсяг пропозиції токенов біткойнов і (б) створити стимули для користувачів брати участь в роботі мережі.
Ходлінг допоміг біткойн народитися. Ходлінг збільшує вартість Койнів, що збільшує попит на них, хешрейт і безпеку мережі, що в свою чергу приваблює нових Ходлер і розробників. Цей самореалізуємий зворотний зв’язок забезпечує мережеві ефекти, безпеку і цінність біткойнов– @TobiasAHuber
Ранні Ходлери вірили в біткойні, незважаючи на велику кількість негативних відгуків і дезінформацію (зокрема, біткойни називали валютою для відмивання грошей і торговців наркотиками і вказували на великі коливання цін). Ходлери мали досить сильну схильність до ризику, щоб стати першими користувачами біткойнів. Вони були готові піти на цей ризик.
Не кажіть мені, що ви думаєте краще просто покажіть мені своє портфоліо– @nntaleb
Володіння біткойнами – це повна протилежність спекуляцій. Торгівлю можна назвати спекулятивною, коли стимули для купівлі та продажу засновані виключно на ринкових настроях. Ви сподіваєтеся продати продукт, незважаючи на те, що він не придбав жодної внутрішньої цінності для суспільства за той час, поки ви ним володієте. У володіння грошима немає цього недоліку, скоріше навпаки. Володіючи грошима, ви вкладаєте в економіку в цілому. Кожен раз, коли ви вирішуєте зберегти гроші, ви скорочуєте доступну в зверненні грошову масу … Це призводить до збільшення купівельної спроможності за одиницю цих грошей. В результаті ціни в цій валюті знижуються, і всі учасники цієї економіки стають багатшими. Утримуючи біткойни, ви збільшуєте їх ціну. Чим більше людей буде інвестувати свої кошти в біткойни на тривалий термін, тим швидше його волатильність поступиться місцем поступового зростання в ціні. Ця тенденція до стабільного підвищення вартості токенов робить біткойн більш привабливим для нових користувачів, створюючи цикл зворотного зв’язку–Willem_VdBergh.
Збільшення вартості біткойнів веде до більш активного його поширення. І в міру його поширення ходлінг стає популярним також серед людей з більш низькою схильністю до ризику, що забезпечує для біткойнів ще більший мережевий ефект– @robustus
З кожним таким злетом і падінням ми бачили, як біткойни переходили – в результаті торгівлі – від старих Ходлерів до нових, що сприяло зниженню коефіцієнта Джині. За один тільки 2017 рік ми спостерігали, як 15% всіх біткойнів перестали належати старим Ходлерам.
Повільно, але вірно, біткойн все більше і більше проникає в психіку можновладців– Віджей Бояпаті.
Завдяки ефекту Лінді, чим довше існує біткойн, тим більше суспільство впевнене в тому, що він буде існувати і в майбутньому.
Протоколи вмирають, коли в них більше ніхто не вірить– Naval.
Віра в нову фінансову систему – це те, що пов’язує все разом. Біткойн – це не просто проект ПО. Це спосіб координації для великої групи людей, які стикаються з могутніми супротивниками. Біткойн – це не тільки технологічний, але і соціальний прорив.
Стабільна і стійка ідеологія повинна лежати в основі всіх криптовалют. Ніяка криптографія або розрібка протоколу консенсусу не допоможуть криптовалютам з нестійкою або неспроможною ідеологією. Саме стійка ідеологія сприяє процвітанню ком’юніті– Кей Курокава.
Гроші – це заснована на мережевих ефектах технологія, що працює за принципом «переможець отримує все». Таким чином, криптовалюта з найбільшим числом Ходлер буде найбільш затребувана серед споживачів і стане переможцем.
Біткойн – це цифрове золото в очах [Ходлерів]. В якійсь мірі ця група вже мислить в біткойнов-стандарті: інвестиції оцінюються за їхньою здатністю приносити дохід в біткойнах– @TuurDemeester.
Володіючи біткойнами, ви самі стаєте наче центральним банком, основою фінансової системи. Ходлінг – це не пошук покупця, який запропонує кращу ціну колись в майбутньому – якщо станеться гіпербіткойнізація, вам ніколи не доведеться продавати свої койни.
Ходлери змінять ринок капіталу. Річна норма прибутку ваших біткойнів – це безризикова ставка з додатковими рівнями прибутку на одиницю ризику. Наприклад, мережа Lightning надає можливість вимірювання вартості біткойнів в різні періоди часу в Lightning Network Reference Rate або LNRR– Нік Бхатія.
Біткойн обіцяє громадянам всього світу можливість зберігати свої заощадження у вигляді грошей, які не можуть бути конфісковані і не втратять вартість. Різке зростання біткойнів може скасувати уряди, перетворивши їх в добровольчі організації. Ходлінг допоможе нам здобути свободу.
Ті, хто вибирають біткойни (червона таблетка), відмовляються від чогось, що є в достатку, на користь того, що є лише в обмеженому доступі, відмовляються від минулого на користь майбутнього, відмовляються від фінансової залежності на користь фінансового суверенітету.
Переклад статті “Hodlers are the revolutionaries“
Ця стаття про те, як з часом змінювалася основна концепція біткойну.
По-твоєму, я суперечу собі? Ну що ж, значить, я суперечу собі. (Я широкий, я вміщую в собі безліч різних людей.)
(Волт Вітмен, «Пісня про себе»)
Мабуть, саме постійне джерело конфлікту в біткойн-співтоваристві полягає в різних уявленнях про те, що таке біткойн і яким він повинен бути. Ті, хто намагалися побудувати бізнес на біткойні, вважаючи, що це дешева глобальна платіжна система, зрозуміли свою помилку після подій з блоками в 2017 році. Справа не в тому, що вони були неправі, просто їх уявлення про світ виявилося непопулярним в біткойн-співтоваристві, а розробка протоколу не була спрямована в потрібне русло в потрібний час.
Так як визнаний лідер у біткойну відсутня, людям доводиться грунтуватися на документах і ранніх постах на форумах, щоб розшифрувати справжні наміри Сатоши щодо валюти. Це схоже на те, як Верховний суд США схвалює корпіння над Конституцією і керується її древньою мудрістю для прийняття рішень у справах сучасності. Інші ж займаються не тлумаченням текстів, а проводять прагматичний аналіз ситуації в контексті.
Таким чином, конфлікти з біткойнами виникають через наявність взаємовиключних уявлень про його протоколі. Якщо ці уявлення примирити не можна, виникають проблеми. Уявлення про біткойн постійно змінюються. Технологічні розробки, практичні обставини і події в реальному світі формують загальне уявлення про біткойн. У цій статті я спробую об’єднати різні основні уявлення про біткойн, що виникали протягом 9-річної історії його життя. Стаття заснована на чудових роботах Мурада Махмудова і Адама Таше, які я рекомендую прочитати.
Ми хочемо детально вивчити поширення ключових концепцій. Ми виділили сім основних ідей, які зберігають домінуючі позиції в біткойн-співтоваристві протягом довгого часу. Це можуть бути не найвпливовіші концепції, але самі основні думки, що характеризують користувачів біткойнів.
Отже, в грубому порядку появи:
На графіку нижче ми порівняли різні ідеї щодо їх популярності в часі.
У цьому графіку ми порівняли відносний вплив всіх сем концепцій, перерахованих вище. З графіка видно, що ідея доказу концепції електронної валюти була домінуючою в самому початку, хоча платіжна p2p-мережі та цифрове золото також зберігали свої позиції в той час. Пізніше біткойн як анонімна валюта даркнету отримав популярність на Шовковому шляху. Ця ідея нікуди не поділася, біткойн досі використовується в даркнеті, хоча існують і інші альтернативи, що зберігають конфіденційність.
Після винаходу ICO і розвитку широкого ринку альткойнов BTC став резервним активом для більшої економіки. Це стало важливою характеристикою біткойнів, особливо під час підвищення цін в 2014 та 2017 років рр. Варто відзначити, що ідея p2p-мережі залишалася популярною до середини 2017 року, коли її прихильники почали підтримувати Bitcoin Cash (деякі перейшли на Litecoin або Dash). Проте, з появою в 2018 році мережі Lightning був помічен новий спалах ентузіазму щодо онлайн-мікротранзакцій і онлайн-платежів без комісії.
У 2015-2016 рр. почали набирати популярність сайдчейни. Передбачалося, що біткойн незабаром розширить свій функціонал, знищивши більшість альткойнов. Такі розширюють функціонал проекти, як Mastercoin (тепер він називається Omni), кольорові монети, Namecoin, Rootstock, Blockstack і Open Timestamps підтримували цю точку зору. Проте, виявилося, що впроваджувати сайдчени складно, і додаткові способи використання біткойну стали неактуальними.
Після завершення ринкової тенденції зниження ціни біткойну в 2014-2015 рр. аналітики почали міркувати над його статусом як унікальних товарних грошей. У листопаді 2015 року Туурі Демеестер опублікував інвестиційну замітку під назвою «Як приготуватися до ралі біткойну», в якій стверджував, що біткойн володіє унікальними характеристиками активу для портфелів. В середині 2016 року Бурніске і Уайт висунули серйозний аргумент на користь того, що біткойн є абсолютно новим класом активу. Аналітики відзначили, що біткойн не схожий на традиційні активи і, відповідно, біткойн став популярним засобом диверсифікації портфелів серед далекоглядних учасників індустрії управління активами. Сьогодні це дуже популярна точка зору, яка підтримується попитом на фінансові продукти, що викликають інтерес до біткойну у традиційних інвесторів.
Концепція цифрового золота була впливовою протягом всієї історії біткойну. Сьогодні з нею згодна більшість, вона стала популярнішою жалюгідного табору p2p-готівки, який розпався після появи Bitcoin Cash. Після багатьох років ворожнечі і внутрішні тертя цю ідею підтримує більшість. Проте, не всі користувачі біткойну є його ідеологічними прихильниками, і ми хотіли відобразити це на графіку. Багато власників біткойнів використовують їх для диверсифікації свого портфеля, деякі до цих пір користуються біткойнами для здійснення анонімних транзакцій в даркнета, а прихильники p2p-готівки знову набирають силу після появи Lightning.
Якщо уважно розглянути наведений вище графік, можна помітити, що деякі уявлення про біткойни повністю суперечать один одному. Наприклад, перехід до глобальної платіжної мережі на блокчейні конфліктує з концепцією цифрового золота. Ми відбили цей конфлікт між існуючими уявленнями в наступній діаграмі.
Серйозних обертів конфлікт набрав у 2015 році після створення BitcoinXT, хоча ворожі обговорення велися і задовго до цієї події. Наступні провокації, включаючи Bitcoin Classic і Unlimited, тільки посилили конфлікт, який досяг свого піку в середині 2017 року під час створення Форк Bitcoin Cash. Під час тенденції підвищення в кінці 2017 року комісії біткойнов піднялися до неймовірного рівня, завдяки чому ряди прихильників Bitcoin Cash поповнилися. Проте, з того моменту комісії вже зменшилися і необхідність у великих блоках здається не такою терміновою.
Крім того, на початку 2018 року було розпочато впровадження Lightning, з’явилася можливість проводити мікроплатежі в мережі біткойна. Таким чином, напруга ослабла, і обидва табори зосередилися на власних цілях. У 2018 році оптимізм щодо платежів другого рівня відродився, і ми помітили збільшення інтересу до дешевих платежів біткойну.
З цього аналізу можна зробити цікавий висновок: біткойн переживає рідкісну стадію відносної гармонії. Єдиної домінуючою концепції не існує, але ідея цифрового золота сьогодні є найвпливовішою. Громадянські війни 2015-2017 рр. завершилися Форком Bitcoin Cash і міграціями в інші табори p2p-платежів, серед яких Litecoin, Dash і Nano. Сьогодні основна напруга спала, і ми опинилися в незвично спокійній епосі історії біткойну. З суб’єктивної точки зору здається, що в таке відносно спокійний час розробка буде вестися швидше. Нескінченні війни в соцмережах, угоди після конференцій і створення сумнівних ФОРКІВ, безсумнівно, ускладнювали роботу розробників. Проте, на горизонті видніється новий конфлікт.
Як видно з графіка вище, анонімне і багатофункціональне уявлення про біткойн (популярне в таборі цифрового золота) знаходиться в конфлікті з фінансіалізірованною прозорою версією біткойну, популярність якої росте. Тим, хто хочуть бачити біткойн як фінансовий актив, потрібен сумісний з AML / KYC біткойн, вони приділяють менше уваги безпеці і багатофункціональності.
Зрештою, періоди конфліктів і спокою однаково важливі. Конфлікти допомагають зрозуміти позиції впливових структур, а також подають інформативні сигнали про те, що по-справжньому думають ключові гравці. Знаходяться під тиском компаніям, приватним особам та розробникам доводиться приймати якусь сторону, розкриваючи свої справжні уподобання щодо розробки протоколу.
Ми розуміємо, що велика частина нашого аналізу заснована на нашій суб’єктивної інтерпретації старих постів на BitcoinTalk. Якщо ви не згодні з цим, то ми готові розглянути альтернативні думки. Для того щоб полегшити подальший аналіз ми створили графік послідовності ключових подій біткойну, що відображає всю його історію. (За основу ми взяли грубу інтерпретацію цінового графіка 99bitcoins з примітками). Ми радимо вивчати наші кольорові графіки «мінливих припливів» разом з тимчасової схемою, наведеної нижче. Їх протиставлення допоможе зрозуміти, чому ми зробили такі висновки.
Для створення графіка змін уявлень про біткойн ми взяли за основу аналіз постів BitcoinTalk, обговорення біткойну найвідданіших його прихильників, здоровий погляд на історію біткойну і спогади про основні підходи за роки його існування. Подібний аналіз може провести кожен, хто цікавиться біткойном вже досить довгий час.
Ми не стверджуємо, що цей аналіз відображає абсолютну істину. Ми хочемо, щоб прихильники біткойнів не захоплювалися абсолютизмом і розуміли, що основні концепції в співтоваристві біткойну змінюються з плином часу. І це нормально – уявлення про речі змінюються в міру появи нової інформації. Випробування чистоти ненадійні, тому що вони мають на увазі відсутність еволюції. Якщо ж прихильники біткойну поміркують над своєю власною історією, то, швидше за все, виявлять, що і вони еволюціонували з плином часу. У всякому разі, так сталося з обома авторами цієї статті.
Нарешті, здоровий погляд на історію біткойну – це обов’язкова відправна точка для будь-якої спроби визначити його суть. Це неоднозначне поняття, і прихильники біткойну не мають про нього єдиної думки. Біткойн містить в собі безліч різних можливостей, і необхідно нагадувати собі про це.
Переклад статті “Visions of Bitcoin“