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

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

12.08.2025

Бюджет на рішення (так, я про гроші)

Давайте про дуже важливе питання, яке я особисто довгу частину своєї карʼєри не розумів.

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

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

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

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

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

Все це ще більше стосується власних проєктів, де ніхто тобі не платить. Бо там ще менше часу! Чи хочеш ти витрачати цей час на розробку корисних можливостей, або на налаштування нотаризації під macOS?

11.08.2025

Нотаризація програм під macOS (наче все працює)

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

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

Для випуску програми я беру GoReleaser. Ця утиліта поєднує всі кроки — від збірки до створення версії на GitHub та відвантаження архівів. Але підписувати вона… вміє з недавніх пір, втім, тільки в версії за підпискою — на яку мій масштаб поки не заслуговує.

В GoReleaser є підтримка підписів, теоретично (секція signs), але ці підписи мають конкретну реалізацію (GPG тощо) та ніяк навчити того, що нам потрібно, не вийде. Тому дивимося далі.

Варто тут зʼясувати, чого ж від нас хоче Apple. Тут автентифікація складається з трьох частин. Спочатку підпис сертифікатом розробника (sign) - так само як і GPG - це криптографічний підпис, який каже, що програму скомпілював не аби хто, а я. Далі нотаризація (notarize) - а це вже особливий для Apple крок, коли ти надсилаєш програму на їхній сервіс, вони її перевіряють та реєструють в базі даних. Так, в Apple є центральна БД всіх перевірених двійкових файлів! Нарешті, коли користувач запускає застосунок перший раз, ОС перевіряє його в цій базі — що потребує підключення. Цього можна уникнути, якщо завантажити та прикріпити квиток нотаризації (staple) до пакета.

Перші два кроки на 2025 рік є практично обовʼязковими, бо без них програма в користувача не запуститься без спеціальних дій. Та так, пакети з Homebrew та інші серйозні застосунки так і роблять. (Або інший вихід — збирати двійковий файл локально.) Прикріплення теж варто робити, але то потребує пакування в епловський формат - .dmg, .pkg чи принаймні .app. Я б і не проти, але безплатний GoReleaser їх не робить.

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

Весь процес збірки диригується GoReleaserом. На збірки для macOS в нього поставлений постхук. Хук викликається після компіляції, генерує конфігурацію Gon, робить всю магію, в тому числі пакує в ZIP, надсилає на нотаризацію, а потім розпаковує та вертає підписаний файл назад на місце.

З усього цього, певно, найскладнішим було те, що хуки GoReleaser запускаються без оболонки! А значить, в них не працює перенаправлення виходу, умовне виконання та інші оболонкові функції. Коли збагнув, що треба все завертати в sh -c, справи пішли.

(PS: сиджу і думаю - чи варті були всі ці зусилля, щоб заощадити 11 доларів на місяць на GoReleaser Pro?)

10.08.2025

Какао

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

З незвичайного — можна знайти густий шоколад з крохмалем — це італійська рецептура. Мабуть, моя улюблена з того що можна зробити вдома без викрутасів (про які нижче.) Ну й зʼявляються місця, де какао роблять без цукру, а ще й не просто на порошку (бо какао-масло робить важливий внесок). А щоб без молока - ніколи не бачив. Ще у “Львівській майстерні шоколаду” готують топлений шоколад — це буквально розтоплена плитка. Але він ну зовсім солодкий.

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

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

Какао-маса збивається з гарячою водою блендером, в співвідношенні десь 10:1. Отримуємо напій, який нагадує еспресо за насиченістю та характером, але на відміну від нього жирний. (Ясно, що масло не плаває на поверхні, а створює емульсію.) Тож, мабуть, скоріше bulletproof еспресо, якщо чули про таке. Для мене це єдиний гарячий напій, який може змагатися з кавою.

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

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

08.08.2025

Тимчасове робоче місце для Mac Mini, коло друге

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

Виникає питання — а як тоді працюють сервери з macOS - бо такі існують? З того що я розумію, у них вимикають шифрування диска FileVault. Я, звісно, для робочої машини так робити не буду. Інший, дорогий варіант - KVM, тобто емулятор робочого місця через мережу. А от на Windows компʼютер готовий завантажуватися і з шифруванням — в мене так і є, компʼютер з доступом тільки через мережу та Parsec.

Спробував заходити на робочу машину через Parsec або TeamViewer. З них двох тільки Parsec дає зручне керування, бо, наприклад, Cmd+Tab та Cmd+Space передає. Та якщо робоча машина підключена до Ethernet, я б сказав що навіть з іншого міста та з Wi-Fi можна працювати. Але, в мене через деякі причини (можливо, налаштування безпеки?) Parsec періодично викидав з сеансу. Також ризик того, що машина чомусь вимкнеться, залишається.

Нарешті, варіант простий, але дієвий: купити портативний монітор. За 100 євро є 15-дюймові моделі від пристойних брендів. Може це не так круто, як відкривати VNC через Thunderbolt Ethernet Bridge, зате перевірено та надійно.

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

08.08.2025

Хтось повинен стежити за оновленнями

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

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

Отже, я пропоную такий варіант. По-перше, потрібно визначити особу, відповідальну за перевірку оновлень — це може бути інженер підтримки, наприклад. ЇЇ задача — раз на тиждень (чи кілька) переглядати залежності та приймати дії.

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

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

Для важливих залежностей можна підписатися на RSS - кожна сторінка релізів на GitHub її має, навіть якщо офіційний сайт проєкту — ні. Я підписаний на все, що хочу тримати свіжим.

Оце якщо для такого підходу є автоматизація, зокрема для моїх улюблених Ruby + JS + Go, то прошу поділитися.

07.08.2025

Пʼять фактів, щоб краще зрозуміти React Native

React Native відрізняється від React тільки набором компонентів. Тож замість div буде View, замість p - Text тощо. Ці компоненти створюють справжній набір відповідних “рідних” компонент пристрою. (А якщо так подумати, то div та p в React для вебу теж не “є” тегами HTML, а тільки створюють вузли DOM - поведінка така сама.)

Все інше, що ти знаєш з React, продовжує працювати й в React Native. Власні компоненти, хуки, контексти, модель, Redux, Reselect, Axios, і так далі. Також це звичайний JS/TS. (Хіба що тулчейн буде особливий - Metro замість всього, до чого звикли в вебі.)

В React Native власна модель викладки, яка майже повторює Flexbox. Та вона нам дуже корисна, бо мобільні пристрої бувають всяких різних розмірів. В мене взагалі так вийшло, що я цей флексбокс вивчив саме в контексті React Native, в той час, як на вебі користувався старішими рішеннями. Сподобалось! На мобільний пристрій дизайнити екрани якось легше, бо вони тебе заздалегідь обмежують та нема такого відчуття великого порожнього аркуша, як на вебі.

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

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

Майже всі мислимі можливості покриті бібліотеками. Завжди всі питають “наскільки легко інтегрувати то чи інше”. Практично завжди відповідь “на то є бібліотека!” Все те, що не входить в базовий комплект, можна знайти на NPM, наприклад: react-native-iap для підтримки покупок.

06.08.2025

JSON Canvas Tools

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

Що я сьогодні й зробив: результат тут. Для початку переклав на Go. Бо ділитися скриптом на Ruby має сенс тільки серед рубістів, а от скомпільованою утилітою може скористатися будь-хто. Причому на Go я легко зроблю версії під всі платформи — на то є GoReleaser.

Знайшовся вже готовий пакет supersonicpineapple/go-jsoncanvas для роботи з JSON Canvas… ну як роботи — головне, що він схему описує, щоб мені цього не робити.

В принципі, можна вже зараз забрати інструмент та користуватися. Але наразі стикнувся з проблемою підписів. MacOS взагалі відмовляється запускати файл без підпису. Такий саме що я тільки що скомпілював — дає. А якщо його ж завантажити з GitHub - вже не можна. На Windows проблеми схожі, але ми можемо скасувати перевірку.

Причому якщо на MacOS в мене і дійсний сертифікат є (він, якщо що, коштує $100 на рік), то на Windows немає та я навіть не знаю що там за процедура поки. Доведеться розібратися.

05.08.2025

Канбан та нащо він гідний

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

Це мені нагадує сімейний список покупок: коли закінчилася гречка, її записують в список (у нас для цього стіна — майже канбан!) Коли в списку достатньо пунктів, час піти за покупками.

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

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

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

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

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

04.08.2025

Наш світ побудований маркетологами

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

Мораль історії в тому, що будь-який продукт мало зробити, його треба ще й продати. Сам продукт не продасться. Так, хтось про нього дізнається, хтось поділиться… але такий підхід не масштабується.

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

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

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

03.08.2025

Перший погляд на Nushell

Оскільки вже кілька людей радили подивитися на Nushell, вирішив все ж випробувати.

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

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

(Для порівняння, Fish теж не повністю перетинається з POSIX Shell, але принаймні структура викликів однакова, а різниця зазвичай суто синтаксична. Зі скриптами все складніше, але я нею скрипти й не пишу.)

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

Найбільш помітним в Nushell є використання конвеєрів | для обробки структурованих даних. Для мов оболонки це інновація, але для Ruby (чи будь-якої сучасної мови програмування) нічого особливо нового. Гарно, що вбудована візуалізація для таблиць, Гарно, що є підтримка різних форматів даних. Не просто JSON, а, наприклад, Excel - що натякає (спойлер), що може я - не цільова аудиторія.

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

Одним словом, Nushell для мене знаходиться в дивному місці посередині, та не спокушає замінити ані Fish, ані Ruby.

Але зате з позитивного: що Nushell піклується про гарну підтримку Windows. Тому, гадаю, якщо в когось потреба працювати і на *nix, і на Windows - то це дійсно гарний варіант оболонки. Та заміна знайомих утіліт командами оболонки просто рятує - бо у Windows зовсім інший набір. (Між Linux та macOS різниця незначна та стосується лише окремих опцій, які ти здебільшого просто уникаєш або обходиш псевдонімами.)

Раніше

Пізніше