日々の破片

_ OData

どうにもかんとも気持ちが悪いOData。

気持ち悪いという感覚を重視すれば、こんなものは使わないほうが良いのだが、さてどうしたものか。

_ 対語の非対称性

冬に備えて緩効性の肥料を与えろというような事が説明書に出てたので、肥料を買って与えたのだが、緩効性とういのは妙な言葉だな。

B003STEOKM

対語は速効性だと思える。

という事は、速と緩は対概念だ。

でも、速いの反対は一般には遅いじゃなかろうか。拙速の反対は巧遅だ。

でも、早番と遅番ってのがあるから、遅いの対は早いのほうかも。

でも、早婚に対して晩婚ってのがある。ということは、早いの対は実は晩いだ。

でもしかし緩慢の逆は迅速だから、すると、緩の対は迅で、速いの逆は慢いだ。

にもかかわらず、慢いって、何とよむかわからない。

遅かれ早かれというが、似た言葉に早晩ってのもある。兵が尊ぶのは神速で、将が尊ぶのは仏緩だ。でもそんな言葉は無い。

と、いろいろ考えてみても、緩の対は早にはならないものだな。

が、緩急あざなえる縄の如しと、急が急浮上。だが残念、緩浮上なんていう言葉は無い。急行の対はしかし鈍行。鈍重(どんちょうだと思うのだが、iPadの変換器によると、ドンジュウらしい。まさに鈍重、だが大辞林を引いたらドンジュウが日本の言葉) の対は尖軽、しかしこの言葉も存在しない。でも鈍器の対は鋭器。尖器ではない。

_ MicrosoftのAPIの謎を推理する

ODataの$filterを書いていて謎現象に苦しむ。

最初、Fooテーブルのbarカラムが32のやつを読もうと次のように書いた。

/FooBar.svc/Foo(bar='32')

するとエラーになって、どうも複合主キーの場合は()に主キーはすべて書かなければならないようだと気付く。で、次のように書く。

/FooBar.svc/Foo?bar='32'

書いたつもりで何か間違えていたのか、とにかくエラーになって、しょうがないので、ODataのドキュメントをちゃんと読んでみた。

で、Filter System Query Option ($filter)のOperatorを見ながら、$filterというのを使えば良いのだな、と次のように書く。

/FooBar.svc/Foo?$filter=bar Eq '32'

が、エラーとなる。

何度も表を見て、オペレータがEqなのを確認して、もう一度、二度、三度やってあきらめた。

嘘ばかり書きやがって。で、2番目の方法に戻してうまくいったのかなぁ。

後になって、やはり$filterを使わなければならなくなって、再度見返して、Exampleのところを見て驚く。オペレータはEqなのに、Exampleにはeqって書いてあるじゃん。で、

/FooBar.svc/Foo?$filter=bar eq '32'

だとちゃんと答えが返ってくるではないか。

この表を書いたやつは、Operatorっていう言葉をTitleと誤解してるんじゃないか！ ぷんぷん。

で、それはそれとしてWordで書き物していて、例によってgetFooBarと打ち込むと、WordがGetFooBarにわざわざ直して赤い波をつけてくれるから、インテリタグとかいう不細工なやつを使って元に戻していて、なぜ、ODataの表でOperatorに嘘が書いてあるのかに思い当たる。

おそらく、あの表を書いたやつは、Operatorには正しくeqと打ち込んだに違いない。しかし、Wordが気を回してEqに変えて、それに気づかずにHTML化したのだろう。きっとそうだ。

そこで、なぜ.NET Frameworkのメソッドやプロパティが不細工に大文字で始まるのかについての不思議が氷解したような気がした。

PASCAL出身のデザイナーが悪いのではなく、おそらく、APIを決めた連中はちゃんと、disposeとか、notifyとかgetDisplayInfoとか定義したに違いない。しかし、彼らのツールは仕事柄じゃなくて勤務先の都合でWordだから、DisposeとかNotifyとかGetDisplayInfoとかになってしまって、しかしそれに気付く余裕もなくどんどこ記述しては実装者に仕様を渡していくから、実装者はドキュメント通りにDisposeとかNotifyとかGetDisplayInfoとかにしてしまって、気づくともう後戻りはできない状況になっていたのだろう。

得心した。

【旧商品】Microsoft Office Word 2010 アカデミック [パッケージ](-)

アカデミーパックは安いな。（APIが汚くなるというデメリットはあるが、ワープロとしてのできは良いとは思う）

_ ピラミッドの目

子供がダンブラウンがおもしろいので、これを読めとロストシンボルを貸してくれたので読んだ。

ロスト・シンボル 上(ダン・ブラウン)

曰く、何がおもしろいかと言うと（と、最近は美点を説明するようになった）

1. 常に時間との闘いがあり、切迫感がある。この物語の中でも全体の時間とその間に細切れに設定された時間がある

2. 追いかけっこが常にあり、その緊迫感が1と併せて盛り上がる

3. 敵対する側の描写が挟まり、その複眼的な視点によりああそう来るのかという意外性が形作られてそれがおもしろい

4. 暗号のような謎が提出されることで、その謎をどのように解析するかの知恵の発動が興味深い

とからしいが、それに加えて、歴史的建造物などに対するトリビアがおもしろいというのもあるかも。

で、実際、どえらくおもしろくあっと言う間に読み終わるわけだが、存外拍子抜けというか、ああ、これは日本じゃうけねぇかもなぁ感が残った。

で、実際にアマゾンから書影を引っ張るために眺めても、あまり評判も良くないようだ。

ロスト・シンボル 下(ダン・ブラウン)

なにしろ、下巻のほうには8人のレビューがあるのだが、上巻の26人に比べるとずいぶんと少ない。世界的ベストセラー作家のエンターテインメント小説としては、大してアピールしていないと言えるだろう。

理由は2方向から考えられる。

おれのがっかり感は、おれの異文化受容性によるものらしい。一番の緊迫を生み出す理由が、おれにはまったく理解できない。それは世の中には愚かな人間が存在することは知っているが、それにしても、あまりにもどうでも良いことに感じる。そんなことのためにCIAの偉物が駆けずりまわって大騒ぎするというのがむしろ驚きというか。が、おそらくそれはおれの感覚の問題なのだろうということでそれは良い。というか、不思議に思って子供に「あのくだらない理由で大騒ぎしているってことで納得した？」と訊いたら、やはりそこはスルーしていたらしいから、物語の大山場の種明かしが、大山鳴動ネズミ零匹みたいなもので、これは結構効いているんじゃないかなぁ。

異文化受容に関する小話が本書の最初のほうに出てくる。主人公のラングドンが大学でいろいろな宗教の説明をしていると、学生たちが偏見丸出しにするので、次のように語る。「諸君、では私の属するカルトについてどう感じるかね？ そのカルトは古代の太陽神ラーの祝祭の日になると、古代の拷問具の下に跪いて、血と肉体の儀式のための象徴物を貪り食らうというものだが」。で、だからどうした？ とかふつうに感じると思うのだが、物語上はインテリなはずの学生たちがいっせいに恐怖におののくというように描写しているから、物語の前提として、少しでも異端的なものを差別するのが当たり前の社会である、ということがあるのだろう。それにしても、極端な前提だなぁ。

もう一つは、おそらくそのほうが重要なのだろうが、どれだけアメリカの建国の歴史（というか、時代精神というか、ジェファーソンとかフランクリンとかワシントンが傑物揃いだったか。おれはペインを加えたいけど）が知られていないか（したがって興味を惹かないか）ということと、存外フリーメイソンに関する陰謀論が知られていないということだろう。したがって、扱っている題材が大仰なわりにほとんどの読者がまったく興味を持てないのかも知れない。せっかく、主人公の一人は日系のすごい人なのだが、それはアピールポイントにはならないしな。

でも、おれはそっちのほうはそれなりに楽しめた。

陰謀があるかどうかはどうでも良いが（レッセフェールのほうがむしろ富が増えるので妙な陰謀とかは巡らさないだろうと思うけど）、確かに本書の影の主役たるソロモン一族のような一族は世の中に存在するらしくて、その昔、広瀬隆の描いたロスチャイルド本とかは興味深く読んだ覚えがある。それで、ああ、確かにそういう一族ってのが世の中にいるなぁとか納得してみたり。

赤い楯 ロスチャイルドの謎1 (集英社文庫)(広瀬 隆)

あるいは、東京タワーの根本に確かに存在しているロッジとかを眺めたこともあって、本当にフリーメイソンってあるんだなぁとか。でも、すぐ近くの霊友会のほうがよっぽどおれの生活圏に対して良くない影響があるようだけどな。石原とか。

それにしても、アメリカの中心的な建物に単なる樵（比喩だけど）の正直少年が神格化する画が掲げられているというのにはびっくりした。そんなものがあるとはねぇ。テクノロジーと宗教の融和ってのがアメリカなのか。

フランクリン自伝 (中公クラシックス)(フランクリン)

(それにしても、まずはこれを読んでからだ、という気にはなる）

_ WCF Data Service

最近の傾向だと思うが、社内にファイアウォールを導入して基幹システムネットワークとオフィスのネットワークを分断しているシステムに出会うことがある。

このようなシステムに既存のソリューションを適合させる事を考えると、WCF Data Serviceは相当良いところをついている。

が、何点か引っ掛かっている。

インターセプト可能なポイントが少ない事と、情報の分散だ。

とりあえず、クェリストリング指定でJSONで返す方法を調べて、属性で介入するコードが提供されていることはわかったから、それを読めば、シリアライズする方法はわかるだろう。

もう一点はキャッシュで、DataServiceクラスの唯一の仮想関数を使った介入を試すと、独自に設定したEtagが悪さをして、リクエストが40xのエラーではじかれる。介入して、リクエストオブジェクトからif-not-matchを削除してやっても、どうも与えられているのはクローンらしく、効かない。

WCFサービスを作ればそのあたりのハンドリングは簡単だろうが、データサービスの雛形生成の強力さが失われてしまう(サービスからデータサービスへリクエストするのは馬鹿げているし、かと言ってコンテキストをインポートするのも無駄だ。とすると、普通にADO.NETを使うことになってしまう)。

さて。

·HTTPモジュールを使ってjsonをサポートする例：

JSONP and URL-controlled format support for ADO.NET Data Services

結局、HTTPモジュール(ASP.NETのフィルタ)を記述するしかないのか。

·こっちの方がきれいだ。jsonpattribute

-

IDispatchMessageInspectorを実装して、フォーム認証のクッキーを確認する、アプリケーションレベルのアクセスログを行き返りで採る。リードオンリーキャッシュを実装するとかすれば良さそうだ。

_ F#入門はクリスマスに来るそうですよ

荒井さんたちが執筆しているF#本ですが、アマゾンでは「並列」という字がついていますが、もう少し概要的な内容を含む入門書になるようです。

実践 F# 関数型プログラミング入門(荒井 省三: いげ太)

（でも実際の書影は次のようになるらしい）

と、紹介はじめてるけど、いいんだろうな？

1章が、まず意識合わせの章になっていて、関数型言語が出てきた背景や特徴について俯瞰的な説明があります。これはおそらく意味があって、CやRubyやJavaやVBのように、誰でもなんとなくわかっている言語とはやはり異なるわけで、どういう特徴があるのかとか、おそらく読者にとっての既知の言語とどう考え方が違うのかを明らかにしておくのは重要でしょう。特に、読者のターゲットをVisual Studioの利用者と想定したとすれば。

2章は、さらにF#の特徴についての概説（と、対話型シェルの起動方法など）。

ここまでで約60ページ。

で、3章が「F#へようこそ」で、本格的に言語入門、しかしプログラミング入門のための序章としてF#（およびF#プログラミング）の特徴説明となります。

3.1がHello World。3.2が電卓。関数と演算子（といっても関数のはずだけど）の簡単な紹介。3.3でコメント。

で、いよいよ本当にF#のプログラミングに入っていくわけですが、3.4が「itの正体」。なるほど、こうくるのか（ふうむ）。

で、3.5で「変数束縛」。この書き方も一つの方法だなぁ。代入という言葉は使っていません。したがって、代入という概念を知っている読者は、それとは異なる概念だと（たぶん）解釈してくれることを期待しているのでしょう。

3.6「初めての関数」。3.5で示した変数束縛によって右辺の関数が束縛されることを示すと同時に、apply（適用）という用語を提示。

3.7で「ローカル変数」。ここで、関数内での変数のlet束縛（トップレベルのlet束縛をlet宣言、ローカルでのlet束縛をlet式としているけど、そう呼ぶものなのかな）。

ここまで来るとexpressionとstatement、declarationについて話せるので、3.8が「式と文」。F#はstatementはdeclarationのみ。つまり、手続型言語ではないから、文はなくて式で構成するよ、という説明があります。でも、CやC++やJava……と手続型言語を並べて最後におまけにRubyと書いているけど、Rubyにはstatementと呼べるのは、えーと何があったかな？ 答：while, until, while 修飾式、until修飾式 それから、and, or, not, if/unless/rescue修飾式。ただし、Rubyの説明上はこれらもすべて式であって、ただ値を返さなかったりメソッド引数に指定できない（したがってstatementとみなすことができる）のでちょっと違うかなぁとか感じます。でも、手続型言語なのは正しいわけですが。

で、3.9が「ファーストクラス関数」（この表現はなんか引っ掛かる）。fun式を使うことで関数リテラルを記述できることをこう呼んでいるようですね。

3.10で「束縛≠代入」として、束縛とは何かを説明しているけど、ここは論議を呼びそうな内容。言いたい（強調したい）ことは、F#では変数に対する再設定ができないということなのだろうけど、そのために、代入可能な変数は容器、それに対して……という説明をしている。でも、参照主体の言語のほうが多いご時世だから、そもそも容器型の説明そのものが最近ではされず、むしろラベルによる説明が多いわけなので（そうでもないのかな？）、むしろ混乱を招く恐れを感じます。ただし、容器やラベルをそういった手続型言語の良くある説明を無視して、この本のこの章の中で定義された説明のための用語として読めば、書いてあることは正しいと思います。

3.11は「シャドウイング」。なんでわざわざ一項を設けたのか不思議ですが、積極的にスコープが変わった場合に名前を再利用するように勧めている（それは再代入の代替となるからという理由）からかなぁ。とすれば、親切なのかも知れません。

で、4章以降で本格的なF#のプログラミングが始まります（のだと思うというのは、リークされた見本は3章までなので）。

_ メモ:WCF Data Serviceのstored procedure

最後のsqlが埋め込みだと、どういう方法か、スキーマを得て、複合クラスを返り値として生成してくれる。

最後が文字列を引数としたexecuteだと、戻り値がないというようなエラーになる。ここで、手動で複合型を定義するとうまく処理されないことがある(表面に見えないコンバータ情報に問題がありそう)。この場合、executeをコメントアウトしておき、ダミーで同じ型というかカラムを返す埋め込みsqlを記述しておけば、変換可能な複合型が生成される。後でstored procedureの方は元に戻しておく。

500が返る場合は、そのままではログがなく、原因を調べられない。以下のようにメソッドを組む。

[WebGet]
public 複合型テンプレート stored_procedure_name(..仮引数名はクェリストリングのキーと一致)
{
    try 
    {
        return CurrentContext.stored_mapped_method(...);
    }
    catch(Exception e)
    {
        eをログへ書き出す
        throw e;
     }
}

_ C#の引数と返値

public class Fun
{
    delegate int x();
    static x cx(int n)
    {
        int i = n * 10;
        return () => { return ++i; };
    }
    static x dx(x xx)
    {
        return () => { return xx(); };
    }
    public static void Main()
    {
        var fun1 = cx(10);
        System.Console.WriteLine(fun1());
        var fun2 = cx(20);
        System.Console.WriteLine(fun2());
        System.Console.WriteLine(fun1());
        System.Console.WriteLine(fun2());
        var fun3 = dx(fun2);
        System.Console.WriteLine(fun3());                
        System.Console.WriteLine(fun2());
        System.Console.WriteLine(fun3());                
    }
}

C:\test>fun
101
201
102
202
203
204
205

_ 漢数字からアラビア数字

以前、どこかで漢数字からアラビア数字へ変換するという問題を見かけたが、実際に必要になって書いてみたら実に気に食わない。あのとき、ちゃんとうまい解答例を見ておけばよかった。

ここでやりたいのは単純で、一～五十くらいまでで、十一とか三十一とかの表記となる。これを1～50、11とか31とかに直す。

最初こう書いた。

KINDEX = "十一二三四五六七八九"
ARABIC = "0123456789"
def kj_to_arabic(s)
  r = ''
  s.each_char do |c|
    r << ARABIC[KINDEX.index(c)]
  end
  if r =~ /¥A0(¥d)¥Z/
    "1#{$1}"
  elsif r == '0'
    '10'
  else  
    r.gsub(/0(¥d)¥Z/, '¥1')
  end  
end

たかがこんなことに//が2回も出てくるのも気に食わないし、なんか不細工だ。

そこで次に//を使わずにこう書いてみた。

KINDEX = "十一二三四五六七八九"
ARABIC1 = ['10', '1', '2', '3', '4', '5', '6', '7', '8', '9']
ARABIC2 = ['1', '1', '2', '3', '4', '5', '6', '7', '8', '9']
ARABIC3 = ['0', '1', '2', '3', '4', '5', '6', '7', '8', '9']
ARABIC4 = ['', '1', '2', '3', '4', '5', '6', '7', '8', '9']
def kj_to_arabic(s)
  case s.size
  when 1
    ARABIC1[KINDEX.index(s)]
  when 2
    ARABIC2[KINDEX.index(s[0])] + ARABIC3[KINDEX.index(s[1])]
  else
    r = ''
    s.each_char do |c|
      r << ARABIC4[KINDEX.index(c)]
    end
    r
  end
end

最初のよりはましな気もするが、あまりにもアドホックに過ぎる。(追記:3文字なら2文字目は無視すればいいな。)

というわけで、よりスマートに書くにはどうすれば良いのだろう？

_ 漢数字からアラビア数字（続）

ebanさんから教わってゴルフ場を見たけど、あまり役にはたたなくて残念。

ゴルフなのだからある意味当然なのだが、1.8の動作と文字コード（utf-8）に依存し過ぎている。

kskさんのは、やたらと短くて(なんと92バイト)読みやすそうだから見てみたが1文字文字列.hashがその文字の値になるという1.8の振る舞いを利用しているからちょっとだめだ。

（ゴルフ以外だとsumimさんがオーソドックスなやつを出してくれている。）

でも、ゴルフを見ていて、文字列→文字列と馬鹿正直にやるよりも、文字列→整数→文字列とするほうが楽そうだというのはわかった。

で、こんな感じになった。

KINDEX = "十一二三四五六七八九"
ARABIC = [ 10, 1, 2, 3, 4, 5, 6, 7, 8, 9 ]
 
def kj_to_arabic(s)
  n = 0
  s.each_char do |c|
    if n < 10 && n > 0
      n *= 10 
    else
      n += ARABIC[KINDEX.index(c)]
    end
  end
  n.to_s
end

_ 荒井さんのOSSとの付き合いのコラム

荒井さんが『荒井省三のBlog』で『Ruby環境構築講座 Windows編』を取り上げてくださったなぁとか思っていたら、それがITmediaのほうにも『Windows上でOSSと付き合っていくために』として転載された（荒井さんによると『MSDNブロガーの視点』というタイトルのページは、ITmediaが独自の判断でピックアップするらしい）。

初出の時点で、荒井さんらしい坦懐な語り口の良い文章だなぁと（おれの本を取り上げているからとかいったこととは別に）感じたので、それをさらにピックアップする人がいるということを嬉しく思った。

_ ポケモンの日々

子供がポケモンでWiFi使いたいとか言うのは良いとして、さすがにWEPのセグメントを組んだりするのは面倒だし、クリスマスプレゼントということで、DSi（WPAをサポートしている）を買ってやった。

ニンテンドーDSi ライムグリーン【メーカー生産終了】(-)

で、そうすると元々は自分用に買っといたわけだが長期貸し出し状態になっていたDS Liteが戻ってくるので（実際はもう少し複雑だけどそれはどうでも良い）、おれもポケモンでもするかと、子供が黒なので白を買ってみる。

ポケットモンスター ホワイト(-)

そして、危惧した通りに、はまりまくる。

元々Wizardly（MSX版）にはまりまくった過去があるだけに、物語はどうでも良く、ひたすらレベルアップだけをしまくることになるというのは目に見えているので、このタイプのゲームはやらないようにしていたのだが、まあしょうがないなぁ。

ただ、砂漠のところでほとんど必ず不快なワニが出てくるのでうんざりしているところ。アステカ風な妙なのは好きなのだが（先頭に置いている岩型のやつが「うちおとす」とかいう技で大抵の場合、一撃で沈めてくれるからだ。

で、ポケモンがおもしろい（あるいは今風ということなのかも）のは、WizardlyにしてもUltimaにしても（ドラクエとかも同じはず）プレイヤを中心としたチームはほぼ固定された状態で冒険をすることになるのだが、ポケモンの場合は、コアになる何匹かを残して（と、おれはやっているが、子供を見ているとそれすらないように思える）ころころ入れ替えていくし、また入れ替えが難しくないようなシステム（学習マシンとか持たせているだけで他のメンバの戦闘で稼いだ経験値を譲られる仕組みとか、途中で捕まえるポケモンはレベルがそれなりに高くなっていたりすること。これはWizardlyでパーティの1人を消失した場合に、マーフィーの亡霊の部屋へ延々と戦いに行かなきゃならないシステムとはえらく違う）になっていることろだなぁと思った。

でも、それはそれでおもしろい。確かに、Baneあたりだと全種族でパーティ組んでみたくなったりしたしな。

_ 正しいインセンティブ

青木さんが訳したTEDのやつを読む。

クリエイティブで素晴らしいパフォーマンスを引き出すにはどうすれば良いか?

おれには、ここで語られていることは次のように読める。

給料はそれほど高くなくても良いが、リラックスできて安心感があり、適度な権限と解決すべき課題があること。

なるほどね。

だから、年功序列、生涯雇用は、ばっちり機能していたわけだ。それは理にかなっている。

なんでそれをやめさせたい奴がいるのかな?

_ スカイツリーは高度経済成長の夢を見るか

こないだ髪を切りに行ったら、髪結いのおっさんが、俺、最近、良くスカイツリー見に行ってんだよね、と話し掛ける。

えっもう営業してるんですか？ と訊き返すと、いやもちろんまだなんだけど、行くたびに少しずつ高くなってるんだよ、それがなんていうか、見上げてると夢があるんだよねぇとか眠いことを云う。

先日、昼飯食いながら食堂のテレビ眺めてたら、爺さんが集まって来てはスカイツリーを見上げてるってニュースをやってた。インタビューに応えて曰く、どんどん伸びるよねぇ、いいんだよなぁ、なんか夢があって。

ああ、その時、おれは髪結いのおっさんの言葉を思い出し、連中はおれより年上だが、なんかわかった。

街角に超高層ビルの曙っていう映画のポスターが貼られて、霞ヶ関に36階、それに続けて浜松町に40数階、そして淀橋の浄水場の跡地に最初が京王プラザ、次に三井、そして住友と、次々高みを目指してビルが建つ。あの頃、それこそ、高度経済成長ってやつが、誰の目にも明らかに見えてたんだ。俺は子供だったからそれ程実感はないが、でもあれは印象的だったろうな。

その記憶がスカイツリーによって目覚めさせられてるんだ、夢として。

そして、まだ建築中の、だから逆にどんどん天を目指して突き進んでいるスカイツリーの周りには、老人達がただただそれを見上げるために集まってくる。

江戸時代の古地図でそこを見ると、実はそこには一切の夢も希望も無さそうなのだが、でも今そこが、光り輝いていた過去の栄光の悪あがきの姿を、というのは、摩天楼ってのは、グラトオシエル、つまり空を引っ掻くことだから、まさに引き摺り落ちかけているのを爪を立てて食い止めようとしている悪あがきの姿そのものを晒している。

だから、まさに今が、スカイツリーを間近で見るべき時なのだ。まだ、江戸時代の場所の記憶が残っているその地に、高度経済成長の幻を観に老人が集まって来ている、そんなタイミングは今、まだ未完成の今しかない。

_ 1つの言葉、複数の概念

winplusさんの『売上の「正しい」名前とは何か』を読み、頭をひねる。

ビジネスの世界じゃなければ、名前空間で分けるけど、そういうことでもなさそうだし。

でも、もし、それがOOPの世界だったらどうだろうか？

売上はSalesで、SalesのデータなんだからSalesDataとかいうPOJO（POCOでも良いけど）を作ることにして、工場と商品企画で異なる名前空間があるとする。

namespace 工場
class 売上 {
  顧客 {get; set; }
}

namespace 商品企画
class 売上 {
  顧客 {get; set; }
}

これについては、それほど違和感ないな。

名前空間ってのは、日常生活での言語においては文脈ってことになるけど（文脈によって同じ言葉が異なる概念を持つ）、データベースではそれは何だろうか。データベース（カタログ？）ってやつかな。

でも、文脈っていうので実は良いのではなかろうか。

if (endPoint == "商品企画") {
  notify(salesData.Customer);
} else if (endPoint == "直接販売") {
  notify(salesData.Customer);
}

ここでの文脈はendPointで、それぞれの節内で、上のほうは内線電話が鳴り、下のほうはEメールが飛ぶ（か、カスタマサポートとか外商とかに指示が飛ぶ）。

というか、OOPであれば、はなからthisが異なるクラスだから途中で自分が何者かを調べるまでもなく

notify(salesData.Customer);

で良いのであった（というか、そう記述する）。

……なんという空気読みの世界。

_ 401, 405, 500 bang!

WCF Data ServiceでPUTをやろうとしてはまりまくっていて、先が見えなくて困りきる（現在進行形）。

環境はWindows 2008 Server R2で、IISにはWebDAVも載せている（これは他の要件から必須）。で、WCF Data Serviceが独立した仮想ディレクトリにある。

GETはご機嫌に動いているのだが、いろいろあって、クライアント側は手作りJSONクライアント。

で、PUTをしたら、最初は401になる。

当然、URIがおかしいのだろうとか、メッセージボディがおかしいのだろうとか想像するのだが、わからん。URIは、GETしたJSONのd/resultsの中の__metadataのuriを指定しているからおかしくはないはず。メッセージボディはおかしいだろうと思うが（だからテストしてるわけだし）、でもそれで401ってのはおかしい。

いろいろ調べると、WebDAVが悪さをしているという説を見つけ、WCF Data Serviceの仮想ディレクトリのHTTPハンドラから、WebDAVを削除する。

すると、405が返るようになった。わからん。

そこで、モジュールからWebDAVを抜いてみた（WebDAVが影響しているのは401の解消から間違いなさそうだと考えた）。

すると500が返るようになった。よっしゃ。

が、全然よっしゃじゃない。おれは、svcに制御がわたって、そこで500になっているのだと思ったのだが、DataService.HandleExceptionに制御が渡っていない。

そこで、IISのパイプラインのログを見ると、2ステップ程度で500を返している。WCFに制御が来ていない。

で、どうもWebDAVをモジュールから削除したのがまずそうだと、いろいろいじったり、IISを再起動したりして、ついWCF Data Serviceの再デプロイをやったらWeb.configが上書きされて元通り。

401が返るようになった。

で、ハンドラからWebDAVを削除して405まで再現させた。

上の経緯から、405を返しているのは、パイプラインの途中にいるハンドラらしいというのは当たりはつくが、一体どうやって探せば良いのか、そいつが問題だ。

HTTP Error 405 With ASP.Net MVC and HTTP PUT on IIS 7.5というのを見つけたが、この人はWebDAVが405を返すからハンドラから削除したと書いている。おれのとは異なる出方だなぁ。

WCF ASP.NET (405) Method Not Allowedというのは、POSTが405になるというので、また異なる問題のようだ（GETはうまくいっているのかな？）。(IIS Hosted Service Failsなんてのもあるが、3.5だし、*.svcに対するGETは処理できているから異なる原因だろう）

IIS 7.5 WCF service: (405) Method Not Allowed.に、ログの取り方が出ているからそれをまずは試してみることにしよう。

それはそれとして、IIS＋WCF関係で検索していると、http://ja.w3support.netというのがやたらと引っ掛かって、まったく理解不能な間違った日本語翻訳で困る。原文が引っ掛かるのなら良いのだが、こういうゴミのような日本語翻訳はspamの一種として検索から除外してくれないかなぁ。

追記：結局、アプリケーションプールをパイプラインからクラシックに変更したら動作するようになった。でも、環境によってはパイプラインでも動作するらしいので、クラシックを使うのは最後の手段としたほうが良さそうだ。

_ 500バンバン

で、トレースの設定をフルセットにしてログを取り直してみたら、なんと405を返しているのはWebDAVモジュールだった。

ハンドラがないので405ってことかな。

で、モジュールからWebDAVを削除して500で、振り出しに戻った。が、トレースがフルセットなので500の理由が少し見えるようになった。asp.net4のアプリケーションプールが見つからないというようなエラーだ。が、GETはできてるから謎過ぎる。手詰まりだ。

というわけで、サポートを受けようとしたらなんか手続き的にごちゃごちゃ面倒なこと言われて面倒になったので、考えて見ればおれ個人がMSDNサブスクライバなんだから(しかもこれまで行使したことないし、でも考えてみれば一足先に自分のMSDNライセンスでVS入れてるんだよね)、そっちを使ってサポート問い合わせ。

_ クリスマスに真夏(夏至)の夜の夢

恵比寿ガーデンシネマに、デプレシャンのクリスマスストーリーを観に行く。ストーリーといってもリストワールではなくルコントのほう。現存している映画作家の中でおれにとって1番か2番目かに好きな作家なだけに、映画館で観られるというだけでうれしくてたまらず、11時開場なのについ、9時30分に恵比寿に着いてしまってうんざりして10時までは地下のバーガーキングで時間を潰す。でも10時20分頃の開館時間にはすでに長蛇の列となっていたので、9時30分に着いてもそれほどはまずくはなかったようだ。

最初、墓地で蛙系のおっさんが長男の死の悲しみを乗り越えて、おれは新たな生を受ける、というような言葉を参列者に投げているところで始まる。そして影絵で長男が6歳で白血病になり、両親も長女も骨髄移植は適合せず、次男を妊娠したが羊水検査でやはり適合せず（期待はずれの次男というような言い回しが出てきて、なんじゃそりゃとこの時点で思う）、結局長男は死んでしまい、そこに3男、4男が生まれて、弟の面倒は長女が一手に引き受けた、ということが語られる。この家族構成に関する語りが、実は一方的なものであり、にもかかわらずお話の枠組みであることが示される。

というわけで、すべての不幸を背負った次男が、そして僕は恋をするで主人公をやっていた役者によっていい加減に演じられる。

最初、話は一貫性なくそれぞれの人物を適当に描いて進む。

そして僕は恋をする(-)

母親はお茶を入れていて歩きだして、そしてお盆を取り落す。蛙親父がやってくる。

彼女は白血病であと3年くらいで死ぬか、骨髄移植をするかということになり、では誰がドナーになるかということで、各家族が順に出てくる。

というような細かい物語はそれぞれ伏線が張りまくられていて緊張感とちょっとした謎解きと（語りのいい加減さによって観客置いてきぼりで話も進むことも一因）がからみあって、おお、このおもしろさがデプレシャン、としびれまくる。

この作家のおもしろさは、うまく説明できない。信号まで目をつむってふらふら次男がやってきて、立ち止まって、そのまま顔から車道に倒れ込むところとか、フィールズ賞を受賞したという長女の夫がいきなり次男をぼこぼこに殴る蹴るしていきなり家を飛び出して行ったり、親父がいきなり「ああ、あの子がなんで白血病になったか、やっとわかった。妻の遺伝だたったのか」とか言ってみたり、というか、黒板いっぱいに親父が妻の生存率を計算した式を見て、長女の夫が、その間違いを指摘して次々と式を書きながら講義をしていくとか（もっともらしいがでたらめっぽい）、異常な音楽一家と3男の妻に言わせて（でも、実際には親父は染色工場経営だし、次男は詐欺師のようなオークション師のような、3男はなんだかわからないし、4男は画家、長女は劇作家）、そこでつじつま合わせの必要が生じたもので、父親にチャールズミンガスの楽譜を読まさせたり、3男の息子たちによるクリスマス劇（親父は楽師で登場）では山羊だったり、細かな言葉のやり取りと、どこまで計算しているのかわからない適当な映像のつなぎ合わせと（意外なほどアップが多い）、おかしな間の取り方とが組み合わさって、あっというまに2時間半くらいが経過して、何とも言えぬもやもやが残ったまま映画は終わる。あーおもしろかった。映画を観る楽しさそのものであるなぁ。

だいたい、血の繋がりがテーマのふりをしているが、親も兄弟も誰一人として似てない(というかいつものデプレシャン映画の人達だし)し、ユダヤ教の話が出てきたのでダビデの星のネックレスさせたり、役者のアドリブとそのフィードバックが映画の推進力だといわんばかりに見える(これを緻密な計算のもとに脚本を組み立てているとしたら間抜け過ぎる)。つまるところこの行き当たりばったり具合こそ人生だし、映画ってのは結局は人生なんだから、おもしろくて当然だ。

長女は相変わらず次男を目の敵にしているし、3男と4男と3男の妻の関係は複雑度を増し、長女の息子はさてどうなるのだろうか（次男の一番の理解者のようになっているが）、あるいはバルトルディみたいな名前の3何の息子たちとか。

途中で、真夏の夜の夢の映画と、音楽。映画は他に多分パリの恋人（アステアとオードリーヘップバーンだと思う）、映画館にかかっていたのはなんだったか忘れた、とか。

それにしても、真夏の夜の夢はすばらしい曲だ。これを16歳くらいの時にちゃちゃちゃと書いてしまったというのは、驚くべきことだ。

メンデルスゾーン:夏の夜の夢(小澤征爾,ボストン交響楽団)

_ 時の流れに気付く

サポートを受けるために電話して、「お名前をお願い」される。

おれの名前は、暁で始まるわけだが、これまで散々面倒な思いをして来ている。

素直に「あかつき」で通じた試しがない(あることもある)。教育漢字じゃないからしょうがねぇな。

で、教育漢字を使って説明する。「焼くという字の偏が火ではなくて日(にち)」。10人中9人はこれで通じるが、1人くらい、「暁」という字をおそらく見たことがなくて違和感を覚えるのか独自に補正して「焼」とわざわざ否定されている字にしてくれる。名前にはつかわんだろうJK。

で、ふと気づいたら、そういう経験からおれは「あかつきという字」という説明を避けていたのだが、今は電話の向こうの人はまともな日本語かな漢字変換システムを使って名前を打ち込もうとしているのだから、むしろ偏がどうの旁がどうのとか言わずに訓読み出せばいいんだなぁ。

_ WCF Data Serviceでのエラー処理

エラー処理のうち、おそらく予想通りに動作するのは、返されたETag(カラムの同時実行制御属性をFIXEDにすると__metadataフィールドにuriやtypeと一緒にオブジェクトとしてパッケージされる)をIf-Matchヘッダで指定した場合のHTTPステータス（precondition not match)だけ（etagをオブジェクトに設定して送信すると500になってメッセージが「ETagはIf-Matchに入れろ」となるけど、これもなんだかなぁな仕様）。ほとんどすべてのエラーが単純にInternal Server Errorになるので、普遍的に発生するKEY重複みたいなものは検出できない。

無理矢理がんばるとすると、Serviceのエラーハンドラで、Inner Exceptionにラップされた元のSQL例外を拾って、それをMessageボディに入れてやってクライアントで検出するしかない（何をやろうがHTTPステータスコードは500になってしまう）。

と、実にくせがある。

くせがあると言えば、PUTはすべてのカラムが対象になり、省略したカラムにはNULLが入る。突然ほとんどからっぽになってびっくりした。

で、指定したカラムだけを更新するには、MERGEというメソッドを使う。これは明らかに馬鹿な仕様なので、現在出ているCTP1では、PATCHに直している（というか、直しているのではなくPATCHを「追加」しているだけなことを祈る）。というか、WCF Data Serviceの連中はHTTPのプロトコルを知らないんじゃないか（で、誰かが指摘してあわててPATCHを持ってきたとか。というか、PUTでそう振る舞えば良いのになぁ）。

_ マイクロソフトは何か勘違いをしている

Windowsの開発をすることを考える。スタンドアローンのWindowsアプリケーションではなく、クライアント＋サーバのシステムだ。

組み合わせは次のいずれかとなる。

1. クライアント＝Windows7(x64)＋サーバ＝Windows Server 2008(x64)

2. クライアント＝Windows7(x86)＋サーバ＝Windows Server 2008(x64)

3. クライアント＝Windows7(x86)＋サーバ＝Windows Server 2008(x86)

4. クライアント＝Windows7(x64)＋サーバ＝Windows Server 2008(x86)

で、問題は、1と2の場合だ。

この場合、開発環境は次の組み合わせが考えられる。

1. クライアント(x64)PC + サーバー用(x64)PC

2. クライアント(x86)PC + サーバー用(x64)PC

3. クライアント(x64)PC + 仮想PCサーバー(x64)

4. クライアント(x86)PC + 仮想PCサーバー(x64)

5. サーバー(x64)PC + 仮想PCクライアント(x64)

6. サーバー(x64)PC + 仮想PCクライアント(x86)

このうち、1と2はどうでも良い。どうでも出来るからだ。

問題は、上記の組み合わせのうち3と4が純正な環境では構築できないことにある。でも、4は直観的にできなくてもしょうがないなぁとは考えられるので、問題は3だ。

3と5,6の違いは明らかで、グラフィック処理とか細かいところが（DirectXもそうだし、Silverlightグリングリンとかいくらでもある）、サーバWindowsとクライアントWindowsではクライアントWindowsのほうが使い勝手が良い点にある。気分の問題かも知れないがVisual Studioもサーバで実行するよりクライアントで実行するほうが高速に動作するように感じる（JITがWindows Froms最適化しているのではないかとかいろいろ要因もありそうだ）。つまり、ホストをWindowsサーバにして、仮想マシンでクライアントを動かすという運用はまったく魅力がない。（とは書いているが、勤め先ではグラフィックがしょぼいマシンを開発用に利用しているのでホストがWindows Server 2008なので気づいていなかった。昨日、家のマシンにサーバ環境を入れようとして気付いたのだった。）

したがって、開発以外での利用も考慮すると、ベストな選択肢は3となるのだが、問題は、純正な環境ではこれが作れない点にある。

具体的には、Windows7組み込みのWindows Visrtual PCがCPUをx86に固定しているからだ。Windows Server 2008(x64)をインストールしようとすると、すぐさまサポートされていないハードウェアとしてはねられてしまう。

ではどうすれば良いかというと、どうしても純正環境でやりたければ、クライアントPCの利点を捨てて、5や6でやる（Hyper-Vなら何でもできる）か、あるいはデュアルブート以上にする（だが、これはすごく負けた感がするし、ブートし直すというのは現在のコンピュータの運用から言えば最悪だ。環境構築の都度、マシンが占有されるのもたまらない。ただ、世の中には、開発者全員が同一のイメージで利用できるように、あらかじめ仕込んだサーバ上の開発環境をVHDで渡して、VHDブートして開発環境へ移るという運用をしているところもあるようだ。それはそれで良さげではある）。

さもなければサードパーティ仮想マシンを利用することになる。VirtualBoxならばっちりだ（ちゃんとマウスキャプチャの仮想ドライバや、NATで外に出られるネットワーク仮想ドライバも提供されているので、使い心地も良い）。

でも、それっておかしくないか？ Hyper-Vのように、当然といえば当然だが、マイクロソフトは使えるx64の仮想マシンを持っているのだ。

というわけで、マイクロソフトは、Visual Studio 2010 Pro以降のSP2以降では、Virtual PC for X64を開発者に提供すると良いと思う。

Microsoft Visual Studio 2010 Professional with MSDN(-)

（MSDN更新の時期だが、今年からはProにして、Officeは別に買うことにするかな。どうせInfoSetとか使ってないし)

【旧商品】Microsoft Office Home and Business 2010 通常版 [パッケージ](-)

_ 正規表現は重要でしょう

Javaでも.NETでも普通にクラスが用意されているわけで、以前ならなんかforとかでクルクル回す必要があったコードも"^¥¥d+$"とか使って楽勝でチェックできるようになった。

というわけで、自分が正規表現を読み書きできるのは当たり前として、周りも読めるようにならないと、三流プログラマの呪いの言葉「難解なコード」攻撃に襲われることは確実だ。あの連中は概念の難解さではなく、見た目の記号含有率で難しさを判定するからな。

このままだと、コーディング規約に「ソースが難解になるので正規表現は禁止。1文字単位にswitch、caseでチェックすること」と書かれる日は近いぞ。

というわけで、いやいや、正規表現は四則演算程度に常識ですよ、ナンカイはナンカイでも南海のパラダイスと言えるように、周囲のみんなや後輩に、こいつを薦めて学習させよう。職場へのクリスマスプレゼントにピッタリだ。

反復学習ソフト付き 正規表現書き方ドリル (WEB+DB PRESS plus)(杉山 貴章)

_ 良い時代だなぁおい

WEB+DBプレスは献本してもらっているんだけど（以前に記事を書いたことがあるからだと思うけど、そういう意味ではそろそろ期限切れになるんだろうんぁ）、ほとんどここで紹介することもなく、来てしまった。他の人がそれぞれ良いログを残しているしね。

が、これはいい！

WEB+DB PRESS Vol.60(まつもと ゆきひろ)

特集のタイトルは『知るべき言語設計の基礎知識』だから、それ自体が意表を突いているけど、額面通りに受け取ると実におもしろい。

1. おれは言語設計なんかする気はないから興味ないもんね

2. おお、実はおれも言語設計したかったんだよね

のうち、後者のほうが多いだろうというのに賭けたのかな？ というようなことより、内容が実に見事なプログラミング入門になっていることだ。なんというか、プログラミングというものが成熟した証拠のような記事だ。

一般論として、プログラミング入門であれば、利用するプログラミング言語の利用方法の説明になるだろう。

が、ここではプログラミング言語というのはどのようなものか、について基本的なあり方から順に説明している（順かどうかは別か）。

そのため、すごく見通しが良く、俯瞰的な眺望を読者に与えることに成功している。すげぇなぁ。

というわけで、次の諸点が良い。

・プログラミング言語の論点がわかる

・プログラミング言語とは何かがわかる

・プログラミング言語の傾向と差異がわかる

・筆者の分析力がわかる（＝こう考えるのかとか、こう目をつけるのかとか、こう掘り下げるのかとか、実に参考になる）

他にもいろいろあるけど、そういうのは各人のモチベーションや興味に依存する。

併せて読みたい、著者のメタデータ：「言語設計の基礎知識」本日発売！

_ ASR (ruby-1.8.7-p330)

ActiveRuby-1.8.7(35)をリリースしました。

・Ruby-1.8.7-p330パッケージです。

・VC++6でコンパイル/リンクしてあります。

・添付ExerbはRuby-1.8.7-p330をコアとした5.3.0に更新しました。

ダウンロード

_ 目標設定の記述方法

アスキーの嘉平さんから妙な本をもらったので読んだ。多分6ポモロード(注:正しくはポモドーロ。完全に逆転して書いているので注意)くらいで読み終えた（つまり通勤3日分）。おもしろかった、ありがとうございます。

アジャイルな時間管理術 ポモドーロテクニック入門(Staffan Noeteberg)

ということは大ざっぱに3時間弱くらいで読了できるということだ。おれはこの文章を書くためにいろいろひっかけながら読んだからそれだけかかったが、多分、もっと早く読めるかも知れない。

ポモロードってのはトマトのことで（子供が表紙を見て、トマトの本か？ と訊いたくらいだ）、それをポモロードと呼ぶことによる異化効果はあまり日本ではなさそうだが（トマト銀行という銀行名から受けるインパクトに比べると赤やなんか間抜けっぽさや薄皮っぷりとかの印象が抜け落ちるからだけど）、でも謎めきっぷりからは良いのかも。

192ページと、比較的薄っぺらい本だが、内容そのものも書かれているテクニックそのものも比較的単純だ。

最初にTODOリスト（ただし、ここで作るのは中長期目標なので「アクティビティ在庫」という用語を使っている）を作り、毎日どのタスクをやっつけるか予定を書き（本書ではこの短期目標がTODOリスト）、1単位25分で集中して1セッションを行い、終わったか終わっていないかチェックして、次のセッションを確定してまたセッションを行い（途中3分から5分の休憩を取る）、それを数セッション繰り返したら少し長めの休憩を取り、またセッションの繰り返し。一日の終わりには振り返りを行い、セッションの切り方（時間は25分で固定することをまず前提として、タスクの切り方ということになる）のぶれを減らしていく。ついには、あたかもボクサーが3分＋1分という間隔を感覚として確立させるように25分＋5分というようなフロー没入へのリズムを養成するという方法論だ。

で、1冊にわたってその方法の論拠とか、経験談とかそういったことを語っていく。特に重要なのは割り込みへの対処方法の章かも知れない。

この手の本で重要なことは、読んでいて、なるほどわかった確かにそれは効果があるだろう、が、面倒くせぇからやらないとならないようにすることだが、紙と鉛筆（イタリア人も鉛筆を使うが、書いているのは北欧の人だ）とキッチンタイマー（またはその他のタイマーで携帯電話でも良いと書いているから、試しに携帯電話でやってみたが、確かに25分というのはそれなりの経験則から来るのだろうけど根拠ある時間に思えた）だけで試せるというのが長所かも知れない。

だまされたと思ってやってみても、失うものがほとんどゼロなので（懐疑主義者のおれは、このてのうまい話に乗ることそのものが何かを失うことだったりはするのだが、実はそれによって失うことは何もないとこないだリンゴの樹を見て気付いたので、わりと気楽にやってしまうのだった）なんか、時間管理とかタスク片づけテクニックとか、模索している人はのってみる価値は大いにあるだろう。

翻訳はうまいと思う。

でも、いささか馬鹿正直かも。

たとえば『ネコ、箱、タコ、横』といった言葉の集合を瞬間的に記憶するよりも、『小さい、狭い、極小、控えめ』という言葉の集合を一瞬で記憶するほうが簡単です。

という訳文があり、読めば音韻が関連している（しかし概念は雑多）言葉の羅列と、意味が関連している（いずれもサイズなのだが、しかしその伝では「控えめ」は微妙かも知れない。むしろ「小ぶり」程度のほうが適切なんじゃないかなぁと原文を読まずに想像してみる）ほうが記憶しやすいということを書いているのだな、と理解するわけだが（この節――P.51『連想マシーン』――は著者が書き足りていないような気がする。長期記憶は意味の連なりだが、短期記憶は音韻が主体なので、短期記憶では音が異なるものの組み合わせのほうが記憶しやすいとか……と書いているうちに、実は誤訳か原著の誤りなんじゃないかという気がしてきた。実際に試してみると『ネコ、箱、タコ、横』のほうが覚えやすいぜ。でも長期になると、後者の意味的に関連しているやつのほうが覚えていられる気がする。いや、そうではなく長期的にも前者のほうが記憶していられるかも。歌詞とかじゅげむみたいなものだからだ。というわけで、アンディの脳みそハック本もそうだが、このての本には妙なうさんくささというか、自分の領域ではないサイエンスを自分勝手に引用する人特有のご都合主義から生じるでたらめというか俗流解釈の持ついい加減さが爆発しているような気がしてくる『第二章』であった）

というか、何を書きたいか思い出したが、『ネコ、箱、タコ、横』には訳注があって、本当はcat, hat, fat, rat（ほら見ろ、おれは覚えていて、本を読まずに正しく書けたぞ）だけど日本語で同じような雰囲気（確かに韻を踏んでいるが具体的な生物の名称、物の名称、抽象概念の名称と中身はばらばらだ）を出したとしているくらいに、原著の内容を日本語化すべくしているからだ。で、そんな注はいらないよなぁ（いきなり『ネコ、箱、タコ、横』で十分じゃん）というのが馬鹿正直だなぁと思った点だが、もちろん、それはポジティブな言い方をすれば誠実な翻訳ということだ。

で、この本で一番重要な点ではないか、とおれが感じたのは、実は中長期TODOリスト（つまり、アクティビティ在庫リスト）の書き方にある。

項目を書くときは、やるべきことを書くのではなく、作業が完了したらどのような状態になるかを書いてください。

たとえば、リビングルームを掃除して整頓する、ではなく、リビングルームがきれいになる。

おれはここを読んだ瞬間、安能務（この人は毀誉褒貶ありな人だが、おれは、おそらく台湾学派とでも言うべき中国学の人なのだろうなぁと想像しているんだ。であれば、読み一つとっても北京学派とは異なって当然だし利用する資料も違うだろうしな、というかおれにはどうにもこの人の主張はしっくり来るのだ）の項羽と劉邦とでもいうべき中華帝国志を想起した。

中華帝国志〈上 治乱興亡篇〉 (講談社文庫)(務, 安能)

この中で異才の軍師、張良は、項羽ではなく劉邦につくことを即決するのだが、その根拠として、項羽は始皇帝を見て「とって代わるべし」と豪語したのに対して、劉邦は「男子たるものかくあるべし」と奮起したというように語らせている。

これって、項羽は「リビングルームを掃除するべし」と豪語したのに対して劉邦は「リビングルームはきれいであるべき」と奮起したと言い換えられるよなぁということだ。

つまり、TODOではなくTOBEである。

おそらく、何かをするにあたって一番重要なのはモティベーションで、モティベーションを高めるのは何をするかではなく、どうあるべきかのイメージを確固として持つこと（だからこそ、スポーツ選手はイメージトレーニングをする）なのではなかろうか。

何しろ刃牙なんか、イメージトレーニングで烈海王を何度も倒したおかげで一発で首ぽっきんをするくらいだ。（お、ポモロードが終わった）

_ Ruby-1.9.2-p136 MSI

ruby-1.9.2-p136(2010-12-25)のWindowsインストーラ用パッケージです。

ダウンロードページ

readlineを利用した場合の漢字入力不可、カーソルキー無視問題については、対応パッチを当ててあります。

パッケージングのバグなどを見つけた場合、ツッコミをお願いします。

特に問題が見つからなければ、1/1に、ruby-listでアナウンスする予定です。

_ 新国立劇場のトリスタンとイゾルデ

えらく満足した。

トリスタンはオセロで観たことあるグールドという巨漢。良く通る声の立派なトリスタン。イゾルデはトゥーランドットとかブリュンヒルデとか新国立劇場の常連みたいなテオリン。おれは好きではないが（どうも好きな音ではないので、こればっかりはしょうがない）今回もやはり好きではない。それに対してブランゲーネの人はいいな。あと、クルヴェナールはヴォータンやってた人。この人は好み。2幕では一言トリスタン！と叫ぶだけだが3幕では大活躍。

前奏曲は最初の2つの塊の間が良く、解放されるところの入り方も好きで、いきなり気に入る。大野和士という有名な人らしいが僕には初めて。でもそういうわけでいきなり好きになる。

オーケストラは前奏曲は良かったのだが1幕の途中で金管が派手に失敗して、2幕でそれなりに持ち直していたのが、3幕でぐだぐだになったりしたのが耳についたが（全体が良いと粗が気になる原理）、それでも全体として良い演奏だったと思う。厚みとか。

トリスタンとイゾルデは名曲という扱いだが、CDで聴くとどえらく退屈で、前奏曲以外の印象がまったくなく、当然のように物語もちゃんと把握していなかったので、今回字幕つきできちんと観て、結構驚いた。

だいたい、ペレアスとメリザンドのような話だろうと思っていたので、塔でのゴローの一閃のような悶着があるのかと思っていたら、いきなり無理心中するために毒薬を盛ろうとしたら侍女が機転を利かせ過ぎて媚薬に取り換えたために、したくてしたくてたまらなくなるというある意味エロ話のような内容だったのにはびっくりした。それもあってか2幕では男女交合の象徴としか思えぬ巨大な棒と輪っかがそびえていて、逢瀬の最中は輪っかが光って、マルケ王と家臣が乱入してくると輪っかの光が消えるとか、妙な舞台。（あとでマクヴィカーの演出と知って、なんとなく納得したり）

でも、舞台美術は好き。

前奏曲の途中から白い月が波の上にゆっくりと上り右へ動いていく。美しい。1幕はぼろぼろの船の一部で、全然平和かつ幸福な婚礼の船には見えず、2幕はその妙な棒と輪っかで、3幕は海辺の岩（でもトリスタンはパイプ椅子）。

3幕はいきなり赤い太陽（夜の次なので朝日のイメージかと思ったが、おそらく血にまみれた白日なのだろう。イゾルデが着くと薄妙な白光となり、最後は暗黒の海へ赤い背中が消えていく（というか、イゾルデの衣装は最初黒い頭巾かと思うとぱっと後ろに投げると巨大な赤いローブとなり、非常に効果的）。

3幕の開始時は海辺の岩場でむさくるしい（ホームレスのような）トリスタンとクルヴェナールがうだうだしていて、どこのゴドー待ちか、それとも検非違使を待つ俊寛か、ここはどこの喜界島といった趣。しかも船はまだか、船は見えるかと大騒ぎなので、ますますもって俊寛みたいだ。

ユリシーズが翻案されて百合若大臣になったように、トリスタンが翻案されて俊寛（トシヒロンと訓読みするのが正しかったりして）になったのかなぁとか想像してみたり。時代的にも12世紀頃の発祥だから、鎌倉時代にシルクロードを経由してやってきたとしてもおかしかない。

音楽はそういう意味では前奏曲以外はきちんと聴いたのは初めてと言っても良いくらいなので、新鮮だった。1幕、侍女がとうとうと、権勢並ぶものなきコーンウォール王の女王となるのだから好意というものだろうJKとか言うのに対して、イゾルデのセリフは何やら単なる言いがかりのようで、なぜ心中に持っていきたいのかが今一つ良く見えない。

2幕は、なるほど演出通りの性交音楽で、それは良いとしていささか長すぎてだれた。30分程度でいい内容。ただ、オーケストラのうねり具合もグールドの声も良く、聴いていて実に気持ち良い。

3幕は、打って変わってドラマティックだが、最初の羊飼いの笛はちょっと気持ち悪すぎるかなぁ。侍女と王女のかけあいに始まり、従者と騎士が入ってきて、また侍女と王女のかけあいで、騎士と王女で延々と歌い、そこに王様が入ってきて、今度は従者と騎士のかけあいで、そこに王様が入ってきて最後に王女が歌いまくるという（まあ、あと雑魚がちょっと歌う）、歌手にとっては歌いっぱなしの5時間で、相当疲れそうだ。元は軽い小品を、発表のあてない指輪の作成に疲れた（資金も底をついた）ヴァグナーが、稼ぎ仕事用に構想したというだけに、オーケストラもハープは2面しかないちょっと小ぶりな感じだが、内容たるや超ヘヴィー級の超大作になっているところが、ヴァーグナーってのは怪物であるなぁとつくづく感じる。

そこかしこで、あたかもジークフリートのモティーフ（≒アルベリッヒの呪詛）のようだったり、なるほど、途中でこの作品を作ったから、火の山での世界挨拶や神々の黄昏があれだけ重層的な見事な音楽になったのだなぁと（練習重要）と思った。

それにしても、マーラーやシェーンベルクを通り過ぎた今聴けば、実にロマンティックで官能的な美しい音楽だけど、当時の人にはぶっとびだったのだろうと思うと時間の経過と表現の過激さというのは不思議なものがある。

ワーグナー : 楽劇「トリスタンとイゾルデ」全曲(コロ(ルネ))

（当然のように持っているのはクライバーとドレスデンなのだが、どれだけクライバーがすごい指揮者であろうとも、どれだけコローがその頃のヘルデンなヘルデンテノールであろうとも、実際の舞台でそれなりの演者がやっているものを観るほうが、数億倍も素晴らしいと実感しまくった）

_ ソーシャリスム

シャンティでゴダール。

しかし、昨日のトリスタンで集中力を使い果たしたのか撃沈してしまった。

系統としては、犯罪映画ものじゃなくて、似非ドキュメンタリーものなのだが、パッションや新ドイツ零年並の傑作ぽいような気がする。冒頭のピー音にやられたっていう面はあるけれど。

パッション 【ベスト・ライブラリー 1500円:第4弾】 [DVD](ハンナ・シグラ)

軸はゴルトベルクの金を巡る冒険と、ソーシャリスムの遺跡を巡る地中海クルーズとガソリンスタンド経営の3本のような気がするのだが、何しろ断片的にしか記憶が無いので怪しすぎる。オデッサとポチョムキンとか出鱈目に階段の説明をする観光案内者とか、帽子を被って階段で本を読む子供と、帽子を盗られた女性とか、夜にはニュースを見るとか全く繋がっていない。

機会があったら再挑戦しよう(もっとも、三戦して三回とも撃墜された彼女についてのような例もあるから、観て見ないことには判断できない)。

_ マンガ読んでたら年が変わった

これはおもしれぇや。

それでも町は廻っている 1 (ヤングキングコミックス)(石黒 正数)