ひがやすを技術ブログ

電通国際情報サービスのプログラマ

Seasar Conferenceでスピーカーをしませんか？

Seasar

「Seasar Conference 2008 Autumn」では、スピーカーを募集しています。
「開発者による開発者のためのカンファレンス」を目指し、もっとオープンなカンファレンスにします。

「Seasar」だけではなく、他のオープンソースコミュニティ、開発者コミュニティなどの「話したくてうずうずしている皆さん」、スピーカーとして参加してみませんか？

例えば、以下のような言語、フレームワーク、OSSに関係のある方々に参加していただきたく、考えています。

お問い合わせは「 sc2008autumn-entry@seasarfoundation.org 」にお願いいたします。

スピーカーの皆さんのご参加、お待ちしています。

NTTデータのTERASOLUNAだとか、Spring Batchの話だとか是非聞きたいですね。後、リストになぜかあがってないけど、JBossの話も聞きたいなぁ。 > nekop
もちろん、Java以外の言語の話も聞きたい。RSpecによるBDDだとかね。
理事会の重鎮たちからみたSIer見たいな話も面白そう。


イベントの詳細は下記のとおりです。

Seasar2のロードマップ

Seasar

Seasar2のロードマップは、カンファレンスでもしゃべったし、何度かblogでも書いているけど、最近、また、話題に上がることが増えたような気がするので、再度書いておきます。
過去のエントリはこちら。
Seasar2の今後のロードマップ
肥大化し続けるフレームワークは衰退する
Seasar2にもいろいろいたらないところはありますが、新たに大きな機能を追加すると、その機能を覚えて使いこなすまでにはそれなりに時間がかかります。過去に覚えたことが直ぐ陳腐化してしまうことに不安を覚える人もいることでしょう。
だから、Seasar2は、これ以上進化するのをやめました。バグや要望があれば小さな機能改善は行ないますが、大きな機能追加は行ないません。
S2JDBCのエンティティのソースの自動生成やデータベースのマイグレーション(Railsのマイグレーション相当)が予定している機能追加の最後です。どちらかというとユーティリティ的な機能追加ですね。使い勝手を上げるためのユーティリティ的な機能追加は、要望があれば、今後も行ないます。


Seasar2は、使うユーザがいる限りMLでの手厚いサポートや素早いバグフィックスを続けます。個別のblogにSeasar2についての問い合わせを書いても発見できれば、ちゃんとお答えします。はてなダイアリーはキーワード検索が強力なので、はてなだとほとんど見落としはないはず。


弊社の有償のバージョン固定サービスだと、あるバージョンがリリースされてから最大7年間、お客さまごとにバージョンを固定して個別バグフィックスを含めてサポートしているので、仕事上で保障が必要な場合も安心です。


フレームワークは、最初に使うときよりも、何度か使ってノウハウがたまったときが、生産性を発揮します。Seasar2も今後古いフレームワークになってしまうときが来ると思いますが、ノウハウがたまっていくことで、生産性は落ちることなく向上するはず。


Seasar2のロードマップが最近話題に上がるのは、Slim3の発表があったせいだと思いますが、このエントリでも書いたとおり、Seasar2は使うユーザがいる限りサポートし続けるので安心してお使いください。
また、私は、Seasar2のユーザにSlim3を使って欲しいとは思っていません。私の夢は、「一人でも多くの人が楽に開発できるようになって欲しい」というものなので、これまでSeasar2を使っていない人がSlim3を使うことが、より多くの人の開発を楽にすることにつながるからです。

Slim3の環境設定機能

slim3

環境設定はwarアーカイブ内で持ちたくない．JNDIで取得するべき．そのための利用しやすいObjectFactoryを用意してもらえるといいのかも

Configurerの目的がいまひとつピンときませんでした。環境切り分け用であれば、SpringはJNDIを簡単に使えるのでそちらを利用したいところです。特に、本番環境用設定は設定ファイル上には持ちたくないので、セキュリティ的にはJNDIが最も安心だと思っています。環境面での切り替え用途だけではなく、APサーバ提供機能に対する切り分けという意味でも便利ですし。

Slim3の資料はこちら。
http://jsug.googlegroups.com/web/slim3.ppt?gda=TdayYzwAAABCmnn5cQjQR2l7OdNDgO501qg1jqxANuq4CRYYyzE6PaOfm6yDD3t3iM6guxGxRbRhNKlgHwxd66RgHfBM_wS5
shinさんもda-yoshiさんも環境設定はJNDIで取得すべきと書いているけど良くわからないなぁ。二人とも私の説明を直接聞いていないので、私のいっていることが伝わっていないのかもしれないし、私が勘違いしているのかもしれない。
そのため、Slim3の環境設定周りを説明しておきます。Springでは、環境設定をプロパティに書いてBean設定ファイルで参照することがポピュラーな手法(なはず)です。
例えば、プロパティファイルに



db.userName=scott
とかいてあるとすると設定ファイルで次のように参照できます。

<value>${db.userNname}</value>

この方法だと、単体テストするときと総合テストするときと本番で設定を変えなければいけないときに、そのぞれの環境用にプロパティファイルを用意してプロパティファイルの中身を入れ替えるか、Bean設定ファイルで利用するプロパティファイルを変更する必要があります。
環境ごとにファイルを変更するのは、できる限り避けたいので、環境ごとにslim_env_環境名.propertiesを用意しておいて、WARの外からコンテキストパラメータを使って環境名を指定するようにします。
Tomcatならコンテキスト設定用のアプリケーション名.xmlで次のように設定します。

<Parameter name="slim.env" value="環境名"/>

他のアプリケーションサーバだと設定画面から設定できるようになっているはず。
slim_env.propertiesの内容をslim_env_環境名.propertiesで上書きできるので、本番用の設定をslim_env.propertiesに書いておいて、個別の環境用の設定をslim_env_環境名.propertiesに書くのが推奨される使い方です。アプリケーションサーバ上で動かさないときには、TestCase上で環境名を設定できるようにします。
アプリケーションサーバで動かさないこともあるわけだから、JNDIで取得するのはつらいと思うけどね。また、アプリケーションサーバ外で動くJNDIの実装を使うこともできるけど、どのJNDIに接続するのかをパラメータで設定(環境設定)する必要があり、堂々巡りの予感。


Slim3の場合は、本番の時には下記のようなプロパティ(slim_env.properties)



#slim.ds.user=

#slim.ds.password=

#slim.ds.driverClassName=

#slim.ds.url=

slim.ds.jndi=datasource/oracle
JUnitのテストの時には下記のようなプロパティ(slim_env_ut.properties)


slim.ds.user=scott

slim.ds.password=tiger

slim.ds.driverClassName=oracle.jdbc.driver.OracleDriver

slim.ds.url=jdbc:oracle:thin:@xxx:1521:xxx

# slim.ds.jndi=
にしておいて、TestCase#setUp()でEnv.setName("ut")とすることで、簡単に環境を切り替えることができます。
DataSourceConfigureは、slim.ds.jndiが設定されていれば、JNDIからDataSourceをlookup()し、そうでなければアプリケーションサーバを使わないデータソースの実装に切り替えます。アプリケーションサーバを使わないデータソースの実装はS2DBCPを移植する予定です。


同様にTransactionConfigureは、各アプリケーションサーバの実装クラスがあれば、そのJTAを使い、なければ、アプリケーションサーバを使わないJTAの実装に切り替えます。アプリケーションサーバを使わないJTAの実装はS2JTAを移植する予定です。


この方法だとBean設定ファイルはどのプロジェクトでもほとんど一緒になるはず。各プロジェクトごとの作業はslim_env.properitesのデータソースの設定を雛形をみながら書き換えるだけになります。