昔書いたGithub止まりのモジュールをほじくり返す – Test::Proc 篇

※このエントリはPerlアドベントカレンダー2018の5日目のエントリとなります。

CPAN(MetaCPAN)でモジュールを公開するということ

Perlでプログラムを書くことに慣れてくると、CPANモジュールを使うようになったり、もっと慣れてくると自分でPerlモジュールを作るようになり、最終的にはCPAN(今はMetaCPANですね)で公開するようになるかもしれません。私は過去にそのような道を歩んできました。

では私は過去にどんなモジュールを書いたのか。ひとまずMetaCPANに上がっているものを一部挙げると、 Otogiri(これはほとんど@tsucchiさんの力です), XML::Diver, Net::Azure::CognitiveService::Faceなどがあります。

PerlモジュールをMetaCPANで公開する前に

しかしながら、MetaCPANでモジュールを公開する前に気にかけておいて欲しいこととして、個人的には以下のような項目を挙げたいと思います。

  • そのモジュールを公開することで不快感を感じる人々が生じないか
  • そのモジュールはセキュリティ的に致命的な問題を抱えていないか
  • そのモジュールは新しい機能を提供してくれるか
  • そのモジュールはプログラミング体験をより幸せにしてくれるか
  • そのモジュールは従来の類似モジュールよりもパフォーマンスに優れるか
  • そのモジュールは従来の類似モジュールよりも依存性が削減されているか

もし上記について該当するかわからない場合は、ひとまずgithubに上げておきつつ、ブログやTwitter等で言及してみましょう。運が良ければ誰かが注目してくれて、レビューをしてくれるかもしれません。これらのことは、Perlモジュールの公開に及び腰になってしまわない程度に、気をつけるとよいのではないでしょうか。

CPANの歴史を少しだけ垣間見る

では、なぜこのように自律する必要があるのでしょうか。それを知るためには過去に目を向けることが重要です。

歴史を振り返ると、charsbarさんによるエントリでCPANは幼稚園児の砂場じゃないよねという、2008年当時、大変考えさせられたものがあります。若い方の中にはこのような歴史を知らない方もいると思いますが、是非とも同じ轍を踏まぬための知識として、知っておいていただければ幸いです。

また、まかまかさんによるPerl同人誌「Acme大全」には、「Acme大全2012」から毎回、巻末付録として「とあるAcmeモジュールの削除について」という章が設けられています(ブログにも同様のエントリがある)。

このように、MetaCPANへモジュールを公開する上では、ある程度その性質を律せられる側面があることは間違いないでしょうし、誰かがつらい思いをしないためにも必要なことであると私は思います。

それでも日の目を見ないモジュールもある

そんな事もあって、実際にはたくさんのPerlモジュールを作っていたとしても、実際にMetaCPANにて公開されるものはその一部でしかありません。ほかにもMetaCPANに公開するのが怖いとか、作者がそこまでの有用性を感じていないだとか、謙遜している、などの理由でMetaCPANで公開されていないPerlモジュールがGithubにはあります。

このようにあえてGithubでの公開にとどめられているPerlモジュールを、私は親しみを込めてGithub止まりモジュールと呼んでいます。

そして今回紹介するGithub止まりモジュールは、拙作のTest::Procです。

Test::Proc – プロセスを起動し、その起動状態をテストする

Test::Procは5年前にGithubにpushされています。今となっては当時の記憶を頼りに解説する他ないという点がいささか不安です。

さて、Test::Procが目指したところは、テストスクリプトでプロセスの起動状態をテストしたいというものでした。

使い方はSYNOPSISにある通りです。(done_testingが抜けていたので、補足してあります。)

use Test::More;
use Test::Proc;


my $proc = test_proc 'my_task' => sub {
    print 'test';
    warn 'dummy';
    sleep 20;
};


$proc->is_work;


$proc->stdout_like( qr/\Atest/ );
$proc->stderr_like( qr/\Adummy/ );


$proc->exit_ok;
done_testing;

あら捜し

レポジトリを見てみると、テストの少なさが気になります。github止まりモジュールにはよくある話かもしれないですが、だいぶ控えめなテストの数だなと感じますね。

そしてインターフェースが片手落ちです。というのも、このTest::Procはtest_procというDSLを提供しており、Test::Proc::Objectインスタンスを返しているのですが、test_proc側にはクロージャ以外でプログラムを起動する方法が提供されていません。Test::Proc::ObjectはProc::Simpleのサブクラスであり、24行目で引数の$codeを実行しているので、Proc::Simpleのインターフェースを見る限り、文字列で外部コマンドとオプションを渡すことができるはずです。

実験

実際に以下のようなテストを作って実験してみました。

$ cat hoge.sh 
sleep 3
echo "hoge"

$ cat t/12_shell.t 
use strict;
use Test::More;
use Test::Proc::Object;

my $proc = Test::Proc::Object->new('sleep 3 sec. Then print "done"', 'bash ./hoge.sh');

$proc->is_work;
$proc->exit_ok;
$proc->isnt_work;

$proc->stdout_like(qr/\Adone\z/);
$proc->stderr_like(qr/\A\z/);

done_testing;

これを実行すると、以下のようになり、テストは成功します。

$ perl -Ilib t/12_shell.t 
ok 1 - process sleep 3 sec. Then print "done" is work
ok 2 - process sleep 3 sec. Then print "done" exit code is 0
ok 3 - process sleep 3 sec. Then print "done" is not work
ok 4
ok 5 - process sleep 3 sec. Then print "done" STDERR like (?^:\A\z)
1..5

深掘りしていく

上記のことから、test_procにコマンドを文字列渡しして起動させることができそうですが、実際に以下のようなテストを試してみると、失敗してしまいます。

$ cat t/13_shell-with-test_proc.t 
use strict;
use Test::More;
use Test::Proc;

my $proc = test_proc 'my_work' => 'bash ./hoge.sh';

$proc->is_work;
$proc->exit_ok;
$proc->isnt_work;

$proc->stdout_like(qr/\Adone\z/);
$proc->stderr_like(qr/\A\z/);

done_testing;

$ perl -Ilib t/13_shell-with-test_proc.t 
Type of arg 2 to Test::Proc::test_proc must be sub {} (not constant item) at t/13_shell-with-test_proc.t line 5, near "'bash ./hoge.sh';"
Execution of t/13_shell-with-test_proc.t aborted due to compilation errors.

これはtest_procのインターフェースが($&)となっているために起こっている問題となります。ですのでこれを($$)としてあげると、以下のように成功します。

$ perl -Ilib t/13_shell-with-test_proc.t 
ok 1 - process my_work is work
ok 2 - process my_work exit code is 0
ok 3 - process my_work is not work
ok 4
ok 5 - process my_work STDERR like (?^:\A\z)
1..5

なぜgithub止まりなのか

このように、完成度の低さゆえにgithub止まりとなっているTest::Procですが、その他に大きな理由として、私個人が出くわす状況にそもそもテストスクリプトでプロセスの起動状態をテストしたいケースがあまりにも少ないという点が挙げられます。

そういうわけで、結局あまり洗練もされないまま5年もgithub止まりとして塩漬けになっていたというわけです。

Test::Procの今後

一応、ユースケース的に「いいじゃん?」って思ってくれる人がいらっしゃるのであれば、forkしてshipitするまでやってくだされば良いとおもいますが、今の所私自身がなにかをするということは無いでしょう。

コンセプトモデルということでここはひとつ、ご理解いただければ幸いです。

まとめ

ざっくりまとめると以下のようになります。

  • MetaCPANでPerlモジュールを公開する前に、いま一度そのモジュールの性質を見つめ直そう
  • Perlコミュニティの歴史から、誰かがつらい思いをしないための行いについて知ろう
  • Test::ProcというPerlモジュールを作ったけど、ユースケースに遭遇しなさすぎて結局Github止まりになった
  • Github止まりモジュールは「コンセプトモデル」として見ると良さそうかも

明日のPerlアドベントカレンダーは6日目。@yoku0825さんによる「マイエスキューエルにはPerl Mongerが必要かもしれないはなし」です。

Hokkaido.pm #14で 予想の話 というか 予想を支えるシステム設計の話 をしてきました

予想の話予想を支えるシステム設計の話

札幌で開催されたHokkaido.pm #14というイベントに参加し、予想の話(というか予想を支えるシステム設計の話)をしてきました。

内容としては「おとなの自由研究」の取り組みの中で作った南関競馬予想システム「うまミる」のシステム構成と予想ロジック、運用などについてを話したのですが、30分は予想以上に短く、あらかじめ40分で発表枠を押さえておけばよかったというのが正直な感想です。

うまミるについてより詳しく聞きたい方は、アルコールチャンスを用意してくださればお話しますので、是非ともよろしくお願いします。

Hokkaido.pmの皆さん、本当に楽しかったです。ありがとうございました。出来たら11月くらいにもう一発くらい開催してくれたらいいのにな、って思いました!

あと当然ながら、初夏の札幌を満喫したのは言うまでもありません。

Gotanda.pm #18 六本木編 でLTしました

Gotanda.pm #18 六本木編で、Core Modulesに寄せてみたら?というタイトルでLTしてきました。

オフィスから歩いていける場所ということもあり、割と早々とLTすることを決めたんですが、勢いは大事ということでLTもどうにか勢いを維持して発表できたんではないかなと自負しております。

「システムプログラミング」というテーマだったようでして、 strace を使ったperlのopenとシステムコールの結びつきについて詳説したトーク(kazeburoさん)や、ネタが被ったと言いながらも、別の切り口によるディープなトーク(skajiさん)、はてなブログSSL化の裏側についてのトーク(papixさん)など、全体的に「掘り下げられた発表」が多かったように感じました。

Mishima.pm #3 に参加してきました

Mishima.pm #3というイベントが6/3(日)に開催されました。

主催の@dokechinさんが三島在住ということで、数年前から不定期的に開催されていまして、私は #0, #1, そして今回の #3 と、開催されるたびにできるだけ行こうと思っているpmの一つです。

今回の参加者は私を含めて4名。当日の様子は#mishimapmtogetterにもまとまっていますので、そちらも併せてご覧いただけると雰囲気が伝わりやすいのではないでしょうか。

「Why people says “Perl is guilty”?」というタイトルで発表

こちらに発表スライドのMarkdownを置いてありますので、そのままご覧いただくか、reveal.jsで任意のテーマを当ててご覧ください。

この発表で言いたかったこと

かなりポエムっぽいことなのですが・・・

様々な言葉でPerlを貶める人はいるし、私も彼らの言っていることにも一定の理解を示します。確かに一部は事実でしょう。

しかしそれらは大抵、他の言語で鳴らしてきた人が、大して知りもしないPerlについて語っているだけではありませんか?少なくとも私にはそう見えます(私がPerlのすごい人かと言われると、そんなこともないんですけど)し、悲観的すぎるだろうと思います。

そんなことを気にするより、低い理解度でも自分の思った処理を書くことができることの方が大事だと思いますし、Perlにはそのためのツールセットが揃っているんだ、と言いたい。

実は覚えることがかなり少なくて良いので(例えば変数記号については$と@と%を理解できればひとまずOK)、まず書いてみて、足りないところの知識を補いながら少しづつ上達するのに向いている言語なんです。

斜に構えて100%理解した風に振る舞うより、まず手を動かして試すところからPerlを触ってみると、意外といいものだと思えますよ。

・・・スライドからは読み取れないでしょうけど、こんな感じのことを話しました。

コンテキストの観点でPerlを理解する

私の発表の前に@karupaneruraさんの発表内容が、Perlのコンテキストに関する話題に触れていました。

例えば$age = 100というデータについて、

  • $age . "歳のおじいさん" という文字列的な扱い
  • $age + 1 という数値的な扱い

の両方を同じ変数に対して行えることは、コンテキストを意識することで、一見複雑に思える挙動を理解できるという感じの話でした。

似たようなことをやっている言語はLispやFORTHなどが挙げられます。

この考え方のメリット・デメリットについて書くと長くなるので別の機会に回しますが、Perlについての理解を深める視点として、非常に慧眼だなと感じました。

三島を満喫する

うな丼

三島で八王子

竹倉温泉の待合室

新幹線コンコースから望む富嶽

Windows10でPerl+VSCodeな開発環境を整える

※このエントリはPerl入学式 Advent Calendarの13日目のエントリとして、滑り込むように執筆したものです。

私とPerl入学式の関わり

わいとんです。

実は私、第1回東京開催のころから散発的にPerl入学式のサポーターをやってきました。もう3年以上の関わりになるので、サポーターの中では最古参の部類に入るでしょう。

さて、今回はWindows10でPerlの開発環境を整える話をしたいと思います。

WindowsはPerlの開発に向いていないのではないかという話

Perl入学式の講義では、Windows向けの開発環境としてVirtualBoxUbuntu Linuxをインストールする方法をレクチャーしています。

というのも、基本的にはWindowsでPerlのプログラミングを行うことはやや困難であるとか、あるいはWindowsでPerlを書いている人がサポーターを始め、さほど見受けられないので、サポートを受けにくい状況にある、などという理由が横たわっているためです。

当たり前を疑ってみる

では、本当にWindowsでPerlアプリケーションの開発を行うことは困難なのでしょうか?

あるコンテキストにおいてはこれはYesなのかもしれません。

例えば(Perl入学式の講義レベルから見ると相当高度な話となるのですが)MySQLを使った開発をすべてWindows上で行う場合は、もしかするとLinuxでは考えられない苦労が待っているのかもしれません(ただし、私は試したことがないので、これは間違いかもしれません)。

しかし、Perl入学式のカリキュラムの範囲であれば、私見ですがWindowsでも困ることはないだろうと思います。

WindowsでPerlの開発環境を構築したい向きには、もしかすると役に立つかもしれないので、私なりの環境構築法を紹介します。

Windowsにもパッケージマネージャがある!

個人的に、もっと有効活用されてもよいのにと思うプロダクトに、chocolateyというパッケージマネージャがあります。そう、yumやaptのように、ほしいプログラムパッケージ名を教えると、あとは全自動でインストールまでやってくれる便利なやつです。

chocolateyのインストール

まず、Windowsのスタートボタンを右クリックし、 Windows PowerShell(管理者)を選択します(この時、管理者権限を求められますので、「はい」を選びます)。

すると、PowerShellターミナルが開きますので、chocolateyのインストールガイダンスに従って、以下のコマンドをPowerShellターミナルに貼り付けて実行します(長いので折り返して見えるかもしれませんが、一行です)。

Set-ExecutionPolicy Bypass -Scope Process -Force; iex ((New-Object System.Net.WebClient).DownloadString('https://chocolatey.org/install.ps1'))

これでchocolateyのインストールが完了しました。

chocolateyは、Windows管理者にchocoコマンドを提供してくれます。うまくインストールできているか、試しにchocoコマンドを使って、以下のようにパッケージを検索してみましょう。

choco search perl

chocoateyのインストールに成功している場合、以下のようにパッケージがズラッと表示されます。

Perlを使えるようにする

さて、無事にchocolateyのインストールができたら、今度はPerlを使えるようにしたいところです。

Windows向けのPerlにはいくつか種類がありますが、比較的はまりどころが少ないと感じているStrawberry Perlを、chocolateyを使ってインストールしていきます。

先ほどの choco search の結果を見ると、パッケージ一覧の最初に

StrawberryPerl 5.26.1.1 [Approved] 

と書いてあります。もう見たままなのですが、一番左側にはパッケージ名が、その次にはそのバージョンが表示されていまして、つまり以下のようにchocoを実行してやるだけで、Strawberry Perlの5.26.1.1がインストールされるというわけです。

choco install StrawberryPerl

非常に簡単ですね。途中でインストールの可否を問われますので、「Y」を選択してあげればOKです。

VSCodeをインストールする

VSCodeとはVisual Studio Codeの略称です。エディタですので、宗教上の理由によりほかのエディタでなければいけない、という方はここはスキップしてかまいません。

VSCodeは、MicrosoftがOSSとして開発しているエディタです。atomなどにも似ていると思います。

そんなVSCodeもchocolateyで検索・インストールすることができます。

choco install VisualStudioCode

たったこれだけです。

第2回の課題を一つ、Windowsで実際にやってみる

chocolateyを使って、いとも簡単にPerlの開発環境を整えることができました。

では、実際にこの開発環境をつかって課題をこなしてみます。

via GIPHY

まとめ

  • WindowsでもStrawberry Perlを使うと、Perl入学式のカリキュラムを乗り切ることができるかもしれません。
  • Windowsのパッケージマネージャchocolateyを使うと、開発環境の構築が意外と簡単でした。

Perlコアモジュールに寄せてみる

※このエントリはPerl Advent Calendar 2017の9日目のエントリとなります。

8日目は@mackee_wさんの担当でマスタデータを宣言的かつ高速にテストするTest::MasterData::DeclareとTest2の構造についてというエントリでした。Test2を使ったモックデータを伴うテストの記述に、大変強力そうなモジュールでしたね。

さて、本エントリではPerl5におけるコアモジュールについてのさわりと、その中でも鉄板とも呼べる非常に有用なものをいくつか紹介していきます。

コアモジュールとは?

Perl5におけるコアモジュールとは、Perl5と抱き合わせでインストールされるモジュール群のことを指します。

コアモジュールとして収録されるモジュール群は、Perl5のバージョンごとに差がありますが、個人的な肌感としては、本当に鉄板とも呼べるような物は大抵5.14以降であればそろっていると考えても差し支えないと思います。

コアモジュールをちゃんと調べたい

私のようなテキトーな人間の肌感なんかは余り当てにならないでしょうから、確実性のあるソースを当たるのであればperldoc.perl.orgのコアモジュール一覧がありますので、そちらを参照するのが間違いないでしょう。

上記ページの左上には、Perlバージョンを指定するドロップダウンメニューがありますので、お使いのPerlバージョンを選ぶとよいでしょう。

もしくは、ターミナルで corelist モジュール名 と打ち込んでやると、そのモジュールがコアモジュールかどうかと、(もしコアモジュールの場合は)どのperlバージョンからコアモジュールに収録されたのかを返してくれます。

例えば私の使っているRazer Blade Stealth(Windows10 + Strawberry Perl 5.26.1)で Module::Load について corelist を使って調べてみると、以下のような結果が得られました。

C:Usersytnob>corelist Module::Load

Data for 2017-09-22
Module::Load was first released with perl v5.9.4

なお、 corelist コマンドは Module::CoreListというモジュールによって提供されておりますが、当然これもコアモジュールです。

C:Usersytnob>corelist Module::CoreList

Data for 2017-09-22
Module::CoreList was first released with perl v5.8.9

なぜコアモジュールを使うのか

Perlをはじめとしたモジュール管理のエコシステムが整ったプログラミング言語を各種開発に利用するにあたって、大抵はそのモジュラリティをフル活用した開発スタイルを取ることになると思います。つまり、インターネットなどを通じて外部からモジュールを取り入れて利用することがほとんどでしょう。

CPANなどで公開されている便利な外部モジュールを利用することで、本質的なロジックの開発に集中しようということがその狙いだったりするのですが、つぶさにコアモジュールを調べてみると、外部モジュールに頼るまでもなく、案外とコアモジュールで済ませられる事も多かったりします。

コアモジュールに寄せておくことで、以下のようなメリットに与ることができます。

  • スクリプトの利用環境制限を緩めることができる(Windowsでも動く、とか)
  • 外部モジュールのインストールの手間を省くことができる

私が選んだお気に入りコアモジュール5選

さて、ごちゃごちゃと説明してきましたが、私がよく使うコアモジュールを5つだけピックアップしてみました。本当はもっとお世話になっているコアモジュールはいっぱいあるのですが、執筆に必要な集中力の都合上、このくらいに留めさせておいてください。

HTTP::Tiny (from v5.13.9)

LWP::UserAgentFurlよりもプリミティブな感じのあるHTTPクライアントモジュール。レスポンスがオブジェクトではなくハッシュリファレンスで帰ってくる点が前述のモジュール達よりもシンプルです。

HTTP::Tinyについては、shohexさんが6年前に書いたエントリが非常にわかりやすいですので、そちらもご覧ください。

Module::Load (from v5.9.4)

モジュールの動的ローディングを実現するモジュール。状況によって読み込むモジュールを差し替える(Strategyパターン)ようなケースに使ったりします。

似たようなものにはClass::Loadとかがあるんですが、Module::Loadだとちょっと足りない、というケースで使うかもしれません。私は使わないけど。

Encode (from 5.7.3)

日本人に生まれ日本語とPerlを操っている以上、マルチバイト文字と仲良くすることが求められるのですが、Encodeはそのためのツールを提供してくれるモジュールです。もはや説明の余地もないですね。

JSON::PP (from v5.13.9)

PerlでJSONを扱うためのモジュール。これとHTTP::Tinyをつかうことで、コアモジュールだけでちょっとしたAPIクライアントを作ったりすることができます。

とにかく速度を求められるケースであればJSON::XSを使ったりするのですが、速度よりも簡便性を求める場合にはJSON::PPを使うことが多いです。Windowsでもつるしで使えますし。

List::Util (from v5.7.3)

配列操作に関する追加の関数を提供してくれるモジュール。プログラムを書く仕事をして15年以上経過していますが、配列を処理するプログラムは頻出パターンの一つで、必然的にこのモジュールに助けられる事が多いです。

君もコアモジュールを探検してみよう

時折思い出したようにコアモジュールを探検してみると、「こんな便利なのがコアにあったんだ!」という発見があったり、「このモジュールはこういう使い方もできるな」という発想ができたりと、なかなか飽きないものです。

そもそもコアモジュール自体は結構種類があるので、全部を覚えるのはまぁ無理なんじゃないかとも思われますが、普段なかなか見かけないコアモジュールの使い道を考えたりするのも面白いものですよ。

さて、明日は@tsucchiさんの番で、なにやらMinionの話かなにかをしてくれるようですよ。楽しみですね。

Kichijoji.pm #11 でLTしました

Kichijoji.pm #11 に参加し、「あれっもしかしてPHPっていいんじゃないの?」というタイトルでLTしてきました。

This is an embedded Microsoft Office presentation, powered by Office Online.

内容としてはYAPC::Fukuoka 2017で話した内容の超絶短縮版なのですが、若干の内容追加も行なっております。

個人的に興味あった話

Songmuさんのbusyboxを参考にしたバイナリサイズダイエットの話ってのがなかなか面白くて、go generateからのperlってのがとにかく格好良さありましたね。一つの言語に縛られずに手間を無くしていく様子はさすがというところです。

macopyさんkuiperbeltの話なんかは、だいぶ前に構想を聞いた時と比較してどんどんdocs周りが洗練されてきていると感じました。リアルタイムなやり取りが必要なケースではちょっと試してみたいかも。

sakuraさんの検索の話、独特のリズム感と検索エンジンに出てくる広告の話への転換があり、トークの間「次は何がくる?」という期待の連続で非常に楽しませていただきました。

YAPC::Fukuoka 2017 HAKATAでトークしました

YAPC::Fukuoka 2017 HAKATAにてトークしてきました。

PaaSをつかって怠惰・短気・傲慢にシステムを作るためのマインドセットについての話です。当日は徳丸さんの裏番組ということもあり、人が来てくれるのかと心配しておりましたが、思いの外結構人がいらっしゃったので、話した甲斐があったと思っております。

これを機に「Azureってすごいじゃん!」とか「Azure PaaSで作ってみようかな」と思ってもらえれば本望です。

スタッフの皆様、会場提供してくださったLINE様、その他YAPC::Fukuoka成功に向けて尽力された皆様に、改めて御礼申し上げます。ありがとうございました。

YAPC::Fukuoka 2017 Hakataにて登壇することが決まりました

7/1(土)に開催されるYAPC::Fukuoka 2017 Hakataへの登壇が決まりました。

発表タイトルはBe PaaS Monger – クラウドエンジニアの三大美徳、またはIaaSを使わない3つの理由となります。

上記のセッションでは、PaaSを使ったシステム設計・構築におけるマインドセットを、プログラマの三大美徳になぞらえて解説します。

クラウドの運用に人手がかかっていてお悩みの方、PaaSという物がよくわからないという方などに向けた内容となる予定です。

Otogiri-0.18 – A lightweight medicine for using database – metacpan.org

Otogiri-0.18 – A lightweight medicine for using database – metacpan.org