NEXT>
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回目なので、なるべく安く済ませて他の人に回せるように注意する所存でございます。
Kyoto.pmが立ち上がったと聞き、更に発表予定の中にQudoが入ってたり、生まれも育ちも京都な私が#01に参加しないなんてありえない！
ということで、急遽参加することとしました！
当日は捗る達人のYappoさんがJPA の 地域PM向け 講師派遣支援プログラムで参加されたり、関東近辺からの参加者もあるようなので、お時間ある人は来ると良いと思います。
参加枠が既に埋まってるみたいなんですが、発表者枠はまだ開いているようなのでhttp://www.atnd.org/events/25441発表者枠でねじ込み参加すればいいんじゃないかな。
ということでKyoto.PMな方々どうぞよろしくお願いします。
Just Ideaなんですが、Forkして子プロセスに処理を行わせる事はよくやることなんですが、実際の全ての処理にある程度時間がかかる場合に、現在走っている処理を一時停止したり再開したりすることができるとおもろいかなぁとおもったのでサクっと書いてみた。
#! perl use strict; use warnings; use Parallel::ForkManager; use Time::HiRes qw(sleep); my $pm = Parallel::ForkManager->new(10); my $pause=0; $SIG{HUP} = sub { $pause ^= 1 }; my $finish=0; $SIG{TERM} = sub { $finish = 1 }; sub pause { $pm->wait_all_children; while (1) { return unless $pause; return if $finish; warn 'pause....'; sleep(0.5) } } while (1) { warn "parent process id: $$"; pause() if $pause; last if $finish; my $pid = $pm->start and next; warn "in progress...: $$"; sleep(2.5); $pm->finish; } $pm->wait_all_children; warn "finished all process..";
このプログラムを使うと、
$ kill -HUP $PID
と打ち込むと、処理がpause状態に遷移します。
そして再び
と打ち込むと、処理が再開されます。
また
$ kill -TERM $PID
と打ち込むと、処理を終了させることができます。
こんなんどうですかねぇ
