※IE限定です、JavaScriptとActiveXを有効にする必要があります。
| 声色 | |
| 音量 | |
| 速度 | |
| 声の高さ |
Ajaxを使ったはてなキーワードインクリメンタルサーチというのをとくひろさんが作ってたので、対抗してAjaxを使わないはてなキーワードインクリメンタルサーチというのを作ってみました。
http://la.ma.la/misc/hatena/
CPUが遅いマシンだとブラクラなので注意。推奨2GHzぐらい。1GHzでもそこそこ快適。IE、Firefox、Opera8で動きます。safariでは動きません。最初にgzip圧縮済みキーワードリスト1.3MBを受信するので回線が遅いと利用開始までに時間がかかります。また、メモリをたくさん食います。
ドキュメントを書くのが面倒くさいので気が向いたら詳しい解説を書きます。
以下簡単な説明。
----
下準備
1.キーワードリストを取ってくる
2.kakasiで振り仮名をつける
3.文字コードをUTF8に変換、gzip圧縮して保存
JavaScriptの処理
1.キーワードのリストをXMLHttpRequestを使って受信(初回のみ)
2.ローマ字からmigemo風の曖昧検索用の正規表現文字列を作成する
3.受信したキーワードのリストから検索、euc-jpのURLエンコードして画面に書き出し
サーバー側でふりがな処理、クライアント側でローマ字かな変換と処理を分散することで、完全ではありませんがmigemo風の曖昧検索を実現しています。
それから、JavaScriptでgrepをやらせるのに、今までは配列をループさせてString.search()で検索していたのですが、このキーワード検索は巨大な文字列からRegExp.exec()で検索しています。マッチする箇所が見つかったら、左右の改行位置で行を切り出し、検索開始位置をずらして次のマッチ箇所を探します。とまあ、結構面倒くさいことをやっています。
今までは1000件程度ならJavaScriptで検索をやらせた方がいい、と考えていたのですが、この方式であれば、1万件ぐらいまでは余裕です。さすがに10万件はどうかと思いますが、1万件ぐらいなら余裕です。強調しておきます、1万件ぐらいまでは余裕です。この場合は件数というよりも「1MBぐらい」といったほうが正確かも。
問題は、必ず最初に1.3MBをダウンロードしないといけない点で、300KBずつに分割なんかも考えたのですが、面倒くさいのでやめました。イントラネット内だとか、ローカルに保存して使うなどの場合は全然問題無いのですが、逆にそういう回線が速くてサーバーを自由にいじれる環境ならそれこそAjaxを使っておけという話になるので存在意義が微妙です。
まあ、pure JavaScriptでも10万件から検索することができるよ！と、選択肢を一つ増やしてみた感じです。
実際は、何が速いとか遅いとかよりも、上下カーソルで選択してエンターで開けるようにしてみたりとか、そういう細かいところのUIのチューニングの方がよっぽど重要で、Googleが頑張ってるのもまさにそのあたり。バックエンドがどうなってようとも、ユーザーにとってはどうでも良いのではないかと思います。
http://la.ma.la/misc/hatena/
CPUが遅いマシンだとブラクラなので注意。推奨2GHzぐらい。1GHzでもそこそこ快適。IE、Firefox、Opera8で動きます。safariでは動きません。最初にgzip圧縮済みキーワードリスト1.3MBを受信するので回線が遅いと利用開始までに時間がかかります。また、メモリをたくさん食います。
ドキュメントを書くのが面倒くさいので気が向いたら詳しい解説を書きます。
以下簡単な説明。
----
下準備
1.キーワードリストを取ってくる
2.kakasiで振り仮名をつける
3.文字コードをUTF8に変換、gzip圧縮して保存
JavaScriptの処理
1.キーワードのリストをXMLHttpRequestを使って受信(初回のみ)
2.ローマ字からmigemo風の曖昧検索用の正規表現文字列を作成する
3.受信したキーワードのリストから検索、euc-jpのURLエンコードして画面に書き出し
サーバー側でふりがな処理、クライアント側でローマ字かな変換と処理を分散することで、完全ではありませんがmigemo風の曖昧検索を実現しています。
それから、JavaScriptでgrepをやらせるのに、今までは配列をループさせてString.search()で検索していたのですが、このキーワード検索は巨大な文字列からRegExp.exec()で検索しています。マッチする箇所が見つかったら、左右の改行位置で行を切り出し、検索開始位置をずらして次のマッチ箇所を探します。とまあ、結構面倒くさいことをやっています。
今までは1000件程度ならJavaScriptで検索をやらせた方がいい、と考えていたのですが、この方式であれば、1万件ぐらいまでは余裕です。さすがに10万件はどうかと思いますが、1万件ぐらいなら余裕です。強調しておきます、1万件ぐらいまでは余裕です。この場合は件数というよりも「1MBぐらい」といったほうが正確かも。
問題は、必ず最初に1.3MBをダウンロードしないといけない点で、300KBずつに分割なんかも考えたのですが、面倒くさいのでやめました。イントラネット内だとか、ローカルに保存して使うなどの場合は全然問題無いのですが、逆にそういう回線が速くてサーバーを自由にいじれる環境ならそれこそAjaxを使っておけという話になるので存在意義が微妙です。
まあ、pure JavaScriptでも10万件から検索することができるよ！と、選択肢を一つ増やしてみた感じです。
実際は、何が速いとか遅いとかよりも、上下カーソルで選択してエンターで開けるようにしてみたりとか、そういう細かいところのUIのチューニングの方がよっぽど重要で、Googleが頑張ってるのもまさにそのあたり。バックエンドがどうなってようとも、ユーザーにとってはどうでも良いのではないかと思います。