過去の記事 - 氾濫原

2010年 12月 23日

写真枚数

16:57

今年は約5588枚撮ったようだった。手元に残っているのは1800枚ほど。昨年は約4146枚撮って2800枚ぐらい残ってる。今年は撮る枚数自体は増えたけど、消した枚数が多かった。10000枚撮ろうというのは無理があるようだった。

✖

17:35

Canon 望遠ズームレンズ EF70-200mm F2.8L IS II USM フルサイズ対応 - キヤノン — Canon 望遠ズームレンズ EF70-200mm F2.8L IS II USM フルサイズ対応 cho45

キヤノン

★ 3.0 / 5.0
cho45

そういえば、土曜日にこれを買った。ちょっと自分が買うには高額すぎるので、どうかと思ったけど、レンズ買って貧乏になるならまぁいいかというのと、100mm が予想外に気持いい画角で、もうちょい望遠側にも興味が沸いてきたりした。事前に調べた感じだと、結構冷たい描写をする印象だったので、結構遠くから、冷静に、誰かいた感じを描写するにはいいのかもしれないと思った。

カメラ 890g + レンズ 1490g で 2.3kg なので、片手だと結構重いけど、MacBook と同程度なので、まあこんなもんかというのと、これがぎりぎりだなあぐらい。

土曜、日曜とちょっと撮った感じだと、撮ってるときは 100mm MACRO を買ったときの感動ほどはなくて、これはどうしたもんだろうと思ったけど、実際現像してみると面白いのでまあいいかな、という気持ちになった。とりあえず、できるだけ 200mm 側で固定して使ってみたけど、ふと立ちどまって画角決めると100mm前後になってしまうので、意識的に使わないとあんまり意味ない感じになりそう。

直前まで 50mm F1.2 と悩んだりした (やっぱ 50mm の明いのが欲しいというのがある) けど、50mm は言っても 1.4 あるしいいかと諦めた。

❤️ 投げ銭する

Apache2 + mod_perl2 の仕様と正しく mod_perl2 を使うための方法

subtech

23:17

Plack::Handler::Apache2 をちょっと使ってみているのですが、本格的に使おうとすると挙動がおかしいところがあって最近手を入れています (Plack にクソパッチを送ったりして申し分けない気分にはなりますが、背に腹は変えれないので、恥を忍んで送りまくってます……)。その間に気付いたこととかをいくつかメモ書きしておきます。

Apache2::RequestRec (以下 $r) の path_info は全く信用できない

$r->unparsed_uri から作りましょう。

この path_info とかいうやつは Apache がパースしたあとの値が入っているので、いろいろおかしいことになっていることがあります。例えば

foo///bar とかを foo/bar とかにしてしまう (重複するスラッシュが消えます)
ファイルシステムの内容に影響される

とかがあります。この $r->path_info から変なことになってない状態に復元することは不可能なので、$r->unparsed_uri から作るしかありません。基本的には以下のように

URI->new($r->unparsed_uri)->path

で PATH_INFO 相当になります。$r->uri というのあって "The path portion of the URI" と書かれているので、これも上記と同じ動作をするはずですが、信用できないので自力で unparsed_uri をパースしたほうが懸命な気がしています (遅いだろうけど、正しく動かないと早いも遅いもない)。

とはいえ、これで PATH_INFO 相当になるのは <Location /> で PerlHandler をしかけている場合に限っています。例えば /foo とかに PerlHandler をしかけたら、SCRIPT_NAME 相当のものは /foo で PATH_INFO は残りの部分になってほしいわけですが、上記のままではそうなりません (unparsed_uri を使って自力でやってるので当然です)。

SCRIPT_NAME を期待通りとる確実な方法がない

$r->unparsed_uri と $r->location から頑張って作りましょう。

subprocess_env でとれる SCRIPT_NAME は PATH_INFO と同様、ファイルシステムの影響 (よくわからず再現できなかったけど他の何かの影響をうけていることもある気がする) をうけるので信用なりません。 (SCRIPT_NAME と PATH_INFO は御互い重複する部分がないという性質があるので、一方が変わったら一方も変わります ref. RFC3875)

CGI とかの場合ファイルシステムを実際見るのはたぶん正しいと思いますが、mod_perl のように実際にファイルがあるかとかは関係なく Location を使ってハンドリングする場合、Location の位置を SCRIPT_NAME とし、残りの部分を PATH_INFO を扱ってくれるのというのが一番混乱しない仕様でしょう (まぁだいたい / にしか PerlHandler 書かないと思いますけど……)。

Location ディレクティブの引数は $r->location でとれるので、これを SCRIPT_NAME として扱えばだいたいいいんですが、ややこしいことに LocationMatch ディレクティブというのもあって、こちらは正規表現が使え、これも $r->location で取得できます。すなわち $r->location は正規表現の場合があります。といっても Location と LocationMatch を区別する方法はないようなので、どっちを使っているかは推測する必要があります。(実際のところ、こんなことしないだろという気はするので、汎用的にしないなら決めうちでどうにかしてしまうべきでしょう……)

で、もろもろ解決するため、テストを追加しつつだいたい動くであろう以下のようなコードを書きました。

    my $path_info = URI->new($r->unparsed_uri)->path;
    my $location = $r->location;

    if ($path_info =~ s{^($location)/?}{/}) {
        $env->{SCRIPT_NAME} = $1 || '';
    }