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

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

25.04.2024

Живе втілення технічного боргу

Довелося з майстром інтернет-провайдера сходити до розподільчої коробки в підʼїзді та дещо допомогти. А там… мало того, що кабелів безліч. Та ще й переплетені вони в клубок — такого я й вдома надивився. Вразила кількість та якість з’єднань — десь були чесні коробочки-каплери. Десь замість них поєднання нутрощів Ethernet-розетки та звичайного конектора. Але місцями просто вісім гільз на кожну пару дротів або (лишенько!) навіть скрутки. А ще, проміж гнізда з кабелів висіли та блимали лампочками два звичайних світча на вісім портів, заживлені з подовжувача, який вів бозна-куди.

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

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

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

24.04.2024

Логи це все що потрібно

Днями була задача додати в сервіс пачку метрик, щоб за ними потім стежити. Метрики у Cloudwatch.

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

…Наступного дня згадав про радикально простіший підхід. Можна просто записувати метрики в журнал! Якщо це зробити структурним логуванням — наприклад, модулем slog, то в будь-якого сервісу зберігання логів не буде проблем створити з цих даних справжню метрику з графіками та моніторингом.

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

23.04.2024

Годинники з радіокеруванням

Нещодавно придбав красивий деревʼяний годинник в Німеччині. (Виробника з каламбурною назвою Natuhr - можу порекомендувати.) Опис годинника включав “автоматичне налаштування”… ніколи того не бачив — ну, то й добре! Навіщо відмовлятися від гарної фічі?

…Як саме то радіокерування працює, задумався вже коли розпакував годинник. Бо, як виявилось, в нього взагалі немає ручного регулювання! Годинник на 100% залежить від наявності радіосигналу. Тут я вже відчув підступ. Як мій годинник знає про часові пояси, наприклад? Радіо не підкоряється межам поясів.

Виявилося, що радіокерування — це німецький сервіс DCF77. Технічно, його можна спіймати в Україні (радіохвилі розповсюджуються на тисячі кілометрів), але проблема в тому, що сигнал транслює час в зоні UTC+1. Відповідно, нас така система обходить, тому я про неї ніколи нічого не чув. Втім, в Європі це досить популярна технологія — від IKEA до годинників в публічних місцях, вона може коректувати годинники та навіть переводити на літній час автоматично.

На щастя, як я дізнався, настінні годинники всі мають цей стандартизований годинниковий механізм, який без великих зусиль можна поміняти. Але не всі вони взаємозамінні: довжина вісі та навіть її діаметр відрізняються. В мене, наприклад, оригінальні стрілки не сіли на новий механізм. Але за виключенням того, заміна механізму робиться тривіально. Можна навіть купити механізм зі стрілками та перетворити будь-яку площину у годинник!

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

22.04.2024

Jupyter: спостереження

Дивлюся досить непоганий курс Андрія Карпати про програмування нейронних мереж. Що поки вразило, так це те, що курс ведеться цілком в Jupyter - інтерактивному “блокноті” для Python. Я, певно, перший раз бачу його в реальному використанні.

Jupyter - це REPL. Я як рубіст добре знайомий з REPL (тобто “run-eval-print loop”). Тільки в Jupyter кожний шматок коду зберігає можливість редагування та перезапуску. Так само як і в інших REPL, весь код має спільну область змінних, та хоч всі шматки можна запустити як цілу програму, але користь саме в тому, що їх можна запускати окремо. Також на відміну від REPL-консолей, в Jupyter можна зручно набрати та запустити цілий блок коду та не звертати увагу на проміжні результати.
Одна з перших дій Андрія — оголошення у власному класі методу repr. То є перетворенням об’єкта в рядок для зручнішого перегляду — аналог to_s в Ruby чи String() в Go. Зрозумів, що я майже цього не роблю у своєму коді, а за потребою покладаюся на автоматичне відображення, або переглядаю конкретні атрибути. Скільки ж я за довгі роки надивився на всякі Object(0xdeadbeef).
Взагалі, спостерігаю, що Jupyter (та й REPL взагалі) переносять увагу з коду на дані. Я звик розуміти та розробляти код алгоритмічно та абстрактно, без конкретних даних взагалі — не в останню чергу тому, що для цього код не потрібно запускати. А тут зовсім інший підхід: спочатку окремі приклади — можливо, навіть обчислені вручну — а потім вже узагальнення.
Нарешті, ефектно виглядає використання візуалізацій. Це ще одна перевага Jupyter над “просто REPL”. Я сам писав, що графіки спрощують розробку — але як круто, коли можливість побудувати графік з даних вбудована в середовище! Та й не тільки графік, а табличка (для записів з бази даних) або граф (для звʼязків між ними) або дерево (для складної структури) теж корисні.

21.04.2024

Мої незамінні доповнення до HTPC

🪄 Пульт для компʼютера. Я довго обирав та знайшов Pepper Jobs W10 Gyro - його й досі можна придбати на Амазоні. В нього чудова “гіроскопічна” миша — тобто курсор “слідує” за тим, куди вказує пульт. Це абсолютно магічна та корисна функція, щоб керувати компʼютером з дивану. Також присутня повноцінна клавіатура. З таким пультом периферію можна за собою не тягати.
🎃 Фонова підсвітка. Класична підсвітка потребує включення в HDMI, але в мене чудовий варіант від Govee, який знімає зображення з екрана камерою. Топологічно, це окрема лампа, ніяк не повʼязана з телевізором. (Колись давно писав, як вони разом вмикаються.) Цього цілком вистачає для ефектної підсвітки. Причому камера в мене знаходиться під телевізором та практично непомітна. До тієї камери потім можна синхронізувати освітлення хоч на всю кімнату та влаштовувати дискотеки.
🎛️ Гарний перемикач HDMI. Тут маю прикрі новини: всі перемикачі, що я бачив, створювали проблеми. То звук загублять, то не зрозуміють, що пристрій може 4К, з HDR взагалі складно. Це і дешеві, і дорогі, і з кабелями різними… Люди в інтернеті радять брати AV ресивер, тобто пристрій розміром з два відеомагнітофони від таких фірм як DENON чи Yamaha. Можу підтвердити, що з “бюджетним” ресивером від DENON жодних проблем більше не маю, та дуже задоволений. (Зате з ресивером можна заощадити на акустиці, бо в ньому вже є підсилювач. Хоча “заощадити” давайте теж візьмемо в лапки.)
📡 USB хаб-подовжувач. Всілякі пульти, бездротові клавіатури та джойстики працюватимуть краще, коли їхній приймач знаходиться спереду, в досяжному місці, а не позаду компʼютера десь за телевізором. Легше за все придбати USB-подовжувач та винести всі приймачі туди. (До речі, також це уникне відомої проблеми з наведенням на USB від портів.)

20.04.2024

Освітлення з добовим ритмом

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

В ідеалі, освітлення мало б адаптуватись до часу доби. Тому довелося відступити від правила покупати тільки якісні червоні лампи та знайти щось зі змінною температурою. Знайшов такий виріб, як Philips WiZ Connected Tunable White Smart LED.

Тепер, як зробити, щоб температура лампи відповідала часу? Пішов спочатку складним шляхом: через HomeAssistant. В цілому, автоматизація за часом — зрозуміло. Але нюанс — в мене ця лампа йде під звичайний, не розумний вимикач. Тобто вносити зміни доведеться тоді, коли лампа вмикається. Чи може HomeAssistant “помітити”, що лампа зʼявилася в мережі? Так. Тільки доведеться використати подію “сутність змінила стан з Недоступний на Увімкнений” замість більш звичної “пристрій увімкнено”.

З такою автоматизацією задача була розвʼязана. З єдиним недоліком: поки лампа зловить Wi-Fi, проходило декілька секунд, під час яких лампа була в попередньому режимі. (Насправді в реальному використанні це абсолютна дрібниця. Але…) (О, до речі, відразу через застосунок Wiz вимкнув функцію, коли лампа автоматично перемикає світло з синього на жовте на кожне увімкнення.)

Тоді вирішив звернутися до (очевидно гірших?) засобів автоматизації, вбудованих у Wiz. Та був дуже здивований, що добовий ритм — це стандартна функція цих ламп! Налаштувати розклад тривіально (див. ілюстрацію). Ніякого HomeAssistant тут не потрібно. Єдине — що все одно режим змінюється з затримкою.

19.04.2024

Стохастичний трекер: перші успіхи

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

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

Проте на статистиці по тижнях зміни зʼявляться тільки наприкінці тижня. Не дуже дієво. Тож я сидів, записував пінги та думав, що робити.

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

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

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

18.04.2024

Як зробити мінікарту?

Добре, вчора я отримав GPS-трек для відео з реєстратора. Наступний крок — зробити з нього мінікарту на кшталт GTA.

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

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

Тоді план Б це використати пакет векторних карт та записати з нього відео. Тобто… доведеться звертатися до вебпрограмування. На щастя, MapTiler, звідки я беру карти, має гарний SDK. Показати та зорієнтувати карту — справа на хвилини. Результат — зверху.

Єдиний недолік — відео трохи смикається — спочатку не знайшов, як робити анімацію. Бо не шукав: приклад лежить на поверхні, а анімація функцією flyTo робиться практично так само, як просто перехід до координат. Тільки easing повинен бути лінійним для плавного руху — за замовчуванням він не лінійний та з серією рухів карта все одно стрибає.

17.04.2024

Отримання GPS-треку з відеореєстратора

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

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

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

exiftool -g3 -ExtractEmbedded video.mp4

Кожний пакет даних вже привʼязаний до кадру, тобто залишається (якщо це слово доцільне) згенерувати відповідний кадр UI та накласти його. Далі буде.

16.04.2024

URL в повідомленнях про помилку

Просте та геніальне рішення: щоб покращити досвід від ваших повідомлень про помилки, можна зробити на сайті підтримки сторінку з поясненням та… вставити посилання на цю сторінку прямо в текст помилки. (Йдеться про повідомлення в API чи SDK, не в інтерфейсі — хоча там посилання на довідку теж доцільні.)

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

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

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

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

Раніше

Пізніше