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

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

09.01.2024

Ціна виправлення помилки

Скільки разів ми чули історію про знамениту помилку, що була виправлена одним рядком? Ну, наприклад, класична відсутність значення там, де воно очікується. Чи був той рядок приречений стати великою помилкою, коли його писали?

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

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

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

Як уникнути простих помилок? Я думаю, тут нікого не здивує, що я бачу вихід в типізованих мовах: вони як раз запобігають тривіальним помилкам. Але це моя особиста пристрасть.

08.01.2024

Цілочисельні типи в Go: int проти int64

В Go, як у системній мові програмування, є ціла низка цілочисельних типів з явно заданим розміром: int8, int16, int32, int64 (Є ще типи без знаку - uint8 і так далі — але то зараз не важливо.)

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

В Go ми вільні обрати те число, яке нам потрібно. Але… також можемо взяти тип int, який, в залежності від платформи, має розмір 32 або 64 біти. Ми знаходимося посеред довгої епохи 64-бітових чисел. Вони всюди, від телефонів до суперкомпʼютерів. Тому, у 100% практичних випадків, int та int64 це один та той самий фізичний тип.

Коли брати int8, int16, та int32 більш-менш зрозуміло: або для відображення зовнішніх значень з чітко заданим розміром, або коли потрібно заощадити на розмірі великого масиву даних. В інших випадках економія не виправдана, бо процесор швидше за все працює зі словами своєї “рідної” довжини, тобто int64.

Але як щодо int та int64? Що краще? Тут є декілька аспектів. Перше — типи все ж не сумісні на синтаксичному рівні та потребують явної конвертації. Друге — константи мають тип int, змінні, що ними ініціалізовані — теж. Так само len має тип int. Третє — офіційний посібник радить вживати int, якщо немає “особливої причини” на int64.

Яка то може бути “особлива причина”? На мою думку, так само як з меншими типами, int64 має сенс там, де розмір числа заданий ззовні. Коли ми читаємо (або пишемо) число з бази, чи з файлу, чи отримуємо з інтернету — розмір залежить вже не від нас — значить, int64 правильний вибір.

07.01.2024

Як записувати розвʼязки

Перелічи кроки, які довелося зробити. Це можуть бути просто інструкції для людини. Може, консольні команди. Якщо йдеться про написання коду, може модулі, які створив чи редагував. Зазвичай перелік починається з мінімальних нотаток, а наскільки їх розкривати — залежить від аудиторії.
Якщо знайшли крок у зовнішньому джерелі — статті, StackOverflow - не забуваємо посилання; коли наступного разу будуть питання, повернемось туди.
Для кожного неочевидного кроку — пояснення: з якого розуміння вийшов саме такий крок. Потребу визначаємо самі, так би мовити, за “принципом сюрпризу”: якщо щось здивувало, потрібно записати.
Також не забудь про неуспішні спроби та напрямки. Після того, як витратив багато часу, та все одно не вийшло — мусиш занотувати, щоб наступного разу не повторити.
Особливо якщо є очевидний або “простий” шлях, який виявляється нежиттєздатним пізніше, обовʼязково потрібно про це записати. В мене зазвичай це виходить на другому підході — читаєш документацію — думаєш “навіщо воно так складно?” - через пару годин розумієш, чому. Потім пишу собі: “ні, так робити не треба, бо А, Б, В”
Так, до речі, кожного разу як документ використовується, варто оновити його тими деталями, які раніше були невідомі, або просто додалися через зовнішні зміни.

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

06.01.2024

Записуй свої розвʼязки

Задокументував встановлення DietPi, про яке писав два дні тому.

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

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

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

Що я хочу сказати. Записуй свої розвʼязки. В Obsidian, в корпоративну вікі, в коментарі в коді, в блог… головне, щоб не тільки в голову.

05.01.2024

Домашній сервер: HomeAssistant, Pi-Hole

Сьогодні закінчив з налаштуванням HomeAssistant. Бо, хоч він в мене вже був, оновлення за чотири роки потребує низки змін. На щастя, нічого складнішого, ніж редагування конфігурації.

Розумна розетка (Meross) підʼєдналася в Home Assistant теж без проблем. Власне, до розетки підключений витяжний вентилятор (української фірми Vents), який сам по собі розумний — вмикається при наявності вологості в ванній. Але, чого вентилятор не вміє — це вимикатись за розкладом.

А мені не хотілося, щоб він вмикався вночі. Тут і допомогла розумна розетка — коли вона вже є в HomeAssistant, то додати роботу за розкладом це справа на пару хвилин. Та й витрати невеликі - 200-300 грн за розетку, причому є варіанти на декілька розʼємів, так виходить економніше.

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

З DietPi Pi-hole встановлюється дуже просто. Залишається вказати його як DNS сервер на роутері — на моєму Asus навіть є така функція DNS Director, щоб зробити використання Pi-hole примусовим через перенаправлення всіх DNS запитів на нього.

04.01.2024

DietPi: свіжа начинка для ODroid

Колись давно писав, що в мене налаштований Home Assistant. Для цього в мене є мікрокомпʼютер Odroid XU4. Він мене влаштовує настільки, що у 2022 я навіть замовив для нього цільно алюмінієвий корпус, з яким вистачає пасивного охолодження.

Але… проблема в тому, що остання офіційна версія ОС для Odroid XU4 вийшла у 2020. Та в ній, окрім іншого, застарий Python - на якому відмовляється працювати свіжий Home Assistant. А це значить, що плагіни теж втрачають сумісність, тож потроху система перестає працювати. Нарешті, після придбання нової розумної розетки, плагін для якої не можна було встановити, пішов на радикальне оновлення системи.

Мав на прикметі збірку під назвою DietPi. Це сучасний Debian з образами для всіляких мікрокомпʼютерів. Ще там є зручний конфігуратор (наприклад, можна легко змінити тепловий профіль процесора) та репозиторій ніби “оптимізованих” сервісів. Але то поки не можу оцінити.

З встановленням були деякі проблеми, про які розгорнуто тут не буду, але: спочатку ніяк не міг запустити новий образ з eMMC; потім зрозуміти, як оновити версію ядра, бо система встановлюється на приєднаний SSD (причому за замовчуванням — це величезний плюс!) - а ядро та завантажувач залишається на eMMC.

Після розвʼязку цих задач, все нарешті завелося та працює. Встановити Home Assistant на DietPi легше, ніж просто на ODroid (де все робилося вручну.)

Одним словом, дуже задоволений, хоч встановлення потребувало досвіду.

03.01.2024

Weightplot: запуск та сайт

Нарешті, вчора WeightPlot пішов в маси: ось сторінка в AppStore (готовий поділитися промокодом). Щоб це здійснилось, вчора розробляв сайт.

Бо, як писав минулого разу, сайт мусить бути, це обовʼязкова вимога до всіх застосунків в App Store. Тож, окрім розробника, доведеться попрацювати маркетологом.

Спочатку хотів зробити сайт чисто на HTML. Проте, згадав, що я збираюся накидати туди хоч декілька статей — для розʼяснення та для SEO - то все ж взяв рідний Hugo та зробив на ньому.

Щоб впоратись за день, відшукав готову тему. Зазвичай не люблю брати готові теми, але, оскільки сайт грає другу скрипку, то це має повний сенс. Обрав тему Paige. Вона побудована на Bootstrap, та тому дозволила доробити все, що потрібно — наприклад, табличку функцій.

Проблеми зʼявилися з деплоєм на Vercel. Річ у тім, що теми на Hugo тепер встановлюються як… модулі Go. Що, як на мене, дуже дивно. А на Vercel взагалі з цими модулями відбувається щось дивно, та я за кілька годин так і не зрозумів, що. На щастя, є тупе, але ефективне рішення: будувати сайт локально, комітити, та залишити на Vercel тільки хостинг.

Взагалі, цінуйте роботу відділу маркетингу. Бо без нього все, що інженери наробили, просто нікому буде невідомо та не потрібно.

02.01.2024

Реверс-інжинірінг пріоритетів з розкладу

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

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

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

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

Тоді, може, потім зʼявиться час зробити щось нове, пріоритетне.

01.01.2024

2023: Роздуми року

Якщо виділити думку року, то це: існує осяжна межа того, що можна встигнути зробити за рік. Є роки, коли відчуваєш, що можна було постаратися та зробити більше. Однак 2023 - рік, коли я наблизився до межі можливого.

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

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

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

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

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

31.12.2023

Дев-адвент 31: випускаємо!

🥂 Нарешті застосунок готовий до випуску в App Store. Фаза щоденної розробки закінчується.

Щоб випустити застосунок, окрім власне програми ще багато всього треба наробити. Скриншоти з різних моделей айфонів — принаймні два набори — без кнопки “Додому” та з кнопкою. Опис, звісно. Всілякі анкети ставлення до приватності та обмежень по віку.

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

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

Раніше

Пізніше