未来のいつか/hyoshiokの日記

というわけでよしおかです。http://www.miraclelinux.com/ というところでCTOをやってます。最近では中国の紅旗リナックス http://www.redflag-linux.com/ 、韓国のハーンソフト http://www.haansoft.com/と戦略提携をして共同でCommon OS Platformを開発する Asianux Project http://www.asianux.com/ というのをやっています。

Linuxの専業ベンダーですので、オープンソースで飯を食っていると言ってもいいかもしれません。オープンソースで飯を食うなんて事は、少なくとも自分自身としては数年前には考えられなかった事ですので、環境の変化そのものに戸惑いもなくはないですが、この環境を楽しんでやってます。

90年代中ごろまではOSを商売にするなんていうことはIBMやマイクロソフトあるいはSunあるいはAppleというような大企業以外ありえなかったわけで、その意味ではMiracle Linuxのような非常に小さい会社がまがりなりにもOSをビジネスするというのは誰が想像したのでしょうか。奇跡だ。てな感じですね。

Miracle Linuxを立ち上げる前は日本オラクルというところにいてOracle RDBMSのサポートをしていました。その前にはシリコンバレーにある米国Oracle本社でOracle RDBMSカーネルの開発をしていました。SQLの言語プロセッサをごりごり書いていました。ごりごり。シリコンバレーはわたしに多大な影響を与えた事は間違いないです。ソフトウェアの作り方とかプログラマの生き方とかあるいはオープンソースというのもの黎明期を見た事は、わたしの人格を形成するうえで。

さらにその前は今はなきDECという会社にいました。DECのソフトウェアの国際化かなんかをしこしこやっていました。そのころに文字コードと接近遭遇したおかげでiso 2022がどーしたとか、Unicodeがどーした、iso 10646がどーしたなんてことを口走っていました。

大学院を修了したのは1984年ですから今から20年前で初代マックが発売された年でもあるんですね。

ということでツレヅレなるままに自己紹介などをしてみました。なんだか履歴書というか仕事関連ばっかの話で面白くもおかしくもないですね。すいません。

CNET JapanのゲストBLOGが面白い。http://blog.japan.cnet.com/umeda/archives/001893.html はてなの伊藤さんが書いているが、その前の宮川さん、高林さんとの一連のBLOGの流れで読むと非常に面白い。

改めて振り返ってみると、高林さんや宮川さんや私は年齢がほとんど離れていません。77年生まれ、あるいは76年生まれです。そして前回の記事でも紹介したGREEの田中さんも76年生まれ。2ちゃんねるを管理する西村博之氏も同年代。はてなの代表近藤淳也は75年生まれ。近頃インターネットを騒がす人々は共通して70年代後半生まれだったりします。

いい感じの世代感である。日本のギーク達が個人として発言している。その肉声を聞く僥倖に立ち会っているような気がする。

彼らが産声をあげたころ高校の部室でペンキを塗っていた自分という存在が実に面白おかしい。

最近コードを書いていないので、コードを書きたい書きたいと思っているのだが、時間を見付けるのが難しいなあ。(てなことを言ったら、/homeの下のファイルを全部消してしまうような人はコードを書くのは禁止とか言われてしまった。そりゃないぜ、セニョリータ)

プロの作家の本を読みたくなって、大沢在昌「心では重すぎる」を買う。大沢の作品と言えば、「新宿鮫」くらいしか知らないのであるが、第十九回日本冒険小説協会大賞というのに引かれて買ってしまった。

■ 高校のころ

1970年代の中ごろの話である。日経サイエンスという雑誌があってそれにIC(集積回路)の写真が載っていた記事を読んだ覚えがある。マイクロプロセッサとよばれるコンピュータの心臓部分の写真だった。インテルの4004だか8008だかあるいは8080だかは忘れたが碁盤の目のような写真は美しかった。

当時わたしは高校の数学研究会という何をするかわけのわからないクラブに入っていて放課後とりあえづわけもなく部室にいき部室の壁にペンキを塗ると言う作業を誰に言われたわけでもなく特に情熱もなく行っていた。退屈をしていた。

付属の高校だったので受験勉強をしないでもとりあえづは大学に行けると言う恵まれた環境にいたため学校の勉強をまじめにしたと言う記憶はない。

大学にはメインフレームコンピュータ(いまはなきUnivac製のコンピュータ)があって、いくばくかの利用料金を払うとそれを自由に利用できるという特権を我々は持っていた。コンピュータのプログラムを作ると言うのはパズルを解くような不思議な魅力があって、同好の連中が数学研究会に集っていた。数学の成績はさっぱりだったがコンピュータプログラムを作ることは嫌いではなかった。大学のコンピュータプログラムの講座を履修したりした(勿論単位にはならない)。COBOLやFORTRANやLISPといった古典的プログラミング言語を習ったのはそのころである。

そしてマイクロプロセッサが世界を変えると言う予感だけは強く持っていた。いつの日か自分専用のコンピュータを持ちたいとも思っていた。当時自分専用のコンピュータを持つと言う妄想を持つ高校生というのはそれほど多くはないだろうが「数学研究会」の連中はそんな連中であった。高校３年の時に何人かの新入生が入部した。その一人に梅田望夫という男がいた。20年後にシリコンバレーで再開した。

先日学生時代のしかもサークルのOB会なるものに出席した。毎年学園祭の時期にOB会がある。大学近所の中華料理屋で昼間から集まっていい感じでへべれけになったころに一次会はお開きになる。その後学園祭に流れ後輩の展示などを冷やかしつつ県人会で酒をまたまたしこたま飲むというのが例年のパターンである。夕方にはすっかりべろんべろんで正体がなくなっている。学生時代からほとんど変わらない秋の過ごし方である。

T谷のお嬢さんは今年大学一年生だとかうちの娘は中学二年生で部活がどーだとかいう話をしつつ子供の成長によって時の経つのを確認するというのがOB会の趣旨でもある。(本当かいな)

今年は紅一点のAコがいたせいか県人会にはいかづピアノクラブでお茶をにごし昔話に華をさかせつつ、若い子は綺麗だなあ…と皆に同意を求めているのであった。実際みんな可愛かったぞ。しかし今年のOB会の女子の参加が少なかったのは残念である。みんな来年は参加してね。

■ ギークと語る

OB会でいい感じになったその足で渋谷方面に向かってギークの皆様(ほとんど初対面)と怪しげな(うそうそ)会合にでる。

Perlの達人とかRSSがどうだとかBLOGのサービス実装しちゃったやつとかSNSを立ち上げたやつとか日記とかとか。シリコンバレーから出張で帰国している昔の友人のネットワークで若い人達と一緒に話をする機会を得られた。感謝したい。

そこでいろいろ面白い話が出たのであるが、忘れない程度にキーワードだけを拾っておくと、「東京という地域の優位性」、「日本語で技術が語れる幸せ」、プラットフォームのレイヤーをOSでみるのか、アプリケーション層でみるのか、誰にもまけない技術優位性をどのように確保するのか、そもそもそのような事は可能なのか可能ではないのか、Amazon/Yahoo的な優位性なのかGoogle的な優位性なのか。

Googleの東京R＆Dセンターの話も出ていたけど、可能ならば見学に行った方がいいかもしれないというような結論になったようなならなかったような。

PHPとかPerlとかApacheとかのコミッターが日本にも何人かいるということを教えてもらった。あんまり意識したことがなかったけど、アプリケーションのレイヤーでの第一人者をいろいろ集めて技術的なコラボレーションとかできたら面白いなあと思った。セミナーとかそーゆーんじゃなくてちゃんとした技術的な案件でのコラボレーション。運用とか実装とかチューニングとか、そーゆーよーなお話でね。適度によっぱらっていたので妄想は尽きないのではあるが、最後にはやっぱしOSのレイヤーも含めていろいろやりたいよなあ、どーでしょうか、若いギークの皆様？

忘年会のシーズン間際だが(早いかな)お酒の席のお話。わたしは実はお酒には弱い。そーゆー事を言ってもなかなか信じてくれる人は少ないのだが本当に弱い。すぐに赤くなる。ビール一杯で真っ赤である。数杯ものんだらへべれけである。極めて効率がよい。

無理矢理飲む事を強要する人がいたりすると極めて困る。さすがに最近はそーゆーことは少なくなったが大昔はイッキとかあって無理矢理飲ませる事があったりして極めて野蛮な時代であった。危険ですので良い子は真似をしないように。無理強いされるといっきに酒がまずくなるので、やめてほしいと思う。飲む自由、飲まない自由があると思う。

ところがである。最近中国の人と仕事をするのであるが彼らの酒の飲み方は一昔のサラリーマン映画の中にあるような無茶な飲み方で、やたらイッキをさせたりしたりするのである。わたしとしては、かんべんしてほしいのであるが、もー無理、ダメと言っても、まあまあまあ、飲みましょう飲みましょうの世界である。さらに韓国の人達も加わっちゃったもんだから、おーさわぎ、彼らもイッキ飲みの世界である。ひーん。多勢にブゼイの世界である。しょうがないからトイレに駆け込んでうぷっと戻したりする。(すいません、汚い話で。特にお食事中の方)

自分の嫌な事は人にはしないという原理原則を持っているので、お酒の席で他人に酒を無理矢理勧めたりはしていないつもりだが、グラスが空いていたりすると「あ、何かいかがですか？」などと聞いてしまったりする。これは社会人になって接待の席でお客さんのグラスが空いているのに自分だけがばがば飲んでいていーきになってしまった時、そのお店のママさんにお客さんが帰った後、「お客さんのグラスが空いているのに気がきかない」と教えてもらって以来の習慣である。

「あ、何かいかがですか？」は別に強要はしていないつもりなのだが、ひょっとしたら無言の圧力にとる人がいなくもないような気もしないでもない。積極的には飲みたくもないのだが、まあ飲む事にやぶさかではない、みたいな、あいまいな世界である。大人なんだから飲みたくない時は、「あ、まだ結構です」とかきっぱりすっきりいきたいものである。わたしは飲まない自由は尊重したい。やっぱり楽しく飲みたいからね。

若いころは自分の限界をまだ十分に把握してなくて非常に速いペースでかぱかぱやっちゃったりして、後でありゃ失敗みたいなことがなくはないかとは思うが(あ、今でもそーか＞自分)、まあそこはそこ、大人として楽しく飲むワザを学びたいものである。

■ クリスマスツリー

赤坂見附のクリスマスツリー。平和である。クリスマスの想い出についてはそのうち記すかもしれない。

■ お題リクエスト

さっそくお題リクエスト(？)を頂く。ありがたいことである。

バグ／仕様、品質とかの話はぜひおいおい書いて行きたい。80年代の日本的品質管理というのはいったいソフトウェア開発ではどこにいっちゃたんだとか、現場のQCサークルとかはどーなったんだとか、工業製品ではめちゃくちゃ国際競争力があるのに、車とか家電製品とか特にね、ソフトウェア製品の国際競争力のなさってのは、どーゆーことだとか。日本から世界に輸出されるようなソフトウェア製品って何かありますか？とか。あるかもしれないけど、なさすぎというのが実感とか。

一方でシリコンバレーから世の中を席捲するおびただしいソフトウェア製品がこれでもかこれでもかとでて来るのは何なんだろう？どこに違いがあったどこに違いがないのか？

しかし上の設問(シリコンバレーの競争力みたいなお話)は、そーゆーことを知ったかぶりして書くというのもわたしの目指すところでもないので、多分書かない。シリコンバレーモデルということについては評論家の先生に任せるとして、わたしがわたしの知っている範囲で見たものを書くような予感がしている。

OSS(オープンソースソフトウェア)については書かなければならないと思っている。どーゆー切口で行くかは考え中。

■ 95/8/31のシリコンバレー日記

http://web.archive.org/web/20000520032645/www.best.com/~yoshioka/d/95/10/i950831.html

この２ヵ月間でしたことは，銀行口座作って，免許とって，

アパート見つけて引っ越して，それでなんにもしないうちに

１月たっちゃて，あ，これじゃ，いかん，俺は何しに

きたんだつー危機感持って，引っ越しの荷物整理して，

ちょっと落ち着いて，わけのわかんないカレーと

肉野菜スープ風の手料理作って，ＰＣ買い込んで

それにＬｉｎｕｘのっけてｐｐｐｄで

プロバイダにつないで，（ぜいぜい），

スペック一本書いてそのレビューミーティングが

明日だ，つーような感じでいます．

そして２ヵ月間でいろんなことを始めて，学んで

失敗して，３０代なかばのおぢさんらしい葛藤も

あって，でも極楽でやりたいようにへらへらして

技術者の良心って一体なんだなんつーことも，

ちょっとは考えたりして，肩に力いれちゃった

こともあったけど，

おれがここにいるのはこの仕事をするためだ

つーこころいきだけで，今に至る．

学生さんも就職とかいろいろ大変かもしんないけど，

３０代なかばのいい歳したおっさんも新しいことに

チャレンジしちゃったりして，やってみると，ま，

どーにかなっちゃたりして，転職考えているちみも

人生１回しかないないんだから，やりたいこと

やれば〜とか，あおってしまったりする今日この頃．

得たもの失ったものいろいろあるけど，瞬間瞬間

葛藤しながらはりきってまいりましょー

明日のミーティングでわたしの書いたスペック認めさせて

それで２週間のバケーションだ．

どだ．まいったか．

はげましのお便りは

よしおかひろたか

までどーぞ．

9年前の日記を引用しつつ今日はこのへんで。

CNET Japanの人気BLOG、梅田望夫「英語で読むITトレンド」 http://blog.japan.cnet.com/umeda/ でゲストBLOGをやる事になった。

随分前からお願いはされていたのだが、清水の舞台から飛び降りる覚悟で受ける事にした。前半が日本の若いばりばりのプログラマの皆様のBLOGなのでわたし自身も大変楽しみにしている。私のはどんなBLOGになるのかちょっと見当もつかないのではあるががんばってみたいと思う。(あ、がんばらない方がいいかな)

梅田氏のBLOGの読者とわたしのそれとは多分、そーとー違うだろうから梅田ファンには申し訳ないが、彼とはかなり違ったテイストのものになることは想像に難くない。

とはいうものの読者を意識しないでものを書くと言う事はありえないので、できればこっそり、こーゆー話を読みたいとかコメントなりメールなりをいただけると非常に嬉しい。お題拝借である。

開発者も利用者もバグと認めた現象についての解決は時が経つのを待つ。問題は開発者がその現象をバグと認めない場合だ。「それは仕様です」

仕様だろうがなんだろうが利用者が困っているという状況は変わらない。利用者としてはどうにかして仕様だろうがなんだろうがどーにかして欲しいと切に願っている。ここに開発者と利用者の目に見えない綱引きが発生する。

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136290

SJISのlocaleを用意して欲しい、という要求に対し開発者はNOと言っている。中身を見てみよう。

Description of problem:

Add Japanese SJIS locale.

Red Hat doesn't support, but the community do.

SJISのlocaleをサポートして欲しい。

Steps to Reproduce:

1. SJIS!

2. SJIS!

3. SJIS!

再現方法としてSJIS／SJIS／SJISとしているが正直言って意味不明である。

Additional Comment #1 From Jakub Jelinek on 2004-10-19 03:37 -------

There is a big problem with SJIS, particularly that it isn't ASCII

compatible. Therefore many POSIX programs will misbehave when in

SJIS locale, which is not something that we should IMHO support.

開発者からの返事である。ASCII互換ではないと主張している。ASCII互換というのが未定義なので何を開発者が指しているのか精密に理解する事は難しい。

Additional Comment #2 From Ulrich Drepper on 2004-10-19 03:44 -------

Using a SJIS-based locale means violating standards. And beside, we

only support UTF-8 locales from now on.

標準に準拠しないのでUTF-8 localeしかサポートしない。どの標準に準拠しないかという指摘はない。

Additional Comment #3 From Yukihiro Nakai on 2004-10-19 08:04 -------

Sounds like a very dictator logic by European and American

as always happened on codeset issues.

ううむ、EuropeanとAmericanを一緒くたにした乱暴な発言である。codesetの議論には全く関係ない余計な一文だ。有害無益である。

Other commercial UNIXs have that SJIS locale and troublesome.

Users knows them but still want SJIS locale.

他の商用UNIXではSJIS localeを持っているという主張は正しい。

Additional Comment #4 From Jakub Jelinek on 2004-10-19 08:19 -------

Users that want to shoot themselves in the foot can do so themselves.

localedef -i ja_JP -c -f SHIFT_JIS /usr/lib/locale/ja_JP.sjis

will create that for them, but I don't think that is something

we should promote and support.

iconv(1) and iconv(3) certainly support SJIS, so if users have documents

in SJIS charset, they can convert to UTF-8 (and back).

開発者は localedef -i ja_JP -c -f SHIFT_JIS /usr/lib/locale/ja_JP.sjis というワークアラウンド(回避策)を提示している。さらに、iconvを利用すれば問題は解決すると主張している。

Additional Comment #5 From Ulrich Drepper on 2004-10-19 11:03 -------

> Sounds like a very dictator logic by European and American

> as always happened on codeset issues.

This is an issue of maintenance for the distribution. Using a

non-ASCII clean locale means that various programs will just cease to

work. How will pay all the wasted hour of our developers who get

reports a program doesn't work and it turns out it is the fault of

this locale?

non-ASCII localeを利用する時の問題点を指摘している。

Arguing about other Unixes having support is irrelevant. There is no

Unix in existence even today which has internationalization as

complete as Linux. They simply don't have these programs. And in

case of, say, Solaris there is an additional problem that they have a

non-fixed wchar_t representation (in old code, they switch for new

code as well) which makes it all but impossible to write correct

i18n'ed software.

Solarisでの問題点も指摘している。

I would appreciate if you don't use words like the above anymore since

we actually know what the implications are since we actually wrote the

code.

先に引用した(Sounds like a very dictator logic by European and American

as always happened on codeset issues.)みたいな言い方はしてくれるなと苦言を呈している。

Additional Comment #10 From Yukihiro Nakai on 2004-10-20 13:13 -------

>This is an issue of maintenance for the distribution. Using a

>non-ASCII clean locale means that various programs will just cease to

>work. How will pay all the wasted hour of our developers who get

>reports a program doesn't work and it turns out it is the fault of

>this locale?

Adding SJIS locale doesn't mean directly that you need accept and fix

all SJIS among applications. There should be what our developers should

and what they should not. Just rejecting SJIS locales will get rid of

any chances. Don't skew open source freedom by just your unwillingness.

全然双方の主張がかみあっていない。

>Arguing about other Unixes having support is irrelevant. There is no

>Unix in existence even today which has internationalization as

>complete as Linux. They simply don't have these programs. And in

>case of, say, Solaris there is an additional problem that they have a

>non-fixed wchar_t representation (in old code, they switch for new

>code as well) which makes it all but impossible to write correct

>i18n'ed software.

Stop messing around.

Linux is just the best implemented the incomplete international

standards, ignoring many imoportant domestic issues.

There are many UNIXs with much better Japanese support than Linux.

Even there were versions of Japanese by Japanese for Japanese.

Why can you glibc is enough and ready for real Japanese already?

もし商用UNIXの方がよりよいサポートをしていると主張するならば、例示をしないと説得力に欠ける。

When migrating from other unices to Linux, SJIS is the biggest problem.

Wnen migrating from Windows to Linux, SJIS is the biggest problem.

Your opinion is like that of who are enjoying to wath other people's

fatal suffers through TV, sitting in the comfortable, safty rooms

in a far distance.

意味不明な段落である。

>I would appreciate if you don't use words like the above anymore since

>we actually know what the implications are since we actually wrote the

>code.

Sorry, just learned from your mails before.

I don't bow to the dictator.

またまたいらない事を言って喧嘩をしている。

Additional Comment #11 From GOTO Masanori on 2004-10-21 14:40 -------

I couldn't understand why you guys insist to support ja_JP.SJIS locale.

I guess you want to use SJIS for text convertion (use iconv, nkf),

or use SJIS on filesystem (use mount option). But why do you want

to use ja_JP.SJIS _environment_?

ja_JP.SJIS locale is broken for unix environment.

Most Japanese locale developers do not consider about ja_JP.SJIS locale

for daily processing because SJIS is not suitable for unix environment.

We have tested for ja_JP.ujis, ja_JP.eucJP, ja_JP.EUC-JP, and

ja_JP.UTF-8. However ja_JP.SJIS (and ja_JP.ISO-2022-JP variants) are

out of scope.

Only the thing I heard about using ja_JP.SJIS is to handle SJIS on

xmms. But I think it's just local hack for that user, and I doubt it's

usable for everyone (and read comments; it's not).

I think it's useful that you check whether ja_JP.SJIS is usable or not,

and which part violates POSIX behavior before complaining, because

no one has tested and collected it, IIRC.

別の観点からのコメント。

Status: CLOSED

Resolution: WONTFIX

最終的な結論は、クローズ、修正予定無し(WONTFIX)

コミュニケーションとしては失敗の例である。ここから皆さんは何を学ぶか？どうすればよかったか？オープンクエスチョンとしておきたい。

バグデータベースを読む人の立場から、すなわちバグを直す人の立場から、バグデータベースの書き方のコツを一つ二つ。

バグと思われるものを発見したあなたはどのようにバグを報告するか？あなたはその問題を解決してほしいとせつに願っている。

• 現象の記述
• 再現方法の記述
• 期待される結果

最初にやることは現象をあるがまま報告する。次にその現象を再現する方法を明確にかつ簡潔に記さなければならない。その現象を再現するのに必要なOSのバージョン、ソフトウェアのバージョン、その他関係しそうな事を厳密に記す。そして再現方法を逐一記述する。

最後に本来期待される結果を記す。XXXでYYYするとZZZとなるが、AAAという結果になるべきである。

ここから開発者(バグを直す人)とコミュニケーションが開始されるのである。バグを直す立場から言うと再現方法の書いていないバグを修正することは非常に難しい。コミュニケーションの密度、スピードを加速するためには、明確に記述した再現方法が必須である。バグを通して利用者と開発者は会話をしている。共通の理解をするために、バグの再現方法は重要である。バグを再現できればその問題について９割方解決したと言っても過言ではない。デバッグの最初のステップは問題を正しく理解し、バグを再現することだ。そしてバグを再現できれば最初のステップはクリアしたことになる。

開発者はその実装について詳細をしっているので現象をみれば多くの場合、ほとんど瞬時に原因を特定できる。問題の８割はそのような簡単な問題であると言う事を経験論は示している。残りの２割はソースを読んで詳細を検討しないといけないような問題である。

それはともかく、期待される結果と現象の差を利用者はバグと認識するわけだが、開発者がそれに同意するとは必ずしも限らない。ZZZという結果は仕様である。修正しないという宣言である。これについてはまたまた後日記す。

開発者と利用者のコミュニケーションの手段としてのバグデータベースをどう利用するかのHOWTOというのは実はあまり議論されていないような気がする。(お、大きくでたな＞自分)

最近ではメーリングリストでのやりとりに関しての(ありがたい)ガイドラインみたいなのがあって、どーすれば自分の意図する回答を得られるか、得られる可能性を大きくできるかというようなことを、ご丁寧にも指南してくれたりする。 http://www.hyuki.com/writing/techask.html とか http://www.geocities.co.jp/SiliconValley/5656/ とか。まあ、どうでもいい話であるが、当事者はそれなりに切実なので、必ずしも無用な長物というものでもない。

商用ソフトの場合、仕様や実装上の問題はバグデータベースを介して開発者と利用者がやり取りをする場合が多い。実際はその間にベンダーの営業やらSEと呼ばれる人や、サポートエンジニアと呼ばれる人が介在するので直には開発者とやり取りする事は少ないのかもしれないが、まあなんらかの形でのコミュニケーションがある。

利用者がサポートのお世話になるのは、利用者の環境で利用者自身が解決不可能な問題に遭遇した場合である。利用者にとって解決不能な問題というのは必ずしもバグとか実装上の不都合というような話ばかりではなく、ちょっとした利用方法が分からないとか、使いにくさへのクレームとかいうも物も含まれる。利用者にとっては自分のブチ当たっている問題を解決してくれればいいわけでそれは必ずしもバグの修正だけではなく簡単な回避策の提示だけでも十分なこともある。まあ、ここらへんはケースバイケースである。

サポートエンジニアのミッションは顧客の問題を解決する事だとすると、とにかく回避策でもなんでもいいから今ここにある問題を解決したいということになる。簡単な回避策が見つからない場合は(なにがなんでも)問題を修正してほしい(狭い意味でのバグを修正してほしい)ということになる。

できるサポートエンジニアはもちろんコミュニケーションのエキスパートである。単に技術的に優れているだけではなく、顧客の解決したい真の問題を探り当てる天才である。現象的にはソフトウェアのバグのようであるが、そのバグを修正する事が目的ではなく、ある作業を行いたいのにたまたまそのソフトウェアのバグXXXに遭遇しちゃったので、別にXXXという機能を使わなくて、ある作業を問題なく遂行できるのであれば、極論すればバグXXXが直ろうが直るまいが、まあ頓着しないという立場である。その落とし所を動物的勘で見付けて来る天才である。

そーゆー人にとってのバグデータベース利用のHOWTOをぜひ知りたいというのが今日のお話であるが枚数が(？)尽きたので明日に続く。(ほんまかいな)

宿題： https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=136290 を事例として検討したい。各自よく読んでおいてほしい。

日記と言う割には日々の雑事を記していない。ということで意味もなく一日を記す。

朝起きる。トイレに行く、顔を洗う。PCの電源を入れてメールを処理する。朝食を食べる。歯を磨く。出勤。会社につく。メールをチェックする。会議をしたり、書類を作ったり、プレゼン資料を作ったり、客先にいったり、コーヒーを飲んだりしながら、あ、もうこんな時間だと思う。昼飯でも食うか。新聞読んだり、会議をしたり、資料のコピーをしたりしているうちに、いかんいかん、今日の成果はなんなんだ、自分のパフォーマンスの低さにほとほといやがさすころ小腹も空いたので夜食を食い、夜の電話会議をしたり、メールを読んだり、Webをみたりしているうちに、あ、もうこんな時間だ、帰らないと。今日も長時間労働をしたなあ、などと思いつつ、ふと手を見る。

そして思う。自分の人生９９％上記のごとくだ。進歩がない。昨日と違う事を、新しい事をどれだけチャレンジしたか。別に新しい事が無くても実直に当り前の事をちゃんとやって一歩でも前に進んだか。時々思う。人には厳しいが自分には甘い、そーゆー自分を発見する。

いかんいかんこれではいかん。と思うのだが、どーすればいいのかよく分からないという、これまた進歩のない結論に陥ってしまう、おじさんなのであった。なんか何年か前に同じような日記を書いたような気がするが、同じところをぐるぐる回っている迷路に迷いこんだ鼠のような気分である。まあ、たまにはこうゆう精神状態もあるということでわたしには休暇が必要だ。