良いもの。悪いもの。

今年は2012年です。 bool leap_year(int y) { return !(y%4)^!(y%100)^!(y%400); } そして、 leap_year(2012) が真となるので閏年です。平年と比べて一日増えるわけですが、その一日たりとも無駄にしない充実した一年にしたいと思います。 本年もどうぞ宜しくお願い申し上げます。

現在のオフィスでは、エントランスからどの通路を通るのが最も近いのか、未だに話題になることがある。エントランスからオフィスにつながるエレベータまでの道が二通りあり、どちらも似たような距離なので同じオフィスに行く人達なのにそこで別々になってしまうこともしばしば。左の図が問題のフロアなんだけど、エントランスから青丸で示したエレベータまで行く必要がある。だったらコンピュータに解かせてしまえばいいじゃない、ということでプログラムを作って最短経路と正確な距離を調べてみた。定規で測ったほうが早いという意見は聞こえません。 以前、 Python: 画像で与えられた迷路に対し2点間の最短経路を求める というブログ記事で、画像から直接最短距離を求めるプログラムを書いたことがあるので、まずはそれを使って調べてみた。図面の邪魔な文字だけ消して、あとはスタート地点とゴール地点の座標を引数で指定するだけだから簡単なんだけど、これだと問題があることに気がついた。というのはCCL (connected component labeling; 連結成分ラベリング)で移動できる領域を調べて、それをA*で解いているのだけど、隣接するノード(ピクセル)を上下左右斜めの8方向のみで調べているから正しい距離を出すことができないのだ。実際に作成した図は以下のようにギザギザになってしまい最短ルートを通らない。なので通り道の分岐や方向が変化する箇所をノードにしてそれをA*で求めることにした。 全部で10個のノード(画像のピクセル座標で指定)を作って調べたところ、以下のような結果になった。左側を通る通路の距離が324.53、右側を通る通路の距離が322.51となり僅かに右側の通路のほうが近かった。ただし、右側の方は途中でフロア案内と少し重なるし、6つあるエレベータのどれを使うかによっても結果が変わってしまうぐらいなので、実質的には同じ距離といってしまっても差し支えないと思う。 結局、それぞれの距離にはほとんど差がないので、結論としては「好きな方を使え」ということになるだろう。自分は広い通路の方が好みなので右側の通路を利用している。最後にソースコードとその使い方を示しておく。 nodes.datに、一行を"ピクセルX座標 ピクセルY座標 隣接ノード番号リスト"としてノード数の...

昨年は開発エンジニアが転職するという話題が多かったように思う。それに触発されたというわけではないが、自分も昨年11月に開発エンジニアとして転職した。そしてつい先日、試用期間の3ヶ月が過ぎた。これで何かが変わったというわけではないが、正式に採用されたということで、転職して思うことなどをブログに書くことにした。転職先については敢えて名前を出さないが、主にマルチコアやGPGPUなどの並列処理を扱うベンチャー企業といえばピンとくる人もいるかも知れない。 自分はこれまでずっとアカデミックな研究所に所属していたのだけど、少々居座りすぎてしまったことは否めない。基本的に研究者は流動的であることが推奨される。そして、所属していた研究所は所長でさえも任期制で、研究員は普段から職探しをするのが当たり前になっている。しかし、アカデミックなポストは空きも少なく、枠が一人のところに100人200人と応募してくることはザラで、終身雇用の職を得るのはかなり難しい。 そんな中、自分はほとんど職探しをしていなかった。第一の理由として、自分が専攻した薬学の分野でバリバリとコードを書くことと研究が両立できるか疑問だったことがある。ただでさえ狭き枠にそのような特殊な環境を求めるのが非常に厳しいものに思えたからだ。第二の理由として、所属していた研究所ではメインでHPCを扱っており薬学に関連した研究を遂行するためのプログラムを自由に書くことができ、それが求められていたことがある。相手の要求と自分の希望が合致していた。 そうは言っても、ここ最近の政治的判断による不透明さや年齢に伴うマネージメントの必要性など、当たり前だが要求は厳しくなってくる。また、地理的な面でも大きく変わることになったし、こちらの事情で現在の住処を離れたくないということもあった。研究所で一緒に仕事をしていた人たちには大変お世話になっていたので少々迷うところもあったのだが、最終的に転職することにした。 自分の仕事選びの基準は単純で「楽しめるかどうか」だけだ。楽しめればどんなにきつい仕事でも苦にならないし、逆にきつければきついほどチャレンジングであり、やりがいを感じられる。特に開発エンジニアの方なら、自分の技術で困難な問題を克服する達成感、創造する喜び、知識を得る楽しみなどについて分かってもらえるのではないかと思う。それに、企業と...

明けましておめでとうございます。 今年は2011年で素数。前回の素数の年は8年前の2003年、次の素数の年は6年後の2017年。だからどうと言うわけでもないのだけど、なんとなく特別な年であるように思えてくる。昨年は自分にとっては大きな節目の年であった。環境も大きく変わって、なんちゃってプログラマから「なんちゃって」を外すことができたのではないかと思う。そして今年は、どんな数にも割り込まれず自分自身を失わない2011年のように、自らの意志をしっかり持って行動する年にしたい。 ところで、冒頭のQRコードだけど、いつものように Android SL4A のソースコードになっている。SL4Aを起動して、メニューからAddを選択し、Scan Barcodeで取り込むと new_year.py が作られる。大したコードではないのだけど、当ブログからのメッセージが入っている。音が出るので注意。 これからもどうぞよろしくお願いします。

小学3年生の娘の日曜授業参観に行ってきた。算数の授業だ。授業の後半、以下のような問題が出された。 問題 : ゴマダラチョウとトノサマバッタがあるゲームをしている。0から9までの数字の書かれたカードがそれぞれ一枚ずつ全部で10枚あって、それを使って3桁の数を2つ作り、その差をできるだけ小さくした方が勝ちとなるゲームだ。ただし百の位は0にできない。できるだけ小さくするにはどのようにカードを選べばよいだろうか。 これを約30人の生徒に考えさせていた。解き方を先に教えるということはしない。生徒が問題を考えている間、先生は生徒たちを見回り、質問などに答える。しばらくするといろいろと答えが挙がってきた。自分の娘は以下のように考えたようだ。 百の位は差が1であればどの数字でも良いので、まず十の位を最小にする数字を考えてみると、最小の数字0から最大の数字9を引いた場合が最も小さくなる。同様に一の位では0と9以外の最小・最大の数字を選ぶ。つまり1から8を引いた場合が最小になる。百の位は残りの数字カードから差が1となるものを選ぶ。解答例は「501-498」や「701-698」となり、差は3になる。 これはまさにアルゴリズムだ。Pythonであれば以下のコードと同じだろう。 digits = range(10) ten = (digits.pop(), digits.pop(0)) one = (digits.pop(), digits.pop(0)) idx = random.randrange(len(digits) - 1) hund = (digits.pop(idx), digits.pop(idx)) a = reduce(lambda x, y: x * 10 + y, map(array, (hund, ten, one))) print "%d - %d = %d" % (a[1], a[0], a[1] - a[0]) 出力例: 601 - 598 = 3 小学3年生の算数だと思ってそれほど期待せずに観に行ったのだが、生徒たちはみな楽しそうに問題に取り組んでいたし、なかなか面白い授業をしているようで何だか安心した。因みに、今回のようなクラス全員で考える問題は普段からよく行っているとのことだった。

明けましておめでとうございます。 今年でこのブログも4年目になるなぁ。早いものだ。自分が初めてインターネットに触れたのが1994年で、それ以前はNIFTY-ServeやPC-VAN、草の根BBSなど利用していた。インターネットを利用し始めたころはメールアドレスを持っていても周りが誰も使っていなかったので全くの無用の長物だった。その頃、みんなが電子メールを持つようになれば素晴らしい世界になるのにと考えたものだが、それから数年でその「素晴らしい世界」になったわけだ。 自分のウェブサイトを作ったのが1996年から、ブログを書き始めたのは2000年2月14日からだけど、最初の頃はHTMLを直接編集していた。その後、Movable Typeに移行してしばらく使っていた。それからいくつかのサイトやブログなどに手を出し、科学情報ばかりを扱った「科学随想録」や以前ハマったMMOのEverQuestのギルド用フォーラムを作成したりしつつ、今の「良いもの。悪いもの。」に落ち着いた。 このブログはプログラミング関連情報をメインとして扱っているけど、昨年は、Google Wave、Android、Twitter、mixiアプリなどが興味深かったな。今年はどんな技術が出てくるんだろう。今からワクワクする。ブログ記事は自分が楽しめるものを書く、書きたい時が書き時というスタンスだけど、他の人にも楽しんでもらえるとしたら嬉しい。因みに自分のプログラミングスタイルの変遷は「 プログラミングができるということは、人生を楽にできるということ 」に書いてある。 これからもどうぞよろしくお願いします。

先日の事業仕分けによる次世代スーパーコンピュータ(次世代スパコン)の予算見直しで事実上の「凍結」との結論が出たことで、多くの人々から次世代スパコンについて注目が集まることになったが、情報不足のためか、一部誤解があるようだ。そこで、自分の知っている範囲で次世代スパコンについて記したいと思う。もし自分の知識が至らず間違っている場合は指摘して頂けると有り難い。 次世代スーパーコンピュータ 次世代スパコン は富士通のCPU、 "Vinus" SPARC64 VIIIfx か、その後継CPUで構成する公算が高いが、このCPUはスカラ型だ。もともと、NECと日立がベクトル型のCPUを開発する予定であったが、撤退によりベクトル型とスカラ型の混成システムから、スカラ型のみのシステムに変更された。因みに、この富士通のCPU "Vinus"は現時点で世界最高速のCPUであり、国産で高速なCPUを開発できるのかという疑問も払拭できている。 ところで、この撤退により次世代スーパーコンピュータ開発について危惧する声が出たのだが、実のところ次世代スパコン開発に関わるユーザや開発者の一部では、開発がしやすくなったとして喜んでいたりする。もともとの混成システムでは、 実用的に使う場合 、ベクタ部はベクタ部のみの利用、スカラ部ではスカラ部のみの利用でしかパフォーマンスが出せず、これでベクタ部とスカラ部を一台に入れる意味があるのかというもっともな疑問が出ていたようだ。また、次世代スーパーコンピュータ開発実施本部のプロジェクトリーダーである渡辺氏がNEC出身であることからのあらぬ疑いもされずに済むようになったと思う。 NECと日立が撤退した理由として、 百数十億円の負担が重荷になった と答えている。しかし、実際はそんな負担額では済まなかったというのが関係者間での通説だ。つまり、それ以上の巨額の開発資金を企業は自腹で負担しなくてはならなかったのだ。では何故そのような負担をしてまでも次世代スパコンに参加したかったのか。それは「世界一高速なコンピュータを作りました」という事実が企業にとって非常に大きな宣伝になるから。世間一般ではそれで世界一の技術があると見なしてくれるのだ。それに、売り上げももちろん重要だが、技術者の士気も上がることのメリットが大きい。技...

どのようにプログラマになったのか知るのは面白く、興味深い。そして、プログラミングに対するの様々な考え方や捉え方を知り、それを自分の知識に加えるのが楽しい。そこで自分自身がどのようにしてプログラミングを学んできたのか、そしてプログラミングについてどのように考えているのか述べたいと思う。たいした内容でもないが書いているうちに長文になってしまった。取り敢えず概要だけを知りたい方は、それぞれの段落の最初の文章を読めば何となく分かると思う。 最初のプログラミング 初めて触れたPCは、父親が購入したNECのPC-8801mkIIだった。当時のPCには最初からBASIC(N88-BASIC)が付属しており、これを使って手軽にプログラミングができた。ただ、BASICはインタプリタであり、当時のPCの性能と相まって処理速度が非常に遅く、高速化のためにはアセンブラが必要だった。そこで、父親の書籍を漁りつつ、ニーモニックをハンドアセンブルでマシン語に変換したりもした。 しかしながら、BASICのプログラミングですら当時の自分にとってはとても難しく感じた。その頃読んでいたマイコンBASICマガジンに載っていたプログラムのようなコンパクトでエレガントなコードに比べ、自分のコードはなんて拙くて汚いのだろうと何度も思ったものだ。結局、プログラミングはセンスがある人だけのもので、自分には無理なのだろうかとさえ考えた。あるアイデアがあっても、それを思ったようにコードに落とせないのだ。毎回リファレンスとのにらめっこになる。それでも何とか書き上げたコードは不必要に肥大であり、分かりにくく、あちこちからバグが顔を出していた。 それでも、不細工だろうが何だろうが、プログラムが完成するのはとても嬉しいことだった。自分の力でゼロから何かを作り上げるという行為は本当に楽しかった。後に気が付いたことだが、プログラミングはセンスなんかよりも、この「楽しい」という気持ちの方がよほど重要だったのだ。センスがあっても楽しくなければ長くは続かないだろうし、楽しいと思っているのならば小さな積み重ねが経験となり、知識となっていく。 ただ、その当時はプログラミングばかりをしていたわけではなかった。PCゲームにもはまっていた。オールマシン語が売り文句の一つだった頃だ。そして、その頃のゲームソフトは個人もしくは少数...

プログラミングをしているときに一つ気になることがある。それはPCから出るノイズだ。特に自分は職場でも自宅でも周りを数台のPCに囲まれているのでその音も馬鹿にならない。聞いているうちに何となく慣れてしまうのだが、常に耳に届くノイズは少なからずストレスになっているような気もするのだ。それもあって、ノイズキャンセリングヘッドフォンは複数所有している。 最近、デジタルノイズキャンセリング機能を有したSonyのウォークマンNW-X1060が発売されたことを知った。フラグシップモデルらしい。高性能ノイズキャンセリング機能と聞くと食指が動く。しかも、無音のままノイズキャンセリング機能だけを働かせることができるらしい。今回もそれが大きな動機となって購入してしまった。 所有しているノイズキャンセリングヘッドフォンは、BOSEのQuietComfort2、SennheiserのPXC300、SonyのMDR-NC22など。ほかにも安物のノイズキャンセリングヘッドホンがあったりする。今回はデジタルノイズキャンセリングと云うこともあり、それらと比べてもなかなかの性能を発揮しているようだ。自分の周りのPC環境で使うと、それまでうるさかったノイズがすぅーっと消えるのが心地よい。 コーディングしているときに使ってみたが、音質が良く、長時間の使用でも聴き疲れがないのがいい。今までのものは耳が疲れてしまってコーディングなどの作業に集中ができなくなったりしたが、今回のものは疲れにくいようだ。それと、電車通勤時に動画を視聴するのにも便利。画面は小さいけどね。でも、かさばらないし、有機ELなので画質はかなり良い。 欠点としては、やはり付属のソフトウェア(SonicStage)が使いにくいことと、本体にストラップがつけられないので胸ポケットなどに入れて使うしかないこと。別売りの専用ケースを使えば良いそうだが、このぐらいは初めから付けて欲しかった。SonicStageは相変わらずだ。ソフトウェアの使い勝手が良くなるだけでだいぶ印象も変わるだろうに。NW-X1060自体の使い勝手はまあこんなものか? 特に比較する対象も持っていないので何ともいえない。 結論としては、思ったよりも音が良く、聴き疲れもしないし、デジタルノイズキャンセリングも効果があり、購入して良かったという感想。まあ、音の聞こ...

平成の世も既に20年以上が過ぎた。名作、駄作と呼ばれる様々なゲームをプレイしてきたが、初めてウィザードリィをプレイしたときの感動を今になって得られるとは思いもしなかった。 PS3のゲームソフト、 デモンズソウル(Demon's Souls) はまさに末弥純(すえみじゅん)の描いたウィザードリィ(Wizardry)の世界そのままだ。初代ウィザードリィをプレイしてその面白さに虜になった自分だが、生粋のウィザードリィフリークでもある 末弥純のイラスト はまさにその世界を的確に表現している。 そんな末弥純の世界を生きているかのように錯覚させるデモンズソウルだが、このゲームは本当に面白いと思う。メーカー側が事前にほとんど宣伝していなかったにもかかわらず、初週売り上げ4万本で消化率9割超だそうだ。メーカー側も在庫を切らすほど。因みに消化率と云うのは店に卸した本数に対して実際売れた本数のことで、それが9割超というのはほとんどの店で売り切れている異常事態だそうだ。つまり口コミでそれだけ売れるほどデキが良いのだ。まあ、実際のゲームレビューや感想は amazonのレビュー でも見てもらったほうが早いだろう。 甲冑の擦れ、軋む音、剣先があたる鋭い金属音、何かが這いずる鈍い音、遠くから聞こえる人の声、物の落ちる音、悲鳴や哄笑、等々。これらはただのBGMではない。すべての音には理由がある。デモンズソウルは、世界が息づいていることを実感できる得がたいゲームの一つだ。

本年もよろしくお願い申し上げます。

大学の実習で学生にプログラミングを教えているのだが、C言語などでプログラムを書かせるとほとんどの人がインデント(字下げ)をでたらめに入れる。これは何故だろう。 教えている学生は2年生なのだが、1年生で既に講義で習っているはずなのに。自分ならインデントを揃えないと読みづらくてやっていられなくなるが、インデントをでたらめに書く人はそれを苦労とは思わないのだろうか。インデントの意味を教えてもキツネにつままれたような顔して、それが重要であると考えてくれないようなのだ。それならばと放っておくと括弧が足りなくてコンパイルエラー、条件文のスコープが分からなくなって四苦八苦、関数を終わらせずに次の関数を書き始める等々、奇妙奇天烈なコードを書いてくれる。で、最後には分からなくなったので教えて欲しいと言ってきて、インデントがでたらめなコードを自分が読む羽目になるのだ。 プログラムを書くなら、文法などよりもまずインデントの重要性を知る必要があると思う。…と考えるとやっぱりPythonはプログラミングを習い始めるのに良い言語のように思うなぁ。

11月はほとんどブログを更新しなかったな。11月最後のリトルビッグプラネットの記事も以前に書いていたものをアップロードしていなかっただけだし。一番の原因は風邪で体調を崩したことかなぁ。この時期はいつも体調が悪い気がする。仕事の掛け持ちやらで疲れているところに、周りに風邪引きが増えてそれを貰ってしまうという悪循環。一度体調を崩すと気力が削られて様々な「やる気」が萎えてしまうのだ。 体調が悪かったり、仕事がちょっと忙しかったのもあるけど、ブログの更新が滞った別の理由としては面白いゲームが出ていたってのもあるな。ブログ更新の優先度はそれほど高くない、というか一番低い位置にあるので他にやることができてしまうととたんに更新が滞ってしまう。プログラミング関連だと趣味や仕事とも共有できて、ブログネタにもなるんだけど、ゲームだとねぇ。まあ需要があればプレイ日記を書いてもいいのだけど。個人的には他の人のゲームプレイ日記を読むのは好きだし。 因みに11月中に、PS3ではリトルビッグプラネットとWipEout HD、PSPではパタポン2と勇者のくせになまいきだor2をプレイした。この四つのうち主にプレイしたのはリトルビッグプラネットとパタポン2で、どっちもかなり面白いよ。残りの二つも面白いのだけどプレイする時間がなかっただけ。PlayStation Homeの大規模βテストにも当選したけど時間がなくて一回起動しただけだな。 12月は時間と体調の管理に気をつけたい。

2D物理演算ソフトウェアの Phun は楽しい。Phunと云う名前自体が、Physics(物理)+Fun(楽しむ)の造語であり、名が体を見事に表している。 物理演算と聞くとなにやら難しそうだが、このPhunは少しも難しくない。もちろん壮大な設計図のもと、緻密で複雑な機械を作ろうとすれば大変だろうが、とりあえず四角や丸の置物、バネや水を出してみたりといったことはマウス操作でちょちょいのちょいだ。3歳の子供だってできるのだから誰にだってできるだろう。 まずはここに掲載されている Phunの動画 を見て欲しい。ちょっとばかり楽しい気分になれる。因みに自分は リトルビッグプラネット のβテストが終わってしまったので、発売日までそれに代わる類似ソフトを探していたところPhunを知った。もしPhunを少しでも楽しめたのならリトルビッグプラネットに嵌ることは間違いないと思う。

自宅の居間に設置しているPCはほぼ録画専用になっていてHDD容量は500GBだ。しかし、この容量でも録画目的だと全然足りない。仕方がないので、MPEG-4に変換して保存したり、DVDにバックアップしてたりしたのだが、バックアップの手間が非常にかかるので、先日、ブルーレイディスク(BD)ドライブを購入した。 MPEG-4への変換は、Pythonスクリプトとmencoderを使って、タイトルから自動的にフォルダを割り振って変換するようにしてあるので、ある程度自動化できていたのだが、DVDへのバックアップについては、1枚4.8GBの容量では何度もドライブから出し入れしなくてはならず非常に厄介だった。BDだと一層で25GB、二層(DL)で50GBと、DVDに比べ容量が格段に大きいのでバックアップがとても楽になった。最近はBD-Rの値も下がり、一枚350円を切る値段になっていて、これなら許容できる。 と云うわけで、我が家では着々とBD化が進んでいる。そう言えば最近は市販のDVDはまったく購入しなくなってしまった。BDの画質を見た後だととてもDVDを購入する気にはなれないなぁ…。

Evernote を使っていないと人生を損していると思う。もちろん独断と偏見だけど。それにしても、もっと早くからこのようなサービスがあることを知っていればなぁ、と思ってしまう。それほどまでに個人的には画期的なアプリケーションであり、サービスであったのだ。 少し前にあるウェブサイトでEvernoteのことを知り、すぐにインストールした。しかし、イマイチその便利さが分からずしばらく放置していた。まず、どのように使えばいいか分からない。画像やPDFファイルなどを貼り付けることができるノートのようなものと云うことは分かったのだが、どこが便利なのか。普通にノートを取れば済む事ではないかと思ってしまったのだ。 それで、Evernoteはしばらく使っていなかった。ところで、自分は仕事用のノートを持っており、ミーティングやセミナー、仕事の進捗、ちょっとしたメモをこれに書いていた。ある日、以前行った仕事の手順を知るためにそのノートを見返してみたのだが、すぐに該当する箇所を見つけることができなかった。この時間の浪費はひどく損だ。特に仕事関係のメモは高い頻度で見返すことが多く、仕事の効率にも響く。そこで、Evernoteを思い出した。Evernoteならタグでグループ分けもでき、ソートや検索もお手の物だ。これは使わない手はないと、ここで初めて気が付いた。 それからしばらく使ってみたのだが、これがとても良い。まず、入力したメモやデータがオンラインストレージと同期されるので、どのPCからも同じノートを読むことができる。もちろん、オンラインでデータを扱うことに対しセキュリティが気になるようならローカルデータとして扱うこともできる。この場合、入力したPCでしか閲覧できないが。 また、普段PCを使って仕事しているので、仕事の進捗など一々ノートを取り出して開いてペンで書き込むという行為はそれだけで効率が落ちるのだ。EvernoteであればPCから離れることもない。さらに、仕事のデータ、例えば数値計算のグラフなどを画像のまま貼り付けることができるのも凄く便利だ。 自分は仕事柄、論文を読むことが多く、ほとんどの場合PDFで保存されているのだが、その管理が今までは非常に大変であった。ファイル名やフォルダでの分類に気を使って管理していたのだが、これだと手間が掛かり、ファイル数が多いとあ...

巷ではGoogleで 399999999999999-399999999999998 を計算させると0を返すと話題になっているが、ちょうど 333333333333335-333333333333334 の計算から0を返すようだ。ちなみにこの倍となる数値で計算させると 666666666666669-666666666666667 =0のように差が2で0を返すようになる。たぶん近いうちに修正されるんじゃないかな。

ここのところ、ゲームクリエイターの人材発掘に力を入れているようだ。SCEJからはクリエイター発掘支援プログラム「 PlayStation@C.A.M.P! 」、MSからはXNA Game Studioによる「 マイクロソフト XNA ゲーム クリエーター コンテスト 2008 」が開催される。 これらの内容をみるととても魅力的だ。自分が学生だったら迷わず参加していただろう。しかし、こうやって魅力的なコンテストなどを行っていかないと(もしくは行っても)なかなか良いクリエイターが見つからないのが今のゲーム業界なのかもしれない。 自分が一番最初にゲームのアイデアやシナリオを考えたのは小学生のころだった。そのころはインベーダーゲームが流行っており、それに対しとても惹きつけられたのを思い出す(もちろん ゲームセンターあらし はお気に入りだった)。もっとも、小学生で小遣いもあまりなかったので、実際にはアーケードゲームはほとんどプレイしなかったのだが。 その当時に作ったシューティングゲームのアイデアは以下の通り。まず、雑魚敵は多種多様に存在し、画面の半分以上を占めるような非常に大きなボス敵がいる。そのボス敵を倒すのは非常に困難で、短い間だけ開閉される出入り口にミサイルを何発も命中させなければならない。その間に弾幕攻撃と執拗な雑魚敵の襲来があるというものだった。もちろん、方眼紙を使って、それぞれの敵をデザインし、何枚も使ってどのように敵が動くのかも描いたものだ。今考えるととても幼稚に思えるが、後年、実際にそんなコンセプトを持つシューティングゲームがたくさん出てきた。 今では多種多様なゲームが作られており、自分が小学生の頃に思い描いたような理想のゲームを自分自身で考えるということはなくなってしまっているのかもしれない。ゲームを考えるのはプロであって、自分たちではないと思っているのだろう。確かに、ゲームはより複雑になり、たくさんの人たちの連携で作成されるようになった。一人が、シナリオを書いて、イラストを作り、音楽を考え、プログラムを組むという時代ではなくなったかもしれない。それでも、本当に面白いアイデアというのは個人の発想力がモノを言うと思う。 最後にプログラミングの観点から。個人的にはゲームを作るためのプログラム言語はActionScript 3.0が良いように思...

この ビューティフルコード (Beautiful Code)は悶絶するほど凄い本だ。著者には、カーニハンを筆頭に世界中のGuruたちが並ぶ。個人的には、高速ビットカウントやNumPy、MapReduceあたりに興味を覚えた。コードを書く人なら興味を覚えるテーマが一つや二つは必ずあるだろう。 しかしながら、私にとってはビューティフルコードの価値の1/3は、久野靖さんとまつもとゆきひろさんの対談にある。これは凄いよ。ずいぶん前、fj.comp.lang.c++で大規模なフレームがあった。 malloc/freeについての論争 である。mallocでメモリを確保した後にfreeをしなければならないのか、そうではないのかという、今でも時々蒸し返される定番の話題だ。 この当時、初心者にはmallocと対応させてfreeをすることを教えない方が良いとする意見がGuruたちの間では優勢であり、その中の一人にまつもとさんもいた。一方、久野さんは教えるべきだとの意見だった。前々からfjでの久野さんの意見はほとんど自分と一致していて、そして自分にとっては一々が説得力を持っていた。このときのmalloc/freeの意見でも完全に久野さんと同意見だった。malloc/freeについての主義や主張をここで繰り返しても仕方がないので、あとは C FAQ でも読んで欲しい。云いたいことは、自分にとってこの時期がプログラミングに対しての考え方を形成する上で重要であったということだ。 現在、自分はメインのLLとしてPythonを使っている。これは上記のフレームが影響しているのだ。malloc/freeについて自分と異なる考え方を持つまつもとさんはRubyの作者であったが、私がRubyではなくPythonを選んだのはまさにこの考え方の違いのためだった。個人的には、Rubyの方がよりオブジェクト指向としての完成度が高いし、短く書ける(内包表記はまた別だけど)ので、好みに合うように思うのだが、やっぱり作者の考え方が自分と違うことを知ってしまうと喜んで使うことができなくなるのだ。今ならもう少し柔軟な考えもできるが、当時はまだ若かったこともあってどちらも使うという選択にもならなかった。 そして、久野さんとまつもとさんの対談をあの当時の懐かしさと一緒に読んでみた。型に対する意見の違いなど、や...

たまにPCに入っているファイルを探し出すのが大変だと聞くことがある。また、OSの機能としてファイルの検索機能について大きく取り沙汰されることがある。それだけ、ファイル検索については世間で関心が持たれているのだろう。 しかし、個人的にはその感覚がよく分らない。PCの個人フォルダには10万件近いファイルを入れているが、ファイルを探し出すのに困ったことはほとんどない。逆に何でファイルを探し出すだけのことにそんなに苦労するかが分らない。 新しいPCを購入した時にまず行うのがディレクトリ(フォルダ)の作成だ。ホームディレクトリには必ず以下の7つのディレクトリを作成することにしている。そして、このディレクトリ以外はいかなるファイルも恒常的には置かないことにする。ただし、Windowsの設定ファイル(隠しファイル属性)やUnixのドット(.)ファイルなどはこの限りではないが。また、researchというディレクトリがあるが、私の場合、仕事=研究なのでこのようになっている。 bin data develop document network research temp それぞれのディレクトリは複数のサブディレクトリを持つ。それぞれをさらに分類するわけである。その分類の方法は該当するファイルの性質による。大抵はプロジェクト毎だとか、ジャンル毎で分けるが、日付が重要なものであれば日付で分ける。こうして分けておけば、取得したいファイルが何かさえ知っていれば迷うことはないと思う。もし、どうしても二つもしくは複数にまたがるような種類のファイルになってしまう場合は、コピーして同じファイルを持ったり、リンクを張ったりして、複数のファイルを持つことにしている。これで、どちらか一方で検索しても探し出せるわけだ。 また、Windowsでのフォルダ管理は別途ユーティリティを入れないと扱いづらいので、私は FileVisor を使って管理している。基本的にはエクスプローラと同じような感じであるが、様々なところで使いやすくなっている。特に、ファイルの中身検索やクイックアクセス、ファイルのアーカイブなどが便利だ。たとえば、多数のファイル群で構成されるプログラムコードの中から指定の変数などを探す場合、そのディレクトリ内から簡単に探し出すことができる。また、フォルダがある程度の深さの階層になっ...