読書会支援プログラム更新した話・（ほぼ）完全自動化
こんにちは！
以前より開発を進めているオンライン読書会の支援ツールについて、またアップデートを行ったので、今回はそれについて書いていきます。今回の変更点は各種作業の（ほぼ）完全自動化です。
ソースコード
まずはいつもどおりソースコードを紹介します。Read meも更新していない上、全体的にかなりコードも複雑になってきたので、そろそろきちんと整理しないとなぁとは思いつつ、結局自分で使えればいいかと思って後回し担ってしまっているのが現状ですw どうしても新しい物をつくることに気が言ってしまって、整理みたいな地味なことはなかなか手がつかないんですよね…
今回追加したメイン部分は、なんといってもschedule.pyというファイル。このコードを定期的に自動実行することで、「読書会のリスト作成」「Googleドキュメントへのアップロード」「カレンダーへの登録」「ZOOMミーティングの作成」などの雑事を自動でこなしてくれるようになります。前回の記事で、プログラム内のリスト作成部分を別ファイルとしてモジュール化したということを書きましたが、それはこのための下準備だったわけですね。
全体構成
プログラム全体の構成は以下のような感じです。
と言ってもこれだけだとよくわからないと思うので、全体のコードの流れだけフローチャートで解説します。一つ一つは別に大したことをやっているわけではないのですが、システムとしては徐々に複雑になってきた感じは有りますね。
ちなみに、一つ一つの処理はほとんどこれまで作ったモジュールをそのまま使っているだけなので、今回追加したコードの量はそこまで大したことありません。このあたりはオブジェクト指向プログラムの強みって感じですね。
処理の流れ
ポイントはデータベース（DB）を追加したところですかね。完全自動化はいずれやりたいとは思っていたので、色々と構想は練っていたんですが、考えつく範囲ではこの構成が最もシンプルかつ上手くいくのかなと。
処理の流れはフローチャート通りですが、敢えて再度説明すると。。。
① 読書メーターの自分の主催イベントをチェック
② DBを確認し、登録されていなければ、ZOOMミーティング・Googleカレンダー・Googleタスクへの登録を実施した上でDBにも追加
③ DB全体をチェックし、終了していないイベントをチェック。
③-1、現在が開催一週間より前なら特に処理せず
③-2、開催日が現在より以前なら終了フラグを立てる
③-3、どちらでもなければ、リストの作成とGoogleドライブへのアップロードを行う
とまあこんな感じです。このプログラムが参照するのは読書メーターのマイイベントなので、基本的には読書メーターにイベント開催だけ設置し、プログラムを定期的に実行するように設定すればあとは自動的に各種処理をやってくれます。
おそらく問題ないとは思いますが、長期的に使っていると上手く行かないケースとかも出て来るかも知れません。まあそのあたりは、使いながらその都度対応と言ったところですかね。いずれにしても、これで読書会の開催に関してやるべきことの大部分を自動化することができたので、開催する側の手間はだいぶ軽減されました。
あと、フローチャートには書いていませんが、ついでにSlackへの投稿機能も追加しています。新しく追加されたイベントがあったり、リスト作成を行ったイベントがあった場合にはSlackでお知らせしてくれる感じですね。Slackへの投稿はタブレットを通して読み上げしてくれるようになっているので。音声通知にも対応です。この手の定期実行プログラムはその存在を忘れがちなので、とりあえず何らかの形で通知してくれると嬉しいですw
「（ほぼ）完全自動化」という言葉の意味
これで「完全自動化」！と言いたいところですが、まだ自動化できていないところは残ってしまっています。具体的には以下の4つですね。
① 読書メーターのサイトへのイベント告知
② 読書メーター外からの申込みの対応
③ 開催1週間以内の参加者の変更
④ 参加者へのZOOMアドレス等の告知
②と③は割とどうしようもないかなぁと思っていますし、①と④はできなくはなさそうですが、少し実装がめんどうなのと、バグなどがあった時に参加者の方や読書メーターさんに迷惑がかかってしまうのでちょっと難しいかなと。seleniumというブラウザ操作をプログラムで自動化できるツールがあり、①と④はそれを使えば実装できるだろうとは思うのですが、上記の理由から着手しかねているというのが実情です。
というわけで、これ以上の自動化は難しいかなというところまでは自動化したので、（ほぼ）完全自動化という微妙に怪しい言葉を使っている感じですねw リストの作成が読書メーターに依存している分、ある程度の制約は仕方ないかなと。読書メーターを使わないと利用者的にも主催者的にも手間が明らかに増えるので、まあ仕方ありません。なんだかんだで、それなりに規模のあるプラットフォームが便利なのは否定できませんね。
Dockerにおける定期実行について
これはやや余談的な話ですが、今回の開発・実行環境はDockerコンテナ内であり、その定期実行でちょっと悩んだところがあったので備忘録的に残しておきます。かなりニッチな話なのでほとんどの方はこの部分は読み飛ばしてもいいと思いますw 以前書いた以下の記事に関連する話ですね。
僕自身がITエンジニアというわけではないので、そこまで詳しいことはわかりませんが、コンテナ内のアプリケーションを定期実行するには以下の四つの方法があると思います（文章では便宜的にCronと書いていますが、同じような定期実行ツールなら何でも良いと思います）。
① コンテナを常設として、内部のCronからプログラムを実行する
② Cronを実行するための常設コンテナを別途立てて、そこからコンテナ起動→プログラム実行→コンテナ破壊を定期的に実行する
③ ホスト側のCronからコンテナ起動→プログラム実行→コンテナ破壊を定期的に実行する
④ Kubernetes等の定期実行機能付きのコンテナオーケストレーションシステムを使う
おそらく、正攻法的に言うなら④だとは思うのですが、個人で使用するこの程度のシステムでKubernetesを使うのは流石にちょっと過剰だと思ったのでこちらは見送りました。Kubernetesも興味があるのでそのうち使えるようになりたいなぁとは思うものの、個人開発でちょっとしたプログラムを組むくらいだと、学習コストのわりに適用できることが少ないのがどうかなぁと。
①〜③のうちどれを選ぶかは考え方によるのかなと思います。定期実行も1プロセスと考えて、1プロセス1コンテナの原則を厳密に適用するならば②か③でしょうし、定期実行まで含めて1つのアプリケーションと考えるなら①でもそんなに変でもない気がします。どれでも大して差はない気はしますが、③のデメリットとしては可搬性がありますかね（ホストOS側での設定作業が必要になるという意味で）。
で、どれを選んだかと言うと①のコンテナ内でcronを回すという方法です。Docker内でCronを回そうとすると環境変数の受け渡しの部分でちょっとめんどくささがあるらしいのですが、それはbusyboxというツール郡のcronを使うことで回避できるようだったので、こちらを採用しました。ちなみに、そのコンテナの設定ファイルは以下のリポジトリに置いているので、興味のある方はご覧ください。
まとめ
今回はオンライン読書会の支援ツールの更新について書きました。今までは自動化とは言え、自分でタイミング良くプログラムを実行するという作業が必要だったわけですが、今回の実装によってそれすらも自動化出来るようになりました。
今後、これをどのように更新していくかはそんなにはっきりした方針はないので、また何か思いつき次第実装していきたいと思います。とりあえず、一旦は出来ることは実装したという意味で、一区切りをつけてファイル整理やRead me整備の方を進めても良いかも知れませんね。
それでは、また！
この記事が気に入ったらサポートをしてみませんか？