Tengのco-maintainer変更のお知らせ / perl / 2013-05-28 / permalink / Comments このエントリーをはてなブックマークに追加

背景としては、私自身がTengのメンテナスに時間を割くことができず、利用者からの要望に答えることが難しくなってしまった為です。


せっかくpull-requestを送ってもらっても気づくこともできず長期間放置してしまったり、
仕様に関する議論もしっかりできず、これでは死んだプロジェクトとなってしまうと思いました。


後任としては現在Tengを実際に利用しており、意欲的にpull-requestを送ってくれているcho45さんにお願いすることとなりました。
cho45さんであれば安心して後をお任せできると確信しております。


cho45体制のTengをこれからも応援よろしくお願い致します。


:D


Redis の SortedSets 同点問題について / redis / 2013-03-06 / permalink / Comments このエントリーをはてなブックマークに追加

WEB+DBのRedis特集をひろせまさあきさんと共同で執筆しました。


WEB+DB PRESS Vol.73
WEB+DB PRESS Vol.73
posted with amazlet at 13.03.05
設樂 洋爾 白土 慧 奥野 幹也 佐藤 鉄平 後藤 秀宣 mala 中島 聡 堤 智代 森田 創 A-Listers はまちや2 大和田 純 松田 明 後藤 大輔 ひろせ まさあき 小林 篤 近藤 宇智朗 まかまか般若波羅蜜 Mr. O
技術評論社
売り上げランキング: 335


買ってください。


このRedis特集の第五章では、Redisを使ったリアルタイムランキングについて取り上げたのですが、
記事中にある同点問題について、執筆時から状況が変わりましたのでupdateします。


記事中では、RedisのSortedSetsはスキップリストというアルゴリズムを使っている特性上、
同じスコアが同じランクで扱えない問題があると記載しましたが、
同点問題についてパッチが送られ取り込まれる流れになっています。

https://github.com/Sylvain-Royer/redis/tree/unique_ties


このパッチが当たったRedisを利用すると、

see) https://github.com/Sylvain-Royer/redis/blob/unique_ties/tests/unit/type/zset.tcl#L193

        test "ZRANK unique - $encoding" {
            r del zranktmp
            r zadd zranktmp 10 x
            r zadd zranktmp 20 y
            r zadd zranktmp 20 z
            r zadd zranktmp 30 d
            r zadd zranktmp 30 e
            r zadd zranktmp 40 f
            assert_equal 0 [r zrank zranktmp x unique]
            assert_equal 1 [r zrank zranktmp y unique]
            assert_equal 1 [r zrank zranktmp z unique]
            assert_equal 3 [r zrank zranktmp d unique]
            assert_equal 3 [r zrank zranktmp e unique]
            assert_equal 5 [r zrank zranktmp f unique]
            assert_equal "" [r zrank zranktmp foo unique]
        }


こんな感じで同点を同じランクとして扱うことができるようになります。
素晴らしいですね!


みんなRedis使うといいよー


(追記)

ちなみにこのRedisのパッチを書いたのは、DeNA San FranciscoのEngineerです。
Great!
今usに着てて本人に所属を公開していいか?って聞いたらいいよーって言ってくれたので
updateしておきます。


簡易2WaySQL / perl sql / 2012-04-20 / permalink / Comments このエントリーをはてなブックマークに追加

2WaySQLというものがあるわけです。
2WaySQLについてはhttp://www.slideshare.net/t_wada/tokyo-rubykaigi-01-twada-presentation
を参考にしてもらうとして、
超絶簡単に説明すると、実行可能なSQLを書いておいて(where句の値もデフォルト値を書いておくので実行可能となる)
プログラム側で良い感じにプレスホルダーとかに置き換えて値を良い感じに置き換えます。


どんなSQLかというと

SELECT * FROM USER WHERE id = /*:id*/1 OR name = /*:name*/'nekokak' OR ids IN /*:ids*/(2,3,4)

こういう感じ。

普通に実行可能ですよね。
これを、

my $sql = q{SELECT * FROM USER WHERE id = /*:id*/1 OR name = /*:name*/'nekokak' OR ids IN /*:ids*/(2,3,4)};
$bind = +{
    id => 10,
    name => 'zigorou',
    ids => [qw/11 12 13/],
};
my ($stmt, @bind) = two_way_sql($sql, $bind);

こんな感じのメソッドを通すと

$stmt; # SELECT * FROM USER WHERE id = ? OR name = ? OR ids IN (?,?,?)
@bind; # [10, 'zigorou', 11, 12, 13]

という感じに変換されます。


実装はこんな感じ。

sub two_way_sql { 
    my ($sql, $bind) = @_; 
    my %named_bind = %{$bind}; 
    my @bind; 
    $sql =~ s{/\*\s?:(\w+)\s?\*/(\S+)}{ 
        Carp::croak("$1 does not exists in hash") if !exists $named_bind{$1}; 
        if (ref $named_bind{$1} && ref $named_bind{$1} eq "ARRAY") { 
            push @bind, @{ $named_bind{$1} }; 
            my $tmp = join ',', map { '?' } @{ $named_bind{$1} }; 
            "($tmp)"; 
        } 
        else { 
            push @bind, $named_bind{$1}; 
            '?' 
        } 
    }ge; 
    ($sql, @bind); 
} 


2WaySQLというとIFだったりLOOPだったり複雑なことができるんですが、はっきりいってそこまで複雑になったら
意味分からんくなるので、*あえて*実装はしてません。

こういう感じで実行可能SQLがあるのは結構いいんじゃないかなーとおもうました。


JPA理事 / perl life / 2012-04-19 / permalink / Comments このエントリーをはてなブックマークに追加

今期からJPAの理事となりました。
よろしくお願いします。


Fukuoka.PMで発表してきました! / perl / 2012-04-10 / permalink / Comments このエントリーをはてなブックマークに追加

と言う事で Fukuoka.PM #1 は JPA 講師派遣制度として発表してきました。



他の方のまとめ記事はこちら
http://yokoninaritai.hatenablog.jp/entry/2012/04/03/012440
http://spring-mt.tumblr.com/post/20696127846/fukuoka-pm

前日入したとたん屋台に連れて行ってもらったり、深夜にラーメンに付き合っていただいたりと
堪能することが出来ました。
福岡名物のラーソーメンも食べれたし満足ですた!
はやしさん++


自分は最近ぽちぽち作ってるClutchの発表をしてみました。
資料を https://github.com/yoshiki/markdown2impress で作ってエフェクトを多めにかけたら
酔う酔うと言われて(´・ω・`)ショボーン



自分はいままでHokkaido.PMやKyoto.PMそして今回Fukuoka.PMと地方PMに何度か参加したのですが、
SkinnyだったりTengだったりを使ってる人が多くてありがたい気持ちで一杯でした。
懇親会中にポスグレをTengで使うと使いにくいよーとか、last_insert_idのカラムがid決め打ちなのががが!
などのご意見いただいたりしたのでパッチとテストを正座して待ってる感じです。


福岡?ではRubyで仕事をするエンジニアを雇うと補助金的なのが支給される制度があったらしく、
Rubyエンジニアがおおいそうな。
Perlでもそういう試みができたらいいですね!とおもったけどそう単純にはいかないんだろうなとか。


今後も許す限り地方巡業してみようかなと改めて思うなどなど。


今後どっか行く時はワークショップとかいいかもなー。などなど。


兎に角、福岡は空港から近くてとても便利で暖かくて飯も美味しくて女性も美人が多くて素晴らしいところでした!


Clutch-0.04 released / perl clutch / 2012-03-26 / permalink / Comments このエントリーをはてなブックマークに追加

http://hirobanex.net/article/2012/03/1332719670
この記事をみてて、
Clutchにいくつか機能を追加してリリースしてるのを
紹介していなかったので簡単に書く。


リリース情報としては
・request_multiとrequest_background_multiメソッドを追加
・Clutch::Adminを一旦廃止
・Data::WeightedRoundRobinをcoreから外す
・プロトコルを変更(argumentはJSON一択)

といったところでしょうか。


request_multiとrequest_background_multi


まとめて複数のjobをリクエストできるようになりました。

my $res = $client->request_multi(
    [
        +{function => 'method1', args => 'hoge'},
        +{function => 'method2', args => 'hoge'},
        +{function => 'method3', args => 'hoge'},
    ]
);
$res->[0]; # method1 response
$res->[1]; # method2 response
$res->[2]; # method3 response


至って簡単ですね。
request_multiに渡す\@argsの順番通りにレスポンスを受け取れるので、
受け取ったレスポンスを何も考えなくて取り出せば良いですし、
worker側も特別responseを工夫しなくていいです。


また、workerは特別変更必要ありません。
clientが全て解決します。


request_background_multiも使い方は一緒です。


Clutch::Adminを一旦廃止

とりあえずもう少し落ち着いてから考え直すので一旦廃止。

Data::WeightedRoundRobinをcoreから外す

coreでは渡されたserversを順番にRRします。
Data::WeightedRoundRobinのような重み付けRRがしたい場合は

use Data::WeightedRoundRobin;
my $client = Clutch::Client->new(
    rr => 'Data::WeightedRoundRobin',
);


とすることで内部のロジックを差し替えることができますが、
まだとりあえずなのでいろいろ変わるかもしれません。


プロトコルを変更(argumentはJSON一択)

色々考えた結果JSONにしました。

$METHOD $FUNCTION $JSON_ARGS

と言った感じです。

普通に使う分には特に気にする必要はありません。


パフォーマンス

Benchmark: timing 10000 iterations of clutch, gearman...
    clutch: 6.67131 wallclock secs ( 2.71 usr  1.04 sys +  0.00 cusr  0.00 csys =  3.75 CPU) @ 2666.67/s (n=10000)
   gearman: 14.8758 wallclock secs ( 5.15 usr  0.72 sys +  0.00 cusr  0.00 csys =  5.87 CPU) @ 1703.58/s (n=10000)
          Rate gearman  clutch
gearman 1704/s      --    -36%
clutch  2667/s     57%      --

まぁgearmandを挟まない分当然早いですね。

こんな感じで鋭意開発継続中です。
今月末のFukuoka.PMでClutchの話をやる予定なので、福岡近郊の人や、近郊じゃない人も参加してはいかがでしょうか。


Kyoto.pm#01のQudoの発表についてのレス / perl qudo / 2012-03-19 / permalink / Comments このエントリーをはてなブックマークに追加

@shiba_yu36さんがQudoの発表をするというのがKyoto.pmに行く強いきっかけになったので、
一番まえの席に陣取って発表を見ていました。
@Yappoさんのように発表者が発表している最中にtwitterという公開の場でlive disをするのはためらわれたので、
今あらためて@shiba_yu36さんの発表内容を振り返りつつ突っ込んでみたいと思う。
disじゃないよ。


@shiba_yu36さんの発表資料
http://shibayu36.hatenablog.com/entry/2012/03/18/230525


拡張性について


Job Queueを使う上でTheSchwartzではなくQudoを使った利用に、
「TheSchwartzはオーバースペック」
「たくさんカスタマイズ詩たいわけではない」

「Qudoがちょうどよさそう」

とあったのですが、Qudoは拡張性が高いことを目指したJobQueueです。
むしろTheSchwartzのほうがあいだにロジックを挿し込んだり、
シリアライザをStorable以外のものに変えたりするのが難しいです。


Clientの実装について

これはtwitterでポロリと言ってたんですが、
QudoのClientを用意する時は継承する必要はありません。
http://search.cpan.org/~nekokak/Qudo-0.0213/lib/Qudo.pm#SYNOPSIS
もちろんQudoのClient自体を拡張したい場合は継承することも可能です。


Job管理の仕組み自体をカスタマイズしようとすると難しい

ですね。
それはQudoもTheSchwartzも同じです。
おそらくそういう用途では自分でつくるか、Q4Mを使うなどの選択肢になるかとおもいます。
ただ、どういうJob管理にしたいのかにもよります。

いま私はQ4Mをよく使っているのですが、Jobをbulkで扱う場合なんかはInnoDBのtableを使って
独自実装にしています。

Jonkが本来そういう用途で考えていたのですが、ちょっと力尽きてます。

信頼性

信頼性に関しては、もちろんTheSchwartzのほうがQudoよりも多くつかわれていますし間違いないと思います。
Qudoに関しては自分の前職や前々職でバリバリつかってました。いまでもMF社では使っているというtweetも見かけましたし
現役でバリバリうごいてますね。
何を持って信頼性というかにもよりますが、TheSchwartzもQudoもバックエンドにMySQL(だったり他のRDBMSもあるが)をつかっているので
そこで大きな違いはないとおもっています。
むしろQudoのほうが、TheSchwartzよりもエラーの扱いをしっかりしているので、
リカバリーに強いと思っています。
exception_logテーブルだったりjob_statusテーブルだったり。
QudoはJobの処理に失敗したらexception_logテーブルに失敗したJob情報が格納されるので、
Qudo::Manager#enqueue_from_failed_jobを使えば、exception_logからJobをリカバリーすることもできます。


Qudoの失敗しているところ

・頑張って無駄に複数のRDBMSに対応しようとしたところ
・DBIx::Skinnyをつかってしまっているところ

が一番大きな問題だとおもっています。



今回@shiba_yu36の人が自分が作ったプロダクトの発表をしていてすごく緊張したと同時にすごく嬉しかったです。
ありがとうございました!
折角なのでもっとお話できればよかったなーと思っておりまする。


Kyoto.pm #01 に参加してきた / perl / 2012-03-19 / permalink / Comments このエントリーをはてなブックマークに追加

第一回のKyoto.pmに帰省を兼ねて参加してきました。

自分の発表資料は以下
http://nekokak.org/presen/kyoto01/

ORMとはといったような概論的なはなしをしながら、
最後は一緒にTengを開発しませんか?
といったかんじ。

プレゼン中でも触れていますが、今あまり(ほとんど)Tengの開発に注力できないので
新機能だったり、リファクタリングだったりが滞っています。
DBIx::SkinnyもTengも多くの人に使われるようになってきているので、
使っている人からの開発リソースの還元を受けたいなーとか
開発に関わりたいと思っているような人をうまく取り込みたいなーと考えています。


プレゼン後の懇親会で、Tengは必要最低限の機能にわざと絞ってるのに、
新機能開発ってどういうこと?
という質問を受けたのですが、Tengは自分の理想を完璧に形にできているわけではなく、
細々と治したい部分だったりが結構あるのです。
また、Tengのmeta data apiは中途半端な作りになっていて、
Schema 情報の内部をさわれそうで触れなくて、結局使い物になっていなかったりします。

そういうところを一緒にできたらなと。

ただ、方向性は明確で「ゴツくならない」なんですが、いろいろできそうだから機能足してみたとかは
やられがちなので、そのあたりはコミュニケーションを取りながら進めていきたいなと思っています。

とりあえず興味ある人は#dbix-skinny@irc.perl.orgにjoinするか
google group: https://groups.google.com/group/dbix-skinny
があるのではいってもらえれば。

また過去のTeng開発のときに話していたIRCのログなども適宜共有したり話たりはできるので
遠慮無く聞いてください。


Kyoto.pmは3,4ヶ月毎くらいに開催されるとのことで、機会があればまた参加してみたいなと思います。
今回は東京から自費で4名ほどきてましたが、みんな行動力があってすばらしいですね。


個人的には今月末にFukuoka.pmに参加するのですが、Kyoto.pmみたいにみんなあつまらないかなー。


Kyoto.pmおつかれやまでした!


Re: Perlで動的ディスパッチ/動的メソッド定義 / perl / 2012-03-05 / permalink / Comments このエントリーをはてなブックマークに追加

http://akiym.hateblo.jp/entry/2012/02/29/214856

package MyString;
use strict;
use warnings;

our $AUTOLOAD;
my %colors = (
    black   => '000',
    red     => 'f00',
    green   => '0f0',
    yellow  => 'ff0',
    blue    => '00f',
    magenta => 'f0f',
    cyan    => '0ff',
    white   => 'fff',
);

sub new { bless +{}, +shift }
sub AUTOLOAD{
    my ($method) = ($AUTOLOAD =~ /([^:']+$)/);
    (my $color = $method) =~ s/in_//;
    qq|<span style="color: #$colors{$color}">$color</span>|;
}
### don't autoload this
sub DESTROY { 1 }


こんなんとか


Fukuoka Perl Workshop #21 に JPA の 地域PM向け 講師派遣支援プログラム で参加してきます! / perl / 2012-03-04 / permalink / Comments このエントリーをはてなブックマークに追加

ということで、2012/03/31にFukuoka.PMに行ってきます。


去年のYAPC::AsiaでFukuoka.PMの方々とお話する機会があり、
北のHokkaido.PMの次は南のFukuoka.PMだろ!ということで行きます。


http://atnd.org/events/25550


当日はJPA代表理事であるlestrratさんも参加され、
まだ若干余裕があるようですので、福岡だけでなく近県の方々でお時間ある方はどしどしご参加ください。


予定では前日の03/30に福岡入りして、04/01のお昼に帰ります。


支援2回目なので、なるべく安く済ませて他の人に回せるように注意する所存でございます。