前言#
本記事は 2024-03-17 から 2024-03-24 までの一週間の生活の記録と考察です。
今週は多くの仕事や学びへの熱意を取り戻し、TODO リストに長い間載せていたブログコメントシステムとデータ統計システムの移行を完了しました。まるでデスクを整理したような心地よさを感じています。週末には初めて油絵を体験し、自分の新しいアイコンを描き、達成感で満ちています。フィットネスも再開し、運転の勉強を続けて科目二の試験を受けました。他にもたくさんの面白いことがありました。
油絵体験と新アイコン#
私は学姐と性格や好みが大きく異なります。彼女には私が触れたことのない多くの趣味があり、私が夢中になっていることも彼女にとっては未知の領域のようです。そこで、私たちはお互いの趣味やスキルを体験し合うというフラグを立てました。私はダブルピンとプログラミングを選び、現在ダブルピンはすでに成果を上げています。彼女は今週、私を油絵の授業に連れて行ってくれました。
私は絵を描くことに関しては本当にゼロからのスタートで、これらの芸術的な趣味とは何の関係もないと思っていました。ただ、彼女がスケッチや油絵のスタジオで午後の大半を小さなディテールを磨くために座っているのは、どんな魅力があるのかと興味を持っていました。期待と緊張が入り混じっていました。
初心者は人像のような複雑なテーマから始めることはあまりないはずですが、新しいアイコンを描きたいと思い、スタジオの先生も親切に指導してくれました。「頭」を主題にした写真を選び、輪郭を描き、色を調整し、光と位置に応じてディテールを加えていきました。すべてが想像以上に楽しく、いくつかのシンプルな色の組み合わせが多くの層を生み出すことができ、創造そのものが魔法のように心を奪われました。
午後の成果はこの通りです。筆致は未熟ですが、自分の筆で創り出した作品には特別な意味があります。全プラットフォームのアイコンを変更しました。
ブログシステムのアップグレード#
Cusdis -> Remark42#
以前、「軽量級オープンソース無料ブログコメントシステムの解決策 （Cusdis + Railway）」という記事を書きましたが、私のブログでは自分でデプロイした Randy のオープンソース Cusdis コメントシステムを使用しています。2021 年の中頃から使用しており、今ではちょうど 3 年になります。最初の頃は Heroku や Railway が相次いで料金を徴収したため、デプロイプラットフォームに手間取ったこともありましたが、それ以降は安定して運用されています。
しかし、使用中にいくつかの問題に直面しました：
- おそらく WeChat 内蔵ブラウザがいくつかの魔改造を行ったため、ブログを WeChat のチャット / 対話から開くとコメントコンポーネントが表示されません。
- メールアドレスを入力できますが、コメント返信の購読はサポートされていません。
- 管理者が手動でコメントを承認する必要がありますが、コメント通知の TG ボットが時々機能しなくなり、コメントを見逃すことがあります。
また、コア機能が長い間更新されていないため、他の成熟したコメントシステムと比べて少し簡素に見えます。しかし、私は「使えれば良い」という原則を持っていたため、移行や更新の考えはずっと持っていませんでした。学ぶためにフロントエンドを勉強していた時期に、Cusdis V2 の開発に参加したこともありましたが、開発チームはすぐに活発ではなくなりました。
最近数ヶ月、ブログはほとんど更新されず、コメント TG ボットの通知も受け取っていなかったため、誰もコメントしていないと思っていました。しかし、最近データベースをホスティングしている Supabase プラットフォームの接続文字列を変更する必要があり、その際に数十件のコメントがあったことに気づきました。中には関心や励ましのコメントもあり、技術的な質問もありましたが、見た時にはすでに一、二ヶ月が経過していて、少し恥ずかしかったです。
さらに、データベース URI を変更する際に Vercel のデプロイがずっとエラーを出していたため、Cusdis からの移行を決意しました。調査の結果、reorxが「ブログコメントシステムの変更」という記事で最後に選んだRemark42を選びました。
単純に設定オプションだけを見ても、Cusdis よりもかなり豊富になりました。現在、一般的なソーシャルアカウントログイン（GitHub、Twitter、Telegram、メール）を設定し、匿名コメントを許可し、メールでの返信通知をサポートし、TG ボット通知も設定しました。また、fly.ioにデプロイし、Go の単一バイナリ + データベースの単一ファイルという非常に快適なソリューションです。
以前に多くのコメントデータを蓄積していたため、Cusdis は pg を使用し、Remark42 は boltdb の単一ファイルデータベースを使用しているため、後者はリモート接続をサポートしておらず、直接 SQL 文で書き込むことができません。必要なフィールドの json ファイルをエクスポートするためにまず結合クエリを実行し、その後手動で Migrator スクリプトを実行する必要がありました（公式が WordPress、Disqus、Commento の 3 つのみをサポートしているため、変換ロジックを手動で実装する必要がありました）。幸いにも、Go で書かれているため、夜を徹してprを完成させました！！！
移行を終えてみると、これまでに 438 件のコメントが蓄積されていたことに驚きました。すべて戻ってきました！！！
Umami -> GoatCounter#
コメントシステムを変更したついでに、ずっと心の中にあったデータ統計システムも更新しました。
Umami は実際には問題なく使い続けていましたが、変更時には整整 1 年半も稼働していました。ただ、早い段階で使用していたため、大きなバージョンアップの際にデータベースのマイグレーションスクリプトに互換性のないフィールド更新が発生しました。このような規模のオープンソースプロジェクトでなぜこのような問題が発生するのか理解できませんでしたし、issue の中には他のユーザーも同様の要求をしていましたが、最終的には良い解決策が提示されませんでした。
しかし、すでに半年以上運用していたため、以前のデータを手放すのが惜しく、ずっと引き延ばしていました。現在も自分がフォークした古いバージョンに留まっていますが、新しいバージョンに対してそれほど多くの機能的な要求はありません。ただ、少し強迫観念的に不快感を感じていましたが、そのまま放置していました。
そこで、今回のブログの大改修を機に、goatcounterに変更しました。こちらも Go の単一バイナリ + sqlite データベースの単一ファイルで、fly.io にデプロイされており、非常に快適な設定です。
面白いことに、goatcounter の作者は非常にこだわりを持っており、単一ファイルのアプリケーションをコンテナ化することが逆にメンテナンスコストを増加させると考えているため、公式のイメージを提供していません。しかし、自分の VPS やサーバーレスプラットフォームにデプロイするためのイメージがあると便利なので、GitHub Actions を使って CI を作成し、毎日最新のコードを取得し、イメージを構築して Docker Hub にアップロードしています。必要な方はご利用ください。対応する Dockerfile と Docker Compose ファイルはこの PRを参照できます。
docker pull pseudoyu/goatcounter
この半年の週報の出力頻度は懸念されるもので、情報管理システムに関する長文以外には満足のいく出力がなかったため、以前の訪問データは移行しないことに決めました（複雑さもかなり高いと思います）。私のブログサイトに訪れたすべてのサイバー友達に感謝し、スクリーンショットを記念として残します。
最近、これらのソフトウェア / ハードウェア / サービスの設定に対する情熱が戻ってきたように感じ、多くのブログのアイデアが浮かんできました。新しいデータは新たな始まりとしましょう 🫡
変更の最大の動機は、goatcounter のインターフェースが私の古いブログテーマと完璧にマッチしていることです。このインターフェースを見続けることができると感じています 🤩 このレトロなインターネットデザインには抗えません。
セルフホスティングについての考察#
実際、私は VPS とサーバーレスプラットフォームで多くの試行錯誤を経験してきましたが、特に心得があるわけではありませんが、深く体験した後の経験談です。
以前の私はサーバーレスの支持者でした。当時、Vercel や Railway などの PaaS プラットフォームでデプロイできるものは、自分で構築することはほとんどありませんでした。運用コストがほとんどかからない前提で、大規模プラットフォームに匹敵する安定性を得ることができ、実際に自分の各種サービスをサーバーレス化することができました。確かに長い間、心配なく楽に過ごしていました。
しかし、HeroKu と Railway が相次いで料金モデルを変更し、n8n が Railway 上で月に十数ドルの請求書を発生させた時に、いくつかの欠点に気づき始めました。サーバーレスは確かに自分でサーバーを運用する要求を減らしましたが、それに伴いこれらのプラットフォームのルールに制約されることもあります。
料金モデルは一因に過ぎませんが、自分で良いスペックのサーバーを借りることと比べると、コストはそれほどでもありません。ただ、自分のサービスやデータが中央集権的なプラットフォームに結びついているように感じ、不安感が生じます。また、別のプラットフォームに移行したいと思ったとき、プラットフォームは便利な解決策を提供しないことが多く、自分で試行錯誤する操作の複雑さは、サーバー間で docker-compose ファイルを使ってボリュームをマウントして直接コピーするよりもかなり高くなります。
そのため、多くのサービスをサーバー上に置き、430 日以上安定して運用しています。
数日前、reorxとサービスのデプロイメントについて話しているとき、彼は現在 SQLite やその他の同様のファイルデータベースのセルフホストソリューションを優先的に考慮していると述べました。これにより、多くのメンテナンスや移行のコストと複雑さを減らすことができます。
その後、考えてみると、VPS でもサーバーレスプラットフォームでも、本質的にはセルフホスティングの選択であり、実際にはデプロイするサービスの依存関係を考える必要があります。私が以前使用していた Cusdis や Umami の多くの不安定性の原因は、Vercel や Netlify のような PaaS にサービスサイドが依存していることにあり、データは Supabase のような DaaS にホスティングされているため、自分用のサービスが同時に 2 つのプラットフォームに依存していることになります。どちらか一方に問題が発生すると、サービスが利用できなくなります。VPS が行うことは、実際にはそのリスクを単一のポイントで自分でメンテナンスすることに過ぎません。
そのため、久しぶりに試行錯誤を始め、Remark42 と GoatCounter をfly.ioにデプロイしました。単一バイナリ + ファイルデータベースのため、パフォーマンス消費は完全に無料プランの範囲内です。一方、RSSHub、n8n、画像ホスティングなど、より依存度が高く外部にサービスを提供する必要があるアプリケーションは、引き続き VPS に集中して配置し、パフォーマンスやストレージ消費が高いサービスはホームサーバーで実行し、内網を通じて公開しています。
その他#
Mac にインストールしたソフトウェアを各ソースから統一しました。原則として、brew cask でインストールできるものはすべて再インストールしました。以前はコマンドラインで自分で検索していましたが、今は GUI で確認すると、実際にはソフトウェアのソースが想像以上に豊富であることがわかりました。この方法は管理や移行が容易で、ソフトウェアの出所の安全性をある程度保証できます 🫡
RapidAPI から新しい API デバッグツールBrunoに切り替え、ゴールデンエディションを予約購入しました。現在の使用感は非常に良好です。
面白いことと物#
入力#
ほとんどの面白い入力は「Yu's Life」Telegram チャンネルで自動的に同期されますが、ここでも一部を選んで列挙してみます。ニュースレターのような感じです。
書籍#
コレクション#
記事#
動画#
シリーズ#
- 三体 第一季、視聴中です。