カンファレンスでSlimの話を聞いた限り、
Slimは「もうひとつのSeasar2.4」なのかな、と思う。
その根拠は、、、と説明する前に、
ちょっとだけSeasar2.4をdisりたい。
率直に言って、
エンタープライズ分野でSeasarを使うなら、バージョンは「2.3」が良い。
S2Struts1.2.x + S2Dao + Seasar2.3が鉄板。間違いない。
Seasar2.4やTeedaは、複雑だし、Smart Deployの挙動が微妙だし、規約が多いし
Seasar2.3 + S2Strutsほどの安定性／安心感もない。
いくらHot DeployやDoltengで「実装の生産性」が上がったところで、
そんなのはプロジェクト全体で見れば、1/10も貢献しないはず。
だから僕は、生産性よりも、
「ミスしないこと = いかに問題が起こらないか」ということと
「ハマらないこと = 問題が起きた時にいかに素早く対応できるか」
の方が重要だと思っている。
ミスして、ハマれば、あるいは、それに気づかずにプロジェクトを進めていれば
あっという間に予算は消し飛んで、プロジェクトはデスマーチに突入する。
生産性を上げて稼いだコストなんて、焼け石に水。むしろ下手をすれば火に油。
なんて、ちょっと言い過ぎたかも知れないけど、
とにかく、僕はSeasar2.4やTeedaに、そういう危うさを感じている。
で、話は戻って、Slimの話。
Slimは「Hot Deploy」っていう点以外は、
とにかくシンプルにするという方向性を打ち出すらしい。
シンプルなものは、通常、ミスしにくいし、ハマりにくい。
学習コストだって肥大化しにくいはず。
このSeasar2.4とSlimを比べてみると、何となく一昨年の秋に言ってた
「Easy Enterprise」と「Super Agile」を思い出す。
要は「Easy Enterprise」なんてものに囚われて道を誤った、
あるいは誤った道から戻ろうとして戻りきれなかったのが「Seasar2.4」で
「Super Agile」だけを見据えて作り直したのが「Slim」だという風に見える。
つまり「Easy Enterprise」に囚われなかった、
「Hot Deploy」による生産性向上を目的とした
もうひとつのSeasar2.4が、Slimなんじゃないかなって思う。
今日のセッションでは、
思想が違うものを別ブランドで出す意義を、ひがさんは説いてくれたんだけど
僕には、そこまで「Seasar」と「Slim」の思想が違うようには見えなかった。
海外進出とか、タイミング的な問題、マーケティング的な問題などなど
僕みたいな一介のエンジニアには分からない複雑な問題があって
「Slim」っていう別プロジェクトになってるんだとは思うけど、
僕の捉え方は、やはり「もうひとつのSeasar2.4」。
けっこー、望まれていたもの、じゃないかな。
ただ、、、
シンプルにするなら、Spring Bean対応は不要だと思う。
これこそ、無駄な複雑さを産み出しそうで。
海外でデファクトな立場であるSpringからの
マイグレーションパスを準備することは、重要なのかも知れないけど、
そんな欲を出すことで、複雑になったら元も子もない。
別にSlim Flexは、いいけど、さｗ
