2004-06-09

リターンキーと呼べ！

　最近、自分がオールドタイプであるという事実を突きつけられることがおおい。

　みんなBackSpaceキーの下のでかいキーのことをなんて呼んでる?　って普通「エンターキー」だよな。オヤヂなら「改行キー」か。
　しかし、PC98世代のオイラはこれをリターンキーと呼ぶのさ。ええ、もうどこにも「リターン」なんて書いてません。
　これなんでリターンって呼ぶかというと、日本の歴史に残る迷機 PC-9801シリーズのキーボードでは「リターンキー」と定義されていたから、ですかね。SHARPのX-1シリーズやX68000でもそうだったんじゃないかな。
　いや、もうウソみたいに通じません。「ええっと…そうそう cat hogehoge 、でリターン」「はい?」「え、だからリターン」「リターンってなに」みたいな。そうですね、あなたの方が正しいです… orz

　PC-9801のキーボードにはこんなキーもありましたよ

"Help"キー。ちなみに押してもヘルプなんて出てきませんよ。諸行無常を教える意味なしキー。
"Graph"キー。さらに古い世代のころはこのキーを押しながら文字入力すると罫線がはいったりしました。PC-9801における"Alt"キー
"KanaLock"キー。カナキーですね。
テンキーに "," があった。すげえ便利。なんでないんだよ。 > AT標準
"STOP"キー*1。このキーだけバネが硬い。とにかく強力なキー。一撃で外部割込み発生。DOS最強の味方。
"COPY"キー。まあ、これはPrintScreenみたいなもんか。たまに機能します。

　懐かしい。ていうかまだ他にもあったような。忘れてます。

*1:SHARPは "Breakキー"でしたっけ

2004-06-09

続・旧型体制向けUnitTest

システム開発

reki 『Mindとはまた…… それはそうと、逆にJUnitTestのソースコードから assert を抽出してを帳票化するアプローチの方が現実的でない?』

　というコメントからいろいろ考えてみる。

　まず、帳票化する意図は何かというとどんなテストを何項目実施したか、を洗い出すことなのだが、マッピング上はこんな感じになるのか。

あくまで testHoge() testFuga() で1項目ずつになる
testHoge()内には当然assertが含まれまくっているわけだが、これは「１項目」の中の「事前条件」「事後条件」である。

　と、すると、

「事前条件」「事後条件」を判断する方法がない
「処理内容」を検出する方法がない

　という問題がある。前者に関しては例えばアノテーションのような方法を使えばいけるのではないか?　いや、もっといい方法があるのか?

J2SE1.5ならannotationで「事前条件」と「事後条件」のアサーションを明記してやればいい
TestCaseのサブクラスを作る。これは例えば HytelighsysTestCaseみたいな名前を付けるとして、 assertPreTrue() とか assertPostTrue() とかになっている。ここまで来ると、シグネチャの違いから事前と事後の区別が可能である。

　なんとなく、この方法は現実的かもしれないぞ。では「処理」を追跡する方法はどうか…?　うーん、これはさすがに「Java -> 日本語逆コンパイラ」が必要になりそうなので、単純には難しそう。
　ただ、上のアノテーションなんかを「使っていい」ということにするのであればこの際

/**
 * .
 * .
 * @testcase:subject 
 *   データベースに10秒以内に接続出来ない場合にエラーログが出力されることを
 * 　確認する
 * @testcase:pre
 .
 .

　というようなことも可能ではないか。

　あれっ・・・これって XDoclet的アプローチ…

　またまだ奥は深い。

2004-06-09

LombozのRC1対応版

Java

　eclipseでJSP編集する人愛用のLombozのメンテナンスが長らく遅れている?ため、M9とかRC1で動かなくて困ってる人向け。

RE: Eclipse 3.0M9 and Lomboz [ 返信 ]
2004-06-04 16:37  
Ok, here it is: 

http://rainbow.mimuw.edu.pl/~po189428/lomboz-cvs-for-3.0-rc1.tgz 
md5: 393366d4a75eb2e33cb08d20fe4f2f45 

Thanks for these binaries,

試してみよう。

2004-06-09

assert構文とDbCの関係

Java

　JDK1.4からサポートされたassertを使ってDbCする…ということを考えるときに、assertの振る舞いについて考えたい。
　assert自体はビルドセットの切り替えみたいなもので、起動時やコンパイルタイムでそのon/offを指定できるという特徴がある。しかしながら、「制御できないアサート時の動作」という問題もある。ここでは、常に AssertErrorが throwされるという問題がある。
　狭義のDbCをそれこそマニュアル的に遵守して実施するとすれば、メソッドの入り口には引数のチェックが入る。ここで、丁寧なプログラマは

public void hoge(int a) {
  if (a<0 || a>10) {
    throw new IllegalArgumentException("arg a must be between 0 and 10");
  }
  ...

　などというコードを書くだろうし、私自身これを推奨したい(場合による)。
　そしてassert推進派はこのスタイルを「古い」と指摘する。

public void hoge(int a) {
  assert a>=0 && a<=10;
  ...

　このコードは一見簡潔に見えるが果たしてそうなのか?　まずthrowされるものは非検査例外という点で共通している。IllegalArgumentExceptionは明示的にcatchする必要はない(コンパイラがエラーを吐くかどうかという点で)。AssertionErrorは、"Error"であるのでもはやキャッチして処理する必要すらない、ということになる。
　しかし…「そんなことが起こるはずはない、AssertionErrorだ」というのは、publicメソッドの引数で実施してもいいものだろうか?　私の答えは現段階では"No."である。DbCの理念とも一部関係があるかもしれないが publicメソッド、ならびに外部から利用される、もしくはインタラクションのあるクラスは、その事前条件のチェックについて必ずしも "Error" だと言えるほど責任を放棄できるものではない。
　Sun自身の文を引用してみると…

同様に、public メソッドの引数チェックに assertion を使うべきではありません。引数チェックは一般にはメソッドの責任であり、この責任は assertion の有効無効に関わらず遂行されなければなりません。引数チェックに assertion を使うことにはさらに別の問題もあります。誤った引数は IllegalArgumentException、IndexOutOfBoundsException、 NullPointerException といった実行時例外を引き起こすべきです。しかし、assertion の失敗は例外を throw しません。

　大賛成。
　そして、以下の文にも賛成できる。

しかしもし、public ではないメソッドに事前条件があり、クラスの使用者がそのクラスを用いて行うことに対して事前条件は何も影響しないとクラスの作者が信じるなら、assertion は適当です。

(snip)

単純な assertion 機能は契約による設計スタイルのプログラミングを、限定された形で可能にします。assert 文は事後条件とクラス不変条件のチェックに適します。事前条件チェックは相変わらずメソッド内で行うべきです。事前条件チェックは、API 仕様書に書かれた特定の例外を throw します。 IllegalArgumentException や IllegalStateException といった例外です。

　間ー違いない