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

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

16.08.2025

Мої перші 5 покупок в Steam.

Інтернетом ходить цікавий тренд — поділитися та прокоментувати перші свої ігри зі Steam. Осьо мої.

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

Абсолютно не памʼятаю, чому я вирішив першою купити колекцію Fallout (а це 1, 2 та Tactics), та ще й не по розпродажу. Розпродажів тоді було значно менше, фактично літній та зимній. Що ж, я досі так і не пройшов жодний з цих Фолаутів, та й напевно не пройду вже — хоча був би просто щасливий гідному ремастеру. Дуже їх поважаю, але керування та інтерфейс не подужаю.
А от TES GOTY Pack (Morrowind + Oblivion) - це моє рідне, тут ніяк не здивований. Перший раз грав в обидві у перекладі, тож, певно, хотілося придбати мовою оригіналу. (До речі, може й з Fallout така саме історія.) Особливо Morrowind й досі час від часу запускаю — а величезні доповнення від Tamriel Rebuilt виходять частіше, ніж я встигаю їх проходити.
Comix Zone - красивенна гра, в яку грали з другом ще на Sega Genesis десь у 90-х. Мабуть, мені гадалося, що версія зі Steam буде зручніша, ніж така що на емуляторі… але насправді виявилося, що ні. Звичайний невидатний порт. Чесно, досі не бачив офіційних портів кращих за емулятори в RetroArch.
“Сталкер: Чисте Небо” - тобто друга частина Сталкера — знову зрозумілий вибір. (А “Поклик Припʼяті” зʼявився в бібліотеці через пів року.) Щось там його зараз на Стімі критикують, але якщо перший Сталкер подобався, то цей це просто додаткова порція того ж самого, що тут не любити.
Та остання покупка зроблена на моєму першому розпродажі — на честь Різдва 2010. Якщо зайти по посиланню, то як Super Meat Boy, так і Deus Ex Collection (з перших двох ігор) були в топі з величезними знижками. Так що все зрозуміло. Super Meat Boy я так і не пройшов, в мене на то терпіння немає — зате син пройшов… пару років тому. :) А Deus Ex - то золота класика, легендарний саундтрек, унікальна атмосфера та нескінченне джерело мемів.

А у вас що як?

15.08.2025

Портативні монітори (та Mac Mini)

Трилогія про Mac Mini завершується щасливим кінцем. Після минулого поста я взяв та купив найдешевший з адекватних портативний монітор Acer PM161Q 15.6" 1080p. Прийшов, розклався підʼєднав — і все працює! Практично як за ноутбуком… з механічною клавіатурою та мишею. Та вилкою в розетці, звісно.

Що я скажу — сучасні портативні монітори дуже зручні! Для підключення достатньо одного кабелю USB-C. Він і живить монітор, і передає картинку. Є й вхід HDMI, який буде корисний нижче. Монітор має форму кришки від ноутбука, тільки товщої рази у два. Опирається на ніжку-скобу, яку можна виставити під будь-яким кутом. Монітор під нахилом — так, дивно, але ж дивитися на нього доводиться зверху, як на ноутбук, тому насправді все зручно.

Є в нього навіть кріплення VESA, тож можна легко кудись змонтувати. Тобто якщо хочеться, користь від такого монітора можна знайти. Наприклад, дивитися на кухні серіали. Завдяки USB-C монітор легко приймає сигнал й з телефону, лише потрібно в другий розʼєм USB-C включити зарядку.

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

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

Так що рекомендую — просте та зручне рішення, прямо unix way якийсь.

14.08.2025

GitHub Actions: Docker Compose замість сервісів

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

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

Вихід, відповідно, очевидний — замінити сервіси на Docker Compose. Кумедно, що весь блок конфігурації services буквально копіюється у docker-compose.yml практично без змін. Потім на початку збірки (другим кроком після checkout) запускаємо docker compose up --detach та бачимо запуск вже за 45 секунд. Ось так, майже без зусиль, півтори хвилини заощаджено з кожної збірки.

Різниці у використанні немає — сервіси так само будуть доступні за тими ж портами, які були налаштовані раніше. Хіба що єдиний недолік — журнал контейнерів з сервісами ми просто так не побачимо. Хоча якщо він прямо потрібний, можна ж забрати з Docker без проблем.

Окреме питання — це величезні образи залежностей, які доводиться тягнути, а саме - OpenSearch, який важить майже гігабайт. Та й запускається він повільніше за всіх. Такий він, Web Scale!

PS. Самому хочеться щось вже позбавитись тих Actions разом із GitHub, але ж для роботи він точно ще довго залишиться.

13.08.2025

Єдиний різновид інтеграційних тестів, що працює

Чим більше років пишу тести, тим більше переконуюсь:

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

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

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

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

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

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

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 для підтримки покупок.

Раніше

Пізніше