2007年2月アーカイブ

前回のエントリに引続き、今回も Piece アクションクラスについてです。アプリケーションを作成する上で役に立つヘルパー基底クラスを準備するにあたって、じゃあ実際アクションクラスで何をやっているのかを再確認していきます。

今回は基本に戻り、「入力」→「確認」→「完了」という簡単なウィザードステップを伴うアプリケーションを、3種類のテンプレート (PHP, Smarty, HTML_Template_Flexy) を使った場合どのような違いが出るかというところを確認してみましょう。先のエントリより明らかにこっちを先に示すべきだな ;)


2/17 の Piece Framework 勉強会のときにちょこっと話をしてたんですが、Piece でアプリケーションを作成する際のアクションクラス内の行為・行動例が程よく上がってきつつあります。

(1) 使用頻度の高い行為

=> ページ描写に利用する変数値の割り当て

  $viewElement = &$this->_payload->getViewElement();
  $viewElement->setElement('foo', $foo);

という内容。そのページに動的な値(変数値)を当てはめるならば 100% 登場。

(2) 状況に応じて必要とされる行為

=> Request 値の取扱い (Validate 含む)

  $validation = &$this->_payload->getValidation();
  if (!$validation->validate('Registration', $registrationElement)) {
      ....
  }

という内容。ある状態遷移と共になんらかのリクエストが発生する場合にしなければならない。

(3) 極めて稀だが実行の必要な行為

=> Configuration の動的設定

  $config = &$this->_payload->getConfiguration();
  $config->setExtension('View', 'renderer', 'Renderer_PHP');
  $config->setConfiguration('Renderer_PHP', 'templateDirectory',
                            '../webapp/templates/Extra'
                            );

とかの行為。
ただしこんなシーンは基本的に「如何ともし難い理由により動的変更する」というニッチなシチュエーション、つまり「開発者が分かりきった上で任意のタイミングに変更する」ことが殆どなので、どうでもよいっちゃあどうでもよい。

で、これらの処理をサポートするヘルパーを基底クラスを準備するのが分かりやすくて良いですね、というお話。つまりこんな感じ。

(1) ページ描写に利用する変数値の割り当て

  $this->_setViewElement('foo', $foo);

拡張的な機能として以下のようなものも準備できそう。

  $list = array('foo' => $foo);
  $this->_setViewElements($list);

(2) Request 値の取扱い (Validate 含む)

  if (!$this->_validate('Registration', $registrationElement)) {
      ....
  }

1 ステップ減る程度。いうほど嬉しくない。

(3) Configuration の動的設定

  $this->_setExtension('View', 'renderer', 'Renderer_PHP');
  $this->_setConfiguration('Renderer_PHP', 'templateDirectory',
                           '../webapp/templates/Extra'
                           );

でもなんとなく変にみえる。このコードだとアクションに対しての setConfiguration みたいに見えるからか。

基本はこれを使うんだ!とか説明できるようになればドキュメントも楽になりそうです。この辺、次もしくは次々リリースくらいで第一弾が同梱されるよう頑張ります。

正月実家に帰ったときに旨い醤油をかっぱらってきたおかげで、この手の料理が美味しくできます。
問題は明らかに一人分としてできないことだな。

20070218_01.jpg

ついでになんかマグロがやけに安かったので、「ヅケ」にして丼に。こちらも醤油か。醤油が旨けりゃなんでも旨い。

電気代:7500円
ガス代:6000円

電気代はまあ範疇内、というかこんなもんかなと。昼間は家にいないものの帰宅後活動時間に入れば PC とディスプレイ複数台数稼動するわ別途 TV はついてるわで。しかしこのガス代は何とかならんのか。家族が暮らす一般家庭並みの料金のような気が。一人身であっても家庭であっても、普通に自炊し風呂に入るという行為をしてる以上完全なる固定費として発生するだろうなあ。

ということでこりゃ本格的に ALL 電化な生活環境に移行すべきなような気がしてきた。聞くところによると電気+ガスの時分より半分くらいの光熱費になるそうだし、電気機器先行の環境で暮らしている手前より効果がありそう。今住んでいるところをそのまま All 電化にするのは厳しそうなので、新しい部屋を考えるか、いっそのこと本格的に住居を考えるかかな。

Piece Framework で実現する「検索→結果」+ページャ機能を有した最小限フローとして、なかなかすっきりしたものが出来たんじゃないかと思ってしまったのでちょこっと発表。あとで ITEMAN に叩いてもらうぜ ;)

まずステートチャート図はこちら。

20070208_01.png

これを Piece の YAML ファイルとして書くとこんな感じ。

firstState: DisplayForm

viewState:
  - name: DisplayForm
    view: Form
    activity:
      class: SearchMember
      method: setupForm
    transition:
      - event: search
        nextState: processSearching
        action:
          class: SearchMember
          method: search

  - name: DisplayResult
    view: Result
    activity:
      class: SearchMember
      method: viewResult
    transition:
      - event: turnNext
        nextState: processTurn
        action:
          class: SearchMember
          method: turnNext
      - event: turnPrevious
        nextState: processTurn
        action:
          class: SearchMember
          method: turnPrevious

actionState:
  - name: processSearching
    transition:
      - event: goDisplayForm
        nextState: DisplayForm
      - event: goDisplayResult
        nextState: DisplayResult
  - name: processTurning
    transition:
      - event: goDisplayResult
        nextState: DisplayResult

で、実際の PHP コードは以下のような感じ。

<?php
class SearchingUser extends Piece_Flow_Action
{
    function search()
    {
        $this->_criteria = new StdClass();
        $validation = &$this->_payload->getValidation();

        if ($validation->validate('SearchUser', $this->_criteria)) {

            $this->_limit = 100;
            $this->_criteria->offset = 0;
            $this->_criteria->limit  = $this->_limit;

            $this->_search();

            return 'goDisplayResult';
        } else {
            return 'goDisplayForm';
        }
    }

    function turnNext()
    {
        $this->_criteria->offset += $this->_limit;
        $this->_search();

        return 'goDisplayResult';
    }

    function turnPrevious()
    {
        $this->_criteria->offset -= $this->_limit;
        $this->_search();

        return 'goDisplayResult';
    }

    function viewResult()
    {
        $viewElement = &$this->_payload->getViewElement();
        $viewElement->setElement('results', $this->_results);
    }

    function _search()
    {
        $manager = new UserManager();
        $this->_results = $manager->search($this->_criteria);
    }
}
?>

あくまでミニマムな内容で、Pager 機構としてもとりあえずな動作のみ。ちなみに UserManager クラスは実際の検索を行う任意のドメインオブジェクト。

Piece_Unity 0.9.0 から追加された「アクション継続」によって、同フローが続いている限りアクションクラス内のプロパティ値が継続して保持され続けます。(それも特定ウィンドウ上の値であることが保証された状態で。)したがってコードも構成も極めて直感的でシンプルにまとまります。

(以下、ネタばらしはありませんのでご安心ください)

開いた時間にコツコツやってきた Wii 版ゼルダも無事終了。
まさかここまでとはと驚くほど、本当に面白かったです。

神のような 2D ゲームだった神トラから衝撃的かつ神のような 3D ゲームに進化した時オカのようなインパクトとまではいかなかったものの、やはりリモコン操作によるプレイがまず素晴らしいです。
はじめはリモコンのポインタ+モーションというデバイスに感動し、慣れるにしたがって自分とリンクの動きが同調しはじめ、最後には剣や各種アイテムの使用動作まで体とシンクロし使いこなす感触というものが凄く気持ちいい。

ゲームそのものも本当によく作られてます。

実は今回ゼルダを遊ぶにあたって、プレイヤーとしての視点とは別のもうひとつの視点もあわせもった状態でプレイしました。それは今回のゼルダの作り、つまり演出・展開であったりデザインであったり、さらにはインターフェースまわりやシステムの設計部がどうなっているか、なぜこう作られたのか、あるいは用意されたのか、といった具合の確認です。

私は演出家ではないですしそもそもゲームの作り手ですらありません。ですがいち技術系開発者であると同時にクリエイターでありたいと願っています。
何らかの製品、システム、サービス、エンターテイメントといった「モノ」を作り、世に送り出し、そしてそれが認められる(受け入れられる)ことは非常に大変なことです。それを実現するためにはどうすればよいかを考えなければならないわけですが、そのためにはまずそのものを知ることも重要だと思います。

実際プレイを始める前(Wii 発売前)に関連する記事やインタビューなども確認して、本家の「社長が訊く」のゼルダの項なんかも読み、実際プレイしてみて、あぁ、やっぱり宮本氏は God Man なのだなあと。受け入れられるためのエッセンスに溢れています。そしてその結果プレイヤーにとっては面白いゲームとしてプレイできるのだなあと。

 
最後になりますが、ゲーム内ミニゲームの1つに今回も「釣り」があるのですが、このシステム+アルファの仕様で釣りのゲームそのものがリリースされることを期待します。アルファ部分はステージ、魚の種類と難易度あたりのボリュームが増える、で十分です。

http://mayu.sourceforge.net/

窓使いの憂鬱の開発は終了いたしました。また、Windows Vista では動作しません。

やっべー



ITMedia の記事 (http://plusd.itmedia.co.jp/pcuser/articles/0609/05/news012.html ) によれば、

(1) 32bit 版の Vista では、デジタルサインのないデバイスドライバを使用すると、HD DVD や Blu-ray を視聴することはできない。
(2) 64bit 版の Vista ではデジタルサインのないデバイスドライバは動作できない。

ということになっています。mayu はキーボードカスタマイズを実現する際にドライバを利用していますので、上記のような状況になります。したがって Vistaへ mayu をインストールするのはお勧めできません。また、Vista へ OS をアップグレードする前に mayu をアンインストールしておいてください。

ということらしいです。
ちなみにこのデジタルサイン、年間10万円くらいだそうだそうですが個人で取得できないようで、どこかの会社がソースを引き継いだ上でリリースしてもらう必要があるようです。

Vista を入れる予定は今のところ一切ありませんが、もし仮に今後 Vista 以降の OS を使用する際に困りますね。Windows + mayu でヘタなウィンドウマネージャー以上の機能と操作性を誇る環境を使用している手前、継承したソフトウェアが登場しない以上、この環境が引き続き実現できるウィンドウマネージャーを探さねばならんということですね。

ちなみに要求される機能のうち大きめな要件は

・モディファイヤのカスタマイズ
・2 ストロークキーマップ動作
・1 キーで 2,3 の機能
 (ex. 「変換」キーを単独で押すと「変換」キー、別のキーと一緒に使うと Alt)
・アプリケーション・ウィンドウレベルの挙動変更機構
・ウィンドウ操作全般

最後に開発者の奈由太氏には深く感謝を申し上げたいと思います。
このソフトのおかげで、札束のお風呂に入りながら美女に囲まれることはありませんでしたが、快適な PC 操作はできているのですから。

20070204_01.jpg

日曜の真昼間からこれを作っている男をどう思う?

 
ちょいと煮過ぎて卵が崩れちゃってますが。
一度作って残りは冷蔵庫にいれておくと1週間くらい食べれるのが素晴らしい。白いご飯食べまくり。こういう系統のが色々作れるとやっぱり便利です。

そういえば Blog に書いてなかったなあというお話なのですが、HDD レコーダ買ったんですよレコーダ。去年の 12/30 に。

殆どテレビ見ないんですけど、ここぞという番組のときに限って当然ながら家にいなかったり、あと今日はテレビ見ながらゆっくりするぜーというようなタイミングに限ってクソ詰まらん番組しか放送してなかったりとかあるじゃないですか。そういう時のために1つあっても良いんじゃないかなと思って。シリーズで番組取りまくりとかしない限り、最近安くなってきたレベルのレコーダで十分です。

恐らく3年後くらいにはもう BD とか HD-DVD の話もすっかり終結してると踏んでいるので、今買うことで3年+αの年数は凌ぐことができるだろう、というのも購入の理由。現行レコーダからの進化って、メディア部分以外ではあとはもう容量増加および HDD の自由交換機構が実装されるくらいしかないんじゃないかしら。ということでゴリゴリ編集しまくるのではないライトユーザならば、今の辺りが1つの区切りと思ってます。別にどっかのまわしもんじゃないですが。

まあ、タモリ倶楽部くらいしか毎週予約してないんですけどね。

以下の RSS フィードを取得することで、当 blog のDAoC 関連オンリーの内容が参照できます。

http://hatotech.org/kumatch/archives/cat_daoc.rdf

このアーカイブについて

このページには、2007年2月に書かれたブログ記事が新しい順に公開されています。

前のアーカイブは2007年1月です。

次のアーカイブは2007年3月です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。

Powered by Movable Type 4.01