日替わり通信術練習は一総通の電気通信術(モールス受信)の対策に特化したWebアプリとして2021年にリリースした。
おかげさまでこれまでに10名以上のユーザから、このアプリを利用して総通試験に合格したとご報告を頂いており、平均利用者数も推定100ほどと、総通受験者の大部分に認知頂けるアプリに育った。
ユーザにとってはアプリの見た目とかコードなんかはどうでもいいことだと思うんだけど、開発者としては、元々知識のないところからスタートして汚いコードだった上に、長年の増築やその場しのぎのデバッグで、見るに耐えない状態になってしまっており、気になっていた。
2025年になって生成AIがかなり使えるレベルになり、特にgoogleのGeminiはLinuxのCLI環境で直接コードを書いたりコマンドを実行できるということで、自作の日記アプリをリファクタリングしたり、ブログを自作CMSに移行したりと、活用できることがわかった。
そこで、いよいよ重い腰を上げて日替わり通信術練習のリファクタリングに着手。ざっくりとした方針をAIに伝えて、リファクタリングプランを考えてもらった。
- 日替わり方式から、サーバでバックエンドAPIを動作させて、いつでも電文更新可能とする
- ただし本番サーバの既存アプリに影響を与えないこと
- モダンなUIに刷新
サーバは自作日記アプリや、従来の日替わり通信術アプリのバックエンド(cronで1日1回実行)が走っているので、それに影響を与えないように、というのが重要。AIの提案はFastAPIとUvicornのAPIをDockerコンテナで隔離して動かすというもの。はー、なるほどそんな方法があるのかと勉強になる。
今まで別々に管理していたフロントエンドとバックエンドもモノレポ化して、ローカルのubuntuサーバで動作確認できるようにしてもらった。
UIの刷新はReactを使ってサクサクと進んだものの、バックエンドのリファクタリングは優秀なアシスタント猫AIでもかなり苦戦。AIというのは公開データを学習しているわけで、マニアックな和文モールス信号だとか漢字仮名交じり文の読み仮名変換だとかはニッチすぎてなかなか理解してもらえなかったみたい。
コツはとにかくできるだけ具体的で小さなタスクに分解して、ひとつひとつ解決してもらうことかな。それでもAIが勝手に暴走してとんでもない改良をやらかすことがあるので、ひとつタスクが進んで確認したら、コミットしてもらうのが大切。それでもどうしてもバグが治らないことがあって、最後の方は自分で直す場面もあった。
1ヶ月半ほど時間を要したけれど、なんとか試験公開できるところまで漕ぎ着けた。当面は既存アプリを使っているユーザに迷惑をかけないように、並列して公開して使ってもらう予定。その意味でもDocker仮想コンテナは便利な仕組みだと思った。
アプリのメッセージやコメントが猫語になっているのはご愛嬌。
