日々の破片

_ コップ

コップに求められるものはなんだろう？

たとえば、それはガラスまたはプラスティック（というかポリエチレンとか）でできていて……というような良くある素材から考察すると、

・透明

中の液体に異物が混入していないかすぐわかるという実利性と、中の液体の色が見えて場合によってはきれいという装飾性

・ツルツル

中の液体が染み出さない、汚れが落ちやすい、とかなんとか

・なんていえばいいのかぱっと思いつかない

プラスティックだと微妙なところだが、熱い液体入れても溶けないとか、冷たい液体入れても溶けない（崩れないかな）とか、そのあたり。上と同じことかも

・持ちやすいサイズ

まあ、これは当然、手で握って、上に口をつけて飲めるだけのはみ出し分が取れて……のようなサイズが決まるはず。

で、mputさんのコップの写真を見て、その機能美にそそられるオレと、良くわからない理由からちょっと否定的なオレの2人のオレが存在するので、あらためて考えてみても、後者のオレが存在する理由がわからない。

もしかすると、模様のせいかもしれない。知れないが、別にいやな模様ではなく、むしろハイテクでかっこいいほうに倒れているように思える。

ちょっと太過ぎて、あるいは太くないとすれば寸が足りなくて、そのあたりに違和感があるのかも知れない。

_ 本の読み方

Twitterで哲学ノートについて見かけたので、30年前ならいざ知らず、今頃になってなんで哲学ノートなんだろうかと検索してみた。

すると、トップに松岡正剛の哲学ノートについてのページが出てきた。

しかもぼくは、この本で初めて、世の哲人や学者や革命家たるものがマーキングをしながら本を読んでいるのだということを知ったのだった。

レーニン哲学ノート〈上巻〉 (岩波文庫)(レーニン)

ふむふむふむと思うところがある（既に最初のトリガーから別のところにいる）。

そういえば、本の読み方をおれはどこで学んだんだろうか？

もちろん、小川未明の読み方は母親に教わったわけだが、そういう話ではない。

小川未明童話集 (新潮文庫)(未明, 小川)

ひとつは、高校時代の作文の時間の教科書の板坂元の方法で、手元にダーマトグラフがあるのは、この本の教育によるはずだ。

考える技術・書く技術 (講談社現代新書)(板坂 元)

で、読書のツールたるダーマトグラフ。

B001U3UEHA

あの時点ですでに蛍光マーカーは売っていたから、なぜ黄色のダーマトグラフなのかは疑問でもなくはなかったが、消えない、剥ける、透けないとか、マーカーよりも納得感があったのは記憶にある（ので、手元にもある）。つまり、要点をダーマトグラフでぬることで、その作業を数ページやれば、その書き手がピラミッド型に文章を構成しているかそれとも逆に構成しているか判明するから、後はそれにあわせて読めば良い……とは書いていなかったはずだが、そういうような分析用のツールとして利用することを勧めていたような記憶がある。まあ、覚えてないけどな。KJ法もこの本で学んだのだが、軽い語り口でうまく情報整理術をまとめてあるとは思う。

しかしそれ以上に利用したのは、NOBLOT INK PENCILだ。鉛筆にインクが混ぜこんであるので一度定着すると半永久的に消えない（かすれない）、しかし書いてすぐなら消しゴムで消せるという謎鉛筆で、かすれないという点から本へ書き込むにはもってこいなのであった。

これも、板坂元なのかな？

というのは、同じ時期に、別の読書の方法論を読んで、これまた影響されまくったからだ。多分、その著者は目が見えないのでインク鉛筆みたいなツールを提示したりはしないだろうから、ツールは板坂、線の引き方はそっちみたいな方法をとったらしい。手元で残っているのだと思想書のたぐいには、明らかに影響下にある書き込み方法をしているものがある。

読書のしかた (1970年)(黒田 寛一)

いやぁ、思い出したよ、こんなものも読んでいたのだった。どういう人かは知っていたけど、多分、高校の図書館で借りて読んだのか、区の図書館で借りたのか。

クロカンは言わずと知れた革マルの理論的指導者だが、同盟員（で良いのか？）教育のための著作もものしている。これもその一つ。で、なぜかおれは実用書としてこれを読んだのだ。多分、ぺらぺらと手に取って眺めて、具体的な方法論が書かれていて、おおなるほど、思想書とはこういう読み方をするものなのか、と借りて読むことにしたのだろう、と思う。

で、読み進めると、レーニンの哲学ノートでの線の引き方を真似しろ（というか哲学ノートを読め）というのがあったのであった（はずだ）。

重要なことが展開されている可能性があれば上に横線、間違いなく結論であれば縦に傍線、何か感じたことがあれば、一言その感じたことを書いておく、とか。

そうやって学習した方法を利用して右手にインク鉛筆、左手にページをもち、書物を順に紐解けば、次第に理解してくることがある。読書とは、読みながら文章の構成を分析して、要点にあたる情報を抽出して、夾雑物を排除しながら論点だけを残していく作業だが、それと同時に文は人なり、言葉に人は感銘するのだ。感興は要点だけからは生じない、その心の動きも同時に記録していくのだ。つまるところ、読書は知性と感性の双方を使う作業なのだ。であれば、美辞麗句や難解な言い回し、綺語、古語、そういった論旨にとってのノイズが、実は正しく思想にとっての通奏低音であり、哲学書、思想書の類が晦渋なのは当然のことであった。

しかし――今は、そういう線を引っ張ったりはしないなぁと考える。

理由は、必要ないからだ。それほど晦渋な本は読まなくなったというのもあるけど、どう読めば良いかという方法論が身に着いてしまったからだろう。

でも、たまには、そういう読み方をし直してみるのも悪くはなさそうだな、とか思ってみたりしてみたりする。

_ 時代は回る、ショーは止まる

闘うプログラマー[新装版](G・パスカル・ザカリー)

アマゾンの評を読むと、

本書のオリジナル・タイトルは"SHOW-STOPPER!"という。これは、演技を中断させるほど長い喝采を受ける演技であり、人を魅了するもの、思わず見とれるものを意味する。著者のザカリーはWindowsNTとその開発プロジェクト・チームを "show-stopper" と見ているようだが、我々読者にとってはこの本そのものが"Show-stopping!"なのだ。

おれの記憶とまったく異なる。おれの記憶では、リリースショーをストップさせるのは、いつだってリリース間際になると発覚するバグ、それも、ロータスが動かない、dBaseが動かない、そういった大物アプリケーションのAPI呼び出しに対する非互換動作のことだった。

つまり、ショーストッパーとはネガティブな意味だ。

以前読んでから長い時間が経つ。

おれが覚え違えている可能性はある。しかし、しょせんアマゾン評という可能性もある。

というわけで、読んだ人はこっそり教えてください。まあ、わかったからといって何がどうなるわけでもなく、すでにWindowsは32ビットどころか64ビットになっているわけだが。

追記：ショーを止めるもの。ありがとうございます。

_ 自分でばんばん

tDiayをバージョンアップする気が今はないことと、現在、回線が微妙な状態なので（来年にはプロクシを提供できるかも知れないが現時点ではそれはありえない）、とりあえず、直接misc/plugin/amazon.rbにパッチして動かすことにした。

が、結構、はまったのでいくつかメモ。それにしても日曜の昼下がりの再発明は楽しい。

まず、プラグインだけを動かすのが面倒だった。そういう場合はスタンドアロン実行用のテストを作れば良い。ので、作る。

require 'rexml/document'
require 'test/unit'
class EcsTest < Test::Unit::TestCase
  class DummyConf < Hash
    def secure
      nil
    end
  end
  def add_conf_proc(name, conf)
  end
  def setup
    @conf = DummyConf.new
    @cache_path = Dir.pwd
    @amazon_ecs_url = 'http://webservices.amazon.co.jp/onca/xml'
    eval(File.read('my_amazon.rb'), binding, 'my_amazon.rb', 1)
  end
  def test_getisbn
    doc = REXML::Document::new(amazon_call_ecs('4797337958', 'ASIN')).root
    item = doc.elements.to_a( '*/Item' )[0]
    assert_equal('4797337958', item.get_text('ASIN').to_s)
  end
end

これで、とりあえずはプラグインを嘘でも呼べる体勢ができた。

で、何にはまったかというと、Base64でシグネチャをエンコードした上で、さらにCGI.escapeして（つまり最後の＝をURLエンコードして）やらないと403になるという点。

あと、この手のテストには、printfデバッグがばかばかしいほど、有効だと知った。

というのはgnome-terminalが、コンソールに出力されているURLらしきものを見かけると、右クリックでURLを開く動作をしてくれるからだ。こいつのおかげで、何が返っているのかやたらとわかりやすい。というわけで、GETしてどうこうなアプリケーションをデバッグするのなら、URLは何はなくともprintfしておくと良さそうだ。

_ ショーストッパー

ワグナーが、いちいち拍手やらブラボーで劇の流れが止められるのが嫌で、楽劇(アリアとレシタティーボに分けずに無限旋律を導入)を創始したり、ストコフスキーが観客の拍手に不快感を表明したり(じゃあどう感動を表明すりゃいいんだ? と訊かれて、そんなもん不要だと答えたような)とか。

リリースエンジニアリングは楽劇のようだ。

_ 半けつ王子

つまらないなぁと思いながら、気付けば3時間がたっていた。ということは、えらくおもしろかったようだ。(人物の物理的な配置はうまいとは感じた)

不思議と書いてはてなと読みたい不思議ちゃんって、国境を越えて存在するのかな。

リッカルドムーティのようなスネイプ先生。

_ マイクロベンチでアイアンが鉄板

Comparing the performance of IronRuby, Ruby 1.8 and Ruby 1.9 on Windows

では実用性といえば、Socketエラーになる処理系は使えないかなぁとか思うけど。それと、良く読むと、Ruby 1.9.1のほうが高速というのが結論になっている。

.NETが強そうに思っていたけど、例外やGC(配列除く)でYARVが圧倒的（倍とか）なのはすごいな、と思った。

_ LOL

LET OVER LAMBDA Edition 1.0(ダグ ホイト)

PHPのランキングで不動の一位（3週連続）なんだけど、なぜだろう？

『世界のトップ0.01%のプログラマになるために』の本を買いに0.01%のプログラマが書泉に3週間にわたって集まって来てるとか？

（たとえば、PracticalとかOn Lispとかはそういう結果を残していない）

# それとも、新しい風の向きがことここにいたって鮮明になったとか？

_ 電気と車

自動車の光沢が持つ映画的な光景というと、ラングの暗黒街の弾痕を思い出す。

暗黒街の弾痕 [DVD] FRT-309(ヘンリー・フォンダ)

_ 貴重な一角

青山通りの、表参道との交差点の北西の角（交番の角）から善光寺山門までは、3階建くらいの低層ビルで占められている。

本来であれば、その低さが郊外のさびれた駅前広場程度の侘しさで見るに堪えないものになりそうなのにも関わらず、電飾と青山通りが持つ道幅のせいで、実に良い感じを醸し出している（上の写真が少しでもそれを表現できていれば良いのだが）。

他にはその高さ（低さ）を維持した場所がないため、実に貴重な景観で、ここだけがヨーロッパ風に見える（他はアメリカ風な日本に見える）。

おそらく、道路拡幅後にも店を維持した本屋の物語と、善光寺の物語（裏の参道によって区画の奥行きを制限しているのも影響していると思う）が、この貴重な区画をブックスタンドのように挟み込んでいるからだ。

_ 調べる気がおきないこと

必要性がまったくなく、面白味もないこと。

必要性でまとめると、損得利害も含まれるからつまらないな。

携帯で撮ったビデオはなぜyoutubeで3秒になるのだろうか? 3度目なので、再現性はある。最初の音声がある箇所だけを拾っているのかなぁ。

_ トムとジェリー

仲良くケンカしな

ネズミだって生き物さ

ネコだって生き物さ

トムとジェリー セット1 【VOL.1～4】 [DVD](ダン小路)

_ MessageFormatのワナ

開発したフィルターを通すと特定のパターンのタグの属性が閉じられないという問題が出る。

たとえば、<option value='>blabla</option> みたいな感じ。

属性が閉じられないって、非常にまずい感じがするので当然、さっさと修正したいのだが、さっぱりわからん。

だが、状況証拠から、問題なさそうなソースにまさに問題があることがわかった。

次のプログラムの出力を考えてみよう。

import java.text.*;
public class MF {
    public static void main(String[] args) throws Exception {
        System.out.println("hello '' !");
        System.out.println(MessageFormat.format("{0} '' !", "hello"));
    }
}

MessageFormatにそういう処理が含まれるとはまったく気づいていなかった(と書いたところでJavadoc読んだら思いだした。{0}とかを文字列内に含めるためにクォートするのに利用できるからだった)。

というわけで次の出力となる。

$ java -cp . MF
hello '' !
hello ' !

_ Wikibana vol.7

とりあえず、自分のLT分について。

RubyKaigiに引き続きマシントランブルに遭う。mputさんにVAIOを貸していただけたので(多謝)それについてはどうにかなったのだが、プロジェクタでの見え方などのその場で初めてわかった問題とかあって、まあ、失敗しました。楽しみにされていた方がもしいたら、ごめんなさい。

Ubigraphでの動作やc2の奇妙さ（系の粒度の揃い方とか）などの見どころは、歓談の時間にmputさんが見せてまわってくださったので、見られた方もいるかも。それにしても、mputさんにはお世話になりっぱなしでした。ありがとうございました。

発表資料

以下は、WiLiKiを最大数1000（ということはすべてのページが収まっているはず）にして実行したもの（元のプレゼンでは200ページだけを抽出しようとしていた）。

WiLiKiの特徴は、なんといっても、エンタープライズ号のような形状にある。艦長室のあたりに多分shiroさんがいて、エンジンルームにGaucheがあるのではないかとか。

WiLiKiは、最近の編集のような索引機能を持つページがWikiNameによるページ空間と分離していることで（だと思う）、機械的なハブが無い（ように見える）かわりに、R6RS（vertextの日本語が表示されていないため、R6RSが強調される）やHaskellの雲が特に目立つ。

以下は、c2.comで同じく1000ページ分（全体の3%に満たない）。

RecentChangesといったハリネズミのようなノード（ハブ）もあるが、全体としてクラスタが適度な粒度で作られている点が興味深い。

いずれも、ノードの生成はRuby 1.8のHashの順序（つまりはWikiネームをハッシュした順序）なので時間軸と実際のWikiの成長過程は一致しているはずはない。はずはないのだが、おそらくこんな感じなのだろうとは思える。実際に検証したければ、最初にページが生成された時間が取れるようなWiki（たとえばWikipedia）ならvertexの生成をマップしてみれば良い。

追記：83.2秒が2.2秒に速度改善ってのは凄過ぎ

_ Wikiばな Vol.7（続）

自分の発表について引きずると、つまるところは以下の順にものごとが起きた。

BEST SOFTWARE WRITING(Joel Spolsky)

ジョエルがまとめたWeb界隈の人々のアンソロジーで、何よりも、「クレイ・シャーキー」という名前が印象に残った。

(そのまさに今、ちょうど、石坂さんがソーシャルメディアについて語った講演を取り上げている)

で、その名前が出て来て、おやと思う。

プログラマーのジレンマ 夢と現実の狭間(スコット・ローゼンバーグ)

シャーキーは、クリストファー・アレグザンダーの古い論文を再発見したことについて書いていた。

で、c2.comのことを考えて（ついでに手も動かしてマシンも回して、しかし実際にはそんな必要はなかったことは後でわかることになる）いると、

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

おお、となった。

しかし、実装方法がわからない。さて、何から手をつければ良いのだろうか？ とか考えている間もなく、RubyKaigiとなり、RejectKaigiでmoothoさんのトークを聴き、Ubigraphを知る。

で、もにょもにょとOSXじゃ動かないじゃんとかやっているうちに（うんざりしてくる）のだが、Wikiばな Vol.7でLTの募集があり、突如としてモチベーションが上がる。

で、Ubigraphでいろいろ動かしていると楽しい。そこで、Modulobeを思い出す。あれも、用意してやれば勝手に動き出すものだった。おや、etoさんに対する別のリンクが伸びることになった（と、セミラティス構造）。

というわけで、おれにとっては、アレグザンダー、パターン、XPではなく、高橋悠治−アンガージュマン（ここまでは背景）−ソーシャルメディア−クレイ・シャーキー−CGM−Wiki−eto−Modulobe−編集可能性−プログラマブル−Rubyというようなものがそれぞれにリンクされた日だったのだ。

あとひとつ、

クレイ・シャーキー−シャーキーの日−ローリーアンダーソン−ICC−Modulobe−etoという流れも押さえておきたい。

Mister Heartbreak(Anderson, Laurie)

_ 右と左

中埜さんのセッションで、左と右のどっちを選ぶというのがあった。

左の写真はたとえば雑踏、右の写真は誰もいない路地、左の写真は日が差す窓辺、右の写真は物が置いてあるベッドサイドのアップ（かなぁ）とか。なぜか、同数の人はいませんかと複数回訊かれていたのが印象的なのだが、そこまでハイブリッドな人はそうはいないだろう。

おれは、右側だ。

右側に気をつけろ [DVD](ジャン=リュック・ゴダール)

無名の質は良いものだろうし、縁側の前に長方形の石があって、その向こうに小さな池と灯篭があり、生垣があり、縁側には日があたっていて、障子を開け放した向こうの畳の上に寝転び、入り込む風にまどろむ午後というものとか、そういうものがなんか良い感じだということは、肌身で理解しきっている。

が、おれはそういうものは嫌いだ。

金時様をふりたてて疲れ切った物売りのさまを必死に表現する人間の意志の力が感じるものが好きだ。

自然には存在しない直線と平面を、ガラスと鋼鉄を使えば表現できることがわかり、それに全霊を傾けて構成した連中が好きだ。

エル・リシツキー―構成者のヴィジョン(祐策, 寺山)

徹底的に人為的に構成したものには、無名の質はかけらもないだろうが、それこそが人間のための美というやつじゃないか。

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

というわけで、おれは岡本太郎が好きだな。

美の呪力 (新潮文庫)(太郎, 岡本)

で、そこで、実のところ、岡本太郎的なるマンションというものがもし存在するとすれば、そこにもまた沢マンが出てくるとおれは思うのだが、どうだろうか？

右の道を選ぼうが、左の道を選ぼうが、行き着く先は、沢マンなのだとしたら、おれは効率的な方法を取りたいわけだ。

そこで、パターンランゲージというのは、どこまで効率的か、というのは論点となる。

60年代にアレグザンダーは、コンピュータを使って計算していては効率が悪いと信じるにいたって、そこでパターンランゲージを選択した、のではなかったか？

現在のところ、コンピュータにプログラムを生成させるよりも、デザインパターンを叩きこんだ人間にコードを書かせたほうが効率的だ、ということでデザインパターンがある、のではないか。

そのように考えてみると、実のところ、重要なのは、建築主と建築家の効率的な合意形成のための手段としてのパターンランゲージであり、それが持つ効果の説明責任の放棄としての無名の質という言葉という可能性はありうるのではなかろうか。

身もふたもない結論を言うかわりに、あたりさわりのない抽象的な表現で人をたぶらかすという手法がある。たいていの場合（論理よりも印象で物事の是非を決定するような場合）、身も蓋もない物言いは相手を不快にさせるようだ。ならば、その無さを隠すために煙幕を張る、という手法。

手を挙げて横断歩道を渡ろうよ、と言っても一文にもならないが、水がめ座のあなたは乗り物によって傷つけられる運勢なので、車道を横切るときは注意が必要、とのたまえば金が取れるかも知れない、といったことだ。

であれば、それはおもしろい。まさに意志の力による言葉の魔術である。

とか、後になって考えてみたりしてみたり。

_ catalina.outの交換

Tomcatを起動しっぱなしにした場合、catalina.outがどでかくなるから、/dev/nullに変えようかとか相談したが、標準出力とかが見えなくなるのはあまりうれしくない。そこで、

<%
  java.io.PrintStream old = System.out;
  System.setOut(new java.io.PrintStrema(new java.io.File("catalina.out" + createDateString(Calandar.getInstance())));
  System.setErr(System.out);
  old.close();
%>

とか書いたjspをちょっと流してみたら、あっさりと交換できて拍子抜けした。

追記：でも、そこで変わるのはそのjava.lang.Systemをロードしたクラスローダ配下だけだということが発覚して、撃沈。つまり、Tomcat自身の出力は依然、以前のファイルへ書き出されていたのであった。

_ 今日の誰かが買った本

New Oxford Dictionary for Scientific Writers and Editors(Isaacs, Alan)

Dictionary for Scientific Writers and Editorsというのがあるのか。別にライターやエディターでなくとも、手元にあると便利そうだ。

というわけで、真似して取りあえずカートへ入れた。

_ privateを破壊する

今日も、ばかげたprivateに出会ってうんざりする。

うんざりしながらもとりあえずばかでっかなメソッドをコピペしてしのごうとするが、変えたいフィールドは1つなのに対してメソッド全体を持ってくると4〜5個所もprivateなフィールドをいじっていて、フィールドのオーバーライドでしのぐのにも手間がかかり過ぎる。

しょうがないので伝家の宝刀を抜くことにした。

    ....
    Field f = FooBar.class.getDeclaredField("prapra");
    f.set(this, apropsPrapra);

で、IllegalAccessExceptionになって、ああ、忘れてた（FiledクラスのJavadoc見ながら書いていたので基底のAccessibleObjectクラスのメソッドを忘れてた）と、

      ....
      Field f = FooBar.class.getDeclaredField("prapra");
      f.setAccessible(true);
      f.set(this, apropsPrapra);

としても、やはり例外を食らう。はて、と見るとIllegalArgumentExceptionで、なんでだろうと不思議に思う。
で、良く読むと

  class Inner {
      ....
    protected void setupFields() {
      ....
      Field f = FooBar.class.getDeclaredField("prapra");
      f.setAccessible(true);
      f.set(this, apropsPrapra);

と、ビルダクラスをインナークラスとして実装していることに気づく。6インデント位置のメソッドなのだがアウタークラスのメソッドのつもりになっていた。

そういえば、これ書いたやつは2インデントだったっけ、と思いだす。インデント幅は個人の趣味なので、最初にソースコードを書いたやつの専権事項とするルールを作ったが、はじめてインデント幅でだまされるというのを経験した。でもまあしょうがない。

    f.set(FooBar.this, apropsPrapra);

として、無事完了。

しかし、private修飾子って、ほんとにただの癌だな。余計な手間をかけさせられた記憶はあるが、役に立った記憶はただの一度たりとも無い。

_ ハチ

リチャードギアのハチ公の映画を観に行った。

秋田犬は歴史上最初の飼い犬だとか、4000年の歴史があるとか（でたらめ日本書紀でさえたかだか2650年程度なのに）とか（400年の書き間違え/読み間違えだとしたら佐竹氏の闘犬の歴史と等しくなるから意味が通る）、八という字は上って下がる縁起の良い字とか（末広がりという概念は通用しないのだろうか）とか、嘘八をとうとうと語る日系人の友達がいい味を出していたり、リチャードギアが好好爺然としていい味を出していたりする映画。

_ ハチの続き

元の映画は観てないから、元々、そういうシナリオだったのかも知れないが、シナリオはただ一点を除けば好きだ。嫌いな一点は、最後の最後になって、ちゅーせーしんという嫌な言葉が出てきたことだ。英語でなんといったかは聴いてなかったのでわからないけど。

一貫して、犬がリチャードギアを選んだ、犬が好き好んで迎えに来ている、なんだか良くわからないが誇り高い（ボールを取ってこさせようとしても取って来ないので代わりにギアが取ってきたり、娘のボーイフレンドが取って来たりするのだが、このボーイフレンドの描写は奇妙だが、もちろんボールのエピソードは日系人の友達の話とあわせて物語的な核心になる）ということにしているので、それに対してちゅーせーしんというのはそぐわない。忠実ということにはなるのだろうけど。でもボールのエピソードから明らかにわかっているはずなので、犬自身の何かに忠実なのであって（でも、結局はギアのことが好きだという自分の考えに対してなので、同じこととも言えるけど）、それはいい感じ。

元のお話にしてみれば、時代的な背景がちゅーせーしんを強要する時代なので宣伝に利用されてもしょうがない（1930年代だ）のだが、そういうことにはしていないから、突如、子供の口からちゅーせーしんが出てくるのは奇異な感じ。

あと、ローカル紙に取り上げられるということに対する駅周辺の人々のナイーブさが、いつの時代か、いやいやどうみても現代だけど、2時間に1本しか列車が来ないとか、こういう日常があるからこそ東海岸の田舎町を舞台にする必要があったのだろう、とか。

_ Ruby3

プログラミング入門シリーズのRuby3がアマゾンで予約可能となりました。

CD付 Ruby 3 オブジェクト指向とはじめての設計 (プログラミング学習シリーズ)(arton)

実物は手元にも来ていないけど。

でもまあいいか。

ふつぱいらの青木さんのひそみにならって保護者（プログラミングの本を「自分よりできる人」に勧められて買うという場合の「自分よりできる人」を指す言葉らしい）用の解説を書いてみる。

1章と2章は、いわゆるオブジェクト指向プログラミングの説明です。いわゆるということは、カプセル化、継承、ポリモーフィズム、犬だ猫だ哺乳類だのやつ。Ruby1,2,3は、コンサバなプログラミング入門書というのがコンセプトだと思っているから、これは当然。

すでにこの時点で保護者の何割かがうんざりするのが手に取るようにわかるけど、普通の保護者はこれらの言葉がなければそれをオブジェクト指向プログラミングの本だとは思わないとおれは思うからだし、書いてみてわかったけど、自分でも驚くくらいえらくまっとうな説明ができたので、ということで古典的に始めています。結果的にOOP（ほんの少しOODを含む）の解説としては、自分としては会心のできだと自画自賛。

1章の内容は、Ruby1でサンプルにしただらだらした手続きだけのプログラムに、クラスと属性を導入して、まずはクラス定義の説明。次に、オブジェクト指向プログラミングによってプログラムの構成がどう変わるか、では変えてみましょう、というところまで。

2章で、でもまだ構成が整理されていないわけで、整理するということはどういうことかというとこういうことだと、継承を利用して2つのクラスに分離して示してから、でも重要なのは継承ではなくポリモーフィズムですよ、とダックタイピングとコンポジションを使って書きなおしたところで、次の段階へ。

3章、4章はるいもさんのターン。犬猫の世界から責務分割とデザインパターンのごく最初のあたり。とはいえ、いきなり抽象的にしてもついていけない（というよりもサンプルプログラムの長さを考えても具象性が必要だと思う）だろうから、デジタル回路を例にしています。歯ごたえが程良くあるので、良い感じだと思います。

ここまでで、基礎的なお話は終わり。

残りは、フレームワーク（制御の逆転なくしてOOD/Pなし）、ユニットテスト（これは最重要だけどフレームワークの後にしたのはテスティングフレームワークにつなげるためでもある）、メタプログラミング（の初歩の初歩。パラメータファイルを例にしたしょぼい例だけど、ここでは同じことを方法を変えて何度も書き直すのでユニットテストの後の必然もある）が各1章ずつで全7章。

というわけで、まずは書店で見かけたら手にとって見て、ついでに買っていただけると幸いです。

_ 子供たちのヨーロッパ

友人に借りたイル・トロヴァトーレを観て、あまりの恐るべき（まさに怖いの意味と、ばかばかしいほど極端の2つの意味）悲劇に凍りつく。

ヴェルディ:歌劇《イル・トロヴァトーレ》全曲 [DVD](カラヤン(ヘルベルト・フォン))

それにしてもカラヤンとドミンゴの組み合わせは絶妙だ。

カバイヴァンスカというのは初めてだが、美しいソプラノ歌手の典型のような人。

ただ、なんでヴェルディをあまり好きではないかもわかってきた。

親しみやすいメロディの美しいアリア、そこに逆方向の心情の歌がかぶり2重唱、3重唱になり、さあ盛り上がってまいりました、まいったか、でチャチャチャーンと見事なオーケストレーション、でチャカランチャカランパパーパパー、の繰り返しだからだな。素晴らしき名人芸。

_ かっこ悪いこと

コジョカルとコボーを主演に迎えた眠れる森の美女を観に上野。

マラーホフ版はなんか寒々とした（しかし踊るための平面を大きく確保したとも言える）舞台だし、妖精たちが全員同じような色の衣装なせいもあってプロローグが平板な印象を受ける。その分、カラボスが異彩を放ちまくるとも言えるけど。マラーホフ版がすばらしいのは、退屈きまわりない(かんきまわりないタイポ)2幕をアタッカに毛が生えた程度に省略していることだ。

とにかくえらく混んでいて、元々チケットもNBSのWeb予約に失敗して、ぴあでは売り切れ、辛うじてe+で5Fの後ろが取れるだけ（しかも並びが取れなかった）という状態で、どのくらい混んでいたかというと、男性用トイレはB1除いてすべて女性へ解放するというくらい混んでいた。そのせいでいつもはがらがらな男性トイレがうんこおじさんの行列で満杯していた。おっかねぇなぁ。

で、第一幕まで音楽は頑張っていたと思うけど、なんか舞台が遠い（でもド真ん前見下ろしで、実はへたな2FL側なんかよりよほど見やすいような気もするが）からか平板なところに、真っ白な衣装でコジョカルが出てくると突然いきいきした感じになって、驚いた。きびきびはきはき動きにメリハリがあるのかな。ただ、大技繰り広げのような踊りではなく、うまい人がきちんとやってるだけという感じもする。

で、休憩の間に外に出ていると、年取った大先生らしきおっさんと、それを取り巻く数人のおばさんの集団が近くにいて、大先生が大きな声で、「最低だね最低」を連発していて、うっとおしいながらもほほえましく聞いている状態にされてしまった。「まあ、最低だね。妖精は最低、なんちゃらは最低、なんとかも最低、コジョカルだけだ」と吐き捨てまくっている。ふーん、年寄りなら20年前、30年前より、ばかばかしく技術も体型も向上して、これが最低なら君の世代はなんなのかなぁとか聞いていると、ついに舞台美術にまで最低論が移る。「こんな最低なの観たことないね。衣装は最低、舞台も最低、幕のあの下品なのはなにかね？ クリスマスツリーじゃあるまいし緑に赤でバラなのかバカなのか最低以外の何物でもない、まったくこれだからもにゃんもにゃん」

すかさずおばさんの一人が愛の手を出す。合いの手かも。

「あの幕はマラーホフの指定でしょう。マラーホフ演出だし」

「マラーホフ……いや、そんなことはないでしょ。あんな下品な」

「でも、マラーホフ版のインタビューのときの背景にもわざわざ利用していたし……」

おれは当然、おっさんは、そらみろマラーホフってそもそも名前も下品だし、そんなマラーはシャルロットコルデを遣わせて成敗してくれるわ、とかなんとか言いまくることを期待した。

だが期待は裏切られた。

その後、おっさんは貝になってしまった。なんだ甲斐性がない。自分の美学に基づいて最低論を垂れているのではなかったのか。単に外から来るものはすべて良しとする黒船待望論者だというだけなのか。

見損なったぜ。

というわけで、最低論を吐くのなら、自分の観点から垂れて欲しいものだし、そうあるべきだな、と他山の石。

で、コボーは普通にうまいし、宝石が出てきたら普通にうまいし、青い鳥のカップルは楽しいし、赤ずきんのショールはマラーホフの下品なジョークが効いているし、シンデレラの音楽は好きだし、楽しかった。

にしても、去年だか夏の夜の夢のコジョカルを観に行ったときはこんなに混んでいなかったことを思うと、なんでこんなに混んでいたのだろうか。8/15という日付に関係しているのか、コボーがすごい人気なのか、1年の間に何かがあったりしたんだろうか、とか、不思議に思った。

で、夜の動物園で、ツキノワグマの家の窓にかぶりついて、立ったりうろうろしたり葉っぱ食ったり、窓からこっちを観たりするのを思う存分眺めてから上野を後にした。

_ ブルレイ

リゴレットが観たい。

モダンな演出のやつ。

こないだ、友人宅で観せてもらったフローレスがマントヴァ公爵やったようなやつ。あれは演出が実に良かった。

で、アマゾンを探すのだが、ジャケット写真を見る限り、どれもこれも19世紀から時代の流れが止まったようなのばっかりでうんざりする。

でも、このしょぼくれた執事のような服着たリゴレットはなんだろう？ とえらく気になるのがあった。

ヴェルディ:歌劇「リゴレット」 [Blu-ray](-)

が、これはしたり、ブルーレイ。DVDでも出してくれないかなぁ。

_ ラ・ボエーム

Rigoletto [DVD](Verdi)

結局マクヴィカー版を買おうということで、同じリージョン2のUKに行ったら安くない(GBP 24.49)。FR行ったらもっと高い(EUR 63,00)。ヨーロッパの若者はDVDを買えないだろ。大人でもほとんど買えないんじゃないかというか、ごく少ない富裕層が山ほど買うことで支えている市場なんだろうか。

で、USへ行くと普通に売っている($26.99)。リージョンも今はほとんどフリーなんだな。日本とかUSは文化的に平坦な印象があるが、価格的にもそのとおりなようだ。

で、USでオペラを買いまくろうとしたらヴェルディだらけになった。送料のこともあるのでバランスを取ろうとネトブレコのボエームを買おうとしたら、存在しない。

ラ・ボエーム デラックス版 [DVD](アンナ・ネトレプコ)

日本では予約可能でUKでは売っている（たいして値段は変わらない）。しかしUSには無い。そういうこともあるんだな。

_ JavaプログラマのためのLisp入門

LET OVER LAMBDAが届いたので読み始めたらめっぽうおもしろい。

著者は、『はじめに』の時点から突っ走る。

知性を持つプログラマが、いったんプログラミング行為を論理的手続きと考え始めれば、その手続きの論理的な次のステップは、自動化そのもので利益を享受することである。結局、プログラマはまさにこの自動化工程を遂行すべく訓練される。

そのためにはLispだしマクロだと主張する。というのは、

メタプログラミングは、すべてのプログラミング言語で多かれ少なかれ採用されている。だが、Lispほどそれを徹底して取り入れた言語は他にない。他のどんな言語も、メタプログラミングテクニックに都合の良いコーディングをプログラマに要求したりはしない。だからこそ、非LispプログラマからはLispプログラムが奇天烈に見えてしまう。Lispコードがどう表現されるかは、Lispのメタプログラミングの要求から来る直接の帰結なのである。

Lispコードそれ自体にある。

この本は、Lispのマクロの本だが、「はじめに」で大上段に構えているように、プログラムコードをプログラムすること、つまり自動化、メタプログラミング、言語内DSLの考え方の本としても読める。その点と、その薄さ（本文だけなら300ページ弱）から、実のところ、この本を本当に読むべきは、一番層が厚いわりには中級者あたりのところで止まっている人が多そうな言語、つまりJavaに熟練したプログラマとかではないかな、とも思える。

が、もしLispのことを(カッコ 多い (奇妙p 言語)))くらいしか、知らなければ、そもそも読みようがない。それに、たぶん、その後もLispを使い続けることもないのではなかろうか。とすれば、この本を読むために、Lispの入門書を頭から読んだりするのは時間が無駄だろう。

記法については、適当に探せばいくらでも見つかるわけだから、Lispのコードとはどういうもので、なぜそれが「メタプログラミングテクニックに都合の良いコーディング」なのかを押さえておけば良いのではないだろうか。

というわけで、Lispがどういう言語かについて解説する。

LispはList Processingという名前の通り、リストを操作するための言語で、プログラム自体がリストで構成される。

リストとは、要素の繋がりのことだ。

その要素を格納するために、コンスセルを利用する。Javaで実装するとすれば、以下のようになる。

public class ConsCell {
    Object car;
    Object cdr;
    public Object getCar() { return car; }
    public void setCar(Object o) { car = o; }
    public Object getCdr() { return cdr; }
    public void setCdr(Object o) { cdr = o; }
    public boolean isNil() { return false; }
    public boolean isList() { return true; }
}

今、3要素、0,1,2を持つリストを作るとする。すると、以下のようになる。

ConsCell elem1 = new ConsCell();
ConsCell elem2 = new ConsCell();
ConsCell elem3 = new ConsCell();
elem1.setCar(1); // auto boxing
elem1.setCdr(elem2);
elem2.setCar(2);
elem2.setCdr(elem3);
elem3.setCar(3);
// リストをプリントする
System.out.println("(");
for (ConsCell c = elem1; c != null; ) {
    System.out.println(c.getCar())
    c = c.getCdr();
    if (c != null) {
        System.out.println(" ");
    }
}
System.out.println(")");

各コンンスセルは、cdrフィールドで連結される。最後のコンスセルのcdrはnullなのでそこがリストの終端となる。

このように、リストは、0個以上のコンスセルから構成される。ここで、0個以上というのは重要で、特に0個のリスト（空リスト）をNILと呼ぶ。

リストを構成するコンスセルに対して、それ以外をアトム（原子のこと。それそのものでしかない）と呼ぶ。上の例では、1とか2とか3はアトムだ。文字列もアトムだ。

そして、重要なアトムがある。それはNILだ。

NILは空リストなので当然リストだ。しかし、コンスセルではない（0個のコンスセルと言っても良い）。したがって、アトムでもある。

もっとも、本当に空でアクセスすると例外となるJavaのnullとは異なる。NullObjectパターンの実装を考えると、より近いものとなる。

public class NIL extends ConsCell {
    private NIL() {}
    public final static NIL NIL = new NIL();
    public Object getCar() { return this; }
    public void setCar(Object o) { ; }
    public Object getCdr() { return this; }
    public void setCdr(Object o) { ; }
    public boolean isNil() { return true; }
    public boolean isNil() { return true; }
    public boolean isList() { return true; }
}

NILクラスの導入により、元のConsCellクラスの実装は以下となる。

public class ConsCell {
    Object car = NIL.NIL;
    Object cdr = NIL.NIL;
    public Object getCar() { return car; }
    public void setCar(Object o) { car = o; }
    public Object getCdr() { return cdr; }
    public void setCdr(Object o) { cdr = o; }
    public boolean isNil() { return false; }
    public boolean isList() { return true; }
}

Lispのプログラムは、これらのオブジェクトを利用して記述する。

たとえば、以下のプログラムは1と2を加えた結果を返す（Lispは最後に評価した結果を返す）。

(+ 1 2)
* 3  ←結果

このプログラムは、概念的には（実際には機械語などにコンパイルされるからだが）、以下のようにコンパイルされる。

top = new ConsCell();
ConsCell elem2 = new ConsCell();
ConsCell elem3 = new ConsCell();
top.setCar(+);
top.setCdr(elem2);
elem2.setCar(1);
elem2.setCdr(elem3);
elem3.setCar(3);
Method m = top.getCar().getMethod("default");
return m.invoke(elem2);

すべてのリストは先頭要素で指定した関数に対して、2番目以降の要素を引数とした関数呼び出しとなる（マクロに展開されることもある）。関数を呼び出して結果で置き換えることを「評価」と呼ぶ。

ただし、先頭に「'」（クォート）を付けてクォートすると評価をスキップできる。

'(+ 1 2)
* '(+ 1 2)

なぜ、この仕組みが「メタプログラミングテクニックに都合の良いコーディング」なのだろうか。

それは、プログラムが最初からリスト（というデータ構造）で示されているからだ。

ほとんどのプログラミング言語は、テキストとして記述されたプログラムを処理系が内部で処理する。かりにソースをプログラムから操作したい場合、それはテキスト処理となる。

それに対してLispではソースをプログラムから操作したい場合、それはリスト処理となる。そして、Lispは元々リスト処理に特化した言語である。したがって、メタプログラミングテクニックに都合が良いのは当然である。

LET OVER LAMBDA Edition 1.0(ダグ ホイト)

_ Java6のジェネリクス

今日のコンパイルエラー。

public class Foo {
    public void addSome(List<Bar> list) {
        ....
    }
    public void addSome(List<Baz> list) {
        ....
    }
}

コンパイルしたら

Foo.java:3: 名前が競合しています。addSome(java.util.List<FooBar.Bar>) と addSome(java.util.List<FooBar.Baz>) は削除後の名前が同じです。
    public void addSome(List<Bar> list) {
                ^
Foo.java:6: 名前が競合しています。addSome(java.util.List<FooBar.Baz>) と addSome(java.util.List<FooBar.Bar>) は削除後の名前が同じです。
    public void addSome(List<Baz> list) {

使えねぇなぁ。
すげぇいやだけど

public class Foo {
    public void addSomeBar(List<Bar> list) {
        ....
    }
    public void addSomeBaz(List<Baz> list) {
        ....
    }
}

と修正。
本当に見てくれだけなんだな。

_ 椿姫

子供にねだられてパリ・オペラ座バレエの椿姫を買ってやったら、おそろしくできが良く、どえらく気に入った。これは美しい。

La Dame Aux Camelias/ [DVD] [Import](Agnès Letestu)

まず舞台がシンプルで、確かにゼッフィレッリのアイーダみたいなスペクタクルは嫌いではないのだが、それでも先日の東京シティバレエのロミオもそうだが、おれは抽象的な舞台が好きなのだと再確認。

東京流れ者の木村威夫ファンだしな。

確かにできの良いプティパは観ていて嫌いではないのだが、モダンな舞台のほうがしっくりとくる。

同時にマノンレスコーと椿姫が進行し、情景はフラッシュバックで構成されているため、お話を良く知らないとついていけなくなるかも知れないが、そこはばかみたいに単純素朴な椿姫の物語なので気にせず突っ走れる。

2枚組DVDで、2枚目で演出家のノイマイヤーやダンサーがいろいろ語るのが入っていて、ここではノイマイヤーが多分、フランス人のためにえらくわかりやすい英語で話すので（意味も明確になるように考えているのだと思う）日本語字幕とか入ってなくても十分に聴ける。というか、ノイの部分がノイだからドイツの人なのかな？

で、椿姫を踊る女性（アニエス・ルストゥツと読むのか？）が背が高くて、どうも最近小柄なバレエダンサーばかり見ているからか（したがって、あまり背が高いダンサーは居ないとか考えていたらしい）、最初違和感があった。が、演技がかっちりとできる分、年取っても仕事ができそうに思える。というかえらく美しい人だ。

ということもあって、いずれにしろこれは大人のバレエだなと思う。ベッドに転がったり服を脱がせたりするし。それが痛切だったりするのだから表現力はすばらしい。特に、親父に説得されて別れたものの、最後の一度だけ燃え上がるところの凝集性はおそるべきだ。黒い服ということは喪服だが弔っているのは自分たちの愛ということだろうが、それを一度は脱ぎ捨てて、しかしまた大慌てで身にまとい去っていき、そして2度とは遭うこともなく、一人で死んでいく（メイドさんはいるけど）。

（白塗りがきついこともあって、暗黒舞踏の表現力を想起したりもする）

主役はほとんど出ずっぱりだからすさまじく体力も消耗しそうで、特にアルマンは大変そうだ（デグリューも同時にマルグリットとマノンを運ぶところがあって、これはこれで重労働）。

それにしても、つくづくバレエという表現芸術も奥が深いものだな。

_ 特化

派生先でインターフェイスを絞るのはありだと思う。逆に実装にとらわれ過ぎているのではないだろうか。

WEB+DB PRESS Vol.52(矢野 勉)

携帯からうちこむには長過ぎる。

_ Struts 1.2（3かも）のActionMessage

エラーメッセージをActionMessageに入れて処理したい。

この時、エラーメッセージはリソース（プロパティファイル）に入れておきたい。

で、そのメッセージが「かっこは[]{}()が使えます」だとする。

当然、プロパティファイルには、message.kakko=かっこは[]{}()が使えます とか書いて、それをnative2asciiしておく。

これが例外となる。

MessageFormatが、{}に数字がないのはIllegalArgumentだと言うからだ。それは正しい。

そこで、「かっこは[]'{}'()が使えます」と、クォートする。こないだ覚えたから問題なし。

しかしうまくいかない。同じく例外となる。どうもStrutsが消費しているような気がする(つい調べてしまったらMessageResourcesのescapeメソッドで''を作っているからだ。プロパティファイルをMessageFormat透過にしようとしているのだと思う)。たとえば、「笑顔の値段は\2です。」としたのが「笑顔の値段は2です。」となったりするので、「笑顔の値段は\\2です。」とする必要があるのと同じく何かをStrutsがやっているからだろう。

そこで、「かっこは[]{0}()が使えます」として、"{}"を与えることを考える。

これは多分うまくいくと思う。しかしねぇ、ActionMessageを作る処理の中で、常に"{}"を引数として与えるというのも妙だ。かといって、文字列の中に{0}が存在したら"{}"を与えるというのも気に食わない。

そこで、常に new ActionMessage(msgresource.getMessage(key).replace("curlykakkokokka", "{}"), false)としてみる。プロパティの中で{}の代わりにcurlykakkokokkaを書くことにするわけだ。

と、書いてみるとこれで良さそうだが（なぜそうしなかったのか覚えていないが）、最終的にはActionMessageを継承してgetKeyの時点で上記を実行するようにして逃げた。

しかし、MessageResources#setEscapeをあらかじめfalseを引数にして呼んでいれば良かったことに気づいてしまった。というか、今、MessageResourcesを読んで気づいた。明日、修正しよう。

_ メンドーなことは一度で十分ですよ

繰り返しは悪なので、エディターの指使いなんていう面倒なものは1度しか覚えなかった。

したがって、^pとか^fはあってもkとかl(とか空白とか）のことは何も知らないのだが、それにしてはvimvim言う人は後を絶たない。

まさに読んでいるLOLの人はnvinvi言っているけど。

居心地の悪いemacsのキーコードの並びの代わりに、viは強力なモーダル設計によって透過的かつ効率的に、単純にも複雑にもテキスト操作を実行することができる。

多分、単純にも粗雑にもの書き間違いだとは思うけど。

LET OVER LAMBDA Edition 1.0(ダグ ホイト)

で、不思議なのは、viみたいに使いにくいものに一定以上の愛好家がいるということだ。そこにはオリジナルの作者がビルジョイだということ以上のなにか玄妙なマジックがあるんだろうと考えずにはいられない。

で、WEB+DBの52にはちょうどVimの流儀という特集があるので、読むことにした。

WEB+DB PRESS Vol.52(矢野 勉)

で、いろいろ知ったのだが、やはりぴんと来ない。

Emacsが良いところは、elispでもなければ作者がRMSだということでもない。^X-o と^x-2、^x-1、^x-0、^x-b、そしてM-x shellだ。これらのキーは、Alt-Tabより1000倍以上高速にタスクを切り替えられる。しかもタイルウィンドウなので、切り替え後にすぐに作業に入れる。マウスとかAlt-Wのなんちゃらとかとは全く異なる。

でも、とりあえず:helpしてしばらくvimvimしてたら^w-nとか^w-kとかわかって、しばらく使ってみたりしたが、wってxより左ctrl（当然最左最下のキーのことで、Capslockのことではない）から遠過ぎてキーコンビネーションとしては、^-5や^-6と同じくらい非現実的だ。

というわけで、やはりEmacsが一番だなぁと（デフォルトで使えるほうが楽だし）。

#逆も真で、Ctrlが大文字化キーに化けている環境なら、vimのほうが使いやすそうだな。

_ Youtubeのコメント

問題を解決する: コメントが動画に表示されない

コメント テキストに URL や HTML タグなどの特殊文字が含まれていないか確認してください。

この記述を読まずに小一時間悩んだ。

_ メモ

買おうかどうか迷っている。

Wiiであそぶ ちびロボ!(-)

それともこっちか。

おかえり! ちびロボ! ハッピーリッチー大そうじ!(-)

しかし本命は、これだったり。

iRobot Roomba 自動掃除機 ルンバ 530J 白色(-)

_ 今日のバグ

一見すると（と書いたが、実はそうでもない）バグがないように見えるバギーなプログラム。
たとえば、\0を含んだバイト列を文字列として（\0までの）長さを求める処理。

int foobar(unsigned char* ptr, int len)
{
    int i;
    unsigned char* p = ptr;
    for (i = 0; *p != 0 && i < len; i++, p++);
    return p - ptr;
}

大体、正しく動く。

#include 
int foobar(unsigned char* ptr, int len)
{
    int i;
    unsigned char* p = ptr;
    for (i = 0; *p != 0 && i < len; i++, p++);
    return p - ptr;
}
int main(int argc, char* argv[])
{
    unsigned char a[] = "abc\0def";
    printf("len = %d\n", foobar(a, sizeof(a)/sizeof(a[0])));
}

実行すると

c:\test>cl len.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
 
len.c
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
 
/out:len.exe 
len.obj 
 
c:\test>len
len = 3

だが、あるときバグが発現する。しかし、それまで10年以上元気に動いていたという事実から、なかなかバグに気づかない。ということもある。
ではどのあたりでバグが発現するか見てみる。

#include 
#include 
int foobar(unsigned char* ptr, int len)
{
    int i;
    unsigned char* p = ptr;
    for (i = 0; *p != 0 && i < len; i++, p++);
    return p - ptr;
}
int main(int argc, char* argv[])
{
    int i;
    unsigned char* p;
    for (i = 16300;; i++) {
        p = (unsigned char*)malloc(i);
        memset(p, '\xff', i);
        printf("len = %d\n", foobar(p, i));
        free(p);
    }
}

実行すると

...
len = 524251
len = 524252
len = 524253
len = 524254
len = 524255

で終了。思ったよりももったが、つまりは524256バイト与えたところで死んだことになる。
クイズ：524256から、Windows(またはmsvcrt)のメモリーアロケータが管理のために利用する領域のサイズを推測してみよう。
考察：言語仕様を知っているかどうかということではないか？

_ ムオームオーなベルリオーズ

最近、子供が図書館でCDを借りまくるようになって、ベルリオーズの幻想交響曲を借りてきた。

ガーディナーとかいう（おれは初耳の）指揮者のやつだ。

Sym Fantastique(Berlioz, H.)

これが、むちゃくちゃに変だ。

ベルリオーズの幻想交響曲はいろいろな意味で変なのだが、それにしてもおかしい。

まず、この指揮者は古楽器野郎だ。でもベルリオーズは前期ロマン派だし、そこに古楽器の出る幕はあるのか？

と思うと、ライナーを読むとあるらしい。

ベルリオーズが変な点は山ほどある。まずこの男は医学生で解剖がおっかなくてドロップアウトして作曲家になったという中途半端な学歴の男で、当然のようにクラシックの英才教育を受けたわけでもなんでもない。それが理由というわけでもないだろうが、当然のように当時の作曲家だったらピアノを弾けるのに、ギターしか弾けない。

そのため、頭の中の妄想管弦楽になる（のだと思う）。しかし、ベートーヴェンマニアだ。ベートーヴェンを研究しまくる。もちろんベートーヴェンはピアノ男だ。しかし、ギター男にはピアノ男の響きは出せない。代わりにピツィカートやらはてはコルレーニョやらを多用した妙な響きで満ち溢れた曲を作ることになる。それにしても絶妙。ベルリオーズがいなければ、おそらくフランス人は交響曲に目覚めず、そうであればフランクやサンサーンスの魅力的な曲もないかも知れず、ベルリオーズがいなければ同じ主題（運命の動機よりもはるかに大きな単位）が出たり引っ込んだりを堂々とやれず当然フランクもいなければリスト（ロ短腸ソナタ）もいなくて、するとへたすればヴァグナーもいないし、というような音楽史的には革命家、作曲家としてはそれほどすごいとも思えない（リストやヴァグネルに比べれば特別な二流というところだろう）、という実におれの好みの作家である。

というような感じで、これまで結構、聴いてきた。最初に聴いたのはオーマンディがCBSで録音したやつで、今考えても立派なスタンダード（中学生のころのはずで、1月に1枚しかレコードを買えないのでそればかり聴くことになるので、ほぼ覚えたはず）、それからバルビローリとハルレのモノラル録音であらゆる弦がポルタメントするという異様なもの（アムステルダムコンセルトヘボウみたいにうまいわけではないのでずっと聴いていると酔ってしまい気持ち悪くなる）、バレンボイムの普通の名演（まったく印象がない）、そんな感じ。死ぬより遅いブーレーズは話でしか聴いたことはないが、4楽章だけはFMで聴いた記憶があってなんかテンポとか覚えているんだけど気のせいかも知れない。

ガーディナーのはそれらのどれとも異なる。異様に遅い。しかし、実際には遅くはない。響きが古楽器のせいだと思うが、途中で途切れてしまうので演奏に間が入るのではないかと思う。それにところどころにムオーンムオーンという妙な低音の笛のたぐいの音が入るのだが、なんだかさっぱりわからない。

しかも、それが結構に魅力的なのだ。古楽器と現代楽器の軋みというようなことを標榜しているらしいが、軋みというよりももっと遥かに肯定的な響きがある。

それにしてもムオーンがなんだかわからなくて気持ち悪い。多分、オフィクレドかセルパンとからしいが、そう書かれていてもさっぱりわからないし、やたらに想像力が刺激される。

で、アマゾンで眺めるとDVDが出ているのだな、これが。

ベルリオーズ:幻想交響曲 [DVD](ガーディナー(ジョン・エリオット))

きっとこれを手に入れればムオーンムオーンがなんだかわかるに違いないと思う反面、それほどには幻想交響曲という曲は好きじゃないんだよなぁとも思うわけで、これも迷うなぁ。

_ メモリ参照は後にする

王様がリンクしているので、まじめに書いてみる（意図を誤読しているかも知れないけどまあいいや）。

なんとなく16K境界で発現しそうに思ったら、思いのほか伸びたので途中から別の話になってたし。

問題は指定された長さのメモリーブロック内の文字走査の書き方だ。

int foobar(unsigned char* ptr, int len)
{
    unsigned char* p = ptr; // 元のポインタ値を保持するためにインクリメンタル用ポインタを別に用意する。
    for (int i = 0; *p != '\0' && i < len; i++, p++); // 0が現れるか指定長に到達するまでpを後ろへ移動する。
    return p - ptr;         // 元のポインタとの差=ターゲット文字までか、または元のメモリーブロックの長さを返す
}

バグは、for文の条件式にある。

今、foobarに長さ2バイトのメモリーブロックを与えるとする。ターゲット文字（この例では0）は含まない。

unsigned char a[] = "\xff\xff";
printf("len=%d\n, foobar(a, 2));

ここで、aがポイントするアドレスを0とする。
すると、unsigned char* p = ptr; で、pには0が入る。

forの最初の時点でiは0、pは0、lenは2となっている。

条件式を実行すると、pは0(ということはa[0]なので'\xff')、iは0なので条件は成立せず、継続式に制御が移り、pは1、iは1となる。

条件式を実行すると、pは1（ということはa[1]なので'\xff')、iは1なので条件は成立せず、継続式に制御が移り、pは2、iは2となる。

条件式を実行すると、pは2（ということはa[2] --- バグ　----)仮にa[2]相当のメモリー位置の内容が0ならforステートメントを抜ける。そうでなければiは2で、lenの2と等しいためforステートメントを抜ける。

現在のpの値2から、ptrの値0を引いた値2が戻り値となる。

ここで、このバグがほとんど(見た目上)発現しないのは、条件式の左項が成立してもしなくても、右項のi < lenにより最終的にforステートメントを抜けることができるからだ。

しかし、メモリーアロケーションの結果、ptr + lenの位置がページ境界で、かつ以降のページが未割当ならば、i == lenの時点での条件式の左項は、未割当メモリーに対する参照となり、バグが（見えるかたちで）発現する。

正しいプログラムであれば、条件式は、i < len && *p != '\0'のように、最初に長さの比較をし、次に（左項により*pが安全なアクセスであることを確認できた後に）メモリーの参照を行う。

この形式で記述できるのは、Cが、条件式をショートカットするからだ。ショートカットにより、左項の条件が満たせなかった場合、つまり、iがlenと等しい＝pが与えられたメモリーブロックの範囲を超えた位置を指している場合は右項の実行を回避できるからだ。

（ショートカットしない言語、具体的にはVBで、つい、i < len and a(i) <> 0 みたいな条件式を書いてIndexOutBoundExceptionみたいな例外で死んだことがあるので、言語仕様を読むのは重要ですなぁと）

あと、JavaとかC#とかインクリメンタル操作とかが可能なポインタが無い言語では、同じようなことをするには配列を使うしかないので、当然、IndexOutOfBoundExceptionみたいな例外をさっさと食らえるので（ユニットテストとかまじめにしていれば）この手のバグが入り込む余地はない。というわけで、ああいう言語は楽ですなぁと思う。

_ Cが低レベルなわけ

忘れてたけど、上のバグは慣れればすぐわかるのだが、しかし犯しやすい。

なぜなら、*p != '\0' && i < lenのほうが自然な記述だからだ。

というのは、ここでやりたいこと、主要な機能は、iがlenの長さになるまで、ではない。*pに'\0'が見つかるまで、だ。

関数コメントを1行で書けば、「与えられた文字列内の'\0'までの長さか、見つからなければ（と条件つきで）その長さを返す」になるだろう。

つまり、重要な機能を最初に書くのは、むしろ良い習慣だから、或る程度プログラムが書ければ逆に書いてしまうし、プログラムの機能を読めば見過ごしてしまいかねない。

というわけで、String#indexOfだとか、Array#find（あるかどうか知らないけど）とかのメソッドが用意された言語のほうが良い言語だし、自前でループ書くより用意された（名前がついた）メソッド使え、というような話になるのだ、と思う（けど他にも理由はあるから言い切れない）。

そのあたりが、Cのだめっぷりということになるんだけど、逆にその生々しさがCの魅力でもあってとっても悩ましい。というか、C好きだし。

_ Java三題話

Socket、GC、ulimit。

これから確認。

_ rotatelogs

Tomcatのcatalina.outをSystem.setOutで変えられるじゃんと考えてみて試してみたものの、どうもおかしい。よくよく考えてみればSystemクラスローダがロードしたSystem.outを変えられるわけではないので、あえなく撃沈。

で、しょうがないのでrotatelogsを使うことにする。

で、--helpしてみると、rotatelogs [-l] logname-(strftime strings) (interval [utf diff]| sizeM) となっているので、サイズが100Mとかになったら切り替えられるといいかなぁと、そっちを設定してみた。

| /usr/apache2/bin/rotatelogs -l foobar-%Y-%m-%d 1M

で、1Mで切り替えられるか試す。で、やたらとSystem.outに書きまくるJSPを作って試して、ふと気付くと単に foobar-2009-08-27 というどでかいファイルができている。（しかも-lが効いていないけど、これはバージョンがからむのかな）

なぜだろうといろいろ設定している例とかグーグルさんに訊いてみても、無いし。

期待したのは、1Mを越えたあたりでfoobar-2009-08-27.001とか002とかが作られることだったのだが。

で、いろいろためしていて、何気なくfoobar-%Y-%m-%d-%H-%M-%S とかやったら、ああ、そういうことかと納得したようなだまされたような。

結局、rotatelogsは、与えたファイル名のテンプレートが変化可能かつ与えた条件を満たすときにローテートする。

そのため、24時間相当の秒数を指定しても、最初の作成時点から24時間後ではなく、日付が変わった（%dが変化可能）ときにローテートする、と同じようにファイルサイズについても処理しているのだった。

秒をファイル名に持たれても扱いやすいとは思えないので、%Y-%m-%dまでのファイル名を使って24時間切り替え運用することに決定。

_ LLTV

今日は中野でLLTV。

なんか当日券もあるそうだから、寄席でも冷やかす感じで(もちろん着流しで)ふらりと中野ゼロに行くといいかも。

坂の途中で売ってるラスクがおいしいし。

というか、技術書の新刊買うなら種類が集まってたり、出版者の人とか著者とか翻訳者とかがそのへんをうろうろしているわけだから、（小規模）コンピュータ系技術書見本市としての利用というのもあるんじゃないかなぁ。

_ IDEO

発想する会社! ― 世界最高のデザイン・ファームIDEOに学ぶイノベーションの技法(トム・ケリー)

ネジの気持ちになって公園の中をぐるぐる回る。

スクリューの気持ちになって水の中をぐるぐる回る。

プロペラの気持ちになって大空に向かってぐるぐる回る。

あー目が回る。

_ LLTV

18:00以降が本命という気がしていたが、都合は都合なので、夕休みで離脱。

実のところ午前中で帰っちまおうかと思ったが（というか普段からテレビを見慣れてないんだからしょうがないかなぁとか思った）、志村さん、酒井さんと一緒に昼飯食ったので、そのまま戻ってしまった。

そしたら、クラウドのやつで取り戻して、次のプロトタイピングがどえらくおもしろかった。帰らなくて良かったと志村さんたちに感謝。

クラウドのやつでは、トップバッターの荒井さんがSaaSだのPaaSだのIaaSだのの言葉の定義から入るプレゼンで、結果的にクラウドとは？ の土台を与えるからディスカッションのトップとして良いプレゼンだと思った。

で、高井さんのムードメーカーっぷり（に意識的になろうとしているのか、単に地なのか、時々雪崩のように地滑りもしている）が楽しい。

というか、SIヤーがどうだのとかの話になったときに、「では1000人規模の受託開発案件で、支払いは完成したブツの承認後、となったときに、バッファとしてのSIヤーなしでどうやるの？ 自転車乗るの？ 2年とか3年とか食わずに？」というやたらな正論を吐いて、場を凍りつかせたような。きっと、そういう規模のソフトウェアを想定してないんだろうな。キャパは大規模、機能は小規模とか。iPhoneアプリなんてのはそういう感じだから。とすれば参加者が、大体、クラウドといったときに、どういうソフトウェアを暗黙のうちに想定しているのかが窺えて興味深かったりした。

で、圧倒的にプロトタイピングのやつはおもしろかった。

おれは、Sourceforgeとかgithubとかに誰からも顧みられないソフトウェアが死蔵される状態こそが適正だと考えている(10000の挑戦があってこその1つの果実)。それがハードウェア（というかガジェットというか）で可能となり、どこかの倉庫群（中国あたりかなぁ）がハードウェア版Sourceforgeのストレージとなって何億何兆の（ロット100として、つまり何億ものプロジェクトがある状態）ガジェットで埋め尽くされていて、そしてそういった文化も消え去って数千年後に掘り返されて、オーパーツとしてそのころの人類の心を震わせる世界を夢想して感動した。

_ プライベートクラウド

言われるまでその発想はなかったが、言われるとコロンブスの卵だなぁと思う。

歴史を振り返れば、実に正しい発想で、成功は約束されていると思う。

メインフレームの商用利用、オープンシステムの企業システムへの導入、インターネットからイントラネット、と同じ筋。

1企業グループに10社あり、大樹に寄りかかる中規模業者（独立系）3〜4社の面倒もみるデータセンターとかコンピュータセンターを考えれば、プライベートクラウド(というよりIaaSとかPaaSってことか)というのは必然で、AzureだけじゃなくてGAEにも当然そういうビジネスがあるんだろうな。

_ 並行プログラミングの原理から実践まで

アスキーの鈴木さんからもらって読み始めたが、いきなり1章の練習問題でつまづく。教科書（序文によれば大学の最終年度の教科書兼実務者の参考文献を想定している）っぽく、ぶっきらぼうに問題が出ていて解答はない。

おれの本来の読者（実務者）としての正しい読み方は1章をすっとばして（アムダールの法則は別らしい）、いきなり実践編の並行スタックだとか並行キューとか、プライオリティキューとかを読めば良いのだろうが、せっかくだからまじめに（CSコースの読み方）読んでみようかなぁと。

（もっとも2章の相互排他、3章の並行オブジェクトは基本的に読むべきとされている。3章ではJavaメモリモデルとしてダブルチェックロッキングがなぜ無効なのかについての解説があったりするが、わかりやすい。ただ、volatileフィールドを揮発性フィールド、シリアライザブルを線形化可能と日本語にしているので（教科書としては正しいのかも知れない）ちょっととまどった。特に線形化のほう。このあたりは実務的には理解しているはずなので流し読みでも良いかなぁとか思った。が、練習問題のレベルは別）

プログラミング言語としてはJavaを利用して、扱う範囲としては原理編の最後の章（第6章で、ここまでが全体の1/3）が「コンセンサスの普遍性」として「ロックフリー普遍構造」「無待機の普遍構造」となっている。ここでの普遍性とは、オブジェクトの数が十分であるとすれば、任意の並行オブジェクトの線形化可能な無待機実装を構築可能なことを意味している。

The Art of Multiprocessor Programming 並行プログラミングの原理から実践まで(Maurice Herlihy)

価格の高さは刷り数の少なさを意味するから、2年後くらいには入手困難となりそうな書籍なので、ちょっとでも必要性を感じたら購入しておくべきと思う。

で、つまづいている問題は以下のようなやつ。

P人の囚人の1人と仮定する。

看守が次のように言う。

・今日は戦略を巡らし意見交換可能である。明日からは独房に入り連絡は取れない。

・オンとオフのスイッチを持つ部屋がある。スイッチはどこにも接続されていない。

・ときどき1人の囚人を無作為に選んで、スイッチ部屋へ入れる。囚人はオンとオフの間で切り替えることも、そのままにすることもできる。

・囚人を部屋に入れる頻度は任意である。Nが任意の正数であれば、最終的に各囚人は最低でもN回スイッチ部屋に収容される。

・どの囚人も常に「全員が少なくとも1回はスイッチ部屋に収容された」と主張できる。正しければ、その囚人を釈放する。正しくなければ、全員をワニの餌にする。

問1）初期状態がオフの場合の必勝法を考えよ

問2）初期状態が不明な場合の必勝法を考えよ

ヒント）すべての囚人が同じことをする必要はない

今写して気づいたが、「その囚人を」であって、全員ではないのか。