やっとこPlaggerを使えるところまでたどり着けた。livedoor Readerの更新FeedがGmailにどさっと届いたよ。おもしろい。
さて、Plaggerにたどり着くまでには、いくつものモジュールインストールとそのテストの失敗、たくさんの妥協、汗、涙、睡眠不足などの困難が伴ったわけだ*1。そのおかげでCPANやPerlについてわかったことをあげてみることにした。
CPANは便利でおもしろい
WWW::YouTubeとかHatena::FormatterとかMac::Glueとか。もっとセンセーショナルなモジュールもたくさんあるよね。CPAN漁ったりPlaggerの依存で入るモジュールを眺めていると、こんなのもモジュール化されてるのか！っておどろくことが多い。もうほんと自分でコード書く必要あるのかというほどの充実ぶり。
CPAN漁りにはモジュールに関するいろんな情報があつまったCPAN searchが普通ですね。ここは良い。テストが失敗したときもCPAN searchでテスト結果やバグレポートなどの情報をさぐれば、だいたい答えがみつかった。モジュールの使い方もすぐわかるし。ソースコードもすぐに調べられる。CPAN最強説を唱える人がいるのもうなずける話だ*2。
あと、最速の中の人がつくったCPAN saisoku searchにはかなりお世話になった。便利すぎ、これ。まさに最速。これのおかげでCPAN searchの便利さが5割増くらい。
テストは失敗する、あるいはCPANは熱いうちに喰え
ほんとテストはちょくちょく失敗する。apt-get installとかのノリでいくと耐えきれない。失敗の理由でありがちなのは依存関係がうまく解決できていなかったり、テストケースが時代遅れになっていたりすること。テストが失敗したときには、以下のようなことをやってみていた。
- インストールのエラー表示をみてCan't locate hoge/fuga.pm in @INCとかあるときは、hoge::fugaなモジュールをいれる。
- 隠れた依存モジュールがありそうならググって情報をさがす
- とりあえず、テストケースのソースコードを読んでみる。
- テストケースに外部のリソース(Webページとか)やライブラリに依存してる部分があったらあやしい。そのあたりを重点的に調査。
- テストケースは自分で実行してみる。モジュールのビルドディレクトリでperl -Mblib t/hoge.t。
- CPANシェルからだと古いバージョンがインストールされることもあるので、モジュール最新版をためす。
- ロケールがUTF-8だと良くないときがあるので、bashならLANG=C sudo -H cpanを使う。
- 依存でインストールできなくても個別でインストールすれば通ることもある。
実はやっかいなのが、テストケース自体が古くてうまく行かない場合。これは、テストケースが修正されない限りはテスト成功しないので、force installしか手が残されていないことが多い。まぁ、実害はないのだけど、テストケースが間違ってるのを確認するのに手間かかるよね。
やはり、更新されたの時期が新しいほどテストは成功することがおおいだろうから、なるべくモジュール追っかけるようにするのが幸せになれるコツなのかもしれない。CPANモジュールは熱いうちに喰え。
CPAN漁りは勉強になる
CPAN漁ったりインストールしたモジュール試したりテストの検証したりすると、必然的にPerlのコードを読むことが多くなる。とくにテストの検証はその一挙一動に目を凝らす必要があるので、きちんと読むことになる。そうすると、ハッカーが書いたソースコードにひたり続けることになってこれは良いんじゃないか！
というわけで
こんなことしている間にすこしはPerl力もあがったであろうかな。Plaggerインストール祭りもやっとこ終了。つぎはPlaggerいじりだ！まぁ、とりあえずFeedの更新をNotify::Ejectだな。
