ガンホー担当の証券アナリストとかが読んだら、やばくない！？このBOTerの話

ここの記事

超大物BOTerが語るBOT・RMTオンラインゲームの闇
http://blog.livedoor.jp/botbokumetu/archives/50518431.html

ウィリアムのいたずらはオンラインゲームもやんないし、ガンホーの株をもってないので、
あんまりかんけーないのですが、
この話、ガンホー担当の証券アナリストとかが読んだら、やばくない（＾＾；）
うーん。。。

ちなみに、ウィリアムのいたずらのブログ読者には、この話、あまりにも飛びすぎているので
一応、用語説明しておきますと。。。

癌呆　ガンホー・オンライン・エンターテイメント（証券コード3765）のこと
ＲＯ　「ラグナロクオンライン」のこと（ガンホーのオンラインゲーム）
RMT　　リアルマネートレーディングのこと（くわしくはここ）
ＢＯＴ　ここ参照
GM　ゲームマスター
ＢＡＮ　アカウントＢＡＮ（利用禁止措置)

まあ、ウィリアムのいたずら自身、あんまり知らない分野なので、これくらいしかわかりませんけど、それでも、上記のサイトのお話、たのしめます。
　みなさんも、時間があったら（すごーく長い話）、ごたんのーくださいませ

Ｄomによる、ＸＭＬデータ操作を、じゃらん宿表示ＡＰＩで示してみる（その１：仕様とソース）

　ってことをやろうと思ったんだけど、時間がないので、今回は、仕様とソース。
　次回以降で説明を書きます。

---

■仕様
　リクルートの提供ＡＰＩのなかに、「じゃらん宿ＡＰＩ」というのがある。
　ここ　http://www.recruit.jp/mashup2006/api_jalan.html

　ただし、詳しい内容は、実際には、以下のところにある。
じゃらんWebサービス
http://jws.jalan.net/ws/viw/U00001

　で、じゃらんＷｅｂサービス／チュートリアル／あるエリアの宿泊施設を検索するフォームを作成する
　の内容を元に、
　「東京都：130000、お台場・汐留・新橋・品川：137100、お台場・汐留・竹芝：137102」

　地域のデータを取得し、テキストエリアにホテル名と住所をいれよ。


参考：発行するＵＲＬは、以下のとおりとなる
http://jws.jalan.net/APILite/HotelSearch/V1/?key=guest&pref=130000&l_area=137100&s_area=137102

---

■ソース

　以下のとおり

＜?xml version="1.0"＞
＜!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"＞
＜html xmlns="http://www.w3.org/1999/xhtml"＞
＜head＞

＜title＞ＡＪＡＸ版？じゃらん読み取りだよ＜/title＞

＜script language="javascript" type="text/javascript"＞
var	httpObj;
var	timer;		//	タイムアウト用

//*==============================================//
//*	関数：httpRequest()		  *//
//	内容：XML読み取り開始		  *//
//*==============================================//
function httpRequest(target_url)
{
	try
	{
	      	if(window.XMLHttpRequest)
		{
			httpObj = new XMLHttpRequest();
		}
		else if(window.ActiveXObject)
		{
			httpObj = new ActiveXObject("Microsoft.XMLHTTP");
		}
		else
		{
			alert('エラーです');
			return;
		}
	}
	catch(e)
	{
		alert('エラーです');
		return;
	}

	//	タイマーセット
	timer = setInterval("timeoutError()",60000); //60秒にセット

	//	データを取得する
	httpObj.open("GET", target_url, true);
	httpObj.onreadystatechange = DataRead;
	httpObj.send("");

	return;
}

//*==============================================//
//*	関数：timeoutError()		  *//
//	内容：タイムアウト			  *//
//*==============================================//
function timeoutError()
{
	clearInterval(timer);	//	タイマーとめる
	httpObj.abort();
	alert('タイムアウトです');
}

//*==============================================//
//*	関数：DataRead()			  *//
//	内容：XML読み取ったあと		  *//
//*==============================================//
function DataRead()
{
        if ( httpObj.readyState == 4 )
	{
		clearInterval(timer);	//	タイマーとめる
		if ( httpObj.status == 200)
		{
			DataOut();
		}
       	}
}

//*==============================================//
//*	関数：DataOut()			  *//
//	内容：書き出し			  *//
//*==============================================//
function DataOut()
{
			//	返り値ＸＭＬの取得
	xtree = httpObj.responseXML;

			//	ホテルリストの取得
	hotellist = xtree.getElementsByTagName("Hotel");

			//	書き出し
	buf = "";
	for(i = 0 ; i ＜ hotellist.length ; i ++ )
	{
		//	１件分のホテルデータ取り出し
		hotelnode	= 	hotellist[i];

		//	各種データ取り出し
		HotelName = hotelnode.selectSingleNode("HotelName").nodeTypedValue;
		HotelAddress = hotelnode.selectSingleNode("HotelAddress").nodeTypedValue;

		//	書き出し
		buf = buf + "￥n" + HotelName + "　" + HotelAddress;
	}
	document.form1.textarea1.value = buf;

}

＜/script＞
＜/head＞


＜body bgcolor="#ffffff" 
    onload="httpRequest('http://jws.jalan.net/APILite/HotelSearch/V1/?

key=guest&pref=130000&l_area=137100&s_area=137102')"＞
＜form action="" name="form1"＞
    ＜textarea name="textarea1" rows="15" cols="80"＞＜/textarea＞
＜/form＞

＜/body＞
＜/html＞

（上記　＜　＞　￥　は本当は半角）

---

■説明

今度、気が向いたときします（DataOut以外の関数は、こことおなじなので、そのDataOutの中だけ説明します。）

ケータイまで考えると、検索エンジンはサーバー型からＰ２Ｐ型になるのかな？

　前のブログに書いた、グーグルの限界の話のつづき。

　グーグルのような検索エンジンは、結局、クライアントサーバー型で、サーバー側に検索エンジンを置くということになる。そうすると、

　　　グーグルから検索可能になるということは、

　　　すべてのデータはグーグルでアクセスできなければならない。

ということになる。アクセスできなければ検索できないから。

---

　しかし、これは、非現実的である。たとえば、ケータイ電話のメールを考えよう。

　ある人のメールのデータが、他の人、たとえば、彼女とか奥さんとか上司とかに検索できちゃったら、大問題である。

　システムのセキュリティ、ばっちりだから大丈夫！といっても安心できない。

　漏洩する可能性があるから。。

　つまり、秘密にしたいデータは、世の中にあるわけで、それは、自分では検索したいけど、他人には検索されたくないわけだ。

　じゃ、その場合、どうするか。。

---

　答えは、ちょー簡単！

　ケータイ側に、検索エンジンがあって、自分のデータは、そのエンジンで検索して、
　自分以外の外部のデータの検索は、外部に検索要求を出す形にすればよい。

　たとえば、Ａ会社のＢ氏との打ち合わせのメールをもらったが、その中身が見たい、さらにＡ社の資料も見たい。っていうとき、

　ケータイの検索エンジンから
　「Ａ社」
　と入力すると、その検索エンジンは

１．まず、自分のメールやアドレス帳からＡ社の検索データを取得する
２．同時に、ＷｅｂのＡＰＩで、大手検索エンジンに、キーワード「Ａ社」で検索をかける。
３．１、２から見つかった情報を、きれいに表示する

とすれば、ケータイの内容を公開しなくても、大手の検索エンジンと、自分のケータイの中身を見ることができる。

---

　もちろん、このシステムの場合、さらに発展させて、検索結果にもとづき、自動処理を行うようにすると、もっと有効だろう。

　たとえば、宛名に、Ａさん、Ｂさん、Ｃさんとあった場合は、そのメールは、すべて一括削除！という命令を入れられれば、イザというとき（どーいうときだ！）
いっぺんに消すことができる（どーいうときに使うかは、ご想像にお任せするぞ！）

　っていうことで、このシステムは

１．ローカルのデータの検索
２．指定された箇所へ検索を投げ、結果を受け取る
　　→上記の場合は、大手検索エンジンに投げている
３．自動処理も登録可能
　　→ちなみに、検索範囲も指定可能

　っていう機能を満たすことになる。

　でも、ここまでだと、あちら側とこちら側の話でＰ２Ｐでない。

---

　しかし、ここで問題なのは、今の例のようなケースの場合、会社のデータも参照したいだろう。
　このようなとき、どうするか？会社のサーバーにも、上記のような検索エンジンが入っていたとすると、

１．ローカルのケータイで、情報を検索
２．会社の検索エンジンにも、検索を依頼
　　　→大手の検索エンジンには、この会社のサーバーが検索依頼という
　　　　形にしてもいいし、ケータイから直接検索をかけてもいい
３．１．２の結果を見やすく表示

ってことになる。

　ってことは、この検索エンジンは、少なくとも、ケータイから会社の検索エンジンを検索するように登録しておけば、会社の検索エンジンは、さらに大手検索エンジンを検索し。。。っていう感じで検索ができる。そのため、ケータイでは、非力でも、会社サーバーを充実させればいいってことになる。まあ、このような、バケツリレー的な検索、これはまさにＰ２Ｐ検索といえるだろう。

---

　さらに、自分のケータイ情報のうち、差出人Ａさん、Ｂさん、Ｃさんの情報は、見られちゃ困るけど、Ｄ部長からきたメールは、みんなに公開したほうがいいっていうケースもあるだろう。
　そういう場合は、会社サーバーに、Ｄ部長メールの情報を置いて公開できる機能（データごと転送するか、私、その情報持ってる！っていうインデックスだけでいいかは、時と場合によると思うけど、技術的にはどっちも可能だろう）も付けられる。

　ということで、会社サーバーが、データの中継地点ということになる。

　実際の場合、パソコンなら、

１．自分の検索エンジン
２．会社の検索エンジン
　　：（この間にグループ会社の検索エンジンとかもあるかも）
３．大手プロバイダの検索エンジン

　とインターネット上で、組めるけど、ケータイの場合、会社の検索エンジンにアクセスするとき、ローカルに会社のサーバーを立てると思うから、そのローカルのネットワーク（ＬＡＮ）に入っていけるようなＦＴＰ（１９２．１６８指定で入れるような）のしくみが、ケータイにないといけない（あった気がするけど。。たしかではない）

---

　ってことで、自分のデータは検索エンジンで検索し、それ以外のデータは、中継点（たとえば会社とか）に検索依頼をかけるといったＰ２Ｐ式の検索にすると、自分のデータは公開しないで、検索をかけることができる。

　また、中継点に対して、自分のデータを公開すれば、公開したデータのみ、検索対象とできる。

　こうすると、検索エンジンがもろに検索するのは、自分のデータに対してだけだから、さほど大きな検索エンジンはいらないことになる。

　こういったかたちで、今後Ｐ２Ｐ型の検索エンジンっていうものが、考えられて。。
　。。。こないかな？こないか（＾＾；）

　まあ、ついでなんで、これによって、オントロジーの限界を超えるような話を、気が向いたときにでも、しようかな。。

グーグルも時代遅れで、限界ってこと。。

　話題の「ウェブ進化論」を読みんだんですけど。
　まー、半年前の本だからねー、考え方が古臭いっていうのは、しょーがない。

　だけど、この本、読んでると、「グーグルも時代遅れで、限界かなあ・・・」って感じがするね。。
　まあ、その点を上げてみると（以下括弧内のページ数は、「ウェブ進化論」のページ番号から）

●第三章でロングテールについて取り上げている。
　ロングテールの重要なことは、負け犬、つまり出版競争から淘汰された、そんな本でも、意味があり、大きな利益を上げているということだ。
　出版競争は、情報競争といえるだろう。つまり、ロングテールとは、情報競争から淘汰された情報を、今までは切り捨てていたが、そこにも非常に意味があり、大きな利益を上げるチャンスがあるということだろう。

　なのに、グーグルのメンバーは、爆発的に情報が増えたら情報自身が淘汰を引き起こすんだよ（P84）一言で、片付けている。今の時代、淘汰されぞうな情報を、どのように引き出すか、そしてそれが引き出せれば、価値があり、お金になるのに、そーいうアプローチは、お構いなしでいまだにキーワード検索だ（＾＾；）。。。

　その問題点をばしっと突いて、解決して見せたみさこさんの、情報Aのほうが、おもしろかったぞ！


●Web２．０の中心は、その本が指摘するように誰もが自由に、別にだれの許可を得なくても、あるサービスの発展や、ひいてはウェブ全体の発展に参加できる構造（P１２０）だとしている。これは、ウィリアムのいたずらも認める。

　では、さてここで、googleに広告があるのはわずらわしい！といって、だれかが、グーグルから広告をなくして、検索結果だけを表示するサイトを仮に作ったとする（たしか、現状では、これをやらせないためか、グーグルのAPIは、与えられたキーみたいのごとに、１日１０００回しかアクセスできない）。

　それは、便利ですよねえ。広告を見たいわけではないですから。。
　っていうと、この「検索結果だけを表示するサイト」のほうが流行ってしまい、広告は誰も見なくなる。広告を出してる会社には、意味がなくなってくる。。

　つまり、Web２．０が、今後もっとすすみ、マッシュアップが進んできると、わざわざ、機械的な広告なんかははじいてしまう。そーすると、広告会社は、googleに広告を出さなくなるだろう。これへの対策は何も書いていない。グーグル、大丈夫か。。
　Web２．０によって、マッシュアップが進むと、広告の出し方も違ってくるんだけど（それについての私見は、あまりにも話ぶっとびなんで、別の機会へ。ライブドアの臨時株主総会では、ヒントが出てたね）。。


●「グーグルブックサーチ」(P181から）という、世界中の本をスキャンして、グーグルで検索できるようにするということが、著作権違反で訴えられるというのは、あったりまえのことだ。
　ビジネスマンとして、人の権利を奪ってまで、自分が有名になろう、とか、選ばれた人間だけ、利益が享受できればいいなんつー考えが許されるわけはない。

　こんなビジネスモデル、ウィリアムのいたずら様なら、２、３分でちょっと考えれば、もっと皆に受け入れられるモデルに、すぐに変えられるのに（実際さらにその変形が、絶版本の販売になるんだけど）、そんなこと考えないで、自分の考えをごり押しするって、どーなの（ちなみにウィリアムのいたずら様の考えは今後紹介する。その前に、前提となる技術（P2P検索エンジン）があって、それを説明してからなので）

　こんな考えじゃ、本屋さんの広告は出してもらえなくなり。。そーしたら、広告で食べてるgoogleって、どーなのどーなの？？

---

　まー、これ以外でも、「あちら側」と「こちら側」っていう、サーバーとクライアント議論みたいな、古臭い議論や、「自動秩序形成システム」というものがあたかも必要みたいな、グーグルの立場にたちすぎた考え（実際には、そこまで自由になると、人々は「自由からの逃走」を行うって、倫社か？現代社会か？でならったじゃん！これについても、機会があったらね）で、なんか、あちゃーって感じなんだけどね。。

　でも、この本を読んで納得しちゃう人って？？？矛盾、感じないの？？
　たぶん、ウィリアムのいたずらのお客さんたちだったら、すぐに矛盾をついてきて、質問攻めになっちゃうけど。。

　っていうか、ウィリアムのいたずらのお客さんたちと、明らかに違うと思ったのは、
はてなマップの制作費で、ある会社のトップが「数億円、いやもっとかかるに違いないだろう」(P128)と質問してがっくりと肩を落としたっていう点。

　上のほうの偉い人たちって、なにもかんがえないってことだよね。

　これ、どう考える？

「数億円かかるなら、数十億円儲ければいいんだね！ウィリアムのいたずらさん！そーいう絵（ビジネスモデルのこと）を描いて来てよ！」って言われるだけだし、ウィリアムのいたずらの２００１年ころのお仕事は、まさにそんなかんじ！

　つまり、微々たるお金でも、出費は出費、むしろそれ以上の儲け話がプラスになれば、そっちのほうがgoなのよ！なので、そーいう儲け話を考えるっていう発想になる。。

　ちなみに、ウィリアムのいたずらなら、この場合、ゼンリンにたしか、SDKがあったはずなんで、ゼンリンとのビジネス展開だよねーとか考えて。。っていくんだけど、それを書いてると、長くなるので、今回はカットする。

---

　ってことで、この本、ツッコミどころ満載で、ブログネタを一杯提供してくれる。
　ってことで、この次あたりは、気分が向いたら、グーグルの検索方法ではだめで、どーいう検索エンジンが求められるのか、そのP2Pエンジンっていうのを書いてみたいと思う。

P.Sこのほん、そんなにキーワード検索が重要だと思うなら、索引くらいつけろよ！
　ここの引用でページ数調べんの、大変だったんだから（－＿－；）

以降じぶんへのメモ（このとおり書くとは限らない。あくまでもメモなのだ）
今後の予定
　・P2P検索―ケータイメールから、大規模検索までのシームレス感
　・日本におけるインターネットビジネスの変化
　　　　広告から、物品販売とオークションへのモデル変化の理由
　　　　日本ブログ発展史

やばい、じかんないので、ここでUP

editaはWeb2.0のマッシュアップを簡単にできそうだが、とりあえずＢＲＥＷ関係をまとめた

なんか、「edit@」って言うのがあるみたいで

ここ　http://www.edita.jp

あることがらについて、自分が編集長になってまとめられるようだ。

たとえば、ＢＲＥＷについてまとめたいとすると、指定されたブログからＢＲＥＷの言葉の入っている記事をぬきだして、ブログにすると。。

おお、つまり、今流行のＷｅｂ２．０のマッシュアップってやつを、
プログラムをかかずに、簡単にできるっていうことですね！
すごーい！

　まあ、マッシュアップという概念は、今後、流行っていくことは確実だと思う。
　グーグルのキーワード検索は、ブログが繁栄しすぎた結果、自分に関係ないブログばかり検索できて、結局欲しい情報が見つからないという状況になりつつある。
　それへの対抗する１手段として、ある人の観点で記事をまとめて紹介するって言うのが重要で、その方法がマッシュアップってことになる。
　なので、グーグルで見つかんない人が増えれば増えるほど、マッシュアップは必要となる可能性は高い。。。

　そーすると、こういうマッシュアップの自動化ツールも重要。。。

---

　とかなんとか、世間では、高尚な目的が述べられるに違いないのだが、ウィリアムのいたずら、今回は、そこまでいかず、まあ、このブログを見てくれる人は、ＢＲＥＷ関係を見てくれている人が多いので、ＢＲＥＷ関係のまとめブログをとりあえず、作ろうと思って、使ってみました。

　で、作ったのが、これでーす！
ＢＲＥＷ開発関係のまとめ
http://www.edita.jp/xmldtp/

うーん、もっと一覧がずらずらーっとでるほうが使いやすいにゃー
でも、なんか、設定すると、そうなるのかなあ（たぶん、なりそうだよねえ。。。）

ま、とりあえずＢＲＥＷについてまとめてあるので、ここのブログよりかは、見やすいんじゃないかな？

とはいえ、まだまだなので、ちょっと、いろいろと研究してみますね。
うーん、グーグルに対抗すべき、ＢＲＥＷ関連のポータルサイトとなるべき、道のりは、遠い（つーか、はるかに遠い　＾＾；）