#МоїПроєкти

Сьогодні випустив оновлення для Headless. За всіма вимірами, це треба було зробити вже давно, але краще пізніше, ніж ніколи — принаймні, якщо люди все ще просять. (Я вже писав), що мені він давно не потрібний. Десь з рік тому до мене зверталася людина та пропонувала зайнятися підтримкою, та я навіть доступи надав, але… в неї теж поки не знайшлося часу, напевно? Історія класична. Десь з тиждень тому мені знову нагадали, що гем не працює з сучасним Ruby, тож вирішив взятись.

Як я себе змусив це зробити. Думаю, ну мені не хочеться - Cursor зможе. Успіхи з Cursor були різного рівня.

Замінити Travis CI на Github Actions - впорався на 95%. (Чомусь запхав у виконання тестів xvfb-run, хоча вся суть мого гему, що він заміняє xvfb-run для програм на Ruby.) Це чудово! Я вручну б довго сидів та розбирав синтаксис.

Оновити матрицю версій Ruby для CI - впорався на 100%. Теж гарно, бо це наче просто, але довелося б бігати по сторінках завантажень Ruby та JRuby.

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

Додати Rubocop - тут я б сказав 30% успіху — наче щось виходило, але конфігурації забагато та rubocop-rails намагався теж впхати.

Виправити Rubocop - цього взагалі не раджу робити, хоча в мене були великі сподівання. Бо код псує більше, ніж виправляє. Причому псує в сенсі змінює зміст. А я зрештою замінив Rubocop на Standard - це надбудова над Rubocop із переконаним набором налаштувань. Окрім іншого, Standard добре виправляє помилки та підійде навіть в ролі автоформатувальника. Навіщо ШІ, коли є спеціалізований інструмент?

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

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

Власне, майже всі запчастини в мене вже є, Я вже писав, як отримати список вкладок з Safari та генерувати Canvas зі списку, утиліту для чого pbcopy-chromium я вже публікував. Але одне рішення — на AppleScript, друге — на Ruby. Вирішив, що найбільш елегантно буде зібрати до купи на JavaScript for Mac Automation, про який я теж вже писав. Бо інакше інтеграція буде ще складніша, ніж частини.

Отже. AppleScript у JXA перекладається 1-до-1. Це, за моїм досвідом, найкраща задача для ШІ! Замість години копирсання поганою документацією та поступового налагодження — задля, фактично, “нульового” результату, бо ми тільки перекладаємо логіку на іншу мову — одна команда. Так само вдалося й перекласти генерацію канви з Ruby на JXA - причому, ба більше, ШІ відразу її автоматично “вписав” у попередній скрипт.

Це 80% роботи. Решта 80% була менш автоматичною. Ну, згенерувати команду для виклику pbcopy-chromium вийшло, та це гарно, бо там не одна команда, а цілий ланцюг. От тільки як в нього передати зміст? ШІ зробив через echo. Зрозуміло, що зі складним JSON від цього буде купа проблем. Тоді спробував через тимчасовий файл. ШІ нагенерував відповідні команди — включаючи mktemp для генерації файлу — десь на 80%.

Але тепер залишилося найцікавіше, бо запис у файл з JXA не використовує UTF-8. Поради ШІ тут були безпомічні. Тоді знайшов на SO відповідь, як то зробити… мостом в Objective C? Дико, але працює!

Нарешті, про рефакторинг. Сьогодні ШІ накидав все в одну купу; наприклад, вище згадана побудова JSON для канви відбувалася прямо в циклі по вкладках браузера. Звісно, краще ділити логіку за намірами. Зате інструкція “розбий це на дві функції для того та для того” спрацювала.

Ще з суто ШІшного ексцесу (тобто такого, що я б сам не став робити) - генерація ID вузла через хеш змісту. Це я попросив зробити, але функцію воно нагенерувало само. Нічого бібліотечного готового немає. Вирішив, нехай залишається.

Знову, таку роботу я б сам не зробив, бо часу немає. Забрати скрипт можна тут.

Отже, вчора в коментарях зʼясували, що Apple Reminders технічно можна було б вивантажити в JSON через фреймворк EventKit. А сьогодні я вирішив, що це гарний проєкт для того, щоб погратися з ШІ, та майже витягнув його в App Store (!)

Чому гарний для ШІ? Бо я гарно розумію, що треба зробити, але це все одно багато роботи. Це проєкт-“клей”, тобто такий, де потрібно поєднати готові частини в спеціалізоване рішення. Я люблю цитувати статтю You can’t buy integration, але — здається, ШІ чудово виконує “склейку”.

В цьому випадку, я спочатку згенерував функції читання з EventKit та генерації JSON, потім — окремо — експорт будильників та графіків. Потім конфігурацію командного рядка. Потім конвертував застосунок командного рядка у SwiftUI (!) Створив набір значків потрібного розміру. Додав файли Fastlane для публікації. Та більшу частину всього цього зробив Claude.

Але на “інші 80%” пішло набагато більше часу. Наприклад, спочатку я хотів консольну утиліту. Але в моделі безпеки macOS вони не можуть отримати дозвіл на читання Reminders. (Бо ця модель розрахована на “товсті” застосунки, із всілякими підписами.) Та мені так і не вдалося це побороти, хоча наче можливість є — невідомо тільки як до неї прийти. Локально в XCode наче працює, але на іншій машині абсолютно відмовляється.

Промучився пару годин та вирішив зробити очевидне рішення — перетворити на графічний застосунок. Та тут ШІ впорався не тільки зі створенням інтерфейсу, але й, наприклад, із відкриттям діалогу для збереження файлу (ще одна склейка).

Сам застосунок дуже нудний — бере нагадування, зберігає в JSON. А, ще деякі атрибути нагадувань недоступні з EventKit - наприклад, групи списків. Ну то вже таке. Через пару днів має зʼявитися в App Store. А ось вже й в App Store!

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

Ось пітч: Perplexity мені подобається всім, окрім одного: продукт досліджень залишається у них на сайті. А мені б хотілося відразу все це зберігати в Obsidian. Можливість експортувати є, але тільки по одному діалогу. Та й API на це немає — тільки через вебсайт. Але, думаю, чом би не автоматизувати експорт всього з Perplexity у Markdown за допомогою скрипту? Так і зробив — за допомогою Cursor та того ж Perplexity.

Про Cursor більше не буду, там нічого особливого, робота в режимі дрібних змін. Хоча він мені непоганий скелет згенерував, та навіть переклав потім на TypeScript. Він же ж обрав Puppeteer для керування браузером. Я самого Puppeteer не знаю, але ж на автоматизації соба… тобто капібару зʼїв. З допомогою Cursor (та TypeScript) можна документацію не читати, а прямо казати, яка команда потрібна. Ну майже.

Авторизацію залишив в напівручному режимі — ти сам копіюєш код з пошти у вікно браузера. Тут все прямолінійно, окрім захисту Cloudflare. Який я навіть в ручному режимі не міг пройти. Тоді Perplexity мені сам підказав, що для обходу безпеки є puppeteer-extra-plugin-stealth. З ним сторінка захисту навіть не зʼявляється, бо браузер “виглядає як нормальний”.

Далі цікавим питанням було — як під час експорту зберегти файл туди, куди треба. Чомусь в Puppeteer так само як і в Capybara для цього немає вбудованих функцій, а треба викликати вже знайомий CDP та слухати події. Зокрема, важливо помітити, що файл вже завантажився, та так само — що відбулася помилка. Загорнув все це у клас DownloadManager, який повинен бути універсальним.

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

Осьо perplexity-exporter, можна забрати собі, можна просто почитати.

Минула версія скрипту для експорту з Perplexity трохи завʼязла через обмеження частоти запитів. До того ж експортований Markdown був досить неповноцінним та не містив, наприклад, знайдених зображень. А оце сьогодні вдалося зробити з усіх боків краще!

Сиджу та думаю: ну якщо я вже відкрив сторінку з діалогом, то навіщо мені ще експортувати — в такий “джерельний” формат, як Markdown - коли в теорії можна просто забрати зміст зі сторінки?

Подивився журнал запитів (вкладка “Мережа” в інструментах розробника корисна, як завжди.) Та дійсно — бачу смачний запит до API, який віддає зміст в усіх подробицях (/rest/thread, якщо будеш шукати для себе.) Там не тільки Markdown діалогу, а й перелік посилань, зображень, навіть розʼяснення плану пошуку. Абсолютно все.

Але найкраще навіть не це. У таких запитів майже немає обмежень! Бо це звичайний перегляд сторінки. Коли я зробив паузу між сторінками у 2 секунди, то успішно забрав всі свої 500 діалогів.

Я вирішив не робити ті запити до API напряму, а все ж взаємодіяти зі сторінками так, як це робить звичайний користувач. В Puppeteer дуже легко забирати будь-які запити, що відбуваються: достатньо зробити page.on('response'). А там вже фільтрувати за URL та зберігати в файли.

Єдине (хороше!) ускладнення — дані я отримую у JSON. Це чудово, бо можна так їх і зберігати та сподіватися, що це вичерпний експорт. Але документ Markdown з них ще потрібно збудувати. На щастя, кожна відповідь генерується вже в Markdown, тобто їх залишається просто склеїти. Найбільше проблем створили посилання на джерела: вони помічені просто як [1], а мені довелося будувати список посилань з внутрішніми якорями ^0-1, а потім на них посилатися: [[#^0-1]]. Ну то дрібниці.

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

Як і збирався: yarn global add perplexport - утиліта для експорту діалогів з Perplexity. Я поки боюся, що з браузером будуть якісь складнощі, але подивимось. Є ще варіант з Puppeteer переїхати на Playwright.

(Взагалі я дуже не люблю утиліти, написані на JS за те, як вони встановлюються. А коли ще то цього домішується ASDF - то й зовсім. Втім, маємо те що маємо.)

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

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

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

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

Все це дійсно наближує мене до браузера, який я хочу… хіба що замість сторінок тут пошук з перетравленням ШІ.