日々のつぶやき(99/09/4〜)

1999/09/27

認識枠のマークアップの動作が、変だったのでちょっと手を入れるが、どうもうまくいかない。DrawSelf()(MFCのOnDraw()に相当)でちゃんと描画できるようにイメージ座標系で描画すると、OnClick()(OnLButtonDown()に相当)でマークアップを描画した時に位置がずれる。逆に、マウスクリックした時にちゃんと描画できるように、ポート座標系で描画すると、DrawSelf()でおかしくなる。どっちもPaintRect()を使っているんだけど、一体どっちの座標系を使うのが正解なのか、それとも別の座標系を使えばいいのか、さっぱり分からない。(x_x;;

結局、DrawSelf()の時にPaintRect()を呼び出す時にはイメージ座標系で、OnClick()からPaintRect()を呼び出す時にはポート座標系で、描画領域を渡すことにした。そしたら確かにうまくいったけど…、そんなのありかぁ?(?_?)

1999/09/20

文字認識エンジンで残っているのは表のマス目をちゃんと認識しているかという部分。色々前提条件やらがあって手間取る。さらに、MacでのMFCに相当するPowerPlantの理解が不足していた部分もあって、いい加減なコードになっていたので、それもある程度ちゃんと書き直す。書き直す過程で感じたのだが、メンバ関数が並んだジャンプテーブルにおけるC++の実装って、OOPの思想からするとなんか変な感じがする(本当だったらメンバ関数が上書きされたらジャンプテーブルもそれに従って変わってほしい)けど、まあMFCで使われているようなマクロを書く根性はないので妥協する。ま、書き終わって見ればそこそこキレイにかけているような気がした。JavaのFinal宣言みたいに、「上書き宣言拒否」みたいな宣言が書けるとか、クラス自体をFinal宣言(クラス継承を許さないという宣言)出来てしまえば、ちょっとは気が楽になるんだけど。

色々手間取ったが、何とか表のマス目をちゃんと認識できているようだ。これで認識エンジンに関しては、これ以上いじらなくても、「どんな環境に持っていっても大丈夫なソース」になったはずだ。やっとこれで「あとはがりがりUI/F部分を書くだけ」になった。まさかこんなに認識エンジン部分だけで苦戦するとは思わなかったが、まあ仕方がないかという気もする。ドキュメントない、ノウハウないから始めたんだもんな。(^_^;

1999/09/16(Thu)

文字認識エンジンのどこがおかしいのか、ちゃんと文字認識するWindows版と誤認識の多いMac版両方をトレース実行して、どこで違ってくるのかを調べるという地道な作業が続く。Mac(CodeWarrior)のトレース実行はCTRL-T、Windows(Visual C++)のトレース実行は、F11。変数を見るための操作も違う。2つの操作体系が頭の中でぐちゃぐちゃになって、訳がわかんなくなってくる。(;_;)

もっとも本当に1行1行トレースしたわけじゃなくて(^_^;、要所要所だけをトレースしたり、動作が怪しい関数の前後でデータを比較してみたり…、ということを続けたんだけど、何か調べた範囲ではちゃんと動いているように思える。ちょっと考える時間が欲しかったので全部のモジュールをビルドして、もう一度トレース。あれ?今度はちゃんとWindows版と同じような文字認識をしている。本当の理由は分からないのだが、多分出力モジュールがbugありのままリンクされていたんだろう。確かにあのモジュールにはバグがあって直したような気がした。で、そのままそのモジュールをビルドするのを忘れていたという…。ウキィー。

1999/09/14(Tue)

東京の営業所で仕様に関するミーティングを行う。その会議ではMacOS7.x系統をサポートするかということが問題になった。正直言えばMacOS7.xなんてのはサポートOSに含めたくない。大体Appleが作っているプログラミングに関するドキュメントでもMacOS7.x、MacOS8.x、MacOS X(Ten)はそれぞれ別のカテゴリーになっていることからもそれぞれ別のOSだと思ったほうがいいと考えている。Windowsで言ったら、Win31、Win32s、Win32みたいな区分けだと思う。

もっともMacOS Xはクライアントとしてはまだβ版すら世の中に出ていないんで、当面MacOS7.x、MacOS8.xだけ考えればいいんだけど、AppleはMacOS X以外はなるべく早く捨てたいと考えているらしいし、Appleの考えでは、MacOS Xでは「注意して書けば、MacOS8.x以降とMacOS Xをソースコンパチにできる」(ただし、それにはまだβバージョンのCarbonライブラリがちゃんと完成するということが前提)で充分だと考えているようで、MacOS7.xでのソースコンパチは考慮されない。Apple Japanが開催したCarbonセミナーでもCarbonライブラリで実装されない部分は、積極的に書き直したほうがいいみたいなことを言っていたし。MacOS X Clientが出ると捨てなきゃいけないような寿命の短いモジュール(プログラムのパーツ)を書く気にはとてもなれないよなぁ。

うちの会社は基本的にMacの事は分かんないので「この件に関しては要調査」ということで、ある程度区切りが付いた。営業からは「もう少し仕様を削って早く出せないか?」ということを言われたが、削るって言ってもこれ以上削ったら「認識結果がデタラメなOCRソフト」とか、「認識結果を修正できないOCRソフト」になっちゃうぞ。(^_^;

会議の時間はかなり短かったので、後は営業所で空いているiMacをいじって遊んでいた。で、いじってみると、なんか妙にWWWアクセスが遅い。おかしいなぁと思って調べ初めて見たら、(WWWアクセスが遅いのとは関係がないんだけど)OS、Internet Explorer、Netscape Navigator、Acrobat Reader、QuickTime…etc,etcと軒並みバージョンが古い。「全然いじっていないんだったら1ヶ月レンタルで、開発の方に貸してほしいなぁ」と言ったら当然のことながら、やんわりと断られた。(^_^;とりあえず、そのiMacの責任者にバージョンアップの許可をとって、諸々のソフトウェアをバージョンアップする。東京営業所は松本にあるプロキシーサーバーを使っていて、松本-東京営業所の回線が細いもんだから、転送するのにえらく時間がかかる。イライライライラ。Windowsマシンもセキュリティーホールがあるブラウザとか平気でそのまんまだもんなぁ。(-_-;;

で、私の近くに座っていたKさんとUさん(松本本社勤務)の会話。

Kさん

「いつも東京営業所はメールを見るだけでもすごく時間がかかるんだよね。でも、今日はなんだか本当に遅いね。」

Uさん

「本当にいらいらするよね。やっぱり回線を太くしたほうがいいんじゃない?」

お、いいぞ、いいぞ。もっとも回線を太くする前に、すべてが松本経由ってのを何とかしたほうがいいと思うんだけど。(^_^;ちなみに、この日「なんだか本当に遅い」原因は大体見当がついていたけど(^_^;、やっぱり社内インフラを整えるためには上の人が不自由をしてもらわないとさくさく進まないと思ったので、心を鬼にしてそのままにしておいた。(爆)

1999/09/08(Wed)

今日は、まず文字認識モジュールがアクセスする単語辞書のアクセスルーチンに手を入れた。この単語辞書へのアクセスルーチンがまともに動けば、認識文字がかなりまともになるはず。で、早速読みはじめる。

で、読みはじめるとやっぱり1つの関数が結構長い。短いものでも200行程度はありそう。(^_^;同じようなことを繰り返し書いている部分もあったので、目についた場所はどんどん関数に分割していく。そうでもしないと200行以上もある関数なんて、ちょっとデータの流れを追っていくだけでライフワークになりかねない。(^_^;書き直したおかげで、ソースは読みやすくなって、おまけにソースファイル自体も小さくなったんだけど、後でこの修正をWindows版に反映させるとなったら大変だな。(^_^;もっともこの部分、Windows版は次のバージョンで大幅に修正が入るらしいから、要らない心配かもしれないし、大体その作業をやるのはOさんで私じゃないから、「これでいいのだ〜」←無責任(^_^;

で、最初は辞書を読み込むモジュールだけ手を入れればいいはずと楽観視していたんだけれど、辞書内の単語を表すレコードの中に可変長メンバーが2つあるので、単純に構造体の入出力みたいには行かないことが分かった。(x_x; こうなったら実際に読み出された単語レコードが認識モジュール内のどこで使われているか全部調べあげて、どこでEndian問題があるアクセスをしているか探すしかない。認識モジュールってソースファイルにして10万行近くあるんだぞ。なんか気の遠くなるような作業だなぁ…。

今年の私の予定としては、日程的に見ても、Macにかかりっきり。で、ほぼ同時進行で進んでいるWindows版のコードは新人のS''さんに引き継いでもらうことになっている。(これでWindows版に戻る目が完全になくなったなぁ。)S''さんには今まで私が抱えていたモジュールに加えて、PDFへの出力が新規モジュールとなる。以前に私が新規に起こしたExcel形式はVBAストリーム周辺とかのドキュメントがなかったので、その部分を解析するのが大変だったが、PDF形式は基本的にはPostScriptなのでかなり楽じゃないかと思う。以下、そのS''さんとの会話。

vyama

「PDはバイナリファイルだから、窓の杜とかVectorとかを探して自分の手に馴染むバイナリファイルエディタを探してね。」

S''さん

「バイナリファイルエディタって何ですか?そもそもバイナリファイルってなんですか?」

ここでちょっと頭がくらっと来たが、まあ新人で日も浅いことだし、こんなこともあるだろう。これが新人じゃなかったら「勉強不足!」と少しくらい怒っているふりをするところなんだけど。(^_^;

vyama

「え〜とね、例えばExcelのファイルをテキストエディタで開いてごらん。」

S''さん

「はい、開きました。」

vyama

「ほら、なんか変な風に表示されるだろ。こんな風に、普通のファイルにはテキストエディタじゃ表示できなかったり入力が出来ないデータが含まれているんだ。大雑把に言えば、それがバイナリファイル。で、バイナリファイルは普通のテキストエディタじゃ編集できないから、そんなデータを表示したり、編集したりするために特別の編集ツールが必要なんだ。それがバイナリファイルエディタ。」

S''さん

「なるほど。」

vyama

「ほら、このバイナリファイルエディタで、さっきのExcelのファイルを開くとファイルの中が16進表記でどんな風になっているか分かるんだ。で、こんな風にするとこの部分を変えられるだろう?こうやって、自分の作ったプログラムが出力したバイナリファイルが、どこがおかしくて、どこを直すといいのかを調べるんだよ。」

S''さん

「分かりました。じゃ、PDFファイルを開いてみると…。なるほどね。でもこれじゃデータ構造とかを追いかけるのってすごく大変じゃないですか。そういうデータ構造までちゃんと表示してくれるバイナリーエディタってないんですか?」

vyama

「…それはあんたが作るんだよ。」

S''さん

「…」

だ、大丈夫かぁ。(^_^;まあ、私が引き渡すコードは、私が引き渡されたコードよりは格段に分かりやすくなっているし、ソースコードは半分程度(2.5万行弱)にまで小さくなっているので、お手並み拝見といったところか。私が新人の時は15万行近くのアセンブラのソースをいきなり渡されたんだもんな。(^_^;

もう一人の新人Iさん。この人は入社してからコンピュータを本格的にいじりはじめた、プログラムを作ることは入社するまで全くやったことがないという人で、文系学部の出身。プログラミングなんてのは文系・理系は関係ないとは言われているが、理系学部だったらどこかでコンピュータ関連の単位があるはずで、プログラミングに関して全く白紙ということはまずないと思っていい。ところが、この人の場合、プログラムをするということが入社するまで全くなかったらしい。まあ、研修を受けたとはいえ、白紙状態から5ヶ月くらいの訓練じゃたかが知れている。今後の成長待ちかな。

で、Iさんには社内で認識結果の評価ツールを作ってもらうことになった。これだったら、多少使い勝手が悪くても構わない。また、その評価ツール自体はアルゴリズム的にちょっとファジーな所があって、上司のNさんから提示された最終的なアルゴリズムに求められる仕様に関しては、どう実現していいのか分からないでいる。(^_^;その意味では自分でアルゴリズムを考えるという意味で、Iさんにはいい訓練になるだろう。大雑把な機能仕様をNさんから聞いて、それをもうちょっとブレークダウンして、Iさんに渡してある。で、その経過があるのと、パーティションが隣ということもあって、プログラムで分からないところとか、仕様で分からないを時々質問に来る。

return TRUE;