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

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

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

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

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

24.07.2025

Протокол ACME: сертифікати для всіх!

Минулий раз про Let’s Encrypt я писав три роки тому. Відтоді трохи ще довелося попрацювати з сертифікатами, тому розуміння додалося.

Цікаво, що разом з сервісом Let’s Encrypt - який, нагадаю, роздає сертифікати TLS для сайтів — зʼявився й протокол автоматизованої видачі сертифікатів ACME. Річ у тім, що сертифікати хороші, якщо термін придатності їх обмежений, а коли так, їх потрібно оновлювати… чого вручну ніхто раз на 1-3 місяці робити не буде. Зате якщо зробити автоматичний сервіс, то можна зробити щастя.

Це й була революція, яка дозволила всім, аж до домашніх сторінок переїхати на HTTPS. Наразі Let’s Encrypt видає понад 50% сертифікатів в інтернеті! Але чи знаєш ти, що практично всі інші провайдери також впровадили підтримку ACME, причому часто — теж безплатну? Є, наприклад, Google Trust Services. А взагалі ось список.

Тому зараз отримати сертифікат — це прямо дуже легко. Та для цього навіть не потрібно встановлювати certbot чи шукати інший клієнт ACME, бо можна цю підтримку додати прямо у свій код. Для підтвердження сертифіката достатньо правильно відповісти на спеціальний URL на обраному домені, тобто це повністю під силу будь-якому вебзастосунку. (Є ще підтвердження за DNS, його складніше зробити технічно, зате легше підтримувати, бо на кожне наступне оновлення буде однакова перевірка.)

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

23.07.2025

Книги та аудіокниги

📚 Сьогодні вперше дослухав “Убік” Філіпа К. Діка. Але цікаво тут, мабуть, те, що я кілька разів намагався прочитати цю книгу, та ніяк вона не заходила. Ані в перекладі, ані в оригіналі. А аудіокнига пішла — та дуже сподобалась. Книжка 1969 року, а її вплив тепер бачу в багатьох сучасних творах — починаючи з “Матриці”. Та й ідеї комп’ютеризованого, монетизованого світу… ну може запізнилися на 30 років, але нарешті нас наздоганяють.

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

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

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

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

22.07.2025

Три речі, які варто знати про LLM, щоб не робити дурниць

Щось останніми днями триває буря драми навколо LLM, від трагічної історії, як Replit не стримав обіцянки до “відкриттів” про небезпеку MCP. Я часто дивлюся і думаю: ну якщо хоч би базові речі розуміли, то багато питань відпадають самі собою.

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

Друге: LLM є незмінними. Сучасна архітектура не може навчатися в процесі роботи. Ба більше, для навчання LLM потрібна велика кількість прикладів. Ви не можете навчити LLM ні-чо-му. Єдиний спосіб вплинути на вихід LLM - змінити вхідний текст. Тому всі наші правила, а також “памʼять” та інші контекстні дані всі заходять з тим самим текстом (хоч і неявно для користувача.) LLM не “памʼятає”, що ви просили не видаляти базу — вона тільки бачить інструкцію на вході. Разом з епічною кількістю інших інструкцій — сотнями кілобайтів.

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

Ось так. До того ж LLM є серцем (чи мозком?) всіх сучасних “ШІ”. На такому етапі розвитку ми знаходимось. Масштабуванням тут нічого не змінити. Так що поки не почуєте, що зʼявилося щось на заміну LLM - будемо жити з цими обмеженнями.

21.07.2025

Керування проєктами для розробника-одинака

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

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

Досвід роботи в команді мало допомагає, бо командне керування проєктами більше розвʼязує потреби комунікації: хто що робить, хто на кого чекає. От взяти канбан. Канбан цінний, коли за кожний стовпчик відповідає окрема команда, та відразу зрозуміло, в кого скільки задач. А яка мені з нього користь, якщо у “поточних” завжди буде лише одна задача?

Мій улюблений особистий GTD теж мало допомагає в розробці, бо планування програмних продуктів — річ особлива, в ній завершення проєкту не є чітко визначеним. Я пробував додавати в GTD проєкти на кшталт “Ping - наступна версія”, але вони виходять примарними, тож і мало успішними. (А успішними були б проєкти-задачі на кшталт “Додати редагування декількох записів одночасно”, до яких ще треба дійти, про що я й кажу.)

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

Проблема в тому, що я Agile знаю на рівні “спринти та стендапи”, от може книжку треба прочитати та все зрозумію. Поки залишу вас з 10 принципом:

Необхідною є простота — мистецтво залишати незробленою якнайбільше роботи.

Поезія!

20.07.2025

Atomfall: британський не-Сталкер

⚛️ Atomfall - гра, в 40 разів менш популярна за Сталкер 2, та й не є ААА, втім уваги варта. Призвістко “Сталкер в Британії” вона отримала, бо відбувається в карантинній зоні навколо АЕС після якоїсь катастрофи. Але насправді схожість на цьому практично закінчується. (Ну, ще, як я зрозумів, Atomfall зробили британці з такою ж любовʼю до своєї країни, як Сталкер — українці, але я не дуже в цьому знаюся.)

🔎 Насамперед Atomfall гра зовсім іншого жанру. Якщо Сталкер схиляється до симуляції та лінійного сюжету, то Atomfall - гра про дослідження. І мені вона цим дуже сподобалася. Тобі практично нічого не пояснюють. Гра починається з наймінімальнішої мети: втекти! Ну, та спочатку зрозуміти, що взагалі відбувається. Без спойлерів: на то гра дає кілька інтерпретацій та нуль конкретики. Я ще до кінця не дійшов, та досі маю свої версії.

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

👣 Я, звісно, граю в режимі “перевернути кожний камінь”, але може було б цікаво цього не робити, а обрати напрямок та рухатись в ньому, створивши таким чином власний сюжет.

🔑 Прогрес складається з проникнення дедалі глибше в ландшафт та в таємницю. На шляху стоять перешкоди. Замки, до яких доведеться шукати ключі. Інколи є підказка, де ключ, інколи просто доведеться чекати, поки не натрапиш на нього. Та противники: флора, фауна, суспільство.

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

💙 Природа, фантастика, загадки. Для мене такі ігри — як для кота валерʼянка.

19.07.2025

Лимонад

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

🍋 Класичний рецепт - 1 чашка лимонного соку та 1 чашка цукру на 1-1.5 л води. Чашка соку — це приблизно 500 г лимонів, але краще брати з запасом. Зауважу, 1-1.5 л води це на вході, а не на виході. Хоча взагалі завжди можна розбавити більше до свого смаку.

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

Щоб везти на природу, простіше за все купити велику (на 3-5-6 літрів) пляшку води, частину відлити та замінити смачненьким. Можна прямо в ній й мішати, тоді не треба шукати другий великий посуд. Можна мішати й з газованою водою, хоча газу залишається небагато. Або, якщо є можливість, і з льодом.

🫚 Оце, наприклад сьогодні робив 6 літрів лимон + малина + імбир. На цей обʼєм - 2 кг лимонів, 200 г імбиру, чашка малини та 3 чашки цукру.

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

18.07.2025

Приватний ключ як сервіс

Є такий цікавий сервіс, як AWS Key Management Service або аналогічний від Google, ну і так далі. Зазвичай з ними стикаються, коли треба щось десь зашифрувати — наприклад, відро (хахаха) у S3 чи зміст однієї з баз. Тому з першого погляду може виглядати так, що цей сервіс — внутрішня абстракція, та на цьому його користь закінчується.

Але насправді той AWS KMS - це сховище звичайних криптографічних ключів. Тільки в цьому випадку, нам доступні тільки публічні ключі, а приватні — приховані за API. Таким чином ми можемо створити собі криптографічну пару, ніколи не знаючи приватного ключа, а потім шифрувати, дешифрувати, або підписувати через відповідні API.

На що таке потрібно? Ну, як, по-перше, то з KMS легко керувати дозволами на ключі, бо права задаються звичайним IAM. Можна кому завгодно дати можливість підпису, та не перейматися про те, що вони втечуть з приватним ключем. Це насправді величезна перевага.

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

До речі, а як щодо сертифікатів? Тут треба згадати, що сертифікат - це лише публічний ключ із додатковою інформацією. Хоч в KMS не можна зберігати сертифікати, але й потреби не має — достатньо підписати Certificate Signing Request ключем з KMS, та у вас буде сертифікат, яким можна підписувати теж через KMS. (Бо технічно, підписують ключем, а не сертифікатом.)

З недоліків, звісно, те, що зі звичайними інструментами KMS не працює. Тобто публічний ключ отримати легко та весь код, якому потрібний він, можна залишати без змін. А ось код підпису (чи шифрування) доведеться переписати з використанням API. Хоча оце тільки що дізнався, що для сховища ключів є стандартний інтерфейс PCKS 11, та існують реалізації його для KMS - тобто не все так погано.

Раніше

Пізніше