日々の破片

_ 今日（昨日だけど）は期末だったのか

というわけで、るびまも出ているけど（RubyKaigi大特集!）、Firefox3.5が出たので、更新した。

これで、IE7程度の速度（ずーっと起動していた場合の話）になれば良いのだが。

_ 新しい世界にやって来た古い世界の人たち

ローザとコルンゴルトは知っていたが（ハイフェッツの弾いた協奏曲集はお気に入り。映画音楽家としてはローザのムーンフリートは本当に素晴らしい）、ヒンデミットもアメリカの人になっていたのは知らなかった。退廃芸術家とされたのかな。

コルンゴルド&ローザ:ヴァイオリン協奏曲&ワックスマン:カルメン幻想曲(ハイフェッツ(ヤッシャ))

バレエ音楽が嫌いなせいもあって、ストラヴィンスキーはアメリカ時代のほうが好きでアゴンは良く聴くと思ったけどアゴンもバレエ音楽だ。プルチネッラを出せばよいのか（これもバレエだ）。

ストラヴィンスキーと言えば、何かの映画で主人公がハリウッドでゆうゆうと暮らすストラヴィンスキーの家を覗きに行って睨まれるというエピソードが描かれていて、それがイメージ通りの偏屈なロシア人そのもののそっくりさんでえらく笑ったのだが、はて何の映画だったろうか。グッドモーニングバビロンかな？

コルンゴルトという生き方は興味深い。ありあまる才能に恵まれて神童、天才の名をほしいままにしていたのに、あるいはそれゆえに時代が変わる足音に鋭敏に反応してしまう。そこで新しい世界に行き、新しい世界に身を投じる。そこでも神となる。しかし、そこで神となっている間に生れ故郷では彼のスタイルは唾棄すべき古臭いスタイルとなっていて、しかも新世界の神というのは旧世界では単なる邪教への改宗者でしかなく、居場所がなくなり身悶えしながら忘れ去られて死んでいく。

続きがあって、新世界でもみんなが忘れ去った後に、こんだ旧世界の新芸術界（つまり映画）の作家たちがその偉大な存在に気づき、復活を遂げる。それがたった100年の間の出来事だ。

という具合でテレピン（本当にそう読むのかなぁ）は知らないけど、コルンゴルトとローザ（ミクロシュ・ロージャが正しいとは思う）は好きなので、New World Composers from the Old Worldを買おうとしたが、ちょっと考えた末、保留。

_ 5年後に後悔しないJavaプログラムの書き方

ここ数日、死ぬほど後悔しまくっているので、あらためて（というのは、数年前にも一度後悔しまくって、そのときの知見はあらかた処方箋とかコーディングの掟に書いているからだが）後悔しないための書き方をいくつか紹介する。

とにかく、ファクトリメソッドパターンを使うこと。

これは本当に重要。しかも簡単でありながら効果は絶大。

だめな例。

public class FooBar {
    private Connection conn;
    ...
    protected void setup() {
        ...
        conn = DriverManager.getConnection(url);
        ...
    }

urlを指定することや、DriverManagerの実装を交換すれば良いだろうと想定していても（というか、Connectionならそういう方法もあり得るが、そうはいかないものも多い）、そのための手間が大き過ぎれば意味がない。

良い例。

public class FooBar {
    private Connection conn;
    ...
    protected void setup() {
        ...
        conn = newConnection(url);
        ...
    }
    protected Connection newConnection(String url) {
        ...
        return DriverManager.getConnection(url);
    }

利用方法

public class FooBarTest extends TestCase {
    FooBar target;
    protected void setUp() throws Exception {
        target = new FooBar() {
            protected Connection newConnection(String url) {
                return new MockConnection();
            }
        }
    }

ファクトリーメソッドパターンを適用しておけば、オブジェクトの生成時に割りこめる。当然だが、効果は絶大。

フィールドはパッケージプライベートにすること。

この問題は比較的すぐに気づいたのだが、いかんせん、本当にインフラ中のインフラになってしまったコンポーネントはごく初期に開発したためにprivateを使い過ぎていて、厄介なことこのうえない。

だめな例。

public class FooBar {
    private Connection conn;
    ...
    protected void setup() {
        ...
        conn = DriverManager.getConnection(url);
        ...
    }

良い例。

package com.example.foo;
public class FooBar {
    Connection conn;
    ...
    protected void setup() {
        ...
        conn = newConnection(url);
        ...
    }

ファクトリメソッドパターンを適用すれば万事解決だと思うとそうはいかないことが稀にある。稀にしかないからこそ、ちゃんと用意をしておいたほうが良い。

利用方法

package com.example.foo;
public class FooBarTest extends TestCase {
    ...
    public void testSpecialCase() throws Exception {
        target.doSomething();
        MockConnection stat1 = (MockConnection)target.getConnection(); // #getConnectionはprotected
        target.conn = new MockConnection();
        target.doSomething();
        assertEquals(stat1.getCondition(), ((MockConnection)target.getConnection()).getCondition());
        ...

ここで、フィールドをprivateにしたままでパッケージプライベートなsetConnectionメソッドを導入するという代替案を考え付くかも知れないが、メソッド呼び出しとフィールドの上書きはユースケースが異なるので、上記のような処理の役には立たない。仮に立つのであればその程度の利用方法なので、あまり考えてもしょうがないとも言える。

セッタメソッドの公開とフィールドの公開の両立が必要な例

package com.example.foo;
public class MoreFooBar extends FooBar {
    void setConnection(Connection c) {
        ...　　　　　　　　　　　　　　　← この部分の迂回が必要な状況（開発後1年で必要になるとしたら、それは設計ミスだとは思うが）
        super.setConnection(c);
    }

追記:上に関連してメソッドを(構造化の要領で)機能単位に分割する(サブルーチンのインスタンス化)というのがここに入る。

可能な限りDIコンテナを利用する

これは今となっては当然のことだが。

オブジェクトの利用方法はオブジェクトに任せる

悪い例

protected void foobar(Baz baz) {
    ...
    AR ar = newAR();
    ...
    ar.foo(baz.getBzz());
    ar.bar(baz.getBzz());
    ...
}

良い例

protected void foobar(Baz baz) {
    ...
    AR ar = newAR();
    ...
    ar.foo(baz);
    ar.bar(baz);
    ...
}

arをファクトリメソッドを利用して交換可能にしたにも関わらず、限定的な引数を与えているため、Bazオブジェクトが持つ情報をarは利用できない。その時点ではAPIを狭くした良いインターフェイスと考えていたとしても、処理は精緻化複雑化するものだ。与える情報を絞るのではなく、与えた情報を絞らせるように設計すべき。(で、上の例であればファクトリメソッドをオーバーライドしてARを入れ替えるだけでは済まないので、結局foobarメソッドをすべてコピー&ペーストして2行だけ変更するということになってしまう。これではファクトリメソッドを導入してもそれほど役に立たない)

追記：これについては補足した。

将来を見通すことはできないということを肝に銘じる

3年程度の短期寿命と考えていても、リリースしてしまえば中期、長期にわたってソフトウェアは使われることがあるという2000年問題の教訓は今でも有効だ。

つまり刹那的インターフェイスを避ける。

刹那的インターフェイスというのは、強い制約をもたらすものを指す。上に挙げた例では、new、private、オブジェクトの部分的な引き渡しがそれにあたる。他にもたった一つのfinalメソッドのために、クラスをまるまるコピー&ペーストして別クラスを作らざるを得ないというような例もある。というわけでfinalも極めて刹那的なインターフェイスだ。

ここで挙げた内容は、ミドルウェアやフレームワークの内部のオブジェクトにしか当てはまらないと考えることもできるが、必ずしもそうではない。これらは、プログラムの寿命が長ければ長いほど重要になる。なぜならば、寿命が長いということは、そのプログラムのコードの信頼性が高いということであり、それはつまり元にしやすいということに通じるからだ。

コピー&ペーストと、継承と、コンポジションの3種類の再利用方法があり、いずれも一長一短がある。コピー&ペーストはたまたま発覚しなかったバグが見つかった場合に大きなダメージとなる。コンポジションの場合は狭過ぎるインターフェイスによって拡張に耐えられなくなる。継承は細切れな派生クラスの深いツリーによって手が負えない塊になる危険を持つ半面、長期的に成長するソフトウェアに大しては安定した基盤を提供できる（コンポジションと異なり狭いインターフェイスの問題は、内部に食い込めるだけに抑制できる。結局、コンポジションと継承はどちらも重要なのである）。

Javaプログラミングの処方箋 (Programmer’s foundations)(宇野 るいも)

大体、ここに書いたことの通りだ。

_ 手ぬぐいと納税者は絞れるだけ絞れと行政官は言った

流れよわが涙、と警官は言った (ハヤカワ文庫SF)(フィリップ・K・ディック)

昨日書いた後悔先に立たずの公開だが、ぶくまこめで「。与える情報を絞るのではなく、与えた情報を絞らせるように設計すべき。」に対する反応があって、それも正しい反応だと思った。もっとも2行あるのは例示のあやなので、ちょっとそこに突っ込まれてもとは思うが。

たとえば、次に示すBase64EncoderクラスのAPIは何がなんでもおかしい。

public class ComponentInfo {
    public byte[] getGuid() { ... }
    public byte[] getCpuInfo() { ... }
}
...   
public class Base64Encoder {
    public String encodeGuid(ComponentInfo info) { ... }
    public String encodeCpuInfo(ComponentInfo info) { ... }
}

これはどう考えてもあり得ないでしょう。こんなメソッドの決め方をしていたら、一体、どれだけメソッドが必要となるか。正しくは、

public class Base64Encoder {
    public String encode(byte[] data, int offset, int length) { ... }
    public String encode(byte[] data) { ... }
    ...
    public Reader encode(InputStream stm) throws IOException { ... }
}

とすべきだ。クラス名もBASE64エンコーダだし。

この例のBase64Encoderクラスのようなオブジェクトは、呼び出しの末端に来て、この中で別のオブジェクトをコンポジションしていることもなければ、他のオブジェクトをラップすることもない。このタイプ（つまりはユーティリティだ）のオブジェクトが実装すべきAPIは、絞りに絞ったものとすべきだ。具体的には、プリミティブとせいぜいjava.langパッケージのオブジェクトとその配列。もっとも、上の例ではjava.ioのオブジェクトを含めているが、ケースバイケースではそれもありだろう。

しかし、それは逆に言えばファサードのような他のオブジェクトのコンポジションクラスであれば、絞れば良いということではない、ということだ。

次のクラスは、情報を収集して、最後にレポートを出す。

public class CompoenentInfoSet {
    /**
     * {@link com.example.foo.ComponentInfo1}オブジェクトのGuidをレポート用に設定する。
     * @param guid 対象クラスのCompoenetInfoが返すGuidの値。
     */
    public void setRawId(byte[] guid) { ... }
    /**
     ....
    public void setHash(int hash) { ... }
    ...
    public String report() {
        ...
    }
}

利用するコードは以下となる。

....
ComponentInfo ci = new ComponentInfo(this.getClass()); // と何気なくnewを使って自滅するのであった
...
CompoenentInfoSet set = newCompoenentInfoSet();
set.setRawId(ci.getGuid());
set.setHash(this.getClass().hashCode());
...

ここで、CompoenentInfoSetクラスのAPIは一見すると妥当なように見えるかも知れない。が、それは違う。

この時点では、RawIdとして与えるのはCompoenetInfo#getGuidで、Hashとして与えるのは、selfが属するクラスのhashCodeかも知れない。

しかし、5年後の夏には、GuidだけでCompoentInfoを示すのでは困るかも知れない。そのために、拡張が必要となったとしよう。

public class ExtendedCompoenentInfoSet extends ComponentInfoSet {
    public void setCpuInfo(byte[] cpuinfo) { ... }　// 追加

もちろん、5年前には想像もしていなかったことだ。

で、それはそれとして、元のプログラムも現役で稼働しているのだから、同じく継承クラスを作って、でも、基本的な処理は元のクラスと同じだから、と見てみると

....
ComponentInfo ci = new ComponentInfo(this.getClass()); // と何気なくnewを使って自滅するのであった
...(10行程度のフラットな処理)
CompoenentInfoSet set = getCompoenentInfoSet();
set.setRawId(ci.getGuid());
set.setHash(this.getClass().hashCode());
...(その他20行のフラットな処理。しかし最後にはデータベースへレポートを保存するような二度と書きたくはないようなコードもある)

幸いにも、ComponentInfoSetは、ファクトリメソッドパターンのインスタンスで生成するようになっている。が、残念、使えない。どうやって、新しく追加したsetCpuInfoメソッドを呼べば良い？ ファクトリメソッドで割りこめても、cpuInfoの元ネタのci変数にファクトリメソッドからアクセスすることは不可能だ。

かくして、コピー&ペースト再利用となり、メンテすることになるコード資産が倍増した。

もし、以下のようであったらどうだろうか？

public class ComponentInfoSet {
    /**
     * {@link com.example.foo.ComponentInfo1}オブジェクトが持つGuidをレポート用に設定する。
     * @param ci 対象クラスのCompoenetInfoのインスタンス。
     */
    public void setComponentInfo(ComponentInfo ci) { ... }
    /**
     ...
    public void setClassObject(Class c) { ... }
    ...
    public String report() {
        ...
    }
}

つまり、ComponentInfoSetクラスは、別に呼び出し側がわざわざオブジェクトからバイト列を抜き出してやらなくても、自分がどの情報を利用して何をするかは知っている。だからこそ、元々のメソッド名も、setRawIdだったり、setHashCodeだったりしていたわけだ。

これはDRY原則に通じる。すべてのオブジェクトが何をするかの詳細を知っている必要はない。詳細はシステムの末端（ただし、冒頭で示したようにユーティリティなどの「機能」特化オブジェクトは除く）のオブジェクトが知っていれば良い。知識をあまねく分散させたり中央集権でやるのではなく、知識（というよりもそれを利用して果たすべき責務）を適切に分配することが重要だ。

このクラスを利用するコードは元のコードから次のように変わる。

....
ComponentInfo ci = new ComponentInfo(this.getClass()); // と何気なくnewを使って自滅するのであった
...
CompoenentInfoSet set = newCompoenentInfoSet();
set.setComponentInfo(ci);
set.setClassObject(this.getClass());
...

一方、ExtendedComponentInfoクラスは次となる。

public class ExtendedComponentInfoSet extends ComponentInfoSet {
    /**
     * {@link com.example.foo.ComponentInfo1}オブジェクトが持つGuidとCpuInfoをレポート用に設定する。
     * @param ci 対象クラスのCompoenetInfoのインスタンス。
     */
    public void setComponentInfo(ComponentInfo ci) { ... }
    ...
    // もちろん、reportメソッドの実装なども変わる。
}

もし、こうであれば、5年後には、単にnewComponentInfoSetファクトリメソッドをオーバーライドして、ExtendedComponentInfoSetクラスのインスタンスを生成して返すように変えたクラスを作れば、すべての作業が完了する。コードの重複も生まれない。既存の処理に対する影響はゼロ。もし、データベースをいじくるところで問題が出たりしたら、その時にはじめて、本格的に元のクラスのコードのコピー&ペーストなりを行えばよい。

たったひとつの冴えたやり方は、ケースバイケースにいくつものやり方から適切な方法を選択して設計することだ。

たったひとつの冴えたやりかた (ハヤカワ文庫SF)(ジェイムズ・ティプトリー・ジュニア)

_ 産み出す文化と保持する文化

相変わらずSOAPとRESTについて考える。もちろん理由もあるのだが、第三者の目で眺めて興味深いからでもある。

たとえば、WADLを眺めて、なんじゃこりゃと感じる。

LLとHL（そういえば、HLとは言わないな）があって、LLの人は既にハッピーなのだが、そこにHLの人がやってくる。なぜかは知らないがLLの人に「型宣言がないなんて信じらんない」とか言い出したりしてそこらじゅうにシグネチャを埋め込ませようとする。

いや、そんなものなくても困らないから、と言っても聞く耳を持たない。まるでイヌイットに海水パンツを売りに来たり、南洋諸島にオイルヒーターを売りに来たりする商社マンのようである。どうやら、それがなければならないらしい。もっと適切なのは、バナナがなりまくっているフィリッピンの小島のひとつに、バナナ架けを売り込みに来た商社マンであろう。さあ、君たち、バナナ架けを買い給え。これがあればバナナは黒くならない。

いや、それが必要な場合は知っていて、とミンダナオの人が答える。今度日本へホームステイするから、そのときはお土産に買ってくよ、とか。

でも商社マンは納得しない。今、ここになければならないし、今、ここで利用しなければならないのだよ。坊や。なぜなら定義言語があれば、自動でクライアントを作れるじゃないか。

いや、別に自動でクライアントが作れなくても、裏庭で新しいバナナをもいでくれば済むから。というか、食いきれないほどもがないし。とミンダナオの人は答える。

それはおかしい。と商社マン。ストックしなければだめだろ？ 文明というものは銀行とともにあり、流通とともにあり、どちらもストックだ。

そうは言ってもねぇと、目の前のバナナをもいで食いながら、仮にもぎ過ぎて黒くなったら、別に、また書けば済むじゃん。というか、そのためのLL。

そこで考えるに、HLでリファクタリングというのは、文化的な垣根を破壊する作業なのかも（同一性の問題についても考え方が異なる。ダイジェストが同じでなければ同じプログラムではないという考えと、機能が同じであれば同じプログラムという考え方。何をもって同一とみなすかというのも考え方の相違だから理解しあうのは難しいのだろうな）。だけど、垣根はあまり壊れないよね、というよりも、壊れる垣根はそもそも垣根の役に立っていないし。

_ 奇想の王国

文化村で奇想の王国。

國芳の『みかけハこハゐがとんだいゝ人だ』が題名の素晴らしさでえらく気に入る。もっとも画はどちらかと言えば、どうでもいいけど、とにかく題。Wikipediaのリンクにつけられた名前もいかしている。

画としては、17世紀くらいの精緻に書き込まれた静物画の努力に心は打たれる。

妻が、こんな画を書いていて、歓びみたいなものがあるんだろうか、とか言い出して、ちょっと考える。

ジョットーが感じたであろう法悦感とか、ピカソが感じているだろう衝動感だとか、そういったものはないんじゃないかなぁと想像する。

しかし、それに代わり、どれだけガラスのように透明なものを透明に描くか、どれだけ額縁の存在感を平面上に再現するか、何よりも観た人にセンスオブワンダーを感じさせるか、そういった技術をベースにした表現の可能性に対する探求の歓びみたいなものがあるんじゃないか、と考える。

ってことはだ、この画家たちは、技術者であり、SF者である、とそういうことなのであろう。宗教画と春画の両立のために歪めた画を描いてみたり、遠近法の重要さを説くための悪い例の極端流な書き方とかにも、そういった精神があるように思う。

とすれば、20世紀になってダリとマルグリットマグリットの作品が出てきた時点で、何か異なる展覧会になってしまうのもしょうがなさそうだ（エッシャーは良いのだが、マルグリットマグリットとダリの作品群は場違いに見える）。モダニズムの時代では、技術による驚きは画では提供できなくなってしまったからではないか？ もっとも、初めて生でみるマルグリットマグリットは妙に平坦な質感にちょっと驚かされる。エッシャーのように版画を使わなかったことで、特異さが際立っているようにみえるのだ。

それが、現代になって、また驚きの凸が凹に見える画が出て来て、実はまだ探求すべく領域が残っていたということにささやかな感動を覚える。あるいはあっさりと描かれたたくさんの皿の実在感とか。

_ ボウフラ

辻潤の作品に『孑孑以前』というのがあり、見た目もボウフラっぽく、IMEも何事もないかのように孑孑と出してくる。ということもあって、孑孑と書くのかと思っていたがWikipediaには異なる記述がある。でも、ここはEUC-jpだからおそらくコピペしても?になるだけだろうし、典拠は辻潤ということで孑孑は孑孑でいいや。

で、子供が修学旅行のようなもので入手してきた稲をバケツで育てているのだが、孑孑が湧きまくっていることを発見し、どうしようかと考える。

メダカを放すのが好みではあるが、水やりを忘れるとかわいそうなことになるのは目に見えているので、生物兵器の導入は却下。

で、何かの記憶で油を撒くと言うのがあったなぁ、と軽く検索をかけると、食用油を1〜2滴入れて膜を作ると、水面に上がって来ても呼吸ができないので駆除できると書いてあるのを複数個所で見つける。この方法だろうな、と考える。孑孑はエラで呼吸するわけではなく昆虫なのだから、まちがいなく空気呼吸するはずだし、説得力はありそうだ。

で、試してみると、これはしたり。だめじゃん。

まず、食用油を水に入れると、その場で大きな油滴に丸まってしまう。そういえば、水たまりのガソリンとかはきれいな油膜になっているが、あれは揮発性だからか、あるいは親水性を持つように何かの薬剤が入ってるんじゃないか？

というわけで、結構な量を入れたり撹拌したりしてみたが、どうやっても膜にはならない。

で、観察しているとボウフラは水面に上がって来て油滴にぶつかるとしばらく困っているが、結局下に降りて斜め上に上がり……最終的には単なる水のところで息をついている（ように見える）。

おそらく、テレビか何かで田圃用に仕掛けのある油を入れて膜を作っているのに対して、ご家庭では食用油で代用、のようないい加減なナレーションが入り（おれの記憶もそんなようなもので作られたのかも知れない）、しかも実際に試したやつはいない、ということではなかろうか。

というわけで、ボウフラに食用油は意味がない。

と、書いてから、意味がないのは、カノーラ油の特性で、日清サラダ油ならOKとか、種類によって違うのかも、ということに気づく。が、夏休みの宿題でもないので各種食用油を使って実験する気は起きない。

というわけで、羽化したところをアースノーマットで撃退するしかないのかなぁ、ということになった。

アース製薬 アースノーマット 120日セット ミントグリーン(-)

水際封鎖作戦に失敗したため、本土決戦に備える

_ ふつぱいら

青木さんは元気にやっているんだかどうだかさっぱりわからないが、本は書き上げたようだ。

ふつうのコンパイラをつくろう(青木 峰郎)

Javaを使ったC（のサブセット言語）コンパイラという方針は変わってないんだろうな。

それにしても、RHGのプレミア価格はとんでもないものになっている。

Rubyソースコード完全解説(青木 峰郎)

でも、さすがに15000円出すんだったら、アルゴリズムデザインを買って勉強しながら、生ソースを読むほうがいいんじゃないかなぁ。

アルゴリズムデザイン(Jon Kleinberg)

_ 買わせた読んだ

最近は子供が自分で買ってくるので楽になった。

隠の王 11 (Gファンタジーコミックス)(鎌谷 悠希)

ときどきあすなひろしのような絵柄になるときがあって、ちょっと不思議な感じ。

_ メモ

今さらなことをやっているため、今頃にになって気づき、半日潰した。

Please note that JNDI resource configuration has changed somewhat between Tomcat 5.0.x and Tomcat 5.5.x.

_ finally

先日、『世界を股にかける数十億ドル規模の巨大航空会社をストップさせたバグ』を読んで、ふむふむあれだな、と思ったのだが、今日、『わかりませんでした』を読んで、不安になる。

もしかして、あれじゃない別の問題なんだろうか？

で、おれが想定する「あれ」というのは、『Oracle JDBCドライバにオブジェクトの自動クローズ処理を追加する 』で書いた、フレームワークで解消してやれよ、という問題なのだが。

追記：上で引用したcodezineの記事には、そのものずばりの現象は書いていないから、想定しているものを示したことにはならないのか。想定したのは、コーディングの掟の呼び方だと例外の轢き逃げ現象のほう。

_ パターン、Wiki、XP――時を超えた創造生成の原則

江渡さん（と角谷さんと懸田さん）のトークセッションを聴きにジュンク堂。

以下、メモの生データ

どういうつもりで書いたのか
 
『パターン・Wiki・XP』ができるまで
 
2007年、オブジェクト倶楽部のイベントで講演したのがきっかけ。
 
2008年にプロジェクト開始
　情報収集：中埜さんなどにインタビュー（都市計画の専門家としての山形浩生、ソフトウェアとしての平鍋）
 
2009年1月頃にレビューを開始
　（角谷さん、懸田さん、shinoさんなど）
　→これによって、よりよくなった
　　　例）3部構成が、2部と3部の入れ替え、章の追加
 
なぜ書いたのか？
 
　内容は短時間で説明できない。したがって、なぜを説明する。
　Wikiというシステムに興味を持ったのが2002年頃。
　quikWebを作った　（開発中の議論が良い経験になった）
　　機能追加によって悪くなることがある
　　→良い機能追加とは何か？　− Wikiの本質を強化するのが良い機能追加
　　→　では何が本質か？ なかなかわからない。
 
　デザインパターン
　　90年代ころから興味を持っていた
　　パターン良いという人と悪いという人がいる。
　　　　→なぜだ
　　アレグザンダーが元になった（パターンランゲージ）
　　　　→全然違うのに……
　　パターンを取り入れるベック＆カニンガムの論文を読む
　　　→納得した　「コンピュータユーザは自分自身のプログラムを書くべきなのである」
・　パターンとは、プログラムを使う人間が、プログラミングに口を出せるように、
　　パターンという言葉を言ったのである。
　→最初は、正しい言葉だった。なぜ変わったのか？
 
　XP
　　チーム開発はしていないので、直接は取り入れない、しかし方法論としておもしろい。
　　ソフトウェアを作るときに、使う人間を開発の現場に取り入れるべし。
　　→　言うは易く行うは難し
　　：責任の分解点が切れなくなる　のではないか？　でもベックはそう書いている
　　　→　ソフトウェアの業界構造を見直すべきという主張なのか？
 
上記3つの問題意識
　共通項がある。→　アレグザンダーのパターンランゲージ
 　
　　XPにつながっていることが自分にとっての発見だった
　　　→カニンガムとベックは、デザインパターンに満足していなかった
　　　　二人は、デザインパターンが生まれたことで、大事な物が取り落とされた
　　　　→　出直しがXPである
 
　　Wikiは、それを支える土台になったのだ。
 
XPの生まれた土台は、Wikiで議論する（MLでもF2Fでもない）
　　→ Wiki？
　　土台をどう作るか？　どうデザインするか？
　→　問題意識でつながっている
 
　アレグザンダーの建築理論について説明が必要だと思った
　　時代によって理論が変遷したか。
　　前半と後半では異なる。
　　　前半：設計をどう形式化できるか。（1964）
　　　　　絶対に備えているべき条件がある。作る時：形状：などをY/Nで切り分けられるように形式かすることがデザインである、と定義
　アレグザンダーはクリエイティブからデザインを切り離そうとした（数学の言語を使って）
  
　　　後半：都市はツリーではない　（1965）
疑問：前半、後半にしては、1年しか経っていない
(質問に対する解答：周囲の受け止め方は180度違うが、アレグザンダー自身は同じことをしているつもりだと考えられる。要求条件を満たすのがデザインである→一足飛びに見つかるものではない→要求条件の近さでグループ分けしていく→クラスタリングされる→ボトムアップでちょっとずつ集まった条件を1つの大きな建築にまとめる→これを言語化したものがパターンである→要求条件の集合をいくつかまとめたものをパターンと呼ぶ： 変化したのは、最初は中心となる設計者が存在してトップダウンで設計する、コンピュータの助けを借りる： それが建築家はユーザの手助けをするだけであり、建築するのはユーザである。：実現方法ががらっと変わった)
  
　　　オレゴン大学の実験（1975）
　　　　利用者参加で建築を進めると言っている
　　　　設計する側がどのようにすれば理想的か……要求要件が多すぎてデザインできない
　　　　→美しい自然都市のありようを建築に取り入れられるか？　→　利用者の参加
　　　利用者が建築へ参加できるようにするための仕組み：パターンランゲージ
 
　時を超えた建設の道　1979
　　パターンがどのようにして生み出され、どのように使うべきか
　　無名の質という概念
　　・自然都市と人口都市を2つ対立させて説明した
　　　自然都市には良い感じがある。人口都市にはない。この良い感じを無名の質と呼ぶ
 
別の観点：（本には出てこない）
　形の科学
　　中谷宇吉郎「科学の方法」（1958）
　　　科学とは量　計測するのは簡単。長さ、重さなど
　　　　これらに還元可能なものは科学しやすい　ー　形を科学で扱うのは難しい
　　　雪の結晶の成長を分析したい（形）
 
　ダーシー/トムソン『生物のかたち』
　　シマウマの模様がどうやって生まれるか
　　自然界には、あるルールに基づいて自然に生まれるかたちがある。
　　形を科学で扱うのは難しい。再現可能なものとして扱うのは難しい（トムソンはそれをしている）
 
　パターンはそれにトライしようとしているので、難しいことになったのだと思う。
 
書いてみての発見
　・デザインパターンの起源がよくわかった。ベックとカニンガムは深く関与している。
　　　（パターングループの）議論の成果物から生まれた
　・XPの起源
　　　いかにパターンランゲージをソフトウェア開発に取り込むか
　・Wikiの起源
　　　どのようにパターンを取り入れるか
　・Wikipediaの起源がわかった。思ったよりも関係が深かった。（単に道具として使っているのではないか）
　　カニンガムが作ったものをWikipediaがWikiらしく使うことで成長した、と納得した。
 
-----------------------------------------------------------------------------
扱っているテーマは多岐にわたる
　・今回はすべて扱うと散漫になると思うので、ソフトウェア開発に絞ろうと思う。
　→ それらに通じている2人を呼んだ
 
角谷
・ジム・コプリエンという人は、組織パターン、プロセスパターンを書く　
　→　ケントとウォードが研究中に影響を受ける（OOPSLAに呼んで基調講演をさせた）→（洗練）→XP
 
クリーン・コードの前書き：ジム・コプリエンが7ページで前書き（アジャイル、XP、リーン）
　平鍋−コプリエン−ベック
「パターンでやろうとしたことをアジャイルでもう一度やろうとした」（ジムも言っている）
 
コプリエン：パターンムーブメントは失敗した
　　　　　　→　パターンという言葉はデザインパターンの意味に固定されてしまった
　　　　　　→　アジャイルと呼び直し
 
（無名の質ー
 
生成（generative）とはなにか？
　時を超えた創造の原則
　　　　　　----
　　　　　　　+--- 本当は生成（できちゃったという感じ。
　　作ろうとして作るのではなく、なんとなくできちゃった
 
創造の原則は、釣り　（本当は生成の原則で良い）
 
創造と生成の違い
 
アレグザンダーはいわゆる近代建築を、それが発展しはじめたときに、全否定して（コンクリートとガラスはだめだ）、おれはモダンではない建築を取り戻す（人が自分の手で触れて自分の手で組み立てられるような建築）
 
どこかで見たような、懐かしさを覚えるような、そういうものを生み出すこと　!= 「創造」ではないね
 
XP、Wiki、パターンは、すべてつながっている
 
Nature of Order　（アレグザンダーが無名の質を説明しはじめた本）
 
金澤
 
　どうやればパターンランゲージを作れるか、が書けなかった。
　自分で発見して自分で書ける……すごく難しい
　　発見のための原則を考えた：15の属性で切り分けて考えよう（Nature Of Order　ー　まじめな形の科学。直接建築などへ応用できるものではない）
 
デザインパターンのときはC++を前提として書いている
　→　イテレータはパターンであると書いてある
Rubyという言語を作り直したとき、イテレータを自然な形で入っている
　→　構造保存変換
 
------------
 
自然が作るものを人間が作る
（原始共産制を、人間が制度化してみる、とか）
 
最初に欲しいと思っていたものと違うものができる（のではないか）
 
------------
 
XP
壊れないようにして新しくする
 
Scot Brain　（Emergent Design）
 
------------------
 
パターンランゲージによる住宅の建設
　アレグザンダー　（金の勘定まで出ている）
 
構造保存変換
・Structured Preserving Transformation (レオ)

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)(江渡 浩一郎)

サインしてもらった。そこにはさっそくメンテナンスビリティという言葉がアドリブで入っていて楽しい。

-意外と、老子を連想したのは間違っていないのかも。語ることの難しい領域について語るには、それなりの語法があるのではないか？ 中国4000年の歴史は伊達ではない。最古の著作群に語られた内容と語り方。

国の生成＝憲法は国家生成のためのパターンランゲージ

というようなことを想起する。

_ 記名された無名の質について考えてみる

昨日のジュンク堂トークセッションはえらくおもしろかった。

そこでひとつ考えなければならないのは、無名の質をどう捉えるか、だ。

一番だめなのは、ゆんゆん、として扱うことだろう。語ることが難しいことにこそ、意味があるのだから、それをうまく語れていないことをあげつらうのは、児戯に等しい。

そこで、ふたつのお互いに独立した、しかし確実に強力な関連がある事例に気づく。

ひとつは、アレグザンダーの盈進学園東野高等学校（そのパタン）で、もうひとつは宗左近の福島県立清陵情報高等学校 校歌で、どちらも特定の高校のカラーを決定しているのだが、どちらも通常は無名のものだ（自分の卒業した高校の校歌の作詩家や校舎の設計家を言える？）。

……あらためて読んだら、元々考えていた内容が成立しない気がしてきたから、書くのやめた。

フーガの[電子]技法(紙ジャケット仕様)(高橋悠治)

(バッハの作品に見られる無名の質となる予定だった)

_ 虎よ虎よ

NOMADはDAMON。

電池でノーマット 90日用 蚊とりブタ(-)

やっぱりぶたぶた。

_ マンガ注文しまくり

もやしもん(8) (イブニングKC)(石川 雅之)

こないだ2巻を読んでたら、ちゃんと池の話をしていたのに気づいた。

へうげもの(9) (モーニング KC)(山田 芳裕)

この作品を楽しんでいる人たちはどちらかというと治部少輔に近いのではないかと思うときがある。

ZOOKEEPER(8) (イブニングKC)(青木 幸子)

_ バージョンを上げると見方がガチになり、そして利用者は不便を強いられる例

Adobe Readerの8.1がインストールされていると思いねぇ。

ある日、PDFが届く。なんかいくつかコメントとか校正マークとかが入っている。それに対してこちらもコメントとか付けて行く。保存してOK。

同日同刻、まったく同じPDFをノートパソコンにコピーして、出先で同じようなことをすると思いねぇ。

しかし、そのノートパソコンはわりと新品で入っているのはAdobe Readerの9.1だ。新しい革袋には新しい酒が入る道理だ。

そこで、PDFを開く。

するとAdobe Readerは社会の窓を大きく開いて、何かを叫び出す。

この文書でAdobe Readerの拡張機能が有効になりましたが、この文書は作成後に変更されているので、拡張機能は今後使用できません。この文書の元のバージョンの作成者に問い合わせてください。

そして、何をどうしようが、注釈ツールバーを出すことはできない。あらかじめ出すように設定しておいても引っ込んでしまう。

つまり、9.1をインストールしたコンピュータでは、そのPDFに何かを付け加えることは不可能なのだ。（文書のプロパティを見ると、同一ファイルに対して8.1では「注釈」は許可、しかし9.1では「許可しない」となっている。同じ文書に異なる評価。これでは使いものにならんぞ（8.1が、と固くて完成していて自分で手を入れることを最初から想定することがない人は思うのだろうが、おれには9.1が使いものにならん）。

しかし、Adobe Readerは危険なプログラムの培養土になりやすく、アップデートしないとやばいことこの上ないことIEの如し、なので当然、最新版を使いたいというか、8.1はどこからダウンロードすれば良いんだ？

というわけで、ますますAdobeを嫌いになる。

_ Rubyのデフォルト引数

1.9はいろいろすごいな。

irb(main):001:0> RUBY_VERSION
=> "1.8.7"
irb(main):002:0> def a(x=0, y)
irb(main):003:1>  puts("#{x}, #{y}")
irb(main):004:1> end
SyntaxError: compile error
(irb):2: syntax error, unexpected ')', expecting '='
(irb):4: syntax error, unexpected kEND, expecting $end
        from (irb):4
        from :0

だったのが

irb(main):002:0> RUBY_VERSION
=> "1.9.1"
irb(main):003:0> def a(x=0, y)
irb(main):004:1>  puts("#{x}, #{y}")
irb(main):005:1> end
=> nil
irb(main):006:0> a(1)
0, 1
=> nil
irb(main):007:0> a(1,3)
1, 3
=> nil

_ 7ページでわかるパターン、Wiki、XP

先日のジュンク堂トークセッションで、角谷&懸田コンビの掛け合いで、実は、7ページでこの本の内容がわかる秘密兵器として紹介されていたのが、クリーンコードのコプリエンの前書きだ。

いや、それデタラメじゃねぇか、とあらためて読んで思ったが、でも、確かにおもしろい点は突いている。

Clean Code アジャイルソフトウェア達人の技(Robert C. Martin)

一体、コプリエンは前書きに何を書いているのだろうか？

印象深いのは、5Sだ。整理、整頓、清掃、清潔、しつけ。もちろん、クリーンコードという本の前書きなので、一言でまとめれば、「この本を読んで、きれいなコードを書きなさい」に尽きる。

これは、K&Kがetoさんからのアジャイルを始めるには何すれば良い？ という質問に対して、ちょっと考えただけで、「あいさつすること」と答えたことに通じるものがあるように思う。つまり、ささいなことのように見える、窓の汚れやヒビに気をつけろ、ということだろう。割れてから取りつくろうのではなく、いつもきれいにしておけば良いということ。

それにしても、あえて日本人という立場を離れて虚心に前書きを読んで言えば、日本のソフトウェア開発では、終始、コードに対して絶え間なき改善を施すリファクタリング先進国ということになる。日本と言えば、フジヤマ、ゲイシャ、カイゼン、なんだから、コードについてもカイゼン＝リファクタリングと、考えているのかな。

では、どうして工業製品で行えることがソフトウェア製品では行えないのかね？ 神は細部に宿るのだから、きれいなコードこそが重要だし、きれいなコードを生むのは、絶え間なき改善しかなく、今日の一針、明日の十針、早起きは三文の得なのだ。「かもしれません」がボルドなのが良い点だ。コード以外のものに気を取られているのだろう、きっと。

もちろん、私は依然として、広い視野で物事を考えることと、特にソフトウェアの有用性とドメインの深い知識とに根ざしたアーキテクチャ主導の取り組みの提唱者です。この本は、こうしたことをには（少なくとも明確には）触れません。この本では、より本質的な趣旨を扱います。

ソフトウェアにおいて、本質はどこにある？ もちろん、コードだ。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)(江渡 浩一郎)

それにしても、途中で2部と3部を入れ替えたから、目次の順（パターン、XP、Wiki）に対して、タイトルはパターン、Wiki、XPなのかな。とすれば、タイトルが最初にあったのかな、とか考えたり。

---

と、ここまで書いて、読み返すと、いくらでたらめとは言え、なぜ7ページのアンチョコなのかが、まったく見えてこないことに驚く。

パターン、Wiki、XPは、「時を超えた創造の原則」を考察した本だ。で、K&Kがその原則が7ページでわかる、としてクリーンコードのコプリエンの前書きを示した、ということだ。

創造というと、天地創造という4文字熟語に端的に現れているが、無から有を生じさせる活動を想起させる。

そうではなく、生成というと、すでにある何かが元になるように感じられる。

生成のための場というのは、ベムベラベロのオープニングの、なにやら液体に泡がぼこぼこしていて、膨張して、そこから何か得体の知れない3つのものが生成される壺のことだ（違うか）。いずれにしろ、元になる液体とかが必要で、しかも、そこにはなんらかのマジックが必要ともなる。

そのマジックというのは、新たな生命を吹き込む「気にさせる」もので、一般的には、気分の良さとか、やる気がむらむらとかそういうもので、そのような気分になるということは、そこに無名の質があるということだ。

と、いうような意味だと受け取った、おれは。

_ プログラムの創造

で、と上から続いて、プログラムの創造には、お手本となるアプリケーションがあり、そこに不満とかがあり、代わりとなるものを作るというのがあり、そうやって、フリーなOSとかフリーなコンパイラとかエディターとかが生み出される。

そうやって創造されたコードがフリーであれば、今度は、そのフリーなコードを元に別のアプリケーションが生成できる。

その生成のための重要な要素として、クリーンなコードを上げられることになる。きちゃにゃいコードは読めないか読む気にならないから、つまりは無名の質もなにもあったものではないから、何かを生み出すための肥沃な土壌の提供とはいかない、というように話が続く。

でも、クリーンなコードがあればそれで済むはずはない。

そこから何かを生成しようとするには、コードを読むことも必要で、そこで、コードを読むということについて、最初のお膳立てから、アプローチの仕方、アプローチするための登攀計画の立案、そのための地図の入手方法、そういったことを説明したものとして、RHG、というようなところに話は進むことになるのであった。

コードの書き方の本は、いろいろある。

それに対してコードの読み方の本は、そんなにはない。

アプローチの手段として、テストを作るという方法もあり、それは最近、翻訳されたわけだが、そしてそれは多分正しいアプローチだが、であれば、クリーンなコードと同時にクリーンなテストコードもあってしかるべきだ。

すると、パターン、Wiki、XP（あ、テストファーストを含んでいる）、となる。

レガシーコード改善ガイド (Object Oriented SELECTION)(マイケル・C・フェザーズ)

この本については、mumrikさんのエントリーを読むと良いと思う。Working Effectively With Legacy Codeとか、Working Effectively With Legacy Code(途中経過）とか、Lazy Getterとか、いろいろ。

_ 孑孑の続き

油を流して2日ほどは様子を見ていたのだが、効果はなさそうなのでしばらく放置していた（水の継ぎ足しはしていたけど、まじまじと覗きこまないと孑孑の存在は確認できない）。

今日見たら、一匹もいなくなっていた。

おそらく、元いた連中は羽化して飛んで行ったんじゃないかとは思うが（死滅した可能性もないわけではないだろうけど）、少なくとも、第2弾、第3弾は攻め込んではいない。

とすれば、水の表面に油が浮いていると、蚊はそこを産卵すべき場所とは認めないように思える。もちろん、産卵可能な蚊が、たまたまここ数日このへんをうろうろしていないという可能性もあるけれど。

というわけで、効果があったのかなかったのか、わからない。

_ アホウドリがやってくる

久々にバラードを読んだ。

楽園への疾走 (創元SF文庫)(J.G. バラード)

結構、時間がかかったのは、表現方法がひっかかるからだろう。それは悪い意味ではなく、味わい深いということである。

きわめて不快なお話である。

イギリス人の自然保護活動家の中年（これは重要な点となっている）女性と、彼女に惹かれるハイティーンの青年（親父は、どうやら核実験のときに被曝したことが原因で自殺。この青年の視点で物語は動く）、適当に成功している実業家、原爆の語り部たるに目覚めた日本人の植物学者夫妻（日本人の科学者は以前にも登場していたが、どのようなシンボルなのか。静かに怒って静かに死んでいく）、ヒッピーと訳されているが1990年代が舞台なのだからゴスと訳したほうが良いだろうななドイツ人達、ハワイ独立運動の活動家、筋金入りの自然保護活動家の女性とその親父、こういった人たちを見捨てられた軍事施設がある南海の孤島に住まわせる。

当然のように、物語は蠅の王様のような話になる。

しかし、年老いてもバラード、物語がどれだけステレオタイプになろうとも、興味は一貫して、ある状態におかれた人物が、その偏った考え方のために異常な適応をしてしまい、その結果、その異常な状態に魅了されて逃れられなくなる、という心理観察にある。どうあっても、脱出しないのだ。

それにしても、多彩な登場人物、二転三転する状況と気のもちようによって、舞台となった南国にふさわしく彩り鮮やかな物語であるが、たった3人がグレーのコンクリートと緑の草とほんの少しの土だけで構成された空間でうじゃうじゃする島のほうが、凝縮度が高いからだとは思うが、おれには好みだ。あるいはそうではなく、読んだときの年齢の問題かも知れない。

安部公房とずいぶん近い位置にいる作家なのだな、と気づく。

客観的に見れば、さっさと逃げ出せば良いだけなのに、またその機会はいつでも転がっているのにもかかわらず、その状態に留まり、さらに悪い状況へ陥る。それを支える、他人から見ればささいで、しかも現在の行動とは何の関係もなさそうな、トゲのようなものが脳みそに刺さっているために、そこから逃げ出すことははなから眼中にない。かくして、ますます異常な状況へ突き進んでしまう。

普遍的なテーマだ。

_ 神コピペ

コピペという言葉の意味が変化してる気がする。

_ enum

Javaでenum値をDBに格納するときに、intへ変換する。

public enum Encho {
    Hee(1),
    Huu(2),
    Hoo(3);
    private final int value;
    Encho(int n) {
        value = n;
    }
    public int value() {
        return value;
    }
}
...
statement.setInt(1, Encho.Huu.value()); 

で、ここまでは良いのだが、逆ができなくてしばらく悩む。

Encho e = (Encho)rs.getInt(1); // => error

そこでしょうがなく、自前変換メソッドを作ったが、本当にこんな方法しかないのかなぁ。

public enum Encho {
    Hee(1),
    Huu(2),
    Hoo(3);
    private final int value;
    Encho(int n) {
        value = n;
    }
    public int value() {
        return value;
    }
    public static Encho valueOf(int n) {
        for (Encho e : values()) {
            if (e.value == n) {
                return e;
            }
         }
         throw new IllegalArgumentException(n + " is not Encho");
    }
}
...
Encho e = Encho.valueOf(rs.getInt(1)); 

_ 日本と東京

青は藍より出でて藍より青し、と、東経の隣人には見えるらしい。

_ 懇親会

maicosさんにカヤック星人のその後について聞く。それにしても、JavaからRubyの人は、まさか自著の表紙がコモンズになるとは想像してないだろうな。

JavaからRubyへ ―マネージャのための実践移行ガイド(Bruce A. Tate)

で、おれは見たことないけど、見るにはどうにかしてinternal server errorを起こさせなければならないんだろうかとか訊いたら、こうすれば良いと教わった。が、500じゃなくて404なメッセージが出ている。でもナイスカヤック。(追記：本当は、internal server errorだという驚愕の事実)

でも、いまいち角谷さんの似顔画としては失敗しているような気がする。

JavaからRubyへと言えばこちらもどうぞ。初版あります(は明日というか今日だけど)。

JavaプログラマのためのRuby入門(arton)

_ 今日のRubyKaigi

ささださんが、今にも泣き出しそうに感じたのは、おれだけか？

（昨日の懇親会で、何気なくるびまの話を訊いたら（というか、今日のお題をすっかり失念していたのだが）、明日、終了のお話をするんだとかいってはぐらかされたが、終了ってそういう意味だったのか）。

_ 超人たちのWikiあるいはペディア(education)

江渡さんのパターン、Wiki、XPを読み終わって、振り返るに、おれは第3部のWikiが2つの意味でどえらくおもしろかった。

1つは、それが実装に関するトピックだということで、Wikiというソフトウェアについての考察だからだ。

で、問題はもう１つのほうにある。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)(江渡 浩一郎)

以前、山形浩生のアマゾン書評を読んでいて、やたらと印象に残ったのが、アイン?ランドの肩をすくめる巨人の評だ。作者も作品も初めて見かける名前だが、それにしても、題名が意表をつく。ニュートンが乗ろうとしたら、肩をすくめて、リンゴのように地面に落とすところを想像してみたり。

肩をすくめるアトラス(ランド,アイン)

アイン?ランドの代表作。長いし、小説としてはへたくそです。大仰な描写、延々としゃべりまくる饒舌な登場人物。すべては功利主義で進み、主人公の鉄道会社重役ダグニー?タガートは、ボーイフレンドよりも有能な男が目の前に登場するとあっさり乗り換えて、そのボーイフレンドも功利主義者なのでそれを平然と祝福するなど、失笑するような場面が満載です。

本書に人気があるのは小説として優れているからではなく、その思想に共鳴した人々が一種のカルトを形成しているからです。（中略）本書でも、有能な人は生まれてずっと有能、そうでない人はずっと無能な寄生虫、という描かれ方は一貫しています。

読みたくねぇなぁ、というわけで読まなかったのだが、しかし語呂の良さもあって、アインランドという名前は記憶に残った。

で、江渡さんの本に戻ると、

オプションや先物取引のトレーダーだったジミー?ウェールズは、……アイン?ランドという小説家?思想家の愛好家だったため、その思想を普及させるためのWebサイトをホスティングしたりしていました。

というくだりで、？となった。

有能な人と無能な寄生虫という考え方（こんなものに「思想」という言葉を使いたかない）の愛好家が、Wikipediaなのか？ でも、Wikipediaというのは、無能な寄生虫がよってたかってリンゴ（知恵の実）にワームホールを開けて行く作業で作られているのではないか？

という大きな疑問だ。

続く。

_ ロメオとジュリエット

ティアラこうとうで、東京シティ・バレエ団のロメオとジュリエット。

プロコフィエフの曲って素晴らしいではないかと、特にバイオリンで寄せて返すフレーズの曲で感じたが、作曲家だけの問題ではなく、テンポの取り方と強弱の付け方で、東京シティ・フィルがうまいのだと気づく。あと、いかにも新古典主義的な、タカタッタカタ、タカタッタカタというのが、ロメオとジュリエットだと初めて（多分）知った。この曲、えらく聴き覚えがあるのだが、いったいどこで聴いていたのかな？

演出は石板のようなものを組み合わせたシンプルな舞台で、ヴィンラントヴァグナーのリングを想起するが、実に効果的（と、後でわかるが、観ているときはオリジナルではなく、元々そういう演出なのだと思っていた）。特に、ジュリエットが家から抜け出して修道院を訪ねるところの演出がすばらしい。

最後のジュリエットが絶望してロメオにナイフを握らせて倒れるところとか、音楽の良さもあわせて、自分でも驚くほど心が揺さぶられた。

バレエは、やたら有名なイタリア映画とは違って、原作に忠実な、血の気の多いヤクザ一家の対立を軸にした不良のあんちゃんねえちゃんの恋物語に則した感じで、たかだか13だか14だかの小娘っぽさをうまく生かした演出。役作りがうまいのかも知れない。それにしても、嵐が丘とか、ロメオとジュリエットとか、ある程度のリアリズムで映像化すると、今ではチャイルドポルノになってしまうんだな、と、時代の変遷っぷりには驚かずにはいられない。

で、音楽もよし、舞踏もよし、でえらく気に入ったので、帰りにHMVでDVDをあさったが、モンテカルロのやつと、ルグリのやつしか見当たらず、さすがにモンテカルロはないんじゃないかとルグリのやつを買って帰って、うむ、おれは東京シティ・バレエ団の演出と東京シティフィルの演奏（指揮かも）のほうがはるかに好きだ（曲の組み合わせも）。それにしても、バレエでの曲の入れ替えって、同一性保持原則もへったくれもないんだな、とまたまた思わずにはいられない。

パリ・オペラ座バレエ - ロミオとジュリエット [DVD](ルグリ(マニュエル))

(悪くはないし、最後のジュリエットの演技はこれまた良い意味で豊かな表現だが、東京シティ・バレエの演出と演奏のほうがおれは好きだ)

_ RubyKaigi2009

というわけで、午後はこうとうのほうへ行ってしまったので、基調講演とかいろいろ見逃したのだが、それはしょうがないとして、（どっちも重要だし）、発表ではいろいろご迷惑をおかけして、ごめんなさい。

・昨日、DELLがいかれてしまって、画面フリーズ多発状態になることが判明（多分、例によってnVidiaじゃないか、とは疑っている。というか、まるで一時期のVIAのようなnVidia。VとIとAはspamのネタにも頻出する文字だが、実によろしくない）。

・しょうがないので、MacBook Pro17のVistaへ移した。

で、VGA出力がないことに気づき、DVI-VGA変換コネクタも用意して、万事OKと思ったら、いざ、会場でセッティングしてたら外部出力へ切り替える方法がまったくわからないことに気づく。唖然。（どのくらい想定外だったかというと、DVI-VGA変換コネクタを置き忘れてきたくらいだ。）

どうにもしょうがないので、ごとけんさんのマシンをお借りすることにしたのだが、こんだ、パワポ2007のままではだめなことを発見して、2003に変換してとかやっているうちに、時間は過ぎ去り、AKRさんと順番を交換していただいた。というわけで、AKRさんのセッションから観ようと10時から来られた方には申し訳ありませんでした。

（この後、Emacsを使ってメモを取ったりしていたら、AltがoptionでCommandじゃないわけだが、キーのでかさから、ついCommand-Xと叩くわけだ。で、それを叩くとモバイルセンターというのが起動されて、そこに外部モニタ出力設定があることに気づいたのだが、後の祭りの笛太鼓）

というわけで、発表資料。

このあと、ごとけんさんと、とは言うものの使い捨てでスクリプト書いてると、結局、メタなところで手作業の繰り返ししているわけだよな、というような話をする。プログラムとスクリプトの関係の逆転とか。プログラムをスクリプトで繋いで制御したりするのだが、でも、演劇とかだとプログラムの中にスクリプト（に基づく演目）が含まれているよね、とかうささんも交えて与太話とか。

それにつけても、スタッフのみなさん、参加者のみなさん、お疲れ様＆どうもありがとうございました。

_ RubyKaigi総論

・RubyKaigiが終わるや天空に7色の架け橋が浮かび上がった

ということで。

_ Ruby-1.9.1-p243のMSI

ダウンロードページ

インストーラパッケージを更新しました。見事にRubyKaigi会期中にリリースしたYuguiさんをはじめ、関係各位に感謝します。

_ Ubigraph

Ubigraphで遊ぼうと思ったが（LTがおもしろかったわけだが）、Windows用が無いのはともかくとして、OS Xでうまく動かない。サーバーは起動するのだが黒い画面のままで、デバッグモードにしてみるとGLUT Warning: GL error: invalid enumerantというメッセージが出まくる。が、このメッセージで検索しても何もわからない。

なんとなく、以前入れたghcのライブラリが影響しているような気もするが、ドキュメントには出ていないように見える。

というところまで。

追記：Snowleopard入れたら動く（見える）ようになった。良かったね。

_ Ubigraph続き

サポートにメールしてみたがあるはずのオートリプライもない。このとりつくしま(携帯の辞書はいいもんだ)のなさは、こうとうてきで、素敵だ。

で、Airにも入れてみたが同じく黒いままで、動いている基準がないので、根本的に間違っているのか見当がつかない。

帰ったら、Linuxボックスを作って試してみる。

_ Ubigraph

Ubuntu 9.04を導入してやっと動作するところを見られた。

というか、もう木曜日というより金曜日の朝だなぁ。

_ Emacsの文字

なんか、?\177という書き方が通用しなくて(Invalid read syntax: "?"となる)、普通に127と書かされたが（DELの文字コードだとわかると、何をしようとしているかもわかる）、Emacs22で?の意味が変わったのかなぁ。まるで、Ruby1.9みたいだ。

_ 2つのレシピ

Ruby3の校正をしている関係ということもないけど、翔泳社からRuby札幌グループの逆引きレシピを頂いた。

で、読んだ（目を通したというべきか）。

うーん、おれは高橋さん、青木さん、裕蔵さんのレシピブックのほうが好きだな。でも好き嫌いとかそういう感覚をレシピブックのような実用書に対して持つのは意味がわからないので、正確には、何か違和感を覚えるということだろう。

けれど、きっと、札幌レシピのほうが時代には則しているのだろう。それはRuby 1.9に関連したレシピ（文字コードのあたりとか）が出ているからとかそういうレベルのことではない。

この差を説明するのは難しい。

たとえば札幌レシピの項目には、「QRコードを生成したい」とか「サムネイル画像を作成したい」とかいった、それRubyのレシピなのか？ と感じるところがある。でも、実用性からいけば、もちろんレシピだからそういった項目があるのだし、ユースケースも容易に想像がつく。「memcachedを利用したい」とかいうやたらと狭い気がするレシピもある。

あるいは、RubyGemsやRakeの使い方だ。何しろ最初のレシピが「Rubyの便利なライブラリやツールをインストールしたい」で、次が「RubyGemsを使ってパッケージをインストールしたい」。

つまりおれが感じる違和感の正体は、高橋−青木−裕蔵レシピがまつもとゆきひろのRuby（というスクリプト言語）の本なのに対して、札幌レシピは、今のRuby（というビジネスに利用されるシステム）の本だという点にあるのだろう。パラダイムの形成を見たぜ、ということかも。

Ruby 逆引きレシピ すぐに美味しいサンプル&テクニック 232 (PROGRAMMER’S RECIPE)(島田 浩二)

（るびきちさんの本は、その対比でいくと、高橋−青木−裕蔵レシピをさらに個的に先鋭化したような内容なのだろう、と思うが、読んでいないのでわからない）

別の言い方をすれば、かぶるところとかぶらないところがあるんだから、両方もってりゃ良いとも言えるかな。さすがにオーバースペックかも。

Rubyレシピブック 第2版 268の技(青木 峰郎)

(おれが持っているのは赤いやつだけど)

おれの手元にあるレシピブックについて言えば、楽しみながらRubyでスクリプトを組んだりなんとなく読んだりするなら、高橋−青木―裕蔵レシピ、仕事モード（本番システムモード）でRubyを使いまくっているのなら札幌レシピという感じかな。

_ いろいろな考え方

まともでないものとまともなものという切り口はおもしろい。

対比1)

zsh | sh

対比2)

Linux | BSD

対比3)

Ubuntu | Slackware

対比4)

vc | gcc

対比5)

もやしもん | ぽけもん

もやしもん 親子で楽しむ8巻 (KCピース)(石川 雅之)

(家には子供がいるからこっち……というわけはない)

_ きれいなリゴレット

知り合いの家でフローレスがマントヴァ公爵を演じたリゴレットのビデオを観る。

リゴレット役（ユーゴのあたりの人らしい）もジルダの人もフローレスも、みんなきれいな声で、演出もきれいに抽象化していて、ルイージの指揮（苗字なんだな）も明瞭で、つまりみんなきれい。

で、おれはきれいなヴェルディは好きだということを知る。

それとは別に、物語の中でおれが一番心惹かれるのは、そんな刺客道にもとることができるけぇ、とリゴレットを殺して金を奪えばいいじゃんと頼む妹を一喝するスパラフチレのプロ意識だ。

_ 諸学

なんとなくノヴムオルガヌムを読み返しているのだが、諸学の大統一理論を導かんとするヴェルナムのフランシスの意気??たるさまにあらためて深く感じ入る。

_ 今日も虹

垂直に伸びて消えて行く

_ ベーコンを読んでみたり

なんとなくノヴム・オルガヌムを読み返すと、400年近く前に書かれたとは思えないようなことが書かれていて、鼓舞されるよりもむしろ暗然たる思いにとらわれるのだが、にもかかわらず、60歳くらいになって発表しているということ（20代のころに下書きしてたらしいが）に、力づけられないこともない。

にしても、序言ひとつとっても、色あせないことはなはだしい。いかに、人類の歩みというものがゆっくりとしたものかということでもある。

たまたま或る一人の大胆な知能をもち、かつ方法の簡潔のゆえに人々に迎えられ好評だった人が出現し、外見上或る技術を作り出し、実際上は昔の労作を駄目にしてしまったからである。ところがそうしたことは、労作の安易な使用と新たな探求の嫌悪およびもどかしさのゆえに、後の人々に感謝されるのが常なのである。

というたぶんアリストテレスについて語ったことは、まるでビルゲイツについて語っているかのようであり、かといって

ところがもしここに人あって、他人の意見にも自己の意見にも縛られず、自由を愛して、他人も自分とともに研究することを欲する気持ちであったとしても、なるほど彼らは心情的には立派だけれども行動的には力なかった。というのも彼らは単にもっともらしい理由を求めてきたように思われ、かついろいろな論拠の渦に振り回されて、どうでもよい研究の自由によって、探求のきびしさを骨抜きにしてしまったからである。

あるいは、

そしてさらに経験の波浪にあえて立ち向かって、ほぼ職人的に慣れてしまった若干の人々も、やはり経験そのものの中で何か手探りの探求を行い、確かな法則によって経験に仕えることをしない。いやさらに大多数の人は、何か1つの発見を掘り出すことができれば大したことだと考えつつ、つまらない課題を自分の仕事にした、こうした狙いは不手際でもあれば貧弱でもあるのだが、というのも何びとも或る事物の本性をば、そのものの中だけは正しくもしくはうまく探求し尽くせないもので、多くの実験を骨折っていろいろ変えてみた後にも静止することなく、さらに先に進んで問うべきことを見出すものだからである。（この後の投光的実験でなく成果的実験をしやがりやがってのような個所は痛烈だが面倒になったのでここでおしまい）

なんとなくikegamiさんが言いそうなことでもある。(追記：なんかすみませんというのが偽らざる気持ちではあるが、こう返してくれるというだけで、おれは好きだなぁ。ありがとうございます。ベーコンに戻ると全巻序言からひとたび本文序言に入るや、「精神の予断」と「自然の解明」どっちもありなんだからまあいいじゃん、でもおれと一緒に後者の道を進む人も出て来いよ、と言いだして、まあそのあたりも含めて。知は力の知は多分前者)

で、ヴェルラムのフランシスことベーコンは、帰納法について説き、

ところで今や、自然解明の技術そのものを提示する時である。その中で我々は最も有用で最も真正な法式を説いたと信ずるけれども、しかしそれに絶対的必然性、もしくは完全無欠を認めたわけではない。というのも我々は次のような意見だから、すなわち、もしも人々が正規の、自然および実験の誌を現にいま持っていて、それを熱心に研究しかつ自分を二つのことに仕付けて、1つには在来の意見および概念を取りのけ、二つには精神をば、最も一般的なものおよびこれに近いものから、一時遠ざけることができたとしたら、人々は精神の固有のかつ生まれながらの力でも、何ら他の技術なくとも、我々の解明法式に思い付きうるはずなのである。

と、筆をいったん引っ込める。

にしても、すでに帰納法を学んで400年になるのにもかかわらず、相変わらず序文でベーコンが嘆いたあれやこれやが大して変わらない（もちろん、はるかに前進はした位置にはいるということは間違いのないことであるが）ということは、不思議なことでもある。

ノヴム・オルガヌム―新機関 (岩波文庫 青 617-2)(ベーコン)

_ ファラデーの伝統

土曜日に文京シビックホール（なんで区民講堂って言わないんだろう？）で、英国科学実験講座クリスマス・レクチャー2009に子供と行った。

第20回とか書いてあったので、子供に、ファラデーの国だからこういうのをやってんのかなぁとか言ってたら、もらったプログラムにまさにファラデーが始めたとか書いてあって、おおそうだったのかと納得する（妻が申し込んだので、なんだか良くわかっていなかったのであった）。

ロウソクの科学 (角川文庫)(ファラデー)

（多分、寺田寅彦は『茶わんの湯』を同じ精神をもって書いた（意識して書いた）のだと思う）

で、今回は子供のためのコンピュータサイエンスに対するとっかかりとなりそうなお話ということで、ページランキングとかPKI、パターン認識といったことが取り上げられていた。

元々子供（小学生くらいだろう）を対象としたレクチャーをさらに非英国人向けにやるということで、おそろしくわかりやすい英語で話すので、むしろ英語のヒアリング学習に良いなぁと、通訳なしで聴いていたが、それでもわからないところはやはりわからない。

で、そこでネットワーク渋滞について取り上げていた。

プログラムには「韓国のソウルにつながる3つのトンネルのうちの1つを閉鎖したら、交通渋滞が改善された」という例が出ている（その場でソウルの話をしていたかどうかは分からない程度にしか聴き取れていない）のだが、最初に

「グレイのパラドックス」と呼ばれるとても不思議な現象があります（右の図）。A市からD市へ行くのに何分かかるか考えてみましょう

とある。

でも、どうもBraess' Paradoxのことのようだ。

（つまり、おれは、すでにクリストファービショップ先生が「ブレイス」と言っていたか「グレイ」と言っていたかは覚えていない）

調べるとグレイのパラドックスとはイルカの泳ぎから来たもので流体力学のほうで使われているものらしい。

それとは別に経路の距離と帯域、分散に関するグレイさんの研究もあるのかも知れないが、単にプログラムの間違いなんじゃないかなぁと思うのだが、問合わせ先とか出てないな。

_ ドンキホーテ

一幕目ではじめて退屈しなかった。キューピッドと子供たちが良かっただけじゃなく指揮も良かったのだ。

主役二人も良く飛び良く浮き良く回って楽しかった。が、名前は忘れた。

追記：バレエの主役2人とは宿屋の娘のキトリとカリスマ床屋のバジルの2人。ドンキホーテは二人の結婚を認めさせる役。

_ hash -r

Linux（というか、OSXでも同じ）で、最初なんとなく、rubyと叩くと/usr/binのやつが起動されて、当然のように古くて、まあ野良ビルドするかと考える。

$ ruby -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]

で、ftpして./configureしてmakeしてmake testしてsudo make installする。

$ ruby -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]

はて面妖な。

$ echo $PATH
/home/arton/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin……

どうみても/usr/local/binが先なのだが。

$ /usr/local/bin/ruby
ruby 1.8.7 (2009-06-12 patchlevel 174) [x86_64-linux]

だよなぁ。

$ ruby -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]

はて面妖な。

$ which ruby
/usr/local/bin/ruby

だよなぁ。

$ ruby -v
ruby 1.8.7 (2008-08-11 patchlevel 72) [x86_64-linux]

はて面妖な。

というときは、bashが起動したコマンドを覚えているのが原因で、そのおかげで多分、PATHをたどる回数もぐっと減るはず。良く使うコマンドを良く使っていれば。

で、上のようなことをやって、既に起動してしまったコマンドを後から別のパスに置いた場合は、bashのhashを初期化する必要がある。で、それが

hash -r

別にバッシュのハッシュという韻を踏みたかったわけではない(でも面妖という怪しい言葉は使ってみたかった)。

追記：csh、zshだとrehashとなるので、knuさん曰く

kshやbashでも alias rehash="hash -r" しておくとcsh系(zshを含む)との齟齬がなくなって便利

僕はbashメイン（生kshあり）なので、このエイリアスはしないと思うけど、参考まで