一体どうしてこんなことになったのかよく分からないのだが、(^_^;今年のSF大会の実行委員会に入っている。SF大会に出たことが一度もないのに、金勘定やらトラブル窓口の担当になっている。(^_^;金勘定はやったことがないし、SF大会でのトラブル処理なんて全然経験がない(SF大会に出たことが一度もないんだから当前だが)のに、何の因果で…。
家に帰ってから、大会のWebページの更新やら、会計前任者から渡された会計関連のExcelシート(ひねた書き方になっているんだ、これが。(^_^;)資料をひっくり返しているうちに、あっという間に午前3時、4時という日が続く。当然のことながらこのページは更新できず。
認識エンジンを曲がりなりにも動かしてみる予定だったが、どうやって曲がりなりにも動かせばいいのか全然ドキュメントがないので(^_^;、せっせとソースコードを読んでいった。結局それだけで一日終る。(^_^;;;
たまたま気が向いたのでgooでvyamaで検索をかけてみたら、面白いことが分かった。スワヒリ語の研究をしている人が、土着の哲学書(?)の翻訳をしてくれていて、その中でvyamaの訳を載せていたのだ。
そうともそうとも。たちどころに不思議（vyama）を見るだろうさ。
以前からスワヒリ語でvyamaという単語があるのは知っていたのだが、めちゃめちゃ卑猥な言葉だったり、「大天才」とかいうようなとんでもない意味があるんじゃないかと思って冷や冷やしていたんだけれど、「不思議」くらいの意味だったら結構面白いかもしれないなと思っている。もっとも詳しく読んでいないからどんな文脈で使われているのかよく分かんないんだけどさ。(^_^;
ここの所、日記を全然書いていない。家に帰るとやねこんページの更作業に追われて、全然日記を書く時間が出来ないのでした。(じゃあ今は自宅じゃないのか?というツッコミは禁止(^_^;;)
この前送ってもらった体験版の不具合に関して、OEM提供先の対応があまりに人をバカにしているので、頭にきている。ソースコードのブランチを避けたいので、クライアント(つまり私)が指摘した不具合をそのままで通させてくれなんてのは、完全にこっちをなめているとしか考えられんよな。ライセンス契約が体験版と製品版で違うから返させてくれといっても、嫌だとごねるし。全くこっちにどれだけ迷惑をかければ気がすむんだろう?こいつらとは本当にさっさと手を切りたい。
Macプログラム。GetPrivateProfileXXX系統のAPIをエミュレートする関数の作成の続き。データを読み込むのはMacの神様のMさんの書いた初期化ファイルのライブラリのソースを読んで何とか作成できた。が、ど〜しても書き込みがうまくいかない。
エンジンをちゃんと動かすためには、いろいろ初期設定ファイルから情報を読み出さなくちゃいけない。今まではその部分はダミーだったが、今週と来週かけて認識エンジンだけでも動くようにする予定なので、まずは初期設定ファイルの部分をコーディングというか、Macの初期設定ファイルのことを何にも知らないので、Macの神様のMさん(Macの師匠Sさんのさらにその師匠格)が書いたリソースファイルに関するライブラリを読んで、いただけそうな所はいただいて…、と思っていた。
が、世の中そんなに甘くはなくて(^_^;、Macの事とかよく分かっていない私が読んでもよく分からないところが続出。え〜と、初期設定ファイルをいじるクラスの親クラスがLFileか。確かこれはPowerPlant(Macのフレームワーククラスライブラリ。要するにWindowsで言えばMFCみたいなもん)のファイルに関するクラスだったはず。え〜とこのクラスのメソッドは…とPowerPlantのリファレンスライブラリを見たら…。LFileについて何にも書いてない。げげげ、じゃあソースファイル読まないと何やるメソッドなのか分かんないの?(^_^;;;
Code Warrior MLで「Macでプログラムを書く人で変なプログラムを書く人がいない」という経験談を読んだけど、これ確かに当たっているような気がする。というか、LFileなんていう基本クラスの説明が抜けているようなドキュメントしかない状況でプログラムをばりばり書ける人ってのはよっぽど優秀じゃないと不可能だ。普通の日曜プログラマーレベルじゃ絶対プログラムを書けるようになんかならんぞ。(^_^;つまり「Macでプログラムを書く人で変なプログラムを書く人がいない」のは正しいんだけど、理由が「優秀なプログラマーじゃないとMacプログラマーとして生き残れない」じゃあんまり意味のある主張だと思えんなぁ。(^_^;;;
かくして、平凡というレベルすら怪しい、ましてや優秀では絶対ない私が今やっているMacへの移植作業は大幅に遅れるどころか、そもそも出来るんかというレベルで非常に怪しくなってきたのだった。(^_^;;;まあ、完成すれば大ラッキーなんだから、1年とか2年くらいの遅れくらいどぉってことないよな。(^_^;;;;
出社してみると、OEM提供先からCD-ROMが届いていた。やれやれ、これで検査ができる。で、その体験版のプログラムなんだが、ある程度日数が経ったら、使えなくなるという以外に制限事項はないはず。で、最初に日数制限の検査をした。そしたら、日数制限のトリガが一度起動されたら、二度と体験版が起動できない。もちろん体験版なんだからそう動いて欲しいんだけど、一度そのトリガーを起動してしまったらOSの再インストール以外にはそのトリガーを外す手段がないというんでは、テストするほうとしてはつらすぎる。(^_^;一応手持ちマシンが2台あったので何とかなったが、これでは2ヶ月くらい経って、体験版についてのサポートをしなくちゃいけない場合に、大変なことになるぞ。(^_^;心当たりのありそうな、関連するレジストリとか、ファイルとかを全部削除しても効果がなかったから、一体どうすればいいんだ?(^_^;
それ以外にも体験版について、前に指摘しておいて、向こうも直すと約束していたバグが全然直っていない。実はこのバグ、本当は「ど〜でもいい」感じのところで、実際の動作・操作にはあんまり影響がないんだけれど、こっちが指摘したバグをちゃんと直す気がOEM提供元にあるのか?、直すといったところは本当に直るのか?という指標として使うつもりでいた。(以前にも直すといっておきながら、ドタキャンで直せなかった致命的部分も結構あったし。)結果はNG。バグを出しても発見する気どころか、指摘されても直せない(or/and 直す努力が見えない)んじゃ、OEMを提供してもらう取引相手としては失格。営業サイドではどう思うか知らないが、技術的に誠意を感じられない、信頼できないところと一緒に仕事なんか出来るはずもない。まあ、今後あの会社とは一定の距離を置いたお付き合いになるだろう。もうあの会社のことは馬鹿馬鹿しいんで、真剣に考えるのは止めて、この日記のネタになるようなおバカな行動を期待することにしよう。(^_^;
とりあえずの不具合報告と、体験版のトリガーを外す方法についての問い合わせのメールにもOEM提供元はナシのつぶて。こいつら、「人の時間を無意味に消費させる」能力だけは一流なんだよなぁ。(^_^;
ロシアのサイトからのダウンロード作業が一晩経っても終らない。昨晩帰社前にすべてのファイルが夜のうちにダウンロードできるようにしておいたのだが、ほとんどのファイルがタイムアウトエラーでダウンロードできなかった。という訳で、今日もダウンロード作業を行う。なんでこんな作業をクライアント側が負担しなければいけないのか、よく分からない。今度からはこっちのFTPサイトへの転送終了をもって、納品とするように変更してもらおうと決意。
で、つらつらとダウンロードしていると、サイトから突然ファイルがなくなった。おいおい、こっちが転送し終わらないうちにファイルを消しちゃって、一体どういうつもりなんだ?頭にきて、相手先にこっちのFTPサイトに送ってくれとメールを出したら、「月曜日にCD-Rをこっちから発送したから、明日の午後にはそっちに届くだろう。それで届かなかったら、もう一度連絡をくれ。」との返事。バカを言うんじゃない、締切日は先週の金曜日なんだぞ!クライアントと約束した締切が金曜日で、実際にクライアントに届くのが水曜日って、それじゃ締め切りの意味がないじゃん。
金曜日とか土曜日に発送したんだって言うんだったらともかく、こっちが受け入れ作業を始めようという月曜日になって発送するっていうのは一体どういう神経なんだろう?バカも休み休み言ってほしいと思った。担当者が変わったから少しはまともになるかと思えば、これだもんなぁ。はっきりいえばこの会社とはもう二度とお付き合いしたくない。今回はまだ日程に余裕があったから、まあ何とかなるけど、ユーザーから上がってくるクレームも「確実に再現する状況を教えてくれなければ、おいらはなんにもしないもんねぇ。」なんてとぼけてみせるし、品質はβレベル以下で、納期も守らないとなると、こういう会社を信用しろってのが無理だというものだ。まあ、そうやって自分の首を絞めているうちはいいんだが、結果的にそういう無責任な行動が私の首まで絞めてくれる訳で、非常にありがたくない。(-_-;;
ダウンロード中に、Iさんのコーディングをちらちら眺めてみると、色々問題になる所が見つかって頭を抱えてしまう。まあ、あんまり経験がないんだから仕方がないんだし、「そこそこ書ける」程度から「ちゃんとしたプログラムが書ける」レベルへステップアップする時の壁に丁度ぶつかっている感じなんで、その意味ではあまり心配はしていない。
if (fread(pBuffer, 1, uSizeOfFile, fp) != uSizeOfFile)) {
//エラー処理
…
return ERROR;
}
BITMAPINFOHEADER * pBmph = pBuffer + sizeof(BITMAPFILEINFOHEADER);
DWORD dwSize = pBmph->biSize;
LONG lWidth = pBmph->biWidth;
LONG lHeight = pBmph->biHeight;
…
おいおい、このコードだと、例えば100MバイトのBMPなんてのをロードしようと思ったら、100Mbyte以上メモリを割り当てていないと、動かないってことになっちゃうじゃないか。(^_^;おまけにBITMAPINFOHEADERの始まるファイル上の位置を、パッキング状況によってコンパイラ依存、処理系依存(本当にそうなのかは深く調べていなけどさ(^_^;)の sizeof(BITMAPFILEINFOHEADER) なんてので調べているし。この部分も手を入れなくちゃいけないなぁ。
そう思ってつらつら眺めていたら、昨日直しておいてね、といったはずの
//pBmphはファイルから読み込んだバッファ内のポインタ
DWORD dwSize = pBmph->biSize;
LONG lWidth = pBmph->biWidth;
LONG lHeight = pBmph->biHeight;
ConvLE2BE((LPBYTE)&pBmph->biSize);
ConvLE2BE((LPBYTE)&pBmph->biWidth);
ConvLE2BE((LPBYTE)&pBmph->biHeight);
…
DWORD dwSize = pBmph->biSize;
LONG lWidth = pBmph->biWidth;
LONG lHeight = pBmph->biHeight;
…
void ConvLE2BELPBYTE pBase)
{
swap(pBase, pBase + 3)
swap(pBase + 1, pBase + 2)
}
え〜ん。こんな修正コードじゃ、あれほどよくよく言っておいた、アライメントの問題が全然解決されていないじゃないかぁ!なんでこんなコードを書いたのかを問い詰めてみたら、「GetLEndianDWORD()がうまく動かなかったから」という。「馬鹿も休み休み…」と思って調べてみたら本当にうまく動いていなかった。(^_^;ソースコードを読んでみたら、
//Little EndianのDWORD変数を取得する
DWORD GetLEndianDWORD(void * pBase, int iOffset)
{
unsigned char * pCharBase = (unsigned char *)pBase;
return ((DWORD)pCharBase[0] ) + ((DWORD)pCharBase[1] << 8) +
((DWORD)pCharBase[2] << 16) + ((DWORD)pCharBase[3] << 24);
}
…
もっとも、「彼なりに」再構成したEndian処理プログラムも見れば分かるとおり、パッキングの問題を全然意識していないので、問題がありすぎなんだけどね。(^_^;まあ、現段階では、「これはこんな感じで書くんです」と押しつけるしかないかな。だって、社内にほとんどWindowsプログラマーしかいなくて、ファイルイメージ = 構造体のメモリイメージだと思っている人だって結構いるみたいだからなぁ。(sigh)
なお、Cプログラマーで、どうしてこんなに「マシンによってパックが云々なんて言っているんだ?」とかGetLEndianDWORD()みたいな関数を使わなきゃいけないか分からない人は、
typedef struct tagTEST1 {
char a;
short b;
} TEST1
TEST1 t;
printf("%d %d\n", &(t.a) - &t, &(t.b) - &t);
OEM提供を受けて、国内ではうちの会社のブランドで出している製品の体験版の締め切りが金曜日なのに、全然モノも届かないし、連絡もない。あわてて相手先に連絡をしてみたら、「出来たという連絡を入れるのを忘れた」という「お前なぁ…」状態の返事が帰ってきたのでむっとする。まあ、モノができていて、こっちで受入検査が出来るんだったら文句は言わないでおこう。
ええと、なになに…。モノはどこどこのFTPサイトにおいてあって、アカウントとパスワードがこれだから、そこから取ってきてほしい。ふ〜ん。じゃあ、早速そのサイトにアクセスしてみるか。ええとftp.xxx.ru…。え?.ru?おいおい、これってロシアのサイトじゃないか!モノは40Mバイト近くもあるんだぞ。(8つに分割されてはいるんだが。)転送できるんか?
やってみたが、案の定、転送が途中で失敗しまくって、全然モノが手に入らない。いらいらがつのる。一体どんな経路を通っているんだと思って調べてみたら、アトランタのISPらしき所を経由している。ふ〜む、太平洋を一回超えた後、ベーリング海を超えて転送されてくるんだ。こんなに沢山回り道をするんだったら、転送がなかなか成功しないのは当たり前だよなぁ。(sigh)
そういう訳で、今日はすごく機嫌が悪い。とばっちりは一緒に作業をしているIさんに向かう。(^_^;BMPファイルの読み込みルーチンを移植しているIさんから、「MacでファイルからWORDデータを読み込むと、上位バイトと下位バイトが反対になって読みだされるんですけど、どうしたらいいんですか?」と聞かれる。これは典型的なEndianの問題だろうなと思って読んでみたら、案の定こんな箇所が見つかる。(説明のためかなり変えてある)
if (fread(pBuffer, 1, uSizeOfBuffer, fp) != uSizeOfBuffer)) {
//エラー処理
…
return ERROR;
}
BITMAPINFOHEADER * pBmph = pBuffer;
DWORD dwSize = pBmph->biSize;
LONG lWidth = pBmph->biWidth;
LONG lHeight = pBmph->biHeight;
…
もろにEndianの問題に引っ掛かっているだけでなく、マシンやプロジェクト設定によっても構造体のパッキングが違うことも考慮に入れていないじゃないか。(x_x;さっそくその部分については書き直しを命じた。言うまでもなく普通は、ファイル上の表現と内部的な構造体の表現とか完全に一致していることは保証されない(が、たまたまWindowsでやっているときには一致するのだが)ので、例えば、
DWORD dwSize = GetLEndianDWORD(pBmph->biSize, 0);
LONG lWidth = (LONG)GetLEndianDWORD(pBmph->biWidth, 4);
LONG lHeight = (LONG)GetLEndianDWORD(pBmph->biHeight, 8);
…
DWORD GetLEndianDWORD(void * pBase, int iOffset)
{
unsigned char * pCharBase = (unsigned char *)pBase + iOffset;
return ((DWORD)pCharBase[0] ) + ((DWORD)pCharBase[1] << 8) +
((DWORD)pCharBase[2] << 16) + ((DWORD)pCharBase[3] << 24);
}
…
もう1つ、ダウンロードの経過を注意深く見守りながら、本職のコーディングが出来るほど頭の切り替えがさっさと出来るほうではないので、Iさんの書いたコードをボ〜と見ていたら、何やら途中でローカル変数の宣言が20個近くもあるCの関数を見つける。こんな関数は大体本体も長いもんなんだよなぁ、と思って数えてみると140行以上あった。この部分はMac移植の際に、新規コーディングした部分だったので、迷わず即座に書き直しを命じた。ついでに新規コーディングに関しては「100行以上の関数を書いちゃ駄目」と厳命する。しかし、こんな長い関数、良く書けるというか、書く気になるというか…。(^_^;私だったらこんな長い関数を書いたら、何をやる関数だったのか書き終わりの頃には忘れてしまうぞ。(^_^;
出社して、親会社を含む後方掲示板を読んでみたら、某親会社の子会社、つまりは私の所属している会社にとっては兄弟会社から、在庫一掃セール(ただし社内限定)ということで240Mbyte MOを安く販売してくれるとのこと。早速注文しようと思ったのだが、受け付けが明日からということなので、ぐっと我慢。とりあえず申し込み用紙に必要事項を全部書いて、明日朝一番で出すことにしよう。
Mac版移植作業。何とかそれぞれカスタマイズした(といってもカスタマイズ内容はこれから書くんだが)Windowを出せるところまでいった。順調とはとてもいえないが、PowerPlantを勉強しだしてから、勉強しながら、色々なリソースの移植をやりながらの試行錯誤だから、まあ仕方がないか。(^_^;
HTML出力でとんでもないバグが分かった。"と書くべきところを&quatと書いてしまったというバグ。(^_^;単純な変換テーブルデータの書き間違いで直すのはあっという間なのだが、たまたま今日は今関っている製品の体験版の制定日だった。この変更を反映させられればいいな、と思ってはいたが諸般の事情で(^_^;体験版での修正は見送って、次の出荷バージョンから修正することになった。
もっともその体験版CDを一緒に作っている別のチームがミスをして、CD-ROMを作りなおしになったので、入れようと思えば入れられたんだけど、まあ体験版だからまあいいかぁ。(^_^;
夕方になってから、在庫一層セールの品物が尽きたという掲示が出ていた。ウソ〜!受付が始まる前になんで品物が尽きちゃうの?(T_T)ふざけるんじゃないと思って、掲示を出した部署に抗議。で、もうそのことだけで今日は仕事をする気が失せてしまった。(^_^;
MacのプログラミングツールであるCodeWarriorのMLに入ったのだが、思ったより流通量が少ない。Visual C/C++ MLやらBecky! Internet Mailの流通量に比べるとはるかに少ない。(流れているメールの桁が違う。(^_^;)やっぱりMacでプログラムする人が少ないのか、それともMacでプログラムをする人はみんな優秀で質問するまでもないのか。でも多分前者。(^_^;
PowerPlantの勉強は、PP Bookの第8章までいった。まだまだ先は長いなぁ。(;_;)
MacのInterface、Macのエディタ、Macのキーボード、MacのIME(WX3)を使いながら、 WinのInterface、Winのエディタ、Winのキーボード、WinのIME(WXG)を同時に使っていると、もう指先と頭が大混乱。(^_^;例えば、クリップボードへのコピーは、Windowsだったらctrl + C、MacだったらCommand + Cなんだけど、当然ながら、ctrlキーとCommandキーは全然別の位置なので、両方ちゃんぽんにいじっていると、例えば、クリップボードにコピーしたつもりでもされていなくていらいらしたりする。う〜む。(-_-;また、テキストに限っては、Win-Winの間ではクリップボードを共有できるようなプログラムを作ったので、データの転送は楽なのだが、Win-Mac間だとちょっとしたデータでも、どこかにコピーして、それをアプリケーションから読むという手間がかかってしかたがない。う〜む、マシンの間でのクリップボード共有ツールをMac上でも作らないといけないのかなぁ。でも、あのプログラムって、MFCべったりだし、そもそもソースをなくしちゃったからなぁ。(^_^;IPMSGのソースをもう一度読み直して、クリップボード共有ツールを1から作りなおさないといけないのかな。(^_^;(それともJavaで書くか?(爆))