著作一覧
著作一覧 |
なるほど。こういう仕組みなのか（今日、初めて入ってみた）。
デキシーズは持ってるから、ためしに検索したら出てきたNaked EyesとOrchestral Manoeuvres In The Darkを買ってみた。ばかだな、しかし。
気づいたら20分近く同じ曲をダウンロードするところで止まってた。とりあえずiTunesを終了させて（ダウンロード中だけど良いか？ と再起動したら再開するよの2つのダイアログが出た）、再起動したら無事再開したようだ。
まあ、うまくできてるようだ。でバックアップってどうするのが筋なんだろう？ CDへ焼くくらいなら最初からCDを買うわけだし、DVD-RWに焼くとかが良いのかな。それとも、場所と保管期間の価格のほうが、いざとなったら再購入より高価につくと、ほったらかしにするのが正解か。
自転車で走ってると、無灯火、逆送のカスと良く交差する気がする。
最初のうちは、なんとなく、そういったクソはばばっちいからよけていたが、気が付くとよける方向って右側なんだよね。つまり、逆送ヤロウは歩道寄りを走ってるのだ。
でも、それはおかしい。
車はこちらの背後から来て、逆送ヤロウとは対面通行なんだから、危険が良く見える連中のほうが右寄り（こちらから見て。つまり中央分離帯寄り）に行くべきジャン。おれは、うんこやろうどものために、自らを死地に追いやっていることになる。これは馬鹿げている。ちなみに、前を同じ方向に走っているあんちゃんとかがいると、何も考えずに右に寄って逆送のカスを安全側に倒してやってるんだが、あんた、それ危ないよ。自分の過去の動きを振り返って考えるとどうも本能的な動作のようにも見える。しかし、それはうんこを避けさせられているだけで、主導権をゴミが握っているからかも知れない。つまりあっち側からくる左巻きドモが歩道寄りをキープしてくるから自然と押し出されているだけなのかも。
というわけで、意識的に逆送小僧を見かけたら徹底的に左に寄るようにしていると、意外なことにあの蛆虫ドモは、他人の危険には鈍感でも自分の危険には敏感らしくて戸惑うんだね。これはおどろいた。一寸の虫にも五分の魂か。
で、大体行動は3種類。
1. 気にせず右（こちらか見て）に入って進む。
これ、オッサンに多いように見える。といっても1割程度。
2. ぎりぎりまで近づいてから右に抜ける。
これがほとんど。7割くらいか。
3. 止まる。
この場合、こっちも止まる。と、大体2になる。しかし賢いやつも居て、駐車している車と車の間にはまってこちらをやり過ごそうとするのも居る。OK、しょうがないな。その場合はでもこちらは直進で済むから勘弁してやる。若い男（青年ってことだな）とそれなりに若い女に多い気がする。でも、歩道に逃げるのはいないみたいだな。
どうも、自分たちが歩道寄りを安全に走る権利を持つと勘違いしているらしい行動パターンだ。
ちなみに、こういう腰抜け連中（1.のオッサンたちは少なくても腰抜けじゃないな。どこかネジが緩んで抜けてはいそうだが）の自転車ってたいていいい加減な自転車が多い（って、おれのもそうだから心配すんな）。ヘルメットかぶってたり、本格的だなうらやましいなや、自転車便とかが逆送してくるのは見たことがない。
で、そういった車種と、無灯火率と、見た目だけど性別と世代別の統計を取ってみようと思いついた。多分、無灯火率は100%だと今のところは思うんだけど。あと、実際には違反らしいが発光かつ白光のダイオードの（点滅する）やつがほんのちょっと。
なんとなくきちんと有意な結果が出そうに思えたからだ。
でも、一昨日、昨日と天気が怪しかったんで自転車通勤じゃなかったし、今日はまったく逆送ヤロウを見かけなかった。残念だ。
子供のころやったカルタの「無理が通れば道理引っ込む」の絵は、橋の上での日吉丸と蜂須賀小六の出会いの場面だった。と突然、思い出した。
#無理が通りをやってくるからと言って道理が引っ込む道理はない道理だ。ちなみに無理が通りをやってくるというのは馬鹿が戦車でやってくると同じイントネーションで発音する。
9÷3＝3
だなぁ、と思ったり。
IQだかEQだかが高いとセグメンテーションされた層は、もとからNegativeなんだから、彼等に資料が見えても無問題。ターゲット層はどっちにしてもそんな資料は読まない／読めない（だからそのセグメントにいるわけで）から無問題。
早稲田を通ったらいつの間にか大学芋があったとこからまっすぐな道が都電のほうに続いていて、なんじゃこりゃと思って降りたら右側にでっかなビルがある。確か第2文学部とかがあったあたりかな？ とか思いながら右折してもう一度右折（明治通りにでると混んでそうだから、早稲田通りを直接Uターンせずに大きく回って夏目坂へ抜けようとしているのだ）したら、見覚えのある道が出てきて、混乱した。
そう言えばグラウンドを潰したとか聞いた覚えがあるけどこうなったのか。で、見覚えのある坂を登りきるとさっきの新しい道に繋がっていて、本当はこっちの坂に出たかったのになと（そうすれば、都バスの車庫を越えてポストモダンなマンションのある道に出てそのまま夏目坂に入れるのだが、道が違ったから右折のタイミングも間違えたのであった）思ったが、それはそれとして、抜弁天から靖国通りへ続く道も妙に整備されたし、時々道ががらっと変わる（そう言えば甲州街道から大山へ続くとこも妙にまっすぐな道ができた）のだが、あれはおもしろい。どこへ行かされるのかわからないところと、ヘタをうつと行き止まりになるところとか（たとえば、今はつながったか以前、国立からピーコックのところを通って立川方面へ抜ける道とか）、で、私道協会の支配の先の乃木坂の道も変わるんだろうかとか。そう言えば私道協会の道はここ数日、良く猫を見かける。私道協会の厳しい指導にもかかわらず、こっそり猫を育てている心優しい人がいるんだろうか。人影に物怖じしないきれいな猫たちだ。
そんなものは無いというのには強く同意する。
私（あるいは私が想定する存在しない誰か）が読んでも理解できない、あるいは一目ではわかりにくいコード、ならあるかも知れない。
でも、聞くは一時、聞かぬは一生というものでもなく、調べるのは一瞬、それでおしまいなわけで、ある言語の文法にしたがって記述したものが理解できないということはありえない。難読化していたって読むのは可能なのだが、それは別の話になるので、あくまでも書いた人が普通に書いたコードのこと。
というか、もしあるのなら、それはその仕事に向かない。遠視の人の辞書の校正のようなもので、別の人に代わってもらったほうが良いだろう。だいたい自然言語の文章と異なりコンパイラーですら解釈できるのに、まして人間様が読めないはずはありえない。
だから、「トリッキー」という言葉が出てきたら、眉にツバを付けて臨むべき、あるいはそんなくだらない迷信で対処するのではなく、ばかですね、と言えば良い。
もし、あるコードが読み手にとって難しければ、理解せず（あるいは読みもせず）にコピペということは無いだろう。したがってコピペ＆修正ミスという黄金パターンにはまることも無い。無駄が多いとコピペしやすい（読んでその気になれるし、行数があるから打ち込むのではなくコピペしたくなる）ので、結果として修正が漏れる（行数が多いから）。しかし既存のコードなのでコンパイルは通る。
とはいうものの、センスの良い短いコードが往々にしてトリッキーと呼ばれることがあるようだが、実際に読みにくいのはセンスの無い（悪いじゃなくて、無いという厳然たるもの）コードで、これはどんなに長く書こうが短く書こうがインデントがあろうがなかろうが、読めないんだよね。なぜだろうか。
・子供の作文パターン（メリハリがなく、要点が絞れず、すべてが平坦）
今日僕は朝起きて顔を洗って歯を磨いてランドセルに教科書を詰めているうちに登校の時間になったので朝ごはんを食べたかったけど登校の時間になったので今日の朝ごはんのおかずは僕の好きな卵焼きだったけど時間がなかったので食べるかどうか迷っているうちに……
このパターンのプログラムは往々にしてコーディング規約を満たしているのだが最悪に読みにくい。
・ゆんゆんパターン（実装継承を好むシロウトパターン）
今日僕は朝起きて卵焼きだったけど詰めているうちに時間がなかったので登校の時間になったので歯を磨いて……
もっとよく考えましょう。子供の作文と同じことをもっとまずくやっていますね。でもなぜかコーディング規約を満たしていたり
・トリッキーなコード
だらだら用意をしていたら登校の時間になってしまった。朝のおかずは大好物の卵焼きだったのでちょっと迷ったが結局あきらめた。というわけで今日は朝抜きだから早く給食の時間になると良いな。
歯磨きや洗顔が抜けているトリッキーなコードです。
追記：言語的な解説としては、「aに1を加算する。aが0でなければ……」ではなく「aに1を加算し、その結果が0でなければ……」のほうが、組み合わせが増えた場合にマッチングのストレスがかからないから、代入と比較は同時にすべきであるという話。if ((buff = breader.readLine() != null) {みたいなやつ。確かにこのての書き方でコピペによるミスをしているのを見たことは無い。
#なんかタイムリーに同じようなことをこないだ記事に書いた（表現は違うけど）ので激しく同意したのであった。
サメはつまらなかったがこっちはすごくおもしろかったぞドリームワークス。最初、子供のためにイヤイヤ行くという感じだったが（サメがつまらなかったし）、でもとても楽しめた。今年見た中では象についで2番目。ペンギンやアナキンより映画っぽくておもしろかった。
ペンギンがシージャックしようと船長室にやってくる。それまでペンギン視点でペンギンを撮っているからペンギンのサイズはスクリーンの縦の4/5くらいはある。それが、船長室に入った瞬間に視点が切り替わって1/10くらいになる（人間の視点になる）。そこで4人並んでペタペタ歩く。あるいはその前のドアから飛び込んでくるところ。
砂浜でライオンが箱から出てくるところと、キリンの箱を見つけるシーン。キリンを箱から出そうと突進するところ。
リスザルのダンスパーティ。音楽スキスキ。踊るのスキスキ。
生き物がステーキ肉に見える（黄金狂時代でチャップリンが鳥の丸焼きに見えるくだり―なんで条が出てこないんだ―をはじめこのくらい映画的な手法はないな）ところ。夢の中の舌なめずり。
話の内容は深刻。なんでライオンが最後までパラダイスへ行かないかとか。
ペンギンにしろキリンにしろライオンにしろ動きがとても映画的だ。サメもそう言えば兄貴がくたばるシーンが映画の動きだったのを思い出した。たとえばロボッツ（ワーナーかな）より遥かに動きがリズミカルできれいだからだ。
ストラウストラップは
C++ was designed to support data abstraction, object-oriented programming, and generic programming in addion to traditional C programming techniques under these constraints.
- The C++ programming language third edition p.22 -
（抽象データ型−これ良い訳ではないね−とOOPと総称プログラミング（に加えてこれらの制約の下で伝統的なCプログラミング）をサポートするように設計してある）と言ってるんですが、この言い方だと、抽象データ型とOOPは並立しているように見えます。
ここに限らず、どうもStroustrupの書いたものを読むと、C++にとって抽象データ型はすごく大事なポイントで、OOPはすごく便利なポイントというように考えているように思えます。この場合、OOPはポリモーフィズムの実現という意味以上のものは無いのではないかと考えられるのは、OOPについて語る箇所にはクラス階層とvtblを利用した実装の話が付いて回る点です（かつ、他にもやりようはいくらでもあるんだが、と少しばかり投げやりな感じも見える）。
このように読むと、StroustrupがC++で重視しているのは、あくまでも抽象データ型（これはデータ構造と操作言語の組なので、良く『カプセル化』と言われるものと同じ）であり、それが型である以上クラス中心主義という呼び方はそんなに外れてはいないと思います。
#vtblの中身（と大元のポインタ）を動的に変えればC++でインスタンスベースのOOPもできるじゃんとか思わないでもない。
#なんかプログラマー日記(9月2日)のコメント欄が盛り上がっていて楽しそうなのですごく久々にtCppPLとか読んでみたり（デザインのほうのやつは家に置いてあるので読めない）。
#っていうか、thisを省略できるというのはすごく大きい気がする（selfが省略できなくなるのはやだな）。あと常に省略可能なthis以外については操作の対象（＝object）を最初に記述するのだから、OOP以外の何物でもないとも思う。まず対象物、そして操作。なるほどインテリセンス（コード補完）だな。
kmt-tさんから反応があったんだけど、
・トラックバックが打てない（追記：設置ミスでした。ごめんなさい）
・ある言語の……理解できないことはありえない、というのには賛成できない
・トリッキーなコードは駄目コード、というのには賛成できない
という3点が挙げられていて（追記：点だけを書いていたので修正した）、ちょっと1については実験（ここをトラックバック先にして打つ）。
2については後ほど（追記：書いた）。最初に書くと、HOGE/HUGAが何してるかさっぱりわかりません。でもそれは問題なしと僕は思います。
3って、これは僕に対してではないですよね？ 僕はトリッキーなコードというものは空想の世界の話だから、そんなものにだまされちゃいけないよ、と言っているんだけど。駄目なコードというのは読みにくいコード、センスが無いコード、退屈なコード、つまり僕の主観でだめなコードと、コンパイルできないコード、脆弱性があるコード（これはそのコードの実行コンテキストにも依存する点に注意）、遅いコード、リソースを不必要に食うコード、バグがあるコード、つまり実行に支障があるコードの2種類から構成されるのであって、トリッキーかどうかなんていうのは関係ありません。
うが。tb.rbを入れてなかった……orz
壊れかけている、が正確かな。突然、プッチンパッチン言いながら画面がパキパキ点滅したり、それは恐ろしいのなんのって、爆発すんじゃないかという感じ。だましだまし使うにもそろそろ限度という感じだ。
一応ビデオカードも疑ってみたが、他のマシンに繋いでも同じだ。
まあ、考えてみれば14"―15"―17"―19"と順調に来たわけだし、こいつも買ってそろそろ5年くらいになるんじゃないか？ ゴミ捨て料金を見ると4000円とか出ていてげんなりするが、しょうがない。
で、履歴を考えると次は21"だが……高いよ。
B00082391C
というわけで20"で妥協。
ちなみに、この10ヶ月でLDプレイヤー、洗濯機、掃除機、ガスコンロ、モニターと順調に壊れてるんだが、購入時期は異なるのにどうしてこうなるんだろう？ というか、コンピュータもなんかおかしくなってきてるし。
kmt-tさんのトリッキーなコードはちょっと矛盾がある。
最初に、
コードのバックグラウンドにある理論が解ってないと理解できない（特に高度な数学や学術的な内容を含むもの）コードってたくさんあるような気がします。
として、次に
多分、これ読んでも何やっているか解る人は殆どいないと思いますが、正攻法より性能がでるので個人的には有用なコードだと思います。
という例を出している。
最初の言明を次のところで引っくり返しているように見える。高度な数学でも学術的でも無いという言い方もあるのかな。でも、僕には4バイト浮動小数点数のビット構成を一目ではわからないからFP_ONE_BITS 0x3F800000が何を意味しているかはわからない。
この場合、僕の立場（そのコードを見て何をやっているかわからないということ）から少なくても2種類の反応があるのだと思う。1つは、「これはトリッキーだから禁止」。もう1つは、「で、何をやっているのですか？（訊ける場合。または）調べるとするか」。
もし、仕事でこのコードを読むのなら後者を選ぶのは当たり前の話だ。前提が
・そのコードが出て来るプログラムのソースを読むのも仕事のうちである（必要なら、やれ。というだけのことだ）
・それが仕事だということは、可能だという予測がついている（無理じゃないということがわかっているということだ）
・そのコードの界隈に他のメンバーがいる（＝調べてわからなければ、あるいは調べる時間的な余裕が無ければ訊けるということだ）
となるからだ。
もちろん、例示ではなく現実の世界であれば、HOGEとかHUGAという「名前」は切って捨てることになる。HOGEじゃなくてRECIPRO（かな？ 自信なし）、HUGAはEXPにするだろう。だが、コードを変える必要はおそらく無い（JITがインライン展開する可能性を持つユーティリティ関数が存在すると言う可能性があれば、そっちを使うと思うから「おそらく」）。
だから、僕は、2番目の（tbについての点は除いた2番目）のkmt-tさんの意見に賛成だ。正攻法というのはおうおうにして子供の作文になる。小学生用に教科書を書くのか中学2年生用に書くのかでは異なるのは当然だから、そのコンテキストに応じた良い結果を出すのが良いコードだと思うからだ。
したがって「トリッキーなコード」という呼び方は、結局のところ意味が無い。
へたくそや無知であれば、そんなコードが出て来るわけがない。逆に言えば、そのてのコードが出てくるのには理由がある。その理由がどこまで理に適っているか、あるいは理屈は通らなくても利に適う（適正なコストで使える）という切り口もあるけど。その理と利のバランスの問題で、そのバランスをどこに置くかだけの話だ。つまり「トリッキー」なんていう言葉には意味がない。
したがって、「〜という書き方はしないこと。トリッキーなのでどうしたこうした」というのは理由になっていないから「ばかですか？」としか反応できないということを、トリッキーなコードというとこに書いたのでした。で、おそらく、ほとんどの場合、トリッキーという烙印が押されるほうが理にも利にも適っているだろうな、と思う。っていうのは、トリッキーに見えるものというのは、ほとんどの場合は洗練されたものだからだ。洗練されて無駄が殺ぎ落とされたコードは、傍目には妙にコンパクトなので「トリッキー」という妄言の対象になるのだと思えるからだ。でも洗練の過程には必ずそのコードを作った人間の知恵が入っている（ただし、歴史の澱になっていることもあるからちょっと難しい。キャッシュラインを無視して、4バイトのコピーを*(long*)p = *(long*)&buff[3];なんてやったら却って遅くなる可能性があるとか）わけだから、それはイディオムとしてむしろ学ぶべきものだ。
単純な理屈ではfor (i = 0; i < 4; i++) { *((char*)p + i) = buff[3 + i];}（うむ、Cは忘れた。左辺はこんな書き方であってるかな？）よりも、*(long*)p = *(long*)&buff[3];のほうが1回で4バイト転送できるので高速なはずだが、実際には異なる可能性もある。そのあたりが、妙な手動最適化をするな、というような話になるのだが、であればトリッキーなんていう言葉を使わず、JITにお任せ、とかコンパイラにお任せとか、まずは計測とか言えば良い話だということだ。あるいはダブルチェックロッキングのように、なぜかnullチェックを2回やることで高速化を狙い、しかも実はそれがメモリーモデルに反しているという逆転に次ぐ逆転みたいなこともあるのだが、それに対してダブルチェックロッキングのような記法を「ほら、これだからトリッキーなコードは……」というような言い方はできないということだ。少なくても「トリッキー」なんて言葉を不用意に持ち出す人間の100倍は（仮に間違った結果であったとしても）先人の知恵が含まれているからだ。
これは、応用と基本の問題でもあるな、と書いていて気付いた（というふうに脱線するけど、日記だから問題なし）。
レシピブックみたいなイディオム集に問題があるとすると、「なぜそういうコードになったのか」を読み飛ばして単純に結果のコードが利用される可能性があるところだろう。それ自体は利には適っているから必ずしも悪くはないのだが、でも時々は理由を考えたほうが良いし、そのためには原理とか仕様に対する知識が必要となる、ということだ。なぜなら、永遠のコードなんてものは存在しないからだ。CPUがかわったりメモリーバスのアーキテクチャが変われば昨日の最適化は今日には遅くなるかも知れないし、final付ければ速かったものが、final付けなくても速いし付けるとモッキングが出来ないとかにも変わる。なんでそうしたかを知っていれば、それをやめる時期も理由もわかる。単に使っているだけだとやめ時もかっては有効だった理由もわからない。当然代替案も出て来ない。
で、話は飛ぶが、まだまだ粒度が細かい。だからこういうコードの1行とかに関するつまらん規約とかが必要になるんだろう。そういう規約で縛る必要がある世界に対しては、もっと粒度を粗くしなければ無駄だと思う、というように考えは続くのであった。
テレコズム―ブロードバンド革命のビジョン(ジョージ ギルダー)
ジョージ・ギルダーという人がいて、ニクソンのスピーチライターだったりゴアの知恵袋だったり、とっても怪しいんだが皆さんごぞんじですか？ 私は一昨日までまったく知りませんでした。
で、読む気はほとんど無いんですが、いやこれを読まなきゃ嘘だろうというご意見があれば募集中です。
伊原さんのメモ（追記：イの字を間違えてました。ごめんなさい）。
これいろいろ使い道があるはずなのだが、FDへコピーした瞬間に消失しちゃうという問題があったけど、今はFD使わないしな（でもFTPしたらやはり消えるだろう）。
#ゾーン情報の保存に使うというのは思わず納得。
・メタデータ
・構造化記憶
![馬鹿が戦車でやってくる [DVD]](http://ecx.images-amazon.com/images/I/616295V6W1L._SL160_.jpg "馬鹿が戦車でやってくる [DVD]")
馬鹿が戦車でやってくる [DVD]![マダガスカル スペシャル・エディション [DVD]](http://ecx.images-amazon.com/images/I/61KN1A0PFRL._SL160_.jpg "マダガスカル スペシャル・エディション [DVD]")
マダガスカル スペシャル・エディション [DVD]
// I like C#
public class Foo {
protected int facility;
public int Facility {
get { return facility; }
}
...
}
継承したクラスはフィールドを直接アクセスすることで設定可能。それ以外の利用者にはread onlyとして提供。
これは、VS2005 RCではVB.NETで継承するとエラーになる。
元々CTSには違反している（はず）これはCLS準拠違反(確認しました。多謝)。VB.NETはケースインセンシティブだ。したがって、これは矛盾しているので×。
VS2005 ベータまでは、VBからはプロパティしか見えていなかったのに。
では、どうするのが正解か？
(1) protected int m_facility; (2) protected int _facility; (3) protected int facility_;
どれも標準コーディング規約に違反している。
(4):
protected int facility;
public int getFacility() {
return facility;
}
うむ。八方丸く収まった。
か？
追記：しょせん、他人事とあまり深くは考えていなかったけど、結構、やっかいであるなぁ。コメントにはああ書いたけど、プロパティのセッタとゲッタでアクセス指定子を変えるなんて細かいことはできるんだっけ？ というのが1つと(.NET 2.0でできるようになったから−とLady.BUGさんのコメントではなっている−コンパイルエラーにするようにしたのかも)、それはそれとしてprotectedフィールドを利用したいという場合もあり得る点。
#継承関係があるクラスは、もう、どうしようもなく密結合しているんだから、それを前提として設計して良いと思っている。
たとえばpublicなセッタではレンジチェックするが、直接フィールドをさわることで、特権的な設定をサブクラスには許可するというような場合。
もちろん、protected void setFacilityWithoutCheck(int x); とか protected void setFacilityCheatly(int x); とか
あくまでも変なメソッドを用意しても良いかも知れないけど、外部インターフェイスで機能仕様そのものなpublicなメソッドと違って、あくまでも内部処理の延長なprotectedなアクセスであれば、そこまでムキになって変なバイパス用メソッドを用意する必要もなかろう。
つまり、問題は、フィールドに対して透過的なプロパティのあるべき名前は何か？ ということ（あるいはその逆）。
Javaだと何も考えずに
int facility;
public void setFacility(int newFacility) {
facility = newFacility;
}
public int getFacility() {
return facility;
}
と書けるけど、C#/VB.Netではその手は利用できない/あまり利用しない方が良いのではないかということ。だからといってm_facilityとか_facilityとかfacility_とか nFacilityってのはいやなこった。
スロットとか？
public class Foo {
protected static readonly FACILITY = 0;
protected int[] attributes;
...
public int Facility {
get { return attributes[FACILITY]; }
}
...
}
#これもダメじゃん……。enumにして名前空間を区切れば良いのか? Javaと違って数値だったはずだし。
ついふらふらと買いそうになったが、多分、iPod picoが出ると思うから待とう。
どなたかがアフィリエイト経由で買ったのを見てついショッピングカートに入れといたので、こっちをチェックアウト。
奇妙な天使か。天使の顔写真とは関係ないけど。
後、これも。サイベリアってシベリアのことなのかなぁ。シベリアは寒そうだ。
追記：っていうか、辞書ひいたらやっぱりシベリアじゃないか。サイベリア特急？ サイベリア抑留？
それはそれとしてiPod nano、やっぱり欲しいかも。ちなみに僕は白のほうが好きだ。（でも実物を見てないので質感がわからないから錯誤かも）
オバQ「P子、お兄ちゃんのことを尊敬しているか？」
P子「まさか」
オバQ「それではこれから尊敬するように」
P子「えーどうして？」
オバQ「それは、偉いからだ」
P子「どこが？」
オバQ「だってお兄さんだということは先に生まれたということだ」
P子「先に生まれたらどうして偉いの？」
オバQ「えーと、えーと、……そうだ、先に生まれると書いて先生と読む」
P子「ふーん」
#そもそもなんで急にオバQがこんなことを言い出したのかは覚えていない。
ある職業の年齢に下限があるって変なことか？ 求職案内を見るとほとんどの場合上限があるぞ。上限があれば下限もある。どっちもやめろというか、どっちもOKと見るならわかるが。自分が制限に引っ掛かれば文句あり、引っ掛からなければ気付かない。意図的なダブルスタンダードは政治という人間の知恵の一種だが、無意識のダブルスタンダードはオバケのQちゃんだ。
モローを子供と見に行った。
出口のミュージアムショップにボッスのクリーチャの模型が売っていてちょっと欲しくなった。買わなかったけど。
で、子供が興味を持ったので家にある画集をちょっと見せてやったり。しかし買ったときはネロほどじゃないが（生きてるし）結構苦労したのだが、アマゾンで値段を見ると当時より更に値上がりしていてちょっと驚く。5万円台か。でも20年前の3万8千円よりは相対的に安いかな。
それにしても本物はすごいな、とモローを見ながらつくづく思った。たとえばヘレナの絵だが、手元の画集ではまったくわからないことがいくつもわかったり。他の女性と異なり、本当に顔を描いていない（絵にも書けない美しさ？）のだが、にも関わらず鉛筆による下書きはあって、その上に白を塗っているため、良く眺めると下にうっすらと眼の丸があって、パックしたオバケ女性のステロタイプになっていたり。
部分の素描がたくさん、色配置の実験、ミニチュア版、そして本物。
要素技術のテスト、プロトタイピング、アーキテクチャ見本、プロダクトみたいだ。要素技術の確かさと細かなイテレーションに裏打ちされた幻想。
ゼウスではなく雷帝だからユピテル、でもミューズではなくムーサとか、表記の揺れが良くわからなくて子供に説明すると書いてあることと違ったり。星座がギリシャ神話だというのは、このてのものを説明するのに楽だな。でもヘラクレスとヒュドラの絵にカニがいないことにこだわって細部をいろいろと探していたり。なんで焼く役の友人がいないんだろう？ 死んだふりしてるんじゃない。
V字の構図と、Vの真ん中にTが入る構図。肖像画のフレームワーク。
つい、Bicカメラに寄って触ってみたり。というか4Gは売り切れ。2Gだけある。確かに2Gモデルは割高感があるよ。
それにしても実物は、写真と違って2トーンって感じがあまりしない。なんでだ？ あと、ちょっとテカテカかな。シャッフルもてかってるけど。miniのマットな感じと微妙な薄い色は異質だったんだな、とか。
#なんか、本物を見たらいらないや感が強くなった（購入してまではいらないや感。くれるのを断るほどのいらないや感ではない）ので、やはり本物を見るのは重要なようだ。
きしださんからサインを貰う。
カバンからみすず書房の本が何気なく出て来るところがいかしていた。
結論は、顧客の非論理的な要求というものを論理化できるプログラマは自由な意思の持ち主である、ということらしい。
約40人もいると、ちょっと傾向というものが知りたくなるので角谷さんに頼んでアンケートしてみる。なお、数字はとっても大雑把。僕は野鳥の会の会員ではない。
・利用言語（重複あり）： Java 30、.NET 5、PHP 5、その他 5
・ターゲット： Webアプリケーション(B2C限定ではないと思うけど) 30、基幹系（Web無関係） 10、組み込み 1〜3、その他 ？
・開発プロセス： いわゆるウォーターフォール 10、アジャイル 10、その他 30
.NETの少なさにちょっと驚く。開発プロセスの「その他」というのが興味深い（ハイブリッドということであって、無手勝流というわけでは無いとは思う――追記：というわけでも無いらしい）。
日本的な動きだなと思って、この選挙結果をみていました。
なるほどなぁ、と納得してしまった。変える変えないという時に、これまでずっとやってきたところを（わざわざ）支持しにのこのこと出かけるというのは、確かにそういう考え方が根底にあるからだというようにも見えるな（たかだか10人を大げさに斬って捨てることでそれ以上の大きな釣果）。今度のWindowsは……とか、それまで嫌な目にあっていようが、それまでの実績がどのようなものか知っていようが、節目となると逆にはりきって支持してしまうわけなのかも。今度は変えます、本気です。で、どう変わるんだろうか、なかなか楽しみである。
・雷が鳴ると気が削がれる（らしい）
・キューはCommand（これは僕の純然たる興味。StateとStrategyは明白に相違がわかるんだけど、Commandってどうもわからないんで。実行するやつが選択するのがStrategyで実行するやつが選択しないのがCommandということらしい）
・DxOというのは、どうやら絵に（記号として）描いたときにeXcahngeのXを挟んでDataとObject（どっちでも構わないけど、中が白抜きになった箱）が両脇にあるのがミソではないかと思った
・層ってのは時間とは関係ないんじゃないか？（ここからは直接は関係ない）もちろん関係ない。
・もしレイジーロードとかしている最中のエラーが問題となるのであれば、それはViewの位置が悪いと思う
・POJOはMbVが可能なのがミソだと思うのだが
・アプリケーションロジックという言い方。Smalltalk由来らしい。
・意外なほどIDEデモに感心する（ふりかも）人数がいるのにちょっと驚く。へー
・サービスレイヤーは当たり前
・僕の夏休みはどこへ行ってしまったのでしょうか？（でもリンクはしなかったり）
・3次元フローチャート（というのを思いついた）
・ひがさんと高橋さんは�遒離織鵐�トップ。しかし微妙に色が違う。
・羽生善治。ルールを変えた伝道師（兼勝負師）。なるほどね。
・ジェネリクスは、関数のパラメータが型制約されるのが当然だったのに対して、それ自体をパラメータ化できることを示した（ということかな？）。自然数の世界に対してゼロと負を導入したようなもので、それまでの前提＝世界が、実は単なるサブセットであることを示した、ということなのかなとぼんやりと考える。
・図の→が間違えてるんじゃないかという指摘。RecognitionはProductに対して与えるようにするのが本当。でもまあ例だから。つまりダブルディスパッチすべきとkoichikさんから。
・iBook 12" ほすい……（でもそれどうすんだというのはあるけど）
・ケントベックがデマルコった。でもそれってどんなこった、てらこった。
全然別の話。abortを_NTだったらtlhelp32のAPIに置き換えるで良さそうな気がする。
これ、いい。コンパクトにまとまっているし、用語の用例の宝庫でもある。そう言えば、GUIのViewはModelのことを知り抜いていたな（だから更新通知にはパフォーマンスオプション用のヒントしかなかったりする）。Viewはモデルに対して特化するからだ。
r-matudaさんなのか。
役に立たないよな、と思っていたのだった。
EoDというお題目からいけばIDE重要だから1.は十分にありそうだ。でもどうってことは無い話でもある。2番目は悪質で、そのうちベストプラクティスとして
Strange Angels
サイベリア
public class Color {
static final int COLOR_RED = 9;
static final int COLOR_BLUE = 10;
...
}
みたく、COLOR_というようなインポート元を示すプレフィクスを付けましょうとか言い出すようになったりして。それを人は本末転倒と呼ぶ。
でも考えてみたら、thisについては置いておくとして、mix-inなのかも。なら利用価値が見える。
すべてのメソッドは必ずしもインスタンスを触る必要はなくて、それがstaticかそうでないかはデザインによって決定される。別にthisを参照しないからstaticというように機械的に決定できるわけではない。（いや、とんでもない規約でthisを参照していないとstaticにしろ、と文句を垂れるとかしていることもありそうだが、デザインを考えないのならそれはそういうメタデザインなのだから知ったことではない）。
たとえば、文字列操作用の便利メソッドユーティリティがあるとする。それはたとえばStringUtilクラスというような名前がついていて
String after = StringUtil.filterFoo(before);みたく使う。でも、文字列のフィルタをしまくるプログラム（たとえばDisplayableStringBuilderとかしておく）であれば、呼び出し先が外部のユーティリティクラス（StringUtil）のメソッドである必要はない。
public class DisplayableStringBuilder {
StringBuilder buffer;
public DisplayableStringBuilder(String original) { ... }
public String buffer() { return buffer.toString(); }
public String addDecoration(Decoration decoror) { ... }
String filterFoo(String part) { ... } // フィルタメソッド(自前) thisは参照しない
String filterBar(String part) { ... } // 同上
}
しかし、このfilterFooは既にStringUtilに実装されている（というよりも、DisplayableStringBuilder以外のクラスからもガンガン利用可能）。
というような場合に、StringUtilという外部のクラスは無視して、あくまでもDisplayableStringBuilderの自前の延長線上のメソッドとしてStringUtilのメソッドを取り込みたい。
というような場合が、使い道なんだろうな、と『地味だけど便利! - Static Import』を読みながら思った。mixinとは書いていないけどそういうことを言っているのだろう。
教科書を読み直したら、補償トランザクションはsagaのdefinitionに組み込まれていました。ということは、補償トランザクションがある＝サーガは、少なくてもバーンスタイン本を教科書とする限り正しいです。噛み付いてすみませんでした>WRさん。
This is called a saga: a sequence of transactions that either runs to completion or that runs a compensationg transaction for every committed transaction in the sequence.
(p.120)
完全に実行するか、またはシーケンス上のすべてのコミット済みトランザクションの補償トランザクションを実行する、トランザクションのシーケンス
この定義に従えば、トランザクションのACID特性のうち、Aを満たしたマルチトランザクション（時間軸に注目すればロングトランザクション）をサーガと呼ぶということになります。
ついでに言えば、補償トランザクションは自動化されることが定義上必要です（とは言え、どこまで実用的に運用可能かというと疑問がありますが）。
これを実現するためには補償トランザクションは元のトランザクションの実行順を遡ることになります（なぜならばロールバックによって自動的にアトミシティを満たすための機能を持つことが定義なので）。あるトランザクションが順にA→B→Cの3つのトランザクションを実行する場合に、Cでロールバックした場合に補償トランザクションがCからBへ送り出され、Bを（ロジカルに）ロールバックし、BはAに補償トランザクションを送りAが（ロジカルに）ロールバックする、こういったロングトランザクション／マルチトランザクションの実装形態がサーガトランザクションです。
赤い伝票がA→B→Cと、ロジカルなロールバックを実行する場合、これは意味的には補償トランザクションかも知れませんが、上の定義を満たす補償トランザクションではありません（少なくても自動化されていない）。したがって、これは単なるロングトランザクションまたはマルチトランザクションということになります。
以上が言葉の定義に厳密なトランザクションの伝説（サーガ）です。
#しかし、赤伝だろうが補償トランザクションの実行に人手を介す必要があろうが、アトミシティだけでも守ろうじゃないかという心意気で作ったロングトランザクションシステムはそれだけで立派に伝説（サーガ）足り得るのではないかと思わないでもないけど。
というところで、シベリウスのサガ(op.9)を聴きながら、この後に続くレミンカイネン(op.22)のサガ（英雄詩譚）にでも思いをはせてください。
（性（さが）だと椎名林檎だが）
追記：yoshiさんのTB参照。Garcia-Molinaという人が元らしい。
年配の観客が立ち上がって、「MacPaintというのはプログラムの歴史上、最も素晴らしい作品だったんじゃないかと私は思うのですが、ソースコードを見せていただくということは可能なのでしょうか」という質問をしてきたんだ。その質問をした年配の観客というのは、実はドナルド・クヌースだった。
おもしろい。質問をしたクヌースもおもしろければ、FDにソースを格納するために工夫が必要だった時代もおもしろい。Computer History Museumというのもおもしろい。っていうか、なんか夢があるね。
NerdTVの作品をNHK教育とかでやってくれないかな（もちろん日本語字幕か吹き替えで）。
#く、CCなのか。CCだってことはこういう他力本願寺な言い方は無効化されるんだよな……でも、誰かやってくれないかな。
追記：もちろん、福盛さんが訳されてることについて最大限の謝意と賛辞は惜しまないわけです（が、最初それが抜けてましたな）。感謝してます。
実は非常にやっかいなプログラムを持っている。とあるコンポーネント（OCX）で、VB4の時代から利用されている。時代背景から当然のようにMFC4.0上に構築されている。MFCDUALを利用してデュアルインターフェイスを実装しているのは我ながら慧眼だったが、それはまた別の話だ。
このOCXの問題はフリップフラップ（oをアと読むのは良いよね？）だ。
Aというプログラムに貼り付けるとある特定のタイミングでハングする。
OK。修正しよう。
Aは動くようになった。
1年が過ぎる。Bというプログラムに貼り付けるとある特定のタイミングでハングする。
OK。修正しよう。
Bは動くようになった。
1年が過ぎる。A'というプログラムに貼り付けるとある特定のタイミングでハングする。
OK……これはいつか見た状態だ。Aの問題の時の修正と同一症状みたいだが……でも今、Aは元気に動いている。なぜ、同じような構造のA'が確かにハングするんだ？ 修正したはずだし……
そこで気付く。B用の修正が最初のA用の修正を打ち消してしまったことをだ。巧妙に別の方法でオリジナルの状態に戻してしまっていたということだ。
ではなぜAは問題が起きないのだろうか？
2年という歳月がインストール対象のマシンを変えたことが原因だ。
オリジナルAがインストールされたマシンはBの修正の影響を受けずに2年前の状態で稼動している。Bの修正後にAがインストールされたマシンはその時点のマシンだから影響を受けていない。
つまり、AとBはこのOCXを全く逆の使い方をしているために、本来両立しない仕様を要求していたのだ。しかし、時代が変わりCPUやメモリーやHDDはムーアの法則にしたがったりしながら進歩して、元の構造のまずさを打ち消してしまったのだ。
でも、時代は新たな機能を要求し、Aをさらに重くでかく複雑にしたA'を生み出した。A'には最新のマシンも能力不足で元の仕様の逆をつく問題が顕現してしまったということだ。
そこでA'のために、B用の修正を元に戻す。
さらに1年がたつ。予期していたかのようにB'が登場する。
今度は、A’打消しを行う。でも大丈夫。
また1年が過ぎる。たまたまA''は遅れているようだ。
さらに1年が過ぎる。やっとA''が出てきた。
そこでB'打消しを行う。手馴れたものだ。
そしてまた1年が過ぎる……
選択肢を考えてみよう。
1. フリップフラップを続ける
2. Aを根本的に変えてBと同様にさせる
3. Bを根本的に変えてAと同様にさせる
4. コンポーネントを根本的に変えてAとBを両立可能にさせる
2,3,4は既存のコードベースをゼロに戻す必要がある。アーキテクチャの問題だからだ。どこで入力しどこで出力し、どのようにプロセス間で通信し、どのようにネットワークを利用するか。
1.は永遠に続く（かも知れない）。しかし安定している。
iPod 15Gのバッテリが何もしないでも3日くらいで空っぽになるようになっちゃったけど（買って1年半くらいしか経ってないと思うが）、そういうもんなのかな（そういうもの＝Appleクォリティとか、なんか。っていうか3ヶ月くらい何もせずに放置していたのが効いたのかな）。
しかしバッテリ交換で約1万6千とかって、元の値段と比べるとすごいなぁ。
こうなると、既に移動用にはShuffleがあるので、iPodはiTunesのバックアップディスクとしてのみ利用としたいが、それは可能なことなんだっけ？
・Mac側クラッシュ
・Macへ新規にiTunesをインストール
・iPodを接続
・iPodが空のiTunesに同期されて空っぽ化
→バックアップとしては使えない
か。となると、単なる外付けHDDとしての利用となるわけか……（それはそれで使えなくはないがなんとなく口惜しいような気も）
シュトックハウゼンと言えば、国立劇場でのまさに凍てつく雅楽を思い出さずにはいられない。オートバイを乗り回す猿。
グルッペンという曲は3群のオーケストラから構成される。それについて柴田南雄が、伝聞として書いていたブーレーズについての逸話を思い出す。ロスバウトとブーレーズと誰だかが指揮を執ったのだが、ブーレーズの側から聞こえてくる音があまりに美しいので、聴衆は曲の構造を無視してブーレーズ側のパートばかり耳を傾けてしまい、これっぽちも3群から構成した意味がなかった。思えばそれが指揮者ブーレーズ伝説の始まりだったのだと。
そのグルッペンをアバードが振っている。これは聴かざるを得ないだろう。歌を歌わすということにかけてアバードが特別な才能を持っていることは明らかだ。そして少なくてもグルッペンに関しては優れた指揮者の下では美しい音楽が聴こえてくるのだ。
多声法が横軸と縦軸に注意が必要なアセンブリプログラミングなら、和声法は進行を中心とした高級言語による手続き型、ミュジクセリエルはすべてのパラメータを一度分解して再構成することで多声法の手法を極限まで分解した別のパラダイムに相当する。個々のセリーは状態を持ち得ないので関数型と類比することができるかも知れない。グルッペンはそれを3つのノードに分散させたものと考えることができる。それは極度に精緻な作業で、多分、疲れてしまったのだろう。1960年代以降のシュトックハウゼンは作曲家から上流工程の人になってしまったと言えそうだ。
Racc-1.4.4とamstd-2.0.0を追加 (racc.bat作成済み)。rjb 0.2.3へバージョンアップ。vrswin050618にバージョンアップ。zlib.dllをzlib1.dll (1.2.3)へバージョンアップ。
zlibのlib名が変わったので再コンパイルした。
Principles of Transaction Processing (Morgan Kaufmann Series in Data Management Systems)(Philip A. Bernstein/Eric Newcomer)
セリー主義
cd ~\ruby-1.8.2\ext\zlib
diff -u extconf.rb~ extconf.rb
--- extconf.rb~ Wed Apr 23 08:39:32 2003
+++ extconf.rb Sat Sep 17 22:52:11 2005
@@ -10,7 +10,7 @@
dir_config 'zlib'
-if %w'z libz zlib'.find {|z| have_library(z, 'deflateReset')} and
+if %w'z libz zlib zdll'.find {|z| have_library(z, 'deflateReset')} and
have_header('zlib.h') then
defines = []
yahoo.co.jpの自分の名前を騙るspamがあるから差出人＝artonx@yahooなメールをspam設定していたのを忘れていたもんで、なんでruby-listへ送ったやつが反映されないんだろう？ と不思議に思った。
皆、この機能が気に入り、Billが起こした新たな奇跡を祝福した。 それから数日後、MacPaintから文字認識機能を外すことにしたとBillが言ったとき、僕は耳を疑った。彼が言うに、もしこれを残しておくと、人々はこの機能をたくさん使うことになるだろう、そうなればMacPaintは優れたドローイングプログラムではなく、出来の悪いワードプロセッサとしてとらえられてしまうのではないか、ということを恐れたのだという。という部分が山場らしいけど、僕はビルアトキンソンがどんどんパレットにツールを追加してくとこが好きだ。フロンティアってのはこういうことなのか。
winebarrelさんの指摘を修正。
うう、ASRと連動なんですね。ということは、ASRも更新が必要か。
ちなみに0.2.4では次のようになります。
C:\test>ruby -rrjb -e "sys = Rjb::import('java.lang.System');sys.getProperty(nil)"
-e:1:in `method_missing': key can't be null (NullPointerException)
from -e:1
C:\test>ruby -rrjb -e "sys = Rjb::import('java.lang.System');sys.getProperty('')"
-e:1:in `method_missing': key can't be empty (IllegalArgumentException)
from -e:1
ちなみに0.2.3では両方ともIllegalArgumentException。
というわけでASR 1.8.2.4。
rjbに興味を持ってもらえると作者としては嬉しいけど、それの具体的な使われ方がわかるとさらに嬉しい。
SQLを簡単に発行することを目的としたDbUtilsモドキのデータベースアクセスライブラリーです。
……
すこしだけRuby対応 ※要rjb
――rubbish-db
明日、試させてもらおう。
追記：出版社データベースは自分で作る必要があるのかな？最初は、それが最初だと言うことそのものがリスクだから安定した技術と組み合わせるほうが正しいと思う。
次があるかが見えない状況では最後まで歩を進むたくなるかも知れないが、全てのパラメータが見えていないのだから、ある一点だけを極端に尖らせると嚢中の鑽となる可能性が高いだろう。穴が開いたら負けだ。
そこから、最初から袋に入れない、入らないと言う戦術も生まれるのだが、それは別の話だ。
福助ポイントが出て来たので失敗。
追記：書いたおれにもこの文章だけでは意味がわからない（前半と後半でサブジェクトが変わったからだけど。で、中間＝福助ポイントでサブジェクトを混ぜ込んでいる）
囲われれば、きっと生活は楽になるかも知れないかも知れない。でも、そんなにおもしろい暮らしにはならないかも知れないかも知れない。
Java関連の追加機能を提供するアドオン・ベンダーによる囲い込み――のリスクは、今日、これまでになく高まっていると危惧しているのである。
……
曰わく、オープンソースは「神からの贈り物」。ベンダーによる囲い込みを回避しつつ機能を追加することが可能になるからだという。
僕は異なる考えだ。
つまり、オープンソースはYAAV（yet another add-on vendor)だと思うからだ。神は神でもモロク神だ。
J2SE1.4、J2SE5.0の標準のLoggingと、Log4J＋common loggingどちらが利用されているか？ といったことがそれで、真の（JCPが採択した）仕様（+実装）とデファクトな仕様（+実装）の対立があった場合に、オープンソース実装はそれがオープンソースだというその一点で最初に選択される可能性が高い。暑さの夏にはオロオロ歩きもそういう気配を感じなくもない。が、それはやはり誤った選択だろう。標準に組み込まれたらさっさとそっちへ移行すべきで、それができないのなら、それはロックインされているということだ（というか、それがロックインという状態を指している）。ロックインされるのが好きなら、それはそれで良い選択だと思うのでだからどうしたということではない。が、YAAVだ。それにロックインされれば、AVLIと同質のYAAVLIに過ぎない。
#本当のことを言えばYAAVではない。それをネットワークから遮断された真夜中のシステム室で一人でソースを見ながら直せるのなら全然、問題ではない。その状況を想定すれば、小さな(特化したサブセットな)オレ様の世界を作るのがベストということだ。
ちなみに僕は、YAAV >>>>> JCP >>>>> AV/MSとは思わない。
オレ様(目の届く範囲の話なのは当然。企業システムの話なのだから) >>>> JCP >>>> その他（AV、YAAV、MSなど）と思っているだけのことだ。
毎日コミュニケ危機感ーション
1.8.3は未だこれから（多分、来週になっちゃうかも）。
目的：[ruby-dev:27267]（まだbladeには反映されていないみたいだけど）。
追記：10:37時点でまだ見えないけど、ちょっとドキドキ。なぜ？
追記：23:00時点で見えるようになっていた。
IPAの説明はわかりやすいな。ってことは、やっぱり図は重要ってことなのか……
soutaroさんのところ経由。
Dynamic Interfaces (or Strong "Duck Typing")
おお、確かにDuck Typingの文字が。
あ、でも考えてみたら、IDispatchってのはダックタイピングだったわけだから、ある意味では以前の方法（を使えるように）に戻したともいえるかも。
The dynamic-language community calls this "Duck Typing": if it walks like a duck and talks like a duck, then it is a duck.
でお決まりの、アヒルのように歩いてて、アヒルのように喋ってる、つまりあいつはアヒルだぜ。というのが。でもイギーポップという固有名詞は無い。
技術的にはダイナミックプロクシ＋デリゲートの自動生成ということみたいだ。
id:toshiyukisasakiさんと初台へ。
兵ドモがもうすぐ夢の跡地となるICCであらかじめ時間の記録を見ておこうと。
受話器が天井からブランブラン。取ると親父がモゴモゴ。バロウズからだ。
ドヒヘン、ドヒドヒと鳴るバイオリン、眼鏡のツルの打楽器、奇妙なクローンとか。で、2階へ。
大きな科学にうんざりさせられた口で、そのころはやっぱりニューヨークはジェームズチャンスとかでしょうとか思ってたけど、やっぱ違うわ。
右と左にぎったんばったんとか、プッシュフォンで物語、暗い小部屋でホログラム効果（魔法の杖を振る）、オウムがお喋り、そうそう昔、マルチメディアってのはCDの中に入っていてクリックしては次の世界へ入っていったもんだね、手がバタン。クリックすると手がバタン、クリックすると手がバタン、どうにもしょうがなくてエスケープとか。
机に肘ついて手で耳を押さえる。音を遮断しているポーズだが、実は音を傾聴。
部屋は広くて、音は明瞭、光と影がくっきり、暗い部屋はひたすら暗く、そしてほとんど訪れる人は無し、これはもったいないくらい贅沢な時だ。
小さなホログラムが騙りかける。語りかも知れないけど。鏡が汚れていて、それに彼女は気付いていない。鏡が汚れてますが？ え、そうですか？ こちらに来て見てみてください。まあ本当だわ。私に見えるものが彼女には見えない。そして私が訪れることは2度とない。
ジュークボックスは2に固定。
ゴッホみたい。というわけで私はゴッホみたいと書く。すばらしい個展だったまるでゴッホみたい。ある日編集長が私を呼び出す。ゴッホみたいはやｍてくれ。詩人について書いた。まるでゴッホじゃないみたい。
氷上のバイオリン（まだ髪が長い）。レコードのついたバイオリン。ドヒヘン、ヘン、ドヒのバイオリン（これはiBookのほうかも）。壁画を本人が描いたのか？ 本人が壁画を描いたのか？ ドラムスーツ。相変わらず暗くて誰もいない部屋の正面のでっかなスクリーンでドラムスーツを着た頭の毛をツンツンにした小柄な158cmしかないと壁のどっかに書いてあったが、ポーズを取るとドン、ガン、ピシャーン、カンカン。
で、トイレの前のベンチで寝る。とにかく寝る。夢を見る。海岸で寝ていたら自殺と間違えられて警官が呼ばれた。夢を見た。
枕に耳をあてると音が聴こえる。
で、トルネードだ。トルネード。上下と左右に音のトルネード。そこだけ上からスポットライト。オルレアンの少女はきっとトルネードから流れる声を聴いたに違いないと僕は確信する。
言葉が滝になって波紋を描く。日本語が落ちると英語の波紋。時々順序が違うのがあるが、意図した仕様ですか？
それぞれの音と夢。これまた広く、暗く、そして誰もいない。というわけで私はジミーカーターに会ったわけだが。と左下。その上はファンキー。左右対称つまりA-2では古臭い音楽。
で、最後の部屋では、テレビに腕。テレビに腕といえばプレノンカルメンのトムウェイツの腕に合わせて、何をかっこつけてるのよあほんだらの記憶がほとんどだが、確かにこの腕も記憶の片隅にあるな、ァァァァァ。ハロー、オー、スーパーマン。いい曲だ。ビジュアルが付いていれば。次にブラックな3人組のバックコーラス、キッドクレオールとかリジメルシアデクルとかZeとかと同時代ですな、と来て、でも、花を持った影が壁に残るとことか(言葉はウイルス。思い出したが途中で911って数字が入るけど相当に象徴的)。そして、シャーキズデイ。ああ、ああ、びっくりだ。こんなに新鮮、なんて斬新。T字型の独楽の上に未来都市。乗り物が世界を駆け回る。倒れこむと黄色に抜いた人影が踊り出す。iPodの広告ってセンスないね、と20年前の新しさに比べれば。
で、この3曲がぐるぐる。今でも耳に残ってる。ミスターハートブレークのリフレインとか。
全部見て、体験して、約2時間30分。
（っていうか、ビジュアルがついてなきゃ欲しくないが）
それにしても、曲だけを取ればトマスドルビーと同じようにやはり退屈だ。というか、音楽家じゃないのにレコードしかメディアが無かったというのが問題だったのだな、僕にとっては。
属性というのはつくづく面白い概念だと思った。
でも何が要素で何が属性かっていうのは、そんなに簡単には決められない。
属性＝メタデータと決めたとしても、昨日のメタデータは今日の要素ってこともあるだろうし。逆も真で、synchronizedとかvolatileというのは今日では属性だ。というか元々属性かも。でも、それが元々属性なら型だって属性じゃなかろうか。名前は属性だろうか。多分、属性だろう。
コンパイルが完了したら、ソースは属性かな。その前から属性だったり。すると、メタデータしかなくてデータが無いという状態を作ってることになるのかも。それはとても不安定な話だ。
といったようなこと。
オブラートがいろいろかかっている（糸井メソッドなのか？）ので真意が読めないが、それはそれとして一理も二理も九里よりうまい十三里半もあるように読める自分で作る話。
関心事は「作る」か「使わないか」なのだが、コンテキストによって「自社の分離独立王国が作ったものを使わせられる（ヒント：使えない）」「おれさまおれさま」「どこかの馬の骨が作ったものを使わせられる（ヒント：結構使える）」「どこかの牛の骨が作ったものを使わせられる」「作るのかったるいじゃん」「奴等が作ったものは意地でも使わない」「とりあえずあるんだから使っとけ（ヒント：使えない）」とかいろいろからむのでウィービングできるかどうかは技術だけでも政治だけでも気分だけでも決められない。ちなみに余の辞書にはジョイントポイントは無い。
非常に興味深い話なので、後で革めて能書きを垂れてみるかも。
サイボーグ戦士経由。
ちなみに最初サイボーグ戦死と誤変換されてたorz。
Bob: 今から10年後のあなたは何をしていると思う？
Andy: うわあ。もう60過ぎだよ - 今51歳だからね。
Bob: 僕もだ。僕らカッコイイと思わないか？
年を取るってのもそう悪いことではない（し、どっちにしたってそうなる決まりだ）。
つまり、世界はそれでも進歩はしている。牡蠣の食中毒の原因がウイルスによるものだとわかったってことは進歩だ。Googleを利用できるようになったのはやはり進歩だ。今はだめだったり夢だったりしても10年後には実現してるかも知れない。それに力を貸せるかも知れない。そんなことだ。
いや、あれは本当にひどい仕組みだった。名前もひどいもんだが。pThis。しかし無ければ困るし、他に手段を考えると、thisをコンストラクタに与えてそれを利用させるくらいしか考えつかない。多重継承を利用するATLと異なって、MFCではCOM用のクラスは内部クラスとして実装することになる（マクロを利用しているため気付かない人は永遠に気付かなくて済むハッピーな仕様）。ところが、このクラスのインスタンスはCOMのコンポーネントとしてはともかく、MFC上は母艦と連絡を取る必要がある。というわけで利用するのがpThis。
Mister Heartbreak
class Outer {
int m_refCount; // 参照カウンター
class Nested {
Outer* pThis;
Nested() { pThis = ((Outer*)(LPBYTE)this - offsetof(Outer, nested)); }
...
UINT Release()
{ // こんな感じかな。
UINT u = --pThis->m_refCount;
if (u == 0)
{
delete pThis;
}
return u;
}
...
} nested;
...
}
// まじめに書いてみると、まともな仕組みで、ポータビリティもありそうだな。
// というか、MAC兼用のはずだからポータビリティはあるのか。
Javaのインナークラスを見て、やっと子機というか着陸船（母船と紐付き）というかが言語仕様に入ったんだなと思ったら、C#にはDelegateにこそthisが入るけど、内部クラスは単に名前空間だけが提供されるだけのJavaのstatic nested class相当だったんで相当がっかりした。
ちなみに、ATLではpThisは不要なかわりに、今さわっているthisはどの基底クラスでのthisなんだ？ 問題というのが結構出てきてどこかへ吹っ飛ばしてしまったり、それはそれで厄介であった。
「バルバロイ！」それは歴史の闇に葬り去られた者たちの反攻の叫び。
はらさんのツッコミが無闇におもしろかったので、ちょっと検索してみたら見つけたサイト。
蝉がキリギリスになぜ変わったかとかいろいろおもしろそうだ(し、読んでみた範囲ではおもしろかった)が、残念なことに眺めた限りではアリストテレスについては異聞集が抄録されているだけみたい。
#Firefoxを利用しているので、次々と興味深そうなリンクはopne link in new tabしていくのであるが（で、スタックされる）、その一方で読みながら次々とタブを閉じていく（次のタブがポップ）わけで、何事かとびっくりしただよ。（というわけで、時々viaや経由が無い−−リンク先のリンク先のような場合−−ものがある。これもそう）
とは言え、本当に刺激を受けたのはセリーヌとボリスヴィアンとかだから、そういうのはおいておいて、それなりに役に立ちそうなものから。
考える技術・書く技術 (講談社現代新書 327)(板坂 元)
これは、高校の作文の教科書だった。で、授業はろくに聞かなかったけどこの本は読みに読んだ。とにかく繰り返し読んだので、高速道路でパンクをしたときに回避方法をかって読んだポルノの1シーンから思い出して事なきを得たというようなどうでも良いエピソードまで覚えている。
というか、刺激は受けてないかも。
というわけで、それは取り消して、あらためて5冊。
言わずと知れたレビーのハッカーズには刺激を受けたなんてものじゃない。ところで、ここには3世代のハッカーが出てくるわけだが、
・LISPハッカー
・Homebrewハッカー
・ゲームプログラミングハッカー
僕は最初のやつが1番好きなんだが、やはり、2番目サイコーとか、3番目ですよ、とかいろいろな人がいるんだろうな。
テレビゲーム―電視遊戯大全(テレビゲーム・ミュージアム・プロジェクト)
UPUのテレビゲーム。これ、すごい本だ。どのくらい刺激を受けたかというと、テレビゲームをする必要がなくなるくらい刺激を受けた。
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI(W.リチャード スティーヴンス)
ちなみに、手元にあるのは1991年に刊行された原書のソフトカバーと、第2版の翻訳版の2種類。特に最初のやつはいろいろ読んだし、試しにいろいろ実装した。ネットワークプログラミングをCでsocket叩くのなら、いずれにしても読むべき本だろう。
socket（というよりネットワーク）は、びっくりすくらいディスクやメモリーとは異なる。TFTPの行き違いの説明とか本当におもしろい。
ソフトウェア考現学―基礎概念への最新おもしろガイド (Fine soft series)(萩谷 昌己)
すでに何回か貼っているが、ソフトウェア考現学も読んで刺激を受けたな。これを読んだおかげで触ったことも無いAPLが変態で、PL/Iの図体がでかくて、FORTRANとBASICと4人合わせて大阪人だということを知ることができたくらいだ。とういか、この本が書かれた時でも人月の神話が出てきていたりするのだが。
先にプログラマは奴隷ではないといったが、じつをいえば、プログラマを奴隷化するための学問、それが、ソフトウェア工学なのだ。
――P.178
ということだ。語り口の軽さといい、内容の適当さといい、実に名著。
Common LISP―Common LISP言語仕様書(Guy L.,Jr. Steele)
これは熟読した。言語仕様書というのを隅々まで読んだという点ではこれが最初の本だ。仕様書というものがどういうものか、これを読んで相当わかったような気になったし、言語というものをどう詰めていくのかとか関数とはどう定義するのかとか、実にいろいろ教えられたように思う。にもかかわらず、全然LISPでコードは書けない。読み方がLISPを使う方向から読んだからではないからだ。
追記：別にCLtLを読むことを勧めてるんじゃなくて、あくまでも僕が刺激を受けたということ。それはそれとして、C#でもJavaでもVB.NETでも良いから（このあたりは仕様がオンラインで読める）やはり言語仕様というのは読んだ方が良いとは思う。
こんなとこかな。
行政主催の痴呆シンポジウムなどに出ると、メインの講師がその手のデタラメを教えていたりすることはしょっちゅうで、普通に臨床に関わっていれば、こんなアホなことはいえないのになぁと、天を仰ぐこともしばしばである。ま、この手の人は自分がデタラメをやっているという自覚を得るほどの関わりをすることはないので、非当事者にはそれなりに響く、建て前だけのきれい事をいっていてもそれに気付くことは永遠にないのだけれど。
−−老人介護を楽になる方法から引用
これは、本当に不思議なことだ。痴呆の臨床例についてはわからないけど、相対的に同じ構造（何も知らないやつが何か意味ありげなことを言うと、本来知っているはずの人間がひれ伏してしまうという構造）を見ることがあるからだ。
ひとつの理由として、「言葉」の魔術、つまり「名前をつけること」があるかも知れない。人は、それを良く知っていても名前を知らない（というよりも、名前をつけるという知恵がはたらかない）と、自分が知っていることに対して根拠無く不確実さを感じてしまうのかも知れない。そこに口舌の徒が鳴り物入りで登場、ジャージャーーン。すると、魔法のように、その良く知っている物に名前があることがわかる。ガーン。しかし、どうも自分が良く知っているものとは全然違うように思うし、間違っているような気がするし、変じゃないかとは思うが、もう遅い。魔法にかかってしまっているのだ。何しろ、向こうは名前を知っている！
つまり、かまわんから自分でそれに名前を付ければ良い。後から同じものについてよりメジャーな名前があることを知ったら、その時点で付け替えれば良いだけだ。a = A.newとやって、b = a、とやるとaからbに変わったように表面上は見えるけど最初にA.newしたインスタンスには代わりは無い。
名前をつけるのは確か、これだったと思うが、記憶違いかも。
AOPで、関心毎を入れる場所のことをJoin Pointとする派とJoint Pointとする派の2種類があるのか、それとも両者は別概念なのか、それとも本当はJoin Pointなんだけどプログラムで利用するためにJoinpointとしたのを誰かそれなりに影響力がある人が読み間違えてJointpointとしてしまったのか、いったい何が正しいのかな。
教えてえらい人。
追記(9/30)：AOP AllianceのJavadocには
joinpoint(in the AOP terminology)という表記がある。
このあたりから、Join Pointが正しい用語と言えると考えることにする（太田@mixiさん、星さん、tsuneさん、ありがとうございます）―なおカタカナでは、ジョインポイントと表記すべきだと思う。
昨日のツッコミにテレビゲームが復刊されても意味あるかなとか書いていて、以前、お宝探偵団で見たエピソードを思い出した。
依頼人は、20年くらい前のかな、どうも名機という言葉がふさわしいらしきワープロだかハンドヘルドコンピュータだかを持ってきた。
ついた値段が-500円。
鑑定人曰く、「工業製品の古いのは産業廃棄物ですから引き取り賃をいただきます」
MacPaintのソースコードは美術館に入ることになったようだが、さて、ソースコードのお宝度というものをちょっと考えてみたり。
たとえば、テレビゲームのどれか、優れた作品がいつかの将来のソフトウェア美術館に入ることになるとして、それは
・グラフィックが評価
・音楽が評価
・ゲームバランスが評価
・敵機の動きが評価
・ギミックが評価
とかになるのかな？ それともソースコードが評価されるのか？
映画と同じようなものかも。多くの人たちは、映画ではなく物語や俳優の魅力あるいは音楽を評価する。だから、ジョンフォードの西部劇とか舛田利雄の石原裕次郎ものとかは、ビクターヤングやジョンウェインや石原裕次郎によって評価されている。黄金の馬車がどんなに魅力的でも、感動的な大物語がある大いなる幻影のほうが有名だ。
でも、その理由はわかる。評価するには、評価方法を知っている必要があり、その規準は普通はわからないからだ。嘘だと思ったらとてもチャーミングなコードを書いて街で100人に見せてみよう。それがチャーミングだと正しく評価できる人は間違いなくゼロだろう。
次の時代というのは来るし、来なければならないわけで。
モーツァルトの時代のぎりぎりお尻の頃、やっとベートーヴェンで完成したわけだが、どこかの誰かが礼拝用の音楽を作ったり晩飯用の音楽を作ったり（ディベルティメントはBGMだよ）、演劇に音と唄がついていたり（魔笛とか）という7氏による産業用のものだったものが（でも楽譜が残っていて良かったね）、ベートーヴェンというすごいおっさんが必至に作ったすげぇ（というように固有名詞が全面に出てくる）音楽と本物の産業用の音楽とに分化する（サリバンとかシュトラウスとかは微妙な位置だ）。1970年代くらいに歌謡曲という唄を歌う人だけが見える音楽と、アーティストと呼ばれる自作自演の人の音楽に、大衆音楽が2分化されたり。
ソフトウェア工学は前者の産業用のものを生み出す。基本は自動化になるし、そうじゃなきゃならない。歴史はがらりとは変わらずに同じことを繰り返す。というか、それが産業だ。奴隷が手作業で100人でやっていたものが、3人＋機械でどばどばできるようになる。その一方で、後者も生まれるはずだ。そこで生まれなきゃ、それは本当に単なる産業用の製品に過ぎないジャンルだったということだ。
というわけで、とりあえず後者のプログラムを作る人がいてもいいなぁ、と思ってみたり。読んだ人が感動のあまり3日はプログラムがかけなくなるような素晴らしいコードのハーモニー。どうして、こういう発想ができるんだ、と誰もが息をのむ例外処理、しかも高速、コンパクト、でも水晶よりも明晰でまったく無駄がない、でも遊び心にあふれていてしかも優雅。
#でも、VB6で書いてあったり。
とか、そういうプログラムを見てみたい。
福盛さんがMacPaintのソースの探索を開始する（それはなぜか）と、そこにはさらに思わぬ人物が登場するのであった（それは誰か）。
へい、日本には、RHGという「コード読解」の本は少なくてもあるぜ。
ServerSocketを利用した簡易HTTPサーバーの自作。
なんか、つい最近話題になったやつを彷彿とさせるが。
とりあえず自由にいじれるプラットフォームを用意しておけば、後はいくらでもネタがふれるだろうということで。
ちなみに、今回から完全にNetBeansの利用を意識することにした（以前もNetBeansですんなりインポートできることは確認していたが）。
#追記：ガーン。なんで気付かなかったか、2ヶ所いやんなものを見つけてしまった。-1のチェックと、bi.closeの重複。後で修正だけどソースも直さなきゃならないな。
更に追記：ソースアーカイブのアップロードができない……。記事とソースが異なって、ソースのほうが良くないというのはまずいので、週明けに修正予定。
ジェズイットを見習え |
鬼追うもの (プチフラワーコミックス)(佐藤 史生)
Before...
_ えむ [自転車に乗ってるときは同意。 自動車を運転してるときは逆にかたくなに車線外側を維持する自転車が鬱陶しい時があります。..]
_ arton [僕は、自転車に乗ってる場合は上に書いたとおりだけど車の場合は無灯火が気になる。大体、後ろには反射板が付いているから、..]
_ rucila [わたしは車道走り(意識は自動車)なので逆走はさほど気になりませんが無灯火は腹立たしいです。あと工事現場の交通整理が無..]