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

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

05.01.2025

JSON-бази для простих застосунків

Я якось писав, що використовую JSON для зберігання даних мого застосунку для GTD. Застосунок досі живий та я ним користуюся постійно, тож JSON виріс та займає цілих… 120 кб!

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

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

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

Гадаю, все залежить від того, як часто вам потрібно читати чи писати в базу. Якщо читання відбувається під час запуску застосунку, а запис — на дії користувача, то JSON вам (як і мені) вистачатиме надовго.

04.01.2025

Моя спроба зробити Undo/Redo

Був в мене проєкт застосунку для самоменеджменту… який не досяг успіху через відсутність бачення. Втім, рушій я для нього нагородив досить потужний. Застосунок був на React Native, а стан зберігався у базі PouchDB, яка синхронізувалася з сервером CouchDB. Для мене, як я вже писав, CouchDB досі залишається потужною, але нішевою технологією без зрозумілого застосування — приблизно як Clojure.

Отже, механізм Undo/Redo, тобто “скасувати/повторити”. Зазвичай його складність полягає в неоднорідності операцій зі станом. Так, в багатьох (чи усіх) застосунках текстові операції є скасованими, але спробуй змінити блоки, що містять той текст — наприклад, задачі — та можливість скасування втрачається.

CouchDB тут має корисну властивість. Документи в ній мають ревізії, та старі ревізії зберігаються поруч з новими. Це потрібно для реплікації. Є схеми, де реплікуються зміни, а ось в CouchDB реплікуються цілі ревізії. Таким чином, досить довго можна прочитати стару версію документа. Навіть видалення відбувається через нову ревізію з маркером _deleted. Тому: всі дії в моєму проєкті проходили через єдину операцію put, а також — я завжди мав доступ до старих ревізій всіх документів.

Але очевидно, для користувача інтерфейс повинен бути вище за скасування “документ за документом, ревізія за ревізією”. Тому всі функції-дії, що потребували скасування, загорталися в функцію withUndo та отримували всередині особливу реалізацію інтерфейсу DBEffects, яку потім передавали усім операціям з базою. А інтерфейс DBEffects складався з єдиної функції put… з Undo вона не тільки писала в базу, а й складала перелік документів та їх ревізій до об’єкта, створеного в функції withUndo. (Звісно, через put були реалізовані звичайні create, update, delete і так далі.)

Потім, щоб скасувати останню дію, я брав крайній обʼєкт з переліку дій, та вертав назад попередній стан порушених документів. Ось так просто. (Ревізії утворювались нові, до речі, бо як і в Git, старі дані не можна змінити.) Та це дійсно працювало з будь-якими змінами, від примітивних до складних.

03.01.2025

Що робить інтерфейси "дорогими"?

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

🍃 Дрібні анімації. Практично кожний елемент інтерфейсу може мати анімації переходу, але робити їх зазвичай важко.
⚠️ Змістовні повідомлення про помилки. Не “невірна сума”, а “сума повинна не перебільшувати 66.00”, а ще краще “у вас в гаманці залишилось 66.00 на витрати”.
⏳ Видимий стан внутрішньої активності. Коли застосунок робить запити до сервера, або щось обчислює, зробити це помітним та зрозумілим. Як бонус: результат на завершення — теж. Від операцій, що тривають секунди, до багатогодинних.
🔙 Можливість скасувати зміни. Навіть найкрутіші застосунки не можуть цього собі дозволити в повному обсязі. Між іншим, я колись намагався це зробити з Redux/CouchDB - та щось навіть виходило. От тільки проєкт не злетів. Треба буде про це написати.
🐣 Обробка виключних ситуацій. Найперша з них — порожній стан. Але інтерфейси просто складаються з виключних ситуацій. Наприклад, коли предмет один, або коли їх значно більше, ніж заплановано. Коли назви довгі, а статті короткі. Коли світлина прямокутна, а не квадратна. Далі та далі.
🇺🇦 Переклад. Потребує величезних інженерних витрат, а потім ще й власне перекладацьких. А ще й локалізації — правильного відображення кількостей та значень. А потім ще й підтримки. Втім, це найбільш практична “розкіш” з переліченого.

🥳 PS: стохастичний таймтрекер вже доступний для бета-тестування, доєднатися можна за посиланням.

02.01.2025

Мій власний Steam Replay, або в що я грав у 2024 році

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

…Насправді зі звітом все складніше. Те, що ви бачите — це я, після першого поганого досвіду, обрав топ-10 ігор. Бо там ще купа дрібних записів на 1-2 години, які вже перетворюють графік на шум. В кольорах розібратися неможливо. (Гадаю, треба відразу автоматично залишати на графіку топ-10.)

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

…А тепер, до результатів. BG3 я так і не пройшов; досяг level cap та стало якось не цікаво. Сталкер здивував; але його поки теж закинув. Evil Within 2 - нудьгуватий, але компетентний. Hades - екшн-Roguelike з безліччю цікавих комбінацій. Echo Night Beyond на PS2 - гра випередила час, вигадлива, але логічна адвенчура від першого лиця. Ashes of the Apocalypse - вже писав, бумер-шутер з мистецьки зробленим світом.

Dread Delusion - не закінчив, але все ще планую, це як King’s Field з відкритим світом. Morrowind - цього року досліджував Tamriel Rebuilt. Rule of Rose - ще одна гра на PS2, SIlent Hill 2-like в цікавому сетінгу. Cyberpunk 2077 - а ви знаєте, що з виходом доповнення вони повністю переробили всю рольову систему та лут? Я таке вперше бачу.

Нагадаю, що вся ця статистика зібрана моїм стохастичним таймтрекером, який ось-ось можна буде завантажити в TestFlight… як тільки відділ підтримки Apple виспиться.

01.01.2025

Застосунки за замовчуванням: 2025

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

📨 Поштовий клієнт: MailMate
📮 Поштовий сервер: Fastmail
📝 Нотатки: Obsidian 📝 та Drafts 📝
✅ Задачі: мій власний застосунок CoreGTD
📷 Фотографування айфоном: звичайна камера, але в складних ситуаціях (як ручний фокус) також Halide.
🟦 Керування світлинами: Apple Photos
📆 Календар: Apple Calendar та Dato
📁 Хмарне сховище файлів: Apple iCloud
📖 RSS: Reeder Classic та Miniflux. 📝
🙍🏻‍♂️ Контакти: Apple Contacts
🌐 Браузер: Safari :)
💬 Спілкування: там, де контакти. Але будь моя воля, певно залишив би тільки Apple Messages.
🔖 Закладки: Obsidian. Просто закладки “окремо” я не люблю.
📑 Список читання: Reeder Classic 📝
📜 Текстовий процесор: Apple Pages, я не вибагливий :)
📈 Табличний редактор: Apple Numbers :)
📊 Презентації: давно не робив, але Deckset.
🛒 Список покупок: Apple Reminders
🍴 Планування їжі: рецепти мої у Paprika, а не мої — в NYT Cooking. 📝
💰 Особисті фінанси: якби вів, то в нашій Сінтрі. 📝.
📰 Новини: знову Reeder та RSS 📝
🎵 Музика: Apple Music
🎤 Подкасти: Overcast
🔐 Паролі: 1Password 📝
👨‍💻 Редактор коду: VSCode
🔣 Термінал: Fish, а емулятор - в тому ж VSCode
🎨 Графічний редактор: Pixelmator.

31.12.2024

Дев-адвент 31: воно живе!

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

⏰ Зупинився на короткій назві: Ping!. Насправді я цю назву бачу вже місяцями як заголовок сповіщення, та нічого кращого не уявляю. Значок застосунку все ще тимчасовий.

Так що сьогодні я ще встиг перейменувати всі ресурси застосунку, а ще змінити назву моделі Sample на Ping. Це майже тривіальна заміна по коду, єдине, що довелося експортувати та наново імпортувати власні дані в новий застосунок (бо перейменування — це ж фактично створення нового застосунку.)

🚚 Багато чого ще залишилось доробити. Я не планую зупинятися, хоча точно доведеться приділити час іншим справам (та іншим темам для каналу, хе-хе.)

🧪 Доєднатися до TestFlight можна за посиланням. На жаль, про що я забув — перед розповсюдженням застосунку на TestFlight він повинен пройти перевірку від Apple. Тому посилання наразі не пускає. Не впевнений, що це відбудеться сьогодні, але як тільки пройде перевірку, так відразу й посилання запрацює. 🧘

❄️ З прийдешнім Новим Роком вас!

30.12.2024

Дев-адвент 30: TipKit

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

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

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

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

29.12.2024

Дев-адвент 29: онбордінг та поради

🏁 Десь нещодавно чув — можливо, в документалці до 20-річчя Half-Life 2 (яку я всім раджу подивитись задля цікавих продуктових історій) - що перший рівень гри варто робити останнім, коли всі механіки та підходи вже пропрацьовані. Бо перше враження — головне, тож варто зробити його найсильнішим.

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

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

🗃️ Але “тестова проба” була функціональним баластом та тільки створювала ускладнення (наприклад, її треба прибирати з усіх статистичних запитів.) Тому знайшов кращий спосіб: під час першого запуску я буду генерувати до тижня старих проб. З ними можна не тільки погратися, а й зрозуміти частоту проб, випробувати автозаповнення з Apple Health (та запросити дозвіл для нього!) та отримати перші результати.

💬 Також випробовую TipKit. Це цілий фреймворк для підказок. Не просто для того, щоб їх показати (але це теж), а відстежити, які підказки вже були закриті, а також в який момент їх пора показати. Наприклад, підказку про улюблені теги має сенс показувати, коли тегів буде принаймні 5. Цікавий взагалі фреймворк — адже підказки потрібні всім.

28.12.2024

Підсумки року: я та час

🎆 Для мене 2024 рік відзначився парою помітних проривів у стосунках з часом.

Перше — це робота зі стохастичним таймтрекером, який я заповнюю 100% часу починаючи з лютого. Те, що він нагадує про себе у випадковий момент, вже приносить усвідомленість. (Існують навіть пристрої, весь сенс яких — це в випадковий час нагадати про “зараз”.)

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

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

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

Головна ідея GTD, як на мене: що всі свої справи треба викласти з голови, а потім достатньою мірою пропланувати.

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

27.12.2024

Дев-адвент 27: рушії рекомендацій

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

Важливо розуміти, що саме потрібно рекомендувати. В цьому випадку — такі теги, що будуть ймовірними для проби, яку ми заповнюємо. Досить складне завдання, бо з умовних 500 тегів це тільки 3-4. Та на відміну від рекомендацій покупок, тут практично немає вибору користувача: або вгадаємо, чим він займається, або все марно.
Влучні рекомендації краще за пошук, так. Але погані рекомендації точно гірше за пошук, бо створюють погане враження, та ще й місце займають та звертають увагу. Знаєте відчуття, коли купили пилосос, а магазин рекомендує купити ще один пилосос? Так саме й тут.
З використання спостерігаю два частих випадки. Або повторюю теги попередньої проби (якщо заняття триває). Або в голові зʼявляється набір тегів та його легше швидко знайти та відмітити, ніж переглядати список рекомендацій. Ще є третій випадок — коли вже вказав один тег, то за ним випливають інші; наприклад, з тегу робота випливає в 95% тег десктоп.

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

Так що намальовується такий UX: починаємо пропозиції з попереднього / наступного запису (можна навіть 2-3 попередніх). Після того, як обрані теги, рекомендуємо суміжні. Отак буде зручно, та не потребуватиме складного рушія. Бо я вже почав вигадувати “програмістське рішення”, де буде складний багатофакторний алгоритм.

Раніше

Пізніше