3/6(Sun)
/** チーズケーキ */
昨日、チーズケーキファクトリーというところのケーキを買ってみました。
僕はNYチーズケーキってのを食べてみたんですが、
かなぁりチーズが濃厚で、なかなか食べ応えがあり、おいしかったです(^^)
ちょっと他にはないかなぁという感じですね。

ちなみに、僕がおすすめするチーズケーキといえば、モロゾフってことになりますね。
昔はよく、丸いのを家族で分けて食べたものですが、
こないだヒサビサに大船のVIVREで見かけたので思い出しました。

たまには甘いものも良いですが、食べすぎには注意かもです(^^;

/** 環境差異のあるもののリリースの仕方 */
うちのプロジェクトは比較的規模が大きいためか、
テストをする環境が、いくつか用意されています。

(1) 単体テスト環境（各自のPC ＆ データベースサーバ、一部のインフラは用意されていない)
(2) 結合テスト環境 (本番機より性能が落ちるが、インフラが整備されているサーバ)
(3) 総合テスト環境 (後に本番となる環境)

(1)と(2)の違いは、インフラがあったりなかったりするので、
一部のモジュールをスタブとして用意し、
(1)から(2)へリリースする際に、スタブから本物へ切り替える必要があります。
このような場合、AbstractFactoryとか、FactoryMethodなどのデザインパターンを使えば、
スタブから本物への切替を、プロパティファイルに逃がせたりします。(最近流行りのIoCコンテナとかそうですね)

また、データベースは(1)環境にも存在するため、この接続パラメータも、
(2)環境に合わせて変更する必要があります。

(2)と(3)の違いは、データベースも含めたミドルウェアへの接続パラメータが異なる点で、
これは、(1)と(2)でデータベースの接続パラメータが異なることと一緒です。

つまりこの前提では、各環境の差異はプロパティファイルに集約できるのですが、
では、このプロパティファイルをどのようにリリースかが問題になります。
謝って、(1)環境のプロパティファイルを(2)環境にリリースしたり、
また、(2)環境のプロパティファイルを(3)環境にリリースしたり、
それぞれ逆の事象が起こってもうまく動作させることは出来ません。

どのようにこの問題を解決するかを考えたのが以下です。

・案1
Antなどの自動化ツールを用いて、プロパティファイルをリリースする際に書き換える。
最も合理的でかつ人為的ミスが少ないと思います。
しかし、(3)環境へのリリースが管理外の場合は無理でしょう。

・案2
あらかじめ(3)環境に合わせてプロパティファイルを作成しておき、
(1)、(2)環境ではリリース後書き換えて使用する。
(3)環境へのリリースミスはなくなりますが、
(2)環境から(3)環境へ謝って接続してしまう可能性があります。

・案3
環境専門の担当者が、各環境向けのプロパティファイルを作成して、それぞれ配置する。
確実ですが、専門の要員を配置するのがそもそも難しいでしょう。

ちなみにうちのプロジェクトでは、
案1 → 変更頻度の高いプロパティファイル
案2 → 変更頻度の低いプロパティファイル
案3 → 管理外のもの
と使い分けてます。

案2は案1に寄せられたら良いのですが、いかんせん人手の問題で出来てなかったりします。
そもそも、全て案3だったら理想なんでしょうけど。

この辺、まともに考えたことのある人の意見とか聞いてみたいですね。