アプリ開発の

4,992 views

Published on

アプリ開発の

  1. 1. アプリ開発の新しい動向 @maruyama097 丸山不二夫
  2. 2. Agenda o  Facebookの選択の波紋o  「Webアプリ」とは何か?o  Webの世代についてo  Webを取り巻く環境の変化o  変化の三つの方向o  WebプロトコルとHTTPの見直しo  サーバーとクライアントの役割の見直しo  開発言語の見直し
  3. 3. Facebookの選択の波紋
  4. 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. 5. 「スマートフォンのアプリを、HTML5でWebアプリ化する」というビジョン o  開発の現場ではiOSとAndroidの両方のアプリを作って いるところは多く、同じアプリを、わざわざ、Objective-C とJavaの二つの言語で開発するのに苦労しているところ は少なくない。その上、Androidの場合には、機種ごと OSのバージョンごとに違いが大きいという問題もある。 o  PC上のWebの世界がそうであるように、ハードの違い、 OSの違いに関係なく、誰でも、ほぼ同じコンテンツを楽し めるようにスマートフォンのアプリを作れればと、多くの開 発者は考えていると思う。o  HTML5の表現力と新しい機能が、スマートフォン 上のWebアプリを、ネーティブ・アプリと同等以上 のものにするだろうという展望は、魅力的なもの
  6. 6. 「何が、モバイルFacebookを遅くしたのか」              9月15日 o  W3Cのメーリングリスト public-coremob@ w3.orgへの、Facebookの技術者Tobie Langel 氏の投稿。”Perf Feedback - Whats slowing down Mobile Facebook”o  どういう理由で、FacebookがiOS向けのアプリを、 ネイティブ中心に作りかえたかの理由を、モバイル Webの作成中に遭遇したパフォーマンスの問題を 詳しく報告している。
  7. 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. 8. 2. スクロールのパフォーマンスo  これは、我々の最も重要な問題の一つである。 ニュースフィードやタイムラインを無限スクロール する時(ユーザーがアプリを下向きにスクロール する際、コンテンツは先読みされ、追加される)、 あるいは、膨大な量のコンテンツ(テキストと画像 の両方)を逆向きに読む時、典型的に問題になる。o  現在は、我々は、スクロールは全てJavaScript を利用して行っている。その他の選択肢では、(実 装上の問題で)十分な速さが得られないので。
  9. 9. o  QoI Issues n  一定しないフレームレート n  GPUバッファーの枯渇 n  ネイティブ実装も、OS毎に違う印象を与える n  Androidのタッチイベントのパフォーマンスの問題o  Requirements n  ... n  ...o  new API suggestions n  ...
  10. 10. 3. GPU o  現時点では、GPUはブラックボックスである。 (ベンダーが、そうしようと思ったつくりになって いるということ) o  しかしながら、実際には、開発者は、与えられ たコンテンツを、無理にでもハードウェアで高 速化する為に、そうしたトリックを利用せざるを 得ない。o  今日のコンテンツが消費するサイズと、GPU バッファーのサイズのギャップ。
  11. 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は、我々には重要なものだ。
  12. 12. 「Webアプリ」とは何か?
  13. 13. Webアプリの特徴 o  クライアントとしてのWebブラウザーの利用o  データ表現に、HTMLを利用。o  通信プロトコルに、HTTPを利用。o  サーバー・サイド・プログラミング。o  人間がブラウザーの前にいることを想定した、 インタラクティブなアプリ。
  14. 14. Webの世代について p  第一世代  Static Web p  第二世代  Dynamic Web p  第三世代  Structured Web p  第四世代  Real-Time Responsive Web
  15. 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登場。 同年、インターネットの最初の爆発が起きる。
  16. 16. 第二世代  Dynamic Web o  第二世代のWebは、Webアプリの登場とともに 始まる。そこでは、HTMLのページは、サーバー 上のプログラムで、動的に生成されることになる。o  このDynamic Webの登場は、Webの歴史の中 でも、ある意味革命的な変化であった。一方向に 情報を伝えるだけだった「ホームページ」は、イン タラクティブな「アプリケーション」に変わった。
  17. 17. サバ・クラ・モデルとWebアプリ o  Webアプリ登場以前の、エンタープライズのネット ワーク・アプリは、いわゆる、「サバ・クラ・モデル」 で、アプリの開発者は、サーバー側とクライアント 側の二つのプログラムを作る必要があったばかり か、サーバーとクライアントを結ぶネットワークの プロトコルを設計し、そのプロトコル上で運ばれる データの形式を考える必要があった。o  Webアプリは、プロトコルをHTTP、データの形式 をHTML、クライアント・プログラムをWebブラウ ザーに固定することによって、ネットワーク・アプリ の開発を飛躍的に容易にした。
  18. 18. Webアプリによる「配布問題」の解決 o  同時に、Webアプリは、サバクラ型ネットワーク・ アプリの懸案だった、沢山のクライアントのプログ ラムの配布・更新をどのように行うのかという、 「配布問題」を鮮やかに解決した。Webアプリで は、サーバーのプログラムを書き換えるだけで、 アプリケーションは更新される。
  19. 19. エンタープライズ・システムの主流になったWebアプリ o  Webアプリは、こうした優れた特徴によって、エン タープライズ・システムの主流に、またたくまに躍 り上がる。o  20世紀の末から21世紀の初め、ITバブルの頃。 ASP, J2EE, Springといった著名なフレーム ワークが大きな成功を収め、その簡易版である LAMPも、広く受け入れられるようになる。
  20. 20. クラウドも、基本は、Webアプリ o  現在のクラウドも、クラウド上のシステムの設計者 から見れば、ScalabilityやAvailabilityは補強 されているのだが、そのアーキテクチャーは、基 本的には、サーバー・サイドのWebアプリのエン ジンに他ならない。o  このように、Webアプリのアーキテクチャーとその アイデアは、今日も、強力な影響力を持っている。o  クラウド・デバイスの開発者達が、こうした歴史的 な成功を、自分たちのフィールドにも持ち込もうと するのは、ある意味、当然のことである。
  21. 21. 第三世代  Structured Web o  現在のWebの世代を特徴付けるのは、もはや、 残念ながらWebアプリに代表される、Dynamic Webではない。その変化は、むしろ、エンタープラ イズのシステムの中からではなく、コンシューマ向 けのシステムから生まれてきた。 o  先行するものは、20世紀末からあるのだが、 Webの新しい世代を画期付けたのは、何と言っ ても、AJAXの登場であった。この言葉が出てくる のは、2005年頃、その時の主役は、やはり、 Googleだった。
  22. 22. それまでのWebアプリの制限 o  それまでのWebアプリでは、ブラウザーの表示に 対する人間の入力は、HTTPのRequestに乗せ られてサーバーに送られ、サーバーがそれに対 する処理をおこなって、新しい表示画面を Responseとして返す。o  サーバーの処理が終わるまで、人間は、だまって 待っていなければならない。第二世代のWebア プリというのは、こうしたHTTPのRequest/ Responseの繰り返しなのである。
  23. 23. AJAXの特徴 o  AJAXは、それに対して、ブラウザー上の人間の アクション、例えば、マウス・ポインタの移動とかマ ウスのドラッグといったイベントを全て捕まえて、 ページのRequest/Responseのサイクルを待つ こと無しに、非同期にシステムに送りつける。シス テムは、また、非同期にそれに対する処理を、ブ ラウザーに返す。
  24. 24. AJAXの実装 構造化されたDOM o  AJAXのシステムは、もはや、第二世代のWebア プリのように、テキストで表現されたHTMLを操作 の対象にしていない。AJAXのシステムでは、 HTML/CSSの情報は、その構造に即して、メモ リー上に構造化されたDOMとして展開される。o  システムは非同期にそれぞれのDOMにアクセス して、その内容を動的に書き換えることが出来ま る。ブラウザーは、変更されたDOMの内容を、た だちに表示する。DOMへのアクセス、内容の変 更に、主にJavaScriptが使われることも、AJAX の大きな特徴の一つになる。
  25. 25. スマートフォン・アプリの出発点としての、第三世代Web o  こうした第三世代のWebを、構造化されたDOM をハンドルの対象としていることで、Structured Webと呼ぶことがある。o  もしも、スマートフォン・アプリを、Webアプリ化し たいのなら、例えば画面へのタッチや、スワイプ 操作を検出したいのなら、第二世代のWebアプリ では、対応出来ないことは明ら。スマートフォン・ アプリのWebアプリには、この第三世代のWeb 技術が出発点になる。
  26. 26. インタラクティブなアプリとしてのWebアプリ o  先に、Webアプリの特徴として、「人間がブラウ ザーの前にいることを想定した、インタラクティブ なアプリ」という特徴を与えた。o  こうした観点は、それぞれの世代の個々の要素 技術の相違にもかかわらず、Static Webから、 Dynamic Webへ、Dynamic Webから Structured Webへの発展を、統一的に捉える ことを可能にする。o  同時に、こうした見方は、Web技術の更なる発展 を予想するものである。
  27. 27. 第四世代  Real-Time Responsive Webへ o  Webの世界は、今や、次の世代に変化しようとし ている。それは、人間に取って、より直感的で使 いやすいものへの進化を求められている。o  第四世代のWebは、Real-Time, Responsive Webと呼ばれることが多い。その意味、それに対 する期待は、名前を見れば明らかだと思う。o  私たちは、現在、この新しいWebの世界の入り口 にたっている。
  28. 28. Webを取り巻く環境の変化 p  クラウド・デバイスの、飛躍的な拡大。 p  マシンのハードウェア性能の向上。 p  ネットワークの高速化と、それを上回るス ピードでのトラフィックの増大。 p  最新のWeb技術に接する人の増大。
  29. 29. クラウド・デバイスの、飛躍的な拡大 o  新規の出荷台数ベースで見ると、こうしたクラウ ド・デバイスの数は、2012年で、Windowsや MacといったPCの数を上回っている。o  かつては、インターネットに接続するにはPCが必 須だった。また、Webアプリがターゲットにしてい たクライアントはPCだけだった。o  PCの普及がインターネットの普及を支え、エン タープライズでのPC利用の拡大が、Webアプリと いうアークテクチャを生み出したのだが、いま、PC の時代は、終わろうとしている。
  30. 30. Webの世界の主役、Webアプリの主要なターゲットとしてのクラウド・デバイス o  去年までは、クラウド・デバイスの中心はスマート フォンだったが、こうした構造にも変化の兆しが見 えている。o  今年のアメリカのクリスマス商戦では、iPad mini とNEXUS 7とKindle FireとSurfaceが激しく 争っている。わずか一年で、タブレット市場を独占 していたAppleのシェアは、半分に落ち込んだ。o  こうした競争は、クラウド・デバイスの新しい市場 をさらに拡大して、PCの時代の終わりを、さらに 早めることになる。
  31. 31. マシンのハードウェア性能の向上 o  10年前は、PCではPentium 4がよく使われてい たが、最新のCore i5/i7では、20倍から30倍以 上、CPUは速くなっている。 http://www.cpubenchmark.net/ common_cpus.html
  32. 32. Intel Core i7-3960X @ 3.30GHz 12,784 Intel Pentium 4 3.00GHz 367
  33. 33. クラウド・デバイスのマルチ・コア化 o  クラウド・デバイスに多く利用されている、消費電 力の少ないARM系のチップの性能向上も目覚ま しいものがある。ARM系チップのマルチ・コア化 は、このところ急速に進んでいる。o  例えば、DoCoMoの2012年冬モデルは、10機 種中6機種が4コアで、残りの4機種も2コアになり、 シングルコアとデュアルコアしかなかった一年前 とは、大きく変わっている。
  34. 34. 個人が携帯するマシンのパワー o  10年前のサーバー・マシンを、はるかに上回る性 能のマシンを、現在は、個人が日常的に持ち歩い ている。o  ただ、現在のWebアプリでは、クライアントとして のクラウド・デバイスは、基本的には、サーバーか ら送られてくるデータをブラウザーがレンダリング しているだけである。
  35. 35. ネットワークの高速化と、それを上回るスピードでのトラフィックの増大。 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 倍以上になっている。
  36. 36. ネットワークのリソースに、大きな負担をかけるAJAX o  現在のWebの主流であるAJAXも、トラフィックの 増大に拍車をかけている。ブラウザー上で何かの イベントが起きるたびに、クライアント・サーバー 間で、頻繁にトラフィックが発生する。o  HTTPは状態を持たないので、データの送信のた びに、HEADERの情報は繰り返し送られる。o  また、サーバーからクライアントへデータを送る通 信路を確保する為に、クライアントは、定期的に サーバーをpollingしたり、あるいは、一度つくら れたコネクションを、長期にわたって維持しようと 試みる(Long Polling)。
  37. 37. クラウド・デバイス固有の問題Fast Dormancy o  電話網を通じてインターネットに接続しようとする クラウド・デバイスの場合には、その為に電話網 との制御信号のやり取りが必要になる。それは、 当然、必要なことである。o  ただ、そこには、一つ問題がある。実は、デバイス 側は、電池の消耗を避ける為に、当面不要と思 われるプロセスを、どんどん休止状態にしていく。 Fast Dormancyと呼ばれるもの。これはこれで、 デバイスの電池のもちを延ばす為には、欠かすこ とが出来ないものである。
  38. 38. クラウド・デバイス固有の問題Signaling Burst o  普通のプロセスを休眠させるだけならいいのだが、 ネットワークのプロセスが休止するとコネクション は切断されてしまう。結局、プロセスが休眠から 覚めるとき、コネクションの回復の為に、あらため て電話網との制御信号のやり取りが必要になる。 o  ユーザーが気がつかないうちに、あるいはプログ ラマーが意識しないままに、デバイス上では、コネ クションの切断・回復が繰り返され、時によっては、 ネットワークを流れる本来のデータより、制御信 号のトラフィックの方が多くなるということが起きる。 Signaling Burstという現象である。
  39. 39. 最新のWeb技術に接する人の増大。 o  日本では、これまでガラ携しか使ったことのない 人が、大量に、スマートフォンのユーザーになって いる。世界中では、初めて持った携帯電話がス マートフォンだと言う人は、何千万人の単位で存 在する。o  こうした人たちに、現在のWebの技術は、どのよ うに見えているのだろうか? また、逆に、スマー トフォンを、既に何台か買い替えている人たちは、 最新のデバイスに対して、どのような期待を持っ ているのだろうか?
  40. 40. UIとUXの改善は、最重要の課題 o  クラウド・デバイスの利用者達の、グローバルな かつてないほどの規模拡大ということは、世界人 口の大多数にとって、最新のテクノロジーに触れ る条件が整い始めているということである。o  そこで何よりも必要とされていることは、IT技術に 対する知識を前提とはせずとも、誰にとっても直 感的で分かりやすいユーザー・インターフェースと、 誰にとっても快適なユーザー体験を提供すること である。
  41. 41. ユーザー・インターフェースの改善 o  もちろん、ユーザー・インターフェースの点では、 この間大きな進歩があった。o  タッチスクリーンの導入は、キャラクター端末から、 デスクトップ・メタファーとポインティング・デバイス によるUI/UXの改善以上の進歩だと思う。o  また、音声認識技術に基づく、自然言語を用いた インターフェースも登場し、多くの期待を集めてい る。
  42. 42. Real-Time, Responsive Webへ o  ただ、人間の欲求が無限だからかも知れないの が、我々は、必ずしも、現在の我々の経験に満足 している訳ではない。o  我々は、もっと快適で反応のいい技術を求めてい る。来るべきWebの世代が、Real-Time, Responsive Webと呼ばれているのは、とても 示唆に富んでいると思う。
  43. 43. 変化の三つの方向 p  WebプロトコルとHTTPの見直し p  サーバーとクライアントの役割の見直し p  開発言語の見直し
  44. 44. 変化の予兆 o  アプリ開発の今後の変化について三つのトレンド を紹介する。それは、様々な角度から、Webアプ リの基本的な前提の見直しが行われている。o  重要なことは、これらの動きが、同時多発的に進 行していることだと思う。これらの動きは、深いと ころで、相互に絡み合っている。o  それは、アプリ開発の枠組みが、全体として、大 きく変わろうとしていることの「予兆」だと、僕は考 えている。
  45. 45. WebプロトコルとHTTPの見直し o  HTTPは、本来は、文書の転送のためにデザインされたも ので、URLでリソースを指定して、リクエスト・レスポンスを 交互に繰り返す。o  データのキャッシュが可能であるというメリットはあるが、 もともと、バイナリーデータを含む、リアルタイムの大量の データ通信用に設計されたものではない。o  HTTPは、双方向ではあるが、Request/Responseのそ れぞれの時点を取れば、データの流れは一方向で、半二 重の通信プロトコルである。o  また、HTTPは、状態を持たないので、ヘッダーの情報は、 リクエストのたびに、再送される必要がある。
  46. 46. HTTPとAJAX o  HTTPは、リクエストに対するレスポンスが返るま で、処理がブロックする同期型のプロトコルだが、 実際のAJAXでは、非同期にサーバー・クライアン ト間で、頻繁にデータのやり取りが発生する。o  そのため、AJAXでは、サーバーへのPollingや Long Pollingというあまり自然とは言えない手段 を使って、なんとか、コネクションを維持している。o  こうしたトリッキーなスタイル自身が、ネットワーク のトラフィックを増大させ、AJAXが切り開いてきた ユーザー・エクスペリエンスの反応の良さに、むし ろ、反対の作用を及ぼしている。
  47. 47. 「AJAXは、HTTPの可能性を、最後の血の一滴まで、搾り取った。」 o  これ以上のHTTPの使い回しは限界に近づいて いる。もし、あるWebアプリの反応が良くないとし たら、ネットワークが遅いことが原因の一つになっ ている可能性は高い。o  現在のAJAXが主役の第三世代のStructured Webから、次世代のReal-Time, Responsive Webの世代に移行する上で、HTTPの見直し自 体が求められている。 o  この問題では、SPDY, WebSocket, Server Sent Event, SignalR等々、いくつかの提案が なされている。
  48. 48. サーバーとクライアントの役割の見直し o  サーバーに負荷が集中するのは、ある意味、当 然のことである。なぜなら、ネットワーク上のサー ビスは、ほとんど全て、一つのサーバーが、沢山 のクライアントのリクエストに応えることで成り立っ ているからである。o  ただ、以前は、サーバーに利用されるマシンとク ライアントのPCのハードウェアの性能差は歴然と していた。サーバー・マシンは、PCの数十倍から 数百倍の性能とメモリー/ディスクを持っていた。
  49. 49. クライアントの能力の飛躍的拡大 o  ただ、今日では、状況は違っている。サーバー・マ シンに使われるCPUは、ほとんどの場合、上位機 種のPCと同じものである。o  重要なことは、こうしたことは、サーバーの能力が 低下したということではなく、私たちが手にしてい るクライアントの能力が、飛躍的に向上したことを 意味しているということである。
  50. 50. クラウドは、速いか? o  クラウドは、高価で特殊なマシンではなく、PCと同 じレベルのコモディティ化したマシンを、大量に集 積したものである。o  IaaS型のクラウドでは、多くのサービスで、マル チコアのCPUの一つ一つのコアを仮想化して、ク ラウドのノードの最小単位として公開している。o  こうした場合、もっともチープなクラウド上のサー バーの能力は、CPUのコアを全部使っているクラ イアントPCの能力より、低いものになる。
  51. 51. Webアプリサーバーの最も重い仕事は、HTMLデータの生成 o  サーバー・サイド・プログラミングのWebアプリで は、Webアプリ・サーバーは、アプリの中核であ るビジネス・ロジックの実行はもちろんだが、デー タベースの管理等、沢山の仕事をこなさなければ ならない。o  ただ、その中で最大のもの、70%以上をしめるの は、クライアントに送るHTMLデータの生成である。
  52. 52. クライアントの負荷は、相対的には、軽い o  一方、クライアントの側は、潜在的には高い能力 を持ちながら、サーバーから送られてくるHTML のデータをレンダリングすることだけが、主要な仕 事になる。o  相対的には同程度のパワーしか持たないサー バーとクライアントでは、明らかに、要求される仕 事は、サーバーの方が重く、クライアントの方が 軽いものになる。
  53. 53. サーバーとクライアントの不均衡の解消 o  Webアプリのサーバー側では、多数のクライアン トからのサービス要求に、どのように応えようとし ているのか? o  サーバーとクライアントに要求される仕事量に不 均衡があることを前提とする限りは、本質的には、 うまい解決策はない。
  54. 54. WebアプリのScale-outの手法 o  現在行われている解は、基本的には、一台だけのサー バーで対応が難しいのなら、対応するサーバーの数を増 やそうということである。o  WebアプリのクライアントからのRequestは、システムの 前面に置かれたLoad Balancerで、同じWeb層、同じビ ジネス・ロジック層をもつ、複数のWebアプリ・サーバーの レプリカに分配される。o  こうしたWebアプリのScale outの手法は、サーバー・サ イド・プログラミングの3-Tier Modelの登場とともに実装 され、10年以上の長い歴史を持っている。そうしたアーク テクチャーは、現在のクラウドにも引き継がれている。
  55. 55. サーバーの負荷を軽くする試みThin Server Architecture o  ただ、サーバーの負荷の集中による応答の悪さ を解決しようとするなら、別のアプローチも必要に なってくると思う。今まさに、そういう模索が始まっ ている。o  僕が注目しているのは、サーバー側の負担を軽 減して、クライアント側に可能な処理を移していこ うという、Thin Server Architectureと呼ばれ るものである。基本的には、アプリのプレゼンテー ション層を、クライアントに移そうという試みである。
  56. 56. 開発言語の見直し o  “Write Once, Run Everywhere”というのは、 かつてのJavaのスローガンだった。o  ただ、Webの標準技術に基づくWebアプリの登 場とその普及は、Javaだけでなく、.NET系の言 語だろうが、PHP, Python, Rubyだろうが、どの ような言語で開発されようが、“Write Once, Run Everywhere”なアプリを作成することを可 能にした。o  アプリの機能を、開発言語の束縛から解放したこ と、これはWebアプリの大きな功績である。
  57. 57. Webアプリは、開発言語の多様化を生み出した o  もちろん、それは、どんなOS、どんなハードウェア の上でも走るアプリの開発が可能になったことを 意味しているだけで、アプリの開発には、特定の 開発言語が必要だということには、何の変わりも ない。o  むしろ、Webアプリは、開発言語の多様化を生み 出したと言っていいのかもしれない。
  58. 58. Webアプリ開発の標準言語としてのJavaScript o  Webアプリの開発言語の多様化の一方で、重要な変化 が進行する。かつては、HTMLのscriptタグの内部に、 ひっそりと存在していただけのJavaScriptが、第三世代 のStructure Webの時代には、AJAXの手法の主要な 担い手として、スポットライトを浴びるようになる。o  jQueryを初めとして、数十ものJavaScriptライブラリー が登場し、どのような開発言語を選んだとしても、多くの Webアプリの開発では、JavaScriptのコーディングが必 要になってきている。JavaScriptは、事実上のWebアプ リの開発の標準言語になっている。o  ResponsiveなWebアプリを作ろうと思ったら、なおさら、 JavaScriptの知識は、必須になる。
  59. 59. クラウド・デバイスの多様化の進行は標準言語への指向を高める o  いまや、PCに代わってクライアントの標準になろ うとしている、スマートフォンやタブレットといったク ラウド・デバイスの普及は、クラウド・デバイス上 のWebアプリ開発のニーズを、今まで以上に高 めている。o  ただ、クラウド・デバイスのベンダー毎の多様化の 進行は、アプリの開発者を、ベンダーの特定の開 発言語に縛り付けている。全く同じ機能のアプリ を開発するのに、クラウド・デバイスのベンダーと 機種に応じて、開発環境を変えないといけないと いうのは、あまり合理的でも経済的でもない。
  60. 60. マルチ・スクリーン環境でのユーザーの意識の変化 o  一方で、ユーザーは、PCだけではなく、スマート フォンやタブレットといった複数のクラウド・デバイ スを所有するようになってきている。この流れは、 テレビやゲーム機がクラウド・デバイス化すること によって、さらに大きなものになるだろう。o  こうしたマルチ・デバイス、マルチ・スクリーン環境 では、ユーザーは、同じ機能のアプリが、いつでも、 どこでも、どんなデバイスの上でも動くことを望む ようになる。そうしたニーズは、ベンダー毎に分断 された開発環境のもとでは、開発者側の負担を 増大させるだけである。
  61. 61. Lingua FrancaとしてのJavaScript o  こうした中で、本当の意味での“Write Once, Run Everywhere”を実現する言語、Lingua Francaへの期待が高まっている。そのもっとも有 力な候補は、JavaScriptに他ならない。o  おそらく、今後の言語のイノベーションの中心は、 JavaScriptを舞台に展開されることになる。ここ でも、様々な模索が行われている。
  62. 62. WebプロトコルとHTTPの見直し SPDY: HTTP自体の高速化の取り組み WebSocket: HTTPの置き換え
  63. 63. SPDYとWebSocket o  ここで取り上げるのは、 SPDY(「スピーディー」と読む)と http://dev.chromium.org/spdy WebSocket http://www.w3.org/TR/websockets/ の二つである。o  両方とも、HTTPの見直しの動きだが、一方の SPDYは、HTTPプロトコル自体の高速化を目指 し、他方のWebSocketは、HTTPそのものを、他 のプロトコルで置き換えようと試みである。
  64. 64. その他の注目すべき動き o  本当は、このテーマでは、数年前にはSOAの担 い手として最も注目されていた、Webサービス/ SOAPが影響力を落とし、RESTのスタイルが主 流になってきているという重要な変化がある。o  また、プロトコルの見直しでも、サーバーからの Push技術、Server Sent Event http://dev.w3.org/html5/eventsource/ や、マイクロソフトのSignalR  https://github.com/SignalR/SignalR/wiki といった技術があるのだが、これらについては、 今回は、割愛する。
  65. 65. AndroidのChrome対応は重要 o  残念なことに、Androidの開発者にとっては、 SPDYもWebSocketも、これまでのAndroidの 標準のブラウザーがこれらの技術には対応して いなかったので、チェックすることは出来なかった のだが、状況は、変わりつつある。o  Android4.0から、Android上でChromeが走る ようになった。NEXUS 7では、初めてChromeが Androidのデフォールトのブラウザーになった。 Googleは、来年から、最新のChromeを Androidに対応させるという。これは、非常に重 要な変化だ。
  66. 66. SPDY --- HTTPの高速化 o  SPDYは、HTTP自体の高速化の取り組みなので、 SPDYを話すサーバーとSPDYを理解するブラウ ザーさえあれば、SPDYを使うのに、既存のWeb アプリを変更する必要は全くない。o  事実、僕らがほとんど気付かないうち、Googleの サービスとTwitterは、既に、SPDYを使っている。 また、ChromeやFireFoxは、SPDYに対応して いる。
  67. 67. o  SPDYは、Webアプリ開発者からみると、ほとん どHTTPと同じと考えていいのだが、正確に言うと、 ネットワークのレイヤーが違う。o  HTTPはアプリケーション層で、SPDYはセッショ ン層のプロトコルである。セッション層のSPDYは、 プレゼンテーション層SSLの上に構築されている。o  SSLは、対応するアプリケーション層のプロトコル で言うと、HTTPSだと思ってもらっていい。
  68. 68. o  セッション層のSPDYは、その上に、既存のHTTP のsemanticsをそっくりまねて、アプリケーション 層として新しくHTTPを再構成する。o  正確に言うと、SPDYといわれているものは、 SPDYの上に再構築されたHTTPのことである。o  ただ、HTTPという同じ顔をしているので、Webア プリもその開発者も、インターネット上のルーター もプロキシーも、自分がハンドルしているのは HTTPだと信じ込んでしまうことになる。o  それは、SPDYの大きなメリットなのだが、その同 じ顔の下で実装されているのは、それまでの HTTPとは違うものである。
  69. 69. SPDYが行っていること o  SPDYは、下位のSSL(=TLS)層で、バイナ リーのフレーム転送プロトコルを持つ。o  SPDYは、一つのコネクション上で、複数の HTTPコネクションを同時にはることが出来る。o  Headerの圧縮。o  サーバーからのPush
  70. 70. 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/1340873192o  SPDYは、現在策定中のHTTP 2.0 の有力候補 のひとつだといわれている。
  71. 71. WebSocket --- HTTPの置き換え o  WebSocketは、Webのコミュニケーションの網 の目を大きく改善する、Web上で、全二重の Socketを提供するW3C、IETFで標準化された プロトコルである。o  ファイアウォール、プロキシー、ルーターをシーム レスに通過し、既存のHTTP上のコンテンツと、 ポートを共有する。o  TLSを使って、セキュアな通信が可能である。o  Cross-Origin Resource Sharingが可能であ る。
  72. 72. WebSocketで、WebがHalf DuplexからFull Duplexに
  73. 73. WebSocketの考え方 o  WebSocketのアプローチは、基本的には、Web 上のネットワークのプロトコルは、何もHTTP中心 に限ることはないだろうという考え方。Webでも、 もっと積極的に、TCP/IPのSocketを使おうとい うこと。o  こうしたアプローチは、特に、ネットワーク・プログ ラミングを複雑にし、ネットワークのリソースを過 剰に消費している、AJAXでの非同期の通信には、 非常に効果的。
  74. 74. Polling vs. Web Sockets
  75. 75. 通常の汎用のSocketプログラミングとWebSocketとの違い o  通常のSocketプログラミングとWebSocketは、 次の点で異なっている。1.  WebSocketによる通信は、クライアントとサー バーとのやり取りによって開始されるのだが、そ の最初の交渉には、HTTPが使われる。2.  WebSocketが想定しているクライアントは、ネッ トワーク上の任意のノードではなくて、Webブラウ ザーである。
  76. 76. 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
  77. 77. 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]*
  78. 78. WebSocket 実装の状況 o  現在、ほとんど全ての言語、ほとんど全てのWeb アプリの開発フレームワーク、ほとんど全ての Webブラウザーで、WebSocketへの対応は行 われている。o  まず、AJAXでのデータ転送あたりから通信の WebSocket化は、急速に進むと思う。エンター プライズも、積極的に取り組んでいる。 o  環境は出来ている。あとは、それを、我々が利用 するだけ。
  79. 79. 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/ 
  80. 80. WebSocketの課題 o  WebSocketの一つの問題は、WebSocketを開 いて渡されるTCP/IPのソケットが、低レイヤーの もので、自由度が高すぎることである。o  本格的な応用を考えたら、通信プロトコルの設計 から始める必要がある。「サブ・プロトコル問題」と いわれることがあるようだ。o  でも、それでは、開発者の負荷を考えたら、サバ・ クラ時代への逆戻りにもなりかねない。この点で も、面白い探求も行われているようだ。
  81. 81. サーバーとクライアントの役割の見直し Thin Server Architecture p Meteor p Avatar
  82. 82. サーバーとクライアントの役割の見直しの一般的な背景 1.  ハードの性能が、特にクライアント側で飛躍的に 向上したこと。クラウド・デバイスは、PCより、はる かにリッチなクライアントである。2.  サーバーの負荷の増大3.  ネットワーク・トラフィックの増大4.  プログラムとViewの分離の難しさ n  全てがサーバー側でコントロールされ、特に、両者が 密に絡み合っているようなWebアプリでは、どちらの 変更も、開発の工程に大きなインパクトを与える可能 性がある。 n  プログラマはデザインの変更を嫌い、デザイナーは、 プログラムの変更を嫌う。
  83. 83. クラウド・デバイス側の状況 1.  クラウド・デバイスの普及に伴って、どんなデバイ スでも動くアプリへのニーズが、市場に生まれて きている2.  クラウド・デバイスのアプリでも、ネットワークに接 続するアプリが確実に増え始めている3.  こうして、クラウド・デバイスのアプリ側では、「ア プリをWebアプリ化する」ことが、重要な選択肢 の一つとして浮かび上がってきている。o  基本的には、それは、HTML5への期待として、 「アプリを、HTML5を利用して、Webアプリ化す る」という展望として定式化出来ると思う。
  84. 84. 奇妙な状況・混乱 o  サーバー側では、HTTPを含んだWebアプリの見 直しの動きが起きている、その時に、クライアント 側では、Webアプリへの期待が高まっている。o  冒頭でふれた、アプリへのHTML5の導入に熱心 だったFacebookが、一転して、それを「最大の誤 り」として、ネーティブの開発に転換したのも、現 在の混沌とした状況を表している。
  85. 85. Thin Server Architecture o  Thin Server Architecture というのは、2008 年の初め頃に、Mario Valenteを中心とするグ ループが考えだしたコンセプト。o  残念ながら、発表当時は、大きな反響を起こすこ ともなく、忘れられていた。今また、こうした数年前 のコンセプトに照明があたると言うのも、興味深い ことである。https://sites.google.com/a/thinserverarchitecture.com/home/Home
  86. 86. Thin Server Architectureの定義 Thin Server Architecture(TSA)は、今日のWebアプリケーション・フレームワークの、慢心と複雑さに対する、反応である。TSAは、全てのプレゼンテーション層のロジックを、サーバーから、クライアント(Webブラウザー)上の、JavaScript(あるいは他)のロジックに移し変えることを提案する。これによって、次の三つのポジティブなことが得られる。
  87. 87. Thin Server Architectureの定義 1.  サーバー側の開発者は、ビジネス・ロジックに 集中出来る。 2.  クライアントが分離して開発されるので、アプ リケーションは、より複雑でなくなる。 3.  サーバーとクライアントの通信は、データを他 方の、あるいは将来のシステムとの間のデー タのインポート、エクスポート、あるいは表現 に利用可能な、プロトコルを利用する。
  88. 88. Thin Server Architectureの図式 クライアント サーバー
  89. 89. Meteor
  90. 90. Meteor o  この点で、僕が、最近興味をもったWebアプリの 開発フレームワークに、Meteorがある。o  何よりもMeteorでは、Webアプリの開発は、す べてクライアント側だけで可能になる。o  これまで、Webアプリの開発は、すべてサーバー 側で行われてきた。Webアプリの開発をすべてク ライアントで行うというMeteorのアプローチは、 サーバーとクライアントの役割については、丁度、 正反対のものである。 http://meteor.com/ https://github.com/meteor/meteor
  91. 91. Meteorの開発スタイル o  もちろん、Meteorはクライアントに閉じたアプリで はなく、きちんとしたWebアプリを作り出す。o  Meteorは、Full JavaScriptの開発フレーム ワークで、サーバーには、Node.jsを利用。o  サーバー側のコードを記述する必要は、ほとんど ない。クライアント側で作成する一つのコードの中 に、簡単に、サーバーとクライアントのコードを同 時に記述出来るo  Webアプリ・サーバーとのかかわりは、基本的に は、Meteorが生成したアプリを、サーバーに deployするだけ。
  92. 92. Thin Server ArchitectureとしてのMeteor o  Meteorは、クライアント側に、MVC(のようなも の)を持っている。この点でも、サーバーとクライ アントの役割については、従来とは反対のThin Server Architectureである。o  ネットワークを隔てたサーバーの介在無しで、クラ イアントが、Viewを直接操作出来ることは、この アーキテクチャーの大きな利点。頻繁に発生する、 AJAXイベントも、ネットワークをまたぐことなく、ク ライアント内部で処理が可能となる。o  こうして、Real-Time, ResponsiveなWebアプ リの作成が可能になる。
  93. 93. Meteorのデータ層の扱い o  Meteorは、データ層 Modelの扱いでも大きな特 徴を持っている。o  Meteorは、ローカルなシステム自体に、デフォー ルトでmini-MongoDBを内蔵しているのだが、こ のDBは、ローカルなサーバーに置かれても、リ モートのサーバー上に置かれても、Meteorのシ ステムからは、全く同じように見えます。
  94. 94. Re-Activeプログラミング o  より、強力なのは、Meteorでは、データベースの 項目が変更されると、自動的に、そのデータ項目 に関連した関数は、全て再計算される。o  少なくないケースでは、それはViewの変更を引 き起こす。プログラマが、ModelとViewを仲立ち するControllerで、そうした処理を記述する必要 はない。Modelの変更は、ただちにViewに反映 される。このことは、プログラマの仕事を大いに助 ける。 cf. Excelo  こうしたスタイルを、Re-Activeプログラミングと 呼ぶ。
  95. 95. Meteorアプリケーションの構造 o  Meteorアプリケーションは、クライアントのWeb ブラウザの内部で走るJavaScriptと、Node.js コンテナーの内部のMeteorサーバー上で走る JavaScript、それにサポートされている全ての HTMLフラグメントとCSSルール、静的なアセット から構成される。o  Meteorは、これらの異なるコンポーネントのパッ ケージングと連携を自動化する。ファイル・ツリー の中で、これらのコンポーネントに、どのような構 造を選ぶかについては、Meteorは、極めて柔軟 である。
  96. 96. Meteor Data and security 以下は、Meteorのドキュメントの 一部の抄訳である。
  97. 97. In Memory DB Cache o  全てのMeteorクライアントは、イン・メモリーの データベース・キャッシュを持っている。o  このクライアントのキャッシュを管理する為に、 サーバーは、JSONドキュメントの集合を publishし、クライアントは、これらの集合に subscribeする。o  集合内のドキュメントが変化すると、サーバーは、 それぞれのクライアントのキャッシュを変更する。
  98. 98. publish function o  それぞれのドキュメントの集合は、サーバー上の publish関数によって定義される。o  publish関数は、新しいクライアントが、ドキュメン トの集合に対してsubscribeするたびに、実行さ れる。o  ドキュメントの集合の中のデータは、どこから来て もいいのだが、一般的な場合は、データベースの クエリーをpublishすることである。
  99. 99. // server: publish all room documentsMeteor.publish("all-rooms", function () { return Rooms.find(); // everything);// server: publish all messages for a given roomMeteor.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}]});});
  100. 100. subscribe o  いったんsubscribeされると、クライアントは、そ のキャッシュを高速なローカル・データベースとし て利用するので、劇的に、クライアントのコードは、 単純化される。o  Readは、サーバーへの高価な回り道を、要求さ れることはない。 そして、それらは、そのキャッ シュの内容に限られている。クライアント上の集 合中のドキュメント全てに対するクエリーは、サー バーがクライアントにpublishしたドキュメントを返 すのみである。
  101. 101. // client: start a parties subscriptionMeteor.subscribe("parties");// client: return array of Parties this client can readreturn Parties.find().fetch(); // synchronous!
  102. 102. allow/deny rule o  クライアントが、いくつかのドキュメントを変更した 時、クライアントはサーバーに、その変更を要求 するメッセージを送る。o  サーバーは、提案された変更を、JavaScriptの 関数で書かれたallow/denyルールに照らして チェックする。o  サーバーは、全てのルールをパスした変更のみ を受け入れる。
  103. 103. // server: dont allow client to insert a partyParties.allow({ insert: function (userId, party) { return false; }});// client: this will failvar party = { ... };Parties.insert(party);
  104. 104. データの更新と伝搬 o  サーバーが変更を受け付けると、サーバーは、 データベースにその変更を適用して、影響を受け たドキュメントにsubscribeしていた他のクライア ントに、その変更を、自動的に伝搬する。o  もし、受け付けなかったら、更新は失敗する。サー バーのデータベースは、変わらないまま残り、他 のクライアントは、誰も、更新を見ることはない。
  105. 105. データの更新と伝搬 o  Meteorは、キュートなトリックも使う。クライアント がサーバーに対して書き込みをしようとした時、 サーバーの返答を待つこと無しに、ローカル キャッシュをただちに書き換える。このことは、ス クリーンは、ただちに再描画されることを意味する。o  もし、サーバーが更新を受け付けた時、これは 、 クライアントが正しく動作している時には、大部分 の時間は、そうなるべきなのであるが、クライアン トは、変化にただちにジャンプして、スクリーンを 更新するのに、サーバーへの回り道を待つ必要 がない。
  106. 106. Meteor Reactivity
  107. 107. Reactive Programming o  Meteorは、reactive programmingのコンセ プトを擁護する。このことは、コードを単純な命令 スタイルで書くことを可能にし、その結果は、コー ドに従って、データが変更された時にはいつでも、 自動的に再計算されることを意味する。
  108. 108. reactive context o  この自動的な再計算は、Sessionと Meteor.autosubscribeの協調によって達成される。o  Meteor.autosubscribeのようなメソッドは、”reactive context”を確立する。そのコンテキストの中で、データの 従属性が追跡され、必要な時に、関数の引数を再実行す るように準備している。o  SessionのようなData providerは、それに対して、 そ れらが呼び出されたコンテキストと、どのようなデータが要 求されているかを意識して、データが変更された時、 invalidationシグナルを送るように準備している。
  109. 109. reactive context +reactive data source o  この reactive context + reactive data source という単純なパターンは、広い応用可能 性をもっている。o  それ以上に、プログラマーは、 unsubscribe/ resubscribe の呼び出しのコードを書く手間が 省け、それらは、正しい時に確実に呼び出されこ とになるo  一般的に、Meteorは、そうでなければ、誤りを犯 しやすいロジックで、アプリケーションの邪魔にな る、データ伝搬の全てのクラスを取り除くことが出 来る、
  110. 110. reactive-context o  次のMeteor関数は、コードを、reactive- contextで走らせる。 n  Templates n  Meteor.render and Meteor.renderList n  Meteor.autosubscribe n  Meteor.autorun
  111. 111. 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
  112. 112. Meteor LiveHTML
  113. 113. LiveHTML o  HTML templating は、Webアプリの中心であ る。Meteorのライブ・ページ更新技術で、HTML を、reactiveにレンダー出来る。それは、ページ を生成するのに利用されたデータの変化を追跡し て、自動的に更新が行われることを意味する。o  この特徴は、全てのHTMLテンプレート・ライブラ リーで機能し、手で書かれたJavaScriptで生成 されたHTMLでも機能する。
  114. 114. 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”); // ページは自動的に更新される
  115. 115. Meteor.render() o  Meteor.render は、rendering function、あるHTML を文字列として返すを関数を引数に取る。それは、自動更 新するDocumentFragmentを返す。o  rendering functionで利用されたデータに変更があった とき、それは、再実行される。DocumentFragment 内 のDOMノードは、ページのどの場所に挿入されていても、 その場で自分自身を更新する。それは全く自動的である。o  Meteor.renderは、rendering functionによって、どの データが利用されたかを発見する為にreactive context を使う。
  116. 116. Meteor Template
  117. 117. <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 Meteors optional </p> {{> preserveDemo }} {{> constantDemo }} {{> stateDemo }} {{> d3Demo }}</template>
  118. 118. <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>...
  119. 119. <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
  120. 120. データベースへのクエリー <template name="players"> {{#each topScorers}} <div>{{name}}</div> {{/each}}</template> Template.players.topScorers = function () { return Users.find({score: {$gt: 100}}, {sort: {score: -1}});};
  121. 121. // in a JavaScript fileTemplate.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>
  122. 122. // 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}}); }});
  123. 123. Meteor Examples
  124. 124. <head> <title>Leaderboard</title></head><body> <div id="outer"> {{> leaderboard}} </div></body><template name="leaderboard"> <div class="leaderboard"> {{#each players}} {{> player}} {{/each}} </div>
  125. 125. {{#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>
  126. 126. 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}); } });}
  127. 127. 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" : ; }
  128. 128.   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); } });}
  129. 129.   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); } });}
  130. 130.   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); } });}
  131. 131. Project Avatar
  132. 132. 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
  133. 133. なぜ、Avatarなのか? o  ブラウザーとサーバーのViewは、これまでと同じ く、HTML/JSで結ばれているのだが、ブラウザー のModelは、サーバー側のServiceとJSONで結 ばれている。 o  これは、僕の想像だが、Avatarというプロジェクト 名は、このブラウー上のModelが、サーバー上の データのAvatarだと言うことではないかと思って いる。サーバー上のAvatar Serviceは、ブラウ ザー上に、Avatarを作り出す。
  134. 134. Avatar クライアント o  Avatarのクライアントは、UI NodesとModelsと Controllerから、構成される。o  UI Nodesは、Page, Form, Input, Table, Container, Menu, Button等からなる。o  Modelsは、Local, Rest, Push, Socketからな る。
  135. 135. Avatar サーバー o  Avatarのサーバーは、Data Providerと Servicesから、構成される。o  このData Providerは、Avatar Serviceの中核 である。File, DataBase, Coherence等の永続 化サービスから構成される。Avatarは、JPA-RS とも呼ばれていた。o  Servicesは、クライアントのModelに対応して、 Rest, Push, Socketからなる。
  136. 136. Avatar の開発言語 o  Avatarは、Javaのフレームワークとは言えない。 JavaEEのクラウド化とは、全く異なるものである。o  クライアントは、全て、JavaScriptで記述する。o  Back-Endで、Javaのサービスを利用出来るの は当然だが、サーバー側も、JavaScriptで全て 記述出来る。
  137. 137. Avatarのプログラミング・スタイル o  Avatarのプログラミング・スタイルは、かなり奇妙 である。XMLの中にJavaScriptやHTMLが埋め 込まれている。この例では、クライアント側の Model=LocalModelとView=Pageの定義が見 える。
  138. 138. 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の例。
  139. 139. ModelとServiceの対応 o  クライアントの restModel, pushModel, socketModelに対応して、サーバー側では、 restService, pushService, socketService が定義される。
  140. 140. 「アプリ開発の新しい動向」中間のまとめ
  141. 141. Webアプリについて o  Webアプリが登場して10年以上たつ。AJAX の 登場からも5年以上たつ。o  Webアプリは、いろいろなところで息切れが始 まって、いろいろな見直しが始まっている。そろそ ろ、次のモデルが登場する時期に近づいている。o  Webの世界は、Real-Time, Responsiveな Webに変わろうとしている。アプリも、その流れに 追従するだろう。o  変化を牽引しているのは、クラウド・デバイス。 PCの時代は終わりつつある。
  142. 142. クラウド・デバイスのWebアプリ化について o  現在、Webアプリのスタイルが変わりつつ転換点 にあるという認識が必要。o  クラウド・デバイスのWebアプリ化は、開発者とシ ステムにとって万能でも、ユーザにとって最良の 選択肢とは限らない。o  少なくとも、現在のWebアプリの枠組みをそのま まにして、HTMLをHTML5に変えただけでは。 Facebookが直面した問題は、そこにある。
  143. 143. Thin Server Architectureについて o  Webアプリに代わる、あるいは、Webアプリの新 しい段階の候補としては、Thin Server Architectureが有力である。o  そこでは、アプリのプレゼンテーション層をクライ アント側に置くことで、現在のWebアプリの抱える 多くの問題が解決される可能性がある。o  ただ、大きな枠組みの見直しなので、エンタープラ イズ含めたその受容には、一定の時間が必要に なるだろう。o  同時に、データベースを中心に、様々な技術の見 直しの連鎖反応が起きてくると思う。
  144. 144. 再び、Thin Server Architectureについて o  ただ、注意してほしいのは、Thin Server Architectureは、現在では孤立しているが、未 来では成長するアーキテクチャーなどではないと いうことである。o  それは、気の利いたWeb業界の人や、マルチ・ス クリーンのクラウド・デバイスの開発プラットフォー ムを作っている人、ネットワーク・ゲームの開発者 にとっては、よく知られているし、既に、広く利用さ れているものである。o  それは、すでに、そこにある。
  145. 145. あらためて、Facebookの選択について o  事実として重要なことは、ネットにつながる、クラ ウド・デバイスのネイティブ・アプリは、Webアプリ 形式ではなく、ほとんど、プレゼンテーション層を ネイティブに自前で持つTSAの形態をとっている ということである。o  HTML5について、”because it just wasn’t there”といった、Zuckerburgの発言は、Web アプリ/HTML5指向からの後退ではあるが、むし ろ、現状でのクラウド・デバイスでのWebアプリ形 態の限界と、TSAの有効性を示すものだと考えた 方がいい。
  146. 146. 過渡期としての現在HTML5とJavaScriptの未来 o  サーバー・サイドで進行しているWebアプリの枠 組みの見直しも、クラウド・デバイス側で現在の主 流である、ネイティブ言語でのTSAの実装も、い ずれも、過渡的なものである。o  いずれ、おそらくは、TSAを中心として、新しいア プリ開発の統一的な枠組みが、登場して来る。o  少なくとも、クラウド・デバイス側で、その中心的な 役割を担うのは、HTML5 とJavaScriptであるこ とは、ほぼ間違いないと感じている。o  HTML5とJavaScriptは、これからますます重要 になるということ。開発者は、それに対する準備を。
  147. 147. エンタープライズ・システムの変化 o  こうした流れの中で、エンタープライズのシステム がどう変化するのか予測するのは、コンシューマ やデバイス側の変化予測より、難しい。o  というか、Webアプリに事実上特化した、アプリ ケーション・サーバーと開発ツール群を擁する、エ ンタープライズのプレーヤの変化の予測が難しい。o  ただ、サーバーは、HTMLのレンダリングではなく、 サービスの提供に集中すべきだというのは、正し いと思う。その意味では、SOAは重要である。o  結局は、サーバーのサービスの受け取り手が、ク ラウド・デバイスに変わっていくことで決着がつく。
  148. 148. 開発言語の見直し 12月17日のクラウド研究会へつづく。 申し込みは、 http://kokucheese.com/event/ index/64071/
  149. 149. 12月17日 クラウド研究会 o  日時   2012年12月17日(午後19時開始)o  開催場所 日本マイクロソフト社 品川本社 Seminar Room A (東京都港区港南 2-16-3 品川グランドセン トラルタワー)o  参加費 無料 o  定員 150人(先着順)
  150. 150. クラウド研究会の告知から o  「今回のクラウド研究会は、Webアプリ開発の 新しい動向という点では、内容的に、前回のク ラウド研究会と連続するものです。今回は、こ うした動きを主導しているのが、開発言語のレ ベルでいうと、JavaScriptであり、 JavaScriptの適用範囲の拡大とその機能強 化が、今後のWebアプりの開発に、大きな影 響を与えるであろうという観点から、セッション を構成しました。ご期待ください。」
  151. 151. 丸山の講演 「JavaScriptの進化」 o  JavaScriptでは、jQuery.jsをはじめとして、Node.js, Backbone.js, Redis.jsといったライブラリー・レベルの 機能拡大が活発に行われています。それと同時に、重要 な動きとして、JavaScript言語自体の拡張の模索が、い ろいろな形で行われています。o  講演では、JavaScriptのMulti-core対応の高 速化の試みとしての、IntelのRiverTrail、 JavaScriptでの大規模開発を展望した、 JavaScriptへの静的型付けの導入の試みとして の、GoogleのDart、同じく、Microsoftの TypeScriptを紹介したいと思います。

×