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

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

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

31.07.2025

Плагіни для застосунків на Swift (та macOS)

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

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

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

Але також подивляюся в бік плагінів. Не мав великого досвіду з плагінами, отже, гадав, що там все складно — треба тягнути якийсь інтерпретатор, обирати мову, і таке інше. Виявилося, що в macOS є система динамічного завантаження бібліотек — приблизно так само, як .so в Linux чи DLL в Windows, тут є Bundle.

Причому користуватися ними на Swift дуже приємно. Спочатку оголосити протокол, який виконуватимуть плагіни. (Протокол звичайний свіфтівський.) Ну й, звісно, його реалізувати та скомпілювати. Далі залишається завантажити Bundle, викликати в нього метод principalClass - яким вже можна користуватися як звичайним кодом.

На iOS, звісно, завантаження динамічних бібліотек заборонено, але мені поки, припустимо, і не потрібно.

30.07.2025

Якою мовою писати одноразовий скрипт?

Я раніше гадав, що відповідь очевидна, але виявляється, що ні.

Відразу першим кандидатом буде Bash. Мабуть, тому, що в Bash прямий доступ до інструментів командного рядка. Та якщо рішення збирається саме з таких інструментів, то чому і не писати його на баші. До речі, хоч є й інші мови оболонок — для мене насамперед Fish, але скрипти я майже завжди пишу для Bash.

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

На цьому можна було б підсумувати, що скрипти пишуться скриптовою, тобто динамічною мовою, до якої ти звик, та закінчити. Але є винятки. Про один я колись писав - скрипти, що обробляють великі обʼєми даних, варто відразу писати ефективнішою мовою (яка в мене Go).

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

До речі, ще одна перевага “скриптів” на Go - вони самодостатні: не тільки бібліотеки, а й потрібні файли можна зашити в вихідний файл. Та й кроскомпілювати немає проблем. Так що, виходить, Go гарна скриптова мова!

29.07.2025

В пошуках сенсу

В GTD є модель горизонтів фокуса. Це шість перспектив, з яких можна дивитися на своє життя: починаючи з нульового рівня наступних дій, та закінчуючи пʼятим рівнем мети життя та життєвих принципів.

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

Мені було важко почати, бо не хотілося писати зовсім загальні речі штибу “бути чесним”. Справа зрушилася, коли я пройшовся по списку проєктів з питанням “навіщо я це роблю?” Так набирався список тверджень як-от “допомагати близьким” чи “підтримувати форму”. Головне, щоб таке твердження вже давало відгук: так, це воно! Бо, власне, вправа не на вигадування, а на пошук в собі.

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

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

Найцікавіший ефект: поки принципи не усвідомлені, ти можеш почувати себе жертвою обставин. Раціональність за браком фактів тут готова робити нам кривду. Наприклад, я чимало зусиль витратив на розробку плану електрики для квартири, та весь цей час вважав, що це така неприємна праця, яку я мушу робити. Складно — факт. А чому мушу? Можна ж фахівцю віддати? Неясно… А от тільки зараз зрозумів, що мені ж взагалі-то подобається, коли я сам все дослідив та продумав подробиці під себе! Тож тепер така саме робота буде в задоволення, а не в тягар.

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

28.07.2025

Моніторинг для одинаків: постмортем та роздуми

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

Про Hacker News досі не зрозумів. Вона є, тільки порожня. Але, коли запускаю скрипт вручну, то вона наповнюється, але після запланованого запуску знову зникає. Це пахне обмеженнями для ботів, що буде прикро, але в будь-якому разі спочатку треба зрозуміти. Накидав туди логів стільки, скільки влізло, та буду читати.

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

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

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

Тут подивився на n8n, але це такий комбайн, що не схоже, що мені сподобається його підтримувати. Ще знайшов Uptime Kuma - наче непогане рішення, self-hosted, для перевірки ресурсів. Навіть вміє завантажити RSS та подивитися, чи є там тег item. Можна було б його закинути на домашній сервер та нехай собі тестує. Поки ясного рішення немає — хоч здається, на наш час воно повинно бути простим.

27.07.2025

Коментарі для статичного блогу

Отже, коментарі в блогах… взагалі забуте мистецтво, бо як я бачу, ніхто не залишає ніяких коментарів, за виключенням сайтів — спільнот. Але. В мене з давніх часів були коментарі — спочатку з Wordpress, природно. Потім я переписав блог на Ruby on Rails та й коментарі переніс. Потім зʼїхав на статичний блог, а коментарі переніс в модний тоді Disqus (це такі “коментарі як сервіс”, де авторизуєшся один раз на блоки коментарів на всіх сайтах.). Та, нарешті, Disqus спаскудився, то довелося написати власну систему. Яка поки жива й досі.

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

Ні, просто ідея коментарів на сайті — це щось до Web 2.0. Як тільки зʼявилися соціальні мережі, вся культура спілкування в блогах зійшла нанівець. Тому, як я гадаю, найкраще інтегрувати коментарі з чогось такого, чим люди користуються. Навіть бачив системи на основі GitHub Issues.

Або інший, дуже простий варіант: опублікувати власну статтю в якійсь спільноті, а замість коментарів залишити посилання на сторінку обговорення. Наприклад, я бачив “обговорити на Hacker News” чи на Reddit.

Ну а також, обговорення статті ідеально лягає в модель Федиверсу! Можна навіть сказати, що Федиверс створений, щоб обговорювати матеріали незалежно від сайту, на якому вони опубліковані. Головне, щоб сайт був федерований. Тому в простій формі можна дублювати статтю в Mastodon (тощо), а потім показувати відповіді на сайті. Але федерувати статичний сайт (тобто зробити кожну статтю обʼєктом ActivityPub) теж можна — хоч з допоміжним сервером, але не гірше ніж зробити власну систему коментарів. В теорії — до практики я поки не дійшов.

А ще що мені дуже хочеться зробити на своєму сайті — це реакції до постів. Можна навіть використати інфраструктуру коментарів, яка вже є.

26.07.2025

Розділ рецептів 🧄

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

Та й до того, набридло щоразу як просять рецепт, незграбно пересилати його в месенджер. З сайтом можна навіть додати розмітку мікроформату… чого я поки не зробив. Та я ще й світлини не встиг додати, бо це треба мінімум стилів описати.

Також із технічних аспектів в розділу є власний RSS. Це Hugo сам вміє. Так що можете підписатися. Також переніс загальну підтримку коментарів (про які, як виявляється, я ще ніколи не розповідав, а там цікаве рішення, web scale.)

А ще додав зручність: під час перегляду рецепта екран смартфона не гасне. Для того існує API Wake Lock. Дуже просте, до речі — достатньо попросити. Та підтримується всюди, де ця зручність потрібна. На айфоні (принаймні) є нюанс: операція дозволена тільки у відповідь на дію користувача. Тому в мене на то є кнопка (хоча звісно, хотілося б автоматично.)

Ось так. А ви кудись рецепти викладаєте? Або де шукаєте?

25.07.2025

Власний сайт: ресепшн або кухня?

Можна до власного сайту підходити з двох різних боків.

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

А з іншого боку, власний сайт — це ж майданчик, який контролюється тільки тобою. Туди можна викладати все, що заманеться. Сьогодні статтю, завтра текст пісні, післязавтра галерею, рецепт, поробку на JavaScript, цікаві файли конфігурації… Будь-що!

Коли відпустиш очікування про ідеальний дизайн, то зробити це стане зовсім легко. Бо ж залишається написати трохи HTML - і все. Або у випадку з Hugo - навіть Markdown. Написали, опублікували, пішли далі. Хоч в нас не буде професійного дизайну, зате внести дрібні виправлення та побажання можна прямо тут, а не чекати, поки їх реалізує чужий сервіс. Та кожна така сторінка отримує URL, який можна поширити де завгодно, та який ніхто ніколи не відбере та не закриє за авторизацією.

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

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

Раніше

Пізніше