MS の連中が嫌々ながらとはいえ各種 Office の仕様を公開したわけだが、まあ予想の通りに酷かったわけだ (流石に全部は読んでないが、酷くない部分は存在しないだろう)。勿論この酷さには理由があって、
といった問題があり、そのため既にこの世界の誰も使っていなさそうな仕様を廃棄することが出来ないでいるわけだ。ある視点からの理想を言えば、適当なところでデータフォーマットもきちんと洗い直して、古いデータ形式から新しいデータ形式へのエクスポートを行えるようにして、既にニーズが消滅しているであろう仕様は撤廃するのがいいのだろう。が、これをやると古いバージョンを使いつづけたいというユーザをどうするか、誤差に過ぎないとはいえ確実に存在するニーズを無視するのか、といった問題を生みだす。そしてそちらの問題は古いパッケージも継続して使えるようにする以外に方法は無く、継続的あるいは永久的に旧バージョンのメンテナンスとサポートを行うことを意味する。勿論、それら全てに目を背けて大鉈をふるってもいい。さあ、一番高くつくのはどれだ?
ちなみに俺は何にせよこの手の問題を生み出したのは他ならぬソフトウェア開発者だと思っていて、要するにユーザに対して自分たちのソフトウェアの思想を提示することが出来なかったから、惰性でどんどん仕様が膨らんでいくわけだ。相手の要求に答えるだけならどんなバカでも出来るのだ。本当に重要なのは、相手が何故その要求を出したのかについて考え、本当の問題解決手段を提示することで、それこそが個人であれ企業であれソフトウェアにおける思想というものだろう。そして俺は「全部入り」のような回答を出すことは人間の知性に対する許されざる冒涜だと考える。
もっともプロプライエタリなソフトウェアの場合、どうしても囲い込みとモノカルチャー化というのが付いて回るのが割と真実に近いと思う。そして結局それは「何でもやります」というくだらん結論にしか至らないわけで、俺がよりフリーでオープンな方向を指向するのはそういうことだ。
最後に書いておくと、 Office の仕様が公開されたこと自体は喜ばしいことだと思う。たとえそれが 99% の開発者の手に負えないようなとんでもない代物で、 MS Office と完全互換のソフトウェアを MS に依存せずに作るのは限りなく不可能だということになっても、公開されていないよりはマシだ。少なくとも公開されたことで、このフォーマットに真面目に付き合うのは俺にとっては人生の浪費だということがわかった。これは「もしかしたらどうにか処理できるフォーマットかも」というささやかな希望を完膚なきまでに叩き潰すものだが、問題に対する回答ってのは得てしてそういうもので、この場合の「解決不能」は「わからない」より相当マシだ。
それにしても Apache POI の連中はこれをリバースエンジニアリングで解析してある程度のことは出来るようになったんだから、本当にとんでもない連中だよな。
Scribes をアップデートしたら、どうにも不安定になっちまった。具体的には、自分で書いたプラグインの挙動が変だ。エラーメッセージから推察するに API に変更があったようなのだが、まだ詳しくは調べていない。やはり正式なドキュメントが揃う前にプラグインを書くのは無謀だったか。
これはどうにもいただけないので、対応策を考える必要があるのだが……。しばらくは kwrite でも使うか?
どーでもいいけど、シェルスクリプトで「とあるディレクトリが空かどうか」を調べる方法。
if [ -d $TARGET ] && [ 0 -lt `ls $TARGET | wc -l` ]
これしか思いつかんかった。
実は例の世界樹2 のページはファイルの生成とかデータのコピーとか、そういうのを Makefile に書いて次のようなターゲットを定義している。
doc:
python .... #テキストファイルから HTML 生成のコマンド
cp work/* ./ #作業ディレクトリ内からファイルをコピー
ところがこれだと、作業ディレクトリが空の時にエラーになる。この作業ディレクトリは画像の編集にしか使ってなくて、作業が終わったら空になる。なので、画像の編集が終わって文章を書いてる段階になると、 make するたびにエラーが出てきてウザったい。なので、次のように書いてる。
doc:
python ....
if test 0 -lt `ls work | wc -l` ; then cp work/* ./ ; fi
ところで俺はこの手のビルドスクリプトは Makefile と Ant しか知らないんだけど、どっちがいいって言われたら Makefile かなあ。 Ant ははっきり言って嫌い。 Ant の嫌いなところは、そもそも俺は XML をスクリプトとして使うのが嫌いというのが大きいんだけど、それ以上に行いたい操作が要素として定義されていたり、あるいはとある要素の属性だったり、定義済みの要素がどこで定義されているのかさっぱりわからなかったり、とにかくそういう部分が嫌い。
この怪文書はクリエイティブ・コモンズ・ライセンスの元でライセンスされています。引用した文章など Kuwata Chikara に著作権のないものについては、それらの著作権保持者に帰属します。