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

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

Підписатись на RSS · 📢 Канал в Telegram @stendap_sogodni

Раніше

Пізніше

15.05.2024

Масове видалення обʼєктів з AWS S3 та Google Cloud Storage

Сьогодні стикнувся з несподіванкою: якщо для видалення бакета AWS S3 Terraform примушує його спочатку спорожнити вручну, то з Google Cloud Storage робить те ж саме автоматично. Видалення може не тільки тривати днями, а й дуже дорого обійтись.

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

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

Правила життєвого циклу — корисна штука. Єдине, що вони розглядають кожен обʼєкт окремо, тому не можна висловити, наприклад “залишити 1000 останніх файлів”. Зате можна розмежовувати правила за шляхом та за тегами, та навіть за розміром файлів — є де докласти фантазію.

14.05.2024

Відстеження кофеїну

🤎 Після перегляду ось цього відео вирішив задля забави встановити собі застосунок для стеження за кофеїном - HiCoffee. Треба сказати, що я й так відповідально ставився до кави принаймні не пив її після шостої. Бо під кофеїном я засинаю ще більш-менш, але прокидаюся декілька разів на ніч.

…Отже. Найбільшим відкриттям з застосунку було те, що період напіврозпаду для кофеїну - 5 годин. Цифру я цю знав, але не усвідомлював; точніше, в моїй уяві було так: за пʼять годин до сну кави не пити.

А тут завдяки графіку в застосунку я зрозумів, що насправді на час сну в організмі залишається 1/8 ранкової кави, 1/4 обідньої та 1/2 вечірньої. Якщо підсумувати, виходить майже ціла порція кави перед сном! Одним словом, за типовий день кофеїн накопичується швидше, ніж виводиться.

Все це, очевидно, дуже приблизно та абстрактно. Але дозволяє зрозуміти у відносних кількостях, як на тебе впливає кава, та коли пора зупинятись. (Звісно, не тільки кава, а й кола, чай, енергетики та так далі.) Для мене дуже корисний експеримент.

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

13.05.2024

OpenSearch в тестовому оточенні

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

12.05.2024

Anbernic RG353M: ностальгія в кишені

🕹️ Минулого року натрапив на кишенькові консолі-емулятори. В мене (та й мабуть, у цілого прошарку українців) такий пристрій моментально викликає бурхливу ностальгію. З одного боку, вони нагадують кишенькову гру “9999 in 1”, з якою можна було грати в Тетрис в трамваї. З іншого, емулятори пропонують ігри з всіх приставок, які можна було зустріти у друзів чи в компʼютерних клубах — від NES до PlayStation 1. Та, на диво, з карткою памʼяті можна дійсно зібрати “9999 в 1” ігор з усіх поколінь на пристрої, який влазить в кишеню.

Обрати консоль насправді дуже складно, бо їх є безліч. Мене спочатку привабила модель, яка взагалі кріпиться на дармовис та здатна емулювати PSX - бо це просто чорна магія! Але ж на практиці з таким розміром нереально грати. Треба знайти вірний баланс розмірів, ціни, та можливостей саме для тебе. Можу порадити канал RetroGameCorps на YouTube, там є огляди, порівняння та інструкції.

Я зупинився на Anbernic 353M. Розміром вона приблизно з iPhone 15. Якість збірки чудова — краща за Nintendo Switch, наприклад. Софт я відразу переставив на ArkOS, за рекомендацією. Взагалі на таки пристрої стає або Android, або збірка Linux (як-от ArkOS). Далі залишається знайти комплект ігор та насолоджуватись. Головне, що всі емулятори вже готові до використання.

Головним мінусом цього пристрою є те, що в мене немає часу на ньому грати! Я давно не їжджу годинами в транспорті, а коли є час пограти — то кишенькова консоль просто програє великому екрану та сучасним іграм. (Хоча, до речі, її можна підʼєднати до HDMI.) Все одно, в пристрої, що готовий запустити будь-яку ретро-гру є щось магічне та особливе.

11.05.2024

YAGNI

✂️ Трохи рідше ніж DRY або KISS можна почути мантру YAGNI - вам це не знадобиться. Мантра нагадує, що зайві функції ускладнюють проєкт, та на варто витрачати час на те, що не є підтвердженою потребою користувачів.

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

Наведу приклад з проєкту, на який я витратив пару років, але так і не запустив. Це був застосунок на React Native з власним ORM на основі PouchDB; на кожному пристрої — власна база, з синхронізацією через CouchDB. Тут поки все прийнятно. Але… база, як завжди, потребує оказійних змін схеми — міграцій.

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

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

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

Засновник екстремального програмування висловив цей принцип ще екстремальніше: Вам потрібний гетер для змінної. Добре, пишіть. Але не пишіть сетер “бо теж знадобиться”. Не пишіть гетери для інших змінних “бо теж знадобляться.” Кращий спосіб писати код швидко це писати його менше.

10.05.2024

OLTP проти OLAP простими словами

Коли ви обираєте базу, щоб напхати в неї багато даних — давайте зараз не будемо думати про те, що таке “багато” - та ганяти по цих даних аналітику — звіти, статистику, і таке інше — то недовго потрібно, щоб прийти до баз категорії OLAP та вирішити, що це саме те, що тут потрібно. Snowflake, Redshift, Clickhouse - всі вони говорять про великі дані та аналітику.

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

Проблеми виникнуть, коли паралельних запитів буде багато. Бо типова OLAP база загнеться на 10-100 одночасних запитах. (Хмарна OLAP база на кшталт Snowflake буде просто зростати у витратах, тож там легше помітити заздалегідь, що багато запитів краще не робити.)

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

09.05.2024

Як влаштована кросплатформенність у Swift?

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

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

Все це у Swift розвʼязується просто та приємно — блоками умовної компіляції. Виглядають вони як директиви препроцесора в C та інших мовах: #if os(iOS) ... #endif. (Але, на відміну від C, ці блоки є частиною мови.) В блоки умовної компіляції можна заточити майже будь-яку ділянку коду:

MyContentView()
#if os(iOS)
  .navigationBarHidden(true)
#endif

Це чудово підходить для внесення точкових змін та не потребує багато думати про сумісність платформ: щоб скомпілювати застосунок SwiftUI з iOS на macOS, достатньо виключити всі специфічні інструкції. А головна маса стандартної бібліотеки спроєктована семантично універсальною.

08.05.2024

Особливості HTTP клієнтів на iOS

У Swift є практично монопольна бібліотека для HTTP запитів. Це Alamofire. Їй вже майже 10 років (тобто вона пережила всю еволюцію мови Swift з її суттєвими змінами.) Звісно, запити можна робити й стандартною бібліотекою — ба більше, Alamofire тільки її загортає.

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

Наприклад: є особливий метод download для завантаження великого файлу прямо на диск (ми отримуємо шлях до файлу.) Це не просто синтаксична зручність: наша програма не отримує зміст файлу та не змушена виділяти на нього памʼять. Коли файл завантажений, можна, наприклад, читати його по частинах.

Або: на iOS можна замовити завантаження в фоні. Йдеться про те, що наш застосунок може взагалі бути закритим та не палити процесор: операційна система сама виконає завантаження. Єдине, що фонове завантаження розраховане на один чи декілька файлів; з сотнями файлів, навіть маленьких, можна очікувати необмежених затримок через особливості планування.

Як на мене, то перекласти обробку HTTP на ОС це винахідливе рішення. Причому Apple справно підтримує нові стандарти: підтримка HTTP/3 зʼявилася ще у 2021.

07.05.2024

Завантаження відео з сайтів

Чи випадала тобі задача завантажити відео з інтернету? Мені чомусь багато разів, першу статтю про це писав ще у 2008… Ось кілька порад.

Для Youtube та багатьох інших сайтів є yt-dlp. Якщо стягнути з командного рядка вас влаштовує, то, може, більше нічого й не потрібно. Але якщо, наприклад, хочемо завантажувати відео прямо у мобільному застосунку?

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

Втім, будь-який хостинг буде використовувати звичайний компонент <video> для відтворення відео. А значить, відеопотік знаходиться за адресою, та нам залишається тільки її дізнатись. Колись відео захищали аплетами Flash та особливими кодеками, але цей час давно минув.

Де взяти адресу відеопотоку? Бажано, без використання справжнього браузера, бо це складно та повільно. В найпростішому варіанті, її можна обчислити з адреси сторінки, проте зазвичай адреси файлів розбігаються зі сторінками в першу чергу з технічних причин. Інколи адреса відео збігається з адресою картинки з метаданих — тільки з різними розширеннями.

Також часто адреса відеопотоку отримується з виклику API. Його можна підглянути в браузері на вкладці “Мережа”. (Взагалі, інструменти розробника в браузері це перше, за що ми беремося.) Тут можемо виявити наступне питання: як авторизуватись? API зовсім без авторизації — рідкість. Але, знову ніякої магії немає: або мусимо відтворити куки, або отримати та передати API токен. Все це можна знайти, підгледівши запити, які робить справжня сторінка.

Нарешті, інколи сервер робить додаткові перевірки: User-Agent досить типова, а також Referer. Тут доведеться поекспериментувати. Для реверс-інжинірінгу API дуже корисний RapidAPI - в ньому легко будувати запити та випробувати альтернативи. Набагато зручніше ніж curl/wget.

06.05.2024

Автокатегоризація постів: підготовка

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

Аналіз тексту починається з того, щоб отримати той текст в чистому вигляді. В мене всі пости в Markdown; найпростіше тут взяти парсер Goldmark, який я вже використовую в телеграм-боті, та приписати до нього рендерер, що видає чисто текст без всякої розмітки.

Далі мусимо перетворити кожен пост на послідовність слів, тобто токенізувати. Тут ніби нічого важкого. Застряг я на наступному кроці — стемінгу. Стемінг то відкидання від слова змінної частини, щоб алгоритм не плутався між “слово” та “словом” або “застрягнути” та “застряг”. В кожній мові стемінг свій; до того ж немає “стандартного” стемінгу, бо він не призводить слово до базової форми (це надто складно), а навмання відрізає закінчення. Тут потрібна бібліотека саме для української мови.

Поки що знайшов чудовий ресурс про обробку текстів українською мовою. Також колекцію стемерів. Далі буде.

Раніше

Пізніше