NEXT>
背景としては、私自身がTengのメンテナスに時間を割くことができず、利用者からの要望に答えることが難しくなってしまった為です。
せっかくpull-requestを送ってもらっても気づくこともできず長期間放置してしまったり、仕様に関する議論もしっかりできず、これでは死んだプロジェクトとなってしまうと思いました。
後任としては現在Tengを実際に利用しており、意欲的にpull-requestを送ってくれているcho45さんにお願いすることとなりました。cho45さんであれば安心して後をお任せできると確信しております。
cho45体制のTengをこれからも応援よろしくお願い致します。
:D
WEB+DBのRedis特集をひろせまさあきさんと共同で執筆しました。
買ってください。
この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というものがあるわけです。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の理事となりました。よろしくお願いします。
と言う事で 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でもそういう試みができたらいいですね！とおもったけどそう単純にはいかないんだろうなとか。
今後も許す限り地方巡業してみようかなと改めて思うなどなど。
今後どっか行く時はワークショップとかいいかもなー。などなど。
兎に角、福岡は空港から近くてとても便利で暖かくて飯も美味しくて女性も美人が多くて素晴らしいところでした！
http://hirobanex.net/article/2012/03/1332719670この記事をみてて、Clutchにいくつか機能を追加してリリースしてるのを紹介していなかったので簡単に書く。
リリース情報としては・request_multiとrequest_background_multiメソッドを追加・Clutch::Adminを一旦廃止・Data::WeightedRoundRobinをcoreから外す・プロトコルを変更（argumentはJSON一択）
といったところでしょうか。
まとめて複数の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も使い方は一緒です。
とりあえずもう少し落ち着いてから考え直すので一旦廃止。
coreでは渡されたserversを順番にRRします。Data::WeightedRoundRobinのような重み付けRRがしたい場合は
use Data::WeightedRoundRobin; my $client = Clutch::Client->new( rr => 'Data::WeightedRoundRobin', );
とすることで内部のロジックを差し替えることができますが、まだとりあえずなのでいろいろ変わるかもしれません。
色々考えた結果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の話をやる予定なので、福岡近郊の人や、近郊じゃない人も参加してはいかがでしょうか。
@shiba_yu36さんがQudoの発表をするというのがKyoto.pmに行く強いきっかけになったので、一番まえの席に陣取って発表を見ていました。@Yappoさんのように発表者が発表している最中にtwitterという公開の場でlive disをするのはためらわれたので、今あらためて@shiba_yu36さんの発表内容を振り返りつつ突っ込んでみたいと思う。disじゃないよ。
@shiba_yu36さんの発表資料http://shibayu36.hatenablog.com/entry/2012/03/18/230525
とあったのですが、Qudoは拡張性が高いことを目指したJobQueueです。むしろTheSchwartzのほうがあいだにロジックを挿し込んだり、シリアライザをStorable以外のものに変えたりするのが難しいです。
これはtwitterでポロリと言ってたんですが、QudoのClientを用意する時は継承する必要はありません。http://search.cpan.org/~nekokak/Qudo-0.0213/lib/Qudo.pm#SYNOPSISもちろんQudoのClient自体を拡張したい場合は継承することも可能です。
ですね。それは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をリカバリーすることもできます。
・頑張って無駄に複数のRDBMSに対応しようとしたところ・DBIx::Skinnyをつかってしまっているところ
が一番大きな問題だとおもっています。
今回@shiba_yu36の人が自分が作ったプロダクトの発表をしていてすごく緊張したと同時にすごく嬉しかったです。ありがとうございました！折角なのでもっとお話できればよかったなーと思っておりまする。
第一回の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は３，４ヶ月毎くらいに開催されるとのことで、機会があればまた参加してみたいなと思います。今回は東京から自費で４名ほどきてましたが、みんな行動力があってすばらしいですね。
個人的には今月末にFukuoka.pmに参加するのですが、Kyoto.pmみたいにみんなあつまらないかなー。
Kyoto.pmおつかれやまでした！
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 }
こんなんとか
ということで、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回目なので、なるべく安く済ませて他の人に回せるように注意する所存でございます。
