_ 1470.netのユーザーページで参照元が見られるようになりました

久しぶりの機能追加ですが、1470.netのユーザーページ（のパーマリンク）に対する参照元情報（いわゆるREFERER）の記録＆閲覧機能を追加しました。といっても、MM/Memoの頃にはあった機能を今更ながらにリニューアル版にもつけただけなんですが。

ちなみに、1470.netではユーザーページは日付単位で管理しているので、参照元も日付ページ単位で管理されます。各日付ページの一番下にはその日付のページに対する参照元を（例）、ユーザーのトップページっ中段あたりには最近3日間の参照元（例）を表示します。

MM/Memoの頃とは違って、自分のページの参照元情報は自分だけ見られるというのではなく、誰でも見られるようになっています。また、MM/Memoの頃は最近の参照元情報のみ見られるようになっていましたが、今回は集計不可が大きくならない限りは、古い参照元情報も残しておく（見られるようにしておく）つもりです。

_ 自転車通勤往路

3ヶ月ぶりの自転車通勤。久しぶりすぎてかなりつらかった。ここ数ヶ月テニスばっかりやっていたからなー。ちなみに今日も自転車通勤の前にテニス朝練2時間。

• レーパンなしの普通の半袖短パンで出発したところ、出だしからケツというか、タマウラが痛かった。後半じわじわと広がっていくケツの痛みと共に、レーパンを履いてくるんだったと後悔。
• くそ暑い。冬場は750ml水分を余裕で余らせていたけど、この時期だと飲む量をコントロールしないと途中でなくなっちゃいそうだ。
• そういや最後に自転車に乗っていた頃は、自転車といえば鼻水（寒さ or 花粉症）という状態だったけど、久しぶりに自転車に乗っても鼻水が出なかった。なんて壮快なんだ！
• 17号上り方向志村警察署付近の左端車線が、3ヶ月前までは工事後のアスファルト埋め立てのできが悪くて、自転車だとかなりケツに来る荒れた路面だったんだけど、それが全面きれいに舗装されていた。えらいぞ、道路公団（かな？）。
• 明治通りは相変わらずの工事で荒れた路面。っつーか、あの工事って3ヶ月経っても進んでいるように見えないなー。表側じゃなく、地下の作業をずっとやっているのか？
• 明治通り新宿6丁目付近で、ジャンプ＆ウィリーをやっている29er（たぶん）がいた。29erほしさがちょっと高まった。
• 20号上り方面に向かって、のんびり走っているリカンベントと、明示道理の交差点で行き会った。まだ連休中？
• 17号（旧道）で、車道右側をゆっくりどうどうと逆走するばあちゃんと、正面から行き交った。なぜそのスピード＆逆走サイドなのに、車道を走る？
• 同じくばあちゃんが、広い歩道がある裏道で、車道の左側を走っていたのはいいんだけど、根本的に自転車でまっすぐ走ることができず、車道の端から端まで使ってふらふらと走り続けていた。このくらいになると、車道とか歩道とか逆走とかいう以前に、2輪の自転車に乗るのはやめさせるべきだ。
• なんだか無駄に心拍数が高いなー。スピードも大して出していないし、基本的に無理しないように走っていたのに。ここ数ヶ月で体質が変わったんだろうか？　心拍計の方で、最大心拍設定を187から189に上げるように指示された。

_ モビリオ初長距離

連休中に岩手まで行ってきた。モビリオ初長距離。

主に長距離燃費を確かめたかったんだけど、燃費走行（85〜95km/hあたり）で瞬間燃費計が16〜7km/lくらい、追い越し車線を巡航していても14〜15km/lくらいと、走り方による差はそんなに大きくない模様。といっても、追い越し車線を飛ばすような走り方をしたら、おそらく燃費もがっくり落ち込むだろうけど、そんな走り方をする車じゃないし。ちなみに岩手の田舎の空いている下道を巡航していたら、信号停車がある程度あっても、給油直後で20km/lオーバーをしばらく維持できた。一番燃費がいいのは60〜70km/h巡航あたりなのかな。

ちなみに、上記は瞬間燃費計での表示で、満タン法での燃費は13〜14km/l程度だった。普段は瞬間燃費計と満タン法での燃費の差はそれほど大きくない（せいぜい1km/l程度の差）なんだけど、高速巡航だとその差が大きくなる模様。あるいは給油するガソリンスタンドが安定しないから、満タン法の誤差が激しくなるだけだろうか？

7速スポーツシフトも試してみたけど、実用的にはエンジンブレーキの強さのコントロールにしか使わないかなー。あの車でマニュアルシフトでの加速とかしてもうれしくないし。

あと、エンジンパワー的にも上り坂で軽ターボよりもだいぶ余裕ができてくれた。前は長い上り坂で失速すると取り返しが付かなかった（追い越し車線の巡航速度に戻れない）からなー。

室内空間はもちろんムーヴよりもだいぶ広くなったんだけど、空間はあればあっただけ使ってしまうのが人情というやつで、すごく広くなったー！という感動はない。ただ、初めて6人乗りを試してみたけど、大人4人、子供2人程度だったら十分いけるな。足下はちょっと狭いけど。大人6〜7人は短距離以外はやめておいた方がよさげ。

あと、長い距離を運転していたら、なぜか右膝が痛くなった。なんか右足の角度が安定しないらしい。座席位置を前後にずらしてみても、いまいち変わらず。座布団でも置いて座面を高くする必要があるのかなー。

_ 自転車通勤復路

_ 麻布十番から渋谷まで歩いてみた

麻布十番の商店街を抜けて、六本木ヒルズ経由で六本木通りに出て、あとは渋谷までまっすぐ。寄り道しながらだらだら歩いても、50分くらいしかかからなかった。自転車で近いのは知っていたけど、歩くのもそんなにつらくない距離だな。ただ、六本木通りはあんまり面白みのない通りなんで、後半ただただ歩くしかないのがだるかったけど。

_ 昨日の自転車通勤のダメージは大きかった

3ヶ月も経つと、自転車関連の筋肉は完全に衰えてしまうもんなんだね。ケツが痛いのもそうだけど、（重い荷物を背負っているせいで）背筋から首にかけてもすげーつらかった。あと、足の持久力もなくなっているらしく、帰り道の後半は足がだるくて力が入らなかった。ケツをかばって乗っているうちに、両手の平も痛くなってくるし。

自転車に乗っていない間も、テニスはハードにやっていたから、それなりにいけるものだと期待していたんだけど、こんなんじゃしばらく自転車はリハビリ程度にしか乗れないな。たかが通勤でこんなにダメージを負っていたんじゃ、話にならない。

_ 自転車通勤往路

ほぼ一週間休んでケツの具合もだいぶ良くなったんで、今度はちゃんとレーパンを履いて自転車で出発。しかし、足の筋肉の弱りっぷりはただごとじゃないな。道半ばで早くも足がだるくなり始めた。これはしばらくの間はかなりのんびりとリハビリに努める必要がありそうだなー。

• 今日から交通安全週間なのかな？　白バイ＆警察官がたくさん交差点にいた。
• あと警察官が、民間の指導員に対する指導のレクチャーをやっている風景もあちこちでみかけた。

_ 自転車通勤復路

_ ガット張り替え

RDS002TOURのガット張り替え。前回と同じポリプラズマ128/面圧58。3/12にラケットを買ってから一度も張り替えてなかったから、約2ヶ月ぶりか。最初の一週間くらいで一気に固さが変わってからあとは、ずっと安定していたから、別にまだ大丈夫な感じだったんだけど、それなりの頻度で打っているし、一応替えておいてみる。まだ自分の技術が安定していないから、どこまで技術でカバーするべきで、どこまでガットのセッティングに頼るべきなのか、よくわからないんだよなー。

_ PHPで__setを使ったプロパティに対する配列要素の追加

PHP（5以降）で、

class Foo
{
  protected $_vars = array();

  public function __set($name, $value)
  {
    $this->_vars[$name] = $value;
  }

  public function __get($name)
  {
    return $this->_vars[$name];
  }
}

みたいに、プロパティに対して__get()、__set()を使ってアクセスするようなクラスを作って、

$foo = new Foo();
$foo->bar[] = 'test';

みたいに、プロパティに対して配列要素追加の演算子を使った場合、昔は期待通りに動作していた（$foo->bar == array(0 => 'test')になった）んだけど、最近のPHP（5.2.2）では期待したとおりには動作しなくなっていた（「Notice: Indirect modification of overloaded property Foo::$bar has no effect」になる）。確かに怪しい記法ではあったんだけど、これっていつから変更されていたのかな？

ググったら、関連情報としてPHP 5.2.0 で配列をオーバーロードするときの注意点 - PHPプロ！ニュースが見つかった。ArrayObjectって使ったことなかったけど、こういう使い道もあるのか。でも、なんかバッドノウハウ度が高くていやな書き方だなー。

あと、バグレポートでの関連議論「PHP Bugs: #39449: Overloaded array properties do not work correctly」。

まとめると、

• PHP 5以降で__get()、__set()を使ってプロパティオーバーロードし、プロパティがarray型の値を持つ場合、それに対して利用できる演算子は制約を受ける（$foo->bar[]= 〜や$foo->bar[$hoge] = 〜などは使えない）
• プロパティオーバーロードを利用したarray型のプロパティを、従来の配列型プロパティと同じように操作したい場合、ArrayObject＋ARRAY_AS_PROPSオプションを利用することで、ある程度対応できる（完全にネイティブ配列型プロパティ互換になるわけではない）
• PHP 5.2以前に、プロパティオーバーロードを使って配列型プロパティを操作するコードを書いた記憶がある人は、関連コードの見直しをガンガレ！　チョーガンガレ!　Notice出力している開発環境だと気づきやすいけど、production環境だと結構気づきにくいバグになったりするぞ！

_ mb_convert_kanaの'a'と'rn'は違うのか

元は、

/ ↑全角の斜線は強制的に半角に変換しちゃうのか…。

http://1470.net/user/shingo/2007/05/31#m_134678

というメモで、メモのコメント欄はmb_convert_kana($var, 'KVas')がフィルタとして設定されていた。半角全角カナ英数のみをそろえるだけで、記号は変換かけていないつもりだったんだけど、試しに、mb_convert_kana('／', 'KVas')すると、見事に「／」が「/」に変換される。

結論としては、mb_convert_kana('／', 'a')でも変換がかかった。aオプションって、マニュアルには『「全角」英数字を「半角」に変換します。』と書かれているけど、その下のAオプションのところには『（"a", "A" オプションに含まれる文字は、U+0022, U+0027, U+005C, U+007Eを除く U+0021 - U+007E の範囲です）。』という注釈がついている。んで、文字コード表で該当の範囲を見ると、がーん、'a'だと結構な数の記号が対象になっちゃってるじゃん。この記号の取捨選択の意図がよくわからん。

まあともかく、mb_convert_kana($var, 'KVas')じゃなくて、mb_convert_kana($var, 'KVrns')にしておいたほうがいいな。

_ Zend Framework（1.0RC）もだいぶ複雑になったなー

ようやくZend Framework 1.0RCのMVC周りの概要がつかめてきたんだけど、昔（0.6以前）読んだときと比べるとだいぶ複雑になっているなー。

MVC周りの結合度があがった

前は、シンプルなフロントコントローラ、ルーター、ディスパッチャー、アクションコントローラが疎結合して連携しつつ、それとは独立したシンプルなビューがある、って感じの構成で、ざっと関連ソースをながめれば全体像が把握できたんだけど、もうそんなシンプルな構成じゃなくなっている。

まず、以前は独立していたビューが、現在のバージョンではかなり密にコントローラ周りと結合している。といっても、それなりにインターフェースは整えられているんで、分離不可能になっている訳じゃないけれども、標準状態では一体化して動作する前提になっていて、古い（0.6以前の）知識で扱おうとするとかなりとまどう（特にViewRenderer周りの挙動がわかりにくかった）。

モジュールの導入

あと、以前はアクションコントローラやビューのディレクトリは、それぞれ一つだけ用意するような構造になっていて、そのターゲットとなるアプリケーションのスケールがそれほど大きくない感じだったんだけど、現在のバージョンでは、「モジュール」というアクションコントローラやビューディレクトリを複数管理するための仕組みが追加されている。おそらくは、一つのWebサイト（アプリケーション）で複数のサービス（モジュール）を実装するような、今までよりも大きなスケールに対応できる設計なんだろう。

モジュールの導入により、MVC周りの複雑さがかなり増している。今まではルーティングの結果は、コントローラ名＋アクション名＋パラメータに解決されていて、ソースコード的には、コントローラクラス＋アクションメソッドを追えば良かったんだけど、現在はそれにプラスしてモジュール名という要素もオプショナルに解決されるようになった。モジュール名付きでルーティングが解決された場合は、ランタイムで（コントローラやビューの）ディレクトリのスコープが変わるような動作イメージになってしまうため、コントローラクラス＋アクション名だけじゃなくて、収録ディレクトリレベルでソースを追う必要が出てくる。

標準でコントローラ周りと連携して動作するビューは、ランタイムで解決されるモジュールと自動的に連携するようになっているんで、標準で提供されるコントローラ＋ルーター＋ビューを使っているぶんには、「まあそういうもんだ」って感じで使えるだろう。

でも俺みたいに、Zend FrameworkのMVC周りをラップした自前のフレームワークを作っている人間には、非常に扱いにくい仕組みになってしまった。昔と違って、複数箇所でコントローラやビューが結合しているため、単純にコントローラ（あるいはビュー、あるいはルーター）クラスをラップしたクラスで置き換えるだけでは、うまく動かない可能性が高い。特にオプション設定＋アクションヘルパーなんかを経由して、遠回りに結合している部分（たとえばViewRenderer）なんかは、扱いが面倒だ。

現在のMVC周りのまとめ

昔のZend Framework（のMVC）は「取り替え可能なコンポーネント群で構成された、シンプルな疎結合のMVCフレームワーク」と紹介できたけれども、現在のZend Framework（のMVC）は「充実した拡張性を持つMVCフレームワーク。単純な拡張（機能追加）は容易だが、各コンポーネント間の結合は密なので、大規模な拡張（コンポーネント入れ替え）は難易度が高い」って感じかなー。

その他目に付いた主な変更点

って概要レベルの話だけでなく、目について主な変更点も上げておこう。

モジュール

さっきも書いたけれども、モジュールという複数のアクションコントローラ＋ビューを管理する概念が追加されている。これがおそらく一番大きな変更じゃなかろうか。互換性のためにモジュールがあってもなくてもそれなりに動作するような実装となっており、それがMVC周りのコンポーネントのコードの可読性を下げていて、ラッパー開発者にはつらいとこ。

アクションヘルパー

あと、新しくアクションヘルパーが追加されている。従来はヘルパーは、ビュースコープで使えるビューヘルパーだけだったけど、今回はアクションコントローラレベルのヘルパーが追加された。ちなみにアクションヘルパーはアクションコントローラ内のメソッドスコープだけでなく、グローバルな（アクションヘルパーブローカーのスタティックメソッド経由）スコープでアクセスできる。従来は、アクションコントローラよりも上のレベルで共用したいロジックは、グローバルなクラス（あるいはグローバルなファンクション）に実装するしかなかったけど、これでアプリケーションスコープで共用ロジックを置く場所ができた。

ビューエンジン

ビューは、新しくエンジンという概念が追加されて、従来のPHPコードを使って記述するビューだけでなく、Smartyとかのテンプレートエンジンを使えるようになった。らしい。というのは、レポジトリを見ても、いまだに他のテンプレートエンジンを使った実装が見あたらないから。MLとかを見ると公式のZend_View_Smarty実装があるみたいなのに。いったいどこにあるんだろう？（といっても、あまり真面目に探してないけど）

入出力ラッパー（Request/Response）

あと、だいぶ前からだけど、入出力にPHPの標準入出力をそのまま使わず、Request/Response系オブジェクトを経由するような仕組みになっている。この辺は（ラッパーを作ろうと）実装を追っていくと結構複雑で面倒くさい部分だけど、標準で使うぶんには従来とさほど変わらないかな？　テストとかを作るときにはだいぶ楽になるだろう。

Zend_Db_Tableの拡張

そういやZend_Db_Tableは実装（およびその元となる規約）がだいぶ変わったっぽい。あと、リレーションをたどる機能も追加された模様。ソースをながめた限りでは、機能が少なくてそのままでは用途が限られていた昔のバージョンとはだいぶ変わって、かなり実用的に使えるような雰囲気になっている。ただ、相変わらずモデルクラスをロードする仕組みは特にないっぽいけど、Zend_Loaderでもつかえってことなのかな？

その他

今のところMVC周り以外はほとんど見ていないけれども、AuthとかAclとかの認証・権限管理系のコンポーネントも標準化されていたり、各種ユーティリティクラス系もだいぶ充実している模様。前に見たときにはなかったバリデーション系クラスもちゃんとできているし。っつーか、昔のフィルターとバリデーターがごっちゃになっている仕組みは良くなかったし、それと比べるとだいぶいい感じになっているように見える（ざっと見ただけだけど）。っつーか、なんかWEBXP_FilterとかWEBXP_Validatorと似たような実装になっているなー。