Jun 20, 2016

Mozilla All Hands in London 2016 イベントレポート:技術編

現地時刻で2016年6月13日から17日にかけて行われたMozilla All Hands in London、通称MozLondonに参加してきました。 (オープニングセッションの開始前の様子)

最近はこの種のイベントに参加する機会が減ってしまい、「えっ、Mozilla関係で何かやってる人だったの?」みたいになってそうな気がするので、ちょっと記録を残しておこうと思います。

Mozillaの活動に関わっている人はMozillaの雇用スタッフもそうでない人も世界中に散らばっていてコミュニケーションコストが高いので、半年ごとにAll Handsと称して社員と外部の開発者を一箇所に集めて色々話し合っています。 ただ、社員は全社員が招集されるのに対して、自分のような外部の人は活動のアクティブさの度合いなどに応じてボランティア枠で招待される形です。 自分は連絡を頂いた時点ではBugzilla上でそんなにアクティブではなかったのですが、今回はアドオン作者へのヒアリングということでアドオンチームの方から推薦を頂いたようです。 「ボランティア」とはいっても招待なので、交通費・食費・宿泊費は全部Mozilla持ちでした。

前述のような趣旨なので、Firefox Developers Conferenceのような種類のイベントとは異なり、All Handsの各セッションは「チーム間での情報共有」や「普段オンラインではやりにくいブレーンストーミング」といった感じの、実務寄りの内容でした。 自分はFirefoxそのものの今後とアドオンに関するセッションに参加して、それ以外の時間は会場内のフリースペースでアドオンのメンテナンスをしたり仕事をしたりしていました。

セッションで聞いた話は随時Twitterで垂れ流していましたが、話題ごとに改めてここにまとめてみようと思います。 自分の英語のリスニング力が低すぎて正確な所や詳細を聞き取れていない所が多いので、「えっそれマジ?」というような話については僕の聞き間違え・誤解である可能性も大いにあると思って話半分に読んで下さい。 そういう大きな変更の話は、事実であれば後から何かしら正式なアナウンスが出ると思いますので。 もしかしたらアドオン管系の話は既にMozilla Wikiのアドオンチームのページから辿れるかも知れません。

XULの廃止について

  • デスクトップ版ブラウザとしてのFirefoxのここまでの歩みと将来についてのセッションで、ロードマップの見出し項目の1つとして挙げられるくらいには、「deXUL」つまりXULの廃止は大きな目標の1つとして掲げられている。
  • 「アドオンの移行が進まないうちにXULが廃止される事はあるのか?」という問いに対しては、「最新のWeb技術への対応等やらないといけない事がたくさんあるとか、Firefox自体がXULに基づいてるから全面移行には大きな手間がかかるとか、色々理由があってXUL廃止は最優先というわけではない」という感じの回答をKevさんからもらった。
  • 以上を踏まえると、XUL廃止は「回避可能な未来」ではなく「いずれ来る未来」と考えて備えておく必要がある。

後で知ったんだけど、プレゼンターのKevさんはアドオンチームのマネージャで急遽代理で発表をされていたようなので、XUL廃止をどのくらいの優先度で進めていきたいという話には、もしかしたらFirefoxチームの最前線の人との間では温度差があるかも知れない。

アドオンのパッケージへの署名の義務化について

  • 署名の検証を無効化する設定を残す「ノーブランド版の通常リリース」が準備できておらず、それに依存するため署名必須化(無効化設定の廃止)はFirefox 48に延期された。
  • ESR版では署名の検証を無効化する設定は引き続き提供され続ける。
  • ESRをサポートしない事を明言しているSalesforceのようなサービスを全社で使っていることが理由で、ESRではなく通常版を使っている法人ユーザは実際にいるので、ESR版があっても依然としてノーブランド版ビルドは必要だという事を述べてみた。

既に公開されている情報の通りだけど、アドオンの関係者が多く集まる場面で改めて話題として取り上げられる事で、問題の認知自体が広まっていたらいいなあ……と思ってる。

Mozilla Add-ons Webサイト(AMO)におけるアドオンの公開申請のレビューについて

  • アドオンのレビュー待ち時間増大問題の解消についての報告があった。
    • レビュー待ちのキュー数が激減し、レビュー待ち期間も短縮された。
    • 最近は1週間あたり500レビューという水準で落ち着いている。
  • 非公開(Unlisted)なアドオンのレビュー方針の変更について報告があった。
    • この時、プレゼンター(どなただったか失念した)からセッション参加者に対して「そもそもサイドローディングというものの存在を認識しているか?」と質問が投げかけられていたが、認識している人の方が少数派だった。
    • エディターレビューは、一部のアクティブなエディターが頑張っている模様。
  • アドオンのe10s対応はあまり進んでいないという報告があった。

AMOそのものの改良について

  • サーバをAWSへ移行しようとしている。
    • AMOのサーバをDockerコンテナ化する。
  • フレームワークをDjango(Python)からReact(JavaScriptでサーバーサイドレンダリング)へ移行しようとしている。
  • 現状では、アドオンのユーザーレビュー欄で「星1つを付けてバグ報告する」という使われ方が横行しており、ユーザーレビューが本来の目的に使われていない。そのため、星が判断の参考にならない。
    • ユーザーにとっても、「アドオンを入れたことを忘れて、レビューすることも忘れる」という問題がある。
    • リリース前に十分にベータテストをしてからリリースしたくても、実際にはリリース後にそういう形でバグ報告が来るという事も多い。
    • これらの問題の解決策として、アドオンのレビューとバグ報告を切り離せるようにする事を検討中。
  • 後述するDiscoveryの話に関連して、AMOのデザインをガラッと変えるプランがあるようだった。でもモックアップを見た感じではGoogle Playの画面みたいだった。(……と一言で形容できてしまう程度には、全く目新しいという感じではない印象だった。)

アドオン開発環境としてのFirefoxの改良について

  • about:debuggingの改良についての報告があった。
    • アドオンのIDが無くてもテストできるようにする仕組みが入った。署名無しの状態で開発中のアドオンを動かして検証できる。
    • コンテントスクリプトやバックグラウンドページをデバッグできるようになった。
    • 構成ファイルの変更(CSSファイル等の変更)を検知してアドオンを自動的に再読み込みできるようになった。
  • エディターによるQAレビューを省力化するにはどうすればよいか? アドオン作者側も、どうやればFirefoxのバージョンごとの変更に効率よく追従できるか? というような事が話されていた。
    • 人気のアドオンの作者に聞いて、開発者同士の情報共有について意見を求めたみたい。
    • Salesforceを使うという案が具体的に話されていたが、これはアドオン作者も関係する話だろうか?
    • AMOにCommBadge機能を入れるという案が出ていた。
      • よく分かっていなかったが、後で調べたらスタートレックに出てくる通信機の名前みたい。つまり、困った時に相談できるチャットを用意するということか?

アドオンを通じたユーザ体験の向上について

  • ユーザがどういう動機でアドオンを使っているのかについて分析結果の概要が話されていた。
    • 試しに入れただけとか、作業効率向上のためとか、調査のためとか、色々な立場がある。
    • 開発者にも同様に色々な立場がある。趣味の開発者、何かのサービスの提供事業者としてユーザ向けの補助機能を提供している、実験のため、あるいは、FirefoxやChromeであれば既にユーザが多いからそれに乗っかってユーザに広くリーチしたいという場合もある。
  • ドキュメントがあちこちに散らばっているのを集約する事について、Chrome用拡張機能のFirefoxへの移植手順なども含めた総合情報ポータルを用意するという案が出ていた。これはWebExtensions移行とセットの話だと思う。
  • アドオンごとに見た目がバラバラなのはユーザを戸惑わせるのでということか、アドオンのスタイルガイドライン(アイコンやポップアップなどのデザインについてのガイドライン)を用意する事を考えているようだった。

この辺の話を聞いていると、XUL廃止は新規の開発者を増やすためにも必要と見られているように感じた。 実際に、自分が業務の中でMozillaサポート事業の人員を増やすべくアドオンの作り方の技術移転を進めているが、XULだったりJavaScriptだったりXPCOMのようなMozilla固有の事情だったりと、知るべき情報の範囲が異常に広くて覚えきれない(伝えきれない)のが悩みの種になってる。 JavaScriptが言語として機能強化されて、例えば複数行に渡るリテラルの定義やテンプレート風の値の埋め込みなどもJSだけでできるようになっているので、「XUL」というMozilla固有の技術の必要性は下がってきている印象がある。

アドオンをまだ使った事がないユーザ・アドオンをあまり使っていないユーザにアドオンを使ってもらいやすくする事について

セッション後もFirefox Homeroom(Firefoxチームのパブリックスペース)でスケジュールにない意見交換会が行われていて、「アドオン開発者向けのフォローアップの充実」という事と併せて、特に重要なトピックとして扱われているようだった。

セッション中に色々出ていた案はEtherpadのメモに残されているが、以下は自分に聞き取れた範囲の事。

  • 現在about:addonsの「Get Add-ons(アドオン入手)」を選択した時に表示されている内容をが実際のダウンロードに結びついていないようなので、これを変えて、アドオンをもっと使ってもらえるようにしようとしている。「Discovery Pane」で、通称「Disco Pane」。
    • もっとシンプルに、お薦めの物(Onboarding Addon)をいくつかをすぐ試せるようにする。
    • 現状の物は、インストールするだけで何度もいろんな所をクリックする必要があり、何度も確認を求められる。これを、設定項目のON/OFFを切り替えるレベルの簡単さで済ませられるようにしたいようだ。
      • アドオンマネージャ上でもインストール済みのアドオンをカテゴリでグループ分けし、グループ化されたチェックボックスとして見せれば、使う上でのハードルが下がるのではないかという話だった。
      • ユーザ調査の結果、ユーザは設定のON/OFF程度までは理解できても「アドオン」という概念になると技術が前面に出すぎていて抵抗がある、という分析結果を得たらしく、それがこのプランの背景にはあるみたい。
      • これをやるには、そのアドオンが本当に安全なのかというのを事前に正しく判断しておける必要があるので、そういう動機からもWebExtensionsの宣言的なパーミッションモデルの拡充が求められている模様。
    • これは発言の機会を逸したのでミーティング中には言えなかった事で、後で何人かのプレゼンターを個別に捕まえて話す機会があった時に話したんだけど、Onboraningで表示するお薦めのアドオンはAdBlock Plusのように用途がはっきりしているものに限定して欲しい。Tab Mix Plusのように機能の範囲が広いと、ユーザが入れた事すら忘れてて、TMPの問題と気付かずにFirefoxや他のアドオンのバグと勘違いする事例が今よりもっと増えてしまいそうに思う。
  • Amazonなどのように、このアドオンを使っている人はこちらも使っています……のようなお薦めを出すのはどうかという案。
  • アドオンの数が多すぎるから減らしてはどうかという案。
    • 発言の機会を逸したけど、自分はこれはよく考えてやらないといけないと思う。目的指向の単機能のアドオンがたくさんある事自体は悪くないと自分は思うので。
  • ブログ記事などでの推薦はどうか。
  • オプトアウト式にするのはどうか。
    • この辺よく聞き取れなかったけど、Test Pilotみたいな開発版向けの実験ではなくリリース版で勝手に何かアドオンが入るというのはさすがにどうかと思う……
  • コミュニティミーティングの場では発言できなかったが、ユーザが不満を感じたその瞬間にUI上から「ここをカスタマイズする」というメニューを選んだらお薦めアドオンを列挙するような仕組みはどうか?という案を、その後ミーティングメモに書いて、Andrewさんにも口頭で話した。

SDKやレガシーな開発手法からの、WebExtensionsへの移行について

  • WebExtensionsはFirefox 48で一旦「正式にリリース」ということになる。
    • XUL廃止(非推奨化)の動きはFirefox 48でのWebExtensions正式リリースを受けて本格化していく模様。
    • というか、推奨非推奨でいえばXULは既に非推奨扱いになっている。
  • WebExtensionsのロードマップ上の項目として、サポートするAPIの充実と、Android対応の事が挙げられていた。
  • プラットフォームに強く依存する機能・他のアプリケーションとの連携という課題の解決方法として、他のプロセスとパイプラインを通じて通信するchrome.connectNativeのデモが行われていた。
    • Webページ中の入力フォームをEmacsで編集するというデモで、これをやるためにEmacs側を改造する(通信を受け取るための口を新規に設ける)必要はないとの事だった。
  • パーミッション機能(そのアドオンが必要とする機能を事前に宣言したり、実際にセンシティブな機能を使う段階になって許可を求めたりということ)について、今後改善を進める予定みたい。
  • WebExtensionsにまだAPIが無い機能は、native.jsという仕組みで実験的に実装できるようにする。
    • native.jsは実験的アドオンのみに使用が許可され、一般向けのアドオンとしてリリースするアドオンからは使えない(機能を使っていたらレビューが通らない)ようになる模様。
    • SDKで、下手に低レイヤの機能を提供したばかりに、結局XULに触ってるからSDKの更新だけではアドオンがFirefoxの新バージョンでは動かなくなる……という愚を繰り返さないため。
    • native.jsで実現された機能でニーズが高いものをWebExtensionsのAPIとして採用する(提案されたAPIをnative.jsで先行実装し、提案の妥当性を判断する材料にする)という流れにしていきたい模様。
    • native.jsという仕組み自体はFirefoxの機能の一部として提供され、SDKのようには切り離されない。よってFirefox ESR45にはバックポートされず、ESRで使えるようになるのはFirefox ESR52からとなる。
  • 当面の目標として、Google Chromeで人気のアドオンをそのまま動かせるようにするレベルに持っていきたいみたい。現状のサポート範囲の比較表で作業の進行状況を確認できる。
    • ただ、APIによってはFirefoxには無いChrome固有のUIを前提にしているものがあるため、どうやってマッピングするかは課題が多い模様。(UIがChromeと同じになればAPIもそのまま持ち込めるだろうけれども、FirefoxにはFirefoxのUI設計ポリシーが一応あるし、そもそもFirefoxのUIをどう変えるかはアドオンチームではなくFirefoxチームが決定権を持つので、単純にChromeと同じUIにする訳にはいかない。)
  • アドオンのWebExtensions移行については、統計情報やアンケート調査の結果を見て色々な判断の材料にしている。
    • connectNativeもそうして提案された機能の1つである。
    • Firefoxのアドオンはロングテールが非常に長く、熱烈なファンがいるアドオンはそういうロングテールの方にこそ多く潜んでいる(企業利用で必要とされる機能もそういう部分にある)というのが自分の印象なので、統計情報だけから判断していると大事なものを見落とす気がしてならない。
      • Kevさんに個別に話す機会があった時、その辺の事をどうか考慮して欲しいとは伝えてみた。
  • WebExtensionsへの移行を段階に進めるための技術として、native.jsとは別のアプローチで、ハイブリッドアドオンという仕組みの実装が進んでいる。
    • 再起動が不要なアドオン(Bootstrapped Extensions。SDKベースのアドオンもこの中に含まれる)の中にwebextensionsというディレクトリを作り、その中に、単一のWebExtensionsベースのアドオンと同じ内容(manifest.jsonなど)を置き、コンテナとなるレガシーアドオンのinstall.rdfem:enableEmbeddedWebExtension="true"というフラグを加えておく。
      • 埋め込まれたWebExtensionsアドオンは、コンテナとなるレガシーアドオンと同じIDを持つ。
      • アドオンマネージャ上からはコンテナとなるレガシーアドオンだけが見える。
      • 埋め込まれたWebExtensionsアドオンは、基本的にWebExtensionsのAPIを通じてFirefoxと直接やりとりをする。
      • 埋め込まれたWebExtensionsアドオンは、コンテナとなるアドオンとはchrome.runtime.sendMessage経由で通信する。
      • native.jsのように独自のAPIをWebExtensionsに加えるものではない。
      • 送れるメッセージはJSON化できるメッセージに限られるので、JSON化できない情報はやりとりできない。例えば生のDOMに触るような機能の処理の一部だけを委譲するというのはこの仕組みの上ではできない。
        • どうしてもやりたければ、機能を発火させるメッセージをWebExtensionsアドオンからコンテナアドオンに送り、コンテナアドオン側で主体的にDOMツリーをいじっていくような形でやらざるを得ない。
    • アドオンの中で、古い部分と新しい部分をきれいに分離したままで、WebExtensionsの機能不足を補うアイデアである。
      • 必要なAPIがWebExtensionsに揃って、コンテナアドオンが不要になった段階で、コンテナアドオンを破棄してwebextensionsディレクトリの内容をそのままそのアドオンの新バージョンとして公開すれば、移行が完了する。
    • 再起動が必要な本当にレガシーなアドオンからは、この機能は原則として使えない。
      • これは、再起動不要なアドオンが個別のサンドボックスを持つという仕組みの延長線上にWebExtensionsアドオンの仕組みがあるため。
      • なので、まずは再起動不要にする所から移行を始めないといけない。

WebExtensionsのAPI提案について

  • まず、WebExtensionsのAPIの提案を採択するかどうかの判断基準が示された。
    • 具体的な判断基準
      • 高レベルのAPIであること。ここで言う高レベルというのは、SDKでの「高レベルAPI」と「低レベルAPI」の区分けと同じようなニュアンス。
      • 安全であること。XSSなどの問題を引き起こしかねないAPIの提案は却下される。
      • 実装のメンテナンスコストが低いこと。Mozilla側の人的リソースが限られているため、APIの実装と維持が大変な提案は却下される。
      • Firefoxの現在のUIや設計に強く依存しないこと。例えば、XULが廃止された後には「タブバーをウィンドウの上から横に動かす」のような機能は実現のしようがないので、そういう観点のAPIデザインは駄目。
      • アドオン作者から見て簡単に使えること。これはあくまでアドオン作者に対しての「簡単」という意味なので、アドオン作者が簡単に使えるAPIにするためにFirefox側が苦労するのは必要なコストである。(とはいえ、上記のメンテナンスコストの話もあるから、程度問題だとは思うけど。)
    • 上記の判断基準は、項目によってはゼロイチで判断できないので、そこはケースバイケースなのだと思われる。
    • 判断の基準の話題の中に「W3C」という言葉は出てこなかった。
      • セッション後にJorgeさんにその事を聞いてみた。大まかな話としては、W3CとFirefoxの都合(現実にあるアドオンを移行したいという都合)のどちらを優先するかについては答えが出ていないという事のようだった。
  • 新しいAPIの提案はBugzilla上でやってよい。
    • バグを立てたら[design-decision-needed]タグをWhiteboardに書いておく。これは自分で付けてよい。
  • 現在既にBugzilla上に提案があるものを叩き台にして、実際このAPIは有りか無しか? どうして必要なのか? という議論が行われた。
    • 法人利用の必要から自分が立てたバグはほとんどが「何々を無効化する」というような物なので、実際の所、それをやる別の手段(例えばActive Driectoryのグループポリシーなど、設定で機能を無効化できるようになるなら)があるならWebExtensionsである必要はない。今までは「そういう機能はFirefoxには入れられない」と言われても「じゃあアドオンでやります」と言えたので、こちらも簡単に引き下がれた。WebExtensions化後はそういう次善の策を取れなくなるので、APIとしてとりあえず提案してみたという状況である事を話した。
      • この後、法人利用とグループポリシーの事について議論が交わされていたが、英語のスピードが速くて付いていけなかった……でも「そういう問題で困っている人が実際ここにいる」という事のアピールはとりあえずできただろうか。
    • Back to Owner Tabのような機能をやるにはフックを仕掛けられる必要があるのではという事を話したら、AdBlock Plusの作者の人から「それは履歴に偽の項目を挿入することでできるのでは?」という提案をもらえた。なのでこれは試してみないといけない。
  • 軽量テーマのインストールを可能にするAPIの提案についての議論の中で、「見た目はユーザの関心のかなり大きな部分を占めている」みたいな話になったようで、現在WebExtensionsへの移行の障害になっているっぽいアドオンの代表としてStylishとTree Style Tabの名前が挙がっていた。
    • CSSの指定を反映するという物をどうやってWebExtensionsのAPIに持っていくのか?という事の議論がヒートアップしていた用だけれども、やはりスピードが速くて付いていけなかった。
    • ただ、個別の技術の話にフォーカスしていたようだったので、「必要なのはアドオン同士の互換性で、それが維持できるならCSSである必要はない。CSSは単に今使える技術というだけの事。」という事を言った後、FirefoxのUI要素のエイリアスを作れるようにするという案を紹介した。言いたい事がちゃんと伝わっているといいんだけど。

アドオン同士の互換性と、単機能アドオンについて

セッションとは別の時間で、AndrewさんJorgeさん、ハイブリッドアドオンの発表をされていたLucaさんと個別に話して以下のような事を伝えた。

  • Tab Mix PlusやAll-in-one Sidebarのようなオールインワン型のアドオンではなく、単機能の小さなアドオン同士を組み合わせて使えることが、ユーザにとってもアドオン開発者にとっても望ましい。
    • 実際にXUL/Migemoを例として挙げて、これはFirefox標準の検索機能を少しだけ変更する物だが、同じ事をやるのに検索ツールバーを丸ごと再実装しないといけないとなると、それはもう他のアドオンと連携できない。という事を説明した。
    • UIに依存しないAPIの案であることが求められているが、イベントリスナのようにフックを仕掛けるという方向で、今より多くのエントリポイントを設ける事はできるはず。
  • 「設定をON/OFFするような感覚でアドオンを気軽に試せる」というアイデアと、オールインワン型のアドオンは相性が悪い。
  • 一方で、オールインワン型アドオンが実際に必要とされてしまう現状もある。ユーザは自分で何が不満か分かっておらず、「何かお薦めは無いの?」と気軽に聞いてきてしまい、オールインワン型アドオンはそういう人に対してお薦めする物として便利な選択肢になってしまっている。
  • WebExtensionsのAPIは高レベルである事が求められているということだが、法人利用のサポートを通じて企業間で共通のニーズがある事が分かってきたので、それらを法人利用のコンテキストでの「高レベルのAPIのニーズ」として提案していきたい。

当初、自分がひどく誤解をしていて「Mozillaが音頭を取ってオールインワン型アドオンを排除していくのか?」のような受け取り方をしていたんだけど、それは本当にただの誤解だった。 高レベルなAPIという視点でどういうAPIを実装していくかという事と、それらのAPIを使って単機能のアドオンにするのかオールインワン型のアドオンにするのかは全く別のレイヤの話で、前述の基準にマッチするAPIのみに基づく限りであればオールインワン型でも存在としては許容される……と考えていいと思う。 「ニーズが減って、存在の必要がなくなって、自然とフェードアウトしていくのが望ましい」という点ではLucaさんとは意見が一致してたけれども、そのためにMozillaがAppleのAppStoreやGoogle Playのようになっていくという事が方針として示されているわけでは全然無かった。

台北チームの人と話した時にも「Mozillaは選択肢を提供するのがミッションだ」というフレーズが出てきていた。 合理的な理由があって選択肢が必要な人に対して選択肢を提供する事が大事で、どういう理由であればOKでどういう理由ではNGだという事についてはよっぽどの強い理由がない限りは踏み込まないのが、組織としてのMozillaの立ち位置だというのを折に触れて感じた。

Janitor、Firefoxのビルド環境をシェアするというアイデアについて

これはアドオンとは関係ない、というかFirefoxにすら限定されない全然別の話。

  • Janitorは、開発者向けのクラウドでCloud 9というサービスがあり、これのプラグインの仕組みを使って、FirefoxやThunderbirdの開発を楽にしようという試みである。
  • FirefoxやThundebrirdといった巨大プロダクトはビルド環境を整えるだけで非常に手間がかかる(ツール一式を揃えるのも大変だし、ソースコードのダウンロードだけでも滅茶苦茶時間がかかる。例えばFirefoxのリポジトリは10GBある)ので、「このバグを直してみたい」と思った時に気軽に始められない。そこで、構築済みの開発環境をクラウドで共有してすぐに使えるようにしておくというのが、Janitorの基本コンセプトである。
    • 開発環境はDockerコンテナになっている。DockerはCopy-on-writeで、コピー元に対して変更があった箇所だけを保存するので、巨大なサイズの開発環境のDockerコンテナを各自がコピーしてそれぞれ別の作業を行う、という用途に適している。
    • 具体的には、外部の開発者がBugzilla上の特定のバグを修正するために、環境を作ってバグを修正して差分をパッチとして提出する、というような使い方が想定される。
    • 開発環境としては、IDE的な機能、ファイルブラウザ、コンソール、エディタ、デバッガなどが備わっている。
    • 開発・ビルドだけでなく、ビルドされたFirefoxを仮想環境上で動かして試す事もできる。
      • VNCクライアントを用意する必要はなく、ブラウザ上のcanvas越しに仮想環境を操作できる。
  • 制限事項、不向きな用途もある。
    • 共有される開発環境はUbuntuベースなので、Windows版やmacOS版の開発はできない。isolatedな仮想環境なので、特定ハードウェアやGPUアクセラレーションに関わるバグのテストにも使えない。
      • あくまで、クロスプラットフォームな機能のテスト・開発用ということになる。
      • ビルドしたインストーラをダウンロードして手元の環境で動かしてテストする、という事(単なるリモートのビルド環境としての利用)はできる。
    • ユーザがコンテナ上で行った変更が増えてくると、Copy-on-writeで変更の差がどんどん大きくなっていくので、前述のメリットが薄れてくる。
      • コンテナをコピーしてバグを修正して、作業が終わったら環境を捨てる、というような短命の使い方(環境そのものをトピックブランチ代わりにする)に適している。コピーした環境のリポジトリを長期に渡って維持するような用途には向いていない。
      • Gitのリベースのような事(Copy-on-writeの基準となるリビジョンを、環境構築時のリビジョンからその時点での最新リビジョンに変更する)もいずれはできるようにしたいらしい。
    • 共有環境なので、秘密の情報を持ち込んでの開発には向いていない。
    • Cloud 9を使っているので、オンラインでなければ利用できない。
  • サービスとしては既にアルファ版が運用中。
    • Firefox、Thunderbird以外に、Google ChromeやKDEなどもホスティングしている。
    • 実際に既にそれらの製品のバグの修正にも使われている。
    • Vimなど、今はホスティングされていないプロジェクトも取り扱えるようにしていくみたい?(ここはよく分からなかったが、Vimなどのいくつかのプロジェクトの具体名は挙がっていた)

みんなでFirefoxのバグを直してみよう、みたいなハッカソンをやりやすくなるので面白い試みだと思う。

ただ、自分が仕事で関わるのは基本的にWindows版Firefoxなので、環境依存の問題の修正には使えないのが残念な所。 WindowsでのFirefoxのビルド環境は、Firefox自体のソースツリーだけでなく、WindowsのSDKなど数ギガバイト単位で色々なツールをダウンロードしないといけないので、構築がめんどくさい。 それを自動化するWindows PowerShellのバッチか何かがあるといいんだけど……(自分で作れって? ごもっともですハイ……)

英語について

これは全般的な話。

セッションやその他の議論の場では基本的に英語が公用語で、セッションによっては皆さん英語で熱い議論を戦わせていたのですが、自分はこのイベントの参加者の中では一番英語ができない方の人なので、「ああ、この話題について話していたのか……じゃあこういう事を言いたいなあ」と思った時にはもう話が次に移っているという感じでした。

ただ、英語がネイティブでない人もいて、アドオンチームのLucaさんはイタリアから、Jorgeさんはコスタリカからの参加だそうですが、彼らの英語は比較的聞き取りやすいかなと感じました。(逆に、USの人はスピードが速いし単語同士が明瞭に別れてない事が多くて辛かった。)

また、僕の語彙力が無くて言いたい事を上手く言えなくて詰まってしまったりよく分からない表現をしてしまっている時でも、「それはこういう事か?」と別の言葉で言い直してくれたりして、こちらの言いたい事を読み取ろうと向こうも合わせてくれる事が結構あり、「こいつの言ってる事はよく分からん」で放置されるという事は無くて、そこは非常に有り難かったです。

イベントへの参加が確定してから自分はBugzillaに多数のバグを報告していましたが、これは、口頭では言いたい事を上手く伝えられる自信がなかったからという部分が大きいです。 でもそのおかげで、セッション中にも「これだけのバグをここにいるPiroが報告してくれた」のように紹介してもらえて、それも辿々しい英語ながらも辛抱強く話を聞いてもらえた理由の1つなのかもなあと思いました。

まとめ(特にアドオン関係)

アドオンについては、「このアドオンがあるからFirefoxを使ってるんだ」という人がいる事について、「うるさい人達が多いからとりあえずポーズ示しときゃいいんでしょ、あーもうめんどくせえ」みたいな投げやりな感じではなく、Mozillaもちゃんと意識しているという印象を受けました。 XUL廃止・WebExtensionsへの移行、そしてW3Cでのワーキンググループといった諸々の情報から「アドオンに関してもFirefoxはChromeと同じになっていくのか?」という危惧がありましたが、それによってMozillaのユニークな価値が無造作に失われてしまうのは良くないという事はMozillaのアドオンチームの人達の頭にちゃんと入っているのだという事を、セッション資料の見出しの付け方や会話の内容などから感じられました。 ホッと胸を撫で下ろすまでには至らないものの、「ちゃんと声は届いていた」ということを、いちアドオン作者としてこの場で報告しておこうと思います。

自分の作っているTree Style Tabなんかは、eval()を使っているなど色々とお行儀が悪いし、Mozilla Add-ons上でも実験的アドオン扱いだし、移行において積極的に切り捨てて行かれる対象にされてもおかしくないと思っていたのですが、逆にセッションの中でTree Style Tabの名前が何度も出てきていて、「えっなんでみんなそんなに認知してるの」とこっちが驚いてしまいました。 何度か名前が出てきたLucaさんも個人的に使っているとか、他のセッションに参加した人がたまたま見かけたFirebugの開発者の人の画面内のFirefoxにツリー型タブが入ってたとか……バグ報告のメールなどでたまに「Mozillaの中でも使ってる人がいる」という事をMozillaの人から言ってもらっていたりはしていたものの、「いやーでも所詮はねぇ」と思って悲観的な見方をしていたのですが、実際にこういう場で名前が出てくるんだというのを目の当たりにして、非常に感慨深かったです。

また、元々はそういう感じで個人制作のアドオンがきっかけで招待を受けたという事のようでしたが、仕事でやってる法人向けの作業内容についても便乗で言及する事ができて、具体的な確約であったり意志決定だったりといったものには繋がらないまでも、「実際にそういう使い方をしている人がいる・そういう使われ方がある」という事について認知を広められたのではないかと自分では思っています。 法人利用の話はユーザ数や具体的なユースケースなどについてMozilla側に伝わらない(伝えられない)部分が多く、Mozilla内部でも部門やチームとして法人利用専従の人がいるわけではないのが現状のようなので、実際に手を動かしている人達と直接話ができて良かったです。

技術の話以外にもMozLondonについては色々イベントレポートとして書いておきたい事があるので、それは別のエントリに分けて書こうと思います。

エントリを編集します。

wikieditish message: Ready to edit this entry.











拡張機能