Ajaxという未来をWEBという歴史にどう接続するか

Pragmatic Ajaxという本のベータ版が公開されている。これはAjaxという今最も注目されているWEBの技術についての解説書だが、徹底的に技術指向でありながら、深く考えさせる内容を含んでいる。

技術解説書というのは、読者に新しい技術を勉強させよう目論むものだから、「Ajaxって凄いよ!あれもできるよ!これもできるよ!こんなに嬉しいよ」という話に終始しがちなのだが、この本の最後の「7.2 It isn’t all Just Wine and Roses...」という章は、Ajaxの暗黒面に焦点を合てている。

技術の長所と同時に短所もきちんと理解して使うのが、まさに " Pragmatic "なやり方なのだが、同時に、そこには「未来をどうやって歴史に接続するか」という、技術を超えた難問に対する思索の結果が見えてくる。

この章は、まず「WEBとは何だったのか、なぜここまで受け入れられたのか」という問題提起から始まる。


Even though Ajax has this power to change the web so radically, it behooves us all as developers to remember why the web enjoys such broad acceptance. It is based around certain standards (technical and visual) that have allowed users of all stripes to take advantage of services provided there. Those standards, some written and some simply understood, are vital to the success of all applications on the web,whether or not they use Ajax.


(試訳)AjaxがWEBを急激に変革する力を持っているの確かだが、WEBがなぜこのように広く受けいれられたのかを忘れてはならない。WEBは、技術的にもビジュアル面でも確固とした標準の上に確立されている。だからユーザは、提供されているサービスをフルに活用できるのだ。その標準は、文書化されたものもあるし、ただそのまま理解されているものもあるが、それらが成功の核心である。Ajaxを使っていようがいまいが、WEB上の全てのアプリケーションの成功の鍵は、その標準(にいかに準拠できるかということ)なのだ。

Ajaxは、ただ便利になるだけではなくて、この標準をなるべく壊さないようにしないといけない。そのためには、我々が今立っている「歴史」の本質を理解し尊重しなくてはならない。それが著者の暗黙の主張だと思う。

その暗黙の標準、つまりWEBの歴史と、Ajaxという新しい技術が葛藤を起こすテーマとして、以下の項目を論じている。

  • Watch that back button!
  • Bookmarking makes the web
  • GET is for getting, POST is for doing
  • Tell People When Updates are Happening
  • Don’t Reinvent the Wheel

まず「戻る」ボタンについて、著者は次のように言う。


The back button isn’t just a button; its a symbol of freedom.


(試訳)「戻る」ボタンは単なるボタンではない。それは自由の象徴なのだ。

「戻る」ボタンがあることによって、ユーザは安心してある画面から次の操作を試すことができて、その結果、予期しない都合が悪いことが起きたら、いつでも「戻る」ことができる。つまり、「戻る」とは情報の探検におけるUNDO(「取り消し」)なのだ。

WEBの中では、いつでも「戻る」ことができるので、ユーザは、気軽にどこへも進める。それが「自由のシンボル」という意味である。

Ajaxでは、最初にページを開いてから、ユーザの操作によって、同じページの中で内容が更新される。場合によっては、サーバから持ってきた新たな文書が、まるまるそのページに埋めこまれる。その時、もしユーザがその操作を「取り消し」したいと思ったら、ブラウザの「戻るボタン」を押すことで、ページの内容を復帰できると期待するだろう。

しかし、期待に反して、そのページの前に見ていた全く関係の無いページまで戻ってしまう。「取り消し」の「取り消し」つまり「進む」ボタンを押すと、問題のページを最初に開いた状態に戻る。

これは、世界中のどのWEBページを見ていても、常にそこにあった「戻る」自由という、ユーザが暗黙にWEBブラウジングに持っていた期待を裏切る動作だ。

そして、これと似たような問題で、さらに深刻な問題がブックマークにある。


we use bookmarks for deep linking. This means capturing the state of the application or site at some point after you have begun interacting with it. Perhaps the results of a search at Amazon, or the report of your current holdings at your financial institution, or some particular article at the New York Times. Deep linking means that users have the complete ability to pause and return to your application.


(試訳)我々は(Googleによって大半のサイトのトップページに到着できる現在においては)主としてディープリンクの為にブックマークを使う。これは、自分が好き勝手にいじった後で、そのアプリケーションの状態を保存することだ。アマゾンの検索結果、あなたの財政状態とそれについてのアドバイス、ニューヨークタイムズの特定の記事。ディープリンクができるということは、その(WEBブラウズという)アプリケーションにおいて、いつでも状態を保存しておいて、好きな時にその状態を復帰できるということなのだ。

RESTという言葉こそ使ってないが、これは、REST=コミュニケーション指向やBBもRemixableにされてPax Googlicaに飲みこまれるでしょうという記事で私が述べている、RESTの価値に通じる話だと思う。

WEBブラウジングというアプリケーションの状態は、ブックマークとして保存できるだけではなくて、URLによって他の人と共有できることに価値がある。ほとんど全てのWEBサイトが共通に持っている、こういう特性をAjaxは破壊してしまう可能性があるのだ。

Ajaxは、ひとつのページ(=URL)の画面の中で、対話的な操作を行ない、場合によってはサーバから持ってきた新しいデータでそのページの内容を書き換えていく技術だ。ということは、そのURLというのは、そのアプリケーションの中では、「開始時点」という意味しかない。

Ajaxなページの中で、対話的な操作を行なって、望むような、特定の結果が得られたとする。「その画面をブックマークに保存したい」とか「その画面を誰かに見せたい」という要求をかなえることができるのか。不注意なAjaxの使用は、それを不可能にしてしまう。

残りの3つの項目は、やや技術的に細かい内容だが、同様に「歴史に未来をどう接続するか」というテーマの具体的な問題を取りあげている。

もちろん、全てのクリック、全てのキーボード入力のたびに、新しいURLが割りあてられて、何がなんでも状態をブックマークできるべきであり、常に状態を「取り消し」できるべき、というのも非現実的だ。

完全に、「昔通りの懐しいWEB」しか許さないのであれば、Ajaxに限らず、新しい技術は導入できない。重要なのは、そこで少しだけ立ちどまって、それが本当にユーザにとって使いやすいものになるか、大局的に考えることだ。


Tactically, the change might increase the usability of this single page,but strategically, reduce the usability of the application as a whole.


(試訳)戦術的には、その変更によってそのページ単独の使い勝手はよくなるだろう。しかし、戦略的な目、より広い目で見てみると、その変更は、アプリケーション全体(サイト全体)の使い勝手にとっては、マイナスとなっているかもしれない。

自分がやろうとしていることが何なのか、それをユーザの立場から見ることができれば、それによって得るものと失うものを正しく比較検討することができる。

「続きを読む」が開いている画面をブックマークして、その「状態」を復帰した時に、「続きを読む」が閉じていても、問題ではない。しかし、ブックマークした時と別の文書がそのに現れたらユーザは混乱する。Ajaxによる操作でも、保存すべきものとそうでないものがあるだろう。

WEB全体に対してユーザが暗黙に期待しているものに、うまく適合させて、新しい操作を導入することは可能だ。Ajaxが、FLASH、Javaアプレット、Active-Xと言った、過去の「動くWEBコンテンツ」と違う長所があるとしたら、そのような「未来を歴史に接合すること」において、構成要素が同じHTMLエレメント(+CSS)である分だけ有利であるということだろう。

しかし、それを使いこなすには、WEBの歴史に対して大局的な理解が必要になる。

未来を現在につなげるには、歴史を知り自分を知ることが必要なのだ。

Pragmatic Ajax 概略

この本は、予想通りすごくいい本だと思いますので、ついでに、全体的な内容をざっと紹介したいと思います。

まず、章立ては以下の通り

  1. Building Rich Internet Applications with Ajax
  2. Ajax In Action
  3. Ajax Explained
  4. Creating Google Maps
  5. Ajax Frameworks
  6. Ajax UI, Part I
  7. Ajax UI, Part II

この中で、4章と7章が「さすがPragmaticシリーズ」と思わせる内容で、単なる表面をなぞった技術解説ではない、読みごたえのある内容でした。

Building Rich Internet Applications with Ajax

ここは、Ajaxの概要と歴史について。さっぱりとしたわかりやすい説明です。

Ajaxについて断片的な情報を得てやや混乱気味の人が、頭を整理するにはちょうどいいでしょう。よく知らない人が、これだけでAjaxを理解するには不十分かもしれません。

Ajax In Action

実例による「Ajaxとは何か」の説明。

郵便番号から住所を引いて来るという例を使い、余計なもののない最低限のHTMLとJavaScriptのコードを、基本から説明しています。

Ajax Explained

Ajaxプログラミングの重要事項(以下の三点)に関するポイント解説

  • 言語としてのJavaScriptについて
  • DOM
  • XMLHttpRequestObject

どれも最小限の説明ですが、特によいのは、言語としてのJavaScriptについて、普通でない所に的を絞って説明している所。型がないことや、関数がオブジェクトであること等、Javaのような普通の言語しか知らない人がビックリしてしまう所だけを解説しています。

たとえば、次のような例(クロージャ)ですね。

 var a = 10;

 var b = 12;

 var myFunction = function() {

   return a + b;

 }

 var result = myFunction(); // result is 22;

myFunctionもaもbも普通の変数です。普通の変数に関数を代入できるわけです。aに 10 を代入するのと同様に、myFunctionという変数に、動的に生成した関数を代入しています。しかも、その関数では、関数の外側にある変数を使っている。

こういう「あれっ」と思うような側面(であり、実際にAjaxのプログラミングで必要となる機能)を解説しています。

Creating Google Maps

ここは特に素晴しい。Google Mapsを自分で実際に実装してみようという章です。

無料の地図データを取って来て、そのシステム用に編集する所からはじまって、最低限ではありますが、動くGoogle Mapができるまでを、詳しく解説しています。非常に画期的なUIを持つGoogle Mapsですが、こうやって解説されてみると「なんだ、そんなことか」と思えてきます。

GUIのドラッギング等の処理をやったことがある人なら、JavaScriptやDOMについてよく知らなくても、容易に理解できると思います。

要するに、Google Mapsとは次のようなHTMLを動的に生成しているわけです。

 <div>

   <div>

     <img src="xxxxxx" />

     <img src="xxxxxx" />

     <img src="xxxxxx" />

     ....

   </div>

 </div>

外側の<div>は固定で、覗き窓になります。内側の<div>はマウスのドラッグによって移動する領域で、ここに<img>を貼りつけていきます。<img>は、現在表示している座標に合わせて、その位置から見える領域を計算して、それをイメージファイルのファイル名に変換して、対応する相対位置にイメージを置いていけばいいわけです。

これを、次のようなJavaScriptコードで実装します。

 function processMove(event) {

   if (!event) event = window.event; // for IE

   var innerDiv = document.getElementById("innerDiv");

   if (dragging) {

     innerDiv.style.top = parseFloat(top) + (event.clientY - dragStartTop);

     innerDiv.style.left = parseFloat(left) + (event.clientX - dragStartLeft);

   }

 }

これは内側の<div>をマウスのドラッグに合わせて動かす関数です。innerDiv.style.topは、DOMによるCSS属性へのアクセスで、これによって座標を設定しているわけです。

その移動につれて、見える地図のイメージを貼りつける必要があるわけですが、実は、ユーザコードで地図の断片を取って来る必要はありません。地図(のイメージデータ)を自分で持ってくる代わりに、<img>要素を動的に生成して適切な位置に置いておけば、あとは、それを解釈したブラウザが勝手に処理を進めてくれます。もし、エラーが発生したらそこに×を表示するという処理も含めて、<img>要素さえ置けば、あとはブラウザが勝手にやってくれるわけです。

イメージを分割してファイルにする時に、ファイル名を規則通りにつけておけば、その規則に合わせたファイル名をsrc=に設定すればいいわけです。

部分的にコードを示すと次のようになります。

       var tileName = "x" + tileArray[0] + "y" + tileArray[1] + "z0";

       var img = document.createElement("img");

       img.src = "resources/tiles/" + tileName + ".jpg";

       img.style.position = "absolute";

       img.style.left = (tileArray[0] * tileSize) + "px";

       img.style.top = (tileArray[1] * tileSize) + "px";

       img.setAttribute("id", tileName);

       innerDiv.appendChild(img);

この章では、こういうコードが、ステップごとに、ひとつづつ詳しく解説されています。

Ajax Frameworks

ここは、Ajax用のJavaScriptライブラリ、具体的には、PrototypeとDojoを紹介する章です。

生のJavaScriptで書くと、冗長で繰り返しの多いコードだったのが、その手のライブラリを使うと、次のようなお洒落なコードになるそうです。

 function getZipData(zipCode) {

   dojo.io.bind({

     url: url + "?zip=" + zipCode,

     load: function(type, data, evt){ assignCityAndState(data); },

     error: function(type, error){ assignError(error); },

     mimetype: "text/plain"

   });        

 }

このハッシュの形式で渡すパラメータにいろいろな設定項目があって、これを使って、非同期的な処理を同期に変更するとか、いろいろな指定ができます。

Ajax UI, Part I

この章は、上で紹介したライブラリを使って、Ajaxらしい派手っぽい画面を作る具体的なテクニックがたくさん紹介されています。

さすがに、動きのあるUIの説明なので、ここは読むだけではよくわかりませんでした。実際にコードを動かしながら読む必要があると思います。

Ajax UI, Part II

ここまでは「Ajaxって凄いよ!あれもできるよ!これもできるよ!こんなに嬉しいよ」に終始していましたが、この章はうってかわって、Ajaxの暗黒面に焦点を合てています。

こういう所をきちっと書いてくれる所が、本当に "Pragmatic" の名に恥じないというか、ここも第二の読み所だと思います。

最初は、非同期処理をどのようにユーザにフィードバックしていくかという話です。

たとえば、フィールド単位のエラーチェックを行なう場合、普通のJavaScriptではクライアントの内部の閉じたチェック、数値の範囲とか文字数くらいしかチェックできません。もちろん、JavaScriptの機能を駆使すれば、サーバ側のDBと突き合わせるようなチェックを行なうこともできるわけですが、そうなると、カーソルが移動するタイミングでサーバとのやりとりが発生して、その間、ユーザが操作できない時間が発生します。つまり、マウスやキーボードに反応しなくなってしまいます。

そこで、AjaxのAつまり、Asynchronous(非同期)の出番となります。XMLHttpRequestObjectを使うことで、サーバからの返答が来る前にも操作を継続できるようにすることが、Ajaxの意味というか新しさです。サーバにチェックの要求を送信してその結果を待つ間もユーザは、キーボードとマウスの操作を継続できます。

それによって、「フィールド単位のエラーチェック」と「サーバサイドで行なうチェック」と「ユーザの操作が中断しない」という三つのことが全部OKになるのが、Ajaxのメリットです。

しかし、同時に、そのことからこれまで存在しなかった、特有の問題が発生してしまいます。それは「ユーザがエラーを見逃す可能性」です。「サーバサイドのチェック中も操作が可能である」ということは、極端に言えばスクロールでページを最後の方に送ってしまうことも可能になります。

そうなると、エラーが発生したフィールドを赤くするとかのフィードバックを与えても、そのフィールドがユーザの見えない位置にあって、ユーザが気がつかないで次へ行ってしまうという可能性もあります。

だから、AjaxなUIでは、「あなたは先に行ってもいいけど、私はこのフィールドでチェックをしてますよ」というフィードバックをユーザに与えて、それを意識させる必要があります。これまでの「チェック中です」はマウスが砂時計になってクリックに反応しないとか、キーボードが反応しなくなるとかの形で、ユーザの操作を不可能にする形で暗黙にユーザに与えられていたわけですが、それと全く違う種類のフィードバックが必要になるわけです。

この章の最初は、このフィードバックを与える為に、具体的なテクニックの紹介です。

結果だけ言えば、チェック中は、入力したフィールドのすぐ横で何か小さなマークが回転していて、エラーが無ければ、チェック完了後に、そのマークが消える、エラーがあれば、マークが消えると同時にそのすぐ横にエラーメッセージを表示するという、そういうUIを作る方法です。

そのコードは、特にビックリするような凄いコードではないのですが、そのコードが必要となる背景、このコードはAjaxならではの新しい種類の問題に対する対策ですよ、ということが、詳しく説明してあって、そこがなるほどと思わせました。

この具体的な話の後は、上に書いた大局的な話が出てきます。

上の解説だけ読むと、思索的、理論的な本と思われてしまうかもしれませんが、そうではありません。深い思索の後は感じられるのですが、書いてあるのは具体的、技術的なことで、大半はコードが付属しています(でないと私は英語の本は読めない)。

ただ、そこには常に「なぜ」があって、「なぜ」から実際のコード例までが短かくつながっているので、読みやすいのです。

Ruby をはじめた唯一の目的は暇つぶし

mputさんの大変貴重なレポートを見て、一番どうでもいい所に注目する私ですが

 Q Ruby の開発は何かの目的を達成するために始めたのか?

 

 A いや。 Ruby をはじめた唯一の目的は暇つぶし

イノベーションの主体が組織から個人にとかよく言われますが、「個人」とは「個人の暇つぶし」のことで、暇つぶし以上に欲かいたら、それは「個人」ではありません。

HSKI's: 経営という独裁と離脱可能な従業員


労働者の味方を装う弱小政党は、二大政党時代に埋没したくなかったら、「離脱可能な転職環境を保障する制度の確立」あたりをぶち上げてみたらどうなんだろか。

これはまさに有望なニッチというか、ニッチ以上に大化けする市場だと思います。