たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能!
UxU(UnitTest.XUL)を利用したFirefoxアドオンのデバッグの例 - ククログ(2008-11-17)
XUL/Migemo 0.11.7での修正内容が典型的な「自動テストを使ったデバッグ」だったので、UxUのチュートリアルを兼ねて、会社のサイトの方に書いてみました。UxUの解説って言うよりは、テスト駆動開発自体の解説という気もしますが。
リンク先に解説してるのはpXMigemoFindのfindFirstVisibleNodeメソッドだけのデバッグ話ですが、実際にはこのメソッドはだいぶ根幹に関わる物で、このメソッドの挙動の変更によって他の機能に色々と影響が出る可能性がありました。が、他の挙動に関しては一通り自動テストを作成済みだったために、後退バグの発生で収拾不能な事態に陥るということを恐れずに安心して修正に取り組むことができた、というまさに自動テスト様々な事例だったということも忘れずに付け加えておきたい所です。
入力が英語だったから日本語圏の人間からはそれこそvimperator等と見分けがつかないけど、英語ネイティブの人にとっては、自分が話す言葉でFirefoxに指示を出せるようにする画期的な仕組み、なのだと思う。
と書いたけど、Firefox Hacks:ブラウザの新境地? Ubiquityが変える衝撃のブラウザ体験 (1/2) - ITmedia エンタープライズとか完全にギーク向けと評されているのとかを見るにつけ、その思想の伝わっていなさに改めて悲しくなった。いや、僕自身も、昨日本人が喋ってデモしてる所を生で見るまで、全く同じ誤解をしてたんだけども。
確かに、英語で使ってる所を見たら、そう誤解してしまっても仕方がない。でも、操作の様子を注意深く見て欲しい。「email jono」じゃなくて「email this to jono」であることに気がついて欲しい。昔のお粗末なハリウッド映画でありがちな、何故か「コマンド」じゃなく「自然言語」で入力する、今となってはお笑い種のシーン、あれを現実のものにしようとしてるってことに。
昨日のデモの受け売りだけれども、Ubiquityはそれ自体で「万能」は目指していない。また、全てのユーザが自分でコマンドを定義して使うという風なあり方も、想定していない。Firefoxとアドオンの関係のように、必要に応じてさまざまな「動詞」を憶えさせて使うというシステム。それでいて、アドオンに比べてはるかに作るのが簡単だから、「開発者」の数も段違いに増えて、その結果として、エンドユーザが受ける恩恵もずっと大きくなる。これがUbiquityのしようとしている事だと、僕は受け取った。
Googleのトップページに行けば「ググる」という「動詞」をインストールできて、Tumblrのトップページに行けば「たんぶる」という「動詞」をインストールできて、はてな匿名ダイアリーのトップページに行けば「マスダる」という「動詞」をインストールできて、ニコニコ動画のトップページに行けば「ニコる」という「動詞」をインストールできる。そして、「ミクをニコってたんぶる」と入力すれば、ニコニコ動画で初音ミクの動画を検索した結果を自動的にTumblrに投稿できるようになる。「別れたいをググってマスダる」と入力すれば、「彼氏が○○だった。別れたい・・・」のテンプレを見つけてきて増田にエントリを書けるようになる。そういう、動詞の連結による可能性の追及が、Ubiquityのしようとしている事だと、僕は受け取った。(←妄想補完しすぎ?)
という所まで理解できるとなおのこと、このUbiquityという試みが日本語圏で満足に利用できるようになる日の遠さがよく分かってしまうのも、辛い所なんだよなあ……
まず障壁になるのが日本語という言語の特性。分かち書きじゃないテキストを形態素解析しなきゃいけないし、異常に多い同音異義語や語尾の変化にも対応しなきゃいけない。
入力方式も問題だ。前のエントリにも書いたけど、IM経由で入力するっていうだけで操作は全然インクリメンタルじゃなくなってしまう。
文化の違いもある。日本では、自分で入力して何かをするよりも、メニューからぽちぽち選ぶというスタイルの方が主流だ。そのスタイルに慣れた人にとっては、何か入力しなくてはならないということ自体が「面倒」ということになる。(ああ……そういう意味では、そもそも、Firefoxのアドオンもそういわれているのと同様に、自分で何かを組み合わせて使うという発想自体がギーク志向すぎるのか……)
それに、上の文章を書いてて思ったけど、日本語には、サービス名が動詞になるっていう例が少ない気がする。「ググる」はその珍しい「成功例」だ。「ヤフオク」も「ミクシィ」も、「名詞」としてまでは認知されるんだけど、そこから先、「ヤフオクる」とか「ミクる」とかいう風な「動詞」にまではなってない。そういう点もまた、Ubiquityのコンセプトが日本語圏にマッチしにくい所なのかなあ。
とりあえず近々また話せる機会がありそう?なので、その時にはXUL/Migemoだけでなく、セカンドサーチの「目的語を入力したら動詞を自動で提案する」という方向についても意見を聞いてみたい。
Firefox Developers Conference 2008に行ってきた。
モバイルとか次世代のWebとかそういうのがメインの話題という風に聞いていたので、僕が行ってもあんまり得る物は無いのかなー、と思ってたんだけど、逆に今まで全然関わり合いがなかった分野の話を聞く良い機会になった。
Ubiquityについては、vimperatorと同類なんじゃね? 誰が喜ぶのこんなの? という感じにしか思ってなかったんだけど、実際に見てみるとなかなかぶっ飛んだ感じの物だった。入力が英語だったから日本語圏の人間からはそれこそvimperator等と見分けがつかないけど、英語ネイティブの人にとっては、自分が話す言葉でFirefoxに指示を出せるようにする画期的な仕組み、なのだと思う。
他の言語への対応、特に日本語のように英語とはルールが全く違う言語を解釈させるためには、Mozillaだけで全部解決しようとするよりは、Anthyなりprimeなりをライブラリとして利用するような方向の方がまだ現実的なんじゃないかと思った。あと、IMの問題(Enterキーの事とか、そもそもIMを使って入力するから全然インクリメンタルじゃないとか)の解決のためのヒントになるんじゃないかと思って、懇親会の時にAza氏にXUL/Migemoの事を売り込んでおいた。
最大の問題は、これが「能動的に操作する人」「目的語よりも動詞を先に思い浮かべる人」を強く志向しているという事だろう。これについては講演を聴く前後で認識が変わらなかった。「受動的に操作する人」「動詞よりも目的語を先に思い浮かべる人」のためにはどういうUIが良いのか? という事についてのAza氏の考えを聞いてみたいところだ。「そういう人はそもそもPCを使うべきではない(そういう人のために設計されるのが、単機能に特化した物、例えば電子辞書であるとかデジカメであるとかメール送受信専用端末であるとか)」ってのも、まあ、一つの考えだと思うけど。
それ以外の話。
パネルディスカッションでMozillaのえらい人が「日本の状況は他と違うと思うか?」みたいな質問に対して「すごく違う」と答えていたけれども、「stupid」ではなく「different」と言っていた事に気がついて、ああこれが政治的に正しい喋り方っていうものなんだなあと、本題とは関係ないところで感心した。
組み込みの話が進まない理由について、組み込み屋さん的には「一緒に頑張って仕組みを作っていきましょう」みたいに協力的な態度で来られれば「よしやろう」と思えるけど、Mozillaみたいに「いい物作りましたんで後はみんなが勝手に開発して使ってね」という態度だと使う気になれない、みたいな。Mozillaが高飛車すぎるのか、日本の組み込み屋さんがベッタリ甘々な関係に慣れすぎているのか……まあ企業対企業という観点で見るとMozilla何様のつもりやねんって感じだけど、Mozillaは理念と利益だったら理念の方を取る(むしろ、取らなければならない)団体だということを考えると、当然の事かなー、と。
XUL/Migemoの動作で怪しい所を見つける→再現条件確定→その条件下でのテストを行うためのUxUのテストケースを作成→何かちゃんと動かない→UxUのバグ発見→抜本的修正開始→途中で疲れて寝る→抜本的修正続き→やっとチェックイン→XUL/Migemoのテストを書く気力がなくなってる→それでもめげずにテスト書き再開→UxUの別の問題発覚→心が折れかける(今ここ)
ソース表示タブ更新しました。メインはMinefield 3.1b2preで使えるようになった「ページのソース」内のリンクへの対応です。タブ内でソースを表示している時にソース内のリンクを辿った場合、普通にフレームを使ったページでフレーム内のページを移動したのと同じような動作になるようですが、タブのタイトルやURIの表示欄を遷移に合わせて更新するように修正しました。リンクのミドルクリックから別のタブでソースを開くという操作にも対応してます。
あと、ソースをタブで開く設定にしてる時にたまにデフォルトの動作(ウィンドウでソース表示)をちょっとだけ使いたい、というケースがあったので、メニューの「ページのソース」や「ページのソースを表示」をミドルクリックまたはCtrl-クリックした時に設定を反転した動作を行う、という機能も付けてみました。挙動の変化の説明は文章にするとわかりにくいので、以下に表を置いておきます。
設定 | 通常の操作での動作 | ミドルクリックで反転された動作 |
---|---|---|
ソースを別ウィンドウで開く | ソースを別ウィンドウで開く | ソースをタブで開く |
ソースをタブで開く | ソースをタブで開く | ソースを別ウィンドウで開く |
外部アプリケーションで開く | 外部アプリケーションで開く | ソースを別ウィンドウで開く |
今まで全然知らなかったんだけど、vimperatorでXUL/MigemoのAPIを使ってタブの切り替えやヒントモードを強化するなんてことをやってる人がいたんだ。(←って、分かったような書き方をしてるけどvimperatorの事は全然分かってません……)
その関係でいくつかページを渡り歩いてたら、XUL/Migemoのバグって話題が出ていて、なぬ!と思ってさらに辿ってみた所、半角括弧がらみの問題のことらしい。あーこの辺ちゃんと見直さないままずっとここまで来てたんですよね……UxU用のテストも基礎部分の単体テストはさっぱり手つかずのままだったし(ぉぃ)。ということで本腰入れてテスト書いて、潜在してたバグを潰し始めました。でもまだまだ見落としがありそう。
ツリー型タブとクリック証券のFXツールバーが衝突しているという話を見かけたので調べてみたんだけど、だいぶお手上げです。
リバースエンジニアリング禁止とあったけどべつに僕はこれを利用するつもりも使用するつもりもないのであくまで自作アドオンとの競合の原因を調査するために難読化されたコードを頑張って解読してみたところ、FXツールバーは非同期処理のための便利メソッドを持ってるくせに何故か初期化の時は同期処理にしているという事が分かった。何故そんなところで手を抜くんだ……
サーバからの設定の読み込みを非同期で行って、設定の読み込み完了後に初期化処理の続きを行うようにすれば、この問題は解消されると思うんだけど。ツリー型タブ以外にも物によっては衝突する可能性があるし、向こうの方で対処してくんないかなあ。望み薄かなあ。一応問い合わせ先のアドレス宛にメールしてみたけど……
続報。返信があり、初期化処理を非同期で行うように改良された新バージョンがもうすぐ公開されるとのことです。反応はやっ!(僕がメールするより前から準備してたっぽい?)
表題の通り。最大化状態でFirefoxを終了して次にFirefoxを起動した時に、最大化が勝手に解除されてしまう問題。ブラウズ領域の描画内用が変になることがある問題というのが発生してて、ウィンドウをリサイズしたら直るようだったので1ピクセルだけウィンドウの大きさを変えてまた元に戻すというコードを入れてみてたんだけど、最大化状態でやると最大化が解除されてしまうということに気付かないままリリースしてしまってました。
みんな最大化って結構使ってるんですね……ということを、このバグの報告が大量に来たことで実感した次第です。
表題の通り。昨日と今日とでガラッとUIが変わったりしてカオスな事この上ないMinefield 3.1b2preですが、最終版まで残るものと踏んで、タブの一覧を表示した時に絞り込みを行う検索欄でMigemo検索できるようにしました。ページ内検索の物とは異なり、スマートロケーションバーと同様にスペース区切りで複数語句のAND検索になります。入力からそれに対応する正規表現を生成する部分の処理はスマートロケーションバーの物を汎用化して使っているので、語句の頭に「-」を付ければNOT検索もできます。
で、その関係でpIXMigemoインターフェース(XMigemoCore)に新しくいくつかメソッドが加わりました。以下、IDL定義から抜粋。
AString getRegExpFunctional(
in AString input,
out AString termsRegExp,
out AString exceptionsRegExp
);
attribute boolean andFindAvailable;
attribute boolean notFindAvailable;
boolean isValidFunctionalInput(in AString input);
AString trimFunctionalInput(in AString input);
getRegExpFunctional()
に「nihon go -hoge」という風な文字列を渡すと、nihonとgoをローマ字入力として解釈した結果でAND検索を行うための正規表現が返ってきます。第2引数に渡したオブジェクトのvalue
プロパティには、AND検索ではなくOR検索のための正規表現が格納されます(これを使うと、検索にマッチした単語を取り出すことができる)。第3引数に渡したオブジェクトのvalue
プロパティには、NOT検索で「これにマッチしたら除外する」という用途に使う正規表現が格納されます。先の例だと「hoge」をローマ字入力として解釈した結果の正規表現ですね。
trimFunctionalInput()
メソッドは、例えば「nihon go -」という風な(NOT検索の入力中と思われる)文字列を渡すと、前後の空白と最後のハイフンを取り除いた結果を返します。NOT検索が無効な時は、前後の空白だけが取り除かれます。今の所はそれだけしかしません。
isValidFunctionalInput()
は、trimFunctionalInput()
やgetRegExpFunctional()
に渡してMigemo検索するに値する内容かどうかを判定します。このメソッドがfalseを返した場合はMigemo検索のための処理を丸ごとスキップする、という風な感じで使います。
タブの一覧の絞り込み部分のコード(filterListFromInputメソッド)が、まさにこれらの実際の利用例ということになります。自分のアドオンやらuserChrome.jsやらで使ってみたい人は参考にしてください。
他の目につく改良点として、スマートロケーションバーの検索処理を改善しました。というか修正しました。元々スマートロケーションバーでは、例えば「moz」と入力して出てきた候補から「mozilla.jp」を選択した場合、2度目以降はその候補が真っ先に表示されるし、同様に「mozilla.gr.jp」や「addons.mozilla.org」なども選択したことがある場合には選択回数が多い物から順に表示される、という仕様になってるんですが、これを再現するためのSQL文を書き間違えてて(MAX関数をJavaScriptのMath.max()
みたいなものと勘違いしてた)、同じ項目を何度選んでも表示の順位が上がらないという状態になってました。スマートロケーションバーが全然スマートじゃなくなってたという……