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

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

Підписатись на RSS
📢 Канал в Telegram @stendap_sogodni
🦣 @stendap_sogodni@shevtsov.me в Федиверсі

21.10.2025

Fail Fast проти Hang In There

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

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

Hang In There: застосунок повинен триматися, хай би що трапилося. Кожну помилку пробувати наново. За браком залежності продовжувати без неї, в обмеженому режимі. Взагалі ніколи не зупиняти застосунок, поки не отримаємо на то сигнал. Переваги тут — що не буде перезапуску, власне.

Обидва підходи мають своє застосування. Колись я вважав, що в сучасній інфраструктурі з контейнерами Fail Fast - очевидний вибір. Але дедалі більше хочеться робити застосунки, які не будуть перезапускатися. Зокрема, перезапуск ризикує зробити із поганого гірше, як зі мною вже траплялось.

Вчорашній простій AWS us-east-1 це підкреслив, бо в нашому випадку найдовше не було можливості запускати нові задачі. Отже, те, що трималося — працювало, а те, що очікувало на перезапуск — просто впало до закінчення інциденту. (До речі, також не могли стартувати лямбди, а вони можуть бути тільки Fail Fast.)

Хоча здається, був і протилежний приклад: черги SQS не спричинили відмову споживачів, а просто припинили доставляти повідомлення до перезапуску клієнтів. Поки не зрозумів, чому так сталося.

20.10.2025

Робота із Windows по SSH

Є в мене домашній сервер на Windows. Точніше не так: в мене є ігровий компʼютер на Windows, але оскільки в ньому потужна відеокарта та й решта заліза, він чудово підходить для важких задач, як-от бібліотеки Plex. У 2023 я писав, як перекодовував фільмотеку у HEVC.

Тоді я робив всю роботу на макбуці, а на Windows потім тільки запускав bat-файл для перекодування. Для обмеженої задачі того вистачало. Але тепер стикнувся із тим, що читання файлів у випадковому порядку — з мережевого диска значно повільніше за локальне. Та аналіз кодеків утилітою Mediainfo не закінчився за декілька годин. Отже, вирішив запускати скрипти безпосередньо на Windows.

Але, власне працювати на Windows в мене не було бажання аж зовсім. Зате у Windows є вбудований сервер SSH. Це вже половина справи — можна відкривати термінал та щось там робити. Було б чудово, аби в Windows були нормальні команди оболонки, а не dir замість ls і так далі — але жити можна. От тільки ж Ruby немає.

Ну то й що, chocolatey робить встановлення Ruby в одну команду: choco install ruby mediainfo-cli. Серйозно, без Chocolatey на Windows взагалі немає чого робити. (Також можна було встановити Mise, але поки потреби немає.)

Залишилося питання того, як доставити скрипт на компʼютер із Windows. Окрім того, що можна було змонтувати мережевий диск та редагувати файл прямо там, можна скористуватися звичайним scp, бо він також працює без жодних проблем. Я чомусь про мережевий диск забув, а зробив собі скрипт по типу scp script.rb pc:. && ssh -tt -x 'ruby script.rb'.

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

17.10.2025

Висновки зі спостереження за глюкозою

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

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

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

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

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

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

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

16.10.2025

Моя система ведення нотаток

В інтернеті безліч описів систем, зазвичай епічно складних — всілякі PARA, zettelkasten, графи знань. Може скластися враження, що ведення нотаток потребує академічної ретельності та відданості. Що ж, я так ніколи не робив, мій “граф нотаток” має вигляд тисяч незʼєднаних вузлів, а все-таки (все ж таки) я щодня покладаюся на ведення нотаток та моя система практично не підводить.

Отже, головна ідея моєї системи: система хороша настільки, наскільки легко в ній знайти те, що потрібно.

Як я шукаю? Майже завжди через плагін OmniSearch для Obsidian. (Власне, це тільки продовження моїх давніх звичок користуватися пошуком замість навігації — через LustyJuggler, Alfred, Sublime Text Search in Project, та Cmd+P у VSCode/Cursor.)

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

Наприклад: якщо в мене була нотатка jeans із посиланнями на гарні джинси, але я намагався знайти її за пошуком pants, то коли нарешті згадаю та знайду, допишу в нотатку також слово pants. (А ще часто джинси та штани.)

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

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

Це, звісно, дуже спрощений приклад, бо на практиці нотаток в мене тисячі, і там будуть і jeans from X tv show, і recommended jeans makers, і winter pants, і ще багато всього. Але цей впорядкований хаос залишається корисним — навіть без жорсткої системи.

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

15.10.2025

Міст з узагальненими типами на TypeScript

У Firebase, окрім стандартного для JavaScript пакету firebase, є також неофіційний пакет React Native Firebase. Він побудований на “рідних” інтеграціях для iOS та Android, а тому має переваги саме на мобільному пристрої.

От тільки є проблема: хоч RNFirebase майже збігається зі стандартним Firebase за API, але типи для TypeScript оголошує власні. Що з одного боку логічно, бо кожен має власну реалізацію цих типів — наприклад, і там, і там є клас CollectionReference. А з іншого — унеможливлює написання спільного коду, що буде працювати й в браузері, і в React Native. Або чи правда унеможливлює?

(Окремим аспектом тут є те, що не так давно Firebase перейшов з класового API на функціональний. Тобто замість app.firestore().collection("path") тепер є collection(getFirestore(app), "path"). Що і спрощує, і ускладнює задачу.)

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

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

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

interface FirebaseAPI<CollectionReference> {
  collection(path: string): CollectionReference;
}

class FirebaseLayer<CollectionReference> {
  constructor(api: FirebaseAPI<CollectionReference>) {}
}

export let firebaseLayer: FirebaseLayer<unknown>;

Тепер залишається окремо для мобільної та вебверсії реалізувати інтерфейс з конкретними типами та передати цю реалізацію в шар абстракції. А решта коду зовсім не цікавиться тим, які конкретні типи всередині.

Так вийшло мати на 100% покритий типами код та, можна сказати, мінімум повторення (а повторення все ж є, бо реалізації інтерфейсу майже однакові.)

14.10.2025

Правильні помилки в API

Чи знаєте ви, що існує аж цілий RFC про повернення помилок з API? Ось: RFC 9457 - Problem Details for HTTP APIs. Виглядають ці помилки трохи дивно, як на мене:

{
  "type": "https://docs.leonid.codes/no-mana",
  "title": "We require more mana",
  "detail": "Teleportation spell requires 20 mana, but you have 15",
  "spell": "teleportation",
  "mana_required": 20,
  "mana_available": 15
}

Тут type - це URL, який може вказувати на документацію про помилку. Що мені дуже подобається. title - назва помилки, яка є незмінною. А detail - текстове пояснення, яке вже може містити подробиці про конкретний випадок. Нарешті, окрім цих полів можна додавати будь-які власні.

Альтернативою є формат помилок зі специфікації JSON API. Причому назва JSON API може й загальна, але специфікація досить конкретна та суворо обмежує структуру відповідей. Щодо помилок, то вона вимагає на верхньому рівні ключ errors, а в середині — цілий масив обʼєктів помилок — кожна з яких недалека від RFC 9457.

Логіка така, що в такому повідомленні є й частини, які може прочитати людина, зокрема й в журналі, а також є інформація для машинної обробки. Але чого тут немає, так це success: true або status: "ok", які я звик бачити. Знаєте, чому?

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

Є така тенденція ігнорувати статус та дивитися тільки на зміст. Наприклад, на фронтенді так може “простіше” робити. Чув і такі думки, що статуси HTTP тільки для критичних помилок, а якщо сервер “в тямі”, то може вже давати 200-й із success: false, errors: .... Це все від нерозуміння основ протоколу HTTP.

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

13.10.2025

React Native: екосистема на піску

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

Корінна проблема React Native в тому, що його існування є, певною мірою, хаком. Так, в теорії, писати під всі системи на знайомому JS/TS - дуже зручно. Але реалізація проста тільки в парадигмі компʼютера, де кожна мова рівноправна. Принаймні на iOS, це точно не так (про Android тут нічого не знаю.) JavaScript виконувався раніше на рушії, який не розрахований на повноцінні застосунки, та упирався в суттєві гальма.

Тому історія розвитку React Native - це поступовий пошук кращої моделі виконання для застосунків, написаних на JavaScript. Зверни увагу, остання “нова ера” в цій історії розпочалася 5 днів тому.

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

Наприклад, що було з Сінтрою цього разу: React Native Navigation нарешті вийшов із підтримкою… але не найновішого RN, звісно, а тільки версії 0.77, та яка січня 2025. Тепер React Native Firebase поки не підтримує стандартний режим збірки застосунків та потребує статичних бібліотек. На жаль в RNN поки тільки наздоганяють стандартні вимоги, тому в них немає прямої сумісності зі статичною збіркою. На щастя, хтось зробив патч для поточної версії RNN, яка робить її сумісною. Та після застосування цього патчу, нарешті, принаймні зібралися залежності.

О, і ще, все це хоча б запускається на новому XCode 26, бо в цьому й була мета капітальних оновлень. Можна рухатись далі.

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? Я — давно. А може, варто й почати.