Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

Пости з тегом #HugoWope

11.09.2022

Бот для відправлення постів у Telegram

🤖🤝😁 Сьогодні метапост: я запостив цей пост за допомогою бота, який теж написав сьогодні. До цього пости публікував вручну через додаток Telegram.

Навіщо це потрібно? Є декілька важливих переваг:

Телеграм-бота створити досить нескладно — для Go є бібліотека, а реєстрація проходить через телеграм-бот @BotFather та займає хвилину.

До того ж для публікації постів потрібен не бот, а просто скрипт. Ідея скрипту проста: для телеграм-каналу створив окремий тип постів (а блог в мене на Hugo); також тримаю файл з відповідністю постів до ідентифікаторів у Telegram. Перед публікацією в Hugo запускаю скрипт, який запостить або оновить пост в Телеграмі, дивлячись на файл відповідностей.

Все б було ідеально, якби Телеграм не вимагав суворого екранування символів для Markdown (наприклад, треба екранувати дефіси та крапки.) Спробую для наступного поста HTML.

16.04.2023

Заголовки постів — тепер в Телеграмі!

Зробив сьогодні маленьку фічу, яку давно хотів. У моїх постів досить давно є заголовки, але вони зʼявляються тільки на сайті та RSS. В Телеграмі заголовків не було, бо мій скрипт їх не підтримував. Нарешті, коли заголовки реалізовані, поділюся проблемами та нюансами.

Заголовки постів, як вони є, містяться в front matter до поста. Вони не є частиною тексту. Так Hugo може показати заголовки на сторінці переліку постів, в RSS, в тезі <title> і так далі. Але для мого скрипту для постінгу в Telegram це проблема, бо він генерує текст посту в Телеграмі шляхом перетворення вхідного тексту в Markdown у HTML; при цьому титул, як і вся інша передня частина, ігнорується. Ну, точніше, не ігнорується, а виноситься в окрему змінну за допомогою плагіну goldmark-meta; але потім титул треба приєднати до поста… або рудиментарним шаблоном, або — як я поки роблю — просто склейкою. Та при цьому не забути про санітаризацію.

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

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

22.05.2024

Mastodon: публікація через API

Хотілося б ретранслювати цей канал в Mastodon, але ж в концепції WOPE (Write once - publish everywhere.) В Телеграм я давно публікую ботом, також весь зміст є на сайті, доведеться й для Mastodon зробити автоматичну публікацію.

В цілому це набагато простіше, ніж з Telegram або з Twitter. У GoToSocial є API, з ним все зрозуміло, працює без сюрпризів. На власному сервері жодних обмежень на довжину поста немає. Навіть в Markdown можна писати.

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

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

25.05.2024

Труднощі з автопостингом з CI

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

Модель така: є статичний сайт на Hugo; коли в вхідному коді зʼявляється новий пост, публікуємо його в Telegram, Mastodon та ще кудись. Логічним було б поєднати публікацію з розгортуванням самого сайту: для цього на CI вже запускається hugo. Втім, просто “взяти та запустити” мої скрипти на CI не вийде. Чому?

У скриптів є стан. Наприклад, це відображення постів на ID повідомлень в Telegram. З нього скрипт знає, які пости залишилось опублікувати. Поки стан зберігається в JSON прямо в репозиторії. Це просто в реалізації та уможливлює виправлення його вручну.

Чи можна зберігати JSON в репозиторії з CI? Технічно, можна; GitHub Actions дозволяють робити git push. Але з CI ми потрапляємо на територію рівночасності та мусимо виконувати всі її вимоги. Що буде, коли я зроблю git push два рази поспіль — може, щоб виправити помилку? По-перше, git push з CI може вже не спрацювати, бо репозиторій “поїхав далі”. По-друге, два різних запуски можуть так само налізти один на одного (хоча цього легше уникнути.) А нам життєво необхідно, щоб кожна публікація була занотована в стані!

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

PS: для простіших випадків знайшов цікаву дію github/lock - тут замки вбудовані у GitHub.

26.05.2024

Автопостинг з CI: зовнішнє сховище

Я зʼясував, що без зовнішнього сховища з CI постити не вийде. Займався пошуком такого сховища.

В мене тут є дві потреби: запобігання конфліктам та власне зберігання стану. Краще першу відразу відокремити: запобігання конфліктам вимагає синхронності, що відразу звужує можливий список. Думаю, краще для того покладатись на вбудований функціонал CI - щоб просто не запускав дві збірки одночасно. Принаймні, для першої версії цього достатньо. (Наприклад: Terraform з S3 може використовувати DynamoDB для замикання стану.)

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

Тому вирішив залишитись в парадигмі “єдиний великий JSON”: всі дані зберігаються в один файл JSON, а далі ми цей файл зберігаємо… на S3. Це очевидний вибір, оскільки API S3 став стандартом де-факто для хмарного сховища. Плюс, користувачі Hugo вже можуть мати налаштований S3. Плюс, JSON-“базу” можна взагалі нікуди не відвантажувати, а тримати локально, якщо CI вам не потрібний.

08.01.2025

Генерація JSON на Hugo

Мій бот скрипт для каналу — який бере зміст з файлів блогу на Hugo - був з самого початку збудований як повністю окреме рішення: він сам знаходить пости, сам їх парсить, сам їх надсилає в Telegram. З Hugo в нього спільні тільки домовленості про структуру тек та формат файлів.

Нещодавно мені спало на думку, що взагалі-то перші два кроки Hugo теж робить, та незрівнянно вправніше. Тому гарно було б якось включитися в Hugo та залишити на власний скрипт тільки публікацію. Зокрема, це розблокувало б інші напрямки публікації, бо наразі скрипт дуже завʼязаний на Telegram та розділити його мені поки не вдалося.

Механізму плагінів в Hugo немає, тож що я придумав: Hugo під час збірки буде генерувати мені JSON з всіма даними, що потрібні для публікації, а скрипту залишиться зчитати JSON та, так би мовити, “синхронізувати” його в канал.

…Механізму “згенерувати JSON” в Hugo теж немає. Зате ми можемо створити окрему сторінку, а в її шаблоні назбирати даних, викликати для них jsonify та надрукувати — от і буде JSON. На щастя, принаймні з кожної сторінки є необмежений доступ до даних сайту.

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

Але, попри все це, мені вдалося! Найбільше часу витратив на спроби функціонального перетворення масивів — бо там наче є функція apply - аналог map - але виявилося, що дуже обмежена. А мова шаблонів — все ж імперативна. Тому, наприклад, щоб перетворити масив тегів-обʼєктів у масив назв, я оголошую новий масив та циклом складаю в нього назви. Коли це збагнеш, решта вже не так складно.

Так що чекайте в наступні тижні покращень по скрипту публікації, а може й публікації самого скрипту.