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

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 05/09 16:10 / Filesize : 285 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

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/
792 名前：デフォルトの名無しさん mailto:sage [04/10/23 13:34:02]: >>791
それなら、それでいいんじゃないですか。
うまくいってるなら、特に変える必要はないと思います。

でも、ダミーの実装を作って、取り替えてなんて、
やるのは、大変そうですけどね。

あとから、実装が何だかおかしいから、ダミーに戻して
確認するってのも大変。

ちゃんとバージョン管理しているなら、ダミーと実装の
管理がすごく複雑になる気がします。
793 名前：デフォルトの名無しさん mailto:sage [04/10/23 13:57:33]: まさか、自動テストの一括実行をやってないとか。
794 名前：785 mailto:sage [04/10/23 14:32:12]: >>792
ダミーの実装はバージョン管理に追加しないですね。
中身の無いクラスだけコミットしてもらって、ダミーの
実装は各自勝手にといった感じ。中身が出来たら更新。

その点seasarはダイコンファイルで複数のダミーパタンを用意して
それを取っておけるのが良いですね。

>あとから、実装が何だかおかしいから、ダミーに戻して
>確認するってのも大変。
実装が出来上がっちゃったら、ダミーに戻すことは無いですね。
おかしいなって思ったら、大抵他人のコードでもデバック
しちゃいます（修正はしないで、原因だけ伝えるかな）。

上の方で言ってるくーすの話は面白いですね。seasar大して使ってないけど
設計論なんで、関係ないし。
ただ、貧血症とか、DAOにビジネスロジックとかって答えがあれば聞きたいけど
答えなんかないんだよね。漏れ的には、迷ったらメンバーで相談する。
SQLでやった方が楽で、早いならSQLでゴリゴリって書いて、ドキュメントなり
分かる形で残す。ViewとDAOのデータの受け渡しはBeanUtilsマンセー。
795 名前：デフォルトの名無しさん mailto:sage [04/10/23 14:38:34]: >自動テストの一括実行をやってないとか。
それってseasarと関係なくない？
seasar使ってないとJUnitで一括実行出来ないとでも？
796 名前：デフォルトの名無しさん mailto:sage [04/10/23 16:59:16]: デバックってゆうな～
797 名前：デフォルトの名無しさん mailto:sage [04/10/23 18:00:15]: >おかしいなって思ったら、大抵他人のコードでもデバック
切り分けにはモックを使う方が便利。モックの造りにもよるけど。

モックは単純実装になってるはずなんで、モックが仕様通りなら
他人のところがおかしい可能性大。
モックが間違っているならモックを直して再テスト。

ちなみにdebugなんでデバッ"グ"
798 名前：デフォルトの名無しさん mailto:sage [04/10/23 18:24:12]: OSSに対する直接的な貢献というのは、狭義にはソースコードの提供である。
通常は元となるソースに対しての差分をパッチという形で提供することになる。
そのパッチをメンテナと呼ばれるコアな開発者にメールなどで送りつける事が狭義の貢献である。
メンテナはそのパッチをみてよければ採用しよくなければ採用しない。
良い悪いというのはどうやって判断するのか？オープンソースの七不思議である。
ある人のパッチは受け入れられてある人のパッチは受け入れられない。
ある種の経験則はもちろんあるがその経験則を厳密に記述する事は難しい。
商用ソフトウェアの場合はコードの変更は担当者が行うので受け入れるも受け入れないもなくて
各社の社内規約に従って淡々とコードが追加されていく。
オープンソースの場合その明文化された「社内規約」に相当するものがないので、
ある種の秘密クラブの掟みたいな空気によって様々な意志決定がなされる。

新参者は空気を読め、空気をという話である。
799 名前：785 mailto:sage [04/10/23 18:58:14]: デバッグですね。お恥ずかしい。。。

>切り分けにはモックを使う方が便利。
これは同意です。ただ、相応の手間が漏れには受け入れられないなと。

逆に他人のコードをデバッグして得られる事も多いです。
ただ、開発フェース外での他人のコードをデバッグするような事は
勘弁ですが（ｱﾊ　
800 名前：デフォルトの名無しさん mailto:sage [04/10/23 19:10:45]: >>798
何のコピペ？
801 名前：デフォルトの名無しさん mailto:sage [04/10/23 19:36:39]: はぶ氏もひが氏もここの話題に反応してくれてますな

っと、話ふり逃げに思われると残念なので書いとこう
802 名前：デフォルトの名無しさん mailto:sage [04/10/23 21:45:01]: >>800
これだろうな。
ttp://d.hatena.ne.jp/hyoshiok/20041022
803 名前：デフォルトの名無しさん mailto:sage [04/10/23 22:08:24]: ttp://d.hatena.ne.jp/akon/20041023#p2

こんな未来は嫌だ。
804 名前：デフォルトの名無しさん [04/10/23 23:03:29]: どう作業分担するかで悩んでるらしいけど、
参考になるのはEclipseだと思うよ。Javaで作られた唯一役に立つソフトウェアだ。
これの開発方針を見れ。
805 名前：デフォルトの名無しさん [04/10/23 23:05:49]: > Stateless BusinessLogicパターンのメリット
> ttp://d.hatena.ne.jp/higayasuo/20040805#1091664617

上記サイトの内容で疑問点がありまして。

ひがさんは

「Statelessにするとメソッド間の依存関係を0にできる。
あるメソッドの呼び出しが、別のメソッドに影響を与えることはない。」

と仰っています。

ここでいう「メソッド間に依存関係がある」というのは、
あるメソッド(以下 Ma)と別のメソッド(以下 Mb)が共に、あるステート(以下 S)に
依存しているということに他ならない。

このステートSをクラスの外に出したところで、Maと Mbが Sに依存していることには変わりない、
つまり Maと Mbは間の依存関係を0にできていないと思うんだけど。
806 名前：デフォルトの名無しさん [04/10/23 23:27:38]: >>805
だいたいゼロってことで、それでいいじゃん。
そんなん深く考えてもしょうがない。
807 名前：785 mailto:sage [04/10/23 23:35:51]: >>805
ステートSがオブジェクト変数だとMaかMbからのみ変更される
って事だからだと思うよ。
ステートSをクラスの外に出すと、MaやMbはステートSに依存
はするけれど、MaとMbの依存関係は無くなるんだね。

よって、MaのテストはステートSの取りうるパターンのテストを
考えれば良いと。Mbがさらに何かに依存しているとテストパターン
が依存度倍になると。

でもステートSを隠蔽することがオブジェクト指向じゃんって思うけど
ここが、Blogに書いてあるように業務ロジックの変更頻度との兼ね合い
なんだろうね。
808 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:44:01]: statelessって「実装に依存しない」って意味なんじゃないですか？

依存関係はインターフェイスで全て捉えるって意味だと。
違ったのかな。

stateless
【形-1】国［国籍｛こくせき｝・市民権｛しみんけん｝・国家統治権｛こっかとうちけん｝］のない
【形-2】《コ》処理状態｛しょりじょうたい｝を把握｛はあく｝しない～◆【対】stateful

って辞書にあるそのまんまの意味だとばっかり思ってました。
809 名前：デフォルトの名無しさん [04/10/23 23:48:50]: d.hatena.ne.jp/higayasuo/20040805#1091664617
810 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:51:34]: >>808
HTTPはステートレスってことは、実装に依存しないって意味なのか？

> 処理状態｛しょりじょうたい｝を把握｛はあく｝しない

そのままじゃないか。
どこにも「実装に依存しない」とは書いてないぞ
811 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:52:33]: >>808
かなり根本から間違ってるな。State が lessなんだぞ。
812 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:57:32]: >>808
SLSB/SFSBの違いを思い出せ。
813 名前：デフォルトの名無しさん mailto:sage [04/10/23 23:58:14]: オブジェクトが状態をもたない。
814 名前：デフォルトの名無しさん [04/10/23 23:59:14]: class Foo {
int s;
int method(int x);
}
があったとして、method(x)っていう呼び出しの結果がxの値だけじゃなく
sの値にも依存すればstatefulで、
xの値のみに依存すればstatelessなんじゃね？

だから
＞Statelessといっても、すべてスタティックメソッドにすれば良いという
っていうことになるんだと思ったけど
815 名前：デフォルトの名無しさん [04/10/24 00:01:29]: >>814
statelessでもポリモフィズムは使いたい。
816 名前：デフォルトの名無しさん [04/10/24 00:03:16]: >>814
>すべてスタティックメソッドにすれば良いという

ポリモーフィズムが使えるところが違うっていうところだな。
システムをプラグイン的に拡張していけるっていうのがありがたいんだろう。
これやるとプログラマのシステムの意図の理解に役に立つし。
817 名前：805 [04/10/24 00:07:34]: >>807
> >>805
> ステートSがオブジェクト変数だとMaかMbからのみ変更される
> って事だからだと思うよ。
> ステートSをクラスの外に出すと、MaやMbはステートSに依存
> はするけれど、MaとMbの依存関係は無くなるんだね。

そうかな?

「MaとMbが依存関係とみなされている理由は、ステートSに依存するから」
なら
「クラスの外に出したステートSに依存するメソッドは全て依存関係にある」
と言えると思うんだよね。
818 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:09:28]: >>804
ポインタ希望
819 名前：785 mailto:sage [04/10/24 00:33:53]: >>817
じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
いないのに、MbはMaに依存しているっているって言える？
あくまでステートSに依存しているだけだよね。

あとは、ステートSの場所についてだけどこれは　>>813
って事だね。
820 名前：805 [04/10/24 00:37:11]: メソッドの処理がステートに依存するクラスの例として
以下のクラスがあったとする。

class File
void open();
void close();
int read();
}

これが以下のようにStatelessになったところで
open、close、readの依存関係がなくなったとは言えないと思うんだよね。
例が悪いのかな?

class File {
void open(FileState state);
void close(FileState state);
int read(FileState state);
}
821 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:37]: だからステートって具体的なメンバ変数だの
それをクラスにして外に出すって事じゃないでしょ。

810の言う通りHTTPがステートレスというのと同じで
「状態を持たない」って事だと思って読んでたけど。

状態を持たないだと判りにくいか、
状態の変化を管理しない。

S2コンテナの考え方は、オブジェクト間の関連は
インターフェイス同士の関連だけ定義して
実装はdiconまかせでしょ、どんな実装をされるかが
オブジェクトにとって「状態の変化」でしょ、
だから、オブジェクトは「状態を持たない」
って思って読んでたよ。

結果的に「実装に依存しない」ってのは、
割と外れちゃいない気がする。
822 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:47:53]: ひがさんのblogで例に挙がっている、手数料計算なんかだと
ドメインモデルではStrategy/Stateパターンになるよね。
そうすると、
aModel.手数料計算()メソッドは、aModel.set手数料計算方法()に依存する。

この計算方法は各業務に付随するものなので、業務ロジッククラスのメソッドで
あるべき。aLogic.手数料計算(anEntity)の方が、自然だとは思う。
823 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:50:36]: ああでもよくわかんねぇ
824 名前：デフォルトの名無しさん [04/10/24 00:50:40]: class File {
static int read(String filename, int position);
}
これは？
825 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:52:15]: なんか俺も混乱してきたのでひがさんきぼんぬ
826 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:09]: ここへ来て基本的な知識不足が露呈したなあ。
ああ自分が恥ずかしい。

あ、821=823です、
まぎらわしくなっちゃってすみません>822
827 名前：デフォルトの名無しさん mailto:sage [04/10/24 00:54:10]: >>820
オブジェクトをステートレスにしろって事じゃないの？

下の例だとＦｉｌｅＳｔａｔｅオブジェクトさえ作れば、
readメソッドのテストにopenメソッドは必要ない（場合がおおくなる）よね。

上の例だと、クラスにFileStateオブジェクトを持ってるって前提で、
readメソッドのテストにはopenメソッドが必要ってことになるよね。
828 名前：785 mailto:sage [04/10/24 00:58:40]: >>820
何に対して、誰から見るとStatelessなのか、Statefullなのか
って事だよー。
上のFileクラスは、使う側から見るとopen、close、readのメソッドが
Statefullなんだけど、下のFileクラスは、引数のstateに対して
statefullであって、open、close、readの関係はStatelessだよ。

ようは、stateだけ考えてれば、良いって事。

ん？漏れはコアなseasar利用者じゃないんだが。。。
モンキーターン見てくる
829 名前：805 [04/10/24 01:00:19]: >>819
> >>817
> じゃあMcってメソッドを追加してこれもステートSに依存するとしよう。
> Mcをコールした後にMbをコールした場合、Maは一度も呼び出されて
> いないのに、MbはMaに依存しているっているって言える？
> あくまでステートSに依存しているだけだよね。

今思ったんだけど、Maと Mbは依存関係にある、という認識が間違いなんじゃないかな。
Maと MbはステートSとのみ依存関係にあって、互いの依存関係なんてものは最初からない、と。

へんなこと言ってるかな?

> あとは、ステートSの場所についてだけどこれは　>>813
> って事だね。

そうです。
830 名前：805 mailto:sage [04/10/24 01:05:18]: >>828
> >>820
> 何に対して、誰から見るとStatelessなのか、Statefullなのか
> って事だよー。
> 上のFileクラスは、使う側から見るとopen、close、readのメソッドが
> Statefullなんだけど、下のFileクラスは、引数のstateに対して
> statefullであって、open、close、readの関係はStatelessだよ。
>
> ようは、stateだけ考えてれば、良いって事。
>
> ん？漏れはコアなseasar利用者じゃないんだが。。。
> モンキーターン見てくる

混乱させてごめんなさい。
レスは、今日はもう寝ちゃうので、また明日以降に。
831 名前：デフォルトの名無しさん mailto:sage [04/10/24 02:51:26]: ハイレベルな話題で盛り上がっているところ悪いんだけど、教えてほしい。
何回か話題に出ている「ドメインモデル」ってなに？
ぐぐってもNT Domainばっかひっかかるよ。。
832 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:14:28]: ドメインモデル->実世界の構造のウツシミ
833 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:17:11]: 結局、こういう「だから何？」的な答え方になるんだよね。
これでわからなければ、一から説明しないといけない。
834 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:20:59]: モデリングの本とかで問題領域とかいわれてる部分。

簡潔に一言でいうの、頭よくないと出来ないと思う。
だから本とか読んだ方が早い。
835 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:23:09]: あ、そうか、だからぐぐるんなら
オブジェクト
設計
モデリング
問題領域
とか周辺の言葉を組み合わせでやってみれば
いいかも。
836 名前：デフォルトの名無しさん mailto:sage [04/10/24 03:44:42]: なんでも突き詰めると
「絵画の本質は絵を描くことだ」
みたいな、だから何？的な結論になるんだけど、その過程をたどってない人にはその意味や価値がわからないんだよね。
837 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:01:43]: 児玉センセの「UMLモデリングの本質」あたりを読むと
いいかもしんない。わりと薄いし。けど濃いめ。

釈然としない所もあるけどさー。
838 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:08:57]: > 釈然としない所もあるけどさー。

どういうところ？
839 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:19:41]: 2chの議論系スレッドの鉄則。
よっぱらったら書き込まない。

でも、なんか、ヱビスについてるフィギュアでシーサーがついてきて、なんとなく嬉しくなったので書き込み。

こういうビジネスモデルの場合はこういうモデルにするべき、そうじゃなくてこうするべき、って議論はとっても役に立つんだけど、そもそも、「こういうビジネスモデルの場合」があてにならないのはいかがなものか。
特に、間にわけのわからない人が挟まってる場合は顕著。
「これはこうで、そこまでは必要ないから」っていわれて、実際の利用先に行くと、「いや、これはこうじゃなくてそこまで必要、とっても重要」とか言われること多数。
どうするべきよ？
どうよ？
840 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:30:49]: >>838
大変面白く読めたし、勉強にもなりましたが
実装レベルに変換する、としておいて
OODBじゃなきゃだめよとなってるので
どうも現実感が湧かなかったのです。

その釈然としない所からO/Rマッピングを
色々調べだしまして、S2Daoに行き着いた時は
感激でしたわ。
841 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:32:09]: >>839
マジカの出番かな？
842 名前：デフォルトの名無しさん mailto:sage [04/10/24 04:59:47]: マジカ？
843 名前：デフォルトの名無しさん mailto:sage [04/10/24 05:01:25]: >>840
OODBは、RDBの成熟度の高さに打ちのめされた感じだね。
844 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:31:16]: 結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。
845 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:48:45]: Stateless, Statefulの違いって、DIコンテナとの相性があるのではないだろうか。

ttp://d.hatena.ne.jp/higayasuo/20041024#1098580377
> Statefulでやる場合、状態Sを持ったJavaBeansをnewして作成し使うことになるでしょう。
>そうすると、クライアントは、インターフェースではなく、実装クラスに依存することに
>なります。それを避けるために、すべての状態ごとにFactoryクラスを用意するのは、面倒
>でコストがかかります。
>Statelessでやる場合は、実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。

S2DaoのBeanアノテーションをSeasar2.1のmetaタグにしてしまえば、
Factoryクラスはいらなくなるんじゃないでしょうか。
さらに、S2DaoがBeanを作成する際にinjectDependency()すれば、業務ロジックをもたせる
ことが簡単になると思います。

>こう考えていくと、プレゼンテーション層から最初に呼び出されるクラスは、
>Statelessにすべきだと思います。

この「プレゼンテーション層から最初に呼び出されるクラス」というのが
ファウラー氏の言う「薄いサービス層」ですね。
846 名前：デフォルトの名無しさん mailto:sage [04/10/24 10:58:45]: >>845
その文脈でS2Daoを引き合いに出す理由が不明
ファウラー氏とひが氏のいうことを無理にあわせるのはよくないと思う。
847 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:00:29]: >>843
OODBはOOがどうのという前にDBとしてこれからなんだろうね。
RDBだって数10年かかって今の地位を築いたんだからこれからだろう。
848 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:04:19]: >>846
俺は>>845じゃないけど

「UMLモデリングの本質」を読んだら
OODBじゃないとだめよっていってるので
（RDBじゃ駄目なのかと）釈然としなくて
O/Rマッピングを調べたらS2Daoに出会えて
感激した

っていってるんだろ？別にファウラー氏もひが氏も
出てきてないぞ。
849 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:11:58]: ttp://nekop.programmers.jp/diary/?date=20041024
これ読んだらEAは俺には縁のない世界だと思った。
うちの会社はオフショアにまっしぐらだorz
850 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:12:46]: >>846
薄いサービス層のことなら、何も無理にではないですよ。
まさに合致していると思います。
S2Daoをだしたのは、「実装クラスの生成やDIは、DIContainerがすべて面倒を見てくれます。」に対応していて、StatefulなBeanを生成する際でも、DIContainerにある程度面倒みて
もらうことができると思ったんで。
851 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:18:07]: >>849
うちの会社の競争相手は中国人 orz..
852 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:25:51]: >>803
安心するヨロシ。
構造化や正規化すらできない、まともな仕様書すら書けない、要件定義だってできない。
そんな元請けがNやら何やらって名前だけで仕事とって丸投げする連中が、
くーすでオフショアなんて無理だって。
できる連中は今でもできるだろうし、そんな案件は元からうちにはこないアルよ。
853 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:26:46]: 先に誰かが書いていたアメリカの事情とか、
Fowler氏の前提としているEAとかあわせると
日本国内で一体どれだけの会社がEAを
必要としているのかという疑問が出てくるな。
漏れの会社は大手の下請ばかりやってるけど、
こんな案件はこないよ。そうじゃない案件は
大連と競合してるよorz
854 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:47:18]: >794

>>漏れ的には、迷ったらメンバーで相談する。

これすごく大事。そして相談できるようなプロジェクトはいいプロジェクトだと思う。
ところが世の中には「1年生」とか「ひよこ」とか人材派遣会社から送り込まれてくるJava初心者どころか
プログラム初心者とか三国人とかがたくさんいるところも多い。

そういうところではカッチリひとつの方針を決めないとやってらんないんだよね。
855 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:53:57]: 段々と下請の悲哀を語るスレと化してきたな
856 名前：デフォルトの名無しさん mailto:sage [04/10/24 11:56:26]: 結局、ソフトウェア開発の本質的で構造的な問題だからな。
857 名前：デフォルトの名無しさん [04/10/24 12:09:28]: 要するに悲哀感じるのは経営者がソフトウェア制作のことを分かってないから。
しっかり理解して投資していいチームを作るってことが重要なの。
858 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:20:20]: >>857が投資していいチームを作って漏れをやとってくれYO
859 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:29:31]: 問題は>>858が良いメンバーか、ということだが…
860 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:51:24]: >>857
その投資の原資はどこからもってくれば良いのでしょうか？
861 名前：デフォルトの名無しさん mailto:sage [04/10/24 12:57:45]: 資本金。
862 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:09:16]: >>861
資本金を投資する以上、一定期間後にはキャッシュリターンの実現が必要。
本当にキャッシュがリターンされるの？
各担当者の技術レベル向上が収穫とかいう寝言はやめてくれよ（藁
863 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:11:12]: データと処理は分離、という点でいくと、ORマッピングで継承使ったときに、ポリモーフィズムで処理を切り替えることについてはどう考えたらいいのかな。
864 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:12:02]: >>862
競争力。
865 名前：858 mailto:sage [04/10/24 13:13:24]: >>859
漏れはいいメンバーになるYO
頑張るから入れてください
866 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:18:14]: >>864
わけわからん
867 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:20:53]: >>853
そもそもアメリカってそんなにEAだらけなのかな？
ひょっとしてレアな特殊事例を一般論として売り込まれるだけなんじゃ…
868 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:21:18]: >>849
> ttp://nekop.programmers.jp/diary/?date=20041024
> これ読んだらEAは俺には縁のない世界だと思った。

ttp://d.hatena.ne.jp/habuakihiro/20041024#1098575922

はぶ氏も似たようなこと言ってる。
869 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:24:51]: >>844
手続き指向に対してオブジェクト指向はいわば「データ指向」といえる。
オブジェクトのデータ構造はオブジェクト内に隠蔽されているが、手続き自身も
オブジェクト内に隠蔽されているので、この手続きの再利用性が低くなる。
オブジェクト内の手続きを再利用する方法として継承を使うことができるが、
継承はクラス間の関連としては大変密な結合であり、単に手続きを再利用する
ためだけに派生クラスを作成して実装を継承するのは結合度が強くなって
しまうためよくない。

これらに対して、ジェネリック・プログラミングは「アルゴリズム指向」である。
これは、手続きの再利用性を求めて単に手続き指向の世界に回帰したように
見えるかもしれないが、そうではない。

ジェネリック・プログラミングにおける手続き(アルゴリズム)は、手続き指向の
手続きと違い、データの構造は知る必要がない。そのアルゴリズムを実装する
ために必要な操作をオブジェクトから開示してもらうことにより処理を行う。
従って、あるアルゴリズム(手続き)に処理してもらうために必要な最小限の
インタフェースをデータ型から抽出することが、ジェネリックプログラミングを
実現する第一歩となる。
870 名前：デフォルトの名無しさん [04/10/24 13:41:33]: >>844
>結局、やっぱプログラムとデータは分離するのが正しかった、というオチか。

ウィンドウシステムを扱うライブラリが非ＯＯだったときのことを考えれ。
871 名前：デフォルトの名無しさん [04/10/24 13:48:36]: >>890

>587
>顧客クラスにパスワード変更メソッド付けるなんてアフォ

つまり、データはハッシュマップなりで適当なもので表現して
（実際、形宣言無し言語ではこれが常識）、それを扱うプログラムをクラスとして
定義するのがいいってことで、パスワード変更クラス、ユーザ名変更クラスを作るのは
よい設計ってことやね。（経験積んだ人がシンプルに作ろうとしたら結局そうなる、いうまでもなく）
872 名前：デフォルトの名無しさん [04/10/24 13:52:04]: >>871

データを一番シンプルに扱えるのがハッシュマップである以上、
無意味なキャストが頻繁に起こるJavaは業務アプリ作りには向いてない。
型宣言が無い言語のほうが業務アプリ作りには向いてる、Javaは向いてない
っていう仮説はどうかな。
873 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:52:20]: >869
オブジェクト指向は学術的には"手続による抽象化"であって、
抽象データ型(ADT)より手続に近いっていう話しだが
漏れにはその区別がどうも良く解らない

結局メッセージパッシングしてメソッド(==手続)呼び出してるだけって事なのかな。
ADTとはどう違うんだ。
874 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:53:31]: 「こんなデータと処理の分離は嫌だ」シリーズを考えてみよう。

データと処理が分離されたCollection API

ｺﾜｰｲ…。
875 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:56:18]: ttp://sumim.no-ip.com:8080/wiki/710

視点の違い
876 名前：デフォルトの名無しさん mailto:sage [04/10/24 13:56:32]: データと処理が分離されたデータベース
877 名前：デフォルトの名無しさん [04/10/24 13:58:43]: >>873
結局メソッドを呼び出すのがＯＯ。
オブジェクト指向の肝はポリモーフィズムで、
それでシステムをシンプル（柔軟性と、メンテナンス性を保つ）に表現
するっていう、ただそれだけ。
878 名前：デフォルトの名無しさん [04/10/24 13:59:31]: >>872
Java5で解決ですが。。
879 名前：デフォルトの名無しさん [04/10/24 14:02:18]: >>878
漏れには解決しているようにはとても見えへんのよ
880 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:13:32]: だれか、>>863について斬ってくれ。
881 名前：デフォルトの名無しさん [04/10/24 14:15:50]: ORマッピングで継承って一体なんなんだ？　意味不明。
データはデータ。処理は処理だろ？
882 名前：デフォルトの名無しさん [04/10/24 14:20:09]: 処理の切り替えって、やりたきゃやればいいんじゃないの？
883 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:36:40]: >>881
こういうののことでつ。
ttp://objectstyle.org/cayenne/modelerguide/modeling-object-layer/inheritance.html
884 名前：デフォルトの名無しさん [04/10/24 14:44:58]: 処理の切り替えが沢山あるなら、

処理できる？
Handler#canHandling(data)
処理が重複したときの優先順位を返す
Handler#priority,
処理する
Handler#handle(data)

みたいのを作って

Manager#addHandler(handler)

てなことやると分離できるな。これが適切なときもあるにはあるだろう
885 名前：デフォルトの名無しさん mailto:sage [04/10/24 14:54:13]: >>871
>>872

そんなお前らはDbUtilsでも使ってろ。

まあ、>>872の後半はわりといいポイントをついてるような気がするんだが。
886 名前：デフォルトの名無しさん mailto:sage [04/10/24 15:57:59]: Ruby最高ってことでFA
887 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:11:53]: >>845
「薄いサービス層」の薄いって何のことだか分かって言ってる？
何でツッコミが入ってないのか分からんけど。

>>884
そこまでやって分離したがる理由が分からない。
素直にO/RMapper使って解決できる問題であれば、そうすべきだろう。
↑でも適材適所って言ってるだろ？
888 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:13:34]: >>887
「分離可能」といってるだけじゃないの？
「適切な場合もあるにはあるだろう」だし。
889 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:15:11]: >>888
だね。最後の方良く読んでなかった。ｽﾏｿ。
890 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:16:15]: >>871

890ゲット！！

データはマップで持っておくのがいいかもっていうか、だめっていうか、いいね。
思ってもいないことを言ってみる。
891 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:21:15]: ER図と照らし合わせながらでしか解読できんコードになるぞ。
892 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:35:46]: なんか急激にしょぼいスレに戻りましたね。
＞＞８８７
blogでは、その後ろに「ドメインモデル」或いは「リッチな業務ロジック」が続くと
書いてあります。ドメイン層ですね。
プレゼンテーション層から最初に呼ばれ、適切なドメイン層の処理を呼び出す
ステートレスなクラスというのは、薄いサービス層に他ならないのでは？
ファウラーではなくEric Evansですが。

間違っていたらご教授願います。
以下 ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?AnemicDomainModel より引用

アプリケーション層（サービス層のこと）：ソフトウェアが何をしなければいけないかを
定義し、ドメインオブジェクトに対して、問題を解決するよう命令する。この層の役割は
ビジネス活動にとって重要であり、別のシステムのアプリケーション層とやり取りをする
のにも必要である。この層は薄く保たれている。ビジネスルールやナレッジを含むもの
ではないが、その下の層にあるドメインオブジェクトの協調関係に対して、タスクを調整
したり、仕事を委譲したりしている。これはビジネスの状況を反映するものではないが、
ユーザーやプログラムの進捗状況を反映することは出来る。

ドメイン層（モデル層）：ビジネス、ビジネスの状況に関わる情報、ビジネスルールに
ついての概念を表す。ビジネスの状況を反映する情報は、ここで管理・使用される。
技術的には、その情報はインフラ側でストアされている。この層はビジネスソフトウェアの
魂である。

ここでのキーポイントは、サービス層は薄い、という点です（キーとなるロジックは
ドメイン層に置かれています）。
893 名前：887 mailto:sage [04/10/24 16:53:26]: >>892
なんだ、わかってたのね。

つまり、

[ドメインモデル]
UI層 ⇒ 薄いサービス層 ⇒ ドメインモデル ⇒ データアクセス層

[リッチな業務ロジックモデル]
UI層 ⇒ 薄いサービス層 ⇒ リッチな業務ロジックモデル ⇒ データアクセス層

こういうことなら、あのコンテキストで「薄いサービス層」って
言葉が出てくるのも納得できる。
ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
あまり見出せない。
分散環境でも無い限り、ドメインモデルでの薄いサービス層はリッチな業務ロジックモデルに
対応するって方が自然な気がするんだけど、どうでしょう。
894 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:55:07]: >>892
> なんか急激にしょぼいスレに戻りましたね。
禿げ胴!!
S2とも、くーすとも関係なくなった。しかもレベル低い。
895 名前：デフォルトの名無しさん mailto:sage [04/10/24 16:58:47]: OO厨なんてこんなもん
896 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:32:46]: と、OOがわからなかったCプログラマーが申しております。
897 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:42:11]: フォーラムみたいなのがあればなぁって
誰かが言ってたけど、ホントにあったほうがいいような気がする。
2chだとまともに議論にならんことも多いから。
898 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:45:23]: >>893
>ただ「リッチな業務ロジックモデル」の場合、薄いサービス層の存在意義が
>あまり見出せない。

プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。
899 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:55:05]: >>898
> プレゼンテーション層から呼び出す際の、業務ロジックのファサードになるのでは？
> ドメイン層の詳細にプレゼンテーション層が依存してしまわないように。

素直に考えるとそうなんだけど、実際にファサードが必要になる状況ってそんなに無いよね？
だからそれをスタンダードにしまうのにはちょっと違和感を感じる。

ステートレスなサービス層が具体的に何を想定しているのか、
ひがさん本人に聞くのが一番早いんだろうけど。まだちょっとわかり辛いかな。
900 名前：デフォルトの名無しさん mailto:sage [04/10/24 17:58:36]: ファサードが必要になる状況というか、
普通にデザインしてたらそこはそうするだろ。
EJBを使ったことのある人間なら。
StatelessSessionBeanでサービスを作る必要性がわかる人間なら。。
StrutsのActionクラスに業務ロジックを書くことにためらいがある人間なら。
901 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:03:10]: >>900
StrutsのActionから直接ステートレスな業務ロジック呼び出すのと、
間に無駄なファサード挟むことの違いを言ってるんだが。
902 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:03:41]: ひがさんは「プレゼンテーションから呼び出す（業務ロジックの）メソッドは１つだけ」
と仰ってます。

分散環境でなくとも、各層間のインターフェースはシンプルにしておくのは有効だと思います。
プレゼンテーション層は、StrutsやTapestryなどのフレームワークに密接に依存するため、
テストがしにくいからです。また、各層での平行開発も行えるようになります。
903 名前：910 mailto:sage [04/10/24 18:12:38]: 説明が悪いのかな。
900氏の言うように「普通にデザインしてたら」、
StrutsのActionなどに提供される業務ロジックインターフェースの
メソッドは１つだけになる。で、複数必要になるような状況ではファサード挟む。
でも、複数呼び出しが必要になるような状況(つまりファサードが必要になる状況)ってそんなに多いか？
多くないならいきなりActionから業務ロジックのインターフェースで提供されてる
メソッド呼び出すほうが素直じゃないの？って思ったんですよ。
904 名前：デフォルトの名無しさん [04/10/24 18:13:33]: >>869
それって、DB毎にアクセス用サブルーチン作って、手続き型してるだけでわ。
905 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:18:01]: >>903
必要ないでしょ。ケースバイケース。
906 名前：デフォルトの名無しさん mailto:sage [04/10/24 18:28:51]: かつて、ほぼ並行して2つのやり方をしたプロジェクトがありました。

あるプロジェクトでは、人に業務機能を割りあてました。
データベース設計はある一人が担当し、
他の各人がデータベース―EJB―Web層(Struts)、HTMLをすべて担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、ある程度のレベルまで上昇しました。
メンバに感想を聞いてみると「設計としては汚い。楽なことはなかった」とのことでした。

あるプロジェクトでは、人にシステムの機能を割りあてました。
データベース設計、EJB、Web層(Struts)、HTMLを、それぞれが担当しました。
全員のスキルはまちまちでした。
みんな徹夜を続けながら、死ぬ思いで納品しました。
みんなのスキルは、担当場所についてのみかなりのレベルまで上昇しました。
メンバに感想を聞いてみると「綺麗な設計になってる。実装作業は楽だった」とのことでした。

誰が幸せなのでしょう。
907 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:22:17]: >>906
> 誰が幸せなのでしょう。
俺俺！
908 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:25:02]: 綺麗な設計を手に入れたお客さん。
909 名前：デフォルトの名無しさん mailto:sage [04/10/24 19:34:41]: >>897
S2で作れ！期待してます！
910 名前：デフォルトの名無しさん mailto:sage [04/10/24 20:12:08]: >>909
その前にくーすで設計だろ？
911 名前：デフォルトの名無しさん [04/10/24 20:32:39]: そうこうしている間に.Netが主流に。
912 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:01:43]: Ruby.netが最強だと。
913 名前：デフォルトの名無しさん [04/10/24 21:05:27]: 薄いサービス層 ⇒ ドメインモデル
とか
薄いサービス層 ⇒ リッチな業務ロジックモデル

これ、何いうてるんですかね。
どうしてもプラットフォーム／言語非依存にしたくてっていう気分でもならないかぎり、
この２つを分ける理由は謎。
914 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:09:50]: >>913
...これまでの流れ、分かってます？
915 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:21:37]: Ruby最強・・・かな？
916 名前：デフォルトの名無しさん [04/10/24 21:21:50]: 正直、ドメインモデル　リッチな業務ロジックモデル

の違いも分からん

藻前ら難しく考えすぎだ
917 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:41:30]: >> 916
お前は、きっちり分割されたシステムの一部を仕様通りに
月１５万でコーディングすればいいだけだから、気にするな。
918 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:56:07]: >>917
月１５万でコーディングしてくれるの？
だったらうちで働いてよ。
919 名前：デフォルトの名無しさん mailto:sage [04/10/24 21:58:55]: 2人日の価格で1人月か。お徳だ。うちにぜひこないか
920 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:14:18]: うほっ！

か　か　な　い　か　？
921 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:16:11]: >>919
あんたのところ高すぎ。
コーダーで月１５０万かよ！

うちの倍とってるじゃん。。。
922 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:16:47]: じゃあRubyのDIコンテナに期待しよう
あるのかな
923 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:33:31]: そろそろ新スレ立ててもいいんでない?
924 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:38:28]: 今の流れだと、次スレは必要なさそう。
925 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:39:14]: 盛り上がっているところに水を指すのは申し訳ないが
正直S2ネタが殆どないのにS2の名前で新スレ立てる
意味がないような気ガス。どう見ても単なるOOネタ。
こっちのスレのほうが適している気がする

【OO?】オブジェクトオリエンテッド総合【非OO？】
pc5.2ch.net/test/read.cgi/tech/1041658161/l50
926 名前：デフォルトの名無しさん mailto:sage [04/10/24 22:45:08]: そうだな。
PoEAAのスレでも立てるほうがよっぽど盛り上がるんじゃないか？
S2ネタはS2JSFｷﾎﾞﾝﾇばっかりだしｗ
927 名前：デフォルトの名無しさん [04/10/24 22:52:43]: >>917
>お前は、きっちり分割されたシステムの一部を仕様通り

そんなシステムあるわけないだろボーケー
928 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:02:45]: >> 927
まず日本語から勉強しましょうね～。
929 名前：805 [04/10/24 23:05:07]: >Statelessな場合は、Ma、Mbに依存関係はありません、と以前書いたのですが、
>実は間違ってますね。m(_ _)m
>ここでいっている依存関係とは、呼び出し順序の依存関係です。
>
>状態Sが更新されない場合は、確かにMa、Mbには依存関係はありません。
>しかし、MaでSが更新され、MbがMaで更新されたことをあてにしている場合、
>MbはMaに依存しているということになります。

Mbが依存しているのは Maじゃなくて、ステートSなんだと思うんだよね。

Maの呼び出しによって、ステートS => ステートSa となるとして、
Mbが当てにしているのは「事前のMaの呼び出し」ではなくて
「Ma呼び出しによってセットされるステートSa」なんじゃないかな?

よって、ステートSを外に出したところで MbがステートSaを前提にしていることには
なんら変わりない、ステートSを中に置こうと外に出そうと何も変わりはない、と。
930 名前：805 mailto:sage [04/10/24 23:06:15]: >>929

ごめん、ソースは
d.hatena.ne.jp/higayasuo/20041024#1098580377
ね。
931 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:13:31]: OOネタはS2というかくーすから転がっていって
ひがさんのブログでの反応とあいまって
こうなったんで、このままここでいいよ。
932 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:16:36]: 普通はスレ違いなんだがな。
このスレには優しい人が多いということか。
933 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:19:16]: このスレは次から「国産DIコンテナSeasarの人たちv2」という名前にするべきだ。
そうすれば、今までのこともスレ違いではなくなる。
934 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:20:03]: ダサッ！
935 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:46:17]: >>929
　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
したりできて便利になるような気がするんだけど。

もちろんこれは（現実に広い応用はあっても）トイ・アプリケーションレベルの簡単な
ロジックの場合だけであって、複雑なステートを持つ UI セントリックなアプリケーションが
必要な場合などにはステートを外だしにすることによって情報隠蔽の逆を行ってしまう
可能性もあるわけだけれども (そういう部分をクライアント側に押し付けられるなら有効か・・・)。
936 名前：デフォルトの名無しさん mailto:sage [04/10/24 23:53:55]: 比嘉氏はStateはPresentation層に持つって言ってるので>>935は同じ事を言ってる気がするのだが
937 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:00:23]: >>933-934
「S2のソナタ」にでもしておけばよかろう
正直漏れは次スレいらん気がしてるが
938 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:03:48]: >933
人たちというか、そもそもS2ってそれ自体で何が出来るというものでもなくて
開発を支援する（＝楽にする）ってな発想だと思うので、その流れでくーすときて
じゃ、既存のOOPとか設計ってどうなのよ？って話になってもおかしくないと思われ。

>936
Flash（Flexもだが）やら.NetのSmart ClientみたいなRIA（リッチかどうかはさておき）のWebアプリなら
Presentation層で保持するのでやり易いだろう。
HTMLのブラウザベースのWebアプリだと小細工をせんといかんのだけど
939 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:13:28]: >> 938
そこでS2JSFですよ。
940 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:15:06]: >938
おれ今までsessionとかrequestってプレゼン側領域だと思って
状態の管理にも使ってたんだけど、世間じゃ違うのかな。
小細工ってどんなの？
941 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:19:59]: OOPの話がしたければ、それなりのスレへ。
新しい別のスレをたてる必要はない。
そこではSeasarの話はスレ違いだがね。
Seasarの話、くーすの話、ひがさんはぶさんの話がしたければ、それなりのタイトルのスレ建てれ。
942 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:25:20]: 禿同
長文多いしage多いしスレ違い多いし
ハッキリ言ってウザイ
943 名前：805 mailto:sage [04/10/25 00:26:53]: >>935
> >>929
> 　おバカな漏れからみると、ステートを外出しに出来れば、例えばセッションの方を
> ステートフルにしてサービス（ロジック）オブジェクトはステートレスにしてプーリング
> したりできて便利になるような気がするんだけど。

ドメインロジックを含んだクラスをステートレスにすると、
SmalltalkBestPracticePatternsで挙げられているパターンや、リファクタリングの
テクニックの大半が使えなくなります。
# 数少ない経験に基づいてるので嘘かもしれませんが。

そんな強烈なデメリットを負ってまでステートレスにして得られるものが、
「サービスオブジェクトのプーリング」というのは、
*個人的には*、割に合わないと感じています。

# もちろん、必然性のあるステートレス化には賛成ですが。
944 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:29:27]: 「ダイコン時代のスレ」でいいんじゃない？
945 名前：デフォルトの名無しさん [04/10/25 00:34:31]: もう分かりきってることだと思うけど、抽象的過ぎてかみ合わない。
アプリケーション毎に違うんだよ。どういうパターンがいいかなんて。
もう漏れは飽きた。寝る。
946 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:35:59]: seasarの話、くーすの話、OOの話、業務の話、
全てはひが様のもとへ、じゃ。
よってこのまま続行。

つか、ここの住人が杓子定規なスレタイ重視によって
分散してしまうのは、しじょーにもったいなく思いまーす。
947 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:38:14]: では違うところに集うが良かろう。
でなければまずはsage進行で頼む。
948 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:48:11]: >943
Cookieゴソゴソしたり、HTTP越しにSessionオブジェクトを弄ぶのはなんか不健康な気がしたので。
勿論、仕方無しにPresentationの役割と思ってやってるんだけど

>941、942
見てるからには何らかの関心があると思うんだが、じゃ、どんな話題なら良いのよ？
大半の香具師はアンチうざいのでsage進行だと思うしさあ。
とにもかくにも嫌なら見ることねえじゃん。君の人生、時間は限られてるんだからさあ。

>944、946
禿同、けど’ダイコン時代’ってキーワードはまだ認知されてないのでスレタイにはどうかなあ。
J2EEに疲れてませんかってなのはどう？けど、アンチJavaの呼び水になるからなあ。
あ、ちなみに自分は.NetもJavaでも楽に儲かりゃどっちでもいいし、どっちも実務でやってるので
宗教論争ならくだらん。
949 名前：デフォルトの名無しさん mailto:sage [04/10/25 00:59:23]: しょっちゅうageてるじゃねえか。
上にくりゃ見えちまうだろうが。
sageくらい覚えろよ。
あと変なポインタ振るな。
長々書き込むな。
正直このスレの住人ウザイ。
2ちゃんにくんな。
950 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:10:48]: J2EEに疲れてませんか、ではくーすの話はスレ違いだね。
951 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:29:23]: >>949
N速にでも逝って２ちゃんらしさを存分に味わっとけ。
次スレはsage進行でマターリと語りたいね。
952 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:30:13]: >>945みたいなアゲにげするやつがいるからねぇ。
953 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:32:45]: じゃ、次はS2JSFでてからってことで解散。
954 名前：デフォルトの名無しさん mailto:sage [04/10/25 01:33:08]: 分析から実装まで
開発を見つめるDICON
955 名前：デフォルトの名無しさん [04/10/25 02:17:15]: もはや広告が撲滅された以上、sageと入れるのは馬鹿。
そもそも同人板のヲタ女達が始めた風習だし。
956 名前：デフォルトの名無しさん mailto:sage [04/10/25 02:24:08]: 風習の起源とか目的とか、どうでもいいだろうが。
いまそういう風習なんだから。
957 名前：デフォルトの名無しさん mailto:sage [04/10/25 02:38:26]: Stateless化することで見込まれているメリットの肝は、実は分業の徹底では
ないかと思う。設計段階でDomain Modelを完璧に固めるのは困難だし、
かと言ってXPみたいにボトムアップでぐりぐり設計が変わるのを許容して
しまうと、チームに馬鹿が一人いるだけでリーダーは安心して眠れない。

そしてある程度の規模の仕事となるとだいたい馬鹿のほうが多数派になって
しまうのが悲しい現状だ。

そこで「馬鹿はinterfaceをいじっちゃいけない」という制約が登場。
958 名前：デフォルトの名無しさん mailto:sage [04/10/25 08:06:05]: 次スレ立てるんなら>>1はガイドラインよろ
sageでﾏﾀｰﾘとか個人名晒した誹謗中傷はなしとかそういうのな
せっかくいい感じになってきたのでﾀﾉﾑ
959 名前：デフォルトの名無しさん [04/10/25 11:28:42]: >>957

ペアプログラミングと腐らずコミュニケーション続けることしか解決の道は無い
960 名前：デフォルトの名無しさん mailto:sage [04/10/26 00:49:26]: このままのスレでいいじゃん。
961 名前：デフォルトの名無しさん mailto:sage [04/10/26 01:14:57]: スレタイに「くーす」要追加。
962 名前：デフォルトの名無しさん mailto:sage [04/10/27 05:30:18]: AVAYAのロゴがAYAYAに見えるオレは、なにかに毒されていますか？
963 名前：デフォルトの名無しさん mailto:sage [04/10/27 17:20:16]: 次スレはS2JSFが完成してからだね。
964 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:13:24]: 関係ないけど、サンプルのHTMLにmetaタグでcontent-type入れるのはかっこ悪いからやめたほうがいいと思われ。
S2JSFだとContentTypeヘッダーを送れないというのなら別だけど。
965 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:15:46]: 最も単純な例がXHTMLだとしたら、普通のHTMLは使えないのかと思ってしまう。
966 名前：デフォルトの名無しさん mailto:sage [04/10/27 20:57:39]: >>964
なんでかっこわるいの？
967 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:00:22]: ContentTypeヘッダーを送るならmetaタグ入れないほうがいいことになってるから。
968 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:11:17]: >>967
それがかっこわるい理由か？
969 名前：デフォルトの名無しさん mailto:sage [04/10/27 22:59:04]: >>967
RFC&W3Cﾏﾝｾｰなんだね。

IEおよびNetscapeの特定のバージョン（忘れた）でヘッダだけでは
文字化けする場合があるバグありバージョンがある。
客に文字化けするんだがって言われたらブラウザのバグですって言うの？

まー、客から見たら文字化けしないサイトもあるんだから対応しろボケって
なると思うけど。
970 名前：デフォルトの名無しさん [04/10/27 23:13:06]: 次スレ立てました。

国産DIコンテナSeaserとくーすその2
pc5.2ch.net/test/read.cgi/tech/1098885253/
971 名前：デフォルトの名無しさん mailto:sage [04/10/28 01:05:52]: 技術屋がかっこつけようとすると
お客さんの価値観とは合わなくなる事が多く思いますが
よい例でしょうかね。

俺も出来る事なら存分にかっこつけてみたいわ。
972 名前：デフォルトの名無しさん mailto:sage [04/10/28 02:20:21]: 969が正解でしたね。

ひがさんてば、こんな事にまで答えてくれるとは・・・・。
973 名前：デフォルトの名無しさん mailto:sage [04/10/29 00:38:27]: >>972
俺は >>571 です。
ここはエセ技術屋が多いインターネッツですね。
うんこばかりだな。
974 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:42:43]: はいはい
あなたみたいにみんなから尊敬される素晴らしい技
術屋さんには見るもの全てがうんこにしか見えない
んだろうからここに来なくてもいいよ
975 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:53:25]: エセねらーがｲｿﾀｰﾈｯﾂとか書いてんじゃねえよ（藁
976 名前：デフォルトの名無しさん mailto:sage [04/10/29 01:59:02]: お，半角SPACEたんｷﾀｰ(AA略)
相変わらずの粘着ぶりでつね！
977 名前：デフォルトの名無しさん mailto:sage [04/10/29 02:00:22]: metaタグうんぬん言ってた人が
571ってこと？

まあmetaタグがどうのってこだわりがあって
そういうのが技術力だって価値観も確かにアリだと思うけど
そういう価値観の人ならseasarもくーすも要らないんじゃないかな。
978 名前：デフォルトの名無しさん mailto:sage [04/10/29 02:15:26]: 571 たんはひがたんよりも自分のほうが優秀なのにひがたんのほうが目立っているので嫉妬してるのでつ
ASM も meta もせっかく教えてやってるのに聞いてくれないのでひがたんはうんこな香具師だと思ってるのでつ
要するに 571 たんはひがたんのうんこが食べたいのでつ
頑張ってイソターネッツとか書いてる 571 たんは本当はいい人なのでつ
979 名前：デフォルトの名無しさん mailto:sage [04/10/29 23:50:16]: ひがさんはいつ仕事してるんだろうか
980 名前：デフォルトの名無しさん mailto:sage [04/10/30 17:02:00]: タペのサンプルの動かし方がわからん。
981 名前：デフォルトの名無しさん [04/10/31 13:23:24]: 顧客満足＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞W3C,RFC
982 名前：デフォルトの名無しさん mailto:sage [04/10/31 17:26:28]: 長期間の動作保障＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞クイックハック
983 名前：デフォルトの名無しさん mailto:sage [04/10/31 21:52:57]: ベンダの短期的な思惑＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞＞(超えられない壁)＞＞＞＞＞＞＞＞＞＞＞＞＞＞長期間の動作保障
984 名前：デフォルトの名無しさん [04/10/31 23:28:25]: 長期の動作保証とクリックハックは往々にして両立する罠
例えば、metaタグでcontent-type入れるのとか。
985 名前：デフォルトの名無しさん mailto:sage [04/10/31 23:31:04]: ×リ
○ィ
986 名前：デフォルトの名無しさん mailto:sage [04/11/01 23:58:53]: ちゃんとスレ埋め立てようぜ
次スレばっかり伸びてるじゃねえか
987 名前：デフォルトの名無しさん mailto:sage [04/11/02 00:52:51]: いっそ次スレのほうが先に埋まるのを見届けるとか
988 名前：デフォルトの名無しさん mailto:sage [04/11/02 05:42:06]: 980も超えてるし、そのうち勝手に落ちるよ。
989 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:09:12]: せっかくだからしりとりでもしようぜ。まずは俺からな。

シーサー

次！
990 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:27:24]: サッシ
991 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:47:24]: 示唆
992 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:55:37]: サラシ
993 名前：デフォルトの名無しさん mailto:sage [04/11/02 14:57:10]: シーサー
994 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:01:49]: >>993
サナダムシ
995 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:51:14]: 視差
996 名前：デフォルトの名無しさん mailto:sage [04/11/02 15:55:14]: 桟橋
997 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:14:19]: 審査
998 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:18:16]: 酒蒸し
999 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:23:44]: しにせ
1000 名前：デフォルトの名無しさん mailto:sage [04/11/02 17:24:23]: せん
1001 名前：１００１ [Over 1000 Thread]: このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef