Як інструмент проектування може працювати краще для розробників? Це питання ми ставимо собі та нашій спільноті. Сьогодні ми раді представити Dev Mode – новий робочий простір у Figma, створений для того, щоб розробники отримували те, що їм потрібно, коли їм це потрібно, використовуючи інструменти, які вони використовують щодня.
Figma народилася в Інтернеті – нетрадиційний початок для інструменту проектування, але ми відчували, що він украй необхідний дизайну продуктів. За допомогою одного єдиного посилання дизайнери могли співпрацювати над поточною роботою, обмінюватися ранніми напрацюваннями, а не берегти дизайн доти, доки він не буде “відшліфований”. У міру того, як все більше дизайнерів освоювали Figma і цей розрахований на багато користувачів спосіб роботи, ми почали спостерігати природне розширення використання в різних командах і дисциплінах, особливо серед розробників.
Сьогодні ми знаємо, що на наших платних тарифних планах Figma відвідує більше розробників, ніж дизайнерів. Ми також знаємо, що розуміння потреб розробників та їх проблем має вирішальне значення для перетворення Figma на місце, де розробка продукту може бути більш ефективною, спільною та виразною.
Розробники мають унікальні робочі процеси та переваги. Від front-end розробників, які працюють із зрілими системами дизайну, до інженерів, що створюють компоненти систем дизайну, до тих, хто створює макети контенту та експортує ресурси у своїй роботі з бренд-дизайнерами, – кожна команда хоче працювати з мінімальними обмеженнями, наскільки це можливо .
У режимі Dev Mode ми бачимо величезну можливість швидко та ефективно надавати розробникам те, що їм потрібно – так само, як це було з дизайнерами, коли ми тільки розпочали створення Figma. Чим простіше командам проектувати, документувати, знаходити і реалізовувати високоточні проекти, не втрачаючи при цьому на увазі роботу і один одного, тим кращий результат продукту. Ми раді зробити цей перший крок до об’єднання проектування та розробки у Figma, і нам не терпиться побачити, що команди робитимуть далі.
Швидше приступайте до кодингу
Хоча Figma відмінно підходить для вільного дослідження дизайну, вона може спантеличити, якщо ви потрапили у файл дизайну, в якому відсутня інформація, необхідна для реалізації. Режим Dev Mode – це як інспектор браузера для вашого файлу дизайну, він наближає концепції дизайну – форми, шари та групи – до концепцій розробника, таких як код, іконки та маркери. Навівши курсор і натиснувши на полотно Figma, ви можете знайти та експортувати всю необхідну інформацію, таку як вимірювання, специфікації та активи, а також розкрити додатковий контекст вашої системи проектування. Подібно до Chrome Dev Tools , Dev Mode черпає натхнення з інших інструментів розробки, щоб створити середовище, яке відразу ж стане для вас звичним.
Код у режимі Dev Mode повністю перероблений і налаштовується під ту мову, якою ви працюєте. Ми знаємо, що код не є корисним із коробки. Швидше, він є відправною точкою, щоб вам не доводилося щоразу переходити від 0 до 1. Тепер ви побачите боксову модель CSS, сучасний синтаксис з деревоподібною виставою, а також зможете перемикатися між одиницями вимірювання, щоб відповідати вашій кодовій базі.
Доступ до всього, що вам потрібно, в одному місці
Створення продуктів вимагає надійного набору інструментів, але стрибки між бібліотеками дизайну, базою коду та іншими інструментами управління проектами можуть призвести до неефективності, особливо коли назви компонентів та стилів не збігаються з назвами коду, або команда не відстежує та не документує завдання. Dev Mode покликаний зробити вашу роботу більш продуктивною, зв’язавши інструменти і компоненти коду, що використовуються вами, з файлом дизайну.
Плагіни дозволяють розширити функціональність Figma, щоб адаптувати її до того, як працює ваша команда. Ви можете керувати проектами за допомогою Jira , Linear та GitHub , щоб ви і ваш дизайнер знали, що відбувається у ваших відповідних процесах. Storybook допоможе вам послатися на те, що відбувається у вашій кодовій базі, у контексті самого дизайну. А плагіни codegen від AWS Amplify Studio , Google Relay та Anima допоможуть вам налаштувати висновок коду – ви навіть можете створити свій власний на основі вашого унікального робочого процесу.
Дуже корисно мати плагіни, які взаємодіють із нашими повсякденними інструментами. Ми використовуємо GitHub, ми використовуємо Storybook – це економить мені багато часу.
Лоран Тьєбо, керівник інженерного відділу та провідний спеціаліст з систем проектування, Decathlon (частина бета-версії Dev Mode)
Системи проектування стають більш потужними із запровадженням токенів проектування через змінні . Токени – це маленькі шматочки даних інтерфейсу користувача, які можна використовувати в дизайні і коді. Тепер вони відображаються в режимі Dev Mode, тому відразу стає зрозуміло, що потрібно для початку розробки. Ви також можете додати пов’язані посилання на об’єкти на полотні, щоб посилатися на документацію або те, що знаходиться у ваших плагінах.
Слідкуйте, що має бути відправлено у розробку
Навіть якщо етапи проектування та розробки продукту зливаються воєдино, артефакти кожної з них – файли дизайну та код – залишаються різними. До цих пір було непросто переміщатися файлами дизайну, вибирати конкретні компоненти та їх властивості або навіть знати, що змінилося з моменту останнього перегляду файлу. Тепер дизайнери можуть просто позначити розділ як “готовий до розробки” і відправити його безпосередньо, не створюючи окрему сторінку або файл. Підтримка Diff дозволяє порівнювати зміни між різними версіями кадру і залишатися в курсі подій.
Розширте свій робочий процес
За допомогою розширення VS Code ви можете використовувати можливості режиму Dev Mode у редакторі коду для перегляду дизайну, повідомлень та коментарів, а також для відстеження змін, не виходячи із середовища розробки. Розширення VS Code також виконує автокомліт стро коду на основі перегляду дизайну, допомагаючи вам працювати набагато швидше.
Dev Mode та Figma для VS Code знаходяться у бета-версії та безкоштовні для всіх користувачів до кінця 2023 року. Починаючи з 2024 року, для доступу до Dev Mode вам знадобиться платний тарифний план. Якщо ви є редактором на платному тарифному плані сьогодні, Dev Mode буде увімкнено. Ми знаємо, що є розробники, яким може не знадобитися повний набір функцій Figma, тому вводимо два нових варіанти тарифного плану для них.
Набагато вищий рівень довіри, коли люди працюють з одним і тим самим інструментом – інформація набагато актуальніша, ви більше не тягнете якісь файли на свій комп’ютер і не ганяєтеся за чимось електронною поштою. Це набагато спільніший процес.
Джорі Лалло, співзасновник, Linear
Це лише перший крок у покращенні Figma для розробників. З урахуванням вашого вкладу в бета-версію Dev Mode та VS Code ми з нетерпінням чекаємо на розширення функціональності, включаючи нові способи покращення співпраці дизайнера та розробника, отримання специфікацій та забезпечення більшої відповідності між дизайном та кодом.
Індекс страху та жадібності на крипторинку. Все про показник простими словами.
У цьому матеріалі ми розберемо дуже важливий показник стану як фінансового, так і криптовалютного ринку – індекс страху та жадібності та відповімо на запитання: чому важливо його включати до свого ресерчу? На основі яких даних він вимірюється? Як інтерпретувати його значення? І що таке “надзвичайна жадібність” та “абсолютний страх”? Поїхали!
Що таке індекс страху та жадібності?
Більшість рішень учасники фінансових ринків беруть на емоціях. Коли люди бачать зростання ринку, вони починають відчувати FOMO (синдром втраченого прибутку) і жалкувати, що не зайшли в ринок до того, як він почав зростати. У той же час інвестори, які вже перебувають в активах, хочуть забрати ще більший прибуток і продовжують збільшувати свої позиції. Ці процеси формують над ринком стан “жадібності”.
Зворотна ситуація – “абсолютний страх” на ринку вказує на те, що криптовалюти недооцінені. Це може призвести до масового продажу валют і надмірної паніки. Проте страх не обов’язково означає, що на ринку спостерігається довгостроковий ведмежий тренд. Його варто розглядати як короткостроковий чи середньостроковий зріз настроїв ринку.
Індекс страху та жадібності аналізує різні тенденції та показники ринку, щоб визначити, чи відчувають учасники ринку жадібність чи страх. Оцінка 0 свідчить про надзвичайний страх (Extreme Fear), а 100 – на крайню жадібність (Extreme Greed). Оцінка 50 показує, що ринок щодо нейтральний.
Умовно, шкалу індексу можна поділити на кілька категорій:
0–24: сильний страх (помаранчевий)
25-49: страх (жовтий)
50-74: жадібність (світло-зелений)
75–100: сильна жадібність (зелений)
На основі яких даних вимірюється індекс страху та жадібності?
Складові індексу страху та жадібності:
Волатильність (вага в індексі – 25%)
В даному випадку вимірюється поточна волатильність і максимальні просідання BTC, проводиться порівняння з середніми значеннями за останні 30 і 90 днів. Незвичайний сплеск волатильності – це ознака ринку, що «лякає».
Співвідношення імпульс/обсяг ринку (25%)
Для визначення даного показника співвідносяться значення поточного обсягу та ринкового імпульсу (також за останні 30 та 90 днів). Якщо щодня на тлі позитивних умов на ринку фіксуються високі обсяги покупок, це означає, що гравці ринку виявляють зайву жадібність.
Соціальні мережі (15%)
Цей фактор аналізує кількість пов’язаних з криптовалютами хештегов у Twitter та швидкість їх поширення. Твіти збираються, підраховуються та аналізуються: наскільки швидко та активно користувачі реагували на ці повідомлення за певні періоди часу. Висока активність призводить до зростання інтересу громадськості до монети і, на думку авторів індексу, відображає жадібність гравців ринку.
Опитування професійних учасників ринку (15%)
Спільно з платформою strawpoll.com розробники Індексу жадібності та страху проводять щотижневі опитування та дізнаються, як люди сприймають поточну ситуацію на ринку. У кожному опитуванні бере участь 2000-3000 чоловік, і таким чином формується уявлення про настрій крипто інвесторів.
Домінація BTC (10%)
Про цей показник буде окремий матеріал у наступних статтях. Тут коротко. Домінація – частка монети у загальній ринковій капіталізації. У випадку з біткоїном: розробники індексу вважають, що зростання домінації викликається страхом надзвичайно спекулятивних інвестицій в альткоїни, тому біткоїн стає дедалі безпечнішим інструментом збереження капіталу. І навпаки, коли домінування BTC зменшується, це означає, що люди виявляють зайву жадібність, вкладаючи гроші в ризикованіші альткоїни, мріючи про можливість взяти участь у новому великомасштабному бичачому ралі.
Google Trends (10%)
Для оцінки даної метрики аналізуються дані Google Trends за різними пошуковими запитами, пов’язаними з біткоїном та іншими криптовалютами. Особлива увага приділяється зміні обсягів пошукових запитів, а також рекомендованим та популярним запитам на даний момент.
Де відстежувати індекс страху та жадібності?
Індекс страху та жадібності для криптовалютного ринку можна відстежувати тут.
Індекс страху для ринку вважається інакше, але має той самий сенс – відбиває емоційний настрій учасників ринку. Його можна відстежувати за цим посиланням.
Індекс страху і жадібності – це лише один з його статистичних метрик. Для повного аналізу його значення недостатньо, але як доповнення до вашої системи ресерчу та для швидкої оцінки поточної ринкової ситуації – це досить добрий інструмент.
:nth-child(2n): Вибере всі парні дочірні елементи (2-й, 4-й, 6-й, 8-й тощо).
:nth-child(2n+1): Вибере всі непарні дочірні елементи (1, 3, 5, 7 і так далі).
:nth-child(5n+1): Вибере 1-го (=(5×0)+1), 6-го (=(5×1)+1), 11-го (=(5×2)+1), дитину.
Щоб інтерактивно побачити, як логіка An+B впливає виділення, використовуйте тестер :nth-child.
Але можна зробити творчіший вибір, якщо опустити параметр A. Наприклад:
:nth-child(n+3): Вибере кожен дочірній елемент, починаючи з третього (3-й, 4-й, 5-й тощо).
:nth-child(-n+5): Вибере кожен дочірній елемент до 5-го (1-го, 2-го, 3-го, 4-го, 5-го).
Об’єднайте кілька таких селекторів :nth-child()і ви зможете вибирати діапазони елементів:
:nth-child(n+3):nth-child(-n+5): Вибере кожен дочірній елемент від 3-го до 5-го (3-й, 4-й, 5-й).
Використовуючи :nth-last-child(), ви можете робити подібні селектори, але замість того, щоб починати рахувати з початку, ви починаєте рахувати з кінця.
Коли вказано of S, логіка An+B застосовується лише до тих елементів, які відповідають заданому списку селекторів S. Це означає, що ви можете попередньо фільтрувати дочірні елементи, перш ніж An+B зробить свою справу.
Приклади
Наприклад, :nth-child(2 of .highlight)вибирає другий відповідний елемент, що має клас .highlight. Іншими словами: з усіх дочірніх елементів із класом .highlightвиберіть другий.
Це відрізняється від .highlight:nth-child(2), який вибирає елемент, що має клас .highlight, а також другий дочірній елемент.
У демонстраційному прикладі нижче ви можете побачити цю різницю:
Елемент, що відповідає :nth-child(2 of .highlight), має рожевий контур.
Елемент, відповідний .highlight:nth-child(2), має зелений контур.
Зверніть увагу, що Sце список селекторів, що означає, що він приймає кілька селекторів, розділених комою. Наприклад, :nth-child(4 of .highlight, .sale)вибирає четвертий елемент, який є .highlightабо .saleз безлічі дочірніх елементів.
У демонстраційному прикладі нижче елемент, що відповідає :nth-child(4 of .highlight, .sale), має оранжевий контур.
Зебра, переглянутий варіант
Класичним прикладом використання :nth-child()є створення таблиці зі смужками зебри. Це візуальний прийом, коли в кожному рядку таблиці чергуються кольори. Зазвичай це робиться так:
Хоча це добре працює для статичних таблиць, це стає проблематичним, коли ви починаєте динамічно фільтрувати вміст таблиці. Коли, наприклад, другий рядок стає прихованим, у результаті залишаються видимими перший і третій рядки, кожен з яких має однаковий колір тла.
Щоб виправити це, ми можемо використовувати :nth-child(An+B [of S]?), виключивши приховані рядки з логіки An+B:
tr:nth-child(even of :not([hidden])) {
background-color: lightgrey;
}
Посткапіталізм – термін, що описує нову економічну систему, яка має прийти на зміну капіталізму.
Докладно концепцію посткапіталізму описав британський журналіст Пол Мейсон. На його думку, поточна капіталістична модель себе вичерпала і веде до масового збіднення та зростання нерівності.
На думку Мейсона, зараз людство переходить до системи посткапіталізму. Глобальні тенденції, такі як повсюдна автоматизація та поширення інформаційних технологій, дозволять у майбутньому мінімізувати вартість основних товарів та послуг, значно підвищивши якість життя.
Централізовані та ієрархічні економічні структури поступляться місцем горизонтальним моделям добровільного співробітництва.
Концепцію посткапіталізму, описану Мейсоном, критикують за утопізм та ангажованість у бік лівої ідеології.
«Неоліберальна революція»
Теорію посткапіталізму виклав британський журналіст та публіцист Пол Мейсон у книзі «Посткапіталізм. Путівник з нашого майбутнього» (PostCapitalism: A Guide to Our Future), виданої у 2015 році.
У своїй роботі він вказував на структурні проблеми в західній економіці і популярність вкрай правих сил, що зростає, як на тривожні ознаки системної кризи капіталізму. Волатильність суспільно-економічного життя в розвинених країнах, на його думку, викликана тим, що «неолібералізм зламаний».
Мейсон зазначав, що реальні зарплати перестали зростати пропорційно до зростання продуктивності з початку 1970-х років. До початку 1980-х економічне зростання почали все активніше підтримувати за допомогою боргових інструментів, через що їхній загальний обсяг зріс до більш ніж 300% від світового ВВП до 2010 року. Восени 2021 року розмір боргових зобов’язань перевищив $300 трлн, а їхнє співвідношення до глобального ВВП — 350%.
Зростанню боргу сприяла грошово-кредитна політика: ключові ставки у США та країнах Європи послідовно знижувалися починаючи з 1980 року. Це стимулювало економічне зростання за рахунок дешевих інвестицій. Інший чинник — масштабне збільшення грошової маси, зокрема шляхом програм «кількісного пом’якшення», запущених починаючи з 2008 року. Як результат, прискорилася інфляція, а реальні ставки за вкладами та державними облігаціями впали.
1979 року відбулася «неоліберальна революція», констатує автор «Посткапіталізму». Вперше за сотні років капіталістична еліта вийшла з чергової кризи не шляхом компромісу з «робочою більшістю», а стрімким нарощуванням боргу за рахунок емісії грошей. Це і призвело до збільшення продуктивності без зростання реальних доходів у наступні десятиліття.
Криза капіталізму
«Капіталізм більше не здатний адаптуватися так, як він робив це в найуспішніші часи початку 20 століття і після Другої Світової війни. Він більше не дозволяє створювати цінність із навичок та працездатності», — вважає Мейсон.
На сучасну економіку дуже впливає так званий «інформаційний ефект». За словами Мейсона, стрімке зростання обсягу інформації та її вільне поширення змогли зробити доступними багато послуг та товарів. Проте через структурні особливості капіталізму вони вирішили проблему продуктивності, що у стагнації.
Цифрова економіка у поточній структурі «класичного» капіталізму, впевнений Мейсон, сприяла небувалій концентрації багатства. В даному випадку в руках великих технологічних корпорацій, які монополізували інформаційне середовище за допомогою платформ. Як наслідок, соціальне розшарування останні десятиліття лише збільшилося, що характеризується постійним створенням беззмилених робочих місць (bullshit jobs).
Ще один наслідок неоліберальних відносин — переведення на ринкові відносини діяльності, яка раніше була суспільною та добровільною, а також фінансування різних товарів та об’єктів.
Перехід до посткапіталізму
Мейсон упевнений, що світова економіка знаходиться на порозі нового історичного циклу завдовжки 500 років. Попередній цикл розпочався у 15-му столітті та призвів до появи капіталізму. Новий тип економічних відносин дослідник назвав пост-капіталізмом. Його наступ став можливим завдяки технологічному прогресу.
Транзиту до пост-капіталізму, який зможе вирішити проблеми, сприятимуть кілька глобальних трендів:
Тотальна автоматизація промисловості та сфери послуг за рахунок машин, ІІ та роботів;
запровадження загального базового доходу;
Доступність основних товарів споживання;
Розповсюдження принципу відкритого вихідного коду;
Боротьба з рентними економічними моделями та монополіями;
Зниження розміру громадського боргу шляхом регулювання банківської сфери та утримання ставок нижче за рівень інфляції.
Мейсон закликає віддавати перевагу в інвестуванні інформаційно-мним технологіям, наприклад у сфері промисловості та охорони здоров’я. Останнє дозволить суттєво знизити вартість життя та підвищити його якість, водночас знизивши навантаження на систему соціального забезпечення.
Підсумком усіх цих тенденцій стане мінімізація вартості більшості товарів та послуг, що дозволить підвищити загальний рівень добробуту, а потреба у низькокваліфікованій роботі відпаде. Обсяг обов’язкової роботи скоротиться, вільний час у більшості людей стане вільним. Будуть втрачати колишню роль засновані на нерівності централізовані структури та вертикальна ієрархія.
Натомість все більшого поширення набудуть децентралізовані моделі діяльності, в яких індивідуальні фахівці добровільно об’єднуватимуться для реалізації будь-яких проектів. Для цього вони витрачатимуть свій вільний час, часто не вимагаючи жодної оплати.
Концепція критики
Хоча деякі експерти визнають обґрунтованість ідей Мейсона, інші критикують його пропозиції та висновки. Крістан Фукс з університету Вестмінстера називає автора «Посткапіталізму» «утопічним соціалістом», який сподівається на інформаційні технології як спосіб вирішення економічних проблем.
Він зазначає, що технології формуються під впливом самої ієрархічної системи капіталізму. Отже, вони скоріше сприяють його розвитку, а чи не сприяють краху.
Оглядач The Guardian Кріс Маллін у своїй рецензії на книгу пише, що сприйняття Мейсоном профспілок та робочого руху у 1960-х та 1970-х на Заході, зокрема у Великій Британії, надто ідеалізоване.
Крім того, Маллін вказує на минуле Мейсона: у молодості той брав активну участь у ліворадикальних рухах. Цим, як вважає критик, можна пояснити, чому Мейсон присвятив значну частину своєї книги критиці капіталізму, але запропонував надто просту і розпливчасту програму дій, що відсилає до робіт Маркса та соціалістичних політиків минулого.
7 Інструментів для оптимізації та прискорення React розробки
React – це універсальна і гнучка бібліотека, яку можна використовувати для створення всього, від великих SPA до компактних модулів, що підключаються. Однак створення React проекту може виявитися непростим завданням, що потребує нескінченних доробок та різних маніпуляцій. Отже, вам потрібно буде мати у своєму наборі інструментів найкращі, щоб прискорити розробку React.
У цій статті я розповім про 7 інструментів і фреймворків, що змінюють правила гри, які зроблять вашу розробку React швидше, простіше і ефективніше, ніж будь-коли! Отже, приготуйтеся попрощатися з дискомфортом від метушні та перейти до більш ефективного робочого процесу!
1. Gatsby
Сайти з великою кількістю контенту, такі як блоги та інтернет-магазини повинні ефективно працювати з великими обсягами контенту. Старий create-react-app, не підходить для такого роду веб-сайтів, тому що він надає все у вигляді єдиного великого JavaScript файлу (bundle), який браузер повинен завантажити, перш ніж щось відобразиться на сторінці. Найбільш підходящим рішенням цієї проблеми є використання Gatsby – популярного генератора статичних сайтів з відкритим вихідним кодом на основі React.
Gatsby дозволяє розробникам створювати швидкі, безпечні та прості в обслуговуванні веб-сайти. Він генерує статичні файли HTML, CSS та JavaScript, які можуть бути надіслані безпосередньо за допомогою CDN (Мережа доставки вмісту) або веб-сервера, що робить його чудовим вибором для створення веб-сайтів із високими обсягами трафіку. Gatsby має безліч плагінів, які можуть ефективно завантажувати та перетворювати дані зі статичних локальних даних, джерел GraphQL та сторонніх систем керування контентом, таких як WordPress.
2. NextJs
Next.js це інструмент для генерації React додатків та серверного коду. API та клієнтські сторінки використовують угоди про маршрутизацію за умовчанням, що спрощує їх створення та розгортання, ніж якби ви керували ними самостійно. Ви можете знайти повну інформацію про Next.js на веб-сайті.
Наступного разу, коли ви захочете керувати серверним та клієнтським кодом одночасно, розгляньте NextJS.
3. Webpack
Наступний у цьому списку – не фреймворк, а збирач модулів JavaScript з відкритим вихідним кодом. Webpack часто використовується в програмах React для об’єднання коду і пов’язаних з ним ресурсів в один файл, який може бути переданий браузеру.
Крім компіляції програми, Webpack також можна використовувати для використання гарячої заміни модуля (HMR) у програмі React, що дозволяє вам бачити зміни у вашому коді в режимі реального часу без необхідності оновлювати сторінку.
4. Storybook
Storybook – це інструмент для відображення бібліотек компонентів у різних станах. Ви можете назвати це як галерея компонентів , але це, ймовірно, занадто коротко. Насправді Storybook – це інструмент для розробки компонентів. Він може бути пов’язаний з React для створення колекції компонентів, які можна переглядати ізольовано та тестувати незалежно один від одного.
5. Preact
React програми можуть бути більшими. Досить легко створити просту програму React, яка перетворюється на бандли JavaScript-коду розміром у кілька сотень кілобайт. Якщо вам потрібні функції React, але ви не бажаєте щоб бандли важили по кілька мегабайт і більше, то розгляньте можливість використання Preact.
Preact – це не React. Він заснований на тому ж API, що і React, і поділяє багато його функцій, такі як компоненти, керування станом і віртуальний DOM. Однак він відрізняється від React кількома ключовими способами. Наприклад, Preact використовує більш агресивний підхід до оптимізації, покладаючись на такі методи, як запам’ятовування (memoization) та відкладена оцінка (lazy evaluation), щоб мінімізувати обсяг роботи, який необхідно виконати для оновлення DOM.
6. nwb
newb (“neutrino-web”) – це інструмент для створення повноцінних React додатків або окремих компонентів. Він також може створювати компоненти для використання в проектах Preact та InfernoJS. Він надає простий консольний інтерфейс для створення React додатків та з коробки має підтримку популярних інструментів та фреймворків, таких як Webpack, Babel та Jest.
Використовуючи nwb, ви можете легко налаштувати новий проект React всього кількома командами, а також швидко створити, протестувати і розгорнути свою програму без необхідності самостійно керувати складними конфігураціями або залежностями.
7. Razzle
Razzle – це інструмент, який абстрагує всю складну конфігурацію, необхідну як для додатків SPA, так і для SSR, в єдину залежність, надаючи вам приголомшливий досвід розробника create-react-app, але залишаючи інші архітектурні рішення вашого додатка щодо фреймворків, маршрутизації та вибірка даних залежить від вас. При такому підході Razzle працює не тільки з React, але і з Preact, Vue, Svelte та Angular.
Що сталося у 1971 році і чому це так важливо для криптовалют?
Щоб відновити світову економіку, яка сильно постраждала через Другу Світову війну, в 1944 році представники 44 держав, які входили до Антигітлерівської коаліції, ухвалили угоду про нову валютну систему, названу Бреттон-Вудською за місцем проведення конференції.
В основі нової системи була фіксована вартість золота ($35 за тройську унцію) та тверді курси валют країн-учасниць, встановлені стосовно ключової валюти — долара США. Прив’язка була зумовлена тим, що вже тоді економіка Сполучених Штатів була найбільшою і найменше постраждала від війни.
У США зберігалася приблизно половина світових запасів золота. Хоча Бреттон-Вудська система змінила систему золотого стандарту, вона багато в чому була його продовженням: вартість валют була забезпечена запасами золота.
Нова система гарантувала конвертованість долара та зробила його світовою резервною валютою. Завдяки цьому та іншим заходам післявоєнна економіка змогла повністю відновитись до початку 1950-х і продовжила швидко зростати. На Заході цей період довжиною приблизно 25 років назвали «повоєнним економічним дивом».
Упродовж цього часу у світі зберігався високий попит на долари. Щоб задовольнити цей попит, Федеральна резервна система США (ФРС) друкувала гроші швидше, ніж зростав обсяг золота в резервах. Крім того, з початку 1960-х Сполучені Штати все активніше залучалися до війни у В’єтнамі, що вимагало підвищити державні витрати — їх також частково покривали за рахунок «друкарського верстата».
До 1969 року, коли президентом США став Річард Ніксон, загальна емісія долара перевищувала забезпечення у золоті вчетверо. За словами професора Єльського університету Джеффрі Гартнера, який написав книгу про подальші події, у керівництві країни всерйоз побоювалися економічної дестабілізації. Крім того, «сильний долар» робив експорт товарів із США дуже дорогим. У травні 1971 року з Бреттон-Вудської системи вийшла ФРН, а пізніше і Швейцарія. Інші країни також почали поступово обмінювати американську валюту золотом.
На початку серпня 1971 року Конгрес США рекомендував провести девальвацію долара. Саме це рішення протягом деякого часу вже таємно готували до адміністрації Ніксона. 15 серпня американський президент записав звернення до нації, в якому повідомив про відв’язування долара від золота. Ця подія отримала назву «Ніксонівський шок».
«Що це рішення означає для вас? <…> Якщо ви хочете купити іноземний автомобіль або поїхати за кордон, ринкові умови можуть призвести до того, що на долари можна буде купити трохи менше. Але якщо ви серед абсолютної більшості американців, які купують продукти, виготовлені в Америці, ваш долар буде коштувати стільки ж завтра, скільки й сьогодні», — зокрема сказав Ніксон у своїй промові.
Наслідки Ніксонівського шоку та Рейганоміка
Головним наслідком відмови від «золотого стандарту» стала поява глобального ринку національних валют та вільних обмінних курсів грошей. Центральні банки отримали можливість проводити набагато гнучкішу грошово-кредитну політику, зокрема масштабно друкувати гроші для вирішення проблем держави та економіки.
Нова грошова система проявила себе на початку 1980-х років, після того як Рейган проголосив неолібералізм в економіці та неоконсерватизм у політиці.
Протягом 1970-х США та країни Заходу вразила стагфляція — послідовне знецінення валюти за відсутності економічного зростання. Адміністрація Рейгана значно скоротила рівень податків, особливо для бізнесу — це було покликано збільшити інвестиції та скоротити рівень безробіття. Рейган активно скорочував держвитрати на соціальні програми, але водночас суттєво підвищив військовий бюджет та витрати на держапарат.
В результаті вдалося перемогти інфляцію та безробіття, проте зниження податкових надходжень та підвищення військових видатків призвело до різкого зростання дефіциту бюджету США, який активно покривали за рахунок нарощування національного боргу. У результаті до 1988-го його показник зріс утричі, а Сполучені Штати вперше за багато десятиліть перетворилися з найбільшого світового кредитора на найбільшого позичальника.
Рейганоміка мала й довгострокові соціально-економічні наслідки: реальні доходи продовжили падати, а соціальне розшарування стало різко зростати. Цей тренд не вдалося зупинити досі: у період із 1964 по 2018 роки. доходи американців із поправкою на інфляцію зросли лише на 10% .
Як криптовалюти пов’язані з остаточним скасуванням «золотого стандарту»
Багато дослідників публікацій Сатоші Накамото та його соратників сходяться на думці, що біткоін створювали під впливом Австрійської школи економіки та її послідовників. У своїх повідомленнях на форумах і листах майбутні творці криптовалюти згадували таких економістів як Людвіг фон Мізес, який підтримував золотий стандарт і виступав проти принципу часткового банківського резервування. Також творець біткоїну черпав натхнення, ймовірно, були Фрідріх Хайєк, який розвивав концепцію приватних грошей, та Мюррей Ротбард.
Біткоїн став відповіддю на фінансову кризу 2008 року та обрані способи боротьби з нею. Тоді влада Сполучених Штатів та інших країн вперше застосувала політику «кількісного пом’якшення»: центральні банки скуповували проблемні боргові інструменти за рахунок масштабної емісії валюти, зберігаючи при цьому низькі відсоткові ставки. Створювався ризик гіперінфляції, якої все ж таки вдалося уникнути.
«Ключова проблема традиційних валют — довіра, яка потрібна для їхньої роботи. Центральному банку треба довіряти в тому, що він не девальвує валюту, але історія фіатних грошей сповнена порушень цієї довіри. Банкам потрібно довіряти, щоб зберігати там гроші та передавати їх, але ті використовують їх для позик, повторюючи кредитні бульбашки, залишаючи лише малу частину в резервах», — писав Накамото .
Простіше кажучи, криптовалюта є відповіддю на проблеми нової грошової системи, яка призвела до довгострокових негативних ефектів. А точкою відліку цієї нової системи став Ніксонівський шок 1971 року. Такий погляд у криптоспільноті популяризували автори сайту WTF Happened In 1971, які опублікували про нього безліч графіків, присвячених тим чи іншим суспільно-економічним трендам у США. Ось один із графіків:
Концепція критики
Незважаючи на негативне ставлення до скасування «золотого стандарту», у науковій спільноті загалом позитивно сприймають рішення, ухвалене Ніксоном у 1971 році. Опитування професійних економістів, проведене в 2012 році, показало, що жоден з них не бачить повернення золотого стандарту як спосіб покращити економічну систему.
Крім того, не доведено прямого зв’язку між зміною грошової системи, з одного боку, і зростанням нерівності та стагнацією, з іншого. Автори сайту WTF Happened In 1971 показали кореляцію, але не причинно-наслідковий зв’язок, що часто плутають. В одному із коментарів вони навіть визнали, що їхній проект — скоріше спроба поставити питання, а не відповісти на нього, а сайт — мем. Зрештою, рівень життя як на Заході, так і у світі загалом після 1971 року не впав, а значно зріс.
Огляд коду – один із складових процесів підтримки якості програмного забезпечення. У ході нього одна або кілька осіб вивчають та оцінюють програму в основному шляхом перегляду та читання окремих фрагментів його вихідного коду.
Перевірка вихідного коду вручну або автоматично (за допомогою спеціальних інструментів огляду коду) є частиною процесу моніторингу якості програми. Це робиться для пошуку та виправлення помилок, вивчення відповідності стандартам кодування, читабельності та ремонтопридатності коду, наявності дублікатів тощо. Кожна частина програмного забезпечення чи нова функція, створювана розробниками компанії, перевіряється на якість.
Створення надійної процедури перевірки коду закладає основу для безперервного розвитку продукту та запобігає випуску небезпечного для користувачів коду. Щоб підвищити якість коду і переконатися в тому, що кожен фрагмент коду був переглянутий іншим членом команди, методи код-рев’ю повинні бути включені до повсякденної роботи команд, які розробляють програмне забезпечення.
Під час проведення код-ревью слід пам’ятати про такі речі, необхідні ефективного результату.
Огляд коду має бути швидким, зі своєчасними відповідями та зворотним зв’язком. Аналіз коду повинен проводитися відразу після висування нового коду, щоб розробник міг отримати моментальний зворотний зв’язок.
Аналіз коду має розвивати та вчити. Оскільки основною метою процесу є підвищення якості коду, огляди, що проводяться, повинні стати засобом обміну знаннями і досвідом між колегами.
Огляд коду має супроводжуватись тестами. Без проведення необхідних тестів огляд може залишити не усунені помилки та проблеми з безпекою в коді.
Коментуйте та заохочуйте хороше кодування після огляду коду. Варто дати зрозуміти власнику коду, що він добре справляється зі своєю роботою. Огляд коду служить не тільки для пошуку помилок, але й для заохочення програмістів.
Оглядачі коду повинні дотримуватися стандартних практик кодування. Рев’ю коду не варто будувати на індивідуальних припущеннях, необхідно дотримуватися загальноприйнятих принципів, на які можна посилатися та цитувати. Це необхідно для того, щоб усі дотримувалися стандартів кодування, посібників зі стилю та принципів мови, прийнятих для розробки програм.
Результати ревью можуть стати причиною розбіжностей між рев’юєром та розробником. Програміст може не приймати коректність і актуальність зауважень, що висуваються. Подібні суперечки слід вирішувати, дотримуючись загальноприйнятих практик, викладених у посібнику зі стандартів стилю кодування, а також враховуючи думки фахівців, які мають великий досвід у даній галузі.
Приклади коментарів до реву коду:
Підвищення ефективності коду:
“Розгляньте можливість використання словника замість циклу для перевірки існування елемента у списку”.
“Цю ділянку коду можна рефакторити, щоб використовувати вираз-генератор”.
Поліпшення читабельності:
“Ім’я змінної ‘temp’ недостатньо описує її, будь ласка, придумайте більш осмислене ім’я”.
“Функцію можна зробити більш читабельною, додавши до неї doc-рядок, що пояснює її призначення”.
Обробка помилок:
“Цей код не обробляє винятки належним чином, будь ласка, додайте блок try-except для обробки можливих помилок”.
“У даному випадку не слід повертати None, подумайте про те, щоб натомість викинути виняток”.
Безпека:
“Переконайтеся, що введення користувача сановано правильно, щоб уникнути атак XSS і SQL-ін’єкцій”.
“Розгляньте можливість використання бібліотеки типу hashlib для безпечного хешування паролів замість модуля sha256”.
Тестове покриття:
“Цьому коду потрібно більше тестових прикладів, щоб забезпечити повне покриття та запобігти регресії”.
“Будь ласка, додайте негативні тестові випадки, щоб перевірити поведінку коду у непередбачених ситуаціях”.
Стандарти коду та найкращі практики:
“Функція не повинна мати побічних ефектів, будь ласка, відрефакторіть її, щоб вона повертала лише значення”.
“Уникайте використання глобальних змінних, замість них використовуйте властивості класу чи аргументи функцій”.
Найкращі практики рев’ю коду
Встановіть цілі та стандарти компанії. Перед початком огляду коду дуже важливо вибрати ключові показники і встановити чіткі цілі. Цілі компанії мають ставитися з урахуванням відповідних стандартів програмування. Встановивши свої стандарти, компанія повинна гарантувати, що будь-який програмний продукт, який вона розробляє, відповідатиме вимогам.
Створіть чек-лист, щоб перевірити код. Чек-лист складається із встановлених наборів рекомендацій та питань, яких дотримується компанія протягом всього процесу перевірки коду. Це дає компанії перевагу організованого підходу до необхідних перевірок якості коду перед його затвердженням у кодовій базі.
Встановіть деякі метрики для перегляду коду. Ступінь підвищення якості коду має якимось чином оцінюватися. Використовуючи об’єктивні метрики, ви можете вивчити вплив запитів на зміни та оцінити ефективність ваших оцінок.
Обмежте кількість рядків коду для огляду за один раз. Це необхідно, щоб огляд проходив з однаковою ефективністю.
Застосовуйте засоби автоматизації. Будь-яка команда або компанія розробників повинна мати у своєму арсеналі спеціальні засоби автоматизованої перевірки коду. За допомогою подібних інструментів час перевірки коду може бути скорочений до декількох хвилин. Вони здатні проаналізувати всю базу коду за лічені хвилини, виявити помилки та дублікати коду та запропонувати виправлення. До таких інструментів можна віднести: PVS-Studio (виявляє помилки, мертвий код, потенційні вразливості), SonarQube (перевіряє помилки, відповідність стандартам кодування, технічний обов’язок), AppRefactoring (виявляє дублікати та перетину фрагментів коду, надаючи інформацію для унікалізації коду), (Виявляє помилки в коді, проблеми безпеки) та інші.
Дайте позитивний зворотний зв’язок на оглядах коду. Вихідний код може бути результатом парного програмування, тому корисно давати зворотний зв’язок для позитивних змін та рекомендацій.
Приклад чек-листа ревью коду
Структура коду:
Правильні відступи та форматування
Погодження правил іменування та чіткої організації коду
Коментування та документація
Продуктивність:
Ефективність та оптимізація коду
Уникнення ресурсомістких операцій
Безпека:
Валідація та санація введення
Практика безпечного кодування (наприклад, запобігання ін’єкціям SQL)
Захист від поширених загроз (наприклад, XSS)
Функціональність:
Правильна та очікувана поведінка коду
Обробка та налагодження помилок
Тестове покриття:
Правильне тестування та покриття коду
Правильні тестові кейси та умови тестування
Стандарти коду та найкращі практики:
Дотримання професійних стандартів та угод
Можливість повторного використання, супроводжуваність та масштабованість
Правильна обробка помилок та винятків
Аналіз дубльованого коду
У середовищі розробників вважається, що рев’ю коду на наявність дублів та перетинів має важливе значення і це підтверджено практикою. Фахівці з огляду коду повинні тримати під контролем код, що дублюється, щоб надалі було простіше вносити необхідні зміни та скоротити технічний борг.
В якості метрики можна використовувати відсоткове співвідношення фрагментів, що дублюються, до загальної кількості рядків коду. Знайти та видалити дубльований код можна за допомогою таких інструментів, як AppRefactoring. Цей сервіс допомагає видалити дубльований код та провести рефакторинг програмного забезпечення.
Висновок
Основна мета код-рев’ю – забезпечити загальну якість та безпеку програмної системи. Рецензування коду колег не повинно бути таким, що лякає або розчаровує. Встановіть стандарти для огляду коду, введіть метрики та використовуйте інструмент автоматизації, щоб допомогти в процесі аналізу вихідного коду для змін та покращень.
Ethereum – блокчейн-платформа для децентралізованих додатків, і друга капіталізація криптовалюта (ETH). У мережі Ethereum працює більшість популярних проектів у сфері DeFi та NFT.
Хто та коли створив Ethereum?
Основним творцем та «обличчям» Ethereum вважають Віталіка Бутеріна. Він народився 1994 року в підмосковному місті Коломна. У віці шести років переїхав із батьками до Канади, де мешкає донині. З дитинства захоплювався програмуванням та інформатикою, в університеті вивчав криптографію.
2011 року Віталік Бутерін став співзасновником одного з перших ЗМІ про криптовалюти — Bitcoin Magazine.
У 2013 році він опублікував whitepaper Ethereum – блокчейна, в якому можна створювати децентралізовані програми, що працюють на смарт-контрактах. Іншими співзасновниками Ethereum стали Гевін Вуд, Чарльз Хоскінсон, Ентоні Ді Іоріо та Джозеф Любін.
Після публікації whitepaper Бутерін отримав грант у розмірі $100 000 від фонду The Thiel Fellowship, створеного підприємцем Пітером Тілем. Ці гроші він використав для проведення ICO. У ході токенсейлу вдалося зібрати 31 550 BTC – близько $18,5 млн на той момент.
Основну мережу Ethereum запустили влітку 2015 року. З моменту заснування і до сьогоднішнього дня за розвиток проекту відповідає Ethereum Foundation — некомерційна організація, зареєстрована у Швейцарії.
Головною відмінністю мережі Ethereum від біткоїну стала підтримка повноцінних смарт-контрактів. Це комп’ютерний алгоритм, який дозволяє проводити операції без участі третьої сторони. Фактично це «цифровий договір» із заздалегідь заданими умовами, які виконуються за певних умов. Це дозволяє перевести бізнес-операції до блокчейну та уникнути «людського фактора». У смарт-контрактів є необмежену кількість сценаріїв застосування.
Віртуальна машина (EVM)
EVM (Ethereum Virtual Machine) – це “розподілений комп’ютер”, що відповідає за виконання смарт-контрактів. Якщо головна функція мережі біткоїну — транзакції між рахунками у розподіленому реєстрі, то EVM може обробляти набагато складніші операції, запрограмовані у смарт-контрактах (які, проте, основою є перекладами між блокчейн-адресами).
Користувальницькі токени
Ethereum дозволила користувачам випускати власні токени. Для таких токенів розробили єдиний стандарт ERC-20. Цінність користувальницьких токенів у наявності користі у межах певного докладання. Ethereum став першим популярним блокчейном для стартапів, які монетизувалися за рахунок власних токенів.
Незамінні токени (NFT)
Також Ethereum набув популярності як блокчейн для NFT за рахунок стандарту ERC-721. Це незамінні токени, в кожний з яких “зашита” унікальна інформація – зображення або якийсь інший файл. NFT є унікальним цифровим предметом в однині, який неможливо відтворити. У 2022 році також почали набирати популярність soulbound-токени.
Що таке криптовалюта ефір (ETH)?
Ефір (ETH) – розмовна назва для нативної криптовалюти Ethereum. Вона необхідна для роботи децентралізованих додатків та оплати комісій за транзакції у цій мережі.
Після активації оновлення The Merge у вересні 2022 року в мережі Ethereum почав працювати стейкінг ефіру: власники ETH можуть заблокувати монети та отримувати з них прибуток. Однак вивести криптовалюту зі стейкінгу можна буде тільки після впровадження в Ethereum шардингу – це має статися протягом 2023 року. Щоб брати участь у стейкінгу ефіру, потрібно запустити свою ноду (для цього знадобиться обладнання та 32 ETH) або використовувати централізований сервіс, наприклад Everstake, Lido або Binance.
ETH — другий з капіталізації цифровий актив на ринку криптовалют. Станом на кінець жовтня 2022 року загальна вартість усіх монет ефіру перевищує $192 млрд. Курс Ethereum зріс у 10 разів менш ніж за два роки: ще в липні 2020 року одна монета коштувала $300, але вже до кінця 2021 року її ціна закріпилася на рівні вищому $3000. Купити Ethereum можна практично на будь-якій біржі криптовалют.
Як злом The DAO вплинув на розвиток Ethereum?
Першою великою кризою для Ethereum став злам The DAO. Це децентралізована автономна організація (ДАО), яка мала намір управляти інвестиційним фондом за допомогою голосувань членів-учасників. Роботу The DAO планували збудувати на смарт-контрактах Ethereum. За підсумками проведеного у 2016 році ICO його засновники залучили кошти у розмірі $150 млн.
У червні 2016 року смарт-контракт проекту, використавши експлойт, зламав хакер і вивів з нього токени The DAO на суму $50 млн. Після цього команда Ethereum провела хардфорк мережі, щоб повернути постраждалим вкрадені кошти. Частина комьюніті, не згодна з цим рішенням, продовжила колишню гілку, назвавши свій проект Ethereum Classic.
Токенсейли з’явилися завдяки Ethereum?
2017 року ринок криптовалют почав різко зростати, про нього заговорили на глобальному рівні. У цифрові активи почали активно вкладатися, зокрема роздрібні інвестори. На цьому тлі з’явилися сотні проектів, які намагалися повторити успіх Ethereum: публікували whitepaper та проводили ICO. Через доступність ERC-20 випустити свій токен міг будь-хто.
Пік активності токенсейлів припав на 1-й квартал 2018 року — загальна сума зборів на них склала близько $7 млрд. Але потім публічні токенсейли практично припинилися: ціни на криптовалюти почали падати, крім того, токенсейли критикували владу різних країн.
У інвесторів впала довіра до ICO, оскільки вони стали популярним інструментом шахраїв.
Поступово з’явилися нові формати токенсейлів: IEO (Initial Exchange Offering) – продаж токенів проекту через спеціальний сервіс на біржі, а також IDO (Initial Decentralized Offering) – залучення інвестицій через фармінг активу.
Як Ethereum призвів до створення DeFi?
Поява сфери децентралізованих фінансів (DeFi) є значною мірою заслугою Ethereum. У 2017-2018 роках на базі цього блокчейну почали працювати кілька знакових проектів, популярність яких призвела до розквіту DeFi:
MakerDAO. Перший популярний протокол, який дозволяє будь-якому користувачеві випустити стейблкоін DAI під заставу різних криптоактивів. Управління протоколом відбувається через ДАТ, голосування якого можуть брати участь власники токена Maker (MKR).
Compound. У цьому проекті вперше застосували пули ліквідності різних криптоактивів. Крім того, Compound провів для своїх користувачів перше в історії IDO, роздавши токен управління COMP через фармінг.
Uniswap— децентралізована біржа для торгівлі криптовалютами, де вперше застосували механізм автоматичного маркетмейкера. Він формує подобу біржової склянки та виробляє метчинг заявок без книги ордерів. Uniswap став першим протоколом із відносно швидкими торговими угодами у блокчейні.
Сьогодні в DeFi працюють сотні проектів з різними функціями, такі як Aave, Curve Finance, 1inch, Balancer, dYdX, Notional та інші. Вони використовують різні технології та блокчейни, але першим був саме Ethereum.
Чи є у Ethereum конкуренти?
Модель блокчейн-платформи виправдала себе і Ethereum став головним криптопроектом поряд із біткоїном. Але основні компоненти Ethereum не змінювали кілька років, а цей час криптоіндустрія пройшла довгий шлях. Продуктивності, на яку розрахована головна блокчейн-платформа, більше не вистачає.
Зараз Ethereum може обробляти не більше 13-15 транзакцій за секунду (TPS), його мережа неодноразово працювала зі збоями та затримками через навантаження, а комісії за переклади стабільно високі.
У той же час, його сучасні «вбивці» мають продуктивність у десятки та сотні разів вищу. Швидкість блокчейну Tezos перевищує 1000 TPS, Polkadot – до 3000 TPS, Solana – до 50 000 TPS.
Кожна блокчейн-платформ пропонує власне рішення масштабованості, тобто здатності збільшувати свою пропускну здатність при зростанні навантаження. Наприклад, Solana використовує імплементацію алгоритму консенсусу Practical Byzantine Fault Tolerance, а Polkadot складається із кількох пов’язаних між собою блокчейнів.
Однак зростання масштабованості має недоліки, описані в трилемі блокчейна. Вона свідчить, що з трьох ключових властивостей – продуктивність, безпека та децентралізація – децентралізована мережа може одночасно забезпечити лише дві. Як і Ethereum, і його конкуренти прагнуть обійти цю теорему, але загальновизнаного рішення поки немає.
Як розвивають Ethereum?
Розробники вигадали кілька способів збільшити пропускну здатність Ethereum і одночасно знизити розмір комісій. Один із таких напрямків — рішення другого рівня (Layer 2).
Це програми та фреймворки, які розгортають поверх основного блокчейну «першого рівня» (Layer 1). Додатковий «шар» дозволяє знизити комісії за перекази та підвищити швидкість транзакцій.
L2-рішення на блокчейні Ethereum реалізують за допомогою технології Rollups, яка дозволяє включити в одну транзакцію першого рівня сотні транзакцій, що проходять через другий рівень. Приклади таких додатків – Arbitrum, Optimism, dYdX, StarkNet.
Інший напрямок – сайдчейни. Це «паралельні» мережі, які пов’язані з основним блокчейном та між якими можна проводити транзакції. Приклад сумісного з Ethereum сайдчейну – Polygon PoS (один з елементів мережі Polygon).
Що таке Ethereum 2.0 (Eth2)?
Ethereum 2.0 (Eth2) — велике оновлення, анонсоване ще в 2017 році та покликане підвищити масштабованість цієї блокчейн-платформи за допомогою глобальних змін її архітектури. На початку 2022 року розробники Ethereum відмовилися від цього терміну.
Апгрейд Ethereum розділений на кілька великих оновлень:
Перехід на алгоритм консенсусу Proof-of-Stake ( успішно відбувся 15 вересня 2022 );
Впровадження технології шардингу: поділ блокчейна на керовані сегменти (шарди) та паралельне виконання операцій у кожному з них;
Нова віртуальна машина eWASM, яка буде підтримувати смарт-контракти, розроблені популярними мовами програмування.
Оновлення запроваджують у кілька етапів, точні терміни виконання всіх його пунктів невідомі. За приблизними оцінками роботи завершать у 2023-2024 роках.
CSS-селектор :has() та міжрядкові інтервали у довгих текстах.
Якщо ви працювали з сайтами, що містять багато довгих текстів, особливо з сайтами на CMS, де користувачі працюють у WYSIWYG-редакторі, то ви напевно писали CSS для управління міжрядковими інтервалами між різними елементами типографіки – заголовками, параграфами, списками і т.д.
Писати такі стилі напрочуд непросто. Саме тому з’явилися інструменти, подібні до плагіну Tailwind Typography і Prose від Stack Overflow, хоча вони працюють далеко не тільки з міжрядковими інтервалами.
Чому з міжрядковими інтервалами між елементами типографіки важко працювати?
Здавалося б, достатньо вказати, що кожен елемент — p, h2, ulі т.д. — має бути певна величина верхнього та/або нижнього зовнішнього відступу (margin), так? На жаль, не все так просто. Припустимо, що потрібно виконати такі вимоги:
Зверху першого та знизу останнього елемента у блоці з довгим текстом не повинно бути ніякого додаткового простору, щоб нетипографські елементи навколо тексту розташовувалися правильно.
Між секціями у довгому тексті має бути великий інтервал. “Секція” тут – це заголовок і весь текст, який до нього відноситься: великий інтервал потрібен перед заголовком, але не тоді , коли перед заголовком знаходиться ще один!
Після h3 знаходиться параграф, а після h2 ще один h3.
Якщо перед h3 знаходиться елемент типографіки, наприклад параграф, потрібен більший інтервал, а якщо йому передує інший заголовок, то інтервал має бути меншим.
Подивимося, де це знадобиться. Пара скріншотів з інтервалами з іншої статті:
h2 прямо над h3.
h3 відразу після параграфа та міжрядковий інтервал.
Традиційне рішення
Як правило, це завдання вирішують, обертаючи довгий вміст div(або в семантичний тег при необхідності). Зазвичай я називаю обгортку .rich-text– це спадщина старих версій Wagtail CMS, які додавали цей клас автоматично при рендерингу WYSIWYG-контенту. Tailwind Typography використовує класс .prose(і ще деякі класи-модифікатори).
Потім додаються CSS для вибору всіх елементів типографіки в цій обгортці та вертикальні зовнішні відступи. Звичайно, при цьому беруться до уваги вищезазначені вимоги для заголовків, розташованих один за одним, і для першого і останнього елементів.
Традиційне рішення має логічний вигляд… але в чому проблема? Мені здається, що проблем тут є кілька.
Жорстка структура
Необхідність додавати клас-обертку начебто .rich-text впровадження особливої структури в HTML-код. У цьому випадку цього не потрібно. Легко забути додати такий клас у потрібне місце, особливо при використанні суміші CMS та контенту, в якому зміни не передбачені.
Структура HTML втрачає гнучкість, якщо слід прибрати верхній і нижній зовнішні відступи у першого і останнього елементів, оскільки вони мають бути прямими нащадками елемента-обгортки, наприклад, важливий селектор .rich-text > *:first-child. >адже з його допомогою ми випадково вибираємо перший елемент у кожному ulабо ol.
Використання різних сторін зовнішніх відступів
До появи :has() був способу вибрати елемент залежно від наступного елемента. Отже, традиційний підхід до створення міжрядкових інтервалів друкарських елементів – використовувати і margin-top, і margin-bottom:
Спочатку з margin-bottomвизначаємо розмір міжрядкового інтервалу за умовчанням.
Потім, за допомогою суміжного селектора (наприклад, h2 + h3), створюємо міжрядковий інтервал для секцій через margin-top– наприклад, великий інтервал перед кожним заголовком.
Перезаписуємо ці великі інтервали у разі, коли за заголовком відразу слідує ще один.
Не знаю, як вам, а мені завжди здавалося, що при визначенні міжрядкових інтервалів краще використовувати тільки одну сторону відступу, як правило, margin-bottom(припускаючи, що в даному випадку CSS-свойство gapне застосовується. Чи варто так працювати, я залишаю на ваш розсуд. Але для установки міжрядкових інтервалів довгого контенту я віддаю перевагу margin-bottom.
Схлопування зовнішніх відступів
Через схлопування зовнішніх відступів одночасне застосування margin-bottom і margin-topсаме собою не проблема. З двох розташованих один над одним зовнішніх відступів видно буде лише більший, а чи не сума значень відступів. Але мені не подобаються зовнішні відступи, що схлопуються. Їх також варто взяти до уваги.
Схлопування відступів може заплутати розробників-початківців, які не знають про цю особливість CSS. Міжрядкові інтервали зміняться (наприклад, припинять схлопуватися), якщо надати обгортці, скажімо, якість flex з flex-direction: column. Цього не станеться, якщо використовувати лише одну сторону відступу під час завдання вертикальних зовнішніх відступів.
Я більш-менш розумію, як працює схлопування зовнішніх відступів, і усвідомлюю, що так зроблено спеціально. Іноді воно допомагає, але іноді ні. Мені здається, що схлопування – дивна штука, і, як правило, я намагаюся уникати його.
Моє рішення не враховує всіх існуючих елементів типографіки . Наприклад, у моїй демоверсії немає підтримки <blockquote>. Але перелік селекторів просто розширити.
Моє рішення не працює з нетипографськими елементами , які можуть бути присутніми у певних блоках з довгим текстом, наприклад <img>. Справа в тому, що я працюю з сайтами, де WYSIWYG-редактори максимально обмежені основними текстовими елементами, такими як заголовки, параграфи та списки. Інші елементи (цитати, картинки, таблиці тощо) перебувають у окремому компонентному блоці CMS. Ці блоки під час рендерингу на сторінці розділені інтервалами. Але, повторюю, список селекторів легко доповнюється.
Я ввімкнув h1 тільки для повноти картини . Зазвичай я не дозволяю використання h1у WYSIWYG-редакторі: так заголовок сторінки виявляється десь у макеті, а змінювати його потрібно за допомогою CMS-редактора сторінки.
Я не передбачив ситуацію, коли за одним заголовком відразу слідує інший той самий рівень ( h2 + h2) . Це означало б, що перший заголовок не має контенту, що схоже на неправильне застосування заголовків (і виправте мене, якщо я помиляюся, але це може порушувати принципи посібника з доступності веб-вмісту WCAG 1.3.1 Info and Relationships) . Я також не передбачив пропуску рівнів заголовків.
Я жодним чином не зменшую переваги раніше згаданих мною підходів . Коли я створюю сайт за допомогою Tailwind, то, звичайно, використовую чудовий плагін Typography.
Я не дизайнер . Я поставив міжрядкові інтервали на око. Вам слід використовувати більш відповідні значення.
Висновок
У вас на руках ультрасучасне рішення дуже занудного завдання! Цей новий підхід я не назвав би «простим». Як я вже говорив на початку статті, але це завдання складніше, ніж може здатися на перший погляд. Але, крім наявності кількох нескладних селекторів, мені здається, що такий підхід набагато логічніше, а менш жорстка структура HTML дуже приваблива.
Аппчейн (application-specific blockchain, appchain) – блокчейн, призначений виключно для роботи однієї конкретної програми.
Використання подібних рішень надає розробникам більшої свободи при формуванні екосистем, структур управління та алгоритмів консенсусу для створюваних ними децентралізованих додатків.
Як працюють апчейни?
Аппчейни працюють приблизно так само, як і базовий блокчейн, але поверх останнього. Головна відмінність у тому, що вони app-specific.
У контексті безпеки аппчейни спираються на блокчейни першого рівня (L1). Такі системи добре кастомізуються і мають значний потенціал продуктивності, оскільки не конкурують з L1-додатками за обчислювальну потужність і простір для зберігання даних.
У подібних рішень, зазвичай, є utility-токен. Він використовується для стейкінгу, як внутрішній валюти програми, а також для голосувань.
Роботу аппчейнов підтримують валідатори з основної мережі (якщо ті згодні спрямовувати ресурси на конкретний додаток).
Які переваги у аппчейнів?
Використання нового підходу при створенні додатків має ряд переваг у порівнянні з L1, рішеннями другого рівня (L2) та сайдчейнами . Як вже говорилося, аппчейни привносять кастомізованість і збільшують продуктивність систем, не жертвуючи безпекою, оскільки спираються на базовий блокчейн.
Безпосереднє використання L1 під час створення dapps передбачає конкуренцію з іншими додатками за обмежені обчислювальні ресурси. Це загрожує ймовірним зниженням продуктивності та тривалим процесом оновлення платформ, оскільки розробники не контролюють протокол консенсусу.
Через суперництво між dapps на базі однієї мережі можлива ситуація, коли лише один популярний додаток використовує непомірно великий обсяг ресурсів. Це призводить до збільшення комісій (як, наприклад, на тлі запуску XEN Crypto) і затримок при обробці транзакцій.
Аппчейны припускають низькі і передбачувані витрати під час проведення операцій, що благотворно позначається користувальницькому досвіді.
По мірі зростання популярності децентралізованих додатків розробники можуть зіткнутися з необхідністю розширеної кастомізації та оптимізації різних параметрів, включаючи пропускну спроможність, фіналізацію, рівень безпеки та ступінь доступності ( permissionless або permissioned ).
Для традиційних організацій аппчейни надають можливість зануритися в Web3, не роблячи платформи загальнодоступними з першого дня. Наприклад, компанії можуть спочатку вимагати від валідаторів дотримання KYC, покладатися на обмежене коло розробників і вибирати конкретні послуги для кроссчейн- взаємодії.
Які недоліки у аппчейнів?
Основна відмінність і, можливо, обмеження аппечейнів полягає в тому, що вони «заточені» під одну конкретну програму. L2-рішення, навпаки, здатні взаємодіяти з різними dapps.
Аппчейны припускають обмежену компонованість і деякий ступінь ізоляції, що може призвести до фрагментації ліквідності. Проблема багато в чому вирішується за рахунок інтеграції кроссчейн-мостів, проте останні часто є мішенню для хакерів.
Якщо програма використовується недостатньо активно, то запуск і підтримка аппчейна можуть виявитися марною тратою часу та коштів. Виділені для платформи валідатори можуть ефективно використовувати ресурси в будь-якому іншому місці.
Робота аппчейна може бути поєднана з різними складнощами. Наприклад, пов’язані з керуванням додатковими інфраструктурними елементами на кшталт секвенсорів або валідаторів.
У розпорядженні розробників може і не бути готових рішень із коробки — оглядачів блоків, RPC-провайдерів, індексаторів, оракулів, фіатних шлюзів і т.д.
У створенні L1-рішень є свої плюси – наприклад, доступність величезного обсягу ресурсів, інфраструктурних елементів, інструментів для розробників (особливо початківців). Такий достаток може спрощувати інтеграцію з різними екосистемами.
Завдяки L2 розробники можуть підвищувати масштабування сервісів без необхідності внесення значних змін до кодової бази.
Рішення другого рівня також передбачають високий рівень безпеки, оскільки спираються на основний блокчейн. Наприклад, Optimism і Arbitrum швидко обробляють транзакції, а основну мережу відправляють «докази шахрайства» (fraud proofs) завдяки технології Optimistic rollups.
Чим аппчейни відрізняються від сайдчейнів?
Сайдчейни припускають роботу паралельної мережі з двосторонньою прив’язкою до основної, але такі рішення не покладаються на безпеку L1. Від L2 сайдчейни відрізняються тим, що не відправляють транзакції в основний блокчейн.
Аппчейни створюються під конкретну програму (app-specific). Сайдчейни виконують операції будь-якого роду. Їхній основний недолік — знижена безпека через обмежену децентралізацію.
Один з найвідоміших сайдчейнів – Polygon Proof of Stake, що входить до екосистеми проекту Polygon. Останній включає також Polygon Edge – середовище розробки з відкритим вихідним кодом, що дозволяє створювати L2-рішення.
Які проекти мають аппчейни?
Деякі блокчейн-проекти надають розробникам можливість створювати аппчейни. Серед них:
парачейни Polkadot;
Cosmos Zones;
підмережі Avalanche (subnets);
Polygon Supernets
Парачайни Polkadot
Polkadot є мережею EVM-сумісних блокчейнів – парачейнів, з’єднаних із центральною мережею (Relay Chain). Остання спеціалізується на валідації транзакцій усіх пов’язаних із нею систем.
У Relay Chain задіяний механізм консенсусу Proof-of-Stake, де валідатори стейкують DOT (нативний токен Polkadot).
Кожна група валідаторів відповідальна за конкретний парачейн, призначається та підтримується колаторами: вони збирають транзакції користувачів та підтверджують блоки на основі алгоритму Proof-of-Validity (доказ валідності). За свою роботу як ноди колатори отримують нагороду, розмір якої залежить від конкретного парачейна.
Кількість слотів під парачейни в мережі Polkadot обмежена 100. Вони розподіляються за допомогою аукціонів, в ході яких власники DOT голосують за проекти для подальшого їх підключення до Relay Chain.
«Парачейн-слоти можна отримати лише на певний період тривалістю до двох років. Після закінчення цього терміну слот повертається на аукціон», – пояснюється на сайті проекту .
Парачейни можуть також служити мостами, що з’єднують мережу Polkadot із зовнішніми L1-блокчейнами на зразок Ethereum.
Такі рішення надають розробниками всі вищеописані можливості аппчейнов, включаючи свободу вибору економічної чи управлінської структури, дозволяючи використовувати токени.
Один із головних недоліків парачейнів полягає в обмеженій кількості слотів, які можна виграти в ході аукціону. Це робить подібні рішення менш доступними.
Команда Polkadot працює над паратредами – парачейнами з оплатою за фактом використання. Рішення дозволить розробникам не чекаючи на аукціон парачейнів, завантажити код проекту в Relay Chain і запустити кілька колаторів. Надалі паратреди можна буде оновлювати до парачейнів у разі участі та перемоги в аукціонах.
Кількість паратредів, що підтримуються Polkadot, також обмежена — до 10 000.
Інший недолік екосистеми у тому, що Relay Chain не підтримує смарт-контракти. Це обмежує можливості мережі Polkadot.
Приклади парачейн-проектів:
Acala – DeFi-хаб для мережі Polkadot;
Litentry – кроссчейн-агрегатор рішень для ідентифікації.