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

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

27.06.2025

Цінність коду відʼємна

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

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

Я гадаю, людям складно думати про код, бо це зовсім новий ресурс. З фізичними ресурсами практично завжди зрозуміло, що більше витрат — не краще. (Хіба якщо ви отримуєте відкати за цеглу. Що можна порівняти з оплатою за рядки коду.) Але код — це інформація, вона нічого не важить. Коли пишуть для людей, то всі знають, що треба писати стисло. Але код не читають, як книжку. До того ж як взагалі виміряти видачу програміста, окрім як кодом? “Реалізований функціонал” це щось зовсім уявне.

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

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

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

26.06.2025

Федиверс та Mastodon - що то є

Сьогодні у Федиверсі виникла дискусія — що таке Pleroma та чим вона відрізняється від Mastodon. Оце захотілося ширше про все це розповісти, бо я для себе копався, коли робив адаптер для Mastodon до OmniWOPE.

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

Якщо це звучить надто абстрактно, то так воно і є. Бо хоча ActivityPub чітко задає логістику повідомлень, але їхній зміст залишає відносно вільним, щоб охопити будь-який зміст. Тому Федиверс містить не тільки умовний Твітер, але й базу туристичних маршрутів Wanderer, відеохостинг PeerTube, аудіохостинг Funkwhale, також інтеграції від WordPress або Discourse та, звісно, Mastodon.

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

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

Сам собою Mastodon - дуже успішний клон Твітеру для Федиверсу. Але ще важливо, що API для клієнтів Mastodon став де-факто стандартом, тому такі сервери, як Pleroma чи GoToSocial, його реалізують. А клієнти, як Mona, Tusky, чи Ivory, таким чином підтримують не тільки Mastodon, але й ці сервери теж. (Не завжди ідеально.)

От, виходить, коли кажуть Федиверс — то йдеться про загальну світову децентралізовану мережу. А коли Мастодон — то про її потужний твітеро-форматний сегмент, який має спільні клієнти та загальні домовленості про зміст повідомлень. Але не тільки сам Мастодон, присутня певна генералізація. 🦣

25.06.2025

Клавіатура — це питання смаку

За ті пару років, які минули з попереднього поста про клавіатуру, знову багато змінилося. Зараз в мене Lofree Flow84. Але головне — я, нарешті, зрозумів, що клавіатура — це питання смаку, та щоб не марнувати гроші у гонитві за новим та модним, варто зрозуміти, який смак у тебе. Ось що я поки зрозумів про себе:

🫓 Я люблю пласкі клавіатури. А не товстенні друкарські машинки на кшталт Keychron Q1. Зокрема, коли ти час від часу працюєш на ноутбуці, контраст допікає. Але також мені не подобається вигинати кисть догори, навіть із підставкою під долоні, яка з Q1 стає майже обовʼязковою.

📏 Я люблю розмір 84. Це теж наближено до клавіатури ноутбука. Більше клавіш не потрібно, та вони тільки заважають на столі. Проте я не хочу відмовлятися від функціонального ряду або повнорозмірних стрілочок.

🚝 Мені потрібний металевий фрезерований корпус. Бо клавіатура повинна бути важкою та точно не гнутися. (Зокрема, в мене є Keychron K3 зі штампованим корпусом, яка трошки, але помітно зігнулася, та хитається з кожним натиском.)

🪨 Мені потрібні клавіші з PBT. Головний аспект відчуття від клавіатури — це які на дотик клавіші. Поки я знаю, що ABS - це не моє, а PBT - гладенький, щільний, надійний. Хотілося б колись випробувати екзотичні керамічні та деревʼяні клавіші.

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

🌚 Мені не потрібна підсвітка. Ну не дивлюся я на клавіатуру взагалі, вона тільки відвертає від екрана. До речі, це єдиний недолік Flow84 - смужка світла на передній грані, яку неможливо вимкнути. На щастя, натомість її можна заклеїти чорною ізострічкою (незамінний засіб!)

🔌 Мене не важлива бездротовість. Клавіатура майже не рухається, тож наявність дроту практично не заважає (на відміну від миші). До того ж кабель залишається найшвидшим та найнадійнішим способом підключення.

⚙️ Мені не важливе програмне забезпечення. Ну… мінімально. Бо різні клавіатури мають сюрпризи, коли доходить до поведінки функціональних клавіш тощо. Майже для всього іншого є Karabiner Elements.

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

24.06.2025

Карта Чорногори — початок

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

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

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

До того ж карта вимагає набору супутникових знімків та даних висоти, які я завантажую з MapTiler та зшиваю в потрібну мені текстуру. Для того був (та на щастя, зберігся!) набір скриптів — то на Ruby, то на Go, то на JS. Але скрипти знов-таки потрібно адаптувати, а спочатку, згадати, що з них як працює. Пізніше буду робити єдиний скрипт, щоб можна було задати координати треку та автоматично зібрати повністю всі ресурси.

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

23.06.2025

Особливості кешу в GitHub Actions

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

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

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

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

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

Як компроміс, я вигадав використовувати в якості ключа дату: тоді кеш буде не старіше за день, та в нас буде не більше 7 копій одночасно.

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

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

22.06.2025

Стан потоку та програмування

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

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

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

В інших станах не все так погано. Ну хіба що хотілося б хоч деколи бути в потоці. То може для того варто тримати беклог складних задач з твоєї експертної галузі, та підмішувати в план за потребою. Здається, я тільки що обґрунтував потребу в Axe Friday. 🪓

21.06.2025

Стан потоку

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

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

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

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

20.06.2025

Місце паперовому блокноту

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

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

По-перше, мені подобається планувати в блокноті день. Щодня відкриваю новий аркуш, з одного боку розписую календарні події, з іншого — просто задачі. Раніше хотів знайти (чи зробити!) для того застосунок, але блокнот дійсно зручно, а головне — гнучко. Наприклад, з розкладом не обовʼязково точно знати годину та хвилину, як в цифровому календарі. Пиши, як хочеш.

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

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

Ну й найкраще в блокноті — що це доступний завжди вільний аркуш! Як треба щось розписати, запланувати, накреслити — гортаєш на наступну сторінку та вперед.

19.06.2025

Мій літопис операційних систем

…Як всі нормальні українці, я починав з Windows. Першою ОС, над якою я відчував хоч якусь власність, була Windows 98, серійник від якої багато хто памʼятає напамʼять. Саме на Windows я навчився програмувати, та заробляти перші справжні гроші. Та Windows давав широкий лан для творчості — ігри, графіка, системні утиліти всякі, та, звісно, вебпрограмування, на якому я й побудував карʼєру. Славетний стек AMP (Apache, MySQL, PHP) чудово почував себе на Windows, та що цікаво, я навіть не думав про командний рядок. Все робилося через графічний інтерфейс, від операцій з файлами до роботи з базою чи конфігурацією вебсервера. PHP навіть розгортувати можна було через графічні файлові менеджери, та майже не піклуватися, що на сервері інша ОС.

Linux на десктопі для мене почався з Ubuntu 7.10, її треба було замовляти на компакт-диску, бо завантажити було нереально довго. Та, якщо так лічити, то десь чотири роки я з ним боровся; спочатку по-звичайному. Ніколи в мене не було все гаразд з драйверами, особливо на ноутбуках. Потім винайшов для себе віртуалізоване рішення та ще якийсь час використовував з-під Windows. Зараз не можу згадати, але здається, почав Linux просто через моду. Хоча, звісно, це принесло переваги: зокрема, можна було локально запустити nginx, або розробляти багатопроцесові програми в такому ж середовищі, як на сервері. Ну й все, що з Ruby повʼязано, краще працювало в *nix.

Та, нарешті, у 2011 я купив перший макбук (який, до речі, досі живий), та відтоді робоча ОС в мене macOS. Макбуки були надзвичайно популярні у рубістів. (Я ще пригадую в Railsware десь у 2010 була сторінка компанії, де прямо й було написано “ми любимо наші маки”.) Пропозиція macOS проста: це серйозний Unix для користувачів. З одного боку — все майже так, як на сервері — від файлової системи та моделі процесів до конкретних програм та програмних комплексів. А з іншого - macOS - це справжній ОГ графічних інтерфейсів, та культура якісних застосунків тут зародилася та досі залишається найсильнішою. Та до того — ніколи ніяких проблем з драйверами (поки не почнеш підʼєднувати щось рідкісне.) Та найкраща на десктопі модель безпеки.

За ці роки багато всього змінилося. Зокрема, зʼявився Docker, завдяки якому тепер легше мати на десктопі оточення, ще ближче до сервера. На Windows тепер є офіційний віртуалізований Linux. Багато продуктів переїхало в браузер (чи Electron), тим самим зрівняв поведінку всіх трьох систем. Але щоб я думав змінювати робочу ОС? Та ні в якому разі.

18.06.2025

Як я прийшов до Git

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

Розкопав в історії, що я перейшов на Git 16 років тому — у 2009. Вмотивовано було це роботою. Найбільш дивне для мене те, що на GitHub я зареєструвався лише через місяць — значить, у нас був власний сервер Git? Оце так хотілося?

(Насправді, GitHub тільки років з сім тому дозволив безплатні приватні репозиторії. Я памʼятаю, бо один наш проєкт завдяки цьому переїхав з GitLab. Тому, ймовірно, у 2009 GitHub не входив у бюджет.)

До Git в мене був Subversion. Головне, чим він запамʼятався — гілка була копією всіх файлів, а через це їх робили тільки за великою потребою. Також SVN централізований, тобто коміти відбувалися на сервер, отже: повільно, з конфліктами з чужими змінами, та тільки за наявністю звʼязку. Це як замість git commit завжди був git push в main. З усім тим, я навіть тримав SVN для власних проєктів, бо контроль версій це велика допомога.

(До Subversion я ще памʼятаю Visual SourceSafe, де щоб відредагувати файл, його треба було “бронювати”, тобто ніхто інший міняти його не міг. Можете собі уявити, як воно весело — часто доводилося підходити до колеги та просити звільнити файл.)

А ще на початку десь поруч з Git був Mercurial. Я нарешті згадав, чому ніколи серйозно його не роздивлявся. Просто Ruby on Rails був на Git! А я на той час вже почав писати на Rails. Потім став успішним GitHub, та тепер вже ніякої конкуренції між Git та Mercurial немає.

Чи хотілося б чогось іншого за Git? Ну в нього є слабкі сторони, як-от версіювання великих файлів, чи підмодулі, які часто виходять незграбними. Проте він абсолютно “good enough”, та це чудово.

Раніше

Пізніше