ちょっとした改良

RasberryPiを利用しての楽々リモコン生活構築も一段落。もうそろそろ気になってた別のプロジェクトを進めるか〜。
とは言っても、そんな大掛かりなことを始めるつもりはなくて、以前作った小さいサービスの小さな改善。

ComicDashの新刊カレンダーをiCalendar形式に変換するサービスcomdashcal。
以前から、時折エラーを吐くのを気にはしていた。元サイトのアクセスに時間がかかると処理を中断してしまうのだ。
気にしつつ放置していたのは、ユーザー数の少なさもさることながら、エラーによるユーザーへの影響を小さく考えていたことによる。
オンラインのカレンダーに読み込んで使われる前提なので、多少のエラーがあっても更新が滞るだけで、いきなり消えてしまうことは無いから平気くらいに考えていたのだ。

ちょっと考えを改める気になったのは、1時間に数回とか、割と頻繁にアクセスしてくる（本人が意識しているか否かはともかく）ヘビーな使い方をしてくるユーザーもぼちぼち現れてきたから。こちらに行われるアクセス1回が、まんま元サイトへのアクセス1回になってしまうのがさすがに申し訳ないような気がしてきたのだ。寄生虫なりの遠慮というものがあってしかるべきだ。

なので、今までサボっていたキャッシュ機能の実装というのが今回の改善のテーマである。
一つのページヘのアクセスが連続したら、以前アクセスしたときのデータを再利用することとし、元サイトへのアクセスを控える。comdashcalの場合、アクセスするページはそのユーザーの新刊カレンダーのページなので、ユーザーごとに1ページずつ、その内容を保存することになる。
とはいえ、GoogleAppEngineにはmemcacheが最初から入っているので、これを使うだけ。新しいミドルウェアの導入とか必要ない。なんで今までやらなかったのか。
そういや、金融でも物流でもオンラインは当然即時反映、さもなきゃ夜間バッチで翌日反映が当たり前。今までキャッシュなんか扱ったことなかった。I am COBOLer.
人生初のネットワーク・ソケット・プログラミングの次はキャッシュを使った通信量削減に初挑戦だ。この歳で。

ついでに、これまた今更ながらTask Queueという仕組みも導入している。
キャッシュへのページ内容の保存は、元サイトにアクセスしたときのついでに行うのだが、元サイトへのアクセスが中断する場合は当然その内容を保存できない。
これでは「たまたまうまくいく」ことを期待して、元サイトへのアクセスを繰り返すことになってしまう。（実際、うまくいくことも多かった）
ユーザーからの直接のリクエストが失敗した時に、裏でこっそり（もう少し気長に）処理をやり直してキャッシュへのページ内容の保存の部分だけ行い、次に同じユーザーがやってきた時に「こんなこともあろうかと」と取り出してみせる。そんなことを目論んでいる。

果てさて、うまく動きますかどうか。