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

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

06.06.2025

Звички GTD: обробка поточних задач

(Організаційне питання: я подумав, що перейменовувати продукт із торговою маркою — погана ідея. Тому далі буде просто GTD, без вигадок.)

Задачі приходять до нас в різній формі: “додати фічу X”, “повісити москітні сітки”, “купити сорочку”, “купити хліб”. Всі їх можна виконати. Але центральний момент GTD в тому, що ми недостатньо плануємо наперед. Може здатися, що план — це зайвий, якщо й без нього можна все зробити. Але якщо звернути увагу, тоді виходить, що ми змушені “планувати” в момент вибору задачі, та виходить це кепсько.

Наприклад: “повісити москітні сітки” наче зрозуміло… але самі сітки лежать в гаражі, то туди ще треба сходити забрати. “Купити сорочку”… та яку саме ще не вирішили. З хлібом зрозуміло, але його потрібно купити не зараз, а коли будеш в крамниці. Таке мікропланування ми робимо щоразу, коли читаємо список задач, та саме через нього список переростає у незрозумілу купу.

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

Наприклад: з сорочками може результат бути “мати свіжий одяг на літо” (бо сорочки ж не самоціль?) А наступна дія - “спитати в друга, де він купував сорочку.” А ні, то не мій друг, а чоловік подруги дружини. Ну тоді спочатку “спитати контакт в дружини.” Ми розкручуємо задачу, поки не дійдемо до дії, яка не має передумов (окрім контексту, про нього буде окремо пізніше).

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

А “купити хліб” - це взагалі не задача, а пункт списку покупок! Немає сенсу такі рутинні дії тримати в GTD. Та це ще один нюанс: знати, де пора зупинитися. GTD це точно не система “для всіх задач в житті”.

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

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

05.06.2025

Звички GTD: обробка

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

В GTD / БДС є центральна блок-схема для обробки — вона на ілюстрації. В ній є два ключових питання: чи потребує це дій? та коли? Обидва питання критично важливі, щоб не завалити себе незрозумілими “задачами”.

Частина вхідних або просто непотрібна, або записана для довідки. Такі ми викидаємо чи переносимо в нотатки та інші зручні місця. Тут все просто.

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

На оригіналі схеми є питання: is it actionable? Довгий час я думав, що воно значить — чи можна взагалі щось по цьому зробити? Це неправильно! Робити можна майже все. Навіть мрія починається з маленької дії сьогодні. Проте справжній сенс цього питання в розгалуженні: беремося робити в найближчий тиждень, або почекає?

(Я для конкретики написав тиждень, бо це правильний проміжок між оглядами. А на огляді ми маємо шанс переглянути списки відкладеного та поповнити активні задачі. Взагалі в БДС багато чого відбувається в ритмі оглядів.)

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

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

04.06.2025

Звички GTD: збір

Про збір можна дуже швидко сказати: записуй все.

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

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

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

Власне, з пошуку таких місць можна й почати. А також, завести собі зручну записничку. Зараз це 100% телефон — то обрати програму, куди легко заносити нотатки. Для мене це Drafts, але зовсім на ходу надиктовую Siri в нагадування.

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

03.06.2025

GTD - з чого складається ця система?

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

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

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

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

3. Систематизація. То, мабуть, найбільш знайома всім звичка про розкладання задач в різні списки. В БДС на диво списки дуже прості, тому влаштує буквально будь-яке сучасне рішення, від блокнота та текстового файлу. Вся магія не в списках, а в осмисленні, яке їм передує.

4. Перегляд. Звичка, яка все повʼязує. Щотижневий перегляд зберігає впевненість у повноті та актуальності системи. Без нього швидко втрачаєш довіру. Не лякайся, переглядаються тільки поточні справи, та ті, що можливо пора починати — тому перегляд виходить цілком осяжний. (І надзвичайно корисний!)

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

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

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

02.06.2025

Getting Things Done: що це таке, навіщо, та мій досвід

Знаєте що? Червень — місяць, максимально віддалений від Нового року. А значить, це такий надир продуктивності, коли всі старі новорічні обіцянки вже вигоріли, а до нових ще так далеко. Я гадаю, найкраще часу для пояснення системи самоменеджменту не придумати. 🌚

Отже, GTD. Я багато разів згадував її, але тепер хочу систематично пройтися, бо гарного пояснення рідною мовою ще не бачив. На початку була книга. Українською її перекладають нудно “Як привести справи в порядок: мистецтво продуктивності без стресу”. Хіба це бренд? Я пропоную альтернативну назву: Беремося До Справ — БДС, а оскільки це моя авторська адаптація — то БДС Модифікована: БДС(М). 🐴

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

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

Також цікаво, що БДС охоплює всі сфери життя. Теоретично можна її впровадити тільки на роботі (бо в мене зараз взагалі дві окремі системи), але повний результат буде тільки від повного застосування. Бо голова ж зайнята всякими справами, що на роботі, що вдома. В БДС немає нічого специфічно “робочого”, та вона чудово допомагає впоратися з побутом.

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

01.06.2025

Скрипт для експорту з Perplexity

Сьогодні дуже продуктивний був день — вчорашню міграцію довів до компіляції (але, на жаль, не до кінця), випустив маленьке оновлення 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, можна забрати собі, можна просто почитати.

31.05.2025

Масштабний рефакторинг з агентом ШІ

Досяг поки для себе стелі використання помічника ШІ:

В мене є кілька проєктів для iOS, які використовують SwiftData. Мені він зовсім перестав подобатись, тому хочу переписати все на SQLite (GRDB). Але то вручну робити важко. Зате більшість змін робляться за аналогією, хоча не повною: наприклад, у SwiftData асоціації завантажуються автоматично, коли до них звертаєшся, а в GRDB варто наперед запитати все необхідне до купи.

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

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

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

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

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

А вихід є - обмежувати інструкції дрібними змінами. Це, для мене, поки і є сфера доцільного використання ШІ.

30.05.2025

Я втомився від Capybara

В Ruby on Rails надто зручна система для інтеграційних тестів — з Capybara. Вона дозволяє керувати браузером з Ruby. Та це чудово. Можна поєднувати в одному файлі будь-які налаштування застосунку та бізнес-логіки та всі можливості браузера.

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

А ще в Capybara приємний DSL, абстрагований майже від всіх нюансів вебсторінок. (Хоча за потребою можна й спуститися на низький рівень чи навіть виконувати JavaScript.)

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

Але браузер — річ складна та хаотична. Абстракція тече, та замість простих “перевірок браузером” ми починаємо латати в ній дірки. Хоч є багато системних покращень (як-от Capybara вже давно вміє автоматично чекати, доки на сторінці зʼявиться зміст, який ми перевіряємо), але код тестів вкривається латками все одно.

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

Який я можу зробити висновок… Capybara була чудовим інструментом на той час, коли JavaScript був рідкістю (так, колись взагалі окремо виділяли тести, яким він потрібний — решта навіть браузер не запускала!) Але зараз фокусом інтеграційних тестів є застосунок JavaScript, та набагато легше було б їх писати не на Ruby, а наближено до браузера — тобто в Cypress чи Playwright тощо. Тим паче, що для них вже давно зробили інтеграції, які вміють запускати фабрики, а то й довільний код на Ruby.

29.05.2025

Агент ШІ: Від 0 до вайб-кодінгу

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

1. Ставити питання щодо проєкту. Як працює X? Чому тут так написано? Яка різниця між А та B? ШІ здатний швидко обробити багато коду та дати чудові пояснення. При цьому ШІ не пише аніскілечки вашого коду, тому й ніяких ризиків немає. (До речі, тут та далі потрібний редактор з ШІ, як-от Cursor, а не просто чатбот без знання проєкту.)

2. Маніпуляція тексту. Моя улюблена функція поки — це скопіювати шлях до об’єкта в Google Console та попросити зробити з нього виклик CLI. Задачі такого рівня вимагають нудних ручних перетворень, а ШІ з ними порається дивовижно.

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

4. Локальна генерація чи рефакторинг. Можна попросити згенерувати одну функцію, чи скелет класу, чи тесту. В Cursor для цього тиснеш Cmd+K в потрібному місці. А ще - виділяєш текст, тиснеш Cmd+K та рефакториш на місці. При цьому зміни не залишають область виділення, а якщо не сподобалося — можна відразу скасувати.

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

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

7. Генерувати плани за допомогою ШІ. Цим я сам ще не займався. Але технічно ШІ так само може генерувати план, як і код (або навіть краще.)

8. Піддатися та прийняти вайб. Ну слухайте, я досі не вірю, що хтось це робить навсправжки.

28.05.2025

Сліпці та AI слон

🤼 Надзвичайно важко говорити про генеративний AI щось раціональне для загальної аудиторії. Бо визначні голоси поділилися на релігійних AI-оптимістів та таких саме релігійних AI-заперечувачів. Та, як завжди, реальність десь посередині. Щоб побачити її потрібно позбавитися багатьох хиб, які натомість вбиваються дедалі глибше з протилежних сторін. Ось мої думки, як релігійного прагматика.

Спочатку про оптимізм. Слон в цій кімнаті — це те, що генеративний AI став поточним бумом, а значить, на ньому заробляють купу грошей. Не користувачі, а насамперед постачальники (як-от компанія OpenAI). Не з користувачів, а з інвесторів. Поки є оптимізм — будуть інвестиції. Гроші ллються на підґрунтя двох міфів.

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

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

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

Та наступний міф заперечувачів — що генеративний AI здатний тільки на нісенітницю. Я розумію, це реакція на розгнузданий AI-оптимізм. Втім достатньо хоч трохи випробувати LLM, щоб побачити, що це не так. Що результат залежить від твоїх запитів та твого нагляду. Звісно, якщо потребувати від LLM всього та відразу, то вийде сміття. Але це все одно що ображатися на перфоратор, за те що він не зробить тобі ремонт.

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

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

Раніше

Пізніше