.net と J2ee - 暇つぶし2ch

.net と J2ee ..

175:デフォルトの名無しさん
03/02/19 04:19
BizTalk ってまだやってんの?
アクティブチャンネルはどこ逝ったの?

176:デフォルトの名無しさん
03/02/19 04:19
.NETはSOAP/WSDL/UDDIに絞り込んだしょぼい製品でつか

177:デフォルトの名無しさん
03/02/19 04:20
>>176
M$も他のベンダーも、ワークフロー/トランザクションにも力をいれてるよ

178:デフォルトの名無しさん
03/02/19 04:21
>>175
BizTalkやんならロゼッタネットしてebXMLだよな

179:デフォルトの名無しさん
03/02/19 04:22
>>176
WS-Security / Routing / Attachments にも対応してるよ。

180:デフォルトの名無しさん
03/02/19 04:22
>>147
とりあえずもうCORBAはお終いってこと？
もとからそんなに使われてなさそうだけど。

181:デフォルトの名無しさん
03/02/19 04:24
>>180
EJBはIIOPですが…

182:デフォルトの名無しさん
03/02/19 04:25
>>181
だから腐ってる

183:デフォルトの名無しさん
03/02/19 04:27
>>179
そうそう、Atachments って最近よく名前出てくるけど、どうゆうものですか？

184:デフォルトの名無しさん
03/02/19 04:28
>>182
顧客の囲い込みの為だけに、通信のプロトコルをSOAPベースにするような
腐れた頭の連中の作り出すものよりはマシかと。

185:デフォルトの名無しさん
03/02/19 04:28
>>183
XMLに直接バイナリを貼り付けられる。Base64より効率がよろしい。

186:デフォルトの名無しさん
03/02/19 04:29
>>176
ようするにM$はSOAPなどの独自規格を広めて新たなる独占をしたいっつーことだな。

187:デフォルトの名無しさん
03/02/19 04:29
>>183
URLﾘﾝｸ(msdn.microsoft.com)

188:デフォルトの名無しさん
03/02/19 04:30
>>186
Javaも、SOAP/UDDI/WDSLはJAX-ﾅﾝﾁｬﾗでサポートしているはずだが…

189:デフォルトの名無しさん
03/02/19 04:31
ebXMLはWS-Reliabilityの実装が肝だと思ってたけど、
ちゃんとしたデータ送って欲しいからね。連携するときは。
.NETってちゃんとその考えられているのかな？
ごめんおいらDB屋さんなんでやさしく教えてね＞識者の方

190:デフォルトの名無しさん
03/02/19 04:31
>>186
独自規格ならJ2EEでサポートする必要はありませんね。

191:デフォルトの名無しさん
03/02/19 04:33
>188
その何チャラでebXMLもサポートしてるらしいですが
開発者からすると実装が美しくないとのうわさが、、、

192:デフォルトの名無しさん
03/02/19 04:33
>>188
しかしSOAPを作ったのはM$とIBM。
M$は互換性をできる限りWindowsのみに限定させようとし
Windowsで動かないものは使いものにならないと思い込ませる戦術を使って来る。

193:デフォルトの名無しさん
03/02/19 04:35
大抵最後においしいところを持ってくのは IBM

194:デフォルトの名無しさん
03/02/19 04:37
>>188
JWSDP?
JAXというとJAXP?

195:デフォルトの名無しさん
03/02/19 04:44
そうJWSDPだ。JAXPはXML parserだ。

196:デフォルトの名無しさん
03/02/19 05:00
やっぱりJava厨はXMLに無知だな。(ｹﾞﾗ

197:デフォルトの名無しさん
03/02/19 05:07
>>185
8bitスルーな環境では、データ本体がバイナリーでもおっけ、という感じでしょうか？

>>186
M$の WSE/DIME に関するポインタ、どうもありがとうございました。

結局、WS-Attachments って
　　・SOAP 1.1 message を、MIME multipart の仕組みで送るための約束事(multipart/related で転送)
　　・Base URIの決め方に関する約束事
　　・各パートのデータを Content-ID または Content-Location でラベリング/参照する
ってもんなのねぇー。

参考文献: "SOAP Messages with Attachments" URLﾘﾝｸ(www.w3.org)

あと、勉強しとくべきなのは、
WS-Reliability
でつか。

198:デフォルトの名無しさん
03/02/19 05:15
>>197
>WS-Reliability

IBMもMSも絡んでない時点で政治的に失敗確実。

199:デフォルトの名無しさん
03/02/19 05:24
>>198
Fujitsu Limited, Hitachi, Ltd., NEC Corp, Oracle Corp., Sonic Software, and Sun Microsystems　っすか。

リファレンスは、URLﾘﾝｸ(xml.coverpages.org)
でおっけ？

200:デフォルトの名無しさん
03/02/19 05:29
ついでに、
・WS-Security
・Web Services Security Addendum
・DIME
・WS-Routing
・WS-Referral
ってあたりも勉強しておこう・・・

201:デフォルトの名無しさん
03/02/19 05:42
>>200
すべて.NETで対応済みのものばかりですな。
つまり、VB.NET使いの方がウェブサービスで先を行っている、と。

202:200
03/02/19 05:53
>>201
WSE のページから抜書きしただけですが、何か？

ついでに。

WSEのページ(>>186) で、MSもメッセージのreliability を考慮している、と書いてあるけど、
具体的に何してるの？

203:200
03/02/19 05:56
↑186 じゃなく、>>187 ﾀﾞﾀｰﾖ。
　URLﾘﾝｸ(msdn.microsoft.com)

＞In order to drive Web service interoperability in the enterprise,
＞the major players in XML Web services (including Microsoft, IBM, and Verisign)
＞have proposed new specifications that will improve interoperability
＞in areas that are crucial for Web services, such as security, reliable messaging, and sending attachments.

204:デフォルトの名無しさん
03/02/19 06:18
>>203
そこの文脈は Routing / Referral のことを指してるだけだと思う。

205:デフォルトの名無しさん
03/02/19 10:50
>>90
>おいらが言いたいことは設計うんぬんの話ではなくて
>EntityBean使ったら、取得したレコード分「EntityBeanインスタンス」が作られるっちゅー話です。
>分かりづらくて申し訳ない。

無知もほどほどにしてください。

206:デフォルトの名無しさん
03/02/19 11:33
この記述資料の最後の2,3ページが面白いよ。
URLﾘﾝｸ(bdn.borland.com)

207:デフォルトの名無しさん
03/02/19 11:46
やっぱりM$.Net厨はXMLに無知だな。(ｹﾞﾗ

208:デフォルトの名無しさん
03/02/19 11:49
M$ 厨の必死なレスが笑える

209:デフォルトの名無しさん
03/02/19 12:36
そこそこいい具合でいってたのによそのスレと勘違いしてる人がいるようで。

210:デフォルトの名無しさん
03/02/19 19:35
タイミングよくWS-Routingの記事が。
URLﾘﾝｸ(www.atmarkit.co.jp)

やはりこういう分野は.NETの方が先行してるね。

211:デフォルトの名無しさん
03/02/19 20:43
>>210
どういう分野が?
独自規格だけ先行してるだけじゃん

212:デフォルトの名無しさん
03/02/19 20:54
>>211
馬鹿だねー。
IBMとMSがまとめているのに。

213:デフォルトの名無しさん
03/02/19 20:58
>>212
それはWS-Routingのことやろ?
わいはM$の行動のことをいってんのや。

214:デフォルトの名無しさん
03/02/19 21:01
>>213
こういう分野 = M$の行動 ?????????????

215:デフォルトの名無しさん
03/02/19 21:08
>>214
何か疑問があるなら .Net上でWS-Routingをつかうメリットを説明してね。

216:デフォルトの名無しさん
03/02/19 21:11
>>213
さすがデムパは違うね。
急にあさっての方向にいってわけわかんね。
ごまかすならもっとうまくおやりんさい。

217:デフォルトの名無しさん
03/02/19 21:18
厨房の不毛な展開に質が低下する予感

218:デフォルトの名無しさん
03/02/19 21:25
>>204
WS-Routing は reliabilityを提供していないと書いてある。
WS-Referral の概説きぼんぬ

219:デフォルトの名無しさん
03/02/19 21:29
お前ら少しは実際に動かしてから物言え

220:デフォルトの名無しさん
03/02/19 21:34
頭より先に手を動かしてしまうのは、器用貧乏

221:デフォルトの名無しさん
03/02/19 21:55
J2EEはSunの独自規格ですが。

222:デフォルトの名無しさん
03/02/20 00:32
>>220
頭も手も動かさずに口だけ動かすのは、本当に救いがありませんよ。

223:デフォルトの名無しさん
03/02/20 00:33
>>205
無知で申し訳ないですが、分かるように説明してくださらないか？

224:デフォルトの名無しさん
03/02/20 01:31
知恵遅れで申し訳ないですが、.netはフリー（無料）で開発できるの？
期限付きとか以外で。

できるわけねーだろっていわれておしまいぽい。

225:sage
03/02/20 01:34
>198
WS-Reliability の重要性がわからないんだからM$はふしあなさんだっつーの。
ビジネスデータ連携のプロトコルでは必須だっつーの。
ほんとはIBMも噛むべき話なんだがね。ほかのことで忙しかったか。
大事なお約束が抜けてるからM$のビジネスはおまぬけだっつーの。
標準規約の制定なんかまかせられん。

226:デフォルトの名無しさん
03/02/20 01:35
>>224
フリーの.NET統合開発環境「SharpDevelop」
ｽﾚﾘﾝｸ(tech板)

227:デフォルトの名無しさん
03/02/20 02:16
フリーの実行環境は?

228:デフォルトの名無しさん
03/02/20 02:24
mono on Linux とか？

229:デフォルトの名無しさん
03/02/20 02:28
.net開発ツールと連携したＵＭＬツールは？
ソース吐き出したり

230:デフォルトの名無しさん
03/02/20 02:31
>>224
SDK(コンパイラ＋ライブラリ＋ランタイム)だけなら無料だったような。

231:デフォルトの名無しさん
03/02/20 02:37
OS が有料という罠
つか Windows の値段って気にしないよな……何でだろ。

232:デフォルトの名無しさん
03/02/20 04:16
>>229
UMLツールって、クラス図との連携だけだよな？
なら、有料だがEAならいける。(C++やJavaもOK)
URLﾘﾝｸ(www.sparxsystems.jp)
日本語版は4月に発売予定。

しかし実際のところ、UMLツールのキモはユースケース図、ロバストネス図(？)、
シーケンス図だと思うんだが。

233:デフォルトの名無しさん
03/02/20 09:31
　　　　　　　～∞
　　　　　　　　　　彡川川川三三三ﾐ～ ←java信者
　　　　　　ﾌﾟｰﾝ　川｜川＼　　／｜～
　　　　　　　　　　∥｜∥　◎---◎｜～
　　　　　　　　　　川川∥　　　　3　　ヽ～　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　川川　　　∴）〆（∴）～＜ C#は糞！！
　　　　　　　　　　川川　　　　　　～　/～　｜
　　　　　　　　　川川∥　　　　～　/∥～　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　　川川川川　　(⌒)川∥～ｳﾞｨｼｯ！
　　　　　　　／/::::::::|-､ ,-/::::::ﾉ ~.ﾚ-r┐
　　　　　　 /　/:::::::::::|　　/:::::ノ__　|　.|　ﾄ､
　　　　　　 | /:::::::::::::::|　〈￣　　｀-Lλ_ﾚ′

234:デフォルトの名無しさん
03/02/20 09:32
　　　　　　　　　　　　　川｜川川　　川 ←アンチC#厨
　　　　　　　　　　　　∥川 | | | ー　ー|| 　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　　　　川川 | |ｰ□--□l　　　　＜　 C#いらねー。
　　　　　　　　　　　　　川川| |；＼　J/|| 　　　　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿_
　　　　　　　　　　　　　川川∥；　| ロ|/|　カタカタカタ
　　　　　　　　　　　　　川川|∥＼|＿_|l|l　　＿＿＿＿＿
　　　　　　　　　　　　／川川川＿_/川川　　|　　|￣￣＼　＼
　　　　　　　　　　|　　川川|　　|／川l＿_,|　　|　　　　|￣￣|
　　　　　　　　　　　|　　＼＿|＿_|＿|､＿＿|　　|　　　　|＿＿|
　　　　　　　　　　　|　＼＿＿＿＿|つ　　 |＿_|＿＿／　／
　　　　　　　　　　　|　　　　 |　　|　|￣￣￣￣|　　〔￣￣〕
　　　　　　　　　　　　｜　　　　　　|￣

235:デフォルトの名無しさん
03/02/20 09:34
　　　　　　　　彡川三三三ﾐ　　　／￣￣￣￣￣￣￣￣
　　　　　　　川川 ::::::⌒　⌒ヽ＜ C#は糞
　　　　　　川川::::::::ー◎-◎-）　＼＿＿＿＿＿＿＿＿
java厨→川（６|::::::::　　（。。））
　　　 .＿川川;;;::∴　ノ　３　ﾉ
　　／;;;:::::::::::::::＼＿;;;;;;;;;;;;;;;;ノ
　/::::　　/::::::::::::　　　|::::|

236:デフォルトの名無しさん
03/02/20 10:28
C#死滅スレに始まり、Java死滅すれでもやってるかと思えばこのスレでもAAですか。
本当に聖なる戦いですね。

237:デフォルトの名無しさん
03/02/20 10:40
>>232
ロバストネス分析なら
オブジェクト図やステートチャート図などで構成できるので
ロバストネス図というものまではいらんと思うが

238:デフォルトの名無しさん
03/02/20 13:26
WS-ReliabilityはBizTalk Frameworkのパクリですけど。

239:デフォルトの名無しさん
03/02/20 18:54
>>238
ebXMLのパクリでも....?

240:デフォルトの名無しさん
03/02/20 19:13
>>232
JavaDoc を読めばクラス図なくてもいいという気はするね。
詳細すぎるクラス図を読み解く手間は JavaDoc +ソースを読むのと変わらないくらいだし。
してみるとクラス図を表示するときに、
フィルタリングして余計な情報を除外する機能があると嬉しいかも。

241:デフォルトの名無しさん
03/02/20 21:38
>>238
うん、ありえる。
Reliabilityをちょこっと調べてみると、一時期M$がぶいぶい言ってた。

で、今M$は reliable message をどーやって実現しようとしているの？

242:デフォルトの名無しさん
03/02/20 21:39
つーか、キーボードの下10cm位に置いてある BiztalkServer本をめくって調べる気力がでない、今日は疲れてて

243:デフォルトの名無しさん
03/02/20 23:36
>>237
いやいやクラス図とJavaDocは存在目的が全く違うよ。
クラス設計しないんか？

244:デフォルトの名無しさん
03/02/20 23:50
>>240
あったほうがええよ。
デザインパターンとかつかってんならクラズ図見ただけで
なにやってるか推測しやすい。

245:デフォルトの名無しさん
03/02/21 00:24
>>243
クラス図は手書きで書くよ。
ドキュメントとして残すものは visio で清書してるけど。

246:デフォルトの名無しさん
03/02/21 01:24
>>205
>>223の説明しれ

247:デフォルトの名無しさん
03/02/21 02:13
現時点ではJ2EEが圧倒的に先行している。
J2EEがデファクトになりそうだから、MSはあせりまくりだな。

248:sage
03/02/21 02:38
BizTalkは実装したソフトウェア製品自体が不安定だったから
くそだっツーの。規約を安定した実装で実現できないM$には
退場宣告

249:デフォルトの名無しさん
03/02/21 13:12
あのさ、Reliable Messagingなんか2001年前半にはもうすでに文脈が登場してるわけ。
URLﾘﾝｸ(www.w3.org)
MSとIBMは今これを実現するための仕様を策定中なわけだが、富士通が先走って作った仕様じゃ
WS-SecurityともWS-Routingともその他のWS-XXとも、極論言えばSOAP1.2とも
互換性がないわけよ。仕様読めばわかるだろ。WS-Reliablityなんかどうせ消えるから
無視しておいたほうがいいぜ。Sunが出した振り付け仕様だってはなっから無視されてるだろ。
あれと同じ運命。

J2EEがデファクトとかいってるやつ、おまえがもう少しあせって勉強したらどうだ。

BizTalkが不安定とかいってるやつ、BizTalkのレベルでメッセージングシステムを構築できる他社製品をあげてみな。

250:デフォルトの名無しさん
03/03/03 23:37
おまえら J2EE と .NeT が死滅寸前に追い込まれたときどうするよ？

ちゃんと対策とってるかよ
死滅対策をよ
死滅後の行動とってるかよ

251:デフォルトの名無しさん
03/03/04 00:04
おまえら250が死滅寸前に追い込まれたときどうするよ？

ちゃんと対策とってるかよ
死滅対策をよ
死滅後の行動とってるかよ

別に放っておいてもいいか

252:デフォルトの名無しさん
03/03/16 13:43
UMLの本を読んでいたらアナリシスパターンが出てきた。

Layersパターンなんてものもあるんだね。

POSA(Pattern-Oriented System Architecture)
という本もあるんだ。

イディオムなんてものもあったんだ。

253:デフォルトの名無しさん
03/03/17 14:45
なんだかとりとめのないスレだな

254:デフォルトの名無しさん
03/03/31 01:42
初心者に教えれ
J2EEアプリケーションサーバはJavaだからLinuxでもWinでも動くが
.NETアプリケーションサーバはWindowsでしか動かないのですか？

255:デフォルトの名無しさん
03/03/31 01:43
>>254
LinuxでXSPが動いてる

256:デフォルトの名無しさん
03/03/31 02:10
>>254
実質そうだな。

257:デフォルトの名無しさん
03/03/31 02:14
>>254
Linux版は9月正式リリースです。

258:デフォルトの名無しさん
03/03/31 10:43
>>255
つまり.NETはLinux上ではWindowsと同じように動いてくれないと？

259:デフォルトの名無しさん
03/04/01 00:57
Linux版Windowsが９月に出るよ。

260:デフォルトの名無しさん
03/04/01 03:37
>>259
ｴｲﾌﾟﾘﾙﾌｰﾙﾃﾞﾂｶ・ﾟ・(つД｀)・ﾟ・

261:254
03/04/02 00:06
>>256
やっぱりそうなのか、だったら.NETがJ2EEより流行るわけないじゃんね
.NET vs J2EEつーより、サーバーOSとしてWindows << Linuxだもんな

262:山崎渉
03/04/17 15:47
（＾＾）

263:デフォルトの名無しさん
03/05/19 08:55
サーバはJava一色と聞きましたが、J2EEからActiveXも使えるのですか？
それとも、ActiveXを使ったASPが廃れてるのかな？

264:デフォルトの名無しさん
03/05/19 10:47
>>263
ActiveXというとJavaAppletとJavaScriptの中間に当たる
セキュリティホール丸出しの悪い印象があってActiveXで
プログラミングしている人なんて聞かないなあ。
よほどの物好きが使いってイメージがあるよ。

しかもASPも、VBScriptなどで動いている以上、良い印象がないなあ。
ASP.NETならまだいいけど。それでもMVCのViewだけってのは・・・

265:デフォルトの名無しさん
03/05/19 11:39
じゃあ、サーバJavaというのは、HTMLオンリーか、JavaAppletになるわけですか？
質問ばかりですみませんが、先ず一般的にどう作られているのか知りたいです。

266:デフォルトの名無しさん
03/05/19 12:28
一般的なのはJSP/Servet+EJBだろうな。

267:デフォルトの名無しさん
03/05/19 12:34
>>265
HTMLオンリー、JavaAppletとといったらクライアントサイド。
サーバサイドJavaといったらEJB(EnterpriseJavaBeans), JSP(JavaServerPages),
JavaServlet。

MVCアーキテクチャのうちModelが EJB
View がJSP 、これがライバルではASPやASP.NET、PHPってところか。
ControllerがServlet ライバルは良く知らない。

268:デフォルトの名無しさん
03/05/19 12:49
>JSP/Servet+EJB
>JavaAppletとといったらクライアントサイド。
JSPでActiveX並みの画面は作れるわけでしか。
もちろん、JSPでJavaApplet利用ですよね？
一時期JavaAppletは死んだと言われてましたが、
まだ、JavaWebStartなんてインストールされてない気がするというか自分が使ってないような気がする。

269:デフォルトの名無しさん
03/05/19 13:07
>>268
ASPやPHP, CGIをご存知なら解るとは思いますが
それらと同じ目的で作られたJSPはAppletやFlashやActiveXのような派手なものを表現するために作られたものではありません。
掲示板やチャット、オークションサイト、eCommerce. eCRMとか、B2B,B2Cサイトとかで
ユーザからのリクエストに応じてHTMLやAppletに情報をレスポンスする部分に使うものです。

実際には、JSPのソースコードを見てみればわかります。
JSPのタグでもAppletを呼び出す(<jsp:plugin>タグ)ことができます。
が、このタグはブラウザ側からは見られません。
といえばわかるでしょうか？

270:デフォルトの名無しさん
03/05/19 14:24
>AppletやFlashやActiveXのような派手なものを表現するために作られたものではありません。
分かります。

>JSPのタグでもAppletを呼び出す(<jsp:plugin>タグ)ことができます。
>が、このタグはブラウザ側からは見られません。
ブラウザ側からは見られないなんて、初めて知りました。

じゃあ、派手な画面にはAppletが生きてるわけですね。
一時期Applet死滅と騒がれてたので。

271:デフォルトの名無しさん
03/05/19 22:54
>>268
AppletとJavaWebStartは関係ないぞ。
JavaWebStartはAppletよりむしろ、JavaApplicationをAppletのように各クライアントに
インストール不要にする技術。

272:デフォルトの名無しさん
03/05/19 23:32
>>270
Appletで派手なものやろうとすればできないことも無いが
それだけをやるんだったらFlash使ったほうがかなり楽なことは確か。

Flashはデザイナー好みの機能満載だからね。
AppletをFlashのようにマウスだけで簡単に作れるツールは少ないね。

デザイン以外の目的で使うならAppletはまだまだ生きている。
HTMLと併用して何かを表示したいならまだまだApplet

273:デフォルトの名無しさん
03/05/19 23:34
>>270
> >JSPのタグでもAppletを呼び出す(<jsp:plugin>タグ)ことができます。
> >が、このタグはブラウザ側からは見られません。
> ブラウザ側からは見られないなんて、初めて知りました。
ブラウザでソースをみても違うものが返ってきます。ただのHTMLにAppletへのリンク、
<object>タグまたは<Applet>タグが現れます。
サーバ側で<jsp:plugin>を<object>に変換してからクライアントにそのHTMLダウンロードして
表示しているだけなのです。

274:山崎渉
03/05/28 12:56
　　　　∧＿∧
ﾋﾟｭ.ｰ　(　　＾＾）＜これからも僕を応援して下さいね（＾＾）。
　　＝〔~∪￣￣〕
　　＝ ◎―◎ 　　　　　　　　　　　　　　　　　　　　　山崎渉

275:デフォルトの名無しさん
03/06/04 13:28
.Net, WebSphere Security Tested
URLﾘﾝｸ(www.eweek.com)

276:デフォルトの名無しさん
03/06/09 23:16
java厨とC#厨が知識をひけらかしてるだけのｽﾚってここでつか？

277:デフォルトの名無しさん
03/06/17 21:22
Security Evaluation of Microsoft .NET Framework and IBM WebSphere - Executive Summary
URLﾘﾝｸ(www.atstake.com)

278:デフォルトの名無しさん
03/07/14 15:41
XML WEBサービスという名前がカコわるい

279:山崎渉
03/07/15 09:44

　__∧＿∧_
　|（　　＾＾）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣

280:デフォルトの名無しさん
03/07/20 02:06
大抵最後においしいところを持ってくのは IBM

281:山崎渉
03/08/02 02:30
（＾＾）

282:山崎渉
03/08/15 16:58
　　　 (⌒V⌒)
　　　│ ＾＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

283:デフォルトの名無しさん
03/08/25 21:10
WSDPの話出てこないな(ワラい

284:デフォルトの名無しさん
03/09/02 15:27
J2EE vs. .NET - An Executive Look
URLﾘﾝｸ(www.netreverie.com)

285:デフォルトの名無しさん
03/09/02 15:33
[Service or Feature] Microsoft .NET Platform ／Java 2 Enterprise Edition Platform
[Language] VB, C++, C#, Java, Jscript, Perl…30+ ／ Java
[OS Platform & Runtime] Windows - CLR ／ Any ? JRE, JVM
[Mobile Platform] .NET Compact Framework ／ Java 2 Micro Edition
[GUI/In-proc Component] .NET class ／ JavaBeans
[Server-side Component] .NET, with COM+ services ／ EJB
[Persistent Objects] ADO.NET DataSet ／ EJB Entity Beans
[Web Page Generation] ASP.NET ／ JSP
[“Code Behind”] ASP.NET ／ Java Servlet
[Relational Data Access] ADO.NET ／ JDBC, SQL/J
[Hierarchical Data Access] ADO.NET ／ -None-
[Queuing] System.Messaging, MSMQ ／ JMS
[Asynchronous Invocation] COM+ Queued Components ／ Message Beans (EJB 2.0)
[Eventing] COM+ Events ／ -Not specified-
[Remoting] SOAP/HTTP/DCOM ／ RMI-over-IIOP
[Naming] ADSI ／ JNDI
[HTTP Engine] IIS ／ Apache
[XML] System.XML ／ JAXP, JAXM, JAXB, JAXR…
[Web Services] (.NET) XML Web Services ／ Sun ONE, IBM, BEA, Oracle
[Legacy Integration] HIS (COMTI), BizTalk, MSMQ, WS ／ JCA, JMS, WS, CORBA, JNI
[Shared Context] Passport ／ The Liberty Alliance, JXTA
[Security API] System.Security ／ JAAS

286:デフォルトの名無しさん
03/09/06 22:23
>>284
.NETの圧勝！

287:デフォルトの名無しさん
03/09/06 22:43
もう結果は見えてるよね。

JAVAって何？ああ、昔馬鹿な人たちが使っていたやつね、Ah ha.

288:デフォルトの名無しさん
03/09/06 23:09
>284
一番肝心な
Windowsしか選択肢がない，MSと心中 / OSを選ばない，心中することはない
はどうなんだ？

289:デフォルトの名無しさん
03/09/06 23:13
>>288
ちゃんと書いてあるじゃん。

Vendor Neutrality
J2EE 9/14
.NET 3/14

Portability
J2EE 11/14
.NET 1/14

290:デフォルトの名無しさん
03/09/06 23:15
英語の読めない低学歴のためにちゃんと図表で書いてるのにそれでも分からないのか。(w

291:デフォルトの名無しさん
03/09/06 23:18
>>284の著者もM$に脅されて泣く泣く.NETに有利な記事を書かされたのか。
良心の呵責に悩まされながら。

292:デフォルトの名無しさん
03/09/07 00:13
MSと心中した方が幸せになれるのは明白です

293:デフォルトの名無しさん
03/09/07 00:31
それは言えてる

294:デフォルトの名無しさん
03/09/07 19:52
JAVAはエンタープライズ、携帯電話の組み込み向け
.netはVB,C++,Delphiの得意なクライアント市場向け。
クライアントだとネイティブコンパイルができる.NET有利
サーバーとか非MSプラットフォームだといろんなOSのVMがあるJAVAが有利

今後はわからんが現状だとちゃんとすみわけができてる

295:デフォルトの名無しさん
03/09/08 06:42
クライアントにはDelphiがあるので.NET不利。

296:デフォルトの名無しさん
03/09/08 17:04
>>254
そもそも
.NETアプリケーションサーバ
ってなんですか?

297:デフォルトの名無しさん
03/09/11 00:53
マルチプラットフォームなんていらねーじゃん。

298:デフォルトの名無しさん
03/09/11 16:50
>>297
Wintel PCだけがコンピュータではないぞ？
エンタープライズとか組み込み市場なんかだと非Wintelが主流。

299:デフォルトの名無しさん
03/09/11 20:54
マルチも駄目ネイティブも駄目.NETはなんなの

300:デフォルトの名無しさん
03/09/11 21:39
Unicode関連が駄目駄目な某糞ツールよりはマシですよ。

301:デフォルトの名無しさん
03/09/25 11:42
.NETのILってFORTHを彷彿とさせるな

302:デフォルトの名無しさん
03/11/16 02:48
>>299
たんなるマーケティング用語ですが、なにか？

303:デフォルトの名無しさん
03/12/11 17:25

　今日ドッグイヤーといって、新たなシステムソリューションを立案・計画してから市場に
実際に投入するまでの時間を、短縮することは極めて重要な課題となっている。
まずこの観点から両方式を比較する。

　J2EEは、.NETには見られない市場に出すまでの時間を短縮できる特徴を持っている。
例えば状態管理サービスが開発者たちが書くコード量を減らし、状態の管理を思い煩わ
なくてもよくさせている。その結果アプリケーション開発スピードをより高いレベルに押し上
げる。状態管理サービスにより、状態を保持できるコンポーネントを構築することが可能に
なる。（entityBeanの）パーシステンスサービスにより、開発者はデータアクセスの論理を
コーディングせずに、アプリケーションを書き下すことができる。
その結果より簡潔な、データベースから独立したアプリケーションを、
より簡単に構築・保守することができるようになる。プログラミングされたトランザクション
は、より大規模なトランザクション上のコントロールを有するようになる。
そしてカスタムタグ（自分で任意に定義したタグ）は極めて強力なものであり、
開発者やWebデザイナーたちが簡単に協業することができるようにする。

304:デフォルトの名無しさん
03/12/11 19:04
>>303
カスタムタグを使って開発者とWebデザイナが分業できるってよく言われるけど
本当にうまくいってる例あるのかなあ
デザイナがどれくらいこの板を見てるか分からないけど、うちはtaglibで
大助かりだったって人居るの頭？

305:デフォルトの名無しさん
03/12/11 19:09
その問題は.NETでもJ2EEでもどちらでも抱えている問題だわな。

しかしそれもJakarta Tapestryで解決する。

306:デフォルトの名無しさん
03/12/13 15:23
J2EEは今日、さまざまのミッションクリティカルなビジネス上の問題を扱っている。
しかしながら表面的なものを振り返れば、J2EEが成熟さを欠いている、
いくつかの認定可能なリスク領域が存在するということを、銘記すべきである。
・自動パーシステンスが提供されるEJBは、未だに未成熟である。
・Java接続アーキテクチャ(JCA)は、新しい技術である。
・あらゆるWebサービスのサポートは、新しい技術である。
　
　マイクロソフトの.NETにとっては、話は少し違ってくる。.NETのいくつかはWindowsDNA
に基づいている。それはまた今日様々なミッションクリティカルなWebサイトの運用に用い
られ、成功を収めている。しかしながら
・新しいCLRの下では、基礎をなしている.NETプラットホームのかなりの部分が実質的
に書き直されている。実際プラットホームそれ自体は、目下の所β版しか入手できな
い（註：今日では製品版が提供されている）。
・C#は新しい言語である。
・あらゆるWebサービスのサポートは、新しい技術である。

　
　結論としては、J2EEの方がより成熟したプラットホームであるということだ。

J2EEにおけるある種の新規の特徴が、新しくかつリスキーであることは事実である。
しかしながら.NETの基礎の基礎をなす構造は、完全に書き直されており、C#言語全体
が完全に新しく開発されたものである。このことは新しいJ2EEの特徴と比較しても、
極めて大きなリスクを伴うことを示している。.NETについての最良の特色は、
それがCOMレジストリの依存性を排除していることにある。即ち.NETは、
DLL地獄とサヨナラしたのである。しかし、.NETについての最悪の特色は、
今存在しているインフラを追い出してしまうということにある。リスクが嫌なら、
この(.NET)ような第1世代のソフトウエアに対しては「じっと待って観察する。」
というアプローチをとることを勧める。

307:デフォルトの名無しさん
03/12/13 15:24
>>306
何年前の記事だろ？

308:デフォルトの名無しさん
03/12/13 15:26
> NETのいくつかはWindowsDNAに基づいている。

> .NETの基礎の基礎をなす構造は、完全に書き直されており

矛盾してます。

309:デフォルトの名無しさん
03/12/13 15:29
> .NETのいくつかはWindowsDNAに基づいている。

> .NETについての最悪の特色は、今存在しているインフラを追い出してしまうということにある。

やはり矛盾してます。

310:デフォルトの名無しさん
03/12/13 20:34
どう矛盾しているって？

311:デフォルトの名無しさん
03/12/13 20:35
「特色」と「基礎」の意味を理解していれば矛盾していないことに気が付くんだけどなあ

312:デフォルトの名無しさん
03/12/13 21:44
>>304
スタイルシートを使いこなせる(ブラウザの特徴を完全に把握している)
Webデザイナと、ドキュメント構造からどんなデザイン的自由を確保できるのか
理解してるPGがいれば、カスタムタグなんて要らない。

313:デフォルトの名無しさん
03/12/14 05:17
>>312
それいったらJSFやstrutsはおろかASP.NETは敗北宣言しているようなものじゃん・・・・。
　

314:デフォルトの名無しさん
03/12/14 10:14
>>312
＞ドキュメント構造からどんなデザイン的自由を確保できるのか理解してるPG
この部分が分からないので教えて四。それは具体的にどういう職能を持ってれば
タムタムタグが不要なの？

315:デフォルトの名無しさん
03/12/14 14:59
まあJakarta Tapestryを使えばカスタムタグを覚える必要がないのは確かだね

316:デフォルトの名無しさん
03/12/14 15:10
業務でJakartaなんて使う馬鹿いない。
バグったら誰が責任取るのさ？

317:デフォルトの名無しさん
03/12/14 15:22
普通に業務で使ってるけど。
Jakartaであろうとなかろうとバグったらバグの原因を作ったものが責任をとるにきまってるやん

318:デフォルトの名無しさん
03/12/14 15:26
つまりJakartaは一切責任を取ってくれませんと。最低だな。

319:デフォルトの名無しさん
03/12/14 15:29
Jakarta の信頼と実績を知らないでしょチミ。
Apache HTTP Serverがあれだけのトップシェアを誇った理由も知らないんじゃ話しにならないねw

320:デフォルトの名無しさん
03/12/14 15:33
>>319
タダだからだろ？
有料だったら誰も使わないよ。

321:デフォルトの名無しさん
03/12/14 15:34
JakartaとApache WebServerを並べても意味ないだろ。
別物だし。

322:デフォルトの名無しさん
03/12/14 15:35
JakartaがあるからJ2EEは要らないのか

323:デフォルトの名無しさん
03/12/14 15:36
Jakartaなんか使ってまでJavaやりたいかねえ。
Perlで十分じゃん。

324:デフォルトの名無しさん
03/12/14 15:45
つまりJavaはオプソに頼らなければならないほど信頼性も実績もないということか。

325:デフォルトの名無しさん
03/12/14 16:01
オプソの信頼性と実績に頼れない.NET房は大変だな（ｗ

326:デフォルトの名無しさん
03/12/14 16:12
これはこのフレームワーク、とかいろいろ組み合わせないと使い物にならなかったり。
MSの1つでOKとは違うね。

327:デフォルトの名無しさん
03/12/14 16:17
まあ、それは文化の違いでしょう。
どちらがいいかはその人次第。

328:デフォルトの名無しさん
03/12/14 16:32
>>324
ﾌﾟ　お前はPerlのことを良く知らないでperlでいいとかほざいているようだが
perlもオープンソースだぞ(藁

329:デフォルトの名無しさん
03/12/14 16:33
>>321
同じApacheに属しているぞw

330:デフォルトの名無しさん
03/12/14 16:34
>>322
ﾌﾟ J2EEのことをよくわかっていないアフォですねw

331:デフォルトの名無しさん
03/12/14 16:35
>>330
J2EEはApache WebServerを含んでいるとでも？

332:331
03/12/14 16:36
あ、>>322宛てか。>>321宛てと読み違えた。ｽﾏｿ

333:デフォルトの名無しさん
03/12/14 16:44
>>320
それだけじゃない。

まずソースコードが公開されているため
ソースが公開されていない商用ソフトウェアやフリーソフトウェアよりも非常に信頼性が高い。

一企業に依存しない、ネットワークでつながれた
世界中のより多くの人によって開発されている。

だれでもその開発に携わることができる。これも信頼性を大きく高める起因。

数多くの人が開発しながら実際に使ってみてテスターとして貢献しているため
一企業の市販の商用ソフトウェアや同人でやっているフリーソフトよりも信頼性が非常に高い。

競合するソフトウェアの真の価値を暴くことができ、ライバルとなっている企業が
どうしてもオープンソーススフとウェアより価値のある製品を作らなければならなくなる。
オープンソースにも同じような機能があることが顧客に知れ渡れば顧客は安いほうを選ぶ。
すると商用ソフトを作っている企業は、自社ソフトとの値段を下げたり、真剣に新規性を求めた
製品を作るようになる。
これはM$などソースをほとんど公開したがらないM$などにとっては
大きな痛手でもあり、M$に刺激を与える効果を十分に発揮している。

むしろM$が必死にLonghornなど新しいものを作りたがる傾向は
オープンソースのおかげといっても過言ではない。

334:デフォルトの名無しさん
03/12/14 17:38
> まずソースコードが公開されているため
> ソースが公開されていない商用ソフトウェアやフリーソフトウェアよりも非常に信頼性が高い。

ソースを公開すれば必ず信頼性が高くなるわけではありません。
すべては元のソースの品質次第です。

> 一企業に依存しない、ネットワークでつながれた
> 世界中のより多くの人によって開発されている。

それはすなわち一貫性のないカオスということです。

> だれでもその開発に携わることができる。これも信頼性を大きく高める起因。

最近でもクラッカーに書き換えられて被害を出してますね。

> 数多くの人が開発しながら実際に使ってみてテスターとして貢献しているため
> 一企業の市販の商用ソフトウェアや同人でやっているフリーソフトよりも信頼性が非常に高い。

テストにおいて、ソースが公開されているかどうかはほとんど関係がありません。

335:デフォルトの名無しさん
03/12/14 17:38
> 競合するソフトウェアの真の価値を暴くことができ、ライバルとなっている企業が
> どうしてもオープンソーススフとウェアより価値のある製品を作らなければならなくなる。
> オープンソースにも同じような機能があることが顧客に知れ渡れば顧客は安いほうを選ぶ。
> すると商用ソフトを作っている企業は、自社ソフトとの値段を下げたり、真剣に新規性を求めた
> 製品を作るようになる。

それはイニシャルコストの話に過ぎません。
トータルコストから見れば大した割合ではありません。

> これはM$などソースをほとんど公開したがらないM$などにとっては
> 大きな痛手でもあり、M$に刺激を与える効果を十分に発揮している。

それは事実ですが、相手がオープンソースだからということとは何の関連性もありません。
ただ単に競合相手だからです。

> むしろM$が必死にLonghornなど新しいものを作りたがる傾向は
> オープンソースのおかげといっても過言ではない。

いいえ。顧客の機能要求によるものです。

336:デフォルトの名無しさん
03/12/14 18:59
Javaの信頼性なんてこんなものだろ。
URLﾘﾝｸ(www.javalobby.org)

337:デフォルトの名無しさん
03/12/14 19:01
よくわかんないんだけど、ドットネットだとバグはマイクロソフトが責任とってくれるんですか？

338:デフォルトの名無しさん
03/12/14 19:11
>>337
ドットネットにバグなど存在しません。すべて仕様でつ

339:デフォルトの名無しさん
03/12/14 19:22
>>326
M$のAPIを使う香具師は自分で作って公開するって香具師が少ないねほんとに。
Monoだけでしょ, まともなところってw

340:デフォルトの名無しさん
03/12/14 19:43
>>334
> > まずソースコードが公開されているため
> > ソースが公開されていない商用ソフトウェアやフリーソフトウェアよりも非常に信頼性が高い。
> ソースを公開すれば必ず信頼性が高くなるわけではありません。
> すべては元のソースの品質次第です。
まったく言っている意味がわかってないな。このアフォは。
いちいち説明しなおしてやらんとわからんの？　この低脳は。
>>334はApache Jakartaの話をしているんだよ。
ソースを公開していることが信頼されるための第一条件だといってんの。
まずソースコードが公開されていることを説明し、ソースコードが公開されている上で
どれだけ多くの開発者がかかわっているかを全体にわたって説明したでしょうや。脳足りんのチミ？

M$学生エヴァンゲリストだかなんだか知らんが
物事を部分部分で捉えずに全体を見て捕らえるって事ができないのかねM$房は。
視野が狭すぎるんだよM$厨房は。

> > 一企業に依存しない、ネットワークでつながれた
> > 世界中のより多くの人によって開発されている。
> それはすなわち一貫性のないカオスということです。
俺たちはこんあ小学生の作文いたいなぱっとしないコメントを読みたがっているんじゃないんだよ。
何が一貫性がなく何がカオスなのか説明してみろよチミ。
なんでもかんでもわかったつもりになって詭弁術を唱えるんじゃないよ。
オープンソースというのはコミッターによって一貫性を保ちつつしっかりと管理されているんだよ。
勘違いしないように。

341:デフォルトの名無しさん
03/12/14 19:49

> > だれでもその開発に携わることができる。これも信頼性を大きく高める起因。
> 最近でもクラッカーに書き換えられて被害を出してますね。
M$のWindowsUpdateに見られるセキュリティパッチの多さや被害の多さにに比べればたいしたこともないぞ。

> > 数多くの人が開発しながら実際に使ってみてテスターとして貢献しているため
> > 一企業の市販の商用ソフトウェアや同人でやっているフリーソフトよりも信頼性が非常に高い。
> テストにおいて、ソースが公開されているかどうかはほとんど関係がありません。
チミ日本語読めてる？突然「ソースが公開されているかどうかはほとんど関係がありません。」
とか意味不明なこといって。何言ってるのチミ？　　頭大丈夫？　

この一文はソースが公開されてるされていないの話をしているんじゃないんだよ。
数多くのテスターによって何度も繰り返しテストされなんどもチェックされて信頼と実績を確保していることが
Apacheというオープンソースソフトウェアの素晴らしいところなんだよ。

342:デフォルトの名無しさん
03/12/14 19:49
>>335
> > 競合するソフトウェアの真の価値を暴くことができ、ライバルとなっている企業が
> > どうしてもオープンソーススフとウェアより価値のある製品を作らなければならなくなる。
> > オープンソースにも同じような機能があることが顧客に知れ渡れば顧客は安いほうを選ぶ。
> > すると商用ソフトを作っている企業は、自社ソフトとの値段を下げたり、真剣に新規性を求めた
> > 製品を作るようになる。
>
> それはイニシャルコストの話に過ぎません。
> トータルコストから見れば大した割合ではありません。
全ての顧客にとってたいした割合とは限らんだろう。
>
> > これはM$などソースをほとんど公開したがらないM$などにとっては
> > 大きな痛手でもあり、M$に刺激を与える効果を十分に発揮している。
>
> それは事実ですが、相手がオープンソースだからということとは何の関連性もありません。
> ただ単に競合相手だからです。
馬鹿か。オープンソースだからとかではなく、相手がApacheなどの有名で人気どこであることが
M$に強い刺激を与えていることも事実なんだよ。
たとえばEclipseにしてもそうだ。次期VS.NETにはEclipseにあったリファクタリング機能が追加されるんだろ。
タダでできるツールがあれだけ高度なことができるのになぜ有償ツールは
ああいうことができないのか？　と顧客、プログラマから当然のように不満が来る。

343:デフォルトの名無しさん
03/12/14 19:51

> > むしろM$が必死にLonghornなど新しいものを作りたがる傾向は
> > オープンソースのおかげといっても過言ではない。
>
> いいえ。顧客の機能要求によるものです。
馬鹿をいえ、正確な返事は「はい、顧客の機能要求も含めオープンソースソフトウェアより
良いものを作らなければM$社を延命できないからです。」だろ。
平静さを装って逃げるなよ小僧。

オープンソースソフトウェアを見てただであれだけ素晴らしいものができるのに
なぜM$は金を顧客から詐取しておきながらオープンソースソフトウェアよりも
素晴らしい信頼性と高いセキュリティを誇る製品を作れないのだ？
と顧客にいつまでもいわれ続けないように努力するために新しいものを必死に作って
オープンソースソフトウェアに負けまいとがんばっているんだろ。

344:デフォルトの名無しさん
03/12/14 20:04
長くて読んでないけどM$とあるから内容はよくあるやつだと予想できるな。

345:デフォルトの名無しさん
03/12/14 20:04
M$厨マジでウザい
逝ってよし

346:デフォルトの名無しさん
03/12/14 20:06
> >>334はApache Jakartaの話をしているんだよ。

つまり、Apache Jakarta以外には信頼性は当てはまらないこと認めてるわけですね。
理解しました。

> オープンソースというのはコミッターによって一貫性を保ちつつしっかりと管理されているんだよ。

誰でも貢献できるわけではないのですね。残念です。

> M$のWindowsUpdateに見られるセキュリティパッチの多さや被害の多さにに比べればたいしたこともないぞ。

オープンソースに被害があることに変わりはありませんね。

> 数多くのテスターによって何度も繰り返しテストされなんどもチェックされて信頼と実績を確保していることが
> Apacheというオープンソースソフトウェアの素晴らしいところなんだよ。

商用ソフトはテスターが少ないとでも言いたいのでしょうか？
根拠が感じられませんね。

347:デフォルトの名無しさん
03/12/14 20:06
> 馬鹿か。オープンソースだからとかではなく、相手がApacheなどの有名で人気どこであることが
> M$に強い刺激を与えていることも事実なんだよ。

ならば「Apacheが刺激を与えている」と適切に書きましょう。

> たとえばEclipseにしてもそうだ。次期VS.NETにはEclipseにあったリファクタリング機能が追加されるんだろ。
> タダでできるツールがあれだけ高度なことができるのになぜ有償ツールは
> ああいうことができないのか？　と顧客、プログラマから当然のように不満が来る。

だからWhidbeyで対応されました。不満ですか？

> オープンソースソフトウェアを見てただであれだけ素晴らしいものができるのに
> なぜM$は金を顧客から詐取しておきながらオープンソースソフトウェアよりも
> 素晴らしい信頼性と高いセキュリティを誇る製品を作れないのだ？

ユーザー数の多さと幅の広さゆえです。
仮にオープンソースがWindows並みに普及したとしたら、結局は同じ壁にぶつかることでしょう。

348:デフォルトの名無しさん
03/12/14 20:12
> つまり、Apache Jakarta以外には信頼性は当てはまらないこと認めてるわけですね。
> 理解しました。

これ読んだ時点で萎えた。向きになったただの負けず嫌いの餓鬼かよ。

349:デフォルトの名無しさん
03/12/14 20:14
MS房の餓鬼は相手にするだけ時間の無駄です

350:デフォルトの名無しさん
03/12/14 20:15
言い返せないアホアンチ。(ﾌﾟﾌﾟﾌﾟﾌﾟ

351:デフォルトの名無しさん
03/12/14 20:15
小学生みたいなレスだなM$信者のレスは・・・

352:デフォルトの名無しさん
03/12/14 20:16
どっちがムキになってるんだろう。(ｹﾞﾗ

353:デフォルトの名無しさん
03/12/14 20:29
何だよ、オプソの利点もまともに説明できないのかよ。使えない奴

354:デフォルトの名無しさん
03/12/14 20:35
っていうか、得意気にオープンソースを語っておきながら、反論されたら
ろくに説明もできずに一人で勝手に切れて議論打ち切ってるだけじゃん。

どうしようもない馬鹿だな
現実では誰にも相手にされてないんだろうな

355:デフォルトの名無しさん
03/12/14 21:20
Javaがオープンソース？
冗談キツいなぁ

356:デフォルトの名無しさん
03/12/14 21:22
.NET厨(?)も相当性格が歪んでるなあ。(ﾜﾗ

357:デフォルトの名無しさん
03/12/14 21:35
Ｍ＄厨は帰れ

358:デフォルトの名無しさん
03/12/14 21:45
>>357
スレタイよく見ろ馬鹿

359:デフォルトの名無しさん
03/12/14 22:05
小学生のようなM$信者の必死な無知な発言に呆れたよ

360:デフォルトの名無しさん
03/12/14 22:19
アホアンチは幼稚園児並み

361:デフォルトの名無しさん
03/12/14 22:33
×幼稚園児並み
○幼稚園児以下

362:デフォルトの名無しさん
03/12/14 23:14
アホアンチとか言っているやつ、
M$とか言ってるやつ、
どっちも目障り。

363:デフォルトの名無しさん
03/12/14 23:19
>>362
なんだかんだ言ってM$擁護するつもりなんだろ。
これだからM$厨はイタ過ぎる。

364:デフォルトの名無しさん
03/12/14 23:19
つまりアホアンチが一番目障り

365:デフォルトの名無しさん
03/12/14 23:21
生きる価値のない禿豚だからな。www

366:デフォルトの名無しさん
03/12/14 23:35
>>362-365
お前らのことだ。

次ページ