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

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

16.11.2023

Автоматизація macOS: витягання поточної вкладки з Safari

Я останнім часом багато зберігаю закладок в Obsidian. Зазвичай просто копіюю посилання з браузера та зберігаю у належний документ. Все б добре, але хотілося б також автоматично отримувати й назву сторінки. А ще краще відразу ціле посилання у синтаксисі Markdown, щоб не робити його вручну.

Напевно, є безліч способів це робити, але більшість з них починається зі встановлення чогось новенького, яке отримує доступ до всіх моїх вкладок. Хотілося обійтись наявними засобами. З таких найбільш очевидними є засоби автоматизації macOS: Shortcuts та AppleScript.

Shortcuts - то нове графічне оточення для побудови скриптів з готових блоків. AppleScript - стародавня мова та оточення для автоматизації. Задачу можна розвʼязати кожним з них, як видно з ілюстрації. Також кожний зі скриптів можна привʼязати до комбінації клавіш Hyper+C за допомогою BetterTouchTool (може й інакше, але я так звик.) Працює бездоганно, я дуже задоволений. 🥳

Є один важливий аспект. У Shortcuts кожна дія має налаштування приватності, тому під час запуску в тебе спитають дозволу на перегляд сторінки — причому дозвіл привʼязаний до домену, тому доведеться бачити його часто. У AppleScript немає таких детальних дозволів, тому тебе просто один раз спитають, чи дозволяєш BetterTouchTool (де-факто власнику скрипту) взаємодіяти з Safari. Тому я зупинився саме на рішенні на AppleScript.

…Ну й бібліотека засобів у AppleScript та Shortcuts абсолютно різна. На щастя, принаймні можна викликати один скрипт з іншого. Та й скрипти оболонки теж. Мак взагалі надзвичайно дружня для автоматизації система, якщо мати бажання.

(Минулої осені я як раз писав скрипт, щоб зберігати вкладки з Safari до Reeder. От, дійшла черга ці вкладки опрацьовувати та каталогізувати.)

15.11.2023

Вкладені підказки у VSCode; власні налаштування кольорів

💡 Десь близько року у VS Code є така функція, як вкладені підказки (inlay hints.) Вони додають “фантомний” допоміжний текст до коду — наприклад, назви параметрів функцій або їхні типи. В тих мовах, де це підтримується (а для мене це TypeScript та Go), це дуже зручно. Раджу відкрити налаштування, пошукати inlay та подивитися на численні можливі підказки.

До речі, офіційної української локалізації VS Code немає, отже доводиться вигадувати переклади функцій власноруч.

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

🎨 Тому розібрався та знайшов налаштування workbench.colorCustomizations. Ним можна перепризначити будь-який з контекстних кольорів. До речі, для підказок кольорів цілих три — перераховувати їх не буду, бо легко знайти в редакторі налаштувань знов-таки за ключем inlay. (Не знаю, чи всі знають, що окрім графічного діалогу налаштувань у VSCode можна редагувати їх у вигляді JSON, для чого є команда Open User Settings (JSON).)

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

14.11.2023

Неочевидні блокери

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

Але є підступніші блокери — такі, які не повʼязані напряму з предметом роботи.

🕸️ Технічний борг. Код, над яким треба працювати, має застарілі норми. Або тести випадково падають на кожний пʼятий запуск.
🧰 Погані інструменти. Код доводиться вручну форматувати? Поки працюють тести, можна сходити за кавою? Симулятор завжди займає 100% процесору?
🚦 Пріоритизація. Є більш важлива задача, яка все ж не робиться зараз, бо ми вирішили робити те що робимо. Але думками все одно повертаємось до тієї іншої задачі. А поточна робота гальмує.

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

13.11.2023

Виправлення випадкових помилок в інтеграційних тестах на Go

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

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

🔍 Розуміння логіки. З одним з очікувань була інша проблема — ми чекали, поки не залишиться записів в проміжному стані. Інколи таке очікування не призводило до результату. Уважне вивчення документації виявило, що є інші проміжні стани, які ми не рахували (якщо просто, то перевіряли стан “активний”, але не стан “очікування”.)

🤹‍♂️ Перегони даних. Є в тестах такий сервер, який приймає посилання та складає в масив. Все б добре, але запис у масив не є безпечною одночасною операцією. Тож в рідкісному випадку, коли два посилання надходило одночасно, масив втрачав одне з них. Додаємо мьютекс та проблема зникає.

🐳 Залежності Docker. Нарешті, траплялось ще таке, що контейнер з сервером запускався раніше за Redis, намагався підʼєднатись та тут же ж виходив з помилкою. Звісно, траплялось рідко та зазвичай на CI. Не вистачало параметра depends_on.

12.11.2023

Альтернативи для QR-кодів

Чи можна ділитися посиланням якось окрім QR-коду?

Графічних кодів є багато різних, але вони всі мають один недолік: потрібний спеціальний додаток або інший читач. Я знайшов навіть таке дивне рішення під назвою SnapTag: сфотографувати код та надіслати світлину по СМС. Зрозуміло, така технологія не прижилась (а ще, зі Snapchat вони не мають ніякого звʼязку). Бо з нестандартних кодів, мабуть, найбільш відомий — це як раз коди Снапчату Snapcode. Але для поширення звичайного посилання вони не підійдуть.

А от справжня альтернатива - NFC-мітки. Це наліпка розміром десь від 20 мм з мікросхемкою всередині. Всі їх бачили на дорогих товарах в крамницях. Але в таку само мітку можна закодувати URL - місткість більш ніж достатня (100 символів та більше). Читаються NFC-мітки всіма сучасними смартфонами. Причому для читання достатньо піднести телефон на 10 см до мітки — не потрібно шукати вірний кут чи гарне освітлення. Якщо в мітці закодоване посилання, телефон його відкриє.

Щоправда, так люди робити ще не звикли. Можна спонукати їх інструкцією (або навіть наліпити зверху муляж QR-коду.) Та інша проблема — мітки треба програмувати. Програматор наразі коштує близько 1000 грн, а одна мітка — від 10 грн. Оскільки сама мітка малесенька, можна поєднувати її зі звичайною графічною наліпкою… або замовити друк наліпок з мітками, якщо знайти де.

Та інша сучасна альтернатива, до якої теж ще не всі звикли: просто надрукувати коротке посилання текстом. Сучасні смартфони здатні розпізнати текст камерою та відкрити посилання так само як і з QR-коду. (За досвідом, айфон хоч написаний від руки номер телефону зрозуміє.) Таке рішення мені подобається понад усе.

11.11.2023

QR коди: про зміст

Щоб вже закрити тему про QR коди: чи можемо ми впливати та, як зміст коду перетворюється на пікселі, тобто згенерувати інші пікселі?

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

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

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

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

Ще є коди-рамки, про які пише Вікіпедія. Це правильне, стандартне розв’язання задачі поєднання коду з графікою. Але їх не підтримують типові читачі. Хоча Frame QR існує вже девʼять років. Ну, сам QR код існує двадцять девʼять, так що колись підтримка зʼявиться.

10.11.2023

QR коди з зображенням на тлі

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

QR код починається з маркерів у кутах. Маркери обовʼязково мають бути присутні та заповнені одним кольором, бо саме за маркерами сканер знаходить код у світлині. Але не обовʼязково квадратними — головне утворити лінійну послідовність в 1-1-3-1-1 діапазонів темного та світлого. До речі, QR код може бути й світлим на темному. А також не обовʼязково чорно-білим, бо в справжньому світі немає нічого чорного або білого — хоча чим вище контрастність, тим краще код буде читатись.
А окрім маркерів, весь інший зміст кожної клітини, як я це розумію, читається за центральним “пікселем” (світлини з камери) — він має бути темним або світлим. Емпірично, решта пікселів не має значення, тому на тлі QR-коду може бути будь-яке зображення. Навіть якщо тло чорне, а в центрі біла крапочка, то відповідна клітина QR-коду читається як біла. А якщо тло в цьому місці світле, то взагалі ніякої крапочки не потрібно.
Є ще популярний метод поставити посередині QR-коду логотип. Він дуже просто працює - QR-код використовує надлишкове кодування інформації, тож до 30% коду можна закрити будь-чим. Тільки нюанс: маркери та деякі інші функціональні зони коду в ці 30% не входять — тільки клітини з даними. Тож насправді логотип обмежений ще більше.
До речі, в кодах з більшою “місткістю” маркери займають меншу частину площі. Навіть з коротким змістом можна обрати більшу роздільну здатність, та отримати більш “акуратний” код (якщо скористуватися бібліотекою, яка дозволяє власноруч обирати місткість, а правильніше, версію, коду). Тільки треба розуміти, що доведеться його друкувати більшим форматом, щоб камера могла роздивитись клітини.

Чомусь по генерації QR класні бібліотеки написані на Python. Є qrcode, а є amazing-qr. Є ще CuteR, який краще поєднує код з зображення.

09.11.2023

Docker - це не система збірки

…Взагалі, вчорашні відкриття наштовхнули мене на наступний хід міркувань.

Раніше я дивився на Docker як на верхній рівень скриптів збірки. Тобто, щоб ми запускали docker build або docker compose, а все інше витікало звідти. А якщо так не виходить, то це погано, та треба докладати зусиль, щоб затягти всі аспекти збірки всередину Dockerfile. Наприклад, використовувати проміжні контейнери, монтування кешу, як я вчора писав, та інші засоби.

Але насправді, Dockerfile та docker buld не є гарною реалізацією системи збірки, тобто аналогом make, rake, чи просто скриптів оболонки.

Збірка потребує інструментів, які не потрібні в остаточному образі, а також утворює зайві артефакти. Наприклад, файли журналів можна знайти в багатьох публічно доступних образах, що не тільки збільшує їх розмір, але й може вести до витоку інформації.
Кеш, доступний в Docker через RUN --cache, є обмеженим та потребує особливих дій. Наприклад, до нього немає доступу з хосту.
Підготовка до збірки Dockerfile - той крок, що називається transferring context - відбувається через копіювання файлів, що досить неефективно та може тривати десятки секунд. Можна замість того монтувати залежності через RUN --mount, але то, як і кеш, потребує особливого ставлення.

Одним словом, відтепер буду використовувати Dockerfile тільки для створення образу з вже готових артефактів. Та нічого страшного, якщо docker build буде лише частиною більшого скрипту збірки.

08.11.2023

Пришвидшення збірки Go+Docker з 10 до 3 хвилин

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

Що не давало результатів: перенесення контейнерів баз даних з docker-compose в сервіси GitHub Actions: запуск триває однаково. Також кешування шарів Докера: щось на CI воно не гарно виходить.

А далі я помітив, що більшу частину збірки займала компіляція додатків на Go. Яка відбувалася як крок в Dockerfile. Зазвичай Go компілює досить швидко — але то завдяки кешу. Бо Go це така мова, де всі залежності збираються з коду під час кожної компіляції — а тимчасові результати зберігаються в кеш. Є кеш — тоді Go може обмежитись тільки файлами, що були змінені. Немає кешу — та всі наші залежності підлягають компіляції. Щоб зрозуміти обсяг роботи: кеш для нашого проєкту займає 600 Мб!

Проблема глибше: Dockerfile не має доступу ні до якого сталого кешу. Тобто є RUN –mount=type=cache, але такий кеш збережеться тільки між збірками на одній машині. Для CI це не допоможе. Втім, для локальної роботи вже добре.

Остаточним рішенням було винести компіляцію з Dockerfile та запускати окремою командою. Тобто спочатку make, потім docker compose up. Результати компіляції тепер просто монтуються до контейнерів.

З таким підходом компіляція використовує кеш, який легко переноситься між запусками CI. Насправді навіть стандартна дія actions/setup-go кешує (між запусками) кеш компіляції — тож робити її власноруч не потрібно. Єдина різниця, що трохи ускладнився скрипт запуску.

07.11.2023

Експорт даних з Reeder, та бази даних Realm

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

То виявилось несподівано просто, бо Reeder використовує базу даних Realm. У Realm є пакет NPM, тож мені залишилось тільки відкрити файл з базою, прочитати зміст та зберегти в JSON. Задача на пʼять хвилин. Ще є Realm Studio, але він дозволяє експорт тільки в форматі звʼязаного списку, що потребувало б подальшого перетворення.

Взагалі Realm - цікава база, яку я знаю доволі давно. Це одна з тих баз даних, які дозволяють зберігати дані локально, а вже потім синхронізувати. Тобто одна з можливих основ мобільного додатку, де важливе локальне зберігання. Цікаво, але в мене в macOS знайшлося тільки два додатки, які використовують Realm: це Reeder та… додаток Нової Пошти. Можливо, на телефоні їх знайшлося б більше, але взагалі не найпопулярніша технологія

Що знайшов зараз, чого раніше не бачив — це бібліотека IceCream для синхронізації Realm через CloudKit, тобто без впровадження додаткового сервісу синхронізації на платформах Apple.

Раніше

Пізніше