У вас, певно, не буде часу на це переписування

#розробка

Безперечно, переписати проєкт наново приваблива пропозиція. Можна нарешті врахувати все розуміння, виправити всі помилки... Під час це звучить настільки привабливо, що всі інші покращення відкладаються "на після переписування". От тільки зараз часу переписувати немає, але як руки дійдуть... Тоді все зробимо як треба.

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

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

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

Наприклад, я нещодавно думав переписувати наново рушій для блогу. Бо... надто складний він зараз. Але нічого технологічно нового я не планував: той самий Hugo. Та от бачу, що краще поступово додавати функції та оновлювати дизайн на місці. (Цими днями додав посилання на Mastodon... а також замінив значки на обрізаний Nerd Fonts.) Бо переписувати буде нереально довго.

Порядок виконання задач

#керування_задачами

Загально прийнятно планувати виконання задач крайньою датою (due date). Але, як вам повідомить кожний студент, крайня дата не є дієвою для планування роботи. Як на мене, то крайні дати взагалі є засобом комунікації, а не планування. Ми домовляємось з кимось (або з самими собою) про очікуваний результат. Але є мало сенсу робити задачі в порядку крайніх дат.

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

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

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

Для вибору порядку виконання є й більш просунуті системи: наприклад, Autofocus чи Final Version. Але головне, що можна зробити, це частіше звертатися до списку та щось з нього виконувати, а не тільки планувати та розставляти дати.

Найгірша функція macOS (idleassetsd)

Знаєте оті відеошпалери від Apple з мальовничими краєвидами? Дуже їх люблю. На Apple TV. На #macOS я їх просто ненавиджу. Не через те, що вони некрасиві — насправді, я взагалі ними не користуюся, бо рідко бачу робочий стіл. А через те, як вони обурливо марнують системні ресурси.

Почнемо з того, що повний пакет відеошпалер займає понад 80 Гб. Це більше, ніж багато ігор AAA, але в контексті macOS краще порівняння, що це 20% базового розміру накопичувача. На шпалери!

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

Також, як я розумію, шпалери є "доступними для видалення" разом зі значно важливішими файлами, як-от локальні копії з iCloud чи з Apple Photos, або кеш — та мають рівні права на існування. Це як обирати, що брати в подорож — валізу з одягом чи валізу з журналами.

Але і це ще не все. Коли на диску зʼявляється місце для шпалер, то macOS автоматично завантажує їх назад. Бо звісно, шпалери це важливіше, ніж документи з iCloud, які завантажуються тільки за запитом. А коли мій диск майже заповнений, то взагалі починаються нескінченні пересування туди-сюди!

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

А також знайшов на Реддіті як його надурити: не видаляти файли шпалер, а зробити порожніми.

```
sudo truncate -s 0 /Library/Application\ Support/com.apple.idleassetsd/Customer/4KSDR240FPS/*.mov

```

👑 Шпалери 4K 240 FPS, на якості не економимо!

Порожній список дій на роботі та висновки

#робочий_комп

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

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

Це моя перша роздільна система для роботи та дому. Раніше робота завжди була контекстом (текою, зоною) в спільній системі. Зараз в мене окремий компʼютер для роботи та я намагаюсь відокремити роботу від особистих справ, тому було логічно й системи задач зробити дві.

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

В домашній системі до такого успіху ще далеко, бо там все (поки?) вдесятеро складніше. Контекстів багато, проєктів багато, вони всі різні. А головне — потрібно вставати з-за компʼютера. Бо дійсно, зараз робота стала такою зоною комфорту, де все заздалегідь впорядковано — сиди та роби. Раніше так хіба з компʼютерними іграми було. Втім, такий успіх надихає влаштувати особисті справи так само.

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

До речі, майже всі нетермінові прохання я обробляю вранці під час щоденного огляду; протягом дня я їх записую в нотатки чи зберігаю в Slack, а вранці обробляю ці вхідні та перетворюю за #GTD.

Теги в каналі та HTML

#мета_пост

Не так все просто з тегами, як я вчора розповідав. А саме, замінити тег всередині тексту не можна, якщо він вже є посиланням. Ну, наприклад, якщо я вирішив послатися на сторінку Вікіпедії про Go, а також й додав тег #Go, то тегом повинна бути друга згадка, а не перша, яка в посиланні.

Іншою особливістю тут є те, що метадані (разом з тегами) є частиною вихідного тексту, а значить, зʼявляються не до, а одночасно з обробкою Markdown. Тому легше за все замінити теги вже в підготованому для Telegram тексті. Який є потворним гібридом HTML та текстової розмітки. Тож доведеться заміняти в HTML.

Як заміняти? Точно не регулярними виразами. Тут потрібний той чи інший парсер HTML. В Go для того є модуль net/html - я про нього вже згадував. Він надає, окрім іншого, токенізатор HTML, тобто спосіб перетворити HTML в послідовність токенів: "тег", "текст", "коментар" тощо.

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

Замість складного обходу дерева чи пошуку батьків — простий прохід з тривіальним скінченним автоматом. Швидко та прозоро.

Теги до постів в каналі

#мета_пост

🏷️ Сьогодні дійшли руки додати до каналу теги - бо постів вже за 800, та регулярно виникає потреба послатися на ту чи іншу серію. Також це допоможе SEO.

Відразу натрапив на проблему. В мене ж пости йдуть на сайт через #Hugo та в Телеграм. В Телеграмі теги робляться тривіально: додаєш до слова октоторп та він сам робить посилання на пошук за цим словом. У Hugo система в корні інша: теги належать метаданим поста, а не тексту, та на знаки решітки йому ніяково.

(Тривіальне рішення, певно, це писати тег і в метадані, і в текст, та закрити очі на зайві решітки на сайті. Але хіба це може задовольнити?)

Спочатку хотів зробити якийсь тег-шорткод, на кшталт того що маю для внутрішніх посилань. Це ніби працювало б, але в вихідному коді неохайно (особливо порівняно з хештегом!) та технічно складно.

🚿 Тоді сходив в душ та винайшов елегантне рішення: теги будуть в метаданих, а в тексті я буду автоматично додавати тег до першої згадки слова. Або, коли такої згадки немає, просто в перший рядок. Що й зроблено в цьому пості.

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

Ніколи не довіряй клієнту

Натрапив на статтю про вразливості британського застосунку для знайомств Feeld. Особливо цікаво стало, коли дізнався, що цей застосунок підняв 40 млн фунтів доходів за 2023, тож це не невідома поробка - можна уявити, скільки там користувачів.

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

☝️ Сервер ніколи не може бути впевнений, що відповідає на запити справжнього клієнта. Це аксіома інтернету. Звідси висновок: запити клієнта та відповіді сервера мусять завжди бути авторизовані щодо поточного автентифікованого користувача. На сервері!

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

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

Окремо стоять "рідні" застосунки, бо вони виглядають цільнішими та, на перший погляд, їм можна довіряти. Це самообман, рідні застосунки наділені такими ж вразливостями. Критерій "клієнта" лише один — чи виконується код в оточенні, яке ми не контролюємо? Все, що там, в будь-який момент перетвориться на агента з Матриці. 🕴️

Ігри в хмарі з GeForce Now

Я вже більш як рік граю віддалено через Parsec - інколи з сусідньої кімнати, інколи з іншого міста. Та це працює дійсно чудово — але коли є до чого підключатися. Коли ігровий компʼютер став недоступним, то я лишився з тим, що можна запустити на macOS... та з вірою в хмарний геймінг. Нещодавно, нарешті, наважився спробувати й Geforce Now - справжнє хмарне рішення від NVidia. Ось те, про що чомусь мало розповідають.

- ⚡ Щодо якості підключення. Найближчі до нас сервери в Болгарії. Достатньо звичайного дротового інтернету на 100 Мбіт, щоб цілком комфортно грати. Час від часу звʼязок пригальмовує на декілька секунд, що, як на мене, неуникно. Але, наприклад, якщо у вас Wi-Fi, то найбільші втрати будуть саме від нього.

- 🗄️ Щодо асортименту ігор та формату сервісу. Тут все цікаво. По-перше, GFN не надає ніякого віртуального робочого столу — тільки доступ до конкретної гри. Відповідно, ігри є тільки з їхньої бібліотеки (зате чекати завантаження не потрібно!) Там багато всього є, але далеко не все — зокрема, інді-ігор небагато, але й такі гіганти як Elden Ring відсутні. Встановити моди теж не вийде — тож ніякого тут Fallout: London. Але з іншого боку, грати можна тільки у свої ігри — тобто вже придбані на якомусь з майданчиків. Виходить ситуація як з всякими Megogo, де фільмів безліч, але коли шукаєш щось конкретне, то 50/50 його не буде.

- 💸 Щодо заліза та його ціни. Підписка коштує $12 або $24 на місяць (це, до речі, перший сервіс, де я бачу ПДВ, не включений в ціну!) На більшому пакеті отримуєш GeForce 4080, тобто найкраще, що є на сьогодні. Та якщо порівнювати підписку з ціною утримання такого свіжого заліза вдома, то виходить дешевше. Плюс вона не гуде, не займає половину стола, та легко пересувається з тобою. (PS: є взагалі безплатний пакет! Тільки доведеться почекати в черзі та грати не довше години.)

- 🤔 Чи воно того варте? Якби ж за ці гроші можна було запускати в хмарі будь-що, а не тільки дозволені ігри, я б точно відмовився від домашнього компʼютера. А як є, можливо, замість наступного оновлення заліза заміню його на SFFPC без вентиляторів, щоб грати у всілякі Dread Delusion. Або навіть встановлю Parallels на макбук. А в топове та найсучасніше можна й в хмарі пограти.

Обхід блокування Reddit API

В мене окрім гарної стрічки RSS для Hacker News також є стрічка для Reddit - вона наразі не така цікава, але я збирався розширити асортимент та, можливо, зібрати альтернативу для HN з Реддіту.

Ну точніше, вона б мала бути, але на жаль вона давно порожня, та нарешті вирішив зʼясувати, чому. Виявилось, що Reddit блокує запити до власного API з адрес AWS. Причому я спочатку й не думав про блокування, бо використовую Lambda, яка отримує нову адресу щоразу, але коли почав шукати причину, що з дому стрічка працює, а з лямбди — ні, то натрапив на пост, який вказав на це пояснення.

Сиджу думаю, що ж можна зробити, куди переїхати... Може, проксі якийсь... Та тут мене осяяло: ну коли вдома все працює, то нехай скрипт запускається вдома! Можна було б й тут намудрити, наприклад, замінити стрічку на якусь локальну версію, але я пішов найпрямішим шляхом, та просто запускаю той самий код, що в AWS Lambda, тільки в себе на ноутбуці.

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

Для запуску скриптів щодня в macOS є сервіс launchd - аналог systemd в Linux. (Не тільки щодня, а й за купою різноманітних сценаріїв.) А для зручної роботи з ним є застосунок LaunchControl. Це прямо цілий IDE, в ньому все видно та дуже зручно. Особливо тому, що вивчати параметри, наприклад, для запуску за розкладом, не хочеться — а в LaunchControl за ними є довідка та графічний інтерфейс. Так само і для перегляду журналу все готово. Рекомендую.

З несподіваного: Ruby в launchd вмикав кодування ASCII, а не UTF8. Бо він виконується поза оточення оболонки, де в мене виставлена локаль. Це можна рішити аргументом \-E utf\-8:utf\-8. А ще, оскільки сам Ruby в мене сидить в asdf, та тягнути його в сервіс не хотілося, можна дізнатися прямий шлях до виконуваного файлу командою asdf which ruby.

Програмний доступ до Docker

🐳 Чи знаєте ви, що в Docker є зручний клієнт на Go? Інтеграційний тест, про який я два дні тому писав, зупиняє контейнер саме через цей клієнт.

Причому якщо вам не потрібна авторизація, щоб запускати консольні команди docker, то й тут теж не потрібна: client.NewClientWithOpts(client.FromEnv) буде достатньо. Але авторизуватися та керувати іншими машинами теж можливо.

Ми використовували дві функції клієнта: вище згадану зупинку контейнера, а також отримання журналу через client.ContainerLogs(). Через журнал перевірялося, що в ньому немає помилок. Окрім того, буквально все, що можна зробити з Docker, можна зробити через цей API - бо сам Docker написаний на Go та його офіційні клієнти теж.

Та ось що дотепно — мені такий інтерфейс набагато більше подобається, ніж стандартний командний рядок! Він весь типізований та тому можливості перелічені та вичерпні. Наприклад, ось тип Mount - всі атрибути явні, навіть з переліченими типами на кшталт Type чи Consistency.

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