プログラミング入門を支える技術

• こちらはPerl入学式アドベントカレンダーの21日目の記事です。
• 昨日は@karkador73さんの「Perl入学式に参加して、いろいろ刺激を受けた件」でした。
  • ぼくは普段 in東京のメンバーとしかつながりがないので、すごく新鮮な話でした。
  • @karkador73さんがPerl入学式に参加したきっかけは@sago35tkさんからの誘いということですが、その@sago35tkさんも比較的最近からの参加なので、そうやって新しいメンバーがどんどん新たなつながりを作っていく、というのはPerl入学式の稀有な特長だと思います。

• さて、本日の記事では、ぼくが普段プログラミングに触れながら考えていることのうち、あまり他では聞かないというか、むしろ通常言われるセオリーみたいなものとは逆な気もするけど、人によっては役立つかもしれない視点というか、方針について、いくつか書いてみたいと思います。
• 先に簡単に自己紹介をしておくと、ぼくは普段はフリーの編集者として過ごしていて、今はおもに坂本龍一さんの音楽全集「schola（スコラ）」の制作に携わっています。
  • じつはたまたま本日12/21（水）、1年ぶりとなるシリーズ最新刊が発売されました！！
  • いやー、偶然だなあ。（ハハ）
  • 公式ページのどこかにぼくの名前もあります。（→公式ページ）

commmons: schola vol.16 Ryuichi Sakamoto Selections: Japanese Pop Music

• それ以外だと、去年の夏頃に山口県のYCAMという文化施設のWebサイトのリニューアル・プロジェクトに参加したりしました。（→参考記事）
• そんな中、プログラミングは趣味として、2013年の春頃に始めました。そして同年夏からPerl入学式に生徒として通い始めて、翌年から生徒出身のサポーターとして活動に加わっています。
• だから、というわけでもないですが、この記事で想定している「プログラミング入門者（初心者）」は、とくにITの仕事をしているわけでも、それを志しているわけでもない、「一般人だけど趣味で始めてみた」というような人です。
• よって、IT企業の新人さんや、そうした進路を検討している情報系の学生さんなどはちょっとズレますが、部分的には参考にしてもらえるところもあるかもしれません。
• また、上記のような初心者に「教える立場」の人にも、参考になる要素があるかもしれません。

Contents

1. 明確な目標はなくてもいい

• 少なからぬ書籍やネットの記事において、「まずは学習を始める前に、プログラミングでどんなものを作りたいか、具体的にイメージしてみよう！」なんてことが言われます。
• その心はと言うと、「目標が曖昧だと何をやればいいかわからなくて、無為に時間が過ぎるから」とか、「ゴールがはっきりしていれば必要な学習内容に集中できるから」ということのようですが、そこまで聞いても、ぼくにはこれは奇妙な方針だと思えます。
• もしあなたの目の前に、初めて見る精巧な機械をポンと置かれて、「使い方は後で教えるから、まずはこれで何を作りたいか具体的にイメージしてみよう！」と言われたらどう思うでしょうか？
• プログラミングの初心者とは、プログラミングに関する知識がない（または少ない）人ですから、まだそれを教わっていない段階で、「それを使って何ができるのか」を想像させるというのは矛盾があります。
• しかし現実には、そうした要求をする「教える人」が少なくないように見えます。なんでだろう？　と以前は不思議に思っていましたが、これはおそらく、「教える側にとって都合がいいから」ではないか、と今は思っています。
• たしかに生徒さんの方から、「ぼくは掲示板を作りたい！　Twitterアカウントでログインできて、画像も投稿できるようにしたい！」などと具体的なリクエストを言ってくれれば、「なるほど、じゃあそのためにはこの言語を覚えて、この知識を身につけて……」という具合に、何を教えたらいいのか、自然と決めやすくなるかもしれません。
• 一方、「いや〜……とくに何を作りたいとかはないんだけど、とにかくプログラミングをやりたいというか……」などとぼんやり言われてしまうと、教える側としては、提示できる選択肢が無限に広がってしまい、「もう少し具体的に注文してよ！」という感じになってしまうのかもしれません。
• しかし上記のとおり、初心者が知っている「プログラミングで実現できること」なんていうのは、「ない」か、あってもせいぜい数種類しかないはずで、しかもそのなけなしの選択肢ですら、本人が「本当にやりたいこと」かといえば、怪しいものだと思います。
  • 今書きながら気づきましたが、これっていわゆる「顧客が本当に必要だったもの」問題を想起させます。
• ぼく自身のことを振り返ってみると、最初に「プログラミングをやりたい」と思ったときに頭にあったのは、「黒い画面になんか打ち込みたい」とか、「英数字でカッコよく構成されたあれ（ソースコード）を書きたい」みたいなものでしかなかった気がします。
• それは「先に作りたいものをイメージしよう」と助言してくれる人が期待する答えからは程遠いものかもしれませんが、それでもぼくが一番求めていたのは、そんな曖昧で、とらえどころのない憧れのようなものだったと思います。
• 「作りたいもの」なんてなくても、プログラミングの学習はできます。後述のとおり、すぐに（最短ルートで）求めるものに出会うことはできないかもしれませんが、続けていれば必ず、どんな曖昧な憧れであっても、近づいていくことができます。
  • 少なくとも、ぼく自身は入門から3年半が経った今、かつて思い描いていた上記のようなことは普通にできるようになりました。
  • 一応責任をもって、「作りたいものがなくてもプログラミングの学習をスタートする方法」を示しておくと、「入門書を読みながらサンプルコードを動かしていく」という方法があります。Rubyなら「たのしいRuby」、Perlなら「かんたんPerl」か結城浩さんの入門書、Pythonなら、未読ですが「独習Python入門」あたりが良さそうです*1。
    • たのしいRuby 第5版
    • かんたん Perl (プログラミングの教科書)
    • 新版Perl言語プログラミングレッスン入門編
    • 独習Python入門――1日でプログラミングに強くなる!
  • もし希望する言語がないのであれば、上記のようなプログラミング入門書の中で、一番表紙の雰囲気が好きなものにするといいと思います。
  • 動画サイトの「ドットインストール」も良い選択肢だと思います。無料ユーザーにもたくさんのコースが開かれているので、明確な目的がない入門者でも自分の好みに近いレッスンを選びやすいですし、動画1本につき3分なので、ちょっと試して合わなければすぐ次を試したり、スキマ時間に気軽に始めたりすることもできます。
    • http://dotinstall.com/
• 念のために付け加えておくと、初めから「プログラミング自体は目的ではなく、自分のやりたいことを実現するための手段である」と、明確に目標を意識化できている人は上記の限りではありません。
• また、すでに初心者的な段階を終えて、「プログラミングでどんなことができるのか」ということをある程度想像できる人であれば、「先にゴールを定めてから学習に取り組む」という方法も有効かもしれないと思います。

2. エラーは無理に読まなくていい

• プログラミングの入門初期には、「本やネットに書いてあるとおりに実行しているはずなのに、想定どおりの挙動をしない」ということが多々あります。
• そのようなときに、入門者はコンソールに出てくるエラーをろくに読みもせず、自分で書いた（あるいはコピペした）コードをじっくりまったり読み返しては、何度も同じエラーを出し続ける、ということがよくあります。
• そしてこのとき、教える側の人は、「エラーメッセージをちゃんと読んで！」と言います。これはまったく正しいアドバイスで、その点に文句はないのですが、そのアドバイスが果たして有効に働くのかと言えば、あまり有効ではないとも思います。
• 初心者にとって、コンソールに出てくるエラーというのは、もはや文字ですらない帯状の模様です。
• その中のどれが英語で、どれが数字か、という見分けさえすぐにはつきません。
• もし初心者と熟練者が、同じエラーメッセージを同時に覗き込んでいたとしても、両者が見ているのは別物です。おそらく熟練者は、行番号や主要なキーワードを真っ先に見つけているはずですが、初心者はそのメッセージにおける「どの単語がどの単語より重要なのか」という優先順をつけることができません。
• また、普段からプログラミングをしている人は、エラーメッセージが出てきた時点で、「またコイツか……」とばかりに「以前にそれを見たときのこと」を思い出したり、仮にそれが初めて見るエラーメッセージだったとしても、かつて経験したエラーをもとに原因の「仮説」を立てたりしているはずですが、初心者にはそうした過去の蓄積が少なく、経験していたとしてもすぐに忘れてしまっているので、結局毎回メッセージの行頭から、見慣れない文言を一つひとつ読み解いていかなくてはいけません。
• またそれと似た話で、「初心者はエラーメッセージが英語だから読みたがらない」ともよく言われますが、ぼくは「英語」はあまり関係ないと思っています。
• もし「Undefined subroutine ..」の代わりに、「指定されたサブルーティンが定義されていません」などと丁寧な日本語のメッセージが出てきたとしても、経験の浅い初心者には英語と同様の難解さがもたらされるでしょうし、逆にその日本語を理解できるなら、英語であっても理解できるはずです。
• つまり、問題は英語の能力や、本人のやる気の有無にあるのではなく、初心者は「なぜエラーが出たのか？」という文脈を想像できないがゆえに、エラーメッセージを「目に入れる」ことはできても、その意味するところを「読み取る」ことができないのだと思います。
• そうした前提を踏まえつつ、ぼくが思うのは、「エラーメッセージなんて、慣れれば自然に見るようになる」ということです。
• エラーメッセージは、プログラマーが離れたいけど離れられない悪友のような存在であると同時に、忌憚なく、しつこくミスを指摘し続けてくれる親友でもあるので、やがて自分が何をやっているのか理解しながらコードを書けるようになれば、進んでその声に耳を傾けるようになるはずです。
• 逆に言えば、苦しい思いをしてまでエラーを読んで、プログラミングに忌避感を抱いてしまうぐらいなら、気が済むまで何度でも、それを見慣れて頭に染み込むまで、同じエラーを吐き出させ続ければよいと思います。
• ここでも一応付け加えておくと、これは「初心者にエラーを読めとか言うな」という話ではありません。むしろ読むように言うべきですが、ただ、もしあまり積極的にエラーを読まない初心者がいたとしても、それは怠慢や指導者への反抗心によるものとは限らなくて、上記のような理由があるからかもしれないよ、ということです。そして、教える側がそのように思えれば、無用な軋轢を避けやすくなるのではないか、みたいな話です。

3. 先生が間違っているかもしれない

• このアドベントカレンダーの本体である「Perl入学式」は、プログラミングの初心者（またはPerlの初心者）に、無料でプログラミング言語Perlを教える有志による講座ですが、講義に使用する資料（教科書）もすべてメンバーがイチから作成しています。（→今年の資料）
• ぼくもその作成者の一人ですが、メンバーの中に職業としてプログラミングの講師をしている人は一人もおらず、みな自分の仕事の合間に時間を持ち寄って取り組んでいるので、残念ながら（というか）、資料中の不備や間違いも絶えません。
• 一方、講義を受講する生徒さんにとって、ぼくたちスタッフはいわば「先生」ですから、基本的には「間違っていない」ことが前提になります。
• よって、資料の中に誤記や、意味の通らない説明、問題文などがあっても、生徒さんによっては「わからない自分のほうが悪い」と思ってしまい、実際には教える側のミスなのに、それに気づかないまま少なからぬ時間を過ごしてしまう、ということも起こりがちです。
• そしてこのようなことは、じつはプロが作った入門書や技術書でも起こることで、たとえば本の途中から、それまでに一度も説明していない用語や概念を使って話を進めてしまい、それ以降は読者を置いてけぼりにしてしまうような本もよくあります。
• 商業出版物でもそんなことが起きてしまう理由には、そうした技術書が必ずしも「執筆のプロ」によって書かれているわけではない、ということがあるのではないかと思います。
• 小説家や評論家、あるいは各種のメディアに寄稿する本職のライターなどは、みな執筆のプロですが、プログラミングなどを扱う技術書では、執筆で生計を立てているわけではない、それぞれの専門的な分野で活躍する人が文章を書く、ということが多々あり、それは言い換えると、「執筆のプロではない人が執筆している」という状況です。
• 言うまでもなく、そうした状況が悪いわけではなく、そうでなければ生まれなかった名著も数え切れずあるはずですし、むしろそのような「執筆のプロではない人が書いた良書」を生み出すために、「編集者」と言われる人々が読者と執筆者の間に入り、わかりづらい表現や各種のミスを修正して回るわけですが、とはいえ編集者にできることにも限りがありますから、やはり書き手が執筆のプロであるかどうか、という点はどうしても影響してくるところだろうと思います。
  • ちなみに、個人的に思う「執筆のプロ」とそうでない人の一番の違いは、「読者の視点で自分の文章を読めるかどうか」という点にあると思います。それは「読者に対する想像力」とも言えるもので、たとえるなら、幼稚園の先生が何人もの園児たちを引率して外を歩くとき、園児がちゃんと自分についてきているか、つねに振り返って確認しながら先頭を歩く姿に似ています。
  • ぼく自身はこのような、「読者がちゃんとついてきているかどうか」を想像しながら文章を書ける人が「執筆のプロ」だと思っています。
• 話を戻すと、書店で売られている本だからといって、必ずしも安心して身を委ねられるわけではない、ということです。もし入門書などを読み進めているときに、よくわからない説明などに出会ったら、「自分が悪いはず」と思いすぎず、「この著者の表現がわかりづらいのではないか？」と疑ってみることも必要だと思います。

4. 最短ルートはないけど遠回りもない

• よく経験者からの助言で、「自分はAの勉強より先にBの勉強をしていたから、効率がよかった」とか、「私は間違ってAの勉強から始めてしまったけど、時間の無駄だった。Bからやればよかった」といったふうに「学習の最短ルート」を示すような話を聞くことがありますが、ぼくはこういう話はちょっと怪しいと思っています。
  • 上記の「A」「B」には、「HTML」や「JavaScript」、「C言語」や「データベース」といったプログラミングの学習対象を適当に入れてみてください。
• というのも、これがもし資格試験のように、過去の出題データをもとにして、その後の傾向をある程度予測できる分野であれば、効率的な学習の最短ルートを分析したり、体系化したりすることも可能かもしれませんが、一度しかないその人の人生から導き出される「別の方法をとっていれば云々」というタラレバの話は、実際にはとくに検証されたわけでもない、根拠のない思い込みに過ぎない可能性があるからです。
• もし、「Aが駄目だったからBを試したらうまくいった」という人がいたとしても、それはもしかすると、「先にAを試したことが助けになって、その後のBがうまくいった」のかもしれませんし、いずれにせよ、その人が時間を遡って、他のすべての条件を同一に揃えて、別の方法を検証することは原理的に不可能です。
• さらに言えば、100人の学習者がいれば、100通りのスタート地点があり、100通りのゴールがあるはずです。仮に、誰かにとって最短ルートの方法が見つかったとしても、それが他の人にも同様に作用するかと言えば、そのような保証はどこにもありません。
• つまり、学習において、事前にわかる最短ルートなんて存在しないということです。
• と同時に、最短ルートがないということは、遠回りもない、ということです。それが無駄な努力だったなんて、証明できる人はいません。
• 学習というのは、続けるかぎり能力が向上するものだとぼくは思います。その「能力」の定義は時間の経過とともに変化するかもしれませんが、途中でやめてしまわないかぎり、その成果は生まれ続けるはずです。
• というか、途中でやめてしまってすら、無駄になるとは言えないでしょう。どうもプログラミングを学ぶことは、あたかも無条件に良いことであるかのように語られがちですが、「やってみたらあまり興味を持てなかった」という人がいてもそれはそれで自然なことですし、そういう場合には、もっとその人に向いたことに自分の人生を費やすべきかもしれないですから。

5. 自分に合った方法は自分で作るしかない

• 事前に考えていたトピックは上記の4点でしたが、最後にひとつ思い出したので、それを書いて終わりにします。
• ここまでに書いてきたことも含めて、基本的に他人が示してくれる方法というのは、ユニクロで売っている既製服のようなものです。
• ユニクロは、あなたの体型に合わせて服を作っているわけではありません。人間の体型を数種類の「大体のかたち」に分けてそれを作り、お客さんはその中から「自分の体型に近い服」を買っています。
• 他人が示してくれた学習の方法は、世界に一人しかいないあなたのための方法ではありませんから、うまく機能しないこともあるでしょう。
  • むしろ、機能しないことばかりかもしれません。
• これは学習に限らないと思いますが、自分のパフォーマンスを最大限に発揮するには、既存の方法を参考にしながらも、最終的には、自分だけにフィットした、オーダーメイドの方法を作る必要があるのだと思います。
• その方法は、他の人にはフィットしないかもしれませんし、もしかするとほんの数ヶ月後のあなたにすらもう合わないかもしれませんが、「今までいろいろ試したけど、どうしても長続きしなかった」という場合には、この考え方が役立つかもしれません。

• 本日の記事は以上です。
• 明日のアドベントカレンダーは、吉祥寺.pmの主宰でもある@magnolia_k_さんです。
• 今年のPerl入学式 Advent Calendarは、例年に増して多彩な人たちが参加していて面白いので、ぜひお楽しみください。

qiita.com

*1:その後に買って読んだら面白かったです。関連記事 → 変数は「箱」か？（3） - the code to rock

Gitでブランチ名を入力補完する方法がわかった

ここ数日、Perl入学式の講義資料を修正する作業をやっているのだけど、

• 公式サイト

www.perl-entrance.org

• 講義資料のあるリポジトリ

GitHub - perl-entrance-org/workshop-2016

• 作業風景

current status pic.twitter.com/dLa2bQRlO6

— Hiroaki Kadomatsu (@note103) 2016年12月2日

工程としては、そのリポジトリを手元にcloneして、ある程度のまとまりというか、修正の種類ごとにブランチを切って、それぞれ手を入れた後にコミット＆プルリクしていく、というもので。

しかし普段、ぼくのGit用途ってとくにブランチを切る必要もないことばかりなので、そのブランチ間を移動するっていう経験じたいあまりなく、それゆえ、たまにやるとついブランチ名を長くしてしまって（一意になるように）、しかしディレクトリ移動時のように途中まで打ち込んでからタブを打っても入力は補完されず（当然）、ぐむむ……と思いながら地道に手で打ち込んでいた。

さらにしかし、今回はその修正対象がけっこう多岐にわたったこともあり、ブランチの数やその名前もどっと増えてしまったので、さすがにこれはツライ……とTwitterにとりあえずそのストレスを呟いて気を落ち着けようかと思ったのだけど、よくあるパターンとして、そうすると誰かが「こんな方法があるよ」と教えてくれたりするので、そこまでわかっているならそのやり取りも省略して自分で先に調べよ……と思って検索したらすぐに見つかって問題が解消した。

まず参考になったのは以下で、
qiita.com

内容は短いのだけど、ようは以下のリポジトリを紹介していて、

• git/contrib/completion at master · git/git · GitHub

bashを使っているなら、その中のbash用ファイルをそのファイル冒頭に書かれているとおりに設置＆設定すればいい。

.bashrc

source ~/.git-completion.bash

ちなみに、同リポジトリにあるプロンプトをいい感じに設定できるシェルスクリプトもなかなか素敵で、ついでにそれも設定しておいた。

source ~/.git-prompt.sh

before

PS1='[note103] \W\$ '

after

PS1='[note103] \W$(__git_ps1 "->%s")\$ '

閑話休題。

しかし、実際に設置してみたものの、なぜか肝心のブランチ名の補完がきかない。
慣れない作業なので、設定方法を間違っているのかとしばらく調べたがわからず、検索しなおしたら以下の記事にぶつかって、

blog.basyura.org

一部引用すると、

alias g='git' と定義していて常に g と打っているのだけど補完が効かなかったので git-completion.bash をいじったら動いた (正しいのかは知らない)。

  __git_complete git __git_main
+ __git_complete g __git_main
  __git_complete gitk __gitk_main

とのこと。なるほど……エイリアスを設定していると動かないってことか？

たしかにぼくは git checkout のエイリアスを gco にしていて、gco と打った後にそのブランチ名が入らないなあ、と思っていたので、たぶん上に引用した箇所で、__git_main と同等の、git checkout にあたる変数を見つけて同様に記載すればいいのではないか、と思ってファイル内を検索してみたら、それっぽいのがあったのでこのようにしてみたところ、

  __git_complete git __git_main
  __git_complete gitk __gitk_main
+ __git_complete gco _git_checkout

補完されるようになった。

これで一気に労力が軽減され、本質的ではない入力作業にかける時間を人生から削減できた。便利だし、ありがたい。

毎度のことだけれど、こうした知見をネットに書き残してくれている先人に感謝。

gitの長いブランチ名とかいちいち打つのつらい・・みんなどうやってるんだろう、とつぶやく前に調べたらすぐ見つかった＆設定したら便利。Twitter効果。エイリアスを反映させるのに少し時間かかったので時間できたらブログにメモしておきたい

— Hiroaki Kadomatsu (@note103) 2016年12月2日

大抵のことはとりあえず呟いてみればなんとかなるものだが、今回は呟く前に解決し、解決してから呟いた。

最近買った技術書: CとC++

長らく続いたプロジェクトがひと段落し、先週末にようやく髪を切りに行った。

前回行ったのはまだ暑い7月か8月で、さすがにどうかという状況だったが、幸いというか何というか、とくに人と会う仕事でもなかったのでずっと放っておいたのだった。

その帰り、いつも髪を切った後に寄る三省堂で気晴らしの雑誌類と一緒に買ったのが以下の2冊。

新・明解C言語 ポインタ完全攻略

スラスラわかるC++ (Beginner’s Best Guide to Programmin)

前者はC言語の入門書等で有名な柴田望洋さんのけっこう最近出た本の模様。
（と言いながら奥付を見てみたら今年の8月だった。超最近）

この日はとくにC言語の本をほしいと思っていたわけではなかったのだけど、ちょうどここ数ヶ月、時間のあるときは以下を読んでいて、

秘伝C言語問答 ポインタ編 (柴田望洋プログラミングシリーズ)

なかなか集中できないものの、内容は面白い、わかりやすいなあ、と思っていたので、それのアップデート版的なものとして、説明や理解を補完するものとして買ってみた。

後者のC++本は、以前に読んだ以下の記事で名前が出ていたもので、

ascii.jp

こちらの著者の矢沢久雄さんも本当に読者のことを想像したわかりやすい文章を書く人で、その人の書く入門書なら読んでみたい、という感じで買ってみた。

これまたべつにC++に特段の興味があったわけではないのだけど、上記の望洋さんの本でもけっこうCとの比較でC++が出てきたりするので、何となくいい機会かと思ったのと、あと単純に今後何かプログラミングをするような場合に、現実的にCよりもC++に触れる機会の方が多いのではないか、だったら少しでも知っておいた方がいいのではないか、みたいに思ったというのもある。

ちなみに、じつは同書については以前電子版でサンプルを読んだことがあったのだけど、リフローではない固定型だったり、サンプル部分が短く感じられたりして内容以前にフォーマットの問題として読みづらいな・・と諦めたことがあったので、今回紙版であらためてトライ、というのもあった。

で、逆にというか同じスラスラわかるシリーズでもC言語を扱った以下の本があって、

スラスラわかるC言語 (Beginner’s Best Guide to Programmin)

これは以前に電子版を購入して通して読んだのだけど、感想はこんな感じ。

翔泳社の「スラスラわかるC言語」サンプル読んで面白かったのでKindle本買ったが面白かった＆2〜3日で一旦最後まで読めた。共用体、連結リスト、mallocなどは扱っていないけど構造体までは説明されているしいわゆる基礎編としてとてもわかりやすかった

— Hiroaki Kadomatsu (@note103) 2016年7月1日

やはりよく出来た入門書は新しい概念や用語を文中で使うときにその説明をセットで行う、ということを徹底しているなあとあらためて思った。当たり前のようだけどたまにこういう良書に触れて「珍しい」と感じるということは難しいことなのだろうと感じる

— Hiroaki Kadomatsu (@note103) 2016年7月1日

なんというか、絶賛。
いや本当に面白かったし、わかりやすかった。

こっちの方は電子版もちゃんと（というか）リフローだし、結構ことごとく読みやすく作られているように感じた。

まだ上記のC++の方は初めの方を読んだだけだけど、同じシリーズだからかキャラクターやイラストやフォーマットは同じようでいて、じつは各キャラクターのキャラクターというか性格というか、セリフの雰囲気などは著者ごとに違っているようで、たとえば岡嶋さんの本における各キャラクターは毒舌系というか、やけにハイコンテクストで時にハイコンテクストすぎないか、いや自虐的すぎないか、といったことが気にならなくもなかったけれど、それも含めて非常にオリジナリティにあふれた面白さがあった。

この岡嶋さんの本についてはすでにこのブログでも紹介したと思っていたけど、検索したら無かったのでついでのようだけど触れておいた。

bcコマンドで電卓計算（小数の）

ちょっとした数字の計算をしたい、けど電卓出すのは面倒……ということがよくある。

ぼくはちょっと前まで簿記の勉強をやっていたので、マイ電卓がすぐ手の届くところにあるのだけど（一番体に近い引き出しの中）、そこから出すのすら面倒、と感じてしまうことが多々ある。

その一方で、両手はつねにパソコンのキーボードに置かれているので、ターミナルにパパッと打ち込んで計算が済むならそれがいい。

ということで、今まではそういうとき、ターミナルでirbとかPythonとか、最近だとPerl6を立ち上げたりしていたのだけど、たまたま何かの作業中に間違えて bc と打ったらコマンドが起動して、そのままちょっと動かしてみたら電卓だった。

なにこれ便利。

なのだが、どうも小数点の計算ができない。
具体的には「5 / 2 = 2.5」とか。

どっちかを小数にすればいいのか？　と思うも……

そういうことでもないらしい……惜しい。

しかしながら、経験的にたぶん、こういうのはちょっとしたワザを使えば案外普通にできるはず。
と思ってあちこち検索してみたところ、結論的には scale というのでケタ数を指定すればいいようだった。

整数値がゼロの場合は画面に出てこない（小数点から始まってしまう）が、まあよし。

なぜかこの、scale で指定すればいい。というだけのことがなかなか上記の検索でうまくヒットしなかったのでブログにメモしておいた。

ちなみに、その検索過程で echo からパイプでつなげてやる方法も知ったが、

$ echo "scale=1; 5 / 2" | bc
2.5

上記のぼくの用途だと単に bc と打つだけの対話型のほうがラクだと感じる。

Perlにおける日本語文字化け対策の私的まとめ

Perlで日本語のテキストを処理しているとけっこうな割合で文字化けにハマる。
近いことについては以前ここでみっちり書いたが、
note103.hateblo.jp
どうもその後、自分はbinmode関数やopen関数、およびutf8やopenプラグマについて理解が怪しいな、と思ったのでいろいろ調べつつ現時点での認識をまとめてみる。

環境づくり

まずはサンプルケース的に、文字化けしがちな状況を作る。

素材データとして、以下の内容をエンコーディングUTF-8のテキストファイルにsource.txtという名前で保存。

りんご
hello
犬
1234
ネコ

次に、そのデータをopen関数で読み込み、split関数で切り刻んで標準出力および書き込み用ファイルresult.txtへ書き込むPerlスクリプト「openio_stdout.pl」を書く。

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

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

use utf8;
use open IO => qw/:encoding(UTF-8)/;
binmode STDOUT, ':encoding(UTF-8)';

# 1. 素材データ読み込み
my $in = 'source.txt';
open my $fh, '<', $in or die $!;
    my @data = <$fh>;
close $fh;

# 2. いろいろ処理
my @out;
for (@data) {
    my @split = split//, $_;
    for my $s (@split) {
        push @out, "字$s";
    }
}

# 3. 処理済みデータを書き込み
my $out = 'result.txt';
open $fh, '>', $out or die $!;
    print $fh @out;
close $fh;

# 4. 標準出力に出力
print @out;

実行。

字り字ん字ご字
字h字e字l字l字o字
字犬字
字1字2字3字4字
字ネ字コ字

素材テキストの1文字ずつの間に「字」を入れてみた。
これが書き込み先のresult.txtにも、標準出力（ターミナル）にも出ている、という状況。

つまり、この時点では文字化けしていない。が、それは冒頭にある以下の宣言がちゃんと動いているからで、

use utf8;
use open IO => ':encoding(UTF-8)';
binmode STDOUT, ':encoding(UTF-8)';

これを誤るとけっこう盛大に文字化けする。
以下、それを順に見ていく。

utf8プラグマ

まず、今回の例ではソースコード内に日本語の文字（「字」）を入れているので*1、最初のutf8プラグマが必要になる。

use utf8;

もしこれをコメントアウト等で無効にすると……

こんな感じになる。
標準出力でも、書き出しファイルでもこうなる。

utf8プラグマというのは、この例における「字」のように、ソースコード内に素材となる文字を直接書いたとき、それをPerlで処理するための「内部文字列」に変換してくれるもの。

内部文字列に変換されなかったらどうなるかと言うと、Perlがそれを「なんか文字じゃないもの」ぐらいにしか扱ってくれず、上の画像のように化けてしまう。

ちなみに、この「内部文字列に変換されなかった何か」のことは外部文字列……とは呼ばず、「バイト列」と呼ぶことが多いらしい。

で、ここではそのコード内に直接書かれた「字」をutf8プラグマの宣言によって「内部文字列」に変換している。

openプラグマ

次に、このコードではファイル入出力（source.txtを読み込んでresult.txtに書き込む）をやっているので、2番めのopenプラグマも必要になる。

これは別解として、各open関数の第2引数でこのように書いても良いようで、

open my $fh, '<:encoding(UTF-8)', $in or die $!;
（略）
open $fh, '>:encoding(UTF-8)', $out or die $!;
（略）

それを冒頭のプラグマでまとめて宣言している。

また、このプラグマ部分はこのように分けて書くこともできるが、

use open IN => ':encoding(UTF-8)';
use open OUT => ':encoding(UTF-8)';

今回はIN/OUTの両方をやってるのでIOというレイヤーでまとめている。
と同時に、IOなら省略してもOKらしい。

use open ':encoding(UTF-8)';

で、さっきのutf8プラグマは元に戻して、このopenプラグマだけ無効にするとどうなるかと言うと、こうなる。

このうち、上側の

Wide character in print at /Users/kadomatsuhiroaki/open/openio_stdout.pl line 29.

というのは標準出力（ターミナル）に出るもので、書き出し先のファイルには出てこない。

その下の文字化け部分は、標準出力と書き出しファイルの両方に出ている。
不思議なことに、というか特徴的なこととして、一つ前の文字化けでは文字間に挟んだ「字」が化けていたのに対し、今度は「字」だけが普通に表示されている。

この段階ではutf8プラグマが生きていて、openプラグマを止めているのでそういう生死の違いが出るのだろう。

また、openプラグマの引数「:encoding(UTF-8)」は、「:utf8」と書いてもほぼ同等の働きをするようだが、前者はデータの入力時にそれが正しいutf-8かどうかをチェックするのに対し、後者はそうじゃないらしいので少なくとも入力時はあまり省略しないほうが良さそうである。

binmode関数

最後に、binmode関数。じつはこれが今まで一番わかっていなかったのだが、どうもいろいろな現象や解説書を並べて観察してみると、単に（というか）標準入出力時にその対象となるデータの文字コードを指定するもの、と考えれば良さそうである。

今回はデータをファイルから入力して、ファイル＆標準出力に出しているので、STDOUT時の文字コードのみをbinmodeで指定している。

binmode STDOUT, ':encoding(UTF-8)';

例のごとく、これだけコメントアウトしてみると……。

さっきと同じ。……かと思いきや、また微妙に違っていて、まず以下の対象行番号が29から33に変わっている。

Wide character in print at /Users/kadomatsuhiroaki/open/openio_stdout.pl line 33.

ではこの二つの行がソースコード上のどこにあたるかと言うと、以下の部分における、

# 3. 処理済みデータを書き込み
my $out = 'result.txt';
open $fh, '>', $out or die $!;
    print $fh @out;
close $fh;

# 4. 標準出力に出力
print @out;

前者のprint文が29行目で、最後のprint文が33行目。

つまり、openプラグマはopen関数内のprint文に効いていて、binmode関数の方は標準出力時に影響していることがこれらの情報から見てとれる。

また、肝心の本文のほうも、前者は文字化けしているが後者はしていない。
ただしこれは、ここで問題にしているbinmode関数の有無による違いではなく、ひとつ前の例でopenプラグマをコメントアウトした際、入力レイヤー（IN）も外してしまっているために、前者では文字化けが生じていると考えられる。

試しに、一つ前の文字化けはこのような状態で生じたが、

# use open IO => ':encoding(UTF-8)';
binmode STDOUT, ':encoding(UTF-8)';

このように、その状態からopenプラグマの入力レイヤーだけを復活させると、

use open IN => ':encoding(UTF-8)';
binmode STDOUT, ':encoding(UTF-8)';

文字化けは解消する。
（と言いつつ、たしかに文字化けは消えるが今度はbinmode関数のみを無効にした場合とは少し異なるエラーが出てくる。つまり、それらはどれも異なる状態なのだが、これ以上の追求＆説明はだいぶ大変なので割愛）

標準入出力もopenプラグマにまとめる

今回の研究というか勉強に際しては、以下3冊を繰り返し見比べては突き合わせ、読み返したが、

初めてのPerl 第6版

かんたん Perl (プログラミングの教科書)

Perl CPANモジュールガイド

そのうちのCPANモジュールガイドで紹介されていた方法。

現在はこのようにしている2行を、

use open IO => ':encoding(UTF-8)';
binmode STDOUT, ':encoding(UTF-8)';

以下のようにまとめられる。

use open IO => qw/:encoding(UTF-8) :std/;

ようはbinmode関数で指定していたことをopenプラグマの引数に「:std」とすることで代替（というか）できる。

いま自分で書いているコードにおいては、同様のことをしたいときは基本最後の形にしている。

まとめ

日本語の文字化けについては常に悩まされるところだが、原因を追っていくとそれなりに明らかになってくるのが面白い。

エラーの内容も書き換えた部分によって変わってくるし、同じエラー・メッセージでもその分量（行数というか）が異なり、それがまたマシンの気まぐれなどではなく、異なるには異なるだけの理由がある。

面倒だ、ぐぬぬ、イライラする！　と思うことも少なくはないが、それでも玉ねぎの薄皮を剥がすように少しずつマシになってきていると感じる。
そのような理解を助けてくれる上述の書籍、および知見に満ちた先達やネット上の各種解説記事に感謝します。

付録

今回の出力例の画像（黄色っぽいベージュっぽいやつ）について、本来ターミナルに出るような結果なのに行番号が出ているのはなぜだろう？　と思われる人もいるかもしれないが、これはコードの実行結果をVimの同一ウィンドウ＆分割バッファで表示してくれるプラグイン「quickrun.vim」を使って表示している。
github.com

ここでやっているような利用法については以下の記事でも触れたので合わせて挙げておく。
note103.hateblo.jp

*1:サンプルの文字選択を誤ったかもしれない。まぎらわしい。

Perlのオブジェクト指向をつかんだ

経緯

2013年の春にふと「よし、プログラミングやろう」と決めてその夏にYAPC::Asiaに参加して、その直後に買ったのが以下の本。

すぐわかる オブジェクト指向 Perl

たしか同YAPCでDeNAの人が大規模新人研修に関する発表をしていて（→）、その最後のほうでお勧め入門書ベスト5みたいなやつを紹介していたのだけど、それがよくある特定の選者が一括で選ぶようなものではなく、研修を受けた側の新人さんたちに聞いたアンケートから抽出されたというリアルなもので、そこに含まれているのを見て興味を持った。

で、先日ようやくそれを読み終わって出た感想。

Perl5によるオブジェクト指向、ようやく基礎をつかんだ感。長かった・・深沢千尋さんの「すぐわかるオブジェクト指向Perl」買ったのが触れた最初だと思うけど調べたら2013年9月に買ってたので興味持ってから把握するまで3年前かかってる

— Hiroaki Kadomatsu (@note103) September 15, 2016

かるくタイポしてるが、

s/年前/年/

実感的にはほんとに「ようやくつかんだ〜」という感じだった。

オブジェクト指向というと、よく「理解は容易だが運用は難しい」という、なんだかスクラム実践入門みたいなことを言われるわけだが、ぼくはその前者の「理解」の段階だけで3年かかってしまった。

まあ、3年ずっとべったり学習し続けてその間わからなかった、ということでもないのだが（読んでない時間の方が多い）、ともあれ、たしかにわかってみると（あるいはそのような気になってみると）「理解は容易」と言われるのもわかる気はする。シンプルといえば大変シンプルなものである。

またオブジェクト指向といえば、「データと処理をセットで扱うものである」なんていうこともよく言われる。これもとくに理解してない段階で聞くと「はあ、そんなものですか」という感じだが（日本語としては理解できる、というか）、今になって思えば、その辺に関する「わかる／わからない」を分けるのは、概念を聞いて理解できるかどうかということではなく、具体的なコードをどれだけ見たか、書いたか、実行したかによって変わってくるように思える。
つまり、パッと聞いてわかるとかそういうものではなさそう。（あくまで入門者に関して言えることだが）

ひと口にオブジェクト指向と言っても、JavaとRubyとPerlのそれぞれでは、元になる概念に共通する面はあっても、やはりコード上ではそれなりに違いがあるだろう。
そこには、単に構文上の違いだけではなく、お作法というか慣習的な面で、「こうするのがヨイとされている」みたいな違いもあるはずで、だから結局は自分が普段よく使う言語を通してそれを学ぶのが、一番の理解の近道になるのではないかとも感じる。

冒頭の本の話に戻ると、これはけっこうなページ数と文章量があるうえ、大判のせいかやけに重たいので（質量が）、最後まで読むのはけっこう骨が折れた。
ちょっと時間ができたからといって、棚からそれを出すのも大変だし、開いて読むにもちょっとしたスペースが必要だしで、気持ちの面である程度余裕がないと「さあ、読もう」という感じになれない。

もしこれが多少なり素地のある人なら、自分のわからない／知らない部分だけを補う用途で日常的に付き合えるかもしれないが、ぼくの場合はそれこそある程度べったり読み込まないと解読できない内容だったので、その「腰を落ち着けて取り組む機会」をなかなか作れず挫折していた、というのもある。

ちなみに、同書の紹介としては小飼弾さんの以下が大変参考になって、コメント欄では著者の深澤さんもいろいろ述べておられて面白いのだけど、

404 Blog Not Found:$this->get if $you->learn(slow) - 書評 - すぐわかるオブジェクト指向Perl

そこでも言われているように、ほんとに「じっくり、ゆっくり、時間をかけて」という感じで読み継いだ。

じつは同書の前半には、非オブジェクト指向ネタというか、リファレンスに関する説明がみっちり載っていて、購入してから1〜2年ほどは、どちらかというとそのリファレンスまわりの理解を深めるために読むことが多かった。

というか、もちろん最大の目的はその時点でもオブジェクト指向だったので、そっちも読もうとはするのだけど、やはりその辺ってそこまでの前半部分を読んでいる前提で解説されているので、後半だけ読んでもまったく頭に入らず、それで前半に戻ってリファレンスのところなどを一生懸命読み返す、というのがしばらく続いた。

ちなみに、そのリファレンスまわりの解説について言えば、本書ほど丁寧にPerlのリファレンスについて教えてくれる入門書はない（おそらく今後も）だろうと思っている。
もし今つまづいている人がいたらお勧めしたい。

さて、とはいえそんな調子でのったらのったら読んでいるので、後半のオブジェクト指向にはいつまでも入れず、また普段からあまり余裕がなくて本自体にもなかなか触れられず、触れられないうちに前に読んだところも忘れて、だからようやく読み返したときにはまた最初のほうから読み直して……とかやってるうちに「もうこれ、最後まで読み切ることはないかもなあ」という諦め気分だったのだけど、なぜか今年の夏に入ったあたりで、「やっぱり……次はオブジェクト指向だな」と思った。

というのも、オブジェクト指向を多少なり理解していないことには、読めない他人のコードというのが多すぎると感じたのだ。
これは少し前にC言語の学習を始めたことや、シェルスクリプトやLinuxコマンドを学びはじめたことにも近い理由であって、言い換えれば「みんなこの言葉を喋っているので自分も学ばないと彼らが何言ってるのかいつまでもわからないぞ」という焦りの気分でもある。

ということで、じゃあどこから再入門するかと思ったとき、半ば挫折しかけてはいるとはいえ、とりあえず途中までは読んでいる同書に再度取り組みはじめたら、ある程度心が決まっていたせいか最後まで理解しつつ読み終えることができたという話。

概念

ということで、以下ではここまでに理解した内容を簡単にまとめてみたい。

まず、オブジェクト指向を一言でいえば、上でもちらっと書いたように「データ（属性・プロパティ）と処理（振る舞い・メソッド）をくっつけたオブジェクトなるものを使っていろいろやる」ということになる。
この概念が、この話の一番の軸・前提になる。

また、Perlを使ったオブジェクト指向においては、おもに前者のデータをリファレンスで、後者の処理をサブルーチンで表す。
で、作ったそれらをbless関数でくっつけるとオブジェクトができる。

ここで出来たオブジェクトというのは、鋳型（いがた）のようなもので、鯛焼きやタコ焼きで使うような、型のある鉄板みたいなもの。
と同時に、プログラムの中で実際にあれこれやるのはその型じたいではなく、型をもとに作られた鯛焼きなりタコ焼きなりの1個1個。

で、前者の鋳型みたいなものをクラスと言い、その鋳型から出てきた後者の1個1個の具体的な実体をインスタンスと言う。

そしてその1個1個に対して何かを入れたり、そこから何かを引き出したり、それに何かをやらせたりしていく中でいろいろやるのがオブジェクト指向プログラミング。（雑になってきた）

実例

では概念的な話はそのぐらいにして、以下ではPerlによるそれを実例で紹介してみる。
むちゃくちゃベタだけど、動物ネタで。

こんな感じの構成を考える。

Animal
    ├─ lib
    │    ├─ Animal.pm
    │    └─ Animal
    │           ├─ Dog.pm
    │           └─ Cat.pm
    └─ main.pl

これはざっくり言うと、Animalという型が元にあって、それを継承したDog, Catという子クラスを配置したモデル。

いまあっさり「子クラス」と書いたが、そのときAnimal.pmの方は「親クラス」ということになる。

が、それは説明が簡単なのでそのように言っているものの、実際にはAnimalとDog/Catの関係は「親／子」とか「主／従」のような上下関係というより、「抽象／具体」という対照的な（お互いに呼応した）関係だと考えたほうが腑に落ちる。
これは冒頭に挙げた深澤さんの本でそのように説明されていて、なるほどと思った。

では具体的なコード。

まずAnimal.pm。

package Animal;
use strict;
use warnings;

sub new {
    my $class = shift;

    my %self = @_;
    $self{name} //= 'No name';
    $self{age} //= 0;
    $self{sound} //= '(silence)';

    bless \%self, $class;
}

sub speak {
    my $self = shift;
    return $self->{ sound };
}

1;

newメソッドの中でプロパティ（属性）を設定している。この「プロパティ」というのは他にも「アトリビュート」とか「フィールド」とも呼ばれるようだが（後者はJava用語っぽい）ここではプロパティと呼んでおく。

speakというのはサブルーチンだが、オブジェクト指向の際にはメソッドと呼ぶらしい。

上のほうで「データと処理」と表現したが、先のプロパティがデータにあたり、このメソッドが処理にあたる。

次に、Animal.pmを継承したDog.pm。

package Animal::Dog;
use strict;
use warnings;
use parent 'Animal';

sub speak {
    my $class = shift;
    return 'Bow!';
}

sub move {
    my $class = shift;
    return 'Jump!';
}

1;

継承すると、親クラスのAnimalの方で定義しているメソッド（newやspeak）を子クラスでも使えるようになる。だからここではnewメソッドを作らない。

なるほど、これなら重複する内容を書かなくて済むわけで、継承などをしない手法に比べて大きなメリットだと感じる。

その上で、ここではメソッドのオーバーロード（上書き）というやつで、speakメソッドをAnimal.pmのそれからちょっと書き換える。
Animalのspeakメソッドではプロパティ内のsound要素を呼び出していたが、Dogの方ではそうせずに独自の 'Bow!' を返すことにする。

また、Animalの方にはなかったmoveメソッドも独自に追加した。

もう一個、Animal.pmを継承したCat.pmを作ってみる。

package Animal::Cat;
use strict;
use warnings;
use parent 'Animal';

sub new {
    my $class = shift;
    my %self = @_;
    $class->SUPER::new(%self, sound => 'Nyaa..');
}

1;

こちらではnewを少し書き換える。
Dog.pmの方ではspeakメソッドを直接変更したが、ここではnewの方からsoundの値を書き換えて鳴き声を変えてみる。

この書き換えはあまりいい例じゃない気もするが（有効性を感じられないというか）、まあ、子クラスから親クラスのメソッドを呼び出す例として面白いので。

最後に、それらを実行するmain.pl。

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

use strict;
use warnings;
use feature 'say';
use lib './lib';
use Animal;
use Animal::Dog;
use Animal::Cat;

my $animal = Animal->new(name => 'foo', age => 100);
say "Animal's name:\t".$animal->{ name };
say "Animal's age:\t".$animal->{ age };
say "Animal speaks:\t".$animal->speak;
say '---';
my $dog = Animal::Dog->new(name => 'Pochi', sound => 'Vow!');
say "Dog's name:\t".$dog->{ name };
say "Dog's age:\t".$dog->{ age };
say "Dog speaks:\t".$dog->speak;
say "Dog moves:\t".$dog->move;
say '---';
my $cat = Animal::Cat->new(name => 'Tama', age => 3);
say "Cat's name:\t".$cat->{ name };
say "Cat's age:\t".$cat->{ age };
say "Cat speaks:\t".$cat->speak;

結果。

Animal's name:	foo
Animal's age:	100
Animal speaks:	(silence)
---
Dog's name:	Pochi
Dog's age:	0
Dog speaks:	Bow!
Dog moves:	Jump!
---
Cat's name:	Tama
Cat's age:	3
Cat speaks:	Nyaa..

OK。

もう一個、オブジェクト指向では多重継承という手法がよく話題になるようで、ここではDogとCatの親クラスはAnimalのみだけど、複数の親からメソッドを継承したい場合にはどうするか、という話。

たとえば、「動物の中の何か」であると同時に、「その物体は何色か」という要素を規定するクラスをDogやCatで共通して流用したい場合。

ひとつの方法として、現在Animalから諸メソッドを継承しているように、そういった別の親クラス（仮にColor.pmとする）を継承しても良いが、多重継承というのはいろいろ煩雑になる面があるらしく（雑な説明だが）、それを避けたい場合は普通にuseする。

まずColor.pmを作る。

package Color;
use strict;
use warnings;

sub color {
    my $self = shift;
    my $color = shift;
    if ($color) {
        return $color;
    } else {
        return 'brown';
    }
}

1;

引数を与えたらその色、与えなければ「brown」ということにした。
（たしか「続・初めてのPerl」でこんな例があった気がしたので借りた）

ここではこのColor.pmをAnimal.pmと同階層に置いておく。
こんな感じ。

Animal
    ├─ lib
    │    ├─ Animal.pm
    │    ├─ Color.pm # <= 追加
    │    └─ Animal
    │           ├─ Dog.pm
    │           └─ Cat.pm
    └─ main.pl

で、Animal.pmを少し書き換え。

package Animal;
use strict;
use warnings;

sub new {
    my $class = shift;

    my %self = @_;
    $self{name} //= 'No name';
    $self{age} //= 0;
    $self{sound} //= '(silence)';

    bless \%self, $class;
}

sub speak {
    my $self = shift;
    return $self->{ sound };
}

# colorメソッドを追加。
sub color {
    my $self = shift;
    my $color = shift;
    return Color->color($color);
}

1;

このままDog, Catの方はとくに触らずに、main.plでColor.pmをuseして、それぞれのcolorを呼び出してみる。

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

use strict;
use warnings;
use feature 'say';
use lib './lib';
use Animal;
use Animal::Dog;
use Animal::Cat;
use Color; # <= 追加

my $animal = Animal->new(name => 'foo', age => 100);
say "Animal's name:\t".$animal->{ name };
say "Animal's age:\t".$animal->{ age };
say "Animal speaks:\t".$animal->speak;
say '---';
my $dog = Animal::Dog->new(name => 'Pochi', sound => 'Vow!');
say "Dog's name:\t".$dog->{ name };
say "Dog's age:\t".$dog->{ age };
say "Dog speaks:\t".$dog->speak;
say "Dog moves:\t".$dog->move;
say "Dog's color:\t".$dog->color; # <= 追加
say '---';
my $cat = Animal::Cat->new(name => 'Tama', age => 3);
say "Cat's name:\t".$cat->{ name };
say "Cat's age:\t".$cat->{ age };
say "Cat speaks:\t".$cat->speak;
say "Cat's color:\t".$cat->color('white'); # <= 追加

結果。

Animal's name:	foo
Animal's age:	100
Animal speaks:	(silence)
---
Dog's name:	Pochi
Dog's age:	0
Dog speaks:	Bow!
Dog moves:	Jump!
Dog's color:	brown
---
Cat's name:	Tama
Cat's age:	3
Cat speaks:	Nyaa..
Cat's color:	white

OK。Dog, Catの最後にカラーが追加された。

このように、「多重継承したいけどしたくないので別の方法でいい感じにいろんなクラスを取り込みたい」みたいな時のこういう方法をMix-inというらしい。
いや、厳密に定義すれば上のような方法をそうは言わないかもしれないが（よく知らない）、まあ理念というか目的としては似たようなものかと捉え中。

参考書籍

ちなみに、そのMix-inを含めてオブジェクト指向の基礎みたいなところについては、まつもとゆきひろさんの以下の本がとても参考になった。（まだ読み切れていないが入門者向けっぽいわりにすごい濃い）

まつもとゆきひろ　コードの世界

また、同書を紹介してくれたのはYAPC::AsiaやPerl入学式で時々会う人で、「あの本はオブジェクト指向の説明がすごくわかりやすかったな」と、たしか一昨年（2014年）のYAPC::Asiaで会の終了後に会場下のHUBで飲んでいるときに教えてもらったのでそのまま購入＆読んだという経緯がある。
その節はありがとうございました。＞その方

それから、上でもちらっと書いたとおりオブジェクト指向Perlの学習に際しては、冒頭の深澤さんの本の他、皆さんお馴染み『続・初めてのPerl』と、

続・初めてのPerl 改訂第2版

@kaz_hiramatsuさんによる『雅なPerl入門 第3版』が参考になった。
kazhiramatsu.hatenablog.com

どちらかと言うと、『すぐわかるオブジェクト指向Perl』と『雅なPerl入門』で全貌をつかみつつ、『続・初めてのPerl』で脇を固める、みたいな読み方だったか。

まとめ・展望

ということで、本当はこのまま今度は上記のコードをMouseというモジュールを使って書き換えた版も復習がてら書いておきたかったのだけど、だいぶ長くなったのでひとまずここまで。

実際には、これらを踏まえた上で同内容をMouseで書き換えたら「なるほど、まあこの方がいろいろラクかもしれない」と思ったりしたので、そこまでを自分の理解のひとまとまり、と捉えてはいるのだけど。

あと、上では触れなかったがアクセサ（ゲッター＆セッター）というやつに関する理解が薄いという自覚があり、かつたぶんカプセル化というやつを意識する上ではそれが重要だと思われるのだけど、その辺の理解度が低い段階で上のようなblessを使った方法でゴリゴリやっているといつまでもこの記事をUPできなそうなので、次にMouseの基礎的な使い方をまとめる際、あらためてその辺も勉強してみたい。

ひとまずのまとめとしては、やはりオブジェクト指向というのはどうもプログラマーの人たちにおける一種の共通言語のようになっている部分があるようで、その一部をカタコトながらも解読できつつあるのは喜ばしい。

同様に、サーバーまわりやSQL、あとちょっと外れたところで（というか）TeXなど*1、勉強したいことは山積みだが地道に触れていってみたい。

*1:自分の分野に近いので、というところもある

GOPATHの設定でハマって解決した話

「みんなのGo言語」が話題だから、というつもりでもなかったのだけど、やはり影響はあるかもしれない。

みんなのGo言語【現場で使える実践テクニック】

どうもGOPATHというやつの理解がぼんやりしていて、これまでも見よう見まねで設定してはいたのだけど、その足元のおぼつかなさゆえにいつ混乱に陥ってもおかしくないという不安がだいぶ募ってきたので整理と理解を試みた。

けっこう前にセットしてそのままだった.bash_profileを見てみると、こんな風になっていた。

export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin
export GOBIN=$GOPATH/bin

しかしどうもこの最後のGOBINというのは最近見かけない気がするので、いかにも理解してない感じがありそれが怖い。

ということで、とりあえず以前に買って少し読んでいた以下の本を見ながら最新版のGo1.7をMacにインストールし、

スターティングGo言語

そのまま同書の案内にしたがって.bash_profileを以下のように書き換えたのだけど、

export PATH=/usr/local/go/bin:$PATH
export GOPATH=$HOME/go

動かない。

具体的には、第一に毎日毎時間頻用しているmattnさんのchoが動かない。

GitHub - mattn/cho

ぼくは自作のコマンドラインツールでchoをデフォルト的に組み込んでいるので、

choっと作った便利なツール - the code to rock
最近のcarvo: pecoとchoをくっつけた - the code to rock

これにはさすがにゾッとした。ディレクトリ移動、ファイルオープン、不要ファイルの削除などあらゆる面で支障をきたす。

焦りつつ、何がどうなっているのかチェックしてみると、たとえば「$ go get 〜」というふうに外部のパッケージをインストールした際、それがGOPATHで指定した先に入っていくところまでは思惑通り動いているようなのだが、本来ならそれで次の瞬間から有効になるはずのコマンドが効かない。

どうもGOPATHとして設定した「$HOME/go/bin」のバイナリファイルがマシンに認識されていない、無視されている、屍のようだ、という雰囲気を感じる。のだけど、ではそれをどうしたらいいのか……というところで多分4〜5時間ぐらいハマり続けた。

で、結論的にはこれはPATHの設定が駄目で、以下のようにしたら解決した。

export GOPATH=$HOME/go
export PATH=$PATH:$GOPATH/bin

しかしこれ、よくよく見直すと最初の状態に戻っているだけである。

と同時に、なんとなく自分で当たりをつけた原因がそれほど外れていなかったこと、そしてこれまで数年にわたりどうにも理解しきれずにいた「PATHを通す」という言葉の意味の片鱗が、ようやく腑に落ちてきた気もする。

「PATHを通す」という表現をプログラミングの初心者にまともに解説してくれる人や記事にぼくはいまだに出会ったことがほぼないのだけれど*1、自分なりに言い換えれば、それは「最高権力者であるところのマシンが認める限定的な《コマンドファミリー》の一員に入れてやる」というようなことではないかと思い始めている。
（抽象的すぎて初心者にはむしろ不親切な説明だが）

言い換えると、あるコマンド候補生を正式なコマンド集団の一員に昇格させるためにやることは、そいつが今いる場所をその《ファミリー》が支配する新たな縄張りに加えるか、あるいはすでに縄張りになっている場所にそいつを入れるか、そのどちらかであり、通常言われる「PATHを通す」というのは基本的にその前者なのかなと。
（この説明もきわめて抽象的だが）

そのようなことを考えながら上記の失敗例を見直すと、GOPATHの設定とPATHの設定がバラバラで繋がっていない。
懲りずに上の喩えを用いるならば、こちらの意図としてはGOPATH/binの中身をすでに正式なコマンドの一員だと思いこみ周りにもそう吹聴しているのだけど、最高権力者であるところのマシンはそれをまだ《ファミリー》の一員だと認めていない。

これがもし、GOPATHの設定をしないのであればそのPATH設定でもいいかもしれないが、GOPATHを設定する前提ならそのPATH設定のままでは駄目ではないか、と前掲「スターティングGo言語」を何度か読み返しつつ心の中で呟いた。*2*3

ちなみに、PATH設定については以下のように先頭へ代入するよう説明している本や記事もあったが、

export PATH=$GOPATH/bin:$PATH

どうもこうして先頭に入れるというのは、それなりに意味というか必然性がないとちょっと抵抗があるように感じたので、

export PATH=$PATH:$GOPATH/bin

というふうに後に付けるようにしたがそれでとくに問題なさそうである。

というか、こちらのWeb+DBプレスGo特集にもそのように記述されているので大丈夫だろう。

WEB+DB PRESS Vol.82

というか、このGo特集はその4〜5時間ハマってる間にも何度も目を通していたのだけど、解決した後にあらためて見直したら上記と同じPATH/GOPATH設定の正解がちゃんと載っていて、やっぱり人間、焦ると見落とすな〜とつくづく身に沁みた。

ということで、実りがあるのかどうかよくわからない内容になったが、後になってまた同じようなことで普通にハマりそうなので、そのときの自分のために書いておいた。

追記

「みんGo」のKindle版が出ていたのでサンプルを読んでみたら、第1章の途中まで載っていて好印象*4……と思っていたら上記のGOPATH/GOROOTについても丁寧に触れられており、かつ上記設定で問題なさそうなことを確認できたのでよかった。

みんなのGo言語[現場で使える実践テクニック]

*1:以前に以下で紹介した「新しいLinuxの教科書」はかなりイイ線行っているが。 http://note103.hateblo.jp/entry/2015/12/17/083000

*2:もしかしたら書中ではきちんと説明されていて、ぼくがそれを見落としているだけかもしれないが。

*3:ちなみに同書じたいはそれこそ初心者向けの丁寧で良いつくりの本だと感じている。

*4:こういったサンプルで前書き＆目次までしか載せてないような本も時々あって、売上戦略としては正しいとも感じるが（高額でなければ「本文の方にほしい情報が載っているかもしれない」と考えて焦って買う可能性もあるので）印象は良くない。