【DI】Java Spring Framewoｒｋを語るスレ 2.0

【DI】Java Spring Fr ..

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

次ページ