Perlメインだった人からみたElixir

最近Elixirにふれる機会が有りましたので、理解を深めるためにも、見識を書いていきたいと思います。

なお、このエントリを書いている時点でElixir歴だいたい3日ほどです。いろいろ間違えているかもしれませんが、もし間違いに気づいた方、Twitterで教えてくれると嬉しいです。

私のメイン言語変遷

ここでいうメイン言語というのは、「業務で主に触っている(触っていた)言語」という定義でよろしくお願いします(他にもたくさん触ってますけど、かくの面倒なのでいろいろ端折ったりしてます)。

  • 1998: batch(MS-DOSのアレ)
  • 1999-2000: bash, batch
  • 2001-2002: bash, PHP, たまにPerl
  • 2003-2015: bash, Perl, たまにRuby
  • 2016-2018: JavaScript(Node.js), Swift, PHP, たまにPerl
  • 2019: JavaScript??

タイトルにPerlメインだった人って書いてるのは、多分自分で一番慣れている言語がPerlだからそうしている、という感じです。このエントリもPerl使ってる向けに書いているところがあるので、ご了承ください。

ちなみに、とってもお恥ずかしい話なんですけど、Elixirに触るまではElixirが動的型付け言語だということすら知りませんでした。

個人的感想「これPerlでは?」

少し触ってみて思ったのは、「これはRubyというよりPerlにだいぶ酷似してるな」ということでした。

Perlについては、比較的歴史のある動的型付け言語ということでよく知られているかと思います。そしてPerl自体はマルチパラダイムな言語なのですが、実はPerlのご先祖様はLispということもあって、関数型パラダイムの要素を多分に包含しているのです。

一方でElixirもまたマルチパラダイムな言語であり、関数型パラダイムの要素がふんだんに盛り込まれています。その上動的型付け言語だということになると、この時点でだいぶPerlに似ている感じがしますね。

Perlで言うところの「あれ」が「これ」

さて、ここからは具体的な例を挙げて、ElixirとPerlの機能ごとのマッピングを少しだけしていきたいと思います(並列性云々の話は、そこまでたどり着けていないので書きません)。

Cartonだとかcpmみたいなやつは「mix」

RubyでいうところのBundler、Node.jsでいうところのnpm、そしてPerlでいうところのCartonに相当するものとして、Elixirではmixというツールがあります。

このmixは、Perlでいうところの「Minilla」でもあります(パッケージ作成ツールです)。

例えばmy_modというパッケージを作成する場合は、mix new my_modを実行すれば、パッケージのひな形がmy_modフォルダに生成されます。このとき、assertionベースな検証手法が用いられたテストコードも同時に生成される点なんかは、minil newしたときとそっくりですね。

依存パッケージの指定は以下のように、mix.exsdefp deps doendの間につらつらと記入していくようです。

  # Run "mix help deps" to learn about dependencies.
  defp deps do
    [
      # {:dep_from_hexpm, "~> 0.3.0"},
      # {:dep_from_git, git: "https://github.com/elixir-lang/my_dep.git", tag: "0.1.0"}
    ]
  end

そして依存パッケージの導入はmix deps.getだけでOKとなります。

metacpanみたいなやつは hex.pm

ドメインがまさかの.pmなのでElixirはPerl!!!」というのは冗談ですが、Perlで言うところのmetacpan.orgに相当するのがhex.pmというサイトになります。

hex.pmはもともとErlangとElixirのパッケージ検索サイトなのですが、ElixirがErlangのラッパー言語だからか、Erlangで使われているエコシステムをそのまま使ってるようです。

例えばhttpクライアントが欲しい場合、hex.pmでhttp clientを検索すれば、いくつも該当します。

ただ、hex.pmにおける各パッケージのドキュメンテーションは、そのスタイルが統一されていない(CSSが全く違うというレベル)ので、読む側としては正直なんとかしてほしい気持ちはあります。きっとルールが定められていないからなんでしょうかね。。。

REPL(PerlでいうところのReply)は「iex」

標準でついてくるREPLはiexというものでして、必要十分かつ標準的な機能を持ちます。Perlで言うならばReplyが似たようなものかと思います(コチラは標準ではついてこないですが)。

Sigilは意味が違うけど、Perlにあるアレと似てる

Perlでは、Sigilというと変数の最初につく$@といった「変数の性質を決める記号」という事になっていますが、Elixirでは異なる意味の物となっています。それは、以下のような文字列リテラルや正規表現、文字のリストなどを表すためのものです。

// 文字列リテラル(エスケープ・式埋め込みあり)
strX = ~c/1 + 2 = #{1 + 2}/

// 文字列リテラル(エスケープ・式埋め込みなし)
strY = ~C/1 + 2 = #{1 + 2}/

// 正規表現
regex = ~r/(Perl|Elixir)/i

これらをiexで出力してみると、以下のような結果になります(IO.putsはperlで言うところのsayみたいなやつ)。

iex> strX |> IO.puts
1 + 2 = 3
:ok

iex> strY |> IO.puts
1 + 2 = #{1 + 2}
:ok

iex> "I like Elixir" =~ regex  
true

iex> "I like PHP" =~ regex   
false

iex> "I like Perl" =~ regex
true

正規表現の適用が=~なのもPerlと全く同じで、親しみすら感じます。

ところで、ElixirのSigilに相当するものが「演算子」という形でPerlにもあって、以下のように利用できます。

# 文字列リテラル(Elixirの~cに近いが、変数展開はするけど式展開はだいぶ特殊)
my $strX = qq/1 + 2 = @{[1 + 2]}/;

# 文字列リテラル(Elixirの~Cに同じ)
my $strY = q/1 + 2 = @{[1 + 2]}/;

# 正規表現
my $regex = qr/(Perl|Elixir)/i;

これらをsayしてみると、以下のような結果になります。

# 実行内容
use feature qw/say/;
my $strX = qq/1 + 2 = @{[1 + 2]}/;
my $strY = q/1 + 2 = @{[1 + 2]}/;
my $regex = qr/(Perl|Elixir)/i;
say $strX;
say $strY;
say 'I like Perl' =~ $regex;
say 'I like PHP' =~ $regex;
say 'I like Elixir' =~ $regex;
# 実行結果
1 + 2 = 3
1 + 2 = @{[1 + 2]}
Perl

Elixir

まとめ

ElixirとPerlの似たところをほんの少しだけ取り上げてみました。これをきっかけに、ElixirもPerlもちょっとでいいから利用者増えてほしいなぁ・・・

実は他にも似ている箇所が結構ある(構造体とパッケージの紐づけとか)のですが、このエントリはここまでにしたいと思います。この2つの言語、だいぶ似てませんか?私はかなり似ているなと思うんですが・・・。

WEB+DB PRESS Vol.109 に寄稿させていただきました

WEB+DB PRESS Vol.109

紹介

WEB+DB PRESSVol.109(技術評論社:gihyoより2月23日発売予定)のPerl Hackers HubコーナーにサーバレスでもPerlというテーマで寄稿させていただきました。

ぜひお買い求めください!

Perl Hackers Hub – Perl Hacker達による旬の技術の紹介

Perl Hackers HubとはWEB+DB PRESS誌内の連載のひとつであり、Perl Hacker自身が筆を執り旬の技術を紹介するというものです。

gihyoさんのPerl Hackers Hubのページには、Perl Hackers Hubについて以下のような説明がついています。

本連載は,第一線のPerlハッカーが回替わりで,Perlの旬な技術について解説していきます。

記事概要

Microsoft Azure Functionsを使ってPerlスクリプトを実行します。スクリプトの内容は、「画像URLを与えると、画像の顔認識結果(年齢と性別)をJSON形式で返すWeb API」です。

サンプルコードとして、Azure上に環境とプログラムを全自動でデプロイしてくれるスクリプトを収録してあります。Azureアカウントがあれば、最初の無料枠で試せる範囲の内容となりますので、ぜひともお試しください。

謝辞

この度機会を与えてくださった@songmuさん、Perl Hackers Hubコアメンバーの皆さん、そして一緒に原稿の仕上げをしていただいた@inaoさん、本当にありがとうございました。

特に@inaoさんには度々ご迷惑を掛けてしまったにもかかわらず、辛抱強く対応してくださいました。感謝しきりです。

また、Azureについて深く言及した内容の記事はWEB+DB PRESS誌上では初めてだそうです(本当ですか?)。私も驚きました。正直な話、流石にAzureについては過去に誰か書いているだろうと思っていたのですが…意外なところで「誌上初」だったんですね。

ともかく私としては、今回の記事がPerl Hackers Hubというコーナーを通じて、様々な技術に触れるきっかけを読者の皆様に作ることができたらいいな、と思っています。

YAPC::tokyo 2019で登壇しました

YAPC::Japan 2019にて「実演サーバレスPerl – 顔認識データを扱おう」というタイトルで登壇させていただきました。見に来てくれた方、本当にありがとうございます。

そして、結局ライブコーディングするための時間が足りず、見せ場を作れなかった点、本当にごめんなさい。あの後、見に来てくれていた同僚や@note103さんに励まされたのが本当にありがたかったです。

資料

敗因

20分で、受け手側に前知識が必要な内容をライブコーディングするのは、あまりにも無謀でした。

前知識のインストールが終わった時点で7分ほど経過しておりました。さらにクラウド側(Azure)の処理待ち時間が思った以上にかかる。

これではまずいということで、事前に用意しておいた出来上がり環境を使って説明していきましたが、それでも時間が足りず、コードを書くところをお見せできませんでした(コードそのものをお見せすることはできたのですが・・・)。

補足(というか宣伝)

今回のセッションをおさらいする内容で、Web+DB Press誌 2019年2月号のPerl Hackers Hubに寄稿させていただいております。まだ発売まで時間がありますが、より詳しく解説されているものとなりますので、興味のある方はぜひお買い求めください!

また、Web+DB Press誌ではサンプルコードも提供します。サンプルコードは、今回の顔認識システムを自動でAzure上に構築するスクリプトとなっておりますので、構築する手間が惜しいが試すだけ試してみたい、という方にもおすすめです。

前夜祭でもLTしました

本編のみ参加の方はご存じないかもしれませんが、前夜祭でもLTで発表しました。Webappにおける@INC Hooks絶対許せないマンとしてネタに振り切った内容です。

LT資料

Acme::AtIncPoliceのその後

実は昨日Acme::AtIncPoliceissueが立ちまして。なんだろうと思ってみてみると、「Testで使ってるTest::Exceptionが入ってないからTest失敗するんですが」という内容でした。

それを受け、今朝慌ててTest::Exceptionをdependencyとして登録し、shipit。なんと0.01をshipitしてから、たった2日で0.02をshipitすることとなってしまいました・・・

感想など

@songmuさんベストトークおめでとうございます!感極まって感情が溢れ出たときに、周りで何名かもらい泣きした人がいたんですが、songmuさんの情熱があるからこそなんだろうなと。

個人的には@risouさんのPerl6トークと@hitode909さんのWebVRトークがかなり良い話だと思いました。hitode909さんからは豆本の夢日記を頒布していただきました。家宝にします。

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