親父と一緒にやってるBPMに変わる新しいアプリケーション「Kailas」の開発で、 必要になったので Data::Validator::Simple っていうちっちゃいモジュールを作り出しました。 アプリの要求として、「条件分岐」させなくてはいけないところがあって、 その判定に使うってのが作ることになった主な目的です。 条件分岐というと if else 使いますが、それを抽象化して、 特定のルール、例えばその値が範囲内にあるかどうかという「BETWEEN」や、 文字列や数値が一緒かという「EQUAL_TO」などをパラメータと共に渡せば結果が返ってくるという具合です。

というといわゆるFormValidator::*を思い浮かべますし、 実際のところそれを使ってもよかったのですが、 今回特殊なパターンがでてくることを想定したり、 基本的にWebのFormから受け取るようなデータは扱わないつもりなので、 作ってみました。

とはいってもFormValidatorっぽい動きもしたいよねーとも思ったりしたので、 Data::Validator::Simple::Formオブジェクトがその役目を(ある程度)担うようにもできてます。 実践に使ってないのでなんとも言えませんが、その辺りは改良できればします。

まだdeveloper release扱いなので、APIが変わるかもしれませんが、 以下現状のSYNOPSISを解説。

まずは単一なデータの検証。

use Data::Validator::Simple;

my $data = Data::Validator::Simple->new( data => 5 );
my $result = $data->check( ['BETWEEN', 4, 10 ] );
if( $result ){
  print "valid";
}else{
  print "error";
}

複雑なパターン。checkメソッドに配列で渡せば順番で評価。 渡す値がハッシュリファレンスでかつ評価が成功した場合、その中のsuccessを返します。 successの中身は何でもいいので、この辺りがKailasで生きてくるはずです。

my $data = Data::Validator::Simple->new( data => 5 );
my $result = $data->check(
    {
        rule    => [ 'EQUAL_TO', 6 ],
        success => 'fist_message',
    },
    {
        rule    => [ 'EQUAL_TO', 5 ],
        success => 'second_message',
    }
);
print $result; # second_message

最後に、FormValidator的に使う方法。

my $q = CGI->new;
$q->param( id   => 'login_id' );
$q->param( name => 'user_name' );
my %params = $q->Vars;

my $form = Data::Validator::Simple->form;
my $results = $form->check(
    \%params,
    {
        id => [ 'ASCII', [ 'LENGTH', 4, 10 ] ],
        name => [ 'LENGTH', 4, 20  ]
    }
);
if( $results->{id} && $results->{name} ){
  print "valid";
}

今のところValidateに使えるルールが少ないので、これは増やしていくと共に、 Web特有のそれ以外のケースにも対応したいです。 で、まぁかなーりFormValidator::Simpleを参考にしているので、 それでいいんじゃねーか!みたいなことはおいといて、 更なる発展を自分で祈って作っていきます。

0.01_01というバージョンでshipitしちゃったんで! そのうちsearch.cpan.orgにインデックスされると思います。

Perl vs PHP

Perl と PHP の比較をしてみましょう。 私はPHPから入った口ですが、 今は、どちらがよいかというと、個人的な意見としてはやはりPerlです。

それは、PerlにはWebアプリ以外にも使える沢山のモジュールがCPANに用意されており、 PHPのように膨大な標準の関数を使ってせいぜいWebアプリを作るってだけではなく、 モジュールを入れさえすればそれで、CLI含めほぼなんでも出来てしまうからです。

*もちろんPHPもCLI作れるけどねー^^;

例えば、PHPの標準のfopen関数でファイル以外にも指定したURLのコンテンツを開けます。 ところが、Perlの場合はそれをモジュールで解決しようとします。

# cpan > install LWP::Simple
use LWP::Simple;
my $content = get('http://yusukebe.com/');

PHPの場合fopen一発でできるところ、Perlではモジュールのインストールからしなくてはいけません。 一見するとめんどくさいですねー^^; ところが、ちょっと発展させて、取得したコンテンツからh2タグの中身一覧を取得するといった複雑な処理を 考えてみましょう。 PHPの場合、どーするかわかりませんが、Perlだと便利なモジュールがあります。 今後、より複雑な処理を行うことを考えWeb::Scraperを使ってみます。

# cpan > install Web::Scraper
use Web::Scraper;
use URI;

my $scraper = scraper {
    process "h2.entry-title", 'titles[]' => 'TEXT';
};
my $res = $scraper->scrape( URI->new('http://yusukebe.com/') );
map { print $_ . "\n"} @{$res->{titles}};
Twib in Yokohama.pm テクニカルトーク#5
実例で学ぶPerlにおけるリファレンス
Perl入門本を書こうとしている話
PHPの小文字から始まる関数が4405個もあってびっくりした件
Perl初心者向け勉強会(by カジュアルPerl)をやりますという予告
Twitterの友達が好きなアーティストがわかっちゃったりする「音探し」を作ってみた
Twitterで話題のYouTube動画が一目でわかるTubetter - ツベッターを作ってみた
CatalystアプリケーションをStarmanで運用しよう!
3/5 Yokohama.pm #5 が開催されます
オススメのIRCチャンネルを教えてください@人力検索はてな

CSSセレクタやXPathで指定した部分だけを配列に入れてくれたりして便利ですね! こうした便利ーなモジュールがCPANには沢山あるので、 Perlの場合お好きな方法で楽してより多くの目的を達成することができるのです。

あと、PHPの場合オフィシャルの関数リファレンスを見たりしますが、 Perlの場合perldocというコマンドでモジュールに付属のドキュメントを見たり、 search.cpan.orgでは整形済みのそれを見たりすることができていいですね。 大抵「SYNOPSIS」っていうところのコードを実行すればモジュールの使い方がわかります。

まぁ、サーバの負荷うんぬんってのは状況によってはmod_perl使えばいいですし、 デプロイの話ってのはPSGIが標準化すれば手元で書いたコードがそのまま、レンタルサーバで動くぜみたいなことができるようになると思っています。

それにデバッグもPHPは簡単らしいのですが、 PerlだってData::Dumperモジュールや、YAMLモジュール使えば視覚的に中にどんなデータが入っているかが わかります。

use Data::Dumper;
use YAML;
# use utf8;

my $ref = { name => 'yusukebe', zokuseis => [qw(メガネ エロ)] };
print "Data::Dumper::Dumper\n";
print Dumper $ref;
print "YAML::Dump\n";
print Dump $ref;
Data::Dumper::Dumper
$VAR1 = { 
          'zokuseis' => [ 
                          'メガネ',
                          'エロ'
                        ],
          'name' => 'yusukebe'
        };
YAML::Dump
---
name: yusukebe
zokuseis:
  - メガネ
  - エロ

私はもう今となってはPHPはほとんど触りませんが、 やはりWebの開発から小物スクリプトまでPerlに軍配が上がる、と思います。

モジュールのインストールがめんどいなーとかレンサバで動かないよーとかも local::libやcpanmのおかげで解決しつつありますし、 上記した通りPSGIやPlackが頑張ってくれればWebアプリを動かすのもいろんな環境で楽できると思います。

それとPHPからPerlに移行したい!って人によっては php-funcref-in-perlっていう素晴らしいプロジェクトがあるので、 安心ですね^^

別にPHPをディスってるわけじゃないですが、 なんとなく書いてみましたよ!

元ネタ: PHP vs Perl - phpspot

PS. 最近「ゆーすけべー日記」がperlcodesampleさん化しつつあるのは、 Perl書籍を書こうとしているからです^^;

Yokoahama.pm テクニカルトーク#5 に参加&発表して来ました。 いやー和気あいあいとしていて、かつ初参加の人も結構いたのでよかったですね。 自分は、Twib というサービスを「いかに個人でやりつつ、パフォーマンス上げてくか」 みたいな話を中心にさせていただきました。 今まで記事にしてなかった Twib の裏側現状編という感じです。

スライドはいかにアップしておきました。

注釈としてここで出てくる「取りこぼし」の問題の件なのですが、 これはTwitter APIを頑張って用いても、対象となる全件のツイートを取得するのが無理だという話ですね。 なんとかしたいっすなー。 他の方の発表はみなさん自由な雰囲気がよろしくて、 しっかりとそれぞれのPerlの話をしていました。

gfx

内容のログはいつも通り丁寧にhirataraさんがまとめてくていれますので、 参考にしてください。 Yokohama.pmというと我先に!と発表したがっちゃう自分がいますが、 まだ発表したことない!という方も次回はチャレンジしてみたらいかがでしょうかと思いました。

Perlの文法が大体わかってくるとぶちあたる壁が「リファレンス」です。 Cを既にやっている人ですと「ポインタ」という概念を知っているので、 あまり違和感がないのですが( by lestrrat さん )、個人的にはこいつを理解した時に 「パーと」Perlに対する視界が開けた感じを受けました。 perlcodesampleさんもこう言ってます。

Perlで一番ややこしく感じるのはリファレンスだと思う - サンプルコードによるPerl入門

でまぁ、そんな難しい話ではないし、 慣れれば全てリファレンスで扱うケースもありとのことなので、 コードを交えて解説してみたいと思います。 ツッコミ歓迎です。 ちなみに、僕がリファレンスを理解するきっかけになった「続・初めてのPerl」の例を多いに参考にしています。

これから扱うサンプルは

  • 萌え
  • メガネ
  • ギーク
  • エロ
  • 嫁あり

という5つの人に関する属性があると過程して、 それぞれの人がどのような属性を持っているかをチェックして出力する簡単なプログラムです。 例えば、yusukebe には メガネ エロ という属性がある という具合です。 これから例で示す人名らしき物はあくまで架空のものだと思ってください。 まずは素の配列のみを使ってそのデータ構造を書いてみます。

my @zokuseis = qw(萌え メガネ ギーク エロ 嫁あり);
my @miyagawa = qw(萌え ギーク);
my @yusukebe = qw(メガネ エロ);

これをそれぞれの人が持っている属性と予め定義された「@zokuseis」の文字列と比較して、 マッチすれば出力するというプログラムは、 何も考えないでやると以下のようになります。

# 配列のみを使った場合

for my $zokusei (@zokuseis) {
    if ( grep $zokusei eq $_, @miyagawa ) {
        print "miyagawa is $zokusei \n";
    }
}

for my $zokusei (@zokuseis) {
    if ( grep $zokusei eq $_, @yusukebe ) {
        print "yusukebe is $zokusei \n";
    }
}

2個ループがでてきて冗長ですね。 ということでこの部分一つのサブルーチンにまとめてしまいましょう。

# サブルーチンを使った場合

check_zokusei( 'miyagawa', @miyagawa );
check_zokusei( 'yusukebe', @yusukebe );

sub check_zokusei {
    my $name = shift;
    for my $zokusei (@zokuseis) {
        if ( grep $zokusei eq $_, @_ ) {
            print "$name is $zokusei \n";
        }
    }
}

ちょっとすっきりしました。 しかし、問題とやりたいことがいくつか。

  • check_zokuseiサブルーチン内で、@_ は配列の中身全てをコピーしているので、 配列が大きくなった時に無駄である。
  • check_zokuseiサブルーチンの引数として、第2引数以降の配列全て、つまり一度 shift した後の @_ が 属性名前の配列だとは限らないかもしれない。
  • データ構造を表す時点で miyagawa, yusukebe といった「名前」を定義したい。
  • メンバーが増えた時に毎回メソッドを実行するコードを書くのが面倒である。

で、ちょっとぶっ飛ばして、無名リファレンスと呼ばれてる方法で、 データ構造を定義してそれを扱うことにしてみます。 配列の無名リファレンスは [] 、ハッシュの無名リファレンスは {} で表現します。 変数に入れるときは、@ や % を使うのではなく $ つきのスカラー変数に入れます。 これを使うことで、ネストしたデータ構造を記述することができます。 データ定義は以下のようになりました。


my $members = [
    { name => 'miyagawa', zokuseis => [qw(萌え ギーク)] },
    { name => 'yusukebe', zokuseis => [qw(メガネ エロ)] },
    { name => 'nekokak',  zokuseis => [qw(ギーク 嫁あり)] },
    { name => 'Yappo',    zokuseis => [qw(ギーク エロ)] },
    { name => 'acotie',   zokuseis => [qw(萌え エロ)] },
];

細かいことは置いといて、これでメンバーがどういう名前で、どのような属性を持っているかが、 一望できるようになりました。 このようにネストしたデータ構造を配列リファレンスとハッシュリファレンスを駆使して、 表現するとヒューマンリーダブルでもありわかりやすいと思います。

では、これを先ほどのように属性チェックさせてみます。 まず、配列リファレンスを「デリファレンス」という方法を用いて、素の配列に変換してから、 ループを回しています。スカラー変数名に @ と頭に付ければ、配列にデリファレンスされます。 そして、先ほど定義された無名のハッシュリファレンスをそのまま、 check_zokusei_with_ref に渡しています。 ハッシュの中身へのアクセスは、 $who->{name} のような形で実現しています。

for my $member (@$members) {
    check_zokusei_with_ref($member);
}

sub check_zokusei_with_ref {
    my $who = shift;
    for my $zokusei (@zokuseis) {
        if ( grep $zokusei eq $_, @{ $who->{zokuseis} } ) {
            print "$who->{name} is $zokusei \n";
        }
    }
}

最終的に出力は以下のようになりました。

miyagawa is 萌え
miyagawa is ギーク
yusukebe is メガネ
yusukebe is エロ
nekokak is ギーク
nekokak is 嫁あり
Yappo is ギーク 
Yappo is エロ 
acotie is 萌え 
acotie is エロ 

ということで実例を用いて、素の配列だけで表現していたものを リファレンスを使ってわかりやすくかつ効率的にデータを扱う方法をかなり駆け足で解説をしてきました。 文法的な部分はしょってますが、 リファレンスというものがなんなのかが多少でもわかれば幸いです。 「これ間違ってるお!」とか「こんなんじゃわかんねーよ!」とかご意見あったらください。 ということでEnjoy!

あんまこれからやることを書きたくはないと思っていたんだけど、 書いたらよりやる気になると思って書きます。 ていうか書いていいことなのかよくわかりませんが、書きます。

実は、今年の夏発売目標で、Perl入門本を書こうとしています。 某出版社さんから話があったのがきっかけです。 自分はPerlを教えるような立場ではないとは思いつつ、 昔から友達などにプログラミングの楽しさ、特にPerlについてを「うまく」教えたいなとは感じていました。 ということでいい機会なので乗っからせていただいてます。

世の中にはいいPerlの入門本があります。 特にオライリーの「初めてのPerl」と「続・初めてのPerl」は、 個人的に最初の一歩を踏み出すいい機会を与えてくれました。 大学に通っていた時に研究室でいらなくなったともらった「初めてのPerl」の初版がまた面白くって! さらに、「続・初めてのPerl」ではリファレンスの概念がわかって、 そこからかなりPerlに対して納得がいくようになりました。

ただ、Perl本はあるとして、数が少ないのと、上記した二つは 「語り口調?が難しいすぎる」という問題があって、これはなかなか取っ付きにくいだろーと思います。 それと他の本はどうしても「Perl=CGI」というペースで解説が進むものになっていて、 これがシンプルに理解をすることを妨げることになっている感じもします。

そこで、基本的には「初めてのPerl」の初版をかなり参考にしながら、CGIはとっぱらって、 自分なりの語り口調で構成案を練っているところです。 基本的なことほど教えるのが難しいと実感しつつ、多くの人に参考になるものしたいと 頑張ろうと思います。

以下にその書籍の企画意図みたいなものを書きますので、 それでこれからやろうとしていることがわかると思います。 執筆をする過程でいろいろな方に協力をしてもらう場面あるかもしれませんが、 よろしくお願いします。

まぁ、ようは 「自分が好きな人達に自分が好きなことを教えたい」 ってだけなんだけどねっ!

以下企画案。

Perlは実用的で「使える!」プログラミング言語です。 元々テキスト処理向けに作られた言語であるゆえ、 世の中に多く存在するテキストベースのシステムの管理に強いのが特徴です。 テキストと言えば、Webもその対象の中の一つで、最近ではmixiやlivedoorといった会社が 大規模Webシステムのバックエンドに採用しています。

また、テキスト整形やファイルフォーマットの変換など、 日常的に発生する業務おいても有効に活用できる機会が非常に多いです。 そして、Perlは実用的であると同時に「楽しい!」プログラミング言語です。 「TMTOWTDI ... There's More Than One Way To Do It(やり方はいくらでもある)」 というスローガンが表す通り一つのことを叶えるのに様々な記述方法があり、 それゆえに多くのやり方を私たちは見ることができます。 レベルや個人の趣向に応じて様々な楽しみ方があるのです。

また、CPANという仕組みにより先人達が作ったモジュールを再利用して楽をすることが可能です。 例えば、日付扱うモジュール、Webページにアクセスするモジュールなど多数存在し、 一から基本的な機能を記述する必要なく素早くシステムの目的に集中してプログラムを組むことができます。 このようにPerlは「使えて」「楽しい」言語なのです。

ところが、2010年1月現在、RubyやPythonなどの比較的新しい言語に押され、 Perlという言葉を目にする機会が少なくなってきています。 つまり、Perlはもう古い、ということなのでしょうか。確かに、Perlが古い言語であることは事実です。 しかし、だからといって全てのPerlプログラムが今の時代に合わないということはありません。 いわゆるCGIと呼ばれるプログラムの中には冗長な記述の上、パフォーマンスが悪い例があり、 一昔前に氾濫していたふしがあります。 Perlに対する悪評があるとしたら、その印象が強いからかもしれません。 ただ、Perlでも、しっかりとやり方さえ選べばよりモダンで高負荷にも耐えられるシステムを作ることができます。

本書では、現代のシステム開発において冒頭で述べたPerlの「使える!」「楽しい!」といった特徴を多くの方に 享受していただくため、より新しいPerlの入門書として位置づけます。 「やり方はいくらでもある」ために全てを網羅するのはもちろん不可能ですし、 そのような必要もありません。必要最低限のPerlをわかりやすく解説し、Perlの世界への導入としたいと思います。 冒頭ではPerlでのプログラミングの要素を一望できるようにサンプルプログラムを用意し、 簡単な解説をします。そして、後半部分では実用的なプログラムの例を取り上げ、 Perlの「使える!」もしくは「楽しい!」利用方法について紹介したいと思います。 なお、Perl入門本ではよく取り上げられるCGIについては詳しく「扱いません」。 CGIを扱うとPerlプログラムの本質とは離れた部分の説明が多くなるためです。 その代わり、後半部分のサンプルプログラムを掲載する部分で簡単に解説いたします。 さらに、近代の他言語では必須とも言われているオブジェクト指向プログラミングについても 「扱いません」。ただ、オブジェクト、つまりPerlにおけるモジュールの使い方についての記述は 盛り込みます。Perlの入門時においてオブジェクトの作り方までを学ぶとなるとなるとレベルが 本書の想定レベルからは離れるからです。

#perl-casual@freenode で話題になって、 PHPの関数の 機能をPerlで実現するにはどうすればいいのかの対になったリファレンスが欲しいよねー ということになりました。junichiroさんによると需要があるみたいです。 詳しくはYappoさんが書いてくれると思います。 そんで(ちょっとした僕の発言のおかげでWikiHubに迷惑をかけてごめんなさいな感じなのですがすいません><)、 PHPのリファレンスサイトにのってる関数っていったいどんなのがあるんだ!というのを くまなく調べることをしてみました。 あんまPHPよくわかってないのですが、クラスから派生してるっぽい関数は除きつつ、 小文字から始まる関数名の数を公式サイトから数えてみると、 なんと「4405」個もあったよ!

以下がそれを調べるために使えるPerlの簡単なスクレイパースクリプトです。

use Web::Scraper;
use URI;
my $url = 'http://php.net/manual/ja/indexes.php';
my $scraper = scraper {
    process 'dd.indexentry', 'functions[]' => 'TEXT';
};
my $res = $scraper->scrape(URI->new($url));
my @fs = grep { $_ =~ /^[^A-Z]/ } @{$res->{functions}};
print $#fs . "\n";

perldoc perlfuncでPerlの標準関数を調べると数が220個ほど。 ちょっと何を「標準」と呼んだらいいのかPHPの場合わかりかねますが、 リファレンスサイトに載ってるその数と比べるとだいぶー違いますね。 まぁ、Perlの場合は標準でついてくるモジュールの関数を使ったりしますから、 一概に比較はできませんが、言語の違いってのを改めて感じました。

ちょw、この関数使わないだろw

みたいなのもPHPにはあったりしますが、Perlの場合はそれをCPANモジュールで解決してるわけであって、 組み込みの関数でやるかモジュールインスコしてやるかはそれぞれ利点や不都合な点あるわけで... ただ、Perlの場合は配列を操作する関数であっても、 どちらかというといくつかの関数を組み合わせて目的を達成するのに比べて、 PHPの場合はそれぞれがひとつずつ関数になっている感じは受けました。 僕はやっぱり柔軟なPerlのやり方の方(思想)が好きなーと思います。 自分は、確か、Perlより、PHPの方を最初に触りました。 問題を解決する関数がすぐに見つかればPHPは初心者にとって簡単という印象ですが、 わかってると、少し考えればいかようにも解決ができるPerlの方がいいなという具合です(思想的にね)。 よりスマートなやり方を好めばList::Utilモジュールを使うというような解決策もありますし。

いやーでもこんなたくさんあるとは知らなんだです。 まぁ、使う人が気持ちいい言語を使えばいいと思いましたね!

今朝、「そろそろ...」とJapan Perl Association会長の牧さんからTwitterで声をかけられて、 一応企画のドラフトまで作りました。 それはどういうことかというと...。 カジュアルPerlのイベントとしてJPAの協力?にて「Perl初心者向け勉強会」を開催します! 予定ですが、日程は4/21(水曜日)19:00-21:00で、場所はおそらく初台のどこかになると思います。 最後にドラフトのプログラム原稿を貼付けておきますが、 テーマが「CPANとエディタ」となっております。 「CPANってなんぞー」という方を含め、少しでもPerlを勉強したいと思っている方に参加してもらいたいと思います。 内容は、スペシャルゲスト(世界のmさん予定があえば)を含め4人の方を講師に迎え、 それぞれライブコーディングを含めた講義?っぽい発表をみんなで聴くという形になります。 Perlは初心者向けの勉強会が非常に少ないというかそんなの聞いたことないので、 いい機会になればと思っています。 なるべく、常連なPerlerメンツにならないように参加資格を初心者向けに設定し、 ATNDで近日募集を開始しますので、よろしくお願いいたします。 何かご意見あれば、はてなブックマークなりTwitterなりでコメントくれればできる限り反映、リプライしたいと思います。

「気になるアーティストの人気な曲のYouTube動画を連続再生してくれて、 さらにテイスト似ているアーティストも提案してくれるから音楽探すのにぴったりだね」 という自分が欲しい機能を満たすシンプルなサービスを作ってみました。 ってのが最初の目的でしたが、機能をこれに追加して、一応目玉としては 「Twitterログイン(OAuthという仕組み)すると、自分がフォローしている一部の人が大好きな アーティストがわかっちゃうかも!」というサービスになりました。 名前は「音探し」です。

音探し 音探し 音探し このエントリーをはてなブックマークに追加
otosagashi

こちらのスクリーンショットがアーティストページ。 そのアーティストの人気トラックが連続再生できるのでBGMにぴったりかも。

otosagashi

そして、次がトップページからTwitterログインしてからのお友達が「loves」なアーティストが わかっちゃうというページです。 意外なアーティストを好きだったり、やっぱりこの人このアーティスト好きなんだというのがわかったりと 結構面白いです。

otosagashi

お分かりの人はお分かりの通り、Last.fmの機能をそのままAPI経由で使っています。 似たサービスがあると思うのですが、 日本語のシンプルなインターフェースがなかったので作ってみました。 ということでEnjoy!

Twitter上で多くつぶやかれているYouTube動画がぱっとわかって、すぐ見れて、 さらにTwitter OAuthログインをすれば映像を見ながらそれについてツイートできちゃうという 「Tubetter - ツベッター」というサイトを作ってみました。

Tubetter - Twitterと一緒にYouTubeを楽しもう Tubetter - Twitterと一緒にYouTubeを楽しもう
tubetter

拙作、Twitter上での人気URLを集める TwibのYouTube特化版のようなものです。 だったら、Twib上でやれよって感じですが、ちょっとシステム的にそちらの方はあまり手を加えたくないという理由もありTubetterができました。

現在ページを見ると、チリ地震による津波の影響で津波を実際に撮影した映像が今「435tweets」と多くつぶやかれていることがわかります(作りが甘いのでこのページがちと重いのはあとで直します)。 この「435tweets」というかなり多くのサンプル数はTwitterの利用頻度の高まりや気軽さを示しているかもしれませんね。実際同じ動画のはてなブックマークの数を比べてみると、それは、現在「30users」と比べようがありません。多くの人のツイートを見ながら動画を拝見するとまた違った楽しみ方があると思います。

Twibと違う方法でTwitterの情報を取得している件で、今回はこのようにより多くの「tweets」を表示させることが可能になりました。 通常ですとTwitter公式のAPIから「youtube」というような検索クエリを発行してツイートを収集するわけですが、短縮URLの問題や取りこぼしが非常に多いという問題が存在しています。 しかし、Tubetterの場合は一部の動画、特に人気の高い動画のURLに関しては、 topsyというサービスのAPIを使うことにより取りこぼしが少なくっています。 topsyこそTwibのようにTwitter上でつぶやかれたURLを収集しランキングをつけて検索可能にした海外のサービスです。 APIの性質がリアルタイム性のあるTwitter公式のものとは違い、とあるURLに対する「反応」としてツイートを扱っているので、今回のようなサービスにはある程度適して使うことができているみたいです。

ちなみにtopsyのAPIを使っていたら、見たことがあるエラー画面出てきて、

ちょw、Catalystのデフォルトエラーが画面じゃんwww

って思ったところmiyagawaさんによれば、彼らはPerlガイとのこと。 ということでCatalystアプリからCatalyst製のAPIをこれでもかと叩かせていただいています。

ちょっとまだ作りが甘かったり、重かったりしてますが、様子をみて 改善しますので、よろしくお願いします。 Enjoy!

Starmanというmiyagawaさんが目下開発中のPerl製Webサーバがあります。 PSGIをサポートして高速であることが特徴です。 おとといにバージョン0.1000がCPANにアップロードされたばかりという新しいものですが、 とあるエロサイトでStarmanを導入したので、その件について 書いてみたいと思います。 ちなみにStarmanについては日本語のドキュメントがほとんどなく、 全体を通して間違ったこと言ってる可能性あるのでツッコミ歓迎です。

PSGI/Plackが熱いと言われる昨今ですが、 miyagawaさんが口を酸っぱく言うように 「PlackはWebアプリケーションフレームワーク」ではなく、 今まで使っていたWAFをPlackが騒がれているからといってそれに置き換える必要はないということを 最初に記しておきます。 自分もPlackを使ってWAFもどきを作っていますが、 大抵のWebアプリに関してはCatalystを使っています。 Catalystはもちろん個人差がありますが一度慣れると開発が非常にしやすいので大好きです。

てなわけで、例に挙げるとある一番アクセスの多いエロサイトはCatalystで開発しています。 で、今回注目したいのはそのアプリケーションのデプロイの仕方です。 皆さん、Catalystアプリはどのように運用してますでしょうか? 僕は Apache + mod_perl ( Catalyst::Engine::Apache ) というパターンがほとんどです。 中には Lighttpd + FastCGI という組み合わせの方もいるかと思います。 おそらくそれで満足できるものかと思いますし、自分も Apache + mod_perl そして、 フロントに別の Apache を置いて静的コンテンツをサーブさせるというやり方で十分です。 しかし、新しモノ、それにPSGI、Perl製、高速、Starmanという響きに釣られ、 この度、Catalystアプリを Starman で動かすということにチャレンジしてみました。

まずは簡易なベンチマークをとってみましたという報告から。 実際に運用しているApache + mod_perlという環境と、 Starmanで立ち上げた場合、どちらがどれだけ高速か? そのとあるエロサイトを対象にし、同じworker数になるように調節し、 ab でベンチマークをとると、細かい部分を抜きにして、以下の結果がでました (そもそものアプリが遅いというのはおいといてね)。

Apache + mod_perl - Requests per second:    3.18 [#/sec] (mean)
Starman           - Requests per second:    4.43 [#/sec] (mean)

Starmanの方が約140% fasterです。 メモリ消費量はそれほど変わりません。 (*追記: CoWで共有されているメモリがあるのでworkerの実消費メモリをみたら少なくなってました>< ) ということでワクワクしながら早速本番投入してみます。

とその前に、CatalystアプリをStarmanで動かす手順について説明します。 StarmanはPSGIをサポートするので、最初にCatalystをPSGI互換にしましょう。 といっても、簡単で「Catalyst::Engine::PSGI」をインストールし、 Helperスクリプトで

$ script/myapp_create.pl PSGI

とするだけで、plackupで起動可能な.psgiができます。 つまりCatalystアプリのPSGI化ができたことになり、 上記したWAFを変える必要はないということがなんとなくわかる気がします。 plackupコマンドでももちろん起動できますし、Starmanを入れると

$ starman myapp.psgi

とすれば、starmanでCatalystアプリが起動します。 ちなみに現状のStarmanはPlackの開発版リリースを入れないと動かないのでご注意。

おし、これでCatalystアプリがStarmanで起動したぜ、ってことで、 いよいよ本番投入への準備です。 フロントサーバを構え、Starmanはリバースプロキシとして動作させたいので、 「Plack::Middleware::ReverseProxy」を.psgiで使い設定しましょう。 最終的にはこんな感じの.psgiになりました。

use Plack::Builder;
use XXX::Web;

XXX::Web->setup_engine('PSGI');
my $app = sub { XXX::Web->run(@_) };

builder {
    enable_if { $_[0]->{REMOTE_ADDR} eq '192.168.1.xxx' }
        "Plack::Middleware::ReverseProxy";
            $app;
};

最後にstarmanコマンドを使ってお好きなポート、お好きなworkerの数でサーバを起動します。 Plack::Standalone::Server::Prefork::Server::Starter を運用する時のように、 daemontoolsでプロセスを管理することにしました。

exec 2>&1
cd /home/yusuke/www/pulpsite/xxx || exit 1
exec /usr/bin/setuidgid www-data /usr/local/bin/starman \
--workers 20 --port 8080 ./xxx.psgi

こんな感じの run スクリプトを書いて、それが入ったディレクトリを /services へシンボリックリンク張れば、 起動開始。 無事、今まで Apache で運用していたものとリプレースが済みました。

今回は実験的なサービスに、ということで早速Starmanを導入してみました。 今のところいい感じなので、しばらく様子をみたいと思います。 まだ、でてきたばかりのソフトウェアですが、 よろしければ参考にして使ってみてください。

PS.
今度発売されるWEB+DB PRESSにはmiyagawaさんによるPSGI/Plack特集が載るらしいよ!

WEB+DB PRESS Vol.55
posted with yusukebe.com::AmazonSearch on 2010.2.17
  • WEB+DB PRESS編集部
  • 大型本 / 技術評論社
  • Amazon 売り上げランキング: 789
Amazon.co.jpで詳細を見る

プロフィール

yusukebe

ゆーすけべー / yusukebe
Yusuke Wada
1981/12/23 生
天然パーマ Erogeek
HP Twitter mixi はてブ
yusuke (at) kamawada.com

最近10件のアクション

  • yusukebeは"いい感じになってきた http://github.com/yusukebe/Podder"をtweetしました
  • yusukebeは"ドキュメントビュアーPodder、スクリーンショット http://bit.ly/aFYWdp http://bit.ly/a5IVon"をtweetしました
  • yusukebeは"ドキュメントビュアーPodderを作り始めてだいたい形になってきたので、Inao記法に対応させた http://github.com/yusukebe/Podder #inao"をtweetしました
  • yusukebeは"久しぶりに C 書いてる"をtweetしました
  • yusukebeは"久しぶりに"をtweetしました
  • yusukebeは"釣り記事に触発された釣り記事です RT @nog: @yusukebe 釣り記事かと思ったら元ネタが凄かった。"をtweetしました
  • yusukebeは"Perl vs PHP http://yusukebe.com/archives/10/03/07/103912.html"をtweetしました
  • yusukebeは"Yokoahama.pm テクニカルトーク#5 について記事書いた #yokohamapm"をtweetしました
  • yusukebeは"ま、無難に横浜、品川の駅周辺でいい会場があればって感じっすかね RT @zigorou: 北は新宿、南は鎌倉という観点で終電ドリブンで考えるべきかな。#yokohamapm"をtweetしました
  • yusukebeは"藤沢いいなーw RT @everes: 一応言ってみよう。藤沢 #yokohamapm"をtweetしました

最近のブログ記事

最近のコメント

  • 確かにPerlはライブラリを使うことにより、強力なツールとなりますが、逆にライブラリのインストールで失敗して途方にくれてしまう人間(私)にはちょっと敷居の高いツールとなってしまいます。Perl書籍を書...

    へなへな
    Perl vs PHP
  • PHP3,PHP4 の時代には PHP メインでいろいろ制作していましたが、メンテナンスに膨大な手間かかるのを実感するので、現在はメンテナンスのコストが一番かからない Perl をメインにしています。...

    たかはし@札幌
    Perl vs PHP
  • 全く関係ないんですが、YouTubeMP4でダウンロードができなくなりました。メンテナンスかなんかお願いします。...

  • これからPerl の入門書を書いてくださるということなので、入門のレベルは超えるのかも知れませんが、もし可能なら、Perl による index の簡単な作り方を最後の方に書き加えて解説してくださらない...

  • こんばんは、 2010年3月2日 書き込み致しました。 1週間ぐらい前まで、DLすることが出来て下りましたが、突然、ファイルを引っ張ってくれなくなってしましました。 その為、ダウンロードが出来ない...

Categories

月別 アーカイブ

閉じる