mizzy.org

「PlaggerになくてYahoo!pipesにあるもの」は書き方が悪かった について。

Plagger について理解できてないだけです。書き方の問題じゃありません。まず、

このときPublish::Gmailがおかしいなと思った。なにがおかしいかというとフィルター機能があることだ。

Publish::Gmail にはフィルタ機能はありません。Plagger に実装されているものを、Publish::Gmail で利用しているだけです。

また、Publish::Gmail で利用しているのは、実際はフィルタ機能ではなく、ルール機能だったりします。似たような機能でややこしいかもしれませんが、Plagger では フィルタとルールは別物です。

本来フィルターの機能はFilterが担うべきで、Publishのプラグインにつけるべき機能ではない。

はい、Plagger はちゃんとそうなってますよ。

例えばBloglineからフィードを取得し、その中からいくつかのブログのフィードを各ブログごと取り出し各ブログごと異なる条件でフィルタリングしたり、はてなブックマークに登録し、残りのフィードはそのままGmailに送るということは本来的にはできないのでは無いかと考えた。

できます。たとえば、mizzy.org だけローマ字変換して Gmail へ、残りはそのままはてブへ、ということであればこんな感じ。（設定はかなりはしょってますが。）

plugins:
  - module: Subscription::Bloglines

  - module: Filter::Romanize::Japanese
    rule:
      expression:  $args->{feed}->title eq 'mizzy.org'

  - module: Publish::Gmail
    rule:
      expression: $args->{feed}->title eq 'mizzy.org'

  - module: Publish::HatenaBookmark
    rule:
      expression: $args->{feed}->title ne 'mizzy.org'

この例では、2つの Publish プラグインの出力対象フィードが別だから、プラグイン毎に rule 設定してるけど、両プラグインが同じフィードを出力するのであれば、Filter::Rule プラグインでフィルタすれば、rule を指定する必要がなくなる。

まあ、この辺りは分かりやすくはないから、誤解するのもしょうがいない気がするけれど、設定例だけ見て、そこから推測したものがあたかも実際の Plagger の仕様であるかのように書くのはやめようよ。

コメント/トラックバックスパムがうざいので、一時的に受け付けないようにしました。

で、blosxom で対策してもいいのですが、これを機会にブログツールを乗り換えようと、Angerwhale を試すことに。（本当は Catlxom への乗換えを前々から検討していたのですが、大きく作り変えると typester さんがおっしゃっていたので、ちょっと様子見。）

Angerwhale と同様に、Catalyst ベースのブログツールに Typeface というのがあるのですが、Angerwhale はエントリをファイルベースで管理するので、blosxom に近いものがあるし、作者の jrockway は YAPC::Asia Tokyo 2007 にも来るので、もしかしたら話す機会もあるかもしれないので、こちらを使ってみることに。

使ってみてちょっと不便だな、と思ったのは、

• エントリタイトルはメタデータとして管理する。
• カテゴリ名はディレクトリ名そのまま表示。

の2点。

以下、もう少し詳しく説明します。まずはエントリタイトルの件。

Angerwhale ではエントリの作成時間などを、メタデータとして管理します。メタデータは File::Attributes を利用して作られ、.entry_file_name.attributes といったファイルが、エントリファイルと同じディレクトリに作られます。内容は以下のように YAML になってます。

---
creation_time: 1172377648
guid: 813B071C-C488-11DB-BB28-6F396B4151C7

このメタデータファイルに、

title: エントリタイトル

といった記述があれば、これをエントリのタイトルとみなします。なければ、ファイル名から拡張子を除いたものがエントリのタイトルになります。

ファイル名とタイトルが違う、なんてことがよくあるわけですが、そうしたい場合には今の仕様だと、

1. エントリファイルを置く
2. 一度ブラウザでアクセスしてメタデータファイルを作らせる
3. メタデータファイルを開いてエントリタイトルを記述する

なんてことをしなければいけない、ということになります。めんどいですね。

次にカテゴリ名の問題。

Angerwhale は カテゴリ ＝ ディレクトリなんですが、ブラウザ上にはディレクトリ名をそのまま表示しちゃうんですね。ディレクトリは英語で、表示は日本語でしたい、ってのもよくあることなので、これも不便ですね。

この辺り、パッチ作ったりして対応したいな、と思ってます。

また、以下のバグと思わしき問題もありました。

• ホームにアクセスすると、カテゴリわけされたエントリが表示されない。
• カテゴリにアクセスすると、404 エラー。

これは以下のパッチを書いて、jrockway に送ってみました。

Index: lib/Angerwhale/Model/Filesystem.pm
===================================================================
--- lib/Angerwhale/Model/Filesystem.pm  (revision 573)
+++ lib/Angerwhale/Model/Filesystem.pm  (working copy)
@@ -58,7 +58,7 @@
 sub get_article {
     my $self    = shift;
     my $article = shift;
-    my $base    = $self->base;
+    my $base    = shift || $self->base;

     die "article name contains weird characters"
       if $article =~ m{/};
@@ -90,10 +90,14 @@
         my $entry = "$base/$article";
         next if $article =~ m{^[.]};    # hidden files are also ignored
         next if !-r $entry;
-        next if -d $entry;

+        #next if -d $entry;
+        if ( -d $entry ) {
+            push @articles, $self->_ls($entry);
+            next;
+        }
         #entry is acceptable
-        my $article = $self->get_article($article);
+        my $article = $self->get_article($article, $base);
         push @articles, $article;

     }

前回のエントリ で取り上げた方のブログに、Plagger になくてYahoo!pipesにあるもの というエントリがあったので、それについても釣られて言及してみます。

基本的に Plagger の処理は一本道であり、複数の基本データを扱うことができなかったはず

それ Plagger でもできるよ。複数の入力から一つの出力もできるし、一つの入力から複数の出力もできるし、複数の入力から複数の出力もできる。

いってみればPlaggerは一つの入力に一つの出力が対応している直線的な処理しかできない。それに対しYahoo!pipesは複数の入力に一つの出力が対応するという、逆ピラミッド的な処理もできる。これがPlagger になくてYahoo!pipesにあるものだ。（もしかして今はできるのかもしれない。）

id:otsune さんも指摘してるけど、それ smartfeed で。

「Plagger の発展をフォローしてないので不正確かもしれない」とか「もしかして今はできるのかもしれない」などと書かれてますが、少なくとも SmartFeed::All は 2006/05/03 には作られているので、複数の入力に対して一つの出力は、かなり前からできます。

また、一つの入力から複数の出力、複数の入力から複数の出力は最初からできます。なので、「基本的に Plagger の処理は一本道」というのは完全に間違い。Plagger の発展をフォローしてない、というのは言い訳にならない。「少なくとも自分が使っていた頃のPlagger になくて」と書いてるけど、本当に使ってたの？

まあ、Yahoo!Books のエントリを見てもわかるように、Plagger が何かをまったくわかっていない人間のたわごとなので、適当に流しておくのが大人の対応なんでしょうが、Plagger ラブな人間としては、間違った情報広められるのは嫌な気分になるので。

さすがにPlaggerでもこれは無理だと思いたい。PythonでYahoo!Booksのランキングをとってくる。 というエントリを見て、なんか釣りっぽいタイトルだけど敢えて釣られてみた。

ちょっとアウトプット違うけど、Plagger なら 10 分でできた。

以下の2つのファイルを用意してやるだけ。

config.yaml

plugins:
  - module: Subscription::Config
    config:
      feed:
        - url: http://books.yahoo.co.jp/ranking/general/all/all/weekly/index.html
          meta:
            follow_link: /book_detail/.*

  - module: CustomFeed::Simple

  - module: Filter::EntryFullText

  - module: Publish::Gmail
    config:
      mailto:   xxx@gmail.com
      mailfrom: plagger@mizzy.org
      mailroute:
        via: smtp
        host: localhost
        attach_enclosures: 1

EntryFullText 用 yaml

author: Gosuke Miyashita
handle: http:\/\/books\.yahoo\.co\.jp\/book_detail\/\d+
extract: <!-- 書籍紹介 -->.+<small>(.*?)</small>.+<!-- //書籍紹介 -->
extract_capture: body

既存の設定からほぼコピペなので、10 分のうち7割ぐらいは、EFT 用 yaml の文字コードが UTF-8 じゃないといけないのに、euc-jp にしてて「なんかうまくいかねー」とかやってた時間。

デブサミ発表資料中に、テストプラグインがどういうコードなのかを書いていたのですが、時間がなくてまったく説明できなかったので、ここで補足しておきます。

テストプラグインのコードはこの様になっています。

package Assurer::Plugin::Test::SMTP;

use strict;
use warnings;
use base qw( Assurer::Plugin::Test ); #(A)
use Assurer::Test; #(B)
use Net::SMTP;

sub register {
    my $self = shift;
    $self->register_tests( qw/ connect / );          #(C)
}

sub connect {
    my ( $self, $context, $args ) = @_;

    my $conf = $self->conf;

    my $host     = $conf->{host}     || $context->conf->{host};
    my $timeout  = $conf->{timeout}  || 10;

    my $smtp = Net::SMTP->new(Host => $host, Timeout => $timeout);
    ok($smtp, "smtp ok $host"); #(D)
}

1;

青字の部分が、プラグインを書く際のお約束というかポイントとなる部分なので、順に説明していきます。

(A) では Assurer::Plugin::Test を継承しているわけですが、テストプラグイン共通の処理はすべて Assurer::Plugin::Test に記述することにより、各プラグインでのコード量を減らそうという目論見になってます。

(B) で Assurer::Test を use することより、ok(), is(), like() といったテスト用メソッドをインポートしています。

(C) ではテストを行うメソッドを登録しています。複数登録する場合には、

$self->register_tests( qw/ test1 test2 test3 / ); 

といった記述をします。この場合、test1(), test2(), test3() の順で実行されます。

(D) が実際にテストを行っているところで、Test::More の ok() と同じ動作をします。この ok() は上で書いたように、Assurer::Test からインポートしたメソッドです。このような組み込みのテストメソッドを使うことで、if 文で結果を判断して適切なステータスを返す、といった処理を書く必要がなくなります。

kazeburo さんの発表にある、Nagios プラグインと対比してみると、Nagios は exit 時のステータスコードだけ気にすればいい、というのに対して、Assurer では、上のコード (A), (B), (C) の様に、Assurer 特有のお約束を守る必要があるものの、exit コードは気にしなくていい、といった特徴があります。また、お約束を守ることによってコード量も減らせます。（特に結果判定で if を書かなくていい。）

Nagios の場合、ステータスコードだけ気にすればいい、とは言っても、ステータスが OK, Warning, Crtitical, Unknown とあるわけで、OK はまだしも、どういった場合が Warning でどういった場合が Critical なのか、ということを気にするのは、ちょっと面倒な気もします。

また、結果を受け取る側も、Warning とか Unknown とか受け取ると、それって問題あるの？ないの？って迷ったりしないのかな、とか、Warning と Critical の解釈って、人によって違うんじゃないかな、って思ったりします。（Nagios使ったことないんで、変なこと言ってるかもしれませんが。）

そういった曖昧さをなくしたくて、Assurer では OK か NOT OK かの2種類の結果しか返さない、というポリシーにしました。

とは言っても、Nagios の様にステータスが何種類かある方が便利だという場面はあるんでしょうね。その辺りは Assurer では、エラーメッセージでフィルタリングできるようにして、「こういったエラーメッセージの場合は、問題ないから OK にする」といった設定ができるような形にして、結果の解釈を利用者に委ねられるようにしようと考えています。

デブサミ出張 Shibuya イベントで、Assurer についてしゃべってきました。発表資料をここに置いておきます。

感想とか書きたいのですが、嘔吐下痢性の風邪にやれられて、一日何も食べることができず、打ち上げにも参加できないぐらい体調悪いので、今日はこの辺で。

Assurer についてその後あんまり書いてないですが、何もしてないわけではなく、リトライをハンドリングできるようにしたり、並列実行できるようにしたりと、ちょこちょこと開発は進めています。

で、前回のエントリ で、Archer にシェルモードをつけてみたわけなんですが、シェルモードってテスト/監視ツールにこそふさわしい、と思ったので、Assurer にもつけてみました。こんな感じになります。

$ assurer.pl --config=config.yaml --shell --role=app --para=3
shell> uptime
[www.mizzy.org]  02:59:34 up 4 days,  3:39,  1 user,  load average: 0.21, 0.23, 0.22
[svn.mizzy.org]  02:59:34 up 4 days,  3:39,  1 user,  load average: 0.21, 0.23, 0.22
[ftp.mizzy.org]  02:59:34 up 4 days,  3:39,  1 user,  load average: 0.21, 0.23, 0.22
shell> 

--role がなければ、config.yaml で列挙されているホスト全部で実行します。

id:tokuhirom さん作のデプロイツール Archer を最近使い始めたのですが、これがすげーいいっす。

で、この週末は更に便利に使えるように、Archer 用のプラグイン書いたりしてました。

• Archer::Plugin::SVN::Log
• Archer::Plugin::SVN::Diff
• Archer::Plugin::SVN::Update
• Archer::Plugin::Rsync
• Archer::Plugin::Shell

global:
  work_dir: /home/miya/work
  dest_dir: /home/miya/assurer

tasks:
  init:
    - module: SVN::Diff

    - module: Confirm
      config:
        msg: really update? [y/n]

    - module: SVN::Update

    - module: Confirm
      config:
        msg: really deploy? [y/n]

  process:
    - module: Rsync

projects:
  Assurer:
    app:
      - mizzy.org

こんな感じの設定をして、

$ archer.pl Assurer -c assurer.yaml

とか実行すると、

• /home/miya/work/Assurer にある svn co したファイルと、SVN HEAD の diff を表示。
• svn up するかどうか、プロンプト表示。
• svn up 実行。
• 実際にデプロイするか、プロンプトを表示。
• ローカルの /home/miya/work/Assurer から リモートサーバ上の /home/miya/assurer へ rsync でファイルコピー。

といった動作になります。

Archer 同梱の config.yaml では、svn log, svn up, rsync は Exec::Local プラグインで実行しているのですが、この辺りの記述をできるだけ簡略化したいな、ということで、こういったプラグインをつくってみました。

また、ライブドアテクノロジーセミナーの naoya さんのプレゼン で、Capistrano にはシェルプロンプトを表示して、指定したコマンドを複数のリモートサーバ上で一発で実行できる、という機能があって、これがうらやましかったので、Archer プラグインとして実装してみました。

tasks:
  init:
    - module: Shell
      config:
        role: app
        para: 1

projects:
  mizzy.org:
    app:
      - www.mizzy.org
      - svn.mizzy.org
      - ftp.mizzy.org

といった設定をしやると、以下の様な感じで実行できます。（3つのサーバは実体が同じなので、結果が同じですが。）

$ ./archer.pl -c shell.yaml mizzy.org
[info] run hook init
[debug] load Archer::Plugin::Shell
[info] run Archer::Plugin::Shell
shell> uptime
[www.mizzy.org]  02:59:34 up 4 days,  3:39,  1 user,  load average: 0.21, 0.23, 0.22
[svn.mizzy.org]  02:59:34 up 4 days,  3:39,  1 user,  load average: 0.21, 0.23, 0.22
[ftp.mizzy.org]  02:59:34 up 4 days,  3:39,  1 user,  load average: 0.21, 0.23, 0.22
shell> 

Archer はこちらから入手できます。また、俺が書いたプラグインなんかは、ここに置いてあります。