More Related Content More from maruyama097 (6) アプリ開発の4. 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に、あまりに賭けすぎたことだと思う。
5. 「スマートフォンのアプリを、HTML5で
Webアプリ化する」というビジョン
o 開発の現場ではiOSとAndroidの両方のアプリを作って
いるところは多く、同じアプリを、わざわざ、Objective-C
とJavaの二つの言語で開発するのに苦労しているところ
は少なくない。その上、Androidの場合には、機種ごと
OSのバージョンごとに違いが大きいという問題もある。
o PC上のWebの世界がそうであるように、ハードの違い、
OSの違いに関係なく、誰でも、ほぼ同じコンテンツを楽し
めるようにスマートフォンのアプリを作れればと、多くの開
発者は考えていると思う。
o HTML5の表現力と新しい機能が、スマートフォン
上のWebアプリを、ネーティブ・アプリと同等以上
のものにするだろうという展望は、魅力的なもの
7. 1. 開発ツール / 開発者用のAPI
o モバイル・ブラウザーのツールが欠如している
ことが、実際の問題がなんであるかを掘り下
げ、発見することを非常に難しくしている。ツー
ルあるいはそれらの欠如が、本質的な問題で
ある。
o メモリー問題では、 FPS
p
n Heap size, n ハードウェア・レベルで
n Object count, fpsを計測する能力
n GC cycles,
n GPU buffer size,
n resource limits.
8. 2. スクロールのパフォーマンス
o これは、我々の最も重要な問題の一つである。
ニュースフィードやタイムラインを無限スクロール
する時(ユーザーがアプリを下向きにスクロール
する際、コンテンツは先読みされ、追加される)、
あるいは、膨大な量のコンテンツ(テキストと画像
の両方)を逆向きに読む時、典型的に問題になる。
o 現在は、我々は、スクロールは全てJavaScript
を利用して行っている。その他の選択肢では、(実
装上の問題で)十分な速さが得られないので。
9. o QoI Issues
n 一定しないフレームレート
n GPUバッファーの枯渇
n ネイティブ実装も、OS毎に違う印象を与える
n Androidのタッチイベントのパフォーマンスの問題
o Requirements
n ...
n ...
o new API suggestions
n ...
10. 3. GPU
o 現時点では、GPUはブラックボックスである。
(ベンダーが、そうしようと思ったつくりになって
いるということ)
o しかしながら、実際には、開発者は、与えられ
たコンテンツを、無理にでもハードウェアで高
速化する為に、そうしたトリックを利用せざるを
得ない。
o 今日のコンテンツが消費するサイズと、GPU
バッファーのサイズのギャップ。
11. 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は、我々には重要なものだ。
15. 第一世代 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登場。
同年、インターネットの最初の爆発が起きる。
17. サバ・クラ・モデルとWebアプリ
o Webアプリ登場以前の、エンタープライズのネット
ワーク・アプリは、いわゆる、「サバ・クラ・モデル」
で、アプリの開発者は、サーバー側とクライアント
側の二つのプログラムを作る必要があったばかり
か、サーバーとクライアントを結ぶネットワークの
プロトコルを設計し、そのプロトコル上で運ばれる
データの形式を考える必要があった。
o Webアプリは、プロトコルをHTTP、データの形式
をHTML、クライアント・プログラムをWebブラウ
ザーに固定することによって、ネットワーク・アプリ
の開発を飛躍的に容易にした。
20. クラウドも、基本は、Webアプリ
o 現在のクラウドも、クラウド上のシステムの設計者
から見れば、ScalabilityやAvailabilityは補強
されているのだが、そのアーキテクチャーは、基
本的には、サーバー・サイドのWebアプリのエン
ジンに他ならない。
o このように、Webアプリのアーキテクチャーとその
アイデアは、今日も、強力な影響力を持っている。
o クラウド・デバイスの開発者達が、こうした歴史的
な成功を、自分たちのフィールドにも持ち込もうと
するのは、ある意味、当然のことである。
21. 第三世代 Structured Web
o 現在のWebの世代を特徴付けるのは、もはや、
残念ながらWebアプリに代表される、Dynamic
Webではない。その変化は、むしろ、エンタープラ
イズのシステムの中からではなく、コンシューマ向
けのシステムから生まれてきた。
o 先行するものは、20世紀末からあるのだが、
Webの新しい世代を画期付けたのは、何と言っ
ても、AJAXの登場であった。この言葉が出てくる
のは、2005年頃、その時の主役は、やはり、
Googleだった。
22. それまでのWebアプリの制限
o それまでのWebアプリでは、ブラウザーの表示に
対する人間の入力は、HTTPのRequestに乗せ
られてサーバーに送られ、サーバーがそれに対
する処理をおこなって、新しい表示画面を
Responseとして返す。
o サーバーの処理が終わるまで、人間は、だまって
待っていなければならない。第二世代のWebア
プリというのは、こうしたHTTPのRequest/
Responseの繰り返しなのである。
23. AJAXの特徴
o AJAXは、それに対して、ブラウザー上の人間の
アクション、例えば、マウス・ポインタの移動とかマ
ウスのドラッグといったイベントを全て捕まえて、
ページのRequest/Responseのサイクルを待つ
こと無しに、非同期にシステムに送りつける。シス
テムは、また、非同期にそれに対する処理を、ブ
ラウザーに返す。
24. AJAXの実装 構造化されたDOM
o AJAXのシステムは、もはや、第二世代のWebア
プリのように、テキストで表現されたHTMLを操作
の対象にしていない。AJAXのシステムでは、
HTML/CSSの情報は、その構造に即して、メモ
リー上に構造化されたDOMとして展開される。
o システムは非同期にそれぞれのDOMにアクセス
して、その内容を動的に書き換えることが出来ま
る。ブラウザーは、変更されたDOMの内容を、た
だちに表示する。DOMへのアクセス、内容の変
更に、主にJavaScriptが使われることも、AJAX
の大きな特徴の一つになる。
26. インタラクティブなアプリとしての
Webアプリ
o 先に、Webアプリの特徴として、「人間がブラウ
ザーの前にいることを想定した、インタラクティブ
なアプリ」という特徴を与えた。
o こうした観点は、それぞれの世代の個々の要素
技術の相違にもかかわらず、Static Webから、
Dynamic Webへ、Dynamic Webから
Structured Webへの発展を、統一的に捉える
ことを可能にする。
o 同時に、こうした見方は、Web技術の更なる発展
を予想するものである。
27. 第四世代
Real-Time Responsive Webへ
o Webの世界は、今や、次の世代に変化しようとし
ている。それは、人間に取って、より直感的で使
いやすいものへの進化を求められている。
o 第四世代のWebは、Real-Time, Responsive
Webと呼ばれることが多い。その意味、それに対
する期待は、名前を見れば明らかだと思う。
o 私たちは、現在、この新しいWebの世界の入り口
にたっている。
29. クラウド・デバイスの、飛躍的な拡大
o 新規の出荷台数ベースで見ると、こうしたクラウ
ド・デバイスの数は、2012年で、Windowsや
MacといったPCの数を上回っている。
o かつては、インターネットに接続するにはPCが必
須だった。また、Webアプリがターゲットにしてい
たクライアントはPCだけだった。
o PCの普及がインターネットの普及を支え、エン
タープライズでのPC利用の拡大が、Webアプリと
いうアークテクチャを生み出したのだが、いま、PC
の時代は、終わろうとしている。
38. ネットワークのリソースに、
大きな負担をかけるAJAX
o 現在のWebの主流であるAJAXも、トラフィックの
増大に拍車をかけている。ブラウザー上で何かの
イベントが起きるたびに、クライアント・サーバー
間で、頻繁にトラフィックが発生する。
o HTTPは状態を持たないので、データの送信のた
びに、HEADERの情報は繰り返し送られる。
o また、サーバーからクライアントへデータを送る通
信路を確保する為に、クライアントは、定期的に
サーバーをpollingしたり、あるいは、一度つくら
れたコネクションを、長期にわたって維持しようと
試みる(Long Polling)。
40. クラウド・デバイス固有の問題
Signaling Burst
o 普通のプロセスを休眠させるだけならいいのだが、
ネットワークのプロセスが休止するとコネクション
は切断されてしまう。結局、プロセスが休眠から
覚めるとき、コネクションの回復の為に、あらため
て電話網との制御信号のやり取りが必要になる。
o ユーザーが気がつかないうちに、あるいはプログ
ラマーが意識しないままに、デバイス上では、コネ
クションの切断・回復が繰り返され、時によっては、
ネットワークを流れる本来のデータより、制御信
号のトラフィックの方が多くなるということが起きる。
Signaling Burstという現象である。
41. 最新のWeb技術に接する人の増大。
o 日本では、これまでガラ携しか使ったことのない
人が、大量に、スマートフォンのユーザーになって
いる。世界中では、初めて持った携帯電話がス
マートフォンだと言う人は、何千万人の単位で存
在する。
o こうした人たちに、現在のWebの技術は、どのよ
うに見えているのだろうか? また、逆に、スマー
トフォンを、既に何台か買い替えている人たちは、
最新のデバイスに対して、どのような期待を持っ
ているのだろうか?
42. UIとUXの改善は、最重要の課題
o クラウド・デバイスの利用者達の、グローバルな
かつてないほどの規模拡大ということは、世界人
口の大多数にとって、最新のテクノロジーに触れ
る条件が整い始めているということである。
o そこで何よりも必要とされていることは、IT技術に
対する知識を前提とはせずとも、誰にとっても直
感的で分かりやすいユーザー・インターフェースと、
誰にとっても快適なユーザー体験を提供すること
である。
44. Real-Time, Responsive Webへ
o ただ、人間の欲求が無限だからかも知れないの
が、我々は、必ずしも、現在の我々の経験に満足
している訳ではない。
o 我々は、もっと快適で反応のいい技術を求めてい
る。来るべきWebの世代が、Real-Time,
Responsive Webと呼ばれているのは、とても
示唆に富んでいると思う。
46. 変化の予兆
o アプリ開発の今後の変化について三つのトレンド
を紹介する。それは、様々な角度から、Webアプ
リの基本的な前提の見直しが行われている。
o 重要なことは、これらの動きが、同時多発的に進
行していることだと思う。これらの動きは、深いと
ころで、相互に絡み合っている。
o それは、アプリ開発の枠組みが、全体として、大
きく変わろうとしていることの「予兆」だと、僕は考
えている。
47. WebプロトコルとHTTPの見直し
o HTTPは、本来は、文書の転送のためにデザインされたも
ので、URLでリソースを指定して、リクエスト・レスポンスを
交互に繰り返す。
o データのキャッシュが可能であるというメリットはあるが、
もともと、バイナリーデータを含む、リアルタイムの大量の
データ通信用に設計されたものではない。
o HTTPは、双方向ではあるが、Request/Responseのそ
れぞれの時点を取れば、データの流れは一方向で、半二
重の通信プロトコルである。
o また、HTTPは、状態を持たないので、ヘッダーの情報は、
リクエストのたびに、再送される必要がある。
48. HTTPとAJAX
o HTTPは、リクエストに対するレスポンスが返るま
で、処理がブロックする同期型のプロトコルだが、
実際のAJAXでは、非同期にサーバー・クライアン
ト間で、頻繁にデータのやり取りが発生する。
o そのため、AJAXでは、サーバーへのPollingや
Long Pollingというあまり自然とは言えない手段
を使って、なんとか、コネクションを維持している。
o こうしたトリッキーなスタイル自身が、ネットワーク
のトラフィックを増大させ、AJAXが切り開いてきた
ユーザー・エクスペリエンスの反応の良さに、むし
ろ、反対の作用を及ぼしている。
50. サーバーとクライアントの役割の見直し
o サーバーに負荷が集中するのは、ある意味、当
然のことである。なぜなら、ネットワーク上のサー
ビスは、ほとんど全て、一つのサーバーが、沢山
のクライアントのリクエストに応えることで成り立っ
ているからである。
o ただ、以前は、サーバーに利用されるマシンとク
ライアントのPCのハードウェアの性能差は歴然と
していた。サーバー・マシンは、PCの数十倍から
数百倍の性能とメモリー/ディスクを持っていた。
52. クラウドは、速いか?
o クラウドは、高価で特殊なマシンではなく、PCと同
じレベルのコモディティ化したマシンを、大量に集
積したものである。
o IaaS型のクラウドでは、多くのサービスで、マル
チコアのCPUの一つ一つのコアを仮想化して、ク
ラウドのノードの最小単位として公開している。
o こうした場合、もっともチープなクラウド上のサー
バーの能力は、CPUのコアを全部使っているクラ
イアントPCの能力より、低いものになる。
56. WebアプリのScale-outの手法
o 現在行われている解は、基本的には、一台だけのサー
バーで対応が難しいのなら、対応するサーバーの数を増
やそうということである。
o WebアプリのクライアントからのRequestは、システムの
前面に置かれたLoad Balancerで、同じWeb層、同じビ
ジネス・ロジック層をもつ、複数のWebアプリ・サーバーの
レプリカに分配される。
o こうしたWebアプリのScale outの手法は、サーバー・サ
イド・プログラミングの3-Tier Modelの登場とともに実装
され、10年以上の長い歴史を持っている。そうしたアーク
テクチャーは、現在のクラウドにも引き継がれている。
57. サーバーの負荷を軽くする試み
Thin Server Architecture
o ただ、サーバーの負荷の集中による応答の悪さ
を解決しようとするなら、別のアプローチも必要に
なってくると思う。今まさに、そういう模索が始まっ
ている。
o 僕が注目しているのは、サーバー側の負担を軽
減して、クライアント側に可能な処理を移していこ
うという、Thin Server Architectureと呼ばれ
るものである。基本的には、アプリのプレゼンテー
ション層を、クライアントに移そうという試みである。
58. 開発言語の見直し
o “Write Once, Run Everywhere”というのは、
かつてのJavaのスローガンだった。
o ただ、Webの標準技術に基づくWebアプリの登
場とその普及は、Javaだけでなく、.NET系の言
語だろうが、PHP, Python, Rubyだろうが、どの
ような言語で開発されようが、“Write Once,
Run Everywhere”なアプリを作成することを可
能にした。
o アプリの機能を、開発言語の束縛から解放したこ
と、これはWebアプリの大きな功績である。
60. Webアプリ開発の
標準言語としてのJavaScript
o Webアプリの開発言語の多様化の一方で、重要な変化
が進行する。かつては、HTMLのscriptタグの内部に、
ひっそりと存在していただけのJavaScriptが、第三世代
のStructure Webの時代には、AJAXの手法の主要な
担い手として、スポットライトを浴びるようになる。
o jQueryを初めとして、数十ものJavaScriptライブラリー
が登場し、どのような開発言語を選んだとしても、多くの
Webアプリの開発では、JavaScriptのコーディングが必
要になってきている。JavaScriptは、事実上のWebアプ
リの開発の標準言語になっている。
o ResponsiveなWebアプリを作ろうと思ったら、なおさら、
JavaScriptの知識は、必須になる。
62. マルチ・スクリーン環境での
ユーザーの意識の変化
o 一方で、ユーザーは、PCだけではなく、スマート
フォンやタブレットといった複数のクラウド・デバイ
スを所有するようになってきている。この流れは、
テレビやゲーム機がクラウド・デバイス化すること
によって、さらに大きなものになるだろう。
o こうしたマルチ・デバイス、マルチ・スクリーン環境
では、ユーザーは、同じ機能のアプリが、いつでも、
どこでも、どんなデバイスの上でも動くことを望む
ようになる。そうしたニーズは、ベンダー毎に分断
された開発環境のもとでは、開発者側の負担を
増大させるだけである。
65. SPDYとWebSocket
o ここで取り上げるのは、
SPDY(「スピーディー」と読む)と
http://dev.chromium.org/spdy
WebSocket
http://www.w3.org/TR/websockets/
の二つである。
o 両方とも、HTTPの見直しの動きだが、一方の
SPDYは、HTTPプロトコル自体の高速化を目指
し、他方のWebSocketは、HTTPそのものを、他
のプロトコルで置き換えようと試みである。
66. その他の注目すべき動き
o 本当は、このテーマでは、数年前にはSOAの担
い手として最も注目されていた、Webサービス/
SOAPが影響力を落とし、RESTのスタイルが主
流になってきているという重要な変化がある。
o また、プロトコルの見直しでも、サーバーからの
Push技術、Server Sent Event
http://dev.w3.org/html5/eventsource/
や、マイクロソフトのSignalR
https://github.com/SignalR/SignalR/wiki
といった技術があるのだが、これらについては、
今回は、割愛する。
67. AndroidのChrome対応は重要
o 残念なことに、Androidの開発者にとっては、
SPDYもWebSocketも、これまでのAndroidの
標準のブラウザーがこれらの技術には対応して
いなかったので、チェックすることは出来なかった
のだが、状況は、変わりつつある。
o Android4.0から、Android上でChromeが走る
ようになった。NEXUS 7では、初めてChromeが
Androidのデフォールトのブラウザーになった。
Googleは、来年から、最新のChromeを
Androidに対応させるという。これは、非常に重
要な変化だ。
69. o SPDYは、Webアプリ開発者からみると、ほとん
どHTTPと同じと考えていいのだが、正確に言うと、
ネットワークのレイヤーが違う。
o HTTPはアプリケーション層で、SPDYはセッショ
ン層のプロトコルである。セッション層のSPDYは、
プレゼンテーション層SSLの上に構築されている。
o SSLは、対応するアプリケーション層のプロトコル
で言うと、HTTPSだと思ってもらっていい。
70. o セッション層のSPDYは、その上に、既存のHTTP
のsemanticsをそっくりまねて、アプリケーション
層として新しくHTTPを再構成する。
o 正確に言うと、SPDYといわれているものは、
SPDYの上に再構築されたHTTPのことである。
o ただ、HTTPという同じ顔をしているので、Webア
プリもその開発者も、インターネット上のルーター
もプロキシーも、自分がハンドルしているのは
HTTPだと信じ込んでしまうことになる。
o それは、SPDYの大きなメリットなのだが、その同
じ顔の下で実装されているのは、それまでの
HTTPとは違うものである。
75. 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 の有力候補
のひとつだといわれている。
76. WebSocket --- HTTPの置き換え
o WebSocketは、Webのコミュニケーションの網
の目を大きく改善する、Web上で、全二重の
Socketを提供するW3C、IETFで標準化された
プロトコルである。
o ファイアウォール、プロキシー、ルーターをシーム
レスに通過し、既存のHTTP上のコンテンツと、
ポートを共有する。
o TLSを使って、セキュアな通信が可能である。
o Cross-Origin Resource Sharingが可能であ
る。
78. WebSocketの考え方
o WebSocketのアプローチは、基本的には、Web
上のネットワークのプロトコルは、何もHTTP中心
に限ることはないだろうという考え方。Webでも、
もっと積極的に、TCP/IPのSocketを使おうとい
うこと。
o こうしたアプローチは、特に、ネットワーク・プログ
ラミングを複雑にし、ネットワークのリソースを過
剰に消費している、AJAXでの非同期の通信には、
非常に効果的。
81. 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
82. 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]*
85. WebSocketの課題
o WebSocketの一つの問題は、WebSocketを開
いて渡されるTCP/IPのソケットが、低レイヤーの
もので、自由度が高すぎることである。
o 本格的な応用を考えたら、通信プロトコルの設計
から始める必要がある。「サブ・プロトコル問題」と
いわれることがあるようだ。
o でも、それでは、開発者の負荷を考えたら、サバ・
クラ時代への逆戻りにもなりかねない。この点で
も、面白い探求も行われているようだ。
87. サーバーとクライアントの
役割の見直しの一般的な背景
1. ハードの性能が、特にクライアント側で飛躍的に
向上したこと。クラウド・デバイスは、PCより、はる
かにリッチなクライアントである。
2. サーバーの負荷の増大
3. ネットワーク・トラフィックの増大
4. プログラムとViewの分離の難しさ
n 全てがサーバー側でコントロールされ、特に、両者が
密に絡み合っているようなWebアプリでは、どちらの
変更も、開発の工程に大きなインパクトを与える可能
性がある。
n プログラマはデザインの変更を嫌い、デザイナーは、
プログラムの変更を嫌う。
88. クラウド・デバイス側の状況
1. クラウド・デバイスの普及に伴って、どんなデバイ
スでも動くアプリへのニーズが、市場に生まれて
きている
2. クラウド・デバイスのアプリでも、ネットワークに接
続するアプリが確実に増え始めている
3. こうして、クラウド・デバイスのアプリ側では、「ア
プリをWebアプリ化する」ことが、重要な選択肢
の一つとして浮かび上がってきている。
o 基本的には、それは、HTML5への期待として、
「アプリを、HTML5を利用して、Webアプリ化す
る」という展望として定式化出来ると思う。
89. 奇妙な状況・混乱
o サーバー側では、HTTPを含んだWebアプリの見
直しの動きが起きている、その時に、クライアント
側では、Webアプリへの期待が高まっている。
o 冒頭でふれた、アプリへのHTML5の導入に熱心
だったFacebookが、一転して、それを「最大の誤
り」として、ネーティブの開発に転換したのも、現
在の混沌とした状況を表している。
90. Thin Server Architecture
o Thin Server Architecture というのは、2008
年の初め頃に、Mario Valenteを中心とするグ
ループが考えだしたコンセプト。
o 残念ながら、発表当時は、大きな反響を起こすこ
ともなく、忘れられていた。今また、こうした数年前
のコンセプトに照明があたると言うのも、興味深い
ことである。
https://sites.google.com/a/
thinserverarchitecture.com/home/Home
91. Thin Server Architectureの定義
Thin Server Architecture(TSA)は、今日
のWebアプリケーション・フレームワークの、
慢心と複雑さに対する、反応である。
TSAは、全てのプレゼンテーション層のロジッ
クを、サーバーから、クライアント(Webブラウ
ザー)上の、JavaScript(あるいは他)のロ
ジックに移し変えることを提案する。
これによって、次の三つのポジティブなことが
得られる。
92. Thin Server Architectureの定義
1. サーバー側の開発者は、ビジネス・ロジックに
集中出来る。
2. クライアントが分離して開発されるので、アプ
リケーションは、より複雑でなくなる。
3. サーバーとクライアントの通信は、データを他
方の、あるいは将来のシステムとの間のデー
タのインポート、エクスポート、あるいは表現
に利用可能な、プロトコルを利用する。
95. Meteor
o この点で、僕が、最近興味をもったWebアプリの
開発フレームワークに、Meteorがある。
o 何よりもMeteorでは、Webアプリの開発は、す
べてクライアント側だけで可能になる。
o これまで、Webアプリの開発は、すべてサーバー
側で行われてきた。Webアプリの開発をすべてク
ライアントで行うというMeteorのアプローチは、
サーバーとクライアントの役割については、丁度、
正反対のものである。
http://meteor.com/
https://github.com/meteor/meteor
96. Meteorの開発スタイル
o もちろん、Meteorはクライアントに閉じたアプリで
はなく、きちんとしたWebアプリを作り出す。
o Meteorは、Full JavaScriptの開発フレーム
ワークで、サーバーには、Node.jsを利用。
o サーバー側のコードを記述する必要は、ほとんど
ない。クライアント側で作成する一つのコードの中
に、簡単に、サーバーとクライアントのコードを同
時に記述出来る
o Webアプリ・サーバーとのかかわりは、基本的に
は、Meteorが生成したアプリを、サーバーに
deployするだけ。
97. Thin Server Architectureとしての
Meteor
o Meteorは、クライアント側に、MVC(のようなも
の)を持っている。この点でも、サーバーとクライ
アントの役割については、従来とは反対のThin
Server Architectureである。
o ネットワークを隔てたサーバーの介在無しで、クラ
イアントが、Viewを直接操作出来ることは、この
アーキテクチャーの大きな利点。頻繁に発生する、
AJAXイベントも、ネットワークをまたぐことなく、ク
ライアント内部で処理が可能となる。
o こうして、Real-Time, ResponsiveなWebアプ
リの作成が可能になる。
99. Re-Activeプログラミング
o より、強力なのは、Meteorでは、データベースの
項目が変更されると、自動的に、そのデータ項目
に関連した関数は、全て再計算される。
o 少なくないケースでは、それはViewの変更を引
き起こす。プログラマが、ModelとViewを仲立ち
するControllerで、そうした処理を記述する必要
はない。Modelの変更は、ただちにViewに反映
される。このことは、プログラマの仕事を大いに助
ける。 cf. Excel
o こうしたスタイルを、Re-Activeプログラミングと
呼ぶ。
100. Meteorアプリケーションの構造
o Meteorアプリケーションは、クライアントのWeb
ブラウザの内部で走るJavaScriptと、Node.js
コンテナーの内部のMeteorサーバー上で走る
JavaScript、それにサポートされている全ての
HTMLフラグメントとCSSルール、静的なアセット
から構成される。
o Meteorは、これらの異なるコンポーネントのパッ
ケージングと連携を自動化する。ファイル・ツリー
の中で、これらのコンポーネントに、どのような構
造を選ぶかについては、Meteorは、極めて柔軟
である。
102. In Memory DB Cache
o 全てのMeteorクライアントは、イン・メモリーの
データベース・キャッシュを持っている。
o このクライアントのキャッシュを管理する為に、
サーバーは、JSONドキュメントの集合を
publishし、クライアントは、これらの集合に
subscribeする。
o 集合内のドキュメントが変化すると、サーバーは、
それぞれのクライアントのキャッシュを変更する。
104. // 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}]});
});
105. subscribe
o いったんsubscribeされると、クライアントは、そ
のキャッシュを高速なローカル・データベースとし
て利用するので、劇的に、クライアントのコードは、
単純化される。
o Readは、サーバーへの高価な回り道を、要求さ
れることはない。 そして、それらは、そのキャッ
シュの内容に限られている。クライアント上の集
合中のドキュメント全てに対するクエリーは、サー
バーがクライアントにpublishしたドキュメントを返
すのみである。
106. // client: start a parties subscription
Meteor.subscribe("parties");
// client: return array of Parties this client can read
return Parties.find().fetch(); // synchronous!
108. // 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);
109. データの更新と伝搬
o サーバーが変更を受け付けると、サーバーは、
データベースにその変更を適用して、影響を受け
たドキュメントにsubscribeしていた他のクライア
ントに、その変更を、自動的に伝搬する。
o もし、受け付けなかったら、更新は失敗する。サー
バーのデータベースは、変わらないまま残り、他
のクライアントは、誰も、更新を見ることはない。
110. データの更新と伝搬
o Meteorは、キュートなトリックも使う。クライアント
がサーバーに対して書き込みをしようとした時、
サーバーの返答を待つこと無しに、ローカル
キャッシュをただちに書き換える。このことは、ス
クリーンは、ただちに再描画されることを意味する。
o もし、サーバーが更新を受け付けた時、これは 、
クライアントが正しく動作している時には、大部分
の時間は、そうなるべきなのであるが、クライアン
トは、変化にただちにジャンプして、スクリーンを
更新するのに、サーバーへの回り道を待つ必要
がない。
113. reactive context
o この自動的な再計算は、Sessionと
Meteor.autosubscribeの協調によって達成される。
o Meteor.autosubscribeのようなメソッドは、”reactive
context”を確立する。そのコンテキストの中で、データの
従属性が追跡され、必要な時に、関数の引数を再実行す
るように準備している。
o SessionのようなData providerは、それに対して、 そ
れらが呼び出されたコンテキストと、どのようなデータが要
求されているかを意識して、データが変更された時、
invalidationシグナルを送るように準備している。
114. reactive context +
reactive data source
o この reactive context + reactive data
source という単純なパターンは、広い応用可能
性をもっている。
o それ以上に、プログラマーは、 unsubscribe/
resubscribe の呼び出しのコードを書く手間が
省け、それらは、正しい時に確実に呼び出されこ
とになる
o 一般的に、Meteorは、そうでなければ、誤りを犯
しやすいロジックで、アプリケーションの邪魔にな
る、データ伝搬の全てのクラスを取り除くことが出
来る、
116. 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
118. LiveHTML
o HTML templating は、Webアプリの中心であ
る。Meteorのライブ・ページ更新技術で、HTML
を、reactiveにレンダー出来る。それは、ページ
を生成するのに利用されたデータの変化を追跡し
て、自動的に更新が行われることを意味する。
o この特徴は、全てのHTMLテンプレート・ライブラ
リーで機能し、手で書かれたJavaScriptで生成
されたHTMLでも機能する。
119. 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”); // ページは自動的に更新される
120. Meteor.render()
o Meteor.render は、rendering function、あるHTML
を文字列として返すを関数を引数に取る。それは、自動更
新するDocumentFragmentを返す。
o rendering functionで利用されたデータに変更があった
とき、それは、再実行される。DocumentFragment 内
のDOMノードは、ページのどの場所に挿入されていても、
その場で自分自身を更新する。それは全く自動的である。
o Meteor.renderは、rendering functionによって、どの
データが利用されたかを発見する為にreactive context
を使う。
122. <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>
123. <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>
...
124. <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
125. データベースへのクエリー
<template name="players">
{{#each topScorers}}
<div>{{name}}</div>
{{/each}}
</template>
Template.players.topScorers = function () {
return Users.find({score: {$gt: 100}}, {sort: {score: -1}});
};
126. // 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>
127. // 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}});
}
});
130. {{#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>
131. 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});
}
});
}
132. 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" : '';
}
133. 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);
}
});
}
134. 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);
}
});
}
135. 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);
}
});
}
137. 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
140. なぜ、Avatarなのか?
o ブラウザーとサーバーのViewは、これまでと同じ
く、HTML/JSで結ばれているのだが、ブラウザー
のModelは、サーバー側のServiceとJSONで結
ばれている。
o これは、僕の想像だが、Avatarというプロジェクト
名は、このブラウー上のModelが、サーバー上の
データのAvatarだと言うことではないかと思って
いる。サーバー上のAvatar Serviceは、ブラウ
ザー上に、Avatarを作り出す。
141. Avatar クライアント
o Avatarのクライアントは、UI NodesとModelsと
Controllerから、構成される。
o UI Nodesは、Page, Form, Input, Table,
Container, Menu, Button等からなる。
o Modelsは、Local, Rest, Push, Socketからな
る。
143. Avatar サーバー
o Avatarのサーバーは、Data Providerと
Servicesから、構成される。
o このData Providerは、Avatar Serviceの中核
である。File, DataBase, Coherence等の永続
化サービスから構成される。Avatarは、JPA-RS
とも呼ばれていた。
o Servicesは、クライアントのModelに対応して、
Rest, Push, Socketからなる。
149. 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の例。
153. Webアプリについて
o Webアプリが登場して10年以上たつ。AJAX の
登場からも5年以上たつ。
o Webアプリは、いろいろなところで息切れが始
まって、いろいろな見直しが始まっている。そろそ
ろ、次のモデルが登場する時期に近づいている。
o Webの世界は、Real-Time, Responsiveな
Webに変わろうとしている。アプリも、その流れに
追従するだろう。
o 変化を牽引しているのは、クラウド・デバイス。
PCの時代は終わりつつある。
155. Thin Server Architectureについて
o Webアプリに代わる、あるいは、Webアプリの新
しい段階の候補としては、Thin Server
Architectureが有力である。
o そこでは、アプリのプレゼンテーション層をクライ
アント側に置くことで、現在のWebアプリの抱える
多くの問題が解決される可能性がある。
o ただ、大きな枠組みの見直しなので、エンタープラ
イズ含めたその受容には、一定の時間が必要に
なるだろう。
o 同時に、データベースを中心に、様々な技術の見
直しの連鎖反応が起きてくると思う。
156. 再び、
Thin Server Architectureについて
o ただ、注意してほしいのは、Thin Server
Architectureは、現在では孤立しているが、未
来では成長するアーキテクチャーなどではないと
いうことである。
o それは、気の利いたWeb業界の人や、マルチ・ス
クリーンのクラウド・デバイスの開発プラットフォー
ムを作っている人、ネットワーク・ゲームの開発者
にとっては、よく知られているし、既に、広く利用さ
れているものである。
o それは、すでに、そこにある。
157. あらためて、Facebookの選択について
o 事実として重要なことは、ネットにつながる、クラ
ウド・デバイスのネイティブ・アプリは、Webアプリ
形式ではなく、ほとんど、プレゼンテーション層を
ネイティブに自前で持つTSAの形態をとっている
ということである。
o HTML5について、”because it just wasn’t
there”といった、Zuckerburgの発言は、Web
アプリ/HTML5指向からの後退ではあるが、むし
ろ、現状でのクラウド・デバイスでのWebアプリ形
態の限界と、TSAの有効性を示すものだと考えた
方がいい。
158. 過渡期としての現在
HTML5とJavaScriptの未来
o サーバー・サイドで進行しているWebアプリの枠
組みの見直しも、クラウド・デバイス側で現在の主
流である、ネイティブ言語でのTSAの実装も、い
ずれも、過渡的なものである。
o いずれ、おそらくは、TSAを中心として、新しいア
プリ開発の統一的な枠組みが、登場して来る。
o 少なくとも、クラウド・デバイス側で、その中心的な
役割を担うのは、HTML5 とJavaScriptであるこ
とは、ほぼ間違いないと感じている。
o HTML5とJavaScriptは、これからますます重要
になるということ。開発者は、それに対する準備を。
159. エンタープライズ・システムの変化
o こうした流れの中で、エンタープライズのシステム
がどう変化するのか予測するのは、コンシューマ
やデバイス側の変化予測より、難しい。
o というか、Webアプリに事実上特化した、アプリ
ケーション・サーバーと開発ツール群を擁する、エ
ンタープライズのプレーヤの変化の予測が難しい。
o ただ、サーバーは、HTMLのレンダリングではなく、
サービスの提供に集中すべきだというのは、正し
いと思う。その意味では、SOAは重要である。
o 結局は、サーバーのサービスの受け取り手が、ク
ラウド・デバイスに変わっていくことで決着がつく。
162. クラウド研究会の告知から
o 「今回のクラウド研究会は、Webアプリ開発の
新しい動向という点では、内容的に、前回のク
ラウド研究会と連続するものです。今回は、こ
うした動きを主導しているのが、開発言語のレ
ベルでいうと、JavaScriptであり、
JavaScriptの適用範囲の拡大とその機能強
化が、今後のWebアプりの開発に、大きな影
響を与えるであろうという観点から、セッション
を構成しました。ご期待ください。」
163. 丸山の講演 「JavaScriptの進化」
o JavaScriptでは、jQuery.jsをはじめとして、Node.js,
Backbone.js, Redis.jsといったライブラリー・レベルの
機能拡大が活発に行われています。それと同時に、重要
な動きとして、JavaScript言語自体の拡張の模索が、い
ろいろな形で行われています。
o 講演では、JavaScriptのMulti-core対応の高
速化の試みとしての、IntelのRiverTrail、
JavaScriptでの大規模開発を展望した、
JavaScriptへの静的型付けの導入の試みとして
の、GoogleのDart、同じく、Microsoftの
TypeScriptを紹介したいと思います。