- 1 名前：デフォルトの名無しさん mailto:sage [04/08/09 18:36]
- 一部で話題になっている国産オープンソースDIコンテナSeasar V2(略してS2)。
ってどうよ？みんなもう使ってるの？
最近、気になるのでスレ立てました。
使用経験とか、実戦配備情報とか、つかえねーよボケ、とかいろいろ書いてね。
それではスタート！
本家 seasar.org
www.seasar.org/
Seasar Projectグループ
seasarproject.g.hatena.ne.jp/
関連スレ(なのか?)
Java Spring Frameworkを語るスレ
pc5.2ch.net/test/read.cgi/tech/1077465099/
Java⇔RDBのMapping-Frameworkを語るThre Vol.3
pc5.2ch.net/test/read.cgi/tech/1090653286/
- 281 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/04 15:22:57]
- 私はどちらかというと方法論者(Methodologist, 社内でRUPとかの推進をしています)で，その立場からSeasarを応援(期待)しています。
理想的には純粋なOO分析，設計でRUPなのですけど，スキルやリソース，コストの観点からは最低レベルの技術者でも一定の枠組みに従って開発できる仕組みと方法論が必要というのが現実のところです。Seasarと「くーす」はその一つの回答となっていると考えました。
こちらでもはぶさんのおっしゃられているようにもう少し建設的な意見があると良いかなと思うのですがどうでしょうか。
- 282 名前：デフォルトの名無しさん mailto:sage [04/10/04 15:40:36]
- >>280
冬ソナかよ！
- 283 名前：デフォルトの名無しさん mailto:sage [04/10/04 16:20:52]
- >>281
そんなに否定的な意見ばっかりかなぁ？
否定的意見に対する反論もあるし、後は読んだ人が自分で判断することなのでは。
- 284 名前：デフォルトの名無しさん mailto:sage [04/10/04 16:24:41]
- >>281
匿名の場合、ネガティブな部分が大きく出て、建設的な意見は出にくいと思う。
ナイスアイデアは名乗ってから言いたいからな。
逆に、否定的な意見をここで拾えばよろしい。
>>279-280のようなとても建設的な意見もあるが。
っていうか笑わせるな。ひさびさ腹いたくなった。
- 285 名前：デフォルトの名無しさん mailto:sage [04/10/04 16:33:30]
- 否定的なことを建設的に書けばいいんじゃないかな。
特定個人をとやかくいうんじゃなくて例えばJavaDocがない
とかならS2DaoのここだけでもJavaDoc書けやゴルァとかな。
何をやればもっと良くなるのかを指摘してやればいいんじゃないかな。
- 286 名前：デフォルトの名無しさん mailto:sage [04/10/04 17:00:55]
- 全体的な指摘だと、こうするべきっていうのは書きにくいからなぁ。
現状サイトが貧弱だし、最初の入り口になるナビゲーションが非常にとぼしい。
最初になにをすればいいかわからないしな。
何度も言ってるけど、使ってみないとなにができるかわからない。
DIやAOPがなんであるかを知っていないと、使おうと思わないだろうな。
こういうのは、「ここをこう」みたいなヒトコトじゃ指摘できないんだよね。
ま、とりあえずホームページの体裁を整えて欲しい。
作者のブログとはいえプロダクトとはあまり関係ない話題を引用してきてどうこういうのはどうかと思うが。
- 287 名前：デフォルトの名無しさん mailto:sage [04/10/04 17:35:04]
- トップページは何の更新もないし、タイムスタンプで新しくなったのがわかっても、ダウンロードするまで何がかわったかわからないし。
で、よくみたらブログにはちゃんと書いてあったりする。
- 288 名前：デフォルトの名無しさん mailto:sage [04/10/04 19:26:46]
- >>287
それははなからブログをチェックするのが正解かと。
- 289 名前：デフォルトの名無しさん mailto:sage [04/10/04 19:34:44]
- >>281
２ちゃんのスレは「小さなはじめの一歩」次第でどうとでも変わります。
一旦方向性をみつけると、良くも悪くもそちらへ爆走します。
どちらに向いて爆走するかは「小さなはじめの一歩」次第です。
太田氏が「方法論者(Methodologist, 社内でRUPとかの推進をしています)」であるなら
その現場で培われた成功例(例えば、知識のない人にどう啓蒙していったのか、どうや
って教育したのか、何を見せどう説明したのか等など)を書き込んでもらえると、このス
レにとって「前向きな小さなはじめの一歩」に成り得ると思うんですが・・・・・・・・
勿論、ただの要望で「もしよろしければ」という話です。
- 290 名前：デフォルトの名無しさん mailto:sage [04/10/04 19:56:47]
- >>288
そういう情報は、「公式サイト」には書いてないからねぇ。
別に広めるつもりがないならかまわないけど。
雑誌なんかでSeasar知った人が、ブログをチェックしないといけないとは考えないだろ。
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。
- 291 名前：デフォルトの名無しさん [04/10/04 21:59:47]
- 国産じゃデファクトスタンダードには間違っても為らないワケで。
国産唯一の利点は「ドキュメントに読みやすい日本語が期待できる」だが、
それも無いし。
結論：ｲﾗﾈ
- 292 名前：デフォルトの名無しさん mailto:sage [04/10/04 22:23:32]
- デファクトスタンダードは難しいだろうけど、ニッチでもいいじゃん。
世の中みんながトヨタやフォードに乗ってるわけでもなければ、
OracleやDB2を使ってるわけでもないんだから。
つーか、デファクトはEJB3.0なんじゃないの？
実際の小さい仕事で使ってみて今、基本部分が出来上がったとこ。
業務ルールとそれのつなげ方を分けて管理できるライブラリ、って感じで使ってみたけど
なかなかイイよ。俺は手抜きしてついつい業務ロジックを大きく作っちゃうんだけど、
単純なクラスをDICONで連結する構造が、結構自然に簡単にできた。
慣れるまで１週間くらいはかかったけど。さすがに１時間じゃ無理ぽ。
あと、バックエンドが簡単になったらフロントの Struts の辛さ倍増。
はやくS2JSF使わせてけろ。
- 293 名前：デフォルトの名無しさん mailto:sage [04/10/04 22:37:47]
- >>292
使ってみれば、いいことはわかるんだよ。
そのための情報が少ないのが問題だね。
ブログ騒ぎで「ここだけの話」を見てみたら、リリース情報が逐一載っていた。
唖然とした。
公式サイトのチェックはしてて、新しいもののリリースは最近ないものだと思っていた。
- 294 名前：デフォルトの名無しさん [04/10/05 00:05:04]
- 公式サイトのwhat's newが欲しいってのはわかるなー。
- 295 名前：デフォルトの名無しさん mailto:sage [04/10/05 00:35:33]
- MLでは逐一リリース告知されているわけだが
- 296 名前：デフォルトの名無しさん mailto:sage [04/10/05 01:04:23]
- sourceforgeにも、リリースメモがあると思うが。
- 297 名前：デフォルトの名無しさん mailto:sage [04/10/05 01:09:10]
- 要するに興味ないくせに文句だけは言いたいわけだ
- 298 名前：デフォルトの名無しさん mailto:sage [04/10/05 02:21:15]
- >>293-294
ttp://sourceforge.jp/projects/seasar/news
- 299 名前：デフォルトの名無しさん mailto:sage [04/10/05 03:09:38]
- 探さないのが問題だとも言えるし、探さないと見つけられないようなのが問題だとも言えるかも。
- 300 名前：デフォルトの名無しさん mailto:sage [04/10/05 07:09:43]
- >>295-298
「仲間うちで使うための便利なもの作ってます。使いたければ勝手に使ってください」
というスタンスだというなら、とやかくいうつもりはないが。
- 301 名前：デフォルトの名無しさん mailto:sage [04/10/05 07:16:45]
- とりあえず、公式サイトは吉田カバンなみ。
- 302 名前：デフォルトの名無しさん mailto:sage [04/10/05 09:17:27]
- ていうか、Seasarに文句言ってるヤシは、Springを使ってるの？
- 303 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/05 10:31:46]
- 289さん>
とりあえず社内外で
patterns-wg.fuka.info.waseda.ac.jp/study/8th.html
なことや，社内でのRUP研修で紹介して興味を持ってもらっている段階です。
私は開発ではなくテストが専門なので，その分野から攻めていって「テストが効率が上がる」というと興味を持ってくれるSEが多いです。
- 304 名前：太田＠会社 mailto:oota_ken@hotmail.com [04/10/05 10:36:55]
- あとはオブジェクト指向分析・設計の研修ですと，
やはりみなさまオブジェクト協調関係の生成をどのオブジェクトがどういったタイミングですべきかについて悩むが多いです。
そこで，Robert C. Martinのオブジェクト指向の基本原則などとからめて，DIコンテナを説明し，
もっともとっつきやすい(私の主観ですが)，Seasarを紹介するという形です。
- 305 名前：デフォルトの名無しさん mailto:sage [04/10/05 11:22:56]
- モノ自体の仕組みとしてはとっつきやすいと思う。
SeasarのBean定義はSpringより少ない記述量でできる。
だから、わかってる人が近くにいれば、とっつきやすいと思う。
問題はわかっている人が近くにいないとき、Springの方が情報が得やすいということ。
- 306 名前：デフォルトの名無しさん mailto:sage [04/10/05 12:57:39]
- >>305
>Springの方が情報が得やすいということ。
そうか？
Springは機能やら専門用語が多すぎて、わけわからん。
- 307 名前：デフォルトの名無しさん mailto:sage [04/10/05 14:08:15]
- >>306
書籍に記述もあるし、網羅したリファレンスもあるし、そのモノが難しいというのは置いておいて、情報は得やすいと思う。
AOPのための記述とか、Seasarに比べるとアホみたいにめんどい。
もっと簡単な記述があるのかもしれないけど。
- 308 名前：デフォルトの名無しさん [04/10/05 14:58:08]
- S2のJavadoc、@authorの下の行にコメント書いてある。
作者はJavadoc使ったことねぇのかな？少し笑えたぞ。
- 309 名前：デフォルトの名無しさん mailto:sage [04/10/05 18:10:02]
- 「2chに悪意を持って書き込む奴がいる」って何をいまさらｗ
- 310 名前：デフォルトの名無しさん mailto:sage [04/10/05 18:59:41]
- 善意がないだけで、悪意もないと思うんだけどね。
無責任なだけで。
「Seasar2はインストールするだけでシステムが不安定」とか事実ではないこと書けば、それは悪意があるんだろうけど。
- 311 名前：デフォルトの名無しさん mailto:sage [04/10/05 19:00:08]
- >>309
ところで、どこに書いてあるの？
それ。
- 312 名前：デフォルトの名無しさん mailto:sage [04/10/05 19:34:49]
- なんか、サイトの構築始まってるね。
左側のメニューにWhat's newが欲しい、とか、ロードマップが欲しいぞな、とかは思うが。
まあとにかく要望は出せばキリがないからほっといて、早いトコサイトインできるようにがんばって欲しいね。
せっかくWEB+DB PRESSに寄稿したり、JAVA PRESSに記事が載ったりしてんだからね。
記事みてサイトにアクセスして迷子になってあきらめる人がいるだろうから。
- 313 名前：デフォルトの名無しさん mailto:sage [04/10/05 19:55:27]
- 307を書き込むときに、AOPのドキュメントってこんなに充実してたかなぁと思ったんだけど、やっぱり書き直されてたのね。
サイトの更新履歴も欲しいぞな。
ブログベースってことで、どうなるのかしらんけど。
まあ、関係者のブログの関連するネタを整理して、アイドルネタを省いたものになるという感じか。
- 314 名前：デフォルトの名無しさん [04/10/05 21:38:25]
- EJB以外を使う香具師は、厨房。
- 315 名前：デフォルトの名無しさん mailto:sage [04/10/05 21:45:06]
- >314
そんな餌（ｒｙ
- 316 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:05:08]
- というか、厨房でもなんでもいいから、動くものを早く手軽に、ってことだな。
いくら高尚で美しい設計でも、利用開始に間に合わないんじゃ仕方ない。
- 317 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:18:29]
- >316
他のコンポーネントやテーブル設計を待たずに実装とテストのフェーズに入れる＞S2Unitによるリードタイムの短縮
S2OpenAMFやS2FlexみたくWebベースでHTML以外のUIの選択肢でも連携する手立てが用意されてるのもS2の良いところかもな。
- 318 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:24:55]
- >317
他のコンポーネント→他の’関連する’コンポーネント’の実装’
>313
S2DAOのドキュメントも刷新されてますね。
- 319 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:30:46]
- 真剣に「くーす」で設計してみようと思って、ひがさんの↓
ダイコン事態の設計手法と、その２
を読んだ。
最後の「何か合コン誘われたから行ってくるわ」が気になったので読んで見た。
関係ねーじゃねぇか＞くーす
もう帰る。ｳﾜｧｧｰﾝ
- 320 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:37:44]
- >316
御意＞いくら高尚で美しい設計
美しい設計はあくまでメンテナンス性の為の一手段に過ぎない。
そうありたいし、心掛けてるが納期に間に合って、利益を生むのが大々前提。
で、プロジェクトには新人さんも（使用するテクノロジーに）不慣れな人間も居るのが当たり前。
彼らが、この先淘汰されるかどうかは知ったことでは無いが、現実の案件をデスマらせない
には、個々のスキルに任さないのは一つの立派な考え方。
数を集めるより少数精鋭の方がコストメリットもあるとは思うけど、愚痴をたれても仕方無い。
というわけでS2が選択肢としてあって、使ってるんだが。
- 321 名前：デフォルトの名無しさん mailto:sage [04/10/05 22:41:10]
- >319
御愁傷様（藁。くーすについては大阪のからさわぎの資料がテンプレも付いてるので興味深いな。
- 322 名前：316 mailto:sage [04/10/05 23:03:41]
- じゃあDIは美しくない設計なのか、というと、そうじゃないんだよね。
むしろ、DIだと設計をしなくてよくなるので、美しいとか美しくないとか判定する必要もない。
各機能各層について独立したクラスを作って、ゴンゴン組み立てればいいわけだから。
どこでオブジェクト生成してどこに保持してどうやって受け渡すか、それをいかに美しい設計で実現するかなんて考える必要はないんだから。
もちろんミクロやマクロの設計はしないといけないけど、それはEJBだって助けてくれるもんじゃない。
それにミクロやマクロの設計は楽しいし。
- 323 名前：デフォルトの名無しさん [04/10/05 23:19:30]
- without hairとか、禿げ本、禿げ会とかさー、言語の壁を隠れ蓑にして、
先人（Rod）をリスペクトしない姿勢が、鼻につくんだよ。
お前ら、Rod本人に向かって、禿げって言えんのかよ。
- 324 名前：デフォルトの名無しさん mailto:sage [04/10/05 23:25:07]
- 他者に優しいのが、XPのペアプロに代表される少数精鋭の徒弟制度。
「スキルの無い奴」とか
「彼らが、この先淘汰されるかどうかは知ったことでは無い」とか、
結局お前、自分に優しいだけちゃうんかと。
- 325 名前：デフォルトの名無しさん mailto:sage [04/10/05 23:33:39]
- >>324
それ作者にも言ってやれ。
- 326 名前：デフォルトの名無しさん mailto:sage [04/10/05 23:39:53]
- >324
少数精鋭のXP、って時点でスキルの無い奴がはじき出されてるぞ。
仕事なんだから、最低水準の質を確保する仕組みってのは求めて当たり前でしょ。
そこから先、どう仕事に取り組むかは個人の問題なんだから。
- 327 名前：デフォルトの名無しさん mailto:sage [04/10/05 23:43:41]
- >323
コミッタでも近しい関係者でも無いよ。確かにイクナイ ＞お前ら、Rod本人に向かって、禿げって言えんのかよ。
禿しく同意だ。が、ひが氏本人が言い出した訳でもあるまい。
323本人の発言ではないと思うが、かといって逆にウンコ呼ばわりしたら同じ穴の狢でしょ？
>324
少数精鋭の徒弟制度がすくすくと育てば、ある意味で素晴らしいと思う。
で、’まず’自分に優しいのは当たり前だろ？社内のみならず協力会社を含めた遍く全ての他者が
今後、どう身を振るかまで慈悲深く’優しく’すんのかい？
- 328 名前：デフォルトの名無しさん mailto:sage [04/10/06 00:48:38]
- >>323
Rodにハゲと言える仲になりたい。
- 329 名前：デフォルトの名無しさん mailto:sage [04/10/06 02:12:53]
- つーか難癖つけすぎ。
粗探しばっかりでは面白くない。
- 330 名前：デフォルトの名無しさん [04/10/06 02:24:16]
- まぁ、１のことを１０の言葉で語る人のことはさておき
（cocoon本のころは良かったのになぁ）、ちょっと本質的なネタを
振ってみたいな。
(1) S2を使うと、本当にテストがしやすくなるのか
(2) S2を使うと、本当によいものができるのか
(3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
(4) S2を使わないと、上記のようなことはできないのか
(5) 成果物全体がS2に汚染されるけど、それはOKなのか
まぁこの際S2をDIコンテナと言い換えてもいいや。
いくつかモノを作ってみたが、(1)はまぁ同意できる。
EJB使ってるとFactory駆使しないと結合を切れないが、
その辺をフレームワークとして統括できるのは便利。
(2)〜(3)は、ツールで解決するものか？という気がぬぐえない。
あと、テストパターン研究会でも話題になったが、ソースコード
トレースがし難くなるのは避けられないという問題もある。
(4)は程度の問題か。(5)はメリットとの天秤になるのかな。
インテグレーションクラス周辺だけ使う、というのが現実的か。
ところで、S2が正しくinjectionしてくれるかどうかの
テストはどう書けば？（汗）
というわけで皆の意見を聞きたい。
- 331 名前：デフォルトの名無しさん mailto:sage [04/10/06 03:11:04]
- 似たような方向の技術ならスタンダードなものを選んで習得するのが鉄則。
となると、EJB以外の選択肢は無い訳で。
- 332 名前：sage [04/10/06 05:47:27]
- >>330
>ソースコードトレースがし難くなるのは避けられない
これはDIの概念を読んだときからずっと気になってた。スキルの低い技術者が
出入りする大規模なプロジェクトでは影響がでかくない？
モデリングがちゃんとできる人がインターフェースの設計まで
きっちり終えてからコーディングさせないとメンテ不能なソースになりそう。
ひが氏はクラス図すらいらないみたいな事をどこかで言ってた気がするけど。
開発者もメンテナもくーすに従えば解決するのだろうか？
- 333 名前：332 mailto:sage [04/10/06 05:49:57]
- sage間違えて恥ずかちぃ
- 334 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:27:38]
- >>323
何だSpring派がS2叩きしてるだけか
- 335 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:29:10]
- >>324
少数精鋭をどう育てるの？
- 336 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:32:15]
- >>324
スキルのない奴が淘汰されるのは当然だろ？
- 337 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:33:15]
- >>323
で、オマエはRodの言ってることどれだけ理解して実践してるの？
- 338 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:36:42]
- で、お前等結局
１）S2が邪魔
２）ひがが嫌い
３）羽生がウザイ
のどれYO？
- 339 名前：219 mailto:sage [04/10/06 06:38:27]
- 俺のおかげでスレも伸びたし S2 も注目されたわけだ。感謝汁！
- 340 名前：デフォルトの名無しさん mailto:sage [04/10/06 06:55:09]
- 羽生ウザイ
羽生はキチガイ
羽生はデブ
羽生はウンコ
羽生は氏ね！
- 341 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:17:30]
- >323
Spring派とかいうわけでも無いんじゃね？
>331
EJBとがどこがどう似てるんだろ？スタンダードってのは
2.0なのか、それとも先の3.0のことを指してるんだろうか？
先のことを指すんであればそれこそJDOも含めて、流れが
どうなるか判らんと思うんだが
>330
(2)、(3)は今後のくーす次第かな、S2を使うからどうなるわけでもない。
(4)は疑問自体が難しいな、逆にどう思います？
(5)についてはDIコンテナが依存性を注入するので汚染？と
言われてもと思うんだけど
だからトレースやりづらくなるというのは判らなくもない
- 342 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:19:48]
- >340
ID表示が無い板だからといって朝から釣りはやめような
- 343 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:25:08]
- ＞＞３４２オマエ羽生だな（ｗ
- 344 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:25:54]
- 羽生氏ね（藁
- 345 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:29:44]
- 219頑張れ！219は正しい！219はネ申！羽生氏ね！
- 346 名前：デフォルトの名無しさん mailto:sage [04/10/06 07:34:43]
- >343
釣れて小躍りしてるかもしれんけど赤の他人だ、
数少ない君の人生の喜びを奪って申し訳無い。
>332
どうだろう？メンテナというかカットオーバーしてチーム
が解散、保守は引継ぎってところで発生する問題点は
まだ言及されてないんじゃないかな。
diconのまとめかたを含めて330のトレースの問題が
出てくるかもしれない。
- 347 名前：デフォルトの名無しさん mailto:sage [04/10/06 08:59:40]
- >>330
全て、S2やSpringを使えば無条件にというわけではないというのは前提。
> (1) S2を使うと、本当にテストがしやすくなるのか
コンポーネントが独立するので異なる環境で動かしやすくなる。
> (2) S2を使うと、本当によいものができるのか
よいものの定義にもよる。
同じものであれば早くできるようになると考えれば、よいものにするための時間が多く取れるのでよいものができる確率が高いといえるかも
> (3) S2を使うと、本当にスキル低い人でも一定の品質を保てるのか
スキルが低い人が一定の品質を保てるのではなくて、スキルが低い人がいても一定の品質を保てる、だと思われ。
コンポーネントの独立度が高くなるので、スキル低い人の影響が減らせる。
> (4) S2を使わないと、上記のようなことはできないのか
DI+AOPを使わないと、初期コストがかかりがち。
ただし、その場合はプロジェクト用フレームワークをかっちり作ることになるので、DI+AOPを単純に使う場合よりも楽にできるかも。
でも、同じ努力をDI+AOPを使ってやったらもっとやりやすくなるだろう。
> (5) 成果物全体がS2に汚染されるけど、それはOKなのか
設計がDI前提のものになるだけで、個々はあまり依存しない。POJOだし。
だから、S2とSpringを切り替えることも、S2を使わなくすることも、個々の部分には影響なくできる。
と思う。
- 348 名前：デフォルトの名無しさん mailto:sage [04/10/06 09:02:27]
- ソースコードのトレースが難しくなるって
んなもん、ＯＯＰになってから諦めてますよ
ただ、インターフェースの設計をかっちりやらないとダメなのは同意
くーすでは単なる単体テストがやりやすいとかでなくて、
設計やら仕様のテストについても言及があってしかるべしだとおもうんだが
- 349 名前：デフォルトの名無しさん mailto:sage [04/10/06 11:28:08]
- 今更だが。
>>245 名前：デフォルトの名無しさん[sage] 投稿日：04/10/03(日) 17:56:40
>>半角英数字の前後にスペースを入れるクセは珍しいから直したほうがいいよ
スペースが入ってるほうが見やすいだろ？
Java 標準 API ドキュメント日本語版や Eclipse 言語パック適用後みたいにな。
それとも、こいつらも珍しいから直してもらうか w
- 350 名前：デフォルトの名無しさん mailto:sage [04/10/06 12:21:09]
- >>349
いや、キミを判別しやすくて便利だから構わんのだけど。
- 351 名前：デフォルトの名無しさん mailto:sage [04/10/06 16:19:56]
- >んなもん、ＯＯＰになってから諦めてますよ
俺的にはOOPになってから、スキルの低い人が書いたソースは
前(構造化設計)より酷くなったけど、スキルが高い人が書いたソースは
前と比較にならないくらい読みやすくなったと思う。
クラス図を見ればどの実装がどこにあって、それぞれの責任範囲が見えてくるから。
ヘボが書いたソースは不可思議なところにメソッドが実装されていて
ソースを追うのが困難。スキルはそこそこだけどオブジェクト指向に慣れていない技術者は
画面または機能ごとにクラスを作っていて、「これじゃC言語を構造化設計で
ソースファイル分割していたのと大して変わらんなあ」というのが多い。
- 352 名前：デフォルトの名無しさん mailto:sage [04/10/06 17:59:54]
- 要するに、クラス図があればオッケーってわけで、
なければやっぱりトレースしにくいと思う。
ソースだけで一番追いやすいのは、最後の
「スキルそこそこオブ不慣れ」のソース。
勿論良い悪いは別ですよ。
きちんとドキュメントは残しましょうって事ですかね。
- 353 名前：デフォルトの名無しさん mailto:sage [04/10/06 18:01:39]
- ああそうか、diconファイルが上手いこと
ドキュメントになりゃいいのか。
- 354 名前：デフォルトの名無しさん [04/10/06 18:48:42]
- そりゃそうだ。
DIベースのプログラミングの従来型からの違いはそこにあるわけだし。
- 355 名前：デフォルトの名無しさん mailto:sage [04/10/06 18:57:14]
- >ソースだけで一番追いやすいのは、最後の
>「スキルそこそこオブ不慣れ」のソース。
それは確かにそうかも。
diconからドキュメントにするのはどうかなあ。シーケンス図をかかないと
そのインターフェースで必要十分なのかどうか判断しづらいと思う。
実装に入ってからレビューすると修正作業が多くなるので、やっぱり
あらかじめクラス図とシーケンス図を元にPLがちゃんとレビューして、
修正が終わってから実装に入った方がトータルでは楽じゃない？
まあくーすとは路線が違うのかもしれんが。
- 356 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:14:53]
- DIコンテナのBean定義ファイルは、オブジェクトの関連図になるよね。
コラボレーション図になるのかな。
- 357 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:19:09]
- >>355
そうだよなー。だから開発プロセスについて
あーだこーだ盛り上がるわけだ。
オブジェクト指向のおかげで（せいで？）
ゴリゴリ書いて動けばおしまいってのじゃ
済まなくなったと。
くーす本、楽しみです。
実業務に則して、要件定義から見積もり提示とか
そういうのまで含めてくれるととても嬉しい。
- 358 名前：デフォルトの名無しさん mailto:sage [04/10/06 19:30:30]
- あー、見積りは嬉しいかも
- 359 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:16:01]
- くーすは、要件定義がインプットになるから、要件定義とか見積りとかは無い。
くーすでなくてもいいから、見積りは欲しい。
- 360 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:22:12]
- 結論：EJB3.0 >>> Spring >>>>> S2
- 361 名前：デフォルトの名無しさん mailto:sage [04/10/06 20:30:32]
- EJB3.0が本当に良いならS2EJBが出るような気もするがな
- 362 名前：デフォルトの名無しさん mailto:sage [04/10/06 21:18:38]
- SpringならGeronimo::Springがすでにあるけどね。
プロジェクトだけ。
- 363 名前：デフォルトの名無しさん mailto:sage 釣られ [04/10/06 21:56:25]
- >360
比較できるほど三つとも使い込んでいるのか。
どこでどう差がつくのか是非教えて欲しい。
- 364 名前：デフォルトの名無しさん mailto:sage [04/10/06 22:04:01]
- >360
リリースされてないしさ。まだまだ仕様は変わっていくので
比較は出来ないでしょ。
- 365 名前：デフォルトの名無しさん mailto:sage [04/10/06 22:13:01]
- 是非>>360にEJBとJDOの統合による将来像というのを教えてもらいたい
- 366 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:24:06]
- ひがさんがここを見てるかもしれないんですよね？
ってことはこの板で一番要望が高いS2JSFで「こんなんほしい！」ってのを
書き込むと良いんではないでしょうか？＞ほしがってる方々
- 367 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:35:52]
- はぶ氏が作ったサイトにアクセスしてみたけど、かなり頻繁にMySQLのエラーを吐くな。
もちっと余裕があるサイトに引っ越したほうがいいような。
- 368 名前：デフォルトの名無しさん [04/10/06 23:48:29]
- ロジックとデータの分離って、やりにくくね？
- 369 名前：デフォルトの名無しさん mailto:sage [04/10/06 23:54:26]
- >>366
自分でひが氏のブログにコメントしろ！
ちゃんと返事来るぞ。
- 370 名前：デフォルトの名無しさん mailto:sage [04/10/07 00:07:47]
- >>368
やりにくい部分もあるけど、やれる部分のほうが多くない？
- 371 名前：330 [04/10/07 00:25:56]
- みんな朝からありがﾄﾝ
提案目的は、S2が使えるシチュエーションと注意事項を確認したい、ということね。
330で提示した中で、
(2)と(3)を聞いた意味は、自然なモデリングを変に崩すことになったり、制約が変な方に
働いて妙なものができてこないか
(4)は、書き方がまずかったが、DIパターンの目的である「依存関係のreasonableな分離」
を実現するためにS2は適切なのか
(5)は、importが云々という話の他に、例えば、「コンポーネントはsingleton、状態はク
ライアントが持つ」という考え方に染まったコードになり、理解者（というより共感者？）
以外は気持ち悪い思いをするよね？ということ。
個人的に気になるのは、作成するソフトウェアの複雑性を緩和するブレイクスルーがない
ように見えることなんだよな。
例えば、状態はクライアントに持たせ、コンポーネントはステートレスという思想という
か制約。データとロジックを分離させる方が有効なケースがあるのはわかる。コンポーネ
ントを作りやすくなるケースがあるのもOK（小規模な場合しか想像できないが）。
ただ、一般的には複雑性が増すわけで、適用箇所次第では、複雑性のしわ寄せがクライア
ント側にくるだろうし、コンポーネントも組みにくくなる。
さらに、346が言うように、思想を理解させなければ、こうやって組まれた構成の第三者
の理解およびメンテナンスが困難だ。
というわけで、ぶっちゃけた話、ある程度大きなアプリの適用例とメイキングオブが知り
たいわけだが。これは身をもって体験するのが一番か？
S2に限らず、J2EEのメリットが出るような規模のサンプルって、ほとんど表に出てこない
しね。抽象的か、短すぎる事例報告だけ。というわけで、もーちょっと様子見かな。
- 372 名前：デフォルトの名無しさん [04/10/07 00:27:23]
- >>370
「構造体と関数」って感じで慣れないな。
どうしてもドメインモデルで考えてしまうYO。
ロジックをビジネスロジックとビジネスルールに分けて、
ルールの方はドメインオブジェクトに記述するのはどうだろ。
問題はS2DAOでとってきたEntityに他との関連をインジェクト
しないといけないとこだな。
- 373 名前：330 [04/10/07 00:27:49]
- あ、ソースコードトレースがしにくいってのは、メタデータ使う
フレームワーク全般に言える事ね。オブジェクト指向レベル
どうこうというよりは、頭の中の回路を頻繁に切り替えるのが
おっくう。該当箇所探索もフレームワークのメタデータ特有の
探索方法に特化した知識や支援手段が必要になるのがウザイ。
だいたい、インピーダンスミスマッチがないレイヤーで、
別言語(?)によるコンフィギュレーション使う必然性って
あるんかいな。
テスターは再ビルド権限がないとか、SIerには再ビルド許さん
けど自由度は与えたいとか、そういう運用的理由なら、
わからんでもないが。
というわけで、DIコン使うならPico/HiveMind派（しょーもない着眼点だな、おい）。
- 374 名前：デフォルトの名無しさん [04/10/07 00:33:41]
- ・言葉がダサイ
「ダイコン」「くーす」「から騒ぎ」ちょと恥ずかしい。
・オタくさい
から騒ぎの後、アニソンカラオケ大会。きしょい。
- 375 名前：デフォルトの名無しさん [04/10/07 00:48:22]
- Web層 フレームワーク固有のオブジェクト
↑
DTO
↓
ビジネスロジック層 DTO or ドメインオブジェクト
↑
ドメインオブジェクト
↓
ビジネスルール層 ドメインオブジェクト
↑
ドメインオブジェクト
↓
データアクセス層
こんな感じか。
- 376 名前：デフォルトの名無しさん [04/10/07 00:51:41]
- 戻り値にDIするインターセプタかな。
- 377 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:12:22]
- >372
スマン、ここでのビジネスルールの粒度がイマイチ判らなかった。
揚げ足取りじゃないんだけど、ビジネスって曖昧な伝わり方もするんで、
例えばで良いんで教えて貰えますか？
PicoもHiveMindもよく知らないんだけど、どんな手順でDIするのかな？
>373
S2と関係無くメタデータと上手く付きあわないかんのもしゃあないでしょう。
ひょっとすると、今後は基本設計レベルではメタデータ定義するだけってな
思想になるかもしれんし。実装のソースコード書く人と完全分業みたいなことにも。
>374
ベタベタなほうが伝わりやすいってのもあるしさ。
あ、あとブログ読むと、アニオタ臭いのはコミュニティのごくごく一部な気もする。
ちなみに、から騒ぎ→からさわぎ、な。
- 378 名前：デフォルトの名無しさん [04/10/07 01:33:48]
- >>377
Picoについては
www.picocontainer.org/Two+minute+tutorial
この辺みとけ。お前に与えられた時間は２分間だ（意味が逆）
クソ長いメソッドが多いが、エイリアスで短い名前も用意されてる。
>>367
ブザマだよな（苦笑）。
サービス運用規模の見積もり失敗でつか。
まーボランティアでそれなりの環境用意するのは金かかるので
大変なのはわかるが、今年は2004年です。
- 379 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:38:17]
- >>377
思いつきなんで、はっきりとはしてないんだけど、例えば
・計算フィールドの導出
単純な計算ですむ場合もあるし、導出にStrategyパターンを使う場合もある。
・他エンティティとの関連
User.isMemberOf(Group)みたいなメソッドが欲しい。
ロジック層でisMember(Group, User)ってなるとヤだなって思う。
ビジネスロジックをアクティビティ図で表すとき、それぞれのアクティビティ状態
をルールって呼ぶような感じかな。
- 380 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:41:39]
- >>371
ソフトウェアの複雑性というのは、結局かわらないんじゃないかと思う。
単純に言えば、作るものが決まると、そのプロダクトのエントロピーの下限というのが決まるんではないかと。
そして、管理のしやすいソフトウェアというのは、エントロピーが低いソフトウェアだといえると思う。
フレームワークを使うというのは、エントロピーをフレームワークに押し付けて、コア部分のエントロピーを下げることになる。
ライブラリというのも、エントロピーをプロジェクトの外に追いやる手段だね。
あと、JavaのコードはBean定義ファイルに比べて情報量が多いから、コードを書かかずにBean定義を書くということはエントロピーを下げることにつながる。
そうやって、プロジェクトが管理する成果物のエントロピーを低い状態に保つというのが、すごくざっくり見たDI+AOPの効果ではないかな。
そういう意味では、無限の可能性をもつJavaコードを書く変わりに、数限られたXMLタグで同じことを実現する仕組みであれば、なんでもエントロピーが下げれていいんだよね。
XMLタグの表現力が上がると、それぞれのタグの情報量があがっていくから、またどこかにエントロピーを追いやる必要が出てくるわけだけど。
- 381 名前：デフォルトの名無しさん mailto:sage [04/10/07 01:47:54]
- それを推し進めると、浅見たん提唱のXMLによる伝票指向アーキティクチャになるのか。
|
 |
