■CGIは死滅。これからは.NETできまり■

1 ：02/06/03 〜 最終レス ：8)

CGIなんて死滅技術つかってんなよ。Javaも問題外だ。
これからはゲイツ様の.NET。これ最強。
馬鹿みたいにいつまでもCGIなんて使ってるな。
PERL最悪
こらからはC#
はい、みなさんもご一緒に

2 ：

はい、みなさんもご一緒に

　　　　　　　　　　>>1　　逝　　っ　　て　　よ　　し

　

3 ：

続いてご一緒に
　　　　　　　　　　>>1　　逝　　っ　　て　　よ　　し

4 ：

更に続いてご一緒に
　　　　　　　　　　>>1　　逝　　っ　　て　　よ　　し

5 ：

1はC#=.NETと思ってる厨房君ですか?

6 ：

>>1さんは２ちゃんねる初心者ですか？
書き込む前にSG(セキュリティー・ガード)に登録しないと危険ですよ。
SGに登録せずに書き込んだ場合、
あなたのパソコン内の情報が他人に見られる恐れがあります。
初期の頃から２ちゃんねるにいる方達は
かなりのスキルとこのBBSのコマンドを知っています
ですから簡単にあなたのIPアドレス等抜かれ、住所まで公開された人も数多 くおり
社会的に抹殺されてしまう。それが２ちゃんねるの隠れた素顔でもあります
SGしておけばまず抜かれるコマンド自体が無効になってしまうので
どんなにスキルがある人でもIPアドレスを抜くことが不可能になります
SGに登録する方法は、名前欄に「 fusianasan 」と入れる。
これでSGの登録は完了します。
一度登録すれば、電話番号を変えない限り継続されます。
fusianasanは、正式にはフュージャネイザン、
又はフュジャネイザンと読みます。
元々はアメリカの学生達の間で、チャットの時に
セキュリティを強化する為に開発されたシステムです。
fusianasanを掲示板に組み込むのは結構面倒なのですが、
２ちゃんにカキコしてたらウィルスに感染したとか、
個人情報が漏れた等の抗議がうざったくなったひろゆきが、
仕方なく導入しました。
悪意のある人間にクラックされる前にSGを施す事をお勧めします。

7 ：

>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁
>>1 は　井　の　中　の　蛙　（藁

8 ：

3歳児を煽ってもなあ。

9 ：

いまどき６みたいなのに騙されるやつはいるのか？

10 ：

しまった、あげてしまった。鬱だ

11 ：

お前らネタを煽らないでください

12 ：

このスレは痛い発言をTESTするスレになりました。

13 ：

ネタスレだろ？

14 ：

腹減ったな
ねたにきまってるだろ、こんなすれ

15 ：

>>9
PCQAに常駐してたらたまにいます。

16 ：

Ｍ＄は .ＮＥＴを広めようと、デモンストレーションをあちこちでやっているそうだが、
クラッシュしてしまうらしい。デモンストレーションでクラッシュするくらいだから
実践ではしまくりだろう。

実用段階に達していないよう。

17 ：

>>16
と、推測だけでものを言うあなたは何者？

18 ：

やらせ反対

19 ：

ってゆーか、サンデープログラマならともかく、
出て5年と経ってない若いプロダクトをよく仕事で使う気になるな。。。。

MS好きってよっぽどバカ？

20 ：

ジャヴァでも当初同じことが言われたが

21 ：

M$なんて、技術力ナシ、常識ナシだぞ。そんな会社の作ったもんよくみんな使ってるな…

22 ：

使ってみればわかる。
JSPやPHP使うのが馬鹿馬鹿しくなってくる程簡単に組めるぞ。
要は使い方だべさ。
まぁ、VB厨な低納技術者がどっと流れてくるのが目に見えるがな。

23 ：

　 　　　 ＿＿ ┌┬┬┬┐ ＿＿
　　　　―――┴┴┴┴┴―――――、
　 　/. ￣￣￣//.￣￣| ||￣￣￣|||￣ |｜　　　 　＿＿＿＿＿＿＿＿＿＿
　　/.　 　　∧// ∧ ∧|.|| 　 　 　||| 　 |｜　　／
　[/＿＿__(ﾟ_//[ ].ﾟДﾟ,,) ||＿＿＿||| 　 |｜ ＜ 　MS信者を迎えに来ました
　||_.　*　 ＿|_|￣￣ ∪|.|. 　 　 　 .|ヽ. _|｜　　＼＿＿＿＿＿＿＿＿＿＿
　lO|o―o|O゜.|二二Del|.|ｷﾞｺ 精神病院 ||
　| ∈口∋￣_l＿＿ｌ⌒ｌ_|＿＿＿__|_ｌ⌒ｌ_||
　　￣￣`ー'￣ 　　`ー'　 `ー'　 　`ー'

24 ：

IIS必須というのがちょっと・・・
フロントエンドをapacheにしたいんだがそれって可能かね？

25 ：

24
不可能
絶対不可能
１００％不可能

26 ：

M$を叩くスレはここ？

27 ：

どんなもんかだけ試そうと思ったが、>>24の
「IIS必須」を読んで一気に萎えた。

28 ：

Apacheから.Net Frameworkを使う
モジュール作れ！おまえが作れ！

29 ：

VBに慣れた身には楽な部分があるが、IISはセキュリティホールが怖い・・・
それに、VBの方が楽な処理もあれば、perlの方が断然楽な処理もあるし。

30 ：

>>28
簡単だと思うがね。
やってることはリクエスト渡してHTML（XMLかも）吐き出すだけなんだから。

31 ：

>>28
M$工作員に潰されます

32 ：

C:\MOD_DOTNET>cl mod_dnet.c
Microsoft(R) 32-bit C/C++ Standard Compiler Version 13.00.9466 for 80x86
Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
エラー: 不明なエラーが発生しました。1インシデントご購入の上、Microsoftのサポートまでお問い合わせ下さい。

33 ：

>>32
不正コピーですか。。。

34 ：

あ、必須というのは確認したわけじゃないですが、
>>1のいうperl&CGIの代替となるには、.NETのプログラムをactivateする
なんらかのフロントエンドが必要になりますよね。

それがIISなら(ASP.NETが?)ネイティブで動作するというのは分りやすいですが、
皆さん懸念されてるようにセキュリティーホールが怖いです。

Apacheのモジュールでなんとかなるもんですかね。
Servletなどを参考にすれば行けそうな気がしますけども。

35 ：

放置ですか・・・

36 ：

Ｍ＄信者、必死だな（藁

37 ：

linux信者必死だな藁

38 ：

>>34
つべこべ言ってないでお前がやってみれ

39 ：

必死だな（藁　←こいつが一番必死（藁

40 ：

必死だな（藁　←こいつが一番必死（藁 ←こいつが一番必死だな（藁

41 ：

LOOP

42 ：

必死だな（藁　←こいつが一番必死（藁 ←こいつが一番必死だな（藁 （略

43 ：

必死だな（藁　←こいつが一番必死（藁　←こいつが一番必死（藁 ←こいつが一番必死だな（藁 （略

44 ：

（（（（((((( 使いたい方をつかえば良い ))))））））
（（（（((((( 使いたい方をつかえば良い ))))））））
（（（（((((( 使いたい方をつかえば良い ))))））））

45 ：

>>44必死だな（藁

46 ：

でも.NETに移ったほうがよいのでは？

47 ：

んなこたぁ無い

48 ：

>>46必死だな（藁

49 ：

>>47こいつも必死だな（藁

50 ：

>>38 ホラよ（藁
@echo off
echo 必死だな（藁 >必死.txt
:loop
echo ←こいつが一番必死だな（藁 >>必死.txt
type 必死.txt
goto loop

51 ：

／￣￣￣￣￣￣￣
|　ほう、覚え立てのバッチで煽りですか。
＼ 　　　　　　　
　 ￣￣￣|／￣￣￣
　　∧＿∧　　カタカタ
　 （　・∀・） 　 ∧ ∧
　 （　　 　 ）Σ(ﾟДﾟ ,,) 　　う、うるせえ! ｺﾞﾙｧ!
￣￣￣￣￣　（つ＿つ＿__
￣￣￣￣￣￣＼| DELL |＼ <<50
　　　 　 　 　 　　 =======　 ＼

52 ：

#!/usr/bin/perl
print "必死だな（藁\n";
while ( 1 ) {
　print " ←こいつが一番必死だな（藁";
}

53 ：

>>52 ミスった（ｗ
#!/usr/bin/perl
print "必死だな（藁 ";
while ( 1 ) {
　print " ←こいつが一番必死だな（藁";
}

54 ：

ださっ

55 ：

ファイル名をハードコードするのは悪い癖だと思う。

56 ：

test

57 ：

>>55
unix文化を軽視するやつは許さん

58 ：

古いものは去る
老人も去る
はやくR

59 ：

(　´,_ゝ`)ﾌﾟｯ

60 ：

↓必死

61 ：

王
金銀桂

62 ：

↑必死だな藁

63 ：

[1-62] > /dev/null

64 ：

↓瀕死

65 ：

うぐぅ・・・

66 ：

んで誰かチャレンジした奴はおらんのか

67 ：

うっせーはげ！

68 ：

はげって言った奴が禿げなのです、覚えておきなさい。

69 ：

あー終わりだね。これからは.txtだね。

70 ：

.NETはOracleAiより１８倍も遅いらしい。次の資料参考

ベンチマークＰＤＦ：

http://otn.oracle.com/tech/java/oc4j/pdf/9ias_net_bench.pdf

71 ：

Ｊａｖａ コード：

private void getAfterI(String name)
{
int i = name.indexOf("I");
if(i > 0)
{
afteri = name.substring(0,i).trim();
}

}

C# コード
private void getAfterI(string name)
{
int i = name.IndexOf(" ");
if(i > 0)
{
afteri = name.Substring(0,i).Trim();
}

}

以上の例では、C# コードはＪａｖａコードの大文字・小文字を違えただけ。

これでは著作権侵害で差し止めになる可能性もでてきた。

72 ：

どうせWFCの時みたいに、みんなか知らないうちに無くなるんだろ。>>.NET
どうせWinAPIみたいに変な動作する仕様なんだろ>>.NET
まともなことをキgしようとするとMSの製品で埋め尽くさないとできないんだろ>>.NET

73 ：

.netﾏﾝｾｰ

74 ：

.NET、俺は好きだけどな。実際に書いてから判断してほすぃよ。
(俺がミクロンマンセーなのは認めるが)

75 ：

C#悪くないのになあ・・・。
問題の本質はC#ではなくIISにあると見た。

76 ：

無知は恐いね（ｗ

77 ：

C#ってあのJavaとなんら変わらんようなヤツですか

78 ：

何も変わらんのなら後発の方が何かと便利だよね。
俺はC++マンセーだけど。

79 ：

C#ってJavaの替わりになるの？
だったら歓迎するけど...

80 ：

C#?
Java?
(　´,_ゝ`)ﾌﾟｯ

81 ：

>>72
まともなことをキgしようとするとMSの製品で埋め尽くさないとできないんだろ>>.NET
これは、ちょっと正しくないな。
「まともなことをキgしようとするとM$の製品で埋め尽くしても駄目なんだろ>>.NET」
これが正しいと思う（ｗ

82 ：

もうJavaにはこりごりなので、M$にはなんとかしてほしいんですが・・・
誰だよ、「オープンソース環境のほうが整ってますよ」なんていう大嘘付いたのは・・・

83 ：

面倒だからメシ食えてるんだよ（ｗ

84 ：

オープンソース、俺も数年前はこの方法が一番良いと思っていたのに…。
今思うと、これってただの能無しが何も考えずに、
知識を手に入れたりぱくったりしようとする為に考え出した方法ではないかと(;ー;

85 ：

結局お前らはこのスレが好きなんだな…（泣）

86 ：

必死だな（藁

87 ：

82
ﾜﾗﾀ

88 ：

おもしろいね

89 ：

まぁWindowsが普及し始めた頃にも、「あんなの絶対広まるはずがない」
とか、「Windowsを使うやつはバカ」だと言ってDOSにしがみついてた
やつがいたけど、数年たったらWindows使ってたもんなぁ。あそこまで
言ったんだからDOSと心中すればよかったのに

90 ：

ウイルス入り、さすがだ。

91 ：

>>90
いや、あれは逆に評価してやっていい（ｗ

92 ：

>>89まぁ、クライアント市場ではそうだろうね。
でも、うちの会社じゃ win 使ってる（インストされてる）マシン無いけどね（ｗ

93 ：

>>84
それはオープンソースそのものが悪いんじゃなくて、
「オープンソースソフトウェア＝ただ（無料）のソフト」としか認識していない厨が
大量に流れ込んできたからだろ？
LinuxやApacheのような著名プロジェクトは、厨が増えた代わりにIBMやSunが
人的リソースを大量投入してくれるようになったけど、中小のプロジェクトは酷いですな・・・

94 ：

オープンソースには騙されました。
結局勢力の強いところがより強くなるだけなのね。

95 ：

オープンソースにだまされた奴はまるで、猿回し並みの知能だね

96 ：

ID:dtiHXwj1 ←猿回し並みの知能

97 ：

モンキーマジックはよかった

98 ：

金がある、有能な人物を高い金をだして雇える、MSまんせー

99 ：

金がある、無能な人材を高い金出して雇える、技術力皆無、Ｍ＄マンセー

100 ：

>>99の実力はたいしたことないな藁

101 ：

>>98=>>100
（･∀･）*****ﾃﾞｼﾀ!!

102 ：

（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）
　 　 　 　 　 　　 ＿＿＿
. 　 　 　 　　　　 |（･∀･）|
. 　 　　　　 　 　 |￣￣￣　　　ｼﾞｻｸｼﾞｴﾝ王国
　　　　　　　　　△
　　　　　　　 △ｌ　|
　　　＿＿△|_.田 |△＿＿＿＿＿
　　　　　　|__|__門_|__|＿＿＿＿＿|＿＿＿＿＿
（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）

103 ：

なんか、ここで .net マンセーとか言っている奴。>>1 が一人でやってるように思えてきた（藁

104 ：

javaはなんだかんだ言って部品を組み合わせるところが面倒すぎです
それぞれ固有のコトバを使いすぎててたまらん。
.netでも同じかね？

105 ：

上司：オープンソースでやってみろ。MSは嫌いだ。WinNT4.0で懲りた。
（結局、フリー、オープンソース導入。）
漏れ：トラブりました。ベンダにすぐ連絡します。
ベンダ：バグです。結局フリーですから。。。だから最初から当社の製品を。。。
上司：だったら納品するな。保守ぐらい出来ないでどうするんだ！
漏れ：（心の中、上司に向かって：　　バーカ　　ケチるからだよ！）
・・・・結局、即刻システムは腐り始め、リプレイスでMSの術中にハマってCAL地獄に・・・またこの繰り返しか。。。



飽きたよ

106 ：

>>105 プッ…
すげー、ヘタレ会社だな。バグがあったら自分達でリカバリーする技術力もねーのか。哀れ

107 ：

>>106
上司語録
「保守契約しているんだから、とにかくベンダに直させろ！」
「お前はいじるな！同一性がなくなるとか、前にベンダに因縁付けられただろ！」
フリー、オープンソースって、ソースレベルからの保証が出来る
ところじゃないと、何かトラブったときベンダが逃げるのよ。特に大手はね。
逃げなかったとしても新たな金を要求してくる。結局高く付く。
かえって、小さいベンダの方が小回りが利いて面倒見てくれるよ。
（前にfmlでバグって懲りた。）
それでMS導入しても、なんかでトラブると、「仕様です」。
結局、金をまき上げられるのさ。
うち、社員１万人以上いるところです。

108 ：

>>107
ベンダの逃げ道を片っ端からつぶしまくる、むちゃむちゃ的確な指示ですね＞上司
まぁベンダ側からすればそれでも変にいじられてから呼ばれるよりいいかな。

109 ：

（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）
　 　 　 　 　 　　 ＿＿＿
. 　 　 　 　　　　 |（･∀･）|
. 　 　　　　 　 　 |￣￣￣　　　ｼﾞｻｸｼﾞｴﾝ王国
　　　　　　　　　△
　　　　　　　 △ｌ　|
　　　＿＿△|_.田 |△＿＿＿＿＿
　　　　　　|__|__門_|__|＿＿＿＿＿|＿＿＿＿＿
（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）（･∀･）

110 ：

ＣＧＩにとってかわるものはできてるので別にいまさら必要ないと
思います。

111 ：

>>110 だったら、ageるな。ヴォケ

112 ：

>>110
具体的に何？
Servletとか言わないでよ。あんなオモチャ。

113 ：

>フリー、オープンソースって、ソースレベルからの保証が出来る
>ところじゃないと、何かトラブったときベンダが逃げるのよ。特に大手はね。
ソースレベルで保証するぐらいならサーバーもモジュールも
機能を絞った自家製で固めてしまうわ。組み込みの流儀で。
汎用ソフトの巨大なソースなどコストかかりすぎ。

そんなことよりも、
新しいシステム導入する時にいきなり飛びつくのが馬鹿。
まず社内で使ってみるとかよその運用事例を調査するとか
石橋を叩いて渡る事。いきなり本番の仕事に突っ込んでやけどする奴が馬鹿。
思いつきはダメ。

オレがこうしたいからこれを導入する、ではなくて
これなら大丈夫そうだから使ってみるという思考だ。
クリティカルな仕事の場合にはね。

114 ：

.NET
ﾊﾞﾝｻﾞｲ━━━━━(ﾟ∀ﾟ)━━━━━ !!!

115 ：

あっそ。フーン…(　´_ゝ`)

116 ：

>>112
mod_perl とか PHP とかのもっとおもちゃな方面だと怒る?

117 ：

勘弁してくれ
あんなのアセンブラだよ...

118 ：

テクニカルライター　執筆中なのかな？
.NET本　くだらないか　外人本か、役に立たないのばっかり。

119 ：

ど厨房です。
頭が悪いんでBASICしかできません。
会社でもVB6使っています。
で、VisualBASIC.NET買おうと思っています。
まぁ、1万2千円ですし・・・
掲示板くらいは作れるかな?

120 ：

で、ＶＢ．ＮＥＴってどうですか？

121 ：

>>118
検索してみたら、ほとんどが６月か７月の発行だよ・・・
http://search.shopping.yahoo.co.jp/books_search?p=visual+basic.net&f=0
http://shopping.yahoo.co.jp/shop?d=jb&id=30908737
が2001年の11月だけど、ガリバーさんが書いたんだと・・・
多分、読みにくい訳なんだろうなぁ。

122 ：

>>121
p,s,
読者レビューなんて一つも無いよ・・・

123 ：

&3642;&9745;&3642;

124 ：

ฺ☑ฺ

125 ：

英語本くらい英語で読めよ。訳なんか使うな。
英語できないやつはプログラマー、SE失格。

126 ：

>>125
>英語本くらい英語で読めよ。
英語本を英語以外の何で読むんだよｗ
日本語出来ないやつは日本人失格。

127 ：

>>125
プログラム＝英語だと思ってる厨房ﾊｯｹﾝ（・∀・）ゞ

128 ：

ﾜﾀｼﾆﾎﾝｼﾞｱﾘﾏｾﾝ

129 ：

watasi,
nihonngo,
yoku,
wakaranai,
aruyo,,,

130 ：

C#の名前を聞いたことがあるだけの素人です。
教えてください。
C#はApache上では動かせないんですか？
やはりIISでしか動かないんですか？
サーバーサイドの言語なんですか？それとも、単なるjava Appletの
類似品みたいなものなんですか？
近頃、日本製のPHP統合開発環境を探し続けているのですが見つからず
もう疲れました。本屋に行くと山と積まれたC#の本を見るたびに、
そちらにうつろうかと思うことひとしおです。

131 ：

>>130
なぜ PHP 統合開発環境から C# に行くのかが理解不能だ。

132 ：

DQNだからしょうがない。

133 ：

ゲイツのKissAsserの諸君への煽りなんだよ（Ｗ

134 ：

M$厨必死だなー、ｵｨ（藁

135 ：

謝れとは言いませんがこちらもちょっと大人げないのですが
ムカついたので友達のゲイツに頼んで あなたのPCをWindows機にしてもらうことにしました。 あ、もう遅いですよ。
もうすでに友達インストール始めちゃってますから・・・(^^;
ちなみにこれは自慢じゃないんですがゲイツは世界でも
５の指に入るくらいMS信者です 。
この前彼の家に遊びに行ったらものの５分でオープンソースを攻撃していました。
彼にとってそれくらいお赤子の指をひねるくらいの行いなんですよね(爆)
これでリーナスもいっかんの終わりってやつですね(^^;
まあせいぜい後悔してくださいね。
それからもう二度とLinuxﾏﾝｾｰなんて言わないこと
(ゲイツはオープンソースが大嫌いらしいです。
ソース公開されたら即晒しに入るみたいです(^^;)
それでは、う〜ん二日後くらいかな？また例の所に来てくださいね。
あなたのホストOSその他もろもろのせておきますんで(笑)
あ、警察とかに言ったって無駄ですよ。
あなあはハゲ進行中(犯罪)なんだから通報したところで捕まるのはアナタです????? ゲイツはシェアを自在に操ることができるんです。
と、いうことでbye♪(＾0＾)/~~

136 ：

>>130
統合環境ってなんとなく解る。
やっぱM$で環境構築すれば.netにVSSなどのソース管理、データベースなど、
全てM$製品で統合されてるもんね。
でもやっぱセキュリティー的にどうしてもIISは厳しいね。
まあSUNが何かやってくれるさｗ（注なんとなく）

137 ：

統合環境って便利なのは最初の年だけ。
複数のツール立ち上げてウインドウ複数並べて作業する
ようになると重くてでかくてうざくなってくる。
viって慣れてくると画面あんまり見ないで作業できるように
なるんで目が疲れないよ。
統合環境で細かい表示をジーッと見て作業するとこを、
天井見ながら時々画面をチラリチラリって感じ。
カーソルキーやファンクションキーなしの操作体系のなせる技。

138 ：

M$の「推奨」している統合環境は俺にとっては糞。
はっきり言って押しつけがましいね。
エディタは emacs メイク、コンパイルはエディタから perl とかの
スクリプト起動してメイク自動生成→コンパイル。
ソースファイル管理は rcs とか…
データベースは oracle とか、postgre 使い分け。
みたいな感じで、ここの環境が独立して無くて、全ていっしょくたにして
それを無理やり押しつけている所が終わってる

139 ：

しかしC#簡単だね
ある意味VBより楽かも

140 ：

C# や .NET の構想自体はまあいいんだけど、問題は実装があまりにもアレなこと。

141 ：

これからはKENTできまりに見えた。

142 ：

やっぱり代替となるものはないのかな...C#やってみるか...
Servletみたいなオモチャは論外だし...

143 ：

142=112=ただの煽り

144 ：

.NET = C#
CGI = Perl
と勘違いしている >>1 を煽るスレはここですか？

145 ：

どっからＫＥＮＴがでてくんだＹＯ！！

146 ：

sage

147 ：

うるせーハゲ

148 ：

http://go.iclub.to/ddiooc/
お役立ちリンク集
必ず役立ちます
コギャルとＨ出来るサイトはここ
ヌキヌキ部屋へ直行便
↓
http://kado7.ug.to/wowo/

149 ：

最近ASP.NETというものを使っているんですが
servletより遥かに簡単で楽なんですけど、
参考にするべくサンプルとか探してみても
ASPもWSHもVBScriptばっかで嫌になります。
JScriptは迫害されているのでしょうか。

それはともかくアパッチでASP.NETが
使えるようになる日が早く来て欲しいです。

150 ：

>149
本気でサンプルを探してるんなら、CodeProjectを見るのが一番速い。
あとはGotDotNetの日本語版を読めば、大抵の事は 2日で出来るようになる。
だれか、展開・折りたたみのできるDataGrid教えてくれ…。
プラス、マイナスマークを押したら、カテゴリー単位で表示・非表示が制御したいのです。

151 ：

男は黙ってIISつかっとけ

152 ：

大変申し訳ございません、WebObjects（Win2k)て奴で開発してます。
まぁそれなりに便利です。.netはどうですか？

153 ：

もし、CGIが死滅して.NETが主流になったらPerl.NET使うよ。

154 ：

>>1
はCGIがなんだか、わかってないんだろ。

155 ：

#include <stdio.h>
void main()
{
while(1){
printf("\<\<1必死だな(藁<br>\n");
}
}

156 ：

Delphi7のIntraWebは、ﾎﾟﾄﾍﾟﾀでWebアプリの開発ができる。
WindowsのApacheまたはIISのモジュールにできるほか、
単体のexeにコンパイルすることも可能。
このexeは簡易Webサーバとしての機能も持つ。
exeのサイズは大きくなるものの、単体で動作可能だ。
要するにIISは不要ということだ。
セキュリティ的に危険度の高いIISを排除できる。
さらにネイティブコンパイルされているため、
ランタイムは不要であり、高速に動作する。
鯖にexeファイルを置いて実行させるだけの手軽さ。
簡易Webサーバと言ってもBasic認証などの機能があり、
プロパティを設定するだけで利用可能。
このWebアプリケーションをRADスタイルで開発できるの
だから、ASP.NETなんて利用する気も起きないね。
Kylix 3（Delphi言語版）も同梱！
http://www.borland.co.jp/delphi/del7/feamatrix/
.NETランタイム無くても良くて、Linuxにも逝こう出来ちゃうなんて。
.NETがDelphi/VCLをコピーしたかと思ったやさき。
C#やVBはM$囲い込みの道具だからLinuxどころかWin32ネイティブも出来ないんだからねえ。

157 ：

.net の VM ってオープンソースじゃなかったっけ？

158 ：

ASP.NETって、aspx（デザイン）ありきの、コードビハインドで.csという
概念だが、JSP + ServletのRequestDispatcherとかStrutsみたいな
MVCモデルは、システムとして用意されてないの？
同じオブジェクトを使って、違うcontent-typeの出力をしたいんだが、
いざtext/htmlのページだけ作って、そういうのがないことに気がついた。
結構、controllerという概念、仕様書書きやすくて好きなんだけど。

159 ：

1日VS.NETでASP.NETのサンデープログラミングしてるが、
疲れと共に、だんだん、むかついてきた。
・VS.NETが遅すぎる。セレ650のVaioSRX3だが、このスペックで
　この遅さだと1GHzでもきっと速くないと思われ。
　aspxのコードビューの編集とデバッグモードは遅すぎ。
・Web鯖のポート変えたら、プロジェクトそのものが開けなくなったぞ。
　どうやって変更するんだ???　変なところに依存してんじゃねーよ。
　いろんなところラッピングしやがって独自テクノロジーが意味不明すぎ。
　Unixなら、先人の文化だから勉強する気になるが、MSの作った仕様で
　苦労したくない。苦労しないのが唯一のＭＳの魅力だろ。ASPの簡単さに
　比べると、無駄に複雑な印象。
WebFormsはWebを知らない人にと作ったものらしいが、Web知ってる
人には複雑で、もどかしい。やりたいことができなくて、結局、getで値の
やりとり実装してるし・・・。そういうのはやらずに済むのかと思ってた。
しかし、鯖イベントは、HTMLを読めないと意味が理解できないのでは？
クラと鯖のイベントが、未だにわからない奴が多量にいる現状では、
なんかワケワカになる奴続出に違いない。
・・・というわけで、商売に、特別なメリットなしに.NETを導入するのは、
やめようかと思った。

160 ：

こっちより、プログラム板のほうが参考になるね。
いやみとかでなく、あんまり盛り上がってないようなので・・・

161 ：

あっちも死滅っぽいが・・・？

162 ：

>>159
＞・VS.NETが遅すぎる。
初回アクセス時のコンパイル終われば早いよ。
＞・Web鯖のポート変えたら、プロジェクトそのものが開けなくなったぞ。
テストサーバや稼働サーバのポート変えれば、どっかで設定するのはどんなツールでも共通っしょ？
＞WebFormsはWebを知らない人にと作ったものらしいが、Web知ってる
＞人には複雑で、もどかしい。やりたいことができなくて、結局、getで値の
＞やりとり実装してるし・・・。そういうのはやらずに済むのかと思ってた。
禿同。
実にｲﾀｲんだよこのへんが。
＞しかし、鯖イベントは、HTMLを読めないと意味が理解できないのでは？
＞クラと鯖のイベントが、未だにわからない奴が多量にいる現状では、
＞なんかワケワカになる奴続出に違いない。
これまた禿同。
手の届かない場所のイベントが取れるとは無理が過ぎる。
ここで切る

163 ：

つづき
WebFormsについて多くのメリットや解説を裂いている現状が問題なのであって、.NETそのものが寒いとは思わない。
まず大事なことは、「スパゲッティコードよさようなら」的なまやかしを信じないことだ。
あるいは「DLLヘルはなくなる」なんてことも。
これは「オープンソースは次代を救う」的な屁の突っ張りにもならない神話をUNIXｦﾀが信じ切った過ちに似ている（結局は商売上手に新たなるﾈﾀを提供したに過ぎない＝悪い事じゃないけどね）。
.NETの導入によってWebソリューションの開発が被った最大の恩恵は、まともなオブジェクト指向の一枚岩の開発環境だと思う。
真の再利用可能なコンポーネント指向もやっと実現できた。
今までのCOMベースでは、結局は再利用ってものが単にOLEオブジェクトのインストールと変わらないようなレベルであったように思う。
純粋にクラスなんだかよくわからない参照を使ったり、そういう曖昧さや誤魔化しなどは二次的なレベルに追いやられつつあると感じる。
WebFormsのようにｶｽで使えないものは捨てちまえばいいんだが、これが生きる場面もある。
たとえば.Net Framework SDKのサンプルにもあるが、DetaSetをページ上のエレメントにバインドする作業（便利でありかつテンプレート指定による柔軟性も高い）。
これをコードパート＜＝＞レンダリングパートの行き来をせずにスマートに行えるのは好ましい。
また、コードビハインドも制作物をより取り扱いやすくしてくれたと感じる。
分離されたコード部は記述もよりネイティブな書き方（端的な例がImportsなのかImportなのか）が出来、俺は好きだ。
長くなりそうなので切るけど、細かい部分でも最適化が進んでパフォーマンスも良くなっているよ。
たとえばstringbuilderなんかも良い例だね。
逆にADO.Netは悲観的ロックの未実装など課題も残しているのも事実。
いずれにしても、「やめようかと思った」っていうそのセンスはある意味正しい。
だが、実際にそのままやめてしまうには惜しいよ。
もう少しでイイからいじってみな。
見えてくるものがあるはずだ。
あんたならきっと活用できるし、その価値はある。

164 ：

CGIはついに死んだか。
.NETは産まれる前から死んでたがな。

165 ：

うーん、ASP.NET書くならエディタで充分なんじゃないの？
VS.NET買ったけど、インストールすらしたことないよ。
.NET Frameworkについてくるリファレンスだけで結構事足りない？

166 ：

>>165
インストールもしてないのに必要ないって言ってる・・・
まずはインストールしてみて
オブジェクト名のあとに　.　を打ったり
newのあとに半角スペースを打つ楽しさを感じてください。
それでもダメなら本当に必要ない人なんじゃない？

167 ：

ASP.NETに限定すれば、VS.NETはエディタのみに利用価値があると思う。（個人的に）
VBライクな開発ができるし、インテリセンスが利くし、本当に便利。
ただ、デバッグが致命的に重い。あれでステップインするくらいならデバッグプリント入れたほうがマシ。
というかそもそも今までWeb開発してきた人はデバッグプリント入れるほうがデバッグ手法として慣れているから、あの重さのままではあれでデバッグする人は少ないと思う。

168 ：

>>166
１６５じゃないけど。
確かにそれは楽なんだけれど、どうもVS.NETってがさばるような気がするんだよね。

169 ：

莫迦揃いの日本政府すら見放した .NET。がんばれ .NET!! 俺たちに明日の
ネタを提供してくれ (w
> 電子政府は脱ウィンドウズへ　OSに公開型導入の動き［11/16］
>
> 1 ： ◆y9CAMELxSM ＠キャメルφ ★ ：02/11/16 06:06 ID:???
> ■電子政府、脱ウィンドウズへ　ＯＳに公開型導入の動き
> 　政府は、インターネットを通じて申請や検索ができる「電子政府」の安全性を高めるため、
> 政府内ネットワークのコンピューターで採用する基本ソフト（ＯＳ）の見直しに乗り出す。
> 設計内容が公開され、独自に安全対策を講じられる「オープンソース」と呼ばれるＯＳの
> 採用を想定。現在は政府内コンピューターのＯＳの大半を占めるウィンドウズから切り替え
> が進む可能性が高い。
>
> 　オープンソースＯＳでは、設計図にあたるソースコードが無料で公開されている。「リナッ
> クス」が代表例。利用者はライセンス料を支払う必要がない。プログラムの変更も可能で、
> トラブルに対応するためのシステム管理がしやすいとされ、世界的に導入の動きが出ている。
>
> 暫定ソース：
> http://www.asahi.com/paper/front.html#top

170 ：

MSもLINUXもUNIXもすきだけど、
　Opensourceマンせー、MSはゴミみたいな発言をするカルトな馬鹿が嫌いだな。
　逆もやだけど。

171 ：

オープンソースマンセーなやつらって何でソースもみたことないのにえらそうなこといってんの？
っていうかソース読めない奴。俺も読めないけど。

172 ：

>165
あんたの書くASP.NETのソースが、
1.Request
2.Requestパラメータの処理
3.DBのアクセス
4.Responseデータ作成
5.Response
で終わるならエディタで十分かと。要は、元来ASPが担っていた
メインの用途だ。
それよりも、１階層でも深いクラスの階層を作っていこうと思うなら、
絶対に統合開発環境があったほうが良い。
ASP + COM（メインはCOMだが）で、WebServiceToolKitを試したときは、
途方に暮れたぞ。

173 ：

>163
一ヶ月半も前の書き込みのレスだから、気がつかなかったよ。ｽﾏｿ
今度、プルダウンメニューに連動して動的にテーブルを切り替える処理を
JSP + Servletでやらなきゃならない。ASP.NETなら、こういうのすげー
楽だよなぁ。何せ、ベタなform + JavaScriptのやりとりを自動生成
してくれるわけだから、工数削減には確実に寄与する。実際、同じやり取りをする
JSP<-->Servlet連携の設計書書くのがバカバカしい。
で、漏れじゃないが、昔、同じ実装をASP + RemoteScript + DHTMLでやってしまったんだ。
それのメンテは最悪だよ。まさにパズルを解くようなデバッグをしなきゃいけない。
鯖側の通信Objectが理解できないと何も帰ってこないし。
そんな技術を作るMSもMSだが、あぁいうDHTMLの発想がASP,NETの発想の原点
ではあるなとは思う。そういうのを経験してるから、漏れ自身はASP.NETの
イベントの発想はとても進歩を感じてるよ。ようやく、まともな開発ができる！って。

174 ：

上のつづき
あと、これだけは間違いないのは、とても便利なクラスライブラリが、
一パッケージに標準として入っているのは、すごく使いやすいのは確か。
恥ずかしながら、ドキュメント日本語っつうのも含めて。
最近のお気に入りクラスライブラリは、XMLのソートが簡単に
できる奴だな。週末プログラムでソートなんて地味な処理書きたく
ないんで、とても役に立ったよ。
また、最近思うことだが、鯖はUnix Java or ASP,NET、クライアントは.NETのWinFormsを
使い、インターフェースはSOAPを使って、Webの管理ツールや簡単な業務系でクラサバ的に
Webアプリを組む発想が復活するんじゃないかな。
Flashのことを日経ではクラサバの復活とかほざいてるが、そのレベルでクラサバ
云々言っていいのなら、UIの完成度も生産性もFlashの比ではないんだから、
こっちこそが本命だろう。
次に設計する予定の奴もJava鯖ベースなんだが、ゆくゆくはUIを、ヘボいブラウザ
だけじゃなく、WinForms＋SOAPに入れ替えられるように設計するつもり。

175 ：

自分で会社おこせや

176 ：

>>173-174
禿同
最低でもJavaは標準のドキュメントをMSDN並にしてほしいよ
Javaやってるけどやることなすことくっさく思えるね。

177 ：

オープンソース(以下OSS)、本当に騙している?
ハロウィン文書( http://cruel.org/freeware/halloween.html )によれば
Ｍ弗はOSSを恐れているらしい。
金があってもテクノロジがない組織の製品は、そんなに長寿な信頼性を維持できないだろう。最近ハロウィン文書7が公開されたところによるとM＄がOSSを恐れていることが確実になったらしい。
JavaがOSに依存しないのに対してC#(.Netの中心?)は言語に依存しないらしい。
しかしこれには大きな落とし穴が...。
COBOLしか使いたくない者とVBしか使いたくない者、C#だけしか、Javaだけしか、FORTRANだけしか、、、などといっている者同士が団結してまともに大規模プログラミングなどできるのだろうか?
バグとりがとても恐ろしいことになりそうだ。
「言語にこだわらない」なんて向こう見ずになりすぎると、みずほ銀行(COBOLやFORTRANを使っていたらしい)の二の舞になると思う。
(Webプログラミング向けとしての)CGIがいずれ廃れるのはほぼ確実か?
Sunのスコットマクリーニは来日したとき(今年春頃) .NETのことを ドットノットと馬鹿にしているようだし.NETはウィルスだと相変わらず強烈な毒舌を吐いたようだ。

178 ：

>177
落とし穴も何も、.NETの「言語に依存しない」から、多数の言語でシステム
作る奴なんて、実践する奴いないだろ。
ありゃ、ただのマーケティングだろ。おかげで、富士通はCOBOLを作り、
ボーランドはDelphiを作るわけだ。コアは、Windowsなんだから万々歳だろうな。
こちらは、これまでのC++のCOM + VBのプログラミング程度の
認識でいれば、何の問題もないだろう。
まっとうなマネージャーだったら、２種類以上のマルチ言語なんて許さない。
作った奴がいなくなったらメンテできないようなマイナー言語を使わせる馬鹿が
どこにいる。
COBOLは知らん。COBOLから抜け出せない奴は、言語の書き方ではなく、
オブジェクト指向の設計で悩むんじゃないのか？
ちなみに、ＭＳがNetscapeやRealNetworksをタダ製品でメタメタにしたのと同じく、
自社のコアビジネスモデルであるOSとDBをタダにするオープンソースが怖いのは
当たり前だよな。労働の対価にお金を貰うという、単純なビジネスモデルが曖昧だから、
玉砕的に見えるのは確かだしね。

179 ：

言語に依存しないも何も、C# なんかで作った GUI アプリは結局 Win 以外じゃ
動かないじゃん。NOMO 連中もさじ投げて WINE 入れれっつー事になったし。
エミュもどきいれて動きますって言われてもただの詐欺だろ。

180 ：

金があれば優秀な人材を雇えるのを忘れなる。そんなこともわからんのか、
三流馬鹿が。M$にはお前より優秀な人材は五万といる。っていうか
おまえがすげープログラマーなら向こうは実力にあった給料で
迎えてくれるぜ。というと信者と言われるが、仕事はLINUXでやってる

181 ：

>180
誤爆？
誰に言ってるんだろ。誰もMS社内の心配なんてしてないと思うけど。

182 ：

ﾌｪﾗﾃｨｵ

183 ：

>180
確かに忘れてはならないと思います。
M$が甘い汁で迎えてくれても、(経済的に余裕があれば)拒否するかも。迎えてくれるほどの能力はいまは無いけど。
金があるだけじゃ、夢を実現できぬ。
金だけでなく技術も必要。夢や技術だけじゃ金は入ってこないけどさ。
>178
マルチ言語を許さない。やはりこれからの時代は、既存のコードを再利用しない限り、そうあるべきですね。M＄の.NETは多くの技術者にとってM$の誇大な宣伝、情報操作、戦術としか見えないんですね。
ということは、これからはC#と.NETできまりとは言い切れない?
参考になりました。Thank you.

184 ：

金があるー＞優秀な技術者を雇えるー＞優秀な技術を作れる
SUNなどがリストラするなか、M＄だけが利益を拡大させてる。
金があれば、東大、京大、MIT,ハーバード卒の学生、経験者も
余裕でやとえる。もちろんM$が嫌いな奴はやとわれんが、
この時代金だろ。

185 ：

>>178
しかしですよ、C#で作ろうが、VBで作ろうが、コンパイル後の動作はほ
ぼ一緒という結果が出ている限り、できるだけ作業効率の高い言語を
使うべきではないかと思いますよ。
ASPからASP.NETに移行して、全部C#で書き直していますが、へぼ
プログラマにとっては超えにくい壁に結構あたって大変なんですわ。
なので考えるのがめんどくさいところは全部VBで書いたクラスに引
数渡すことにしてるであります。

186 ：

C#くらい使えろよ、ヽ(・＊・)ﾉｱﾅﾙ野郎

187 ：

>> 185
コンパイル後の動作とは、速度のことですか?
もし速度だとしたら、
速度を重視するよりもオブジェクト指向的な拡張性、可搬性、コードの可読性を重視するからVBではなくC#を使うのでは?
VBは型の概念が曖昧だから、余裕ができたらC#に移した方が良いかと。
型が曖昧な言語は大規模化(複雑化)するとソースが読みづらく、何が起こるか、どんな潜在的なバグが発生するかわかりにくくて怖い。
M$側もVBプログラマをいかにしてC#に移行させるか、ということを心配しているようですし。
C#もJavaよりも余計に余分な機能が付いているのが、かえって仕様を複雑にしコードの可読性を低下させる素を持っているかのようで奇異にみえます。

188 ：

>>173
どんまい。
ＭＳの上手さを感じるよ。
昔JSP+Servletをやって、わけあってやめたんだが、その「わけ」の部分に対する回答がかなり盛り込まれている気がするんだよね。
１５９とそのへんは同じ感覚なんだろうな。
ASP+RemoteScripting+DHTMLについて、ASP + RemoteScriptingってところまでは有りだと思うんだよ。
そこに+DHTMLってのがかなり辛そうだ。
DHTMLってのも込み入ってくると、DOMレベルのバグなんだかコードのバグなんだか判断が面倒になる上にリモートの要素まで関わってくるからな。
そうしたほうが良さげなケースでも、どうしても避けざるを得なかった。
加えてjavaに関する不信感かなあ・・・（笑）

189 ：

>>174
うん、その一貫したクラサバのアーキテクチャの鯖側にWebアプリケーションがあるってのがずっと求められてきた姿だと思うんだ。
それを実現するためのプロトコルがSOAPであり、またXMLでもあった。
ただこれらの土台ができあがっているにもかかわらず、それを有効に実装する岩盤みたいな存在が不足してたんだよね。
あまたの企業が寄ってたかって料理しようとしたけれど、結局はたいしたものは出来上がらずにここまで来た。
１５９が言うように、Flashでクラサバ復活云々なんてのは寝言以外のなにものでもなくって、まさに.Net的な総合的（総合的ってのが大事）アプローチが大事で、それさえ著に付いたばかりだ。
矛盾しているようだけど、「高機能なダム端末」なんだよね、ブラウザの使命って。
それ以外にWinForms+SOAP、あるいはモバイルベースのWinForms+SOAPの実装が見えてきてこそ、Webアプリケーションの存在価値が上がるってもんだね。
UIを入れ替えるっていうか、できるだけデータ交換のレベルでアプリケーションが動作しているように設計していくことが望ましいと思うし、それこそが.Net的であるんだろうね。
お互いに頑張ろう！

190 ：

>>189
「高機能なダム端末」
まさにtarantella

191 ：

>>187
オブジェクト指向的な拡張性、可搬性、コードの可読性はVB.NetとC#そこまで大きく差があるとは思えない。
また可読性って事に関しても、それはあくまで主観的な問題であろうし、どんな言語で書いても善し悪しが出るのは個人差ではなかろうか？
.Netに関する板だからあえて言うけれど、.Net以後のVBで型は曖昧ではない。
それからMSはC#にいかに移行させるかなんて心配はしていないと思う。
最大の関心事は、「いかに膨大な数のVBプログラマーをそのまま.Netに移行させるか」だ。
言い換えれば、これは「いかにVBからVB.Netに移行させるか」と捉えるのが自然。
またC#javaよりも余計に余分な機能が付いているってのもなんだか不自然に聞こえる。
機能ってのはあくまでclassからの派生のことでしょう？

192 ：

>185
自分達でコンセンサスが取れてれば、ＶＢ使おうが、ＣＯＢＯＬ使おうが
かまわないと思いますよ。それが.NETのメリットなわけだし。
しかし、１年後に、ソース書いた奴が、会社、やめちゃったりして、
後日、クラスのソース開いて、いきなりCOBOLで書かれてたら途方に暮れるだろうなぁ。
あと、VBとC#で、ループのカウンタの取り扱いとか変わったりしない？
忘れちゃったが、VBのuboundとC#のlengthって違う値になるんだっけか？
仮に、それが違ってたとして、そういう細かいところで、エラーにならない
不具合を作っちゃったら最悪だし。作業効率とは裏腹に、間違いの可能性
を減らすってのも、避けたい理由かなぁ。

193 ：

>>192
でもCOMコンポーネントと同じ感じで完全パッケージ化させてしまえば中の言語なんてどうでもいい。
その辺を考えれば単純に１つのプロジェクトだけで考えるんじゃなくって過去の共通クラスを流用とか、
コントロールクラスを持ってきてバージョンあげていったりとかできるわけよね。

194 ：

C#てソフト開発からWEBプログラミングまで出来るんですか？

195 ：

>>194
おう

196 ：

>193
Basp21のように完結した汎用モジュールなら、それもアリだが、
実際は、流用して改造したり、後日オーバーロードして拡張したくならない？
（継承ではなく・・・。）
ＭＳもカプセル化による隠蔽が多言語利用の前提になってるような気がする
んだが、そこまでの汎用化は、漏れ的には、考えてる暇はないので、
最終的には、拡張、拡張で汎用モジュールの機能アップを実現したいので、
「完全パッケージ化」という発想自体が、なかなか理想的な話だとは思う。
漏れ的には、汎用モジュールであっても、後日の情報共有のしやすさ、
カスタマイズのしやすさを重視したいなぁ。
その辺は、どのようにプログラミングするか？という話なので、あくまで
「ウチの場合は」ですけどね。しっかり隠蔽して流用できるものが作れるなら
おっしゃるとおり。

197 ：

>>196
でもC#でしか作るきないけどね。
今までのMSの言語体系って
C++,MFC <=上級者
VB <=初心者、中級者
っていう扱い
でも、この全部を内包してC#に移行できるだけのパワーがC#にはあると思うよ。
結局全社で統一させる場合にはC#かVB.Netでしょう。
でも、私としてはどっちの言語で書かれていても同じことだからかまわないなぁ。
XMLWebサービスなんか言語は外からわからないしね。
COBOLのバッチプログラム -> COBOL.NetによるXMLWebサービス
こんなんができれば最高だとは思う。

198 ：

http://www.agemasukudasai.com/bloom/

199 ：

>>191
確かに個人差が無いとはいえない。集団でプログラミングするときコーディング規約、ある程度はガイドラインを定義すればどうにかなるかもしれませんね。
C#がJavaより余分な機能があるというのは、
class からの派生とかではなく、
Javaでは複雑になるからとC/C++あった機能を排除したが、
C#では復活している機能(仕様?)があるということです。(機能とは言わない?)
JavaにはないがC#にある仕様(機能?)を適当に列挙
- Cとはちょっと異なる構造体の復活
- unsafe 修飾子によってそのスコープ内でCのようなコード(ポインタ、アドレス操作可能なコード)の埋め込みが使える。
- 列挙型の復活
- JavaBeansに相当するプロパティ機能がデフォルトで使える、set, get修飾子使用。
- メソッドの引数の種類(参照引数、出力引数、可変長引数)が余分に増えた - デレゲート
- 演算子のオーバーローディング
- インデクサ
- Javaのプリミティブ型に相当する値型がJavaよりも数個余分にある。ushort,ulongなど。

200 ：

続き
便利とはいえ、こんなに余計な機能が多くあるとこれらを使ったソースコードの解読、修正、バグ検出するとき、Javaで書いたのと比べると苦労しそう。なんでもできるということはその反面ソースコードを読みにくくする。
余計な機能を追加するくらいならクラスとして提供すればいいのではないか、というのがC#の仕様を見たときの感想。
C#で集団で新規にコーディングするときにこの機能は使うな、と規定を定めればどうにかなるかもしれません。
しかし、誰か個人がコーディングしたこれらの機能をフルに使用したコードを流用したいときがあるかもしれない。そのときそのコードがどれだけ正確か、などを確認することも起こりうると思われる。
Ｍ＄は妙なガイドラインを発表している。クラスやインターフェースを継承するとき、クラスとインターフェースどちらを継承しているかわからないのでインターフェース名の頭にIをつける、これは厄介そう。
Javaならクラスの継承を意味する修飾子は、extends、インターフェースの継承を意味する修飾子は implementsでありこれをみるだけですぐにクラスかインターフェースかがわかる。

201 ：

続き
C#だと :: なのでわからないためにインターフェース名の頭にIをつけているのだろう。::の方短縮できるからいいだろう、C++プログラマのために、と思ってこのようにしたと思われるが。言語仕様の設計そのものに問題があるようなきがする。
クラスやインターフェースがあれば構造体も列挙型もいらないような気がする。これらは、速度を高めるために、Javaのプリミティブ型に相当する新しい型を定義する取り入れられた機能と思われる。
オブジェクト指向的な観点で言えば、本来型はすべて参照型にすべきと思われる。が、C#の構造体は値型。継承できない構造体とクラスをうまく使い分けるっていうもの大変そうだ。
演算子のオーバーローディングもクラスとメソッドを定義すればいらないだろう、と思う。記述方法が短縮できる以外にメリットは無い。逆にコードの可読性が低下するという欠点がある。
速度を気にしなければ構造体も列挙型も不要と見える。
C#をプラットフォーム非依存にさせると目指しているM$の発言にも不信感を感じる? 言語非依存にすればC#以外の言語でかかれたものがプラットフォーム非依存な言語であればWin以外の他のOSでは使えない。.NETも同様?

202 ：

連続投稿の最後です
.NETの利便性というのは殆どがWinに依存しており、セキュリティ性、プラットフォーム非依存性の犠牲の上に成り立っていると思う。
.NETで開発するときはこのあたりを大いに覚悟しなければならないと思う。

203 ：

>>199
そうだね、確かに数々の指摘はその通りだと思うよ。
それらは機能というより仕様だね（レスに書いてくれたけど）。
インターフェイスに関する存在の冗長性やオーバーローディングの曖昧性も、仕様としてはかなり不細工に感じるのは自然だと思う。
ただ、それぞれにはそれなりの存在理由があるので、言語として整理整頓されましたということが自慢できた時代とは異なる昨今でプライオリティが低かったのではないかな。
それから保守などについてだけれども、圧倒的多数のコードの寿命が極端に短くなった現在、次々と新しく書き直されることがより求められている気もする。
C#をもっとブラッシュアップしてしまえば良かったのにって思うけれど、VBについては、まあこの程度でよしとして良いんじゃないかな。
セキュリティもひっくるめたあらゆる利便性がWin依存というのはなかば当然だと思う。
もっとも、これはC#などに限らずあらゆる言語や環境に言える事じゃないかな。
たとえ言語がオープンであっても、圧倒的多数のクライアント環境はWinであり、Winには固有のシェル環境があり、またインターネットへの一般的窓口であるブラウザはIEが多い。
最適化した実装を施したいと考えればその縛りは必ず受けざるを得ないよね。
この企業の姿勢は「客」という存在を絶対的な立場から見てどこにあるかとらえて徹底した征服を行い、誰しもがそれに依存せざるを得ない状況を作り上げることにある。
それが今後も変わるとは思えない（善し悪しということではなく単純に考えての話ね）。
それに、恐らくＭＳのセールストークを全部信じてわくわくしている開発の現場って限りなくゼロに近いんじゃないだろうか。

204 ：

言語の話からはそれるレスだけど、ASP.NETが吐き出す自動生成サーバー
連携HTMLは、HTML3.2の仕様を満たすんだったけ？
.NETが最初に発表されたころのセミナーで聞いた話だから、実際
古いネスケ4.04とかで、どう動作するのかは検証してないけど、
サーバーサイドオブジェクトなどのイベントモデルを作った最大の
メリットは、POSTを主体としたサーバー通信を自動化しているところで、
その目的は、IEに依存しないというところだと思う。
そういう部分では、.NETという枠組みでは、普遍的なところへの
チャレンジがあって、これ自体は、とてもMSっぽくないなと思って
わくわくした。（ただ、FAQになりそうなのが、サーバーサイドの
プルダウン選択したら、FlashやEmbedのWMPが初期化されちゃいました。
バグですか？・・・とか。）
ところで、IE EmbedできるActiveX OCXって、作れないん
だよねぇ・・・。アプレットの入れ替えとか言って、
サンドボックスのセキュリティとかになってしまうと、
困るんだけど。ActiveXは、わかってて使う、悪魔の魅力こそが魅力なので。

205 ：

たとえばJavaになくってC#にある機能っていうのはJavaの開発してたらなんでやねん、
なんでないねんていう機能ばかりじゃないか？
- Cとはちょっと異なる構造体の復活
Javaで同じValueClassを書くのは無駄にコード量が増えるだけ
- unsafe 修飾子によってそのスコープ内でCのようなコード(ポインタ、アドレス操作可能なコード)の埋め込みが使える。
これは基本的にしちゃいけないから、かなりガードは高い。
でもやりたい時には最悪許してあげるっていうスタンスかな？
- 列挙型の復活
これも同じことをしようとすると意味もなくコード量が増える
- JavaBeansに相当するプロパティ機能がデフォルトで使える、set, get修飾子使用。
VBと同じような機能
何でもありの変数はgetter, setterを書く必要なんかない。
publicにしたらいい、チェックが必要になったりしたときにプロパティにして
コードを書けばいい
- メソッドの引数の種類(参照引数、出力引数、可変長引数)が余分に増えた - デレゲート
関数ポインタがないためにJavaでは何をしていたか、しているかを考えれば当然
- 演算子のオーバーローディング
これは賛否両論あるけど、文字列比較がすっきりしなきゃ言語としてどうかと思う。
Java: stringA.equals("ABC")
C#: StringA == "ABC"
VB.Net: StringA = "ABC"
=なんかの演算子には等価という意味合いが強く現れるので、構文的にはC#とかの方がいいと思わない？

206 ：

続き
- インデクサ
java: a.get(1)
C#: a[1]
Cのchar*なんかの時と似てるけど、レコードはインデクサなんかが似合ってると思わない？
- Javaのプリミティブ型に相当する値型がJavaよりも数個余分にある。ushort,ulongなど。
これはちょっと問題かもしれない。
CLRでは動くけど、CLIでは動かない範囲ですね。
わたしはこれらのunsignedは使わないと思うけど、最悪ガリガリのチューニング用か？

>Ｍ＄は妙なガイドラインを発表している。クラスやインターフェースを継承するとき、クラスとインターフェースどちらを継承しているかわからないのでインターフェース名の頭にIをつける、これは厄介そう。
昔はクラスにCをつけるようにとなっていたよね。
Javaをしていると継承関係がややこしくてインターフェースかクラスかわからなくなるよ。
でも.Netのように現在は入り組んでないライブラリでも、今後入り組んでいくとおもう。
その時に真価を発揮すると信じているよ。
どうせならコンパイルオプションではじける設定もほしい

207 ：

あと忘れ物だ
!!!throws!!!
これってあんまり役に立っていないと最近思う。
RuntimeExceptionはつかまないし、ほとんどつかみたいのはruntimeだって。
この機能はスパッと切って正解だったと思うよ。
!!!ボクシング／アンボクシング＆すべてがobjectを継承していない!!!
javaでは値型が特殊な変数になっているためにVectorなんかにそのまま入れれない。
これって誰も言わないんだけど致命的な設計ミスじゃない？
んじゃ

208 ：

厨が長文Rーしてるのはこのスレですか？

209 ：

論理的に説明してる気かも知れないが長々と主観を連ねただけだな。

210 ：

今時の高等言語はどれをとっても一長一短でしょ、いずれにしても。
無駄な関数や多少の冗長性があっても大した問題ではないしね。
表面的な実装がどうであるかよりもむしろ深層部分で変数・型をどう扱っているかとか、もろもろ無茶苦茶細かい部分に関する部分が気になるでしょ。
そうして、そのような箇所はそれなりに時代に合わせた設計が為されているしね。
ここ１０年の流れとしては、「どの言語がどれだけ素晴らしいか」ということでなく、「どの言語がどれだけ<<実効性のある総合的環境>>を持つか」じゃない？
Javaにしてもそうだったし、インタープリタがあらゆるブラウジング環境に実装されだした流れにしてもそうだった。
今後もそうとう長い期間、そんなＭＳ的なるアプローチが支配的であるように思うな。
理念の先行や重厚な布陣よりも、即効性とゲリラ戦が主流でしかあり得ないだろうし。

211 ：

.NET も寒々としとるなぁ。

212 ：

.NETでDBを扱う場合、DBがSQL Serverの場合とOracleの場合って何か違いがありま
すか？.NETやるならSQL Serverの方がイイ！っとかあります？

213 ：

>>212
そもそも現時点ではSQLServerとOracleでは扱うライブラリが違う。
ADOみたいに１種類のライブラリでSQLServerもOracleも同じ操作でアクセスできるということはない。
現時点では、
・SQLServerを使うならADO.NETと呼ばれるライブラリ（System.Data）
・Oracleを使うならOLE DB .NETと呼ばれるライブラリ（System.Data.OleDb）
を使い分ける必要がある。
クラス名からメソッド名からみんな違うので注意が必要。
現時点では.NETではSQLServerが最適と考えたほうがいい。というか他のRDBベンダ（OracleやSybase、IBM）に
.NET専用のライブラリを提供しようという気がない。（OracleはMSが対応ライブラリ出したらしいけど）

214 ：

>>213
SQLサーバは System.Data.Sqlclient
Oracleはオラクル用のドライバが出たからSystem.Data.OracleDriver?かなんかで使える。
クラス名は違うけど基本的に同じだから置換するだけでつかえる。
ただ移植度はADOより下がっているのは事実かもしれないね。
これから選ぶっていうならSQLServerだとは思うけど、Oracleだから敷居が高いなんてことはないから安心して。

215 ：

>>212,213
Thanx!
うちはプチOracle使いからプラチナマスターまで揃ってるOracleマンセーな
ところなので.NETはイカンのかと思ってましたよ。
移植度が下がるってのはどういうことでしょうか？うちだとSQLでselect文も
DDLもDMLも書いて、ADOでレコードセット開いたり、コネクションで実行して
ましたよ。それができないって事はないんでしょうけどどの辺が下がるんです
か？

216 ：

>>214
System.Data → System.Data.Sqlclient
補足してくれてthanks。
>>215
>移植度が下がるってのはどういうことでしょうか
たぶんSQLServerからOracleにRDBを移植する時にコード修正の必要があるということでは？
ADOだったらConnectionStringを変更するだけで95%くらい移植可能だったんだけどね。
ちなみにうちの会社ではOracle＋.NETのシステムをこの前作ったよ。ASP.NETじゃないけどね。

217 ：

訂正。
漏れは>>212じゃなくて>>213だった。

218 ：

>>216
>たぶんSQLServerからOracleにRDBを移植する時にコード修正の必要があるということでは？
それもそうなんだが、たとえばレコードセットで,movenextだ .updateだって使っていた場合には
接続文字列の変更だけなんだけど、.Netの場合自動生成でSQL文が出来るやり方があるし、それが主流
そうなると、どうしてもDB固有の機能が出てきちゃったりする。
私はDB固有の機能を使うの賛成なんでDBかわったらとうぜんソース修正して、最適化すべきだと思う。
シーケンスとIDENTITYとかもあるしね。
わかりにくくてごめん

219 ：

皆さんレスどうもです。
.NETにはSQL Serverじゃないとイカンのか！？という問題は、
.Oracleも可。ただし、.NETではADOを使わない(使えない？主流ではない？）ので
SQL Server<->Oracleの移植性は落ちる。
って事でしょうか。
.NETでのDBの扱い方とか色々勉強になりました。どうもです。

220 ：

>>219
.NetではCOMを利用できるからADOも当然利用は可能。
どうしてもサーバカーソルが必要な時になんかしか使わんときましょうっていうのが路線です。
SQL文がOracleとSQLさーばで互換性がないんだからその辺の移植性は仕方ないよね。
OracleとSQLサーバしか知らんけどDB2とかPostgreSQLとかどうなんかな？

221 ：

RCWやCCWなんて本当に使い物になるの？

222 ：

>>220
どもども。大変勉強になります。
ありがとうございました。

223 ：

ウィンドウズベースでならM$　SQLつかっとけば？

224 ：

>>219
ADOはADO.Netになっているねえ。
その辺のことはリファレンスにきちんと書いてある。
やっぱさ、一通りでいいからリファレンスって読むべきだと思う。
.NetになってからCOMをどう使うかってのも、各種資料では優先的な課題としていくつも例が挙げられているよ。

225 ：

>>220
共通仕様ののSQLの範囲であればどれも一緒だけれど、各ベンダーはもれなく独自の関数やメソッドを持っているよ。
だからOracleとSQL Server程度に互換性はない。

226 ：

>>225
ま、そういうところやろうね。
ADOでRecordsetでのアクセスであってもほとんど、MoveNextとかを駆使する方法じゃなくって
更新はConnection.Executeでやっているのがほとんどだろうから、ADOと大して変わらない
という説明でもいいかもね。

227 ：

aspがLINUXサーバーで使用できるなら
C#使ってもいいよ
WINDOWSサーバーは高いしセキュリティー貧弱で
ウィルス攻撃の的になってるから
aspは流行らない

228 ：

>>227
Windowｓを攻撃したいのね。
難癖つけて

229 ：

【ついに】Winnyで逮捕者【でた】
愛知県で初の逮捕者！
↓↓↓↓↓↓実況スレ↓↓↓↓↓↓↓
http://choco.2ch.net/test/read.cgi/bobby/1038742045/238
↓↓↓↓↓↓実況スレ↓↓↓↓↓↓↓（うｐ済み
http://comic.2ch.net/test/read.cgi/gcomic/1035547729/741

230 ：

>>229
それもう古い。
新しいネタ考えろ能無し

231 ：

>>225
しかしDB2はストアドプロシージャの記述がSQL鯖・オラクルとは違うような印象がありますです。

232 ：

>>220
サーバカーソルってことは、.NETでフツーに開発するとDBへの問い合わせが遅
くなるんですか？
>>224
うちはまだ.NET使ってないからドキュメント無いんですよ。MSDNのWEBやCDに
入ってるかな。見てないや。

233 ：

２２７がC#使ってもどうなるわけでもないし
その前にC#つかえこなせないだろ藁

234 ：

>>232
逆。
ADO.NETはサーバとは非同期型のクライアントカーソル。
ADOはサーバと同期を取るクライアントカーソル。

235 ：

>>234
>>>232
> 逆。
> ADO.NETはサーバとは非同期型のクライアントカーソル。
> ADOはサーバと同期を取るクライアントカーソル。
おしい。
ADOはクライアントカーソルと、サーバカーソル両方使えるのが正解。

236 ：

>>235
スマン。ADOのほうはクライアントカーソルは意図的に省いた。
ADOの場合、主流（というかデフォルト）はサーバカーソルだし、
UseClient（だっけ？）モードの実装はベンダに委ねられているので、
確かプロバイダによってはクライアントカーソルをサポートしてないものも
あるらしいと聞いたので。

237 ：

>>234-236
勉強不足で同期型、非同期型ってのは聞いたことないっす。あとで調べるか。
つまり（強引か？）ADO.NETだと速くなると？

238 ：

>>236
同期を取るクライアントカーソルと書いてありますが・・・
ま意図はよくわかります。

>>237
要はADOは細かくDBとアクセスする。
ADO.Netは最初と最後にどかんとアクセスする。
だから、ADO.Netの場合にはアクセスの数が少ないから早いけど、シリアライゼ
ーションで若干問題がある。
バッチ処理なんかはADOを使わざるを得ないかも（試してないんでわからんが）

239 ：

>>231
えーと、だから共通仕様のＳＱＬってのはＳＱＬ９２のことね。
ＤＢ２には当然ＤＢ２の方言があるんだからオラやMSSQLとも違って当然っしょ？

240 ：

>>228
プアーなLinux厨なんだからいちいち反応せずともヨロシ。
言ってることド素人なんだから放っておけよ。

241 ：

>>232
.Net Framework SDKにかなりのボリュームの資料があって、これがなかなか参考になるんだ。
例題も豊富なので、是非目を通してくれ。

242 ：

>>236
ADOの主流がサーバカーソルなのではないぞ。
サーバカーソルはあくまでデフォルトであるだけで、クライアントサイドにカーソルを実装しなければならいケースが非常に多いので、かえって逆だろうと思う。

243 ：

>>203
シェアは殆どがWin。クライアントマシン側ではそうですね。
しかしアプライアンスサーバ至上ではサーバOSのシェアはLinuxのほうが上という結果もでているそうです(今は違う?)。これはM$KKの阿多氏も認めていたような..(違うかもしれない)。
中国ではTurboLinuxのシェアが7割りという発表が数年前の記事にありました。
>恐らくＭＳのセールストークを全部信じてわくわくしている開発の現場って限りなくゼロに近いんじゃないだろうか。
学生個人が勉強する上では、VB, VC++経験者が、信じてわくわくしながら楽しんでいる学生が多かったりということはありそうです。
初心者な人も結構信じていそうです。
学生アルバイトを紹介し他者に派遣するある派遣会社の社員は、
「これからはC#だ、C#だ、JavaはC#によって廃れていく」と学生に言い回っていました。
Javaのことをよく知らない人たちが多く、ASPのことをよく知っている人たちが多かったので、そのことを鵜呑みにする学生が数人はいました。
学生たちは、JSPとLinuxという言葉を聴くだけで嫌な顔をしていました。
Javaは遅いからASP以外はいらない、と思い込んでいる人もいるようでした。ASP以外は勉強したくないと。
中小企業では.Netを使う企業が多いのでは無いかと思います。
Sunがハイエンド企業をターゲットにした戦略を練っているのに対し、M$は中小企業をターゲットにしているようにみえます。
お金に困っているIT系中小企業の多くがM$からの圧力により.NET, C#を迫られて開発に使用しているように見えます。実際、「M$からの圧力によりJavaからC#への以降を迫られている」というある小企業もいました。

244 ：

>>205
> たとえばJavaになくってC#にある機能っていうのはJavaの開発してたらなんでやねん、
> なんでないねんていう機能ばかりじゃないか？
> - Cとはちょっと異なる構造体の復活
> Javaで同じValueClassを書くのは無駄にコード量が増えるだけ
> - 列挙型の復活
> これも同じことをしようとすると意味もなくコード量が増える
それは個人の主観と思う。
最近のXP(eXtreme Programming), RUP(Rational Unified Process)な観点から見れば、コード量が増えてでもソースコードは他人に読みやすい方が良いのでは、と思う。
このクラスは継承できる、と思ったら構造体だった、というのも...。
また、構造体や列挙型はUMLで的確に表現できるのでしょか?

245 ：

>>205
> - 演算子のオーバーローディング
> これは賛否両論あるけど、文字列比較がすっきりしなきゃ言語としてどうかと思う。
> Java: stringA.equals("ABC")
> C#: StringA == "ABC"
> VB.Net: StringA = "ABC"
>=なんかの演算子には等価という意味合いが強く現れるので、構文的にはC#と
>かの方がいいと思わない？
== のほうがすっきりするといえばしますね。
しかし、 == とequalsとを使い分けたいときには面倒なことになると思います。オブジェクトの中にある特定の変数が同じであっても、それを別のものとみなして扱いたいときにはこの機能はちょっと困り者です。
ある==がJavaのequalsに相当するものか、それともJavaの==相当するものなのか、を区別するにはどうすればいいのか、というときに困りそうです。
"Javaの鉄則" という本にはオブジェクトの等値の扱いについて注意すべき項がよく載っている。
例えば、クラスAのオブジェクトと、クラスAを継承したExtendedAのオブジェクトを比較するとき、equalメソッドをどちらのクラスに実装するかを考えなければならない。
また、親クラスと子クラスのオブジェクトを同一とみなすか同かも自分で定義しなければならない。下手に instanceof 修飾子を使うのも良くない。
かといってC#のようなオーバーローディングだけはどちらの等値メソッドを使うかという使い分けをすることができない。
こういう状況にあるときだけ、==と定義したeqauls()メソッドを使い分けてもいいが、"Javaの鉄則" に載っているような状況にでくわしたとき、
equal()メソッドの実装について悩む上に、==の定義についても余計に考えなければならないとか、
勝手に==をオーバーロードされるのは余計なお世話言いたくなる状況も出てくる。

246 ：

>>206
>を継承するとき、クラスとインターフェースどちらを継承しているかわか
>らないのでインターフェース名の頭にIをつける、これは厄介そう。
> 昔はクラスにCをつけるようにとなっていたよね。
> Javaをしていると継承関係がややこしくてインターフェースかクラス
>かわからなくなるよ。
> でも.Netのように現在は入り組んでないライブラリでも、今後入り組
>んでいくとおもう。
> その時に真価を発揮すると信じているよ。
> どうせならコンパイルオプションではじける設定もほしい
そのときこそUMLが真価を発揮する?
この、頭にCやIをつけるガイドラインは悪しき習慣、ハンガリアン記法の伝統ではないかと。
インターフェースとクラスの区別もUMLクラス図を見れば一目でわかるし、
継承する側は上の説明のとおりimplements, extendsを見れば一目で解るし、
Javadoc API によって生成したドキュメントを見れば一目でわかる。
たいていの場合、複数のクラスやインターフェースは、一つのファイルにつき一つのクラス、インターフェ−スを記述しているはずだ。
そうすれば、同じディレクトリ内に入っているクラス、インターフェースを見るだけで区別にそれほど苦労しない、と思う。
膨大なクラスやインターフェースが沢山あると区別しにくいのではと思うかもしれないが、
同じディレクトリに膨大なのクラスやインターフェースのファイルを入れる方法はソフトウェア管理手法として効率的でない。
デザインパターンを深く学んでいくと、クラスやインターフェースをpackageに入れて分けることの重要性に気づく。
Javaならpackage, C#/C++ならnamespaceで管理し、package, namespaceの違いはディレクトリ(フォルダ)の違いとして判断させる。

247 ：

>>207
> あと忘れ物だ
> !!!throws!!!
> これってあんまり役に立っていないと最近思う。
> RuntimeExceptionはつかまないし、ほとんどつかみたいのはruntimeだ
>って。 この機能はスパッと切って正解だったと思うよ。
これは超重要ですよ!!
C#でこれ無くしたことはある意味、ミッションクリティカルで大規模なプログラミングでは致命的ではないかと。
RuntimeException 以外にも、特にファイル入出力では FileNotFuondExceptionとかIOExceptionとかかなり重要なものもありますよ。
throwsはずすのはさすがにまずと思われます。
C#では すべてのメソッドは Javaの throws Exception に相当することをやっているというわけで、どの例外が投げ出されるか具体的に判別できなくなります。
throwsに加える例外はできる限り詳細に並べよ、というのが(これまた) "Javaの鉄則" に載っています。

248 ：

>>207
class AException extends Exception {}
class AAException extends AException {}
class AAAException extends AAException {}
class ExceptionDemo {
method() throws Exception {
//何かの実装
throw new Exception();
//何かの実装
throw new AException();
//何かの実装
throw new AAException();
}
}
これではmethod()がAAExceptionやAExceptionをスローしたとしても返ってるのはExceptionのみ。なぜなら、これらの例外クラスはExceptionのサブクラスで同一とみなされる。
具体的な例外を知りたいときは以下のようにしなければならない。
class ExceptionDemo {
method() throws Exception, AException, AAException {
//何かの実装...大幅に省略
}
というわけでthrowsは重要であり、C#でこれがなくなったということはバグの検出を非常に困難にしているのではないかと思います。

249 ：

throws節をはずしたことによる問題点が議論されています。
http://www.users.gr.jp/ml/archive/CS/391.asp
簡単なプログラムでははずした方がよくても
複雑になると、これをはずすというのはバグ捕りのしやすさに影響が出ると思われます。
万が一のことを考えるとthrows節はあった方が良いと思います。
throws節で例外クラスを指定しないということは、
他人がコーディングしたC#のコードを解析、ライブラリをインポートするときにどのような例外がスローされるのか想定しにくい。
throwsされる例外クラスからどのような例外が起こりうるかと想定してコーディングできなくなります。

throws節はプログラマに契約を守らせる上で重要だと思います。

C#が発表されたとき、オブジェクト指向を超越した、エージェント指向な、アスペクト指向なプログラミング言語が出現すると期待していたんですが、全然違っていますね。これも C#が .NETによる多言語の互換性のために作られたということなのですね。

250 ：

.NETの中心に据えられていると考えられるC#についてさらに意見を追加
virtual 修飾子は余分。
virtual修飾子をつけつけないに影響する速度の問題など気にするべきでない。
これも.NET政策のためにC++との下位互換性維持のために速度重視のためにあえて付けられたと推測。
Javaだとvirtualを意図しないときはfinal属性をつける
速度問題よりもむしろ、UMLにマッチするような、すっきりしたソースコードを書くほうが重要。

interfaceで宣言されてるメソッドをinterfaceを介して呼ぶ出すなら
常にvirtualメソッドと見なされるので、クラス中のメソッドの定義のデフォ
ルトがvirtualか否かはそれほど重要な問題ではない、ともいえる
デザインパターンを意識するならば、構造体、列挙型は極力使わないようにすべきと思います。
ついでに、#がトリップパスに代わったので修正。

251 ：

>>207
> !!!ボクシング／アンボクシング＆すべてがobjectを継承していない!!!
> javaでは値型が特殊な変数になっているためにVectorなんかにそのま
>ま入れれない。
> これって誰も言わないんだけど致命的な設計ミスじゃない？
ボクシング／アンボクシング
自動的に変換するというのも奇異です。
これも過去の言語の型との互換性をどうにかしたかったために用意されたものではないかと。
unboxingについてよく理解していないのですが、ラップクラスに相当するものを呼び出さなくても自動的に変換できることでコード量が短縮できるという利点があるだけに見えます。
値型をどうにかするには、dobule型なら、DoubleクラスなどでラップしてからVectorに add() すれば、C#よりコード量がちょっと多いことを除いて同じことではないかと思います。
この程度のコード量などオブジェクト指向的な観点から見れば気にするべきではないと思います。
この程度のコード量の多さを気にしていてはインターフェースや抽象クラス、例が処理のtry-catch節などまともにかいていられません == オブジェクト指向性を失う。

252 ：

>>207
Smalltalkから見たらJavaのプリミティブ型というのは失敗だったのですね。
型はすべて参照型でint, long doubleなど使わずに最初からInteger, Long, Doubleなどのラップクラスのみで定義すべきだったということですね。
私にはJavaにプリミティブ型(値型)が存在すること自体が致命的なミスではないかと思います。
型キャストも簡単にできてしまうのもミスだと思います。
J2SE1.5からJavaGenericによりC++のテンプレートに相当する機能が使えるようになりこれによりコレクション系インターフェースの型キャスト問題を解消できると期待しています。
Javaのプリミティブ型は唯一Objectクラスを継承しないものですね。
結論をいうと、 .NETというもは古い言語プログラマのため、古い言語を再利用したいためにあるものということが、C#の仕様からわかります。
新規にプロジェクトを開始するときに一種類の言語しか使う予定が無い、古い言語で書かれたコードもすべて新しい言語で書き直す方針、ならばC#よりJavaのほうが良いかな、と思える。
古い言語を再利用し、書き直さずに利用する予定がある場合にはJavaよりC#が向いている、と思える。

253 ：

このスレは時々長文を書くアホがいるな。
いくら力説しても、ここはネタスレ・隔離スレなんだから誰もそんな作文よまねーよ。

254 ：

このスレは時々長文を書くアホがいるな。
いくら力説しても、ここは厨板・過疎板なんだから誰もそんな論文よめねーよ。

255 ：

>>243
アプライアンスの市場や組み込みOSの市場のシェア見積もりはかなりいい加減だと思うよ。
それぞれの大本営発表だから無理もないけれどね。
特にエンタープライズ市場などは販売網にしても昔ながら投網形式で、最大手が最大手を一網打尽。
外からはまったく見えないところで何事かが進んでいくので、まあ正確なところは見えなくなっているよ。
Linuxもオープンソースの皮を被ったしたたかな商人の巣窟だから、昔のような誠意のあるレポートも望めない。
ある面では堂々とガメているＭＳよりもたちが悪い。
ＭＳトークに萌え萌え的な学生はいても不思議はないと思うよ。
そのたりを冷静に見ているのは、あくまで第一線級の現場の話ね。
ところで、自分は別の意味でJSPとLinuxは絶対にもうやりたくないけれどね。
TomcatとApacheで散々作ってみてその不安定さとパフォーマンスの悪さに懲りた。
商用レベルで複雑なロジックを持つアプリはちょっとぞっとするなあ。
あれはもう偏見か愛がなければ支持され得ないプラットフォームであるとさえ思った（笑）。
新しい環境はがたいの大きな市場にはなかなか採用されないと思う。
.Netが零細企業や中小レベルから浸透するのは当然だと思うな。
Javaの時だってそうだったじゃない。
大きな所はまず様子見だよね。

256 ：

このスレは時々長文を書くアホがいるな。
いくら力説しても、ここには暇な奴はいないんだから中身の無い徒然書きなんか読まねーよ。

257 ：

C#とJavaの違いって各地で色々論議されてるし、漏れも参加してるんだけどJavaらしいことを
J#.Netでできるんだよねー
とくにthrows。
でもthrowsって言っても下位で利用しているツールが何をはくかなんてあんまり興味ない。
続行可能か不可能かくらいなんだよ。
その辺があるとシステム固有の例外に集約して投げなおすだけになっちゃうことが多くて
ほとんど意味を成していない。
.NetであればSystemからのthrowsは知りたいとは思うけど、それを自分で書くのはどうかと思う。
勝手なこといってるけど。

それよりJavaはクライアントに本気でswinguiとかで浸透させようとか思っているの？
それに比べて.NetやKylixだっけ？の方向性はあっていると思うんだけど・・・

258 ：

この板は時々長文を書く「わ」がいるな。
いくら力説しても、ここには.NET好きなんて知恵遅れな奴はいないんだからMSﾏﾝｾｰ洗脳文なんか読まねーよ。

259 ：

C# vs Javaという言語でどっちが良いか悪いかという構図に興味はないな。
現状は、まだビジネス的にLinuxをどう考えるか？で決まるのに、
なんだかんだ言っても、なんの生産性ももたらさずに、いらんストレスを
生むだけのような気がする。
C#やJavaの言語設計に関わるエンジニアなら、話は別だが。
ところで、ここはWebProg板なのでWebアプリベースで語るが、
今、.NETやASPなどを使うのは、レガシーエンジニアの救済策や、Unixが
使えないからというネガティブな印象があるのは事実。
果たして、Apache vs IISとかLinux vs Winという対立軸で、.NETの
選択肢が、有効な手段とみなされる日は来るのだろうか？
Webサービスも、結局、Apache + J2EEで実験してる人たちがほとんどらしいし。

260 ：

>>259
J2EEって本当に有効なんでしょうか？
有効に活用している現場ってある？
ApacheやらWebLogicやらで変わってしまうのも問題だし、わけのわからないフレームワークだとか言うのも
いっぱいあるのもどうかと思う。
結局互換性ないしね。

261 ：

>260
逆に教えてほしいんだけど、NECとか富士通、その他、いわゆる大手SIは
Java率高くないんですか？
NECは、とにもかくにもWebLogicベースというイメージもありますが。
互換性というのは、同じAppサーバーのWinとLinux版で動けば、とりあえずＯＫ
だと思ってます。
より性能の高い、J2EEサーバーが要望されたときは、最低限の工数で移植が
可能であれば問題ないと思います。
ホントに、Run Anywhereを信じるほどピュアじゃないし。商用appサーバーが、
差別化していく上では、MS的に、互換を崩して、他社を出し抜き、ユーザーを
囲い込むのは、ビジネスとしてあるべき姿だと思っています。
あと、有効か？と言う論点には、なんらかの判断基準が必要かと思いますが、
「使っていて、シェア向上に寄与している」だけではダメなんでしょうね。
とりあえず、ちゃんとクラス設計すれば、複数人開発で分担しやすく、
単体デバッグもやりやすく、確実で、最後に組み合わせると、ちゃんと動いてくれれば、
「オブジェクト指向らしく有効である」とは思ってて、
あとは、LinuxとWinで動けば、「Javaらしく有効」とか思ってるんですけど、
どうですか？

262 ：

>>261
大手SIにからんだことはないんだけど今のプロジェクトはWeblogic
差別化はわかるんですよ、ただ便利になっているというのが実感できない。
一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
純粋に使いにくいと思います。
XMLも手書きしろという姿勢もね。
J2EEである必要のない局面で使うのは全体的に手間が掛かるだけではないかと
分散サーバ環境でも何でもないところなのに、そのための手続きを書くのか？とか
あとDBサーバを有効に使わない方向は個人的には嫌いです。
高い金払ってDBサーバ買ってるんだから最大限機能を引き出してやりたいと思うんですけどね。

263 ：

>262
質問です。
> 一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
> 溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
> 純粋に使いにくいと思います。
これは、大きいところも小さいところも.NETで統一すればいい
という理由になりますか？
確かに、オープンソース系の複雑さは、大企業のオープンソースの熱が
一段落したら表面化してくると思います。
やはり、オープンソースは良い意味で、自分でケツがふけて、
工数がかかることも厭わないオタクのおもちゃだと思います。
フレームワークの乱立なんて、まさしくその辺の表れだと思いますし。
もちろん、大きなところも安定して動く信頼感を得ることがMSには
もっとも重要な責務で、そこ次第だとは思いますが。鯖管やってる
ような人は、Windowsを使ったこともないで否定する人も少なくありません。

264 ：

>>263
Microsoftのいいところでもあり悪いところ？でもあるのが単純化。
Unix -> Dosもそうだとおもうんだけど、単純化して使いやすくしてくれる。
一般ユーザのレベルなんてLinuxがああいう雰囲気のままだと一生触らないよ。
簡単さがない、よくても悪くても単純に一本化してくれるから逆にJava陣営も
ある程度単純、一本化できないのかなぁ？と。
あと日本語化にどこも熱心じゃないでしょ？
Javaもいままでうけいれられなかったのはそれが原因かなと、そしてすでに.Netの日本語情報の
方が多い現実。
ライバルとしてがんばってほしいとは思うけどね。

265 ：

>>262
> 質問です。
> > 一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
> > 溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
> > 純粋に使いにくいと思います。
> これは、大きいところも小さいところも.NETで統一すればいい
> という理由になりますか？
ごめん質問に答えてなかった。
大きいところも小さいところも.Netで統一よりは、小さいところもJavaが受け入れられるように
なんとかしろよと。
.Netはすごい勢いで制圧しちゃうかもしれないよ？っと。
技術提供の会社では大企業はWeblogic、一般向けにはtomcatじゃ全然別の環境を用意しなくちゃ
いけないし、TCO的にもWindows環境に負けてる。
オープンソースを推奨するところはそれを維持、管理、開発する人件費を見ていないところが多いね。

266 ：

>>259
＞果たして、Apache vs IISとかLinux vs Winという対立軸で、.NETの
＞選択肢が、有効な手段とみなされる日は来るのだろうか？
市場はそういう対立軸は意識せずに、単純にアプリケーションを要求するだけでしょう？
その要求を見越して.Netが有効であると判断すれば採用すればいいだけだよね。

267 ：

>>265
＞オープンソースを推奨するところはそれを維持、管理、開発する人件費を見ていないところが多いね。
そこをうまく騙すというマーケティングがオープンソースの戦略の骨子だから無理もない。

268 ：

環境：Win2000、VB.NET、OLEDB
VB.NETからCrystalReportを用いて帳票を出したいのですが
帳票を出力する前に、ユーザ名やパスワードを入力する
ダイアログボックスが出て困っています。
次のような記述で、データベースに繋ぐのに必要な情報を
送っているつもりなのですが・・・。
Dim logOnInfo As New CrystalDecisions.Shared.TableLogOnInfo()
Dim CryRep As New CrystalReport1()
logOnInfo.ConnectionInfo.ServerName = "xxx"
logOnInfo.ConnectionInfo.DatabaseName = "xxx"
logOnInfo.ConnectionInfo.UserID = "xxx"
logOnInfo.ConnectionInfo.Password = "xxx"
CryRep.Database.Tables.Item(0).ApplyLogOnInfo(logOnInfo)
回避する方法を教えてもらえないでしょうか？

269 ：

あげげ

270 ：

.NETですか。ﾌﾟﾌﾟ
どうせaspがらみで糞みたいなツールﾌﾟﾌﾟ
セッション管理も相変わらずマイクロソフトテイストでﾌﾟﾌﾟ

バカが。php最強伝説

271 ：

別に適材適所でいいんじゃないの？
○○最強なんていってるのはタダの馬鹿にしか思えない。

272 ：

>>255
>ところで、自分は別の意味でJSPとLinuxは絶対にもうやりたくないけれどね。
>TomcatとApacheで散々作ってみてその不安定さとパフォーマンスの悪さに懲りた。
そのときこそstruts, JSPカスタムタグライブラリが役に立つのでは?
さらにパフォーマンスは悪くなりますが、設計しやすさはかなり向上します。
struts-config.xmlファイルの修正がちょっと面倒ですが(Caminoなどのツールを使うことが解決できる)、コードが煩雑になりやすいスクリプトレットに悩まされる心配もなくなり、
真の意味でのデザインとロジックが分離できることです。デザイナはstruts専用のJSPカスタムタグを使うだけで、プログラムの知識なしで簡単に掲示板を作れる。
従来のように、デザイナがHTMLファイルの作成を待ってまらプログラマがHTMLをJSP化してHTML内にJavaコードを埋め込むという手順を踏まなくて済むようになる。
先にロジックを作成してからデザインすることもできるという利点がstrutsにはあります。
あと、JSPを使うなら、Servlet,Servlet無しのJavaユーティリティクラス、Beanも併用した方がいいですよ。
strutsはActionクラスを継承することでServletの代用ができ、ActionFormクラスを継承することでBeanを作ることができます。
それにstrutsタグを使ったJSPファイルを用意し、専用のstrutsタグだけで、
Actionクラスを継承したクラスを呼び出し、ActiobFormクラスを継承したBeanにデータを格納する。
全部JSPコード内にロジックを埋め込むのは考え物です。

中小企業からの浸透ですか。Sunの場合はハイエンド企業をターゲットにして市場を展開しているのに対し、
M$は中小企業をターゲットに展開しているという両者の違いについての説明をどこかの記事で見ました。
大手企業はM$に逆らうだけの余力が残っているので、各企業同士(SunとOracleなど)で同盟を結び巨大帝国に立ち向かい、中小企業はお金が無いので仕方がなくM$に従うという構図をもっていると思う。
実際、いくつかの中小企業は、M$から相当の圧力と資金が流れているのではないでしょうか。M$以外の競合製品を使わないなら苛めるなんてこともしていると思われる。

273 ：

>>257
> C#とJavaの違いって各地で色々論議されてるし、漏れも参加してるんだけどJavaらしいことを
> J#.Netでできるんだよねー
J#ってRMIが使えないのがちょっと。Windows限定はね、他OSへの移植が面倒くさいのではないかと。
> でもthrowsって言っても下位で利用しているツールが何をはくかなんてあんまり興味ない。
メンテナンス性に影響でないかな? もともとそういうプログラムを作る必要がないなら興味がわいてこないのも無理も無いと思う。
> 続行可能か不可能かくらいなんだよ。
> その辺があるとシステム固有の例外に集約して投げなおすだけになっちゃうことが多くて
> ほとんど意味を成していない。
複雑なプログラムを書いているとそうも言っていられないものです。
> .NetであればSystemからのthrowsは知りたいとは思うけど、それを自分で書くのはどうかと思う。
> 勝手なこといってるけど。
C#のSystemってクラスでなくパッケージ名(namespace)だったんですね。
System.out.println()とSystem.Console.WriteLine()で騙されました。
CompositeやVisitorパターンでは、自作例外クラスは必須です。
非常に便利です。あのパターンで、スーパークラスのメソッドで例外を無条件でスローさせて、サブクラスがそのメソッドをオーバーライドしたときのみ
スローさせないという仕組みに感動した!
Exceptionクラスしか投げないというのは情報が少なすぎです。
> それよりJavaはクライアントに本気でswinguiとかで浸透させようとか思っているの？
> それに比べて.NetやKylixだっけ？の方向性はあっていると思うんだけどSwingの普及は長期的な作戦が必要だと思う。
いずれマシンのスペックが向上し、Swingを使おうとそれ以外を使おうとほぼ変わらないとすれば、ポータビリティの高い言語で作られたSwingがいずれ浸透すると思う。現状ではとても無理でしょうが。
使い捨てでないプログラムであれば、Swingは使い道あると思う。
といっても今は、IBMのSWTの方がいいかな?
Kylixはどれだけ普及しているのだろうか。Linuxをちょっと改造するために作られたように見える。

274 ：

>>260
> J2EEって本当に有効なんでしょうか？
有効に活用している現場ってある？
>>259ではありませんが、
もろにあります。>>261 の企業のほかに、
IBM, 東芝、あとどこだったかな。
製造業、工場、金融機関、医療機器だったかな。
ミッションクリティカルな現場ではよく使われているらしい。
オークションサイトでも使っているところがある。
一見JSPしか使っていないように見えるけれど、Solaris上で動き、J2EEも使っているらしい。○○王ーク○○ンというサイトだったかな。
お金が絡みますからね、ちょっとしたミスも許されない環境を構築するには信頼性の高いJavaがよく適しているようです。
> ApacheやらWebLogicやらで変わってしまうのも問題だし、わけのわからないフレームワークだとか言うのも
> いっぱいあるのもどうかと思う。
>結局互換性ないしね。
Webサーバの違いによる互換性はさほど影響にならない。
バージョンの違いによる互換性の悪化は、
モジュールを自分でmake(WinならVC++のmsdevか?)すればよい。
他はちょっと修正を加えればよい。
100PureJavaが実現されなくとも他の言語と比べほぼ100%近いポータビリティを実現できるというのが優れている。

275 ：

J2EEは企業向けのシステムが主流。
企業システムはその技術内容を公開しないのが基本（ヘタに技術内容を公開するとクラックのヒントを与えてしまうこともある）だから、あまり大々的に宣伝されることはないんだよ。
J2EE事例が知りたいなら日経○○とかを読むがよろし。腐るほどでてくる。

276 ：

>274
Solaris規模の開発なら、Javaが一番簡単。

277 ：

>272
Sunは大企業に離れられると潰れます。ここは最後の砦です。
MSと戦って敗れる企業は、個人ユーザー、中小から堀を埋められて、
最後は大企業、ハイエンド市場のみへと市場が狭まっていく
のは多々あることです。これは珍しいことではありません。
MSと戦って敗れていった数多くの企業は、先駆者としての実力はあるのですが、
いかんせん、アフターケアや、開発環境、商品アピール、日本だったら開発ドキュメントの
ローカライズなどをユーザー側の努力に頼りすぎています。逆にMSは、その辺は
抜け目なくケアしています。
MSに負けていく技術は、一部の偏差値の高いアーリーアダプター層には
熱狂的な支持を受けていたても、ビジネスとしては市場を失っていくというのが
往々にして見られる特徴です。これは高偏差値層が担ってきたコンピューターの
歴史において、前例なき動きであり、彼らにとっては非常に由々しき出来事なのです。
中小企業や個人ユースの市場がMSに奪われていくには理由があり、MSと他の企業を
比較すると、他の企業の方がelegantであっても、いろいろとcomfortableなのはMS
だからでしょう。

278 ：

>273
＞J#ってRMIが使えないのがちょっと。Windows限定はね、他OSへの移植が面倒くさいのではないかと。
.Net Frameworkでプログラミングしようかと言う人間が他のOSへの移植性なんて
考えて作るもの？
RMIなんて使えなくても、COMが使えるんだからいいんでないの？
他の仕事でJavaも書くことが多いんならJ#が一番楽なのでは？という
気にもなる。

279 ：

> .Net Frameworkでプログラミングしようかと言う人間が他のOSへの移植性なんて
> 考えて作るもの？
.Net Frameworkでプログラミングしようかと思ったことは無いけど、
あれはLinuxやFreeBSDでも動くんじゃないかい。
Linux版.NET開発環境もあるしね。特許問題でもめているが。
.NetとC#はJavaと同じようにプラットフォーム非依存を目指すと聞いたが、
結局それは中途半端かい。
> RMIなんて使えなくても、COMが使えるんだからいいんでないの？
> 他の仕事でJavaも書くことが多いんならJ#が一番楽なのでは？という
そりゃあなたがWin環境onlyを前提しての話じゃん?
COM使うならCORBA使った方がいいって感じ。
RMIはプラットフォーム非依存のJavaで動くから良いんだよ。
JavaモドキのJ#はいやじゃ。
J#はJ2SDK1.1までしか対応していない。
もう古臭くて使い物にならんわい。
J2SDK1.4でないとね。
Java Sound APIも入っているし、JAXP(Java API for XML Processing)も入っているし、従来のJ2SDKにあった欠点も大幅に改善されているし。
1.1よりも1.4のほうが(少なくとも1.5倍以上は)高速だし。
最新版J2EEはJ2SEが1.3以上でないと動かんし。
J#はとても使っていられないよ。
Java使うの嫌であれ使うならそれこそC#使った方がいいんじゃない?
J#は古いコード(J2sdk1.1までのバージョンのJavaコード)をC#でも動かせるように作られたものじゃなかった?

280 ：

>>277
(数多くの企業が)別に何もかも敗れたってことではないんじゃないかな。
つまりM$は宣伝に大量に資金投入しているから勝っていると?
それでもオープンソース的なやり方は敗れていないものではないかな。
M$がいくら特定の企業にかったとしてもオープンソースには勝てないだろうな。何をもって勝利と定義するかによるけど。
M$のやり方に不満をもっているからSunもIBMもあそこまで生き延びることができる。たとえ今突然、赤字続きのSunがつぶれてもJavaが廃れることはないだろう。
またそのとき、JavaがM$に渡る可能性はかなり低いだろう。
司法省が付いているだろうから。あとは政権が交代し、ブッシュ以外のブッシュらしくない政権が現れればM$に好都合なことは起こりにくくなるだろう。

281 ：

マイクソ製品最高

282 ：

>279
いや、だからJavaだからマルチプラットフォームってんじゃなくて・・・
・・・・ま、いいや、以下は同意する事項だろう。
「MSがJavaをやってもJDK1.1までしか対応できないので、
　ホントはJavaやっても意味がない」
すなわち、
「J#でJDKのプログラミングすることには、こと最新の開発においては
　価値がない」わけだ。
でわ、J#の存在価値とは何ぞや？という話になるが、
「JDKではなく最新の.net FrameworkをJavaという言語でプログラミング
　できればJDKなんていらねーじゃん。」
これこそがJ#の価値だと思っている。一応、VisualJ++時代の資産が
云々とは言ってるが、本質は.NetFramework上で動くJavaだ。
クラスライブラリがJDKを使わないのなら、Sunとの係争云々なんて無関係だということ。
.NetFrameworkで、JAXPより遥かにお手軽なXMLの取り扱いはできるし、
Win32のアプリ作れるし、WebServicesも作れるので、別にJDK1.4の後ろ盾は不要（ｗ
あと、現実ビジネスに使えるCLRがない以上は、.NETはWindows onlyの解釈で良いだろ。
.NET使う奴は、最初から、そんなのわかってて言ってるんだし。そういうことに
こだわる案件は最初から、SunのSDK使って作るんで構わんのだよ。
Javaという言語仕様の解釈がずれてるかﾓﾅｰ

283 ：

>>282
Javaというのをどこまで仕様とするかにもよるけど、Java風構文ができりゃいいんだろ？ってのがMSの主張かな？
それ以上は裁判のこともあるし突っ込みがたい。
で、CLRは来年か再来年にはLinuxには移植されるのではないかと思うがどうだろう？
OfficeがWindows向けじゃなく.Net向けになったときが勝負の時のような気はしますな。

284 ：

ほんとうにJAVAが成功するとおもってるやつは馬鹿だな
そんなヽ(・＊・)ﾉｱﾅﾙやろうはやく死んでしまえ

285 ：

C#+ASP.netをサンデープログラマでやろうと思っているのですが、
要IISってところで怖じ気づいてます。
ボーリングのスコアを各自で入力してランキングを出すとかいうレベルだと、
ASP.netってもしかしておおげさ？

286 ：

>>285
要IISでなんで怖気ずくの？
Webサーバを立ち上げる場合には常時接続であろうと無かろうと、常に最新パッチの存在を調べる義務を負う。
それがapacheであっても一緒だからね。

287 ：

IISが駄目とかいってる時点で何も知らない糞野郎
パッチあてろや
ばーか

288 ：

ＩＩＳがいやなら最初からアパッチでＣＧＩでもなんでも動かせばいいだろが

289 ：

素朴な質問。
.NETで負荷分散はどういう仕組みがあるんすか？
たとえば、DBとアプリとWeb鯖を分けた典型的な３階層の場合、
アプリ鯖の負荷を軽減する目的で鯖を増やします。けど同じアプリを
入れるので、アプリ間同士でのデータ（オブジェクト）の共有・同期がどういう
仕組みでやってるのか興味あります。JavaですとRMI（OpenJMSとか）で
実装できるんですが。
とかく２ｃｈなどの大量アクセスのある掲示板では負荷分散て
しているんだろうかと思う次第であります。（１つの掲示板に
２つ以上のハードウェア使用しているんですか？もしくはサーバーの
ハードウェアスペックに依存してるって感じすか？）
冬休み厨房なようですいません。

290 ：

>>284,285,287
熱心なM$信者か。お前みたいな知ったかぶり香具師はJavaを使おうが.Netを使おうがIISを使おうがApache使おうがTomcatを使おうが成功しない。
VB中毒のこのM$信者はJavaによる成功事例を知らないアホ。
パッチ当てたくらいでセキュリティが万全だと思い込むお前は馬鹿。
Apacheの方が信頼と実績が格段に高い。
むしろお前がR低級言語VB信者のリアル厨房.

291 ：

>>290 >>284 >>287-288　に訂正 Mq2bd0MのVB信者厨房

292 ：

.NET厨は、せめてもっと流行ってから吼えたり煽ったり欲しい。
普及してない現状では負け犬の遠吠えと言われて相手にされなくても仕方ないよ。

293 ：

誰か289の質問にこたえてやれ。漏れじゃ答えられぬ。かといって
答えがなければ.NETダメじゃん、でおわっちまいそうだ。

294 ：

>>289
Windows2000AdvencedServerなんかで、同一IPでの付加分散できる。
当然コストはかかるけど、Unixなんかとその辺は同じ
2chは付加分散してないから板ごとに鯖ふりわけられてるよね？
その辺はあんまり詳しくないんでsage

295 ：

>283
> で、CLRは来年か再来年にはLinuxには移植されるのではないかと思うがどうだろう？
> OfficeがWindows向けじゃなく.Net向けになったときが勝負の時のような気はしますな。
確かに、最近のLinux参入の噂を聞くとあっても良いような気がする。
X窓でWinFormsとか動き出したら、凄いことになる。
まぁそこまでは無理そうな印象があるので、とりあえずASP.NETだけでも十分だ。
例えばApacheに組み合わせられるASP.NETとかになると、いろんな考え方の軸が
めちゃくちゃになって楽しい鴨。

296 ：

>289
漏れもあんまり知らない。今、それやるならWebLogicとか考えるからなんだけど、
興味はすげーある。
が、MSDNのヘルプにゃこんなことが書いてあるので、実はすげー簡単に
できるのではないか？と。
（EJBみたいな分散オブジェクトも、実はすげー簡単にできるのか？）
以下、引用
サーバー ファーム構成に対するサポート -
アウトプロセス モデルに移行することにより、ASP.NET はサーバー ファームの
問題点も解決します。新しいアウトプロセス モデルは、ファーム内のすべての
サーバーが 1 つのセッション状態プロセスを共有することを許可します。
ユーザーは共通のサーバーを指すように ASP.NET 構成を変更することにより
これを実装できます。

297 ：

>285
VisualStudio.Netが使えるなら、楽チンWebプログラミングで作れるので
決して大げさではありませぬ。
XMLで、ファイルにデータストアして表示するときに、スコアのノードで
XMLソートかけて表示するとかなら、並び替えロジックも書く必要はなく、
.net frameworkのクラスで実現可能。
IISなら最新パッチも、WindowsUpdateがやってくれるから
厨房管理者なら、今はWindowsの方がよっぽど確実かと。

298 ：

>296
自己レスだが、ローカルネットワークでは、オブジェクトシリアライズを
Binaryで行って、IISが、http,tcp,dcomで分散オブジェクトを実現可能
インターネット経由したきゃSOAPでHttpでもSMTPでもどうぞ。
その辺のサンプルは、
　Duwamish 7.0 サンプル
　Fitch and Mather 7.0 サンプル
などを見ると詳しく分かる模様。
オブジェクト的には、こんな感じ。
System.Runtime.Remoting.Channels.Http.HttpChannel

299 ：

見事に馬鹿が釣れちゃいましたね

300 ：

>>289
むりやりCORBA使うとか?
基本はJavaで、RMI使ってJNI通して
C/C++の .NETにアクセスという横着はどうですか?

301 ：

（＾＾）

302 ：

>>268
Dim objRp As CrystalDecisions.CrystalReports.Engine.ReportDocument
Dim logOnInfo As New CrystalDecisions.Shared.TableLogOnInfo()
Dim i As Integer
objRp = New CrystalDecisions.CrystalReports.Engine.ReportDocument()
objRp.Load("Report1.rpt", CrystalDecisions.[Shared].OpenReportMethod.OpenReportByDefault)
logOnInfo.ConnectionInfo.ServerName = Server
logOnInfo.ConnectionInfo.DatabaseName = DatabaseName
logOnInfo.ConnectionInfo.UserID = UserID
logOnInfo.ConnectionInfo.Password = Password
For i = 0 To objRp.Database.Tables.Count - 1
　objRp.Database.Tables.Item(i).ApplyLogOnInfo(logOnInfo)
Next i
objRp.PrintOptions.PrinterName = PrinterName
objRp.PrintToPrinter(1, False, 1, 1)

303 ：

.NET出てだいぶ経つのに影薄いのはなんでですか？

304 ：

>>303
あなたが引き籠もって外の世界に出ていないので、そう感じるのですよ。

305 ：

ＣＧＩ？まだ存在してたの？
なんかいいところあったけ？

306 ：

　　　______________
　／:＼.＿＿＿_＼
　|:￣＼(∩´∀｀)　＼　　＜先生！こんなのがありました！
　|:在　 |:￣￣ U￣:|
http://saitama.gasuki.com/wara/

307 ：

>>305
1. CGIは規格自体がシンプルなため、.NET以上に多言語での開発ができる。
2. サーバの構築、運用がApacheだけでできる。シェアNo.1＆フリーウェアなサーバなのでWEB上には情報も多く、導入コストを低く押さえられる。
3. 参考資料が豊富。拾ってきて動かして理解することができる。

308 ：

Windows2000Server SP3にMDAC2.7と、.NET Framework SDKをインストールし、
最初は、aspxファイル単体で動作確認が出来ていたのですが、ActiveDirectoryで、
ドメインを構築してから動かなくなってしまいました。
同フォルダ内に置いた、aspファイルの方は動作するのでIIS自体は問題なく動いている
みたいです。
どうしたらいいのでしょうか？

309 ：

http://www.agemasukudasai.com/bloom/

310 ：

ちなみに、「HTTP 500 - 内部サーバーエラー」と表示されます。

311 ：

マッピングは？
内部サーバエラーならちゃんとエラーメッセージひらえよー
IEの簡易エラーメッセージを表示のチェックをはずす。

312 ：

すいませんホントに知りたいのですが、
「.net」はgTLDなのでしょうか？

313 ：

>>312
あたりまえだ
gTLDってなにかわかってるか？

314 ：

>>313　そうなんですね。ありがとうございます。
えっと・・・
使われまくってる「.jp」や「.com」等の後に誕生したもの、、
くらいしか分からないんですが、、。
私、YBBなもので、サポートセンターに「gTLDをjpに変えて下さい」と電話しようと思ってるんです・・。
なので、ウチのリモホ「×××.net」はホントに「gTLD」なのかな・・・？と確認しようと思ってここへ参りました。

315 ：

>>314
歴史を学んでください。
ドメインとは何かを学んでください。
gTLDをjpに変えて下さい ハァ？何が言いたいのかまったくわからん。

316 ：

>>314
このスレの.NETはドメインの.netとは違います。
>>315
YBBのリモホは*.bbtec.netだったけど2chで.jp以外拒否の板に書き込めないためyahooBBは.jpドメインも用意したらしい。
希望者はドメインが変えられる。

317 ：

>>316
>YBBのリモホは*.bbtec.netだったけど2chで.jp以外拒否の板に書き込めないためyahooBBは.jpドメインも用意したらしい。
>希望者はドメインが変えられる。
マジで？　ソースは？

318 ：

>>311
返事遅れて申しわけありません！
サーバーのログを見た所、「aspnet_wp.exeを開始する事が出来ませんでした。失敗の HRESULT: 80004005」
と書かれていました。
（３１１さんがまた見てくれますように（祈））

319 ：

３１１さんに指摘されて見たエラーログから辿っていったら解決しました。
どうもありがとうございました。

320 ：

>>317
どこかの板にあった似非情報

321 ：

おまえらついにC#死滅スレがPart11になりましたよ
C#って死滅しちゃうの？？？ part11
http://pc2.2ch.net/test/read.cgi/tech/1047322829/
C#は新言語でありながらさまざまなセキュリティの欠陥が存在する。
そんな言語が.NetとWindowsの将来を担っていけるのか？

322 ：

っていうか .NET 自体死滅してるからもういいよ。

323 ：

痛いとこ、つくのう。

324 ：

.NET構想と新言語C#は、М§の壮大なネタ。

325 ：

マイクロソフトに幾らもらった？＞1

326 ：

#!/usr/bin/perl
print "必死だな(藁";
while(1){
if($res==DQN){
last;
}
print "←こいつが一番必死だな(藁";
}
print "結局俺が一番必死だな(藁\n";
exit;

327 ：

>>1-332 >>334-1000 win板R。厨房

328 ：

.NETは間違いなく、普及する。絶対にだ。
面倒だと、目を背けていたら、置いていかれる。
最低でもそんなやつらに負けないために、.NETに関する情報を齧っておく必要がある。

329 ：

#include <iostream>
using namespace std;
string res;
cout << "必死だな(藁";
while(1){
if(res==DQN){
last;
}
cout << "←こいつが一番必死だな(藁";
}
cout << "結局俺が一番必死だな(藁\n";
return 0;
}

330 ：

ま、俺らがどう吠えようが、どのみち普及するんだよ。
馬鹿ほど騙されやすいからな。

331 ：

http://homepage3.nifty.com/hot-hot/
http://homepage3.nifty.com/llllllllll/

332 ：

ココまで読んでないんだけどさ。
.netってなに？linuxや*BSDでも使える技術？？？
興味あるから教えてくれくれ。

333 ：

>>327 禿同。オマエモナ

334 ：

MAC Addressを含めたGUIDを生成したいんですが、
System.Guid.NewGuid()はMAC Addressを含んでいるんでしょうか。
大量に生成して、眺めると、16byteランダムのような気がしなくもありません。
Windows 2000からGUIDはMAC Addressの部分がスクランブルかかっている
という話も聞いた様な・・・。

335 ：

>>334
何故、世界中でユニークが保証されないキーにこだわる？
一要素には使われているとは思うが。それだけでは足りない
ので、エンコードの要素にしかなりえないと思うが。

336 ：

ＬＡＭＰで構築しなさいよ。
まぁ馬鹿は遅くて、高くて、互換性が低くて、作りづらい
ＷＩＮ、ＩＩＳ、ＳＱＬサーバ、ＡＳＰで顧客を地獄に落としこめば？

337 ：

>>282
> 「JDKではなく最新の.net FrameworkをJavaという言語でプログラミング
> 　できればJDKなんていらねーじゃん。」
できるなら、そして.net frameworkに価値があればの話だろ。

> これこそがJ#の価値だと思っている。一応、VisualJ++時代の資産が
> 云々とは言ってるが、本質は.NetFramework上で動くJavaだ。
むしろJava上で動く.NET frameworkのほうが価値がある。その方がより多くの
プラットフォームで動くようになる。.Net framework上で動くJavaは、Javaらしさを著しく損なう。
> クラスライブラリがJDKを使わないのなら、Sunとの係争云々なんて無関係だということ。
最近ではIBMがJavaの将来を握っている。Sunの関与は少ない。

> .NetFrameworkで、JAXPより遥かにお手軽なXMLの取り扱いはできるし、
JakartaのXML関連APIとの比較も忘れずに。
もはやこれでは言語仕様の比較ではなくなった感がある。
> Win32のアプリ作れるし、WebServicesも作れるので、別にJDK1.4の後ろ盾は不要（ｗ
Win32アプリをつくることは誰もが欲しがっている目的でも価値ではない。
>
> あと、現実ビジネスに使えるCLRがない以上は、.NETはWindows onlyの解釈で良いだろ。
つまり.NETはサーバ用途にはほとんど向かないということですな。

338 ：

.net開発環境が高いYO!

339 ：

高いけど開発時間短ければ結局それだけ儲けになるだろ

340 ：

ついに『モー○ング娘。』のトイレRビデオ見つけた♪
ＴＶ収録時と全く同じ衣装！ここでサンプル動画も見れたよ♪
http://www.nukix.net/index2.html

341 ：

#! /sbin/sh
echo "http://www6.ocn.ne.jp/~mirv/bbstable.html"
echo "http://www.ff.iij4u.or.jp/~ch2/bbstable.html"

342 ：

.NetとCGIは何が違う？
.NetをコンパイルしたCGIはなにの？

343 ：

>>342
絶句するような質問だけど、
http://www.atmarkit.co.jp/fdotnet/aspnet/index/index.html
とか読んで勉強してね。CGIに対比させるならASP.NET。
まあオレは今Java系統で開発してるけど、何にせよ適材適所だわな。
.NETもいい部分がかなりあるよ。
>>337
＞Sunの関与は少ない。
ハア？っちゅう感じ。JCPのSUNからの提案が少ないとでも？

344 ：

ＪＣＰって何？

345 ：

>>344
まあ調べればわかるだろうけど、サイトはここ。
http://jcp.org/ja/home/index
SUNが仕様策定をオープンにしようとして、作った団体。
とはいえ、それはJava規格の分裂を防ぎ、JavaのコントロールをSunが取れるように
した面もあるために、方々からSunの運営に関して批判はあったりも。
http://jcp.org/ja/jsr/all
を見れば、Sunの提案がかなり多いし、中核部分の仕様はほぼSunと言っていい
のではないかと。
まあだからと言って、Sunは悪いとかなんとか言うつもりは無いけどね。
もともとJavaはSunのものなんだし。

346 ：

.NETでWeb系やるとしたらASP以外無いの？
C#とか使えないの？

347 ：

>>346い、意味不明…

348 ：

　　　______________
　／:＼.＿＿＿_＼
　|:￣＼(∩´∀｀)　＼　　＜先生！こんなのがありました！
　|:在　 |:￣￣ U￣:|
http://exe.adam.ne.jp/dice/index_j.html
http://exe.adam.ne.jp/dice/net_development_j.html
DICE : IRC/HTTP/opennapハイブリッドサーバ for Microsoft Windows 2000/XP/2003
DICEは、IRCクライアントからの接続、opennapクライアントからの接続、HTTP
クライアント(WWWブラウザ)からの接続を同時に受け入れることのできるマルチ
プロトコルハイブリッドサーバです。IRCは生粋のチャット環境としてのメディア
であり、一方opennapはチャットルームを備えたディレクトリ公開サービスです。
HTTPは、インターネットでもっともよく知られた、ユーザにコンテンツを配信する
ためのプロトコルです。DICEに実装されているopennap準拠のシステムは
VirtualDirectoryと呼称されます。DICEのHTTPサービスは.NETアプリケーションを
ホストできます。

349 ：

しっかし、この板ASP人気ないね
つか日本ではあまりASPは使われないのかな？
海外ではPHPなんかより人気あるみたいだけど

350 ：

 

351 ：

 

352 ：

 

353 ：

 

354 ：

 

355 ：

 

356 ：

PerlのCGIをJScript.NETやC#.NETに移植して作ったCGIを使ってますよ

357 ：

asp.netを仕事で使うことになった。
GUIのアプリケーションもWebのアプリケーションも作った経験があったが、
あれはちょっと使いづらい。

358 ：

｡ﾟNa-Naﾟ｡ 6月25日
[あいさつより]竜ﾁｬﾝ�b普通の人？ってか普通以下かも�F�ﾑ友達ﾄｶ知り合いとか独立したり、大企業ぢゃない..
[続きを見る]

†♀優姫♀† 6月25日
[あいさつより]竜kunの��パカ�Q�ﾑ�ﾑ�~�~�U

♀ねぇさん♀ 6月25日
ｵﾂｶﾚﾁﾝﾁﾝ�~潮ふいたゎ�Iｳｹｹｹｹ�姐ｧﾝﾊﾟｨ�ﾈ

さ---たﾝ!! 6月25日
[あいさつより]ﾇﾘﾇﾘ�bﾅﾃﾞﾅﾃﾞ�b

359 ：

。NEETって早いの？

360 ：8)

せやろか