Page 16/16: « 8 9 10 11 12 13 14 15 16

2004-12-17

世界最小P2P

Pythonで15行
http://www.freedom-to-tinker.com/tinyp2p.html

Perlで9行
http://ansuz.sooke.bc.ca/software/molester/

Rubyで6行
http://www.rubyist.net/~matz/20041216.html#p01

Slashdot本家、ネタ多し
http://developers.slashdot.org/article.pl?sid=04/12/15/1953227&tid=95

bashで2行
http://developers.slashdot.org/comments.pl?sid=132907&cid=11096822

molesterは外部モジュールを使っていない、本当に9行。
他のは外部モジュールに依存しているところが大きい(特にbash)

単なるファイル転送ではなく繋がった複数のノードの中から
ファイルを見つけてきて転送するという動作するあたりがポイント。
だと思われる。
----
時期を同じくして似たような記事が。
.NETで実装する簡易ファイル交換ソフト
http://www.atmarkit.co.jp/fdotnet/special/networkprog/networkprog_01.html

何行だ、何行だ?
とりあえずLL最強ということで。

2004-12-13

Google Suggestをいかにパクるか

単純に補完機能を実装するだけであれば、
RandomNoteのようなユーザーの検索クエリ、全文検索結果の件数を
キャッシュする機構を備えれば、わりと簡単に作れるだろう。
検索ヒストリをインクリメンタル検索するだけでいい。

これを「手法A」と呼ぼう。呼ぶことにする。

----
ユーザーの入力した語句から取ってくるのが一番楽ではあるけれど、Googleのやっていることはそれだけではない。

Google Suggestがいかにしてその語句を選び出しているのか、という
サーバーサイドの処理に関しても、もっと注目を集めていいのではないかと思う。

例えば「GoogleといえばToolbar」のような連想は、単純に検索結果が多い順ではなく、その語句に対して関連付けられた単語のうちで特徴的なものを検出し、それらをランク付けした結果だろう。

検索されたキーワードを人気キーワードのランキングとして公開する手法はかなり前からあったが、単語同士の関係性まで含めて統計として利用している点が目新しい。

----
GoogleとAmazonはデータマイニングの最先端にあって、両極だ。
両者とも大量に蓄積されたデータベースから
有用な情報を効率よく取り出すことで利益を上げているが、その方法論は全く異なる。
手法AはAmazonのA。手法GはGoogleのG。

Amazonはユーザーの行動、購入履歴から
あなたにお薦めの本を見つけ出すが、

Googleであれば、本の中身を全文検索して
あなたにお薦めの本を見つけ出すだろう、ということだ。

Amazon的な、Googleがあれば
-このリンクをクリックした人はこんなサイトも見ています。
-もっともお気に入りに追加されているサイトを上位に表示。
-この語句で検索した人は、こんな語句でも検索しています。

プライバシー云々の懸念はあるものの、手法Aを使うメリットは大きい。

莫大な計算なくしては導き出せない検索結果が徒労に過ぎず、
人に聞けば一瞬で解決してしまうようなこともあるものだ。

JavaScriptを使ったやや高速なDiff概要

多分もっとちゃんとしたアルゴリズムがあるんだろうけど
適当に思いついたので書いてみる。

配列new_lineとold_lineの比較。
まず、先頭キャラ1文字をキーにした連想配列を作っておく。
例えばAで始まる行の行番号が2,4,6だったとすると。
AのcharCodeが65なので。

old_first_char[65][0] = 2
old_first_char[65][1] = 4
old_first_char[65][2] = 6

こんな具合の配列ができる。
同様に、新しい配列のAで始まる行も調べておく。
互いの「A」で始まる行のうち0~3番目の行番号の内容を比較する。

old_line[old_first_char[65][0]] と new_line[new_first_char[65][0]] を比較する。
old_line[old_first_char[65][1]] と new_line[new_first_char[65][1]] を比較する。

new_first_char[65] = [2, 4, 6]だったとしたら、たった3回の比較で終了する。
文書が殆ど変更されていない場合は、n回のループで比較が終了することになる。

典型的な富豪的スクリプターなのでオーダーlogだのnmだのn^2だのとか
良くわかってないが、多分こんな感じ。
単純にループさせると9行の場合はループ回数9*9で81回。
先頭文字がAAABBBCCCなら最大(3*3)*3で27回ですむ。

短い文章の場合はonkeyupで処理しても負担は少ない。インクリメンタルDiffだ。
テキストエリアの編集の場合、エンター押すたびDiff取るのが良いかもしれない。
ただ、JavaScriptは大きな配列を扱おうとすると、とたんに遅くなるのが困り所。

まだアップしてないネタがたまってきた。
アップするのが面倒くさい。

2004-12-11

悪のJavaScript

結構やばめのスクリプトを書いた。
ユーザビリティの向上に役立てたいのだが、悪いことにも使えてしまう。
は、
タイピングの軌跡まで再現できるようなチャットを作ろうとして、
それの材料として作った。まあそのうち公開できるかもしれない。

[JavaScript] 実用的なエディター

JavaScriptで書かれた化け物みたいなアプリケーションに
htmlAreaというのがあるのだが、WYSIWYG編集よりも、
きちんと実用的なエディターを作る方が良いんじゃないか、とも思う。
WYSIWYGは確かにわかりやすいし、簡単に実装できるが、
それよりも、構造化された文章をきちんと書きたいのだ。
アンドゥ、リドゥ機能。その場でのプレビュー。
行番号表示、アウトライン解析、辞書補完、GREP編集。

GREP編集てのは単語が含まれてる行を抽出して
それをそのまんま編集できるような機能。
なぜか見かけない。あったら絶対便利だろうに。

Suffix Array に関する論文を読んでいて
http://namazu.org/~satoru/sary/

JavaScriptを使ったDiff出力を高速化する方法を思いついた。
速度によっては実用的に使えるものになるかもしれない。

2004-12-10

Bloglines

日本語対応きっかけに少し前から使っているのだが
さすがに使い勝手がいい。改善の余地は大いにあるけれどよく考えられてる。

P2P使ったスマートな負荷分散やらキャッシングやらが普及しない限りはRSSリーダーはウェブサービスとして実装されるほうが受け入れられるのだろうな。データを自分のマシンに蓄積しておきたい、という需要もあるのだが、件数が増えるとさすがに巡回もつらくなってくる。

APIで更新日時付きのRSS一覧が取得できれば最高なんだが。
WEBに埋め込むにしても単に一覧出しただけじゃ面白くない。
やっぱ自前でアンテナ実装しようかな、という気もしてくる。

[Perl] WWW::Google::PageRank

WWW::Google::PageRankは
Googleツールバーからのアクセスを再現して
ウェブサイトのページランクを取得してくれる。

Google的にアリなのかどうかはわからんが、
特定用途、主にGoogleのページランクが知りたいときなどに役に立つ。

被リンクやトラックバックなんかをページランクでソートできたら面白いんじゃないかと思ってみたり。

2004-12-09

[Perl] Class::DBI

最近作ったものに。

Class::DBIからDBD::Googleを呼び出すという検索スクリプト。
ここまで抽象化できるとなると、使い方も変わってくる気がするのだ。

GoogleAPIに手を出すと、Googleの機能を使うことに夢中になってしまいがちなのだが、DBD::GoogleというモジュールはGoogleへのアクセスをデータベースドライバとして実装している。そしてClass::DBIはデータベースをオブジェクト構造として扱うことができるようになる。

Class::DBI::Cacheableというのと組み合わせれば透過的キャッシュを利かせられる、ネットワーク越しのGoogleへのアクセス回数を減らし、応答速度を高められるだろう。

もはやなにがなんだか。
何かしらついでにGoogleの検索結果を表示するようにしてみたい。

と思ったら。
Class::DBI::Cacheableはretrieveのオーバーライドのようだ。
複雑なクエリーの場合は使えない。やはり自前でキャッシュ管理すべきか。


キーワード

リンクの管理、キーワードを使うべきだろう。
例えばWiki風に[[]]でリンクすべき単語を囲うことで明示的なリンク。単語登録され、リンク先アドレスを設定する。

その語句が他のエントリ内に存在していればキーワードのオートリンク、明示的ではないリンク。

みたいな。

サムネイル自動化機構が大体、見えてきた。半自動化というべきか。Win32::CaptureIEを使っている。

2004-12-07

とりあえずの予定

もうね、何だかんだでBlogでしょ。
とりあえず適当なツール書いてアップすんにも何かと都合がよさそうなのでBlogでも書いておくかな、みたいな感じで。バグ報告とかバージョンアップとかメンテナンスとかその他もろもろも全部Blogで、みたいな。

まあそんなところで。
個人的にちまちまと書いているものを、発表していけたらと思ってたりします。

短期的プロダクツ
-このBlogのカスタマイズ(適度に)
-コードネーム BlindBind

長期的プロダクツ
-最強のWikiエンジン
-横断検索エンジン

詳しく説明しようとすると大変なので適当に。

BlindBindは今までにない(少なくとも自分は聞いたことない)種類のソフトウェアで、需要が多きい(はずなのだが誰も必要としていない)ソフトウェアです。なんのこっちゃ。

Wikiとか検索については蔵出ししてないようなアイディアがいくつもあり、ただ、どうせなら言葉で書くよりも動くもんで見せたいという欲求があり、ちまちまと書いていたりします。

[Blog] サムネイルの自動作成

MTはなんだかややこしくなってるし、ダウンロードするのに登録とか必要になっていたので、blosxomを使うことに決まったわけで。

以前書いたスクリプトをちょいと流用、まだ最低限の機能しか実装していない。せっかくなのであまり他で見かけないような機能を実装してみようかと思う。

大まかな案としては。
-文中のリンクを抜き出して
-自動でタイトル取得とサムネイル画像を生成
-最近言及されたページを画像で一覧表示、JavaScriptでの検索など

便利なモジュールが色々見つかったので割と簡単に出来そう。

2004-12-06

wikiの今後

黙殺されてるのかと思ったらレポートが載っていた。

http://bb.watch.impress.co.jp/cda/event/7742.html
http://pcweb.mycom.co.jp/articles/2004/12/06/internetweek/

wikiにビジネスモデルという言葉は疎遠だ。

あーしてこーして金が儲かるといった、わかりやすい成果は期待できないが、情報共有が生産性を上げて、経費を削減するというのは確かだ。Wikiを導入することで得られるメリットと、導入にかかるコストを正確に計算できるやつがいねーから、たぶんいつまでもこんなんなんだろう。

自動リンク

自前のフィルタ作った。
改行をbrにするだけ。
あとは関連リンクの作成。

タイトル調べてエントリ名が入ってたらリンク付記する。
マウスオーバーでハイライト。

ファーストポスト、こんな感じ。

ファーストポスト

あー
まあね。
いろいろあったよいろいろ。

いろいろね。
いろいろ