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

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

10.10.2025

LLM для аналізу логів

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

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

Поки, нарешті, не прийшла ідея: заходжу в роутер (Asus, якщо що), завантажую системний журнал файлом, відкриваю в Cursor та питаю: що тут не так? (Ну, запит був трохи розгорнутіше, щось по типу “це журнал з роутера Asus, який має проблеми з інтернетом. визначити причину та варіанти рішення”.)

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

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

А проблеми були такі. Спочатку вимкнув “roaming assistant”. Це така функція для Mesh-систем, що роутер викидає тебе з низьким сигналом, щоб ти приєднався до іншого вузла. Але тут інших вузлів немає, тож роутер марно переривав підключення. Потім так само вимкнув “smart connect” - це коли роутер пропонує тобі 2.4GHz чи 5GHz за власним вибором. Бо ті ж проблеми, надто нестабільно виходить. Ще знизив transmit power, бо як виявляється він був викручений на максимум, а це, парадоксально, погано впливає на надійність.

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

09.10.2025

Reminders2JSON на iOS

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

Власне, щоб запустити такий маленький застосунок з macOS на iOS, потрібно мінімум дій. В цій екосистемі дуже зручне рішення для коду на різні платформи. Старе, як C: #if os(macOS) та поїхали. Код SwiftUI на 95% однаковий, проте окремі аспекти зустрічаються різні. Наприклад, на macOS є діалог збереження файлу, а на iOS - поширення (де технічно можна надіслати той файл будь-куди.)

І це вже заслуга SwiftUI, що такі особливості навішуються на спільну загальну структуру застосунку, і це в мові з сильною типізацією.

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

І найскладніше — це було організувати xcodegen та fastlane. Звісно, хотілося зробити красиво та менше повторювати — а запрацювало тільки тоді, коли я просто продублював конфігурацію.

Цікавий досвід — в Apple серйозно якісний апарат перенесення застосунків. Прямо хочеться ще щось перенести.

08.10.2025

Зроби спочатку дурний розвʼязок

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

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

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

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

07.10.2025

Ознаки дружнього до розробників продукту

Що дозволить мене, як розробнику, довіряти вашому продукту? Любити його та рекомендувати іншим? Хотілося б щоб все вирішувалося крутим маскотом та максимальною підтримкою ШІ, але… Ось на що я звертаю увагу:

Чим більше документації, тим краще. ЇЇ ніколи не достатньо, навіть у таких великих гравців, як Amazon чи Google. Документація з всього навкруги, починаючи з просто опису продукту та всіляких API, але також посібники, приклади. Історія змін — щоб відстежити, коли сталася несподіванка. Документація дозволить мені виплутатися самостійно, а я дуже не люблю звертатися до підтримки.
Наявність спільноти навколо продукту. Хоча б форум, на якому можна поставити запитання, а також — знайти відповіді на чужі. Але головне, що форум це й індикатор того, що продукт живий, в нього є користувачі. Якщо ви не всесвітньо відомий бренд, то без активності користувачів взагалі незрозуміло — чи це справжній продукт. А окрім форуму можуть бути обговорення на GitHub, сторонні доробки та статті. Та хоч пости в соціальних мережах.
Можливість зробити внесок. Це й відкритий код самого продукту — тут зрозуміло, відразу більше впевненості. Ну може не всього продукту, а хоч чогось це вже приємно. І можливість редагувати документацію. Екосистема плагінів та інтеграцій, де можна зробити свою. Ну навіть той самий форум, де можна поділитися досвідом — то вже щось.

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

06.10.2025

Фактори успіху GTD

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

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

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

03.10.2025

Дивна природа багаточастинних листів

Якщо довелося тобі надсилати електронну пошту автоматично, то, певно, знаєш, що в листа може бути два “смаки”: просто текст та HTML. А також — вкладення. Тож, як воно там всередині влаштовано?

Для надсилання кількох частин в одному листі використовується тип змісту multipart. Приблизно, до речі, такий саме, як і при надсиланні вебформи з файлом. Тільки там multipart/form-data, а в листі буде multipart/alternative, що значить, що клієнт мусить обрати одну з частин за власними можливостями.

Стоп, скажеш ти, а як тоді вкладення вписуються? А для вкладень вже є multipart/mixed, який нічого не говорить про природу частин. Але як зробити і текст/HTML, і вкладення? Ооо, тут ми дізнаємося, що всередині multipart/mixed як одна з частин може сидіти multipart/alternative. Та й взагалі технічно листи у форматі multipart містять ціле дерево частин, майже файлову систему!

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

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

02.10.2025

Тимчасові рішення

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

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

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

Є й інша проблема — рішення “назавжди” так само може виявитися не таким вічним, як нам хотілося. А поступатися зручністю та ускладнювати собі життя доведеться вже сьогодні. Зате якщо зробити просте рішення зараз, може через рік краще буде зрозуміло що ж його робити далі… на наступний “тимчасовий” термін. :)

01.10.2025

Автовідповідач для Ping

Після нещодавнього досвіду Shortcuts для експорту нагадувань з Apple Reminders - який, до речі, вже тиждень як зберігає мені щоденні резервні копії — зʼявилася ще одна ідея. (А експорт вже є в опублікованому застосунку).

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

Я шукав різні рішення для автотегінгу. Наприклад, час сну та час тренувань Ping вміє читати з Apple Health. А далі що? Далі починалися різні складні імпорти та інтеграції незрозуміло з чим незрозуміло як. Поки я несподівано не згадав про Shortcuts.

Отже, функція “автовідповідач”. Суть проста — можна в будь-який момент зайти в Ping, та вказати теги “на майбутнє”. Далі застосунок буде проставляти ці теги на кожний пінг, аж поки автовідповідач не буде вимкнений.

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

Обмеженням є те, що все ж тригерами можуть бути тільки системні події, а не такі що відбуваються в інших застосунках. Тож Shortcuts не є повним аналогом IFTTT чи Zapier, а шкода.

30.09.2025

Розробка обгорток для API: автоматична чи ручна

Якщо вашому продукту пощастить мати HTTP API, а потім ще й стане питання, що варто не тільки мати “голий” API, а ще й надати обгортки-SDK, то ви станете перед вибором. Або робити кожну обгортку власноруч, або згенерувати автоматично.

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

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

А саме, коли потім доведеться розробляти SDK для цього вашого API, може здаватися, що це дуже легко зробити — взяти, наприклад, openapi-generator, який вміє генерувати інтеграції для всіх уявних мов. Тільки як зберешся генерувати, виявиться що згенерований код не дуже красивий. Місцями — прямо гидкий.

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

Повернемося до генераторів… Виявляється, що якість згенерованого коду дуже залежить від якості схеми. Не можу поки дати ніяких конкретних рекомендацій, окрім того, щоб читати згенерований код та знаходити причини його недосконалостей. Найбільше проблем з обʼєднаними типами, тобто oneOf. Або взагалі, може API з самого початку був погано спроєктованим та незручним. Чи зручним рівно для одного внутрішнього випадку.

Як висновок… Можу порадити вкладати більшість зусиль в якість схеми та самого API, а генерацію обгорток залишити автоматизованою.

29.09.2025

Компʼютерні нотаріуси

Щоразу як хтось із LLM-братчиків “дізнається”, що код точніше за природну мову та дає більш очікувані результати, я не можу втримати посмішки. Правда? А я думав, то програмісти просто зговорилися писати, щоб чесним людям незрозуміло було.

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

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

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

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

Раніше

Пізніше