日々の破片
| 著作一覧 |
2007-06-01
_ キュア
（誰かがアフィリエイト経由で買ったCD）
グレイテスト・ヒッツ(ザ・キュアー)これジャケットがいい。っていうか、一見キュアじゃないけど（星のせいだ。星といえばABCとかファーズとか、はやったわけだが、キュアはそういうデザインはしなかった）、良く見るとキュアだし（手の形とか）。
どうしても、ぼくらは檻の中のトラみたく動くラブキャットが好きなのだが、ジャスト・ライク・ヘヴンも好き。
ボーイズドントクライという名前からは、なぜかダムドドントクライのメロディーとストレンジの声を思い出してしまうわけだが。
（iTunesのおかげで、アルバムをそろえているとベスト盤って買う必要がないのだが、ジャケ買いってのはあるな、と思った）
2007-06-02
_ 買ったCD
突然、復活したデキシーズの昔のらしきライブを購入。
まだ届かないけど。
Projected Passion Revue(Dexys Midnight Runners)
One of the Most Singular Bands of all Timeっていうような表現はときどき見かけるが、そんなものかも知れない（うまい日本語にはできないが、時代を超えたすげぇバンドの1つ、って感じにすると日本語っぽいかな。いつの時代であっても＝時代を超えたという感じで）。
あと、良心的なというかまともな価格の中古が出てたので、ソロ1作目（まったく売れなかったらしい）も購入。
The Wanderer(-)それにつけても、最近は、やたらこればっかり聴いている、これまた売れなかったというよりも、買われることを断固として拒否しているとしか思えないジャケットのソロ第2作が、また、中古で出てるな。
マイ・ビューティー(ケヴィン・ローランド)この気持ちの悪いジャケットを我慢して楽曲を手に入れれば、至福の時が待ってるってわけだ。っていうか、聴いているとシナトラとかビングクロスビーとかみたいな気もしてきたりもするが、でもそこはケヴィンローランド。
#some sources quote a figure of fewer than 500 copies sold.いや、確かにこのジャケットならわからなくも無いが、仮にも日本盤も出てるのだが……（全世界で500枚なのか？ UKのみの数字なのかなぁ。というか、良く買ったよな、っておれもだけど）
_ おれのヲレ用語
以下、すべて「さ変」名詞。
開発：もっとも広い範囲。
プログラミング：全般。実装設計からテストまで。
コーディング：とにかくコードを打ち込む時。コードを書くことそのもの。
ハック：バータリーに片付けるコードを書く場合と、仕様に明記されていないあれこれを調べながらそのシステムで使えるものを作るとき。
という感じかな。というわけで、コーディングは使う。
上のような使い分けなので、開発者とプログラマは名乗るけど、範囲が狭すぎるコーダやハッカは名乗らない。JIS用語風に、ハッカとお尻のーを取ると、すごくまぬけだ。パイプみたい（いまの縁日でも売ってたりするんだろうか）。
#っていうか、コードを書くんだから、コーディング以外にどう呼べと。「コードを書く」と言えば良いのかな。したがって、実装設計ができてるものを実装する場合には、「これ、コーディングよろしく」で全然OK。だって、コードを書くわけだから。でも、設計が無い状態で「これ、コーディングよろしく」って……そんな言いかたするやつはいないと思うが。
対象範囲を分けてることに気づいた。
開発：システム
プログラミング：プログラム、アプリケーション、モジュール、コンポーネント
コード：ソースファイル
ハック：パッチ、ちょろい修正、コピペによるでっちあげ、デバッガ使ったり、オンラインモニタ使いながらコードを書く場合。＝つまるところ、自分がゼロから作るんじゃない、他人（３日前の自分を含む）のコード、プログラム、正攻法から少し外れた方法で何かを付けたり変えたりするような場合のシステム、プログラム、モジュール、コンポーネント。
#結構、ひとによって違うもんだね。
_ 20年後＝1970年を予定とした東京
いつのまにか、全部そろっている（ありがとうございます）。すばらしい（ある時代に、使命感に燃えた専門家とそれに賛同した人々が、未来についてのヴィジョンを示す。その示したものを遥か＝50年未来から現実の歴史を省みながら、そうあるべきであったのか、それともかくあったべきなのか、岡目八目で見直すことができる、という機会を得られるということがすばらしい）。
5/21の日記参照。
_ その表彰、待った
世界ネットワーク機器標準機構(WNDSO)は、RJ-11 規格の制定に大きく貢献した Tume Orel氏を、20世紀におけるネットワーク機器最優秀設計者として表彰すると発表した。
おれは、生活者保護の観点（というか、単純に顧客保護というか、結局はこっちの作業負荷を減らしたいからだが）から、断固としてこの表彰は誤っていると主張したい。
技術的観点からみてもこの表彰理由には誤っている点がある。
コネクターが接続されている時には一切発生せず
とされているが、過度の張力をかけた場合、ほぼ確実にRJ-11による接合箇所でオーレル回路が発動する。確かに、オーレルの主張では、この保護回路によってケーブルそのものの切断や、機器を収納したラックの転倒を防止できることになっている。が、同様な問題に対してアップルが新しいMacBookなどで提供しているマグネットを利用した保護回路のほうが断然優れていることは明白だ。
しかもマグネット方式のほうが、よりコストを上げることに貢献する。
2007-06-03
_ RubyKaigiの準備
えーと、状況がこれだけ変わるとは思わなかったわけで。本当に動きが早くて樂しいことだが、それはそれこれはこれ。
鉄分だよ。鉄分をどう補給するかが問題なわけで。
あっさり無視しても良いのだが、それは不誠実だろうしなぁ。
_ 安い
THE BEST 1000 ジョー・ジャクソン(ジョー・ジャクソン)
どんな曲が収録されてるかはわからないけど、知らなきゃ買っても損はしなそうだなぁ。
ジョージャクソンと言えば、最近、なぜかOne More Timeを良く聴いてたりするんだが。
Look Sharp(Jackson, Joe)One More Timeは名曲だが、それ以上に、このジャケットの白いとんがり靴と光線と白黒こそが、時代感そのもの。（ルックシャープのあまりのかっこよさに対して、セカンドのジャケットに出てきたひげのぶおとこっぷりにはたまげたものだ）
Beat Crazy (Reis)(Jackson, Joe)
これは当時聴きそびれたのだが（ジョージャクソンにはいやな思い出がつきまとってるのだが最近、解放されつつある）、どんなんだっけな？ （カリプソとかに移行したのかな）
_ シンクライアント
ちょっと手が空いたので、いただいたCOMPUTERWORLDの最新号を読む。
月刊 COMPUTERWORLD (コンピュータワールド) 2007年 07月号 [雑誌](-)
特集のストレージはへー、今やそういう時代なんですねぇという興味はわくし、読んでておもしろいがそれはそれ。
個人的な感情論だけど、せっかく用意されているUSBポートを潰すとかってのは、ちょっと許しがたい気がする。
で、シンクライアントですよ。隔離したサーバーのパーティション上でクライアントアプリケーション動かすわけだし。
というようなシンクライアントは理解できるのだが（ターミナルサーバーとかシトリクスとか）、特別企画では、シンクライアントのオルターネイティブがアプリケーション仮想化ということになっている。なんのことだ？ と読み始める。
OSの上に仮想レイヤを乗っけて（その上にゲストOSが来れば仮想OSだがそうではなく）アプリケーションを乗せる。やはりシンクライアントなのだが。
で、読んでいくとなんか微妙な技術で、クライアントPCに仮想化したアプリケーションイメージを転送するからインストール不要でクライアント環境を汚染しないというようなことが書いてある。理屈はわかる。サーバー上で起動したプロセス空間をファイルとしてクライアントへ送り込むということだろう。にしてはオフラインでも使えると書いてあるがそれは変だな。おそらく、シンクライアントみたいにまったくただの箱になってしまうのではなく、あらかじめ用意されているものは利用できるという意味だろう。
業務システムアプリケーションとかなら使える技術みたいだなぁ、とか考えながら先を読むと、SoftGridという製品名が具体的に出てくる。
インターネットでのアプリケーション配布形態をSilverlightに集中して、企業ソリューションとしてSoftGridにすれば、スマートクライアント（JWSとかも）だのは不要化できるというシナリオなのかな。
ささっと読んだだけなのであやしい理解だが、プロセス空間を移動可能なようにシリアライズして用意しておき、オンデマンドで配信するってのは、技術的にはおもしろそうなネタだなぁとは思う。もっと、軽量で楽しい使い方はないだろうかな？
2007-06-04
_ 恐怖と想像力
淑やかな悪夢 (創元推理文庫)(シンシア・アスキス他)なんとなく買った（たんぽぽ娘が無いか見に行った時、手ぶらで帰るのもつまらんので）のだが、とりあえず、帯で激賞してた黄色い壁紙だけ読んだ。で、まあ、考える。
（ここはひろいいんたーねっとなので、「黄色い壁紙（Ghostbuster氏の訳）」というのも見つかる。むしろこっちの訳のほうがきれいかも）
雪に閉ざされた山荘のジャックと同じ世界に入ったって読むのが一番の王道なんだろうか？ でも、その読み方では少しも恐怖は無い。というのは、その組み合わせだと語り手自身がジャックだからだ。ジャックが怖いのは、ジャックの行動が変わっていくからだ。
いや、無理やり逆読みをしても良い。正気なのは語り手で、夫と夫の妹（ジェニー）が少しずつジャック化していくというように。にしても、やはり恐怖はない。というか、さすがにそれには無理がある。
よくあるホラー映画であれば、最後、夫が妻の向こう、壁紙が剝された壁に見たものは……ということに落ち着かせてもよい。これはそれなりに怖い。ところで、それは女？ それとも多数の子供？ （いや、これは怖い。ホラー映画のパターンとしてよく使われるわけだ）
因習の恐怖という読み方はあたり前にできるが、それはあまりおもしろくない。
そこで、最初に没にした編集者の言葉、「わたしのこんなにミゼラブルな気持ちを読者に味あわせたくない」を考えてみる。この編集者はこの作品を読んで、不快になったのだということ。恐怖を味わったのではなく。そうすると。まともな読み筋だと、まさに女性からの誤った男性による抑圧の告発として受け取ったのが理由ということになる。
いや、そうではなく、何がこの物語かまったく理解できない、でも何か大切なもの＝真実が書かれている、 でもそれが何か言語化できない＝わたしはばかですな気分＝ミゼラブル＝掲載できないね、という意味ともとれる。それはそれでありだろうな。
窓は釘付けで格子入り。ベッドは移動できないように釘付け。忘れてはいけないのは、壁に吊り輪。魔女を閉じ込めとく部屋だな、と読むこともできる。
床のささくれと引っ掻き傷、壁のこすれた痕。木馬に乗って部屋を一周、二周、三周……というシナリオもあり得る。体の弱い男の子だ。窓から外を眺める。日の光がまぶしい。再び部屋の中に戻り木馬にまたがる。一周、二周、三周……。
黄色と言えば、ガストンルルーの黄色い部屋ってのがあり、あれも女性が部屋の中で追い詰められる話だったな。黄色というのはそういう色なんだろうか？ ムルソーが道玄坂の上でカレーを食べる。卵カレーには輪切りの卵。中心に黄身の黄色が浮かぶ。
あるいは、壁紙と協調できるようになると同時にそれまでの書き方からジョンとジェニーに対する書き方が変わるという点から読解することも可能だ（このときを境に「夫」という単語が消えてすべて「ジョン」となる）。壁紙に同化することで、家庭から開放されたと読める。したがって、それ以降、よそよそしいのはジョンとジェニーであり、逆に主人公は同じ側の住人と共同生活を始める。これも正当な読み方だ。なぜ、共同生活を始めることができるのか。それは同じことが繰り返されているからだ。同じ不動産物件を購入できる層は同じような階級だ。ならば、家の中で家族は変わっても同じことが繰り返される道理である。
それにしても、年を取るということは、恐怖に鈍感になることかも知れない。死が少しずつ身近なものになるからだろう。
でも別の考え方もある。ジークフリートが恐れを知らないのは死を知らないからではない。大切なものを持たないから死がどうでも良いことだからだ。そのため、ブリュンヒルデに一目ぼれした瞬間から恐怖を知る。
#だがね、ジェニーのことも気にかけてやってくれ。
_ これはいいな
「らしい」とか煽りっぽい書き方（おれには真似できないから、やっかんでるだけかも）ではあるけど、@ITの読者が対象だと考えると抜群に良い記事。
局所化すべきものを言語の機能を利用して局所化するのに、匿名メソッドが利用できるという提示の仕方。そのコードはどこに（ここではメソッド）に所属するのかという視点。（どうも、おれには前者＝局所化より、後者＝所属の概念のほうがしっくり来る）
まあ、例題が特にDRYではない（ifのサンドウィッチ）例だというのがあるけど、そのDRYじゃなさに鈍い人がいるのは事実だし。
2007-06-05
_ TableAdapter
TableAdapterって、ADO.NETじゃないのか……（System.Dataネームスペースじゃないし）
でも下層には、SqlDataAdapterがいるから、ADO.NETっていっても間違いじゃないよね？ と、誰とも無く同意を求めてみたり。
_ なんで？
もしかして、「アノニマスメソッド」と呼べ、という意味だったりするわけはないだろうから、文字通り、使うな方面の意味なんだろうけど（追記：ではなく、無名メソッドじゃなきゃおかしいだろう、ということでした。うむ、それはそうですね。でも待てよ、と書いた先からシステム付与のとんでもない本名を匿名化したもの、と解釈してみるとか。と考えてみると、delegateというキーワードを匿名に利用している、つまり「〜というメソッドを提供するdelegateさん（仮名）」という感じなのではないかな、と。実際問題として関数名としてdelegateと書いているわけだし）。
#もちろん、まずい使い方はいくらでも考え付くけど、悪用は善用に転化できるけど、使われなければそれまでだ。
例）カプセル化
class Foo {
int counterValue;
public int Counter {
get { return counterValue; }
}
public void bar() {
Baz baz = new Baz();
baz.doSomethingWithFoo(this);
}
}
class Baz {
public void doSomethingWithFoo(Foo foo) {
...
if (foo.Counter == 0) {
...
}
...
}
}
に対して
と、ここまで書いて、この例だと何も匿名メソッドを使うまでも無く、次の書き方で良いことに気づいたので、この例はやめた。
class Foo {
int counterValue;
public bool IsFirstVisit {
get { return counterValue == 0; }
}
public void bar() {
Baz baz = new Baz();
baz.doSomethingWithFoo(this);
}
}
class Baz {
public void doSomethingWithFoo(Foo foo) {
...
if (foo.IsFirstVist) {
...
}
...
}
}
で、別の例を考え付くまで、一回休み（というか、普通にイベントハンドラを書けば良いのだが）。
#おれはTell Don't Ask原理主義者だから、Tellのネタを与える方向は常にOK
とりあえず最初の一歩としては、外部へは常に振る舞いのみを与えて、属性は（プロパティのような仮想化されたものですら、属性そのものとしては）見せないってこと。
でも、さらに考えると、Fooのインスタンスに対しての最初の呼び出しであれば、何をするか、というのはFooの所有ではないかとか、と思ったけど上の例は、Fooに連動して動作するBazなので、クリーンなFooを与えられたときのBaz自身の動作がifのブロックの中に入るのでこれで良い。次のように書くのはさすがにやり過ぎだろう。
class Foo {
int counterValue;
public bool InitializeBaz(Baz baz) {
if (counterValue == 0) {
baz.Initialize();
}
}
public void bar() {
Baz baz = new Baz();
baz.doSomethingWithFoo(this);
}
}
class Baz {
public void doSomethingWithFoo(Foo foo) {
...
foo.InitializeBaz(this);
...
}
public void Initialize() {
...
}
}
でも待てよ。こっちのほうがチャーミングだな。こっちのほうが良さそうだ。（条件判断がメソッド全体を覆うものに変形できているというのが、チャーミングな理由）
追記：っていうか、アトミシティ原則（っていう名前じゃなかったかも。ステートの問い合わせを処理と分離するな）からもこっちが良いというか、場合によってはこっちでなければならない。
_ fact
「保守不能なコードを書く大原則とは 可能な限り多くの場所において可能な限り多くの方法で 事実を明確にすることである」
DRYの反対。そこら中で繰り返せ（しかも複数の方法/アスペクトで）、ってことでは。
2007-06-06
_ Visual Studio Team Edition for Developers
勤め先で、C#でちょっと癖があるクラスライブラリを作る必要が出てきたので、さすがに、NUnitを入れることにして、入れて、さてテストプログラムを作るにはどうしたら良いのか？ とプロジェクト作成ダイアログを見ると、さっそくテストプロジェクトというのがある。
ほー、ちゃんとVisual Studioに組み込まれるのか、と実は疑問も感じながらそれをソリューションに追加して、でも、やはり疑問に感じるわけで（そういうインストールではないように思えたからだが）、参照しているところをみると、Microsoft.VisualStudio.……みたいなネームスペースだ。ってことは、これはNUnitじゃない。
で、MSDN見てみると、同じソリューションのクラスのコンテキストメニューにテストのスタブ生成が組み込まれているとか書いてあるので、なるほど、と作って、Assertクラスが勝手にいるし、インテリセンスを見るとIsTrueだのIsNullだのが出てくるから、普通にテストプログラムを作り、テストプロジェクトのほうをスタートアッププロジェクトにして、ほーこれは便利ですな、という具合にプログラム作りまくり。クラスライブラリ作るには、やっぱりユニットテストツールは欠かせませんな。
ただ、アサート結果のスタックトレースをダブルクリックしてもそのソースコードが表示されないのは、いまはちぐらいだけど。
で、こんな良いものが組み込まれてるのに、なんで今まで気付かなかったんだ？ と疑問に思いながら、家のVisual Studioを起動すると、そんなプロジェクトはどこにもない。なぜだ？
で、家にあるのは、同じTeam Systemでもfor Architectsで、勤め先のはfor Developersだからだ、ということに気づく。
でも、それはおかしいだろう。宇宙飛行士だけがそのロールじゃない。っていうか、プログラムも作ることを想定しているからVC#だのVBだのも分散デザイナのほかに組み込まれてるわけだろう。で、プログラムを作るってことは、当然（昨年はバータリーに作ってたから、まあ、ほとんどの場合と譲歩するとしても）テストプログラムも作るってことだ。
というわけで、この点に関しては欠陥商品と呼んでも良い気がする/した。
for Developersの差別化ができないってことになるのかな？ でも、デバッガ系もやたらとfor Developersは充実しているようだから、それで十分じゃないかな。
というわけで、すべてのVisual StudioにMicrosoft.VisualStudio.TestTools.UnitTesting（参照の追加の.NETには無いようだ。アセンブリはどっかに入ってるのかも知れないけど） とテストプロジェクト（なきゃ不便極まりない）の搭載を希望。
2007-06-07
_ 「配布」で引っかかった
さてできたアプリケーションをどうしてくれようか、と考えた末、「配布」を選んだ。
その結果、最初は、ディレクトリ名が長すぎるエラーになって配布パッケージが作れない（Manifestが引っかかり、最後のはApp.Configが引っかかり、結局解消できないので、面倒になってあきらめた）。というか、単にプロジェクト名を、xxx.yyyyyyyy.zzzzzzzzzzzzz.ProjectName としただけで、引っかかるものなのだろうか？ ここで、xxxは会社名、yyyyはプロダクト名、zzzzzはドメイン名で、ごくごくありきたりのネームスペース名だと思うのだが。もしかして、ネームスペースって使われてないのか？ （というか、MSは使ってるけど）
で、ネームスペースを変えるのはルールの問題であり得ない選択だから、プロジェクト名を変えたり（一度、ソースに組み込まれたネームスペース名は後からプロジェクト名を変えても消えない）、いろいろ試したがどうにもならなかった。
で、それだけならばまだ良いが。
こんだ、テストプロジェクトがまったくビルドできなくなってしまった。どうしてこんなのばかりなんだかなぁ。
で、検索するとMicrosoft.Windows.CommonLanguageRuntime、それなりに同じところで引っかかってる人がいて。
よくみたらKazzzさんも引っかかってた。読んだときは全くピンと来なかったが、これのことだったのか。
それにしても、テストプロジェクトは自動生成だから、ある意味かってにプロジェクトを参照するわけなので始末が悪い。かといって、テストプログラムを異なるソリューションに置くというのは考えられないし（というか、プロジェクトを分けるのも、あまりやりたかないわけだが、ビルドルールが面倒なことになるし、せっかく1ソリューション複数プロジェクトという管理方法ができるんだから、それはそれでOK）、この参照設定の付け直しって付いて回るのかも知れない（と一瞬思ったけど、ネームスペースと配布ウィザードの失敗の関係を追い詰めるまでは、2度と「配布」はクリックしないから、もう起きないかも知れないのか）。
ヒューマン・メナジュリー(スティーヴ・ハーレイ&コックニー・レベル)_ ホワットユーウォント
（カタカナだと変だな）
ボディ・アンド・ソウル(ジョー・ジャクソン)iPodから突然、ブラスが鳴ってつんのめるようなビートが刻まれて、そして軽いようなにやついてるようなでもなんとなく真剣さも感じる声が歌を歌いだす。ジョージャクソンはモダーンだ。
これは、実に名曲だなぁと、何度も聞き返す。何が欲しいかわかってるのかい？
たぶん、これだ。
This Is What You Want...This Is What You Get(Public Image Ltd.)
（ということはない）
_ Ruby.NET
VS2005で参照設定をしてやると、
require 'mscorlib.dll'
require 'system.Windows.Forms.dll'
System::Windows::Forms::MessageBox.Show('hello')
は動いた。
require 'mscorlib.dll'
require 'system.Windows.Forms.dll'
System::Windows::Forms::MessageBox.Show('hello')
a = "System::Windows::Forms::MessageBox.Show('hello')"
instance_eval a
も動いた。しかし、なんでVS2005がいるのだろうか？ （コンパイル時の参照の解決というのはあるにしろ、ってのも、インテリセンスが実行されない）
2007-06-09
_ RubyKaigi
いよいよ当日。
_ Ruby.NET
仕様的な考慮点。
if $0 == __FILEイディオムがきかない。
うーん、と考えてもしょうがないので、みてみたら$0がnilになってる。なぜ？ ああ、そうか。ruby $0-named-file だが、exeが作られるから、$0相当のファイルが存在しないからだ。ってことは、CのARGV[0]と同じように$0を自分自身にしてやらなければならないってことだな。
でもバグ報告ってほどでもないので、OSSモデルへ移行してからにしようかな。
#結局、Google groupに送った。
_ VS2005ここがだめ
多言語を前提としたIDEを作るなら、インデントやスタイルは、言語ごとに設定できなきゃ嘘だろう。っていうか、Rubyで4インデントは深過ぎ（でも、C#が2インデントでは耐えがたい）。
#う、誤爆だった。見る場所が違った。
2007-06-11
_ 追加
で、Daveは残念だったけど、ほかの発表はどうかと言えば、
・インフォテリア epoll（無理やりWin32APIにマップすると、IO完了ポート）
・にゃすさん
・高井さん（きっと、くねくねしたプレゼンだったんじゃないかと思うが、そのくねくねを見たかった）
・メトローさん 前夜祭のときデモ見せてもらうのスキップしたのだが（初日だと思ってた）、見損なってしまうことになるとは。残念
は、特にこれまでの経緯（と特別な興味）もあって見たかったなぁ。
あと、かくたにさんのカヤック星人シャツ（カヤックの表紙→誤読（空目）による宇宙人化（＋Dukeの体型）→はてなセリフ化→シャツのプリント（今ここ）→動画化（カヤック星人がコーヒールンバに合わせてRubyダンスを踊ったりブーンをしたりしているうちに、背中のチャックが開いて中の白とか黒とか赤い鼻とかが見え隠れしてぶいmぶいm言わせる――JRubyの広告だな））
2007-06-12
_ ASR(p36版)の予定
今週末くらいに出します、多分。
_ 個人的にRubyKaigi2007で一番、おお！ と思ったセッションについて
かって、
嫌いなところは Syntax Error で、end の抜けで、ファイルの最後まで行っちゃうときな。あれはたまんないよな。
（「言っちゃう」になってる……orz）
と喋った人間としてみれば、2次元の存在とは言え、山野 ゆき菜さんのLTに一番、感銘を受けたよ。
あの場にいた人間は誰も（もちろん僕も含めて）、需要も解決方法もわかっているのに何もしなかったのに、彼女はやっちゃったんだからね。
（多分、このパッチはありがたくp36版ASRに入れ込むつもりです）
なんかぽろぽろ書いているけど、このセクションをtbしよう。
_ すげぇな
ある意味、各種ブラウザーをサポートするのが仕事とは言え、もうSafari for Windowsを日本語化させて試してる。
_ カヤック星人のライセンス
かくたにさんに聞かれたが（というか、そもそもJavaからRubyへの表紙の2次創作物なわけなのだが擬人化した時点でなんらかの創作性が加わったとみなしてよいものなのかなぁ？）、
・営利目的でもなんでも使ってOK
・改変自由
・オリジナル著作権表示不要
と思ったら、3番目の条件のために、クリエイティブコモンズには適合するライセンスがないように見える（わかってないだけかも）。結局、おれが望むライセンスってのはpublic domainだ、と書いてあることになる。でも、日本じゃpublic domainっていう状態が存在しないんじゃなかったっけ？ それに、Cマークがあろうがなかろうが、著作権って付いて回る仕組みだったはずだ。っていうか、もともと画像上にクレジットが存在してないわけだから、気にするまでもないのかも。
というわけで、カヤック星人の画像については、CCのby 2.1（利用許諾条項）を適用します（元々の画像にクレジットがないので、表示すべきクレジットは無いということになります（としてよいのか良くわからないけど、いらないものはいらない））。
2007-06-14
_ 工場はピタゴラスィッチ
こないだテレビ見てたら、ガリガリ君を作る工場とか、ラムネ菓子作る工場とかやってたんだが、ころころ転がって、紙に包まれて、向き変えて、折り曲げられて、風に吹かれて口が開いて、棒が差し込まれて、……、と進むのがえらくおもしろかった。
ああいうマシンの設計ってカラクリみたいでおもしろそうだな（それにつけてもおそるべき生産性だ）。
（ジグソーパズルは最後のところ見た瞬間に、だめだこりゃと思ったが、他に方法はないんだろうか（あればとっくにやってるか）？ あれは、絶対にミッシングピースが混ざるだろう）
2007-06-15
_ なぜ、diffのpオプションが重要なのか
diffには、-pというオプションがあって、これを指定すると変更された関数名が含まれる。
例）
/tmp$ diff -u test.c test2.c
--- test.c 2007-06-15 01:12:37.886290094 +0900
+++ test2.c 2007-06-15 01:17:49.292036097 +0900
@@ -4,6 +4,9 @@
for (i = 0; i < 100; i++) {
n *= i;
}
+ if (x) {
+ n ** x;
+ }
return n + x;
}
/tmp$ diff -pu test.c test2.c ← p付き
--- test.c 2007-06-15 01:12:37.886290094 +0900
+++ test2.c 2007-06-15 01:17:49.292036097 +0900
@@ -4,6 +4,9 @@ int foo(int x) { ← ここに注目！！！
for (i = 0; i < 100; i++) {
n *= i;
}
+ if (x) {
+ n ** x;
+ }
return n + x;
}
別にあってもなくても影響なさそうに思えるわけだが。
で、なぜ-pを付ける必要があるかについて、nokadaさんがRubyKaigi前夜祭で力説してたのを思い出したので、メモ。
だっておれらが見てるソースはcvsヘッドだから-pが無いと全然わからないんだよね。
というわけで、ruby-devにパッチを送るときは、-pを付けようという話でした。
_ いまさら動的/静的どっちが言語の例のやつ
水島さんのとこを読んでて（もちろん、元（なのか？）のrubycoさんのところからだいたい読んではいたわけだけど）、こないだのRubyKaigiのテーマともからんで、多分、アジャイルな考えも入れて、そのあたりで思いついたことを書いてみる。あまりまじめには書かない。
さて、プログラムを書く人は、だいたい誰でも知っていると思うし、それゆえにケントベックの変化抱擁があれだけ受け入れられたんだと思うのだが、なにはなくても「自信」というのは、目的遂行には欠かせないものだ。
（ここには挿入しないが、能力ある−能力ない×自信ある−自信ない の4象限で相手の状況を分析し、それにあわせて適切な目的遂行のためのガイドをすることをリーダーシップと呼び、技術的にはティーチング、カウンセリング、コンサルティングの3種類の方法論を適用するというメソッドがあるのだが、「自信」っていうのは、つまりは気の持ちようなわけだが、「能力」と同程度に重要だという点が取り込まれていることはやはり注目に値する）
で、実際にプログラムを書く人にとって、自信の裏づけとなるのは、テストだ（もちろん、地力ってのはあるにしても）。
でも、プロジェクトの完了は、プログラマだけで行われるわけではない。さまざまな調整や管理が必要なほど（少なくても大規模であればあるほど）、その他の利害関係者は多くなるものだ。
彼らも彼らの自信の裏づけが必要となる。
テスターの裏づけは、なんだろうか？ テスト要項書とチェックマークかな。ユーザーの裏づけは、要件仕様書に書かれた内容や、プロトタイプの動作や、受け入れテストとか。あるいは、単に口うるさく会議をこまめに開きまくるってのも、すべては自信のためだ。大船に乗って……ってのは、自信がベンダーに対する信頼だけで成り立つ場合のみで、利害関係者が多ければ、全員がそういう気持ちになることはあり得ない。
めんどうだから、これで終わりにするが、静的言語の選択というのは、つまるところ、実際にプログラムを書くわけでも、テストをするわけでもないプロジェクトメンバーにとっての、自信の裏打ちだ、ということだ。したがって、間違いなく、本気で、「なぜ静的言語を選んだのか本心を教えてよ」と聞けば、「プログラマーが楽に（早く、正確に、デバッグしやすく、大して学習しなくても済む、とかいろいろな理由から）コードを書けるようにするためだ。それにより、スムーズに次のフェーズに移行できるし……ひいては、プロジェクトの成功に結びつく」というような答えが返ってくるだろう。
人間系においては、「自信」というのは、砂上に築かざるを得ない。
検証できないからだ。
したがって、評判とか世間様とか、常識（なんのかは知らん）に従うことは、すごいアドバンテージとなる。道に外れていないというのは、自信に通じる（それはそうでしょ？）。
逆に、自信がないとプロジェクトの成功可能性は低くなる。自信がない状態でプログラミングしたプログラムには間違いなくバグがあるってのと同じことだ（自信があってもバグがあるのがなんともゆくゎいなところではあるけれど）。
したがって、規模が小さく、デベロッパーとマネージャとカスタマーの結合強度が強ければ、当然、信頼度も高いので、このデベロッパーが選択したテクノロジーなら間違いないだろう、というプロジェクトの人間系の自信となり得る。
しかし、規模が大きく、顔も見たこともない、もしかしたら海の向こうのデベロッパーの進捗まで考える必要があるような場合には、評判や世間様や常識や定石を外れてそうなテクノロジーの選択は、まったく自信とはならない。というか、不安となる。だめだね。こりゃ、失敗プロジェクトだ。
JavaからRubyへ ―マネージャのための実践移行ガイド(Bruce A. Tate)
こいつが、ビジネス書だっていうのは、そういうことだ。ビジネス書は、ビジネスマンの血肉となり、つまり自信となる。デバッグもテストもプロトタイピングもできない世界で自信を保つには、自分自身による実績の積み重ねと、実績の積み重ねをした他人の教えの学習が必要だ。
というのが、実態ではないか、と僕は考える。
というわけで、この「自信」については、ダックタイピングがどうこうというのは、まったく問題ではない。それでは意味が通じないから自信となるわけがない。
（デベロッパー一人一人の顔が見えれば、その顔色を見て、自信となったり、逆に不安となったりするだろうから、規模の問題というのは正しい）
したがって、たとえば、IBMでもNTTデータでも良いけど、世間様の規範となりうる大きな人たちがたとえばJavaScriptだけで第8次オンラインシステムを構築して、安くて（開発のみならず運用＝実行時も）速くて、しかもカスタマーからの感謝の言葉と、日経BPの賞賛記事が出まくれば、大規模開発＝JavaScriptという動的言語による開発、っていう選択がプロジェクト全体の大きな自信となる。
あるいは、東証の新しいシステムがHaskellで作られて日経BPに賞賛記事が書かれて、稼動後1年なんのトラブルもなく、富士通（じゃないかも知れないけど）が成功事例としてそこらじゅうで宣伝しまくれば、大規模開発＝関数言語というか成功したHaskellによる開発、ってのが規範となり、その選択をすることが大きな自信となる（おそらく、最初にそのプロジェクトをGOした人たちはイノベータとして社内外で高く評価されることになる）。
だから、20年後には、（今、動的言語で自信を付け始めた人たちがヘゲモニーを握っているので）大規模システムはRailsで作られるようになるわけだし、そのころの若い開発者（まだ生まれてなかったり3歳くらいだったりする）は、「げー、動的言語で開発かよー、だっせー」とか「なんで関数型言語みたいな信頼性が低い（ということに、その時代の先端パラダイムではなっている）のを使わなくちゃならんのだー」とかの怨嗟の声が巻き上がるようになる。
そして、そこで「大規模開発は動的言語と相場が決まっているようだけど、なんで？？？言語は向かないってされてるのでしょうか？」というような疑問が出てきたりするのだろうな。
#大規模開発＝プロジェクトチーム全体で顔が見えない開発、と考えるとだいたい概念的にはOKではなかろうか。データベースのサイズとかクライアント数とか、コードの総行数は関係ない。GNUプロジェクトは大規模だけど、大規模開発じゃない（ESRによると伽藍建築だそうだけど）。いや、顔が見えないじゃなくて、利害が複雑で、プロジェクト全体の目的が曖昧になりやすい、というか末端の開発者がプロジェクトの全体の目的をわかっていない（教えられていない）開発を大規模開発と呼ぶというのが正しいかも。
#技術的には、ダックタイピングがあるから大規模開発に向かないというのは考えにくいと思う。interface継承（実体が伴わないから、どのような実装をも許容してしまう）があるJavaで大規模開発が行われているし、performで呼び出す名前の衝突がありえるCOBOLでも行われているというのがその証左だと考える。
#なんか、オチの部分は意図せずに、こないだ読んだ羽生さんの『Railsが普及した次の世界を想定すると……』みたいになってしまった。こういう輪廻転生みたいなというか、万物流転なことを言い出すってのは、ようするにそういうのを見てきたってことでもあるから、羽生さんも年を取ったな、ということなんだろう。でも、思うに、羽生さんもおれも、まだ次の新しいやつがくるし、その後にも次の新しいやつがくる、って見越しているから、来るなら来い、どーん！ とそれを受け入れ可能（使う/使わない/気に入る/気に入らない/知る/無視するという選択肢があるのは当然）だってことなんですな。
2007-06-16
_ 興味深い
日本 Python ユーザ会イベントにマイクロソフト エバンジェリストが登場
来年のRubyKaigiのオフィシャルスポンサーにマイクロソフトが登場して、Silverlight＋IronRubyのテクニカルスポンサーセッションをしたりとかが見られたりするんだろうか？
で、ノベルもオフィシャルスポンサーになってて、Moonlight＋IronRuby（Monoの上で動けば）のテクニカルスポンサーセッションがあったり。
で、SunがJavaApplet＋JRubyのテクニカルスポンサーセッションをやってみせたり。
実際にそうなった状態を想像すると、あまりおもしろくなさそうな気がするわけだが、おもしろいかどうかだけじゃなくなるのが2008年なんだろうか（とか勝手に予想してみたり）。
でも、おもしろくないとつまらないからなぁ。
プログラムをおもしろくするのには、レースコンディションを導入すると良い。あれはおもしろい。どう解決するのが効率的か、とか。でぎりぎりを見分けるのが難しいのだが、思わぬところに穴があってNullPointerExceptionしてしまったり。
というわけで、順番に3セッションやるんじゃなくて、ついでだからAdobeのやつを含めて、東門、北門、西門、南門から、それぞれを代表するちからびとが入場してきて、ということは、後楽園ホールの地下を借りれば良いだろうな。マージャン卓みたいなところで、決められたお題をハック開始だ。
そこに、オーガが乱入してきてコアを吐かせるとか。
オーガだから、プロプラエタリは嫌いだろうしな。
_ テクノロジーゲリラ
で、やりたいひとはやれば良いだけなのだが、愛は確かに重要だ。
と、NetBeansはインストールしてあるのに、JavaでプログラミングするときにEmacsを起動して、結局APIはHTMLを眺めながらコード書いている自分がいたりするわけで、それはEmacsを愛してるからだ。
では、Rubyに対する愛が抑えきれないけど、回りを見渡すと、学校とか研修とか以外で新しい技術をおぼえたり使おうとか思う人が本気でいない状況だったらどうすれば良いのか？ についてちょっと考えてみる。立場的に佐官ではなく尉官の下のほうという前提。
で、さらに条件として宮廷内革命をしたいなぁ（=革命に成功すると大規模意思決定能力が取得できるから）とか野心があるとすると、内部でどうにかしなければならないわけだから、取り得る戦術は比較的限られてしまうかも。
で、考えつくのは分割戦術だ。
もし、大規模であってまともなアーキテクチャが採用されていれば、システムは分割され、いくつかのサブシステムが疎結合されているはずだ。その中には、障害耐性要求やパフォーマンス要求が比較的低く、長期的には利用されないことがわかっているサブシステムがあるだろう。なければ、そういうサブシステムの必要性を指摘して需要を喚起すべきだ。間違いなくあるから。それによって、そのサブシステムに対する適用というのが取れる。だから後はそのサビシステムに対するコミットメントの問題となる。もともとコミットメントが見えないから信用がおける方法を取っているというのが実情のはずだ。そのサブシステムが成功すれば、次は適用領域が拡大できる。逆に適用結果が思わしくなければ、コミットメントに従い、リカバリーするしかない。したがって、開発速度は非常に重要となる。
2007-06-17
_ rjb-1.0.6
JRubyに合わせてRubyスタイルのメソッド名も使えるようにした。
正直なところ、Rubyスタイルにメソッド名を変えることは、あまり良いアイディアとは思わないのだが（JRubyと異なり、Rjbを利用する場合、Javaのクラスを知っている開発者がそれを利用するわけだから、Javaのメソッド名を知っていることが前提となるはずだ）、名前忘れたがJRubyの来日した一人から、「requireしてるところとか別にすれば、Javaオブジェクトを利用するコードがCRubyとJRubyで共用できるよね」とかその点に関しては尤も至極なことを囁かれたので、まあ、それは正しい、と思ったわけで、1.0.6。
ただ、JRubyの変換規則を調べて実装したわけではないので、実は互換性が取れていないかも知れないので、気づいた点があれば御教示いただければ直します。
たとえば、CRuby＋Rjbで作っておいたソースが、JRubyにほとんどそのまま移行できるというようなシナリオは、たしかにあるでしょう。逆にJRubyで作ったらパフォーマンスがだめだめなのでCRubyで動かすってのもあるだろうし。
_ rjbのマスコット
カヤック星人か！
2007-06-18
_ ASR-1.8.636
今回、従来使用していたVisual Studio InstallerをVS6版からVS2005版に切り替えたため、幾つか変更しています。特に、バージョン番号。
内容は
-ruby-1.8.6-p36
-Exerb 4.2.0.0 (ruby-1.8.6-p36 core)
-Rjb 1.0.6
が、以前からの変更点となります（rdocは今回ドロップしてサイズを半減させてます）。
また、インストーラ構成をゼロからやり直しているため、不備があるかも知れません。
というわけで、もしよろしければ、試してみて以前のバージョンより欠けているライブラリなどが見つかりましたら、本記事のツッコミで教えていただけると幸いです。
一応、一週間後くらいを目処にinfoseek.co.jpのほうも更新します。
追記：肝心なこと忘れてた。山野 ゆき菜パッチを適用しています。-wでend警告が入ります。これが欲しかったんだよなぁ。すばらしいね。
_ 基本的に全然同意できないのですが、
かっこいい。
2007-06-19
_ リソースなのかRPCなのか
REST魂ってのはありそうだな。と、 HTTP ステータスコードを正しく使おう と、ぶくまこめんとを眺めて思った。
complexTypeとか出てきてること考えると、SOAPツールキットみたいなものを使って実装したんじゃないかと思える。とすれば、実装の考え方はRPCだろうし、エラーコードはその関数の実行結果であって、関数呼び出しのレイヤーの結果とは別にするのは素直にみえる。しかし、そうではなくてリソースの取得と見ればステータスコードを使えというのはもっともだ。
RPCなら専用クライアントがあるのが（暗黙の）前提となるから、話は合うのだが、その一方で、そんなものなくても利用できるんだから（＋多分、そんなものなしで利用してほしいと考えているようにもとれる）、だったらRPCとしての実装じゃなくて、リソース取得としての実装にすれば良いじゃんというのももっともだ。
これって、結構、おもしろい問題だな。
#自分で想像している以上に、自分が貴族的に考える(エラーコードは別じゃん)ことに新鮮な発見があったので、細かく書いてみた。
via soutaroにっき
_ ちょっと思い出したこと(1996あたりか?)
COMの実装方法にHRESULT foo(); HRESULT bar([out,retval]long* pResult);
問題というのがあって、fooのように実装するか、barのように実装するかというのが問題だった。
一般論（MSの推奨だと思う）としてはbar実装をする。
HRESULT stdcall bar(long* pResult) {
if (something_bad) {
*pResult = BAD_CONDITION;
} else {
*pResult = OK_CONDITION;
}
return S_OK;
}
でも、おれはこれはくだらないと思って、foo実装が多かった。
HRESULT stdcall foo() {
if (something_bad) {
// ミソの部分
return E_FAIL;
} else {
return S_OK;
}
}
ミソの部分でIErrorInfoを作れるからだ。で、これに相当するのがレスポンスボディ部のテキストということなんだろう。とすると、実際にはボヘミアンな考えをしてたってことだな（むしろ、その後に貴族化したらしい）。(追記：ちょっと違うな。呼び出し失敗は呼び出し失敗ということと、例外を使うと付加情報が多いことが理由だから、こっちはやはり意味を重ね合わせてるようだ)
ちなみにfooとbarを呼び出すクライアントのコードは次のようになる。
Dim Result As Long Result = obj.bar() If Result <> OK_CONDITION Then ... End If '''''''''''''' On Error Resume Next obj.foo If Err <> 0 Then ... End If
_ カリブの海賊
日曜は映画の日なのでカリブの海賊を見て来た。
パイレーツ・オブ・カリビアン/呪われた海賊たち(期間限定) [DVD](ジョニー・デップ)
パイレーツ・オブ・カリビアン デッドマンズ・チェスト スペシャル・エディション [DVD](ジョニー・デップ)
子供がはまりにはまっているんだが、1と2は見てないので、どんなものなんだろうか（子供はテレビで見てた）。
なんか、スターウォーズの4〜6で、主役の男女よりもハンソロのようなアウトロー風味の風来坊が人気抜群で、2作目の最後では敵に捕らわれるわけだが、3作目でちゃんと主人公たちに奪還してもらえて、みたいなところもあったりするんだが、そのくらいスターウォーズは良いフレームワークを提供してるってことなんだろうか。
それにつけても、食べ物じゃないものを人はどうしてああも気持ちが悪いものとして描くんだろうか。昆虫を食べない人たちは、昆虫を気持ち悪く描くし、鶏肉を食べない人たちは、鶏を気持ち悪く描く。鯨を食べない人は、鯨を悪魔として描く（船長の片足食ったり、木の人形を飲み込んだり、ヨナまで呑み込んでしまう）。だから、他人を受け入れがたい人たちは、まずは人間を食べるところから始めればよいのではないだろうか。そうすれば、気持ちの悪いタコ船長じゃなくて、とってもかわいいオズワルドとかタコのはっちゃんみたく見えてきて親しみがわくだろうから。(トンカツ屋の看板がかわいいぶたがぶーぶーみたいなのも同じ原理なのか？)
Hello! オズワルド DVD-BOX (限定版)(比嘉栄昇)
I Love Big City! (Oswald)(Chanda, J-P)_ リソース/RPC
クライアント側に立てば、実装がWebアプリケーションかWebサービスか静的なファイルの返送かはまったく関係ない。というか、世界系なんだから、そんなものを気にしてもしょうがない（逆に言えば気にしなきゃまずい方面はあるし、その場合は、クライアントは当然のように必要になってバグが増える（ということはあり得ないから、そのあたりはノイズだな））。
と、リクエスト出す側に軸足を置いてみるのか、それとも、サーバーの実装方法によってレイヤーが違うんだから、それぞれのレイヤーごとにきちんとエラーを返さなきゃだめじゃん、とレスポンス返す側（というより、両側そのもの側）に軸足を置いてみるのか、の違いのようだ。
とすれば、貴族とボヘミアンっていうよりは、キュロット（パンが食えなきゃ菓子食いな）とサンキュロット（おれたちに食い物を寄こせ）というほうが適切かも（元の分類方法は別にして）。ではなくて王の立場（飯の確保と輸送路の確保と輸送手段の確保と輸送計画と……飯が置き去りにされてしまったり）かも。
_ すげぇ発見
こりゃいいや。
っていうか、この歌はシルバーライトの歌だったのか。っていうか、空耳アワー。
アイアイアイアンパイーソン
アイアイアイアンルビーィーィーィー
いろんな言語でオフショアだyo!
シルバライット、シルバライット！
Moonlightより、ポップで好きだ（でも、もう2度と聴かないけどな）。
追記：いや、もう4回くらい聴いてるけど。（今日は午後からイベントなんで会社に行ってないのだった）
惜しみない称賛。
いろんな音楽知ってるよ、かずおさん、かずおさん
_ RubyLife.exe
ASRのインストール途中で起動されたrubylife.exeって何だろう
いや、起動されるってとっても変なんですが、何が起きたんだろう？ もうちょっと詳細を教えていただけないですか？
あと、RubyLife.exeは、ASRのsamplesに入っている、ScriptControlを利用してRuby本のLifegameを自分のフォームに描画するVBのプログラムです。
_ お金はモチベーションになるよ
中国の言い回しに親子三代が「贅沢に暮らせる」金額というような表現がある。現在の日本円に換算するとざっと、最低8億円くらいだろうか（軽く試算したが、ちょっと足が出るような気もする）。
1年間死ぬほど働いて成果を上げたら成功報酬が8億円と言われたら、おれだったら確かに死ぬ気ではたらくよ。
でも、7億9千万円程度じゃいやだね。
たぶん、ほかの人も同じか、もう少し高く勘定してるかも（9億円とか）。
それが労働価値より高すぎると考える程度の端金しか出ないんだったら、そりゃモチベーションにはならないだろうなぁ。
#金銭って絶対価値でしか考えてもしょうがないように思うが、そこを相対的な価値をもって成功報酬にしようとするのは間違ってるように思う。しかも、「死ぬ気で働」こうが楽しく働こうが実際問題として上げられる成果に差があるとは考えられないわけだが（でも無いかな？）
2007-06-20
_ RHG読書会での推薦図書
山下さんとcut-seaさん（実は名前知らない）がおもしろいおもしろいかわいいかわいいオリザ最高、いきなり会議で奥さんはまりまくりとか力説するので、あまりの迫力に押されてつい買ってしまって読んだ。
もやしもん(1) (イブニングKC)(石川 雅之)確かにおもしろいわ。（いきなり会議ってのは次の巻なのか?）
で、以降の巻も買うか、と思ってアマゾン見てると
もやしもん(5)おまけ付き (プレミアムKC イブニング)(石川 雅之)
が、
Amazon.co.jp ランキング: 本で2位とすごいことになっている。が、巻数が書いてないので、買えない。というか、人気あるんだな（本屋で平積みずーっとされてたのは見てるから人気あるってのはわかっていたはずだが、いかに、口コミが購買行動に影響するかを身をもって知るとか）。
で、もう一冊、口をきわめて賞賛してたのが
CPUの創りかた(渡波 郁)いや、おもしろそうだとは思っても、それほど興味はないわけだが、表紙もあれだし、しかしnobsunがでっかな声で、クロックを自分で決めて……（忘れちゃったが、なんかものすごくおもしろそうだということは良くわかった）……おもしろい！ とか断言すると、本当におもしろそうに思えるから不思議だ（題材的にはおもしろくないはずはないから、そりゃおもしろそうなわけだが）。
_ MD3
あとで書くつもり。
WPFはWPF。
Jasperは、レイトバインディング。ActiveRecordだなぁ。というか、レイトバインディングを主流にするつもりなんだろうか、とか。インテリセンスを実装するとしたら、初回アクセス時に取り出してキャッシュするとかかな。
LINQの本命はやはりペトポタか、というか、TableAdapterはどうなるんだろうかガクブル。
エンティティを中心に据えた場合（そもそもでもエンティティを構成するのは何かというのは目をつぶるのか、どうか）、ビジネスプロセスをどうそのエンティティにからめるのか？ という問題に対して、エンティティをオブジェクトとして多重継承でプロセスをからめる方法はオブジェクトグラフを固定化してしまうからあまりよろしくないのではないか、ではコンポジションでプロセスを挿入していくという方法はどうだろうか（そこにインターフェイスを決めるのか、それとも名前で決めるのか）、レイヤリングで分担ではどうか、アスペクトやデコレータによる外ざしはどうか、またはミキシンなど（オブジェクトではなく、関数の外ざし）はどうか、とか。書いてみると、いろいろな手法があるな。と書きながらふと思ったが、そもそもCでやってれば、全部関数テーブルでシンプルに解決するように思えてきたけど。
そのあと、NyaRuRuさんやakirameiさんや荒井さんと談笑。生成したTypeはアンロードできないのでAppDomainごと殺して解放する野蛮な手法とか、それに対してDynamicMethodとか（記憶違いかも）。
#メモのつもりが結構、長い。
2007-06-21
_ アイバリット先生 リムポポー
何気なく、リズムを取って、ふと思いついて検索すると、2件しかない。
みんな、アイバリット先生について書かないのか？ なぜだ？
でも、アイバリットで検索すると、兵庫の動物病院ががんばってて、やたらと引っかかる。
アイバリット先生は、↑というわけで、動物のお医者さんだ。ドリトル先生じゃないよ。
この先生、とにかく動物が悲しいことになっているのは耐えられない。だから、どこにだって出かけていっては、動物の病気や怪我を治療する。
さて、ある日のこと、アイバリット先生が寝ていると、電話がかかってきた。
もしもし、アイバリットですが、と眠い目をこすりながら電話に出ると、向こうからすっかり困り果てて取り乱しまくっている女の声がする。
わたし、くまですが、うちの坊やが元気がないんです。
そりゃ大変だ。
さっそくアイバリット先生は帽子をかぶり、黒いかばんに診察道具やら薬やらを詰め込むと飛び出した。
今度はアフリカか、遠いぞ。
先生、港から船に乗り、アフリカに着いた。
くまの坊やはどこにいる？ 病気で泣いてる坊やだよ。
その子なら、山を7つ越えたところでさぁ。
それは大変、急がなきゃ。
アイバリット先生リムポポー、リムポポー
先生、どんどこ山登り、山下り、さあさあ、残るはあの高い山。
しかし、これはびっくり、まるで壁。
でもここであきらめたら、熊の坊やがかわいそう。
先生、どんどこ崖のぼる。
あっと危ない、足すべらした。
まっさかさまに落ちてくよ。
そこにワシが飛んできた。先生咥えて、背中に乗せた。
アイバリット先生、どこ行くの？
山の向こうで熊の子が、病気で泣いているんだよ。
それなら、このままひとっ飛び。
アイバリット先生、リムポポー、リムポポー。
先生、先生、お待ちしてました、熊のかあさん、駆けてきた。
あいさつそこそこ、坊やはどこだ？
どれどれ、おなかを見せてごらん？ おやおやなんともなさそうだ？
いったい、どこが痛いのかな？
お指が痛いのえーんえん。
ああああ、これはトゲですな。ちくっとするけど、がまんして。
ほーら抜けたよ、大丈夫。ちょっと包帯巻いとこう。
坊やにっこり、嬉しそう。
アイバリット先生リムポポー。
というような感じのお話というか、韻がのりのりの散文詩だったような（よく覚えてない）。
#あさまししたいよりむぽぽー。でも無いのか。童心社のいわさきちひろが絵を描いている箱に入ったでっかな本（童話集だと思うが）だった。童心社の本自体、3ページ分しかないしな。
あ、あいばりっとせんせいだったのか。りむぽぽ〜だし。子供が自分で読む本だからひらがななのか、りむぽぽ〜。
2007-06-22
_ ASP.NET
実行時にコントロールの名前を得るのではない使い方、例えばブックマークレット用アンカータグ、にコントロール名を埋め込むことを考える。
問題はコントロールのネストなどのUIの変化によって名前が変わることだ。
ブックマークレットを想定した以上、これが問題となることは明らかだ。
とすれば、クエリに利用する名前はコードビハインドで実際のコントロールの名前（name属性値)にマップするのが良いだろう。
ところでASP.NETにもURLを書き換える仕組みってあるのかな？
2007-06-24
_ toruby#4
とちぎに行ってきた。高橋さんといっしょに。
で、外延でいくつか気づいた点。
・車が4台あったが、どれも小型の2ボックスカー
・西那須野には、公民館がすぐ近くに2つある
・牧場が多いみたいだ。
・5時くらいだと牛は牛舎にはいない（ただしサンプリング数は1つ）
・東北自動車道は、ETCパラダイス。
・目白駅の左横に謎の階段がある
・三島通庸の銅像。治安維持法の先駆者にして明治圧政の象徴的な自由への弾圧者としては知ってたけどインフラ作りもしたという側面はあったらしい。……朝鮮半島での日本人の振る舞いの先駆者でもあったわけか。あるいは、箱もの行政の先駆者とも言えるかも。つまり銅像という表現にふさわしい人物であるな。
・渡辺美智雄の銅像。胸に輝く菊の勲章。
おもしろかった話
・WEB+DB Pressは西那須野では買えないらしい
・駅名忘れたが、国会議事堂がある件
・オブジェクト指向は関数テーブルの交換が簡単な仕組み（というような内容）。
（実装上はその通りなので異論は無いのだが、割り切りがおもしろかった）
・1980年代中頃に、ワープロ喫茶というものがあって、400円払ってワープロ打ち放題。2〜3年くらいで普及したため、存在価値がなくなった。（インターネットカフェとの違いを考えるとおもしろい。内向きと外向きという差なのか、使いたい人の収入の問題なのか、あるいは）
・おもしろいとはfunなのかinterestなのか問題
・おもしろいと愛の問題
・RESTは不滅かどうか？ （不滅のものなどあり得ないので、長期的か中期的かというか）
・HTMLの技術的な寿命はあとどのくらいか
・女性プログラマは今この時に何をしてるんだろうか問題
2007-06-25
_ 酸っぱい料理
ひさしぶりにロシア料理を食って、あれ、こんなに酸っぱかったっけとちょっと驚いた。
たとえばペリメニに猛烈な酢の塊とか。ボルシチはサワークリームが入ってるわけだし。肉料理には酸っぱいピクルスが付く。
脂っこい料理には酢があうな、と中華料理の油脂の甘さがおいしいタイプの料理（炒め物とか）で感じてたけど、いささかロシアの酸っぱさは強力な気がする。
日本で酸っぱいというと、酢飯とかがそうだけど、それほどお目にかからない気がする。懐石料理とかに酸っぱい一品ってのは文字通りの酢の物くらいだったり。焼き魚に細長い生姜が付くとか。でも、それほど酸味は強くないように思う。〆た魚の酸味もそれほど強くはないような。いずれも保存食っぽいのに酢を使ってるように思うんだけど（酢の物は違うか）、ロシアのやつは地理的に保存食もへったくれもなさそうなだけに不思議だ。シベリア風牛肉料理とか、つまりはルイベの牛肉版だったり。北海道の人は冷蔵庫を常温保存のために利用するというような話を思い出してみたり。
2007-06-26
_ ライフハッカー本
Lifehacker インターネット時代のワークスタイル改善術!(Gina Trapani)
まあ、なんていうか、OS Xのキャプチャに注目ということで。
メールの分割統治法はすごく参考になったし、実際に実行してたりします。
この本の流儀だと、すぐ返事書く（書いたら捨てるか右のどれかに移す）、全部読み終わったら返事書くためにとりあえず入れておく（activeフォルダ）、お知らせとかの類で期限までとっておく（holdフォルダ）、後で必要そうなので貯めておく（archiveフォルダ――検索すれば良いのだから、1つで十分）という分類方法。
で、生まれた時間にスラド眺めてたりするんだから、実は役に立ってなかったり（そういうことをさせない方法も出てるけど、そこはあっさりスルー）。
2007-06-27
_ 眼力王
さて、一番好きなマンガは何かと聞かれたら、そのときの気分に依存するけど、眼力王は間違いなく入ってくる。
B00007CFTH
眼力王は、眼力（見つめると熱線が目から出てくるので、いろいろ燃やしたり焦がしたりできる）の持ち主で、その能力を生かして怪盗というビジネスをしている王様だ（若いけど）。オバQみたいに、そのうち、眼力の父とか母とかも出てきたりもするけど。王様といっても、王国があるわけじゃなくて、すげぇ奴の意味の王様だけど。
友達には、音楽王がいる。バイオリンでマーラーを弾くと、聴いた人間は踊りだして無抵抗状態になるから、その特技を生かして怪盗というビジネスをしている王様だ（こういうろくでもないニート達が自分で「王」を自称するってのが笑いを誘うわけだが、最近、「〜王」みたいな自称って見かけないなぁ。たぶん、80年代的な言語感覚――糸井重里とかが主導したやつ――なのかも。知らないだけで、そこらじゅうにいるのかも知れないけど。謎はキングだから違うか）。
で、おれが一番好きなエピソードは、緻密な作業が得意な音楽王が趣味のジグソーパズルを眼力王に自慢すると、眼力王が悔しがって暴れだす。そのため音楽王がまさに作りかけている何万ピースだかの斉藤由貴のジグソーパズルがもろくも元の紙片と帰す。愕然とする音楽王。それを横目にへらへら笑いながら、「直してやるよ」と眼力王がばらばらになった斎藤由貴のジグソーパズルを持ち逃げする話。（家の外まで音楽王が追いかけてくるので、振り向きざまに眼力で音楽王の家をジグソーパズルの形に切り分ける。ぱらぱら分解する音楽王の家をしり目に「音楽王よ、そんなにジグソーパズルが好きなら、それでも作ってろ」と言い放って逃げるような気がする。で、音楽王は悔しがりながらも、嬉々として組み立てるんじゃなかったっけな？）
しかし、当然のように、ずぼらな眼力王にジグソーパズルなんてできるはずもない。
かくして、音楽王が「完成したぜ」という眼力王の電話に呼ばれて見に行くと、そこで見たものはなんと……というのが、愕然とするほどおもしろすぎて、笑い死にしてしまったわけだが、あのおもしろさを理解するには、当時の斉藤由貴の人気っぷりとYMOの露出っぷりとかを知らないと無理かも。いや、今でもときどき、完成したジグソーパズルを思い出しては笑い死んでいたりするわけで、ついさっき突然死んで思い出した。
恋する女たち [DVD](斉藤由貴)（やっぱこれかな？ 大森一樹のゴダール厨っぷりがプラス方向に働いてるし）
_ ひさびさに必死を見た
「ノート：慶應義塾大学」というようなのを目にすると、くだらねぇ学校だな、と感じるわけだ（たかだか数人のせいで）。なるほどなぁ。組織のイメージってのは突出したくずな部分で刷り込まれるのかも知れないな。逆もまた真（突出した良い部分で刷り込まれる、知人だと酒井さんとかetoさんとかすごい人たちを知ってるわけだし）かも知れないけど、ネガティブなほうがインパクトがある。
2007-06-28
_ 残しといて良かった
_ うむ。
そうだろうな。
でも、まだ紆余曲折はありそうな気もするな。ってのは忘れっぽいだからだ総体として。
最初、誰かが気づく。ツメコミってのは、自分の頭で考えないで口を開けてるだけな状態を生みやすいってことに。そこでがんばるとその時点でのいろんな知識やノウハウを獲得できるからえらく優秀ではあるけれど、無から有を作ったり、なんだか創意したり工夫したりは苦手な人ばかりが出てくるらしい。っていうか、「その時点」では役に立つけど、「別の時点」に対応できんだろう、それでは。（注：その対応できなかった状態を90年代に見てきたと言うことができるわけだ、とおれは思うな。）
そこで、ツメコミはまずいと気づいた人たちがそれに対して軌道修正を入れる。自分の頭で考えるための余地を作るってことを。つまり、むやみとツメコマずに、ユトリを作るってことだ。
ところが、最初のうちは、まだツメコミ指向が残っているから、せっかくのユトリになにやら妙なものをツメコンでしまっていたりして。そのあたりのハイブリッドな人たちは実はもっとも豊かな可能性はあるのだが、声の大きい総体としてはあまりそうは感じない。
というのは、不思議なことに、ユトリという軽蔑語のようなものは見かけるわけだが、ツメコミという軽蔑語をみかけないからだ。
実験した理由、その結果、そういうものはちゃんと総体としての知識に組み込んどいたほうが、無駄な軋轢を生まなくて良いだろうな、と思うわけで、そうしているのであった。
2007-06-29
_ NetworkStream.DataAvailable
ふと気になったのだが（というか、気になるコードを見たわけだが）、
NetworkStream に読み取り対象のデータがあるかどうかを示す値を取得します。
……
プロパティ値
ストリームからデータを読み取ることができる場合は true。それ以外の場合は false。
という記述を読んで、
while (stm.DataAvailable)
{
int len = stm.read(buffer, 0, buffer.Length);
memory.write(buffer, 0, len);
}
stm.Close(); // 読取完了
というコードを書くというのは、常識がないのか、それともMSDNの説明が不足しているのか、どっちなんだろう？ （つまり、おれは常識がないように思う。しかし、そんな常識はどこにあるんだ？ と聞かれると確かによくわからないと言えばわからないわけだし）
追記：sawatさんのコメント。うーん、まあ「読んでいない」というのは論外として、「理解していない」としたら、どうするのが良いかなぁ？ この程度のプロパティの説明に「ブロッキングモードのソケットに対する擬似ノンブロッキング処理を行う場合の読み込み可能性のチェックのために利用します。クライアントが送信するすべてのデータの受信完了を調べるためには、ブロッキングモードの場合はreadメソッドが0を返すまでreadを実行してください」みたいな噛んで含めるような説明が必要か（しかも、特定ユースケースの例しか挙げることはできないし）とか。まあ、現場では教えれば済むわけだけど。
富豪的な別解：常に予想される送信データ長より大きなバッファを利用する。
2007-06-30
_ ダックタイピング(というかRuby)と大規模開発(実装設計編)
大規模開発の意味を、ここでは以下の要件として考えてみる。
・静的構成の多様性
・実装設計の最適化
・実装の容易性（ここでの容易性というのは、コードが少なくて済む、制約――覚えなくてはならないこと。たとえば種々の規約、ライブラリ関数名、呼び出し手順、など――が少ないことを意味する）
静的構成の多様性は、非機能要件の実装を運用時に多種類の中から選択可能だということを意味する。また、一定の粒度のコンポーネント（ビジネスコンポーネント）単位での入れ替え、削除、追加が可能なことを意味する。
実装設計の最適化とは、上記、静的構成の多様性を許容可能とするための制約を実装設計に対してあらかじめ含めることを直接には意味する。
実装の容易性とは、実装者が一定の手順を遵守することで比較的に均質なモジュールを実装できることを意味する。
従来このような実装のための方策として選択されたのは、フレームワークである（注：しまった。後で書こうと思って、「注」とアノテーションを入れたのは良いが、書くべき内容を忘れた。やっぱりこういう文章では()を使うべきだ）。
フレームワークとは、3種の類型実装からテンプレートを経由して自動生成へ進む過程のある段階のソフトウェア（構造、環境、実装）を示す。
フレームワークが実装に課す制約の多くは型判定に基づく(例：C++の仮想関数、Javaのinterface)か、またはクラスの継承関係に基づく（例：Rails）。これらは相互に排他ではなく、相互に補完しあう。例：C++の仮想関数とクラスの継承関係。
ダックタイピングは基本的に型を利用しない。
そうではなく、名前に基づく。
ダックタイピングに対する危惧は、名前による制約の有効性にあると仮定する。
これは、以下の3点のうち、
・静的構成の多様性
・実装設計の最適化
・実装の容易性
実装の容易性を破壊するのではないか、という危惧である。
#あ、最初に考えていたのとは異なるソリューションを見つけた。もうちょっと考えてみる。
_ いまさら読んだが、最高に刺激的
多分、shelarcyさんかmumurikさんか、あるいは両方だと思うが、えらく褒めていたのを見て、購入したものの放置していたわけだが、やっと読み始めて、しびれまくり。
Modern C++ Design―ジェネリック・プログラミングおよびデザイン・パターンを利用するための究極のテンプレート活用術 (C++ In‐Depth Series)(アンドレイ アレキサンドレスク)そうそう、「直行性」だよね、言葉は。機能要件と非機能要件は直行していなければならないし、さらに各非機能要件は相互に直交していなければならない（各機能要件には直交していなければならないという制約は完全に、まったくもって、存在しない。機能要件に対する制約は原理的にはビジネス以外には存在してはならない）。
とは言え、そんなに単純ではない（たとえば本書の例だと削除時の呼び出しとコンテナの実装方法）。したがって宇宙船を操縦することにもそれなりの意味があるということになる。
正直なところ能天気な本だなぁという気も実はするのだが、でも考えてみるまでもなく、ここまでフルに言語の機能を理解していたわけではない。
推薦文のスコットメイヤーの坦懐な述懐もいい。機能を知っていることと、機能を利用することには確かに差がある。Effectiveな本であれば確かにその通りだ。尊敬に値する著者だなぁ＞スコットメイヤー。
実装設計について考える必要がある人には、いまさらながら強く推薦する。これは価値がある本だ。でも、C++の暗号的なコードの本でもあるので、そこをどう気にするかだな。多分、()にアレルギーがなければOn Lispで、<>にアレルギーがなければ本書、なのかも（適当）。
typedefは暗号のような記述を簡潔にするだけではなく、シンボルとして実装を隠蔽するためのものである、というのは言われてみればその通りなわけだが、そういう意識しないことを言語化した知見にもあふれている。
#第1章を読んだだけだけど、ある意味、これだけでも十分に価値があった。
_ 筒井康隆の先見の明
金持ち娘と貧乏娘、性格の良いのはどっち？ みたいなやつを読んだ記憶が甦ってきたが、大まかにはあの結論は合ってるんだろうなぁと思ってみたり。
ジェズイットを見習え |
Before...
_ mumurik [といったその日にinterop版が出ました(笑) 評価はこれから。]
_ arton [interopって言っても、interoperability with other .NET languages で..]
_ mumurik [確かに。interopっていい方は悪いかもしれませんね。 もうCLIの上の住人なので気にならなかった。 ちょっといじ..]