2009-03-06
Firefox 3.1はBeta 4からFirefox 3.5に名称を変更
昨日のFirefox Product Delivery Meetingでの決定を受けて、Mozilla Corporationの技術担当副社長Mike Shaver氏は、Firefox 3.1の名称をBeta 4からはFirefox 3.5に変更すると発表した。
この流れに合わせてTrunkは3.2a1preから3.6a1preへと変更されたが、これは3.5の次が3.6になることを意味するものではない。また、3.1から3.5に改称された点についても、Shaver氏は、あくまで現在の開発状況を踏まえたにすぎず、新機能が追加されるわけではないと念を押している。なお、GeckoのバージョンはTrunk、Branchともに維持される。
発表に従えば、「Firefox 3.5 Beta 4」がリリースされるのだから、その開発版であるShiretokoは、3.5b4preとなるのが自然だ。ところが、実際は3.1b4preと表示される。これは誤記ではなく、"Bug 475077 - Tracking bug for Build and Release of Firefox 3.1b3"をみると、いったん3.5b4preとしたパッチをわざわざ作り直している。
理由は不明だが、「3.1b4preを経由して」とか、「当面はこれへと引き上げる」といった文言が見えるので、Firefox 3.1 Beta 3がリリースされた時点で3.5b4preに切り替えるのかもしれない。
Permalink | コメント(0) | トラックバック(1) | 08:15 
Glodaの国際化対応は緒に就いたばかり
Thunderbird 3では、強力な全文検索機能が導入される予定だが、そのバックエンドを担うのがGloda（Global Database）である。Glodaは、Thunderbirdが管理するあらゆるメッセージのインデックスを作成し、柔軟で高速な検索処理を行う。
しかし、その開発は英語を念頭に置いて進められてきたため、国際化対応は遅れている。今のところ、ライバルのPostboxと同様に、Thunderbird 3はインデックスを利用した日本語全文検索には対応していない。しかも、肝心要のインデックス作成アルゴリズムが決まっていないのだ。この点に期待している方もいらっしゃるだけに、残念なことである。
この件に関しては、Mozilla Japanのdynamisさんが本家Bugzillaで問題点を詳細に指摘されているので、これを参照しながら話を進めていきたい。
dynamisさんによれば、今のGlodaは次のような問題を抱えているという（Bug 479783）。一つは、マルチバイト文字列をデータベースに格納する時点で、文字化けが発生すること。この点はエンコードの問題なので、対処は比較的容易であり、まだ解決済みではないものの、パッチが完成に近づきつつある（Bug 479214）。
真の問題は、英語のようにスペースで分節できる言語はいいとして、そうでない言語、たとえば日本語ではうまくインデックスを作成できないことだ。メッセージを解析してインデックスに落としこむプログラムをトークナイザー（tokenizer）と呼ぶが、Thunderbird 3はSQLiteの"Porter stemmer"というトークナイザーを使っているものの、これはスペースで分節する言語にしか対応していない。
これを日本語に当てはめようとすると、たとえば、「現在の Thunderbird は全文検索エンジンが使い物にならない。」という文字列は、「現在の」「Thunderbird」「は全文検索エンジンが使い物にならない。」というインデックスに変換される。「は全文検索エンジンが使い物にならない。」などというインデックスに検索文字列がヒットすることは皆無といってよく、このままではユーザーの期待とはかけ離れた低レベルの検索機能しか提供できなくなってしまう。しかも、上の例は、たまたま「Thunderbird」の前後にスペースが入っていたから三つに分解できただけで、スペースがなければお手上げだ。
そこで、別のトークナイザーが必要になるわけだが、開発者が考えていたのは、スパムフィルターで使われているトークナイザーを流用することだった（Bug 472764）。
しかし、dynamisさんの指摘では、これも使い物にならない。理由は三つあり、「全角シンボル（カッコなど）をうまく分けられない」、「『のすべてを』など、ひらがなやカタカナ（韓国語も）の一部をうまく分けられない」、「単純なユニグラムでは速度が不十分である」というものだ。これは、現行のスパムフィルターの欠点でもあり、それをGlodaに持ち込むべきではないとdynamisさんは主張する。
ここで、ユニグラムについて説明しておこう。工藤智行氏の「検索エンジンを作る」シリーズを参照すると、検索エンジンのインデックスを作成する際、形態素解析とN-gramという二通りの方法があるそうだ。ユニグラムはN-gramに含まれる一技法である。
形態素解析では、原文の自然言語を構文解析して分かち書きする。たとえば、「今日/は/良い/天気/です。」といったように。検索ノイズは少ないが、特定の言語を対象にするため、Thunderbirdのように多言語を扱うプログラムには向かない。
これに対し、N-gramは、単純に文字の並びを見出し語としてインデックスを作成する。1文字を元にインデックスを作成する技法がユニグラムで、2文字の並びを元にするときはバイグラムと呼ばれる。たとえば、バイグラムであれば、「今日は良い天気です。」という文字列を、「今日」「日は」「は良」「良い」……といった形で切り分けていく。見出し語の切り出しに文法解析を要しないので、特定の自然言語に依存しないという特徴があり、Thunderbirdが採用するならこちらの方法になる。
スパムフィルターに使われているnsISemanticUnitScannerというトークナイザーは、ひらがなとカタカナを区別するので、単純なユニグラムとは違うようだが（Bug 176528）、それでも切り出す量はバイグラムよりもはるかに多い。そうなればインデックスは肥大し、検索速度が落ちてしまう。
どう対処するかだが、dynamisさんから指摘を受けるまで主要開発者たちがこの問題に気づかなかったことからも明らかなように、言語学の知識とプログラミングの技術を兼ね備えた開発者の不在がネックになっている。また、Beta 3のリリースまでにメドを付けなければいけないが、期間は約10週しかなく、新たなアルゴリズムを開発している余裕はない。いちおう単純なバイグラムでインデックスを作成するパッチ（Bug 414102）はあるものの、精度やパフォーマンス面でかなり不安が残る。
主要開発者たちは態度を決めかねているようだ。dynamisさんが既存の有名な全文検索エンジンを挙げており（Hyper EstraierやSennaなど）、そこと交渉してライセンス問題を解決したうえで、トークナイザーを丸々取り込む話も出ている。ただ、それらはMySQLなど別のデータベースを対象にしたものであるため、SQLiteでうまく動く保証はない。
先行きは不透明だが、日本語版Thunderbird 3にとって中核的な問題であるだけに、きっちりと解決してほしいものだ。
Permalink | コメント(9) | トラックバック(0) | 07:24
「新しいタブ」にタスクを追加する実験
Firefox.next（3.5の次のバージョンを便宜上こう呼ぶ）では、新規タブを開いたときに、空白ページではなく有用なタスクを追加したページを開くようにしようという計画がある（『Firefox 3.2のタブ機能をさわりだけ』参照）。Mozilla Labsは、これまで温めてきたコンセプトを具体化する実験的なアドオンを公開した。ただ、利用にはFirefox 3.1のβ版が必要だ。
実際に導入してみて気づいたことも含め、その機能について簡単に紹介しよう。
Quick-access Bar
以前"Quick-access Strip"と呼ばれていたものだが、画面右端にサムネイルが縦に並ぶことから、バーに改称された。なぜ右端なのかといえば、ユーザーの中心視覚からあえて外れた場所に置くことで、操作の邪魔にならないようにするためである。
サムネイルは7つあり、最初の時点で自動的にWebページにアクセスして画像を取得する。ファビコンはサムネイルの上に重ねて表示される。将来のバージョンではこれらがグレースケール、つまり白黒で描画されるという。また、ユーザーが能動的にページにアクセスすると、RSSを取得し、タイトルの下にヘッドラインが加わる。このヘッドラインは毎回更新されるようだ。
対象となるWebページは、Firefoxの履歴をベースに、訪問日時と訪問頻度を計算して順番が決められる。ただ、スマートロケーションバーと違って、ユーザーがブラウジングを始めるページに絞ってこの基準を適用する。つまり、ユーザーが最初にアクセスする可能性が高い順にページが並べられている。
Firefox版のGoogle Toolbar 5 Beta 2と比較すると（『「新しいタブ」をパーソナライズ』参照）、Quick-access Stripは積極的にページの情報を取得しようとする傾向が強い。その分、読み込みに時間がかかるため、賛否両論ありそうだ。
また、今のところ特定のページが現れるのを抑止する機能はない。いったん現れたサムネイルを削除する機能もない。RSSのヘッドラインが次のページのタイトルと被ることも多く、スクロールバーが出ないので一番下のサムネイルは途中で切れてしまうといった問題もある。
Contextual Actions
ユーザーの直前の操作に合わせて、一定のタスクを提案する機能だ。具体的には、ユーザーがページ内でコピーを選択した情報を参照する。それが語句なら検索を提案し、住所なら地図表示を提案する。ユーザーは、提案されたタスクのボタンをクリックするだけでいい。
現在のところ、反応するのは英語だけで、日本語の語句を選択してもタスクは出ない。また、URLを選択したときはそのページへ直接飛ぶボタンが出るというのだが、筆者の環境では出現しない。このあたりは最初のプロトタイプだけに仕方のないことだろう。
当初のモックアップでは、別ページに最近閉じたタブの一覧が表示されることになっていたが、これは採用されなかった。その代わり、直前に閉じたタブの復元がタスクとして提案される。Contextual Actionsの一つとして統合されたわけだ。ただ、複数のタブを一気に閉じたケースには未対応である。
感想
モックアップを洗練させて、動く形にまでもってきたことは評価できる。しかし、使い勝手には微妙なところもあり、Google Toolbarのほうが実用性は高いのではないだろうか。とはいえ、RSSでヘッドラインを取得するアイデアは目新しい。Webメールの新着情報を確認するのに便利だと説明されており、人によっては重宝するだろう。
（09/03/07追記）
About:Tabアドオンが、記事アップ時のバージョン0.0.2から、0.0.18へと更新された。サムネイルはグレースケールで表示されるようになり（ファビコンは意図的にカラーのまま）、サムネイルの数も画面サイズに合わせるようになったため最下部が途切れなくなった。また、URLをコピーしたとき、ちゃんとページを開くボタンが出現する。
なお、Mozilla Links日本語版に『Mozilla Labs から新しいタブページ』という記事が掲載された。併せてどうぞ。
Permalink | コメント(0) | トラックバック(1) | 06:14
