アプリ開発の

アプリ開発の新しい動向

@maruyama097

丸山不二夫

Agenda
o  Facebookの選択の波紋
o  「Webアプリ」とは何か？
o  Webの世代について
o  Webを取り巻く環境の変化
o  変化の三つの方向
o  WebプロトコルとHTTPの見直し
o  サーバーとクライアントの役割の見直し
o  開発言語の見直し

TechCrunch誌とのインタビュー
2012年9月11日
I think the
biggest mistake
that we made,
as a company,
is betting too
much on HTML5
as opposed to
native…
because it just
wasn’t there.
会社として、我々が犯した最大の誤りは、ネーティブに対して、
HTML5に、あまりに賭けすぎたことだと思う。

「スマートフォンのアプリを、HTML5で
Webアプリ化する」というビジョン
o  開発の現場ではiOSとAndroidの両方のアプリを作って
いるところは多く、同じアプリを、わざわざ、Objective-C
とJavaの二つの言語で開発するのに苦労しているところ
は少なくない。その上、Androidの場合には、機種ごと
OSのバージョンごとに違いが大きいという問題もある。
o  PC上のWebの世界がそうであるように、ハードの違い、
OSの違いに関係なく、誰でも、ほぼ同じコンテンツを楽し
めるようにスマートフォンのアプリを作れればと、多くの開
発者は考えていると思う。
o  HTML5の表現力と新しい機能が、スマートフォン
上のWebアプリを、ネーティブ・アプリと同等以上
のものにするだろうという展望は、魅力的なもの

「何が、モバイルFacebookを遅くした
のか」　　　　　　　　　　　　　　9月15日
o  W3Cのメーリングリスト public-coremob@
w3.orgへの、Facebookの技術者Tobie Langel
氏の投稿。”Perf Feedback - What's slowing
down Mobile Facebook”
o  どういう理由で、FacebookがiOS向けのアプリを、
ネイティブ中心に作りかえたかの理由を、モバイル
Webの作成中に遭遇したパフォーマンスの問題を
詳しく報告している。

1. 開発ツール / 開発者用のAPI
o  モバイル・ブラウザーのツールが欠如している
ことが、実際の問題がなんであるかを掘り下
げ、発見することを非常に難しくしている。ツー
ルあるいはそれらの欠如が、本質的な問題で
ある。
o  メモリー問題では、　　　　FPS
p 
n  Heap size, n  ハードウェア・レベルで
n  Object count, fpsを計測する能力
n  GC cycles,
n  GPU buffer size,
n  resource limits.

2. スクロールのパフォーマンス
o  これは、我々の最も重要な問題の一つである。
ニュースフィードやタイムラインを無限スクロール
する時（ユーザーがアプリを下向きにスクロール
する際、コンテンツは先読みされ、追加される）、
あるいは、膨大な量のコンテンツ（テキストと画像
の両方）を逆向きに読む時、典型的に問題になる。
o  現在は、我々は、スクロールは全てJavaScript
を利用して行っている。その他の選択肢では、（実
装上の問題で）十分な速さが得られないので。

o  QoI Issues
n  一定しないフレームレート
n  GPUバッファーの枯渇
n  ネイティブ実装も、OS毎に違う印象を与える
n  Androidのタッチイベントのパフォーマンスの問題
o  Requirements
n  ...
n  ...
o  new API suggestions
n  ...

3. GPU
o  現時点では、GPUはブラックボックスである。
（ベンダーが、そうしようと思ったつくりになって
いるということ）　
o  しかしながら、実際には、開発者は、与えられ
たコンテンツを、無理にでもハードウェアで高
速化する為に、そうしたトリックを利用せざるを
得ない。
o  今日のコンテンツが消費するサイズと、GPU
バッファーのサイズのギャップ。

Zuckerburgの発言を詳しくみる
o  And it’s not that HTML5 is bad. I’m actually, on
long-term, really excited about it.
それは、HTML5が悪いということではない。長期的には、
私は、HTML5にとても興奮している。
o  One of the things that’s interesting is we
actually have more people on a daily basis
using mobile Web Facebook than we have
using our iOS or Android apps combined. So
mobile Web is a big thing for us.
興味深いことの一つは、iOSとAndroidのアプリを使って
いる人をあわせた数よりも、モバイルのWeb Facebook
を使っている人の方が多いということだ。だから、モバイル
Webは、我々には重要なものだ。

「Webアプリ」とは何か？

Webアプリの特徴
o  クライアントとしてのWebブラウザーの利用
o  データ表現に、HTMLを利用。
o  通信プロトコルに、HTTPを利用。
o  サーバー・サイド・プログラミング。

o  人間がブラウザーの前にいることを想定した、
インタラクティブなアプリ。

Webの世代について

p  第一世代　　Static Web
p  第二世代　　Dynamic Web
p  第三世代　　Structured Web
p  第四世代　　Real-Time Responsive Web

第一世代　　Static Web
o  1989年、CERNのティム・バーナーズ＝リーが、
研究者のドキュメント管理のツールとして構想。
1990年末に実装。
o  HTTPは、Hyper Text Transfer Protocol
HTMLは、Hyper Text Markup Language
Home Page 等、ドキュメント交換ツールの母斑
は、今も残っている。
o  1992年、NCSA Mosaic登場。
1995年、JavaとApplet登場。
同年、インターネットの最初の爆発が起きる。

第二世代　　Dynamic Web
o  第二世代のWebは、Webアプリの登場とともに
始まる。そこでは、HTMLのページは、サーバー
上のプログラムで、動的に生成されることになる。
o  このDynamic Webの登場は、Webの歴史の中
でも、ある意味革命的な変化であった。一方向に
情報を伝えるだけだった「ホームページ」は、イン
タラクティブな「アプリケーション」に変わった。

サバ・クラ・モデルとWebアプリ
o  Webアプリ登場以前の、エンタープライズのネット
ワーク・アプリは、いわゆる、「サバ・クラ・モデル」
で、アプリの開発者は、サーバー側とクライアント
側の二つのプログラムを作る必要があったばかり
か、サーバーとクライアントを結ぶネットワークの
プロトコルを設計し、そのプロトコル上で運ばれる
データの形式を考える必要があった。
o  Webアプリは、プロトコルをHTTP、データの形式
をHTML、クライアント・プログラムをWebブラウ
ザーに固定することによって、ネットワーク・アプリ
の開発を飛躍的に容易にした。

Webアプリによる「配布問題」の解決
o  同時に、Webアプリは、サバクラ型ネットワーク・
アプリの懸案だった、沢山のクライアントのプログ
ラムの配布・更新をどのように行うのかという、
「配布問題」を鮮やかに解決した。Webアプリで
は、サーバーのプログラムを書き換えるだけで、
アプリケーションは更新される。

エンタープライズ・システムの
主流になったWebアプリ
o  Webアプリは、こうした優れた特徴によって、エン
タープライズ・システムの主流に、またたくまに躍
り上がる。
o  20世紀の末から21世紀の初め、ITバブルの頃。
ASP, J2EE, Springといった著名なフレーム
ワークが大きな成功を収め、その簡易版である
LAMPも、広く受け入れられるようになる。

クラウドも、基本は、Webアプリ
o  現在のクラウドも、クラウド上のシステムの設計者
から見れば、ScalabilityやAvailabilityは補強
されているのだが、そのアーキテクチャーは、基
本的には、サーバー・サイドのWebアプリのエン
ジンに他ならない。
o  このように、Webアプリのアーキテクチャーとその
アイデアは、今日も、強力な影響力を持っている。
o  クラウド・デバイスの開発者達が、こうした歴史的
な成功を、自分たちのフィールドにも持ち込もうと
するのは、ある意味、当然のことである。

第三世代　　Structured Web
o  現在のWebの世代を特徴付けるのは、もはや、
残念ながらWebアプリに代表される、Dynamic
Webではない。その変化は、むしろ、エンタープラ
イズのシステムの中からではなく、コンシューマ向
けのシステムから生まれてきた。
o  先行するものは、20世紀末からあるのだが、
Webの新しい世代を画期付けたのは、何と言っ
ても、AJAXの登場であった。この言葉が出てくる
のは、2005年頃、その時の主役は、やはり、
Googleだった。

それまでのWebアプリの制限
o  それまでのWebアプリでは、ブラウザーの表示に
対する人間の入力は、HTTPのRequestに乗せ
られてサーバーに送られ、サーバーがそれに対
する処理をおこなって、新しい表示画面を
Responseとして返す。
o  サーバーの処理が終わるまで、人間は、だまって
待っていなければならない。第二世代のWebア
プリというのは、こうしたHTTPのRequest/
Responseの繰り返しなのである。

AJAXの特徴
o  AJAXは、それに対して、ブラウザー上の人間の
アクション、例えば、マウス・ポインタの移動とかマ
ウスのドラッグといったイベントを全て捕まえて、
ページのRequest/Responseのサイクルを待つ
こと無しに、非同期にシステムに送りつける。シス
テムは、また、非同期にそれに対する処理を、ブ
ラウザーに返す。

AJAXの実装　構造化されたDOM
o  AJAXのシステムは、もはや、第二世代のWebア
プリのように、テキストで表現されたHTMLを操作
の対象にしていない。AJAXのシステムでは、
HTML/CSSの情報は、その構造に即して、メモ
リー上に構造化されたDOMとして展開される。
o  システムは非同期にそれぞれのDOMにアクセス
して、その内容を動的に書き換えることが出来ま
る。ブラウザーは、変更されたDOMの内容を、た
だちに表示する。DOMへのアクセス、内容の変
更に、主にJavaScriptが使われることも、AJAX
の大きな特徴の一つになる。

スマートフォン・アプリの出発点
としての、第三世代Web
o  こうした第三世代のWebを、構造化されたDOM
をハンドルの対象としていることで、Structured
Webと呼ぶことがある。
o  もしも、スマートフォン・アプリを、Webアプリ化し
たいのなら、例えば画面へのタッチや、スワイプ
操作を検出したいのなら、第二世代のWebアプリ
では、対応出来ないことは明ら。スマートフォン・
アプリのWebアプリには、この第三世代のWeb
技術が出発点になる。

インタラクティブなアプリとしての
Webアプリ
o  先に、Webアプリの特徴として、「人間がブラウ
ザーの前にいることを想定した、インタラクティブ
なアプリ」という特徴を与えた。
o  こうした観点は、それぞれの世代の個々の要素
技術の相違にもかかわらず、Static Webから、
Dynamic Webへ、Dynamic Webから
Structured Webへの発展を、統一的に捉える
ことを可能にする。
o  同時に、こうした見方は、Web技術の更なる発展
を予想するものである。

第四世代　　
Real-Time Responsive Webへ
o  Webの世界は、今や、次の世代に変化しようとし
ている。それは、人間に取って、より直感的で使
いやすいものへの進化を求められている。
o  第四世代のWebは、Real-Time, Responsive
Webと呼ばれることが多い。その意味、それに対
する期待は、名前を見れば明らかだと思う。
o  私たちは、現在、この新しいWebの世界の入り口
にたっている。

Webを取り巻く環境の変化

p  クラウド・デバイスの、飛躍的な拡大。
p  マシンのハードウェア性能の向上。
p  ネットワークの高速化と、それを上回るス
ピードでのトラフィックの増大。
p  最新のWeb技術に接する人の増大。

クラウド・デバイスの、飛躍的な拡大
o  新規の出荷台数ベースで見ると、こうしたクラウ
ド・デバイスの数は、2012年で、Windowsや
MacといったPCの数を上回っている。
o  かつては、インターネットに接続するにはPCが必
須だった。また、Webアプリがターゲットにしてい
たクライアントはPCだけだった。
o  PCの普及がインターネットの普及を支え、エン
タープライズでのPC利用の拡大が、Webアプリと
いうアークテクチャを生み出したのだが、いま、PC
の時代は、終わろうとしている。

Webの世界の主役、Webアプリの主要
なターゲットとしてのクラウド・デバイス
o  去年までは、クラウド・デバイスの中心はスマート
フォンだったが、こうした構造にも変化の兆しが見
えている。
o  今年のアメリカのクリスマス商戦では、iPad mini
とNEXUS 7とKindle FireとSurfaceが激しく
争っている。わずか一年で、タブレット市場を独占
していたAppleのシェアは、半分に落ち込んだ。
o  こうした競争は、クラウド・デバイスの新しい市場
をさらに拡大して、PCの時代の終わりを、さらに
早めることになる。

マシンのハードウェア性能の向上
o  10年前は、PCではPentium 4がよく使われてい
たが、最新のCore i5/i7では、20倍から30倍以
上、CPUは速くなっている。
http://www.cpubenchmark.net/
common_cpus.html

Intel Core i7-3960X
@ 3.30GHz
12,784

Intel Pentium
4 3.00GHz
367

クラウド・デバイスのマルチ・コア化
o  クラウド・デバイスに多く利用されている、消費電
力の少ないARM系のチップの性能向上も目覚ま
しいものがある。ARM系チップのマルチ・コア化
は、このところ急速に進んでいる。
o  例えば、DoCoMoの2012年冬モデルは、10機
種中6機種が4コアで、残りの4機種も2コアになり、
シングルコアとデュアルコアしかなかった一年前
とは、大きく変わっている。

個人が携帯するマシンのパワー
o  10年前のサーバー・マシンを、はるかに上回る性
能のマシンを、現在は、個人が日常的に持ち歩い
ている。
o  ただ、現在のWebアプリでは、クライアントとして
のクラウド・デバイスは、基本的には、サーバーか
ら送られてくるデータをブラウザーがレンダリング
しているだけである。

ネットワークの高速化と、それを上回る
スピードでのトラフィックの増大。
o  例えば、W3C.orgのトップページは、ページがで
きた1996年には、たった800バイトの一つの
HTMLファイルで出来ていた。
o  それが10年前の2002年には、HTMLファイルは
31KBになり、5つの画像ファイル13KBを含むよ
うになった。
o  現在2012年の、W3C.orgのページは、1
HTML (31 KB), 31 Images (97KB), 4
CSS (40KB), 2 JS (90KB)で、この10年で6
倍以上になっている。

ネットワークのリソースに、
大きな負担をかけるAJAX
o  現在のWebの主流であるAJAXも、トラフィックの
増大に拍車をかけている。ブラウザー上で何かの
イベントが起きるたびに、クライアント・サーバー
間で、頻繁にトラフィックが発生する。
o  HTTPは状態を持たないので、データの送信のた
びに、HEADERの情報は繰り返し送られる。
o  また、サーバーからクライアントへデータを送る通
信路を確保する為に、クライアントは、定期的に
サーバーをpollingしたり、あるいは、一度つくら
れたコネクションを、長期にわたって維持しようと
試みる(Long Polling)。

クラウド・デバイス固有の問題
Fast Dormancy
o  電話網を通じてインターネットに接続しようとする
クラウド・デバイスの場合には、その為に電話網
との制御信号のやり取りが必要になる。それは、
当然、必要なことである。
o  ただ、そこには、一つ問題がある。実は、デバイス
側は、電池の消耗を避ける為に、当面不要と思
われるプロセスを、どんどん休止状態にしていく。
Fast Dormancyと呼ばれるもの。これはこれで、
デバイスの電池のもちを延ばす為には、欠かすこ
とが出来ないものである。

クラウド・デバイス固有の問題
Signaling Burst
o  普通のプロセスを休眠させるだけならいいのだが、
ネットワークのプロセスが休止するとコネクション
は切断されてしまう。結局、プロセスが休眠から
覚めるとき、コネクションの回復の為に、あらため
て電話網との制御信号のやり取りが必要になる。
o  ユーザーが気がつかないうちに、あるいはプログ
ラマーが意識しないままに、デバイス上では、コネ
クションの切断・回復が繰り返され、時によっては、
ネットワークを流れる本来のデータより、制御信
号のトラフィックの方が多くなるということが起きる。
Signaling Burstという現象である。

最新のWeb技術に接する人の増大。
o  日本では、これまでガラ携しか使ったことのない
人が、大量に、スマートフォンのユーザーになって
いる。世界中では、初めて持った携帯電話がス
マートフォンだと言う人は、何千万人の単位で存
在する。
o  こうした人たちに、現在のWebの技術は、どのよ
うに見えているのだろうか？　また、逆に、スマー
トフォンを、既に何台か買い替えている人たちは、
最新のデバイスに対して、どのような期待を持っ
ているのだろうか？

UIとUXの改善は、最重要の課題
o  クラウド・デバイスの利用者達の、グローバルな
かつてないほどの規模拡大ということは、世界人
口の大多数にとって、最新のテクノロジーに触れ
る条件が整い始めているということである。
o  そこで何よりも必要とされていることは、IT技術に
対する知識を前提とはせずとも、誰にとっても直
感的で分かりやすいユーザー・インターフェースと、
誰にとっても快適なユーザー体験を提供すること
である。

ユーザー・インターフェースの改善
o  もちろん、ユーザー・インターフェースの点では、
この間大きな進歩があった。
o  タッチスクリーンの導入は、キャラクター端末から、
デスクトップ・メタファーとポインティング・デバイス
によるUI/UXの改善以上の進歩だと思う。
o  また、音声認識技術に基づく、自然言語を用いた
インターフェースも登場し、多くの期待を集めてい
る。

Real-Time, Responsive Webへ
o  ただ、人間の欲求が無限だからかも知れないの
が、我々は、必ずしも、現在の我々の経験に満足
している訳ではない。
o  我々は、もっと快適で反応のいい技術を求めてい
る。来るべきWebの世代が、Real-Time,
Responsive Webと呼ばれているのは、とても
示唆に富んでいると思う。

変化の三つの方向

p  WebプロトコルとHTTPの見直し
p  サーバーとクライアントの役割の見直し
p  開発言語の見直し

変化の予兆
o  アプリ開発の今後の変化について三つのトレンド
を紹介する。それは、様々な角度から、Webアプ
リの基本的な前提の見直しが行われている。
o  重要なことは、これらの動きが、同時多発的に進
行していることだと思う。これらの動きは、深いと
ころで、相互に絡み合っている。
o  それは、アプリ開発の枠組みが、全体として、大
きく変わろうとしていることの「予兆」だと、僕は考
えている。

WebプロトコルとHTTPの見直し
o  HTTPは、本来は、文書の転送のためにデザインされたも
ので、URLでリソースを指定して、リクエスト・レスポンスを
交互に繰り返す。
o  データのキャッシュが可能であるというメリットはあるが、
もともと、バイナリーデータを含む、リアルタイムの大量の
データ通信用に設計されたものではない。
o  HTTPは、双方向ではあるが、Request/Responseのそ
れぞれの時点を取れば、データの流れは一方向で、半二
重の通信プロトコルである。
o  また、HTTPは、状態を持たないので、ヘッダーの情報は、
リクエストのたびに、再送される必要がある。

HTTPとAJAX
o  HTTPは、リクエストに対するレスポンスが返るま
で、処理がブロックする同期型のプロトコルだが、
実際のAJAXでは、非同期にサーバー・クライアン
ト間で、頻繁にデータのやり取りが発生する。
o  そのため、AJAXでは、サーバーへのPollingや
Long Pollingというあまり自然とは言えない手段
を使って、なんとか、コネクションを維持している。
o  こうしたトリッキーなスタイル自身が、ネットワーク
のトラフィックを増大させ、AJAXが切り開いてきた
ユーザー・エクスペリエンスの反応の良さに、むし
ろ、反対の作用を及ぼしている。

「AJAXは、HTTPの可能性を、最後の
血の一滴まで、搾り取った。」
o  これ以上のHTTPの使い回しは限界に近づいて
いる。もし、あるWebアプリの反応が良くないとし
たら、ネットワークが遅いことが原因の一つになっ
ている可能性は高い。
o  現在のAJAXが主役の第三世代のStructured
Webから、次世代のReal-Time, Responsive
Webの世代に移行する上で、HTTPの見直し自
体が求められている。
o  この問題では、SPDY, WebSocket, Server
Sent Event, SignalR等々、いくつかの提案が
なされている。

サーバーとクライアントの役割の見直し
o  サーバーに負荷が集中するのは、ある意味、当
然のことである。なぜなら、ネットワーク上のサー
ビスは、ほとんど全て、一つのサーバーが、沢山
のクライアントのリクエストに応えることで成り立っ
ているからである。
o  ただ、以前は、サーバーに利用されるマシンとク
ライアントのPCのハードウェアの性能差は歴然と
していた。サーバー・マシンは、PCの数十倍から
数百倍の性能とメモリー/ディスクを持っていた。

クライアントの能力の飛躍的拡大
o  ただ、今日では、状況は違っている。サーバー・マ
シンに使われるCPUは、ほとんどの場合、上位機
種のPCと同じものである。
o  重要なことは、こうしたことは、サーバーの能力が
低下したということではなく、私たちが手にしてい
るクライアントの能力が、飛躍的に向上したことを
意味しているということである。

クラウドは、速いか？
o  クラウドは、高価で特殊なマシンではなく、PCと同
じレベルのコモディティ化したマシンを、大量に集
積したものである。
o  IaaS型のクラウドでは、多くのサービスで、マル
チコアのCPUの一つ一つのコアを仮想化して、ク
ラウドのノードの最小単位として公開している。
o  こうした場合、もっともチープなクラウド上のサー
バーの能力は、CPUのコアを全部使っているクラ
イアントPCの能力より、低いものになる。

Webアプリサーバーの
最も重い仕事は、HTMLデータの生成
o  サーバー・サイド・プログラミングのWebアプリで
は、Webアプリ・サーバーは、アプリの中核であ
るビジネス・ロジックの実行はもちろんだが、デー
タベースの管理等、沢山の仕事をこなさなければ
ならない。
o  ただ、その中で最大のもの、70%以上をしめるの
は、クライアントに送るHTMLデータの生成である。

クライアントの負荷は、
相対的には、軽い
o  一方、クライアントの側は、潜在的には高い能力
を持ちながら、サーバーから送られてくるHTML
のデータをレンダリングすることだけが、主要な仕
事になる。
o  相対的には同程度のパワーしか持たないサー
バーとクライアントでは、明らかに、要求される仕
事は、サーバーの方が重く、クライアントの方が
軽いものになる。

サーバーとクライアントの
不均衡の解消
o  Webアプリのサーバー側では、多数のクライアン
トからのサービス要求に、どのように応えようとし
ているのか？　
o  サーバーとクライアントに要求される仕事量に不
均衡があることを前提とする限りは、本質的には、
うまい解決策はない。

WebアプリのScale-outの手法
o  現在行われている解は、基本的には、一台だけのサー
バーで対応が難しいのなら、対応するサーバーの数を増
やそうということである。
o  WebアプリのクライアントからのRequestは、システムの
前面に置かれたLoad Balancerで、同じWeb層、同じビ
ジネス・ロジック層をもつ、複数のWebアプリ・サーバーの
レプリカに分配される。
o  こうしたWebアプリのScale outの手法は、サーバー・サ
イド・プログラミングの3-Tier Modelの登場とともに実装
され、10年以上の長い歴史を持っている。そうしたアーク
テクチャーは、現在のクラウドにも引き継がれている。

サーバーの負荷を軽くする試み
Thin Server Architecture
o  ただ、サーバーの負荷の集中による応答の悪さ
を解決しようとするなら、別のアプローチも必要に
なってくると思う。今まさに、そういう模索が始まっ
ている。
o  僕が注目しているのは、サーバー側の負担を軽
減して、クライアント側に可能な処理を移していこ
うという、Thin Server Architectureと呼ばれ
るものである。基本的には、アプリのプレゼンテー
ション層を、クライアントに移そうという試みである。

開発言語の見直し
o  “Write Once, Run Everywhere”というのは、
かつてのJavaのスローガンだった。
o  ただ、Webの標準技術に基づくWebアプリの登
場とその普及は、Javaだけでなく、.NET系の言
語だろうが、PHP, Python, Rubyだろうが、どの
ような言語で開発されようが、“Write Once,
Run Everywhere”なアプリを作成することを可
能にした。
o  アプリの機能を、開発言語の束縛から解放したこ
と、これはWebアプリの大きな功績である。

Webアプリは、開発言語の
多様化を生み出した
o  もちろん、それは、どんなOS、どんなハードウェア
の上でも走るアプリの開発が可能になったことを
意味しているだけで、アプリの開発には、特定の
開発言語が必要だということには、何の変わりも
ない。
o  むしろ、Webアプリは、開発言語の多様化を生み
出したと言っていいのかもしれない。

Webアプリ開発の
標準言語としてのJavaScript
o  Webアプリの開発言語の多様化の一方で、重要な変化
が進行する。かつては、HTMLのscriptタグの内部に、
ひっそりと存在していただけのJavaScriptが、第三世代
のStructure Webの時代には、AJAXの手法の主要な
担い手として、スポットライトを浴びるようになる。
o  jQueryを初めとして、数十ものJavaScriptライブラリー
が登場し、どのような開発言語を選んだとしても、多くの
Webアプリの開発では、JavaScriptのコーディングが必
要になってきている。JavaScriptは、事実上のWebアプ
リの開発の標準言語になっている。
o  ResponsiveなWebアプリを作ろうと思ったら、なおさら、
JavaScriptの知識は、必須になる。

クラウド・デバイスの多様化の進行は
標準言語への指向を高める
o  いまや、PCに代わってクライアントの標準になろ
うとしている、スマートフォンやタブレットといったク
ラウド・デバイスの普及は、クラウド・デバイス上
のWebアプリ開発のニーズを、今まで以上に高
めている。
o  ただ、クラウド・デバイスのベンダー毎の多様化の
進行は、アプリの開発者を、ベンダーの特定の開
発言語に縛り付けている。全く同じ機能のアプリ
を開発するのに、クラウド・デバイスのベンダーと
機種に応じて、開発環境を変えないといけないと
いうのは、あまり合理的でも経済的でもない。

マルチ・スクリーン環境での
ユーザーの意識の変化
o  一方で、ユーザーは、PCだけではなく、スマート
フォンやタブレットといった複数のクラウド・デバイ
スを所有するようになってきている。この流れは、
テレビやゲーム機がクラウド・デバイス化すること
によって、さらに大きなものになるだろう。
o  こうしたマルチ・デバイス、マルチ・スクリーン環境
では、ユーザーは、同じ機能のアプリが、いつでも、
どこでも、どんなデバイスの上でも動くことを望む
ようになる。そうしたニーズは、ベンダー毎に分断
された開発環境のもとでは、開発者側の負担を
増大させるだけである。

Lingua Francaとしての
JavaScript
o  こうした中で、本当の意味での“Write Once,
Run Everywhere”を実現する言語、Lingua
Francaへの期待が高まっている。そのもっとも有
力な候補は、JavaScriptに他ならない。
o  おそらく、今後の言語のイノベーションの中心は、
JavaScriptを舞台に展開されることになる。ここ
でも、様々な模索が行われている。

WebプロトコルとHTTPの見直し

SPDY：　HTTP自体の高速化の取り組み
WebSocket：　HTTPの置き換え

SPDYとWebSocket
o  ここで取り上げるのは、
SPDY（「スピーディー」と読む）と
http://dev.chromium.org/spdy
WebSocket
http://www.w3.org/TR/websockets/
の二つである。
o  両方とも、HTTPの見直しの動きだが、一方の
SPDYは、HTTPプロトコル自体の高速化を目指
し、他方のWebSocketは、HTTPそのものを、他
のプロトコルで置き換えようと試みである。

その他の注目すべき動き
o  本当は、このテーマでは、数年前にはSOAの担
い手として最も注目されていた、Webサービス/
SOAPが影響力を落とし、RESTのスタイルが主
流になってきているという重要な変化がある。
o  また、プロトコルの見直しでも、サーバーからの
Push技術、Server Sent Event
http://dev.w3.org/html5/eventsource/
や、マイクロソフトのSignalR　
https://github.com/SignalR/SignalR/wiki
といった技術があるのだが、これらについては、
今回は、割愛する。

AndroidのChrome対応は重要
o  残念なことに、Androidの開発者にとっては、
SPDYもWebSocketも、これまでのAndroidの
標準のブラウザーがこれらの技術には対応して
いなかったので、チェックすることは出来なかった
のだが、状況は、変わりつつある。
o  Android4.0から、Android上でChromeが走る
ようになった。NEXUS 7では、初めてChromeが
Androidのデフォールトのブラウザーになった。
Googleは、来年から、最新のChromeを
Androidに対応させるという。これは、非常に重
要な変化だ。

SPDY　--- HTTPの高速化
o  SPDYは、HTTP自体の高速化の取り組みなので、
SPDYを話すサーバーとSPDYを理解するブラウ
ザーさえあれば、SPDYを使うのに、既存のWeb
アプリを変更する必要は全くない。
o  事実、僕らがほとんど気付かないうち、Googleの
サービスとTwitterは、既に、SPDYを使っている。
また、ChromeやFireFoxは、SPDYに対応して
いる。

o  SPDYは、Webアプリ開発者からみると、ほとん
どHTTPと同じと考えていいのだが、正確に言うと、
ネットワークのレイヤーが違う。
o  HTTPはアプリケーション層で、SPDYはセッショ
ン層のプロトコルである。セッション層のSPDYは、
プレゼンテーション層SSLの上に構築されている。
o  SSLは、対応するアプリケーション層のプロトコル
で言うと、HTTPSだと思ってもらっていい。

o  セッション層のSPDYは、その上に、既存のHTTP
のsemanticsをそっくりまねて、アプリケーション
層として新しくHTTPを再構成する。
o  正確に言うと、SPDYといわれているものは、
SPDYの上に再構築されたHTTPのことである。
o  ただ、HTTPという同じ顔をしているので、Webア
プリもその開発者も、インターネット上のルーター
もプロキシーも、自分がハンドルしているのは
HTTPだと信じ込んでしまうことになる。
o  それは、SPDYの大きなメリットなのだが、その同
じ顔の下で実装されているのは、それまでの
HTTPとは違うものである。

SPDYが行っていること
o  SPDYは、下位のSSL（＝TLS）層で、バイナ
リーのフレーム転送プロトコルを持つ。
o  SPDYは、一つのコネクション上で、複数の
HTTPコネクションを同時にはることが出来る。
o  Headerの圧縮。
o  サーバーからのPush

SPDYの到達点と今後
o  SPDYは、HTTPのスピードを倍にすることを目標
にしている。現在の達成は、その半分、25%程
度の高速化だと言われている。
n  “Not as SPDY as You Thought”　
o  http://www.guypo.com/technical/not-as-spdy-
as-you-thought
o  http://d.hatena.ne.jp/vwxyz/
20120628/1340873192

o  SPDYは、現在策定中のHTTP 2.0 の有力候補
のひとつだといわれている。

WebSocket --- HTTPの置き換え
o  WebSocketは、Webのコミュニケーションの網
の目を大きく改善する、Web上で、全二重の
Socketを提供するW3C、IETFで標準化された
プロトコルである。
o  ファイアウォール、プロキシー、ルーターをシーム
レスに通過し、既存のHTTP上のコンテンツと、
ポートを共有する。
o  TLSを使って、セキュアな通信が可能である。
o  Cross-Origin Resource Sharingが可能であ
る。

WebSocketで、Webが
Half DuplexからFull Duplexに

WebSocketの考え方
o  WebSocketのアプローチは、基本的には、Web
上のネットワークのプロトコルは、何もHTTP中心
に限ることはないだろうという考え方。Webでも、
もっと積極的に、TCP/IPのSocketを使おうとい
うこと。
o  こうしたアプローチは、特に、ネットワーク・プログ
ラミングを複雑にし、ネットワークのリソースを過
剰に消費している、AJAXでの非同期の通信には、
非常に効果的。

通常の汎用のSocketプログラミングと
WebSocketとの違い
o  通常のSocketプログラミングとWebSocketは、
次の点で異なっている。

1.  WebSocketによる通信は、クライアントとサー
バーとのやり取りによって開始されるのだが、そ
の最初の交渉には、HTTPが使われる。
2.  WebSocketが想定しているクライアントは、ネッ
トワーク上の任意のノードではなくて、Webブラウ
ザーである。

WebSocketのハンドシェーク
　--クライアントからのリクエスト
必須
GET /chat HTTP/1.1
HOST: server.example.com WebSocketに
Upgrade: websocket
Connection: Upgrade Upgrade
オプション
出来ますか?
Sec-Websocket-Key: 16-byte nonce, BASE64 encoded
Sec-Websocket-Version: 6
Sec-Websocket-Origin: http://example.com
Sec-Websocket-Protocol: protocol [, protokol]*
Sec-Websocket-Extension: extension [, extension]
Cookie: Cookie content & other cookie related headers

WebSocketのハンドシェーク 
　--サーバからのレスポンス
必須
HTTP/1.1 101　 WebSocketに
Upgrade: websocket 切り替えますね。
Connection: Upgrade
Sec-Websocket-Accept: 20-bytes MDS hash in Base64

オプション
Sec-Websocket-Protocol: protocol
Sec-Websocket-Extension: extention [,extension]*

WebSocket　実装の状況
o  現在、ほとんど全ての言語、ほとんど全てのWeb
アプリの開発フレームワーク、ほとんど全ての
Webブラウザーで、WebSocketへの対応は行
われている。
o  まず、AJAXでのデータ転送あたりから通信の
WebSocket化は、急速に進むと思う。エンター
プライズも、積極的に取り組んでいる。
o  環境は出来ている。あとは、それを、我々が利用
するだけ。

WebSocket　代表的なサーバー
o  WebSocket対応のサーバーを二つほど紹介
したい。是非、お試しを。

o  Jetty （Java）
http://www.eclipse.org/jetty/
o  Node.js + socket.io.js (JavaScript)
http://nodejs.org/ socket.io
http://socket.io/

WebSocketの課題
o  WebSocketの一つの問題は、WebSocketを開
いて渡されるTCP/IPのソケットが、低レイヤーの
もので、自由度が高すぎることである。
o  本格的な応用を考えたら、通信プロトコルの設計
から始める必要がある。「サブ・プロトコル問題」と
いわれることがあるようだ。
o  でも、それでは、開発者の負荷を考えたら、サバ・
クラ時代への逆戻りにもなりかねない。この点で
も、面白い探求も行われているようだ。

役割の見直し

p Meteor
p Avatar

役割の見直しの一般的な背景
1.  ハードの性能が、特にクライアント側で飛躍的に
向上したこと。クラウド・デバイスは、PCより、はる
かにリッチなクライアントである。
2.  サーバーの負荷の増大
3.  ネットワーク・トラフィックの増大
4.  プログラムとViewの分離の難しさ
n  全てがサーバー側でコントロールされ、特に、両者が
密に絡み合っているようなWebアプリでは、どちらの
変更も、開発の工程に大きなインパクトを与える可能
性がある。
n  プログラマはデザインの変更を嫌い、デザイナーは、
プログラムの変更を嫌う。

クラウド・デバイス側の状況
1.  クラウド・デバイスの普及に伴って、どんなデバイ
スでも動くアプリへのニーズが、市場に生まれて
きている
2.  クラウド・デバイスのアプリでも、ネットワークに接
続するアプリが確実に増え始めている
3.  こうして、クラウド・デバイスのアプリ側では、「ア
プリをWebアプリ化する」ことが、重要な選択肢
の一つとして浮かび上がってきている。
o  基本的には、それは、HTML5への期待として、
「アプリを、HTML5を利用して、Webアプリ化す
る」という展望として定式化出来ると思う。

奇妙な状況・混乱
o  サーバー側では、HTTPを含んだWebアプリの見
直しの動きが起きている、その時に、クライアント
側では、Webアプリへの期待が高まっている。

o  冒頭でふれた、アプリへのHTML5の導入に熱心
だったFacebookが、一転して、それを「最大の誤
り」として、ネーティブの開発に転換したのも、現
在の混沌とした状況を表している。

o  Thin Server Architecture というのは、2008
年の初め頃に、Mario Valenteを中心とするグ
ループが考えだしたコンセプト。
o  残念ながら、発表当時は、大きな反響を起こすこ
ともなく、忘れられていた。今また、こうした数年前
のコンセプトに照明があたると言うのも、興味深い
ことである。

https://sites.google.com/a/
thinserverarchitecture.com/home/Home

Thin Server Architectureの定義

Thin Server Architecture(TSA)は、今日
のWebアプリケーション・フレームワークの、
慢心と複雑さに対する、反応である。
TSAは、全てのプレゼンテーション層のロジッ
クを、サーバーから、クライアント（Webブラウ
ザー）上の、JavaScript（あるいは他）のロ
ジックに移し変えることを提案する。
これによって、次の三つのポジティブなことが
得られる。

Thin Server Architectureの定義
1.  サーバー側の開発者は、ビジネス・ロジックに
集中出来る。
2.  クライアントが分離して開発されるので、アプ
リケーションは、より複雑でなくなる。
3.  サーバーとクライアントの通信は、データを他
方の、あるいは将来のシステムとの間のデー
タのインポート、エクスポート、あるいは表現
に利用可能な、プロトコルを利用する。

Thin Server Architectureの図式
クライアント
サーバー

Meteor
o  この点で、僕が、最近興味をもったWebアプリの
開発フレームワークに、Meteorがある。
o  何よりもMeteorでは、Webアプリの開発は、す
べてクライアント側だけで可能になる。
o  これまで、Webアプリの開発は、すべてサーバー
側で行われてきた。Webアプリの開発をすべてク
ライアントで行うというMeteorのアプローチは、
サーバーとクライアントの役割については、丁度、
正反対のものである。
http://meteor.com/
https://github.com/meteor/meteor

Meteorの開発スタイル
o  もちろん、Meteorはクライアントに閉じたアプリで
はなく、きちんとしたWebアプリを作り出す。
o  Meteorは、Full JavaScriptの開発フレーム
ワークで、サーバーには、Node.jsを利用。
o  サーバー側のコードを記述する必要は、ほとんど
ない。クライアント側で作成する一つのコードの中
に、簡単に、サーバーとクライアントのコードを同
時に記述出来る
o  Webアプリ・サーバーとのかかわりは、基本的に
は、Meteorが生成したアプリを、サーバーに
deployするだけ。

Thin Server Architectureとしての
Meteor
o  Meteorは、クライアント側に、MVC(のようなも
の)を持っている。この点でも、サーバーとクライ
アントの役割については、従来とは反対のThin
Server Architectureである。
o  ネットワークを隔てたサーバーの介在無しで、クラ
イアントが、Viewを直接操作出来ることは、この
アーキテクチャーの大きな利点。頻繁に発生する、
AJAXイベントも、ネットワークをまたぐことなく、ク
ライアント内部で処理が可能となる。
o  こうして、Real-Time, ResponsiveなWebアプ
リの作成が可能になる。

Meteorのデータ層の扱い
o  Meteorは、データ層 Modelの扱いでも大きな特
徴を持っている。
o  Meteorは、ローカルなシステム自体に、デフォー
ルトでmini-MongoDBを内蔵しているのだが、こ
のDBは、ローカルなサーバーに置かれても、リ
モートのサーバー上に置かれても、Meteorのシ
ステムからは、全く同じように見えます。

Re-Activeプログラミング
o  より、強力なのは、Meteorでは、データベースの
項目が変更されると、自動的に、そのデータ項目
に関連した関数は、全て再計算される。
o  少なくないケースでは、それはViewの変更を引
き起こす。プログラマが、ModelとViewを仲立ち
するControllerで、そうした処理を記述する必要
はない。Modelの変更は、ただちにViewに反映
される。このことは、プログラマの仕事を大いに助
ける。 cf. Excel
o  こうしたスタイルを、Re-Activeプログラミングと
呼ぶ。

Meteorアプリケーションの構造
o  Meteorアプリケーションは、クライアントのWeb
ブラウザの内部で走るJavaScriptと、Node.js
コンテナーの内部のMeteorサーバー上で走る
JavaScript、それにサポートされている全ての
HTMLフラグメントとCSSルール、静的なアセット
から構成される。
o  Meteorは、これらの異なるコンポーネントのパッ
ケージングと連携を自動化する。ファイル・ツリー
の中で、これらのコンポーネントに、どのような構
造を選ぶかについては、Meteorは、極めて柔軟
である。

Meteor Data and security

以下は、Meteorのドキュメントの
一部の抄訳である。

In Memory DB Cache
o  全てのMeteorクライアントは、イン・メモリーの
データベース・キャッシュを持っている。
o  このクライアントのキャッシュを管理する為に、
サーバーは、JSONドキュメントの集合を
publishし、クライアントは、これらの集合に
subscribeする。
o  集合内のドキュメントが変化すると、サーバーは、
それぞれのクライアントのキャッシュを変更する。

publish function
o  それぞれのドキュメントの集合は、サーバー上の
publish関数によって定義される。
o  publish関数は、新しいクライアントが、ドキュメン
トの集合に対してsubscribeするたびに、実行さ
れる。
o  ドキュメントの集合の中のデータは、どこから来て
もいいのだが、一般的な場合は、データベースの
クエリーをpublishすることである。

// server: publish all room documents
Meteor.publish("all-rooms", function () {
return Rooms.find(); // everything
);
// server: publish all messages for a given room
Meteor.publish("messages", function (roomId) {
return Messages.find({room: roomId});
});

// server: publish the set of parties the logged-in user can see.
Meteor.publish("parties", function () {
return Parties.find({$or: [{"public": true},
{invited: this.userId},
{owner: this.userId}]});
});

subscribe
o  いったんsubscribeされると、クライアントは、そ
のキャッシュを高速なローカル・データベースとし
て利用するので、劇的に、クライアントのコードは、
単純化される。
o  Readは、サーバーへの高価な回り道を、要求さ
れることはない。そして、それらは、そのキャッ
シュの内容に限られている。クライアント上の集
合中のドキュメント全てに対するクエリーは、サー
バーがクライアントにpublishしたドキュメントを返
すのみである。

// client: start a parties subscription
Meteor.subscribe("parties");

// client: return array of Parties this client can read
return Parties.find().fetch(); // synchronous!

allow/deny rule
o  クライアントが、いくつかのドキュメントを変更した
時、クライアントはサーバーに、その変更を要求
するメッセージを送る。
o  サーバーは、提案された変更を、JavaScriptの
関数で書かれたallow/denyルールに照らして
チェックする。
o  サーバーは、全てのルールをパスした変更のみ
を受け入れる。

// server: don't allow client to insert a party
Parties.allow({
insert: function (userId, party) {
return false;
}
});

// client: this will fail
var party = { ... };
Parties.insert(party);

データの更新と伝搬
o  サーバーが変更を受け付けると、サーバーは、
データベースにその変更を適用して、影響を受け
たドキュメントにsubscribeしていた他のクライア
ントに、その変更を、自動的に伝搬する。
o  もし、受け付けなかったら、更新は失敗する。サー
バーのデータベースは、変わらないまま残り、他
のクライアントは、誰も、更新を見ることはない。

データの更新と伝搬
o  Meteorは、キュートなトリックも使う。クライアント
がサーバーに対して書き込みをしようとした時、
サーバーの返答を待つこと無しに、ローカル
キャッシュをただちに書き換える。このことは、ス
クリーンは、ただちに再描画されることを意味する。
o  もし、サーバーが更新を受け付けた時、これは、
クライアントが正しく動作している時には、大部分
の時間は、そうなるべきなのであるが、クライアン
トは、変化にただちにジャンプして、スクリーンを
更新するのに、サーバーへの回り道を待つ必要
がない。

Reactive Programming
o  Meteorは、reactive programmingのコンセ
プトを擁護する。このことは、コードを単純な命令
スタイルで書くことを可能にし、その結果は、コー
ドに従って、データが変更された時にはいつでも、
自動的に再計算されることを意味する。

reactive context
o  この自動的な再計算は、Sessionと
Meteor.autosubscribeの協調によって達成される。
o  Meteor.autosubscribeのようなメソッドは、”reactive
context”を確立する。そのコンテキストの中で、データの
従属性が追跡され、必要な時に、関数の引数を再実行す
るように準備している。
o  SessionのようなData providerは、それに対して、そ
れらが呼び出されたコンテキストと、どのようなデータが要
求されているかを意識して、データが変更された時、
invalidationシグナルを送るように準備している。

reactive context +
reactive data source
o  この reactive context + reactive data
source という単純なパターンは、広い応用可能
性をもっている。
o  それ以上に、プログラマーは、 unsubscribe/
resubscribe の呼び出しのコードを書く手間が
省け、それらは、正しい時に確実に呼び出されこ
とになる
o  一般的に、Meteorは、そうでなければ、誤りを犯
しやすいロジックで、アプリケーションの邪魔にな
る、データ伝搬の全てのクラスを取り除くことが出
来る、

reactive-context
o  次のMeteor関数は、コードを、reactive-
contextで走らせる。
n  Templates
n  Meteor.render and Meteor.renderList
n  Meteor.autosubscribe
n  Meteor.autorun

reactive data sources
o  変更をトリガーできる、reactive data sources
には、次のようなものがある。
n  Session variables
n  Database queries on Collections
n  Meteor.status
n  Meteor.user
n  Meteor.userId
n  Meteor.userLoaded

LiveHTML
o  HTML templating は、Webアプリの中心であ
る。Meteorのライブ・ページ更新技術で、HTML
を、reactiveにレンダー出来る。それは、ページ
を生成するのに利用されたデータの変化を追跡し
て、自動的に更新が行われることを意味する。
o  この特徴は、全てのHTMLテンプレート・ライブラ
リーで機能し、手で書かれたJavaScriptで生成
されたHTMLでも機能する。

LiveHTMLの例

var fragment = Meteor.render(
function () {
var name = Session.get("name") || "Anonymous";
return "<div>Hello, " + name + "</div>";
});
document.body.appendChild(fragment);

Session.set(“name”, “Bob”); // ページは自動的に更新される

Meteor.render()
o  Meteor.render は、rendering function、あるHTML
を文字列として返すを関数を引数に取る。それは、自動更
新するDocumentFragmentを返す。
o  rendering functionで利用されたデータに変更があった
とき、それは、再実行される。DocumentFragment 内
のDOMノードは、ページのどの場所に挿入されていても、
その場で自分自身を更新する。それは全く自動的である。
o  Meteor.renderは、rendering functionによって、どの
データが利用されたかを発見する為にreactive context
を使う。

<head>
<title>Advanced Template Demo</title>
</head>
<body>
{{> page}}
</body>

<template name="page">
<h1>Advanced Template Demo</h1>
<p>
This demo shows off the advanced features of Meteor's optional
</p>

{{> preserveDemo }}
{{> constantDemo }}
{{> stateDemo }}
{{> d3Demo }}
</template>

<template name="preserveDemo">
<h2>Element preservation</h2>

<input type="button" value="X++" class="x”>
...
</template>

<template name="constantDemo">
<h2>Constant regions</h2>

<div>
<input type="button" value="X++" class="x"> <br>
<input type="checkbox" class="remove" which="1" {{checked 1}}>
Remove map 1<br>
<input type="checkbox" class="remove" which="2" {{checked 2}}>
Remove map 2
</div>
...

<template name="hello">
<div class="greeting">Hello there, {{first}} {{last}}!</div>
</template>

// in the JavaScript console
> Template.hello({first: "Alyssa", last: "Hacker"});
=> "<div class="greeting">Hello there, Alyssa Hacker!</div>"

Meteor.render(function () {
return Template.hello({first: "Alyssa", last: "Hacker"});
})
=> automatically updating DOM elements

データベースへのクエリー
<template name="players">
{{#each topScorers}}
<div>{{name}}</div>
{{/each}}
</template>

Template.players.topScorers = function () {
return Users.find({score: {$gt: 100}}, {sort: {score: -1}});
};

// in a JavaScript file
Template.players.leagueIs = function (league) {
return this.league === league;
};

<template name="players">
{{#each topScorers}}
{{#if leagueIs "junior"}}
<div>Junior: {{name}}</div>
{{/if}}
{{#if leagueIs "senior"}}
<div>Senior: {{name}}</div>
{{/if}}
{{/each}}
</template>

// Works fine with {{#each sections}}
Template.report.sections = ["Situation", "Complication", "Resolution"];

<template name="scores">
{{#each player}}
{{> playerScore}}
{{/each}}
</template>
<template name="playerScore">
<div>{{name}}: {{score}}
<span class="givePoints">Give points</span>
</div>
</template>

Template.playerScore.events({
'click .givePoints': function () {
Users.update({_id: this._id}, {$inc: {score: 2}});
}
});

<head>
<title>Leaderboard</title>
</head>

<body>
<div id="outer">
{{> leaderboard}}
</div>
</body>

<template name="leaderboard">
<div class="leaderboard">
{{#each players}}
{{> player}}
{{/each}}
</div>

{{#if selected_name}}
<div class="details">
<div class="name">{{selected_name}}</div>
<input type="button" class="inc" value="Give 5 points" />
</div>
{{/if}}

{{#unless selected_name}}
<div class="none">Click a player to select</div>
{{/unless}}
</template>

<template name="player">
<div class="player {{selected}}">
<span class="name">{{name}}</span>
<span class="score">{{score}}</span>
</div>
</template>

Players = new Meteor.Collection("players");
.......
if (Meteor.isServer) {
Meteor.startup(function () {
if (Players.find().count() === 0) {
var names = ["Ada Lovelace",
"Grace Hopper",
"Marie Curie",
"Carl Friedrich Gauss",
"Nikola Tesla",
"Claude Shannon"];
for (var i = 0; i < names.length; i++)
Players.insert({name: names[i],
　　　　　　　　　　　　　　　　score: Math.floor(Math.random()*10)*5});
}
});
}

Players = new Meteor.Collection("players");

if (Meteor.isClient) {
Template.leaderboard.players = function () {
return Players.find({}, {sort: {score: -1, name: 1}});
};

Template.leaderboard.selected_name = function () {
var player = Players.findOne(Session.get("selected_player"));
return player && player.name;
};

Template.player.selected = function () {
return Session.equals("selected_player", this._id) ? "selected" : '';
}

Template.leaderboard.events({
'click input.inc': function () {
Players.update(
Session.get("selected_player"), {$inc: {score: 5}});
}
});

Template.player.events({
'click': function () {
Session.set("selected_player", this._id);
}
});
}

Project Avatar
o  Avatar は、今年のJavaOneで発表された
(正確に言うと、去年も予告はあった)、Thin
Server Architectureを導入したOracleの
実験的なプロジェクトである。

n  JavaOne 2012 (CON7042)
Building HTML5 Web Apps with Avatar
o  Santiago Pericas-Geertsen
o  Torkel Dominique
o  Sumathi Gopalakrishnan

なぜ、Avatarなのか？
o  ブラウザーとサーバーのViewは、これまでと同じ
く、HTML/JSで結ばれているのだが、ブラウザー
のModelは、サーバー側のServiceとJSONで結
ばれている。
o  これは、僕の想像だが、Avatarというプロジェクト
名は、このブラウー上のModelが、サーバー上の
データのAvatarだと言うことではないかと思って
いる。サーバー上のAvatar Serviceは、ブラウ
ザー上に、Avatarを作り出す。

Avatar クライアント
o  Avatarのクライアントは、UI NodesとModelsと
Controllerから、構成される。
o  UI Nodesは、Page, Form, Input, Table,
Container, Menu, Button等からなる。
o  Modelsは、Local, Rest, Push, Socketからな
る。

Avatar サーバー
o  Avatarのサーバーは、Data Providerと
Servicesから、構成される。
o  このData Providerは、Avatar Serviceの中核
である。File, DataBase, Coherence等の永続
化サービスから構成される。Avatarは、JPA-RS
とも呼ばれていた。
o  Servicesは、クライアントのModelに対応して、
Rest, Push, Socketからなる。

Avatar の開発言語
o  Avatarは、Javaのフレームワークとは言えない。
JavaEEのクラウド化とは、全く異なるものである。
o  クライアントは、全て、JavaScriptで記述する。
o  Back-Endで、Javaのサービスを利用出来るの
は当然だが、サーバー側も、JavaScriptで全て
記述出来る。

Avatarのプログラミング・スタイル
o  Avatarのプログラミング・スタイルは、かなり奇妙
である。XMLの中にJavaScriptやHTMLが埋め
込まれている。この例では、クライアント側の
Model=LocalModelとView=Pageの定義が見
える。

AvatarのData Binding
o  先のコードで、<a:localModel ...>
<a:Page ... > のaは、AvatarのName
Space である。
o  Avatarの最大の特徴は、クライアント上の
Modelだが、localModelの他に、Data
Bindingの種類に応じて、restModel,
pushModel, socketModel等がある。
o  もちろん、restModelはRESTに、pushModelは
Server Side Eventに、socketModelは
WebSocketに対応している。サンプルのコード
をあげよう。これは、socketModelの例。

ModelとServiceの対応
o  クライアントの restModel, pushModel,
socketModelに対応して、サーバー側では、
restService, pushService, socketService
が定義される。

「アプリ開発の新しい動向」
中間のまとめ

Webアプリについて
o  Webアプリが登場して10年以上たつ。AJAX の
登場からも５年以上たつ。
o  Webアプリは、いろいろなところで息切れが始
まって、いろいろな見直しが始まっている。そろそ
ろ、次のモデルが登場する時期に近づいている。
o  Webの世界は、Real-Time, Responsiveな
Webに変わろうとしている。アプリも、その流れに
追従するだろう。
o  変化を牽引しているのは、クラウド・デバイス。
PCの時代は終わりつつある。

クラウド・デバイスの
Webアプリ化について
o  現在、Webアプリのスタイルが変わりつつ転換点
にあるという認識が必要。
o  クラウド・デバイスのWebアプリ化は、開発者とシ
ステムにとって万能でも、ユーザにとって最良の
選択肢とは限らない。
o  少なくとも、現在のWebアプリの枠組みをそのま
まにして、HTMLをHTML5に変えただけでは。
Facebookが直面した問題は、そこにある。

Thin Server Architectureについて
o  Webアプリに代わる、あるいは、Webアプリの新
しい段階の候補としては、Thin Server
Architectureが有力である。
o  そこでは、アプリのプレゼンテーション層をクライ
アント側に置くことで、現在のWebアプリの抱える
多くの問題が解決される可能性がある。
o  ただ、大きな枠組みの見直しなので、エンタープラ
イズ含めたその受容には、一定の時間が必要に
なるだろう。
o  同時に、データベースを中心に、様々な技術の見
直しの連鎖反応が起きてくると思う。

再び、
Thin Server Architectureについて
o  ただ、注意してほしいのは、Thin Server
Architectureは、現在では孤立しているが、未
来では成長するアーキテクチャーなどではないと
いうことである。
o  それは、気の利いたWeb業界の人や、マルチ・ス
クリーンのクラウド・デバイスの開発プラットフォー
ムを作っている人、ネットワーク・ゲームの開発者
にとっては、よく知られているし、既に、広く利用さ
れているものである。
o  それは、すでに、そこにある。

あらためて、Facebookの選択について
o  事実として重要なことは、ネットにつながる、クラ
ウド・デバイスのネイティブ・アプリは、Webアプリ
形式ではなく、ほとんど、プレゼンテーション層を
ネイティブに自前で持つTSAの形態をとっている
ということである。
o  HTML5について、”because it just wasn’t
there”といった、Zuckerburgの発言は、Web
アプリ/HTML5指向からの後退ではあるが、むし
ろ、現状でのクラウド・デバイスでのWebアプリ形
態の限界と、TSAの有効性を示すものだと考えた
方がいい。

過渡期としての現在
HTML5とJavaScriptの未来
o  サーバー・サイドで進行しているWebアプリの枠
組みの見直しも、クラウド・デバイス側で現在の主
流である、ネイティブ言語でのTSAの実装も、い
ずれも、過渡的なものである。
o  いずれ、おそらくは、TSAを中心として、新しいア
プリ開発の統一的な枠組みが、登場して来る。
o  少なくとも、クラウド・デバイス側で、その中心的な
役割を担うのは、HTML5 とJavaScriptであるこ
とは、ほぼ間違いないと感じている。
o  HTML5とJavaScriptは、これからますます重要
になるということ。開発者は、それに対する準備を。

エンタープライズ・システムの変化
o  こうした流れの中で、エンタープライズのシステム
がどう変化するのか予測するのは、コンシューマ
やデバイス側の変化予測より、難しい。
o  というか、Webアプリに事実上特化した、アプリ
ケーション・サーバーと開発ツール群を擁する、エ
ンタープライズのプレーヤの変化の予測が難しい。
o  ただ、サーバーは、HTMLのレンダリングではなく、
サービスの提供に集中すべきだというのは、正し
いと思う。その意味では、SOAは重要である。
o  結局は、サーバーのサービスの受け取り手が、ク
ラウド・デバイスに変わっていくことで決着がつく。

開発言語の見直し

12月17日のクラウド研究会へつづく。
申し込みは、
http://kokucheese.com/event/
index/64071/

１２月１７日　クラウド研究会
o  日時
　　2012年12月17日(午後19時開始)
o  開催場所
日本マイクロソフト社　品川本社　Seminar
Room A
(東京都港区港南 2-16-3 品川グランドセン
トラルタワー)
o  参加費
無料

o  定員
150人(先着順)

クラウド研究会の告知から
o  「今回のクラウド研究会は、Webアプリ開発の
新しい動向という点では、内容的に、前回のク
ラウド研究会と連続するものです。今回は、こ
うした動きを主導しているのが、開発言語のレ
ベルでいうと、JavaScriptであり、
JavaScriptの適用範囲の拡大とその機能強
化が、今後のWebアプりの開発に、大きな影
響を与えるであろうという観点から、セッション
を構成しました。ご期待ください。」

丸山の講演　「JavaScriptの進化」
o  JavaScriptでは、jQuery.jsをはじめとして、Node.js,
Backbone.js, Redis.jsといったライブラリー・レベルの
機能拡大が活発に行われています。それと同時に、重要
な動きとして、JavaScript言語自体の拡張の模索が、い
ろいろな形で行われています。
o  講演では、JavaScriptのMulti-core対応の高
速化の試みとしての、IntelのRiverTrail、
JavaScriptでの大規模開発を展望した、
JavaScriptへの静的型付けの導入の試みとして
の、GoogleのDart、同じく、Microsoftの
TypeScriptを紹介したいと思います。

アプリ開発の

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (20)

Similar a アプリ開発の

Similar a アプリ開発の (20)

Más de maruyama097

Más de maruyama097 (6)

アプリ開発の