Subscribed unsubscribe Subscribe Subscribe

ローカルに立ててる memd に対しても get_multi するべきか

結論:するべき。

リモートの memd はつなぎにいくコストが高いから、 memd のアクセスは get_multi を用いてまとめて行なうべき。 http://blog.64p.org/entry/20070503/1178144869

しかしローカルで立ってる memd ならつなぎにいくコストは微小だろうし、 get_multi は使わなくて良いのでは? と思ったので、ベンチ取ってみた。

ベンチスクリプト -> https://gist.github.com/Cside/0172e511dd910bb141bd

key の数: 5 のとき

             Rate       get get_multi
get        9091/s        --      -82%
get_multi 50000/s      450%        --

key の数: 50 のとき

             Rate       get get_multi
get         909/s        --      -95%
get_multi 20000/s     2100%        --

key の数: 500 のとき

            Rate       get get_multi
get       85.5/s        --      -97%
get_multi 2564/s     2897%        --

Test::Base::SubTest というモジュールを作った。またはテストケースとテストコードは分離されていたほうが嬉しい話

perl

自分は Test::Base が好きでよく使うのだけど、subtest 的な、テストのグルーピングができないのがずっっっと不満だったので、Test::Base::SubTest というモジュールを書いた。

以下の様な拡張記法が使えるようになる。### でsubtestの 1 単位を表現する。

use Test::Base::SubTest;
filters { input => [qw(eval)] };
run_is input => 'expected';
done_testing;

__DATA__

### subtest 1
    ### subtest 1-1
        === test 1-1
        --- input:    4*2
        --- expected: 8

        === test 1-2
        --- input :   3*3
        --- expected: 9

    ### subtest 1-2
        === test 2-1
        --- input:    4*3
        --- expected: 12

実行する

f:id:Cside:20140115222211p:plain

ところで

僕が Test::Base 好きなの、テスト「ケース」とテスト「コード」をちゃんと分けて書けるからなんだけど(別に Test::Base 使わなくても分けられるけど)、これって僕は大事なことだと思っている。

テストケースとテストコードが混ざってるコードだと、たとえばケースの抜け漏れだけレビューしたいときに、コードの中からケースを目 grep しないといけないのが、レビュワーの負担になる。

Test::Base だと、たとえばテストケースをレビューしてもらいたいときは、 __DATA__ 以下だけコピペして見てもらえばいい。まぁ Test::Base じゃなくてもいいんだけど、とにかく自分はテストケースとテストコードを明確に分けたテストを書くように心がけている。

テストを書くこと自体も大事だけど、障害を避けるためにはカバレッジがもちろん重要。であれば、何をカバーしているテストなのかを明確化するために、カバーしている事柄をすっと理解できるようなテストの書き方をするべきではなかろうか。

Data::Validator のようにコマンドラインオプションをパースするやつを作った

perl

Getopt::TypeConstraint::Mouse - A command line options processor uses Mouse's type constraints - metacpan.org - Perl programming language

in your script

#!perl
use Getopt::TypeConstraint::Mouse;
 
my $options = Getopt::TypeConstraint::Mouse->get_options(
    foo => +{
        isa           => 'Str',
        required      => 1,
        documentation => 'Blah Blah Blah ...',
    },
    bar => +{
        isa           => 'Str',
        default       => 'Bar',
        documentation => 'Blah Blah Blah ...',
    },
);
 
print $options->{foo}, "\n";
print $options->{bar}, "\n";

使う

$ perl ./script.pl --for=Foo --bar=Bar
Foo
Bar

$ perl ./script.pl
Mandatory parameter 'foo' missing in call to (eval)

usage: script.pl [-?] [long options...]
	-? --usage --help  Prints this usage information.
	--foo              Blah Blah Blah ...
	--bar              Blah Blah Blah ...

コードは 99.9% MouseX::Getopt と同じです。

経緯

以下の条件を満たすコマンドラインオプションパーサーを探していた。

  1. Mouse の型を指定できる
  2. バリデーションにこけたら Usage を勝手に生成して出力してくれる
  3. PadWalker に依存しない(これさえ無ければ Smart::Options がドンピシャだった)

と、twitter で、つぶやいたら Songmu さんに MouseX::Getopt を教えていただいた。

MouseX::Getopt - A Mouse role for processing command line options - metacpan.org - Perl programming language

これは上の要件を満たしているのだけれど、コマンドラインオプションを解析するためにクラスを定義するのが個人的にはあまり直感的ではなく、 Data::Validator のようなインターフェイスで使いたかった。なので MouseX::Getopt の基底クラスを使ってインターフェイスだけ異なる Getopt::Constraint::Mouse というモジュールを作った。