過去の記事 - 氾濫原

2009年 07月 27日

✖

16:31

昨日は鞍馬寺 (由岐神社) → 貴船神社にいってきた。雨がふったりやんだりする、なんともいえない天気で、行こうかどうか悩んだけど、行ってよかった。鞍馬山にいる間、短時間に晴れたり豪雨になったり繰替えして、面白かった。かえって得した気分だった。狙って晴れの日、雨の日に行くことはできるけど、こういう天気は滅多にない、雨、雨上がり、曇り、晴れ。

鞍馬寺とかは、普通に山登りだった。山登りって、今まであんまりいい経験がなかったんだけど、今回は見るものすべて美しく感じたので、テンションあがりまくって、疲れた気分にさえならなかった。足はガクガクいっていたけど「なんでガクガクいってんだろう……」とか頭で考えてた。

貴船神社あたりは、川床の店がたくさんあった。本社のほうでは七夕飾りをやっていたので、僕も「フミにご縁がありますように」と書いてきた。短冊とかたぶん小学生か中学生以来すぎて独りでウケてた。ちなみに「フミ」は、コード (プログラミングは文芸だと信じています) とか、日記とか、文乃さんとか、文江さんとか、そういうのです……

なんというか、貴船あたりは時代が違うような錯覚に陥いってしまい、洋服ってなんか違和感あるなぁとかいうレベルだった。雨でリアルなコントラストが強かったせいかもしれない。

とにかくまぁ、昨日は、肺一杯に良い空気を吸いこんで気分がよかった。空気は記録に残せないし、行って価値が絶対にある。そして「緑」というのは、やっぱり眼で見ないと、確実な色ではないなぁと感じた。

あのへん、秋になったら本当に紅葉がすごそうだなぁと思った。そうでなくても、普通にまた行きたい。昨日のような天気であっても、それなりに人がいたから、普通の日はかなりやばそうだなぁと思った。

❤️ 投げ銭する

✖

16:55

ディスプレイの輝度落として作業すると彩度をあげすぎたり、さげわすれたりする。。

2009年 07月 26日

WAF の設計方法

subtech

00:14

結局、アプリケーション (not Web App = WWW 非依存) なものを Web っぽい部分とつなぐ Dispatcher (Router) があればよくて、あとはおまけっぽいので、HTTP::Engine + Router で WAF っぽい部分は終わりになるような気がした。

http://subtech.g.hatena.ne.jp/cho45/20090517/1242556113

と書いたのですが、あれを書いたときから、「そうだろうか?」というのを薄々と思っていました。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 なインターフェイスなのだから、ちゃんと書かないとだめ
自然と API に必要な機能が揃う
- CLI から叩こうと思ったとき必要な機能が勝手にできる

一方、微妙なところもあります

バッチ処理しかしないサーバーでも HTTPD を立ち上げてることになる
各ハンドラだけの実行をしにくい
テストが遅くなりがち

この辺はフレームワークでモックリクエストを充実させたら解決できます、というかちゃんとしたモックリクエストの仕組みがテストのために必須です。

[めんどくさくなったのでまた考えて追記する]

❤️ 投げ銭する

DBIx::RewriteDSN

subtech

16:44

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 に繋ぐような事故が防げると思います。

❤️ 投げ銭する

関連エントリー