“You Should Probably” は、インターネットの時間つぶしを知らせてくれる

誰もがデジタルな悪癖を持っている。気づけばぼんやりと見続けているサイト。あなたの時間を奪い、一日なにをしていたのか心配になるサイト。紫色のリンクをクリックするばかりでto-doリストを消せない日々。

ある人にとって、それはHacker Newsであり、他の人にとっては,MetafilterかFacebookだろう。おっと、人によってはTechCrunchかもしれない。私の場合は、Redditだ。

You Should Probably“は、 時間を無駄にしているサイトからあなたを引き離してくれる、Firefoxの拡張機能だ。

LeechBlock (Firefox) やNanny (Chrome)とは異なり、”You Should Probably” はサイトを〈ブロック〉しない。代わりに、大きくて鮮やかな消去可能なバナーを、あらかじめ選んでおいた時間つぶしサイトの上に表示して、何か他にすることがあるかもしれないことを思い出させてくれる。

“You should probably go read a book,” [本でも読んだ方がいいんじゃない]とか、 “You should probably go outside and take a walk.”[外へ出て散歩した方がいいんじゃない]とか。

バナーは自由にカスタマイズ可能で、どこのサイトにでも表示できる。

バナーを無視して今やっていることを続けたければ? そうすればいい — ただし意志を持って決めること。これは、厳格な親ではなく、親切な(でも不機嫌そうな)友達だ。バナーはページのトップに表示され、多くのサイトで主要な内容をブロックするので、必ず目に止まる。

この、口やかましさとブロックの違いこそ、私がこのアイデアを〈大好きな〉理由だ。これまでいくつもブロックする拡張機能を使ってきたが、必ず数日後にはアンインストールしていた。1分間生産性を高めてくれるかわりに、何らかの正当な理由によってサイトに行く〈必要がある〉場合に、2分間イライラさせてくれるからだ。時間つぶしサイトの問題は、〈選んで〉そこへ行く場合ではない。生産性スランプに陥り目もうつろな時、気づけばそこにいたときだ。大して空腹でもないのに、1時間に冷蔵庫を8回開けるようなものだ。

私の望みは、to-doリストの項目をこなすことだけ。「ほら、どうせ明日には忘れている〈今日わかった新事実〉を読もうとしている? 〈You should probably〉6日前からto-doリストにあるあのメールを書いた方がいいんじゃない」

私の知る限り、今のところこの拡張機能はFirefoxのみだ。もし、Chromeにも同じようなものがあれば、この記事のコメント欄で知らせてほしい。

原文へ
 
(翻訳:Nob Takahashi)


Mozillaからの企業や広告業界への要求: 消費者のプライバシーを犯さない個人化技術を採用せよ

Mozillaが今進めているプロジェクトが完成すると、ブラウザがユーザのすべての関心事のリストを収める中心的なリポジトリになる。今日(米国時間7/25)Firefoxブラウザの非営利の母体的団体Mozillaは、多くのWebサイトで個人化が進んでいるが、しかしそのために、“ユーザが知らず知らずのうちに自分の個人情報その便利な機能のいわば代価として払っている場合が多い”、と論争を挑んだ。個人の関心グラフをオンラインで多くのベンダと共有するのではなく、Firefoxのやり方ならユーザの閲覧履歴を見るだけで趣味や関心事を見抜ける、と。

Mozillaは前にもこのアイデアを提唱したことがあるが、今日の提案はMozillaが広告業界と、クッキーやDo Not Trackトラッキング拒否)の取扱いについて長らく議論している最中に行われたのだ。

この提案は、ユーザが、自分が訪れたWebサイトと自分の関心を共有する場合は、それを明示的かつ透明に(==自分に分かるように)行われるべきだ、という主張に基づいている。Webサイトは、ユーザの関心事に関する個人プロファイルを密かに勝手に作らなくても、個人化は十分にできる。そのような個人化なら、ユーザがそのサイトを初めて訪れた場合でも可能だ(閲覧履歴が見られるならば)。

“Web上の対話的な活動に個人が明示的に参加することによって、欲しいものを容易に得られるようになるべきだ。その参加の仕方も、ユーザに見えない楽屋裏部分があるのではなく、その全体が明示的に定義されていなければならない”、Mozillaの企業および法務担当SVP Harvey Andersonが、今日そう書いている。“Webサイトのコンテンツの個人化とそれに関連したイノベーションはすべて、ユーザの体験の質を上げるものでなければならない。そのためには、個人化を行おうとする側が消費者に、彼/彼女にどれだけの個人情報を公開する意思があるかを問う、明確なオプションを提示すべきである。サイトは、それに基づいて、もっとも適切なコンテンツやサービスをユーザに提供するものでなければならない”。

Mozillaはこの考え方の実装を目下実験中だが、誰もが利用できる公式の実装が提供されるのはまだまだ先のようだ。Mozillaがこれについて初めて語ったときにはしかし、Webサイトはユーザの個人的情報を勝手に記録すべきでないし、どんな情報を共有するかしないかはユーザ側が完全に決められるべきだ、と述べていた。しかしそのことを、企業の善意と良心と良識にだけ依存して実現するのは、とても難しいだろう。

しかし当面Mozillaは、とにかくこの問題について会話を始めよう、という姿勢だ。広告業界もMozillaには一目置いているから、会話ならそんなに難しい課題ではないと思われる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Chrome 29ベータはAndroidにWebRTCとWeb Audio APIを実装, デスクトップではOmniboxを改良

Googleが今日(米国時間7/16)、Chrome 29のデスクトップAndroid用バージョンのベータをリリースした。とくにAndroid版に重要な変化があり、オーディオ合成処理のためのWeb Audio APIと、リアルタイム通信のための最新API WebRTCをサポートしている。

デスクトップ版(Windows、Mac、Linux)のアップデートには、omniboxの改善提案が取り入れられ、ユーザが最近訪れたWebサイトが尊重されるようになった。このほかデスクトップバージョンでは、WebMによるビデオ再生でGoogle自身のVP9コーデックがサポートされた。


ただしWeb Audio APIが当面使えるのは、NEONオプティマイゼーションをサポートするARMデバイスのみである。これは、ARM Cortex-A8プロセッサで導入された新しい命令を実行する方法のことだ。Web Audio APIをサポートしている実機の上では、ここでそのデモを楽しめる。デスクトップのChromeでは、かなり前からサポートされている。またiOSと、今回のAndroid用ベータもサポートしている。

なおFirefoxは、先週のNightlyがこのAPIをサポートしている。

WebRTCは、このAPIを使うとビデオとオーディオによるリアルタイム通信がプラグイン不要でできる。それが、今回はAndroid用ベータでサポートされた。デスクトップのChromeは、このAPIを早くからサポートしたブラウザの一つだ。実装が今後さらに普及すれば、多くのデベロッパの関心がそれに向かい、Webブラウザのほとんど標準的な機能になるだろう。ChromeとFirefoxはすでにサポートしているが、MicrosoftはInternet Explorer 11までお預けのようだ。

WebRTCに関しては、Googleのビデオチャットのデモがここにある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Firefox 22安定版リリース―asm.jsとWebRTCをサポートでウェブ・アプリ開発全般にも大きな影響

今日(米国時間6/25)、MozillはFirefox 22リリースした。これはWebRTCプロトコルasm.js JavaScriptサブセットをサポートする最初の安定版Firefoxだ。

Microsoftの場合を除けば、現在、ブラウザのアップデートは日常的ルーチンになっている。しかし今回のWebRTCとasm.jsの追加は今後のウェブアプリの開発のあり方を大きく変える可能性がある。当面Firefoxをターゲットにしていないデベロッパーもこの変化には注目しておく必要があるだろう。

 

ビルトインWebRTCのサポート

デベロッパーはWebRTCを利用してビデオチャットや音声通話、ファイル共有などの機能をビルトインしたアプリを開発することができる。サードパーティのプラグインやソフトウェアを組み込む必要はない。Tokboxを始め多くの企業がWebRTCに社運を掛けている。しかし現在までWebRTCをサポートする有力ブラウザはGoogle Chromeだけだった。今回Firefox安定版がWebRTCをサポートしたことでスタートアップも既存大企業もこぞってこのテクノロジーの利用を始めるだろう。今のところMicrosoftだけがWebRTCとは異なる規格の採用を決めているが、将来Internet ExplorerにもWebRTCが採用される可能性は大いにある。

asm.js

asm.jsもゲームのルールを変える可能性のある重要なテクノロジーだ。われわれが3月の記事で詳しく紹介したとおり、asm.jsはJavaScriptのサブセットで、ウェブブラウザ内でネーティブアプリに匹敵する高速で作動する。MozillaのCTO、BrendanEichは私の取材に対して、「メモリが安全ではないC、 C++のような言語に対して安全なバーチャルマシンを構成できるJavaScript言語のサブセットだ」と説明した。EmscriptenのようなC and C++をasm.js向けにコンパイルできるツールのおかげで、デベロッパーは既存のC、C++プログラムをブラウザ内で安全に作動させることができるようになる。

この新機能はMozillaのBananaBreadゲーム・デモで試すことができる。このデモにはWebGL、Emscripten、asm.js、WebRTCが使われており、ハイエンドの3Dマルチプレイヤー・ゲームをブラウザ内で高速に作動させることができることを証明している。

その他Firexfox 22ではWebGLのレンダリングのパフォーマンスの向上などいくつかのマイナー・アップデートがある。詳細なリリースノートはこちら

[原文へ]

(翻訳:滑川海彦 Facebook Google+


Internet Explorer 10の消費電力はChromeやFirefoxより18%低い, とMicrosoftは主張

Microsoftが行った委託研究によると、合衆国のChromeとFirefoxユーザの全員がブラウザをWindows 8上のInternet Explorer 10に換えたら、合衆国の1万世帯ぶんの電力を節約できる。Microsoftによるとその理由は、同社はIEの高速化に力を入れてきたしまた、IEはネイティブのグラフィクスカードなど現代的なPCのハードウェアの能力を有効活用して、レンダリングのパフォーマンスを向上させているからだ。

しかし率直に言って、ブラウザについて考えるときその電力消費を気にする人はあまりいない。研究のテーマとしてもかなり異例だと言えるが、でもたしかに、Webの閲覧に費やされる時間は最近とみに多いから、研究が言うようにIEの電力消費がCやFよりも18%少ないなら、それはIEの無視できないメリットには違いない。

Microsoftによると、IEに切り換えると1億2000万キロワットアワー(kWh)の電力が節約され、また220万本の木を苗木から10年育てた期間に相当する二酸化炭素の除去量が達成される。

Microsoftは2011年にも同種の委託研究を行い、IE9はFirefoxやChrome、Safari、Operaなどよりも優れている、とした。今回の研究では、人気上位のWebサイトを対象にベンチマークが行われた。また、FlashやHTML5によるビデオも、多数再生された。

しかし研究とその結果はまともなものだとは思うが、省エネを動機としてChromeやFirefoxからIEに切り換えるユーザは、あまりいないだろう。でも、今MicrosoftはIEのイメージアップとシェア奪還に躍起になっているから、そのためのマーケティングキャンペーンのネタとしては、とりあえず理解できるけどね。


[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


次世代Firefox v.25のデザインはChrome風―メジャーアップデートのNightly版公開へ

数日前、MozillaのFirefoxエンジニアリング担当副社長、Jonathan Nightingaleは私の取材に対して新しいFirefoxを説明し、「もうこれはブラウザとは呼べないかもしれない」と述べた。

Nightingaleは、「ブラウザというのはすでに語感が古臭い。ユーザーはブラウザで以前ほどウェブサイトをブラウズしない。ブラウザは高度なウェブ・アプリを動作させたりソーシャル・ネットワークにアクセスしたりする手段としてもっぱら使われている」という。つまり開発者はブラウザの利用法の大きな変化に対応して、ブラウザのあるべき姿を考えなおさねばならないということだ。

コードネームはAustralis:タブは角丸に、機能は単純に

Mozillaの未来型ブラウザ計画はAustralisと呼ばれている(Mozillaはプロジェクトのコードネームに星の名前をつけるのが好みのようだ〔タニア・アウストラリスはおおぐま座の連星〕)。このプロジェクトの成果は近くFirefoxのNightly版v.25として公開される。その後、Firefoxの通常のリリース・チャンネルで公開され公開され、最終的には安定版での公開となるはずだ。

ただしNightingaleによればこのバージョンが安定版として公開されるまでにある程度時間がかかるかもしれないという。

冒険をいとわないユーザーならMozillaのあまり知られていなUX部門から開発途上版をダウンロードしてインストールできる(ただしその結果クラッシュするのはもちろん、HDDがずたずたになるなどの事態が起きても自己責任で)。

ではAustralisとは何か? 従来のFirefoxよりGoogle Chromeに似ているというのが第一印象だ。 現在のAustralisのテーマは角を丸めたタブでその下にURL窓、検索窓、各種アイコンと並ぶ。右端は三本の横棒のアイコンの設定オプションだ。

Nightingaleによれば、Australisのコンセプトは「できるかぎり高機能化すると同時に操作をできるかぎり単純化する」ことだ。このため開発チームはユーザーが実際にブラウザをどのように操作しているか詳しく観察した。新デザインは明快で直感的になっているという。たとえば、現在のデザインでは選択されていないタブは枠も表示されず、アイコンだけを残して背景に溶け込んでしまう。Chromeでどんどんタブを開いていくとやがてタブの表示幅が狭くなりすぎてアイコンも見えなくなってしまうが、Australisではタブの最小幅が設定されており、タブの数が表示の限界を超えるとタブ・バーがスクロールできるようにした。

AustralisのUIテーマが安定版に実装されるのは10月以後になるということだが、 Nightingaleは「現在公開されているバージョンもAustralisのデザイン・コンセプトの影響を受けている」と強調した。「読込中止、読込、再読込」がひとつのボタンに統合されたのもその一例だという。

またこうした新デザインはAndroid版Firefoxにも用いられている。このアプリは4000万ダウンロードを記録しているという。念のために付け加えるとMozillaは現在でもiOS版を諦めたわけではない。しかしAppleの現在のApp Storeの約款ではMozillaとしてiOS版をリリースすることはできないのだという。しかしMozillaチームはブラウザ以外の分野でのiOSアプリの開発を考えているようだ。

カスタマイズ

Australisの単にUIデザインの改良だけではない。ルック&フィールを含めたブラウザのカスタマイズの方法も大きく変わる。Mozillaは現在多様なカスタマイズ・ツールを提供しているが、必要なツールが探しにくく、使いやすさも高いとはいえない。MozillaのGavinSharpは私の取材に対して「ここでの目的はユーザーがそれぞれのニーズに合わせて簡単にカスタマズでできるようにすることだ。しかしせっかくのカスタマイズ機能もユーザーが存在に気づかなければ意味がない。われわれはユーザーがFirefoxのほとんどあらゆるパーツを自由に削除、追加、配置できるようにし、またそのカスタマイズ機能を今までよりユーザーの目につきやすいようにすることにした」と語った。

もちろん未来のブラウザを作るにはデザインだけでは足りない。MozillaではユーザーがSocial APIのようなツールをどのように利用しているか詳しく調査している。またパフォーマンスの改善のためにはOdinMonkeyやasm.jsのプロジェクトを実施している。

とはいえ、Australisが公開されたときにユーザーがまっさきに気づくのは新デザインだろう。率直に言ってChromeとの類似を否定するのは難しい。この点をめぐっては間違いなく賛否の論議が巻き起こるに違いない。

[原文へ]

(翻訳:滑川海彦 Facebook Google+


BlinkとServoとRust: ブラウザの次の進化の方向性が見えてきた

先週は、ぼくのようにブラウザを追っているブロガーにとっておもしろい週だった。週の終わりには、Internet Explorer 11がWebGLとSPDYをサポートするらしい、という話も聞いた。その前の火曜日にはMozillaがメールで、MozillaのCTO Brendan Eichへの電話インタビューの可能性を打診してきた。その話題は次世代のブラウザエンジンServoと、それが書かれているプログラミング言語Rustだ。しかしMozilla Researchが単独でこれらを手がけているのではなく、この、マルチコアプロセッサと異種混成的なアーキテクチャ向けに最適化されている新型エンジンをAndroidとARMに実装する作業には、Samsungが協力しているのだった。MozillaはこれまでServoについてあまり何も発表しなかったから、今こうやって大きく発表することは少々意外だ。

おもしろいことに、GoogleのChromeのチームが話をしたいと言ってきたのも、先週の火曜日だ。おかしなことに、そのときの広報の連中は、いつもと違って、詳しい話を何もしない(通常は、何の話かぐらいは事前に教えてくれる)。Googleのエンジニアリング担当VP Linus UpsonとOpen Web PlatformのプロダクトマネージャAlex Komoroskeは、WebKitをフォークしてWebKitベースの独自のレンダリングエンジンBlinkをローンチする、と言った。ぼくは自分が話を聞き間違っていないか気になって、何度も彼らに念を押した。WebKit開発の外部の人間ににとっては、GoogleがWebKitの本流を去るという話を、にわかには信じられない。一般的にWebKitは、ChromeとSafariのおかげでデスクトップとモバイルで大成功した、と見られている。それを独自フォークする理由が、思い当たらない。

でもBlinkは正しい

だからGoogleのWebKitフォークは先週のいろんな発表やリークの中で、いちばん話題になった。Googleはフォークの理由を純粋に技術的なものと言うが、WebKitは今でもAppleとGoogleが仲良くやっている数少ないものの一つだから、政治的動機も疑われる。しかもWebKitへのコード貢献量は、このところGoogleが最大なのに。

今後の成り行きを予言するのは早すぎるが、ぼく自身はかなり楽観的だ。たしかに、Webデベロッパが自分のコードを試験すべきレンダリングエンジンが一つ増えてしまう。でもChromeのチームによれば、それは彼らにとって“苦渋の決断”だった。Googleはレンダリングのスピードを上げたいが、WebKitは今いろんなブラウザで使われている。だから、WebKit本流における抜本的な改作は難しい。

Chromeのチームは、“ブラウザが複数あることと同じく、レンダリングエンジンも複数あった方が、今後の健全なイノベーションを刺激し、オープンなWeb全体のエコシステムの健康にとって良い”、と考えている。たしかに、そのとおりだろう。2008年にChromeが突然現れてから、ほかのブラウザのイノベーションは加速した。当時の競争の中心は、高速なJavaScriptエンジンの開発だった(そしてWebKitを使っているブラウザも、JavaScriptエンジンはそれぞれ違っていた)。BlinkとServoという新しい馬が走り出した今は、レンダリングエンジンも重要な競争の要素になり、そしてその競争は、より速くてより安定的なブラウザを求めるユーザとデベロッパに利益をもたらす。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Firefox 20がローンチ: プライベートウィンドウ, ダウンロードマネージャの刷新, WebRTCとHTML5の実装が充実, など

Firefox 20がリリースされ、今日(米国時間4/2)からダウンロードできる。この新バージョンの最大の目玉は“プライベートウィンドウで開く”という閲覧モードができたことだ。これでデスクトップのFirefoxユーザは、ブラウザを終了しなくてもプライベートウィンドウを開けるようになった。またFirefox for Androidのユーザは“プライベートタブ”を開ける。このほか新バージョンでは、デスクトップのダウンロードマネージャが改良され、モバイルではホーム画面のショートカットにお気に入りのサイトを置け、そしてHTML5とWebRTCのサポートがさらに充実した

Firefox for Androidの新バージョンは非力なARMv6プロセッサを使っているデバイスもサポートする(Samsung Galaxy Next, Dart, Pop, Q; HTC Aria, Legend; ほか)。

プライベートウィンドウ/タブについてMozillaは、“それまでの閲覧を妨害されずにお誕生日プレゼントの買い物をプライベートウィンドウでできる。複数のメールアカウントを同時にチェックできる”、という説明をしている。

でも、ユーザが最初に気づく機能は、新しいダウンロードマネージャだろう。下のビデオはそれを解説している:

デベロッパ向けには、今度のバージョンでWebRTCのgetUserMediaがサポートされた。これを呼び出してデベロッパはユーザのカメラやマイクにアクセスできる(パーミッションがあるなら)。HTML5では<canvas>でブレンドモード(色を重ねる)がサポートされ、また<audio>と<video>の実装が改善された。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


MozillaがFirefoxのデベロッパツールの充実に注力: ブラウザ内エディタ, Firebugの統合, ネットワークパネルなどなど

先週、MozillaのテクノロジエヴァンジェリストPaul RougetがWebデベロッパたちに、Firefoxの開発ツールとして何が欲しいか、という質問をTwitterやHackerNewsで投げかけた。そのフィードバックに基づいてFirefoxのDevToolsチームは、今後のFirefoxの安定版に盛り込むべき新作または改良版のデベロッパ機能の数々を構想し、それらのプロトタイプ作りに取り組んできた。

Rougetが書いた記事によると、リクエストでもっとも多かったのは、ブラウザ内でコードを書けて、そしてエディタやIDE(統合開発環境)からブラウザをコントロールできることだ。このリクエストに対してチームは今、二つのやり方を検討している。DevToolsのチームは人気の高いSublime TextエディタとFirefoxに本来あるリモート機能を利用するライブエディティングの概念実証を作った。しかしMozillaはそのほかに、Firefoxの中にエディタを置くことも検討している。

Mozillaがブラウザ上のエディタを考えたのは、これが初めてではない。2009年にMozillaは、Bespinというものに取り組んだ。それがのちにSkywriterになったが、このプロジェクトは今休眠している。しかしCSSとHTMLによるエディタThimbleは、Mozillaが再び取り組んでおり、RougetはDevToolsの作品がエディタのメインのような書き方をしているものの、ブラウザ上のテキストエディタに関してはMozilla本体にも相当な経験と知識があることは確かだ。

デベロッパたちのもう一つのリクエストは、Chrome的Firebug的なネットワークパネルとタイムラインだ。チームはすでに、Webアプリケーションがネットワークをどのように使っているかを容易に見るためのツールの、プロトタイプを開発した。

Firefoxのチームは、ブラウザの互換性の向上にも取り組んでいる。Rougetによると、現状は“FirebugのユーザにとってFirefoxのDevToolsは邪魔者”という状況なので、それを何とかするためにMozillaは、コンテキストメニューの”inspect”メニューをディスエーブルにできるようにする。またFirebugをDevToolsのボックスに統合する方法も検討中だ。

そのほかにチームが今取り組んでいるのは、ブラウザの右側にドックツールを置けること(Firefox Nightlyではすでに実装)、CoffeeScriptのサポート、最小化したCSSとJavaScriptファイルのデバッグ、ページ上のリペイントされた部分が分かること(これもFirefox Nightlyにはある)。

Rougetによれば、チームはそのほかの機能にも取り組んでいる(イベント結合の視覚化、オフラインのストレージツール、擬似要素の検査、など)。

以上はどれも、すぐに実現するというものではなく、プロトタイプを脱するのに数か月かかりそうなのもある。でもデベロッパにとっては、こうやってMozillaがデベロッパツールの改良に励み、競合に負けまいとしている姿は大歓迎だ。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


TokBoxのWebRTCによるビデオチャットがFirefoxのNightlyとAuroraに対応

tokbox_firefox_logo

スペインのTelefónicaが2012年に買収したTokBoxは、ビデオチャットサービスの中では早くからWebRTC(Web Real-Time Communication API)を採用した企業の一つだが、今WebRTCは、プラグインが要らずブラウザ本体の中でビデオやオーディオのリアルタイム通信ができる技術として、標準規格の整備が急がれている。TokBoxは、今年初めにChromeで使えるようになったのに続き、今日(米国時間2/25)はMozillaのFirefoxにも対応した。ただしFirefoxの最終安定バージョンではなく、先進機能をテストしているバージョンであるAuroraとNightlyにおいてだ。そこでFirefoxのデベロッパたちはTokBoxのWebRTCバージョンであるOpenTokプラットホームを利用して、自分のアプリにビデオ通信機能、たとえばビデオチャットなどを実装できることになった。そのチャットは今や、iOSとChromeとFirefoxのユーザ間で可能だ。

WebRTCがFirefoxの先行リリースバージョンに載ったということは、安定リリースバージョンではバージョン21か22あたりでWebRTCがサポートされるのかもしれない(今はバージョン19)。

tokbox screenshot

TokBoxのCEO Ian Smallの話では、同社がMozillaとの共同作業を開始したのは昨年の11月ごろだ。彼のチームはMozillaによるWebRTCの実装に初期段階からアクセスできることになり、実装の安定化に向けてのMozillaの努力につきあってきた。TokBoxのOpenTokプラットホームは、デベロッパがWebRTCのブラウザごとの実装の違いを気にする必要がなく、またビデオを大量のビューワにブロードキャストしたり、ビデオを録画するなど、ふつうのブラウザネイティブのWebRTCアプリケーションにはないようなサービスも提供している。OpenTokは、同社(TokBox)によれば、7万あまりの企業や団体が使っており、その中にはMajor League Baseball、Ford、Bridgestone、それにリモートプレゼンスを提供するスタートアップDouble Roboticsなどがいる。

Smallによると、“Firefox 21(近未来)とChrome 25(現在)の間で、安定的な相互運用性が得られるようになるだろう”、という。彼によると、WebRTC自身がまだ幼児期であり、ブラウザ内のネイティブバージョンを使って2人の人間のチャットは可能でも、グループチャットや録画は多くの実装がサポートしていない。またWebRTCの標準規格も、それらの機能ははサポートしていない。またTokBoxにおけるSmall自身のWebRTC体験に基づくと、その仕様はGoogleのVP8形式以外のビデオコーデックにも対応すべきだ。そしてまた、アプリケーションがユーザにより多くの帯域を許容できるために、帯域の割り当てをWebRTCの標準規格に(標準機能として)盛り込むべきだ、と彼は語った。

このように、課題や問題はいろいろあるけど、Small曰く、今年の後半はWebRTCがデベロッパ界隈で本格普及期に入る。今やモバイルでもデスクトップでも、主なブラウザがすべて、WebRTCをサポートしているのだから。

[原文へ]

(翻訳:iwatani(a.k.a. hiwa))

Firefoxの先行テスト版がWebRTC, H.264, MP3をデフォルトでサポート

Mozilla_Nightly_icon_2011

Firefoxブラウザのテスト専用の先進的バージョンFirefox Nightlyで、WebRTCがデフォルトでサポートされた。WebRTCは、プラグインなしでブラウザ自身がリアルタイムのUDP通信を行う規格で、とくにオーディオやビデオによる対話やコンテンツ配布に適している。これまではFirefox Nightlyのオプションとしてサポートされていたが、これがデフォルトになったことにより、数か月後には安定版(正規リリース版)の工程に組み入れられることが期待される。

MozillaのPaul RougetとRober Nymanが今日の発表声明の中で、“これは大きな前進である。これにより特殊な設定や構成を必要とせずにWebRTCを直接、Webブラウザの中で動かせるようになる”、と書いている。

おそらく今年いっぱい、WebRTCがにぎやかな話題になるだろう。主なブラウザがこぞって、その実装を開始しているからだ。Chromeはすでにバージョン23から安定版でWebRTCをサポートしており、最近Mozilla とGoogleは、二つのブラウザのユーザ同士がWebRTCを使って対話できる、というデモを公開した。

なお今回のFirefox Nightlyでは、H.264とMP3形式がサポートされる。ただしデコードはオペレーティングシステムが行い、今はWindowsの7以上のみでサポートされる。MacとLinuxのサポートは、目下開発中だ。

Mozillaが今週初めに発表したように、このNightlyリリースはWindows 8のMetroインタフェイスをサポートしている。

WebGLのデモも…

ちょっと関係のない話題だが、Mozillaは今日(米国時間2/20)、WebGLの すばらしいデモ発表したACTISKUのAnthony Liotが書いたこのデモは、Webブラウザもついにここまで来たか!と思わせる最先端のグラフィクスであり、しかもデベロッパはプラグインに依存せずにクロスプラットホームな体験をユーザに容易に提供できる。ただし現状では、Internet ExplorerがまだWebGLをサポートしていない。

webgl_demo_actisku

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

Firefox 19がHTML5だけによるPDFビューワを搭載, Androidバージョンはテーマをサポート

Subway1.png-600x311

長く待たされたが、やっとFirefoxブラウザの本体がPDFビューワを内蔵した。それまではベータだけだったが、今日(米国時間2/19)のFirefox 19安定版のローンチ(Windows, Mac, Linux)により、そのHTML5によるPDFビューワが一般的に可利用となる。このPDFビューワはPDF.jsと呼ばれる研究プロジェクトから生まれ、HTML5の標準APIを使ってブラウザが迅速に標準のPDFファイルを描出する。Foxit ReaderSumatra PDFなどのプラグインはもう要らない。

GoogleのChromeにはかなり前からPDFビューワがあり、それに比べるとMozillaはかなり時間がかかった。いずれにしてもそれは、Firefoxの機能として大歓迎であり、またその出来栄えも良い。ただしプラットホームによってはフォントのレンダリングがややおかしい場合もある。

Firefox 19に加わったそのほかの機能は、その多くがデベロッパ向けで、たとえばCSSの@page成分のサポートや、内蔵デバッガ(ブラウザやアドオンのデベロッパ向け)のアップデートなどだ。リリースノートの全文は、ここで読める。

pdfjs-2

Android用Firefox 19

Android上のFirefoxに関してMozillaは、CPUの性能要件を600MHzへ下げた。Firefoxのチームによると、これにより、LG Optimus One、T-Mobile myTouch 3G slide、HTC Wildfire SとZTE R750などおよそ1500万あまりのデバイスで動くようになった。.

さらにまた、モバイルバージョンがテーマをサポートすることになったので、モバイルブラウザのカスタマイズがある程度できる。中国語は、繁体と簡体の両方をサポートするようになった。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))

WebKitの独占状態の是非

icon-goldOperaが自前のレンダリングエンジンの開発を停止し、オープンソースのWebKitエンジンを採用することにしたというニュースは各所から大いに注目を集めた。WebKitはGoogleのAndroid向けブラウザでも、またAppleのiOS向けブラウザにも採用されている。すなわちモバイル環境においては、既に事実上の標準の地位を獲得している。そしてさらにその触手をデスクトップ環境にも伸ばしつつあるところだ。既にChromeは、Tridentを採用しているMicrosoftのInternet Explorerや、MozillaのGeckoを採用しているFirefoxと比べてかなりのリードを獲得している。こうした状況の中で、頭に浮かぶ疑問がある。各社が独自のエンジンを開発して、競い合う環境の方が良いのか、それともWebKitを標準として各社に採用してもらう方向が望ましいものなのだろうか。

WebKitはオープンソースのプロジェクトであるので、誰でも開発に参加することができる。Google、Apple、Mozilla、Microsoft、Opera、あるいはブラウザ関連のさまざまな企業が参加しているので、標準的に採用される技術を即座に実装することができる。レンダリングエンジンが統一されることで、開発者の苦労は大いに低減されることとなる。レンダリングエンジンの違いによる細々とした表示スタイルの違いに頭を悩ませないで済むようになるわけだ。

Hacker Newsのスレッドにも多くのコメントが寄せられている。WebKitの開発に集中することで、多くのイノベーションが生み出されるのであれば、WebKit独占の状態は開発者にとっても利用者にとっても良いものとなる可能性があるという論調もみてとれる。

こうした独占に向けた流れに抵抗する筆頭はMozillaだ。これまで独自のGeckoエンジンおよび、その後継となるServoに多大なリソースを割いてきた。Mozilla CTOのBrendan Eich曰く、Mozillaの存在意義をかけて独占には抗っていくつもりだとのこと。また、MozillaエンジニアのSteve Finkは、モバイルかデスクトップかを問わず、WebKit独占を許してしまえばイノベーションが阻害され、少数企業によるプラットフォーム独占を惹起してしまうと述べている。そのような状況になれば、結局は各社利益を追求する迷惑な混乱に支配されてしまうことになるとも述べている。

しかしWebKitはオープンソースであるので、もし開発が滞ったりあるいは特定のステークホルダーが開発を政治的理由によって妨害するようなことがあれば、即時に開発の道筋を分岐させることができるので、独占による悪影響などはないと考える人もいる。

From Google's Chrome Launch Comic Book

但し、ウェブの世界ではこれまでにも「独占の弊害」を経験したことがある。IE5やIE6の時代(Netscapeが舞台を去り、そしてIEは6のリリースが2001年で、IE7が登場したのは2006年だった)には、完全に「停滞」状況になっていた。そうした状況の中、2004年あたりからはFirefoxがスタートし、そしてWebKitをベースとしたGoogleのChromeも2008年に登場してきたのだった。Chromeのミッションはレンダリングエンジンの標準化を試み、そしてJavaScriptの高速化を行うということだった。独占を崩す存在が登場してきたことにより、ウェブプラットフォームは現在のような応用環境に進化したのだとも言えるだろう。

「ウェブ」が今後戦っていく相手は?

Operaは、「独占状態は良くない」と主張しつつ、その言葉とは正反対にも見える道を歩むことになった。Operaもそれなりのシェアを獲得しているにも関わらず、「多くの開発者たちがWebKitのみをターゲットに開発をしているという現状があります」と述べ「先頭に立って独自の道を追求していくことにメリットは少ないと判断しました」とのこと。

Operaの選択した方向は興味深いものだ。結局のところ、ウェブ技術は各社のレンダリングエンジンの違いで競っていくのではないと判断したわけだ。今後の競合相手はネイティブアプリケーションであると判断したわけだ。Operaは「閉鎖的な“アプリケーション”に対抗して、オープンなウェブ技術を推し進めていくつもりだ」とのこと。その戦いを効率的・効果的に進めていくためにWebKitの採用を決めたということだ。

開発者と利用者の着眼点の違い

理想を言えば、さまざまなベンダーが「標準」に則った開発を行って、レンダリングエンジンの違いによる差異などを意識しないで済むというのが良いのだろう。同じコードは同じように表示されるべきだろう。しかし、「標準」を意識しつつも実装により細かな違いがあり、同じような表示を実現するなどということはできなかった。

但し、たいていの利用者はレンダリング方式の違いによるウェブページやウェブアプリケーションの見え方にはほとんど意識を払わなかった。利用者は利用可能な機能(ブックマーク、プラグイン、タブなど)によってブラウザを選択していただけなのだ。そうした機能の多寡や使い勝手によって、利用者はブラウザを切り替えてきたのだ(もちろんあまりに速度が遅いものなどは排除されることになる)。

Mozillaは、魅力的な機能を提供していくためには、ブラウザ全体を自ら手がけていく必要があると述べている。今やWebKitに対する唯一の対抗勢力と言っても良い存在になったMozilla陣営は、自らの言葉を証明するために、利用者にとって真に魅力的な機能を提供していく必要がある。

個人的には、「標準」に基づいた競合がある方がイノベーションサイクルも早まると考えている。ウェブ技術というのは、まだひとつのエンジンに集約してしまうような枯れた技術ではないと思うのだ。レンダリングエンジンが複数存在すれば、余計な作業も増えるだろうし、迷惑に感じられることすらあるかもしれない。しかし将来的にきっと実を結ぶ、「若い時の苦労」になると思うのだ。

原文へ

(翻訳:Maeda, H)

FeedlyでSync’ing feedly. Please wait…が無限ループする

Feedly8.0で「Sync’ing feedly. Please wait…」無限ループについて解決方法を探しまくってたら情報を見つけたので。

Firefox9にFirebugとFeedlyがインストールされている環境下だと動作しなくなるようです。現時点ではFirebugを無効化するしかなさそうなので気長にアップデートを待つこととします。

あ、だいぶ遅いですけど、あけましておめでとうございます。