2007年7月アーカイブ

Wii のバーチャルコンソールに SFC の風来のシレンがきたー。
がんばって原稿とかレポートを書き上げたらプレイするっぺい。

『おれは原稿を書いていたと
思ったらいつのまにかシレンが終わっていた』

な…　何を言ってるのか　わからねーと思うが（以下略

先のステートフルに関する連続エントリの最後が一日開いたのはシレンをやっていたと思っていただいて何ら間違いはありません。

さて、これから肉道頑張って、そのあとゆっくりと罠道を楽しみます。

第3弾の今回で最後になります。今回は、ステートフルWebアプリケーションで戻るボタンを利用するための方法、および戻るボタンの利用是非について紹介していきます。

(7) ステートフルWebアプリケーションで戻るボタンを機能させる

前述したとおり、ステートフルなWebアプリケーションではブラウザ機能の戻るボタンによる再描画に対しての振る舞いを簡単に抑制することが出来ます。通常は状態の遷移を行うための指示（以下イベント）を規定していく形でフローを構築するため、結果的に戻るボタンは機能しなくなります。

この戻るボタンを機能させるにはどうすればよいか。PCブラウザの場合、戻るボタンを押すと1つ前のサーバリクエストが発生します。このことより、通常の遷移と同じように戻るボタンを押すことで発生する遷移イベントを予め想定して設定しておけば良いのです。

図7. 3画面間を遷移するサービス

図7は、再び3画面を遷移するサービス例です。このサービスのステートフルモデルによる構築で、戻るボタンを有効化するための遷移イベントを追加すると、図8のようになります。

図8. 3画面間遷移サービスに戻るボタンを有効化

図中の赤矢印部分は、全く同じリクエスト内容であることを示しています。PageCが表示されている状態で戻るボタンが押されると、1つ前のリクエスト、つまりPageBが表示されるための「toB」が実施されます。PageCからPageBへ戻るためには、この「toB」イベントをPageC自身も受け取るよう準備しておけば、正しく戻るボタンによる状態遷移が出来るようになります。
なお、図8ではPageBからPageAへ戻るためのイベントが指定されていませんが、これはPageBで戻るボタンを押すことで実行されるリクエストが、このステートフルWebアプリケーションが開始されるためのリクエスト（ステートフルモデルから見ればイベント無しにあたる）で、厳密にはリスタートのような扱いとなりますので、PageBからPageAへは自然と戻っているように動作します。

ただし、全ての状態遷移について戻るボタンを有効にする必要はありません。図9の例を見てください。

図9. 会員登録アプリケーション例

図9は、良くあるサービス利用に伴う会員登録を行うためのアプリケーションフローの例です。説明文を表示した後、入力フォーム、確認画面、登録完了画面の4画面を遷移します。それぞれの遷移に伴う位置づけとして、登録開始（start）、入力項目の確認/妥当性チェック（validate）、情報確定と登録（register）です。この例において戻るボタンを有効化する場合は、以下の図10のようにすべきです。

図10. 会員登録フローに戻るボタンを有効化

先ほどと同じように、戻るボタンに伴う再リクエストで共通化している箇所は赤矢印になっています。ここでは、確認画面から入力フォームへの戻り（つまり再入力）にあたる逆遷移は戻るボタンの有効化で可能としているのに対し、完了画面から確認画面への逆遷移は設けていません。これは登録完了後戻るボタンにより逆遷移→確認画面から再び再登録 といった二重投稿を禁止するためです。「会員登録を行う」という目的のため動作させていたフローとして無事登録が終了した以上、画面を戻す必要はありません。もし仮に確認画面で見ていた入力情報をまた見せたいのであれば、この完了画面で再び表示すればよいでしょう。

なお、当然ながら「再読み込み」ボタンによる再リクエストの二重投稿も発生しません。これはステートフルモデル内で、完了ページが regisrer を受け取って何かしらの処理をするような設定を一切行っていないからです。完了ページを表示し最終遷移まで到達した今、このステートにおいてこれ以上の遷移およびそれに伴う処理が起きることは2度とありません。ステートレスなWebアプリケーションで良くある Token などによる二重投稿チェックなどは必要なく、ステートフルWebアプリケーションの利点の1つだと言えます。

このように戻るボタンを有効化するポイントは、そのアプリケーション毎においてケースバイケースで考える必要がありそうです。おおよそ、データベースへの挿入・変更処理が伴うポイントやメール送信といった、「一度だけ実施すればそれで十分」である処理に伴う状態遷移において考えることになるでしょうが、やはり現在のところベストプラクティスは出ていません。

(8) au 端末における戻るボタンの利用

過去2回にて紹介したとおり、au 端末における戻るボタンはPCおよび他の携帯端末とは異なり、ページキャッシュの再表示を行うよう動作します。
しかし au 端末は、戻るボタンそのものの動作（ボタンを押すとどうなるか）を制御することの出来る仕様をあわせて備えています。これは他の携帯端末にはない機能で、au EZWeb のコンテンツを構成する WML を記述することでこれを実現します。この事については以前あげたエントリの通りで、私も参加しているステートフルなWebアプリケーションフレームワーク Piece Framework の HOWTO にも記載されるようになりました。

Piece Frameworkを使ったEZWeb向けWebサイトの遷移制御

Piece_Unity HOWTO
EZweb端末の強制的なブラウザキャッシュに適切に対処する

前述した (7) のように、戻るボタンによって状態遷移イベントを発生させるよう振る舞う動作を au 端末向けにも実装するには、描写ページ内で WML を記述します。例えば図8の遷移を au 端末で実現させる場合、PageCの body コンテンツ内の末尾にリスト1のようなコードを埋め込みます。

リスト1. 図8の遷移を実現するための PageC HTML ソース (抜粋)

また、図10の遷移を au 端末で動作させる場合、完了画面コンテンツ内ではリスト2のようなコードを埋め込むことで、戻るボタンを完全に機能しないようすることができます。

リスト2. 図10の完了画面を実現するための HTML ソース (抜粋)

これで au 端末向けにおいても、PC や他の携帯端末と同じ動作となるようになります。
このように挙動の異なる場合においても、ちょっとした＋αのコードを追加する形でWebアプリケーションの仕様・挙動が共通となるよう構築するよう心がけるほうが、結果的に開発者およびサポート担当者の負担は軽くなり、最終的には還元される形でユーザにも使いやすいアプリケーションとなっていくのではないでしょうか。

挙動の異なる携帯キャリア向けに構築するステートフルWebアプリ
- その 1
- その 2
- その 3

前回のエントリの第2弾で、続きのお話になります。

今回はステートフルWebアプリケーションとしてシステム構築を行った場合、その基本的な動作のお話（おさらい）、戻るボタンに伴う動作、そして携帯端末におけるシステム利用と戻るボタンによる動作の違いについて、図による解説を含めて紹介します。

(4) ステートフルWebアプリケーションの基本動作

例えば以下の図1のようなサービスがあったとしましょう。

図1. 3画面間を遷移するサービス

PageA, PageB, PageC という3画面があり、PageAからPageB、そしてPageBからPageCという画面遷移を行うサービスであるとします。
ステートフルなシステムとして構築する場合は、PageAをスタート地点として、PageAからPageBへ行きたいという「toB」指示が出るとPageBへ遷移、同じくPageBにいる状態で「toC」指示が出るとPageCへ遷移するという意味になります。ステートフルですので、必ずPageAから始まることを限定しています。またPageAにいる状態で「toC」と言われても遷移することもありません。
このサービスを実際に実行した例が図2になります。

図2. 3画面遷移を実行した例

緑色のマークはこのサービスを利用するユーザ（クライアント）です。PageAから始まり、「toB」指示と共にPageB、その後「toC」指示と共にPageCへ遷移していることを示しています。PageA〜PageCまでを閲覧しているページ、緑色マークは現在閲覧中の場所の目印、黄色のふきだしはGET/POSTリクエストで、赤矢印はそれに伴う画面描写の切り替え（リフレッシュ）と観るとさらに分かりやすいかもしれません。

(5) 戻るボタン使用による状態の非遷移

上記図1の3画面遷移サービスに対しブラウザの「戻る」ボタンを使用するとどうなるでしょうか。

前述したように、あるページを表示している状態において想定していない遷移指示が出たとしても勝手に遷移するようなことはありません。通常は「意味のない指示」と判断し、その場の状態に留まろうとします。（ステートフルなWebアプリケーションを実現するためのライブラリおよびフレームワークの仕様に基づきます。）

例えば PageC まで遷移済みの状態から戻るボタンを押下した場合、ユーザは PageC の1つ前のページ、つまり PageB に戻ると想像することでしょうが、図3のように画面リフレッシュが行われたにも関わらずPageCが再描画されるという動きになります。

図3. 戻るボタンを押しても現ページが再描画される

(6) 携帯キャリア毎における戻るボタン押下と画面〜システム状態の認識ずれ

さて、この3画面遷移サービスを携帯端末で利用するとします。キャリア毎に携帯端末の仕様がありますが、基本的なWebアクセスのための通信機構はPCのものと何ら変わらない仕組みになっているため、PCと変わらないサービス内容を利用することができます。これは、戻るボタンに関する事柄も全く同じです。

前回にも紹介しましたが、Docomo, Softbank 端末の場合戻るボタンを押下すると1つ前に行ったサーバリクエストを改めて実施します。これはPCと同じ仕様のため、図3と全く同じ動きになります。
PCによる画面表示の情報量に比べ携帯端末は若干少ないため、「あれ、ひょっとすると画面が戻っていない？」と認識するまでに時間を要する可能性があるかもしれません。今まで当たり前のように利用していた戻るボタンがまさか効かないと考えることが出来ず、行動に対する応答内容のズレに混乱をきたす利用者も出るかもしれません。

au の場合はさらに悲惨なことになっています。前回のエントリの通り、auの戻るボタンはページキャッシュの再表示です。容赦なく前回ページをそのまま再表示しますので、図4のように完全に画面〜システム間の状態相違が発生します。

図4. auにおける画面〜システム間の状態相違

ユーザは戻るボタンでPageBに戻っているつもりですが、システムでは PageC にいることになっています。仮にこの遷移サービスが図5であったとしましょう。PageB からは PageC だけでなく、「toD」指示で PageD へ行ける遷移になっているとします。このようなサービスにおいて、au 端末で戻るボタンを駆使して画面遷移を行おうとすると、図6 のようになってしまいます。

図5. 画面間遷移するサービス その2

図6. ユーザにとって思いがけない画面遷移

PageC から戻るボタンで PageB に戻り、PageD へ行こうとします。画面上では PageB に戻ったことになっていますし、PageD へ遷移するための「toD」に相当するようなページリンクもあるでしょう。しかしPageB は「戻ったつもり」の扱いとなっており、PageD へ行こうとしても実際は PageC にいるわけですから、「PageC を再描画する」という動きとなります。ユーザにとっては「どうして！？」という動きに違いないでしょう。

このように、携帯キャリア毎にシステムそのものの挙動が異なることになっています。これらは統一した挙動となるよう、調整をかける必要があるでしょう。
またこれとは別に、戻るボタンそのものについてその取り扱いを考える必要があるでしょう。システムとして不具合が発生せぬよう制限を設けることは重要ですが、だからといってユーザビリティを損なうようなサービスにしてしまってはいけないということです。ということでもう少しだけ続きます。

挙動の異なる携帯キャリア向けに構築するステートフルWebアプリ
- その 1
- その 2
- その 3

以前 Piece Framework で作る EZWeb 向けサイトの画面遷移のお話をあげましたがその結果「極めて一部な人達にのみ好評」だったため、その補足および、より詳細な情報・アプローチを含めたお話です。久々に技術的なお話をあげたと思えばこういう極めてニッチな事柄であるのが hatotech::kumatch です。

なお既にタイトルに 1 とつけているだけあって、少しだけ連続したエントリになります。

(1) 挙動の異なる「戻る」ボタン

現在日本国内では複数のキャリアがそれぞれの携帯端末仕様を展開し、それらに準ずる端末が発売されています。
ご存知のとおり各携帯端末にはWebサイトを閲覧する機能が備わっており、各キャリア向けの仕様に基づくサイトを閲覧できる専用のブラウザが組み込まれています。
携帯端末ブラウザはPCで利用するようなブラウザと同じようにページコンテンツを表示したり「ブックマーク」「再読込み」といった機能が準備されていますが、そのうちの前画面に戻るために利用される「戻る」ボタンの挙動がキャリアによって異なることになっています。以下にそのパターンを紹介します。
なお、今回の話に Willcom や eMobile の端末は含めないものとします。現在のところこの2キャリアについては携帯キャリア端末としての動作とは異なり PC となんら変わらず振舞うことができると考えることができるからです。

● 再リクエスト形式
Docomo、Softbank の2キャリアは「戻る」ボタンを押下すると、1つ前に行ったサーバへのリクエストそのものを改めて行います。このとき画面に表示される内容はこのリクエストに伴う結果によるもので、これは PC におけるブラウザ仕様と同じであると言えます。

● ページキャッシュ形式
au の端末で「戻る」ボタンを押下した場合、1つ前の画面で表示していた内容をそのまま再表示します。通常は事前にキャッシュしていた内容を表示し、サーバへのリクエストは行いません。

(2) ステートフルWebアプリケーション

Webアプリケーションはステートレスと呼ばれるバラバラな処理と描写を連続して実行することで目的を達成しています。そもそもWebアプリケーション自体、HTTP という「リクエスト−レスポンス」のセット間同士に一切の関連性がない細切れな通信プロトコルを利用して動作しているわけですが、そのWebアプリケーションはある程度決められたやり取りをもって動作していることがよくあります。例えばユーザ情報を入力した内容を使用して会員登録を行ったり、商品をカートに入れて決済を行い購入確定とするショップサイトなどとといった具合です。
これら一連の流れ（フロー）をもって1つの処理内容（アプリケーション）と捉え実装する方法を、ステートレスWebアプリケーションに対し「ステートフル」なWebアプリケーションと呼びます。

ステートフルなWebアプリケーション開発は、既存のステートレス指向なWebアプリケーション開発で常に頭を悩ませる以下の問題に対し、驚くべき単純な解を与えてくれます。

●セキュリティ対策
一連の流れをもって1つのアプリケーションと考えており、いきなり最後の処理 (例えばデータベース書き込み) だけを実施するようなリクエストは排除

●戻るボタン対策
画面遷移の内容（ルート）を完全に制御するため、ブラウザの戻るボタンを押されたとき（及びそれに相当する操作）の挙動まで管理可能

●マルチウィンドウ対策
各ウィンドウごとに状態を保持することが可能であり、セッション情報の混合が起きず管理が容易

ステートフルなWebアプリケーション開発を支援するいくつかのライブラリ、およびフレームワークが登場しています。しかしそれを利用する上で開発を行っていく設計基準、手法にベストプラクティスがないのが現状です。

(3) ステートフルな携帯サイト

ステートフルなアプローチで構築するWebサイトでは、(2)で記載したとおりの恩恵を受けることができます。しかしながら構築するものが携帯端末向けのサイトである場合、以下のような理由でステートフルなWebアプリケーション開発による旨みが減少するだけでなく、「余計なこと」を考える必要があります。

●シングルウィンドウ固定
現在のところ、携帯端末で利用されているブラウザ内で複数のウィンドウを開くような概念は一般的ではありません。一部端末ではマルチウィンドウに対応していたりもするようですが、フルブラウザ (PCサイト閲覧向け) であったりということで今回のような話とは別件になります。したがってマルチウィンドウ対策を考える必要は特にないでしょう。

●戻るボタンの挙動の違い
前述した(1)で示したとおり、携帯キャリアにより戻るボタンの動作が異なります。Docomo、Softbank に関しては PC と同じように考えることができますが、au は完全にページキャッシュによる再描画を行うことが可能であるため、これに対する対策を別途考える必要があります。

●戻るボタンそのものの考え方の違い
私自身あまり携帯端末をヘビィに使うユーザではありませんが（加えて Willcom 端末利用のため PC と同等のように扱う）、携帯端末を利用する場合中央四方キーの左もしくは左側ソフトキーなどを使ってページを戻る（来た道を戻る）ような利用方法がPCブラウザ以上にあるのではないでしょうか。
これはPCブラウザの場合、マウスによるポインタ機能が備わっているため、メニューなどのページ内リンクによる画面遷移が比較的容易であるのに対し、画面内に描写できる量が限られる携帯サイトでは「メニューから項目を選択」→「詳細表示」といった画面遷移が取られていることが多く、結果他項目へ移る際に1つ前のメニューへ戻るために戻るボタンが利用されるというという流れです。

携帯端末における戻るボタン殺してしまうと、PCブラウザ以上に操作感を損なうことなるだけでなく、場合によっては混乱を招く恐れもあるのではないかと推測しています。このあたりのより詳細なお話を予告として、次回に続きます。

挙動の異なる携帯キャリア向けに構築するステートフルWebアプリ
- その 1
- その 2
- その 3

無駄にHDリマスターｗ

当然レコーダにも入れつつ観てたけど、しまったなあ、最高画質（非エンコード）で撮ればよかった。しかしこれでいつでも楽しめる。

自宅で使っているメインのデスクトップPCは2年程前に組み立てたコヤツなのですが、何やらAthlon 939 用のデュアルコア X2 4200+ が1万ちょいで買えるみたいなので思い切って付け替えてみた。

デュアルコア自体は普段使ってるノートが Intel C2D なのでどんなものか大凡分かってるものの、やっぱりシングルからデュアルにパワーアップするそのワクワクさ加減は半端ないです。まあコレに限らず新しい PC パーツが来るだけでもうワクテカなのですが。
で、全般的にキビキビ動き始めたのが嬉しかったので、ついでに OS も入れなおして完全におニュー状態に。起動とか超はやい。しかし使っていくうちに（これから導入していくなんらかのソフトウェアにより）また重くなっていくんだろうなあ。

さらに、今まで装着していた 939 の 3000+ が浮いてしまったのが勿体無かったので、939 用のマザーを買い足してサブ PC 化する計画を立てる。以前までのサブが XP 2500+ (豚) で DDR1 1GB x2, AGP 環境なので、939 用 AGP スロットかビデオオンボードマザーを買えばそっくりそのまま流用できるなと考えたところ、丁度 ASUS A8V (939 + AGP) が 4980円 で売ってるということでさくっと購入し組み立て。こちらも OS を入れなおして綺麗な体に。

で、次に浮いた XP 2500+ も勿体無かったので、別で稼動してる P4 1.7G のマシンと中身を入れ替え。512MB の DDR メモリも2枚余ってる状態だったので丁度よかった感じ。なお位置づけ的には 3rd PC なものの、現在のところ用途が 0 すぎて困る。DAoC してた頃は好評稼動してたのになあ。

最後に浮いた P4 1.7GHz はどうでもよいけれども、そこで使っていた PC133 512MB メモリが3枚も同時に浮いてしまったのが勿体無い。オークションにでも出そうかしら。

しっかり堪能した。

微妙に泣きそうになったりして、いよいよオッサンになり始めたのかなあとおもた。あのおばあさんの優しさ（ケーキのプレゼント）とか。だが付き人おばあさんの空気読めなさ加減＋無邪気っぷりでいい感じに中和してくれる。

んでもって来週はコマンドーだ。メイトリクス、楽しみに待ってるぞ。

現在の楽しみは、トレーニング直後に鏡の前に立って膨れ上がった筋肉を見て「いいわ〜」って思うことです。

ちょくちょく会ってる人は既に把握済みでしょうが、ちょくちょく自宅で筋トレ中なのです。

元々は、普段あまりにも運動不足だったことと、相変わらず華奢で運動すれば若干肉が付くだろうと思ったことが重なったのがきっかけ。
で、そのとき世間で盛り上がりつつあったビリーズブートキャンプに入隊する予定だったものの、内容かなりヘビィだという話を聞いて、先に付いていくための基礎体力から復活させないとマズイと考えたわけです。なんせ元々バスケや長距離をやってにも関わらず、社会人になってからは完全に運動しなくなり喫煙もしていたこともあったりで体力は最悪な状態でしたので…。

基本は、疲れたらやめる。その代わり、よっぽどの事がない限り毎日やる。酒飲んで帰ってきたり既に疲労してたり（前日からの筋肉疲労も含む）したらやらない。でもそれ以外ならば平日帰宅後でもやる。普段は仕事から帰ってきて米を炊いている最中の数十分程度と短いもの。疲れたらやめるのも、このあと夕飯を作るため。
こんな適当なものでも、明らかに肉の付き方が変わってきてます。脂肪を減らすための運動じゃなく肉をつけるための運動なので、参考にはならんかもしれませんが、腹筋とかもいい感じになりつつあります。

元々はブートキャンプ入隊のためのトレーニングだったのに、このまま継続すれば別にいらないんじゃないかみたいな。このままもうちょっと続けて、壁みたいなのに当たらないとなんとも分からないですね。

今月関西圏で予定している Piece Project としての活動が2つあります。

まず 7/20(金) 京都にて開催されるオープンソースカンファレンス2007に Piece Project としてイベントに参加します。

オープンソースカンファレンス2007 Kansai Piece Framework講演のお知らせ

Piece Frameworkの概要について、セキュリティに関するお話を踏まえつつ解説する予定だそうです。14:00 からということですが、7/20のタイムテーブルを確認して他のイベントとあわせてどうぞ。

また 7/21(土) には、新大阪でオブジェクトリレーショナルマッピングを提供するプロダクト「Piece_ORM」の勉強会を開催。

第8回Piece Framework勉強会開催のお知らせ

実際にプログラムコードを書きつつ動作の確認を行っていきます。Piece_Unity サンプルアプリケーションとの電撃合体 (新日風) による実装例も。