今までスパムメールについては、Thunderbirdのスパムフィルター頼りでほかには特に対策を施してなかったのですが、最近中国語人とかさちことかさゆりとかロレックス売りとかから届くメールなど、Thnderbirdがスパムと判定してくれないことが多くなってきて、スパムかなりうざーな状態でした。
そこでSpamAssassinを試してみることにしました。
このSpamAssassin、いろいろな方法でスパムメールかどうかを判定し、スパムらしさ度を点数にし、その合計がある閾値を超えるとスパムと判定。メールのヘッダにその情報(X-Spam-Flagなど)を書き込むというようなことをしてくれます。
スパムっぽかったら問答無用で削除というようなことはしないでヘッダ(スパムメールだと本文にその点数の詳細もつきます)に情報を付加するだけなので、正当なメールがなくなるなんて事はありません。
あとはヘッダの情報からメールを振り分けるなり、ゴミ箱にうつすなりすればいいわけです。
昨日から試してますが、かなりの精度でスパムを判定してくれています。
実際の導入方法は今月号のSoftwareDesignに詳しく載っています。実はこれを読んで導入しようというきになりましたw
特集記事「オープンソース+αでキメる完全無欠のメールサーバ」の中で紹介されています。この特集記事、SpamAssassinのほかにも有益な情報が載っていてお勧めです。特にsendmail、postfix、qmailの比較は非常に参考になりました。今までなんとなくpostfixを使ってましたが、今回の記事を読んでこれからもpostfixで行こうと思えました。
2005年7月28日木曜日
2005年7月25日月曜日
黒武骨味玉チャーシュー麺@上野 麺屋武蔵武骨
麺屋武蔵の姉妹店武骨に行ってきました。注文したのは「黒武骨味玉チャーシュー麺」。黒い色はイカスミの油らしいです。このイカスミの油結構効いていて、後味に磯の香りが残ります。磯の香りが苦手な人は白の方がいいかも。
麺は極太麺で食べ応えがあります。
チャーシューは角煮に近く、一つがかなりでかいです。長時間煮込んでいるのか、チャーシューはちょっと味が濃かったです。チャーシューはもっと薄味でもいい気がしました。
次回は白にチャレンジ。
お店: 麺屋武蔵 武骨
住所: 台東区上野6-7-3
電話: 03-3834-6528
2005年7月21日木曜日
2005年7月20日水曜日
マッシュルームバーガー@7025 Franklin Avenue
先週日曜、五反田にあるハンバーガー屋さん「7025 フランクリン・アベニュー」に行ってきました。
注文したのはマッシュルームバーガーチーズのせの一番大きいサイズ。
お店に入るのに30も並んでいたので、おなかが減りすぎて一番大きいサイズを注文してしまいました。
肉はミディアムレアで中は赤い感じ。味は薄味なので肉の味を味わえました。
ちょっと値段は張りますが、また食べに行きたいと思えるくらいおいしかったです。
もう一つ気になったのが、シェイク。カウンター席に座ったので、目の前で、調理しているところを
見ることができたんですが、シェイクのおいしそうなこと。次に行ったときは注文します。
そうそう、このお店で偶然にもnaoyaさんに遭遇。
まさかこんなところで出会うとは。かなりびっくりしました。
7025 フランクリン・アベニュー
7025 Franklin Avenue
住所: 東京都品川区東五反田3-15-18
TEL: 03-3441-5028
livedoorBlogのAtomAPIが仕様変更
livedoor Blog 開発日誌:リニューアルに伴うランキングの変更、使用できる機能について - livedoor Blog(ブログ)
livedoorBlogのリニューアルに伴い、AtomAPIの仕様も変更されるようです。
>
エンドポイントが変わるだけなのかなー。
livedoorBlogのリニューアルに伴い、AtomAPIの仕様も変更されるようです。
>
Atom APIのURLがリニューアルに伴い変更となります。<
http://cms.blog.livedoor.com/atom
Atom APIを利用したペットなどのアプリケーションをご利用の場合は上記のURLに変更いただけますようお願いいたします。なお、このAPIのサービスにつきましてはlivedoor Blogとして正式にサポートしておりませんのでお問い合わせ等につきましてはご遠慮いただけますようお願いいたします。
エンドポイントが変わるだけなのかなー。
2005年7月8日金曜日
Class::DBI::Plugin::Factory
昨日書いたselectトリガを使ったClass::DBIのFactoryパターンをLost-SeasonのkatoさんがClass::DBIのプラグインにしてらっしゃいます。仕事はやっ!
ちなみに、Class::DBIのFactoryの実装方法について、インスタンス生成専門のFactoryクラスを別に作るという方法も考えたんですが、この実装方法だと、retrieve_allやsearchなどのリスト取得系の検索メソッドでインスタンスのリストを取得する際にサブクラスのインスタンスを生成ってところまでは感知できないので、やめにしました。
ちなみに、Class::DBIのFactoryの実装方法について、インスタンス生成専門のFactoryクラスを別に作るという方法も考えたんですが、この実装方法だと、retrieve_allやsearchなどのリスト取得系の検索メソッドでインスタンスのリストを取得する際にサブクラスのインスタンスを生成ってところまでは感知できないので、やめにしました。
2005年7月7日木曜日
selectトリガを使ったClass::DBIのFactoryパターン
以前からClass::DBIでFactoryパターンを使えたらなーと思ってました。
たとえば、有料、無料、VIPのように複数の会員タイプがあるような会員サイトを作る場合、Class::DBIを継承したMyService::MemberがFactoryとなり、会員のタイプによって、MyService::Member::Basic, MyService::Member::Free, MyService::Member::VIPというようなサブクラスのインスタンスを作成するというようなイメージです。
さらにFactoryクラスでMyService::Member->retrieve_allとかすると、適切なサブクラスのインスタンスのリストがとれると最高です。
そんなことができないかなーとClass::DBIのドキュメントやソースを眺めていたんですが、Class::DBIに組み込まれているselectトリガを使えば実現できそうだったので、試してみました。
selectトリガはインスタンス生成時に必ず呼ばれているので、ここで会員のタイプを判別し、サブクラスにreblessしてやります。ソースコードはこんな感じです。このコードそのままではないですが、実際に同じようなコードを書いて試してみたところ、うまく動いているようです。
***MyService::Member - Factory
>
*** MyService::Member::Basic - 一般会員
>
*** MyService::Member::Free - 無料会員
>
*** MyService::Member::VIP - VIP会員
>
たとえば、有料、無料、VIPのように複数の会員タイプがあるような会員サイトを作る場合、Class::DBIを継承したMyService::MemberがFactoryとなり、会員のタイプによって、MyService::Member::Basic, MyService::Member::Free, MyService::Member::VIPというようなサブクラスのインスタンスを作成するというようなイメージです。
さらにFactoryクラスでMyService::Member->retrieve_allとかすると、適切なサブクラスのインスタンスのリストがとれると最高です。
そんなことができないかなーとClass::DBIのドキュメントやソースを眺めていたんですが、Class::DBIに組み込まれているselectトリガを使えば実現できそうだったので、試してみました。
selectトリガはインスタンス生成時に必ず呼ばれているので、ここで会員のタイプを判別し、サブクラスにreblessしてやります。ソースコードはこんな感じです。このコードそのままではないですが、実際に同じようなコードを書いて試してみたところ、うまく動いているようです。
***MyService::Member - Factory
>
<
package MyService::Member
use base qw(Class::DBI);
require MyService::Member::Basic
require MyService::Member::Free
require MyService::Member::VIP
__PACKAGE__->set_db('Main', @datasource);
__PACKAGE__->table('member');
__PACKAGE__->columns(Primary => qw(member_id));
__PACKAGE__->columns(Essential => qw(member_type name age));
# select トリガにrebless用のメソッドをセット
__PACKAGE__->add_trigger( select => \&_rebless );
# サブクラスにrebless
sub _rebless {
my $self = shift;
#会員タイプ(member_type)でreblesするサブクラスを選択
my $class = 'MyService::Member::Basic';
if ($self->member_type eq 'Free'){
$class = 'MyService::Member::Free';
} elsif($self->member_type eq 'VIP'){
$class = 'MyService::Member::VIP';
}
bless $self, $class;
}
# abstract method
sub is_free {}
sub monthly_cost {}
*** MyService::Member::Basic - 一般会員
>
<
package MyService::Member::Basic;
use strict;
use base qw(MyService::Member);
sub is_free { 0 } # 無料ではない
sub monthly_cost { 500 } # 月額500円
*** MyService::Member::Free - 無料会員
>
<
package MyService::Member::Free;
use strict;
use base qw(MyService::Member);
sub is_free { 1 } # 無料
sub monthly_cost { 0 } # 月額0円
*** MyService::Member::VIP - VIP会員
>
<
package MyService::Member::VIP;
use strict;
use base qw(MyService::Member);
sub is_free { 0 } # 無料ではない
sub monthly_cost { 250 } # VIPは月額250円
2005年7月6日水曜日
2005年7月4日月曜日
2005年7月1日金曜日
Web2.0な世界ではPerlがいい
antipop2.0 - Perler な Blog を列挙祭りのエントリでhori-uchi.comを取り上げてくださっていただいたのに最近Perlの話題あんまり書いてない!ということでちょっと思うところを書いてみたいと思います。
世の中にはいろいろなプログラミング言語が存在しますが、Web2.0な世界ではPerlがいいんじゃない?って話です。
Web2.0というと幅が広いですが、ここで言うWeb2.0はアプリケーション同士がAPIを通して相互に接続される世界とします。
このWeb2.0な世界でなぜPerlがいいのか、僕が考える理由は以下の3つです。
-型のない言語
-強力な正規表現
-CPANの存在
APIの実装はRESTやXML-RPC、SOAPなどを使った、XMLをデータのフォーマットとしてやりとりするというものが一般的です。ですので、各アプリケーションはXMLを解析し、処理すると必要がでてきます。XMLをプログラム内で扱う際にはXMLデータをXMLの階層構造を表現したハッシュであるとか、構造体のような形式にする必要がありますが、型を指定しなければいけない言語だと、いかようにもできるXMLをそういうデータ形式にするのは大変だろうなーと思います。その点PerlはXML::Simpleなんかをつかうと、
という一行でXMLのデータ構造をそのまま表したハッシュに変換してくれます。
また、XMLを解析してデータ形式に変換というような作業は結構時間のかかるものですが、Perlには高速で強力な正規表現があるので、これを使って、高速に特定のデータを抜き出すなんてことも簡単にできます。
最後にCPANの存在を忘れてはいけません。今後はAPIを提供するようなサービスが次々に出てくると思います。CPANには人気があるサービスだとそれらのAPIを簡単に使えるようにしてくれるモジュールがたいてい存在しています。Net::Amazon、Net::Google、WebService::Bloglines、WebService::Hatena::Fotolifeなど数え上げればきりがありません。
これらを使えば旬なサービスを簡単に使うことができます。
こんな訳で、APIでサービス同士がつながるWeb2.0な世界では、Perlがまた脚光をあびるんじゃないかなと思いました。
世の中にはいろいろなプログラミング言語が存在しますが、Web2.0な世界ではPerlがいいんじゃない?って話です。
Web2.0というと幅が広いですが、ここで言うWeb2.0はアプリケーション同士がAPIを通して相互に接続される世界とします。
このWeb2.0な世界でなぜPerlがいいのか、僕が考える理由は以下の3つです。
-型のない言語
-強力な正規表現
-CPANの存在
APIの実装はRESTやXML-RPC、SOAPなどを使った、XMLをデータのフォーマットとしてやりとりするというものが一般的です。ですので、各アプリケーションはXMLを解析し、処理すると必要がでてきます。XMLをプログラム内で扱う際にはXMLデータをXMLの階層構造を表現したハッシュであるとか、構造体のような形式にする必要がありますが、型を指定しなければいけない言語だと、いかようにもできるXMLをそういうデータ形式にするのは大変だろうなーと思います。その点PerlはXML::Simpleなんかをつかうと、
my $xml_href = XML::Simple->XMLin($xmlfile);
という一行でXMLのデータ構造をそのまま表したハッシュに変換してくれます。
また、XMLを解析してデータ形式に変換というような作業は結構時間のかかるものですが、Perlには高速で強力な正規表現があるので、これを使って、高速に特定のデータを抜き出すなんてことも簡単にできます。
最後にCPANの存在を忘れてはいけません。今後はAPIを提供するようなサービスが次々に出てくると思います。CPANには人気があるサービスだとそれらのAPIを簡単に使えるようにしてくれるモジュールがたいてい存在しています。Net::Amazon、Net::Google、WebService::Bloglines、WebService::Hatena::Fotolifeなど数え上げればきりがありません。
これらを使えば旬なサービスを簡単に使うことができます。
こんな訳で、APIでサービス同士がつながるWeb2.0な世界では、Perlがまた脚光をあびるんじゃないかなと思いました。
Sleipnir2アルファ版をインストールしてみました
タブブラウザ Sleipnir 開発日記より
上級者向け国産タブブラウザ Sleipnir2 (アルファ版)が公開されたようなので、試しにインストールしてみました。
まだIEと同等の機能しかついていないということです。
僕は普段、Bloglinesなどで気になる記事をピックアップしとりあえず全部開いてから後でじっくり見ていくというようなブラウザの使い方をしているので、タブが30個とかざらに開いてます。旧Sleipnirではそういう使い方をしているとCPU使用率がかなり波打ってWindows自体が不安定になったりしてましたが、僕がSleipnir2を試した限りでは、たくさんタブを開いてもCPU使用率が以前ほど高くならないようです。
とりあえず感想はそれくらい。マウスジェスチャーが実装されたらもう少し本格的に使ってみようかなー。
上級者向け国産タブブラウザ Sleipnir2 (アルファ版)が公開されたようなので、試しにインストールしてみました。
まだIEと同等の機能しかついていないということです。
僕は普段、Bloglinesなどで気になる記事をピックアップしとりあえず全部開いてから後でじっくり見ていくというようなブラウザの使い方をしているので、タブが30個とかざらに開いてます。旧Sleipnirではそういう使い方をしているとCPU使用率がかなり波打ってWindows自体が不安定になったりしてましたが、僕がSleipnir2を試した限りでは、たくさんタブを開いてもCPU使用率が以前ほど高くならないようです。
とりあえず感想はそれくらい。マウスジェスチャーが実装されたらもう少し本格的に使ってみようかなー。
登録:
投稿 (Atom)