怖くないwhile

※おもにPerlの話です。

非エンジニアながら趣味でプログラミングに入門したのが2013年の夏。そろそろ4年になろうとしているけど、Perlの基礎を学びはじめてからつい最近まで、一貫して怖かったのがwhile文だった。

怖い、というのも変な気がするが、ようはすぐに無限ループするのがつらく、それを避けたいがためにwhileを使わずに済むかぎりはなるべく使わないようにしてきた、ということ。

すぐに無限ループするとか、なるべく使わないようにする、とかいうのは、結局whileの構造というか、挙動をよく理解していないからそうなる。

理解したくないわけではないのだけど、触るとビビッと痛みを味わい、そこから回復するまでにけっこう時間がかかるので、限られた時間を使ってプログラミング学習をしている身としては、やはり距離を置かざるをえなくなっていた。

べつに無限ループしたって、Ctrl-c とかで抜けちゃえばいいじゃん、と思う人もいるかもしれないが、ぼくは普段からちょっとしたコードの実行ならVimのquickrunというプラグインを使っているので、これで無限ループをするとVimごと強制終了&再起動しなくてはならず、ときにはPerlのプロセスが走り続けてマシンのメモリがゼロになってしまい、マシン自体の再起動もできないまま電源ボタン長押しでマシンごと強制終了、みたいなことも幾度となく繰り返してきたので、やっぱりそれはなかなかつらい。
(そのうちにそこまで行く前にプロセスを切断する方法も覚えたけど、それはまた別の話)

じゃあwhileを使わないでどうしていたのかというと、ずっとfor文を使っていた。

ここで言うfor文というのはPerlでよく使われるそれで、だからC言語なんかで使われるそれではなく、foreachのエイリアスとしてのそれである。

forはいい。forは無限ループしないから。
いや、させようと思えばさせられるけど、普通に使えばまずしない。

無限ループしないループは人に優しい。

しかしながら、forでは実現できない繰り返しというのもやはりあって、それで仕方なく時々whileに付き合ううちにようやくわかったのが以下の本題。

forは「流れ」 whileは「繰り返し」

forもwhileも「繰り返し」としてひとまとめにされがちだが、実際は全然違う。

上で無限ループについて言ったように、同じことを両方にさせることも可能だが、元々備わっている性質が違うということ。

forというのは、たとえてみれば高速道路の料金所のようなものである。
ひとつのチェックポイントを上りから下りへ(あるいはその逆へ)、多くの車が次々と通過していくが、道はワンウェイで、同じ車が何度も同じ料金所を通ることはない。

だから、これを「繰り返し」と表現するのは厳密にはおかしい。

forを通して起きている現象は本来「流れ」とでも表現すべきもので、上では高速道路にたとえたが、より汎用的に言えば「滝」のようなものか。滝はいつも同じ姿をしているように見えるが、実際には同じ水は二度と同じ場所を流れない。

一方のwhileはまさに繰り返しで、同じものが同じところを何度も走る。
それはたとえてみれば競馬とか、F1とか、あるいは陸上競技の1万メートル走とか、そういう感じ。
同じ馬や車や人が同じコースを何周も走っている。

具体例で見てみよう。

forをforらしく使うには、「最初に用意したデータをすべて通過させる」という用途で用いるのがいい。

たとえば、10個の文字列の語末に一律で「!」をくっつけるとか。

#!/usr/bin/env perl
#
# for.pl

use strict;
use warnings;
use feature 'say';

my @arr = qw/aaa bbb ccc ddd eee fff ggg hhh iii jjj/;

for my $str (@arr) {

    say $str.'!';

}

f:id:note103:20170508124043g:plain

ここでは、最初に用意した @arr の中身を処理し終えたらプログラムも終わる。
プログラムの目的は、@arr の中身(aaa〜jjj)を対象として、それらに何かすること。

一方、whileがやることは根本的にそういうものとは異なる。
これの特徴を一言で言うなら、「やめろと言うまで繰り返し続ける」ということになる。

誰かがどこかで「もうやめてください」と泣いて懇願するまで、それは同じものに対して同じことを何度でも実行し続けるし、逆に言えばそれをやめさせる条件をちゃんと設定しておけば、おとなしくそこでやめる。

whileで無限ループが生じてしまう原因の大半は、結局のところ、この「やめる条件」を設定できていないことに尽きるだろう。

そして、なぜそれを設定できていないのかと言えば、それはfor文と同じように「一連の処理を通して元のデータになんらかの変更を加える」ことを強く考えてしまっているからで、相対的に「いつ・どういう条件でやめさせるか」ということにまで想像が至ってない(考えるのが後回しになってる)からである。

しかしここまでの話を見ればわかるとおり、whileを使う上で最初に考えるべき&最も重要なことは、「いつ・どういう条件でやめさせるか」の方である。
先にそれさえ決めれば、無限ループは生じない。

whileの特徴を示すには、対話型のプログラムを作るのが良いだろう。

#!/usr/bin/env perl
#
# while.pl

use strict;
use warnings;
use feature 'say';

print '>> ';
while (my $input = <STDIN>) {

    chomp $input;

    if ($input eq 'stop') {
        say 'Bye';
        last;
    }
    else {
        say $input;
        print '>> ';
    }
}

f:id:note103:20170508124100g:plain

もちろん、というか確かに、というか、whileでも先にfor文で挙げたような処理を行うことはできる。

#!/usr/bin/env perl
#
# while2.pl

use strict;
use warnings;
use feature 'say';

my @arr = qw/aaa bbb ccc ddd eee fff ggg hhh iii jjj/;

while (my $str = <@arr>) {

    say $str.'!';

}

f:id:note103:20170508124121g:plain

しかし、これならwhileを使う必要はない。というか、forを使う方シンプルだし、目的に適っている。

また逆に、for文で先のwhile文のような対話型処理を行うことも可能ではある。

#!/usr/bin/env perl
#
# for2.pl

use strict;
use warnings;
use feature 'say';

print '>> ';
for (;;) {

    my $input = <STDIN>;
    chomp $input;

    if ($input eq 'stop') {
        say 'Bye';
        last;
    }
    else {
        say $input;
        print '>> ';
    }
}

f:id:note103:20170508124144g:plain

しかしこれまで数年間Perlを触っていて、こういうコードを見たことはないし、今後もあまり見る機会はないように思える。

よって、一般的にはfor[eache]文は「垂れ流し型」、while文は「対話型」の用途で使われる(使われやすい)という前提で話を続ける。

「限定40食の蕎麦屋」と「気まぐれなラーメン屋」

必要なのは、ありありとしたイメージである。

forとwhileの違いを「ありありと」イメージできなければ無限ループは止まらない。

forとwhileの違いは、「限定40食の蕎麦屋」と「気まぐれなラーメン屋」の違いとして想像することができる。

「限定40食の蕎麦屋」は、for文のたとえである。以下のようなコードになる。

#!/usr/bin/env perl
#
# for_soba.pl

use strict;
use warnings;
use feature 'say';

my $limit = 40;

for my $count (1..$limit) {

    say "soba $count";

}

f:id:note103:20170508124211g:plain

最初に限定食数を変数 $limit に設定して、それを売り切ったら終わりである。

一方のwhile文は、「気まぐれなラーメン屋」にたとえられる。
コードにすると、このようになる。

#!/usr/bin/env perl
#
# while_ramen.pl

use strict;
use warnings;
use feature 'say';

print 'time >> ';
while (my $input = <STDIN>) {

    chomp $input;

    my $open = 11;
    my $close = $open + int(rand 12);

    say "Opening hours is $open - $close.";
    if ($input < $open || $input > $close) {
        print 'time >> ';
    }
    else {
        say 'ramen';
        last;
    }
}

f:id:note103:20170508124232g:plain

ここの店主は午前11時に店を開けるが、何時まで営業するかが日によって違う。店主の気まぐれですぐに閉めたり、22時まで営業したりする。

客は自分の行きたい時間を「13」とか「18」とか入力し、開いていれば「ramen」にありつけるが、開いてなければ開くまで時間を入力し続けることになる。

whileはこういう処理に向いている。

言い換えると、forは「何を(あるいは何回)実行するのか事前にわかっている時」に使いやすく、whileは「何回実行するのか事前にはわからない」という状況で使いやすい。

そしてそのようなwhileでは、「何回繰り返すのか」が事前には決まっていないから、自分で能動的に「やめどき」を作らなければならない。

終わりに

この記事のきっかけになったのは、BSジャパン(テレ東のBS版)で毎週放送されている『ワタシが日本に住む理由』という番組で、バングラデシュ出身の日本蕎麦屋さんの回を見たことだった。

腕の良い&こだわりのある彼は、毎朝40食分の蕎麦を打ち、それが売り切れたらその日の営業は終わってしまう。

番組じたい面白かったが、それを見ながら、「これはfor文みたいだな」とふと思った。

そして、これがfor文ならwhile文は何だろう? と考えて上のような話になった。

for文は「繰り返し」ではない。「流れ」である。
手元に溜めておいた素材を出しきったら、そこでおしまい。

たしかに見た目には「回っている」ように見える。というより、システム自体は回っているが、その上を流れるデータは回っていない。

それは新聞などを印刷する輪転機のようでもある。
輪転機はグルグルと回り続けているが、その上を流れる紙は長い1本道をスタートからゴールまで駆け抜けているだけである。

while文は「繰り返し」とも言えるが、本質はその「終わらなさ」だと思う。

それは『うる星やつら劇場版 ビューティフル・ドリーマー』のように、あるいはビル・マーレイ主演による『恋はデジャ・ブ』のように、同じ日々を何度も繰り返す。

どこかに決定的な「終わりへの抜け道」を作らなければそこから抜け出すことはできず、それが実現するまではひたすら終わらない1日を繰り返さなければならない。

whileはやっぱり怖い。

基本情報技術者試験を受けてきた

結果

先週日曜(2017/04/16)、基本情報技術者試験というのを初めて受けてきた。

同日中に解答が公式に配布されて、翌日さっそく自己採点したところ、たぶん今回は駄目だった。
(正式な合格発表は5/17)

同試験は午前と午後の部があって、それぞれ60点以上とれば合格なのだけど、午前は77点ちょいでパスしたものの、午後がたぶん53点ぐらい。
だから午後の方でアウトになってる。

ちなみに、午前は厳密に配点が公開されてるのだけど(1問につき1.25点)、午後は大問ごとの配点のみ明示されていて、その中の小問というか、枝問の配点まではわからないので、上記は大体の目安。
とはいえ、少し厳し目に算出したものの、さすがに7点ずれてるということはないだろうから、駄目なものは駄目だと思う。

今年の1月末にITパスポートという、やはり国家試験ながらコレ系では一番カンタン(というか一般人向け)、みたいのを受けて(それは受かった)、そのための勉強を始めたのが昨年末ぐらいだったので、それも含めると約3ヶ月、とはいえ2月は別件であまり時間が取れなかったので正味1〜2ヶ月程度の学習期間だったのだけど、それにしてはまあ、頑張った方だと思う。

というか、元々今回は記念受験というか、とりあえず受けるだけ受ければそのために否が応でも勉強するだろうし、それを土台にして秋の合格を目標に据えて頑張ろう、とか思っていたのだけど、だんだん過去問の結果がいい感じになってきて、「あれ、これもしかして結構ギリギリのところまで行けるのでは……」みたいに思ってたら本当にギリギリ(アウト)だったという感じ。

当初の目標は低めに設定していたとしても、当然のことながら合格できるならしてしまいたかったわけで、やっぱり無念ではある。

と同時に、しかし実際には、午前はともかく午後の方はだいぶお手上げな感じで、午後試験が始まってから1時間ぐらいで、「うわー、今回は駄目だ、まったく駄目! 過去問はそこそこできてたのに、全然歯が立たないじゃん。秋までサヨウナラ〜だな!」と、会場で完全パニック&気持ちが180度折れるぐらいわからなかったので、それにしては拮抗したじゃん、というか当てずっぽうの回答が当たりすぎただけでは、という気すらする。

まあ、60点という基準点がそれだけ低めの設定なのかな……とも思うのだけど。
簿記は70点が基準点で、前回2級に落ちたときは60点で落ちたので、まあ60点が基準点というのはけっこう懐が深い感じなのかもしれない。

上では記念受験と書いたけど、それに近い感じで今回の最大の目標というのは、何しろこの基本情報技術者試験、午前が9時半からのスタートで、かつぼくの家から会場までが1時間ぐらいの距離だったので、とにかく「時間に間に合う」というのが最大の目標になっていた。

ようは試験の開始時刻にちゃんと間に合って、かつベストの体調で最後まで受けきり、持ってる実力を発揮する、ということ。

実力を発揮した上で落ちるなら、まあしょうがないのだけど、体調不良とか寝不足とか、あるいは準備するもの(受験票とか)の不備とか、寝坊とか無自覚な違反行為とか、そういうのが理由で落ちたら悔やんでも悔やみきれないので、そういうことを最大限避けて受験する、というのが目標だった。

で、それは達成できて、しかしその結果としては上記のように、問題が自分には難しかったり、(おそらくはその影響もあって)とにかく時間が全然足りなかったので、次に受けるときはもうちょっと余裕を持って、少なくとも問題の内容を理解しながら最後まで答えきる、というのを新たな目標として設定したい。

とくに、必須問題である第8問のアルゴリズム問題。これは擬似言語というのを使って、プログラムの中身をトレースしていくような問題なんだけど、これが本当に最後の最後まで苦手で、結局まともな得点を取れないまま本番が終わってしまった。
次回はとくにこの問題で、ちゃんと自信を持って回答できるようにしたいという気持ちが強い。

今回はこれだけの短期間で、仕事もしながら(他にもいろいろ忙しかったのだけど)、ここまで来たのだから、その調子でいけばもう少し向上できるはず。たぶん。

参考書

学習経緯としては、以下に簡単なログというかメモを残してある。中途半端だけど。
基本情報技術者試験の受験勉強の記録 - note103

進捗記録の最初(一番下に記載)が3/18だけど、手元のログを見ても過去問に着手したのが3/11とかなので、本格的な問題練習はその頃から、という感じか。

そのリンク先には参考にした本なども記載しているけど、その後に購入したものを含めて、とくに参考になったものを列記&簡単にコメントも付しておく。

(PDF・スマホ単語帳付) かんたん合格 基本情報技術者 過去問題集 平成28年度(2016年度)秋期

(PDF・スマホ単語帳付) かんたん合格 基本情報技術者 過去問題集 平成28年度(2016年度)秋期

  • たぶん一番読み返した&使った。単なる過去問集ではなく、解説も丁寧で充実していた。多謝。

平成29年度 ITパスポート合格教本 (情報処理技術者試験)

平成29年度 ITパスポート合格教本 (情報処理技術者試験)

  • 作者:岡嶋 裕史
  • 出版社/メーカー: 技術評論社
  • 発売日: 2016/12/01
  • メディア: 単行本(ソフトカバー)

  • 後述。

ゼロからはじめる基本情報技術者の教科書

ゼロからはじめる基本情報技術者の教科書

  • 作者:滝口直樹
  • 出版社/メーカー: とりい書房
  • 発売日: 2014/11/26
  • メディア: 単行本

改訂第3版 すらすらと手が動くようになる SQL書き方ドリル (WEB+DB PRESS plus)

改訂第3版 すらすらと手が動くようになる SQL書き方ドリル (WEB+DB PRESS plus)

  • すでに古典(?)な本書。受験用ではなく少し前に買ったのだけど、データベース問題対策として非常に有用だった。挿絵(イラスト)も最高。

(全文PDF・単語帳アプリ付) 徹底攻略 応用情報技術者教科書 平成29年度(2017年度)

(全文PDF・単語帳アプリ付) 徹底攻略 応用情報技術者教科書 平成29年度(2017年度)

  • 今回の受験とは対象が違うけど、念のためと思って買っておいたらビンゴ。「基本」用の教科書では省略されてしまった重要トピックについても図入りで詳細に解説されているケースが結構あって、助かった。平明な動画講義も何度も見返した。瀬戸先生の教え方は単に詳しいだけでなく、どのポイントが重要なのかという見極め、それから知識のための知識ではなく、その技術が実社会でどう活用されているのか、みたいなことに意識を繋げながら教えてくれる、という印象があった。

情報処理教科書 基本情報技術者試験のアルゴリズム問題がちゃんと解ける本 第2版

情報処理教科書 基本情報技術者試験のアルゴリズム問題がちゃんと解ける本 第2版

  • 作者:矢沢久雄
  • 出版社/メーカー: 翔泳社
  • 発売日: 2016/12/15
  • メディア: Kindle版

  • 勝手に馴染みを覚えている矢沢久雄さんによるアルゴリズム本。アルゴリズム問題に絞って書かれているというだけでもツボだったけど、基本から応用まで幅広く解説されていて良かった。結果的には成果は出なかったけど、取っ掛かりとしては有効だったと思う。

改訂3版 基本情報技術者試験 C言語の切り札 (情報処理技術者試験)

改訂3版 基本情報技術者試験 C言語の切り札 (情報処理技術者試験)

  • 作者:宮坂 俊成
  • 出版社/メーカー: 技術評論社
  • 発売日: 2017/02/09
  • メディア: 単行本(ソフトカバー)

  • 過去問のプログラムが1行ずつ丁寧にトレース&解説されていてとても参考になった。終盤ではアルゴリズム問題も扱ってくれていて、上記の問題集や矢沢さんの本と突き合わせながら読むことで奥深いところまで検証できた。多謝。

そして2番目に挙げた岡嶋裕史さんの本、ITパスポート用と銘打たれているのだけど、内容的にはすごく詳しく幅広く、どう考えてもこれ、ITパスポート試験でここまでの知識いらないだろ(笑)というぐらいの充実度で、会場まで持っていく厳選参考書の中にこれも含めたぐらい良かった。

電子版も出ていて、紙版と合わせて買ったけど、すごく面白かったし今後も折々読むと思う。

岡嶋裕史さんは元々、「スラスラわかるC言語」という本を読んで「面白い著者だなあ」と思っていたので、岡嶋さんが書いた基本情報技術者の本がないかなあ、とわざわざ探していたら、それに一番近いのがこれだったので&サンプルを読んで良さそうだったので買った、という感じだった。

とにかくサービス精神が半端ない人で、時々自虐ネタをやりすぎる感じはあるんだけど、トータル的には得るものしかない感じで楽しんだ。

そう言えば、今書きながら思い出したけど、岡嶋さんの以下も電子版で買って読んだのだった。

擬人化でまなぼ! ネットワークのしくみ

擬人化でまなぼ! ネットワークのしくみ

  • 作者:岡嶋 裕史
  • 出版社/メーカー: 翔泳社
  • 発売日: 2016/02/19
  • メディア: 単行本(ソフトカバー)
擬人化でまなぼ!  ITインフラのしくみ

擬人化でまなぼ! ITインフラのしくみ

  • 作者:岡嶋 裕史
  • 出版社/メーカー: 翔泳社
  • 発売日: 2016/10/18
  • メディア: 単行本(ソフトカバー)

これもいずれもすごく面白い(とくにネットワークの方)のだけど、どちらもちょっと二次元系エロ要素とも言えるものが少なくなくて、あんまり大きな声でこれを「読みました!」とか「オススメです!」とかは言いづらいのがなんというか……。
内容的には本当に丁寧&幅広い解説で良いんだけど、そういうある種の趣味的要素にウッとなってしまう向きにはあまり勧められないというか。
(実際、ここで紹介するかも一瞬迷ったけど、やっぱりすごく参考にはなったので紹介した)

ちなみに、インフラ編の方は前著(ネットワーク編)が好評で作られたのかな、と思ったけど、ネットワーク編に比べるとちょっとキャラクター同士の会話が冗長な感じで、もう少し時間をかけて作ってほしかったかなあ……と、もはや誰目線なのかわからないが思ったので合わせて記しておく。

経緯

さて、そもそもなんで基本情報技術者試験? という話なんだけど、資格試験としては上にもちらっと書いたように、以前に日商簿記を受けたことがあって、ある意味ではその延長というか、ヴァリエーションみたいなものとして、「そういう資格があれば今後の人生、多少なり生きやすくなるのでは」みたいなこともあったのだけど、とはいえ、その選択肢にどうして基本情報技術者試験が入ったのか? ということで言うと、直接的にはまず以下の @songmu さんのツイートを見たということがあって。


へえ、面白いな、いずれやってみたいな。とか思って、でもしばらく忘れていたんだけど、その後にちょまどさんの以下のインタビューを読んだら、

https://codeiq.jp/magazine/2016/03/39334/codeiq.jp

 どれもこれも、最初は、何が書いてあるのかサッパリわからない。そしてその先には途方もなく広い、全くの未知の世界がある。その不思議な魅力にどんどん引き込まれました。右も左も分からない当時の私には、体系立った教材が必要で、その教材として、基本情報技術者試験を選びました。書店で教科書が買えるので。
 そして本当にたくさん勉強して、合格しました。理系の情報系の人たちにちょっとだけ追いつけたみたいで、とても嬉しかったです。その次は、応用情報技術者試験も合格することができました。
(※太字引用者)

ひえ〜、すげえ。応用も受かっちゃったのかよ。と、ここでかなり刺激を受けたのが大きかったと思う。

と言っても、前者の @songmu さんのツイートは2014年で、ちょまどさんのインタビューも去年の3月とかなので、その後もすぐには行動に移したりしていなかったのだけど、去年はなんというか、だんだん自分の今やっている仕事について、「いつまでもこの心地よいルーティンを繰り返していていいのかな……良くないよな……むしろ不安……」みたいな思いが徐々に強まってきて、それで大きめの作業が収まった年末から一念発起的にとりあえずITパスポートの勉強から始めた、という次第だった。

勉強した感想

勉強の結果としては冒頭に書いたとおりなんだけど、短期間ながらいろいろ勉強してとくに実感したのは、以下の2点。

  • ぼくは算数ができない
  • ぼくは長文が読めない

ぼくは算数ができない

まず算数について。ぼくは5才から13才ぐらいまで公文式に通っていて、13才のときにたしか高1ぐらいの数学をやっていたので、そこまでの学力は結構あったのだけど、そこで公文式をやめてしまって、かつ高校の数学の先生が非常に自分と合わない人だったのもあって、高校からの数学っていうのがまったくわからないまま年をとってしまった。

でも、「子供の頃は算数ができた」という妙な成功体験だけは残っていたから、今までずっと意識していなかったんだけど、今回つくづく思ったのは、もう数学以前の算数的なことから苦手になってるな……ということで。

とくに割り算。割り算が必要な場面になるたびに結構混乱して、もしかしたらこれ、子供のときからちゃんとわかってなかったんじゃないか? 「雰囲気でやってた」んじゃないか? みたいなぐらい、「え、なんでそれでそれを割ると答えが出るの?」みたいなことだらけで本当に落ち込んだ……。

割り算にかぎらず、情報技術者試験ってとにかく計算が必須になる問題が多くて、単純計算でも何度も計算を重ねないと答えが出ないやつとかがあって、その繰り返しをしているうちにどんどんエネルギーを消費してしまうというか。

もしある程度計算や算数に耐性というか、体力があれば、もう少しスイスイできるんじゃないか、という場面でもぼくはその計算作業で非効率に体力を使ってしまって、リソースを適切に配分できてないなあ……ということを身にしみて思った。

つまり、とにかく算数。計算。その辺の基礎体力をつけて、苦手意識を直さないと、このままこの勉強を続けること自体つらそう……みたいに思ってる。

ぼくは長文が読めない

もう一つ、長文の件。長文なんて、むしろ本職じゃん、いくらでも読んでるし、まさにこのブログがそうであるように自分でも書いてるじゃん、そしてそれを何度も読み返しては何度も直してるじゃん、みたいな感じなんだけど、そういうことではなくて、問題文の長文って、実際には出題者の頭の中にあるイメージというか、「こういう状況をまず前提として設定しておきますね」みたいな話を受験者の頭の中で再現する必要があって、その「出題者の頭の中にあるイメージを自分の頭で再現する」という行為が、非常に自分には難しかったということ。

これがたとえば、村上春樹の小説を読むとかだったら、読者が一人ひとり好きなようにその文章から情景を想像すればいいことなんだけど、問題文の文章っていうのは、受け手によって想像するものが「みんな違って、みんないい」みたいなものじゃ駄目なわけで、一意の像を頭の中で結ぶ必要がある。にもかかわらず、どうもぼくの能力として、その出題者のイメージというか、意図を自分の頭で再現する能力というのが非常に少ないな……と痛感する場面が多かった。

で、その原因はある程度想像できて、それは共通のコンテキストを持ってないというか、前提にしている文脈を共有できてない、というのが主要因だろうと思ってる。
より簡単に言うと、ぼくの持っている知識が少ない。

実際には、まあ出題者の日本語がもう少し上手なら……とかも思わなくもなかったのだけど、結局問題文が同じである以上、他の受験生とも条件は同じなのだから、それはそれとして受け入れるべきだと思ってる。

その上で言うと、「わかりづらい文章」っていうのは、結局「省略しちゃいけないところを省略してる」からわかりづらい。執筆者としては「当然、これはわかってるよね。だから省略しとくよ」みたいに、それはもう無意識レベルも含めて省略してるところであって、でもそれを読んでわからない人っていうのは、その省略されたところが本来それを理解するために必要な要素なのに省略されてしまっているからわからない、ということがままあると思う。

ぼくは職業病なのか、そういう長文の問題文を読んでいても、全体の整合性とかを気にして、「なんでこの部分の説明がないんだろう……隠された意図とかあるのか……?」とか悩んで、すごい時間をかけてその不明部分を妄想で埋めながら問題を解いて、解答と突き合わせると、あたかもそんなことはまったく問題でなかったかのように「当然ここはこうだよね」みたいな、暗黙の了解的にさらっとスルーされていた、みたいなことが多々あって、だから試験の少し前ぐらいになってようやく、「長文問題、そんな厳密に読んじゃ駄目だ。もっと雑に読まなきゃいけない。だって、誰もそんな細かいこと気にしてないんだから」と、方針を立て直したりもした。

その「雑に読む」というのは、単に斜め読みするとかではなくて、あくまで出題者の意図を踏まえながら、ということ。出題者の頭の中には明確なイメージがあって、でも出題者は日本語の文章を通してしかそれをぼくら受験生に対して伝えることができないので、ぼくらもその文章を通じて彼ら出題者が言いたいこと、そのイメージを受け取らなきゃいけない。

おそらくは出題者的にも、「あまり長すぎてもいけない。最小限の文章量で表現しなくては」みたいになってるはずで、だから図や表と組み合わせながらそういう問題ができていると思うのだけど、とにかく今回の学習過程においては長文の問題を読むってこと自体がつらく、「ああ、俺これ、全然向いてないかも……問題がなに言ってるのか、全然わからないもの……」と、何度も絶望したものだった。

C言語から表計算へ

すでにだいぶ長くなってしまったけど、もうひとネタ。

午後試験のクライマックスとも言えるプログラミングの問題で、基本情報技術者試験の場合はJava、C言語、COBOL、アセンブラ、表計算、の中からひとつ選んで回答する、という問題があるのだけど、これをぼくは最初は「C言語」で受けようと思ってた。

というのも、元々C言語は今後プログラミングの勉強をしていく上で、それ自体を書かないとしても新たな言語習得に際してきっと助けになるだろうと思っていて、この機会にC言語学習の必要性というか口実を得られれば、より一生懸命勉強せざるを得ないというか、必然的に知識も経験も積んでいけるだろう、という目論見があったから。

なのだけど、これが何度過去問を解いてもまったく点数を取れない。基礎構文はそこそこ理解というか、把握できているはずなのだけど、問題になるとまったく結果が出ないというか。

今思えば、それは単純に問題練習の数が足りなすぎるというか、その20倍ぐらいやって初めて、玉ねぎの薄皮が剥がれていくように結果が表れたのかも、とも思うのだけど、そのときはすでに試験が近づいていて、そこで比較的簡単と言われている「表計算」の方にシフトするかすごく悩んで、結局方針転換することにした。

表計算、というのはようはExcelで、「いやあExcel、今から勉強したくない……いや、むしろその方が社会的・業務的には役立つだろうってわかるけど、でもなんかそれはそれでExcelの軍門にくだるようでちょっと悔しい……」みたいな心境ではあったのだけど。

でもこのまま、勝負にならない勝負をして悔しい思いをするよりは、と意を決したのが、今手元の記録を見ると3/29。試験のほぼ2週間前だった。

で、結果的にはこれは良い判断で、過去問レベルだったら試験前の段階で基準を超える正解率を出すことも増えてきて、これがC言語のままだったら他をいくら頑張ってもカバーしきれなかったと想像してる。

それにしても、このプログラミング問題、JavaとC言語と表計算まではわかるけど、COBOL、アセンブラが選択肢って……とくにアセンブラ。本当にそれ「基本」なのか? いいのか、それで……? という感じがする。どうなんだろ……。

ぼくがそこそこ馴染んでるPerlとまではいかなくても、Rubyとか、PHPとか、なんかそういう、それこそすぐに仕事で役立つかもしれないものにもう少し寄せられないのか……という気もするんですがどうなんでしょうね……。
それとも結構、使われてるんだろうかアセンブラ……。

謝辞

そろそろ締め。ここまでにとくに触れていなかったんだけど、そして上では「短期間のわりによく頑張った」みたいなことを書いたのだけど、実際にはこの学習期間に得た知識だけではこれだけの得点はできなかったと思っていて、やっぱり2013年から参加しているPerl入学式の経験は非常に大きなアドバンテージになってたよなあ、とすごく思ってる。

もちろん、そこで知ったことがすべてなわけではなくて、それを起点に自分で勝手に調べたり作ったりしてきたいろんなことが全部、これまた玉ねぎの薄皮のように積もり積もって身になってた、ということだと思うけど、それでも最初にあのプログラミング講座がなかったら、自分の努力だけでここまで続けてくることはできなかったと思うので、Perl入学式の運営各位には本当に心から感謝しています。

今後

ということで、結果としては駄目だったもののそれなりに成果は上がってきているので、なんとかこのまま勉強は続けて次はパスしたいなあ、と思ってる。

実際には、次の情報技術者試験はおそらく10月半ば、これって自分の業務が一年を通して最大ピークの時期と思われるので、その頃に本当に学習&受験できるのか、ということはまったく不明なのだけど……。

ともあれ、ひとまず今回の一連のトライのまとめは以上。
俺、おつかれ!

最近よく使っている自作ツール(3) select.pl

TL;DR

www.youtube.com

ちょうどひと月ぐらい空いてしまいましたが、以下のシリーズの続きです。

note103.hateblo.jp

note103.hateblo.jp

今回は、複数のファイルを直感的に選択して、それらに同じコマンドを渡すためのツールです。

リポジトリは以下。

GitHub - note103/select

で、いつものようにLICEcapを使ったGIF動画と、文章による説明とを組み合わせつつ記事を作ろうかと思っていましたが、けっこうそれも大変なんだよなあと思い直し、それでこのところ「音声入力による文字起こし」の実験をする過程で泥縄的に身に付けたスクリーンキャスト的手法で紹介してみようか、と思って作ったのが冒頭の動画(YouTube)です。

説明としてわかりやすいかどうかは不明ですが、文章で全部書くよりはずっとラクでした。

で、とはいえ、それだけではいろいろ情報が不足するだろうと思って、その補足ぐらいは文章で補おう・・と思っていましたが、やっぱりそれもまた面倒というか、いや面倒ならやらなければいいのですが、いや説明はしたい、そもそも自作ツールを紹介したいからわざわざこんな記事を書いているのだ、ということで、それならいっそその動画で喋った音声もそのままGoogleドキュメントの音声入力機能でテキスト化しちゃえばいいのでは、と思ってそうしてみました。

で、さらにその際、なんだかメタっぽいですが、せっかくなのでその音声入力による文字起こしの模様も動画に撮ってみたので、記事の最後に貼り付けておきます。興味のある人はご高覧のほど。

ということで、上の動画で喋った内容をGoogleドキュメントの音声入力でテキスト化した上で、簡単に手直ししたもの(それでも40分ぐらいかかったけど)を以下に掲示して本記事を終わりたいと思います。

このシリーズ自体はまだ続きがあるので、また時間ができたら更新したいと思っています。

Transcript

[00:00]

  • ええ、はい。今日はですね。これ、プログラミングの、いつも練習をですね、記録しているブログに、動画でですね、ちょっとのせてみようかと思っておりまして。
  • `test`っていうディレクトリで、ちょっとやってみようかなという感じですけど。
  • 今日紹介したいコードはですね、`select.pl`ってやつで。詳しくはですね、GitHubとかにも上げてるはずなので、ブログの方で紹介したいと思いますけども。
  • 私は今この`e`っていう名前のエイリアスを入れてるんですけども。
  • こんな感じですね。複数のファイルをこんなふうに選択して、選択するとこういう`+`マークがつくんですね。
  • で、デフォルトでただ`e`って入れるだけだと、echoするよって、選択したファイルを全部echoするよ、みたいな感じになるんですね。
  • で、そのままやっていいかなってなった場合は……(実行)はい、ちょっとわかりづらいですけど、フルパスで全部出るんですね。3つファイルがあってですね、全部echoされたと。

[02:00]

  • で、それの何が嬉しいのって感じなんですけど、eあるいはそのselect.pl をこれPerlで書いてるんですけど、実行するときの引数にですね、コマンドを何か入れると。たとえば、こんな感じでcatするよと。`e cat`って入れて、 `yes` ってやるとですね。
  • この`project1.txt`ってやつの中身がcatされて、`project3.txt`の中身もcatされて、みたいな感じでですね。ようするに、複数のファイルを選択して、それに同じコマンドを渡すみたいなことをやりたいと。
  • んで、そんなのべつに普通にやればいいんじゃないの、みたいな感じもするんですけど、なんでこんな、ハッシュ値が入っているような長いファイル名にしているのかっていうことが、これを作った理由を示しているんですけど。
  • これをですね、たとえばcatしようって言ってですね。project2なんかを選ぼうと思ってもですね、めちゃくちゃ長いファイル名だと、めんどくさいわけですね。
  • たとえばproject2と、なんかを選びたいなと。projecct2とproject4を選びたいなってときにですね、2015……とか書いても、これでタブを押しても駄目なんですね。2016の……05の……とかやってるとですね、いつまでも選択が終わらないぞ、みたいな。
  • 2017のこれを選びたいので‥‥とかやってもですね、めんどくさくてしょうがないですね。
  • まあ、できますけど、それもこれでやれば、これで選ぶと、楽ですよね。
  • ちなみにもう1回選択すると、消えたりとかするんですけど。
  • まあ、それだけっちゃそれだけですけど(笑)。

[04:40]

  • あとついでにっていうか、`de`っていうエイリアスを仕込んでるんですけど、これ消したいなという時ですね。複数のファイルを消したいと。
  • そういう時は、これ私は`trash`っていうコマンドが入ってるんですけど、ない場合は、まあ`rm`とかでもいいんでしょうかね。
  • 私はこれを仮のゴミ箱がこういう場所にあるんですが、ここにtrashしたいと。(実行)で、どうなったかっていうとですね。1,2,4のファイルしか、もう残ってないと。
  • 複数のファイルをどっかに飛ばしちゃいたいという時にこれはよく使いますね。
  • あとまあ、ちなみに、不可視ファイルをですね。捨てたいなっていう時も時々あるんですね。
  • そういう場合は、`de.`っていうのでやると、ちゃんとそれも飛んでってくれると。
  • 逆にっていうか、そのまま`de`だけだと不可視ファイルは出ないようになってるので、こういうコマンドならこれも消せるよと。
  • そういう感じにしてたりします。

[06:30]

  • あとは複数じゃなくて、1個だけファイルを選んで何かやりたいっていう時は、また別にこれだけで済ませるコマンドを作ってるんですが、またそれは必要があれば紹介するかもしれないですけども。
  • まあどんどん消しちゃって。無くなっちゃいますけど。
  • という感じで、そういうselectコマンドを紹介してみました。

余録

www.youtube.com

※音声入力による文字起こしについては以下をご参照。
21世紀の文字起こし - the code to rock
21世紀の文字起こし(2) - the code to rock

補足

動画の中で、エイリアスのことをちらちら言っていました。補足的に以下に示しておきます。

alias e="perl /path/to/select.pl"
alias de="perl /path/to/select.pl 'trash -r'"
alias de.="perl /path/to/select.pl -a 'trash -r'"

alias d="sh /path/to/delete.sh"
alias d.="sh /path/to/delete.sh -a"

最後にオマケ的に紹介していた`d`, `d.`などは、すでに前回紹介していたdelete.shのエイリアスでした。
最近よく使っている自作ツール(2) delete.sh - the code to rock

プログラミングを学ぶ理由

ひさしぶりに彼女とお茶を飲んで、まったり雑談していたら、不意に

あなたがそんなに好きなプログラミングっていうの、私に教えてみてよ

と煽ってきたので、彼女のMacBook AirのシステムPerlで、ターミナルから「Hello」が出力されるだけのコードを目の前で書いてみた。

print 'Hello';

これをhello.plで保存する。
shebangさえ付けない。改行も入れない。ほんとに最小限。

実行。

$ perl hello.pl
Hello

この「Hello」って書いてある部分を書き換えると、出力される内容もどんどん変わっていくんだよ、と言ってそこをいろんな数字や言葉に置き換えていく。

print 'Hi';

実行。

Hi
print 1234;

実行。

1234

ほらね、という感じで様子を見ると、「これの何が面白いのか、まったくわからない」と言う。

なんで「Hello」って出さなきゃいけないの? 「1234」ってなに? 何か意味あるの? と言う。

あなたもPerl入学式で、人に教えたりするの? それはすごいね。私みたいな人だったら大変じゃない? だって本当に、何もわからないんだから。と言う。

いや、そうじゃない。とぼくは言う。

問題は、プログラミングをやりたいと思っているかどうかなんだよ。「わからない」なんて当たり前なんだよ。だって、最初は誰だって何も知らないんだから。

でも、「プログラミングをやりたい」って思う人は、わからなくてもわからないままやるんだよ。わからなくても、わかるまでやる人が「プログラミングをやりたい人」なんだ。

だから、そういう人に教えるのは何も難しくない。その人がわかるまで付き合ってあげればいい。「わからない」なんて前提なんだ。わからなくても、それはつまずきでもなければ間違いでもない。息を吸ったり水を飲んだりするのと同じだ。それは必要なことですらある。だから困ったりしない。

難しいのは、「プログラミングをやりたくない」という人に教える場合だと思う。そういう人にとっては、「わからない」ということが致命的な問題になる。「何のためにやるのか」ということが問題になる人に教えることは、だから難しい。

「プログラミングをやりたい」という人は、すでに「何のために」がはっきりしているか、そんな目的すらなくてただ何となく「やりたい」という人だから、ぼくらがわざわざ「プログラミングが何の役に立つのか」とか、「どこが面白いのか」なんて教えてあげる必要はない。その人たちはすでに学ぶこと自体を楽しんでいるし、「わからないから」という理由でやめたりはしない。

でも自分以外の意志によってやらされている人は、何かそれを「やる理由」がほしいと思うだろうね。「楽しみ」や「目的」を外部から提供してもらう必要がある。それが悪いってことじゃない。自然なことだ。ぼくだってプログラミング以外の何かに関してはそうだと思う。

そのうち小学校とかでもプログラミング教育をやるらしいけど、それはまた別の話で、基礎的な教養として教えるものだろうから、算数や漢字や英語に馴染ませるようにプログラミングに馴染ませるのはいいことだと思うけど、そういうことじゃないなら、まあ、やりたい人がやればいいことで、ということは「プログラミングの何が面白いのか」を他人が教えてあげたり、他人から教えてもらったりする必要はどこにもないってことになるだろうね。

MacVimで簡単にウィンドウを切り替える

なぜ今まで気づかなかったのか……? たまたまキーを打ち間違えたら実現した。

f:id:note103:20170225164346g:plain

コマンドを押しつつ「 [ 」か「 ] 」を押すとどんどんウィンドウが切り替わる。
これ、今まで一番欲しかったやつや!!

Excelで複数のファイルを開いているとき、コントロール+TABを押すとどんどんウィンドウが切り替わるので、それのMacVim版が欲しい〜……でもそういう機能はなさそう〜って、ずっと思っていた。

で、今あらためてメニューを見直したら……

f:id:note103:20170225165029p:plain:w350

ちゃんと書いてありましたね……こういうの、結構チェックしている自覚だったけど全然見てなかった。

最近よく使っている自作ツール(2) delete.sh

前回に続き、掲題の件。
前回の内容は、以下。

note103.hateblo.jp

今回紹介するのは、以下。

github.com

と言っても、シェルスクリプト1本ですが。

このツールには前段があって、以前にこのブログでも紹介した「trash」というソフトウェアがあるのだけど、

note103.hateblo.jp

github.com

今回のツールはそれを自分なりにアレンジしたもの。

DEMO trash

先に、その元ネタになったtrashの方を簡単に紹介すると、使い方としてはこんな感じ。

f:id:note103:20170218145111g:plain

trashというコマンドの引数にファイル名を入れると、そのファイルを任意のフォルダへ移動してくれる。
ディレクトリを扱う場合はオプション「-r」を付ける)

その移動先が「仮のゴミ箱」みたいな役割を果たすので、いきなりrm -rfとかするより安全でいいよね、しかもコマンドラインからの簡単な操作で不要なデータを捨てられるのでいい感じだよね、みたいな話。

ただこれの場合、ちょっと面倒なのは、いちいち対象のファイル名を自分の手で打ち込まなければいけないところ。

上のデモのようなシンプルなファイル名なら指定しやすいけど、たとえばこんなファイル名がうごめくカレントディレクトリだったりすると、

2016-04-22-project1.txt
2016-05-14-project1.pdf
2016-05-24-project2.txt
2016-05-25-project3.md
2017-05-26-project4.txt
2017-06-26-project5.md

何回タブで補完しても他のファイル名と共通する文字列でいちいち詰まってしまって、目当てのファイルを指定しきるまでになかなか厳しい思いをすることになる。

そこで、こういうファイル群からプルダウン的に(ファイル名を打ち込まなくても)対象を選択できるようにしたいなあ、と思って、例のごとくpecoとchoをこれに結びつけたのが今回のスクリプト

DEMO delete.sh

f:id:note103:20170218145211g:plain

「d」を叩くとカレントディレクトリ内のファイルやディレクトリがバラララッと出てくるので、あとは画面を見ながら対象を選択。すると、それが任意のゴミ箱へ飛んでいく。

(「d.」を叩くと不可視ファイルも候補に含まれる。いずれも後述のエイリアスで設定する)

移動先のゴミ箱は初期設定だと「$HOME/.Trash」(Macのゴミ箱)になっているけど、.bash_profileからTMPTRASH変数に設定すれば自由に置き換えられる。

# ホームディレクトリ直下の tmp_trash/ をゴミ箱にする場合
export TMPTRASH=$HOME/tmp_trash

なお、前述のとおりchoとpecoを使っているので、それらも要インストール

前回紹介したchoco同様、オプションで-aを指定すると不可視ファイルも扱えるようになり、-pを指定すると選択ツールがchoからpecoになる。

よって、それらを組み合わせたエイリアスを設定するならこんな感じ。

alias d="sh /path/to/delete.sh"
alias d.="sh /path/to/delete.sh -a"
alias dj="sh /path/to/delete.sh -p"
alias dj.="sh /path/to/delete.sh -ap"

ちなみに、このエイリアス例にある「d」はdeleteのdだけど、「j」にはとくにそういう意味はない。

jは単に打ちやすいから使っているのと、僕の場合は「pecoを使う時のエイリアスはjにする」という暗黙のルールみたいのがあるのでそうしている。

なんにせよ、これらのツール&設定により、「このファイルちょっと作業の邪魔だな〜。ゴミ箱に移動しとこ」と思ったらポンと「d」を叩くだけでサクサク選択&ポイできる。

一方、このツールだと1回のアクションで捨てられるデータが1個だけなので、複数の対象を選択してポイできるようにしたいなあ、と思って作ったツールもあって、次回はそれを紹介したい。

最近よく使っている自作ツール(1) choco

プログラミングの学習にともない作った自分用のコマンドラインツールというものがあって、折りに触れこのブログでも記録&紹介しているのだけど、それでも以前に紹介した後に手元でどんどんアップデートしつつも外には出せていないものや、新たに作ったけど自分しか知らないツールというのもあって、少しずつでもそういうのをあらためて紹介していきたいと思ったのでそうする。

リストアップしてみたら結構な数になったので、何回かに分けるかもしれない。(いま書きながらどうするか考えている。書き終える頃にはどうなるか決まっているはず)

choco

まずはこれまでも何度か紹介している以下の最新版。

github.com

mattnさんによるchoと、lestrratさんによるpecoを使って、ディレクトリをスイスイ移動したり、移動した先で選択したファイルをオープンしたりする。

choで移動しているところ

f:id:note103:20170217202617g:plain

pecoで移動して最後に選択したファイルを開いているところ

f:id:note103:20170217202639g:plain

オープンするやつはmacOSのopenコマンドを使用しているので、他の環境でどうなるかはわからない。

たぶんコンピュータを開いて作業している日のうち、これを使わない日はないと思う。
我ながらすごく便利だし、俺グッジョブという感じ。

(いやもちろん、mattnさんやlestrratさんのおかげなわけですが)

名前

以前はこのツール、 "dirmove" という名前にしていたけど、それだとファイルやディレクトリ自体を移動させる意味が含まれてしまいそうなのと、移動先のファイルを開く、という目的も大きくなってきたので名前を変えたいと思い、choとpecoを使っているので合わせて "choco" にした。

これ自体は作業のメインに使うものではなく、単にちょこちょこ動きたいだけ、というグルー(のり)的な道具なので、意味を限定しすぎず、なおかつちょっと可愛い感じで良いネーミングではないかと自分では思っている。

懸案

メインのコードはPerlで書いているが、コマンドラインから居場所をどんどん移動して、なおかつ移動先に着地しなければならない都合上、bashrcにも少なからず記述が必要になる。

詳しくはREADME.mdを参照してほしいが、現時点ではこんな感じ。

# .bashrc

function dirmove {
    local result="$1"
    local basename=""
    local dirname=""

    if [ -e "$result" ]; then
        basename=${result##*/}
        if [ -f "$result" ]; then
            dirname="${result%%$basename}"
        elif [ -d "$result" ]; then
            dirname="$result"
        fi
    fi
    cd "$dirname"
}

function choco {
    local command="${@:$#}"
    local result=$(perl ~/path/to/choco/choco.pl "$@")

    if  [ $# = 0 ] ; then
        command=echo
    elif [[ "$command" =~ - ]] ; then
        if [[ "$command" =~ p ]] || [[ "$command" =~ a ]]; then
            command=echo
        fi
    fi

    if  [ -e "$result" ]; then
        dirmove "$result"
    fi
    $command $result
}

alias s=choco
alias s.="choco -a"  # 不可視ファイルを対象に含める
alias j="choco -p open"  # pecoを使う
alias j.="choco -ap open"  # pecoを使って不可視ファイルも対象に含める

zshだとどうなるか、とかはわからない。

上では関数を二つ書いていて、chocoというメインの関数の他にdirmoveという関数を分けて作っているのだけど、これは後日紹介予定の別ツールでもそのdirmove関数を使うから。
逆に言うと、chocoしか使わないならこれらを一つの関数に合わせてしまってもよい。

いずれにせよ、けっこう行数があるので、シェルスクリプトのファイルに切り出した方が良いのではないかと思って何度か試したのだけど、前述のとおりディレクトリを移動するためにはbashrcへの記述が必須のようで*1、仕方なくbashrcにいろいろ書くことになってしまっている。

最後にエイリアスをいくつか設定しているが、ようはデフォルトだとchoを使うようになっていて、オプションとして -p を指定するとpecoを使うようになり、また -a を指定すると不可視ファイルが対象に含まれ、さらに引数の最後にopenコマンドを入れると最終的に選択したファイルがオープンされる、という感じ。

次回予告

似たようなツールを少なくとももう一つ紹介するつもりだったが、結構長くなったのでここまで。

ブログ記事1本あたりの負担を軽減してコンスタントにパブリッシュできるようにしたいところだけど、どうなるか……。

*1:たとえば「start/path/to/end」というディレクトリ構造で、「startから移動してendのディレクトリに出たい」というときに、それらの関数をbashrcではなくシェルスクリプトなどに書くと、操作中はあちこちに移動できるのだけど、操作を終えるとstartに戻ってしまう。