@nqounetです。

Perl入学式ネタで3記事目です。

それなのにこういうタイトルをつけるとビビりますが、まだ勢いが足りてないような気もします。

たった1つと書いていますが、2つ紹介します。

Data::PrinterあるいはDDP

最低限必要なのはこっちです。

プログラミングの基本はデバッグです。

文法を覚えることではありませんよ。（個人の感想です）

Perl入学式も第2回まではスカラと配列だけですが、ハッシュも出てきて、さらに入れ子（リファレンスが必要です）になっていると中身を確認するのも一苦労です。

その辺を感覚的に見てもらうためにも、データの構造がわかるような仕組みが必要です。

最近はChromeのデベロッパーツールが常に画面に出ている状態ですが、JavaScriptのConsoleはいいですよ。

配列もオブジェクトも丸見えです。

Perlも使い勝手では負けますが、簡単にプリントデバッグできるモジュールがあります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/usr/bin/env perl
use utf8;
use 5.012;

use DDP {deparse => 1};

my $string = 'Perl入学式';
my @foo = ('foo', 'bar');

p $string;
p @foo;

変数も配列も中身の確認がこんな感じでできます。

まあ、慣れてきても使えるモジュールですよ、コレは。

嘘だと思ったら実行してみてください。

動かなかったらモジュールが入っていないと思われます。

Perl入学式で環境を整えている場合は、cpanmが使えるはずなので、インストールは簡単です。

1

cpanm Data::Printer

もっと詳しい使い方は、こちらの記事が参考になりますよ。

• Perlのデータ構造をダンプするためのモジュール群 | hirobanex.net
• Breno G. de Oliveira / Data-Printer - search.cpan.org

そんなことよりもテスト

とはいえ最近はテスト駆動の方がいいなぁとは思います。

Perl入学式でも、条件式の説明をするときには、変数に様々な値を入力して動作を確かめていきます。

でも、それってTest::Moreでやったらいいんじゃないか、と思ってしまうのです。

書きなおすのではなくて追記できるから、どんな値を試したのかがわかるし、将来的にテストをすることに抵抗もなくなってプログラミングの品質向上にも繋がるはずです。

なにより、色々なことが簡単に試せるのが良いです。

今回の場合だと、if文の中身をok()でくくると、その中身が真の場合はok、偽の場合はnot okという表示になるので、どういう状態が真なのか、偽なのかが色々と試せます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

#!/usr/bin/env perl
use utf8;
use 5.012;

use Test::More;

my $num = '42string';

ok($num == 42);
ok($num eq 'string');

done_testing;

慣れるまではメッセージがわかりにくいかもしれませんが、そういう時こそサポーターに聞けば良いと思います。

最初から全部を使いこなす必要はありません。まずはokからはじめてみませんか？

やりかたはいろいろある

今回の最終問題は有名なFizzBuzz問題でした。

どんな問題なのかはこちらの記事か、あるいはFizzBuzzで検索してみてください。

• よしいずの雑記帳 FizzBuzz問題の解答例 まとめ

で、初心者向けの場合は、大体3と5と15でif文を作るんですね。

でも、それで決めて欲しくないんですよ。

そういう意味もあって、15を使わない方法を書いてもらったり、FizzとBuzzの文字を1回しか使えないようにしてみたりしました。

言いたかったことが伝わったかどうかはわかりませんが、答えが沢山あるのがプログラミングです。

もしかすると、答えを聞きに来ているのかもしれないのですが、聞いた答えでプログラムが動いたとしても、それだけでいいんですか？

それだけだと、プログラミングがただの作業になってしまって面白くなくなっていきます。

Perl入学式のような勉強会に参加する目的は色々とあるとは思いますが、少なくとも勉強会に参加する意欲を持っている人にはそういうふうにはなって欲しくありません。

何も制約がない状態で1つ答えができたら、なにか制約をひとつ作ってもう一度解いてみる。

FizzBuzzの場合なら、15を使えないようにする（3*5という風に書いてもダメ）とかが制約です。

そういうことを繰り返すと、プログラミングの感覚が養われます。

この感覚は言語特有のモノもありますが、プログラミングの基本スキルだと思います。

そして、その自分自身の軌跡を残しておくことも大事です。

場合によっては1週間もしないうちに、自分自身の成長っぷりがわかると思いますよ。

懇親会でpeco自慢

話がアレコレ飛んでますが、懇親会も楽しかったですよ。

Perl入学式は、いくら敷居が低いとはいえ、やはり時間中は話しかけたりするのも躊躇すると思います。

懇親会は、さらに敷居が低いので、沢山質問が来るのをいつも期待しています。

時間中にもサポートした人には言っています。資料は2回分あるので是非予習をしてきてくださいね、と。大体の方は顔がひきつってますがｗ

で、次回には（昨年の）第5回の資料について質問してくれると私は嬉しい、という風に言っています。

テキストはかなりわかりやすいと思いますし、わからないところはわかりやすいように変更して行きたいと考えているので、できるだけ予習をして、できるだけ質問をして欲しいと思っています。

本編ではこんな感じでサポーター側から声掛けすることが多いのですが、本来はフィードバックが欲しいところです。

基本的にはそう思っていますので、バカ騒ぎしている中でもこっそりPerlの質問とかしても全く問題無いです。

それと、やはり情報交換ですね。

講師役で画面を表示していると、ターミナルの画面がぜんぜん違うとか、画面がパパパパパっと切り替わるとか、そういうところも教えて欲しい、とか思いませんか？

講師役をやるような人は大体教えたがりなので、想像している20倍位のことを教えられることになりますが、それって嬉しいからなんですよ。ドン引きしないでくださいね…。

私は今回、残念ながら画面を映すことがなかったので、つい最近入れたpecoの自慢をするために（狭い席なのに）パソコンを取り出して操作して見せていました。

自慢と言いながら、見せながらの操作はなかなかできないので、ものすごく中途半端な説明だったと思います。ごめんなさい。

シンプルなツールだけに、何を伝えればいいのかよくわかりません。

どんなことができるかは、公式のデモが沢山あってわかりやすいと思います。

• peco/peco

pecoはバイナリ配布もあるので、使うだけならとても簡単ですよ。

• 例えば、pecoをビルドしない - Qiita

ghqとの組み合わせ技では、宮川さんが書いた（英語の）記事ですが、最後の方にあるgifアニメを見るだけでもなにか感じるものがあると思います。

• ghq + peco/percol - Tatsuhiko Miyagawa’s blog

手元の環境では、ghqしたソースは$HOME/local/srcに入るようにしました。

peco-srcしてからのsubl .みたいなのが快感です。

もっと深く知りたくなったら、日本語の情報はQiitaがまとまってて良いと思います。

• Pecoに関する34件の投稿 - Qiita

まとめ

1

cpanm Data::Printer Test::More

1
2
3

use Test::More;
ok('ok');
done_testing;

1

ls | peco | xargs cat

Perl入学式をよろしくお願い申し上げます。