jflute と Seasar

org.dbflute

「そろそろ DBFluteSeasarから独立したら?」

と言われ続けて何年も。。。

しますよ、1.1からは。
org.dbflute で運用していきます。

...
...

10年近く前、Seasar-2.2

初めてのSeasarは、10年近くも前ですね。
Seasar-2.2で Apache Torque と合わせたプロジェクト。
そう、DBFluteの誕生のきかっけになったプロジェクト。
そのとき、S2Dao も知り 2Way-SQL に感動をしました。

Seasar系の勉強会にちょこちょこ

そのプロジェクトでの出会いがきっかけで、
Seasar系の人が集まる勉強会、
大規模なSeasarカンファレンスなどに参加して、
それまでの「ひとりでオープンソースに触れてた」感じから、
フツーに周りにオープンソースの話ができる感覚が新鮮でした。

DBFlute作っちゃった

DBFluteの前身となる、DaoGenと呼ばれるツール、
udagawaさんから、
「いいよ、オープンソースにしちゃいなよ」

よーしっ、沖縄用語にしないとーって言ってたら、
「いや、別にそういう規約があるわけじゃないよ」
って、yokotaさんに教えてもらって、
申し訳ない気持ちで、やっぱり自分の好きな用語で。
ググらびてぃが良い方がいいよって、
manholeさんからのアドバイスも決め手。
「DBFlute]に。

オープンソースやるのに、
Seasarプロダクト以外の選択肢は考えられなかった時代。
2006年9月26日、org.seasar.dbfluteの誕生。

Seasarカンファで登壇

とうとう、Seasarカンファで登壇!
レギュラーな感じで毎度毎度しゃべる。
そんなことやったことなかったので下手くそだったけど、
とにかくしゃべらなきゃって。

2014年の今でも、その頃にセッションを聴いてくれた方が、
「Seasarカンファで見たことなりますよー」
って言ってくれることがあります。うれしいですね。
「もっと堅い感じの人かと思ったら、少しチャラい...」
チャラくないですよー

スーパー独自路線

オールインワン要素の強い Seasar で、
DBFluteは、スーパー独自路線。
やればやるほど、ちょっとアウトローな感じに。

別に狙ってやってるわけじゃないですよぅ。
ただ、jfluteの性格なんですかね。
自分の求めるものをただひたすら追求してきたつもり。

DBFluteのその「あまりに尖った機能」から、
どうしても Seasar の一部機能と方向性に
相容れない主張になってしまうケースもあって、
はぐれメタルみたいなレアキャラフレームワークな感じ。
そして、なかなか倒されないみたいな(^^

Seasarの中では、端っこを歩いてた感じがあります。

S2Daoから独立

0.9.0からは、S2Daoを依存ライブラリから外し、
Seasar だけでなく Spring でも動作するように。

その頃は、Spring で動作させたいっていうことより、
S2Dao に引きずられて機能追加ができないケースが
多々あったので、そろそろという感じで。

でも、S2DaoのコードはApacheライセンスとして
利用していますから(正式にDBFluteサイトに明示)、
DBFluteの中で生き続けてます。
跡形もないくらい拡張されてしまっていますが、
s2daoという名前のパッケージは残しています。
尊敬するフレームワークですから。

スーパー独自路線と言っても、
「S2Daoの自動生成ツール」という要素があったからこそ、
DBFluteはある程度の方々に受け入れられたと確実に言えます。

そういえば、S2Daoのコミッタでもありますよ。
最後しっかりコードのコミットもしています(^^。

TeedaYmir にぞっこん!

TeedaYmir などのフレームワークを
使ったプロジェクトを次から次へとやっていきました。

Teeda は、そのGoodなポテンシャルとは別の苦労がありました。
かわいそうだなと思いつつも、
自分はDBFluteばかりで手を動かせない、
Webフレームワークのスキルもない、無力で終わりました。

Ymir は素晴らしいフレームワークでした。
これまた Seasar のメインメンバーには入らない、
DBFluteと似た境遇のレアキャラフレームワークでしたが、
jfluteの中では最高のフレームワークでした。

でも、世の中は、SAStrutsの時代へ。
その流れには逆らえず、
SAStrutsとたくさん付き合うように。

その成れの果ては...知る人ぞ知る、SAFluteですね笑

気付いたら古くなってた

気付いたら、Seasarは古い古い言われるようになっていました。
仕事に没頭して、DBFluteに没頭して、
ふはーって顔を上げたらいきなり聞こえてくる声。。。
「あっ、そ、そうなの!?...まあそりゃそっか」
みたいな(^^。

Seasarカンファもいつからか開催されなくなりました。
(って、開催するのは大変な労力ですから、
運営されていた方々に、感謝感謝です)

でもちょっと勘違いしてはいけないのは、
「メンテナンスされていない」わけではないこと。
致命的なバグなどはちょろちょろアップグレードされています。
2013年10月19日には Seasar-2.4.47 がリリースされています。 
seasar-user-MLで質問が来ても、わりと答えが帰ってきます。

ただ、方向性として「新しいことはやらない」ってのは事実。
これ以上、改善されることはないというのは事実。

枯れてると正と捉えるか、負と捉えるか。

尊敬の気持ち

もう、進化が止まったプロジェクト、というのはその通り。
ただ、ネガティブなイメージはありません。

10年もの間、日本のオープンソースに活気を与えてきたのは事実。
「日本人が作ったツール」という負のブランドが根強い日本で、
それをある程度覆したのは事実。

いま思うと、わりと革命だったんじゃないかなって思いますね。
なので、それに対する尊敬の気持ちは変わりません。

オープンソースプログラマーとして、大切にしたいこと

DBFluteも、Seasarがなければ、ここまで発展していませんから。

さて、実務的には...

さあ、つまらない実務的なお話!
といっても、もちろん jflute と Seasar が中心のお話です。

まだまだややこしい。
最近よく書いてる通り、ちゃんと立体的に考えないとね。

Seasarは古い、のデメリットって何だ?

o 最新のJavaでの恩恵を受けられない
o 他で導入される最新の機能が反映されない
o 細かい現場フィットがいつまでもされない
o Seasarに長けた開発者が少なくなっている
o 技術者にとって将来性のあるスキルではない
o リクルーティング的なイメージダウン

前提がズレてるかもしれない!?

最初の三つは、実装的な面と言えるでしょうか。

o 最新のJavaでの恩恵を受けられない
o 他で導入される最新の機能が反映されない
o 細かい現場フィットがいつまでもされない

これらのデメリットをもろに食らってる感は...
意外にそんなんでもないなぁってのが、正直な感想です。
というのは...

世の中の「Seasar使ってる」っていうイメージと、
ぼくの身の回りでの「Seasar使ってる」っていう感覚が、
だいぶ違うかもしれません。

通常は、Seasarと言えば、

Seasar + SAStruts + S2JDBC
(S2Unit, S2Dxo or BeanUtil)

ってのがほとんどかもしれませんが、
jfluteはその構成をやったことすらない...
まあ、こんな感じ:

Seasar + SAFlute(相当のもの) + DBFlute
(UTFlute, 詰め替えはしっかりベタにやる)

素のまんま使うことはないし...
 -> jfluteが「Seasarどう?」って聞かれたら...

めっちゃ拡張しちゃってるし...
 -> SAFlute | DBFlute

って、感じなので、

Seasar使ってる」というのは、
純粋に「DIコンテナとしてのSeasar

にわりと近い感覚です。

SAStrutsは、拡張ベースの土台のような感じ。
規約ベースという点は悪くないので、足りないとこだけ拡張して...
 -> URLマッピングは規約ベースベースがいいな

もうラップされたツール。

それよりは...

やっぱり、HotDeployは欲しいし...
 -> HotDeploy、いつどこでだれと?

なので、事業会社の現場としては、
「単なるDIコンテナとしてはわりといいことしてくれるじゃん」
ってかんじ。
Interceptorもあまり使わない方向に進んでますから、
「コンポーネントをnewしてinjectしてくれりゃいい」
みたいな。

...
...

どうなんでしょう?

「まだ、Sesaar使ってるの!?えぇーーー
(素のSAStrutsとかS2JDBCとか、まだ使ってんのぉぉ!?)」

って言われるとき、

「まあ、使ってるねぇ。。。うーん
(や、やっぱりDIの機能ってそんなに重要かな汗!?)」

って...
なんかすれ違いしてるような気がするんですよね。
「指し示しているスコープ」が。

そう言う意味では、
Seasarの本とか記事とかで紹介されている
「素の構成」では、ぼくも使いません。
しかも、最初から(昔々から)使おうとしてなかった。

...
...

とはいえ、純粋にDIの機能としても、
ちょっとずつ遅れは取っているのかもしれませんが、
そこはまだちょっとわかりません。
DIのところではそんなに気になるところは
あまりないなぁって感じではいます。
まあ、この後どんどん変わってくるのかなー!?

DIコンテナの影響力は?

ディレクション的な要素としては、こちらの三つ。

o Seasarに長けた開発者が少なくなっている
o 技術者にとって将来性のあるスキルではない
o リクルーティング的なイメージダウン

一つ目、まだ現時点ではそれは感じません。
色々なエンジニアと接していますが、
どちらかというと、まだまだいらっしゃるイメージ。
まあでもだんだん減ってはいくでしょうが。

そして、二つ目にも同じことが言えますが、
意識してるスコープが「DIコンテナとしてのSeasar」なので、
普段ディベロッパーはそこまで意識しないので、
あまりそこに負の面を感じることは少ないなという気はします。

やはり、最後の一つが大きいでしょうかね。
これだけイメージが変わってしまったわけなので。
DIコンテナがそこに与える影響、
どれだけあるのかは...よくわかりません。

現場のエンジニアはどう思ってる?

こういったことを現場のエンジニアにも話をしたりします。
もちろん、主に事業会社の現場ではありますが、
色々なプロジェクト、色々な場所で。

やはり、リクルーティングの面を心配してる人がいますが、
実装的な面では、そんなに気にしてない人が多い印象です。

「まあ、別にいまのプロジェクトでは関係ないし、
 というかそれどころじゃないよぅ」ってかんじ。
(別のプロジェクトでも、別の会社さんでも)

それよりも、データベースのほにゃららとか、
JavaScript周り、ビジネスロジック周りのほにゃららとか、
よっぽど気にしていかなきゃいけないところ他にたくさん!

少なくとも、既に使っていて、
DI自体は安定しているプロジェクトからすれば、
「それどころじゃないよぅ」というのはわかる気がします。
DIコンテナというパートの優先順位がそれほどでもないようで。

そう、先の通り、
「DIコンテナとして他のDIコンテナにどれだけ劣っているか?」
が、焦点になりますから、
「HotDeploy」がある分、全然いいじゃんみたいな。
細かいDIの機能よりも、やはりそこの方が遥かに大きいみたい。

昨今、実務上の論点も、土台フレームワークよりも、
現場フィットレイヤの方に重点が置かれ始めています。
 -> なにを社内フレームワークと呼ぶか?

ただ、リクルーティングの面は、
技術的なアプローチではどうにもできないですね。
果たして、他のDIコンテナだったら、
「事業会社に向いたエンジニア」が集まってくるのでしょうか...

バランス取ってるだけかな

って、こんなことを書いてると、
恐らく、Seasarエバンジェリストとか言われそうですね笑。
でもむかしの自分からすると、
こんなこと書いてるって夢にも思わなかったですねー(^^。

...
...

単に、バランスをとろうとしているだけかもですね。

Seasarプロジェクトで頑張ってた仲間と話をしたとき、
すっかり「Seasar」という言葉を発するのが怖いと聞きます。
(まあ、jfluteは何も考えずKYに言っちゃうけど...)

「古い人」というレッテルを貼られそう、
怒られる勢いで「えぇぇぇー!?」って言われそう(言われた)...
みたいなw。
まあ、「ハッハッハ」って笑い話ではあるんですけど、
一方で、なんだかちょっと気持ちの悪い話だなって。
まあ、この業界よくそういうことありますよね。

世の中の話題はいつも極端な方向に流れる。
でも、現場が求めているのは変わらない。
立体的なセオリーで導いた「役に立つツール」なのです。

...
...

逆に「Seasar最高!」って言ってる人がいれば、
「それは違うぞぅ!」と言うでしょうし。
いま jflute は SpringBoot や SpringMVC に
アプローチしています。それはとても自然なこと。

むかし、Seasarが全盛期で、
「新しく出た機能はどれもこれも素晴らしい」
みたいに騒がれていたとき...jflute は、
「いや、まあ素晴らしいものは確かに素晴らしいけど、
これとこれとこれはちょっと使わないかなーっ」て。

Seasarが大好きな方からは
「えっ、ちょっと何言ってんの?」な感じで思われたり。
いまはそれが逆になってるだけ。。。
「これとこれとこれはもうダメだなーっ、
でもまああれとあれはまだまだ使えるじゃんっ」て。

感覚的には「部品」です。

わかってる人はちゃんとそれはわかった上で議論しているんでしょうけど、
わりとみんな流されて極端な議論になっちゃう人もわりと多いので、
自然と「バランスを取らなきゃ」って思うのかもしれません。

今後、新しいツールを使っても、新しいプログラミング言語を使っても、
jfluteは、たぶん同じようなこと言ってるでしょうね(^^。


仕事人のアーキテクトとして、
「何が良いのか?何が悪いのか?」
をぼかしたくないので

これからはDBFluteブランドを

さて、話は戻りましょう。

「S2Daoの自動生成ツール」というブランドで、
ほそぼそでも利用者が増えていった、ということ。

「Seasarプロダクトの一つ」というブランドで、
それなりに安心して使ってもらえた、ということ。

これらは事実です。
感謝の言葉がいくらあっても足りません。

タイミング的には、
ブランドが負に転換する頃くらいに、
そのブランドを外しているというのが、
わりとしたたかな感じに思われそうですが...(^^、

オープンソースサバイバル、
という意味では当然のことと割り切り、
気にせず好きなようにやらせてもらいますと行動しつつ、
心の中では感謝の気持ちであふれています。

2Way-SQLは、Seasar という肩書きを外して、
Doma2 や Mirage, そして DBFlute などで、
これからも生き続けるし。
すごい功績だったなぁと切に思います。

...
...

そう、ここからは、
純粋な、DBFluteというブランドで、
しっかり歩いていかないとですね。
本当の戦いはこれから。。。

そんなことで、DBFlute-1.1 からは、
Github にて、org.dbflute でいきます!

さあ、明日(9月26日)は、
DBFluteの Birthday です。
盛大に祝ってあげようかと思います。

...
...

あっ、Seasar.NET は違うからね

そうそう、Seasar.NET (C#) は、
まだまだ終わってませんよー。
というか...始まってもいないみたいな(^^。

.NETの世界では、Seasarに対するネガティブムードは
あまりないというか、そもそも名前も浸透してないみたいな。
だから、始まってもいない。

でも、ずっと一定数のユーザーがいらっしゃいます。
最初から多くはなかったけど、あんまり減ってる気配もない。
メーリングリストは、ほんのり活発です。

新しい Seasar.NET プロジェクトの、
「Quill2 と DBFlute.NET」を、
始まらないかもしれないというリスクはあるけどね(><。
 -> Quill と DBFlute.NET の未来プロジェクト

ちょっとずつ頑張りますよぅ。