追記＠2012/02/03）解決したよ→今日の検索キーワード：ASP.NET MVC3、Subversion 1.7＋Eclipse動いた<!--more-->

WindowsでSubversion関連を扱うためのツール類をいろいろ使っているわけだ。具体的には、TortoiseSVNとか、EclipseのSubversionプラグイン（Subversive、Subclipse）とか、VisualStudioのSubversionプラグイン（AnkhSVN）とか。

で、各開発環境（IDE）を使うときにはそれぞれの開発環境用プラグインを使い、そうじゃない場合はTortoiseSVNを使っているわけなんだけど、TortoiseSVNは結構よくアップデートされていて、アップデートがあると起動時に「アップデートしないかい？」というダイアログが出る。

でまあ、Explorer拡張であるTortoiseSVNのアップデートはたいてい再起動を伴うんで、面倒くさくて「いいや、アップデートしない」としておくんだけど、しばらくアップデートしていなかったんで久しぶりに「いいよ、アップデートしても」と返事をした。まあTortotiseSVNのアップデートは今まで問題が出たことなかったし、特に何も考えずに。

で、アップデートしてから普通に使おうとしたら、「Working Copyの形式がSubversionの1.7形式になっていないから、1.7形式にアップグレードするかい？」と聞かれた。へー、今回のアップデートはその辺も変わったのかと「いいよ、やっちゃってよ」と返事をしたら、いろいろ問題が出た。

このフォーマット変更は、結構互換性がない変更だったのね。っつーか、.svnフォルダをルートのみに置くようになったのか。それはすげー便利。けど、Subversion 1.7形式に対応していない古いプラグイン達からこのWorking Copyを扱えなくなってしまった。くそー、Subversion関連のアップデートで今更こんな互換性がない代物が発生するとは。油断していた。

それでもまあ、VisualStudioプラグインであるAnkhSVNに関しては、ちゃんとSubversion 1.7以降に対応したバージョンがすでにリリースされていたんで、それにアップデートしたらちゃんと扱えるようになった。ありがとう。

しかし、Eclipseプラグインの方は、今までSubversiveを使っていたんだけど、こちらはまだSubversion 1.7形式に対応していない。試しにSVNKitの1.7対応アルファ版をインストールしてみたりしたんだけど、だめだった。

Subclipseは1.7対応版が出ているんだけど、今までSubclipseがちゃんと動いたことないんだよなー。インストールして動かそうとしても、JavaHL関連の依存関係エラーが出る。32ビットJava環境で動かしているはずだけど、OSはWindows 7 64ビットなんで試しにSilk SVNの64ビット版を入れてみたりもしたけど、状況は変わらず。

というわけで、結局現時点でEclipseのSubversion関連プラグインをSubversion 1.7形式に対応させるのは挫折。

まあそのうち標準的なアップデートインターフェースからアップデートされてくるだろうし、TortoiseSVNが使えるんでEclipseプラグインが使えなくても使い勝手が大幅に悪くなるわけじゃないんだけど、まだ1.7系にアップデートしていない人でEclipseも使っている人は、1.7系にアップデートするのはしばらくやめておいた方がいいと思う。

まあ、Working Copyを1.7形式にアップグレードせずに使い続ければいいんだろうけど、TortoiseSVNで新規にcheckoutしたWorking Copyを後からEclipseでマウントしようとしたら、SVNアクセスがうまくいかない、とかの罠にはまるのも面倒だし。

Zend_Frameworkにおけるバリデーションコードの置き場所ってどうよ？　ってのをいろいろ試行錯誤した結果、今のところこうしてるよ、というのをまとめてみる。

DBアクセスレイヤーは基本的にZendDbTableを使っている。テーブルにマッピングできないものも、データ操作レイヤーに関するものはapplication/models/以下に置いて、ZendDbTableと同じようなインターフェースを持たせて使う。で、共通化できるバリデータはこのモデルクラスにまとめて持たせる。

[sourcecode language="php"]
class ModelBase extends ZendDbTable
{
  protected $validators = array();
  public function getValidators()
  {
    return $this->validators;
  }
  public function getValiator($name)
  {
    if (!isset($this->validators[$name]) {
      $this->validator[$name] = new ZendValidate();
    }
    return $this->validator[$name];
  }
}
[/sourcecode]

みたいなベースクラスを作っておいて、 各実装クラスでは、

[sourcecode language="php"]
class FooTable extends ModelBase
{
  public funciton init()
  {
    $this->getValidtor('foo')
    ->addValidtor(new ZendValidateStringLength(5, 15));
  }
}
[/sourcecode]

みたいな感じでinit()内でバリデータをセットしておく。そうすると、ZendDbTableRowとかでこのバリデータを使いたい場合は、

[sourcecode language="php"]
class FooTableRow extends ZendDbTableRow
{
  public function isValid()
  {
    $result = true;
    foreach ($this->getTable()->getValidators() as $name => $validator) {
      $result = $validator->isValid($this->$name) && $result;
    }
    return $result;
  }
}
[/sourcecode]

なんて感じでバリデーションを書ける（上の例は共通バリデータをぶん回すだけでOKな場合の話ね）。また、このFooTableに対してのCRUDを行うようなZendFormでは、

[sourcecode language="php"]
class FormFoo extends Zend_Form
{
  public function init()
  {
    $fooTable= new FooTable();
    $foo = $this->createElement('input', 'foo');
    $foo
    ->addValidator($fooTable->getValidator('foo'))
    ->addValidator(new CustomValidatorForForm());
    $this->addElement($foo);
  } 
}
[/sourcecode]

なんて感じでFooTableの該当パラメータ用のバリデータを使うことができるし、それにフォーム専用の追加パラメータを追加することもできる。

アクションコントローラのパラメータの場合は、

[sourcecode language="php"]
class FooController extends ZendControllerAction
{
  public function fooAction()
  {
    $foo = $this->_getParam('foo');
    $fooTable = new FooTable();
    $validator = $fooTable->getValidator('foo');
    if (!$validator->isValid($foo)) {
      // IIIINNNNVALIIIIIIIDDDDDDDDDDD!!!!!!!!!!!!!!!!
    }
  }
}
[/sourcecode]

なんて感じで、使いたい要素のバリデータだけ引っ張り出して使える。

ということで、バリデータはモデルクラスにパラメータ名ごとに共通（使い回せる）部分を突っ込んでおいて、シチュエーションごとにそれを取り出しつつ、シチュエーションに特化したバリデータはその場でaddValidator()して使う、いう置き方が一番きれいなんじゃないかと思うのだが、どうだろう。

フィルターに関しては、まとめて同じ処理をしたいという要求がそれほど大きくない、というか同じパラメータでも入力シチュエーションによってどういうフィルターをかけたいかが変わるんで、必要な場所（アクションメソッドとかフォーム要素とか）にそれぞれ書くのが無難な気がする。フィルタークラス自体はアプリケーションに特化したものをapplication/filters以下に用意しておいた方が楽だけど。

と、久しぶりにZendFrameworkで新しいアプリを書こうと思い、どうせならZendFrameworkのコンポーネントを使い倒した書き方にしてみるかといろいろ試行錯誤した結果、こんな感じになったという話でした。

Windows Server 2008でManaged DirectXを使ったASP.NET MVC3が動かないという、ググってもレアケース過ぎて解決策が見つからないシチュエーションからの現実逃避の一環でもある。単にDirect 3Dのベクトル演算関数をサーバーサイドでも使いたいだけなんだけどなー。なんで依存関係が解決できないんだろう。

AndroidとiOS、プライバシーを丸裸にするソフトが仕込まれていたことが発覚 -INTERNET Watch

このCarrier IQってのは何なんだ？　OSをまたがって採用されているってことは、モバイル端末でトラブルが起こったときに後から詳しく解析するための情報を記録しておくための、ミドルウェアみたいなものなのかな。

しかも、この記事を読む限りでは、端末内にログを保存するだけでなく、外部にその情報を送信しているのか。送信処理がなくて、故障とかで修理送りになったときに工場とかだけで内容を確認するんだったらセーフだったかな？

【西田宗千佳のRandomTracking】PS Vita発売前の最終情報を開発チームに聞く -AV Watch

DSもVitaもゲーム機がどんどんPDAっぽくなってくるなー。結局PS Vitaはスマートフォンにゲーム優先動作モードをつけて、ゲーム機ならではの囲い込み機能を用意したものだよなー。最初のうちはゲーム機として開発されたVitaが先行するだろうけど、そのうちスマートフォン系機種にもゲーム方面に特化した亜種が増え始めて、あっさりVitaを食ってしまいそうな気がする。

なぜPHPアプリにセキュリティホールが多いのか?：第44回　セキュリティ対策が確実に実施されない2つの理由｜gihyo.jp … 技術評論社

gihyo.jp セキュリティ対策が確実に実施されない2つの理由

はてなブックマーク - 第44回　セキュリティ対策が確実に実施されない2つの理由｜gihyo.jp … 技術評論社

なんではてブでこんなに叩かれているんだ？　Rails関連はよう知らんけど、それ以外の内容で特に叩かれるようなことは書いてないと思うんだけど？

「多重のセキュリティ対策」って言葉に引っかかっている人がいるみたいだけど、単に「既にチェック済み，これは数値だからエスケープ処理は不要，などとの誤った判断からエスケープ処理を行っていないコード」みたいな事例に対して、入力値でバリデーションしたから出力値はエスケープしなくていいとか考えるなって言っているだけでしょ。

で、上記みたいな誤った判断をする人がその理由として、「だってDRYって言うし、いったんこの入力値に対してはチェックコードを書いたから、出力時の処理は書かなくていいよね」とか言いかねないから、「セキュリティ対策とコーディングのベストプラクティスは相反する」と言ってるんじゃないの？　結局ここで言うベストプラクティスってのは「重複処理を排除した効率よいコード記述」のことみたいだし。「それを重複と考えるのはおかしい」とか言っても、それを重複と考えるような馬鹿を前提とした文章だって読み取れるじゃん。

あと出力時のバリデーションに関しては、「1と2の対策が不可能な場合は出力時にバリデーション処理を行う」と書いてあるとおり、どうしてもエスケープなどを使った安全な出力ロジックが使えない場合は、しょうがないから出力に関してもバリデーションしようね、という話になっていて、別に推奨しているわけじゃないし、実際特殊な環境向けの出力ではあり得る話だと思うんだけど。

それにしても「セキュリティ対策」って言葉は曖昧で良くないな。

1. 普通に動作させるために必要な設計と実装（そして、それができなかった際に発生するバグ）。
2. 情報漏洩や情報破壊を引き起こしうるバグに対する注意。
3. 積極的なセキュリティアタックに対しての対抗策。

それらが全部なんとなく「セキュリティ対策」でくくられてしまうけど、全部混ぜて議論すると焦点がぼやけてぐだぐだになる。どこまでわかっている（問題にしている）人に対して、何を伝えたいのかがそれぞれ違ってくる。

前提条件

ZendFrameworkで、内部エンコーディングとしてUTF-8を利用しているWebアプリケーションを構築していて、一部ページのみガラケー（SHIFTJIS）対応したい。

問題

ZendViewFilterでUTF-8からSHIFT_JIS変換するフィルターを作り、ガラケー用コントローラのinitで

[sourcecode language="php"]
public function init()
{
  $this->view->addFilter('文字コード変換フィルター名');
}
[/sourcecode]

とかしてみた。すると、一見ちゃんと文字コード変換がかかったかと思いきや、一部文字化けしている。

調べてみると、addFilterしたフィルターはZendViewがレンダリング処理を走らせるたびに実行されるんで、レイアウトとかを使って内部で複数回ZendView::renderされてしまうと、その部分で複数回文字コード変換がかかる→文字化けする、ということらしい。

ZendFrameworkで文字コード変換 - slumbersでは、ZendLayoutControllerPluginlayoutを拡張したクラスで出力時に変換をかけたらうまくいったよって話が書いてあるけど、もうちょい楽な方法ないかなー。

解決策

複数回フィルターがかかるのがいやなら、出力する文字列が最後まで確定した後にフィルターがかかればいいんじゃないか、ということで、ガラケー用のレイアウトファイルの一番最後に、

[sourcecode language="php"]

....(省略)
<?php echo $this->layout()->content; ?>
....(省略)

<?php $this->addFilter('文字コード変換フィルター名');
[/sourcecode]

とかしてみた。うまくいった。

【PC Watch】 Seagate、ハイブリッドHDD「Momentus XT」を強化 ～容量750GB、NANDは8GBで高速化

HDD750G＋SSD8Gに増量。SSDが安くなるのを待っていたけど、これでもいいかもなー。値段がこなれてくるのは来年頭くらいか。

Apple、15インチのMacBook Air準備中との噂

私物でMacを買うとしたらこれがいいかなー。

キミ・ライコネン、ロータス・ルノーGPでF1復帰！ 【 F1-Gate.com 】

ライコネンはラリーよりもF1向きだろうから、F1のそこそこのチームに帰ってきた方が活躍できるだろうけど、あそこまでの成功を収めた後に、もう一度中堅チームから地道にステップアップしていくモチベーションが残っているだろうか。それにつけてもクビサのもったいなさよ。

今日のテーマも昨日の続き。

だいぶ攻撃的なファーストサーブの確率が上がってきた。のだが、逆にファーストサーブが何本か連続で入った後のセカンドサーブにミスが増えてきた。ファーストはフラットとスライスを多用し、セカンドはスピン多めのスライスなんだけど、ファーストのフラットサーブが連続して入った後のセカンドサーブをこすりすぎることが多い。回転系サーブ中心に打っていくぶんにはだいぶダブルフォルトをすることは減ってきたんだけど、これからはフラット、スピンを交互に打ちつつもスピンの確率を上げる練習もしないとな。

今日はフォアハンドの調子が良く、ベースラインからも浅いチャンスボールもしっかりコースを狙って打てることが多かった。ただし、それがうまくいくのはある程度テンポがいい打ち合いからの展開のとき。相手が緩い気の抜けた球を打ってきたときには、力んでしょうもないミスをしてしまうことが多い。これは実戦でもよくやるパターンなんで、相手が弱い球しか打ってこないときに、ミスをせずにしっかりポイントを取れるようにならないと。

ネットプレイは、頑張ってたくさん出たんだけど、やはり決定力不足。完全にネットについた状態で待てればそれなりに決められるんだけど、ネットへ付く動きの流れでボレーをするときには、ミスしないように安全に返しすぎて、逆に相手のパッシングチャンスボールを与えてしまう。これは頭で考えて何とかなる気がしないんで、場数を重ねて体で覚えていくしかないかな。

asahi.com（朝日新聞社）：給水地点に水がない！　静岡のマラソン、参加者脱水症状 - スポーツ

《公式サイト》ふじのくに新東名マラソン 2011年11月20日(日)開催

公式サイトには何もお詫びも報告も出てないんだな。→お詫びあった

@nifty：デイリーポータルZ：スッポンを捕まえよう。そして食べよう。

この間市場でスッポン丸ごと売ってたなー。チャレンジする勇気がなくて変えなかったけど、チャレンジする価値があるんだろうか。

オリンパスの粉飾疑惑、金融庁が12年前に黙殺(1) | 企業戦略 | 投資・経済・ビジネスの東洋経済オンライン

同庁は「関係書類が残っていないので、コメントは控える」としている。

金融庁ってこういう事件の調査書類を12年以内で破棄してしまうのか。すごいな。

お知らせ | blog MONSTER KISS

彼は福島原発の３０キロ圏内で野宿をしていませんし、 そこで釣った魚を食べたという事実もありません。 もちろん、記事にそのような内容はありません。

Facebook の CSRF 対策トークンを盗み出す手口 | Symantec Connect Community

認証コードの確認のふりをして、CSRFチェックトークンを含むソースコードをコピペさせるのか。

今週のテーマは攻撃力アップ。具体的には

• ファーストサーブを攻撃的に（フラットも交えて）狙う
• 積極的にネットに出てポイントを取りに行く
• ボレーは安全マージンを取りすぎず、きちんと決めにいく
• 浅い球は強打だけでなく、コースや球種も選択肢に入れて決める。必ずしも一発で決める必要はなく、有利な状況を維持したままポイントにつなげられればいい

というあたり。まだいまいち体になじんでいないんでミスも多いが、一応テーマは意識して動けた。ただ、いつもより運動量が多くなるせいか、早い段階で息が切れてしまった。やっぱり基礎体力練習もしないとだめか。

グループA ジョコビッチ vs. ティプサレビッチ

•  ティプサレビッチ def. ジョコビッチ 3-6 6-3 6-3

ファーストセットをジョコビッチが圧倒して取り、もしかして本気で最終戦を取るつもりでギアを上げてきたの？と思いきや、セカンドセット以降はティプサレビッチのいいプレイばかりが目立つ展開。結局圧倒的だった今シーズンは、怪我による失速で最後は尻つぼみに終わってしまった。ナダル同様、めいっぱいフィジカルを酷使すれば強いことは証明したから、今後はフェデラーのようにフィジカルコンディションを維持しつつ、どこまで安定した強さを維持できるかが課題か。

グループA フェレール vs. ベルディヒ

•  ベルディヒ def.  フェレール 3-6 7-5 6-1

この大会はフェレール安定して強いなーと思っていたら、セカンドセットをベルディヒが巻き返し、最後はフェレールにしては安定感を失ってしまった。これは見事な体力切れ？　これでフェレールはグループA、2位抜けになってしまうんで、準決勝はフェデラーと当たってしまうことになる。この失速状態でフェデラーと当たるのは厳しいな。

準決勝 第1試合　フェデラー vs. フェレール

• フェデラー def. フェレール 7-5 6-3

最終戦というよりは、普段の大会のフェデラー vs. フェレールといった戦い。まだ元気があって調子が良かった大会序盤のフェレールだったら、もっといい勝負ができたかもしれないのに。

準決勝 第2試合 ツォンガ vs. ベルディヒ

• ツォンガ def. ベルディヒ 6-3 7-5

フィジカル的なスペックは同じくらいだけど、闘争心は倍くらい違いそうな二人の戦い。このクラスの戦いになると、最後までしっかり攻撃できる方が勝つことが多いな。ベルディヒは下位への取りこぼしの少なさだけでなく、上位に対してアップセットできる攻撃するメンタルが欲しいところ。まあこのクラスになってしまうと、上位と戦う機会自体がそれほどないんだけど。

決勝 フェデラー vs. ツォンガ

• フェデラー def. ツォンガ 6-3 6-7(6) 6-3

安定して強いフェデラーと、強引に勝負してエラーも多いがポイントをもぎ取る能力も高いツォンガの戦い。普通だったらフェデラーが競り勝ち、ツォンガのできが良ければツォンガがスーパープレイで競り勝ちそう。

序盤はフェデラーが安定感でツォンガを上回ってファーストセット先取。セカンドセットも同様の展開だったのだが、最近のフェデラーの悪いパターン＆ツォンガの捨て身の攻撃で、フェデラーのサービングフォーザチャンピオンシップをツォンガがブレイクバック。さらにタイブレイクの1ミニブレイクアップからフェデラーが2本サービスポイントを取れば勝つというところからも、ミニブレイクバックされてしまい、セカンドセットを落とすフェデラー。

ここでツォンガが乗ってきそうな展開だったんだけど、フェデラーはファイナルセットの序盤何とか踏みとどまって流れを対等に引き戻す。お互いいいプレイを続けながらの3-4のツォンガのサービスゲームをフェデラーがブレイクし、今度こそはきちんと試合を締めて、フェデラー6回目の最終戦優勝。

大事なポイントやゲームを取りきれない勝負弱さが目立ってきたフェデラーだけど、それでもフィジカルコンディショニングまで含めればまだまだナンバー1復帰もあり得るか。ただ、ピークコンディション同士の戦いだと、年齢的な問題もあってさすがにトップ4の中では分が悪い。現状でもGS中心のスケジューリングで戦っているけど、ここから先はナンバー4以内を維持しつつ、本気でウィンブルドンだけを取りに行くようなスケジューリングの方がいいのかもしれない。ただ、普通の大会に出てもそれなりに勝っちゃうからなー。もっと大会出場数を絞るべきか。