Mozilla Vision 2012 – Conference Day

Mozilla Vision 2012 Conference Dayに参加してきたので、その時のメモです。(いつも通り正確性は保証されません)

NewImage

 

Boot to Gecko

B2G = Boot to Gecko

なぜ必要なのか

モバイルは閉鎖的すぎる

過去を振りかえる

  • 2002年 ブラウザの場合

IE のみだったので、拡張性はなかった。 拡張する必要がなかった

やがて複数のブラウザが登場して競争するようになった。 ブラウザ間で実装の競争が起こると

  • UXが良くなる
  • ユーザーはハッピーになる
  • 標準化も良くなっていく -> 書き手もハッピー

ブラウザとモバイル

モバイルプラットフォームは閉鎖的で、プラットフォーム側がコントールできるようにしている。

様々なプラットフォームに対応しようとするとそのプラットフォームに対応しないといけない -> 時間の無駄になってる。

プラットフォームを移行するとデータが移行できない。 このようなsilosがあるとオープンではない

これを変えるためにB2Gを作っていく。

Webプラットフォームができる事

オープンなものにするために必要なもの

  • オープンなApp Marketsが必要
  • プラットフォーム間を移行する際にデータも移行できる Firefox Syncのデバイスを超えた同期システム。
  • BrowserID

ネイティブアプリだと使えるケドWebからは使えないモバイルの機能があるのはWebのバグなども

Boo2Gecko

B2Gに必要なもの

  • iOS負けないUX
  • オープンスタンダートを構築する。B2G以外でも同じAPIが利用できる
  • Apps。Web自体がapp storeみたいなもの

デモ

  • ロックスクリーン、ホーム画面もWebアプリとして実装されている
  • 60FPS出るようにしている

電話ができるようにWeb APIとしてDevice APIを実装してある。 ネイティブコードではなくてWebの技術で実装されている。

ホーム画面もHTMLベースなので、ソースコードが見られる

  • Quake 3を使ったアプリ
    • WebGLのエンジン

クラッシュしたけど、直ぐ立ち上がる。

B2Gの実装

iOSなどのネイティブAPIの代わりに、Webエンジン/標準化されたDevice APIsがあり、ネイティブUIの代わりにWebベースのUIが存在する。

すべて再開発するわけではなく、Webレイヤー以外の部分は既存のものをサイっ利用したりする。

Gonk ( Androidのものも再利用) WebランタイムにMozillaは集中開発して、GPSなど他の部分に関してはAndroidのコードを利用する。

B2Gは何がしたい

  • モバイルをオープンにしたい
  • プランや開発やソースコードもオープンにしている
  • 作成したAPIを標準化したい
  • オープンなエコシステムを作成したい
  • Boot2Webkit など他の実装も作れるようにしたい
  • B2Gで動くものはB2Wでうごくようになるべき

一からはじめたプロジェクトではない。 Androidのコミュニティ

Q&A

Q どのようにして標準化していくのか。 それぞれの実装に対してそれぞれのUIがあるから、ポートする作業していく必要がでていく。 Gaiaに対してのUIのガイドラインが必要

A 標準化していくのはシステムのテーマ

Q non-nativeなものを場合、ゲーム等最大限の性能出すためにネイティブAPIを開発するの?

A ネイティブAPIを実装するつもりはない。 WebGLがOpenGLが遅ければそれはWebのバグである。 クロスプラットフォームを常に担保していくという目的を持っているので、少し遠回りでもWeb APIをやっていく。

Q アプリが落ちたときに他のシステムを巻き込むの?

A プライオリティの高いものを別のプロセスを走らせる事もできる。 OSがとても軽量なので、全てがダウンしても直ぐに起動できる。

電話のプロセスは別のものとして動いてるのでOSがダウンしても生きてる。 プロセスのセパレーションと呼ばれるものが実装できてる。

Linuxカーネルがあってその上にいくつかのXULや電話やBTなどのプロセスなどを起動していく。そして最後にB2Gのプロセスが起動して、その中でWeb Appが起動する。

Chromelessのようなイメージで、全てがiframeのようなものになって、iframeにマニフェストを与えて、iframeを別プロセスで動作させることができる。

Q どのようにB2Gを提供していくか? Mozillaがサポートするの?

A Mozillaは直接デバイスを出荷することはなく、 Mozilla Phoneパートナーと一緒してやっていく。 メジャーなキャリアとはやり取りを始めていて、最終的にそのキャリアが出していくことになる。

Q デバイスを買ってきて、OSとしてB2Gを後入れるということはできるの?

A 今サムソンのデバイスを使ってるが勝手に入れてる。 なので、将来的にはより多くのデバイスをサポートして行って、そのような事が可能になる

Web 標準の今、そして未来

Tantek Çelik

スライド : Open Standards Stories & Practices

CSSの標準化に参加したことについてのお話

  • ISO

買った上で誰でも見ることができる => 昔のオープン

  • CalConnect

お金を払った上にテストに参加できる。 テストスイートなのに、対象が限定されている。

W3Cはだれても見られるオープン

  • W3C tests

CSS WGはレポートを公開していたので誰でも見ることができた。 CalcConnectは公開してはいけないという縛りがあった

オープンなテストは再現性が担保されている

まだCSS WG不満があった

更にテスト、レポートをオープンにしていく必要がある。

  • Blog
  • Wiki

CSS WGのWikiを作成した。まだ閉ざされていた部分があったが、IRCやバグトラッカーなども公開していくようにした。

当時にメーリングリストはあったが、W3Cのメンバーでないとみられないようになっていたが、テクニカルな内容のものは全てPublicにしていくようにした。

  • editor ‘s drafts

これもエディターが書いてる途中のものも公開していくようにした。

  • last call

2011になってCSS2.1がやっとRCになった。9年もかかった。

CSS3の確固たる基盤になるCSS2.1ができた。

学んだ事

オープンは進化する

2. XFN

  • 2003年

SXSWという会議に参加した時の話。

ブログロールの仕組みについての会議で、ものすごく複雑な仕様になっていた。

rel=”friend”がついてればいいぐらいな簡単なものを提案した。

実際にどういう状態がfriendなのかについて調査した。

CC

XFNは初めてのCCライセンスを使ったオープンな標準化となった。 そこからフィードバックをもらってXFN1.1をリリースした。

rel=me

一番大きな6文字。自分を示すrel属性で、多くのSNSなどで使用されている。

rel=me , OAuth

２つを組み合わせることで、OpenIDをよりシンプルなものを実現できるでは?

XFNから学んだものは単純でシンプルであるべきということ

3. MicroFormat

  • rel=license

この時初めてMicroFormatという事が使われた

その頃はまだ標準に関するWikiがなかったので、Wikiで公開した。= 初めてのWikiで公開され知多Web標準

人を表現するhtml

classnameでつけていた習慣など、定義されていた言葉を元に定義した。

hcard , hcalendar

既にある用語を元に作成した標準。 既存のフォーマットを使用したので馴染みやすい。

Webレビューのフォーマット

いろいろ研究した

80/20の法則 : 比較などのある程度のフォーマットの表現が見えてきた

  • hreview

hreviewという標準化した

microformats.org

これまでの標準化団体とは少し異なる。

  • プロセスそのものを文章化
  • 今までの教訓を掲載した
  • IRCもオープンに
  • パブリックなログを公開

wikiがemail以上の公式な文章であるとした。 -> Wikiが厳格であるようにした

  • IRCに変更をとばすbot
  • スパムの除去

Wikiのイイ点としては同時に翻訳が行えるようになった。 今も標準化作業中に17ヶ国に翻訳作業がされている。

どんどんフィードバックを送る。標準化は誰でも参加ができる環境に翻訳は重要

Wikiは誰でも参加できる。W3Cは組織としての参加が必要になってる。

全てPublic domain / CC0にすることで全てがオープンであることを体現する。

microformats2

更にシンプルになるMicroformat。 ユーザーはシンプルなしようが求められる。

4. HTML5

  • 2004年

W3Cのワークショップが始まり。

HTM + CSS + DOM VS XHTML2 +XForms +etc..

これまでを進化させていく方向　VS W3CのXML

incremental VS replace

進化させていくと置き換えていくの対決

HTML VS XML は8:11でHTMLは負けた

ベンダーはHTMlの方を支持していた。MS,Apple,Mozilla等

Web自体は進化しないと行けない

WHATWGが設立

ここでHTMLは進化していった。

Web Apllication specがHTMl5になっていった。

Core+new APIsという構成はCSSも同じ

WHATWGはMITライセンスをしようした!!! これまであるライセンスを再利用した

W3Cは独自のライセンス – フォークが許されないライセンス

W3CとWHATWGの共通点

  • 要素

エディタを信頼する VS WG全体で協議する

というような対立が生まれてた。

5. W3C CGs (コミュニティグループ)

  • 2011年

2011にW3Cコミュニティグループができた

あるテーマに関するコミュニティグループは4人いればできる

CC0 & OWFa の仕様

Mozillaの弁護士にそれぞれ調べて持ったが、どちらもいい感じだった。 オープンに使えるライセンス。

仕様作成の10個のベストプラクティス

  1. オープンに作る(標準をオープンに作っていく)
  2. オープンに反復を行う(完璧じゃなくてもいいから試行錯誤を出す)
  3. オープンWikiを使う
  4. オープンに討議をする
  5. ブログ、Tweet、あらゆる手を使ってオープンに
  6. オープンなアーカイブ&ログ
  7. Wiki編集はIRCに投げる
  8. オープンテストスイート(堅牢、反復的に
  9. テストレポートをオープンにする
  10. 可能な限りコミュニティを巻き込む( 多くの人を巻き込む)

境界を超えた範囲で巻き込んだ作業をする。標準はグローバル

Q&A

Q MicroFormats以外に草の根的なものはありますか?

A OAuthはメーリングリストだけでできてきた

Q ベストプラクティスはWeb以外に対しても適応できる?

A 他にも適応できるだろう.

Facebookがオープンプラットフォームということをやろうとしている

Q W3Cのノンフォークライセンスだということだけど、コミュニティができてフォークが行われてる。W3Cが変わってきてるの?

A 今は２つの方向ができてきてる。 HTML5はまだノンフォークなライセンスになってる。

将来的には切り替わるかもしれない。

pdf.js — HTML5 と JavaScript の限界に挑戦する

なぜpdf.jsが必要なのか

信頼されたネイティブコードは脆弱性があると問題になる。

pdfに何が必要なのか

portableなのに巨大なフォーマット

  • Adobeのみが実装してるサブセットがある
  • pdfの一部サブセットを実装することを目的にした

圧縮されたpdfを戻して、パースしてdrawTextみたい形にしてレンダリングする。

Document -> ページとオブジェクトがある。

HTML/CSS/JS

  • JavaScriptはTyped Arrayなどを使用して高速化
  • Fast 2D Canvas、GPUで加速的
  • CSS @fant-face フォントに対応、ダイナミックにフォントをロードする機能
  • data: URI バイナリデータをJavaScript上で作れる

SVGなどを使わなかった理由もある。 = スピード

pdf.jsの手順

ダウンロード

バイナリデータをXHRでresponseTYpe = “arraybuffer”でダウンロードできる。

デコード、解読、パース

  • PNG,LZWデコーダーをJavaScriptで書いた
  • パーサーもJavaScriptで書いた

レンダリング

パースしたものをレンダリングしていくのが大変

  • 2D CanvasでLineやarcsなどを描いていく
  • bitmapもimgで描画する

問題

  • 2DCanvasは十分ではなかった。
  • Dash line等Canvasには実装されてなかった。 even odd ruleなどもそう

解決方法として2DCanvas自体を拡張していく

bitmap画像のデコードをサポートしてなかった。

  • img と Canvasはjpeg2000
  • フォーマットを追加するのは大変
  • JavaScriptでデコーダーを書く

フォントの問題

  • OpenType , TrueTypesなどブラウザはサポートしてないTypeがあった
  • Type1は一番PDFで使わてるのにCSS Font faceでサポートされてない

解決方法としてOpenTypeに変換して、中間フォーマット的にType1をサポートした。

まだまだやることはいろいろ

  • Shading fillはCSS gradientsで実装されてる
  • Image Mask はCanvasがネイティブでできる
  • PostScriptオブジェクト – PostScriptのインタープリタをJSで
  • TYpe3フォント PDF.js自体でレンダリングを行ってる

pdfをWeb技術でレンダリングする事に成功した。

デモ

  • Web技術で実装するとモバイルでも動かせる
  • フルのPDFレンダラーがブラウザ上で走っている

PDFビューアーのUI

UIを作っていく

  • ページビュー(サイドでページをプレビューする)
  • ハイパーリンクのサポート
  • テキストの選択 – 難しい
  • テキストの検索 – 難しい

ハイパーリンクの実装

2種類のリンク方式がある

  • 相互参照
  • 外部リング

Webブラウザが認識できるaリンクに変換した。 そのオブジェクトをpdf.jsでレンダリングした上にaリンクを重ねたものを表示して扱うようにした。

相互参照はポイントへ飛ぶようにしていて、バックボタンが機能するようになっている。

テキストの選択

Canvasは画素が並んでいるだけなので選べないが、オーバーレイに透過性を持ったdivタグでテキストを描画している。

アクセシビリティもサポートできている。

pdf.jsの高速化

コンパイル

pdf.jsはPDFのサブセットをレンタリング

  • PDFレンダラーはインタープリタだった
  • PDFレンダラーのJITコンパイルする switch等をコンパイルしたら省略できるので、直接draw*を呼べるようにできて十数倍の動作速度が得られる。
  • Overview of pdf.js guts < Chris Pitchin’ Hey

ダイナミックなコンパイレーションを行なってFunction()で実行してる。

Web Workers

Web Workersを使って別のスレッドで、デコード、パース、フォント変換、デコードイメージを行う。

  • main threadではdrawを行なっていく。(これはUIブロックを生む)
  • 別スレッドで実行してるものはUIブロックの影響されない
  • 同時併用でタスクを実行できるので高速化

pdf.jsの現状

  • 大部分の機能は完成している
  • Firefox,Chromeの拡張して利用できる

* HTML/JS/CSS Can redner PDFs *

next

  • PDF内のテキストを検索
  • HTTP byte-rangeリクエストを使ってPDFを分割ロード。メモリの削減になる
  • Web Worker内でCanvasをサポート。UIブロックを潰せる
  • (maybe) WebGLで高速レンダリング？？？ GPUをもっと使える

質問

Q なぜCanvasを使用したのか?

A JavaScriptが直接やり取りできる。SVGはDOMを経由しないといけないため、より早くするには難しい。

PDFではPDFファイルがあるのだからDOMを作成してやるのは不要だ。

Q 政府などでフォームとしてPDFを利用する場合。インタラクティブなPDFな方向はするのか?

A ２つのフォームフォーマットがある

  • Acro format – 標準化されてる
  • XNA format – プロレタリア

PDF.jsでも実装しやすい部類のもの。 AdobeではSpiderMonkeyベースのエンジンが使わていて、Validationが行われていたりする。

pdf.jsは100%のpdfのサポートするわけではないので、フォームなどのやり取りをべーすとするならばHTMLベースのほうがよいものになるかもしれない。

Q セキュリティポリシーについて

A pdf.jsの用途について

A メールクライアントなどの場合 HTMLのセキュリティポリシーに寄っていく(クロスドメインの問題がでるかもしれない)

Q テキストの描画方法

A PDFは左から右へ書けというようなコマンドが存在する。 まだ、サポートしてないが、Canvasの機能を一部利用かもしれない。

Q Canvasにテキスト選択を追加しなかった理由?

A Canvasにそれが実装されなかったのはとても管理が大変だったから。パフォーマンスとテキスト選択のトレードオフの結果

Q 対応するブラウザについて

A pdf.jsはオープンWeb標準を使って作っていくという方向から始まった。だが、ブラウザにはまだ実装されていない機能があって、その部分が拡張実装として、Firefox や Webkitに実装されていった。

dot line と even fill あたりが互換性ブラウザの問題を生んでる。 => スタンダートを追加していく

重要なのはTyped Arrayのサポートが大事で高速に動作するにはこれが必須。# LT

LT

“実践”Emscripten

  • Alon zakai
    • EmScriptenの作者
  • C, C++をLLVMでJavaScriptへ変換する
    • バイトコードになってそれをエミュレート
  • 手作業よりも少し遅いぐらい
  • まとめ
    • 2-4倍ぐらい遅くなる
    • 変換作業が短くすむ
  • JSViz
    • GraphVizを変換
    • アニメーション機能付き
    • グラフを考えるようにするのを視覚化

ブラウザプレゼンテーションの教育的利用

  • Nurota Lab.
  • 教師と生徒とのやり取りが必要になる。
    • 臨機応変に内容を変えられるようにする
    • 黒板以上のことをできるようにする
  • インタラクティブにコードを実行しながら事業を進行できる
  • Webページを埋め込むとかWeb技術を使える
  • 数学とか物理とか利用方法がある

Firefox Syncサーバを建てて見た

  • Firefox Sync
    • 保存情報をアドオンを同期する機能
    • Androidとも同期できる
  • Mozillaのサーバに情報が転送される
    • ローカで暗号化されてから送信している
  • Syncサーバを自前で建てて利用する
    • 証明書を用意してHTTPSでやり取りできる
  • Python, SQLite、Macurialで動く
    • ビルドして、コマンドだけ動く
  • いろいろ調整しないと動かないけど

Firefox 布教大作戦

  • Firefox を 灘高校 に広める
    • IE 83%のシェアな高校
  • Firefoxノートを1300部発注
    • 教員に止められた
  • 「布教」は簡単ではない

Firefoxのゴキゲンな通知UI

  • Popup Notifications
    • doorhangerがコードネーム
  • ノンブロッキングな通知UI
  • PopupNotification.show()
    • 6つの引数で設定
  • 通知の複数表示ができないバグ
  • ドキュメントが充実してない
    • コードはドキュメントになってる
  • まとめ

ドアハンガーをもっと簡単につかいたい! – Piro

  • PopupNotication.jsmの罠
    • CSSでアイコンの表示
    • コードバックをたくさん指定しないといけない
  • 簡単に扱えるライブラリを書いた

海外の開発コミュニティをを利用して世界デビューをしよう

  • Linuxに企業として参加
    • コミニティに参加していくには
  • ユーザーもどんどん参加する
  • 英語のレベルはあまりきにしない
  • 批判されても落ち込まない
  • 思いついたらすぐ投稿(反応を早く)
  • オープンにディスカッションをする
  • キーとなる人を早く見つける
  • まずは感謝

才能のソーシャルメディア

  • Stylelist DirectoryというSNSサービス
    • 才能のソーシャルメディア
    • 美容師のソーシャルメディア
  • 欧米だと美容師は芸術家的に個人活動
    • 日本だとサロン
  • 美容師が才能を発揮できるようなサイト
    • 活躍のアピール
    • 一般の人たちもそれらに反応
  • Joomla の CMSを使って運営してる
    • 他の業界とのコラボレーションとかやっていきたい

Scratchでつなぐオープンな学び

  • Openな学び
  • Scratch
    • 8 – 12歳向けのMITが開発してるソフト
    • 80万人ぐらいアクティブユーザー
  • デモ

Interop Tokyoでのオープンなネットワークエンジニア育成

  • Interop
    • ネットワークの国内最大のイベント
    • いろんな会社の機器を使ってネットワークを構築する
    • 超ネット
  • ShowNet
    • STMプログラム
    • インターネット技術者を育てる

まとめ

Web 標準の今、そして未来 by Tantek Çelik がとても面白かった。仕様を作っている側からの視点の話は結構貴重な貴重な気がした。

Mozilla飯よかった。

メモツール(セッションごとに別々のファイルで保存)