2009-12-03 (Thu) [長年日記]
_ AWDwR3トークセッション
みなさんのご協力により、46人の方に参加いただき、無事トークセッションを終えることができました。
参加いただいたみなさん、また一緒にお話いただいた大場さん、松田さん、ありがとうございました。
2009-12-07 (Mon) [長年日記]
_ コミュニティについて
るびまの巻頭言を読んで思ったことを勢いでだらだらと書いてみる。
全体的に共感するところが多いのだけれど、あえて引っかかった部分を書こうと思う。たんに言葉の問題で、あまり重要な問題ではないかもしれないけど、でもやっぱり気になるので書きたいと思う。
というのは、ここで書かれているような広い意味でのコミュニティに対してわざわざ「コミュニティ」という名前を付ける意味があるのかな、という疑問があるからだ。 最近はどうかわからないけれど、まつもとさんは以前「コミュニティ」という言葉は嫌いだとおっしゃっていた。コミュニティなどという実体はなく、大事なのはRubyに関わっている各個人だから、といった趣旨だったと思う。僕もその考え方に共感する。
「コミュニティ」という言葉は、その内と外を意識しない限り必要ないんじゃないだろうか。 だから、コミュニティという言葉を、自分がそこに含まれていないと感じている人が使うのは、ある意味正しい気もする。
で、そういう人は次の2種類に分けられるんじゃないだろうか。
- Rubyに関わるつもりがない人
- Rubyに関っている、あるいは関わりたいけど、Rubyに関わっている他の人たちに受け入れられるかどうか自信がない人
前者については、ここではどうでもいいと思うのでおいておく。
僕が考えたいのは後者の人たちで、高橋さんのメッセージはそういう人たちに自信を持って自分もコミュニティの一員として振る舞えばよいと言っているように思える。
でもね、そういう人(僕自身、正直なところRubyコミュニティの一員かと聞かれると自信がない)から見ると、高橋さんはそうは言うけど、自分がRubyコミュニティの一員だなんて言ったら、他の人から拒否されるんじゃないかな、とか思っちゃうわけですよ。
だから、コミュニティという言葉を使うのは止めませんか。 高橋さんが言いたいのも結局そういうことなのかもしれないけど。
「あなたもコミュニティの一員として振る舞うべきです」と言われるより、「コミュニティなんて実体はないので、あなたもRubyに関わる一人として他の人と対等な立場で発言すればいいんですよ」と言われる方が安心してRubyに関われると思う。僕が言いたいのはそういうことです。
追記: 何かあらためて読むと言いたいことが上手く伝わっていないような気がするけど、色んな人が気軽にRubyに関われるといいんじゃないかなあ、と言いたかっただけです。
_ Ruby仕様書のドラフト
以下のサイトで(今後国際標準となることが期待されている)Ruby仕様書のドラフトを公開しています。
そろそろコミュニティレビューを…という話になったので、「Rubyコミュニティという明確な実体はないので、インターネットで公開してコメントを求めるのがよいと思います」とRuby標準化検討WGで御提案して上記のような形で公開することになりました。
上記のサイトにも"request users and developers of Ruby communities to review it"とありますが、あまり「コミュニティって何だろう」とか気にせず、どなたでも御自由にコメントをお寄せください。
こんなものオレたちには意味ないよ、と思う方もいると思いますが、少なくとも私にとってはRubyの仕様を改めて考えるという意味がありましたし、実際に処理系のバグもいくつか見つけました。 前向きに受け取ってもらえるとうれしいです。
なお、大部分の記述は僕じゃなくて弊社(NaCl)のK君とH君によってなされました。よく書けている部分があったとしたら、たぶん彼らのおかげです。まだ不完全だとは思いますが、実際、これだけ網羅的にRubyの仕様を記述した文書は今までになかったと思います。K君、H君、おつかれさまでした(まだぜんぜん終わってないけどね)。
また、不完全な部分については主に私の責任で、コメントで指摘いただいている部分の多くは、私も気にはなっていた部分や、もっと詳細にチェックすれば気付けた部分です。 ただ、我々の力には限りがありますので、みなさんにもご協力いただけるとありがたいです。
_ 実はアジャイルが苦手です
この間のトークセッションの時に松田さんに「前田さんが嫌いなアジャイル」と言われてしまって、その場では補足する機会がなかったので、説明しておく。言い訳じゃないよ。
僕が松田さんに言ったのは「アジャイルが苦手」ということで、もうちょっと補足すると「アジャイルという言葉が苦手」ということだ。
というのも、何かアジャイル開発手法という特定の手法があるように言われて戸惑うことが多いからだ(あったら教えてください)。 たとえば「Rubyと相性がよいというアジャイル開発手法の講習をやってください」とか言われると困ってしまう。
という、ただそれだけのことです。
僕がアジャイルという言葉をあまり使わないのは、アジャイルという言葉で表そうとしているものが、アジャイルという言葉を使わずに表現できるなら、その方が誤解がないような気がするからです。
追記: 上記はあくまでも僕の場合の話であって、他の人がアジャイルという言葉を使うのをとやかく言うつもりはありません。念のため。
2009-12-10 (Thu) [長年日記]
_ instance_eval/class_evalの仕様変更
Ruby 1.9で変更されていた、instance_eval/class_evalのブロック内での定数・クラス変数の探索時の挙動を1.8の挙動に戻した(r25984)。 たとえば、class_evalの場合、レシーバが探索対象に含まれなくなったので注意してください。
1.9の新しい挙動の方が一貫性があってわかりやすいと思っていたが、メタプログラミングではレシーバに何が来るかわからないことが多く、定数名の衝突が問題になるため、Yehuda Katzの強い要望で結局元に戻すことになった。これで、Railsの1.9対応が加速するかも?
また、ブロックパラメータについても、1.8同様にレシーバが渡されるようになった(r26062)。
ちなみに、Yehuda Katzがしきりに定数のスコープをlexicalと言っているが、厳密にはlexicalじゃないと思う(わかった上でわかりやすさを優先してそう言ってるだけかもしれないけど)。
2009-12-24 (Thu) [長年日記]
_ Emacsユーザのためのadvice
Emacs Advent Calendar jp: 2009の参加記事。昨日はid:hayamizさん。 明日は他に参加する人がいなければid:authorNariさん。
最近はVimを使うことが多いけど、shiroさんのお話を聞いてやっぱりLispは強力だなあとか思ったりしたので参加してみた。 知ってる人も多いと思うけど、Emacs Lispのadviceという機能を簡単に紹介しよう。
adviceとは、簡単に言うとCLOSのmethod combinationみたいなものだ。あるいは、Railsのbefore/after/aroundフィルタみたいなものと言った方がいいだろうか。要は、既存の関数(正確にはマクロや特殊フォームを含む)の実行の前(before)あるいは後(after)、前後両方(around)で実行したいコードを定義する機能である。
たとえば、以下のコードはGNU Emacs拡張ガイド―Emacs Lispプログラミングに載っている例(だったと思う)で、switch-to-bufferで存在しないバッファ名を指定した時に、新しいバッファを作らないようにするためのものだ。
(defadvice switch-to-buffer (before existing-buffer activate compile)
"When interactive, switch to existing buffers only,
unless given a prefix argument."
(interactive
(list (read-buffer "Switch to buffer: "
(other-buffer)
(null current-prefix-arg)))))
簡単に説明すると、defadviceはadviceを定義するためのマクロ(マクロ万歳!)で、defunに似ているがちょっと違う。 switch-to-bufferの部分には拡張対象の関数名を指定し、beforeの部分にはbefore/after/aroundのいずれかを、existing-bufferの部分にはadviceの名前を指定する。activateとcompileはフラグで、それぞれadviceを活性化することと、コンパイルすることを指示している。 詳細はマニュアルなどを参照。
以下の例は、find-fileを拡張して、C-u C-x C-fのようにprefix引数付きで実行した時に明示的にcoding-systemを指定できるようにするもので、標準の機能が見つからなかったので自分で定義して愛用している。
(defadvice find-file (around coding-system activate compile)
"When a prefix argument given, specify coding-system-for-read."
(let ((coding-system-for-read
(if current-prefix-arg
(read-coding-system "coding system: ")
coding-system-for-read)))
ad-do-it))
aroundの場合は、元の関数(この場合はfind-file、正確には自分より内側で実行されるaround adviceも含む)の前後でadviceを実行するわけだが、上記のad-do-itの部分で元の関数が実行される。 この例だとad-do-itの後に何も処理していないのでbeforeでもいいと思われるかもしれないが、letでcoding-system-for-readを束縛する範囲にad-do-itを含めるためにaroundにする必要がある(Emacs Lispはdynamic scopingを採用しているので、letで束縛されたcoding-system-for-readの値は、ad-do-itで呼び出される元のfind-fileからも参照されることに注意)。
というわけで、今日はEmacs Lispのadviceを紹介した。 こういったadviceが色んな人の.emacsに散らかっている(そしてどれもちょっとずつ違う)のが、Emacsの楽しいところであり、やっかいなところでもある。 他人のマシンで作業する時のために、第2母エディタとしてviなども習得しておくことをお勧めする…というのが僕からのEmacsユーザのためのadviceである。