FaithのBTOマシンですが、箱を開けたらこんなものが ↓

ブレードランナー…。
スピーカーは要らないので、「二つで十分ですよ」。

Eclipseを使っているとタスクマネージャで見たメモリ使用量が800MBを超えます。
会社で使っているマシンには768MBしか積んでいないので、時々ものすごく遅くなります。
やってられないので、秋葉原に行ってメモリを買ってきました。
DDR400の512MBです。チップセットはDDR266までしか対応していないのでオーバースペックですが、ちょうどいいのが見つかりませんでした。

さて、メモリスロットの最後の空きに買ったメモリを挿し、起動します。

768MBしか認識されません。挿す前と同じです。
スロット1と3が512MBで、スロット2が256MBという構成がまずいのかと思って、順番を入れ替えたり、不良を疑って買ったメモリだけの構成にしたり、いろいろ試しましたが、最高でも512MB×2本の1GBしか認識されませんでした。
どうやら、スロット3がおかしいようです。

あきらめて1GBで運用しようと挿しなおし、起動すると、今度は512MBしか認識されません。
512MB+256MBなら768MBと認識されるのですが、512MBの2本目は順番を入れ替えても駄目です。
さっきは認識されたのに。これでは元に戻っただけです。

ここで、なんとか1GBは認識させようとあがいたのがアダになりました。
メモリを抜き差ししている途中で、何かがはぜるようなパチっという音が聞こえました。
すぐに、樹脂の焼けるニオイが漂ってきます。
やってしまったようです。

案の定、再起動するとBIOSの画面すら表示されなくなっていました。
マザーボードかCPUのどちらかが死んだようです。
ニオイはCPU周辺から漂っているようですが、はっきりとはわかりません。
静電気にあまり気を使わなかったのが失敗でした。

どうしようもないので、再度、秋葉原に戻って中古のマザーボードとCPUを調達しました。
無駄な買い物です。同じCPUを選んだので、性能はぜんぜん変わってないし。

で、会社に戻ってマザーボードを交換します。
CPUファンの取り付けで手が痛いです。グリスが手について取れません。
それでもなんとか組み立て終わり、電源を入れるとちゃんとBIOSが表示され、Windowsのブート画面になりました。

これで一安心と思ったのですが、まだトラブルは終わりません。
Windowsの起動中に、ブルースクリーンで止まります。
INACCESSIBLE_BOOT_DEVICEと表示されているところを見ると、マザーボードを変えたせいでHDDをうまく読めないような感じです。

Google様にお伺いを立てたところ、再インストールせよとのお告げです。
そんなわけで、まだWindows200のインストール中です。
終電までに終わるかなぁ。

Javaでこんなコードを書いたら、例によってjavacに文句を言われました。

static final Tuple<String, FieldType>[] TYPE_MAP = {
new Tuple<String, FieldType>("int", FieldType.INT),
};

そんな型は作れない、と仰りやがります。

10秒ほど考えて、

static final Tuple[] TYPE_MAP = {
new Tuple<String, FieldType>("int", FieldType.INT),
};

としたら通りました。
Genericsの仕様と、言語組み込みの総称型である配列が衝突を起こしています。

Java Genericsの総称型はコンパイル時にのみ解釈され、バイトコードには総称型であったという痕跡すら残りません。
仕様的に残さないことになっているため、実行時に総称型オブジェクトの型パラメータを知る方法はありません。

一方、Javaの配列型は本物の(実行時にも型が残る)総称型です。
Tuple<String, FieldType>[]の型パラメータであるTuple<String, FieldType>も、実行時に残らなければなりませんが、Genericsの仕様からそれはできません。
というわけで、コンパイラはこれを文法違反と見なして文句を言っています。

Genericsの仕様を決めるとき、配列とGenericsの意味論上の互換性も議論されていたはずです。
しかし、文法上の互換性よりバイトコードの互換性を重視したせいで、このような奇妙なことが起きるようになってしまったのだと思われます(注1)。
互換性を理由に言語使用を歪める(注2)なんて、Javaも成長したものですね(注3)

注1.
言語仕様の一貫性よりもバイトコードの互換性を優先したのは、広く使われる言語の設計として妥当な判断だと思います。
ライブラリやフレームワークをコンパイルしたjavacのバージョンを気にしなければならない事態は、DLL HELL並の悪夢を引き起こしたはずです。

注2.
型パラメータをclassファイルに残して、もっと自然な形で総称型を実現できたはずです。
しかし、そのためにはバイトコードの仕様を変更しなければなりません。
そうなるとJDK1.5で作ったバイナリをJDK1.4以下の環境で使えなくなってしまいます。
これを避けるために、実行時の情報から型パラメータを消しているようです(他にも細々した理由はあるみたいですが)。

注3.
老化の兆しかも知れない。
Dog yearの時代に生まれた言語だけに、寿命も犬並みとか。

面白いと思ったのは2点。

1. for文にelse節を書ける

for文がbreakせずにループを完了すると、else節が実行されます。

    for (key, value)i in items:
        if key == "target"
            print "found: " + value
            break
    else
        print "not found"

集合から値を探すときに、見つからなかった場合を区別するためにフラグ変数を用意するのが他の言語では普通ですが、for文にelse節を加えることでこれを不要にしています。
これだけだと、小さい問題を解決するために言語に大きな変更を加えているようで気持ち悪いのですが、whileやtryにもelse節を書けるのでなんとか許容できそうな感じです。

2. __getattr__で委譲を簡単に記述できる

Barの機能をFooでも公開したいがFooはBarの一種ではないという場合、C++やJavaであればBarオブジェクトをFooのメンバにしてFooにBarオブジェクトへの委譲メソッドを書くのが普通です。

class Bar {
public:
    Bar() {}
    void doBar() {}
};

class Foo {
    Bar* bar;
public:
    Foo() : bar(new Bar()) {}
    void doBar() {bar->doBar();}
};

委譲メソッドがdoBar()一個だけならいいですが、これが多くなると作るのも面倒な上、保守性が低下します。
Eclipseで等の統合環境では、委譲メソッドをGUIから一括で作れるようにしていたり、リファクタリング機能で保守性を確保していたりしますが、対症療法であることは否めません。
Pythonの場合、未定義の属性への参照をフックする特殊メソッド__getattr__()があり、これを利用することで委譲を簡単に書けます。

class Foo:
    def __init__(self):
        self.bar = Bar()    # 移譲先のオブジェクト

    def __getattr__(self, name):
        return getattr(self.bar, name)  # 属性nameに対する参照をbarに転送する

動的言語ならではの手法なので、C++やJava等の静的言語でそのまま真似ることはできないのですが、ヒントにはなります。
欲を言えば、継承と同じように宣言的に記述できるとなお良いのですが、それは静的言語の手法かも知れません。

cppllで知ったのですが、Effective C++ 第三版の邦訳が出るようです。

http://www.amazon.co.jp/exec/obidos/ASIN/4894714515/

とりあえず、amazonで予約しました。
項目が増えているようです(第二版の50項目で、第三版が55項目)。
＃5項目のために4000円は高いような気もするけど、まぁいいか。

http://www.radiumsoftware.com/hungarian_notation.html

> Encode 関数を通す前の「危険な文字列」と， Encode 関数を通した後の「安全な文字列」を判別する方法は，言語やクラスの機能としては用意されておらず，プログラマの注意力に頼ることになってしまう。
(中略)
> そこで，「危険な文字列」には接頭子 "us" (unsafe) を与え，「安全な文字列」には接頭子 "s" を与えることにする。

ハンガリアン記法は正しく使えば有用なんだ、という表明。
もちろん、Javaとかの強く型付けされた言語でlong lHeightとかやるのは正しくない使い方です(何も情報を付与しないから)。

文中で、

> char* dest, src;

が「論理的な誤りを抱えている可能性が非常に高い」とされているのは、

 char* dest;
 const char* src;

の間違いでしょ、という主張なのかな？

Iさんがやたらと人に勧める本があります。

実践J2EEシステムデザイン

確かにいい本ですが、重くて分厚くて、まず物理的に読みにくいです。
電車で立ったまま読んでいると、降りる頃には手がおかしくなっています。
内容的にも高度で、正直読んでいて苦痛でした。

同じくらい分厚い「Code Complete」の初版や「Rapid Development」はここまで苦痛じゃなかったし、「プログラミング言語C++ 第三版」や「オブジェクト指向スクリプト言語Ruby」は読んでいて楽しかったので、何か固有の原因がありそうです。
単に私がEJBに興味がないせいなのかも知れませんが (EJBじゃない部分に関してはすんなり読み進められたような気がするし)。

Iさんはこの本をバイトの学生に喜々として勧めるので、ハラハラします (=「こんな本を読ませるArielに絶望した!」 とか言われたらどうしよう)。
Arielのバイトの人たちは怖いくらいに優秀なので杞憂の可能性はありますが、それでも無茶です。

ちなみに、苦痛な本といえば他にアジャイルプロジェクト管理がありますが、こっちは翻訳の問題でしょうか。
後はディアスポラの第一章…。

映画日本沈没を見ました。 全体の印象は、前半が日本沈没で後半がさよならジュピターといった感じ。話がかなり変わっています。
原作通りに進めようとして細部を全部落っことした73年版より好みです (73年版は小野寺役を藤岡弘が演じていて、目を疑ったし)。

ただ、構成が変化した影響で、楽しみにしていたシーンが無くなっています。

1. 「カンです」

科学者にとって一番大事なものは何かと問われた田所博士がこう答える名シーンですが、何故か無くなっています。
代わりに、論敵から「お得意の直感とイマジネーションかね？」と揶揄される場面が入ってます。これに拳で応える田所博士…。どうも田所博士のキャラクターはイマイチでした。

2. 終盤の田所博士と渡老人の会話

沈没を目前にして淡々と交わされる会話ですが、強く印象に残るシーンです。
が、今回は渡老人が登場しません。当然、この場面もありません。
おそらく、今となっては政界の黒幕という存在にリアリティーがないという判断故だと思いますが、残念でした。

3. 富士山の大噴火

変更の影響でありませんでした。これは画として見たかったなぁ。

ちなみに、「海底乱泥流」はほぼそのまま、「なにもしない」とか「燕じゃ」とかいった辺りは形を変えて入っていました。

というわけで、次は日本以外全部沈没の映画版が楽しみです。

を読み終わりました。

第一部は中学生の時に読んだので、20年弱待った計算です。
プロットを小松左京が作って、谷甲州が書くという変則的な小説ですが、あまり違和感がありませんでした (変に饒舌なところはありますが)。

舞台は第一部の25年後です。第一部が198X年の設定だったので、2010±5年が今回の時代背景になります。
ただし、日本が沈没した世界の2010年前後なので、現実とはだいぶ違った状態になっています。

そんな状況下で世界に散った日本人の状況や、日本沈没をきっかけに起きる世界的な危機を描いているのですが、さすがに面白いです。
待った甲斐はありました。

日本が無くなった割に世界情勢が現実とあまり違わないとか、阿部令子がなんで生きてるの?とか、いくつか違和感はありますが、それよりも圧倒的なスケール感を楽しむ小説です。

いったいどう終わらせるのかと思いながら読んでいたら、最後は日本沈没が三部作であることを思い出させてくれました。
これが小松SFの集大成かというとそれは違うと思いますが、いいものが読めたことに感謝です。

＃虚無回廊の続きはどうなったんでしょうか…。

の池袋店に行ったら、日本沈没 第二部がベストセラーリストの3位に入っていた。
ちゃんと売れてるみたいで安心。

ダン・シモンズのイリアムを見つけたが、目的の本と合わせると手持ちが乏しくなるので見送り。
さっきAmazonで注文したけど、本屋からすれば納得できない購買行動だろうなぁ。

1chip MSX 上でFPGAを書き換えたり、FPGAのコンフィグROMをファイルに保存したりするPLDLOAD/PLDSAVEです。

1.  どこかから、MSX2+相当のVHDLソースを貰ってきて
2. Quartus II 6.0 Web Edition Fullでコンパイル(?)して
3. できたPOFデータをpof2pldでPLD形式に変換して
4. PLDLOADで読み込むと!
5. あら不思議。MSX2だった1chip MSXがMSX2+に早変わりです。
   (後でMSX2に戻せるように、PLDLOADを使う前にPLDSAVEで元の内容を保存しておくのを忘れずに)

いきなりPOFで配られてたりしたら、1と2は省略可。
興味のある人は、下のリンクからダウンロードして下さい。

• PLDLOAD & PLDSAVE for 1chip MSX
• pof2pld for Windows ver1.00

要は、1chip MSXとWindowsマシンを接続するケーブル(ByteBlaster2)がなくても、FPGAを書き換えて1chip MSXをバージョンアップさせられるということです。

@ITに、調べもの専用Googleブラウザを作ってみよう という記事を書きました。
さっき見直していたらボロボロでした。説明通りに操作してもコンパイルすらできません。

修正を依頼したので、今週中には直っていると思います。