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

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飯よかった。

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

• Qute for PC/Mac
• Mou

イベントのページ: Mozilla 勉強会＠東京 6th
Twitterのまとめ: Mozilla 勉強会＠東京 6th – Togetter

• 14:30 – 15:00: 開場、発表者準備

• 15:00 – 15:10: Opening

自己紹介の流れ。

• コマンドの補完

Inspector

• 次世代のセキュリティポリシー
  • XSSの攻撃防止
• コンテンツ種別で読み込み制御
  • 画像やCSSやJSなども制御できるようにする
• Webkitではほぼ開発されてる

• デフォルトセキュリティポリシーがいろいろ強化される
• CSPの使い方
  • X-Content-Security-PolicyのHTTPレスポンスヘッダを送信
  • HTMLのメタタグは書き換えできたりするものだからヘッダーで
  • Apache でCSPの設定
• CSP対応に移行する
  • JS,CSSは外部ファイルに
  • evalを使わない
  • ポリシー違反レポートでどこがおかしいのかも確認できる
    • ヘッダーでレポートを報告するURLを指定してログを残せる
  • CSPブックマークレットもある

HTTP Strict Transport Security

• Do-Not-Trackヘッダ
  • ブラウザ側でサイトに通知する
  • IE,Safariも対応
  • Chromeだけ非対応
• 受け取ったらユーザー追跡をしない

• ALT
• back to owner tab
• Fox Splitter

restartlessのコードリーディング

• アドオン SDK を利用した初めてのアドオン開発– by knagato
  
  • 初めてアドオン開発する人が対象
  • SDKを使ったアドオン開発を特徴
    • HTMLやJavaScriptなどが中心で、XULやXPCOMなどMozilla特有の機能を使わなくても開発できる
  • 開発環境の種類
    • Add-on BuilderをWeb上での開発
      • 再起動不要なのでその場で試せる
    • Addon SDKを使った開発
      • コマンドラインベース
  • Add-on SDKのチュートリアル
• Thunderbirdアドオンによるワークフロー開発について– by Nakashima
  
  • 提案するツール
    • 自分自身でのプロセス改善が可能
    • やり取りの簡略化ができる
  • http://www.p2pwf.com/ に仕様の詳細
• Forking Secure Login – by saneyuki_s
  
  • Secure Loginアドオンのフォークの話
    • 現在はメンテナンスアップデートのみになってる
    • 全面改装してる
  • 一部機能の省略
  • レガシーコードの除去
  • doorhanger対応
    • Firefoxに入ってるSSLのポップアップするやつ
• jQueryで破棄されたrequestAnimationFrameとJSでのアニメーション実装で注意すること – by kyo_ago
  
  • requestAnimationFrame
    • setIntervalの問題点としてアニメーション向けではない
  • jQuery 1.6から削除された
    • setIntervalとrequestAnimationFrameが衝突してキューがたまる
    • タブがバックグランドにあるときの挙動
• ES.next WeakMap– by mooz (@stillpedant)
  
  • WeakMap = 連想配列
  • Firefox6から利用可能
  • {}やObject()と比較して
    • keyにオブジェクトが指定可能
      • ハッシュはkeyに文字列しか指定できない(toStringされてる)
      • WeakMapはkeyにオブジェクトが指定可能
        • オブエジェクトしか指定できない
        • プリミティブ値はエラー
      • オブジェクトの外部拡張
        • DOMノードに独自プロパティは危険
        • ES5ではオブジェクトの拡張がfreezeできる
        • オブジェクト自体は拡張しないで、外部に付加情報を持つ
        • WeakMapを利用する
          • キーとして外部情報をもたせる
    • keyに指定されたオブジェクトを弱く参照
      • CGにたいして
• Firefox4以降のE4X– by teramako
  • ワイルドカード
    • *が指定子に使える
  • 属性アクセス
    • @が使える
  • Firefox3.6までは上記のものがE4X以外でも使えた
    • Firefox4以降は禁止された
    • ざんねんでしたね

TwittterのログはTogetter – 「第3回 ブラウザー勉強会(#BrowserWS)のまとめ」にまとまっています。

第3回 ブラウザー勉強会

午前の部 :コミュニティー セッション

ショートセッション : kyo_ago  (http://tech.kayac.com/)
「Testで始まる物語（ストーリー） QUnit CUIの紹介」

[Ustream] [発表資料]

jQuery Plugin testフレームワーク

• 非同期実行されるコードのテストが面倒
• UIのテストが面倒

テストコードは次の３つから構成される

• テスト前のHTML
• テストするコード
• テスト後のHTML

コードにすると以下みたいな感じ。

<script type="dom/base" /> <script type="test/code" /> <script type="dom/comp" />

• iframe内でこれを行うので、セレクタなどの心配が不要
• 自動的にdiffをとれる
• 複数端末上で分散実行
• 複数ブラウザでの比較
• pluginのテストコードを生成

ショートセッション : はせがわようすけ 「Using Win32 API inside Chrome Extension」

[Ustream] [発表資料]

Chrome Extensionの構成

• HTML + JavaScript
• マニフェストとリソース

Chrome Extentionの制約を超える

NPAPI DLL – プラグインを書くためのもの

• OSに依存する
• Extension内にplugin DLL
  • リモートHTMLから直接利用は無理

マニフェストにdllのロードパスを書くだけで読み込める。

• 拡張の制約が超えられる
• 化石のようなもの

NPWIN32

何でも使える汎用DLL * JavaScriptから何でもできる

JavaScriptからネイティブコードを呼び出すことができる

• Windowsの方のalertを呼び出す
• デスクトップ情報の取得

NaCLとの違い * NaCLは OSネイティブの機能は呼び出せない。

ライトニング トーク : normalian さん (http://d.hatena.ne.jp/waritohutsu/)

[Ustream] [発表資料]

「ブラウザ戦国時代で考えるクロスブラウザなテスト方法（仮題）」

• ブラウザのバージョンアップ頻度が高くなった

• ブラウザレンダリングの差異

• JavaScriptのイベントハンドリングの差異
• HTMl5の対応状況の差異

jQuery & Modernizr

jQuery

• jQuery Core
• jQuery Mobile
• jQuery Template
• jQuery Validate

Modernizr

• ブラウザのHTML5対応度合いの確認

jQuery UIとjQuery Mobileはソースコードは一部流用されている。 混ぜると危険。

モバイルブラウザのタブの傾向と対策 -Androidスマフォを主に- saneyuki_s

[Ustream] [発表資料]

• モバイルブラウザのタブの傾向まとめ スマートフォンブラウザの「タブ」の様式にデファクトがない

• ウィンドウ式

• メニューからウィンドウを出して切り替える

• 画面下部に表示
  • Opera
  • Sleipnir Mobile
  • サムネイル付きが多くてわかりやすい
• 画面上部に表示
  • Dolphine Browser
  • タブレットでは一般的
• FIrefox Mobile式
  • サイドに格納する

番外

* IE9 Mobile – タスクスイッチャーと連動
* Sleipnir Mobile – タブグループ機能 -  面倒くさい工程

まとめ

様式は落ち着かないだろう。

Google Chromeはエンタープライズの夢をみるか : Hebikuzure

[Ustream] [発表資料]

• ユーザ権限でインストールできる
• 勝手にアップデートできる
• Google Chrome Frame

管理者が投げ捨てる可能性

Chrome にはグループポリシー機能がある

(Windows版について) Documentation for Administrators – The Chromium Projects

Chromum Projectの方に書かれてる

• HTTP認証の動作
• コンテンツの設定
• 検索プロバイダ
• パスワードマネージャー
• プロキシ
• ホームページ
• 拡張機能
• スタートアップページ
• Google Chrome Frameの動作(無効にできる)
• Google Updateの動作
  • Google製品の個別で自動アップデートの有無
• Google Installerによるソフトウェアのインストールの設定

Chromeのmsiインストーラーもある(?msi=trueでダウンロード)

• Active Directorで配布できる
• 特定のバージョン縛りができる

グループポリシーのテンプレート(ADM,ADMX)が配布されているので、グループポリシーの追加ができる。
PolicyDefinitionsというフォルダーにコピーする事で入れることでも読み込める

Q&A

• セキュリティアップデートも無効にできる

午後の部 : テーマ セッション 「ブラウザーと Web が描く『夢』」

加藤 誠さん (Mozilla Japan)
「Openness, Innovation, and Opportunity」

[Ustream] [発表資料]

Mozillaのミッション「Openness, Innovation, and Opportunity」

非営利法人が扱えるお金が制限されているので、Mozilla Corporationという株式会社ができた。

Mozilla Labsをメインに

• 実装だけではなくて、モックなどでもあり
• RUST 言語

• 将来のFirefoxで取り入れられることも

  • FIrefox Syncなど
• UI/UX
• WEB API

などがLabの範囲

Design Challenge

• 特定のテーマでデザインやモックでアイデアを募る
• アイデア(デザイン)の発表する場所
• 実装ではなく、あくまでもアイデア

Test Pilot

• ユーザーのブラウザ利用データーを取得して解析
  • 収集用のアドオン
  • 結果を公開
• データが偏る傾向があるため、偏りを取る手法を使う
• ユーザーのクリックするホットスポット調査とか

Prospector

• ユーザーが目的のサイトにたどり着くためのUXの模索
• Prospectorは実装ありきのアイデア

Firefox SHARE / F1

ソーシャルネットワークとの結合

Q&A

アップデートスピードが早くなったのはなんで? * Webの流れが早くなってる

UI/UXのアプローチ

• 目線の移動がおかしいとか
• 公開された議論してるので、おかしいとクレームがくる

検索バーとURLバーの統合について

• 一応Firefoxとしてもそういう議論がある
• ユーザーからのフィードバック次第になる。

Daniel Davis さん (Opera Japan)
「ブラウザの未来：HTML5の先には？」

[Ustream] [発表資料]

1899年に書かれた未来2000年について。

未来的なものを想像しても、洋服や建物が変化していない。

More than HTML5

Device APIs

• まだまだカメラでデータ取得は先だけど 。
• Web APIとARを連動してやるなど(Tweetの取得など)

逆にカメラにブラウザが乗ることもあり得る

More like a platform

Web on TV * ブラウザが載ってるTVも増えている * ブラウザはWebを見るためではなく、Appとして利用されてる * 多くのメーカーはSVGでUIを使ってる(レンダリングエンジンがブラウザ)

• TVのUI(user input = リモコン)は最悪
  • これが改善されないとWeb on TVが流行らないかも
  • ジャイロリモコン
  • キーボードタイプ

ブラウザの進化

• ブラウザによりUIが静的から動的に
• 動的からインタラクティブへ
  • ペーパーレス = 静的なものがまだ多い => マルチメディア

履歴書の事例 * 履歴書に動画を入れる * マルチメディアをもっと普通のドキュメントに使う

再生だけではなく、作成もブラウザで? * contenteditable * 今はまだ非力

ネイティブよりウェブ?

• JavaScriptは早く、パワフルになった
• 比較的に書きやすく勉強しやすい
• 100%オープン
  • ひとつの会社などにコントロールされてない
  • 未来的にそれはいいこと

未来の予想は人によって違う

• ウェブはひとつの団体にコントロールされないのが重要
• コントロールされないウェブは未来も一緒に作る

Q&A

ブラウザがいろいろなものに乗った場合、それぞれに対して最適なUIは異なるが、それを上手くやる工夫

• OSとブラウザは大きくは変わらない
• ブラウザを一番下において、その上に何かをかぶせて作らせれば異なるものに対して拡張を作りやすい。

春日井 良隆さん (日本マイクロソフト株式会社 UXエバンジェリスト)
「マイクロソフトにとってのWebって？」

[Ustream] [発表資料]

MSとしてIE6のシェアを減らすのに取り組んでいる。 @mskkie の中の人 with ミゾグチさん

管理者キット9(IEAK 9) * カスタマイズしたIEをパッケージ化、配布、管理するためのツール
なんとか版IEというのはIEAKでパッケージ化したものを使ってる

The Internet Explorer 9 Blocker Toolkit
WindowsアップデートやMSアップデートを管理するツール

HTML5 Native to WIndows

• ウェブの技術をネイティブに持っていく
• ウェブサイトをアプリケーションと同じように使う方向性

タブレットPCは失敗した…

HTML5+JavaScriptでアプリケーションを作る。

MSは同じ表示をするという基本思念がある。

Windowsはカーナビ専用のOSがある。

Windows Phone はIE9ベースのブラウザ

MSと携帯会社である程度端末の取り決めがある

• ボタンは3つを付ける
• 性能についても取り決めがある
• 解像度は固定

IE10は8-12週でリリースする。

MSはブラウザ固有の機能は付けない方向

IEの拡張性について

• IEはカスマイズは上げて行く方向ではない感じ
• 拡張を簡単に作る仕組みはまだ見検討

IE7について

• IE7さんはわすられています。
• まずはIE6からなくしていく。

IDE, Expression について

• Expressionはdevよりの作り
• デザインはDWの方がいいかも
• ExpressionはそっけないVisual Studioな感じ

• IE10は今年はでない
• Windows 8 がタブレット

• Hebikuzure’s Tech Memo
• Internet Explorer デベロッパーセンター
• Mozilla Flux
• Google Chrome OS & Chromebook Review Tips Themes How to Use Install and Learn

などを追加して更新しました。

後、alice0775さんのブログの内容(というかスクリプト群)がalice0775′s Profile – GitHubに移行していました。

翻訳許可のメールをわずか15分で返してくれた著者のJan Odvarkoさんに感謝を。
Thnak you, Jan Odvarko.

原文: Software is hard | Page load analysis using Firebug

ページ読み込みパフォーマンスはWeb開発者にとって重要なトピックです。
各ページロードの例において、FirebugのNet panelから得たデータをどのように解析するかを見ていきます。

このテストにおける例はFirefox 3.6 + Firebug 1.5 + NetExport 0.7においてのNet Panelの結果をNetExportによりHAR形式で出力したものをオンラインで表示しています。
(HAR形式はChromeのWeb Inspectorからも出力できます。)

• HTTP Archive Viewer 2.0.10(オンラインビューアー)

Example 1: Simple Page Load

ここでは2つのリクエストが表示されています。
1つめのリクエストではページは16msで取得できていて、load event (赤いライン)は58msで発生している事がわかります。ログ上にマウスオーバーさせると詳細な表示がされます。

• 青の縦線であるDOM Loaded はDOMContentLoaded event
• 赤の縦線であるPage Loaded はLoad event
• 灰色のReceiving がページの取得にかかった時間

同じように2つ目のリクエストを見てみると、5msでXHRが実行されています。
そして合計経過時間は408msであることもわかります。

2つ目のリクエスト(XHR)上でもマウスオーバーで詳細な情報が表示されています。
こちらでもload event を表していますが、こちらはXHRのリクエストからの相対値が表示されています。XHRが発生(Started)したのは403msなので 403 – 357 = 58msでload event が発生したことがわかります。(load eventはページの取得を見た方がわかりやすいからこう見る必要はない気がするけど)

Example 2: Connection Limit

各ブラウザは一つのページをダウンロードするのに同時接続制限あります。もし、同時接続の制限に達したとき、他のリソースは接続してるリソースが解放されるまでブラウザ内部のキューで待機させられます。
次の2つのページログを見ると、同時接続制限数の違いで8つの画像をロードするのにどれぐらいの違いがでるかがわかります。

#1 Cuzillion (同時接続制限 == 6)

• Firefox 3.6の同時接続制限のデフォルト値は6で、最初の6つの画像をダウンロード開始した時点でドキュメントは利用可能(DOMContentLoaded event が発生する)
• 他の2つの画像はコネクションが空くまで待っている(light-brown 色の部分がblocking部分)
• 他の2つの画像がダウンロードされたときは緑色のconnectionフェーズ無いのは、最初の6つの画像をダウンロードに使用したconnectionを再利用しているためです。

#2 Cuzillion (同時接続制限 == 2)

このテストだと、各画像ごとに2～3秒の時間がかかり、合計経過時間やload eventが発生時間に#1の2倍弱近くかかっていることがわかります。
同時接続制限が2なのはIE7以下のものやモバイル向けのブラウザなどがあります。
各ブラウザの同時接続数はHome – Browserscopeを見るといいでしょう。
Firefoxではabout:configのnetwork.http.max-persistent-connections-per-serverの設定から変更可能です。

同じように#2のポップアップされる詳細のログを見てみると、Blocking(light-brown 色)はページを取得(DOM Loaded)した時から4.63s待たされていて、リソースの取得は2.22sかかり、6.85sで完了している事がわかります。

Example 3: Pipelining

#2と同じページを使い、ブラウザのパイプライン処理がONとなっている場合を見てみる。

Firefox(3.6)でパイプライン処理が有効(network.http.pipelining == true)になっている場合を比べてみると、実際にはload eventが発生するまでにかかる時間が増えていることがわかります。
1から6の画像はそれぞれ異なる接続を利用していますが、7から8の画像は共有接続を利用してダウンロードしています。実際にどれと接続を共有しているかは明らかではありませんが(Firebugからそれを知るAPIはないため)、最後の2つの画像は接続を共有して合計時間を増加させているのは明らかです。

Example 4: Persistent Connections

このテストはHTTP Connectionヘッダーの効果を現しています。このヘッダーは既存の接続が閉じられているか将来のリクエストのために保持されているのかをサーバーに教えるために使われます。
それぞれKeep-Alive (default in HTTP/1.1) or Closeでどのような違いが出るかを見てみましょう。

それぞれのログで、最初のページと3つのリクエストとで合計4つが表示されています。
Connectionヘッダーは3つ(file1.php, file2.php, file3.php)のリクエスト時に要求されます。

#1 Test page (Connection: Keep-Alive)

• 一つ目のページのログでは、ページダウンロードのための一つの接続しか作られていないことがわかります。緑色のConnectionフェーズが一つだけになっていて接続が再利用されている事がわかります。

#2 Test page (Connection: close)

• 二つ目のログでは、ページダウンロードとfile1.phpのリクエストで接続が再利用されている事がわかります。しかし、他の接続ではConnection: closeなため、また接続を作り直す必要があります。

Example 5: Inline Scripts Block

インラインスクリプトがページのダウンロードをブロックすることはよく知られていますが、ネットワークの観点から見るとどのように見えるかを調べてしましょう。

#1 Cuzillion

3番目と4番目のリクエストの間に隙間ができています。これは5秒間のインラインスクリプトの実行によりブロッキング発生しています。 (*ここで言うインラインスクリプトとは<script>/*実行スクリプト*/</script>という感じで<script>タグ内で実行しているものを言う)
Inline Scripts Blockのページにて試すことができます。

Firefox5に試すとちょっと挙動が異なるけど、インラインスクリプトで隙間ができるのは同じ。
どちらかというとChromeがログに近い動きをしていた。
Firefox4からインラインスクリプトの実行タイミングが変わったのも関係するかもしれない。
詳細はSoftware is hard | Script Execution Analysis in Firefox 4に。

#2 Cuzillion

こちらはインラインスクリプトをページの底(</body>前かな?)に置いた場合のログです。
リクエストの合計時間は減っていますが、load eventは#1と同じくインラインスクリプトにより遅れていることがわかります。
こちらはCuzillionのようなイメージだと思います。

特にこれをどうとらえるべきかについては元記事に記述はありませんでしたが、この例はリソースのダウンロード時間よりもload eventなどへブロックが発生している事が重要な気がします。
負荷が大きいインラインスクリプトやdocument.writeなどのブロッキングを誘発するものがある場合loadやDOMContentLoadedイベントの発生を遅くしてしまいます。そのためdocument.writeそのものを避けることや、load eventなどイベントリスナーにして実行させるなどした方がページの表示は速くなるかと思います。

Example 6: Redirects

これはネットパネルにて、リダイレクトがどのように見えるかを表示した例。

#1 Final Page (one redirect)

サーバーによって301リダイレクトが行われて、URLの末尾に/がついたことがわかります。

#2 Final Page (infinite redirection)

無限ループしているリダイレクトの例
自分自身にリダイレクトしているのでいつまでもループしてしまいますが、Firefoxではデフォルトで20回で停止しています(network.http.redirection-limit の設定値)

こうすれば、タブを開くだけでJetpackのコマンドが読み込まれて便利。

Shellにnyaosとかを使う方法はよく分からない。

• インストール – Jetpack SDK – あすかぜ・ねっと

現在のFirefox4に正式対応しているのはFirebug1.7xで、Firebug1.8xはAlpha版として公開されているのでまだ不安定な部分もあることに注意して下さい。
特に注意書きしてない部分はFirebug1.7の項目だと思って大丈夫だと思います

コマンドラインに履歴ボタン

コンソールパネルでのコマンドエディタ(でかい方のコマンドライン)にHistoryボタンが新たに追加されました。
過去に実行したコマンドをポップアップから選択して挿入することができます。(以前はCtrl+ZでUndoし続ける必要があった)

コマンドライン(小さい方)も同様に履歴ボタンが存在します

スタイルサイドパネルの表示が細かく制御できるように

CSSパネルにあるスタイとるサイドパネルの計算済みスタイルでアルファベット順のソートができるようになりました。
そのため並び順でどのようなスタイルが適応されているのかが見やすくなりました。

同じくスタイルサブパネルにて、Only Show Applied Stylesフィルターが追加されました。
これは重複して適応されているものなどを非表示にすることで、実際に適応されているスタイルが見やすくなります。

• Getfirebug Blog » Blog Archive » Firebug 1.7b1

コンソールの実行結果の表示形式が変更

コンソールの実行結果の表示にてglobalStorageオブジェクトにも対応しました。

それに伴ってDOMパネルにおいてDOM Storage(global, session, local)の表示に対応しています。

また、以前はDateオブジェクトをコンソールに表示すると、DateをtoStringした値が表示されていたのがちゃんとDateオブジェクトとして表示されるようになりました。

この辺のコンソール実行結果の表示形式の変更に伴ってか、http://jsfiddle.net/efcl/zVFdd/3/ のようにconsole.log()の返り値が_firebugIgnoreとなっています。これはconsole.log(“hoge”);でundefinedが返ってくるとログ画面にundefinedが表示されてしまうので、仮の値として_firebugIgnoreを返してログ画面ではそれを無視しよう的な方法がとられているため、undefinedではない値を返すようになっているようです。(FIrefox4 +Firebug1.7以降)
なので、console.logがundefinedを返す事を期待するのは少し危険です。

• Re: Test results for Firebug 1.7 + Firefox 4 combo

Break時のメッセージUIが変更

JavaScriptやHTMLの変更に対してブレークポイントを打った際にBreakした事を知らせるメッセージUIが変わりました。
以前よりわかりやすい表示になりました。

ファイルの指定行数目にジャンプ

エディタではよく見られる、JavaScriptやCSSなどの指定行数にジャンプする機能が検索バーに追加されています。

検索バーに #行数 と入力する事で指定行数にジャンプすることができます。

メモリプロファイラー

Firebug1.8a2にてメモリ使用量の変化を見るメモリプロファイラーが実装されました。

これはabout:memoryと同じAPIを使っていて、Firefox4からJavaScriptのヒープメモリなども取得できるようになったのに基づいて作られています。以前書いたJavaScriptからメモリ情報を取得する方法 | Web scratchでのWebkitに実装されているconsole.memoryに近い感じの値がとれるようになったと思います。
メモリプロファイラーはボタンを押してから次にボタンを押すまでのメモリについての変化を見る機能となっているようです。Firebug1.8aを入れた状態でTest Case for Issue #4376にて実験することができます。

このメモリ監視機能は元々MemorybugというFirebug拡張として開発されていて(Firebugの実験的機能は別アドオンとしてくられることが多い)、それがFirebug本体にポートされ始めたものだと思います。将来的にはコンソールAPIにconsole.memoryProfile()などのメモリプロファイル操作APIが追加されると思います。

• Firebug Memory Profiler – FirebugWiki

DOMパネルの表示が細かく制御できるように

同じくFirebug1.8a2にて、DOMパネルにshowOwnProperties と showEnumerablePropertiesのフィルタオプションが追加されました。
showOwnPropertiesはprototypeチェーンの表示を決めるフィルタで、showEnumerablePropertiesはenumerableなプロパティの表示を決めるオプションとなっています。スタイルサイドパネルと同様にDOMパネルにおいてもフィルター機能が充実してきているようです。

ここで書かれている内容はほとんど

• Firebug 1.7 New Features ✩ Mozilla Hacks – the Web developer blog
• Getfirebug Blog
• Firebug Release Notes – FirebugWiki

に載っている内容です。
今回書いたもの以外にも変更点はあるので上記のサイトを読むといいです。
動画で見るFirebug1.6の変化も What’s new in Firebug 1.6 on Vimeo

蛇足

Google ChromeのJavaScriptデバッガの進化がすごい – 0xFFが元ネタなので、それと似たようなアドオンの紹介。

圧縮されたコードの整形

IE9の開発者ツールに実装されていたJavaScriptコードの整形機能はJavascript Deminifierというアドオンによって行う事ができます。

たとえばGoogleのJavaScriptは圧縮されているため普通は読めませんが、

JSBボタン(Javascript Deminifierをインストールするとステータスバーに表示)をONにする事で

このように整形してくれます。
これはリロードした際にも維持されているので、整形した状態のJavaScriptにたいしてもブレークポイントを打つことができます。

これで圧縮されているライブラリの確認も楽にできます。

Firebugをエディタにする拡張

Firebug AutocompleterはFirebugのコマンドラインに自動補完機能をつけてくれます。
コマンドライン(小さい方)は公式にも一応ついていますが、コマンドエディタに対してもポップアップして表示される自動補完機能をつけてくれます。

AcebugはFirebugのコマンドエディタをAjax.org Cloud9 Editorのものに変えてくれます。
Syntax Highlightingや自動補完やファイルからロード、セーブなどエディタさながらの機能をつけてくれます。
少し重たいですが便利です。

そのほかにもjQueryに特化したFireQueryやリッチUI系のExtJSやSproutCoreなどのライブラリに特化しているIlluminations for DevelopersやRuby on Railsに特化したRailsBugなど様々なFirebugアドオンがあります。
後、FirebugはIndex of /releasesあたりに新しい機能や実験的なものをFirebug拡張として分けて置いていることが多いです。その中には要素に適応されているイベントを表示するEventbugやCSSパネルでCSSが適応されてる要素を表示するselectbugなど結構便利なものがあります。(いずれFirebug本体に載るのかもしれない)

• Firebugを拡張するアドオンをまとめてみた | Web scratch

表面的にはFirebugはそこまで大きく変わっていないように見えますが、少しづつ内部の整理も入ってきているため、Firebug拡張も作りやすくなるようです。

IE、Firefox、Chrome&Safari、Operaとブラウザ自体も大きく変化していきますが、その中のデバッガもいろいろな変化が起きています。それぞれのブラウザでいい機能はどんどん取り入れて(パクって)いってもらいたいですね。

• Downloads: All Versions of Firebug : Firebug

追記

タイトルにJavaScriptデバッグとあるのは元ネタに合わせてみただけですが、Firebug1.7はCSS関係の機能が結構拡充されてる印象。

アイコンが…ってのはFireBugのアイコンを置き換えようじゃなイカ : Firefoxをイカ娘が侵略プロジェクトなんてのもあるんじゃなイカ
userChrome.cssとかStylishでアイコンぐらいなら簡単に差し替えできるよ(アップデートの度にやり直さなくてもいいという利点も)

• UrlCleaner for Greasemonkey
• FeedBurnerのトラッキングパラメータらしきものを削るGreasemonkey – ariyasacca(2009-11-18)
• URLのトラッキング用パラメータを無視するFirefox拡張 Through utm_ – SWDYH

history.replaceStateを使う事で他のものに比べて簡潔な処理でURLからトラッキングパラメーターなどを消せます。
またhistory.replaceStateを使ってるのでFirefox4以上向けで(一応Firefox3でも動くようにしてある)、Scriptish向けに最適化してあるので、できればScriptishで使った方がいいです(Greasemonkeyでも動きます)

• GreasemonkeyからScriptishへ環境設定を移行する | Web scratch

history.replaceState(data, title [, url])の使い方

historyオブジェクトについてはgithubなどで話題になったので知ってる人も多いと思いますが、pushStateはブラウザの履歴に新規エントリを追加するAPIで、replaceStateは現在のエントリを入れ替えるAPIです。
引数はpushState()と同じで、

history.replaceState(stateプロパティに入る値, 状態識別用のタイトル, [現在の状態に対応するURL]);

という引数をとります。
第三引数を指定してSame OriginならURLバーの表示を書き換える事ができるので、以下のように実際に移動しなくても表示が書き換わります。

// http://example.com/ で実行
history.replaceState(null, "", "/hey");
// => http://example.com/hey とURLバーの表示が変わる

• history.pushState、history.replaceState – 素人がプログラミングを勉強するブログ
• Firefox 4 での History API の変更 « Mozilla Developer Street (modest)

これを使って、今回はトラッキングパラメーターが存在するURL(アイテム – データベース: UrlCleaner – wedataで管理)にアクセスしたとき、トラッキングパラメーターを除去したURLへhistory.replaceStateを使って書き換えているので他のGreasemonkeyのようなリロードがなかったり、アドオンのように通信を監視する手間が省けます。(以前同じ名前でアドオンを作ってたけど重すぎた)

UrlCleanerと同じWedataで管理されたものを勝手に使ってるので、処理自体は互換性があるようにしています(一部拡張してるけど) 気になったものがあったらSITEINFOを書いて、UrlCleaner – wedataに登録するとよいです。

ParamCleaner for Greasemonkeyi

http://userscripts.org/scripts/show/100611

PCに入ってたランタイムは2008ぐらいのだったので、Microsoft Visual C++ 2010 再頒布可能パッケージからランタイムをダウンロードし、インストールし直したら動作するようになりました。

ついでに広告配信先が変わって動かなくなってたUstreamのFlash動画内広告を消す方法もアップデートしました。

BENKIi

http://park2.wakwak.com/~benki/index.html

自分はEmacsユーザーでもありませんが、KeyConfigの代わりにKeySnailを使い始めました。
そもそもKeyConfigとは役割違うし、KeyConfigもFirefox4対応したので併用しています。
keysnailはuserChrome.jsのキー特化みたいな存在で、便利なAPIがある環境みたいなとらえ方でもいいかもしれないです。(emacsのキーバインドは一切使わないで、まっさらな状態で始めました)

KeySnailのプラグイン開発について

JSReferenceというMDN(MDC)やECMA-262 3rd EditionをKeySnailのプロンプトから検索できるプラグインを書いたので、これに沿って説明していきます。

こんな感じの動作するやつです。(フルスクリーンで見た方がいい)
端的に言えばChemr-jsみたいな感じでインデックスをキャッシュしてリファレンスを検索するものです。

KeySnailのプラグイン開発の情報元

• KeySnailのgithub wiki
• 作者ブログ
  • mooz deceives you
  • きすねた(ん) – keysnailグループ
• keysnailグループ(はてなグループ)
• タグ「keysnail」を含む新着エントリー – はてなブックマーク
• KeySnailのソースコード(content at master from mooz/keysnail – GitHub)

KeySnailのプラグイン開発についての情報はドキュメントが不足(分散)している印象を受けるため、wikiに情報を反映させたり(github wiki使いにくいのでもっと他のがあるといいのだけど)、ブログなど開発手順を記したりすると他の人のためにもなると思います。

メタデータ

まずKeySnailにはドキュメントも表示できる優秀なプラグインマネージャーとGUIでも追加したコマンドなどの管理ができる(.keysnail.jsを直接いじるのも可能)ため、プラグインを作った時にはメタデータが結構重要です。

プラグインマネージャー

GUIで管理できるキーマネージャー

プラグインはJavaScript(拡張子は .ks.js)で書きますが、プラグイン内部にE4Xを利用してメタ情報を含めることができます。(是非入れて)
メタ情報の書式はWriting Plugins (Japanese)に詳細に書いてあるので、これと他のPluginをまねるのが早いです。E4Xで書くのでプラグインの詳細な情報を入れるdetail内には簡単なWiki記法を使ってプラグインの詳細を書くことができます。

<detail lang="ja"><![CDATA[
複数行のヒアドキュメント
のような書き方ができる。
簡単なWikiみたいな記法も使える

見出し:
    - == heading1 == で第一見出し(h1)
    - === heading2 === で第二見出し(h2)
    - ==== heading3 ==== で第三見出し(h3)
整形式テキスト:
    >|| と ||< で囲むと整形式テキスト(pre)になります。
    コードなどを書きたい場合に使用できるでしょう。
など
 ]]></detail>

自分の書いたJSReferenceでは以下のようなメタ情報を書きました。

var PLUGIN_INFO =
        <KeySnailPlugin>
            <name>JsReferrence</name>
            <description>JavaScriptリファレンスを引く</description>
            <updateURL>https://github.com/azu/KeySnail-Plugins/raw/master/JSReference/js-referrence.ks.js</updateURL>
            <iconURL>https://github.com/azu/KeySnail-Plugins/raw/master/JSReference/MyIcon.png</iconURL>
            <version>0.0.1</version>
            <author mail="info@efcl.info" homepage="http://efcl.info/">azu</author>
            <license>The MIT License</license>
            <provides>
                <ext>JsReferrence-open-prompt</ext>
                <ext>JsReferrence-reIndex</ext>
            </provides>
            <detail><![CDATA[]]></detail>
            <detail lang="ja"><![CDATA[
            === 使い方 ===
            ....略.....
            ]]></detail>
        </KeySnailPlugin>;

それぞれの属性についてはWriting Plugins (Japanese)を見ればいいので飛ばしますが、E4Xを利用しているのでプラグイン内部からこれらのメタデータを利用する事もできます。
たとえば、プラグイン内部からname(JsReferrence)を取得したいと思ったら、

var name = PLUGIN_INFO.name.toString();// JsReferrence

という風に参照することができます。詳しいE4Xのプロパティやメソッドについてはrephrase § E4Xが詳しいです。
E4X自体については以下にリンクをいろいろまとめてあります。

• E4XとDOM – prog*sig

以上でメタデータについては終わりですが、アップデートURLやアイコンURLなども指定できてとてもいい感じにできてると思います。

デバッグ方法

自分のデバッグ方法を書きますがもっと効率のいい方法があったらお知らせくださいな。
まずKeySnailにはいくつかのデバッグ関係に使えそうなのAPIがあります。

util.message("format", [args...]); // コンソールにログを出力
display.showPopup(title, msg, [options]);// Growlみたいな通知(Firefoxの通知のやつ)
display.prettyPrint(msg, [options]);// DOM内にポップアップで出力
display.notify(aMsg, aButtons, aIcon);// ページ上部に出てくるインストールButtonみたいな感じ

display.prettyPrintは以下みたいなのが出ます。

display.prettyPrint

他のutil関係のAPIはutil.js – GitHubに載っています。(ただこれがkeysnail API全部ではなくてドキュメント化されてないものも含めて他にもたくさんあります)

これらの用意されてる出力形式はオブジェクトを渡すと[object Object]と表示されてしまうので、Firebugでオブジェクトの中身を見られる関数を.keysnail.js(or _keysnail.js)に書き足してデバッグに使っていました。

// PRESERVE エリア内に
// firebugでオブジェクトをインスペクト
function fbug(x) {
    var args = Array.slice(arguments);
    var windowManager = Components.classes['@mozilla.org/appshell/window-mediator;1']
                        .getService(Components.interfaces.nsIWindowMediator);
    var {Firebug} = windowManager.getMostRecentWindow("navigator:browser");
    if (Firebug.Console.isEnabled() && Firebug.toggleBar(true, 'console')) {
        Firebug.Console.logFormatted(args);
    }
    return args.length > 1 ? args : args[0];
}

上を書き足したら、プラグイン内でfbugというメソッドが使えるようになります。
fbugに適当な値を渡すとFirebugでそれを開いて表示してくれます。(要はconsole.logみたいなもの)
この関数はxqjsから拝借しています。xqjsはとても便利なJavaScript実行コンソールなので是非使うといいです。

注意としてマルチバイトの文字列を渡すと文字化けするので、Writing Plugins (Japanese)にも書いてありましたが、そのときはL() と M()を使いましょう。

プラグインのリロードについて

プラグインのインストールは.ks.jsファイルへのリンク上で右クリックかプラグインマネージャーから行う事ができます。
プラグイン開発しているときはkeysnailのプラグインディレクトリ(プロファイル/keysnail/plugin)に.ks.jsファイルを置いて開発すると思います。変更を反映させるとき、毎回プラグインマネージャーから”プラグインのリロード”をするのは面倒なので、以下のようなものを.keysnail.jsに書き込んで使ってます。

// PRESERVE エリアの外に
key.setViewKey(['ESC', 'ESC'], function (ev) {
    userscript.loadPlugins();
}, 'プラグインのリロード');

これでESCを2回押したらプラグインのリロードするようになるため、プラグインを書き換えて実行→確認がすぐにできるようになります。(ページのリロードすらいらない)

プラグインのAPI

プラグイン内でthisを見ると、プラグインから使える関数などが見えてくるかも知れません。

fbug(this) -thisをFirebugで見る

KeySnail 1.8.5からはundersocre.jsを使えるようになっています。

• KeySnail 1.8.5 – 相対パス指定, underscore.js, 補完強化 – きすねた(ん) – keysnailグループ

また、プラグイン内でグローバル空間(this)を拡張しても問題ないそうです。
今回、KeySnailプラグイン書くために使ったAPIはJSONでデータの読み書きをするpersist.preserve(aObj, aName) , persist.restore(aName) と 渡した配列から絞り込み検索UIを簡単に使えるprompt.selectorです。
特にprompt.selectorは便利なので、これのためにKeysnailを使うのもありです。(はてなブックマーク検索ができるHatebnailとかがすごく便利)

それぞれのAPIの使い方は以下を参考にしました。

• 食堂はじめました – きすねた(ん) – keysnailグループ
• prompt.selector を使おう　～はてなブックマーク拡張と KeySnail の連携～ – mooz deceives you

注意点としてpersist.preserveに渡すオブジェクトは特にシリアライズしないでそのままオブジェクトを渡せばいいようです。また、prompt.selectorのflagsでHIDDEN IGNORE, ICON以外に数値で指定されている場合がありますが、内部でそれぞれ対応する数値が割り当てされているので、直接数値で指定しても大丈夫なようです。

• content/modules/prompt.js at master from mooz/keysnail – GitHub

他にもいろいろ使えるAPIがありますが、Github wikiの方に適当にまとめておいたのでそこら辺を参照するといいです。

プラグイン開発の参考リンク

Writing Plugins (Japanese) – GitHub

以上でKeySnailのプラグイン開発については終わりです。
是非、引っかかった点や参考にしたものなどは文章化してください。これは別にKeySnailに限ったことではありませんが、文章化されていないコードは非実在コードになりがちなため、文章やドキュメントにすることは大切だと思います。

azu/KeySnail-Plugins – GitHubi

https://github.com/azu/KeySnail-Plugins

KeySnaili

https://github.com/mooz/keysnail/wiki