J2EEパターン

これまで自分が携わってきたウェブアプリケーションはあまり大規模なシステムが無かったこともありますが、自分の会社で優秀な人間が基盤を作りその基盤を元に開発していくということがほとんどでした。
小規模なものなら自分で基盤を作ってそのまま一人で作り上げることもありました。
ただそういったやり方だとそのシステムの保守の容易性やパフォーマンスといったところはかなりその基盤を作る人間のスキルに左右されてしまいます。

技術スキルのベースがあまりない会社では結構悲惨なソースが散らばってたりもするでしょう。
そういったことを改善するために確かに既に有名なGOFのデザインパターンはよい指針になります。
しかしウェブアプリケーションにおける指針になりえるかと言われるとそれは難しいでしょう。

そういった環境のなかよいウェブアプリケーションにおけるよい指針はないかと探しつづけているとようやくいい本に出合えました。(正直もっと早く読みたかったです)

J2EEパターン 第2版

純粋なデザインパターンとしても勉強になりますがJ2EEにおいて使うべきではないアンチパターンなどを例しながらよりよいウェブアプリケーションを構築するためのノウハウがふんだんに詰まってます。

自分もこういったときはどう記述すべきか悩んだときはまずこの本を見るようにしています。
J2EEでの開発に携わる方でよりよい方法を探している方はまずこの本から始めてみてください。

HttpSessionの使用方法について考える

HttpSessionはとても便利でついつい多用してしまいがちです。
しかし間違って膨大な検索結果等(これに限らず巨大なオブジェクト)をHttpSessionに入れてしまった日にはサーバのメモリを圧迫してしまいパフォーマンスの低下は免れません。
removeAttributeですぐ削除すればよいですが削除する前にブラウザを閉じられたりするとどうしようもないわけです。

パフォーマンスに関してはこちらのブログが詳しく説明してくれています。

結局使用しないのが一番なんでしょうが、正直なところ画面によってはHttpSessionが使用できないことで実装するのがとても大変になったり別のデメリットがでてくることもあります。

このHttpSessionに関するやり取りでも触れてるようにHttpSessionの代わりhiddenフィールドを使うことによるセキュリティのリスクもあります。

やはり設計方針をきちんと定めセキュリティ上問題のある箇所でのみ使用するとか画面デザインによって止むを得ないシチュエーションでのみ使用するなどと決めるのが一番なのかも。
他の対策として極力タイムアウトの時間を短く調整するといったところでしょうか。
もちろんログイン情報等は例外でHttpSessionで管理すべきでしょうけど。

明確な答えは出せませんが、今後も代替案を含めて調査していきたいと思います。

LS-GL#2

さて昨日の結果について書いていきます。
HS-DHGLのファームウェアの更新プログラムをLS-GLに使えれば一瞬で終わると思い、
まずそのまま更新プログラムをダウンロードして起動しました。
結果は更新プログラムがLS-GLを見つけられず終了です。(当たり前か！？)

で腹をくくり昨日調べたサイトから手順を調べて実行することにしました。

参照したサイトはこちら：LinkStation/玄箱をハックしよう

まず最初にLS-GLのハードディスクを取り出してLinuxにマウントしないとファームウェアのコピー自体できない事を知りました。
家にCentOS 5を入れたPCはあるのですが、SATAが付いたマザーボードがないので安くすませるにはSATA → USBに変換するケーブルがよさそうなので調べてるうちにいいのを見つけました。

センチュリー SATAハードディスク用クレードル裸族のお立台 CROSU2

しかしこいつの名前なんとかならないのでしょうか？
小心者の自分にはお店で「裸族のお立ち台」くださいと面と向かって言う勇気はありませんでしたので、商品だけ持ってって無言で購入しました。(ネットで買えばいいんでしょうが、すぐに欲しかったので・・・)

で次はLS-GLからハードディスクの取り出し作業です。
どうも自分は不器用でこの手の作業は苦手でして、ハードディスク取り出すまでに結構時間がかかりました。
ちなみにこれでLS-GLは保証対象外となったわけですが、そんな事はもうどうでもいいです。

ディスク外す手順は下記の通りでいけます。

1. LS-GLのフロントパネル下のネジを外すと、フロントパネルが外せるようになるので取り外します。
2. サブボードに繋がっている電源ケーブルを外します。
3. サブボードにとめてあるネジ２本を外します。
4. これでサブボードが外せるようになるので、ハードディスクごと引き出します。
5. サブボードとハードディスクをとめているネジを外せば完了です。

さてここから「裸族のお立ち台」＆CentOSの出番です。
取り出したハードディスクを「裸族のお立ち台」に取り付けてCentOSを起動して認識することを確認。
ちなみにディスクは/dev/sdaで認識しました。

ファームウェアの更新は結構簡単で以下の手順

1. HS-DHGLと同じ構成でパーティションを切る。
2. /dev/sda1にuImage.buffalo、initrd.buffalo、hddrootfs.buffalo.updated ファイルをコピーする。
　・これらのファイルはバッファローが提供しているHS-DHGLの最新ファームウェアをダウンロードしてそこから取り出す
3. LS-GLにハードディスクを再度取り付けて、電源ボタンを押せば後はHS-DHGLのファームウェアに自動的に更新されてLS-GLが起動する

を想定していたのですぐ終わると思ったのですが、世の中そんなにあまくなかった・・・。(手順としてはホントにこれだけなんですが)

手順1. のパーティションに関しては既存の構成がそのまま使えそうなので何もしませんでした。
大変なのは手順2.以降でinitrd.buffalo、hddrootfs.buffalo.updatedの取り出し方にまずかなり苦戦。
ダウンロードしたファームウェアにinitrd.imgとhddrootfs.imgがあり、これらはzipで圧縮されてるようなので解凍すれば
initrd.buffalo、hddrootfs.buffalo.updatedができるのですが、解凍しようとするとパスワード聞いてくる・・・。

というわけでいきなり終了・・・

と簡単にあきらめられないので適当なものを打ち込んでみました。
hddrootfs.imgは無理でしたが、initrd.buffaloは誰でも思いつきそうなhttp://d.hatena.ne.jp/images/admin/markup_url.gifのを打ち込むとパスワードが通ってしまいやったと思ったら結局エラー吐いて解凍できません。
なんで万能な解凍ツールであるUniversal ExtractorなるものをダウンロードしてWindows経由で解凍したら成功！！(ところがこれがこれからの苦労の元凶となろうとは・・・)
で時間はかかったけどパスワードはなんとか解決（すいませんが、パスワードについては何も書けません)とりあえず検索エンジンありがとう。

さてこれで全ての準備は整ったので後は/dev/sda1にuImage.buffalo、initrd.buffalo、hddrootfs.buffalo.updatedファイルをコピーしてLS-GLにディスクを戻し再起動。

LEDが点灯してゴリゴリいい始めさあこれで完了と思ったらピィピィピィピィとLS-GLが甲高い声で泣き始めた。
根拠のない自信はかなりあったのにいきなり失敗とは・・・。

何が原因か考えると/dev/sda1にファイルをコピーしただけで他のパーティションをフォーマットしてないことに気づき
まず/dev/sda2をマウントしようとしたら・・・できない。
なんで？と思いながらググッてるとどうも/dev/sda2はxfsでフォマーットされてて、CentOS 5のデフォルトではxfsはサポートしてないと。
これはもう面倒くさすぎてちょっとあきらめかけましたが、どちらにしろこのままだとLS-GLがただの内蔵ハードディスクまで落ちてしまうことになるので再度がんばりました。

こちらのシステム開発の備忘録 | CentOS 5 + XFSを参考にCentOSをxfsに対応させマウントに成功。

後は/dev/sda2と/dev/sda6のファイルを全てを削除(/dev/sba5はスワップなので何もせず)再チャレンジです。
ちなみに/dev/sda2と/dev/sda6は最初からxfsなので特にフォーマットはしていません。
で結果はというと・・・またピィピィピィピィ泣き始めた。
さすがにこうなるとそもそも最初から無理だったんじゃないかと思いました。
さらに追い打ちで自分が買ったのは新型のLS-GLであることに気づき、ハード自体が異なってるから無理なんじゃないかという疑問が頭をもたげ始めました。

とはいいつつもこんなところで諦めたくないので色々考えているうちにinitrd.imgを解凍したときのエラーを思い出しました。
なので早速ファイル自体に問題ないか確認してみました。
hddrootfs.buffalo.updatedファイルはtarでアーカイブされてるだけのようでtarコマンドでエラーもなく展開できました。
ところがinitrd.buffaloはちゃんと見れない・・・なぜ？

手順としてこんな感じでinitrd.buffaloの中身を確認しようとしました。

1. ddコマンドで先頭のブロックをスキップしてファイルに出力します。
　$ dd if=initrd.buffalo of=initrd.gz bs=64 skip=1

2. gunzipコマンドで出力したファイルを解凍します。
　$ gunzip initrd.gz

3. 解凍してできたファイルを適当なディレクトリにマウントします。
　$ mount -o loop initrd /mnt/tmp

initrd.buffaloに問題なければこの手順でマウントできるはずなのにできないってことはファイルが壊れてるってことだ！！とようやく原因に気づきました。
なので適当なパスワードではなくちゃんとしたパスワードを入力してinitrd.imgを解凍すると・・・何のエラーも発生せず普通にunzipコマンドで解凍できました！！
後はいうまでもなく手順通りにやって全てがうまくいきました。
確認してないですけど、/dev/sda2にファイルや/dev/sda6にファイルが残ってても問題なくできたと思います。
ファームウェア更新したらデータが全て飛んだなんて事になったら大問題ですから。

長々と書きましたがLS-GLでHS-DHGLのファームウェアを動かすことは可能です。
ですが一切ここに書いてあることを行うことは推奨しておりませんので、みなさんは素直にHS-DHGLを買ってください。
やるならあくまで自己責任で行い、メーカーの保証も請けられなくなりますのでご注意を。
まあ俺みたいな間違いをする人もそんなにいないでしょうが。

LS-GL

Playstation3の話で触れたHS-DH500GLを先週さっそく購入しました。
で喜び勇んで家に帰ってさっそく試してみました。
ところがどっこい箱を開け早速ネットワークにつないでブラウザから機能を確認してみたら・・・無い！！
欲しかったDLNAサーバ関連の設定が全然ない・・・。
おかしいと思って型番を確認してマニュアルを見てみたみたらやはりDLNA関連の情報が完全に抜け落ちてる。
でようやく冷静になってBuffaloのページを確認して全てを悟りました。

自分でもびっくりするような勘違いでHS-DH500GLではなく実際に購入したのはLS-500GLでした。
ようはただの製品違い・・・痛すぎる！！
ハードディスクのサイズが一緒でご丁寧に値段まで一緒とはっ！！
もう箱を開けちゃってるしさすがに返品はきつい。
まあ無理矢理交渉すればとも思ったけど、そんなパワーももうなくて。

で仕方なくもう一台、今度こそHS-DH500GLを買おうかなと思ったのですが、
どうしても気になる事があってググって見ました。
でその結果からやはり自分の勘は正しかったと確認。

LS-500GLとHS-DH500GLがあまりにも似てるので確認したら
どうもハード自体はほとんど一緒でファームウェアを入れ替えればHS-DH500GLの機能がそのまま使えるのではという情報を発見したんです。
でこれはもうさっそく試してみたいとどうやってるか調査を開始しました。
でものすごいサイトを発見したのでそこからの情報だけでほとんどやり方が分かりました。

参照したサイト：LinkStation/玄箱をハックしよう

本当にここまで情報を提供しているなんてすごすぎですよね。
管理者の方にお礼が言いたいです。
で実際にトライしてみたのですが、今日はもう疲れたので結果はまた後日報告したいと思います。

Eclipseの設定情報を簡単に移行する

Eclipseの設定情報をエクスポート、インポートすることで別のPC等にも移行することができます。

手順は至って簡単でEclipseのメニューから
エクスポートをクリックするとエクスポート・ウィザードが開きます。

項目の中から「一般　→　設定 」を選択して次へボタンをクリックします。
次の画面の中央より少し下にある「宛先設定ファイル」にエクスポートする設定ファイルの名前を指定します。
後は終了ボタンをクリックすると設定ファイルが作成されます。

作成された設定ファイルをインポートすることでエクスポートした設定情報を反映することができます。
手順はほとんどエクスポートと同じです。

Eclipseのメニューからインポートをクリックするとインポート・ウィザードが開きます。
項目の中から「一般　→　設定 」を選択して次へボタンをクリックします。
次の画面の上側にある「ソース設定ファイル」でエクスポートした設定ファイルを指定します。
最後に終了ボタンをクリックすれば設定がEclipseに反映されます。

HttpSessionはスレッドセーフか？＃２

以前の日記でも書きましたが、この問題に関する自分のなりの回答を見つけましたので公開します。

SUNのForumからHttpSessionに関する質問見つけたのですが、
この中でこのような回答があります。

Servlets, by default, are multithreaded and can respond simultaneously to multiple users' requests. However, you have to ensure that the methods within your implementation of Servlet or HttpServlet are thread-safe. This means that they do not refer to any instance variables within the Servlet that might change.

As far as sessions, each time you call getSession() or getSession(true) on HttpServletRequest, a UID will be generated by the Servlet container. This will be sent back to the client, either as a re-written URL, a URL parameter or a cookie. On subsequent requests, the client/browser should re-send this token back to the Servlet. In these requests, getSession() or getSession(false) will return the user's original session, located via the UID. You do not have to implement any of the above yourself. It works out of the box. Unless two users get the same random session UID (rare, and should not happen in a proper container) or unless another user attempts to manually hijack another user's session (possible), session data will not get corrupted.

意味としてはSessionのUIDはgetSession()を呼び出すタイミングでサーブレットコンテナが生成しており、このUIDはユーザー毎に生成されているため複数ユーザーが同時にHttpSessionに書き込み等を行ってもUIDが同じリクエストでない限り
データが壊れる等の問題が発生することはないといった感じの事を述べています。

確かに言われてみるとその通りですよね。
ただ注意しなければならないのはやはりここで述べているように同じユーザーが同じUIDを複数もってしまった場合はその限りではないというところでしょう。
例えば一つブラウザを開いた後、そのブラウザから新しいブラウザを開くと同じUIDを使ってしまうことなどはありえるかと思います。
これはHttpSessionがスレッドセーフではないということを意味していると言えます。
ただこのレベルの話になると後はシステムの設計次第になるのでご自由に制御してくださいといったところでしょうか。

広告

Amazon.co.jpアソシエイト･プログラムとGoogle AdSenseへの申し込みをしてみました。
ブログ始めて１年過ぎてようやくやってみようかなと気になりまして。

申し込み自体はとても簡単でAmazon.co.jpアソシエイト･プログラムは申し込んで２０分くらいで承認されたというメールが届きました。
Google AdSenseは審査が少し厳しいということが書いてあるサイト等もあったのですが
１日くらいで承認されたという通知がきました。
で早速使ってみたのですがちょっと邪魔臭いかな？

今日はもう面倒なので細かいことはまた考えよう。