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

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

03.11.2022

Огляд додатків карт, якими я користуюсь

🗺️📍🧭 Сьогодні весь день за кермом, тож замість коду розповім про карти. Картографія — моє маленьке хобі. Зроблю короткий огляд додатків, якими постійно користуюсь.

Apple Maps - карти за замовчуванням. В Україні не те щоб в них погана карта (бо вона від TomTom, це одна з найкращих карт), але їм просто не вистачає полірування. Добре, що вони є, але я майже ніколи їх не відкриваю.

Google Maps - справжні карти за замовчуванням (навіть в DuckDuckGo за ключем !map). Добрі й для навігації, і для пошуку обʼєктів (особливо корисним є те, що вони підсвічують цікаві райони жовтим). Що тут казати, немає нічого кращого. В загальному плані.

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

Organic Maps - найкращий клієнт OpenStreetMap. Це гілка додатка Maps.me, яка має відкритий код, та не має трекерів. Бо Maps.me колись купив мейлру, і після цього я був вимушений припинити їм користуватись, хоча програма дуже зручна, особливо в подорожах, бо зберігає повний функціонал без інтернету. Їй навіть можна користуватись для автонавігації та навіть через CarPlay.

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

02.11.2022

Тип "дата" та його відсутність у різних мовах програмування

📆⏱️🙅‍♂️ Просуваюсь з HealthKit проєктом. Черговий раз стикаюсь з відсутністю типу даних для календарного дня, на цей раз у Swift. Поки терплю.

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

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

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

Ось в Ruby є окремий тип Date і це чудово. Для JavaScript я зробив бібліотеку dayjs-date. А у Swift поки нічого не знаю, роблю як є.

А ще — чи знаєте ви, що можна в ActiveRecord створити модель, що буде працювати не з таблицею, а з вьюхою (view)? Працюватиме так само — з усіма вигодами Arel, асоціаціями та таке інше. Тільки, зрозуміло, без можливості збереження змін. Це може статися до нагоди, якщо будуватиме складні запити, або щоб показати їх в ActiveAdmin тощо.

01.11.2022

Организація нотатків у Obsidian

🪨📂🧊 Продовжуючи тему з Obsidian: для системи, що працює з простими файлами, можливостей організації тут багато.

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

Крім того, я створив теки для: проєктів; робочих нотаток; довідкових матеріалів; чернеток. Все це вже було в моїй базі нотаток, але без доброї організації. Раніше я спирався на теги, які в Obsidian, звісно, також є.

Тобто є три способи впорядковування нотаток: за директоріями; за тегами; та за посиланнями. У кожного свої переваги. Директорії чітко ділять базу і не перетинаються. Теги легко додати до будь-чого, і потім використати для пошуку (в мене є практика: якщо довго шукав деякий запис — потім тегнути його всіма ключовими словами, по якім він не знайшовся.) А якщо потрібно щось більш змістовне, завжди можна робити явні посилання між нотатками (з яких, до речі, Obsidian може намалювати граф.)

Про структуру: подивився, що таке канбан по-обсідіанівські. Дані для канбану зберігаються в одному файлі. Тобто технічно це особливий вигляд звичайного списку задач. Заголовки створюють стовпчики канбану, а власне задачі перетворюються на картки. Це значить, що можна відкрити весь канбан у Markdown, відредагувати, та повернутись назад — дуже зручно. Крім того, кожна картка канбану може посилатись на окрему нотатку з деталями та метаданими.

Відкриття дня — гра Frostpunk. Атмосферна стратегія про виживання міста у льодяній пустелі. Йде і на macOS, а ще зараз зі знижкою.

31.10.2022

Перші враження від Obsidian. Тести з Redshift.

🪨📓💫 Що ж, переніс нотатки в Obsidian. Перші враження дуже приємні, як вже писав, працює швидко, інтеграція з Git вбудована. Знайшов ще важливу властивість — при перейменуванні чи пересуванні нотатки всі посилання на неї будуть виправлені автоматично. Що стане до нагоди, коли я буду впорядковувати базу, для чого і шукав більш зручну програму.

Дуже зручно мати глобальну комбінацію клавіш для пошуку та додавання нотаток. Таку комбінацію можна створити програмою BetterTouchTool - для цього дія на комбінацію має бути “відправити ⌘+O програмі Obsidian, перед чим вивести її на передній план”.

По роботі писав та тестував SQL-скрипти, що мають працювати на AWS Redshift. Великий недолік Redshift - у неї немає локального емулятора. При цьому мова помітно відрізняється від Postgres - настільки, що тести для Postgres недостатні. Багато разів було таке, що навіть після ретельного тестування код не працював, і дізнавались про це тільки на стейджингу. Тому у нас на CI тести (RSpec) запускаються також і з Redshift. Це надзвичайно повільно — ця база не розрахована на транзакційні операції. Маю ідеї переробити тести на щось більш сумісне — наприклад, замість створення тестових даних на кожний тест окремо, підготувати базу для всіх тестів один раз.

30.10.2022

Перенос нотатків з Bear до Obsidian, перші враження

📓🐻🪨 Подивився більш уважно на Obsidian - додаток для збереження нотаток. Почав переїжджати (до того в мене все було в Bear і трошки невпорядкованого в Drafts.)

Чому саме Obsidian:

Працює зі звичайними файлами в теці. Це я люблю.
Але при цьому вміє показувати зображення. Також дуже цікаво, що він підтримує формат YAML Frontmatter, та за допомогою цих метаданих можна побудувати справжню базу даних на свій смак.
Мобільна версія існує та її можна синхронізувати через звичайний iCloud. Підтримує навіть плагіни.
О плагінах: їх можна писати на TypeScript. Тобто можна побудувати для себе автоматику, процеси та інше. Є, наприклад, плагін, що зберігає зміст бази в Git. Це зручно не тільки для резервного копіювання, а також і для історії. Колись давно я такий робив самостійно та окремо для nvALT, а тут вже все вбудовано в сам Obsidian, і знає, коли ти зробив зміни. Або ж є плагін, що робить з нотаток дошку канбан. Чого немає, а я хочу зробити, це автоматична архівація всіх вебсторінок, на які є посилання.
Спритний! В мене понад 2000 нотаток, та ніяких гальмувань я не побачив. Немає їх і з великими нотатками (в мене є нотатка з повним текстом ПДР — все добре. Також і нотатка з резервною копією 700 посилань-закладок.)

Експортувати нотатки з Bear просто та очевидно, але ж мені ще хочеться побудувати з них Git-репозиторій, та при цьому зберегти дати останнього редагування. (До речі, при експорті Bear сам виставляє правильну дату зміни файлів. Це половина успіху!)

29.10.2022

Багажник на дах

🚗🧳🎿 Сьогодні про автомобільні багажники на дах. Мав нещодавно купувати, виявилось не так просто. Може, і вам стане до нагоди.

Нащо це потрібно? Ну то зрозуміло — додаткові 300-400 л місця, дуже зручно при кочовому образі життя. До того, якщо вже обладнати дах машини під багажник, то далі можна туди кріпити й ровери, і лижі, і човен, і намет, і меблі… можливостей багато.
Багажник — справа дуже відповідальна. При поганому закріпленні чи неправильному користуванні улетить на трасі, якщо повезе — то не в чужу машину. Треба ставитись серйозно.
Багажник обмежує максимальну швидкість до 130 км/г. Це зрозуміло, бо він очевидно погіршує динамічні показники машини — гальмування повільніше, в поворотах трохи, але помітно несе. Що цікаво, витрати палива в мене менше за звичайні — напевно, через обмежену швидкість.
Край боксу опиниться десь на 30 см вище даху. Залазити туди складно. Особливо якщо у вас SUV.
Сам по собі бокс по розміру нагадує ліжко і важить близько 30 кг. Тобто знімати його з даху нелегко, а для зберігання треба мати гараж. Є цікаві механізми для монтування боксу на стелі гаража, я ще не роздивлявся.
Для кріплення багажника до машини на даху мають бути рейлінги. Є кріплення без них, але вони притискаються безпосередньо до даху, і, як на мене, то несерйозно — хоча б тому, що псуватиме фарбу.
Якщо рейлінгів немає, то, зазвичай, їх можна докупити. Є всілякі моделі від сторонніх виробників, але ж на мою думку оригінальні будуть надійніше. Я купив оригінальні повздовжні рейлінги — для них на даху підготоване місце. Потім, поперечні від THULE. До поперечних йде адаптер під конкретну модель машини, а взагалі вони модульні, складаються від власно рейлінгів, кінцевиків, та кріплень-адаптерів.
Сам бокс кріпиться до поперечних рейлінгів. І бокс, і поперечні рейлінги можна рухати взад-вперед. Головне, це щоб бокс підійшов по довжині — не заважав заднім дверям, та не дуже нависав над лобовим склом. Тож перед тим, як обирати бокс, варто виміряти довжину даху, це головний показник.
Отже, перелік необхідних покупок: рейлінги повздовжні оригінальні, рейлінги поперечні (комплект), багажний бокс. Все це не дуже дешево, але ж ще раз кажу, що заощаджувати на надійності нераціонально.

Можу ще порадити офіційний магазин THULE в Україні - bagazhnik.ua. (Вони мені не платять.)

28.10.2022

Чому робочі питання треба обговорювати в спільному чаті.

💬👥📖 Всі робочі питання в команді краще обговорювати в спільному чаті. Приватний чат залишається для особистих питань - “коли зустрічаємось”, “як справи”, “ходімо на обід” та інше.

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

Питання. Якщо ставити питання приватно, то відповісти має той, кого запитали. Це створює блокер — один чекає, другий має терміново відповідати. Також це підвищує bus factor, бо не дає іншим членам команди використати свої знання. Тому краще питати публічно, навіть якщо здається, що відповідь знає хтось конкретний.
Обговорення. Ніхто ніколи не тримає весь контекст проєкту водночас, тому завжди є шанс, що дехто з команди відкриє ще невідомий бік питання. Також обговорення в спільному чаті роблять рішення відомими всім та відразу. Якщо ж обговорювати приватно, то хибні рішення будуть помічені пізніше і коштуватимуть дорожче.
Історія. Зміст публічного чату можна знайти пізніше. Є питання та ситуації, що виникають знову і знову. Так, ідеально було б задокументувати кожне, але я не вірю, що хтось так робить. Але якщо просто обговорювати публічно, то журнал чату — це вже документація. Я часто шукаю (та знаходжу!) висновки з обговорень, зроблених рік чи більше тому. Звісно, документацію це не скасовує. Наприклад, розвʼязок кейсів підтримки можна почати в чаті, а потім перенести в повноцінну базу знань.

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

27.10.2022

Зручніше відображення даних з бази HealthKit

⚖️📉💚 Нарешті, можу проілюструвати, що я мав на увазі, коли казав, що вигляд даних у вбудованому додатку Health залишає бажати кращого.

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

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

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

Систему з середнім я придумав не сам, а прочитав багато років тому у книзі Hacker’s Diet. То є легендарна книга, яку варто прочитати кожному інженеру, що хоче схуднути. Написав її засновник компанії Autodesk.

До речі, нічний режим у SwiftUI надається автоматично, якщо вживати палітру системних кольорів. Дуже зручно.

26.10.2022

SwiftUI після React - враження

📱📐🎨 Потрохи просуваюсь зі своїм проєктом на HealthKit та тепер на SwiftUI. Скористуюсь нагодою розповісти трохи про SwiftUI і як на ньому писати після React.

Всім відомо, що SwiftUI був створений, щоб йти в ногу з часом саме з React та іншими схожими фреймворками. Це добре.

Перше слабке місце SwiftUI - відсутність JSX. JSX це чудова технологія, бо з одного боку надає можливість описувати структуру елементів та атрибутів наочним чином, а з іншого боку, еквівалентна JavaScript/TypeScript коду та піддається всім технологіям роботи з кодом — рефакторингу на функції та модулі, формальній перевірці та інше.

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

Друге слабке місце - Swift це суворо типізована мова, але при цьому з тенденцією автоматичного виведення типів. Тож весь той синтаксис має створювати коректну структуру типів. Я не маю компетенції повністю зрозуміти, як воно працює, але факт, що у великій компоненті можна прийти до неможливості виведення типів. Ще скоріше цю помилку побачиш, якщо вживати блоки if, які, на відміну від JSX, інколи працюють добре, а інколи ламають компілятор. Відповідь — рефакторити на менші компоненти.

Щоб почати, варто відразу зрозуміти, що аналог Redux будується на основі ObservableObject. Тобто в простих випадках можна зберігати стан в компоненті, як і в React, але при подальшому розвитку краще винести логіку в клас з ObservableObject.

З приємного — гнучка система лейаутів — особливо для того, щоб покрити різні розміри екранів, та навіть різні пристрої. Бо у SwiftUI одна і та сама компонента може працювати й на айфоні, і на маці, і на годиннику. Тут все супер.

Ще раджу продивитись офіційний курс по SwiftUI, він багато чого прояснює.

25.10.2022

Ми є то, що ми робимо щодня

☀️🌚🫂 Ми є то, що ми робимо щодня. Це дуже потужна думка.

Майбутнє є неосяжним. Спланувати його, а потім слідувати плану, мало кому вдається.

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

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

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

Раніше

Пізніше