諸事情があって、っていうかドンキホーテ観に上野に行ってたわけだが、Daveを見逃したのはすごく残念だったようだ。スタッフの皆様、お疲れ様でした。前夜祭のときデモ見せてもらうのスキップしたのだが(初日だと思ってた)、見損なってしまうことになるとは。残念は、特にこれまでの経緯(と特別な興味)もあって見たかったなぁ。今週末くらいに出します、多分。抜けで、ファイルの最後まで行っちゃうときな。あれはたまんないよな。ゆき菜さんのLTに一番、感銘を受けたよ。あの場にいた人間は誰も(もちろん僕も含めて)、需要も解決方法もわかっているのに何もしなかったのに、彼女はやっちゃったんだからね。(多分、このパッチはありがたくp36版ASRに入れ込むつもりです)なんかぽろぽろ書いているけど、このセクションをtbしよう。Windowsを日本語化させて試してる。・オリジナル著作権表示不要と思ったら、3番目の条件のために、クリエイティブコモンズには適合するライセンスがないように見える(わかってないだけかも)。domainだ、と書いてあることになる。それに、Cマークがあろうがなかろうが、著作権って付いて回る仕組みだったはずだ。いうか、もともと画像上にクレジットが存在してないわけだから、気にするまでもないのかも。2.1(利用許諾条項)を適用します(元々の画像にクレジットがないので、表示すべきクレジットは無いということになります(としてよいのか良くわからないけど、いらないものはいらない))。僕らを2つに分かつとき妙にリバーブしてる。工場はピタゴラスィッチこないだテレビ見てたら、ガリガリ君を作る工場とか、ラムネ菓子作る工場とかやってたんだが、ころころ転がって、紙に包まれて、向き変えて、折り曲げられて、風に吹かれて口が開いて、棒が差し込まれて、......、と進むのがえらくおもしろかった。いうマシンの設計ってカラクリみたいでおもしろそうだな(それにつけてもおそるべき生産性だ)。diffのpオプションが重要なのかdiffには、-pというオプションがあって、これを指定すると変更された関数名が含まれる。}別にあってもなくても影響なさそうに思えるわけだが。-pを付ける必要があるかについて、nokadaさんがRubyKaigi前夜祭で力説してたのを思い出したので、メモ。おれらが見てるソースはcvsヘッドだから-pが無いと全然わからないんだよね。いうわけで、ruby-devにパッチを送るときは、-pを付けようという話でした。動的/静的どっちが言語の例のやつ水島さんのとこを読んでて(もちろん、元(なのか?)のrubycoさんのところからだいたい読んではいたわけだけど)、こないだのRubyKaigiのテーマともからんで、多分、アジャイルな考えも入れて、そのあたりで思いついたことを書いてみる。プログラムを書く人は、だいたい誰でも知っていると思うし、それゆえにケントベックの変化抱擁があれだけ受け入れられたんだと思うのだが、なにはなくても「自信」というのは、目的遂行には欠かせないものだ。4象限で相手の状況を分析し、それにあわせて適切な目的遂行のためのガイドをすることをリーダーシップと呼び、技術的にはティーチング、カウンセリング、コンサルティングの3種類の方法論を適用するというメソッドがあるのだが、「自信」っていうのは、つまりは気の持ちようなわけだが、「能力」と同程度に重要だという点が取り込まれていることはやはり注目に値する)で、実際にプログラムを書く人にとって、自信の裏づけとなるのは、テストだ(もちろん、地力ってのはあるにしても)。プロジェクトの完了は、プログラマだけで行われるわけではない。さまざまな調整や管理が必要なほど(少なくても大規模であればあるほど)、その他の利害関係者は多くなるものだ。彼らも彼らの自信の裏づけが必要となる。テスト要項書とチェックマークかな。ユーザーの裏づけは、要件仕様書に書かれた内容や、プロトタイプの動作や、受け入れテストとか。口うるさく会議をこまめに開きまくるってのも、すべては自信のためだ。大船に乗って......ってのは、自信がベンダーに対する信頼だけで成り立つ場合のみで、利害関係者が多ければ、全員がそういう気持ちになることはあり得ない。めんどうだから、これで終わりにするが、静的言語の選択というのは、つまるところ、実際にプログラムを書くわけでも、テストをするわけでもないプロジェクトメンバーにとっての、自信の裏打ちだ、ということだ。したがって、間違いなく、本気で、「なぜ静的言語を選んだのか本心を教えてよ」と聞けば、「プログラマーが楽に(早く、正確に、デバッグしやすく、大して学習しなくても済む、とかいろいろな理由から)コードを書けるようにするためだ。それにより、スムーズに次のフェーズに移行できるし......ひいては、プロジェクトの成功に結びつく」というような答えが返ってくるだろう。人間系においては、「自信」というのは、砂上に築かざるを得ない。したがって、評判とか世間様とか、常識(なんのかは知らん)に従うことは、すごいアドバンテージとなる。道に外れていないというのは、自信に通じる(それはそうでしょ?)。逆に、自信がないとプロジェクトの成功可能性は低くなる。自信がない状態でプログラミングしたプログラムには間違いなくバグがあるってのと同じことだ(自信があってもバグがあるのがなんともゆくゎいなところではあるけれど)。したがって、規模が小さく、デベロッパーとマネージャとカスタマーの結合強度が強ければ、当然、信頼度も高いので、このデベロッパーが選択したテクノロジーなら間違いないだろう、というプロジェクトの人間系の自信となり得る。規模が大きく、顔も見たこともない、もしかしたら海の向こうのデベロッパーの進捗まで考える必要があるような場合には、評判や世間様や常識や定石を外れてそうなテクノロジーの選択は、まったく自信とはならない。