ダッシュボードのプラグインから単独のツールへ
これまでブログの管理ツールは、
別で作っていたダッシュボードのプラグインとして動かしていました。
ただ、他のシステムの中に組み込む形で開発を続けていると、
設定の受け渡しが複雑になったり、
ちょっとした修正でも手間がかかったりすることが増えてきました。
そこで今回は、ブログ管理ツールを完全に独立させて、
自分のパソコンの中だけで完結する単独のツールとして、
一から作り直すことにしました。
作り直すにあたって、いくつか試してみたいことがありました。
・画面の作成にPythonで動かせるFletを使ってみること
・記事の執筆にはAPIの従量課金ではなくGemini CLIを使うこと
・記事データの管理をフォルダ分けからSQLiteに変えること
まずはこのあたりの組み合わせが本当にうまく動くのか、
AIに細かく質問しながら整理していくことにしました。
構成の相談と疑問の解消
FletとAstroは一緒に使えるのか
最初は、画面を作るためのFletと、
ブログのWebページを作るAstroをどう組み合わせるのかが、
いまいちピンと来ていませんでした。
AIに聞いてみたところ、
Fletは記事を書いたり管理したりする「作業デスク」の役割で、
AstroはできあがったデータからWebページを作る「印刷所」の役割になるため、
そのまま組み合わせて問題なく使えるとのことでした。
また、以前の仕組みでは毎回ローカルサーバーを立ち上げて、
ブラウザからアクセスして操作する必要がありました。
たまに前回の処理が残っていてポート番号が重複し、
エラーになって動かないのが地味に面倒だったのですが、
Fletでデスクトップアプリにすれば、
普通のソフトのように専用ウィンドウが開くだけなので、
そういったサーバーの起動やポートの競合も気にしなくてよくなると分かりました。
記事の管理をフォルダからデータベースへ
これまでのブログでは、年や月のフォルダを作って、
その中にJSONファイルで記事を保存していく形をとっていました。
ただ、このやり方だと長く続けたときにフォルダだらけになってしまい、
「過去の特定の月の記事だけ一覧で見たい」といったときにも、
ファイルを一つずつ読み込むことになって不便そうな気がしていました。
そこで、記事データをSQLiteのデータベース1つにまとめる案を相談しました。
SQLiteならJSONの構造を保ったまま保存できますし、
検索や絞り込みもすぐに行えるので、
今回の作り直しに合わせてデータベース管理へ移行することにしました。
ソロ開発でGitHubは必要なのか
もう一つ、以前から疑問に思っていたのがGitHubの使い道です。
世の中の開発者の人たちを見ていると、
みんな当たり前にGitHubを使っている印象がありますが、
私のように一人で開発していて、
しかも公開用のWebアプリではなくローカルだけで動かす場合、
わざわざネット上のGitHubを使う理由があるのかよく分かりませんでした。
AIに相談してみると、パソコンが壊れたときのバックアップなどの利点はあるものの、
自分でコードを直接読むことがほとんどなく、
他の端末から作業する予定もないなら、
手元のパソコンで動くGitだけで十分という結論になりました。
無理に使わない機能を増やして管理をややこしくするよりも、
まずはローカルのGitでセーブポイントを作りながら進めることにしました。
Gitの初期化で場所を間違える
方針が決まったところで、古いファイルを整理する前に、
現在の状態をGitでセーブしておくことにしました。
最初はAIにGitのコマンドも全部任せるつもりだったのですが、
親フォルダの安全設定（フック）が働いて、
AIが勝手に新しくリポジトリを作る`git init`コマンドは、
自動でブロックされる仕組みになっていました。
そこで、自分でターミナルを開いて`git init`を実行したのですが、
うっかりブログ用の作業フォルダに移動するのを忘れたまま打ってしまいました。
出てきたメッセージをよく見ると、
パソコンのユーザーフォルダ全体がGitの管理対象になってしまっていました。
このまま進めるとパソコン全体のファイルが対象になって重くなるところでしたが、
AIに削除用のコマンドを教えてもらい、
すぐに設定ファイルを消して正しいフォルダでやり直すことができました。
普段あまり使わないコマンドを手動で打つときは、
今どのフォルダにいるのかをちゃんと確認しないといけないなと反省しました。
データの引っ越しと機密情報の分離
Gitで最初のセーブポイントを作ったあとは、
以前のプラグイン時代の古い設計書や不要なスクリプトを、
隔離用のフォルダへまとめて移動してもらいました。
また、以前のツールではブログのタイトルや設定、過去の記事データなどが、
別の場所にあるダッシュボード側のフォルダから毎回渡される構造になっていました。
調べてみると、過去に書いた15本分の記事データや画像、
サイトの設定ファイルなどが無傷で残っていたので、
それらを今回の新しいブログツールのフォルダへすべて引っ越しさせました。
最後に、データベースの設計を自律会議スクリプトにかけて検討しました。
その際、以下の2点をあらかじめ対策しておくことにしました。
・サーバーの接続パスワードや秘密鍵などの機密情報を安全に管理すること
・なぜその設計にしたのかという理由（ADR）を忘れずに記録として残すこと
以前は設定ファイルの中にそのままパスワードなどを書いてしまっていたのですが、
今回は一般の設定だけデータベースに入れ、
パスワードなどの大事な情報はGitの記録から除外する専用ファイルに分けて、
二重で管理する形にしました。
また、修正を繰り返すうちに「なぜこうなっているのか」を忘れないよう、
設計の判断理由をまとめるレポートの仕組みもフックとして組み込みました。
散らかっていたフォルダも片付き、過去のデータも手元に揃ったので、
次からは実際の画面や機能の作り込みに進んでいけそうです。