ニコニコ動画のAPIのバグ？

参考：ニコニコ動画のAPIのメモ

↑こちらの情報を参考に、以下のニコニコ動画のAPIを試しています。

http://www.nicovideo.jp/api/getthumbinfo/[動画IDかスレッドID]

で、こちらのAPIを使用してsm4562のvideo_idの情報を取得しようとするとなぜか途中でrubyが落ちるなと思ったら、取得されるXMLデータ中に含まれる<description></description>要素の値が空になってます。

http://www.nicovideo.jp/api/getthumbinfo/sm4562

<?xml version="1.0" encoding="UTF-8"?>
<nicovideo_thumb_response status="ok">
<thumb>
<video_id>sm4562</video_id>
<title>金は返さないんじゃないよ！一生借りてるだけだよ！</title>
<description />
…省略

で、実際の動画の視聴ページを見てみるとちゃんと投稿者のコメントはあります。

またまたアスキーアート…。

ということは、ニコニコ動画の動画管理DBにはきちんと情報は保存されているけど、APIのプログラムがきちんとデータを返せていないと思うんですよね。

IE7でもFirefox3.0.5でも同じ結果になるので、自分が作成しているプログラムのせいではなさそう。

ということで、是非とも修正をお願いします。　＞　ニコニコ動画の中の人

ニコニコ動画との死闘？ いや巡礼中です

最近、ニコニコ動画の検索機能が絶望的にダウンしまくりです。

土日平日、昼夜を問わず、とにかく検索機能が使えないです。

視聴ページ（http://www.nicovideo.jp/watch/*）までたどり着ければ、そこそこ快適に動画が再生されるんですけど、ニコニコ動画ってYouTubeと違って動画サーバが超分散化されていないようなんですよね。

YouTubeなら同じ動画でも動画データのURLが毎回変わるのに対して、ニコニコ動画だとほぼ固定っぽい。

かたや１兆円企業のGoogleとニワンゴを比較するのはかわいそうな気もしますけど、通信回線の帯域の問題に加えて、検索用のサーバが非力すぎるのか、それとも、うまく分散処理ができていないのか、はたまた、使用しているDBMSのソフトウェアの限界なのでしょうか？

GoogleではBigTableというすごい分散ストレージシステムを使っているらしく、YouTubeでも使っているとのこと。

ニコニコ動画のhttp://www.nicovideo.jp/watch/sm*だけでも、通番で600万に届こうという勢いですから、大変ですよね。単純に600万レコードって凄くないですか？（企業のDBだと600万レコードぐらい普通なんでしょうか？）

で、個人でなんとかできないかと思い立って、ニコニコ動画の動画データベースを自力で作り始めたんですけど、しょっぱらからやられました。

以下の動画では、詳細情報で、シングルクオート（'）が使われていて、SQLのINSERT文にそのまま突っ込んだらMySQLにいきなりエラーで怒られてしまいました。で、どんなコメントなんだろうと思って見てみたら、なんと、クマーでした・・・。orz

よりによって、クマー、ですか、違いますか、そうですか・・・。

さすがは２ちゃんねる文化のニコニコ動画です。恐るべし！(^^;

■クマとの死闘

http://www.nicovideo.jp/watch/sm14

 

INSERTするときは、必ず、quote処理しましょう！という良い教訓になりました（ていうかいきなり洗礼を受けました）。SQLインジェクション問題とかもあるし、セキュリティのことを考えても非常に重要ですよね。

ちなみに、sm*の数字が若い番号の動画を見に行くことを”巡礼中”というのだそうです。

SeeSaaのサーバの調子が悪い

SeeSaaのブログの管理画面でブログを再構築しようとするとエラーが出てしまいます。Webブラウザのキャッシュをクリアしてみたのですが、症状が改善されません。

2007/12/26（水）、昨日、サーバー機器増設に伴うサービス一時停止があったようですが、これが原因でしょうか？最近、SeeSaaのサーバの調子が悪いような気がします。

ぷららの「迷惑メール振り分けサービス」

ぷららでもようやく「迷惑メール振り分けサービス」が会員向けに標準・無料で提供されることになりました。2008年1月31日からだそうです。

ぷららのメールサーバは動作が多少、怪しいところがあるので、このスパムフィルタもあまり期待はしていないのですが、ないよりはマシかなという気もします。スパムフィルタのためだけにgmailにすべて転送したりすると、Googleに個人情報を知られてしまうことになるのでそれは避けたいですし。

ちなみに、振り分けられたスパムメールは「ぷららの迷惑メール専用フォルダに格納」されるそうですが、このフォルダにはどうやってアクセスするんですかね。Webで確認するのは正直めんどいです。imapとかで確認できると良いのですがぷららってimapサポートしてないような。

2chスレ「ブラック会社に勤めてるんだが…」を読んで

2chスレ「ブラック会社に勤めてるんだが…」の世界に、一気に引き込まれてしまいました。

最初、読んだ時、これフィクションなんじゃないか？と疑いました。仮に事実だったとして、脚色されている部分もたぶんにあるだろうし、そもそも作り話という線も拭えない。でも、自分の経験に照らし合わせてみると、恐らく経験者じゃないと書けない内容なんじゃないかと。

話の結末は、自分が期待していたものとはだいぶ違っていましたが、読み物としては面白かったのではないかと思います。

ニコニコ動画で炎上中らしい

これまでニコニコ動画で遭遇したことのない「回線が混雑しています」のメッセージが表示される。また、システムエラーなのかと思ったら、某大手掲示板でよくある「祭り」状態になってたんですね。

動画で某大手掲示板と同じ「祭り」が起きるとは。。。

POPFileでスパムメールを「隔離」する

POPFileの学習が進んでくると、かなり高い精度でスパムメールを振り分けることができるようになります。スパムメールがいい感じで振り分けできるようになってきたら、思い切ってスパムメールを「隔離」してしまうことを検討してみる価値はあると思います。

POPFileは、通常、タイトルにバケツ名の追加とメールヘッダーにヘッダーの追加を行います。しかし、HTMLメールはそのままメーラーに渡されるためスパムメールの場合は危険な場合があります。（ウィルスが仕込まれているかもしれませんしね）

そこで、隔離機能をONにします。すると、POPFileはオリジナルのメールを添付ファイルの形にして、オリジナルのメールの最初の20語を本文にして、メーラーにメールを渡してくれるようになります。

具体的にはバケツの設定画面で、隔離のチェックを入れるだけです。 

POPFileが賢いとはいえ、振り分けをミスることもあるので、スパムとして振り分けられれたメールを何も確認せずに削除してしまうのにはちょっと抵抗感じますが、これで安心してスパムメールかどうかチェックできるようになります。

POPFileでの分割メールの対処方法

POPFileの落とし穴　→　分割メール

以前、巨大な分割メールがくるとPOPFileがハングアップしてしまうと書きましたが、どうやら、Becky!側にも問題があったようです。

POPFile自身は一生懸命処理しているのですが時間がかかるため、Becky!側でタイムアウトしてしまうようです。

そこで、POPFile Control Plugin（BkPOPFile）の「HTTP TimeOut」の値を十分余裕のある値に増やしてやれば、「POPFileの判定を訂正」する際にタイムアウトしなくなります。

根本的な解決にはなっていませんが、とりあえずは対処できるようになります。

POPFileをすり抜けるメールが出現！

最近、POPFileではSPAMと認識しているのにBecky!で正常に振り分けられないメールが2通届きました。

そこで、その怪しいSPAMメールのメールヘッダを見てみると以下のようになっています。

Return-Path: <[e-mail]>
Received: from m21.mailyes.net ([125.187.32.216])
 by xxxxx.xxxxx.or.jp
 with ESMTP id <[e-mail]> for <[e-mail]>;
 Sun, 6 Aug 2006 15:36:24 +0900
Received: (qmail 17301 invoked
 by uid 0);
 6 Aug 2006 15:28:23 +0900
Message-Id: <[e-mail]>
To: xxxxxxx <[e-mail]>
Subject: 現金３万円プレゼント！!
From: koike keiko <[e-mail]>
Reply-to: delivery_rt <[e-mail]>
Date: 2006-08-06 15:25:11 X-Text-Classification: spam
X-POPFile-Link: http://localhost:8080/jump_to_message?view=1314

Content-type: text/plain; charset= ISO-2022-JP
X-Mailer: NEXTism Mailer 1.0
X-Priority: 1
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Keywords: 20060805204311_cbao
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

モニタースタッフ募集!!　ＡＳ企画
登録料・情報料一切無料

 

恐らく問題になっているのは、上の赤字の部分ですね。

察するに、POPFileがメールヘッダの解析方法に問題があるのか、それとも、X-Text-Classification:ヘッダの挿入方法に問題があるのかなどなど、 理由はいくつか考えられます。

オリジナルのメールを見ると、Date:ヘッダと、 Content-type:ヘッダの間に空行が入っているのでこれが原因、つまり、SPAMメール側の問題なのかもしれません。

SPAM業者が、POPFileをすり抜けるように故意に不正なヘッダ構造にしているか、 はたまたSPAM業者がたまたまアホなのか、よくわかりませんが、上のようなメールヘッダだと、X-Text-Classification:ヘッダを頼りにBecky!が振り分け処理を正常に行うことができないようです。

また、上のようなメールヘッダをもったメールをBkPOPFileCon （POPFileの判定を簡単に訂正する為のBecky! Plug-in） を使ってPOPFileの判定を訂正させようとするとエラーになります。

 

苦肉の策として、すべてのメールヘッダに「X-Text-Classification: spam」 という文字列が含まれていたら、SPAMフォルダに振り分けるようにも設定しました。これで、 Becky!が自動的にSPAMフォルダに振り分けてくれるようになります。

 

これで、SPAMフォルダに無事に振り分けられるようになるのですが、依然としてBkPOPFileConではPOPFileの判定を訂正することができません。

そこで、Becky!でメールヘッダを表示されるモードにして、「X-POPFile-Link: http://localhost:8080/jump_to_message?view=1314」 をダブルクリックするとWebブラウザが起動するので、Webブラウザ経由で判定を手動で訂正するようにします。

こういう変なメールがそんなにはこないので今のところ大きな問題にはなっていませんが、 POPFile側で対応してもらえると非常に嬉しいのですが。。。(^^;（他力本願モード）

 

 

Windows Live Messengerの共有フォルダ機能を使うとPCが落ちるが確信に近づいた。。。

今日、オフィスのマシンでWindows Live Messengerの共有フォルダを試してみたところ、やはりPCが落ちました。 ブルーバックに落ちるどころか、強制リセットがかかりました。

やはり、同期元のPCが落ちるようです。

う〜ん、使えない。もしまともに使えるようになったらとてつもなく便利な機能なのに実に惜しい。

しかも、エラーログを残す余裕もなく落ちるものだから、マイクロソフトにエラーリポートもできない。

エラーリポートを送ろうとすると、エラーログが壊れているらしく、エラーレポートを送信しようとするとまたPCが落ちる。

う〜ん、なんともしがたい。。。

 

Windows Live ダメダメ。。。

ThinkPad T42にWindows Live Messengerをインストールして共有フォルダ機能を使おうとするとブルーバックスクリーンになるとご報告しましたが、 ThinkPad X31では比較的安定しているようです。（まだまだ油断はできませんが）

そこで、hotmailのアカウントを新しく作成して、共有フォルダ機能を試そうと思ったところ、 passportでログインできないんです。何度試してもだめ。

エラーコード80048821が出るんです。

 一瞬、「passportに技術的な問題が発生している」とエラーメッセージが出たのですが、 MSNの方からサービスの状況を調べてみると、正常に動作しているとのこと。

おかしい。

既存のMSNやhotmail、Messengerサービスと、新しいWindows Liveのシステムでうまく連携できていないんじゃないかと非常に疑わしいです。

→　すいません。ドメイン名が間違ってました。昔、 メールアドレスを取得した時は、@hotmail.comなのに、今、 メールアドレスを取得しようとすると@hotmail.co.jpなんですね。思い込みのせいですっかりはまりました。。。 (^^;

統合認証のpassportが死んでしまうと、MSのネットワーク系のサービスがほとんど利用できなくなるので非常に困ります。

お陰で、余分にアカウントを作っちゃいましたよ。なんか活用方法を考えないと。。。

一体、いつになったら、Windows Liveってまともに安定するんでしょうか。

P.S

そうそう、やっぱり、Windows Live Messengerを入れて、 共有フォルダ機能を使ってデータの同期が始まると確実にブルーバックスクリーンに落ちますね。同期元（T42）→同期先（X31） だとすると、同期元のマシンのT42が落ちるようです。

T42固有の問題ですかね。共有フォルダ機能さえ使わなければ、T42でもWindows Live Messengerは正常に動作するんですが。。。

 

 

IPアドレスが使われている地域がわかってしまうという恐ろしいサービス 「IPひろば」

ネタフルさんより、「IPひろば」という記事を発見。

IPアドレスを打ち込むと、なんとそのIPアドレスが使われている地域がわかってしまうという恐ろしいサービス。

県単位くらいで表示されるみたいです。

ISPなどでは、地域ごとに細かくサブドメインを切っているようなので、それでわかってしまうんでしょうか？

某巨大掲示板などで威力を発揮するかもしれませんね。書き込んだ途端、県名が表示されたらちょっとびっくりかも。

ちなみに「www.itmedia.co.jp」 を調べてみたところ、地域は表示されませんでした。

そうは言っても結構使えないかも。まぁ、そんなもんですかね。

 

 

POPFileの落とし穴 → 分割メール

巨大なデータが添付されたメールは分割メールで送信されてくることがあり、 それらのメールはPOPFileでうまく取り扱えないことがあるようです。

分割メールは、アルファベットと数字の羅列からなるテキストでエンコードされていますが、あまりにも膨大なデータとなるため、 POPFileが処理仕切れずハングアップしてしまうようです。

また、分割メールを結合する前は、「X-Text-Classification」ヘッダがついているため、 適切に振り分けることができるのですが、分割後は「X-Text-Classification」ヘッダが失われるため、 POPFileの分類情報に基づいて振り分けることが出来なくなってしまうようです。

困りました。巨大な分割メールの振り分けはあきらめるしかないようです。

POPFileが分割メールを認識して、処理方法を変えてくれるといいんですが。。。

 

Skypeで利用できるコードレス電話機

パイオニアから販売される、TF-FS55M-Sという、Skypeで利用できるコードレス電話機なのですが、 なにげにこれは良さそうです。

今時、電話といえばコードレスは当たり前。理想は、今使っている携帯電話（例えばFOMAとか） をSkypeの電話機として使えれば最高なんですが、とりあえずはこれでなんとかなりそうです。PCとはUSBで接続して、 アナログ回線もつなげるので普通の電話機としても使えるんですよね。

 

GmailでPOPFileを使う！

自宅ではPOPFileは絶好調で機能してくれていて、分類精度は74.96%です。

職場では、非常に多岐に渡るメールがやりとりされているため、そう簡単には行かないようです。結構、振り分けを間違います。 試行錯誤しながらバケツを追加していったため、変に学習してしまっているのかもしれません。分類精度は50%弱程度で、 振り分け直す度に分類精度が下がっていくような段階ですが、辛抱強く学習させていくしかないようです。

ということで、どのようにバケツを作るかといったバケツの設計というか戦略は、最初が肝心なようです。

 

さて、POPFileの効果に気をよくしたのでGmailでもPOPFileを使えるようにしてみました。 Gmailのスパムフィルタはとても優秀らしいですが、 メールの趣旨に応じて効率的に自動的に振り分けてみたかったというのが最大の動機です。

 

（１）POPFileに”SSL Support”モジュールを組み込む

Gmailは、POP3S（POP3 over SSL）を使うので、POPFileのオプション・モジュールのSSL Supportを組み込んでやる必要があります。

（↓とあったので、初回インストール時に組み込まなかったんですね。(^^;）

POPFile のモジュール

モジュールは、POPFile に POP メールを処理する以外の機能を追加するためのアドオンです。 多くのユーザはそれらのモジュールを必要としていないため、ほとんどのモジュールは（使用する前に）有効にする必要があります。

すでにPOPFileをインストールしてある場合は、”アップグレード”を選択すればモジュールを簡単に追加できます。

POPFileのアーカイブに含まれているsetup.exeを実行して、”アップグレード”のボタンを選択します。

そして、”SSL Support”のチェックボックスをチェックします。

 

あとは、実行が終了するまで、”次へ”や”アップグレード”のボタンを押していけばいいだけです。

 

（２）Becky!の設定を変更する

↓の情報を参考に設定します。

Gmailのメールをpopfileに通す方法

・メーラーからアクセスするメールサーバのポート番号を 995 → 110 に変更(POP over SSLを外す)

・メーラーからアクセスするメールサーバを"127.0.0.1"に変更

・ サーバにアクセスするメールアカウントを"pop.gmail.com:995:yourmailadress:ssl"に変更

 

めでたく設定完了です。

POPFileに”SSL Support”のモジュールが組み込まれていないと、 POPFileがハングアップしてしまうようなので、その時はPOPFileをシャットダウンして、 モジュールを組み込んでから再度試します。私ははまりました。

 

DS Lite クリスタルホワイト、遭遇。。。

今日は、朝から打ち合わせをしていたのですが、突然、携帯にメールが着信。

日時：2006/5/24 AM10:19:13

件名：アマゾン・アラートからのお知らせ

内容：「ニンテンドーDS Lite クリスタルホワイト」が24時間以内に出荷になりました。

 

アマゾンでは、月曜がだめなら、火曜日にDS Liteが入荷することがあると噂では聞いていましたが、 本当らしいですね。

でも、打ち合わせ中だったので泣く泣くスルーせざるを得ませんでした。

ま、競争が激しいらしく、瞬殺されるらしいので結局買えなかったかもしれませんが。

実に悔しい。。。

次回に望みを託すだけです。。。

アマゾン・アラート導入

まいたうん：「チーフ、DS Lite クリスタルホワイトって現代科学が生み出した”プレシャス”の１つですよね。」

レッド：「あぁ、そうだな。どうやら人気絶頂で全然手に入らないらしいな。」

まいたうん：「アマゾン・アラートというソフトを使って、DS Lite クリスタルホワイトをアマゾンで自動的に監視してみようと思うんです。」

レッド：「ちょっとしたボウケンだなぁ〜。よし、プレシャスだ。ボウケンジャー、ミッションスタート。アタック！」

 

ちゅうことで、アマゾン・ アラートという、アマゾンの人気商品が注文可能になると教えてくれる監視ソフトなるものを導入してみました。

狙いはズバリ、DS Lite クリスタルホワイトです。

お店に並んで買うのもしゃくだし、ここは文明の利器を最大限活用してなんとかDS Lite クリスタルホワイトをゲットしようというミッション開始です。

注文可能になると、携帯のメールにお知らせするように設定もしました。

が、全然、買えるようになりませんね。月曜がだめなら、火曜日。火曜日がだめならまた次の日に。

とにかく監視しまくります。

 

ぷららのWinny規制は「違法」と総務省

ぷららのWinny規制は「違法」と総務省

総務省は、ぷららがトラフィックを解析し、特定の通信を完全に遮断する行為が、通信の秘密の侵害にあたると判断。 「安定したサービスを提供するためのトラフィック制限は他事業者もやっており、『正当な業務』として許容範囲だが、 特定のアプリケーションによる通信の完全規制は、手段として適当でない」（総務省）としている。

 

別段、WinnyなどP2Pユーザを擁護するわけじゃないですが、プロバイダが通信の中身を監視し続けた上に、 問答無用で規制してしまうのはいかがなものかと思います。

例えば、極端な例で言うと、広義の意味ではSkypeなどVoIP系のアプリはP2Pなわけで、 通話の中身を傍受されているかもしれないと考えるとあまり気持ちの良いモノではありません。

通常の通信に影響が出るくらい通信帯域を圧迫するようになってくるとさすがにそれは問題だと思うので、 トラフィックの制御はして欲しいと思いますけどいろいろ難しいです。

 

POPFileを実践投入 ＜仕事活用＞

POPFileの使い方のコツがだんだんわかってきたので、ついに仕事のメールにPOPFileを実践投入してみました。

○はまったこと１）　POPFileを導入した途端、メールの送信で失敗する！

オフィスのネットワークはイントラネットになっているため、さすがにセキュリティが高いのでいきなりつまづいてしまいました。 うちのオフィスに運用されているSMTPサーバーは、SMTP認証が必要なのです。

 

POPFileは、POP3のプロキシーサーバー的な働きをするため、SMTP認証が失敗してしまうことが原因でした。

つまり、受信する際のユーザーIDとSMTP認証する際のユーザーIDが異なるため、SMTP認証に失敗してしまうからです。

POP3のユーザーID：「POP3サーバー名」＋「:（POPFileのデフォルトではコロン）」＋「本来のユーザーID」

SMTP認証のユーザーID：「本来のユーザーID」

これでは、「POP3のユーザーID」≠「SMTP認証のユーザーID」となってしまうため、SMTP認証に失敗するわけです。

POPFile をインストール、設定したらメールの送信ができなくなってしまったのですが？

Becky!では、受信時と送信時のユーザーIDを個別に設定できるので、SMTP認証時のユーザーIDを  「本来のユーザーID」に設定してやれば、きちんとメールが送信できるようになりました。めでたしめでたし。

 

○はまったこと２）　「unclassified」も意識して振り分けてやる。

「unclassified」という、 POPFileがデフォルトで用意している仮想的なバケツに対応するBecky!上のフォルダも用意しておいて、 自動的に振り分けるようにしました。振り分けに失敗していることを明示的にはっきり認識できるようにするためです。 振り分けに失敗したら豆に再振り分けをしてあげます。

POPFileは、再振り分けという指導をしてあげないと、全然学習しません。つまり、 明示的に再振り分けをしてやらないと一切学習しないため、一向に賢くならないんですね。

 

つまり、「unclassified」 に分類されたメールは学習効果を高めるためには放置しておいてはいけないわけです。

 

また、仕事内容に応じてカテゴリー別にバケツを作ってやり、豆に再振り分けの学習をしてやります。 職場のメール量は半端じゃなく多いので、学習するのに必要なメール数５００なんてあっという間にクリアできました。

 

まだ、導入して一日しか経ってませんが、今後、どれくらい効果が出てくるかとても楽しみです。

導入一日目でも、退社する頃には目に見えて学習効果が実感できるようになってきたので、POPFileってほんとすごいですね。

 

 

 

POPFileがなかなか賢くならない。。。

POPFileを導入したのは5/13（土）です。今日で3日目。

いっこうにきちんと振り分けしてくれる様子はありません。

で、どれくらい学習すれば、POPFileがきちんと動いてくれるようになるのか気になって調べてみました。

すると、↓のような記述がありました。

POPFileが適正な精度に達するにはどれぐらいかかりますか？

必要な期間は受信するメールの数によります。

ほとんどの場合、 1000 くらいのメッセージを受信すると非常によい精度（ 97% 以上）が得られると報告されています。 包括的な統計情報（下のリンクを参照）によれば、 500 メッセージ以上のメールを受信した場合の精度の平均は 96% であり、 その時点で 85% 以上のユーザは 95% 以上の精度を得ています。

このことは、この状態になるまでに 1000 回もの再分類をしなくてはいけないということではありません。 1000 通のうちのほとんどは正しいバケツに分類されるでしょう。しかし、 コーパスが新しいうちは多くの間違いが起こるということを知っておくべきです。

この3日で受信したメールが303通だったので、まだまだ全然足りないという感じでしょうか。 最低でも500通は学習してやらないといけないんですね。一日100通として、最低でもあと2日くらいは効果が現れないってことですかね。

逆に言うとものすごい数のスパムメールが日々届いていることになるので呆れますけどね。

 

すいません。私の不注意で、せっかくコメントを頂いたエントリーを削除してしまいました。 (^_^;

追記の方に、頂いたコメントを転写しました。　＞　amatubu様

 

 

 

続きを読む