nDiki : 2011年06月08日

2011年6月8日 (水)

レビュー】リーズナブル価格の突っ込み系 iPad 2 ケース

naney:5823633784

昨日届いた iPad 2、

  • スマートフォンほどヘビーな環境下におかない。
  • 自分でバッテリー交換できないとか自分でメンテして長く使う感じじゃない。
  • Apple 製品にケースとか保護フィルムとか無粋。

かなと思って裸で使おうと思ってる。 大切にしない訳じゃないけど、ほとんど自腹じゃないこともあってあまり追加投資もしないつもりだし。 せっかくだしガシガシ使いたい。

ただあれだけ液晶面が大きいと、その辺に置いておいた時に落下物とかで破損とかありそうでちょっと不安。 と思って、ひっくり返して ThinkPad X200 の上に置いておいたら、今度は滑って落ちてたし。 それにさすがにバックに入れる時は多少は保護しないといけないなと。

ということで安めのケースを探してみた。 店頭で見つけたのがサンワサプライiPad2スリップインケース PDA-IPAD23G。 金属・プラスチック部品がないので iPad 2 を傷つけることなくさっと出し入れできる。擦り傷防止にはちょうどよさそげ。 自分は持っていないけれど iPad Smart Cover をつけたままでも入れられるとのこと。

バッグに入れておくにも、ミーティングにいく時に RHODIA と一緒に持って歩くのにもいい感じ。 しかし iPad 2 って着痩せするタイプなんだな。ケースに入れた方が薄く小さく感じる。

SANWA SUPPLY iPad2スリップインケース グリーン PDA-IPAD23G


[ 製品レポート ]

スポンサード リンク

require_ok してテスト可能な Perl スクリプトを書く

ちょっとしたものをのぞいて、Perl プログラムはアプリケーション部分も App 的 Perl モジュール(.pm)に入れて、実行するスクリプトファイル (.pl) では use して new して run するだけにしている。

 #!/usr/bin/perl

 use warnings;
 use strict;

 use MyApp; exit MyApp->new->run;

@ARGV の処理は new から呼ばれているプライベートメソッドの中で local @ARGV してから、Getopt::Long::GetOptions あたりで解析処理をしている。

でテストスクリプトではこの MyApp を use_ok して local @ARGV = qw(引数組み合わせパターン...) した後に new を呼んだ結果を検査するようにしていた。

そんなところ今回「.pm の中で @ARGV いじるのやっぱり気持ち悪くない?」っていう意見をもらった。気持ちはわかる。ただ

 MyApp->new(@ARGV)->run;

のように .pl 側で受け取ったものを解析すれば?」いいかというと、直接 @ARGV を使わない Getopt::Long::GetOptionsFromArray は 2.36 からしかなくて、古いバージョン の Getopt::Long でも動くようにすると結局 local @ARGV になってしまうのである。

また「@ARGV の解析は .pm の方には入れたくない」っていう意見もあったので、今回はそれらのコードは .pl 側に追い出すことにした。

そうすると次の課題は .pl にある @ARGV の解析処理のテストはどう書けばいいかなと。.pl ファイルを require したらスクリプトが走っちゃうし。試行錯誤していたらマスタリング Perl で紹介されている caller(0) を使う方法を教えてもらった。

caller(0) で直接実行されたのか、require されたのかで処理を変える

 スクリプトファイル(.pl)

 #!/usr/bin/perl

 package App;
 # スクリプトの実行開始エントリ
 sub main {
   # ここに実行したい処理呼び出しを書く。
 }

 main() unless caller(0);

こうするとこのスクリプトファイルを直接実行した場合は main サブルーチンが実行され、他から require された場合は main は実行されないというようにすることができる。前者の場合は caller(0) は undef を返し、後者は 'main' (あるいその他のパッケージ名)が返されることを利用している。

これでテストファイルの中でこのファイルを require_ok できるようになるので、あとは各サブルーチンのテストを書けばよい。

pod2usage の exit を回避

それから Pod::Usage を使っているんだけれど、テストでは Pod::Usage::pod2usage で exit されてしまうと困るので exit が何もしないようにしておく。テストスクリプトでは以下のようにする。

 BEGIN {
   *CORE::GLOBAL::exit = sub {};
   require_ok('script/myscript.pl');
 }

これで myscript.pl のテスト中に pod2usage が exit を呼んでもスルーさせられる。 ただし本番では exit させたい pod2usage がある場合は、その後に制御が流れていっても問題がおきないようにプログラムを書いておく必要があるので注意。

pod2usage の STDERR 出力をチェック

それから pod2usage で期待するメッセージが STDERR に吐かれているかをテストするには STDERR をオープンしなおせばよい。

 {
   my $message;
   local *STDERR;
   open STDERR, '>', \$message or die $!;
   # ここで pod2usage がメッセージを出すことが期待されるテストを実行。
   like($message, qr/expected message/);
 }

以上、スクリプトのテストについての何点かのまとめ。

[ 6月8日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

follow us in feedly

月別インデックス
Process Time: 0.046821s / load averages: 1.97, 0.99, 0.65
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker