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

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

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

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 - то гарний початок розумного будинку, але ж ми не будемо спати на підлозі?

10.04.2025

Коли та як документувати код?

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

Чому? Бо кожний клас та кожний атрибут був пояснений влучно, але не багатослівно. Рівно стільки, щоб зрозуміти, що він робить. Всупереч цьому, зазвичай я бачу приблизно нуль документації, а коли її все ж багато, то вона скочується в тавтології на кшталт “ID це ідентифікатор продукту”.

Тоді коли корисним коментарем було б (уявне) “ID продукту, унікальний в межах облікового запису” - тобто щось таке, що код нам прямо не скаже, але ми б хотіли дізнатися.

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

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

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

09.04.2025

4 способи пришвидшити збірку CI на 10 секунд

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

Зменшити кеш. Ні, серйозно, якщо у вас 500 Мб зайвого кешу, то достатньо його прибрати та збірка стане швидшою. Де взяти 500 Мб зайвого кешу? Наприклад, в тимчасових артефактах гему grpc (про що можна окремо розповідати.)

Навпаки, додати кеш Ну от кешуєте ви пакети, які завантажив yarn. З них можна повністю відтворити node_modules. Але то буде довго! Швидше самі node_modules теж закешувати. Відновлення кешу не моментальне, але швидше за yarn install.

Не робити зайвих анотацій Ясно, перед тестами потрібно промігрувати базу. А після міграцій автоматично запускається анотація моделей. Зручно локально. Абсолютно зайве на CI. Вимикаємо анотації — та замість 21 секунди міграції проходять за 11.

Можна спитати — а кому ті 10 секунд важливі? Самі собою, згодний, нікому. Але якщо 6 разів по 10 секунд - то це вже хвилина. А коли це хвилина паралельної збірки в 10 потоків - то вже 10 хвилин оплачуваного часу. А також одна хвилина, яку ніякою кількістю потоків не пришвидшиш. Так що інколи варто й на 10 секунд пришвидшувати.

08.04.2025

Valetudo - відв'язання пилососа від інтернету

Роботи-пилососи — це революційний винахід. Але мені зовсім не хотілося мати в хаті вебкамеру на колесах. На щастя, існує аматорський проєкт Valetudo, який для деяких моделей пилососів здатний прибрати привʼязку до хмари — так, що навіть офіційного застосунку не доведеться встановлювати.

Що воно таке? Дві окремі зміни. Спочатку рут, тобто відкриття адміністративного доступу. Взагалі пилосос то маленький компʼютер з Linux, тільки ще й на колесах. А потім прямо на пилосос встановлюється Valetudo - сервер, який заміняє хмару. Все забезпечення пилососа залишається без змін. Тобто тут не буде такої ситуації, коли встановлюєш деяку ОС та залишаєшся, наприклад, без блютузу. А от в UI, певно, можуть бути відставання, хоча на мій недосвідчений погляд все добре. Також, зауважу, для Valetudo не потрібно ніякого додаткового домашнього сервера, бо пилосос стає сам сервером — як для себе, так і для керування. 🤯

Пилососи. Тут є цілий список, але також є нюанс. Більшість моделей потребують складної розборки. Найпростіший варіант це Dreame - для них потрібно тільки придбати розвідну плату. Хоча “найпростіший” тут дуже умовно.

Далі за інструкцією буде потрібний ноутбук з Debian. В мене знайшлася на ігровій машині Ubuntu другою системою. Завелося і з нею. Потім такі кроки лячні… я, мабуть, останній раз таке робив, коли прошивав книжки на свій Siemens C55. Лячні тим, що пилосос в “сервісному режимі” вимикається через пару хвилин, тому всі операції потрібно робити швидко, а не то пилосос стане цеглиною. 🧱

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

Коли вже є рут, то до пилососа можна підʼєднатись по SSH, та градус напруги спадає. Але Valetudo на пилососі ще нема. Далі інструкція каже підʼєднатися до Wi-Fi пилососа… та я розумію, що в мене машина без вайфаю. А там ще залишилося використати якийсь міст, який теж є тільки для Linux. (Та ще для Windows, але в мене вайфай тільки під macOS.) На щастя, міст тільки віддає файл по HTTP, та класична python -m http.server 7777 чудово покрила цю потребу.

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

07.04.2025

Покращення split_tests

Поки я згадав про свою утиліту для розподілу тестових пакетів split_tests, захотілося її оптимізувати — тобто зробити так, щоб вона розділяла тести на комплекти найрівнішої тривалості.

На початку вона використовувала жадібний алгоритм. Сортуєш файли за зменшенням часу. А потім береш по черзі та додаєш до найменшого досі комплекту.

Це чудово, але всі знають, що жадібні алгоритми неефективні. Дослідив цю тему. Виявилося, що задача має назву планування ідентичних машин та вже має декілька розвʼязків. (Хоча і є NP-складною.)

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

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

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

Втім, новий алгоритм причешу та опублікую: може, в когось інші обставини.

06.04.2025

Чим покращити свій досвід роботи з SQL?

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

Навчитися робити розрізи. Розріз (View) - це фактично збережений запит. Ззовні виглядає як таблиця. Якщо у вас складний багатоповерховий запит, можна його декомпонувати — винести з нього розрізи, та тоді кожний етап буде легше зрозуміти окремо.
Навчитися використати CTE CTE - Common Table Expressions (“спільні оголошення таблиць”, певно) - як розріз, але оголошений в межах поточного запиту. Це перший крок до структурованих запитів. Спочатку через WITH оголошуєш допоміжні запити, а потім в головному запиті використовуєш як звичайні таблиці. Чомусь вважається просунутою технікою SQL, хоча насправді в CTE немає нічого складного.
Опанувати параметризовані запити. Чого точно не варто робити, так це будувати SQL шаблонами. По-перше, це небезпечно. По-друге, параметризований запит (Prepared statement) дає БД можливість відстежувати та оптимізувати повторювані запити, навіть коли їхні параметри змінюються.
Тести! А чом би й ні? Побудували дані, перевірили результат. Звісно, легше це робити, коли не потрібно кожний стовпчик заповнювати явно. Тому в Go мені з цим важко, зате в Ruby - легко. Сьогодні дізнався, що й тести безпосередньо для СКБД теж існують — наприклад, pgTAP для PostgreSQL.

05.04.2025

Чи потрібний SQL, якщо є ORM?

Потрапила на очі фраза “хто ж пише SQL, коли вже н-цять років існують ORM?” Хотілося прокоментувати. Тут є цікавий розподіл.

Головна міць реляційних баз даних — це, власне, ота реляційна модель, яку ніхто (включаючи мене) досконало не розуміє. (Пропоную задати собі питання — про яке відношення йдеться?) Але суть в тому, що ми можемо обʼєднувати розрізнені факти, щоб отримати сукупний результат.

Наразі існує достатньо нереляційних баз, щоб побачити, що ця можливість не є універсальною. От в OpenSearch все, що ми можемо — це шукати документи за критеріями та агрегувати. Все інше — дорого (та реалізується тим самим пошуком.) У CoreData немає COUNT. В DynamoDB взагалі кожний запит треба задумати наперед.

А у реляційній базі всі дані доступні для поєднання. Роби з ними що хочеш. Причому поєднання ще й буде ефективним — це і є основна пропозиція будь-якої реляційної бази. Та хто працює з аналітикою, бачив ті кілометрові запити на SQL, які генерують звіт з двадцяти таблиць з усіх околиць компанії. (Користуюся нагодою прорекламувати наш продукт Coupler, який допомагає зібрати ті дані з розрізнених джерел.)

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

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

Раніше