07/01/23 11:00:54
Rod Johnson著「実践J2EE システムデザイン」
URLﾘﾝｸ(www.amazon.co.jp)
TheServerSide.com - Introducing the Spring Framework
URLﾘﾝｸ(www.theserverside.com)
Rod Johnson著「J2EE Development without EJB, Expert One-on-One」2004年5月発刊予定
URLﾘﾝｸ(www.amazon.co.jp)
SourceBeatの電子出版書籍「Spring Live」
URLﾘﾝｸ(www.sourcebeat.com)
「Spring Live」サポート用Blog
URLﾘﾝｸ(www.sourcebeat.com)
Struts + Hibernate + Spring Framework のWebアプリ 作者は「Spring Live」の著者
URLﾘﾝｸ(raibledesigns.com)
Spring Frameworkを使用したJDBCプログラミングチュートリアル(作成途中)
URLﾘﾝｸ(www.buggybean.org)
eclipseプラグイン「Spring UI for Eclipse」
URLﾘﾝｸ(springui.sourceforge.net)
Spring FrameworkのWiki「Spring Pad」
URLﾘﾝｸ(wiki.bmedianode.com)
Spring Frameworkを利用した蔵書検索アプリケーション
URLﾘﾝｸ(www.commentout.com)
PicoContainerのプレゼンテーション資料日本語版(IoCの説明がわかりやすい)
URLﾘﾝｸ(cvs.picocontainer.codehaus.org)
3:デフォルトの名無しさん
07/01/23 11:27:24
コネクションプールからEntityManagerのDI生成するのは常識だろ
NetBeans＋glassfishとか全部自動でやってくれるぜ
TomcatからしかやらないようなレベルならDIコンテナも（DBによっては）コネクションプールもいらないかもしれないけどな
4:デフォルトの名無しさん
07/01/23 11:30:42
DI生成するってどういう意味？
DIって言葉の使い方がおかしい希ガス。
5:デフォルトの名無しさん
07/01/23 11:42:42
注入コードってことだな
6:デフォルトの名無しさん
07/01/23 11:54:55
>コネクションプールからEntityManagerのDI生成する
いみふ
>TomcatからしかやらないようなレベルならDIコンテナも（DBによっては）コネクションプールもいらないかもしれないけどな
これもいみふ
7:デフォルトの名無しさん
07/01/23 12:58:51
スレ違いだがglassfishて運用に耐えるクオリティなのか？
8:デフォルトの名無しさん
07/01/23 15:22:02
>>3
言葉は正しく使おうな。
脳内で勝手に進化させないように。
>>6
まったく同じこと思いました。わけわかんないね。
9:デフォルトの名無しさん
07/01/23 15:23:00
>>7
Tomcatを運用で使える程度の要件ならおｋ。
10:デフォルトの名無しさん
07/01/23 15:24:15
EntityManagerのDI？
DI生成する？
しかもコネクションプールから？
氏んでいいよ。
11:デフォルトの名無しさん
07/01/23 16:45:52
>>9
sunが9.0はまだプラットフォーム版しか出してないからな
これがスタンダード版やエンタープライズ版もだしてくるようだと大丈夫と思われ
どちらにせよ開発はglassfishで運用はsunやIBM,WebLogicの商用版ってところだろうが
どこが最初にJavaEE5対応の商用版出してくるか見もの
12:デフォルトの名無しさん
07/01/23 17:03:14
>>11
goodなコメントThanx.
>>3
nonsense
13:デフォルトの名無しさん
07/01/23 22:24:34
ﾊ,,ﾊ
('(ﾟ∀ﾟ∩_ おいらをどこかのスレに送って！
／ヽ 〈／＼ お別れの時にはお土産を持たせてね！
／|￣￣￣|.＼／
| .ﾓﾂ煮..|／
￣￣￣
現在の所持品：カスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
ＪＡＳＲＡＣが73歳おじいちゃんに音楽を演奏したんだから840万払えと告訴
判決懲役１０月、執行猶予３年（求刑・懲役１０月）
日本音楽著作権協会（JASRAC）が、名古屋の飲食店経営のおばちゃんに、
音楽を演奏したんだから1,600万円払え、と告訴し、おばちゃんは逮捕。
ｽﾚﾘﾝｸ(news4vip板)
14:デフォルトの名無しさん
07/01/23 23:13:37
>>3 のアレは煽りのつもりなのか何なのか。
ようやく変な人が出てくるくらいに普及し始めたのだと
前向きにとららえることにした。
ところで DIxAOP コンテナとして紹介されるけど
AOP を意識してる人ってどのくらい居ます？
トランザクション管理とかで間接的には使ってるんだけど。
15:デフォルトの名無しさん
07/01/23 23:19:00
spring使うからにはAOP使わないと意味ないだろー！！！
ってぐらい意識してる
16:デフォルトの名無しさん
07/01/23 23:20:22
>>15
どんなことに使うの？
17:デフォルトの名無しさん
07/01/24 01:12:20
Japan Spring User Groupにある導入事例見てみるといいよ。
ほとんどがトランザクション管理とかトレースとか一般的な使い方だったよ。
今さ、S2DxoをSpringで使えるように移植してるんだけど、AOPってこういう使い方もあるんだって勉強になる。
HibernateとかもAOPでエンハンスしてるんだよね？
18:デフォルトの名無しさん
07/01/24 04:49:17
Jythonって完成度高い？Pythonの勉強に使ってみようかと思ってるんだけど。
19:デフォルトの名無しさん
07/01/24 11:52:01
JRubyは完成度高かった。
20:デフォルトの名無しさん
07/01/28 18:12:25
javaでWeb開発やってるが、strutsとかFWをまったくつかったことがない。
オブジェクト指向がわかってないし、javaもわかってて使ってるのかも怪しい。
勉強なんかはまずしない。
こんな連中にSpringを使わせるのは危険かな？
Hibernateは無理だろうからとりあえずiBatisかDbUtilあたりから入ってみようと思ってる。
21:デフォルトの名無しさん
07/01/28 18:27:52
そんな連中にソフトウェア開発させるのが危険ｗ
でも、そういった連中に指導・指示・教育できるのならspring導入は問題ないのでは？
22:デフォルトの名無しさん
07/01/28 18:40:03
> javaでWeb開発やってるが、strutsとかFWをまったくつかったことがない。
自社製フレームワークとかすらも無いわけ？
プロジェクト毎にゼロから書きなおしてるとか？
23:デフォルトの名無しさん
07/01/28 18:59:44
他はどうとうでもなるが
＞勉強なんかはまずしない。
これは話にならんな。
知らんものは調べれば済むんだが調べようとしないのでは。
24:デフォルトの名無しさん
07/01/28 20:25:42
やっぱ無理だよね。
仮に使えるようになってもspringの何がいいの？設定ファイルうざくね？ってなるのがオチだな。
ﾊｧ。もっとまともなレベルの会社に行きたい。
みんなありがと。
25:デフォルトの名無しさん
07/01/28 20:29:41
むしろ>>20みたいな環境でこそspringが役に立つと思うが。
26:デフォルトの名無しさん
07/01/28 20:40:05
>>24
プロジェクトとしてSpringを使うことは可能。
連中にはinterfaceだけはとにかくきちんと定義することを徹底させて
(interfaceがきちんと機能を表現できてるかはお前さんがチェックする。)
実装は好き勝手にしやがれ、単体テストだけは完璧に通せと言う。
設定ファイルうざくね？とか言われたら
じゃぁお前がフレームワーク作るか？といえば黙る。
Springそのものの仕様・実装でうまく行かないところとかは
全部お前さんが調べてお前さんが直す。
これでどうにかなる。
他のメンバーの10倍以上の負担をお前さんが背負うことになるが
闇雲に突き進むより数段マシな結果が得られる。
あとコードレビューは最低週１回以上はやった方がいい。
27:デフォルトの名無しさん
07/01/28 20:43:33
>>26
同意。
ほっとくとゴミを量産されて、10倍どころの負担じゃ効かなくなる。
28:デフォルトの名無しさん
07/01/28 21:10:32
>>25
おれもそう思ったんだが、なかなか・・・
>>26
interfaceの存在は知っていても自分で宣言したことはないであろう人々だからなぁ。
やっぱ俺が使うって言ったら俺が面倒みなきゃなんないんだよな。
客と打ち合わせして、ドキュメント作って、環境構築しに行って(運用もやるので)、
コードレビュー・・・。手が回らん気がする。俺も実装やらなきゃいけないだろうし。
Springスーパーサンプルとかいう本を全員に読ませれば少しはましになるかな？
簡単だけどWebアプリの作り方が１からのってるし。
新人(そこまで馬鹿じゃないと思うが)にspringつーかjavaを理解させるのにどういうことから教えますか？
29:デフォルトの名無しさん
07/01/28 21:23:01
＞手が回らん気がする。
この状況はSpring使わない従来の作り方だと解消されるの？
であるならば従来のやり方でやったらいいんじゃないかな。
いずれにせよ一人は辛い。もう一人で良いから理解ある人を連れてくるべき。
＞どういうことから教えますか？
開発環境だけ整備してやって、あとは実地でやれでいいんじゃないの？
分からないところあったら質問に来いで十分。あなただってそうだったでしょ？
これはもうマ板の話題だと思うんだが。
30:デフォルトの名無しさん
07/01/28 21:24:11
ｔｈｘ。そろそろ引っ込みます。
31:デフォルトの名無しさん
07/01/28 23:58:38
>>28
インタフェースは全部あなたがつくってみんなに配ればいいじゃない。
んで、内製のクラスはnew禁止にする。
これでOKじゃね？
32:デフォルトの名無しさん
07/01/29 06:57:22
何か１つ業務選んで、Spring使ったプロトを作って、それをひたすら真似させたら？
33:デフォルトの名無しさん
07/01/30 22:19:25
ロジックを実装しているクラスをActionSupport実装クラス内で使いたいのですが、
インスタンスを取得するのにgetBean()をするのと、setterインジェクションを使用するのではどちらがよいのでしょうか。
もしかしたらどちらもおかしいのかもしれませんが、一般的？な方法を教えていただけないでしょうか。
34:デフォルトの名無しさん
07/01/31 08:03:31
お好きな方で♪
35:デフォルトの名無しさん
07/01/31 09:16:16
インジェクション！インジェクション！
36:デフォルトの名無しさん
07/01/31 09:38:18
異論反論インジェクション！！！
37:デフォルトの名無しさん
07/01/31 10:59:50
>>2
> eclipseプラグイン「Spring UI for Eclipse」
> URLﾘﾝｸ(springui.sourceforge.net)
これってSpring IDEよりもいいの？
Spring IDEと重複しても問題ない？
コンフリクトでEclipseが壊れるのが怖いんだけど。
なんどもEclipseを再インストールしている身分ですので
38:デフォルトの名無しさん
07/01/31 11:04:47
>>37
あれ？
名称変更された同一プロダクトじゃなかったっけ？
間違ってたらｽﾏﾝ。
39:デフォルトの名無しさん
07/01/31 12:24:14
>>37
URLが
URLﾘﾝｸ(www.springide.org)
にかわっとるね
40:デフォルトの名無しさん
07/01/31 12:24:50
見ると、Spring IDEという名前に変わってるね
41:33
07/02/01 00:36:44
>>34-36
どっちでもいいってことですか？すみません。
なんかからかわれてるようにもみえるのですが・・・
42:デフォルトの名無しさん
07/02/01 01:32:24
setter injectionを使うのが一般的。
43:デフォルトの名無しさん
07/02/01 02:01:26
半々かな
44:35
07/02/01 09:02:53
>>41
ごめん。からかってみた。
俺敵にはセッターインジェクションで。
Springに依存したコードでいいならgetBeanも選択肢って程度。
45:デフォルトの名無しさん
07/02/01 21:36:45
ちょっと書いてみればいい。
getBean だと疲れるよ。
46:デフォルトの名無しさん
07/02/01 23:46:06
すみません。質問させてください。
ログイン管理をするインターフェースが用意されていて、それを私が実装することになりました。
login(id, password)
logout()
のようなメソッドがあり、id,passが正しかったらセッションに情報を格納しようとしたのですが、
どう考えてもセッションのインスタンスが取得できません。setterインジェクションとかでどうにかなるものなのですか？
47:デフォルトの名無しさん
07/02/02 00:01:57
セッションのインスタンスってなに？
48:デフォルトの名無しさん
07/02/02 00:23:03
>>46
＞どう考えてもセッションのインスタンスが取得できません。
できないことないけど、無理してやるメリットがない。
login(context, id, password)
こうしとけ
login(userのbean, id, password)
のほうがいいけど。
49:デフォルトの名無しさん
07/02/02 01:23:08
contextってなんだ？ｗｗｗ
50:デフォルトの名無しさん
07/02/02 01:32:24
やっぱSpringかな？
時期的にも
51:デフォルトの名無しさん
07/02/02 02:09:48
>>50
でもこのスレ見る限りまともに使えてそうな奴も居ない現実
52:デフォルトの名無しさん
07/02/02 02:28:19
>>51
Strutsとかと違って、下手を引き上げるためのもんじゃないしな。
上手が楽するためのもんだから。
53:デフォルトの名無しさん
07/02/02 03:42:56
Strutsだってマトモに使えるやつ（ｒｙ
54:デフォルトの名無しさん
07/02/02 08:43:45
やっとstruts + spring + jpa の maven環境できた・・・
55:デフォルトの名無しさん
07/02/02 11:42:55
>>46
聞くならもう少し詳しく。
その説明じゃ、セッションにバインドされるクラスなのか、
セッションを扱うクラスなのか、何も分からんじゃないか。
56:デフォルトの名無しさん
07/02/02 12:19:35
そんなまじにならなくてもｗ
既に解決して用済みかもしれないしｗｗｗ
57:デフォルトの名無しさん
07/02/02 13:00:47
つかSpring2.0ならセッションスコープのインジェクションできなかったけ。
58:デフォルトの名無しさん
07/02/02 13:06:52
連投スマソ。
1.0系の時はServketFilterでHttpServletRequestを全部ThredLocal変数にいれて、
使う側、たとえばログインサービスなんかはThredLocal変数を保持したHolderクラスかなんかをインジェクションしてたな。
まあ>>46の場合はまともに考えたら、
interface LoginService {
User login(String id, String password);
void logout(User user);
}
とかなって、セッションにデータを保存なんて、
このインターフェースでやる事じゃないと思うが…。
59:デフォルトの名無しさん
07/02/02 15:43:56
Acegi
60:デフォルトの名無しさん
07/02/02 16:54:16
ThreadLocalって便利だよな。気をつけないと乱用してしまいそうだ。
61:46
07/02/02 20:12:05
>>58
まさにその状態です。＋ログイン済みならtrueを返すメソッドがあります。画面遷移毎に呼ばれるそうです。
で、私のやることはUserDaoを実装して、id,passwordをチェックして、正しければなんからかの形でログインしている状態を保持します。
いろいろ調べてみたのですが、HttpSessionを取得してBooleanかなんかで保持するのが一番簡単なのではと思いました｡
ちなみにまだ解決してません。。。
ThreadLocalを調べてみます。
62:デフォルトの名無しさん
07/02/02 20:57:02
設計がおかし・・・
63:デフォルトの名無しさん
07/02/02 20:58:19
LoginServiceはAction(Page)で使用してるんじゃないの？
サービスから取得したUserインスタンスをAction(Page)で保存させて
Filterでチェックが筋だと思うけど
あとBooleanで保持してるだけだとログインしているUserIdはどうやって
取ればいいのでしょうか？って俺速攻聞くよ
64:デフォルトの名無しさん
07/02/02 21:08:15
とーしろにAnA実装させるなんて怖いシステムになりそうだなｗｗｗ
65:デフォルトの名無しさん
07/02/02 21:37:36
spring2入門を参照しながらacegiでやればいいじゃない
66:デフォルトの名無しさん
07/02/02 22:08:28
ThreadLocal 使ってウハウハと思いきや
サーブレットコンテナでスレッドの使い回しがされてて
なんかうまく動かねーやとか言うわけだ。
67:デフォルトの名無しさん
07/02/02 22:11:56
>>46の話聞く限り、設計おかしいよね…。
68:デフォルトの名無しさん
07/02/02 22:15:03
おかしいかどうかでなくていみわかんね
69:デフォルトの名無しさん
07/02/02 22:16:57
Webアプリだとは一言も言ってないのに話が通じてるのが恐ろしい。
確定したのは61でHttpSessionと書いてからだ。
質問以前の何かが欠けてる。
70:デフォルトの名無しさん
07/02/02 22:58:21
まぁ、活気のないスレに書き込みがあるだけで俺は楽しいわけで。
Springの参考書にWebアプリのサンプル載ってたが、ログイン処理も載ってるかもよ。
71:デフォルトの名無しさん
07/02/03 00:17:40
ここでまともな会話求めるほうがおか・・・
72:デフォルトの名無しさん
07/02/03 00:57:19
>>66
その場合はspring自体もｗ
73:デフォルトの名無しさん
07/02/03 10:05:29
よし
Spring勉強しよ
74:デフォルトの名無しさん
07/02/03 10:07:11
>>73
一緒にべんきょしよ♪
75:デフォルトの名無しさん
07/02/03 19:30:35
だがお断りだ
76:デフォルトの名無しさん
07/02/04 15:25:25
勉強とかぬかしてる時点で負けｗｗｗ
77:デフォルトの名無しさん
07/02/04 21:35:23
Spring導入してるとこって少ないのか?
78:デフォルトの名無しさん
07/02/04 22:55:57
まだ少ないとは思う。案件で使うにはそれなりに使える、アーキがわかってるやつがいないと地獄みるからな。
一度暴走すると保守できなくなるし。
Strutsの時もそうだった。
79:デフォルトの名無しさん
07/02/04 23:52:30
少ないことないよ。
新規の案件でSpring使わないところは、はっきりいって単に「ついていけてない」ことを意味する段階に入っている。
（もちろん「敢えて」使わないことを選択できる技術力が高いところは除いて、の話だが。）
80:デフォルトの名無しさん
07/02/04 23:54:37
人員の自転車操業ばっかしてる業界だから
「質が安定しない」のがFrameworkがStrutsに偏る理由。
81:デフォルトの名無しさん
07/02/05 00:12:30
Web層のフレームワークは未だにStruts使ってるところは多いだろうなってのは同意するとして、
＞「質が安定しない」のが
が良く分からん。
82:デフォルトの名無しさん
07/02/05 00:30:30
毎度毎度フレームワークの使い方から覚える奴でなりたってるから
83:デフォルトの名無しさん
07/02/05 00:54:33
フレームワークの使い方云々より日本語の使い方を覚える必要がありそうだな
84:デフォルトの名無しさん
07/02/05 00:56:15
おまえが？話がかみ合わないなら無駄なレスせんでええ。
85:デフォルトの名無しさん
07/02/05 01:00:46
かなりカチンときたようだな ( ´,_ゝ｀)ﾌﾟｯ
86:デフォルトの名無しさん
07/02/05 12:28:00
そもそも>>77のネタフリから
>>80で突如Web層の話になる理由が分からん。
87:デフォルトの名無しさん
07/02/05 23:22:13
seasarのほうが使われているのかね？
88:デフォルトの名無しさん
07/02/05 23:29:14
日本でもSpringの方が多いんじゃない？
89:デフォルトの名無しさん
07/02/05 23:31:45
シーさースレ見る限りあまり使わんほうがいい気がするなしーさーは
90:デフォルトの名無しさん
07/02/05 23:47:45
それでもS2Daoは良いものだという話だ。
Sesarスレはまぁ一昔前のRubyスレがあんな感じだったじゃない。
日本語プロダクトはいろいろな人が湧くんだよ。
いい意味でも悪い意味でも。
久しぶりにSpring1.1.xのプロジェクトをメンテして
<property name="hoge" ref="fuga"/>
が動かなくて小一時間無駄にした。
1.2.xになるまでは
<property name="hoge">
<ref bean="fuga"/>
</proerty>
と書くことに気がついたときは泣きそうになった。
91:デフォルトの名無しさん
07/02/06 01:43:59
Spring Lint使えばすぐに教えてくれたのにね☆
92:デフォルトの名無しさん
07/02/06 15:41:48
俺の回りでは断然springの方が多いな。
また、俺の回りではDI使ってないプロジェクトの方が断然多いなｗ
93:デフォルトの名無しさん
07/02/06 16:18:58
これはあくまで印象（というかむしろ偏見）だが、
Seasarは同じ日本人が作ってるからかファウンデーション内のごたごた感が気になってしまって、
「プロダクトまでグダグダ・仕様が右に左にフラフラ」という印象になってしまった。
実際そうなのかどうかは問題じゃなくて、
俺個人がそう思い込んでしまったんだから、この不信感はどうしようもない。
とりあえず、Springはトランザションマネージャが気になってしまう。
まぁ、単一DBしか接続しないなら全く問題ないんだけどね。
94:デフォルトの名無しさん
07/02/06 18:07:13
Hibernate3 が出た頃、Transaction Manager 絡みで
Spring と Hibernate の両コミュニティがやや険悪になってた気がする。
95:デフォルトの名無しさん
07/02/06 19:55:37
国産プロダクトだからって使いやすいかっていうとそうでもない。
俺は基本的に日本人が作ったもの信用してないからどうしてもSpringを使ってしまうんだよ。
96:デフォルトの名無しさん
07/02/07 07:19:41
開発者の国籍なんてどうでもいい。
重要なのはその道具が俺にとって役立つかどうかだ。
97:デフォルトの名無しさん
07/02/07 07:22:00
>>96
と朝から2chやるような使えない奴が言っています
98:デフォルトの名無しさん
07/02/07 07:29:57
>>97
7:22って朝だよね？ｗｗｗ
99:デフォルトの名無しさん
07/02/07 07:42:35
>>98
ゆとりか？
100:デフォルトの名無しさん
07/02/07 07:56:26
またいみふな奴が出てきた
springが普及し始めたということか？
101:デフォルトの名無しさん
07/02/07 10:09:59
>>99
何が言いたい？
102:デフォルトの名無しさん
07/02/07 11:52:42
> 普及し始めたということか？
知名度は上がってきてる。
ただ実際の使用はまだ限定的だねえ。
予算握ってるオッサン連中説得するのが大変だもん。
ていうか絶望的に不可能な場合が多数。
103:デフォルトの名無しさん
07/02/07 11:56:38
現実は厳しいのねん。
104:デフォルトの名無しさん
07/02/07 12:00:15
ORMやWebフレームワークは、その必要性が明確なんだよな。
「使わなければぐちゃぐちゃになる。使わなくても結局スクラッチすることになる。」
DIコンテナは「使わなくても出来るけど」が説明についてくる。
105:デフォルトの名無しさん
07/02/07 12:02:45
AOPによる宣言的トランザクションあたりは説得材料にならないか？
バグが減る・使わないとぐちゃぐちゃになるとかなんとか言って。
106:デフォルトの名無しさん
07/02/07 12:07:36
短期的に見れば、宣言的トランザクションはDI&AOP導入の大きな魅力になるからね。
ただ、それを頭の固いオヤジに理解させるのが一苦労ｗ
107:デフォルトの名無しさん
07/02/07 12:45:19
宣言トランザクションを理解させる段で諦める
108:デフォルトの名無しさん
07/02/07 12:50:01
>AOPによる宣言的トランザクションあたりは説得材料にならないか？
かな～りなる気がする。
結局は以下を責任を持って実施できるかどうかじゃない？
・Spring導入に関するメリットを上司に説明できる。
・Springについては実開発で使えるくらい検証済みである(もちろんテスト工程も含む)。
・メンバへの教育も問題ない。
・Spring導入したことによる問題は自分が全責任を負うと公言できる。
これができないなら上司を説得するのは難しいだろうし、
Spring導入しても失敗するだけかも？
上記をやっても納得してもらえないなら、上司の頭が余程固いか自分がまだ信頼されるようなエンジニアではないのどちらかでは？
109:デフォルトの名無しさん
07/02/07 14:09:30
「new がないんだが？」
「setter 書いとけばコンテナが勝手にやってくれますよ。」
「でも new ないんだよ？」
「設定に従ってコンテナが勝手に探し出して set しますから。」
「でも設定面倒じゃね？」
「その分 new が減ってますから。」
「でも面倒だよね？」
「その変わり設定変えるだけで実装を切り替えられますから。」
「実装なんて切り替える必要ないだろ？」 ←この辺りからおかしくなる
「単体テストの時にモック差し替えていろいろ試したりとか、
問題調査の時にデバッグ版に切り替えたりとか、結構便利ですよ。」
「モック差し替えって・・・リリース時と違う状態でテストすんのか？」 ←そもそもブラックボックステストを理解してない
「・・・？ そうですけど。」
「馬鹿なこと言っちゃいかんよ、君。リリースと同じじゃなきゃテストにならんだろ！」
「いや、だから単体テストだからインターフェースさえ守ってればそこは・・・」
「いかん、いかんぞ、これは。今までそんないい加減に仕事していたのか！」
「の入り口と出口さえ厳密に決まってれば、中身なんてどうでもいいじゃないですか。」 ←やや誤解される表現
「どうでもいいとはなんだ！そもそもプログラミングと言うものはだな云々」 ←大昔を語りだす
※ このやり取りはフィクションであり、実在の上司・オッサンとは一切関係がありません。
110:デフォルトの名無しさん
07/02/07 14:29:28
部下の発言が説得力ないねｗ
111:デフォルトの名無しさん
07/02/07 14:56:26
図解入りでプレゼン資料提示したり
実際に架空案件でも開発して工数比較したりしないと
新しいツールなんてそう簡単に導入に持ち込めないでしょ。
でもそんなことやってる時間は普通無い罠。
結局デカいベンダのそういうおもちゃで遊んでる部門からでも話が流れてくるのを松鹿内。
112:デフォルトの名無しさん
07/02/07 15:13:40
>新しいツールなんてそう簡単に導入に持ち込めないでしょ。
そういうこと。
個人の力でできる人もいるだろうけど、難しい人もいるだろうね。
いずれにせよ、行動しなければ松鹿内。
113:デフォルトの名無しさん
07/02/07 15:29:22
ソフトウェアアーキテクチャを握っていない立場なら確かに松鹿内なｗ
そうでないならプロジェクトにSpringを新規導入できるだけのアーキテクトがいるかどうかだろ？
そんな人材がいなければ残念ってこと。
Seasar導入できるアーキテクトでもよくてよｗ
114:デフォルトの名無しさん
07/02/07 15:32:30
>でもそんなことやってる時間は普通無い罠。
>>111の会社ではアーキテクトはあまり評価されてないんだろうなｗｗｗ
115:デフォルトの名無しさん
07/02/07 16:01:29
なんで個人攻撃しようとするかなｗ
アーキテクトなんて職種は中小ベンダじゃほとんどいないでしょ。
俺はツール売り込んでる方の人間だから悩みはいっしょなのよね。
最近は昔みたいに
「生産性上げたら人月取れなくなるからツールなどいらん」
っていう豪快な管理者がめっきりいなくなったけどね。
116:デフォルトの名無しさん
07/02/07 16:36:59
アーキテクトなんて肩書きがあるケースは少ないだろうけど、中小企業でもプロジェクトでアークテクチャを担当しなければならいケースは少なくはないでしょ。
そういった立場の奴がプライベートな時間を使ってまで新規ツールの検証をするかどうか。
現状がかなりひどいか、新し好きものの変態じゃなければしないだろうな。
どうぜ評価は変わらないのだろうから。
117:デフォルトの名無しさん
07/02/07 17:09:54
名刺の肩書きで「アーキテクト」は見たことないなｗ
中小だと、アーキテクチャは天の声で指定されることが多いんだよ。
俺「XXXフレームワーク使って良いですか？」
発注元「実績がないので駄目です。」
118:デフォルトの名無しさん
07/02/07 18:27:47
>>116
> プライベートな時間を使ってまで新規ツールの検証
この時点で「アーキテクチャを担当」とは言えないのでは。
>>117の言うとおり、「天の声」で決まるケースがほとんどでしょう。
で、それは>>111の言う「遊んでる部門」に決定権があったりすると。
119:デフォルトの名無しさん
07/02/08 00:26:39
Spring導入するくらいで、いちいち聞かなきゃよくね？
120:デフォルトの名無しさん
07/02/08 09:32:10
勇者あらわる。
121:デフォルトの名無しさん
07/02/08 10:48:15
言い訳なんて何でもよくね？
「DIコンテナ入れない場合UnitTest出来ないですけど、それでいいですか？」
「APサーバのリファレンスに、Springを使用しろと書いてありますが。」
122:デフォルトの名無しさん
07/02/08 11:41:45
豪胆だなｗ
俺は嘘ついてまで導入させようとする勇気はないなぁ…
UTできないわけでも、APサーバが求めてるわけでもないってことが、もし後でばれたら…
123:デフォルトの名無しさん
07/02/08 17:12:01
そんなことチマチマ調べる管理職にお目にかかったことがないので、
ばれない
顧客のためになることだから、独断でガンガン行くべし
124:デフォルトの名無しさん
07/02/08 21:41:17
StrutsやHibernateとかの必須ライブラリとか言っておけばいいんじゃね？ｗ
125:デフォルトの名無しさん
07/02/09 00:13:50
>>122
まるっきりの嘘でもないでしょ。
というか、良かれと思ってやってるのに「勇気がない」って。。
126:デフォルトの名無しさん
07/02/09 00:15:30
もし失敗したら責任取らないといけないからだろ。
127:デフォルトの名無しさん
07/02/09 00:24:22
大抵のことはよかれと思って始められるが、その結果が常によいとは限らない。
128:デフォルトの名無しさん
07/02/09 00:44:27
っていうかさ、必要なモノを作らずに利用するってだけじゃん。
そういうアプローチで説得していけばいいんじゃね？
129:デフォルトの名無しさん
07/02/09 01:31:41
自分以外にもSpringを使える奴がいないと難しいかもナ。
あとあと改修とか保守とか考えると
130:デフォルトの名無しさん
07/02/09 01:59:44
基本的な機能つかうだけならものすごく簡単だとおもうんだけど。。
struts-configを読めて、bean定義の読み方わからない奴なんていないとおもうぞ。
131:デフォルトの名無しさん
07/02/09 02:13:58
>>129
それはその時に担当が勉強・・・って考え方は駄目かなｗ
132:デフォルトの名無しさん
07/02/09 08:11:51
>>131
駄目に決まってんだろ。突然トラブったらどうすんだよ。「勉強中なので対応できません」？
133:デフォルトの名無しさん
07/02/09 10:36:46
DIコンテナ部分だけ使ってる限りにおいては
勉強とか一瞬だと思うんだが。
134:デフォルトの名無しさん
07/02/09 10:50:00
>>125
＞「DIコンテナ入れない場合UnitTest出来ないですけど、それでいいですか？」
POJOだけで作ってれば、DIじゃなくてもUTは出来る。
モック作るのが面倒かもしれんが、出来ないわけじゃない。
＞「APサーバのリファレンスに、Springを使用しろと書いてありますが。」
俺は、リファレンスに「Spring使わなければ駄目」って書かれてるAPサーバを知らない。
Spring必須のSPサーバってのがあるの？
135:134orz
07/02/09 10:50:58
×Spring必須のSPサーバってのがあるの？
○Spring必須のAPサーバってのがあるの？
136:デフォルトの名無しさん
07/02/09 11:16:53
>>134
そういうことじゃなくて、
よくわかってない連中をそうやって言いくるめちまえ！ってことだろ。
真に受けるなよ。コミュニケーション能力のない奴だな。
137:デフォルトの名無しさん
07/02/09 11:54:16
まるっきり嘘じゃねぇか。
138:デフォルトの名無しさん
07/02/09 12:10:29
でも少しずつ広まりつつあるのは感じられるなあ。
DIなんて知らね
↓
DIの良さがわからね ← 半年前のこのスレでこんな奴がいた
↓
導入しようとしたら拒否られた ← 今ここ
↓
普通使ってるでしょ
↓
DI古すぎ。これからはアレの時代。
139:デフォルトの名無しさん
07/02/09 13:48:07
確かに。
大手SIerなんかは、Springベースの自社フレームワーク作ってるところ多いんじゃないかな。
ただ、現場の部課長に「フリー（オープンソース）のソフトなんか信用ならねぇ」とか拒否ってるのがいたりする。
140:デフォルトの名無しさん
07/02/09 13:59:01
>>139
一昔前にStrutsがはやり始めたとき、大手SIerにはOSSを忌避して、
自社独自のWebフレームワークをスクラッチしたところが少なくなかったよな～
結局、フレームワークのバージョンアップコストと、
（極端な例え話だが）アウトソーシングするたびに教育が必要になるから、
Strutsベースで作り直すトコが出始めた。
だが、途中からでもOSSベースに乗り換えたトコはましだった。
いまだに自社フレームワーク使ってるところは、バージョンアップがままならないばかりか、
好き勝手に拡張されたフレームワークを使ってる。
だから別の部門に移ると、同じフレームワークと思えないほど変形してることすらある。
もう、そろそろ学習しろよと思うんだよな。
141:デフォルトの名無しさん
07/02/09 14:08:01
>>136みたいなやつがリーダーのプロジェクトって
ほとんど火を吹くんだよな。最新技術オタク。
142:デフォルトの名無しさん
07/02/09 14:24:07
>>141
そういう話をしてるんじゃないだろ。話がずれてる。
むしろおまえみたいに叩くのが目的で
ずれた議論をしたがる奴がいるほうが迷惑。
火は吹くんじゃなくて、噴くんだよw
143:デフォルトの名無しさん
07/02/09 14:28:35
>まるっきりの嘘でもないでしょ。
がなければ、話の筋は通ったんだがな。
これでは知識不足にしか思えん。
144:デフォルトの名無しさん
07/02/09 14:28:38
要するに、冗談も通じずに叩きネタばかりつっこむ奴がいるとやっかいということか。
145:デフォルトの名無しさん
07/02/09 14:30:51
>>143
ホントだｗ
嘘も方便ってことなのに。
だから>>141みたいな粘着が沸いてきちゃうんだよｗ
146:デフォルトの名無しさん
07/02/09 15:12:14
自分は中小企業をいくつか経験しているが、
ここ読んでいると自分はかなり恵まれているのだと実感したｗ
給料はそんなに高くないけど、責任を負う気持ちがあればチャレンジできる環境に多謝。
147:デフォルトの名無しさん
07/02/09 15:13:36
>>146
ちょっとｳﾗﾔﾏｼｽ。
まぁ、何の責任も無しに高給貰うほうがうれしいけどなｗｗｗ
148:デフォルトの名無しさん
07/02/09 15:21:06
>何の責任も無しに高給貰うほうがうれしいけどな
確かにｗ
>ちょっとｳﾗﾔﾏｼｽ。
弊社に是非。
今ならStruts, Spring2, JPAプロジェクトにすぐにアサインですよｗ
149:デフォルトの名無しさん
07/02/09 16:53:54
ごめん。今更Strutsなんて使いたくないんだ。
と、>>147でない俺が答えてみる。
150:デフォルトの名無しさん
07/02/09 17:07:07
では、Web framework 何使ってるの？
151:デフォルトの名無しさん
07/02/09 17:13:03
んー、Strutsは要件次第ではまだいけると思うんだ。
なによりも成熟してるし実績が無数にある。
JSF・リッチ・テンプレ系は強力だし、
いつでも使えるといいんだけど人的リソースの確保がなかなか…
152:デフォルトの名無しさん
07/02/09 17:15:29
>>151
同意
153:デフォルトの名無しさん
07/02/09 17:20:00
>>149だけど、Wicket使ってるよ。
設定ファイルを書かなくていいからもう他のは使えない体だ・・・
でも、結局Spring使ってるからXMLは書くんだけどなｗ
154:デフォルトの名無しさん
07/02/09 18:25:21
最近よく耳にするWicketかあ。
プロジェクトの規模は何人くらい？
数名とか小規模なんだよね？
155:デフォルトの名無しさん
07/02/09 21:17:52
Viewは使いどころにもよると思うが、今はStrutsだろな。
JSFは開発する側はラクだが、使う側からしたら微妙に思う。
Wicketはまだ開発者集めれる段階ではない。
>「フリー（オープンソース）のソフトなんか信用ならねぇ」
こういうの言われるといつも思うんだが、自社製ソフトも信用ならねぇ。バグだらけ。
とつくづく思う。
新規に作ったほうが工数がかかり、多くのバグを仕込むことになることにやつらは気付かないのか？
156:デフォルトの名無しさん
07/02/09 22:49:45
作るやつと作らせるやつの感覚が違うのが問題
自分が作るつもりで考えないと生産性なんて
得られないおー
157:デフォルトの名無しさん
07/02/09 23:55:57
バグの無いプロダクトなんて無いからな。
管理職の考えてるのは「落とし前のつけ方」なんだよね。
フリーでいいソフトありますー採用しましたー失敗しましたー
ってなったときに部下に責任なすりつけて逃げていいんなら採用できるけど。
158:デフォルトの名無しさん
07/02/10 00:25:40
そういっていまだにＣ言語やってそう
159:デフォルトの名無しさん
07/02/10 07:32:34
>>158
Ｃ言語って何？
おじさん世代？
160:デフォルトの名無しさん
07/02/10 11:14:20
知ったかぶったガキンチョかｗ
161:デフォルトの名無しさん
07/02/10 11:39:34
会社じゃポジションがないおっさんかｗｗｗ
162:デフォルトの名無しさん
07/02/10 15:39:26
いまさらながら>>125について解説しておくと、
[UnitTestの件]
UnitTestするにはPOJOで実装する必要がある。
↓
DIなしでPOJOをアセンブルするにはファクトリが必要
↓
ファクトリなんか書くはずない。めんどくさすぎ。
↓
newしまくりで実装
↓
最下層のクラスがコンテナとくっつく
↓
テスト不能
[APサーバの件]
WebLogicのトランザクションを使用
↓
WebLogicはネストトランザクションを未サポート
↓
「WebLogic ネストトランザクション」で検索
↓
dev2dev内のページがヒット
↓
dev2dev「Springのトランザクションマネージャで出来るよ。」
163:デフォルトの名無しさん
07/02/10 15:57:58
>>162
すれが活発なのはいいけど、ばかがふえた?
UnitTestするには多くの場合、POJOが望ましいが
POJOである必要はない。
何らかの手段で依存オブジェクトを交換できるように
なっていないPOJOだとテストはやりづらい。
ネストしたトランザクションなんかほとんど使わないよ。
必要だと思っても処理を見直せば何とかなる。
164:デフォルトの名無しさん
07/02/10 16:03:51
>>162
んなことわかってるけど、上司にどう言い訳するかってはなし
165:164
07/02/10 16:04:54
ごめん
>>162じゃなくて
>>163
166:デフォルトの名無しさん
07/02/10 17:01:19
素朴に疑問なんだけど、Spring使って開発楽になった人っている？
キレイになったとか、テスト用意だったとかじゃなく、あくまで結果楽になった人。
167:デフォルトの名無しさん
07/02/10 17:01:50
ていしえ：テスト容易
168:デフォルトの名無しさん
07/02/10 17:18:54
まだまだチーム全体で経験不足なので、楽になったとは言えない。ただ、可読性とかはあがったと思う。
トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
トランザクションの設定はわかるやつが統率して更新したほうがいいよ。
新しいこととか流行の物を使わせるとモチベーションが上がるやつもいる。
そういうやつはそこそこ使えるからいいけど、なんで新しいものおぼえなｋｙ（ｒｙってやつには不評だね。
前者 -> メリットとか関係なく新しいものがつかればいい
後者 -> メリットとか関係なく勉強するのがやだ
俺も年取ると後者になるんだろうなぁ。今はちょうど中間にいるってかんじ。
Ajax系のライブラリも乱立するし、SpringMVCだとか余計なのもでてくるし、次から次へと新しいのがでてくることに飽きたというかうんざりというか。
169:デフォルトの名無しさん
07/02/10 17:33:04
.NETにようこそ
170:デフォルトの名無しさん
07/02/10 18:02:24
>>168
Seasarにいらっしゃ～い（三枝風）
171:デフォルトの名無しさん
07/02/10 18:06:50
>>168 に近い感覚。
172:デフォルトの名無しさん
07/02/10 18:07:22
工エェェェ（´д｀）ェェェエ工
173:デフォルトの名無しさん
07/02/10 19:05:52
昨年末に買ったSpring2.0入門やっと読破したｗ
いいねこの本
174:デフォルトの名無しさん
07/02/10 19:09:12
>>173
だんな乙
なんて言わないですよ
だってここはSeasarスレではないのですからｗ
175:166
07/02/10 19:25:44
>>168
なるほどねぇ。
いやぁ、私もSpring使った開発に足つっこんじゃってて。
正直、使う前に予測してた弊害にモロにやられてるから。
ノウハウが足りないってのもあるけろ。
改めて思うのは、DI自体にそこまで価値あるのかしらっていう。
>>トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
激しく同意だけど、これってAOP的要素なんだよね。
オブジェクトの疎結合によるメリットはまだイマイチ感じれないなぁ。
176:デフォルトの名無しさん
07/02/10 20:21:51
ただ導入すればメリットをえられると思っている単細胞には、ﾅﾆを使ってもメリットは得られないだろうねぇ
そういうヤツは何も考えずにゴリゴリ書いてガッツリ結合したプログラムを、またゴリゴリメンテナンスするのが
日常だから、考えてプログラム作ること自体がデメリットになっちゃうんだよね
そういう奴らが主導権を握ったプロジェクトだと、こっちまで巻き添えくうから困る
177:デフォルトの名無しさん
07/02/10 20:23:19
>>175
使う前に予測してた弊害って何？
178:デフォルトの名無しさん
07/02/10 20:38:13
疎結合そのものにメリット感じられないなら
DI使ったプロジェクトには来ないで欲しいよ・・
179:デフォルトの名無しさん
07/02/10 20:39:20
って言うか、オブジェクト指向言語使った開発全般に（ｒｙ
180:デフォルトの名無しさん
07/02/10 20:41:44
>>175
まずは依存関係逆転の原則でググれ。
181:デフォルトの名無しさん
07/02/10 20:43:54
>>175
>> 激しく同意だけど、これってAOP的要素なんだよね。
そうなんだよね。AOPを使ってトランザクション制御を書かなくていいんだ！ってのは理解してもらえるんだよ。
try,catch,finally close()とかはみんな煩わしいと思ってるし。
問題はDIの部分なんだよね。
setterインジェクションでDaoとか渡さなくても自分でnewすればいいじゃんてなる。
やれInterface書くのめんどくさくないの？とかsetter書くのがめんどいだのいうわけよ。
Daoなんか1個実装すれば終わりだし、ORMが途中で変わるわけないだろとか。
うちの人間は極端にリソースが増えるのを嫌がるからなぁｗ わからなくもないんだけどね。
182:デフォルトの名無しさん
07/02/10 20:45:07
Interface書くのがめんどくさいとかいうヤツは
コボルでもやってりゃいいんだよ
183:デフォルトの名無しさん
07/02/10 20:46:26
>>181
そういう奴らの方がよっぽどめんどくさい事を一生懸命やっているっていう事実を
当人達が気が付いていないのが笑える
184:デフォルトの名無しさん
07/02/10 20:46:53
>>181
自分でnewして良いかどうか、
JUnitでテストケースかいてみりゃ一発でわかるだろ。
185:デフォルトの名無しさん
07/02/10 20:53:15
PGレベルのやつはspring意識しなくて良いから「勉強ダルい」なんてことはないと思われ。
上でもあるが、トランザクションやログなど、アプリケーションの動作をプログラムから排除することで、
オブジェクト指向設計したメソッド呼び出しのみに注力することができるので見通しが良くなる。
186:デフォルトの名無しさん
07/02/10 21:07:56
蜜結合大好きならスクリプト言語の世界へどうぞ。
187:デフォルトの名無しさん
07/02/10 21:44:14
宣言的トランザクションを利用する場合も
TransactionManager, DataSourceなどをBean定義ファイルで設定してるよね？
あれってDIだよね？ｗ
これはkiddingだけど、
DIの価値がよくわからなければnewすることからはじめてもいいのでは？
それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
一気にモジュールを作成してUnit Testをせずに
結合して単体テストするという文化ではnewでいけるのかも？
188:デフォルトの名無しさん
07/02/10 22:21:29
飲み過ぎだろ・・・常識的に考えてｗｗｗ
189:デフォルトの名無しさん
07/02/10 22:22:41
誤爆しましたｗ
190:デフォルトの名無しさん
07/02/10 23:37:41
あなたの常識って何ですか？東国原
191:デフォルトの名無しさん
07/02/10 23:53:40
＞DIの価値がよくわからなければnewすることからはじめてもいいのでは？
＞それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
単に、問題の存在に気づかないだけだとおもう。
192:デフォルトの名無しさん
07/02/11 00:07:00
かもなｗ
193:デフォルトの名無しさん
07/02/11 00:08:26
>>191
問題って何？
194:デフォルトの名無しさん
07/02/11 00:20:52
理解力不足と、そう思われるのがイヤで
難癖付けるヤツ
195:デフォルトの名無しさん
07/02/11 00:22:42
自分自身のこと？ｗ
196:デフォルトの名無しさん
07/02/11 00:26:03
あと、空気読めないガキ
197:デフォルトの名無しさん
07/02/11 00:26:37
なんか現状に不満みたいだねｗ
198:デフォルトの名無しさん
07/02/11 01:54:09
>>191-197
これがSpringを導入するかしないかで繰り広げられる会話か。
199:166
07/02/11 02:53:16
うあ。大反響だ。
この中で実際開発してる人っているんですよね。
理想論は理解できるけど、どれだけ『体現』してるのかな。
それも個人ではなくプロジェクトとしてね。
ISID内じゃ前からSeasar2不評だよ。
タ ブ ー だ け ど 。
200:デフォルトの名無しさん
07/02/11 03:03:48
>>199
どうでもいいけど、>>175で書いてた、使う前に予測してた弊害って何よ？ｗｗｗ
201:デフォルトの名無しさん
07/02/11 03:04:13
疎結合否定した時点で、真性かネタの二択だよ俺的には。
202:デフォルトの名無しさん
07/02/11 03:05:27
今時DIすらわからんJava開発者は、さっさとRubyあたりに移った方が身のためだと思う
多分Rubyもわからなくて廃業するだろうけどな
203:デフォルトの名無しさん
07/02/11 04:05:38
実際、楽になったといえるような香具師はいないだろうねぇ
Strutsがそうであるように、結局使いこなせなくて大変な思いだけ
が記憶に残ってしまうんだよね
とSpring使ったことないオレがイって見る
204:デフォルトの名無しさん
07/02/11 04:30:32
だからさっさとスクリプト言語でも何でも、簡単な方にいけばいいのに
DI以前のクソソースしか書けないJava開発者が、現場では一番使えない
205:デフォルトの名無しさん
07/02/11 05:27:13
ｸﾝｸﾝ
ﾑﾑｯ！！
ｺ・・・ｺﾚﾊ！！！
206:デフォルトの名無しさん
07/02/11 08:49:34
>>203
とことん楽になったよ。
あとStrutsと比較したらただのアホだから、
人前では決して口にしないように。
DIは(AOPも)パラダイムなんだから。
構造化言語、オブジェクト指向、とかと同列。
進化の方向は「関心ごとを極小にして実装に集中する」で一致してる。
207:デフォルトの名無しさん
07/02/11 10:41:51
>>203
Javaも使いこなせてないみたいだな
208:デフォルトの名無しさん
07/02/11 10:44:20
>>204
人の上に立てないやつ
209:デフォルトの名無しさん
07/02/11 10:47:07
>>199
>ISID内じゃ前からSeasar2不評だよ。
これほんと？(ぁゃιぃ)
不評な理由はなに？
210:デフォルトの名無しさん
07/02/11 11:01:34
なんかさ、
ジャヴァ・スプリング・フレームワーク と
ネギ・スプリング・フィールド って
なんかにてね？
211:デフォルトの名無しさん
07/02/11 11:03:50
ネギ・スプリング・フィールドはおまえにそっくりだな
212:デフォルトの名無しさん
07/02/11 11:59:28
なんか暖冬のせいか、馬鹿がたくさん沸いてでてきてるな
213:デフォルトの名無しさん
07/02/11 12:00:39
>>206-207
そういう意味で比較したんじゃないからｗ
日本語も読めないようなヤツだと大して使いこなせてもいないんだろう
214:デフォルトの名無しさん
07/02/11 12:16:30
必死だなｗｗｗ
215:デフォルトの名無しさん
07/02/11 12:43:38
ネタだと思いたい。
216:デフォルトの名無しさん
07/02/11 12:44:51
>>212
そりゃ、春のフレームワークだからなｗ。 Spring = 春
217:デフォルトの名無しさん
07/02/11 12:53:49
バネもってこい！
218:デフォルトの名無しさん
07/02/11 12:59:28
温泉のフレームワークじゃないの？
219:デフォルトの名無しさん
07/02/11 13:28:49
スプリングフィールドとかって名前の外人さんいそうじゃねｗｗｗ
220:デフォルトの名無しさん
07/02/11 13:34:40
DIの考え方は肯定するがDIの存在は否定するよ。
DI使いこなせるやつは密結合でもちゃっちゃと作れる。
DI理解できないやつは密結合の方が早かったりする。
現実問題として多数の人間が後者なんだよ。
この状況でDIコンテナ導入するのは最適かね。
私が言っていた弊害てそういうこと。
ムキになって噛みついてきてる方々は、普段からあまりDIの良さをわかってもらえず、もどかしい思いをしているのかな。
残念ながら多くのプログラマは君達よりずっと馬鹿。
有識者やセンスある人の内輪で盛り上がり、気付いたらJavaの市場規模は縮小してました なんて平気でおきそうで。
『誰にでも』簡単に、より速く これが理想でしょ。
まあ上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
221:デフォルトの名無しさん
07/02/11 13:42:17
>>220
作業の分担の仕方を変えれば、あっさりうまくいくよ。
旧来式：
・うまい奴が難しい業務
・下手な奴が簡単な業務
DI導入後：
・うまい奴が全業務のインタフェースを切る
・下手な奴はインタフェースを実装する
222:デフォルトの名無しさん
07/02/11 13:55:20
>>221
そのうまい奴がいないでDI導入するプロジェクトが存在する訳だが・・・
223:デフォルトの名無しさん
07/02/11 13:58:16
>>222
それは流石に無謀だろｗ
224:デフォルトの名無しさん
07/02/11 14:08:48
うまい奴がいないプロジェクトはDI導入しようがしまいがこけるでしょｗ
225:デフォルトの名無しさん
07/02/11 14:10:14
自分はわかっていると思っているヤツがいるプロジェクトが一番危ういｗ
226:デフォルトの名無しさん
07/02/11 14:11:41
DIxAOPの宣言的トランザクションや他フレームワークとの連携機能は使いたいが、
DIのメリットが享受できない、理解できない場合は蜜結合すりゃいいんだよ。
227:デフォルトの名無しさん
07/02/11 14:12:16
220は導入主導したやつにうまい奴だと期待されたんだな。
お前は何も悪くない。そいつの目が節穴だっただけだ。
＞上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
こんなのは当たり前にやってることなんだよ、普通なら。
228:デフォルトの名無しさん
07/02/11 14:15:42
>>225
他の奴がわからないと、調べろよとか、
そんな馬鹿な奴らと仕事したくないとか、
俺が５人いたらなとか言う奴がアーキテクチャーを
仕切っていると確かにやばいなｗ
そういう奴は自己中でプロジェクトの成功だとかコストといった観点が抜けてる。
229:デフォルトの名無しさん
07/02/11 14:21:33
>>222だが、
DI導入を推進してすんごいインターフェースきりまくった奴が逃げ出した
残骸見る限り使い方もわかってない様子。
230:デフォルトの名無しさん
07/02/11 14:22:15
>>228
＞他の奴がわからないと、調べろよとか、
＞そんな馬鹿な奴らと仕事したくないとか、
むしろDIコンテナは、雑魚に何らの調査力を期待しないで済むように
デザインされていると感じるが。
231:デフォルトの名無しさん
07/02/11 14:24:00
>>229
何がいいたいかわかんね
232:デフォルトの名無しさん
07/02/11 14:24:47
DIコンテナといったコンテキストの話じゃない
233:デフォルトの名無しさん
07/02/11 14:27:27
>>229
それはDIうんぬんの問題というよりも
そいつが技術的に仕切れる奴じゃなかったという話では？
234:デフォルトの名無しさん
07/02/11 14:33:18
そういう話
235:デフォルトの名無しさん
07/02/11 14:47:11
よし、今からDIとやらをやるぞ。
ところでJavaもプログラム言語も
ほぼ素人の新人なのだが、
勉強すべき用語をリストアップしてくれ！
236:デフォルトの名無しさん
07/02/11 14:51:10
>>235
1. 単一責任の原則（SRP：Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない
2. オープン・クローズドの原則（OCP：Open-Closed Principle） ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていなければならず（オープン：Open）、修正に対しては閉じていなければならない（クローズド：Closed）
3. リスコフの置換原則（LSP：Liskov Substituion Principle） 派生型はその基本型と置換可能でなければならない
4. 依存関係逆転の原則（DIP：Dependency Inversion Principle） a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきであるb. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである
5. インターフェイス分離の原則（ISP：Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない
237:デフォルトの名無しさん
07/02/11 14:53:55
>>235
仕事ならマジ勘弁してくれ
238:デフォルトの名無しさん
07/02/11 14:54:07
SRP、OCP、LSP、DIP、ISP だな？
他に知っておく技術は無いか？
俺は素人だからな。当然基礎的なものから全部だ
239:デフォルトの名無しさん
07/02/11 14:54:46
「人」についての理解が重要です。
240:デフォルトの名無しさん
07/02/11 14:55:42
>>238
それらを習得する過程で必要なものは全て手に入る。心配するな。
241:デフォルトの名無しさん
07/02/11 14:56:38
>>240
その必要なものをすべてリストアップしてくれ！
242:デフォルトの名無しさん
07/02/11 15:05:25
>必要なもの
他の業界への転職
243:デフォルトの名無しさん
07/02/11 15:06:15
明らかにスレ違いだと分って聞きます。すみません。
Spring Frameworkのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
最近のフレームワークは
WebアプリでHTMLやHTMLっぽいテンプレートを
使ってUIを実装する話しばかりで困ります。
244:デフォルトの名無しさん
07/02/11 15:08:23
Spring Frameworkのような仕組み とは？
245:デフォルトの名無しさん
07/02/11 15:10:04
>>243
日本語でおｋ
246:デフォルトの名無しさん
07/02/11 15:14:43
>>244
えぇ、ですからいわゆるウインドウで作りたいのです。
Windows Formsとか、GTKとかQTとか。
247:デフォルトの名無しさん
07/02/11 15:17:15
お前はSpringをなんだと思ってるんだ？
248:デフォルトの名無しさん
07/02/11 15:19:34
もう一度聞く
Spring Frameworkのような仕組み とは？
249:デフォルトの名無しさん
07/02/11 15:21:23
>>243
電子レンジのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
と質問されたら貴方はどう答えますか？
250:デフォルトの名無しさん
07/02/11 15:25:32
Springはよく知らないが
SpringでSwingコンポーネントを構成して、部品をFrameにDIさせて実行すればいいんじゃね？
JFrameが部品だらけでごちゃごちゃになるのは
DIコンテナを使えばある程度綺麗にまとめられる気がする
NetBeansやVEが対応できなさそうだが
251:デフォルトの名無しさん
07/02/11 15:31:54
>>250
NetBeans使った場合コンポーネントのプロパティがDIの定義だと考えるんだ
実際のところインターフェースベースは使い物にならないし複雑にイベントが飛び交うので無理
252:デフォルトの名無しさん
07/02/11 15:37:46
無理？
253:デフォルトの名無しさん
07/02/11 15:41:17
>>251
Component自体が継承前提だし、実装に依存した細かなプロパティを外側から変更したいしで
よく考えれば、たしかにインターフェイスベースは無理がありそうだな
DIでの開発に慣れた後にSwingのソースを読むと、ごちゃごちゃしすぎて嫌になるが
あれはRADで開発するものだと割り切るべきか
254:デフォルトの名無しさん
07/02/11 15:51:03
GUIコンポーネントはプロパティが動的に変わるものだから使えないな
DIってあらかじめ挙動がわかっていて成り立つもの
ただ、GUIコンポーネント単位で使うのではなく、それらを包括した単位で扱うのなら可能
その場合フレーム単位で扱うことになるだろうね
結局はコンポーネントを制御する部分が一番厄介なところなので恩恵はあまりないけど
あとでまるごと作り直したフレームと交換とか出来るようになるのはいいのかもしれない
それでも結局サービスロケータの域からはでないな
おそらくゲームのほうが適用範囲は広いかと
255:220
07/02/11 15:53:50
しーましぇん、ちなみに私は>>166です。
ちなみに>>227 私は開発に加担してるけどコーディングも設計もしてないお。
>>221の言うとおりの役割分担になるんだろうね。
ただ、プロジェクトによって(人員の)質のバラつきがあるからねｗ
>>222の言うような状況は発生するんだな。
上位開発者が上手に作れば>>230の言うことおりってのもわかる。
少数の優秀なプログラマと多数の雑魚でチームが構成されても、そこそこイケそう。
>>雑魚に調査力を期待しないで済む
これねえ。 この状態に持っていけるような技術者以外DIに絡むなってことか。
私には扱えないね。
デューダするかな。
256:デフォルトの名無しさん
07/02/11 16:07:27
>>254
以前作った奴だと getBean 呼びまくりになって
DIでもなんでもなくなっちまったですよ。
そのアプリに適した画面フレームワークを作成した方が
最終的なコストは低く抑えられるし、
変更にもむしろ強いだろうってのがその時得た感触。
画面はやっぱ面倒ですね。
何が面倒って、お客・利用者の目にモロに触れるから
要求の変更速度がやんごとないところ。
257:デフォルトの名無しさん
07/02/11 16:08:25
256はあくまでも画面(ビュー)の話ね。
258:デフォルトの名無しさん
07/02/11 16:18:48
つまりある程度以上の複雑さのものまでしか扱えないってこと？
259:デフォルトの名無しさん
07/02/11 16:19:23
日本語変だなｗ
扱える複雑さに上限があるってこと？
260:デフォルトの名無しさん
07/02/11 16:20:37
どのような物にも・・・(ry
261:デフォルトの名無しさん
07/02/11 16:22:26
つーか・・・C#が無料なのに？DI使いたければS2.netとかもあるのに？デスクトップアプリでjava？
262:デフォルトの名無しさん
07/02/11 16:26:00
LinuxやMacでも動かさないとならないのです
263:デフォルトの名無しさん
07/02/11 16:27:48
あっそ
264:デフォルトの名無しさん
07/02/11 16:29:43
リッチクライアントの最先端に興味がある奴は あぱれっと様のご意見を参考にしろ。
URLﾘﾝｸ(www.atmarkit.co.jp)
265:デフォルトの名無しさん
07/02/11 16:33:30
>>264
吹いたｗｗｗ
266:デフォルトの名無しさん
07/02/11 16:34:01
>>256
お偉いさん相手にすると見た目大事なんだよな
帳票も5mこっちにずらせとかすごい多い
WEBアプリだと多少見た目や操作性が貧弱でもいいけど、
リッチなクライアントだとほんと細かい制御をさせられるから無理
JavaSEにJAX-WSとグループレイアウトが標準搭載されたことでたぶんリッチクライアントははやると見てる
鯖もEJB3はDIコンテナになったし、どのDIプロダクトを使おうがDIは必須の知識にはなるだろうね
そしてそのPOJOで作られたEJB3コンポーネントをJAX-WSですぐに公開が可能
1年前のEJB2.1までとは別次元の開発効率になったな
267:デフォルトの名無しさん
07/02/11 16:36:52
１年前のPOJOでの開発と比べてはどう？
268:デフォルトの名無しさん
07/02/11 16:36:53
Springは細かい仕様変更要求に弱いってこと？
5mだったらこまかくないか
269:デフォルトの名無しさん
07/02/11 16:38:35
>>261
クライアントがWindowsだけならC#でもいいかもしれんけど、Javaのクライアントはかなり作りやすいよ
C#はDelphi時代の古いものという感じが強い
当時はBCBともどもお世話になったけど
C#だって無料なのはへぼい開発環境なやつだけなのは問題
クライアントと鯖とで技術者を2つの言語を扱える人を探すより1つの言語を扱える人を探すほうが楽だしな
>>264
一般人には考えもつかないような斬新なシステム・・・
それにしてもリッチクライアントでのJavaクライアントが多いね
1年前というJAX-RPCが使いにくい時代の割には・・・
270:デフォルトの名無しさん
07/02/11 16:39:42
>5mだったらこまかくないか
ﾜﾛﾀｗ
271:デフォルトの名無しさん
07/02/11 16:41:21
>それにしてもリッチクライアントでのJavaクライアントが多いね
Javaのフォーラムですからｗｗｗ
272:デフォルトの名無しさん
07/02/11 16:47:18
>>267
Spring1.2だったかな
それで開発してたけど結局設定ファイルを書くのが面倒だとか
ビジネスロジックに直接絡まないセッターのコードが邪魔とかいろいろいわれて
なかなかDIは認識してもらえなかったよ
柔軟性のあるサービスロケータとしてしか使ってない感じかな
EJB3でテストプロジェクト動かしてるけど、これだとフィールドインジェクションであることやXML必要としないことで
すんなり使ってもらえてる
プライベートな変数にインジェクションしてくれるのはわかりやすくていいね
Spring2は扱ってないのでなんともいえない
フィールドインジェクション使いたかったらSeasar2＋EJB3アノテーションを使って勉強という手もあるね
273:デフォルトの名無しさん
07/02/11 16:56:26
ほうほう。
俺たちはこれからSpringとEJB3にどう付き合っていけばいいの？
・分散とかSFSBとかを使う必要がある場合はEJB3を使うが、EJB3の機能が特に不要な場合はどちらでもいい？
・EJB3が今後開発の標準になっていく？
・Java Webアプリの大多数はEJB3コンテナを必要としないので、EJB3はあまり普及しない？
・SpringはEJB3とうまく連携していく？
・その他？
識者の方、ご意見よろぴこ
274:デフォルトの名無しさん
07/02/11 16:59:12
Javaは業界全体で迷走中
HibernateがEJBに逆流したあたりから顕著になってきた
275:デフォルトの名無しさん
07/02/11 16:59:36
>>254
>DIってあらかじめ挙動がわかっていて成り立つもの
↑これ本当？
276:デフォルトの名無しさん
07/02/11 17:01:18
ある意味本当でもあるし、ある意味違うとも言える。
>>275
どのようなケースを考えてる？
277:デフォルトの名無しさん
07/02/11 17:07:53
>>272
Spring Annotationという手は？
278:デフォルトの名無しさん
07/02/11 17:12:39
>>276
いや具体的にどうって言うわけじゃないんですけどね。
はっきり言い切ってるから気になったんさ。
279:デフォルトの名無しさん
07/02/11 17:24:58
>>274
HibernateがEntityBeanを乗っ取ったという方が近い
280:デフォルトの名無しさん
07/02/11 17:32:34
>>279
Hibernate微妙じゃない？
HQL廃止すれば、少しは光さすけど。
281:デフォルトの名無しさん
07/02/11 17:37:06
スレ違いだ スマン。
282:デフォルトの名無しさん
07/02/11 17:50:24
>>269
>C#はDelphi時代の古いものという感じが強い
>それにしてもリッチクライアントでのJavaクライアントが多いね
>C#だって無料なのはへぼい開発環境なやつだけなのは問題
>クライアントと鯖とで技術者を2つの言語を扱える人を探すより1つの言語を扱える人を探すほうが楽だしな
色々とすごいな・・・
283:デフォルトの名無しさん
07/02/11 17:56:49
EJB3のコア技術の一つJPAはまず普及する技術だろうね
DBマガジンだっけ？アレでちょうど特集やってるね
HibernateはHibernateEMということでJPAの実装のひとつと思うくらいがちょうどいい
実装はどれもオープンソースだし一長一短だと思うがリファレンス実装になってるTopLinkはわりと素直でいい動きしてる
TopLinkは新人に見えるが歴史は長くJavaが登場する前からあるのも面白い
Java版のTopLinkも登場してから8年くらいたってるんだっけ
まぁリファレンス実装というのがどれだけ強みなのかはTomcatを見れば明らか
そして今JavaEEのリファレンスという位置づけでオープンソースなglassfishが稼働中
glassfishはJavaEE鯖の中では軽量なほうで5秒あればノートでも起動するね
Tomcatで面倒なコネクションプールを定義するくらいならglassfishでやったほうが手っ取り早い
EJB3の利点はJavaEEのコアな技術ということでフリーから商用のさまざまな鯖で動かせるというのがいい
JavaEEが注目されはじめたのはその技術そのものよりオープンソースのAP鯖など環境面での影響があると思う
今までサーブレット/JSPしか注目されなかったけど、Tomcatもフリーでテストする環境がすぐに用意できたという理由はあると思う
284:デフォルトの名無しさん
07/02/11 18:01:39
>>277
コード見たことないのでわからんけど
フィールドインジェクションしてくれるならいいと思う
ただ、Springのプロジェクトって全体的にhibernateにべったりなのがちと気になる
Seasar2もJPA無視なんだっけ？
285:デフォルトの名無しさん
07/02/11 18:17:54
>>259
上限があるのは複雑さじゃなくて、変化の度合い。
画面アプリは朝令暮改の仕様変更なんてザラ。
サービス仕様決めて・・・とかが水泡に帰す。
この場合、何使って作ってもグダグダになるので
逃走の準備をきちんとしとくのが何よりも大事。
286:デフォルトの名無しさん
07/02/11 18:25:19
>>266,283
きしだﾀｿ乙
287:デフォルトの名無しさん
07/02/11 18:56:05
>まぁリファレンス実装というのがどれだけ強みなのかはTomcatを見れば明らか
実例はTomcatだけ？ｗ
JPAがTopLinkよりもHibernateの仕様にかなり近いことを考えると、
Hibernate EMの方が良いのではという考えもあるのでは？ｗ
JPA実装を何するかは様々な観点から検討する必要があり、
プロジェクトによっても採用基準が異なるだろうから
単純に年数だけで決定すると失敗するかも。
288:デフォルトの名無しさん
07/02/11 19:04:23
>>266は岸田たんというよりもたぶん >>3だろｗｗｗ
289:デフォルトの名無しさん
07/02/11 19:11:59
>>284
フィールドインジェクションはしてくれなかったと思う。
>ただ、Springのプロジェクトって全体的に
>hibernateにべったりなのがちと気になる
この感覚は俺にはわからない。
>Seasar2もJPA無視なんだっけ？
Seasar2はJPAをサポートしてるよ。
S2Hibernate-JPA, S2TopLink-JPA, Kuina-Dao。
Kuina-Daoは動的な問い合わせを生成したりするのにかな～り便利。
まだ品質は今一歩かもしれないけどｗ
290:デフォルトの名無しさん
07/02/11 19:17:07
Session Beanの単体テストって簡単にできるの？
俺、昔のEJBの印象が残っててそこが引っ掛かるんだけど。
291:デフォルトの名無しさん
07/02/11 19:23:53
>>290
昔のEJBと同程度のユニットテストしかできないと思っていた方がいい。
過剰な期待は禁物。
つまり、ビジネスメソッドの正常系のみ。
トランザクションやセキュリティロールが絡むとダメダメ。
292:デフォルトの名無しさん
07/02/11 19:23:53
>>288
グループレイアウトやJAX-WSごときでJavaクライアントがはやるなんて
寝言がいえるのはきしだﾀｿしかいない
よって>3もきしだﾀｿ
293:デフォルトの名無しさん
07/02/11 19:24:05
POJOですからｗｗｗ
294:デフォルトの名無しさん
07/02/11 19:24:42
＞よって>3もきしだﾀｿ
なら納得ｗｗｗ
295:デフォルトの名無しさん
07/02/11 19:26:58
>>290
EJBは
Context c = new InitialContext();
(NewInterface) c.lookup("NewInterface");
見たいな感じで取得すればおけ
getBeanとやれることはかわらん
296:デフォルトの名無しさん
07/02/11 19:27:19
>>291
経験に基づいたコメントサンクス
>過剰な期待は禁物。
そっか。
俺はしばらくは Struts + Spring + JPA/iBATIS でいいやｗ
297:デフォルトの名無しさん
07/02/11 19:41:23
>>291
具体的にたのむ。
298:デフォルトの名無しさん
07/02/11 19:43:43
釣れてきましたね～ｗｗｗ
299:デフォルトの名無しさん
07/02/12 02:01:58
>>243
あなたはSpring FrameworkがWebアプリ専用だと思ってますね？
他の人が答えたようにSpring Framework上でSwingアプリを作れます。
Javaでスクラッチ開発より楽にデスクトップアプリを作りたいのなら
スタンドアローンアプリでなくEclipseかNetBeansのプラグインを作れば
典型的処理をFrameworkにまかせてアプリ固有処理に専念できます。
「統合開発環境Eclipseプラグイン開発QA」
ｽﾚﾘﾝｸ(tech板)
WebアプリでHTMLなどでUIを実装するようにデスクトップのUIを実装したい、
という話だったらSynthをどうぞ。
「進歩したSynth」
URLﾘﾝｸ(www-06.ibm.com)
300:デフォルトの名無しさん
07/02/12 02:04:45
そういえばSpring RCPとかあったな。
URLﾘﾝｸ(spring-rich-c.sourceforge.net)
301:デフォルトの名無しさん
07/02/12 02:25:19
swingったってviewが変わっただけだと思うんだが。
302:デフォルトの名無しさん
07/02/12 07:41:59
Swing Application Frameworkってあったな。内容は知らないけど
あれがSwingのView部分を受け持って、ロジック側をSpringが受け持つようになれば
Struts+Springみたいなイメージで使えるようになるだろうか
303:デフォルトの名無しさん
07/02/12 10:31:44
上の方でGUIは無理ぽって言ってるひとがいるじゃん。
304:デフォルトの名無しさん
07/02/12 10:57:44
>>303
そのうちの一人が俺ｗ
305:デフォルトの名無しさん
07/02/12 11:33:01
>>303-304
Ｖｉｅｗと密結合でつか？ｗ
306:デフォルトの名無しさん
07/02/12 11:56:40
View内で完結される話で、ロジック以下を密結合させるわけではない。
Viewから上のレイヤはレイヤ内でよろしくやれってことだ。
307:デフォルトの名無しさん
07/02/12 12:40:04
>Viewから上のレイヤは
サービス層などは上か下かと言えばViewの下のレイヤようなｗ
「Viewから先のレイヤ」の方がまだしっくりくる
308:デフォルトの名無しさん
07/02/12 12:43:06
っていうか、Ｖｉｅｗ内でよろしくならそのＶｉｅｗがＧＵＩだろうがＣＵＩだろうが
ＪＳＰだろうがなんだっていいんじゃねーの？ｗ
309:デフォルトの名無しさん
07/02/12 12:56:25
>>305
View部分には使えない。
それ以外に使おうとするとメリットが少ない。というかほとんどない。
310:デフォルトの名無しさん
07/02/12 13:02:24
>>309
Sptingは、WebアプリのViewを実装する事にしかメリットが得られる使い道が無い
といっている？
311:デフォルトの名無しさん
07/02/12 13:03:27
>>310
ゴメン、間違えたｗ
312:デフォルトの名無しさん
07/02/12 13:09:49
だれもViewでSpringを使いたいという話はしていない件
313:デフォルトの名無しさん
07/02/12 13:10:30
>>310
309ではないが、そんなことは言ってないと思うし、
SpringはWebアプリのViewの実装をサポートするだけではないのは明らか。
314:デフォルトの名無しさん
07/02/12 13:17:39
>>310だけど、>>309を読み間違えましたｗ
「View部分には・・・」と「それ以外・・・」という言葉のつながりが
よくわからん買った
315:デフォルトの名無しさん
07/02/12 13:45:44
この流れ見ててわかるだろ。
無理してSpring使うなｗ
316:デフォルトの名無しさん
07/02/12 13:53:43
>>308
なんだっていいだろ。
何かに限定する話なんぞ誰もしていない。
317:デフォルトの名無しさん
07/02/12 13:57:01
なんでもいいよ
なんにしても大した発言は無いスレだｗ
318:デフォルトの名無しさん
07/02/12 13:59:03
>>317
これこれｗ
だが、「こないだ雑誌にのってたのマンマだな」とかよくあるｗ
319:デフォルトの名無しさん
07/02/12 13:59:21
>>317様
是非仕事に役立つSpringのTipsをご紹介下さい
320:デフォルトの名無しさん
07/02/12 14:00:36
上の方でもDB MagazineのJPA特集読んで知ったかしてた馬鹿がいたなｗ
321:デフォルトの名無しさん
07/02/13 00:29:56
あー、Ｗｅｂ層のフレームワークって何がいいのでしょうか？
お馬鹿な私にはStrutsは難しいです・・・
322:デフォルトの名無しさん
07/02/13 00:36:30
SpringMVC
323:デフォルトの名無しさん
07/02/13 00:40:07
SpringMVCですか・・・
Strutsとあまりかわらないような・・・
そんなことないですか？
324:デフォルトの名無しさん
07/02/13 00:45:50
自作が一番わかりやすいよｗ
325:デフォルトの名無しさん
07/02/13 00:48:55
サンプル見ただけなんですけど、
Clickってわかりやすそうに感じました。
１人プロジェクトならいいんでしょうけどね（苦笑）
326:デフォルトの名無しさん
07/02/13 00:52:02
Springスレなんであれだけど、
もうちょっとしたらSeasarのTeedaがおもしろいと思うよ。
327:デフォルトの名無しさん
07/02/13 01:42:30
SpringMVC (ViweはVelocityが良いと思われ。)
Wicket
Teeda
この辺りが有力株か？
簡単なものは SpringMVC+Velocity でやっつけて
ある程度面倒になったら WebService+RichClient で
ってのが最近の俺のパターン。
328:デフォルトの名無しさん
07/02/13 03:09:24
SpringMVCって戻るボタン、ダブルクリック、マルチウィンドウ対策とかしてくれる？
329:デフォルトの名無しさん
07/02/13 06:59:00
JBoss Seamがいい。
330:デフォルトの名無しさん
07/02/13 09:55:39
>>328
WizardFormController使ったアプリで、
マルチウィンドウ試したら思いっきりデータが上書きされたorz
やり方悪い！？
331:デフォルトの名無しさん
07/02/13 10:38:37
>>328
個人的にはMVCでそんなもんコントロールするなよって思う。
レイヤがそもそも違うじゃねえかと。Viewで勝手にやったらいい。
下位レイヤでサービスしようとするといつか破綻する。
そこまでしてWebアプリにするなってのが本音。
332:デフォルトの名無しさん
07/02/13 11:13:15
>>329-331
コメントとんくす
やっぱりSpringMVC単体で解決してはくれないのねん。
こういった制御コードはもう書きたくないし、
そうなるとTeeda, Seamを選択したくなっちゃうのよねん。
333:デフォルトの名無しさん
07/02/13 11:21:25
>>331
気持ちはわからないでもないが、
何の解決策にもならない。
334:デフォルトの名無しさん
07/02/13 13:09:41
Strutsみたいにトークンの管理をWebフレームワークにさせたいと思うのは自然じゃないか？
が、コードに決まりきったこと書くのはメンドイ。設定ファイルだけでできるとうれしいな。
というかこういうのをAOPで何とかできないのかね？
で、それ以上のこと(ボタンを押せないようにしたいとか)はView(のJavaScript)でやればいいとｵﾓﾀ。
なんか的外れ？
335:デフォルトの名無しさん
07/02/13 13:12:13
>>334
的外れじゃないと思うよ。
その解決策の１つがJBoss Seamだって話。
336:デフォルトの名無しさん
07/02/13 13:16:52
>>335
Teedaも忘れないでね (。-_-。)ポッ
337:デフォルトの名無しさん
07/02/13 13:17:46
おー、そーりー、そーりー
Teeda最高！
Seasar最高！！！
これでよい？ｗ
338:334
07/02/13 13:21:21
>>335
そうなのか。Seamって使ったことないからわからなかった。
ﾄﾝｸｽ。
>>336
URLﾘﾝｸ(www.seasar.org)
これ？
でもスレ違いじゃないかぁ？！ｗ
339:デフォルトの名無しさん
07/02/13 13:38:13
>>338
Seamもスレ違いな件
340:デフォルトの名無しさん
07/02/13 13:46:07
選択肢提示するだけならまぁいいんじゃねえの？
Springの話をここでしかしないわけでもないんだし。
詳細に立ち入るならスレ違いだが。
341:デフォルトの名無しさん
07/02/13 13:52:07
>>339
全くすれ違いというわけではないと思うよ。
だって、Seam使う人はSpringを同時に使うことはたいていないわけで、
「じゃあSpringを使って開発していてSeamと同様の機能を
享受するにはどうしたらいいの？」
っていう話に発展してくれること願って投稿したんだけどねｗ
念のため言っておくけど、HibernateとiBatis、StrutsとJSFのように
SpringとSeamは同列のものだとは思ってないよ。
342:デフォルトの名無しさん
07/02/13 14:02:31
>>341
SeasarのTeedaでは一部Seamを意識しているところがあるよね？
Spring使って開発している場合、
自前で制御コード書いてやってるケースがほとんどじゃない？
Ｗｅｂ特有の問題について全く考慮していない
Ｗｅｂアプリも少なくないと思う。
343:デフォルトの名無しさん
07/02/13 14:09:14
>SeasarのTeedaでは一部Seamを意識しているところがあるよね？
これは俺も感じたｗ
>Spring使って開発している場合、
>自前で制御コード書いてやってるケースがほとんどじゃない？
Springの責任というわけではないというのはいいよね？ｗ
Struts で開発している人ってSpringを導入しても
たいへんなんじゃないかな？
もう体にしみついちゃって不感症状態なのかもしれないけどｗ
344:デフォルトの名無しさん
07/02/13 14:35:44
Struts開発で業務に集中したい場合は、Valentine Frameworkがいいかも
URLﾘﾝｸ(www.valentineframework.org)
345:デフォルトの名無しさん
07/02/13 14:41:07
あれ、バレンタインのつづり違う？
346:デフォルトの名無しさん
07/02/13 15:22:30
SpringMVC自体はあくまでもMVCで
ViewはViewでよろしくやりやがれってスタンスでは？
(Controllerが抽象化されたModelAndViewを返してくるだけ)
347:デフォルトの名無しさん
07/02/13 16:35:35
>>346
それはそれでいいんだけど、
現実問題としてＷｅｂ固有の問題は解決しないといけないよね？
それはViewで解決する問題っていってる？
その場合のViewって具体的に何？
348:デフォルトの名無しさん
07/02/13 16:41:25
Spring2.0入門買いました
すごいいいとおもいました
349:デフォルトの名無しさん
07/02/13 16:44:19
おれもかったよ
著者は印税がっぽがっぽじゃね？
350:デフォルトの名無しさん
07/02/13 16:45:53
>>330
ﾜﾛﾀｗｗｗ
ｵﾚもそうなったｗｗｗ
351:デフォルトの名無しさん
07/02/14 00:16:43
>>348-349
俺もかおっかなー・・・・
352:デフォルトの名無しさん
07/02/14 00:39:06
みんなで買って、はせがわさんをスプリング長者にしてあげよう♪
353:デフォルトの名無しさん
07/02/14 13:03:54
Spring2.0入門Amazonで買ったけど、
Springわかってない俺にはSprng入門が必要だった orz
354:デフォルトの名無しさん
07/02/14 13:57:09
そこで Reference Manual ですよ。
ていうかこれ日本語化してるプロジェクトとかある？
周囲に日本語になってないと読まないやつが多数居て泣ける。
355:デフォルトの名無しさん
07/02/14 14:28:37
>>354
URLﾘﾝｸ(andore.com)
356:デフォルトの名無しさん
07/02/14 17:57:34
>>354
Reference Manual読むのがつらいかたら買ったのに？ｗ
最初はつらかったけど、Spring2.0読んでいくうちにたいぶわかってきた。
なんとかJPAを使ったDao作成までできるようになった。
357:デフォルトの名無しさん
07/02/15 00:57:59
便利だねコレ
358:デフォルトの名無しさん
07/02/15 09:09:37
今日はでぶさみいきまつよ
JSUGのみなたまよろしくでつ
359:デフォルトの名無しさん
07/02/15 22:16:32
コアパッケージ含め、全てのnewをSpring経由にしてみたんだけど・・・
完全にプロジェクト失敗だ。
360:デフォルトの名無しさん
07/02/15 22:28:23
>>359
明らかにおかしい
間違いなくプロジェクトがこけたのはお前のせい
361:デフォルトの名無しさん
07/02/15 22:41:54
StringBuffer とか BigDecimal とかも全部ってことか
362:デフォルトの名無しさん
07/02/15 23:21:24
中庸と言う言葉があってだな
363:デフォルトの名無しさん
07/02/15 23:47:23
使える奴には良い道具を与えよ。
使えない奴にはｒｙ
364:デフォルトの名無しさん
07/02/15 23:51:38
>>359のような馬鹿はすっこんでろ！
お前は定型作業やってりゃいいんだよ
回りを不幸にするな
365:デフォルトの名無しさん
07/02/16 00:21:42
newを全部って、楽しいヤツだな
366:デフォルトの名無しさん
07/02/16 01:51:36
Stringとかどうやったんだろう。
367:デフォルトの名無しさん
07/02/16 23:58:57
>>366
String str = "aaa";
"new"って文字列が出てこないからOK！！
とかw
368:デフォルトの名無しさん
07/02/17 03:27:00
newは世の元凶です
369:デフォルトの名無しさん
07/02/17 03:31:38
さては、コンストラクタがクラスに内包されるのってオブジェクト指向言語自体の設計ミスなんじゃないのかね。
370:359
07/02/17 14:13:51
ネタですたｗ
371:364
07/02/17 16:28:07
ネタだと知っていて罵倒してやりました
すげえ気持ちよかったでつｗｗｗ
372:359
07/02/17 16:53:19
ストレス解消に貢献でき何よりですｗ
373:359
07/02/17 16:53:51
>>369がちょっと興味深いこといったかも。
374:デフォルトの名無しさん
07/02/17 18:04:33
>>359
お前ごときが興味深いだと？
身の程を知れｗｗｗ
興味深いという奴は何も考えてないといってるのと同じｗｗｗ
ちょー気持ちいいーｗｗｗｗｗｗ
375:デフォルトの名無しさん
07/02/17 18:17:34
確かに３５９は頭わるそうだな( ´,_ゝ｀)ﾌﾟｯ
376:デフォルトの名無しさん
07/02/17 19:10:16
>>370
. ｨ
.._ .......､._ _ ／:/l! またまた、ご冗談を
:~""''.>ﾞ' "~ ,､､''‐'､| _
ﾞ､'､::::::ﾉ:::::::_,.-=. _～:、 ／_.}'':,
``､/:::::::::__....,._ `ﾞ'Y' _.ｪ-､....._ ／_ﾞ''iﾞﾉ､ﾉ
,.--l‐''"~..-_'.x-='"ﾞｰ ､`'-､ ,:' ﾉﾞﾉﾌﾞ
" .!-'",／ `'-‐'') /＼ `/ てﾞノ-〈
.-''~ >'ﾞ:: ‐'"ﾞ./ ヽ.,' ~ ／
／/::::: ', / ,:'
377:デフォルトの名無しさん
07/02/17 19:53:21
俺、環境構築（総合テスト＆本番）担当なんだけど、
開発からあがってくるXMLのbeanidがすげー適当で一発で動いたためしがないんだけど
なんかうまいことチェックできるような仕掛けとかないですかね？
378:デフォルトの名無しさん
07/02/17 20:03:53
beanLint
379:デフォルトの名無しさん
07/02/18 21:44:27
チェックのイミがわからんが、Spring IDEだけではだめなの？
380:デフォルトの名無しさん
07/02/19 04:19:54
springのxml helloで死にそうです。
seasarを使うべきでしょうか？
381:某スレ167
07/02/19 17:07:25
……誰も覚えてないコテハン&ちょー遅レスで恐縮だが（笑）
SpringということでなくDIxAOPということでなら、少なくとも今自分が弄ってるEclipse RCPには大いに有用だと思う。
イベントリスナの管理やログ管理オブジェクトの生成の煩雑さには正直ウンザリしてる（苦笑）
（まさに「フレームワーク」として」）アプリケーションの枠組みはEclipse RCP、AOPするための仕組みと割り切ってComposite（SwingだとPanelかな？）の管理にDIxAOPを導入するのはアリだと思う。
……ちなみにPHPもヤる人間なので現在Seasar2で遊んでいるのだが、どーも隔靴掻痒の感が否めん。Springに移行してしまおうかしらん？
一番アテにしていたコンポーネント（Springでは「Bean」かな？の自動登録はEclipse RCPで使えんよーだし。
ただ、それでもS2Daoはスゴいと思う。……ちゃんと動けば（苦笑）
うごかねーだよ、ヒマ見てちょこちょこ動かしてるレベルぢゃ(T_T)
382:デフォルトの名無しさん
07/02/19 22:08:11
なにいいたいのかいみふ
近視眼的で構成力のないコーダーと推測
383:デフォルトの名無しさん
07/02/19 22:15:08
たしかに
384:381
07/02/19 23:24:42
……バレるもんだな、下地の無さは。２ちゃんでもよく考えて書き込まないとボロが出ますな（苦笑
素直に「プレゼンテーション層が変わるだけでビジネス層やプレゼンテーション層は変わらん」と書いてしまえばよかったかな？
ただ、プレゼンテーション層そのものの作り込みにも、意外とDIxAOPが適用できる部分は多いんぢゃね？ と書きたかったんだけど……まぁいいか、またボロが出る前にやめとこう（苦笑
385:デフォルトの名無しさん
07/02/19 23:28:34
>>384
キモイ
386:デフォルトの名無しさん
07/02/19 23:35:52
taglibにインジェクションする仕掛けがSpringに無いのはなんでだろう。
387:デフォルトの名無しさん
07/02/20 00:20:43
キモイ荒らしが来たと聞いてすっ飛んできますた
388:デフォルトの名無しさん
07/02/20 01:44:13
キモイ荒らしが来たと聞いてすっ飛んで通り過ぎます
389:デフォルトの名無しさん
07/02/20 18:32:50
まじきもいな
こんなやつが同じプロジェクトにいなくてよかったよ
まあ、こんなやつがいたら皆で手を組んで出社できなくなるくらい
追い込んじゃうけどねｗｗｗ
390:デフォルトの名無しさん
07/02/20 20:22:03
>>384
天才。
391:381
07/02/20 20:54:34
>>384
あ、typoしてるし（苦笑）
誤：「ビジネス層やプレゼンテーション層は変わらん」
正：「ビジネス層やデータアクセス層は変わらん」
でよろしく。
392:デフォルトの名無しさん
07/02/21 00:12:19
,. -‐ ''" ￣￣ ｀`丶､
i:::::::::::::::::::::::::::::::::::::::::::i |
ｶ ヽ:::_; ‐--､､ ､---､ ;;_:| |
ﾁ `!;{ |ﾄNヽ }.:.:.:| |ヽ' 要
ｶ lf へ、| ､,. へ､ヽ;| | チ
ﾁ ,.-!. <(')' '(')> '=､ | ェ
ｶ .{{〉,| '" , , ` ﾑ }〉 ､ | ッ
ﾁ ／ヾ‐l ,.---､ u i､..ｲ ｀`'| ク
ｶ ,.ィ_" |`''i、 〈ﾖ￣´,〉 / / | や
ﾁ/,ノr:} ヽ ヽ `'三'"／ / ﾑ !!
/ /,.⊥L_ ＼l! ` -‐' / ／ /|
／ / ─‐〈 ｀ヽ､一r''" ! |／￣ !ヽ
r''" .ノ 'ー─〈 ＿＿ -─‐=ﾆ二二) l ／ |
/ （ ､ 二.ﾌ |-ﾆ￣ -─- | | i
393:デフォルトの名無しさん
07/02/21 10:45:03
>>389
俺はそんな暇があったらコード書くよ。
まっとうなフレームワーク作って、個人の作業範囲が明確になるようにする。
それでもついて来れないようなら他のプロジェクトに回ってもらう。
394:デフォルトの名無しさん
07/02/22 03:06:15
>>393
こんなとこ書いてないで手を動かせｗ
395:デフォルトの名無しさん
07/02/22 03:09:42
>>394
おまえ・・・正論すぎると嫌われるぞｗｗｗ
396:デフォルトの名無しさん
07/02/22 10:03:01
wwwって書くバカっぽいwww
397:デフォルトの名無しさん
07/02/24 00:45:13
ビジネスロジックを複数のCommandとして捉え、ChainOfResponsivirityのように次々に呼び出したい。
この設計思想に基づいてSpringを選択するのは正しい？
また、Commandの実行結果によっては次に呼び出すべきCommandが変わる場合もある。
この場合、設定ファイルだけで実現可能？
教えてｴﾛい人
398:デフォルトの名無しさん
07/02/24 00:53:54
Struts
399:デフォルトの名無しさん
07/02/24 00:57:28
>397
spring以前の問題
そんなもん自前でやれ
springは疎結合モジュール間の依存を解決させるためのもの
400:デフォルトの名無しさん
07/02/24 01:00:01
>>397
つ Jakarta Commons Chain
401:デフォルトの名無しさん
07/02/24 01:20:47
>>399,400
サンクス。
DIで上下レイヤー間の粗結合を受け持たせる…って認識でおk？
>>400の言う通りcommons-chainにするわ。
二人ともありがと
402:デフォルトの名無しさん
07/02/24 14:55:12
commons-chainのcommandにinjectionするニーズっていうのは結構あると思うんだけど。
403:デフォルトの名無しさん
07/02/24 15:23:12
5年以上前からこんなしくみつかっとるがな
404:デフォルトの名無しさん
07/02/24 18:58:12
ビジネスロジックは画面単位、イベント単位どんな風に区切るべき？
405:デフォルトの名無しさん
07/02/24 19:09:56
イベント単位じゃ
まだ荒い
406:デフォルトの名無しさん
07/02/24 21:08:32
っていうか１つのビジネスモデル（もしくは更に細かいモデルであったとしても）＝１画面 or １イベントではない
407:デフォルトの名無しさん
07/02/25 05:47:04
>>403
それって自慢？
俺はその前から使ってるがなｗ
408:デフォルトの名無しさん
07/02/25 06:29:27
>>407
それって自慢？
俺はその前から使ってるがなｗ
409:デフォルトの名無しさん
07/02/25 07:37:48
つい画面単位で物を考えてしまうけど、それではうまくいかないかなぁ
410:デフォルトの名無しさん
07/02/25 08:38:51
画面はビジネスモデルのビューなので
大きなくくりのビジネスモデル (1) ← (n) 画面
だけど、イベント単位に考えると、１つのイベントに他のビジネスモデルでも流用可能な
手続きがあったり、そもそも他業務の機能の呼び出しが入ってたりするから、
細かくしておいた方が都合が良いと思うなぁ
業務B画面 Action 業務A 業務B
│ │ | |
├───→.│ ① | |
│ ├──→| ② │
│ ├─────→.│
│← - - - - - - │ | │
① 業務Aで生成されるデータを取得
② ①のデータを使って業務Bの処理を実行
みたいな
411:デフォルトの名無しさん
07/02/25 10:47:59
>>408
それって自慢？
俺はその前から使ってるがなｗ
412:デフォルトの名無しさん
07/02/25 12:52:13
Spring Web Flowってめんどくせえな
413:デフォルトの名無しさん
07/02/25 13:36:03
>>411
それって自慢？
俺はその前から使ってるがなｗ
414:デフォルトの名無しさん
07/02/25 14:07:00
>>413
それって自慢？
俺はその前から使ってるがなｗ
415:デフォルトの名無しさん
07/02/25 14:19:48
>>414
それって自慢？
俺はその前から使ってるがなｗ
416:デフォルトの名無しさん
07/02/25 14:58:52
>>415
それって自慢？
俺はその前から使ってるがなｗ
417:デフォルトの名無しさん
07/02/25 17:40:47
おもしろいとおもってるのか？これだからプログラマーは。
418:デフォルトの名無しさん
07/02/25 18:04:47
合コンで女性陣がポカーンとしてる光景が目に浮かぶなｗ
419:デフォルトの名無しさん
07/02/25 19:02:31
>>41６
それって自慢？
俺はその前から使ってるがなｗ
420:デフォルトの名無しさん
07/02/25 19:34:09
>>419
それって自慢？
俺はその前から使ってるがなｗ
421:デフォルトの名無しさん
07/02/26 04:27:58
>>420
それって自慢？
俺はその前から使ってるがなｗ
422:デフォルトの名無しさん
07/02/26 05:46:40
今度のSpring勉強会で１０分のデモする人ってあっぱれっと殿じゃね？ｗｗｗ
URLﾘﾝｸ(www.atmarkit.co.jp)
勉強会出席して拝見させてもらわなきゃｗｗｗ
もちろんデモじゃなくてあっぱれっと殿をねｗｗｗ
423:デフォルトの名無しさん
07/02/26 10:58:45
Spring勉強会もアッパレット殿とやらも分からん。
424:デフォルトの名無しさん
07/02/27 01:22:45
だああああああああああああああああああああああああああああああああああああああああああああああああああああああああ！！！！！！！！！！
425:デフォルトの名無しさん
07/03/09 01:52:25
SpringMVCはこれから流行ると思うかね？
426:デフォルトの名無しさん
07/03/09 02:18:15
おもわん
427:デフォルトの名無しさん
07/03/09 04:13:32
思います
428:デフォルトの名無しさん
07/03/09 06:36:52
思えば
429:デフォルトの名無しさん
07/03/09 06:53:10
思うとき
430:デフォルトの名無しさん
07/03/09 07:35:44
思え
431:デフォルトの名無しさん
07/03/09 08:57:34
思おう
432:デフォルトの名無しさん
07/03/09 12:39:27
もうWebはいいだろ・・・と思う。
あえてWebで行く時はSpringMVCは悪くない。
433:デフォルトの名無しさん
07/03/09 19:22:45
>もうWebはいいだろ・・・と思う。
はい！消えた！
434:デフォルトの名無しさん
07/03/10 02:33:46
つまんねーなー
435:デフォルトの名無しさん
07/03/10 02:38:16
今日の勉強会レポよろ
436:デフォルトの名無しさん
07/03/10 08:19:06
つURLﾘﾝｸ(d.hatena.ne.jp)
437:デフォルトの名無しさん
07/03/11 11:51:58
>>436
レポート乙
２番目のトーカーに対するツッコミがきついようだが、そんなに納得でけへん内容やったん？
438:デフォルトの名無しさん
07/03/13 22:38:59
URLﾘﾝｸ(code.google.com)
439:デフォルトの名無しさん
07/03/14 05:23:42
これ軽いね
440:デフォルトの名無しさん
07/03/15 04:58:09
super-injectionがいい
441:デフォルトの名無しさん
07/03/18 21:32:16
Springって、netBeansで動くの？
net-sf-springnetbeans-support.nbmをNetBeansにインストールしたけど、この先どうして良いかわからない。
やっぱりエクリプスが良いのかな。
442:デフォルトの名無しさん
07/03/18 22:07:46
Springが動作するのは、IDE上ではなくてJVM上だ。
「Springって、netBeansで動くの？ 」なんて質問は的はずれもいいところ。
443:デフォルトの名無しさん
07/03/18 22:07:51
動かないわけないべ。
eclipseつかえるならとりあえずそっちでやっとけ。何ら問題ないだろ
444:441
07/03/18 22:29:53
>>442-443
とりあえず、ありがとう。
eclipseはプラグイン探しが大変そうなので、敬遠していたけど、All In One Projectがあるので、そっち試してみます。
445:デフォルトの名無しさん
07/03/18 22:45:04
>>444
まぁかまわんが、spring使うときにプラグインなんぞ使ったことないぞ
何の貯めにプラグインがいるんだ？
446:デフォルトの名無しさん
07/03/18 22:50:44
設定ファイル書く時に補完が効けば少し嬉しいんじゃね？くらいだな。
447:デフォルトの名無しさん
07/03/18 22:53:24
このIDEで動きますかと質問をしている時点でプロジェクトの成功はないだろうなぁと思う
448:デフォルトの名無しさん
07/03/18 22:55:34
時代はアノテーション