CFリプレイ『世界の卵』

異界戦記カオスフレアSCリプレイ『世界の卵』

カオスフレアのリプレイ、久々登場。
1話目はRole&Roll（これはサタスペと違って最近のVol.49～50）に掲載されたものを加筆したもので、2話目はその続きで書き下ろし。
SCの前の旧版からのキャラも、1話目はエリオット、2話目は暁生が登場。（でも暁の戦士たちの内容、忘れちゃった(爆)(汗)）

加筆だそうだけど、削れたものもあって残念。
フェーズとフェーズの合間のパスの取得の際の会話とか面白かったのにな～。取ったパスが欄外にさらっと書かれているだけなので、面白みが減っちゃった＞＜
（その点、アジアンパンクGO!GO!は欄外のツッコミ（「オレだ」とか）も面白かったｗ）

どうも最近のリプレイの単行本は、ルール説明はよく省略されちゃうよなー。カオスフレアもSCになって変更されたルールの特徴が雑誌には載ってたと思うんだけど。
（後半になって突如出てきた「差分値」っていったい何だろう？＾＾；
欄外がいっぱい空いてるんだから、埋めてくれても…ってルール説明なんかいちいち書くのは大変だろうけど(苦笑)）

ところで、最近の単行本ではセリフのPC名の間違いが1冊につき1回くらい見受けられるが、p.163の「誰か」とp.164の重複はちょっとひどい(苦笑)
（でもリプレイの原稿ってそうやって修正しながら書いてるんだなーと(笑)）

それにしても、2話目も良かった。シナリオの仕掛けも良かったし、いいなぁ、こういう終わり方＾＾
美酒町の説明とか、珍しく読みふけっちゃったよ。
追加データの魔法少女とかフィストウォーリアーの技名も、おいおい！って感じだし(笑)

サタスペリプレイ『アジアンパンク GO!GO!』

サタスペリプレイ『アジアンパンク GO!GO!』

サタスペのリプレイが初めて単行本になって発売された！
と思ったら、新作じゃなくて、だいぶ前のサタスペ食べ放題のリプレイの収録だった。（でもさらに大元があって、Role&Rollに掲載されていたもの…Vol.が一桁台だからすごく昔だが＾＾；）
でもけっこう加筆されているし、ルールも最新版?に合わせて用語や操作（ダイス目とか）を改変しているようだ。
だから「（当時既に発売されていた）サプリメント（番外地）を使う」という話が、「（今年これから出る）サプリメントを使う」という未来の話になってる＾＾；
しかもRole&Rollで読者アンケートを募集したことは変えられないので、そこは過去の話になっているという矛盾。苦しいなｗ

（加筆されているので、さりげなく解説も増えてる…
だったら情報収集ルールももうちょっと具体例を載せて欲しかったな～。リンクというのがどうつながっていくのか、目的となるSLってどう示されているのか、いまいち分からない…。
ケチャップについては欄外の説明で分かるような気がするけど、p.40に「ジオラマ（51ページ参照）」とあるのは、p.54の間違いかな？）

さすがにそれだけじゃなくて、書き下ろしも加わっている。
気になる弗箱と素子の過去の話…やべー、このオチ、すげー困ったちゃんだよ！(爆)

あと、未来を描いたリプレイもあるらしい…そんなのこっそり(?)後書きに書かれたら、気になっちゃうじゃないか(笑)

テキスト以外のUNDO

テキストコンポーネントはUndoManagerを使ってUNDO/REDOが簡単に実現できるけど、他のコンポーネントではUNDO機能は提供されていない。
でも編集可能なJTableをいじっていると、ついCtrl+Zとか押して戻したくなる(苦笑)
という訳で、JTableでUNDO/REDOを実装してみた。

UndoableEditSupportというクラスがあって、UndoManagerへの通知に便利。
それだけじゃなくて、編集を一括してまとめてくれたりとか、最低限の便利機能が揃っている。

でも一番肝心なUNDO/REDO処理（セルを編集したときに戻すとか行を追加したり削除したりして戻すとか）は自分で作らないといけないので、けっこう大変。（なにせメソッド数が多い）
しかもセルの値って「Object」だから、何でもいいんだよね。Javaではディープコピーがデフォルトではサポートされていないので、オブジェクトを戻し用にコピーしておいても、下手すると別の場所で書き換えられてしまったりする。
こりゃ標準でUNDO機能が提供できない訳だわなぁ。
でもせめて、行の削除前に通知するfireメソッドは欲しかった。

→ExTableModel
（HtJavaDBツールのテーブル編集用テーブルを、これを使ってUNDO/REDOできるようにしてみた）
（どうでもいいけど、RDBの「テーブル」とJTableの「テーブル」ってどっちも「テーブル」なので、区別したいときに困る(苦笑)）

throwsの減少

メソッドをオーバーライドする際、throws句に宣言されていた例外は減らすことが出来る。
減らした場合、親メソッドで宣言されていた例外は暗黙で宣言された扱いで引き継がれる。
と思っていたのだけれど、間違いっぽい(汗)

正解は、その例外は発生しない（という宣言）になる。
つまり、オーバーライドしたメソッド内からthrowすることが出来なくなるし、
そのメソッドを呼び出す側はtry～catchを書く必要が無くなる！

try～catchの必要性も、実行時のインスタンスのクラスやその親クラスにthrowsがあるかどうかは関係なくて、コンパイル時に使用されているクラス（変数のクラスやインターフェース）にthrowsがあるかどうかで決まる。

Vectorクラスのclone()を使ってみたらCloneNotSupportedExceptionのtry～catchが不要だったので、あれ？と思って調べてみたら、そういう事だった…。

JavaDBのドライバーのキャッシュの問題点？

HtJavaDBツール（自作のJavaDBアクセスツール）では、derby.jarの場所を動的に変えられるようにしている。
でも全く同じjarファイルでも、クラスローダーのインスタンス及びDriverのインスタンスを新しくすると、変更前に接続していたDB（もちろんコネクションは事前に切断（close()）している）に再度接続した時にエラーになってしまう(汗)

この現象は、EclipseのプラグインであるDBViewerを試した際と全く同じ！
（アプリケーションを再起動したら直るが、Eclipseの再起動は時間がかかるのでつらい…その点、HtJavaDBツールの方が再起動はまだ軽い(笑)）
あれはDBViwerのバグかと思っていたが、問題はJavaDBの方だったのか…たぶん。
改めて試してみたら、jarファイル関連の設定を変えない限りは、何回か接続・切断を繰り返しても問題無かった。まぁ、そりゃそーだよなー。

同じEclipseのプラグインであっても、データソース・エクスプローラーの方はjarファイルを設定する箇所が無い。つまりクラスパスにderby.jarが入っている前提で、素直にDriverManagerを使っているのだろう。（少なくとも後から変更しない）
そうであれば今回の問題は発生しないはずで、理に適っている。

あと直接は関係ないけど、JDK1.6.0_13でJavaDBを試してみた。
JavaDBのインストール箇所（derby.jarの場所）が変更されているのは知っていたが、他にも色々便利になってる。
ij.batを動かす際に、以前は環境変数DERBY_HOMEを設定する必要があったが、バッチファイルの場所から相対的に探すようになったらしく、設定する必要が無くなった。（stopバッチもちゃんと動くようになってるしな！ｗ）
とは言ってもij.bat自体が使いやすくなった訳ではないけど＾＾；