小松 健作 – HTML5Experts.jp https://html5experts.jp 日本に、もっとエキスパートを。 Sat, 07 Jul 2018 03:14:05 +0000 ja hourly 1 https://wordpress.org/?v=4.7.19 Googleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？ /komasshu/19704/ Wed, 22 Jun 2016 01:00:14 +0000 /?p=19704 「Google I/O 2016」では、これからのWebアプリ開発パターンとして提唱しているPWApps(Progressive Web Apps）について多くのプレゼンテーションがなされました。

PWAppsとは、最新のWeb技術を有効に活用し、漸進的（Progressive）に高度なユーザー体験を提供しようとする概念です。このPWAppsの概念を具体化する一つの手法として、「PRPL」（パープル）と名付けられた開発・提供パターンが提案されました。本稿ではこのPRPLを解説するとともに、その有効性や課題点を考察します。

本稿は、Google I/O 2016の二つのセッションに関する、解説記事です。

PRPLの概要、PWAppsとの関係

PRPLは、次の4つの頭文字をとった、開発パターンです。

  • Push
  • Render
  • Pre-cache
  • Lazy-load

モバイルWebアプリケーションにおいて、現行のWeb開発・提供パターンが抱える課題点を解決するものとしてGoogleが今回の I/Oで提案した新たなフレームワークパターンです。

Web Componentsや、Service Worker、HTTP/2 Serveer Pushといった Webの最新技術をフルに活用し、レスポンス性の高いユーザー体験を提供しようというものです。PWAppsの具体的なパターンの一つとして位置付けられます。

The PRPL Pattern

PRPLについては、以降のパラグラフで詳しく解説するとして、まず最初にPWAppsについて概説します。

PWAppsが最初に発表されたのは、昨年11月。シリコンバレーGoogleオフィスで開催された Chrome Dev Summitのことです。モバイルWebアプリにメインターゲットをおき、ネイティブアプリに近いユーザー体験（オフライン動作や高速なレスポンス性）を漸進的に提供していこうという考え方です。

ここで、漸進的といっても、イマイチピンと来ない方も多いことでしょう。具体例としてService Workerのパターンについて紹介します。Service Workerの詳細ついては、HTML5 RocksやGoogleの安田絹子さんの記事（Service WorkerのChrome実装者です！）を参照ください。

Service Workerは、オフラインWebを実現する最新Web標準技術の一つ。オフライン環境でも動作するWebアプリケーションの提供を可能とします。オールドファッションなオフライン Web（Application Cache）とは異なり、柔軟なキャッシュ制御が可能となるため、多様なWebアプリケーションにオフライン Webの世界を適用することができます。ネイティブアプリのようにオフラインでも動作するWebアプリ体験を提供することが可能となるわけです。

また、Service Workerは単なるオフラインアプリの実現にとどまりません。多様なキャッシュ制御ができるということは、リソース（HTMLやJavascriptファイルなど）のロード時間短縮が可能となることを意味しており、アプリキャッシュによる高速なレスポンス性を実現します。

さらに、Service Workerは、プッシュ通知もサポートします。これにより、該当のWebサイトにアクセスしていなくても、通常のモバイルアプリのようにプッシュ通知を提供することができます。Service WorkerはモバイルアプリとWebアプリとの間の様々なギャップを埋め、より高度なユーザー体験を提供するためのAPIなのです。

では、このService Workerと漸進性との関係はなんでしょう？答えは単純で、Service Workerは、それが対応していないブラウザ環境であっても、Webサイトのサービス提供自体を止めることはありません。

したがって、非対応ブラウザ利用ユーザーには、ベースとなるWebサービスのみを提供し、対応ブラウザ利用ユーザーには、オフライン対応・高速なレスポンス性・プッシュ通知といったより高度なユーザー体験を提供します。これが漸進的なWebアプリケーションと言われる所以です。

現状のWeb開発課題を解決するPRPL

さて、本題のPRPLです。これは前述のService Workerなど、様々な最新Web技術を活用したWeb開発・提供パターンです。もちろん、PWAppsの理念に基づいています。

現状のWebアプリ開発の課題。バンドルの肥大化

最近のWebアプリ開発手法は、コンポーネント化による独立性・安定性の向上と、バンドル（単一ファイルの生成）による高速性の両者に基づいています。BabelやReact、npmといったツール類を用い、ES2015やTypeScript記法による洗練されたコンポーネント志向のコーディングを行いつつ、mochaやwebpackなどを用い、オートメーション化されたテスト駆動開発と全てのコンポーネントを集約したコンパイルの実行、バンドルを行うのがベストプラクティスとなっています。

ここで、コンポーネント化のメリットは解説不要でしょう。Webアプリの各機能要素をライブラリとしてコンポーネント開発することで、独立性・安定性・再利用性といった様々な恩恵を得ることができます。

一方で、バンドル化のメリットはなんでしょうか？答えは、ロード時間の短縮です。この点は、PRPLを理解する上で重要な知識となりますので、より詳しく紹介します。

そもそも、Webはコンポーネント志向を支えるプラットフォームであると捉えることができます。それぞれのコンポーネント要素（Javascriptライブラリ、HTMLテンプレート、CSS）は、それぞれ個別のリソースファイルとして提供され、 <script> タグや、 <link> タグなどにより個別にダウンロード、ブラウザ内で一連のプログラムとして結合・コンパイルされ、Webサービスとして提供されます。

しかし、このような開発・提供手法は甚大なユーザー体験の低下を招きます。HTTP/1.1の制約により、ファイルロード時間の増大を促してしまうのです。HTTP/1.1はリクエスト＆レスポンス型のデータ転送プロトコルとなっているため、リソースファイルのダウンロードが完了しないと、次のファイルのダウンロードを開始することができません。

この影響は無視することができないものであり、仮にブラウザとWebサーバー間の往復転送遅延時間を0.1秒とし、300個のコンポーネントリソースをダウンロードしなければならないとなると、0.1 x 300で合計30秒の待ち時間がサービス起動にかかってしまいます（実際には、平行ダウンロードにより数分の一に短縮されますが、極端な例として理解ください）。

HTTP/1.1

これを解決するのがバンドルです。Webアプリ開発時に、サーバーサイドで一連のコンポーネントリソースを結合した一つのファイル（バンドル）を生成し、サービス提供時には、バンドルファイルのみをダウンロードすることで、転送待ち時間によるサービス起動時間を短縮する手法が用いられています（バンドル時には単に結合するだけでなく、ブラウザ依存の解決や、構文チェック・コードの最適化・重畳リソースの削減など、各種コンパイルプロセスが実行されます）。

App bundling

しかし、これは新たな問題を引き起こしました。それはバンドルファイルの肥大化です。全てのコンポーネントが一つのリソースファイルに集約されるため、設計を怠るととんでもないサイズのバンドルファイルが生成されます。

最近では、SPA（Single-Page Application）の進展により、全てのルート（SPAに不慣れな方は、個別のWebページと考えていただいて結構です）を制御する一つのバンドルファイルが提供されることも珍しくありません。

このようなケースでは数百キロバイトのバンドルファイルとなることもチラホラ。ダウンロード時間の増大をもたらします。これは、モバイル環境のユーザーにとっては、とくに深刻な状況になりえます。

コンポーネント志向への回帰。PRPLによる解決

このバンドルファイルの肥大化問題を解決するのがPRPLです。最新のWeb技術を活用することで、バンドルを行わずとも、転送待ち時間によるユーザー体験の低下を解決することができます。

コンポーネントの定義

PRPLでは、各コンポーネントがWeb ComponentsのCustom Elementsで提供されることを前提とします。具体的には、各コンポーネントが カスタム要素としてHTMLファイルとして提供され、親となるHTMLからはHTML Importsにより各コンポーネントの利用が宣言されます。

HTML Imports

この手法の重要な点は、標準化された手法によりコンポーネントの利用が宣言されること、これによりサーバーサイドでHTML Importsのリンクを解析し、Webサービスに必要となるコンポーネントツリーを得ることができます。これが、その後の HTTP/2 Server pushの適用につながります。

HTTP/2 Server pushの適用

先に解説した通り、HTML Importsで記述した場合、個別のリソースファイルの転送待ち時間によるサービス起動時間の増大が発生します。これを解決するため、PRPLではHTTP/2 Server pushが利用されます。

HTTP/2は、HTTP/1.1に続く最新バージョンのファイル転送プロトコル。HTTP/1.1のリクエスト＆レスポンスによる待ち時間の制約を受けずに、複数リソースファイルを効率的・スピーディーにダウンロードすることが可能になります。

HTTP/2

HTTP/2では、ダウンロード完了を待つことなく、以降のリソースダウンロードを行うことができます。したがって、サーバーサイドでバンドルすることなく、個別のコンポーネントファイルを高速に転送することができるのです。

PRPLでは、さらなる転送時間の短縮を図るため、HTTP/2 Server pushが用いられます。先にも書いた通り、PRPLでは各コンポーネントファイルがHTML Importsの記法により親となるHTMLファイルに記載されています。したがって、最初のHTMLファイルがダウンロード完了しないと、各コンポーネントファイルのダウンロードを開始することができません。

しかし、HTTP/2 Server pushを用いると、この待ち時間すら短縮することができます。前述の通り、PRPLでは、サーバーサイドで HTML Importsを解析し、コンポーネントツリーを得ます。そして、そのコンポーネントを最初のHTMLファイルに対するレスポンスヘッダーに記述することで、HTTP/2サーバーはクライアントからのリクエストを待つことなく、以降のコンポーネントリソースをPushすることができます。

HTTP Request Headers

HTTP/2 + Server Push

これにより、いわゆる0 RTT（Round-Trip Time）で、全てのコンポーネントリソースをブラウザに転送することが可能になります。

Service workerによるpre cache

ここまでであげた手法により、初期起動に必要となる リソースを高速に転送し、ユーザーの起動待ち時間を短縮することが可能となりました。しかし、Webサービスは、初期画面だけではありません。その後の、ユーザー操作に基づいた各画面の提供が必要となります。

例えば、ショッピングサイトでは、各商品画面や商品購入画面が必要となります。これらを形成するコンポーネントは、初期画面に含まれるものもあるでしょうし、それ以外のものも含まれるでしょう。これらのコンポーネントリソースのダウンロード待ち時間を短縮するために、PRPLではService Workerが用いられます。

PRPLでは、初期画面用のコンポーネントリソースをService Workerを用いて、キャッシュに保存します。以降の画面で該当のコンポーネントが必要になった場合は、このキャッシュが用いられるためダウンロードは発生しません。

また、初期画面を表示したあと、以降の画面で必要となるコンポーネントリソースをバックグラウンドで事前にダウンロードし、Service Workerを用いキャッシュとして保存します（pre cache）。したがって、これらのコンポーネントリソースについても待ち時間は発生しません。非常にレスポンス性の高いWebアプリをon-the-flyで提供することが可能となります。

さらにユーザー体験を向上する lazy load

最後にlazy loadです。Webアプリのリソースには優先度があります。例えば、ファーストビューには表示されない画像ファイル、初期画面のメニューコンポーネントなどは、優先度が低いリソースの典型的なものです（メニューは、ファーストビューに含まれますが、最初からは表示されてなくてもいいですよね！）。

これらのリソースについては、lazy-loadとして、優先度の低いものとして宣言してしまいます。こうすることで、ブラウザはこれらのリソースのダウンロード順番の優先度を下げ、ファーストビューに本当に必要なものを優先して表示することができるようになります。

サンプルサイト、開発ツール

PRPLを活用したサンプルサイトとして、ショッピングサイトのサンプルが公開されています。

https://shop.polymer-project.org/

SHOP

Chromeのdev tool、networkタブのwarter fallパターンから、PRPLの転送フローを確認することができます。

SHOP - Push

また、開発ツールPolymer App ToolboxではPRPLの一端が提供されています。

Polymer App Toolbox

$ npm install -g polymer-cli
$ mkdir my-app; cd my-app
$ polymer init app-drawer-template
#... write code ...
$ polymer build

HTTP/2対応ブラウザ、非対応ブラウザ用に、それぞれPRPLの概念に基づいた非bundle版、bundle版のjsが生成されます（こういったところに、PWAppsの概念が適用されています）。ただし、こちらの開発ツールでは、HTTP/2サーバーは提供されておらず、PRPL概念の一部を具体化したものとなっています。その点は、注意してください。

PRPLは即座に利用可能か？

さて、今回のGoogle I/Oで発表・提案された新たな開発・提供手法のPRPL。最新のWeb技術を活用することで、従来のWebアプリが内包する課題を解決し、モバイル環境での最高のユーザー体験提供を目指したものです。ただ、ここで気になるのが、以下の2点です。

  • 「PRPLは今すぐ、production環境に適用できるものなのか？」
  • 「本当にこれまでの開発プラクティスよりも優れているのか？」

この点について、（あくまで）個人的な見解を述べ、本稿を締めたいと思います。

まず結論から言うと、「Productionでの利用は、まだ早い」 というのが僕の率直な感想です。

その理由として、以下の点があげられます。

まだHTTP/2の環境が整備されていない

HTTP/2は、最近標準化が完了したばかり、実装はまだ完全には追いついていません。実際、apahceやnginxではHTTP/2の基本機能は搭載されているものの、Server pushまだ未サポートです。

また、これらの実装が完了したからといって、それがすぐ Productionに適用できるというものではありませんし、AmazonのELBやHerokuなどIaaS/PaaS事業者側のサポートも必要となるでしょう。WebSocketがそうであったように、サーバーサイドのエコシステムが整備されるのにはしばらく時間が必要です。

まだ開発者フレンドリーではない

開発ツールPolymer App Toolboxを見てみてもわかりますが、PRPLの概念はnpm + webpackのような開発者フレンドリーな開発手法とは相性が悪いです（実際、bowerが用いられています）。

Webアプリのコンポーネント開発において、Javascript部分が占める割合は非常に大きく、これをbowerベースで行い、いちいちHTML Importsで記述することは大変なストレスとなります。やはり、npm + webpackでストレスレスにコーディングしたい…、というのがJSエンジニアの率直な意見でしょう。

cacheとの相性が悪い

PRPLで用いられているHTTP/2 Server pushですが、Webのキャシュと非常に相性が悪いことが知られています。基本的に、ブラウザの状態と無関係にリソースをPushする仕組みのため、ブラウザにキャッシュがあろうがなかろうが、リソースをPushしてしまいます。

したがって、「初回の起動である」、「常にダイナミックに変動するリソースである」の場合を除いてHTTP/2 Server pushの効果は限定的ですし、逆に負の効果をもたらします(キャッシュがあるのであれば、リソースをPushする必要はない)。バンドルのサイズ肥大化の問題も、persistant cache制御さえちゃんとしてやれば、初回起動時およびバンドル変更時の問題だけになります。

最後に

最後にネガティブな意見を述べましたが、僕はPRPLの考えには基本的に賛同しています。Googleは常にWebをより良いものにするため、努力を続けている企業。その姿勢の表れであると感じています。

本稿で述べたPRPLの限界点は、現状のツール環境に依存するところが大きく、新たなツールが登場することでこの状況は一変することでしょう（本来、ツールは概念の一部を具現化するものであって、それをもって概念全体を評価されるべきものではありません）。

さまざまな概念やツールが融合し、開発者がフィードバックしていくことで、よりよい形が作り上げられていく。これまでのWeb開発の進化がそうであったように、そのような文脈の中でPRPLや、それのベースとなっているPWAppsが進化していくことでしょう。

]]> ティムのクロージングトークが素晴らしい！「W3C20 ANNIVERSARY SYMPOSIUM」ライブレポート(2/2) /komasshu/11258/ Thu, 30 Oct 2014 02:10:09 +0000 /?p=11258 連載： イベントレポート (27)

10月29日、米シリコンバレーのサンタクララマリオットホテルで開催された「W3C20 Anniversary Symposium」より、 ティム・バーナーズ=リー氏の講演を現地レポートします。

※このレポートは、小松 健作, 飯田 アレン真人, 本間 咲来の3名で共同作成しました。

Closing Talk

Tim Berners-Lee, Web Inventor and W3C Director

今日、講演者からWebの未来や課題点について、貴重な意見・ディスカッションをいただけたことを嬉しく思っています。
25年前、この技術を考案し、私は一緒に働く人を探さなければなりませんでした。その後起きたことは、全てランダムで。しかし、全てが重要なことでした。


▲ティム・バーナーズ=リー氏

最もアメージングだったことは、Webに集った人たちの情熱で。元々のHTMLのタグはたったの6個でしたが、すぐに人々は新しいタグを追加し、コラボレーションの必要性が生まれました。
みんなは、全ての仕様が、私のコンピュータに格納されていることを心配し、コンソーシアムを作ることにしました。そして、多数の会社の協力を得ることができるようになりました。
多数の企業の協力に感謝します。そのオープン性にも。そして、CERNにはロイヤリティを変更しなかったことを感謝します。
今、我々は、仕様を規定するフレームワークを持ち、企業がロイヤリティフリーに協力してくれる環境を得ました。
W3Cに協力してくれる全ての方、W3Cの全てのスタッフにとても感謝します。
メンバーには2種類がいます。一つは招待された人たち。WG会合中で、「あの人は凄い」と言われた人たちです。仕様を作るのには本当にたくさんの苦労が必要です。W3Cの仕様化に協力いただいた、この部屋にいない人たちも含め感謝します。

次に、レイヤーについて話します。
低レイヤーのケーブルは、全てをつなぎ、ハイレイヤーは、今何をしたいかを表現します。ただ、コードを書けばいい。下位のことは気にしなくていい。Webプラットフォームは公平でbumpはありません。何の制限もありません。最初は10bpsでしたが、今は10Gbps。電車は最初は10マイル/秒でしたが、今も10Gマイル/秒にはいたっていません。

インターネット技術の進化と供給は、それがなぜ成功したのかとは、完全に独立に実行されています。
Webが作り上げたものは、健康にクリティカルで、民主的で。
まれに、我々はlayerを破ります。誰がtrustか、何が悪いのか、オープンなマインドを保つために
我々は、全ての時間をWebに費やすことはできません。もし、そうするなら、それを防ぐ必要があります。
我々は、あなたのISPがどんなことを考えているかに関係なく、その防御を保ち続ける必要があります。
ラグジャリーな時間の中で、考えなおすことが必要でしょう。それはなぜ必要なのか？世界にとって本当に必要なことは何なのか？

不公平性は問題です。我々は、がんを治したい。
我々は、人類に多数のチャレンジすべきことを有している。でも、それを成し遂げるには社会構造を変革しなければいけない。
Twitterは、それを増幅してくれるシステム。我々は、それが必要なのか？
それを反対にしてくれるシステムをつくり上げることはできるだろうか？意見をモデレートする。
Facebookはどうだろう、友達間のみにターゲットを置く。あなたは、新しいアイディアや意見を得ることはできない。

違う興味、違う信念、違うパーティ。我々は、これをWebの上で解決する方法を見出さなければならない。

関連レポート

* Webのメモリアルイヤー！W3C20 ANNIVERSARY SYMPOSIUM ライブレポート(1/2)

]]> Webのメモリアルイヤー！W3C20 ANNIVERSARY SYMPOSIUM ライブレポート(1/2) /komasshu/11213/ Wed, 29 Oct 2014 21:41:46 +0000 /?p=11213 連載： イベントレポート (26)

今年は、Webのメモリアルイヤー。Web生誕25周年、W3C設立20周年、そして昨日アナウンスされたようにHTML5の勧告化が完了した年です。このようなメモリアルイヤーを記念し、本日（10/29）PM3時～6時（現地時間）、シリコンバレーのサンタクララマリオットホテルにてW3C20 Anniversary Symposiumが開催されます。本稿では、その模様を現地よりライブレポーティングします。
w3c20logo

※このレポートは、小松 健作, 飯田 アレン真人, 本間 咲来の3名で共同作成しました。

Welcome and Introductions

Jeff Jaffe, W3C CEO

イベント開始は、W3CのCEOを務める Jeff氏よりウェルカムトーク。
W3Cの役割は、webのポテンシャルを広げること。webの素晴らしさ、広がりは今さら言うまでもない。Webはデバイスまで広がり、そのポテンシャルは広がる一方であることを述べました。

招待講演

Vint Cerf – A Long Term View of the World Wide Web

最初の招待講演は、TCP/IPの発明者 Vint Cert氏。WWWへの長期的な観点について述べられました。
Internetの最初のドキュメントが公開されたのは40年前。それから現在にいたるまで多くのことが変わりました。そして、我々のコミュニケーション手段のほとんどは、インターネットで行われるようになりました。
様々なメディアが現れ、消滅していきました。floppy disk, CDメディア。いずれなくなるでしょう。長きに続くメディアが必要です。優れた設計が施されたソフトウェア。更なるプライバシーの保護も重要でしょう。

David-Michel Davies – Forging the Big and Beautiful Web

1990年代のWebサイトは、ほんとにひどいものでしたが、最終的には彼らがWebを前進させてくれました。感謝しなければいけません。
フランスには、ストリートアートを飾るビルディングがありますが、それらが陳腐化するのを防ぐため、WebGLでオンライン公開することにしました。

優れたインターフェースは、人々が伝えたいことの価値を高めます。ビデオやインタラクティブにより、スクロールするだけでストーリーを語ってくれます。
人々は、様々なルールを壊してきました。大きな会社がルールを壊し始めた時、AdobeはFlashの提供を開始しました。Flashでサイトを作るのはどうかという考えもありますが、FlashはWebを大きく前進させました。ルールを壊すことで、前進が生まれるのです。

Anders Wahlquist – Stories Empower, and We Power Stories


Webの表現力は、格段に上がりました。1999年のWebは制限が強く、クリエイティブなものを提供することはできませんでした。2008年には、Flashでホラーゲームを作れるようになり、iPhoneの登場で、その役割はHTML5へと移されていきました。また現実世界とWebとの繋がりも始まりました。例えばロボットを動かすとか。
ムービーを作るために、参加者がそれを手伝うことができるようになりました。コンテンツをpushするほど、良いストーリーが作られていきます。
10年前にできなかったことが、今ではWebでできるようになりました。クリエイティビティの美しさは、技術の進化と共に変わっていきます。良いストーリー、優れたデザインには常にニーズがあり、テクノロジーはそれを支え続けるのです。

Di-Ann Eisnor – Solving Problems Together: Beyond Crowdsourcing toward Mass Participation

クラウドソーシングについて。多くの人が少しのコントリビュートを行うことで大きなことをできるようになりました。Wikipediaやmapなど。
スケールは大きく広がり、2billionのスマートフォンが、様々なデータを収集し、それらをオープンに共有することができるようになりました。
オンラインゲームで10日で得られるデータは、科学者が15年間探し続けてきたもの。50ミリオンのドライバーが地図の作成にコントリビュートし、トップコントリビューターはチームに入ることができます。
ハリケーンサンディの時も、人々の10,000に上るレスポンスから、ガスステーション情報の入手などの問題が解決されました。
各都市の自動車問題も、クラウドソーシングにより解決されていくでしょう。

Moh Haghighat – Bringing the Full Power of Modern Hardware to the Open Web Platform

JavaScriptは、本当に高速化されました。ここ数年で数百倍のパフォーマンスを示すようになり、ネイティブアプリとの違いも1.5倍程度の処理時間と、かなり接近してきました。CPUはマルチスレッド化が進んでいます。アプリケーションは並列処理に最適化されるべきです。レンダリングの33%は並列化されるようになりましたが、残りはまだ最適化の余地があります。SIMD – single instruction, multiple data。Javascriptに組み込むことでより高速化が促進されます。9-18fpsがSIMDを使うことで、30fps以上になるというデータも。Web Workerを使うことで100fps以上も可能です。
3Dカメラを使うことで、遠くのオブジェクトをフィルターし、最適化された映像処理を行うことも可能になります。
コンピュータ演算コストの高い、エッジ抽出を用いたモーション検出も可能に。モーション検出を用いたゲームも楽しむことができるようになりました。
Webは、今もっとも広範なクロスプラットフォームです。さらに、ユビキタスアプリケーションのプラットフォームになっていくことでしょう。

Alex ‘Sandy’ Pentland – Toward A Sustainable Digital Ecology

10年前に、最初のスマートフォンを用い地図上で、人々がどこに行くのか、どのレストランに行くのかをビジュアライズしました。データから、どのような生活をしているかがわかります。これは良いことですが、人々に恐れを感じさせました。政府は、それをハッピーと感じ、人々はそれから安心を得て、企業は収益を得る必要があります。
人々は、データをコントロールできなければいけません。削除可能でなくてはなりません。この機能がないと、経済は回りません。
これらのディスカッションを通し、私はp2pを活用した信頼されたネットワークというアイディアを思いつきました。クラッキングされることのない、信頼された。openPDSは認証からパスワードをなくします。”are you in california?”といったYes/No質問に答えることで。
データを集中せず、分散させることで、クラッキングの脅威を低減します。
データの分散を制御できるようになることで、子供の社会生活を向上することができます。プライベートデータは匿名化されることで共有可能となります。信頼されたネットワークを使うことで。

Commissioner Jessica Rosenworcel – Access for All

TEDのトークで、ティム・バーナーズ=リーより、Webのためにmagna cartaを作って欲しいと頼まれました。目の不自由な方が参加できるように、壁を壊さなければなりません。数週間前にスティービー・ワンダーが私を訪れました。スティービー・ワンダーは伝説的なミュージシャンというだけではなく、目の不自由な方への伝道師です。ビデオキャプションを作るためのガイドラインに関する法律を策定しました。
最大の問題は、文章を読めないこと。なので、OCRと音声合成機を用いています。彼のオフィスのスキャナーには全てOCR機能が実装されています。
ウェアブル、バーチャル・リアリティ、無人カー。グローバルスケールで、これらの技術がもたらすものについて考えなければいけません。165の国々でシンポジウムを開催しました。これはとても成功し、他国は興味を示しました。こういった活動を続ける必要があります。そして、数年後にはソリューションが得られるはずです。

Panel and Discussion: “The Future of the Web and How it is Run”

  • Lee Rainie (Moderator)
  • Fadi Chehadé
  • Jun Murai
  • Darren Walker

—

Lee
アメリカで、「Webは何を成し遂げたか？」というアンケートを取りました。生活の向上が 90%, 社会性の向上が 75%でした。
発展途上国へのインターネット普及は、更なる社会性をもたらしました。このようなチャレンジと変革のタイミングにおいて、どのようにそれを政治的に行っていくべきでしょうか？

Lee Rainie (Moderator)

Fadi
21世紀の政治システムは Web により様々なチャレンジが行われています。Web はパワフルで、我々はそれをコントロールしようとしています。もし我々が人々のパワーとWebによる拡散性を政府に認識させることを怠ったら、様々な問題が起こるでしょう。
もし、我々が価値を保ちつつそこに参加していく方法を見つけることができれば、素晴らしいWebを実現できることでしょう。
来年のThe General Asssembly of UNでは、コミュニケーションにフォーカスを置きます。
Webは人々の団結にとって最も重要な情報源として作用しています。我々は、挑戦を続けています。政府の役割を見つけるために。
さもないと、彼らは彼らの方針と司法権を行使してくるでしょう、万人共通となったときに。

Fadi Chehadé

Murai
この部屋の殆どの人はアメリカや日本などからインターネットがすでに普及している国々から来ていますが、グローバルスペース（発展途上国）へのインターネット普及を助ける責任をもっています。
グローバルスペースと、インターナショナルスペースの違いはなんでしょう？インターネットは最初にグローバルスペースを作った技術です。インターナショナルスペースで無く。

Jun Murai

Darren
私は理想郷と暗黒卿の間で、このような会話を見つけました。私からのクエスチョンは、民主化への人々の動員です。来年のUNで、我々は人々の動員についてのディスカッションを行うために何を考えなければいけないでしょうか？
市民権と人権をケアする人々はどこにいるのか？

Darren Walker

—

Lee
我々は、30ヶ国でインターネットの検閲について尋ねてきました。パキスタンだけが 100% のオープンインターネットを望みました。ほとんどの南アメリカの国々は 75% 程度でした。
インターネットの脅威と、コミュニティはいかにそれを解決しうるかをお話しいただけますでしょうか？

Fadi
インターネットのフラグメンテーション。現在部分的なフラグメンテーションは増加傾向にあり、人々の考えが伝えられていく流れを止めてしまいます。インターネット上での摩擦が多い国々はGDPが減少しており、人々の団結と経済に影響を与えています。
摩擦はISPによって起こります。かれらはコンスタントに攻撃を受け、会社は彼らの壁に囲まれたインターネットを作りたがります。我々は、法的に技術的に摩擦を削減する努力を行う必要があります。どこに摩擦が生じ、誰が責任者かを見つけ、それらと戦う必要が有ります。

Murai
フラグメンテーションは、最大の脅威です。別の脅威は透明性が無くなること。何度も人々は「インターネットは危険だ」と言い、切断すべきと言ってきました。

Darren
ポリシーと政治。我々は、最終的に人々に影響をおよぼす、これらの問題を解決する可能性を持つ構造を保有していません。科学者は課題と認識していますが、人々は、どこでこの議論をしているのか

—

Lee
人々はテクノロジーに精通していません。教育が語れることで、何が最も欠けているでしょう？

Murai
データを欲している人が誰なのかに関する誤解です。それは誰のデータなのか？所有しているのは、個人、建物、会社どれなのか。個々の産業は現在インターネットの上に存在しています。

—

Lee
人々からの期待に対し、何が最もフラストレーションを覚えますか？また、ICANで行いたい役割は何ですか？

Fadi
最も大きなフラストレーションは、ICANNがインターネットを運営していると人々が考えていることです。ICANNはとても目立つ存在です。故に、注目をあげ、収入を得ています。しかし、役割は制限されています。
他のフラストレーションは、インターネットを管轄するには、トップダウンモデルを取るしか無いと、人々が考えていることです。それは、インターネットが動いている仕組みに反抗します。
我々は、ガバナンスの他心性の上で仕事を進めています。たとえ、フランス政府がトップダウンレベルが必要であると考えたとしても。

—

Lee
人々が抱えている問題を気づかせるために、どのようにしたら良いと考えていますか？

Darren
指導は年間10億ドルの価値を、政策と戦い、民主化を推し進めることに与えられるでしょう。しかし、彼らは数十年に渡り、古い方法論を用いています。なぜなら、テクノロジーは彼らにとって脅威だからです。草の根運動の巨大なパワーは存在しますが、まだ未開発です。

—

会場より質問
マグナ・カルタなどは数百年以前のものですが、再度考慮する必要が有ります。インターネットは、境界で分割されていない共有の空間を作り上げました。

回答
2つのスタンスがあります：「政策立案者と協調的な関係を結ぶこと」と「政府が、保守的な体制をとること」です。テクノロジーによって、我々は政府を助ける必要があります。政府は敵ではありません。

—

会場より質問
我々は、インターネットを結合させるためにDNSに依存しています。しかし、それは毎年満了します。単一障害点となるのを防ぐために、より強化する必要があるのではないでしょうか？毎年お金を払うべきではないと考えます。

回答(Lee)
我々は、それの周辺で動いている金銭額がいくらになるのかを心配しています。最近のトップレベルドメインのオークションでは30ミリオンダラーを超えました。

—

会場より質問
トップレベルドメインの新しいコミュニティにより何がもたらされるとお考えですか？

回答（Fadi）
新しいトップレベルドメインには価値が芽生えるでしょう。ガバナンスへの影響として。アマゾンは、.amazon ドメインを買おうとしましたが、アマゾンの人々から嫌われました。.gay ドメインを欲する人は、全てのコミュニティにそれをさらけ出すことになります。

—

会場より質問
政府は、国家的な力を欲し、通常はそれはOKです。私は、データを何に使うかに関するコミュニティにいます。UNに行く前の文書では、それは公共のものであるべきと述べています。おそらく、我々はそれを基に進めていきます。

回答（Murai）
世界経済を考えた時、それはグローバルの課題です。インターネット上の個人を考えた時、既にグローバルです。ほとんどの国々は、世界中にマーケットを広げることで彼らの経済をのばそうとします。

回答(Fadi)
革命は、課題を帰着点で解決するためのプロセスです。これを進める際、2つの先導者がいます。一つは、世界のトッププレイヤーたち。彼らは通常、意思決定者としては参加しないことが重要です。これは良いことです。なぜなら、我々は彼らに従事することを望み、彼らは我々が Web に何を望んでいるかを聴くことができます。それ以外のサークルからは聴くことができない。もう一つの先導者は、物事をどう進めるかを決める人たち。技術面からではなく、政治家や法律家の視点より。現在我々は、これまでには見られなかったことですが、革命をボトムアップですすめている。


関連レポート

]]> Tech Crunch DISRUPT SF HACKATHON 2013 ライブレポート！！ /komasshu/2272/ Sat, 07 Sep 2013 20:35:02 +0000 /?p=2272 エキスパートNo.2の小松です。

本日から開催されているTech Crunch DISRUPTに参加するため、サンフランシスコに来ています。

Tech Crunchに先立ち開催されている 「DISRUPT SF HACKATHON 2013」。ただいま現地時間13時を過ぎたところですが、明日の昼までのオールナイトハッカソンイベントです。小松もあまりに楽しそうなので参加しています。ここでは、その模様をライブレポートしていきます。だいたい、2時間おきぐらいには更新していきたいと思っていますので（寝ちゃったらごめんなさい）、お楽しみに！！

開始前（13時ぐらい）

IMG_20130907_123120

会場外で、registrationを待つ面々

IMG_20130907_124216

会場内は多くのテーブル。まだ、開始前ですが熱気ムンムンです。

IMG_20130907_124207

会場奥には「DISRUPT」！！

IMG_20130907_124254

なぜか、シボレーが会場内に展示されています。。。。

IMG_20130907_124315

ハッカソンでは、各社(Dropboxとか)のAPIを使うのが推奨ですが、シボレーが車にアクセスするAPIを提供するようです。ってことで、展示されてるんですね。

IMG_20130907_130041

今回一緒にチームを組むYukioさんとKazuさん。といっても、3人ともそれぞれ違うアプリを作る予定ｗ。まぁ、話し相手って感じですね。

IMG_20130907_125807

何はともあれ記念写真。しっかり、日本で6/8に開催したイベントhtmldayをアピールしてます。これから24時間頑張りまーす！！

開始2時間半後（16時ぐらい）

ハッカソン開始後、2時間半が経過しました。テーブル囲んだり、地べたに座ったり、作るサービスのアイディアソンしているチームもいれば、黙々とコーディングしている人もいたりとさまざまです。全体的には、アイディアソンしている人より、最初からコーディングしている人が大多数という印象です。（僕は、30分ほど寝落ちしてしまいましたが……時差ボケとの戦い！！）

IMG_20130907_152142

最初の頃はオネェさんが回ってきて、空き缶とか持っていってくれたのですが、それもどこへやら段々とテーブルもいい感じに荒れてきました。

IMG_20130907_151102

API出展企業が会場両脇にブースを出したりしています。質問とかにも答えてくれたり。

IMG_20130907_155656

パイオニアさんが Zyprのブースを構えていました。スマートフォンで音声認識アプリを作るSDKを提供しており、これを使うとカーナビ（AppRadio3)と連携動作するアプリが作れます（審査を通る必要あり）。このSDKを使ったアプリ部門で一位を取ると「2,000ドル + AppRadio3」がもらえるとのことで、「ぜひ何かトライしてみてよ！！」とのことでした。小松は作るものを決めているので、今回はパスですが……。

IMG_20130907_154946

ちなみに、AppRadio3も展示されており、カーナビとスマフォを連動したサービスデモを見せてもらったりしました（スマフォの音楽をbluetoothで飛ばしてカーナビで流したりとか）。最近ChromeCastが出たりと、セカンドスクリーンサービスが脚光を集めていますが、カーナビとスマートフォンのセカンドスクリーンサービスも面白そうです。

開始後6時間ぐらい（19:30）

久しぶりにbootstrap使ったので「あれ、どう使うんだっけ？」とかひーこらしてたら、あっという間に6時間経過してしまいました。ここまででやったことは、ワイヤーをhtmlにしてbootstrapあてて……ぐらい、さてとここから頑張らないと。

チームメンバーのyukioさんも「やっとサーベイが終わったー。光が見えたー」とのたもうていらっしゃいます。ここから、いよいよ本格化。サンフランシスコはだんだん寒くなってきました（＞＜）

さて、このタイミングでお楽しみの夕飯タイム。まだ、夕飯を食べる体力は残っています。

IMG_20130907_190408

さて、食事を取りにいこうとするとすごい列！！Webサイトによると「800人のハッカーが一同に……」とのこと。

「いやー、これは食事にありつけるのは相当かかるなー」と待っていたら、親切な海外の方が「並んでるのこの列だけで、前行けばすぐに取れるよ」と教えてくれました。

IMG_20130907_190549

食事を取る場はこんなかんじ。夕食はメキシカンでした。

IMG_20130907_191911

僕が、盛りつけたお皿。盛りつけ方にセンスがないのはお許しを。結構美味しかったですよ。（デザートは、アメリカ仕様で無茶甘かったス）

IMG_20130907_192903

食べ終わった後、皿を捨てに行ったら、会場Wifiが無造作に置いてありました。ちなみに、Wifiつながりづらいです。あしからず！

開始後11時間（だいたい0:30）

予定では現地時間23:00ぐらいに更新しようと思っていたのですが、（自分でも情けないぐらいつまらないところに）ハマってしまい更新が遅れてしまいました。うーーーーー、くやしい orz　そんな中、チームのkazuさんのアプリがあまりにも凄くて・・・惚れ惚れしてしまいました。

夜になり、気温もかなり下がってきました。温度計見るといやになるので見てませんが、セーター着てないとやってられません。真面目に毛布欲しいです。会場のホットドリンク（お湯やらコーヒーやら）も底をついた様子。

でも、半袖でハックしている人がたくさんいる。。。。信じられない。。。気が付いたら人数が気持ちまばらになりました。終電に合わせて（カルトレインのサンフランシスコ駅が比較的近い）帰ったのかも。おかげで、だいぶWifiは快適になりましたｗ

IMG_20130907_212400

隣のチームが、地べたに基板置いて遊んでいるので、思わずパシャリしちゃいました。聞いたら、ラズベリーパイ経由でWebサービスとデバイスを連携させるんだとか。オチも聞いたのですが（あまりのくだらなさ……いえいえ素晴らしさに笑い転げてしまいました）、LT前なのでここではふせておきます。全く明日昼からのLTが楽しみで仕方ありません。

IMG_20130907_222549

スペシャルフルーツジュースの差し入れ by スポンサーが！！

IMG_20130907_222632

目にやさしいかな（時差ボケで、ホント目がしょぼしょぼなので）ということで、ブルーベリージュースを選びました。ものすごくドロッとした「濃いーーーー」ジュースです。結構美味しかったし、飲んだら気のせいか調子良くなった気がしました。こーゆー健康的な差し入れ嬉しいですね。

IMG_20130907_234647

さらに、アメリカでハックといえばやっぱり「ピザ！！」。小腹が空いたところを、（必要以上に）満たすことができました。ちなみに、ビールもサーブされているのですが、いろんな意味で呑んでる場合じゃないので（呑んだら、ソッコーで寝れる自信あり）、健康的にコーラで美味しくいただきました。

できれば、次に更新するタイミングでは「ひと通りできたーーーー！！あとは、細かいところを調整するだけ ;-)」と言いたいところですが、はてさてどうなることやら。

14時間経過（AM3時半ぐらい）

もうしばらくすると午前4時になろうとしています。なんだか、寒いんだかなんだかよく分からなくなってきました。なにはともあれ眠いです。

とりあえず、作ろうとしていたブツはひと通りできたので（やったーーーー）、祝杯しようとビールを取りにいこうとしたら既に片付けられていました……ま、まだ細かい調整とかあるし！！

去年は、これぐらいの時間に「ハーゲンダッツ」が振る舞われる摩訶不思議な自体が起きたらしいのですが、今年は極めて平和です。

IMG_20130908_033334

さしてUpするほどの写真も特にないのですが、全く何もないのも寂しいので、会場の写真。かなり閑散としてきました。

IMG_20130908_033503

Microsoftブースにも誰もいません。

20時間経過（AM9時半）

前回の更新のあと、、、告白します。2時間ほど寝てしまいました。

IMG_20130908_070238

地べたでとどのように眠るハッカー達

SONY DSC

小松は、こんな感じでお行儀よく寝てたようです。（撮影はyukioさん）

完全に地べたに雑魚寝。寒かった。。。。。あーーー、ベッドで寝たい。ちなみに、チームメイトのyukioさんとkazuさんは完徹 ( ｰ`дｰ´)ｷﾘｯ

IMG_20130908_070336

起きてしばらくすると、朝ごはんがサーブされました。ベーグルがいっぱい！！

IMG_20130908_070902

ホットドリンク（コーヒーなど）も準備され、冷えきった寝不足の体をいやしてくれました。やっぱ、朝はコーヒー！！

さて、ハッカソンタイムは9:30で終了。とりあえず、コーディングは完了。午後のLTに臨むのみです。

今年のLTの持ち時間は1分間。とにかく、一発芸を狙うしかありません。はたしてウケるかどうか、滑ったらどうしよう……ドキドキです。

21時間経過（10:30）

LTの順番が発表されました！！小松のタイトルは”SMILE NOW”順番は、、、、、262番!! なんと、最後の発表です！！イエーイ！！やったーーーー！！！・・・・・・・・・ドキドキドキ

IMG_20130908_102230

LT大会!!さて、その時小松は？

すみません、ライブレポートといいつつ、終わった後ホテル戻ったら倒れるように寝てしまいました。。。ただ今現地時間のAM2:00。時差ボケ中に24時間ハッカソンで、さらに体内時計がおかしくなった模様です。というわけで、遅ればせながらレポートの締めです。

AM11:00からいよいよハッカソンの成果を見せる、大LT大会が始まりました!!総勢265チームが一チーム1分間の持ち時間で入れ替わり立ち替わり。だいたい17時に終わったので、途中10分の休憩をはさみつつ6時間の長丁場でした。

IMG_20130908_141923

始まった時がこんな感じ。会場が満席近くまで埋まり、多分1000人弱の観客でもの凄い雰囲気でした。感覚的には去年の倍ぐらいの発表者で、観客の埋まり方も倍ぐらいになっているとチームのyukioさんから教えてもらいました。

IMG_20130908_142028

9歳の女の子がプレゼンしたり（多分、一番ウケていた）。

全体的には、大きく二つに分類され、

  • 各スタートアップによる自社のサービスを紹介
  • 24時間で頑張って作った

に大別され、（作りこみが明らかに違うので）完成度含めくっきり分かれる感じ。

内容としては、技術的に頑張るというより、ビジネスとして使えるサービスを作った人たちがほとんど。まぁ、中には僕みたいなキワモノも含まれつつ……

IMG_20130908_163327

僕の番は262番。最初順番が紹介された時は最後だったのですが、その後入ってきた人たちがいたようで、最後から4番目。これは、ステージ上からの写真です。 24時間かけて作りこんだものの、本番でまともに動かず……かなり残念な結果でした。くーーーーー

講演ビデオはこちら、あっという間に終わってますｗ

プレゼンで失敗したので、代わりにどんなものを作ったか軽く紹介。「気持ちを伝える」チャットです。

generic

ビデオチャットで自分の顔を伝えたくない時にも対応したもの。「SMILEモード」にセットすると、普通の表情の時は、相手には普通の表情のニコちゃんが表示されるのですが、、、

laugh

笑うと、ニコちゃんも笑う！！

yawning

さらに（24時間ハッカソン明けで 😉 ）うっかりあくびをしても大丈夫。この時もニコちゃん笑ってくれます。あくびをしたことがバレません！！

・・・・という一発ネタを狙ったのですが、ど滑りというより本番で上手く動かず、しゅーりょー・・・・・。

笑顔検出をWebでやるという技術的にはかなりとんがったことをしていて、表情検出にはclmtrackrを、笑顔判定にはsvm.jsを使い、サポートベクターマシンによる機械学習を用いて、自動判定しました。

Webでこんなキワい事ができるなんて、、、、発表はズタボロでしたが、そのうちどこかで詳しく紹介したいなぁと思っています。

さて、話は戻ってハッカソン。全ての発表が終了すると、API出展企業から各API賞が、さらに全体でのTop3がその場で表彰されました。確か、1位で5千ドル（あれ？5万ドルだったかな？？？）ぐらいの賞金。（ちなみに、発表すると3千ドルのTech Crunch入場が無料になる特典がもらえます。（1チーム2名まで））

この辺りは、今後Webサイトが更新されていくのかな？？？

今回は初参加で、いろんな意味で手探りでしたが、リベンジを兼ねて、来年もぜひ出たいな！！とゆー、とても素敵なイベントでした。なんか、不思議な一体感も生まれましたし、ホント楽しめました。

あと、日本でもこんなイベント開催したいなーーーー終わった後、エキスパートのあんどうさん、えーじさんとこんなTweetも。

スクリーンショット 2013-09-09 3.22.07

あっ、HTML5 Experts.jpでやればいいのか！！（と、自分とこのハードルを無茶苦茶あげるプレイ ;-)）

IMG_20130908_183022

何はともあれハッカソンも終わり、軽く打ち上げ。アメリカですし……ということで、リブアイステーキをチームメイトのkazuさんと美味しく頂きました。お腹いっぱい。

]]> リアルタイムにライブ映像をマンガ化「マンガテレビ」アーキテクチャ編 /komasshu/1649/ Mon, 26 Aug 2013 04:00:45 +0000 /?p=1649 「漫画家の先生をゲストに迎えた対談イベントで、“マンガ”をフィーチャーしたエンターテインメントを最新のWeb技術で作れないだろうか？」そんな思いから生まれた「マンガテレビ」。映像をリアルタイムで“マンガ化”するだけでなく、イベントをもり上げる各種機能が盛りだくさん。今回は、そのアーキテクチャを紹介します。

マンガテレビの紹介

「マンガテレビ」は最新のWeb技術をふんだんに活用し、イベント映像を“リアルタイムでマンガ化”するエンターテイメントツール。俗にいう「技術の無駄遣い」Webアプリケーションです。我らが、HTML5 Experts.jpの編集長「白石俊平」氏が開催している「（白石俊平と）カッコいいやつら」のイベント用ツールとして開発しました。

「マンガテレビ」を説明するのに言葉は不要。とにかく、サイトにアクセスしてみてください。ただし、Chromeでしか動作しません（後述のWeb Speech API利用のため）ので、その点ご注意ください。

スクリーンショット 2013-08-23 1.13.22

なお、初回アクセス時は、下図のようにカメラとマイクへのアクセスを確認するダイアログが画面上部に表示されますので、「許可」をクリックしてください。

スクリーンショット 2013-08-23 11.26.03

スクリーンショット 2013-08-23 11.26.21

かの有名アプリ「漫画カメラ」を最大限に「リスペクト」したことは一目瞭然です。なお、「マンガ化」のアルゴリズムはこちらのslideshare(スライド9)を参考にさせていただきました。

しかし、そのままリスペクトするだけではなく、Webならではの機能をふんだんに盛り込みました。

盛り込んだ機能は大きく二つ。一つ目は「みんなで『かっこいいね！！』」機能です。これにより視聴者参加型の「マンガテレビ」を実現しました。

スクリーンショット 2013-08-23 1.17.29

Webの特徴は、みんなが簡単に繋がれること。そこで、白石さん謹製の「かっこいいねボタン」と連携し、様々なエフェクトがかかるようにしました。「ボタン」を3回連打すると「ざわ・・」、5回連打すると「ゴ・・・」が画面を横切るという仕掛け。イベント参加者が「ちょっと、かっこいいね！」と連打すれば「ざわざわざわ・・」が、「すごい！！かっこいいね！！」と連打すると「ゴゴゴゴゴゴ・・・」と文字が横切っていきます。

スクリーンショット 2013-08-23 1.18.43

もう一つは、「自動吹き出し機能」。最新Webの目玉機能の一つ “Web Speech API” を使い自動認識した音声を、吹き出しとして表示する機能です。

スクリーンショット 2013-08-23 1.20.24

音声認識には誤認識がお約束ですが、その誤りっぷりが相まって、さらにエンターテイメント性を引き立ててくれています。なお、吹き出しの表示位置を調整するために、顔検出機能を利用しています。技術の無駄遣いっぷりは半端ではありません。

  • なお、自動吹き出し機能を利用する際には、#faceをハッシュ指定し、顔検出機能をONにする必要があります。

    • また、”WebSpeech API”による音声認識機能を応用し、音声コマンド機能も実装しました。例えば「バーン」と話すと、画面に集中線と「バーン」が表示されます。イベントの盛り上がりに欠かせない機能です。

    スクリーンショット 2013-08-23 1.21.45

    なお、開発メンバーは、筆者を含め HTML5Experts.jp 編集部メンバー4名で開発しました。

    マンガテレビ実装のポイント

    この「マンガテレビ」の実装のポイントを紹介します。本稿では、以下の4点について紹介します。

    • WebRTC と HTML5 canvas による映像のリアルタイムマンガ化
    • WebSpeech API による音声認識
    • headtrackr.js による顔検出
    • WebSocket によるインタラクティブ機能

    getUserMediaとHTML5 canvasによる映像のリアルタイムマンガ化

    最初に紹介するのは「マンガテレビ」の基本機能。リアルタイムで映像を「マンガ」にする機能の実装方法の紹介です。

    ステップは以下のようになります。

    1. WebRTC の getUserMedia() により、カメラから映像を取得する。
    2. HTML5 canvasのgetImageData() により、映像から画像データを取り出す。
    3. 画像データにフィルター処理を行い、マンガ化する。
    4. requestAnimationFrame() により、画像変換処理を繰り返す。

    WebRTC の getUserMedia() により、カメラから映像を取得する。

    まず、カメラから映像を取得します。これを行うためWebRTCのgetUserMedia()を使っています。(前述のとおり、Chromeを前提としているため、接頭辞 webkit を記述しています）

    $v_ = $("video");

    // カメラからのストリーム映像を取得し、videoノードのsrc属性にURL指定する navigator.webkitGetUserMedia({video: true, audio: false}, function(stream){ var url = window.webkitURL.createObjectURL(stream); $v_[0].src = url; $v_[0].play(); });

    取得するのは映像のみのため、第一引数のaudioプロパティはfalseとしました。第二引数は取得成功時のコールバック関数で、カメラから取得した映像はインスタンスstreamに返されます。ここで、「マンガ化」の変換処理を行うためには、一旦streamをURLに変換し、videoノードにsrc属性として指定する必要があるため、 createObjectURL()を用いています。また、video ノードは、play()をコールしないと映像再生が開始しないため、このタイミングで呼んでいます。

    HTML5 canvasのgetImageData() により、映像から画像データを取り出す。

    マンガ化する画像変換処理を行うためには、映像から画像のピクセルデータを取得しなければなりません。このため一コマづつcanvasに画像として書きだし、getImageData()により、取得します。

    var canvas = $("canvas")[0] , ctx_ = canvas.getContext('2d');

    // 映像の一コマを一旦canvasに画像として書き出す ctx_.drawImage($("video")[0], 0, 0)

    // canvasから画像のピクセルデータを取得する var imgData = ctx_.getImageData(0, 0, 640, 480)

    画像データにフィルター処理を行い、マンガ化する。

    取得した画像データに対してフィルター処理を行いマンガ化します。アルゴリズムは以下の通りです。

    1. 画像を黒・スクリーントーン・白の3階調化する。

    スクリーンショット 2013-08-23 1.27.21

    1. エッジ抽出を行い、階調画像に縁取りを行う。

    スクリーンショット 2013-08-23 1.26.57

    （階調処理やエッジ抽出の具体やコードについては次回の記事で紹介します）

    上記フィルター処理を行ったデータをcanvasに描画し、「マンガ化」された画像が表示されます。

    // 「マンガ化」フィルター処理後のデータを、canvasに書き出す。 ctx_.putImageData(toon, 0, 0)

    requestAnimationFrame() により、画像変換処理を繰り返す。

    上記操作を16msec毎にループ処理することで、60fpsで「マンガ化」された映像が表示されます(パラパラ漫画の要領です)。このような処理を行う際、これまでだと

    // doToon()は、映像の一コマを画像変換する関数 setInterval(doToon, 16);

    と、setInterval()を用いるのが普通でした。しかしながら、このコードでは、doToon()の処理に16msec以上かかった場合、処理がスタックしていく問題が生じます。ここで、requestAnimationFrame() を用いると、doToon の処理時間に応じ、画像フィルター処理が繰り返し実行され、適切なフレームレートでマンガ化された映像が表示されます。

    requestAnimationFrame(doToon)

    WebSpeech API による音声認識

    二番目に紹介するのは、音声認識機能です。認識した音声を吹き出しに自動表示したり、音声コマンドを使ったりするためにこの機能を利用しています。

    音声認識を実現するために、Chrome で試験実装されている WebSpeech API を利用しました。ちなみに、このWebSpeech APIはW3Cで正式なドラフトも出ていない実験的なAPIです。音声認識が簡単にできてしまうなんて、ほんとブラウザの進化は留まるところを知りません。今後、本格的な仕様化や実装が進んでいくことでしょう。楽しみですね。

    インスタンス生成後、start()メソッドをコールすると、音声認識が始まります。

    var rec = new webkitSpeechRecognition();

    rec.continuous = true; // 音声認識を継続する rec.interimResults = true; // 認識処理中の候補も返す rec.lang = 'ja-JP'; // 認識モードを日本語にする

    rec.start(); // 音声認識を開始

    音声が認識されると、’result’ イベントが発生します。認識結果は、SpeechRecognitionEventオブジェクトとして返されます。

    rec.onresult = function(ev) { for(var i = ev.resultIndex, l = ev.results.length; i < l; i++) { if(ev.results[i].isFinal) { // 音声認識が完了した var res = ev.results[i][0].transcript; // 音声認識結果 } else { // 音声認識途中 var res = ev.results[i][0].transcript; // 音声認識中の途中結果 } } }

    「マンガテレビ」では、認識結果の値をチェックし「バーン」や「ドーン」などの場合は、音声コマンドとして認識し、映像エフェクトを実施。それ以外の場合は、吹き出しに表示するといった処理を行っています。

    なお、イベント中講演者が話し続けているようなケースだと、ずっと音声認識中となり、認識が完了しないケースが頻繁に発生します。これを避けるため

    // 認識結果の文字列長が15文字を超えたら、認識を再起動する。 if(res.length > 15) { rec.stop(); rec.start(); }

    のように、認識結果が15文字を超えた時点で音声認識を再起動する処理を入れています。

    なお、再起動の際に、サイトのプロトコルスキーマがhttpsでない場合、毎回音声認識の許可を求めるダイアログが表示されてしまいます。注意してください。

    headtrackr.js による顔検出

    次に紹介するのは、顔検出機能です。音声を表示する吹き出しや、音声コマンドで集中線を出す際の位置を決めるために、この機能を利用しています。

    JavaScript で顔検出を行うライブラリーとして face.js が有名ですが、検出スピードに難があるため、より高速に動作する headtrackr.js を用いました。

    headtrackr.jsは、最初に顔検出を行うまでは低速ですが、一旦検出が完了すると、それ以降は検出した顔の周辺のみを検出対象とするため、face.jsに比べ格段に高速動作します。もちろんハードウェアに依存しますが、筆者の Mac Book Pro では、概ね30fps(frame per second : 1 秒辺りのフレーム数）が得られました。ただし、検出できる顔は一つのみとなりますので、その点は注意してください。

    Tracker オブジェクトのインスタンスを生成した後、検出対象のビデオ要素と、検出処理に用いるcanvas要素を指定し、start()メソッドを呼ぶと顔検出処理が始まります。

    var tracker = new headtrackr.Tracker({ui: false}); // uiをfalseにしないと、検出状態を示すテキストが表示される。 tracker.init($("video")[0], $("canvas")[0]); // 対象ビデオ要素と、検出処理用canvas要素を指定する。 tracker.start(); // 顔検出を開始する。

    顔が検出されると、’facetrackingEvent’ イベントが発生します。認識結果は、コールバック関数にfacetrackingEventオブジェクトとして返されます。

    document.addEventListener("facetrackingEvent", function(ev){ // ev.x, ev.y -> 顔の中心座標 // ev.width, ev.height -> 顔の幅と高さ }, false);

    これら顔の検出位置情報から、吹き出しの表示位置を決めています。

    WebSocket によるインタラクティブ機能

    最後に紹介するのは、インタラクティブ機能です。イベント参加者が「かっこいいねボタン」を連打すると、それがWebSocketで「マンガテレビ」に送られ、連打の数に応じて「ざわ・・」とか「ゴ・・・」などの文字が横断するエフェクトが動きます。参加者も一体になって盛り上がれるインタラクティブ機能です。この連打の数を「マンガテレビ」に送るために、HTML5の双方向通信機能WebSocketを使いました。なお、『マンガテレビ」では、socket.ioを用いているため、WebSocket が利用できない環境では自動的にHTTPポーリングにフォールバックします。

    「マンガテレビ」では、socket.ioを更にラップし、メッセージ受信をsubscriberモデルとしたZapper オブジェクト(白石さん謹製)を用いています。

    Zapperオブジェクトのインスタンスを生成し、connect()メソッドでサーバーへ接続。その後、’zap’メッセージに subscribe()すると、「かっこいいねボタン」の連打データを受信することができるようになります。受信データのcountプロパティに連打回数が入っているため、その値に応じて「ゴ・・・」や「ざわ・・」といったエフェクトをかけています。

    // 接続先サーバーを指定してインスタンスを生成 var zapper = new Zapper({ serverUrl: 'http://somewhere/' });

    zapper.connect(function() { var event = zapper.event();

    event.subscribe('zap', function(zap){ // zap.count に連打回数が格納されている }); });

    次回はパフォーマンスチューニング

    今回の記事では、筆者らが最新Web技術を駆使してイベント用に開発した「マンガテレビ」について、そのアーキテクチャを紹介しました。HTML5 の進化によりブラウザの世界観がさらに広がっていくことを感じて頂ければ幸いです。

    さて、「マンガテレビ」では、本稿で紹介した各種機能以外に、もう一つ大切な点が。それは「高速動作する」ことです。映像のマンガ化処理に時間がかかると、「マンガテレビ」はカクカク動いてしまい、イベントが興冷めしてしまいますからね。次回は、「マンガ化処理」を高速に行うためのパフォーマンスチューニング・ポイントについて紹介します。

    ]]>         WebSocket、WebRTC、ホームネットワーク、W3C標準化etc.通信エンジニアの習性は「何でもつなぐ」── 小松健作さん /komasshu/1134/ Mon, 19 Aug 2013 22:00:38 +0000 /?p=1134 連載： エキスパートインタビュー (2)

    エキスパートインタビュー第二弾は、小松健作さん。NTTコミュニケーションズでHTML5、特にWebSocketやWebRTCなどの通信系の研究開発、W3Cの標準化活動に携わっています。通信技術のエキスパートである小松さんに、これまでのキャリアと最近の活動を聞きました。

    Webのオープンに自由につながる世界観が大好き

    ──最近、WebSocketやWebRTCなどのWeb通信系に加えて、ホームネットワーク系のDLNA（Digital Living Network Alliance）に関する研究開発もされているそうですね。

    通信系のエンジニアって、何でもかんでもつなぐのが大好きなんです。通信系のAPIってことで、WebSocketをやってきたけど、それがホームネットワークにも広がってきたってかんじ。これまでのWebは自分の端末をクラウドのWebサーバと繋ぐパターンがメインで、ホームネットワークの端末同士を繋ぐ用途には殆ど使われてなかったんです。このような用途には、主にApple TVやビエラリンクに代表されるような、各ベンダーに特化した連携サービスが使われています。

    それが最近のWebではブラウザからテレビを操作するというような、ベンダーにかかわらず端末同士をオープンに繋ぐことができるようになってきました。オープンで自由につながるっていうのがすごく大好き。HTML5の中でも、Canvasなどの描画系技術も基本知識としては押さえているつもりだけど、どっぷりつかるのはやっぱり通信系ですね。

    ──なるほど。通信エンジニアの習性というか、好みを聞いたのは初めて。何でもつなぐのが大好きなんですね。僕的には、ホームネットワークとWebSocketって全然違う技術。なんで小松さんそこいったのかなと思ってたけど、「つなぐ」っていう共通点があった。

    なんでHTTPからWebSocketに飛び込んだかっていうと、HTTPって結構制約が多いじゃないですか。あくまでも文章をダウンロードするための用途っていうか。つなぐという意味では自由がない。WebSocketはその制約がなくなって、クラウドと自分のデバイスを自由につなげられる世界が作られる。そうなるとすごく楽しいなと。ホームネットワークについてもベンダーに特化した仕様ではなく、Webとオープンに自由につながる世界観ができれば自然に面白いことができるんじゃないかなって思ってます。

    磁気センサーからデータマイニングまで。幅広いキャリア

    ──小松さんって、キャリア的には通信エンジニアになるんですか？

    白石編集長

    白石編集長

    う～ん…自分の専門職が何なのか語るのは難しいなあ。大学の時は磁気センサーのデバイスの研究をしていました。会社に入ってからは映像配信システムやCDN（コンテンツデリバリネットワーク）など、どちらかというとインフラよりのネットワークエンジニアを10年くらいやってきました。

    でも新しいことがやりたくて、データマイニングの研究を始めました。テキスト解析など今で言うビッグデータに走ってましたね。そんな中、HTML5に出会いWebSocketで一番最初に作ったのがwakachiのデモ。当時社内の要望で、テキスト解析システムをHTTPインタフェースで作って欲しいと頼まれたんだけど、たった一つの文章でも下手をすると30秒ぐらいかかっちゃったり、これだと一億文書解析するのに100年かかっちゃう。それがWebSocketで処理すると、1時間か2時間くらいで分析できてしまう。WebSocketを使うと、簡単に業務課題を解決できると思って飛び込んだのが3～4年前です。

    ──小松さんはいろんなことをされてますよね。初めてお会いしたときは、Webサービス系をやってなかったでしたっけ？

    Webサービス系もやってましたね。NTTの中でいろんな会社を渡り歩いていますが、新サービスを立ち上げる担当を任されることが多かったんです。NTT東にいた頃は、フレッツとか、ひかり電話とか…。Webに関しては、やれって言われたわけじゃなくて、すごいと思って個人的にやってたら仕事になったかんじですが（笑）。今はHTML5に関する事業を社内で立ち上げる役目です。通信系のWebSocketやWebRTC、ホームネットワークとか…ざっと挙げただけでも結構あります。

    jQueryのように誰でも簡単に使いこなせる仕組み作り

    小松健作さん

    ──ホームネットワークでいろんなデバイスが共通のプロコトルでつながる話を聞きたいです。将来的にはあらゆる家電にWebサーバーが搭載されると、それを連携させる仕組みや標準化も必要になりますね。

    WebSocketやWebRTCをうまく活用して、リアルタイムコミュニケーションなどの双方向性サービスがもっと広がる形を作っていきたいと考えています。ただ、WebSocketやWebRTCを使うには新たにサーバーを立てなくてはいけないし、ネットワークの知識も必要だし、面倒なことが多いのも事実。そこを通信事業者としてサポートして、もっと気軽に使える環境を築いていきたい。例えばjQueryのように、誰でも簡単に使いこなせるようなもの。今のWebはjQueryが登場したからこそインタラクティブなものに発展しました。そういうチャレンジングな世界観を創りたいですね。

    ──その小松さんのビジョンには、すごく共感します。言葉にしちゃうとSaaSとかPaaS、BaaSになっちゃうのかもしれないけど、それとは違う。アプリを簡単に作れるようにとか、双方向に通信する次のWebを加速させるといったことのために取り組むという姿勢に感銘を受けました。WebRTCやWebsocketが当たり前の世界でないなら、あって当たり前の世界に変えていけば、Webがさらに進化する。時代の到来を早めようとしている気がします。

    僕、性格的にせっかちなんです。そういう世界を先に見たくて（笑）。

    標準化の活動。日本のデベロッパーにも参加してほしい

    白石編集長

    ──小松さんが主導で進められたW3Cの活動についても聞きたいです。日本人でWebの標準化について語れる人はまだあまりいません。小松さんはどんなマインドで臨まれているのでしょうか。

    世界から見ても日本のデベロッパーはとても高いポテンシャルを持っているのですが、これまでW3Cみたいな国際標準化団体を遠い存在に感じていたと思います。きっかけ、やり方のヒントがわかればそこに踏み出していけるはず。そう考えて、もっと世界に飛び立つための仕組みやベースを作りたかったんです。

    ──日本のWeb開発者とW3Cメンバーとの交流イベント「W3C Developer Meetup」をやってみてどうでしたか？

    日本の開発者は、これまでW3Cと接触する機会が殆どなかったわけで、それだけでも意義が大きかったと思っています。みんな楽しんでくれていたことに一番の達成感を感じました。今後はこのきっかけを継続する仕組みを作らないといけない。コードは世界共通言語なわけですし、英語が得意でなくても標準化に貢献できるような形も作っていきたいですね。

    いやらしいことを考えずにつぶらな眼（まなこ）で貢献をしていけば、何か成果が生まれてくるし、日本全体がよくなってくる。今までの自分自身の活動もそうですね。やらないより、やったほうが絶対よかった。「それって儲かるんですか？」ってよく聞かれるんだけど、金銭などのリターンを常に前提においてやっていたら今の自分はなかったと思ってます。

    エキスパートメンバーで有機的なコラボレーションを

    ──最後に、今後の活動や「HTML5 Experts.jp」に対する抱負をぜひ！

    エキスパートの人たちと意見交換や何かを作り上げたい。有機的なコラボレーションができたらいいですね。 執筆陣やレビュワー以上のつながりを作り出し、エキスパート同士のコラボでどんどん新たなWebの世界を引き拓いていきたいです！

    Screenshot_4
    [エキスパート No.2 小松 健作] 1972年生まれ。NTTコミュニケーションズにてネットワークとWebとの関わりや、インタラクティブマルチデバイスWebサービスに関する研究開発・標準化活動に従事。Google API Expert（HTML5）、Microsoft Most Valuable Professional（Internet Explorer）
    こてさきAjax – livedoor Blog（ブログ）

    ]]>         変わるWebプロトコルの常識（SPDY, HTTP2.0編） /komasshu/404/ /komasshu/404/#respond Tue, 09 Jul 2013 11:54:25 +0000 /?p=404 最新の各種通信プロトコルにより、Webの可能性は大きく広ろうとしています。今回は、それらの中から Web をより高速かつスケーラブルなものに変えていくプロトコル、SPDYとHTTP2.0 について解説します。

    SPDY, HTTP2.0

    HTML5の登場により、Webで使われるプロトコルは、 HTTP1.1 から大きく変わろうとしています。具体的には、SPDY, HTTP2.0, WebSocket, WebRTC といったプロトコルがそれにあたります。これらは、現状のHTTPが抱える各種問題点を解決するものです。

    しかしながら、これらのプロトコルについて、

    • いったい何であるのか
    • 今のWebの何を解決してくれるのか

    は、あまり知られていません。そこで数回に分けて、これらのプロトコルがいったい何であるのか、今のWebの何を解決してくれるのかを解説したいと思います。[1]

    今回は、SPDY, HTTP2.0について取り上げます。

    そもそも HTTP とは？

    まず、従来のWebプロトコル HTTP についておさえておきましょう。HTTPは Hypertext Transfer Protocol の頭文字をとったもの。その名の通り HTML (Hypertext Markup Language) 文書をサーバーからブラウザにダウンロードするために開発されました。ちなみに現在もっとも使われているバージョンは1.1です。

    このHTTPの特徴は、動作が非常に単純であることにつきます。その動作パターンは以下のようになります。

    1. ブラウザから、サーバーに HTML 文書を要求(request)する
    2. サーバーは、ブラウザに要求された HTML文書を返す（response）

    このため、HTTPは request & response型のプロトコルと呼ばれます。

    Webの進化に伴い、スピードの問題が!!

    Webが登場してしばらくの間は、このHTTPで全く問題がありませんでした。Webの初期は文書を表示することしかできなかったため、一つのHTML文書をダウンロードすれば良かったからです。

    しかしWebの進化に伴い、特にスピード面で問題が出るようになりました。多くのリソースをダウンロードすることによる、パフォーマンス上のボトルネックが生じるようになったのです。

    今皆さんが利用しているWebページは、多くのリソース（JavaScriptやスタイルシート, 画像など）から構成されています。例えば、HTML5 Experts.jpのトップページでは 80個のリソース から構成されています。これらのリソースを、HTTPを用いて 素直に 取得しようとすると、以下の様なパターンとなります。

    1. ブラウザから、サーバーに HTML 文書を要求する
    2. HTML 文書を取得したら、次のリソース（スタイルシート）を要求する …
    3. 最後の画像リソースをダウンロードしたら、それを表示してWebページが完成する

    つまり、request & responseの繰り返しが 80 回起きるわけです。もし、仮にサーバーからリソースをダウンロードするのに 1 回あたり、0.2秒かかったとすると 16 秒かかる計算になります。こんなに時間がかかっては、正直サービスになりません。

    このため、現在Webで使われている HTTP1.1 では、同時に送信するリクエストの数を増やすことで、ダウンロード時間の短縮を図っています[2]。運送業者にたとえるなら、80個の荷物を1台のトラックで1個づつピストン輸送するよりも、同時に複数台のトラックでピストン輸送したほうが早く終わる…という感じです。

    この解決策により、スピードの問題は著しく改善しました。現在のWebでは様々なテクニックを駆使し、10本以上の同時リクエストを送信することで、スピードの高速化を図っています。

    同時リクエストの乱用による新たな問題

    しかし、このようなHTTPの同時リクエストの乱用は、新たな問題を生むことになりました。サーバーやネットワーク機器の負荷を上昇することとなってしまったのです。

    先の運送業者の例で、伝え忘れていたことがありました。このトラックは、一本の車線を占有しないと走れないという困った特徴があります。これは、同時に10台でピストン輸送しようとすると、10本の車線が必要となることを意味しています。

    これは、あまりにも大変で、無駄が多いことは直感的にわかると思います。トラックに積荷を載せる倉庫は、多くの車線をカバーする大きなものが必要になりますし、途中の道路についても同様です。

    ここで、倉庫をサーバーとし、道路をネットワーク、車線をTCPコネクションとしたのが今のWebです。HTTPはTCPコネクションという車線の上を走るトラックに相当しますので、同時に送信するリクエスト数が増えれば増えるほど、TCPコネクション数が上昇し、サーバーやネットワークに過剰な負荷を引き起こします[3]。

    SPDY, HTTP2.0の登場

    このようなTCPコネクション数の乱用による問題を解決するために登場したのが SPDY, HTTP2.0です。これらの最新Webプロトコルを用いることで、スピードを高めつつ、サーバーやネットワークの負荷を下げることが可能となりました。

    そのアイディアは非常に単純・明快です。トラックでたとえれば、一台あたり一本の車線を専有してしまうのが諸悪の根源です。もし筆者が運送業者の社長であれば、運転手を説得し、全てのトラックを一本の車線で走らせることでしょう。冒頭の図面のように。SPDYやHTTP2.0についても、全く同様のアイディアです。複数のHTTPを一本のTCPコネクションで運べるようにしたのです[4]。

    最初に登場したのは、SPDYです。Googleが提唱した独自プロトコルで、ドラフト仕様が最初に公開されたのは 2009 年のことです。HTTPの多重化以外にも、HTTPヘッダーの圧縮やサーバープッシュ、フロー制御など高速化のためのさまざまな機能が盛り込まれています。

    既に、Googleの各種サービスや Twitter, Facebookなどの大規模サイトで実際に利用されており、運用実績があるのも大きな魅力です。ブラウザとしてはすでにChromeやFirefoxが対応しており、Internet Explorerの次期バージョン IE11 でもサポートされることから、今後更に普及することが予想されます。

    HTTP2.0の検討は、SPDYをきっかけとして 2012年に始まりました。SPDYのエッセンスを新しい HTTP のバージョンに盛り込み、HTTP1.1の様々な問題を解決した標準仕様を策定しようとする取り組みです。最初のドラフトは SPDY そのものでしたが、徐々にその形を変えてきています。今年度内には、テスト実装も予定されており、これをベースとして検討がより具体化されると予想されます。

    SPDY と HTTP2.0の関係・これから

    SPDYとHTTP2.0の関係ですが、SPDY/4では、HTTP2.0仕様の一部を取り込み始めています。短絡的に考えるのは早計ですが、SPDYとHTTP2.0は互いに影響を与えながら、あるべき次世代 HTTP の結論を導くことでしょう。

    ただし、SPDYがカバーしようとする領域は HTTP だけではありません。Webに関わるその他のプロトコル〜DNSやWebSocketなど〜もSPDYの中に取り込んでいこうとするアイディアもあります。こういった様々な興味深いトピックも、HTML5 Experts.jpでは今後紹介していければと思っています。

    [1] このシリーズは、最新Webプロトコルの入門編的な記事です。その後、より詳しいシリーズを執筆する予定です。

    [2] 正確にはHTTP1.1というより、現在のブラウザのHTTP実装がそうなっているというほうが正しいのですが、話が複雑になるので割愛します。

    [3] 例えばIPv4枯渇に伴い、特にモバイルキャリアのネットワークに CGN（Carrier Grade NAT）の導入が進んでいますが、このような振る舞いがCGNに大きなインパクトを与えています。

    [4] 多重化のアイディアは、HTTP1.1でもpipeline仕様として存在しているのですが、相互接続性の問題から実際には殆ど使われていません。

    ]]>     /komasshu/404/feed/ 0