家にいるとなんだかんだと親がうるさいので(^_^;外出。とはいっても疲れ気味なので遠出はしたくない。結局スクーターで行ける範囲の本屋とかゲームセンターにしか行けない。で、さらに田舎町なので、行くような所もそんなにない。(^_^;こんな時は普通はどうするものなんだろうなぁ。(^_^;
結局、仕事をするわけでもないのだから行くもんじゃないと分かっていても、ふらふらと会社に足が向いてしまう。(^_^;情けないことだけど、「タダで」「座れる場所があって」「長いこといても嫌な顔をされず」「そこそこ遊び道具(つまりコンピュータとネットワークアクセス環境)がある」というと、会社しか思いつかなかった。(爆)
状況からすればお仕事をしたほうがいいんだけど(^_^;、行く所がなくて結局仕事をしているなんてのも間抜けだし、結局ネットニュースとかWWWページとかを眺めて一日過ごす。
休日出勤。OEM提供元から送られてきたヘルプファイルにコメントを(英語で)付けていく。こっちの翻訳もかなりぼろぼろなのだが、この翻訳部分は何人かの協同作業らしくて、「結構いい感じじゃん」というところと、「この章、全部リライトじゃぁ(大激怒)」というところが混在している。もっとも一番いい感じのところでも相当手を入れないと市場に出せるようなレベルではないのだが。そもそもこのプログラムってもともとはロシア語圏で開発されたらしくて、それを英語に翻訳し、その英語に翻訳したものを更に日本語に翻訳したらしく、英語のヘルプを見てもなんか変なことが書いてある所がある。その英語を単語単位で逐次翻訳している感じなので、出来上がった日本語訳は何を言いたいのかさっぱり分からないところが続出する。(^_^;
で、そういう「変な日本語」を何回も長時間読んでいると、なんだかこっちの日本語まで変になりそう。もっとも、もともと私の日本語はそんなにまともじゃないけれど。(^_^;;とりあえず急いで目を通したので不十分な所もかなりあるが、いちいち指摘していったらいつまでかかるか分からないし、本当は評価レポートの締め切りが昨日だから仕方がない。次に送られてくる時にはもっとまともな翻訳になってくれればいいが。
Iさん、Sさんも休日出勤。昨日の牛丼の賭けの話をネタにしてIさんをからかう。「これからこの会社にいる間、ずっとこの話をネタにしてからかわれるのか」と、Iさんが苦笑する。いいキャラクターだよなぁ。(^_^;
水曜日あたりに、TWAINの仕様書を読んでいる新人のKさんが「ネイティブモード」という単語で引っ掛かっていた。私はTWAINの事はよく知らないのだが、多分インテル系のCPUの動作モードの「ネイティブモード」と何か関係があるんじゃないのかと口をはさんだ所、Iさんを巻き込んで一体それは何だという話になった。でもそれを説明するには8086の時の話から始めないと、リアルモードでプログラムを組んだことのない人には分かってもらえまい。第一私だってよく分からん。(爆)実際、詳しく話しはじめると長くなるので、「あとでその辺の事情が書いてある本を渡すから」とその場はお茶を濁しておいた。
で、今日になってやっとその本を自宅から持っていた。(持って来ようとしても朝はボ〜としているから忘れちゃうんだよね。(^_^;)たまたま物をとりに出社してきたKさんに富士通うんちゃらとかいう所から出ていた「ザ・80386ブック」とかいう、大学時代に80386の勉強をする時に使った本(とはいっても、その時には386マシンなんて高くて手に入らなかったから、本当に読んだだけだったが)を渡した。まあ、今はアプリケーションプログラムを書く時にCPUアーキテクチャーを強く意識して書くなんて時代じゃないから(組込型だったら話は別かもしれないが)、読んでも役に立たない可能性大だが、知っていたら損をするという性質のものでもなかろう。
もちろん、その後のCPUの技術革新は目覚ましく、分岐予測とかキャッシュとかベクタ処理とかパイプラインをうまく詰めるためのテクニックとか、それらをサポートするコンパイラ技術とかなどに関しては、その本には何も書かれていない。そんな訳でもう一冊「Hi-Performance Computing」という本を副読本として用意しておいたのだが、一人で同時に2冊も読める訳じゃないので、こっちはIさんに貸すことにした。まあ、この本に書かれている内容も、知っていたから得をするなんて可能性が低いことは確かなのだが、逆に知っていたから損をする可能性は考えられないのでまあいいか。
本当だったら「プログラム書法」を読ませたい。しかし、FORTRANやPL/Iで書かれているので勧めにくい事情がある。実は書いてあることは今でも充分に通じるところがあって、今での私の愛読書の1つだし、この本を読むためだけにPL/Iを(コンパイラが手元になかったのに)勉強したので、思い入れもある。「プログラム作法」ならRATFORで書かれているから、Cしか知らない人でも読みやすいのかもしれない。でも「作法」は分厚い本から読み切るのは並み大抵の根性じゃ無理だし、悪夢のようなFORTRANのFORMAT文からは逃れられないし。(^_^;←半分くらいはちゃんと読んだが、後の半分はざっと目を通すだけで挫折した奴。
とうとう、このページのアクセスカウンタが10000を突破。Sさんのメールでそのことを知る。私がアクセスした時には10004だった。あやうく自分でジャストナンバーをゲットする所。(^_^;見事10000をゲットした方、ご連絡いただければ何かプレゼントが出るかもしれません。(^_^;更新を続けている(といっても最近サボりがち)私が偉いのか、飽きずにアクセスしている読者が偉いのか。私が偉い訳ないか。(^_^;どうも読者の皆様、ありがとうございます。<(_ _)>
OEM作業。調べれば調べるほど翻訳がぼろぼろな状態なので泣けてくる。結局ローカライズに関して問題のある部分、翻訳に難のある部分、マニュアルの翻訳に難のある部分を相手先に送ったのだが、とにかく翻訳部分で問題点がありまくり状態で、最初はある程度きちんとしたレポートにまとめようと思ったのだが、これだけ翻訳上の問題点が多すぎると、とにかく「この日本語って変じゃない?」という所を手当たり次第指摘するだけで精一杯。
私の最初の目論見では一ヶ月位やらせてみて中間結果を見て、大雑把な方向性を修正してあげれば、いくらなんでもひどいことにはならないだろうと思っていたのだが、結局営業サイドへの見通しの妥協、OEMサイドへの妥協を繰り返した結果、2ヶ月以上も放置して、結局βが出来上がってからの評価期間が月曜日から金曜日の5日。で、その評価期間が作業上のトラブルがあって、評価期間は実質3日。こんな期間では、本来まともな評価が出来るわけがないのだが、予想に反して結構まともな評価が出来たと思う。私の評価結果「βレベルに値せず。」とにかく翻訳がぼろぼろ。3日間で150ヶ所以上も翻訳/不自然な日本語に関する指摘が出てくるようでは、その程度の評価もやむを得ないと思う。実際、もうほとんど全部にリライトをしたくなってきている。プログラム自体は結構よく出来ていてあとは翻訳とか、その翻訳を自然な日本語にすれば結構いい感じに仕上がるだろうなというな感触なだけに、検査をしている立場からすると翻訳の稚拙さがかえって目立つ。まあ、「119を構築します」という翻訳を見た時点でどう頑張ってもまともな翻訳は望むべくもないというのは分かっているのだけれど。(_ _)ア〜ア。
性格診断テスト。Sさんが「石橋貴明と鈴木保奈美(おお、どちらも一発で変換した。なんちゅうIMEなんだ。>WXG (^_^;)が結婚したって俺が言ったら信じる?」とIさんとKさんに聞いた。Kさんは「どっちでもいいから、Sさんを信じます。」と答えたが、Iさんは「そんなの嘘に決まっているじゃないですか。」と全然信じていない様子。Sさんの挑発もあって、Iさんは「それが本当だったら牛丼をおごりますよ、Sさんも何か賭けてください」とまで言い出す始末。私は既にその情報が正しいと知っていたので、面白がって「じゃあその賭けに私ものろう。Sさんが正しい方にしゃぶしゃぶ食べ放題。」と言ったら、やすやすと賭けにのってきた。当然その情報が正しいと知っている他の何人かもその賭けにのってくる。
数分してからNさんがWWWページのニュースをプリントアウトして持ってきた。その紙を読んだ時のIさんの呆然とした顔つきといったらなかった。私にしては珍しく大声をあげてげらげら笑う。まあ、私の分ははっきり八百長なんだけど、滅多に賭け事なんかしない私が大いに乗り気になって賭けにのった時点でおかしいと気がつくべき。何にしても賭けは賭け。まだまだおぬしも青いのぅ。>Iさん。さて、いつ牛丼をおごってもらおうかな?(^_^
OEMの作業。相手は海外の企業で、主な作業は英語バージョンのリソースを日本語へ翻訳する作業で、私はその作業の進捗をチェックし、受入検査の作業をする立場だ。ところが、向こうから送られてきたβバージョンの日本語訳が「すごくて」手を焼く。なんか1つ機能を試すごとに、「とほほ」な訳にぶち当たってその度にその誤訳をレポートにしないといけない。おかげで全然テストが進まない。アバウトダイアログのビルド表示、英語表記で"Build 119"を「119を構築します」と訳している箇所を見つけた時には、なんかざるで水を汲んでいるようなむなしい作業をしているだけなんじゃないかと思って心底がっかりした。あ、もっとよい喩えがあった。「vyamaにビール。」(^_^;
発売日から1日遅れでStarTrek VoyagerのLDを入手。家に帰ってから日記も書かずにそれを見まくる。
OEMの作業。相手先のFTPサーバーから落としてきたファイルでインストールをしてみたが、どうもうまくいかない。相手先に聞いてみると、何かファイルを落とし忘れていないかという返事。よくよく調べてみると、1つファイルが足りなかった。相手先に平謝りに謝って(といっても今回はこっちがクライアントサイドになるので、かなり横柄な謝り方なんだけど。(^_^;)、許してもらう。
プログラムを動かしてみると、結構こっちの思惑通りに動いてくれなかったりして、クレームのメールとか、問い合わせのメールを何通も送る。ところが相手は日本語が分からない人なので、それらのメールは全部英語で問い合わせないといけない。(^_^;昔から英語はそんなに得意じゃなかったので、言いたいことがなかなか言えない気がするし、大体向こうも英語が母国語じゃないので、言えたとしてもちゃんと伝わっているか怪しいものだ。(^_^;まあ、その意味では向こうだって言いたいことが言えているか怪しいかもしれないが。(^_^;;
受け入れるプログラム自体は英語版があって、基本的にはメッセージなどのリソースを日本語訳するだけなんだけど、1時間ほどいじっていて細かく数えると40ヶ所くらい「なんだ、これは?」という翻訳箇所や日本語として全然意味が分からない部分を見つけた。この調子じゃ本格的にチェックしはじめたらどれくらい変な訳があるか分からない。かなりげんなりする。これ、制定までにあと1ヶ月しかないんだよなぁ。
ちゃんと翻訳できているなら、RTFモジュールのコーディングに集中できるのだが、この状態じゃ、とてもじゃないけど今週一杯はOEM作業に掛かりっきりにならざるをえない。勘弁してほしいよなぁ。
Nさんの具合が相当ひどい。朝からずいぶん咳き込んでいる。さっさと休めばいいのにと思うのだが、連絡事項とかがあって休めないらしい。お気の毒に。もっとも相当体調が悪そうで、連絡・指示を与えてから2:30くらいに帰宅。明日、明後日は体調不良で休むとのこと。お大事に。
OEMの作業。プログラムの提供先からβ版が上がっているとの連絡を受けて、早速FTP経由でβ版を取り寄せる。ところが全然転送がうまくいかない。まあ、かなり巨大なファイルだったのだが、どうしても10Mほど転送した所でパケットが届かなくなってしまう。何回かやって駄目だったので、プログラム提供先に「でかすぎてうまく転送できないから分割してくれ」とメールを出す。返事は比較的早く届いたのだが、それに気が付いたのがもう帰る寸前の出来事。一応転送プログラムだけ立ち上げて、夜のうちに転送しておくことにする。今度はうまくいけばいいが。
そういえば、Communicator 4.5 の日本語版が公開された。早速ダウンロードしようと思ったのだが、こっちのダウンロードもうまくいかない。どうしても途中で転送が止まってしまう。やっぱり大きなファイルは会社のみんながWWWサーフィンに忙しい昼間じゃなくて、夜にやらないと駄目かな。(^_^;
今日はそのベータの評価をするつもりだったのだが、結局βが手に入らなかったので、あきらめてRTF出力モジュールのコーディングを行う。今日は実際にファイルに書き込む部分についてのコーディング。元のプログラムは_write()とかを使って、自前でバッファリングをしていたのだが、そのバッファリングのやり方が下手くそで、バッファリングを制御する変数をプログラムの至る所でいじらなくちゃいけなくなっている。RTF出力するなんて、どうせ大して時間がかからないはずなんだから、多少遅くてもOSのバッファリングに頼るか、標準I/Oのバッファリングに任せてしまったほうがいい。iostreamはちょっと自信がなかったので(あれってフォーマット付き出力って出来たっけ?)、使いなれたFILE構造体による出力に書き直しはじめる。
面倒だったのが、エラー処理。書き直す前は_writeが呼ばれる比較的数が少ない場所でだけエラーチェックをしていればよかったのだが、今度はfputs()とかfprintf()とかを呼ぶたびにエラーチェックをしなくちゃならない。これじゃあ面倒。もっとも元のプログラムはバッファーオーバーランの危険性もあったし、出力するたびにエラーチェックをする方がよっぽど見通しがすっきりするので、後戻りする気はさらさらない。しばらく考えて、どうせC++で書いているのだから、C++の例外処理機を使おうと決めた。どうせ処理しなくちゃいけない例外はfputs()とかのC標準ファイル出力ライブラリだけだったので、
int Myfputs(LPCTSTR pStr, FILE *fp)
{
int nLength;
if ((nLength = fputs(pStr, fp)) < 0) {
thow 例外オブジェクト
}
return nLength;
}
そんなこんなとやっていたら、やっと4つの修正予定の.cppファイル(もともとは7つあったが、そのうちの3つは捨てるつもり。)の最初の1つのファイルの修正が完了した。(動作チェックをしていないので完全には終了していないが。)この最初のファイルの修正前と修正後の行数を比較してみたら、修正前が3200行程度で、修正後は1300行程度。修正前のプログラムはCで書かれていて、修正後のようにファイル出力エラーをC++の例外処理を使って簡単にすることができなかったという不利な面はある(でもそれだったら、setjmp/longjmpを使えばいいのだ)にせよ、修正前のプログラムは本来やるべきことの2.5倍近く膨れ上がっていたことになる。
このペースで行ったら、7つあったファイルのうち3つを捨てることはほぼ確実だから、修正前のプログラムは本来やるべきことの3〜4倍の量を書いていることになる。これじゃあ読みにくいと思うのも当然だよな。ちなみに今日は処理に重複した部分が少なかったせいで400行程度しか削除できなかった。(^_^;
今日目にした珍しいコーディング。変数WORD wFlgFlg。まあ、名前のいい加減さはいつものこと(^_^;なので気にしないでおこう。で、何故フラグなのに型がWORDなの?本当はフラグじゃなくて、何かのパターンを表しているんじゃないのか?と思って読んでみたが、やっぱりTRUEとFALSEしか値を取らないみたい。じゃあ何故BOOLにしないんだろう?まさかBOOLよりWORDのほうがコンパクトだからなんて考えている訳じゃないだろうし。(2byte alignを採用するなら別だけど。)
目が覚めたら、夕方だった。(^_^;
なんだか知らないが、やたらと体調が良い。体調が良いから機嫌もいい。いつもより3時間ほど早く目が覚めて、いつもだったら大抵寝ぼけ眼で、もう一眠り…と行く所だが、なぜかちっとも眠くない。気分がいいので、どこかにドライブにでも行こうかな?と思ったが、そういえば今日は出社する日だったっけ。ちぇ。(^_^;で、3時間も早く起きたのに、猫をからかって遊んでいたら、結局出社時間はいつものとおりになってしまった。(^_^;
うちの会社では、土曜日出社なんてのは大体みんな嫌がるモノなので(スケジュールが押し詰まっていればそんな事も言っていられないが。)、前の部署では結構年休なんかを使って休んじゃう人が多かった。ただ、今回はさすがにクリスマス商戦前ということもあるせいか、結構出社している人が多かったような気がする。私の課は全員出社していた。まあ、αが目の前に迫っているから当然だけど。(^_^;
ちなみにパッケージソフトウェアの新製品をかきいれ時のクリスマス商戦にぶつけようと思ったら、最悪12/15くらいには発売しないと店頭に並ばないので、CD-ROMをプレスしたり、パッケージを作ったり、流通に流したりの期間が2〜3週間だとして、11月末にはプログラムが完成していないとどうにも間に合わない。だからそういったボーナス商戦を狙った製品に関わっているプログラマーは、その1月くらい前が一番忙しいことになる。もっとも今日はどこの部署もスケジュール的に厳しいことになっているから、おちおち休んでいられないという所だろうと思う。
取り組んできるプログラムは、1関数100行以内という「掟」を守るのはあきらめた。ただし、対になっている、良く似た200〜300行以上ある2つの関数を何とかまとめる作業と局所的(10行程度)によく現れる表現を関数にまとめる作業だけは続ける。(それだけでも相当分かりやすくなったのだが。)対になっている関数というのはとっても似通っていて、200行以上あるのに違う所がせいぜい20%か、下手をすると5%以下しか違わないんだけど、後で修正するにしろ、「経験的」などという恐ろしいロジックがプログラムの中に入っているらしいので、いったんは修正前と修正後とで同値なプログラムにしなければいけない。やっていてひどく消耗する。結局今日もその作業をしていって1000行ほど削ったのかな。前任者は「おお、今日はコピーとちょっとした修正で1000行も書けたぜ」と喜んだ日があったかもしれないが、後任者の私がそれをせっせと削除している訳だ。何のことはない、前任者が手を抜いた部分を今になって私が必死に尻ぬぐいしている訳だ。勘弁してほしいぞ。(-_-;これが新人研修の課題だったらまずまちがいなく書き直しを命じている所。
日曜日にメンテナンスのため会社がある雑居ビルが停電になるので、それに合わせて19:00にサーバーがshutdown。かなり制約があって作業効率が落ちるにせよ、仕事を続けられないわけでもなかったし、やらなきゃいけない作業は目白押しだったんだが、とりあえず逃げる口実が見つかったので(^_^;、さっさと退社。
「封神演技」(講談社文庫)を何とか読み終わる。最初は面白かったのだが、後半はやたらと人名が出てきて、出てきたと思ったらあっさり殺されてしまうの繰り返し。仙人界の最終決戦なんてたった10行ほどで150人ほどの仙人が殺されて「封神名簿」(戦死者名簿)に並べられる。で、登場人物のほとんどは死んじゃうし。でもマンガの「封神演技」とはずいぶん違う…。ま、あれはあれで面白いけど。
信濃毎日新聞。あいかわらず変な読者投稿を載せている。商品券をばらまくっていう企画もなんだかなぁと思っていたのだが、この投稿は「商品券じゃなくて旅行券を配れ」という主張だった。そんな特定業種が儲かるようなものをばらまいてどうするんだ?いや、これを書いた人を責める訳じゃない。それを採用した新聞社の記者なり従業員の頭の中が腐っているんじゃないのか?というわけである。だから新聞はおもしろい。変なことを探すんだったら、結構新聞は格好なのである。こんなひねた新聞の読み方をしているのは渡しだけかな?(^_^;
ふと気になって、調べてみると来週Star Trek Voyagerの1stシーズン Vol.2が発売される。早速昼休みを利用して、予約に走る。
プログラムのほうはかなりつらい作業になっている。とにかく元のプログラムが読みにくすぎて、意図がはっきりしない部分が多すぎる。やたらと長い、ちょっとだけ違う関数(150〜400行)なんてのがゴロゴロしているし、中には名前以外全く同じなんて関数もある。(^_^;目についた不自然な表現を片っ端から書き直したり、関数の中で繰り返して現れる表現は別の関数に分離して見通しを良くし、ちょっとしか違わない関数は一本にまとめて、片方を捨てたり、長すぎる関数は分割してせめて100行程度に収まるようにした。多分、今日だけで1000行以上廃棄して、同じくらい書き直したと思う。で、書き直した部分もコメントをたっぷり入れて、分割した部分まで含めて修正前の70%くらいに小さくなっている。ほとんど休憩を取らずに作業をしたので、さすがに疲れた。これでもまだ全然作業が終らない。あ〜あ。
今日目が点になったコード。その1。if … else … の多重ネスト攻撃。if … else … のネストが4重くらいになっていて、最初のif … else …ブロックの長さが80行近くになっていた。なんとかそのブロックを分解して分かりやすくしようと思ったのだが、私の頭が悪いせいか分解どころか意図すらもつかみかねた。仕方がないのでその部分は「修正不可能。元気のある人は書き直してね。」とコメントを付けて終わりにした。
その2。70行ほどある関数だったが、8つある自動変数の6つにプリフィックスTmpがついていた。で、その6つある自動変数の全部が関数内で使われまくっていてちっともテンポラリ変数じゃないのである。(^_^;で、残りの2つの変数はループカウンタに使われていたのだが、変数名が wIと wJ。なんだかなぁ。(^_^;
さすがに、11時間もひたすら寝ていたら、かなり体調が復活してきた。まだちょっとお腹がゴロゴロするけれど、昨日よりはずっといいし、食欲も出てきた。出社して、昨日集中できなかった分を挽回すべく頑張る。
金曜日から取り掛かっているテキスト出力モジュールは、今回データ構造が大きく変わった部分以外はデバッグを含めてほぼ終了。今回データの表現が大きく変わった表出力部分も出力先がテキストだけに、あれこれ余計なことを考える必要がないので、30分ほどであっさりコーディング終了。で、早速動かしてみると…、やっぱり動かない。(^_^;まあ、新規部分が一発で動くなんてことは期待していなかったので、早速デバッガで追いかけてみたら、どうやら親モジュール(これは別の人が書いている)から渡されるデータに問題があるらしいということが分かった。とりあえずそこまで分かったら、一通り机上デバッグをして、いったん作業を終了。今日追加したのは70行程度だから、一通りの机上デバッグができていればそんなに醜いことにはならないはず。(と信じよう。(^_^;)
一通り作業が終って、全体を眺めてみると、DDE用にメモリに結果を吐き出すルーチンと、ファイルに結果を吐き出すルーチンのロジックがかなり似ているので、何とかそれを統合できないか考えてみる。これまでの作業はどちらかと言えば「局所的に同値で、読みやすいものに置き換える」という作業だったが、これを統合するとモジュール構成ががらっと変わってしまう。どうしようか1分ほど悩んだが、やっぱり統合することにした。ちょっと手間取ったが、思っていたよりは簡単にできたし、ソースファイルもかなり短くなったので、ずいぶんすっきりしたプログラムになった。一応は満足。
次にRTFファイルの出力モジュールに取り掛かる。こいつは以前日記にも書いたように、よく似ているけどちょっとだけ違う、しかもやたらと長い関数が延々並んでいたり、200行以上もあるif とか for ブロックがバシバシ出てきたり、変数名が変だったりと問題がありまくりの部分だったので、もう最初からほとんど書き直しになるだろうな、と覚悟してやった。まあ、イメージがらみとか、表がらみで相当変更が入る予定だし、あのままじゃ、とても恐くて修正できない。(^_^;もっともここさえうまく出来てしまえば、後はここで作った下位モジュールがかなり再利用できるはずなので、多分これが最難関。
案の定、モジュールのエントリーポイントから、バシバシ修正が入る。1つの関数で繰り返し現れる表現を関数にまとめたり、多少計算は冗長になるけど意図が分かりやすい表現に書き改めていったり、長くてネストが深いif連続技を、条件判定を逆にしたネストが浅くて短いif連続技に変えたり…。そうやって、意図を明確にしたり、短くしたりすればするほど、その関数のやりたいことがはっきりしてきて、2つの関数を1つにまとめたほうがいい部分とか、バグじゃないの?というところが見つかる。バグじゃないかと思える所はよほど直そうかと思ったが、過去のプログラムの動作との整合性もからんでくるので、丁重にコメントを付けてそのままにしておいた。加えて、廃止予定のWin16 APIを使っている所をWin32 APIで置き換えてやったりしていたら、それだけで一日終る。
そういえば、スケジュール通りにやるとすると…、私は来週からOEMの作業に掛かりっきりにならないとまずいはずだから…、あと2日で3.5万行ほどプログラムを書き換えないと間に合わない計算になる…。もう笑ってごまかす算段をしないといかんな。(^_^;
そういえば、今日も上司のNさんはお休み。懸案だった上司の承認印は部長からもらった。今年のカゼは質が悪いらしい。「バカはカゼにかからないから、私は大丈夫。v(^_^」とKさんに言ったら、「今年のカゼはバカでもかかるみたいですよ。」とのこと。むむ〜。(^_^;
体調が悪くて、ここ2〜3日、ろくにモノを食べていない。今日もあまりモノが喉を通らなかった。仕事にも集中できなかったので、早く帰るつもりだったのだが、飲み会のお誘いがあったので、とりあえず出席。
飲み会では、出張で松本に出てきた友人の迎撃宴会で、参加者は私も含めて3人。話は結構盛り上がったのだが、ビールを飲んでも、つまみを食べても美味しくない。だんだん疲れてきて、途中で退席。うちに帰ってもあまり食が進まず、ばったりと寝こむ。
そういえば、今日は上司のNさんがカゼでお休み。部長も社長も出張だったので、上司の誰でもいいから、承認印が欲しい件があったのだが、それは明日に持ち越しとなった。
ちょっと髪の毛が伸びたし、パスポート用の写真も取らなくちゃいけないので、床屋に言ったのだが、あいにくどこもお休み。あちこち捜し回ったのだが、どこもかしこも休みと来ている。何故?スクーターで捜し回ったのだが、おかげですっかり体が冷えてしまった。
結局近所の美容院に言ってカットと洗髪だけしてもらう。この歳になって初めて美容院なる所に行ったのだが、あおむけになって洗髪するというのはなんか不思議な気分だった。
今日はお休み。旅行中に飲み過ぎたのが響いて、完全に二日酔い。それでも、パスポートを取るための書類を準備した。
旅行から帰ってきた。旅行先で効いた「オケサ音頭」のメロディーが頭から離れない。(^_^;