2013年何やったかのまとめ
ジョブがチェンジした
上の見出しの通りです。詳細は（少なくとも当面は）書きません。
Mozilla
何件かバグ直した
ジョブチェンジした関係で忙しくなったので、昔ほどアグレッシブにはやってないけど、2013年も気になった物をちょこちょこと直してた。自分のやってたものは、主にリファクタリングとか、自分で物足りなかった箇所の設定追加とかなので、そんなに華々しいものやってないです。小粒なものをちょこちょこと。
Firefox OS Code Readingとかに顔を出し始める
Geckoのコード読むための強制力が欲しくて、ときどき参加するように。
Rust
Rust langが楽しそうなので色々始めた。
Rust Samurai
「JavaScript Ninjaがいるんだから、Rust Samuraiが居てもいいだろ。Mozilla的に」 というギャグから始まった企画。気がつけば二回も勉強会的な事をやってました。
自分としては巨大なコミュニティにするつもりは一切なくて、本当に、ただ単にRustの勉強とか研究をする会なので、人数が極端に増えるようになったら、たぶん活動止めると思う。
"Rust Samurai"って名前で、コミケ申し込んだりとか、色々好き勝手にやってしまってるしね。
だいたいこんな感じ。
今のうちに、ちょっとRust Samuraiっていう団体について、個人的な意思を述べておこうと思う。コミュニティの総意ではないけれども。
— さねゆキーノ (@saneyuki_s) September 15, 2013Rust Samuraiの主宰のようなことをやっているけど、自分としては、Rust Samuraiをそのまま「日本Rust langユーザー会」のような大きな公式コミュニティにするつもりはあんまりないです。
— さねゆキーノ (@saneyuki_s) September 15, 2013理由は幾つかあるんだけど、自分はコミュニティ組織を立ち上げたいんじゃなくて、「Rustを知りたいけれども他に誰もやっていないので仕方なく自分で始めた」という程度の動機なので、大きくするつもりが全く無い。つまりは「繋ぎ」のポジションとしてやっているから。
— さねゆキーノ (@saneyuki_s) September 15, 2013あと、Rust Samuraiって名前で、個人的な一発芸的なことをやっているので、そういう手垢のついたブランド名を、そのままpublicなものにしてはダメだと思っている。
— さねゆキーノ (@saneyuki_s) September 15, 2013なので「発表中にも自由闊達なツッコミが出来ない規模になったら=会場として借りているMJオフィスに入りきらない規模になったら」、即座にRust Samurai名義の勉強会は休眠モードにします。別の名前で立ち上げたい人がいたら、手伝いこそすれども、その人にお任せする所存。
— さねゆキーノ (@saneyuki_s) September 15, 2013以上、だいたいそんな感じです。
— さねゆキーノ (@saneyuki_s) September 15, 2013コミケでRustの薄い本出した
正直、こんなニッチな言語の本、10部くらいしか売れないだろうと思って、30部だけ持っていったら、11:30過ぎに全部捌けて衝撃的だった。本当に流れが読めん。
本当は言語の内容に突っ込んだ内容にした方が良かったのかもしれないけど、言語仕様自体がunstableすぎて、原稿も満足に書けない状態であるのと、言語仕様自体は公式のチュートリアルやリファレンスを読めばいいけど、具体的な実践例がなかった点を補足した方がコンテンツとして需要が有るだろうことを考えて、各人が（割と）好きなように書いたら、あんな構成になった。
ちなみに自分の担当した原稿は本当に難産でした。書いても書いても一向にServoの説明に入れないので、本当に辛かった。。。
Servo
コード量少ないし、アーキテクチャ楽しいし、最高に面白い。
まとめ
だいたいこんな感じでした
Gecko勉強会 2で話した内容の補足です
この記事はFirefox Advent Calender 2013の24日目の投稿です。
先日開催されたGecko勉強会 2で「Geckoは何者か Geckoはどこへ行くのか 非同期編」という題で、ブラウザがページを処理するにあたってどのような処理をしているのか、および、ここ数年で直面した課題と対応策について、ざっくりと話させていただきました。
本当は、発表したネタを丸まるここに書くつもりだったんですが、縁あって、勉強会でお話しさせていただいたので、その解説を。
補足解説
ブラウザの処理の詳細について
ブラウザがページを処理するにあたってどのような手続きを踏んでいるのかについては、ブラウザのしくみ: 最新ウェブブラウザの内部構造 - HTML5 Rocks という名記事が存在しています。GeckoとWebKitを参照した上で、ブラウザがどのようなプロセスを踏んで処理しているのかについての概説としては、非常によくできているので、一度は読んでおいて損は無いでしょう。
そのような名文ですが、以下の点に注意する必要があります。
- オーソドックスかつ基本的な内容を網羅しているものの、最新のアーキテクチャについて触れているわけではない
LayerやCompositor、GPUアクセラレーション、Tiled Renderingなどの「最近の進化」への言及は殆ど存在しません。記事が公開されたタイミングが2011年8月と古いので致し方ない点も有りますが、こうした点については、（主に英語で書かれた）他の情報を参照する必要が有ります。 - JavaScriptエンジンの進化については書かれていない
これも厄介な点です。HTMLおよびCSSというレンダリングエンジンとして重要な構成要素については詳細に書かれていますが、JSエンジンの進化の歴史については、別途情報を参照する必要が有ります。 - なぜこのような設計になっているのかについての言及が少ない
具体的には、ブラウザエンジンがシングルスレッドな理由について、思いのほかさらりと流されている点です。この点については、JSがシングルスレッドで実行される同期実行モデルであることと、CSSOMを介したレイアウト情報の取得がJS側から可能である事に起因した設計です（とはいえ、鶏と卵の関係のような物で、シングルスレッドの同期実行モデルであったが故にレイアウト情報の取得が同期的に可能であり、同時に、そのようにレイアウト情報が同期的に取得できるような世界になってしまったが故、このような設計が続いているとも言えます）。
とはいえ、オーバービューとしては非常に出来が良いため、目次と第二章まで流し読みをして、その後、必要に応じて読み返すような読み方がおすすめです。
ブラウザの処理の詳細について2
実際にはブラウザの処理というのは、スライド中の図のようには上手く行きません。DOMツリーの精製中にdocument.writeなどが走り、パースに対して影響を与える事が有るなどもありますので、目安という事で。
Mozilla Memes
Mozillaの開発IRCなどで流れたジョークをアメリカンな画像にして乗っけてるジョーク置き場です。基本的にハイコンテクストです。繰り返しますが、ハイコンテクストです。
ちなみにTwitterアカウントもあります。最近はあんまり更新されないね (´・ω・`)
CompositorとLayer
ブラウザのレンダリング処理に際し、CSSのposition:absolute, fixed, CSS Animation, CSS Tranformなどは、基本的には再度ペイントを行わずにページ上のどこに重ね合わせるかを判断するだけで、最終的なレンダリング結果を出力できます。この処理のことをCompositionと言います。そして、その合成にあたっての要素の重なり合わせに用いられる物がLayerです。まんまPhotoshopのLayer。
このLayerについては、他にも、Pluginの描画対象の要素だったり、WebGLなどが該当します。これらの処理は、そこ自体が独立した描画コンテクストを保有している為、要素の中で描画されている物が、レイアウトフローに影響を与える事がないため合成が可能というわけです。
なお、LayerとCompositionの仕組みはGeckoに限らず、WebKit, Blink, トレンドを鑑みるにおそらくIE (Trident)も実装していますが、仕様などで明文化された挙動ではなく、仕様の重箱の隅をつついた最適化であるため、実装依存となります。速度を突き詰めると概ね似たような設計にはなってきていますが、あくまでも実装依存ですので、細部の挙動はブラウザ間およびバージョン間で違いが有る点に注意しましょう。
Off Main Threadを説明した画像の出典
http://benoitgirard.wordpress.com/2012/05/15/off-main-thread-compositing-omtc-and-why-it-matters/
Firefox Android (Fennec, Native Fennec)のUIスレッドとコンテンツスレッドの分離
これは、正確には「Javaで書かれたUIスレッドとGecko上で動くスレッドの分離」です。そして、Fennecでは、UIロジックの一部がGeckoスレッド上で動作している為、完全に、UIスレッドとコンテンツスレッドを分離しているわけではありません。とはいえ、Off Main Thread Compositiingの実装によってユーザーとの入出力を受け取るスレッドが分離されており、Geckoスレッド上で記述されるロジックもそれほど巨大な物ではない為、結果として、軽快なレスポンスを実現できています。
プロセス分離
プロセス分離は、あくまでも、レンダリングエンジンのスレッド（プロセス）をUI側と切り離す事でコンテンツ側のハングアップをUI側に影響させないためのアプローチです。レンダリングエンジンのシングルスレッドのループについては、問題を解決できていません。レンダリング部分の設計転換が歴史的にも困難である事と、コンテンツ側の影響でUIが止まってしまう問題に比べれば相対的に問題ではないため迅速な解決が必要ではないことが、先送りとなっている理由です。
宣伝
この辺りの話について、偶然にも、冬コミで頒布予定のRustの薄い本である「Rust Dojo」のServoの章で説明しています。興味を持たれた方がいらっしゃいましたら、足を運んでいただければ幸いです。
GeckoView 計画
Firefox for Androidに関連して、ごく一部でにわかに注目を集めているバグがある。これね。
867517 – Gecko-based WebView for Android
概要
バグでは完全に実装に関連する話しかされてないので、イマイチ何を目的としているのかわかりにくい。なので、MLにMark Finkleが投稿したメールを引いてみる。
- Create a View and support interfaces needed to allow developers to use Gecko in place of a WebView
ビューを作成し、WebViewの代替として開発者がGeckoを使えるようなインターフェースをサポートする- Create a library (JAR) that makes it easy to pull in the Gecko code into a normal Android application. Devs should not need to build Mozilla/Gecko to get this to work.
通常のAndroid中のアプリケーションにGeckoのコードを封入しやすいようにライブラリ（JAR）を作る。この目的の為にデベロッパーがMozilla/Geckoを自分でビルドするのはナンセンス。- Use GeckoView in Firefox for Android as a first class citizen.
Firefox for AndroidでGeckoViewを第一級市民（訳注：APIとしてそのまま扱うという意味で良いと思う）として使用する- We'd like to support using more than one GeckoView in an application.
アプリケーションにて複数のGeckoViewの使用をサポートしたい
というのが目的。
この作業が上手く行けば、悪名高いAndroidのWebViewの代わりにGeckoを使えるようになるので、Android OSのバージョンなどを抽象化できる。Geckoが上手く動作できない端末の問題は有るし、apkパッケージサイズが大きめにはなるけれども、現状であればAndroid 2.2~4.xまでを丸々抽象化できて、且つ最新のWeb APIを使用できるので、WebViewを使っていたような地獄のアプリ開発に使い道が幾らかあるんじゃないかな。
ちなみに、mfinkleのメールには以下の事がnon-goalとして記載されている。
特に下については、WebViewがOSとセットのAPIとして提供されていることを考えれば当然だよね。
進捗
Bradのパッチの第一弾が投入されてる。とはいえもう少し関連パッチを投入する必要が有る状態で、現在開発中。ターゲットについて明確なバージョンは目にしてないけど、Firefox 24~25までの間にある程度の形になるんじゃないかと予想してる。
Firefox (Windows) の Austrails Visual Design がコレジャナイ理由考えた
Firefox/Features/Theme Refinement and Evolution (Australis) - MozillaWiki
何かがコレジャナイ。でも Mac だとそこまでひどいわけでもない。てなわけでテキトーに考えてみた。
慣れ
慣れって大切だよね。慣れればそこまででもないかもしれないね！
テクスチャが古い
全体的に使われてるテクスチャが Firefox 4（2010年）の時と殆ど変わってないので微妙に見えるんじゃないの仮説。
2010年の時点ではともかく、あれから2年経ってもうすぐ2013年に至り、Windows ユーザーは Windows 8 の Metro と呼ばれた真っ平らなビジュアルデザインの洗礼を受けてしまった。そのため、登場から既に6年以上の時が流れたAero Glassと親和性の高いビジュアルデザインのテクスチャは垢がついたように古くさくなってしまった。Windows 8 のデスクトップモードのGUIのテクスチャさえ、Metroに親和性があるようにアップデートされているというのに。そういう辺りの時代の変化が結果としてダサく見えるんだと思います。
テクスチャって見た目の印象に大きく影響していて、例えば Mac OS XのGUIなんかは基本構成は最初から殆ど変わっていないんだけど、今から見ると OSX 10.0とかその頃の Aqua は、青いチューブ然とした所にどこかイモ臭さがある。
Chromium/Google Chromeなんかも登場初期から全く変わっていないように見えて、テクスチャ（この場合はグラデーション）類は地味に変わっていたりする。一番顕著なのはGoogle Chromeのアイコンですね。メッキ調だったのがマット塗装されたっぽい何かに変わった。
この辺りの違和感が時代遅れ=ダサさに繋がってるんじゃないかと思います。
バックグラウンドのタブの文字が読みづらい
モックアップだとそこまででもないけど実際に使ってみると結構読みづらい。 Aero Glassの色をユーザーが自由に変更できることがまず考慮されていない。なおかつ、漢字のような複雑な字形をあのサイズで表示すると尚の事背景に埋没して読みにくい気がする
中途半端に Chromium/Google Chrome っぽい
真似るなら細部の挙動まで研究して消化して「盗む」方が良いと思うんだ！
まとめ
最終的にどうなるかは知らないけど、ダサくなくなってるといいね
Mozilla 勉強会＠東京 8thで話しました
さる12月1日に、Mozilla 勉強会＠東京 8thでお話しさせて頂きました。発表の内容でお聞き苦しい点がありましたら申し訳ありませんでした。
今回は「Mozillaへのバグ報告とバグの修正ステップを通じて、contributeへの間口を広げる」というテーマを設定しました。単にcontributeへの間口を広げるだけであれば、バグ報告のパートは要らないのですが、あえて追加した理由としては、この機会を通じて、バグ・不具合報告のやり方のたたき台のようなものを作成しておきたかったからです。
ユーザーとしてアドオンを使ったりFirefox自体を使ったりする上で、不具合報告をする機会はそれなりにありますが、「具体的にどのように不具合報告をすればいいのか？」というノウハウのようなものは、非エンジニアはもちろん、エンジニアの方でも知識レベルがまちまちです。各種勉強会では、開発インテグレーションやソフトウェア設計に関する発表は多々見られますが、「バグ報告」という初歩のそのまた一歩となると数も少なく、まったくの初心者の方向けのガイドライン足りうる資料を探すのは決して容易ではありません。 その結果、「バグ報告してください」との言葉だけが一人歩きし、無用のバグ報告ばかりが行われる事で、問題の本質を探るまでのコミュニケーションコストばかりがかさんでしまい、結果、報告者・修正者ともに余計な時間を過ごすというのはあまりにもバカバカしいと言えます。
いいアドバイスをもらうための相談の仕方 - ククログ にもあるような、アドバイスにおいて必要な情報をすべてうまいこと伝えるためにはどのような点を押さえておくべきなのか？ ということを、最低限のテンプレートとして参照できるように意図して作成しました。
Mozilla Firefoxは完全なリポジトリもMLもBTSもIRCもちゃんと公開されているOSSではありますが、非社員であるボランティアのコントリビューターや普通のユーザーにとっては公開される情報量の多さ故、新規機能実装案の初期から議論に参加するのは結構難しいプロジェクトでもあります。そうした特性上、どうしてもユーザーが気づくのは実装が煮詰まってから、あるいは完成後になることが多く、実装経緯のログも簡単に読める分量を超えているため、適切なツッコミのコメントがなされない、あるいはコメントが上がってもスルーされるということがままあります（ユーザーが触れるUI関連の開発では、UI開発という作業の性質もあるのでしょうが特にその傾向が感じられます）。
ですが、その一方でbugzilla.mozilla.orgというBTSは民主的ないしオープンであり、真っ当な意見の声が複数集まれば、ちゃんとそれなりに意見として（短期的・長期的かはケースバイケースですが）影響力を持つという文化が存在します。ですので、英語という言語の壁はありますが、可能であればbugzilla.mozilla.orgやMLフォーラムになるべく意見を明確に申し立てることにチャレンジしてみるといいと思います。人間の仕事ですので、観測圏外で騒いだところで、その騒ぎ声は存在しないのと同義になってしまいます。
あと、番外編としてLTで話した Browser Debuggerですが本当に便利です。これさえあればFirefoxのchrome領域に絡むパートのデバッグが一網打尽というわけではないのですが、コードリーディングをして当たりを付けた箇所にブレークポイントを張り、実際に動かしてそこで止めてスタックトレースを閲覧できるまでのステップがVenkmanに比べて簡単になりました。幸せです。不具合や仕様上の問題、未実装箇所なども幾つかありますが、結構楽しいです。願わくばこれがtoolkitに移動して、thunderbirdなどでもしようできれば良いのですが。 とりあえず騙されたと思って使ってみるといいと思います。
手元で Firefox をビルドせずに Mochitest を動かす
Mozilla のソースツリーには Firefox 自体のテストを行うツールが色々と埋まってて、その中に Mochitest というものがある。詳しくはリンク先を見てもらった方が速いんだけど、Mochitest では chrome 権限で動くコードを対象に含むテストができる。
で、これは普通は手元で Firefox をビルドしないと使えないんだけど、自前でビルドせずとも Mozilla の ftp サーバーから、ビルド時に生成されるテストセットを DL して、適切にオプションを設定することで手元でビルドせずに動かせたりする（つまり、Mochitest 自体はビルド処理をかませたものでないと動かないけど、それさえ行ってあればコマンドラインオプションを追加することで動かせる）。
用意するもの
- 実行環境に応じた firefox-*.tests.zip
（たとえば最新のNightlyの場合は ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/ から拾ってくる - テスト対象の Firefox
（拾ってきたテスト一式と同じリビジョンから生成されたものを使います。というわけでこれも拾ってきたりする） - テストケース
（Mozilla のソースツリーに入ってるものは、拾ってきたテスト一式の中に入ってる）
テスト実行
最初に挙げた Mochitest のドキュメントを読めば基本的には実行できる……はずなんだけど、今回の場合はそれに追加で最低限以下のオプションを付ける必要がある
--appnameに、実行する Firefox のバイナリのフルパスを指定--utility-pathに$(TESTS)/bin/を指定--certificate-pathに$(TESTS)/certs/を指定--test-pathは Mozilla のソースツリー上での位置を指定（実行される実ファイルは$(TESTS)ディレクトリ以下のもの）。
なにがうれしいの
これだけだと自分でビルドせずにパッチを書くような人か Firefox のテストを延々実行して悦びを見出すような変態しか面白くないだけど、オプションでコマンドラインをつけることで
指定したアドオンをインストールした状態でテストを実行できる:
--install-extension=path/to/<add-on-id>.xpi指定したプロファイルを使ってテストを実行できる（ただしテスト終了時に選んだプロファイルは削除される）:
--profile-path=path/to/profile/
といった機能を使える（mochitest/runtests.pyを参照）。
というわけで、アドオンのテストなどにも地味に使えるわけです。
アドオンのテストというと、UxUなどがあるわけだけど、Mochitest でテストを行うメリットとしては、Mozillaのソースツリーに埋まっている山のようなテストコード資産を使える（新規にテストを書く際の参考にできる・本体側に余計な影響を及ぼしてないかテストできる）という辺りだと思う。
逆に Mochitest でのアドオンテストのデメリットは、「UxU と違っていちいちテスト環境を用意しないといけない」「そもそも UxU でも相当数のテストケースは書ける（アドオンをインストールせずともテスト実行できる）」という辺り。特に前者が致命的かもしれない。
だいたいこんな感じ。
Marionette とか他のテストツールの使い方？ そのうち気が向いたら書くかも。
Mochitest
Mozilla のテストフレームワーク Mochitest についてのメモ。
