WAF の設計方法
結局、アプリケーション (not Web App = WWW 非依存) なものを Web っぽい部分とつなぐ Dispatcher (Router) があればよくて、あとはおまけっぽいので、HTTP::Engine + Router で WAF っぽい部分は終わりになるような気がした。
と書いたのですが、あれを書いたときから、「そうだろうか?」というのを薄々と思っていました。Web + App ではなく、WebApp にしてしまうのもいいんじゃないかということについてです。
Web + App は大人気 Sinatora もそういう考えっぽいですが (誤解しているかもしれません)、Web というのが App へのインターフェイスの一つにすぎず、例えば CLI + App という組み合せもあるし、Desktop GUI + App という組み合せも考慮されています。ロジックのテストはしやすそうでいいですね。でも、もっと富豪的でもおこられないんじゃないかなぁとも思うのです。
WebApp の場合、Web (というより HTTP) を唯一のインターフェイスとして提供し、例えば CLI だろうが GUI だろうが、HTTP を仲介するようにします。HTTP + App, CLI → HTTP + App, GUI → HTTP + App。これは例えば GAE だと、そもそもこういう方法をとることしかできません。Cron も HTTP で特定のURLが叩かれるだけです。ユーザ向けAPIみたいなのがだいたいのサービスでありますが、それをアプリケーションのオーナーまで権限を拡張しているような感じです。
これは一昔前のシェルに入れない CGI サーバみたいな趣きがあって古い気もしますが、こうすると Web + App に比べていくつか楽をできるようになります。「楽」とは違うかもしれません。自然と良い方向にアプリケーションが進化する、という感じでしょうか。
- バッチ処理だろうがなんだろうが、専用の CLI 環境みたいなのを考えなくても、他のハンドラと同じように書ける
- 自然と結合テストを書くようになる
- Web + App にすると App のまでのテストは書いても、Web 側の結合テストを怠りがち
- 最終的にユーザがみるのは Web なインターフェイスなのだから、ちゃんと書かないとだめ
- Web + App にすると App のまでのテストは書いても、Web 側の結合テストを怠りがち
- 自然と API に必要な機能が揃う
- CLI から叩こうと思ったとき必要な機能が勝手にできる
一方、微妙なところもあります
- バッチ処理しかしないサーバーでも HTTPD を立ち上げてることになる
- 各ハンドラだけの実行をしにくい
- テストが遅くなりがち
この辺はフレームワークでモックリクエストを充実させたら解決できます、というかちゃんとしたモックリクエストの仕組みがテストのために必須です。
[めんどくさくなったのでまた考えて追記する]
DBIx::RewriteDSN
http://search.cpan.org/~satoh/DBIx-RewriteDSN/lib/DBIx/RewriteDSN.pm
というのを作ってみました。DBI->connect に渡しされた dsn を別の場所で一括して書きかえるモジュールです。
- dsn がハードコードされている
- ソースコードが膨大で DBI->connect を全部探しだすのが困難
- DB 情報を管理する Config インスタンスがない
ような場合に、それなりに安全にテスト環境を構築するのに使えると思います。
例えば
use DBI;
use DBIx::RewriteDSN -rules => q{
(dbi:mysql:database=foobar;host=192.168.0.1) $1
# fallback
dbi:mysql:database=([^;]+)(?:host=.+)? dbi:mysql:database=$1_test;host=127.0.0.1
};みたいな感じにすると、dbi:mysql:database=foobar;host=192.168.0.1 についてはそのまま繋いで、それ以外はローカルホストに繋ぎにいくようになります。ローカルにDBがなければエラーになるだけなので意図せず production に繋ぐような事故が防げると思います。
✖
京都の神社を google map にプロットする
地図にマップされたやつがなかったのでてきとうに……
- http://ja.wikipedia.org/wiki/Category:%E4%BA%AC%E9%83%BD%E5%B8%82%E3%81%AE%E7%A5%9E%E7%A4%BE:title
- http://www.kyoto-jinjacho.or.jp/shrine.html
を元にプロット。京都府神社庁からは郵便番号 (京都市内ものだけ) をスクレイピングし、Google の geocode にあらかじめかけておいたやつを表示している (青のマーカー)。Wikipedia からは、JSONP の API を使って、神社一覧を取得し、さらにそれぞれに神社のページに埋め込まれている緯度経度情報を JSONP でとってきてる。
Wikipedia のほうは動的なので京都市以外でも
とか、カテゴリからひっぱってこれる。北海道の神社は今のところ全く緯度経度情報を持ってないのでプロットされない。
✖
✖
何をやるにしても、見当もつかないような方法で、優れたことをする人がいて、そういう人には、決してかなわない。上に人がいて、追っ掛ける気になるなら、それはとても楽しくて、よいことなのだけれど、追っ掛ける気もなれないほどに、離れていれば、そういう気もなくなり、立ち尽すしかない。
気概を持ってとりくめなければならない、気骨を持ってないのはだめだと、しばしば聞かれることだけれど、そんなこと、「そうじゃない」と、否定する人はまずいないだろう。「その通りです」と、「仰る通りです」と、思って聴くけれど、どうすればそういう心になるかは、全く聞かされない。本人達も、一種の才能によって、それを実現してきたわけだから、伝えられない。そのくせに、他人には、結果的にできたこと、「おまえらとは違うのだ」といわんばかりに、教訓めいたことは存分にいう。
しかし時々、とてもうまく言葉を使いこなす人がいて、そんな人は、上に書いたような、わかりきったことをただ繰り返して、却って他人のやる気を奪うようなことではなく、淡々と事実だけを、飾らずに言葉にして、「それでいいなら、自分にできそうだ」と、やる気をわかせてくれる。ただし、そういう人は極めて少ない。
関連エントリー
- ✖ 人とできるだけ関わりたくないが、そうもいかない。思うことをいっていると、他人樣のやる気を奪う結果になる。全くよくない。そう思っても、たびたび...
- ✖ 今年はギリギリになって、仕事とは関係ないけれど、かなり(自分の中では)チャレンジングなことをすることとなった。切っ掛けは外部要因だが、その切...
- ✖ 例えばおれが他人が欲しがるような何か (価値) を持っているかっていうと、全然持ってないわけですよね。コード書くとか (それさえも不完全であ...
- ✖ やる気のコントロールって高校のときからずっと考えてるけど全く解りませんね。彼ら他人のやる気のコントロールがとても上手いですね、失なわせる方向...
- 日記を書くこと 日記を書き初めたとき、そもそも文というものが全く書けなくて、大変苦しい思いをしたことを思い出した。何度も「頭の中の言葉をそのまま書けば良い」...
✖
人とできるだけ関わりたくないが、そうもいかない。思うことをいっていると、他人樣のやる気を奪う結果になる。全くよくない。そう思っても、たびたび何もかもどうでもよくなり、他人のことを全く考えずにいるようになる。

