Latest topics 近況報告
たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。
の動向はもえじら組ブログで。
宣伝。日経LinuxにてLinuxの基礎？を紹介する漫画「シス管系女子」を連載させていただいています。
以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能！
スマートロケーションバー周りの設定が少し分かりやすくなった - Jan 21, 2009
browser.urlbar.search.sourcesとbrowser.urlbar.default.behaviorという似たような設定が2つもあってわけわからん！！という話をこの間書いたけれども、新しいパッチが入って、browser.urlbar.search.sourcesは廃止された。
- スマートロケーションバーの検索機能のON/OFFはbrowser.urlbar.autocomplete.enabledという真偽型の設定で制御される。
- スマートロケーションバーの検索対象をブックマークにするか・履歴にするか・両方を横断検索するかについてはbrowser.urlbar.default.behaviorで制御される。
ということで割としっくり来る所に落ち着いたみたい。search.sourcesのために色々調べたり実装を直したりしたのはまるっきり無駄になってしまったけど、しょうがない（異議申立てをした本人だから文句は無い）。
Firefox 3.1で新しいタブを開く位置を変更する機能が入るかも？ - Jan 12, 2009
- リンクから開くタブを右隣に開く - えむもじら
- Firefox3.1 でもしかするとタブを開く挙動が変更されるかも知れない。 - alice0775のファイル置き場 - Yahoo!ジオシティーズ
- Firefox 3.1でタブの並び方が変更に - Mozilla Flux
- Mozilla Links 日本語版: Firefox の新しいタブ動作
- Bug 465673 – Change 'Default' Tab Opening Behavior/Position for Firefox
そういう機能が入ること自体は、別に悪い事ではない（ていうかIE7が標準でこの機能を持ってる以上は入れといた方がいいだろう）と思うんだけど、実装がなんだか……addTab()の第1引数がabout:blankかどうかで挙動を変えるとか、ちょっとひどすぎない？
本気でこのあたりの挙動をちゃんとしようと思ったら、ツリー型タブ等のようにタブの親子関係をどっかに保持しておかないといけないと僕はずっと思ってる。それを避けて最小限の変更でそれらしい挙動を実現しようとしているから、余計にややこしい事になってるんじゃないかって気がする。
議論をよく読まないままBugzillaにコメントしてしまったんだけど、僕がコメントに書いた事のうち1つ（ブックマークを開く時にこれが働くのはなんか変じゃね？という件）は、すでに俎上にのぼって議論され尽くしてたみたいだ。
タブを開く、閉じるときの動作に関しては多くの議論が行われてきましたが、結局、「ユーザより賢くなろうとはしないこと（do not to try to be more clever than the user）」というガイドラインに従うことになりました。言い換えると、経験則に基づく自動動作がユーザの意図した動作に合致すると確信できないときは、自動動作を行わないということです。
追記。誰か分からんけど「feature freezeなのに何やってんだ！」という指摘をしている人もいたので、その辺の事も入れてコメントしてみた。
しかしまあこんな事ばっかやってるとますます「手は動かさないくせに口だけ出しやがるウゼエ奴」度が増していきますなあ……
1月15日追記。新しいパッチが提出された。addTab()に引数を一つ増やして、それで新しい挙動を使うかどうかを制御するというもので、他に与える影響はだいぶ小さくなってると思う。引数の個数がどんどん増えていくのは見てて頭クラクラしてくるけど、これ以上のことをやろうとすると話がもっとでかくなりそうだから、落とし所としては無難な線じゃないかと思う。
Firefox 3.1のスマートロケーションバーまわりがわけわからん！ - Jan 09, 2009
- 「Location bar search (1)」 - Scene Side B
- Firefox 3.1: スマートロケーションバーの絞込み - えむもじら
- Firefox 3.1の主な変更点を日本語で - Mozilla Flux
現時点までで、以下の設定項目が新設されたところまでは把握してる。
- browser.urlbar.restrict.history（文字列型）
- browser.urlbar.restrict.bookmark（文字列型）
- browser.urlbar.restrict.tag（文字列型）
- browser.urlbar.restrict.typed（文字列型）
- browser.urlbar.match.title（文字列型）
- browser.urlbar.match.url（文字列型）
- browser.urlbar.default.behavior（整数型）：Bug 463459 – Use a separate pref instead of empty restrict/match values to specify defaults により追加された。restrictとmatchの値が「空の場合は」云々の特例的な処理を一本化するための物。
- browser.urlbar.search.sources（整数型）
以下は削除された、と。
- browser.urlbar.matchOnlyTyped（真偽型）
が、どれがどんな風に働くのかがごちゃごちゃして分からんようになってきた……
browser.urlbar.default.behavior（フラグを指定しておくことで、restrictとかmatchとかの指定をしたのと同じ状態から検索をスタートする）に3を指定するのと、browser.urlbar.search.sourcesに3を指定するのとの、違いがいまいち分からない。ので、ソースをあちこち辿ってみた。見てみた感じでは、どうやらnsNavHistoryのProcessTokensForSpecialSearchメソッドが鍵になってるっぽい。
検索対象のテーブルの指定や絞り込みの条件は、すべてmAutoCompleteCurrentBehaviorという1つの変数にフラグとして格納される。
- 1（最下位ビットがON）は、履歴だけを検索対象にする。
- 2（下から2番目のビットがON）は、ブックマークだけを検索対象にする。
- 4（下から3番目のビットがON）は、タグ付けされている項目だけを検索対象にする。
- 8（下から4番目のビットがON）は、タイトルにマッチする。
- 16（下から5番目のビットがON）は、URIにマッチする。
- 32（下から6番目のビットがON）は、ユーザがロケーションバーから手動操作で訪問した項目だけを検索対象にする。
これらを踏まえて、以下の順で処理されている。
- browser.urlbar.default.behaviorの指定でmAutoCompleteCurrentBehaviorを初期化する。
- browser.urlbar.search.sourcesを見て、
- 1だったらmAutoCompleteCurrentBehaviorの最下位ビットをONにする。
- 2だったら下から2番目のビットをONにする。
- それ以外の時（0や3）は何もしない。（browser.urlbar.search.sourcesが0の時、つまりスマートロケーションバーの検索機能自体を無効にしている時は、ここにそもそも処理が回ってこない？）
- スマートロケーションバーに入力中の文字列をトークンごとに分割して、restrictやmatchで設定されている文字列と比較する。一致したらその都度、mAutoCompleteCurrentBehaviorの対応するビットをONにしていく。
- 入力中の文字列が空の時は、最下位ビットと下から6番目のビットをONにする。（Bug 426864 – Only show user typed history pages for the urlbar dropdown によって追加された処理で、ユーザが何も入力してない状態でドロップダウンリストを開いたら過去の入力履歴だけを表示する、という挙動をこれによって再現する。）
- ここまでの結果のmAutoCompleteCurrentBehaviorを見て、以下の順で、どのSQL文を使うかを決定する。これは排他的な選択なので、どれかの道に分岐したらその時点で検索条件が確定する。
- 下から3番目のビットがONの場合、タグ付けされた項目だけを検索するSQL文を使う。
- 下から2番目のビットがONの場合、ブックマークだけを検索するSQL文を使う。
- 下から6番目のビットがONの場合、ユーザがロケーションバーから手動で訪問した項目だけを検索するSQL文を使う。
- 最下位ビットがONの場合、履歴だけを検索するSQL文を使う。
- 上記ビットがいずれもOFFの場合、履歴とブックマークの両方を対象に検索するSQL文を使う。
- 下から4番目のビットと下から5番目のビットは、次の段階での絞り込みに使われる。
ああややこしい……
- 5のステップでは排他的な選択になっているので、例えば「タグ付けされた項目で、且つ、ロケーションバーから訪問した事がある物だけを対象に検索する」という風なことはできないようだ。
- 条件を指定する方法には、browser.urlbar.search.sources、browser.urlbar.default.behavior、検索時のキーワード入力の3つがあるが、これら3つの間には優先順位は無い。優先順位は各ビットの方にあって、常に5-1から5-5の順番に従って判定される。なので、以下のような不可解なことが起こる。
- browser.urlbar.default.behaviorを使って、ブックマークからのみ検索を行うようにした状態（下から2番目のビットがON）で、検索時語句の中に「^」を含めて履歴のみの検索を指示した（最下位ビットがON）、という場合、手動で指示した検索条件はまるっきり無視されて、あくまでブックマークからのみ検索が行われる。
- browser.urlbar.default.behaviorを使って、ユーザがロケーションバーから手動で訪問した項目だけを検索対象にするように指定（下から6番目のビットがON）していても、検索時語句の中に「+」が含まれていた（下から3番目のビットがON）場合には、手動で指定した方の条件が優先されて、タグ付けされた項目からのみ検索が行われる。
- browser.urlbar.default.behavior=3とbrowser.urlbar.search.sources=3の違いは、前者は「ブックマークされていて且つ履歴にも含まれている（＝訪問済みのブックマーク）」項目だけが検索対象になり、後者は「ブックマークと履歴の全体」が検索対象になる、という点。search.sourcesが0（検索機能自体が無効になっている）以外で、default.behaviorが3の時は、両方の条件がMIXされて、browser.urlbar.default.behavior=3の条件と同じ（ブックマークと履歴の全体から訪問済みのブックマークだけを検索するのも、ブックマークから訪問済みのブックマークだけを検索するのも、履歴から訪問済みのブックマークだけを検索するのも、全部同じ事ですね）になる。
その場での入力とデフォルト設定のどっちが優先されるのか、がパッと分からないのってどうかと思うんだけど……XUL/Migemoのスマートロケーションバー周りの挙動をこれに合わせないといけないんだけど、こういうわかりにくい挙動をそのまま再現するというのは、モチベーションが上がらないなあ。（ていうかバグ立ってそう）
21日追記。browser.urlbar.search.sourcesが廃止されてこのエントリの内容のかなりの部分は無駄になりました。
MozillaがWindows Mobile上で動いてる様子のデモ - Jan 08, 2009
弊社の足永さんが、Windows Mobile（エミュレータ）上でMozillaが動作している様子のデモ動画を公開してくださいました。YouTubeを見てみた所、Windows XP上で動くFennecの動画はいくつかあるみたいですが、Windows Mobile上での物の動画となるとこれが一番乗りっぽい？
スクロールバーのクリックでスクロールしなくなる現象 - Dec 15, 2008
普段、ページをスクロールするのにスクロールバー上のクリックだとかホイールの回転だとかキーボードのPageUp/PageDownキーだとかスペースキーだとか色々使ってるんだけど、ここ数日、なんかスクロールバーの空白部分でのクリックだけ突っかかるっていうか詰まるっていうか急にスクロールしなくなる現象が自分の手元では起こっている。下方向にスクロールしてる時に、急に、クリックしても何も起こらなくなる。ホイールスクロールしたり、一度上方向にスクロールしたりすると、「詰まり」が解消されてまた下方向にスクロールできるようになる。
「click scrollbar」とかで検索しても他に同じ問題を報告してる人がいないような感じだったし、いまいち確実な再現条件が特定できない――他の環境でもこうすれば確実に発生しますよ！と断言できそうな条件が分からない、自分の手元の環境でも起こったり起こらなかったりしてるので、WORKSFORMEとかINVALIDとかにされてまた永久に放置食らいそうな気もするけど、問題が起こるようになってから数日経ってもなお現象が発生し続けているので、直れば儲け物だと思ってダメ元で一応登録してみた。
問題があるとしたらきっとC++の層での話だと思うので、条件が特定できたとしても僕には絶対にパッチ書けません。パッチ書ける人誰かフォローしてください。それか、僕には既にある同様のバグを見つけられませんでしたが、もしあるならDUPLICATEDにして下さい。
ってこんなネットの辺境で書いても誰も見てないんでしょうけどね。
追記。他の人の環境でも再現されて、どうやら原因になった改変が行われたバグなどが特定されたようです。中野さんのフォローのおかげです。ありがとうございます。
初パッチ - Dec 02, 2008
だいぶ前に報告した、TabCloseイベントの前後でタブの数が変わることを想定してないせいで複数タブを一気に閉じられない問題は、他のバグにおける変更の影響で結果的にFIXEDになったようだったんだけれども、今日あたりのビルドで試してみたらまた同じ問題が……「何故そうなるのか」と「何が問題なのか」が開発者に理解されてないとこうなるってことですかね。
とりあえずMozillaBuild入れて最新のソースをチェックアウトしてパッチ書いて、モジュールオーナーと思われるmconner氏のメールアドレスをreview欄に書いてみた。
どっかで聞いたけど、こういうのって結局IRCで本人を突っつかないと放置食らう事が多いんですって？ 英語チャットか……気が重いなあ。
もっと良いAutoPagerize - Nov 25, 2008
新はてブとAutoPagerizeの競合のことで色々もめているようですが、個人的にはこの間Aza氏に見せてもらったUIデザインのモックアップみたいなのがいいなーと思いました。Azaはタブの代わりに使いたいと思ってたようだけど、AutoPagerize的な用途に使うのが現時点では有用なんじゃないかなあ。
イメージしづらいと思うけど、XULのbrowserとframesetとframeでそれっぽく表現するとこんな風になるかな。
<xul:browser height="600"><!-- ←この要素がスクロールバーを提供する -->
<html:frameset rows="*,*,*" height="6000">
<html:frame src="今見ているページ（ページ1）：ページの長さ＝2000px"
height="2000"/>
<html:frame src="ページ1のrel=nextのリンク先のページ（ページ2）：ページの長さ＝2000px"
height="2000" />
<html:frame src="ページ2のrel=nextのリンク先のページ（ページ3）：ページの長さ＝2000px"
height="2000" />
</html:frameset>
</xul:browser>本物のXHTML 1.0 Framesetとは違う嘘マークアップであることに注意。あくまで雰囲気だけ見て欲しい。こういう作りなら、AutoPagerizeの原理的な問題の一つである「ページを動的に継ぎ足すせいで、継ぎ足された内容に対してユーザスクリプトが実行されない」という問題は起こらなくなるはずだし、想定されない内容改変によるページのレイアウト崩れも起こらないはず。その代わり、広告が二度も三度も表示されるという問題は起こるけど。
ちょっと作ってみようかな、そういうの。
エイザを囲む会 - Nov 21, 2008
Aza Raskin飲み会行ってきた。
普段あまり顔を合わせることがないplus7さんが来られていた。plus7さんは最近タブレットPCを使われているそうなのだけれども、タブレットPCはキーボードが無い。そういう環境で便利に使えるUbiquity的なUIはどういうものか？という事についてのアイデアをAza氏に解説されてた。
それはどういうものかというと、逆ポーランド記法の計算が「演算対象のデータをスタックに溜め込」んでから「演算の種類を決定する」という形で行われるのと同じように、リンクやら文字列やらをドラッグ＆ドロップでどんどん「スタック」に溜め込んでからコマンドを選択する、というものだ。溜め込まれるデータ自体が持つコンテキストであるとかメタデータであるとか（Microformatsもそう）をキーにすれば、その時提示される「コマンド一覧」について最も適切と思われるものをサジェストできるのではないか？とか、色々と夢が広がる。セカンドサーチで、ページ内の文字列を選択→検索窓にドラッグ→ポップアップが出てくるのを待つ→ポップアップから検索エンジンを選んでドロップ という風な操作をよくやってる僕としては、このUIが実現されれば結構使えるかも？と感じた。片手がふさがったままでも色々できるし。
組長に、現状のUbiquityにおける日本語対応用コードの内容というのを教えてもらった。曰く、「で」とか「に」とかの助詞をデリミタとして文を分割するという物だそうな。単純に作るとそうなるよなあと思うんだけど、実際の日本語の文章ではこれはまずマトモに動かないことが予想されるわけで……やはりきちんとした形態素解析の仕組みは欠かせないと思う。それか、ローマ字入力で分かち書き入力するという前提で、XUL/Migemoの応用によって、例えば「miru」という入力に対してマッチするコマンドをコマンド一覧から探し、「見る」と「診る」の両方をサジェストの候補として出す、という風にするとか。
ATOKダイレクトのAPIがオープンになっていること、PerlとRubyに対応していてSDKが公開されていることをAzaに伝えると、「Pythonは無いの？」とAza。そこから、何故Pythonが日本であまり流行らないのかという話になった。最初に出た訳本が微妙だったからじゃないかとか、名前の元になったモンティ・パイソンが日本であまり知られてないからじゃないかとか、PHPやPerlやRubyがすでにデファクトスタンダードとなってしまっているからじゃないかとか……
モンティ・パイソンの話から、コメディは文化に強く依存するのかもしれないという話にもなった。Azaが紹介してくれた「far side」というアメリカの漫画は、日本人に見せても「何が面白いのかよく分からない」と言われがちだという。モンティ・パイソンも組長曰く「ギーク受けするような内容」とのことで。でもサウスパークは日本人にもウケてる気がする。直接的なギャグ、は日本でも受け入れられるということなんだろうか？
日本語入力といえば、IME上でEnterで変換を確定するとUbiquityのコマンド実行として扱われてしまうという問題。これにはAza本人も参っているとか……誰かパッチを公開してたはずだ、という話をその場でもしてたけど、今調べたらFireMobileSimulatorの堀川さんだった。このあたりの、キー入力とIMEの組み合わせの問題を回避するノウハウは、Find As You TypeがC++からJavaScriptに移植された後に中野さんが頑張って直したFindToolbarの実装（今だったらfindbar.xml）に詰まっているので、Azaにもおすすめしておいた。
Azaは日本語がしゃべれるということで、みんな普通に日本語ベースでしゃべっていたけど、日本語ネイティブでないAzaにはちょっと辛いんじゃなかろうか？ と、勝手に気を回してしまって僕はなるべく英語を使うようにしようとしてみたんだけど、基本的な語彙力がないからやっぱり日本語混じりの怪しい英語にしかならなくて、あの場では僕が一番アホな喋りになっていたんじゃないかという気がする。
その後、終電までの短い時間だったけどカラオケにも行った。Azaは「津軽海峡冬景色（石川さゆり）」「花火（AIKO）」「First Love（宇多田ヒカル）」を歌ってた……って、ちょ、どこで憶えるんだそんなラインナップ？！
そんな感じの会。いろんな人が色んな知識やアイデアを持ち寄って話すのも大事だなということを改めて思った。こういう機会を設ける提案をしてくれた組長に感謝せずにはいられない。組長はかなりの量のウィスキーにビールにワインに色々飲んでいてカラオケの時には呂律も回らなくなってヤバイ状態に見えたけど、無事会社まで辿り着けたんだろうか。心配だ。
ところで、帰ってきてから気付いたけど、ATOKダイレクト開発者ブログで前のエントリが紹介されてる。UbiquityにはATOKダイレクト開発者の方も以前から興味を持たれてたとのことで、みんな似たようなことを考えるものなんだなあと感慨を憶えた。……ATOK 2008（for Windows）買いそびれててすみませんすみません ATOK X4（？）での改良に期待してます。
Ubiquityの先にある未来についてAza氏と直接話せた - Nov 19, 2008
所用でMozilla Japanオフィスに行った際、とても幸いなことに、Aza氏と話すことができた。
ちょうどPCを持っていたので、XUL/Migemoのデモをお見せした。IMを使わずに日本語を検索できる様子というのは、なかなかインパクトがあった……っぽい。と思う。
結論から言うと、僕の理解は大筋ではそう間違っていなかったようだ。「translate "english sentence" to japanese, and email to jono」や「『別れたい』をググってマスダる」みたいな複数の「動詞」の組み合わせ（チェインとかパイプとかそういう感じのもの）は、Ubiquityの将来のバージョンで入れる予定があるとも言っていた。セカンドサーチやLookpickやinquisitorについては、悪くないけどいまいち、という風に言っていて（……だと思う。英語不得意なので曖昧）、Aza氏はむしろもっともっと先を目指しているようだった。「動詞」を人間がいちいち入力しなくても、例えばSocial IMEやGoogleやYahooがそうしているように、多くのユーザの行動傾向をベースにして統計処理により精度の高い推測を行うようにする、という風なことも考えているとのことだった。
UbiquityはFirefox上で動作するものだけれども、もっと言えばデスクトップ環境のどこでも動作するようにできれば一番イイ、とも言っていた。彼がUbiquityの前に作ったEnsoがまさにそうで、デモしてもらった様子を見たら、デスクトップ上で特定のホットキーを押すとUbiquityのような物が起動してUbiquityのようにコマンドを入力できる、という物だった。
そういった一連の話を経て僕が思い浮かべたのは、ATOKダイレクトだ。ユーザが語句の入力を行うフロントエンドにいつも存在していて、デスクトップ環境のどこででも動作して、おもむろに始めた入力操作から「乗り換え案内」や「辞書検索」といった多様な機能をシームレスに呼び出すことができる。（それに、日本語圏のユーザなら基本的にいつでもIMEを使っているから、UbiquityやEnsoのように「それを使うためにモードを切り替えるぞ！」という気負いをしなくていい。そういう意味で、こういった操作系に馴染みやすいのはもしかしたら日本人や中国人の方なのかもしれない。）
Aza氏は、ATOKがプロプライエタリな製品であるということを残念がっていた。僕はUbuntu上のATOK X3で変換候補から同音異義語の説明が出る様子を見せたけど、これがもっとオープンな物だったら……と彼は言っていた（この時僕は、PerlやRubyからATOKダイレクトAPIを簡単に呼べるということを完全に失念していたので、そのせいもあるとは思う）。オープンソースの環境で、完全にオープンなソフトウェアだけで、IMから追加コマンド（アドオン、プラグイン）まで全部まかなえれば、もっと自由度が高くなってイノベーションが産まれるかもしれない、と。
ATOKダイレクトのようにどこでもシームレスに使えて、Ubiquityのように簡単に機能を追加できて、Webの向こう側にあるサービスと連携できる。そういう物がAza氏の当面の目標なのかもしれない。
ただ、IMをこれから新しく作るというのは、特に日本語や中国語のユーザのためにそうするというのは、さすがに無謀だと僕は思う。Ubuntu環境では最初からSCIM Anthyが使えたにもかかわらず、Firefox 3 Hacksを執筆するにあたって、大量の文章を入力する時に誤変換によるストレスが尋常でなかったため、慌ててATOK X3を購入することにした。という自分のエピソードも引き合いに出して、日本語圏のユーザにとってIMは空気のように欠かせない存在であって、その品質が日常の生産性にダイレクトに影響する、だから生半可なIMでは使ってもらえない公算が高い、ということをつい熱く語ってしまった。まあ、やるとしても、Anthyのようなすでにある開発コミュニティと協力し合って進めるのがまだ現実的だろうと思う。
ところでATOK 2008を買いそびれてしまったためというのもあって僕は全然知らなかったんだけど、ATOKダイレクトって想像以上の物みたいだ。HowTo記事によると、プラグイン作るのも関数を1つ定義するだけでいいという簡潔さだし。ATOKダイレクト開発者ブログでは色々ユニークなプラグインが紹介されている。これは20日にでもAza氏に補足として伝えておかないといけないなあ。阿波徳島マジパネェ。
余談だけど、GIMPのGUIはほんとひどいな！という所でAza氏と意気投合できたのは愉快だった。実際にそのツールを使って何かをする人の立場に立って、実際に使う場面でのフィーリングを大事にする、ということの重要性をAza氏も気にしていた。日本語圏でUbiquityのような物を使おうとする時に、キーボードを使って言葉を入力するということ自体がもう大多数の日本人にとってとてもストレスフルだという事を思い、僕は、日本人のフィーリングに合うUIの設計の難しさというものを改めて実感した。
20日のアレに先んじて、抜け駆けのようになってしまったけれども……色々話せたのはとても良かったと思う。この時の会話で深まった理解を還元したくて、こうして書いてみた。
Ubiquityにも、コマンドを作る人というのよりももっと深いレベルでこれからコミットできればなあと思う。
Ubiquityは天才じゃないと使えないのかもしれない。あと、Forth、Mind、日本語プログラミング。 - Nov 18, 2008
熱く色々書いてみたけど、書いたら書いたで落ち着いてきてまたネガティブな見方が増してきた。
複数の動詞を繋げて……と書いたのはやっぱり僕の考えすぎ・妄想しすぎだったっぽい。がんがんコミットしてそういう方向にこれから持って行く、っていうことは可能かもしれないけど、Aza氏の想定はそういうことじゃなかったって事のような気がしてきた。やっぱりもっと単純な考えだったのか？ と。
アイコンより言葉の方が分かりやすいんじゃね？という発想。アイコンをたくさん並べていちいち見比べるよりも、言葉を直接入れちゃえばよくね？という発想。その前提にあるのは「沢山の言葉が頭の中に入っていて、瞬時に適切な物が思い浮かぶ」っていうことだ。「頭の中に入って無い」のも「瞬時に思い浮かばない」のも、Ubiquityを使うためには致命的な問題となる。（だから、前のエントリの最後でもセカンドサーチ的な「動詞の提案」という案を書いたんだけど。）
そう考えると、そういう発想が出てくるのはAza氏が天才だからじゃないのか？ 天才が考えたツールは凡人には使えないんじゃないのか？ という疑念がムクムクと膨らんできてしまう。
タイトルが釣りっぽくて誤解されそうだけど、僕だって自分のことは凡人と思ってる。前のエントリに書いたような物が実現されたとしても、自分が使える「動詞」は10個にも満たないだろう、下手したら5個とかそのくらいだ。それ以上はとてもじゃないけど憶えられたもんじゃないだろうと思ってる。いざ使おうとしても「あー、あれ何だったっけなあ、えーと、うーんと、もうここまで（ノドのあたりを指しながら）出てきてるんだけどなああああ」とウンウン唸ってるんじゃないかって気がする。
勝手に妄想補完して勝手に舞い上がって、そしてこうして勝手にまた落ち込んでる自分が恥ずかしいなあ。
という風に考えていた所でplus7さんのコメントに気がついて、plus7さんが紹介してくださったForthというのを見てみた。おおお……これってあの日本語プログラミング言語の「Mind」の元になった物だったのか。こんな物があったとは知らなかった。そうか、「逆ポーランド記法」って、こうして見てみると確かに日本語の文法に似てるんだなあ。
上述した「根本的な問題」＝天才にしか使えないのかもしれない、という点はさておいて、現状のUbiquityが英語的・関数言語的な語順を前提にしているのに対し、日本語に対応するのは逆ポーランド記法的な解釈にも対応するっていう事になるのか、と考えると、プログラムの作り事態に関わる話になってきそうで興味深いと思った。
そういえば、英語式語順は自然な思考の順番に反する（英語ネイティブの人間でも、身振り手振りで説明させると順番が「主語」「目的語」「述語（動詞）」になる）という話もあったなあ。これも何か関係してるような気がしてきた。