2007年10月アーカイブ

1年ぐらいスパムフィルターとしてBeckyのプラグインとして提供されている深海魚フィルタ(シーラカンスソフト)というものを使っていたのですが、ここ最近バージョンアップの頻度が多くて安定していないのかなという印象があったり、自分の環境では動作時にCPUが100%までいってしまいマシンの動作が重くなってしまったり、精度的にも悪くはないけど良くもないという感じだったため、他のスパムフィルターの導入を検討することにしました。

検討する際のポイントとして以下の5点を考慮しました。

1. Windowsで動作する
2. Beckyで使うことができる
3. スパム判定精度がある程度高い
4. 導入が楽
5. メンテナンスが楽

で、いろいろと探した結果SpamAssassinのWindows PortであるSAwin32が一番しっくりきたため、それを使うことにしました。
SAwin32にはSAProxyというアプリが含まれていて(というか、それしか含まれていない)、SAProxyはPOP3のプロキシとなりスパムをフィルタリングをしてくれるソフトになります。他の同様のソフトとしてはPOPFileなどがありますね。

以下、インストール方法になります。

1. http://sawin32.sourceforge.net/よりSAwin32をダウンロード

Download SAwin32ってところからダウンロードしてください。

2. SAwin32をインストール

ダウンロードしたexeファイルを起動してインストールしてください。インストール時にいつも使うPOP3サーバを聞かれますので、今メーラーに設定されているPOP3サーバを入力してください。この設定はあとで変えられます。

3. スパムを勉強させるために、sa-learnとsa-updateをダウンロード

先程のページの右側のリンクからsa-learnとsa-updateをダウンロードしてください。

4. sa-learnとsa-updateのアーカイブを解凍する

これらはインストール作業はないので、単純に解凍して適当なディレクトリに置いておけばよいようです。

5. どこからかスパムのデータを持ってきて、sa-learnを使ってSpamAssassinにスパムを学習させる

なにはさておきSpamAssassinにスパムを覚え込ませる必要があります。そこで最初にsa-learnを使ってSpamAssassinにスパムを学習させます。
まずは、DOSプロンプトを開いてsa-learnを解凍して出来たディレクトリに移動しください。そこでどこかからもってきたスパムデータをspam.txtという名前でカレントディレクトリに保存して以下のコマンドを打つことでSpamAssassinがスパムを学習します。


% sa-learn.exe --spam spam.txt


もし、どこかからもってきたスパムのデータがmbox形式であれば、 以下のように--mboxを指定することでmbox形式のスパムも勉強できます。


% sa-learn.exe --spam --mbox spam.txt

6. sa-updateで設定ファイルを更新

sa-updateは、SpamAssassinの設定ファイルを更新するコマンドです。これは定期的に更新をするもののようですので、適当なときに以下のように実行しておけばよいでしょう。--nogpgはgpgをインストールしてない環境用のオプションです。


% sa-update.exe --nogpg

7. SpamAssassinの日本語に特化した設定ファイルをダウンロード

TLECの方が用意したuser_prefsファイルをhttp://tlec.linux.or.jp/docs/user_prefsからダウンロードしてください。ここには日本語のスパムのためのフィルタ条件が含まれています。これを用いることでかなりのスパムをフィルタリングすることができるようです。
ダウンロードしたものを C:\Documents and Settings\ユーザ名\.spamassassin に置きましょう。

8. SAwin32のSAProxyを立ち上げる

やっとここで、最初にインストールしたSAProxyを立ち上げます。単純にプログラムメニューから起動するだけでよいです。

9. メーラーを設定する

SAProxyのインストール時にちゃんとPOP3サーバを設定できていれば、メーラーのPOP3サーバの部分をlocalhostに変更するだけでオッケイです。

10. あとはメールを受信するだけ

メーラーで受信をしてみてください。スパムがはじかれていれば成功です。

かなり駆け足で説明したのでどこかで抜けがあるかもしれませんが、概ねこんな感じでインストールできると思います。

あと、スパム情報のメンテナンスですが深海魚フィルタより若干面倒です。
流れとしては、(Beckyの場合)スパムを集めておいてそれをファイルにエクスポートし、それを上記でやったようにsa-learn.exeで勉強させるという感じになります。

で、一番気になるスパム判定の精度ですが、今のところなかなかいい精度ではないか思います。
深海魚よりはスパムをハムと間違える率は少なくなっているし、ハムをスパムと間違える率も少なくなっているようです。

ということで、しばらくはこれを使ってみたいと思います。

・Catalystで携帯端末ID取得
・Catalyst::Plugin::MobileUserIDがそのままでは動かなかった

この辺で言われている件を修正しました。
修正内容は千葉さんのブログにある通り$c->req->user_agentを$c->req->headersにしただけです。

CPANでインデックスが更新されるまで待てない方は↓こちらからどうぞ。
http://svn.clouder.jp/repos/public/Catalyst-Plugin-MobileAgent/trunk/

「Module::Installを使ったプロジェクトのincディレクトリについて」の続きです。

ブクマコメントを見ると、「入れてない」or「入れないで欲しい」って意見がほとんどでした。miyagawaさんは入れてないということですし、charsbarさんがコメントしてるPlaggerとCatalystのリポジトリを見ると、たしかにincディレクトリがありませんでした。

あとCatalystのリポジトリでは、incがないだけでなくMANIFESTもリポジトリに入れてないようです。たぶんリリースするときに make manifest && make dist してパッケージングしてるんだと思います。

ということで、今後subversionでプロジェクトを管理するときには、

• リポジトリにincは入れない。
• リリースするときには make manifest && make dist でパッケージング

ってやることにします。これからは「inc含めない派」だぜ。

ちなみに、この一件でMANIFEST.SKIPがないのにmake manifestしたら、ちゃんと.svnやその他のいらないファイルがMANIFESTから除外されるのは、ExtUtils::ManifestにMANIFEST.SKIPが含まれていてExtUtils::Manifestと一緒にインストールされているからだということを初めて知りました。(see perldoc -ml ExtUtils::MANIFEST.SKIP)

Module::Installを使ったCPANモジュールはincというディレクトリがあって、その中にinc::Module::Installなどのファイルが同梱されています。なぜ、inc::Module::Installなどが含まれているかというと、これによってModule::Installがインストールされていないマシンでも、そのモジュールをインストールできるという利点があります。

Module::Installを使ったモジュールのプロジェクトを作るのは意外と簡単で、module-starterなどでプロジェクトの雛形を作り、以下のような感じでMakefile.PLをModule::Install用に書き換えてやるだけでいいのです(module-starterはテンプレート機能があるので、$HOME/.module-starter/の設定で最初からMakefile.PLをModule::Install用で出力することも可能)。

use strict;
use warnings;
use inc::Module::Install;

name     'Sample::Module';
author   'Foo Bar <foo@example.com>';
all_from 'lib/Sample/Module.pm';

auto_install;
WriteAll;

Makefile.PLをModule::Install用に書き換えたら、いつもCPANモジュールをインストールするときと同じようにperl Makefile.PLを実行すると、Makefileや前述のincディレクトリなどのインストールに必要なファイルが生成されるというわけです。


で、ここからが本題です。

他の人と同様に自分もモジュールを作る際にソースをsubversionで管理しているのですが、管理しているモジュールのリポジトリにincディレクトリがコミットしてあると、そのモジュールのデバッグ時にperl Makefile.PLとやることで毎回incディレクトリが再生成され、incディレクトリ内のsubversion用の.svnディレクトリが消されてしまいます。

当然この状態でsvn updateやsvn commitをすると、

% svn up
svn: Directory 'inc/.svn' containing working copy admin area is missing

とか

% svn commit
svn: Commit failed (details follow):
svn: Directory '/path/to/inc/.svn' containing working copy admin area is missing

とおこられちゃいます。

なぜincディレクトリがperl Makefile.PLするごとに再生成されてしまうのかというと、incディレクトリに「.author」という空のディレクトリがあり、これがあることによってModule::Installがauthor mode(作成者モード)で動くため、毎回Makefile.PLの中身を判別して必要なModule::Installのモジュールをincディレクトリにコピーするためです(その辺はinc::Module::Installのperlpodに書いてあります)。

author mode でincディレクトリを再生成してくれるのはとてもありがたいのですが、「デバッグ→コミット→デバッグ→コミット」とスムーズな開発がしたいのに、毎回.svnが消されることにより「デバッグ→incディレクトリを消す→svn updateでincディレクトリを最新にする→コミット→デバッグ→incディレクトリを消す→svn updateでincディレクトリを最新にする→コミット」と、とてもめんどくさいことになってしまいます…。


ということで長々と書いてしまいましたが、モジュールのプロジェクトをsubversionで管理するときに、incディレクトリ内の.authorディレクトリまで管理した方がよいのか、それとも.authorディレクトリはsubversionで管理せずに必要な時に適宜自分で.authorディレクトリを生成してincディレクトリを再生成させた方がよいのか、どちらがいいのでしょうか。


このエントリを見ている人で、こうしてますっていう人がいたら是非教えてほしいです。

CodeReposとかみると、あんまりModule::Installを使ってる人がいないので、あんまりModule::Installって使われてないのかな？
→追記：http://unknownplace.org/memo/2007/10/12#e001 いくつかのモジュールを見て判断してしまいましたが、Module::Install使ってる人は結構いるようですね。失礼しました。

amachangさんの「一行で IE の JavaScript を高速化する方法」を見てて、見慣れない/*@cc_on なんちゃらなんちゃら @*/ って記述が気になった。

なんだろうとおもい、早速ぐぐってみたところ、ここに書いてありました。

@cc_onはステートメントというものらしく「条件付きコンパイルの機能をアクティブにします。」との説明があります。

でも、「条件付きコンパイル」ってなんだよ！そんなの知らないぜ！
ということで調べてみたら、以下のようなことが書いてありました。

条件付きコンパイルを使用すると、JScript の新しい言語機能を利用しながら、その新機能をサポートしていない以前のバージョンとの互換性も保持できます。JScript の新機能を使用する場合、スクリプトにデバッグサポートを埋め込む場合、コード実行をトレースする場合などは、条件付きコンパイルを使用するのが一般的です。

なるほど。ようは、条件付きコンパイルに対応していないブラウザには影響せずに、JScriptの新しい機能を使えちゃうぜ、ということらしいです。

ということでためしに以下のようなHTMLを書いて動作確認してみた。

<html>
<body>
<script type="text/javascript">
/*@cc_on document.write("Hello, JScript!"); @*/
</script>
</body>
</html>

このHTMLを各ブラウザで確認してみたところ、Internet Explorerで開くと「Hello, JScript!」とみごとに表示され、FirefoxやOperaだと表示されませんでした。

ちなみに「/*@cc_on」の /* と @ の間にスペース空けたり、@ と cc_on の間にスペースを空けても動きませんでした。ようは「/*@cc_on」のどこにもスペースは空けるなということですね。

この条件付きコンパイルは、こういう用途以外にもいろんな機能が使えるみたいですので、興味のある方はこちらの条件付きコンパイルの説明のページをご覧になってみてください。


ってここまで書いたけど、@cc_on ってもしや常識！？

こないだ書いた「ustreamの録画した動画のflvをダウンロードする方法」ですが、突如#plagger-jaで、これをシステマチックに取得できないのかという話題になって、typesterさんとかYappoさんとかmiyagawaさんがあれこれやって数時間でPlaggerでできるようになってしまいました。

はやい、はやすぎるよ！

「Ｗｉｉリモコンジャケット」についてのお知らせ

　謹啓　平素は弊社商品をご愛顧いただき、誠にありがとうございます。
　弊社では、お客様に、より安心して商品をご利用いただくための改良を日々研究しておりますが、この度その一環として、Ｗｉｉリモコン用保護カバー「Ｗｉｉリモコンジャケット」を開発し、無償で提供することといたしましたのでお知らせいたします。

申し込ませて頂きました。無償なんで！