変奏現実

真っ先に思いつくのがsvn。こいつはよく壊れるというかリビジョン・デストロイヤーだ。
いつソースが消えるか改ざんされるか判ったものではない。
不味いことにsvnのクライアントのうちでsubclipseが一番最低。長く使うとアチコチと壊れてくるEclipse。その配下にworkspaceを配置するほど愚かなやり方はないくらいだが、そのWorkspaceにそのまんま.svnを配置してうごくsvclipseは独自の管理方法で自己流にやってくれるから、他のクライアントから他のsvnクライアント（亀さんなど）でsvclipseが使っているリポジトリィをいじると、変テコな履歴ができてしまい、クライアント上でクリーンナップしても意味がなく、リポジトリィ上でクリーンナップしても破綻する。こうなったらリポジトリィをエクスポートして作り直すしかない。
さてそんな苦労をしってか、法条　遥の「リビジョン」も現在・過去・未来のリライト合戦になっている。もっとも、時系列は一直線のハズだったのが途中から分岐が始まり、最後には無茶な結末が待っている。
svnでは、thunk（作業机）、branch（パッケージング）、tag（要約）と大雑把なまとめができるようになっているが、小説の方は波瀾万丈。
元々、リビジョンとは改訂の意味で、rev.1.1 で作った。rev1.2で取りまとめて修正、rev 1.3はちょっとしたミス直し、rev2.1は結構手直ししてみた。な感じに纏めるものだ。
しかし、現実は、そんな改訂とは程遠い。
そして、小説は　もっともっと遠い結末だった。
 
 
 

固体や液体は分子や原子の集合体で出来ているというのが定説だが、『物質を無限にどこまでも小さく分割できる訳では無い。なぜなら無限に分割できるなら無から有が生じることになり、どこかで限界つまり最小単位（アトム）があるハズだ。』と云う哲学的な考察から生まれた原子論がそのまま受け入れられた訳では無い、なぜなら最小単位が充分に小さいなら無限に分割可能と考えても差支えないからだ。
近年の原子論は物質にX線をあてるとその反射の具合が一様ではなく、小さな粒がかなりの間隔を置いて配置されているかのような結果だったことに始まる。人間の物質の感触からはX線を反射する小さな粒が大きな間隔を置いて並んでいるという構造は感じられない。（笑
この違和感を埋めたのが素粒子論だった。つまり原子は独特な構造（小さい原子核と周囲の電子雲）を持っているが、この小さな原子核が遥かに大きなサイズの力場を形成し、原子同士はこの力場が作用するため、人間（つまり原子の集合体）には、その隙間を感じることができないとしたのだ。

その原子の構成要素である素粒子はその後結構な数が発見された。素粒子論では素粒子＝力場を形成するもの＝力場を伝達するものと考えているため、力場即ち、素粒子同志の新しい反応が発見されると、新しい素粒子が自動的に生まれることになるからだ。余りにも数が多いので、実際には原子同様に素粒子も内部構造があると考えられた。つまり原子レベルでの原子核のようなものと考えていい。それはクォークと名付けられた。
その意味では原子も素粒子も同じ様な構造（力場とその中に極小さい素粒子がある）もので、実際、水素なぞは陽子とその周囲を電子が回っている様なモデルであり、素粒子のよくあるペア構造と云ってよく、よくよく考えれば原子も素粒子も境界線は結構曖昧だが、素粒子なのに物質にタメ口を吐くのが水素といってよい。物質たる人間はそんな素粒子なら感じられる。
しかし感じるものは何でも物質と人間は思っているので、水素は物質として扱われてる。
物質として扱う都合上、水素はH2と表記され、２つの水素原子が結合した状態であるとされる。
これは、１個の電子が原子核の周囲を回ると、原子核が電子を振り回すような恰好になり、反動で原子核はふらつき不安定だが、２つの原子核を２個の電子の雲が覆うと電子が周回軌道の反対側に位置すれば、原子核の位置が安定するし、２倍のクーロン力で電子が原子核に引き寄せられるため、電子の持つエネルギー量はH×２個よりも高くり、その分他の原子核の影響度は低くなり疎遠になり何かのはずみで大気中の放出されやすいと云える。
一方、クォークは厄介な概念になっている。力場＝素粒子と云うそれまでの素粒子論の考え方が安易だったと反省することもなクォークがあるハズだとく突っ走っているからだ。さらにクォークは素粒子の実態（素粒子の素＋力場）と考えるとクォーク単体での力場は素粒子の力場より強力でそれ故に素粒子同志の衝突でも容易に正体を現さないと考えられている。さらに原子サイズでは素粒子の力場が原子の反応に関与していた様に、素粒子サイズではクォークの力場（＝クォークのサイズ）が素粒子の反応そのものに影響を与えるため、素粒子の力場よりクォークの力場の方が大きくなければならず、それではなぜ原子の反応に直接クォークの力場が介在しないのか不明のままであり、原子・素粒子・階層モデルは概念としてかなり破たんしている。
単純に云えば、地球を構成する物質はどんな圧力でも壊れない原子で構成されているのではなく、それなりの圧力を加えれば原子も壊れてしまうが、そんなレベルでは素粒子は壊れない。しかしもっと圧力を加えれば素粒子も壊れるが、クォークは壊れない。そう考えると、物質は実際にはとんでもなく頑強で絶大な力場を持った何かで構成されているハズだが、実際にはそれを感じることができないからだ。
それを解決したのが力場理論である。
素粒子（あるいはクォーク）はいくつかの力場を持ち、それぞれの力場には力場の到達限界距離があり、地球に例えるなら、表層、マントル層、外核、内核という感じで各力場が目立った働きをする距離（間合い）があるとした。
それも最近では１１階層以上あるらしく、雲行きはかなり怪しく、大方の力場は素粒子よりかなり小さいサイズの到達距離しか持たないとされ、物質に関与しそうな力場は４大力場（重力、クーロン力、核力、弱い核力）とされ、他はビックバンなど非常に高密度で高エネルギー状態でないと反応することはないとされる。
さて、最近話題になってるヒッグス粒子は、質量の力場を構成する素粒子である。他の素粒子の行く手を阻む赤信号の様な陰湿な性格の持ち主である。何だったら今話題の消費税８％と同じと云ってもよく、ヒッグス粒子は素粒子世界の大不況の元凶なのである。どの素粒子も光速度で移動できハズなのだがコイツのせいで一気にスピードダウンし、まごまごしているうちに原子になったりしてしまったらしい。
そうなればヒッグス粒子は見えないし感じることもできないが空間に充満しているはず。否、ヒッグス粒子がぎっしりと詰まっているのが物質界での空間と云えることになる。宇宙には十分なヒッグス粒子がない領域もあるだろう。そこでは素粒子は自由に移動しており、物質なぞないだろう。ただヒッグス空間は広がり続けているらしい。他の素粒子に慣性質量の属性（あるいは力場）を生成するヒッグス粒子がある方向に移動するとそのヒッグス粒子はあらゆる方向に偏在しつつ移動することになる。なぜなら、そうならないと他の素粒子の慣性質量を維持できないつまり運動量を保存できないからだ。そうなると、自らの影武者の影響を受け止めどない自己増殖が始まる。まずいことにヒッグス粒子自体は質量を持たず、他の力場も持たないため、自己増殖に要するエネルギーは理論上０で一度勢いが付けば、際限なく増殖していく。まだヒッグス粒子が増殖していない空間では光速度で移動する素粒子が乱舞する世界。そこに不気味な真っ黒なヒッグス球状空間。まるでブラックホールの内側の世界みたいだ。
しかし、宇宙誕生直後から宇宙空間にヒッグス粒子があった訳では無い。かなり出遅れて出現し、今現在もまき返しの真っ最中。
 
 
 
 
 

定期的にパスワードを変えているが
面倒くさくなるとやばい
無線LANのパスワードを変えたら・・・
あっちもこっちも
 
そして無線LANにしかぶら下がっていないこの鯖のパスを事前に変更するのを忘れていたので
パスワードの変更の仕方もすっかり忘れていた。
 
キーボードとマウスとモニターを繋いで・・・
本当に面倒だった。
 
次は簡単に
 
怪しいのが、無線LANにつながろうとしている
まだ何か忘れている
 
暫くしてその正体が判明。
 
それは・・・
 
寝室のテレビに繋がっている無線LANのアダプターだった
 
youtubeが観れなくて気が付いた
orz

実体は、
private なプロパティにSetter/Gettorを付けただけのもの。

class  xxxBean {

private int aaa;

int getAaa(){ return aaa; }

void setAaa( int aaa) { this.aaa = aaa; }

}

これが美味しいのは、
ちょこっとコードを付け加えると、容易に似たものがいっぱい作れるからだ。
例えば、
void setGMT(Date gmtTime) { this gmt = gmtTime; }
で時刻をセットしたら、
Date getJst() /* 日本　*/         { return gmtTime  + 9 hour; }
や
Date getEst() /* アメリカ西部*/{ return gmtTime  –  9 hour; }
や
Date getEt() /* アメリカ東部*/{ return gmtTime  –  5 hour; }
で判れば便利だからだ。
でも、全世界分のメソッドを作っても、賞味期限は不明なので、別のやり方(Locale)で延命している。
Localeでも新しい標準時刻が規定されれば、新しいstatic Locale を追加しなければならないが、メソッドそのものを追加する必要はない。
だが、５０歩１００歩なので、実際は大きな差は無い。
新しいメソッドを追加しないと国際問題になるが・・・
新しいstatic Localeを追加しなくても
代用で済むならOKな世の中の情勢によるところが大きい。
このBeanを使うと全てのメソッドは大雑把に

XxxBean   aMethod (YyyBean)

に纏めることができる。
が、それはC言語どころかCOBOLでもBASICでも同じで、できないのは古い版のFORTRANぐらいなものだ。
※構造体の概念が欠落しているからね。
しかし、JavaだけBeanとか言っているところが、幼い感じがする。
そう、今のJavaは幼い。
見の丈が足らない。
例えば、インターフェースのための、ヘッダーファイルを定義できない。
インターフェースとして外殻だけだがクラスとしての実態を持たなければいけないので、
インジェクションによる初期化が必要なクセにそのコードの実装は実に巧みに隠しているため、
ソース上は丸く収まっても、実行してみれば・・・インターフェースのオブジェクトの実体はnullポインターなので、Exceptionが容易に発生する。
つまり、一通り出来上がっている振りをしているが、実は使い物にならないのだ。
そのため、jarをいくつもクラスパスに記述しないと、executeすらできない
ボロクソなものになってしまっている。
なぜこうなってしまったのかと云えば
java  xxxxx  -jar zzzzz.jar
と手軽に実行できるので、null pointer exceptionが起きたら・・・
足りない何かをくっ付けて
java  xxxxx  -jar zzzzz.jar　-jar yyyyy.jar
とすれば済んでしまうので、
Javaコードの集合体はセキュリティ的には非常に危ない作りになっている。
java  xxxxx  -jar virus.jar　-jar zzzzz.jar　-jar yyyyy.jar
で簡単に乗っ取ることができる。
しかしサーバー内の話なのでOKということになっている。
ま、侵入されるなら、それ以前の出来事と云うところなのだろう。
 
 

簡単に書くと
ドコの
xxxDao   dao;　/* 実は普通のクラスではなくinterfaceクラス */
なソースに
dao.selectXXXX(dto);
すれば、
簡単にNullPointerExceptionが起きて使えないが、
どこかでコッソり
dao = new xxxDaoBean();
してしまえば使える様になるたったそれだけのこと。
@EJB　　　　ejb.jarのどこかのクラスのstatic Mainメソッド
とか
@Resource   ibatis.jarのどこかのクラスのstatic Mainメソッド
とか
アノテーションを書いておけば、誰かがやってくれる。
ハズ。
え？勝手にどうやって動くのか？

class   xxxx{

static {

/* スタティックの無名領域で初期化を無意識に恣意的に実行 */

initialize();

}

void  static initialize () {

/* 沢山の初期化処理 */

}

}

 で、いいじゃないですかね？
簡単でしょ？
※同じことはC++でも出来ます。
 
実は、環境に応じて、
dao = new batchDaoBean();
とか
dao = new onlineDaoBean();
とか
dao = new androidDaoBean();
とか
dao = new iosDaoBean();
とかに差し替えが効くところが良いのだが、
 
実際にはそんな使い方をすることは・・・
 
アリエナイ話。（爆
 
 
実にJavaは、何かのjarのMainが勝手に初期化するので、どんな動きになるか、判ったものではない。
当然のことだが、安易なインジェクションはソースレベルデバッグを困難にさせる。
strutsもそうだが、ソースが無いclassを跨いでワークフレームを作ることが多いからだ。
 
競合が起きて当たり前だし、上記の初期化処理に膨大な時間がかかるのも当然の話。
 
で、なんでそんなものを使うのか？
一つにはモジュールの差し替えがしやすい点があるものの。
 
そんなものはワークフレーム側の話で、それにぶら下がるクラスは普通に作ればいいはず。
でも、過去のインジェクションのデザインは、その上下関係が間違っていて、ワークフレームに作り込む方が
自動的にインタフェースじの変数にオブジェクトがインジェクションされることを前提にしている。
これは、ワークフレーム側がインジェクションの仕組みをカスタマイズする手法を勘違いして作ってしまったためだろう。
というかサンプルでサクっと作ったら、出回ってしまったと考えた方がいいだろう。
だって
/*  フレームワークのソース　*/

for(Class class :  all_class_list ) {

if(   class.isClass() ) {

for(Method method :  class.getMethodList() ) {

if( method.class.isInterface ) {

if(method.value == null) {

Object object = classMap(method.getClassName());

if( object != null ) {

method.value = object.getInstance();

}

}

}

}

}

}
な感じでnullにオブジェクトを挟んでくれたら楽そうに思える。
でも、その実態は・・・
 
interface  xxx = new XxxBean();
XXX.method()
を
@xxxInjection
interface  xxx;
XXX.method();
と書いて、全ソースのインジェクションを巡回する長～い初期化に時間を費やすことになり、
デバッグも面倒なので、
何も得るものはない。
ま、失敗なのだが、駄作であれ、悪貨であれ、出回ってしまったものが勝ちな世の中。
強いて云えば、
自分で作るつもりが無い部分をinterfaceとしてコードし、
その実装を外注に出せばいいだけだが
interfaceをclassに書き換えらる。（自分のコードを書き換えられるのが嫌）なら、
先のEJB手法が必要だ。
もっとも、
java   -jar 自分のソース.jar   -jar interface.jar
を
java   -jar 自分のソース.jar   -jar interfaceの処理を実装したクラス.jar
で実行すれば済む話でしかないのがEJBだ。
もちろん、自分のソース.jar にinterfaceの処理を実装したクラス.jarを使ってコンパイルしておかないとうまく動かない気がする。
ので、やっぱりEJBがいい。と思ってしまうのだろう。
だが、そんなEJBの動作テストはどうやるのか？
実装.jarができるまで放置しておくのか？
その辺の考慮がごっそりと抜け落ちているのが
やはりJavaerの幼さなのだろう。
 
でも、世の中どんどん変なものが残っていくのも仕方がないことだよね。（大笑