前言#
本篇是對 2024-03-17 到 2024-03-24 這周生活的記錄與思考。
這周重拾了很多工作學習的熱情，把 TODO 裡列了很久的博客評論系統和數據統計系統遷移做完了，有種整理規置了書桌的舒心感；周末第一次體驗了油畫，給自己畫了一個新頭像，成就感滿滿；恢復了健身；繼續學車並報考了科目二；還有很多有意思的事。
油畫體驗與新頭像#
我和學姐性格和喜好迥異，她有許多我不曾涉足的興趣愛好，而我著迷的似乎往往也是她未知的領域，於是我們前段時間有立一些 flag 說帶對方體驗自己的愛好 / 技能，我定的是雙拼和編程這兩項，目前雙拼已經卓有成效；她則是在這周帶我去上了一節油畫課。
我對畫畫其實確實是零基礎，也從不覺得自己和這些藝術搭邊的愛好有什麼關聯，只是好奇於究竟是怎樣的吸引力能促使她常常在素描或是油畫畫室坐上大半個下午打磨著一些小細節，期待之餘還有些緊張。
按理說初學者不太會從人像這樣的複雜主題開始，只是想要換一個新頭像，畫室的老師也很 nice 地願意輔導，選了一張以 “頭” 为主的照片就開始了，畫輪廓、調色、上色、根據光線和位置加細節，一切比想像得更加有趣，幾種簡單的顏色組合能夠幻化出很多的層次，創造本身也如同魔術一樣令人心馳神往。
一個下午的成果如圖，筆觸生澀，卻是我用自己的畫筆創造出來的作品，也有著與眾不同的意義，換了全平台的頭像。
博客系統升級#
Cusdis -> Remark42#
之前寫過一篇「輕量級開源免費博客評論系統解決方案 （Cusdis + Railway）」，有講過我博客使用的是自部署的 Randy 開源的 Cusdis 評論系統，從 2021 年中就開始使用了，到現在整整三年了，除了最開始的時候因為 Heroku、Railway 相繼收費而折騰了一下部署平台外，一直都穩穩地運行著。
不過我在使用中也有遇到一些問題：
- 大概是由於微信內置瀏覽器做了一些魔改，在博客從微信聊天 / 對話打開是看不到評論組件的
- 儘管可以輸入郵箱，但並不支持訂閱評論回覆
- 需要管理員手動審核評論，但評論提醒的 TG Bot 時常失效而錯過評論
另外因為其核心功能已經許久沒有什麼更新，比起其他較為成熟的評論系統也顯得有些簡陋，不過由於我也秉持著夠用即可的原則，一直沒動遷移 / 更新的念頭，只有在其中一陣子在學前端時還參與了一些 Cusdis V2 版本的開發，不過也沒做多久開發小群就不再活躍了。
而最近幾個月因為博客幾乎沒怎麼更新，也沒收到評論 TG Bot 的提醒，一直以為是沒人評論，直到最近數據庫托管的 Supabase 平台需要更換一下 Connection String，我才發現原來陸陸續續有幾十條評論，有的是關心和鼓勵，也有的是諮詢一些技術問題，但看到的時候也已經是一兩個月後了，還挺不好意思的。
再加上更換數據庫 URI 時 Vercel 部署一直報錯，於是下定決心從 Cusdis 遷移，調研了一圈後選擇了和 reorx 在「更換博客評論系統」一文中最後選定的 Remark42。
單純就配置選項來說比起 cusdis 還是豐富了不少，目前配置了常用的幾種社交賬號登錄（GitHub、Twitter、Telegram、郵箱）、可以匿名評論、支持郵件訂閱回覆提醒並且也設置了 TG bot 提醒，並且部署在 fly.io，go 單二進制 + 數據庫單文件，很舒服的解決方案。
而因為之前積攢了很多評論數據，因為 Cusdis 使用的是 pg 而 Remark42 使用的是 boltdb 單文件數據庫，後者不支持遠程連接，沒法直接 sql 語句寫入，只能先聯表查詢導出需要字段的 json 文件，再手動執行 Migrator 腳本（而因為官方只支持 wordpress、disqus 和 commento 這三個，於是還得手動實現轉換邏輯），幸好是熟悉的 go 寫的，花了一晚上終於肝完了 pr！！！
遷移完才發現這些年一共積攢了 438 條評論，自己都驚到了，都回來了！！！
Umami -> GoatCounter#
本著既然連評論系統都換了的心態，乾脆把一直也是個心結的數據統計系統也更新了。
Umami 其實一直用得倒沒出現什麼問題，直到我更換時盡職地跑了整整一年半，只不過可能因為自己用得比較早，在一次大版本更新的時候數據庫 Migration 腳本出現了不兼容的字段更新，其實有點不理解這樣量級的開源項目為什麼會出現這樣的問題，也看到 issue 中有很多其他用戶有同樣的訴求，但最終並沒有給出一個比較好的解決方案。
但是又由於自己已經運行了大半年，捨不得之前的數據，於是一直拖著，直到現在還停留在自己 fork 的一個舊版本，雖然倒也沒有對新版本有那麼多功能上的訴求，只是有點半強迫症地感覺不舒服，但也就拖著。
於是趁著這次博客大施工，就順便換為了 goatcounter，同樣是 go 單二進制 + sqlite 數據庫單文件部署在 fly.io，又是很舒服的配置。
有意思的是，因為 goatcounter 的作者很有堅持，覺得這樣單文件的應用容器化反而會增加更多維護成本，所以不提供官方鏡像，不過自己在 vps 或者 serverless 平台部署有個鏡像還是方便一些，所以用 Github Actions 做了個 CI 每天拉取最新代碼、構建鏡像和上傳 Docker Hub，有需要的可以使用，對應的 Dockerfile 和 Docker Compose 文件也可以參照這個 PR。
docker pull pseudoyu/goatcounter
這半年的周報輸出頻率堪憂，除了一篇關於信息管理系統的長文外也沒有什麼滿意的輸出，所以決定之前的訪問數據就不作遷移了（複雜度應該也高很多），感謝每一位點進我博客網站的賽博朋友們，截圖以作留念。
最近感覺折騰這些軟硬件 / 服務配置的心情回歸了，也有了很多博客想法，新數據就當作一個新的開始了 🫡
更換的一個最大動力還是 goatcounter 的界面跟我的古早博客主題一樣完美卡在我的審美點上，感覺我能一直盯著這個界面看 🤩 無法抗拒這種 Retro Internet 設計。
關於 self-hosting 的一些思考#
其實我對於 vps 和 serverless 平台經歷過許多次的折騰和反復，算不上心得，但確實是深度體驗後的經驗之談了。
曾經的我算是 serverless 的擁趸，當時幾乎是能在 Vercel/Railway 等 PaaS 平台部署的絕不自己搭建，能在幾乎沒有運維成本的前提下還能獲得媲美大平台的穩定性，也確實踐行了把自己的各項服務都 serverless 化了，確實經歷過很長一段時間的省心省力。
然而隨著經歷過 HeroKu 和 Railway 相繼中途改變收費模式，以及 n8n 在 Railway 上跑出單月十幾刀的賬單時，才也逐漸發現一些弊端，serverless 確實是減少了對於自己運維伺服器的要求，但相對應地也要受制於這些平台的規則。
收費模式其實只是一部分緣由，比起自己租賃一台配置不錯的伺服器，成本倒是還好，只是似乎又將自己的服務和數據綁定在一個中心化平台了，會有一種任人宰割的不安全感；而當想要遷移到另一個平台時，往往平台不會給出較為方便的解決方案，自己去折騰的操作複雜度比起伺服器之間 docker-compose 文件外加掛載 volume 直接複製要高不少。
因此也把自己的很多服務都放在伺服器上，穩定地跑了 430+ 天。
而前幾天和 reorx 聊到服務部署方案時，他提到了現在會優先考慮 sqlite 或其他同類文件數據庫的 self-host 方案，能夠減少許多維護和遷移的成本和複雜度。
後來我想了想，其實不管是在 vps 還是 serverless 平台，本質上都是 self-hosting 的選擇，其實更多需要的是思考部署的服務依賴本身，如我之前 Cusdis、Umami 很多不穩定性來源其實是在服務端在 Vercel、Netlify 這樣的 PaaS，而數據卻托管在 Supabase 這樣的 DaaS，一個自用的服務同時依賴兩個平台，任何一方出了問題都會導致服務不可用，vps 所做的其實也不過是把這樣的風險變為單點自己維護而已。
於是又久違地開始折騰，把 Remakr42 與 GoatCounter 都部署在了 fly.io 上，因為單二進制 + 文件數據庫，性能消耗完全在 free plan 的範圍內；而把 RSSHub、n8n、圖床等相對依賴更重且需要對外提供服務的應用還是繼續更集中地放在 vps 上；而把一些性能或存儲消耗較高的服務則是跑在 Home Server 上並且通過內網穿透方案來暴露。
其他#
把 Mac 從各個來源安裝的軟件都統一了一下，原則就是能 brew cask 安裝的都重新安裝，之前命令行需要自行搜索沒什麼感覺，現在有了 GUI 查看後發現確實軟件源比想像得豐富很多，這種方式便於管理 / 遷移且相對能保障軟件的來源安全性 🫡
從 RapidAPI 切換到一個新的 API 調試工具 Bruno，預購了它的 Golden Edition，目前使用起來體驗很不錯。
有趣的事與物#
輸入#
雖然大部分有意思的輸入會在 「Yu's Life」 Telegram 頻道裡自動同步，不過還是挑選一部分在這裡列舉一下，感覺更像一個 newsletter 了。
書籍#
收藏#
文章#
視頻#
劇集#
- 三體 第一季，在看。