前も同じようなこと書いた記憶があるのですが、なんか仕事が増えたんです。ひとつひとつが特に関連あるわけではないのに仕事が舞い降りてくるという不況とは信じられない世界です。ゴールデンウィークが明けたら少しは楽になりそうですが、疲れました…

今日は他人のソースコードを見ていてラッパークラスの意義について考えさせられました。 DB のレコードを UPDATE してるのに影響を与えた行数が取れないというブレイバーメソッドにはちょっと手を入れる必要があるかもしれません。

自分の設定が悪い可能性も高いのですが、 Meadow は折り返した行を縦に横断する際、キャレットが改行を１行と数えた場合の次の行に移るのに対し、 Emacs は表示的に１行と数えた場合の次の行に移ります。つまり、 Emacs は折り返して２行に見えている行を横断するためにキャレットを２回下に動かさなければならないのですが、これが Windows のエディタっぽくて使いやすく感じます。

プログラムのソースコードでしたら適度に改行を入れるのも楽なのですが、 HTML となると長い行に改行を入れにくくなるケースがあります。ひどい時は折り返して３行になるコードとかありました。

ちなみに、 Emacs, Meadow 共に行を折り返さない設定がありますので、折り返したくない場合は elisp で設定します。

VBA だとプロシージャと関数とでサブルーチンのようなものを作ることができますが、 C/C++ だと関数です。関数＝機能と考えると、処理のブロックをなんでも関数で実装するのに違和感がなくなってくるのですが、最初は大変かもしれません。

ただ、 VBA の関数は戻り値を捨てられないとか、プロシージャを呼び出すのに Call が必要という仕様は、ソースコードが読みやすくなって良いなぁ、と思いました。 C/C++ を初めて見たときの記号っぽさが苦手だっただけに強く感じます。

VBA で逆に有利だと感じたのは、構造体や参照渡しができるという点です。普段 VBA しかやってなくても、できるだけ楽したいと思っていろんなプログラムを組まれている方は、ゲームプログラミングを覚えるのも楽だと確信しました。

VBA の基礎を活かしてゲームプログラミングを学ぶ際の一番の壁は、イベントドリブンというモデルで考えていた部分をゲームにうまく応用できるかだと思うのですが、ちょうどそのあたりの原稿を書いているので、書店に並んだら「ああ、こうなったか」と笑っていただけると幸いです。

プログラマで、生きている: ググるな危険

本文中にある、「30分悩んでもわからなかった場合はわたしに聞きにくること！」というルールを新人の方などと交わしておくのは良いなぁ、と思いました。確かに長く悩まれても困ります。

ELLEGARDEN にジターバグという歌がありまして、冒頭の歌詞に強く共感を覚えるのですが、仕事では許さないことがほとんどかもしれません（納期がありますので）。（→歌詞を改めてよく読んだら反対の意味でした。視点によりますね）

Emacs を使っているのでプログラムのソースコードは一発で整形できるのですが、 HTML がそう簡単にいきません（そういう拡張機能を持っていないのです）。

そこで役に立つのが Dreamweaver のソースコード整形機能。「コマンド」→「ソースフォーマットの適用」で実行できます。インデントは綺麗にそろい、必要とあらば改行のポリシーも変更することが可能です（あらゆるブロックエレメントで改行するとか、パラグラフだけは整形しないとか）。ショートカットは M-c M-a です。編集しづらいソースコードを貼り付けて M-c M-a で綺麗になります。ありがたひ…

始まりのない終わりタグ。前後するネスト。対にならないクオーテーション。まだまだ８月は終わりません。

いずれ、講座再開するときに備えて、初めてそれを見たとき、何が書いてあるのかわからないという感覚を忘れないようにメモしておこうと思います。

• 記号の意味がわからない
• 情報の切れ目がわからない（記号がどこで切れているのかわからない）
• 要不要が判断できない（自分で再現するとき、最低限必要な部分がわからない）
• 情報が流れる方向がわからない（たぶん記号がわからないから）
• まとまりがわからない（独立しているのか、まとまっているのか、いっしょくたに考えるのか、分けて考えて良いのか）
• どこまでできるのかわからない（解説向けに必要な情報が省略されているかもしれない）

たぶん、プログラミングの解説にも通ずるはずです。楽譜読むのは学校の授業でやったはずなんですけど、ほとんど忘れております。

TortoiseSVN | The coolest Interface to (Sub)Version Control

最近では、ソースコードの取得手段が Subversion を通じてのみのプログラムを使うことが多くなったため、良い感じのクライアントを探していたのですが、最終的にこれに落ち着きました。

昔、 WinCVS を使っていて、その使用感が当たり前になっているせいか、エクスプローラに統合される点に違和感を感じていたのですが、チェックアウトばっかりだとこっちの方が楽でした。

今、 diff で空白を無視する方法を探しております。

次からは積極的に関数やメソッドを作ってコードに色をつけていこうと思いました（コピペポイントを多く作るとでも言うのでしょうか…）。関数化って基礎ですし、どう考えても最初からやっておくべきでしたよね。

実は、この考えは私の恩師流なのですが、自分も昔から自分の想像が正しいかどうかを確かめるためにわざどエラーを起こすようにして確かめてきました。ただ単にエラーを起こすだけではいけません。「こう変えたら、こうエラーになるはずだ」と予想してからエラーを組み込むことが重要です。

先日も XML にて xmlns:alias=”http://～” の alias の部分は何でも良いのかと疑問に思って、試しに unko とかに変えてエラーを確かめました。

私の場合、読みづらいソースコードとなると情報処理試験のソースコードが思い浮かびます。 COBOL で受験したという言語選択の影響も大きいのですが、情報処理試験のソースコードは１行の無駄や不自然さも許さないところがあって、最初、何をしているのかよくわからない状態から始まります（それを解析する能力を養うのが目的なのかも）。

そういった経験がありましたこともあり、今は無駄や不自然さを覚悟でソースコードに情報を埋め込むようなことを意識しています。しかしながら、この辺がうまく生きているかは次に保守するときならないとわからないので、突き詰めようにも何とも難しいですね（もしくは、他人が読むような機会を作るとか）。

ときどき、「 Byerkut さんのソースコードは読みやすいです」と言われるのですが、どの辺を見て言っているのかちょっと気になります。割と、目的意識が一致していれば、多少ソースコードに問題があっても読みやすくなるような気がしますよね。