ニコニコと2chに最大級の感謝を。
正直、舐めてたわ。今まで。2chとニコニコを。
でも、初音ミクの件でAce combat6の宣伝動画と組み合わせたMADを見て、改めて思った。
http://www.nicovideo.jp/watch/sm1318819
こーゆーのを許容できる場所があるのって、凄い。しかもそのミームの広がる速度も凄い。
半世紀前には考えられなかった事だ。
検索サイトを開いた瞬間に、我々は心理操作と情報操作の混沌に投げ込まれる。
抗する者達にとって、正悪善邪全て飲み込み坩堝に溶かすニコニコや2chはどれほど強力で心強い兵器であることか。
（まぁ、もちろん同じ性質を有しているので取り扱いには同じだけの注意は必要なのだけれど。）
ふと、こと日本における60年ごとの「おまつり」が起きないのは、2chやニコニコの影響が大きいのでは無かろうかと。
2chが、日本人に与えた精神的・金銭的影響を勘定すると、実は相当でかい筈。
ということに今更ながら、遅まきながら気が付いた。まあ、自分のいつものパターンだけど。
だからこそ（2chは自分は使わないだろうが、それでも）ニコニコと2chに最大級の感謝を捧げます。
多分、日本が平和なのは。1945年から60年経てもまだ「おまつり」が起きないのは。2chとニコニコの貢献が無視できないほどの要因になっているはず。
それか「おまつり」の舞台がネットに移ったのかも。
Dataクラス、最初の実装。
やっとSVNにコミットできた。長かった。
後はThreadのdaoを用意して、それが終われば実際のドメイン・・・というかトランザクション処理？相当のレイヤーを実装しよう。
トランザクションと言ってもrollbackができる訳じゃないけど。まぁ要するに、複数のdaoや物理ファイルにアクセスする場合とかをひとまとめにしたもの。それってMVCでのMに当たるんじゃないの？という話だけど・・・厳密に言うと若干変わってくるかも。
今回はXhwlayを使うにせよ、大まかにこんなレイヤー分けをするつもり。
ユーザー → Xhwlay → "Service Layer" → "Transaction Layer" → "Dao Layer"
横文字で格好良く書いてるけど、PofEA囓ったの使ってるだけなので。
- "Service Layer"
- POST/GETパラメータを、次の"Transaction Layer"の扱える形に変換する変換層。また、Transaction Layerからの戻りを、Viewで扱える形に変換し、XhwlayであればRendererにセットする変換層。要するにユーザー視点のデータ構造と、データ処理の為のデータ構造とを相互変換するレイヤー。
- "Transaction Layer"
- 物理ファイルや一覧アクセス時のインデックスファイルを複数操作する処理をまとめる層。まあ、そのまま。また、発生したエラー・・・というか、警告というか、ユーザーに何かしらアラートを知らせたい場合に、それを上部のService Layerに伝える役目も果たす。ErrorStackを使うのかな。多分。
Transaction Layerが要するに、「一覧処理」「バージョン変更」「更新」など、まぁ、データ処理の一連のセット毎に作られる塊。
Service Layerについては、恐らく通常のHTMLのレンダラ以外にも、RSS用などで分ける可能性が高い。あるいは、将来APIを用意する場合に於いても、ServiceLayerを追加する格好になるだろう。つまりPresentation層(というのか？)毎に用意することになるだろう。
ソートのロジックで致命的なミスしてた・・・。
ownerなどでのソート。あれ、ヤヴァイ。アホだ。
えーっと、つまり、一意でない値が入ってくるようなフィールドのソート処理全部。ええ。もう、察しの良い方はとっくに嗤っているかと。
// find系でファイルから読んだデータ($_els)を一行ずつarrayにバラして詰めているところ。 $_k = $_els[$_sort_by]; // $_sort_by はソートで指定されたフィールドに対する配列の添字。 ... // ソート対象の値をキーにして、行データをバラしてarrayにして詰め直している。 $records[$_k] = array( ... ); ... ksort($records); // ORDER_BY_DESC なら krsort
アホかと。馬鹿かと。これ、例えばownerフィールドで、同じ値が連続してたら、ファイルの下の方のレコードでどんどん上書きされていって仕舞いますよね。
orz
うーん・・・ああ、そうか。uksort()使えば良いのか。いや、そもそもソート対象をわざわざキーにする必要もないので連想配列にする必要も無くなる。usort()でイイじゃん。
<?php //... // "hoge" が、指定された $sort_by にあたる。 usort($records, create_function('$a, $b', 'if ($a["hoge"] == $b["hoge"]) return 0; '. 'return ($a["hoge"] < $b["hoge"]) ? -1 : 1;')); //... ?>
おお・・・できた。よっしゃ、えーっと・・・。
・・・
後で直しとこ。ヽ(°▽、°)ﾉｴﾍﾍﾍﾍ。
Threadクラスも実装終了。
Groupとかからのコピペであっという間に終了。
で、ずっと気になってたんだけどSimpleTestの弱みって setUp()/tearDown()が、test****メソッド「毎に」呼ばれてしまうのだ。
つまり、ある FooBar_TestCase クラス全体の、始まりと終わりで何か処理をさせたい、というようなフックポイントが提供されていない。
ということで、Threadのテストケースからはちょっと構造を書き換えてます。データファイルがあればチェックできる、find系についてはそのまま testFind***()系で記述しますが、テンポラリファイルなどを使用するCreate/Update/Delete系については、「testCUD()」みたいなメソッド中に集約し、テンポラリファイルの作成と削除などは一括して制御するようにしてみました。
<?php function testCUD() { // テンポラリファイルの作成 $this->_file = tempnam($this->_dir, "Thread_"); $this->_testCreate(); $this->_testUpdate(); $this->_testDelete(); // テンポラリファイルの削除 @unlink($this->_file); } function _testCreate() { // ... } // ... ?>
こんな感じで動かせましたので、どこかのタイミングで他のDAOのTestCase.phpについても同様に直しておきたいです。
