国産オープンソースDIコンテナSeasar V2(S2)

国産オープンソースDI ..

540:デフォルトの名無しさん
04/10/11 09:05:44
>>539

いや、しかし、世間的にはどうか知らんが、
漏れの経験では業務アプリでウェブベースなほうがむしろ稀だった。

ウェブベースなのは補助的な用途の場合が多い。
そういうときって、やはりクラスタ機能ある常駐プログラム
作る必要あるわけで、それはJavaで作るならばejbかdiコンテナか選択するんだろうな。

業務アプリに必要なのって、サービスを管理するライブラリだよね。
インストールはコマンド一発。
DHCPでIP振られたら自動的にデータベース起動して、アプリサーバ起動して、
クライアント探して・・・　っていうのを自動でできるようにしなきゃいけない。
（でないと導入コスト高いんだ）

541:デフォルトの名無しさん
04/10/11 09:37:23
>>540
S2の用途は539の言うとおりだと思う。
S2が自分の用途に向かないなら他を探すのが良いと思う。

542:デフォルトの名無しさん
04/10/11 10:28:32
今のトレンドはStatelessだよな。EJBを使うにしてもだよ。
ということは負荷分散をEJBコンテナがやらなければならない
ケースは少ないといえるんじゃないのか。しかもHTTPだろ。
俺ならロードバランサを前に挟むけどな。

543:デフォルトの名無しさん
04/10/11 10:30:16
>>537
そういう場合は、DBの機能を使うよ普通。
OracleならRACとかな。EJB使うほうが当てにならん。

544:デフォルトの名無しさん
04/10/11 10:38:24
>>532
実際要らないシステムが多いだろ。デプロイが楽だからWeb使うだけで
大したトランザクション量じゃないシステムも多いよ。

>>534
そりゃそうだろ。DI自体がEJBに対するアンチテーゼだからな。
インコンテナのテストなんて面倒だろうに。
当のEJBだってPOJOに方向転換じゃないか。

EJB*だけ*がスケーラビリティ確保の手段だと本当に思ってるのか？
PHPで大規模やってる連中だっているだろ。そいつらが
どうやって負荷分散やフェールオーバを実現しているのかを見れば
EJBのレイヤーでなくてもやれることがいっぱいあるのはわかるだろ。
頭が固いか不勉強か単なる言いがかりかのどれかに見えちゃうぞ。

545:デフォルトの名無しさん
04/10/11 10:49:08
>>534
EJBの長所が負荷分散だというなら
それはEJBでなくても他に汎用的で
実績のある代替手段を使えばそれで
済むんだからEJBｲﾗﾈってことになるな。
EJBのテストが面倒なのは事実。
性能が出なくて変なテクニックばかり
横行するO/RマッピングもHibernateや
S2Daoのほうが便利で性能がいい。
EJB-QLなんて何の意味がある？
EJBの長所は何があるんだ？
DIがなくてもEJBにはウンザリしてるよ。

546:デフォルトの名無しさん
04/10/11 10:50:42
EJB擁護派はこちらで論破してきてください。

EJBは終わってる
ｽﾚﾘﾝｸ(tech板)l50

547:デフォルトの名無しさん
04/10/11 12:42:54
>>537
フェールオーバとロードバランスは別だよ。
でもってどっちもDIとかEJBとか関係なく
考えるべきものだから。クラスタリングは
EJBの専売特許ではない。

548:デフォルトの名無しさん
04/10/11 13:41:47
>540
「DIコンテナ」部分だけ使うなら、他を自作しても邪魔にはならないよ。
S2開発者が主軸に考えてるのがWebだってだけ。
周辺プロダクトはそれに合ったものからでてくるけど、別に必須ってわけじゃない。

業務機能と非業務機能を全部自作するにしても、DIコンテナで管理できると楽だ。

549:デフォルトの名無しさん
04/10/11 14:05:45
>>540
なんか、もっとすっきりできる気がするが・・・

550:デフォルトの名無しさん
04/10/11 14:52:49
diconファイルはシンプルだけど、それでもいろいろ書き間違える。
Kijimunaがないとやってられない。
Kijimunaってどれくらい使われてるんだろう。
SpringIDE(?)と比べるとどう?

551:デフォルトの名無しさん
04/10/11 15:02:57
>>550
「どれくらい使われているか」より「どれくらい使いやすいか」の方が大事

552:デフォルトの名無しさん
04/10/11 15:22:36
>>551
最新バージョンは使いやすいよ。
何が自動インジェクションされているかも分かるし、
コンポーネントの定義からソースにも飛べる。

553:デフォルトの名無しさん
04/10/12 01:45:36
Strutsでページ遷移の単体テストにS2Struts使うと楽になりますかねぇ？

554:デフォルトの名無しさん
04/10/12 07:30:29
>>553
なるよ。

555:デフォルトの名無しさん
04/10/12 21:58:53
JBossで座絶したんだけどこれ結構使える？

556:デフォルトの名無しさん
04/10/12 22:14:53
ちょっとずつ始めれるので、挫折しにくいよ。

557:デフォルトの名無しさん
04/10/13 00:04:53
何に挫折したのかを書くと世話焼きが相手をしてくれるぞ
Servletで挫折したならそれはJBossのせいじゃないからな。

558:デフォルトの名無しさん
04/10/13 02:59:31
インストールで挫折しますた。

559:デフォルトの名無しさん
04/10/13 03:04:47
ダウンロードに挫折しますた。

560:デフォルトの名無しさん
04/10/13 10:51:27
はぶにっき、訳分からん。突然切れチョル。
日記だからっちゅうても、雑誌に「S2はblog駆動」とか書いてるん
だから、何について言ってるんかハッキリするか、非公開にするか
せんと。
自分、さんざん内向きにアピールしちょるやないけ。
ひが氏が２chの戯言にまで耳を貸して、開発やドキュメント整備に
尽力しとるのを、足ひっぱっとりゃせんか？

車やコンピュータや家電だけが産業と違うじゃろ。
ハードウェア屋がコスト削る部分なんざ、ソフトでいえばコンパイル部分よ。
ここがこれ以上ないぐらい最適化されとるんやし、全品オーダーメイド
で、掛かる費用ほぼ人件費な状態を、車と一緒に考えられんわい。

「客に向け」「この業界に先はない」っちゅうんは至極まっとうだと思うが。
URLﾘﾝｸ(d.hatena.ne.jp)

561:デフォルトの名無しさん
04/10/13 10:53:23
メインフレーム時代からコストどれだけ下がったか。

562:デフォルトの名無しさん
04/10/13 10:59:26
>>560
あれは基本的に経営側の人間であって開発側の人間ではないのよ。
だから、経営の視点で開発の人間を判断して、当人としては歯がゆい思いを感じているんだろう。
といって、偉そうなこと言う割にはべつに経営で成功しているわけではないあたり、
文句たれている相手と同じ程度の人間であることをさらしてしまってるのだが、
それに気付いていない無知の無知がちょっとイタい。

563:デフォルトの名無しさん
04/10/13 11:16:17
>> 562
人格はどうでもいい。

564:デフォルトの名無しさん
04/10/13 11:27:28
つうか、はぶ氏個人の評価はスレ違い。

565:デフォルトの名無しさん
04/10/13 11:40:43
「経営側に回れるだけレベルは上」と考えてるんだろう、ある意味間違ってないが

566:デフォルトの名無しさん
04/10/13 12:00:24
>>560
URLﾘﾝｸ(capsctrl.que.jp)
ここへのコメントの続きじゃないの？

ここの人、若いんだけど、いっつも歯に衣着せぬ物言いなんで
（あ、若いからか）、いっつも微笑ましく読んでたんだけど
さすがはぶたんですなー、容赦せんもん。

上記サイトの人、今会計の仕訳の勉強とかしてるみたいで、
そういう勉強中の人に「DOAなんて否定的な表現」うんぬん言われると、
むちゃくちゃ厚い債権債務帳票とか出したり、
やったらきっつくて頭の切れる、出禁とかすぐ口に出すお客さんと
仕事した事あるのかなあ、と思ってたので、
ちょっとだけ溜飲が下がったよ。

はぶたん徹底して「顧客」って言わないね。お客様、と言う。
ちょっと気持ち悪くは感じたけど、プロなんだなとは思った。

567:デフォルトの名無しさん
04/10/13 12:38:18
まあなんつーか、たまに余人に見えないモノが見えてるヒトではあらぁね、
ソレが天才だからなのかデムパ受信してるのかはむろん余人に分かろうハズは無く…

ナニが言いたいかつーともーすこし他人の目を意識して書いてくださいと

＞金持ちに寄生して搾取してるだけじゃん。狭い世界の中で偉そうにしてるだけですよ。
＞OOもDOAも構造化も全員そうだよ。コバンザメでしかないよ。世界中が腐ってる！

568:デフォルトの名無しさん
04/10/13 13:02:47
コメント化って空のコメントがあるだけなんだけど
なんか書いてあったの？

569:デフォルトの名無しさん
04/10/13 13:14:31
相変わらず個人ネタか。

570:デフォルトの名無しさん
04/10/13 13:39:38
でも、お客にとっちゃOO分析だろうがER分析だろうが
知った事ではないだろうってのは、
くーすのよってたつ所なのではないかなあと思った。

だから本がどんなんなるか楽しみな訳で。
前に、見積もりの提示の仕方についても盛り込んでくれたらなーって
ここに書いたんだけど、それも上記が理由。

571:デフォルトの名無しさん
04/10/13 14:24:45
> 方法論がエンジニアにとって癒しにしかなってないじゃん、って思うんですよ。そりゃね、
> みんな賢いからさ、そういう人間が集まって膝突き合わしてそういうやり取りしてれば、
> 自分だけじゃない、って思えるしそりゃ楽しいでしょう。

> 別にS2でなければならない、ってこともないんですよ。EJBでも構わない。
> PHPでもRubyでもいいんですよ。

> 幾ら優れたことをやっても、根本的に「で？」としかならない。自分が一顧客として金を
> 出すとしたら、って考えると、欲しいのはそんな裏方の話じゃないっしょ。

これまた正論だが、日記でよく言うね。だが、あんたが自分でも気づかないフリしてる
心境は「確かに S2 は良いかもしれない。ひがが目立つのはうれしいが、俺のほうが
できる人間なのにが影に隠れてるのはくやしい。」だろ。

だいたい、客に伝わらんのはあんたの営業能力不足だろ w
古い言葉で言えば「バカの壁」だな。規模が違う話して悪いが、例えば IBM の研究所の
人間でもあんたは「方法論ばかり言ってないで少しは経営のことを考えろ」って言うか？

類稀な経営手腕を持ってんだったら、開発者に対してやる気なくすこと言わずに
気持ちよく駒として動かすことに専念すれば？くーすﾏﾝｾｰとか言ってやれば
ドーパミン全開で土木作業してくれるよ w

多少、建設的なネタを。ひが君「cglib 遅せーから Javassist 使う」とか言ってないで
直接 ASM 使えよ。まー、バイトコードライブラリ作者は使う側のスキルはアテにしてないと
思うけどな。

　性能： ASM ＞ Javassist（初心者向け）＞ cglib(初心者向けASMラッパー)
　　　　　　　＞ BCEL ＞ SERP

572:デフォルトの名無しさん
04/10/13 14:56:42
日記への反応は日記に書けば？あっちでも匿名で書けるんでしょ？

573:デフォルトの名無しさん
04/10/13 14:58:46
もしくーすがOOAなのかER分析なのかしったこっちゃないというなら俺は興味ないな。
システムの狭い世界での話であっても、OOAと構造化には明らかな壁があるのに
OOPLを導入してもその壁をうまく越えられてない人が結構いる。
くーすでクラス図もなしにバウンダリを基準に設計する(と読めたけど違う?)ものなら
壁を越えられない人たち向けには良い指針になるかもしれない。

前に使ったある外注は顧客クラスがあるにもかかわらず、
パスワード変更クラスとメールアドレス変更クラスをつくりやがった。
OOAでの1クラスが、複数のバウンダリに登場するのでバウンダリ基準はいくないと思う。

あと顧客が納得できるモノは画面イメージだけっていうのには諸手を挙げて賛同するけど、
顧客が仕様変更したがるのも画面なわけで、「やっぱり確認画面をいれたい」みたいな
変更要望に強くするためには、その後ろにあるクラス設計がいかに業務にマッチしているかが
重要になってくると思うんだけどお前らはどう思い松か？

574:デフォルトの名無しさん
04/10/13 15:37:37
別にさあ、日記に何かいてようがいいじゃん。
少なくとも、ここでどうこういう話じゃない。
プロダクトやプロモーションに関わることなら別として。

また呼び出しくらうよ？

575:570
04/10/13 15:37:50
>>573
「くーすが知ったこっちゃない」んじゃなくて、
くーすは「お客さんはそんなこと知ったこっちゃない」って
前提で考えられてるんじゃないかなーって
思ったの。

後半の、「顧客が納得できるモノは画面イメージだけって
いうのには諸手を挙げて賛同するけど」と同じでっす。

ちょっと言葉足らずでしたかすんません。

576:デフォルトの名無しさん
04/10/13 16:09:04
>「お客さんはそんなこと知ったこっちゃない」って前提で
なるほど。そうかも

その他の部分はひが氏の日記を拾い読みした記憶から勝手に脳内保管して
書いているので、見当違いだったらごめん、っていうか指摘してくだちい

577:デフォルトの名無しさん
04/10/13 19:01:57
しかしみんないろんな日記よく読んでるねえ。

みんななんだかんだいってもS2が気になってしょうがないんだね。

578:570
04/10/13 19:24:45
>>577
まさにそのとおり。からさわぎいくどー。

579:デフォルトの名無しさん
04/10/13 21:03:02
S2ってさ、ひがさん一人で開発してるんだよね？
開発者として、複数の人が参加して、互いにCheck&確認していった方が、
もっと、いい方向になると思うんだけどなぁ...
一人で開発してると...どうも、一人よがりになりそうで...

580:デフォルトの名無しさん
04/10/13 21:09:02
>>579
あれってオープンソースでやってて、独りで作っているわけじゃないでしょ？
S2Xxxって感じで他の人もやってたような…。

581:デフォルトの名無しさん
04/10/13 21:33:58
うちなーんちゅ記念ｶｷｺ

582:デフォルトの名無しさん
04/10/13 23:19:53
>> 580
コアな部分は全部１人でやってるよ。

583:デフォルトの名無しさん
04/10/13 23:43:03
S2Dao使うにはMySQLは不向きだな。

584:デフォルトの名無しさん
04/10/14 00:05:05
>>579
オープンソースの大半は最初はそんなもんじゃないの？使う人が増えて
パイが大きくなったらコントリビューターも増えるでしょ。
つかそうならないと増えないような

585:デフォルトの名無しさん
04/10/14 00:07:17
コアな部分はだいたいどんなプロダクトでもひとりでやってるもんじゃない？
コアとはいえ、全体からすれば一部分なんだし。

586:デフォルトの名無しさん
04/10/14 06:56:40
>>573
> パスワード変更クラスとメールアドレス変更クラスをつくりやがった

これの何が悪いのか。
これが適切な場合だって（むしろそのほうが）多いだろ。

587:デフォルトの名無しさん
04/10/14 06:57:10
顧客クラスにパスワード変更メソッド付けるなんてアフォとしか漏れには思えん

588:デフォルトの名無しさん
04/10/14 07:22:10
ケース倍ケースじゃん。
573のシチュエーションだと変に見えただけじゃないの？

589:デフォルトの名無しさん
04/10/14 16:25:45
顧客クラスというからには
cust.load();
cust.setPassword(pass);
cust.update();
とするだけで更新できるので、わざわざ別クラスつくる意味がまったくわからん。
顧客クラスにパスワードのバリデーションメソッドを追加するだけでいいのに。

わざわざパスワード変更用のクラスをつくってバリデーションと更新メソッドを
つくる意味を教えてくれないか？さらにメールアドレス変更クラスは
これにそっくりで、バリデーションの内容がちょっと違う(".@"が使える)のと
更新メソッドのsqlがちょびっと違うだけ。クラスの見通しも機能拡張への対応も
顧客クラスにまとめた方がはるかにいいじゃん。

是非俺にも納得できるように説明して欲しい

590:デフォルトの名無しさん
04/10/14 16:36:32
誰でも自由にクラスを作れて、
どんなクラスでもDBに自由にアクセスできて、
DBが間違いなく更新される以上なにも問題が起きない、

という無法状態を放置しているのがそもそもの間違い。

591:570
04/10/14 17:11:30
>>589
データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないかという考えもあるんですよ。
エンティティは純粋にデータとしてとらえる。
意味がないわけではないと思いますよ。

ただそれもシステム全体の規模やルールとの兼ね合いも
あると思うので、杓子定規に当てはめるのもなあとも思う。
この場合は、印象のみだけど、ちょっと煩雑かなー。

592:デフォルトの名無しさん
04/10/14 17:54:51
>無法状態を放置しているのがそもそもの間違い。

まあそりゃそうなんだが。

>データと振る舞いをカプセル化するという方向は
実は間違いなんじゃないか

ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
daoCustomer.setData(this);
dao.update(connection);
みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
使えば楽になるのかなあと思って興味を持ってるわけだけど。

で、パスワード変更やメールアドレス変更のために別クラスをつくって
似たような処理をいろんなクラスに書きまくった方が良いケースってのは
どんな場合よ？画面単位なので名前・住所・電話番号等の変更クラスは
一つにまとまってるんだろうけど。
「これらの画面を一つにまとめたい」とか「メールアドレスに対して
パスワードを送付する機能をつけたい」とかの仕様変更に対応するには
顧客クラスが汎用的に(といってもこのシステム内で、だけど)顧客情報を
管理できるクラスであることが重要じゃない？顧客検索みたいに顧客クラスの
インスタンスを複数扱う機能には、別に顧客検索クラスをつくるけどさ。

593:デフォルトの名無しさん
04/10/14 20:34:50
>>592
顧客情報と認証情報を別個に分けて管理したい時。
セキュリティのためにね。

>メールアドレスに対してパスワードを送付する機能をつけたい
顧客が希望しても、こういう仕様は止めろよ・・・

594:デフォルトの名無しさん
04/10/14 21:09:20
>顧客情報と認証情報を別個に分けて管理したい時

そのために内部の実装を分けないといけないようなケースがそんなにあるの？

>>メールアドレスに対してパスワードを送付する機能をつけたい
>顧客が希望しても、こういう仕様は止めろよ・・・

誰でもすぐ会員登録できる情報サイトなんかではこれでいいと思う。
つーか話題とずれてるけど

595:デフォルトの名無しさん
04/10/14 21:21:04
>>592
>ちなみに今ウチでは顧客クラスでDataAccess顧客クラスを参照して
>daoCustomer.setData(this);
>dao.update(connection);
>みたいな感じでDAだけ分離する方向です。小規模だとやらないけどね。Connection
>渡すのは複数のDAにまたがってトランザクション管理するためね。S2DAOとか
>使えば楽になるのかなあと思って興味を持ってるわけだけど。

S2Dao使うと、dao.update(customer);で済む。
複数のdaoでconnectionを共有するなんてのは、まさにDIの使いどころ。

596:デフォルトの名無しさん
04/10/14 21:38:20
>>591
データと振る舞いを分離するって、Customerクラスと
CustomerLogicクラスに完全に分かれるってこと？

597:デフォルトの名無しさん
04/10/14 22:00:15
>596
で、CustomerLogic を具体的な業務ロジッククラスから呼び出して使えばいいのか。

白黒あいまいな感じで作りやすいかもしれない。
OOしてると、後だしででてきた要件の扱いに悶々と悩むことあるから。

598:デフォルトの名無しさん
04/10/14 22:07:20
下手するとDRY原則やぶりなコードができそうだな。
さらにS2Dao使うと、SQLの中にロジック散らばりそうだし。

599:デフォルトの名無しさん
04/10/14 22:16:47
データとロジック分けるメリットって？

600:デフォルトの名無しさん
04/10/14 22:48:16
>>599
メリットは597が言ってる。

でもそのメリットも、システム規模、それとクラスを分けた事による利用性や
他の利便性（DIのアーキテクチャにのりやすいとか他いろいろ）と
応相談ってところじゃないかな。

なんでもかんでもOO的にエレガントだからって押し切ると
業務要件とか実装上の現実問題とかないがしろにしちゃう。
パターンはパターンで有用だけど皆頭使おうぜって所ですか。

S2やくーすが、その頭使おうぜって所を
何処まで軽減できるかってのが、楽しみなところじゃない？

601:デフォルトの名無しさん
04/10/14 22:48:26
ValueObjectに処理を持たせるという話をしてるの？

602:デフォルトの名無しさん
04/10/14 23:01:23
>599
OOだと、組み替えたり、整理したり、やっぱこの部分独立させよう、いやいやそこはそのままで、
としてるそばからお客さんに「やっぱりおしごとのやりかたかえますた」って言われてイヤ。

ロジックとデータは分けておいて、diconファイルとかで業務構造を動的に管理するために
計算資源を使ったほうが合理的かも。

603:デフォルトの名無しさん
04/10/14 23:09:27
業務構造って、えらくあいまいな言葉だな。
データストア層とドメインモデル層を分けて考えるなら、おのずとDAOが出てくるわけだが。

604:デフォルトの名無しさん
04/10/14 23:16:36
S2JSFまだぁ？

605:デフォルトの名無しさん
04/10/14 23:21:26
>> 603
ドメインモデル層をデータとロジックに分けてしまおうって言ってんじゃないの？
ファウラー氏の言う「ドメインモデル貧血症」に。

606:デフォルトの名無しさん
04/10/14 23:40:01
601ハ、ValueObjectノ意味ヲハキチガエテマス。

607:デフォルトの名無しさん
04/10/15 00:33:00
>603
設計方法論に詳しいわけじゃないんで、変なこと言ってたらすまん。
処理の方法がころころ変わるような場合の話で。

ビジネスルールをそのままソフトウェアにしちゃいたい。
静的な構造はうまい人が作らないと汚くなるし、
完成するとそれで世界が完結するから変更が大変。

だからソースコードで書く部分をビジネスルール層だけにしてしまう。
それをO/Rツールが自動化してくれるデータアクセス層に被せる。
データは「ビジネスルールが正しく実装された」ことをテストして保障。

うまくいけば楽にならないかなぁ。

608:デフォルトの名無しさん
04/10/15 00:55:06
>>607
ふつーうにS2の実装ってそんな感じじゃないの。

609:デフォルトの名無しさん
04/10/15 03:00:24
ビジネスルールがSQLに分散するんじゃね？

610:デフォルトの名無しさん
04/10/15 09:44:02
ビジネスルールって言葉が曖昧だよな

611:デフォルトの名無しさん
04/10/15 13:35:54
>>609
どーせ、SQLは山ほど書くんだから問題なし。

612:デフォルトの名無しさん
04/10/15 14:09:21
>>611
山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
SQLバリバリの人だったら、その辺問題ないのかなあ。

613:デフォルトの名無しさん
04/10/16 04:31:40
S2Ayaya を使えばあややのどこにinjectionできますか。

614:デフォルトの名無しさん
04/10/16 04:55:10
もちろん大事なところでしょう。

615:デフォルトの名無しさん
04/10/16 12:56:46
メタについてはどうよ？
実物がないからなんとも言えんが、
実装者への負担増えない？

616:デフォルトの名無しさん
04/10/16 14:25:56
>614

RejectedRuntimeExceptionが発生します。

617:デフォルトの名無しさん
04/10/16 21:29:13
>>591
>データと振る舞いをカプセル化するという方向は
>実は間違いなんじゃないかという考えもあるんですよ。
>エンティティは純粋にデータとしてとらえる。
>意味がないわけではないと思いますよ。

やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。

おまいら、以下を読んで目を覚ましてくれ。

----
ドメインモデル貧血症
URLﾘﾝｸ(capsctrl.que.jp)

このアンチパターンが根本的に怖いのは、オブジェクト指向設計の
基本概念（データと処理を一緒にする）の真逆だということです。
ドメインモデル貧血症とは、単なる手続き型設計のことなのです。
まさに、私（そしてEric）のようなオブジェクト信望者が、Smalltalkの
初期からずーーーーーっと戦ってきたもの、そのものなのです。
さらに困ったことに、貧血オブジェクト(Anemic Object) が本物の
オブジェクトだと思っているひとがたくさんいます。つまり、
オブジェクト指向設計が何たるかをまったく分かっていない
ということなんです。
----

618:デフォルトの名無しさん
04/10/16 21:50:51
そういう名前のアンチパターンがあるからといって、それが常に正しくないわけじゃないんだけどね。

619:デフォルトの名無しさん
04/10/16 21:57:31
>やめてくれ、それは「ドメインモデル貧血症」という名のアンチパターンだ。
それは、一見ドメインモデルだけどそうではない、ってやつだろう。
591のは、もっと違う考えもあっていいんじゃないか、ってことで。

617は、世の中のソフトはすべて静的モデルで書くべきだ、という考えなのか。

620:デフォルトの名無しさん
04/10/16 22:49:27
構造化は一時期までかなーり成功を収めた手法だけれど、
OOってまだそこまで大成功は収めていない手法にも関わらず、
ここまで熱烈信者が増えてるのは何故だろう…？

621:デフォルトの名無しさん
04/10/16 23:09:46
591だけど、ドメインモデル貧血症の事は知ってます。
だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
別の流れも最近よく目にします、っていう意味ですよ。

世の中ファウラーの言う事だけが有用って訳ではないでしょう？
議論の余地があるみたいですね、って話です。

大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
ってだけなのは、ちょっとお寂しいですね。
まあそのページを読むとファウラーさんは結構面白い文章を書く
おちゃめさんぽいので、半分ネタといか煽りの気もしますけど。

で、俺の立場としては、所詮DOA育ちなんで
基本的に貧血症大好き、
ただしメンテナビリティなどの事情を鑑みて、
責務割り当てるのもまぁありかなって所です。

そもそもその貧血症だのなんだの、
純血種しか許さない態度が俺は好かん。

622:デフォルトの名無しさん
04/10/17 00:13:43
> OOってまだそこまで大成功は収めていない手法にも関わらず

ぽかーん。
まるで、親にメシ食わせてもらいながら「親なんて必要ない」とほざいてる中学生みたいだな。

623:デフォルトの名無しさん
04/10/17 00:15:16
>>620
>OOってまだそこまで大成功は収めていない手法にも関わらず、

ΣΣ(ﾟдﾟlll)ｶﾞｶﾞｰﾝ!!

624:617
04/10/17 00:30:58
>>621
> 591だけど、ドメインモデル貧血症の事は知ってます。
> だけど、そういったゴリゴリオブジェクト指向マンセーな流れとは
> 別の流れも最近よく目にします、っていう意味ですよ。

寡聞にして知らないのですけど、どのへんで見たのか教えていただけませんか?

> 大体貧血症が怖い理由が、オブジェクト指向の基本概念と真逆だから
> ってだけなのは、ちょっとお寂しいですね。

いや、

ファ> ドメインモデル貧血症問題の本質は、ドメインモデルのベネフィットを何も得ず、
ファ> コストだけをすべて被ってしまうという点です。

とも仰ってます。
もちろん「ドメインモデルなんて使わないで TransactionScript一本」っていうプロジェクトであれば、
ドメインモデル貧血症に該当してもなんの問題もないとは思いますけど。

> そもそもその貧血症だのなんだの、
> 純血種しか許さない態度が俺は好かん。

これはそうですな。反省してます。

625:617
04/10/17 00:39:55
>>612
> >>611
> 山ほど書く中に分散したり、２重になったりがまずいんじゃ。。
> SQLバリバリの人だったら、その辺問題ないのかなあ。

SQLバリバリだろうがなかろうが問題ありありだと思うよ。DRY原則に反してるわけだから。
# DRY原則は数あるソフトウェアの原則の中でも、最も尊ぶべき原則だと思うなぁ

626:デフォルトの名無しさん
04/10/17 01:50:08
DIともseasarとも関係ない話が続いてるけどなんか面白いな。
混ざってみよう。

これがすばり貧血症にあたるかわからないけど
URLﾘﾝｸ(www.relaxer.org)
エンティティの管理クラスが軒並み外出しになってる。どう？
はぶ氏も日記で「エンティティはDBのテーブル」と位置づけてたと思った。
意図的な極論なのかも知れないが、態度は貧血に近いと思う。

あとファウラーさんも「これはずいぶん昔からあるアンチパターンのひとつですが、
今になって台頭してきているようです。」って書いてるくらいだから
やっぱり貧血派は増えてるんではないすかね。

でもそんな違いは誤差だとかってまた言われそうだ。

627:デフォルトの名無しさん
04/10/17 02:07:30
あ、そうか、エンティティがDBのテーブルって事なら
ファウラーの言う所の「コスト」はかかってないって事か。
それにDTOと所謂ドメインモデルを合わせた
バリュー・オブジェクトって事も言ってますね。
ああ恥ずかしい。

628:デフォルトの名無しさん
04/10/17 02:25:12
まあ、DI、Seasar、くーすの流れだから、関係なくはないかな。

業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
前提に、ICONIXやくーすってあると思う。

浅海氏のページ見たけど、要求分析から実装まで通して示してあって
いいね。とてもいい。
実装見ると、リファクタリングしたい（やっぱエンティティにもっとロジック
追加したい）って思うけど、上に書いた考えでいくと、酷い訳ではないし、
これっくらいが現実的なOOとのつきあい方かもしれん。

VB + OCXが割と正解だったってことかな。

629:デフォルトの名無しさん
04/10/17 03:37:46
626のサイト、とても勉強になりました。
ICONIXを基に、より包括的なプロセスになってる。
くーすは、ICONIXから無くしてもいいんじゃないかという部分を省いた、
軽いプロセスを目指してるんですね。ただ、常人には難しそう。
Relaxerプロセスを一通り実践して、カスタマイズしていくのが一番良さそうです。
Relaxer自体はどうだろう。自動生成のデータベースアクセスは重たそうだったけど。

完全にスレ違いになってしまいました。

630:デフォルトの名無しさん
04/10/17 09:05:34
>>629
どこが、常人に難しそうなの。

631:デフォルトの名無しさん
04/10/17 10:40:20
最近は、ドメインモデリングより、振る舞いのモデリングに
シフトしつつあると思う。

ドメインモデルはER分析した結果を使う。
(Entityとテーブルはほとんど同じ)
画面は、欲しい形でDTOとして受け取る。

DTOなので振る舞いを持たない。
DTOとEntityの相互変換をおこなうのは、
コストがかかるので、業務ロジック層や
データアクセス層で直接DTOを処理する。

これがくーすの考え方なんだと思う。

それを支えているのがS2Daoで、ほとんどコストをかけずに
DTOを処理できるようになっている。

632:デフォルトの名無しさん
04/10/17 11:06:45
> DTOとEntityの相互変換をおこなうのは、
> コストがかかるので、業務ロジック層や
> データアクセス層で直接DTOを処理する。

これは大きな間違いだと考える。
そのコストはオプショナルなコストではなく、必須のコスト。
必須のコストを減らす目的で他のマッピングツールを作ったほうがいい。
(DTO <-> Entity(≒ドメインモデル) を相互変換するような)

633:デフォルトの名無しさん
04/10/17 11:19:55
>>632
必須であるわけは。
業務ロジックは、画面のためにあるんだから、
画面に適したDTOを扱うのは自然だと思うけど。

634:デフォルトの名無しさん
04/10/17 11:33:13
システムを層に分ける。
データストレージ―(1)―ビジネスロジック―(2)―プレゼンテーション

ここを流れるデータを分類する。
(1)は DTO<->ドメインモデル
(2)はドメインモデル->View用モデル(左から右のみ)

ドメインモデルをDTOと同じ構造にすることができるのは、
データストレージ層を新規に設ける場合のみ。
DBスキーマを新規にゼロから構築するケースがどのくらいあるだろうか。
ほとんどないのが実情だ。

ドメインモデルとDTOを一緒にしたいという方向から考えると、上記モデルとは矛盾する。
俺は上記モデルから考えるからこそ、ドメインモデルとDTOは一致しないという立場にたつ。

実際、(1)と(2)で別クラス(実際には別インタフェース)を作ってから実装させたことがある。
DB操作、ビジネスロジック、プレゼンテーションを綺麗に作業分担させられたよ。

635:デフォルトの名無しさん
04/10/17 11:44:16
>>628
> 業務アプリ作ってる人全員が、上手いことOOで作ることは無理っていう
> 前提に、ICONIXやくーすってあると思う。

くーすはそうかもしらんが、ICONIXはそんなこと言ってないと思うんだが?
Use Case Driven Object Modeling with UML(ユースケース入門)で読んだ知識しかないんだけどさ。

636:デフォルトの名無しさん
04/10/17 12:04:21
>>634
ドメインモデルとDTOは、もともと一致するものじゃないと思うけど、
コストをかけても良いなら、
テーブル<->ドメインモデル<->View用のモデル(ViewHelper)
を相互変換しても良い。

きれいな設計というのはものすごくあいまいな言葉で、
自己満足にすぎない可能性もある。

内部スキーマ、概念スキーマ、外部スキーマの考え方は、
昔からあるけど、各スキーマの構造のミスマッチを解消するための
コストがかかるから、実際にはあまり使われていない。

637:デフォルトの名無しさん
04/10/17 15:42:09
まず前提。Domain ObjectとDTOの相互変換はめんどくさい。

FowlerのPofEAAのService Layerの説明のところに確か
「DTO変換のコストを過小評価するな。オブジェクトのツリーが
深くなるとすげー辛い」みたいなことが書いてあったはずだ
(いま本が手許にないので正確な表現はわからん)。

俺も「Presentation層のコントローラ(この時はStrutsのAction)は
Service Layerを介してDTOを受け取り、Domain Objectには絶対
直接触らない」ってポリシーで設計したけど結局実装とテストが
やたらしんどくなって方針転換したことがある。

んで、DTO変換をしないとなると、Domain Object側に巻き込むか、
DTO側に巻き込むかという二者択一となる。最近のひが氏は後者に
転んでいる模様。

# URLﾘﾝｸ(d.hatena.ne.jp) とか

ちなみに俺の上記のケースは細粒度のDomain Objectのトランザクション間
かつコントローラ間のロングキャッシュが非常に重要なドメインだったので
前者を選択したよ。

# ひが氏はロングキャッシュは知らんとか言ってるけど。
# URLﾘﾝｸ(d.hatena.ne.jp)

638:デフォルトの名無しさん
04/10/17 16:43:55
>>633
業務ロジックは画面のためにある、というのは違うでしょ。
画面の目的は２つ。
　・業務ロジックを起動するための情報を収集する(=入力画面)
　・業務モデルに関する情報を提示する(=参照画面)

639:デフォルトの名無しさん
04/10/17 17:35:07
>>637
よくわかる説明だけど、わかるやつにしかわからんってなってるかも。

640:デフォルトの名無しさん
04/10/17 18:18:33
>>638
それ、なにが嬉しいの？業務ロジックのために人は画面に情報を入力するの？

業務ロジックが画面のためにあるというのは違うと思うけど。
あくまで、印刷とか、ファイル転送とか画面をIFとしない業務ロジックもあると思うから。
>>633
こっちの方が正しいんじゃない？

641:デフォルトの名無しさん
04/10/17 18:49:29
>>640
>>638の1行目を穴が開くまで読むべし。

642:デフォルトの名無しさん
04/10/17 18:56:47
>>641
穴があいたら、次はどうすればいいですか？

643:デフォルトの名無しさん
04/10/17 19:01:05
>>642
入るしかないでしょ。

644:デフォルトの名無しさん
04/10/17 19:52:07
入れるしかないよ。

645:デフォルトの名無しさん
04/10/17 20:19:25
入れるから穴があくんだろ。逆転してるぞ。

646:デフォルトの名無しさん
04/10/17 23:33:54
はぶ氏の長文は、リファクタリング前のコードと同じ臭いがする。

647:デフォルトの名無しさん
04/10/17 23:59:45
俺らは研究者じゃなく、売り物を売ってんだから、新しかろうと古かろうと
コストが低く品質のいいソフトが作れる技術を選べってことだろう。
構造化もOOも上記を実現するためのものの筈だ。
清く正しいOOに固執するあまり、逆に生産性を下げて
しまってるのはマズいな。

ER分析と構造化手法に上手くOOのおいしいとこだけ取り込んでっていう
くーす的なやりかたが「今の時点」の正解だと思う。カスタマイズは自分らの
貯蓄に合わせてすればいい。
で、正しいOOの負の部分が解消されるようになれば（OODBの性能があがって安くなるとか）
すれば、それを使えばいい。

DIやAOP、ORMに関しても、効果と新しいコストとのバランスが重要で、
その点がS2が優れてるんだな。
ということで、Seasar2マンセー！S2Daoマンセー！S2JSFも（多分）マンセー！

648:デフォルトの名無しさん
04/10/18 00:09:33
まったく同意。本当、からさわぎ楽しみ。

でも仕事の頭からちょっと離れると、
やっぱファウラーの文章とか読むとワクワクするんだよね。
そんな自分も居るのが判ってるんで、ちょっと悔しいというか
さみしいというか。
だから617の気持ちも判るんだよなー。

649:デフォルトの名無しさん
04/10/18 00:10:53
リファクタリングして説教して来いｗ
みんなが>>646に期待してるぞ

650:647
04/10/18 00:30:39
>>648
>やっぱファウラーの文章とか読むとワクワクするんだよね。

その辺は先行投資だね。
関数型言語や形式仕様なんかも、そのままの形で仕事に使えないかもしれないが、
懐を広げておくのは開発者として重要だと思う。
ただ、いつの間にかその学習コストを客に押し付ける格好で、実案件に適用しようと
考えてしまう。
「この技術を使っています。だからこれだけ値段が上がります。」ってのは通用しない。
「この機能がこれだけ安く実現されます。」「この作業がこれだけ軽減されます。」
これを末端開発者も忘れないように気をつけたいね。

651:デフォルトの名無しさん
04/10/18 00:45:33
>650
ありがとう、なんか気が楽になりましたよ。

気が楽ってのは、けして安くない本を
会社の金でパカパカ買って乱読しちゃった
罪の意識が楽になった、って事だけど（w

652:デフォルトの名無しさん
04/10/18 00:47:45
まあ、スレ違いかもしれんが、こういった話無しにS2の良し悪しは語れんからな。

653:デフォルトの名無しさん
04/10/18 00:59:42
書籍代なんて誤差の範囲だよ。

プププ

654:デフォルトの名無しさん
04/10/18 02:34:48
結局、はぶさんは TransactionScriptでいーじゃんか、ってことか。
くーすもTransactionScriptをベースとしてんの?

655:デフォルトの名無しさん
04/10/18 02:46:23
>. 654
TransactionScriptだろうとMDAだろうと、今使えて、生産性向上とコストダウンを
実現できるやりかたでやるということだろ。客の利益になる物を作って、お金を頂いて
生活してることを忘れるな。

って、所詮2chか。S2にもフォーラムが欲しいな。

656:デフォルトの名無しさん
04/10/18 04:21:56
>>655
みんな各自のblogで満足してるから、実現性は低いね。

657:デフォルトの名無しさん
04/10/18 07:58:24
>>637
ドメインオブジェクトにViewHelper的な要素を
持たせるということなら反対。

むきだしのドメインオブジェクトなら、画面では激しく使いづらい。

658:デフォルトの名無しさん
04/10/18 09:28:58
>>655MLじゃ駄目なの？

659:デフォルトの名無しさん
04/10/18 15:53:43
>655
コイツはなに当たり前のこと偉そうに言ってるんだ？
生産性とコストダウンに加えて拡張性とメンテナンス性も向上させるのに
OOの中でもどういう手法をとったら効率がいいのか話あってるんだろ？

はぶか？

660:デフォルトの名無しさん
04/10/18 16:07:11
「客だよ、客！」
「利益なんだよ、利益！」
「コストダウンっつたらコストダウン！」

文脈を無視してこれしか言わないのはハブだろ。
じゃなければハブのクローンか。

661:659
04/10/18 16:08:44
どちらにしろ匿名で言い合っている中で人物名だす必要はなかったな。
あやまっときます。すんません

662:デフォルトの名無しさん
04/10/18 18:00:26
じゃあこれからは人物名「はぶ」ではなく機器名「Hub」ってことで。

663:デフォルトの名無しさん
04/10/18 18:56:32
納期とか予算とかがまずあって、手法はそのあと、とかそういう考え方って、サービス残業しろ、間に合わなければやっつけで、っていう考えにたどりつきがちだけどね。
ソフトウェアの開発は気合でうまくいくものではないと思うんだけど。
「客優先」「利益」「コストダウン」って、サービス残業させるための「魔法の合言葉」だね。
「やればできる。」
長期的に品質(含納期・予算)を確保するためには手法が必要だと思うんだよね。
手法にもてあそばれるのは良くないけど。

664:デフォルトの名無しさん
04/10/18 19:08:31
> 客の利益になる物を作って、お金を頂いて生活してることを忘れるな。

という考え方も、古いね。
サービスの対価としてお金もらってるんだから。主従関係ではないよ。
金額にみあったサービスを提供できればそれでいい。
それができないのは問題だけどな。

665:デフォルトの名無しさん
04/10/18 19:14:28
>>663
それははぶについてでなくて一般論だよね？

はぶは手法としてはくーすカスタムなわけで
サービス残業うんぬんの負荷の軽減を
言ってるわけで。

ほっときゃ本人があっちに書くか。楽しみにしていよう。

666:デフォルトの名無しさん
04/10/18 19:18:17
今の流れって前向きなの？ム板ですべき話なのかな？
技術のギの字も出さずにただ現場の話がしたいだけなら
マ板いけば？

って、所詮2chかｗ

667:デフォルトの名無しさん
04/10/18 19:34:01
俺はそんなにスレ・板違いにも思えないんだな。

S2からくーすにつながる中で
やっぱり現場の話は、どうしても出るよ。
それだけ実践的なものって事なんでしょう。

ムだのマだのでがっつり分けたがる方が
所詮2ch。

668:デフォルトの名無しさん
04/10/18 20:02:15
>>666
前向きもうしろ向きもなく、雑談。

669:デフォルトの名無しさん
04/10/18 20:03:18
マ板は、ネタスレ用隔離板ですよ。

670:デフォルトの名無しさん
04/10/18 20:04:47
現場の話が技術の話だと思わないあなたはピープルウェアでも読んでください。

671:デフォルトの名無しさん
04/10/18 22:29:15
ｽﾙｰしる

672:デフォルトの名無しさん
04/10/18 22:45:41
そんなことよりも S2JSF だよ。
まだでねーのかよ！
S2Flex とかどーでもいいからはやく S2JSF リリースして栗

673:デフォルトの名無しさん
04/10/18 23:39:08

OpenSymphony QuartzのJobにDIしたいと考えてるんだけど、タイミングが
つかめない。Jobインスタンスは実行ごとに生成されてそうだから、JobRunShell
でnewInstance()するごとにDIせねばならん。
Tapestryもそうだけど、元のライブラリがDIを考慮した設計になってないと
きついな。

674:デフォルトの名無しさん
04/10/19 02:32:25
はぶさんも、いちいち相手にしなけりゃいいのに。
「伝染るんです」のスズメみたいなもんなのにね。

675:デフォルトの名無しさん
04/10/19 03:31:31
おお、すずめかあ。懐かしいなあ。

でもピンポンダッシュっぽい感じもするので
「こらー！」ってゆってくれないとちょっと寂しい。

676:デフォルトの名無しさん
04/10/19 03:50:38
いやー、言いたいことをおもしろおかしく、語弊と誤解とあらぬ疑いをまじえながら、勝手に書き込んでるだけなんだよね。
2chってところは。

で、怒られたら逃げる。でもやっぱり離れたところでこそこそやる。
怒られなかったらそれはそれでちょっと寂しい。

677:デフォルトの名無しさん
04/10/19 13:18:16
>673
そうだね。一応outer定義してinjectDependencyという手段はあるけど、
メリットのあらかたを享受できないからね。
DIを考慮した設計でなくてもいいけど、生成部分の自由度が低いと辛い。

678:デフォルトの名無しさん
04/10/19 20:57:03
業務アプリケーションをそんなに急いで作りたいなら、一番確実な方法としては
「あらかじめ作る」しか無い。

つまり、業務アプリでEclipseみたいにプラグインで拡張可能なソフトを作ることだと思うよ。
（この設計は極めて難しいものになるだろうけど。）

679:デフォルトの名無しさん
04/10/19 20:59:44
業務アプリとはいえ、プラグインプログラミングをやらうとするなら、
ソース公開されていることは必須条件。別にGPLじゃなきゃだめというわけじゃないけど。
（ソース読まずにプラグインだけ作ることは無理だ）

680:デフォルトの名無しさん
04/10/19 21:23:49
>>678
StrutsやらHibernateやらいろいろ抽象化してくれるものと、DI+AOPのおかげで、極めて難しいというほどではないとおもう。
規模やら分野によるだろうけど。

681:デフォルトの名無しさん
04/10/19 23:15:00
この中の何人くらいがちょっとS2さわってみたとかではなく、
実案件でS2を適用し、かつ無事にリリースできているのでしょうか？

682:デフォルトの名無しさん
04/10/19 23:31:44
3.14人くらい？

683:デフォルトの名無しさん
04/10/20 00:10:39
S2というか、そもそもJavaで実装すること自体やめたほうがいい

684:デフォルトの名無しさん
04/10/20 01:06:05
なんで？

685:デフォルトの名無しさん
04/10/20 01:27:24
Jobの抽象クラスを作って、実行前にSingletonS2ContainerFactory.getContainer()
を呼ぶか。

686:デフォルトの名無しさん
04/10/20 01:29:31
S2コミュニティって、コアのおっさんたちは確信犯だろうから別にいいんだが、
周辺の若手マンセー君たちがイタイ。

何で「くーす=現場密着使える」「それ以外のOO方法論=机上空論使えねー」
って2分割の構図で思考停止できちゃうのかわからん。

# 逆説的に、2年前くらい前に「Togetherでラウンドトリップ」とか「永続化は
# EJB2.0CMPで決まり」とか「Struts最高」とか「Taglib凄い」とか言って
# 懐疑派を時代遅れの馬鹿扱いしてたやつらと同じ罠にはまってる気がする。

くーすは、素人だらけの現場でいかに一定の品質をキープするかという点
(予測可能性?)にフォーカスした、いわば極めて後ろ向きな方法論であって、
決して根本的な工数の削減やメンテナビリティにはフォーカスしていないと思う。
Transaction Scriptの欠点は単価安い下っ端ブルートフォース(+中国?)で
カバー、的な。

687:デフォルトの名無しさん
04/10/20 01:41:00
スレの流れとは関係ないが、なぜか同じ穴のムジナという言葉を思い出しちゃったな。

688:デフォルトの名無しさん
04/10/20 02:04:06
S2Daoに要望
・挿入時にAuto Incrementフィールドを
オブジェクトのプロパティで更新しないようにしてほしい。
・数値とbooleanの変換をして欲しい。
・countXXX(), sumXXX()なんかの集計関数の自動生成が欲しい。
・テーブル名、エイリアス名は`なんかで囲って欲しい。
・getLastInsertId()欲しい。

所詮２chなんで、さらっと無視して下さい。
S2JSF期待してます。
どうぞご自愛ください。

689:デフォルトの名無しさん
04/10/20 06:33:55
>「それ以外のOO方法論=机上空論使えねー」
ってあったっけ？
誰が若手やらわからんので俺が見てないだけかもしれんが。

690:デフォルトの名無しさん
04/10/20 06:39:58
>>686
TransactionScriptが
ロジックの共有化をはかると構造が複雑になる
と述べている理由を述べよ。

なんか、大きい仕事を任せてもらいない人が
思い込みで語っているような。

あなたにまかされたプロジェクトが、いかに効率的
なのか説明してみよ。

691:デフォルトの名無しさん
04/10/20 09:19:09
S2Quartz!!!
URLﾘﾝｸ(d.hatena.ne.jp)

692:太田＠会社
04/10/20 12:05:09
686さん>
「若手マンセー君」はWithout EJBの勉強会に参加して見回した限りは
(本当はRUP推進派の)僕も含めて存在しないです。僕自身の立場としては
限られたりソース内での最大限の効果を望む社内のDOA(Data Oriented
Approach)な人にも使っていただけ，単体テストが効率化する「くーす」と
Seasar2(および周辺プロダクト)を応援しているというだけで，マンセー
ってわけではないです。理想は，でも現実的には，だったらどうしたらよい
という前向きな人たちの集まりだと思うのだけど。そうじゃなかったら休日の
半日つぶして勉強会に集まったりしませんよ。

693:デフォルトの名無しさん
04/10/20 13:08:35
>>686
>2分割の構図で思考停止できちゃうのかわからん。
思考停止しているのは、あ・な・た☆

694:デフォルトの名無しさん
04/10/20 19:20:59
比嘉氏・取り巻き・羽生氏ときて今度は若手か。
徹底的に人に絡んでくるな。

695:デフォルトの名無しさん
04/10/20 19:25:28
つうか、取り巻きって誰かが明示されてないし。

イタい取り巻きの例示きぼん>>686

696:デフォルトの名無しさん
04/10/20 19:26:14
s/取り巻き/若手

697:デフォルトの名無しさん
04/10/20 19:34:42
んなこといいけど、S2JSFって進んでるのかな？
なんか、S2FlexとかS2.1とかくーす本とかで忙しいみたいだからねえ。
S2JSFのためにS2のバージョンアップが必要なのだろうか？

698:デフォルトの名無しさん
04/10/20 19:48:08
S2JSFのためのS2.1化だろ。

699:697
04/10/20 19:49:30
う～～待ちきれない

700:デフォルトの名無しさん
04/10/20 20:04:00
そこでJSF-Springですよ

701:デフォルトの名無しさん
04/10/20 20:30:58
>>695
やめれ。これ以上個人名を出す必要はないよ。
比嘉氏や羽生氏はともかく他の人は関係ない。

702:デフォルトの名無しさん
04/10/20 23:09:40
ひがさんやはぶさんの名前を出す必要もないけどな
S2の話題でﾏﾀｰﾘやろうや。からさわぎ楽しみ。

703:デフォルトの名無しさん
04/10/20 23:12:53
やっぱりからさわぎはくーすのトラックが人気なのかな？
俺もデザイントラックにしようかと思ったんだけど
くーすは本が出るからそっち読むとして
今回はビジネストラックにしようかなとも思って。
マジカ面白かったし。

704:デフォルトの名無しさん
04/10/21 00:08:30
S2JSF いつ頃だろうか。
前のプロジェクト、プレゼンテーション層までSpring使うんじゃなかった orz

705:デフォルトの名無しさん
04/10/21 00:11:39
>>704は>>700に助けてもらえ

次ページ