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

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

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

08.10.2024

Вхідні

Мій підхід до керування справами (а може й будь-який?) базується на тому, що є невпорядкований “вхідний” простір, який регулярно потрібно обробляти, переносити у систему та спустошувати. Практично в будь-якій програмі з задачами будуть “вхідні” - Inbox, Things, OmniFocus - це стандартна на наш час функція.

Втім, у своїй програмі я вхідні робити не планував. Я вже маю програму для вхідних нотаток - Drafts - та в ній функцій чи не більше, ніж у типовому менеджері задач: інтеграція з іншими програмами, версія для телефона та годинника тощо. Ба більше, всі вхідні в одну програму не збереш — бо є ще пошта, збережені повідомлення з Slack, та навіть реальні, фізичні предмети на столі.

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

Таким чином, я не забуду обробити й Drafts, і пошту, і всі інші місця. До речі, оцей Open на ілюстрації — це не статичне посилання, а текст Markdown - воно відкриває застосунки за їхньою URL схемою, наприклад, drafts://. Причому у SwiftUI вбудований рушій Markdown; для статичних рядків він працює сам собою, а змінні достатньо завернути в LocalizedStringKey. Мабуть, для продукту я б таке ризиковане рішення не взяв, але для себе дуже зручно мати Markdown під рукою.

07.10.2024

Перці

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

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

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

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

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

Можна робити соуси — якщо на оцті, то соус все одно повинен кілька місяців стояти, щоб поєднався смак. На мою думку, соус має сенс робити на свій смак — додавати оцет, сіль, цукор/мед, спеції, часник… чи навіть будь-які овочі та фрукти. Те, що подобається. Ласкаво прошу до /r/hotsaucerecipes.

Ферментація (тобто киснення) - то вже для сильних духом, практично тваринництво. Пліснява — це страшно. Але багато відомих соусів саме квашені — серед них Табаско та Шрірача. Бо киснення, скажімо так, відкриває можливість цікавого, складного смаку. Про це теж є сабреддіт.

06.10.2024

Розробка для себе

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

Технічна реалізація досить проста: скрипт для експорту канви в список я вже писав, залишилось портувати його на Swift та додати необхідний мінімум UI. Та ще менший мінімум моделі: відображення ID вузлів канви в ID дій, щоб памʼятати, які з них вже імпортовані. О, а ще щоб звʼязати проєкт з канвою, я шукаю в нотатках до проєкту URL від Obsidian, розбираю його та отримую імʼя файлу — який потім можу знайти в файловій системі, знаючи шлях до бази Obsidian.

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

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

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

05.10.2024

Найкраща зустріч

Цими днями в мене трапилась просто найкраща зустріч-обговорення. Вона закінчилася раніше запланованого, з новим розумінням та корисним висновком. Що цьому посприяло, на мою думку:

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

04.10.2024

Не займайся плануванням в списку задач

Пʼятничний пост про планування. В мене типова ситуація, коли намагаюся відразу від постановки цілі (задачі, проєкту, доручення) перейти до вигадування кроків до неї. Тобто відкрити порожній список та писати: задача 1, задача 2…

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

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

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

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

03.10.2024

BetterTouchTool

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

Сьогодні мені захотілося, щоб в Drafts посилання відкривалися за Cmd+click, як це роблять інші редактори. Однак в Drafts для того особливий режим “Link mode”. Хоча ні, знайшов ще пункт контекстного меню “Open Link”. Щоб не псувати мʼязову памʼять, призначив в BTT для Drafts на Сmd+click операцію “Обрати пункт контекстного меню Open Link”. Готово!

BTT - це дійсно один застосунок на всі потреби. Я його вже згадував 1 2 3 4 5 6 разів. І ще тільки нещодавно зробив, щоб Cmd+пробіл в iPhone Mirroring відкривав пошук по айфону. Особливо мені подобається, що завдяки BTT можна впевнено нормалізувати поведінку різних застосунків, щоб не згадувати, де знаходишся.

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

А ще для ігор в мене Hyper+F змінює призначення функціональних клавіш з медіа на звичайні. Там цілий шел-скрипт запускається. (Хоча, до речі, я давно звик привʼязувати Quick Save на \, а Quick Load на /.)

02.10.2024

Опублікував pbcopy-chromium; Swift Package Manager

Нарешті дійшли руки опублікувати мою утиліту для копіювання з Obsidian Canvas. Тепер вона доступна на GitHub. Трохи деталей про публікацію, бо це мій перший проєкт з відкритим кодом на Swift.

До того я збирав та запускав проєкт в XCode. А потім скопіював виконуваний файл собі в каталог скриптів — все працювало добра. (Взагалі, попри те, що застосунки macOS мають розширення .app та є текою, а не файлом — всередині кожного все одно сидить виконуваний файл.)

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

Залишався тільки один нюанс: щоб програма для macOS під час запуску не викликала застережень, її необхідно підписати, тобто нотаризувати. На це теж знайшов [статтю](Build a notarized package with a Swift Package Manager executable – Scripting OS X) та з нею команду codesign. Теж нічого складного. Хоча в мене вже був сертифікат, який був отриманий через XCode.

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

01.10.2024

Ще SwiftUI на десктопі

Ще трошки вражень від розробки на SwiftUI для macOS. Я потроху роблю свій застосуночок для GTD, та зізнаюся, це значно легше, ніж робити щось аналогічне для iOS.

Вже не знаю, чому, але в мене давно не було інтересу до розробки десктопних застосунків. Можливо, через те, що я професійно пишу для вебу, та десктоп виглядав як щось зайве. Можливо, від мобільних застосунків більше вау-ефекту та вони більше на слуху. Але в мене якось не було ідеї робити щось для macOS. Взагалі останній раз серйозні застосунки робив ще на Windows, тобто років 15 тому.

Втім, зараз я впевнений, що якщо вивчати Swift / SwiftUI, то варто робити це на десктопі, а на мобільні застосунки переходити вже з досвідом.

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

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

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

30.09.2024

5 правил програмування Роба Пайка

Я не раз посилався в цьому каналі на правила програмування Роба Пайка.

Роб Пайк — якого я знаю як одного з засновників Go - взагалі людина з багатою карʼєрою — він доклав руки до Plan 9, Unix, UTF8 та інших проєктів. А правила ці були записані ще у 1989. Це один з документів, який я постійно згадую у своїй роботі. Наведу їх тут з моїми коментарями.

1. Ти не знаєш наперед, де програма витрачатиме час. Вузькі місця трапляються несподівано, тому не поспішай оптимізувати, поки їх не знайдеш. Навіть коли алгоритмічна складність ясна, в реальних програмах важливий вплив вводу-виводу, та особливо запитів через мережу.
2. Вимірюй швидкість. Не оптимізуй, поки виміри не покажуть, що одна з частин значно повільніша за інші. Я б ще додав, що міряти потрібно в реальних обставинах, бо потім виявляється, що ноутбук на батареї пригальмовує процесор, а локальний доступ до мережі значно швидше за віддалений.
3. Заморочені алгоритми повільні на невеликих обсягах даних, а обсяги зазвичай невеликі. Базова ціна складних алгоритмів висока. Не ускладнюй код, якщо тільки не відомо, що даних зазвичай буде багато. (Та див. правило 2) А ще великі обсяги даних можна доручити готовим рішенням (як-от база даних).
4. Заморочені алгоритми містять більше помилок та писати їх важче. Використовуй прості алгоритми та структури даних. Ускладнення, так само як кількість рядків коду, не свідчать про гарно виконану роботу.
5. Дані переважають. Коли обрав вірні структури даних та впорядкував їх гарно, алгоритми стануть очевидними. Структури даних, а не алгоритми, є центральними в програмуванні. Цей принцип бачу всюди — від функціонального програмування до програмування типами до повсякденного моделювання задач.

29.09.2024

Чому робота складніша за олімпіади?

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

Наведу приклад дуже складної задачі з мого нещодавнього досвіду. Потрібно було розробити систему бізнес-правил. Одні правила були загальні для всіх випадків; інші покладалися на конфігурацію. Параметри правил могли належати до однієї з 4 сутностей. Сутності були вкладені та це впливало на вибір правила. До всього цього повинен бути зрозумілий інтерфейс, який адекватно покривав можливі комбінації параметрів.

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

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

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

PS. А ще про олімпіади згадували дружні канали тут та тут, доєднуйтесь й ви.

Раніше