日々の破片
| 著作一覧 |
2004-11-01
_ 端倪できないバカが往く
Programming Legends Debate .Net, J2EE 。
この記事おもしろい。消えないリンクにしておこう。
"We'd be crazy not to recognize the success the competition is having," Hejlsberg said. "I think it's obvious to anybody that there's competition between .Net and Java. And I think we'd be stupid to ignore what they've done there. I've seen further by standing on the shoulders of giants. There is so much in this industry that there's really no reason to reinvent. So I think we are all learning from each other."
Crupi, a respected J2EE architect, said, "I love what they have done with annotations and Web services."
For instance, both Box and Hejlsberg wore black shirts. Fowler said, "I see the Microsoft guys are dressed in black. Are they taking this evil empire thing a little too seriously?"
まあ、読め。
2004-11-02
_ 1+1=2
忘れた。
_ 分析・設計・実装
確かに区別がわからなくなってしまったな。
なぜかっていうと、すべきことがわかると、どうすればそれができるかが見えてしまうからだ。
つまるところ、自分が実装した結果まで早い時点で見えてしまう。
でも、それではしょうがないから形式化する必要があり、それが文書となるということなのだろう（だろうってこたないけど）。
作曲家はできあがった曲を楽譜にするんだろうか？
楽譜は音楽ではなく、音楽は演奏家によって生み出される。
作曲家＝演奏家のリストとかショパンと、ほとんど演奏ができないベルリオーズを比べると、できあがったものの規模に差がある（リストは比較的大規模な曲も作るが、特例のような気がしないでもない）。
どっかに書いたがシェーンベルクの逸話だと音楽が先にできて、それを楽譜に映していたようだ。
多層構造ってオーケストラに似ているかも知れない。
スコアの下のほうは比較的決まりきった処理が多い。シューベルトのグレートのチェロは最初のミドルウェアかも知れない。
とかいろいろ考えながら、今日も文書かきかきするか。
2004-11-03
_ なるほど
WikiなんかはむしろSN向
そうかも知れないな。
いつも矛盾した考えも持つから、その一方で、せっかく開けているのにわざわざ狭い世界を作る（たとえば話に聞くところでの海外赴任者の日本人村とか）こともあるまいのにな、とか。
_ ある時期のイヴシモン
思えば遠くへ来たもんだっていう意味なのか？
吉田拓郎風（っていうかディラン風なんだろうが）ではあるが、思わず、Petite fille, p'tite misereを聴いてじーんときたり。iPodならではですね。
しかし、今や意味が全然わからん。
君の内側、そこは冬。？？サンドウィッチとビール、夜の中に忍び込む。
ディアボロマーント。違う。似ているけど。こっちだ。http://perso.wanadoo.fr/daviken/Pageweb/Diabolo/diabolo.mp3
リセ（と書くと一時の少女漫画を想像するな）のロッカーには、夢と秘密。決して口にすることはないすべての言葉。
それにつけてもアビシニアは遠い。
2004-11-04
_ 画力
『傑作だ! 買え! 読め!!』とたださんが絶賛しているので（それだけが理由ではもちろん無いのだが）早速買いに行って（リブロのようなバイヤーの勘が良い本屋が近所にあるってのは便利なことだ）読んでたら、さっそく子供が釣れた（っていうことは、子供に読ませる下心があったということだが、こういう内容で妙なのを掴みたくはないから、たださん絶賛というとこに惹かれたわけだが）。
で、覗き込むから、「後で貸してやるからあっち行け」と追い払うと（っていうか、くそまじめに読んでるのに覗き込まれるのはやだったり）素直にどっか行って何かごそごそしている。
しばらくして『おおきなポケット』という子供雑誌を手に戻ってきた。で開いたページを指差して
「この人のマンガだよね？」
と言うじゃないか。
どれどれ、と覗き込むと、あ、確かにそうだ。どうも見たような絵だと思ったらそれか。
2〜3年前の雑誌でその時点で読んだだけだから記憶があいまいだが、こんな話。底意地が悪い河童の王女がいて、頭にどかどか花が咲く呪いにかかってしまった。花は皿から水を吸い取るからどうにかしなきゃならない。どうやら人間の世界で善行を積むとその都度1本ずつ花は抜けていくそうだ。だから人間界へ行って善行を積もう。でも、底意地の悪さは生まれつき、気付けば花は咲くばかり、みたいな物語だ（ったような。でもどうにかこうにか毎月1本くらい花が抜け落ちるようにしていたような）。
そう言えば『ずいぶん毒や皮肉が効いているものの』とたださんもこの作者の別の作品を評しているが、いずれにしろ一筋縄でいくような作家じゃなさそうだ。そういう作家が毒や皮肉を抑えて勝負をかけてくればえらいものができても不思議ではないのかも。
それにしても画力ってのはアイデンティティだなとつくづく思ったのであった。
『今はそれ以上は言えない。』ということは内容についてはそのうちたださんが書かれるだろうから省略。
2004-11-05
_ ExcelとVBA
今更何を言い出すのか、と思われてもしょうがないが、僕がExcel＋VBAというのを（少なくても自分でプログラムしたのは）つい1週間ほど前のことだ。
それまでExcelのBookをRuby＋Win32OLEというのは散々使ったけど、何しろ今はPowerBookなもんでExcelはあるしRubyもあるけどWin32OLEは無いからだ。
#と書いてからもしかしてMac用にもOLE2ってあるのかな？ と思ったり。
で、使ってみるとやっぱり便利だったというだけなんだけど、当然のようにVBAのコードってOSXとWin32で互換なんだな（ボタンとかの見た目はちょいと異なるけど）ということでそれなりに感心した。
_ Windowsノートパソコン(もやはり必要ではあるな)
B00029LKRG
これ、Vectorで叩き売りしてるけど、どうなのかなぁ。メモリーは不足してるから512×2に替えなきゃだめだろうけど、CPU的には問題なさそうだし。
あと気になるのは1024×768って今となっては狭い気がするところ。
2004-11-06
_ メッセージングの3番目
以前、P2PとPub/Subしか知らん。ポーリングくそと書いたけど、やっぱ、第3の道は、『常にクライアントがトリガーとなってキューにアクセスできるモデルだ。』なのか。がっかり。
#こういうことだ。大した話ではなくきわめて単純な非EJBでの手作りメッセージングの話。
今は2台だとする。この場合P2PでもPub/Subでも良いが、プッシュモデルである以上、配送元に設定が必要である。
しかしシステムが発展すると、第2、第3の配送先が必要になる可能性がある。この時、配送元は既に安定稼動しているのだから、いっさい変化を与えたくはない（H/W増強とかはもちろん別の話となる）。第2、第3の配送先にのみ、何かをすればすぐに配送元に繋がるという状態が望ましい。
つまり、ある意味において一元管理はしたくないということだ。新規に追加されたもののみ変更したい（というか設定したい）ということ。
この場合、P2Pは最初から土俵に上がることさえできない。
Pub/Subの場合はどうだろうか？
設定としてあらかじめ配送先を配送元に記述する方法は最初の要求から問題外だ。
しかし配送リクエストをネゴするという方法は取り得る。
この場合、配送元はプッシュする前に配信先のポートを知ることができるからだ。FTPみたいな。
ネゴの過程で配送デーモンを1つ相手に貼り付ける。後の動作はP2Pとして実行しても良い。この場合の問題点はめんどうだということだ。めんどうなソフトウェアはバグの混入率が大抵の場合上がってしまう。配送デーモンが消滅することの監視も必要となる。（スレッドではなくプロセスにすれば多少監視しやすい）ネットワークを使う場合、キープアライブを流すのを避けたり無通信検出タイマーの間隔が長いとこの状態が発生してしまう。（よく考えたらP2Pでも動揺だ）
（配送先が消滅したら配送元の送信エラーで発見できる）
ネゴの問題点はもう1つ、タイミングである。配送先がネゴしようとしたら配送元がたまたまメンテ中だったから無応答。この場合、配送先に適切なリトライのロジックが必要となる。これもめんどうのうちだ。
これらについてポールが解決策となりうるのはわかり切っている。
この場合の考慮点は、
1.メッセージの抜け対策
2.配送先の突然死（誰も気付かない）
3.ポールの間隔
の3点。1.は配送先毎のキューを使わないことから簡単に発生しうる。配送先が独自のシーケンス管理（キュー—と言っても1本しかないし、配送先複数が前提なので誰もデキューできない。したがって、単純にはDBMS上のテーブルとして配送元は何も考えずにインサートし配送先が勝手に読み取るというのが現実的だ）
たとえば、配送元はSEQUENCEを使ってキュー（っていうかインサート）していく。障害が発生すればSEQUNECEは飛ぶから必ずしも1繰り上がるわけではない。
そのため、配送先がSELECT DATA FROM QUEUE WHERE SEQ=?; setInt(1, current+1); というようには単純化できない。また、発生順の維持は当然必要だ。したがって
SELECT DATA,SEQ FROM QUEUE WHERE SEQ=SELECT MIN(SEQ) FROM QUEUE WHERE SEQ>?; setInt(1, current);
でなければならない。（が、これはこれだけのことだ）
このようにして得たデータ（というよりも現在のSEQの値）を配送元は独自に管理する。
2.については時々、配送先のプロセスとは異なる（配送先と同一ノード上の）プロセスが、
SELECT max(SEQ) FROM QUEUE
を実行し、配送先プロセスのログと突合せをして一致していなければ怒る（怒る前に数秒待って、配送先の受信済みSEQが変化しなければ本気で怒るとすべき。そうでなければたまたま遅延しているだけかも知れない。したがって、ここでの数秒というのは、ポールの間隔よりは長い必要がある）というような防御が必要となる。
それでも、配送元、配送先、および配送先監視のいずれのプログラムも非常に単純に実装できる。
問題は、結局、3.として残るポールによる負荷（空読みのくせに、MIN(SEQ)とかが必要となるため、必ずしも効率的ではない）だ。
#配送元のQUEUEテーブルへのインサートが複数のプロセスによりランダムに行われるとSEQUENCEのロックがあってもポールの微妙な間隔で飛ぶ可能性があることも注意点となる。
W1 W2 W3
SEQUENCE.next
insert SEQUENCE.next
insert SEQUENCE.next
insert
と必ずしもならないからだ。プロセス/スレッドスィッチがinsertの呼び出し未満で発生するとまずい(追記：バカなことを書いている。insert時点では次のシーケンスを得ているんだから全く問題ではない)。もっともSEQUENCEのカウントアップとinsertでトランザクション境界を作ってコミットするまで次のプロセス/スレッドがSEQUENCEの操作ができないようにすれば良い（かな？ ちょっと微妙な感じがしないでもない）。って言うか発生順が重要なら順序維持は必須か。
やっぱりポールが固そうだな。
追記：
わかった。上のバカなことは、ラック使っている場合でパフォーマンスを上げるために各ノードがシーケンスキャッシュを使うようにさせている場合に問題となる動作を想定していたようだ。あるノードが1を得た時に100までキャッシュする。別のノードが次にシーケンスを得ると101になる。この間に最初のノードの2回目の書き込みが発生しないと配送先は現在のシーケンスを101としてしまう。これ以降、最初のノードの書き込みの2〜99は無視されることになる。
したがって、シーケンスキャッシュの分だけ現在のシーケンスからひいてやらなければ危ない。
というようなこと。
追記の追記：
だめだめだ。
最初のノードからの書き込みがずーと無いまま、2番目のノードが201まで書いてしまえば、シーケンスキャッシュ分の100を現在の配送先が得ているシーケンス（つまり201）からひいても、次の最初のノードの書き込み（シーケンス2）は得られないことになる。
固くやるには、SELECT DATA, SEQ FROM QUEUE WHERE SEQ NOT IN (自分が持ってるすべてのシーケンス） となり、それは無意味に限りなく近い。
方法1: とりあえず、SEQ > CURRENT+1 とし、時々（ポール30回に1回とか）で、WHERE SEQ < CURRENT AND SEQ > (連番の最後) とかを呼び出す。
っていうか、負荷は高まるばかりなり。
ビットマップ管理（ギャップの先頭を条件とする）とか？ でもシーケンス抜けを考慮するとギャップの先頭にマージンを持たせる必要もあるわけだし。
あと、最初のノードがダウンしたら2〜99は永遠欠番になるわけだから、後の考慮がすべて無駄。
すると
方法2: SEQUENCEキャッシュを無効にする
この場合の負荷は？
まんべんなく配送元の各ノードからの書き込みがあるならば、方法1に一工夫したバージョン。配送元の書き込みが基本的に単一ノードからだったり滅多に書き込みがなければ方法2。閾値をどう得るかはえいやの世界のような。とすれば固く方法2が正解かも。処理は単純。
もっと追記：timestampを避けているのは半ば本能的なことなのだが、timestampでも良いかも。複数ノードの時刻同期ってどこまで信用できるのだろうか？ Oracleのタイムスタンプ関数を使った場合ラックだと必ず一致するのかな。そのあたりが落としどころのような。
#再起動したら（前方向に）時刻がずれましたとかなるとやばめ（キーとするのだから重複したらすごくまずいというかそもそも書けない）だし。
_ とりあえず
適当にplugin/disp_referrer.rbを以下のように修正。
- 'antenna.url' => '(\/a\/|(?!.*\/diary\/)antenna[\/\.]|\/tama\/|www\.tdiary\.net\/?(i\/)?(\?|$)|links?|kitaj\.no-ip\.com\/iraira\/)',
+ 'antenna.url' => '(\/a\/|(?!.*\/diary\/)antenna[\/\.]|\/tama\/|www\.tdiary\.net\/?(i\/)?(\?|$)|links?|kitaj\.no-ip\.com\/iraira\/|i-know\.jp\/)',
tdiary.confの@referer_tableに以下の行を追加
['^http://i-know\.jp/([^/]*).*', 'i-know.jp(\1)'],
2004-11-07
_ メッセージングの3番目（続）
まだ問題がある。
配送先の突然死の監視ロジック。
前提から、MAX(SEQ)が等しいかはだめだ。（SEQEUNCEキャッシュを無効にすればOKだし、timestamp方式でも多分OK)
効率的には最悪だが処理的には確実なのはCOUNTでロウ数のチェック。突然死と言ったってプロセスは生きているがイヤンなところに入り込む可能性（プログラム自身の問題と、JDBCドライバに起因する問題などさまざま）があるからメッセージそのものについての何かを監視すべきだろう。
配送元（というかポールで良ければ単純にQUEUEに見立てたテーブルへのINSERTで良いと前提しているわけだから）キーに利用する値をSEQUENCEやTIMESTAMPのように外部から取るではなく、こんなのもありかも。
INSERT INTO XXX VALUES (SELECT MAX(SEQ) FROM ... + 1, DATA)
と一瞬思ったけど排他制御ができないからだめかな？ それは一意制約違反に引っ掛かったら再試行すれば良いだけだ。と思う。MAX関数の負荷ってどんなもんだろうか？
2004-11-08
_ BGM
こないだ突然もえあがーれもえあがえーれと聞こえて来た。
昨日はかならーずここへーかえーってくるとーと聞こえてきた。
なんかいろいろリバイバルしてんのかなぁ。
でも、あのてで（リアルタイムに見てたやつで）1番すきなのはすーいーへーいーせーんのむこうからぁあっあっあーってのだったり。
っていうか耳が覚えてるのってのは（頭は覚えてないから聞かないと思い出せない）毎週聞くことになるからなのか。反復ってのは記憶するためのもっとも優れた手法だなぁとか思ったり。
2004-11-09
_ Entourage
Office:macに入っているEntourageって最初なんだかわからなかった。だってそんなのWindows用のOfficeにないんだもの。
で、起動してみたらなんのことはなくOutlookじゃん（Outlook Expressとは全く異なる）、なら会社のサーバーと相性良さそうだし……といろいろ設定してもサーバーとつながらない（Exchangeとしては）。でも、SMTPとPOP3でならつながるからまあいいや、と使い始めたのだが。どうも、Outlookよりはるかに使いやすい。少なくてもReferencesかIN-REPLY-TOかどっちかはちゃんと見てるっぽくて選択したメールに関連するメールの色が変わったり（Outlookにもそういう設定があるかも知れないけどわからなかったし）、自分が出したメールに対して「全員へ返信」をやっても自分は入らないし（OutlookにしろBeckey!2にしろ、送信者たる自分も宛先に入るので面倒ながら消すか、あるいは忘れて送信してしまい受信してうんざりしたり）、細かなところで使い勝手が良い。相当良い。カレンダーにしろアドレス帳にしろ見る気にもならないOutlookと違って見る気になる（でも、iCalデータのインポートができなかったから今更カレンダーは使わないけど。でもiCalよりも使いやすそうだ）。
とは言え、仕事用にしか使ってないから折り返しがどうなるかとかいった細かなことまでは確認していないのだが。
2004-11-10
_ 良い悪いの問題ではなく
* インテル ハイパー スレッディング (HT) テクノロジに対応しています。
* NEC PC-9800・9821シリーズには対応していません。
* マルチプロセッサには対応していません。
1と3（2はどうでも良いけど）って矛盾ではなくありえることなんだろうか？
・単にテストをしてないから動作保証できないという意味
・実際、マルチプロセッサには対応していないから動作不可という意味
・HTとMPは事実異なるのだから、確かに動作も異なるというだけの話
2004-11-11
2004-11-13
_ アンテナ斜め読み
ほぼ、風のためにって何かと思ったら、3行くらいを一度に見ていたということだったり。
_ 無名インナークラスとテンプレートクラス
だからどうよという気もするが
import java.util.Iterator;
public class Each {
public interface Block {
void call(Object o);
}
public static void call(Iterator i, Block b) {
for (;i.hasNext(); ) {
b.call(i.next());
}
}
}
----------------
Each.call(list.iterator(), new Each.Block() {
public void call(Object o) {
bar((Foo)o);
}
});
というような感じで、テンプレートとして利用可能なスタティックメソッドを持つクラスと無名インナークラス(である必要はないが、位置的な可読性は無名インナークラスが上だと思う)を組み合わせると、単純なテンプレートメソッドは必要なくなる。スペシフィックなテンプレートメソッドについても継承関係といくらかは無関係に作成できる。
public class SafeExecution {
public interface Block {
void prepare() throws Exception;
void call(Object ... args) throws Exception;
void finish() throws Exception;
}
// Varargsってこんな使い方で受け渡しできるのかな？
public static void execute(Block b, Object ... args) {
log(args);
try {
log("start");
b.prepare();
log("prepared");
b.call(args);
log("success");
} catch (Exception e) {
log(e);
} finally {
try { b.finish(); } catch (Exception e) { log(e); }
}
}
}
いろいろ能書きも浮かんだりもするが、実装があるから後はいいや。
_ んで
上のみたいなのって、OOPならではの面はあるけどOOAとかOOD（は微妙か）とはある点において無関係だから（有関係な点ってなんだ？）UMLで記述するとかそういうのってほとんど意味ない。って言うかuse関係を使うくらいしか書きようがないだろうし、そんなもの書いても意味がない（と思う）。なぜなら実装の役にしか立たないからだ。
では無価値かというとそれは多分違う。テンプレートだから型に嵌める役に立つ。たとえばログの強制もそうだし。
ものは言いようだからこれをマクロと言うこともできるしテンプレートと言う事もできるように、アスペクトと言うこともできなくは無い。AOPと180度異なるのは、機構はOOの枠内のものを利用しているから後ざしにはできず、関心事を利用するための積極的な介入がコード側に必要となる点で、その意味ではフィルターに近い。が、もちろんフィルターではない。コードによる積極的な関心事への自分挿し込みとか。
ドメインロジックを制御するけどコントローラでもない。コントローラはドメインロジックを呼び出すが、こちらはドメインロジックが呼び出す。で、その結果としてドメインロジックが制御される。なんじゃらほい。
イディオムをそのままテンプレートとしたとも言えなくもない。イディオムを抽象化するとデザインパターンとなるが（相当怪しい見方）、イディオムからパターンとなる実装だけを抜き出したと言えなくも無い。
上のほうではstaticメソッドにしているから動的な変更はできないが、どちらかというと呼ばれるブロック群をインターフェイスとして抽出させることを主と見れば、動的に替えられるようにもできる。つまりテンプレート自体をインターフェイスとすることも可能だ。
_ あぶねぇ
subjectが『納品予定のご連絡』のメールが来たら、まあspamだと思うかも。で、差出人がsexorder@……と見た瞬間に削除するわな。でも良くみたらsxorder@sun.co.jpじゃん。
・頭の中がsexでいっぱいなので見間違えた
・spmaズレしてsとxで自然にそう読み取った
っていうかsxorderってどういう意味だ？
さらに、文字数の問題なんだろうが
Sun Java Studio Creator 2004Q2、1 ユーザ・スリムキ SDSI9-4Q2-T99MC x 1
「スリムキ」……妙過ぎる。（もちろんslimkitだとはわかるが）
2004-11-14
_ 嵐の晩に地獄の蓋があく
ヴィーが出てこようとしている(QuickTime Playerで再生可能)。
子供の頃、ゴーゴリのヴィーを（なんかのジュヴィナイル版で）読んだが、次々と主人公の医学生に襲い掛かる不幸と恐怖のずんどこと最後の馬鹿馬鹿しいほどの救いの無さ（魔方陣＋魔物＋ヴィー＋鶏の結果、あまりに汚らわしい状況となって封印されてしまう）で死ぬほど恐ろしかった。
確か、白黒時代に映画にもなっていて（ムルナウじゃないが、ロシア映画なのかなぁ？ とっても表現主義的だった記憶があるのだが）これまた恐怖に満ち溢れていた。
キエフ（大都会である）の大学で医学を専攻する学生が、夏期休暇だかなんだかを貧乏なもんで徒歩＋野宿で郷里に帰ろうとするのだが、途中の寒村で魔女に出会って死ぬほど怖い目にあう。
その魔女の呪縛からはどうにかこうにか逃げ出せるのだが、それはそれとして一宿一飯の義理のために、（医学生だとばれたので）村長の娘の病状を見ることになると、なんとこの女が件の魔女じゃないか。恐れおののき断ると、義理が裏返って「タダ飯食ったんだから奴隷になるか、病気を治すかどっちかを選択しろ」と迫られる。
かくして恐怖の夜が始まる。
っていような感じだったけど、実際のところはどうだったろうか。
医学生の合理精神と、それを根底から破壊し尽くす田舎に実在する非合理的な日常(理不尽という言葉がまさにぴったりだ)という、（と書いてふと思ったが、ゴーゴリ版注文の多い料理店なのかも）、それだけで読書人（まあ、19世紀ロシアなんだから都会に住む合理主義者であろう）を慄かせるには充分な主題の中に、ロシア文学の巨匠がこれでもかこれでもかと色んなおっかない迷信やら伝承やらを注ぎ込んでいるものだから、怖くないはずがない。
というようなことを想起させるある嵐の夜の記録である。
_ おお、いい言葉だ
やれないことはやらない、やりたくないことは後回しにしてきたのが、Rubyを10年以上継続して開発できた秘訣です。
——[ruby-list:40298]
これは直観的に正しく、しかもRubyの存在によって実証されているわけだし。
問題は、これをリアル（というかビジネスというか）ワールドに適用することが基本的には不可能だということなのだが。
#語られた文脈では「私はこうやって続けてきたわけだから、それから外れるのはリスキーである」という意味になるのだろうから一般化してはいけないんだろうけど、非常に心地良く響く言葉なので一般論にしたくなる誘惑にはかられる。
2004-11-15
_ ブリキの太鼓
](https://m.media-amazon.com/images/I/21DR1E95GDL._SL160_.jpg)
思い出したので貼っておいたり。
とは言え、映画は見たことないんだけど。見る気も起きなかったのはオスカル（主人公の太鼓を叩く子供というか少年というか青年）のイメージが違い過ぎたからだ。
でも、シュレンドルフでAmazon.co.jpを探索してもブリキの太鼓しか出てこないのか。ましてファスビンダー（僕が1番好きなドイツの作家）では何も出て来ない。
オスカルのイメージを決定付けたのは集英社文庫のカバーだ。では、本を読んだのか？ と言われると実は読んでない。（1巻だけは持っているが）
なんで読まなかったんだろう？ 読みたくなかったんだろう。
ではどんな太鼓なら知っているかと言えば
ジャパンだったり。
なんで星が1つなのかと思ったらCCCDだからか。というか退屈だと思う。紳士は写真を撮る。あの島へ私を連れてって。静かな生活。このあたりは必ずしも今でも聴かないわけでもないが、ミックカーンのベースだけが印象的なわけだし。
実際このアルバムは最後が意味深にもすごく浅く感じる。
Cantonese boy, bang your tin drums...(あやふや)
なんで広東の少年？ なんでブリキの太鼓？
なんか在広東少年とギュンターグラスをごっちゃにして、しかもそこに何もなかったり（プロモだと紅衛兵の格好をして大砲に火を点けていたように記憶している）。いずれにしろ勘違いとしか思えない。
2004-11-16
_ Javaらしい
うーん、インターフェイスを決めて、がんがん無名インナークラスで処理を差し込んでいくのがJavaらしい（Javaならでは）だと思うのだが。（半分は言ってみただけだが、半分はRubyらしさの「挙動によって多数のクラスを使い分けるようなものではなく、挙動の違いをブロックで指定できるようになる」についてRubyではそうは思わないがJavaだとそのほうが良いように感じるなぁ、という感想から割と本気——でも仕事上のコードは別だけど——）
_ うが
結構、間違ったこと書いてるよ。(追記：この書き方だと記事そのものについて書いているように読めますね。すみません。作者の声の部分についてです（例えば下に書いているようなこと）(更に追記：全然「結構、」じゃないのだが(2ヶ所だし明らかな間違いはML名だけ)、なぜ最初にそう書き始めたかやっと思い出した。最初に開発動機としてJavaには気に食わない点があるとしているのに、3番目の目的がJavaとは無関係な理由になっている点だ（っていうことは現実を無視して3個の目的と誤算を書こうとして題を決めたのではないかという疑念も出てくるが、実際には3つの目的は正しくその通りで、最初に要約するときにちょっとしくじったというのが正解。したがってそこを読んだ瞬間に「結構、」と書いたのだが構造的な問題なのでついさっきまで何が間違いなのか忘れていた。っていうかこれは修正してもらってもしょうがないな、今更）。
ruby-listじゃなくてruby-talkだし。
あと、謝辞を入れてるけど（多分、桑島さんだとは思うけど）テストを手伝ってくれた無名の人のことを書き忘れてますね。感謝してるです。
それから、babieさんから指摘されて目的の2が誤解を招くかもと気付いたので補足。
例）今、こんなクラス（例えばStruts用にモデルとして作成したクラス）があるとして
public class Foo {
public ResultData {
String name;
private ResultData(String s) {
name = s;
}
public String getName() {
return name;
}
}
Connection conn;
// DI.
public void setConnection(Connection c) {
conn = c;
}
public ResultData searchName(String address, String account) {
assert conn != null;
ResultSet rs = null;
try {
....
ResultData r = new ResultData(rs.getString(1));
return r; // こういう連続した2行でしか出現しない変数に複数文字割り当てるのはムダ。
} finnaly {
if (rs != null) {
try { rs.close(); } catch (SQLException e) {}
}
}
}
}
これをシェルの中で使いたいと仮定する（この例はやたらと単純なのでRuby-DBIで充分だけど）。テストというわけではなくて、たとえばフラットファイルで与えられた行から（この例で言えば）名前を得て別のファイルへ追加して書き出すとか。
っていうような場合にrjbを使う。DI前提としているのでこのへんは楽なのだ。
#っていうか、CLASSPATHは修正しなければ。っていうか、桑島さんのパッチの取り込み含めてさっさとやんなきゃ（と言いながら週末を待つ）
#RubyJDWPはおもしろいな。
2004-11-17
_ かっこいい
やっぱ、プログラミング漢(guyと振る)はこうでなきゃな。「必要なことは全部 Rubyist Magazine の記事に書いてあるから」とさらりと言うところがいいな。
_ おもしろい
車輪は2個必要だ（セグェイしかり、芝刈り機しかり、自転車しかり）。
でも、なんか違うような気もするが。両方が間違えてる可能性ってテストプログラムが間違える可能性より高いように思うんだけど。
_ 試してみたり
何にも選択していないとcurrentTrackがnilになるな。
# playing.rb
require 'win32ole'
itunes = WIN32OLE.new("iTunes.Application")
track = itunes.CurrentTrack
if track.nil?
puts "not playing"
else
puts "#{track.Artist} - #{track.Name} (#{track.Album})"
end
かな。
_ 結構おもしろい
トラック名がマッチしたものをプレイリストに登録して再生するとか
require 'win32ole'
if ARGV.length != 2
puts 'usage: ruby plist.rb list-name track-name'
exit(1)
end
itunes = WIN32OLE.new("iTunes.Application")
list = itunes.createPlayList(ARGV[0])
r = Regexp.compile(ARGV[1], Regexp::IGNORECASE)
itunes.libraryPlaylist.tracks.each do |trk|
if r.match(trk.name)
list.addFile(trk.location)
end
end
list.playFirstTrack
track#locationはファイル名（多分URLとかもあり）だった。
list#addFileのほかにlist#addUrlもある。っていうかlist#addTrackというのもあるから素直にやるなら直接トラックを追加するほうが良いかも
if r.match(trk.name)
list.addTrack(trk)
end
_ もっと試してみた
オムニバスとかも突っ込んだりしてるので重複しているエントリーがある。それを削除する危険なスクリプト。名前とアーティストと時間だけでチェックしている（というかアルバム名をチェックしたらだめだから）。ただし、このスクリプトはトラックを削除するだけ。
require 'win32ole'
h = Hash.new
a = []
itunes = WIN32OLE.new("iTunes.Application")
itunes.libraryPlaylist.tracks.each do |trk|
s = sprintf("%s %s %s", trk.name, trk.artist, trk.time)
if h.key?(s)
puts s
a << trk
else
h[s] = true
end
end
a.each do |trk|
# File::unlink(trk.location) #コメントは外さないほうが良いと思うが。
trk.delete
end
っていうのとは別に、動かしてわかったがファイルは削除したのにエントリーが残っているのもある(iTunes上は左端に!で示されている)。そういうのをプレイリストから削除するスクリプト。
require 'win32ole'
a = []
itunes = WIN32OLE.new("iTunes.Application")
itunes.libraryPlaylist.tracks.each do |trk|
begin
if trk.location.empty?
a << trk
end
rescue
p trk.name
end
end
a.each do |trk|
trk.delete
end
途中でrescueしているのは、URLをインポートしたトラック。この場合、Track#locationはメソッド自体が存在せず、かわりにTrack#urlがあった。
2004-11-18
_ 盗賊と言っても
買って読んだ。大体。
義和団の洪秀全を除けば出てくる大盗賊は全員国祖と言える人物なわけで（李自成は3日天下だけど）ちょっとスケールが違う。
見方によっては、よその国のありようを泥棒が作った国と腐しているわけだからつまらない本とも言えるし、実際個人的に目新しい発見は李自成の軍師の李巌が架空の人物らしいという点くらいだ。
実際には、盗賊という呼び名の意味は最初に民間の武装グループという意味だとしているわけだが、それにしてもタイトルは「大盗賊」で解説もなにもなく、しかも自分で書いているように一般的な日本語での意味と異なるのだから（こういうネガティブな呼び方をする必要はない）、あえて誤解を招くようにしていると言えるだろう。しかも後記を読むと著者は「盗賊伝」のように「大」すら抜きにしたかったようだから、この点だけに着目すれば単なる反共爺さんが中共を腐すために上梓したと読んでも外れではなかろう（ということと、大躍進が地獄の結果に終ったというようなことは別の問題だろう。盗賊が作った国でなくても失政で餓死者が大量に出ることはある。にしても盧山会議についての書物——もちろんこんな本ではない——を読むとどうにも困った主席と愉快な中間達だったようではあるが）。たとえば大躍進の失敗の原因として土咆炉に見られる技術的な問題点などは一切無視して（あるいは知らないのか）単に根性で頑張るだけなら失敗しても当然のような（それはそうだ）どうでも良い書き方しかできていないわけだからなんなんだろうね、この本は。
というわけで小盗賊のような本に小金を巻き上げられてしまったということだ。
2004-11-19
_ ひさびさにRPGやってみたり
ぴちょん君の四川省を果てしなくやっているうちに別のことをしたくなったり。
地下鉄がほとんどだからそんなにBlogを見ることもできないし。
で、エストポリス伝記DXが比較的安い割にはおもしろそうなので買ってみた。NethackというかRogueみたいだし。が、ミミックとかゴーレムが出れば確実に全滅しちゃうからB8Fより下に行けない。こんなに難しいもんなんだろうか？ それとも何か根本的に間違ったやり方してるのかなぁ。
2004-11-21
_ からさわぎ
助田さんもいらしてたのか。とはいえ200人もいれば気づけなくてもしょうがないかも。酒匂さんはおいででしたね。
WRさんには何を今更のように思われたみたいだけど、どうも外部向けの仕様書というのは何をどう書いたらよいのかわからなかったりしていたので（というか、わからなくなってしまったので、かも）、くーすは間違いなく参考になりました。相当、思い当たる節もあったし。
ひがさん、はぶさん、その他スタッフの方々、どうもありがとうございました。
#それはそれとしてS2JSFって、これまで誰も完全には実現できていなかった(と思うけど世の中は広いから他にもあるかも、と追記)埋め込みHTMLのそのままブラウザーでの表示可能性をクリアしているんですね。すごいな。
_ 糊と紅玉
日本人はRとL、VとBの区別がないから、Groovyって言われるとどうしたってGlue+Rubyって空耳が聞こえるとか。
_ rjb
桑島さんのコントリビュートの取り込み（gccで警告が出るので多少修正しています）と、立石さんから指摘されたCLASSPATH取り込みのバグ修正、Rjb::loadの第1引数の削除（修正しようと思ったけど、JVMのバージョン指定ではなくJNIのバージョンネゴシエイション用だと気付いたので、思い切り削除。それでは指定可能とする意味がない）。
桑島さん、立石さん、ありがとうございます。
#一応、CLASSPATHバグについてのメモ：PATH_SEPは、文字ではなく文字列。%cで取り込んでいたので%sに修正。CLASSPATHのプロパティ名はjava.class.pathなのに間違えてenv.class.pathと記述していた。という2重のバグでした。
2004-11-23
_ 大黒柱
新しいアプリケーションを設計する際には、将来的に窒息死しやすいように設計するということだ。
っていうのを読むと、何で読んだか忘れたが昔の家は大黒柱と束石の間にくさびを入れるだかくさびを抜くかだかするとぱらぱらと家が自然と解体できるようにできていた（うそ臭いな）というようなことが想起される。
_ なんだかわからないが音が届いている
ヒカリというギタリスト兼ヴォーカル兼ソニックデザイナーがいる（いた？）んだが、あれは一体なんだったんだろう？ グーグルで検索してもオークションに出ているのが見えるだけでそれ以外に何もない。と思ったけどHIKARIで検索すりゃいいのか。まあ、でもカタカナにしておくか。
確かにグッド・バイ・スプートニックというCDが手元にあるし、Laoxだと思ったけどテクノがどうしたとか手書きポップも覚えている。ギターでテクノか、XTCみたいなのかな、とか思った(全然これは外れていた。XTCみたいなキンキーな要素は無い。すさまじく滑らかだ)記憶も残っている。髪は金色で宇宙服みたいなのを着ていてはっきり言ってかっこわるいルックスなのだが基調の青とスプートニクという言葉の選び方にツボを突かれてつい買ってしまったのであった。
聴いてみると歌いかたも僕が嫌いなギターをギツァーと発音するようなタイプなんだが、メロディーラインの作り方がうまいし、音の混ぜ方がきれいで、しかも言葉の選び方がうまいからとても心地よい(スプートニクとかライカとかの固有名詞によってもたらされるイメージってあるわけだ)。描かれているのはスペキュラティブなサイファイ(たとえば過去と未来を行ったり来たりしながら伝説を作っていく僕たち2人の出会いと別れの風景を描くJesusとか。わけわかんねぇな)で、軽薄といえばこれ以上ないほど軽薄なのだが、声と音の軽さとあいまってそれが——つまり心地よく響く。気に入っている。
前回聴いたのは2003/9/8らしいな。
_ 君はオレになる、オレはネコになる
こんだパンタか。（iPodでランダムに聴いているのであった）
_ 00（マネ）
シングルトンのビジネスロジックが山ほどあるとする。これはOOとしてどうなのよ？
コードってなんだろう？
コードは振る舞いを規定するものだ。あたりまえ。
コードはデータを持つか？ ——持つ。なぜならば、コードによって表現されているものには条件判断するためのデータがあり、ループするためのデータがあり、フロー制御するためのデータがある。それらのデータは外部から与えられる場合もあるが、コードに内在している場合もある。さらに言えばコードはそれ自体がデータだ。
コードは振る舞いを持ち独自のデータを持つ。すなわちオブジェクトの要件をある程度まで満たしている。しかしJavaの場合コードそのものにはアイデンティティが無い。このため、コードはそれだけではオブジェクトとして扱うことはできない。
言い換えると、Javaではコードはメソッドとして実現されているからそれ自体をインスタンスとして扱うことはできない。あるクラスのインスタンスのメソッドとしてはじめてインスタンス化される。コードそれ自体は本来的にスタティックであるがオブジェクトの多態性（交換可能性を満たすために必要）を実現するためには、インスタンスメソッドとして実装する必要がある。
まとめるとこのようにして実装されたコードにとってクラス#メソッドシグネチャがアイデンティティなのでスタティックメソッドでも良いのだが、さらにストラテジとして(多態に)扱えるようにするにはスタティックではなくインスタンスメソッドとしなければならない。また、可変なパラメータは外部からメソッド呼び出し時に与えることが可能なためシングルトンでよいことになる。
結局
ArrayListfooList = new ArrayList (); ... for (Foo f : fooList) { f.bar(); } ...
として扱うことができるFooのインスタンスはもちろんオブジェクトだということだ。
ここで
class Foo {
public Foo() {
...
}
public void bar() {
...
}
...
}
というようにFooが定義されているとOOで
interface Foo {
void bar();
}
...
public FooImpl implements Foo {
static FooImpl singleton = new FooImpl();
private FooImpl() {...}
public static Foo get() { return singleton; }
public void bar() {
...
}
...
}
ならOOではなく「シングルトンいくない」というようなことを言い出すとしたらそれは森を見ていないことになる。あるいはメソッドをオブジェクトとして扱うということが理解できていないかだ。
最終的にこういったシングルトンは
... fooList.add(FooImpl1.get()); // FooImpl1のシングルトンの取得 fooList.add(FooImpl2.get()); // FooImpl2のシングルトンの取得 ...
となり、個々のインスタンス毎に振る舞いとデータを持ったオブジェクトとして動くからだ。Javaの表現としてはメソッドをオブジェクトとして扱うためには単一のクラスとそこから生成される複数のインスタンスではなく、複数のクラスによるそれぞれのインスタンスとなるということである。
まとめるとビジネスロジックというのは、それ（ビジネスロジックを提供するメソッド。クラスではなく）自体が抽象度が高いオブジェクトである。そしてそれをJavaで実現するには、シングルトン(ロジカルにはそのクラスの複数のインスタンスを作成する意味はない。なぜならばこのクラスはメソッドを提供すること以外に意味がないからだ）が良く（同一アイデンティティのオブジェクトが複数生成されるのは気味悪いでしょという感覚的な理由と、生成コストがまったく無駄になるという現実的な意味の両方から）、外部から与えられるパラメータと必要に応じて処理中に利用される外部のエンティティにのみ影響を与えるのだからステートレスであるべきだということになる(実装の都合でインスタンス変数を複数の内部的なメソッドでの共有資源としてグローバルに扱う必要がゼロになるとは言わないが、意味的にはインスタンス変数は不要である。なぜならばコードそのものにデータがあるからだ)。
2004-11-24
_ 基礎はどこまで必要なのか？
人類が人類たるゆえんは火を獲得したことだと、ギリシャ神話は教えてくれている。
ということは、人類にとって真に基礎的な技術は、1.山火事の中に入り込んで火を自分の住処まで持ち帰ること、2.木を擦り合わせて火を興すこと、3.噴火する火山へ昇って流れ落ちる溶岩流を飛び越えたり飛び交う石をよけたりしながら火を自分の住居まで持ち帰るってことだろうな。
2.のバリエーションで弓を作って回転させるってのもありだな。この場合は、弓を作るって技能で、これは飯の種にもなるから非常に良い技術だ。
では、そういう基礎的な技術を学ぶ必要ってあるのか？ と言えばマッチもライターも手元にない状態で無人島に流れ着いたら必要になるかも。このあたり煙草吸いはライターとか持ち歩いているからより文明的なマージンがあってハッピーかも知れない。
IDEがどうしたとか言う前にこういった真に基礎的な技術力を身につけて欲しいものだ。
でも、もっと基礎的な技術ってのは、貝殻のような無価値なものに価値があるように見せかけることで価値あるものと価値なきものの交換手段を確立した詐欺師のじゃなかった貨幣流通の技術を築いた何者かが発明した口八丁の技術なのかも知れないな。こういう技術って学校とかでは教えてくれないのが問題だろう。というわけで欺術は人類の進歩と調和には欠かせないから社会で学んでいくしかないだろう。OJTとか。
でももっと重要な技術ってのは子孫を残す技術かも知れないな。これもきちんと基礎から叩きこまれるってことがないように思える。QC活動とか。オーストラリアの大学では教えていたかも知れないが。
でも別の観点からより重要な技術ってのは正しい噛みかたとか消化のしかたとかかも知れないな。
いや、しかし、日本人として生まれたからには神武天皇から全部の名前を言えなきゃならんだろう。九九とならぶ基礎の基礎だ。紀元は2600年。
いずれにしろ、こういった基礎をやる前に統合開発環境を使うから最近の若い者は髪の毛の色が薄いんだ。昔の人は緑の黒髪と言ってそれは黒々としていたものだ。もっとワカメを食べろ。それに耳や鼻やヘソから金属が飛び出しているが、あれは鉄分の過剰摂取が原因に違いない。もっと米を食え。
忠君愛国少なきかな仁。
_ おお
もちろん本当は、「巧言令色少なきかな仁」だけど、適当な4文字熟語と組み合わせるといろいろもっともらしいぞ。
謹厳実直少なきかな仁。
滅私奉公少なきかな仁。
重厚長大少なきかな仁。
子孫繁栄少なきかな仁。
山寺和尚少なきかな仁。
前途洋洋少なきかな仁。
針小棒大少なきかな仁。
政教分離少なきかな仁。
三権分立少なきかな仁。
国体護持少なきかな仁。
老若男女少なきかな仁。
日本全国少なきかな仁。
共存共栄少なきかな仁。
国家安康少なきかな仁。
結局南極少なきかな仁。
2004-11-25
_ LPがCDになって失われたこと
知ってる人は知ってるがA面とB面が無くなったこととか、最後をループさせることが（多分）できなくなったこととか。最後のループか。イーノのタイガーマウンテンだかウォームジェッツだかがそうだったな。
あと30センチというサイズを失ったことも結構大きそうだ。見た目重要なものって小さくなって良くなるってことはほとんどなさそうだ。東武ワールドスクェアみたいなのもあるからすべてがすべてそうだとは言えないだろうけど、大仏が5cmくらいだったらこれっぽっちも有り難味はないだろう。
でもそんなことはどうでも良くて、A面とB面という区別が無いLPだ、問題は。
結局、ジョージャクソンのナイトアンドデイを買って何度も繰り返して聴いたが、やはりすごく違和感がある。ありまくる。これのLPにはAB表記が無くてナイトとデイの2つの面があるだけだったからだ。
確かにタイトルがナイトアンドデイなんだから、ナイトサイドを聴いてからデイサイドを聴くのが正しかったんだろうな、とは思うし、事実CDはナイトサイドから始まるんだからそれがジョージャクソンの意図なんだろうが。
でも、すでにBreaking Us in Twoから聴き始めて最後にSteppin'Outで終るというのが確立されてしまっているんだからどうにもならない。
大体、Another Worldというちょっとだるい感じの曲で始まるより、Don't you feel like trying something new ?とBreaking Us in Twoの問いかけで始めるほうが気持ちいいし。最後をSlow Songなんていうスローな曲で締めるより、軽快なSteppin'Outで終るほうがいかしているじゃん。それにリアルワールドな面を聴いてから引っくり返してAnother Worldというほうがロジカルだし。
というように、LPならアーティストの意図を誤読して楽しむことができたのに、CDみたいなリニアなメディアじゃそういうことができないんだよね。とは言え、LPのCD化だからそういったことが言えるわけであらかじめCDを意識して作成されたものであればそんな誤読が入り込む余地はないのだが。
でも、誤読の余地がないってのもつまらない。
2004-11-26
_ 値型と参照型
otsuneさんのとこの日記を読んで考えた(とトピックの逆方向をやってみたり)。
構文は同じだからint i = 9;とObject o = foo;は一見同じことを表現しているように見える。Rubyのように実際、同じことをしている場合もある。が、JavaやC#ではこの違いはパフォーマンスという観点からは比較的大きい。
Webページで例えるとわかりやすいかな？ とふと思った。
今、自分のWebページで言及したいページを見つけたとする。
参照型の代入というのはアンカータグを文中に埋め込むことに相当し、値型の代入というのはブロッククォートでページ上の文章を引用することに相当する。
参照型では、リンク先の文章が勝手に変わってしまうことがある(Webはマルチスレッドだから)が、値型は勝手には変わらない。値型である手元の引用した文章はいくら変えても元のページには反映されない。
参照型はアンカータグだから、何かするためには必ずリンクをたどらなければならない（その分、パフォーマンスは低下する）が、値型は手元のページなのでそのような操作は不要だ。
C#の構造体が値型だというのは、配列で大きな意味を持つ。
ブロッククォートのリストと、アンカータグのリストを考えてみる。
ブロッククォートのほうが不利な点はページのサイズがでかくなることだ。一方、アンカータグであればページのサイズはタグの分でしかない。しかし、連続して操作する場合には、いちいちリンクをたどらなければならないアンカータグのほうがパフォーマンスは劣化する。
勝手な妄想であるが、Webの構造を意識している人のページでは、他のページへの言及はリンクが多く、紙文化になれた人のページでは、他のページへの言及には引用が多い、かも知れない。値型のほうがおそらく直観的なのではなかろうか（全然、根拠ないけど）。
っていうか、この最後の妄想についてさらに上塗りをすると、論文は引用は要旨にとどめ最後に参照文献としてリンクするが、論説は読者の(その場限りの)便のために引用が普通だ（へたすると参照文献へのリンクすらない）。論文がリンクを使うのは読者が参照先を読むこと（あるいは参照先を「直接」参照すること）を前提とし、論説は読者はそんな手間をかけずその場限りで終らせるだろうことを前提としている。おお、理系文化、文系文化論がでっちあげられたぞ。理系＝参照型、文系＝値型。でも、僕は理系/文系論ってくそだと思っているから間違いなくヨタだけど。
_ Web GC
デッドリンクが発生しないようにする仕組みってできないだろうか？ ってそりゃ無理だな。でもデッドリンクを見つけたらarchive.orgやGoogleキャッシュからどっかの殿堂へ移動してそこへの参照に付け替えるスパイダーとかが蠢いていたら(って言うかそれはページが勝手に更新かかるということになるけど自サイトならできなくはないかも)、すごくサイバーだ。リンクがある限り消したくても消せないシステムだ。
当然、逆も真というかGCなんだから、誰からも儀礼的な無関心されているページは次々と削除されてしまうという。
追記：というのを受けて
2004-11-28
_ POIメモ
POIをいきなり見に行くと複合文書についていろいろ書いてある。でも、やりたいことは単にExcelで処理可能な、でもCSVやタブ区切りではないファイルの作成だったり（拡張子がxlsのやつ）。
で、そのドキュメントを探すのにちょっと苦労したり。だって複合文書用のファイルシステムがやたらと多いから。で見つけて使ってみるといきなり日本語が正しく表示されなかったり。
というわけでとりあえずシート名を日本語にし、セル内に日本語を埋め込むサンプルのメモ。
import java.io.FileOutputStream;
import org.apache.poi.hssf.usermodel.HSSFRow;
import org.apache.poi.hssf.usermodel.HSSFCell;
import org.apache.poi.hssf.usermodel.HSSFSheet;
import org.apache.poi.hssf.usermodel.HSSFWorkbook;
public class PoiTest {
static void setData(HSSFSheet s, int n) {
for (int i = 0; i < n; i++) {
HSSFRow r = s.createRow(i);
for (int j = 0; j < 8; j++) {
HSSFCell c = r.createCell((short)j);
c.setEncoding(HSSFCell.ENCODING_UTF_16);
c.setCellValue((n % 2 == 1) ? "漢字のテキスト" : "abc");
}
HSSFCell c = r.createCell((short)8);
c.setCellValue(i);
}
}
public static void main(String[] args) throws Exception {
HSSFWorkbook hw = new HSSFWorkbook();
HSSFSheet st = hw.createSheet();
hw.setSheetName(0, "日本語", HSSFWorkbook.ENCODING_UTF_16);
st.setColumnWidth((short)0, (short)(256 * 12));
setData(st, 11);
st = hw.createSheet("English");
setData(st, 20);
FileOutputStream fo = new FileOutputStream("test.xls");
hw.write(fo);
fo.close();
}
}
で、
$ javac -encoding Windows-31J -classpath poi-2.5.1-final-20040804.jar PoiTest.java $ java -cp .:poi-2.5.1-final-20040804.jar PoiTest $#意図はよくわかるが、shortってのはガンだな。
2004-11-29
_ 0から始めるか1からやるか
POIは0から始まる。これはJavaの配列のインデックスとも一致している。
しかし、VBAの配列のインデックスは本当は1から始めるのが文法を作った人の意図のはず。だからExcelを初めとしたOffice系のオートメーションではインデクサの引数は1から始まるのではないだろうか。
というかExcelそのもののロウが1から始まってるからかも。0じゃないよ。表計算ソフトの行表示としても1と書いてあるのは多分、正しい（しょせん多分に過ぎないけど。しかし自然数を採用するのは自然ではあると思う）。
だからVBAでの(というかCOMで表されているExcelのAPIとしての)Cells(1,1)というのは、POIのRow=0、Cell=0になるのだが、これってどうなのかな。少なくてもRange("A1")というのは判りやすいし、そこからCells(1, 1)もわかりにくくは無いような気もする。とすればPOIがわかりにくいということだ。でも、最初から0として試し始めていたから直観的なのかも知れないけど、わからん。
同じJavaのAPIでもJDBCは1から始めてる。これはとってもイヤで、getString(0)とか書いて実行時に例外を食らったことが無いわけでは無い。とは言え、SQLの発想としては正しいのかな、と思うし、（実はADOは知っているけどODBCは知らないし、今更調べても役に立たないから調べないけど）多分ODBCも1から始めてるんじゃなかろうか。
っていうか調べてしまった。
ColumnNumber
[Input]
Number of the column for which to return data. Result set columns are numbered in increasing column order starting at 1. The bookmark column is column number 0; this can be specified only if bookmarks are enabled.
——SQLGetDataのAPIリファレンスから引用
そうかカラム番号なのか。なら、1から始まるのはExcelのセルと同じで（多分）正しい発想だろう。
このあたりがPOIの注意点かな。Excelのオブジェクトモデルとは全然異なるということで。
2004-11-30
_ タビアたん
おれも、日本人はアクティブたんとか、FreePeekたんとか呼称せよとか書いてみれば良かった、と一瞬思った。根拠なく。
Via How My Hear Sings。
ところでタビアたんってなんなんだ？ タブブラウザなのかな。
ジェズイットを見習え |
_ dVmfB [ valium class of medication - 5mg valium anxiety]