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

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

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

02.08.2025

Три навички, які потрібні інженеру для росту

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

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

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

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

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

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

Як бонус — вміння побачити кінець та не йти далі. На цьому все.

01.08.2025

Асимптотична оптимізація

Роб Пайк казав, що оптимізувати наперед не варто. Та в цілому, я згодний з цим! Оптимізація майже завжди ускладнює код або загрожує багами, отже, писати “заздалегідь оптимізований” код — погана звичка.

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

Для того є просте правило. Поки пишеш код, потрібно мати на увазі та враховувати, скільки циклів та рекурсивних викликів він робить. Бо це впливає на асимптотичну оцінку складності — чи буде програма O(N), O(N²) тощо. Від цієї оцінки дійсно залежить, чи буде наша програма літати або лежати.

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

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

Тому я б не дуже переймався таємними знаннями на кшталт “якщо переставити ці два аргументи місцями, операція буде на 20% швидше”. Та тим паче не поспішав впроваджувати в код. Краще вивчити О-складність — спочатку базових алгоритмів, а потім на конкретних структурах даних у вашій мові та СУБД.

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

Раніше

Пізніше