Час іде, технології розвиваються, а проблеми, пов’язані з використанням API, викликають у багатьох розробників ті самі складності, що й десятки років тому. Тим часом, зростання числа сервісів, які взаємодіють один з одним за допомогою даного способу, з кожним днем тільки збільшується, і невміння надійно, якісно і безпечно працювати з API може призвести до небезпечних збоїв або поломки системи, що розробляється.
Працюючи над проектами з використанням API передбачити всі проблеми заздалегідь просто неможливо. І це стосується не тільки веб-розробки: подібні складності (як і способи їх вирішення) схожі в системах різного типу. А оскільки з розвитком технологій взаємодія між різними сервісами через API з кожним днем все більш затребувана, то і вміння правильно вибудувати роботу з АПІ стає для кожного розробника ключовим. Для підтвердження цього факту не потрібно ходити далеко за прикладами: так, з великими мовними моделями, на зразок OpenAI GPT-3.5 або GPT-4, щодня взаємодіють тисячі сервісів, і ця взаємодія відбувається саме за API. Про величезний інтерес інтеграції з боку розробників можна судити, наприклад, за кількістю зірок на гітхабі OpenAI Сookbook (понад 53000).
Ще трохи статистики: більшість сучасних API є HTTP API (такими як REST і GraphQL), і за результатами дослідження Postman “2023 State of the API Report“, REST (і його підвиди) залишається найпопулярнішою архітектурою – її використовують 86% респондентів. З цієї причини в статті я більше зосереджуся на проблемах, пов’язаних швидше з REST, хоча багато згаданих мною рішень можуть бути актуальними і для інших підходів.
Отже, ви тільки розпочали розробку свого веб, десктоп, мобільного або ще якогось додатку, який повинен отримувати інформацію із зовнішнього джерела за допомогою API. На перший погляд, завдання може здатися нескладним: швидше за все, ви вже маєте хорошу або не дуже документацію по взаємодії зі стороннім сервісом і прикладами його інтеграції. Усього тільки і потрібно, що просто написати код, який буде надсилати запити з вашої програми, чи не так? На жаль немає…. Адже насправді все набагато складніше, ніж у теорії. Вас може очікувати безліч труднощів, починаючи від проблем із продуктивністю зовнішньої системи та закінчуючи питаннями безпеки. Кожна з них по-своєму підриває стабільність вашої розробки: іноді ризики маленькі, і їх можна знехтувати для швидкості створення проекту. Але часто проблеми наростають як снігова куля. Саме тому не варто недооцінювати їхню складність, щоб завжди бути готовим до різних перешкод на шляху до успішної інтеграції із зовнішнім API.
Проблеми вирішуються легше, якщо заздалегідь підготувати стратегію з їхньої опрацюванню: дотримуючись наведених нижче правил, можна мінімізувати вплив сторонніх сервісів на стабільність проекту, який ви створюєте.
Почнемо розбір із однією з найчастіших помилок, яку іноді припускають навіть найдосвідченіші розробники систем, що взаємодіють з API сторонніх сервісів. Це некоректна обробка випадків, коли запитуваний ресурс поламаний або зовсім недоступний.
Навіть у великих сервісів, таких як GitHub, можуть відбуватися збої, які впливають на роботу залежних від них програм. А, наприклад, статистика щодо інцидентів і uptime для Discord показує, що доступність їх API далеко не завжди становить 100%: раз на кілька місяців відбуваються будь-які проблеми. Це означає, що сервіси, що використовують API Discord у своїх додатках, схильні до ризиків, і можуть також ламатися, якщо заздалегідь не передбачити і не реалізувати систему обробки помилок.
Але якщо навіть такі відомі сервіси іноді ламаються, що тоді говорити про менш популярні?
Розберемося з тим, як можна вирішувати проблеми, пов’язані з доступністю ресурсів. Звичайно, підходи можуть дещо відрізнятися в залежності від того, для якої мети ви здійснюєте API-запити.
Для обробки помилок при оновленні даних на сторонньому сервісі список варіантів рішення буде таким:
Для кейсів, де ви запитуєте дані через API, способи та підходи рішення трохи інші, але є й загальні пункти:
Крім перерахованого, для всіх випадків роботи з API важливо проводити налаштування connection timeout та request timeout запитів . Це допоможе уникнути надмірного навантаження на вашу систему, запобігаючи ситуації, коли запити виконуються надто довго.
Визначаємо connection timeout та request timeout за допомогою curl
Вибір значення таймууту – завдання непросте, і залежить від великої кількості факторів. Connection timeout зазвичай виставляється менше ніж request timeout, тому що процес встановлення з’єднання зазвичай займає менше часу, ніж обробка цього запиту сервером. Хоча, звичайно, все залежить від того, де розташовані сервери провайдера API. Щоб підібрати відповідні значення, розумним рішенням буде спочатку зібрати статистику роботи даного API в shadow mode. Такі дані легко отримати через curl за допомогою опції –write-out:
curl -o /dev/null -s -w "Time to connect: %{time_connect}\nTime to start transfer: %{time_starttransfer}\n" https://google.com
У libcurl цю інформацію можна отримати через метод curl_easy_getinfo , де необхідні дані будуть повернуті до CURLINFO_CONNECT_TIME та CURLINFO_STARTTRANSFER_TIME .
Після збору необхідних метрик, використовуючи статистичні дані, ви зможете визначити поріг допустимих таймаутів для роботи з API.
Ще однією корисною дією буде додавання систем моніторингу та оповіщень . Якщо сторонній сервіс перестав відповідати, ви повинні дізнаватись про це миттєво. А якщо API починає видавати занадто велику кількість помилок, необхідно передбачити систему, яка автоматично знизить потік запитів, що надсилаються в момент часу.
Тепер, коли ми вирішили проблеми, пов’язані з недоступністю АПІ, слід подумати, як боротися з лімітами на кількість запитів. Це питання теж дуже актуальне і може спливти в невідповідний момент. Більше того, провайдер API може ці ліміти зовсім несподівано змінити, тому життєво важливо передбачити подібну ситуацію заздалегідь, щоб вирішити всі труднощі максимально швидко.
Частина прописаних вище порад підійде і тут. Наприклад, кешування відповідей може врятувати вас від необхідності надто частого відправлення API-запитів, оскільки ймовірність перевищення лімітів тоді буде помітно нижчою.
Додаткова інформація про кеш в HTTP
Зазначу, що в HTTP API є безліч зручних механізмів роботи з часом життя кешу by design.
Наприклад, для отримання часу життя кешу можна використовувати заголовок Expires .
Cache-Control може використовуватись для встановлення інструкцій кешування.
ETag є ідентифікатором версії ресурсу. Якщо ресурс буде змінено, ETag також зміниться.
А Last-Modified показує, коли запитуваний ресурс був змінений востаннє. Але за наявності ETag, краще орієнтуватися саме на нього, оскільки він вважається надійнішим: Last-Modified має обмеження у вигляді одиниці часу (зазвичай за секунди), що може не відображати дрібні зміни. Крім цього, ETag буде точнішим у випадку, якщо ресурс був змінений, але його вміст залишився незмінним.
При цьому всі перераховані вище заголовки можна отримати за запитом типу HEAD . Він, зазвичай, не обмежується показником рейт ліміту чи обмежується значно більшим лімітом, ніж інші типи запитів.
Як і у випадку обробки ситуацій при недоступності API, крім реалізації кешування, ефективно використовувати чергу запитів і механізм для повторного відправлення запиту (можливо з реалізацією diff-логіки). Цей підхід можна назвати «золотим стандартом» для сценаріїв, коли не завжди можна отримати відповідь від стороннього сервісу миттєво. Керування чергами запитів допомагає забезпечити безперервну роботу програми, навіть якщо сторонній API тимчасово збоїть. Але є й додаткові рекомендації для запобігання проблемам з rate-limiting:
До речі, використовуючи перелічені вище поради, ви не тільки зменшуєте ймовірність помилок, але й економите бюджет, якщо доступ до API – платний. Отже, це саме той випадок, коли можна вбити одразу двох зайців та заощадити патрони.
Сторонній АНІ може повернути буквально все, що завгодно. Виправлення: а може і не повернути те, що ви хотіли від нього отримати. Адже не всі мають хороші методи для версіонування, а іноді їх і немає зовсім. Тож часом навіть один і той же запит може сьогодні повертати одне, а завтра – зовсім інше. Мораль: не забувати про такий варіант розвитку подій і ніколи не покладатися повністю на сторонніх розробників.
До речі, проблема не завжди пов’язана із зміною версій. Бувають випадки, коли після блокування ресурсу інтернет-провайдери замість якогось JSON-а починають повертати HTML з інформацією про блокування. Або, наприклад, сервіси захисту від DDoS можуть замінювати контент, також повертаючи HTML з капчею для перевірки користувача. Так, другий кейс можуть передбачити творці API, але на практиці таке відбувається далеко не завжди. Ось що допоможе в цій ситуації:
Ось про що, а про безпеку користувачі API думають не так часто. А дарма, адже зловмисникам це добре відомо. Досвідчені зломщики можуть скористатися вашою неуважністю і хакнути розроблювану вами систему, і для цього у них приготовлена маса способів.
Розробник, що реалізує взаємодію зі стороннім API, завжди повинен пам’ятати такі правила:
У цій статті я спробував висвітлити проблеми API, що найчастіше зустрічаються, і методи їх вирішення. Головне, що повинен пам’ятати кожен: під час роботи зі сторонніми API не варто вірити в їхню абсолютну надійність. Проблеми можуть виникнути там, де ви на них найменше очікуєте, тому вкрай важливо ретельно продумувати архітектуру та стратегії обробки помилок у ваших додатках заздалегідь, щоб максимально зменшити потенційні ризики та забезпечити стійкість роботи вашого сервісу в майбутньому.
З квантовими комп’ютерами вже не перший рік пов’язують безліч надій і водночас побоювань. На думку оптимістів, вони дадуть новий ривок у сфері обчислювальних технологій і зможуть вирішувати найскладніші завдання, з якими не справляються найпотужніші машини, що нині існують. Песимісти вважають, що пересічним користувачам всі ці кубити в «люстрах» не принесуть нічого, крім нових викликів у галузі криптографії та захисту персональних даних. Про те, як влаштовані квантові комп’ютери, які вже існують до початку 2024 року, і наскільки виправдані страхи перед ними, для читачів ForkLog розповідає Сергій Голубенко.
1965 року американський інженер Гордон Мур вивів закономірність: кількість транзисторів на мікросхемах подвоюється приблизно кожні два роки. Це спостереження згодом підтвердилося — потужність обчислювальних пристроїв досі стабільно зростає за експонентом.
Однак у 2007 році сам Мур припустив, що виявлена ним закономірність скоро перестане працювати – такі закони фізики. Найбільш перспективним виходом із цього глухого кута вже не перший рік називаю квантові обчислювальні системи (КВС), про які ми сьогодні розповімо.
Їх найважливіша відмінність від звичайних комп’ютерів полягає у способі зберігання та обробки інформації. Традиційні машини, побудовані з урахуванням кремнієвих мікросхем, містять мільйони транзисторів. Виконуючи роль мініатюрних «рубильників», кожен із них може бути або у положенні «включено» («1»), або «вимкнено» («0»). Згодом комп’ютер зберігає та обробляє дані, використовуючи двійкову систему (код) та оперуючи бітами даних.
КВС оперують кубитами (квантовими бітами) і можуть бути побудовані різними способами через надпровідні електричні ланцюги або за рахунок окремих іонів, захопленими магнітними пастками.
Для розуміння цього процесу потрібно вийти за рамки звичного сприйняття світу і перенестися у сферу квантового простору, де більший потенціал мають кубити, які мають здатність перебувати одночасно в кількох станах. Це явище називається суперпозицією. Квантовий стан дозволяє кубіту набувати значення не тільки одиниці або нуля, але й будь-якого між ними, а також обидва значення одночасно – зовсім як у уявному експерименті “Кіт Шредінгера“.
І найцікавіше: пригоди ймовірностей значень миттєво припиняються, щойно втручається спостерігач, якому потрібний лише результат «так» чи «ні». Цей дослідник, оператор квантового комп’ютера, з допомогою спеціального алгоритму отримує лише відповідь «1» чи «0». Перебування кубіту в суперпозиції дозволяє КВП паралельно обробляти значно більший обсяг даних, ніж класичний комп’ютер.
Створити один кубит і керувати ним лише частина завдання. Крім суперпозиції, кубити також відчувають «Сплутані квантові стани» – ще одна ключова квантовомеханічна властивість, при якій стан одного кубіту може залежати від іншого. Простіше кажучи, якщо «заплутати» два кубити і відправити один із них, наприклад, на відстань у кілька десятків кілометрів, використовуючи оптоволокно, то вони збережуть зв’язок і знатимуть один про одного все. Це відкриває неймовірні можливості у транспортуванні інформації з урахуванням квантового шифрування. Але ця технологія має слабкі місця: частки мають звичай губитися дорогою, і тому не всі з них приходять до фінішу.
Частинки, що виступають у ролі кубитів, вкрай сприйнятливі до випадкових збуджень – найменших теплових ефектів або електромагнітного поля сусіднього об’єкта. Через це квантовий комп’ютер видає правильну відповідь поки що лише з ймовірністю 98-99%. Для підтримки стабільної роботи кожну пару кубитів поміщають у холодний вакуум, де крім них немає нічого. Виникають питання: як організувати зберігання кубіту і які частинки можуть виступати у ролі?
Розглянемо на прикладі комп’ютера, який використовує як кубіти частинки іонів, наділені квантовою природою. Завдання: надати відповідній природній частинці (у нашому випадку іону) значення «1» або «0», яке він приймає відповідно на північ або південніше від екватора сфери Блоха. Це дозволяє створити «крани», якими можна керувати (змінювати значення ймовірностей усередині частки), використовуючи низькорівневе програмування. А для захоплення такої пари іонів та їх утримання у тісній заплутаності існує спеціальна пастка з електромагнітних полів. В результаті маємо заплутану пару іонів, якою можна керувати, помістивши у холодний вакуум.
У квантових обчисленнях використовують такі технології:
Далі слід розібратися в принципах роботи квантових комп’ютерів та показати їхню відмінність від класичних.
Квантовий комп’ютер — це об’єднана аналого-цифрова система, яка працює за принципом «безліч значень ймовірностей» і дозволяє за допомогою заданого алгоритму отримати вибірку з кінцевих реалізацій цього алгоритму. Класичний комп’ютер — це цифрова машина, що обробляє інформацію в дискретній формі як рядок з одиниць і нулів.
Тут виникає ще одне закономірне питання: як отримані аналогові дані перевести у звичну цифрову форму? Використовуючи системи перетворення сигналу, вчені зробили низькорівневе програмування частинок. І в цій галузі тепер вирує серйозна робота: треба зробити так, щоб програміст писав високорівневий код, не маючи додаткових поглиблених знань у фізиці та хімії.
Ще одна актуальна проблема полягає в тому, що квантові комп’ютери на даному етапі мають масивну конструкцію і можуть розміщуватись тільки у великих приміщеннях. Форма «люстри», яку для цих цілей використовують у надпровідникових технологіях IBM та Google, вважається найзручнішою. Ця конструкція складається з безлічі мідних проводів, які поєднують усі частини комп’ютера: підсилювачі сигналу кубитів, надпровідні котушки, квантовий процесор, різні засоби захисту від радіації та електромагнітних хвиль. Причому це все в умовах вакууму. Якщо лабораторія використовує інші технології кубітів, форми конструкцій таких комп’ютерів можуть відрізнятися і навіть нагадувати класичний серверний блок.
Особливі властивості кубитів (надпровідність, надплинність і т. д.) починають проявлятися тільки при температурі, близькій доабсолютному нулю. Для охолодження квантового процесора доводиться використовувати установки з гелієм чи азотом.
Наскільки ж виправданий такий клопіт?
Якщо провести порівняння потенційних обчислювальних потужностей, то в класичному комп’ютері вони пов’язані з кількістю бітів: додавання одного транзистора збільшує пам’ять на 1 біт). У квантовому додавання одного кубіта збільшує пам’ять відразу в два рази. Як ми вже говорили, 1 кубит має всього два стани («0» або «1»), а завдяки заплутаності 10 кубітів мають уже 1024 стани; ну а сотня кубітів має 2 в 100 ступеня станів.
Очевидно, тут є що боротися. Але основне завдання — зберегти належний рівень якості заплутаності нових пар кубітів, оскільки просте зростання їх числа не призведе до підвищення продуктивності комп’ютера і не дасть квантової переваги.
В даний час найбільших успіхів у галузі створення КВС досягли наступні корпорації, державні дослідні центри та молоді незалежні проекти.
IBM
Парк квантових комп’ютерів цієї корпорації вже налічує понад 20 машин, доступ до яких організовано через хмарний сервіс IBM Quantum Experience. У грудні 2023 року Quantum Summit представили перший модульний квантовий комп’ютер IBM Quantum System Two. Він базується на 133-кубітному процесорі Heron, який представники компанії називають найпродуктивнішим у світі. IBM також анонсувала процесор Condor з 1121 кубитом та на 50% більшою щільністю їх розміщення.
У 2019 році співробітники техгіганту заявили про досягнення квантової переваги завдяки 53-кубітному комп’ютеру Sycamore на надпровідниках (щоправда, досягнення було оскаржене IBM). Тест, на думку критиків, був скоріше «показовим виступом» у рамках квантових перегонів. З того часу дослідники змогли додати до показників Sycamore ще 17 кубітів. Тепер він виконує за кілька секунд обчислення, на повторення яких сучасний суперкомп’ютер витратив би 47 років.
У Google, як і IBM, пішли перевіреним шляхом використання класичних мікросхем, впроваджуючи кубити через надпровідники.
Xanadu
Ця канадська компанія навесні 2022 року оголосила про запуск нового квантового комп’ютера Borealis, розгорнувши його в хмарі і надавши загальний доступ. Комп’ютер оснащений 216 фотонними кубитами. Як пише Nature, система успішно подолала бар’єр квантової переваги, закладений алгоритмом. І якщо найпотужнішому сучасному суперкомп’ютеру на виконання цієї операції знадобилося б приблизно 9000 років, Borealis впорався лише за 36 мікросекунд.
Atom Computing
Ця компанія з Каліфорнії створила перший у світі квантовий комп’ютер із 1180 кубитами, використовуючи нейтральні атоми, захоплені лазерами у двомірну сітку. Як результат, у комп’ютері Atom Computing квантові біти здатні працювати без помилок майже хвилину, тоді як аналогічний показник у комп’ютері від IBM становив лише 70-80 мікросекунд.
Науково-технічний університет Китаю
У грудні грудня 2020 року китайські вчені повідомили, що їх комп’ютер Jiuzhang, який працює на заплутаних фотонах, досяг квантової переваги. За 200 секунд вони успішно провели обчислення, які найшвидший у світі цифровий комп’ютер виконав би лише за півмільярда років.
Існує думка, що квантові комп’ютери в найближчому майбутньому зможуть зламувати блокчейни і, наприклад, знищити біткоін. Ці тривоги небезпідставні, але важливо пам’ятати про два нюанси.
По-перше, загроза більше відноситься до PoW -блокчейн, де під загрозу потрапляє дешифрування хешу. По-друге, шифрування RSA (найпоширеніша альтернатива криптографії еліптичних кривих) може бути квантово-стійким. Хоча коли йдеться про традиційне дешифрування, прийнято вважати навпаки.
Якщо міркувати глобально, багато залежатиме від того, наскільки швидко криптографи у відповідь на потенційні виклики вирішать проблему захисту від квантового злому.
У криптосфері вже є приклади компаній, які заявили про свою повну квантову стійкість: Quantum Resistant Ledger зі своєю криптовалютою QRL, а також технологія розподілу ключів QKD від JPMorgan – для захисту блокчейну від квантових обчислень. Для реалізації квантової стійкості QRL використовує IETF XMSS – схему прямого безпечного підпису на основі хешу з мінімальними припущеннями про безпеку, де XMSS – розширена схема підпису Меркла.
Рух у бік модульних блокчейнів також видається позитивним. Завдяки своїй структурі вони супроводжують простіше впровадження квантових підписів і в майбутньому вирішать проблему розподілу операторів нід для посилення децентралізації та захисту розподілених реєстрів.
Резюмуючи, можна сказати, що об’єднання зусиль блокчейну та квантових обчислень допоможе створити більш безпечні та потенційно революційні обчислювальні рішення, які зрештою дозволять вирішити цілу низку криптографічних та життєвих проблем.
Чи побачимо ми квантовий хардфорк біткоїну чи світовий квантовий інтернет — думаємо, питання часу.
Щоб усім було зручно його писати, обговорювати та рефакторити — без розпухлого беклогу та обличчя девопса.
Мені здається, що якщо запитати 10 випадкових розробників про те, як у них у командах влаштовано роботу над кодом, то в 9 випадків відповідь буде «Ну, як доведеться. Як звикли!».
Це дивно для галузі, в якій є справжній культ менеджерських практик: з них пишуть книги, проводять конференції, їм навчають. Але рідко коли навчають практик хорошої роботи над кодом! У крайньому випадку в команді знайдеться досвідчений лід або людина з хорошим системним мисленням, яка при цьому готова допомогти колегам стати краще.
Нагадаю вам базові правила, з яких потрібно розпочинати роботу в цьому напрямку. Побуду вашим системним лідом на півгодини, так би мовити!
Стандарти роботи над кодом та принципи його оформлення мають бути легко доступними для кожного учасника команди. Корисно провести невеликий семінар усередині та розібрати, які стандарти бувають.
Якщо ми говоримо про JS, то приклад відмінно оформленого та вичерпного стандарту можна підглянути у Google. Також непогано розроблений стандарт Airbnb.
Доступні всім стандарти полегшують виявлення проблем з якістю коду і дуже допомагають під час код-рев’ю.
Але не перестарайтеся з посібниками! Достатньо встановити суворі правила іменування, інтервалів та відступів, щоб покращити читабельність. Не потрібно регулювати кожен рядок коду. Завжди і скрізь більше правил — це менше швидкості розробки.
Код-рев’ю – це не тільки спосіб виправити помилки і зробити код кращим, це ще й можливість отримати знання про різні області вашої кодової бази. І спосіб поповнювати та покращувати стандарти, само собою.
Багато інженерних команд використовують принцип DoD (Definition of Done) – такий контрольний список виконаного перед тим, як код можна віддавати в продакшен.
Наприклад:
Ось кілька інструментів, які допоможуть у ревію:
Якщо у вас в команді немає регулярного код-рев’ю, то вам буде дуже важко писати код, що масштабується, ефективний і підтримується.
Наше завдання – не давати технологу розростатися.
Раджу виділити приблизно 20% ресурсів у кожному спринті на виправлення технічного боргу. Крім того, регулярно проводьте спринт, присвячений усуненню технічного обов’язку – цілком.
Ну, а взагалі є різні стратегії роботи з техборгом, це гідно окремої статті. Наприклад, є стратегія «контрольованої розширюваності» за рахунок низькопріоритетних іш’ю.
У компаніях часто сегментують помилки та звернення користувачів за пріоритетами, щоб насамперед лагодити найважливіше. Але з кодом це зробити складніше.
Наприклад, у JIRA не можна пов’язати проблеми користувачів з кодом та ефективно працювати з технічним боргом. Можна підключити зовнішній трекер, наприклад Stepsize – він дозволяє керувати проблемами прямо із середовища розробки.
У деяких командах прийнято стежити за метриками коду. Є навіть ціла академічна стаття про те, як вони влаштовані.
Наприклад, корисно вважати кількість коментів на 1000 рядків коду – це дасть загальне уявлення про складність. Якщо послідовно стежити за метрикою, можна побачити зміну складності, що буває корисно для техліда або техдира.
Також є поняття зв’язності коду (Code Cohesion). Цією метрикою вимірюють наскільки добре структурована та організована кодова база. Це не дивно, адже високоорганізовану кодову базу легше розуміти, підтримувати та покращувати.
Ніщо не покращує код краще за постійного внутрішнього обговорення, такого колективного код-рев’ю. Я раджу проводити їх не рідше 1 разу на місяць. У деяких командах це називають «прожаркою».
Попросіть кожного зібрати по кілька прикладів (доброго та поганого), зберіться у неформальній обстановці, можна з пивом та піцою (краще без ананасів). Описані стандарти, дружня атмосфера та терпимість до помилок – це найкраще, що ви зможете зробити для коду, колег та компанії.
WAAP (Web Application and API Protection) є брандмауером веб-застосунків наступного покоління WAF (Web Application Firewall). Термін вперше почав використовувати Gartner для опису захисту сучасних, постійно змінних веб-сервісів. Так як у світі CI/CD, динаміки та API перших компаній, функцій традиційного WAF (Web Application Firewall) вже недостатньо.
Термін “WAAP” більш точно відповідає тому, як змінився ринок. Клієнти стали вимагати і чекати додаткових засобів захисту для боротьби з ландшафтом загроз , що швидко зростає і розвивається , який частіше включає вплив на інтерфейс програмування додатків (API), використання засобів автоматизації (ботів) для організації атак і розподіленої відмови в обслуговуванні (DDoS-атаки) ). Це також відображає тенденцію до консолідації функціональності, оскільки організації прагнуть більшої операційної та фінансової ефективності.
Багато компаній, які вже мають веб-додатки, що приносять дохід, запускають програму «API-First». Тепер старі монолітні програми розбиваються на мікросервіси, розроблені в еластичній та гнучкій архітектурі сервісної мережі.
API-First – це підхід до розробки серверних програм, при якому API є найважливішою частиною продукту. При застосуванні такого підходу API вашого продукту має власний цикл розробки, відповідно створюється його артефакт. Очевидно, що у вашому сервісі є залежність від артефакту API, чим забезпечується актуальність специфікації в цьому артефакті. Як видно, необхідно спочатку розробити API, а потім працювати над реалізацією цього API у вашому сервісі. Зазначена черговість розробки є необхідністю прихильності до підходу API‑First, але не визначення самого підходу. First у найменуванні означає, що API – це перший за важливістю продукт. У тому числі і з погляду захисту.
Загальне питання, з яким стикаються більшість організацій: як підвищити безпеку веб-додатків, у тому числі API?
Захист API від сучасних кіберзагроз потребує виходу за рамки традиційних рішень. На допомогу приходить захист веб-застосунків і API (WAAP) – брандмауер веб-додатків наступного покоління (WAF-NG).
Загрози веб-застосунків постійно змінюються, що робить рішення на основі сигнатур немасштабованими. Рішення WAAP допомагають організаціям випереджати середовище загроз додатків, що розвивається завдяки аналітиці в реальному часі та постійному самонавчанню.
WAAP – це сукупність методів та технологій, які використовуються для захисту веб-додатків та сервісів від атак та вразливостей. WAAP включає такі технології, як WAF-NG, сканер вразливостей, автоматичне виявлення та блокування атак 0-дня (у тому числі за допомогою віртуального патчингу), виявлення аномалій за допомогою технологій Machine Learning і смарт-капчі.
WAAP є еволюцією класичного WAF і пропонує сучасні автоматизовані механізми захисту для постійно змінних веб-додатків.
Брандмауер веб-додатків наступного покоління (Next-Gen WAF) захищає та контролює веб-програми від широкого спектру атак у точці їх розгортання на рівні додатків.
Самозахист програм під час виконання (RASP), вбудований у домен середовища виконання додатків, забезпечує захист від атак у реальному часі для API та веб-застосунків.
Захист мікросервісів та API забезпечує безпеку мікросервісу, програми або безсерверної функції для створення мікропериметра з урахуванням контексту та даних навколо всіх окремих сервісів.
Тобто до традиційних засобів захисту (WAF) мають бути додані такі можливості:
Оптимальним варіантом використання отриманих даних буде профіль трафіку: WAF зазвичай приймають рішення на основі окремих запитів або групи запитів, наприклад, всіх запитів в рамках HTTP сеансу або з однієї і тієї ж вихідної IP-адреси. Якщо виявити групу запитів у межах HTTP-сеансу, можна визначити статистично оцінити деякі характеристики. Наприклад, можна перевірити ймовірність певної послідовності HTTP-запитів у межах сеансу. У типових послідовностях зазвичай переважає звичайна поведінка користувача. Атипові послідовності можуть вказувати на небажані дії, наприклад, веб-сканер, що викликає посилання в незвичайному порядку.
Основною відмінністю WAAP від WAF є використання машинного навчання (ML) та/або поведінкового аналізу, а не лише наданих правил безпеки або відомих шаблонів атак».
Щоб виявити небажаний HTTP-сеанс за допомогою методів машинного навчання спочатку необхідно визначити відповідні функції (інжиніринг функцій). Тут базові дані використовуються для ідентифікації атрибутів, для яких модель згодом робить прогнози. Цей крок є важливим для успіху моделі. Приклади таких функцій веб-трафіку включають розподіл часу інтервалів запитів, розмірів об’єктів HTTP або розподіл кодів стану HTTP. Як очевидно з цих прикладів, окремі базові атрибути необроблених даних, такі як позначки часу, можна використовуватиме створення більш складних функцій кілька етапів. На основі цих функцій потім вибираються, налаштовуються та навчаються відповідні моделі машинного навчання. Слушна комбінація різних моделей призводить до створення системи, здатної виявляти певні відхилення в веб-сеансі. Ця система може відповідати на такі питання, як: чи виконувались окремі запити в сеансі людиною, чи це робилося лише програмним забезпеченням? Чи це звичайний користувач або його поведінка говорить про те, що він зловмисник? Якщо запити були викликані будь-яким програмним забезпеченням або ботом, чи це була легітимна пошукова система, інструмент моніторингу або, можливо, небажаний сканер сайту, бот або навіть інструмент атаки?
У цьому контексті кожну веб-програму можна навчати та захищати за допомогою власної спеціальної моделі. Наприклад, певна аномалія в одному додатку може бути абсолютно нормальною поведінкою в іншому. Це дає додаткову перевагу WAAP у порівнянні зі статичними функціями безпеки (класичний WAF), які потребують великих зусиль для налаштування та оптимізації для кожної окремої веб-програми. Під час навчання моделей також необхідно вжити заходів безпеки, щоб гарантувати, що зловмисник не зможе вплинути на етап навчання та побудови датасетів.
Web Application and API Protection знижує ризик компрометації, крадіжки даних, захоплення облікових записів та простою за рахунок інтеграції різних елементів керування безпекою захисту веб-застосунків.
Ймовірно, ви чули заяви типу «HTML і так за замовчуванням має accessibility» або «Не потрібно винаходити цей абсолютно ідеальний елемент управління HTML». Я вважаю, що це загальні заяви, а чи не універсальні істини. Веб-розробникам дуже важливо усвідомлювати недоліки платформи, тому я вирішив зібрати кілька прикладів того, коли у HTML виникають труднощі з точки зору як accessibility, так і usability.
Це неповний список, і він не включає недоліки ARIA. Мені хотілося знайти баланс між широко відомими проблемами і найчастіше зустрічаються (але менш відомими), а також додати до списку те, що ми сприймаємо як належне. У кожному розділі я вкажу ступінь серйозності проблеми, альтернативні рішення та посилання, за якими можна знайти більш детальну інформацію.
Почнемо з простого. Атрибут multiple елемента <select> не варто використовувати практично ніколи. Він нагадує повну протилежність одиночного <select>. Єдине, що його виправдовує, то це те, що я поки не зустрічав цей атрибут в жодній кодовій базі.
Цитата користувача програми для читання екрана (з чудової статті Сари Хіглі, посилання на яку наведено нижче):
Це зламаний listbox. Він зовсім поламаний, я не бачу, як це можна виправити.
Серйозність : висока. Є велика ймовірність того, що більшість ваших користувачів не вміє працювати з цим жахливим елементом керування.
Що використовувати замість : цілком підходяща альтернатива – список чекбоксів; або можна створити власний listbox із множинним вибором.
Додаткове читання : <select> your poison part 2: test all the things (стаття Сари Хіглі).
Ще один простий приклад для розігріву. Елемент <i> семантично несуттєвий, тому необов’язково «поганий», якщо використовується для звичайного текстового вмісту. Однак найчастіше він застосовується для шрифтів значків.
У звичайній ситуації я навіть не став би включати його до списку, адже це більше помилка розробників, ніж проблема платформи. Проте вже 2024 рік, а я, як і раніше, зустрічаю елемент <i>, що використовується з чимось на кшталт FontAwesome. Це проблемно в основному тому, що веб-шрифт використовується для заміни текстових символів (які можуть мати одне значення) на значки (які ніяк не пов’язані з текстовими символами). сторінки та за промовчанням будуть включені в accessibility-дерево. Крім того, вони погано виглядають, часто (і непередбачувано 🐴) ламаються, призводять до інших проблем з accessibility. Докладніше про всі ці проблеми можна дізнатися з поста Тайлера Стіка, посилання на який наведено нижче.
Серйозність : низька або середня. Можна підвищити accessibility, виключивши його з accessibility-дерева (за допомогою aria-hidden) і задавши текстову альтернативу (за допомогою візуально прихованого тексту ), але елемент все одно залишається проблематичним.
Що використовувати замість : SVG! У них хороша підтримка, і вони у багатьох відношеннях кращі. На відміну від шрифтів SVG призначені саме для відображення графіки, тому через них в accessibility-дереві не з’явиться несподіваний текст. Крім того, їх можна застосовувати безліччю різних способів, так що ви можете вибирати: вбудовувати їх, використовувати спрайти або зберігати всередині CSS (за допомогою mask).
При використанні <svg> слід застосовувати наступний надійний патерн: aria-hidden разом із додатковим альтернативним текстом (який за потреби можна візуально приховати). Наприклад, розмітка кнопки виглядає так:
<button>
<svg aria-hidden="true"><use href="#heart" /></svg>
<span>Favorite</span>
</button>Додаткове читання : Seriously, Don’t Use Icon Fonts (стаття Тайлера Стіка)
Неможливо скласти список проблемного HTML та не включити до нього ці списки.
Я не кажу «не користуйтеся списками», у багатьох ситуаціях вони дуже корисні. Але розробники схильні використовувати їх занадто активно, часто просто видалити стилі списків. Іноді ми навіть причіплюємо до них роль ARIA (перевизначаючи таким чином семантику списку), або, гірше за те, додаємо дочірні елементи без <li> стилізації або чогось іншого (створюючи таким чином неприпустиму розмітку). У всіх таких ситуаціях ми втрачаємо всі переваги елементів-списків та потенційно додаємо нові проблеми.
На це надмірне використання списків звернули увагу розробники Safari та почали в деяких випадках видаляти семантику списків; списки, що знаходяться зовні nav та стилізовані list-style: none, Safari списками не вважає. Хоча наміри розробників були хорошими, це призвело до того, що навіть правильно стилізовані списки стають виключно візуальними.
Крім того, упорядковані списки теж мають власні дива. Браузери вважають номери елементів «візуальними», тому при виборі та копіюванні списку номери не включаються до текстового елемента буфера обміну. Це порушує очікування користувачів, особливо якщо номери для них важливі, наприклад, у разі юридичних документів.
Серйозність : низька або середня. Я думаю, що цілком нормально дозволити Safari/VoiceOver робити те, що вони роблять; їх користувачі звикли до цього і навіть можуть очікувати, що веб майже немає списків. Проблема впорядкованих списків та буфера обміну може бути досить серйозною, але її можна вирішити обхідними шляхами.
Що використовувати замість : якщо вам сильно потрібно зберегти семантику списків, то <ul>можна додати role="list". Якщо ви використовуєте іншу роль, то цілком підійдуть звичайні <div>. Ще однією потенційною альтернативою для пар «ключ-значення» може бути <dl>.
<ul role="list">
<li>…</li>
<li>…</li>
<li>…</li>
</ul>Якщо важливими є номери пунктів списку, можна спробувати використати невпорядковані списки, в яких числа — частина текстового вмісту.
Додаткове читання : “Fixing” Lists (стаття Скотта О’Хара), пост у Twitter Джеймса Крейга з Apple та “I Blame the W3C’s HTML Standard for Ordered Lists” (стаття Сібіли Бостонієнсіс).
Атрибут title напружує мене найбільше, зокрема, через його довгу історію. Він настільки поганий, що у специфікації HTML прямим текстом не рекомендують використовувати його. Проте я зустрічав цей атрибут у кожній кодовій базі, з якою працював.
Ось лише деякі з безлічі проблем title:
title.title.title бути частиною імені або опису елемента (або ні те, ні інше).title у різних елементах.Серйозність : висока. Використовуючи цей атрибут, ви навмисно вибираєте зниження accessibility для більшого відсотка користувачів.
Що використовувати замість : у багатьох випадках достатньо включити текст у вигляді частини вмісту елемента; при необхідності цей текст може бути візуально прихований. В інших випадках aria-labelledby або aria-describedby працюють краще, ніж title. Один із винятків — це iframe, які потрібно розмічати за допомогою title.
Майже у всіх випадках, поряд з описаними вище техніками, краще, ніж titleпідійде власна підказка. Однак у підказок є свої проблеми, тому ще краще буде перепроектувати так, щоб повністю позбутися необхідності підказок. Наприклад, завжди можна відображати текст або використовувати паттерн disclosure.
Додаткове читання : The Trials and Tribulations of the Title Attribute (стаття Скотта О’Хара) і Using the HTML title attribute (стаття Стіва Фолкнера).
Спочатку елемент datalist видається успішною альтернативою своїх комбобоксів. Однак чим більше ви його використовуєте, тим глибшим стає розчарування.
color-scheme.Серйозність : середня або висока. У кращому випадку цей елемент може бути корисним як необов’язкова підказка полів введення, які будуть повністю робітниками без додаткової допомоги з боку опцій автоматичного завершення.
Що використовувати замість : <select> або власний комбобокс.
Додаткове читання : Under-Engineered Comboboxen? (Стаття Адріана Розеллі)
Текст-заповнювач повинен допомагати користувачеві, підказуючи, коли поле введення порожнє. Насправді він часто виконує зворотну функцію.
Текст-заповнювач зазвичай схильний до проблем контрастністю кольорів. Якщо спробувати виправити контрастність кольорів, то він може стати невідмінним від реальних значень, що вводяться. Якщо помістити в нього важливу інформацію (наприклад, вимоги до пароля), то значення, що вводиться, приховує цю важливу інформацію відразу після того, як користувач почне друкувати.
Серйозність : середня або висока. У найкращому разі його можна ігнорувати. У гіршому він може дратувати користувачів та шкодити прибутку.
Що використовувати замість : може, нічого? Цілком можливо досить помітного label. Якщо вам потрібен текст підказки, можна розмістити його зовні поля введення і зв’язати їх за допомогою aria-describedby.
<label for="phone">Phone number</label>
<input id="phone" aria-describedby="phone-hint" />
<div id="phone-hint">Example: 123-456-7890</div>Додаткове читання : Don’t Use The Placeholder Attribute (стаття Еріка Бейлі)
Числові поля введення виконують інкремент/декремент під час використання колеса миші, жестів чи клавіш зі стрілками, внаслідок чого вкрай ймовірні неприємності.
І це на додаток до інших проблем з accessibility, узгодженістю та стилізацією.
Серйозність : висока. Щоб відмовитися від елемента, достатньо проблеми зі скролінгом, тому що користувачі можуть ввести неправильне число, навіть не зрозумівши цього.
Що використовувати замість : <input inputmode="numeric" pattern="[0-9]*">. Атрибут inputmode допомагає відображати на пристроях із сенсорним екраном зручнішу клавіатуру, а атрибут pattern допомагає з валідацією.
Додаткове читання : Why the GOV.UK Design System
Нативні елементи вибору дати мають неузгодженість у браузерах, а деякі їх частини порушують accessibility.
У всіх середовищах формат даних відображається як текст-замінник, який, як ми вже з’ясували, викликає проблеми. Формат дати визначає браузер і він може вибрати щось дивне (наприклад, формат дати США), що призводить до непотрібних труднощів.
Серйозність : висока. Ці неузгодженості не просто невеликі незручності, вони створюють реальні перешкоди для accessibility.
Що використовувати замість прості поля введення тексту, а в деяких випадках навіть select.
Також можна використовувати окремі поля для дня/місяця/року та згрупувати їх за допомогою fieldset. Цей fieldset навіть можна стилізувати так, щоб він виглядав, як одне суцільне поле форми . Однак якщо ви вирішите сховати label поля введення, то я б рекомендував відображати формат дати поза поля вводу (як частина легенди або під полями введення).
Відомо, що власні елементи введення дати дуже складно реалізувати правильно, тому якщо вирішите створити їх, вони повинні бути опціональними і доповнювати поля введення тексту.
Додаткове відео : What makes an accessible date picker? Is it even possible? (Доповідь Расса Уїклі)
Просто не користуйтеся ними. Якої б поведінки ви не очікували від цього елемента… ви, швидше за все, помилитеся. Спочатку елемент <menu> мав на увазі як “контекстне меню”, але його так і не реалізували, а тепер він замінений <ul>.
Серйозність : низька. <menu> просто перетворюється на <ul>.
Що використовувати замість : оскільки термін «меню» перевантажений значеннями, це залежить від того, що ви хочете зробити. Ось деякі з альтернатив:
<ul>(або role="list"), якщо у вас є список.role="menu"якщо у вас меню в десктопному стилі.role="listbox", коли у вас щось нагадує власний <select>.<dialog> або role="dialog" якщо у вас стандартний спливаючий контейнер (можливо, з role="list" всередині).Варто зазначити, що деякі з цих ролей вимагають підключення взаємодій із JavaScript.
Додаткове читання : Be Careful Using ‘Menu’ (стаття Адріана Розеллі)
Відключені кнопки чомусь активно використовують, можливо через їхню звичність. Ось два популярні сценарії застосування відключених кнопок:
Однак атрибут disabled не просто запобігає клікам. Він також вимикає функції hover та focus. І це має багато негативних наслідків. Вимкнені кнопки не можуть відображати підказки (які можуть пояснювати, чому кнопка вимкнена). Клавіатурні користувачі не можуть дістатися до вимкнених кнопок через Tab. Якщо кнопка раптово стає вимкненою (наприклад, при відправленні форми), фокус може загубитися і збити з пантелику. Крім того, відключені кнопки звільняються від вимоги контрастності кольорів , підвищуючи ймовірність їх поганої контрастності.
Серйозність : висока. Відключені кнопки зручні (та й то не особливо) тільки для невеликого відсотка бази користувача.
Що використовувати замість : aria-disabled="true" і вручну вимкнути кліки. Однак, при можливості, переробте дизайн так, щоб він не вимагав відключених кнопок.
Додаткове читання : Making Disabled Buttons More Inclusive (стаття Сандрини Перейра)
Нативний програвач відео, як і раніше, має безліч проблем з accessibility і usability. У багатьох браузерах у клавіатурних користувачів виникає проблема з фокусом, тому що вони можуть дістатися не всіх елементів управління, і ці елементи пропадають після початку відтворення відео. У деяких аспектах він незручний і для користувачів програм читання екрана, особливо у разі «просунутих» функцій на кшталт режиму «картинка у картинці».
Рекомендую прочитати наведену нижче статтю Адріана Розеллі, щоб глибше вивчити підтримку цього елемента в різних браузерах і програмах читання екрана.
Серйозність : середня або висока.
Що використовувати замість : точно не знаю. Можливо, альтернативний програвач відео, якщо він розроблявся з урахуванням accessibility. Але чим би ви не користувалися, не забудьте додати підписи та транскрипції, а також надайте можливість скачування відео для його перегляду у зручному для користувача плеєрі. І заради піклування про користувачів не застосовуйте autoplay.
Додаткове читання : Browser Video Players Review (стаття Адріана Розеллі)
Посилання в Інтернеті можуть мати протокол, що не відноситься до http на кшталт mailto: або tel:. Ці протоколи активно використовують, щоб допомогти користувачам (або спамерам) надіслати електронний лист або набрати номер. Однак дуже сміливо було б вважати, що користувач заходить на сайт з того ж пристрою, який буде використовуватися для надсилання електронного листа або набору телефонного номера, і що він хоче використовувати для цього програму за промовчанням. Це може призвести до роздратування, коли користувач просто шукає спосіб скопіювати номер або набрати його з іншого пристрою. Найгірше, адресу пошти/номер часто приховують під посиланням, відображаючи замість нього щось марне типу «Написати мені».
Серйозність : низька або середня. Це дратує і збиває з пантелику, але, напевно, нічого особливо страшного в цьому немає. Користувачі знаходять способи вирішити проблему.
Що використовувати замість : просто покажіть реальну адресу пошти або номер телефону. Його можна легко скопіювати або перенести вручну на потрібний пристрій. Крім того, багато пристроїв автоматично відображають підказку під час вибору тексту, який можна розпізнати як пошту/номер.
Додаткове читання : tel: me.about.it. (Стаття Браяна Керделла)
На завершення хочу повторити, що з реалізації accessibility недостатньо «просто використовувати HTML». Навіть маючи найкращі наміри та використовуючи абсолютно правильну розмітку HTML, можна створити UI без потрібного рівня accessibility, якщо підійти до справи без старанності.
Я впевнений, що за десять років цей список буде виглядати інакше (і, сподіваюся, стане коротшим). Чим більше людей цікавитиметься цією темою, тим доступнішою стане інформація. Це змусить органи стандартизації та постачальників браузерів удосконалювати платформу та наблизити нас до Інтернету з більшим ступенем accessibility. Ви особисто можете допомогти, повідомляючи про нових баг або коментуючи вже знайдені:
Ефект (закон) Лінді – теорія, згідно з якою очікувана тривалість існування феномена прямо пропорційна тому, що він існував до цього. Вперше закономірність виявили на Бродвеї, де постановки, що протрималися на сцені 100 днів, найчастіше могли розраховувати на такий же термін «життя» у майбутньому (якщо шоу йде 200 днів, йому прогнозують ще стільки ж).
Появу теорії приписують фінансисту Альберту Голдману, який 1964 року опублікував у газеті The New Republic статтю «Закон Лінді». Він припустив, що тривалість успішної кар’єри коміків залежить від кількості та частоти їхніх публічних виступів.
Пізніше до цього ефекту звернувся математик Бенуа Мандельброт, який працював в IBM, і згадав закон Лінді в книзі 1982 року «Фрактальна геометрія природи». У наші дні теорію популяризував письменник Нассім Талеб. Він описав закон Лінді у своїй книзі 2012 року «Антихрупність».
«Якщо книга перевидавалася протягом сорока років, я можу передбачити, що її перевидатимуть ще сорок років. Однак, і в цьому головна відмінність від псованих явищ, якщо книгу перевидаватимуть і через десять років, можна буде прогнозувати, що вона перевидаватиметься і через півстоліття. Ось чому речі, які оточують нас довгий час, як правило, не „старіють“, подібно до людей, — вони „старіють“ навпаки. Щороку, який річ зуміла пережити, подвоює її очікувану тривалість життя», – пише Талеб.
У такому вигляді теорія стала найбільш популярною для застосування під час інвестування в ідеї, продукти та активи.
В інвестиційній діяльності ефект Лінді є своєрідним знаком якості — «перевірено часом». Якщо перенести припущення Талеба про книжки на активи компаній, ми отримаємо таке: що довше «живе» фірма, то вищі шанси, що вона «виживе» у майбутньому.
Наприклад, якщо фінансовий гігант JPMorgan існує більше двох століть, то ймовірність, що він продовжить роботу в наступні 10 років, набагато вища, ніж у біржі Coinbase. І навпаки, закриття компанії Coinbase в найближчі 10 років можна прогнозувати з більшою впевненістю, ніж банкрутство JP Morgan.
Як приклад звернімося до даних про капіталізацію 10 найстаріших громадських підприємств.
Логічно припустити, що старі компанії мають міцні зв’язки на всіх рівнях, найкращий досвід у побудові бізнесу, підборі кадрів та виборі векторів розвитку. І нехай закон Лінді не гарантує вищі прибутковості при інвестуванні в старі компанії щодо молодих, є докази ефективності цієї стратегії у довгостроковій перспективі.
Аналітики з Market Sentiment провели ретроспективний аналіз стратегії вкладення $100 у компанії, яким понад 100 років порівнявши її з інвестуванням такої ж суми в активи з індексу S&P 500.
Експерти виявили, що з 2000 по 2023 рік акції Лінді зросли на 676%. За цей же час індекс S&P 500 показав прибутковість лише на 386%.
За допомогою ефекту Лінді інвестори прогнозують не лише «живучість» тієї чи іншої компанії, а й технологічні та інші тренди. Наприклад, якщо Web3-соцмережі не приживуться протягом найближчих п’яти років, то навряд чи вони продовжать існувати в наступне десятиліття.
Якщо звертатися до закону Лінді, перша криптовалюта нічим не відрізняється від інших технологічних трендів. Однак варто врахувати, що біткоїн вже прижився у всьому світі.
Наприклад, схвалення спотового біткоін- ETF може свідчити про остаточне прийняття цифрового золота глобальною фінансовою спільнотою.
Отже ефект Лінді для BTC варто розглядати з точки зору стабільного розвитку першої криптовалюти. Якщо біткоїн зміг «вижити» за минулі 15 років, він, ймовірно, продовжить існувати й у наступні 15 років.
У той час як біткоїн виглядає дуже «живучим», ринок альткоїнів таким не є.
Аналітики часто відзначають циклічність, якої схильні ціни на криптовалюти. Передбачається, що це корелює приблизно з чотирирічними періодами між халвінгами в мережі біткоїну.
Згідно зі статистикою CoinGecko, понад 50% усіх криптовалютів, перерахованих на їх платформі, припинили своє існування. За даними сервісу, з 2014 року «померло» 14 039 проектів, а запущені під час бичачого ринку 2021 постраждали найбільше.
Звідси може випливати, що для застосування ефекту Лінді до альткоїнів варто розглядати тільки ті токени, які пережили хоча б два цикли халвінгу біткоїну, тобто близько восьми років.
Отже, якщо якийсь альткоїн проіснував, наприклад, чотири роки, це не означає, що він проживе ще стільки ж. А якщо він зміг витримати на ринку вісім і більше років, ймовірність того, що він котируватиметься надалі, стає вже вищою.
CSS як технологія справді трохи роздутий, але не такий хаотичний і складний, як його іноді описують. Просто потрібно прагнути лаконічності – у тому числі, за допомогою описаних підходів.
Ненависть до CSS цілком можна зрозуміти – врешті-решт технологія розвивається вже понад 25 років. Нові браузери, що з’являються на ринку, реалізують підтримку CSS по-різному, що призводить до того, що частина коду працює в одному браузері, але не працює в інших. А розробнику доводиться інтегрувати до коду купу вендорних префіксів. Адже це потім ще треба розширювати і підтримувати!
Щоб не потонути в коді, користуйтеся більш сучасними та наочними підходами. Про деяких із них ми й поговоримо.
Найкращий спосіб не вивчати CSS – це використовувати фреймворки, на зразок Bootstrap або Tailwind CSS. Ці інструменти допомагають швидко отримати гарний інтерфейс користувача, але ніяк не сприяють вивченню основ CSS (використовуючи їх, ви навчаєте тільки сам інструмент). І ви точно відчуєте біль і страждання при спробі від них відмовитися.
Вивчення основ CSS дає більше контролю над кодом та творчістю. І найкраща порада – почати з блокової моделі CSS, тому що зрозумівши її, ви знайдете більше сенсу у всій іншій мові.
Просто думайте про кожен HTML-елемент, як про блок, всередині якого міститься контент. Блок може мати висоту ( height) та ширину ( width), межу ( border), відступи всередині ( padding), а також пробіли навколо цієї межі зовні ( margin). Все, що CSS пов’язане з макетом і розташуванням, спирається на блокову модель.
Якщо ви відкриєте інструменти Chrome, побачите, як обчислюється блокова модель для будь-якого елемента на сторінці.
І це автоматично приводить нас до наступної поради.
Історично розташування елементів один щодо одного було одним із найскладніших аспектів CSS.
Ох вже це споконвічне питання про те, як центрувати елемент divі по горизонталі, і по вертикалі! Один із варіантів це реалізувати – задати дочірньому елементу абсолютне позиціонування, а потім перемістити його в нижній правий кут, використовуючи властивості top і left. Щоб помістити в центр не верхній лівий кут елемента, а саме його центр, потрібно також вказати властивість transform: translate(-50%, -50%). Ця властивість переміщає елемент вгору на 50% його висоти вздовж осі Y і вліво на 50% його ширини вздовж вісь X. У результаті потрібної точки виявиться саме центр.
.no-flex {
position: absolute;
top: 50%;
left: 50%;
transform: translate(-50%, -50%);
}Такий підхід працює, але дуже не інтуїтивний.
Більш сучасний інструмент CSS – це flex, який створює гнучкий стовпець або рядок в будь-якому місці інтерфейсу користувача. У flex-елемента також є осі X і Y, якими можна вирівняти його дочірні елементи (їх можна вирівняти вздовж головної осі за допомогою властивості justify-content: center). Перемістити елемент в центр і по горизонталі, і по вертикалі можна за допомогою властивості align-items, вирівнявши відносно поперечної осі.
.with-flex {
display: flex;
justify-content: center;
align-items: center;
height: 100vh;
}Flex – це перший інструмент, до якого слід звертатися, коли справа стосується макету. Але він має один істотний недолік. Якщо користувальницький інтерфейс великий і складний, з безліччю рядків і стовпців, що перетинаються, в HTML-коді буде занадто багато елементів-контейнерів. Ці елементи не мають семантичного значення і існують просто для того, щоб CSS-код був, до чого прикріпитися.
На заміну їм є сучасна функція CSS – Grid. На відміну від flex, який працює тільки з окремими стовпцями та рядками, gridдозволяє думати про макет в цілому. Якщо ви займаєтеся веб-розробкою досить довго, ця ідея може здатися вам знайомою, тому що дуже нагадує таблиці. Просто gridнабагато більш дружелюбний до розробників.
Встановлюючи grid, можна визначити його дочірні елементи як набір стовпців і рядків. Стовпці мають ширину, яку можна визначити за допомогою властивості. grid-template-columns.Можна використовувати значення frабо fractional unit, яка ділитиме доступний простір з іншими стовпцями в сітці. Ми також можемо визначити декілька рядків, після чого кожен елемент усередині сітки буде розміщуватися автоматично.
У наступному прикладі дочірні елементи розміщуються в сітці 2 рядки та 3 стовпці. Середній стовпець має фіксовану ширину 500px, а інші два стовпці займають простір, що залишився. Рядки мають фіксовану висоту 100pxі 200pxвідповідно.
.grid {
display: grid;
grid-template-columns: 1fr 500px 1fr;
grid-template-rows: 100px 200px;
place-items: center;
}У контексті адаптивних макетів найчастіше йдеться просто про зміну ширини чогось залежно від доступного місця на екрані пристрою або в області видимості. Є кілька способів її скоригувати.
Допустимо, ви хочете, щоб стаття займала 50% ширини. Але на маленьких екранах її необхідно зробити фіксованою – шириною 200 пікселів, а на великих – 800 пікселів. Ви можете зробити це, вказавши @media, які застосовуватимуться, залежно від розмірів області перегляду. Проблема в тому, що @mediaбудуть розмножуватися разом із зростанням проекту і підтримувати це стане складно.
article {
width: 50%;
}
@media only screen and (max-width: 600px) {
article {
width: 200px;
}
}
@media only screen and (min-width: 1200px) {
article {
width: 800px;
}
}Ви можете змінити ситуацію, використовуючи функції min, maxта clamp. З їх допомогою код легко реорганізується в:
article {
width: clamp(200px, 50%, 800px);
}Тут 200px– мінімальне значення, 800px– максимальне, а 50%– переважне.
Наступна порада для тих, хто вставляє на сторінки адаптивні зображення або відео, які підтримують певне співвідношення сторін, наприклад 16:9.
Щоб усе нормально відображалося, завжди доводилося додавати зверху відступ padding-top: 56.25%, а потім задавати дочірньому елементу абсолютне позиціонування.
.container-16x9 {
position: relative;
padding-top: 56.25%;
}
video {
width: 100%;
position: absolute;
top: 0;
}Але це можна спростити, використовуючи таку властивість video, як aspect-ratio. У нашому випадку – aspect-ratio: 16/9.
video {
width: 100%;
aspect-ratio: 16 / 9;
}Ми часто використовуємо те саме значення кольору в декількох місцях на сторінці. Якщо потрібно змінити колір, доводиться змінювати кожен рядок коду, який посилається на нього.
p {
color: rgb(255, 0, 0);
}
h1 {
color: rgb(255, 0, 0);
}
h2 {
color: rgb(255, 0, 0);
}Але набагато простіше визначити докорінно глобальну змінну, на яку можна буде посилатися скрізь, де це необхідно. Якщо доведеться змінити цей колір, потрібно буде поміняти лише один рядок.
:root {
--main-color: hsl(0, 100%, 50%);
}
p {
--main-color: green; /* переопределение, как в обычном css */
color: var(--main-color);
}
h1 {
color: var(--main-color);
}
h2 {
color: var(--main-color);
}Змінні каскадуються, як і решта CSS. Це означає, що будь-яку глобальну змінну можна поставити докорінно, але перевизначити глибше в дереві. Також змінні можна комбінувати для складання складніших значень. Наприклад, колір RGB можна визначити на основі трьох інших змінних.
Раніше використання змінних було прерогативою препроцесорів CSS, дуже приємно, що такий корисний інструмент перекочував і в сам CSS. До речі, нещодавно в CSS з’явився і nestling (раніше він також існував лише в препроцесорах).
CSS насправді не є мовою програмування у традиційному сенсі. Але в ньому є можливість виконувати базові обчислення за допомогою функції calc, де доступні деякі базові математичні обчислення. Але найцікавіше, що у цій функції можна комбінувати різні одиниці виміру. Наприклад, можна відняти 50 пікселів із поточної ширини області перегляду.
Допустимо, в коді є анімація, в якій елементи падають зверху. Але ми хочемо їх упорядкувати, щоб вони з’являлися один за одним. Один із способів досягти цього — застосувати різну затримку анімації для кожного окремого елемента.
.first {
animation-delay: 100ms;
}
.second {
animation-delay: 200ms;
}
.third {
animation-delay: 300ms;
}
/*
<i class="drop first"></i>
<i class="drop second"></i>
<i class="drop third"></i>
*/Але за великої кількості елементів таке важко організувати в коді. Складніший підхід — визначити вбудовану змінну CSS для порядкового номера кожного елемента. З її допомогою можна визначити затримку анімації як порядковий номер, помножений на 100 мілісекунд. Так можна обробляти безліч елементів, не збільшуючи обсяг CSS.
.drop {
animation-delay: calc(100ms * var(--order));
}
/*
<i class="drop" style="--order: 1"></i>
<i class="drop" style="--order: 2"></i>
<i class="drop" style="--order: 3"></i>
*/Вище ми згадували, що CSS не є повноцінною мовою програмування, але насправді в неї вбудований механізм керування станом. Ви можете відстежувати поточну позицію у своєму CSS-коді, не написавши жодного рядка JavaScript.
Відмінний приклад – нумерація заголовків. Простий спосіб зробити це — вручну додати ці цифри до самого HTML. Але якщо ви будь-коли захочете додати новий заголовок, доведеться перенумерувати все вручну.
Більш розумний підхід – лічильник CSS. Він створюється через властивість скидання лічильника ( counter-reset). Йому можна дати будь-яке ім’я, а потім збільшувати щоразу, коли застосовується потрібний селектор за допомогою counter-increment. Такий лічильник почнеться з 0 і щоразу збільшуватиметься на одиницю.
:root {
counter-reset: headings;
}
h1 {
counter-increment: headings;
}
h1::before {
content: counter(headings);
}Можна подумати, що при створенні складного меню, що розкривається, для керування відкритим і закритим станом повинен використовуватися деякий JavaScript. Але тільки з CSS також можна просунутися досить далеко.
Швидше за все, ви знайомі з псевдокласом focus, який застосовується до елемента, коли ви вводите форму або натискаєте кнопку. Його можна використовувати, щоб відкрити меню. Але при натисканні на щось всередині меню втрачає фокус і закривається. Саме в цей момент зазвичай використовується JavaScript для керування станом.
Однак усередині є ще один псевдоклас focus-within. Він залишається активним, якщо в результаті взаємодії з елементами на сторінці фокус зберігся у будь-яких дочірніх елементів меню. Так що в цьому випадку можна взагалі не використовувати JavaScript для включення та вимкнення станів.
Коли можливо, замість статичних значень пікселів використовуйте відносні одиниці.
При розробці адаптивних макетів у вас можуть бути заголовки або контейнери з фіксованими полями та відступами. Ви змінюєте їх на екранах меншого розміру за допомогою @media.Якщо у точному дотриманні розмірів цих полів немає потреби, це overhead. Підтримувати таке складно, плюс це не дуже добре працює на пристроях, що автоматично масштабують шрифти під розмір екрану.
Замість фіксованих одиниць, на зразок пікселів, можна використовувати відносні – emабо rem:
em– автоматично розрахує розмір, спираючись на шрифт елемента (а оскільки розмір шрифту успадковується та рідко перевизначається, за фактом em спиратиметься на шрифт найближчого батьківського елемента). Якщо розмір шрифту 16px, то 2em дорівнюватиме 32px;rem– Працює аналогічно, але спирається на розмір кореневого шрифту. Цей спосіб кращийЄдине зауваження – em та rem реагують на зміну розміру шрифту браузера. Отже, якщо хтось у своєму браузері збільшить розмір тексту, зовнішній вигляд сторінки може змінитися.
У CSS є інші відносні одиниці, зокрема ch – ширина символу. За допомогою неї можна продати один трюк.
Якщо ви справді серйозно ставитеся до дизайну, можливо, ви читали «Основи стилю в друкарні» Роберта Брінгхерста. Він каже, що оптимальний розмір абзацу становить від 45 до 75 символів. У CSS ми можемо забезпечити зразкове дотримання цього правила за допомогою функції clamp, яку згадували вище ( width: clamp(45ch, 50%, 75ch);). Так кожен абзац матиме ідеальну ширину.
Відверто кажучи 45ch– це не рівно 45 символів, а відстань, на якій можна розмістити 45 нулів. Якщо використовується моноширинний шрифт, все працює ідеально. Якщо ні, краще перевірити результат практично.
RGB – це червоний, зелений, синій, де кожен елемент може мати значення від 0 до 255. Шістнадцятковий формат містить ту ж інформацію, але в компактнішому вигляді, який ще складніше інтерпретувати.
HSL – це відтінок, насиченість та яскравість. І такий формат спрощує обчислення гарної палітри кольорів. Просто виберіть насиченість і яскравість, а потім збільште відтінок на певну величину, наприклад, на 25. Так можна отримати кілька кольорів, поєднання яких виглядає добре. Ще простіше за допомогою HSL затемнити або висвітлити елемент інтерфейсу. На відміну від RGB, для цього не доведеться ставити окремий колір.
На веб-сайтах з фіксованою навігаційною панеллю часто зустрічається одна проблема. Коли ви переходите до якірного посилання, сторінка автоматично прокручується, але потрібний заголовок закривається фіксованою навігаційною панеллю.
Щоб цього уникнути, виправте властивість scroll-padding, яка додасть додатковий відступ.
PS Рука не піднялася оголосити це окремою порадою, але в оригінальній добірці автори рекомендували використовувати емодзі як імена класів. З їхньої точки зору так код стане більш читаним.
.💪 {
display: flex;
}
.💄 {
color: red;
}
.🌈 {
background: linear-gradient(to right, red, orange, yellow, green, blue, indigo, violet);
}
/*
<div class="💪">
<p class="💄">Hello</p>
<p class="🌈">World</p>
</div>
*/
Як це випливає із самої назви, монолітний блокчейн — розподілена система з єдиною структурою. У ній ноди відповідають за консенсус, виконання транзакцій та доступність даних.
На відміну від модульних, монолітних блокчейнах всі ці завдання виконуються на одному рівні або в групі тісно пов’язаних ланцюгів (також працюють на одному рівні).
Більшість блокчейнів криптоекосистеми – монолітні. Наприклад, біткоін, Solana, Ethereum (на перших етапах розвитку).
Розглянемо принцип роботи монолітного блокчейну з прикладу протоколу биткоина:
Ноди монолітного блокчейна забезпечують:
Архітектура монолітних блокчейнів передбачає, що ноди виконують усі ці функції. У модульних системах виконання відокремлено від врегулювання, консенсусу та доступності даних.
Модульний підхід знаменує собою кардинальну зміну парадигми під час побудови блокчейнів. Суть полягає у спеціалізації: один блокчейн відповідає за виконання транзакцій, інший за підтримку консенсусу.
Таким чином, модульний блокчейн сфокусований на виконанні лише деяких завдань, передаючи інші одному або декільком окремим рівням. Компоненти таких систем можна подати у вигляді кубиків Lego, які можна комбінувати для створення різних конструкцій.
Модульні блокчейни являють собою модулі, що підключаються, кожен з яких може замінюватися або об’єднуватися з іншим залежно від конкретного юзкейсу.
Приклад таких модулів – роллапи. Ці рішення масштабування спеціалізуються з обробки транзакцій (виконанні). За консенсус, доступність даних та врегулювання відповідає батьківський ланцюжок.
Розглянемо принцип роботи Ethereum у контексті модульного підходу. Як і біткоїн, а також багато інших блокчейнів першого покоління, мережа другої за капіталізацією криптовалюти була спроектована як монолітна система. Однак для вирішення трилеми масштабування ефір перетворюється на модульну структуру.
Один із важливих етапів на цьому шляху – реалізація шардингу. Ідея полягає в поступовій відмові від моделі, де кожна нода має обчислювати кожну операцію, на користь моделі паралельного виконання, в якій ноди обробляють лише певні обчислення. Це дозволяє обробляти безліч транзакцій одночасно.
Шардинг розбиває блокчейн на кілька підмереж, кожна з яких обробляє свою частину активності. Розділяючи функції на кілька компонентів, досягається більш висока ефективність і продуктивність, ніж якби всі частини системи працювали над тими самими завданнями.
Ethereum-розробники впроваджують систему із 64 компонентів (шардів), що працюють паралельно. Ноди управляють лише частиною реєстру, яку вони закріплені (виконують процеси і підтверджують транзакції), а чи не підтримують весь реєстр.
У контексті модульного підходу шардчейни зберігають різні частини даних Ethereum. Сегментування виконання дозволяє кожному із 64 компонентів обробляти власний набір транзакцій. Такий підхід допомагає збільшити пропускну спроможність системи та підвищити швидкість виконання операцій.
Деякі розробники є прихильникам орієнтованого на роли підходу до підвищення продуктивності Ethereum.
На відміну від інших (більш централізованих) рішень масштабування на кшталт сайдчейнів, роллапи тісно пов’язані з батьківським ланцюжком. Вони представляють своєрідне розширення для поліпшення пропускної спроможності системи.
Завдяки ролапам блокчейн Ethereum «передає на аутсорсинг» обчислення, фокусуючись на врегулюванні, консенсусі та доступності даних.
L2-рішення здатні кардинально оптимізувати обробку транзакцій без шкоди безпеці або децентралізації системи.
Монолітні блокчейни – історично перший підхід до побудови розподілених систем. Однак за такої схеми складно вирішити проблему масштабування, не пожертвувавши безпекою чи децентралізацією.
Основна перевага монолітних блокчейнів полягає у їх простоті. З однорівневим дизайном менше складнощів при створенні та обслуговуванні системи. Такий підхід також зрозуміліший для новачків, які намагаються розібратися в особливостях технології.
Головні недоліки монолітних блокчейнів:
«Накладні витрати при розгортанні монолітних блокчейнів високі. Що ще гірше, фрагментується безпека, оскільки кожен ланцюжок має завдання зі створення власного набору валідаторів. Якщо ми хочемо інтернет блокчейнів, не можна, щоб кожен із них забезпечував власну безпеку», — зазначають представники проекту Celestia.
За їх словами, фрагментація через відносну закритість монолітних блокчейнів може створювати перешкоди інтероперабельності, ускладнювати життя розробникам і негативно позначатися на досвіді користувача.
З плюсів модульних блокчейнів можна виділити:
Celestia — один із найвідоміших представників модульних блокчейнів. У жовтні 2022 року проект залучив $55 млн у раунді під керівництвом Bain Capital Crypto та Polychain Capital.
Блокчейн дозволяє ролапам та іншим модульним ланцюжкам використовувати Celestia для забезпечення доступності даних та консенсусу. Ноди можуть підтверджувати доступність даних без необхідності завантаження всього набору конкретного блоку.
Архітектура Celestia розроблена таким чином, щоб дозволити її вузлам одночасно досягати консенсусу в різних мережах при виконанні офчейн транзакцій.
Чіткий поділ рівнів консенсусу та виконання дозволяє Celestia зосередитись на створенні організованого та системного підходу до зберігання даних, залишаючи виконання транзакцій окремим ланцюжкам.
У березні 2023 року компанія виділила розроблену модульну структуру Rollkit для підтримки роліпів на блокчейні біткоїну в окремий напрямок бізнесу.
Восени 2023 розробники Celestia запустили мейннет Lemon Mint, а токен TIA почав торгуватися на ряді великих бірж.
Проект Polygon розробляє подібне модульне рішення – Avail. Воно призначене для зниження навантаження на блокчейни за рахунок перенесення даних та підвищення масштабованості «в усіх напрямках».
Avail позиціонується як шар доступності даних для Optimism, Validium та інших рішень на базі доказів з нульовим розголошенням , які працюватимуть поверх нього. Технологія дозволить розміщувати та підтверджувати доступність даних поза мережею, виступаючи ключовим компонентом концепції модульної мережевої структури.
“Avail спеціалізується на впорядковуванні транзакцій і збереженні їх доступності, не займаючись валідацією, як це відбувається в типових блокчейнах”, – пояснив співзасновник Polygon Анураг Арджун.
Рішення дозволяє створювати довільні блокчейни з будь-яким середовищем виконання (EVM,wasmта інші) без шкоди для децентралізації чи безпеки.
Як згадувалося, роллапы працюють у контексті модульного підходу. Optimistic rollups використовують Optimistic Virtual Machine, а ZK-rollups – zkEVM як рівень виконання (смарт-контракти, обробка транзакцій).
Обидва типи роллапів покладаються на Ethereum для інших важливих функцій:
Технологія масштабування під назвою Validium має багато спільного із ZK-rollups. Її особливість у тому, що транзакції виконуються офчейном. Потім система відправляє дані пакетами (батчами) у батьківський ланцюжок разом із доказом валідності.
У таких платформах може використовуватися структура типу «комітету доступності даних» (DAC) або окремої мережі на базі Proof-of-Stake як у випадку з Celestia.
Таким чином, модульний стек Validium складається з таких елементів:
Приклади систем на базі Validium (відповідно до L2Beat): Immutable X, ZKFair, ApeX, rhino.fi, Sorare.
Довгі роки точилися суперечки, як краще називати класи – по бему, за цілями, за компонентами або як завгодно, але з додаванням хеша. І це дійсно важливе питання, який спосіб буде комфортний у розробці великого проекту, що розвивається. Але що ці способи означають для користувача, чи потрібні йому ці класи і як вони пов’язані з його досвідом?
Часом, заходячи в стилі проектів, я мимоволі лякаюся довжині імен, що склалася – модуль, блок, елемент, поделемент, модифікатор 1, модифікатор 2. БЕМ дійсно чудовий і я не збираюся його заперечувати, але його розміри залишають бажати кращого.
Довгі класи збільшують вагу сторінки, це означає збільшення часу завантаження найголовнішого для рендеру сторінки – документа і файлу стилів, від яких безпосередньо залежать метрики FCP, LCP.
Це стало однією з причин, чому я довгий час задивляюся на модулі (на додаток до ізоляції стилів та їх зберігання там, де вони використовуються).
Модулі дають можливість називати класи коротшими, тільки під поточний компонент, зберігаючи при цьому зручність розробки. Але тепер до класів додаються хеші, роблячи їх довшими, а отже перевага не така, як хотілося б. Тому нарешті до теми статті.
Отже, які є методи скоротити класи:
Перший спосіб не підходить для чогось більшого, ніж to-do лист – зробивши класи занадто короткими ми або втрачаємо DX, або ризикуємо перетину.
Для другого і третього способу, css-loader пропонує властивість localIdentNameдля модулів.
localIdentName: "[path][name]__[local]--[hash:base64:5]"
localIdentName: "[hash:base64]"
Найоптимальніший стиск
Підібравши правило можна значно скоротити розмір класів, але все ж таки, значно не одно максимально. Максимальним зменшенням імен класів буде збереження символів – .a, .b, .c, …, etc.
Таким підходом користуються, наприклад, Google, Facebook, Instagram
Щоб реалізувати таке рішення, нас цікавить властивість getLocalIdent, яка дозволяє передавати функцію для генерування імені. Також можна використовувати такі пакети як posthtml-minify-classnames або mangle-css-class-webpack-plugin .
На цьому можна було б завершувати статтю, якби не одна деталь. Я використовую next.js.
Next.js має кілька особливостей, які не дозволяють використовувати ці рішення. Найбільш очевидною особливістю є те, що він не дає можливості налаштувати getLocalIdent зовні.
Саме тому я, 3 роки тому зробив пакет next-classnames-minifier. У ньому я реалізував алгоритм підбору імен та налаштував вбудовування getLocalIdentу потрібні правила у вебпаку. За наступні роки пакет трохи оновлювався, але було в ньому те, що не дозволяло мені назвати його завершеним і готовим для використання в комерційних проектах.
Головною проблемою була необхідність щоразу видаляти папку зібраного додатка та кешу в ci, що, безумовно, дуже позначалося на зручності розробки. І це друга особливість Некста – його система кешування.
Якщо компонент зібрався, то при наступному запуску режиму розробки або збирання він може не перезбиратися. Тобто при перезапуску, алгоритм починав працювати з чистого листа і генерував класи з найпростіших імен ( .a, .b, .c), але в ряді компонентів і стилів, що не перебираються, такі імена були додані при минулому запуску.
З цієї причини рішення і не включене до next.js
Очевидно, критично важливим завданням було позбавити проблеми очищення кешу. І рішення знайшлося. Тепер пакет, подібно до next.js, кешує результати – згенеровані імена – і при кожному запуску відновлює їх з кешу, аналізуючи їх та перевіряючи їхню актуальність.
При цьому швидкість збірки не стала довшою, адже пакет використовує все той же оптимізований алгоритм підбору імені, а за рахунок кешування пакет працює ще швидше [ ніж базове створення імен з генеруванням хешу ].
Можна знайти статті з ефективністю стиснення 30%, 50% і навіть 70%. Насправді все дуже індивідуально. Наприклад, якщо у вас був клас:
.postsListItemTitle {
font-size: 24px;
}
З нього вийде:
.j1 {
font-size: 24px;
}
21 символ ( .j1{font-size: 24px;}) замість 44 ( .postsListItemTitle__h53_j{font-size: 24px;}) – економія 52%. Цей клас використовується в 20 картках на сторінці, що зменшує вагу та html.
У середньому, мабуть, можна говорити про зменшення ваги css на 10-20%.
next-classnames-minifier – давайте зробимо веб Ще швидше.
Рестейкінг – це можливість повторного використання ETH в основній мережі Ethereum або в пулах ліквідного стейкінгу як обернених токенів на платформах, які застосовують протокол EigenLayer. Отримані монети можна направити на перевірку якості захисту сторонніх мереж поза EVM.
У квітні 2023 розробники Ethereum активували оновлення Shapella, яке включало кілька змін на рівні консенсусу мережі. Найважливішим з них є можливість зняття заблокованих монет із депозитного контракту Beacon Chain. Це оновлення викликало приплив ліквідності ринку. Коли алгоритм Proof-of-Stake був удосконалений до зрозумілої та безпечної моделі, стейкінг забезпечив пасивний заробіток на рівні PoW -майнінгу. Крім того, Хардфорк Shapella, знявши ряд обмежень в архітектурі мережі, сформував необхідну основу для розробки нових напрямків та їх реалізації. Одним із таких векторів став рестейкінг.
У звичайному стейкінгу користувач блокує токени в пулі та отримує відсотки у вигляді нагороди за підтримку працездатності та безпеки мережі. Монети зазвичай залишаються недоступними для вкладника на прописаний у смарт-контракті термін — за аналогією з банківським депозитом.
У випадку з рестейкінгом токени можна розмістити повторно, в інших пулах – у тому числі після ліквідного стейкінгу. Це дозволить отримати додатковий прибуток та брати участь в інших DeFi-проектах.
Концепція рестейкінгу близька до об’єднаного PoW-майнінгу, де майнер завдяки сумісним алгоритмам видобутку одночасно видобуває дві або більше криптовалют без зниження загального хешрейту. Таким чином досягається можливість повторного розміщення монет у PoS-блокчейнах.
EigenLayer – протокол, який створив проміжний шар в архітектурі блокчейну Ethereum. Команда розробників зробила революцію у криптоекономічній безпеці, яка дозволила проектам:
EigenLayer надає можливість брати участь у рестейкінгу з різними активами двома способами:
Після запуску рестейкінгу в основній мережі команда проекту поступово розширює кількість пулів. Якщо у першій фазі було залучено LST в еквіваленті 9600 ETH, то вже в другій – 45000 ETH, а трохи пізніше – 100000 ETH. У січні 2024 року в останньому наразі розширенні було залучено понад 500 000 монет ETH.
Учасники спільноти можуть вибирати такі пули, голосуючи токенами в пропорції 1 голос за 1 ETH. Механізм смарт-контракту влаштований так, що при досягненні пулом межі «застібаних» засобів включається пауза, що діє до розширення числа пулів. Про кожне наступне відкриття пулу команда заздалегідь повідомляє через свій обліковий запис у X.
Спочатку протокол обслуговував лише три пули ліквідного рестейкінгу і лише для користувачів платформ Lido Finance (stETH), Rocket Pool (rETH) та Coinbase (cbETH). За підсумками голосування наприкінці 2023 року було додано достатню кількість пулів із актуальними LST, серед яких:
Грунтуючись на аналітичних даних, більшість операцій здійснюється на платформах ліквідного стейкінгу, а це понад $32 млрд TVL що становить майже половину від загального обсягу заблокованих коштів. Згідно з DefiLlama, з червня 2023 року EigenLayer показав зростання TVL з $13,3 млн до $1,7 млрд вже на початку 2024 року.
Нині створено тисячі dapps поверх блокчейна Ethereum, а децентралізоване середовище зростає за експонентом. Але не всі вони користуються перевагами безпеки та довіри головного L1. Основна складність полягає у написанні власного програмного коду криптографічної безпеки для кожного нового dapp та втрати ресурсів на підтримку рівня довіри та часу на підготовку AVS (Actively Validated Services, сервіси активної валідації).
AVS використовуються в будь-якій системі, що застосовує набір розподілених семантик для захисту мереж. Сюди можна віднести сайдчейни, шари доступності даних (DA), нові віртуальні машини, мережі зберігачів та оракулів, кроссчейн-мости та різні L2 -рішення.
У EigenLayer рестейкери мають можливість отримувати додатковий прибуток та вибирати спосіб використання їх коштів для підтримки різних AVS. У команді протоколу цей підхід назвали управління вільним ринком.
Одним з перших AVS на EigenLayer став EigenDA . Шар дозволяє Ethereum зробити дані доступнішими, не виходячи за межі вимог безпеки. EigenDA також надає ролапам ефективну передачу даних з високою пропускною здатністю.
Термін “доступність даних” означає надання гарантій того, що виробники блоків публікують усі відомості про транзакції блоку та забезпечують доступ до них усім учасникам мережі. Це означає, що всі вузли здатні завантажувати дані, що є у всіх блоках мережі. Вузол автоматично перевіряє їхню доступність, підтверджуючи, що дані блоку дійсно були опубліковані.
Шари доступності поділяють на два види: що знаходяться безпосередньо в мережі та працюють за межами блокчейну.
У загальному розумінні EigenDA прагне продемонструвати, що стейкери та валідатори Ethereum можуть підтримувати критично важливу інфраструктуру на додаток до консенсусу і що AVS та користувачі можуть досягти успіху завдяки використанню токенів поверх мережі.
На даному етапі EigenDA здатна досягати пропускної здатності до 15 Мб/с, що в рази вище за нинішні можливості Ethereum. Команда проекту вважає, що у майбутньому може сягнути 1 Гб/с.
Протокол EigenLayer має очевидні плюси:
До недоліків протоколу можна віднести:
Відкрийте криптовалютну картку Trustee за кілька хвилин! Оплачуйте ваші покупки миттєво з автоматичною конвертацією