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

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

20.04.2025

Кава та сон

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

І тут теж було несподівано, бо я не став спати краще. Скоріше навіть гірше, бо все літо прокидався дуже рано та не міг заснути. Чи то ластівки заважали, чи кішка, чи сонце у вікно — в будь-якому разі був постійно не виспаний.

А після повернення до кави — не став спати гірше. Навіть коли випʼю кави о восьмій вечора. Так що, емпірично для себе, зробив висновок, що кава — це принаймні не головне.

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

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

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

19.04.2025

Протоколи розумного будинку: Matter

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

По-перше, Matter містить протокол прикладного шару. Того, на якому всі питання комунікації вже вирішені, та можна зайнятися передачею змісту. Як HTTP, SMTP чи SSH. Також, Matter стандартизує всі кроки звʼязку пристроїв IoT - від виявлення та підключення до навіть конкретних типів пристроїв та їхніх команд.

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

(Це та галузь, де відкрите ПЗ - HomeAssistant тощо — на зусиллях ентузіастів досягло більше, ніж мегакорпорації. Втім, це покладається на технічну грамотність користувачів, та складно уявити собі HA в кожному будинку.)

Отже, (ті самі мегакорпорації зібралися та) придумали стандарт Matter, з яким будь-який сумісний пристрій можна підʼєднати до будь-якого центру керування. А також до декількох (Multi-Admin). А також навіть поєднувати пристрої між собою — наприклад, зʼєднати вимикач з лампою в самодостатню пару.

В Matter багато плюсів. Він побудований на відкритих технологіях: мережі IP (в тому числі й Thread), сертифікати PKI, виявлення mDNS. Він повністю локальний, на відміну від 99% екосистем виробників. Він звільняє виробників від розробки власної хмари та застосунку та дозволяє сфокусуватися на якісних пристроях. Через це відкриває шлях для маленьких виробників.

Мінус, очевидний — стандарт нічого не значить, поки його не підтримують. Причому якісно, а не аби як. Також, Matter містить обмежений набір категорій та функцій (який розширяється). Та він фактично потребує підтримки Thread (або Wi-Fi чи Ethernet.) Але наразі головний недолік — це дуже обмежений вибір пристроїв.

18.04.2025

Глибше в кролячу нору mDNS

Пробачте, але в mDNS/DNS-SD стільки моментів, які мене змусили зупинитися та подумати, що треба про це розповісти.

По-перше, що таке multicast? Я знав про зʼєднання 1-до-1 та про broadcast - поширення сигналу на всі вузли. А Multicast - це буквально модель publish/subscribe для мережі IP. Для цього виділена категорія адрес (224.0.0.x) та повідомлення на ці адреси приймаються всіма слухачами в мережі. Звісно, це працює тільки для протоколів без сесії, тобто UDP, QUIC тощо, але не TCP.

Є реєстр відомих адрес Multicast, так само як і стандартних призначень портів. Як я розумію, Multicast більше використовується для початкового налаштування та виявлення, ніж для постійного поширення повідомлень.

Як це працює з Ethernet, зрозуміло (пакети розсилаються всім інтерфейсам, та фільтруються з боку отримувача). Але як Multicast можливий за Wi-Fi? Виявляється, так, є особливий режим надсилання за Wi-Fi, коли пакет призначається не одному, а всім клієнтам, та для того у мережі навіть є груповий ключ. Ось більше інформації та ще тут.

Чи можна DNS-SD використати у власних проєктах? Авжеж! Наприклад, для пошуку партнерів для гри в локальній мережі. Або синхронізації застосунку з телефону із компʼютером (забуте мистецтво.) Для того доведеться визначити системний сервіс DNS-SD та інтегруватися з ним. В macOS це mDNSResponder (скількі раз я його помічав, але не розумів, що він робить!), а оголосити сервіс можна тією ж утилітою dns-sd. Тобто все ж “центральний” реєстр сервісів є, але на рівні кожної машини.

17.04.2025

Протоколи розумного будинку: mDNS, DNS-SD, DNS-SRP

А ви замислювались колись, як взагалі пристрої знаходять один одного в мережі? Хто подумав DNS, той вгадав. Але є нюанси.

По-перше, як взагалі працює DNS? Це протокол на основі UDP, тобто асинхронний, тобто дуже спрощено, ви гукаєте у простір “підкажіть адресу вузла (або іншу інформацію)”, та звідкілясь приходить відповідь. В типовому сценарії ви питаєте в конкретного вузла, але насправді відповідь часто приходить не звідти.

Але із виявленням пристроїв все ще цікавіше. Бо тут запит DNS йде на всі адреси в мережі — що називається mDNS, multicast DNS. Та відповідає на нього не роутер чи інший центральний вузол, а самі пристрої! Це називається DNS-SD - стандарт DNS для виявлення сервісів. В macOS є вбудована утиліта для нього, на Linux/Windows наче теж є аналоги. Ось, будь ласка, це команда “агов, хто в цій мережі взагалі підтримує DNS-SD?”

dns-sd -B _services._dns-sd._udp

(Взагалі звичайний dig теж вміє робити запити до mDNS, коли не поламаний):

dig @224.0.0.251 -p 5353 -t ptr _services._dns-sd._udp.local

Я аж рот роззявив від кількості та від різноманіття сервісів. Наприклад, тут є й _airplay, й _home-assistant, а не тільки розумні пристрої.

Як можна здогадатися, така інформація не тільки корисна, а й небезпечна, оскільки запит може надіслати будь-яка програма чи пристрій в мережі. Нарешті зрозумів, чому свіжі версії macOS видають попередження на кшталт “Дозволити застосунку бачити пристрої в локальній мережі.” Бо навіть не потрібно нічого сканувати, як Трініті в Матриці — пристрої самі все скажуть.

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

16.04.2025

Протоколи розумного будинку: Thread

Спочатку цікавий факт: більшість технологій розумного будинку використовують один та той самий радіопротокол IEEE 802.15.4. (Може, хто помічав, що Wi-Fi - це “сусідній” IEEE 802.11.) Це протокол фізичного рівня, тобто відповідає за те, як дані кодуються у радіосигнали. Тому що Zigbee, що Thread, що ще декілька протоколів — це все IEEEE 802.15.4 на частоті 2.4 ГГц (Так само як і “старий” Wi-Fi та мікрохвильовки.)

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

Навіщо ж тоді ще один протокол? Головна особливість Thread - що вузли мають адреси IPv6. (Їх є 340 ундецильйонів — вистачить на всіх.) Це значить, що замість ізольованої мережі, Thread стає частиною локальної та глобальної мережі IP. (Головним транспортним протоколом тут є асинхронний UDP, тому, можна сказати, UDP/IP.)

Звісно ж, це суттєво спрощує архітектуру. З Zigbee чи BLE потрібний привілейований посередник, що перекладає повідомлення між застосунками в TCP/IP та пристроями в Zigbee/BLE. Причому звісно ж прямого шляху це зробити немає — потрібний принаймні якийсь API. А в Thread координатор мережі є простим шлюзом, що займається тільки маршрутизацією. Йому, наприклад, не потрібно знати зміст повідомлень, або розуміти призначення пристроїв. По-перше, так безпечніше, по-друге, шлюзи Thread мають кращу сумісність між виробниками.

З усім тим, Thread стандарт відносно новий (2014 року) та пристроїв з ним значно менше, ніж із Zigbee. На щастя, принаймні вони можуть ділити один радіомодуль, тож можна очікувати більше пристроїв з подвійним стандартом. Субʼєктивно це кращий протокол, але чи він переможе — покаже час.

(Бачите, це не зовсім так, що “було 10 стандартів, додали ще один”. Еволюція простежується.)

15.04.2025

AWS та GCP: не такі вони вже й схожі

Я вже років 8 працюю з AWS, а от з Google Cloud Platform довелося стикнутися навсправжки тільки цього року. До того було хіба що Firebase та щось дрібненьке. Втім, в мене було переконання, що хмарна платформа — вона й в Гуглі хмарна платформа, та різниця хіба що в брендінгу та в назвах. (Ну, до речі, в хостингу для VPS дійсно майже так і є, тому було з чого так думати.)

Зате коли довелося налаштовувати авторизацію з AWS в GCP, вмочив ноги в гуглівську модель авторизації. А там… все зовсім не так, як я звик. В AWS доступ до ресурсів оголошується документом-політикою, де перелічені ресурси та дозволені операції з ними. Ну може декількома політиками. Але я легко можу побачити, до чого є доступи в конкретного користувача чи ролі.

А в Google… ну я, звісно, не експерт. Але тут доступи призначаються зі зворотного боку — з боку ресурсу. В Terraform для того є ціла купа окремих ресурсів на кшталт google_storage_bucket_iam_policy. Та ще й існує якесь успадкування. Та сервісні акаунти. Зовсім інша модель, одним словом, та майже ніякі знання з AWS не переносяться.

Тепер, нещодавно також довелося налаштувати на GCP проксі. Та знову, я звик, що в AWS є Балансувальник, а в нього є Слухачі, які направляють запити до Групи Цілей. А на GCP є Глобальна Адреса, Проксі, Відображення URL, та Бекенд-Сервіс. Я тут теж не знаюся, тому реально довго шукав, які взагалі ресурси мені потрібні та як вони називаються. Зокрема те, що в UI є Load Balancers, а в Terraform просто нічого схожого немає. Виявляється, що ото ці Load Balancers збираються з цілої купи абстракцій.

Так що не варто поспішати зі спрощеннями, поки досвіду немає. Зате, раніше я думав, що AWS надто заплутаний, а тепер здається, навпаки по-людськи зроблено.

14.04.2025

Болюча збірка "застарілого" застосунку на React Native

Потрібно мені було зробити свіжу збірку мобільного застосунку для Сінтри, яка наразі в розробницькій паузі. Та React Native там застарів аж майже… на 2 роки! Ціла вічність просто. Звісно ж, зі свіжим XCode 16.3 він не зібрався (чотири місяці тому на 16.2 ще збирався.)

Це не вперше з ним таке — десь в коді залежностей на С++ вилазить несумісність, яку, звісно, згодом виправляють, але тільки для нещодавніх версій.

Я чесно кажучи не знаю, чому воно так нестабільно себе поводить. Чи це всі проєкти на C++ так, чи то через розробників, чи то тому, що RN не типовий продукт на iOS та потребує особливих обходів.

Почав оновлювати… а там така круговерть. Спочатку RN, потім Node, потім просто React, Babel, React Native Navigation… В якийсь момент Yarn почав відвалюватися за браком памʼяті, що є поганим знаком.

Зрештою зʼясувалося, що оновлення взагалі не можливе, бо React Native Navigation не підтримує поки навіть найстарішу версію RN, яка була виправлена для XCode 16.3. Фініш?

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

І тут несподівано знайшов, що стару версію XCode можна поставити й на мою машину! Осьо сайт Xcode Releases, де є посилання навіть на доісторичні версії. Тобто встановив собі поруч /Applications/Xcode 16.2.app та на ньому, ще після кількох чомусь потрібних виправлень все зібралося.

Гадаю, Apple ускладнили розробникам життя тим, що XCode встановлюється з App Store та через це неочевидно, що старі версії взагалі можна знайти. А виявляється, навіть asdf-xcodes є!

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

13.04.2025

Протоколи розумного будинку: Zigbee

Нарешті, дісталися до першого протоколу, який не є широко відомим. Мені він взагалі, плутався, здається, з помічником від Самсунгу, якого звати (перевірив) Біксбі. Втім, Zigbee - це зрілий протокол для домашніх мереж. Вийшов ще у 2005 - я трохи здивований, що тоді вже була ідеї про розумні будинки… хоча, певно, цій ідеї десь тільки ж років, скільки електрифікації.

Головних аспектів тут два. Zigbee не потребує постійно увімкненого радіо (як і BLE), тобто дозволяє використання в пристроях на батарейках (довгий термін роботи від батарейок — це навіть вимога до пристроїв.) Та Zigbee підтримує ретранслятори, тобто покриття мережі можна збільшити. Ще краще — всі нормальні пристрої, що підʼєднуються до електропостачання, також виконують функцію повторювача. Та, виходить, кожний додатковий заживлений пристрій з Zigbee підсилює надійність мережі. Це дійсно визначна особливість.

Але так, Zigbee потребує центрального вузла — координатора, так його доведеться придбати окремо. Або, наприклад, для HomeAssistant є адаптер USB. Для одного вимикача це трохи забагато витрат, але я от переконався, що коли братися за розумний будинок серйозно, то це цінна інвестиція. Бо, як бачите, Zigbee з кількістю пристроїв стає тільки краще.

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

12.04.2025

Протоколи розумного будинку: Bluetooth

Як і про Wi-Fi, про Bluetooth всі знають. Це йому не на користь, бо насправді Bluetooth це два різних протоколи.

Є “класичний” Bluetooth (так і називається - Bluetooth Classic.) Він спроєктований для передачі даних між двома пристроями (може хтось памʼятає, як у 2000-х з телефона на телефон “скидали пісню”) та прижився для аудіоапаратури. Він практично не має сенсу для розумного будинку, бо витрати енергії для нього досить високі, до того ж один сервер може підтримувати звʼязок тільки з 7 клієнтами.

Та є Bluetooth Low Energy - це абсолютно інший протокол. Спільного зі “класичним” Bluetooth тут тільки використання тих самих радіочастот, через що він підтримується тими ж самими пристроями (це називається Bluetooth 4.0) - наприклад, смартфоном чи компʼютером. А вийшов Bluetooth 4.0 ще у 2009, так що в ньому нічого нового, та багато з наших пристроїв використовують саме BLE.

Різниця в тому, що BLE не потребує постійно увімкненого радіо, отже, периферія може не вмикати радіо аж допоки не потрібно буде щось надсилати. Це є й головна перевага над Wi-Fi. Також в BLE прибрали обмеження на кількість клієнтів, що для розумного будинку дуже важливо.

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

Проблемою Bluetooth є модель “зірка”, тобто всі пристрої повинні підключатися до центрального. Що, звісно, обмежує покриття. У 2017 вийшов стандарт Bluetooth Mesh, який дозволяє використання ретрансляторів. Хоча поки його наче підтримує небагато пристроїв.

Bluetooth можна побачити у всіляких датчиках та кнопках, які не підключені до електромережі. Звісно, для інтеграції таких пристроїв доведеться знайти адаптер Bluetooth, або скористатися тим, що вбудований в компʼютер.

11.04.2025

Протоколи розумного будинку: Wi-Fi

Почнемо мінісерію. Я багато чого тут вивчаю вперше, тож якщо у вас краща інформація — виправляйте! :) Мені, головне, для себе хочеться розуміти, в чому різниця. Бо різниця абсолютно є, і не тільки в назві. Тут як з меблями: чому є стільки пласких меблів? якщо в мене вже є стіл, чи потрібно мені ще ліжко? та й взагалі, якщо вже є підлога, хіба це не найефективніша поверхня?

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

Головний конструктивний недолік Wi-Fi - це високе споживання енергії. Бо клієнти Wi-Fi завжди повинні бути “на звʼязку”. Через це практично будь-який пристрій повинен бути підʼєднаний до електрики (або часто заряджатися.) З цим, звісно, можна жити, тільки пристроїв без дроту не знайдеш.

Не менш важливо, що Wi-Fi підʼєднує всі пристрої до локальної мережі, а напевно — й до інтернету. Інколи це плюс, проте також може відкрити двері для шахраїв, які отримають доступ не тільки до самого пристрою, а й до всієї мережі. Бо Звісно, від цього можна відмежуватися, але це змушує нас власноруч забезпечити систему від світу.

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

Раніше

Пізніше