hkoba blog

プログラマーです。プログラミング言語ミーハーです。ツッコミ歓迎です。よろしくどうぞ(能代口調)

再帰globパターン **/ の元祖は zsh なのか、調べてみた

zsh

今日 @satoh_fumiyasu さんのこんなツイートを見かけました。

私もずっと気になっていたので、この機会に調べてみました。

最初は ..../ だった！

当時のソース公開は usenet 経由だったよな、というわけで groups.google.com で zsh を検索すると、Zsh-1.0 の公開時のアナウンス と、 ソース が出てきました。

アナウンスの中では zsh の機能の由来を From ksh, From tcsh, From bash と細かく挙げているのですが、 再帰globパターンは『その他』として別扱いされています。

Other stuff:

        - recursive directory search in filename generation (for example,
          "ls ..../*.c" lists all .c files in the hierarchy)

これによると Zsh-1.0 では、 **/ のような再帰 glob を ..../ と書いていたのですね。 この書き方は翌年リリースされた Zsh-2.00 でも変わらないようです。

Zsh-2.1 で ****/ に変わった

Zsh-2.1 の README の Modification history に、初めて ****/ の言及が出てきます。

Modification history:
0.03-1.0:
        - "..../" is now "****/".  I know this isn't backward compatible,
          but I had no choice; the string "..../" was unquotable.

0.03-1.0 とありますが、恐らく 2.03 から 2.1 のことを指しているのでしょう。

Zsh-2.2 で **/ になった

そしてついに Zsh-2.2 の Modification history に、 **/ が出現します。

Modification history:

2.2.0-2.1.0:

o ls **/file is now equivalent to ls ****/file

時に、1992/05/14。 ここまでの経緯を見るに、zsh が元祖ではないか？と私には見えました。

なぜ ..../ や ****/ だったのか？

ところでなぜ最初、再帰glob は ..../ という長い書き方だったのでしょう？ それは、どうやら、 実装に理由があったようです。

そもそも zsh の **/ は、０個以上へのマッチ文字 # (正規表現のクリーネスターに相当)を使った書き方 (*/)# の省略形です。 (マニュアルを参照)

で、なんと、Zsh-1.0 のソースを読むと、 ..../ を直接 (*/)# へと置き換える^^、という実装になっていたのです。

gist.github.com

要するに、５文字で、ファイル名として滅多に使わないものという制約の中で、打ちやすいものを選んだのでしょうね。

なぜ私は敢えて Zsh で Shell Script も書くのか、目的合理性はどこにあるのか

zsh

はじめに

UNIX, Linux のためのシェルスクリプトを bash どころか敢えて zsh で書くことに、どんな目的合理性があるのか… 個人的な考えをまとめてみます。 #!/bin/zsh の勧めにしたかったけど、途中で力尽きました。

勿論、 万人向けではない話 なので、なるべく背景・仕事環境・与えられた状況についても言及していくつもりです。

ツッコミも歓迎です。

前提

  1. 人生は短い。 限られた時間で、目的を達成したい。 『成果出力 / 学習含めた開発時間』の比を、納得行くレベルに保ちたい。
  2. sh 族の各々には力の差が有る。 プログラミング言語としての表現力の優劣や、処理系の完成度の優劣が存在する。
  3. チームの root と教育を任されている。 自分が個人としてベストな仕事をするだけでなく、メンバーの学習まで含めて判断したい。
  4. 道具は使い分ける。 sh 族で書くメリットのある、向いたタスクだけを sh族で書き、複雑な部分は他の言語で解く。

1. Pure な sh 縛りで書くことのコストに耐えうるか

記憶では…20年以上前、私が研究室にいた頃に、SONY NEWS と Sun だったか…でどちらでも動く /bin/sh スクリプトを書こうとして、 test コマンドの、あるオプションの有無 で泣いたことが、有ったように思います。今ならベンダー間の互換性テストが十分進化して、 こんな事態は起こらないのかもしれませんが…私が Pure な sh 縛りの美辞麗句に疑問を抱くには十分すぎる出来事でした。 条件検査のような、動作の要すら外部コマンドに頼ると、ベンダー間の移植性を確保するために必要な努力は、生半可でなく膨らむのだと気付いたのです。

当時の zsh は既に ksh 流の組み込みテスト [[ を実装していました。(手元の 1993 頃の zsh2.3.1 のマニュアルで確認)。 これを使えば、移植性の問題は zsh 自体の移植の問題に帰着できます。Port zsh or die! (←いえ、移植に貢献できたことは無いですが…)

なお bash も release note を見ると、 組み込みテスト [[ が入るのは bash-2.02 っぽいですね。 ftp サイトのタイムスタンプ を見ると、 1998-04-18 リリース？なのでしょうか。

(linux の各 distros vendor がいつ↑これを採用したのか、いつか調べてみたいものです)

2. bash/ksh/zsh… 各々の強みを殺して使うコストを払う余裕が有るか

bash/ksh/zsh は互いに切磋琢磨し、機能を向上させてきました。 複数の sh で同じ書き方で使える機能も有れば、そうでないものもあります。 従って、もし複数の sh で互換なコードを書くならば、絶対に使えない機能が出てきます。

一つの具体例を挙げます。

zsh と bash/ksh との違いの中で、私が最も zsh らしさを感じる点の一つが、 sh_wordsplit のオプション化です。

シェルスクリプトで初心者泣かせは沢山ありますが、最初に注意されることの一つは、 $変数 を "double-quote" で 囲むことでしょう。変数にスペースやタブが入ったら誤動作するからです。

$ foo="Program Files"
$ ls -dl $foo
ls: cannot access Program: No such file or directory
ls: cannot access Files: No such file or directory
$ ls -ld "$foo"
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 11:53 Program Files

こんな挙動になっている理由は、Pure な sh に配列変数が無かったことが原因でしょう。 配列がなかったから、複数の値を（一つの変数で）直接渡すことが出来ない。 だから代わりに、一つの文字列変数に空白などの区切り文字で繋げて渡し、受け手でそれを分解して使う… それしか実現手段が無かったからです。 この挙動は sh との互換性を優先する限り不可避です。 bash/ksh は今もそれに従っているはずです。

$ mkdir a b c d
$ foo="a b c d"
$ ls -ld $foo
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 a
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 b
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 c
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 d

対して zsh は、私が初めて触れた頃から既にこの挙動を オプション化して オフに していました。

% foo="Program Files"
% ls -ld $foo
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:30 Program Files

もし本当に複数要素を変数に入れるつもりなら、最初から配列変数にしておけば良いという考えでしょう。 (ここに限らず zsh の設計の節々には、 Pure な sh との互換性は程々にして利便性を優先する 、という、勇気ある選択が見て取れます。私はその勇気を賞賛したい)。

昔から、 zsh では代入の右辺を foo=() のように囲むことで、配列変数を作ることが出来ます。

% foo=(a b c d)
% ls -ld $foo
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 a
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 b
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 c
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 d

ちなみに配列の要素に空白が入っても大丈夫です。(唯一の残念な例外は、空文字列そのもの。私が知る限り…)

% foo=(
a b c d
""   ""
"Program Files"
)
% ls -ld $foo
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:30 Program Files
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 a
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 b
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 c
drwxrwxr-x. 2 hkoba hkoba 4096 Jan 31 12:39 d

重要なことは…このような 特定の sh 処理系の進化のメリットを受けたコードを書くためには、 他の処理系との互換性は捨てざるを得ないケースが有る 、ということです。

いつまで "$foo" って書けって叱り続けるの？

勿論、自分だけがシェルスクリプトを書くなら、 "$foo" と書けば良い、で済みます。 ですが、新人教育も自分の仕事だったら？

もっと言えば…教える相手が、自分と同じ方向での (root を期待されるような) unix プログラマーではなく、 他にもっと大事な仕事を抱えていて、片手間の自動化の道具を求めている人だったら？

明らかに、"$foo" の話は苦肉の策、回避策(work around) です。 そして解決策(配列変数を使え)も存在します。 それに新人さんを巻き込み続けることに、どの程度の合理性があるのか…

それよりも、自分が独裁者になって zsh と no_sh_wordsplit を押し付ける、 俺を信じて zsh で書け と言い切るほうが、お互いハッピーになれるのではないでしょうか…

Zsh で書くメリット

ここに記すには余白が狭すぎる(力尽きた)。

代わりに参考文献

英語が読めるならこちら

From Bash to Z Shell: Conquering the Command Line

日本語の本ならこちら

昔 fj に zsh のマニュアルの和訳を投稿していた方の本のはず。 変数展開フラグの解説など充実しているので、 zsh でスクリプトを書く人にも極めて有益な本です＞

www.amazon.co.jp

Zsh で書くデメリット

  • 明示的にインストールする必要がある
  • 教育を請け負う責任が発生する
  • ユーザ向けの UnitTest の枠組みが不足(良いの有ったら知りたいです)

後は…？

.oO(孤独を味わう…とかはあるかもしれませんね…)

謹賀新年/2016目標

あけましておめでとうございます

昨年交流させていただいた皆様、良くして下さり有難うございました。

また今年も、仲良く本音で楽しんで生きましょう。

昨年の反省点

  1. 引越し、ならず！荷物減らしも、イマイチ進まなかった。
  2. ライフワーク(オレオレ言語作り)にも、望んだほどは体力を充てられなかった。
  3. Twitter 読むのに時間を使い過ぎ？得られる情報も多いとは言え、なかなか難しい…

昨年の良かった点

  1. 生活
    • 食生活改善(肉を積極的にとるようにした)のお陰か、体が疲れにくくなった気がする。(2kg 太ったけれど、痩せ過ぎだったから良いよね？)。以前は一日働いた後は『燃え尽きた』ような脱力感があった。
  2. 仕事と OSS 活動
    1. YAPCAsia2015 のお手伝いが出来たこと
    2. 職場に Slack を有料版で導入してもらえたこと。細かいやり取りを記録に残せるようになったことで、業務のタコツボ化回避に極めて有効と分かった。(独り分報も始めてみた。こっちは todo の意識化程度)。正直、もう出社しなくても良いのでは…？
    3. 2015年の新人さん３人が、何とか職場に定着してくれたこと。本人も教育担当も、大変頑張って下さいました。ありがたや…
    4. お客様の社内で少しずつ YATT::Lite の導入事例を増やせていること。非プログラマのために作った YATT なので、それが目論見通りの成果を出すのを見るのは嬉しい。
    5. Perl で10年?以上かけて探求してきた use fields と import() を活かした、静的 typo 検出とコンパイル時コード生成を両立させたコーディングスタイルの、知見の集大成である MOP4Import::Declare を CPAN にリリース出来たこと。これで自作モジュール CPAN 化の最大の障壁が無くなった。
    6. (Fedora) Linux の Surface Pro3 の日本語キーボードカバー対応に、（ショボいパッチとは言え）貢献できたこと。
    7. 長年構想をあたためてきた、TclTk + sshcomm + tkhtml3 ベースの、業務特化ウェブサイトのための半自動設定 GUI、そのプロトタイプを一週間ででっち上げて実戦投入できたこと。大きな手応えを得られた。
  3. 英語
    • 未来塾で、自分の英語の音作りに関して、ほんの少し、進むべき道が見え始めたこと

今年の目標

  1. 追記 いいかげん棚卸しの習慣をつける。本のあふれ、食材の賞味期限切れに対策を。
  2. 引越し(移住？)を、現実の計画にする。Slack ベースで働ける体制が出来た以上、職場から遠くても良いので、家賃の低い所に移りたい。
  3. YATT::Lite (や perlminlint) の静的な typo 検出のメリットを、普通の人が簡単に受けられるように、 Web IDE とか作れないか…模索したい。
  4. TclTk + tkhtml3 という thin なプラットフォームの可能性を、もっと世の中の人に使いやすい形にまとめる。
  5. FSharp か OCaml の勉強をもう少し頑張って、実戦投入の道を探る。
  6. 自分の余暇時間を増やせるようなツール作りを模索する。(Twitter 関連かなぁ…)
  7. 彼女(嫁)探しを、諦めない…諦めない…(一体どこに行けば、オイラと共存可能なひとが見つかるのか…？)

SQLite でも列名を生成する時の quote には backtick (`) を使ったほうが良いぽい気がしてきた

sqlite perl

軽くハマったのでメモ。

まずは実験用のテーブル tab1 を作ります。(中身は空のままにします)

sqlite> create table tab1(foo, bar);
sqlite> select * from tab1;
sqlite> select * from tab1 where foo = 3;
sqlite>

次に、意図的に列名を打ち間違って入れてみましょう。 例えば fooo みたいに。

sqlite> select * from tab1 where fooo = 3;
Error: no such column: fooo
sqlite>

ちゃんとエラーになります。では、今度は(間違った列名を) double-quote で囲んで "fooo" のように変えてみましょう。これは SQL 標準に従った書き方です。ところが…

sqlite> select * from tab1 where "fooo" = 3;
sqlite>

なんと、 エラーにならない！

なぜこうなるかは SQLite の公式マニュアル SQLite Query Language: SQLite Keywords にあるように、

If a keyword in double quotes (ex: "key" or "glob") is used in a context where it cannot be resolved to an identifier but where a string literal is allowed, then the token is understood to be a string literal instead of an identifier.

"..." の指す列が存在しないなら、代わりに 文字列として解釈し直して しまうから。…超、迷惑…

このように、SQLite において、列名を double-quote で囲むと 列名の誤りがエラーにならないため、問題に気づくのが遅くなるのでよろしくないのでは？という話です。

むしろ mysql 風の backtick (`) で囲ったほうが (SQL標準から外れても) エラーになるだけマシではないか？と。

sqlite> select * from tab1 where `fooo` = 3;
Error: no such column: fooo
sqlite> select * from tab1 where `foo` = 3;
sqlite>

SQL::Maker で引用符を切り替えるには

例えば Perl の SQL::Maker - Yet another SQL builder - metacpan.org は SQLite に対してはデフォルトでは double-quote (") を使います。 これを backtick に切り替えるには、明示的にオプション "quote_char => q{`}" を渡して

use strict;
use SQL::Maker;
my $mk = SQL::Maker->new(driver => "SQLite", quote_char => q{`});
print join "\n", $mk->select(tab1 => ["*"], +{fooo => 3});
# SELECT *
# FROM `tab1`
# WHERE (`fooo` = ?)
# 3

とする必要が有ります。

zsh 実験メモ：文字列変数の中から空白文字の位置を探したい時…

zsh

ふと迷ったのでメモ。ツッコミ希望です。

foo='key foo   bar
  baz...'

のような文字列変数が有るとして、これを key と

"foo   bar
  baz..."

の２つに分割したい。

要するに perl の split " ", $foo, 2 がしたい。

一旦配列変数に展開してから、２つ目以後を取り出して join し直す、だと、途中に複数のスペースや改行があっても 一文字にされてしまうので、いつでも使えるとは限らないなあと。

ary=($=foo)
print $ary[2,-1]

文字列の中から、特定の文字の位置を探すのは、 subscript の (r) や (i) フラグを使えばいける、 けど、スペースを subscript に書くとパースエラーになる。 \ や " " だとマッチしないし。

% foo='key foo   bar
  baz...'
% print $#foo
22
% print $foo[(i) ]
zsh: invalid subscript
% print $foo[(i)\ ]
23
% print $foo[(i)" "]
23
% print $foo[(i)' ']
23
%

一時変数を作ってそこにスペース文字を入れれば行ける、けど、凄く負けた感が有る。

% k=' ';print $foo[(i)$k]
4

自分が思いついた解決策

${:-文字列式} を使う。ベストかどうか、分かりませんが。

% print $foo[(i)${:- }]
4
% print $foo[(r)${:- },-1]
 foo   bar
  baz...
% pos=$foo[(i)${:- }]
% print key=$foo[1,pos-1] value=$foo[pos+1,-1]
key=key value=foo   bar
  baz...
%
% print key=${(qq)foo[1,pos-1]} value=${(qq)foo[pos+1,-1]}
key='key' value='foo   bar
  baz...'
%

(key 側に off by one が有ったので訂正)

追記：上記を位置パラメータに使うには ${...} が必要…

% set -- --define 'dist .fc22.hk1'
% print $2[(i)${:- }]
zsh: no matches found: dist .fc22.hk1[(i) ]
% print ${2[(i)${:- }]}
5
% typeset -A defines
% p=${2[(i)${:- }]}
% defines[${2[1,p-1]}]=${2[p+1,-1]}
% print ${(kvqq)defines}
'dist' '.fc22.hk1'
%

(zsh) ある日のインフラ業 - bind の入れ替えを例に

zsh linux bind

雑に記録だけ。

大体、こんな感じだった。(Fedora22 の場合です. P3 の src.rpm はここから download. YMMV)

fn=bind-9.10.2-4.P3.fc22.src.rpm
rpm -ivh $fn
cp ~/rpmbuild/SPECS/bind.spec .

# gpg --keyserver pgpkeys.mit.edu --recv-key 911A4C02
# gpg --edit-key codesign@isc.org trust
# gpg bind-9.10.2-P4.tar.gz.sha512.asc

fn=bind-9.10.2-P4.tar.gz
cp $fn ~/rpmbuild/SOURCES

sed -i -e 's/\(^%global PATCHVER\) P3/\1 P4/' bind.spec

LANG=C rpmbuild -ba --define 'dist .hk2' bind.spec |& tee build.log

sed -n 's/^Wrote: //p' build.log > bind-rpm.files

typeset -A rpmdict
rpmdict=($(for fn in $(grep /RPMS/ bind-rpm.files);
 rpm -qp --qf "%{NAME}\t$fn\n" $fn))
  
rpmnames=($(rpm -qa --qf '%{NAME}\n'|
 grep '^bind'|grep -v bind99|sort))
  
pkgs=()
for n in $rpmnames; do
 pkgs+=($rpmdict[$n])
done
  
sudo dnf upgrade $pkgs

sudo systemctl restart named-chroot

最後の YAPC::Asia 2015 、ボランティアで参加してみました

yapcasia.org

(今の形の) yapcasia は最後と聞いたので、最後くらいは少しでも恩返し出来ないかと、サポートスタッフのボランティアに参加してきました。

前日準備と前夜祭

ノベルティグッズの袋詰め作業(千人分以上？)は、事前の打ち合わせの時に牧さんが一番つらいと言っていたので、 私もかなり覚悟して行きました。でも実際にやってみると、（確かに肉体的には辛いものの） 意外に楽しめる面もありました(私にとっては。他の人にとって楽しめたかどうか…それは聞いてみないと分からない)。 記憶では、牧さんの予想時間より２時間？ほど早く作業を終えられた！とか。(11時集合で、14時頃にほぼ終わってたので…)

早く終わった理由を振り返ると、少し思い当たるのが、作業する自分たちを、並列プログラミングにおける『ワーカー・プロセス』に例える人が多かったこと、のように思います。並列度の大小に気を配り、ボトルネックを探し、思いついた改善を自ら即座に実行に移す人が多かったことと、それに誰もとがめず違和感ももたず自然に追試し良ければ即広める。でもそれが効果を発揮しない段階が来たらさっさと捨てて、また次なるアイディアの出し合いを楽しむ…そんな雰囲気が、うっすらですが、あったこと、でしょうか。

私の視点で振り返ると、

  • 最初の Tシャツたたみで、例の YouTube で話題になった２秒でたたむやり方を、自分の手で上手く出来るまでやってみたことで、改善意識に火が付いた。
  • 次に向かったノベルティグッズ詰めでも、工程の改善が見る間に進んでいった。
    • 当初は『チラシ重ね』『袋入れ』『グッズ入れ』『シール入れ』の四段流れ作業を４並列、だったかな？
    • チラシ重ねは、上に重ねるより下に重ねるほうが速いと気づく人が出て皆真似る→速度上がる
    • 速度が上がるとバッファがたまる→工程を減員して、別の工程に進んでもらう
    • 改善→移動を繰り返すうちに、全員が全工程に慣れる。
      • 今いる工程のパイプラインが詰まったら、自発的に別の工程に移動し始める
      • ムダに気づける余地が更に生まれる。
    • 『袋入れ』工程をグッズ入れ側で受持つように。
    • シールを一枚一枚、山から取ってトートバッグに直接入れるのは効率悪いと気づく人が出て、 シールだけまとめる人と、それ以外の工程の人へと分業
    • シールまとめの作業が狭苦しい感じだったので机を移動させる。ついでに移動距離も最適化

単調作業のストレスと肉体的大変さは有ったけど、こういった諸々の改善プロセスが、時間の経つのを忘れさせる面白さにもなったのかも？。勿論、仕事の工場とかだと、あんなふうに工程間を自在に行き来することは許されないでしょうけれど。

あの時、我々は、我々自身をプログラムしていたんじゃないかな…並列処理が当たり前の時代のプログラマーは、 ああいう作業の効率改善にも向いてるのかもしれない、な〜んて。

前夜祭

私は受付チームに配属されて、企業スポンサーさんとスピーカーさんの受付を @kaihar4 さんと一緒に受け持ちました。

開始早々、渡されてたリストが去年のだった！w なんてトラブルも有りましたが、 そこでスタックせずに『名刺だけもらって対応』路線にさっと切り替えを指示してくれた、 コアスタッフの女性陣、その後も随所に発揮してくれた柔軟性、臨機応変な対応力と適切な指示出しは、 非常に頼もしかったです。優秀な人は魅力的ですね！

英語圏のスピーカーさんの受付は、ちょっと緊張しましたが、牧さんに『お名前を伺ってもよろしいですか？』を何ていいますか？と聞いて『Can I have your name, please?』だと言ってもらえたので、よしこれ一本槍だ！と押し通しました。

一日目

やっぱり早起きが辛かった(^^

お昼までは、ひたすら受付してました。有名な方々が目の前に来るという点では凄く美味しいポジションだったのですが、 とにかく粗相をしないようにするのが精一杯、みたいな感じ。リストからお名前探すの遅くてごめんなさい！みたいな。『アメちゃんもどうぞ』で笑ってくれた方がそこそこ居てよかった…。

午後になって少し落ち着いたので、一件だけトークを聞きに行かせてもらいました。 個人的に興味が有ってどうしても聞きたかった WebAudio のトーク です。 WebAudio の全体像の説明がとても良くまとまっていたのと、 ScriptProcessorNode が Deprecated! みたいな最新の話題も 聞けて、更にそう来るか！みたいなビックリ応用の話もあって、大満足でした。

.oO(あの Canvas のオシロスコープとか、github に置いてあるんでしょうかね…見てみたいな〜って…)

懇親会

color sync のお陰で、入場誘導が非常に楽でした。 (参加側だった去年までは、ごにょごにょって感じがあったので（＞＜）。これは劇的な改善だったと思います)

いくつかの営業さんとお話出来たのは、もしかしたら今の仕事や将来に役立つかもしれないので、この御縁は大事にしたいなぁ、とか。

あと、大昔の O'Reilly の第一回 The Perl Conference Japan のトーク応募に私を誘って下さった、 前田 薫 さんが私に気付いてくださったのが、とても嬉しかったです。

るーるーるーだけの蛍の光で追い出し、楽しかった。（俺だけ？)

二日目

やっぱり早起きが(ry

(前の週のコミケ参加から続く)肉体的疲労もピーク！ ですが、一日目に比べると遥かに暇で、まったりした感じでした。 ですので、交代で少しトークを聞くことが出来ました。

私は Jonathan Worthington の Perl6 の並列処理・非同期処理・並行処理のトークを聞きに行きました。 yapcasia.org

(同時通訳ではなく、英語だけで聞いたのですが)、彼の英語は、英語の耳さえ出来ていれば意味が追えるレベルのスピード・明瞭さだったので、内容に集中できました。

トーク後半の、Perl6 のメタプログラミング機能を使って書かれた OO::Monitors, OO::Actors の紹介の下りや、 "Concurrency is about competition to access and mutate" という概念把握は、非常に面白く聞かせてもらえました。

折角なので質問もしてみました。『メタプログラミングを使って実現しているとのことですが、 OO::Monitors や OO::Actors の複雑さはどれくらいか？例えば何行くらいか？』と(日本語で^^; 同時通訳さん、ありがとうございます) 尋ねた所、そんなに難しくないよ、monitor は 50(15?)行くらいじゃないかな？みたいな返事だったように思います。 ほんまかいな！と思ってググったら

oo-monitors/Monitors.pm at master · jnthn/oo-monitors · GitHub

今は 93 行だったけど、それでも凄いよ！

…それにしても、こういう技術的な質問を即席で英語で質問するのは今の私には非常に困難ですが、 日本語で質問して良いなら、かなり楽になりますね。やはり今回の通訳さんは、とても優秀な方だったのだと思います。

最後に, RJBS にバグの話を出来たこと

個人的に今回の yapcasia で、自分が達成できた一番大きなことは、 私が以前 RT に報告した perl5 のバグの問題を、 perl5 の開発まとめ役である @rjbs に話せたこと、 重大性を認識してもらえたこと、ではないかと思います。

↑このバグ自体の説明は省きます。詳しくは RT 参照、手元で動かせば重大さは理解できるはずです。

本当は懇親会の時に話しかければ良かったのですがボランティア業で頭が一杯で気づかず…

二日目の終わるギリギリに気付いて、でも rjbs は最後のトークを聞きに行ってる状況で。 でも諦めきれず、トーク会場に入ってこっそり彼の姿を１０分ほど探すと、彼らしき人を発見。 トークに熱中してたら悪いな〜と思って遠くから様子をうかがうと、何やら手元に光る二画面の液晶が… DS じゃん！

なら迷惑にはならないか…と意を決して、彼に mention を飛ばした所、しばらくして、返事をくれました。

彼に私の服装（狂った紫の帽子！）を伝えて、 クロージングの後の、出口の所で待っていると、ちゃんと見つけてくれました。(今私のツイ見ると不定冠詞が落ちてるw)

後は、カタコトの英語でバックポートのお願いをした所、彼から今朝、RC に入ってるよ！って返事をもらえました。

これなら、少なくとも 5.20 以後は救われそうです。 Perl を主なプログラミング言語として使う者の一人として、この数カ月一番気をもんでいたことなので、 胸のつかえが取れた感じです。

Email での議論と違って、対面の英語は、身振り手振りを交えて英文自体の難度は相当下げることが出来るし、 相手の表情を確認しながら話せるので失礼がないか過度に心配する必要も無くなるので、 相手の英語を聞き取ることさえ出来れば かえって楽なのかもしれません。

中津燎子の英語未来塾で英語の発音改善に取り組んだ成果が出ているようで、 ちょっと自信がつきました。

まとめ