不可解計画

2010年05月23日

作りたいものを、作りたい

　４月中頃から、普通の社会人生活に復帰している。去年の末から着手している、iPhone OS 向けの電子書籍の仕事も続いている。通勤電車は東京都心のそれなので、ほとんど座ることができない。職場は情報セキュリティがガチガチなので、昼休みに別の仕事をするような余地はない。

　．．．結果、自分のやりたいこと、作りたいものが全部ストップしている。

　所詮は趣味の領域なので、それをやらなければ生活に困るとかいうわけではない。生活に困るかどうかという意味では、半年以上続いた無収入の期間の方がよほど困っていた。貯蓄を削り続けていたからだ。時間はあるが金が無い（というか減っていく）生活。しかし、実際に仕事中心の生活に戻ってみると、それが単に「金は少しずつ貯まっていくが時間が無い生活」に切り替わっただけであることに気付く。

　作りたいものを、作りたい。

投稿者 kagelow : 12:00 | コメント (0)

2010年04月25日

昨日の続き

　さて、本題に入るとしよう。テンプレートを使用したメタプログラミングでエンディアンを操作するやつだ。

　使い方から先に書くと、以下のような感じになる。

int n = LittleEndian::ConvertTo<BigEndian>( 0x12345678 );

　このことからわかるのは、クラス LittleEndian にクラススコープのメンバ関数テンプレートがあり、テンプレート引数に BigEndian を渡してエンディアン変換をしているということだ。実際には、LittleEndian および BigEndian は typedef であり、以下のように定義されている。

typedef Endian<__LITTLE_ENDIAN> LittleEndian;
typedef Endian<__BIG_ENDIAN>    BigEndian;

　つまり、Endian というクラステンプレートがあり、その内部にメンバ関数テンプレートとして ConvertTo() があるわけだ。で、この __LITTLE_ENDIAN と __BIG_ENDIAN とはなにか。これは、endian.h にある数値で、バイトオーダーを表現している。

#define __BIG_ENDIAN    4321
#define __LITTLE_ENDIAN 1234

　ちなみに、endian.h ではマシンのバイトオーダーを __BYTE_ORDER として定義しているので、以下の定義によりマシンのエンディアンを取得できる。

typedef Endian<__BYTE_ORDER> MachineEndian;

　ここまでで、Endian クラステンプレートの定義が見えてくる。以下のような感じだ。

template<int BYTEORDER>
struct Endian {
  static const int byte_order = BYTEORDER;
  template<typename ENDIAN>
  static inline int ConvertTo( int n );
};

　static const int byte_order がここでのキモだ。これをコンパイラが定数として扱うことで、コンパイル時点でできる計算をかなり増やすことができる。

　ここで少し脱線すると、こいつは little endian と big endian だけでなく、他のバイトオーダーも扱うことができる。例えば以下のように。

typedef Endian<3412> PDPEndian;

　で、問題はメンバ関数テンプレートである ConvertTo の実装だ。これは、以下のようになる。

template<int BYTEORDER>
template<typename ENDIAN>
inline int Endian<BYTEORDER>::ConvertTo( int n ) {
  return __ConvertEndian( n, Endian<BYTEORDER>(), ENDIAN() );
};

　これは、変換元と変換先の Endian クラスをタグディスパッチに使うことで、__ConvertEndian() の関数オーバーロードを使用して処理を振り分けている。このオーバーロードによって LittleEndian、BigEndian、それ以外の相互変換を個別に実装しているのだ。最初はメンバ関数テンプレート ConvertTo() 自体を特殊化しまくって対処しようと考えていたのだが、いかんせんメンバ関数自体のパラメータは int だけなので断念したような次第。

　例えば、little to big の変換では、以下のような __ConvertEndian() になる。これは一番素直な変換だ。

inline int __ConvertEndian( int val, LittleEndian, BigEndian ) {
  return ( ( val & 0xFF000000 ) >> 24 ) |
         ( ( val & 0x00FF0000 ) >>  8 ) |
         ( ( val & 0x0000FF00 ) <<  8 ) |
         ( ( val & 0x000000FF ) << 24 );
};

　ちなみに、変換元と変換先のバイトオーダーが等しい場合、なにもしないようにオーバーロードされている。だから例えば、MachineEndian が LittleEndian に等しいことに気付いていなくても、以下のコールは安全だ。

int n = MachineEndian::ConvertTo<LittleEndian>( 0x12345678 );

　そして、もうひとつだけ例をあげておこう。little endian から little でも big でもないエンディアンに変換する場合のオーバーロードだ。

template<typename TO>
inline int __ConvertEndian( int val, LittleEndian, TO ) {
  union { int val; char ch[4]; } wk;
  wk.ch[3] = ((char*)&val)[( TO::byte_order      %10)-1];
  wk.ch[2] = ((char*)&val)[((TO::byte_order/  10)%10)-1];
  wk.ch[1] = ((char*)&val)[((TO::byte_order/ 100)%10)-1];
  wk.ch[0] = ((char*)&val)[((TO::byte_order/1000)%10)-1];
  return wk.val;
};

　なんだか複雑そうに見えるが、重要なのは変換対象である val 以外は全て定数ということだ。つまり、これは計算のほとんどをコンパイル時点でやってしまえる。昨日試した限りでは、配列解釈による転置よりもビットシフトで実装する方が速いが、このような変換でも同じように実装することが可能だろう。

　ひとまずこんなところだが、冷静に考えるとまだまだ改善の余地があるような気がしてくる。全てをビットシフトでなんとかでき、計算の多くをコンパイル時点にやってしまえるなら、ConvertTo からタグディスパッチを使って __ConvertEndian のたくさんのオーバーロードの中から処理を選ぶ必要などないのかもしれない。そこのところを上手く書くことができれば、同じ効率でも実装はもっと短くなる。

投稿者 kagelow : 18:00 | コメント (4)

2010年04月24日

アセンブラまで降りるとわからない

　なぜだか、エンディアンを操作する処理をクラステンプレートを使用したメタプログラミングでやる、というのを楽しんでいる。が、その話は後だ。読んで楽しいと思う人が少ないだろうからだ。それよりも、自分が悩んでいることを先に書いて助けを請うことにしよう。

　何で悩んでいるかというと、エンディアンを little ─ big 間で相互に変換する際の処理で一番早いのがどれか、自分では判断がつかないのだ。候補として扱う条件は、分岐やループなど、遅くなる要因がないことや、可能な限り局所変数の数や演算の量が少ないこと。扱うのは 32 ビット変数のみと（ひとまずは）しておく。最初は std::reverse() で片付けようかと思ったが、ループやスワップが多いので論外。で、ひとまずイケそうなのは以下の２つと考えた。無論、int が 32 ビット幅だという前提はあるものとする。

int endian_invert( int n ) {
    return ( ( n & 0xFF000000 ) >> 24 ) |
           ( ( n & 0x00FF0000 ) >>  8 ) |
           ( ( n & 0x0000FF00 ) <<  8 ) |
           ( ( n & 0x000000FF ) << 24 );
};

int endian_invert( int n ) {
    union { int val; char ch[4]; } wk;
    wk.ch[3] = ((char*)&n)[0];
    wk.ch[2] = ((char*)&n)[1];
    wk.ch[1] = ((char*)&n)[2];
    wk.ch[0] = ((char*)&n)[3];
    return wk.val;
};

　正直言って、どちらが速いのか自分にはわからない。アセンブルリストを出してみた限りでは、後者の方が短いようだ。自分の無根拠な直観も、後者の方が速いのかな‥‥‥と思ってはいる。しかし、アセンブルリスト上で１行でも、命令によって実際に実行するのにかかる処理コストは異なるという話を聞いたことがある。しかし、そもそも自分はアセンブラを読めない、で困っているというわけだ。こういうときの判断のためのガイドラインとか知っている方、教えて下さい。

投稿者 kagelow : 20:30 | コメント (3)

2010年03月30日

７年以上こつこつと

　ここ最近、自作の正規表現エンジンをイジっている。現時点の開発資産のうち、もっとも古いもので 2003年６月というのがあるから、少なくとも７年前から作っていることになる。2006年くらいには安定したので、ここ４年くらいは使うだけで修正はしていないが、今の時点で自分にできる状態まで引っ張り上げようということで、再び手を入れ始めたのだ。

　少なくともこの５年で、自分の開発ベースも大きく変わった。昔は開発環境といえば Visual C++ を使っているだけだったが、今では基本的に g++。UNIX 系も Mac も Windows も使うし、Palm 環境なら 16bit だし仕事では 64bit も使う。文字コードだって少なくとも４種類以上は使っているのだ。全部とは言わなくても、これらをカバーしたいと思ったら、何らかの手を加える必要があるだろう。そしてその修正内容たるや大きなものだ。もちろん新しい機能も付け加えたい。

　以前にも書いたことがあるが、自分が昔作成したプログラムに手を入れるのは良いことだ。他人の作ったプログラムから得るものも多いが、過去の自分の作品を振り返ることには別の意味がある。それは、当時自分がどこにいるかを知り、それによって自分が今どこにいるのか、そしてどこに行こうとしているのかを知ることができるということだ。自分の昔の作品を見ると恥ずかしくなることがあるが、それは良いことと言うべきだろう。それは自分が変化（そして願わくば向上）していることの証なのだから。

投稿者 kagelow : 22:00 | コメント (0)

2010年02月12日

SVG で UML

　前回の続き。

　そんなわけで、ソフトウェアベンダーが販売する UML ツールは個人には好きではない。大艦巨砲主義的で、大抵高価だからだ。安価なものやフリーのものも存在するようだが、細かい仕様に追従しようとして扱いが面倒だったりする。自分が必要としているのは、あくまで思考を記録しておくためのスケッチとしてのツールだ。そこからソースコードを生成するつもりもないし、微に入り細に入った記述をするつもりもない。

　昔は、そこまで考えていなかったため、（Microsoft に買収される前からの）Visio を使用していた。Visio は VBA マクロを搭載していたため、オートメーションができたから色々とマクロも仕込んだ。余談だが、Visio 社はドローツール関連の特許を持っていた上に Visio 製品に VBA マクロを搭載してしまったために Microsoft に買収されてしまったのだ。ちょっと残念だったりする。

　現在の話に戻るとしよう。Visio は現在では UML の記述を標準でサポートしているが、問題は Visio が必要だということだ（当たり前だが）。これが自分としては引っ掛かる。PDF にでも印刷すれば良いが、それで場所を選ばなくなるのは閲覧だけだ。そして、Visio の UML 機能も、これまた『頑張り過ぎている』のだ。自分にとっては too much なのである。くどいようだが、自分が必要としているのは軽量で、必要十分な描画ができて、どこでも使えて他のソフトウェア製品に依存しないツールである。

　そのような不満を感じていた頃、VML（ Vector Markup Language ）というのをネット上で目にした。HTML のようなテキストによるマークアップの記述により、ブラウザ上にベクタグラフィックスを描画できるというやつだ。最小限のテキスト記述から VML 文書を生成するツールを作れば、あとの描画はブラウザに任せることができるだろう。

　当時は実験的に試しただけだったが、最近またその熱が戻ってきた。調べてみると、VML は SVG（ Scarable Vector Graphics ） にとって替わられたようだ。この仕様を調べ、自分にとって必要なダイアグラムを生成するツールを作ってみた。たとえば、以下の画像はツールで生成した SVG ファイルをブラウザで表示させた、ツール自身の設計情報（の一部）の画面キャプチャである。

　この SVG 画像を生成するためにツールに入力するテキストファイルは以下の通りだ。

class
name:Entity
abstract:true
position:300 100

class
name:EntityFinder
stereotype:interface
position:500 100

class
name:SVG
position:300 300
attributes:
- m_rect : Rect
- m_entityList : EntityList
operations:
≪EntityFinder≫
+ FindEntity( ... ) : Entity*

dependency
from:Entity
dest:EntityFinder

inheritance
from:SVG
dest:Entity

implementation
from:SVG
dest:EntityFinder
linestyle:RB

composition
from:SVG
dest:Entity
linestyle:LL
arrow:1

　このツール、まだ完成には至っていない。簡単なクラス図とユースケース図しか書けないし、関連の多重度やロール名などにも対応していない。とはいえ、膨大な UML 仕様の全てをサポートするつもりはないし、あくまで（現時点では）個人的なツールに過ぎない。必要に応じて少しずつ育てていけたらいいなとは思っている。

　問題は、Internet Explorer が SVG をネイティブサポートしておらず、Adobe SVG Viewer というプラグインを必要とすること、そして Adobe SVG Viewer はどういうわけだか開発を終了していることだ。Mozilla Firefox はネイティブサポートしているようだが、なぜか点線すらまともに描画してくれない。設定が悪いのかもしれないが、そこまで調べる元気もない。こうなると、『軽量で、必要十分な描画ができて、どこでも使えて他のソフトウェア製品に依存しないツール』という当初の目的が達成できるのかも怪しくなってきている。悩ましいところだ。

投稿者 kagelow : 04:00 | コメント (0)

自分にとっての UML

　UML が好きだった。過去形だ。

　C++ がネイティブな自分にとって、UML は設計のためにとても便利な表記法だった。しばらく離れているうちに UML は仕様が肥大化し、個人的には一番重要と考えている『意思疎通のためのスケッチツール』という側面を薄れさせてしまったと思っている。だから『好きだった』と過去形にしているのだ。

　個人的には、UML の仕様の肥大化には『CASEツール症候群』とでも呼ぶべきソフトウェア業界の古典的な病気と関係があると考えている。イデオロギーと言っても良いかもしれない。これは、『設計書を書けばそこからプログラムを作れるはずだ』というシンプルな発想からいくつもの病態を発生させるもので、特にプログラミングを知らない管理者クラスや上層部などがこれに罹患すると大いに苦しむことになる（現場の人間が）。過去に CASE という名で壮大な失敗を演じて以来、一時的にこのイデオロギーは『なかったこと』にされていたが、UML などの新しい表記法が表舞台に現れると、そこに取り付いて同じような事態を発生させる。

　で、これが UML 仕様の肥大化とどう関係するか。ソフトウェアベンダーは自身が販売する UML ソフトウェアに CASE 的な機能をつけている。付加価値を高めるためだろう。そして、UML 仕様の策定や改善にはソフトウェアベンダーも絡んでいる。これにより、UML 仕様はあまりにも厳密に、そして大きくなりすぎたのだ。

　ところで、『設計書を書けばそこからプログラムを作れるはずだ』という考えがなぜ間違いなのか。これは、設計というものをどう考えるかによるが、決定論的な方法（つまりなんらかのソフトウェアの実行）によってプログラムを生成できる設計情報というのは、人的であれ機械的であれ、プログラミングに必要な情報を全て含んでいるはずだ。その作成作業は、もはやかたちを変えただけのプログラミング作業に他ならない。

　‥‥‥というところまでであれば、なにも「間違い」であると言って切り捨てるほどのものではない。自分としても、これを否定するつもりはない。問題なのは、そこに幻想が挟まっていることだ。つまり、プログラミングに必要な情報量（つまり人が作成する設計情報の量）を過小評価する幻想である。これは、過去の CASE ツールが判で押したように『省力化』だの『開発コストの低減』を謳っていたことからもわかる。つまり、『設計情報からプログラムを作成できる』だけなら（ひとまず）正しいものの、それが『プログラミングそのものよりも簡単な設計情報の作成により、魔法のようにプログラムを作成できる』になってしまうのが誤りなのだ。

　公正を期すために書いておくと、上記のような幻想にとらわれなければ、この方法にはメリットがないわけではない。それは同期の問題だ。つまり、設計と実装の間の乖離を防ぐ方法としては、これは良いものだと言える。人手を使って同期をとることと比べて、CASE 的な方法で同期をとるのがコスト的に安くなるなら、これは良いことだと言えるだろう。

　かなり話が横に逸れてしまった。本題に入る前に随分と長くなってしまったので、続きは改めて。

投稿者 kagelow : 02:00 | コメント (0)

2010年01月06日

Meadow から Emacs23 へ

　暮れに Mac OS X 上で使用するエディタとして Carbon Emacs というのを導入したことは以前書いたとおりだが、今回 Windows PC 上で使用している Meadow も Emacs に乗り換えることにした。

　Meadow というのは、『もともとはWindows向けのGNU Emacsにおいて多言語拡張をするとの題目で進められて』いたものである、と Meadow のサイト には書かれている。しかし、本家 Emacs が多言語拡張（ Mule 統合と同義でいいのかな？ ）され、Meadow 由来のコードも移植されるなど、なかなか複雑な経緯を辿っているようだ。

　今回 Meadow の最新版でなく、Windows 版 Emacs の最新版を選んだのには、さしたる理由があってのことではない。これまで使ってきた Meadow 2.10 では utf-8 でのファイル保存ができなかったのが一番の理由だが、Meadow 3 ではできるようになっている。まぁ Linux でも Mac OS でも Emacs を使用しているんだから、Windows でも合わせておきましょうか、という程度のモノだ。

　しかし、Meadow を完全に手放してしまえるかというと、どうやら直ぐには無理っぽい。というのは、現時点では ASCII 文字と日本語文字が混在している状態だと、それらの文字幅の比がキレイに １：２ になってくれないのだ。前のバージョンの Emacs とはフォントの扱いが変わっているらしい。色々設定をイジってはみているが、どうも上手く行かない。ネットを検索しても、ズバリな解決策はまだ見つけられていない。だから上記の問題で困るような場合には Meadow に出動願うことになりそうだ。

投稿者 kagelow : 02:30 | コメント (0)

2010年01月04日

PODS の cygwin で問題発生

　自宅で使用している DELL のノート PC には CodeWarrior も PODS も入っている。PODS は Cygwin ベースの開発環境なので、このノート PC で使える cygwin は PODS のインストールにより導入されたものだ。パスも C:\PalmOSCygwin となっている。

　これまで、ひとまずは何の問題もなく使用できていた。しかし、この年末年始にやっていた作業で問題が発生。作っていたプログラムで原因不明の segmentation fault が発生するようになり、その原因がさっぱりわからないのだ。

　で、PODS を入れずに普通に cygwin を入れた ASUS のノート PC で同じソースコードを試してみたところ、そのまま正常動作したため、PODS の cygwin を疑った次第。すこし考えた振りをしてから、PODS をアンインストールして cygwin を単体で導入。正常に動くようになった。PODS がバンドルしているバージョンの cygwin に含まれるコンパイラにバグでもあったのだろうか。

　Palm OS 向けの開発をやめるつもりはないが、ひとまず CodeWarrior がメインだし、今後 PODS を使うことはないだろう……と思ってのアンインストールだったが、良く考えたら DA の開発は PODS 前提でコマンドラインでビルドしていたんだった。今更気付いても遅いが。（汗

投稿者 kagelow : 22:30 | コメント (0)

2009年12月30日

2009年総括

　去年に引き続き、今年も１年の総括はやめておこうかと思ったが、今年はあえてやることにしよう。

　今年リリースしたのはたった２つのアプリ。CashMemoDA のバージョンアップが１つと、iPhone OS 向けアプリの mult puzzle のリリースだ。

　本当はもう１つ、年内に間に合わせたかったアプリ（これはゲームではない）があったのだが、色々と事情があって間に合わなかった。一部では長いこと待っていてくれる方もいらっしゃるようなので、なんとかはやく道筋をつけたいと思っている。申し訳ない。

　あと、作業中のゲームが２つ、企画中のゲームが１つあるが、これは来年の早いうちにリリースしたいと思っている。作業中の２つのうち１つは既存 Palmware の iPhone OS への移植だ……って、書いてて全然総括じゃないよなこれ。だからやめとこうかと思ったんだ。

　そんなわけで、2010 年に期待。

投稿者 kagelow : 22:00 | コメント (0)

2009年10月25日

『偽装』の勉強中

　といっても、産地とか耐震強度の話ではない。あくまでプログラミングの話だ。

　これまで必要に迫られたことがなかったのだが、いわゆるセキュアプログラミングという分野がある。これは、アプリケーションのオブジェクトコードや実行中のメモリ状態を解析・追跡して重要な情報を取り出したりする、いわゆる『クラッキング』と呼ばれる行為からプログラムやデータを保護するためのプログラミング技法のことだ。いま、これを勉強しているわけである。なぜかといえば、必要に迫られたからだ。

　思い出すのは、Japonica に設定した隠し機能だ。あれは別段死守しなければならない秘密でもなんでもなかったわけだが、なんの保護もしなかったとはいえミニーさんにあっさりと見つけられてしまったときは本当に驚いた。自分は C/C++ よりも下の世界は詳しくしらないので、逆アセンブルリストから動作を紐解くというのはまるで魔法のように見える。

　で、今回はそれよりももっとシビアな理由でコードが何をやっているのかをわからなくしなければならないワケだ。つまり、プログラムが何をやっているか、あるいはどのようなデータを扱っているかを偽装して分かりにくくするというテクニックだ。この手のセキュリティには『完璧』というものはないようで、どれだけ努力しても技術と時間をたっぷり投入されればいつかは破られてしまう。キーワードは損益分岐点だろう。つまり、破るための時間やコストが、対象の価値を上回ればよい。良いというか、そこで手を打つしかないのだ。

　ミニーさんには『次回はもう少しヒネリを期待してま～す』などと言われたが、今作っているものが「次回」であるとすれば、破られたりしたらそれこそ笑えない話になる。頑張ってみよう。

投稿者 kagelow : 23:30 | コメント (2)

2009年10月23日

UI なんてキライだ

　iPhone OS 向けの開発を必死こいて頑張っている。Palm OS の時もそうだったが、UI（ユーザーインターフェース）というやつにはいつも泣かされる。

　陰郎がもっとも得意とするのはプログラミングそのものだ。つまり、Windows とか Palm とか iPhone OS とかに特化したプログラミングはそれほど得意ではない。それは要するにそれぞれのプラットフォームに特有の技術とかスタイルのことで、API とかユーザーインターフェースはそれに含まれる。なんかこう、学校のお勉強でいうならば暗記科目みたいなのものだ。知っていれば難しくはないが、知らなければ正解を得ることができない。そして、覚えなければならないものはどんどん増えていく。解決に必要なのは、「考える」ことではなく、「調べる」ことなのだ。そのために本を買ったりネット上で英語の文章を読むハメに陥る。うんざりしているのがわかっていただけるだろうか。

　陰郎が好むのは、工夫すれば実現できるような問題だ。いわゆるプログラミング言語を使ってデータ構造やアルゴリズムを組み立てるのが一番好きな作業だろう。もちろん、言語の仕様を頭に入れておかなければできないことではあるが、それは暗記科目というよりは数学の公理や定理、公式を覚えて応用することに似ている。比較的少ない量の暗記で、あとは工夫次第で色々なことができる。

　以前書いたとおり、陰郎がアプリケーションを作成するときはコアの部分から書き始める。これはどのプラットフォームにも依存しない部分だ。UI を必要最低限にしてコアを書いておき、コアができたらいくつかのプラットフォームに載せる。ここで初めてユーザーインターフェースを書くことになるわけだ。

　しかし、それでもやはりコケるときはコケる。UI とコアの境界線の部分で、UI 側のルールがわかっていないがゆえにコアに修正が入ることがある。今日もそれで大きくつまづいた。しかし UI というのは大事だし、それが気が利いていたりエレガントだったりするがゆえにたくさんのユーザが集まるものでもある。しかし、外見や振る舞いがそうであったとしても、プログラマからみて同じようにエレガントであるとは限らない。まさに今それを痛感しているところだ。

投稿者 kagelow : 23:00 | コメント (0)

2009年10月21日

落ちモノゲーム、作ってます。

　まだ先々の話なのだけど、今作っている作品の話。

　陰郎は、落ちモノといえばテトリスくらいしかまともにやったことがない。それ以外のはあまりしっくりこなかったのだ。いや、単純に楽しむ時間がなかったのかもしれない。そういえば、テトリスは旧ソビエト連邦の心理学者が作ったゲームという話を聞いたことがある。陰郎も実は大学では心理学をやっていたのだが、今 Wikipedia で調べてみると特に心理学者という言葉は載っていなかった。

　閑話休題。そんな陰郎だが、最近になって突然、新しい落ちモノゲームを思いついた。ゲーム性のバランスをとるのに苦労したが、ひとまずコア部分は出来上がっている。コア部分というのは、つまり UNIX のシェル上であればなんとか動作する状態になっているということだ。実現の目処がついたらこの日記でルールなどを紹介しよう。

　問題は、Palm OS であれ iPhone OS であれ、実際のモバイルプラットフォーム上での UI などに載せること。これが一番時間がかかる。同じようにコア部分だけ出来上がって順番を待っている作品はこれで２つ目だ。それとは別に今現在 iPhone OS 向け作品の『本丸』とも言うべきものが１つ作業中。頑張れ自分。

投稿者 kagelow : 00:00 | コメント (2)

2009年10月14日

コメントフル・プログラミング

　かれこれ４年前に、「コメントレス・プログラミング」というエントリを書いた。極端を承知で、ソースコードに記述するコメントに対するアンチテーゼをぶち上げてみたのだ。その思いは今でも基本的に変わっていない。しかし、この２年間で状況は大きく変わった。2007年６月～2009年７月の２年ちょっとの間やっていた仕事で、陰郎は山のようにコメントを書くスタイルに変わったのだ。今回はそれについて書いてみよう。

　最初に書いておくが、４年前に書いたエントリの基本的な考え方は今でも変わっていない。コンパイラはコメントをチェックせず、コメントとコードが正しく対応していることを保証するのは人間であり、人間は誤りをおかす動物である。コメントだけでコードを完全に理解するというのは現実的でない。コードの読みにくさを誤魔化すようなコメントが増えがちである。これらの考え方は今でも正しいと思っている。

　陰郎がこの２年間でコメントを書きまくるようになったのは、まったく別の理由からだ。この２年間の仕事では、とにかく時間がなかった（いつものことだが）。だからいわゆる設計書を書く時間もなかったのだ。とあるシステムのリプレースに伴うソフトウェアの全面刷新だったが、先代のソフトウェアもドキュメントは（少なくとも『正しくて役に立つもの』は）皆無といっていい状況だった。だからドキュメント類を整備するだけの時間も予算も人的資源も割り当てられはしなかったのだ。それについて恨みつらみを並べるのはよそう。そういった意趣は全部陰郎が地獄へ持っていく。陰郎の仕事は、とにかく何とかすることだった。

　ドキュメントというのは、要するに設計書だが、これはコメントよりもさらにコードから遠く離れている。コードを直すときはコメントを追従させるのを忘れる可能性があるが、ドキュメントの修正を忘れる可能性はもっと高い。しかし、何も作らないわけにはいかないし、だからといって（最終的には）システムとまったく同期のとれていないドキュメントを作るというのもやりたくない。

　この問題をなんとかするために利用したのがコメントだった。コメントの書式を定めておき、それに従ってコメントを記述する。ソースコードを処理するスクリプトを作っておき、それを実行することで HTML 形式のドキュメントを生成するようにしたのだ。もちろん同じようなことをする便利なツールがたくさん存在することは知っている。しかし、自分がやりたいことに完全にマッチするものがなかったため、結局自作することにした。結果はといえば、システムの全ソースコードの 50% がコメント行という状態になった。

　この方法は確かにドキュメントとコードの距離を縮めはしたが、同期の問題は解決されていない。また、これによって生成されるのは大まかにいって関数および構造体のリファレンス以下の情報だけなので、より上位の設計については別のテキストファイルに記述して同じツールで HTML を生成した。こちらは距離の問題についても解決されていないが、同じソースコードツリーの中に置くことや、Microsoft Word などのバイナリ形式を使わずにデータをプレインテキストで管理するというメリットを選択したわけだ。色々問題は残っていたにせよ、あの状況でできる限りのことであったとは信じている。そして、２年間そのやり方で必死で書き続けた結果、今となっては個人的な開発作業にもそのスタイルが持ち込まれてしまった。今や陰郎個人のソースコードもコメントだらけである。

　あの仕事は C 言語だったので、それに完全にロックインした作りになっていたが、できることなら C++ にも対応できるようにしたいものだ。しかし、クラスの概念やオーバーロードなど、一筋縄ではいかない要因が山ほどある。これも「やりたいけど多分やらない」という箱の中に放り込まれて終わりになるのだろう。

投稿者 kagelow : 23:30 | コメント (0)

2009年10月05日

林檎の樹の下で

　言語を３つ跨いでいる。iPhone OS のフレームワークが使用している Objective-C と、自分のネイティブ言語である C++ 言語、そして、それらの共通の祖先である C 言語だ。

　幸い、Objective-C は直接 C++ を扱うことができるため、生の C を使う必要はあまりない。しかし、C++ のインターフェースを Objective-C 側で実装したり、逆に Objective-C の protocol を C++ 側で実装したりする方法はどうやらないっぽいため、そこで生の C の関数インターフェースで繋ぐことになる。Objective-C についてはまだ学習途上のため、何ができて何ができないのか、あるいは何が効率的で何が非効率なのかがわからない。だからイチイチ手探りになる。

　それにしても、Objective-C というのは奇妙キテレツな言語だ。おっと、慣れない人間が言うことなのでどうか文句は言わないで欲しい。きっと慣れれば快適なんだろう。とてもそうは（現時点では）思えないが、無理に自分にそう言い聞かせている。

　それよりも奇妙なのは、Objective-C が公式開発言語になっている、という事実だ。これも「林檎の樹の下」効果というやつだろうか。つい最近まで、Objective-C は Smalltalk 系の動的オブジェ指向カルト集団だけが使い続け、すでにワシントン条約で保護されるくらいの絶滅危惧種になっているという認識だった。まぁ言い過ぎなのは認めよう。しかし、これから世の中に広めていこうというモバイルプラットフォームにこの言語を採用するということ自体、それくらいの暴挙だと思っている。iPhone OS 向けアプリケーションの開発を始めるにあたって、初めて Objective-C を学んだ、というプログラマの比率を調べてみれば、陰郎の言っていることがあながち暴言ではないということがわかるだろう（と勝手に想像している）。

　で、林檎の樹の下の話だ。陰郎はたしかに iPhone OS 向けアプリの開発に参加した。しかし、それだけを作るつもりはない。PC 向けもやりたいし、これまで通り Palm 向けもやりたい。林檎の樹の下にずっと居続けるわけではないのだ。そう考えると、Objective-C にあまりどっぷり漬かりたくないと思うのは自然なことだろう。Objective-C というのは、近代的なプログラミング言語の世界でいえばガラパゴス諸島にしか生息していない動物のようなものである。その狭い世界から出ていけば、本か動物園でしかお目にかかれない（まぁこれも言い過ぎだよね。わかってるってば）。だから、自分が開発するアプリケーションは、全てを Objective-C で書く気にはとてもなれない。要するにそれが言語を跨ぐ理由だ。

　言語やプラットフォームを跨がる場合は、色々な気苦労があるものだ。Palm で ARMlet を書いていたときは、68K エミュレーションと ARM チップの違いを意識して不格好なプログラミングを余儀なくされたし、ARMlet は大域が使えなかったから C++ の例外処理や多態も使えなかった。今もまた同じようなことをしているのだ。今はアプリケーションのコア部分を C/C++ で書き、Palm OS と iPhone OS の両方で使えるようにしようとしている。楽しいのかどうかは、イマイチわからない。

投稿者 kagelow : 02:00 | コメント (0)

2009年10月04日

追いつかない

　また新しいアイデアが出てきてしまった。先日書いた２つのアプリは着手したものの、いずれも完成には至っていない状態なのに。このままでは追いつかない。

　これを嬉しい悲鳴と思ってもらっては困る。アイデアや「作りたい」という欲求はナマモノなのだ。時間が経ちすぎると、いつの間にか消化できなくなっていく。事実、Japonica の開発期間中に「賞味期限の切れた」ネタというのがいくつかあるのだ。恨み言ではない。それが現実だと言っているだけだ。

　幸か不幸か、現在無職。いや、もともと自営業なので無職はおかしいのだが、要するに無収入だ。そのかわり時間はある。できるだけ、新鮮なうちに料理しよう。

投稿者 kagelow : 02:00 | コメント (1)

2009年09月24日

リメイク、というか移植。

　傍目には何もしていないように見えるかもしれないが、このところ頑張って開発をしていた。内容はまだ言えないのだが、既存アプリの別プラットフォームへの移植だ。もうしばらくしたら、ちゃんとここで報告できるようになると思う。

　それにしても、７月末に仕事を終えて以来、はや２ヶ月が過ぎようとしている。その間にも色々と買い物をしてしまっているのだが、一体全体自分は経済的に大丈夫なのだろうか。なんといっても１円も収入がないのだ。明日か明後日にはまた家賃を振り込まねばならないし。仕事は見つからないし（探していないとも言うが）。

投稿者 kagelow : 00:00 | コメント (0)

2009年08月23日

川崎にて会談

　川崎にて、eye さんと会談。いろいろと情報をいただいた。

　まだ何もかも準備段階なので確たることは書けないのだけど、始めたいことが色々ある。この老体が持つのかどうかわからないが、まぁやってみよう。無職だから時間は自由だ。財布は不自由だが。（汗

　そんなわけで、近々にも初期投資として十数万円の散財が発生する。生活は大丈夫なのか、自分。

投稿者 kagelow : 03:00

2009年03月17日

初 EeePC お出かけ

　今日、初めて EeePC を持って出勤した。もちろん、通勤途上での使用に限る。

　感想は、といえば、『十分実用になる』という感じか。陰郎の大きめサイズの手では、キーボードのサイズがぎりぎりになってしまうが、慣れればなんとかなるだろう。もひとつ感想といえば、『思ったより重い』である。まぁ EeePC 1000 なので仕方ないか。これより小さいと多分使うのが苦痛になる。

　で、何をやっているか。現在 Emacｓ（というか Meadow）と Cygwin をインストールしているだけなので、Visual C++ 時代の昔からイジっているプログラムを g++ 用に移植する作業をちまちまとやっている。それでも、自分の開発作業を日常的にやれるだけでも随分とリハビリになるものだ。

　先が長いのか短いのかよくわからないが、ひとまず。

投稿者 kagelow : 00:00 | コメント (0)

2009年03月09日

一転、新奇性肯定

　以前、あれだけ書いたくせに、買ってしまった。

　2GB のメモリも同時に購入して到着と同時に換装。起動して1GBしか認識しないのをみてビビったが、BIOS 画面を起動すれば大丈夫だった。あと、PDAIR のレザーケースも勢いで………うん、勢いで。

　まぁ、いいじゃん。以前も別に新奇性を全否定してたわけではないし。『買っちゃえばいいじゃない』って、みんな言うじゃない。『人間だもの』って。こんなに心安らかに身を委ねられる言葉があるだろうか。２１世紀の人類に、新たな免罪符を。

　それはさておき、基本的にコーディング以外のことで使用するつもりはない。なので、「ネットブック」とか言われてもぴんとこない。インストールするのは Cygwin と Emacs 。だけかな。

投稿者 kagelow : 23:00 | コメント (2)

2009年03月05日

近況報告

　このブログを書くのが月イチペースになってきている。こんなことではいかんとは思いつつも、いくつかの理由から前進できない状態だ。いくつかの理由とは、

　・仕事があまりにも忙しい。
　・現状を克服してでも「作りたい」と思うものがない。

　‥‥‥というところだろうか。以前も一度だけ書いたことがあるが、陰郎はとある研究所で仕事をしている。途方もない数のコンピュータを集めたクラスタを制御するシステムを２年近く前から作っているのだ。これにほとんどかかりきりの生活になっている。この状態はあと半年くらい続く予定だが、それまではゆっくり自分の開発をやる時間を確保することはできない。そして、それが終わったらまた別の仕事を探さなければならないし、その後のことはその時にならないとわからない。

　そんな状況を別にして、「とにかく作りたい」と思えるようなものがあるか、という２番目の問題についてはどうだろう。これが残念ながらないのだ。palmware に限っても、陰郎は現在手元にあるデバイスとアプリケーションでほぼ満足している。相変わらず Palm は日用必需品であり、現在の安定した使用状態を犠牲にするリスクを冒してまで何かを変更する気にはなれない。自作既存アプリのバージョンアップの方がまだ食指が動く気がするというのが正直なところか。

　とはいえ、仕事では C 言語ばかり。自分のネイティブ言語である C++ を最近触っていないような状況も良くない。ちょっとずつ、何かを始めたいところだ。それが palmware でないということも、まぁありうることではある。

投稿者 kagelow : 01:30 | コメント (0)

2008年12月30日

総括もできない 2008 年

　やっと、今年の仕事が終わった。休みは２日間。1/2 からまた仕事をせねばならない。毎年、一年を総括するエントリを書いて project-enigma の活動を休むことにしてきたが、今年はその総括すらもできなさそうだ。やったことと言えば、Japonica を何回かアップデートしただけである。

　愚痴を書いても仕方がないのでやめておく。この半年間、開発が滞っている理由はいくつかあるが、自分にはどうしようもないものもあれば、努力次第でなんとかできたのではないかと思えるものもある。来年もどうなるかはわからない。少なくとも、あと半年程は今の状態が続きそうな気がする。

　とにかく、仕事を２日間だけ休む。

投稿者 kagelow : 21:00

2008年12月04日

UMPCが欲しい

　電車の中しか、時間がない。

　Palm では、さすがにプログラミングはできない。実用レベルの入力環境と、最低限のコンパイルができなければならないから、Palm 用の外付けキーボードは解決にならない。自宅で使用しているノートPCは DELL の INSPIRON 1501 だ。開発のためのツールはひとおおり入っているものの、とてもではないが持ち歩く元気はない。

　最近は、とりわけ小さなノートPCが出回っているようだ。UMPC というのがそれだろうか。こんなことなら Palm の Foleo だってイケたんじゃなかろうかというのは多くの人が書いていたような気がする。陰郎の場合はコンパイラが動作しなければならないので、きっちり WinXP が動作していることが必要だ。でも Foleo が発売されていたら買っていただろうけど。

　昔は、ストレスなく持ち歩けるようなモバイルノート（という表現でいいのだろうか）は、大きくて重いノートPCよりも高価なのが常だったような気がするが、何がどうなると５万円台とかで売れるのだろう。職場近くの家電量販店で、いくつか UMPC を物色しながら「これで十分だよなぁ」などと呟いてみた。やはり決定的に重要なのは打鍵したときの感触だ。少しでも不快だと、使うのが億劫になってしまう。キーの配列、ピッチ、タッチ、隅の面取りや表面の微妙な湾曲。快適でなければならないなどと贅沢を言う気はない。とにかく不快でなければいいのだが……

　結果、これならいいかな、と思えるものがあることはあった。さて、どうするか。

投稿者 kagelow : 00:00

2008年11月26日

２ヶ月あいた

　復活を模索しつつも、なにも書かずに２ヶ月が経過した。

　ここ最近、なにをしていただろうか。職場で寝泊りしたり、朝イチの始発で帰宅してシャワーを浴び、昼ごろ出社したりを繰り返していた。仕事で開発中のシステムは、とても１人や２人で書けるような規模ではなくなっている。prject-enigma の活動が滞っているのは、忙しい上にいわゆる「開発欲」とでも言うものが仕事で満たされてしまっているからだろう。言い訳したくないと思いつつも、言い訳になってしまうことを承知で書いている。

　そういえば、職場での雑談で、「画像ファイルから、ビーズを連ねたすだれのようなものを簡単に作れたら面白いかもしれない」といった話が出た。要するに１つのピクセルが１つのビーズに対応し、縦１列を１本の糸（？）に通してぶら下げるようなものだ。プログラムにできるのは画像データを解析して手作業が楽になるようなデータに変換してやるところまでだ。画像ファイルと、手元にあるビーズとRGB値のマッピングが入力となって列ごとのデータを出力する。別段難しいことはない。サポートする画像ファイルの形式やその他の煩雑な処理（エラー対応とか）までは面倒なので一般公開には至らないが、ここ最近で作った仕事以外のソフトウェアはたったそれだけである。

　とはいえ、やりたいことは本当はたくさんある。Japonica も使っているうちに追加したい機能や改善したい挙動も増えてきた。今の仕事が終わったら、できるかもね。

投稿者 kagelow : 01:30

2008年05月18日

SICP の学習

　『計算機プログラムの構造と解釈 第二版』である。正直言って持ち歩くには重いのだが、通勤用のバッグに入れて通勤中（で Zen of Palm の訳出に行き詰ったとき）や職場での空き時間を利用し、学習を進めている。これにより、就寝前に読む本ではなくなった。

　そして、自分にプレッシャーをかける意味でも、きちんと学習の足跡を残しておきたいと思ったため、FSWiki を用いて記録をつけることにした。職場や自宅で、MIT Scheme を使用しての実習がメインになってきている。

　先は長いし、Knuth 本の学習と平行してやりきれるかどうかも自信がない。しかし、この仕事は磨かなければ磨り減る一方だし、30～40歳の10年というのは職業人としても重要な時期だろう。頑張ろう。

投稿者 kagelow : 21:30

2008年05月05日

現況

　連休３日目のはずだが、まったく捗々しくない。

　疲労感と、コードに向かったときに感じる言い様のない嫌悪感に悩まされている。集中力が続かず、食欲を始めとしたあらゆる欲求が減退している。

　実は、土曜日から日曜日にかけて、自宅から歩いてもいけるくらいの距離にあるビジネスホテルに一泊してみた。もちろんノートパソコンを持ち込んで。ネットも、本も、冷蔵庫も、なにもない環境でなら集中して作業できるかもしれないと思ったのだ．．．しかし、甘かった。もちろん、多少は進めることができたものの、たとえば Japonica の開発をしていた頃とは比較にならないペースだった。単に気を逸らせるものがないだけではダメなようだ。集中力が落ちているだけはないらしい。

　こういうとき、陰郎のような独り者は逃げ場がなくて困る。今できることと言えば Zen of Palm の訳出くらいのものだ。それとて行き詰っているのだが。

投稿者 kagelow : 20:00

2008年04月21日

進まない道のり

　たしか、３月に入ったあたりから Knuth 先生の The Art of Computer Programming を消化し始めている。ここしばらくは、昼休みはキーボードを脇へ押しやり、紙とペンを持ち出す。そんなふうに過ごしているのだ。

　しかし、最初に 「 数学的な基礎 」 と題して指数関数だの総和だのをやらされるのだ。１ヶ月半が経過しようというのに、まだ最初の 30ページくらいしか進んでいない。logarithm だのΣだのと延々格闘する昼休みが続いている。

　高校の頃やっていたのに比べると楽しくないのが我ながら心配だが、まぁこれはこれで新鮮なのでよしとしよう （ 新鮮だが楽しくはない、ということだってあるものだ ）。数学的な基礎の部分をなんとか通り抜ければもう少し計算機なところに辿り着けるだろう。それまでに力尽きなければの話だが。

投稿者 kagelow : 13:00

2008年04月10日

闘病中．．．

　またもや単純ヘルペスウィルスとの格闘。

　先週末から兆候があり、火曜日あたりに大発生した。以前は口の周りに発生したが、今回の主戦場はなんと両目の周り。眼軟膏というやつを処方され、眼の中に軟膏を入れている。また眼の周囲や眉のあたりにまである。不快なことこの上ない。ウィルスの繁殖を阻害する飲み薬も飲んでいるが、これがまた高価．．．

　とにかく安静にしていろ、という医者の勧告に従い、昨日からずっと寝ている。眼に薬が入っているから本を読むことも PC に向かうこともままならない。今は薬の塗り替えのタイミングなので、珍しく視界がクリアなのでこの記録をつけている。

　つくづく無理が利かない年齢になった．．．

投稿者 kagelow : 13:00

2008年04月08日

陰郎の一日 （ 2008年 4月版）

　朝、起床。通勤途上、地下鉄では座れないので、Japonica でニュースを読む。JR は座ることができるので、PPL でやっている Palm OS User Interface Guidelines の訳出をしている。降りる駅に着く前の 10分程度、「デバッガの理論と実装」を読み進める。通勤の仕上げは徒歩。片道 3km 歩く。歩いているときは開発のことは考えない。これは脳を休める時間だ。

　職場での昼休み、自席にて出勤途上で購入した昼食を食べる。10分で済ませ、Donald E. Knuth 教授の The Art of Computer Programming Vol.1 の自習を進める。

　終業後、やはり徒歩。3km 歩く。このときも頭は回転させない、つもりではあるものの、Esprit か Scrooge のことをなんとなく考えている。電車ではやはり UI Guidelines の訳出。都心で生活しているにもかかわらず、行きも帰りも JR は座れる。というより、座れるようにいろいろ調整している。長時間立っていては生産的に過ごせない。

　帰宅後、やはり簡単に食事を済ませ、曜日によっては洗濯などの家事。片付き次第、Scrooge の検討エントリを書く。少しずつ実装も進める。それが終わると Esprit の検討作業をする。

　就寝前。ベッドに入ってからエイホの「コンパイラ I」 を読み進める。

　以上がここ最近の陰郎の一日。まだ突破できる部分がないか検討中。

投稿者 kagelow : 21:30

2008年01月26日

一年の計

　一年の計は、「元旦にあり」だ。昔からそういうではないか。元旦にきちっと「今年はこうするのだ」と気持ちを改めてこそなのだ．．．しかし、もう１月も終わりである。じゃぁダメだ。今年はもうだめだ．．．　（愚

　自分で書いててよく分からないが、そんなわけはない。まぁとにかく今年取り組むことをきちっとまとめておきましょうという考えが、年明けから１ヶ月たってようやく出てきたわけだ。それにはまぁ、もっともらしい理由もある。昨年末時点での予定では Japonica をリリースした後、2008年は本格的に次の作品にとりかかるはずだったのだ。まだ完全には終わっていないものの、project-enigma にとっては、ようやく 2008年が明けつつある．．．というところなのだろう。

　全部できるかどうかは別として、とにかく列挙してみよう。

■Japonicaメンテナンス

　これは今後も続くだろう。Version 1.32 のリリースにより、とにかく普通には使えるようになったと思っている。しかし、できれば対応したい改善案件もあるし、できれば直したい不具合もある。なので、ひとまず最初に挙げておいた。特に、これを最後に書いたりしたら、「もうJaponica をイジる気はないのでは」 なんて思われそうだし。

■2008年公開開発案件

　名前がまだ決まっていないのでこう書いておく。何の話かご存じない方は下の２つの記事あたりを読んでほしい。

　・2008年公開開発案件
　・2008年公開開発案件 [3]

　まぁ、「お買い物最適化ツール」だ。これは、名前からいっても今年中にやるべきものだ。なので今後本格稼動することになるだろう。

■SquareRoot

　以前から書いている、２年前から構想しているゲーム。内容的にはまだ完全に秘密だし、SquareRoot というのは今適当に付けた開発コードネームだ。これは多分開発期間だけでも Japonica と同じくらいかかるだろう。よって優先度低め。以前も書いたが、個人的には一番情熱があるので、放っておいても前進するだろうし。

■SmartPointer

　これまた即席の開発コードネームで語る実用アプリ。できれば今年中。ダメなら来年の前半くらいを目処にしたい。内容は、SmartPointer という名前から想像できるようなものではない。たいちさん、メールしたあれだよ。

■Patriot

　これも開発コードネーム。いくつかのツール、というか、遊び心のあるアプリ横断的なユーティリティ？　できれば早く作りたいなぁ。

■Palm OS User Interface Guildelines 訳出

　PPL の活動。英文が（陰郎には）難しくて捗々しくないが、とにかくゆっくりでも進めていくつもりだ。

　

　そんなわけで、もう 2008年には収まりきらないことが明白だったりする。さぁ行くぜ。あと11ヶ月だ。

♯Palmware 以外が出てこなかったな．．．（汗

投稿者 kagelow : 23:00 | コメント (0) | トラックバック

2008年01月25日

バックアップと同期

　今日も Inside Japonica はお休み。

　以前、SD カードリーダーと 2GB のカードを購入した話を書いた。理由はそのとき書いたとおりで、自宅と職場で参照・更新するメモ書きやソースコードを通勤途上でも Palm で操作したいからだ。

　繰り返しになるが、これまで陰郎は、メモ書きなどは Palm 上のタスクやメモ帳で、ソースコードなどは USB メモリで管理していた。しかし、PIM データになっていると職場でイジり難い（職場では Palm デバイスの同期はしていないので）し、USB メモリ中のデータは移動中にイジれない。結果として、PIM データ中のテキストデータや USB メモリのデータなどをすべて SD　カードに放り込み、PC ではカードリーダーを使用して、Palm では Japonica や CardTXT を使用して参照・編集をする．．．というシフトチェンジをしてみたわけだ。

　．．．なんて Japonica と CardTXT を並べて書いてしまうと、『 Japonica にエディタ機能まで載っけてしまえ 』 という妄想が去来したりもするのだが、それは今日書くことではない。そうではないのだ。問題は、SD カード内のデータへの依存性が高くなりすぎることのリスクである。だからこのエントリのタイトルは 「 バックアップと同期 」 なのだ。

　バックアップと一言でいっても、やはり日常的にこまめなバックアップを取らないと効果が薄い。重要なデータは頻繁に更新する。特に開発作業などではそうだ。だから数日前のデータはあっという間に陳腐化する。と、バックアップはこまめでなければ意味がない。、前回も大容量化を嘆くようなことを書いたが、バックアップに時間がかかるととにかく億劫になる。カードを PC に接続して、ダブルクリックするだけで 『 変更されたファイルだけがコピーされて欲しい 』 わけだ。

　まず、思いつくのは市販のバックアップソフトだ。しかし、それも大袈裟である。自分で組めないはずはない。陰郎が使用している PC にはどれも Cygwin が入っているので、ちょっとスクリプトを組んでやれば．．．などといって始めたわけだ。無知というのは恐いもので、結局 cp -R -u -v で大方の目的は達成できることに後になって気づく。この年になるまで -u というオプションは知らなかった。-u で新しいファイルと更新されたファイルだけをコピーするから、仕事が完了するまでの速度はかなり速い。これは便利だ。

　しかし、これは一方通行のバックアップなので、カード上から削除したファイルがバックアップ先から消えるわけではない。つまり、バックアップ先にはファイルが堆積するから、完全にカード上と同期がとれるわけではないのだ。そのため、開発データなどは個別にカード上の「最新」ディレクトリと同期が取れていてほしい。当然 PC 上で作業する場合もあるから双方向の同期が取れる必要がある。誤って両側で編集してしまった場合にはコンフリクトを通知して手作業で解決するように促してほしい．．．まぁ、そんなことをしたかったわけだ。しかも手軽に。

　同期の問題も、バックアップと同様に２つの選択肢がある。市販の同期ツールを購入して使用する方法と、自前で作ることだ。結局自作の道を選んだ。結局、自分の必要とする機能だけを実装できるし、自分のニーズに合わせて変更もできる。なにより、問題が起こっても人のせいにしないで済む。（笑

　使用したのは、Cygwin のシェルコマンドと Perl だ。同期対象ディレクトリは「最終同期日時」だけを持っている。同期を取るたびに双方のディレクトリ配下の全ファイルの情報を作成し、Perl でイジりまくってどのファイルをコピーする必要があるか、必要があるとすればどちらが最新か、コンフリクト状態はどれか．．．などを判定し、必要なコピー処理を行うシェルスクリプトを作成して実行する。ただし、コンフリクトが検出された場合はシェルスクリプトは作成するが実行はしない。確認してから手作業で実行するのだ。

　やってみてわかったのだが、多対他の同期は意外と難しい。陰郎の場合、SD カード１枚に対して、職場のPC、自宅のPC、自宅のノートパソコンという３環境と同期を取ることになる。すると、当然ながら同期対象の SD カードと PC 上のディレクトリで「最終同期日時」が一致しない場合がある。そのような場合には完璧な判定は難しい。それでもひとまず動作するようになったのでひと安心というところである。それでも同期を実行する前にはカードのバックアップをとっていたりするのだが。（汗

投稿者 kagelow : 00:00 | コメント (2)

2007年12月30日

2007年総括

　今年もいろいろあった。いろいろやったし、いろいろできなくもあった。という書き出しは例年通り。さぁ、総括するぞ。

・ Palmware 開発

　今年は Japonica。それに尽きる・・・と言っても良いと思う。他、新作は TagCopiDA、CashMemoDA、ConvertDA、TimeBatDA といったところか。DA ばかりだな。あとはいくつかのアップデートがあったくらいだ。

TagCopiDA version 1.00
ConvertDA version 1.00
CashMemoDA version 1.20
BracketsDA version 0.75
ListMakeDA version 0.80
TimeBatDA version 1.00
Japonica version 1.00

　Palmware 以外の Palm 関連作品としては、Japanized PilrcEdit があるが、これは結局自分で使うには至っていないため、今後の見通しは立っていない。

　作品以外では、今年の大きな動きとしては With Palm の始動がある。陰郎は手広く Palmware を使いこなすというような立ち位置にはいないので、裏方的に手伝いをさせてもらっている。まだ始動して２ヶ月程度だが、ひとまずは形になり始めていると言って良いだろう。

　そして開発者として忘れてはならないのは、もちろん Palm Programmer's Laboratory だ。今年は新機軸として Palm OS Programmer's Companion の訳出作業というのを打ち出した。これは12月初旬で Volume I が完了し、Volume II については alg さんが進めて下さっている。現在、陰郎は少しずつではあるが Palm OS User Interface Guidelines の訳出を進めている。

　さて、Japonica のリリースによって、２年前に着想を得た新しいゲームの試作（というか思索？）を再開したのだが、これを 2008年中にリリースできるかどうか．．．多分無理なので、細かい作品をリリースして間を持たせるという project-enigma 一流のお家芸を来年も続ける所存だ。しかし誓って言うが、この２年越しのゲーム、Japonica のように一般受けするものでは決してないので、どうか期待しないように。

　

・その他の開発

　今年は、Palm 関連以外の開発は一切やっていない。少なくとも project-enigma 名義では。これは自分としては残念なことではあるが、Palm の現状を考える限り、致し方ないと言わざるを得ない。ちなみに、去年の総括では 「 来年こそバランスの良い活動を心がけよう 」 などと書いている。残念だ。残念極まる。今年はそういうことは書かずにおこう。

・さらにその他の活動

　project-graphica は完全に開店休業状態。そういえば初のコンデジとして RICOH Caplio R7 を購入したが、それは Nikon D70 に積もった埃をさらに厚くする効果しかなかった。場合によっては D70 を処分する必要があるかもしれない。その前に、どういうわけだか２台ある F80 をなんとかしなければならないのだが．．．

　また、年を追うにつれて書籍を購入して読む、ということが減っている。これはソフトウェア開発者としては磨り減る一方だということに近い。おかげでサイトの books review もちっともエントリが増えない。まぁこれもこれである。

　．．．というわけで、このエントリをもって project-enigma の今年の活動は終了する。来年も今年同様、粛々と開発を続けるのみだ。

　ではまた来年。

投稿者 kagelow : 15:00 | コメント (1) | トラックバック

2007年12月23日

Lambda ! なんて素敵なラムダ！

　リリースの準備をあらかた済ませ、本当に久しぶりに 「 何者にも追われていない時間 」 を今日は楽しんでいる。リリースしてしまえば、次の作品に取り憑かれ、追われるような生活が戻ってくるのは目に見えている。だから、今日・明日くらいはのんびりするのだ．．．と、久しぶりにこの本を読み返している。

　

　ともすれば熱狂的な信者のように、陰郎は C++ 言語を作った Bjarne Stroustrup 教授の哲学が好きだ。だが Palmware 開発を、とりわけ ARMlet を中心とした開発をするにつれ、本来の意味での C++ から離れてしまっているため、ここらで読み返してみようと思ったわけだ。

　読み始めてすぐ、第 -1 章の xx ページでなんとも面白いものが目に飛び込んできた。おそらく以前は読み飛ばしてしまったのだろう。先へ読み進めたい気持ちを抑えながら前書きを読むときには往々にしてやってしまうものだ。そこには、STL アルゴリズムにファンクタを渡す際に表記が劇的に簡潔になる Lambda クラスの例示があった。何が面白いのか、順を追ってみていこう。

　通常、シーケンスの中から 「 ある値を超える最初の要素 」 を見つける場合、ファンクタ greater をアダプタ binder2nd と組み合わせる。つまり、以下のように。

const int v[] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 };

const int* p = find_if( v, v + 10, bind2nd( greater<int>( ), 6 ) );

　問題は、bind2nd( greater<int>( ), 6 ) という部分が直感的に分り難いということだ。find_if 関数テンプレートは unary_function を要求するため、binary_function である greater の第２パラメータを 6 でバインドした binder2nd を得るために bind2nd 関数テンプレートを使っている。それは読めばわかるし、仕様からも明らかだ。しかし、読まなければわからない。ひとめ見て直感的に理解出来る方が望ましい。

　この問題を解決する、目の醒めるようなのが書かれていたのだ。最終的な答えを先に書くと、以下のようになる。

Lambda x;
p = find_if( v, v + 10, x > 6 );

　これはもう、表記上はほとんど文句のつけようがない。背後にあるカラクリもそれほど難しいものでもない。要は、x > 6 が binder2nd( greater<int>(), 6 ) を返せば良い。そのために必要なのは以下の Lambda クラスと演算子オーバーロードが１つだけである。

class Lambda{ };

template<class T>
binder2nd< greater<T> > operator> ( Lambda, const T& v ) {
　　return bind2nd( greater<T>( ), v );
};

　Lambda クラスは空っぽ。そして演算子オーバーロードも簡潔だ。これにより、期待した通りのことが起こる。先のややこしい記述とやっていることは同じだ。効率も変わらない。STL の理念どおり、すべてはコンパイル時に解決される。素敵だ。素敵だよ Lambda ！

　とはいえ、現実のプログラミングではなかなかこのようなシンプルな例にはお目にかからない。しかし、こういった素敵なアイデアがあるだけでもプログラミングは楽しくなる。今日は良い日だった。

投稿者 kagelow : 18:30 | コメント (0) | トラックバック

2007年12月20日

いろいろな環境で閉口

　今日は面倒くさい話。

　2006年の初頭から企画を練っていたゲーム。この時点では（というか今でもだけど） Palmware として考えていました。その後、2006年６月くらいからは別の Palmware ── そう、リリースが目前に迫っているあのPalmware ── の開発が始まったこともあり、お蔵入りしておりました。

　で、2007年の年末リリースに目処が立ったため、２年前の構想を引っ張り出してきたわけです。しかし、今度のは異常なまでにややこしく、いきなりちっこい Palm デバイス上で動かすことはとてもできないような面倒臭いシロモノ。陰郎はこういうとき、コアの部分だけを独立したソフトウェアコンポーネントとして書き、PC などのデバッグしやすい環境で動かします。今回もそうしているわけです。

　ところが。

　今回は、ゲームでありながら相当重い処理をしなければならないため、コアエンジンを丸ごと ARM ネイティブコードで書くことになりそうなんです。すると、陰郎の開発環境である CodeWarrior、その中に組み込まれた ARM 用コンパイラ、そして Palm OS Simulator でデバッグをかけるときに使用する Windows DLL をビルドするための Microsoft Visual C++ 6.0 という、これだけで３種類のコンパイラを通さなければなりません。

　陰郎は C++ プログラマです。ARMlet ですからポリモーフィックなクラスや例外処理、RTTI などは使えませんが、テンプレートは使えますし使います。階層化も使います。その他、普通ならば重箱の隅っこと見なされるような言語機能も使います。すると問題になるのが、各種コンパイラの挙動が微妙に異なるということ。普通は気にならないようなことかもしれませんが、キャスト演算子オーバーロードをメンバ関数テンプレートとして書いたりクラステンプレートの内部に別のクラステンプレートを作ったりすると、コンパイラごとに言うことが違ったりするんですよ。

　しかも、それだけじゃありません。最近は、職場で過ごす昼休みは開発サーバである Solaris 上で作業させてもらっています。自宅では、Linux 上で gcc　を使って開発しています。こういった様々な環境やコンパイラ全部で通るコードを書くというのは、意外と大変。どこかのコンパイラに文句を言われて直したかと思うと、それが原因で他の環境で叱られたりするわけです。実際にはまだ Solaris 上と gcc on Linux でやっているだけなので、このまま突き進んで CodeWarrior や Visual C++ に文句言われたら目も当てられません。嗚呼。

　まぁそれはそれとして、構想と実験を重ねるにつれて、Palmware に仕立てるのは無理なのでは．．．と感じ始めています。現時点で書けることは非常に少ないのですが、シミュレーションゲームなのです。ひょっとしたら Palm ではなく PC 向けの作品になっちゃうかもしれません。あるいは再びお蔵入りになるかも。（汗

投稿者 kagelow : 22:00 | コメント (2) | トラックバック

2007年09月08日

罪とバグ

　「 バグ指標値 」 という言葉をご存知だろうか。単体試験や結合試験、総合試験といった各試験フェーズにおいて、プログラム 1 キロステップあたりに存在すると想定されるバグの件数である。ソフトウェアを開発している企業ではたいていこういう指標値を持っていて、開発プロジェクトでそれを振り回す人がいるわけだ。

　最初にそれに出くわしたとき、陰郎は大きな勘違い．．．というか、善意の解釈をしてしまった。ふむふむ、これはつまり統計的に過去のバグ密度をデータとして蓄積し、未来の開発プロジェクトに（たとえばスケジュールとか予算とかに）フィードバックできるようにするためのものだな、と。これから立ち向かうプロジェクトの想定規模にこの指標値を当てはめれば、想定されるバグ件数がある程度の精度で見積もれるし、それをもってスケジュールや人的資源の配置も計画できる。時系列に沿ってその時々のバグ密度を並べれば、開発部隊のいわゆる 「 質 」 を追跡できるし、なかなか殊勝な心構えじゃないか、というわけだ。ところが。

　そんなわけはなかったのだ。

　少なくとも陰郎は、このバグ指標値がプロジェクトのスケジュールに影響を与えるところを唯の一度も目にすることは無かったし、自分達の仕事の結果によってこの指標値が修正されることもなかった。不思議なことに、なんとも固定的な数字だったのだ。では、何のためにこの数字が使用されたか。驚くべきことに、この数値の使い方は、そもそもこの指標値に対する以下のような発想を基にしたものだった。

　作成されるプログラムにはこの指標値に該当する数のバグがあるはずだ。なければならない。

　そう、つまり 『 想定された件数のバグを試験で摘出することを要求する 』 ために使用されるのだ。試験で発見されたバグの件数が少ないと、「 質のいいコードを書いた 」 と誉める代わりに 「 ちゃんと試験してるのか 」 と疑われる。では、逆に指標値を上回るバグを発見したら 「 たくさんバグを見つけてくれた 」 といって誉めてくれるだろうか。そんなわけもない。 「 指標値以上のバグの存在は低品質なコードを意味する 」 といってやっぱり叱責されるのだ。

　なんだか笑い話のようだが、陰郎が昔参加したプロジェクトではこんなのがまかり通っていたのである。穏便に済ませるには、バグ検出数が指標値の範囲内に収まるようにするしかない。当然、誠実にやっている限り、運を天に任せるしかなくなってしまうのだ。

　そして、それは陰郎の身にも災厄として降りかかってきた。とある小さなプロジェクトで陰郎が一人で書いたコードは、検出されたバグ件数が指標値をはるかに下回っていたのだ。当然のごとく、会ったことも無い誰かさんから物言いがつき、陰郎と陰郎の書いたコードは 「 理由付け 」 を迫られることになった。

担当 ： 「 バグ件数が少なすぎるって指摘がきちゃったんですよ。 」

陰郎 ： 「 だって俺が書いたんだよ？　そんなにバグ出るわけないじゃん。 」

担当 ： 「 でもそれじゃ納得しないですよ。なにか理由出せないですか？ 」

陰郎 ： 「 ．．． 」

　結局、理由として 「 開発作業中からローカルで小刻みなテストを繰り返していたため、試験フェーズでは指標値を下回るバグ検出数となった 」 という話で通ったと記憶している。これは事実だが、理由の全てではない。しかし、問題の誰かさんに理解できる理由は他になかったのだ。

　この一件があまりにも阿呆らしく感じられてしまったため、陰郎はその次の仕事で本来ならやってはならないことをやった。すなわち、指標値どおりのバグが試験フェーズで摘出されるよう、自らバグを仕込んだのだ。ただ、発注元の担当者（前述の会話の相手）にだけは話しをしておいた。結果、試験でのバグ検出数はご注文どおり。それまでで一番波風の立たないプロジェクトとなった。

　これを茶番だといって糾弾するのも結構だが、それをいうなら 「 N 個のバグがあるはずだ。なければならない。 」 という発想とそれを振り回す阿呆の踊りだって十分に茶番だろう。所詮は 「 ルールに従ってさえいれば、問題が起こってもルールのせいで自分のせいじゃない 」 程度にしか考えていない連中である。こっちは実際にモノを作って動かさねばならないのだ。だいたい重要なのは検出して直したバグの数ではなく、残っている（かもしれない）バグの数だろう。最初に指標値を持ち出してバグの数を固定して、あとはその数だけ検出すれば合格、というのはどう考えてもおかしい。無論、「 バグはあといくつある？ 」 という質問に簡単に答える方法はないが、だからこそ 「 実用に耐える 」 だけの品質を確保するような試験を構え、その内容や結果を皆でレビューするのではないのか？

　実際のところ、何があのようなバグ指標値の倒錯を生み出すのか、陰郎には今でも判らない。これからも判るとは思えない。しかし、それが何であろうと、「 誠実さ 」 でないことだけは確かだ。

投稿者 kagelow : 20:00 | コメント (0)

2007年06月12日

さてそろそろ、そろそろと。

　．．．復活しましょうかね。

　こまごまとしたことは少しずつやっていたのですが、きちっと開発に復帰しようかと。この２週間近く、いわゆるサラリーマンになったり職場が変わったりで状況の変化に慣れるのが大変だったのです。バイク通勤などとても考えられない状況（というか距離）だし、なれない電車ばかりかバス ── おまけに PASMO 未対応地域！ ── だったり、しかもどの乗り場から乗るのが正しいのやらもうワケがわかりませんで通勤中に遭難するかと半ば本気で心配したりだったのです。

　しかしまぁ、そんな状況の変化にもようやく慣れてきまして。そろそろやるかと。そろそろと復活しましょうかね。いきなりアクセルをベタ踏みできるほどの若さはもうありませんので。（汗

投稿者 kagelow : 21:00 | コメント (0) | トラックバック

2007年06月06日

時間の中に立ち尽くして

　体が動かない。

　時間はそこそこあるのだが、開発に復帰する気力がない。

　これはあれだ。た○ちさん達と新○浜で楽しいひとときを過ごせばやる気が出るかもしれん。あるいは、○○○○の○○○に参加すればやる気が出るかもしれん。ちょっと遠いが。

　しかし、そう考える時点でどうもおかしいのだ。「 外からやる気を供給しないと動けなくなったか？」 ということだ。そうかもしれない。

　どうしちゃったんだろう。

　単に、いつもの 「 時間に余裕があるとかえって捗らない 」 病気だろうか。そう思いたいものだ。

　だらだらと流れていく時間の中に立ち尽くして、そんなことを考えた。
　

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2007年05月03日

ハイゼンバグの思い出話

　陰郎は、本格的なプログラミングを C 言語から始めた人間なので、アセンブラのことは良く知らない。しかし、長年この業界で仕事をしていると高級言語の水準では説明のつかない事態にでくわすことがある。以下、長い上に後味の悪い、そしていささか怪談じみた内容ではあるが、陰郎が経験した話を紹介しよう。

　かれこれ２年近く前の話であるが、当時面倒を見ていた UNIX システムで原因不明のバグが問題になっていた。業務アプリケーションがクラッシュするのだが、とにかく再現性が低い。24時間365日稼働のシステムで夜間に動作するバッチジョブであり、発生すれば呼び出しを受ける。しかし、発生条件もはっきりせず頻度も低いため、コストや他の条件から 『 無事を祈る 』 ことしかできなかった。しかもこのバグ、デバッグバージョンのビルドでは一切発生しないというのが悩みのが種だった。このように再現条件がはっきりせず、追跡のために環境を変えると姿を消すようなバグはハイゼンバグ （ heisenbug : 量子物理学の Heisenburg の不確定性原理から。「 ハッカーズ大辞典 」 参照 ） と呼ばれる。一般的にハイゼンバグはメモリ管理の脆弱性などが原因であることが多い。

　そんな状況で陰郎に調査が命じられたわけだ。さて、なにができるか。最初にやったのは、発生時に作成されたコアファイルをデバッガで調査することだった。コアファイルというのは UNIX システムでアプリケーションがクラッシュした時に作成されるファイルで、アプリケーションのメモリ空間の状態がダンプされている。これをデバッガで開くことでクラッシュした時点の状況が再現できる。

　コアファイルをデバッガで開くと、ソースコードの具体的な位置やそこに至るまでの道筋、そして各種の変数に格納されている値を知ることができる．．．と言いたいところだが、それはアプリケーションがデバッグオプション付きでビルドされている場合だけだ。通常、リリース向けのビルドではデバッグオプションを外し、最適化オプションを指定している。だからソースコードに現れるような名前は登場せず、全てアドレスで表示される。当然このままではどこで落ちているのかわからない。正直どうしていいのかわからなかったが、詰まるところソースコード上のそれぞれの関数がどのアドレスにマップされたかがわかればいい。結局、コンパイルオプションを変更して関数アドレスのマッピング情報をファイルに出力し、それと照らし合せることで呼び出されている関数を特定することができた。

　しかし、呼び出し関数の追跡は最後のところで行き詰まってしまった。関数アドレスがマップファイル上に見当たらないのだ。ということは、これは実行時にリンクされる外部ライブラリの関数．．．例えば標準ライブラリの関数、ということになる。しかし、それをどのようにして特定すれば良いのだろう？　．．．デバッガでコアファイルを開いて得られる関数の呼び出し経路情報には、呼出元のコードのアドレスも含まれている。ということは、最後の関数を呼び出した位置だけはわかるわけだ。ならばということでコンパイルオプションを更に変え、今度はアセンブルリストを出す。これと突き合わせればソースコードの位置がわかる。

　．．．突き合わせの結果、やはり動的リンクしている標準ライブラリ関数の内部でオチていることがわかった。これで再現性が低いということは、普通ならばやはりメモリ管理関連のバグが疑われるところだが、残念ながらそうでもない。メモリ管理とは無関係なコードだったのだ。全く同じ条件でも正常に動作する場合もあればコアを吐くこともある。再現性を確認するためのテストプログラムを作成し、同じ条件で１時間に数千回も実行を繰り返す耐久試験をしてみたが、発生率は１％に満たない。しかし、０％ではないのだ。

　この時点で上に状況を報告し、「 どうしても無理ならいい 」 と言われたものの、個人的に面白くない。ソースレベルで究明できない原因なんて本当はあっちゃいけないはずだ。C言語は他の 「 高級 」 言語やスクリプト言語とは違うはずだ。そうだろう？　．．．というこだわりがあったわけでは必ずしもないものの、陰郎も意地になっていたというのが実際のところである。

　で、最終的にどうなったか。これがなんと直せた （ というか直った ） のだ。しかし、どう考えても不本意な内容だった。とはいえ、事象の理不尽さを考えるならば致し方なかったかもしれない。陰郎は、問題を起こしているコードブロックの周辺を眺めた。大まかに、以下のようになっていた。

if( foo ) {
　　/* ・・・ */
　　/* 問題を起こす部分 */
　　/* ・・・ */
}

if( bar ) {
　　/* ・・・ */
}

　ここで、陰郎は foo と bar の２つの条件が決して同時に成立しないことに気付いた。つまり、同時に通過しない以上、これら２つのブロックの順序を入れ替えてもまったく問題なかったのだ。そして、それをやってみたところ、バグは発生しなくなった．．．完全に。

　陰郎はこのとき、正直なところ非常に悩んだ。先の耐久試験をどれだけやっても再現しない。それはいいのだが、まったくもって説明に苦しむのだ。どうして２つのブロックを入れ替えたら直るのか、そもそもなぜそんなことを試そうと思ったのか？　．．．自分でもわからない。しかし、実際に （ 微々たる発生率とはいえ ） 確実に再現させられる試験で再現しなくなっている。そして、２つのブロックを入れ替えても実処理に影響がないことは論証できる。しかし、バグの原因と、直った理由については何も言えないのだ。これでは直った（あるいは直した）とは言えない。より再現率が低くなっているだけかもしれないのだから．．．

　陰郎の良心はほぼ完全に負けを認めていたが、同時に上に全てを委ねようという気にもなっていた。有体に説明し、判断を求めた。結果としては、その修正を受け入れ、稼動させてみようということになった．．．それ以来、ほぼ２年間にわたって実稼動システムではこのバグは発生していない。顧客は喜んでくれた。深夜の不意の呼び出しに悩まされていた担当SEからも感謝された。敗北に打ちのめされていたのは陰郎一人だった。今でもこの案件の話が出るたび、「 なぜあんなことを思いついたのか 」 という話になる。格好をつければ 「 直感が働いた 」 とでも言うのだろうが、実際のところは 「 他に何も思いつかなかったから 」 でしかないし、それで直るとも思っていなかった。今でも陰郎にはわからない。

　しかし、ひとつだけ実感として学べたことがある。それは、コンピュータはソースコードのことなど何も知らないということだ。アセンブラやマシン語を肌で知らない開発者は、自分の書いたソースコードがコンピュータに指示を与えていると思いがちだ （ 陰郎もその１人だ ）。しかし、そこにはコンパイラが介在しており、コンピュータはコンパイラが作ったオブジェクトコードしか見ていない。本当に機械語のレベルで考えたり追跡したりできる開発者なら、この案件の原因や対処についてきちっと論証できたかもしれない。しかし、陰郎には最後までできなかった。ただ必死でマップファイルやアセンブルリストで 「 位置 」 を追っていただけだ。最後までコンピュータの目線まで降りることはできなかった。

　．．．以上が、２年前に陰郎が経験した案件の顛末である。これは陰郎が覚えている限り、この10年間の仕事で 「 解決 」 できなかった唯一のバグであり、こてんぱんに敗れた上に 「 結果オーライ 」 という皮肉な結末が添えられた案件だ。陰郎はこの件をずっと忘れないだろう。

投稿者 kagelow : 23:50 | コメント (5)

2007年05月01日

下準備、あるいは空回り

　今仕事をしている職場は、インターネットに接続できます。なので、昼休みやちょっとした空き時間など、思いついたことや書き留めておきたい設計上のアイデアを自分の開発用隠しサイトに書き込むことができます （ 本日、日中帯は暇だった．．． ）。それ自体は開発ではありませんが、下準備というか、設計の取りまとめ作業というか。まぁとても大事なことだと思っています。実際にコンパイラやデバッガを前にするとコードにかじりついてしまいますからね。気がつくとコードだけが何週間も先走ってしまい、詳細の検討やドキュメントが置き去りにされてしまったりするわけです。だから、設計はできるけれどもコードは触れない、そんな時間があるというのは大事なことなのです。

　しかし。逆にそんな時間ばかりというのも考え物。完全に煮詰まってしまいます。空回りを始めてしまうわけですね。そうなると今度は設計も進まなくなる。なんとまぁ扱いにくいことでしょうか。どんなことにも当てはまるのでしょうが、大事なのはバランス。ま、開発者というのは放っておけばコードに立ち向かってしまう生き物です。その意味では多少の「おあずけ」状態の方がいいのかもしれませんね。

　．．．と、思わぬ深夜残業で何もできなかったのでこんなエントリでお茶を濁します。ごしごし。

投稿者 kagelow : 23:59 | コメント (0) | トラックバック

2007年04月30日

4月の反省会

　．．．といっても１人でやってますが。

　えぇと。まずはこの３連休ですが、いまひとつエンジンが回りきらないまま終わってしまいました。いまだに４月上旬までの激務の疲れが抜け切れていない．．．というのは言い訳になりませんね。いくらなんでも。

　冷静に数えてみますと、４月は２週間しか仕事していません。正確には13営業日です。それ以外は休みだったわけですが、全体的に見て休息するのが精一杯というところでした。はい。一応開発は進めていますが、自分としては納得の行かない進捗でした。５月はもっと頑張りましょう。まる。

　で、５月はといえば連休は仕事です。そこから先のことはわかりません。見えていないのです。というか、６月以降の仕事も見えていません。急にジョブレスになってしまいそうな予感。どういたしましょう。（汗

投稿者 kagelow : 23:00 | コメント (0) | トラックバック

2007年04月23日

鶏==卵、あるいは透過性と等価性

　．．．などという考えにとらわれてしまいました。ちなみに夕べは4時頃まで眠れませんでした。

　「 鶏が先か卵が先か 」 といいますが、今回陰郎に取り憑いたのは、「 式が先か値が先か 」 というものです。式はその計算（＝評価）の結果としての値を持ちます。その意味で式は値に推移できますが値は式には推移できません。値は値です。となると、式ありきで結果としての値がある．．．ということになるのですが。

　しかし、値 （ というか式と見なされないような単一のリテラル値 ） も、「 その値自身を返す式 」 と見なしたらどうでしょう。すると、式も値も、統一的に式と見なすことができますよね。となると、どちらが先かとか、式と値を区別するという考えを捨てて、両者を等価なものとして透過的に扱う方がシンプルで良いということになります。式は値であり、値は式である、と。

　．．．不真面目に思われるかもしれませんが、簡単な構文解析処理を考えていたらそんな感じになってしまったのです。しかし、その方式だとまたシンプルに作れるのです。式も値も 「 式 」 として抽象化してやれば、複雑に階層化された構造の式も容易に扱うことができるわけですね。イマイチまとまりのない文章ですが、ひとまずそんなところで。

投稿者 kagelow : 23:45 | コメント (4) | トラックバック

2007年04月21日

プログラムと子供は夜作られる？

　あー、なんか頑張れた気がする。昨日は、多分17時くらいから開始。夕食のあと気持ちが萎えそうになったのを無理矢理続行。その後は奇妙なバグにハマったのもあって開発端末にかじりついてました（物理的にではなく）。

　そんなこんなで寝たのは朝の６時。あー、徹夜するとやっぱり捗るわぁ。昼間は選挙屋たちがうるさいしねぇ。そういえば先日、区議会選挙の広報（候補者達の書いた原稿が載ってるやつね）がポストに入ってましたが、あの広報の方が余程参考になるわ。近所迷惑も顧みずに大音量で名前ばかり連呼しおって．．．ま、それはそれとして。

　プログラムと子供は夜作られると言いますが、やはりこれは真理なのでしょうかねぇ（子供は余計だろう）。なんといっても、静かで長時間集中できる。やはりこれが大事なところなんでしょうね。加えて、日中帯は静かでもなんとなく気が散るんですよ。人間のサガなんですかねぇ。

　問題は、２日後の月曜日から社会人の日常に復帰せねばならんということ。嗚呼、体内時計が狂いまくりです。（汗

投稿者 kagelow : 13:40 | コメント (0) | トラックバック

2007年04月19日

衰えを感じるとき

　数日前に （ 別のアプリ開発のために ） 中断した作業を再開しようとして、「 どんな状態だったか 」 をさっぱり思い出せないとき。

　．．．途方に暮れる。そして、中断したそのときの状態に自分を戻すのにかなりのエネルギーを消費する。なんとか作業を再開できても、何か肝心のことを忘れているような、そのために微妙なバグを仕込んでしまいそうな、そうでなくてもマズいデザインで実装してしまいそうな、そんな不安をひきずりながら作業をすることになる。

　衰えたかなぁ、と思う。ソフトウェア開発者は20代がやはり華である。陰郎などはもう引退せねばならん。若い世代に次を託さねば．．．とか思う。悲観的とかいうのとは別の次元で、5年前の自分を思い返すと剃刀のように鋭い思考をもっていたように思う （ 多分過去を美化してるだけだが ）。今の自分は、といえばすっかり集中できなくなった。散漫で、鈍重な思考をずるずると引きずっているだけだ。

　なんとなく、クスリに手を出す人間の気持ちがわかるような気がしてきた今日この頃．．．いや、やらないけど。

投稿者 kagelow : 19:00 | コメント (1) | トラックバック

2007年04月18日

お風呂であんなこと

　陰郎は自分の開発作業用にプライベートな wiki サイトを持っています。そこで開発中のアプリの計画や記録を管理しているのですが、これのおかげで開発がとてもやりやすくなりました。ネットにつながる職場環境にいた頃は仕事中でも思いついたこと （ またそういうのが多いんだな ） をさっと記録できたし、なんなら外出中でも Palm から接続して．．．なんてこともできるからです。まぁ、外出中は Palm に入力して帰宅後整理するのが 「 王道 」 ではありますが。

　ところで、陰郎は風呂が嫌いです。　．．．いや、不潔なのは想像しないでください。湯船に湯を張って浸かるのが苦手、という意味です。普段はシャワーで済ませます。最大の理由は、時間が惜しい。これに尽きます。基本、風呂に入っているときは何も出来ないじゃないですか。冷えた時や疲れが溜まってきたときは、半身浴をしながら本を読みます。それでもなんとなく時間が勿体無い気がして、なかなかそういう気にはなりません。かくして、冬の間でも陰郎はシャワーで済ませる毎日だったのです。

　しかし。今日ふと気付きました。先日無線LANカードで復活したあのノートPC、あれを風呂場に持ち込めば、実装までは無理としても設計ならばできるのでは？　やってみたところ、これはナイス。半身浴でものすごい長風呂をしました。というか、しながらこれを書いています。無線LAN経由でプライベートwikiサイトに接続し、設計をまとめたり色々考えたり。なによりも良いことは、設計や記録管理はできるが開発（というか実装）はできないこと。どうしても、コンパイラがある環境ではそっちに行ってしまうわけですね。でも、ノートPCだけであれば実装やテストは無理。設計や記録の管理に集中できます。これなら長風呂も楽しいかもしれません。

投稿者 kagelow : 01:00 | コメント (2) | トラックバック

2007年04月16日

書け！　書きまくれ！

　．．．というわけで、えっちらおっちらと開発中の陰郎です。勢いがついてしまうと今度は止まるのが大変なわけでして、家事やら生命維持やらがおろそかになっています。しかも、勢いがちょっと違う方向に進んでいるのでなんとかせんと。

　あ、そういえば、またもや書籍を２冊ほど 「 ぽちっ 」 としてしまいました。数日のうちに黒猫の大和くんが届けに来てくれるでしょう。４月に入ってから本にいくら使っとるねん．．．というくらい買ってますな。いかんいかん。

投稿者 kagelow : 22:30 | コメント (0) | トラックバック

2007年04月15日

波に乗ってくると

　更新が滞る陰郎です。

　．．．まぁ、致し方ないのかもしれませんけどね。目の前に積みあがったものと、それより先にあるものに興味を奪われつつある現状、「 休暇 」 という名の思いのほか作業が進まない期間．．．人間と言うのは難しいものです。

　そんなわけで、ちょっと書くことがありません。そういえば、今年はまだ１本も作品を発表できていないような．．．嗚呼。

投稿者 kagelow : 23:00 | コメント (0) | トラックバック

2007年04月11日

陰郎も愛用しています

　ちょっと紹介が遅れてしまいましたが、MEGASOFT 社のエディタ MIFES for Windows が Version 8.0 になりました。

http://www.megasoft.co.jp/mifes8/

　何故に陰郎が MIFES エディタに肩入れしているかは、過去の記事を読んで頂ければわかると思います。最近はどんどん Emacs/Meadow の深みにハマっていってますが、それでも陰郎にとって MIFES エディタはなくてはならない存在。もちろん Version 8.0 にバージョンアップするつもりですよ。

　皆さん、良いエディタを使いましょう（ 『良い』の基準はもちろん人それぞれですが ）。

投稿者 kagelow : 22:30 | コメント (2) | トラックバック

復活したい陰郎

　休みに入って３日目。

　なんとか寝たきり生活からも立ち直ろうとはしています。そうなると早く開発に復帰したい！　と思うのですが、どうにも気力が戻ってきません。開発端末の前に座って、いざ Codewarrior を立ち上げるぞ．．．というところまでは行くのですが、うむぅぅぅなどと呻いてうなだれています。なにゆえに動き出せないのか。

　原因ははっきりしています。第一に気力の減退。そして第二には時間が経ちすぎたこと。これに尽きます。そうはいっても始めてしまったものは終わらせにゃなりません。着手したのに断念するのはイヤです。「なんとかする」と決めたプロジェクトは、実はもう４つ積み上がっています。着手しているのはそのうち２つ。残りの２つは着手することに決めたもの。さらに、検討中のプロジェクトが４つあります。嗚呼。

　Palmware 開発で生計を立てられんものか．．．と思い悩む 32歳でありました。

投稿者 kagelow : 17:00 | コメント (1) | トラックバック

2007年02月19日

気が触れたように

　．．．この週末は Palmware 開発に耽っておりました。結果、ソースファイル数は 110 ファイルに到達。まだまだ行きそうです。

　最近はまったく周囲の状況についていけていないのですが、ひとまず．．．

　MA-CY さんのところでレーシング双六が大幅なバージョンアップを成し遂げたようですね。現状のんびり楽しむ時間が無いのが残念ですが、一区切りついたら楽しませていただきます。是非 OreCa 対応も！

　そういえば、ちょっと私信ですがたいちさん。先日新横浜で話した 「 あれ 」。そう、○○を正しく処理できる「 あれ 」、春以降を目処に作ろうと思ってるんだけど．．．

　今週は是非お会いしたいと思っていたあの方と会うチャンスがあります。楽しみです。

　さぁ、春のセルフ納期に間に合うか．．．現在作成中の Palmware 。うん、頑張る。

投稿者 kagelow : 01:00 | コメント (5) | トラックバック

2007年02月09日

冷徹に進め

　仕事が忙しい。理不尽に忙しい。今日も帰宅し、粗末な夕食を作って食べている間に日付が変わった。

　眼精疲労も限界に来ている。でも、ここで手を休めるわけには行かない。春にリリースする予定で開発中の Palmware、少しずつ仕様的に肥大化し始めているため、このままでは間に合いそうにないのだ。この時間からでも、１時間でも３０分でもいいから前に進めて行かなければ．．．

　こういう状況で一番必要なのは冷徹さだ。自分の健康状態とか、ストレスとか、そういうものに蓋をしてしまうのだ。そして開発の中盤戦で感じる不安にも冷たい態度をとる必要がある。そうでないと怖気づいて前に進めなくなるのだ。そうはいっても、冷めた気持ちでことにあたるというのとは違う。「 冷静に、熱くなれ 」 と言ったのは誰だっただろうか。要するにそういう感覚だ。

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2007年01月21日

というワケで Technote

　結局購入してしまいました。紙にペン入力した内容をデジタルデータとして取り込むことができるデバイス、Technote であります。黒・赤・青の３色が使えるのは世界初なのだとか。しかも PC と接続した状態ではペンタブレットとしても使える．．．と。ふむふむ。

　第一印象としては、『思ってたより大きいな』という感じです。用紙サイズは A5 ですが、本体を付属のケースに入れると A4 サイズくらいでしょうか。実際に A4 の用紙と並べてみました。たしかにそれくらいの大きさがありますね。

事前にネット上にあるマニュアルを読んでおいたので、電池を入れてすぐに使うことができました。

　最初に感じたことをいくつか書きとめておきます。

1) 背面の電池を入れる部分の蓋ですが、ネジ止めは正直キツいです。最初の段階で付属のドライバーで締めようとしたらネジ山が潰れそうになりました。なので恐くてネジ止めしていません。ペンの替え芯も入っていることだし、ネジ以外の方法で蓋を留める方がいい気がしました。

2) ペンは芯と電池を交換することで使い続けられるワケですが、肝心のペン本体が樹脂製で少し不安を感じます。予備が購入できるなら何本か手元に置いておきたいですね。

3) 別売品としてでも良いので、３色のマルチペンタイプのものがあるといいなぁと感じました。

　

　昨夜は MobilePLAZA でこれを購入し、その足で新横浜へ向かったわけですよ。ものは試し、居合わせた Palm 好きなナイスガイ達に一筆よろしく。鶴丸さんはお絵描きもしてくれました。

　皆酔っ払いでしたからもう適当な感じですね。陰郎なんて自分の名前を書き損じてます。良く見たら鶴丸さんも mokomok Voice になってますがな。わはは。

　．．．で、今朝帰宅して、初めて PC に接続してみるわけですよ。GIF には変換できないみたいで、BMP 形式で保存してから Photoshop で GIF 形式に。どんなのができたかというと、こちらをご覧ください。

　まぁそんなわけで、ひとまずは使えそうです。作成中の Palmware の設計図面も書いてみたのですが、ネタばれになってしまうので今回は掲載できません。でも、設計図のラフスケッチを描くにはいい道具になりそうです。

投稿者 kagelow : 12:00 | コメント (7) | トラックバック

2007年01月20日

ひさびさに 「 欲しい 」

　MobilePLAZA さんで、Technote なるものが販売されていることを知った。普通紙を重ねて専用のペンで書き込むとそれがデジタルデータとして記録されるというものらしい。しかも３色使い分けられるとな。

　．．．というわけで、ひさびさに 「 欲しい 」 と思ったわけです。が、ここはひとつ冷静になりましょう。なになに、USB 接続だが、プラグ＆プレイのペンタブレットとしても使えるとな。逆に言えば mass storage device としては認識されないのね。描画データについては専用のソフトで取り込み、PC上では独自形式、BMP、JPG、GIF ．．．と。うーむ、デバイス側で保存形式を選択できて、mass storage device 認識で PC にはコピーするだけ、というのが個人的には好みなのだが。惜しい。

　ちなみに、「市販のボールペン用替え芯に対応」とあるが、製造元サイトの仕様や FAQ を見ると、どうやらペンの方にもボタン電池を入れる必要があるらしい。つまり、インクが特殊なのではなく、ペンが特殊。市販の替え芯が使用できるが、ペンを替えることはできない．．．使い慣れたペンを使用したいのだが。うーむ、惜しい。でも、でも。

　あー、これで UML 図を書きたいぃぃ．．．

　．．．というわけで、やっぱり欲しい．．．ような気がする。

投稿者 kagelow : 12:30 | コメント (1) | トラックバック

2007年01月13日

複雑性との闘い

　これまでも散々書いてきたのでご存知だとは思うが、陰郎は C++ がネイティブ言語である。よってクラス、多態、多重継承、名前空間、例外処理、テンプレート、階層化、演算子オーバーロード．．．などなど、使える言語機能は何でも使う。おっと、Palmware 開発では例外処理だけは使わないようにしているけれども。

　それぞれの言語によって提供される機能、あるいはその言語が持つ思想は互いに異なる。そのため、開発やデザインのアプローチは当然違ってくるわけで、ある程度規模の大きなソフトウェアを書くとなれば相応の複雑さと闘わなければならない。そのために言語が持つさまざまな機能を利用することで、言語特有のいわゆる 「 色 」 が出てくるわけだ。これはいろいろな言語で "Hello world" を書いてみた経験だけではわからないことである （ 当たり前だが ）。

　時折出くわすのが、「 C++ ができるならどんな言語でもできるでしょ？ 」 という言明だ。しかし、陰郎は可能な限りこれに対して 「 No 」 と答えるようにしている。ここで問いに含まれる 「 できる 」 という言葉の意味を軽んじてはいけない。おそらく発言者の基準では、陰郎は 「 Yes 」 と答えるはずなのだ。その人にとっては 「 できる 」 はその程度の意味なのだ。しかし、陰郎にとっては 「 No 」 である。

　確かに C++ は言語として大きいし、他の言語でできて C++ にできないことはほとんどないと言って良い。しかし、複雑性を制御し、ソフトウェア全体の構造を良い状態に保つためにその言語が持つ機能をフルに利用する人間というものは、その言語の機能に丸ごと （ 表現は良くないが ） 依存するような傾向のデザインをするものだ。自分の専門言語があまりに体内に浸透しているがゆえに、他の言語を触るときにいろいろな問題が発生する。その言語では使えない機能があることにフラストレーションを感じたり、逆にその言語にはある便利な機能を自然と避けてしまったりする。自分の専門言語が直接サポートする言語機能を模倣したいがためにいびつなプログラミングをしてしまう場合もあるだろう。陰郎の基準では、それは 「 できる 」 ことにはならないのである。たとえ、正しく動作するソフトウェアを書くことができたとしてもだ。その言語で 「 考え 」、その言語の機能を 「 正しく 」 使い、適切なデザインを自然と行うことができる．．．そうなって初めてその言語を使える、ということになるのだと陰郎は考えている。

　．．．勢いで書いたので散漫なエントリになってしまった。現在作成中の Palmware、まだ道程の半分程度なのだが、ヘッダファイルとソースファイルの合計が 70 ファイルを超えた．．．記憶している限り、RPNToGo で約 70 ファイル、PipeWorks で 110 ファイルくらいあったはずだ。おそらく、過去最大規模になるだろう。RPNToGo や PipeWorks はデザイン上浅く広い継承階層ができていたためにファイル数が多くなったが、今度のはそうではない。純粋に機能性が高いのだ。

　今度の旅は長くなりそうだ．．．

投稿者 kagelow : 23:30 | コメント (0) | トラックバック

2006年12月30日

2006年総括

　今年もいろいろあった。いろいろやったし、いろいろできなくもあった。そのへんを総括するぞ．．．と、去年と同じ文章で。

・ Palmware 開発

　今年は、Palmware 開発ではあまり動けなかったなぁ．．．と思いつつバージョンアップ作品も含めて並べてみたところ、９本あった。うちバージョンアップ作品は３本。３ヶ月に２本のペースか。なんだ、結構やってるじゃないですか。

BlackBox version 1.00
ReplacedDA Version 0.71
ListMakeDA Version 0.70
BracketsDA Version 0.73
RPNToGo Version 1.02
FEPSwitch Version 1.00
DIAFEPSwitch Version 0.96 beta
Mathphilia Version 1.10.001
PalmLife Version 0.95.001 beta

　作品以外では、やはり Palm Programmer's Laboratory を挙げないわけにはいかないだろう。今年の作品のうち、DA ３本はいずれも PPL と深く関係のあるものばかりだ。まぁいろいろあったし、いろいろな思いもしたが、総じて今後も頑張っていく価値のあるものだと思っている。また、PPL のおかげで wiki の勉強ができた。その意味でもまた感謝している。

　

・その他の開発

　今年は、Palmware 以外の開発では以下の２つがバージョンアップとなった。

WinLife Version 0.95
VBGeneric Version 1.03.356-001

　去年の総括では、「 もうないだろうと思っていた VBGeneric ライブラリのバージョンアップがあった 」 と書いた。今年はもうないだろうと思っていたが、やっぱりあった。来年こそはもうないだろうと書くのは信憑性がアレなのでやめておこう。過去10年でもっとも思い入れのある作品ではあるが、残念ながら普及という意味では成功とは言い難い。あれを使いこなせると、Visual Basic や VBA のプログラミングが劇的に楽になるのだが．．．まぁ能書きはよそう。

　Palmware 以外の活動といえば、regex++ がまたもや忘れられつつある。VBGeneric を超えるのではないかという内容の未完の大作ライブラリだ。ReplacedDA 向けに移植しようという目論見があったのだが、さすがにニーズが無さ過ぎるっぽいという理由で無期限延長状態である。嗚呼。

　

・さらにその他の活動

　project-graphica のことは記憶から消えつつある。関わっていたバンドも解散してしまったので、なおさら被写体が減ってしまった。ひとつだけ良いニュースは、ドラムの離脱で活動を休止していた名古屋の 「 ごくつぶし 」 が新メンバーを迎えて再始動したことだ。最近は東京よりも横浜にライブに来るので、残念ながらなかなか撮影できない。残念だ。

　開発関連の話題に戻るが、今年は UMTP の UML モデリング技能認定試験の L1 を受け、合格した。受験の１週間後くらいに認定証が送られてきたが、何年も UML を使い、簡単ながらもツールまで自作している陰郎にとっては L1 合格など当たり前である。時間を見つけて早く L2 を取得したいし、L3 の試験も早く始めてもらいたいところだ。

　

　そういえば、今年の始めに 「 抱負 」 と称して 「 今年は Palmware 以外の開発も復活させる 」 という目標を立てた。それがどうなったのかを書かなければ、とても総括とはいえないだろう。白状すると．．．自分としては、やりたかったことの半分もできていないというのが本当のところだ。ここは今年の反省点である。この反省を活かし、来年はあまり大きな目標を立てるのはやめよう．．．ではなく、来年こそバランスの良い活動を心がけよう。

　そんな思いとは矛盾するようではあるが、来年はかなり大きな Palmware の開発に取り組む予定でもある。詳細は現時点では伏せざるを得ないけれども、かなり気合の入った内容とボリュームになりそうだ。うん、がんばる。

　．．．というわけで、このエントリをもって project-enigma の今年の活動は終了する。今年頑張った人も頑張れなかった人も、来年が良い一年になることを願う。頑張る気がさらさらない人は、来年が良い年になるなどと不相応な希望を持ってはいけない。せめて人様に迷惑をかけないように．．．というのも去年と同じ文章だ。

　ではまた来年。

投稿者 kagelow : 03:00 | コメント (0) | トラックバック

2006年12月20日

走り出して躓くとか

　開発をやっていると、急にアイデアが浮かんできたり、もやもやとイメージしていたものがものすごい勢いで具体的な形を取り始めることがある。そうなるとこれがまた大変なことで、頭の中で形を変え続けるものをなんとかしてまとめるために急いで PC に向かったりするわけだ。陰郎の場合、基本的には設計図は UML で書いている。専用のツールは持っていないが、Microsoft Visio で過去に自作したステンシルとマクロがあるので、それを使って作図するわけだ。インプレレベルの定義を作成すればソースファイルのスケルトンまで自動生成できるんだぞ。えへん。

　．．．というわけで、Visioを起動して．．．あれ、起動しない。というか、見つからない。嗚呼そうだ、開発PCの再構築をしたんだった。あの日以来 Visio は使ってないんだ。だからインストールしていないんだ．．．というわけで夜遅くになってからインストール作業でございます。勢いづいていた思考はすっかりスローダウン。内心うなだれながらこのエントリを書いているのでございましたとさ．．．

投稿者 kagelow : 23:00 | コメント (0) | トラックバック

2006年12月10日

FSWiki、あるいはLinux上でのPOBox

　wiki というものに親しむにつれ、自分のサイト全体を wiki 化してしまおうかと考えるようになってきています。別段複数の人が更新できるようにとかいう目的があるわけではなく、個人としての更新・管理コストの省力化が目的ですね。

　そんなわけで、自宅に作成した Linux 環境上で FSWiki を設置していろいろ試しているわけですが、設定ファイルを編集する際に陰郎としては当然 Emacs エディタを使用するわけです。しかし、今日になっていろいろな設定をしていないことに気づきました。よく考えたら、以前使用していた Redhat 環境で整備した .emacs ファイルを持ってきていません。さらによく考えたら、POBox も移設していません。そんなわけで、昔の Redhat 環境を引っ張り出してきてせっせと設定をしてみました。うん、快適。

　で、FSWiki に話が戻るわけですが、サーバ上で直接編集できるということは、ローカルにコピーが存在しないということになるわけです。当たり前ですが、だからこそ省力化になるわけで、バックアップのためにわざわざ FTP ソフトを起動しなければならないようではマズいと。更新に比べてバックアップが面倒であればついおろそかになってしまいかねません。だから簡単にバックアップがとれ、簡単にダウンロードできるようになっていなければならんわけです。

　とまぁそんなことを考えてバックアップを自動化する CGI を以前書いたわけですが、これが原始的な割りに便利なやつでして、ブラウザ上から CGI として実行すると指定ファイルを tar ball に固めてくれて、ついでにダウンロード用のリンクを表示してくれるんです。しかし、逆に言えばそれだけなのでバックアップファイルがサーバ上に残留するんですね。陰郎が借りているサーバはいまいち手狭なところなので、バックアップファイルをダウンロードしたらさくっと削除したいわけです。今日はそこのところをイジっておりました。具体的には、もう１つ CGI を用意して、それを起動するとバックアップファイルをサーバ上から削除してくれる．．．と。ふぅ。

投稿者 kagelow : 23:40 | コメント (0) | トラックバック

2006年12月09日

L1の試験を受けてきたよ

　今日の試験は11時半。時間の30分前に到着してみると、なんと試験センター閉ってます。どうやら開館自体が11時らしいので、もう少し待っていれば開くのでしょう．．．と思って待っていたわけですが、11時を過ぎても開く様子がありません。さすがに不安になって電話してみたところ、担当者が遅れているのだとか。

　11時10分頃に担当者到着。手続きをして L1-T1 の試験を 11:20 に開始。．．．欠伸の出そうな試験でした。全問回答してさらに１回見直しても30分。もういいやという感じで終了。結果は．．．といえば98点。なんと１問間違えてしまいました。シーケンス図の問題で曖昧なのがあって見直しの時に修正したのが祟ったらしいです。コンプを逃してしまいました。嗚呼。

　予定時刻よりも早い着手は問題ないらしいので、近くのカフェで休憩し、予定より１時間ほど早く L1-T2 試験を受験。こっちは90分試験です。回答と全問見直しで50分程度かかりましたが、結果は 100点。全問コンプです。こうなると、なおさら L1-T1 の１問ミスが悔やまれますね。まぁ終わったことです。胸を張っていきましょう。

　さぁ、次は L2 だ。

投稿者 kagelow : 15:15 | コメント (0) | トラックバック

2006年12月08日

というわけで L1 受験

　わぁ、資格試験って久しぶり♪

　．．．というわけで、UMTP の L1 を受験することにしましたよ。明日。なぜなら、オンラインで予約して翌日でも受験できるからです。L1 は T1 と T2 の２つに分かれていますが、明日は１時間のインターバルを置いて２つとも受験することに。

　何で２つも唐突に、かつ気軽に受けられるかというと、例の L1 の学習書、設問を解いても模擬試験を解いても、ほとんど間違えないからなのです。まぁオージス総研の認定試験の頃ゴールドまでとってますし、UML は日常的に使ってます。何でいまさら L1 を．．．というくらい慣れている人間には簡単なのですね。

　だったら最初から L2 受ければいいじゃん、と思うでしょう。陰郎もそう思いました。L1 の受験料もったいないですし。ところが、L1 認定を持っていないと L2 を認定されないのですよ。恐るべし資格ビジネス。陰郎はこういうの好きじゃありません。好きじゃありませんが必要経費と思って我慢することにします。

　ここで思い出すのが、オージス総研がやってた UML 技術者認定制度の合格者に L1-T1 を免除するという話。陰郎自身、確かに移行手続きをした記憶があるのですが、過去メールをひっくり返しても免除IDを発見することはできませんでした。仕方ありませんね。よよよ。

　そんなわけですので、明日は試験２つ、一発合格してきます。ここまで書いてどっちか落ちたらすごく恥ずかしいですが、そこはそれ、自分を追い詰めるいつもの段取りってことで。

　

投稿者 kagelow : 21:50 | コメント (0) | トラックバック

2006年11月26日

熱中症

　季節はずれなタイトルかもしれませんが、書きたいことは全然違います。何かというと、PC に向かって何かを作っているとき、考え込んでいるときの陰郎の熱中状態のことであります。とにかく没頭していると忘れるんですよ。たとえばお茶。陰郎は紅茶が大好きで、茶葉を湯の中で２分ほど泳がせてから飲む（飲む前には茶葉を取り除かないと渋くなってダメ）のですが、セットしてから PC に戻って作業を始めると茶のことを思い切り忘れます。半端じゃなく長時間たってから思い出すので、渋みが出ちゃって飲めなくなったりするんですね。えぇ今日も２回やってしまいました。

　まぁお茶なら淹れなおせば済むんですが。PC に向かって作業している陰郎には頼みごとをしない方がいいでしょう。

投稿者 kagelow : 15:00 | コメント (0)

2006年11月21日

心の平穏

陰郎は悩んでいる。

　久しぶりにゲームの開発に戻って、それなりに順調だ。体調が優れないのは気になるもののそれは今に始まったことでもないし、何もかもそれほど驚くには値しない。心配事といえば、今年に入ってからめっきり自分という人間が摩耗してしまったこと、さらに言えば自分がそれを自覚するようになってしまったことだろう。思うに、その自覚にこそ老いの始まりがあるのではないだろうか。

　社会人になってからの１０年、それなりに頑張ってきたつもりでも、心の平穏という部分で陰郎は常に静かな危機に直面してきたと思う。もちろんそれとて多くの人々と（おそらくは）同じように、だ。平穏の材料がなんであるかは人それぞれであるのだろうけれど、陰郎の場合は自分が何かの役に立てているか、あるいは自分の役割（があるとして、それ）をきちんと果たせているかどうかという問題が大きな意味を持っているらしい。自分にとって重要なことが他の人々にとっても重要かどうかはわからない。それが確固たる違い（または違いのなさ）であったとしても、それがいったいなんだろう？　そんなことは重要ではないはずなのだ。均質であることは時に耐え難いほど苦痛だが、異質であることもまた同様である。いずれに関してもそこに思い悩むことなど時間の無駄に過ぎない．．．と切り捨てることができるようになったとしたら、陰郎は心の平穏を得ることができるだろうか。それが決して無関係で無いであろうことは想像がつく。しかし、どのように関係しているのかはわからないのだ。

投稿者 kagelow : 00:30 | コメント (0)

2006年10月31日

沈みそうな船だから

　そう、どんな船だって載せてる物が重過ぎれば沈むだろう。そうでなくたって、穴でも開いて浸水してくれば、重いものから海中に投棄せざるを得ない。そんな船に乗ってたら、誰だってそうするだろう。

　陰郎だって、そうするのだよ。

　

　本日を持って、「ぱむあん。」の登録を解除していただいた。また、mixi も退会した。これらのものが不要だったのでは決してない。ただ、それくらい今現在の陰郎は焦っているということは白状しておいた方がいいだろう。正直、陰郎は沈んでしまいそうなのだ。

　あまり御託を並べ立てるつもりは無い。ただ、開発をやめるつもりは無いこと、mixi や「ぱむあん。」、またはその他の機会を通して関わった方々には感謝していることだけはここに書いておきたいと思う。大したことはできないけれど、Palm のために自分にできることはまだあると思っている。それをやるために、日陰に戻るだけのことだ。

　以上。

投稿者 kagelow : 23:30 | コメント (2) | トラックバック

2006年10月19日

ひさびさに、逆境ハイ

．．．みたいですね。本当久しぶりに。

　風邪ひいてます。仕事も忙しいです。風邪薬やらカフェインやらで軽くラリった状態で遅くまで仕事して、帰ってきてからもPCの前で唸ってたりするわけですよこれが。

　なんかこう、燃えてくるんですよね。悪条件が揃わないとやる気出なくなっちゃったのかしら。○×□じゃないとどうも△▽ないとかみたいな。あー何言ってる。

　まぁそんなわけで、ここ数日は ARMlet と戯れたり、まだここには書けないような状況のアプリの設計をやってみたり。それほど活発ではありませんが、開発者としての陰郎はどうにかこうにか生きています。

投稿者 kagelow : 23:59 | コメント (0) | トラックバック

2006年08月30日

逆境ハイ、２日目

　まだなんとか頑張っています。が、早くも息切れしてまいりました。

　うん、これが三十路なんですな、きっと。

　しかしまぁ、アレです。なんか最近 DA ばっかり作っているので、普通の Palmware の作り方を忘れてしまいそうです。ぼちぼちなんとかせんと。特にアレとアレだ。うん。

　

　脈絡のない文章で申し訳ありませんが、NS Basic な方々は年に１度のプログラミングコンテストということで盛り上がっているようですね。なんであれ多くの人たちが Palmware に取り組んでいるのを見ると嬉しくなります。他の Palm 向け開発環境でも似たようなコンテストとかがあればいいのにぃ。

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年08月29日

甘やかしちゃダメ。ぜったい。

　．．．なんだかアレなタイトルですが、要するに忙しさに甘えて開発が滞っておるのです。

　まぁ要するに自分を甘やかしてしまっているのですよ。忙しいけれどもまだ余裕があるときというのは、「 その気になりゃできる 」 とでも言いたげに 「 今日はやめて明日にしよ♪ 」 などと音符つきで先送るわけです。おんぷ付きで。

　しかし。今日も明日もその次の日もずーっと忙しいことが明々白々になってくると．．．まぁ音符なぞ出てこなくなるわけですね。焦り始めます。で、火がつくわけです。それが今日の状態。それが逆境ハイ。というわけなので無理して頑張りました。明日も忙しいので頑張れそうです。はい。

投稿者 kagelow : 01:30 | コメント (0) | トラックバック

2006年08月25日

去年の今頃は

　過去２ヶ月ほど書き忘れていましたが、月イチでやっているはずの 「 去年の今頃は 」 コーナー。あまり長々と書いている暇がないので、箇条書きで失礼します。

・ 2005/7/24　　PipeWorks リリース

　おそらくは project-enigma 謹製 Palmware としてはもっとも人気の高いゲーム。もう１年以上も前の作品なんですね。いくつか手を入れたい案件があるのですが．．．ううむ。

・ 2005/7/25　　ぱむあん。登録

　自薦できないタチの人間なので、「 登録されたらいいなぁ．．． 」 と指をくわえてみておりましたが、めでたく登録していただきました。これまた１年前のこと。この１年の間に 「 ぱむあん。 」 の管理は michieru さんから Palmwareinfo のたいちさんに移りました。御二人に感謝。

・2005/8/1
　後に RPNToGo となる作品の開発途上、「 新しい挑戦がないのでいまいち回転数が上がっていかない 」 などと書いています。実際にはその後否応無しに加速していくのですけどね。このとき、Edward Yourdon の書籍から引用しつつ、以下のようなことを書いています。うん、なつかし。

　．．．挑戦や、リスク、困難といったものは逆の意味でよく似ていると思う。大きすぎては萎縮してしまうが、まったくないのも問題だ。目をつむっていても歩けるような安全な道を歩いていれば不安はない。すべては予測可能で、安心していられる。しかし、わくわくするようなことも決してないのだ。

・2005/8/5
　「 モノクロ・低解像度 Palm はレガシーか 」 と題して書いています。このスタンスは現在でも変わっていません。RPNToGo 以降、Mathphilia や GraffitiRush ．．．と、モノクロや低解像度でも動作する（ しなかったっけ？ ） ものとしてデザインしましたし、2006 年に入ってからの DA は言うまでもありません。ワイドディスプレイと同様、「 必要としない 」 範囲で活用するというのは 「 おまけ 」 という位置づけになりがちなので残念ではありますが、そこは Palm という世界で考えないと。

・2005/8/20
　このあたりで PC故障が故障しています。ということは、今使っている PC も１年経つのか．．．

　．．．そんなわけで、１年前の陰郎は PipeWorks をリリースし、続いてアクセル前回で RPNToGo を開発している真っ最中だったようです。来年の 「 去年の今頃は 」 ではなんて書くことになるのかな．．．

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年07月26日

こっちは休刊

　えー、突然のことですが、以前仕事をしていたプロジェクトの送別会に呼ばれまして、先ほどようやく帰宅しました。なので今日はまだなんにもしていません。しかし、このまま寝てしまうと進捗ゼロになってしまいます。それは （ 自分的に ） マズいので、ちょっとがんばろーかと。はい。

　そんなわけでここに長々と書いている時間がありません。それではまた。

投稿者 kagelow : 01:00 | コメント (0) | トラックバック

2006年07月19日

相も変わらず

　ListMakeDA をちまちまと作っておりますよ。今日は一括削除機能を実装し、仕様が甘いことに気付いて一人赤面しておりました。陰郎は、夏はダメなんですよ。すっかり季節を先取りして夏バテしております。もう、何を食べてもお腹壊すの。テキメンですよ。そのくせ痩せないんだから困りものです。先日は知人の結婚披露パーティーに出席してきたのですが、食べ物には一切手を触れられず。水分だけ取っていましたが、それだけでもやっぱりお腹が下るんですな。嗚呼、機械のカラダが欲しい．．．

　さて話を戻して。陰郎がそんな状況なので、まぁ遅々として進まない ListMakeDA ですが、残すところは仕様の詰めがいくつかと、あとはリストの編集機能ですね。これについては SDK スタイルでやったことが無いのでいささか面倒に感じる、というのが正直なところでございます。でも、なんとか一区切りつけないと次にいけませんし。頑張らないとね。

　ところで。

　陰郎にとっては、日々の開発作業で蓄積される情報を管理するための場所というのは非常に重要なものであります。過去においてはこの日記がそうであったのですが、日記はやはり日記。それに、リリースまでは人目に晒したくない情報というのもありますから、別の場所が必要だったのですね。そんなワケで、自宅の PC にそのような環境を作りまして、そこでカチャカチャとやっております。そうなるとこの日記に書くのはどんな内容であるべきでしょ？　まぁいろんな意味で表に書いて差し支えないことでしょうね。PPL は PPL で、あれはパブリックな場所ですから。パブリックスペース。すなわち大人の社交場。ノーネクタイでも構いませんが、礼儀知らずはお断り、と。うん、いいね大人の社交場。男ばっかりだけどね。（笑　　．．．さらに高級感を出すために、会員制にしちゃどうだい？　（笑

投稿者 kagelow : 00:20 | コメント (0)

2006年07月16日

復帰するよ

　はい、復帰します。

　．．．といっても、この日記を書いていなかっただけで、陰でごそごそやってたんですけどね。おもにアセンブラで遊んでいました。いや、アセンブラに遊ばれていたという方が正しいか。（汗

　まぁそのあたりのこともぼちぼち書いていこうと思っています。今後も更新が滞るようなこともあるかもしれませんが、まぁ内容が内容ですのでそれなりに。

投稿者 kagelow : 01:30 | コメント (0) | トラックバック

2006年07月12日

一身上の都合により

　２・３日、お休みをいただきます。

投稿者 kagelow : 00:00 | コメント (0)

2006年07月08日

半歩ずつでも、毎日。

　昨日は、「 できるだけ速く 」 と書いたものの、やはり速度は上がらない。仕事して、食事して、帰宅して、家事をすませ．．．そこから寝るまでの短い時間が勝負なのだ。できるだけ速くといっても、その頃には急ぐほどの元気は残っていない日が多いとしても。

　しかし、それに続く台詞は昨日と同じだ。悠長なことは言っていられない。今、一番大事なのは、「 半歩ずつでも毎日 」 という姿勢。元気がなくても、時間が無くても、進捗ゼロは許されない。ミリ単位でもいいから、常に脳内の開発情報のキャッシュをリフレッシュし続けなければ、再開すらおぼつかなくなる。

　その意味では、今週はまぁまぁ良い状態といえるだろう。小刻みながら、ListMakeDA を version 0.01 から 0.04 まで小刻みにリリースできた。もちろん試作品だけれども、確実な前進があり、フィードバックを得られる状態が続いているのだ。PPL の存在には改めて感謝である。

　さて、以前書いたかどうか覚えていないが、ListMakeDA は内部構造的には新しい試みがなされている。それは、陰郎が FortuneDA++ で実験した、C++ による簡単なフォームクラスによる実装である。仮想関数が使えない DA でもクラスと継承を使用して実装するのには少々苦労があった。おそらくあのような構成で実装されている DA はこれまで存在しなかっただろうし、あれを叩き台にして ListMakeDA を作成しているからこそ、SDK スタイルが苦手な陰郎でも小刻みに DA を発展させられる。C++ をやっている Palmware 開発者の方は、是非 FortuneDA++ のソースコードを参照してみてほしい。 FortuneDA++ は PPL のこのページからダウンロードできる。

投稿者 kagelow : 01:00 | コメント (0) | トラックバック

2006年07月06日

考え中．．．

　思うところありまして、今後のことを色々と考えております。

　．．．あ、開発はやめませんよ？　そんなことしたら何も残りませんから。哀れなもんですね。

　今は、日々の時間の使い方から余計な贅肉をそぎ落としたいのです。

　考え中．．．

　

投稿者 kagelow : 00:30 | コメント (0) | トラックバック

2006年07月02日

Linux とかのお勉強

　えぇと、本日はちょいとわき道へそれまして、Linux のお勉強をしておりました。ちょっと離れると、もう全然変わってるのね。最近は昼間の仕事でもやれ Apache だ Tomcat だといっているんですが、仕事自体は Solaris なんで、やっぱり Linux は匂いが違う。どちらも別に臭いわけではありませんが。

　．．．そんなワケで、本日は Palmware 開発関連の作業を何もしないまま．．．です。明日からまた頑張りますよん。

投稿者 kagelow : 01:30 | コメント (0) | トラックバック

2006年06月30日

エッジは何処だ

　以前、「 もっともっとエッジに！ 」 と題して所信表明めいたことを書きました。その直後に Palm Programmer's Laboratory が開設され、およそ１ヶ月が経過．．．というわけです。あ、そういえば今月は 「 去年の今頃は 」 を書いてないな。

　それはそれとして。その所信表明から１ヶ月が経過したわけです。陰郎は 「 エッジのギリギリのところ 」 にいたいと、確かにあのときそう書きました。そして１ヶ月。いろいろと目まぐるしくもありましたが、ひとまず頑張ってはきました。試作品も含めると、RPNToGo のバージョンアップ、BracketsDA、AlertEX、DPadInput、ApptCountDA、draggable な FortuneDA のサンプルから FortuneDA++ へ．．．PPL の活動が多いですが、それとて重要な活動です。

　．．．それでも、開発という点に関していえば、今でも陰郎は渇いています。エッジのギリギリまで寄ったつもりでも、目を凝らせばまだまだ距離があるように見えてきます。不思議なものですね。際限なく追い詰め続けなくちゃ満足しないのでしょうか。いいんです。ビョーキですから。

投稿者 kagelow : 01:15 | コメント (0) | トラックバック

2006年06月20日

クロスオーバー

　互いに平行な２直線でさえ、「 無限の彼方で交わる 」 などと表現されるわけですから、陰郎がこれまでの短い人生で取り組んできた、まったく無関係 （ は言い過ぎ ） な２つの開発だって、ひょんなことから交差してしまうこともあるわけです。Palmware に取り組み始めて１年、ずっと放置してきた自作正規表現エンジンを Palmware に組み込んでしまおうという新しい狂気が生まれました。合掌。

　最初はそんなこと考えもしなかったんですけどね。しかし、以前 ARMlet を組んだとき以来、ARM ネイティブコードなら結構ヘヴィな仕事も Palm にさせられることには気づいておりました。あとはネタさえあればよかったわけです。そして、そのネタがやってきたわけです。そう、検索・置換 DA です。

　．．．で、まぁやることに決めて色々と準備をしておるわけですが、一昨日も書いたとおり、色々と不安要素はあるわけでして。DA で ARMlet という不安でしょ。複数画面ある DA を SDK スタイルで書かなきゃならない不安でしょ．．．あ、あともう１つ気付いたんだ。マルチセグメントコードリソースで DA は作れるの？　とか、ね。さらにさらに、自作の正規表現エンジンを CodeWarrior でコンパイル通すのにどれくらい作業が発生する？　とか （ これまでは Visual C++ 6.0 で開発してました ）。

　でも、頑張るのです。はい。

投稿者 kagelow : 00:40 | コメント (0)

2006年06月03日

wiki の勉強もするのですよ

　なんかもう、いろいろなモノがいっぺんに動いていて目が回りそうです。ひとまず Palm Programmer's Laboratory。とにかく wiki に慣れなきゃいけないってんで、いろいろと勉強中です。

　実は、自分のサイトにも同じ FreeStyleWiki をインストールして色々試してみているところです。さすがに運用を開始してる PPL で無茶なことはできないですからね．．．まぁ、ひとまず勉強用の wiki なんで非公開です。中身からっぽですし。

　しかし、あれですね。wiki と weblog があれば、HTML をまったく知らなくても簡単な Web サイトを運営できるようになりますねぇ．．．しかし、この手の CGI の塊を築き上げる人たちってすごいなぁ．．．と思います。スクリプト言語ってのは、ちょっと膨らんだだけで陰郎の手には負えなくなりますから。（汗

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年05月29日

もっともっと edge に！

　最近、思うところがありまして、はい。

　開発者というのは結構短命です （ 生物としての寿命ではなく、開発者として頑張れる年齢ね ）。現在３１歳の陰郎が、あと何年くらい前線にいられるか、正直わかりません。結構無茶する方なので、思いのほか短いかもしれません。

　じゃ、無理せず長く続けろよ、といわれるかもしれませんが、たぶん陰郎には無理です。そういうスタイルなんです。そして、決して長くない期間しか頑張れないなら、せめてその間だけでもギリギリのところで頑張っていたいんですね。もうエッジのギリギリのとこ、あと半歩で向こう側に行っちゃうような、そんな感じで頑張りたいのです。抽象的ですね。上手く表現できなくてごめんなさい。

　そういうわけなんで、陰郎は少し変わろうと思っています。具体的にどうなるのかは自分でもわかりませんが、もっともっと 「 開発者としての活動 」 に集中したいんです。それが、ひょっとしたら結果として 「 付き合いの悪いヤツ 」 とか 「 コメントに反応しないやつ 」 みたいなカタチで表に現れてしまうかもしれません。あるいはこの日記に 「 開発者にしかワカラナイようなコトばかり書く 」 とか、「 更新そのものが滞る 」 とか、そんなこともあるかもしれません。正直に言って、この日記に書くことを考えるのも開発の妨げになる日があるんです。陰郎はいわゆるブロガーではありません。陰郎が本来書くべきなのはソフトウェアであって、日記や活字ではないんです。沢山の Palm ユーザーが Web 上で （ ブログであろうが直書き HTML であろうが ） 情報交換をすることで Palm 界に貢献するように、開発者はソフトウェアを書くことで貢献するんです。陰郎は今の自分の開発者としての活動に満足していません。どうやったら満足できるのかすらわかりませんし、ひょっとしたら 「 気の持ちよう 」 なのかもしれません。どんなに頑張ったってこれ以上は無理なのかもしれません。でも、自分が納得できるまでやってみたいんです。

　陰郎は特に Palmware に専門特化した開発者として自分を認識しているわけではありませんが、ひとまずのところ Palmware 開発にもっともウェイトを置いています。Palmware の開発を始めたのが 2005 年４月ですから、現在の Palmware 開発者の中では最後発組に分類されるでしょう。最低でも、次の世代の Palmware 開発者が揃ってくるまでは頑張り続けたいと思っています （ もちろん可能ならばその先もずっと ）。

　以上。

投稿者 kagelow : 01:15 | コメント (2) | トラックバック

2006年05月21日

去年の今頃は

　えぇ、FEPSwitch やら m-plug 定例会やらを乗り越え、ひとまず平穏な週末を過ごしております。あ、でも皆様より頂いてます FEPSwitch の動作確認報告をまとめなきゃね。ひと休みしたらやりますので．．．

　で、タイミングよくやってきました。毎月20日は 「 去年の今頃は 」 でお茶を濁す日であります．．．と、ところがですね。去年の５月の日記を見ると、5/1 以外は全部空っぽ。なにも書いておりません。仕方がないので某 SNS に書いていた日記から引っ張ってきましょ。つまり、自分の本拠地をほったらかして SNS の日記を書いていたわけですね。なぜなら、まだ blog 移行前の HTML 手書き状態で、それが作業時間を圧迫してたから。この５月の反省が、６月の MovableType 移行へとつながっていくわけです。ま、それはそれとして。

　5/8 に２作目の Palmware、PalmDLA をリリースしていますね。そして、5/21 には３作目である mpuz をリリースしています。この間たったの２週間．．．狂ってます。あの頃は Palmware 製造マシーンと化してました。今にして思えば相当簡素な作りのゲームですし、Emacs エディタで遊べる mult puzzle の事実上の移植ですから、手を動かすだけといえばだけ。しかし、よく２週間で作ったものです。そして久しぶりにやると相当ヘコむゲームでもあります。

　そしてその後は４作目、すなわち、あの PipeWorks の開発が始まるわけです。もう５月の終わり頃から泥沼にはまっています。初めてハイレゾに挑戦したのが効いているのね。

　では、最後に、2005/05/01 に書いた日記を再掲載。先月同様、「僕」という表記は現在の書き方に直しています。最後のコードは、文字列リテラルに配列の添え字を直接つけられるという点で遊んでいるわけです。しかし懐かしい。そう言えばこの本、読了してないや。

---

【雑感】 x % 87 % 48 ？

「ハッカーのたのしみ」という本 （ ISBN:4-434-04668-3 ） を読み始めた。セキュリティ破りの本ではない。プログラミングの真髄を垣間見ることのできる本だ。

冒頭の「推薦の辞」にこんなのがあった。

c2n(x)
　{ return x%87%48; }

　ナニをやっているかといえば、0～9、a～f の文字を対応する 16 進数に変換するらしい。一瞬信じられないが、よくよく見るとこれで正しく動作することがわかる。簡潔だし、これ以上速くする方法はないかもしれない。すごいの一言だ。

しかし、一方で以下のような疑問が湧く。

・特定の文字コード体系に依存している。
・ascii コード前提でも、アルファベット大文字のA～Fでは動作しない。
・入力に対するチェックがまったくない。

　以上の意味で、これは「古典的な」ハッカー臭のするコードだといえる。上記の仮定を呼び出し元にすべて押し付けているのであれば、それは「身勝手な」コードに過ぎない（場合によるけど）。もちろん、速度・テクニック面では 100 点満点だ。陰郎にはとても思いつかない。しかし、それ以外の面ではいかがなものかと思う。

　もしこのようなスタイルを「ハッカー的」というのなら、陰郎はハッカーには（なれたとしても）なりたくない。陰郎は、優秀なプログラマというのはプログラムを大切にする人間だと思っている。そういう人間は、可用性、可読性、堅牢性、変更容易性、例外処理といった様々な品質のバランスをとりつつ、可能な限りのパフォーマンスを追及するものだ。これらを無視して性能だけを追うのは命知らずの走り屋といわざるを得ない。

　．．．などと言いつつ、陰郎もちょっと危なっかしいコードを書いてみた。さっきのとは逆に、0～15 までの入力に対して対応する16進数の文字を返すコードだ（範囲チェックは割愛）。これでも合法的なＣ言語なんだよ！

char n2c( int hex ) {
　　return "0123456789ABCDEF"[hex];
}

---

　

投稿者 kagelow : 00:00 | コメント (0)

2006年05月08日

反省会

　えぇと、１人ですが反省会。なんのって、この連休の。

　えとですね。最後の２日間は思いっきり緊張感が切れてしまいました。で、だらだらと過ごしてしまいました。もう少し気分転換なるものを用意しておかなければならないようです。最初の３日間はなんとか頑張ったんですけどね．．．いじょ。

　明日から頑張ろう．．．どうやら陰郎は時間がありすぎるとダメなようです。うん、忙しい日常の中でのほうが燃えるんだね。うん．．．

投稿者 kagelow : 01:30 | コメント (0) | トラックバック

2006年05月03日

７年前のコード

　以前にもこんな話題があったような気がしますが、気付かない振りをして書いてしまいましょう。またもや古い作品を引っ張り出してイジってみましたよ。今日はファイル比較ツールであります。

　職場でとなりの席に座っているＫ君が、ファイルを比較するために使用しているフリーソフトのバグで悩んでおりました。一致行の検出にちょっとした不具合があるというものなんですが、そのバグが発生しない場合でも、いわゆる「自然な結果」が得られないということで不満があるとのこと。うんうん。ソフトウェアで機械的に差分を調べると、「 そこはそーじゃねぇだろ？ 」 という結果になることがありますよね。２つのファイルをこう、左右に並べて相違点がビジュアルに見える必要があるので、いわゆる diff コマンドではダメなんですね。

　陰郎は Microsoft 社の Visual Sourcesafe を持ってますから、個人的にはそのファイル比較機能を使います。アレもまぁバグのあるソフトウェアですが、わかった上で使うのであればまぁ便利ですし、ファイル比較機能もそこそこ賢く動いてくれます。陰郎も手があいているときはＫ君の作業を手伝ってあげるのですが、いつでもというワケにはまいりません。個人で持っているライセンスなので、Visual Sourcesafe を自分の PC 以外に移すこともできません．．．と、そういえば、６～７年前に自分で作ったファイル比較ツールがありますよ。あれをちょいとイジってやれば彼の作業の助けになるのでは？

　とま、そんなワケで古ーいソースファイルを引っ張り出してきたわけでありんす。しかし．．．うん、かび臭い。当時は特定のフォーマットに特化した比較機能を実装するために自作したので、このままじゃダメ。普通一般のテキストファイルを比較できるようにイジって．．．うん、動いた。でも遅い。よく見ると稚拙なテクニックを使ってるなぁ。過去の自分の作品を見るのはたまにやりますが、７年前ってのはこれまでで一番長いかも。このままじゃ陰郎品質をクリアできませんことよ。よし、やったる。

　そんなこんなで、さらにイジり始めたわけです。ファイル比較を自分で書いてみると分かりますが、「 もっとも自然な一致箇所 」 をどう決めるかというのはそうそう簡単な話ではございません。陰郎の場合は多少遅くても結果重視という方針を採っているのですが、今回は相手が悪かった。巨大なファイルだったんですね。そうなると 「 多少遅くても 」 という部分が 「 多少 」 ではなくなったりします。ええくそ、負けんぞ。パフォーマンスチューニングも兼ねて書き直しじゃ．．．！

　まぁそんなところで、いまだにやってます。オチはありませんが、それではナニなのでいつだったかと同じコトを書いておきましょう。自分の古い作品は時々手を入れてあげましょう。ちょっとリファクタリングをしたり、自分のコーディングスタイルの変化を反映するだけでもいいんです。過去の自分のコードが下手に見えるのであればおめでとう。それは自分が成長していることの証です。とはいえ、大事なのは Happy programming。明日も開発日和でありますように♪

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年04月30日

まさに黄金週間

　まったくノーマークだったのですが、今年は休みが長いんですね。バカンスやら行楽なんてどこ吹く風の陰郎です。そんな陰郎にとっても、やっぱりゴールデンウィークは黄金週間なのですよ。だいたい情報産業にお勤めの人間にとっては 「 仕事の黄金週間 」 だったりするのが実情で、大型連休でシステムが停止するタイミングでデカい仕事 （ システム移行とか ） をやるわけですね。昔いた職場で聞いた話ですが、１０年もの間年越しを職場のマシン室で迎え続けた人もいたのだとか。こうなるともう手を合わせるしかないですね。はい合掌。かくいう陰郎も去年の５月連休は職場で過ごしました。酸っぱい思い出です、はい。

　しかしですね、今年は違います。昼間の仕事は暦どおり休みます。休みの日に何をするかっていうと、休んだりはしないのですよ。とはいっても予定表はからっぽなのですよ。やることなんて決まってます。夜のお仕事ですよ。いかがわしい話はしてません。開発をやるのですよ。頑張るのですよ。まさに黄金週間。連休明けはきっとヘロヘロになって職場復帰するに違いない。

　現在作成中の Palmware は時間がかかりそう＆複雑なので、とにかくまとまった時間が欲しいんですね。職場の昼休みや帰宅後の短い時間の作業をいくら積み上げたってなかなか進捗はあがりませんし。今は既存 Palmware のバージョンアップを息抜き代わりにやってますが、それは近日中に後悔できるでしょう。いやもとい、公開できるでしょう。算術愛好癖患者たちよ、楽しみに待っていろ。

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年04月28日

スパムフィルタじゃなくて

　えぇと、今夜は Palmware の作成はお休み。なにをやっていたのかというと、自分が借りているWeb サーバのスパムフィルタリストの作成を支援するためのツールを作っておりました。スパムフィルタそのものを作っておったのではありません。やっていることは簡単で、サーバのメールログを読み込んで送信元のメールアドレスを統計を取る。それだけ。ドメイン名とメールアドレスの２つで出現順にまとめます。ま、そこから回数の多いドメインやメールアドレスを選択してスパムフィルタリストに登録するワケですね。あぁ、なんて原始的なんでしょう。

　要するに自分で作るのが好きなわけですよ。高機能なものを買うのもまぁ好きですが、自分で作るのはもっと好き。稚拙で貧弱なものだったとしても、いいところも悪いところも分かっているし、必要なものが足りないことはあっても、不必要なものがくっついていることはない。うん、Do it yourself。

投稿者 kagelow : 01:30 | コメント (4) | トラックバック

2006年04月22日

オブジェクトもリサイクル

　データ抽象やオブジェクト指向を中心としたデザインでソフトウェアを書いていると、どうしてもヒープ領域を頻繁に使用するようになります。クラスの在り方によっては、ソフトウェアのライフサイクル中にそれこそ膨大な回数 new と delete が繰り返されることにもなります。

　ヒープ領域の頻繁な使用がどれくらい問題になるかは環境にも状況にもよります。しかし、一度確保した領域をまた（ 別のコンテキストででも ）使うことができるのであれば、やるに越したことは無いでしょう。これから書くテクニックは別に目新しいものでも難しいものでもありません。昔何かの本で読んだものだと記憶していますが、まぁ最近使うことが多いので書き留めておくにはいい機会です。間違っても陰郎が自分で考え出したなんて主張するものではありませんのでお間違えのないように。

　さて、説明のために分かりやすいクラス Foo があるとしましょう。別にどうということもありませんね。しかし、これが膨大な回数 new と delete を繰り返すことになるとします。

class Foo {
private:
　　int m_data;

public:
　　Foo( );
　　Foo( int data );
　　~Foo( );

public:
　　// public methods...

};

　このクラス Foo のオブジェクトをリサイクルして使うとなると、誰かがそれを管理せねばなりません。お手軽な方法は、Foo クラス自身 （ Foo オブジェクトではない ） にやらせることです。というわけで、クラススコープの CreateInstance( ) と ReturnInstance( ) を追加し、コンストラクタとデストラクタは private とします。

class Foo {
private:
　　int m_data;

private:
　　Foo( );
　　Foo( int data );
　　Foo( const Foo& foo );
　　~Foo( );

public:
　　// public methods...

public:
　　static Foo* CreateInstance( int data );
　　static void ReturnInstance( Foo* wreck );

};

　ひとまず、これで Foo オブジェクトを得たければ Foo::CreateInstance( ) を呼び出す以外に方法はなくなりました。どさくさにまぎれてコピーコンストラクタが追加されてます。これまた private ですからスタック上にオブジェクトを作ることも禁止されます。sizeof(Foo) に等しい領域を用意して reinterpret_cast<Foo*> をかけたり、さらには Foo のヘッダファイルを #include する前に #define private public とするなどの 「 荒業 」 もありますが、それは意図的かつ悪質なタイプシステムの侵犯というものです。

　で。使い終わった Foo オブジェクトは Foo::ReturnInstance( ) を呼ぶことになりますが、Foo はクラススコープでこれをどう管理するのでしょう。そう、まだ必要なステップがあるわけですね。配列を作って格納したりすると拡張が面倒ですから、Foo オブジェクト自体で数珠つなぎをつくりましょう。不要なオブジェクトサイズの膨張を防ぐためにあえて union を使用します。で、数珠つなぎの先頭を掴んでおくためにクラススコープメンバ s_pCemetery（ 共同墓地 ）を追加します。結果、こんな感じになりました。

class Foo {
private:
　　union {
　　　　int m_data;
　　　　Foo* pNext;
　　};

private:
　　Foo( );
　　Foo( int data );
　　Foo( const Foo& foo );
　　~Foo( );

public:
　　// public methods...

private:
　　static Foo* s_pCemetery;

public:
　　static Foo* CreateInstance( int data );
　　static void ReturnInstance( Foo* wreck );

};

　で、まぁキモはクラススコープメンバの使い方なわけですから、それだけ以下に示します。特に難しいことはありません。Foo::CreateInstance( ) では、s_pCemetery にリサイクル可能なオブジェクトがあればそれを使い、空っぽなら新しいオブジェクトを作ります。Foo::ReturnInstance( ) では返却された Foo オブジェクトを s_pCemetery による数珠つなぎに追加し、以後のリサイクルに備えるわけです。

Foo* Foo::s_pCemetery = NULL;

Foo* Foo::CreateInstance( int data ) {
　　Foo* p = s_pCemetery;
　　if( !p )
　　　　p = new Foo( data );
　　else {
　　　　s_pCemetery = s_pCemetery->pNext;
　　　　p->m_data = data;
　　}
　　return p;
}

void Foo::ReturnInstance( Foo* wreck ){
　　wreck->pNext = s_pCemetery;
　　s_pCemetery = wreck;
}

　まぁ大体こんなところなのですが、肝心なことを忘れていますね。new が使用されているにもかかわらず、このコードには delete がまったく見当たらないのです。結局のところ、プログラムの終了時には全ての Foo オブジェクトが墓地に収まっている（ 嫌な表現だな ）はずなのですが、それを開放するのは誰の責任か．．．ということです。まぁ成り行きからいって Foo クラスにやらせたいのですが、Foo が「 自分で 」プログラムの終了時を検出することは現状ではできません。では、どうすればよいか。

　ここでは面倒なの（ と、もうひとつの別の理由があるの ）で具体的な方法は書きませんが、プログラムの終了時に破壊されることが保証されている大域変数を利用して Foo クラスの共同墓地をキレイにしてあげればよいわけですね。では今夜はこのへんで。

投稿者 kagelow : 00:25

2006年04月21日

去年の今頃は

　ネタがあっても書いている時間がないとネタの持ち腐れになります。そんなときにやってきました毎月２０日。そう、月イチの後ろ向きな企画、「 去年の今頃は 」 です。2005 年 4 月 はなにをやっていたのかと言えば、記念すべき陰郎の初 Palmware である PalmLife のリリースです。

　まずは正規表現エンジンの開発ですが、４月の前半あたりから放置プレイが始まっておりますね。で、PalmLife イジりに精を出しておりますが、4/1 の東ラの花見の時点でなんとか動作するバージョンを持参しております。で、それが一段落したころに２作目の PalmDLA の前身である Windows 版 WinDLA を作成し始めると。その後、PalmDLA へと移るわけですが．．．おそらく、陰郎がもっとも力を入れなかった Palmware ．．．でもそこそこ面白いので一度くらいは遊んでみてください。ほとんど PalmLife の使いまわしですが。

　んで、他にはあまり書くことがないんですが、4/30 に書いた文章を見て懐かしくなりました。再掲載しておきましょ。ただし、当時は自分のことを 「 僕 」 と書いている。これは恥ずかしいので直しておきます。

---

　「どのエディタが最高か」という話には興味がない。 「どこのラーメンが一番美味いか」という命題と同じで、主観的でナンセンスだと思うからだ。多機能なもの、シンプルなもの、速いもの、いろいろある。各々が一番と思うものを使ったり楽しんだりすれば良い。エディタは開発者の手に馴染む道具だ。大工さんの金槌や鉋（かんな）のようなものである。

　陰郎の使っているエディタにまつわる、ちょっとしたエピソードがあるので紹介しておこう。ある日、かなりレアケースなバグを発見した。開発者向けのエディタの常としてプログラムソースのキーワードを色付きで明示する機能があるのだが、そのキーワード明示機能が働いているときだけ、特定の正規表現検索が正常に動作しなくなるのだ。最初はキーワード明示機能との関連に気づかず、単なる正規表現機能のバグとしてレポートを送ったが、「再現しません」との返事。実際の対象ファイルを送ってくれと言われ、用意しているときにキーワード明示機能との関連に気が付いた。

　特筆すべきなのは原因がわかってからの対応の早さだ。翌日にはメールにてバグフィックスの連絡があり、週明けにWebにアップするという。急ぐならメールで送るか、CD なり FD なりのメディアで郵送するとまで言ってくれたのだ。こっちが恐縮するほど迅速で丁寧な対応だった。もともとハードな使用にも耐えるだけの頑強なエディタだったが、それ以来ますます気に入っている。

　賞賛の意を込めてクレジットしておこう。そのエディタというのは、MEGASOFT 社の MIFES for Windows である。このエディタはプロの道具と呼ぶにふさわしい。３万円は決して高くない。素晴らしい道具を持つに相応しい開発者になりたいものだ。

---

　今となっては、Emacs （ というか Meadow ） が陰郎の中ではかなり大きな位置を占め始めているのですが、それでも MIFES for Windows は自分の中では最高のエディタの１つであります。おそらく今後も世話になるでしょう。皆さん、良いエディタを使いましょう。

投稿者 kagelow : 00:00 | コメント (2) | トラックバック

2006年04月12日

ネットワークのお勉強

　えぇ、ネットワークのお勉強を始めました．．．仕事人としての陰郎はネットワーク系は非常に苦手でして、今でも伝書鳩の足に DDS4 の DAT をくくりつけて伝送した場合の効率とパケットロストのトレードオフがよく理解できていません。また、56kbps の回線による伝送と CD-ROM 媒体を手に持ったマラソン選手で比較した場合、距離とデータ量の兼ね合いからどちらが効率的かを判断することもできないのです。きっと世の中のネットワークスペシャリストな方々は即答できるに違いない．．．嗚呼！

　そんな陰郎が IP ルーティングの解説書を読み始めたわけですが、困ったことに伝書鳩もマラソン選手も登場しません。おかしいな、本選びを間違えたか．．．？　ま、それはそれとして。ルーティングのお勉強を始めたといっても、ネットワークのお仕事を自分のキャリアの中心に据えようと思っているわけではありませんよ。陰郎は今後もアプリケーションデザインの専門家として肩身の狭い思いをしながらこの業界で生きていくのです．．．書いてて悲しいですが、本当、重宝されないのですよ論理デザインの専門家は。まぁソフトウェアなんて動きゃいいと思っている人たちを相手に仕事するわけですからね。

　脱線しましたが、そんなわけでルーティングのお勉強の真の目的は．．．？　それはですね。まだ言えません．．．なんて、バラしてるようなもんですが。まだどのようなカタチになるかわからないんです。さて頑張ろう。

投稿者 kagelow : 00:45 | コメント (0) | トラックバック

2006年04月07日

聞くは一時の恥

　皆さん、お久しぶりです。休暇明けで社会復帰に手間取っている陰郎です。皆さんいかがお過ごしでしょうか（余計）。休みの間は Palmware イジりに専念するために日記の方は連載と称する駄文を連ねて濁らないお茶を無理に濁しつつその駄文に足を引っ張られて Palmware 開発がイマイチ進まなかったような次第で休みが明けてみれば書くことも無くどうしようかと途方に暮れておるような今現在です （ 棒読みはお約束 ）。

　そこで。引っ張ってきた話題と言うわけでもありませんが、Wiki です。Wiki に興味を持ちました。Palm 関連諸氏のサイトでも Wiki を活用しておられるところがたくさんあります。「 ぱむあん。」 登録サイトをちょっと見渡すだけでも nicc さんの Palmware Stockyard、たつやさんの 英語版 Palm ： 日本語化まとめ Wiki、michieru さんの ぱむあんりみてっど！、pamupamu さんの WristPDA@Wiki、陣来霧さんの G-Lexicon ．．．とまぁ、いっぱいあるわけですね。

　ところが。つい最近までですね、陰郎にとっては Wiki というのは謎のハイテクノロジイだったのですよ。といっても weblog のときもそうでしたが。上記諸氏の Wiki を訪れてみても、編集方法はおろか閲覧方法もイマイチわからない．．．まるで初めてパソコンの前に座ったおじさまのような感じでまごつくわけですね。あれは新鮮だった （ 意味不明 ）。

　しかしま。いつまでも新鮮でいられるわけもなく、自分的にもちょいと勉強せんといかんなと思うに至り、休暇最終日の夜になってから乱心いたしまして Pukiwiki を自分が借りている Web サーバ上にそれっ！　と展開してみたのでございます。さぁ学ぶぞと鼻息も荒く Web ブラウザを起動して見たのですが。

　PHP のバージョンが古くて動きませんでした。

　共用サーバのレンタルなので、そこんとこは自分では何ともできないんですね。あまり古いバージョンを試すのも気が進まなかったのですが、そんなことを某所で呟いてみましたら、他にもいくつもの選択肢があることを教えていただきました。ありがとうございます。相変わらず陰郎は世間知らずです。

　で、陰郎の人生においてもっとも不可解な距離を持つ男、某 Loki が教えてくれたのが TiddlyWiki でありました。これが変わりダネでありまして、JavaScript で実装されており、しかも HTML 形式の１ファイルのみの実装という、ある意味男気にあふれた逸品なのであります。サーバ上で静的マルチファイル生成ができる Wiki をやりたかった陰郎のニーズにはちょっと合わないのですが、これはこれで使える！　とこれまた鼻息を荒くしまして。で、今日職場で社会復帰一日目にしてイジり倒していたのですね （ 手間取ったって最初に書いたでしょ？ ）。

　１日使ってみた感想ですが、いやこれ使えます。面白い。長いスパンで見て、エントリの量が増えてきたときに JavaScript で動的に見せているという実装が性能面にどのくらい響くかな．．．というのがちょいと懸念事項ですが、Wiki 特有の文書整形ルールも慣れればなんとかなるものです。ひとまずこれまで使ってきたお手製の業務日誌 HTML 直書きツールから移行する方向で検討。

　ありがとう、某 Loki 。

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年03月24日

例外を投げつけないで

　いろいろと書きたいことはあったとしても、ここに書くことじゃなかったりします。一応開発日記なんで、与太話やら社会的なネタばかりだと 「 看板に偽りあり 」 ということになってしまうわけで、今日は開発のちょっとした話。想定読者は CodeWarrior + POL で Palmware 開発をしている C++ プログラマ。つまりほとんどいない。

　えぇと、かなり初期に作成した Palmware をイジっていまして、その作品は Palm のデータベースを使用していなかったんですね。で、データベースに設定などを保存するように改修すべく、最近の作品からデータベース関連のソースコードを引っ張ってきたのです。で、デバッグ。データベースを使用する Palmware でも、初回起動では当然データベースは 「 まだ 」 ありません。で、普通にデータベースをオープンしようとすると、当然エラーになります。エラーコードを確認して、「 あ、データベースが無いや 」 となればデータベースを作成する、と。まぁそんな実装にしているわけです。これで不都合なくやってきたのです。そのまんまいけるはず．．．おっと、デバッグセッションが固まった．．．なんで？

　冒頭でちょいと書きましたが、陰郎は CodeWarrior9J で POL （ Palm Object Library ） を使用して開発しています。POL は Palm OS API をラップする C++ のクラスライブラリなのですが、デバッグセッションをやり直して POL のコードまで降りて見ると、どうやら C++ 例外が投入された様子。しかし、既存の作品 （ ぶっちゃけ MathPhilia ） ではデータベースが存在しなくても例外は投入されなかったぞ．．．？　ははぁん、さてはプロジェクトの設定で C++ 例外処理が有効になっているな？　そこを直せば．．．あれ、無効になっている。しかし、デバッグセッションでは確かに例外投入コードを通過する．．．と。なんだこれは。呪いかなにかかしら。

　余談ですが、陰郎が C++ 例外を無効にするのは Palmware 開発でだけです。それ以外の場合は例外を普通に使用します。Palmware で使用しないのは、非力なデバイスで動作する場合のパフォーマンスを考えてのことだった気がするのですが、まぁ気にしすぎかもしれませんね。

　で。POL ライブラリのレベルで例外が投入されるということはライブラリの設定か？　と疑って見たところ、どうやら C++ 例外を使用するバージョンの POL ライブラリをリンクしているらしいということがわかりました。POL プロジェクトを作成するときに 「 C++ 例外処理を使用する 」 設定にした時点で、リンクライブラリは例外投入バージョンに設定されたと。でもってその後 C++ 例外を使用しないように設定したものの、リンクライブラリの設定は変更されなかった．．．と。うん、ライブラリが例外を投入しても、プロジェクトのコンパイル自体は例外処理を行わないため、デバッグセッションが固まってしまったと。うん、納得がいく。

　結局、リンクライブラリを総入れ替えしたらこの奇妙な現象は収まってくれました。これまでどおり、エラーコードを返してくれる．．．と。うん、ばっちり。

投稿者 kagelow : 20:40 | コメント (0) | トラックバック

2006年03月21日

逆境ハイ

　２日ほど寝かせた 「 忙しいネタ 」 ですが、ここらでまとめに入るとしましょう （ なんだそりゃ ）。陰郎も遅まきながら腹をくくることができました。なんというか、楽しくなってきたのです。非情な忙しさの中、我慢するのではなく、ほとんど腹いせのレベルで深夜まで開発作業にいそしむ。これです。これが楽しいわけです。やってみればおわかりと思いますが （ 勧めるなよ ）、人間そうそう死ぬもんじゃありません。そもそも個人レベルの開発を無理にでも続けなければ自尊心が保てないという時点で、昼間の仕事の内容の悪さは推して知るべしといった程度のもの。なんでこの業界はこうなんでしょうねといった愚痴はたっぷり後回しにするとして （ するのかよ ）、とにかく今は頑張れます。後先考えずに開発できます。中途半端に忙しかった時期の陰郎は贅沢でした。ひさしぶりにアドレナリンが充満するような感覚が戻ってきたのです．．．幸せ。　．．．えぇ壊れていますとも。

　．．．で、急に冷静になって堅いことを書きますが、基本的にはそんな逆境でソフトウェア開発をするべきではありません。ほぼ間違いなく 「 後からみてがっかりする 」 デザインが出来上がります。ユーザーインタフェイスの部分ではなく、内部の設計レベルの話ですね。UI というものは、最低限の設計レベルをクリアしていれば大抵はあとから変更がききます。しかし、内部的な ── まぁ大げさに言えば ── アーキテクチャをミスると比較にならないほど高くつくことになります。そういう意味では、我慢して比較的機械的な作業をしたほうがいいんですよねこういうときは。右側の脳味噌が重要になるデザイン上の決定はゆったりした時間にやらないと。でもそんなこといってるといつまでもできないと。ごもっとも。でも、３月の最後の１週間はヒマになるはず。そのときまでは腹いせの深夜開発を続けるのです。はい。

投稿者 kagelow : 23:45 | コメント (0) | トラックバック

2006年03月20日

去年の今頃は

　さて、月イチで書いておりますのは一年前に何をやっていたかを振り返る後ろ向きな企画、「 去年の今頃は 」 です。2005 年 3 月 はどんなことをやっていたか。PUM in Tokyo を大きな転機として、生活が Palmware 開発の方へ大きくシフトして行った期間のようです。今回はごたまぜに書いてみましょう。どん。

　まずは開発から。相変わらず正規表現エンジンをイジっております。しかし、下旬あたりから Palmware 開発へとシフトし、最初の作品である PalmLife をやっておりました。その後正規表現エンジンは長期間の放置プレイに晒されることになります。合唱。いや合掌。

　２月末に m515 の液晶漏れを修理に出しておりましたが、 3/5 に帰ってきております。Palm OS 5 に慣れ切ってしまった現在では、もう主役の座に返り咲くことはないでしょうが、Vx と共にこれからも大事にしていきます。

　で、2005年3月 といえば PUM in Tokyo がありました。ここで Palmware 開発に挑戦することを決意したんでしたね。数日後 MobilePLAZA へ行って Codewarrior の取り寄せをお願いしていたように記憶してます。そして CodeWarrior を手にしたのが 3/27。帰宅してインストールし、ユーザー登録をしようと思って Metrowerks のサイトに接続したら、CodeWarrior 製品群から手を引くというプレスリリースに出会って落ち込んだのでした。あのときはちょっとショックだった。

　話は少し戻って 3/21。この日、CodeWarrior 入荷時に連絡先として MobilePLAZA に伝えておいた WILLCOM の PHS （ 当時はまだ DDI Pocket か ） を紛失。京ぽんに機種変更したのですが、腹いせに Zire72 を購入してしまいました。冷静さを欠いていたと未だに主張していますが、明らかに言い訳でしょう。

　で、CodeWarrior 入荷の知らせを受け、3/27 に MobilePLAZA へ。その２日前に自宅の開発 PC 用ディスプレイがお亡くなりになっています。というわけで CodeWarrior 購入前に有楽町で液晶ディスプレイを購入。その後何を考えたか有楽町から MobilePLAZA まで歩こうとして大手町あたりですぐに断念。CodeWarrior を入手してからは興奮して地下鉄で反対方向の電車に乗ってしまっています。子供かっつうの。

　そんなこんなで３月の最後の４日間は CodeWarrior と取っ組み合う生活をしておりました。たしか、2005/04/01 の東京ラ・パームの花見（だっけ？）には、なんとか動作するまでにこぎつけた PalmLife を持参したはずなので、かなり濃い数日間を過ごしていたはずです。やれやれ。

投稿者 kagelow : 23:59 | コメント (0)

2006年03月17日

Codewarrior と夜遊び

　『 忙しいネタ 』 を水で薄めて使い続けるにも限度があります。ちなみに昨夜は午前３時まで Codewarrior と夜遊びを決め込んでみました。結果、今日の昼間はどうだったか。別段どうということもありません。いつもどおり体調悪いですが、さりとて普段より悪いということもなし。これならイケるんではなかろうかという明らかな判断ミスをするのも疲れているからでございましょう。ひょっとしたら憑かれているからかもしれませんが。

　で、今週末は泊り込みで試験のお仕事。先週も土日仕事してました。以前休んだのがいつだか思い出せません。とはいえそんなに昔のことでもありません。そもそも昨夜の夕食が思い出せませんから。いや、毎日御飯と味噌汁だけですから思い出す必要すらありませんね。なんだかみじめったらしくなってきました。

　でも、明日はシフト勤務扱いなので午後出勤です。というわけで今夜も CodeWarrior と夜遊びします。ちなみに、昼間の職場で夜遊びという言葉を使ったら、「 夜遊びしそうに見えないのに 」 と言われました。 「 深夜の開発作業 」 を夜遊びといいませんか？　言わない？　おかしいな。

投稿者 kagelow : 00:15 | コメント (2) | トラックバック

2006年03月16日

忙中 「 考 」 あり

　忙しい、忙しいと言っておりますが、実際に忙しいです。しかし午前様で帰宅しても洗濯機を回し、洗い物をし、米を炊くわけです。まぁそのあたりが限界で、最近の朝食＆夕食は御飯と味噌汁だけだったりします。おかずにまで手がまわりませんし、まして開発に割り当てるだけの時間の余裕があろうはずもありません。

　しかし、そんな閉塞感で満たされた生活の中、精神はどんどんすさんで行きます。これではいかん．．．なんとかせねばならん．．．しかし、仕事をこなし、生命維持と最低限の家事を続けるので精一杯ではなんともなりません。

　ここで陰郎は考えました。気持ちがすさんで行くのは忙しいからではなく、その結果としてやりたい開発ができないからです。なぜなら、時間があったとしても、開発をしていない陰郎はやっぱりダメになっていくからです。ということは、忙しいときでも無理矢理やりたい開発を頑張れば、せめて人間がすさんで行くのは避けられるのではないでしょうか。そのためだったら、ちょっと生命維持がおろそかになったって構うことはないでしょう （ それはどうかな ）。

　まぁ、そんなことを考えたわけです。タイトルには忙中 「 考 」 ありなどと書きましたが、ここまで書いて別の言葉が浮かんできました。「 下手の考え休むに似たり 」 。 あ、ダメだこりゃ。

＃ でも今夜くらい実践してみよう．．．

投稿者 kagelow : 01:00 | コメント (0) | トラックバック

2006年03月10日

テンプレートと文字列リテラル

　忙しくて気の利いたことを書けない。申し訳ないが開発寄りの話。

　c++ では、ワイド文字は wchar_t で扱うことになっている。char と wchar_t は、（ 通常は ） まったく別の型だ。一般に wchar_t は 16 ビット値だし、それぞれの文字列を扱うためのライブラリ関数も別だ。ここでは、１つのプログラムソースで char と wchar_t の２つをテンプレートレベルでサポートしたい場合のことを書く。

　ここで、文字型でパラメタライズされたクラステンプレート Foo があるとする。そのメソッド Bar( ) の中で文字列リテラルを使用したい場合、どうするか。たとえば以下のような感じだと、Foo<char> なら問題ないが、Foo<wchar_t> ではコンパイラが文句を言う。なぜなら、ワイド文字の文字列リテラルでは、手前に L を付けなければならないからだ。

　

template <typename CT> class Foo {
public:
　　typedef CT CharType;
public:
　　void Bar( ) {
　　　　const CharType* p　= "Foo::Bar( ) has invoked.";
　　};
};

　

　一般的に、文字環境の切り替えで文字列リテラルを上手に扱うために使用されるのは TEXT("string") といったマクロだ。これは、ワイド文字環境なら L"string" に、そうでなければ "string" に展開される．．．のだが、実はこれが嫌いなのだ。マクロはコンパイラが関知しないため、ハマると実に不愉快な時間を過ごすことになる。それに、そもそもテンプレートのレベルで文字環境を認識したいのにマクロ定義と同期をとらなければならない。そんなのは変だ。

　陰郎がとっている方法は、リテラルを管理するクラステンプレートを作成する方法だ。本体は空にしておき、char および wchar_t で特殊化する．．．以下のように。インデックスを指定して複数の文字列リテラルを取得できればよいが、 operator( ) を使用しているのは陰郎の趣味だ。

　

template <typename CT> class Literals { };

template <> class Literals<char> {
public:
　　inline const char* operator( )( int idx ) {
　　　　// ．．．
　　};
};

template <> class Literals<wchar_t> {
public:
　　inline const wchar_t* operator( )( int idx ) {
　　　　// ．．．
　　};
};

　

　こうしておけば、以下のようにすることで CharType の実際の型が char でも wchar_t でも動作するようになる。インライン関数にしてあるし、賢いコンパイラならきっちり最適化してインデックス指定のコストを事実上なしにしてくれるだろう。

　

　typedef Literals<CharType> LiteralsT;
　LiteralsT literals;

　const CharType* p = literals( 0 );

　

　正直、ここまでやるのはやりすぎかもしれない。しかし、可能な限りプリプロセッサディレクティブを追放することを考えるとこんなふうになってしまった。当然、文字列処理をするライブラリ関数をマクロを使用して使い分けたりもしない。文字型をテンプレートとするクラスユーティリティを作成して切り分けるのだ。ここまでくると立派なものである。ただし、テンプレートを使っているせいでソースコードのほとんどがヘッダファイルに入ることになるが．．．（ 汗

投稿者 kagelow : 00:30 | コメント (0) | トラックバック

2006年03月01日

VBGeneric version 1.03.356.001

　さて、陰郎個人としてはもっとも思い入れがあるにも関わらず１番不人気かもしれない作品、VBGeneric の４ヶ月ぶりのアップデートである。今回はファンクタの仕様変更ということで、旧バージョンとのバイナリ互換性はない。つまり、旧バージョンを使用してコンパイルしたものについては、リコンパイルが必要ということだ。

　具体的にどのような変更が加わったかについては、以前書いたとおりだ。ファンクタインタフェイスである UnaryFunction, BinaryFunction, GenerateFunction の Execute( ) メソッドがクラスの既定メソッドに指定された。これによって、Execute( ) メソッドを明示的に呼び出さなくても、あたかも C++ のファンクタのごとく operator( ) が実装されているかのように使用できる。以下のように。

　Dim func As BinaryFunction
　Dim ret As Long

　Set func = New FooFunc
　ret = func( 5, 3 )

　

　ちょっと厄介なのは、これらのファンクタインタフェイスを実装するユーザークラスでも Execute( ) を既定メソッドに指定することが仕様上要求されることだ。例えば、上記の FooFunc がその仕様上の要求を満たしていない場合、上記コードは OK でも以下のコードはコンパイルエラーとなる。

　Dim func As New FooFunc
　Dim ret As Long

　ret = func( 5, 3 )　　'// コンパイルエラー！

　

　実際のところ、ファンクタはインタフェイス経由で使用するべきなので、この点はそれほど心配はしていない。しかし、問題はもうひとつある。VBA 環境でファンクタを自作する場合、そもそも既定メソッドの指定ができないらしいのだ。これは環境上の制約としてドキュメントしておいた。

　あとは、以前書いたとおり、スコープ外のオブジェクト（ 要するにクラスメンバとか大域オブジェクト ）に対して復帰値を利用しない形式で既定メソッド呼び出しを使った場合にエラーが発生する。この点についてもドキュメントした。正直制約が多いが、なんとなく STL っぽい書き方ができるようになったので個人的には気に入っている。

　．．．というわけで、2006 年最初の仕事は奇しくも VBGeneric となった。さて、Palmware に取り掛かるか．．．（ おいおい正規表現エンジンはどうなった？ ）

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年02月22日

去年の今頃は

　さて、こんな時間の更新でも実は職場からだったりしてかなりふてくされた結果として少しばかり後ろ向きな心持で過去を振り返りますは成り行きで月イチ企画になってしまった 「 去年の今頃は 」 ですそれでは行ってみましょうどん（ 棒読み ）。

　2005 年 2 月 はどんなことをやっていたか。Movable Type に移行する前なのは先月と一緒。さて。

　
・ 開発

　１月に引き続き正規表現エンジンの実装に取り組んでおるようです。エンジンが扱う文字の型をテンプレートパラメータにするという、後からやるにはキチガイじみた修正をしております。いい感じで泥沼にはまっていますな。ま、最近その泥沼に戻ってきたわけですが。

　
・ project-graphica

　2 / 6　にわざわざ名古屋まで行って REDRED ＆ ごくつぶし の２バンドを撮影してますな。今年に入ってデジタル一眼レフにしましたが、やっぱり使っている暇がありません。なかなか気軽に持ち運べるもんではないので、たまにこの日記用の写真を撮る程度です。5cm くらいまで寄れるマクロレンズが欲しいな。

　
　
・ Palm

　Palm のコーナーである in my palm を独立させたのが２月の末頃。ということはそろそろ１年になるんですな。そして同時に m515 の液晶漏れを修理に出しています。ということは、これまた良品交換から１年ということ。最近は開発機として使うだけなのでちょっぴり可哀想です。

　
・ その他

　２月の中ごろに dunnet にハマっていますね。dunnet というのは、Emacs エディタで遊べるテキストベースのアドベンチャーゲームです。Emacs を持っている人は M-x dunnet で起動！　当然全部英語で、しかも全部テキストベース。しかしこれが面白い！　暇があったらもう一度やりたいですね。しかしそれは当分やれないという意味。嗚呼。

投稿者 kagelow : 00:05 | コメント (0) | トラックバック

2006年02月17日

Functor、でいいのか？

　えぇと、VBGeneric の話ですごめんなさい （ と先に謝っておく ）。

　いきなりだが C++ の演算子オーバーロードをご存知だろうか。たとえば、自作のクラス Foo に対して以下のような大域比較演算子を定義しておくと、

　bool operator==( const Foo& foo1, const Foo& foo2 );

．．．Foo のオブジェクトに対して比較演算子 == を使用することができるようになる。演算子オーバーロードは、クラスを組み込み型のように扱えるようにするための仕組みだ。その他にも色々な演算子がオーバーロードできるようになっているが、その中には関数呼出し演算子 （ て名前だったかな ） もある。これは、オブジェクトを関数ポインタのように扱えてしまうというものだ。以下のようなクラス FooFunc があると、

class FooFunc {
public:
　　int operator( )( int arg1, int arg2 ) {
　　　　return arg1 + arg2;
　　};
};

　．．．FooFunc のオブジェクトを作成して以下のようなことができる。

　FooFunc func;
　int ret = func( 5, 3 );

　この演算子オーバーロード、テンプレートと組み合わせるとその真価を発揮する。テンプレートパラメータに組込み型とユーザー定義タイプを分け隔てなく指定できるようになるからだ。STL の関数オブジェクトもこの operator( ) を利用している。これによって、アルゴリズムのテンプレートに関数ポインタを渡したり関数オブジェクトを渡したりできるわけだ。そして STL を真似している VBGeneric にも関数オブジェクトは存在する。ところで、関数オブジェクトのほかにファンクタという呼び方もあるようだが、Functor という綴りでいいのだろうか？　辞書に載ってないんだよなそんなの。

　話を戻そう。Visual Basic には当然演算子オーバーロードなどというものはない。だから、VBGeneric の関数オブジェクトである UnaryFunction や BinaryFunction では Execute( ) というメソッドを用意する。しかし、ここでも前回のバージョンアップでの At プロパティと同じことができてしまうのだ。つまり、Execute( ) を既定のメソッドに指定することで、まさにファンクタのように使えてしまえるようになるのである。先の FooFunc の使用例をそのまま VBGeneric に当てはめると以下のようになるだろう。

　Dim func As New FooFunc
　Dim ret As Long

　ret = func( 5, 3 )

　．．．と、まぁこんな仕様変更を思いついたわけだ。というか、コンテナやランダムアクセス反復子の At プロパティを既定化するときに気づくべきだったのだが。というわけでまぁこれを早いとこ対応してしまおうとしている．．．修正は２時間くらいで終わるもののリファレンスマニュアルが時間がかかりそう。

　しかし。話はこれでは終わらない。Visual Basic の（ 変な ） 仕様が原因で、どうもこの既定のメソッドが使用できない局面があるのだ。調べた限りでは、スコープ外のオブジェクト（ 要するにクラスメンバとか大域オブジェクト ）に対して復帰値を利用しないような記述をした場合にエラーが発生する．．．まぁそれはそういうものとして提供するしかないか。

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年02月03日

入門ノ思ヒ出

　いくつかのサイトで、プログラミング入門的な話題がちらほらと。mizuno-ami さんの所からたどり着いたこちらの一文が目を引いた。引用させていただく。

　．．．自転車で例えると、入門書というのは「補助輪」ではないか？。効果的だが本質的ではない。補助輪をつけている時は自転車に乗れるが、外したとたん乗れなくなる。入門書は最初から最後まで一通りやってみたが、その先にうまく進めないという人が結構いるのではないか？　ここがプログラミングを覚えるということの特異性だと思う。

　この一文は、「 脱入門書問題 」 を良く言い表していると思う。入門書によって入門することはできても、脱入門できない。入門書と、脱入門の間には、なお隔たりがあるのだ。しかし、「 脱入門書 」 なるものにはお目にかかったことがない。それが難しいことだからなのかもしれないし、この問題に対して決定的な処方箋がないからなのかもしれない。それに関してなんらかの意見を持ってはいるが、はっきりと書けるようなものにはなっていないのでここには書かないでおく。

　少し、この件をきっかけに自分自身のプログラミング入門時代を思い出した。といっても、かれこれ20年以上も前の話だし、物心つくかつかないかという年齢のことなので記憶が曖昧なのだが。陰郎が初めて触ったプログラミング環境は、あの （ そう、あの ） Family Basic である。Family Computer、いわゆるファミコンに専用カセットと専用キーボードをつなぐと、Basic のプログラミングができた。ソースコードの記憶領域は 2KB。2MB ではない、「 ２キロバイト 」 である。何故 10歳にもならぬ子供がそんなものを欲しがったのかすら、もう思い出せない。どうやら、プログラミングという行為をするという自覚もなしに始めたようだ。

　最初はわけもわからずにマニュアルのサンプルを打ち込んだ。行末で Enter を押さないとその行が保存されないことも知らず、カーソルキーと文字キーだけを使って画面上にソースを打ち込み、動作しないで首を傾げたことをぼんやりと覚えている。どういう幸運があったのかはわからないが、正常に動作するようになると、ファミコンのコントローラを使ってマリオやルイージを動かすことができた。そのうち、試行錯誤的にソースを修正し、ソースをどう変えたら動きがどう変わるのかを学んでいった．．．ように記憶している。あの頃、飽きて放り出していたら自分の人生はまったく違ったものになっていただろう。

　だらだらと書くのはよそう。陰郎の 「 入門 」 は上に書いたような感じだったのだが、「 脱入門 」 がどのようになされたのか、それは自分でも良くわからない。しかし、答えは案外プログラミング以外のところにあるような気がする。実は、陰郎は高校の後半から大学の４年まで、計５年近くもプログラミングから遠ざかっていた。それ以前は書籍に書いてあるコードを打ち込む程度だったのだが、大学４年生のときに復活した時点ではあきらかに脱入門していたように思う．．．では、その間やっていたことに理由があるのだろうか？　しかし、昼休みは終わってしまった。続きは改めて書こう （ 書かないかもしれないが ）。

投稿者 kagelow : 12:55 | コメント (0) | トラックバック

2006年02月02日

class DLL [3]

　さて、ここからはちょっと微妙な話になる。５年前の陰郎は LoadLibrary( ) や FreeLibrary( ) について完全に理解していたわけではないようだ （ 今もそうかもしれないが ）。というのは、LoadLibrary( ) や FreeLibrary( ) を複数回数呼び出すことによるトラブルは、API の側で参照カウントを管理することで対処がなされているにも関わらず、陰郎の DLL ラッパークラスは自前で参照カウントを実装し、オブジェクトのライフサイクルを管理していたからだ。

　前回は説明を単純化するために参照カウント関連は完全に省いて書いたが、実際には SampleDLL クラスは参照カウントを実装し、値オブジェクトとして使用されるハンドルクラステンプレートがそれをさらにラップする．．．このあたりの実装はボツにする予定なので詳しくは書かないが、要するに必要の無いことをやっていました、ということだ。それに、オブジェクトの new や delete にまつわる問題を回避するために参照カウントハンドルを使用するとしても、最初から組み込んでしまうとそうしたくない場合に困る。C++ には多重継承があるのだし、それ以外の方法でも参照カウントを利用した DLL ラッパーは必要に応じて合成できる．．．それならば DLL ラッパー単体の実装はシンプルである方が良い。これが参照カウント実装をボツにするもうひとつの理由である。

　まだある。前回の説明用サンプルコードでいうところの DLLBase クラスがあるせいで、DLL 個別に定義する派生クラスは小さい割りに記述が面倒になる。これを、５年前の陰郎はプリプロセッサマクロで乗り切ってしまった。しかし、５年経った今見てみると、明らかに幼稚だ。今となってはプリプロセッサマクロを避けた方が良い理由は痛いほどわかっているし、DLL のラッパークラスなどそうそう乱造するものでもない。というわけで、どうやらマクロもやっつけなければならないようだ。

　．．．となると、どうやら public な const 関数ポインタをもってメンバ関数のように見せかけるというテクニックしか面白いものはないということになる．．．やはり人間５年も経つと考え方や見え方が大きく変わるようだ。前回、そのうち公開しようかなどと書いてしまったが、どうやら思いとどまった方がいいのかもしれない。

投稿者 kagelow : 12:10 | コメント (0) | トラックバック

2006年02月01日

class DLL [2]

　さて、今回は DLL ラッパークラスのカラクリについて書いてみよう。前回書いたような使い方を実現するためには、SampleDLL クラスは以下のようになっていればいいことになる。

　

class SampleDLL {
private:
　　typedef int (*FooT)( int, const char* );
　　typedef void (*BarT)( int );
public:
　　SampleDLL( );
　　~SampleDLL( );
public:
　　const FooT Foo;
　　const BarT Bar;
};

　
　．．．と、こうなっていれば、SampleDLL のオブジェクトに対して Foo( ) や Bar( ) が呼び出せるわけだな。そして、これらの const な関数ポインタメンバを初期化するのは当然コンストラクタでやるべきことだ。しかし、const メンバである以上、コンストラクタの初期化リストで指定せねばならん。関数ポインタメンバが public である以上、const メンバにしないわけにはいかない。ここで問題が発生する。const メンバを初期化するよりも前に DLL をロードしなければならないのだ。これをどうするか。クラスのメンバよりも先に初期化されるもの。それは基底クラスだ。そう、それが答えだ。

　というわけで、DLLBase クラスを用意する。こいつはコンストラクタとデストラクタで DLL のロードと開放をする。そして、派生クラス向けに関数ポインタのアドレスを取得するメンバ関数を用意．．．と。インプレは省略。

　

class DLLBase {
private:
　　HINSTANCE　m_handle;
public:
　　DLLBase( const char* pDLLName );
　　~DLLBase( );
protected:
　　void* GetProc( const char* pProcName );
};

　

　で、この DLLBase クラスから SampleDLL を派生すれば、SampleDLL のコンストラクタは以下のように書ける。これなら関数ポインタメンバが初期化される時点では DLL のロードが完了していると前提できる。

　

SampleDLL::SampleDLL( ) : DLLBase( "Sample.dll" ),
　　　　　　　　　　　　　Foo( (FooT)GetProc( "Foo" ) )
　　　　　　　　　　　　　Bar( (BarT)GetProc( "Bar" ) ) { }

　

　基底クラス DLLBase で DLL のロードに失敗したら？　一般に、DLL のロードや関数アドレスの取得で発生するエラーはアプリケーションレベルでは致命的とみなしてよいものだ。だから、これらのクラスはエラーを検出すると例外を投入する．．．と。こうなっていれば、SampleDLL クラスのインスタンスの生成に成功すればすなわち DLL 関数が利用可能であることが保証されるわけだ。

　．．．さて、基本的なカラクリは説明したかな。今日はこの辺で。

投稿者 kagelow : 12:15 | コメント (0) | トラックバック

class DLL

　仕事中、Windows エクスプローラを使用していたら、ちょっと間違えて懐かしいフォルダを開いてしまった。そこには、かれこれ５年前に書いた DLL 関数のラッパークラスのソースコードが。最近仕事に倦んでいるせいもあり、忙しいのにちょっとイジってみたりして。というわけでちょいと書いてみよう。

　普通、Win32 SDK の世界では、直球勝負で DLL 関数を呼び出す場合、LoadLibrary( ) で DLL をロードし、GetProcAddress( ) で DLL 関数のアドレスを取得し使用、用済みになったら FreeLibrary( ) で開放．．．という段取りを踏む（ もちろん他の方法もあるが ）。ここで Sample.dll に以下の２つの関数 Foo( ), Bar( ) があるとすると、上記の方法なら以下のようなコードになる。あ、ちなみにコードは C++ スタイル。

　

　typedef int (*FooT)( int, const char* );
　typedef void (*BarT)( int );

　HINSTANCE handle = ::LoadLibrary( "Sample.dll" );

　FooT pFoo = static_cast<FooT>( ::GetProcAddress( handle, "Foo" ) );
　BarT pBar = static_cast<BarT>( ::GetProcAddress( handle, "Bar" ) );

　int ret = pFoo( 0, "test" );
　pBar( ret );

　::FreeLibrary( handle );

　

　まさにクラスでラップするためのサンプルのような状況だ。FreeLibrary( ) を呼び忘れることが考えられるし、アプリケーション全体でこの DLL を使用するのであれば handle を保持したり、FreeLibrary( ) を呼び出すタイミングや責任をどうするかという問題もある。取得した関数アドレスを、FreeLibrary( ) を呼び出した後で使用すれば簡単に破局が訪れるだろう。また、場合によっては typedef が大域に浮遊することも考えられる。そして、これらの問題のほとんどはクラスでラップしてやることで解決できる。たとえば、以下のように使用できるクラス SampleDLL があったらどうだろう。

　

　SampleDLL theDLL;

　int ret = theDLL.Foo( 0, "test" );
　theDLL.Bar( ret );

　

　．．．つまり、DLL にまつわる API 呼出しは全てこの SampleDLL クラスの中に隠されているわけだ。クラスのコンストラクタ／デストラクタで DLL のロードや関数アドレスの取得、DLL の開放をやってくれるからミスは少なくとも局所化できる。SampleDLL::Foo( ) などを使用できるのはオブジェクトが存在している間だけだからその点でも安心だ。DLL が提供する関数とクラス定義は密接に関連するから、DLL 名ですらクラスの中に隠すことができる。そして面白いことに、このクラス SampleDLL にはメンバ関数 Foo( ) や Bar( ) は存在しないのだ。なんと、上記コードで使用されている Foo や Bar は、DLL 関数のアドレスを指す public な const 関数ポインタ、つまりデータメンバなのである．．．ま、こういったことを巧妙にやってくれるカラクリを作ったわけだ。５年前に。

　で、５年経ってソースコードを見る．．．うぅむ、甘い。甘いぞ５年前の陰郎よ。以前にも書いたことだが、昔書いたコードに未熟さを感じるとき、陰郎は少し安心する。まだ自分は成長しているのだ．．．というわけで修正。作ったときもそう思っていたけれども、このカラクリは結構面白い。せっかくだから続きは後日書こう。そしてこの DLL ラッパークラス、そのうちに公開してみるとしよう。使う人がいるかどうかはわからないが。

投稿者 kagelow : 01:17 | コメント (0) | トラックバック

2006年01月23日

pure C が書けない

　昼間の仕事の話。

　今関わっているプロジェクトの中心にある、こみ上げてくるほどデキの悪いシステム。C言語で書かれたプログラムの山なのだが、その機能拡張案件で、テストのためのドライバプログラムを書くことになったわけだ。陰郎としては、本当に久しぶりな C 言語の作業。ま、１日で仕上げなきゃならないのだけれど、やってみるとこれが惨憺たる結果になった。C++ なら毎日のように書いているのだが、逆にそれが災いしたのだ。情けないくらいに細かいところでつまづく．．．細かいことを書くのは避けるが、要するに C と C++ で違う部分全部でつまずいている感じだ。関数分割と構造体くらいしか組織化メカニズムが無い状態で論理デザインを上手に構成する、ということもすでにできなくなっている。これには唖然としてしまった。C++ の豊富な言語機能を使うというのは贅沢なことなんだな．．．と思った次第。

投稿者 kagelow : 23:15 | コメント (0) | トラックバック

2006年01月22日

ひさしぶりに個人使用プログラム

　昨日のエントリ 「 去年の今頃は 」 で、日常的なバックアップを何とかしなければならないことに久しぶりに気が付いた。最近はお手ごろな値段で高機能なバックアップソフトが売られているようだが．．．いやいや陰郎、おまえは開発者じゃないか。たまには自分専用のプログラムでも作っちゃどうだい？

　．．．というわけで、高機能でなくてもいいから、自分にとって 「 必要十分 」 なバックアップツールを作ろう！　となったわけだ。できあがったのはどちらかというと 「 低機能 」 なのだけれど、シンプルなつくりでけっこうお気に入り。

　カラクリは簡単。バックアップ対象のディレクトリ一覧を書いたテキストファイルを読み込み、バックアップ用のバッチファイルを作成する。それだけのツール。で、このツールを起動し、出来上がったバッチファイルを起動して終わったら削除するようなバッチファイルも作っとく。さらに、コマンドラインからメールを送信するフリーソフトウェアを使用して、バックアップが終わったら自分の京ぽんにメールが入るようにしておく．．．と。これでバックアップ中に PC から離れても大丈夫。

　で、毎日やるのと、週一回のもの、月一回のものと分けておけばいい感じ。でもって OS 標準のタスクスケジューラに定期的な起動を指示しておく．．．うん。できあがりぃ♪

　なんか、Ｄ．Ｉ．Ｙ って感じでいいね。自分専用だから、汎用性を個人レベルでしか気にしなくていいってのも気楽。シンプルに作って、必要なら後からイジれるし。ま、すぐにイジりたくなるんだけど。

投稿者 kagelow : 13:15 | コメント (0) | トラックバック

2006年01月21日

去年の今頃は

　久しぶりに、このタイトルで書こうかね。

　えぇと．．．まだ Movable Type に移行する前ですな．．．2005年１月 は、と。まだ Palmware の開発を始める前なんだな．．．（遠い目

　では、どんなことをやっていたか。トピックごとに。

　
・ 開発

　あの頃は、regex++ 一色だったな。リファレンスを書いたり、最適化についてああでもないこうでもないと考えていた。そんな１年前を振り返ると、この作品の復活に向けて気が引き締まるというもの。春までには最初のアルファ版リリースをするぞ （ アルファ版かよ ）。

　あと、regex++ を Linux 上でコンパイルさせるという試みをやっていたのもこの頃だ．．．う～ん、全敗しているな。（一般的なという意味で）徹底してジェネリックなスタイルのC言語プログラムでない限り、複数のプラットフォームやコンパイラでそのままコンパイルできるソースコードを目指すのは無理なのかもしれない．．．な。

　
・ project-graphica

　2005年から正式にトップページからリンクを辿れるようになったわけだけれども、まともに写真を撮っていたのは春くらいまでだったわけだな。このあと、Palmware 開発を始めたあとは写真機をほとんど触らなくなっていく．．．しかし、今年はデジタル一眼レフの購入も決意していることだし、なんとかこの方面も復活したいものだ。

　
・ books

　1/26 に 「 D & E 」 と 「 C++再考 」 を購入している。「 D & E 」 はもう２～３回は読み返しているな．．．でも、「 C++再考 」 はまだ読了していない気がする．．．

　本に関しては、1/29 に books review を改造している。この改造で、books review の各ページから引用文のページにリンクできるような CGI になったんだな。しかし、以後、このあたりのコーナーも放置されることになる．．．もっとバランスよく活動する必要があるな。うん。

　
・ Palm

　1/30 に、Tungsten T5 のクレードルを入手している。陰郎のメインPCのデスクの隅っこにいるこいつももう１年か．．．最近接触が悪いのが気になるな。

　当時を振り返って思うのは、自分にとっての Palm という存在は、Palmware 開発を始める前と後ではまったく違ったものになったということだ。どっちがいいとかいう問題ではなく。どう変わったのかと問われると上手く書けないのだけれど。曖昧だけれど、「 真ん中に来た 」 という感じ。

・ その他

　1/22 に PC の HDD トラブルが発生している。あのとき、日常的なバックアップの重要性を痛感したにもかかわらず、１年経ってみればなにも改善されていない。適当なバックアップのカラクリは作ったけれども、結局対して使っていないのだ。それでいいのか？　いいわけがない。ちゃんとやろう。うん。

投稿者 kagelow : 19:55 | コメント (0) | トラックバック

2006年01月18日

型伝播の悩み事

　．．．というタイトルでエントリを書いたのだが、プログラミングをやらない人には面白くもなんともない内容になってしまった。そのため、内容の大半は「続きを読む」の向こう側に置く事にする。結論としては、Microsoft Visual C++ 6.0 は標準 C++ への準拠という点からは少々古いんだね．．．ということである。まぁ８年も前のコンパイラだし、この10年でC++は大きく変わったから無理もないのだけれど。

　C++ のテンプレートあたりに興味のある方は読んでいただけると幸いである。もちろんそれ以外の人も歓迎するが、あくびがでないことを祈る。なお、別に目新しいことを書くわけではない。それでは、はじめようか。

　

　C++ のクラステンプレートでは、テンプレート引数を typedef することで、後から型情報を拾うことができる。たとえば、以下のようなクラスがあるとしよう。

template <typename T>
class Foo {
public:
　　typedef T　　ParamT;
};

　こうなっていれば、Foo<int>::ParamT は int 型である。

　次に、テンプレートの特殊化について。あるクラステンプレート、およびそのクラステンプレートのポインタ型に対する特殊化を用意したとする。以下のように。

template <typename T>
class Baz {
　　// 定義Ａ
};

template <typename T>
class Baz<T*> {
　　// 定義Ｂ
};

　こうなっていると、Baz<int> であれば定義Ａが使用され、Baz<int*> であれば 定義Ｂが使用される。結論からいうと、この特殊化が Microsoft Visual C++ 6.0 ではコンパイルできないのだ。

　この機能は、テンプレートを駆使したプログラミングでは有用なテクニックで、STL などでも使用されている （ と記憶している ）。例として、ポインタの一般化としての反復子をパラメータとするテンプレートを考えよう。そのテンプレートでは反復子の型を IteratorT、その反復子が指す値の型を ValueT として typedef したい。反復子自身が ValueT を提供するとして、それは以下のように書ける。

template <typename ITR>
class Qux {
public:
　　typedef ITR　　　　　　　　　　IteratorT;
　　typedef typename ITR::ValueT　　ValueT;
};

　しかし、このテンプレートにはポインタ型を渡せない。ポインタは ValueT を提供しないからだ。そこで、以下のような特殊化を用意する。

template <typename VAL>
class Qux<VAL*> {
public:
　　typedef VAL*　　IteratorT;
　　typedef VAL　　ValueT;
};

　こうすれば、Qux<iterator> でも Qux<object*> でも対応できる．．．少なくとも標準 C++ に準拠していればこのコードはコンパイル可能だ。以下のような感じで。

#include <iostream>

template <typename ITR>
class Qux {
public:
　　typedef ITR　　　　　　　　　　IteratorT;
　　typedef typename ITR::ValueT　　ValueT;
};

template <typename VAL>
class Qux<VAL*> {
public:
　　typedef VAL*　　IteratorT;
　　typedef VAL　　ValueT;
};

class Dummy {
public:
　　typedef int ValueT;
};

int main( void ) {

　　typedef Qux<Dummy>　　Qux1;
　　typedef Qux<char*>　　Qux2;

　　std::cout << "size of Qux<Dummy>::ValueT is " << sizeof( Qux1::ValueT ) << std::endl;
　　std::cout << "size of Qux<char*>::ValueT is " << sizeof( Qux2::ValueT ) << std::endl;

　　return 0;
}

　．．．一応、Windows 上で動作する gcc （ 多分 2.95 かな ） ではコンパイルできたし、結果も正しかった。しかし、 VC++6.0 ではコンパイルできない。もちろん、この機能が使えないとしても代替策はある。しかし、それをやるとコードが煩雑になるのでやりたくないのだ．．．ところで、いくつかの理由でいまだに 6.0 を使用しているわけだが、このあたりの 「 重箱の隅っこ 」 は最近のリリースでは標準に準拠するようになったのだろうか？　もちろん、そうだとしても安易に乗り換えるのも怖い。世の中ではまだ Visual Studio 6.0 が現役で使用されていたりもするからだ。最新のコンパイラでなければ通りません、というのも別の意味で困る．．．はてさて。

投稿者 kagelow : 21:25 | コメント (0)

2006年01月16日

ど忘れのブルース

　．．．「 ブルース 」 という部分に意味は無い。昨年 11/01 にアップデートをリリースした VBGeneric ライブラリ。あれ、Vector に登録してあったのだが、なんと、２ヶ月半もの長きに渡って更新の連絡をするのを忘れていたのだ。嗚呼。

　．．．というわけで ftp にて Vector にファイルをアップしてから連絡メールを出す。２ヵ月半前のアップデートの掲載をお願いするというのも恥ずかしい話だ。しかも、毎度のことだが連絡方法がイマイチわからず四苦八苦する。

　VBGeneric のことを書くときは恒例になってしまった感があるが、今回も宣伝。世のプログラマの皆さん、薄幸のライブラリ、VBGeneric をどうぞよろしく。

投稿者 kagelow : 21:40 | コメント (0) | トラックバック

2006年01月15日

お気に入りの横着コード

　突然だが、以下のコードを見て欲しい。なにをやっているか、わかっていただけるだろうか。（ weblog だとインデントが崩れるのは勘弁願いたい ）

　switch( n ) {　　while( true ) {
　case 0:　　　　　　 Foo( );
　　　　　　　　　　　if( n == 2 ) break;
　case 1:　　　　　　 Bar( );
　　　　　　　　　　　if( n == 0 ) break;
　case 2:　　　　　　 Qux( );
　　　　　　　　　　　if( n == 1 ) break;
　}　　　　　　　　}

　人によっては、以下のように書き換えた方が見やすいかもしれない。　
　
　switch( n ) {
　　　while( true ) {
　case 0:
　　　　　Foo( );
　　　　　if( n == 2 ) break;
　case 1:
　　　　　Bar( );
　　　　　if( n == 0 ) break;
　case 2:
　　　　　Qux( );
　　　　　if( n == 1 ) break;
　　　}
　}

　いずれにしても奇妙だ．．．switch と while のブロックが絡み合っている．．．switch によって、while ブロックの 「 途中 」 にいきなり飛び込んでしまうようだ。しかし、これは C/C++ のコードとして完全に合法である。つまり、コンパイルが通り、「 書かれている通りに 」 動作するのだ。しかし、「 書かれている通り 」 とは？　そもそも、このコードは何をしようとしているのだろう？　なぜこんな書き方をしているのだろう？

　n が 0, 1, 2 それぞれの場合でコードを追ってみるとよくわかる。n == 0 の場合、Foo( ), Bar( ) の順に実行されて break、n == 1 の場合、Bar( ), Qux( ), break、そして（ ここが肝心なのだ ）、n == 2 の場合、Qux( ) を実行した後、while ループによって先頭に戻り、Foo( ) を実行して break する．．．つまり、これは以下のコードと同じである。

　switch( n ) {
　case 0:
　　　Foo( );
　　　Bar( );
　　　break;
　case 1:
　　　Bar( );
　　　Qux( );
　　　break;
　case 2:
　　　Qux( );
　　　Foo( );
　　　break;
　}

　ようするに、３つのうちから２つの組み合わせがそれぞれ実行されることを利用し、Foo( ), Bar( ), Qux( ) の呼び出しを１回だけしか書かないようにするため（ だけ ）にこんなことをしているというわけだ。いささか馬鹿げているように感じられるかもしれない。しかし、場合によってはこれは 「 使える 」 テクニックだし、そうでなくてもお楽しみという点では合格点だろう。実際、Foo( ) だの Bar( ) だのといったシンプルな呼び出しは説明のためであり、実際のコードはもっと長いから、このテクニックによって長さが半分になるのである。

　このテクニックは陰郎の頭の中に突然浮かんだものではない。これは、「 ハッカーズ大辞典 」という本に載っていた Duff's Device というやつの簡単な応用である。switch 文の case ラベルが while ループの中に飛び込んでしまえるというのを初めて見たときはショックだった．．．陰郎はこれを大変面白がり、自分のコードに使った。それが冒頭に載せたコードである。久しぶりにそれを見つけたので、懐かしくなってここに書いた次第。

投稿者 kagelow : 13:40 | コメント (0) | トラックバック

2006年01月13日

読了。すなわち行動開始。

　．．．読み終わった。何の話かといえば先日のアレだ。先日は 「 あと１年分くらいある 」 と書いたが、それは誤りだった。記録は 2005/04/21 を最後に途絶えているから８ヶ月分だ。毎日つけていたわけではないから、実質的には半年分くらいだったことになる。それにしても、2004/04/21 ってことは一時期 PalmLife の開発と平行して作業していたんだな。ふぅ。（ 遠い目

　しかし、読み終わったということは動き始めるときが来たということだ。もちろん、いきなりアクセル全開というわけにはいかない。絶対怪我する。少しずつ慣らし運転をしていこう。事実上一年ぶりの開発再開である．．．今後、正規表現エンジンの実装に関する意味不明なエントリが増えるかもしれないが、あまり気にしないでやってほしい。

　それでは皆さん、良い終末を。（字が違う）

投稿者 kagelow : 22:45 | コメント (0)

チームひとり

　どういう因果か知らないが、陰郎は昼間の仕事でも単独行動的な役割を果たすことが多い。今現在の仕事では、管理者を除いて現場には８人いるのだが、４人のＡチーム（とここでは呼んでおこう）、３人のＢチーム、そして陰郎ひとりのＣチーム．．．である。

　１人なのにチーム？　しかし、Ｃチームと呼ばれるのだ。何をやるかというと、いろいろやる。無論 「 主力部隊 」 はＡ・Ｂチームだ。陰郎はその陰に隠れていろいろやる。Ａ・Ｂ両チームに関わる共通的なことも受け持つし、突発的に発生する作業の対応、スケジュール上に現れないような 「 裏の仕事 」 もやる．．．なんて書くとなんだかアレな感じがするけれども、要するに遊撃部隊みたいなものである。そしてどうやら、それが陰郎には向いているようなのだ。

　気が付けば、仕事人としての陰郎のスタイルになりつつある 「 チームひとり 」 。似たような名前の芸人がいたような気がするが、テレビを持っていないのでよくわからないし、それでいい。そういえば project-enigma も最初はあと２人くらいいたような気がするな．．．でも多分気のせいだ。うん。

投稿者 kagelow : 00:00 | コメント (0) | トラックバック

2006年01月10日

現在 2004/09/04 の辺り

　．．．なんの話かというと、2006/01/05 に書いた 「 そうなるに至った経緯 」 で少し触れた、「 ８ヶ月ほど放置したプロジェクト 」 の作業記録を読み返す作業。記録としては 2004/03/30 からつけていたのだが、必死こいて読み返すこと１週間弱、なんとか５ヶ月分くらいは読んだ。ふぅ。かなり脳が当時の状態に戻ってきた。でもあと１年分くらい読まなきゃなんだな。

　このプロジェクト、実は 「 2005年総括 」 に書いた、自作正規表現エンジンのことなのだ。今年はなんとかしてこいつを完成させるのだという密かな目論見を立てていたのだが、目論見のままだと都合よく忘れる可能性がある。そのため、この開発日記に露出することにした。過去の記録を読み終わり次第、開発を再開するつもりだ。日々の経過もここに記録することになるだろう。

　Palm 関連で訪れてくださる皆さんには面白みの無い話題かもしれないが、興味があったら斜め読みでもしてやっていただけると幸いである。あ、もちろん今年も Palmware 作りますよ。でも、他の活動も平行して頑張ってみようと思うので、去年みたいなハイペースにはなりません。悪しからずご了承くださいまし。

投稿者 kagelow : 23:25 | コメント (0) | トラックバック

2006年01月09日

UML にノスタルジア

　開発に縁の無い方にはさっぱり意味不明な話だとは思うが、陰郎の重要な活動テーマの１つに UML がある。これは Unified Modeling Language の略で、Language とは言うもののプログラミング言語ではない。これは、オブジェクト指向系の言語のモデル図を作成するための記法のことだ。

　陰郎が UML を使い始めた頃は、まだ安価なツールが存在しなかった。欲しくて指をくわえて見ていたのが、IBM に買収される前の Rational 社の Rose だった。たしか 50万円くらいしたと記憶している。当時はまだ会社従業員だったので購入できず、当時は紙にペンで作図することから始めた。そんなものが長続きするわけも無く、これまた Microsoft 社に買収される前の Visio 社の Visio を購入した。Visio はシェイプとよばれるコントロールを自作できるから、これで UML のいろいろなダイアグラムの部品を自作した。Visio は自動化という点でもよくできていたし、VBA を搭載していたからさまざまなマクロを書いて自動化できた。これは６年近く使っている。陰郎の自作ツールの中でももっとも息が長い。余談だが、Visio 社が Microsoft に買収されたのはドローイングソフト関連の特許を持っていたことに加え、主力製品である Visio に VBA を搭載してしまったからではないかと陰郎は考えている。食われやすいように自らを料理してしまったというわけだ。そして現在は Microsoft Visio という Office 製品の一部であるかのように並べられている。合掌。

　で、この２年ほどはその自作ツールも使っていなかった。UML から遠ざかっていたわけだが、先日からやっている Java の仕事で、設計図などのドキュメントを書くのに使っている。これがもう懐かしくてたまらない。C++ やデザインパターンを必死こいて勉強していた20代の自分が思い出される．．．UML の本も一生懸命読んだっけな。GoF のデザインパターンも面白かったな．．．あの頃に戻りたい．．．（涙

　しかし、懐かしいのと同じくらい激しくほころびが目立つんだな。ツールの。細かいバグもたくさんあるし、全体の構造が汚い。これまた余談になるが、昔作ったプログラムを見て恥ずかしい思い （ 俺ってこんな酷いコードを書いてたの？ ） をすることは 「 良いこと 」 だと陰郎は思っている。いや、酷いコードを書くことが良いのではなく、過去の自分の書いたものを見てそう思うのは自分が成長している証と言えるからだ。昔書いたコードを見て、今でもまったく同じコードを書きそうだったとしたら、自分に何の変化もなかったことを意味する。どちらかといえば、そっちの方がずっと恥ずかしいだろう。

　で、陰郎は悩むわけだ。「 このツール、作り直したい 」 と。しかし、当時と今では事情が違う。安価な UML モデリングツールや、フリーソフトウェアとしてリリースされているものがあるのだ。今、自分で作る必要や必然性があるだろうか？　これに対する陰郎の姿勢は、「 作ることは、使うことだけのためではない 」 というものだ。VBGeneric を作ることで STL の細部の細部まで学習することができたように、自分で作ることで UML の細部まで学習することができる。未完の大作である regex++ も同じだ （ 絶対今年中にリリースするぞ ）。今から UML に取り組むなら UML 2.0 のいい勉強になるだろう．．．

　そんなわけで、陰郎は今年もやりたいことが山積みである。時間が足りない。土地を売り買いするみたいに時間も売ったり買ったりできないものだろうか。そうすればヒマ人は時間を売って金を手にできるし、逆の人は金を時間に替えることができる。こんなことを考える陰郎はやっぱり変人かもしれない。

投稿者 kagelow : 00:45 | コメント (0) | トラックバック

2006年01月07日

誰にでもわかるように

　．．．ちょっと心がすさみがちな最近の陰郎。なんでかというと、昼間の仕事でいろいろとやるせない思いをしているからだ。日本だけがそうなのかどうかはわからないし、陰郎が仕事をするところだけがそうなのかもしれないのだが、なんで情報処理業界 （ ＩＴという言葉は嫌いだ ） の人間はああも幼稚なのだろう？　今回は、その幼稚さを象徴する （ 少なくとも陰郎はそう思っている ） 言葉、「 誰にでもわかるように 」 について書いてみよう。

　「 誰にでもわかるように書いてください 」 とか 「 誰にでもわかるように作ってください 」 とか言われると、毎度のこと陰郎は言いようのない怒りを感じる。そもそもこの発言にはなんの前提も条件も無い。厳密に、どうすればこの条件を満たせるのかを知る方法があるだろうか？　苦労してわかりやすく作ったつもりでも、出来上がった後に 「 誰にでもわかるようにって言ったじゃないですか。これじゃわかりませんよ。 」 と言われたら終わりなのだ。なんら条件を提出していないという点で、この言明はあまりにも無責任である。

　大体、「 誰にでも 」 ってどういうことだろう？　"Anyone" ということだよな。つまり、その辺の通りを歩いているおばちゃんや子供にもわかるように、ということだろうか。揚げ足取りのように聞こえるかもしれないが、「 誰にでも 」 という言葉を額面どおりに受け取ればそうなるし、そうでないならば 「 誰にでも 」 はすでに誤りなのだ。百歩譲って、「 この業界の人間ならば誰にでも 」 だとしよう。それでもまだ解決はしない。たしかに対象領域は限定されたが、それでもまだ広すぎる。陰郎にはとてもそんなことはできないし、できそうな人にお目にかかったこともない。

　あまり話を広げるつもりはないので、特にソフトウェアの設計と実装に関連する部分について書いておこう。ことプログラミングになるとよく言われるのが 「 初心者にでもわかるように書いてください 」 というものだ。ちょっとまて。我々はプロじゃないのか？　もちろん、気持ちはわからんでもない。今陰郎に作らせたとしても、未来永劫陰郎がメンテナンスするわけではないのだ。次にやってくるのが箸にも棒にもかからぬようなクズかもしれないと思うからこそ、そんな発言が出てくるのだろう。そしてその （ クズがやってくる ） 可能性はきわめて高いのがこの業界なのだ．．．しかし、しかしである。

　自営業の陰郎は自分の腕だけを頼りにして仕事をしている。そんな仕事人に対して 「 初心者にでもわかるように作れ 」 というのがどれほど侮辱を感じさせるものか、そういう考えは浮かばないのだろうか？　気難しい職人気質の大工に向かって、施主が 「 私のような素人にも修繕できるように家を作ってください 」 なんて言ったらどうなると思う？　さっさと荷物をまとめて帰ってしまうだろう。陰郎もそんな気持ちになる （ さすがに帰りはしないが ）。初心者にもわかるように作らせたければ初心者にやらせればいいだろう！．．．というわけだ。

　こんなエントリを書くに至るほど陰郎が 「 誰にでも 」 という言明を嫌うのは、その背後にこの業界の現状を暗黙に是認する諦めを見るからだ。業界に初心者がいるのはいつだって当然としても、きちんとした教育を受けてプロになっていくのが本筋というものだ。いつまでも初心者でいてもらっては困る。我々は少なくともプロとして仕事をするのだから。しかし、教育という点ではこの業界は本当にお粗末なもので、そこらじゅうに無駄に年齢だけ重ねたようなクズがたくさんいる。しかし、そのような現状を簡単に諦めてしまっていいのだろうか？　諦めてしまえばそれ以上の進歩はない。「 誰にでも 」 は、そんな諦めの表れなのだ。陰郎は自分がプロとして仕事を続けていくためにも、そのような諦めを許すわけにはいかない．．．かくして、陰郎はいわゆる 「 お上 」 に対して言挙げをせざるを得なくなるのだ。

投稿者 kagelow : 22:55 | コメント (0)

2006年01月06日

商業言語に四苦八苦

　昼間の仕事の話。まぁなんと言うか、因果応報．．．かな。実は、陰郎は 12月の末頃から Java の仕事をしているのだ。そう、Java 言語。以前あんなことを書いたあの商業言語だ。正直仕事でまともに Java を書いたのは初めてだけれども、いや苦しい苦しい。４割くらいは自分の不慣れさのせいとしても、残りの６割くらいはその言語仕様に感じる違和感のせい。それでも使っているのが Java 1.5 なのでまだましなようだ。

　しかし太ったねぇ Java 。 「 シンプルで純粋なオブジェクト指向 」 が売りなんじゃなかったっけ？　総称のシンタクスなんて C++ の真似としか思えないし、実行時解決に傾きすぎてかえって使うのが不安だ。Sun は C++ を散々批判しているくせに、いろんなところで C++ の真似をしている。そして臆面もなく 「 Bjarne Stroustrup が C 言語との互換性にこだわる必要がなければ設計していたであろう言語 」 などと言って Java を宣伝するのだ。そう言うことは Stroustrup 氏自身が言わなければ意味がないだろうに。（ Bjarne Stroustrup 氏は C++ 言語の設計者 ）

　今回はツールという位置づけの仕事なのでまぁいいけれども、これをメインストリームに据える気にはとてもなれない。特に自分の技術者としての未来をともにする言語に選ぶなんてもってのほかである。いい加減なものを作って誇大広告で売り歩く連中というのは、見切りをつければ客もろとも全部捨て去ってしまうものだ。Java 言語がそうならないと言えるだろうか。Sun の誰かさんは、「 Java は２年以内に C++ を完全に殺す 」 と言っていたそうじゃないか。それから何年経ったのか知らないが、当時の誇大広告およびその結果について Sun の釈明を聞いてみたいものだ。他の人達がどう思うかはしらないが、少なくとも陰郎にはそんな連中が作って売るものの未来は信用できない。自分が想像する Java の未来は、ある日駅のゴミ箱に突っ込まれている姿だ （ ちょっと願望もまじっている ）。

投稿者 kagelow : 22:22 | コメント (0) | トラックバック

2006年01月05日

そうなるに至った経緯

　個人的な開発でもそうだし、仕事でもそうだ。半年、一年という単位で昔のことを調べなければならないことがある。「 今、どうなっているか 」 は簡単だ。現状を調べればいい。しかし、「 何故そうなるに至ったか、その経緯は？ 」 という問いに現状は答えてくれない。それは歴史であり、現状はその歴史の積み重ねではあるものの、現状それ自体は歴史を語ってはくれない。

　何度も何度も、そんな経験を繰り返す。だから、陰郎は長期にわたる仕事では必ず 「 作業記録 」 をつけるようにしている。何をやったかだけでなく、何故そのような選択をしたか。どんなことで悩んだか。何を量りにかけたか．．．そんなことを、敢えて感情を必要以上に交えて書き込む。歴史はそこに書き込まれるのだ。自分の歴史でもあり、作品の歴史でもある。作品そのものが語らぬものはそこに残しておくのだ。そうすれば、歴史を常に手元に置いておける。そして、作品そのものに歴史を書かずにすむ。だから陰郎のソースコードには過去のコメントアウトされたコードや冗長な説明書きは一切ない。

　今なら weblog のような自動化されたツールを使うのもよかったかもしれない。しかし、陰郎がこのようなことをはじめたのは 2002 年頃からだ。そのころは weblog のようなツールは知らなかった。だから最初は HTML を直書きするところから始めた。今でもほとんど直書きなのだが、文書全体の構造やリンク関係を管理する部分は自分で作成したツールを使用している。そして、Microsoft HTMLHelp Workshop というツールを使用して HTML Help 形式のファイルを作成する。こうすれば単体で全文検索をかけることも簡単にできる。ある意味で、これが陰郎にとってもっとも重要な道具かもしれない。

　2006年の活動を開始するに当たって、８ヶ月ほど放置したプロジェクトをなんとかしようと考えている。まずはそのプロジェクトの作業記録を読み返すところから始めるのだ。といっても記録をつけてある期間だけでも１年以上ある．．．しかし、これを読み直せば自分の頭はこのプロジェクトを放置する前の状態に戻れるだろう。人間は ── 少なくとも陰郎は ── すべてのことを記憶していることはできない。忘れたり、歪んだりするのだ。記録をつけることは大切である。書いてあれば、少なくとも思い出すことはできるだろう。いろいろなことに手をつけ、中断したり再開したりする場合は特に大切である。そんなことを痛切に感じたのでこんなエントリを書いてみた。

投稿者 kagelow : 12:50 | コメント (0)

2006年01月04日

2006年の抱負

　2005年の総括と重複する部分があるのだが、一応今年の抱負を書いて自分を追い込んでおこうと思う。

　１、今年は Palmware 以外の開発も復活させる。

　２、既存 Palmware のバージョンアップ案件に対応する。

　３、もう少し人間らしく生きる。

　．．．まぁこんなところか。新規 Palmware 開発案件がないことにお気づきだろうか？　別に作らないとは言っていない。というより、他の事をやると明言しておかないと新規 Palmware 開発ばかりをやってしまいそうなのだ。だからこそ敢えてそれは外し、他のことを挙げたような次第。

　さて、頑張るぞ．．．

投稿者 kagelow : 12:36 | コメント (0) | トラックバック

2005年12月09日

余裕なきレース

　陰郎は昔から長距離走が苦手だった。高校の頃は陸上部だったのだが、明らかな短距離向きの体躯にもかかわらず走り高跳びを専攻（？）したため、さんざんな結果を残したものだ。自分の身長くらいまでは跳べたが、それは誰でも練習すればできるもの （ いやマジで ）。長距離走に至っては悲惨なもので、思い出しただけでも冷や汗が出る。ま、人間向き・不向きというものがあるのは事実。これも人生と思ってあきらめるしかない。

　なんでそんな昔話をしたかというと、陰郎の今の開発スタイルがまさに 「 短距離走 」 みたいだからだ。長く一定したランニングができない。息を止めて一気にカタをつける。そのときに体内（脳内？）にある全てを注ぎ込むわけだ。どうやら運動能力的な特性は開発スタイルにも反映されるらしい。

　ところが、Palmware を作り始めてからというもの、走っている最中に次のレースが決まったりするからツラい。走り終えたら、少し休んで息を整え、すぐに走り出す。人間が消耗する一方だ。それ以外のことがなんにもできない。まぁそれでもやめられないから 「 開発バカ 」 なんだな。最近は陰郎のことを 「 職人 」 と読んでくださる方もいる。陰郎にとっては最高の褒め言葉だ。燃え尽きるまで走ってみようじゃないか。

　いなあもさんがボイスブログ 「 道の途中で～On the Way～ 」 をスタートされた。おめでとうございます。きっと日記と同じようなクールだけど暖かな語りを聞かせてくれるのだろう。陰郎は昨今のボイスブログブームには完全に置いてきぼりを喰った人間なので、余裕のあるときしか聞けない （ SD カードの中にはダウンロードした皆さんのボイスブログが溜まる一方．．． ） けれども、いつだって草葉の陰から応援しています。

投稿者 kagelow : 12:35 | コメント (0)

2005年11月10日

ソフトウェア開発者の限界

　この文章は、先月末の東ラのオフ会が終わった直後から書き始めていたものだ。常々感じていた、ソフトウェア開発者の限界というものについて書いてみた。

　ソフトウェア開発者の仕事というものは、潜在ユーザーに対する訴求力に欠けるという宿命があると思う。普通は、ハードありきで使えるソフトを探すだろう。Palm デバイスのユーザーでない人が、Palmware を先に見るということは考えにくい。もちろんそういう人もいるだろうが、どちらかといえば少数派だろう。「 このソフトが使えるハードは？　Palm だけ？　じゃあ Palm を買う！ 」 というレベルに達するソフトウェアというのは相当なものだ。そうでなければ、ソフトウェアというものは 「 すでにそのハードウェアを持っている人 」 向けのものとして通常は認識されると考える。

　つまりだ。その意味において、ソフトウェア （ とその開発者 ） というのは、本質的な限界を抱えていることになる。確かにコンピュータというものはソフトウェアが無ければただのハコだが、ソフトウェアだってそれを動かすハコがなければただのビット列なのである。そして、何よりも重要なことは、一般的な潜在ユーザーが最初に目にし、手にするのはハードウェアの方なのである。

　その意味で、潜在的なユーザーに対してなんらかのアクションを起こしたいと考えるとき、ソフトウェア開発者というのは 「 その現場から常に一歩隔たっている 」 。これは一般的な消費者ユーザーを考えるとき、残念だが本質的だ。このことは、Palm のような （ 少なくとも日本では ） 苦境におかれているプラットフォームでは、特に重要な意味を持つ。まず最初にユーザーに提示しなければならないのは、現実的な価格と手続きで入手できるデバイスであり、またその製品を目にし、手にすることができる機会なのだから。その意味では、潜在ユーザーに対して実際に手にすることのできるデバイスを勧める草の根的な努力をしている人たちの方がより現場に近い．．．

　こういった現状に対し、ソフトウェア開発者には一体何ができるだろうか？　特に国内に Palm デバイスを製造・販売するメーカーが存在しない今、ソフトウェア開発者にできることとはいったい何か？　残念ながら、「 直接的には 」 何もできないかもしれない。しかし、陰郎は悲観しているわけではない。間接的にでも、なにかできることはあるはずだ。

　以前にも書いたことだが、人間は自分の背丈以上のことはできない。頑張ったところでせいぜいがちょっとした背伸びくらいのものである。しかし、それは行動しないことの言い訳にはならない。陰郎はソフトウェア開発者だ。だから開発者の身の丈にあったことを頑張ろう。まずはできることを、できるだけ。

投稿者 kagelow : 11:45 | コメント (0) | トラックバック

2005年11月03日

すごろくで言えば 「 一回休み 」

　明日は仕事は休み。今日は仕事を早めに退けて．．．そう、これだけまとまった時間が取れればやることはひとつ。開発ですよ開発。帰り道の途中で食事も済ませ、20時には Palmware 開発端末の前に座っておりました。久々のコーディングランだ。気絶するまで行くぜ！　．．．とそこまでは調子が良かったんですけどね。そのあとは坂道を転がり落ちるどころか崖から滑落するくらいの凄惨な電脳絵巻が展開したのでした （ オオゲサな ）。

　ま、以前から問題となってはいたんですが、Palmware 開発用のＰＣの調子が悪かったんですね。アプリは結構頻繁にオチるし、ＯＳ自体も突然オチる。まるで電源が突然切れたかのようにぷつっと落ちて、何食わぬ顔をしてまたブートする．．．そんなことが１日に何度も発生する端末で RPNToGo は作られたわけですよ。そりゃもう大変だったんですから。ウィルスも疑いましたが検査結果は陰性 （ なんじゃそりゃ ）。ファイヤウォールもちゃんとしてるしねぇ．．．あとはハード障害くらいしか考えられんわ、と。

　で、ぼちぼち買い替えかなぁ、でも、その前にできる限り調べたいなぁ．．．と思っていたんです。で、今日も開発を始める早々 CodeWarrior がぷつっ．．．と行きました。しかも、再度 CodeWarrior を起動しても直後にアプリケーションエラーでオチる。仕方ない。PCを再起動．．．いやまてよ。やろうと思ったことがあったんだ。ブート時のメモリチェック。やってみたらこれがビンゴ。２本刺さってるメモリのうち、１本がイカレてました。それを抜いたら PC の 「 自動リセット病 」 が治りました！　ぱちぱち。

　しかし、幸運はここまで。OS は安定しましたが、CodeWarrior の 「 起動直後にオチる病 」 は治ってませんでした。仕方ない．．．CodeWarrior を再インストール．．．しても治らないんですよ。しかも、アンインストール -> インストールを何度か繰り返している間に、中途半端なとこでインストール自体が失敗し、アンインストールも再インストールもできなくなっちゃった。どうやらシステム系のファイルの一部が破損している模様 （ それしか考えられんというだけで根拠は無し ）。哀れ陰郎、この時点でもうぐだぐだです。もうどうにでもなりやがれと。こういうときに人間の底の浅さが見えるってもんですね （ 自分で言うなよ ）。

　というわけで０時現在、予備の新品ハードディスクの封を切り、呪いの言葉を呟きながら新しい環境を構築している最中です。この時点でもう４時間浪費しました。気分的には最悪です。多分、現在作成中の７作目 Palmware はこんな理不尽な怨念が詰まった作品になりそう （ なんてお茶目で意味深な前振り ）。

投稿者 kagelow : 00:00 | コメント (0)

2005年11月01日

VBGeneric Version 1.02.352.001

　この開発日記を読んでくださる皆さんは、ほとんどが Palm 関連で訪れてくださる方だと思っている。そのせいか、Palm 以外の話題を書くのは微妙に気が引けるのだが、もともとは陰郎の開発日記なので Palm の話題に限る理由は何もない。読んでも面白くない方もいるだろうとは思うが、ひとまず申し訳ない。

　先日、VBGeneric という陰郎の作品を１年半ぶりにバージョンアップするというエントリを書いた。修正はすぐなのだが、ドキュメントが面倒なため、正直なところ 11月の中旬までにできればいいかな．．．と思っていたのだが。

　なぜかできてしまいました．．．というわけで、VBGeneric version 1.02.352.001 のリリースであります。ぱちぱち。

　で、それだけで終るのもなんなので、この場を借りて VBGeneric の宣伝をさせていただきたいと思う。Visual Basic や VBA をお使いのそこのあなた。是非読んでみて欲しい。いつだったかのエントリでは小難しいことを書いたが、今回はもっとわかりやすくいこうと思う。

　単純に行こう。まずは配列だ。VBGeneric の配列である GVector は、要素の数を指定しなくても後ろにどんどん要素を追加できる。こんなふうに。

　Dim gv As New GVector

　Call gv.PushBack( 3 )
　Call gv.PushBack( 0 )
　Call gv.PushBack( 9 )
　Call gv.PushBack( 4 )
　Call gv.PushBack( 7 )

　この時点で要素は５つ。もちろん 100 でも 1000 でも、メモリを自動的に拡張してくれるナイスガイである。では、これをソートしてみよう。１行でことたりる。これで配列の中身は 0, 3, 4, 7, 9 と並ぶようになる。

　Call Algorithm.Sort( gv.First( ), gv.Last( ) )

　どうだろう？　たったこれだけでも便利だと思ってもらえるのではないだろうか？　あまり長々と書くのはよすが、あと１つだけ書かせて欲しい。なんと、文字列などを配列のインデックスのように使える魔法があるのだ。それは GMap というコンテナである。

　Dim gm As New GMap

　gm("sin") = 1989
　gm("wish") = 1991
　gm("closer") = 1994
　gm("wretched") = 1999

　こうしておいて、以下のようにすればメッセージボックスには 1994 と表示される。

　MsgBox gm("closer")

　実際にはこれは魔法でもなんでもない。これは連想配列というもので、キーとなる値（上の例では文字列）を使用して２分木構造を作成してデータを保持するものだ。バイナリサーチのイメージで検索をかけるため、そこそこ早い上に便利に使える。

　VBGeneric は、このようなデータ構造やアルゴリズムといったプログラム開発をサポートする部品を ActiveX DLL の形式で実装したクラスライブラリだ。もちろん上に紹介したのはそのごく一部である。全部を使いこなせばものすごいことができるが、上に書いた程度の使い方でも十分利用価値がある。C++ の標準ライブラリ （ の一部 ） を模倣して作られており、なんといってもフリーライブラリだ。作者の陰郎も非常に便利に使っている。自分で言うのもなんだが、１万円払っても使う価値はあると思う （ だからこそ自作したわけだが ）。

　興味をもたれた方がいたら、是非試してみていただきたい。使ってみてわからないことがあれば遠慮なく質問していただければ、多分大喜びで対応するだろう。この VBGeneric こそが陰郎のこの８年間の最大の （ そしてもっとも報われなかった ） 作品なのである。

投稿者 kagelow : 00:55 | コメント (0)

2005年10月30日

2005年の VBGeneric、そして怒り。

　一ヶ月ほど前に、VBGeneric という過去の作品について回顧録のようなエントリを書いた。そう、過去の作品。そう自分では思っていた。今後は手を入れるようなことも無いだろう。自分としても日常的な使用では満足しているし．．．と、本当に思っていた。

　しかし、メールが来たのだ。今日、改善要望のメールが。まずはその内容について紹介しておこう。

　STL の std::vector などでは、operator[] 演算子が提供されている。これによって、オブジェクトに対して、それがまるで配列であるかのようにインデックスを指定して要素を取り出せる。しかし、STL を模倣した VBGeneric は Visual Basic 上で動作するから演算子のオーバーロードはできようはずもない。そこで、VBGeneric の GVector などでは At プロパティを使用するようにしていた。こんな具合だ。

　Dim gv As New GVector

　Call gv.Resize( 3 )

　gv.At( 0 ) = 10
　gv.At( 1 ) = 9
　gv.At( 2 ) = 8

　しかし、演算子のオーバーロードはできなくても、部分的にそれを模倣することはできた。At プロパティをクラスの 「 既定のプロパティ 」 に設定してやれば、上記のコードは以下のように書ける。

　Dim gv As New GVector

　Call gv.Resize( 3 )

　gv( 0 ) = 10
　gv( 1 ) = 9
　gv( 2 ) = 8

　．．．というわけだ。この改善を施す対象は、コンテナクラスとしては GVector、GDeque、GMap の３つ。反復子としては RandomAccessIterator と GVector & GDeque の反復子。Visual Basic についてそれほど詳しくない陰郎は、「 既定のプロパティ 」 によってこういうふうにできることを知らなかった。これは是非とも取り入れるべき機能である。実は修正はもう済んでいる。あとはマニュアルを書き換えるだけだ。それに時間が少しかかるのだが。

　しかし、ここで陰郎は少々機嫌が悪いことを白状し、書きたくないことを書かなければならない。それは、この改善要望をくれた人のあまりの礼儀知らずに対してだ。その改善要望というのは陰郎のサイトのメールフォームから送られてきたものだが、まず第一に送信者のメールアドレスが無い。無くても送れるが、これでは返信ができないではないか。しかも、名前欄にはどう見ても恒久的に使用しているハンドルネームとは思われない名前を書いてきている。さらに、本文には VBGeneric という作品名すら書いておらず、本当に必要最低限のこと（ ＊＊してほしいです、とか ）しか書かれていない．．．要するに、ほとんど 「 便所の落書き 」 状態なのだ。

　おい！　REMOTE_HOST : ******-************-acca.tokyo.ocn.ne.jp から送ってきやがった hogeo さんとやらよ。見知らぬ人にモノを頼むときはな、最低限の礼儀ってモノをわきまえろよ。面と向かって人にモノを頼むときでも同じようにするのか？　ネット上ではいつでもどこでも hogeo なのか？　人を馬鹿にしたような名前で送ってきやがって。ネットだって public space だろうがよ。反省して改めなさい！

　まぁ、そんなワケだ。これで 「 個人的な要望 」 だったら完全無視するところだったが、内容自体は誰にとっても改善といえるもっともな修正なので、対応することにした．．．嗚呼、まだちょっと気分が悪い．．．

投稿者 kagelow : 03:00 | コメント (0) | トラックバック

2005年10月22日

復活に向け、筆を抑える。

　開発への復帰に向け、この日記に関して少しばかり筆を抑えようと考えている。

　RPNToGo のリリース以降、この日記にかける時間が急に増えた。それは、なんとなく開発の方向に向かなくなってしまった自分の中の 「 何か 」 が、この日記の方へと向かって行ったせいだと思う。しかしそれは次第に膨らみ、なんだか Palm にまつわる思想めいたことまで語り始めてしまった。まったく暑苦しい。なによりも問題なのは、開発に復帰したくてもできないくらい、この日記に時間がかかるようになりつつあることだ。

　僕はソフトウェア開発者だ。モノ書きでもなければ思想家でもない。僕が書くべきは文章ではなくソフトウェアプログラムだ。文章ばかり書いて開発作業ができないのは、それは怠慢というものだ。どちらかしか十分にやる時間を確保できないなら、僕はソフトウェアを書く。それが自分にできる貢献だと思っているし、そういう立場に自分を設定したからだ。

　もちろんこの日記がぱったりと更新されなくなるとか、そういうことにはならない。ただ、開発作業を圧迫しない程度の更新を心がけるようにする、というレベルで 「 筆を抑える 」 だけだ。断筆ではない。念のため。

（ しかし、なんで自分の書く文章はこんなに暑苦しいんだろう？ ）

投稿者 kagelow : 00:45 | コメント (0) | トラックバック

2005年10月19日

開発するは我にあり

　「 忌屋 陰郎 」 というのは、とあるフリーランスのＳＥからソフトウェア開発者という個性だけを抜きとって固めたキャラクターだった。「 だった 」 というのは、最近は Palm Handheld に対する愛情やその他の個性も混じってきているからだ。こんなふうに書くと、実際の人物と全然違うのかと思われるかもしれないが、実際に陰郎に会ったことのある方ならご存知の通り、陰郎とその中にいる人物にはそれほど違いはない。なぜなら、ソフトウェア開発を取り上げたら後には何も残らないような人間だからだ。そう書くとなんだか悲しいが。

　念のために書いておくが、「 陰郎 」 は 「 かげろう 」 と発音する。「 忌屋 」 も 「 いまわや 」 である。それ以外の読み方はお願いだからしないでほしい。また、この名前は固有名詞のつもりである。国語辞典に書いてある 「 忌屋 」 や 「 陰郎 」 という単語の意味とは関係ないことを特に強調しておきたい。

　話を戻す。要するに僕は 「 開発バカ 」 なのだろう。３度の飯よりもソフトウェア開発が好きだ。そして、どういうわけだか熱中しだすとそれこそ体を壊すほどやる。Palmware の開発を始めてからはその傾向に拍車がかかったようだ。開発期間が長くなると情熱を維持できない年齢になってしまったせいもあり、短期開発を心がけている。平行開発も基本的にしない。そして休憩など無意味だ。リリースまでは精神的に休めないため、休憩すると返って落ち着かず、罪悪感で気分が悪くなる。開発こそが、陰郎にとっての呼吸であり、生命活動なのだ。

　そんなふうにして、ずっと突っ走ってきた。何本かの Palmware もリリースできた。フルタイムで働く社会人としてはまぁいい方なのではないかと思う。視力か、手か、はたまた頭脳か、どれかがダメになるまではきっとこんな調子でやっていくのだろう．．．と思っていたのだが、どういうわけだか RPNToGo のリリース以降、体がいうことを聞かなくて困っている。次のネタもあるし、設計も始めている。しかし、何かおかしい。全身にアドレナリンが充満するような、あの感覚がやってこないのだ。

　PipeWorks と RPNToGo が少々キツかったから、疲れているのだろうか？　しかし、RPNToGo のリリースからもう２週間だ。それとも、早くも枯れ始めてしまったのだろうか？　しかし、まだ旗を下ろすわけにはいかない。しかし、本格的に動き出すまでにはもう少しだけ時間が必要かもしれない。自分でも情けないとは思うが、僕も年をとって少しばかり人間臭くなったのかもしれない。

投稿者 kagelow : 23:34 | コメント (0) | トラックバック

2005年10月07日

自分の足を撃ち抜くリスク

　最近忙しくてなかなか書けないので、またもやつまらないエントリを。

　C/C++ のキャストが危険だという意見がある。また、たとえば Java は多重継承が危険だからと言って多重継承をサポートしない。同様に Java はポインタも提供しない。だから Java は安全だと主張される。また、似たような理由を並べて Java は 「 純粋なオブジェクト指向言語 」 だという言い方もされる。

　安全か危険か、またオブジェクト指向として純粋か、という論点なら、まぁ同意しないこともない。しかし、あくまでプログラミング言語は道具だし、プロが使うのはプロの道具でなければならない。オブジェクト指向として純粋かどうかなど、それぞれの道具ができること・できないことに比べればどうだっていいことだ。僕に言わせれば Java などおもちゃのピストルである。本物のピストルが必要ない人、または本物を使いこなすことのできない人はおもちゃを使えばよい。プロってのはたとえ自分の足を撃ち抜く危険を孕んでいたとしても本物を使わなければならないことが多いのだ。プロにとっては、おもちゃは安全であってもいざというときに役に立たない。危険だ危険だと吹聴してまわる連中は、たいてい本物を使いこなせないか、またはおもちゃを売って金儲けをしたいのだろう。要するに Java を作って売った連中のことだ。

　別に僕は Java ユーザーに恨みがあるわけでもなんでもない。しかし、Java を売り歩いた連中の誇大広告と嘘八百には恨みがある。Java がオブジェクト指向の普及に貢献したことは確かだ。しかし、それ以上に Java はその宣伝によってオブジェクト指向を、さらにはプログラミングというものまでを貶めたのである．．．異論・反論大歓迎だ。ただしちゃんと理論武装してから来てくれ。

── 追記 ──

　読み返してみると少々誤解を招きそうなので補足しておくが、別に僕はおもちゃのピストルを否定するわけではない。僕だって本物を持ち出すに及ばぬ時はおもちゃを使う。僕が言いたいのは、時として危ない道具を使わなければならない局面があるということ、そして、「 このおもちゃさえあればもう本物を使う必要はありません 」 と吹聴した卑しい商売人たちのことなのだ。

投稿者 kagelow : 12:50 | コメント (2) | トラックバック

2005年09月25日

ポケットの中のカビ臭い狂気

　Palmware 開発を始める前、僕はプログラマ向けのライブラリ作成をメインに活動していた。といっても、それで飯を食っていたとか、その世界で名を上げたとかいうわけではない。まぁそれでも自分なりに真剣にやってはいたわけだ。あの頃の自分の無謀さは、思い返しただけでも果てしない気持ちになる。回顧録臭いけれども、ちょっとだけ、昔を思い出しながら書いてみよう。

　一部の皆さんはご存知のとおり、僕は C++ プログラマである。C 言語と同様、C++ にも標準ライブラリというものがある。1997 年（だっけ？）に ISO 標準が制定された C++ の標準ライブラリには、STL というものが含まれている。これは Standard Template Library というもので、C++ のテンプレート機能を最大限に活用した恐るべきライブラリだ。STL には何種類ものコンテナ、イテレータ、アルゴリズム、ファンクタなどがテンプレートとして収められている。2001年頃に芽生えた僕の狂気は、この STL と（ ほぼ ）同等のクラスライブラリを、Visual Basic 向けの Active X DLL として実装することだった。

　それがどれくらい 「 イカレて 」 いたか、C++ と STL を知らない人に説明するのは正直言って難しい。だが、STL を褒め称える有名なこの言葉なら少しはわかってもらえるかもしれない。「 STL を使えば、C++ のソースコードが 100 分の１の長さになる 」。実際に使っている人間として証言しよう。この言葉は本当だ。ただし使いこなせれば、だが。僕は完全に使いこなせているわけではないから、100 分の１とまでは行かないが、まぁその半分というところだろうか。それでもとんでもなく短くなるのである。

　ひとつ例をあげよう。Visual Basic で考えていただきたい。テキストファイルを読み込み、各行の 3 ～ 8 バイト目をキーとしてファイル全体を昇順にソートし、別のテキストファイルに書き出したい。キーは重複することもあり得るが、キーが互いに等しいレコードに関しては元ファイルと同じ順番を保っていなければならない。そしてソートは挿入ソートのような時間のかかるバカソートであってはならない。ファイルに含まれる行数は事前に知ることはできない．．．さて、素の Visual Basic で書いたらこれが何行になるか想像してほしい。想像しただろうか。この処理を、僕の作成したライブラリを使って実装すると以下のようになる．．．

Public Sub SortFile(inFileName As String, outFileName As String)
　　Dim vec As New GVector
　　Call Algorithm.Copy(Iterators.FileReader(inFileName), _
　　　　　　　　　　　　 New FileReadIterator, _
　　　　　　　　　　　　 Iterators.BackInserter(vec))
　　Call Algorithm.StableSort(vec.First(), vec.Last(), _
　　　　　　　　　　　　　　　Functional.PtrFun2(AddressOf LineCompare))
　　Call Algorithm.Copy(vec.First(), vec.Last(), _
　　　　　　　　　　　　Iterators.FileWriter(outFileName))
End Sub

Private Function LineCompare(arg1 As Variant, arg2 As Variant, _
　　　　　　　　　　　　　　 Optional ret As Variant = Nothing) As Variant
　　ret = 0
　　If Mid(arg1, 3, 6) < Mid(arg2, 3, 6) Then
　　　　ret = 1
　　End If
　　LineCompare = ret
End Function

　これは実際に動作するコードだ。いきなりこのコードを理解してくれとは言わない。ただ、どのくらい短くなるかを体感してもらえればいいと思う。Visual Basic 向けの独自拡張も含んではいるが、STL プログラマならさほど苦労せずにこのコードを読めるだろう。

　最初にやろうと思った時、どこまで腹をくくっていたのか、今となっては正直疑問だ。STL を Visual Basic でも使えるようにしようなんてどうかしている。普通に考えれば、最後までやれるだろうか．．．という気持ちになるのが当たり前だ。しかし、そういうことを考えた記憶がない。結構いいかげんな気持ちで始めたのかもしれない。しかし、だからこそ始められたとも言える。

　まともに作業に取り掛かったのは多分 2002 年の秋頃だ。僕はSTLの仕様や実装を調べ、ひとつひとつ Visual Basic のクラスとして実装していった。最初のうちは楽しかった．．．そう、最初のうちは。しかし、その後の半年間は苦痛の連続だった。実装し、テストを書き、リファレンスを書く．．．ひたすらその作業を繰り返した。

　ま、苦労話は置いといて、2003/06/17 に Version 1.00.344 をリリース。最初は ￥3,000 のシェアウェアだったが、諸般の事情により 2004/03/06 発表の Version 1.01.349 よりフリーウェアになった。VBGeneric という名前。それが当時の僕の狂気の結晶だ。

　「 諸般の事情 」 というのは、要するにさっぱり売れなかったと言うことだ。理由はおそらく、1) VB プログラマには敷居が高すぎたこと、 2) クラスライブラリという性質上、レジストしなくても使えるようになっていたこと．．．だろう。実際問題、STL をマトモに使っている人で Visual Basic もやっている人がどれくらいいるか．．．あまりにもニッチに過ぎたのだ。そう考えれば納得のいく話ではある。それでもフリーウェア化して１年半が経つが、今確認すると Vector のサイトの人気順で８位になっている。そう考えると、結構ダウンロードしてくれる人はいるのかもしれない。それらの人々が皆使ってくれているかどうかはわからないけれど。

　http://www.vector.co.jp/vpack/filearea/winnt/prog/vb/index.html

　あの頃、Microsoft の .NET 開発環境向けにこのライブラリを書き直すという別の狂気があった。でも、いまだにそれはリリースされていない。実は、モノはもうほとんど出来上がっているのだ。しかし、リファレンスが書けていないし、最新の Visual ****.NET では似たようなことが言語レベルでサポートされるという噂も耳にした。.NET に対する興味は完全に失ってしまったので、そのあたりの情報はさっぱりウォッチしていない。自分が .NET を使うことがなければ、未完の .NET 対応版は永遠にお蔵入りだろう。僕は他にもいくつかの狂気を抱えている。自分が必要としていない狂気にかける時間は、残念ながら無い。

投稿者 kagelow : 17:30

2005年09月22日

TypeTacho 試作品

　職業は自称プログラマ。なぜだかインフラ周りとか色々やるので、本当に開発でお金を稼いでいるのか自分でも常々疑問ではある。しかし、やっぱりプログラマなのだ。キーボード大好きである。マウス撲滅結社東京支部代表である （ 今作った ）。Windows でエクスプローラを起動するだけでも [Ctrl]+[ESC] → R → explorer → [return] とタイプするくらいなのだ （ さぁやってごらん！ ）。職業的なスコープが狭いせいもあるが、自分のタイピングスピードはなかなかのもんだと自負している。しかし、ここ５年の自分を振り返ると、その速度は徐々に落ちてきている。そんなわけで、たまには Palmware 以外のソフトウェアの構想について少し。

　作ろうとしているのは、「 タイピングタコメーター 」 とでもいうものだ。起動しておくと、キーボードのタイピングをフックして打鍵速度を計り、表示してくれる。自動車のタコメーターに倣って、１分当たりの打鍵数という表示がいいな。あとは累積打鍵数や瞬間最大打鍵速度なんかが表示されるとうれしい。

　問題は、別のアプリがアクティブな時でも全てのキーボード入力をフックしなくてはならないということだ。これを、Win32 の世界では「 グローバルフック 」 というらしい。自作のフックを OS にインストールする場合、Win32 API の SetWindowsHookEx( ) という関数を使用することになるが、グローバルフックの場合、フック関数は DLL 内になければならない．．．

　ところで、DLL のコード内で（ 普通に ）大域変数を使用した場合、複数のプロセスがその DLL を共有したとしても大域変数はプロセスごとに割り当てられる。だから、DLL 内の大域変数ではプロセス間のデータの共有はできない。このグローバルフックの場合もやはりそうなのだろう．．．フック関数内部からメッセージを投げたりしなければならないため、フックの DLL はタコメーターアプリのウィンドウハンドルとフック自身のハンドルを知っていなければならない。そのため、DLL 内の大域変数は共有データとして指定されたセクションに置いてやらなければならないのだ。

　．．．というわけで、コア部分の用件は大体固まった。グローバルフック関数を収めた DLL とお試し実装の EXE を１つずつ。ZIP に固めたものをとりあえず置いておこう。

　　TypeTachoTest.zip ( 20KB )

　適当なところに展開し、TypeTachoTest.exe を実行すればよい。ちなみに Windows 95 & 98 では動作しない。動作するのは Windows NT 4.0 SP 3 以降である。また、OS に潜りこむようなアプリなので、大事な作業をしているときは使用しない方が良いと思う。

　これはまだ試作品なので、画面は以下のような適当実装だ。だが、ひとまずのところ知りたい情報は表示されるようになっている。画面下部のプログレスバーは、その時点での最高速度に対する、現在の速度の百分率を表示している。ちなみに、今日の最高速度は 780 hit/min である。瞬間最高速度で１秒当たり13回打鍵しているわけだな。

　　

　できれば、画面は自動車のタコメーターみたいにしたいなぁ．．．と思ったり、タスクマネージャの CPU 使用率履歴のような折れ線グラフも欲しいなぁ．．．と思ったりしている。しかし、内部の複雑なカラクリが大好きなかわりに表面的な画面周りがとても面倒臭く感じる性分なので、この先はどうなるかわからない。このアプリを面白いと思う方、ご意見を求む。

投稿者 kagelow : 16:37 | コメント (0)