Seasar2系のノウハウをSpringコミュニティに提供

私がSlimというプロジェクトをはじめるということは、Seasarカンファレンスで発表しました。
http://itpro.nikkeibp.co.jp/article/NEWS/20080524/303949/
もともとSlimのコンテナ部分は、Seasar2からもってくるつもりでしたが、最近、NTTデータやCTCのフレームワークをやってる部隊がSpringベースのフレームワークにいろいろ悩んでいることを聞いて、Slimのコンテナは、Springベースにしたほうが、世の中のためになるんじゃないかと思い直しました。
NTTデータと真昼の対決
CTCと夜の決闘


もちろん、SpringベースでHOT deployを提供します。エイプリルフールネタを現実にやるということですね。
Super Agile Spring


HOT deploy可能なSpringの上に、SAStrutsS2JDBCを移植して、HOT deploy可能なフルスタックのフレームワークを提供します。
Springは、DIコンテナとしては優れているけど、実際にWebアプリケーションを開発しようとすると、WebフレームワークやO/Rマッパとの組み合わせがありすぎて、どれを選んだらいいかわからないということがあったかもしれません。
また、組み合わせたときのアーキテクチャだとか、その辺も決まったものがないので、個別に試行錯誤しているというのが実体でしょう。
いろいろ試行錯誤したけど思うように生産性が出ないというのが、NTTデータやCTCの悩みなんだと思います。

もしCTCやNTTデータが生産性で悩んでいるのであれば、それはフレームワークの問題ではなくてアーキテクト(アーキテクチャ設計)の問題です。アーキテクチャ設計の手間をフレームワーク任せにすることは悪い選択肢ではありません。ですが、よく考えないで採用してから「***だからだめなんだ」といったのであれば、お門違いです。

そりゃ、アーキテクチャ設計の問題だけど、正解が広まってないからみんな試行錯誤して、その結果うまくいってない人たちがいるわけでしょう。

SSH 等を採用しても,Spring は Struts/Hibernate などとの穏やかな連携を提供するだけで,より高水準な方向への拡張は (意図的に) 提供しないですよね.つまり,SSH を採用するということは,裸の Struts,裸の Hibernate を使うことと大差ないわけです (暴言?).そのため,SSH 等の上により高水準なアプリケーションフレームワークを「自前で」,繰り返す「自前で」,構築する必要があるわけですが,それは大手 SIer にとってさえも簡単なことではなく,ひがさんに声がかかったり,SAStrutsS2Dao を Spring でも使いたいという声になるんじゃないでしょうか.

Webアプリケーション開発の関して、Seasar2系のプロダクトは、生産性が高いと認められているんじゃないかと思います。そうじゃないと4年以上もSeasar2が生き残っている理由がわからない。
そのSeasar2系のノウハウをSpringコミュニティに提供することによって、Springな人たちも楽に開発できるようになったらいいなぁって思います。


Slimの正式な名前は、Slim3になりました。Slim3.orgも取得済みです。「ぐぐらびりてぃ」も悪くないよ。


追記:Slim3のドキュメントは、日本語も用意するつもりでいます。Slim3が想定するSpringの使い方は、Slim3でドキュメント(英日)を提供する予定です。Springは完全に日本語で情報が出回っているわけではないので、足りない分は補うということです。