日々のつぶやき(00/06/06〜)

2000/06/28(Wed)

普通のプログラミングでは「Aという機能を実現するには、まずそれをB、C、Dなどの適当な機能に分割して レイヤーAのレベルで、B、C、Dを適切な順番で制御する」というのが基本だ。(いわゆる構造化プログラミングの基礎)ところが、今回は、「BからCへの移行のタイミング」が外部からメッセージとして伝達されるというパターン。今日取り組んでいる部分は普通に組んでいてさえ頭が痛くなるような複雑な制御構造なのに、その制御構造をメッセージ伝達機能だけを使って実現しなきゃいけない。Windowsのようなお気軽なSendMessage()一発で話が済めば簡単だけど、MacOSの場合、代替えのAppleEventは自分自身にメッセージを伝えるにでさえも気の遠くなるような繁雑な作業が必要だ。あのAppleEventの複雑さを何とかコントロール出来る自身は今の私にはない。どうすればいいんだか…。スレッド分割しようにも、スレッド関連のライブラリのリファレンスが全然ないんじゃ手に負えそうにない。本当にMacOSって始末に負えないよな。(-_-)

フレームワーククラスライブラリの出来も簡単には手が出せないほどにひどい出来だというのがよく解った。画像を表示出来るような1次元のリストを表現するコントロールとかライブラリがないので、表を表現するライブラリを1 x n で使うことで疑似的に、1次元のリストを表現するクラスを実現していた。ところが、何故か列を削除した後、削除したはずの列がそのまま表示されている。必死になって数時間ドキュメントを読んだり、自分の書いたソースを読んだりしてバグの原因を探っていたのだが、ドキュメントとの整合性を見る限り、こちらに何も原因はない。なにせ、列を削除した後、表の全領域に対して再描画をかけているのは間違いないのだから。

半信半疑でライブラリのソースを読みはじめて、とんでもないことに気がついた。このライブラリにバグがあったのだ。この表の描画ルーチンは「セルの再描画するべき部分だけ再描画する」というコードになっていた。まあ妥当な方針だとは思うけど、じゃあセルがない部分、前回の描画ではセルがあったけど、今回の描画ではセルがなくなった部分はどうなるんだ?と更に深く読み直してみたら、「セルがなくなった部分に関しては何もしないで何が書かれていようがほったらかし。」つまり、列を削除する時には、いつでも、最後の列がどれだけの描画範囲を持っているか調べて、その部分を背景色で塗りつぶさないといけない訳だ。行を削除した時にも同様なことが起きる。普通、それくらいはライブラリの仕事だろ?これははっきりとライブラリのバグだと思う。

今回の場合は有り難いことにC++を利用しているのと、問題のあるメソッドがvirtual宣言されていたので、ある程度の工数をかければなんとかそのバグを回避出来るのは幸いだった。

しかし、これだけは言わせてもらおう。このクラスライブラリ、まずドキュメントをまともにしろ。使えそうなクラスに限ってドキュメントに言及されていない。で、定義されてはいるんだけど、デフォルトでまともに使えないクラスを何とかしてくれ。「出来て当たり前」の操作にやたらと前置き・後起きが必要だったりするのはうんざり。こんなクラスライブラリにつき合わされている開発者は悲劇以外の何者でもない。

話を元に戻して、表を操作する時には、行とか列とかを削除するなんてのは当たり前の動作だと思っていたし、実際そういうメンバも用意されているからそれを使ったまでなのだが、それを使うと削除した部分の再描画が必要になる。馬鹿馬鹿しい限り。その場合にその部分の再描画が必然だというのを解っていなかったんだろうか?テストをしなかったんだろうか?で、もっと分かんないのはこんな簡単なバグなのに今の今まで誰も指摘しなかったんだろうか?

もう1つ。アプリケーションmodal dialogを表示した時。そのダイアログを移動した時にアプリケーション側で再描画が必要な部分が再描画されないという問題が起こった。コードを追いかけてみると、ちゃんと再描画コードは実行されているようなのだが、実際には再描画されていない。訳が分かんない。まあ、こんな訳のわかんないモニタもどきのシステムこそがMacOSなんだろう。このくそったれOSを発明した奴は地獄に落ちろといいたい気分。

2000/06/24〜25

死んだようになって眠っていた。一日何時間眠っていたんだろう?幸いなことに、眠りから冷めた後、しばらく起きていたいと思うような悪夢を見ることは少なくなってきている。ひたすらひたすら眠る…。zzzz

2000/06/22(Thu)

この日もあんまり考えがまとまらずに別件を処理する。

テーブル内の罫線がうまく描画されない場合があるという障害に対処。ところが肝心要のテーブル内の罫線データの持ち方がWindows版とMac版で異なっていることを発見して愕然とする。

Mac版ではすべてのモジュールにおいて、単純に画像の左上角を基準に罫線の座標を格納していた。ところがWindows版だと、エンジンは左上角が基準の座標を使っているのだが、アプリケーション本体の中ではテーブルの左上角を基準としてモジュールが作られている。Macに移植する時には「何をやっているのかはよく分からないが、何か意味のあることをやっていると想像される関数」というのを沢山持ち込んだんだが、どうもその座標基準の取り方の違いでうまくいっていないということが分かった。もちろん、ちゃんと理解して持ち込まなきゃいけないのは分かっているんだけれど、ちゃんと理解しようとしたら数千行は丁寧に読まなきゃいけない。そんなことやってられないし、第一思わず読みたくなくなるようなソースだったんだよね。(1つの関数が数百行とかのパターン…)

おかげで今回一緒に作業している他の人に多大な迷惑をかけることになってしまった。このWindows版のへんてこな内部仕様は「1つの枠を移動する度に200個ほどのWORDデータを書き換えなきゃいけないから、罫線座標は相対座標にした」と説明を受けた。が、枠を移動しなきゃいけない場合と、枠を移動しないでそのまま認識する場合と、どちらが頻度が高いといえば圧倒的に後者。で、後者の場合にはいくつあるかもしれない全ての枠に対して、画像左隅座標→テーブル左隅座標の変換を行っている。まともに考えれば、枠を移動する度に高々200個ほどのデータを書き換えたほうがいいと思うんだが、この場合、どの道大した時間がかかる訳じゃないので、実は速度的にはどっちでも構わない。とすると、仕様を複雑にした分だけ損なんだよね…。前任者のコードとのしがらみもあるだろうけど、そんな部分は「書き直さないといけない」と乱暴に主張しておこう。実際私が今のチームに移ってから最初にやったことはそれだったし。(^_^;

ふと思い出したのは、「モジュールが腐っているのはそのモジュールを書き直せばすむが、データ構造が腐っているのは関係したモジュール全部の書き直し」という言葉。Windows版のソースは「なんでこう物事を複雑に考えられるんだろう?」というくらいデータ構造が入り組んでいる。このソースって局所的にもデータの取り扱いにしても「どうすれば読む側が苦労するように工夫出来るか?」と苦労したんじゃないかという思いさえする。実例は以下。

今回はちゃんとdebugしようと思ったのである程度深くまで読み進めた。で、読んで最初意味が分かんなかったけど、意味が分かってがっくりしたというコード。なお、変数名などは分かりやすいように書き換えてますし、本質的でない所は全部省いてます。さらに接頭子g_が付いているのはグローバル変数ということです。


	CPoint ptOffset(g_OldRect.left - g_NewRect.left, g_OldRect.top - g_NewRect.top);
	g_OldRect = g_NewRect;	//g_OldRect と g_NewRectの型は一緒

	RECT Temp1;
	//g_OldRectはRECT構造体ではないのでメンバーごとの代入が必要 注vyama
	Temp1.left = g_OldRect.left;
	Temp1.right = g_OldRect.right;
	Temp1.top = g_OldRect.top;
	Temp1.bottom = g_OldRect.bottom;
	//以下の操作はTemp1を使っての操作だがTemp1は変わらない
	...	//色々な処理
	g_OtherRectArray[i].left = Temp1.left - 1;
	g_OtherRectArray[i].right = Temp1.right - 1;
	g_OtherRectArray[i].top = Temp1.top - 3;
	g_OtherRectArray[i].bottom = Temp1.bottom - 3;
	//以下の操作はg_OtherRectArray[i]を使っての操作だがg_OtherRectArray[i]は変わらない
	...	//色々な処理
	RECT Temp2;
	Temp2.left = g_OtherRectArray[i] + 1;
	Temp2.right = g_OtherRectArray[i].right + 1;
	Temp2.top = g_OtherRectArray[i].top - 3
	Temp2.bottom = g_OtherRectArray[i].bottom - 3;

	CPoint Pt(Temp2.left, Temp2.top);
	Pt += ptOffset;
	//Ptを使った処理
	...

さて、Ptには何が入るでしょう?これじゃ「パズル」だ。(;_;)ちなみにこの「パズル」、Windows版のメンテナンス担当者(私なんかよりはずっと優秀)に少し前、「結局Ptには何が入るのか教えてくれ」と頼んだ時には間違った答えを返してきた。(^_^;まあ、「色々な処理」と書いてある所を省けばそんなに難しい問題じゃないけど、正解が分かった時にはひどくがっくりした。もっと分かりやすい書き方があるだろうがぁ。「言いたいことがあるんだったら分かりやすいように書け」というプログラミングの金言(もちろん、例外はあるけど)を知らないんじゃないだろうか?一人でやっているんだったらいいけれど、他の人も巻き込むんだったら、こんなコーディングスタイルは考え直したほうがいいぞ…、と出来ることなら8年位前の某氏に忠告してあげたい。ま、さすがに経験を積んだ今だったらこんなコーディングはしないだろうけどね。(^_^;;;;

2000/06/20(Wed)

次のモジュールにかからなきゃいけないのだが、次のモジュールを実現するような大まかなデッサンが頭の中でうまくまとまらないので、それを熟成させるために検査チームから上がってきた障害レポートで、自分の担当分の対処をする。

しかし、このレポート、内容がひどすぎる。いや、検査の人が悪いって言っているんじゃなくて、こんな障害を抱えたままで検査に出すかっていう程度には十分ひどいのがほとんど。これが別人だったら、「こんな障害を作り込んだ奴の顔が見てみたい」と書く所だろう。ちなみに最近私は顔を洗う時にも鏡はほとんど見ないようにしているので、このbugを作りこんだ奴の顔はあまり頻繁には拝んでいない。(^_^;;;;

2000/06/20(Tue)

昨日作ったプロトタイプをアプリケーション本体に組み込んでみた。エラーチェックやら何やらをやったのだが、3時頃にはアプリケーションツールバーに関する作業が全部終ってしまった。2週間かかるはずだったのが、実質1日半で終ってしまって嬉しい大誤算。(^_^;まあ、実装に色々汚い所はあるが、まだ全部の機能が実装されてもいないのに、来月の今頃には雑誌編集部にβバージョンを配ってレビューをしてもらわなきゃいけないというこの局面なのだ。だから「ある程度の汚さ」は許容して、短い期間で動くプログラムを完成させるほうが大切になってくる。後で時間があったらこの部分はもうちょっと何とかしよう。

次のモジュールに取り掛かるにはちょっと時間が足りない。出来上がった(とされる)所から検査チームに変な所を見つけてもらっているんだけれど、それがかなり溜まってきているので、それを読んでみる。しかし読んでみると…、いかに自分が書き飛ばしているかが分かって恥ずかしくなってくる。もっとも現時点でいつもの私のペース、つまり1つもジュールが出来上がったら(モノにも依るが)1時間くらいは仕様も含めてテスト・再検討・結合テストをしてみるというペースでやっていたら間に合いっこないのが分かっているので(^_^;、1つのモジュールが出来上がったら典型的なパターンだけ検査して終わりにしちゃっているので、止むを得ない所がある。だが、それにしても多いよなぁ。(^_^;←笑い事ではない。

プログラムの書き飛ばしに関しては、最近ではプログラム中のコメントもまともに書いていない。後で訳が分かんなくならなければいいが…。もっとも元のWindows版のソースなんて、数百行あるメソッドなのに役に立つコメントが全くなかったりしたし(^_^;、PowerPlantだってほとんどのクラスに関してドキュメントがなかったり、ひどい時にはドキュメント、ヘッダー、揚げ句の果てにソース中のコメントを読んでも何をするメソッドなのかさっぱり分かんなかったりする。私がコメントを書いていないのは大体エラー処理を含めて20行程度、本質部分は10行程度ののメソッドがほとんどなので、まあMacのアプリケーションのソースをメンテナンス出来る人だったら誰でもメンテナンスが出来る程度の酷さだろうと思っている。(^_^;;

今までC/C++で2次元以上の配列ってあまり使わないんで、


	CSomeClass (*pArray)[100] = new CSomeClass[50][100];
これが何故だか分かんないけれど、どうにも気色が悪いんだな。(^_^;頭の中のどこかでnewとmalloc()を同一視しているので、なんだか1次元のフラットなメモリ空間に無理やり階層構造を入れようとしているような感じがして…。

S''さんの書いたコードを少し読む。クラスのconst referenceを渡せばいいようなところで、値渡しをしていた。まあ、せいぜい10〜20バイトほどのちっちゃなクラスで、ポインタデータメンバーとかがないんで値渡しをしても悪くはないんだけれど…。まあ、最近「おっかない会社の先輩」になっているので、あんまりうるさく言わないことにしよう。(^_^;

2000/06/19(Mon)

土曜日、日曜日とやたらと眠りまくったので、眠りすぎみたいな感じがある。朝3時頃目が覚めてしまって、その後なかなか眠れずに、朝を迎え、1時間ほど早く会社に行く。同僚からは「今日は朝のミーティングに遅刻しませんでしたね。」と言われるが、まあ普段の行動が普段の行動だけにこちらも苦笑い。

今日からはアプリケーションツールバーに関するプロトタイプを作るつもりだった。プロトタイプを作る作業は作る前からかなり大変な作業になるだろうというのを予測していて、一応上司のはどう短く見積もっても2week位かかるでしょうと見積もりを出しておいたのだが、本心では1月位かけてもプロトタイプが出来るかどうか…と思っていた。とりあえず手元にあるサンプルを片っ端から試してみる。片っ端から試してみたが、結局今回の目的にはそぐわないようなサンプルだけだったので、がっくりして、「最初から書き直す」積もりで、何か役立つことがあるかもしれないと思って、クラスライブラリのソースを読み出した。ドキュメントがないからとりあえずソースを読むしかない。(;_;)

数時間ほどソースやらヘッダやらを引っ掻き回していたら、LBevelButtonクラスに作ろうとしたプロトタイプその物ずばりのようなメソッドがあったので、プロトタイプを作ってみたらあっという間に目的のプロトタイプが出来てしまった。ラッキ〜。(^_^;

2000/06/17(Sat)

午後起きて、近所のサウナ目当てに保養所に行く。大学時代頃はサウナって全然駄目だったけど、今はサウナが大好き。風呂から上がって、安いワインを買い、それを飲んだ。一本呑みきらないうちにぐっすり眠ってしまう。

2000/06/16(Fri)

前日までに、他のアプリケーションへのデータの転送モジュールのプロトタイプの中核がほぼ出来上がったので、これを本体に組み込む作業。プロトタイプを作っていた時にはいい加減だった(というか即値で書いていた)様々なエラー処理などを組み込むのに結構時間がかかる。

もっとも一番時間がかかったのは,以前に自分が書いたコードがえらくいい加減なせい。今日書いたコードは依然に書いたコードがちゃんと動くことが前提で書いていたのだが、その前提コードがいい加減なので、まあ、まともに動かないだろうなとは思っていたが、案の定まともに動かなかった。(^_^;(ま、現状それだけ追い込まれているということだ(^_^;)幸い例によって例による「デバッガで追っかけると『自分が馬鹿だと思い知らされるような愚かなバグ』とか『1つ違いのなんでコーディング段階で気がつかないの?馬鹿者!』級のバグ」がぼろぼろ出てくる。まあ、今回のプロジェクトはスケジュールの都合上、ある意味特殊意識して飛ばして書いている、言い替えれば最終出荷段階はともかく、経過での品質は犠牲にしている所があるからなぁ。検査泣かせの作り方ではある。検査の人には申し訳ない。(_ _;;

それでも思ったより順調に進んだ。今週やろうと思っていたノルマは(多少バグはあったとしても)かなり自分でも満足の幾四ごとが出来たんじゃないかと思って帰宅。

2000/06/15(Thu)

私の父親方の伝統(?)で、白い毛の犬とか猫には「シロ」という名前を付ける。私の家の本家には5代目くらいの「シロ」がいる。わが家にも12年前にもらわれてきた(父親が付き合いで押しつけられたというのが本当らしい。)飼い猫「シロ」がいる。

この猫、もう身体が弱ってきていて、食べ物も飲み物もろくに取ろうとしない、いつ死ぬか分からないような状態だった。数ヶ月前に獣医さんに看てもらった時に「次はもう老衰だからあきらめるように」と言われていたので、今回は家族で「相当具合が悪そうだけど、犬猫病院に連れていってもどれくらい持つか分からないし、前回もシロが犬猫病院に行くのをすごく嫌がったので、シロの好きなようにさせてあげよう」ということになっていた。

最近のシロのお気入りの場所は私の布団の上だったようで、ここ1ヶ月くらいは家に帰ると大体私の布団の上でまどろんでいたし、朝私が起きると、夜私が寝る前にいた枕元にいた。もっとも私が寝ている間にどこかに出かけているらしく、朝起きると、枕元が乾いた泥まみれにはなっていたが…、一体どこに行っていたのやら。

朝7:30頃、枕元で壁を引っかくような音がして目が覚めた。布団から身体を起こしてみると、シロの身体全部が布団からはみ出している。「やれやれ」と思いつつ、シロを枕の脇の「最近の指定席」に移す。これでいつもの通り、シロの寝息とともにもう1時間くらいは寝られるはずだ…と思った。が、シロはぐったりしているまま。いつもだったら移動させられた時には「なんて迷惑な」という顔をしてこっちに振り向くのに。その瞬間、シロが死にかけているんだと気がついた。

慌ててシロをシーツにくるんで抱きかかえながら、階段をかけおりて「シロが死にかかっている」と言った後、居間にシーツごとシロを降ろして、身体のあちこちをそっとなぜた。もうかすかにしか息をしていない。もう助からないのは目に見えている。朝食の途中だったが家族みんなでやさしく身体のあちこちをなぜた。当猫がどう思ったのかは分からないが、死にゆく猫に対しての精一杯の感謝の表現をしたかった。母親が「シロは昔から箱の中が好きだったから」といって段ボールの箱をもってきて、それにシロの身体を入れた。段ボール箱に入れたシロは瀕死だったけど、少し安心したような顔になったような気がする。

8:30頃にシロは静かに息を引き取った。しばらく猫の亡骸を目の前にして呆然とした後、「こんな日は仕事を休んでもいいだろう」と思って寝ることにしたが、結局1時間ほど「眠ろう・休もう」と努力しただけに終る。無駄な努力とあきらめて、会社に行った。緊急にやらなきゃ仕事はいくらでもあるが、あんまり集中出来そうにない…。会社に行くにはスクーターを使っているのだが、今日だけはつくづく電車じゃなくてよかったと思った。いい年をした大人がぼろぼろ涙を流しているのをみたら、きっと変な奴だと思うだろう。とりあえず会社に付くまでには涙は止まっていた。

会社に着いてからは気分を切り替えて現状の仕事に集中しようとしたのだが、問題になかなか集中出来ない。同僚に話しかけられても話返すのがつらいし、こっちから話しかけるのもつらい。何か話すと涙がこぼれるような気がするのだ。最悪今日はここまでやらないと…、と自分で決めていた線をクリアー出来たので、17:00位に家に帰った。いつもより3時間は早い帰宅だ。ただ今日だけは--他の人はバッカじゃないか?と笑うかもしれないが--日が沈む前に帰りたかったのだ。

帰宅した時には、既にシロは自宅の北の柿の木の下に埋葬された後だった。こんなに早く帰ってくるんだったら埋葬を1時間くらいずらしてもよかったねぇと、母親。まあ間に合うとは思わなかったし、早く帰ってきたのは感情が混乱していて、まともに仕事が出来ないだろうなと判断したせいなのだが、もっと早めに判断して、土に還る所までも見届けたかった気はちらりとした。そこらに転がっている単なる石が墓石だったが、線香をあげて手を合わせた。

自宅の北の柿の木のそば。12年家族同様暮らしてきた「シロ」が眠っている。楽しい思い出をいっぱい、ありがとうね。今いる所は、誰にも邪魔されず、のんびり、ゆっくり眠っていていいところだからね。ゆっくりお休みなさい。(涙)

2000/06/13(Tue)

最近見る悪い夢でありがちなパターン。自分が高校生の夢だ。というと、「自分が高校生だった時の夢」と思うかもしれないけど、ちょっと違う。その夢の中では、大学を卒業したんだけど、地元に戻った時に、中学生と2月の受験を争って、もう一度母校へ入学したというへんてこなシチュエーションが全体のバックボーンになっている。この背景を前提にする夢って、もう5年以上は見続けているんじゃないだろうか?

その夢の中での自分は、なんだかやたらと戦闘的。目が覚めてみると、最初に難癖をつけるのか相手だか自分だか分からない。幸いなのか、不幸なのか、夢の中で出会う人達は実生活で会ったことのない人達ばかり。まれに実生活での知り合いが現れることもあるが、その人達とは喧嘩はしない。「お〜元気かぁ」などと声を掛け合ったりする。時々その相手がもう実生活ではこの世にいないことがあって、夢からさめた時に悲しくなったりすることがあるんだが。

喧嘩の相手は、時にはクラスの先生だったり、自分のいるクラスの生徒だったりする。もっとも大体の場合、喧嘩している当面の相手は一人とか二人で、それも殴り合いの喧嘩は絶対なくて、口喧嘩なんだけど、喧嘩している最中に「ここにいる自分以外の人間はあっちに行くな」ってなんだか分かっちゃって、一層過激になっていく…。で、夢だと分かって一人気まずい思いをするという…。

なお、私は実生活でそんなに派手な喧嘩ってしたことがない。(知らずに泣かしたことは沢山あるかも…。ふ、色男はつらいぜ(爆笑))何故なら、やっても負けるのが目に見えているから。(^_^;(負けず嫌いなので「負けるかもしれない」喧嘩はしたくないってのもあるかも。)でも寝ている間に見る夢の中くらい、例えば、大金持で、美人に取り囲まれて、悠々自適の安全な暮らしをする…、てのは贅沢なのかなぁ。

ちなみに、その夢の中の高校生活で、授業をサボりすぎて進級出来ないって悪夢も何回も見た。冷や汗を書いて夢の中で勉強していたという…。(^_^;;;;

2000/06/12/(Mon)

最近やたらと悪い夢ばかり見る。

道に迷ってうろうろしているうち、大嫌いな高い所(私は高所恐怖症)に行き当たる。そこから先に行くには、その地点からジャンプして、眼下に見える宇宙戦艦みたいな構造物にしがみつかないといけないのだという。自分のいる場所が地上がうっすらかすんでみえるくらい高い場所からのジャンプ。おまけに、その構造物もうっすらかすんでみえる。(^_^;ああ、どうすればいいんだぁ…というところで目が覚めた。

嫌な夢は忘れようと思って、もう一度眠ると、今度は歩道を歩いている途中で人が車にはねられる夢を見る。これも恐くなった所で目が覚めた。で、もう一度寝ると、また別のシチュエーションで人が車にはねられる夢を見て、目が覚める。いい加減にしろと思いつつ、もう一度寝たら、さらに別のシチュエーションで人が車にはねられる夢をみる。もうその時にはいい加減会社に行かなくちゃいけない時刻だったので、もう一度寝直すことがなかったので、この日の悪夢の連荘はこれでお終い。

現実が苦しいんだから、せめて夢の中だけでは楽しい思いをしたいんだがなぁ。

2000/06/11/(Sun)

飲み過ぎ…なのか、パワーの使いすぎなのか…。とにかくこの日は疲れていた。長野オリンピックで使われたジャンプ競技台を見学したが、高所恐怖症のせいで一番上には行きつけなかった。

ロリコンの半公式定例打ち上げ企画のそばツアーに参加した後、chomboさんを自宅に送って、後はひたすら自宅へ。とにかく眠りたい…。ghoo....

2000/06/10/(Sat)

SF同人φの会主催の第17回「ローカルリフレッシュコンベンション」アルファベットで略すと「LRC」カタカナで訳すと「ロリコン」(^_^;当日。30分くらいで荷物が車に積めるかと思ったが、21インチのテレビ、ドリームキャスト、PS2、それ用の今までに購入したコントローラとソフト全て、ついでに身の回りのもの(下着とか着替えとか)をいくつか用意していたら、あっという間に1時間経ってしまった。寝坊したわけじゃないけど、もうちょっと早く起きたほうがよかったかな?まあ、例年のロリコンのパターンではある。(^_^;

30分遅れでchomboさんの荷物と本人をcomboさんの自宅に拾いに行く。私の運転する車に乗るなんて無謀だなぁ。(^_^;案の定、会場の白馬に行く途中で車の挙動が変になる。白馬の待ち合わせ場所で車を点検したら、後輪のボルトがゆるんでいた。(^_^;途中でガソリンスタンドによって点検してもらったのだが、そこまでは見抜けなかったらしい。

白馬の会場「セブンロッジ」についてからはほとんど乱痴気騒ぎ。酒を飲んで、バカなことを言い合って楽しむ。「そういえばこんな人も以前に言葉を交わしたことがあったかもしれない」程度の付き合いだったとしても、とにかく同病相憐れむの心境と言うのか(^_^;、出会った瞬間からタメ口を言い合えるような空間なのだ。それが異常に心地良い。

2000/06/09/(Fri)

出社してすぐIさんから質問を受ける。私は「恐い人」というイメージがあるらしく(苦笑)、最近滅多なことでは私に質問などしないのだが、いつも指導してくれているNさんがいないので、仕方なく(?)私に聞いてきたらしい。とりあえず質問に答えた後、「これってPerl向きの問題だなぁ」と感じた。行単位の定型データがあってそれをあるフィールドでソートして、ファイルに出力したいのだという。PerlをIさんが知っていたら、こんなのあっさり出来るのになぁ。残念ながらPerlを知らないIさんにPerlについて説明している時間が私にない。いつかはPerlを教えてやるぞと心に誓う…というのはおおげさか。(^_^;

Iさんの作業を横目でちらっと眺めながら、Perlを知っていれば、もっと問題を面白く解決出来るのにぃ…と思いつつ、とりあえず自分の仕事に集中することにする。

自分の仕事はひたすらコーディング。今日はとあるダイアログ2つ分のコーディングをした。とにかくひたすらプログラムを書いて書いて書きまくる。ただし、昨日までと違って、今日取り組んだ部分は、今まで使ったことのあるコントロールとかAPIを使って書くことができたので、気分的にかなり楽。

例によって例の如く、移植元のMS-Windows版の仕様書なんかない(^_^;ので、その仕様を探りながらのコーディングになる。もっとも、少なくともその部分の仕様書がないのは当然で、その部分はMs-Windowsのコントロールのデフォルトの動作をなぞっているだけなんだし、その調査結果をドキュメント化しない私もいい加減といえばいい加減である。(^_^;でも現状そんな事までやってられないもんな。(^_^;大体最近では急ぎすぎてコードやメソッドに対応したコメントさえもまともに付けられていない状況なのだ。それでも1つもメソッドは役割がはっきりしているのと、コメントのないメソッドは定義が10行くらいで、誰が読んでも簡単に理解出来るようなメソッドなので、今のような緊急事態ではコメントに依存する可読性はある程度犠牲にせざるをえないかなと言い訳をしてみる。ええ、言い訳だって分かっているんで非難のメールはご容赦を。(_ _;;

で、今日コーディングした部分で使ったコントロールは、今までに(といっても2種類のコントロールは今週の月曜日まで使ったことがなかったのだが…)使ったことのあるコントロールだったので、コントロールの使い方で戸惑うことはなかった。

まあ、一発で動くとは思わないが(実際、他の人の担当しているモジュールのdebugが終らないと、こっちのdebugが出来ない状況なので確認出来ないのだが)、Windows版のソースから頭の中で仕様を起こし(^_^;、その実装まで比較的すらすら書けた。まあそんなに無茶なバグはないはずだ。本当は、そういうようなバグを避けるように書いているんだけど、それはちゃんとしたテストをしてみないと分からないし。とにかくひたすら書きまくって、一通り書いたコードをコンパイラを通し終わった辺りでは、ぐったり。

ちょっと調べてみたら、今日書き下ろしたファイルに含まれるコードだけで1200行以上になっていた。他のファイルも多少いじったので、少なくとも1300行位編集したんだろうか?他のプログラマに比べて、多いのか少ないのか分からないけれど、少なくとも私の短期の限界はこの程度かなと思う。でもその1200行はとりあえずコンパイルは通るし、ある程度動作することも確信している。いつもはところどころでつっかえて一生懸命やっても300行程度しかコードを書けないんだから、今日は「自分で自分をほめてあげたい。」

2000/06/08/(Thu)

すいません。以下の記述は本人以外には分かんないと思います。<(_ _)>

画像イメージとそのイメージをクリップする領域に対応する四角の描画がうまくいかない。特に画像をスクロールした時に、その四角が描画されたりされなかったりする。スクロールされる度にDrawSelf()がちゃんと呼び出されているし、対応する四角の描画・消去はちゃんとやっているはずなんだけど、なぜかそれが実際の画像に反映されない。う〜ん、どうしてなんだろう?

仕方がないので、スクロールする度、全画面を強制再描画するようにコードを変更。ある程度ちらつくけど、まあこの程度のちらつきは許容範囲内かな?

とりあえずこのダイアログは一通りコーディングが済んだが、最終的なdebugをするには他の人の担当しているモジュールがdebugし終わらないと、ちゃんと動作確認出来ない。まあ、多分大体動くだろう…、ということでこの部分はコーディングが終了したということにしてしまう。(^_^;

2000/06/07/(Wed)

ひたすらコーディング。げ、MacのTableViewもそうだったんだけど、MacのListBoxって、キーボード入力に対してデフォルトでは何にも反応しないんで、キーボード入力に対する反応をいちいち自分でコーディングしなきゃいけないんだ。(x_x;)MacのフレームクラスライブラリのPowerPlantもキーが押された時のcallbackルーチンの用意しかないので、キーをdispatchするのも、各々のキーに対応する動作を記述するのも、プログラマの責任になる。げろげろげろ、こんなスケジュールが切迫した状況で、悠長に各々のキーに対応する動作なんて書いていられないぞ。(x_x)

Macintoshでプログラムを書いている他の人達って、この状況が「変」だと思わないんだろうか?気持ちがめげてそれ以上その部分に関してコーディングをする気になれない。もっとも他に作り込まなきゃいけないことが沢山あって、そこまで手が回らなかったというのが正解なんだけど。(^_^;

2000/06/06/(Tue)

Macのコーディングであたふたしているのだが、先週Windows版の担当部分で次期バージョンに向けてちょっとした修正を頼まれていた。先週のうちにやっておいてくれといわれていたんだけど、すっかり忘れていた。(^_^;慌てて修正を行う…といっても修正自体は大した手間じゃない。手早く済ませ、Visual Source Safeのデータベースにチェックイン。その後Macの方に戻る。

夕方になって、そのWindows版の方にちょっと気になることがあったので、もう一度ソースファイルの現状とその履歴を調べてみた。ところがその履歴がきれいさっぱりデータベースからなくなっている。データベースを作成した日付が今日で、ソースファイルの第一版をチェックインしたのはS''さん。ははぁ、さてはS''さんが次期バージョン用のデータベースを立ち上げたんだな、とピンと来た。現状では現状バージョンのメンテナンスも同時にしなきゃいけないのと、データベース自体のサイズもそれほど大きくないからデータベースを分割するのはあまりいい考えだとは思わないが、まあ悪い訳じゃない。ただ、やるんだったら別のデータベースファイルを用意したほうがいい。と言う訳で、データベースをとりあえず元に戻しておくようにメールした。その10分後…。

S''さん「すいません。データベースは元に戻せません。」
vyama「元に戻せないって…。削除したファイルを復活させればいいだけじゃん。」
S''さん「いや、削除じゃなくて全部パージ(完全削除)しちゃいました。」
vyama「仕方がないなぁ。じゃぁデータベースのバックアップからもう一度履歴を作りましょう。消えちゃった履歴は仕方がないからあきらめるとして。幸い前回のマスター制定からそんなに変更は入っていないはずだから、多少履歴が完全じゃなくてもそんなに影響ないだろうし。」
S''さん「vyamaさん、バックアップの復元ってどうやるんですか?」
vyama「とりあえず、君の持っているデータベースファイルのバックアップを元の場所にコピーしておいて、それから君の変更した最新のファイルだけ登録してくれればいいよ。」
S''さん「データベースのバックアップなんて取ってませんけど?」
vyama「え゛?ま、ま、ま・さ・か、データベースの、バ、バックアップも取らずに、い、今までのソースの履歴を、か、完全消去しちゃったの〜!?ウ、ウ、ウソでしょ?(ウソだと言って!)」
S''さん「いや、履歴なんて必要ないと思ったんで、バックアップなんか取ってません。」
vyama「(頭真っ白、顔面蒼白状態で絶句)…」

あまりの思考ギャップによる衝撃に、マジで頭がくらくらしてぶっ倒れるかと思った。で、当然のことだが、そのS''さんが衝撃から立ち直った私に雷を落とされたのは言うまでもない。(^_^;ま、実を言えばそのデータベースファイルはNetwareサーバ上に構築されていて、そのNetwareサーバは定期的にバックアップを取っているんで、そのバックアップから復旧することもできたと思うのだが、頭に血が上っていたのでその時は気がつかなかった。(^_^;また幸いS''さんは偶然(?)2週間位前のデータベースファイルのバックアップを取っていたので、以前の履歴は何とか復元出来たので、一安心。やれやれ。

2000/06/05/(Mon)

PowerPlantのリストボックスのラッパークラスにLListBoxというのがある。ところがこれが使えないクラスで、行・列の追加、データの追加削除などの基本的なメソッドがなくて、全部直にAPIを呼ばなくちゃいけないらしい。セルの単一選択をやるためには、ListRecordというListBoxに関連づけられた構造体のメンバーのあるフラグを直に変更するようだ。なんだか昔、8bitのROM BASICマシンをいじっていた時、ワークエリアとかジャンプテーブルを直接書き換えて昨日を拡張・変更したりしていた頃を思い出してしまった。

2000/06/02/(Fri)

機能を追加している途中で、突然画像データがうまく表示出来なくなった。表示させてみると砂嵐みたいな画像しか表示されない。ま、どこかで作り壊したんだと分かっているので、慌てず騒がず画像データの表地回りのコードを追っかけてみたら、案の定、画像データを読み出した後、ハンドルの設定を間違えて、描画ルーチンに画像へのハンドルじゃなくてNULLハンドルを渡していた。ま、気が急いている状況でコーディングしている状況では、ありがちな間違いではある。

しかし、考えてみると描画ルーチンにNULLハンドルを渡したのに、メモリ保護エラーにもならず、何にも描画されないということもなく、何かが画面に表示されるってのはすごく変。MacOSってまともにメモリ保護ってやってないなと感じた。

2000/06/01/(Thu)

新聞広告によると、今日は「電波の日」。一日中楽しみにしていたのだが、あいにく頭の中に「ビビビ」と来るようなものは何もなかった。(^_^;

2000/05

一月休みました。すんません。<(_ _)>この月は気持ちに全然余裕がありませんでした。でも東京で行われた5/20の大学のT先輩の結婚式は、特に大学のサークル仲間だけでスパークしまくった3次会は、楽しかった。T先輩、お幸せに。


2000/04 のぶつぶつ

2000/07 のぶつぶつ

日々のつぶやき 目次

作者(vyama_at_janis_dot_or_dot_jp)への感想・意見など。
spamよけのため、_at_や_dot_は適宜@や.に入れ替えてください。

目次ページ