一言で云えば無茶。
/etc/sysconfig/network-scripts/ifcfg-eth0 のようにBOOTPROTO=”dhcp”　を書けば、勝手にIPアドレスが貰える訳では無い。
無線LAN接続で、ログインして暫くたった後にブラウザやメーラを起動するハズ！そう云う考えで作られていることを痛感した。
大事なことなので復習しよう。
まず、wpa_supplicantパッケージをインストして、
# wpa_passphrase {SSID}  {パスワード}  >> /etc/wpa_supplicant/wpa_supplicant.conf
でひな形を作った後に、
無線LANの環境に合わせて、

proto=WPA2
key_mgmt=WPA-PSK
proto=WPA WPA2
pairwise=CCMP TKIP
group=CCMP TKIP WEP104 WEP40

などを追加し、
# service   wpa_supplicant   start
# ifup wlan0
# chkconfig   wpa_supplicant   on
これで起動したときに無線LANが使えるような気がするが
実際には無線LANのSSIDの認証をした後に毎回
# ifup  wlan0
が必要らしい。
しかし、モニターすら繋いでいないのに素で、起動の度にキーボードを繋ぐのも面倒なので、
/etc/init.d/wpa_supplicant　に
ifup wlan0を追記するのが現実的。
 
 
何度かコールドスタートを行い、 安定したことを確認したら、
# ifdown eth0
で有線LANをOFF、ルータからIPアドレスの割当てをMACアドレス指定の手動設定に変更し、外部から８０ポートでアクセスがあれば飛ばすようにする。
※このブログを見るにはＩＰアドレスのＵＲＬで十分だが、ＦＦ１４のブログの方はマルチドメイン寄生型なので、無理。
/etc/hosts に
自身のマシン名．ドメイン名     192.168.***.***
名前でＩＰアドレスを引ける様にしておかないと、WordPressの自動バックアップのメールが届かないっぽい。
また、メール送信にはトリガーとなる真夜中のアクセスが必要らしい。
 
しかし、LANケーブル一本減らすには面倒すぎるなぁ～

EJBを使ったJavaのなんたらシステムが起動した後に、中のEJBが安定するまでの時間は運用してみないと誰にも判らない。
と云うのも、ヤベーと誰かが気が付いて、実装クラスのインスタンスをインタフェースの変数にインジェクションするからだ。
云ってしまえば、インタープリターのごとき仕業であるので、遅いの一言に尽きる。
EJBを使えばjUnitでmockが便利なんて詭弁でしかない。
大体、mockのソースの賞味期限は数か月にも満たないのが普通で、
そんくらいなら、Eclipseで、src/main/javaとsrc/test/javaのクラスパスの順番を変えるくらいで十分だし、その為だけにjUnitのテストソースからプロセス起動するようなことをしてもよいだろう。
※当時の言い分：　EJBが出来た頃はEclipseなぞ無く、エディタ＋Shell＋吐き出されるログが全てだったので、環境変数のクラスパスを手で変更するのは大変危険だった。
とあるよく使うDaoなりActionなりをEJBで作り、jUnitでテスト環境を作ったとしよう。
それをベースに１０～２０個のコピペのようなものは、非常に簡単にできる。
しかし、
本当の地獄はその後に始まる。
Daoに何か変更が入ると、上記のコピペに一斉に修正が必要になる。
１０個ならマシだが・・・１００個だったら、結構大変だ。
そして、
当然の帰結として誰も誰も使わなくなり、
更に数か月が過ぎると、全く使い物にならないjUnitソースの残骸が残るだけなのだ。
無論、プロジェクトの立ち上げ時には非常に役に立つ。
但し、その後は捨てるものだ。
最後に残るのはEJBで作ったDaoやAction
どうやってテストするんだろうね？
え、実際に画面を実行？
です。（キッパリ
だって、その方がちゃんとしたテストデータもテストケースもあって、役に立つんですからね。
ここに到達してしまうと、
jUnitなんてもう使う訳もない。
※当初の仕様から全く変わっていないものを除く。
別に、直接Daoオブジェクトを作っても何も支障が無いことに気が付くわけである。
Actionだって、httpセッション経由で起動をかけることだって、別に難しい訳でもない。
それでも、今なおEJBは生き残っている。
理由はいたって簡単、
大半の機能を使うこともないlog4jを何となく使ってしまうのと同じなのだ。
多分、Java系の定番jarファイルを使うのを止めたら・・・
別世界なんだろうな。（大笑
 
 
 

なぜだろう？
JavaとWebが付いたもので、まともな仕様というものは見たことが全く無い。
どこかの会社と云うことは無く、Webにいっぱいあるワークフレームの仕様のこと。
Javaに仕様と云うものは相応しくないのかもしれない。
何故ならサブクラス（または派生クラス）を作ると全く頓珍漢になってしまうことも珍しくないからだ。
なぜ、元クラス（またはアブストラクトなクラス）がこんな風になっているのか、動き、そして得られる結果（ソースの量が少ない、処理が速い、スケーラビリティがある）を衆知せずにサブクラス（または派生クラス）を作らせれば、行き当たりばったりの実装になり、あれれ？の繰り返しになってしまうのだ。
そうならないためには、インスタンスの生成や終了の図なんかは非常に重要なのだが、最近は見たことが無い。
よく聞く、MVCも、MVCの画面と画面をどう繋ぐのか？は別問題と云う厄介な問題があります。
例えばStrutsのMVCのViewであるJSPは、Modelが作りだすActionFormを差し込んでHTMLファイルを作りますが・・・
例えば画面の【検索】ボタンを押し、
いざ検索結果の画面のＡｃｔｉｏｎに沢山のパラメータをどうやって渡すのか？
相手のActionForm？
正解です。
でも誰が検索結果や実行結果の画面を表示するのでしょうか？
正論は、Validatorでパラメータチェックを行うことを前提に、ＨＴＭＬ上の<form action=”検索結果画面.do”>するのが一番です。
しかし、実際に存在するデータのコートがどうかデータベースを検索しないといけない場合なんかは無理があるので、actionでパラメータをチェックした後に
検索処理を行って、ActionFormにデータを積み込んで、
forword(“検索結果画面”);
と書けばいいんでしょうか？
ま、それでもいいんですけど（笑
出来上がったら、検索結果や実行結果の画面のURLが前のURLのままなんです。（大笑
ここでF5を押すとブラウザのURLの通りに再表示しようとするので期待外れな動きになってしまいます。
バックスペースを押すともっと最悪です。
だったら、redirectすればいい訳ですが、StrutsでのsendRedirectで検索結果をパラメータで渡そうとするとURLに書き込むしかない（そもそもHTTPのredirectはurlしか渡さない仕様）ので容量的に無理があることが多いので、セッションbeanに検索結果を詰め込んで、sendRedirect(“xxxxx.do”);とすればいいのです。
勿論、セッションbeanの分量は相当なものになることは覚悟しなくてはいけませんね。（笑
だったら、
ＨＴＭＬ上の<form action=”検索結果画面.do”>して
検索結果画面のActionの中でパラメータをチェックした後に
検索処理を行って、ActionFormにデータを積み込んで、

forword(“検索結果画面”);

と書けばよかったと思いきや、
今度は、パラメータのエラーをActionErrorに詰め込んでしまうと・・・

saveErrors(request, errors);

の様にrequestに吐き出してしまう方式なので、
redirectは使えませんから、

forward(“検索画面”);

にしてみると、
今度は、パラメータのエラーになったのにurlが検索結果画面.doのままになってしまいます。
 
面倒ですが、どんなパラメータでも渡せる便利なredirectなjspを１つ作っておくと便利です。
適当だけど、

<html:form action=”<bean:write property=”actionName” >” >

<logic:itelater id=”xxx” collection=”parameters”>

<input  type=”hidden” id=”<bean:write name=”xxx” property=”key” >”  value=”<bean:write name=”xxx” property=”value” >” />

</logic:itelater>

</html:form>

やっぱり、こっちかな？

<html:form action=”<bean:write property=”actionName” >” >

<カスタム・タグ property=”actionForm”/>　⇒ 中身を<input type=”hidden” id=”name” value=”value”>に展開してくれるようなもの。ListとかMapがあったらStrutsにあったidを振ってくれるとなおうれしい（笑

</html:form>

つまり、ブラウザとかHTTPの仕様とか知っていないと、
いや知っていても、ワークフレーム次第ではボロボロなものが出来上がります。
 
JSPを作る前にHTMLとJavaScriptでサンプルを作っていたりすると、
Actionは無いのですから、HTMLから<form action=”****.html”>とかやっているので、
こういう状況は事前に把握できません！（もう大穴ですね。
 
どうでしょう？
枯れたワークフレームといっても・・・
 
もう、罠ばっかじゃないか？って気分になりませんか？
 
という訳で
いくらりっぱな仕様書を作っても、ダメな理由になったかな？（笑
 
でも、Struts２が出てきたり、jQueryの非同期通信でパラメータチェックや検索結果をごっそり貰ってしまう手もあるし、やりようはいくらでもあります。
でも罠が無いと云えば・・・あります。
Structs2のお手軽redirectはhttps://だったら強制的にhttp://に変わります。中のソースを見るまではそんなの知らなかったぁ～。
jQueryの非同期通信は同じドメイン限定だったりPOST通信はブラウザやサーバーをえり好みします。
やはり制限はあるのです。（笑

node.jsは難しそうな雰囲気が漂ってきたので、自作してみよう。
※失敗したらフリダシに戻ればよいだけだ。
【必要なもの】
1.JavaScriptエンジン
ドコかのブラウザのJavaScriptエンジンを使いたいが、頻繁なバージョンアップとセキュリティホールの巣窟であることを考えると・・・。作った方がいいのかもしれない。
2.リポジトリィ
さっとインストしようと思ったら必須。但しファイルをダウンロードするだけでは何かと不都合なのでrpmみたいなパッケージ設定スクリプトが必要だろうが、そこはjavascriptを使えばいいのかな？多分リポジトリィもjavascriptベースでいいだろう。
3.IDE
ブラウザ上でレイアウトを作り、実際に実行するのはサーバー側でいい。ただ、サーバー側のリソースを全て使えるようにすると、当初はいくつかバージョンを用意してテストしなくてはいけないから、何かと面倒になるので、ワークスペース内のリソースに限定。その外にあるリソースはドメイン(xxxx.local とか)指定でサーバーの中も外も区別がつかないような指定にしておく。プロトコルはローカルルール(resource://xxxx.local/log.txtとか)でいいだろう。
4.デバッガ
コマンドラインの簡単なものがあればいい。
5.ヘルプ
IDE上でビューとしてみたりバルーンでポップアップな感じでも見たい。JavaDocっぽいものでいいだろうが、逆引き辞書は欲しいので、ヘルプDBファイルとエンジンが必要になるかな。
 
な感じだろうか。
まず、

1. JavaScriptエンジンを作る。
2. １.にコマンドライン・デバッガを組み込む。
3. 2.をベースにリポジトリィ・サーバーを作る。
4. 3.を足掛かりにIDEを作る。
5. ソースにドキュメントのコメントを付ける。
6. ヘルプDBエンジンでDBファイルを作り、IDEにフックを取り付ける。
7. 1～6が一通りできたら、リポジトリィにパッケージを作る。
8. 使ってみて、不都合な部分を見直す。

の方向で進めてみよう。
とりあえず、ブラウザ上で動くのはIDEのみで、protocol.jsやjQuery.jsのお世話になるのはココだけだ。
後は自前でガンガン組み込むのが正攻法。