Стендап Сьогодні

Що я зробив, що я хочу зробити, і що це все значить.
Повсякденні здобутки в форматі стендапу.
Детальніше в статті

28.11.2023

Легко та просто — субʼєктивні явища

В списку читання натрапив на інтервʼю про те, як Дерек Сіверс використовує Ruby. Він згадав цікаву доповідь Річа Хікі десятилітньої давності - Simplicity Matters. І це наштовхнуло мене на цілу низку спогадів та думок, бо десять років тому я був в захваті від ідеї “простого коду”, але зараз вона здається мені дуже… недалекою?

Особливо зачепило, коли Дерек як приклад простого рішення навів переніс логіки додатка в функції PostgreSQL. За моїм досвідом, це ніяк не спрощує розробку або підтримку. Він і сам, напевно, здогадується підсвідомо, бо наступним чином каже, що зробив би з рішення опен-сорс, але на жаль, всі його додатки завʼязані на єдину базу даних, що навіть за означеннями Річа ніяк не “просто”.

Я не хочу сказати, що він не правий. Якщо його влаштовує власне рішення, з ним зручно працювати — то все чудово. Яка йому різниця до моєї оцінки? В компʼютерних технологіях немає нічого “простого”, тобто “односкладного” за природою. Абстракції над абстракціями над абстракціями. Простота — це лише влучний вибір того, які аспекти ми хочемо виділити. Це наш, субʼєктивний вибір.

Що значить субʼєктивність, практично? Те, що до простоти можна йти з двох боків. Або наближати предмет (код, архітектуру) до розуміння споживача, або ж споживача наближати до предмета. Придумати кращу абстракцію. Обрати вірну перспективу. Підібрати слова. І тоді люди скажуть — так, це просте рішення!

Цікаво, що в англійській слово simple виходить зі значення “єдине складання”. А в українській мові простий має зовсім іншу етимологію — з того, що я знайшов, то “простий” походить від “знайомий, звичний”. Може, тому я й дивлюся на простоту як на субʼєктивне явище.

27.11.2023

JSON - універсальний формат даних для всіх випадків

Для серіалізації структур даних у рядок є одне правильне рішення: JSON. Є кілька випадків, коли це не найкращий вибір, а у всіх інших можна два рази не думати. (Раніше писав про HTTP/JSON).

Для документів, що призначені для редагування людьми. Синтаксис JSON надлишковий; чого варти тільки обовʼязкові лапки навколо ключів. Також немає стандартної підтримки коментарів — життєво необхідної для документів функції. Зате є інше певне рішення: YAML. (Чи знаєте ви, що стандарт YAML є надбудовою над JSON?)
Для двійкових даних. В JSON їх доведеться кодувати — скоріше за все в Base64. Це зайві витрати як по розміру (хоча Base64 чудово стискається в GZip), так і по часу (а якщо стискати — то ще більше.) На великому масштабі має сенс тримати двійкові дані окремо. З файлами досить поширено явище sidecar file. У HTTP, звісно, є multipart. В базах даних — поля blob.
Для “високонавантажених” вузлів варто переходити до форматів, де структура задається окремо - Protobuf або Cap’n’Proto. А для масивів даних - Parquet. Обовʼязково треба памʼятати, що відокремлення схеми робить дані менш прозорими та ускладнює підтримку. Тому “високу навантаженість” треба починати надзвичайно високо. Якщо сервіс всередині робить виклики AWS SDK по HTTP/JSON, то навряд чи йому потрібна gRPC. А для зберігання масиви JSON, стиснуті у GZip, практично не додають зайвого розміру, оскільки GZip чудово стискає повторювані рядки, якими є ключі та розмітка JSON.

Серед переваг JSON - легкість в розумінні людиною, висока архівна якість, наявність якісних, ретельно оптимізованих та перевірених (це дуже важливо!) бібліотек для будь-якого середовища. В роботі багато дилем, але для серіалізації можна спокійно брати JSON.

26.11.2023

Програмування типами в TypeScript

TypeScript - явище цікаве тим, що для компіляції та роботи додатка жодний тип не потрібний. Вони всі — для нас, для програмістів. Тому при утворенні типів потрібно думати не про те, щоб не було нічого “червоного”, а про те, як за допомогою типів висловити логіку програми. При цьому якщо код описує поведінку програми, то типи описують стани в які вона може потрапить.

В JavaScript широко поширена практика мати в обʼєкті поля на всі випадки життя, а про наявність того чи іншого поля дізнаватись по значенню поля-мітки. Можна реалізувати це в TypeScript буквально — оголосити всі поля опціональними. Або ще гірше — навіть опціональними не робити. Ми здобудемо компіляцію без помилок… але ці типи нічого не додають до правильності програми.

Краще взяти з моїх улюблених інструментів — мічене об’єднання (discriminated union.) Як приклад — історія про різні форми внеску. Міченими обʼєднаннями можна розібрати тип на всі можливі стани, в яких він може знаходитись. З одного боку, це нас примусить додати перевірок в деяких місцях, де нам здається, стан і так зрозумілий. З іншого, надає “скелет”, на який можна натягнути код, котрий буде перетворювати стани, або обмежуватись одним з них.

25.11.2023

Нові стандарти UUID: v6, v7, v8

Дізнався, що з UUID, про які я кілька разів писав, є нові розробки, а саме, чернетка RFC, яка додає ще три стандарти, які виправляють, в тому числі й ті проблеми, про які я згадував.

UUIDv6 залишає розташування полів з UUIDv1, але виправляє дві головні проблеми: UUIDv6 можливо сортувати за датою та замість використання MAC адреси, ідентифікатор вузла обирається випадково.
UUIDv7 позбувається решти незручних та застарілих домовленостей. В якості таймстемпу береться звичайний час Unix (бо в UUIDv1 був свій, особливий стандарт кодування часу.) А решта бітів заповнюється випадковими бітами.
UUIDv8 - це абстракція, яка дозволяє нам вигадати будь-який метод побудови ідентифікатора — він тільки мусить мати правильні біти версії.

Хоч стандарт ще не затверджено, але генератори вже існують для Ruby, Golang, та й взагалі, побудувати та прочитати UUIDv7 набагато легше. Їх можна почати використовувати вже зараз, та якщо вже потрібно мати UUID, то я б радив саме цю версію.

Додатково: чому UUIDv1 не можна сортувати хронологічно, хоч вони й містять дату? А тому, що дата в UUIDv1 має порядок “менший біт на початку”.

24.11.2023

Зробив інструмент для аналізу графу ресурсів Terraform

Сьогодні ставала задача — знайти, де саме використовуються деякі ресурси в Терраформі. Задача ніби нескладна, та з нею порається Terraform Language Server в доповненні для VS Code. Проте є ситуації, коли цей пошук нетривіальний та доповнення його недовиконує. Наприклад, коли залежність проходить через модулі, та не просто модулі, а й ресурси output та var. Зʼявилася ідея оптимізувати, тож написав маленький додаток.

Пошук інструментів, що існують, гарних результатів теж не дав. Зате знайшов корисну команду terraform graph, яка генерує граф ресурсів на мові DOT. Сам по собі граф теж не підходить, бо коли ресурсів тисяча, то нічого наочного в графі немає. Зате граф — хороша основа для машинного аналізу.

…В контексті Terraform цей граф це також добре тому, що він переносний, тобто не привʼязаний до конфігурації, доступів, та іншого, а також тому, що він не містить жодних секретів (хіба що саму структуру ресурсів.)

Оскільки вивчення графу — це операція не з одного кроку, вирішив зробити не утиліту командного рядка, а графічну, а саме, звісно, клієнтський вебдодаток. Для розбору файлів DOT знайшов пакет ts-graphviz. А решта - Svelte (який вже точно став моїм вибором №1 для простих додатків.)

Зокрема, я винайшов рішення для var та інших проміжних ресурсів. В додатку є особливий режим, який робить їх “прозорими” та відображає успадковані залежності. Також, оскільки граф не містить інформацію про розташування ресурсів в коді, то додав можливість скопіювати рядок оголошення ресурсу, щоб можна було легко знайти його в редакторі.

Сам додаток TFDig та його код. Якість поки на рівні “пару годин писав”, ви мої альфа-тестери. :)

23.11.2023

Історія однієї фічі: коректування накопичень

Контекст: в Сінтрі скоро будуть накопичення; внески на накопичення створюються як витрати з бюджету. Але зʼявилася потреба також додавати коректування накопичень, які фактично є теж внесками, але вже без відповідної витрати: таке коректування моделює зовнішню зміну до накопичення. Ось мій процес розробки по кроках.

Починається все з типу GoalDeposit; такий тип визначений для Redux та є єдиним місцем, де явно описана структура внеску. Оскільки коректування це майже внесок, то я розширю той тип, що вже існує.

GoalDeposit = { isCorrection: true } | { expenseID: string }; // та інші поля

Далі, коли ця зміна зафіксована, оновлюю правила безпеки, щоб вони приймали внесок без витрати. Це робиться з покриттям тестами, які фактично є інтеграційними для бази даних — бо тут типи ніяк не допоможуть уникнути помилок. Правила бази існують окремо від решти додатка, як я вчора писав.
А запуск tsc повідомить мені про розбіжності в коді додатка, тобто ті місця, де потрібно поміняти логіку. Таких виявляється небагато: це видалення внеску (бо воно видаляє й відповідну витрату) та форма внеску — тут, зрозуміло, відбудеться головна робота над фічею. (Цікаво, що інші місця, де внесок розглядається як доповнення до витрати, не потребують змін, бо зазвичай TypeScript сам звужує тип через використання поля expenseID.)
Нарешті, залишається оновити форму — тут нічого цікавого, звичайна робота над інтерфейсом.

22.11.2023

Правила безпеки для Firebase Firestore

База даних Firebase Firestore особлива тим, що вона займає місце повноцінного бекенду, до якого звертається клієнтський додаток. А значить, окрім звичайної перевірки даних, яку роблять всі бази, Firestore також мусить робити й авторизацію.

Механізми валідації та авторизації поєднані в Firestore в єдину систему правил безпеки. Правила безпеки — то є попросту функції, які визначають, чи дозволений той, чи інший запит. Правила впорядковані за шляхом.

Найпростіші правила перевіряють зміст документа, а також наявність в користувача доступу до нього — в контексті запиту міститься ID користувача, який можна порівняти з елементами шляху, або з атрибутами.

Правила виконуються в контексті запиту, та мають доступ до самого документу. Окрім того, можна завантажувати й інші документи — наприклад, щоб перевірити наявність у користувача підписки. Проте це рахується та сплачується як додатковий запит до бази.

В цілому, правила це зручний інструмент, та мені подобається їхня завершеність. Що не подобається: правила абсолютно непрозорі для клієнтів — клієнт просто отримує повідомлення “бракує дозволу” як на помилки валідації, так і взагалі на логічні помилки в правилах (наприклад, звертання до атрибута, якого не існує.)

Щоб знайти справжню причину, потрібно дивитися в логи Firestore та зіставляти їх з діями клієнтів. Це робити незручно. Тому я й наполягав на написанні вичерпних тестів на правила безпеки — тести, оскільки працюють з емулятором, мають доступ до справжніх помилок.

21.11.2023

Нюанси перетворення індексів в OpenSearch

Перетворення індексів в OpenSearch (або ElasticSearch) кажуть, що вони схожі на матеріалізовані розрізи в реляційних базах таких, як PostgreSQL.

Схожість в тому, що перетворення утворюють новий індекс, який побудований на даних з індексу-джерела. (Якщо що, то “індексом” в OpenSearch називається колекція документів, а ніяк не механізм пошуку. Але, якщо нахилити голову, то це і є “індекс для пошуку”, а таблиці до нього просто немає.)

Але алгоритм перетворення суттєво відрізняється від матеріалізованих розрізів. По-перше, перетворення завжди інкременті. Повторний запуск перетворення обробляє тільки нові дані. Хоча, в той самий час, перетворення займають набагато більше часу, ніж побудова розрізу схожої складності — очевидно, OpenSearch не розрахований на операції, які обробляють буквально всі документи.

По-друге, цікаво те, як саме тут реалізована інкрементальність. OpenSearch відстежує перелік документів, які змінилися від останнього виконання. Далі — обчислюються всі комірки агрегації, які містять ці документи. І, нарешті, кожна з комірок обчислюється повторно. (В порівняння з розрізами в Redshift, це досить просто для розуміння.)

Складно стає, коли стає потрібно видалити вихідні дані та зберегти при цьому агрегації. З видаленими документами самими по собі OpenSearch нічого не робить. Але якщо відповідні комірки будуть обчислені наново — що відбудеться, якщо нові чи оновлені документи потраплять до тих самих комірок — то вже без врахування видалених документів.

Що пояснює, чому для видалення старих даних рекомендують додати до атрибутів для групування дату створення документа. Тоді ми гарантуємо, що комірки для минулих дат вже ніколи не отримають нових документів — а значить, збережуть свої значення довічно.

20.11.2023

Ролапи в ElasticSearch тепер застарілі?

Не встигли ми інтегрувати ролапи (ні, серйозно - не встигли), аж раптом остання версія ElasticSearch - 8.11 - оголошує, що вони deprecated. Хоч в нас не ElasticSearch, а OpenSearch, я б все одно не покладав великих надій на цю функцію, бо на практиці OpenSearch слідує за ElasticSearch по своїм планам. (OpenSearch це гілка ElasticSearch з відкритою ліцензією.)

Як я розумію, офіційна причина депрекації в тому, що є функція downsampling, яка робить те ж саме, тільки більш ефективно. Але downsampling працює тільки для часових рядів, коли ролапи підтримували агрегацію по набору атрибутів.

Тому інша, краща альтернатива ролапам — це перетворення індексів - transform. Раніше я віддав перевагу ролапам, бо вони виглядали більш спеціалізованими, але за реальним досвідом видно, що працюють вони однаково: роблять пошук з агрегацією, сторінка за сторінкою, та зберігають в новий індекс.

Але важлива різниця в тому, що в ролапах документи, що складають агрегацію, були приховані від користувача, в той час, як перетворення утворюють звичайні вихідні індекси, з яким можна робити все, що з іншими індексами, включаючи ще одне перетворення. Це те, що мені в ролапах найбільш не подобалось, бо зберігати місяці та роки даних в невидимих документах якось… неспокійно.

А ще перетворення здатні на повноцінний заскриптований map-reduce, тобто можна реалізувати майже будь-яку логіку.

19.11.2023

Оптимізація зображень для вебу

Сьогодні в черговий раз прочищав блог від тих проблем, які встигли накопичитись. Для цього в мене безплатний акаунт Ahrefs, який без $99 на місяць небагато всього робить, проте надає корисний аудит проблем з сайтом.

Одною з проблем виявилось те, що в мене забагато великих світлин. Дивно, що Ahrefs не каже прямо, що таке “завелика” світлина, але за розміром найменшою такої зрозуміло, що поріг дорівнює одному мегабайту. Причому, не мебібайту, а саме одному мільйону байтів, що буде важливо нижче.

Звісно, виправляти це вручну — робота не для мене, я краще відшукаю утиліту та буду писати скрипт. Знайшов jpegoptim. Головне тут — це можливість вказати бажаний розмір результату… щоправда, в кібібайтах. Емпірично визначив, що якщо вказувати розмір у 920 кб, то світлини будуть виходити точно менше за 1000000 байтів.

Залишилось знайти всі великі файли JPEG та застосувати до них jpegoptim. Для того підійде стандартна команда find. Єдине, що виявилось, що пару файлів я не хочу оптимізувати (вони стосуються глобуса). Тому додав також файл ігнорування, а щоб застосувати його, довелося дізнатися про команду comm - вона робить, фактично, операції над двома множинами рядків.

Нарешті, само собою, я хочу запобігти повторенню появі нових завеликих світлин. Тому до своїх лінтерів для блогу додав також такий, який просто знаходить файли та попереджає про їх наявність.

Остаточний скрипт, якщо він потрібний чи цікавий, можна забрати тут.

Раніше

Пізніше