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

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

10.05.2025

Нова версія гему Headless та ШІ для розблокування проєктів

Сьогодні випустив оновлення для Headless. За всіма вимірами, це треба було зробити вже давно, але краще пізніше, ніж ніколи — принаймні, якщо люди все ще просять. (Я вже писав), що мені він давно не потрібний. Десь з рік тому до мене зверталася людина та пропонувала зайнятися підтримкою, та я навіть доступи надав, але… в неї теж поки не знайшлося часу, напевно? Історія класична. Десь з тиждень тому мені знову нагадали, що гем не працює з сучасним Ruby, тож вирішив взятись.

Як я себе змусив це зробити. Думаю, ну мені не хочеться - Cursor зможе. Успіхи з Cursor були різного рівня.

Замінити Travis CI на Github Actions - впорався на 95%. (Чомусь запхав у виконання тестів xvfb-run, хоча вся суть мого гему, що він заміняє xvfb-run для програм на Ruby.) Це чудово! Я вручну б довго сидів та розбирав синтаксис.

Оновити матрицю версій Ruby для CI - впорався на 100%. Теж гарно, бо це наче просто, але довелося б бігати по сторінках завантажень Ruby та JRuby.

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

Додати Rubocop - тут я б сказав 30% успіху — наче щось виходило, але конфігурації забагато та rubocop-rails намагався теж впхати.

Виправити Rubocop - цього взагалі не раджу робити, хоча в мене були великі сподівання. Бо код псує більше, ніж виправляє. Причому псує в сенсі змінює зміст. А я зрештою замінив Rubocop на Standard - це надбудова над Rubocop із переконаним набором налаштувань. Окрім іншого, Standard добре виправляє помилки та підійде навіть в ролі автоформатувальника. Навіщо ШІ, коли є спеціалізований інструмент?

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

09.05.2025

Пошук по каналу на сайті за допомогою Orama

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

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

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

Моє рішення складається із чотирьох частин. Спочатку, під час побудови сайту Hugo генерує зміст JSON. Це для мене вже знайомий крок, бо так само працює OmniWOPE.

Потім, теж в скрипті постачі, запускається окремо індексатор. Він перебирає вхідний JSON та генерує величезний (22 Мб!) JSON індексу. Цей файл потрапляє в збірку серверних функцій Vercel.

Далі є функція /search - вона завантажує той індекс з файлу та викликає пошук Orama — це вже досить прямолінійна дія.

Та нарешті, є фронтенд, який теж нагенерував Claude, бо мені не хотілося довго возитися із шаблонами. Фронтенд робить запити до API та виводить список результатів. Попросив Claude “no frameworks, use HTML DOM API” та в цілому отримав те що хотів. Потім додав “use css classes and html tags from post list page”, бо на початку він наробив власних стилів. Якось так.

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

08.05.2025

Повторювані залежності Yarn зі станом — обережно!

Припустимо, у вас в package.json підключена інтеграція… ну скажімо @some/core та @some/angular. Раптом приходить Mend, та каже — в @some/core вразливість, оновлюємо її! А з @some/angular все добре, її залишаємо. Дякуємо Mend, оновлюємо, живемо далі.

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

Річ у тім, що в кожного пакета (та в нашого застосунку) свої вимоги до версій залежностей. Та якщо вони не збігаються, Yarn надає кожному пакету власні екземпляри залежності потрібної версії. Тобто застосунок отримує оновлену версію @some/core@1.2 та @some/angular@1.1, а останній, якщо в нього, як часто буває, жорстко задані версії внутрішніх залежностей, в собі може приховувати @some/core@1.1.

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

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

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

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

Але головне, що ви тепер знаєте, що таке буває, та роздвоєння особистості в пакета не стане сюрпризом.

07.05.2025

Опорні конструкції Ruby on Rails

🛤️ Якщо ти ніколи не працював з Ruby on Rails, а тільки дивився, то я гадаю, головні переваги просто залишаться непоміченими. Зокрема, тому, що в Rails безліч зручностей, яких немає в інших середовищах. Ну це як коли несподівано дізнаєшся, що вода з-під крана питна та смачна, та більше не треба думати, де її взяти — цілий шар проблем відпадає.

До мови Ruby можна ставитися по-всякому. Я, як 4 роки тому любив, так досі й люблю. Як і Ruby on Rails. На своєму місці, звісно. Але тоді я писав тільки про якості мови та архітектури застосунку. Які, дійсно, мають власну нішу.

Проте що я залишив неоціненим, це як багато Ruby on Rails допомагає в розробці.

Міграції для бази, рідною мовою та з вбудованою можливістю відкотити, зберегти схему, відтворити будь-де. Конфігурація оточення для розробки, тестів, продакшна. Інтерактивна консоль, де відразу доступні всі можливості застосунку. Генератори коду під все що завгодно. Це все — вже в базовому комплекті.

Також філософія Rails в тому, щоб надати надійну основу для будь-якої задачі. Тому поступово зʼявлялися модулі для: секретів, відкладених задач, завантаження файлів, вебсокетів, тексту з форматуванням. А такі речі, як компіляція JS/CSS, надсилання пошти чи інтернаціоналізація, були “з коробки” ще 15 років тому. Нещодавно зʼявилося офіційне рішення для розгортування через Docker.

Думаю, найпростіше з усім цим можна ознайомитися з Rails Guides.

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

06.05.2025

Карі

🥘 Є така приправа — карі. її всі знають. (В Берліні варять сосиску, ріжуть на шматочки, посипають карі та кетчупом — називається карівурст.)

А ще є листя дерева карі, яке використовується в деяких карі. А ще є цмин італійський — який теж звуть “кущ карі”.

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

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

Але я взагалі не про те. Є така операція — каррінг, а англійською - currying. Це коли ви функцію багатьох аргументів розкладаєте у вкладені функції одного аргументу. А в практичному сенсі, зазвичай, навпаки — відкусюєте від великої функції декілька аргументів:

function queryDB(db, query) {}
const query = _.partial(queryDB, myDB); // queryDB(db)(query)
query("SELECT foo");

У функціональному стилі програмування через каррінг можна спрощувати код та приховувати деталі реалізації — схоже до інкапсуляції в ООП. Та для того є гарна порада — аргументи функцій завжди впорядковувати від найбільш сталих до найбільш змінних.

А що спільного в каррінга зі смачною підливкою? Аж нічого! Бо названа ця операція на честь математика Гаскелла Каррі, так само як і мова Haskell.

05.05.2025

Середовища для тестів та для розробки

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

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

Але я навіть не про те хотів сказати. Я, з подачі колеги, ось що згадав: інструменти для налаштування тестового середовища значно зручніше, ніж робочого. Причина проста — тестове середовище ми відтворюємо багато-багато разів, а робоче… ну може коли новий працівник приходить, чи після якоїсь катастрофи. Гарно, коли для розробки є скрипт (в Rails це seeds.rb), але за досвідом він майже завжди застарілий, бо його майже не використовують. Та й локальне оточення буде застарілим, якщо єдиний спосіб його оновити — це все перестворити наново.

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

А якщо піти далі (що й пропонував колега), то можна запустити інтеграційні тести з відкритим браузером, а посередині поставити на паузу та далі взаємодіяти із застосунком в потрібному стані.

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

04.05.2025

Цикли ефективності

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

🐹 Режим хомʼячка — це коли робиш те, що спадає в очі. Згадав — зробив, не згадав… не зробив. Звісно, здебільшого робиться гостре. А також багато цікавого; особливо цікаво починати нові справи, а не закінчувати старі нудні. В такому режимі можна теж робити круті речі, але рідко ті, що не вимагають від себе уваги.

🧨 Накопичення роботи — зазвичай з таким ставленням стає дедалі більше справ. До того ж справи, які були важливі, але не термінові, не робляться, та згодом стають терміновими. Поступово “режим хомʼячка” створює більше та більше стресу.

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

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

🌸 Ефективність — з налагодженою системою робити прогрес стає легко! Навіть ті проєкти, на які хом’ячок дивився як на фантазії, піддаються аналізу та поступовому прогресу. А ти згадуєш ще більше цілей. (Ідеї люблять порожню голову!)

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

😵 Та все починається наново — система розвалюється, та я знову починаю робити те, що горить або цікавить. До нової кризи…

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

03.05.2025

Синдром непотрібного узагальнення

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

Може, ми робимо табличку в базі для телефонних кодів країн, хоча тих кодів лише 200 та вони влізуть у словничок. Може, нам доручили зробити архітектуру, яка підійде для будь-якого хмарного провайдера, але фактично замовника цікавить лише три з них, а різницю можна висловити декількома ifами.

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

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

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

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

02.05.2025

Що я любив у Pivotal Tracker

…Якщо в мене й був улюблений трекер робочих задач, то це Pivotal Tracker. Той, що два дні тому закрився, та ще й так суворо, що навіть стилі блогу злетіли — а можливо, невдовзі зникне й сам блог. Згадаю, чим Pivotal Tracker був такий хороший.

(Я навіть давно писав клієнт командного рядка, а потім інтеграцію з OmniFocus). А колеги з роботи писали доповнення для Chrome. Одним словом, років 15-10 тому це було прямо явище.)

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

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

Але ця сфокусованість була й недоліком Pivotal Tracker. Він вимагав дуже чіткого процесу розробки (можна було б сказати - Agile - але це слово може значити аби що.) Ну, наприклад: PT автоматично бʼє роботу на спринти, дивлячись на оцінки та швидкість виконання. Для цього потрібна однорідна команда, де хто завгодно може підібрати задачу.

Pivotal Tracker був продуктом із вбудованою методологією. Що в цілому не так далеко від того, як я сам думаю про продукти, та вважаю, що це чудовий підхід, коли ця методологія є (У Pivotal Labs - величезної та успішної фірми з розробки — була.)

До речі, з живих досі продуктів мені ще подобався Shortcut, тоді відомий як Clubhouse. В нього із Pivotal Tracker є дещо спільне. А ще хтось зробив сайт Goodbye Tracker, де зведені понад 10 альтернатив — деякі дуже зрілі!

01.05.2025

Штучний інтелект — хто виграє від нього найбільше?

Перше, виграють виробники потужностей. Всі великі виробники компʼютерів вже вийшли з “AI” пристроями. Дуже вчасно зʼявилася причина оновити компʼютер, бо якщо не дивитися на “AI”, то останніми часами компʼютери стали достатньо потужні, щоб не думати про наступний. (Бо в моєму дитинстві компʼютер оновлювали, щоб на ньому можна було подивитися фільм.)

“AI” це золота жила тому, що його можна продавати будь-кому — від малої дитини до панів в костюмах. Зокрема, подивимося на відеокарти. Ресурси для відеоігор досягли стелі якості, за якою їх нерентабельно виготовляти. Та й ринок все одно обмежений. А тепер можна скільки завгодно потужностей продати заради “АІ”.

Хоча понад усе виграють власники хмар. Бо, цілком очевидно, що ніж купувати дороге залізо, можна заплатити хмарі. Тому, коли зараз кажуть, що пристрої “з AI” не мають попиту, я гадаю, що споживачу хмари достатньо. Наперекір сумнівному ставленню хмарних компаній до етики — про яке можна судити вже з того, що вони вже тренують моделі навіть на піратському контенті.

Друге, це ринок стартапів. У тому вузькому сенсі, як продуктів, які будуються, щоб отримати інвестиції або продати задорого та швидше. Інвесторів легше переконати, коли за тобою стоїть Технологія Майбутнього, Яка Тільки Відтулила Двері Для Найрозумніших — хай то бізнес в інтернеті, соціальні мережі, блокчейн чи тепер AI. Тому серйозні стартапери не шукають революційних ідей, а застрибують в поточний Віз Революції та галасують якомога гучніше, що Віз справжній, а хто на нього закине грошей — поверне їх встократ.

Я поки не добрався до того, що ж все ж таки “AI” здатний чи не здатний робити, як-от генерувати красивий ввічливий лист, або, наприклад, підсумувати задовгий лист до його змісту. (Жартую.) Давайте так — багато на що здатний. Про це іншим разом.

Раніше

Пізніше