変奏現実

パソコンやMMORPGのことなどを思いつくまま・・・記載されている会社名・製品名・システム名などは、各社の商標、または登録商標です。

この画面は、簡易表示です

2013年11月27日

nucなCentOSのブログ鯖を無線LANで繋ぐ方法

一言で云えば無茶。
/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アドレス指定の手動設定に変更し、外部から80ポートでアクセスがあれば飛ばすようにする。
※このブログを見るにはIPアドレスのURLで十分だが、FF14のブログの方はマルチドメイン寄生型なので、無理。
/etc/hosts に
自身のマシン名.ドメイン名     192.168.***.***
名前でIPアドレスを引ける様にしておかないと、WordPressの自動バックアップのメールが届かないっぽい。
また、メール送信にはトリガーとなる真夜中のアクセスが必要らしい。
 
しかし、LANケーブル一本減らすには面倒すぎるなぁ~



結局EJBは無駄飯食いでしかなかった

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



Java と Web の デスマッチ

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

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

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

saveErrors(request, errors);

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

forward(“検索画面”);

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

<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”>とかやっているので、
こういう状況は事前に把握できません!(もう大穴ですね。
 
どうでしょう?
枯れたワークフレームといっても・・・
 
もう、罠ばっかじゃないか?って気分になりませんか?
 
という訳で
いくらりっぱな仕様書を作っても、ダメな理由になったかな?(笑
 
でも、Struts2が出てきたり、jQueryの非同期通信でパラメータチェックや検索結果をごっそり貰ってしまう手もあるし、やりようはいくらでもあります。
でも罠が無いと云えば・・・あります。
Structs2のお手軽redirectはhttps://だったら強制的にhttp://に変わります。中のソースを見るまではそんなの知らなかったぁ~。
jQueryの非同期通信は同じドメイン限定だったりPOST通信はブラウザやサーバーをえり好みします。
やはり制限はあるのです。(笑




top