今日が社内論文の締切日。で、前日というか、当日の午前中、出勤ぎりぎりまで社内論文をまとめていた。あと12時間(^_^;しかないような状況では、今更書き足してもぼろが出るばかりだと思って、追加してボロを出すか、何も言わずにごまかすかの選択では、迷わず後者を選択。とりあえず、ぼろが出そうな所はばっさり削除した(^_^;。
このページみたいにあっさり馬鹿は馬鹿だと開き直って書ければいいんだけど、あいにくそういう冗談はこの場合には通用しない。別にひどい出来でそのまま提出してもいいんだけど、あまりにひどい出来だと、指導教官的役目の直属の上司が「何をやっているんだ!」と怒られることになりかねない。そんな訳で、合否はともかくというか、結果は否に決まっているのだが(^_^;、得意技の「とてつもなくみっともない文章」は封じられている。得意技を封じられると原稿の進み具合が進まない。まあ、いつもの調子で書いたら論文にならないけど(^_^;。
夕方になって、一通り論文を読み終わった部長から「お情けで月曜日まで待ってあげるから、ちょっとは論文の体裁を整えてこいよ」というありがたいお達しがあった。要するに構成なり論理展開を考えて出直してこいということなんだが、とりあえずぎりぎりの締め切りが月曜日になった。
一旦「これでおわりだよ〜」と言い渡されたあとで、「あと二日だけ待ってやる」とか言われたら、普通は完成度も上がるし、色々修正できる。その意味でありがたい事には違いないが、「もう通るか通らないかはともかくとして、終わらせたい」という感じがつのる。
ごめん、昇進をかけた社内論文のせいでこのページをメンテナンスする時間が取れません。月末まで迄更新ストップします。6月頭にまとめて書くのでゴメンね。<(_ _)>(実は単なる言い訳だったりする。論文なんて全然書いてないもんねぇ、へへぃ。Baby)<もうどうでもいいとあきらめているらしい
忘れた…忘れたのオンパレードだろうな、きっと。(^_^;
そういえば、今日の会議でとびっきりのオフレコ情報を耳にしたんだけど、上司からしっかり「オフレコだからね」としっかりクギを刺されてしまった。(^_^;でもそんなことにはめげないのでここでそのオフレコ情報を公開しよう。
実はね、うちの上司が"ピー"に"ピー"した時なんだけど、やっぱり向こうとしては"ピー"が"ピー"だから"ピー"だっていう話みたい。まあうちの場合、"ピー"が"ピー"だから"ピー"は"ピー"として"ピー"と感じるのも"ピー"かもね。
以上、上司検閲済み。(ウソ)
う〜ん、例の巨大関数とか意味不明の即値の話を書いたら、今日早速Sさんがやってきて、私のパーティション近くのIさんに「昨日vyamaが200がどうしたとかいって騒いでいたでしょう?」とか聞いていた。ページを公開しておいて、こんなことを言うのもなんだけど、そんな事を言われるとすごく恥ずかしい。(^_^;Iさんは「この製品には"経験上つかんだ"みたいな数値が一杯あるからね。」それって経験のない私じゃ読めないということじゃないんだろうか?まあ、そのうち慣れてくるんだろうけど。
今日読んでいて面食らったのが、次のような文だった。
if ((wLineNo == hdData[wDno].wDlineStart)
|| (wLineNo && ((hlData[wLineNo - 1].wLflg & (WORD)H_ZDZA)
|| (hlData[wLineNo].wLfntSize
!= hlData[wLineNo - 1].wLfntSize)))) {
ぱっと見て、3つのor条件のようだ。しかしそれにしてはなんだか変だなぁと思ってよ〜く読んで見ると
if (A or (B and (C or D))) {
という条件式になっている。なんだかカッコが多くてLISPを読んでいるような気になってきた。(^_^;
で、ぐちゃぐちゃ文句を言っていたら天罰が下ったのだろう。私が書いたのだが、1月前に私の手を離れたはずのコードに関して、コンパイルするとメモリ保護エラーが起きるのでなんとかして欲しいと頼まれた。おかしいなぁと思って、コンパイルすると確かにメモリ保護エラーが起きる。よくよく考えたら、ある関数で引数を追加した事を思い出した。修正を反映させるためには、すべてのモジュールをビルドしなおさないとだめだ。その事を、早速担当のKさんに連絡。どうやらどんぴしゃだったらしい。う〜む、確かにそれを伝えていなかった。悪いことをしてしまった。反省。(~_~;)
会社で与えてくれたメールアカウントにマイクロソフトから、「/Microsoft Techヅd 98 Yokohama早期割引申込締切迫る!」という内容のメールが送られてきた。「Techヅd」って一体何なんだ?(^_^;
先日、うちの会社でOCNエコノミーを引いたとの連絡が入った。今までは親会社経由で外部と接続していたのだが、OCNエコノミーはうちの会社の専用線だ。そちらに切り替えたら、いや〜、早い早い。アメリカあたりのFTPサーバーにアクセスしてファイルをダウンロードしても4K CPS位は軽く出るし、調子が良ければ9K CPS位までは行くもんね。これだけ早いと技術資料のサイトなんかにもいらいらせずにアクセスできる。今までなんか、昼間は0.4 CPS位しか出なくて、タイムアウトなんかもばんばん起きていたから、ちょっと資料を見るのでも大変だったのだ。いやはや快適、快適。v(^_^)
検査チームで、マシンが不足しているから、古いマシンがあったら提供して欲しいとの事。で、「性能はPentium120Mhz程度以上、32MBメモリは必要です。」とのこと。6月あたりにPentium 166Mhzマシンが手に入る事になっているが、そうなると今サブマシンとして使っているマシンを提供してもいいかな?と一瞬考えたが、そのマシンはPentium 90Mhzだし、私だってマシンが沢山あった方が何かと便利だしという訳で、検査チームにマシンを提供するのは断念。実はもともと提供する気なんてさらさらなかったりするのだが。(^_^;
どうやら変な噂(笑)が飛び交っているらしい。良く見に行く所の日記ページにこんな事が書いてあった。
彼に関するうわさ。これだけ暑くなったと言うのにブルゾンを着ている理由は「ポケットが足りないから」らしい。一体何をそんなに持ち歩かなくてはならないのかは謎。(笑)
これがお昼休みの私の姿だと仮定して(笑)、持ち歩いているもののリストを挙げてみると…。
うちの会社のサッカーチーム(といっても同好会だけど)がY村のチームと昨日練習試合をしたとの事。Y村のチームは結構強いらしく、親会社の職場対抗のサッカーリークで年に一勝挙げられるかどうかという、うちの会社のチームとは実力に相当開きがあるらしく、なんでも去年の練習試合では12点差を付けられたらしい。(^_^;昨日は何点差がついたのか聞いたのだが、「いや、憶えていない」とか「話せない」とかいってはぐらかされてしまう。これはよっぽど点差が付いて、恥ずかしくていえないのかな?と思ってしつこく聞いたら、なんと本当に何点差がついたのか選手にも分からないらしかった。なんでも10点差位ついた辺りまではスコアを取っていたのだが、途中からスコアを取っていなかったからどれくらい差がついたのか分からないとの事。でも今年こそはがんばって一勝して欲しいなぁ。(^_^;
sambaの最新バージョンをコンパイルしようとしたら、途中でエラーが出るという現象に3week前から悩まされていた。ソースの文法エラーとかで止まるんじゃなくて、コンパイルしている最中にいきなりコンパイラが死んでしまうというので、全くのお手上げ状態。今日、たまたまネットニュースを読んでいたら、原因はslack ware3.4.0に添付されているgccのバグとのこと。なんでも結構有名な話らしい。キ〜〜〜。私は全然知らなかった。そうと知っていればあんなに悩まなくてもすんだのにぃ。(^_^;とりあえずgccの新しいバージョンをダウンロード。でも、今週末は社内論文を書きあげなくちゃいけないから、これをインストールできるのは早くて来週になるだろうなぁ。
言い忘れていたが、実はこのページ、トップページのタイトルが変更になった。もう随分前になると思うのだが、恵比須くんのコーナーを止めちゃったので、タイトルが「ドツボのページ」に戻ってます。まあ、どうでもいいけどね。(^_^;
やっと例の巨大関数を読み終わった。読み終わった感想だが、1つのループでなんでもかんでもやろうとして、1つ1つのループが強烈に長くなっている感じ。おまけに小さな関数(本体が5行程度)とかマクロを利用するべきところで、ループ中に直接展開している。min()とかmax()とかなんて基本中の基本マクロなんだから、長くなりそうな関数では積極的に使って欲しかった。
で、懸案の巨大関数を読み終えたのでめでたしめでたしである。その巨大関数の後には80行ほどの小さな(?)関数を読み始めた。今度の関数はコメントによると、スキャナーから読み込んだ文書の左マージンが、半角空白に換算して何キャラ文になるかを計算しているということだ。大きさの単位はTWIPSで計算しているらしい。まあ、さっと読める程度の長さだから…と思って読んで行った。
ところが一ヶ所、関数中に200という即値データーがマクロとかコメントなしに埋めこまれていた。前後から考えて、フォントの大きさを計算していることは確かだったので、TWIPSで計算した時の1論理単位 = 20 point の20か、1論理単位 = 1440 TWIPSのどちらかならまだ分かるのだが、200という数字の根拠がよく分からない。数時間考えてみてもさっぱり分からなかったので、このソースを書いた人にメールで問い合わせてみる。程無くして回答が来た。
「TWIPS換算で、1440っていう数字が出てきますよね。」ふむふむ。「だけどこの変数はWORDで計算しているから、over flowしないように縮尺を1/10にして計算しているから、144という数値が出てくる。」それなら最初からDWORDで計算すればいいじゃんと思うが、Win16時代にコードを書いて、Win32に移った時にDWORDで書き直せばよかったのだろうが、とりあえず動いているソースに手を入れるのは勇気がいるし、多分そこまで手が回らなかったのだろう。ありがちな話である。まあこの場合前後関係から縮尺を1/10にして計算しているんだろうな、とは読み取れたので驚かなかった。「で、144で計算すると経験的に空白の数が多すぎるので200にした。」そんなの、コメントも説明もなしで分かる訳ないじゃん。勘弁してくれぃ。
「200問題」を色々追いかけて、何かヒントになりそうな箇所がないかソースファイルを捜し回っているうちにとんでもない関数を見つけた。普通関数とかを探す場合には開発環境に備えつけられているサーチツールを使うので気がつかなかったのだが、たまたま「あの関数はすぐそこにあったよなぁ」と思ったので、たまたまPageUpキーを叩いて探した時に発見した。なんか、スクロールしてもちっとも関数の頭にたどり着かないなぁと思ってその関数の行数を調べてみたら、490行以上あった。絶句状態。確か今読んでいる関数のすぐ後に実行される関数だよな、これ。300行の関数を読んだ時には、まさかそれ以上の大物が控えているなんて思わなかった。(^_^;
しかし、こんなにメチャメチャ長い関数ってどうやってメンテナンスしていたんだろう?まあ、switchに対応する条件が沢山ある場合(例えばメッセージハンドラとか)には、関数は長くなってしまうのは分かる。(話に聞いただけだが、以前うちの会社でメッセージハンドラが1000行になってしまった例があるらしい。)でも、今まで読んできた中でswitchは全く使っていないし、なぜこんなに長くなるのか、なぜこんなに長い関数を書けるのかよく分からない。私だったら書いている途中で破綻しているぞ。(^_^;
で、読んでいるうちにソースファイル単位でのオプティマイズが出来るとっても賢いプリプロセッサを使って、そのプリプロセッサの出力結果を渡したのじゃないかと思えてきた。だって、そうとでも考えないと300行とか500行とか巨大な関数を書けると思えないのだ。そうでなければ、きっと頭の構造が違うのだろう。頭のいい人はうらやましいな。
前日の作業の甲斐あって、例の巨大関数の動作が大体見えてくるようになった。動作が見えてきたので、20〜30行程度の下請けの関数を作って、機能分解出来る部分も出てきた。その結果、更に行数が小さくなってコメント付きで180行ほどになる。5〜6行に1つ程度のコメントが入っているので、実質150行程度に収まっている。まだまだ小さくできると思うが、とことんやったら原形を止めないくらいの書き直し作業になっちゃうので、この程度で止めておくのが賢明だろう。他にも読まなきゃいけないファイルは沢山あるし、、この分ではそのほとんどに今回やったような手入れをしなくちゃいけないだろうし。根性入れて書き直すとなったら、全部rewriteなんて羽目に陥りそうだもんな。さすがにそんなに元気はないし。(^_^;
ここのところ、長い関数に頭を痛めている話ばかりだが、私だってものすごく長い関数は書いたことがある。(多分200行程度はあったか?)やっぱり書いているうちに長くなっちゃうってのはあるかもね。書いている人にとっては一本道の何でもない所なんだけど、他の人が読むと「げぇ、長すぎて読めない!」みたいな。まあ、他の人の書いたプログラムをチキンと読むというのは面白いといえば面白いし。
そういえば、結構3年前くらいの話だが、Windowsプログラムを始めたばかりの時に、やたらと長い関数とか、ダーティーなコードを書いたような記憶がある。あれって、今どうなっているのかな。まだ生き残っているとしたら、書き直して欲しいなぁ。さすがにもう書き直ってると思うけど。(^_^;
私が引き継いだのはCで書かれたDLLなのだが、変数の「その場で宣言」方式とかが体に染みついているので、Cでは書きにくい。C++ソースにしてしまおうと思ってC++でコンパイルしたら、unsignedとか配列とかの絡みで沢山エラーが出てしまう。なぜ、C++で書かないのかなぁと思っていたが、そういった理由だったのかもね。(^_^;
一番多いエラーが、日本語文字列をBYTE文字列とみなすか、char文字列とみなすかとか、char *が引数なのに、配列を渡しているぞとかいう型のタイプに関する辺り。まあ、エラーの出る所で全部キャストしてしまうという単純作業でC++に移行できるのは分かっていたが、今の所は動いているソースをなるべく変えたくないという考えが強いし、CはCで、変数のその場での宣言も出来ない訳じゃないので、今の所はCで読み、Cで書き直している。遠からずC++で書き直すことになるのだろうか?あのソースファイル全部書き直すのかぁ?面倒だなぁ。(^_^;
今日は落語会の日。今回の演者は金原亭馬の助、伯楽。熱の入った好演だった。各々2席、合わせて4席話すのだが、前半の伯楽師匠の話は大変に熱がこもっていて50分弱話していたのだが、全く時間を感じさせなかった。会場がお寺の本堂で、畳の上に仮設の演台をつくってそこで演じて貰うのだが、客席最前列とは3m程しか離れていない。当然早めに言って前の席を確保するのだが、私の座っている所と演者とは4メートル程度しか離れていないので、迫力がびんびん伝わってくる。
会場に入った時に、落語会の25周年記念行事に呼びたい噺家さんのアンケートをもらう。24人のギャラが40万円以上の噺家を顔写真付きで紹介し、噺を聞きたい人にマルを付けるというものだった。で、そこに一席あたりの最低ギャラが載っていた。まあ大体40万〜80万という所だろうか。小さん、米朝、枝雀なんかが80万円だった。(枝雀は以前見たことがあるのだが強烈な印象を受けた。機会があったら一回彼の舞台を見て欲しい。)意外だったのが、談志や志ん朝のギャラ。今名人の志ん朝って以外と安いんだ。(^_^;別格なのが小朝。で、更に別格なのが三枝と文珍。確かに三枝はともかく文珍は一回生で聞いてみたい気がする。
以下、その資料に基づく噺家のプライスリスト。どこまで本当かは分からない。(^_^;
とんでもなく長い関数をいじっている。なんかよく分からないテンポラリをそこかしこで使っているし、とにかく長すぎて適当な分割どころがなかなかみつからない。とにかく意味不明のテンポラリ変数を排除し、マクロを使ったり短い関数を使ったりしているうちに、300行あったプログラムがコメント行30行程度を含めて、230行程度になった。もう少し短くしないと私には理解不可能なので、さらに関数に分解しようと思った。しかし、私が受けた単純な説明とは違って、もうちょっと技巧的なデーターの使い方をしているようなので、非常に戸惑う。お〜い、こんな風にリンクデーターを追いかけるなんて聞いていないぞ。(^_^;
金曜日から引き続いて、引き渡されたソースを読んでいる。金曜日にボディーが90行もあるソースファイルを読んでいたので、まあこれ以上読みにくい所はないだろうと思っていたので、読み進めて行った。ところが、金曜日の続きを読み進めて行ったらもっとすごい部分にぶち当たった。(^_^;
同じくCのソースなのだが、関数の始まりから終わりまで、300行近く(293行)ある。で、その関数の中の中身には、ボディーが80行以上あるwhileループが3つもある。(^_^;こんな馬鹿でかいwhileループなんて1つだけでも理解するのが厄介なのに、それが3つもあっては、そのままではお手上げである。頭を抱えてしまったのが、コメントの少なさ。300行のうち、コメント行が5行しかない。(T_T)その数少ないコメントの中に「設定(1)」という脱力もののコメントなので泣けてくる。(関数内の変数宣言には、簡単なコメントが付いていたのが。)で、とどめにこの300行あるSethlData()という関数に付けられたコメントがたったの一行「hlDataを設定する」。ひ〜。
これはコメントの付けなおしから初めて、少しずつ関数単位に分解して分かりやすくしたりしないと私には理解できないプログラムだとあきらめて、がりがり書き直しというか書き改め作業にかかる。まあ、全体像が理解できていないので、まずは部分的に簡単なマクロとか関数を使って、ここで3行、あそこで5行とか言った感じでちまちま等価コードで書き換えていって、アルゴリズムの本質的な所をあぶり出そうと言う訳だ。
とにかく何をやっているのか良く理解していないので、書き直しには慎重を期した。まあ、書き直し自体は私がアルゴリズムを理解するためにやっているのだし、失敗しても最悪書き直し前のソースを使えばいいのだから、気は楽だけど。
昨日から書いている論文、全然筆が進まない…。
社内論文を書かなくてはいけない。この論文で認められないと昇進できないと言う論文だ。でもなぁ、学生時代からそうだったけど、何か大切な事が間近に迫っているとゲームをやりたくなったり本を読みたくなったりするんだよなぁ。(^_^;