spring？

最近雑誌やら何やらでAOPやらDIやらというキーワードをよく見聞きするのだが、なんとなく説明を読んだりしてみて、なんとなくわかったようなわかんないような感じになりながらもおもしろそうだなあとは感じる。
個人的には「springのDIを導入してから残業が減った」と開発者が口々に言っていたという記事が気になる・・。
１つ前の日記でもうちはEJBを使ってて、どうもコーディング量が増えたりといった悩みがあるのだが、もしかしてそういう時こそAOPなのだろうか？などと勝手に思ってみたりしている。


さしあたりJAVAWORLDの１月号などを読みながらspringの実装例などを見てみて「ほー」とか思ったりしている。ただ、それがうちのシステムに導入できるのか？などという具体的なイメージはあまりついていない。

• springを入れる場合、現在つかってるEJBを中心とした構成は捨てないといけないのか？
• はてなの他の方の日記でもよくみかけるseasarなど、他にもいくつかフレームワークがあるがどれがいいのだろうか？
• 単にspringというものを試してみたいという個人的な願望を満たすだけに終わってしまわないか？

今までは数人程度のチームで開発をしていたが、最近チームが増え開発量も増えあまり個人的な興味だけで物事を勝手に進めにくい面もあるためう〜んという感じである。
どちらにせよまだ興味レベルなので実行に移すかどうかはまた別のお話。


参考にさせてもらっているサイト
http://muimi.com/j/aop/spring/
http://www.wikiroom.com/koichik/?Spring%20Framework%20%C6%FE%CC%E7%B5%AD

アーキテクチャについて考えてみる

なかなか日記を継続的に付けてくのも難しいものだなあ。
まあ元々自分自身のメモ用のつもりだし付けたい時に付けてく感じでいくつもり。


最近は実施している開発の製造がようやく終わって試験などをやってる段階。
今回の開発では開発環境を変えたり、digesterやvelocityを使ってみたりと、地味だけどいろいろと効率化につながるようなことに取り組めた気がする。
その一方で全体のアーキテクチャというかそういうものは特にあまり変わってはいない感じである。
あまり変わらないということは、コードの統一性がとれるし慣れてきてやり易いというメリットはあるけど、やはりもっといろいろと取り組んでみたくなるものである。
で何が変えれるかと考えてるところなのだが・・・とりあえず現状の状態を書いてみる。

• 画面　JSPにて実装。今回の開発からJSTLを本格的に使用。strutsタグも便利なものは継続して使用。どうしてもコード量がかさんでしまうのと、画面デザインがもっといい感じにしてみたいというのが懸案。

• 入力チェック　struts1.1のvalidatorを使用。特に不満もなく満足。
• 画面遷移　strutsのactionを使用。特に問題はないのだが同じようなコードを各画面毎に書いてるのがいつももったいなく感じている。呼び出すEJBがそれぞれ違うためしかたないのだが・・。
• EJB　ステートレスセッションBeanにて実装。トランザクション管理をしてくれるのは便利だと思う。ただステートレスセッションBeanのため上位のactionからは１つのメソッドとしてしか呼べないといけないのが扱いにくいところ。EJB内にて様々な業務ロジックを呼び出している。

• 業務ロジック　業務ロジックはステートレスセッションBean内にて実装。ここはコードがかさんでしまうのは仕方ないのかな・・・。
• DBアクセス　DButilsにて実施。世の中にはいろんなORマッピングフレームワークがあるようだが、SQLが複雑なJOINや条件を付加することが多いのと、DButilsが十分便利に感じることから現状で満足。

• メール関連　JavaMailAPIにて実装。MessageDrivenBeanを使用。本文の生成はvelocityを利用。velocityの導入により本文作成もだいぶ楽に。これも現状でも満足。

とりあえず思いついたのはこのような形。
やはりEJBの使用によってうけてる制約がいくつかあるなあと感じる。
actionとかほとんど処理らしきものは何もやってないのだが呼び出すEJBが画面毎に違うのでそれぞれつくらないといけないし、EJBの呼び出し自体のコーディングがかさむ。
あとは業務ロジックの呼び出しとかももっと改善できないかなあ。

velocityを使ってみる

とりあえずjarから無事vmファイルが読めるようになったがどうも気持ちよくない点がある。
velocit.propertiesをjar対応にさせた時にvmファイルが入っているjarファイル名を直接そこに書かないといけないという点があった。
あまり業務固有のjarファイル名を書き込むのはヤダなあという感じである。
このためロジック内にて自分自身が入ってるjarファイル名を動的に取得してみることに。
パスを取る方法はあるものの、入ってるjarファイル名とそのパスを取るというのはほとんどどこにも記述がなかった。
いろいろとためしつつやってたが最終的には取得することができた。
getClass().getProtectionDomain().getCodeSource().getLocation().toString()と実行することで取得できた。
その文字列に頭に"jar:"を付加し、でpropertiesファイルには直接jar名はかかず、resourceBundleにて読み込んだあとに動的に設定してみた。
結果うまくできることができた。
（読み込むクラスとvmファイルが同一jar内であることという制約は必要だが・・）


velocityを使ってみてかなりmail作成ロジックは改善することができた。
さらには画面にも使用することができるらしく、jspが嫌いな人々の中では結構利用されてるとか。
個人的にはjspはjspで便利だし、たしかにvelocityも手軽だし、だけど今までjsp関連でいろいろ知識をつけてきたわけだし最近JSTLも覚えてきたところなので今更jsp廃止ってことはありえない感じである。
画面はjsp、mailはvelocityって感じでどっちもうまく使って行きたいところである。

velocityを使ってみる

うちのシステムでは、web操作から連動してメールを送信するのだが、そのメールの本文作成ロジックは今まではロジックにて実施していた。
つまりString（StringBuffer）操作にてロジック内でベタ書きでメール本文を作成していたわけだが、当然ながら効率が悪い。
幸い本文はたいして長いわけではないためString操作でもなんとかできたが、本文の文面の修正が発生するたびにロジックを書き直したりと何かと不自由が多かった。


そのためうちでもvelocityを導入してメール本文作成を行ってみることにした。
取り組んでみたところ、特に困難もなくあっというまに導入することができた。
相変わらずjakartaのソフトはよくできてるなあなどと感じた。


で最終的に完成したロジック及びvmファイルなどをjarに固めて配置したわけだが（ejb内で呼んでいるためejb.jarに固める必要があった）、ここで問題が発生した。
デプロイしていざ実行してみるとvmファイルが見つからないということでエラーになってしまう。
うーんどうしたものかと思いつつネットをみているうちに、vmファイルをjar内から取り出す場合はvelocityの設定を一部変更しないといけないことがわかった。
velocity.propertiesというファイルにいろいろな設定があるらしく、デフォルトは直置きされてるvmファイルしか読めない設定になってるらしい。
とりあえずpropertiesを書き換えてjar対応にさせた。
で書き換えたpropertiesだが、もともとこのファイルはvelocity.jar内に入っておりそこに戻さないといけないのかなあと思いつつもそれもなんだが運用がめんどいなあと思い、別の場所に配置して読み込んでvelocityのinit処理に渡してみた。
どうやらうまくいったらしくjar内からvmファイルを読んでくれた。


続きはまた。

JNIを使ってみた

以前（といっても去年の話）、まったく別のプロジェクトに短期で参加したことがあった。今の仕事とほぼ同じようなwebシステムだったが、商用システムということで社内システムとはまた違う心持ちだったりした。
で自分が参加したのはAP開発メンバーとしてだったが、たまたま暗号化ロジックについて担当することになった。


暗号化など当然やったこともなかったので調べつつという感じだった。
今でもまだ全然理解はしてないのだがとりあえずネットなどに書いてある通りにやったら意外と手軽に暗号化、複合化ができて「ほー、手軽だなあ」と感じた。
暗号化方式にもいろいろあるということをその時初めて知ったのだが、その詳細まで知らなくてもAPIがいろいろ提供されててすぐできるようだ。
（その時の方式が何ていう方式だったかももう忘れちゃったなあ・・思い出したら書いておこう→思い出したAESってやつだ）


そんな感じでいくつかの暗号化ロジックを作成したのだが、その中で１つ色が違うのがあって、暗号化モジュールがもともと提供されていてそのモジュールを呼べばいいというのがあった。楽勝と重いきやそのモジュールがC言語で書かれてるものということがわかった・・。JAVAのモジュールがあれば解決なのだがどうやらCしかないらしい。
JAVAからCを呼んだりなんてできるの？そもそもCなんてさっぱりやったことないぞ？という状況だった。


途方にくれつつまたネットなどで調べてるとJNI（JavaNativeInterfaceだっけ？）と呼ばれる仕組みがあるということがわかった。JAVAから多言語を呼べるらしい。「JAVAってすごいな」と思いつつさっそく試してみることに。
JAVAとCの架け橋部分の引数のやり取りを行う部分を作るわけだが、なにぶんCの経験が無いためコンパイルの仕方が全然わからなかった。
リンク？と呼ばれる作業が必要なようで、それがうまくいってないとコンパイルはうまくいっても実行時にエラーになるなどJAVAしかやったことないこちらとしてはまったくもって意味不明でかなりイライラさせられた。
最終的にgcc〜とかというコマンドで色々オプションを付けてなんとかうまくいった。
正直もう二度といじりたくないなという感じである。


かなり偏った偏見ではあるが改めてJAVAって便利だなあ・・・と思った。
そして今後Cは可能な限り避けていこうと思ってみたりもした。
（とはいってもやはりCは色々と理解しといたほうがいいんだろうなあ・・）

CVSを導入

先日eclipse＋jbossでローカルでの開発方法を整えた延長で、CVSも入れてみた。
今まではずっとその辺の管理はファイルサーバー上に手動でソースを上げたりしていた。


今まで手動でやってて、意外と反映漏れやら誤更新などはなかったが、何よりもソースの反映が非常にめんどくさかった。夜帰る前にソースを原本に反映させるのに数十分かけてた気がする。


CVSはあいてるサーバーをCVSサーバーにしてCVSをインストールして、あとはローカルからeclipseのCVSパースペクティブからつなげて最新のプロジェクトを登録すれば完了だった。あとは開発者それぞれで朝プロジェクトを「更新」し、夜「コミット」すればいいだけだ。ほんとにその２作業（２コマンド）だけですべて完了。
競合発生時はコミットでエラーがでるので必然的に不正更新は発生しない。競合時はサーバー側、ローカル側どっちを正とするか判断するか、またはキャンセルして競合分の吸収反映をすることもできる。ただしeclipseの場合、設定→CVS→監視のあたりのチェックをいれることで、競合が発生しそうになるといじる前に注意メッセージが出るため競合そのものがまず滅多に発生しない。


今までCVSってなんだか難しそうなイメージがあったものの、導入も意外と簡単で、使用は超手軽で便利だった。


あと、プロジェクトを更新すれば常にお互いの最新状況が反映されるのがうれしい。今までだと何か全般的に影響するような修正がある場合は、皆に伝えてやってもらったり、自分でやって全員に反映してもらったりとか、非常にめんどくさかった。まさにプロジェクトを共有してるという感じで目に見えて良かったといえる。
メンバーからもCVS導入は大好評だった。


CVSについてはこの資料が参考になった
http://works.nri.co.jp/solution/open_pdf/CVSonEclipse.pdf

性能測定

性能計測にうちではjakartaのJMeterを使用している。
ここでもjakartaのお世話になっている。


以前この担当に来たばかりのころは別の有料のソフトを使用していた。しかし最近になってJMeterの存在を知り使用してみた。使い方もなんとなくすぐ理解できかなり楽勝で使えた。
測定値もグラフなどで見ることもでき、計測の目的を忘れてついついいろいろ負荷をかけてどこまで耐えられるかなどをやったりしてしまった。
あと、100%ピュアJavaでjarファイルから起動するため、インストール作業をする必要がないのも個人的には好きかも。（eclipseもインストールが必要ないのがいい）


１つ使う上で壁にぶつかってしまったのが認証についてだった。
うちではFORM認証を行っているのだが、当初その越え方がよくわからず認証をはずしていちいち測定をしていた。BASIC認証のやり方はネットには書いてあったりしたのだがFORM認証についての情報が全然なかったため、たぶんできないんだろうなあと勝手に思ってたりもしたが、いろいろいじっているうちにそれも簡単にできてしまった。
クッキーマネージャーというところで適当に何か追加して、あとは負荷シナリオに初回に１回だけ実行みたいな欄でユーザー名とパスワードをpostするようにすることでできた。
改めて便利だなと思った。


しかしいつも思うのだがこういうソフトって誰でもDoS攻撃とか楽勝でできたりしちゃってまずくないの？とか思ったりする。


JMeterについてはこの辺を参考
http://muimi.com/j/jakarta/jmeter/
http://www.techscore.com/tech/Java/JMeter/1.html