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

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

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

27.04.2024

Використання Jupyter для Javascript

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

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

Проте все одно, ми будемо працювати суто в серверному оточенні, та, скажімо, створити canvas просто так не вийде. Є там якісь емульовані бібліотеки, але це зовсім не те саме, що малювати в браузері. Плюс deno має езотеричні правила імпортів тощо та зовсім не хочеться вивчати їх тільки заради Jupyter.

Трохи подивився на інші проєкти та знайшов, наприклад, Starboard. Тут весь код виконується в браузері, тож можна робити практично будь-що. Але немає підтримки Typescript або JSX.

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

26.04.2024

Риштування в Rails - забута перевага

Коли я тільки починав працювати з Ruby on Rails, тобто десь у 2008 році, в Rails була одна перевага, про яку я абсолютно забув та згадав тільки тому, що у SwiftUI нічого схожого немає.

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

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

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

Одним словом. Як і Jupyter, риштування допомагало отримати доступ до даних та почати щось з ними робити. Якщо повернутись до SwiftData/SwiftUI - як типового сучасного середовища — то щоб відредагувати будь-що в базі даних, доведеться написати все це риштування вручну. Зазвичай це стільки зусиль, що ніхто так не робить, а обмежується необхідною функціональністю.

Цікаво — чи залишилася сама можливість блогу за 15 хвилин у світлому та простому минулому, або все ж можна відтворити її з сучасними технологіями?

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 повинен бути лінійним для плавного руху — за замовчуванням він не лінійний та з серією рухів карта все одно стрибає.

Раніше