PDF出力を担当しているSさんが(私としては不本意ながら)初めて休日出勤をすることになったので、そのための申請書の書き方をSさんに教えた。その申請書には休日出勤をする理由を書く欄がある。普通はそこには「xxxのコーディングのため」とか「xxxのデバッグ」とかどんな作業をするのかを書くのだが、Sさんの書いた理由は「仕事が遅れているから」そりゃ、仕事が遅れていなければ休日出勤なんかしないよな。(^_^;Sさん、天然ボケのあなどれない人物かもしれない。
自分の作ったプログラムのほうは、既に微調整の段階に入っている。さまざまなパターンでちゃんと出力できるかのチェック。チェックはいくらやってもやり足りないことはないんだが、SさんのPDF出力のほうが心配。ソースレベルでもいろいろチェックしているんだけど、ソースレベルだと「勘弁してほしい」というコーディングがいろいろあってそれを指摘する。といってもPDF出力に関して、そんなに分かっている訳じゃないんで表面的にざっと読んでみただけなんだけど。特にメモリががんがんリークしているのは教育不足だったかなぁ、と反省。
彼に関係したモジュールに関係する障害レポートがあったので、Sさんに渡す。で、Sさんから戻ってきた障害レポートには「どんな原因でその傷害が起こったのか(why)」「その障害を解決するのにどんな手段を使ったのか(how)」ということを書く欄がある。で、Sさんから返ってきた障害レポートを読んだら、whyの部分には「そのパターンに関するコーディングをしていなかった」。で、howの部分には「これからコーディング」と書いてあった。
まあ、ちゃんと教えなかった私も悪いんだけど、howの部分に「これからコーディング」と書かれた障害レポートを検査の人が受け取った時にどんな反応をするのか考えると、思わず吹き出してしまった。(^_^;当然ながらこんな回答を障害レポートに書いて検査の人に提出する訳にはいかない。苦笑しながら、「これは対処が終ったら提出するんだよ」と指導。
そういえば、私が新人のときには障害レポートの書き方というのを詳しく教えてもらったという記憶がない。だからあんまり懇切丁寧に教えられもせず、教えられなくても分かるもんだと思っていたが、よくよく考えてみると、そういえば新人で配属された時に先輩社員から「とりあえず預かっておいてくれ」と言われた障害レポートを、お昼休みとかちょっとした休憩時間の暇つぶしにずいぶん読んでいたっけ。
本当はMacの仕事もしなきゃいけないのは分かっている。でも、同僚の新人Sさんの「お目付役」みたいな役柄をはっきりNさんに言われたし、そうでなくても配属されたばかり、しかも会社に入る前はあまりプログラムの経験がなくて、それでも一応私の仕事を引き継いでくれた格好のSさんには、いきなり私が抱えていたのを全部…というのはさすがに気が引けた。とりあえず私が担当した時には都合フォーマットが7種類あったんだもんな。(^_^;
現状ではそれまでサポートしていたフォーマットと、その共通ロジック部分を私が担当して、新規部分をSさんがやっているということになしくずし的になっている。ただ、なしくずし的というと言い方が悪いが、実は、このなしくずし的な構造になってしまった部分というのが、Sさんの今後の教材になるかと思ってちょっと期待している部分がある。汎用性を求めれば、プログラムなんて改善できる所はいくらでもあるもんね。
ま、そんな思惑とは関係なく今日は(多分詳しくは検査されないだろう)Sさんの作ったPDSファイルを検証してみた。で、そしたら…出るわ出るわ、「なんじゃこりゃ?!」のPDFファイル。(^_^;βまでにちゃんとなるんだろうか。すごく心配。
Windows版のプログラムに関して、私が直接手を下せる所はほとんどなくなったので、残った仕事は同僚のSさんが作ったPDF出力プログラムを検証。で、検証といた所で、私はPDFの内部フォーマットに関しては全然シランケンシュタイン(注:まるで無知の意)なので、実際に出力させてみると、あれがおかしい、これがおかしい、という感じでえんえんSさんの作ったプログラムに文句を付ける訳だ。
制定がほぼ一ヶ月後に控えたこの日の同僚の新人Sさんとの会話。
いや、実際は制定間際までプログラマーというのはバグを潰そうとしてじたばたするんだから、ぎりぎり粘るというのは間違いじゃない。ただ、Sさんはこれが初仕事なので、制定間際に倒れられたら大変なことになるんだら健康管理はちゃんとしてくれよ、と一般的な注意をした積もりだったのが、「ぎりぎりまで頑張れるからまだ余裕がある」みたいな取られ方をされるというのはなんか違うんだよな。(^_^;こっちとしては、もうぎりぎりのスケジュールになっているので、今ごろになって風邪とかで2〜3日休まれただけでも、プロジェクトにとって致命傷になるぞと言いたかったんだけど。(^_^;
Sさんのモジュールはようやくαレベルに達しようかという完成度なのに(これは諸般の事情で仕方がない)、製品全体はβ制定目前。そのへんの現状認識のギャップに頭がくらくら。ちなみにβ制定は今週一杯だったりする。今週はSさんのお尻を叩いてでもβ品質に上げないと…。
まぁ、のんびりしているのは先輩社員である馬耳東風の私の影響が大きいのかもしれない。(^_^;;;;;
会社の新年会が近所の温泉旅館であった。泊まりがけの新年会。(泊まりナシのオプションもあったがそれじゃぁね。)べろべろによった状態で深夜の麻雀で箱をかぶる大負け。この屈辱わすれまじ。
もっとも2回やって、一回トップ、一回箱だから成績からいえばとんとんなんだけど、勝った時には馬ナシ、1000点3円!なんだもんなぁ。(^_^;
Windows版Excel形式出力モジュールの仕様変更。今までは表の部分だけを出力していたのだが、表のタイトル部分が通常段落になるパターンが多いので、通常の段落も出力してほしいという要請。
Excel出力モジュールの内部では、一旦Excelの表として出力しやすく、入力としても与えやすいような中間形式に変換してから、Excelの表として出力していたので、大した手間じゃないと思っていたのだが、案の定つまづく。(^_^;
もっとも、つまずくといっても「何をやっていたっけ?」と思い出すのに時間がかかっただけで、思い出しさえしてしまえば、「ああ、ここはこんなことがあろうかと思って、前もって(上司には内緒で)作り込んでおいた部分だったよなぁ。やっぱりちゃんと役に立ったよなぁ。」などと感慨にふけったりする。
Windows版RTF出力モジュールの調整。例の縦書きレイアウト枠でのMS-WORDでのバグ対処。ユーザサポートのK'さんから縦書きレイアウト枠での例の不具合の報告をもらうが、これはWORDのバグだというように答えておいた。その後、次のバージョンでのサンプル画像のからみでもう一度Nさんから同じような質問をされるが、レイアウト枠に絡むMS-WORDのバグのせいなので、どうにも仕方がない。RTFライティングプログラムというのはRTFリーダープログラムがタコだったらもうどうしようもないから、こちらで対処できるのは限られているもんね、と私自身はそれに関してはあきらめ状態。
その後、Nさん、K'さん、私の井戸端会議でその事が話題になった。そのときにK'さんが「他のメーカは段落に対してレイアウト枠じゃなくてテキストボックスを使っている」と発言。RTFの仕様書にはテキストボックスに関する記述は全くなかったので全然気がつかなかったのだが、「その手があったか!」と思って調べてみると、確かにテキストボックスを使えば、くだんのバグは回避できそう。
問題なのはそのテキストボックスに関するタグが全く非公開(もしくはドキュメント化されていない)ということ。MSDNの最新版を調べても、テキストボックス周りに関する記述はほとんどない。(^_^;仕方がないので、テキストボックスを挿入したRTF文書をWORDで書いてみて、テキストエディタで読み込んでみて、「これがこれに関係しそう」という感じでRTF文書を解析する羽目になった。ま、今回はMS-WORDでの再現性を追求するんだからそれで良いとしよう。(^_^;
何とか解析が終って、プログラムを組んでみて、RTFファイルを出力させてみた。なるほど細かい所で調整が必要な所はあったが、結構それっぽく表示できるようになった。やれやれと思って、そのRTFファイルをMS-WORD上で編集してみると、あるレイアウト枠を削除すると、それ以前に記述されていたテキストボックスも一緒に削除されてしまうことが分かった。これもMS-WORDのバグなんだけど、これって、こっち側で対処しないと絶対クレームが来るだろうなぁ。
仕方がないので、今までレイアウト枠で囲っていた部分を全部テキストボックスで囲むように仕様変更。細かい調整(このパターンだと何%くらいレイアウト枠を広げないと…などといった経験的な部分)などを再調整したので結局一日かかってしまった。(;_;)だた、レイアウト枠に絡むMS-WORDのバグに関してはこれでおさらばできたのでよしとしよう。昨日一日分無駄になってしまったことはこの状況じゃ仕方がないよな。
Windows版RTF出力モジュールの調整。縦書きのレイアウト枠内部に改行が沢山あるRTFファイルをMS-WORDに読み込ませると、レイアウト枠の高さが勝手に大きくなっちゃっうというバグがある。で、勝手に大きくなるのはいいんだけれど、MS-WORDはそのレイアウト枠を強引に用紙サイズに納めようとして、Top-Leftの位置を上にずらしてくれる。で、他のレイアウト枠と重なってしまってとてもみっともないことになってしまう…というバグの対処。
あれこれやってみたが、これはレイアウト枠を使うという仕様では絶対避けられない事態らしい。レイアウト枠が重なるとあまりにもみっともないのでレイアウト枠が重ならないように、MS-WORDがレイアウト枠を勝手に大きくしてしまうパターンを調べあげて、レイアウト枠が大きくなって、元の用紙サイズに収まらなくなった場合には用紙サイズを適当に大きくして回避するようにした。ただ、基本的にMS-WORDのバグのフォローをしている訳だし、対処療法的な手段なのであんまり気持ちのいい対処の仕方ではない。もっといい対処の仕方はないものか?Microsoftがバグを直してくれるというのが最善の対処方法なんだけどなぁ。
Windowsの認識結果出力プログラム。外注のMさんから「あんたの作ったデータは整合性が合っていないんで、こっちでうまくいかない」という指摘を受ける。確かに私の作ったモジュールが吐き出した数値をそのまま信じて出力すると、ちょっと無理があるパターンってのはあって、反論できないんだよな。(^_^;具体的にはレイアウト枠の大きさと、その中に書かれているテキストフォントの大きさの関係が結構いい加減だということ。両方とも正しいと信じてプログラムすると、1つの行がレイアウト枠の幅に収まらない場合が出てくる。
じゃあ根本的に回避する方法を考えると、GetTextExtend() APIを使って、実際に文字列が表示された場合にどれだけの長さになるか計算して、1つの行がレイアウト枠の幅に収まるようにフォントの大きさを小さくしてやるということなんだろう。でも、じゃあどんなDevice Context(DC)を使うのか?という所で、袋小路。単にスクリーンのDCを使えばいいのかなぁ。使うとしても、いろいろ汚いことをやらなきゃいけないような気がするんだよなぁ。
心配していたSさん担当のPDF出力モジュールは昨日と今日で結構進んだみたいで、まだまだ油断は出来ないものの、当初心配していたよりはずっと楽観できるような感じになってきた。仕様の勘違いなどからくるミスを駆逐してしまえば(その手のミスは致命的になりやすいので逆に見つけやすいし、細かな仕様の勘違いは修正するのも比較的簡単なものだ)、ある程度の品質にはなるだろうという感触を得る。昨日まではメモリを変なパターンで使っていて、仮想記憶をバシバシ消費して実用に耐えなかったのを、1日で何とか改善できたのはしたのは立派。ま、最初からそうすればいいというのはあるけれど(^_^;、プログラム経験1年未満でちゃんと自力で改善できたのが素晴らしい。ちょっと気が早いが、初めての仕事をよくがんばったね、という感じ。思い返すに私の初仕事なんぞ、見るも無残、語るも無残…て感じだったからなぁ。(^_^;
Windowsの認識結果出力プログラム。Sさんがファイルをチェックアウトしたまま年末年始の長期休暇に入っちゃって、修正したいのに修正できない。しおしおのパ〜。
ミレニアム初出勤の日…のはずなんだけど、朝から質の悪い咳が全然止まらない。熱も下がったし、咳が出る以外は大丈夫なんで、出社しようと思えば出来たんだけど、チームのメンバーにうつしちゃ大変なので、あえて休んだ…。
とかいえば聞こえがいいかもしれないけれど、長い年末年始の休みの間ず〜と風邪ひきの寝たきり同然だったので、怠け癖が付いちゃったからだったのかも。あ、怠け癖は今に始まったことじゃないか。(^_^;
風邪ひき大魔王となって、辺りに風邪ウィルスをまきちらすなどという愚かな真似をせず、ひたすら暖かくして寝る。ああ、今年の年末休暇は結局「風邪とともに去りぬ」にになってしまったぁ。(;_;)