2007年12月31日

CodeReposへのコミットをリアルタイムに通知する仕組みあります

commit-ping/SITEINFO - CodeRepos::Share - Trac

CodeReposにcommitされるとこのページの Commit Ping Servers 以下にかかれているURLに対してコミットの情報がPOSTされる仕組みです。
yamlというパラメータ名でYAML形式に変換されたコミットデータがPOSTされます。
ということでアナウンスしてないけど、こんな仕組みが有ります。

svnのcommit hookを使って、Commit Ping Servers以下に書かれているURLに対してコミット時のメタデータをPOSTで送信します。
POSTする時に詰まると嫌なのでTheSchwartzを使って非同期的に処理しています。

是非面白いことをやってくださいー

Posted by Yappo at 23:22 | Comments (0) | TrackBack

2007年12月28日

Perlで数有る$selfを取る手法をベンチマーク取った

PerlでOOなコード書く時のコンテキストを取る方法は色々あります、最近audreyがselfvarsをリリースしたので、gugodのself.pmとingyのSpiffyそして、既存のmy $self = shift;やshift->や$_[0]->で$selfを取る方法それぞれのベンチマークを取ってみました。

テストコードのモジュール名は、それぞれのモジュールの作者名から取り、既存の手法はYAPC::Asiaでプレゼンした事のある日本を代表するPerlな企業のCTOからモジュール名を取らせていただきました。

コードは以下の通りです。

package Audrey;
use strict;
use warnings;
use selfvars;
sub new { bless { count => 0 }, shift }
sub inc { $self->{count}++ }
1;
package Gugod;
use strict;
use warnings;
use self;
sub new { bless { count => 0 }, shift }
sub inc { self->{count}++ }
1;
package Ingy;
use strict;
use warnings;
use Spiffy -Base;
#sub new { bless { count => 0 }, shift }
sub inc { $self->{count}++ }
1;
package Ikebe;
use strict;
use warnings;
sub new { bless { count => 0 }, shift }
sub inc { $_[0]->{count}++ }
1;
package Naoya;
use strict;
use warnings;
sub new { bless { count => 0 }, shift }
sub inc { my $self = shift; $self->{count}++ }
1;
package Batara;
use strict;
use warnings;
sub new { bless { count => 0 }, shift }
sub inc { shift->{count}++ }
1;
use strict;
use warnings;

use Benchmark qw(:all);

use Audrey;
use Gugod;
use Ingy;
use Ikebe;
use Naoya;
use Batara;

my $inst  = {};
my $codes = {};

for my $pkg qw( Audrey Gugod Ingy Ikebe Naoya Batara ) {
    $inst->{$pkg} = $pkg->new;
    $codes->{$pkg} = sub {
        $inst->{$pkg}->inc;
    };
}
cmpthese(1000000, $codes);

以下結果。

            Rate Audrey  Gugod   Ingy  Naoya  Ikebe Batara
Audrey  110375/s     --    -9%   -91%   -92%   -92%   -93%
Gugod   121803/s    10%     --   -90%   -91%   -91%   -92%
Ingy   1250000/s  1033%   926%     --    -4%   -12%   -21%
Naoya  1298701/s  1077%   966%     4%     --    -9%   -18%
Ikebe  1428571/s  1194%  1073%    14%    10%     --   -10%
Batara 1587302/s  1338%  1203%    27%    22%    11%     --

大体よそおどおりでしょうか?Spiffyはソースフィルタリングしてるので他と肩を並べる速度になってますね。

12/28 21:02追記:すんげー色々ポカってたのでちゃんとやり直しましたorz yasu++

Posted by Yappo at 20:44 | Comments (2) | TrackBack

2007年12月26日

Class::Componentから見たNEXT問題

ちまたで大ブームなNEXTキメェwwwwww問題ですが、Class::Componentを半年作って来て感じた事を

Class::ComponentにもClass::C3っぽい挙動をするNEXTメソッドを内蔵しています。
違和感ありますよね?NEXT.pmとかClass::C3とかを使ってるんじゃなくて、内蔵ですからね。
何でかって言うとClass::Componentは、利用する側に対して必要最小限の干渉しかしないというポリシーで書いてあるので、Class::C3とかを使ってないのです。
ソース見ればわかりますが、Class::C3を使うとnextという名前空間をこっそりと追加してたりするので、それを避けたかったのです。
Class::Componentのソースを見ればわかる通り、徹底的に不要な物を隠そうとしてる為ごちゃごちゃしたコードになってます。

ここまでがClass::Componentの事情の話、ここからはClass::ComponentとNEXTの付き合い方について。

Class::Componentは単体では何もやってくれないモジュールで、use Class::Componentしてからモジュールを作った時に初めて役に立ってくれます。
大まかに言うとClass::Componentを使うモジュールには3人の関係者が発生します。

  1. Class::Component作者
  2. Class::Componentを使ったMyAppというモジュールの作者
  3. MyAppの利用者

MyAppでNEXTを使う局面としては、MyApp::Component::*以下の名前空間で実装されたモジュールで使う事が多いでしょう、ここはCatalyst::Plugin::*と役割的には同等なのです。
MyApp::Plugin::*以下は、Plagger::Plugin::*のそれと近くNEXTが使えません。

だんだん答えが近づいて来ましたが、Class::Component的NEXTの作法としては、MyAppの作者がNEXTを多用するMyApp::Componentの管理や作成に責任を負い、MyAppの利用者はMyApp::Pluginのみ弄れる様にします。

CatalystやDBICの混乱をみるとNEXTを実行する場所が、それぞれ好き勝手にやっていて混乱してしまっているので、Class::ComponentではNEXTを使ったMyApp::Component::*を弄れるのはMyApp作者が全責任を追う事で混乱を防ごうという訳です。

もっというとClass::Component::Component以下(MyApp::Component以下も同義)はClass::Componentを利用したモジュールの作者の為に有るという事ですね。
Pluginは、最終的な利用者の為の選択肢を広めるためにあって、Class::Componentを利用するモジュール作者の利便性を上げる為にある。
Attributeに関しては省く。

MyApp利用者側はHookとかを活用すればMyApp::Componentを弄れなくても困る事は無い筈なので、こんなポリシーでもいけると思います。
要するにClass::ComponentではNEXT以外の方法を提供してるのでCatalyst等の様にNEXT地獄に堕ちる必要が無い訳ですね。

Posted by Yappo at 13:24 | Comments (0) | TrackBack

2007年12月25日

そろそろShibuya.pmについて一言いっとくか

10月1日にShibuya Perl Mongers テクニカルトーク #8Class::Componentに関してのプレゼンをして来ました。
このプレゼンより更に詳細な記事としてgihyo.jpの記事として公開されています。
gihyo.jpでの記事は、Class::ComponentどころかPerlのattribute周りを日本語で詳細に解説している唯一の記事だと思ってます。それくらい気合い入れて書いていたので(ry

で、なんでいまさらこんな事書いてるかというと、先日発売されたWEB+DB PRESS vol.42のたつをさんの記事にて、tech talk#8でのustream配信の件が紹介されていたからです。
今回はotsuneさんと自分でustream配信を担当したので、ちょうど良い機会なので勉強会をMacBookでustream配信する為のtipsを少し書きます。

配信チャンネルは2つ以上で

これは、スクリーンと講師を別にした方が良いという理由と、もし片方の配信予定者が遅刻して来た場合でも、配信不可能になるという事態は避けられるからです。

カメラは2つ用意

ちょっと上と被りますが、一人だけで配信する時には、メインをスライドにして、講師の全体像を左上にワイプして表示するのに必要です。このワイプ方式は結構評判よかったです。

MacBookは2つ以上持ってく事

予備機としての意味もありますが、今回は発表者件配信担当だった為に配信用と発表用のMacBookが必要になりました。

配信カメラはビデオカメラ推奨

MacBookで使える程度のWebカメラでは、どうしても解像度やらが悪くて画面が良くないのですが、DVテープとかで録画出来るビデオカメラをDV端子経由でMacBookに繋ぐと、ぐっと画質が向上します。

マイクにこだわるべし

できればコンプレッサーも持ってくと良いと思います。やっぱり内蔵のマイクは色々聞き取りにくいようです。

WEB+DB PRESS vol.42を買うべし

たつをさんの記事を熟読しましょう。

WEB+DB PRESS Vol.42
WEB+DB PRESS Vol.42
posted with amazlet on 07.12.25
WEB+DB PRESS編集部
技術評論社 (2007/12/22)
売り上げランキング: 114
Posted by Yappo at 23:48 | Comments (0) | TrackBack

GoogleのMapReduceをいまさら妄想した

ブームとかそういうのはあんまり関係無いけど、MapReduceについての妄想だけしてみた。

主要コンポーネント

MapReduceには大体6つのパーツから構成される。

clientshellから叩かれるコマンド的な何か
manager各種 worker を管理する。といっても投げっぱなしで結果がいつまでも帰ってこなかったらworkerを捨てるだけ。同じjobを複数のworkerに投げてる。
map workermapの処理
combinermapの直後に実行出来るreduceのような物、無くても構わない、出力はmapと同じ?
shuffle(Group by Key)map workerから帰って来たkey/valueを集約する
reduce workerreduceの処理
fs分散システムに対応したfsと、local disk

処理内容

mapに対しては任意のデータが与えられる。 mapはkeyとvalueからなる大量のデータを戻す。 shuffleにて、全てのmapのkeyをまとめあげて、keyごとにreduce workerにkeyとvalue listを渡す。 reduceは、受け取ったkey/value listを処理する。

key/valueなデータに特化したPlaggerってことで間違いないのかなぁ? mapperで大量のデータから必要な物をフィルタリング(Subscription,Aggregator)して、reducerで実際の処理(Filter,Publish,Notify)を行うというPlaggerみたいな感じ。

全てのmapやreduceに大しての各workerの仕事量は平均的になる様にバランス良く配置する。 多分、mapやreduceの直前で、それぞれのjobの大きさを計測してmanagerに渡したりしてるのかな。

shuffuleなんかはBig Tableとか使ってるのかもしれんね。 それか集計処理自体MapReduce使ってたり?

map workerの処理が全て終わったら reduce worker が走り出す。 これは、あるいみ無駄な気もするからmap workerが終わるのを待たずにreduce worker走らせてるだろうなぁ。(どうもそうでもないらしい。) mapとshuffuleは同時に処理出来るけど、reduceは他と一緒に処理出来ないそうな。key/value単位で処理するというMapReduceの設計的な制約かな? map,reduceが終わりそうになったら、まだ終わってないworkerのjobをそのまま空いてるwokerに投げて速く終わったworkerの方のresultを採用する事で、途中でworkerがコケても泣かないですむ。

mapとreduceの粒度は細かくした方がよい。 mapperでserialize、reducerでdeserialize。 mapだけ繰り返し呼びたい時はreduceからmapを呼び出す。

オレオレ実装するとしたら

この仕組み自体は対した事無くて、肝は大量のデータを、たくさんのmap workerやreduce workerへjobを投げたりresultを受け取る仕組みとshuffleする処理にある。 ちゃちいものだったらDanga::Socketとかで実装出来るレベルっぽいな。 もちろんGFSも肝だけど、memcachedとかでとりあえずいい気がする。(可用性おいとくという事) というかMapReduce自体もGearmanで構成出来たりしね?

実際問題としてオレオレでMapReduce作る時に考える事は、データとコードを各worker serverに送る仕組みを真っ先に考えなければいけない。 単純にjobを分散出来た所で、それはMQとかに毛が生えた程度の面白さしかないから、分散ストレージ的な物もセットにしないとオレオレMapReduceもどきとは言えないだろうけど、memcachedとか使えば解決するよね?よね?

CPANにMapReduceってモジュールが有ったんだけど、何故か削除されてる。。。backpanには残ってる。

もっとも忘れてはならないMapReduceの肝は、1 serverで並列処理をしてCPUがmulti coreしてる恩恵を受ける為に有るのではなく、大量のworkerを使う事によって大量のメモリを利用したり、大量のdiskを使う事によるi/o負荷を分散させる事に意味が有る。 それなんで、WebからMapReduce使う用な事はないのかね?

でも少数serverでMapReduceやったって良いじゃないか!

Posted by Yappo at 21:31 | Comments (1) | TrackBack

2007年12月20日

ShipItつかわなくて良いのは小学生まで

超クールな CPAN リリースツール 1 選。ShipIt がスバラシイ件 - TokuLog 改め だまってコードを書けよハゲが火種になってるけど、今ShipItが熱い!
という事でちょっと前からShipItに移行してます。 一昨日辺には、オレオレpmsetupもplaggerからコピペしてきたリリースツールを消してShipItしてます。
http://coderepos.org/share/changeset/3295

結構どうでも良いBKがあって、cpanに上げる時にShipIt::ProjectType::Perlを利用してperl Makefile.PLするフェーズがあるのですが、ShipIt::ProjectType::Perl::MakeMakerの実装を見てわかるとおり

sub prepare_build {
    my $self  = shift;
    system("perl", "Makefile.PL") and die "Makefile.PL failed";
}
とかなってるんですよね、要するにperl5.10とかを/usr/local/perl5.10.0/bin/perl とかに置いていた場合には、5.10のperlコマンドを使ってくれない。

そんな感じなので、danをshipitする時にはひと工夫をして(5.9.5以上じゃないとmakeできない)

PATH=/usr/local/perl5.10.0/bin:$PATH shipit
してあげて先に5.10のperlを見つける様にして動かしてあげて解決。
shipitは基本/usr/bin/perlから起動されるので5.10の環境にShipIt入れなくてもうまくいきます。

ちなみにShipItはsoftware release toolという要約の通りCPAN以外へのリリースも出来ます。
標準だとCPANしか無いけどShipIt::Step以下の名前空間にモジュールを置いていけば色々と拡張できます。
皆が大好き跳ね込むが色々うpってるので参考にどうぞ。

JSとか、そういうののリリースツールとかで使うと面白げ

Posted by Yappo at 14:14 | Comments (0) | TrackBack

2007年12月19日

perl 5.10 and perl 20 years old

perlが20歳になったのと、5.10.0がめでたくリリースされたので、お祝い代わりにdanをCPANにuploadしました。

くわしい説明はYappoLogs: dan - リテラルとかを読まなくなるプラグマ作ったにて

Posted by Yappo at 18:22 | Comments (0) | TrackBack

2007年12月12日

overloadのreblessとRHLのoverloadが遅いパッチ

fbis++
overloadと再blessの問題 - Unknown::Programming

でも現状の対策としてはどうすればいいのかちょっと思いつかないですね。リファレンスを捜索してoverloadフラグを立てる、なんてことをするモジュールとか作れるのかしら・・・。
この段落を見て全てが繋がった!
fbisすげーよ!まじすげーよ!

以前騒がせたFedoraCoreやCentOS系の遅いPerlのパッチの件で、overloadすると極端に遅くなるって話題ですが、問題のpatchのコメントに注目すると

This is a hack cope with reblessing from class with overloading magic to one without (or the other way).
まさしく、今回id:fbisが指摘した事へのパッチだった訳ですね!

長年の疑問がすっきり解消しました!
で、v5.9.4から解消されたという事で、もしや?と思ってv.5.10.0RC2で調べてみました。

$ perl /tmp/overload.pl 
Benchmark: timing 1000000 iterations of not overload, overload...
not overload:  2 wallclock secs ( 1.51 usr +  0.00 sys =  1.51 CPU) @ 662251.66/s (n=1000000)
  overload:  1 wallclock secs ( 1.48 usr +  0.00 sys =  1.48 CPU) @ 675675.68/s (n=1000000)
おお!変わってない!

Posted by Yappo at 19:44 | Comments (0) | TrackBack

2007年12月10日

PowerEdge SC440をQuad Core + 8GBメモリで動かす

はてなのnaoyaさんの日記でQuad CPUでxenを動かしてるという事が書いてあったので、自宅でもはてなのサービスをまねた構成をしたくなったので人柱やってみました。
タイトルの通り、1万5千円で買ったSC440をDELL公式のスペックよりもオーバースペックな事をして動かしました。

まずは、メモリから。
ミラクルリナックスの中の人曰くマザーボードの仕様的には8Gまでいけて、8Gちゃんと認識したという事で、以前から買い漁ってたTranscendの1GB DDR2 667MH ECC メモリの 2GB 番の TS256MLQ72V6U 4枚買って来て刺した所 BIOSでは8G認識してるのにOS上げたら3.5Gにも満たなかった、よく考えて64bit番のCentOS入れたら無事8G認識しました。

次はCPU、SC440はXEON 3040 というFSBが1066MHzのCPUが刺さるので、同じFSBの4コアCPUのQ6600をさっき買ってきたら普通に認識して/proc/cpuinfo的にも4CPUの扱いになりました。
ただ、購入したSC440はファン無しのヒートシンクなしマシンなので、調子に乗ると大変な事になりそうで恐い。

そういえば、自宅を整理してちゃんとPowerEdgeを棚に載せました。
PE_SC440_1.jpg
PE_SC440_2.jpg
PE_SC440_3.jpg
PE_SC440_4.jpg

今時のWEBエンジニアは、このくらいの環境を自宅に置いとかないとだめだと思う。

併せて読みたい:お家NOC

インテル Core 2 Quad Q6600 2.40GHz BOX BX80562Q6600
インテル
売り上げランキング: 8565
おすすめ度の平均: 5.0
5 なかなか爆速です。

Posted by Yappo at 00:13 | Comments (4) | TrackBack

2007年12月07日

Tracで自分の追いかけたいディレクトリの変更ログだけを簡単に取り出す為の3個の手順

リポジトリへだんだんと全体のcommit流量が増えて来ると自分の突っ込んだプロジェクトに誰かがpatchを書いても気づかない事が出て来ます。
例えばCodeReposなんかがそうで、困っていた訳です。

さっき知ったんですが、tracは各ディレクトリ毎のコミットログをRSSで出せるので、これを活用して目的を達成します。
具体的にはtracのtemplateを少し追加するとRSS Auto Discoveryできるようになるので、まずはAuto Discovery出来るようにしました。

次は、誰がどのプロジェクトに関わってるかをまとめる訳ですが、これはXOXOというMicroformatsが使えるので、各コミッタページにXOXOで自分のプロジェクトディレクトリへのリンク集を書きます。
自分の場合はhttp://coderepos.org/share/wiki/Committers/yappoこんな感じです。
Tracに生HTMLを書かなければいけないのですが

{{{
#!html
<ul class="xoxo">
 <li><a href="http://coderepos.org/share/browser/lang/perl/Acme-Jyogakusei">Acme::Jogakusei</a></li>
 <li><a href="http://coderepos.org/share/browser/lang/perl/Acme-tsundere">Acme::tsundere</a></li>
 <li><a href="http://coderepos.org/share/browser/lang/perl/Class-Component">Class::Component</a></li>
 <li><a href="http://coderepos.org/share/browser/lang/perl/dan">dan</a></li>
</ui>
}}}
こうする事で生HTMLがかけました。

さぁ準備は整いました、あとはfeedをまとめるだけです。
これはもうPlaggerという優秀な裏ソフトがあるので活用しない手は無いです。
configはhttp://coderepos.org/share/browser/config/plagger/coderepos-commiter-smartfeeds.yamlこんな感じでおkでしょう。
出来上がったFeedはhttp://tech.yappo.jp/coderepos-yappo.xmlにあります。

ね、簡単でしょう?

Posted by Yappo at 16:13 | Comments (0) | TrackBack

2007年12月01日

CodeReposにうpする事は恐くないよ

ユーザ避けとしてのSubversion - blog.fuktommy.comのミラー

だから早いうちからソースを公開するのはいいことだと思うんですけど、 問題もあるんですよね。 ソースはできるだけ早くから公開したいんですけど、 実際にユーザが使うのは「ひととおりできあがった」あとにしてほしいんです。 早くから使われると、当然完成度も低いですし、 仕様の変更だってちょくちょくあるから、 「完成度は低いし、バージョンアップのたびに互換性なくなるし、つかえねー」 という評判が立ってしまう。
これは二つの問題を混ぜて考えてしまっている。

ソースを公開する=将来のユーザになる層に告知するという考え方がまず間違っています。
そりゃ2chとかでスレ立ててやっちゃえば、混ぜこぜになっちゃうのもしょうがないかもしれないすけど、ひげぽんとかの成功例もあるからプロジェクトの切り盛り次第かも。

って話が脱線したけど、CodeReposにコードを上げる事は恐い事ではありません。
まず、CodeReposに作りかけのコードを上げた程度じゃ将来のユーザーは気づく事が出来ません。黙ってcommitする分には、commit logを追いかけまくってる人くらいしか気づかないので問題ありません。
作りかけのコードを上げて、最終的な利用者に使われて評判を落としたくなければ、アナウンスしなければいいんですよ。
じゃぁ、どうやって仲間を見つけるかって?
commitしたらlogに残るから、それみて面白そうなら蟻のごとく皆たかって来るし#codereposにでもさらっと流せばlog追いかけてない開発出来る人とかが気にしてくれるかもしれない。
その程度で最初はコツコツやってけば良いんですよ。最初はスルーされてたけど自分一人で頑張ってるうちに他人から見ても面白い物に進化してたら集まって来るしね。
そしたらあっと言う間に完成度が上がって、勝手に広報してくれる人も出て来るよ。mobircのようにね。

この辺りの他人の評価を気にしすぎるのが日本人の短所でも長所でもあるけど公開されなきゃ存在しないと同じなんだから、たかだか最初の評価気にする程度で出さないのはとても損な事だと思うのですね。
もちろん戦略的に出していく事に関しては、各人の自由なわけでめちゃくちゃ尊重しまくるのは当然なのですが、今回はうpしずらい理由がちっちゃい事なら、そんなの気にせずコミットちゃえよ!you!って感じです。

まあ、そういうわけだから、id:naoyaとid:jkondoには是が非でもhtpasswdを送って欲しいし、未完成な状態でもいいからサントゥニーを klab の仙石さんははやくCodeReposにcommitしてほしいということでした。

そして、オレも作りかけにも満たないTemplate::Classをコミットしたよ!

Posted by Yappo at 19:00 | Comments (0) | TrackBack