トップ «前の日記(2006-07-09) 最新 次の日記(2006-07-11)» 編集

jFD開発したりしなかったり日誌

2004|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|
2006年
7月
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

2006-07-10 [長年日記]

_ 仕事

昨日のDANKETECH中、駆けつけビール一杯、ウイスキーを

グラスで2杯、うまい棒ジェンガによるテキーラ2杯(多分。怪しい)、

さらにその後VJ中にスミノフ2杯、おまけに終了後区ト間で

梅酒を2杯(多分抜けがあると思うが、覚えてない)も飲めば

そりゃちょっとは二日酔いも起こしますよ。

というわけで午前中は半分死にながら仕事してた。

忙しいから倒れる閑もない。

コンビニでウコンのドリンクを買ってきて飲んでみた。

多少利いたような気がするのでガリガリ仕事。

辛いなあ。

早くこんなプロジェクト終わりにしたいなあ。

夕方、急に体が酷く辛くなってきた。

肩周りの筋肉がまとめておやつサラミみたいになったような感触。

なんだこれは、と思いつつ、お社長K君に

「体辛いから少し休ませて」

と頼んで倉庫へ。

ヨガマットを敷いてバタンキューダウン。

しばらく倒れてから復活して、延々仕事。

10時にK君が帰るというので、僕も切り上げた。

一番面倒だった画面である程度目処がついたか。

とにかく早く片付けねば。

_ JET

諸般の事情でJETコンパイラのプロ版を試すことが出来た。

JETはJavaのネイティブコンパイラで、未だに実用的に使うには

心許ないgcjと異なり、昔から動いてる所だけ見せられれば

ネイティブ実行なのかJREを使っているのか見分けられないくらいの

高いJava互換性があった。

もちろんgcjみたいにAWT、Swingが使えないなんていう制限もなく

かなり強力なのだが、いかんせん高かった。

2グレードあり、スタンダード版は35000円と、それなりに納得できるが

これはネイティブコンパイルしてるくせにランタイムが必要という、

「意味ねえじゃん!」

な仕様だった。

で、プロフェッショナル版はそういう制限がない代わりに、高かった。

今でこそ購入後30日間サポート付きで132,300となっているが、

以前は20万円した。

ちょっと個人で手が出せるような物じゃないので諦めていたが、

今回それを使うことが出来たので、さっそくjFD2をネイティブコンパイル

してみることにした。

とりあえずインストール。

昔使ったバージョンでは、インストール時にJREのrt.jarを全部コンパイル

するという仕様だったが、あれは酷く時間がかかったので同じ目に遭うのを

覚悟していた。

しかし今のバージョンではそれは無くなったらしい。

インストールはすぐに終わってしまった。

続いてjFD2のコンパイルを行う。

コントロール画面を開き、クラスパスにjFD2に関連するjarファイルを

まとめてぶち込み、メインクラスを指定し、コンパイルボタンを押すだけだった。

至極簡単。

ただし、コンパイルには死ぬほど時間がかかった。

昔のバージョンでインストール時に行ってたことを、今やっているということだろうか。

このコンパイル結果ってキャッシュされるのだろうか。

ちょっと不安。

気がつけばjFD2はjarが全部で6メガを越えてしまったが、(自分で書いたのは

1メガだけだが)、それだけ全部コンパイルするのは確かにでかい作業なのだろう。

rt.jarの中身もコンパイルしてるのだろうし。

出来上がったexeを実行してみる。

動作は微妙に軽いような気がするが、何せ最近のPCってjFD2実行するくらいじゃ

ほとんどまったくボトルネックがないくらい早いんで、いまいちわかりづらい。

しばらく普段使っている通常版の代わりに使ってみたが、動作に違和感はなかった。

うーむ、これはいいかも。

さて、このバイナリ配布しちゃってもいいものだろうか。

関係者に確認してみるか。

_ 自動ソースコード生成が嫌いだ

自動コード生成は間違ってると思う。

プログラミング言語は、人間が読み書きし、コンピューターが読むためのもので、

コンピューターが書く物じゃない。

コンピューターが書くには、どの言語もほぼ例外なく、つまらないところが

大きな障害になる。

たとえばインデントを正しくすること。

自動生成された変数名の管理。

人間が書くのなら大した作業じゃないのだけれど、人間がプログラミング言語で

コンピューターに書かせるとものすごく面倒くさくなることが多すぎる。

で、同じ理由でSQLをコード中で生成するのも全く持って勘弁していただきたい。

しばらく前から、コード中にSQLを記述するときは、パラメータ数の増減に

耐えられるような書き方をしているので、StringBufferを切り貼りして

SQLを組み立てるようなことはやってなかったんだけど、それでは対応できないくらい

複雑なSQLが必要になり、仕方なくStringBuffer#append祭りをやっている。

うう、本当に面倒くさい。

よくやってることだと思うけれど、検索条件が一件目だったらWHEREを出力、

そうじゃなければANDを出力とか、すごく格好悪いと思う。

SQLって、中途半端に人間寄りの言語だと思う。

構造的には比較的単純なツリー構造で表せるのだから、いっそXMLで書ければいいのに。

XMLならコンピューターが書くのに便利な言語だし。

本日のリンク元
その他のリンク元
検索