2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

最近のJava事情について Part18

1 :仕様書無しさん:04/03/28 20:41
Javaについてマ板風味で語れ

2 :仕様書無しさん:04/03/28 20:41
前スレ
最近のjava人気について part16
http://pc3.2ch.net/test/read.cgi/prog/1079788181/

3 :仕様書無しさん:04/03/28 20:41
17すっとばすな

4 :仕様書無しさん:04/03/28 20:41
適材適所で使い分けるのが効率的。
話題になる分野にことごとくむりやりPerl/VBを適用しようとするから、馬鹿と言われる。

と表現したほうがいかにも筋が通るとは思うだろw

Javaは何にでも話題にしやすい。
何せ多くのほとんどのコードがOSで動くからね。

家電、組み込み、サーバ、汎用機、金融、エンタープライズ、宇宙船
など将来の利用用途はさまざまだ。

これらの話題に分野でJavaの話がでても何もおかしくない。
そこでJavaが気に入らないからといってJavaを否定する香具師ほど馬鹿といわれる。
考え方が古い時代遅れな奴とすぐに言われる。
とくに、未来の話をしているにもかかわらず、いつまでたっても「Javaは遅い」といっている香具師も
もうそろそろ、化石的思考を持つ古い人と言われてもおかしくない。



5 :仕様書無しさん:04/03/28 20:42
>>3
前スレは実質Part17だ。
あれは重複スレだった

6 :仕様書無しさん:04/03/28 20:42
>>1にあおり文句がないのがいまいち。

でも乙。

7 :仕様書無しさん:04/03/28 20:42
じゃあ前スレの結論は

やっぱりVB大人気

って事で良いですね?

8 :仕様書無しさん:04/03/28 20:43
マ板ではJavaが人気が無い理由は
マ板の年齢層が高齢で頑固親父の巣窟だから、またはレベルが低いからだと思われ。

多くの人々がC/C++教育を受け、またはC/C++でインフラが整備されC/C++だけで満足してしまっている
傾向が強い。
しかし、C/C++は変化に弱い。
複数のOSにソフトウェアを対応させるとなるとOSの数だけ開発にかかる負担が増す。
インスタントラーメンのような即座に食べられるようなラーメンを食べたい者にはJavaは好かれない。

ソフトウェアを、将来、大木に成長する植物にたとえるならば
苗木から始まったソフトウェアを徐々に成長してゆく姿を見たい、楽しみにしている者にとってはJavaは
非常に好意の対象になる。

9 :仕様書無しさん:04/03/28 20:43
1000スレ無駄にした>>1はコンパイル時に $java hoge.java って打ち込んで3時間悩む。

10 :仕様書無しさん:04/03/28 20:44
その長文は青臭すぎるから転載しなくてもいいんじゃね

11 :仕様書無しさん:04/03/28 20:44
未来のプログラミング言語は、プログラミング言語ではなくなっているかもしれない。

これからでるプログラミング言語が登場することで
いつかJavaが使えなくなるかもしれない、と思うことがあるだろう。

しかし、Javaは非常によくできており将来のことを真剣に考えて作られた言語のようだ。
オブジェクト指向言語というものは、それによって作られたソフトウェアが将来長く使われることを
目的として存在しているようなものだ。Javaはいつか消えるだろう。しかし未来のソフトウェア開発では
Javaをベースとしたあるものが使われているだろう。  


Javaで書いたコードはC#やC++に移植、コンバートするのはある程度まではほぼ簡単にできる。
その逆に、多くのコードをJavaに移植、コンバートするのは多くの場合、非常に苦労する。
皆の衆よ、これは何を意味するかわかるだろうか?
まず第一に、多くの言語がJavaから派生させることが容易になる、ということがあげられる。
一度Javaから派生した言語で書いたコードは二度とJavaコードに戻ることができないものがほとんどだろう。
Javaは、派生言語を作りやすい言語ともいえるだろう。
これから登場する多くのプログラミング言語はMixJuiceやC#, D言語のようにJavaスタイルをベースとするだろう。
それだけ、Javaは将来のことをよく考えて作られたということだ。


このマ板ではJavaを否定する者たちは、おそらく自分の作ったソフトウェアを、将来長く使ってもらおうとも
考えていないのだろう(そうでないならば異論、反論求む)。
おそらく、彼らはプログラミングという行為を短時間で済ませたいと考えるものたちなのだろう。
そのため、できるだけ短い時間にすばやく完成させられるような言語を好み、
フレームワーク開発などに時間を費やしたくない、という本音が丸見えなのだろう。

仕事でしかプログラミングすることを考えない者にとってはJavaに対する魅力を感じないのも頷ける。

12 :仕様書無しさん:04/03/28 20:44
他の言語を使うかどうかを迷ったときは、ある指標に従って
Javaをどのように使うかを定める。


拡張性重視の場合はJavaをメインとして少し速度がきになる場合はJNIでC++などを補助的に使用する。
速度重視の場合はJavaを補助的に使う。
拡張性のことはそっちのけでとにかく速度重視の場合はJavaを使わない。


古い資産があり、それを再利用したい場合はこれらはすべて例外として古い資産とともにJavaを利用する。

「このプログラムは10年後に完成させる予定だ。拡張性、移植性重視だ。10年後には
ハードウェアも大幅に進化している。今、速度のことは気にする必要が無い。」
このような場合は100%Javaを使う。

13 :仕様書無しさん:04/03/28 20:45
「このプログラムは10年後に完成させる予定だ。拡張性、移植性重視だ。10年後には
ハードウェアも大幅に進化している。今、速度のことは気にする必要が無い。
また、10年後になったときには新しい言語が登場するかもしれない。」
このような場合でも、新しい言語が登場するまで100%Javaを使う。
現在の状況を想定して、今から10年後に登場するであろう新しい言語はJavaにそっくりな言語であろう。
Javaによく似ていれば移植作業も非常に楽である。

仮にJavaに似ていない新言語が登場しても、UMLツール、IDEの真価によって移植作業には苦労しないと
想定される。

諸君も、Javaが嫌いだからといって、「どうせJavaは廃れるんだから覚えても意味が無い」と
いって、自然に普及しているJavaの普及の妨害を無理してしなくても良い。

「どうせJavaは廃れるんだから」といわずにJavaの良さをプログラミング初心者に伝えたほうが
将来のエンジニアのためになるのである。Smalltalkの良さを知っている者は、
あわせて、Smalltalkの良さも初心者に説明して欲しい。

このような行動によって、将来、自分らの後輩や子孫が苦しんでゆく姿を見なければならない、
ということはなくなるだろう。

14 :仕様書無しさん:04/03/28 20:45
>>3,>>9
http://pc3.2ch.net/test/read.cgi/prog/1079788181/1-13n

15 :仕様書無しさん:04/03/28 20:45
>>12
10年後10年後って、お前は朝鮮人か。

16 :仕様書無しさん:04/03/28 20:46
Eclipse
http://www.eclipse.org/

Java
http://java.sun.com/

17 :仕様書無しさん:04/03/28 20:46
>>15
激しくワロタ

18 :仕様書無しさん:04/03/28 20:47
10年後を言うとなんで朝鮮人になるんだ?


19 :仕様書無しさん:04/03/28 20:47
ただの例え話じゃん

20 :仕様書無しさん:04/03/28 20:47
>>10
本当に青臭いと思うならその理由を明記すべきだと思う。

21 :仕様書無しさん:04/03/28 20:48
つか、単純に大規模開発はjavaで書くのが一番効率いい。

文法簡単だから、ドカタコーダはすぐに集められる/育成できるし。
Eclipseあるから、コーディングも楽だし。
オブジェクト指向だから、再利用性の高いコードがかけるし。
一人分かっている人間が居れば、数ある選択肢の中から、適切なフレームワークの選別/クラス図作成までやってくれるし。

その後はみんなでいっせーに、「それ書けー!!!」
出来上がったらそれをお客に提示、要望をまとめて、再構築、でまた、「それ書けー!!!」
下位のクラスで出てきた同じようなパターンは、リファクタリングをかけて、整理、必要ならスーパークラスに抽出。
外注に投げるときも、ユニットテスト込みで発注すれば、品質も安定。管理も楽チン。

やっぱjavaでしょ。

22 :1:04/03/28 20:49
>>6
煽り文句をたてると有益な議論を転換することを嫌う香具師がでてくる。
そうすると煽り厨しかこのスレを使わなくなる。
それでは効率が悪い。
なので中立的な意味をこめてスレタイも少し変えてみた。

23 :仕様書無しさん:04/03/28 20:50
>>18
10年後に日本に追いつく。
10年後に日本を追い抜く。
もう数十年間↑のセリフを言い続けてる馬鹿民族だからさ。

24 :仕様書無しさん:04/03/28 20:50
>>21
つまり、JavaはドカタコーダをSEに成長させる力があるわけだと


25 :仕様書無しさん:04/03/28 20:51
>>20
素で言ってんの?

26 :仕様書無しさん:04/03/28 20:51
>>23
そういうことか。けどJavaでの例はただの喩えだし。

10年後においつくんではなく10年経っても長持ちする、が正解じゃないかと

27 :仕様書無しさん:04/03/28 20:52
>>23
すべての韓国人がそうだったら恐ろしい

28 :仕様書無しさん:04/03/28 20:52
つか、単純に大規模開発はcobolで書くのが一番効率いい。

文法簡単だから、ドカタコーダはすぐに集められる/育成できるし。
過去の負債あるから、コーディングも楽だし。
英文法指向だから、局所的には可読性の高いコードがかけるし。
一人分かっている人間が居れば、数ある選択肢の中から、
もっとも人月稼げる選択までやってくれるし。

その後はみんなでいっせーに、「それ書けー!!!」
出来上がったらそれをお客に提示、要望をまとめて、再構築、でまた、「それ書けー!!!」
下位のクラスで出てきた同じようなパターンは、コピペをかけて、清書、必要ならまたコピペ。
外注に投げるときも、デスマ込みで発注すれば、費用も安定。管理も楽チン。

やっぱcobolでしょ。

29 :仕様書無しさん:04/03/28 20:53
>>9
Ant使っているので悩みません。

30 :仕様書無しさん:04/03/28 20:55
そうか、Javaを普及させればドカタコーダを激減させる力があるのか。
それは凄い発想だ。

ドカタを減らしてプログラマの給料を高める。
そして今までSEのみにしか許されていなかった仕事をすべてプログラマが兼任する。

それはすごいことだ。

31 :仕様書無しさん:04/03/28 20:55
そうだ、これは下手にCOBOLやVBを流行らせるよりも効率がよいことだ。


32 :仕様書無しさん:04/03/28 20:56
Javaはプログラマの質を高め、CMMレベルを高める効果がある。

33 :最凶VB厨房:04/03/28 20:56
CMMレベルだってw

34 :仕様書無しさん:04/03/28 20:56
>>30
いや、まあ、結局ドカタコーダが居なくなっては困るんだけどね。
設計図だけではビルは建たないし。

やっぱ、スコップと鶴嘴もって、どてちんやる方々がいて、初めて今日のニポンがあったんよ。

35 :仕様書無しさん:04/03/28 20:57
>>7
言いたいことがあるならそういうタイトルのスレを建てましょう
最凶VB厨房君


36 :仕様書無しさん:04/03/28 20:59
ん?
最凶はVBでFAだろ
いろんな意味で

37 :仕様書無しさん:04/03/28 20:59
>>35
糞スレ設立を促す発言。それに最後の一言。
どれを取ってもお前はリア厨だと思われる。

38 :仕様書無しさん:04/03/28 21:00
VBマンセーうなってる香具師はどうせ最凶VB厨房だろ

それとお前さん、自作自演ご苦労なこったw

39 :仕様書無しさん:04/03/28 21:02
>>34
そんなこといったらC厨やVB厨はみんなドカタじゃん。

クラス設計やフレームワーク設計とかしている香具師だけが優位になっている構図じゃん

40 :仕様書無しさん:04/03/28 21:02
1K万以下の仕事でやっつけでやるなら、VBよりいい言語ないでしょ。

客からVBで難しいことを言われると、とたんに開発効率落ちるけど。

41 :仕様書無しさん:04/03/28 21:04
>>39
ぶっちゃけ、そう。

だから、javaドカタコーダはドカタコーダでいてはいつまでたってもVB, COBOL使いと変わらないということ。

42 :仕様書無しさん:04/03/28 21:05
客にVB覚えられて突っ込まれる。
「実装できないことないよね?」

43 :仕様書無しさん:04/03/28 21:21
VB, VBというけどさ、VB.NETはVB6と比べると大部違うよ。
殆どC#だ。ありゃ。

44 :仕様書無しさん:04/03/28 21:23
大人数に単純労働を割り振り、結合しやすいのがJavaのドカタたる所以

45 :仕様書無しさん:04/03/28 21:27
そう。Javaは工場である。
金髪や茶髪のDQN工員に効率よく一定品質のものを大量生産せせるための機構なのである。

Javaでデスマってる開発室に行けば、彼ら工員によく似た専門学校卒の派遣PGが馬車馬のように
働かされているであろう。

46 :仕様書無しさん:04/03/28 21:28
いつまでたってもJavaをドカタにしないと気が済まない思考を持つ者はやっぱり真性ドカタVB厨だったのか

47 :仕様書無しさん:04/03/28 21:28
>>45
コピペネタはもう飽きた

48 :仕様書無しさん:04/03/28 21:29
>>40
> 1K万以下
これ何? 1000万のことをえってるのけ?

49 :仕様書無しさん:04/03/28 21:31
でもさ、実際のとこJavaPGって派遣が殆どと思わない?
俺の周りだけかな。しかも、どの案件もことごとくデスマ・・・

50 :仕様書無しさん:04/03/28 21:34
NRIの下僕会社とかな。

51 :仕様書無しさん:04/03/28 21:35
>>43
一般にVB厨といわれる香具師はVB6厨なり

VB.NET厨はC#厨と同格

52 :仕様書無しさん:04/03/28 21:36
>>49
派遣に任せようとしてデスマってるんだろうな。
派遣にやらせるとそれだけやる気が削がれるからな。

53 :仕様書無しさん:04/03/28 21:37
Javaが悪いわけじゃないんですよ。

54 :仕様書無しさん:04/03/28 21:42
>>49
Solaris信者のPerl厨のリーダーとOracleマスターがいて
それのチームでオークションシステムの開発をしていた中に派遣でJavaをやっているのがぞろぞろいたが。
彼らは派遣といえど人材派遣会社から来た派遣とは違う香具師らだったよあれは。

ただの契約社員。本社に戻れば正社員Javaプログラマだった。
Java以外にもちゃんとデータベースとか使いこなせる香具師の10人ほどの集団だったか。

おれはそこで学生アルバイトとしてJavaプログラマをやった。
最初はJavaを使える香具師が少なくJavaプログラマを急募していた。
そのとき俺がバイトに応募してJavaをやることになった。
PerlとかCはわかってもJavaのことは一切解らない香具師で
もちろんクラスの使い方も解っていなかったな彼らは。
このthisやsuperって何を意味する?と聞いてくるレベルだったな。


55 :仕様書無しさん:04/03/28 21:43
>>53
オウム返しはもう飽きた。
死滅スレ風味を作り上げるなとお前。

56 :仕様書無しさん:04/03/28 21:45
派遣を使うからデスマになるんですよ。Javaが悪いわけじゃないんですよ。

57 :仕様書無しさん:04/03/28 21:46
協力会社の正社員?

58 :仕様書無しさん:04/03/28 21:48
まあ、NRIの協力会社社員はこんなとこにはこないけどなw

年度末デスマで

59 :仕様書無しさん:04/03/28 21:55
ぶっちゃけJavaプロジェクトが破綻するのは、
プロトタイプ型開発/XP型開発の誤用、悪用によるものがほとんど。

Javaは登場した頃からずっと、プロトタイプ型開発に向いているといわれていた。
オブジェクト指向型で、再利用性の高いコードが書けること。
インタフェース/抽象メソッド宣言を利用した、実装なきままのコード作成が可能であったこと。
これが主な理由。

が、しかし実際にプロトタイプ型開発を正しく使える開発者はなく、
そのコンセプトを理解して使用できる人間も居ないままスタートしたJavaプロジェクトも多数あった。
そういったプロジェクトでは、顧客仕様の抽出を先延ばしすることにプロトタイプ型開発の名前が悪用された。
そのため、仕様の確定が先延ばしになり、無意味なコードが山ほど書かれ、
結局作り直しの憂き目を見る。

そこへ来て、設計部と実際のコーディングを行うコーダ舞台の間に溝があったとすれば。
たとえば、コミュニケーションに失敗した設計部と派遣コーダのような。
これは当然失敗してしかるべき構図。
設計部から次々に無意味なコードの書き直しが出されたとしたら、
それは派遣に伝わるだろうか?
コーダから見れば、設計への不信感で、開発効率はがた落ちになるわけ。

60 :仕様書無しさん:04/03/28 21:58
つまり、開発者が低脳なだけ。Javaが悪いわけじゃないんですよ。

61 :仕様書無しさん:04/03/28 21:59
結局、Javaが無実というのはわかったけど、
マネージャが悪いの?派遣コーダが悪いの?


62 :仕様書無しさん:04/03/28 22:00
うまくいった例はあるんですかー。

63 :仕様書無しさん:04/03/28 22:01
PHPでさくっと。

64 :仕様書無しさん:04/03/28 22:06
>>61
どっちが悪いと言われれば、マネージャかなあ?

ただ、状況が適切に説明されていれば、
なぜそんな開発を進めなければならないのか、という理由が、
派遣コーダにも伝わったかも知れない。

それぞれ、バカなことをするにはそれなりの理由があるってことが伝われば、
コーダも苦笑いしながら付き合ってくれるかも。

65 :仕様書無しさん:04/03/28 22:09
泣くのは派遣PGだけどね

66 :仕様書無しさん:04/03/28 22:11
最終的に泣くのはお客様です

67 :仕様書無しさん:04/03/28 22:22
つまり、ドカタってことさ。

68 :仕様書無しさん:04/03/28 22:23
>>65
大変なのは、シッパイが発覚した後でスケープゴートで首切り、降格、減俸の憂き目に
遭う、立ち回りの下手な中間管理職何人か。

問題があるのは、不適切な人事をおこなった奴だと思うけどねー。そういう奴が責任
取ることはねえからな。できることも出来なくなるようなひどいアサインしておいて
なに寝言いってんだボケ、とぶん殴りたいエリート連中が数名いるなあ・・・

…俺が負け犬なのか…ガックリ。

69 :仕様書無しさん:04/03/28 22:26
そんな思いをしてもJavaなんですよ。

70 :仕様書無しさん:04/03/28 22:36
Javaで“テレコム業界のOS”を実現する
http://itpro.nikkeibp.co.jp/free/NCC/INTERVIEW/20040324/141882/index.shtml

電話事業者や通信機器メーカーなどのテレコムの世界に,コンピュータ業界と同様
の“オープン化”をもたらそうとする試みが始まっている。その代表的な存在の一つが,
サン・マイクロシステムズが唱える
「JAIN SLEE(Java API for integrated networks service logic execution environment)」だ。

JAIN SLEEは簡単に言うと「テレコム・アプリケーションのための開発・実行環境」。
JAIN SLEE上でJava言語を使いテレコム・アプリケーション(アプリ)を開発すれば,
アプリの移植性(ポータビリティ)が大幅に高まる。
 例えば,通信事業者AがJAIN SLEE上で作ったアプリは,そのまま通信事業者Bが使える,
といった具合だ。もっと噛み砕いて言えば,「OSがWindowsであれば,A社のパソコンでもB社
のパソコンでも同じアプリが動く」──このような世界をテレコム業界に作り上げようとしている。

71 :仕様書無しさん:04/03/28 22:37
 JAIN SLEEはこの2月にバージョン1.0の仕様が公開されたばかり。
オープン・クラウド(本社:ニュージーランド・ウエリントン市)の
デヴィッド・フェリーCTOは,サン・マイクロシステムズと共に
JAIN SLEEの仕様策定に携わった人物。同氏にJAIN SLEEの
可能性について聞いた。(聞き手は武部 健一=日経コミュニケーション)

−−JAIN SLEEで何ができるのか教えて欲しい。

 JAIN SLEEは「テレコム用のオペレーティング・システム」のような
ものだと考えて欲しい。JAIN SLEEの上で開発されたアプリケーションは,
IPネットワークや携帯電話,SS7網,SIP網など,様々なネットワークに対して
配布できる。つまり,テレコムの世界でアプリケーションのポータビリティを実現する。
そして,このJAIN SLEEの仕様に基いて我々の会社で実装したのが「ライノ」という製品だ。

72 :仕様書無しさん:04/03/28 22:38
−−Javaと同様に「一度開発すれば,様々な場所(ネットワーク)で使える」ということか?
具体例を示して欲しい。

 例えば,固定電話や携帯電話,IPネットワーク,あるいは何らかのレガシーなネットワーク
があるとする。これらのネットワークにリアルタイム課金の機能を付け加えたい。
このような場合,JAIN SLEEが無ければ,それぞれのネットワーク用にバラバラに機能を付
加する必要がある。一方,JAIN SLEEに準拠していれば,JAIN SLEEという一つの実行環境上
でその機能を開発し,各ネットワークに対して配布するだけだ。

73 :仕様書無しさん:04/03/28 22:39
−−他にはどのようなケースで有効だとか考えるか?

 ネットワークのマイグレーション(移行)にも有効だ。例えば,2.5Gから3Gへ携帯電話サービスを
移行中の通信事業者がいるとする。将来的には3Gへ移行するが,当面は2.5Gを中心にビジネス
を行っている。このような場合,従来であれば2.5G用のアプリケーションを3Gへ移行させるためには,
アプリの全面的な書き換えが必要だった。だが,JAIN SLEE上でアプリを開発しておけば,アプリは最
低限の修正で2.5Gから3Gへ移行できる。
 すでに,昨年の10月にはスペインのボーダフォンがJAIN SLEEを使った実証実験の結果を発
表している。私たちは4カ月間,ボーダフォンと共にJAIN SLEEを用いてVPN(仮想閉域網)などの
アプリケーションを作り,何度もテストを行った。ボーダフォンはJAIN SLEEが従来のシステムと同
等の性能と可用性を持っていると評価している。

−−日本での取り組みは。国内の携帯電話事業者とも検証実験を行っているのか?

 現在,日本では適切なパートナーと仕事ができるように努力してる。携帯電話に限らず,
主要な通信事業者や通信機器メーカーと話をしているところだ。

74 :貧乏紙:04/03/28 22:58
プログラム板がなくなったから誰か付き合ってくれ。
CDの音は16bit 44.1KHzだ。
16bit 1111 1111 1111 1111となり65536段階を区別できる。
しかし、周波数特性が0-20,000Hzとしたときそれを格納するのに15bit必要になる。
が、それだと音の大きさが格納できないので、多分基本形みたいなものがあって
それを14bit16384段階であらわしていると思う。そうするとだ、15bitで音の情報が
格納できる。残り1bitは誤り訂正だとすると、奇偶数パリーティーしか使えない。
でも、実際はもっと高度にエラー訂正がされている。
CDはいったいどうやって記録してんだ?それさえわかれば圧縮(MP3)などの
プログラムが大体わかるような気がする。誰か教えてくれ。

75 :仕様書無しさん:04/03/28 23:00
>>74
RedBook読め

76 :仕様書無しさん:04/03/28 23:10
Javaスレで聞く真意が理解できない。
音声ネタスレだろ。

77 :仕様書無しさん:04/03/28 23:16
>>74
実は18bitsとか。いや
ECC非対応メモリみたいなもんじゃないかと。

どうせ音声データだ。割れたCDをセロテープで留めても再生できるんだぞ。
変な奴はCDをカッターで傷づける、ケーキやピザのように切ると音がよくなるとか
馬鹿なことを言っているほどだ。そういうことは、それほど人間の耳には雑多なことなんじゃないのか?
MP3であればもっと雑多だろう。

しかもあれは完全にデジタルで保存か?
CD-Rに焼くとき1倍速で焼いた方が音が綺麗になるだろ。

78 :仕様書無しさん:04/03/28 23:16
>>74
そのようなコアな話にはJava派遣はついていけません。
言語仕様でかたずく話にしてください。w

79 :仕様書無しさん:04/03/28 23:17
最近のCD-Rは700MB, 720MBまで入るなあ。
秋葉にいくと800MBもある。

80 :仕様書無しさん:04/03/28 23:17
>>78
それで煽っているつもりか坊主。
Javaプログラマならついてゆけるだろ。


81 :仕様書無しさん:04/03/28 23:18
オープンソース検索エンジン「Nutch」の実力
http://www.atmarkit.co.jp/fjava/column/andoh/andoh23.html

■検索エンジンの台頭

 現在、インターネットを利用するユーザーにとっても、インターネットで仕事やプログラム
開発を行っているユーザーにとっても検索エンジンはとても重要なものです。
SEO(Search Engine Optimization)という業種も確立し、新規インターネットビジネスサイ
トを立ち上げる際や、既存サイトのアクセス数を増加させたい場合、SEOが重要な意味を持
つようになってきています。つまりWebデザインだけでなく、Webサイト(ページ)がどのよう
に検索エンジンとかかわってくるのか、SEO分析や、SEOに関するノウハウが重要視されます。

 確かに便利な検索エンジンの台頭は歓迎されることです。一方、少なからず問題もはら
んでいます。現在の寡占状態にある検索エンジン業界が、ある1社(または数社)によって
独占される状態がこないともいい切れないことです。今日、敏感に感じることができるほど
検索エンジンの数は減少しています。現在の寡占状態からみて、ある企業の商業利用に
独占される可能性がないとはいい切れません。1社の独占は、多くのインターネットのユー
ザーにとってよくないことです。

82 :仕様書無しさん:04/03/28 23:19
現在はある程度落ち着きましたが、検索エンジン業界の中では熾烈な買収劇が繰り広げられ
ています。Microsoftも100億ドルでGoogleを買収しようとしましたが話がまとまらず、
独自の検索技術開発に注力しているといううわさも聞きます(その後この買収のうわさは否定され、
真偽のほどは定かではありません)。

 うわさはともかく、検索エンジンビジネスが100億ドル級のインターネットビジネスとして機能し
ていることが明らかになったともいえます。つまりは新規検索エンジンとして業界に乗り込もう
とすると、数十億ドル級の潤沢な資金がないと無理ということを示唆してもいます。

83 :仕様書無しさん:04/03/28 23:20
■真にオープンな検索エンジンNutch

 検索エンジンの寡占・独占状態を打破するために登場したのがオープンな検索エンジン「Nutch」です。
Nutchはソースコードが公開され、検索のアルゴリズムが公開されている、真の意味でのオープンな検
索エンジンソフトウェアです。ただし、公開されているのはそのソフトウェア自身であり、現在は検証用の
デモシステムが構築されているのみです。Nutchプロジェクトは2003年6月に、ユーザーが1億個の文書
ファイルを検索できるデモシステムを構築しました。

 Nutchは、開発リーダーのDoug Cutting氏が命名したものです。由来は、彼の幼い息子
が「lunch(昼食)」のことを「nutch」といっていたのを聞き、それをこの検索エンジンの名前に使ったそうです。

 Nutchのプロジェクト進行には、検索エンジン「Overture」(現在はYahoo!に買収された)が資金的に協
力しています。またロータスの創業者であり、現EFF(エレクトロニック・フロンティア財団)のミッチ・ケイ
パー氏や、O'Reillyのティム・オライリー氏も協力しているそうです。


 Nutchの基本部分は、電子メールなどの検索を行うための「Jakarta Lucene」がベースになっています。

また、Nutchのデモシステムは人手で編集されているディレクトリサービス
「DMOZ Open Directory(dmoz.org)」を起点としています。DMOZに登録されていれば、
Nutchのデモシステムからの検索対象となります(つまりはNutchデモシステムからの
クローラー(注)の対象となります)。一般的なApache+Tomcat環境でデモシステムを構築し、
動作させることができます。

注:検索用の情報を集めるために、インターネット上のサイトを定期的に巡回するロボット型の
プログラムのこと

84 :仕様書無しさん:04/03/28 23:21
コピペうざい

85 :仕様書無しさん:04/03/28 23:21
Nutchが目指す性能として以下のポリシーが掲げられています。
1カ月ごとに10億ページを取ってくる検索エンジンとして使えること

これらの規模のページのインデックスを維持すること

1秒につき最高1000回の検索インデックスを付けること

非常に高品質で素晴らしい検索結果を提供すること

最小のコストで動作すること

 Nutchは検索アルゴリズムを公開しています。これは暗号技術が、
それ自身のアルゴリズムを公開することによって、その暗号の強固さをアピールする
ことにとてもよく似ています。検索エンジンのアルゴリズムを公開すると、脆弱性があ
った場合に狙われるとか、アルゴリズム公開を逆手にとり不当な順位付けを導くよう
Webページをカスタマイズするとかの心配も語られています。

 Nutchの目的は、オープンな公正な検索結果を提示することにあります。現在の商用
検索エンジンに対抗しよう、駆逐しようとするものではありません。

86 :仕様書無しさん:04/03/28 23:22
■Nutchの課題

 オープンソース検索エンジンとして前途洋々に思えるNutchですが、
開発リソース(開発者数)が十分でないなど、さまざまな課題も抱えています。
Java/UTF-8ベースで国際化されており、日本語も使えるが、各国語固有の細
かい対応や、ドキュメントなどの環境が未整備

自分で検索エンジンを構築する場合、クローラーがないので、検索の元となる
情報の収集が別途必要となる(オープンソースのクローラー Grub <http://www.grub.org/>
を推奨している)

本格的に運用するには、大規模なマシンリソースが必要(大量のディスク容量)

現在PDFファイル内の文章の検索には対応していない

87 :仕様書無しさん:04/03/28 23:22
>>84
この悪党め!貴様のような煽り厨の思い通りにはさせないぞ!

88 :仕様書無しさん:04/03/28 23:23
■Nutchの未来

 優秀な検索エンジンが無料で使えるのに、なぜわざわざ新たに検索エンジンを
開発しようとするのでしょう? その答えとして、1つのチャンネルしかないテレビを
想像してみてください。ニュースの話題は1種類で、お笑いネタも1種類、そうなる
とすべて受け身の、お仕着せの情報になってしまう危険性をはらんでいます。

 Nutchの果たす役割として、以下の事柄が挙げられます。
サーチ結果の算出方法についてアルゴリズムの透過性(公開性)の高いエンジン

を持つことによって、ほかの検索エンジンの検索結果との比較ができること

サーチエンジンの構造を公開することにより、より検索技術が一般化し検索技術
に関する興味や、研究開発が促進されること
だれもが独自の検索環境を手に入れることができること

 ある特定のカテゴリや、ある特定のサイトに限定した検索エンジンとして、
Nutchはとても有用なのではないかといわれています。Nutchは現在のところ
PtoP的検索エンジンには手を広げていません。その理由は現在の技術では「遅い」こと
が分かっているからだそうです。ただ、全面的に否定するわけではなく、PtoP検索エン
ジンに対する将来的期待も語られています。

89 :仕様書無しさん:04/03/28 23:25
Nutchが目指すのは、ある特定の企業の持ち物ではなく、世界のインターネットユーザ
ー全体で所有する、オープンな検索エンジンです。最近GoogleのIPO(株式公開)が話題
になっています。実際どのような形で株式公開されるのかはまったくの未定です。ただ
、特定企業に株を買い占められるようなことがなく、インターネットでGoogleを利用して
いる多くのユーザーに、企業としてのGoogleを支えてもらえるような形態で株式公開した
いとの意向を伝え聞いています。LinuxやApacheのようなオープンソースへの流れが
検索業界にも流れ込んできています。Nutchを筆頭として、検索業界・検索技術が大きく
変化してきています。「検索」は今後とも目が離せない発展が楽しみな技術の1つです。

 余談ですが、日本にはNutchというピーナッツ入りのチョコレート菓子があることは、
海外のNutchユーザーたちにはあまり知られていません。 おいしいですよ!

90 :仕様書無しさん:04/03/28 23:25
つーかおまいらにEFMとか変調とか言ったってちんぷんかんぷんだろ。
ボケ。

91 :仕様書無しさん:04/03/28 23:26
このコピペ野郎は話の流れを変えるのに必死だな。
Java派遣よご苦労さん。

92 :仕様書無しさん:04/03/28 23:27
JavaがJAINによってIP電話で使われる日も近いな。

Googleをサポートする仕組みがNutchで使われるのか。
これはJavaが検索エンジンまで裾野が広がっていることの表れか。


93 :仕様書無しさん:04/03/28 23:28
>>91
このスレにはJava派遣なんぞいないよ。煽り厨のドトネト派遣よ煽りご苦労さん。

94 :仕様書無しさん:04/03/28 23:30
実際のところ話の流れを変えようとしているのはドトネト派遣だよ。
JAINの話題をそらそうと貧乏神が話題を変えようとしているわけだから。



95 :仕様書無しさん:04/03/28 23:30
NutchがNamazuにとってかわるんだろうな

96 :仕様書無しさん:04/03/28 23:31
>>90
それくらい知ってるよ。情報科卒をなめないでくれ。

97 :仕様書無しさん:04/03/28 23:31
話しについて行けなくなると、いつも道理の決まり文句だな。
組み込みにおいてJavaを語るつもりなら、CDのデータ変換方式ぐらい
1分以内に答えてみろ。言っておくがスパークラスの話じゃないぞ。w

98 :仕様書無しさん:04/03/28 23:33
このスレはJava事情について語るスレだから
ああいうコピペは問題ないだろう。

煽り屋の不毛な争いを阻止するために強硬手段に踏み切ったのだろう。
より有益な議論をするためには必要なことなのだろう。


99 :仕様書無しさん:04/03/28 23:33
ナッチとJavaって何の関係が有るの?

100 :仕様書無しさん:04/03/28 23:34
チャットじゃないから1分以内にここにレスすることには期待できないだろうな。
そんな煽りには載ってこないだろ。

101 :仕様書無しさん:04/03/28 23:34
>>99
>>81-89まで良く読んでみ。
もろに関係あるから。


102 :仕様書無しさん:04/03/28 23:35
>>97
ほう、そうか、あんたは組み込みJavaでCDを使う場面があるのか。
Javaと直接関係あるならその例を紹介してくれ。

103 :仕様書無しさん:04/03/28 23:37
>>99
検索エンジンがオープンソースでTomcatで動かすことができるというものだよ。
Jakarta Luceneをベースとした検索エンジン。

104 :仕様書無しさん:04/03/28 23:39
トリビア的な話題が好きな香具師がおるな。
それで自分が知っている僅かなことを相手が知らないだけで優越感に浸ろう
とはなんとも愚かな自己満足、自画自賛と変わりませぬな。

105 :仕様書無しさん:04/03/28 23:41
とりあえず、Luceneのサイト


Jakarta Lucene
http://jakarta.apache.org/lucene/docs/


106 :仕様書無しさん:04/03/28 23:42
Luceneの意味を必死に調べようとしている

107 :仕様書無しさん:04/03/28 23:43
>>59
成功したことあるんですか?デスマしか遭遇したことないんですが。

108 :仕様書無しさん:04/03/28 23:47
>>107
いっつも仕様が固まらないもんね。とりあえず〜とりあえず〜

109 :貧乏紙:04/03/28 23:47
どうもこのスレには「知ったか」が一匹いるようだな。仕方ないから相手でもしてやるか。
知ったか君に質問です。
1、
servletでのイベント処理にはxmlに登録しなければイベントの通知を受けられませんが
ひとつだけxmlに登録しなくてもいいものがあります。何でしょうか?
2、
jspのカスタムタグ利用において<rtexprvalue>要素にtrueまたはyesを指定しないと
どうなるでしょうか?デフォルトではfalseになってます。

110 :仕様書無しさん:04/03/28 23:48
Javaで検索エンジンを作ることに疑問を持つ香具師多そうだな
このスレでは

111 :仕様書無しさん:04/03/28 23:49
誰も自身のことを知ったか君とは思っていないから相手にされないと見た


112 :仕様書無しさん:04/03/28 23:49
んで、しわ寄せは末端のPGが徹夜でやっつけることになるんだよね。
皆さん、現場知ってて書いてるの?冗談抜きで死人がでてるんだよ。

113 :仕様書無しさん:04/03/28 23:49
貧乏紙はアンチJava?

114 :仕様書無しさん:04/03/28 23:50
>>109
>>104

115 :仕様書無しさん:04/03/28 23:50
10分以上経過しても、フォーマットの基礎すら答えられないとはな。
まあ、予想道理だ。その答えの一部はさっき書いてやったのによ。
いいか、組み込みにおいてJavaの位置なんてあってもなくても同じなんだよ。
バブリーなおまけでしかない。
ましてコアな部分には、絶対使われない。
っていうか、使うことが出来ないよな。あの中途半端なプリミティブ型しかなくては。
バイナリのファイルでさえ無理して使おうとすればキャスト、代入ののオンパレードだ。
JNIとかほざいているやつもその利用範囲が全く解っていないようだしな。
所詮はOSのAPI叩くレベルしか使えない。携帯に代表される組み込みではJNIなど
全く使われない。その意味ぐらいわかるだろ。


116 :仕様書無しさん:04/03/28 23:50
おまいらさ、こんなところで話してないで、
日曜深夜は彼女とSEXしろよ。ほら、世の中今がSEX時だぜ?
想像してみろ。どれだけの男が今この瞬間にピストンしてるかを。

117 :仕様書無しさん:04/03/28 23:51
っていうか自演ウザイ。
マジで死んでくれ
強制ID導入してくれって感じ



118 :仕様書無しさん:04/03/28 23:52
答えられないんじゃなく相手にされてもいないことを解ってない煽り厨

119 :仕様書無しさん:04/03/28 23:52
どうして何でもかんでもJavaで作ろうとするんだ?

120 :貧乏紙:04/03/28 23:52
しょうがないから選択問題にしてやるか。
スレッドセーフとなる変数は次のうちどれでしょう?
1、ローカル変数2、インスタンス変数3、クラス変数

121 :仕様書無しさん:04/03/28 23:53
Genericsの使い方も理解できない煽り厨

122 :仕様書無しさん:04/03/28 23:53
>>59
仕様の確定が先延ばしになってる時点で終わってますよ。

123 :仕様書無しさん:04/03/28 23:53
>>116
コーディングでSEX以上の快感を味わえます。

124 :仕様書無しさん:04/03/28 23:54
>>120
そんなことも自分で調べられないのか?
で、もの聞くときは教えてくださいだろ。

125 :仕様書無しさん:04/03/28 23:54
>>115
一生末端タイプの典型だね。自分じゃ高度なこと理解してるつもりだろうけど。
10年も経てば周りは職人だとか、根っからの技術屋と言うかもしれないが、
ビジネスマンとしてヘタレだよ。抽象的に見たら、お前が言ってる事の殆どは
変数に値を代入する方法を試行錯誤説明してるに過ぎない。


126 :仕様書無しさん:04/03/28 23:54
協力会社の奴隷が紺猿に歯向かえるわけがありません。合掌

127 :仕様書無しさん:04/03/28 23:54
誰に出題してんだか。
また自分の宿題を他人にやらせようと言う輩ですか。
ム板が使えないからマ板に流れてきた教えて君ですか。


128 :最凶VB厨房:04/03/28 23:54
クラス変数ってなんですか?

129 :仕様書無しさん:04/03/28 23:55
>>59
作り直しの時点で終わっていますが何か?

130 :仕様書無しさん:04/03/28 23:56
>>115
> いいか、組み込みにおいてJavaの位置なんてあってもなくても同じなんだよ。

組み込みC厨煽りご苦労。チミの地位もそう長くは続くまい。
Javaの浸食を恐れるC厨。JAINがそんなに怖いか(ワラ



131 :仕様書無しさん:04/03/28 23:57
Jiniをも恐れる組み込み派遣C厨

132 :仕様書無しさん:04/03/28 23:57
JiniとJNIとを間違えるC厨(プ

133 :仕様書無しさん:04/03/28 23:58
RISCチップに追われる最適化C厨(w

134 :仕様書無しさん:04/03/28 23:58
>>129
終わってるけど、そこはドカタがちゃっちゃと片付けます。

135 :仕様書無しさん:04/03/28 23:58
金持ちデータベースエンジニアを嫉む貧乏組み込みC厨w


136 :仕様書無しさん:04/03/28 23:58
いつまでも技術技術って恥ずかしいよ。
来るべき時が来たら先人の知恵と自分の経験を重ねて、それを次世代に伝えないと。
それが技術だろ?

137 :貧乏紙:04/03/28 23:59
しょうがないから回答してやるか
ローカル変数は常にスレッドセーフ
インスタンス変数はマルチスレッドにおいて変数を共有されるのでダメです。
クラス変数は同じクラス同士で共有されるのでダメ
クラス変数とはstatic変数です。

138 :仕様書無しさん:04/03/29 00:01
そこでミューテックスですよ。お父さん

139 :仕様書無しさん:04/03/29 00:02
貧乏紙コテハン、独り言みたいだな。

Servletやってる香具師ならだれでも知っていることをいちいち解説するのもどうかと。

スレッドやプロセスにかかわらず並列処理プログラミング経験者ならだれでも知っていることだろが。

140 :最凶VB厨房:04/03/29 00:02
static変数とはなんですか?

141 :仕様書無しさん:04/03/29 00:02
>>138
J2SE1.5の
java.util.concurrentのドキュメントを良く読んでおけ。
勉強になるぞ


142 :仕様書無しさん:04/03/29 00:02
設計者のオナニィをPGが不眠不休のドカタ仕事でフォローする。これがJavaの現実。

143 :仕様書無しさん:04/03/29 00:03
>>137
> ローカル変数は常にスレッドセーフ
おまえが書いたマルチスレッドなプログラムは触りたくない。
頼むからうちのプロジェクトに来るな。カーネルモード、ユーザーモードあたりから
勉強し直したら?

144 :仕様書無しさん:04/03/29 00:03
データベースとかの方が金になるからな。
組み込み系は金にならないw       

145 :仕様書無しさん:04/03/29 00:03
貧乏紙は組み込み系の仕事をしているだけあってさすがに貧乏か(ワラ

146 :仕様書無しさん:04/03/29 00:04
貧乏紙は派遣以下ということか

147 :貧乏紙:04/03/29 00:04
RISCチップとは
論理回路だけ
命令数は少ない。単純命令だけ。
コンパイラを使うことが前提になりコンパリラの最適化技術が重要。
CISCチップとは
マイクロチップが論理回路の前にある
命令数が多く。複雑な命令もできる。
機械語でもあるていどプログラムできる。
こぞう。なめるなよ!

148 :仕様書無しさん:04/03/29 00:04
シンクロも知らないアフォ貧乏ペーパー

149 :仕様書無しさん:04/03/29 00:05
将来、Javaにvariable型が追加されたらどうしよう。
varって予約語が怖い。VBの二の舞だよ・・・・。

150 :仕様書無しさん:04/03/29 00:05
>>140
おまえVB.NETやってるんだろ?
なんで知らないんだ?

151 :仕様書無しさん:04/03/29 00:05
>>74

その書き方だと、サンプリング周波数と、再生する
音の周波数がごっちゃになってるような気がする。

周波数と大きさ を格納するんじゃなくって、その瞬間の
音波の高さを保存してたと思うけど…
単純な正弦波が時間tに応じて変化してるカンジで
音波を単純に書くと、
 α(h sin t)
   h :波の高さ
   t :時間
   α:係数(時間によって変化する数式の代わり)
そのうち、74 が言ってるのは、
αとhを別々に保存した場合。
CDは、α × h を保存してるよ。
正弦波 一周期の間に、何回も波の高さを測定して保存。
再生するときには、そのてっぺんをつなげて波を再現
していくわけだね。

サンプリング周波数 = 保存したい周波数 × 2
人間の可聴域が20kHz程度だから、最低限40kHz必要になる。
余裕を持たせたりとか色々あって、高めの44.1kHzになってる。

エラー訂正なら、各セクタに持たせるだけじゃなくて、
数セクタ〜数十セクタ毎にチェック用のセクタを持たせても
いいんじゃない?

なんか、図で書いたほうが説明しやすいな…用語とか忘れたし。
自分の説明力が足りないのが一番の原因だと思うけど…

152 :仕様書無しさん:04/03/29 00:05
VB.NETだとSharedでは・・・

153 :仕様書無しさん:04/03/29 00:06
>>149
ありえない。


154 :仕様書無しさん:04/03/29 00:06
JiniとJNIの機能的な本質もろくに解っていないとはな。
でも、予想道理だ。
ますますその調子でがむばってくれたまえ。
派遣労働者諸君。

155 :仕様書無しさん:04/03/29 00:06
>>152
まるで富士通の並列処理Cコンパイラ(fcc)用のCコードみたいだな。

156 :仕様書無しさん:04/03/29 00:07
>>59
派遣以前の問題では。

157 :貧乏紙:04/03/29 00:07
シンクロだって?アホですか?
シングルスレッドモデルでしょ?
シンクロなんか使ったら遅くて使い物にならんよ。

158 :仕様書無しさん:04/03/29 00:07
>>147
それがどうしたといわれるオチ(ワラ
どこかのサイトで必死に調べたんだろ(ワラ

159 :仕様書無しさん:04/03/29 00:08
>>149
Object型があるから必要ないんじゃ・・・

160 :仕様書無しさん:04/03/29 00:08
XP自体があやしい

161 :最凶VB厨房:04/03/29 00:08
>>150
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/vblr7/html/vakeystatic.asp?frame=true
static変数っていうのはこれですね。

162 :仕様書無しさん:04/03/29 00:08
>>154
わかったふりをしているみたいだな
貧乏派遣組み込みC厨紙(w

163 :仕様書無しさん:04/03/29 00:09
電波貧乏人は早とちりが激しいなw


164 :仕様書無しさん:04/03/29 00:09
このスレ、頭デッカチばっかだね。伴ってないよ、




























年収と。

165 :仕様書無しさん:04/03/29 00:10
>>161
そのページを開いたら、真っ白な背景に青いリンクで
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
File Not Found
MSDN ????? ???? ???
?????????
??? ????
?? (??)
Embedded ??
??????????
????????????????
????????????????
.NET ??
??????????????? ????
Office ?????????
??????
???????????????
???? ???????? ?????????
Visual ??????????
Web ??
Windows ??
XML Web ????
と表示されたよ

166 :仕様書無しさん:04/03/29 00:11
>>149
まるでJavaScriptみたいだな。
あり得ない話。何のためにGenericsが導入されると思っているのか。

167 :仕様書無しさん:04/03/29 00:12
>>161
C#使ったことがあるのになぜ知らんのかと。

168 :仕様書無しさん:04/03/29 00:12
今日も元気だな。ドカタどもw

169 :仕様書無しさん:04/03/29 00:13
ドカタが話を逸らすのに必死だな

170 :仕様書無しさん:04/03/29 00:13
>>151
だから変調ってしってんの?
その様子ではフーリエ変換さえ知らないと見えるな。

171 :仕様書無しさん:04/03/29 00:13
設計者のオナニィをPGが不眠不休のドカタ仕事でフォローする。これがJavaの現実。

172 :仕様書無しさん:04/03/29 00:13
Luceneって何て読むんだ?

173 :仕様書無しさん:04/03/29 00:13
静的変数って女PGの前では口に出せないよな?

174 :貧乏紙:04/03/29 00:14
>>158
ネットで調べてねーよ。あほ。
来月の18日にソフ開受けんだよ。

175 :仕様書無しさん:04/03/29 00:14
>>170
マジで貧乏紙はフーリエ変換も知らないの?
Java厨ですら知っていることをしらないなんてアフォですねw

176 :仕様書無しさん:04/03/29 00:15
貧乏紙は学生かw

177 :仕様書無しさん:04/03/29 00:15
アセンブラ厨w

178 :仕様書無しさん:04/03/29 00:16
貧乏紙は祖父会の試験勉強を2chでやろうとしていたアフォです

179 :仕様書無しさん:04/03/29 00:17
貧乏紙は信号処理をやりすぎているようだから数値計算誤差とか
の知識が乏しそうだなw
信号処理も数値計算分野カテゴリーの一種なのにw

180 :仕様書無しさん:04/03/29 00:25
な、なんで止まったの?

181 :仕様書無しさん:04/03/29 00:25
ソフ開とっても数十万しかギャラがもらえないな。
そんなことよりも
そろそろもっと新しいネタを資格試験で勉強させようと言う気がないのかね通産省は 

182 :仕様書無しさん:04/03/29 00:26
厨房の巣窟は崩壊しますた

183 :仕様書無しさん:04/03/29 00:26
>>180
なぜか投稿できなかった。
同じプロバイダのヤシがいるのかな?

184 :仕様書無しさん:04/03/29 00:26
マルチスレッドの話題がでたので

J2SE1.5から追加される機能について解説しているサイトを紹介しておくか。

Javaの理論と実践: (若干) シンプルになった並行性
util.concurrentパッケージの紹介
http://www-6.ibm.com/jp/developerworks/java/030214/j_j-jtp1126.html

数多くの他のアプリケーション・インフラストラクチャー・サービスと同様に、
ワーク・キューやスレッド・プールなどの並行性ユーティリティー・クラスは、
どのプロジェクトでもむやみに初めから作り直すことが多いようです。今月は、
Brian Goetz氏が、広く使用されている高品質のオープン・ソースの並行性ユーティ
リティー・パッケージである、Doug Lea氏の util.concurrent パッケージについて紹介します。

私たちの大半は、プロジェクトで必要になったとしても、XMLパーサーや、テキスト検索、
検索エンジン、正規表現コンパイラー、XSLプロセッサー、あるいは、PDFジェネレーター
などのユーティリティーを、プロジェクトの一部として独自に作成することなど決して考え
ないでしょう。これらの機能が必要な場合は、市販やオープン・ソースの実装を使用して、
そうしたタスクを実行させます。もっともなことですが、既存の実装は適切に機能し、また、
簡単に利用することができ、独自のものを作成したとしても比較的利点が少ない (あるいは
まったくない) わりには、多くの作業が必要となるでしょう。ソフトウェア・エンジニアとして、
私たちは、巨人の肩の上に立つ (既存のものを活用する) というIsaac Newtonの熱意を共有
していると信じたいところですが、そう望んでいる人もいますが、いつもそうとは限りません。
(Richard Hamming氏は、Turing Awardの講義で、コンピューター科学者はむしろ「互いの足
の上に立つ (既存のものを活用しない)」ことを好むと述べています)。 

185 :仕様書無しさん:04/03/29 00:27
作り直しの理由を探る

しかし、ロギングやデータベース接続プーリング、キャッシング、タスク・スケジューリングなどの
低レベルのアプリケーション・フレームワーク・サービス (ほぼすべてのサーバー・アプリケーシ
ョンに必要) に関して、私たちは、これらの基本的なインフラストラクチャー・サービスは繰り返し
作り直すものであると考えています。これは、なぜでしょうか。既存のオプションでは適切ではな
いことや、カスタム・バージョンのほうが、手元のアプリケーションに対して、より優れている、ある
いは適していることが必ずしもその理由ではありません。実際、カスタム・バージョンは、広く利用
されている汎用の実装よりも、開発の対象としたアプリケーションに対して適さないことが多く、質
が低い場合もよくあります。たとえば、log4jは好きではないかもしれませんが、作業を適切に処理
します。さらに、自作のロギング・システムは、log4jにない特定の機能を持っているかもしれません
が、ほとんどのアプリケーションに関して、既存の汎用の実装を利用するよりも、完全なカスタム・ロ
ギング・パッケージを初めから作成する方が、それだけの価値があると言い張るのは難しいでしょう。
それにもかかわらず、多くのプロジェクト・チームは、独自のロギングや接続プーリング、あるいはスレ
ッド・スケジューリング・パッケージを繰り返し作成しています。

186 :151:04/03/29 00:27
> 170
習ったけどほとんど忘れた。
知らないものとして扱ってくれていいけど、
あんまいじめないでくれ。凹むから。

とりあえず、CDのデータの保存方法は変調を
意識しなくていいよ。
考え方は、FMみたいなのじゃなくってAMで
よかったと思う…自信なくなってきた。

> 175
オレは貧乏神とは別なんだけど…
そもそも、貧乏神って何者?

187 :仕様書無しさん:04/03/29 00:29
見た目はシンプルですが

XSLプロセッサーを自分で作成することを考えない理由の1つは、
それが膨大な量の作業となるからです。ただし、上述の低レベルのフレームワーク・サービスは
一見簡単そうに見えるので、独自のものを作成することはそれほど困難ではないように見えます。
しかし、正確に行うのは、見た目より困難です。こうした特定のサービスを毎回作り直す主な理由は、
あるアプリケーションで必要な機能が、多くの場合、初めは小さいものですが、他の無数のプロジェク
トが有する同様の問題に直面するにつれ、拡大することです。その主張は通常次のようなものです。
「完全なロギング / スケジューリング / キャッシング・パッケージは必要ありません。シンプルなもの
が必要なだけなので、それを実行するものを作成するだけです。そして、それは、特定のニーズに対
応したものになるでしょう」。しかし多くの場合、作成したシンプルな機能ではすぐに足らなくなり、機能
を次から次へと追加したくなり、最終的には完全なインフラストラクチャー・サービスを作成しています。
その時点で、通常、既に作ってしまったものがいいものであろうとなかろうと、それから離れられなくなっ
てしまっています。すでに独自のものを作成する全部のコストを支払っているので、汎用の実装へ移行
する実際の移行コストに加え、「サンク・コスト」(投下済み費用)の壁も克服しなければならないでしょう。


188 :仕様書無しさん:04/03/29 00:29


並行性ビルディング・ブロックの貴重な発見

スケジューリングと並行性のインフラストラクチャー・クラスの作成は、明らかに見た目より困難です。
Java言語は、wait()、notify()、および synchronized という有益な、低レベルの同期プリミティブのセッ
トを提供しますが、これらのプリミティブの使い方の詳細はわかりにくく、パフォーマンス、デッドロック、
公平性、リソース管理、スレッド・セーフティーに関して回避すべき障害など多くの事柄があります。
並行コードの作成は難しく、テストはさらに困難であり、専門家でさえ初めての場合は間違うことが
あります。Concurrent Programming in Java (参考文献を参照) の著者であるDoug Lea氏は、ロック
やmutex、キュー、スレッド・プール、軽量のタスク、効果的な並行コレクション、アトミック算術演算、
その他並行アプリケーションの基本的なビルディング・ブロックなどの、優れた並行性ユーティリティー
のフリー・パッケージを作成しました。このパッケージは通常 util.concurrent と呼ばれ (実際のパッケー
ジ名は長すぎるので)、Java Community Process JSR 166の下で標準化され、
JDK 1.5では java.util.concurrent パッケージの基礎となる予定です。当面は、util.concurrent は、
十分にテストされ、JBoss J2EEアプリケーション・サーバーなどの多くのサーバー・アプリケーショ
ンで使用されます。

189 :仕様書無しさん:04/03/29 00:30
すき間を埋める

mutexやセマフォー、ブロッキング、スレッド・セーフのコレクション・クラスなど、
有益な、高レベルの同期ツールのセットが、中核となるJavaクラス・ライブラリーか
ら明らかに欠落していました。synchronization、wait()、notify()といったJava言語の
並行性プリミティブは、ほとんどのサーバー・アプリケーションのニーズを満たすには
レベルが低すぎます。ロックを取得する必要がある場合、どうなるでしょうか。一定時間内
にそれを取得しないとタイムアウトになるでしょうか。スレッドが中断されたらロックの取得を
中止しますか。最大Nスレッドが保持できるロックを作成しますか。排他的書き込み付きの
並行読み取りのような、マルチモードのロッキングをサポートしますか。あるいは、1つのメ
ソッドでロックを取得し、別のメソッドでそれを解放しますか。組み込みロッキングは、これ
らをどれも直接的にはサポートしませんが、これらはすべて、Java言語が提供する基本的な
並行性プリミティブ上に構築することができます。しかし、これを作る作業にはコツがいりますし、
間違えやすいものです。

サーバー・アプリケーション開発者は、相互排除を実行し、イベントへの応答を同期化し、また、
アクティビティー間でデータを通信し、非同期でタスクのスケジュールを作成するための簡単な
機能を必要としています。Java言語がこの目的のために提供する低レベルのプリミティブは、使
用が難しく、エラーが発生しやすいものです。util.concurrent パッケージは、ロッキング、ブロッキ
ング・キュー、タスク・スケジューリングのためのクラス・セットを提供することによって、このすき間
を埋めようとしています。これらのクラスは、共通のエラー・ケースを処理したり、あるいは、タスク・キ
ューやプロセス中のワークによって消費されるリソースを制限したりする機能を提供します。

190 :仕様書無しさん:04/03/29 00:31
非同期タスクのスケジューリング

util.concurrent で最も広く使用されているのは、非同期イベントのスケジューリングを
処理するクラスです。このコラムの7月の記事では、スレッド・プールとワーク・キューにつ
いて説明し、小さな作業単位のスケジューリングを行うために「Runnable のキュー」のパター
ンが多くのJavaアプリケーションによってどのように使用されているかを説明しました。

バックグラウンド・スレッドをforkしてタスクを実行するために、タスク用に単に新しいスレッドを
作成したくなるものです。


new Thread(new Runnable() { ... } ).start();


この表記は魅力的で簡潔ですが、2つの重要な欠点があります。まず、新しいスレッドの生成には、
一定のリソース・コストがかかる上、多くのスレッド (それぞれが短いタスクを実行し、その後終了す
る) を生成すると、JVMは、実際に有用な作業を行うよりも、スレッドの生成や破棄に、より多くの作
業を行い、より多くのリソースを消費する場合があります。生成や破棄のオーバーヘッドがまったく
ないとしても、この実行パターンには、特定のタイプのタスクの実行で使用されるリソースをどのよ
うに制限できないという、さらに微妙な2つめの欠点があります。要求が突然殺到した場合に、一度
に1,000ものスレッドが生成されるのをどのように防ぎますか。現実のサーバー・アプリケーションは、
それ以上に注意深くリソースを管理する必要があり、一度に実行する非同期タスクの数を制限するこ
とが必要です。

191 :151:04/03/29 00:33
ごめん、AMも違う…か?

なんて説明すればいいかわからなくなったからROMってるよ。

192 :仕様書無しさん:04/03/29 00:33
>>186
フーリエ変換なんか簡単だから理解しろよ

この本買え
『Javaによるアルゴリズム事典』サポートページ
http://www.matsusaka-u.ac.jp/~okumura/java-algo/

Javaが嫌いならこっちを買え(10年以上前の古い本)
『C言語による最新アルゴリズム事典』
http://www.matsusaka-u.ac.jp/~okumura/algo/

193 :仕様書無しさん:04/03/29 00:34
>>191
とりあえず通信の本嫁
おまい、電気・電子・情報工学系の大学出じゃないのか?


194 :仕様書無しさん:04/03/29 00:35
>>186
ついでにウェーブレット変換も理解しろ。
これからの時代はウェーブレットだ。
フーリエ解析はもう古い

195 :仕様書無しさん:04/03/29 00:36
>>191
おまえ、MATLABというソフト使ったことがあるか?
ないなら使ってみろ。


196 :仕様書無しさん:04/03/29 00:37
スレッド・プールは、これらの問題を両方とも解決し、スケジューリング効率の向上とリソー
ス使用の制限の利点を同時に提供します。プールされたスレッドで Runnable を実行する
ワーク・キューとスレッド・プールは簡単に作成できますが (7月のコラムのコード例で作成)、
単に共有キューへのアクセスを同期化するより、効果的なタスク・スケジューラーを作成する
ためには非常に多くの作業が必要になります。現実のタスク・スケジューラーは、消滅するス
レッドを処理し、不必要にリソースを消費しないように余分にプールされたスレッドを削除し、また、
負荷に基づいてプール・サイズをダイナミックに管理し、キューに入ったタスクの数を制限しなけれ
ばなりません。キューに入ったタスクの数の制限という最後の項目は、サーバー・アプリケーション
が過負荷になった場合に、メモリー不足エラーによるクラッシュを防止するために重要です。

タスク・キューの制限には、ポリシーの決定が必要です。ワーク・キューがオーバーフローしたら、
オーバーフローをどのように処理しますか。最新のアイテムを破棄しますか。最も古いアイテムを
破棄しますか。キューでスペースが利用できるようになるまで、サブミットするスレッドをブロックし
ますか。サブミットするスレッドの新しいアイテムを実行しますか。実行可能なオーバーフロー管
理ポリシーにはさまざまなものがあり、それぞれに利害得失があります。

197 :仕様書無しさん:04/03/29 00:38
>>137
スレッドセーフではないローカル変数の例。

public void hoge() {
  final Map map = new HashMap();
  Thread t1 = new Thread() {
    public void run() {
      map の操作
    }
  }
  t1.start();
  Thread t2 = new Thread() {
    public void run() {
      map の操作
    }
  }
  t2.start();
}

198 :仕様書無しさん:04/03/29 00:38
Executor

Util.concurrent は、Runnable を非同期で実行する Executor
インターフェースを定義し、異なるスケジューリング特性を提供する
Executor のいくつかの実装も定義します。タスクを実行プログラムの
キューに入れるのは極めて簡単です。


Executor executor = new QueuedExecutor();
...
Runnable runnable = ... ;
executor.execute(runnable);

最も簡単な実装は ThreadedExecutor で、各 Runnable に新しいスレ
ッドを作成しますが、new Thread(new Runnable() {}).start() イディオム
によく似て、リソース管理を提供しません。ただし、ThreadedExecutor には、
1つの重要な利点があります。実行プログラムの構成を変更するだけで、異なる実行
モデルに移行することができ、アプリケーション・ソース全体をじっくりと見渡して、
新しいスレッドを作成するすべての場所を探す必要がありません。QueuedExecutor は、
AWTやSwingのイベント・スレッドとよく似たもので、単一のバックグラウンド・スレッドを使用して、
すべてのタスクを処理します。QueuedExecutor には、タスクがキューに入った順に実行されるとい
う優れた性質があり、それらはすべて単一のスレッド内で実行されるので、タスクは共有データへの
すべてのアクセスを必ずしも同期化する必要がありません。

199 :仕様書無しさん:04/03/29 00:39
>>197
貧乏紙はVectorクラスの欠点を知らないんだろうよ

200 :仕様書無しさん:04/03/29 00:40
PooledExecutor は、スレッド・プールの高度な実装であり、ワーカー・スレッドのプールで
タスクのスケジューリングを提供するだけでなく、柔軟なプール・サイズの調整とスレッド
のライフサイクル管理も提供します。これは、ワーク・キューのアイテムの数を制限して、
利用可能なメモリーがキューに入ったタスクによってすべての消費されてしまうことを防ぎ、
シャットダウンや飽和に関するさまざまなポリシーを適用できます (ブロック、廃棄、スロー、
最も古いものを廃棄、呼び出し側のランインなど)。すべての Executor 実装は、実行プログ
ラムのシャットダウン時にすべてのスレッドをシャットダウンするなど、スレッドの作成と取り
外しを管理し、また、アプリケーションが希望すればスレッドのインスタンス化を管理できるよう、
スレッド作成プロセスへのフックも提供します。これによって、たとえば、特定の ThreadGroup に
すべてのワーカー・スレッドを置いたり、記述名を付けることができます。

201 :仕様書無しさん:04/03/29 00:40
FutureResult

結果が後で必要となる場合に利用できるよう、プロセスを非同期で開始したいと思
うかもしれません。FutureResult ユーティリティー・クラスによってそれを簡単に行
うことができます。FutureResult は、実行に多少時間がかかり、別のスレッドで実
行できるタスクを表し、FutureResult オブジェクトは、その実行プロセスのハンドル
として機能します。FutureResult を通して、タスクが完了したかどうか調べる、完了
するのを待つ、そして、その結果を取り出すことができます。FutureResult は、Executor
と組み合わせて使うことができます。FutureResult を作成して、その参照を保持したまま、
Executor のキューに入れることができます。リスト1は、FutureResult と Executor を組み合
わせた簡単な例で、イメージのレンダリングを非同期で開始し、他の処理を続行します

202 :仕様書無しさん:04/03/29 00:42
>>191
CDは基本的にはAM見たく搬送波の上に信号の強弱をデータとして表した物でしかない。
しかし、それに時間軸が加わるので、データの最小単位は588bitのフレームで表される。
んで、そのデータはEFM(Eight to Fourteen Modulation)で変調されて、8bitの値を14bitで
表している。

言っておくが私はJava信者でも貧乏神でもない。

203 :仕様書無しさん:04/03/29 00:44
リスト1. FutureResultとExecutorの実行

Executor executor = ...
ImageRenderer renderer = ...

 FutureResult futureImage = new FutureResult();
 Runnable command = futureImage.setter(new Callable() {
  public Object call() { return renderer.render(rawImage); }
 });

 // start the rendering process
  executor.execute(command);

  // do other things while executing
  drawBorders();
  drawCaption();

 // retrieve the future result, blocking if necessary
  drawImage((Image)(futureImage.get())); // use future

204 :仕様書無しさん:04/03/29 00:45
>>202
先生、AMってなんでつか?

205 :仕様書無しさん:04/03/29 00:46
FutureResultとキャッシング

FutureResult を使用して、ロード・オンデマンドのキャッシュの並行性を改善することもできます。
計算結果自体ではなく、FutureResult をキャッシュに入れることによって、キャッシュの書き込み
ロックを保持する時間を削減できます。最初のスレッドがアイテムをキャッシュに入れる速度が速
くなるわけではありませんが、キャッシュにアクセスする他のスレッドを最初のスレッドがブロックし
てしまう時間が削減されるでしょう。また、キャッシュから FutureResult を検索して取り出せるので、
他のスレッドは、より早く結果を利用できるようになるでしょう。リスト2は、キャッシングに FutureResult
を使用する例です。

リスト2. キャッシングを向上させるためのFutureResultの使用

public class FileCache {
  private Map cache = new HashMap();
  private Executor executor = new PooledExecutor();

  public void get(final String name) {
   FutureResult result;

   synchronized(cache) {
    result = cache.get(name);
    if (result == null) {
     result = new FutureResult();
      executor.execute(result.setter(new Callable() {
      public Object call() { return loadFile(name); }
       }));
      cache.put(result);
    }
    }
   return result.get();
  }
}

206 :仕様書無しさん:04/03/29 00:47
>>204
通信の本を読め by 情報系出身Java信者

207 :仕様書無しさん:04/03/29 00:48
このアプローチによって、最初のスレッドは、同期されたブロックにすばやく入って出ることができ、
また、その他のスレッドは、最初のスレッドの計算結果を、最初のスレッドと同時に得ることができ、
2つのスレッドが同じオブジェクトを計算することはありません。


まとめ
util.concurrent パッケージには数多くの有用なクラスが含まれており、そのいくつかは、みなさんが
何度となく作成したことのあるクラスよりも優れたバージョンであることにお気付きになるでしょう。
これらのクラスは、マルチスレッド化されたアプリケーションの数多くの基本的なビルディング・ブロ
ックの、何度もテストされた、高パフォーマンスの実装です。util.concurrent は、JDK 1.5の
java.util.concurrent パッケージとなる並行性ユーティリティー・セットを作るJSR 166の出発点でした。
しかし、JSR 166がリリースされるまで待つ必要はありません。次回の記事では、util.concurrent のカ
スタム同期クラスのいくつかについて説明し、さらに、util.concurrent と java.util.concurrent APIの異な
る点について説明します。

208 :仕様書無しさん:04/03/29 00:49
>>206
了解しますた。

209 :仕様書無しさん:04/03/29 00:49
>>204
振幅変調

210 :仕様書無しさん:04/03/29 00:51
>>208
「情報通信ネットワーク」などで検索すればそれらしき本がよく出てくる。
大学で教わらなかったのか?

211 :最凶VB厨房:04/03/29 00:53
振幅の大小で01を表す伝送方法だろ?

212 :仕様書無しさん:04/03/29 00:55
信号処理ばかりやっているとオブジェクト指向などの分野の知識が
おろそかになるぞ。
大事だけどな。

きがつけばクラスなんてイラネなんて言い出すからな。

213 :仕様書無しさん:04/03/29 00:56
もはやアナログ信号なんてさっさと滅んでしまえってところだけどな。
そしたらAM,FM,PMなんて関係ねえやw
関係あるのはスピーカ、マイク周りだけだなw


214 :仕様書無しさん:04/03/29 00:57
MP3マンセーな貧乏紙がAMだの言い出す時点で終わってる。

215 :151:04/03/29 00:58
>192
>『Javaによるアルゴリズム事典』サポートページ
を探してみる。
Javaしかできないし。分厚そうだなあ。

>193
高専の電気工学科だよ。
通信で変調とかは習ったけど、CDは変調する必要あるの?
44.1kHzのサンプリング周波数で変調方式でいくと、
かなり無駄なトコの音まで保存してない?
あのディスクに入らなくなるような気がする。

>194
そんないっぺんに出来ない。
来月からまた火消しにされるし。
多分いっしょに燃え上がってると思う。

>196
ない。
トライアル版も登録が必要なのか。
会社名とか住所の登録が必要なのはあんまり好きじゃないなぁ…

216 :仕様書無しさん:04/03/29 00:58
ひょっよして貧乏紙は偉そうにしているわりには
Doug LeeやMutexやセマフォのことも知らなかったのか?


217 :仕様書無しさん:04/03/29 01:00
>>215
TeXで有名な奥村のその本は薄いし読みやすく即座に役立つぞ。 

信号処理系の研究室にいけばMATLABは簡単に手に入る。

218 :仕様書無しさん:04/03/29 01:02
技術屋が素人言語学者に叩かれる光景ってムカつくな

こんなにド頭にきたのは久しぶりだ

219 :仕様書無しさん:04/03/29 01:02
http://ja.wikipedia.org/wiki/変調方式

220 :最凶VB厨房:04/03/29 01:04
>>197のやつってローカル変数なの?

221 :仕様書無しさん:04/03/29 01:08
君たちとは永遠に話が平行線だろうからそろそろ私は消えるよ。
ついでにいっとくけど、変調って言ってもアナログ信号だけに限った話じゃないよ。
EFM変調とは誤り訂正の一種で要ははCD表面のボコボコを確実に検出するためのものだ。

222 :仕様書無しさん:04/03/29 01:08
>>218
言語学者が素人?
情報系の大学出ているヤシは技術屋だぞ。

ソフトウェア工学、ハードウェア工学、信号処理
三つをすべて習得しているんだぞ。

情報理論、電気回路、電子回路、論理学、電磁気学、物理学、ソフトウェア設計、
情報通信、計算機構成論、ハードウェア設計、アルゴリズム論、画像工学、音響工学、
デジタル信号処理、数値解析などをすべて習得する。

その中でソフトウェア設計が関与することでJavaを極めることができる。
そこからJavaを推進する気になるものもいるということだ。
Javaの話題をしているからといってなめんなよ。みくびったか。わかったか?

223 :仕様書無しさん:04/03/29 01:09
>>221
お前、今>>219を読んだだろこの貧乏紙

224 :151:04/03/29 01:10
>>202
ありがとう。
搬送波があるんだ…それで変調の話か。
なんでだろう?
ちょっと自分で調べてみる。

#今日は寝ちゃうけど。

225 :仕様書無しさん:04/03/29 01:10
>>220
内部クラスというものをよく知らないようだね。
おまいの好きなC#にあるdelegateでも代用できる機能だ。あの中にはstatic変数など無いぞ。


226 :仕様書無しさん:04/03/29 01:12
光ファイバーにデジタルテレビ、

なんでもかんでもデジタルが主流になっているというときに
もうアナログの話はやめれ。

デジタルに関することに汁

227 :仕様書無しさん:04/03/29 01:13
鈍感なくせに音にうるさいヤシに限ってアナログにこだわる

228 :仕様書無しさん:04/03/29 01:13
>>222
大学でてると即技術屋ですか。お子様?

229 :最凶VB厨房:04/03/29 01:14
匿名クラスじゃないの?

230 :仕様書無しさん:04/03/29 01:15
>>222
技術屋は「習得してる」「極める」なんて言葉使わないよ


231 :仕様書無しさん:04/03/29 01:15
まあ、君たちみたいに狭い範囲でしか仕事をしない人に何を言っても無駄だと思うけど、
所詮コンピュータって言っても入力と出力は永久になくならないし、物理的な知識も必要だと思うよ。
そうじゃないと、エンジニアリングとは無縁な職業になっちゃうよ。

まあ興味がある人はこのサイトでも見て勉強してくれたまえ。
http://webclub.kcom.ne.jp/ma/takabin/cdda.html
http://xai.jp/suzu/efm.htm

232 :仕様書無しさん:04/03/29 01:15
>>228
ん? なんだお前は高卒か?(ワラ 文系のオコチャマか?
学生の腕前によっては大学を出る前から技術屋だがw
研究室で3年間がんばったヤシは即座に技術屋だがな。
学生だからといってなめてかかると痛い目にあうぞw

233 :仕様書無しさん:04/03/29 01:16
>>230
そりゃおまいの偏見だよ。

234 :仕様書無しさん:04/03/29 01:16
>>231
そりゃどのレイヤに従事している人間にもいえることだ。
お前が知っていることだけが特別だと思っている時点でかなり痛い。

235 :仕様書無しさん:04/03/29 01:17
最近、CDの傷を鑢で削るツールが売られているらしいぞ。


236 :仕様書無しさん:04/03/29 01:17
>>232
新卒か。痛い目みてきなはれ。

237 :仕様書無しさん:04/03/29 01:18
>>233
判断はスレ読者に委ねろよ大口野郎

238 :仕様書無しさん:04/03/29 01:18
どうせならDVDの話題のほうに興味があったな。
これからの時代、CDよりもDVDだろ

239 :仕様書無しさん:04/03/29 01:19
>>236
調子に乗りすぎだお前は。
視野が狭く見くびりすぎだな。


240 :仕様書無しさん:04/03/29 01:20
>>233
まともな研究をしたことがある人間なら、理解が深まるほどゴールが遠くなる感覚くらい
知っていて当然なはずだが。神を自称するのはほぼ間違いなく井の中の蛙だよ。

241 :仕様書無しさん:04/03/29 01:20
>>237
人のこといえるかこの大口野郎

242 :151:04/03/29 01:22
あれ?搬送波は誤り訂正用?
音の保存自体が目的なワケじゃない?
余計分からなくなってきた…。

色々聞いてる中悪いけど、今度こそ寝よう。
これ以上考えてると、眠れなくなりそうだ。
スレが生きてたら、明日返事するよ。

>217
研究室に知り合いがいない…。
母校は離れすぎてて、気軽に行けない。

>220
このコードだとインスタンス変数だね。
final も関係ないし。
public hogeMethod() {
 Map map = this.hogeMap;
 mapに操作。
}
みたいに、変数がローカルでも、操作対象が
それ以外から来たインスタンスだと安全じゃない
こともあるってことを言いたいんじゃない?

243 :仕様書無しさん:04/03/29 01:22
久し振りに自称「真理を理解するもの」タイプのお子様が釣れたようです。
春休みならではのイベントです。みなさんからかいましょう。

244 :仕様書無しさん:04/03/29 01:22
>>240
だれが神を自称しているんだろうか。お前の妄想か。
甘く見るのもいい加減にな。

245 :仕様書無しさん:04/03/29 01:24
>>242
> これ以上考えてると、眠れなくなりそうだ。
> スレが生きてたら、明日返事するよ。
こんな煽りスレを毎日読んでいるよりも本を読んだほうが早い。


> >217
> 研究室に知り合いがいない…。
> 母校は離れすぎてて、気軽に行けない。
どうにかして知り合いを作れ。ほかの研究室や大学などともコネを作れ。
積極的に話をしろ。自分のやりたいことをアピールくらい汁。

246 :仕様書無しさん:04/03/29 01:25
>>243
逆にからかわれてるんじゃないのかw

247 :151:04/03/29 01:25
>242
あ、内部クラスか…
墓穴堀まくり。
ねる!

248 :仕様書無しさん:04/03/29 01:26
>>242
> あれ?搬送波は誤り訂正用?
> 音の保存自体が目的なワケじゃない?
> 余計分からなくなってきた…。
>
> 色々聞いてる中悪いけど、今度こそ寝よう。
> これ以上考えてると、眠れなくなりそうだ。
> スレが生きてたら、明日返事するよ。
>
> >217
> 研究室に知り合いがいない…。
> 母校は離れすぎてて、気軽に行けない。
>
> >220
> このコードだとインスタンス変数だね。
インスタンス変数でもありローカル変数でもあるっていうこと。
貧乏紙はそれを理解していなかったらしい。

249 :仕様書無しさん:04/03/29 01:27
>>243
自分がからかわれたたかれる側からからかう側に回りたくて必死だなw

250 :仕様書無しさん:04/03/29 01:29
MATLABの代わりにMathematicaとかもあるがな。

Ezcelをつかってもいいがなw
効率が悪すぎだw

251 :仕様書無しさん:04/03/29 01:31
>>244
私にとって甘く見られない程度の人間なら、こんなところでこんな時間に
煽りにいちいち反応して書き込みしませんよ。お互い様ですが。

252 :仕様書無しさん:04/03/29 01:31
ジサクジエン開始

253 :仕様書無しさん:04/03/29 01:32
>お互い様
よくわかってるじゃねえか



254 :仕様書無しさん:04/03/29 01:32
>>252
そして即座に終了。
おまえのスキルでは自作自演は不可能。

255 :仕様書無しさん:04/03/29 01:39
Javaは木之本 桜さんには劣る。
よって負け組み

256 :仕様書無しさん:04/03/29 01:40
>>59
仕様の確定が先延ばしになってる時点で終わってる

257 :仕様書無しさん:04/03/29 01:45
ジサクジエンスキル…

258 :仕様書無しさん:04/03/29 01:46
そんな能力イラネ

259 :仕様書無しさん:04/03/29 01:46
ジサクジエン継続中?


260 :仕様書無しさん:04/03/29 01:46
>>256
XPに対する誤解があるのでは?

261 :仕様書無しさん:04/03/29 02:06
きっと信号処理の人はネットによる音楽配信によってCDメディアが
無くなることを恐れているんだろう。
そこでJavaですよ。

262 :仕様書無しさん:04/03/29 12:17
だいぶ無理があるな

263 :仕様書無しさん:04/03/29 12:25
>>261
アフォですか。
Javaで信号処理できないと勘違いしていませんか?
DSPマンセーなC厨どもは速度のことしか考えいないだけですよ。
Cで作った方が安い速い、それだけが売りですからね彼らは。
DSPという限られた箱の中で必死に汗んぶらっているんですよ。
彼らはJavaのようにヒープ領域で大量にメモリを食う言語を
信号処理に使うことが信じられないと言い張っているのですよ。
DSP専用のメモリは16MBでも1万えんとかするトンデモも有りますからね。
C厨はメモリを気にせずに高級言語プログラミングをしている香具師が許せないそうですw




264 :仕様書無しさん:04/03/29 12:58
最近のjava人気についてってタイトルにしなくてもつれますか?


265 :仕様書無しさん:04/03/29 13:26
今日もドカタが大暴れ

266 :仕様書無しさん:04/03/29 13:27
いつガベコレが入るかわからんものをリアルタイムに使おうって時点でキチガイ

267 :仕様書無しさん:04/03/29 13:45
何故、Java案件っていつもデスマなの?水曜まで眠れない人とかいるんだけど。

268 :仕様書無しさん:04/03/29 13:50
天才的言語を使っているから

269 :仕様書無しさん:04/03/29 14:35
戦略の失敗を戦術で挽回しようとしているから。
上流工程担当がJavaとJavaScriptの違いを理解していなかったりするしー

270 :仕様書無しさん:04/03/29 14:40
COBOLerとVBerが流入しているから

271 :仕様書無しさん:04/03/29 14:54
>>267
それは結局無駄な工数ばかり掛かるけど、頭を使わない力仕事で乗り切れるという意味だよ。
Javaコーダーに脳みそなんて不要。
安い馬鹿をかき集めて後は野となれ山となれ。

272 :仕様書無しさん:04/03/29 14:59
Javaの現実そのものだな。
Javaは普及した。でも馬鹿がJavaを使い過ぎている。
理想とは程遠い。

273 :仕様書無しさん:04/03/29 15:42
脈々と受け継がれてきたドカタPG御用達の血。
それを継ぐものこそJavaである!!

274 :仕様書無しさん:04/03/29 15:43
ちと質問なんだけど
1.servletで更新系処理と表示系処理を分けるのと、
2.servlet内で入力処理用のクラスインスタンス、表示用のクラスインスタンスを使い分けるのと
どちらがいいのかな??
補足として、1の場合は更新系処理の中に表示用の条件等がはいっていません。
1でやると入力と表示が完全に分かれて、いい感じがするような…
実際のプロジェクトだと2ばっかりなんだよなぁ〜
でもセッションの使い回しとかあるから微妙かな??

275 :仕様書無しさん:04/03/29 15:50
ドカタは難しいことを考えなくてもよろし

276 :仕様書無しさん:04/03/29 15:54
1クラスのソースファイルで5000行なんてのが当たり前のように現場にはありますが。何か?

277 :274:04/03/29 15:54
マ板で聞いたのが悪かったみたいだね。
ム板復活したみたいだし…

278 :仕様書無しさん:04/03/29 15:57
ここはそういうスレではありません

279 :最凶VB厨房:04/03/29 18:46
ここはどういうスレですか?

280 :151:04/03/29 19:48
帰りにある本屋をいくつか見たけどなかった。
やっぱ大きいトコに行かないと無理か。
今日は学生時の教科書でも眺めるか。

>245
まぁ、オススメの本とか教えてもらえたから。

>250
そんないっぺんにいわれたら分からんがなヽ(`Д´)ノ

#スレの流れからそれてるから、スルーしてくれ。

281 :仕様書無しさん:04/03/29 20:05
>>274
> 2.servlet内で入力処理用のクラスインスタンス、表示用のクラスインスタンスを使い分けるのと
オレはこっち。
#更新/表示の操作をservletとは別のクラスに分けてて、
#どっちを呼び出すかを変えるって意味でいいよな?
ただし、servlet内でのインスタンスの使い分けはifやswitchじゃなくて、
propertiesとかxmlにクラス名書いたのをインスタンス化して共通の操作で呼
び出すようにする。
画面毎に更新/表示用のservletを一つずつ作るってのは却下で。
システム全体で、更新時のリクエストを処理するservletと
表示時のリクエストを処理するservletの2つに分けるくらいなら
やる意味はありそう。

ただ、この辺のことをやってもフレームワークの再開発になるだけな気がする。

282 :仕様書無しさん:04/03/29 22:56
全スレあっというまに落ちたね。読みたかったのに...

283 :仕様書無しさん:04/03/29 23:02

だからさ、Webアプリイラネ
HTTPサーバー逝ってよし、なんだってばっ!!

てな声へのjava厨の明確な返答ってのがまだなわけよ。
ぜひ聞かせて欲しいんだが。


284 :Java厨:04/03/29 23:07
>>283
同意。Servlet/JSPでHTMLソースをクライアントGUI代わりに使うシステム
は、50%以上がイッテヨシだと思います。あれは低能作業員プロジェクト用のテ
ヌキ道具。

リッチクライアントが要件なのに開発側の都合でコレを採用して、お客にむか
つかせている低能プロジェクトが吐いて捨てるほどある。

今ごろ騒いでいる経営層がいるが、おまえらどうせ初めから気がついていて
確信犯だったんだろ?この詐欺師が!と思うね。

285 :仕様書無しさん:04/03/29 23:18
>>271
> >>267
> それは結局無駄な工数ばかり掛かるけど、頭を使わない力仕事で乗り切れるという意味だよ。
> Javaコーダーに脳みそなんて不要。
> 安い馬鹿をかき集めて後は野となれ山となれ。

>>267の言っていることをよく理解せずに話の流れを理解せずに
何いい加減なこといってるんだ?

Javaアーキテクトには数多くのノウハウが蓄積された大脳は必要不可欠なものだぞ。
そりゃJavaに使い慣れない馬鹿はいるだろうさ。しかしすべてのJavaプログラマをそのように
侮辱することはないだろ?


286 :仕様書無しさん:04/03/29 23:23
>>272
> Javaの現実そのものだな。
> Javaは普及した。でも馬鹿がJavaを使い過ぎている。
おやおや、そんなマイナス思考では折角のチャンスがますます逃げてゆくぞよ。
プラス思考で考えよ。馬鹿がJavaを使い過ぎているというが実際そうでもない利点がある。

Javaが普及すればするほどオブジェクト指向と新型ソフトウェア開発手法が普及する。
Javaはオブジェクト指向分析、新型ソフトウェア啓蒙するのに絶大な効果を発揮する。

おぬしもJavaを勉強しおぬしに不足したオブジェクト指向を勉強し
おぬしに足りない最新ソフトウェア開発手法を勉強してみることをお勧めする。



287 :仕様書無しさん:04/03/29 23:24
>>273
> 脈々と受け継がれてきたドカタPG御用達の血。
> それを継ぐものこそJavaである!!

残念。それは真実ではない。

これが現実解

脈々と受け継がれてきたドカタPG御用達の血。
それを継ぐものこそC言語である!!


そしてこれはますます現実解から離れることができないケースであーる。

脈々と受け継がれてきたドカタPG御用達の血。
それを継ぐものこそVB言語である!!


288 :仕様書無しさん:04/03/29 23:26
ほら話がまたスリ変ってる

289 :仕様書無しさん:04/03/29 23:28
>>274
> ちと質問なんだけど
> 1.servletで更新系処理と表示系処理を分けるのと、
> 2.servlet内で入力処理用のクラスインスタンス、表示用のクラスインスタンスを使い分けるのと
> どちらがいいのかな??
> 補足として、1の場合は更新系処理の中に表示用の条件等がはいっていません。
> 1でやると入力と表示が完全に分かれて、いい感じがするような…
> 実際のプロジェクトだと2ばっかりなんだよなぁ〜
> でもセッションの使い回しとかあるから微妙かな??

JSPと併用せずすべてServletでやるつもりか?

includeは知っているか? includeで分割くらいせよ。

そもそもクラスインスタンスとは何のクラスインスタンスなのか?
そのクラス自身はServletなのか? それともただのユーティリティクラスなのか?
それをはっきりせよ。

290 :仕様書無しさん:04/03/29 23:28
>>288
何がすり替わってるって?
そうかチミの脳内ですりかわっていることになっているんだ。


291 :仕様書無しさん:04/03/29 23:30
>>276
> 1クラスのソースファイルで5000行なんてのが当たり前のように現場にはありますが。何か?
それははっきりいって効率が悪い。

オブジェクト指向言語を使いこなしているならば、「分割し、統治せよ!」という原則は極力守るべきだ。

少なくとも Facadeパターンなどを使えるならば使って整理整頓すべきだ。


292 :仕様書無しさん:04/03/29 23:31
>>280
音波のことをよく知りたければ音響工学の本や
音声信号処理の本でも嫁。図書館に腐るほどある。

293 :仕様書無しさん:04/03/29 23:32
>>277
> マ板で聞いたのが悪かったみたいだね。
悪い? そんなことはない。
マ板で聞いて何が悪い? マ板で聞いてどこが悪い?

294 :仕様書無しさん:04/03/29 23:32
>>278
何をいうか。ここはそういうスレだ

295 :仕様書無しさん:04/03/29 23:33
VBが最強ドカタ言語だね。あれはほんとに良くも悪くもお手軽すぎ。
「スケーラビリティが要らないなら」VB+Accessで安く上げるのは
今でも大いにありだとおもうけど。

「スケーラビリティが要らない」要件ではないのに、この仕組みを
適用している、つうか他のやり方知らない馬鹿もいるけどさ。

296 :仕様書無しさん:04/03/29 23:33
VB厨=お絵描き好き

297 :仕様書無しさん:04/03/29 23:34
だからさ、Webアプリイラネ
HTTPサーバー逝ってよし、なんだってばっ!!

てな声へのjava厨の明確な返答ってのがまだなわけよ。
ぜひ聞かせて欲しいんだが。


298 :仕様書無しさん:04/03/29 23:34
>>280
MATLAB, MathematicaのほかにSASというのもある。

ほかは、Fortran。

C言語でもJavaでもいいが。

Javaであるならば Java Sound API, JMF(Java Media Framework API)を使うことをお勧めする。

299 :仕様書無しさん:04/03/29 23:35
>>297
このような無礼なコピペ厨には返答してやる義理もない!

300 :仕様書無しさん:04/03/29 23:36
だから答えろよ。話をスリ変えないで。

301 :仕様書無しさん:04/03/29 23:39
>>295
> VBが最強ドカタ言語だね。あれはほんとに良くも悪くもお手軽すぎ。
> 「スケーラビリティが要らないなら」VB+Accessで安く上げるのは
> 今でも大いにありだとおもうけど。
>
> 「スケーラビリティが要らない」要件ではないのに、この仕組みを
> 適用している、つうか他のやり方知らない馬鹿もいるけどさ。


それならば、「スケーラビリティ」を要求するプロジェクトで
スケーラビリティのことを解っていない者といえばVB厨のほかにもC厨、
COBOL厨(オブジェクト指向を使いこなしたCOBOLerを除く)などがあげられる。

302 :仕様書無しさん:04/03/29 23:40
>>300
いまときチミみたいな化石的思考を持つ人はほとんどいないから
答えは自分で検索してみなよ。

303 :仕様書無しさん:04/03/29 23:42
>>302
結局、答えられないわけね(w

結論
Webアプリ、HTTPサーバーを否定されたら
javaは用なし、役立たず

でOK?



304 :仕様書無しさん:04/03/29 23:42
>>284
> >>283
> 同意。Servlet/JSPでHTMLソースをクライアントGUI代わりに使うシステム
> は、50%以上がイッテヨシだと思います。あれは低能作業員プロジェクト用のテ
> ヌキ道具。

おぬし、GUIをバリバリつかうJavaWebStartというGUIアプリケーションは
HTMLを一切使わないWebアプリケーションでも有るわけだが
それでもGUI兼Webアプリを否定するつもりか?

それともJavaWebStartを否定する輩であろうか?

305 :仕様書無しさん:04/03/29 23:45
だからさ、そこらへんの優位性を語ってくれよ。
いまいち、非Web系のjavaってのに猜疑的なのだが、
実際はどう?


306 :仕様書無しさん:04/03/29 23:45
>>303
オコチャマ臭いが
>>284の発言に興味があったので
それに関することだけ答えてやろう。

チミに恥をかかせて悪いが、
チミはServletなどのWebアプリがHTTPサーバを使わなければ動かないもの
だと勘違いしているようだね。

ServletはHTTPなどという独自のプロトコルなどに頼らずとも動く。
それを理解してから発言した方がチミのためにもいいんじゃないのか。


307 :仕様書無しさん:04/03/29 23:46
>>304
JWSでもFlashでもSVG+XFormsでもいいよ。
それらは「HTMLベースの貧相で不便なクライアント」問題に対する
答えですから。

308 :仕様書無しさん:04/03/29 23:50
 インターネットのWebサービスが広く普及し、各クライアントがWebブラウザを標準的に備えるようになったことから、
従来は独自インターフェイスなどを使っていたクライアント・サーバ・システムにおいて、両者のインターフェイスを
HTTP/HTMLに準拠させ、特定のクライアント・プラットフォームに依存することなく、サーバ・サービスを利用可能にする動きが急速に広がってきた。
たとえばそれ以前のクライアント・サーバ・システムでは、サーバとのやり取りを行う専用のフロントエンド・アプリケーションなどを利用し、
両者が専用プロトコルで結ばれていた。この方法では、さまざまなサーバ・サービスごとにフロントエンド・アプリケーションを用意する必要などがあり効率が悪かった。

 これに対しWebアプリケーションでは、サーバ・クライアント間でのデータのやり取りを標準プロトコルであるHTTP/HTMLに準拠させることで、
Webブラウザを備える環境なら、だれでもサーバ・サービスにアクセスできるようになる。


309 :仕様書無しさん:04/03/29 23:52
>>306
まあ、本人の意図は「HttpServletイッテヨシ」という話なんだろうと思うが。

別に通信速度が必要充分なら、プロトコルなんかなんでもいいとおもうけどねー。
もしかして、原作者はCORBAマンセー野郎?

310 :仕様書無しさん:04/03/29 23:53
>>274
Jakarta Struts,
http://www.jajakarta.org/struts/,
Jakarta Turbine
http://www.jajakarta.org/turbine/
を使ったことはあるか?

311 :仕様書無しさん:04/03/29 23:54
>>309
CORBAの替わりにJava RMIマンセーだったら?
ありうるだろ




312 :仕様書無しさん:04/03/29 23:56
>>308が見事に>>303を論破した。

>>303はXMLとか知らないのかな。

こんなインターネットが当たり前の世界だというのに
彼はCD-ROMで配布するような形態のスタンドアロンアプリしか作れないのかな。



313 :仕様書無しさん:04/03/29 23:56
>>297
> だからさ、Webアプリイラネ
> HTTPサーバー逝ってよし、なんだってばっ!!

> てな声へのjava厨の明確な返答ってのがまだなわけよ。
> ぜひ聞かせて欲しいんだが。


流行っているからだよ?
悪い?

314 :仕様書無しさん:04/03/29 23:57
>>303が見事に恥をカイター(・∀・)

315 :仕様書無しさん:04/03/29 23:58
>>303==>>313

自作自演に必死な>>303(ワラ


316 :仕様書無しさん:04/03/29 23:58
だからHTTPサーバー逝ってよし、って逝っておろう?
どうすんだよ、おいっ


317 :仕様書無しさん:04/03/29 23:58
>>307
JavaWebStartはHTMLベースではありません。

318 :仕様書無しさん:04/03/29 23:59
>>308 はコピペっぽいんだが

319 :仕様書無しさん:04/03/29 23:59
>>316
池沼ですか?

320 :仕様書無しさん:04/03/29 23:59
>>318
>>303に対する的確な返答として合致している。
それでも>>316は餓鬼みたいにグダグダいっておるようだ。

321 :仕様書無しさん:04/03/30 00:00
言い方変えるぞ。
javaってのは>>308の前提に立っている。
で、>>308は本当か?

HTTP/HTMLの世っていつまでつづくのよ(w


322 :仕様書無しさん:04/03/30 00:01
まず最初にServlet + JSPベースで作り次にGUIでJavaWebStart対応アプリを作る。
これが通。


323 :仕様書無しさん:04/03/30 00:03
>>321
次世代標準候補はSVG+XFormsだと思う。基本的にはテキストベースを
通信プロトコルにすることに変わりないよ。

324 :仕様書無しさん:04/03/30 00:05
>>321
確かにその部分では>>308の説明では不十分だな。
しかしお前の言いたいことに対する返答としては十分なはずだ。
くだらん揚げ足ばかりとってないでもっと素直に現実をうけとめたらどうだ?

それとだ、お前は
Servletの仕組みを理解していないようだな。

HTTPからの鞍替えなど朝飯前。
HTMLの替わりという位置づけはないがXMLというものがあるんだろうが。
いっておくがXMLはHTMLの拡張ではないぞ。



325 :仕様書無しさん:04/03/30 00:07
>>323
それってバベルの塔っぽくないか?
デバイスがみんな「お話」すんのか?

326 :仕様書無しさん:04/03/30 00:08
>>325
クライアントにパーサが搭載されるまでの辛抱さ〜

327 :仕様書無しさん:04/03/30 00:10
javaってのは壮大だね〜(wつーのはオチにしか読めんぞ。

328 :仕様書無しさん:04/03/30 00:12
>>327
頑張るのはJavaじゃないよ。W3Cの標準化団体と、Webクライアントに実装を
差し込むベンダの人たち。

329 :仕様書無しさん:04/03/30 00:14
でもどうなのよ?
携帯電話までは良しとしよう。
問題はそこから先だと思うんだがなぁ、実際。
そういう壮大な構想ってのはコストをペイできるのかと。

330 :仕様書無しさん:04/03/30 00:15
>>325
最近のデバイスはみんなHTTP対応しているのが多いぞ。
プリントサーバ、ハードディスクレコーダ、ルータ、家電製品など、
みんな内部にWebサーバを搭載しているぞ。


331 :仕様書無しさん:04/03/30 00:16
>>329
誰かがやるさ。技術の進歩=ビジネスチャンスと考える(金あまってる暇な)人は大勢
いるさ。ゲイツさんとか。

332 :仕様書無しさん:04/03/30 00:16
>>303は、
TCP/IPでやり取りするクラサバを
最近覚えたC++厨房

333 :仕様書無しさん:04/03/30 00:17
>>328
今、SunはWebServicesでW3Cに大きく関わっているぞ。
IBMとM$は脱退してしまったが。Sunが日立、富士通など5社と協力して
WS-Reliabilityで標準化を目指そうとしている。その中でSunがリーダーになっているらしい。

334 :仕様書無しさん:04/03/30 00:17
>>330
嘘付けゴラァ HTTP鯖積んだアイロンなんかあるわけない。

335 :仕様書無しさん:04/03/30 00:18
>>326
何を言っているんだ?
Javaで稼働するApache Cocoonサーバー, 横浜ベイキットサーバーがあるだろう。
これでクライアント側でXMLパーサが用意できないという心配はない。




336 :仕様書無しさん:04/03/30 00:19
>>334
そのうち積むかもしれないところが面白い。
Web鯖化したアイロンで何をするのかは不明だけど。

337 :仕様書無しさん:04/03/30 00:19
>>334
HTTPサーバ積んだ電子レンジや冷蔵庫なら有ったかなw

338 :仕様書無しさん:04/03/30 00:19
うむ、結構面白いな

339 :仕様書無しさん:04/03/30 00:20
>>334
そもそもなんでアイロンに電子回路なんか入れる必要があるの?


340 :仕様書無しさん:04/03/30 00:20
>>335
ごめん、パーサっつったけどエンジンまで含めての話。

341 :仕様書無しさん:04/03/30 00:20
>>336
クリックするだけ良いなら楽だな〜

342 :仕様書無しさん:04/03/30 00:20
>>332
いや、奴はC++の++も理解できないC厨房。

343 :仕様書無しさん:04/03/30 00:21
自動掃除機があるぐらいだから
自動アイロンがでてもおかしくない。


344 :仕様書無しさん:04/03/30 00:21
>>339
リモートのWebクライアントから電源の消し忘れチェックする仕組みなんか、
誰か作るかもよ。IPv6万歳。

345 :仕様書無しさん:04/03/30 00:22
>>334
アイロンにそんなもんいれてどうする気か?

スキャナ機能付きアイロンでも作る気か?
アイロンをかけながら洋服の模様を無線LANでスキャンするつもりか?

346 :仕様書無しさん:04/03/30 00:22
>>342 奴って俺だろ?インクリがどうかしたのか?

347 :仕様書無しさん:04/03/30 00:22
>>343
アイロンの何を自動化するんだ?
クリーニング屋が使うアイロンの改良か?

348 :仕様書無しさん:04/03/30 00:23
>>344
くだらねえ

349 :仕様書無しさん:04/03/30 00:24
>>348
アイロンだけならくだらないけどな。
ホームオートメーションでALLリモート管理可能っていうのは、誰かヤッテルと思うよ。
そのプロジェクトの一部としてそういう発想があってもおかしいことではない。
優先度は低いだろうケド。

350 :仕様書無しさん:04/03/30 00:24
>>344
そんなくだらない用途に使うんだったら洋服のしわの取れ具合や
温度、湿度、洋服の汚れセンサ、汚れの原因になる物質センサ
などを搭載したほうがまし。

351 :仕様書無しさん:04/03/30 00:24
アイロンがけの自動化だよ。
汚れ物をつっこむと洗濯して乾かして糊付けアイロンがけして出てくる。


352 :仕様書無しさん:04/03/30 00:28
>>344
そんなやり方しなくても原始的なバイメタルがあるから十分だろ。
石油ヒーターにしても3時間で自動的に消えるので電源の遠隔管理は不要。
どうせなら灯油残量やヒーターの自動整備点検機能や自律コンピューティング機能の搭載や
ヒーターのステータスを分析しデータ化してPCに転送した方がまし。

それと、その程度の電源の消し忘れはアイロン部分ではやらず
延長コードやテーブルタップなどに取り付けるもんだろ。
機能を取り付ける必要がある部分がおかしいんだよ


353 :仕様書無しさん:04/03/30 00:30
>>351
それにはロボット工学の技術が必要だな。
ソフトウェアやネットワーキング以前の問題

354 :仕様書無しさん:04/03/30 00:31
USB接続できるインターネット対応電子レンジなんてくだらないのがあったなそういえば。
Sharpが出してたやつ。
レシピをダウンロードできるだけかYO!

355 :仕様書無しさん:04/03/30 00:33
つーわけで話がそれたんで元に戻すと

javaの行く末つーか前提となる
HTTP/HTML鯖とそれに続くテキストベースの通信プロトコルで
PCはおろか家電が全部HTTP/HTML鯖(パーサ/エンジン)積む、世に満ち溢れる
なんつー話は現時点で「自動アイロン」並みに実現性と現実感のない話である

ここまではよかろー?

356 :仕様書無しさん:04/03/30 00:37
で、だ。

漏れが思うにjavaといえど完成された最終形ではないわけだ。
だから、java、javaと騒がずに、冷静に「現時点での優位点」を
分析して、使うべきところに使うのがよい。
と思うわけだ。煽られてフル転換しちまうと取り返しがつかないと。


357 :仕様書無しさん:04/03/30 00:37
>>303はWebDAVをしらないんだろ
未だにFTPだけで十分と勘違いしているんだろうな。
セキュリティのこともろくに知らずに


358 :仕様書無しさん:04/03/30 00:39
だから>>303は漏れだっての。

359 :仕様書無しさん:04/03/30 00:39
>>355
ユビキタス社会だしね、どうだろ。
P2Pも並行して普及すると思うけど。

HTTPに取って代わる次世代プロトコル、なんだっけ?

360 :仕様書無しさん:04/03/30 00:41
>>355
そもそも藻前がアイロンなんて自分につごうのいい例だけ出すことがおかしい。


携帯電話、カーナビなどはどうだっつの

361 :仕様書無しさん:04/03/30 00:42
>>359
それこそセキュリティの問題でさ、
漏れはいくとこまでいけば
異種間接続って逆に廃れるつーか
制限されるような気がしてるけどどうよ?


362 :仕様書無しさん:04/03/30 00:42
>>355
いい加減HTMLとかいうのやめれ。
いまどきHTMLに限定したWebなんて少ないぞ

363 :仕様書無しさん:04/03/30 00:43
あ、セキュリティと知的所有権な。

364 :仕様書無しさん:04/03/30 00:44
>>362 表記は>>308に習っただけだよん。

365 :仕様書無しさん:04/03/30 00:44
>>361
暗号化技術が廃れさせない。

異種間接続、それこそJavaの出番。Jiniだ
セキュアな言語だけある

366 :仕様書無しさん:04/03/30 00:46
>>363
Winny問題なんてきりがない。

廃れる替わりに恐ろしい監視システムが導入されると見る。

プライバシーは完全に侵害される社会も考えられる。

367 :仕様書無しさん:04/03/30 00:47
>>365
そこだよな、やっぱ論点は。で>>303の問いに戻るのな。
異種間接続の必要性ってそんなにほんとにあるのか?ってとこな。


368 :仕様書無しさん:04/03/30 00:48
.net passport vs Liberty Aliance Project



369 :仕様書無しさん:04/03/30 00:49
XPに騙されて、仕様確定が遅れに遅れ設計が押し、結局は
オブジェクト指向とは程遠い、コピペコピペのクラスだらけ。
おまえら、スーパークラスって知ってるか?と言いたくなるような
5000行のクラスがゴロゴロ。これがJavaの現実ですよ。

370 :仕様書無しさん:04/03/30 00:49
>>367
便利で夢のある話じゃんか

371 :仕様書無しさん:04/03/30 00:49
アイロンをネタにこんなに話を盛り上げる
java厨マンセー(w

372 :仕様書無しさん:04/03/30 00:50
>>369
それだったら Cやcobolはもっとひどい。

373 :仕様書無しさん:04/03/30 00:50
>>367
サイバーパンクを恐れてるのか

374 :仕様書無しさん:04/03/30 00:50
>>372
んなこたない

375 :仕様書無しさん:04/03/30 00:51
>>374
Cはばっふぁおーばふろーがひどいし

376 :仕様書無しさん:04/03/30 00:53
>>374
ないわけがない。
そもそもオブジェクト指向でないし、スーパークラスなんてないんだから。

377 :仕様書無しさん:04/03/30 00:57
いずれにしてもIPv6によってIPアドレスは有り余っている。
そのとき安全かつ便利なHTTPが使われる。
プリントサーバにWebサーバを内蔵することで
ブラウザ経由でプリントサーバの設定ができるということは便利だろう。

ルータににWebサーバを内蔵することで
ブラウザ経由でルータの設定が変更できるということは
ipchainやiptablesのインストール、設定の仕方が解らない初心者にとっては便利だろう。

378 :仕様書無しさん:04/03/30 00:57
仕様があいまいなまま突っ走って、オブジェクト指向が通用すると思ってるのかね。
当初の設計ではあるクラスからの派生してたクラス群が、想定外の仕様変更で
その関係が崩れたりしたら、波及する範囲が大きいのだよ。

379 :仕様書無しさん:04/03/30 00:59
仕様が曖昧なまま突っ走るようなケースでは、オブジェクト指向はかなり困難。

380 :仕様書無しさん:04/03/30 01:00
本当に成功するのか。Xpはw


381 :仕様書無しさん:04/03/30 01:01
>>367
> 異種間接続の必要性ってそんなにほんとにあるのか?ってとこな。
あるっ!(きっぱり)

そのためにケーブルはUSB, IEEE1394などに統一されようとした。




382 :仕様書無しさん:04/03/30 01:01
先輩!仕変です。基底クラスから作り変えなければいけません。。。。

383 :仕様書無しさん:04/03/30 01:02
>>378
それはおまいがオブジェクト指向の正しい使い方を理解してないだけ。

384 :仕様書無しさん:04/03/30 01:03
>>382
数多くのデザインパターンを習得せよ。
さすればそのような」愚かな問題に突き当たることはなくなる。

385 :仕様書無しさん:04/03/30 01:03
>>380
ならばRational Unified Processを使え

386 :仕様書無しさん:04/03/30 01:04
納期は切られているのに割り込んでくるのが仕変なのさ。

387 :仕様書無しさん:04/03/30 01:05
>>378
それにはどのよなデザインパターンを参考にしたのか?
Abstract Factoryパターンであるか?
このパターンの欠点は知っておるな?
対策法も。

388 :仕様書無しさん:04/03/30 01:09
>>378
継承だけがオブジェクト指向だと思ったら大間違いだ。
委譲、集約もうまく組み合わせて初めてオブジェクト指向という。


お前には、喝ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー!!!!!!!

389 :仕様書無しさん:04/03/30 01:10
設計時に仕様確定できてれば問題ないんだけどねぇ。
XPってなんか間違ってない?

390 :仕様書無しさん:04/03/30 01:13
間違ってない。悪いのはお前の頭だ。
JavaもXPも悪くない。

391 :仕様書無しさん:04/03/30 01:18
つか順番が逆だろ。
仕様確定できないから、XPのような手法が考えられた。

最初からかっちり決まってるなら、をたふぉーるでよい。

392 :仕様書無しさん:04/03/30 01:19
仕様確定せずに設計できますか?

393 :仕様書無しさん:04/03/30 01:19
>>392
出来る。XPは銀の弾丸だ。撃てないお前の頭が悪い。

394 :仕様書無しさん:04/03/30 01:21
ドカタに徹夜させて全部作り直させるから無問題。

395 :仕様書無しさん:04/03/30 04:37
.Net is not Java

フリーなJava実装.NJの世界へようこそ。
糞ナJavaなんかもういらない。100%上位互換。



396 :仕様書無しさん:04/03/30 08:12
パソコンスペックが高くなってきてる現状、集中処理のWebアプリに拘る
必要ないような気がする。CD-ROM配布でスタンドアロンアプリ配布は
ダサイけど、サーバーにアプリ置いてダウンロードさせるようにしたうえで
クライアントのリソースも使うようなC/SとWebアプリの中間のような
アプリケーションが今求められてるんじゃないか?これからは負荷分散だよ。
サーバーのクラスタリングだけじゃ限界なんだよ。みんなで処理しようぜ。

397 :仕様書無しさん:04/03/30 08:47
ここを見て思ったこと。
Javaなんて所詮テレビの中身は知らないけれど使い方は知ってますって感じの言語だな。
実にくだらん。

398 :仕様書無しさん:04/03/30 08:58
.netってフリーだよな。
すっかり忘れてたw

399 :仕様書無しさん:04/03/30 10:23
負け犬Javaの最近の案件はどうよ?

400 :仕様書無しさん:04/03/30 10:30
今日、明日は火の車れす

401 :仕様書無しさん:04/03/30 11:26
こちらの.NET案件はとっとと納品。
総合テストも安定稼動で開発者はまったりと.NET2.0のお勉強中。

402 :仕様書無しさん:04/03/30 12:55
PHPでさくっと

403 :仕様書無しさん:04/03/30 12:59
>>393
自作自演にXP支持者のフリをしてXPの印象を悪くするお前が許せない。

おい、だれかこいつをアク禁にしてくれ!

404 :仕様書無しさん:04/03/30 13:01
>>396
> パソコンスペックが高くなってきてる現状、集中処理のWebアプリに拘る
> 必要ないような気がする。CD-ROM配布でスタンドアロンアプリ配布は
> ダサイけど、サーバーにアプリ置いてダウンロードさせるようにしたうえで
> クライアントのリソースも使うようなC/SとWebアプリの中間のような
> アプリケーションが今求められてるんじゃないか?これからは負荷分散だよ。
> サーバーのクラスタリングだけじゃ限界なんだよ。みんなで処理しようぜ。
それだからJavaApplet with ServletたるやJavaWebStart wih Java RMIが登場したんじゃないか。

405 :仕様書無しさん:04/03/30 13:02
オブジェクト指向を否定してた香具師が論破されて話題をそらそうとしているな。
今度はまたドトネトか。ダサイ香具師だ

406 :仕様書無しさん:04/03/30 13:04
>>367
> >>365
> そこだよな、やっぱ論点は。で>>303の問いに戻るのな。
> 異種間接続の必要性ってそんなにほんとにあるのか?ってとこな。
>
必要あるに決まっておるだろうが。
マニピュレータによる遠隔操作ソフトウェアを実現するためにも必要だ。
将来、ロボット技術が進化したときJavaがさらに浸透すると思われる。

ロボットをJavaで遠隔操作するのだ。


407 :仕様書無しさん:04/03/30 13:04
火星探査機に使われているくらいならロボットなどにも使われるようになってもおかしくないな。

408 :仕様書無しさん:04/03/30 13:07
ロボットなどには使えても、
金融関連では使いにくいJava。

409 :仕様書無しさん:04/03/30 13:09
被害妄想

410 :仕様書無しさん:04/03/30 13:10
組込みJava情報源
http://www.netgene.co.jp/java/

Javaを取り巻く業界の動向

インターネットの普及

OSやハードウエアのバージョンアップを全世界で一斉に,しかも同時に行 わ
なうことは不可能です.よってインターネット環境下では非対称コンピュー テ
ィング(こちら側と相手側が異なるハードウエア,異なるOS,異なるブラウ ザ,
異なる通信手段等)にならざるを得ず,
アプリケーションもアーキテクチャ =ニュートラル性が必要不可欠です.

また使用言語も特定言語を想定することさえできないので,多国語対応も
重要です.Unicodeにも欠点は多数ありますが,それでもないよりはましと
言 えるでしょう.(なおJavaの多国語対応機能のうち,Unicodeはほんの一
部に過 ぎない.)

411 :仕様書無しさん:04/03/30 13:11
もし仮にデバイスがみんなお話するようになったら
別にjavaでなくても構わなくなるな(w
javaへのトランスレータ(ある意味servlet)積むような
アホなマネは廃れるじゃん。

412 :仕様書無しさん:04/03/30 13:11
>>408
されど金融系でJavaがもっともよく使われているという事実を否定することはできない。
また、すくなくともCOBOLやドトネトよりも使いやすい。

413 :仕様書無しさん:04/03/30 13:12
>>411
何も解っていないご様子で。
Appletが生まれた背景も知らずにw
分散処理という言葉をご存じですか?

414 :仕様書無しさん:04/03/30 13:13
既存で一番多いのはCOBOLでは。新規は違うのかもしれんが。

415 :仕様書無しさん:04/03/30 13:13
>>410
またコピペかよ。まったくjava厨は底が浅い。
java厨をjavaで置き換えられそう。
適当なところでキーワードでコピペを繰り返すservletでもおいとけば?(w

416 :仕様書無しさん:04/03/30 13:17
そりゃ妄想の類は理解できないよな(w

417 :仕様書無しさん:04/03/30 13:17
組込みJava情報源
http://www.netgene.co.jp/java/

Javaを取り巻く業界の動向

サーバーサイド=コンピューティング

サーバー分野ではJ2EEがデファクトスタンダードとなったようです.  
信 頼性の高さ,開発効率/再利用性の高さ,開発コストのコストダウン,
ネット ワーク機能,安全なマル チスレッド,セキュリティ,アーキテクチャ=ニュートラル性な
どが理由 でしょう.

アーキテクチャ=ニュートラル性については,将来のハードやOSのバージョ ンアップ時に
おいても,同じソフトがそのまま使えるというメリットがありま す.またサーバーならではの
事情として,開発マシンと実運用のマシンが異な る場合があること(実運用マシンが例えば
16CPU のサーバー機を使うとしても, それを全開発者に用意するのは困難),運用開始後
ユーザー数が急増した時に はより高性能な機種に変更したり,CPU数などの構成を変更す
る場合もあるこ となども,アーキテクチャ=ニュートラル性が必要な理由の一つ.

パフォーマンスについてはサーバーサイドではむしろJavaの方が有利なよ うです.
理由は簡単でJavaならばマルチスレッドで実現できることが,他の言 語や環境では
基本的にマルチプロセスにせざるを得ないからです.C言語など でもマルチスレッド
は不可能ではありませんが,バグが極めて出やすく開発コ ストが嵩むため現実的
では有りません.

418 :仕様書無しさん:04/03/30 13:18
>>415
だからJava厨なんてこのスレにはいないんだから。

あれはただのコピペというよりこのスレに見合ったJavaの動向の議論を
促すための旗振りだと思うよ。

419 :仕様書無しさん:04/03/30 13:19
ごぴぺOFFできないかな。うざくてしゃーない。
どうやら基底クラスにバグ抱えていて止まらないらしい。


420 :仕様書無しさん:04/03/30 13:23
基底クラスにバグを抱えて(もしくは仕変で)にっちもさっちもいかなくなったので、
派生クラスをすべて派生しないようにしてコピペでやっつける技が身体に染み込んでいるの
です。

421 :仕様書無しさん:04/03/30 13:27
>>419-420
お前、本当にオブジェクト指向のことをよくわかっていないヴァカだな。
スーパークラスにバグがあったらそれをどうやって補正するかしらないみたいだな。
一例として、Adapterパターンで委譲してから継承するなどすればいいだろが。
おまえらほんとに頭悪いな。



422 :仕様書無しさん:04/03/30 13:27
顧客主導のバージョンアップ

特に業務用のパソコンにとってはアプリは表計算やワープロ,WWWブラウザ
程度で十分で,あとは各業務依存のソフトウエア(多くはJava2EE分野?)にな る.
いずれにせよ,多くの場合は従来からあるソフトがそのまま使えること, 次にそれ
らを利用者の要望に応じて随時改善していくことが重要.バージョン アップの中心
はベンダーの都合ではなくあくまで顧客の要望で行うべきだろう. (このあたりに難
しい問題があるのは事実だが.Javaのアーキテクチャ=ニュー トラルによるプラット
フォームの支配からの解放が,それを現実的なものにす る.いずれにせよ,ユーザ
ーのニーズよりベンダーの都合を優先する業界に未 来はない.)

423 :仕様書無しさん:04/03/30 13:28
>>419
このスレを高度に優れたスレにするには必要なことだ。

424 :仕様書無しさん:04/03/30 13:28
現場で突貫工事のドカタはそんなことやってないのYO。
現実をみなはれ

425 :仕様書無しさん:04/03/30 13:28
>>419
お前みたいなコピペ煽り厨に対する戒めだよ

426 :仕様書無しさん:04/03/30 13:29
>>424
だれに対してレスしているんだろう。
レス番号つけなはれ、関西人

427 :仕様書無しさん:04/03/30 13:30
信頼性やセキュリティの重要性

IT技術が普及すると共にインフラとしての性質も強くなり,システムの停 止
が大きな損害をもたらすようになりました.今や信頼性は贅沢品ではなく必
需品と言えるでしょう.また,インターネットを通じて世界的に接続可能とい
うことは,同時に常時国際的なクラッキングの危険にさらされているというこ
とでもあり,セキュリティも必需品となってきています.

Javaならば少なくともバッファオーバーフローが起きないし,クラスファ
イルベリファイヤによって危険なコードが排除できます.(他にも様々な理由 がある.)

428 :仕様書無しさん:04/03/30 13:31
XML

XMLは幾つかの分野でデータフォーマットのデファクトスタンダードとなっ
ている.XMLとJavaの親和性については様々な理由があるようですが,アーキ
テクチャ=ニュートラル性,ネットワーク対応,Unicode対応,高い開発効率と
いうだけでも,Javaを使う理由としては十分でしょう.特に文字コードについ
ては他の言語ではUnicode対応が保証されていないため,意外に煩雑な作業に
なる.(実際にはUTF8程度でも運がよければ動くことも多いが,保証されてる
わけではない.ちなみにRubyは公式にUTF8対応のはず.) [JavaとXMLはなぜ仲良し?]

携帯電話/PDA

多くの携帯電話/PHS,PDA等がJavaへ対応しました.最近はこれらの機器は,
ネット端末/モバイルコンピューティング端末としての性質が重要になってき
ていること,その場合にアプリケーションを特定ハード専用に開発するのが現
実的でないことなどがJavaが採用される理由のようです.

情報家電
まだ数は少ないとはいえ,情報家電は二つの意味でJavaへの対応が必要と
なります.一つはネット接続機能/ネット端末として.もう一つはコードサイ
ズの増大によるソフトウエア危機への対策として.

429 :仕様書無しさん:04/03/30 13:32
デザインパターン, リファクタリング, XP

いずれもJavaである必要はありませんが,OOP言語の有効性を高める
ノウハ ウを提供しています.これらによりOOP言語による開発がますま
す重要になっ てきました.

430 :仕様書無しさん:04/03/30 13:33
>>419
Javaに対する偏見をもったしつこいウザイレスが減ってくれるならJava事情を紹介する
コピペはどんどんやってほしい

431 :仕様書無しさん:04/03/30 13:34
夢見るJava

432 :仕様書無しさん:04/03/30 13:37
XQueryも標準サポートしないJavaなんかまともに使えないよな。
.NETの方が至れり尽くせりだ。

433 :仕様書無しさん:04/03/30 13:38
夢見るジャバラじゃいられない♪

434 :仕様書無しさん:04/03/30 13:41
XMLといえば.NET。.NET最強。

What's New in System.Xml for Visual Studio 2005 and the .NET Framework 2.0 Release
http://msdn.microsoft.com/xml/default.aspx?pull=/library/en-us/dnxml/html/SysXMLVS05.asp

435 :仕様書無しさん:04/03/30 13:43
ジャバラの現実。コピペだらけの巨大なメソッド。爆発したクラス

436 :仕様書無しさん:04/03/30 13:44
>>432
お前ドキュンだろ。
それくらい自分で作れよ。
M$が提供した標準でコアAPIがサポートされたものしか使えないのか(ワラ


437 :仕様書無しさん:04/03/30 13:44
必要ないインターフェイスを抽出してadapterとか言い張るジャヴァ厨

438 :仕様書無しさん:04/03/30 13:45
>>436
へー。XQueryサポートを各自で作るんだ。Java使いは。www

439 :仕様書無しさん:04/03/30 13:46
>>434
残念。XMLといえばJava。

もはや.NETという言葉はM$からは消え失せる運命。。

しかもM$のサイトのオナニー記事を紹介しているとは説得力が足りないな。
自分に都合の悪いことはすべて隠蔽してあたかも自分のほうが凄いと
思いこませるのがマイクロソフト帝國のやり方だから。

440 :仕様書無しさん:04/03/30 13:48
>>432
そんなものにたよらず替わりのものを使って代用すればいいのに。
M$が作ったものしか使えないのかM$信者は。
オープンソースで似たようなものがいくらでも転がってるのにねえ。

441 :仕様書無しさん:04/03/30 13:49
さて、次はどんなJavaの動向を解説する?

おや、C++だってよ

442 :仕様書無しさん:04/03/30 13:49
>>439
.NET厨を黙らせるようなXML APIの例見てみたいなー。
あるんでしょ?w

443 :仕様書無しさん:04/03/30 13:50
Java厨はXQueryは必要ないと申しております

444 :仕様書無しさん:04/03/30 13:51
見れば分かる通り,各メソッドの記述自体はC言語に類似.
(Cは有名なだ けに多かれ少なかれCの影響を受けた言語は他にもある.
C++, Objective-C辺 りは露骨にそうだし,間接的にだがPerl,Rubyもそうらしい.
言語じゃないけ どcsh/tcshなども多分そう.C#はJavaの猿真似かね.やっぱり...)

●表記は似ていても,C言語とは流石に時代が違うので様々な点で異なっている.
●オブジェクト指向:Javaはオブジェクト指向言語だが,C言語はもちろん 違う.
●int型:同じ符合付固定小数点数でも,Cでは「ハードウエアにとって最も
 普通のサイズ」なのに対しJavaでは「32bit」と定められている.
●char型:Cでは8bit配列であり,それ以上の文字コードは言語レベルでは
 サポートできない.JavaはUnicode(16bitコード)なので,多文字言語にも一応 対応できる.
●ポインタと参照:ポインタ型はアドレスを持った変数.即ちハードウエア
 に依存した仕様になっている.Javaの参照はインスタンスを参照するもの.ハー ドや実装とは無関係.
●NULLとnull参照:C言語においてはNULLはプラットフォーム依存の定数.
 実際の値は多くの場合は0であるが,仕様ではないため0以外の可能性もある.
 問題なのはポインタpを"if( p == 0 )"で条件判定したり,数値演 算に使ってもエ
 ラーにならないこと.Javaではnull参照と0とは別の型であり セマンティクス上別
 のものであるため,参照と数値で比較したり参照を数値演 算に利用するとエラーになる.

445 :仕様書無しさん:04/03/30 13:52
> もはや.NETという言葉はM$からは消え失せる運命。。
技術は残って言葉だけが消えて、Java厨はさぞ満足のことでしょう。

446 :仕様書無しさん:04/03/30 13:52
Java厨はXMLの話をあまりしたがりません

447 :仕様書無しさん:04/03/30 13:53
>>443
Java厨という香具師は見たことがないけど
XQueryは必要ないと申す香具師はJavaプログラマでも誰もいないと思うよ。
M$の場合、M$独自規格を織り交ぜている危険性があるから、M$独自仕様のXQueryのみ否定しているんじゃないかな。

448 :仕様書無しさん:04/03/30 13:54
ドトネト厨ですからXMLの話題をあまりしたがりません。

449 :仕様書無しさん:04/03/30 13:54
64bitCPUになってもintは32bitのままなの?

450 :仕様書無しさん:04/03/30 13:54
>>444の続き
ドトネト厨の邪魔が入ったが構わず強行突破。

見れば分かる通り,各メソッドの記述自体はC言語に類似.
(Cは有名なだ けに多かれ少なかれCの影響を受けた言語は他にもある.
C++, Objective-C辺 りは露骨にそうだし,間接的にだがPerl,Rubyもそうらしい.
言語じゃないけ どcsh/tcshなども多分そう.C#はJavaの猿真似かね.やっぱり...)

●配列:Cではポインタ演算で実現している.(そういう意味では「C言語に は配列はない」
 と言っても,あながち嘘ではない.)Javaではそもそもポイン タがない.また配列が一
 種のオブジェクト(インスタンス)となっており,境界 チェックなども行われる.文字列も同様.
●文字列:Cでは文字列はchar型(しかも8bit)の配列に過ぎず,文字列の操 作もポインタ演算
 で行う.これがバッファオーバーフローの原因にもなる. JavaではString それ自体がオブジ
 ェクト(インスタンス)であり,文字列の操 作などもメソッド呼出しを使う.
●ライブラリ/API:Cの標準のライブラリは貧弱であること.もう一つは実 装
 とインターフェースの区別がなかったことがJavaとの大きな違い.Javaでは
名前からも分かる通りインターフェースとして定義されている.また,アーキ
 テクチャ=ニュートラル性のためにも,最初から必要となるだろう機能を標準
 APIとして定義している.
●被演算数の評価順序:C言語では実装依存だが,Javaではアーキテクチャ=
 ニュートラル性のためにも評価順序が一意に定められている.評価順序は開発
 効率の面からも重要.評価順序が決まっているからこそ決定的な動作が保証さ
 れる.
●マルチスレッド,例外:C言語には言語レベルでのサポートはない.

451 :仕様書無しさん:04/03/30 13:56
>>445
おれはJava厨という奴はみたもともきいたこともないけど
.NETの技術はJava技術に皮をかぶせたものだけだからね。
Java技術に皮をかぶせたものだけで、ドトネト厨はさぞ満足のことでしょう。


452 :仕様書無しさん:04/03/30 13:56
なおregister宣言に至っては,C言語においてもすでに過去のものとなって いる.


453 :仕様書無しさん:04/03/30 13:57
JavaはXMLと相性が悪いのは周知の事実です。

454 :仕様書無しさん:04/03/30 13:58
C++が反面教師? [Effective C++, More Effective C++]
●C++は多重継承ベースだが,Javaは単一継承が基本.
 多重継承はパフォー マンス的,セマンティクス的に問題が多い.
 今や可能な限り使うべきでないと されている機能の一つ.
●基本的にC++はC言語の上位互換:このためにできることが『多すぎる』.
 特にセキュリティ面ではC言語にできることを全て認めることは困難.また,
  カプセル化一つとっても,C言語にはインスタンスの概念がなく,どのフィー ルド
 の内容も自在に変更可能.たとえC++にprivate宣言(のようなもの)があっ
 たとしても,それが守られる保証は全くない.
●「標準ライブラリ」がない.最近はSTLとかいうのができたらしいが,残
 念ながらとき既に遅しという感がある.また,たとえばMFCのように特定企業
 の独自仕様ライブラリが使われる場合さえある.
●演算子オーバーロードについては賛否両論あり.(継承と同じでうまく使
 えば便利な機能ではあるが,乱用すると手がつけられなくなる.)
●同様にenum 型も廃止されている.enum型もなにかとバグの原因になり易
 い機能の一つ.(例えば"BLACK + WHITE == RED"や"RED == BOOK"や"
 WINDOWS_NT4 + USB==WIDOWS2000"などがエラーにな らない.enumは
 本来は単なる識別子なので,足し算や引き算が定義できない. また異なる
 性質のものとも比較できない.) Type Safe Enum(型安全なenum型) と呼ば
 れるイディオムが作られ,近いうちに標準になると思われる.(型安全 という
 のは,噛み砕いて言えば「価格が高い」と「標高が高い」のような,比 較でき
 ないものを比較することが起こりえないということ.)

●inline宣言を廃止.コンパイル時のインライン展開も原則廃止.インライ ン展開は
JavaVMによって実行時に行われる.

455 :仕様書無しさん:04/03/30 13:59
最近のVB使いはパターンを駆使して非常にレベルが高い。
http://msdn.microsoft.com/architecture/patterns/

456 :仕様書無しさん:04/03/30 13:59
MicrosoftはXMLと相性が悪いのは周知の事実です。


457 :仕様書無しさん:04/03/30 13:59
まあ、現実にはドカタの現場は悲惨なわけだが。いくら夢を語ろうとも。

458 :仕様書無しさん:04/03/30 14:00
XMLと.NETの統合。JDBCではここまで進化はしていません。
http://www.microsoft.com/japan/msdn/sqlserver/dnsql90/sql_ovyukondev.asp

459 :仕様書無しさん:04/03/30 14:02
    J2EE 対 マイクロソフト。NET
 XMLに準拠したWebサービスを構築する際における比較
 
             by チャド・ウオータ&エド・ローマン
http://webclub.kcom.ne.jp/ma/maknakat/Tech_Info2/html/Roman.html


460 :仕様書無しさん:04/03/30 14:03
>>458
JDOも知らないのか。
CMP Entity Beanも知らないのかアフォですねドトネト厨やマイクロソフト社員というのは。

461 :仕様書無しさん:04/03/30 14:03
今頃になってASP.NET1.0と同じことをしようとしてるね。w
http://www.itmedia.co.jp/news/articles/0403/30/news015.html

462 :仕様書無しさん:04/03/30 14:04
今面白いサイトを探そうとしている。
なかなかいい掘り出しものがあったんだけどあのURLはどこにいったかな。

463 :仕様書無しさん:04/03/30 14:05
>>461
そもそもASP.NETなんてたいしたこと無いじゃん。

ASp>ENTはStrutsやTurbine, JSF, Tapestryにはかなわないし。

464 :仕様書無しさん:04/03/30 14:07
>>463
membershipやmaster page、personalizationのないJava糞フレームワークなぞ相手ではない。

465 :仕様書無しさん:04/03/30 14:09
>>463
それは今からやろうとしているJava Studio Creatorは
たいしたことが無いということか?

466 :仕様書無しさん:04/03/30 14:09
マイクロソフトドットネットがJavaよりもセキュリティ面で劣っている証拠が解説されている。

Java vs. .NET Security, Part 1
Security Configuration and Code Containment

http://www.onjava.com/pub/a/onjava/2003/11/26/javavsdotnet.html

467 :仕様書無しさん:04/03/30 14:10
>>464
具体的にどう糞フレームワークなのか解説できないお前は厨房

468 :仕様書無しさん:04/03/30 14:10
ASP.NET "Whidbey" のマスター ページ
http://www.microsoft.com/japan/msdn/net/aspnet/aspnet-masterpages.asp

ASP.NET "Whidbey" の新しいメンバシップ機能
http://www.microsoft.com/japan/msdn/net/aspnet/aspnet-membership.asp

ASP.NET "Whidbey" の新しいパーソナライゼーション機能
http://www.microsoft.com/japan/msdn/net/aspnet/personalizationwhidbey.asp

ASP.NET "Whidbey" の新しいコード コンパイル機能
http://www.microsoft.com/japan/msdn/net/aspnet/codecompilation.asp

469 :仕様書無しさん:04/03/30 14:11
Javaがマイクロソフトドットネットよりも優れている101の理由

101 Reasons Why Java is Better than .NET
http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet


470 :仕様書無しさん:04/03/30 14:12
今度はアスピ信者が現れたか

なにやら必死だなアスピィ


471 :仕様書無しさん:04/03/30 14:14
>>468
プリコンパイル機能はいいね

472 :仕様書無しさん:04/03/30 14:15
>>466
機能のショボイJavaの方がセキュアというのは詭弁

473 :仕様書無しさん:04/03/30 14:16
1. No Proprietary APIs - Any Java public apis are part of the public domain,
.NET apis are proprietary and can open the door to a law suit.

2. Source Code You Can Legally See - Java source code for the core
libraries are available in every J2SDK distribution, .NET sources can only
be seen by resorting to illegal means.

3. .NET Purity is a Myth - Java promotes 100% pure Java libraries, for
.NET purity is nothing more than a myth.

4. 75% of the Enterprise Use Java - Avoid becoming one of the 25% of "use-less" employees.

5. Majority of Programmers Prefer Java over .NET for WebServices - Despite billions spent by
Microsoft in marketing, surveys continue to reveal that Java is the preferred platform when
it comes to Web Services.

6. Superior Web Development Frameworks - ASP.NET is a poorly designed and
crippled framework as compared to the richness of frameworks found in Java.

7. Stored Procedures - Most relational databases support writing of stored procedures
in the Java language. There has yet to be a production release of a database that
supports any .NET languages.

8. Experienced Practitioners - Nobody seems to know how to write .NET programs
well and that's giving .NET a bad name! A pretty lame excuse I must say!

9. Innovative Open Source Organizations - Open Source communities that support
distributed development are a plenty in the Java world.

10. Proven Security - 2 Years after Trust Worthy initiative is launched and we
collectively loose $55 billion last year.

474 :仕様書無しさん:04/03/30 14:16
はぁ。.NETも巨大だな。
今からやっておかないと手遅れになるな。

475 :仕様書無しさん:04/03/30 14:16
>>472
必死だな。具体例もあげられずに

476 :仕様書無しさん:04/03/30 14:17
JavaもJakarta Projectを見れば解るように巨大で
今からやっておかないと手遅れになるな。


477 :仕様書無しさん:04/03/30 14:17
Javaなんて誰もまともに使ってないからセキュアに見えるだけだよ。

478 :仕様書無しさん:04/03/30 14:18
Jakartaはバージョンがコロコロ変わって過去の互換性がゼロだから手を出す価値ないよ

479 :仕様書無しさん:04/03/30 14:19
>>471
プリコンパイルは言語仕様とは関係ないと想われ。

480 :仕様書無しさん:04/03/30 14:20
Javaは巨大ですよ。





フレームワークが乱立してるし

481 :仕様書無しさん:04/03/30 14:20
JSPは実際の表示してみないとエラーを発見できないから糞。
ASP.NET2.0ではそんなことは起きない。

482 :仕様書無しさん:04/03/30 14:21
>>478
> Jakartaはバージョンがコロコロ変わって過去の互換性がゼロだから手を出す価値ないよ
> Jakartaはバージョンがコロコロ変わって過去の互換性がゼロだから手を出す価値ないよ
> Jakartaはバージョンがコロコロ変わって過去の互換性がゼロだから手を出す価値ないよ
> Jakartaはバージョンがコロコロ変わって過去の互換性がゼロだから手を出す価値ないよ
> Jakartaはバージョンがコロコロ変わって過去の互換性がゼロだから手を出す価値ないよ
> Jakartaはバージョンがコロコロ変わって過去の互換性がゼロだから手を出す価値ないよ
> Jakartaはバージョンがコロコロ変わって過去の互換性がゼロだから手を出す価値ないよ


たとえば何処が? 仮にそれだけの理由だとしても手をだす価値がない?
じゃあC#は過去のVisualC++との互換性がないから手を出す価値がないんだね。
君の論理で言うと。

483 :仕様書無しさん:04/03/30 14:21
>>480
C++はもっと巨大ですよ。
フレームワークだけでなくただのライブラリ集など
バイブルと化しています。

484 :仕様書無しさん:04/03/30 14:22
Jakarta同士で機能がかぶったり、プロジェクトそのものが消滅したりでとても怖くて手を出せない。

485 :仕様書無しさん:04/03/30 14:23
Jakartaは俺でも悪意のあるコードを埋め込めるから止めておいた方がいいよ。

486 :仕様書無しさん:04/03/30 14:23
>>481
> JSPは実際の表示してみないとエラーを発見できないから糞。
> ASP.NET2.0ではそんなことは起きない。
無知だな、お前。そんなもんは言語仕様とは全然関係ないことだが。
しかもそれはIDEの機能だろ。
だったらすでに同じものがJSPにもあるわけだが。
それに、お前はCactusの使い方も知らないのか。


487 :仕様書無しさん:04/03/30 14:23
>>466
結論だけ翻訳して読んだ。.NETの方がわずかに優れていると読める。

Java vs. .NET Security, Part 1
この記事は、.NETとJavaのプラットフォーム上のコード封じ込めのセキュリティ?\成問題および異なる様相をカバーしました。
Javaには、そのconfigurabilityを備えた多くの長所があります。コード封じ込めはといえば、両方のプラットフォームは、
わずかにより多くの選択権があり、より直接に使用することである.NETと共に、かなり強い提供物を持っています。

Java vs. .NET Security, Part 2
この記事では、Javaと.NETのプラットフォーム上の暗号学およびコミュニケーション保護が調査されました。
Javaは旧式の米国輸出制限によりより複雑な解決策を持ちますが、両方のプラットフォームは暗号の特徴ではさえかなり現われます。
画像はコミュニケーション保護はといえばより泥だらけになります--Javaが、プラットフォームおよびアプリケーションレベル解決策の
両方の選択の提供によりはるかによく暮らしている一方、それは明白に、ウェブ・サービス・セキュリティのサポートはといえば.NETより遅れます。
ここに、Java開発者はよく独立したベンダーに希望の特徴を求めなければならなかった。

Java vs. .NET Security, Part 3
この記事では、Javaと.NETのプラットフォームのコード保護およびコード・アクセス・セキュリティ特徴が調査されました。
コード保護が多かれ少なかれ現われた一方、さえ、.NETの中のCAS特徴は、単一の例外を除いて、
Javaが提示することができるものより著しくよい。 ―― 柔軟性。Javaは、それが多くの場合そうであるとともに、
.NETが一致することができない政策取り扱いでの容易さおよびconfigurabilityを提示します。


488 :仕様書無しさん:04/03/30 14:24
>>484
> Jakarta同士で機能がかぶったり、プロジェクトそのものが消滅したりでとても怖くて手を出せない。
どこが機能が被っているんだw
Win32APIと.NETframeworkでは機能がかぶってるだろ。
プロジェクトが消滅した形跡などどこにもないしw

489 :仕様書無しさん:04/03/30 14:24
どのフレームワークを使えばいいですか?標準はStrutsですか?

490 :仕様書無しさん:04/03/30 14:24
>>486
.NET FrameworkにプリコンパイラがついててIDEなんか必要ないんだな、これが。
あ、そうか。Javaは高価なサーバがないと何もできないんだっけ。w

491 :仕様書無しさん:04/03/30 14:25
>>485
オープンソースだから問題なし。
しかし.NETはそうはいかないな。
悪意のあるコードを簡単に埋め込める。
型安全性が弱い旧VBを使ってだ


492 :仕様書無しさん:04/03/30 14:26
Strutsは死滅。Tapestry使え。

493 :仕様書無しさん:04/03/30 14:26
>>490
何いってんだろこいつ。
オープンソースで用意すれば全然かねかからないが。
IDEなくてもAntでも差分コンパイルはできるわけだが。池沼ですか?

494 :仕様書無しさん:04/03/30 14:27
>>491
旧VBは.NETだったんだ。w
じゃあ互換性の心配はないね。w

495 :仕様書無しさん:04/03/30 14:28
>>493
AntでどうやってJSPのプリコンパイルできるの?w

496 :仕様書無しさん:04/03/30 14:28
StrutsとTapestryは互換性ありますか?

497 :仕様書無しさん:04/03/30 14:28
>>496
ありません。それどころかお互い潰し合ってます。

498 :仕様書無しさん:04/03/30 14:29
>>492
ひでえ話しだ。M$みたいだな。

499 :仕様書無しさん:04/03/30 14:30
.NETも成長速度が速いな。
Javaに浮かれてると大変なことになりそうだ。

500 :仕様書無しさん:04/03/30 14:30
11. No Lizard Brain - .NET programmers continue to struggle with the
complexities of a hybrid managed/unmanaged environment.

12. More Languages on the JVM - The JVM is more "common" than the CLR.

13. Smaller Runtime Download - You can't run your app if you don't have the runtime.

14. No Mandatory Upgrade Fees - 3 things a Microsoft shop can't avoid: Death, Taxes and License 6.

15. More Vendor Choices - .Net is a marketing program. Java is a Market.

16. Better Collection Classes - The .Net libraries look like
they were designed by high-school students, First year CompSci? students at best.

17. Future Proof - The way to ensure your return on investment (i.e. ROI) is that your choice of
platform doesn't get obsolete in 5 or even 10 years. Avoid the Microsoft upgrade treadmill!

18. Larger Talent Pool - Majority of Universities not only teach but require knowledge of Java.
That's a big talent pool that you need to consider before you off-shore your project to
a different time-zone.

19. More Contributions from Research Institutions - Research institutions and universities
have consistently provided innovative research not only built on top of Java but also
contributing to Java.

20. U.S. Government Approved - Guess where the billions of dollars spent
on the U.S. government's IT renovation is going to?

501 :仕様書無しさん:04/03/30 14:30
そろそろ.NETやらないとまずいな

502 :仕様書無しさん:04/03/30 14:31
>>494
M$は.NETは古い言語もサポートできると主張していたものの現実はちがっていたがw

503 :仕様書無しさん:04/03/30 14:31
2002年〜2003年頃にもてはやされて納品されたStruts案件はどうなりますか?

504 :仕様書無しさん:04/03/30 14:31
Java使いもやっぱりCASは評価してるんだな。

505 :仕様書無しさん:04/03/30 14:32
>>495
どこまでも馬鹿なんですかw
JSPの中身はServletですよ。それもわからないのですか。
自分でAntについて検索してみたらw


506 :仕様書無しさん:04/03/30 14:32
>>503
作り直してください。

507 :仕様書無しさん:04/03/30 14:34
>>505
標準コマンドでどうやってJSP→Servletに変換できるの?

508 :仕様書無しさん:04/03/30 14:34
>>499
遅いだろ。
75% of the Enterprise Use Java - Avoid becoming one of the 25% of "use-less" employees.

509 :仕様書無しさん:04/03/30 14:35
>>508
2年ちょっとでこれじゃあ5年後にはどうなってることやら。
Windowsの中核APIになってるんだろうね。

510 :仕様書無しさん:04/03/30 14:35
>>507
標準コマンドしかつかえないのかお前は
シェルスクリプトもバッチファイルもかけないんだなお前は。
どうやらお前はプログラマに向いてないな。
オプショナルタスクの使い方もしらないとは愚かな奴



511 :仕様書無しさん:04/03/30 14:35
>>506
全部作り直す必要性はまずないだろ

512 :Java厨:04/03/30 14:36
>>510 ドキッ

513 :仕様書無しさん:04/03/30 14:36
>>511
全部作り直すほうがぼれるので紺猿が喜びます。

514 :仕様書無しさん:04/03/30 14:36
>>510
コマンドではできないんですね?
ASP.NET以下ということ?

515 :仕様書無しさん:04/03/30 14:37
>>498
ちょっとちがう。
つぶし合っているからM$みたいなひどい奴?
ちょっとちがう。
お互い、考え方が異なるだけってこと。


516 :仕様書無しさん:04/03/30 14:37
>>512
いきなり「Java厨」なとかかんようにドトネト厨は

517 :仕様書無しさん:04/03/30 14:37
>>515 キーワード:顧客の利益

518 :仕様書無しさん:04/03/30 14:37
>>510
TaskぐらいMSBuildで書けるよ。
でもその上で標準のコマンドでプリコンパイルもできるのが.NETだよ。

519 :仕様書無しさん:04/03/30 14:38
>>516
もう少し落ち着いて

520 :仕様書無しさん:04/03/30 14:38
>>514
さっきから甘えん坊みたいに変なこといっているお前は餓鬼?
バッチ処理もコマンドだぞ。
Antもコマンドだぞ。

521 :仕様書無しさん:04/03/30 14:39
>>520
java.exeもコマンドだけどな。(嘲笑激藁

522 :仕様書無しさん:04/03/30 14:39
>>518
標準じゃないと気が済まないって考え変だな。
M$Buildはもともと標準じゃなかったし。
あれはNantというオープンソースプロジェクトだったわけだが。

523 :仕様書無しさん:04/03/30 14:40
例のブビ厨がマ板にやってきたのか

524 :仕様書無しさん:04/03/30 14:40
NAntなんてゴミ使わねえよ。MSBuildだけで十分。

525 :仕様書無しさん:04/03/30 14:42
そろそろ.NETに乗り換え時だな

526 :仕様書無しさん:04/03/30 14:43
javaコピペが始まってスレのレベルが著しく落ちたな。


527 :仕様書無しさん:04/03/30 14:43
21. No Evil Type Coercion - Some C++ constructs are meant to be entombed forever,
.NET resurrects them with disastrous consquences.

22. Mature O/R Mapping Solutions - You can't beat the wealth of O/R mapping
solutions found in Java.

23. Superior Coding Tools - Like having your own personal Java fairy dancing through your code,
anticipating your every thought and keystroke.

24. Sane Coding Conventions - I don't know what's worse Hungarian notation or .NET
coding conventions.

25. Higher Paying Jobs - Somehow you've got to afford those skyrocketing housing prices don't you?

26. Better Support for P2P - Gnutella and JXTA, anything else legally more pervasive?

27. 100% Pure Java RDMS - Can't beat the ease of installation when the
RDMS is Java based and packaged with the application in a .zip file.

28. More Robust Exception Handling - .NET has no analog to the throws clause in method signatures.

29. Open Source Structured Graphics - When going beyond forms and windows, Java can't be beat.

30. Reusable IDE Frameworks - Why re-invent the wheel?
Start building your killer GUI application on top of killer IDE frameworks.

528 :仕様書無しさん:04/03/30 14:44
>>526
いや、逆に上がった。一時的に下がっているのはASP.NET厨がくだらないことで
JavaよりもASP.NETが優れている主張しているから。

529 :仕様書無しさん:04/03/30 14:45
>>527をみると、そろそろ.NETからJavaに乗り換え時だな。

530 :仕様書無しさん:04/03/30 14:47
31. More Parser Building Tools - Want to build a new language,
well you'll need some robust parser building tools.

32. Aspect Oriented Programming - The next advance in modular software development,
get a head start by using Java.

33. 100% Pure Java Web Servers - Customizations and extensions are easier in a web
container that's built using the same language as applications.
Furthermore, managed environments support better reliability and security.

34. Extensible Java Compilers - Your tools have got to be able to parse the code
before it has any chance in understanding it.

35. Distributed Caching - Sometimes embarassingly parallel applications aren't the only
things that you need to scale.

36. More Reliable Messaging Choices - Java provides more choices for the backbone
that integrates the Enterprise.

37. Faster Development Turnaround - Incremental compilation is unavailable in the .NET environment.

38. Lightweight Persistence - Sometimes a relational database (RDMS) has too big a footprint.

39. Community Process - How does one contribute to the specification of standards?

40. Hardware Accelerators - Performance boosting hardware.

531 :仕様書無しさん:04/03/30 14:47
ドカタが優れている101の理由

532 :仕様書無しさん:04/03/30 14:47
日本語に訳して書き込めアホ

533 :仕様書無しさん:04/03/30 14:48
javaコピペ厨はどっかのコピペ引っ張ってきて
どうだ凄いだろうてなことなんだろうが
客観視ができていないんだよ。
どういうメリットとデメリットがあるのか
客観的な立場からの検証がないからうざいだけだ。
java眼鏡をかけた未来はjavaを通してみれば明るいに決まっている。
だがjavaってのも方法論の一つに過ぎないわけだろ?
もう少し頭冷やせや。宗教がかっているぞ。昔(今もか?)のAppleみたいじゃねーか。

534 :仕様書無しさん:04/03/30 14:48
41. Licensing Options - Ultimate flexibility in licensing.

42. Embedded Device - Java inside small packages.

43. Faster Virtual Machines

44. MickrokernelArchitectures

45. ContinuousBuild

46. Whole Program Optimization - Please sir may I have a linker?

47. Comprehensive RDMS Driver Support - Can you find a ADO.NET driver for an open source database?

48. Superior Code Analysis Tools

49. Unsurpassed Network Connectivity - Why is MSN managed by a Java based tool?

50. More Garbage Collection Options

535 :仕様書無しさん:04/03/30 14:49
Strutsで納めたシステムの更新&拡張はどうしていくのさ。

536 :仕様書無しさん:04/03/30 14:49
ドカタが優れているならそれはドカタとは呼ばない

537 :仕様書無しさん:04/03/30 14:49
>>532
ププ 英語もよめねえのか(ワラ
プログラマ向いてないなドトネト厨はw


538 :仕様書無しさん:04/03/30 14:50
ドカタつーより信者だなまるで

539 :仕様書無しさん:04/03/30 14:50
>>535
Struts使ったことある?
ActionFormBeanとかを継承してさ(ry

540 :仕様書無しさん:04/03/30 14:51
>>533
それをいったらM$の宣伝文句を鵜呑みにしているお前はどうなのかと庄一時間問いつめ

541 :仕様書無しさん:04/03/30 14:52
>>540
ああM$のコピペもうぜぇな

542 :仕様書無しさん:04/03/30 14:52
51. ReliabilityConcerns

52. Better Web Services Interoperability

53. Better Domain Specific Languages Support

54. Painless Upgradability

55. Simple Side By Side Execution

56. More Business Rules Engines

57. Lightweight Containers

58. Better Business Process Management

59. Sixty Four Bit Support

60. Millions Of Java Phones

543 :仕様書無しさん:04/03/30 14:52
>>542 おめたいがいにしろ、うぜぇ

544 :仕様書無しさん:04/03/30 14:53
>>533
お前はろくにこの英文とそのリンク先も読むまでで文句を言わないように。
あれのどこが信者の主張だヴォケ
十分客観的だろが

545 :仕様書無しさん:04/03/30 14:54
MSのGet the Factぐらい客観的でないと信用できない

546 :仕様書無しさん:04/03/30 14:54
>>543
おまえの主張は完全無視。
ドカタドカタなどとは二度と煽らせないためにやっている。
お前がドカタといえば天罰としてこのコピペが延々と続くと思え

547 :仕様書無しさん:04/03/30 14:54
もうアホか馬鹿かと
商売人は自分に都合のいいことしかいわねーんだよ、何処の世界でもな。
そんな手前味噌なコピペ張って得意げにほんと馬鹿じゃねーの?


548 :仕様書無しさん:04/03/30 14:54
でも現実はドカタだらけ。(ワラ

549 :仕様書無しさん:04/03/30 14:55
>>545
あれはどこも客観的でない。詭弁という。
自社の都合にあわせているだけ。

550 :仕様書無しさん:04/03/30 14:55
お客がいないと吼える吼える

551 :仕様書無しさん:04/03/30 14:55
>>549
都合のよい「客観的事実」の寄せ集めなんだよ。分かる?
事実は事実ということで。

552 :仕様書無しさん:04/03/30 14:55
>>546の自白はスレ荒らし行為の証拠になりました。削除対象でつね(w

553 :仕様書無しさん:04/03/30 14:56
>>547
問答無用。
貴君の主張を却下する
あれは商売人のやったことではない。

554 :仕様書無しさん:04/03/30 14:57
>>552
ならばいい加減なことをいっている奴もすべて削除対象w
オープンソースが共産主義と主張した香具師がいたら即刻削除対象。

ついでにアク禁。

555 :仕様書無しさん:04/03/30 14:57
客観的事実として、Javaは.NETより生産性が低いし、Java使いはドカタしかいない。

556 :仕様書無しさん:04/03/30 14:57
61. Garbage Collect Classes - The only way to unload MSIL code is to unload an entire application domain.

62. More Alternative VM Implementations

63. Hard Realtime Capabilities

64. Cross Platform Language Integration

65. More Extensive XML Support

66. Better Support For Dynamic Distributed Systems

67. Superior 2D Drawing

68. Better GUI Framework

69. SuperiorBranding

70. No Anti Open Source Agenda

557 :仕様書無しさん:04/03/30 14:58
>>554
オープンソースの主張は共産主義と酷似。
客観的事実。

558 :仕様書無しさん:04/03/30 14:58
>>555
それは事実でもなければ客観的でもない。
根拠がない。
http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet
にしっかりと目をとおせ 

559 :仕様書無しさん:04/03/30 14:58
やっぱり馬鹿でつか?
連続コピペが削除対象なんでつよ?(w
主義主張は無関係でつ。

560 :仕様書無しさん:04/03/30 14:59
>>558のリンク先にも客観的事実がないわけだが

561 :仕様書無しさん:04/03/30 14:59
>>557
それは主観的な虚偽という。
マイクロソフトのやっていることは閉鎖的で社会主義的。
客観的事実。

562 :仕様書無しさん:04/03/30 14:59
>>560
いや、そこのリンク先には客観的事実がある。

563 :仕様書無しさん:04/03/30 15:00
年度末間近に何やってんだお前ら

564 :仕様書無しさん:04/03/30 15:00

狂信者を晒すスレはここでつか?

565 :仕様書無しさん:04/03/30 15:01
>>559
同じものあちこちに貼り付けたときだけ削除対象になる。
おまえの主張ではニュー速板で記事をコピペしたものは皆削除対象と
主張しているに過ぎない。



566 :仕様書無しさん:04/03/30 15:01
>>563
無職とひきこもりだから年度末は無関係の模様。

567 :仕様書無しさん:04/03/30 15:01
71. Standardized Portal Framework - Standardized ""Integration at the glass"".

72. Run In Interpreter Mode - ""We're just not optimized for interpreting""

73. More Semantic Web Research

74. Leads In Software Process Best Practices

75. Better Concurrency Utilities

76. More Multicasting Libraries

77. Superior Refactoring Tools

78. Higher Demand Therefore More Jobs

79. Faster And More Reliable Regex

80. SuperiorBuildEnvironments - A .NET practitioner's concept of a build is F7.

568 :仕様書無しさん:04/03/30 15:02
マカみたい

569 :仕様書無しさん:04/03/30 15:03
81. Embarassingly Rich Information Sources

82. More Open Source Projects

83. Affordable Industrial Grade IDEs

84. Standardized Enterprise Connectivity

85. DynamicLanguagesSupport

86. Palm, Symbian and Pocketpc support - Why limit oneself to a single PDA brand?

87. OpenTechnologyRoadmap - .NET is like a five year plan in the former USSR: You know it doesn't actually make sense or help anything, but if you live under it, you're certainly not going to say anything negative about it.

88. Sincere Support for Standardization

89. Recommended by Big Brother - JavaCards? are becomming the preferred method of keeping tabs on your citizenry or customers. If Microsoft ever co-opts this technology then "1984" will become more than just a paperback novel.

90. Complete Open Source Stack - Open Source code visibility spanning all layers of an application.

570 :仕様書無しさん:04/03/30 15:04
91. NonStopServers - .NET not fault-tolerant enough for Hewlett-Packard-Compaq?

92. Out Of This World - Java runs on other planets, .NET has yet to leave Terra Firma.

93. UnitTestingSupport - More extensions and comprehensive IDE support

94. More Identity Management Solutions - Can you trust Microsoft to keeping your customer's identity secure and available?

95. Most UML Tools Implement In Java - Ever wonder why the best UML tools are implemented in Java?

96. More R&D On Intelligent Agents - Java is the preferred implementation platform for Intelligent Agents.

97. Easy Rich Client Deployment - No-Touch development was shaky.

98. Lower Cost for Massively Parallel Systems - How much does it cost to deploy a .NET application on a platform with 10,000 servers like google?

99. More Profilers - Profilers mitigate the risk of not finding the root cause of show stopping bugs.

100. Eclipse

101. Obligatory Recursive Definition

571 :仕様書無しさん:04/03/30 15:04
お客がいないと吼える吼える

572 :仕様書無しさん:04/03/30 15:04
JavaがM$ドットネットよりも優れている101の理由



ダイジェスト


573 :仕様書無しさん:04/03/30 15:05
※ 連続投稿で利用者の会話を害しているものは削除対象になります。
個々の内容に違いがあっても、荒らしを目的としていると判断した
ものは同様です。


574 :仕様書無しさん:04/03/30 15:07
>>546
>ドカタドカタなどとは二度と煽らせないためにやっている。
>お前がドカタといえば天罰としてこのコピペが延々と続くと思え
確信的荒らし行為だね

575 :仕様書無しさん:04/03/30 15:08
>>546はアク禁になるのかな?(w

576 :仕様書無しさん:04/03/30 15:08
荒らすなよ。ドカタ

577 :仕様書無しさん:04/03/30 15:09
働いてるのはドカタ。
擁護してるのは無職。

ろくな言語じゃないね、Java。

578 :仕様書無しさん:04/03/30 15:13
言い得て妙だな。

579 :仕様書無しさん:04/03/30 15:16
若い頃は理想主義にはまりがちなものだよ。

580 :仕様書無しさん:04/03/30 15:18
やはり.NETぐらいが現実的なベストバランスだ

581 :仕様書無しさん:04/03/30 15:30
アホアンチ、休んでる場合ではないぞ。
もっとJavaの宣伝をしないとドトネト厨にいいようにやられるぞ!

582 :仕様書無しさん:04/03/30 15:41
ASP.NET2.0の方が魅力的だね

583 :仕様書無しさん:04/03/30 16:02
ドカタは力尽き、無職は昼寝の時間帯のようだ。

584 :仕様書無しさん:04/03/30 16:26
論破させれば話題を変えて
ああいえば、こういう。

往生際の悪いJavaer。

話をループさせるから太刀が悪い。

585 :仕様書無しさん:04/03/30 16:31
Javaがつかえない、ドカタ、とか言ってる奴は、オブジェクト指向、デザインパターン等の
最新の情報工学の成果を理解出来ないオッサンだろ。

586 :仕様書無しさん:04/03/30 16:37
へー。最新なんだ。
君どこの大学出た?プププ

587 :仕様書無しさん:04/03/30 16:38
OOごときが最新とはかなり斬新な意見だ。

588 :仕様書無しさん:04/03/30 16:39
これが低学歴の限界というやつか。(ワラ
やはりドカタ以上のことに手を出さない方が賢明だ。

589 :仕様書無しさん:04/03/30 16:40
うっさい。社畜オッサンは年度末の仕事でも片付けろよ。
リストラされるぞw

590 :仕様書無しさん:04/03/30 16:42
無職で年金も払ってないやつには言われたくないな。w

591 :仕様書無しさん:04/03/30 16:44
今日もコボラがうざい

592 :仕様書無しさん:04/03/30 16:44
最新の情報工学の成果を活かしたドカタ仕事とはこれ如何に。

593 :仕様書無しさん:04/03/30 16:44
得意の金融関係をJavaに侵食されたコボラおっさんのオナニースレはこちらですか?

594 :仕様書無しさん:04/03/30 16:45
Java派遣は最新の経営学の成果です。

595 :仕様書無しさん:04/03/30 16:46
C厨おっさん氏ね

596 :仕様書無しさん:04/03/30 16:47
金融計算にJavaのBigDecimalは使えないよな。
演算子オーバーロードできるなら考えてもいいけど。

597 :仕様書無しさん:04/03/30 16:47
ポインタも使えないJavaでどうやって柔軟なシステムを作れと?

598 :仕様書無しさん:04/03/30 16:48
Javaは遅い。
フルネイティブでないプログラムは信用できない。

599 :仕様書無しさん:04/03/30 16:49
なんで金融関係にJavaとか言ってる奴がいるんだろう。
元々PC用パッケージソフト屋だったんで、COBOLに関する知識はほとんどないが、
それでもJavaよりCOBOLのほうが向いていると思う。蓄積もあるしね。

600 :仕様書無しさん:04/03/30 16:53
Javaは日付計算も糞だしな。

Calendar.getInstance().add(Calendar.DATE, -1)

601 :仕様書無しさん:04/03/30 16:54
フロントエンドにJava使うのが流行ってるから。

602 :仕様書無しさん:04/03/30 16:55
まあFlashで事足りるわけだが。

603 :仕様書無しさん:04/03/30 16:56
なんでこんなのをWebアプリでってのもあるよな。
リプレース前はオフコンとかVBのクラサバだとかで、あまりにも使い勝手が変わってしまい、
ユーザーが切れたって話も聞くしな。

604 :仕様書無しさん:04/03/30 16:56
>>600
−演算子使うよな、普通

605 :仕様書無しさん:04/03/30 16:57
勘定系にWindows使い出した銀行があったけど、その後何も起きてない?

606 :仕様書無しさん:04/03/30 16:57
スレが伸びてると思ったら荒しかよ。

607 :仕様書無しさん:04/03/30 16:58
作る側の都合優先はおかしいよな。
ドカタかき集めて高い単価ぼったくるなよ。
ドカタ本人には金は回らないけどな。w

608 :仕様書無しさん:04/03/30 16:59
>>596
自分勝手にいろいろ作ったら、可視性、共通性下がるだろうが…、
保守性等も考えたら、自分でサブクラス作っていろいろメソッド作ればいいだけだろう…
サブクラスで計算メソッドの安全性(バグがない)が分かったら
他にも使えるだろうし…
全然OOをしらないのか?それでよくやっていけるな??

609 :仕様書無しさん:04/03/30 16:59
やっぱりメインフレーム+Windowsクライアントが最強ということで。

610 :仕様書無しさん:04/03/30 17:01
>>603
それは、コボラが作ったWebアプリの画面です。
奴らは汎用機の端末のイメージでしか考えられないのだ。

611 :仕様書無しさん:04/03/30 17:02
XP SP2出てポップアップ系も壊滅的打撃だな。
またユーザーからJavaで作ったシステムは糞だと罵倒される。

612 :仕様書無しさん:04/03/30 17:03
>>603
リプレース前のシステムに似せるためにアプレット埋めまくりとかねw

613 :仕様書無しさん:04/03/30 17:05
Javaドカタは徹夜作業で動作確認しなさい。
チミらの作った糞システムの動作が変わるから。
http://www.microsoft.com/japan/technet/prodtechnol/winxppro/sp2preview.mspx

614 :仕様書無しさん:04/03/30 17:06
糞システムが翼システムにみえる。

615 :仕様書無しさん:04/03/30 17:07
オープンソースはドカタに負の遺産を提供した点で罪深い

616 :貧乏紙:04/03/30 17:07
さて今日は画像処理についてお前ら、かたれ!!!
仕様 480*480 RGB各8bit計24bitだ。 1K=1024byt 1M=1024Kbyt。
まず、水平1ピクセル3byt*480 1440byt
垂直480ピクセルで691200byt=675Kbyt。
1ピクセルはRGB各unsigned charの1文字で表せるので、1ピクセルは3文字のchar型構造体に置き換える。
そうすると
struct RGB{
unsigned char R;
unsigned char G;
unsigned char B;
}RGB_p[480][480];
とあらわせる。
圧縮はどう処理されるのか?
またJpeg200は非不可逆方式でありどう処理されるのか?
動画を扱うとき可変ビットは、時間列に対してどう処理されるのか?
また固定ビットは1枚の画(1/30秒)に対してビットが分割されるのかそれとも
1秒間内に指定されたビットに収めれば自由に30枚の画にビットを配分できるのか?
さあ、おまえらJavaでカタレ・・・

617 :仕様書無しさん:04/03/30 17:08
>>616
Javaはクロスプラットフォームなので高速描画はできません。
ポータビリティのために仕方ありません。

618 :仕様書無しさん:04/03/30 17:09
オラクルに詳しい人に質問。
確か最近のオラクルはストアドをJavaで書けるはずだけど、固定小数点はどうなってるの?
確か、あれのフィールドには固定小数点の型あるよね。PL/SQLにあったような記憶がある。

619 :仕様書無しさん:04/03/30 17:09
>>617
描画のお題じゃないんだけど・・・

620 :仕様書無しさん:04/03/30 17:10
>>616
Java厨にはDCTも知らないので無理。

621 :仕様書無しさん:04/03/30 17:11
ボラクルのJDBCドライバってどうしようもない糞だよな。
あれだったらオプソDBの方がはるかにマシ。

622 :仕様書無しさん:04/03/30 17:12
>>616
Javaは崇高なエンタープライズコンピューティングに使うので、画像処理には適しません。

623 :仕様書無しさん:04/03/30 17:15
>>621
素晴らしい

624 :仕様書無しさん:04/03/30 17:16
ドカタにもオプソの波が

625 :仕様書無しさん:04/03/30 17:19
ボラクルはODBCドライバも糞だったな。

626 :仕様書無しさん:04/03/30 17:21
OO4Oがある
Pro*Cってのもある

627 :仕様書無しさん:04/03/30 17:21
ADO.NET Managed Providerさえも糞だった

628 :仕様書無しさん:04/03/30 17:25
さ〜てそろそろ定時なので帰る準備するか。
ドカタの皆さん、深夜残業頑張ってね。w
残業代出ないけど。w

629 :仕様書無しさん:04/03/30 17:27
VC++からOCIを使ったこともある。やっぱり糞だった。

630 :仕様書無しさん:04/03/30 17:30
PBからだとOracleは楽なんだよな
環境が酷すぎるけど

631 :仕様書無しさん:04/03/30 17:32
5年くらい前に、PB+Oracleで納品したシステムの追加や改修の話が持ち上がったら嫌くない?w

632 :仕様書無しさん:04/03/30 17:39
PBのバージョンアップ時のアレは酷すぎなので、置換えだと思うけど
PB自身、導入実績稼ぎ云々があったので、お客とベンダーの力関係が発生するだろうね
開発関係者に環境を提案するだけの余地は低いと思うよ
PBだってドカタ環境だしね、名前からして。

PBって学生はあんまり知らないよね

633 :仕様書無しさん:04/03/30 17:41
もしかしてPBでググッてる?

634 :仕様書無しさん:04/03/30 17:42
カシオのポケットコンピュータですか?

635 :仕様書無しさん:04/03/30 17:44
すげー情報クローズだったな
NIFTYのフォーラムもライセンスコード打たないと入れなかったような記憶あり

636 :仕様書無しさん:04/03/30 17:46
PowerBuilderでしょ?VCばかり使ってたんでよく知らないけど。

637 :初代スレの1:04/03/30 18:27
タイトル変わってるじゃねーか、ヴォケ!

638 :仕様書無しさん:04/03/30 18:33
おまいが24時間張り付いてないからだよ

639 :仕様書無しさん:04/03/30 19:00
.netって名前が変わったり
下手すると消え去ったりするの?

640 :仕様書無しさん:04/03/30 19:17
名前が変わったり、名前が消え去ったりする可能性はある。
技術自体は今の所無くなる気配は無い。

まあいつかは無くなってその他の技術に置き換えられるだろうが、
今の所、代替に値する技術は無い。

641 :仕様書無しさん:04/03/30 19:23
MSはコロコロ名前変えるからな〜。
でも使われていることの基本はなかなか変わらなかったり。
あと、Ver3まで様子を見るのは基本ね。VJみたいな目にあう。

642 :仕様書無しさん:04/03/30 19:24
.NETもあと2回か1回のバージョンアップまでは、案件に使うのは待ったほうがいい。
調査・評価・実験は必要だけどね。

643 :仕様書無しさん:04/03/30 20:01
>>639
つうか、その場合に何を「.NET」と呼ぶか、という話が先。
そうでないと名前だけにだまされ続ける。

・最初はJava対抗で、複数言語間の共通ライブラリや稼働環境(CLR)の話だった
・ところがサーバー製品名に「.NET」を乱発し、単に製品シリーズ名として誤解が広がる
・最近は「XML WebServices」の事を何故か「.NET」と呼んでいる(Javaと見分けできず、不可解だが...)

644 :仕様書無しさん:04/03/30 20:04
>>643
もちっというと、最近の「.NET」は、
「MS製品を組み合わせてWebServicesするための取り組み全般」かね。

ActiveXが、後にはMSのInternet対応の取り組み全般を指したようにね。

645 :仕様書無しさん:04/03/30 20:09
MSの「.NET」に対して、Java陣営は多数なので、馴れないとなんだかわからん。
でも、昔のCOBOLやC/C++、UNIX各社と同じで、各社が競う形。

めんどうなら、それぞれ主流に乗れば、まず間違いない。
今ならIDEはeclipse、フレームワークはstruts。これで断定 (w
ただし選べるならSIerのフレームワークも手軽で良い。

あれがいい、これが凄いって言う人は多いけど、仕事で使って保守するなら、
実績が多くて大手を含めサポートが固いやつね。

646 :仕様書無しさん:04/03/30 20:12
・良くも悪くもMSと心中したい人:.NET
・自己責任で選択もあるが、競争が激しく手軽な世界:J2EE

647 :仕様書無しさん:04/03/30 20:16
>>645
>>492

648 :仕様書無しさん:04/03/30 20:22
Strutsって、いつまで保守されるのかなぁ。。。

649 :仕様書無しさん:04/03/30 20:27
http://pc5.2ch.net/test/read.cgi/tech/1076512706/l50

若いっていいよなあ。いい物を素直にいいと言えて。
このスレの疲れ切ったドカタや精神崩壊してるアホアンチを見てると可哀想になってくるよ。

650 :最凶VB厨房:04/03/30 20:31
最凶VB厨房死すともMS死せず。

651 :仕様書無しさん:04/03/30 21:25
将来のある若者をJavaの道に拉致するなんて、人としてとてもできない。
幸運なことに、彼らは.NETのイベントに出ていい刺激を受けてきたようだ。

652 :仕様書無しさん:04/03/30 21:28
おまいらさ、技術的なセキュリティの話する前に、
まずはポリシーを決めようぜ。

653 :仕様書無しさん:04/03/30 21:32
Sunが「Java Studio Creator」をようやく公開へ
http://www.itmedia.co.jp/enterprise/0403/30/epic01.html

> 「Microsoft系開発者を獲得するまでにはいかないが、Javaプログラマーの
> 離反を阻止する役割は果たすだろう」とオグレーディ氏はinternetnews.comの
> 取材で述べている。

ずいぶん弱気なコメントですね。w
離反が多いんですか?www

654 :仕様書無しさん:04/03/30 21:57
.NETの基本コンセプトすら理解できないVB厨にJavaは無理だろ。

655 :仕様書無しさん:04/03/30 22:08
アクロバチックな展開に

656 :仕様書無しさん:04/03/30 22:09
>>654
じゃあ聞くけど
.netの基本コンセプトを全て正しく理解してる奴なんているの?

657 :仕様書無しさん:04/03/30 22:44
>>656
M$によるVB厨囲い込み戦法

658 :仕様書無しさん:04/03/30 22:45
>>656
それはMS社内にもいない。中身がコロコロ変わるから。

659 :仕様書無しさん:04/03/30 22:46
今日はM$の下僕が大勢来たようですね。
こいつらのおかげで日本のソフトウェア産業は韓国にすら勝てないのですね。

660 :仕様書無しさん:04/03/30 22:49
>>647
StrutsとTapestryは、コンセプトも違うでしょ (w

StrutsはIBMとかもプッシュしてるし。
業務用には多少枯れてからがいいんだよ。


661 :仕様書無しさん:04/03/30 23:01
オプソマンセーでも企業のプッシュをありがたがっているJava厨。


662 :仕様書無しさん:04/03/30 23:45
「オプソ=反企業(反営利)」じゃないからなぁ。

いまだに「オプソ=共産主義」にしかみつくMS信者 > 661

663 :仕様書無しさん:04/03/30 23:50
今日のM$信者は必死だなw

664 :仕様書無しさん:04/03/30 23:52
どっちがw

665 :仕様書無しさん:04/03/30 23:55
MySQLなんか、営利企業が開発してるオプソなんだけどな...
オプソにするってのは、普及させるための手法だったりする。

自社技術を標準化して無償提供したり、特許を無料にするとか、
OSIでもIEEEでも、昔からよくある。

周辺技術に自身があれば、そっちで飯はくえるわけだ

666 :仕様書無しさん:04/03/31 00:09
玄人はWACsってことで。大手銀行とか大抵そうだな。

667 :仕様書無しさん:04/03/31 00:26
>>666
Web Application Components

668 :仕様書無しさん:04/03/31 00:34
>>667
実はStrutsより簡単に作れる

669 :仕様書無しさん:04/03/31 00:39
JavaGenericsってどうなんですかねぇ。
C++みてるとテンプレートって無駄に読みづらくなるだけな気がするんですけど・・・
まぁ色々メリットがあるのはわかるんだけど・・・
JGに備えてModernC++Designぐらいは買っとくべきなのかな?

670 :仕様書無しさん:04/03/31 08:53
私有財産を認めないのが共産主義

671 :仕様書無しさん:04/03/31 09:04
>>670
アホ

672 :仕様書無しさん:04/03/31 09:09
オープンソースの著しい特徴は、一般に所有を廃止することではなく、ブルジョワ的所有を
廃止するところにあるのです。しかし近代のブルジョワ的私的所有は、階級対立に、少数者
による多数者の搾取にもとづく生産と生産物の専有のシステムの、最後の、最も完成され
た表現なのです。

673 :仕様書無しさん:04/03/31 09:10
この意味で、オープンソースの理論は、私的所有の廃止という唯一つの文に要約できるかもしれません。

674 :仕様書無しさん:04/03/31 09:11
私たちオープンソースコミュニティは、人間の自分自身の労働の果実として財産を個人的に
獲得する権利を廃止したがってると非難されます。そういう財産があらゆる個人の自由、活動、
独立の基礎であると言われているのです。

苦労して得た、自分で獲得した、自分で稼いだ財産!あなたが言っているのは、小職人の、
小PGの財産、ブルジョワ的所有形態に先立つ所有形態のことではないでしょうか。
そんなものは廃止する必要がないのです。工業の発展が、既に広範囲に破壊しまったし、
また今でも日々破壊しているのです。

それとも、あなたは近代的なブルジョワ的私的所有のことを言っているのでしょうか。



675 :仕様書無しさん:04/03/31 09:12
しかし、賃労働は労働者になんらかの財産を作り出しているでしょうか。そんなことは決して
ありません。それは資本、つまり賃労働を搾取し、新たな搾取のために賃労働を新たに供給
するという条件の下でしか増加できないような財産を、作り出すのです。所有は、現在の形態
では、資本と賃労働の対立にもとづいているのです。この対立の両側面を検証してみましょう。

676 :仕様書無しさん:04/03/31 09:13
資本家であることは、生産においては、純粋に個人的な地位にではなく、社会的地位につく
ということなのです。資本は集団的な産物であって、社会の多くの成員の団結した行為によ
ってだけ、結局のところ、社会の全成員の団結した行為によってだけ、動かすことができるの
です。

だから、資本は個人的な力ではなくて、社会的な力なのです。

だから、資本が共有財産に、社会の全成員の財産に変えられると、それによって個人的所
有が社会的所有に変わることはありません。変わるのは所有の社会的性格だけなのです。
所有はその階級的な性格を失うのです。

さて、賃労働を見てみましょう。


677 :仕様書無しさん:04/03/31 09:15
PG労働の平均価格は最低の賃金、つまり労働者としてただ生存するのに絶対必要な
生計手段の量なのです。だから、PGが自分の労働によって専有するものは、むき出しの
生存を引き伸ばし、再生産するのに足るだけのものでしかありません。私たちは、この労働の
産物の個人的専有を廃止しようという意図は毛頭ありません。そういう専有は、人間の生活を
維持し再生産するためであって、それによって他人の労働を意のままにするような余剰を
のこさないからです。私たちが廃絶したいのは、この専有の惨めな性格なのです。
というのは、この専有の下では、PGはただ資本を増大させるためだけに生き、支配階級の
利害が必要とするかぎりでだけ、生きるのを許されているのですから。



678 :仕様書無しさん:04/03/31 09:16
ブルジョワ社会では、生きたPGは蓄積されたソフトウェアを増大させる手段にすぎません。

679 :仕様書無しさん:04/03/31 09:19
あなたは、私たちがソフトウェアの私的所有を廃止しようと意図していることに、ぞっとするで
しょう。しかし、あなたの現存する社会では、人口の十分の九にとっては、既にソフトウェアの
私的所有は廃止されているのです。ソフトウェアの私的所有がこの十分の九の人の手には
存在しないということによってだけ、少数者にソフトウェアの私的所有が存在するのです。
だから、あなたは、私たちが所有形態を廃止しようと意図していることを非難しますが、
それは社会の大多数はなんの所有もないということを存在の必要条件としている所有形態なのです。

680 :仕様書無しさん:04/03/31 09:23
要するに、あなたは私たちがあなたの所有を廃止しようと意図していることを非難してるので
す。まさにそのとおり。それこそが私たちの意図するところなのです。


681 :仕様書無しさん:04/03/31 09:25
オープンソースはは誰からも社会の生産物を専有する権限を剥奪しはしません。
こういう専有を使って他人の開発を服属させる権限を剥奪するだけなのです。

682 :仕様書無しさん:04/03/31 09:29
オープンソース党宣言でつか?

683 :仕様書無しさん:04/03/31 09:37
RMSは真性デムパだと思うが。
GPLはちっとも自由じゃない。
奴の嫌いなプロペラなんとかウェアに対抗する為の
RMSサイドの所有物じゃないか。



GPLのソフトは使うけどな。

684 :仕様書無しさん:04/03/31 10:50
           |
           |
           |
           |
     /V\  J
    /◎;;;,;,,,,ヽ
 _ ム::::(;;゚Д゚)::| ジー
ヽツ.(ノ::::::::::.:::::.:..|)
  ヾソ:::::::::::::::::.:ノ
   ` ー U'"U'

685 :仕様書無しさん:04/03/31 10:54
>>573
> ※ 連続投稿で利用者の会話を害しているものは削除対象になります。
すでにドカタ連呼しているヴァカが会話を害しているじゃん。

686 :仕様書無しさん:04/03/31 10:55
>>574-546
こいつらも荒らしの一種だね

687 :仕様書無しさん:04/03/31 10:58
年度末ドカタあげ

688 :仕様書無しさん:04/03/31 11:12
>>582
> ASP.NET2.0の方が魅力的だね
ASP.NETは魅力的ではない。
Model View Conteroller ArchitectureのうちView程度しか関与しないものは
所詮魅力的とは言えない。

これをもう一度良く嫁。
そうすればドットネットが魅力的でないことをよくわかる。
http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet

689 :仕様書無しさん:04/03/31 11:13
>>687は自称ドカタだそうです

晒し揚げ

690 :仕様書無しさん:04/03/31 11:13
C厨はオブジェクト指向を理解できない馬鹿だからドカタ作業しかできない

これ定説

691 :仕様書無しさん:04/03/31 11:23
ここは最近のjava事情についてのスレである。
javaはオープンソースでもGPLでもない。
よってここでオープンソースやGPLについて薀蓄をたれる、
ましてや連続コピペするのはスレ違いであり、
わかってやっているならスレ荒らし行為であり
わかってないでやっているならアホである。

692 :仕様書無しさん:04/03/31 11:24
>>599
> なんで金融関係にJavaとか言ってる奴がいるんだろう。
> 元々PC用パッケージソフト屋だったんで、COBOLに関する知識はほとんどないが、
> それでもJavaよりCOBOLのほうが向いていると思う。蓄積もあるしね。

http://www-6.ibm.com/jp/developerworks/java/040109/j_j-integrate.html
著者について
Srikanth Shenoyは大規模なJ2EEプロジェクトやEAIプロジェクトのアーキテクチャ、設計、
開発、展開などが専門。製造、運輸、金融などの分野の顧客に対し、
Javaの"write once, run anywhere" (一度作成すれば、どこでも実行可能)という夢の実現に尽力し
ていきました。Sun Certified Enterprise Architect (Sun認定、エンタープライズ設計者)であり、
共著でPractical Guide to J2EE Web Projects を出版予定。メールアドレスはsrikanth@srikanth.orgです


Nithin Mallyaは金融分野の顧客に対する企業レベルでの課題解決を専門として活躍。
主にJavaプラットフォームでの、サーバー側でのアーキテクチャ設計・開発に7年間の経験があります。
Sun Certified Enterprise Architectであり、またSun Certified Web Component Developer(Sun認定Webコ
ンポーネント開発者)でもあります。共著でPractical Guide to J2EE Web Projectsを出版予定。メールアド
レスはnithin@mallya.orgです。

693 :仕様書無しさん:04/03/31 11:25
>>691
Javaに関与することを誹謗中傷ヴァカも荒らしとして認定すべきである

694 :仕様書無しさん:04/03/31 11:26
>>691
Javaに関与することを誹謗中傷するヴァカも荒らしとして認定すべきである

695 :仕様書無しさん:04/03/31 11:26
>>693
日本語がおかしいぞ(w


696 :仕様書無しさん:04/03/31 11:28
>>694
javaに対する批判は当然このスレで扱う内容だろう?
最近のjava事情についてのスレなんだから。
javaにマンセーして崇めるスレにしたいのか?
その信者的感性が非常にキモイが。

697 :仕様書無しさん:04/03/31 11:29
>>688
君はMVCが何かということもよく分かってないようだ。
ここでも読んでおきなさい。常識だから。

http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/ImpMVCinASP.asp

698 :仕様書無しさん:04/03/31 11:29
>>600
> Javaは日付計算も糞だしな。
>
> Calendar.getInstance().add(Calendar.DATE, -1)

その程度のことで糞か。ならまお前の頭が糞だな。
Calendar#add()メソッドの仕組みも理解していないで糞だとはよくいえたものだ。

add()メソッドが一般の + 演算子と同様に振る舞われるとしたら大間違いだ。
もう一度数学を勉強し直して出直してこい。

C厨やCOBOL厨はじつに浅はかだ。




699 :仕様書無しさん:04/03/31 11:29
>>695
小僧、>>694を嫁

700 :仕様書無しさん:04/03/31 11:30
>>697
M$の社員は黙って死んでくれ。
M$信者のくせにMVCを語るとは生意気だ。

ブラウザ依存するサイトなんか紹介するなクズ。

701 :仕様書無しさん:04/03/31 11:32
>>700
生意気かどうかはどうでもいい。
君の発言は無知だと指摘したまでだ。
その言い分は自分の無知を認めたということだね。

702 :仕様書無しさん:04/03/31 11:34
所詮ドカタ言語Javaにパターンも糞もないよな。w

703 :仕様書無しさん:04/03/31 11:35
数値計算も日付計算もめんどくさいドカタ言語。
金融には致命的。

704 :仕様書無しさん:04/03/31 11:36
Javaはオープンソース拒否した糞言語。

705 :仕様書無しさん:04/03/31 11:38
sunはjavaでは全然儲かっていないからねぇ

706 :仕様書無しさん:04/03/31 11:39
しかし.NETにもパターンの波が来てるんだな。
本格的に普及し出した表れでもある。

707 :仕様書無しさん:04/03/31 11:39
>>599
> なんで金融関係にJavaとか言ってる奴がいるんだろう。
> 元々PC用パッケージソフト屋だったんで、COBOLに関する知識はほとんどないが、
> それでもJavaよりCOBOLのほうが向いていると思う。蓄積もあるしね。
お前はもはや固定観念と化石的思考しかもてない頭の古いチンカスのクズで低脳で
頭のわるいドカタ厨房だ。

金融系だからといって金融機関専用とも限らないことに気づかない低脳な>>599

http://salesgroup.fujitsu.com/financial/oversea/abc/j.html
Java,J2EE(Java 2 Platform Enterprise Edition)

海外の金融業界におけるITの活用事例についてアルファベット順の連載形式でご紹介しておりますが、
今回は「J」ということで"Java"ないし"J2EE(Java 2 Platform Enterprise Edition)"を取り上げてみます。
米国の金融サービス業界ではリテール分野のみならずホールセール分野においても、
EJB(Enterprise Java Beans)なども含めてこうしたJava開発言語を利用しながら、Internet やWeb に
関連する情報通信システム基盤を構築する動きが始まっています。今後は新たなビジネス・モデルの
具現化や既存の基幹システムの再構築など様々な目的で推進されるイニシアティブにおいてその多く
のパイロット・システムがJava関連技術を適用していくものと見込まれます。

708 :仕様書無しさん:04/03/31 11:41
>>701
どこが無知なんだろうな。
そうかただの煽り厨か


709 :仕様書無しさん:04/03/31 11:41
>>588
> これが低学歴の限界というやつか。(ワラ
> やはりドカタ以上のことに手を出さない方が賢明だ。

そうそう、低学歴のCOBOL厨どもやドトネト厨やC言語厨にはドカタ以上のことに手を触れさせない方が賢明だ。

710 :仕様書無しさん:04/03/31 11:42
こりゃまた古いところにレスつけたもんだな(w


711 :仕様書無しさん:04/03/31 11:43
機能のレスは全然古くないだろw

712 :仕様書無しさん:04/03/31 11:43
>>708
> Model View Conteroller ArchitectureのうちView程度しか関与しない

これが無知なんだけど自覚がないようだね。
基礎から勉強し直したら?

713 :仕様書無しさん:04/03/31 11:44
>>596
> 金融計算にJavaのBigDecimalは使えないよな。
> 演算子オーバーロードできるなら考えてもいいけど。

相変わらず話をループさせている低脳だな。
過去ログを嫁。
その話は、演算子は必要ないということで
すでに決着がつているだろが。

714 :仕様書無しさん:04/03/31 11:45
Javaで作ったシステムは5年もたない。
金融には無理。

715 :仕様書無しさん:04/03/31 11:46
>>712
ばっかじゃないの?
asp.netしかつかえないヴァカはほとんどがviewだけしかいじくり回せないのが現実ジャンw

716 :仕様書無しさん:04/03/31 11:46
>お前はもはや固定観念と化石的思考しかもてない頭の古いチンカスのクズで低脳で
>頭のわるいドカタ厨房だ。

まるでカタギとは思えぬモノのいい様。やはりこの気の荒さ、因縁のつけかた昔のドカタとしか...
組はどちらですか?

717 :仕様書無しさん:04/03/31 11:46
>>714
もっともつよw

718 :仕様書無しさん:04/03/31 11:46
>>592
> 最新の情報工学の成果を活かしたドカタ仕事とはこれ如何に。
最新の情報工学の成果を活かしたんならドカタ仕事とはいわないな、ドカタ文系大学出身君。

719 :仕様書無しさん:04/03/31 11:48
>>716
やっぱりチミは


固定観念と化石的思考しかもてない頭の古いチンカスのクズで低脳で
頭のわるいC言語ドカタ厨房


だったんだね(w

720 :仕様書無しさん:04/03/31 11:49
>>597
> ポインタも使えないJavaでどうやって柔軟なシステムを作れと?
馬鹿を言え、Javaにはポインタがあるとあれほど何度も散々言ったのに
まーーーーだ理解できないのかこの低脳のクズめ!
ポインタがあるからこそ、オブジェクト指向で柔軟なシステムつくれるんだよ。
ただのポインタがあるだけでオブジェクト指向をろくに使いこなせないC言語では柔軟なシステムを
構築することは無理だがな。


721 :仕様書無しさん:04/03/31 11:51
>>719
わたしゃ言語はなんでもいいですよ。もちろんCも使いますが。
javaにも興味あるんですけどね。別に特定の言語にこだわりは
ありませんね。


722 :仕様書無しさん:04/03/31 11:52
>>714
cobolが20年持ったからといって調子に乗りすぎ。
当時のcobol資産はオブジェクト指向が使われてないので
拡張性も再利用性もないだろw
そのうち徐々にJavaに追われるぞw


723 :仕様書無しさん:04/03/31 11:52
ポインタが使えないとか言い出すヤシがいるあたり、過去のVBスレとそっくりだ・・・

724 :仕様書無しさん:04/03/31 11:53
つーか、なんでjava信望者がそれほどC(あるいはC使い)を叩くのか
わかりませんね。使いどころが違う言語に思えますが。


725 :仕様書無しさん:04/03/31 11:53
>>721
ほいこれ嫁

適材適所で使い分けるのが効率的。
話題になる分野にことごとくむりやりPerl/VBを適用しようとするから、馬鹿と言われる。

と表現したほうがいかにも筋が通るとは思うだろw

Javaは何にでも話題にしやすい。
何せ多くのほとんどのコードがOSで動くからね。

家電、組み込み、サーバ、汎用機、金融、エンタープライズ、宇宙船
など将来の利用用途はさまざまだ。

これらの話題に分野でJavaの話がでても何もおかしくない。
そこでJavaが気に入らないからといってJavaを否定する香具師ほど馬鹿といわれる。
考え方が古い時代遅れな奴とすぐに言われる。
とくに、未来の話をしているにもかかわらず、いつまでたっても「Javaは遅い」といっている香具師も
もうそろそろ、化石的思考を持つ古い人と言われてもおかしくない。

726 :仕様書無しさん:04/03/31 11:54
>>724
> つーか、なんでjava信望者がそれほどC(あるいはC使い)を叩くのか
> わかりませんね。使いどころが違う言語に思えますが。
>

マ板ではJavaが人気が無い理由は
マ板の年齢層が高齢で頑固親父の巣窟だから、またはレベルが低いからだと思われ。

多くの人々がC/C++教育を受け、またはC/C++でインフラが整備されC/C++だけで満足してしまっている
傾向が強い。
しかし、C/C++は変化に弱い。
複数のOSにソフトウェアを対応させるとなるとOSの数だけ開発にかかる負担が増す。
インスタントラーメンのような即座に食べられるようなラーメンを食べたい者にはJavaは好かれない。

ソフトウェアを、将来、大木に成長する植物にたとえるならば
苗木から始まったソフトウェアを徐々に成長してゆく姿を見たい、楽しみにしている者にとってはJavaは
非常に好意の対象になる。

727 :仕様書無しさん:04/03/31 11:54
>>598
> Javaは遅い。
> フルネイティブでないプログラムは信用できない。
いまだのそういうことしか言えない奴は時代遅れ。
それで遅いならC#も遅い。Perl6も遅い。信用できに亜。
ポインタ演算の使い方をしっかり把握していないC厨に作らせたプログラムはもっと信用できないがな。


728 :仕様書無しさん:04/03/31 11:54
>>725
>>724 読んでくれ。


729 :仕様書無しさん:04/03/31 11:55
>>584
> 論破させれば話題を変えて
> ああいえば、こういう。
論破されているのはどっちだろう?
オブジェクト指向のことで論破されると即座に話題を変えようと逃げたのは
アンチオブジェクト厨のほうだ。>>419-420にたいして>>421が論破したが
ろくに反論しようともせず必死に話題をすり替えて逃げようとするドトネト厨、COBOL厨、C厨、Perl厨、
どいつもこいつも往生際が悪いドトネト厨、C厨、COBOL厨どもだ。
こいつらは死ななきゃ直らないんだろうかね。

> 話をループさせるから太刀が悪い。
おいおい、なんどもBigDecimalに演算子をつけろと言っている奴や
COBOLマンセー、ASP.NETマンセーといっているヴァカどもこそ
往生際が悪く話をループさせているじゃないか。
自分のことを棚に上げてなにいっているんだドトネト厨、ヴィビ厨、そしてC厨、COBOL厨、
C++厨、Perl厨、こいつは皆往生際が悪く、ああいえばこういう、そして話を何度もループさせている。
非常に太刀が悪い。

730 :仕様書無しさん:04/03/31 11:55
>>728
>>726 読んでくれ

731 :仕様書無しさん:04/03/31 11:56
>>585
> Javaがつかえない、ドカタ、とか言ってる奴は、オブジェクト指向、デザインパターン等の
> 最新の情報工学の成果を理解出来ないオッサンだろ。
最新かどうかはしらんがそれらの技術を理解していないことは確かだな。

732 :仕様書無しさん:04/03/31 11:57
>>730
>>726は答えになっていないと思う。少なくともCを叩く理由にはなっていないよね。

733 :仕様書無しさん:04/03/31 11:59
>>599
> なんで金融関係にJavaとか言ってる奴がいるんだろう。
> 元々PC用パッケージソフト屋だったんで、COBOLに関する知識はほとんどないが、
> それでもJavaよりCOBOLのほうが向いていると思う。蓄積もあるしね。


734 :仕様書無しさん:04/03/31 12:00
>>729
オブジェクト指向、デザインパターンが
どの局面でも有効とは言えないだろう。
そういうものが有効ではない局面で使い勝手の悪さを
他者は批判しているのでは?




735 :仕様書無しさん:04/03/31 12:01
>>732
444 名前:仕様書無しさん 投稿日:04/03/30 13:51
見れば分かる通り,各メソッドの記述自体はC言語に類似.
(Cは有名なだ けに多かれ少なかれCの影響を受けた言語は他にもある.
C++, Objective-C辺 りは露骨にそうだし,間接的にだがPerl,Rubyもそうらしい.
言語じゃないけ どcsh/tcshなども多分そう.C#はJavaの猿真似かね.やっぱり...)

●表記は似ていても,C言語とは流石に時代が違うので様々な点で異なっている.
●オブジェクト指向:Javaはオブジェクト指向言語だが,C言語はもちろん 違う.
●int型:同じ符合付固定小数点数でも,Cでは「ハードウエアにとって最も
 普通のサイズ」なのに対しJavaでは「32bit」と定められている.
●char型:Cでは8bit配列であり,それ以上の文字コードは言語レベルでは
 サポートできない.JavaはUnicode(16bitコード)なので,多文字言語にも一応 対応できる.
●ポインタと参照:ポインタ型はアドレスを持った変数.即ちハードウエア
 に依存した仕様になっている.Javaの参照はインスタンスを参照するもの.ハー ドや実装とは無関係.
●NULLとnull参照:C言語においてはNULLはプラットフォーム依存の定数.
 実際の値は多くの場合は0であるが,仕様ではないため0以外の可能性もある.
 問題なのはポインタpを"if( p == 0 )"で条件判定したり,数値演 算に使ってもエ
 ラーにならないこと.Javaではnull参照と0とは別の型であり セマンティクス上別
 のものであるため,参照と数値で比較したり参照を数値演 算に利用するとエラーになる.

736 :仕様書無しさん:04/03/31 12:02
>>734
だから適材適所だといってるのに。

有効でないといっているヤシはほとんど組み込み系のみ

737 :仕様書無しさん:04/03/31 12:02
オブジェクト指向は大昔からある
デザインパターンも大昔からある(1994に、それぞれに名前が付与されただけ)
双方とも、最新でもないし、情報工学でもない

738 :仕様書無しさん:04/03/31 12:03
>>735
どこが(java使いの立場で)Cを叩く理由なの?
コピペが多いけど何がいいたいのかよくわからない。

739 :仕様書無しさん:04/03/31 12:04
C++とJavaの比較
http://www.infotek.co.jp/java/c_j1.html


740 :仕様書無しさん:04/03/31 12:06
>>739
どこが(java使いの立場で)C++を叩く理由なの?
引用では何がいいたいのかよくわからない。


741 :仕様書無しさん:04/03/31 12:06
>>737
ソフトウェア工学は情報工学のカテゴリーに入るぞ。
すくなくともオブジェクト指向なしでソフトウェア工学は語れない。

742 :仕様書無しさん:04/03/31 12:07
>>740
なんでもかんでもたたき扱いするおまいの思考がわからない。
ただの比較なのに

743 :仕様書無しさん:04/03/31 12:08
>>742
スレの流れと脈絡無く、java|c++の比較を貼る君の思考がわからない。
いったいどうせよというの?


744 :仕様書無しさん:04/03/31 12:10
>>587
> OOごときが最新とはかなり斬新な意見だ。
ま、すくなくともC厨が好きな構造化手法オンリーよりも斬新だなw

745 :仕様書無しさん:04/03/31 12:12
>>744
そこにC厨を引き合いに出す君の思考がわからない(w

746 :仕様書無しさん:04/03/31 12:12
適材適所でいいんじゃないの?

747 :仕様書無しさん:04/03/31 12:13
Cって死滅しちゃうの?
http://pc5.2ch.net/test/read.cgi/tech/1040328020/

748 :仕様書無しさん:04/03/31 12:13
>>746
>>725でガイシュツ

749 :仕様書無しさん:04/03/31 12:14
>>580
> やはり.NETぐらいが現実的なベストバランスだ
名前を.NETに下だけで中身は従来のWin32とさほど変わらないドトネト。
とても現実的でもない。サーバ用途に使うには非現実的ワーストバランスだ。

Win32 APIの焼き増しドトネトは現実的ではないし、もはや古い。

これをもう一度良く嫁。
そうすればドットネットが現実的でないことをよくわかる。
http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet

750 :仕様書無しさん:04/03/31 12:14
適材適所、使いどころが違う。
なのになぜかCを持ち出し比べて叩くjava厨。
そこがわからない(w


751 :仕様書無しさん:04/03/31 12:16
>>749
こりゃまた古いところにレスつけたもんだな。
都合がわるくなるとこうするのな(w
ワンパ。ループ。エンドレス。

752 :仕様書無しさん:04/03/31 12:16
http://java-house.jp/ml/topics/topics.html#general-linguistics

比較言語論
K&Rにいまだに「ポインタを使うほうが一般に高速であるが」なんて書いてあるのは有害 [j-h-b:28534]
「不幸だったのは1990年代前半あたりで誰もがC言語を学ばざるを得なくなってしまったこと」 [j-h-b:28627]
C/C++に対する恨みと擁護 [j-h-b:28628]

753 :737:04/03/31 12:17
>>741
ああ失礼。筆が滑ってしまった
#最初から「ソフトウェア工学」って書いてくれればいいのに

754 :仕様書無しさん:04/03/31 12:19
>>752
ただのjava厨の愚痴を持ち出されても(w

755 :仕様書無しさん:04/03/31 12:20
>>754
どこにJava厨の愚痴がかいてあるんだろうw ノイローゼですか?

756 :仕様書無しさん:04/03/31 12:21
>>696
> >>694
> javaに対する批判は当然このスレで扱う内容だろう?
批判だけでは駄目だ。しかも、このスレでウザイことを言っている馬鹿どもは
批判ではなくJavaに関することを無闇に非防虫要しているに過ぎない。
ただのスレ荒らし。

> 最近のjava事情についてのスレなんだから。
> javaにマンセーして崇めるスレにしたいのか?
> その信者的感性が非常にキモイが。
だれがそんなスレにしろといったのか。

そうではない。Javaをどうやってつかうか、将来のJavaについて語るスレだ。

757 :仕様書無しさん:04/03/31 12:21
>>755
http://java-house.jp/ml/
ってのはjava厨が溜まって愚痴を並べるところでしょ?違うの?

758 :仕様書無しさん:04/03/31 12:21
>>751
> >>749
> こりゃまた古いところにレスつけたもんだな。
> 都合がわるくなるとこうするのな(w
> ワンパ。ループ。エンドレス。
それどうみても違うだろ

759 :仕様書無しさん:04/03/31 12:22
>>757
おまえ、やヴぁいよ。とんでもないものを敵にまわしてるんじゃないんか

760 :仕様書無しさん:04/03/31 12:23
>>756
こりゃまた古いところにレスつけたもんだな。
都合がわるくなるとこうするのな(w
またまたワンパ。ループ。エンドレス。


761 :仕様書無しさん:04/03/31 12:23
>>756
えっ・・・・・。そうだったのかぁ

762 :757:04/03/31 12:24
本音言うとちょっとドキドキしてま〜す。
大丈夫か?>俺(w

763 :仕様書無しさん:04/03/31 12:35
しかしJavaの今後の楽しみって何だろうね。
技術的にはもうネタがないような。

764 :仕様書無しさん:04/03/31 12:37
>>763
.NETをパクる一大仕事があるぞ

765 :仕様書無しさん:04/03/31 12:37
>>763
今後の楽しみは糞Javaシステムの保守があるだろ

766 :仕様書無しさん:04/03/31 12:38
>>763
演算子オーバーロードの追加

767 :仕様書無しさん:04/03/31 12:39
Sunの大風呂敷を生暖かく見守りますが、何か?

768 :仕様書無しさん:04/03/31 12:39
>>763
$unの倒産

769 :仕様書無しさん:04/03/31 12:42
来年度はJavaデフレ元年になるだろう

770 :仕様書無しさん:04/03/31 12:45
Javaドカタの単価はもう上がりません

771 :仕様書無しさん:04/03/31 12:49
来年度は仕事にありつけないJavaドカタが増えるんだろうなあ。
俺の知ってるところも良くて単価据え置きだもん。

772 :仕様書無しさん:04/03/31 12:51
客がJavaの品質の悪さに気付いたのと、Javaドカタのレベルの低さに気付いたのが敗因。

773 :仕様書無しさん:04/03/31 12:52
今日で契約が切れるJavaドカタが多いんだろうね。w

774 :仕様書無しさん:04/03/31 12:55
哀れな使い捨てJavaドカタ

775 :仕様書無しさん:04/03/31 12:57
Javaドカタって死滅しちゃうの???

776 :仕様書無しさん:04/03/31 12:58
最近のJavaドカタ人気について

777 :仕様書無しさん:04/03/31 13:00
明日からJavaドカタの単価も税込価格で表示しなければなりません。

778 :仕様書無しさん:04/03/31 13:14
年度が変わっても叩き売りされて使い捨てられるのがJavaドカタ

779 :仕様書無しさん:04/03/31 13:27
書き込みが減ったな。
Javaドカタも派遣先の撤収準備で忙しいようだ。w

780 :仕様書無しさん:04/03/31 13:51
今日でJava案件ともおさらばだ。
二度と関わりたくない。

781 :仕様書無しさん:04/03/31 13:53
ほんとドカタから足洗わないと精神崩壊するよ。
もっと人間らしい開発案件はJava以外なら確実にあるよ。

782 :仕様書無しさん:04/03/31 15:21
Javaドカタも燃え尽きてしまった模様。

783 :仕様書無しさん:04/03/31 16:00
年度末ドカタが検収を受けられないことが判明して、一気に爆発したようだな。Java信者

784 :仕様書無しさん:04/03/31 16:05
あなたは、私たちがソフトウェアの私的所有を廃止しようと意図していることに、ぞっとするで
しょう。しかし、あなたの現存する社会では、人口の十分の九にとっては、既にソフトウェアの
私的所有は廃止されているのです。ソフトウェアの私的所有がこの十分の九の人の手には
存在しないということによってだけ、少数者にソフトウェアの私的所有が存在するのです。
だから、あなたは、私たちが所有形態を廃止しようと意図していることを非難しますが、
それは社会の大多数はなんの所有もないということを存在の必要条件としている所有形態なのです。

要するに、あなたは私たちがあなたの所有を廃止しようと意図していることを非難してるので
す。まさにそのとおり。それこそが私たちの意図するところなのです。

オープンソースはは誰からも社会の生産物を専有する権限を剥奪しはしません。
こういう専有を使って他人の開発を服属させる権限を剥奪するだけなのです。

785 :仕様書無しさん:04/03/31 16:11
検収も何も、ドカタがプロジェクトの最後まで居られるわけがないじゃん。
結合フェーズに入ったら即ポイ捨て。
代わりはいくらでもいるから。w

786 :仕様書無しさん:04/03/31 16:26
ドカタは大変だね。

787 :仕様書無しさん:04/03/31 16:27
M$の犬どもが。
ちょっと考えれば分かるような宣伝にだませれ、レベルの低い、糞M$製品を盲信し、
ゲイシが私腹を肥やすのに利用され、献身的に働く低脳奴隷どもよ。

お前らのおかげで日本のソフトウェア開発現場はこのザマだ。氏ね。

788 :仕様書無しさん:04/03/31 16:28
わしは生まれてこのかた、だませれたことは一度もないぞ。

789 :仕様書無しさん:04/03/31 16:30
>>787
M$に騙されつつ開発者として人間的な生活を送るのと、
反M$気取りでJavaドカタになって精神崩壊するのと


  ど  っ  ち  が  幸  せ  ?

790 :仕様書無しさん:04/03/31 16:31
Javaドカタだけは勘弁。

791 :仕様書無しさん:04/03/31 16:31
どっちもいやーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー!

792 :仕様書無しさん:04/03/31 16:34
何でだろうね?

.NET開発者もそれほど単価が高いとは言えないけど、
Javaみたいに火噴いてるところは見かけないね。
それに使い捨てなんてひどい話も聞かない。

Java陣営は反M$を盾に人を騙そうとしてるんだね。

793 :仕様書無しさん:04/03/31 16:35
Javaドカタは明日から仕事どうするの?
.NETでも勉強したら?

794 :仕様書無しさん:04/03/31 16:36
春はJavaドカタから卒業の季節

795 :仕様書無しさん:04/03/31 16:38
明日から優秀な新人がやって来るぞ。
チミたちJavaドカタも負けないよう頑張りなさい。
まあ、若さと柔軟さでは勝てないだろうけど。www

796 :仕様書無しさん:04/03/31 16:39
今日のブビ厨はなんだか必死だな。

797 :仕様書無しさん:04/03/31 16:40
優秀な新人には設計を教え込みます。
Javaドカタの皆さんは言われるがままにそれを作ってください。
単価は新人の方が高いけどモチベーションを保って頑張りたまえ。w

798 :仕様書無しさん:04/03/31 16:45
新人には.NETを教え込むよ。いや、マジで。
教育が楽だし、後でJavaに行くなり身の振り方の融通も利くし。

799 :仕様書無しさん:04/03/31 16:47
言語、各種フレームワークの知識、及びそれらの各種バージョンの差異と組み合わせる時の
ノウハウなど、javaで要求されるスキルは、M$のバカチョンカメラとは比較にならない。
プロ用の一眼レフカメラなのだ。どちらがドカタであるかは一目瞭然。
おまいらは自分自身がドカタにすぎないとうすうす気づいているからドカタを連呼するんだろ?

Javaはブビのように日雇い労働者でも扱えるような代物ではない。
高度なスキル、プロフェッショナルこそが使える。お前らと一緒にするなよw

800 :仕様書無しさん:04/03/31 16:48
>>799
> javaで要求されるスキルは、M$のバカチョンカメラとは比較にならない。

だから新人の教育には.NETを使うべきだね。

801 :仕様書無しさん:04/03/31 16:48
Java使ったぐらいで高度なスキルとか思っちゃっているイタイ>>799がいますね。

802 :仕様書無しさん:04/03/31 16:49
.NETが馬鹿でも使えるなら新人でも使える。
しかし、これは使う奴は皆馬鹿という理屈にならないのは既出の議論。
今年の新人には.NETを。

803 :仕様書無しさん:04/03/31 16:51
将来ある有望な新人をJavaドカタにするなんて倫理的に許されない。
彼らには.NETを覚えてもらって来たるべきLonghorn時代に活躍してもらわなければならないのだ。

804 :仕様書無しさん:04/03/31 16:53
Javaドカタはほんと今後どうするよ?
新人がバリバリASP.NETでWebServiceなんてやられた日には。

805 :仕様書無しさん:04/03/31 16:57
新人はVB6すら知らない世代だろ。おー怖。
まっさらの状態に.NETを教え込めばほんと伸びるだろうなー。
Javaドカタ世代はもう要らないね。

806 :仕様書無しさん:04/03/31 16:58
Javaドカタは反面教師として1匹だけ残せばいいよ。www

807 :仕様書無しさん:04/03/31 16:59
Javaドカタをリストラして社会の厳しさを教え込まねば

808 :仕様書無しさん:04/03/31 17:02
死んだ目をしたJavaドカタは新人さんには見せられないね。

809 :仕様書無しさん:04/03/31 17:16
彼らは何故ドカタという言葉にここまで過剰反応するのだろう。
これは何を示唆しているのであろうか。

810 :仕様書無しさん:04/03/31 17:17
Java使いがドカタ扱いされてることが現実に他ならないからでしょう。

811 :仕様書無しさん:04/03/31 17:18
おいらはフレームワークを開発している社員PGだよ。
残念だったな。派遣どかちんどもwww

812 :仕様書無しさん:04/03/31 17:19
Java使い以外に「ドカタ」という言葉が似合う言語は存在しない。
悔しいがこれだけは勝てないな。w

813 :仕様書無しさん:04/03/31 17:20
>>811
ドカタフレームワーク、略してD-FX開発ご苦労様です

814 :仕様書無しさん:04/03/31 17:22
契約切れのドカタはそろそろ派遣先から(・∀・)カエレ!

815 :仕様書無しさん:04/03/31 17:47
>>814
そんなこと言うなよ。
ドカタも人間なんだから。
ドカタにはドカタなりのプライドがあるわけで。

816 :仕様書無しさん:04/03/31 17:56
Javaドカタの皆さん、2003年度はどんな年でしたか?
来年もこの調子で食べていけると思いますか?

817 :仕様書無しさん:04/03/31 18:09

>>594
COBOL派遣、ドトネト派遣は最新の経営学の成果です。
の間違いだろw

818 :仕様書無しさん:04/03/31 18:12
>>764
> >>763
> .NETをパクる一大仕事があるぞ
パクっているのはむしろドトネトのほう。


819 :仕様書無しさん:04/03/31 18:21

>>617
あふぉいえ、BufferedImageクラスみたいなもんを使って高速化できないこともない。
あとはアルゴリズム次第

>>620
さすがにそういう香具師は少ない。
どうせお前はWavelet変換も知らないんだろ

820 :仕様書無しさん:04/03/31 18:24
>>813
> >>811
> ドカタフレームワーク、略してD-FX開発ご苦労様です
ドカタフレームワークというのは、

マイクロソフトが開発した、ドカタネットフレームワークのことです。

821 :仕様書無しさん:04/03/31 18:25
>>804
> Javaドカタはほんと今後どうするよ?
> 新人がバリバリASP.NETでWebServiceなんてやられた日には。

ドカタはこのすれにはいないよ

「ウェブサービスに最適な開発言語はJava」
http://pc3.2ch.net/test/read.cgi/prog/1068137711/


822 :仕様書無しさん:04/03/31 18:28
やはり天罰を下すべきだったかドカタドトネト厨どもには。

Javaがマイクロソフトドットネットよりも優れている101の理由

101 Reasons Why Java is Better than .NET
http://www.manageability.org/manageabilityWiki/WhyJavaIsBetterThanDotNet

823 :仕様書無しさん:04/03/31 18:30
1. No Proprietary APIs - Any Java public apis are part of the public domain,
.NET apis are proprietary and can open the door to a law suit.

2. Source Code You Can Legally See - Java source code for the core
libraries are available in every J2SDK distribution, .NET sources can only
be seen by resorting to illegal means.

3. .NET Purity is a Myth - Java promotes 100% pure Java libraries, for
.NET purity is nothing more than a myth.

4. 75% of the Enterprise Use Java - Avoid becoming one of the 25% of "use-less" employees.

5. Majority of Programmers Prefer Java over .NET for WebServices - Despite billions spent by
Microsoft in marketing, surveys continue to reveal that Java is the preferred platform when
it comes to Web Services.

6. Superior Web Development Frameworks - ASP.NET is a poorly designed and
crippled framework as compared to the richness of frameworks found in Java.

7. Stored Procedures - Most relational databases support writing of stored procedures
in the Java language. There has yet to be a production release of a database that
supports any .NET languages.

8. Experienced Practitioners - Nobody seems to know how to write .NET programs
well and that's giving .NET a bad name! A pretty lame excuse I must say!

9. Innovative Open Source Organizations - Open Source communities that support
distributed development are a plenty in the Java world.

10. Proven Security - 2 Years after Trust Worthy initiative is launched and we
collectively loose $55 billion last year.

824 :仕様書無しさん:04/03/31 18:30
11. No Lizard Brain - .NET programmers continue to struggle with the
complexities of a hybrid managed/unmanaged environment.

12. More Languages on the JVM - The JVM is more "common" than the CLR.

13. Smaller Runtime Download - You can't run your app if you don't have the runtime.

14. No Mandatory Upgrade Fees - 3 things a Microsoft shop can't avoid: Death, Taxes and License 6.

15. More Vendor Choices - .Net is a marketing program. Java is a Market.

16. Better Collection Classes - The .Net libraries look like
they were designed by high-school students, First year CompSci? students at best.

17. Future Proof - The way to ensure your return on investment (i.e. ROI) is that your choice of
platform doesn't get obsolete in 5 or even 10 years. Avoid the Microsoft upgrade treadmill!

18. Larger Talent Pool - Majority of Universities not only teach but require knowledge of Java.
That's a big talent pool that you need to consider before you off-shore your project to
a different time-zone.

19. More Contributions from Research Institutions - Research institutions and universities
have consistently provided innovative research not only built on top of Java but also
contributing to Java.

20. U.S. Government Approved - Guess where the billions of dollars spent
on the U.S. government's IT renovation is going to?



825 :仕様書無しさん:04/03/31 18:34
21. No Evil Type Coercion - Some C++ constructs are meant to be entombed forever,
.NET resurrects them with disastrous consquences.

22. Mature O/R Mapping Solutions - You can't beat the wealth of O/R mapping
solutions found in Java.

23. Superior Coding Tools - Like having your own personal Java fairy dancing through your code,
anticipating your every thought and keystroke.

24. Sane Coding Conventions - I don't know what's worse Hungarian notation or .NET
coding conventions.

25. Higher Paying Jobs - Somehow you've got to afford those skyrocketing housing prices don't you?

26. Better Support for P2P - Gnutella and JXTA, anything else legally more pervasive?

27. 100% Pure Java RDMS - Can't beat the ease of installation when the
RDMS is Java based and packaged with the application in a .zip file.

28. More Robust Exception Handling - .NET has no analog to the throws clause in method signatures.

29. Open Source Structured Graphics - When going beyond forms and windows, Java can't be beat.

30. Reusable IDE Frameworks - Why re-invent the wheel?
Start building your killer GUI application on top of killer IDE frameworks.


826 :仕様書無しさん:04/03/31 18:36
>>645
> MSの「.NET」に対して、Java陣営は多数なので、馴れないとなんだかわからん。
> でも、昔のCOBOLやC/C++、UNIX各社と同じで、各社が競う形。
>
> めんどうなら、それぞれ主流に乗れば、まず間違いない。
> 今ならIDEはeclipse、フレームワークはstruts。これで断定 (w

strutsだけで何ができると思っているのかこのアフォは。



827 :仕様書無しさん:04/03/31 18:39
>>653
> ずいぶん弱気なコメントですね。w
> 離反が多いんですか?www
それこそ随分昔の話だろうな。Javaに精通している者が簡単にVS.NETに移行するケースはごく稀。
離反するのは初心者。とくにお前らがドカタだ派遣だといっているようなJava初心者が
VS.NETに逃げるだろうな。

828 :仕様書無しさん:04/03/31 18:39
言語、各種フレームワークの知識、及びそれらの各種バージョンの差異と組み合わせる時の
ノウハウなど、javaで要求されるスキルは、M$のバカチョンカメラとは比較にならない。
プロ用の一眼レフカメラなのだ。どちらがドカタであるかは一目瞭然。
おまいらは自分自身がドカタにすぎないとうすうす気づいているからドカタを連呼するんだろ?

Javaはブビのように日雇い労働者でも扱えるような代物ではない。
高度なスキルを備えたプロフェッショナルこそが使える。
おまいらと一緒にするなよw

829 :仕様書無しさん:04/03/31 18:40
>>665のいうとおり、技術的なソフトウェアはオープンソースのほうが普及は速い。


830 :仕様書無しさん:04/03/31 18:42
>>651
将来のある若者を.NETの道に拉致するなんて、人としてとてもできない。
幸運なことに、彼らはJava/Linuxのイベントに出ていい刺激を受けてきたようだ。

このほうがしっくりくる。


831 :仕様書無しさん:04/03/31 18:42
>>651
将来のある若者を.NETの道に拉致するなんて、人としてとてもできない。
幸運なことに、彼らはJava/Linuxのイベントに出ていい刺激を受けてきたようだ。

このほうがしっくりくる。


832 :仕様書無しさん:04/03/31 18:43
もちつけ!

833 :仕様書無しさん:04/03/31 18:43
>>622
> >>616
> Javaは崇高なエンタープライズコンピューティングに使うので、画像処理には適しません。

こういういい加減なことをいうドトネト厨は死にたまえ。
Javaは汎用性がたかいのでそういう限定的なようとにしかつかえないということはない。
ちゃんと画像処理用クラスライブラリが用意されている。


834 :仕様書無しさん:04/03/31 18:44
>>645
> MSの「.NET」に対して、Java陣営は多数なので、馴れないとなんだかわからん。
> でも、昔のCOBOLやC/C++、UNIX各社と同じで、各社が競う形。
>
> めんどうなら、それぞれ主流に乗れば、まず間違いない。
> 今ならIDEはeclipse、フレームワークはstruts。これで断定 (w

strutsだけで何ができると思っているのかこのアフォは。

835 :仕様書無しさん:04/03/31 18:44

31. More Parser Building Tools - Want to build a new language,
well you'll need some robust parser building tools.

32. Aspect Oriented Programming - The next advance in modular software development,
get a head start by using Java.

33. 100% Pure Java Web Servers - Customizations and extensions are easier in a web
container that's built using the same language as applications.
Furthermore, managed environments support better reliability and security.

34. Extensible Java Compilers - Your tools have got to be able to parse the code
before it has any chance in understanding it.

35. Distributed Caching - Sometimes embarassingly parallel applications aren't the only
things that you need to scale.

36. More Reliable Messaging Choices - Java provides more choices for the backbone
that integrates the Enterprise.

37. Faster Development Turnaround - Incremental compilation is unavailable in the .NET environment.

38. Lightweight Persistence - Sometimes a relational database (RDMS) has too big a footprint.

39. Community Process - How does one contribute to the specification of standards?

40. Hardware Accelerators - Performance boosting hardware


836 :仕様書無しさん:04/03/31 18:47
>>669
> JavaGenericsってどうなんですかねぇ。
> C++みてるとテンプレートって無駄に読みづらくなるだけな気がするんですけど・・・
JavaGenericsはC++のtemplateとは異なる。
Javaのほうが型安全性が高く高度に堅牢性の高いプログラミングできるようになる。
JavaGenericsでは、C++のような読みにくいコードは作りにくいようになっている。
Genericsは、コレクション系フレームワークで本領を発揮する。
数多くのデザインパターンを適用するときにも大いに役立つ

837 :仕様書無しさん:04/03/31 18:48
>>672
> オープンソースの著しい特徴は、一般に所有を廃止することではなく、ブルジョワ的所有を
> 廃止するところにあるのです。

商用Unixは数百万以上もしておきながらオープンソースソフトウェアを使っているわけだが。
Unixサーバはブルジョワ的所有だろ。



838 :仕様書無しさん:04/03/31 19:00
>>763
> しかしJavaの今後の楽しみって何だろうね。
> 技術的にはもうネタがないような。

ある。P2PのJxta
家電製品に搭載されるJini,
携帯端末の進化に伴うJavaの組み込み系へのさらなる浸透。
(これで徐々にC言語が組み込み系で使われる可能性が下がってくる。)
リアルタイムJava,
Java Communication API,
Java Card API
火星探査機。
Java Web Start
AutoID(バーコードの後継)対応Java API

Jakarta Tapestry
JBoss
Eclipse3.0
Jakarta Commons

Javaによる遠隔操作。
Javaで制御するロボット。

839 :仕様書無しさん:04/03/31 19:01
>>706
> しかし.NETにもパターンの波が来てるんだな。
> 本格的に普及し出した表れでもある。
パターンはVC++のころからすでにあるぞ。
しかしまともに使い粉外努力する香具師がいなかったのと
Win32 APIのような標準APIがパターンで実装されていなかったという問題があった
ためにパターンが普及していなかったわけだが。あとからSTLが登場してももう手遅れと
上のほうのだれかのレスにそうかいてあるように。

840 :仕様書無しさん:04/03/31 19:04
>>762
Java House Mailing Listで
このスレのアンチJavaのような馬鹿どものように愚痴をこぼそうとする
徹底的に叩かれるぞ。愚痴はそれこそこのスレ、この板、マ板のほうが断然多い。
このスレの馬鹿どもがやっているような自作自演も通用しないんだからな。


841 :仕様書無しさん:04/03/31 19:04
41. Licensing Options - Ultimate flexibility in licensing.

42. Embedded Device - Java inside small packages.

43. Faster Virtual Machines

44. MickrokernelArchitectures

45. ContinuousBuild

46. Whole Program Optimization - Please sir may I have a linker?

47. Comprehensive RDMS Driver Support - Can you find a ADO.NET driver for an open source database?

48. Superior Code Analysis Tools

49. Unsurpassed Network Connectivity - Why is MSN managed by a Java based tool?

50. More Garbage Collection Options


842 :仕様書無しさん:04/03/31 19:12
51. ReliabilityConcerns

52. Better Web Services Interoperability

53. Better Domain Specific Languages Support

54. Painless Upgradability

55. Simple Side By Side Execution

56. More Business Rules Engines

57. Lightweight Containers

58. Better Business Process Management

59. Sixty Four Bit Support

60. Millions Of Java Phones

843 :仕様書無しさん:04/03/31 19:31
61. Garbage Collect Classes - The only way to unload MSIL code is to unload an entire application domain.

62. More Alternative VM Implementations

63. Hard Realtime Capabilities

64. Cross Platform Language Integration

65. More Extensive XML Support

66. Better Support For Dynamic Distributed Systems

67. Superior 2D Drawing

68. Better GUI Framework

69. SuperiorBranding

70. No Anti Open Source Agenda

844 :仕様書無しさん:04/03/31 20:14
今ビデオ見てるんだけど、やっぱ海上自衛隊ってカッコ良いわ。

845 :最凶VB厨房:04/03/31 20:18
一番かっこいいのはVB使い

846 :仕様書無しさん:04/03/31 20:28
Java厨の嫉妬は凄まじい

847 :仕様書無しさん:04/03/31 20:54
Java厨に嫉妬するものなんてありません。
逆にJava厨はメモリ管理が簡素化されて嫉妬されまくりです。


848 :仕様書無しさん:04/03/31 20:56
自分でmallocしたものは、自分でfreeする。
そんなことすら忘れるようではアルツハイマーじゃないでしょうか。

849 :仕様書無しさん:04/03/31 21:19
Java厨にドライバ作らせたら・・・・
考えただけでもぞっとする。
この世の終わりだ。

850 :仕様書無しさん:04/03/31 21:49
>>849
C厨にとっては終わりさ。
今までの苦労をJava厨によって否定されるんだから。

Jiniの普及によって。ドライバもJavaで作れる日がそのうちやってくる。
Jiniが普及すればC厨の仕事は徐々に減るか、
Javaの仕事をやらされる羽目になるだろうな。

そこで、C厨がJavaをやり出したとき、
いつもなら出ないはずのコンパイルエラーがやたらと出まくりで
今まで自分がいかにしてバグが多いプログラミングをしてきたかがよく
解ってしまうのさ。


851 :仕様書無しさん:04/03/31 22:03
>>848
大規模化してくるとfreeするタイミングが難しいだろ。
っていうか今時freeかよ。delketeじゃねえのかよ。
C++くらい使えよ。

ガーベッジコレクタを使うと遅くなるというが、D言語の仕様書をみても
解るとおり、逆に速くなることもあるぞ。
あるサイトにアクセスするたびにログイン、ログアウトを繰り返すことは
馬鹿馬鹿しいだろ。アクセスしたらセッションタイムアウトになるまでログアウトしないように、
ガーベッジコレクタは、ある条件に従ってあるところまでメモリが消費されるまで
解放をしないんだよ。

一応、Javaでも自分でfreeらしきことをできないこともないぞ。
一つがSystem.gc()を使うことだが、お勧めはできない。

もう一つは、java.lang.ref.Referenceインターフェースを使うことだ。
これでnullになったオブジェクトをメモリから解放する優先度を上げることができ、
これによってパフォーマンスが向上する。
とくに、ループ内で配列オブジェクトを使う場合などに役立つ。

Javaのオブジェクトには到達可能性というものが設けられている。

強到達可能、軟到達可能、弱到達可能、仮到達可能、到達不可能

これは左にいけばいくほどそのオブジェクトがnullになったとくメモリを
解放してくれる候補になりやすことを示している。
強到達可能になればガーベッジコレクトされる候補になる。
到達不可能なオブジェクトはガーベッジコレクトされない。
これを、java.lang.ref.Referenceによって変更することができるのだ。
到達しにくいオブジェクトを軟到達可能にするなど、到達可能性を変更することで
パフォーマンス、メモリリソースを制御することができるわけだ。


852 :仕様書無しさん:04/03/31 22:06
そんな面倒なことしなくてもfreeせずにとっときゃいいじゃん。

853 :仕様書無しさん:04/03/31 22:07
freeなんてしなくてもプロセス死ねば解放されるじゃん

854 :仕様書無しさん:04/03/31 22:23
ワラタ
殺すんでしょ?

855 :仕様書無しさん:04/03/31 22:27
Java厨のことを派遣ドカタPGと連呼する人たちはあれでしょ。
組み込み系C厨なんでしょ。

限られたメモリ内でプログラミングするという非常に苦しい仕事をしているのに
組み込み系PGはなぜか給料が安い。
それでデータベースとかやっているJava厨が妬ましくてうらやましいそれで
サーバにある豊富なメモリ使い放題で楽そうな仕事をしているように見えるので
自分よりドカタな仕事をしているようにみえるJava厨がムカツクっていっているんでしょ。



856 :仕様書無しさん:04/03/31 23:03
>>855
>限られたメモリ内でプログラミングするという非常に苦しい仕事をしているのに
いや!奴らはそれを楽しんでる。

857 :仕様書無しさん:04/03/31 23:04
と、派遣が申しております。

858 :仕様書無しさん:04/03/31 23:07
コラ、厨同士でケンカするんじゃありません。

859 :仕様書無しさん:04/03/31 23:24
ApacheやJVMがJavaで記述される時代になったら、使ってやるよ(藁

860 :仕様書無しさん:04/03/31 23:25
>>859
根本的に馬鹿。

861 :仕様書無しさん:04/03/31 23:25
困ったちゃんがここにも一人。

862 :仕様書無しさん:04/03/31 23:32
と、Webアプリデザイナーが申しております。

863 :仕様書無しさん:04/03/31 23:46
WebデザイナーはWebProg板へ帰れよ(w

864 :仕様書無しさん:04/03/31 23:59
apache, JVM, qmail, postfix, sendmail, proftpd
これらが全部JAVAで書かれるようになってからえばってもおそうないで。
箱庭言語には箱庭言語向きの分野があるんや。そやけど、世の中には
それ以外の分野もあるんやで。

865 :仕様書無しさん:04/04/01 00:06
と、何がなんでも一つの言語で書きたい方が申しております。

866 :仕様書無しさん:04/04/01 00:18
あふぉやなぁ。マジであふぉやで。
わいは、javaにはjava向きの分野があるというとんのや。
Java向きではない分野にJavaを使えゆうとるやつはあふぉやないか。っちゅうことや。

867 :仕様書無しさん:04/04/01 00:18
誰のサポートなしでも組める力量もったJava(PG)専門の人の工数単価っていくらぐらい?
知人周りにJava専な人いないので教えて、えらい人!!

868 :仕様書無しさん:04/04/01 00:22
Java専門の奴なんているのか?

869 :仕様書無しさん:04/04/01 00:26
>>866は蝦夷春樹

870 :仕様書無しさん:04/04/01 00:42
Java専、て、響きがアレだな(w

871 :仕様書無しさん:04/04/01 00:46
>>867
おれ派遣で120マソ/月だったよ。今月まで。

872 :仕様書無しさん:04/04/01 00:49
>>864
> apache, JVM, qmail, postfix, sendmail, proftpd
> これらが全部JAVAで書かれるようになってからえばってもおそうないで。
> 箱庭言語には箱庭言語向きの分野があるんや。そやけど、世の中には
> それ以外の分野もあるんやで。

一個だけアフォ発想なものがあるな。
その一個を除いて他はすべてJavaで実現されているぞ。

Apacheは100%PureJava Web Server Jettyで実現できる。
qmail, postfix, sendmailは 100%PureJava Mail Server Apache Jamesで実現できる。
proftpdに関してだが、あえてJavaでやるならばFTPにする必要がないな。
FTPへのアクセスは組織によっては制限されているケースもめずらしくもない。
そこでJettyでWAVDAVを使えばFTPサーバの代用とすることができる。


そんなことも知らないでこのスレで煽り厨としてJavaを批判していたのか?

873 :仕様書無しさん:04/04/01 00:49
>>871
派遣社員というより契約社員だろ。
派遣元へ戻れば正社員か

874 :仕様書無しさん:04/04/01 00:50
>>868
いない。大抵、Cから来た香具師とかUNIXが関与している香具師が多い。

875 :仕様書無しさん:04/04/01 00:51
>>872
Jakartaで普通にFTPServer作ってなかったけ?
WebDAVならSlideか。何でもあるんだな。

876 :仕様書無しさん:04/04/01 00:53
んで、その100%PureJava な鯖はつかわれてんの?

877 :仕様書無しさん:04/04/01 00:57
>>866
>>864で示した例はJava向きではないとは必ずしも言い切れないものがあることが
よくわかっただろう。

しかし一部部分的にネイティブにしたほうがいいところも確かにある。
実際、J2EE RI, Tomcat, JBoss( with Tomcat)は一部ネイティブで動作している。

JBossには100%PureJava RDBMS HyperSonicSQL(HSQLDB)が使われているが、
今後、替わりにMySQLを導入するという。
以前、JBossのServlet Containerには100%PureJavaWebServer Jettyが使われていたが
今ではServlet ContainerにはTomcatが使われたバージョンがメインとなっており、
Jetty版は特別バージョンとなっている。

一時的に100%PureJavaからかけ離れる動きがあるが、
コンピュータの性能が十分に満足に向上したとき
再び100%PureJavaに回帰するときがやってくるだろう。



878 :仕様書無しさん:04/04/01 00:57
>>876
Tomcatほどには使われていない。

879 :仕様書無しさん:04/04/01 00:57
Jetty+JBossでJ2EEって使われてるんでは?
Apacheをすでに使っているところにJ2EEねじ込むほうが多いみたいだから、
目立たないけどさ。大体、HTTPDなんて作るの簡単だろ。

880 :仕様書無しさん:04/04/01 00:58
> 世の中には それ以外の分野もあるんやで。

たぶん大事なのはここだと思うんだが。
javaで実現できるとか実現できないといった
「可能性の話は」どうでもいいのでは?
可能性ならなんでも可能性がある。
そうではなくて、なんでも一人でやるわけではないのだから
現実的に実態にあった方法としてどうなの?という話だと思うよ。



881 :仕様書無しさん:04/04/01 00:59
>>867
Java でも C++ でもどれでも会社から見ればただの PG じゃないの。
作業員の単価はそう変わらんでしょ。

言語は関係なくて顧客がビジネス的に成功できるものを
組めれば単価は高いんじゃないかな。

882 :仕様書無しさん:04/04/01 00:59
Tomcatは鯖じゃないでしょ。それと、Tomcatこそ、マジPureJavaでは。
J2EEのServletコンテナのRIとして、Sunがそのまま使ってるくらいだ
もんで。

883 :仕様書無しさん:04/04/01 01:02
>>879
> Jetty+JBossでJ2EEって使われてるんでは?
それは古いバージョンの話。最新バージョンのJBossにはJettyは付属されておらず
替わりにTomcatが付属されている。Jetty版は別途ダウンロードする必要有り。

> Apacheをすでに使っているところにJ2EEねじ込むほうが多いみたいだから、
> 目立たないけどさ。大体、HTTPDなんて作るの簡単だろ。
コネクタ(mod_jk2など)をmakeでビルドするだけで済むからそりゃ簡単だ。


884 :仕様書無しさん:04/04/01 01:03
>>882
Tomcatは鯖だろ。クライアントか?

885 :仕様書無しさん:04/04/01 01:05
>>882
> Tomcatは鯖じゃないでしょ。それと、Tomcatこそ、マジPureJavaでは。
違う。TomcatはWebServerとして使える。しかし機能性とパフォーマンスの影響があるため、
コネクタを使ってよくApacheと連携されている。100%PureJavaではない。
ダウンロードサイトではバイナリ版は拡張子zip, tar.gzなどに分かれている。

> J2EEのServletコンテナのRIとして、Sunがそのまま使ってるくらいだ
> もんで。
J2EE RIもJ2SEランタイム同様、100%PureJavaじゃない。
ダウンロードサイトをみればわかるようにWindows版、Linux版、Solaris版などに分かれている。

886 :仕様書無しさん:04/04/01 01:11
JavaでDNSサーバを作るにはJNDIを使って作るのか?

887 :仕様書無しさん:04/04/01 01:12
>>871
サンクス参考になりやした。

>>874
私の回りもそんなにとです。
4月から暇なのでまたJava再チャレンジ逝ってみるよ。

888 :仕様書無しさん:04/04/01 01:30
>>875
> >>872
> Jakartaで普通にFTPServer作ってなかったけ?
これのことか。
Jakarta Commons Incubator:FTPServer

別名(新規名?)
Apache FtpServer
 FTP server based on Apache Avalon

http://incubator.terra-intl.com/projects/ftpserver/

Features
100% pure Java, free, open source resumable FTP server!!!

889 :仕様書無しさん:04/04/01 01:31
ここも大分ツールが溜まってきたな。

Jakarta Commons
http://jakarta.terra-intl.com/commons/components.html


890 :仕様書無しさん:04/04/01 01:37
おおいたツール?

891 :仕様書無しさん:04/04/01 02:02
明日というか今日から新入社員です。
JAVA習ったことないのですがそれを承知で社長さんが採用してくれました。
入ってセミナーに通わせてもらいそこで勉強→仕事みたいな感じで。
ちと緊張気味ですが頑張りたいと思います。

あー・・・「こいつ使えねえやつ」と思われたらどうしようかとモンモンしてきた。
出来るだけ頑張りやす。
C++は基本習ったので比較的for文とかは・・・なんとかかんとか出来るかも。

892 :仕様書無しさん:04/04/01 02:28
>>885

Tomcatの中を見てみたけど、拡張子がdllやsoなどのファイルが見つかりません。

いろいろな圧縮形式を用意しているのは環境によってはどちらかしか解凍できないということを考慮しているのでは?

893 :仕様書無しさん:04/04/01 02:30
ザワザワ

894 :仕様書無しさん:04/04/01 02:48
Javaと.NETで十分だろ

895 :仕様書無しさん:04/04/01 09:03
Javaドカタの皆さん、年度が変わっても使い捨ての突貫工事、頑張ってください

896 :仕様書無しさん:04/04/01 09:19
C組み込み系って給料安いのか?
なんか限られた人しかできないイメージがあるんで
高そうなんだけど

897 :仕様書無しさん:04/04/01 10:11
Javaでお勧めのメーリングリストありませんか?


898 :仕様書無しさん:04/04/01 10:42
>>896
明らかにデータベースエンジニアより安い。
哀れなほどに。

899 :仕様書無しさん:04/04/01 11:03
jakartaのML

900 :仕様書無しさん:04/04/01 11:04
>>892
> >>885
>
> Tomcatの中を見てみたけど、拡張子がdllやsoなどのファイルが見つかりません。
binにはtomcat.exeがある。shもあるがbatもある。

どっちにしろ動くが特定のOSのみでしか動かないファイルが含まれている。

901 :仕様書無しさん:04/04/01 11:05
>>897
http://www.meisei-u.ac.jp/mirror/apache/dist/jakarta/tomcat-5/v5.0.19/bin/jakarta-tomcat-5.0.19.zip


902 :69式フリーPG ◆hND3Lufios :04/04/01 12:48
年度も変わったことだし、新人さんの降臨きぼんぬ

903 :仕様書無しさん:04/04/01 12:59
入社初日から会社で2ちゃんねるってどういう新人だよ。w

904 :新人:04/04/01 13:16
こんちゃーす。
Javaですか?学生時代に自分のサイト用のJScriptなら経験がありマース

905 :仕様書無しさん:04/04/01 13:41
J2SDKをインストールしてから、JAVAアプリケーション使うと、
フリーズするんだが、なぜなんでしょう?だれか教えて下さい。

906 :仕様書無しさん:04/04/01 13:48
>>904
っていうかJScriptは全然Javaと関係ない。
さらにいうとJavaScriptとも別物。M$が作った偽JavaScript.
JavaScriptもJavaとは全然違う。

907 :仕様書無しさん:04/04/01 13:52
>>905
バージョンはいくつのを使っている?
java -versionで確認。(PATHが通っている場合のみ)

自分のマシンにインストールされているjava.exeあるいはjava.shなどはいくつある?
検索してみるとよろし。


本当にJavaが原因でフリーズしているのかどうか怪しい。
Java以外の原因か?

使用OSは何か? OSのバージョンは?


どの環境でそれを使っている?
プログラミングか? ただのユーザ用途か?



908 :仕様書無しさん:04/04/01 14:23
そこまで把握しないとJavaって動かないんだ。
組み合わせ地獄で面倒だね。

909 :905:04/04/01 14:33
>>907
1.4.1です

SwingとApplet使うとフリーズしてしまいます。

OSはXPです。SP1



910 :仕様書無しさん:04/04/01 14:38
>>908
どこが面倒なんだか。
まだJavaが原因でフリーズするとはきまったわけではないのに。

911 :仕様書無しさん:04/04/01 14:43
>>910
Javaアプリがフリーズしていることに変わりなし。詭弁

912 :905:04/04/01 14:44
java.exeは3つありました >>907


913 :仕様書無しさん:04/04/01 14:46
M糞のOSかサービスパックかアップデートかオフィスかそのぱっちか、
IEかそのパッチが悪さしてるんだろう。M糞のやりそうなことだ。

914 :  俺  :04/04/01 14:47
>>904
名前の通りの奴だな

915 :仕様書無しさん:04/04/01 14:47
>>909
> >>907
> 1.4.1です
1.4.2_04が最新版だ。

> SwingとApplet使うとフリーズしてしまいます。
具体的にどういうソフトなのか? 有名なソフトなら紹介してくれ。
拡張子がjnlpになっているファイルがあるJavaWebStart上で動くのか、
それともあくまでApplet Viewerでしかうごかないのか?

それとSwingとAppletを使うだけなのか、それとも、
自分でSwingとAppletを使ってプログラミングしたコードを
動かすとフリーズするのか? 一体何なのかはっきりと詳細に

そちらの環境、状況をもっと詳しく説明しなければ憶測に頼らざるを得なくなり
こちらは質問に答えにくい。

「SwingとAppletを使う」とは具体的にどういうことか?
SwingとApplet両方が使われたアプリケーションあるいはAppletが動かないのか、
それとも、Swing用アプリ、Applet用アプリそれぞれが別々に存在し、
それが動かないのかどっちなのかはっきりせい。

Appletというからにはブラウザで動かしているのだろうな?
もしそうだとしたら
ブラウザは何を使っている?
IE, Netscape, Mozilla以外のブラウザを使っているのか?
それともOperaなどそれ以外のブラウザを使っているのか?
ブラウザのバージョンは?
ブラウザにインストールされているJava Pluginはちゃんとバージョンが1.4.2_04のJVMを参照しているように
設定されているか? もし設定されていなければコントロールパネルでJava Plug-inを
クリックし、そこで確認するなどをせよ。

916 :仕様書無しさん:04/04/01 14:48
>>911
> >>910
> Javaアプリがフリーズしていることに変わりなし。詭弁
根拠がない。憶測だけ判断することこそ詭弁。

917 :905:04/04/01 14:49
自分のマシンに入れた時は、問題なく動作したんだが・・・

918 :仕様書無しさん:04/04/01 14:51
やっぱりJavaって一般ユーザーには薦められないな。
お客さんに対して>>915みたいな口は叩けないもん。
即行クビだろうな。

919 :仕様書無しさん:04/04/01 14:52
>>912
> java.exeは3つありました >>907
>
その3つは、どこのディレクトリをさしている?
それぞれのjava.exeのバージョンが違うかもしれない。
バージョンを調べるにはコマンドプロンプトで、
まず、setまたはecho %PATH%を確認せよ。
そこでjava.exeにパスが通っているかどうか確認せよ。

そのjava.exeがあるパスを絶対パスで指定して
c:\>c:\j2sdk1.4.2_04\bin\java.exe -version
とするか、

または
そのjava.exeがあるディレクトリまで移動しそこで
java -version と入力せよ。

そこでJavaのバージョンを確認できる。


それと、Windowsディレクトリの方にもあるなら要注意だ。
Micro$oft独自仕様のJVMが存在しているかもしれない。

920 :仕様書無しさん:04/04/01 14:53
.NET Frameworkならこんなトラブルもないわけだが。俺のマシンでは1.0、1.1、1.2、2.0すべて共存して問題なく動いてる。

921 :仕様書無しさん:04/04/01 14:54
Javaで苦しむのはドカタだけにしてほしいね。
ユーザーを巻き込むなよ。自爆テロランタイムが。

922 :905:04/04/01 14:54
すまん説明が下手で>>915

最新番でフリーズしたから変えてみたんだ。
自分でコンパイルしたやつもJAVAwebStartってやつでもとまる。
j2sdkをアンインストールした時もフリーズした。
ブラウザはIEです。



923 :仕様書無しさん:04/04/01 14:55
わてやJavaのせいやないで!
M$や!!M$が全部悪いんや!!
C-NETにも書いてあったで。
M$はパッチをいれるとおかしゅうなるとか、SUNに嫌がらせしとるとか。
中村正三郎先生もゆうとった。わても被害者なんや!!

あんじょう頼みますわ。



924 :仕様書無しさん:04/04/01 14:55
>>918
おいおい、2chだぞ。
ましてや、質問の仕方がなっていない。
掲示板(に限らず技術系メーリングリストでもそうだが)は
なんでも相談ホットラインではない。
ただ適当に質問してくれれば答えてくれるという甘いもんじゃない。

あのような曖昧は質問の仕方に問題がある。

そのような考え方しかできないお前がまずクビだな。



925 :仕様書無しさん:04/04/01 14:56
>>920
そういうのをまさに詭弁という。
ドトネトフレームワークでも同じような問題が起きないこともない。
しかもこれはJavaの問題とは限らないのだ。
WindowsというOSの問題かもしれないわけだが。

926 :仕様書無しさん:04/04/01 14:56
>>924
Javaは初心者は手を出すべきじゃないね。
これじゃあ.NETの天下になるのも仕方がないよ。簡単だもん。

927 :仕様書無しさん:04/04/01 14:57
>>925
根拠ゼロ。やり直し。

928 :仕様書無しさん:04/04/01 14:57
>>917
> 自分のマシンに入れた時は、問題なく動作したんだが・・・
その自分のマシンの環境というのはどういう環境かな?
ただ問題ないといっただけじゃわからないぞ。

929 :仕様書無しさん:04/04/01 14:58
LinuxにJava入れたら誰もサポートしてくれないしな

930 :905:04/04/01 14:59
c:\WINDOWS\PrefetchにJAVA>EXE=********.pfってやつが5こありました。
>>915

931 :仕様書無しさん:04/04/01 15:01
俺のマシンにはjava.exeが1個もないや。
大半のユーザーはこうなのが現実なわけで。

932 :905:04/04/01 15:01
すみません、初めて書き込んだもんで>>924

933 :仕様書無しさん:04/04/01 15:03
>>922
> すまん説明が下手で>>915
>
> 最新番でフリーズしたから変えてみたんだ。
Javaだけが原因でフリーズしたなんて話一度も聞いたことがないぞ。
そのソフトは一体どういうソフトなのかね?
フリーズというと画面が固まって止まるということでよろしいか?
それともただのOS側の問題で起こるブルースクリーンか?
何かエラーメッセージが出たならそのメッセージを
ここに貼り付けてみてくれ。

> 自分でコンパイルしたやつもJAVAwebStartってやつでもとまる。
> j2sdkをアンインストールした時もフリーズした。
具体的に、アンインストールのどういうときにフリーズしたのか?
今までにそんな話は聞いたことがない。
そのとき、アンインストール中にOSに負荷をかけるようなほかの作業を
していたということはないか?

> ブラウザはIEです。
つまり、ブラウザを使ってそのAppletを実行しようとしたのだな?
では、コントロールパネルでJavaを選び、Sun純正のJavaをブラウザで使えるようにするための
設定で InternetExplorerにチェックを入れているか?

934 :仕様書無しさん:04/04/01 15:04
使えねえJava信者だな。
もっとさくっと助けてやれよ低脳。

935 :905:04/04/01 15:06
928>>
まったく自分と同じ環境です。
フリーズしたことはありませんでした。


936 :仕様書無しさん:04/04/01 15:06
>>926
果たしてそうだといいきれるだろうか。
Javaのインストールも随分と簡単になってきている。
JavaWebStart対応アプリケーションならばそれにアクセスするだけで
自動的にJavaをダウンロードし、自動インストールしてくれる。

それと、今回の彼の質問はユーザサイドかというとちょっと微妙に違う。
彼はJ2SDKをインストールしたといっている。つまり彼は
ユーザではなくプログラマという立場でJavaをやろうとしているのではないだろうか。
初心者がどういうという話をしても解決はしないということだ。



937 :仕様書無しさん:04/04/01 15:06
>>929
すでにJava入っているけど。

938 :仕様書無しさん:04/04/01 15:09
サポートがカスだと開発者もどんどん離れていくわな。
今回のケースみたいに。

939 :仕様書無しさん:04/04/01 15:10
>>930
ブラウザ側の設定に問題があるだけみたいだな。

コントロールパネルのあの設定でIEにチェックをいれるのと、

IEを起動してインターネットオプション-詳細設定を選び、

Javaのところのチェックボックスで<applet>にjava3 v1.4.2_04を使用(再起動が必要)
みたいなことが書いてあるからそれにチェックを入れる。

Microsoft VMのほうのチェックボックスはとりあえず全部はずしてみる。
これにチェックが入っていたのが原因である疑いが強くなってきた。

940 :905:04/04/01 15:10
933>>
画面がかたまってしばらくするとマウスポインタも動かなくなる。
J2SDKインストール後、javapluginとjavawebstartをいらうと固まりますし。
自分のプログラムをコンパイルしても固まるときがある。
GUIを使わなければとまらない。
appletviewrは1回目は動く


941 :仕様書無しさん:04/04/01 15:11
>>934
文句があるならお前が助けろ。口だけの餓鬼じゃあるまいし。
そもそも>>905の質問の仕方が問題がある。
もうこれでもお人好しといってもいいくらいだ。


942 :仕様書無しさん:04/04/01 15:12
>>940
> 933>>
> 画面がかたまってしばらくするとマウスポインタも動かなくなる。
> J2SDKインストール後、javapluginとjavawebstartをいらうと固まりますし。
「いらう」って何だ?

> 自分のプログラムをコンパイルしても固まるときがある。
> GUIを使わなければとまらない。
> appletviewrは1回目は動く

マシンのスペックは?

943 :905:04/04/01 15:14
>>939
すでにしています

944 :905:04/04/01 15:15
>>942
セレの2.4 メモリ5121枚 HDD80

945 :仕様書無しさん:04/04/01 15:15
>>938
おまえ、それでも技術者か?
M$からもらったおむつがないと用を足すこともできないほど幼稚で
何もできない甘えん坊みたいだぞ。
サポートにばかり頼っていて自分ではろくに調べようともせず
問題意識もしっかり持とうとしない奴は技術者に向いていないぞ。

それに、M$がいくらサポートしたってC#やVB開発者がC/C++開発者を上回ることがないだろうが。


946 :仕様書無しさん:04/04/01 15:15
よいケーススタディになるね。がんばれアホと説明下手

947 :905:04/04/01 15:16
>>941
すいません

948 :仕様書無しさん:04/04/01 15:16
javaが悪のちゃうで。M$が悪いんや。



949 :仕様書無しさん:04/04/01 15:17
>>944
> >>942
> セレの2.4 メモリ5121枚 HDD80
Celeron 2.4GHzだな? わかりにくい表記だ。
起動時にほかに何か常駐プログラムは動かしているか?


950 :905:04/04/01 15:18
>>949
ウイルスバスターのみです

951 :仕様書無しさん:04/04/01 15:20
>>946
説明が下手?説明がうまいなら自分からうまい説明の手本を見せてみろ。
あれでも十分なほどだ。本来ならばあのような質問では
だれも相手にしていなかったはずだ。情報があまりにも少なすぎて
質問に答えにくくしているだけだ。

952 :905:04/04/01 15:20
>>942
いらうはさわるって意味です

953 :仕様書無しさん:04/04/01 15:21
M$が悪いに決まっとるやないかい。中村正三郎先生もゆうとったで。
それとも何か?Javaが悪いとでもいうんかい。
もし、M$のせいやったらそんときはどうけじめつける気や?

954 :仕様書無しさん:04/04/01 15:21
>>950
それ、怪しいな。思ったが
もう一台のうまくいっているマシンも環境が同じで
双方ともウィルスバスターが入っているんだよな?
設定もおなじか?

955 :仕様書無しさん:04/04/01 15:22
>>953
おまえはウザイから黙れ。

956 :仕様書無しさん:04/04/01 15:24
>>952
どこの方言か知らんが
Java Pluginをさわると固まる?
いっている意味がよくわからない。
ブラウザをさわると固まるということか?
そもそもさわるっていういいかたがおかしい。
起動するとかじゃないのか?
起動してから何をするとフリーズするのか?
自分の作ったプログラムを動かしたときのみ固まるんだな?
では、ほかのプログラムを動かしたときに固まるかテストしてみろ。
もしかたまらなければ自分で作ったプログラムに原因があるかもしれん。


957 :仕様書無しさん:04/04/01 15:26
>>943
ところで、コントロールパネルにはJavaとかかれたアイコンはいくつあった?
古いJavaが複数入っているとJava Pluginのアイコンが複数になってしまうことがある。


958 :仕様書無しさん:04/04/01 15:28
>>940
> 933>>
> 画面がかたまってしばらくするとマウスポインタも動かなくなる。
> J2SDKインストール後、javapluginとjavawebstartをいらうと固まりますし。
> 自分のプログラムをコンパイルしても固まるときがある。
> GUIを使わなければとまらない。
そのGUIとは何のGUIのことを刺しているのか、
自分で作ったSwingアプリケーションのことをいっているのか?

> appletviewrは1回目は動く
1回は動くってどう動くのか?
それと、仮に動かないときどういう挙動が示されたのか、
どのようなエラー、例外メッセージが表示されたのか、
ここに貼り付けよ。


959 :仕様書無しさん:04/04/01 15:30
こちらの、フリーズが起きた原因についての質問には
ろくに答えようとしない奴だなこいつ。

本当にやる気があるのか?

960 :905:04/04/01 15:30
あとDOS窓でもとまります

961 :905:04/04/01 15:32
956>>SWINGを使ったプログラム起動すると、エラーメッセージもなにもなく固まります

962 :仕様書無しさん:04/04/01 15:32
厨は.NETを使っとけ。
ろくに説明も出来ない糞はJavaに触るな。

963 :905:04/04/01 15:32
957>>
1つです

964 :仕様書無しさん:04/04/01 15:35
使えねえサポートだな。誰かもっと分かる奴居ないのか。カスどもが。Java厨はレベル低いな。

965 :905:04/04/01 15:35
958>>
自作プログラムをappletviewerで1回目は動いてくれるが、
もう一回同じコマンドうつとフリーズするという意味です

966 :905:04/04/01 15:36
956>>
JAVA WEB START のプログラムでもフリーズします

967 :仕様書無しさん:04/04/01 15:36
Javaってほんと使えないな。
普通に使っただけでフリーズかよ。ボケ

968 :905:04/04/01 15:38
959>>
すいませんフリーズして再起動してました

969 :仕様書無しさん:04/04/01 15:38
使えないのはJava信者の方。
口だけ宣伝屋で現実の不具合にはダンマリ。

970 :仕様書無しさん:04/04/01 15:38
ム板へいけよ。

971 :仕様書無しさん:04/04/01 15:39
.NETのほうが簡単とか言う奴がいるけど

はっきりいって、こういうヴァカはJavaも.NETもどちらも向いていない。
いやむしろプログラマにすらむいてない。

こういう自分から問題解決に向けて努力しない奴は技術者に向いていない。
教えて君はウザイと言われるのと同じだな。


972 :905:04/04/01 15:40
昨日から、原因をつぶしていってるんですが、まったくわかりません。
マシンに問題があってJAVAがフリーズするなんてことあるんでしょうか?

973 :仕様書無しさん:04/04/01 15:40
>>964
おい、カス、だったらお前が使えるサポートになりな。
おまえは使えるサポータなんだろ?
それとも口先だけでサポートできないのか? カスが。



974 :仕様書無しさん:04/04/01 15:40
Javaが欠陥品なのにユーザーのせいにして罵倒するのはどうかと。
これじゃあ普及しないね。

975 :仕様書無しさん:04/04/01 15:41
>>972
Windowsならなおさらありうる。

もうお前、いい加減に自作自演臭く見えてきたので
メーリングリストで質問してみな。ウザイんだよ。この甘えん坊が。

976 :仕様書無しさん:04/04/01 15:41
結局Javaが欠陥品でした、と

977 :仕様書無しさん:04/04/01 15:41
>>974
Windowsが欠陥品なのにユーザーのせいにして罵倒するのはどうかと。
これじゃあ信頼されないね。

978 :905:04/04/01 15:42
971>>
どー考えてもわからなかったもんで質問させてもらいました。すいません

979 :仕様書無しさん:04/04/01 15:42
使えない馬鹿サポートのせいで時間無駄にした。
Javaなんか使った俺が間違いだった。
使えねえ糞サポートは氏ねよ。

980 :仕様書無しさん:04/04/01 15:43
>>967, 969
使えないのはお前の方。なにかにつけてドトネトを連呼すれば解決すると妄想しているんだからな。
口だけだろ。お前は。ドトネトが使えるというなら>>905が望んでいるものを
ドトネトで実現してみるんだな。ドトネト厨。それとも予想通り口だけか? ドトネト厨は

981 :仕様書無しさん:04/04/01 15:43
Javaを理解できない低脳は触るなっちゅうこっちゃ。

982 :905:04/04/01 15:43
975>>
わかりました。

みなさんありがとうございました。

983 :仕様書無しさん:04/04/01 15:43
java関係をすべてアンインストールせよ。
そこから必要なものだけ最新版を順番にインストール。
ただし必要なものだけってのが重要。

漏れならjava関係は一切インスコしない。
使わなくとも平気だし不安定になるから。


984 :仕様書無しさん:04/04/01 15:44
口先だけの使えねえ低脳サポート。二度と書き込むな役立たず。

985 :仕様書無しさん:04/04/01 15:44
Javaは欠陥品で信者も低脳役立たずでした、と

986 :仕様書無しさん:04/04/01 15:45
>>979
おまえはサポータがいないと自分でなにもできないんだろ
ドトネト厨。そういう馬鹿みたいな餓鬼は無理してJavaを使わなくていいよ。
さっさとドカタ言語VBやC#にでも移行しておきな。

987 :仕様書無しさん:04/04/01 15:45
これは「javaは悪くないんですよ。」とは言えんな。

>>990 次スレよろ。


988 :仕様書無しさん:04/04/01 15:46
Javaのサポートは○ーテック以下だった。

989 :仕様書無しさん:04/04/01 15:47
>>967
そもそも、お前の頭が使えないな。
脳内フリーズかよ(ワラ
OSが原因でフリーズしたのもすべてJavaの性にしないときが済まないのか(ワラ
いままでにフリーズしたJavaプログラムというものをうpローダで実際に挙げてみろよw
実際にテストしてやるからよ。

990 :仕様書無しさん:04/04/01 15:47
ふぅ

991 :仕様書無しさん:04/04/01 15:47
>>987
そんな詭弁術がいつまでも続くと思っているのかこの低脳め

992 :69式フリーPG ◆hND3Lufios :04/04/01 15:47
990げっと

993 :仕様書無しさん:04/04/01 15:48
>>985
むしろWindowsは欠陥品でで者も低脳役立たずでした、と


994 :仕様書無しさん:04/04/01 15:48
>>989
低脳サポートにフォローできるわけないだろ。
Javaの勉強でもしておけ能無し馬鹿。

995 :仕様書無しさん:04/04/01 15:48
>>983
頭がわるい証拠だな。Windows板のアフォどもと同レベルだ。

996 :仕様書無しさん:04/04/01 15:48
Javaは使えない。
Java使いはもっと使えない。
ドカタ

997 :仕様書無しさん:04/04/01 15:49
>>994
低脳プログラマにはJavaが理解できるわけ内だろアフォ

998 :905:04/04/01 15:49
>>989
プログラムは違うマシンでは動くし異常なし

999 :仕様書無しさん:04/04/01 15:49
新年度ドカタが華麗に1000get

1000 :仕様書無しさん:04/04/01 15:49
そうかjavaってのはオプソ厨が嫌うWin以下なんだね(w

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

263 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)