読者です 読者をやめる 読者になる 読者になる

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

git

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

  • 公式サイト

www.perl-entrance.org

GitHub - perl-entrance-org/workshop-2016

  • 作業風景


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

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

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

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

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

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

.bashrc

source ~/.git-completion.bash

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

source ~/.git-prompt.sh
before
PS1='[note103] \W\$ '

f:id:note103:20161204130157p:plain

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

f:id:note103:20161204130207p:plain

閑話休題

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

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

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

f:id:note103:20161204000808g:plain

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

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

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

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

clang book

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

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

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

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

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

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

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

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

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

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

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

ascii.jp

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

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

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

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

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

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

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


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

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

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

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

bcコマンドで電卓計算(小数の)

tips shellscript

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

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

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

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

f:id:note103:20161019025613g:plain

なにこれ便利。

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

f:id:note103:20161019025633g:plain

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

f:id:note103:20161019030316g:plain

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

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

f:id:note103:20161019025651g:plain

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

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

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

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

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

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

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;

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

f:id:note103:20160925140246p:plain

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

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プラグマだけ無効にするとどうなるかと言うと、こうなる。

f:id:note103:20160925140639p:plain

このうち、上側の

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)';

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

f:id:note103:20160925140820p:plain

さっきと同じ。……かと思いきや、また微妙に違っていて、まず以下の対象行番号が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 第6版

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

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

Perl CPANモジュールガイド

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のオブジェクト指向をつかんだ

perl oop

経緯

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

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

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

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

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


かるくタイポしてるが、

s/年前/年/

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

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

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

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

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

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

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

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

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版

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

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

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

まとめ・展望

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

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

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

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

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

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

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

golang

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

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

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

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

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

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

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

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

スターティングGo言語

スターティング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

WEB+DB PRESS Vol.82

  • 作者: 山口徹,Jxck,佐々木大輔,横路隆,加来純一,山本伶,大平武志,米川健一,坂本登史文,若原祥正,和久田龍,平栗遵宜,伊藤直也,佐藤太一,高橋俊幸,海野弘成,五嶋壮晃,佐藤歩,吉村総一郎,橋本翔,舘野祐一,中島聡,渡邊恵太,はまちや2,竹原,河合宜文,WEB+DB PRESS編集部
  • 出版社/メーカー: 技術評論社
  • 発売日: 2014/08/23
  • メディア: 大型本
  • この商品を含むブログ (1件) を見る

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

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

追記

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

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

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

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

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

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

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

Vimと日本語編集(2): 修正前後の原稿の差分を一瞬でチェックする

Vimと日本語編集シリーズ第2回。
前回はこちら。
note103.hateblo.jp

けっこうニッチな内容だったと思うが、今回はもう少し使用頻度&汎用性が高いかもしれない。

前提・状況設定

複数人で利用・共有するドキュメントがあるとして、それをまず自分が書いたとしよう。

大体内容がまとまったのでデータを他のメンバーに渡し、「気になるところがあったら適当に手を入れといて」なんて言っておいたら、しばらくして修正版が届いたとしよう。

でもパッと見たところ、どこが修正されたのかわからない。

たとえば、これが修正前。*1

f:id:note103:20160907004614p:plain

そして修正後。

f:id:note103:20160907004624p:plain

そのようなときに、どうするか。

よくある解決策・その何が問題か

一番容易な選択肢としては、「じっくり見る」。
まあ、数百字程度ならありかもしれない。
とはいえ、人間に向いた作業かは微妙。避けられるなら、あまりやりたくない。

次に容易な選択肢としては、「どこ直したの?」と相手に聞く。
でも面倒くさい。すぐに返答があるとは限らないし、本人だからといって正確な差分を示せる保証もない。(だから最初の選択肢が「とりあえずじっくり見る」になってしまう)

これがエンジニア同士なら、最初からそのドキュメントはGit管理されていて、すべての差分を簡単にチェックできるようになっているかもしれない。
さらにそれがGitHubやBitbucketで共有されているなら、その視認性はさらに高まるだろう。

しかし仮に自分がエンジニアだったとしても、相手がGitを使えない人だったり、ドキュメントの性質としてGit管理の必要がないテンポラリなものだから、といった理由で差分管理が成されていなかったらどうだろう?

僕は普段の作業でGitを使っているけど、それでも既存のリポジトリには入っていない、突発的で一時的なちょっとしたドキュメントの差分を見たい、という状況にちょくちょく陥る。
そのようなとき、そのちょっとした差分を見るためだけにわざわざリポジトリを作るとか、GitHubなどにpushするというのも面倒である。

解決策

というわけで、やっているのは次のこと。

1. 白紙のバッファに差分を見たいドキュメントの「修正前」の文章をコピペ。

2. 新規で無名の分割バッファを出して、「修正後」の文章をコピペ。
この際、新規バッファを水平分割で出すなら

:new

タテ分割なら

:vnew

とすればよい。

3. おもむろに以下を打ち込む。

:windo diffthis

差分が出る。

f:id:note103:20160906231653p:plain

左が修正前。右が修正後。
変更が生じた行だけでなく、文字単位で出てくるのがよい。

差分表示を消すには以下。

:windo diffoff

上記についてはすべてVimcastsのこちらから学んだ。
Comparing buffers with vimdiff

目的の内容以外にも、その過程で次々と小ネタが繰り出されるので目が離せない。すごいコンテンツ力……。

なお、上記のexコマンドを毎回打つのは面倒なので、このようなマッピングを入れている。

nnoremap <silent> <Leader>dt :<C-u>windo diffthis<CR>
nnoremap <silent> <Leader>do :<C-u>windo diffoff<CR>

上では二つのバッファをどちらも無名ファイルにしたが、無名である必要はとくにない。
既存のファイルを二つ並べるのでも、片方だけ無名にするのでもよい。(上述のVimcastsでは片方だけ無名だった)

別解

fugitive.vim / Gdiff

もしリポジトリ管理しているファイルで同様のことをやるなら、fugitive.vimの「:Gdiff」も便利だと思う。
GitHub - tpope/vim-fugitive: fugitive.vim: a Git wrapper so awesome, it should be illegal

というか、上で紹介した方法を知るまではずっとこれでやってた。

fugitive.vimの使い方に関しては、以下の記事がとてもわかりやすい。
blog.yuku-t.com
cohama.hateblo.jp

diffsplit, VDSplit

また、今回の記事を書くためにいろいろ確認するうちにたまたま辿りついたのだけど、以下で紹介されている「:diffsplit」や「:VDSplit」でも同様のことをできるみたい。(後者はKaoriya版限定)
nanasi.jp

用途によってどれがより適している、といったこともありそうだが、そこまでは把握できていない。

まとめ

GitHubなどで色付きの、人に優しいdiffを見慣れていると、差分を知らされず変更後のドキュメントだけを渡されたときにある種の禁断症状に陥ってしまいそうな気になる。

差分を目視で確認するのも、口頭で教えてもらうのも、メールやチャットのテキストで説明を聞くのも、すべて「異様に長い箸で数メートル先の豆をつまむ」ようなもどかしさを感じる。

パパッとコマンドを打って、どの行のどの文字が変更されたのか。そして(もしかしたら変更箇所以上に)「どこが変更されていないのか」といったことがわかると、こみ上げかかったストレスが急速に収まってよい。