2008年02月21日
集客のためのコンテンツ
チャットはログの永続化やエラー時の処理などを実装し、"チャット"の部分は完成した。
匿名掲示板のようにオープンで、かつリアルタイム性の高い実況掲示板的なチャットは十分魅力的なコンテンツになり得るだろう。
が、実況チャットは致命的な弱点もある。
世の中には、人がいない実況チャットほど無価値で無意味な存在はないと言うことだ。じゃがりこサラダ味を置いていないコンビニ以上に無価値だ。
にちゃんねるの閲覧者全体における投稿率が10%前後と言うことで、感覚的にはチャット閲覧者は100人の単位で必要だと考える。それぐらい集まらないと面白くはならない。(そしてこの目標の達成は簡単ではなさそうだ)
よって次のタスクは"人を集める"と言うことになる。
ユーザを呼び込むためには主に次の二つの手段がある。
1,広告を出す
2,検索エンジンからのリンク
強引に呼び込むのは1の広告が有効だろうが、個人では現実的な手段ではない。
よって必然的に2の検索エンジンを使うことになるのだが、当然チャットだけあっても誰も来ない。
と言うことで番組に関する情報サイトを作り、そのコンテンツの一部としてチャットをつけることにする。
情報が集約されているサイトであれば検索に引っかかりやすいのはもちろん、実用的な意味でもリピータが期待できる。
タスク"人を集める"の手段として"情報系サイトの構築"と言うことになる。
なんだか順序が逆のような気がするが、頭の中ではメインのゴールは"情報系サイトの構築"が先だった。
情報系サイト作ろう→チャットもあると面白そう→チャットはCometとAjax使いたい→それプログラム書いてて面白そう
と言う流れでチャットを先に作ってしまったわけだ。
情報系サイトと言ってもいろいろあるわけだけど、ターゲット(方向性と言うべきか？)はAmazon的なものになる。
つまりユーザが番組に対しスコアを付け、どれぐらい評価されているか知ることができ、またその対象アイテムを評価している人は別のこういうアイテムも評価している。と言うことを知ることができるサイトだ。
Wikipediaの情報密度と情報量はすばらしいがデータマイニングはしてくれない、「情報がそこにある」だけなのだ。
攻殻機動隊が好きな人はネット関連経由でserial experiments lainも好きだよね。
serial experiments lainが好きな人は安倍吉俊関連で灰羽連盟やNieA_7が好きだよね。
灰羽連盟が好きな人は・・・・。
と言う情報が必要なわけだ。この情報により「見たけど自分に合わないのでつまんなかった」と言う事を回避できる可能性が高まる。
ちなみにこれらの情報系サイトやチャットを作ろうと思った最初のきっかけは、こういうサイトが存在しないandそういうサイトが欲しかったからだ。
と言うことでダラダラと内容の薄い文章を書いてしまったわけだけど、これからは情報系サイトの開発をしますよと言う事だ。
2008年01月30日
2008年01月28日
2008年01月19日
JSONP対応完了＆オペレータ機能
チャットサイトのJSONP化が完了した。
これでIEでも完璧に動作させることができた。
ついでにjQueryのフェードイン機能などを使い無駄に表示を派手にしてみた。
さらにオペレータ機能も追加。
チャットルームに常駐しているオペレータの人工無能に対し自然言語で話しかけることによってオペレータに対し指示ができる。現在はチャットルームのサブタイトル変更を指示することができる。
たとえば「サブタイトルを「Cometチャット！」に変えて＞オペ子」とチャットで発言することにより変更が可能だ。
オペレータへの入力は、文末に「＞オペ子」をつけることによって入力となる。
オペレータに対して入力された文章は、形態素解析器Senによって形態素に分割され、処理される。
といっても現在は"サブタイトル""変"が発話に含まれているかだけしかみていないが。
より良い実装のアイデアとしてはコマンド入力例を例文として多数用意しておいて、ユーザの入力文の形態素解析結果をベクトルとしてベクトル空間上でのコサイン距離を測ることによって一番近いコマンドを判断するという感じか。
複雑なことをしようと思うと形態素解析だけでは不十分で、構文解析も必要なんだけどJavaから利用できる構文解析器が無いため現在はしていない。
使うとしたらCaboChaあたりをサーバ化して、TCP経由で構文解析をするって感じだろうか。
チャット機能はIE対応をもって完成したわけだが、チャットルームやそのサブタイトルなどの情報の永続化ができていない。
これらはRDBに保存するのが楽かな。
よって部屋のメタ情報はMySQLに入れ、ログの情報はファイルに書き出すことにしよう。
起動時はDBから部屋の情報を取り出し、最終状態に復元するという感じで。
一人でこういうシステムを作成しようとすると、プログラミングの知識はもちろんOS,Webサーバ、アプリケーションサーバ、データベース、通信プロトコル、ネットワークその他諸々の知識が総合的に必要なのでそれらの学習コストが大きく大変だな。それがおもしろくもあるけど。
まぁ広いジャンルでの経験値が得られるので良いことだ。
2008年01月17日
jQueryでAjaｘ
現在作成中のチャットサイトにはAjaxのライブラリとしてPrototypeを使用しているが、いろいろ調べてみるとjQueryが高速軽量でいい感じらしい。
JSONPが簡単に使えるのもいいな。
また、魅力的で豊富なプラグインがそろっているのもすばらしい。
現在それほどPrototypeに依存しているわけではないので、JSONP対応を機にjQueryに移行しよう。
jQuery で JSONP ２通り
[JS]jQueryのプラグイン33+1選 -2007年11月
まずはjQueryに移行してからJSONP対応をするか。
2008年01月16日
IE問題の解決策
IEでCometを実装すると問題が発生する件は、回避策がいくつかありそうだ。
1,チャットルームへ入るたびに新規のサブドメインを割り当てる。
2,JSONPを使う。
世の中的には2のJSONPを使うやり方が一般的のようだ。
JSONPはXMLHttpRequestに存在する他ドメインへのアクセス制限を回避することができる。
が、JSONPはXMLHttpRequestと違いタイムアウトなどエラー時のハンドリングができない。Operaで動作に問題があるなどするようだ。Operaでの回避策は一応あってOperaでも非同期リクエストが並列処理できる img-JSONPを参照。
ふーむ、1のやり方で回避できそうな気もするけど・・・。
Lingrは発言などの投稿はwww.lingr.comへ。新規ログの取得はランダムサブドメインを読むようにしていた。別ドメインにアクセスしに行っているからJSONPだろうか。JavaScriptのソースは読んでないので推測だが。
JSONPを導入するとopera対応も必要だし、とりあえず部屋に入るときにランダムサブドメインを生成するページを経由し、その後そのドメインを使用した部屋にリダイレクトするようにするか。
その後、何か落とし穴があるようだったら素直にJSONPに移行しよう。
というわけで、リダイレクトを使って動的にサブドメインを作るやり方でIE問題を回避した！
これによりIEで部屋の出入りをしてもセッション数制限で不具合はでなくなった。
が、F5でリロードしてしまうとセッション数が足りなくなってやはり問題が・・・。
F5禁止にするかJSONPにするか・・・。
やっぱJSONPが無難かな・・・。
2008年01月15日
IEとCometの相性
IEでHTTPセッションを張りっぱなしにする問題で検索していたら以下のページが見つかった。
IEとCometの相性が悪い
やはりIEでCometは問題があるようだ。
確かにLingrではチャットルームに入るたびにサブドメイン名が変わっている。
IEで使えないと話にならないので対応するしかないようだ。
一度、ランダムなサブドメインを生成するページに飛んでから、そのランダムなサブドメインでチャットルームにリダイレクトするページを作らないとだめなのか。
めんどくさいが仕方あるまい。
まぁ解決策がわかったのでよしとしよう。
しかし部屋ごとにサブドメインを分けるのには気がついたが、部屋に入るごとにサブドメインを生成するのに気がつかなかったのは悔しいな。
2008年01月12日
ログの永続化
さて、「今年はやるぞ！」と書きつつも仕事が忙しくて全然プログラミングが進んでいないわけですが、間を開けるとまたモチベーションが下がってしまうのでちょっと手を出してみる。
しかし相変わらずIEでは動作が怪しい。
発言しようとしても同時セッション数制限で発言用HTTPセッションが張られず、発言ができなかったり、そもそも部屋に入れなかったり・・・。
ログ取得用と発言用のドメインを分けようとしてもJavaScriptからはセキュリティ上の制限で同じドメインのサーバにしか接続することができないからなぁ。
まぁとりあえずその問題は置いておいて、作るのを進めるとするか。
現状のチャットでは、ログの永続化がされていない。
よってサーバを再起動するとログが消えてしまう。
今回はこれの永続化をやってみよう。
現状のチャットサイトではMySQLを使っているが、チャットのログなど読み込みよりも書き込みが激しいデータはRDBに入れるのはまずいだろう。なぜかというと読み込みが多い場合、MySQLのサーバをクラスタリングなどすれば楽に対応できるけど、書き込みの場合はそれができない。普通にクラスタリングをしようと思うとレプリケーションになってしまい、書き込みサーバを増やすことができないからだ。
よって先人に学び、ニコニコ動画のログのようにCSVで保存しよう。
XMLなどリッチな形式にしようかとも思ったけど、チャットのログのデータ形式が激しく変わるとも思えないので単純にCSVで。
CSVならログの追加もファイルに追加していくだけなので楽だ。
単一のファイルならでかくなって困ることがあるので、毎日ファイルのローテーションを行うと言うことにしよう。さらに速度確保のため保存処理は一定間隔毎とし、ユーザの発言処理で発生するIOはメモリのみと言うことにする。
と言って保存したところで読み返すことは無いと思うが・・・。
荒らし対策にIPアドレスの記録がメイン目的と言ったところか。
以前のチャットルーム参加者人数が減らない問題は新規ログの取得が一定時間無いと退出したと判断。
一応チャットウインドウを閉じたり、他のページに遷移するとログオフイベントを投げるようにしているがうまくいかないときもあるようだ。
