#CтохастичнийТаймтрекер

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

Це все не я придумав — йдеться про TagTime - зроблений чимало років тому розробниками сервісу Beeminder. TagTime має вигляд купки скриптів на Perl та, відповідно, здатний працювати тільки на десктопі.

А в мене ідея зробити застосунок для Apple Watch та скористатись повсюдністю годинника. У WatchOS є така цікава можливість. як long look для повідомлень — фактично цілий інтерактивний екран, доступний безпосередньо при перегляді сповіщення.

До того ж використання бази даних CloudKit та універсальності SwiftUI дозволяє легко зробити застосунок, в який можна заносити з десктопу, з телефону чи з годинника — де зручніше. А інтеграція Apple Health може автоматично логувати сон та тренування. Причому виглядає так, ніби все це не потребує багато зусиль, динамічного програмування і так далі. Ну, подивимось.

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

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

Одним з таких джерел є Apple Health. В базі Health зберігається журнал сну та тренувань. Для збереження принципу випадковості я не можу просто скопіювати їх у трекер. (Нагадаю, що трекер будується на тій ідеї, що історія станів у випадкові моменти дає репрезентативну статистику.) Доведеться знайти ті (випадково заплановані) пропущені записи, що припадають, наприклад, на сон, та помітити їх як сон.

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

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

• Заносити записи легко, навіть без застосунку на Apple Watch. Поки є тільки застосунок на телефон, але випадків, коли телефона немає поруч, а можливість скористатися годинником є, дуже мало. На практиці я встигаю записати понад 90% записів. Якщо відразу не запишеш, потім часто це стає неможливим, оскільки…

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

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

• Вплив на свідомість: відсутність передбачуваності пінгів та потреби власноруч заносити час призводить (може призвести) до загальної підвищеної усвідомленості — не заради трекера, а заради себе. Коли памʼятаєш, що в будь-який момент може прийти пінг та доведеться записати “читаю новини”, то не так вже й хочеться багато часу на те витрачати. (Але, також буває прикро, коли три години працюєш невпинно, а пінгів немає. Не пощастило. Але не в пінгах сенс.)

Поки експеримент мені подобається, далі буде.

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

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

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

Одне діло думати “я надто багато часу сиджу в телефоні”, та зовсім інше — бачити, що сидіння в телефоні у топ-10 активностей за тиждень (топ-1 виходить “сон”, до речі, а топ-2 “сидіння за компʼютером”… теж є над чим подумати.) Причому це більш точний показник ніж функція телефону “екранний час”, бо тег “в телефоні” значить, що я буквально в цей час дивився в телефон… відмазок немає.

Зате з позитивного — я більше часу проводжу з сімʼєю, ніж уявляв. Тут теж, СтохастичнийТаймтрекер здатний виміряти те, що я б ніколи не записував традиційним чином (підійшов до сина — відкрив Toggl - увімкнув таймер… бррр.) Навіть більше, ніж сиджу в телефоні! (Хотілося б, щоб це було очевидно, але такі вони, наші часи.)

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

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

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

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

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

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

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

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

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

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

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

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

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

Цікаво побачити, скільки часу уходить на побічні активності; обовʼязки як перегляд PRів здаються такими що відбирають багато часу, але на практиці витрати мінімальні. Хоча це нічого не каже про ментальне навантаження — можливо, в майбутньому почну відстежувати і його рівень.

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

Все ще й ускладнилось тим, що в SQLite якось дивно розподілені команди форматування: в старих версіях є тільки %W - номер тижня, що починається з понеділка, та %w - номер дня, що починається з неділі. А в нових додали протилежні ним %U та %u. Та той SQLite, що є на iOS, ще старий.

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

Натомість просто додав до пінгів стовпчики weekCode, weekday та ще парочку. Оскільки дата не змінюється, то залишається один раз їх заповнити — та можна забути про всі ті запити із strftime.

Що таке weekCode? Комбінація року та номеру тижня: 202451. Тут, до речі, дізнався ще про один нюанс — що звичайного %Y тут недостатньо, бо тиждень 202501 почався 30 грудня 2024. Тобто потрібний “рік, до якого призначено цей тиждень”, та у Swift навіть так і називається: DateComponents.yearForWeekOfYear.

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