ボッチでもOK

こちらは「春のPerl入学式リレーブログ」の7日目の記事です。
blog.perl-entrance.org

ひとつ前は、 id:kousy さんによる以下の記事でした。
kousy.hatenablog.com

Perl入学式での経験が仕事につながるというのは、すごすぎますね! 敬服します。
東京でのプログラマー生活、ぜひがんばってください。

今回の記事では、ぼくが初めてPerl入学式に参加したときのことを書きます。

ぼくが初めてPerl入学式に参加したのは、38才の夏でした。
これは同時に、ぼくがプログラミングの講義に参加した最初の機会であり、また初めて「プログラマー」と呼ばれる人々に対面した日でもありました。

その時のことは、以下の記事に書いています。
note103.hatenablog.com

今でもそうですが、ぼくは当時からプログラミングにまったく関係のない仕事をしていて、IT企業に勤める知り合いもいなかったので、このときには一人で参加することになり、会場には知ってる人が誰もいませんでした。

緊張していたせいか、時間よりも少し早めに会場に着くと、サポーター(スタッフにあたる人々) の id:papix さんや id:mackee_w さんたちもちょうど同じぐらいに着いていて、同じエレベーターに乗って上の階まで一緒に上がりました。

papix さんたちにはその時に少しだけ挨拶をしましたが、その後は基本的にサポーターさんはサポーター同士で楽しそうに話をしていて、今だから言えることですが、ぼくはうっすらと疎外感のような気持ちを抱いていました。

なにしろ、ぼくは年齢的に他の皆よりひと回りも(あるいはそれ以上に)離れていましたし、ITに関係ない仕事をしているのでその話題もまったく意味がわからず、周りに知り合いもおらず、Perl入学式自体も初めてで、さらにはその年の第3回の補講という、中途半端な回からの参加でもありました。

言うまでもなく、その疎外感はぼくが勝手に感じていたもので、サポーターの人たちから嫌な態度を示されたとかいうことは一切ありません。

ただ、自分以外の人は皆知り合いで、その人たちが共通の話題について楽しそうに話している、というその状況が、なんというか、チョット厳しかったわけです。

そしてぼんやりと、「ああ、自分が来るところではなかった」という気持ちになりました。

「呼ばれてもいないのに、身の程も知らずに、なぜこんな冒険をしてしまったのだろう?」と。

「あと何時間、この状況に耐えればいいんだ・・」と。

しかしながら、ボッチでも構わないから参加しよう、と思ったのは自分自身です。

とにかく時間が終わるまで頑張ろうと、そこは38才、なけなしの社会性を発揮して、こめかみには脂汗を浮かべながら、また周りの受講生の人たちともポツポツ会話を交わしながら、最後までなんとか時間を過ごしました。

それまでの人生でも、一人でイベントなどに参加することはよくありました。

知っている人が誰もいない場所に、後先考えずとりあえず飛び込んで、そのままコミュニティとの付き合いが始まったり、意図せず仕事につながったりすることもありました。

そういう経験が知らぬ間に体に染みついていたのか、初めは「すぐにでも帰りたい」と思っていたはずが、講義後の懇親会にも参加することになり、受講生やサポーターの人たちと少なからずおしゃべりをしながら、結局会場が閉まるまで残っていました。

その何日か後に、YAPC::Asia 2013が神奈川県の日吉で開催され、その中で行われたPerl入学式出張版にも参加しました。

Perl入学式 @ YAPC - YAPC::Asia Tokyo 2013
YAPC::Asiaで行われるPerl入学式のワークショップについて色々インタビューしてみました! | YAPC::Asia Tokyo 2013

なぜ一度痛い目にあったのに、懲りずにまた参加したのかというと、じつはYAPC::Asiaのチケットの方を先に買っていて、その下見のようなつもりで上記の講義(第3回補講)を受けていたからでした。

そして、このYAPC::Asiaでもまた、基本的にはずっと一人でした。

YAPCでのPerl入学式には、サポーターはもちろんのこと、先の受講生も何人か参加していたので、今度はまったくの一人ではなかったものの、YAPC全体を通してみれば、前夜祭でも、初日の懇親会でも、大半の時間は一人で過ごすことになり、それが数日間にわたり続いたため、このときには疎外感というより、もう少し重々しい、とりとめのない孤独のようなものを感じていました。

ちなみに、YAPCにおけるPerl入学式の内容は、普段とはちょっと違う番外編のようなもので、入門というにはひねりの効いた、少なくともぼくにはなかなかハードルの高いもので、何をやっているのかよくわからないうちに終わってしまった、という感じでした。

そういうこともあって、「やっぱりYAPC、俺には早すぎた・・」という後ろ向きな感想を持ちましたが、なぜかその後もPerl入学式には参加し続けることになり、翌年の4月からはサポーター側に回ることになりました。

ある種、痛切ともいえるボッチ体験に遭遇しながら、なぜその後もやめずに続けられたのかと考えると、結局のところ、その疎外感とか、孤独感とかいったツラさは最初に味わうものが一番大きくて、その後は痛みに慣れるというか、弱まるというか、軽減される一方だから、ということが言えると思います。

喩えてみると、バンソコウをはがす時に、最初にピャッとはがしてしまえばそれで終わるというか。

あるいはインフルエンザの予防接種を受けるときに、「はい、チクッとしますよ〜」とか言われて、「ひえ〜!」と思っても、その数秒後には全部終わってる、みたいな。

新しい体験がもたらす痛みは、最初の方ほど強く、しかし後は弱まる一方で、やがてそれは心地よい自分の居場所になっていきます。

この記事の前半で、エレベーターに乗ったときの話を書きましたが、今思えば、サポーターさんはサポーターさんで、普段はそれぞれ別の職場で仕事や生活をしていますから、Perl入学式という場で、気の置けない友人たちに久しぶりに会えたなら、普段はできない楽しい会話に時間を使いたくなるのはごく自然なことです。

当時のぼくからすれば、「自分と自分以外」という物の見方しかできていませんでしたが、実際には、サポーターにはサポーターの、特別な場としてのPerl入学式があったわけです。

普段の生活習慣から離れた場に、一人で飛び込むというのは、不安もあると思いますし、実際、人によってはツライ思いをすることもあるかもしれませんが、その次の瞬間から、欲しいものは確実に手に入ってきます。

ぼくの場合、それはプログラミングの技術でした。

だいぶ時間はかかりましたし、今なおかかっていますが、当初では考えられなかったほど、その技術を自分のものにし、それを楽しんでもいます。

プログラミングの勉強を始めるときに、一緒にやってくれる友達は不要です。
自分の体ひとつあればOKです。

Perl入学式では講義資料を広く公開していますし、

講義資料 - Perl入学式 | Perl Entrance

全国各地でも開催していますので、もし都合が合えば、いつでも参加してみてください。
www.perl-entrance.org

ノンプログラマーのプログラミング活用法

去る3月3日に沖縄で開催されましたYAPC::Okinawaでの発表内容をスクリーンキャスト形式で新たに収録してみました。

www.youtube.com

ただし、めっちゃ長いので(85分)各チャプターの頭出しをしたリンクも以下に並べておきます。
興味に近いところなどありそうでしたら、適当につまみ見してください。

  1. はじめに: https://youtu.be/jJZD3k6-q0c?t=0s
  2. 自己紹介: https://youtu.be/jJZD3k6-q0c?t=3m45s
  3. Vim: https://youtu.be/jJZD3k6-q0c?t=13m46s
  4. Shell: https://youtu.be/jJZD3k6-q0c?t=31m38s
  5. Perl: https://youtu.be/jJZD3k6-q0c?t=50m54s
  6. Excel: https://youtu.be/jJZD3k6-q0c?t=1h1m40s
  7. ふり返り: https://youtu.be/jJZD3k6-q0c?t=1h18m12s
  8. まとめ: https://youtu.be/jJZD3k6-q0c?t=1h22m1s

冒頭でも少し説明していますが、今回は発表の録画も録音もしてなくて、一応スライドは公開しているけどDEMOも多用しているので、スライドだけだと一部しかわからないし、まあ「そういうものだ」と割り切るのもアリなんだけど、実際はかなり準備していった話だからこのまま終わってしまうのもな〜・・と思って、このような形で再現してみました。

YAPC本番では40分以内に収めるためにいろいろトピックを削ってしまいましたが(Shell編の文字列検索とか)、今回はそれも含めて基本的には全部入りにしたので、そういう意味ではフルバージョンです。

と言いつつ、これも今聞き直してみたら「あ〜、あの話忘れた」「こう表現すればよかった」といった部分がポロポロ出てきているので、これはこれでひとつの未完成版というか、新たなライブ盤というか、YAPCとはまた別の即興的な何かかな、とも思います。

あとはYAPCの本番だとやっぱり、聞いている人たちの反応コミでの面白さみたいなのがあったので、その意味でも現場でのパフォーマンスとは別物といえば別物な気もします。

とはいえ、当日聞いてくれた人にとってはその補足というか、その日の内容を思い出したり、カットされた話を知るものとして聞けるかなと思いますし、沖縄まで行けなかった〜という人には、スライドではわからない部分を聞いてもらえる機会になると思うので、記憶がなくならないうちになんとか形にできて良かったなと。

なお、この発表に関するざっくりした話(というかスライド作成の過程など)については前回の記事に書きました。
YAPC::Okinawa 2018 ONNASONの記録 - the code to rock

発表スライドはこちら。
The Non-Programmer's Programming Techniques // Speaker Deck

その他、個別具体的なトピックについてはまだまだ語り足りない面もありますが、とはいえキリがなさそうなのでしばらくナシかな・・。

それよりはむしろ、イベント前後の前夜祭、ハッカソン、お土産屋めぐりなどについてまだ書いてないことがいろいろあるので、次に時間ができたらその辺りを書き残しておければ、という感じです。

最後になりますが、このような機会を作ってくれたYAPC::Okinawa運営スタッフおよび関係各位、参加者の皆さん、そして何より時間を割いてB会場で聞いてくれた方々、ありがとうございました!

YAPC::Okinawa 2018 ONNASONの記録

2018/03/03に沖縄県恩納村で開催されたYAPCに参加してきた。
yapcjapan.org

今回はなんと、スピーカーとしての参加。
http://yapcjapan.org/2018okinawa/timetable.html#/detail/10

初めはこの一連の出来事を時系列にまとめようと思っていたのだけど、あまりにもトピックや感想が多すぎて、ちゃんと書こうと思ったら完全に「仕事」になりそうだったので、頭に浮かんだ順に即興的に書いていくことにした。

スライドができるまで

今回、ぼくが発表したスライドは以下。

speakerdeck.com

ただし、当日の発表ではDEMOを多用しているので、このスライドに載っているのは全体の半分からせいぜい3分の2程度。

それは今回のスライドを作るときに強く意識していたことで、発表時にただスライドを読み上げるだけみたいな、紙芝居のように「スライドをめくりながらそれを見て喋る」みたいにはしたくなかった。

理想としては、スライドには見出しだけを列記する。そしてその一つ一つについて、画像なりDEMOなり、あるいは身ぶり手ぶりで説明してく、みたいにしたかった。

だから、スライドだけを見ても面白くもなんともない、現場にいないと(あるいは動画などで発表の様子を見ないと)意味がわからない、そんな感じにしたかったし、それで良いと思っていた。

(実際には、スライドだけを見てもある程度内容を想像できるようになっているとは思うのだけど。ただ事前の方針として、「後からスライドを見る人のために現場では不要な説明を加えたりしないようにしよう」と思っていたということ)

なにしろ今回一番大事にしたかったのは、わざわざ40分もの間ぼくの発表に付き合ってくれる人たちで、その人たちが「うひー、退屈だな」と思わないようにする、というのがほとんど最大のミッションでもあった。

スライドに書かれた文字が読み上げられるだけ、というのはなかなかツライ。大学の授業でもそういう先生が時々いた。
逆に、「その場にいないと得られない情報がどんどん飛んでくる」というのはスリリングで面白い。

だから、構想を練って項目を立てている最中もスライド化のことはなるべく考えず、Keynoteを立ち上げるのも可能なかぎり後に回した。

シャドープレゼンテーション

構想の練り方としては、だからスライドを作りながら考えるのではなく、かといってメモ帳やノート系のアプリを使うのでもなく、とにかく実際に喋ってみた。

頭の中にあるネタを喋りきって、それをすべて録音して、それを自動音声入力でテキスト化して、それをtextlintでざっくり表記統一して、それをプリントアウトして、それを眺めながら紙のノートにパラパラと見出しを書き出して、それを見ながらまた喋る。

これをたぶん3〜4周やった。

とにかく喋る&録音する、というのはシャドーボクシングならぬシャドープレゼンテーションみたいな感じ。

話を聞いている人たちのことを思い浮かべながら(その人たちは皆ぼくの発表に好意的だと設定しつつ)、その人たちに語りかける。

これはちょっとラジオにも近い。目の前にはいない、でもたしかに存在するはずの人々を想像しながら喋っていく。

だからこれは、「ポッドキャスト風ブレスト」とも言える方法で、それをやりながらどんどん構想を煮詰めていった。

ノートにプロットを書き出しつつ構成する、というのも試してはみたのだけど、プロポーザルを見てもわかる通り、ネタがあまりにも多すぎて、まともに精査していたら時間がいくらあっても足りないし、単純にもの凄く疲れそうだった。

その点、とりあえず思うままに喋るだけなら、頭の中はほとんど無意識というか、自動操縦のような感じになって、あまりくたびれずに膨大なアイディアを吐き出せたと思う。

加えて、喋りながら構想を練ると、60分も90分も喋っているうちにどんどん体が疲れてきて、また気分的にも飽きてくるので、この段階でネタの淘汰も進んでいく。

この話、そんなに無理してまで言わなくてもいいな・・みたいなストッパーが自然にかかるというか。

先にスライドを作り込んでからそれを実践するという順番だと、頭で考えた計画に体を従わせる感じになるが、この方法だと先に体の限界を設定しておいて、その条件を考慮しながら構想を作っていく感じになって、より現実的というか、結果的にではあるが、案外効率的だったように思っている。

ミニマルなスライドのメリット/デメリット

初めにブレスト的に、一旦最後まで喋ったときには90分ぐらいかかった。

理想としては、40分の持ち時間のうち、最後に5分の質疑応答を入れるとしたら発表自体は35分に収める必要があるから、ほとんど1時間オーバーしてる。

さすがにこれはまずい、と見出しのメモを見ながらあれこれ削って、やがて70分になり、50分になり、「ここから先は同じ方法では削れないな」と判断したところで、ようやくスライドを作りはじめた。

この時点で全体の構成はほとんど頭に入っていたから、スライドの初稿は1時間もかからずできたのではなかったか。
かなりあっさり最後まで行って、びっくりした。

とはいえ、この段階では上記のとおり、見出し中心の簡素な内容だったから、枚数も少ない。たぶんその時点では20枚ちょっと。

スライドの枚数が少ないと、短時間で作れるし、修正もラクだし、1枚あたりのクオリティも上げられるから、そういう意味ではメリットが大きい。

ただし、そのぶん本番ではスライドをカンペ的に使うことができないから、当日のプレッシャーや負担が大きくなる。
これはトレードオフで、実際ぼくも発表直前まで、本番で内容を全部忘れてしまったらどうしよう? という不安がつきまとった。

スライドの言葉

初稿ができた後は、少しずつ画像を足したり、説明文を補足したりして推敲を重ねた。
これにより、スライドの枚数も、1枚あたりの文字数も増えていった。

その作業をしていて気づいたが、スライドを作りながら物を考えると、「スライドの中の言葉」で思考するようになっていく。
言い換えると、その「スライドの言葉」を使わなければ論理が進まなくなっていく。

「スライドの言葉」とは、普段ぼくらが誰かに直接話しかけるときの「言葉」とはちょっと違って、スライドの中の世界だけで鳴り響く言葉だ。
これを使い始めると、スライド上の文字は加速度的に増殖していく。

その言葉を使うこと自体は悪いことでないけれど、文字数が増えるのは良いことではない。
単純に見づらくなるし、何より前述の「スライド読み上げプレゼン」まで一直線だ。

それはまずい、ということで、そこからまた文字を削ったり、枚数を減らしたり、最大限の抵抗はしたけれど、やはり終盤のまとめに至るあたりでは、そういった説明的な言葉が優勢になってしまった感がある。

いらすとや回避

スライドに文字をなるべく載せない方策としては、DEMOやスクリーンショットを使うこともそうだが、イラストを活用することも考えた。

この点、いらすとやさんに行けば大抵のフィーリングはイラスト化されていて、これはたしかに依存しやすいというか、めちゃくちゃ便利なツールだなと思わされた。

ただ、各所でいらすとやさんのイラストを使ったものを見ていると、中にはハイコンテクストにうまく活用している事例もあるものの、あまり多用すると誰の発表なのかわからなくなるというか、そもそもいらすとやさんのイラストというのはけっこう記名性が高いように感じられるので(匿名的ではないというか)、発表を乗っとられてしまうような危惧があった。

そこで2番めの案として、自分で手書きしてみることを考えた。

具体的には、以前にきしだなおきさんのブログで見た、こちらのような感じ。
d.hatena.ne.jp

さらさらっとルーズリーフのような紙に絵を描いて、そのままポンとプレゼンしている。スゴイ。

しかしどうも簡単には真似できない。ざっと描いてみることまでは出来ても、ぼくだったらその後の推敲であーでもないこーでもないとかえって時間をかけてしまいそうで、今回はそれだけの時間はないな、と思い直して諦めた。

それでふと「あー、これしかないか」と思ったのがGitHubやSlackでもおなじみのemojiを使うことで、ためしにKeynoteに入れていったら、思いのほか効果的だった。🤗

主張しすぎることもなく、かといって地味すぎることもなく、また微妙なフィーリングもそこそこ表現できて、何より簡単に入れたり外したりできる。

おかげで、文字ばっかりの状態に比べて少し楽しげな感じになって、おそらくはそれが奏功してウケた部分もあって*1、ホッとした。

客層とテーマのマッチング

沖縄までわざわざITカンファレンスに行くような人といったら、その時点で大半がエンジニア/プログラマーだろう、とはぼくも思っていた。

にもかかわらず、ぼくの発表は「ノンプログラマーがどうやってプログラミングを役立てているか」というものだったから、客層とマッチしないのでは? という懸念があった。

普通に考えたら、そのテーマから想定される客層というのは、「これからプログラミングを始めてみたいノンプログラマー」であり、その関心はと言えば、「自分がプログラミングを導入したら普段の仕事がどれだけ捗るのか?」みたいなことだろう。

しかし一方で、ぼくの今回の発表の価値というのはそういうところだけにあったのではなく、これはプロポーザルにも書いたことだが、「大半のプログラミング技術に関する情報はプログラマーが発信しているが、ここではノンプログラマーの私がそれを発信する」という点に意味があった。

通常、プログラミングに触れるノンプログラマーは、つねに「教わる側」であり、教わる側は言葉を持たない。

「わからないな」と思ったとき、それは「わからない自分が悪いのだ」と思ってしまいがちだ。

しかし実際には、ノンプログラマーがプログラミングに触れるとき、そこではいろいろなことが起こっている。
わからないのは、「教科書が間違っているから」かもしれないし、「教え方が悪いから」かもしれないし、「カリキュラム(勉強の仕方)が合ってないから」かもしれない。

ぼくはプログラミングを始めたのが38才を過ぎてからで、今では43才になろうとしているから、まあこれは年齢のせいというよりも性格のせいかもしれないが、いずれにせよ、自分の考えを伝えるための言葉を少しは持っている。

だから、変だなと思ったら「変だ」と言うし、しょうもない成果物でも「できた!」と言うし、YAPCトークにも応募する(それも今回で2回め)。

結果的に、普段あまり人々が聞く機会のない発表が実現したわけで、これは誰が聞いても新鮮であるには違いない。

残る問題は、ぼくがそこでどれだけ「純度の高い情報」を提供できるかということで、だからその点には神経を費やした。

もしそこで、ノンプログラマーにも背景がわかるように・・と終始基礎的な話をしていたら(ターミナルの立ち上げ方とか 、Vimの初期設定の手順とか)、一緒に聞いているプログラマーには退屈な時間になってしまうだろうし、かといって専門的な話をしようとしても中途半端になるだけだろう。

だから、とことん「自分が面白いと思ってる話」だけを取り上げることにした。

枝葉的な解説は最小限にとどめ、自分自身がエキサイトするような事象を集めて、そのことだけを話そう、と。

その純度が高ければ高いほど、つまりぼく自身が「この話、面白い!」と思えれば思えるほど、発表はきちんと聞き手に届くはずだと思って、そうした。

懇親会の終わりに話したこと

入門書のジレンマ

発表が終わり、懇親会になり、その終盤、朝からつづいた雨も上がり、会場から一人また一人と夜の庭へ出ていくのが見えた。

それにつられるように、ぼくも会場からフラフラと出ていったところで、ぼくの発表を見たという人から声をかけられた。

その人は、自分もプログラマーではなく、今回スポンサーをしている会社のひとつに勤めているのだと言った。

それからしばらく、いろいろと嬉しい感想をもらいながら、上に書いた「ノンプログラマー発の技術情報であることに意味がある」みたいな話をした。

ぼくらノンプログラマーが技術情報に触れようとしたとき、それを書いているのはつねにプログラマーなのだと。

その人は、プログラマーが書いた入門書などを読んでもわからないことがあると言い、ぼくは「それは自然なことだ」と言った。

プログラマーはノンプログラマーではないがゆえに、ノンプログラマーがどこでつまづくのかをわからないのだと。

もちろん、中には例外的な人もいて、結城浩さんなどはその例にはあたらない。

結城さんはつねに、読者が「今どこにいるのか」を考えながら書いているから、相手がプログラマーであろうとノンプログラマーであろうと、読者を置いてけぼりにはしない。

逆に言えば、わかりづらい入門書とは、読者が「今どこにいるのか」を想像できていないのだ。

何であれ、情報を整理して他人に伝えるときには、膨大な、かつ茫漠とした情報の海の中から、必要と思える要素を取捨選択しなければならず、それはつまり不要な部分を省略しなければならないということだ。

わかりづらい入門書というのは、そのとき、省略してはいけない部分を省略してしまっている。

ビルの上の階まで上がろうというとき、適切な高さの階段が均等に積まれていれば誰でも上がっていけるが、所々に異様に高い段差があったら、上がれない人が出てくる。

入門書を書くような人というのは、すでに専門家として何年もキャリアを積んでいる人だから、「どの階段を省略したら入門者がついてこれなくなるのか」を想像しながら書いていくのが難しいのかもしれない。

だからこそ、自分のようなノンプログラマーが技術情報を発信することには何らかの価値があるだろうと思うし、そのときもたぶんそういう話をした。

プログラマーとノンプログラマーを分けるもの

そのときに話したことをもう一つ書いておくと、これは本来、今回の発表にも入れたいと思っていたのだけど、とても時間が足りなくてカットしたもので、「プログラマーとノンプログラマーの違いは何か?」という話。

また喩え話になるが、ノンプログラマーによるプログラミングが「趣味の魚釣り」だとしたら、プログラマーによるプログラミングは「漁業」である。

趣味の魚釣りと漁業との違いは、「誰のために魚を獲るのか?」ということで、言い換えれば、「獲った魚を食べるのは誰か?」ということだ。

漁師は自分たちの食べ物を確保するために漁をしているのではなく、不特定多数の他人が食べる魚を獲っている。

一方で、趣味の釣り人は自分が楽しむために魚を釣っている。

どちらが偉いわけでもないが、他人の口に入るものを扱う以上、責任は漁師の方が遥かに重い。
それゆえ、面倒なこともたくさんしなければならないし、多くの技術を身につける必要もある。

どれだけ多くの魚を獲れるかという意味で、趣味の釣り人が漁師に勝てる日は来ない。やっていることのケタが違うのだ。

くり返すが、これはべつにプログラマーがノンプログラマーより偉いという話ではない。

視点を変えて、たとえばぼくは今編集を生業にしているけれど、その分野で言ったらぼくの方が漁師ということになる。

だから考えるべきは、趣味の釣り人が魚を釣るように、ノンプログラマーのぼくがプログラミングをかじったところでそれが何になるのか? ということだ。

その答えはある。

ぼくにとってのプログラミングはどこまでも趣味に過ぎず、その技術が毎日大量のトラフィックを重い責任のもとにさばいているプログラマーのそれを超える日は永遠に来ないが、それでもプログラミングを通してぼくの本業の生産性が高まったら、それはめぐりめぐって、プログラマーを含む社会への貢献を果たすことになるだろう。

何もプログラミングの世界で職業プログラマーに勝つ必要などなく、自分の生産性を上げたり、あるいは自分の人生を豊かにしたりできれば、それだけでも充分意味のあることなのだ。

ジェロニモと私

最後にもうひとつ、これを書いてこの記事を終わるが、その会話の最後の方で、「結局、ノンプログラマーがプログラミングを習得する方法としては、やっぱり仕事に取り込むっていうのが効果的なのでしょうか?」みたいな質問をもらって、それについてあらためて考えられたのもよかった。

ぼく自身がなぜプログラミングを続けてこれたのかと考えたら、それは「仕事に役立つから」というより、プログラマーの人たちがいつもなんだか楽しそうで、「あんな風になりたいな〜・・」と思ったからだった。

これは以前、吉祥寺.pmというイベントで発表したとき、そのスライドに入れるつもりだったものの結局時間がなくて削った話なのだけど、『キン肉マン』という漫画に出てくるジェロニモというキャラクターがいて、彼は本当は人間なんだけど、超人のテリーマンたちに憧れて正義超人の仲間に入って、しかしその後悪魔超人たちと闘ってメタメタにやられてしまう。

そこで出てくる名ゼリフに、「だってオラは人間だから」というのがあって、ノンプログラマーでプログラミングなんてやってると、そんなのばっかり。

プログラマーと自分とではまったくいる場所が違うというか、素地が違うというか、土台が違いすぎるので相手にならない。ツライ。

だけど、大事なのは勝つとか負けるとか、誇らしいとかみっともないとかではなくて、そのジェロニモテリーマンとかキン肉マンとかに対して抱いたような「憧れ」があるかどうかなのだと思う。

プログラミングをやる理由が「仕事に役立つ!」というだけだとちょっと弱くて、それだけだと「だって人間だから・・」みたいな感じでつぶれちゃう。くじけてしまう。そんな気がする。

だけどそこに、「憧れ」が残っていたら続けられる。というか勝手に続いていく。

それはべつに特定の誰かに対するものでなくても、ぼくだったらテクノロジーを味方につけることで稀に体験する、「それまで100日かかっていた作業が5分で終わった」みたいな劇的な変化への憧れというか、希求がいつもある。

ぼく自身が経験的に責任をもって言えるのはそこまでなんだけど・・と、そういう話をした。

その他のトピック

上記の機会では、相手の方からのコメントが本当にどれもクリエイティブ&丁寧なものだったので、普段考えていることをどんどん話すことができて、他にもたくさん面白い会話をしたのだけど、ひとまずここまで。

YAPC::Okinawaについては、前夜祭やイベント翌日のハッカソン、その後のお土産屋めぐりや、そもそものプロポーザルに至る話など、まだまだトピックはあるのだけど、その辺はまた時間ができたら、続編として書いてみたい。

*1:P19.「Finderは疲れる」というあたりなど。

tigの車輪の再発明

複数ファイルが立ち並ぶディレクトリにおいて、1つまたはいくつかの限られたファイルだけを`git add`したいという場合、いちいちそのファイル名を打ち込んでいくのがメンドイ。

https://i.gyazo.com/2ea3f4f42a20f00f66837cef4191a00e.gif

こういう時、peco的なものでバッとリストを出して、インクリメントに対象を絞り込みつつ直感的に選択できないものか? と思っていた。

で、こういうのを作った。(コマンドは`ga`)

https://i.gyazo.com/b41528b638db51e86643b50d41c2f6c1.gif

Perl製。
とくにリポジトリを公開したりしていないので、生コードはこんな感じで。
(.bashrcと組み合わせる)

# .bashrc
function gi {
    local arg="$@"
    local pick=$(perl /path/to/gi.pl)  #パスは任意の場所で

    if [ -z "$pick" ]; then
        echo Canceled.
    elif [ -z "$arg" ]; then
        echo Input a command.
    elif [ ! -z "$pick" ]; then
        git $arg $pick
        if [[ "$arg" == add ]]; then
            echo Add $pick
        fi
    fi
}
alias ga="gi add"
alias gr="gi reset HEAD"
#!/usr/bin/env perl
#
# gi.pl
use strict;
use warnings;
use feature 'say';

my $status = `git status`;
my @msg = split /\n/, $status;

my $msg;
my %msg;
my $marker = '';

for (@msg) {
    if ($_ =~ /\AChanges to be committed:/) {
        $marker = 'staged';
    }
    elsif ($_ =~ /\AChanges not staged for commit:/) {
        $marker = 'not staged';
    }
    elsif ($_ =~ /\AUntracked files:/) {
        $marker = 'untracked';
    }

    if ($_ =~ /\A\t(.+)\z/) {
        $msg = $1;
        if ($marker eq 'staged') {
            if ($msg =~ /\A(.+):\s+(.+)\z/) {
                $msg{$2} = 'staged';
            }
        }
        elsif ($marker eq 'not staged') {
            if ($msg =~ /\A(.+):\s+(.+)\z/) {
                $msg{$2} = $1;
            }
        }
        elsif ($marker eq 'untracked') {
            if ($msg =~ /(.+)\z/) {
                $msg{$1} = 'untracked';
            }
        }
    }
}

my @result = ();

while (1) {
    my @list = ();
    my $list = '';

    for (sort keys %msg) {
        push @list, "$msg{$_}:\t$_";
    }
    $list = join "\n", 'OK', @list;

    my $selected_line = `echo "$list" | peco`;
    chomp $selected_line;

    my $selected_status;
    my $selected_file = '';

    if ($selected_line =~ /\* (.+):\t(.+)\z/) {
        $selected_status = $1;
        $selected_file = $2;
        shift @result;
    }
    elsif ($selected_line =~ /(.+):\t(.+)\z/) {
        $selected_status = '* '.$1;
        $selected_file = $2;
        push @result, $selected_file;
    }
    delete $msg{$selected_file};
    $msg{$selected_file} = $selected_status;

    if ($selected_line =~ /\A(OK|)\z/) {
        if ($selected_line eq '' || ($selected_line eq 'OK' && scalar(@result) == 0)) {
            @result = ();
        }
        last;
    }
}

print "@result";

`gi`の後に何らかのgitコマンドを入れれば、選択したファイルに対してそれをする。

ここでは事前にエイリアスを設定して、`ga`と打てば`git add`、`gr`と打てば`git reset HEAD`になるようにしている。

何度も試しながら、結局半日ぐらいかかった気がするが、ひとまず「ん〜、いいじゃん、こういうのが欲しかったのだよ」と満足できる感じにはなった。

が、そこまで来てからふと、「しかし普通のプログラマーたちが毎日そんなメンドイことをしてるはずがないな……皆どうしてるんだろう?」と思った。
まあIDEや各種エディタ、あるいはGUIツールを使っている人なども少なくはないだろうけど、ターミナル操作で済ませている人も多いだろうしなあ、と。

そこでようやく、時々耳にするtigというツールを使えば似たようなことが出来るかも? と思い至り、簡単に調べてみた。

qiita.com

上記でほぼ把握。自分の手元でもやってみた。

https://i.gyazo.com/0d10e3b193ff13468148dca7ca2da9a9.gif

最初に`tig`と打つと、`git log --oneline`的な画面が出てきて、そこで`S`(Shift+s)を打つと`git status`の情報が出てくる。

そこでjk(上下)移動しつつ目当てのファイルの上で`u`を押すと、さくさくステージ/アンステージしてくれる。
めっちゃお手軽!

Vimとほぼ同じ動かし方なので、直感的に使える。
pecoのようなインクリメントな絞り込みはできないけど、必要十分とは言えるだろう。

何より、上記ではaddだけやっているけど、このtigにはその他のgit系機能も盛りだくさんである。
先ほど`git blame`を試してみたけど、これもけっこう目覚ましい体験だった。

これがあるとわかっていれば、わざわざ冒頭のようなコードも書かなかったなあ……と一瞬思ったが、でもどうだろう。

初めからtigを使っていたら、tigの「使い方」には詳しくなったかもしれないけど、コードを書く技術は上がらなかっただろう。

ぼくが望むのは確かに「直感的に`git add`すること」だったけど、同時に「コードをより上手に書けること」も求めていて、言い換えると、ぼくが最終的に求めているのは道具の「使い方」ではなくて「作り方」を知ることなのだと思える。

最新のガジェットやそれらを「使いこなす」ことにあまり興味を持てないのもそのことと関係している気がする。

さらに突き詰めて考えるなら、ぼくが欲してるのは「自由」なのだとも思う。

最新のガジェットに興味がないとは書いたが、そうは言ってもiPhoneが初めて日本で発売されたとき(2008年の6月とかだった)、ぼくはまだソフトバンクで機種変更してから半年ぐらいしか経っていなかったけど、迷わずiPhoneを予約してすぐ交換した。

じゃあなんだ、新しいガジェットに興味あるじゃないか、とも言えるが、それを買ったのは「絶対的に未知の体験を死ぬ前に味わっておかなくてはならない」と思ったからで、それは「現在という束縛からの逃避・逸脱・自由」を求めてのことだったと思える。

他人が作った道具を使うというのは、結局どこまで行っても作り手の想定の範疇から抜け出せない行為のように感じられて、あまり強い欲求が生じないのかもしれない。

たとえば作り手がその大元のルールを変えてしまったら、せっかく覚えた使い方も無効になってしまう。その不自由さがいやなのだ。

それよりは、シンプルで小さな道具を自分なりに組み合わせて、他の誰も使わないかもしれないが自分に最適化された、自分にとって最高の道具を作り、それまでの人生で味わったことのない体験をしたい、という気持ちがある。

プログラミングにはそういう欲求を駆り立てるものがあるようで、「作ること」と「それを使って体験すること」とのバランスが絶妙に感じられる。

[PR] YAPC::Okinawa で発表します

その話と直接の関係はありませんが&次にいつブログ書けるかわからないのでこのまま書いてしまいますが、3/3に沖縄で開催されるYAPC::Okinawa 2018 ONNASON で登壇することになりました。

yapcjapan.org
http://yapcjapan.org/2018okinawa/talks.html#/detail/10

チケットは完売とのことですが(おめでとうございます!>各位)現地に行かれる皆さんにおきましては、ご興味ありましたらぜひお越しください!

ノンプログラマーのためのPerl 〜 forと正規表現を使ったお得なセット

こんにちは。こちらはPerl入学式アドベントカレンダーの20日目の記事です。
(おっと日付が……🙇)

qiita.com

はじめに

あらためまして、まずここで「Perl入学式」について簡単に説明しておきますと、Perl入学式とは、Perlまたはプログラミング自体の未経験者に、Perlを通してプログラミングの基礎をお教えしましょう、という無料のプログラミング講座です。
www.perl-entrance.org

ぼくも2013年の8月、同年度第3回の補講から、まったく素人の状態で生徒として参加しまして、
Perl入学式#3補講に行ってきた - 103

その翌年春からはサポーター(運営側)に加わっています。

……といっても最近は地理的な問題などもあり、リモート参加が大半なのですが。
継続的に現場で開講しているメンバーの皆さんには、本当に敬服するばかりです。

さて本日は、ぼくのようなノンプログラマー、つまり普段の仕事ではプログラミングとは関係のないことをしている人*1が、プログラミング言語Perlを学ぶことによって、どんな便利なことになるのか、みたいな話をします。

といっても、その便利さをすべて説明しようとしたら大変な時間と文章量が必要になりますので、今回はその中でもとくに「これは」というところに絞って説明します。

for文

多くの場合、ぼくが普段の仕事をしているときに、「んー、こりゃプログラミングの力を借りた方がよさそうだな!」と思うのは、

テキストファイルAの内容に何らかの処理を加えて、テキストファイルBとして保存する

みたいなことをやりたい時です。

具体例を挙げてみると、たとえば以下のような名簿があったとして、

ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター

このすべての文末に敬称「さん」を付けたい、という場合。

いやもちろん、このぐらいなら自分で書けばいいんですが、これが何百人もいたら大変なので……ということ。

こんなとき、ぼくだったらこんなコードを書きます。

#!/usr/bin/env perl
use strict;
use warnings;

my @band = qw/
ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター
/;

for my $member (@band) {
    print "$memberさん\n";
}

まず配列 @band に4人の名前を入れて、これをforループで回しつつ、出力時に「さん」を加えています。

実行してみると……
gyazo.com

はい、できました。for文、めっちゃ便利ですね。

このfor文については、Perl入学式の講義資料より以下をご参照ください。
https://github.com/perl-entrance-org/workshop-2017/blob/master/2nd/slide.md#for文-配列

qwについては以下をどうぞ。
https://github.com/perl-entrance-org/workshop-2017/blob/master/2nd/slide.md#qw-ショートカット

if文、正規表現

さてしかし、現実の世界では、このように元のデータすべてに同じ処理をするという機会はそうそうなくて、この内の「ある条件に合致するもの」だけに処理を加えたい、ということが多いです。

たとえば、この中で名前の最後に「ン」が付く人だけ敬称を「様」にしたい、という場合にはどうすればいいでしょうか?

そのような時には、こう書きます。

#!/usr/bin/env perl
use strict;
use warnings;

my @band = qw/
ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター
/;

for my $member (@band) {
    if ($member =~ /\z/) {
        print "$member\n";
    }
    else {
        print "$memberさん\n";
    }
}

実行。
gyazo.com

はい、できました。

このif文と、それに付いてくる正規表現(「=~」とか「//」を使って色々やっているもの)については、同じくPerl入学式の講義資料から以下をご参照ください。

if文
https://github.com/perl-entrance-org/workshop-2017/blob/master/2nd/slide.md#if-else文

正規表現
https://github.com/perl-entrance-org/workshop-2017/blob/master/4th/slide.md#正規表現

__DATA__

さてここで、一旦冒頭の話に戻りますが、普段の仕事(プログラミングとは関係ないそれ)をしていて、時々欲しくなるのは、

テキストファイルAの内容に何らかの処理を加えて、テキストファイルBとして保存する

という能力です。

上の例でいうと、テキストファイルAにあたるのは

ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター

で、処理後のテキストファイルBにあたるのは

ジョン・レノン
ポール・マッカートニーさん
ジョージ・ハリスン
リンゴ・スターさん

になります。

ただ、さすがにこんな風に、処理したいデータ(ここではその4名)を毎回コードの中に埋め込むというのは面倒というか、できればコードはコード、素材データは素材データとして分けて扱いたいので、上記に加えてぼくが多用するのが「__DATA__」という記法*2です。

さっそく、それを使って書き換えてみましょう。

#!/usr/bin/env perl
use strict;
use warnings;

my @band = <DATA>;

for my $member (@band) {
    chomp $member;
    if ($member =~ /\z/) {
        print "$member\n";
    }
    else {
        print "$memberさん\n";
    }
}

__DATA__
ジョン・レノン
ポール・マッカートニー
ジョージ・ハリスン
リンゴ・スター

はい。だいぶスッキリしました。
結果は先ほどと同じですが、一応実行してみましょう。
gyazo.com

いいですね。
こうすることによって、対象のデータがいくら変わっても、それは「__DATA__」より下の部分で書き換えればよくなり、それより上のコード部分を触る必要がなくなります。

また、この方法だと1本のスクリプトファイルで完結するので、コードもデータもそれぞれ手軽に書き換えられて便利です。

じつのところ、ぼくが普段の仕事に関連して書くコードの大半は、これのバリエーションです。

たとえば、少し前に、別のアドベントカレンダーでこんな記事を書いたのですが、
note103.hateblo.jp

この後半で紹介している、本の脚注データを分析するコードにしても、途中でハッシュを使ったりはしていますが、基本形は上記と同じであることがわかるかと思います。

実際には、もう少し踏み込んだことをしようとすると、コードとは別に置かれた素材ファイルを読み込んだり、結果を別のファイルに書き出したり、あるいは任意のディレクトリにあるファイルを読み込んだりもしたくなってくるのですが、まずは上記のようなことができるだけでも、かなりいろんな作業が効率化するので、入門者の方は試しにこれらのセット(for + if + 正規表現 + __DATA__)を自分の環境で動かしてみてはいかがでしょうか?

ちなみに、環境構築を含む第1回からの講義資料は、以下にまとまっています。
講義資料 - Perl入学式 | Perl Entrance

ということで、本日の記事は、以上です。

明日の……ではなくて、本日のご担当はgomaaaさんです!

Perl入学式のアドベントカレンダー、ひき続き、お楽しみに。
qiita.com

*1:ぼく自身は本の編集をしています。より詳しくはこちらをどうぞ。→ note103 - note103 - Scrapbox

*2:『初めてのPerl(第6版)』によると、厳密には「ファイルハンドル」と呼ばれるようです。ファイルハンドルとは、Perlの処理世界と外部世界(おそらく素材のテキストデータなど)を結びつけるコネクションの名前、とのこと。詳しくは同書をどうぞ。

初めてのPerl 第6版

初めてのPerl 第6版

編集とプログラミングと私

こんにちは。こちらは「編集とライティングにまつわるアレコレ」アドベントカレンダーの2日目の記事です。

adventar.org

昨日は本企画の発案&主宰の id:mohri さんによる以下の記事でした。

mohritaroh.hateblo.jp

GitHub Desktop、なかなか良さそうですね。

こういったGUIツールは何となく使い方を覚えるまでが面倒。という先入観があって触ってなかったですが、思っていたより直感的に使えそうなので一度試してみようかな〜と思いました。

あと、GitHubありきではなくてローカルファイルの版管理ツールとして使ってみるという視点も新鮮でした。

私にとっての「編集」

さて、今回の大テーマは「編集とライティング」ということですが、ライティングはともかく「編集」というのはけっこう大ざっぱというか、幅の広い概念ですよね。

たとえばぼく自身が抱く印象としては、「編集」と言ったら「翻訳」に近いというか、左っかわのテーブルに置いてある「素材」を目の前で何やらこねくり返して、右っかわのテーブルに「仕上がり」としてポンと置いていく、変換していく、みたいな作業を思い浮かべます。

これは文字校正とか、文章全体の構成を組み換えるとか、あるいは文字起こしなんかも近いでしょうか。
(文字起こしは音から文字への変換なので)

しかし一方で、メディアの編集といったら企画とか営業みたいな側面もありえるでしょうし、取材なんていうのもけっこう独自のメソッドというか、世界観がありそうです。

ぼくの場合、対談や座談会をテキスト化するために現場に立ち会う、みたいなことは時々あるものの、やはりどちらかというと前者の翻訳的なこと、仕事場にこもってモノが仕上がるまで出てこない。みたいな作業が多くて、後者の、いわばゼロからイチを立ち上げていくような作業にはあまり馴染みがないので、ここでは馴染みのある前者の方を念頭に置いて書いていきます。

(ここまで前置きでした)

この記事のテーマは……

さて、今回のアドベントカレンダー、当初はこんなに速攻で埋まるとは思っていなくて、きっと一人で何個か書くだろうと勝手に思っていたので、だったら最初はVimの小ネタをサクッと書いて、あとは空き状況によって書けるものを書くか〜、とか思っていたのでしたが、あっという間に全席埋まりましたね。 😅

よって方針を変えまして、この記事ではVimを中心としつつもプログラミング全般みたいなことを視野に入れ、最終的には上の方で書いた、ぼくにとっての編集作業みたいなことをぼんやり醸していけたらいいかと思っております。

これに際して、じつは最初に「編集(やライティング)のアドベントカレンダー」と聞いて、んー、まあネタとしてはこの辺か? と思ったのがあるので、とりあえず見出しだけ列記してみますと、こんな感じで。

1. 便利なショートカットあれこれ
2. 便利なExcel関数あれこれ
3. 私のメール術
4. Vimでどんなことをしてるのか
5. シェル(bash)でどんなことをしてるのか
6. Perlでどんなことをしてるのか

まあ、これで6日は消費できるかな、とか思っていましたが、上記のとおりもうそんな席は残っていませんし、かといってこれを全部1本の記事に詰め込んでいたら書くのも読むのも大変なことになりますから、今回の記事ではその中から4番目のVimと6番目のPerlについて、要点をつまみつつ書いてみます。

ちなみに、そんな経緯でこの後は、しばらくプログラミングにまつわる話が続きますが、実際には上にもあるように「私なりのメールの書き方」とかもネタに入れていたぐらいなので、今後に続けて書かれる方におきましてはこういう技術ネタに縛られず、好きなことを書いてほしいと思っています。

(まだ前置きでした)

Vimでサクッと書き換える

さて、もう何度も書いてるのに今さらですが、こちらをお読みの皆様は「Vim(ビム)」ってご存じでしょうか?

いや、ぼくも他人に語れるほど知ってるわけではないですが、えーと入門的には、やはりドットインストールあたりが親切でしょうか。

https://dotinstall.com/lessons/basic_vim

ちなみにぼく自身がVimに触れはじめたのは、以下の記事の頃でした。2013年。

ここ数日のvim - 103

ようはテキストエディタでありまして、ぼくで言ったらVimの前にはCotEditorというのを使っていましたが、

coteditor.com

まあMacだったらテキストエディットというのもデフォルトでありますし、そういうメモ帳的なものですね。

ただ、このVimというのは単なるメモ帳にはまったくとどまらず、文字を打ち込む以上のことがあれこれできてしまいます。

具体的には、たとえば上に書いたこれ、今回のためのネタ帳ですが。(再掲)

1. 便利なショートカットあれこれ
2. 便利なExcel関数あれこれ
3. 私のメール術
4. Vimでどんなことをしてるのか
5. シェル(bash)でどんなことをしてるのか
6. Perlでどんなことをしてるのか

この行頭のナンバリングに続く「ドット」の部分を、「閉じ丸括弧」に変えたい! というときにどうするか。

まあ、このぐらいの行数だったら手動でポチポチ書き換えてもいいわけですが、これが100行も200行もあったらどうでしょうか。けっこうキビシイですね。

もちろん(というか)、上記のCotEditorをはじめ、エディタに付属している検索&置換機能を使う手もあるわけですが、とりあえずVimだったらこうします。

gyazo.com

はい。その変えたいところ(ドット)を直接さわるようにして、一列分フイッと変えてしまいました。

べりー、便利!

これがもし、検索&置換用のウィンドウにわざわざ入れていくと、こんな感じになると思うのですが。(Googleドキュメントを使ってみます)

gyazo.com

たしかに、これもわかりやすいんですが、でも「今ある状況」と「求める結果」との間にその置換用ウィンドウが挟まってしまって、ちょっと直感的ではありません。

しかし、Vimならば上のとおり、あたかも直接自分の手で対象をさわっているかのように、書き換えていくことができるのです!

(……)

大丈夫でしょうか。大丈夫ですね。

Vimで知りたい情報をカウントする

さらには、Vimを使えばもっと面倒な作業だって簡単にできてしまいます。

例として、こんな素材を持ち出してきましたが。

f:id:note103:20171201023132p:plain

これはぼくが今メインでやっている仕事の「commmons: schola(コモンズ・スコラ)」という、坂本龍一さんがかれこれ10年近く続けているライフワーク的音楽全集で使っている脚注のデータですが。

commmons scholaについて | commmons:schola(コモンズスコラ)-坂本龍一監修による音楽の百科事典- | commmons

このシリーズ、CDブックの形態ですでに第16巻まで刊行していまして、いま第17巻を絶賛制作中なのですが(ピークです)、それゆえ脚注も16巻分のデータが溜まっていまして、上記はそれをスプレッドシートで管理している画面の一部です。

で、その左端の方、A列に数字が並んでいますが、それが巻のナンバーで、B列にある見出し語句が第何巻に掲載されたか、ということをA列から読み取れるようになっています。*1

では、この全データ(2008行ありました)のうち、第6巻の脚注は何個あったんだろう? というときにどうするか。

まあ、そのスプレッドシートの機能をちょこちょこ使えばカウントできるかもしれないですが(知らないのですが)、Vimを使うなら、こうします。

1. まず内容をVimに全コピペして
2. コマンドラインモード(というのがあります)で以下を打ち込む

:%s/\v^6\t//gn

と、このように出てきます。(一番下の方を見ておいてください)

gyazo.com

はい。104個ありました。

Perlで知りたい情報をカウントする

しかしそうなると、6巻だけじゃなくて、他の巻の注釈個数も全部一気に知りたい、という欲も出てきます。

果たして、そういう場合にはどうすればいいでしょうか?

前述のとおり、このシリーズはすでに16巻出ていますから、同じことを地道に16巻分(厳密にはあと15回)繰り返すべきでしょうか?

もちろん、そうするのも自由ですが、思い出してください。我々にはPerlがあるのでした!

(……)

はい。結論から言いますと、じつはつい数日前に、実際にその情報を知りたくてそのためのコードを書いたからここでネタにしているのですが、そのときにはこういうものを書きました。

#!/usr/bin/env perl
use strict;
use warnings;

my @array = <DATA>;

my $num;
my %count;

for (@array) {
    chomp $_;
    if ($_ =~ /\A(\d+)\t/) {
        $num = $1;
        if ($num == 16) { $count{$num}++; }
        elsif ($num == 15) { $count{$num}++; }
        elsif ($num == 14) { $count{$num}++; }
        elsif ($num == 13) { $count{$num}++; }
        elsif ($num == 12) { $count{$num}++; }
        elsif ($num == 11) { $count{$num}++; }
        elsif ($num == 10) { $count{$num}++; }
        elsif ($num == 9) { $count{$num}++; }
        elsif ($num == 8) { $count{$num}++; }
        elsif ($num == 7) { $count{$num}++; }
        elsif ($num == 6) { $count{$num}++; }
        elsif ($num == 5) { $count{$num}++; }
        elsif ($num == 4) { $count{$num}++; }
        elsif ($num == 3) { $count{$num}++; }
        elsif ($num == 2) { $count{$num}++; }
        elsif ($num == 1) { $count{$num}++; }
    }
}

use DDP {deparse => 1};
p %count;

__DATA__

冗長!

……ともあれ、詳細は割愛しますが、この最後の「__DATA__」と書かれた下に件のリストをまた全コピペして、実行するとこんな風に出てきます。
(画面の下半分を見ておいてください)

gyazo.com

ヒュー! 一発で出てきましたね。
6巻もちゃんと104個になっています。

(8巻多すぎ……)

まとめ

いかがでしょうか?

本記事はVimPerlの入門を目的としたものではなく、いち編集者であるぼくが、普段どんなふうに自分なりの作業をしているのか、ということを紹介するものだったので、いろいろな細かい手順や前提を驚異的なまでに省略してしまいましたが、こうしてプログラミングを絡めると、日々の地味〜な作業も飛躍的に効率化され、なおかつ目覚ましいほどのクリエイティヴィティを味わえる! みたいなノリが少しでも伝わりましたら幸いです。

ちなみに、ぼくがVimにのめり込むきっかけになった話や、Perlをはじめとするプログラミング入門についてなどは以下にもちらちら書いていますので、ご興味のある方はぜひどうぞ。

ということで、本日の記事は以上です。

最後までお読み頂き、ありがとうございました!

明日のアドベントカレンダーのご担当は id:minesweeper96 さんです。
お楽しみに!!

adventar.org

*1:同じ語句でも巻によって内容が違うので、「エディ・コクラン」なんかは複数記載されています。

基本情報技術者試験にうかった

f:id:note103:20171115124810p:plain

超ぎりぎり(笑)。*1

これまでの経緯。

基本情報技術者試験を受けてきた - the code to rock
基本情報技術者試験の結果 - the code to rock
基本情報技術者試験を受けてきた(2) - the code to rock

今年の春に「あと0.5点」というところで落ちた後、秋の受験(10/15)に向けて7月から学習を再開し、それから試験当日までの3ヶ月ほど、仕事に並行して勉強を続けていた。

勉強している間は、「前よりわかるようになってるな〜」などと一瞬浮かれた気分になっても、すぐに「でも落ちるかもしれない・・」と冷水をかける自分もいて、気が休まることはなかった。

どれだけ普段うまく行っていても、本番で駄目ならまた受験しなければならないわけで、「これだけの努力をまた続けられるだろうか?」とか、「すでに2回めじゃないか。もし落ちたら、3回めもできるか?(いや、できない)」などという、うんざりするような気持ちに何度も襲われた。

だから、「うかったらどれだけの解放感を味わえるだろう!」と期待していたのだけど、ん〜、案外そんなに、解放感はない。
嬉しさも、思ったほどではない。むしろなんというか、真顔というか、無常というか・・。

といっても、べつに燃え尽きたとかいうのでもなくて、単になんというか、「まだまだ先は長いな〜・・」という感じ。

世の中には、もっと大変なことや取り組むべきことがたくさんあって、自分はまだその入り口にも達してないんじゃないか、という。

これをクリアしたらどれだけ「上」に行けるかと思っていたけど、いやいや、まだ全然ふもとですから、と言われているかのような。

でもまあ、そのように思えるというのは、やっぱりどちらかと言ったら、幸せなことなんだろう。

この脱力感、このドヨーンとした感じ。それも見方によっては、一種の解放感と表現できるのかもしれない。

では唐突に、謝辞の時間。

今回の試験勉強では、以下の方々に大変お世話になった。

  • 福嶋宏訓さん
  • 大滝みや子さん
  • 瀬戸美月さん
  • 岡嶋裕史さん
  • 滝口直樹さん
  • インプレス/ノマド・ワークスさん

いずれも今回使用した参考書の著者さんである。

最初に挙げた福嶋さんは、もう何年も前から情報技術に関する参考書を書かれているようだが、そのかたわら、ご自身のWebサイトで動画講義(スクリーンキャスト的な)を無料で公開していて、今回はそれを猛烈に見た。

Webサイトには読者限定の部屋などもあり、その詳細については以下の本に載っているので、興味のある人は見てみると良いと思う。

※ぼくが買ったのは2017年版だが、そちらに記載されているサイト情報(限定部屋へのパスワードなど)はそろそろ期限が切れるようだから、この2018年版という方を紹介しておく。

うかる!  基本情報技術者 [午前編] 2018年版 (福嶋先生の集中ゼミ)

うかる! 基本情報技術者 [午前編] 2018年版 (福嶋先生の集中ゼミ)

  • 作者:福嶋 宏訓
  • 出版社/メーカー: 日本経済新聞出版社
  • 発売日: 2017/11/16
  • メディア: 単行本(ソフトカバー)
うかる!  基本情報技術者 [午後・アルゴリズム編] 2018年版 (福嶋先生の集中ゼミ)

うかる! 基本情報技術者 [午後・アルゴリズム編] 2018年版 (福嶋先生の集中ゼミ)

  • 作者:福嶋 宏訓
  • 出版社/メーカー: 日本経済新聞出版社
  • 発売日: 2017/11/16
  • メディア: 単行本(ソフトカバー)

※追記(2017/12/05): この記事を書いた少し後、2017年12月からWebサイトがリニューアルされていたので、そちらへのリンクを以下に貼っておく。本を持っていない人でも閲覧できる動画がけっこうたくさんあるはず。エンジョイ!(追記ここまで)
xn--tpto73d.jp

元はと言えば、ぼくはとにかく午後試験第8問のアルゴリズム問題が恐ろしく苦手で、そもそも何を聞かれているのかもわからない、という状況が長く続いたのだけど、なんとかそれを克服したいと思って片っ端からその手の参考書を買った中に福嶋さんの本があった。

福嶋さんの教え方の特徴というのは、生徒(読者)に媚びないというか、対等に接しているようなところで、読者に耳当たりのいい(甘い)ことだけを言う、みたいなところがまったくなく、たとえば「問題を解けないのは勉強が足りないから」とか身もふたもないことをバッサリ言い切る。*2

たしか具体的には、「よく『午前はできるのに午後は時間が足りなくて落ちた』なんて言う人がいるんだけど、それは練習が足りないだけなんだよね」みたいな。これはまったく図星だったし、すごく響いた。

ただぼくの場合は、それを聞いて落ち込むとか、憤りを覚えるとかいうことでもなく、「あ、そっか。時間が足りないだけなんだ。じゃあ、時間をかけて何度も問題練習すればできるようになるかも?」とそのまま受け止めて、実際そのように臨んだ結果、なんと春の試験では7問中2問しか解けなかったアルゴリズム問題(つまり正解率3割未満。しかも当てずっぽう)が、この秋試験では8割取れていた。

まあ、それはちょっと出来すぎとしても、その「なんだ、時間をかければいいだけか」と思わされたのはとても大きなことだった。

2番めに挙げた大滝みや子さんについて、上記の通り、今回は何と言ってもアルゴリズム問題がすべてを左右すると思っていたものの、とにかく何回やっても問題の意味すらわからん、何を聞いているのだ? 問題が悪いだろ! みたいなヒドイ状態だったのだけど、上述のいろいろ買いまくった参考書の中に大滝さんの以下の本もあって、おそらくぼくがアルゴリズム問題の深い蟻地獄的暗闇から抜け出すきっかけになったのは、この本だったと思っている。

基本情報技術者 大滝みや子先生のかんたんアルゴリズム解法 ~流れ図と擬似言語~  第3版

基本情報技術者 大滝みや子先生のかんたんアルゴリズム解法 ~流れ図と擬似言語~ 第3版

  • 作者:大滝 みや子
  • 出版社/メーカー: リックテレコム
  • 発売日: 2015/01/28
  • メディア: 単行本

同書は前半で流れ図、後半で擬似言語(試験に出てくるやつ)の解説という構成になっていて、ページを追うごとに徐々に難しくなっていくのだけど、どれをとっても解説が丁寧で、「あ、これはわかるな」「これもわかるわ」「なかなかわからなくならないな〜」「これもわかる・・」とかやっているうちに最後まで行ってしまった。

これによって、それまでの「俺イコール擬似言語苦手」という思い込みはいつの間にか払拭され、「俺イコール少なくともこの本に書かれているような擬似言語ならわかる」という状態になり、なんというか、「絶対的な苦手意識」が「限定的な苦手意識」に変わった。

この大滝さんの教え方のうまさというか、説明のあり方には目からウロコの感じがあり、そのまま以下の2冊も購入して読んだけど、

基本情報技術者試験 アルゴリズムと表計算

基本情報技術者試験 アルゴリズムと表計算

  • 作者:月江 伸弘
  • 出版社/メーカー: 実教出版
  • 発売日: 2011/10/01
  • メディア: 単行本
情報処理教科書 基本情報技術者 スピードアンサー338

情報処理教科書 基本情報技術者 スピードアンサー338

  • 作者:大滝 みや子
  • 出版社/メーカー: 翔泳社
  • 発売日: 2012/08/24
  • メディア: 単行本(ソフトカバー)

いずれも良書で、表計算の本も非常に役立ったし(これはむしろ、試験後の自分の業務に生きているが)、もう一方の「スピードアンサー」も能率的な本で、これは紙と電子版の両方を買ったのだけど、おそらく今後も折りに触れ読み返すだろう。

教えるのが上手い先生に出会えるというのは、それだけで幸運なことである。
教えるのが上手い先生というのは、単に試験の得点を上げてくれるというだけではなく、勉強することの面白さを教えてくれる。

勉強するのが面白かったり嬉しくなったりすると、あとは言われなくても自分でどんどんやるようになるわけで、上記の福嶋さんのコメントにも繋がるが、自分でどんどんやったら必然的に勉強量も多くなる。

瀬戸さん、岡嶋さん、滝口さんの本は前回の春試験から触れていたもの。

瀬戸さんは以下の本をフライング的に買ったら、

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

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

(これも実際に買ったのは平成29年度版だが、一応最新版を載せておく)

ご自身のYouTubeチャンネルで公開している動画が紹介されていて、そこではソート系をはじめとする基礎的なアルゴリズムなど、基本情報にも大いに関わる定番トピックがわかりやすく解説されていたので大変役立った。

滝口さんは昨年末にITパスポートの受験を志した際に以下を買ったのだけど、

それに付録でついていた音声講義が良かったので、今回は以下を買ったところ、それにも付録の音声講義が付いていて、とくに春受験の勉強ではよく聴いた。

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

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

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

岡嶋さんの本は以下でも紹介したが、

基本情報技術者試験を受けてきた - the code to rock

「教科書でこんなの、アリなのか・・?」と思うほどハイコンテクストというか、オタク的とも言えるディープなウケ狙いが散発していて、やはり岡嶋さんの本に出会えたのも幸運なことだった。(これも紙と電子版の両方買った)

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

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

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

ちなみに、岡嶋さんのその本は、見てもわかる通り基本情報用ではなくITパスポート用なのだけど、基本情報の午前試験用としても充分使える内容だと思う。

上記の通り、今回はこれまで以上にいろいろな参考書を買って読んだけど、じつは書籍として一番役に立った&繰り返し読んだのは、インプレスが出している過去問集だったと思う。

それも、一応試験前になって最新の29年度秋版も買ったのだけど、実際に頻用したのは春試験のために買った28年度秋版だった。

この過去問集は大判なのだけど、紙が軽いのでどこへ移動するにもよく持ち歩いた。

古い方の過去問集には書き込みやマーキングも多くなっていて、どの問題をどう間違えたのかとか、どのキーワードを忘れやすいか、とかがわかりやすかったから、それはまるでお守りのようで、実際、試験会場に持っていった参考書はこれと上記の「スピードアンサー」の2冊だけだった。

同書は非常に行き届いた内容で、版元のインプレスさんと制作のノマド・ワークスさんには心からの感謝を伝えたい。

もうひとつ、これは今回の試験に直接関わることではないのだけど、このブログではお馴染みの無料プログラミング講座「Perl入学式」の名前も挙げておきたい。

www.perl-entrance.org

やはり2013年、38才の夏に、「プログラミング」とか「YAPC::Asia」といった未知の大海にダイヴすることになったきっかけはPerl入学式であり、もし以下の記事をたまたま読んでいなかったら、

http://yapcasia.org/2013/08/perl-entrance-meets-yapc-asia.htmlyapcasia.org

そしてその時、その話を真に受けて飛び込んでいなかったら、今回こんな試験を受けることもなかっただろう。
今までそんなことは考えもしなかったが、これを書きながら、ふとそのことに気がついた。

校長の @papix さん、そしていつも多岐にわたりサポートしてくださる @xtetsuji さん、その他各地域の皆さんに深く感謝します。

あ、そうそう、上では「今回の試験に直接関わることではない」と書いたけど、ひとつだけ直接関係することがあった。

というのも、今回の午前試験ではこんな問題が出たのだった。

第8問 Perlの実行に関する記述のうち、適切なものはどれか。
 

  • ア UNIX用として開発されており、Windows用の言語処理系はない。
  • イ 実行にWebサーバを必要とする言語であり、CGIの開発に適している。
  • ウ 動的デバッグは、言語処理系から独立したプログラムを実行して行う。
  • エ プログラムをコンパイルしたファイルを事前に用意する必要はない。

 
基本情報技術者試験平成29年度秋期・過去問題より)

おお〜、Perl出てんじゃん! と盛り上がって、一瞬集中が切れてしまった。
(正解はこの注釈→ *3

最後に、これもある意味謝辞ではあるが、以下の動画を紹介して終わりたい。

AlgoRythmics - YouTube

この一連の動画では、ソートのアルゴリズムを素敵なダンスと音楽で表現している。

何をきっかけに知ったのか、すっかり忘れてしまったが、これを見て、ぼくはソートのアルゴリズムを義務的なものとしてではなく、楽しみとして勉強できるようになった。

その辺の厚紙を小さく切ってカードを作り、動画を見ながらそのカードを何度も並べ替え、何度もリプレイし、また何度も並べ替えた。

基本ソート&応用ソートはほぼ網羅されているはずだが、ここでは最初に大きなインパクトを受けたクイックソートを貼っておく。

www.youtube.com

どれも踊りが超かわいい。音楽もいい。センスを感じる。

まあでも、ひとまず終わってよかった。喜びや解放感がないとは書いたが、多少の安心は得た。ほっとした。
プラスの感じではないけれど、マイナスがゼロに近づいた感覚というか。

これからどうするか、少しは考えてもいるが、登るべき山も飛び込むべき海も多すぎて、はっきりした見通しは何もない。
しかしその見通しのなさは、必ずしも不快なものではない。

*1:合格基準点は午前・午後ともに60点なので。前回は59.50点という逆のぎりぎりで涙をのんだ。

*2:念のために書いておくと、とくに失礼な印象はない。比較的若い世代の読者を想定しているとは思うが、むしろ相手を一人前の人間として扱っているからこそ、そういうオープンな雰囲気が醸されているのだと感じる。

*3:エ。もちろん当たっていた。