Qiitadonについて語る

f:id:note103:20170602192506p:plain

f:id:note103:20170602192525p:plain

というわけで、Qiitadonについて書いてみたいと思います。

Qiitadonは、今週の初めにオープンしたQiita/Incrementsによるマストドンインスタンス

qiitadon.com

公式アナウンスはこちら。

速報系としてはこの辺とか。

その他、マストドン全般についてはITmediaの以下の連載を見ていればほぼ100%追えるはず。
www.itmedia.co.jp

初期の盛り上がりみたいなものについてはぼくもこの辺に書きました。
scrapbox.io

もうひと月以上経ってるのかあ……。

さて、そのQiitadonですが、IT企業系だとぼくの知るかぎりpixivのPawooドワンゴfriends.nicoに続いて3つめの参入。

pixivもドワンゴ(というかニコ動)もそれぞれ核となる自社サービスおよびそのコミュニティみたいなものがあって、それと連動した感じで展開していることを思うと、たしかにQiitaもそういう面があるので、それでやることにしたのかなあ、とも思ったり。

一方、friends.nicoは先行するmstdn.jpにちょっと似て、ノンジャンルに近いインスタンスに見えるんだけど、Pawooは明らかに絵に関心が強い(描くのも見るのも)ユーザーが集まっていて、その意味ではQiitadonはすでに技術系のネタに興味のある人が集まっている感じがするので、Pawooに近いように思える。

さらに一方、Pawooの方はけっこうどしどし投稿が流れていくんだけど、Qiitadonの方はそうでもない。
これはたぶん、Pawooの方は半匿名的に参加できたり、自分の作品をどんどん投稿していくような文化があるのに比べて、Qiitadonの方はけっこうリアルな立場で参加している人が多そうというか、なんか変なことゆったときに自分がこうむる影響が少なくなくて、それで若干自重ぎみになるのかなという感じはする。

マサカリ回避傾向というか。

まあ、とはいえ個人的にはそれはそれ、ひとつの特色というか、インスタンスごとに持っている性格の一部として捉えればいいのではとは思っている。

その話にもちょっと近いけど、Qiitaにはすでにけっこう独特のコミュニティ感みたいなものがあって、個人的にはちょっとはてなに似ていると思ってる。

最近だとコミュニティ・ガイドラインを発表したら軽く賛否両論になったり。*1 *2

まあ、話題にのぼるというのはそれだけ関心が寄せられているということだから、それ自体はいいことだろうけど、どうも中の人の意向がうまく外部に届いてない気がするなあ、という印象は持っていた。

賛否両論の「否」の方がなんで出てくるのかっていうと、いろんな要因があるとは思うけど、けっこう大きいのは「中の人からの反応がナイから反応が来るまで強く叩いてしまう」という、人間が本来的に持っているある種の幼さというか、抱えたフラストレーションを我慢できずに発散してしまう、みたいなところがあるんじゃないかと個人的には思っている。

Qiitaはその辺に対しても真摯に取り組んでいるとは思うのだけど、そこでさらにこのQiitadonが機能することによって、その辺の「ユーザーと中の人との間を埋める潤滑油」みたいな感じになるのでは、とちょっと期待している。

もう少し具体的なことでも、いろいろ期待できることはある。

たとえばこれも「隙間を埋める」という感じだが、「ちょっとした技術系の気づきを得たけどQiitaに書くほどのボリュームでもない」とか、「Qiitaに書くにはちょっと技術要素が弱い(いわゆるポエム)」みたいな話について、さらっと投稿できる場所になれば良さそうだと思う。

案外、人は最初のきっかけというか、入り口さえ見つかってしまえば、だんだん書いているうちに「ちょろっと書くだけのつもりだったのにけっこうなボリュームになったな」みたいなことになりがちなので*3、Qiitadonが呼び水になってQiitaへの記事投稿につながるかもしれないし、自分では「大したことない」と思っていたネタが思いのほか多くの人に役立った、なんてことにもなるかもしれないし。

Qiita本体は上でもちょっと触れたように、ガイドラインが必要になるほど「どこからどこまでが《技術ネタ》なんだ?」みたいな範囲の問題とか、あるいは「こんなネタ誰も必要としてないよな……」みたいな基準的なことで投稿を躊躇してしまう部分もあるかもしれないけど、Qiitadonの方は、

技術に関する話題に限らず、気軽に投稿してください:)

とのことなので、いろんな意味で基準ゆるめで使ってみればいいのではないかと思う。

ぼくは今までmstdn.jp, Pawoo, friends.nico というインスタンスを使ってみたけど、やっぱりマストドンってローカルタイムラインがけっこう特徴的というか、それを見て楽しめないと単に「500字書けるTwitter」というだけみたいになりがちなので、現在ノンプログラマーとしてプログラミング入門中の身としては、技術ネタの多いこのインスタンスは大変貴重でありがたい。

今は試験公開中ということだけど、そんなにほんと大盛り上がりとかはしなくてよいので、細く長く続いてほしいなあと思っています。

ノンプログラマーに求められるもの

ノンプログラマーがプログラミングを覚えることにより普段の業務負担を軽減させる、みたいな流れが徐々に活気を帯びてきたというか、この本なんてその象徴のようにも思えるのだけど

www.oreilly.co.jp
ふと我が身を振り返ってみると、ぼくが趣味でプログラミングをやってるのって、そういう理由というか目的というかモチベーションではあまりなくて、もちろん、そういう効果があれば嬉しいし、実際にはあちこちで発信しているように、プログラミングを習得すればするほど「今までこの作業ってVimPerlやGitを使わずにどうやってたんだっけ……思い出せないし思い出したくもない……」と思うぐらい様々な負担が軽減、またはそもそも不要になっていたりするのだけど、でも気持ち的に、なんでプログラミングをもうかれこれ4年近く続けてやってきたのかっていうと、それはたぶん

《日々の業務があまりに地味かつ長期的で、目に見える効果というものがわかりづらくて、それはまるで人が年齢を重ねていくような、「昨日と今日の違いがほとんど認識できない」ぐらいの変化の無さだから、そういうものとはまったく逆の「一瞬で目の前の世界がガラッと変化する」ような体験を求めて、プログラミングとかテクノロジーとかに希望を託している 》

ということなんじゃないかなあ、と思った。

言い換えると、日々の業務の負担が減るっていうのはたしかに嬉しいことで、村上春樹いうところの「小確幸」なわけだけど、じゃあそれがわざわざ貴重な時間を割いてまでやる「目的」とか「欲望の対象」になるのかっていうとそれにはちょっと弱くて、欲望の対象としてはだから上記の「これまでに見たことのない風景を見てみたい! 味わったことのない気分を体験したい!」みたいな気持ちがあって、結局はそれに向かって一生懸命コンピューターに向かい合ってるという感じがする。

それはほとんど人生を賭けた、生きる意味やテーマのような営みだから、その手段はプログラミングでなくたって構わないとも言えるんだけど、さしあたって現時点ではその過程にプログラミングがあるからそれに時間をかけている、というような。

でも実際には、プログラミングというのは自分が手を動かして英数字などを打ち込んでいかなければ(少なくとも2017年の現時点では)身についていかないわけで、頭の中で「こうなってほしい!」とか念じるだけでは出来てくれない。

何を言いたいのかというと、これってやっぱり一朝一夕に習得できるものではなくて、どうしても時間はかかるということ。

で、それって何に似ているかというと、たとえばスポーツとか、語学とか、あるいは楽器の練習。高い楽器を買って、さあやるぞ! となってもそれが身につくまではずっと自分の体を動かしてくり返し練習しなければならないわけで、さらにはそれを「趣味」でやるということは、普段の仕事は仕事として頑張った上で、その合間に、つまり本来なら娯楽を楽しんだりゆっくり体を休めたりできたはずの時間をつぶしてそれをやらなきゃいけない。

さらに言うなら、結局はそんなふうにわずかな時間を繋いでやっているだけだから、プロとしてやっている人たちとの差はみるみる開いていくわけで、いやそんなの当たり前なんだけど、でもどうしたって「自分より年下のあの人はあんなに出来るのに、なんで自分の上達はこんなにも遅いんだ……」って比べて思ってしまうのもまた自然というか。

つまり、趣味でやるっていうのは結構大変。上達の実感はいつも理想の遥か後ろを遅れてやってくるし、当初憧れたようには全然できないまま時間がどんどん過ぎていく。

それでもぼくがここまでそれを続けてきたっていうのは、だから「日々の業務の負担を軽減したいから」というだけのことではなくて、その向こうにある「なんか知らんけどスゴイ体験をしたい!」という感覚に揺り動かされてきたからだと思う。

そのある種の貪欲さというか、しつこさというか、諦めの悪さみたいなものに引っ張られてダラダラやっているうちに、結果として「なんか知らんけど業務もめっちゃラクになってる〜〜!」みたいなことがあるのかなと思う。

そんなことを踏まえつつ、冒頭に挙げた本のタイトルを見て思うのは、「コンピューターに退屈な作業をさせよう」なんて考えている自分自身はけっこう楽しい(退屈ではない)のだよな、ということ。

より具体的に言うなら、コンピューターにその作業をさせるためにちまちまコードを書いていく作業はけっこう楽しい。

さらに言うなら、そのコードを書く過程で素人なら必ずハマる。何度書き直してもうまく動かない。ちょっと、というかかなりイライラする。そして自分は自分で思っていた以上に馬鹿なんじゃないか? という底知れぬ不安に襲われる。もう何度も棚から取り出しては戻した参考書の、ついさっき見たはずの正規表現のルールをもう忘れてしまって、誰にも向けられない憤りにうんざりしながらまた棚から引き出す。頭はぐちゃぐちゃに溶けて煮詰まっているけれど、なんか踏ん切りがつかなくて深夜まで同じ箇所を修正し続けてしまう。そしてあるとき、突然視界がひらけるようにプログラムが動く。……お…おおおおお〜〜〜〜!!ってなる。……でも周りには誰もいないから、実際にはその叫びは頭の中だけに響いてる。深夜の静かなリビングで、自分とターミナルの黒い画面だけがある。

その無音なんだか轟音なんだかわからない一瞬の魅力に囚われてしまって、その景色をまた見たくて続けてるのかなっていう。

上では何度か「趣味」と書いたけど、だからこのような日々を送るぼくにとってはプログラミングを「趣味」と呼ぶのはちょっと違和感がある。
もちろん仕事なわけではないし、ましてや天職とか使命とかいう大げさなものでもない。

そうではなく、なんか本職でも娯楽でもない、「2つめの仕事」みたいな感じというか。
日本語ネイティブの人が英語も日常生活を送れる程度には喋れる、というときの「第二言語」としての英語みたいな。

そういえば最近、ラムダノートの鹿野さんが書いた以下の記事で、
employment.en-japan.com

IT系エンジニアとして仕事で使っているプログラミング言語ではない言語、つまり第二言語を学ぼうというシリーズ記事

というのが始まっていたけど、ぼくがここで言うのはそれの人生全般バージョンというか、能力としての第二言語、本職を支える副次的な素養みたいな。
そういうものとして、育てていけるんではないかなあ、という感覚が少しある。

その意味では、こういう自分のような人たちを「ノンプログラマー」であれ「非エンジニア」であれ、語の頭に否定形(ノンとか非とか)を付けた呼称で表すことには以前から違和感があったけど、たとえば「セカンドプログラマー」とか「オルタナプログラマー」とか、ぼくだったら編集をやっているので「エディター・プログラマー」とか、「*er Programmer」とか(読めない)、なんかそういう本職の方にフィーチャーした言い方がないかなあ、という気もしてくる。

「趣味」とか「アマチュア(愛好)」ではないのだよね。べつに愛でてるわけではなくて、自分だって早く風呂に入ってさっさと明日に備えて寝てしまいたいんだけど、どうしてもさっきwhileで無限ループした理由が腑に落ちなくて、何度もいろんな場所の変数の中身をプリントデバッグしていたらもう外が明るくなってきたとか、そういうのは愛好ではなくてもう狂気に近い。というか非常識。

上で挙げた鹿野さんの、以下のインタビューも面白かったんだけど

itpro.nikkeibp.co.jp

その最終回にあった以下のくだりが印象的で。

私がオーム社でやっていた本の作り方は、会社から見れば特殊な作り方です。私しか作れない本が増えてきてしまった。会社からは「ほかの社員もできるようにしてほしい」と言われて広めようとしたのですが、うまくいきませんでした。私たちと一緒に仕事するときはバージョン管理などの仕組みを使ってくれるのですが、そうした社員も自分から使おうとはしなかった。

この最後のところ。「自分から使おうと」するかどうか、というのは、ようは上に書いたような「気づいたら時間を忘れて夢中になってた」みたいな感覚があるかどうか、ということだと思う。

そういうのがなきゃ駄目、という話ではなくて、というか誰にだってそういうのはあるはずで、単に対象がプログラミングかそうでないか、という違いがあるだけだろう。

とくにまとめもオチもないのだけど、つまりはプログラミング、結構大変。ぼくの場合は大学も美大で、授業でプログラミングとかなかったし、初めてパソコン&ネットに触ったのは28才で、初めてハローワールド!出したのは38才。だから世代や環境が違えばまったく上とは別のことが言えるかもしれないけど、いずれにしてもこういう人がこういうことを続けるには、「目的」とか「目標」とか「覚悟」とかではなくて、自分でもコントロールできないそういうある種の過剰さみたいなものが必要なのではないか、という気がしている。

基本情報技術者試験の結果

元々はとくに報告する予定はなかったのだけど、ネタになりそうな結果だったので一応書いておく。

先月半ばに受けたこちらの試験。
note103.hateblo.jp

ちょうどひと月後の先週、5/17に正式な合格発表があり、成績(得点)も公開されたようだったのだけど*1、「どうせ駄目だから」と見るのは後回しにしていた。

それでもつい先ほど、ちょっと気になりはじめて見にいったら、やはり合格者一覧には自分の番号がない。

いやまあ、期待したわけではないけど・・でもちょっとは「もしかして」というのもあったかな。

いずれにしても残念。であり、まあ次に期待。

・・で、話は終わると思ったのだけど、ちょっと説明を読んでいたら試験の得点もすぐに参照できるという。

以前に受けた日商簿記の試験では、得点は後から封書で送られてきたので(といっても紙切れ一枚に最終的な合計得点があるだけで、どの問題で何点とれた、とかは一切わからない不充分なものだが)、これもそんな感じかと思っていたのだけど、さすがそこはITな試験で多少は効率化されている。

ということで、そのまま案内に沿って確認・・したら、午前試験は順当にパス。
で、午後試験が59.5点だった。

これはどういうことかと言うと、100点満点中60%以上とれば合格なので、あと0.5点とれば合格だったということだろう。

・・って、ギリギリすぎ!

いやあ・・自己採点では「多めに見積もって57点」とかだったので、その時点でも多少は「惜しかったなあ〜」なんて思っていたものの、さすがに「あと0.5点」まで迫ってるとは思わなかった。

まあ、もちろんというか、結局のところそんなギリギリのラインをうろうろしているようではそもそも駄目なんですよ、ということだとは思ってるし、基本情報なんて本当に入り口に過ぎないようなものなんだから、そんなところで一喜一憂してもしょうがないじゃん、というのもわかってる。

わかってますが、でもまあ、業務の合間にぜんぜん関係ないそれを勉強して、それなりの努力でそこまで行ったわけだから、やっぱりこれは「後悔」みたいな気分も生じざるを得ないですね・・見返りにつながらなかったことの残念さというか。
さすがに0.5点ぐらいなら、どっかもう一周見直したら拾えたかもしれないし。

次は秋かあ・・前にも書いたかもしれないけど、本当に業務ピークになる頃なので、それはそれで不安・・毎日少しずつでも精進しないと。

f:id:note103:20170522125757p:plain

(不合格の下線が胸にしみる・・そんな強調しなくても・・と思うけどこの方が誤解の余地がなくていいのかな)

*1:得点はパスワードを持った受験生のみ照会可能。

crontabでPerlスクリプトを動かそうとしてハマった話

crontabとは

以下がわかりやすいです。

www.server-memo.net

@songmuさんによる以下のシリーズも充実しています。
gihyo.jp

そのcrontabでPerlスクリプトを動かそうと思ったところ、以下のようなハマり方をしたのでメモ。

なお、環境はMacです。

crontabはシステムPerlで動く

最初にテスト的なコードを書いてみたらあっさり動いたので、逆に気づくまで時間がかかってしまったのだけど、たとえば以下のようなPerlのコードをホームディレクトリに置いておいて、

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

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

say "Hello!";

crontabをこのように設定してみると、

10 * * * * perl hello.pl >> test.txt

普通にtest.txtの中に

Hello!

が書き込まれていく。(この場合は毎時10分に「Hello!」が追記されていく)

ただし、このときにhello.plやtest.txtをホームディレクトリ以外の場所に置くなら、それは絶対パスで記述しなければならない。

10 * * * * perl $HOME/sample/hello.pl >> test.txt

とか、

10 * * * * perl /Users/note103/sample/hello.pl >> test.txt

とか。

そこまではまあ、そうだろうなっていう感じなんだけど、どうもタスクが増えるにつれて、その辺を正確に記述してもうまく動かないケースが出てきた。

具体的には、ターミナルで普通に実行するぶんには動くんだけど、crontabに設定すると動かないとか。

で、先に結論というか原因から言うと、上で何気なく記述している「perl」というコマンドが、普段ぼくが使っている「perl」とは別物だった。

ぼくは普段、plenvというのを使って、Perlの現状ほぼ最新バージョンである 5.24.0 を使っているんだけど、crontabはそのplenvとかは経由せずに、マシンにもともと入っているシステムperlを使っていて、ぼくが使っているMacのそれは5.18.2だった。*1

システムPerlに必要なモジュールが入ってない

で、しかしこれは単にバージョンが違うというだけの話ではなくて、システムPerlの方は何しろ普段は使っていないから、いつも使っている要インストールな非標準モジュール(厳密には5.18.2時点で標準モジュールではないそれ)が入ってない。

だから当然のことながら、そういうモジュールを使っているスクリプトは動いてくれなくて、けっこうハマった。

その後、これについては動作する/しない条件を手を替え品を替え特定していく中で、「うわ、これもしかしてシステムPerlで動いてるのか」と気付き、さらに「システムPerlにはあのモジュールが入ってないのか……」などと気付いていったので、とりあえずはシステムPerlにcpanmをインストールして(それも入ってなかった)、以後はcpanm経由で必要なモジュールをどんどんインストールして、なんとか動くようになった。

システムPerl以外のPerlを指定できない

それですべて解決かと思ったんだけど、どうも一個だけ、そこまで設定してもターミナルからの実行とcrontabでの実行とで動作の異なるものが残っていた。

具体的には、以下のようなコード。(実際にはちょっと違うけど、最小限の再現コード)

#!/usr/bin/env perl
use strict;
use warnings;
use feature 'say';
use LWP::UserAgent;

my $url   = "https://pawoo.net";
my $res   = LWP::UserAgent->new->get($url);
my $title = $res->title() // 'No title';
say $title;

これを普通にターミナルから(v5.24.0で)実行すると、こうなるんだけど、

Mastodon (マストドン) hosted by pixiv - Pawoo

crontabから(v5.18.2で)実行すると、こうなる。

No title

ようは後者だとLWP::UserAgentが望みどおりの挙動をしてくれてないということで、でもモジュール自体はシステムの方にも入っていることを確認したので、そうなると原因はモジュールの有無ではなく、Perl自体のバージョンが古いこと以外に思いつかない。

というか、それ以外の原因があるとしても、次に打てる対策は「とりあえずシステムPerlのバージョンを上げても同じ結果になるかを確認する」ということ以外に考えられないということ。

なんだけど、システムPerlのバージョンを上げるというのはちょっと聞いたことがなくて、実際Perl入学式の諸先輩に聞いても「普通そういうことはしない」という話だったので、そこでまただいぶハマった。

で、今サラッと書いたように、本件についてはここで一旦完全に行き止まりという感じになったので、Perl入学式のチャットルームで例のごとく先輩方に相談してみたところ、いろいろな対処法を教えて頂いた。

たとえば、先に.bashrcを読み込ませて、普段使っているplenvなりperlbrewなりを使うように設定するとか。
あるいは、ラッパースクリプトを介してplenvなどを噛むようにしておくとか。

で、そういった案の中に「絶対パスperlを指定する」という話もあって、これはすぐ試せそうだったのでやってみたら、動いた。

具体的には、ぼくの環境だと以下のような感じ。

10 * * * * /Users/note103/.plenv/versions/5.24.0/bin/perl /Users/note103/sample/hello.pl >> test.txt

って、これだとちょっと可読性が低いので、実際には変数を利用してこんな感じで。

perl524="/Users/note103/.plenv/versions/5.24.0/bin/perl"
pathtodir="/Users/note103/sample"

10 * * * * $perl524 $pathtodir/hello.pl >> test.txt

この変数の使い方などについては、冒頭にも挙げましたが @songmu さんの以下の記事が参考になりました。
http://gihyo.jp/dev/serial/01/perl-hackers-hub/002502

で、その記事はまた上記のチャット相談会で @papixさんから教えてもらったのだったけど、その他にも短い時間でいろんな方がそれぞれの知見を提供してくださって、先輩方には本当に感謝です。

コード内に相対パスが残っていた

というわけで、長かったcrontab問題もようやく解決……としばらく安心していたのだけど、まだ終わっていなかった。

というのも、自作モジュールを使ったコードの中で、以下のようにlibモジュールをuseしていたのだけど、

use lib './lib'

これが相対パスだったので、やはりcrontabの方では動いていなかった。

なので、これを絶対パスにしなきゃ……と思って直し始めたのだけど、念のためこのlibモジュールについて、こちらもいつもお世話になっています木本さんの以下の解説を読んでいたら、
d.hatena.ne.jp

use FindBin;
use lib "$FindBin::Bin/lib";

とした方がスマートに見えたので、それに入れ替えたらそれでも動くようになった。
多謝!

ということで、一連のメモはひとまず以上なのだけど、上記で踏み抜いた穴のいくつかについては、以下のWebページでも簡潔に解説されていたので、あわせて参考情報として貼っておきます。

プロンプトとcronでの実行結果の違い − Linux Square − @IT

そのまえに、よくありがちなパターンを書いておきますと、

というのがあります。2番目が結構厄介で、僕もその為に何回か書き直したことがあります。

この後者の話なんて、最後に挙げたものそのものだった。

*1:この辺の記述、「Perl」と「perl」で表記ユレしているように見えるが、一応言語名としては大文字始まりの「Perl」、コマンド名としては全部小文字で「perl」としている。ちゃんと調べていないのでその使い分けがいいのかどうかはわからないが……。

2つの配列から重複を弾く(Perlで)

いきなり例題から。

以下のような2つの配列があるとき、

my @fruits1 = qw/orange banana apple lemon/;
my @fruits2 = qw/orange banana/;

@fruits1のうち@fruits2とカブるものをカットして、重複しないappleとlemonだけ@fruits1に残したいとする。

こういうとき、今までぼくはこう書いていたのだけど、

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

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

# 以後、配列名は短縮
my @f1 = qw/orange banana apple lemon/;
my @f2 = qw/orange banana/;

for my $f2 (@f2) {
    for my $f1 (@f1) {
        if ($f1 eq $f2) {
            say "match:\t$f1!";
            @f1 = grep {$f1 ne $_} @f1;
        }
    }
}

say '===';
say "\@f1の残りは……";
say for @f1;
say "です!";

まあ、これでも目的は達成できる。実行結果は以下。

match: orange!
match: banana!
===
@f1の残りは……
apple
lemon
です!

最初にorange、その後にbananaがマッチして、あとにはappleとlemonが残っている。

コードでやってることとしては、まず2つの配列をループさせて、要素同士がマッチしたらその要素を元の配列からgrepで削除する。

削除というか、実際には「対象の要素以外を元の配列に入れ直す」という感じか。

で、ここでは重複を弾きたい(数を減らしたい)@f1の方を内側のループにして、grepでもその配列を対象としてカットしている。

というのも、この内と外を逆にすると、

# 以後、シバンやプラグマは省略
#
# cut_overlap2.pl

my @f1 = qw/orange banana apple lemon/;
my @f2 = qw/orange banana/;

for my $f1 (@f1) { #<= 外側にもってくる
    for my $f2 (@f2) { #<= 内側に入れる
        if ($f1 eq $f2) {
            say "match:\t$f1!";
            @f1 = grep {$f1 ne $_} @f1;
        }
    }
}

say '===';
say "\@f1の残りは……";
say for @f1;
say "です!";

結果。

match: orange!
===
@f1の残りは……
banana
apple
lemon
です!

こんなふうに、意図に反して最初のorangeだけマッチして、本来消えてほしいbananaが残ってしまう。

中身はどういうことになってるのか、必殺のprintデバッグ

# cut_overlap3_debug.pl

my @f1 = qw/orange banana apple lemon/;
my @f2 = qw/orange banana/;

for my $f1 (@f1) {
    for my $f2 (@f2) {
        say "f1:$f1 & f2:$f2"; #<= 中身を出力してみる
        if ($f1 eq $f2) {
            say "match:\t$f1!";
            @f1 = grep {$f1 ne $_} @f1;
        }
    }
}

say '===';
say "\@f1の残りは……";
say for @f1;
say "です!";

結果。

f1:orange & f2:orange
match: orange!
f1:orange & f2:banana
f1:apple & f2:orange
f1:apple & f2:banana
f1:lemon & f2:orange
f1:lemon & f2:banana
===
@f1の残りは……
banana
apple
lemon
です!

ということで、どうやら最初にorangeにマッチした後、@f1が2周めでbananaを飛ばしてappleの周回に入ってしまっている。(実行結果の4行目)

ちなみに、さっきの上手くいった場合だと、内部はどうなっているのかというと、

f1:orange & f2:orange
match: orange!
f1:apple & f2:orange
f1:lemon & f2:orange
f1:banana & f2:banana
match: banana!
f1:lemon & f2:banana
===
@f1の残りは……
apple
lemon
です!

という感じで、このときは目的上の影響がなくて気づかなかったけど、じつはここでもorangeがマッチした後、@f1のbananaがスッ飛ばされている。(実行結果の3行目)

ということで、実利的には最初の方法であれば目的は果たせるものの、裏で起こっていることはどちらも意図と違うというか、ちょっと気持ち悪い感じがあって、そこでいつもお世話になっていますPerl入学式のサポーター陣とのチャットでいろいろ相談してみた。

で、さっそく @xtetsuji さんからいただいた解答例がこちら。

# xtetsuji_1.pl
# 
# 出力部分は省略

my @f1 = qw/orange banana apple lemon/;
my @f2 = qw/orange banana/;

array_minus1(\@f1, \@f2);

sub array_minus1 {
    my $f1 = shift;
    my $f2 = shift;
    @$f1 = map {
        my $f1_value = $_;
        ( grep { $f1_value eq $_ } @$f2 ) ? () : $f1_value;
    } @$f1;
}

さらに、もう1案いただいた。

# xtetsuji_2.pl

my @f1 = qw/orange banana apple lemon/;
my @f2 = qw/orange banana/;

array_minus2(\@f1, \@f2);

sub array_minus2 {
    my $f1 = shift;
    my $f2 = shift;
    my %f2_value_is = map { $_ => 1 } @$f2;
    @$f1 = map { $f2_value_is{$_} ? () : $_ } @$f1;
}

結果はいずれも、以下。

@f1の残りは……
apple
lemon
です!

前者はgrep, 後者はmapを使っているけど、どちらも「マッチしたら空リストに入れる=元の配列から外す」という処理になっている。

そしてそれとは別に、@skjmさんからAcme::Toolsのminusもあるよ、と教えて頂いて。
Acme::Tools - search.cpan.org

これを使うと、こんな感じ。

# acme_minus.pl

use Acme::Tools 'minus';

my @f1 = qw/orange banana apple lemon/;
my @f2 = qw/orange banana/;

my @result = minus(\@f1, \@f2);

say "\@f1の残りは……";
say for @result;
say "です!";

結果は同じなので省略。

このAcme::Tools::minusの中身はこんな感じ。

sub minus {
  my %seen;
  my %notme=map{($_=>1)}@{$_[1]};
  grep !$notme{$_}&&!$seen{$_}++, @{$_[0]};
}

http://cpansearch.perl.org/src/KJETIL/Acme-Tools-0.21/Tools.pm

ちょっと略記が多いのでわかりづらいのだけど、自分が見慣れた書式に噛み砕くと……

sub minus {
    my $f1 = shift;
    my $f2 = shift;

    my %notme = map { ($_ => 1) } @{$f2};

    my %seen;
    my @result = grep { !$notme{$_} && !$seen{$_}++ } @{$f1};

    return @result;
}

といった感じか。

ちなみに、これの途中にある以下のインクリメント。

!$seen{$_}++

何度見てもこれのある意味がわからず、実際、これを取っても結果は同じなのだけど、じつは最初の配列@f1に対して、

my @f1 = qw/orange banana apple lemon/;
my @f2 = qw/orange banana/;

以下のように、同配列内の重複要素を入れてみると、結果も変わる。

my @f1 = qw/orange banana apple lemon apple/; #<= 末尾にappleを追加
my @f2 = qw/orange banana/;

先のインクリメントを入れた状態だと、これまで通りこうなるのだけど、

@f1の残りは……
apple
lemon
です!

そのインクリメントを外して以下のようにすると、

my @result = grep { !$notme{$_} } @{$f1};

結果はこうなる。

@f1の残りは……
apple
lemon
apple
です!

つまり、そのインクリメントは元になる配列(@f1)内の重複をカット(ユニーク化)してくれていた。

ということで、これについてはもう要件の問題というか、このツールを使う人がそもそもどういう結果を期待しているか? によって要不要を判断するところだろう。

とりあえずぼくの当初の希望としては、「片方の配列からもう片方の配列と重複する要素を取り除く」ということだけを求めていて、「元の配列内に存在する重複も取り除く」ことは求めていないので、そのインクリメントなしバージョンの方が適切かもしれない。

結論としてのコード集

すでにけっこう長くなってしまったけど、もう少しコード例を挙げつつ、では結局のところ、ぼく自身は今後どういうときにどういうコードで対応していくか、というまとめ。

remove

まずはこれまで話題にしたとおり、「片方の配列からもう片方の配列と重複する要素を取り除く」ということをしたい場合には、こんな関数を使う。

sub remove {
    my $whole = shift;
    my $part = shift;

    my %remove = map { $_ => 1 } @$part;

    my @result;
    for my $element (@$whole) {
        if (! $remove{$element}) {
            push @result, $element;
        }
    }
    return @result;
}

これを以下のように呼び出すと、

my @f1 = qw/orange banana apple lemon apple/;
my @f2 = qw/orange banana/;

my @result = remove(\@f1, \@f2);
say for @result;

@f1から@f2の要素と重複する要素を取り除いたものが出てくる。

apple
lemon
apple

この際、@f1内の重複はカットしない。

crush

次に、じつはこれまでに出た要件とは別に、「とにかく重複するものは全部消してほしい」と思うこともあるので、その対策。

この場合、上記の修正前の Acme::Tools::minus でも微妙に適合していなくて、なぜなら上述のとおり、同配列の重複については最低でも1つ残してしまうから。

しかしここでの新たな要件は、たとえば以下の2つの配列があった場合、

my @f1 = qw/orange banana apple lemon apple/;
my @f2 = qw/orange banana/;

lemon以外はすべて重複しているので、

lemon

とだけ出てほしい。

で、そのためにこのような関数を作ってみた。

sub crush {
    my $x = shift;
    my $y = shift;

    my %crush;
    map { $crush{ $_ }++ } ( @$x, @$y );

    for (keys %crush) {
        if ($crush{$_} >= 2) {
            delete $crush{$_};
        }
    }

    my @result;
    for ( @$x, @$y ) {
        if ($crush{$_}) {
            push @result, $_;
        }
    }
    return @result;
}

これで以下のように実行すると、

# 以後、果物の種類を増やす

my @f1 = qw/orange banana apple grape lemon apple/;
my @f2 = qw/orange banana strawberry/;

my @result = crush(\@f1, \@f2);
say for @result;

以下のように、とにかく全体の中で重複したものは取り除いてくれる。

grape
lemon
strawberry

この際、関数内ではハッシュで処理しているので、途中で順番がめちゃくちゃになっているのだけど、用途としては関数に渡した順に返ってきたほうが便利な気もするので、最後のfor文で順番を元に戻している。

ちなみに、関数名の crush というのは、重複した果物どうしをぶつけてつぶしてしまうイメージより。ジュースになって、形が消えるというような。

uniq

ついでにもう一つ、途中で少し話題にしたけど、渡した配列全体の中から、重複した余分な分はカットしつつ、でも1つは残しておきたい場合。

これは List::MoreUtilsのuniq関数を使えば早い。

use List::MoreUtils 'uniq';

my @f1 = qw/orange banana apple grape lemon apple/;
my @f2 = qw/orange banana strawberry/;

my @result = uniq(@f1, @f2);
say for @result;

実行。

orange
banana
apple
grape
lemon
strawberry

登場した果物すべてが1つずつ残っている。

uniqはリファレンスではなく普通に配列を渡すだけなので、用途が合えば作業も手っ取り早くてよい。

まとめ・謝辞・宣伝

ということで、さすがにこれだけ対処法を作っておけば、この辺りの要望には応えやすくなるだろう。

冒頭に示した危なっかしい二重ループ&grepの方法に比べると、コードの効率としても安心感としてもだいぶ改善したのではないか。

そして今回もまた、いつものようにPerl入学式のサポーターの皆さんには大変お世話になりました。
ぼくも一応サポーターなんですが、まだまだ教わってばかりです……。

ちなみに、Perl入学式は東京・大阪に加えて去年からスタートしたin沖縄、そして今年からはin北海道も増えて、ますます積極的に活動中です。
www.perl-entrance.org

近いところだと今週土曜にin東京の今年度前期の第2回が開催されます。
perl-entrance-tokyo.connpass.com

その翌週には大阪と沖縄、さらにその後に北海道もありますので、興味のある方はぜひご確認のほど。
perl-entrance-okinawa.connpass.com
perl-entrance-sapporo.connpass.com
perl-entrance-osaka.connpass.com

以上です。

(大阪の画像……)

怖くない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月半ば、これって自分の業務が一年を通して最大ピークの時期と思われるので、その頃に本当に学習&受験できるのか、ということはまったく不明なのだけど……。

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