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

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

10.04.2024

BigQuery Write API як приклад гарного API

Довелося заганяти дані в BigQuery через тамошній Write API. В мене з Google Cloud досвід мінімальний, тому очікувань гарних не було. Був приємно здивований.

Запис відбувається тільки по gRPC. Щоб надсилати записи, ми мусимо спочатку оголосити для них схему Protobuf. Це розвʼязує відразу декілька задач. Protobuf це компактний формат даних — бо містить тільки зміст, а не структуру. Він обовʼязково повинен збігатися зі схемою таблиці — тобто ми впевнені, що не пишемо сміття.
Також завдяки кодогенерації легко з Protobuf отримати структури даних — наприклад, для Go. Та ще й схеми таблиць. В такому разі можна навіть взяти Protobuf за джерело істини та “мігрувати” таблиці у згенеровану схему.
В сам механізм запису вбудований захист від обриву. Точніше, є два різновиди потоків запису. Всі потоки завжди надсилають дані відразу в BigQuery, проте різниця в тому, коли ці дані зʼявляться в таблиці. Звичайний потік робить дані видимими відразу. А відкладений — тільки по явному закінченню запису. Якщо програма обірвалася та не закрила потік — то як і з транзакціями, дані будуть відкинуті. Єдине, що не подобається — неможливо атомарно закрити потоки в різні таблиці — тож у випадку паралельного запису можна створити розбіжності.
Одним словом, можна швидко зробити надійний імпортер, стійкий до помилок та змін схеми. Нарешті, запис через потоки відносно дешевий - 2.5 центи за гігабайт. Я завжди ставився до BigQuery як до дорогого сховища, але, виходить, дорого буде звертатись до тих даних — а не записувати їх.

09.04.2024

Контексти в Golang, осмислення

Контексти, як і тип error, висвітлюють одну з головних ідіом Go: робити перетік програми очевидним. Навіть в збиток до стислості та легкості написання.

Там, де в інших мовах помилки самостійно “виринають” по стеку механізмом винятків — хтозна-куди — в Go ми примушені перевірити кожну помилку в кожному місці виникнення. Та, в 99% випадків, вручну реалізувати повернення вгору по стеку. (В 1% ми перевіряємо, чи це не io.EOF або ще якась “прийнятна” помилка.) Це найбільше й дратує — що хоч ми робимо перевірки вручну, але практично з єдиним передбачуваним результатом.

Якщо error - це найбільш прозорий спосіб повернути стан з середини назовні, то context.Context - найбільш прозорий спосіб передати зовнішній… контекст всередину коду. Так, це значить, що ми передаватимемо параметр ctx в кожну функцію нашого проєкту, де є бодай одна операція з мережею. Це включає не тільки багато очевидних функцій, але й деякі такі, де, здавалось би, ніякий контекст не потрібен. Наприклад: функція-конфігуратор, яка проміж іншим створює клієнт AWS, повинна передавати контекст. (Ця проблема нагадує поширення async по коду в JavaScript.)

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

Ми всі знаємо, що проблема зависання існує, так само як і проблема несподіваних помилок. Go, на відміну від інших мов, примушує нас не закривати на них очі.

08.04.2024

Бібліотека conc в Golang

Вже другий пост задоволення бібліотекою github.com/sourcegraph/conc. Такі в ній гарні обгортки для типових задач рівночасності.

Цього разу — конкретно про модуль conc/pool. Він реалізує абстракцію “запустити декілька задач рівночасно та почекати на результат”. Ніби для того достатньо стандартного sync.WaitGroup, але то буде примітивне рішення. Доведеться вручну лічити задачі, збирати результати, обробляти помилки…

З conc/pool достатньо запустити необхідні задачі викликом pool.Go(), а потім зачекати — викликом pool.Wait(). Є декілька модифікацій пула залежно від змісту задач: чи повертають вони результат, або помилку; чи потребують вони контекст (з особливою можливістю скасувати контекст після першої помилки.)

conc/pool підходить для ситуацій, коли ми запускаємо різнорідні задачі — приблизно як Promise.all в JavaScript. Та головне, що він робить використання рівночасності легше та простіше. Наприклад, якщо нам потрібно завантажити дві неповʼязані сторінки. Зазвичай така задача надто маленька, щоб розкладати її на горутіни, канали, і все інше. Але з conc/pool майже нічого зайвого писати не доведеться. Просто чудова маленька абстракція.

07.04.2024

Документація

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

Можна поєднувати: тести можуть бути гарною внутрішньою документацією. Зокрема тому, що “зелені” тести ще й гарантовано відповідають реальності. Я періодично звертаюся до інтеграційних тестів, щоб згадати особливості поведінки системи.

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

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

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

06.04.2024

Office key у Windows

Колись базовий пакет Windows містив Сапера. У Windows 11 його немає, зате є більш дорослі ігри — в одну з них грав сьогодні, називається “Не увійти в Office 365”.

…Я граю у Windows через Parsec, та мене досить давно дратує, що час від часу в браузері відкривається сторінка “Увійти в Office 365”. Я знав, що вона привʼязана до деякої звичної мені з macOS комбінації клавіш, проте розібрався тільки сьогодні.

Все виявилося ще гірше, ніж я очікував. На клавіатурах для Windows зʼявилася нова клавіша - “Office Key”. Але… чомусь вона не має нового коду клавіші, а емулює натиск Win+Ctrl+Alt+Shift, тобто комбінації, відомої як Hyper key. Але: Hyper key був обраний саме через те, що таких комбінації не зустрічаються у звичайних програмах та можуть бути призначені за власною потребою користувача.

В мене натиск на Hyper (а насправді Caps Lock) перемикає мову на клавіатурі, тобто натискаю я його регулярно, та часто несвідомо. Що, через Parsec, призводить до появи дратівної сторінки.

А тут виходить, що Microsoft вирішили пригребти Hyper key на власні потреби. Та ще й так, що його неможливо перепризначити або вимкнути. (Для порівняння, macOS дає змінити поведінку кожної клавиші-модифікатора окремо.)

Ну як — неможливо… Коли є AutoHotKey, то можливо. Хоча й не очевидно, бо комбінацію обробляє процес Explorer, та просто перехопити її не вийде. Знайшов тред з розвʼязком — я б сам не придумав.

05.04.2024

Як гарантувати імпорт в базу без дублікатів

Є така задача — завантажувати пакети даних в базу. Пакет складається з декількох частин. Інколи програма буде ламатися посередині (а яка не буде?); нам потрібно гарантувати, що жодний пакет не буде пропущений та в базі не зʼявляться дублікати.

☑️ Можна зробити окрему табличку чекпойнтів, в який записувати ті пакети, які збереглися повністю. Тоді під час запуску наступного імпорту мусимо перевірити, чи є в базі дані з неповних пакетів, та якщо є — видаляти їх. Мінус: не у всіх випадках можна знайти та видалити дані.
💕 Можна створювати нову таблицю на кожний запуск імпорту, та атомарно копіювати дані за закінчення імпорту. Зазвичай, але не завжди, копіювання всередині бази робиться легко. Принаймні якщо дані в одній таблиці. Неповні таблиці просто видаляємо.
💼 А можна згадати, що в базі є транзакції, та вони здатні не тільки гарантувати цілісність подвійної бухгалтерії. В PostgreSQL, наприклад, взагалі немає обмеження на довжину транзакції. А якщо транзакція не буде завершена, то рядки з неї технічно автоматично стануть видаленими. З мінусів — транзакція буде обмежена поточною сесією.

04.04.2024

Чому Go вміє форматувати дати "як Ruby?"

Натрапив випадково на те, що в стандартній бібліотеці Go є, проміж різних стандартних форматів, формат дати time.RubyDate. Тільки Ruby - немає всяких PythonDate, JavaDate, або HaskellDate. Хоч це мене, як рубіста, переповнює гордістю, доведеться все ж поставити питання — навіщо?

Щоб відповісти, знаходимо той файл на GitHub та закопуємося в його blame. (Це типова процедура розшуку причини, яку я роблю щоразу, коли бібліотека поводиться незрозуміло.) Корисніше за все тут функція “open blame prior to this change”. Знаходимо коміт, в якому рядок зʼявився, та з нього - PR, в якому той коміт зробили.

Виходить, в далекому 2010 році, за два місяці після випуску мови на публіку, команда Go виявила розбіжність форматування Ruby та стандартного “Unix date”. Як вони її виявили та чому та розбіжність була варта включення в стандартну бібліотеку? Бо в тому форматі повертав дати тогочасний API Twitter. На той час, певно, цього було достатньо, щоб в мові Go зʼявився формат дат “як у Ruby”.

Наразі Twitter API (наскільки він живий?) повертає дати в стандарті ISO 8601. Якого, до речі, в Go немає! Є тільки формат time.RFC3339, який, як я сьогодні дізнався, тільки перетинається з ISO 8601. Бо обидва стандарти пропонують набагато більше єдиного вірного формату. Наскільки більше? Пропоную роздивитись ось цю жахливу діаграму. Форматування часу — це складно!

03.04.2024

Дизайн та юзабіліті скрипту для експорту рецептів

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

Окрім просто рецептів, довелося знайти в API та експортувати решту інформації, яку до них додає користувач: теки, оцінки, та нотатки. Спочатку треба було помітити, що їх немає (та впевнений, що є й інші елементи, якими я не користуюсь, тому забув.)
Поля, які збігаються 1-в-1, довелося відформатувати. Наприклад, харчову цінність, час приготування. Харчова цінність, як я тільки що помітив, в мене має кращий вигляд, ніж в оригіналі. :)
В Paprika не так багато метаданих; тому в поле “нотатки” я додав: оцінку спільноти, ключові слова, дату публікації, та інше. Оцінку намалював зірочками ⭐. Приємно, що Paprika також вміє базовий Markdown.
Поморочився над категоріями. На жаль, хоч в Paprika є вкладені категорії, але я не знайшов, як їх вказувати в імпорті. Тоді, щоб відокремити категорії з NYTC, додав до них префікс. Префікс мав бути зрозумілим, але не кричущим.
Також призначив всім рецептам категорію “NYT Cooking”, а ще категорію, яка відповідає оцінці спільноти. Бо, як я писав, оцінка ця дуже корисна, та хотілося зробити її доступною для пошуку.

Я б хотів його вже опублікувати, але для того доведеться ще попрацювати маркетологом.

02.04.2024

Федеративна авторизація з AWS в GCP

Довелося мати справу з проєктом, де є компоненти в AWS та GCP. Наївне рішення в такому випадку — просто поділитися ключами доступу. Проте ключі можна вкрасти, тому всередині хмари ми користуємося ролями, що призначені з оточення. Дізнався, що роль AWS можна використати для авторизації в GCP - називається це Workload Identity Federation.

Яким чином Google може перевірити нашу роль? Трохи криво, але дієво: викликом AWS API GetCallerIdentity. Причому щоб Google міг зробити той виклик, ми формуємо параметри, підписуємо їх власним ключем AWS, та передаємо всі параметри в сервіс STS Google (зазначу, що ключі залишаються в нас - Google отримує тільки підпис). Той власноруч робить цей виклик, отримує у відповідь автентичну сутність AWS та, якщо їй дозволено вхід, видає нам ключ Google.

Окрему складність ставить бізнес-модель авторизації: є workload identity pool, який є “дверми в Google”; пул отримує доступ до конкретного service account, який буде нашим представником по всіх інших справах в Google Cloud. Але за авторизацію відповідає workload identity provider; в одного пула може бути декілька провайдерів. Як на мене, то дуже заплутано.

На щастя, більшість тих нюансів (в тому числі весь процес авторизації!) приховані в SDK. Тобто пул видає нам стандартний для GCP credentials.json, в якому міститься повна інструкція для клієнта, який буде запущений на AWS. (Нічого секретного: тільки інформація про засіб авторизації, та координати цільового service account.) Оскільки в межах AWS клієнт може отримати (тимчасові) ключі самостійно з оточення, то нам нічого більше робити не треба.

Тобто, коли вже розібрався, то все “просто”. До речі, так само Google підтримує авторизацію з OpenID Connect та іншими технологіями. Гарно!

01.04.2024

Декодування ненормального JSON у Go

Кастомизація розбору та генерації JSON у Go - один з підходів “вище середнього”, який робить цю типізовану мову зручнішою або взагалі, відкриває шлях до задач, які здаються неможливими.

Вчора зіткнувся з проблемкою: в JSON-LD в одних рецептах світлини передаються переліком об’єктів (в об’єктах - посилання, розмір, і т.д.), а в інших - просто рядком з посиланням.

В мовах з динамічним типізуванням це навіть не варто уваги. А в Go ми повинні задати конкретний тип JSON, який хочемо отримати. Та написати в ньому “рядок або масив обʼєктів” неможливо, бо в Go немає алгебраїчних типів.

Можна, як я колись писав, встановити тип interface{}. Результат можна розібрати або рефлексією, або перевіркою типів; в будь-якому випадку код буде багатослівний. Особливо якщо дані мають складну структуру, а не просто “рядок або число”.

Однак є й кращий спосіб. Це створити спеціальний тип поля та реалізувати в ньому метод UnmarshalJSON. Метод отримує на вхід []byte, та повинний призначити з них свій зміст. Не потрібно вручну парсити JSON; ми делегуємо це звичайному парсеру, коли зʼясуємо, який конкретний тип перед нами. Наприклад, в моєму випадку, я просто дивлюся, чи є перший символ лапкою ", та викликаю Unmarshal в рядок, а якщо ні — то в структуру.

Раніше

Пізніше