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以降は禁止された
    • ざんねんでしたね

- Version 0.1.1 issues
- Version 0.1.2 issues
- Version 0.1.3 issues

に全部載っている事です。
バグとかは面倒なので省いています。結構いろいろあるので気になる人は上のを見ておくといい。

• #347: support GM’s openInTab’s new aLoadInBackground argument – Issues – erikvold/scriptish – GitHub
  GM_openInTabに、バックグラウンドでタブを開くオプションが入った
• #225: Add ignoreRedirect argument to GM_xhr – Issues – erikvold/scriptish – GitHub
  GM_xmlhttpRequestにXHR先のリダイレクトを無視するignoreRedirectのオプションが入った。
• #374: console.log etc. should be hooked to the corresponding web console – Issues – erikvold/scriptish – GitHub
  Firefox4からWeb Consoleが入ったので、console APIがそれにも対応(Firebugとか使ってればあんまり関係ない)
• #338: Add a hidden preference to allow customizing support for URI scheme – Issues – erikvold/scriptish – GitHub
  geo: URI scheme handler, lp: URI scheme handler といった、他の拡張などで用意されたURIスキームでもスクリプト動かせるオプションが用意された。
  extensions.scriptish.enabledSchemes.* という設定をabout:configから作って真偽値を入れる事で可能になるようだ。
  extensions.scriptish.enabledSchemes.foo が true ならfoo: というスキームで動作する。
  - Manual: Preferences – GitHub
  
  
  
  それぞれデフォルトで存在するプロトコルも同じ方式で書かれている。
• configファイルがscriptish-scripts.xml から scriptish-scripts.jsonに
  ちょっと該当bugはどれか分からないけど、多分そうなっています。

オプション画面の変更

Scriptish自体のオプション画面も大きく変更されています。

一枚目は主要プロトコルでの動作の設定以外は以前とそこまで変わらないので、問題ないと思います。
二枚目はグローバルのExclude(スクリプトに書かれてるexcludeとは違ってグローバルで動かないURL)の設定がタブに分かれて書きやすくなっています。

三枚目が結構重要な変更が入っていて、特にGreasemonkeyスクリプトを書く人はここの設定に注意する必要があります。

☑ユーザスクリプトをキャッシュする

という設定にチェックが入っていると、スクリプトを書き換えてページをリロードしても、すぐには反映しない(キャッシュが使われる)ため、スクリプトを書く人はチェックを外した方がいいと思います。

• #289: Provide user pref for caching script & dep contents – Issues – erikvold/scriptish – GitHub

後は、UIを常に英語にしたり、今までabout:configから直接決めないといけなかったものもGUIから設定できるようになっているみたいです。(全てではないですが)

• Manual: Preferences – GitHub

これ以外にも、パフォーマンスとか内部のバグなど結構改善されてると思います。

Greasemonkeyとの互換性の話

新しいAPIはGreasemonkeyが実装してくれないと互換性はない(fail safeを書くか、分岐するなどで対処)ですが、元々あったGM_openInTabなどは拡張して実装されてるので基本的にGreasemonkeyと互換性があると思います。

ただ、GM_registerMenuCommandはGreasemonkeyでは第一引数にeventオブジェクトが渡されるようになって、

function sayHello(evt) { console.log(evt) }
GM_registerMenuCommand("Hello, world (simple)", sayHello);

のようなコードがScriptishではundefinedで、Greasemonkeyで動かすとなぜかイベントオブジェクトが入るようになり互換性がちょっとないです。(これはGreasemonkeyが勝手に壊した感じです)

function sayHello(evt) { console.log(evt) }
GM_registerMenuCommand("Hello, world (simple)", function(){
    sayHello();
});

そのため、Scriptish、Greasemonkeyどちらでも安全に動くようにするには、明示的に無名関数などを使った方が良いでしょう。

後、外部コンテンツを読み込む系のGreasemonkeyやブラウザ拡張を作る際の注意事項などの対策(Full Feedのものが行ってるタイプ)として、GM_xhrで取得したコンテンツを自前でフィルターするのをベタに書くと速度的な問題が発生したりするので、そういう時はScriptishにあるGM_safeHTMLParser APIを使用するのが良いでしょう。
自前で書いても工夫すれば実用的な速度にはなるが、用意されているものを使うのが楽という意味で。

• http://d.hatena.ne.jp/Constellation/20101026/1288020124

また、まだ入っていませんが、Scriptish 2.0でGM_xpath – GitHubというXPathのAPIが入るようなので楽しみ。

• #45: Support @xpath – Issues – erikvold/scriptish – GitHub

Greasemonkeyにとどまる意義はあまり見つける事ができませんが、Scriptitshに移行する意義は見つける事ができるような感じの状態です。
Scriptish作者のErik VoldさんはGreasemonkeyに対してさよならと言ってるので、これから少しずつ差が出てくるような気がします。

• Farewell – greasemonkey-dev | Google Groups

これからGreasemonkeyスクリプト実行環境がどうなるのかはまだ何ともいえませんが、とりあえず私はScriptishを中心に使っていきます。

• 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に移行していました。

詳細は以下を参考に

以前はURLに.txtとつければよかったので、特に何もしなくても不便はしなかったのですが、2011年6月15日現在はraw masterなURLへのURLにするにはちょっと書き換える量が多いのでGreasemonkeyを書きました。

gistのページのファイル名の横にraw master URLへのリンクを追加するGreasemonkeyです。
Scriptishの場合は、リンクをクリックするだけでクリップボードにURLをコピーします。

この仕様変更により、Greasemonkeyで.txtでrequireしてたりするスクリプトは新しくインストールすると死んでいると思うので確認が必要になるかもしれません。

翻訳許可のメールをわずか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 の設定値)

このプラグインはChemr-jsのように先にリファレンスサイトのインデックスのキャッシュを作っておいて、複数のリファレンスからまとめて検索をすることができるプラグインです。

動画だと対応サイトが少ないですが、現在は以下のサイトに対応しています。
(最新の対応サイトリストはJSReference at master from azu/KeySnail-Plugins – GitHubを参照してください)

• developer.mozilla.org
• jp.developer.mozilla.org
• www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/
• api.jquery.com
• es5.github.com
• msdn.microsoft.com

ECMAScriptの仕様書、MDCのドキュメント、jQueryのAPIドキュメント、IEのJavaScriptリファレンスなどを同時に引けるので結構便利です。

対応サイトもSITEINFO的なものを書けば増やせるので、JSReference at master from azu/KeySnail-Plugins – GitHubを参考に見てみるといいです。

プラグインをインストールするとプラグインマネージャーにドキュメントが表示されるので、そこに使い方が書いてありますが簡単に説明すると二つのコマンドが追加されます。

このコマンドをKeySnailの設定メニューや_keysnail.jsファイルに直接書き込むなどでショートカットに割り当てて使います。

設定画面の場合

key.setGlobalKey(['C-b', 'j'], function (ev, arg) {
    ext.exec("JsReferrence-open-prompt", arg, ev);
}, 'JsReferrenceのプロンプトを開く', true);
key.setGlobalKey(['C-b', 'r'], function (ev, arg) {
    ext.exec("JsReferrence-reIndex", arg, ev);
}, 'JsReferrenceののインデックスを作り直す', true);

// 二つのサイトを候補にする - JavaScript
key.setGlobalKey(['C-b', 'l'], function (ev, arg) {
    ext.exec("JsReferrence-open-prompt", ["developer.mozilla.org", "www2u.biglobe.ne.jp/~oz-07ams/prog/ecma262r3/"], ev);
}, 'JsReferrenceのプロンプトを開く', true);
// msdn.microsoft.comのインデックスだけを再構築する
key.setGlobalKey(['C-b', 'r'], function (ev, arg) {
    ext.exec("JsReferrence-reIndex", ["msdn.microsoft.com"], ev);
}, 'JsReferrenceのプロンプトを開く', true);

• KeySnail
• JSReference at master from azu/KeySnail-Plugins – GitHub
• KeySnailプラグイン開発の方法とデバッグ | Web scratch

document.getElementById("ASIN").value

Amazonはページ中のhiddenなinput要素にASINを持たせてるのでこういう手が取れる。

<input id="ASIN" type="hidden" value="4253196519" name="ASIN">

ページの構造が変わったらダメだけど、結構昔からこの部分は変わってないので意外と安定しているかもしれない。
amazon.comだと構造が違うものがあって、Amazon.com: Buried Prey eBook: John Sandford: Kindle StoreのようにKindle Storeだとページ構造が違ってID=ASINがない代わりに次のようなものがある。

<input type="hidden" value="B004LRPGPC" name="ASIN.0">

var ASIN = document.getElementById("ASIN") || document.getElementsByName("ASIN.0")[0];

もう一つの方法はwindowオブジェクトのプロパティから取得する方法

(2011年6月5日現在だと)

window.sitbAsin;

• Amazonの商品個別ページでASINを抜き出す – おれ ここ めも かきなぐる おまえ ここ よむ なぐる – subtech

最後はURLからASIN部分を切り出す方法

URLにはASINが入ってるはずなので、ページに構造の変化には強いけど、少しパースが面倒なところがある。
どのようなURLがあるかを把握する必要があるので、条件分けなども必要になる。
まあASINのフォーマットは\w{10}と決まっているので、ある程度安定するのかもしれない。

ついでに、replaceStateを使ってリロードなしでAmazonのURLを/dp/ASINだけの短いURLにするGreasemonkey書いた。

• Amazon URL Cleaner for Greasemonkey

なので、link rel="canonical"のタグを削除するGreasemonkeyを書いてみました。

• GitHub: remove canonical for Greasemonkey

何でこんな仕様なのか意味不明なので、いずれは元に戻って欲しいです。(このGreasemonkeyは一応、仕様が変わったかどうかかもチェックしてます)

Githubはhisotyオブジェクトを使って動的にURLを書き換えてるのは知ってる人多いと思いますが、link rel="canonicalもそれにあわせて動的に書き換えています。
$.attrで書き換えてるだけなので、link要素を削除してもエラーは特にでないようになっています。

link rel="canonicalはあった方がうれしいと思ってたけど、あると困るケースに遭遇したのは初めて。

adblock#.uc.jsにはadblock系リスト変換君.htmlというadblock++形式などから変換できるものが入ってますが、さすがニッチなadblock++からadblock#への変換はないようなので書いてみました。
(今思えばadblock系リスト変換君.htmlを拡張すればよかったかも…)

必要なもの

• Firebug

以下のコードをFirebugのコンソール上で実行

adblockDataの部分は自分のabout:configからextensions.adblock++.filter_array の値に差し替えてください。
最後のcopy関数以外は別にFirebugに依存しているわけじゃないので、他の環境でも少し書き換えれば動作すると思います(MITライセンスなのでご自由に)
変換したものはクリップボードに入るので、後はadblock#.uc.js Filter Managerを開いて、入力欄にペーストして”追加”のボタンを押せばフィルターを移行できると思います。

Adblock++はフィルタにコンテンツの種類を設定できるのですが、adblock#.uc.jsは対応していないのでそれ系のフィルターは自動で外されます。また既にdisableなフィルターも外されます。
正規表現周りは元々使ってないので、ちゃんと動作するかは微妙です。
一応、Readmeに従って下記の処理には対応させたつもりです。

ただし,「/ads/」のように前後に「/」が付く物は正規表現フィルタと誤認識されるのを防ぐため,「*/ads/*」と表記する.

• adblock++ から adblock# 形式へ変換する(Firebug上で実行) — Gist