http://www.lotr.jp/

色々な意味で面白い映画だと思う。２作目における個人的な注目ポイントは，ローハン国の都市「エドラス」の壮大な舞台セットと，フル CG レンダリングによって描かれたキャラクタ「ゴラム」の緻密な動きだ。

http://www.lotr.jp/legend/lands/edoras/set.html

http://www.lotr.jp/index_editorials_becomegollum.html

「エドラス」は，敢えて実物のセットを用いることにこだわったと言うだけのことはあって，２作目の中でも最も美しい景観を見せてくれるシーンとなっている。たった２週間の撮影のために７ヶ月もの月日を費やしてこれだけのセットを作り上げたというのだから，何とも壮絶な話だと思う。

メイキング・ビデオの解説によれば，「堕落したホビット」こと「ゴラム」の動きは，俳優アンディ・サーキスの演技を忠実にトレースすることによって生み出されたということだ。ふたつの人格「ゴラム」と「スメアゴル」が葛藤を繰り広げるシーンなどでは，非常に豊かな表情の変化を見せてくれる。突き詰めれば「ＣＧ臭さ」を感じてしまう映像ではあるのだけれど，そのリアリティは極めて高いレベルにまで達していると思う。

余談だけれど， CG によって作られた部分に関して，モーションブラーが少し滑らか過ぎるように感じた。いつかの "Temporal Antialiasing" の話が絡んでくる部分なのかと思う。単なる気のせいかもしれないけれど……。

http://citeseer.nj.nec.com/dachille00highdegree.html

DVD 版 "LotR" の音響に関して，ひとつ気付いたことがある。低音成分を含んだ大きな効果音などが鳴る際に，耳が圧迫されるような歪みとともに，全体の音量が押し下げられるような効果が与えられていることだ。詳しいことを分からないものの，とにかく，音圧を強力に高めるための工夫が仕込まれているように思える。

基本的にはコンプレッサの効果に似ているものの，一般的なコンプレッサでは，このような効果は現れないと思う。いわゆるマルチバンド・コンプレッサってやつなのかね……。

http://www.ottotto.com/sound/08/comp.htm

permalink

http://c2.com/cgi/wiki?StatePattern

デザインパターン関連の話題については C2 Wiki を漁ってみると面白い話と遭遇することがある。 State Pattern に関しても，上のページからリンクを辿ることによって，様々な人の意見に目を通すことができる。

まず，意外に多かったのは，「Strategy Pattern と State Pattern の違いが分からない」という意見だ。

http://c2.com/cgi/wiki?StrategyPattern

確かに，このふたつのパターンは，基本的に同じ構造を持つもののように思える。

http://home.earthlink.net/~huston2/dp/strategy.html

http://home.earthlink.net/~huston2/dp/state.html

結局のところ，デザインパターンとは，「こういう状況では，こういう具合に組むと良い」という一種の指針を提示するものでしかないから，その構造や実装手段の部分に目をやってしまうと，どれも同じようなものばかりが並んでいるような印象を持ってしまうのではないかと思う。よくよく考えてみれば， GoF のパターンなんて，そのほとんどが Template Method Pattern を内包しているわけだし，無理も無いことかもしれない。

同じページに目をやってみると， "State has no state" という格言が記されていた。

http://c2.com/cgi/wiki?StateHasNoState

FSM 的なステートの運用を行う場合，そのステートクラスの実装は，次のステートへの遷移を発生させたり，特定のアクションを呼び出すのみであることが多く，内部に実質的な「ステート」を持つことは少ない。ここから，ステートクラスを Singleton や Flyweight と組み合わせることによって無駄なインスタンスの生成を避けるという，ひとつの指針を導き出すことができる。

http://c2.com/cgi/wiki?ContextParameter

State Pattern に関して，もう１つ面白かったのは， "Run and Return Successor" というパターンの存在だ。

http://c2.com/cgi/wiki?RunAndReturnSuccessor

http://wiki.slowass.net/?RunAndReturnSuccessor

ステートクラスのメソッドの返値に「次のステート」を返すことによって状態の遷移を管理するという手法だ。こうすることによって，それぞれのステートは最低でも次のステートの情報さえ知っていれば良いことになる。ステートとコンテキストの間の関係は最小のものとなり（もはやステートはコンテキストの存在を関知する必要さえ持たないかもしれない），また，ステート同士の結合も最低限のものとなる。

この設計は，サブクラス同士の結合を招いてしまっていることから「満点」とは言えないものの，ステートの追加に伴うコストが最小のものとなる（ステートの追加によってコンテキストの実装に変更が生じることは一切無い）ことと，構造的に非常にシンプルな形態へとまとめられることから，個人的にお気に入りのパターンとなっている。

GoF による State Pattern の解説においても，ステートの遷移の管理を誰に任すかという問題は，未解決の問題として提示されている。どうしても循環的な参照が発生してしまうため，構造的に複雑な設計となってしまうという問題の他に， C++ では前方宣言 (forward declaration) が必要となるために，どうしても記述がややこしくなってしまうという問題も残されている。 SMC のような特殊なコードジェネレータを導入したくなる理由は，そういった所にも存在しているわけだ。

permalink

http://www.cocolog-nifty.com/link/link02.htm

僕は以前から SharpReader を利用しているのだけれど，その機能には必ずしも満足していない。そろそろ他のソフトを試してみようかと考えているところだ。

http://www.sharpreader.net/

SharpReader が抱えている最大の弱点として， .NET Framework を利用していることが挙げられるのではないかと思う。とにかく，非常に「富豪的」な設計がなされているらしく，起動が非常に遅かったり（これは .NET Framework を利用したソフトに共通して言える欠点だ），動作が微妙に重かったり，使用中も異様にメモリを食うなど，常駐して利用するアプリケーションとしてはあまり相応しくない内容となっている。

そう言えば，先日，巡回先のブログのひとつである ".NET Undocumented" において，同サイトの管理者である Wesner Moise 氏が， SharpReader の持つ「富豪性」と managed code の関連性について雑感を述べていた。

http://wesnerm.blogs.com/net_undocumented/2004/01/cost_of_ob...

http://wesnerm.blogs.com/net_undocumented/2004/01/cost_of_ob...

つまるところ， .NET Framework に基づいた managed code が必ずしも重いというわけではなくて，扱い方に色々とコツが存在するという話のようだ。氏は参考文献として Jan Gray 氏の "Writing Faster Managed Code: Know What Things Cost" と， Brian Goetz 氏の "Java theory and practice: Garbage collection and performance" を挙げている。まだ目は通していないものの，面白そうな文献なので，機会があれば読んでみたいと考えている。

http://www-106.ibm.com/developerworks/library/j-jtp01274.htm...

http://msdn.microsoft.com/library/default.asp?url=/library/e...

……とその前に，まず .NET Framework について勉強しておく必要があるかもしれない。 .NET の周辺技術に関しては，当分の間，自分には関係の無い話だろうと高をくくっていたのだけれど，予想よりも早く事態は進展しているように思える。油断していると浦島状態になってしまいそうだ。

.NET Framework の概要に関しては， @IT の連載記事「インサイド .NET Framework」を参考にするのが良さそうだ。既に一般的な知識を備えた技術者にとって，知りたい箇所を上手くカバーした，非常にバランスの良い記事だと思う。

http://www.atmarkit.co.jp/fdotnet/technology/idnfw11_index/i...

.NET Framework の存在は，保守的な UNIX 愛好家にとっても対岸の出来事ではなくなりつつあるように思える。 Ximian の "Mono" プロジェクトが，スケジュールに多少の遅延を伴いつつも，かなり良いペースで開発を進行させているためだ。

http://www.go-mono.com/

http://japan.cnet.com/news/ent/story/0,2000047623,20062083,0...

Mono プロジェクトのマネージャである Miguel de lcaza 氏のブログなどを覗いてみると，精力的に開発の行われている様子をうかがうことができる。

http://primates.ximian.com/~miguel/all.html

XML との親和性や managed code の扱い易さなどを考慮すると， C# は開発用のツールとしても有用な存在となりうるのではないかと思う。たとえそれが UNIX ベースの環境であったとしても，だ。

そのような流れの一方で， "Joel on Software" の Joel Spolsky 氏は，先日の記事 "Please Sir May I Have a Linker?" において，ランタイム時の解決に偏重している .NET Framework の方向性に対して，強い疑問を述べている。

http://www.joelonsoftware.com/articles/PleaseLinker.html

いかにも実利主義者の Spolsky 氏らしい意見だと思う。もっともな意見ではあるものの，少し保守的に過ぎるきらいも感じられる。

permalink

http://www.nedbatchelder.com/blog/

僕が Batchelder 氏の経歴について知っていることは少ない。 IBM や Iris Associates において Lotus Notes の開発に係わった人物であるらしいのだけれど，それ以上の詳しい情報は把握していない。

http://www-10.lotus.com/ldd/today.nsf/0/e403f6b6ca35e5fd8525...

氏のブログは，単にギーク向けのエッセイとして楽しんでいる。氏は Python 使いでもあることから， Python 関連の実用的な情報が得られることもあるものの，大抵はとりとめもない雑談に終始している。

例えば，こんな感じだ。

http://www.nedbatchelder.com/blog/200401.html#e20040128T2147...

そんな Batchelder 氏のブログにおいて，先日紹介されていたソフト "SpaceMonger" が面白かった。

http://www.werkema.com/software/spacemonger.html

http://www.nedbatchelder.com/blog/200401.html#e20040123T0808...

"SpaceMonger" は，ディスクの使用状況を視覚化して表示してくれるソフトだ。同様のソフトは他にも多く存在するものの，この SpaceMonger は見易さの点で白眉の出来となっていると思う。

この視覚化手法は，米メリーランド大学の Ben Shneiderman 教授が行った研究 "Treemaps" が元となっているようだ。

http://www.cs.umd.edu/hcil/treemap-history/index.shtml

ただし， SpaceMonger の作者である Sean Werkema 氏は， "Treemaps" のコンセプトを参考にはしたものの，実際のアルゴリズムに関しては独自のものを利用していると述べている。

また，近日公開予定の v2.1 では，様々な統計情報の表示もサポートされており，更に優れたソフトウェアとなっているようだ。

http://www.werkema.com/software/sm2-scrnshot.html

こうして視覚化を行ってみると，意外なデータが容量を食っていることがわかる。僕はてっきり，個人所有の CD を mp3 化したアーカイブが最も容量を食っているものかと思っていたのだけれど，実際にはゲームのパッチや mod を収容したディレクトリが異様に容量を食っていることが分かった。

機会があれば，職場のファイルサーバにも分析をかけてみようかと考えている。何らかの有用な情報が得られるのではないかと思う。

permalink

http://wesnerm.blogs.com/net_undocumented/2004/01/fire_and_m...

これは， Joel Spolsky 氏が自身のブログ "Joel on Software" において記したコラム "Fire and Motion" に対する反応だ。

http://www.joelonsoftware.com/articles/fog0000000339.html

このコラムは次のようなくだりから始められている。

個人の精神面の問題というのは，やや扱うことの難しい問題のように思える。まかりなりにも知的労働を生業としている人ならば誰しも，自分が怠慢であると感じてしまう瞬間を幾度と無く経験しているのではないかと思う。 Joel 氏のような第一線で活躍する技術者でさえ，自らの集中力を制御することは難しいと述べている。人によって偏りはあれど，誰しも精神の働きに「波」を持っているという話だ。

僕はこのコラムを読んで，非常に強い共感を覚えた。僕は普段から，自分の集中力は人と比較して非常に低いのではないかと感じている。以前はそのプレッシャーから，たとえ仕事が少なくとも，１日おきに職場に泊まるような真似をしていたほどだ。低い集中力を長い勤務時間によってカバーしようと考えていたわけだ。

しかし，それほどまでに集中力が低いのならば，何故に人並みの成果を出すことができているのだろうかと思う。案外，皆が同じような悩みを持ちながら，自らの集中力を高める手段を模索しているのかもしれない。 Joel 氏のコラムを読んで考えたのは，そんなことだ。

このような精神面の問題は，人の内面に係わる事柄であるため，あまり気軽に踏み込むことのできない領域となっているのではないかと思う。もし，人から「集中力が高いですよね」などと言われたら，どのような気持ちになるだろうか……僕ならば，「そんなことは無いです」と返したいところなのだけれど，何しろ人と比較する術を持っていない以上，その質問に対して正確な回答を出すことはできないだろうと思う。

permalink

permalink

permalink

http://www.casio.co.jp/ww/waveceptor/products/desk/digital04...

売り場に陳列されていた時計のほとんどは電波時計だった。流行りなのかな……。

http://www.casio.co.jp/ww/waveceptor/wave/

もちろん，購入した時計も電波時計だ。これで，自分の手で時刻を合わせる必要も無くなると思っていたのだけれど，何故かうまく電波を受信してくれない。自分の部屋の条件が特に悪いということは無いと思うのだけれど……初期不良かな。とにかく，手間要らずの電波時計のはずが，ただのデジタル時計になってしまった。ちょっと空しい。

突然，こんな時計を購入したのは，以前から新しい目覚し時計が欲しいと考えていたためだ。今まで目覚ましの代わりに使っていた電話機の時計は，なぜか精度が非常に悪く，気付かぬ間にどんどん時刻がずれていってしまう。アナログ時計よりも誤差が大きいのだから呆れてしまう。ただでさえ慌しい朝を，そんな当てにならない時計を頼りに行動するのは，どうにも心許ない。

あと，音声機能が付いているというのも，ちょっとしたポイントだった。目を開かなくても時間を確認できる時計は，少しでも睡眠時間を延ばしたい自分にとっては，なかなか魅力的な機能だった。

permalink

http://www.ishkur.com/features/music/

このページは，電子音楽……つまりテクノ系の音楽の変遷に関して網羅的な解説を行っているページだ。僕は，この手の分野にはあまり詳しくないので（知ったかぶりは得意だ），その精度についてはどこまで信用していいものやら分からないのだけれど，とにかく物量が豊富なのが印象的だ。約 700 もの曲を例に挙げ，総計で 142 ものジャンルに関して解説を行っている。この派生図を見れば，あの曲はこのジャンルの一派だったんだ，とか，このジャンルが派生してこうなったのか，とか，色々と面白い発見が得られるのではないかと思う。

今だと "2-step" や "Garage" なんかが流行りのジャンルなのかな……。

http://www.listen.co.jp/xtpsub2190.jsp

http://www.listen.co.jp/xtpsub242.jsp

個人的に面白いと思ったのは， "Experimental" の流れから派生した "Casiocore" だ。要するに， 80 年代のローファイなシンセサイザー音によるチープな表現を主体としたジャンルのことらしいのだけれど……本当にジャンルなのかな，これは。

http://www.google.com/search?num=50&q=casiocore

上の検索から引っかかった "Slabco Records" レーベルのページからは， Casiocore なアルバムを無料でダウンロードすることができる。そのアルバムの名も "Casiocore" だ。

http://www.slabco.com/freep3/freep3.html

何とも言えない脱力的な空気が全体を支配する素敵なアルバムだ……単に出音が弱いとかそういう問題では無く，もう曲調全体が危険なまでに牧歌的で，聴き手の戦意を完全に無力化させる力を持っている。投げやりな気分や，うんざりした気持ちなどを演出したい場合にどうぞ……って感じだ。

ドイツのミュージシャン "Casiotone for the Painfully Alone" による楽曲群なども，かなりいい感じの脱力具合だ。

http://www.tomlab.de/artists/cftpa.html

http://www.tomlab.de/hitech/tom16/

どうやら "Casiotone" は，チープな出音のシンセサイザーを指し示す代名詞として世界的に通用する概念であるようだ。とは言っても，それは決して馬鹿にされているわけではなくて，ある種の郷愁を伴っていることがわかる。なんだか妙な愛され方をしているようで面白い。

http://www.vintagesynth.org/audio/vl1.ram

http://archive.keyboardonline.com/features/vintagegear/vgear...

http://www.informatik.fh-hamburg.de/~windle_c/TableHooters/C...

http://www.unhacker.com/maximumcheesecore.html

また時には，フリーキーな改造の対象となってしまうこともあるようだ。

http://bending.hp.infoseek.co.jp/

特に MIT の Joe Paradiso 氏によって行われた改造などは，驚きや呆れと言った段階を通り越して，どこか遠い境地へと辿り着いてしまった観がある。

http://web.media.mit.edu/~joep/synth.html

http://www.synthmuseum.com/casio/casvltone02.html

http://www.synthmuseum.com/casio/cassk101.html

元の VL-1 が全く原形をとどめていないような……。ここまで来ると，最初から自作した方が早いのではないかと思うのだけれど，そこを敢えて改造にこだわるというのが，やはり愛情なのだろうと思う。

permalink

http://grandtextauto.gatech.edu/archives/000225.html

http://www.movesinstitute.org/AAbooklet.pdf

この冊子は，アメリカ陸軍のリクルート用ゲームとして配布され話題を呼んだ "America's Army" の公式解説本だ。この冊子を制作した MOVES (Modeling, Virtual Environments, and Simulation) Institute は，米国の海軍大学院 (Naval Postgraduate School) の一部門であり， "America's Army" の実質的な開発を担当した部門でもあるようだ。

http://www.movesinstitute.org/

どうやら，この冊子は，現在 Yerba Buena Art Center において開催されているイベント "Bang the Machine" のために制作されたもののようだ。

http://www.yerbabuenaarts.org/va/current/bang_mach.html

内容については，非常に小奇麗にまとめられているものの，一般の来場者を意識した内容となっているためか，いまいち深みに欠けるような感触があった。見た目の綺麗さと内容の充実ぶりに関しては，さすが国から金が出てるだけあって……というような印象だ。

個人的に興味を持ったのは，同ゲームのコミュニティを構成するプレイヤー達にインタビューを行っている部分だ。本来このゲームは，陸軍のリクルート活動のために制作されたものであり，メインターゲットは１３歳以上のティーンエイジャーとされているのだけれど，その一方で，コミュニティの中には少なからぬ量の現役軍人や退役軍人が存在する。そのような実際の兵役経験者にとっても，この "America's Army" は特別な意味を持つゲームとなっているようだ。

ここで登場するクラン "1st Veteran's Battalion" の創始者もまた， "America's Army" を特別なゲームとして捉えているようだ。イラク戦において傷を負い，帰国したのちに意気消沈していた彼を立ち直らせたのが，このゲームのコミュニティのメンバーだったと述べている。

実際の戦争の残酷さを知っており，なおかつ，その残酷さの犠牲となった兵士までもが，この "America's Army" をプレイしているという事実には，かなり意外な印象を持った。いずれも，そのコミュニティの存在をゲームへの参加理由としている所が注目すべき点だと思う。

permalink

http://www.bfortune.net/calen/kinenbi/02/kenkoku-kinen.htm

どうやら，かなりいい加減な由来の祝日であるようだ。仰々しい名前の割には，いまいち有難みに欠ける祝日だと思う。

仕事の方が立て込み始めているので，昼から出社することにした。職場に辿り着くと，フロアの隣の区画では，完成に近づいたプロジェクトの方々が今日も当然のように働いていた。あちらと比べれば，こちらの区画はまだだいぶ平和なものだと思う。静まり返った空気の中で黙々と作業を行っていると，ちょっと懐かしい感覚が蘇ってきた。昔はよく職場に泊まりこんで，こんな感じの静かな職場の中で，気だるい気分に浸りながらダラダラと非効率的な作業を行っていたものだと思う。

ちなみに今日は，「戦国無双」と "EyeToy: Play" の発売日だった。

http://www.famitsu.com/game/news/2004/02/11/103,1076466907,2...

個人的には「戦国無双」を購入しようと思っていたのだけれど，時間の都合で店に行くことができなかった。ちょっと悔しい……近いうちにリベンジしようと思う。

"EyeToy" の方は，色んな意味で今後の展開が楽しみなゲームのひとつだ。デバイスの持つポテンシャルという点では，これまでの「デバイスもの」のゲームとは一線を画す存在となっているのではないかと思う。問題は，今後の展開において，果たしてそのポテンシャルをどこまで引き出すことができるだろうかという点だ。色々と「仕込み」は始められているようなのだけれど……。

http://www.digimask.com/news/article_eyetoy.html

http://www.fonix.com/page.cfm?name=news&id=1465

デバイスと言えば，以前から個人的に注目していた GBA のワイヤレスアダプタが既に発売となっている。「ポケモン ファイアレッド・リーフグリーン」だ。

http://www.pokemon.co.jp/game/fireleaf02.html

どうやら既に１００万のオーダーで販売が行われているようで……恐ろしい限りだと思う。このワイヤレスアダプタに関しては，今後行われるであろう「ポケモン」以外への応用に注目したいと思う。

しかし，どうも最近の動向を観察する限りでは，ワイヤレスアダプタよりも，むしろ「カードｅリーダー」の方が先に昇華しそうな観がある。

http://www.nintendo.co.jp/n08/hardware/card_e_p/index.html

これまでは，いまいち日当たりの悪い存在だった「カードｅリーダー」も，最近になってから急に積極的な展開が行われている。その中でも大きな動きは，全国の小売店舗に試遊台の設置が行われていることだ。

http://www.nintendo.co.jp/n08/hardware/card_e_p/playdai/inde...

ちょっと下世話な話ではあるけれど，「トレーディングカードとの連携」というモデルは，ビデオゲームにとって非常にホットなドル箱となっているように思える。何故，最近のアーケードゲームは，ああもカードと連携を行いたがるのか……その収益の仕組みを少しでも考えてみれば，その理由は明らかなものではないかと思う。

それはさておき，この「カードｅリーダー」は，技術的に見てもなかなか面白いネタだ。たった数キロバイトの容量ではあるけれど，単なる紙切れの中にデータを組み込むことができるというのだから，そのコストの安さを考えるだけでも，ポテンシャルは限りなく大きく膨らむのではないかと思う。

http://www.olympus.co.jp/jp/news/2003b/nr030909mobiletrj.cfm

http://www.mainichi.co.jp/life/hobby/game/news/news/2001/03/...

http://www.hallab.co.jp/recruit/project/card/index.html

permalink

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

http://www.gogo3d.com/products/rudy/index.html

この本は，サンノゼ州立大学において教授を務める Rucker 氏が自身の講義のために著した書籍 "Software Engineering and Computer Games" の和訳版だ。以前から原著の存在は知っていたのだけれど，和訳が行われていることについては全く知らなかった。どうやら，昨年末に既に発売されていたもののようだ。

軽く立ち読みしてみたのだけれど，どうにも教科書然とした内容だというのが率直な感想だ。もともと教科書として執筆されたものなのだから，当然のことと言えば当然のことかもしれない。ゲームプログラミングが云々とか，グラフィック技術が云々とか，そう言った専門的な技術に関して触れている箇所は非常に少なく，それよりもむしろ，ソフトウェア設計の一般論に関して多く触れている。しかしそれも，だいぶ基礎の部分に焦点が当てられているため，少しでも経験を持った技術者にとっては，かなり「生ぬるい」内容となってしまっているのではないかと思う。

ただ，ＯＯやらデザインパターンやらＵＭＬやらを持ち出して，ゲームという「ソフトウェア」を設計する手際をまともに教えようと試みている点については，ある種の筋の正しさを感じた。それゆえに，経験者にとっては相応しくない内容ではあるものの，これからソフトウェアの制作方法を学ぼうとしている学生などにとっては，適切な内容の書籍となっているのではないかと思う。例えば，この本に書かれていることをちゃんと理解した学生が新人として入ってきたとしたら，それはそれでとても喜ばしいことだと思う。

まあ，そんなわけで，購入は見送ることにした。早まって原著を買ったりしなくて良かったと思う……。

上の「ソフトウェア工学とコンピュータゲーム」に目を通した際に， listener クラスを利用した設計の例が提示されているのを見て思い出したのだけれど，このように listener クラスを利用して任意のインタフェースを提供するというパターンは，個人的に利用頻度の高いパターンとなっている。多重継承を避けつつも複合的なインタフェースを提供したい場合，この listener クラスを利用したパターンは，なかなか安定した手法として使いでがあるのではないかと思う。 Java の AWT などでも多用されていた手法だ。

http://c2.com/cgi/wiki?GenericListener

http://journals.ecs.soton.ac.uk/java/tutorial/post1.0/ui/act...

個人的には，ネストしたクラスを利用して listener を定義する方法が気に入っている。

http://c2.com/cgi/wiki?NestedClass

ただ C++ の場合は，上の Java の例にあるような「上のクラスへのアクセス」を利用することはできないので，構築時に己の参照を渡し合ったり，適宜に friend 指定を行ったりしなくてはならない。また，この手法では， listener クラスの役割を明確に制限しておかないと，クラス間の主従関係が曖昧なものとなってしまう危険性があるように思える。

何にしろ，もう少しばかり整理して考えてみる必要がありそうだ。

permalink

http://www.deusex.com/

このゲーム "Deus Ex: Invisible War" は，既に昨年の末に発売されており，各所でも話題となっていた。個人的にも注目していた作品なので，是非プレイしてみたいと考えていたのだけれど，なかなか手をつける機会が無くて，今まで放置していたという具合だ。

デモ版のインストーラは Eidos の ftp サイトからダウンロードすることができる。

http://ftp.eidos.com/pub/demos/deusex/dxiw_demo.zip

実行環境は，そこそこ高速なものを要求してくるようだ。自分の Athlon XP 2200 と RADEON 9600 の組み合わせでは，ほぼ安定したプレイが楽しめたものの，多少フレームレートが低めとなっているように感じた。まあ，恐らくは，プレイに支障ない程度だろうと思う。

デモ版をプレイしていて厳しく感じたのは，やはりと言うか，言語の壁だ。 "Deus EX" は，見た目こそ FPS であるものの，中身は RPG に近いものとなっている（公式にもジャンルは "RPG" だ）。ストーリーを正しく理解することができないと，プレイは難しいかもしれない。

RPG の中にも，ストーリーが背景の盛り立て役程度でしかないゲームは多くある。そういったゲームならば，正確にストーリーを理解しなくともプレイすることは可能だ（例えば "Diablo" などは，クエストの概要さえ分かっていれば，プレイは難しくない）。しかし，このゲーム "Deus EX" の場合は，複雑な人間関係の織り成すシチュエーションにおいて，主人公の置かれた状況を正しく理解し，そこに自分なりの解決策を見出すことがゲームの目的となっているため，ストーリーを正確に理解できないことには，ゲームを楽しむことはおろか，解き進めることさえ難しくなってしまうと考えられる。

一応 "Datavault" というシステム（設定上では携帯情報端末のようなものらしい）によって，現行のクエストの目的や内容などを確認することができるようになってはいるものの，それでもプレイは難しいと感じた。現にデモ版をプレイしていても，自分の置かれた状況がよく理解できていないばかりに，訳の分からない展開になってしまうことがあった。

デモ版では， Sophia Sak 一味から Sid Black のジェット機を取り戻すところまでがゲームとなっている。ここでは「ジェット機を取り戻す」という目的さえ達成されれば，その手段は何であれ問われない。手荒に行くのが好みならば， Sak とその取り巻きを皆殺しにしてしまうのが良いだろうし，あるいは，友好的に近づいて Sak と直談判に持ち込むこともできる。

とりあえず最も手軽な解決方法は，入り口の警備員を電磁警棒で眠らせしまってから，そのすぐ近くにある警備装置をハッキングし，離陸場にある砲塔の制御を乗っ取ってしまうことだ。付近にある爆発物を破壊すれば，その騒ぎに反応して Sak と側近も飛び出してくる。砲塔の圧倒的な火力をもってすれば，それらを皆殺しにしてしまうことは難しくない。

あるいは，平和的に解決する手段も用意されているようだ。拾い集めた金や，ハッキングによって得た金（ただし，ハッキングを行うには警備員の目を盗まなければならない）を元手としてギャンブルを行い， Sid の借金である 1000 Credits を肩代わりしてやれば，血を流すことなくジェット機を取り戻すことができる。この方法で行く場合は， Sak のビルに忍び込んで，地下闘技場の最強モンスターである "Gob-Zilla" を殺しておくのが重要なポイントだ。そうすれば，４倍のオッズの賭けを確実に手にすることができる。

……と，ここまでの流れも，何回かプレイした後にやっと分かったことであって，一回目のプレイでここまでの状況を理解することは，正直言って難しいと思う。現に最初のプレイなどでは， Sak に挑発的な言葉をぶつけた挙句に，逆上した警備兵にあっさり殺されてしまった。と，まあ，こんな調子だから，英語版を楽しんでプレイするというのは，自分にとって無理な話だろうと思う。前作 "Deus Ex" は日本語版が出ていたようだから，今作も日本語化されることを期待しておこうと思う。

permalink

http://www.uni.torun.pl/~majewski/jakub/mt_cont.html

そう言えば，同ゲームのゲームデザイナである Harvey Smith が，ゲームデザインにおける "emergence" の役割を説いていたのを思い出した。

http://www.planetdeusex.com/witchboy/articles/thefuture.shtm...

この "emergence" という単語は，ゲームデザイン関連の文献を漁っていると，よく目にすることがある。どうやら日本語では「創発」という訳語が当てられているようだ。

http://dictionary.goo.ne.jp/search.php?MT=%C1%CF%C8%AF&kind=...

この「創発」という単語を google で検索にかけてみると，それなりの数がヒットする。

http://www.google.com/search?num=50&hl=ja&q=%22%91n%94%AD%22...

どうやら，人工知能や複雑系の分野などで用いられる専門用語のようだ。ゲームデザインの分野で用いられている「創発」という語も，恐らくはそこから引用されたものなのだろうと思う。

この単語から即座に連想されるのは，映画 "The Lord of the Rings" の CG 制作に用いられた群集シミュレータ "Massive" の存在だ。

http://www.popsci.com/popsci/science/article/0,12543,390918-...

ゲームデザインにおける「創発」の意味については， Justin Love 氏の "Game Design Wiki" の中にある "Emergent Strategies" のページを参照するのが良い。

http://www.ludism.org/gamedesign/EmergentStrategies

この「創発」という概念は，海外のゲームデザイナにとって，デザインの基幹をなすひとつの要素として捉えられているようだ。例えば僕らが「アクション性」とか「パズル性」とか，あるいは「ゲーム性」とかいうような単語によって参照している概念と同列のものとして，この「創発性」が存在するのだろうと思う。

このように，海外のゲームデザイナの間で「創発性」について頻繁に論じられているのは，比較的古い時代から "Sim City" のような「創発性」に注目したゲームが存在したことが原因なのだろうと思う。これが日本の場合だと，「マリオ」や「スト２」のように，「アクション性」に関して極めて高い次元を獲得したゲームが多く存在したため，「アクション性」を基幹とした「遊戯性」への取り組みが大きく花開いているように感じられる。ここは，両者のゲームデザイン文化の持つ違いの一つとして注目することのできる部分かもしれない。

これらの議論によれば，「創発性」がゲームに対してもたらすものとは，ゲームの持つ「可能性空間」 ("possibility space") の拡大だと考えられているようだ。創発性によって実現される多様性がプレイの幅を広げ，プレイヤーに対してより強い探索への欲求を訴えかけることとなる。

しかし，創発性が直に「プレイの幅の拡大」に繋がるとは限らない。また，創発性によって生まれる「バグの可能性の広さ」も，プログラマにとっては無視することのできない点だ。この辺りの事項については，別途にもう少し調べてみたいと考えている。

ところで，お馴染み Jamie Fristrom 氏が，自身のブログに "Deus Ex: Invidible War" の個人的な感想を述べている。そもそもこのゲームのことを思い出したのも，氏のブログが原因だ。

http://gamedevleague.blogspot.com/2004_01_18_gamedevleague_a...

http://gamedevleague.blogspot.com/2004_01_25_gamedevleague_a...

色々と面白い分析だと思う。願わくば，僕も実際にプレイして，ゲーム内容を体験してみたいのだけれど，なにぶん前述のような言語の壁があるだけに，どうにもならないというのが実情だ。

ちょっと気になるのは，前作と比較して平均的な評価が少し落ちていることだ。

http://www.gamerankings.com/htmlpages2/528588.asp

"Half-Life 2" や "Halo 2" が発売延期パターンにハマってしまっている今となっては，この "Deus Ex: Invisible War" と "Max Payne 2" が注目作として浮上してくるのではないかと思っていたのだけれど……どうなんだろう。ここはひとまず，どちらも日本語化を待つことにしようかと思う。悔しいけれど……。

permalink

http://www.pfu.fujitsu.com/hhkeyboard/hhkbpro/index.html

良い品であることは間違い無いのだけれど……やはりこの価格には納得できない。じきに値が下がることを祈って待ちたいと思う。

ソフマップの "CREATORS LAND" では，色々と魅力的な品が魅力的な価格で控えており，思わず食指が動きそうになってしまった。

http://tenpo.sofmap.com/tenpo/shop/tokyo_10.htm

ボロっちい EA-1 と ER-1 が所狭しと積み上げられていたのが印象的だった。３万未満で EA-1 + ER-1 のセットが揃えられるというのは，なかなか美味しい話なのかもしれない。その一方で，最新機種の EMX, ESX はと言えば，さすがにまだ値が下がっていないようだった。

怪しげジャンク屋の "CompuAce" は，こちらも相変わらず，怪しげな妖気をこれでもかと言うくらいに吐いており，色んな意味で楽しい店だった。

http://www.akasoft.com/compuace/index2.html

普通のジャンクハードウェアを山積みにして売っているかと思えば，その裏手では手作り石鹸を売っていたり，インディーズ CD を棚一杯に並べている横には，オカルトっぽい黒魔術系のアクセサリを売っていたりと，混沌とした雰囲気と品揃えの訳の分からなさにかけては，秋葉原の中でも頭ひとつ抜け出た存在となっている。

どうも，店やウェブサイトの雰囲気からうかがうに，以前は「超級電脳」と名乗っていた店と同じ流れのように思えるのだけれど……詳しいことは定かでない。

ここは，日本竜太の CD と，適当なオーディオコネクタを購入して終了。あとは，メッセサンオーでゲームパッドを購入したり，ソフマップで "MGS2 Substance" を購入したりで，今回の秋葉原行は終了した。

今さら "Substance" を購入したのは，「戦国無双」が手に入らなかった腹いせだ。どうやら「戦国」の方は，プレミアムバージョンを僅かに残すばかりで，通常バージョンは全て売り切れてしまっている様子だった。まあ，予想はしていたことなのだけれど……。

それで，問題の "Substance" はと言えば，単純に面白いゲームだ。純粋に「潜入アクションゲーム」として見た場合，本編よりも "Integral" や "Substance" のような「追加バージョン」の方が面白いというのは，もはやこのシリーズの伝統となっているのかもしれない。バリエーションの豊かなミッションを与えられた中で，本編では十分に活かしきることのなかったアクションの数々を，あますことなく楽しめるようになっている。

……と，ずかずかと調子良くプレイを進めていったものの， VR ミッション・スネーク編の「グレネード」の最後で詰まってしまい，そこでプレイを止めてしまった。なんだか知らないけれど，急に難しくなることがあるんだよなあ……解き方を間違えているのかもしれない。ともかく，もう既に価格分は楽しめていると思う。英語版の "Sons of Liberty" も収録されているということだし（恐怖の片面２層ＤＶＤだ！），非常にコストパフォーマンスの良い製品であることには間違いないだろうと思う。

permalink

http://www.messe.gr.jp/chaos/chaosindex.htm

購入したのは Mad Catz 社の "MicroCON" と "RetroCON" だ。

http://www.madcatz.com/MadCatz/product_details.jsp?product_i...

http://www.madcatz.com/MadCatz/product_details.jsp?product_i...

"MicroCON" は，以前から欲しいと思っていたマクロ機能を搭載しているゲームパッドだ。一応，本家 DualShock2 の仕様は全てサポートしており（もちろん感圧ボタンにも対応している），かつ，サイズは DualShock2 よりも一回り小さいものとなっている。この小ささが意外と便利で，使い始めるとすぐに，机の上のスペースが少し広がったような印象を受けた……いや，大袈裟かもしれないけれど，それだけ DualShock ってのは，案外に大きくて重くて，邪魔くさい存在だったりするのだろうと思う。

グリップ部分の裏側にラバー加工が施されているのも，何気に嬉しい仕様かもしれない。この辺りの摩擦係数が少し上げるだけで，机の上からパッドを滑り落としてしまう頻度を低めることができる。

それで，問題のマクロ機能の方はと言えば……まあ，期待通りのものにはなっていると思う。１つ注意点を挙げるとすれば，「キーオフを登録するのに SELECT ボタンを押す」という仕様を見落とさないようにすることぐらいだ。これを知らないと，同じボタンを連続で押す動作を登録できなくなってしまう。

http://www.madcatz.com/MadCatz/product_support.jsp?id=8236&f...

あと，これは個人的に勘違いしていたことなのだけれど， "MicroCON" に連射機能は搭載されていない。てっきり入っているものと思っていただけに，気付いたときにはかなり残念な思いをした。マクロ機能で代替することも不可能ではないものの，利便性に劣る面があることは否めないだろうと思う。

もう一方の "RetroCON" は，完全にノリで購入した製品だ。レトロ感溢れるデザインながらも， DualShock2 の仕様を全てサポートしている（感圧ボタンはもちろん，この形状で振動機能までサポートしている！）という心意気に惚れて購入した次第だ。

実際に使ってみて驚いたのは，その意外な使用感の良さだ。各ボタンのクリック感に問題は無く，スティック操作にも十分なレスポンスを感じる。パッド自体のグリップ感にも問題は無い。やはり裏面はラバー加工されているので，机から滑り落としてしまうことも少ない。もちろん，方向キーは由緒正しい「十字パッド」だ。

また，これは実際に見て驚いたのだけれど，本体のボタン部分が光るというギミックが入っている。

http://mediaviewer.ign.com/ignMediaPage.jsp?media_id=1787540...

この機能に深い意味は無いものの（というか，ほとんど意味が無い），なんだか嬉しい気分になれる機能であることには間違い無い。元がマニア向けの嗜好品であるだけに，このような見た目に訴えかけるフィーチャーの方が，かえって喜ばれるのかもしれないと思う。

唯一難点を挙げるとすれば， "L1/L2" および "R1/R2" ボタンの配置だろうと思う。通常のパッドでは上下に配置されているはずのこれらのボタンが， "RetroCON" では横方向に並べられてしまっている。これはパッドの形状上，仕方のないことなのかもしれないけれど，やはりどうしようもなく違和感を覚えてしまう部分となっている。

あと，メッセサンオーはかなりの高値を吹っかけてくる（オリジナルが $24.99 なのに対して ￥5,800 の値を付けている）ので，購入には多少の注意が必要だろうと思う。まあ，個人輸入を行うよりかは安くつくかもしれないけれど……。

permalink

http://www.nedbatchelder.com/blog/200402.html#e20040210T2221...

http://www.nedbatchelder.com/code/cog/index.html

この "Cog" は，ソースファイルの中に埋め込まれた Python スクリプトを処理し，その出力を生成コードとして元のソースの中に埋め込むという仕組みを持ったコード生成ツールだ。コード生成ツールとしては，ごく基本的な機能を実現したものであると思う。ウェブページに JavaScript を埋め込むような感覚に近いかもしれない。

僕が興味を引かれたのは，それよりも，むしろ氏の挙げたリンクの方だ。氏は，お馴染み C2 Wiki の中にある "Code Generation" のページを参考文献として挙げている。

http://c2.com/cgi/wiki?CodeGeneration

このページからは，コード生成に関連する様々な話題に向けてリンクが張られている。中でも特に面白かったのは， "Code Generation Isa Design Smell" のページにおいて繰り広げられている議論の数々だ。

http://c2.com/cgi/wiki?CodeGenerationIsaDesignSmell

この場合の "smell" は，恐らく悪い意味を持つものだから……「コード生成は悪の香り」と言ったところだろうか。ここでは「コード生成は悪である」という前提のもとに，それを支持する意見や否定する意見など（あるいは脱線気味の意見など），実に様々な意見が交わされている。まったくまとまりの無い混沌とした議論であることには違いないのだけれど，そこには様々な技術者の「視点」が凝縮されており，少なくとも幾らかの参考となる知見が隠されているのではないかと思う。

僕自身は，まだプロジェクトのメイン言語として C を利用していた頃，必要に迫られて止むを得ずコード生成の手段を利用していたことがある。様々な定型処理を Python スクリプトによって生成するという比較的簡単な機構だ。プリプロセサを利用して解決することも可能ではあったものの，無理にマクロを使った方が却ってメンテナンス性を落としてしまうという結論に辿り着いたため，幾らか躊躇しながらもコード生成の手段を選択したという経緯がある。

今は，この時のコード生成と同じことを， C++ のネイティブな機構によって実現している。「実装を共有する」という点において C++ のテンプレートの機構は非常に強力なツールであり，このような用途の需要はほとんどテンプレートによって充足させることが可能だ。ここで思わず「継承によって実装を共有する」という手段を選択してしまうのは，まさに "design smell" かもしれない。単純に合成とテンプレートによって解決できないか考えてみるステップが必要だと思う。

そのようなわけで，僕自身の現在のスタンスは，「コード生成はできうる限り使わない」というものになっている。コード生成は，汎用的なプログラミング言語が抱えている種々の制限を取り払うという点において，非常に強力かつ魅力的な手段であるように感じられるかもしれないけれど，それが「普段から抱いている嫌悪感の解消手段」となっていないかどうか熟考してみる必要があるだろうと思う。それを解消する行為は，多くの場合，本質的な問題の解決とは結びつかないためだ。

何にもまして気を付けなければならないのは，コード生成の機構を用意するという作業は，油断するとすぐに膨らんでしまう性質を持っていることだ。このことには「スクリプト言語の自作」という行為と同じ "smell" を感じる。スクリプト言語を自作することが問題を解決する手段だと信じ，それに手を染めた結果，「スクリプト言語の保守」と「スクリプタへの指導」という非常に重い責任を抱えることとなってしまい，貴重な才能や能力をその見返り以上に費やしてしまう人が，かなり高い頻度で見受けられるように思える。

コード生成に関しても，少しでも汎用性や機能性を求め始めると，「新たな高級言語」を創作する過程へとはまり込んでしまう危険性がある。ゆえに僕は，「コード生成」と「スクリプト言語の自作」とは，ゲーム制作における２つの大きな「落とし穴」として存在するものであると考えている。この場合，「ミイラ取りがミイラになる」とは，言い得て妙かもしれない

一方，コードジェネレータが既存のものであれば，これは極めてリスクの低い手段であると考えることができる。もう既に，どこかのミイラ取りがミイラになってくれているのだから，僕らは目的のものを無傷で手に入れることができるわけだ。これはスクリプト言語についても同様のことが言える。僕が，「スクリプト言語を自作することは悪であるけれど， Lua は悪ではない」と主張する根拠はここにある。

もうひとつ，例外的にコード生成が許容される場面が存在する。クラスや構造体の型情報と連動した処理をコード中に組み込みたい場合だ。これは， C/C++ には「コードが自分自身の構造を知る機能」……つまり，一般に "reflection" と呼ばれているものが欠如しているためであると説明することができる。この問題を解決するには，コード生成がよく役に立つ。

http://c2.com/cgi/wiki?CategoryReflection

http://c2.com/cgi/wiki?ReflectionVsCodeGenerationArticle

このテクニックが必要とされる場面として代表的なものは，データのシリアル化 (serialization) を行う場面だ。構造体をそのままダンプするような原始的なインタフェースならまだしも，少しでも安全にデータとインスタンスの間の結合を行おうとするならば，何らかの手段によって構造体の情報をコードに向けて「反映」させなければならない。そこでコード生成が用いられるというわけだ。

たとえば， DigitalAnvil の "Brute Force" などで利用されたテクニックがこれに相当するのだろうと思う。

http://www.codegeneration.net/tiki-read_article.php?articleI...

と，まあ，このような感じで，コード生成のテクニックとは，常に一定の距離を保ちつつも，これから利用し続けることになるのだろうと思う。

permalink

http://www.codegeneration.net/

このサイトは，書籍 "Code Generation in Action" の著者である Jack Herrington 氏が運営を行っているサイトだ。コード生成の技術に係わる技術者達へのインタビュー記事をはじめとして，コード生成に関連した様々な記事を掲載している。

これらの記事の中には， "The Pragmatic Programmer" で有名な David Thomas 氏へのインタビュー記事もある。

http://www.codegeneration.net/tiki-read_article.php?articleI...

書籍 "The Pragmatic Programmer" （日本では「達人プログラマー」と言う書名で訳されている）は，ソフトウェア開発にまつわる教訓の数々を載せた参考書だ。氏は同書において，コード生成の技術に関しても軽く触れている。その内容を簡潔にまとめるならば，氏が頻繁に持ち出す "DRY (Don't Repeat Yourself) principle" － 「繰り返し禁止の原則」を実践するという目的に基づく限りであれば，コード生成の技術は積極的に用いられるべき，と言うようなものになると思う。

しかし，流石は「達人プログラマー」というか，コード生成の技術に対して必要以上に「のめり込む」べきではないという警告も同時に行われている。例えば同書の中では，自分の理解の及ばないようなコードを吐く「邪悪なウィザード」は利用すべきでないと述べているし，上のインタビュー記事の中でも，インタビュアーの浮き足立ちぶりをなだめるような冷静な発言を繰り返し行っている。

しかし，何と言うか……このインタビュアーの質問は，どれも微妙に的を外してしまっているような感じがする。インタビュアーがコード生成に関して「浮いた」質問を出すたびに， David 氏は「プログラマは特定の技術に依存すべきでない」というような意見を繰り返し述べている。なんともちぐはぐな感じの会話だ。

結論としては，「少ない手間で大きな効果を得られるという保証があるならば，コード生成を利用すべき」ということになるのではないかと思う。この場合，氏がスクリプト言語 Ruby の愛好家であるというのは，なかなか面白い事実かもしれない（氏は書籍 "Programmming Ruby" の著者としても有名な人物だ）。 Ruby や Python, Perl などのように，テキスト処理に適したスクリプト言語を利用すれば，簡単なコードジェネレータを用意するのに手間はほとんど必要とされない。そのような規模に収まる限りは，安全にコード生成を利用することができるのではないかと思う。

permalink

http://www.bradsoft.com/feeddemon/

昨今のブログブームを反映してか，現状での RSS リーダーのラインナップは非常に豊富なものとなっており，その中にはフリーで配布されているものも数多く存在する。しかし，実際にフリーソフトと商用ソフトの品質を比較してみると，その差は歴然なものとなっているように思える。恐らく，「ブログと RSS フィード」という組み合わせ自体が，比較的歴史の浅い文化であるために，成熟されたフリーソフトが未だ登場するに至っていないのではないかと思う。

この "FeedDemon" は，商用の RSS リーダの中でも，かなり評判の良い部類に入るソフトウェアのようだ。この洗練されたインタフェースと充実した機能，安定した動作などに一度慣れてしまうと，もはや他のソフトに後戻りすることは難しい。さすがに売り物だけあってしっかり作ってあるものだと思う。

先日の Ned Batchelder 氏のブログに出ていた小ネタが面白かった。

http://www.nedbatchelder.com/blog/200402.html#e20040214T1031...

特に興味を引かれたのが， Bob Congdon 氏のブログ内の記事 "Decompression bombs" へのリンクだ。

http://www.bobcongdon.net/blog/2004_02_01_congdon_archive.ht...

この "decompression bomb" とは，多重に圧縮の施された超巨大ファイルを送りつけることによって，受け手のソフトウェアを攻撃することができるというものだ。詳しい情報については下の AERAsec の解説が参考となる。

http://www.aerasec.de/security/advisories/decompression-bomb...

この解説によれば， "0" キャラクタによって埋め尽くされた 100 GB の超巨大ファイルに対して gzip を３回繰り返して施すと，そのサイズは 5928 バイトにまで減少するということだ。すると，展開前と展開後のファイルサイズの比率は，実に 1800 万倍にも達することになる。これが様々なアプリケーションに対して不都合をもたらすであろうことは，決して想像に難くない。

gzip を多重に施すことによって圧縮が効くという話は聞いたことが無かったので，手元の環境で実際に試してみた。 "0" キャラクタを並べて作成した 128MB のファイルに対して gzip を施すと，これは 127kB にまで減少する。この圧縮済みのファイルに対してもう一度 gzip を施すと，今度は 466 バイトにまで減少した。なるほど，こういうことか……。

この「圧縮ファイル爆弾」の持つユニークな特徴は，ウィルススキャナに対して攻撃力を持ちうると言う点だ。圧縮ファイルを展開してウィルスのチェックを行おうとすると，展開を行う時点で過負荷状態へと陥ってしまい，最終的にクラッシュを引き起こしてしまうわけだ。上の AERAsec の報告によれば， Network Associates の "McAfee Virus Scan" などが，この「圧縮ファイル爆弾」に対して脆弱性を抱えていると指摘されている。

脆弱性と言えば，先日， Raymond Chen 氏のブログ "The Old New Thing" において，整数演算のオーバーフローを利用したアタック手法が紹介されていた。

http://weblogs.asp.net/oldnewthing/archive/2004/01/29/64389....

件の記事には，次のようなコードが例示されている。

ここで例えば， allocate_myclass 関数の引数 howmany に対して "0x400001" のように非常に大きな数が渡されたとする。すると，実際にメモリアロケータに渡される要求サイズは 0x400001 * sizeof(MyClass) = 0x100000400 となるのだけれど，実際には最上位のビットが桁あふれを起こしてしまうため，結局 0x400 = 1024 バイトしか確保されないという事態が発生してしまう。もちろん，それでもコンストラクタは 0x400001 個分呼ばれてしまうため，通常ならばこれはクラッシュへと直結する。

まあ，メモリ保護例外によってハングアップするだけならばともかく，これが new ではなく，スタック上のオブジェクトの確保（任意長配列のスタック変数の確保など）であった場合は，かなり危険かもしれない。それによって，スタックの付近を汚すことが可能となるからだ。クラスメンバの構成とコンストラクタの内容次第では，そこからリターンアドレスを書き換えて exploit に持ち込むことも可能であるかもしれない。

http://linux.ascii24.com/linux/linuxcom/2000/06/13/465216-00...

単純な文字列バッファオーバーフローの exploit テクニックと比較すると，かなり難しい条件ではあるものの，可能性が存在しないわけではないと思う。それに，このような攻撃に対して耐性を持っていないソフトウェアはごまんと存在するはずだ。そこが，このアタック手法の意味を高めているように思える。

permalink

http://www.joltcola.com/

眠気覚ましとしてのカフェインの効力は，日本よりもアメリカの方が強く信じられているようだ。 "Bawls" のようなカフェイン飲料をはじめとして， "Penguin Mints" のようなカフェイン入りタブレット菓子などが多く存在する。

http://www.thinkgeek.com/caffeine/

しまいには「カフェイン入りボディーソープ」まで登場してしまう始末だ。

http://www.thinkgeek.com/caffeine/accessories/5a65/

こうした刺激物に頼ることなく眠気を覚ます最も簡単な方法は，隣の人と軽くお喋りを交わすことだと思う。また，これは，作業に行き詰まりを感じたときの気分転換としても良い方法だと思う。プログラミングの作業を行っている間は，自らの内面に閉じこもってしまうことが多く，そこから偏向的な思考や独善的な判断が生まれてしまうことがあるように思える。そこで自分を外面へと引き戻すことが，思考をニュートラルな方向へと修正する効力を持っているというわけだ。

こうしたコミュニケーションの利用は，職場の環境によっては当たり前のことなのかもしれないけれど，高いパーティションによって区切られた環境では，なかなか実現の難しいものとなっているように思える。ましてや， Microsoft 本社のように１人あたりに１部屋を与えられる環境などでは，会社に来ていても鬱状態にハマってしまう人が出てきてしまうのではないかと思う。

".NET Undocumented" の Wesner Moise 氏が，なんとなく関連のあるような無いような話をしていた。

http://wesnerm.blogs.com/net_undocumented/2003/09/asperger_s...

このポストにおいて氏は，自身がアスペルガー症候群 (Asperger Syndrome) と診断されたことを明かしている。軽度の鬱病のために精神科で診断を受けたところ，その症候を指摘されたということだ。「アスペルガー症候群」とは，僕は聞いたことの無い言葉だったのだけれど，どうやら軽度の自閉症として扱われているもののようだ。

http://www.google.co.jp/search?num=50&hl=ja&inlang=ja&q=%83A...

関連する幾つかの記事を見てみると，アスペルガー症候群を持っている人々は，社交性にある種の困難を伴っているものの，限定された分野に対して秀でた能力を発揮することがあるとされている。映画「レインマン」に登場するキャラクタ「レイモンド」を連想してみると良いかもしれない。また，知能テストでは常にトップレベルであったという Moise 氏がその例であることは間違いないだろうし，かの Bill Gates 氏もその１人であると指摘されることがあるようだ。

http://wesnerm.blogs.com/net_undocumented/2004/02/rise_of_as...

もうひとつ興味を引かれたのは，氏が自身を Myers-Briggs における "INTJ" タイプであると述べていることだ。 "Myers-Briggs" とは "Myers-Briggs Type Indication" (MBTI) とも呼ばれているものであり，ユングの類型論 (Typology) を基にした性格分析方法の一種であるようだ。

http://www.google.co.jp/search?num=50&hl=ja&inlang=ja&q=mbti

この MBTI では，４つのベクトルを基にして，その人の持つ性格を１６種類の「型」へと分類するという方法をとっている。簡単な質問によって分析を行うページが存在するので，ちょっとした心理テストのつもりで試してみると面白いかもしれない。

http://www.humanmetrics.com/cgi-win/JTypes1.htm

僕自身が試しにやってみたところ "ISTP" との結果が出た。つまり「内向的，感性的（非直観的），思考的（非感情的），知覚的（非判断的）」ということだ。解説のページを開いてみると "The Crafters" と書かれている。つまり，感覚と経験を重視する傾向から，職人的な資質が見出されるという指摘のようだ。

http://209.15.29.56/myersbriggs/istp.htm

たった７２個の設問から人間の性格を正しく分析できるはずなど無いのだから，本当に占い程度に受け取っておくのが良いだろうと思う。ただ，数種類のベクトルから性格を分類するというアイデアは面白いと思う。 Moise 氏によれば， Microsoft の技術者には xNTJ 型が多いということのようだ。

http://wesnerm.blogs.com/net_undocumented/2003/09/intj.html

permalink

http://wesnerm.blogs.com/net_undocumented/2004/01/can_you_fi...

この種の話題に関しては，現役の Microsoft 社員からも挙げられていることがあるのだけれど，それらは多くの場合において（特に，コンピュータとは関係の無い人から発された話題の場合），あまり良い気分のする話題とはならないようだ。

http://headblender.com/joe/blog/archives/microsoft/001309.ht...

http://blogs.msdn.com/ericlippert/archive/2004/01/13/58420.a...

Moise 氏は現在 MBA の課程を受けており，そこで氏のキャリアが話題となることがあると語っている。まあ， MBA の学位を取得しようと言うほどビジネスに関心を持つ人ならば， Microsoft に対して何らかの特殊な興味を持っていたとしても，それは無理もないことなのかもしれない。

しかし僕も，ビル・ゲイツの人物像なんて話題には，つい興味を引かれてしまう。氏は社員にとってどんな存在なんだろう？

案外普通の「鬼教官」タイプのリーダーなんだなあ，と思う。意外なことに，バルマーの方がよほど柔らかい人物であるようだ。

それと，こんな質問も挙げられている。

permalink

http://weblogs.asp.net/oldnewthing/archive/2004/02/18/75652....

「なぜ矩形領域の指定には右端と下端の辺が含まれないのか？」という話を扱ったものだ。まあ，この話の内容はともかくとして，氏の挙げている Alvy Ray 氏のページが面白かった。

http://alvyray.com/Memos/MemosMicrosoft.htm

これらの文書は， Ray 氏が Microsoft にフェローとして在籍していた間に書き溜めたメモであるようだ。今は全てフリーで公開されている。件のポストからリンクされているのは "A Pixel Is Not A Little Square, A Pixel Is Not A Little Square, A Pixel Is Not A Little Square! (And a Voxel is Not a Little Cube)" という文書だ。

ftp://ftp.alvyray.com/Acrobat/6_Pixel.pdf

まあ，なんともおかしな題名なんだけれど……要するに言わんとしているのは，「ピクセルは決して『箱』ではない」ということだ。

この文書における Ray 氏の主張をかいつまんでまとめるならば，「ピクセルとは『サンプル点』である」というものだ。まあ，そこから先はよくある話で，サンプリング定理が云々とかいう話に持ち込まれる。サンプリング定理に基づいて理屈を再構築しようという発想は，この前に読んだ "High-Degree Temporal Antialiasing" と似ているかもしれない。

http://citeseer.nj.nec.com/dachille00highdegree.html

サンプリング（標本化）のプロセスの復習には， Oliver Kreylos 氏の "Sampling Theory 101" が手っ取り早くて良い。僕は何故か，この辺りの基礎を学校で習った記憶が無く（情報系の学科では必須の項目だと思うのだけれど……），度々忘れてしまっては，この文書を引っ張り出しているような状態だ。

http://graphics.cs.ucdavis.edu/~okreylos/PhDStudies/Winter20...

このような発想に基づくならば，「ピクセルは小さな正方形である」という認識は，すなわち再構築フィルタとして矩形フィルタを利用することに相当する。これは，矩形フィルタが「最も貧弱なフィルタの１つ」として評されていることからも分かるように，あまり好ましく無いプロセスだ。氏は代わりに，もう少し範囲の大きいガウスフィルタや３次フィルタ，あるいは windowed sinc フィルタなどのようなものを想定するのが妥当なプロセスであると主張している。

このような Ray 氏の主張は，「ピクセル」という概念に対して認識を深めるという意味では面白い内容であるものの，実践的な内容であるとは言い難い面があるかなと思う。氏の主張はあくまでも仮想的なモデルに基づいており，実際の表示装置の持つ物理的な特性には基づいていない……と指摘しているのは， Craig S. Bruce 氏による意見だ。

http://www.csbruce.com/~csbruce/cynic/pixel.html

例えば，昨今の LCD によって表示されるピクセルなどは，極めて正方形に近い形状を持っているのではないかと思う。それに最近の表示装置は，サンプリング周波数が云々とか言う以前に，十分に高い解像度を保持している。結局のところ， Ray 氏の主張する「ピクセルとはサンプル点である」という認識は，理屈としては意味を持つものの，回りまわって「ピクセルとは正方形である」という結論に辿り着くのではないかと思う。

permalink

http://www.python.org/~jeremy/weblog/040115.html

これは， vector コンテナクラス － つまり可変長配列構造を扱う場合に，配列をどのような比率で拡張して行くべきか，という話題を扱ったものだ。ちなみに STL の仕様としては，この「延び率」は特に定められておらず，ただ現在の capacity の値に比例すべきであると勧めるに留まっている。

http://www.sgi.com/tech/stl/Vector.html

STL の「元祖」であるところの Hewlett-Packard の実装では，この「延び率」は２倍に設定されているようだし， GCC の libstdc++ も同じ値を利用しているようだった。確認はしていないけれど， STLport も同様だったと記憶している。

ここで件の記事は， comp.lang.c++ にポストされた Andrew Koenig 氏の文書にリンクを張っている。

http://groups.google.com/groups?q=g:thl3230843302d&selm=FUbq...

ちなみに，この Koenig 氏は "Accelerated C++" や "Ruminations on C++" の著者として有名な人物であり，現在は ISO による C++ 標準化の作業にも携わっている。

このスレッドは元々， Scott Meyers 氏（こちらは "Effective C++" の著者だ）が， Visual C++ 7.0 の STL が「延び率」として 1.5 という値を使用していることに疑問を持った所から始められている。その疑問に対して Koenig 氏は，この「延び率」は「黄金比」よりも小さな値に設定されるべきであると指摘している。そこから "2" ではなく "1.5" を選んだのだろうと推測しているわけだ。

vector のような可変長配列構造では，配列の要素が足りなくなると，「延び率」によって拡張された領域を確保し，そこへ古い配列の内容をコピーしてから，古い配列を解放するという手順を踏む。解放された古い領域はメモリの「断片」として残り，配列の拡張が行われる度に蓄積されることになるのだけれど，もし，拡張された領域のサイズが，この「断片」を合計したサイズよりも小さくなれば，「断片」の再利用が生じるはずだ。逆にこの「再利用」が発生しないと，配列は延々と新しい領域を確保し続け，メモリを一方的に消費してしまうこととなる。

では，この「断片の再利用」が生じる条件とは何なのだろうか……それが，「延び率を黄金比よりも小さくすること」であるということだ。これは恐らく，黄金比とフィボナッチ数列の関連性から導くことができるのだと思うのだけれど，色々考えているうちに時間切れとなってしまった（もう寝なければ！）。

http://mathworld.wolfram.com/GoldenRatio.html

http://jwilson.coe.uga.edu/emt669/Student.Folders/Frietag.Ma...

http://gakuen.gifu-net.ed.jp/~contents/museum/golden/page62....

黄金比は，単に美術的な意味を持つだけでなく，数学的にも色々と面白い特徴を持つ数だ。それゆえに，思いがけない所に黄金比が隠されていることがあるように思える。メモリアロケータの定数として黄金比を用いるなんてのは，まさにその「思いがけない」例のひとつとして挙げられるかもしれない。

ただし，実際のメモリアロケータは，よほど簡易的なものでもない限り，先頭一致方式を利用することはないため（例えば Doug Lea のアロケータなどは，もう少し賢いアルゴリズムを利用している），実際には黄金比にこだわる必然性はそれほど無いだろうと思う。件のポストの本題である Python の可変長配列も，特に黄金比にこだわっているということは無いようだ。

ともかく，可変長配列の延び率として "2" ではなく "1.5" を使用するという選択には，今回の話も含めて，それなりの意味が存在するということだ。自作の可変長配列コンテナなどを作成する場合には，考慮に入れておくと良いのではないかと思う。

permalink