mhattaによる
2006年07月23日 11時30分の掲載
大変結構なことなんじゃないでしょうか部門より。
大変結構なことなんじゃないでしょうか部門より。
d'Arc曰く、"国産のオープンソースのJava開発フレームワークであるSeasar2が、三菱東京UFJ銀行のシステムに採用されたことが先日発表された。日経ITProの記事によると、Seasar2を採用することによりPOJO（Plain Old Java Object）で開発でき、複雑なAPIを覚える必要がないため、5日間程度の集中講義を行っただけで，初めてJavaを使う技術者でも問題なく開発を行っているという。また、MYCOMジャーナルの記事によると、「三菱東京UFJ銀行の大規模リスク管理システムにおけるSeasar2の採用は、オープンソースのもつイノベーションをビジネスに生かす先進事例であるといえる」と述べられている。"
関連ストーリー
この議論は賞味期限が過ぎたので、保存されている。
新たにコメントを書くことはできない。
Seasar2って (スコア:5, 参考になる)
また、日本のプロジェクトなのに日本語ドキュメントが少ないとか、サイトをどう歩けばいいのかわからないとか（これは最近だいぶ改善されました）、まったくコメントのないソースファイルを追うのは面倒だとかまぁ問題は山積みです。
せっかく日本のプロダクトなのにまったく同じ技術のSpringのほうが採用されることが多いです。実績とかの違いも多いですがドキュメントの差が大きいですね。
結局ひが氏のサポートがないと使えないようにわざとしてるように取れます。何のためのオープンソースなのかなぁと。
せめてメソッドの頭に１行コメントくらいつけてよ。
Re:Seasar2って (スコア:2, 参考になる)
出てきましたよ。
tpircs’s diary 「2006-07-05 すい。」 [hatena.ne.jp]
コメント欄のところですね。
た、確かにすごい…。
親コメント
Re:Seasar2って (スコア:3, 参考になる)
[java.fw.seasar]Spring vs Seasar [tdiary.net]
内部の人間ってｗｗｗ？ 09:04 [hatena.ne.jp]
Seasar 中心メンバーのひがさん、はぶさんがこのノリってどうなの?? と正直思いますね。 当事者では無いので実害は無いのですが、何となく Seasar プロジェクト全体に対するマイナスイメージを持ってしまいます。
Seasar プロジェクトの人は何か変なコンプレックスがあるのでしょうか?? 素晴らしい活動をされていることは周知の事実ですし、もう少し泰然自若として欲しいですね。
親コメント
Re:Seasar2って (スコア:2)
性格を占う上でほとんど参考にならないでしょう。
先ほど私は「『それは冒涜だ』式の抗議活動」、と書いたけれど、
フェアかどうか検証できないので撤回させてください。
なにしろ他人を憤激させるようなことをブログに書いておいて、
抗議のコメントがたくさん付いたから自分の文章だけ削除しました、
というのでは抗議内容が妥当か過剰か検証できません。
当該ブロガーの意図とは関係なく、一種の罠みたいな状況だったと
推定せざるを得ません。
親コメント
Re:Seasar2って (スコア:2, すばらしい洞察)
わざと書いているのかは分りませんが、
ウェブサイト [seasar.org]の構成があまり良くないことと、
中心メンバーが「それは冒涜だ」式の抗議活動に手を染めていることは、
同根の問題だと思います。外部からどう見えるかを
コントロールする人材が不足しているのではないでしょうか。
「報道官」のなり手がいなかったら衰退するでしょうね。
親コメント
Re:Seasar2って (スコア:2, 興味深い)
親コメント
背景に・・・ (スコア:4, 興味深い)
ある意味、自社製品？のいい叩き台かな・・・いい導入事例になりそうですが。
-- gonta --
"May Macintosh be with you"
Re:背景に・・・ (スコア:4, 参考になる)
親コメント
Re:背景に・・・ (スコア:2, 興味深い)
客観的にとてもよいSeasarの宣伝になるはずなのに。
正直何度か仕事で使うことも考えたんですが、圧倒的にドキュメントが少なくて断念したことも。少々性能がアレでもspringのほうが導入は楽かなぁと。バージョン間の互換性もspringのほうが積極的に維持しているようですし。
# ドキュメントを書くモチベーションはお金だけ、ってことかな。
親コメント
Re:背景に・・・ (スコア:2, 興味深い)
それはどのへんがですか？
DIそのものが？(だったらSpringも駄目ですよね)
「設定より規約」なあたりが？(便利だと思うがなあ)
設定ファイルが少ないあたりが？(多いことにメリットなんて無い気がするが)
>「木に竹を接ぐ」というか「新しい酒を古い革袋に」
新しいのはどっちですか？Javaが？Java以外の要素が？
確かにJavaで「設定より規約」をやるのは、RubyOnRailsに比べれば不恰好に見えるのも確かです。
ただ、そこまでして(させて)Javaにしがみついてるのは、どっちかというと顧客のほうなんじゃないかと？
＃まあ、スターロジック界隈が言う「与件」という言葉には、用心したほうがいいけどさ。
親コメント
初めてJavaを使う技術者 (スコア:3, すばらしい洞察)
プログラマー１年生の
熟練の C++ 使いの
○×△の
技術者
さて、トレーニングが５日間で済むのは誰？
Re:初めてJavaを使う技術者 (スコア:2, おもしろおかしい)
親コメント
Re:初めてJavaを使う技術者 (スコア:3, おもしろおかしい)
親コメント
Re:初めてJavaを使う技術者 (スコア:2, おもしろおかしい)
親コメント
Re:初めてJavaを使う技術者 (スコア:2, 興味深い)
だろうな普通。
C++やVBなんてのを下手に長い時間やってるとあの言語の癖が体に染み着いてやがる。
そんなもんだったらJavaをやるのも初めての方が恐ろしく奇麗なソースを書いてくれる。
なまじ銀行系ってC++/VB出身者が多いから新しい技術への関心少ないし。
とりあえずVB技術者は危ない。ホント。
デスマが発生する予兆を見ているよ…
# 同じ金融系で似たような技術採用してる中の人なのでAC
親コメント
S2Daoについて (スコア:3, 興味深い)
とありますが、実際に採用された現場の人たちの感想を聞いてみたいです。
S2Daoでは、親子関係(1:N)にあるテーブルを１回のSQLでJOINすると、クラスにN:1でマッピングされるため、子(N)のクラスのListが返却されてくる仕様なのですが、これをチームメンバーに理解して使いこなしてもらうのに、とても時間がかかりました。
しかも、この場合で親を複数件取得したい場合はN:1だとマッピングが複雑すぎて、使いこなしがとても難しかったです。
その上、1:N:Nのような３階層以上の構造を持つテーブルを１回のクエリでマッピングすることはできないため、何度もクエリを発行しなおしてマッピングせざるを得ませんでした。
iBATISだと、1:Nでマッピングできて親のクラスを戻り値として受取ることができるので、親を複数件取得するのも簡単です。また、1:N:Nのような構造でも１回のSQLでマッピングできます。
マッピングファイルがXMLで書かれるのでSQLだけでテストしたい際には、SQL定義を編集しないと実行できないっていう手間はありますが、一度実行してログを出力させてしまえばすむ話です。
個人的に、こういうフレームワークが大規模案件で採用されることは、フレームワークのその後の品質向上や、少ないドキュメント関係の問題解消に繋がる可能性があるので、とても喜ばしいのですが、「一般に「S2Daoを使いたい」」ってところだけが、ものすごく疑問に思いました。
過信だったら大変 (スコア:2, 興味深い)
と思ってるだけで実はかなりいい加減なことをやらかしてたら・・・とか思うと怖いですね。
Javaが初めてだろうと、別言語での経験があれば、言語間の差なんて誤差レベルだと思うのは#982975 [slashdot.jp]のコメントの通りなのですが。
木に竹を継いでも (スコア:3, 興味深い)
こういったフレームワークって, 大前提として前工程のシステム設計を, オブジェクト指向なりなんなりの比較的現代的な手法で行わないと効果半減なんですよね. 一方, 銀行業務システムを設計する人って, 多くが20年前の第二次オンラインの時のシステムに縛られているんで, 20年前の設計手法(フローチャートとレコード定義のレベル)に留まっている人が多いってのも事実で.
ですから, この場合
のどちらかってことになると思います. 前者は, まあ言ってみれば設計のやりなおしですから, 出来れば理想的なんですが, 現実には難しいです. ということで, 普通は後者のパターンに行っちゃうことが多いです.
で, 最終的に出てきたコードを見ると, 使用言語にかかわらず, 20年前のCOBOLと同一パターンで
なんて具合になっています. もうこうなると言語仕様がどうこうなんてレベルじゃないですね. Prologぐらい根本的な思想の違いがなければ, 100年ぐらい変わらないんじゃないですかね.
親コメント
Re:木に竹を継いでも (スコア:2, 興味深い)
Javaでこれやっちゃうとぬるぽと配列の境界値制限超えでプログラムから例外が数多く出ることになります。
1000行のうちの最初の100行がnullと空文字列チェックのif文とログ出力のコピペが延々と続くのをよく見ます。
引数がクラスであればメンバがほぼ全てString、クラスでなければほぼStringなわけです。
いいかげんになんでもIDにしてしまう設計を見直さないと生産性向上とか品質向上ができないと思うのですが、皆様の開発現場ではどうでしょうか？
ログ出力ならともかくソースコード上で延々とIDを見せられるとデバッグに余計な集中力がいってたまりません。
親コメント
フレームワーク、フレームワークと言うけどさ…(スコア: -1, フレームのもと) (スコア:2, すばらしい洞察)
元下請けプログラマーより。
補足 (スコア:2, 参考になる)
Open Tech Press | 三菱東京UFJ銀行がミッションクリティカルシステムにオープンソースを採用 [opentechpress.jp]
というのに個人的には感心したり。金融系って先進技術は使わないというレッテルを貼られがちですし。
Re:補足 (スコア:2, 参考になる)
UFJのLinux採用事例 [itmedia.co.jp]のいくつかの [hp.com] 導入事例 [ctc-g.co.jp]や
当時の担当者のインタビュー [nikkeibp.co.jp]をどれか一つくらいリンクしたほうが良かった。
オープンソース採用のネックとなるのは、なんといっても品質保証で、
Seaser2だろうがStrutsだろうがオープンソースというだけで
基本的に敬遠する企業担当者は少なくないこと。
（実際、やみくもに採用した青森の失敗事例 [slashdot.jp]がある）
UFJは、既に問題をねじ伏せて採用してきた実績があるって事を
前提知識にすると、オープンソースかどうかは重要でなく、
国産フレームワークの実績支援という視点が見えてくると思う。
関係ないけど、スラドで評価が高い三井住友銀行は富士通が構築 [fujitsu.com]してるのか。
証券システムトラブルで、矢面に立たされる事が多かった富士通が。
親コメント
Re:補足 (スコア:2, 参考になる)
同業者の集まりで「現在銀行のシステムを担当していて、DBはOracleでクライアント部はJava使ってます」と言ったら「銀行でそんな普通のシステム使うの？」みたいなことを言われたことがあります……。
＃そろそろIDで言うのもアレですがID
親コメント
Re:補足 (スコア:2, 興味深い)
ちょっと調べれば分かることですが, 三井住友銀行のシステムはIBM, NEC, 富士通がやっています. 大きくはメインの勘定系はIBM, 営業店連携がNEC, 外部との接続が富士通という分担で, ハブシステム [nikkeibp.co.jp]を形成しています.
銀行のシステムは大きな所では基本的に銀行側のシステム部隊が構築を行いますので, メーカ側は運用などのテクニカル, 基盤技術等を除けば, 下請けと考えてもよいでしょう.
親コメント
Re:補足 (スコア:2, 参考になる)
ここのところ、銀行によって実情はかなり違うようです。
銀行側のシステム部隊というのがきちんと機能していたのは、旧三菱、旧UFJで、ここでは「銀行システム部(設計)>システム子会社(構築)>大手ベンダ(運用)」の順に仕事が流れていたはずです。
一方、旧富士では、「銀行システム部(なにしてたんでしょう)>富士総研(設計・構築)>ベンダ(構築・運用)」、旧一勧は「銀行システム部>日立(設計・構築)>勧銀システム(構築・運用」になっていたと聞いたことがあります。
ちなみに、証券では、自社の部隊で構築ができる会社は皆無といっていいです。旧大手4社はシステム子会社が全部開発を行う体制だし、準大手以下は通常パッケージか共同利用型システムです。
親コメント
10年くらい前を思い出します (スコア:2, すばらしい洞察)
10年ほど前、まだインターネットの普及黎明期でしたが、どこかの企業や芸能人がホームページ(という表現が正確かどうかはともかく、俗称として)を立ち上げるたびニュースやプレスリリースが公開され話題となっていました。
10年前の「ホームページ」が今では「オープンソース」になっているのですね。
「あの三菱東京UFJがオープンソースを採用」ということがニュースになっていることから察するに、まだまだオープンソースが一般化しておらず消化されていないという証でもあったりします。
10年後、オープンソースが一般化するかどうかは私には解りませんが、それに向けてまだまだ努力せねば、と思うばかりでした。
見える... (スコア:2, おもしろおかしい)
Re:部門名 (スコア:1)
親コメント