Seasar 2 徹底入門 SAStruts/S2JDBC 対応

Seasar 2 徹底入門 SAStruts/S2JDBC 対応

当然、速攻で予約して買いました。まだ読了していないのですが、著者の竹添さんが興味深いエントリをポストされていたので便乗してエントリ。

Seasar2 について

一部のみを引用するとぼくの主観が入って作為的になってしまう恐れがあるので、必ず原文にも目を通して頂くとして、著者の竹添さんが Seasar2 について以下のように言及されています。

でも、そんな今だからこそ、僕が好きになれなかったのはSeasar2というプロダクトではなく、（言い方は悪いですが）ある意味ミーハーな盛り上がりを見せていた、当時のSeasar2のコミュニティだったのではないかと思うようになりました。

http://d.hatena.ne.jp/takezoe/20100425#p1

竹添さんの仰りたい趣旨とはややズレるとは思いますが、自戒の念を多分に込めて言うと、この「ミーハーな盛り上がり」は Seasar2 に限ったことではなく、この業界全般に言えることでもあると思います。
OSS に限らず、何らかの製品や概念など、対象は何でも良いのですが、それそのものの本質や、それによって引き出されるメリットやデメリットまで踏み込まずに、上っ面だけで持ち上げたりこき下ろしたりすることが多過ぎるように思います。

クラウドと NoSQL について

これを踏まえて、同じく竹添さんの別のエントリを引用します。上記同様、こちらについても原文まで目を通して頂きたいと思います。

というわけで、データ中心に設計する場合と比べると事前に決めておかなければならない部分が多く、さらに追加や手戻りのダメージが大きいとなると、そういうデメリットを差し置いてまでスケールアウトすることが必要なアプリケーションでしか分散KVSを使うメリットはないわけです。少なくとも、いわゆる業務アプリケーションの分野ではメリットよりもデメリットのほうがまだかなり上回っているような気がするんですよね…。

http://d.hatena.ne.jp/takezoe/20100424#p2

上記の「ミーハーな盛り上がり」は、現在では「クラウド」と「NoSQL」についても見られると思うのです。
バズワードに食いついて「これからはクラウドである」なんて言っている経営層は言うに及ばず、クチバシを尖らせて「これからは分散 KVS なのれすっ！」とか言っている技術屋も等しく問題です。
クラウドが重要なのではなく、システムの初期導入コストの削減やスケーラビリティの向上によるビジネスチャンスの拡大が重要なのであり、それが実現できれば、あるいはそれが必要なければ、何もクラウドでなくたっていいわけです。
分散 KVS も同じで、従来のような更新頻度が少なくて参照頻度だけがバカ高く、かつ多様な導出項目を求められるようなシステムであれば、RDBMS クラスタリングの方が適しているはずです。

まとめ

ぼくはこれからも技術を磨いていきたいと考えているので、これはと思った技術にはどんどん手を付けていきますし、それをこのブログにエントリしていきます。
ただし、それら全てを仕事に持ち込むかと言えば、決してそんなことはありません。その時々に応じて、プロの技術屋として広げた引き出しの中から最適な技術を提案して、リードして、確実に成果を残していきたいと考えています。