昨日あたりからそうなのだが、ユーザークレームの対処。で、対処内容というと_「(原因は別にあるけど、) とりあえずこうしよう」_と言う指示だった。工場内の対処としては良くやる手であると思うが、上位組織からの指示じゃなかろうに。もっと他にやることあるんじゃないの? と言うことと、どうしてこういう風なトラブルがでるのと言うあたりを突き詰めておかないとならないんじゃないのかなぁ。
で、僕らの仕事が増えるのは勘弁願いたいところだ。(言う方は言うだけだから簡単だよねぇ。)
Apache XML Project関連のツールのインストールの解説記事を書いた。最近のBBSでのやりとりからFOPがどの程度使えるのか調べるためである。FOPは名の通り、XSL-FOというXMLで記述された文書(平たったくいえば、Post Scriptみたいな物)からPDFに変換するツールである。
いろいろなツールのバージョンが軒並み上がっているので、全部インストールし直して、過去のTLUCの勉強会の資料を補筆した訳だ。一応このレベルで、docbook-xmlを使って、Docbook文書をFO経由でPDF出力はできそう。ただ今のところ悩みは、Docbookで画像貼り付けを行った時に画像が上手く表示できないことくらい。(JIMIはちゃんとダウンロードしてCLASSPATHは通しているのだが…) 僕がDocbookの使い方を理解してないので、画像周りの指定を間違えていると言う線も疑い得ないが…
SmartDocからFO経由でPDF出力も試みたが、sdoc2fo自身が吐き出すfoがRecommandationなFOかどうか不明なためで、FOPの処理中でエラーを吐いて終わってしまう。うーむと言うことで、力つきました… sdocのMLに再度入って聞いてみよう。
ようやくお休みになった。なんだか風邪を引いた模様。のどが痛い…
昨日の議論の続き。じゃ_なぜにVBAを使っているのですか?_と言う話も言及しておこう。
本来VBAでできるものは、Active PerlやActiveScriptRubyで書いた方がよりスマートにかける。こないだも苦労したが、VBAは文字列処理が非常に弱いので、テキスト処理を得意としている言語でやった方がスマートにかけるプログラムは多い。
じゃなぜ?と言う話は簡単で、VBAで書く物はお仕事でしか存在しないからだ。(僕は家のPC用にOffice2000のライセンスを2個持っていますが、インストールしてません。) ただみなさんに「ActiveScriptRubyをインストールしてくださいね」と言うのと、インストールしてもらう利点を説明するのが、めんどくさいからだ。(だってExcelはすでにインストールされているものね。)
ただ最近ExcelのシートにマクロをつけるよりはAddinとして配布すべきだと思い至ったので、最近僕が作るマクロはAddinになるようにしています。使っている理由はただそれだけです。VBやVBAというかMSの生成物に美しさを期待するのは愚の骨頂なので、適当におつきあい。それが正しい姿であろうと思うのだ。書きたい言語で書いていいよと言われれば、絶対選択しない物であるのは確か。
今日はなんだか議論になってしまったので、一応日記にも書いておこうと思う。今の時点では僕はJavaを開発言語に使っても良いくらいの完成度になってきていると思っているので、以下の議論はだいぶんどうでも良くなっているのだが、何個かの理由があってまだJavaを開発用の言語に選択する気はありません。
僕はJavaに熱狂があった時代(Alpha版からBeta版の時代)を知っていて、そのあとに大きく失望したので使っていない訳だが、大ざっぱに言えば以下の項目に集約される。
仕様の策定がオープンでない
最近は解消された気はするが、仕様の策定がSunで行われていた頃は、信頼に足るコンパイラ供給ベンダがSunだけという感じだった。自分が使うツールの提供元がただの民間企業1社しかないというのは、あまりに脆弱だと思う。いまはThe Java Community Processである程度読みとれるし、コンパイラベンダも複数になったのでまぁいいかと思うのだが。
開発ツールの提供
当時JDKは、SolarisとWindows版しかなかった気がする。当時僕の主要な環境はLinuxだったので、採用すらできなかった。(BSDユーザーもMacユーザーも悔しかっただろう。)
国際化周りの対処の遅れ
JDK1.2でほぼ解決された問題と考えているが、やっぱ母国語が陽に使えないのは痛い。Unicodeをがんがん使うのは良いが、Unicodeを編集できるエディタが当時なかったこと、処理する対象は非Unicodeな文書で、Unicode周りの問題(正規化とか言うんだっけか)があってどうもねぇと思っている訳だ。
動作が遅い
これはJITコンパイラのおかげで解決を見たと言っていいだろう。(同じアルゴリズムでC++とほぼ同じくらいだから問題なかろう。)
僕は過去も今も「オープンソース」側の人なので、プログラムを書くのに最も重要なのは_「プログラムを書く自由」_だと思っている。僕はあくまで職業プログラマではないので、プログラムを書くことはこの上ない楽しみであり喜びであるべきなのだ。それゆえに上記の用件で最も大切だと思っているのは、言語仕様のオープン性とコンパイラの提供が永続的であることである。その条件を満たせない限り、使ってみようとなかなか思い立てないのである。
ただ今となっては時代遅れな意見も散見している気もするので、ぼちぼちJavaを個人的なプログラムの開発に使えるよう準備を整えて良いかと思っている。なにせXML周りはJavaがないと立ちゆかなくなってきているので切実なところであろうか。僕の中のJavaの不運は、_必要な物が必要な時に提供されなかったこと_につきる。(それで仕事する気が失せるんだもの。) 逆にLinuxは使いたい時に使える形で登場したのね。(こっちもかなり偶然性が強い。) まぁ時の運とはこういう物だろうな。
僕のなかでJavaの残りの問題は、C++におけるtemplateがないことくらい。これはJava GenericsがJDK1.5で実現すれば解決される。僕自身はライブラリ設計者ではないので、Genericな型を持つclassを設計することはないのだが、Collection classを使っていると、Collectionから要素を取り出すのに_型キャストが必要_と言うことと、_意図しない型の要素を追加できること_が気になるわけだ。Java Genericにはそれなりの期待をしている訳だ。
議論については、幾ばくかつきあうので、僕にJavaを使わせたい人は建設的なご意見をください。
今日は明日説明するためのさくっと資料を作成。我ながら数年ぶりにWordなどを使ってみた。(大概の説明用資料は、ExcelかPowerPointで作るからなぁ。) やっぱり文章を書く時はワープロがお気楽で良いなぁとしみじみ思った。無論エディタでざくざくHTMLやLaTeXの方が楽と言うのはあるけれども。