RSSファイルの集積地として有名なrss-jp.netさんですが、現在トップページにアクセスすると勝手にエロオンラインチャットのページが表示されるようになっています。昨年も長期間に渡って似たような現象が発生していましたが、いったいどうなっているんでしょうか。

　2005/2/23 15:50現在
　http://rss-jp.net/ だとエロオンラインチャット

　http://rss-jp.net/index.html だと正常な画面が表示されます。

　おそらくApacheの DirectoryIndex が誤って設定されているんでしょうけど、気持ち悪いので勘弁して欲しいところです。

　少し調べてみたところでは、http://rss-jp.net/index.php にアクセスすると

Location: http://rss-jp.net/dxlive.html?num_cols=5&available=true&flags=true&lang=jp

　が返ってきますので、DirectoryIndex での優先順位が index.html よりも index.php のほうが高くなっているのでしょう。

　何故このようなミスが起こるのか、はたまた故意でやっているのか真相が知りたいです。

ITmediaニュース：さよなら「GO」コマンド　ニフティ、パソコン通信サービスを終了

終了するのは「ワープロ・パソコン通信」サービス（TTY接続および関連サービス）。ほとんどのサービスはインターネットの＠nifty上でも利用でき
るが、代替できないサービスもある。各種ログの閲覧もできなくなる。

　ニフティサーブがパソコン通信サービスを終了するのだそうだ。確かに今の時代には全くあわないので仕方ないんでしょうね。300bpsモデムの時代にパソコン通信をはじめた私ですが、なかなか有料課金に価値を見出せず、ニフティサーブに入会したのは1989年の事でした。（たぶん、FM-TOWNSを買った勢いで入ってしまった)

　当時、ニフティにはあらゆる情報が集積していたけど、中でもTri-PやTYMPASを利用したパケット通信で海外のネットワークに接続できる事に強く惹かれ、関係フォーラムによく出入りしました。ニフティのF1関連フォーラムで有名だったすがやみつるさんはこの関係でもかなりアクティブに活動しており、超初心者だった私のアホな質問にも丁寧に答えていただいた事があります。ありがとうございます。

　ま、それはともかくこのフォーラムで知ったのが日本Sprintのパケット通信。確かに安価なサービスでしたが今から考えると信じられない位の大金を海外通信につっこむ事になりました。これらのパケット網を通じてCompuServe、GEnie、日経mixの元となったBIX等にとりあえずかたっぱしから入会。そうこうしているうちに、unixのシェルを使わせてくれるサービスに出会います。これがインターネットとの初めての出会いでした。まだ日本にAT&T JENSもIIJもTWICSも無い時代にtelnetやftp、netnewsが使い放題というのはあり得ない話でしたね。あれから10年余り、我が家には100MのFTTHが引かれ、常時接続でほとんどなんでもやりたい放題なわけで、あの頃とはまさに隔世の感があります。そんなわけで、インターネットに出会うきっかけを与えてくれたニフティ(とスーパーアスキーに記事を書いてた元麻布春男さん)には大変感謝しております。

　もう一つニフティでお世話になったのはフロッピーのバケツリレー。今で言うところのオープンソフトウェアであるTeXやPC-UNIX(確かBSD386)はFDで数十枚にもなるソフトウェアでして、モデムでダウンロードすると何日かかるかわからないようなシロモノ。そこで編み出されたのが、希望者を募り、該当ソフトウェアのフロッピーセットを希望者がリストに沿って順繰りに送っていく方式。セットが届くとせっせと自分のFDにコピーし、終了したら次の人に送るという、今から考えるとなんともアナクロな方法ですが、実際にダウンロードするより速いし、（従量課金の）お金もかかりませんから極めて合理的な方法だったといえます。(さすがに、PC-UNIXはWalnut CreekのCD-ROM購入に切り替えましたが)

　他にニフティサーブではここには書けないようないろいろな事がありましたが、みんな楽しい思い出です。お世話になりました、ありがとう。

　いつもお騒がせのギャンブル会社 GoldenPalace.com ことゴールデンパレスカジノが、先ごろよりオークションに出されていたボストンのフリートスタジアムの１日命名権を獲得しました！この日の試合は、 ボストン・セルティックス対メンフィス・グリズリーズだそうです。NBAよく知らないのですみません。テレビ中継があったらおもしろいんだけど無いみたいですね、残念。

　落札したのは１日命名権初日の2月16日分で(つまり、日本時間の明日！)、なんと $35,099.00で落札！ざっと360万円です。eBayのオークション結果を見るとかなり加熱していたようですが、最後の最後にざっくりさらっていったっぽいですね。

　既に終了している分の落札価格は、2月17日分が$3,050.00、2月18日分が$3,551.00、2月19日分が$3,855.00、2月20日分が$3,383.33、2月21日分が$3,000.01、最終日の2月28日分が$2,550.00、残りはまだ開催中ですが、だいたい$2,500.00～$3,000.00である事を考えると、(露出の多い初日分とはいえ)他の日の約10倍で落札した事になります。恐ろしいですねぇ。

　このゴールデンパレス、最近では妊婦のどうのこうのっていう落札がありましたがよくわからなかったのでスルー。あれはなんだったんだろう？

　Ｊリーグの応援サイト J's GOAL は公式の応援サイトとして大変人気のあるサイトで、各チームのニュース等も発信している大変有意義なサイトです。

　この J's GOAL の全体のニュースのヘッドラインをRSS配信しているサイトがあるのですが、特定のチームだけのニュースヘッドラインが欲しい！あちこち探しましたが、探し方が悪いのか見つけられません。しょうがないので自分でチーム別にRSSを定期的に生成するようにしてみました。

　右上の書籍「入門RSS」は所有している事をすっかり忘れていたのですが、このスクリプトを書いた後に思い出してパラパラ読み直してみました。RSSに関しては他にマトモな書籍を知らないという事もありますが、大変よくまとまっています。この書籍ではperlのモジュールを使った方法が紹介されていてperl使いの人には即実践も可能でしょう。

　以下のJ1/J2全チーム、およびＪリーグ、J's GOALニュース、JFAと J's GOALに掲載されている区分でのニュースヘッドラインを配信中です。よろしければご利用下さい。

　RSS勝手配信(β)ページはこちら

Ｊ１
鹿島アントラーズ、浦和レッズ、大宮アルディージャ、ジェフユナイテッド市原・千葉、柏レイソル、FC東京、東京ヴェルディ1969、川崎フロンターレ、横浜Ｆ・マリノス、アルビレックス新潟、清水エスパルス、ジュビロ磐田、名古屋グランパスエイト、ガンバ大阪、セレッソ大阪、ヴィッセル神戸、サンフレッチェ広島、大分トリニータ

Ｊ２
コンサドーレ札幌、ベガルタ仙台、モンテディオ山形、水戸ホーリーホック、ザスパ草津、横浜FC、湘南ベルマーレ、ヴァンフォーレ甲府、京都パープルサンガ、徳島ヴォルティス、アビスパ福岡、サガン鳥栖

その他
Ｊリーグ、J's GOAL、JFA(日本サッカー協会)

Amazon Web サービス ブログより～

エディターレビュー、およびカスタマーレビューに文字化けが含まれるとXML的にエラーになる点を修正しました。
ECS v.4でもECS v.3と同じように、文字化けが含まれていても処理できるようなコードにしています。

　先日、Amazon Webサービス(ECS)でレビューを取得した際に、レビュー中に不正な文字が含まれていると正しく結果が取得できないと書いたばかりですが、2/9に2005-01-19バージョンがリリースされ、対応したとの事です。日本語版は2005-01-19バージョンのリリースが遅れていたんですが、この処理を追加していたんですね。

　早速、オリジナルのnusoap.php(CSV 1.84)に差し替えてみたところ、問題なく取得できていることが確認できました。Amazon Webサービスの中の人吉松さん、対応ありがとうございます。一ユーザとして大変嬉しいです。

　この問題に苦しめられていた人は多いと思うので吉報ですね。

　また、同時にマーケットプレイス系のオペレーションも開始したそうです。

　GoodpicさんでGoogle Mapsを知りました。コレ、スゴイです。

　ページが切り替わることなく地図が拡大・縮小・グリグリスクロールします。FlashでもJAVAでもない、JavaScriptのむこうはいったいどうなっているんでしょうか。

　試しに昔お世話になったシアトルの[uwajimaya](宇和島屋)を検索してみました。全米の地図からだと[seattle uwajimaya]、既にシアトル界隈を表示していたら[uwajimaya]だけで検索できます。若干ノイズも混じっていますが、見事にUwajimayaさんが検索されて地図上に表示されました。検索されたポイントをクリックすると DirectionのFrom/Toが設定でき、住所を入力すると地図上にルートが表示され、右側に道順と要所要所のポイントが表示されます。いわゆるナビですね。

　日本にはここまで簡単に使える地図はネット上にはないはず。AdwordsとOvertureを両方使い始めた頃から感じていましたが、GoogleのUIってとても優れていますね。

　シアトルといえばMS。MSといえば古川さんですが、古川氏のblogに登場する I love SushiやWasabi Bistroもちゃんと検索できました。I love Sushiってこんなところにあったのね…。

　プログラム上で、Amazonの書籍やDVDの検索、詳細、出荷時期、レビューの取得等ができるウェブサービスというAPIをAmazonは提供している。サイト側で動的な表示ができるという点で大変重宝するサービスで、各blogのAmazon plugin等はみんなこのサービスを使っているようだ。

　ウェブサービスは他にもGoogleの検索・AdWordsや、オークションのBiddersも提供しているため、プログラムさえ組めば自サイトでGoogleの検索を利用したり、AdWordsの結果を知ったりキャンペーンを作ったり、Biddersの出品物を並べたりすることができる。
　中でもAmazonが一番人気なのはアソシエイト(アフィリエイト)と組み合わせて実利に直結させることができるからだろう。最近ではMac用の独立したアプリケーションまで存在するらしい。

　私も以前PHPとnusoapを使って検索できるものを試しに作ったものの、そのままほったらかしていたのだが、ついにこの機能を実装する必要が出てきてしまったので、再度Amazonウェブサービスを弄る事となった。

　取得したいデータは、「書籍名」「著者名」「新品価格」「ユーズド価格」「発送時期」「おすすめ度」「レビューした人数」で、複数のキーワードでの検索結果をマージして売れ筋ランキング順に10件分が必要。これらは、Amazon Webサービス ECS4.0だとオペレーションがItemSearch、SortがSalesRank、ResponseGroupを Medium,Reviews,Offerfull とすれば取得できる。

　…いや、できるはずだった。

　いざ PHP+nusoap.phpで取り組んでみたところ、売れ筋ランキング(SalesRank)がおかしい。ソート順をSalesRankとしても、一つ一つのデータを見てみるとSalesRankが昇順に並んでない。Google先生に聞いてみたところ、SalesRankでの結果はいつのランキングかわからないデータを元にしているらしい。
　返される結果の順序が正しいのか、一つ一つの書籍が持っているSalesRankが正しいのか判断できないが、画面に表示される順位(とも必ずしも整合しないのだが)をベースにしたいと考えて、30位までのデータを取得後、各書籍のSalesRankを元にソートする事にした。これはこれで解決した事にしよう。

　複数のキーワードで検索した場合に同じ書籍が登場する事があり、それは当たり前の事なので構わないのだが、同じ書籍なのに違うSalesRankが得られる事があった。データベースの更新時間帯だったのだろうか。この場合は、順位が上のものを優先する事にして解決。この方法だと、違う書籍でも同じ順位になる可能性があるが、そこまで厳密である必要はどこにもないので構わないだろう。

　次に大きく悩んだのは「レビュー」の扱い。ResponseGroupにReviewsをつけたり、MediumをLargeに変えると結果が返ってこない…事がある。
　検索キーワードによって結果が返ってきたり来なかったりで、このままだと正しい結果を得ることができない。例えばItemSearchでキーワードを[YMO]、mediaを[DVD]、ResponseGroupを[Reviews]にすると、結果が返ってこない。（このキーワードは一例で今回の仕事とは関係無い）
　Google先生に聞いてみたところ、レビューのテキストの中に本来使用できない文字コードが混じってしまっていてエラーが発生しているらしい。発生した場合は、ECSフォーラムにASIN番号を書き込む事により修正してもらえるとの事で、より一般的な解決策も検討中との事。また、XSLTで結果を処理している場合にも弊害が生じるらしい。とりあえずパース中にエラーとなっているようだ。…Googleでは以上の事がわかった。

　フォーラムで報告するのはやぶさかではないが、仕事なので未知のものにも対応しなければいけない。レビューが取得できないと、「おすすめ度」や「レビューした人数」を得ることができないぞ。う～ん、困った。

　私がやってみた事

1. ItemSearchでItemIdsだけ取得し、ASINを元にItemLookupでデータを一つ一つ取得しなおす。
　　結果:　失敗
　　Reviewsで取得し損ねると10個のデータを失うが、この方法だと
　　レビューが取得できないアイテムだけ失うことになり被害は最
　　小限に留められる。しかし、データが揃わない事に代わりは無
　　いので意味が無い。

2. ECS4.0に問題があるのではないかと考えてECS3.0で組みなおす。
　　結果:　失敗
　　Largeに相当するheavyを指定するとやはり結果が返ってこない。

3. nusoap.phpをPEAR:SOAPに変えてみる。
　　結果:　失敗
　　ECS4.0 だと何故かparse errorが発生。PEAR:SOAPの方にバグ
　　レポートもあがっているようだが、如何ともしがたい。
　　ECS3.0 だとレビューが入っているデータは取得できない。

4. ECS4.0での取得をSOAPからRESTにしてみる。
　　結果:　失敗？
　　socketで接続してGETでパラメータを送信するとXMLな結果が
　　返ってきた。レビューも取得できてる。しかし、XMLparser
　　を通した時点でエラー発生。
　　必要な部分だけ自前で切り出せばOKそうだが、データが沢山
　　あるのでめんどくさそう。

　なかなかうまくいかず時間を無駄にしたが、4.のあとでふと思いついた。

　「取得したXMLデータの中からエラーの原因となるレビューの中身だけ削除しちゃえ！そうするとParserがちゃんと処理してくれるんでは！？」

　「いやいや、いっその事 nusoap.php でその処理をしちゃえば普通にSOAPで扱えるのでは？」

　という事で、1行追加して<Content></Content>間のデータを削除するようにしたところ、最初にやろうとした方法で必要なデータが得られることができるようになりました。今回はレビューの内容を使わないからいいんですけど、必要な時はどう処理すればいいんでしょうかね？その時は、また改めて考える事にします。

　というわけで無事に処理できるようになりましたが、とても疲れました。レビューからイケナイ文字が早くなくなることを祈ってます。または、あってもエラーにならない抜本的な対策の早期導入を望みます。

　ま、なんにしろ結論を言えば私がヘボイということですけどね。

　追記(2005/2/13)
　[Amazon Web サービスがレビューの文字化けに対応]のエントリーで書きましたが、不正な文字が混ざると正しい結果が得られない不具合は、[2005-01-19バージョン]で修正され、nusoapを改造したり悩んだりすることなく正しいデータが得られるようになりました。お試しあれ。