台湾からの取引相手とのミーティングが突発的に入る。会議が嫌いなのに朝一番で予定外の会議が入ってちょっと御機嫌斜め。会議内容は今度取引相手が新しい製品の企画をするから、日本市場での代理店的な役割への打診だった。2つ紹介されたのだが、1つは「まずムリ目」。(^_^;もう1つは、うちの会社でやるのはうまくいかないだろうが、別の販路を探せばオオバケする製品だと感じた。実際、話を聞いて「とりあえず、個人的に買うからいつリリースなのか教えて」と言ったら、「いや、企画段階で…」と逃げられる始末。実際、思わず買いたくなるような商品だった。まあ今のところ企画の段階だから、どうなるかという腹の探り合いみたいな所はあるのだが。ただし具体的にどんな製品かはヒ・ミ・ツ。(^_^;
サブマシンの調子が悪い。Windows95をインストールし直したら、今度はCD-ROMドライブを認識しなくなってしまった。おまけにHDドライバはMS-DOS互換モードで動いていると表示されている。CD-ROMをリアルモードドライバで動かしたりして、だましだましインストール作業を続けていくが、VC/C++5.0だけはリアルモードドライバじゃインストールできないとメッセージが出てしまう。なんとかCD-ROMドライバをプロテクトモードで動かそうと、IRQがぶつかっているんじゃないかと思って調べてみたが全然効果なし。
CD-ROMドライブの開発元の日立の北米ページを調べてみたら、「Windows95のプロテクトモードドライバーは提供しない。時々Windows95がCD-ROMを認識しないことがあるけれど、その時にはCD-ROMをプライマリーIDEのHDの後につなげるとうまくいくことがあるからやってみてほしい。」という情報を得た。不具合があると分かっているんだったら、なんとかしてくれよ。(-_-;試しに「認識されなかったらこのプログラムを試してくれ」というヤツを試してみたのだが、そのプログラムもCD-ROMの認識に失敗して、それ以上先に進めない。バッカヤロ〜。ちなみに日本ページにはドライバの情報どころか、その製品に関するめぼしい情報も探せなかった。そんな訳で、日立は私の中では多いに株を下げる。
あきらめて、Windows95を上書きインストール。そうしたらCD-ROMドライバをちゃんと認識してくれるようになったのだが、今度はシャットダウンが終わりまで行かなくなってしまった。「Windowsを終了しています」という例の雲をバックにした画面までは行くのだが、そこから待てど暮らせどリセットがかからない。
状況からして、この調子じゃマシンが不安定なままだから、バックアップを取ったあと、フォーマットから始めたほうがいいだろうな、と結論が出た所で今日のお仕事は終わり。こんな状況だから、本来やるべきはずのHTML出力プログラムのコーディングが進むはずもなく(^_^;、5つあるうちの比較的小さなファイル1つを何とかコンパイルできるようにするのが精一杯。もっとも作業の中心はいらない関数を削除して、RTF出力プログラムで作ったソースを流用できるようにするのが主な作業。100行程度しかコーディングしていないんじゃないのか?時間もないので困ったことだ。←ともうほとんど他人事。(^_^;
ちょっと前から深夜残業についての制限がきつくなって、申請が繁雑になったので、ノリノリでコーディングしていても「早く帰りなさい」などと水を差されることがあって嫌になってくるという話を聞く。実は私もそれは感じていて、深夜残業の申請は16:00頃までに出してくれなんて言われても、22:00位にならないとその時の気分なんて分からないから出しようがない。手続きもいちいち上司印までもらわなくちゃいけないから、もうそれだけでげんなりしてくるし、本当に忙しい時にはその申請手続きをすると考えるだけで気が滅入ってくる。組合として監視するのはいいんだけど、管理までされちゃ、たまらないよなぁという気がする。
私の会社は、極端にコアタイムの短いフレックス勤務なので、私の場合、大抵11:00以降に出社という重役出勤をした後、20:00位に帰るのが通常のペース(で、その後は残業になる)になっている。で、ノっている時とノっていない時の落差が激しいので(^_^;、18:00位で完全に嫌気が差して帰りたい時もあれば、翌日1:00くらいまで仕事をしていても全然平気ということもある。まあそんなデタラメな仕事ぶりでも1月くらいのトータルで見ると大体1日8時間強働くことになってつじつまが合うのだけれど、22:00で仕事を止めないといけないとなると、そうも言っていられなくなる。ま、もちろんすごいわがままだというのは分かっているんだけれど、今までそれでやってきたんだから今更急にペースを変えるわけにもいかないし。困ったものである。
帰宅したら、fjのフリーマーケットで購入したK6-200Mhzが届いていた。駄目もとで早速、メインマシンのCPUを交換する。今更K6-200Mhzなのだが、私のマシンのマザーボードはK6-200Mhzまでにしかちゃんと対応していないらしいので、これ以上を望むとなったらマザーボードやケースを全部買い揃えないといけない。まあ、今のところMMXがない以外は自宅マシンの性能には満足していたから、今度のMMX対応CPUが入手できたことの意味はかなりある。早速、メインマシンに装着してみる。
マザーボードのメーカーのページにアクセスしてみてディップスイッチの設定を確認したあと、早速K6を差してみて動作確認を行う。おお、ちゃんとBIOSがK6を認識しているぞ、と思ったのも束の間、そこからブートが進まない。おかしいよなぁ、いつもはここからCD-ROMとHDDの認識に移るんだけど…と思って電源を切ってからマザーボードに目を落としてみたら、プライマリIDEのコネクタが外れていた。(^_^;そういえばCPUの装着に邪魔だと思って、いったん外したんだっけ。これじゃあOSがブートしないよな。(^_^;
で、IDEのケーブルを取りつけて、もう一度ブート。ところが今度もスタートアップの雲をバックにしたイメージファイルは表示されるものの、途中でこけた。あれ?CPUの差し方が甘かったのかな?と思ってCPUに手を触れたらメチャメチャ熱い。どうやら熱暴走らしい。(^_^;テストだと思ってクーラーをつけていなかったんだけど、クーラーなしだとこんなに熱くなるものだとは知らなかった。(^_^;この熱でチップが壊れてしまったんじゃないかと心配したが、常温程度まで冷めるのを待ってから、クーラーを取りつけ動かしてみると、今度は何事もなかったようにちゃんとブートした。もっと何かトラブルがあるかと覚悟していたのだが、予想外にあっけなく済んでしまった。おお、これでこれからはMMX機能を要求するソフトも買えるぞ。(^_^;
166Mhz->200Mhz程度の速度向上は体感としてそれほど感じなかった。もっとも私は166Mhzでもそんなに重たくない処理しか自宅ではしていないから当然か。時間が出来たら、じっくり評価するようにしよう。まずはMAMEからかな。クスクス。(^_^;
たまたまよった本屋でStroustrup氏の書いた「プログラミング言語C++第3版」(ISBN4-7561-1895-X)を入手したので、最近は「More Effective C++」(ISBN4-7561-1853-4)と合わせて読んでいる。でも分厚いだけに、前者は読むのが大変そう。後者は参考になるところが多いにあるんだけど、前者はとにかく分厚いだけにそれだけで圧倒されてしまいそう。ただ、ざっと見てそんなに読みにくいとは感じなかった。とりあえず現状である程度使っている人を対象にしている感じはあるけれど、比較的読みやすいんじゃないかと思う。
まあ、K&R位はきちんと読めるくらいの実力が無ければ演習問題を解くのはきついだろうし、初心者のためのC++解説書って訳じゃないから覚悟して読むように。読んで分からなかった?じゃあ私の仲間だ。(^_^;「cout << foo」とか出てきたら(C++の他の入門書を読んでいるならともかく)、普通のCプログラマーは「ドキッ」とするよね。(^_^;まあ私は別のC++入門書を読んでいたのでインパクトは少なかったけど。(^_^;
会社でいつものようにWWW巡回ソフトを使って、いつも行くベージのチェックをしていたら、一般保護エラーが発生した。プログラムの強制終了を選択しても、さらに一般保護エラーが出てきてしまって、どうしようもなくなってしまう。シャットダウンも出来ないので、究極の対処法「電源ボタンを押す」を試して、再起動をしてみたら今度はスタートアッププログラムを起動している途中で止まってしまうようになった。CTRL+ALT+DELも効かないのでやっぱり「電源ボタンを押す」で対処。その後、セーフモードで起動したり、MS-DOSモードで起動したりして何とか修復しようとしたのだが、それが裏目に出て今度はWindows95がブートする時に出てくる「Startup Windows95...」なんてメッセージも出なくなってしまう。乱暴な再起動を繰り返しているうちにブートに必要なファイルを壊してしまったらしい。
仕方がないのでWindowsを再インストール。まずは上書きインストール。ところがこれが途中で一般保護エラーを起こして死んでしまう。実はこのマシンは、ハードディスクの容量が少ないせいで、ディスク圧縮ツールを使っていた。その圧縮ディスクの中には出来れば救ってあげたいデータもあったのだが、もうこうなれば止むを得まい。まあ、最低限救いたいファイルだけは圧縮しておかなかったので、それが救い。更に言えば開発に使っているメインマシンじゃなかったし。
そんな訳で、素直に回収をあきらめて、C:\WINDOWS以下を全部削除してから再インストール。ところが久しぶりにWindowsの再インストールなんてやったもんだから、色々トラブルに巻き込まれる。最初はネットワークカードをどうやって認識させていいのか分からなかった。机の中をごそごそやってみると、そのマシンを買った時の発注書が出てきたので、それで型番を確認してみると、どうやらWindows95で自動認識できない型らしい。Windows98だったら自動認識できるのかもしれないが、Widnows98はサービスパックが出るまで待つと決めていたので試してみる気さえ起こらなかった。更に机の中をごそごそやっていると、それっぽいドライバーディスクを見つけたので、それで解決。他にもインストールの途中で一般保護エラーが出てしまったりして、結局やり直しというのが何回かあった。やれやれ。いろいろ手間取ってしまって、今日はコーディングどころではなくなってしまった。まあ、全然やらなかった訳じゃないけれど、セットアップ作業が気になってコーディング作業に身がはいらない。(^_^;
で、懲りずにディスク圧縮ツールをインストールする。(^_^;まあボリュームファイルだけは残しておいたので、手作業でレジストリとか書き換えてあげればあきらめていたファイルのいくつかでも復活するかもしれないという淡い期待をした訳だ。ところが、その期待はものの見事に裏切られた。インストールして、リブートをしたら、「別に生き返らなくてもいいや」どころか「とっくの昔に削除したはずだったのにぃ」というファイルまで全部復活してしまった。(^_^;ディスク圧縮ツールが監視していないファイル操作をしたおかげ(デスクトップとかお気に入りフォルダーのバックアップ作業分)で、「お前、俺の知らない間に変なことやっただろう?まあ、なんとかつじつま合わせはするから、次からあんまり無茶はしないでくれよな」という警告は受けたけれども、手動で消したC:\WINDOWS以下のファイル以外は見事に復活してくれていた。偉いぞ、賢いぞ、DiskXII98。(^_^;まあ、レジストリを消しちゃったのでアプリケーションのインストールし直しはしなくちゃいけないのだが、それは明日以降使うツールから徐々にインストールしていけばいい。
再びリッジレーサー4をやる。グランプリは取れたのだがどうやら1つの車メーカーあたり20種類くらいのバリエーションがあるらしいので、それを揃えてみようという訳だ。やっているうちに気がついたのだが、どうやら予選を良い成績で通過すればするほど後半になってコンピュータカーが強くなるような感じがする。もっともノーマルモードでは壁にぶつからないように気をつけて走っていれば何とかグランプリは取れるんじゃないかと思う。
19台揃えて、後の1台はどうやって手に入れるのかなぁと思っていたら、メインメニューでExtra Stageという項目がいつの間にか追加されていて、それを選んだらロケットカーが相手に出てきた。これは相当速く走りそうだな、と思ったのでこっちの手持ちで一番速い300Km/hまで出る車を選んでスタート。ところが、そのコースはどう考えても200Km/h位で走るコースなので、最大スピードが大きすぎて、壁にがんがんぶつかってしまう。(T_T)
まあ、このレースはあきらめてもう一度やろうと思い直し、ギアを1段落としてコースを回る。前のリッジレーサーでは、通称「ゴキブリ」「アゲハ」と言われたシークレットカーは基本性能が非常に高く、その車に勝つためには「周回ノーミス + バックミラーを眺めてシークレットカーをブロック」という(私にとっては)かなり難しいことが要求されたので、いつ後ろからカゼのようにロケットカーが現れて、追い抜いていくんだろうなぁと期待して待っていた。が、いつまでたってもロケットカーがバックミラーに出て来ない。おかしいなぁと思っているうちにゴールインしてロケットカーをゲット。どうやら今回のスペシャルカーは最高速度が速いだけで、基本性能に違いはないらしい。(^_^;つまり私が壁にぶつかっていた以上にあっちも曲がり角に差しかかるたびにどかんどかんと壁にぶつかっていたようだ。(^_^;
試しにさっそくロケットカーで超高速コースを走ってみたが、速いことは速いんだが、速すぎて結構壁にぶつかる。(^_^;なるほどねぇ。
R4に熱中しすぎてK1を見そこねた。シクシク。
金曜日に買っておいたリッジレーサー4をやる。ノーマルモードでゲームを初めてからいきなりグランプリ優勝できてしまったのでびっくり。私のゲームの腕は折り紙つきで下手くそな事を考えれば、メチャメチャに「ヌルイ」ゲームだ。
そこでハードモードでゲームをしてみると、今度はめちゃめちゃ難しい。コンピュータカーが早くて全然追いつけない。う〜む、精進しなくては。(^_^;
Excel出力プログラムのデバッグ。データ構造の変換部分は、変換部分を結構大雑把にしか作っていなかったし、片方のデータ構造は自分の作ったものなんだけど、そんなもの何ヶ月も前に作ったデータ構造なんて細かい所までいちいち憶えているわけはないので、おそるおそる書いていく。とはいってもスケジュールが押し迫ってきているので、「たまにまともに動作することがある(^_^;」程度の出来、いや「まずまともに動かない」程度の出来だろうが、とにかくモジュールを書かなくてはいけない。と言う訳で、これも大急ぎで書きまくる。
で、早速「動くことがある」程度の出来くらいか試してみると、これが死屍累々の出来で(^_^;、結局デバッグしただけで終ってしまった。まあ、それでも何とか「動くことがある」程度までには完成度を上げることができて何より。(^_^;まあ後で集中して改良・デバグをすることになるんだけれどね。
グループ旅行でお気に入りの人を見つけた。一緒にぼ〜と風景を眺めているのも(私には珍しく)苦にならないし、話をしても(私には珍しく)つらくならない。みんなでカードゲームに興ずるのもよし(私はこの手の勝負事では楽しむというよりも勝負に辛くなる傾向がある)という至福の時間。旅行が終ってグループが解散したあともその人との馬鹿話が楽しい。ところが話をしている途中で「ブニャ〜」という奇声とともに左足に激痛が走る。
はっと気がついてみると、どうやら寝ている最中に足元に寝ていた猫にしたたかにキックを食らわせてしまったらしく(^_^;、さかんに左足を引っかいている。あわてて左足を引っ込めて猫にトドメの岩山両斬破(というのが北斗の技であるらしい(^_^;)をお見舞いしたが、秘孔が人間と猫では違うせいだろう。「ひでぶ」などとは言わないで、部屋の外に逃げだした。残るは血のにじんだ左足。いつもは試験とか締め切りとかに追われているろくでもない夢しか見ないので、久々にしっぽりとした夢を見れたというのに…。ぶち壊しやがって。夢が覚めたら既にお気に入りの人の顔さえ憶えていないという…。こんなことだったらせめて名前でも聞いておくんだった。いや、夢の中だから名前を聞いた所でどうなるってもんじゃないんですけど。(^_^;;
出社して、昨日気がついた大穴部分のコードを眺めてみる。冷静に自分の書いたコードを読み直してみると、状況はかなり深刻で、関係する部分をかなり書き直さなくちゃいけないことはすぐに分かった。しかもどうやって修正していいのかがしらふの頭で考えてもよく分からない。う〜む、とたっぷり3分(5分だったかも)考えたあとで、比較的単純な方法を思いついたので、その方針に従って関係する所、全部で40行ほどを全部書き直した。WRIプログラムのためだけの部分なんてもう400行近くしか残っていないはず(もとは3000行近くあったんだけど(^_^;、RTFで書いた部分でライブラリ化出来そうな所はそっちにまとめてしまったので、残ったのが結局400行程度。)なので、デバッグが終了したと思った時から更に全体の10%近くを書き直したことになる。これはちょっと反省しなくちゃいけないな。(^_^;
プログラマーにも色々タイプがあると思う。「熟考黙慮、どんなに小さなモジュールでも、関数仕様やサブモジュール図をきちんと書いてプログラムする」なんてタイプが理想なんだろうが、私の場合はかなり違う。(^_^;実は1000行位で済むだろうなと思っても全体への影響が大きくて慎重に熟考黙慮したこともあるが、基本的にはお気楽極楽。アマチュアでもここまで気軽にやらないよなという感じで私の場合にはやっている。
題して「脊髄プログラマ」(^_^;。まず、与えられた問題のうち、自分の知らない所があるか調べる。今まで使っていなかったけど、今回初めて使いそうなAPI群は実際にサンプルプログラムを作ってみて動作を確かめてみる。で、OSの条件を確かめた上で、おおざっぱなデータの流れを頭に浮かべてみる。それが出来たら、まずは流通させるデータで必須のものを決めて、それに見合った構造体とか事実上データメンバーしかないクラスを作る。(必須のものから算出可能なものは加えない。)その後、細かい関数仕様とかを作らずに、いきなりソースファイルに「こんなことをここでやりたい」という感じのコメントとかダミーの関数をが〜と書く。(やりたい事が確実にみえていて、10行程度で済みそうならその場で書いてしまうが)で、そのダミー関数の中もコメントとダミー関数の呼出しをがしがし書いていくことでプログラムのデッサンをする。大体データの流れが、これでいいかな?と思ったら、後はコメントに対応する処理とか関数とかを書いたり、ダミー関数の中身を作っていくという感じ。
まあ、普通はそんなプログラミングの態度じゃいけないんだと教科書的には教えているんだろうけど、数千行程度の独立したモジュールで関数の細部仕様までいちいち書いていたら、仕事を消化できないというのも現実だし、一応古典的なトップダウンのプログラム手法にはなっていて、それはそれで妥協点なんじゃないかな?と思う。実はこういう書き方をすれば200〜300行もある関数を書こうなんて気にならないと思うのだが、まあそれは書き手によるのかもしれない。実際、前の部署で初めて本格的に仕事でVBを使った時には、VBのことをよく分かっていないせいで、なが〜い(100行超。でも200行までは行かなかったはず)関数を書いたこともあったし。(^_^;
まあ、40行ほどならさっと書いてさっとデバッグできる程度な訳で、普通にプログラムを書いていて、本当の最上部の構造さえ理に適ったことをしていれば、下っ端のほうで相当まずいコードを書いても何とか極小で被害が済むんだよね、というのが今回の教訓。
今日の残りはExcelファイルの出力プログラムの作成に当てる。この部分は今回のバージョンアッププロジェクトで新規に起こすプログラムで、7月くらいにあれこれいじっていたのがその布石だったのだが、そのモジュールを実戦投入しようというわけである。モジュール自体は出来上がっていて、後は親モジュールから渡されたデータ構造をExcel出力が要求するデータ構造に変換するだけ。前者は今までずっといじってきたものだし、後者も自分自身で書いたものだから、大したことはないと思っていた。とりあえずデータ構造の変換関数をダミー関数にしておいてコンパイルしてみるが、7月に書いたプログラムなんて当然のことながら憶えているはずもなく、やってみると出るわ出るわのコンパイルエラー。(^_^;ま、これはほとんどがヘッダーファイルのインクルードし忘れだったけど。
それ以外にも、7月に書いた時にはポインタ配列はCTypedPtrArrayを使っていたのだが、RTFとかのモジュールは STL、C標準関数、Win32 APIだけで作っていたので、MFCライブラリ関数(正確にはMFCテンプレートライブラリ)のCTypedPtrArrayじゃなくてvector<void *>で代用しようとしたのだが、当然ながらvoid *からオブジェクトへのポインタの変換はそのままじゃエラーになるので、これまたコンパイルエラーの山。(^_^;仕方がないのでこれだけはMFCを使うようにプロジェクトを変更した。CTypedPtrArray相当のクラスもSTLだけで作れそうだとは思ったけど、STLをちゃんと勉強していないせいで(^_^;、どれだけ書けるのか怪しいものだったし、時間があれば勉強も含めて書いただろうけど今は締め切りが押し詰まっているからなぁという訳でMFCプロジェクトに変更した。本当はどんなに時間がなくてもこういうところはきっちり勉強がてら書いていったほうがいいんだけどね。(-_-;←反省 とりあえずコンパイルエラーだけは何とかして、今日は帰宅。明日変換関数とデバッグをしよう。
fj.*のフリーマーケットでK-6 200MhzのCPUを6000円で売ってくれるという記事があったので早速連絡してみる。同じ値段での申し込みがあるので、高い方に決めますという感じのReplyが入ったので、1000円追加の7000円で再度申し込む。私の使っているメインマシンのマザーボードはおんぼろなので200Mhzまでしか対応していなくて、200Mhzはもう市場に出回っていないから是非とも欲しいということも書き添えたら、そういう事情でしたら…、ということで7000円で商談成立。最新CPUとCPU単独のコスト対性能で比べたらかなり高い値段だけど、最新CPUを買うとなると、CPU、DIMM、対応ビデオボード、マザーボード、ATXケースと一通り買わなくちゃいけないので、それに比べたら安い買い物だ。今まではK5-166だったからついでにMMXもついてくる。これでMMX対応のソフトウェアもダイジョウV。←死語。売り手から決定の連絡が来た時にはラッキ〜と大喜びしてしまった。7000円で天にも昇るような幸せになれるってのもチープな話だが、まあ、チープな話で大喜びしても人に迷惑かける訳じゃないし。(^_^;
数理研究会という偏微分方程式の勉強会という変な会(^_^;から忘年会のお誘いがあった。また、高校時代の棋道部OB会からも新年会の連絡が届く。とりあえず両方ともOKの返事を出す。これで大体年末の予定が埋まりそうだなぁ。R4をやる暇がぁ〜。←おい、仕事はどうした。(^_^;
WRI形式への新規出力は昨日の時点で一段落したのだが、実はまだ追加出力をコーディングしないといけない。どんな処理をやっているのかなぁと思ってソースファイルを眺めてみたらやっぱり、新規出力プログラムのソースファイルをコピーして、関数名の頭にAppendみたいなキーワードをつけて、ちょこちょこっと書き直したもののようだ。読んでいて目眩いがしてくる。こんなものには付き合っていられないと思って、読まずに全面破棄。(^_^;昨日の作業でWRIファイルのデータ構造は大体把握していたので、それほど苦労しなかった。100行ほど書いてコーディングは終了。元のプログラムは追加出力だけで1000行近くあったから、今日もマイナスの進捗。(^_^;
コーディングが一段落した所で、昨日今日の作業のデバッグ(ところで日本語として正しいのはデバグなんだろうか、デバッグなんだろうか?bugのことをバッグとは言わないよなぁ。)WRIファイルのデータ構造仕様書をしっかり読みきっていなかったせいで、結構ぼろぼろな出力結果になってしまい、WordPadがテキストファイルだと勘違いしたり、誰も開いていないのに「別プロセスでファイルが開かれている」なんていうエラーが返ってきたりとさんざんだったが、何とかWordPadで読めるようになった。何とか読めることを確認したら気が抜けてしまってさっさと帰宅。
家に帰ってから、テーブルが入った場合のフォント情報の処理に大穴があって、まともに出力できない場合があることに気がついて青くなる。これが出荷後だったらえらいこっちゃで、青くなるくらいじゃ済まないんだけれど(^_^;、幸いα前なので、大したことはない。だ〜れも気がつかないうちに明日直してしまおうと思ったが、どうすれば直せるかなぁと考えてみたが良いアイデアが浮かばない…。明日しらふでもう一度考え直してみよう。(^_^;
RTF出力のほうが一段落したので、今度はWRI形式の出力に取り掛かる。HTML出力のほうが複雑でそっちのほうを取り掛かった方がいいかも知れないが、そのような諸々の出力プログラムでソースを共有できる所はやってしまおうと決めていた。そうすると、1万行以上あるようなHTML出力プログラムでいきなりやるよりも、3000行程度のWRIプログラムで共有する方が、ソースの共有の作業は易しい。WRIでソースを共有した作業の結果をHTMLでも生かせると信じてとりあえずやるしかない。まあそういったソースの共有化(というか実質ライブラリ化だけど)をすることを意識して、RTF出力プログラムで苦労した分が全然生かせなかったんだったら、今まで何をやっていたんだということになる。
今日の作業分では、RTF出力の時に作ったモデルを一部拡張したが、何とかそのモデルに逸脱しない範囲で拡張できた。今後はそのモデルに従って各種形式の出力プログラムを作っていく積もりなのだが、第一弾としては、当面の(上司に内緒の個人的な)計画としてはそこそこうまく行ったのかな?と思う。
実はWin3.1時代のWRI形式なんてのは既に「ほとんど死んでいる」フォーマットで、実際Windows95のワードパットではWRI形式でセーブしてもRTF形式でセーブされる。よっぽどRTF出力へのショートカットで済まそうと思ったのだが、サポートしているドキュメント形式をバージョンアップで減らすわけにもいかないだろうと思って、修正コーディングを開始。もっとも修正といってもほとんど書き直すつもりの修正ではあるのだが。(^_^;
このプログラムも前任者の「クセ」で、相当ひどいプログラムになっている。さすがにもう真面目に読むのがつらくなってきていたし、残り時間が少なくなっていたこともあって、RTF出力プログラムと共用できるだろうな、というところはバシバシ削って、RTFプログラムのソース部分を共有するようにした。削った部分は状況分析部分なのだが、もちろんその部分に関しては、RTF出力プログラムのほうが詳細に状況を分析しているというのは見切った上でやっている…つもり。(^_^;まあ、どうにもならない何てことにはならないだろう。とりあえず今日は700行ほど書き直して、削除したのが1300行ほど。削除可能なところがあと1000行程度。ひ〜、今日もマイナスの生産量じゃぁ。(^_^;全体が3000行ほどのプログラムなのに何故こんなに削除しなくちゃいけない所が多いんだろうなぁ。(sigh)
RTF出力プログラム。ひたすらデバッグと調整。今日はテーブル部分に手を入れる。最初テーブルをRTFで出力させて、それをMS-Word98で読み込ませたらMS-Word98が沈黙してしまう。何度CTRL + ALT + DELETE を押して、MS-Wordを殺したことか。(^_^;こっちは指定の不足分はあるにせよ、RTFの文法にはキチンと従っているのだから、せめて「解釈できないRTFです」くらいのメッセージを出して欲しい。大体、Microsoft自身が「RTFで意図しないエレメントとか変な指定が出てきたら、そういうのは無視して、なんとか表示できるようにすべきだ」なんて書いているくせに(MSDNのRTFに関する記述)、本家本元のMicrosoftのMS-Wordがそれを実践できていないようじゃ、RTFで文書を書くなんて意味がなくなってくるような気がする。RTF文法のパーサーなんてそんなに技術的に高度なものだとも思えないのだが(困ったらbisonとか使ってもいいし(^_^;)、それさえ出来ないのに「わが社の提唱したRTFが流通の基本だ」なんて言ってほしくないぞ。(^_^;
まあ、いくら文法的に正しいといっても、MS-Wordが受け入れてくれないんだったらどうしようもない訳で(^_^;、何とかMS-Word98がちゃんと読めるようにエレメントを補足した。
ワールドアトラス。解けない謎を追いかけてひたすらやりまくる。どうしても新しい提督が現れない。いい加減最初からやり直そうかなぁ。(^_^;しかしそれにしても時間がない…。
比較的安かったので、買ってはおいたのだがそのまま手をつけずに置いた"バーチャファイターKids"。鉄拳2とかをやって「これはもうコマンド入力についていけない」と思って最近はこの手のゲームは敬遠していたのだが、値段が安ければ買ってみる気にもなる。(^_^;ところがやっぱりコマンド入力タイプのゲームはなかなか難しい。また二等身のキャラクタなので間合いの取り方が分からん。(^_^;難しいよなぁ、最近のゲーム。←お前が下手なだけ。(^_^;
買ってはあったのだが、なかなか進められなかったワールドアトラス。なんとか世界地図を完成させる。しかし、それにしても解けない謎が多いんだよなぁ。(^_^;登場しない提督も二人いるみたいだし。一体どうすれば解けるんだろう。
上司のNさんが台湾から持ち帰ったβ2をざっとインストールしてみて動かしてみる。すると懸案事項だった文字化けがきれいさっぱりなくなっている。おかしいと思って調べてみると、β1からβ2でアップデートされたファイルはリソースを抱えているDLL1つだけという話だったのだが、実はほとんどのDLL, EXEが更新されていた。いい加減だとは思っていたけれど、プログラムのアップデート状況も把握できなくてよく仕事が出来るよなぁ。(-_-;
RTF出力プログラム。昨日、文字領域出力部分のオーソドックスな流れの部分のデバグ/書き直しが正しいかの確認作業を終らせていたので、今日はそれ以外の色々なオプションをつけた場合の動作を確かめてみた。まあ、いつもは200行ほど書いては動作を確認しつつ、コーディングを続けていくのだが、今回は一気に5000行ほど書いて、それから動作を確かめるのだから相当大きな間違いがあるのが当たり前だと考えていたが、思ったより致命的なバグは少なくて済んだように思う。もっとも今日一日はデバグでつぶれてしまったが、OEMの制定作業がズ〜と先に伸びたおかげで、1日2日くらいは余計にデバグしていても全然問題なくなっているので、大手を振ってデバグが出来る。(^_^;
デバグしているうちに「これって元のプログラムにあったから入れていたけど、どう見てもいい加減な動作しかしないから切っちゃおう」とか「おっと元のプログラムのこの部分の意味が分からなかったから捨てちゃったけど、実はこんな意味があったんだ。」などという再発見があったりして、これはこれで楽しかったりする。(^_^;今日捨てちゃった部分には、RTFの段組み機能を使っている部分もあったけど、それを使ってうまく元文書を再現しているわけでもなさそうだったので、ばっさり切ってしまった。
今日一番にはまったのがフォントの大きさ。\fsエレメントで指定するのだが、何故かフォントのサイズが1412(1/2ポイント単位だから706ポイントを指定することになる。)などという指定をしてしまう。座標計算が入り組んでいるので、どうせそこのどこかで計算間違いをしているんだろうと考えて、片っ端から座標計算のロジックを追いかけて計算結果を検算してみる。ところが1時間ほど追いかけてみたのだが、どうしても思ったような計算間違いが見つからないから、訳が分かんない。
で、ふと出力すべき段落の内容を調べてみると、「12日」で始まる文字列だということが分かった。あ、そうか。\fs14 (フォントの1/2ポイント単位での大きさ)の後、デリミタを入れないと「\fs1412日」になって馬鹿でかいフォントサイズになっちゃうんだ。気がついてみれば馬鹿馬鹿しい限りの間違いである。RTF-Jって、例えば「あ」なんてのは「\'82\'A0」なんて書かなくちゃいけないので、ソースを見ようという気が起こらないから分かんないんだ。(^_^;←単なる言い訳。読者の皆さんはRTFライターを書く機会があったらこんなバカな間違いをしてはいけません。(^_^;でも、私自身にたようなプログラムを書く機会があったら同じ間違いをやっちゃうだろうな。(^_^;
Macの師匠Sさんとの馬鹿話。サポートのSさんについての話題。私はもっぱら聞き役。
S師匠「Sさんは近々某所に家を建てるらしいよ。そこからはさすがに通えないからうちの会社を辞めることになるかもね。」
vyama「新築ですか。うらやましいですね。金持ちは違うなぁ。ただ、今まで助けてもらったことも多かった分、抜けるとなったら仕事にでかい穴が空きますね。」
S師匠「まあ、遅かれ早かれ誰か補充されるだろうけどね。今度来る人は若くて可愛くておとなしい感じの女の子がいいなぁ。」
そんな事を言って、サポートのSさんの飛び蹴りかパンチがS師匠に飛んでも知らないぞ。まあ、そうなったらそうなったでまた日記のネタにしてしまおう。(^_^;
ひどくならないうちに休んだのが効いて、ちょっと熱っぽい程度で翌日を迎える。台湾出張から帰ったNさんとミーティング。本当だったら今月の10日には制定するはずだったOEMが、最低8日まで待たないとヘルプファイルが出来上がらず、マニュアルは更に遅れるということで、制定が3月始めまでずれ込むことになった。そんなの8日にようやくヘルプが出来上がるような状態じゃ、10日に制定なんて絶対無理だってことは明らかなんだから、その前に「間に合いません、ごめんなさい」と言って来てくれるとこっちも色々スケジュールが立てやすくなるのに。
セットアップに至っては今年中に出来上がるかも分からない状況だという。一体どうして何だと聞いたら、担当者が感謝祭のため長期休暇を取っていて作業できないんだという。これにはあきれはててモノが言えなかった。制定日をまたいで長期休暇を申請する奴も申請する奴だけど、それを許可するってもの信じがたいいい加減体質。突き合わされる方はたまらない。
もっとも、OEM先の制定予定が延びたおかげで、で別件のバージョンアップ作業に当面注意を集中できることになったし、工数も充分に確保できた。だからひとまず「超多忙」状態からは解放された訳で、予定していた年末の2日間の追加年休も消化できそうだし、、私としてはラッキー。v(^_^)
RTF出力プログラムのほうは文字領域出力の一番オーソドックスな場合の動作がちゃんとうまくいくか調べる。ここがちゃんとしていれば後の部分は必要に応じてエレメントを出し入れするだけなので、慎重にデバッグ。致命的な間違いとかも結構あって、一般保護エラーがバシバシ出たが、ちゃんと短い関数ごとに分けていったせいで勘違いの箇所はすぐに特定できた。これが、200行以上もあって変数が20個も30個も使っているような関数だとあちらを叩けばこちらからという感じでいつまでたっても怪しげなバグが取れなかっただろう。「プログラム書法」に書いてあった「駄目なプログラムをいじくり回すより作り直そう」というのを身をもって実感した。
体調不良で会社を休む。日記も休む。もっとも一日中寝ていたんで、書くことがないんだけど。(^_^;
出社直後に、昨日テストスタッフが報告してきたβ2プログラムのレポートを読んでみる。で、そのレポートを読んでみたのだが、翻訳上の問題はかなり改善されたものの、主要な機能に関する部分で文字化けしているという。その部分はβ1では問題がなかったはずだから、この部分に関してはβ2になって完成度が下がったということになる。ヘルプも来ない、インストールプログラムも来ない、プログラムの完成度は落ちているという状況なので、とうとう「プッツン」。
実際、スケジュールの遅れは事後通告だわ、主要な機能に文字化けがあるわで、まともに相手をしていられないような気分だった。そんな訳で、ひとしきり不具合について報告した後、「これを書いたら台湾でやっている会議が紛糾しそうだなぁ」とは感じていたが、もうこの時点ではっきり相手先の検査体制とかに不信感をいだいていたので、もう腹を括ってはっきりと言わせてもらった。(原文は英語なんだが、雰囲気はそのまんま)
とにかく、ヘルプもマニュアルもインストールプログラムもアップデートされていないんだったら、こんなもんβ2でもなんでもないじゃん。唯一更新された本体も文字が化け化けでβ1より後退している感じ。大体こんな文字化け部分を放っておくなんてお前ら送る前にテストやったのか?
もうほとんど「喧嘩を売っている」感じなのだが(^_^;、とりあえずぎりぎりこらえている部分があった。こらえていないんだったら「テストもしないのに送るんじゃない、バカ」で切り捨ている所である。送り返されたレポートでは、台湾の会社で用意した環境ではちゃんと日本語が表示されるらしい。一体どういう訳なんだ?(^_^;
まあ、さすがに(おおざっぱでも)テストなしにOEM提供先にプログラムを送るバカはいないと信じたかったし、実際上司のNさんの報告では向こうの環境ではちゃんと表示されているというんだけど…文字化けが再現しない環境が構築できない現状では何ともなぁ。リソースを調べたが、問題になりそうな所はなかったし、そうするとCreateFont()とかをつかってFontFaceを直接いじっている所があって問題が発生しているとしか考えられない。ま、どのみち提供元のテストでどのような結果が出ようとも、こっちのテストでパスしなければ意味がないので、とりあえず実務者レベルでそのバグのFixを継続することになったらしい。こんな、どこに文字化けがあるのか分からないバージョンを評価するのが、受け入れ側の仕事か?とも思うのだが、単なる検査だけじゃなくて、実は訳語や訳文が適切かなんてことも質問されているんだから、気分は監訳者(^_^;。で、私に「この訳語がど〜のこ〜の」とか言ってくるんだがTOEICの試験ぼろぼろ(正解率60%〜70%)、日本語ぼろぼろ(この日記を見ていれば分かるよね)が監訳者になる製品って一体…。(^_^;もっともその手の翻訳が難しい件は今のところ「とても難しい」と言って逃げているんだけど、いつかは決着させないとね。
実際の所、テストする立場の人間とテストされる側の人間の人間関係というのは微妙な所がある。プログラマーの私としては、ある程度目処がついたらテスターにテストしてもらいたい。が、テスターとしてはちょっと動かせば分かるような所をいちいち指摘しなくちゃいけないというのは「プログラマーは何を考えているんだ?」と言う気になってくる。大抵のテスターはじっと辛抱するんだけれど、私はもともとテスターじゃなくてプログラマーだから、気が短い。(^_^;まあ、逆に何をどうすればこうなって、この部分はきっとこの部分にエラーがあるはずだろうから、それを直せば…なんてことが見えてくるから、かえって自分がその修正を直接出来ないもどかしさや、実際に修正をしている人の「顔」がみえてこないみたいなのがあって、それでいらついている部分はかなりある。実際、そんな事を言ったらかなり人間関係を壊すだろうなということは分かっていたが、言わなければこっちが崩壊してしまいそう。もうどうにでもなれという感じ。
その後のスケジュール調整で、マスターの締切が大幅に伸びたらしい。もうdelayは許されないな。でも年末に予定されていた台湾行きのスケジュールが2月にずれこんだので、その意味ではラッキー。(^_^;これでしばらくはうちの課がかかえている製品のバージョンアップ作業に集中できる。やれやれ。
福岡にいた時のKさんからメールが届く。「お久しぶりです…(中略)…もうvyamaさんもパパになっているんでしょうか?」このメールを傍目で見ていたサポートのSさん曰く。「永久に彼女も出来そうにない奴に子供が出来る訳ないじゃん。」ある意味図星なのが悔しいが、フ〜ンだ(^_^;