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

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

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

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

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

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

おしい。

ADOはクライアントカーソルと、サーバカーソル両方使えるのが正解。

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

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

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



>>237
要はADOは細かくDBとアクセスする。
ADO.Netは最初と最後にどかんとアクセスする。

だから、ADO.Netの場合にはアクセスの数が少ないから早いけど、シリアライゼ
ーションで若干問題がある。

バッチ処理なんかはADOを使わざるを得ないかも（試してないんでわからんが）

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

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

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

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

>>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#への以降を迫られている」というある小企業もいました。

>>205
> たとえばJavaになくってC#にある機能っていうのはJavaの開発してたらなんでやねん、
> なんでないねんていう機能ばかりじゃないか？
> - Cとはちょっと異なる構造体の復活
> Javaで同じValueClassを書くのは無駄にコード量が増えるだけ
> - 列挙型の復活
> これも同じことをしようとすると意味もなくコード量が増える

それは個人の主観と思う。

最近のXP(eXtreme Programming), RUP(Rational Unified Process)な観点から見れば、コード量が増えてでもソースコードは他人に読みやすい方が良いのでは、と思う。

このクラスは継承できる、と思ったら構造体だった、というのも...。
また、構造体や列挙型はUMLで的確に表現できるのでしょか?

>>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()メソッドの実装について悩む上に、==の定義についても余計に考えなければならないとか、
勝手に==をオーバーロードされるのは余計なお世話言いたくなる状況も出てくる。

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

インターフェースとクラスの区別もUMLクラス図を見れば一目でわかるし、
継承する側は上の説明のとおりimplements, extendsを見れば一目で解るし、
Javadoc API によって生成したドキュメントを見れば一目でわかる。

たいていの場合、複数のクラスやインターフェースは、一つのファイルにつき一つのクラス、インターフェ−スを記述しているはずだ。
そうすれば、同じディレクトリ内に入っているクラス、インターフェースを見るだけで区別にそれほど苦労しない、と思う。

膨大なクラスやインターフェースが沢山あると区別しにくいのではと思うかもしれないが、
同じディレクトリに膨大なのクラスやインターフェースのファイルを入れる方法はソフトウェア管理手法として効率的でない。
デザインパターンを深く学んでいくと、クラスやインターフェースをpackageに入れて分けることの重要性に気づく。
Javaならpackage, C#/C++ならnamespaceで管理し、package, namespaceの違いはディレクトリ(フォルダ)の違いとして判断させる。

>>207
> あと忘れ物だ
> !!!throws!!!
> これってあんまり役に立っていないと最近思う。
> RuntimeExceptionはつかまないし、ほとんどつかみたいのはruntimeだ
>って。 この機能はスパッと切って正解だったと思うよ。
これは超重要ですよ!!
C#でこれ無くしたことはある意味、ミッションクリティカルで大規模なプログラミングでは致命的ではないかと。

RuntimeException 以外にも、特にファイル入出力では FileNotFuondExceptionとかIOExceptionとかかなり重要なものもありますよ。

throwsはずすのはさすがにまずと思われます。
C#では すべてのメソッドは Javaの throws Exception に相当することをやっているというわけで、どの例外が投げ出されるか具体的に判別できなくなります。
throwsに加える例外はできる限り詳細に並べよ、というのが(これまた) "Javaの鉄則" に載っています。

>>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#でこれがなくなったということはバグの検出を非常に困難にしているのではないかと思います。

throws節をはずしたことによる問題点が議論されています。
http://www.users.gr.jp/ml/archive/CS/391.asp

簡単なプログラムでははずした方がよくても
複雑になると、これをはずすというのはバグ捕りのしやすさに影響が出ると思われます。

万が一のことを考えるとthrows節はあった方が良いと思います。
throws節で例外クラスを指定しないということは、
他人がコーディングしたC#のコードを解析、ライブラリをインポートするときにどのような例外がスローされるのか想定しにくい。
throwsされる例外クラスからどのような例外が起こりうるかと想定してコーディングできなくなります。


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


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

.NETの中心に据えられていると考えられるC#についてさらに意見を追加
virtual 修飾子は余分。
virtual修飾子をつけつけないに影響する速度の問題など気にするべきでない。
これも.NET政策のためにC++との下位互換性維持のために速度重視のためにあえて付けられたと推測。

Javaだとvirtualを意図しないときはfinal属性をつける

速度問題よりもむしろ、UMLにマッチするような、すっきりしたソースコードを書くほうが重要。


interfaceで宣言されてるメソッドをinterfaceを介して呼ぶ出すなら
常にvirtualメソッドと見なされるので、クラス中のメソッドの定義のデフォ
ルトがvirtualか否かはそれほど重要な問題ではない、ともいえる

デザインパターンを意識するならば、構造体、列挙型は極力使わないようにすべきと思います。
ついでに、#がトリップパスに代わったので修正。

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

この程度のコード量などオブジェクト指向的な観点から見れば気にするべきではないと思います。
この程度のコード量の多さを気にしていてはインターフェースや抽象クラス、例が処理のtry-catch節などまともにかいていられません == オブジェクト指向性を失う。

>>207
Smalltalkから見たらJavaのプリミティブ型というのは失敗だったのですね。
型はすべて参照型でint, long doubleなど使わずに最初からInteger, Long, Doubleなどのラップクラスのみで定義すべきだったということですね。

私にはJavaにプリミティブ型(値型)が存在すること自体が致命的なミスではないかと思います。
型キャストも簡単にできてしまうのもミスだと思います。

J2SE1.5からJavaGenericによりC++のテンプレートに相当する機能が使えるようになりこれによりコレクション系インターフェースの型キャスト問題を解消できると期待しています。

Javaのプリミティブ型は唯一Objectクラスを継承しないものですね。

結論をいうと、 .NETというもは古い言語プログラマのため、古い言語を再利用したいためにあるものということが、C#の仕様からわかります。

新規にプロジェクトを開始するときに一種類の言語しか使う予定が無い、古い言語で書かれたコードもすべて新しい言語で書き直す方針、ならばC#よりJavaのほうが良いかな、と思える。

古い言語を再利用し、書き直さずに利用する予定がある場合にはJavaよりC#が向いている、と思える。

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

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

>>243

アプライアンスの市場や組み込みOSの市場のシェア見積もりはかなりいい加減だと思うよ。
それぞれの大本営発表だから無理もないけれどね。
特にエンタープライズ市場などは販売網にしても昔ながら投網形式で、最大手が最大手を一網打尽。
外からはまったく見えないところで何事かが進んでいくので、まあ正確なところは見えなくなっているよ。
Linuxもオープンソースの皮を被ったしたたかな商人の巣窟だから、昔のような誠意のあるレポートも望めない。
ある面では堂々とガメているＭＳよりもたちが悪い。

ＭＳトークに萌え萌え的な学生はいても不思議はないと思うよ。
そのたりを冷静に見ているのは、あくまで第一線級の現場の話ね。
ところで、自分は別の意味でJSPとLinuxは絶対にもうやりたくないけれどね。
TomcatとApacheで散々作ってみてその不安定さとパフォーマンスの悪さに懲りた。
商用レベルで複雑なロジックを持つアプリはちょっとぞっとするなあ。
あれはもう偏見か愛がなければ支持され得ないプラットフォームであるとさえ思った（笑）。

新しい環境はがたいの大きな市場にはなかなか採用されないと思う。
.Netが零細企業や中小レベルから浸透するのは当然だと思うな。
Javaの時だってそうだったじゃない。
大きな所はまず様子見だよね。

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

C#とJavaの違いって各地で色々論議されてるし、漏れも参加してるんだけどJavaらしいことを
J#.Netでできるんだよねー

とくにthrows。
でもthrowsって言っても下位で利用しているツールが何をはくかなんてあんまり興味ない。
続行可能か不可能かくらいなんだよ。
その辺があるとシステム固有の例外に集約して投げなおすだけになっちゃうことが多くて
ほとんど意味を成していない。

.NetであればSystemからのthrowsは知りたいとは思うけど、それを自分で書くのはどうかと思う。
勝手なこといってるけど。



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

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

C# vs Javaという言語でどっちが良いか悪いかという構図に興味はないな。

現状は、まだビジネス的にLinuxをどう考えるか？で決まるのに、
なんだかんだ言っても、なんの生産性ももたらさずに、いらんストレスを
生むだけのような気がする。

C#やJavaの言語設計に関わるエンジニアなら、話は別だが。

ところで、ここはWebProg板なのでWebアプリベースで語るが、

今、.NETやASPなどを使うのは、レガシーエンジニアの救済策や、Unixが
使えないからというネガティブな印象があるのは事実。

果たして、Apache vs IISとかLinux vs Winという対立軸で、.NETの
選択肢が、有効な手段とみなされる日は来るのだろうか？
Webサービスも、結局、Apache + J2EEで実験してる人たちがほとんどらしいし。

>>259
J2EEって本当に有効なんでしょうか？
有効に活用している現場ってある？

ApacheやらWebLogicやらで変わってしまうのも問題だし、わけのわからないフレームワークだとか言うのも
いっぱいあるのもどうかと思う。

結局互換性ないしね。

>260
逆に教えてほしいんだけど、NECとか富士通、その他、いわゆる大手SIは
Java率高くないんですか？

NECは、とにもかくにもWebLogicベースというイメージもありますが。

互換性というのは、同じAppサーバーのWinとLinux版で動けば、とりあえずＯＫ
だと思ってます。
より性能の高い、J2EEサーバーが要望されたときは、最低限の工数で移植が
可能であれば問題ないと思います。
ホントに、Run Anywhereを信じるほどピュアじゃないし。商用appサーバーが、
差別化していく上では、MS的に、互換を崩して、他社を出し抜き、ユーザーを
囲い込むのは、ビジネスとしてあるべき姿だと思っています。

あと、有効か？と言う論点には、なんらかの判断基準が必要かと思いますが、
「使っていて、シェア向上に寄与している」だけではダメなんでしょうね。

とりあえず、ちゃんとクラス設計すれば、複数人開発で分担しやすく、
単体デバッグもやりやすく、確実で、最後に組み合わせると、ちゃんと動いてくれれば、
「オブジェクト指向らしく有効である」とは思ってて、
あとは、LinuxとWinで動けば、「Javaらしく有効」とか思ってるんですけど、
どうですか？

>>261
大手SIにからんだことはないんだけど今のプロジェクトはWeblogic

差別化はわかるんですよ、ただ便利になっているというのが実感できない。
一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
純粋に使いにくいと思います。

XMLも手書きしろという姿勢もね。

J2EEである必要のない局面で使うのは全体的に手間が掛かるだけではないかと
分散サーバ環境でも何でもないところなのに、そのための手続きを書くのか？とか

あとDBサーバを有効に使わない方向は個人的には嫌いです。
高い金払ってDBサーバ買ってるんだから最大限機能を引き出してやりたいと思うんですけどね。

>262
質問です。

> 一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
> 溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
> 純粋に使いにくいと思います。

これは、大きいところも小さいところも.NETで統一すればいい
という理由になりますか？

確かに、オープンソース系の複雑さは、大企業のオープンソースの熱が
一段落したら表面化してくると思います。

やはり、オープンソースは良い意味で、自分でケツがふけて、
工数がかかることも厭わないオタクのおもちゃだと思います。
フレームワークの乱立なんて、まさしくその辺の表れだと思いますし。

もちろん、大きなところも安定して動く信頼感を得ることがMSには
もっとも重要な責務で、そこ次第だとは思いますが。鯖管やってる
ような人は、Windowsを使ったこともないで否定する人も少なくありません。

>>263
Microsoftのいいところでもあり悪いところ？でもあるのが単純化。
Unix -> Dosもそうだとおもうんだけど、単純化して使いやすくしてくれる。

一般ユーザのレベルなんてLinuxがああいう雰囲気のままだと一生触らないよ。
簡単さがない、よくても悪くても単純に一本化してくれるから逆にJava陣営も
ある程度単純、一本化できないのかなぁ？と。

あと日本語化にどこも熱心じゃないでしょ？
Javaもいままでうけいれられなかったのはそれが原因かなと、そしてすでに.Netの日本語情報の
方が多い現実。

ライバルとしてがんばってほしいとは思うけどね。

>>262
> 質問です。
> > 一般はApache-tomcat 路線、大手企業系Weblogicっていう区切りではどうにも
> > 溝が深くて、さらにバージョンの違いが困惑度を増しているというか。
> > 純粋に使いにくいと思います。
> これは、大きいところも小さいところも.NETで統一すればいい
> という理由になりますか？

ごめん質問に答えてなかった。

大きいところも小さいところも.Netで統一よりは、小さいところもJavaが受け入れられるように
なんとかしろよと。
.Netはすごい勢いで制圧しちゃうかもしれないよ？っと。

技術提供の会社では大企業はWeblogic、一般向けにはtomcatじゃ全然別の環境を用意しなくちゃ
いけないし、TCO的にもWindows環境に負けてる。

オープンソースを推奨するところはそれを維持、管理、開発する人件費を見ていないところが多いね。

>>259

＞果たして、Apache vs IISとかLinux vs Winという対立軸で、.NETの
＞選択肢が、有効な手段とみなされる日は来るのだろうか？

市場はそういう対立軸は意識せずに、単純にアプリケーションを要求するだけでしょう？
その要求を見越して.Netが有効であると判断すれば採用すればいいだけだよね。

>>265

＞オープンソースを推奨するところはそれを維持、管理、開発する人件費を見ていないところが多いね。

そこをうまく騙すというマーケティングがオープンソースの戦略の骨子だから無理もない。

環境：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)

回避する方法を教えてもらえないでしょうか？

あげげ

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


バカが。php最強伝説

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

>>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$以外の競合製品を使わないなら苛めるなんてこともしていると思われる。

>>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をちょっと改造するために作られたように見える。

>>260
> J2EEって本当に有効なんでしょうか？
有効に活用している現場ってある？
>>259ではありませんが、
もろにあります。>>261 の企業のほかに、
IBM, 東芝、あとどこだったかな。
製造業、工場、金融機関、医療機器だったかな。
ミッションクリティカルな現場ではよく使われているらしい。
オークションサイトでも使っているところがある。
一見JSPしか使っていないように見えるけれど、Solaris上で動き、J2EEも使っているらしい。○○王ーク○○ンというサイトだったかな。
お金が絡みますからね、ちょっとしたミスも許されない環境を構築するには信頼性の高いJavaがよく適しているようです。

> ApacheやらWebLogicやらで変わってしまうのも問題だし、わけのわからないフレームワークだとか言うのも
> いっぱいあるのもどうかと思う。
>結局互換性ないしね。

Webサーバの違いによる互換性はさほど影響にならない。
バージョンの違いによる互換性の悪化は、
モジュールを自分でmake(WinならVC++のmsdevか?)すればよい。
他はちょっと修正を加えればよい。
100PureJavaが実現されなくとも他の言語と比べほぼ100%近いポータビリティを実現できるというのが優れている。

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

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

>272
Sunは大企業に離れられると潰れます。ここは最後の砦です。

MSと戦って敗れる企業は、個人ユーザー、中小から堀を埋められて、
最後は大企業、ハイエンド市場のみへと市場が狭まっていく
のは多々あることです。これは珍しいことではありません。

MSと戦って敗れていった数多くの企業は、先駆者としての実力はあるのですが、
いかんせん、アフターケアや、開発環境、商品アピール、日本だったら開発ドキュメントの
ローカライズなどをユーザー側の努力に頼りすぎています。逆にMSは、その辺は
抜け目なくケアしています。

MSに負けていく技術は、一部の偏差値の高いアーリーアダプター層には
熱狂的な支持を受けていたても、ビジネスとしては市場を失っていくというのが
往々にして見られる特徴です。これは高偏差値層が担ってきたコンピューターの
歴史において、前例なき動きであり、彼らにとっては非常に由々しき出来事なのです。

中小企業や個人ユースの市場がMSに奪われていくには理由があり、MSと他の企業を
比較すると、他の企業の方がelegantであっても、いろいろとcomfortableなのはMS
だからでしょう。

>273
＞J#ってRMIが使えないのがちょっと。Windows限定はね、他OSへの移植が面倒くさいのではないかと。

.Net Frameworkでプログラミングしようかと言う人間が他のOSへの移植性なんて
考えて作るもの？

RMIなんて使えなくても、COMが使えるんだからいいんでないの？
他の仕事でJavaも書くことが多いんならJ#が一番楽なのでは？という
気にもなる。

> .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#でも動かせるように作られたものじゃなかった?

>>277
(数多くの企業が)別に何もかも敗れたってことではないんじゃないかな。
つまりM$は宣伝に大量に資金投入しているから勝っていると?
それでもオープンソース的なやり方は敗れていないものではないかな。

M$がいくら特定の企業にかったとしてもオープンソースには勝てないだろうな。何をもって勝利と定義するかによるけど。

M$のやり方に不満をもっているからSunもIBMもあそこまで生き延びることができる。たとえ今突然、赤字続きのSunがつぶれてもJavaが廃れることはないだろう。
またそのとき、JavaがM$に渡る可能性はかなり低いだろう。
司法省が付いているだろうから。あとは政権が交代し、ブッシュ以外のブッシュらしくない政権が現れればM$に好都合なことは起こりにくくなるだろう。

マイクソ製品最高

>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という言語仕様の解釈がずれてるかﾓﾅｰ

>>282
Javaというのをどこまで仕様とするかにもよるけど、Java風構文ができりゃいいんだろ？ってのがMSの主張かな？
それ以上は裁判のこともあるし突っ込みがたい。

で、CLRは来年か再来年にはLinuxには移植されるのではないかと思うがどうだろう？
OfficeがWindows向けじゃなく.Net向けになったときが勝負の時のような気はしますな。

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

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

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

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

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

素朴な質問。

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

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

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

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

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

>>289
Windows2000AdvencedServerなんかで、同一IPでの付加分散できる。
当然コストはかかるけど、Unixなんかとその辺は同じ

2chは付加分散してないから板ごとに鯖ふりわけられてるよね？

その辺はあんまり詳しくないんでsage

>283
> で、CLRは来年か再来年にはLinuxには移植されるのではないかと思うがどうだろう？
> OfficeがWindows向けじゃなく.Net向けになったときが勝負の時のような気はしますな。

確かに、最近のLinux参入の噂を聞くとあっても良いような気がする。
X窓でWinFormsとか動き出したら、凄いことになる。

まぁそこまでは無理そうな印象があるので、とりあえずASP.NETだけでも十分だ。
例えばApacheに組み合わせられるASP.NETとかになると、いろんな考え方の軸が
めちゃくちゃになって楽しい鴨。

>289
漏れもあんまり知らない。今、それやるならWebLogicとか考えるからなんだけど、
興味はすげーある。

が、MSDNのヘルプにゃこんなことが書いてあるので、実はすげー簡単に
できるのではないか？と。
（EJBみたいな分散オブジェクトも、実はすげー簡単にできるのか？）

以下、引用

サーバー ファーム構成に対するサポート -
アウトプロセス モデルに移行することにより、ASP.NET はサーバー ファームの
問題点も解決します。新しいアウトプロセス モデルは、ファーム内のすべての
サーバーが 1 つのセッション状態プロセスを共有することを許可します。

ユーザーは共通のサーバーを指すように ASP.NET 構成を変更することにより
これを実装できます。

>285
VisualStudio.Netが使えるなら、楽チンWebプログラミングで作れるので
決して大げさではありませぬ。

XMLで、ファイルにデータストアして表示するときに、スコアのノードで
XMLソートかけて表示するとかなら、並び替えロジックも書く必要はなく、
.net frameworkのクラスで実現可能。

IISなら最新パッチも、WindowsUpdateがやってくれるから
厨房管理者なら、今はWindowsの方がよっぽど確実かと。

>296
自己レスだが、ローカルネットワークでは、オブジェクトシリアライズを
Binaryで行って、IISが、http,tcp,dcomで分散オブジェクトを実現可能

インターネット経由したきゃSOAPでHttpでもSMTPでもどうぞ。

その辺のサンプルは、
　Duwamish 7.0 サンプル
　Fitch and Mather 7.0 サンプル
などを見ると詳しく分かる模様。

オブジェクト的には、こんな感じ。
System.Runtime.Remoting.Channels.Http.HttpChannel

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

>>289
むりやりCORBA使うとか?

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

（＾＾）

>>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)

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

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

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

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

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

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

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

マッピングは？
内部サーバエラーならちゃんとエラーメッセージひらえよー

IEの簡易エラーメッセージを表示のチェックをはずす。

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

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

>>313　そうなんですね。ありがとうございます。
えっと・・・
使われまくってる「.jp」や「.com」等の後に誕生したもの、、
くらいしか分からないんですが、、。

私、YBBなもので、サポートセンターに「gTLDをjpに変えて下さい」と電話しようと思ってるんです・・。
なので、ウチのリモホ「×××.net」はホントに「gTLD」なのかな・・・？と確認しようと思ってここへ参りました。

>>314
歴史を学んでください。
ドメインとは何かを学んでください。

gTLDをjpに変えて下さい ハァ？何が言いたいのかまったくわからん。

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

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

マジで？　ソースは？

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

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

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

おまえらついにC#死滅スレがPart11になりましたよ

C#って死滅しちゃうの？？？ part11
http://pc2.2ch.net/test/read.cgi/tech/1047322829/

C#は新言語でありながらさまざまなセキュリティの欠陥が存在する。
そんな言語が.NetとWindowsの将来を担っていけるのか？

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

痛いとこ、つくのう。

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

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

#!/usr/bin/perl

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

>>1-332 >>334-1000 win板逝け。厨房

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

#include <iostream>
using namespace std;

string res;

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

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

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