日々の破片

_ 今日は何の日？

いたずらラッコのバンデッタ

_ スクリプト言語

ううむ、確かに疑う余地が入る余地もなく、スクリプティング言語だけど、おれもト止めをさした覚えがあるなあ。

多分、JavaScriptという言語名かscript要素につられたのかも知れない。

_ Java Sound API

昨日のJava PRESSのkeiskenさんの記事から興味のある個所をRubyに翻案。

require 'rjb'
 
module Java
  File = Rjb::import('java.io.File')
end
module Javax
  #interfaces
  Clip = Rjb::import('javax.sound.sampled.Clip')
  DataLine = Rjb::import('javax.sound.sampled.DataLine')
  Line = Rjb::import('javax.sound.sampled.Line')
  LineListner = Rjb::import('javax.sound.sampled.LineListener')
  Mixer = Rjb::import('javax.sound.sampled.Mixer')
  Port = Rjb::import('javax.sound.sampled.Port')
  SourceDataLine = Rjb::import('javax.sound.sampled.SourceDataLine')
  TargetDataLine = Rjb::import('javax.sound.sampled.TargetDataLine')
  #classes
  AudioFormat = Rjb::import('javax.sound.sampled.AudioFormat')
  AudioInputStream = Rjb::import('javax.sound.sampled.AudioInputStream')
  AudioSystem = Rjb::import('javax.sound.sampled.AudioSystem')
  DataLineInfo = Rjb::import('javax.sound.sampled.DataLine$Info')
end
 
module SoundSampled
  class SoundFile
    include Javax
    def initialize(file = nil)
      file = Java::File.new('/windows/media/ding.wav') unless file
      @ais = AudioSystem.getAudioInputStream(file)
      @clip = AudioSystem.line(DataLineInfo.new(Clip, @ais.format))
    end
    def play(count = 0)
      @clip.open(@ais)
      @clip.loop(count)
      while @clip.running?
        sleep 0.1
      end
      sleep 3
      @clip.close
    end
  end
  class Sin
    include Javax
    FREQ = 1000
    TERM = 5
    RATE = 8000
    DR = 2 * Math::PI * FREQ / RATE
    def initialize
      @format = AudioFormat.new(RATE, 8, 1, true, true)
      @line = AudioSystem.line(DataLineInfo.new(SourceDataLine, @format))
    end
    def generate
      @wave = Array.new(RATE) do |i|
        (Math.sin(DR * i) * 100).to_i
      end
      p @wave if $DEBUG
    end
    def play
      @line.open(@format)
      @line.start
      off = 0
      len = @wave.size
      while len > 0
        written = @line.write(@wave, off, len)
        off += written
        len -= written
      end        
      @line.drain
      @line.close
    end
  end
end
if __FILE__ == $0
#  SoundSampled::SoundFile.new.play
  s = SoundSampled::Sin.new
  s.generate
  s.play
end

_ 不思議な言葉

みねこあさんのとこ読んでたら引用があって、そこで「スクリプト言語というのはフットワークの軽さが売りで、ちょっとしたアイデアをすぐに形にするには都合がよい。反面、刹那的な代物で、保守性に乏しく、巨大で複雑なシステムを構築する言語としては適さない代物です。」という言葉が並んでいる。

メインフレームのREXXとか、まあいろいろ考えるわけだし、

humhum:~ arton$ file /usr/bin/*|grep script|wc -l
     276
humhum:~ arton$ ls /usr/bin|wc -l
     897

と、何気に1/3がスクリプトだったりして、どこが刹那的な代物なのかなぁとか考え込む。

見識の幅って言語の幅に近いのかもなぁ。一言語主義って一面的な見方をしやすいのかも。

30行のスクリプトが300個あって、それが決まった順序でがちがち夜の作業をこなしていったりする現実もあるわけだが、そういうシステムの規模を想像したりすることもないのだろう。

_ 続スクリプト言語

ふと本棚見たら、これがあった。

オブジェクト指向スクリプト言語 Ruby (ASCII SOFTWARE SCIENCE Language)(まつもと ゆきひろ)

_ スクリプティング言語？

プログラムをプログラミングするのがプログラミング言語。

ってことは、スクリプトをスクリプティングするのがスクリプティング言語。

では、プログラムとスクリプトって何が違うのか？

と落とし込んでくと、グルー言語がスクリプティング言語じゃないか？ と思いつき、だからRuby永遠のライバルkshはスクリプティング言語で、（shでもいいわけだけど）/usr/binの1/3を占めることになる。

あたりから、どうもPerlが立派なプログラミング言語でありながら自分をスクリプティング言語とセグメンテーション(追記：ブランディングかも。広まりはセグメントのせいだが、最初はブランディングだろうな)したのがすべての間違いの始まりではないか？ と（勝手にPerlのせいにしたけど、識者の意見が欲しいところ）。

でも、こう書いてきてひとつ気づいたが、トロイの木馬戦略だったんだろうな。つまり、プログラミング言語でありながら、スクリプティング言語を名乗るというのは。

（と、考えていくと、LLと称するのがやはりよさげな感じ）

_ 言語のブランディング

今、上のに追記していて、つくづくと、ブランディングの重要性に気づく。

音でる、絵が動く、簡単、初心者、わかりやすい。習うより先に慣れる。経験主義、具象主義。

つまり、アンチ教養主義、アンチ科学主義。アンチ合理主義。

でも、即物主義ではあるのはあくまでも相手がコンピュータだからだ。

で、そのジャンルはもちろんあると思っていて、例に出しやすいやつだとHSPはそれで良いのだと思う。他にもいっぱいある。アセンブリ言語なんてのも実態はそっちじゃないかな（おれだ）。

問題は、それがサービス（端的にはWebサーバーサイドアプリケーション）になった場合で、今は、ちゃんと考える必要があるわけで、そこをどう越えるか越えられないかとか。

というのはおいておくと、LLというのはそういうブランディング方向を一見すると向いているのに、実際にカンファレンスやるとアカデミックな言語がたくさん出てくるところがおもしろい。そこに何かしらの将来性というか可能性があるんじゃないかと思う。

_ ちょっとしたコンパイル

あなたのエディタで.NET開発

おれ、けっこう、これやるのだが、ワナがある。APIが多すぎるのだ。

だから、ちょろいアルゴリズムのチェック程度だと良いけど、何かそれなりのことをしようとすると、MSDNを見なきゃならなくなるんだよね。

すると、単なるHTMLでJavadocが提供されているJavaより参照速度が落ちるから（MSDNはWeb版もDocviewer版もやたら遅い。少なくともローカルにインストールしたJSEのJavadocやRuby API Refmとは比較にならない）、結局は、Javadoc見ながらRjbという感じになってしまう（Jrubyは最初の起動が遅いから、ちょろいプログラムでは使う気にならない）。

しかも、今はHTML版だって、全文検索エンジンがOSに乗ってるから（GoogleサーチはOSじゃないけど、おれはOS Xは右上の虫眼鏡、Windowsだと犬を使うから、OSで良いだろう）、検索も速い。というか、MSは、全文検索エンジンを信じて、単なるHTMLでMSDNを提供して欲しいよ、本当に。

_ 1.8と1.9で例外が変わっている

次のスクリプトを実行する。

class A
end
A.freeze
class A
  def foo
  end
end

すると1.8と1.9では異なる例外となる。

>\home\ruby\bin\ruby -v fr.rb
ruby 1.8.6 (2008-03-03 patchlevel 114) [i386-mswin32]
fr.rb:5: can't modify frozen class (TypeError)
>\home\ruby-1.9\usr\bin\ruby -v fr.rb
ruby 1.9.0 (2008-03-01 revision 15664) [i386-mswin32]
fr.rb:5:in `': can't modify frozen class/module (RuntimeError)
	from fr.rb:4:in `
'

error.cのrb_error_frozenが変わっているからだ。
こんなのありなのかな？ とちょっと調べるとRuby-RefmのObject#freezeでも1.8と1.9で記述が変わっているし、ChangeLogに明記されているので既定路線のようだ。

_ 無意識ヘテロと無自覚ホモ

Mavenの件とか、木村さんのとこからたどった日本語談義とか見ていると、どうも無意識なヘテロ野郎と無自覚（無意識と同義に使っていながらにして、おれのバイアスを含めることでネガティブな印象操作を意図した言い回し）なホモ野郎がいるようだ。

無意識なヘテロ野郎は、本能的に日本語を回避する。それはこれまで、そのせいでさんざん、差別的な目にあってきたから身に付いた処世術と言える。

たとえば、Mac買って大喜びでサンバでWindowsマシンに日本語ファイル名がついたファイルを書き込んだり、読み込んだりしてみたり、あるいはWindowsでコード書いたJavaのソースファイルをLinuxマシンに送り込んでビルドしようとしてみて失敗してviで開いてみたり、Linuxで書いたHTMLをWindowsマシンのメモ帳で開いてみたりとか、いろいろだ。おかげで、クリティカルなところでは英数字しか使わないし、build.xmlにはencodingを必ず含めたり、常にいくつもの世界を行ったり来たりできるように行動する。当然エディタはEmacsで、開いたウィンドウの左端にはSもあればEもuもある。

一方のホモ野郎は、生まれてからこのかた、「OS？ いっぱーい使ってきましたよ。最初はDOSで、次にはWin3.1。それからWin95ってのもあったなぁ。……もちろん今はVistaでっせ。なんとその数、片手を超えること安請け合い！」とか、自慢にならない数を誇って見せたり。

だからこの連中は、まったく無自覚に、ナイーフに、あどけなく、「おれは日本人だから、日本語でおｋ」とか、ファイル名とかクラス名とかコメントとかに日本語書きまくる。Outlookしか使わないから、メールはシフトJISでおｋとか言い出すのも、無自覚ホモ野郎だったな、とか急に思い出したり。

さて、どちらのタイプが、性別欄をあたまから二択に決め打ったり、あるいは三択にしようと考えるだろうか？

_ 安いものには罠がある

実は、MacBook Airを使いこんでいるうちに、どうしても、母艦となるMacが欲しくなった。PowerBook G4はあるわけだが、G4だしなぁ。

で、迷いに迷っているところに、例によってogijunが17"をバッグから取り出したりしているもんで、うむ、欲しいとなった。

とは言え、やっぱ高価だ。

高価というのは、絶対的な価格の問題。高いというのは印象の問題（または相対的な価値の問題）。この違いはオウミョウ（なぜ変換できないんだ。奥に妙）にして、深遠なり。

で、アップルストアを眺めていると、とても気になるのがあるわけだ。

MacBook Pro 17 2.6GHz Intel Core 2 Duo / 200GB ハードディスクドライブ / 1920 x 1200解像度 [未開封新品]

型落ちったって、2007/11だからLeopardが最初から載ってるし、あと違いはCore2 Duoが古い（今の6Mキャッシュに対して4Mと、プロセスがでかい）のと、VRAMが512Mじゃなくて256M。

でも、2.6GHz、7200rpmHDD、高解像度のデラックス版なわけで、現行モデルでこのオプションにすると約38万円（リモートが便利なのはiTunesジュークボックスとして利用しているとわかるわけで、リモートも最初から付いているので+2000円ってのもある）に比べると2万円以上も安い。

キャッシュ2Mとかプロセスルールとか2万円の差とは思えないし、ましてVRAMがでかいとVista x32だと致命的だ（Boot Campは使うつもりでいる）。

というわけで、型落ち版を買ったわけだ。

しくじった。えらくしくじった。とんでもない失敗だった。

反省のために、理由を残しておくことにした。

1. 熱い！ Airが全然それほど熱くならないので（実にわりと快適なのだよ）、インテルMacは熱くないのだと完全に誤解してしまっていた（MacBookを知っているのに、アルミ版ということで錯誤したんだろうな）。どこまでいってもアップルはアップルだった。Airが別世界だっただけなのだ。で、新型ならCore2 Duoのプロセスルールのせいで、多少ましかもなぁと、想像してみたりして。でも、まあ、これはわからないから割とどうでも良い。

2. Boot Campが違う。これがでかいよ、でか過ぎる。Vistaを前提にVRAMが小さいほうがましだと考えたのが、裏目に出まくり。当然のように利用可能なメモリが3Gを割っている（VRAMが256Mあるから）のだが、ふと気付いたら、x64版を入れる話題が目につく。とはいってもkludgeする気はないので、やるなら正当な方法だ。

で、調べるとBoot Cmapの新しいバージョンではサポートしているらしいことに気づく。で、ものは試しにx64 Vistaを入れて、あれこれやって、ふと気付いて、妻用に買ったMacBook（2008/3版）のインストールディスクを眺めると、x64サポートの話がインストールガイドに出てる（2007/11 MacBook Proにはx32 onlyとしか出ていないので確かにバージョンが違う）。でもEarly 2008以降という文字が入ってるのがちょっと気にはなる。

気にはなったが、x64入れて、MacBookのほうのBoot Campを入れてみると、いきなり「このハードウェアはサポートしないよーだ。買い直したらいいと思うよ（というように受け止められる）」メッセージが出る(MacBook用だという意味には取れない)。ぐは。

この差は2万円を超える。だって、4GBフルにVistaで使えるかどうかの差だからだ。Virtualマシンを同時に2台余裕で動かせるだけの差だということは知っているし。これならVRAMが512MB積んであってもまったく問題ないよな。

というわけで、とても悲しい。思い切って買っただけに買い直すことは当然できるはずもない。

でも、iTunesの変換速度がPowerBook G4と比較して3倍程度向上したので、まあいいか。（なんとなくCD読み込みの速度に依存しているからそんなものは変わるはずないと思いこんでいたので、みるみるうちに変換が終わるのでびっくりした）

G4は、今日、Sofmapの下取りエージェントが引き取って行ったので、これで家からPower PCはなくなった（と思ったらOpenBlockSがあった）。

結論: 1.からMacBook Airはクール。

_ 誤解のJava

Javaのどうしよもないゲッタ／セッタだが、あんなものはJavaの最初の時点からの特徴でもなんでもない。と考える。

なぜならば、String#lengthだ。最も最初のうちに決定するAPIだろう。これがString#getLengthでないことが、その証左である。他にも1.0からあるHashtableのkeys、values、sizeなどもそうだ。

あのアグリー（とここでは設定する）なゲッタ、セッタは、JavaBeans仕様で導入されたものだ。アグリー？（と書きたかっただけなのだが）

JavaBeansは、ActiveXコントロールと同様なGUI部品を記述するための仕様として出発した。これは、Java言語仕様とは独立して上位に構築されたフレームワークなので、当然、その時点のJava言語仕様に従う必要がある。

そこにおいて、既存のAPIと衝突せずに、プロパティ名に対してgetとsetを接頭辞として置くというのは、良いアイディアと思えただろう。そして、より重要なことは、それがJavaBenasというコンポーネントである以上、ツールのドラッグアンドドロップによってフォームへ貼り付けられることと、プロパティ値のパーシステンスに対して外部から読み書きができる必要があったということだ。プロパティへの読み書きは、フォームエディターのプロパティウィンドウに対する設定によって行う。早い話が、コードでgetFooとかsetFooとか書くことは考えていない。少なくとも、それは主たる方法ではない。

その時点で、Java言語仕様にアノテーションが入っていたら、それを利用したことだろう。だが、そんな仕様は含まれていない。使えるのはリフレクションだけだ。

かつ、ActiveXコントロールのマネである以上、コンポーネント開発時にもIDEを利用することは前提している。同様に、プロパティエディタに対して、プロパティ名と型、既定値を埋め込めば、getFoo、setFooは自動生成されることになる。

という程度のプロパティが、大規模開発に役立つはずなんてあるわけがない。というか、大規模というか業務の中核となるアプリケーションクラスにゲッタ／セッタなんて実装しないだろう（セッタインジェクションを前提とすると実装するけど）。

重要な点は、むしろ、JavaBenasというフレームワークが、比較的素直に上位に被せられている点にある。つまり、素のJ2SE APIは、下位APIとして良く考えられていて、その上に、ドメインに特化したフレームワークを構築しやすくなっているのだ（彼らはSwingで試して実証したわけだが、デザインパターンのインスタンス化がしやすい言語/API仕様となっている）。したがって、提供される個々のクラスが妙に何もしないのは、それが理由だ。必要なら上位層で提供すれば良い。

とは言え、いろいろなユースケースが見えてきたので、そこそこ中位くらいのAPIも持つようになってきた、というところだろう。

で、そこで誤解した人たちがいて、妙な癖のあるJavaの書式がなにやら広まったと。（とは言えJavaBeans仕様は標準だからプロパティという概念をインスタンス化する時には従ったほうが良いとは思う）

で、さらに時間が流れて、ActiveXコントロール→JavaBeans→DNA→EJB→.NetFX→　ここにいたってEoDと言ってC#の成果を取り入れて拡張for文とかが来た、というのが3年くらい前。JCPはともかく、Sunはそれほどぶれていないと思うよ。

_ ああ、わかった。

木村さんのとこ経由で西尾さんのとこ経由でオリジナルの質問みてわかった。まさに腑に落ちた。

求道的な人は別として、初心者を名乗るような人たちは、理解する気はないんだ。

つまり、理解しなくても使えるものを望んでいるのだな。（ここに好きなだけ罵倒を入れよう）

ところが、理解していない人たちは、人には何も教えることはできない。小手先の方法は教えられるけど。まさにマニュアル小僧たちだ。マックに行くと見ることができる。「ドリンクはいかがですか？（今は違うような気がするけど、典型例として）」「喉は乾いていないんだ」「？？？？？ドリンクはいかがですか？」「飲み物はいらない」「？？？？？？ドリンクはいかがですか？ って言ってるだろうが！」「！！！！！ いりません」「にっこり」

したがって、抽象的な質問――例：初心者向けのプログラミング言語はなんですか？ ――には回答できない。かりにできても、自分はPHPで簡単でした、とかだけだ。

一方、仮にもCで何かやれているのなら、何かしらの理解をしている（と、信じたい）。理解しているから、抽象的な質問に対しても、自分なりの解釈を垂れることができる。

それが、つまり、C/C++を勧める回答が多い理由だ。

関連するのは「身近な具体例の利用は数学学習の助けにならない」だな。

#でも、そうやって考えを進めると、最初はLispか、Haskellとかが良いということになるのかも知れないな、と一瞬考えたが（追記：多分、おれがこの部分を書いた瞬間に考えたことをきっちり言語化してくれたのが『 実際にはどのプログラミング言語でもプログラムの勉強は出来るよな』だと思う。おれはアルゴリズムと言い切ることになんとなくためらいを感じたのだが、理由はわからない）、コンピュータの物理イメージ（ヒープ、スタック、レジスタ）という意味ではCが良いのか。

#結局、人を見て法を説くしかないのであった。で、妥当なところがマルチパラダイムになっている言語で、RubyとかPythonとかなんだろうな、と思う。

それにしても、元の質問は含蓄がある。初心者と入門者を実は分けているようだ。「入門サイトなどが多数みられる」といった表現がある。入門者は、もちろん、門をくぐるんだから、理解する気があるわけだろうよ。

_ 例の本

ものすごく偉い。みねこあさんが読んで書いてくれている。

たぶん、今読んで書いたのだろうから、正しいとは思う。

というわけで、それを前提に、なぜ、その本がそんなに悪くないどころか、むしろ良かったのかを説明する――というのは、正直なところ細部は覚えてない（10年前だし、実際にはDDJJで連載中に読んだわけで、本も買ったのだがすでに手元にはない）から、読んで感じた印象しか残っていないからだ。

最初に時代背景。

・想定している対象読者は、C++プログラマ（1998年だからJavaはあるだろうとか思ったらそれは間違い。20世紀では、情報は3年遅れでやってくるから、そのころ（1996年から1997年あたり。出版年から少しマイナスする必要がある）のJavaは、遅くて使い物にならないクライアントサイドのHTMLに視覚効果を足すだけの存在という見方がほぼすべて）。で、継承＝実装継承以外の考え方は間抜け扱い（COMのインターフェイス継承とかは、「所詮マイクロソフト」という見られ方をしていたくらい）。

・DDJJという雑誌から、対象読者はWindowsプログラマが主（VBの連載も多かったな、思いだしたけど。酒井法子みたいなペンネームの人とか）。広告もそうだった。したがって、使える言語というのは、VC++、VB、Symantech C++、Visual Cafeとかそのあたり。処理系をそこらから拾ってきて野良ビルドというような環境はあまり考えられていない

・Cはガチ。

・速度命（当時のPCの能力は、今の携帯未満ということは重要）。プロ用の雑誌なので、実用性は重要。「vtblアクセスすると間接参照の分だけjmpが余分に必要になるので、コード量も増えるし速度も低下するので、基本はvirtual付けないこと」というようなノウハウが重視されている。

・ラショナル統一前なので分析分野も戦国時代。

で、より重要なテーゼが支配していたのだ。どこから湧いてきたのかは知らないけれど、「多態＝（C++の）virtual関数」。つまり「多態＝実装継承」。

だから、その本の価値は、みねこあさんがまさにダメ出しの筆頭に持ってきている「多態はどうでも良い」にある。

そこを読者（少なくともおれ）は、「実装継承は重要ではない」と読んだ。(追記：まさにデザインパターンを読むための露払いの役を担ったと言えるな)

あと、Simula系に話が偏るのは、前提としているOOPLがC++だから当然だと思う。それこそ、sumimさんのOOPLの系統分析にしたがえば、むしろ（ある特定の1系統しか取り上げていないことを除けば）一貫しているし、正しい認識ではないかな。

今となってはどうでもよいもののために弁護みたいなものを書くのもあほらしいので、そろそろ嫌になってきたので結論を付けると、

・OOA、OODの結果をそのままC++（STL前の時代だよ）にマッピングするのはやめとけ

・よくわからずにC++で実装継承を使いまくるのはやめろ。そんなものはあれば便利な機能に過ぎない。

・C++を使うには、まずベターCとして型をきちんと扱え（ここはみねこあさんの読み方と一致しないが、おそらくクラスという言葉で代表させているのだと思う）。

・ユーザー定義型重要。カプセル化をおさえろ。

というメッセージを読みとったのであった。

これによって、コード再利用のためのOOPLという考え方から、解放されたわけで、その本には良い印象があるのだ。（has-aのあたりは覚えていないので誤読していただけかも知れないが、内包――コンポジションの意味ではないと思った。has-aも実装継承でインスタンス化するという方法論の否定をしているのだと思うが（そんなバカな、とか言わないこと。その本が良いというのは、相対的に他のがダメだったのだ）。だからis-a以外を継承（＝実装継承）するな、つまり実装の多重継承するな、という意味だと思う）

古いものからでも得るものはあると思ったけど、どうやらコンテキスト抜きに読んでも役に立たないのだなぁ。

というわけで、今読む必要は無いどころか、素直な気持ちで今読むのはダメ、というのが正解なのでしょう。なるほど。

#あと、1997年あたりってのは、テレホーダイで56Kbpsなインターネットがどうにかありますかありませんか、というような時代というのも押さえておきたい。普通の会社だとインターネットには出られないんじゃないかな。ISDN引いた人たちはいただろうけど。参考：1997年で時間が止まった資料が見つかった。Yahoo偉い。歴史を残している。288かぁ……っていうか1997年後半に56Kbpsモデムが出たのか）

いやー、それにしても、今は良い時代だ。

_ 時代は変わる

そういえば、そろそろデザインパターンに即した実装方法もいらなくなるんだろうなぁ、というか逆にダメ出しされるようになるのだろうな、という風向きを感じる。

言語としては成功（シェアという意味で）しなかったSmalltalkの蓄積を、成功した（しかし相当に偏っている）C++のような言語を有効に利用するためにデザインのレベルで（実装のレベルじゃそりゃ無理だろう）示したものがデザインパターンだ、と規定すると、当時主流言語になりつつあったJavaが見事なまでにデザインパターンのインスタンス化に向いていた（実装継承は1系統のみだが、インターフェイス継承の機構を持つ）ので、一気に広まりコンセンサスとなった（のが、21世紀の幕開け）。

（突然思い出したが、ATLのソースを見たとき、多分1996年から1997年の間、このFooBarSingletonとかTataTitiFactoryImplとかいう命名規則（規約かどうかはわからないわけだが）なんだろうとか思ったのが、最初に意識したデザインパターンのインスタンスだな。あとSwingか。本や情報より先にインスタンスを見て覚えたんだよな）

それから10年たてば、デザインではなく実装にそれを持っていてもそう不思議ではない。

そうなると、余計なもの、ということになるから、voidされることになるだろう。

ようやく、これを読み始めた。

On Lisp(グレアム,ポール)

Lispなだけに古さを感じさせないのがおもしろいところだが、1993年の本が2007年に翻訳されたところが、さらにおもしろい。しかも、それが上で書いた、今の風に合っているところがさらにさらにおもしろい。

だからアカデミックな連中で、しかも学んだことを信じて行動するやつは強いんだな。

人海戦術でプログラムする方向、フレームワーク（AもDもひっくるめて）で行く方向だぞう、の2つの方向があって、それに加えてメタプログラミングの方向、の3方向が今の風向きに感じる（クラウドとかはちょっと別にして）。

最初の方向は中間発展段階国の人件費の安さに着目した方向で、20世紀に農業ー工業ときて、ついにサービス業にもやってきたという歴史的には筋が通った発展の方向。

2番目の方向は技術のイノベーションを追求した結果で、これも歴史的に筋が通っている。

3番目はどこまでやれるのか、本当にできるのか、（それこそごくごく一握りのグルだけの世界なのではないか、それを汎化できるのか）良くわからない。しかも危ういのは適用主体が、最初の方向に転んでもおかしくないところだ。そのほうがコストがかからなければいつでもそっちに逃げられるからだ。この方向がメインストリームに浮かび上がったきっかけはRailsなわけだが、それがどういうふうに汎化されるんだろう？

（いろいろ思案中なのでここまで）

身の振り方はともかく、On LispをC++でやるのが

Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート活用術 (C++ In‐Depth Series)(アンドレイ アレキサンドレスク)

これだと考える。

へへ。どちらも「初心者」から進んだ人には手が出ないのはわかる。まともに正直にまっとうに「入門者」から出発しなきゃな。

そこにLLというものが嵌り込むのだ。理解しなくとも使えれば、確かに産業用にはOKだ（と、なれなければ産業用ではない）。

おもしろいなぁ。うーむ。

_ 勇気ある人

突然、ヘリコプターが実用化されたのが1936年だと知った。

（間に戦争があったから、すぐにどんどこ実用化されまくったとは想像できるものの）

それからたった12年で、映画の撮影に利用しようと考えた人がいて、しかも実際にやってのけたというのは、結構、驚きだ。

当時の情報伝達速度がどの程度のものなのかは知らないけど、映画館でオープニングの車のシーンを観た人は度肝を抜かれたんじゃないかなぁ。

世界で最初にヘリコプターからの撮影という新しい技術を取り入れた映画が、忘れられた人々になっているのもちょっと驚きではあるような。

夜の人々 [VHS](ファーリー・グレンジャー)

（公開時の題名が、「夜の人々」だったり「彼らは夜生きる」だったりいろいろなので探しにくい。they live by nightのbyというのは、「夜に寄り添って」の意味か「夜によって生かされる」の意味なのかよくわからないけど、たぶん、前者なのだろう）

ファーリーグレンジャーのとんがり具合とか、キャシーオドネルの田舎娘っぽさとか、ヘリコプター撮影のおかげで可能となったと思われる冒頭の疾走感（当時）とか、傑作中の傑作なのになぁ。

というよりも何よりもニコラスレイという名前がすでにして最高だ。映画を創る人がレイなのだから、最強でもある。

一方、リメイクは生き返ったようだ。

ボウイ&キーチ [DVD](キース・キャラダイン)

ニューオーダーのバージョンは、キリコか誰かの画を使ったマキシシングルで最初出たと思ったが、映画にくらべると相当落ちる。

Thieves Like Us: New Order Tribute(-)

_ 哲学よりパン

「これって何かの事情でここに置かれているけど」 ですが、クラスの説明文に

文字ファイルからの読み込みのための簡易クラスです。このクラスのコンストラクタは、文字エンコーディングとバイトバッファのサイズはデフォルトで適切な設定がされていることを仮定しています。これらの値を自分で指定するには、FileInputStream 上に InputStreamReader を構築してください。

と書いてあるとおりに、便宜を図って入れた以上の意味はないと思います。
でも、中途半端ですね。この便宜の恩恵を受けるのは、設定ファイルのような（プラットフォームに合わせたエンコーディングで配備されていることを前提できる）ファイルなので、だったらBufferedFileReaderというエンコーディングに既定値を使う簡易クラスを用意しておいたほうがreadLineが使えるので望ましいでしょう。
別解：誰だか知らないけどMark Reinholdという人のOJT用の練習問題とかだったりして。(J6のスペックリードだからそれは無いか。単に欲しかっただけだろうな)
重要なこと：というように、Javaが.NETよりおれが好きな点は、顔が見えるところだ。一貫性が崩れているな、と思ったら、ソースを読めば良い。すると、個的な空間がソースとしてそこで読めるわけでね。わかるかなぁ？ わかんねぇよな。

_ Railsのケーススタディ本

自分の本の評価とか売れ行きは気になるので、ときどきアマゾンを覗く。

10日でおぼえる Ruby on Rails入門教室(arton)

うーん、なんか嬉しい（「中身は非常に硬派なしっかりした内容」とか書かれるとそりゃ嬉しい）書評が載ったぞ、とか、もっと売れないかなぁとかいろいろ思ったりするわけだが、それはそれとして関連書籍をながめてたら、ついに「デザイナー本」として名前だけは知られているのりおさんの本が予約可能になってた。

Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~(Plan de Sens)

一瞬、翻訳物かと思ったけど、デザイン事務所の名前だったのか。で、のりおさんが漢字だと智雄だとは知らなかったので、最初、翻訳者かと思った。

というのはともかく、ケーススタディで構成された本で、多岐にわたるメディアコンテンツについてとか、今までにないタイプのRails本だということは間違いない。というか、「今までにないタイプ」って表紙からもびんびん伝わって来てるな。

このサイトを事例にしているそうだ。（なんか、フラッシュより先へ進めないんだけど、これはSafariのせいなのかなぁ：追記、のりおさんに聞いたら今は稼働してないそうでした。残念。また復帰するそうだから、本が店頭に並ぶころには見られるのかなぁ）

音楽系サイトってどんなふうに作るんだか知らないので、興味もあるし、とりあえずアマゾンで予約。

_ まあなんだな

おれたちは、同じところをくるくる回りながらも少しずつは先に進んでいるわけだよ。

なんか向井さんのとこの古いエントリからのリファラがあるなぁと、過去をちょっとさかのぼって自分に出会い、その先のessaさんにたどりつく。

すると、パーザ修正したり、納得できないものは納得できないと書いている(いっぱいあるからリンクはしない)kwatchさんを巡る構図ってのが見えてくるよなぁ。仕様をいろいろ気にしたり追いかけているのも、変だと考えたら襲いかかるためには必要だろうし。

これもまた、essaさん曰くの

「自分の経験の枠組みは自分で変えられる」という信念の人

を巡るエピソードになるのか。

「王様は裸だよ」

「いや、あれは王の権威を守り、諸外国に対して吾国の覇権を維持する役に立っているのだ」

「……立ってないように見えるが」

_ へへ

と、上のを書いて、しばし黙考。そうか、わかった、大規模開発の要諦が。

大規模開発の要諦とは、「自分の経験の枠組みは自分では変えられる」人を排除して、「悪いのは環境ではなくて自分である。変えるべきなのは環境でなくて自分である」人を集めることにあるのだろう。

なんてわけはないだろ。人間をなめ過ぎてるよね。

_ ポリモーフィズム

「ポリモーフィズムって何？」

「それは人の心の数だけあるのだよ」

たくさんのお月さま (1976年)(ジェームス・サーバー)

NyaRuRuさんが幾つかのポリモーフィズムを紹介されているから、僕は、comp.objectのFAQ(1996)

をリンクしよう（僕がこれを読んだのは1999年くらいかなぁ。3年遅れだ）。1996年の主流が読めるだろう。

Comp.Object FAQ Version 1.0.9 (04-02) Part 2/13

2.1) What Is Polymorphism? を読むと、Websters',Author（この人誰なんだろう）, Strachey（NyaRyRyさんの引用にも出てくる。なんと1967年）, Cardelli and Wegner（1985年。おもしろい）, Booch（1991年。ダックタイピング）, Meyer（1988）, Stroustrup（1990年。そうそうそうだ。「Furthermore, the ability to call a variety of functions using exactly the same interface - as is provided by virtual functions - is sometimes called "polymorphism".」つまり、憂鬱本はこの流儀で、多態を便利なだけと言っている。っていうかStroustrupは当然読んで書いているだろうから、それを、独自の研究みたく呼ぶのは不見識だとは思うけどね）, and Rumbaugh（1991年。あっさり）.

すべての道を走るのはいくら高速道路があっても難しいものだ。

ではこれらの多態した多態を知っている必要があるかというと、それは別の問題だろうなぁ。

_ ふむ

なんとなく冷戦下の疑わしきを罰する状態をボブディランあたりが歌ったのだと思ってたが（en.Wikipediaのテストの項とか読むと、あまり良い意味には取れないし）、これ見ると、あんまり関係なさそうだな。

Boowa and Kwala : Can you walk like a duck - the song

_ ランジェ公爵夫人

今をさかのぼること3日前くらいに、30年ぶりだかそこらぶりで、岩波ホールへ行った。最後に行ったのは多分ベルイマンの沈黙だかなんだかだろう。

いずれにしろ、岩波でやるような映画にはそれほど興味ない、と書いてみるもので、思い出したが、チェンカイコー（ガイグじゃないのかなぁ）の人生は琴の弦も岩波だったような気がしてきた。

いくら、興味がない映画ばかりやっているとはいえ、それでもたまには観たい映画はあるわけで、リヴェットは観ても良いかなぁと、ランジェ公爵夫人に行ったのであった。

それにしても、最初、1階のチケット売り場（窓口が開くより前に着いたのだが）に、おばあさんが10人くらい集まっているので、何か間違えたのかと思った。別に間違えじゃなかったわけだが。

で、会場に入ると、おばあさんとおじいさんでいっぱいだ。これが岩波か。多分、全館客の中で、おれが一番若いんじゃないかというこのびっくり。

という、このうえなく演劇的なシチュエーションの中で、はっきり言うと、それほど大して映画を撮るのがうまいとは言えないが、それでも何かしらのおもしろさはあるリヴェットを観るというのがメタでおもしろい。

それにしても、冒頭1時間くらい、たとえばエフィーブリーストを撮ったファスビンダーならどう料理をするだろうかとか、恋のエチュードを撮ったトリュフォーならどうだろうかとか、類い希なるデプレシャンに任せたいとか、そんなことばかり考えている退屈さ。というか、隣の席のおばあさんが、上品ななりではあるけれど、お風呂に入っていないのではないかと思わざるを得ない状況で、相当きついものがあるが、なにしろほぼ満員だから場所も移れないときたものだ。

ところが、最後の20分に満たないところ。一隻の武装した船がスペインに向かっていた、のあたりからのおもしろさと来たら、びっくりだ。

「村人皆殺しにしてから、誘拐しよう」

「それが簡単だな」

「でもまて。闇のように忍び込んで誰も気づかないうちに攫ってくるほうがかっこいいぞ」

「それはかっこいい」

「賛成」

「おれは皆殺しでさっさとやるべきと思う」

「決をとろう。皆殺しに賛成は？ 闇のように攫うのに賛成は？」

すげぇおもしろいじゃないか。

いや、暗い修道院の中を行ったり来たりしているところを観ると、やはりリヴェットはリヴェットで、少しもおもしろくないのだが、台詞のひとつひとつが冴えに冴えている。それが圧倒的におもしろい。

ほら、演技はどうでもよいから、何か喋れ、喋るんだ。

それにしても、映画と演劇は異なるということを知り抜いているはずなのに（そのために12時間の映画を撮ったはずだし）、どうして、こういう映画になるのだろうか？ それが不思議で観ているようなものなのだが。

もっともデパルデューの息子は演技がうまいので、ぎりぎりまで時間をもたせるところとかは良い感じなんだが、役者に頼る映画なのだよな。

最後、死体を前に、ちょっと悲しげな顔をしていると、「それは死体だ。足におもりをつけて海へ投げ込めよ」というような台詞から畳み込んで爽やかに終わって、ああ気分良かったが、ふと気づく。

このおもしろさは、どうみたところで、リヴェットじゃない。原作だ。バルザックがすごいんだ。と気づく。台詞がいちいちいかしているのだ。カメラの動きのつまらなさや構図のどうでも良さにだまされていた。と、まるでアントワーヌドワネルのようにバルザックに目覚める。

というわけで、この、アナーキーでモダンで、現実主義な合理主義者の悪党どもの冒険活劇を読まなければならないだろう。

で、三省堂に行ったらなくてがっかり。でも東京堂にあったので購入。

十三人組物語　バルザック「人間喜劇」セレクション(バルザック)

さっそく、最後のあたりを眺めると、案の定、印象的な台詞はバルザックのものだ。

しかし、まだ読み始めていないのであった。

ランジェ公爵夫人 [DVD](ジャンヌ・バリバール)

_ 探検うさちゃん

最近この歌とその周辺がかかっていて、不思議な感じ。

桜蘭高校ホスト部 サントラ&キャラソン集<特別編>(TVサントラ)

明らかに異質な文化が家の中に入り込むってのはおもしろいものだなぁ。

_ 東のドラムと西のギター

やっぱ、こっちが落ち着くわい。ジャケットもいかしてるしな。

Blue Moons & Laughing Guitars(-)

それにしても、ビーバップデラックスの頃と異なる、この歌唱スタイルってのはなんだろうか？

聴けば聴くほど、高橋幸宏にそっくりなのだが。顔も長いしな。

どっちかがどっちかの影響下にあると考えると素直なのだが、すると、ビルネルソンが高橋幸宏に影響されたと考えるほうが時期的には合うのだが、そうなのかなぁ。

ドラムもギターも結構忙しい楽器なので、スタジオ録音では、ステージでの歌唱スタイルを変えたくなって、このタイプのぼそぼそした感じにしてしまうものなんだろうか、というか、曲調も近いんだけど、それも不思議ではある。

_ Vistが夢をみる

MSは、SP1配布を記念して、唐突に、このCDの復刻をするか配信をして欲しいが、もちろん、なんの関係もない。

Vistamix(Nelson, Bill)

1曲目のリアルアドヴェンチャは、本当の傑作。ああ、ビルネルソンの新しい時代が始まったな、と当時、つくづく思ったものだ。ビーバップのころのハードロックスタイルはまったくなくなって（ギターを使ってないんじゃないかなぁ）、レッドノイズのころの不協和音も影をひそめ、アップテンポの上にきれいなメロディーが重なるが、ミッジユーロのUVとは異なって、個人プロジェクトぽさがむき出しになっていた。

曲がいちいちVistaっぽい。

Acceleration ー そりゃ、3Dアクセラレータが必須だし、

Empire of the Senses ー ユーザー体験の帝国を築こうとしてるわけだし、

Everyday Feels Like Another New Drug ー 毎日のようにUIの変化にとまどい、

Do You Dream I Colour? ー Vistaだし、

Glow World　ー というほどメモリーは食わないかも知れないけど、やっぱり食うし(ちぇ、growと間違えた)

Another Day, Another Ray of Hope ー 人々はさっそく次のWindowsを期待しているようだし。

追記：どうも変だなぁと思ったら（Real World AdventureとかAccelerationで確認したわけだが）、あれはキメラなのか。ジャケットも見覚えがある。

Chimera is futher proof of the genius of Bill Nelson. I remember hearing this back in 1983 and just being blown away yet again at the man's talent. Nelson once again demonstrates his incredible diverseness with electronic rock songs like The Real Adventure……

おれか、というくらい同じ意見のやつがいるな。

_ 4半世紀後の納得

Chimera(Nelson, Bill)

日本でも売ってるじゃんか。

というか、高橋幸宏が参加してたのか。知らなかった……ってことは、ビルネルソンが影響を受けたで当たりだろうなぁ。

_ Javaの原典

そりゃ、これじゃないの？

プログラミング言語Java (The Java Series)(ケン・アーノルド)

厳密に考えると、初版だと思うけど。それにしても、このあたりの書籍のレビューに恬として恥じることもなく読解困難だ、国語力がどうしたとか書く人々はいったいなんなんだろう？ （原書で読んだので知らないんだけど、どう考えてもひどいはずはないだろう。多分、技術的に正確な文章を読む技術がないとか用語を知らないという無知の表明なのだろうとは思うが）

あと、サードパーティではなく、自分たちの陣営でEffectiveを用意したということは、これもだろうな。

Effective Java プログラミング言語ガイド(Joshua Bloch)

_ まだ原典

あれ？ 「やっぱりJava言語仕様なのかな?」と書いているから、言語仕様じゃないのを読みたいのかと思いましたが。

しかも「著者にゴスリン」とか書いているくらいだし。GLSは仕様書を書いたという位置づけだというように何かで見た覚えがあるから、むしろケンアーノルドだと思うし。というか、せっかく書影を張ったのに、「著者について」も読んでないのか。

僕が読んだ（かつ手元にある）のは原書第2版だから、今売ってるのと等しいとも思えませんが（ページ数も半分くらいみたい）、なぜinterfaceかのあたりとかを読むと、Javaの設計方針は明らかになります。引用しとくか。

The fundamental units of design in Java are the public methods that can be invoked on objects.

あとはAnonymous Classesとか。そういえば、柴田さんは木村さんイチオシの「無名クラス」派ですよ。（匿名クラスと訳していないので星1つなんてね）

と思ったら原著がいい加減だったので無名内部クラスに統一した（第4版）とか書いてあるけど。

K&Rは面倒だからいいや（これはそもそも星1評がろくでもない例として挙げただけだから）。ANSI規格を反映したほうが利便性が高いから改訂しただけだと思うし、大学院生うんぬんの評に反応しているのなら（具体例としての翻訳の悪さについて唯一きちんと書いてあるのが、翻訳を学生に分担させて編集者が手直しして監修者が眺めたと書いてある評だけで（これは星1評としては秀逸で、時代感もあるし、提言もあるので良い評）、それ以外の悪い評には有意な情報がないからそう思っただけだけど）、向井さんのHaskell本(当時))や、野田開さんのOn Lisp（訳）はどうなるんだ？ っていうかRHGなんて大学生が書いたんだよ（間違いもそれなりに入っているみたいだし）。そんなのまったく内容および本の価値には関係ないね。肩書きや身分で内容が決まるのかなぁ？ 小説家じゃないから文句があるのかな。それともプロの翻訳家（戸田奈津子さんとか）だったら良かった？（明らかに変なところはあったように覚えているけど、そういうところは変だからわかるし）とか余分なことを書いたけど、K&Rスタイルのリストを眺める以上の価値は今は乏しいかなぁ（BNFが載ってることとか、格上げ規則が完全に書かれているとか、うるう年の求め方がわかるとかは良い点だけど、上に挙げた秀逸な星1評に言わせると、もっと良い日本語の本があるらしいから、それを読めば良いのだろう）。

あとご存知とは思いますが、原典というか言語作家の思い入れがたっぷりなので僕が知っている(持っている)のは、

プログラミングErlang(Joe Armstrong)

クロフォードの80386(わお、プレミア付いてるよ。約3500円だから3倍以上か)

80386 プログラミング(クロフォード,ジョン・H.)

_ 恋の軍勢は

レギオン、レギオン。

HELLSING 6 (ヤングキングコミックス)(平野 耕太)

_ I think

ダーウィン展を観に上野。後で書くかも

_ 奥付

まるごと、えらくおもしろそうだなぁ。

_ BBB

なんとなく気に入ったので、iTMS（今はMusicが取れてるからiTSなのかな？）で購入。

ELECTRIC SUMMER(Base Ball Bear)

多分、速度とか転調の仕方とか。音色も好きかな。

_ コンピュータカー

スラド読んでたら、確かに、おれの最初のプログラムはコンピュータカーのプログラムだったことを思い出した。

壮大なプログラムを組んだら、部屋が狭すぎてOutOfMemoryErrorでクラッシュしたっけなぁ。そういう経験を積んで、日本とアメリカでは生活空間が異なるということを子供心に知ったりするのであった。ビーバー君の家ならクラッシュせずに走りきるのだろう。

しかしさらに思い出したが、コンピューターカーではなく、コンピュータカーなのが不思議で友達と、ばかじゃねぇか、みたいな話をしあったのも思い出した。初めてのJIS用語経験ですな。

_ イマイチ

mirror = 'mirror'
puts "mirror is #{"mirror is #{"mirror is #{"mirror is #{mirror}"}"}"}"

あまりおもしろくなかった。循環参照させることは可能かなぁ。

_ ダーウィン展

入ると、人物、生い立ちなど。話しておもしろいやつなので、自殺した船長の代わりに指揮を執って英国へ戻ってきた若き中尉が、次の航海（つまりヴィーグル号）へ誘った。

金も出ないし、危険もいっぱい、キャリア的な役にも立たないので父親は反対する。しかし、第3者を使って自分を説得できたらOKと、譲歩した。ダーウィンは、叔父さんと作戦を練り、父親の説得に成功する。

中尉は（というか、当時の英国の風潮では、ということだと思うが）学問的探索に理解があるのでやたら充実した図書館を船に用意しておいた。おかげでいろいろ助かる。

そこら中に植民地があって、郵便網が発達していたおかげで、手紙が残っている。そのため、航海中の研究の深化がわかる。

ガラパゴスは火山島なので、生き物はみな灰色。でも赤い鳥だけがいる。多分、別の島から渡ってきているのだろうと推測。

リンネの分類と現代の分類。いろいろな生き物。丸い蛙。ハチドリのエピソード。亀の2種類の甲羅と食べ物の関係。上を向くか、まっすぐ向くか。2種類の鳥。

胚の状態はどの生物も似ている。骨格はどの生物も似ている。奇形。

地層の分析、地理による分布の研究。

こないだ読んだ解剖学者ジョン・ハンターを想起する。英国の当時の科学界では進化という概念はすでに暗黙のうちに含意されている。鳥類には鳥類、植物には植物の、分類学者がいて、彼らと協力して資料をまとめる。だれが宗教と戦うのか、そのための証拠固めが重要。マルサスの研究。食い物がなければ死ぬ。

20年の放置。その間のメモ。I thinkの系統樹（というよりは、線香花火のように見える、枝分かれの図）。

ダーウィンの偉業というのは、地理と生物の分布による緻密な分析にある。

例）細長い蜜管を持った植物。これに対応する鳥の存在の予測。数十年後に、該当する鳥が発見される。

サルが進化して人間になったのではなく、元ネタから片やサルへ、片や人類へ、分岐した。兄弟という概念。

明治日本は、富国強兵政策と一致していたため、すんなり受け入れられる。社会的進化論との結びつき。優生学。その逆にインテリジェントデザインのような考え方。

_ サマータイム

以前、大島さん（カリフォルニア在住）が、いかにサマータイムというのはだめなシステムかというのを書かれていたのを読んで、そりゃだめだと思ったものだが、なんかまたサマータイムが話題になっている。

で、あらためて読み返してみたりして。

サマータイム site:d.hatena.ne.jp/squeaker

3年前のことか。

_ 企画・構成

執筆が別物というのは明らかなのにバカなコメント、という指摘？

_ BBB

ついにiTSでLP(追記：なんのことだろう？ 約8曲程度入っていて45分から60分程度持続する作品のこと。アルバムでいいのか？ でもiTSでもEPはEPとか書いてあるしなぁ。やっぱりLPなのかなぁ)まで買ってしまった。

十七歳(Base Ball Bear)

ちょっとElectric Summerのときとは感じが違うかな？

でも、なんで気に入ったのかわかってきた。（つぁつぃつぅつぇつぉ系の歌は本来嫌い）だが、ギターだな。

そこから、芋づる式に、

B000Z7G7KU

だのを思い出したり、XTCとか思い出したり（急なリズムの切り替えとか、XTCの影響があるように思う）。でも、見てくれと同じく、なんかこなれていて、無理もなければ真似っぽくもなく、そのあたりが好きみたいだ。（というか、メロディーラインの作りかたは、XTCよりうまいだろう）

#今、アマゾン評を見てて気づいたが、嫌いなボーカルスタイルなもんで、音しか聴けないというのがもしかしたら、でかいのかも知れないな。歌詞を意識したらえらくこっぱずかしいのではないかという気がしてきた。

_ ノドグロ

目玉があまりにでかいので驚いて買って焼いて食ったが、干物だといまいちかなぁ。

_ NetBeansファン

＃ヒドイ言いがかりだ。:-P

おれも思ったよ。

Eclipse： プログラム開発統合環境のデファクトスタンダードのEmacsではないため、見た目、操作感が違い戸惑う可能性がある

OS X： パーソナルコンピュータのデファクトスタンダードのWindowsではないため、見た目、操作感が違い戸惑う可能性がある

Linux： UnitxのデファクトスタンダードのSystem Vではないため、見た目、操作感が違い戸惑う可能性がある

パン： 日本人の主食のデファクトスタンダードの白米ではないため、見た目、操作感が違い戸惑う可能性がある

自動車： 日本人の移動のデファクトスタンダードの籠ではないため、見た目、操作感が違い戸惑う可能性がある

旅籠： 宿泊施設のデファクトスタンダードのホテルではないため、見た目、操作感が違い戸惑う可能性がある

ユニットバス： 浴場のデファクトスタンダードの檜の風呂ではないため、見た目、操作感が違い戸惑う可能性がある

なんでもできるな。汎用性のある言葉はカスである。

_ NetBeansファン(続)

茶々はともかく、これ、たぶん社内調査資料を一般化したものに読める。

その想像が正しければ、「JavaのIDEとしてデファクトスタンダードであるEclipseではないため、見た目、操作感が違い戸惑う可能性がある」のオリジナルの文章は、「JavaのIDEとして現在、社内で利用しているEclipseではないため、見た目、操作感が違い戸惑う可能性がある」だな。（大した違いはなく、すぐ慣れるとは思っても、そうは書かずに慎重に書くものだし）これなら表現的に不自然さはない。つまりはそういうことなんじゃないかなぁ。

ということは、つまりは、EclipseからNetBeansへ社内インフラ変えるべしという素晴らしい提言に読める。いいねぇ。

_ 新星堂の3×1020

1枚のCDに1020曲、それが赤、青、黄色の3枚で全部で3060曲。

納められているのは、チェリーレッド、ラフトレード、クレプスキュールなどのアーティストたち。それが1グループ1曲だから全部で30バンド。

ある時代を切り取った、すげぇ傑作CDなんだ。

それを出したのが、新星堂。レコードチェーン店なんだが、今もあるのかなぁ？

たとえばだ。everything but the girlがnight and dayでへたなボサノバと言ってしまえばそれまでなんだけど、そのとき、その時代で、何か他の人と違う新鮮なポップを求めて、そこにたどりついたという感覚があふれている。

あるいは、Eyeless in Gazaとか。名前はかっこいいのに、さわさわとした爽やかなポップで、そのバンド名はなにかと小一時間。アズテックカメラとかもそうだな。

あるいは、Young Marble Giantsがペコペコしたリズムボックスに指一本かというようなシンセサイザでせこくはじめて女の子がへたな鼻歌みたいなのを歌い始めるColossal Youthとか。でもなんていうかアイディンティティを求めてるのはわかるぜ。

The Pale Fountainsかあ。

で、驚くべきはPacificのsea of sandだ。「家族と友人たちへ、たとえ月日が流れ去っても……」おいおいボウイのシルエットや影の影響か？ でもまともな日本語なんだよ。サウンドも落ち着きはらっていて、でもラブリーミュージック風というか、ドラムの上にゆるいシンセサイザ（というよりもオルガン）、時々ギター、シーケンサーがリズムギターの代わりに音を刻む。このバンドは最高だ。

The weekendがやわらかい。

3曲=3バンドに1つは、ゆるいドラムマシーンに浅いストリングシンセ、いまひとつうまくない女の子のボーカル。オリジナリティを出そうとがんばっているのに、みんなクレプスキュールスタイルなのは、そんなもんかもね。でも、それぞれ違う。ああ、Antenaを忘れてはならない。音の奥行き感では圧倒的なサウンドセンスがある。

デュラッティコラムは彼らの中ではベテランだ。つまらないかも。

Josef Kが出だしのベースとギターでジョイディヴィジョンフォロアーっぷりを発揮する。でもボーカルスタイルが違うんだよな。なんというかカーズというか、ちょっと違う。でも悪くはない。

The OrchidsのIt's Only Obviousがどこからそのタイトル？ というくらい、クリアなポップ。でも、歌が吹けば飛ぶような軽さ。でもいい感じ。

ああ、つまりいい感じなんだ。

TangelineのSunburstの少年合唱団、きらきらしたシンセサイザ。ストラングラーズを骨抜きにして湯煎にかけたいたいな音楽だけど、やっぱり悪くない。

_ まるごとRubyでたー

というか、なぜサルにRubyなんだぁぁぁ

というわかる人にはわかるが、もしや、そのノリなのか？

（いや、おれはなんとなく、少しはそういうのを感じてはいたが）

まるごと Ruby! Vol.1(るびきち)

いや、もう、著者の最後に「舞波」という文字が光っているだけで、これは欲しい（あ、おれは書いているから見本誌はもらえると思うけど）。

で、ゴトケンさんやるびきちさんがいて、その一方で、cuzicさんや元気さんや高井さんもいる。

ちなみに、僕は、Javaについて書いています。もちろん、javax.toolパッケージあたり。あ、確かにサルにRubyだわ。

_ OS X

1.9を試そうとsnapshotを取ってきたら、signalのテストで引っかかった。

OS Xだからかと1.9.0-1で試すと通る。

sample/test.rb:signal FF
sample/test.rb:eval .............................
sample/test.rb:system ./sample/test.rb:1683:in `block in 
': Interrupt (RuntimeError)
	from ./sample/test.rb:1814:in ``'
	from ./sample/test.rb:1814:in `
'
not ok signal 1 -- ./sample/test.rb:1681:in `
'
not ok signal 2 -- ./sample/test.rb:1692:in `
'
test failed

なんかsleepが効いていないように見える。(./miniruby -e 'sleep 5'がすぐ復帰するので、それは当たりのようだ)

でもpthread-enableは立てたし反映されているようにみえる。ということは、Threadの取り違いが起きてるのかなぁ？

というところまで見た。

_ Timemachineにお願い

/usr/localの下を戻したいのですが。

黒船(サディスティック・ミカ・バンド)

おれは、高橋のミカじゃないバンドも好きなので、

ゴールデン・ベスト(サディスティック・ミカ・バンド)

これはばかばかしいほどお得なベストだと思うのだが、意見が合わない人もいるのだなぁ。

_ OS X tips

高橋さんが書いたgithubのエントリーがおもしろかったので、アカウント作ってみるかと訪れて、Providing your SSH Keyで登録するキーの作成方法のあたりとかを読む。

すると、見たこともないコマンドが書いてあるじゃん。

[~/.ssh]$ cat id_rsa.pub | pbcopy

なんじゃこりゃ？ と思ったら、うほっ良い反応とばかりに説明が次に書いてある。

The pbcopy command copies whatever is sent to it on STDIN to the clipboard, ensuring that you won’t have any extraneous newlines or other problems.

pbcopyは、標準入力に送られてきたものをなんでもクリップボードにコピーするよ。だから余分な改行とかその他の問題とかなしに（元のファイルの内容を透過的に）取り込める、ってことか。

これは便利なものを教わった。というわけで、早くもgithubを使うメリットを享受できたのであった。

_ この動作は仕様として正しいのかな？

Hashのキーはeql?で比較するという点と、hashメソッドの戻り値を利用する、というのは良いのだが、Arrayのインスタンスを使うとなぜ取得できないことがあるんだ？

irb(main):035:0> a = [1]
=> [1]
irb(main):036:0> h = { a => 1 }
=> {[1]=>1}
irb(main):037:0> h[a]
=> 1
irb(main):038:0> h[[1]]   # aと[1]は異なるインスタンスだがeql?なので値が取得できる（はず）
=> 1
irb(main):039:0> a << 1
=> [1, 1]
irb(main):040:0> h[a]   # eql?が満たされなくなったからかな？
=> nil
irb(main):041:0> h.keys[0].eql? a
=> true                           # eql?は満たされている
irb(main):042:0> h.keys[0].hash == a.hash
=> true                           # hashの値も等しい
irb(main):043:0> h[[1,1]]
=> nil                              # ふむ
irb(main):044:0> h.keys[0].eql? [1,1]
=> true                           # なぜだ
irb(main):045:0> h.keys[0].hash == [1,1].hash
=> true

追記：ああ、テーブル上のスロットが変わるからだ。いちいちキーをチェックしたらハッシュじゃないし。
ってことは

irb(main):192:0> h[[1]]   # 今度はハッシュが等しいので正しいスロットをポイントする
=> nil  　# しかし残念、キーとeql?じゃない

ということか。納得。

_ チェチェチェチェンジス

関係ないが。

Changes(Bowie, David)

どうも、映画館かテレビかどっちかでPV使った広告を観たことがあるな。すごく印象に残っているってことが、サビの部分を聴いて思い出した。

変なところで図書館戦争にぶつかって、なんか世の中のトピックってのは狭いもんだとかも思ったり。

_ デザインという言葉

のりお本を読んでて、ふと考える。この本はクリエイターのための本だ。そう書いてあるし全体がクリエイティブで構成されている。

Rails of Ruby on Rails ~Case of LOCUSANDWONDERS.COM~(Plan de Sens)

クリエイターって造物主だよな。

そっからIDに飛んで、ってことはデザイナーもクリエイターと同じく神々の眷族だよな。

プログラマも神のはずだがそうは言わないなぁ、というとこまできて、そうか、わかった、ソフトウェアデザイナーと呼びゃいいんだ……イナオ神ってのが(大明神かも)、西鉄ライオンズにいたっけなぁ。とか。

_ APIを考える

単にメソッドの引数についてだ。この話は、3ヶ月後くらいにインスタンス化される書籍（翻訳もの）について軽くレビューしていて思ったことだ。というか、その本にも出ている内容だけど、ネタバレということではないので、考えたうちに書いておく。

今、ファイルをコピーするメソッドを作ろうとしているとする。

じょーこーなら、copy(src, dst)あるいはcopy(dst, src)のいずれかになるだろう。

だったら、そんなメソッドは作る必要はない。require 'fileutils'すればよい。

そうではなく、こういうコピーをしたいのだ、とする。

copy src1, src2, src3, src4, src5, dst

あるいは

copy src, dst

メソッドオーバーロードがあれば(C#にしとくか)

copy(string[] srcs, string dst)

と

copy(string src, string dst)

で良い。と言いたいところだがちょっと違う。

この場合、最初のメソッドは

copy({src1, src2, src3, src4, src5}, dst)

と書かなくてはならず、しかし、それは「こういうコピーをしたいのだ」とは異なる。

つまりメソッドオーバーロードがある場合の1は

copy(params string[] files)

が正解だ。これなら

copy(src1, src2, src3, src4, src5, dst)

と書ける。もちろん、メソッド提供者はちょっといやな感じはする。みそーすもくそーすも一緒だからだ。配列の最後の要素がdstというのは、なんか配列のセマンティクスの破壊っぽい。型はstring配列でおかしくはないが、要素の意味が異なるものが混じるのって気持ち悪い（おれは。でもLispのように考えれば、あいつのリストって平気でリストの要素にいろんな意味があるよなぁ。(funname param)なんて普通だし。だから配列でなければそういったことができない言語を利用していれば、それはそれでしょうがないのかも）。で、それが望みのものだ。

ここで、配列の要素の意味を同じにすることを考えると

copy(string dst, params string[] srcs)

というのも考えられる。でもこれは「こういうコピーをしたいのだ」ではない。ｌ

さらに考えれば、「こういうコピーをしたい」にはこんなのもありえる。

copy src

（dstはpwd）

これもcopy(string dst, params string[] src)で受けられるが、dstなのにsrcが空配列の場合にはsrcになってしまう。

でも、もちろん、C#では最初の「こういうコピーをしたいのだ」はできない。()が必要だからだ。

というわけでRubyで実装することを考える。

C#での思考実験から結局

def copy(*files)

とするしかないような気がしてくる。というかそれが良い。

でも実装はあまりきれいとは思えない。

if files.size == 0 then raise ArgumentError elsif files.size == 1 then dst = `pwd` else files = files.dup; dst = files.pop; end

書いてみたら2条件か。意外と悪くないか。

_ まだ言ってるのか

用例を見ると、匿名投票という言葉がある。これの別称は「無記名投票」だ。この用例からは、匿名には名前を隠すという意味とは別に、名前を明示しないという意味があることがわかる。anonymousにnamelessの意味が含まれると英語にダブルミーニングを求めるのがOKなら、日本語にも実際に存在する用例から求めればよいだけだ。

あとは語呂と語感の好みで選べばよい。

くだらん。

_ バットマン

MSDNには匿名関数と出ている。したがって、C#とかについて書く場合は匿名関数と書く（でも埋め込みSQLのとこでは無名パラメータだね）。JDKの日本語Javadocには匿名クラスと出ている。したがってJavaについて書く場合は匿名クラスと書く。

でもECMAScriptについては仕様の定訳がないみたいだし、界隈の人たちは無名関数と書いているから、ECMAScriptについて書く場合は無名関数と書く。

それでいいじゃん、ロビン。

_ 鮫的な粘土

綴りは無視。

バカの獲物にリンクがあった（青木さんが翻訳されている）クレイシャーキーの「ジン、テレビ、社会的余剰」を読む。

この人の書くものには、妙にシンパシーを覚える。

最初に意識したのはジョエルがまとめたやつだ。

BEST SOFTWARE WRITING(Joel Spolsky)

（fjの教祖様が鋭い視点から星3個にしている。要件を満たしていないけど実装が良いので3ってことか）

結局起きていることは、頭数×時間という限られた資源の奪い合い、まっかなトマトの海なのだ。

でたらめだけど分岐点と考えてみることができる。

かってみんなが狩をしていた。かってみんなが米を作っていた。かって戦争は全員参加で負ければ皆殺し。長いことかけて効率を追求して分業が当たり前となる。政治を考える人は政治をし、政治を考えない人は投票したり投票しなかったりする。お金を稼ぐ人とお金を使う人、音楽をやる人と聴く人。それは効率的であり、選択されたもののみを残せば良いのでリソース配分という意味でも正しい。音楽をやるためにみんなが教会に行き歌を歌い、音楽を手元で聴くために楽器演奏を習得して楽譜を買う（ベートーヴェンの時代のCDは楽譜だぜ）。それが分業が発達して楽器演奏を習得する必要がなくなり、その時間を別のことに振り向けられるようになる。あるものの消費者は別のものの生産者である。だからうまく効率的に回る。ほんの30年前にはコンピュータハードウェアに分業はなく（パーソナルシステムの話だ）作る人は使う人、ソフトウェアは20年前くらいまでは作る人は使う人、それがムーアの法則の速度で他の産業が数100年かけたところを、今では完全な分業体制だ。

メディアはどうだろうか？ 大量配布がグーテンベルクによって始まったと考えるならば、テレビ（放送）によって分業体制は確立したように見える（クレイシャーキーがテレビを例にしているのは、現時点において正しいと思う）。

陰極まれば陽に転ず。

しかし、まっかな海の世界の話だ。この世界では意識しているかどうかと関係なく、自分の生産性を最大にしようと振る舞ったものが生き延びる。そこでみんながみんな、自分の取り分を最大にするために好き勝手を言う。「みんなの意見といっても、自分の気に入った意見で固まるだけじゃん。時間のムダだからテレビを観よう!、スポーツをしよう! だまって働け!」とかね。しかし、検索をかければ何かしら異見を目にできる可能性がある。それが重要なわけじゃん。赤い海だと思っていたら、時間を多層的に使う技術も見つかるかもよ。2層式DVDみたく2層式時間術とかね。

銃・病原菌・鉄〈上巻〉―1万3000年にわたる人類史の謎(ジャレド ダイアモンド)

ginとgunだけが似ているが、意識しているだろうなぁ。

_ 黒いプレゼン

もしかしたらおれの誤解かも知れないし、だいたい、そんなにいろんなパターンを見たわけでもない。

でもだ。

次の法則は言えるんじゃないかなぁ。理由は後述。

1. パワポの基本は白地

2. 高橋メソッドはツールを限定しないが、基本は白地

3. Keynoter（キーノーター）の基本は黒地

4. JavaScripterの基本も黒地

いや、3は本当は良くわからないんだけど、ビルゲイツのプレゼンって白地に黒い文字が浮いてる気がするけど、ジョブスのプレゼンって黒い壁の中に白く字（というよりもなんらかのグリフ）が浮いてるように思うんだけど。

4.は、brazilさんのプレゼンの印象が強いだけかも知れないけど。

だからなんだと思うかも知れないが、黒地に白文字ってのはいかしてるのだ（と、書いた瞬間に「語るに落ちたな」とこのページが目の前にあることに気づかれるとか思ったが、別にそれは意識してるわけじゃない。というか、textareaに打ち込んでるときは白地に黒だ）。

で、上の法則に則って、のりお本ってのは初めてRubyistあるいはレイラーが3や4の段階に歩を進めたってことですな（と書いたあとから角谷さんのプレゼンがもろ3だったことを思い出したり）。

というか、書かなければならないものの期限が迫っているので、何か打ち込まなければあならないという強迫観念が、見事にムダな方向にパワーを発揮しているだけということなのだが。

_ VistaにVS6

不思議だが、メインの開発機にはVS6がちゃんと収まっているのに、ノートのほうに入れようとすると最後に失敗して（コントロールパネル上にはいて、かつ一応は実行できる）SP6が当てられない。（サポートされていないのだからある意味当然で仕方ないとは言えるけど）

それにしてもどうやってメインマシンに入れたんだろうか？　（x64を更地インストールしたはずだから、XPのころのインストールの引き継ぎではないと思うのだが、記憶違いかなぁ）

移動しながら1.8.7をいじろうとしたのだが厄介なことだ。

_ インターフェイス

角谷さんから『インターフェイス指向設計』を献本してもらったので、薄いってこともあって、大体読んだ（つもり）。

インターフェイス指向設計 ―アジャイル手法によるオブジェクト指向設計の実践(Ken Pugh)

ぱらぱら読んだ限り、悪くない。むしろ手軽さからは良いのではなかろうか（落とし穴はあるかも知れないから、そこはがっつり読み込んだわけではないので断言はできない）。

まず、この本は普通にUMLを使いたい人（そうでない人は規格本を読むと良いのではなかろうか）で、良く使い方がわからない人の役に立つ。ファウラーの薄いUMLの本も良いけど、これもいいね。少なくとも、シーケンス図、状態遷移図、クラス図、ユースケース図は押さえられる。設計するには、とりあえずそれだけ書ければ十分だ （コンポーネント図と配置図は、UML2で微妙になってしまったしなぁ）。

でも、ちょっと思ったが、この本のUMLってOmni Graffleっぽくて、Judeっぽくないけど、そんなものなんだろうか。（大きなお世話だね）

でも、それはどうでも良い。

ポリモーフィズムとインターフェイスについて、わりと納得しやすい例で始めているところも良いと思う。

JavaとかC#がC++より良い点って、メモリー管理とかじゃなくて、インターフェイスがあること、かつそれが、継承とは完全に分離されて、ただもうポリモーフィズムのために存在している点だと僕には思えるし、それに沿っているからだ。

でも、データインターフェイスって必要か？ とか思ったりもするが、そこはちゃんと読み込んでないから、必要なのかも知れない。うん、APIではなくドキュメント型インターフェイスというのは、そう言い切ったところがおもしろい（というか、そういうコンセンサスがあるのだろう。知らなかったけど。ヴォキャブラリーがそれに当たると考えればよいのだろうか。というか、単にプロトコルでのリクエストレスポンスの取り決めのことを文書インターフェイスと言い換えただけのようにも思うが、概念を固めることは良いことだ……が、オブジェクトをDTOとしてエンコードするのか、文書としてエンコードするかの違いにわざわざ名前をつけただけのように見えるのだが、区別する必要があるんだろうか？）。

と、まあ、読めば何かしら反応できるので退屈もしない。

デザインパターンのおおざっぱだけどたぶん、今となってはこれで十分かも、のような解説もある。特に、デコレータパターンとプロクシパターンの区別について、今までで最も簡潔かつ納得がいく説明があって、思わず納得した（良くわかってなかったようだというか、わかっていなかった）。「Decoratorパターンでは、ユーザーの側がデコレートを行います」――あ、なるほど。そりゃそうだ。

ただ、ゴミのような問題点がある。ひどい問題だ。

UMLについてはこの本で適当に書き方を学ぶで良いかも知れないが、この本のコーディングスタイルは最低だから、絶対マネをすべきじゃない。

うがって見れば、JavaとC#の両方に色目を使ってすべてを台無しにしたという感じだ。

例：正しいC#のコード(MSDNによってオーソライズされている)

public class BeautifulWorld
{
    public BeautifulWorld()
    {
        if (IsReal)
        {
            throw new IdontWantToSeeTheRealWorldsProblems();
        }
    }
}

例：正しいJavaのコード（JDKによってオーソライズされている）

public class PrettyWorld {
    public PrettyWorld() {
        if (isReal()) {
            throw new IdontWantToSeePeopleWhoWantToRuleTheWorld();
        }
    }
}

例：この本のコード

public class WhatYourName
    {
    public WhatYourName()
        {
        if (unpa() && runpa())
            {
            throw new PleaseTellHimTheRightIndentSettingPlease();
            }
        }
    }
}

まったくお手本にならない。

追記：スティーブマコネルさんはこのインデントを推奨しているらしい(via @hajimehoshi)。だからといって、（おれにとっては）まったくお話にならないことには変わりはないんだけど、そういう考え方もあるということは知っておいても良いかも。
CODE COMPLETE 第2版 上 完全なプログラミングを目指して(スティーブ マコネル)

ところで、低凝縮かつ密結合な設計って、存在しうるのだろうか？ ……DTOでんがな？

_ メモ

ジェネレーティブプログラミング (IT Architects’Archive CLASSIC MODER)(クシシュトフ・チャルネッキ)

776ページか。

_ 夢の跡

マルチスレッドGUIツールキットは夢の跡（松尾芭蕉的な意味で）

おもしろかったので途中まで訳したが、結構難しいってことと（英文が）、今更感がぷんぷん漂っているので挫折した。というかSunだからもしかして既に和訳されてたり？

追記：新丈 径さんが訳してくれた。ありがとうございます。「マルチスレッドツールキット：見果てぬ夢？」

特に興味深いのは、実は最後のほうにあるコメントで、GUIツールキットを構成するプログラミング言語のコルーチンの欠如を指摘している。つまり、マルチスレッドではなくイベントキューで良いのだが、イベントハンドラへのファイアの個所をツールキットが抽象化してコルーチンにすれば良いのではないかという指摘。コルーチンっていうのは、この場合、継続の意味だと思う。

ああ、と何か見えた気がしたのは、イベントドリブンとWebアプリケーションの類似性とか、むしろWebアプリケーションよりもイベントドリブンプログラミングでの分断の度合いの強さ（Webアプリケーションは設計上、分散を意識し、イベントつまりリクエスト間は疎結合にする、すべき。しかし、GUIアプリケーションでそんな作りは普通は取りたくない。1プロセス1アプリケーションなんだから密結合で良いはず）に対する一定の解に違いないとか。

で……おれはコルーチン（この場合Fiberよりも継続だと思うのだが）を避けてきたが、ちょびっと興味がわいてきたのであった。

……いやFiberで良いのか。実行を与えれば良いのか？ （今20:20か）

_ はじめてのFiberプログラミング

OS Xだと自由に使える（使いかたを知ってる）GUIツールキットがtkしかなくて、しかもtk良く知らないんだよなぁ。

とりあえず使えることはわかった。最低の例だが、cd_timer.rbのボタンを無理矢理Fiberを使うようにしてみた。

#オリジナル
b.command(proc{ 
            if mode == :start
              timers.each{|timer| timer.restart}
              b.text('reset')
              mode = :reset
            else
              timers.each{|timer| timer.stop.reset}
              b.text('start')
              mode = :start
            end
          })

これを無理矢理Fiber化してみる。と、軽くやってみたらクロススレッド違反になった。……ってことはウィジェットのproc内で作る必要があるのか。あまりうまくないけど、まあしょうがない。

def new_fib(b, timers)  # ウィジェットのイベント処理スレッド内で実行
  Fiber.new do 
    while true   # まったくおもしろくない処理
      timers.each{|timer| timer.restart}
      b.text('reset')
      Fiber.yield
      timers.each{|timer| timer.stop.reset}
      b.text('start')
      Fiber.yield
    end
  end
end
b.command(proc{ unless fib   # ここで作るのがなぁ。
                  fib = new_fib(b, timers)
                end                               # ここまで
            fib.resume })                   # でもキャプション状態の保存は不要に!

（30分かかったorz）

#追記： それにつけてもWindow3.1の頃に、高速で動作する……というか、VBがコルーチンを言語仕様としてサポートしていたら（中間コード方式だからできなくはないはず）世の中、相当変わっていたんじゃないかなぁと、過去のアプリケーションを思い起こしながら考えた。

_ VistaでむりやりVS6

先日のVistaにVS6がインストールできない話の続き。で、にっちもさっちも行かなくてアンインストールしようとしたら、\progra~1\microsoft visutal studio\common\Setup\1041\setup.stfが無いというエラーになった。

これか！

うまくインストールできているところから、そのファイルをコピーして（インストールされたファイル情報が入るテキストみたいだ）やった。

で、あらためてセットアップを走らせたら（アンインストールはやめ）、修復か、追加/削除か、とか聞いてきた。そこで追加/削除で、VC++だけ残して実行して、今度は無事インストール完了が出た。

で、SP6を当てて終了。

_ まるごとRubyの見本誌届いた

さっそく自分のパートに書き間違いを見つけて悲しくなる。

とりあえず、わかっているものをここにメモ。ムックだから正誤表とか出ないだろうなぁ。（追記：編集の方に連絡したら、出していただけるとのことでした）

P.15 リスト6

誤）

try {
    hnd.processParameters(hnd);
} catch (Exception e) {
    // ...
    Logger.getLogger().log(e);
}
if (dirty) {
    params.save();
}

正）

try {
    hnd.processParameters(params);
} catch (Exception e) {
    // ...
    Logger.getLogger().log(e);
}
if (params.dirty) {
    params.save();
}

P.42 コラム2行目

誤）樹木状のなるだけで、

正）樹木状になるだけで、

P.42 図AのクラスC

誤）メソッドb

正）メソッドb'

お詫びして訂正します。

まるごと Ruby! Vol.1(るびきち)

それはそれとして、やはりいい感じだ。

るびきちさんが良い仕事をしている。『試行錯誤ツール、テスト／デバッグツールを使いこなす』は力作で、いろいろ勉強になる。rcodetools（これをgemでインストールする）に入っているxmlpfilterというのは便利そうだ。さっそく導入する。

ごとけんさんの、1.9入門はうまくまとまっていて、これがあれば1.9を利用開始できるな、という感じ。

とりあえず、そのあたりを読んだ。

_ だめだな

unless fib   # ここで作るのがなぁ。
                  fib = new_fib(b, timers)
                end            

とか書いているが、なぜ

fib ||= new_fib(b, timers)

とすぐに出てこないのかと。

_ GUIマルチスレッドツールキット

先日言及したグレアムハミルトンのだけど、新丈さんが翻訳してくれたので、日本語でも読めるようになったわけだ。Failedが変わっちゃったけど、まあいいや。あと、WikiName付けるとき何か夢をみていたようでタスキングしてしまったけど。

ここで彼がなぜムリかという理由として、上から下と下から上の同時多発呼び出しでロックがむちゃくちゃ難しくなるということを挙げていて、それは実感として正しい。

たとえば、あるスレッドで動くアプリケーションがボタンを押されたことをシミュレートしようとする。すると呼び出しは、APL→ツールキットフロントエンド→コントロール（ウィジェット）→描画オブジェクト→描画プリミティブ→描画ドライバというような道筋をたどる（そんないっぱい描画なんちゃらがいるかどうかはおいておいて）。

ちょうどそのとき、ボタンが押されているとする。すると

マウスドライバ→入力シグナル→マウス読み込み→コントロール→描画オブジェクト→……を行ってかつ、→ツールキットフロントエンド→アプリケーションのマウスイベントハンドラ呼び出しが起きる。

ここで、上から下へのロックと上から下へのロックが同時に起きることがあり得るために、デッドロックが生じる可能性がある。

でもだ。

似たような入出力モデルを持ちながら、そこまで破綻はしていないツールキットをおれは知っている。みんなも知っている。

Webサーバーだ。つまり、入力イベントはサーバーソケット一本と、多数のクライアントソケットを利用したモデルだ。

何が異なるかというと、アプリケーションから下向きへ進むのは、ピアとなるクライアントソケットに対してであってサーバーソケットではない。

ここで、サーバーソケットをマウス入力、ボタンコントロールの描画をクライアントソケットと考えてみる。すると、確かに見た目同一のボタンに対するマウスイベントによるプッシュと、アプリケーションによるプッシュが同時に発生する可能性がある点が、ソケットとは異なることがわかる。

わかるのだが、この場合に必要なロックはボタン描画の箇所だけで良いのではないか？ 入力と出力はコントロールの異なるリソースの利用となるはずで、かつ同時多発があり得るのは出力だけで、それだけならばデッドロックとはならない。

いや、違う話なのかも。

それなら、.NET WinFormにInvokeは不要だ。コントロールの中でInvokeをすれば良いわけだから（あれ、なんでそうしなかったんだろう？ ――イベントのリエントラントがあるからかな？ それならコントロールの中にキューを持てば済むんじゃないか？ と思ったけど、それでキュー処理に遅延が生じたときに大騒ぎする連中がいそうだから防御線を引いたのかも。敷いたのかもが正しい日本語かなぁ、突然江戸っ子）。

でも、高々デュアルコア程度のデスクトップマシン用アプリケーションがマルチスレッドで一体どうするという気もするのであった（プリントタスクなら外で動けばよいし……インクリメンタルサーチをどう実装するかを考えれば良いのか）。

とか、そのあたりのことをちょっと考えてみたりして。

_ またBBB買ってみたり

GIRL FRIEND(Base Ball Bear)

1曲目はいいな。

で、2曲目の題にひっかかって、3曲めを聴くと……これRespectable Streetじゃねぇか（iTSで買うとクレジットとか見えない）。……おもしろい呈示の仕方だなぁと思ったり。

Black Sea [2001 Reissue](XTC)

（オリジナルより、BBBのほうが好きなので、そういうのもありかなぁと思ったり）

これも出てたので買った。

changes(Base Ball Bear)

ボーカルが聴き取れるようになったせいで（うまくなったのか、録音方法を変えたのか）、相当気恥ずかしい感じ。高校生のころに聴きたかったね。気持ちの良い、いい曲だ。

_ 自己言及型メタデータ？

Don't Repeat Ourselves

Safariのデフォルトでまったく日本語優先でもなんでもないわけだが。

_ バヤデール

牧阿佐美のラバヤデールを観に、新国立劇場。B席だからどうかと思ったが、むしろ全体が良く見えて良かったかも知れない。

ドンキホーテもそうだが、ミンクスって作曲家はすぐ忘れてまったく印象に残りもしないが、その場その場ではとても印象的な良い曲を作る。とつくづく思いながら序曲が終わると、いきなり半裸の男が火の前に座っている。

なんかアラビアのほうの話かと思ってたら、インドなのか。とはいえ、まったくインドとは関係ないお伽噺の世界ではある。で、兵隊が6人、あとから生かしたあんちゃんが飛び跳ねながら登場する。で、息もつかせぬまま引っ込んで代わりに服着た僧侶が出てきて、親分が出てきて、踊り子が出てきてちょっと踊って、ベールを被った真打ち登場。ベールがうまく取れなくてどうなるかと思ったが、ぎりぎりのところで取れて踊り始まる（そういう演出なのかな）。

お話はひどい話だ。踊り子は黙って男を取られて泣き寝入りのようなやわいやつじゃなく、ナイフを振り回して太守の娘に襲いかかるし、好きでもない男の言うこと聞くくらいならあっさり死んでしまう。で、呪いのおいでおいでをして寺まで破壊するわ、最後はよもつひらかさへ男を連れて行くのかなぁと思わせながらあっさり振り切って置いてきぼり。

でも、びっくりするくらい優美な踊り。ウクライナの人らしい（ザハロワ）。男（マトヴィエンコ）もくるくる良く回る。リフティングもきれいに決まり、見事なものだ。

瓶の踊り（不思議なパドトロワ）もおもしろい。

ただし、おきまりの白いバレエ(どこがインドなのやら)はやはり退屈で意識を失った（白いバレエの部分で最後まで弛緩なく観ていられたのは今のところ白鳥の湖くらいだな。音楽の差だ）。最初次から次へとわいて出てくるところで32人も出てきて、なんか、親猫のあとから仮面ライダーが1号、2号、V3……みたいでおもしろい演出。きっと8×4だろうと思ったら本当にそうなった、でもカーテンコールは12+10×2。

途中退屈したけれど、全体としては優美で（エキゾチックかなあ？ 金粉ショーの神像には度肝を抜かれたけど。どういう魔法なんだ）バレエらしいバレエ。主演の2人が良かったのだと思うが、これは再演したらまた観たいな。

_ 無知と退屈

上のやつで思い出したが、なぜ白いバレエで退屈するかというと、おれが未だにバレエの文法をちゃんと知っていないからだ、ということだ。だから音楽が良ければ観ていられるが、そうでないと脈絡が取れないので退屈するのであった。

音楽もそうだが、伝統芸術には伝統が続いた分だけ、複雑な文法が構築されているので、それを知っているか知らないかで、相当なインパクトとなる。伝統芸術ではなくとも、そこらじゅうで見られることだ。

最終的には、それを知りたい（理解したい、取り込みたい）と思うか思わないかで決まるわけだ。

それを知的好奇心の有無で切り分けるのも無理があって、おそらくぎりぎりのところでは、生存戦略で決まるのだろうな。

でも、興味がないものについては、そんな文法をわざわざ覚えたくはないのであった。バレエについてはこれだけ観るようになると、そしてそれが嫌でもなんでもないのだから、そろそろまともに知っておくべきかも知れない。

そうではなく、その文法そのものを愚かなこととしてバッサリ切り捨てるべき場合もある。

ランジェ公爵夫人が素晴らしいのは、バルザックがまさにそれをしているからだ。優雅で文字通り貴族的で、つまり何も生まず、発展もせず、ただ単に時間だけを消化していく恋愛遊戯を、革命の申し子、神権の否定者、現代人の始まりのような連中が、ばっさり切り捨てて、死と恐怖が常に背後にある現実を仮借なく見せつけること、それが実に鮮烈に描かれていることだ。楽しそうに。足取り軽く。

十三人組物語　バルザック「人間喜劇」セレクション(バルザック)

まして、それが気に食わない文法の存在であればなおさらだ。

文法と書いているが、シンタックスではなく、コードが正解かな？

_ カスピアン王子の角笛

子供と渋谷で観る。初回に行ったら吹き替え版だった。

10:30開演に対して10:00くらいに行ったらすさまじい混雑っぷりで階段の下まで行列している。が、良く見ると客層がなんか違うっぽい。若者でいっぱいで子供連れがいないし。聞いたらシネセゾンのほうだった。で、松竹のほうはがらがら……と思ったら、最終的には満員になってたけど。

原作とは相当異なる。ピーターの冒険主義。プログラムで監督が言い訳をしているのを読んだが、年齢を嵩上げしているのが全体に影響しているようだ。良くもあり悪くもあり。演技がどこまで可能かとか考えると良い選択だったのかも知れないとは思う。おそらくライオンと魔女よりさらにうまい映画に見えるのはそれがあるのかも知れない。

森が動く、この世の終わりだというマクベス的なところもなし。（最初からマクベスにしようとしたわけじゃないだろうけど、どうオチをつけるか構想しているときに、英国人だから当然の教養として持っているだろうマクベスとの類似性にふと気づいて、にやにやしながら書いたのではないかとかいろいろ想像してみる）

しかし、リーピチープの作り方は、瀬田貞二のある種ドンキホーテのような古風な言い回しを使ったおもしろさはないものの、テンポ良いセリフ回しとそれに見合った素早い動きとあいまって、えらくうまい。というか、小学生のころに読んだナルニアの記憶でいちばん印象に残っているのがリーピチープ（あと、確か魔術師のおいだと思ったが、別れのあたりとか）なのだが、やはりこの物語の白眉シンだな。

映画としてはライオンと魔女より物語をいじくったせいも多分にあるだろうが、さらに良い感じで無駄な説明調もなく観ていて楽しかった。ライオンにはうんざりさせられるが、これはしょうがないだろうな。

カスピアン王子のつのぶえ―ナルニア国ものがたり〈2〉 (岩波少年文庫)(C.S. ルイス)

1960〜1970年代の児童文学ではあたりまえの言い回し（リーピチープのせりふ回しは別）が、日本語がヘタ扱いされるのは興味深い。50年もたたないうちに言葉が変わるということだな。なんてことがわかるのも、インターネットのおかげというものだ。

ライオンと魔女―ナルニア国ものがたり〈1〉 (岩波少年文庫)(C.S.ルイス)

_ 軽量

ジェネレーティブプログラミングの6章を読んでいて、おもしろい記述にであった。

その一方で、閉じていない多態は本質的に軽量です。インターフェイスに関する情報は、キーボードから入力する必要も、コピー＆ペーストする必要もありません。ともあれ、それは実装されたコードの中に暗黙のうちに表現されています。それに加えて、型チェックを「怠惰（lazy）」に行います。C++のテンプレート（つまり、閉じていないパラメータによる多態）の場合、型チェックはテンプレートをインスタンス化するときにはじめて行われます。Smalltalkのような閉じていない多態の場合には……（後略）

―P.173

この引用の冒頭に出てくる「軽量」は「lightweight」だろうことと、この本の出版年が2000年ということを考えると、lightweight languageという言葉の出所のひとつとして多態の分類からの観点というものもあるのだろう、と思った。

ジェネレーティブプログラミング (IT Architects’Archive CLASSIC MODER)(クシシュトフ・チャルネッキ)

で、もしそうだとすると、少なくともこの本の定義上、lightweight languageというのは「閉じていない多態」を実装した言語ということになる。「閉じていない多態（unbounded polymorphism）」は、上記引用のように「閉じていないパラメータ多態（または制約されない総称性）―unbounded parametric polymorphism / unconstrained genericity」とは明確に区別されているけれど、元の書き方から「軽量」とは、閉じているかどうかによる区別と読めるので、どちらもlightweightと読める。

まあ、それだけだけど、C++も使い方ということでした。

この本の後書きについての言及をNyaRuRuさんがされていたが、当初予定していた出版社からキャンセルされたところを翔泳社の古田島さん（コンピュータ関連本の人なのかな）に救ってもらったとか書いてある。厚いし値段も内容も高いけど、参考文献リストだけで30ページある本が、日本語化されている点にも価値があると思う。

リストはほとんどC++で、ごくまれにSmalltalkも使われている（閉じていない多態の例は、C++では書けないからだろう。それ以外はC++で書ける）。Javaもちょっとあるけど。

インテンショナルプログラミングをインデンショナルプログラミングと空目して、どうしてここでPythonが出てくるのかと不思議に思ったり（出てこない）。

とにかく実装技術のところを読むのがおもしろい。もっとも、「見果てぬ夢」の可能性もあるわけだが。

_ わざとバグを入れたCの入門書

翔泳社の編集の方から献本していただいたので、読んでみました。

デバッグではじめるCプログラミング(山本 貴光)

今更、おれが読む本でもないしと思わないでもなかったけど、読んでみるものだ。おもしろかったし、参考になった点もあった。

全体としてはゲームを作る本で、BC++をCで使うことを前提にしている。なぜBC++と大きい疑問を感じたけれど、エラーメッセージの適切さが理由のようだ（とは書いていないが）。

最初に、簡単な出力、入力があって、ちゃんとカタカナでprintfはプリントエフと読みますとか、scanfはスキャンエフと読みますとか読み方も指南している。

で、ゲームを作るというのはどういうことかという読み物ふうのエピソード（著者の方は光栄に勤めていたらしい）が来て、企画とおおざっぱな仕様が来て、では実装していきましょうと話が続く。

で、リストをその通りに打たせるわけだが、タイポもあれば型エラーもある。コンパイルすればエラーになるので、こういうことをすることこういうエラーになる。その理由はこれこれです。修正するにはこうします。つまり、これこれするときには、こうしなければなりません、という調子でおまじないとは言わずに、書き方を説明していく。ゲームを題材というか教科を進めるためのエンジンにしているけど、ゲームプログラミングの本というわけではなく（ただ、ユーザビリティなどについてのある意味実証的な解説が入ったりもするし、プログラムを拡張していくためのユースケースはゲームのシナリオにそって出現する）あくまでもCの入門書だ。最終的には、ダンジョンのマップを格納する2次元配列が出て来て、位置情報から移動の可能性を求め、構造体を利用してキャラクタデータを保持して、さらには当たり判定をして、最後はポインタを利用することでグローバル変数の利用を抑制できることやスコープについて解説して終わる。流れを追うと実は正攻法だ。

結局、おれには迂遠だが、こういうのもありだろうなと思うし、学習の流れのつけ方には感心した。口調も良いし適度に脱線したりするところが妙にリアルなのだが、著者の経歴をみると専門学校で教鞭を取られているようだから、そのあたりから身につけた呼吸なのかも知れない。

追記：著者の山本さんの「あとがき 増補版」

_ 名前付きパラメータと位置によるパラメータの一致の不一致

えのさんが「named arguments considered harmful」というのを書いている。怒っているのがよくわかるのだが、と、ここまで書いてパーマネントリンクを取りにRSSリーダからはてなへ飛んだら、おれが書きたかったこと（ちょっと違うが）を成瀬さんがコメント欄で指摘していた。もっともole2disp.dllが頑張っていたおかげで、90年代からIDispatchインターフェイスの仮引数名は同じ問題を抱えていたから、意識改革しかないよなぁという気もしないでもない。

名前付きパラメータがえのさんの指摘のように不幸なことになるのは、位置によるパラメータと一致していることか、または仮引数名を集合として書けないことによると思う。

少なくとも、&keyの後ろだったら、追加すれば良いだけだろうし。

名前付きの名前を次のように書ければ、おそらく問題とはならず（実装は面倒だとは思うが）、位置によるパラメータとも矛盾しない。

public void foo([name="langage"][name="language"]string langage);

（[]はキー名として利用可能な値を属性として提示）

あるいは、RubyのHashを使う方法ではないけれど、位置はあきらめてしまって（速度的なペナルティが付く）

public void foo([type="System.Collections.IDictionary", name="lang"]string langage, string language)

というように書けて、定義側では if (lang["langage"] != null || lang["language"] != null)とかしてアクセスするようになっていれば良いのかも。

属性で位置を生かすというのも考えた。重複した場合のエラー判定が必要だけど、定義側は楽だ。

public void foo([index=0]string langage, [index=0]string language, [index=1]string message);

最悪のシナリオは、キー名違いのオーバーロードだな。

public void foo(string langage) {

foo(language = langage);

}

public void foo(string language) {

……

}

本末転倒という感じがぷんぷんする。

名前付き引数が呼び出し側からみた場合に便利なのは、インターフェイス定義からテンプレートが自動生成できることや、ソースコードの自動生成する場合に与えられたパラメータを仮引数名と関連付ければ済む（不足している場合に位置を意識しなくともかまわない）ことだとは思うが、こればっかりは使っていないのでわからないけど。（Excelのようにパラメータが無駄に50個くらいある場合には、確かに必要な引数だけ用意すれば良いので便利だとは思うが（ある意味では、引数の指定方法によるポリモーフィズム（逆転しているけど）と言えなくもない。同じメソッド名が指定した引数によって処理の意味が変わるから）、現在のVBアプリケーションに必要かというと怪しい）

_ Windows 2008 Server

会社のマシンに入れてみた。既定で強いパスワードの設定を要求するとか、user権限でインストールしようとするとAdministratorのパスワード入力を求めるとか、そのあたりはわりと洗練されているように思うが、致命的な問題を1つ見つけた。

user権限の持ち主が、自分のための環境変数を設定しようとするとする。というか、した。INCLUDE、LIB、PATHのあたり。Serverでするなよ、と言われればそれまでだが、別にそれ自体はできなきゃおかしいと思うんじゃない？

これができない。

コントロールパネルから、システムの詳細設定を選ぶ。これまでと同じだ。

そこで、Administratorのパスワードを入れさせられる。

それも良い。それは良いのだが、その瞬間にAdministratorへ偽装されてしまうため、All Userの環境変数と、Administratorというユーザーの環境変数しか設定できない。おい、どうやれば、今ログインしているユーザーの環境変数を設定できるんだ？ せめて、ユーザー固有の環境変数はドロップダウンリストか何かで設定したいユーザーを選択させてくれ、とか思うが、どうあってもAdministratorしかできない。

しょうがないので、user権限で作業するのはあきらめて、常時Administratorとしてログインすることにした。そのくらい、ユーザー固有の環境変数は重要なのだ。

というか、全然サーバーじゃないだろ。

#追記:ACさん（というのも変な書き方だな）の指摘が正しそうい（Vistaにはあるから、2008Serverにもあるだろう）です。

_ 泥

泥水をすする（ボルネオとかで山岳ゲリラになって戦うイメージ）

泥のように眠る（疲れきって眠りこけてしまう）

泥を吐く（秘密を白状してしまうこと）

泥をかぶる（不祥事とか悪事とかの責任の身代わりを引き受ける）

とかは言うけどなぁ。

イントネーションかも知れない。「ドロのように」のドにアクセントを置いて発音すれば、つまり「泥」として平坦に発音しなければ、ドロちゃんとかの場合のドロになるから、そういう意味かも知れないな。つまり、他人のわざを盗めと。職人さんみたいだ。

犬馬の労をとれという意味で使ったのだろうが、犬とか馬扱いはまずいと思ったのだろうか。言い方変えても内容は変わらないが、シンタックスシュガーは重要だということだな。

ところで、生涯雇用と右肩上がりの収入を片方に置かないとバランスがとれないと思うが、そういうことではないのだろうか。でも、そういうスタイルは否定されていたような気がするのだ。だって私の髪は長いもの。

_ LL Future

チケット買った。

_ ヘッドフォン買った

MVPヘッドフォンのネックバンドの蝶番（？）が折れてしまった。ぷにゃぷにゃプラスティックなので接着剤でも付かないしどうにもしょうがないので廃棄処分。しかし無線の良さを知ったおれが、iPodのおまけイヤフォンに戻るはずはなく。

以前、笹田さんから教わったUSBのやつも考えたが、AirだとUSBポートがふさがってしまって、するとUSBメモリを使いたいときはいちいち外すことになると気づいたのでやめにして、またまたBluetoothに挑戦。

Amazonでいろいろ眺めたが、価格が中間（あまり安いとさすがに音と耐久性（今回経験済み）が不安だし、これより高価だとノイズが乗ること考えるとなんかもったいないし）で、デザインがそこそこで、ネックバンドなのでモトローラのにした。

【国内正規品】 MOTOROLA Bluetooth ワイヤレスヘッドセット HT820 Gray HT820-GR(-)

音と耳のクッションは想像以上に良かった。MVPのやつと違って折れ曲がらないので携帯性はゼロだが、これは耐久性ではプラスだろうから、OK。ただ、今は相変わらずチェチェチェチェンジスだのドラマチックチックだのを聴いているから気にならないだけで、浄められた夜だのペレアスだのを聴き出すと（ちょっと今、初期新ウィーン派の復興運動が始まっている）また異なる印象を受けるかも知れない。チックチック。

ふと気づいたが、Visorの中の人のドラゴンボール以来のモトローラかも知れないなぁ（知らないうちに入っていることもあるだろうけど）。

_ 側を意識する

側ったって、左側とか右側の話ではない。それはそうだけど、右側には注意したい。

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

カプセル化という言葉がある。ある必要性から、コンサバなOOPの本を読んでいるのだが、カプセル化のところを読んでいると、まず何よりもカプセル化というのはフィールドを隠すことだのようなことが書いてあって、まだこんな無意味なことを最初に出すのかと不思議に思う。したがって、理由を考える。

カプセル化で最も重要な点というのは、オブジェクトの状態に対する外部からの操作を「不要にする」ことだ。

としてみる。これが、一番、感覚的（もちろんこの感覚はおれの感覚だ）には重要だからだ。

であれば、重要なことは、インスタンス単位にデータが分離され、そのインスタンスを操作する手続きがあることだ。この手続きが配置されるのが構造体内部の関数ポインタなのか外部の関数かどうかは、上の「外部からの操作」とは一切関係ないことは明らかだ。

したがって、カプセル化そのものについてはクラスは不要であるし、Cでも問題なく使える。構造体を引数にする一連の手続きを用意すれば良いからだ。

つまり、カプセル化という概念は、OODの分野に属し、OOPではその状態と操作のペアを同じ括りで記述できるようにしているために、ソースコードの記述性に優れる「だけ」と言える。

さて、今、右も左もわからず、デザインパターン（GoFを意味するのではなく、たとえば上で書いたカプセル化というのがデザインのパターンに属するということをここでは書いている）を知らない人間にカプセル化を説明することを考える。

実のところ、上で感覚的にしっくりとくる「外部からの状態操作を不要化する」ということはいろいろな角度から言い換えることが可能だ。

もっともプログラミング的な言い方をすると、「外部とのインターフェイスにはAPIのみを利用する」ということだ。

デザインパターンでは、ファサードを建てるということになる。人は表玄関から出入りする。そのほうが広いし、門番もいるし、レセプションでコード（ドレスコード）チェックまでしてくれる。

これと、裏口の存在や大量仕入れのための地下搬入口の存在は矛盾しない。

したがって、フィールドの可視性というのは、なぜ必要なのか？ という疑問に突き当たる。

着飾ったお嬢さんが、わざわざ汚水にまみれながら下水道から忍び込むかね？

「もちろんです。あの連中は目が悪いから、表玄関から来ないのです。あるいは、連中は怠惰なので、たった10メートルの距離をショートカットするために裏口から入ってくるのです。だからprivateにしてやるのです。それが一番重要なのであります」

面倒になってきちゃった。