Javaって重くね？
Javaで作られたソフト見たことないんだけど
まあ消防の作った糞ゲームくらいかなw
それか犯罪者にしか使われないライムワイヤーとかw
まあ消防の作った糞ゲームくらいかなw
それか犯罪者にしか使われないライムワイヤーとかw
|
|
|
1 名前：仕様書無しさん 2005/11/08(火) 20:12:47
Javaで作られたソフト見たことないんだけど
まあ消防の作った糞ゲームくらいかなw
それか犯罪者にしか使われないライムワイヤーとかw
Javaで作られたソフト見たことないんだけど
まあ消防の作った糞ゲームくらいかなw
それか犯罪者にしか使われないライムワイヤーとかw
２ｃｈの半分はＪａｖａで構成されている。
バファリンの半分もJavaで構成されている。
5 ：232：2005/11/10(木) 02:07:49
>>6
何それ？新しい言語？もう覚えられんよ・・・
何それ？新しい言語？もう覚えられんよ・・・
8 ：仕様書無しさん：2005/11/10(木) 22:40:00
ふつーPerlだろ、いまどき。
Javaより>>1のほうが重たい。
脂肪多すぎなキモヲタなんだよ>>1は
JavaOne Tokyo 2005に行ってきたが
>>1みたいなキモヲタデブはいなかったぞ。
みんな若手が多く、イケメンも何割かいた。
Cしかできないコミュニティよりもイケメンが多い感じだ。
しかも女性エンジニアも多いのが特徴的。
Cしかできないコミュニティはジジ臭いのが
多くてかつキモヲタのデブが多すぎ。
Cしかできない奴は考え方は古くさいし
自ら奴隷になって身を捧げることが得意な滅私奉公型のバカが多いし。
脂肪多すぎなキモヲタなんだよ>>1は
JavaOne Tokyo 2005に行ってきたが
>>1みたいなキモヲタデブはいなかったぞ。
みんな若手が多く、イケメンも何割かいた。
Cしかできないコミュニティよりもイケメンが多い感じだ。
しかも女性エンジニアも多いのが特徴的。
Cしかできないコミュニティはジジ臭いのが
多くてかつキモヲタのデブが多すぎ。
Cしかできない奴は考え方は古くさいし
自ら奴隷になって身を捧げることが得意な滅私奉公型のバカが多いし。
今の国際特許検索システムがJavaで作られていることを知らない>>1
しかもそいつはTomcat + Hibernate + Struts + PostgreSQLで動いている。
それすらも知らない>>1
大恥だね。こりゃ。
しかもそいつはTomcat + Hibernate + Struts + PostgreSQLで動いている。
それすらも知らない>>1
大恥だね。こりゃ。
火星探査機がJavaで制御されていることを知らない>>1はアホ
12 ：仕様書無しさん：2005/11/10(木) 23:18:04
今どきJavaが遅いとかいう奴は(ry
今Javaが抱えている問題はリアルタイム処理や
組み込み機器のメモリだけだよ。
速度問題はほとんど解消してるんだけどね。
今Javaが抱えている問題はリアルタイム処理や
組み込み機器のメモリだけだよ。
速度問題はほとんど解消してるんだけどね。
SWINGが重いのは確か。
5.0になって軽くなるかと思ったけどまだまだ。
Javaが重いところは、そのくらいじゃね？
>>10
オープンソースで固めてるな。
postgreSQLはあんまり好きじゃない。。
5.0になって軽くなるかと思ったけどまだまだ。
Javaが重いところは、そのくらいじゃね？
>>10
オープンソースで固めてるな。
postgreSQLはあんまり好きじゃない。。
15 ：仕様書無しさん：2005/11/11(金) 05:13:03
怒るなよJava厨
16 ：なぎさっち ◆Nagi/FmYMM ：2005/11/11(金) 10:20:21
>1は携帯のアプリを一切使ってない、絶滅寸前のDocomoPHSユーザ
18 ：仕様書無しさん：2005/11/11(金) 12:03:08
>>13
> SWINGが重いのは確か。
> 5.0になって軽くなるかと思ったけどまだまだ。
それはおまいのマシンスペックが(ry
とりあえず6.0 Mustangからはさらに速くなる。
初回実行時にネイティブコンパイルされるようだ。
で、２回目以降からの起動はCで作ったアプリと変わらない速度になるらしい。
> SWINGが重いのは確か。
> 5.0になって軽くなるかと思ったけどまだまだ。
それはおまいのマシンスペックが(ry
とりあえず6.0 Mustangからはさらに速くなる。
初回実行時にネイティブコンパイルされるようだ。
で、２回目以降からの起動はCで作ったアプリと変わらない速度になるらしい。
>18
要するにJavaが重いってのが本質的に解決されてない
っていうのは確かだってことだよね。
要するにJavaが重いってのが本質的に解決されてない
っていうのは確かだってことだよね。
20 ：仕様書無しさん：2005/11/11(金) 12:37:44
.NETも重い。
VisualStudio Ver6までがちょうど仕事には向いている。
VisualStudio Ver6までがちょうど仕事には向いている。
21 ：仕様書無しさん：2005/11/11(金) 13:35:17
>>19
どんなプログラムを作るかによるんだけどね。
作り方や作りたいアプリケーションの分野に
よってはCよりJavaのほうが速くなることもよくある。
とくにServletなんかかなり速い。
サーバからクライアントへの通信はCやPerlなどのほうが
速いがクライアントからサーバへの通信はCやPerlより、Javaの方が速い。
Javaはレスポンス性能はCスループットやPerl等には
劣るがスループット性能はCやPerlと比べ、Javaのほうがとんでもなく速い。
スループット性能をいると、「Javaは軽い」ともいえる。
Javaは短距離走は苦手だが
長距離走はめっちゃくちゃ速いってこと。
CでJavaと同じようなコードを書こうとした場合、
短距離走レベル名短いコードではJavaはCには劣るが、
長距離走レベルの長い、複雑大規模なコードでは
JavaはCより断然速くなる。
ここでCのコードを修正すればどうにかしてCをJavaより速くすることは
できるが、それは非常に非現実的であり非常に困難を極める。
そこでも何としてでもCのコードを速くするようコード修正することに拘ると
開発コストが無駄にふくれあがり採算があわなくなり赤字になって
速度原理主義者になってしまう。
どんなプログラムを作るかによるんだけどね。
作り方や作りたいアプリケーションの分野に
よってはCよりJavaのほうが速くなることもよくある。
とくにServletなんかかなり速い。
サーバからクライアントへの通信はCやPerlなどのほうが
速いがクライアントからサーバへの通信はCやPerlより、Javaの方が速い。
Javaはレスポンス性能はCスループットやPerl等には
劣るがスループット性能はCやPerlと比べ、Javaのほうがとんでもなく速い。
スループット性能をいると、「Javaは軽い」ともいえる。
Javaは短距離走は苦手だが
長距離走はめっちゃくちゃ速いってこと。
CでJavaと同じようなコードを書こうとした場合、
短距離走レベル名短いコードではJavaはCには劣るが、
長距離走レベルの長い、複雑大規模なコードでは
JavaはCより断然速くなる。
ここでCのコードを修正すればどうにかしてCをJavaより速くすることは
できるが、それは非常に非現実的であり非常に困難を極める。
そこでも何としてでもCのコードを速くするようコード修正することに拘ると
開発コストが無駄にふくれあがり採算があわなくなり赤字になって
速度原理主義者になってしまう。
22 ：仕様書無しさん：2005/11/11(金) 13:43:29
昨日、JavaOneTokyo2005
を見てきたけど
今どき>>1みたいに「Javaは遅い」
を連呼する人は一人もいなかったよ。
パネルディスカッションでもそんな話は一言も出なかったよ。
マイクロソフトの社員がパネラーとして参加していたけど
そういう話は一切なかった。
一時期のあのSunとMSとの和解があったからこそそういう話になったのかな。
彼は.NETはクライアントサイドでもっともよく使われていることを訴えていた。
裏をかえすとサーバサイドでは.NETはJavaに押されて流行っていない
ことを認めているともいえる。Javaがクライアントサイドでサーバほど
流行っていないことをも意味するが。
Java批判で今どき速度を引き合いに出して叩く人は本当に時代遅れだよ。
「Write One , Run Anywhere.」が幻想だと批判している組み込みメーカーの
スピーカーはいたけど、かといってJavaが駄目だとは言ってはいなかった。
かといってJavaが駄目だからCやBREWにすべきだとも言っていなかったよ。
電池残量がすくになくなってしまうためRAMメモリを大量に
搭載することができないことが、Javaで「Write One , Run Anywhere.」
が実現しにくいことだとも言っていた。
BREWやCを使うことについて話を聞くと、
「セキュリティ上、Javaは必要だ」と強調していた。
顧客に対する企業の信頼を勝ち取るにはBREWやCで作られた組み込み機器よりも
Javaで作られた組み込み機器の方が信用できるということなんだそうだ。
を見てきたけど
今どき>>1みたいに「Javaは遅い」
を連呼する人は一人もいなかったよ。
パネルディスカッションでもそんな話は一言も出なかったよ。
マイクロソフトの社員がパネラーとして参加していたけど
そういう話は一切なかった。
一時期のあのSunとMSとの和解があったからこそそういう話になったのかな。
彼は.NETはクライアントサイドでもっともよく使われていることを訴えていた。
裏をかえすとサーバサイドでは.NETはJavaに押されて流行っていない
ことを認めているともいえる。Javaがクライアントサイドでサーバほど
流行っていないことをも意味するが。
Java批判で今どき速度を引き合いに出して叩く人は本当に時代遅れだよ。
「Write One , Run Anywhere.」が幻想だと批判している組み込みメーカーの
スピーカーはいたけど、かといってJavaが駄目だとは言ってはいなかった。
かといってJavaが駄目だからCやBREWにすべきだとも言っていなかったよ。
電池残量がすくになくなってしまうためRAMメモリを大量に
搭載することができないことが、Javaで「Write One , Run Anywhere.」
が実現しにくいことだとも言っていた。
BREWやCを使うことについて話を聞くと、
「セキュリティ上、Javaは必要だ」と強調していた。
顧客に対する企業の信頼を勝ち取るにはBREWやCで作られた組み込み機器よりも
Javaで作られた組み込み機器の方が信用できるということなんだそうだ。
猛スピードで>>1は
Cocoaは軽くない？
つか、携帯のJavaアプリを忘れてるぞみんな。
28 ：仕様書無しさん：2005/11/11(金) 23:40:55
だからCocoaは軽くない？
VBは重い上に、メモリリークし放題、
他の関係ないソフトインストールすると挙動不審になるし
他の関係ないソフトインストールすると挙動不審になるし
>23
だいぶムリがあるな。
>1から見てJAVAが遅いなら相対的に>1は速くないといけないだろ。
JAVAが>1に依存しているなら遅い原因として関連付けることは
できそうだがな。
JAVAが重いというよりVMの作りが悪いんだろ、要するに。
だいぶムリがあるな。
>1から見てJAVAが遅いなら相対的に>1は速くないといけないだろ。
JAVAが>1に依存しているなら遅い原因として関連付けることは
できそうだがな。
JAVAが重いというよりVMの作りが悪いんだろ、要するに。
ＧＵＩアプリとか見ても、特にストレスは感じないけどなあ
すいすい動いてるよ？
俺の環境はWin2000 Pen4 2GHz メモリ512M JDK5.0
すいすい動いてるよ？
俺の環境はWin2000 Pen4 2GHz メモリ512M JDK5.0
なんかフォントが美しくない。
>>33
気にくわないなら変えればいいじゃねーか。
気にくわないなら変えればいいじゃねーか。
35 ：仕様書無しさん：2005/11/21(月) 23:39:14
プログラミング覚えたてで、初めて仕事を頼まれたときに、
仕様書の内容が良く理解できず、バグが大量に見つかってしまった・・・
その後、先輩がひとつずつバグを取り除いていたが、
「おまえわざとか？」とかイヤミを言われた。
俺は全然悪くないのに、イヤミを言われてアタッマきた
仕様書の内容が良く理解できず、バグが大量に見つかってしまった・・・
その後、先輩がひとつずつバグを取り除いていたが、
「おまえわざとか？」とかイヤミを言われた。
俺は全然悪くないのに、イヤミを言われてアタッマきた
36 ：仕様書無しさん：2005/11/21(月) 23:41:10
>>35
いや、バグ入れたお前が悪いんだろ。アタッマきた。
いや、バグ入れたお前が悪いんだろ。アタッマきた。
37 ：仕様書無しさん：2005/11/21(月) 23:41:44
>>35
あるあるｗｗｗ
あるあるｗｗｗ
>>35が悪いだろ。
>仕様書の内容が良く理解できず、
理解出来ていないのに、そのままその状態を放置して
実装に突き進んだおまいが悪い。
わからんなら聞け。
理解出来ていないのに、そのままその状態を放置して
実装に突き進んだおまいが悪い。
わからんなら聞け。
40 ：なぎさっち ◆Nagi/FmYMM ：2005/11/22(火) 11:36:31
>35
> 仕様書の内容が良く理解できず、バグが大量に見つかってしまった・・・
なにこの他人事のようなつぶやき
> 仕様書の内容が良く理解できず、バグが大量に見つかってしまった・・・
なにこの他人事のようなつぶやき
41 ：仕様書無しさん：2005/11/22(火) 12:59:53
ヲチｗ
>>32
いくらなんでも、それは遅いのに慣れちゃった人か、ネタだろ。
.NETアプリと同じで立ち上がりの遅さは酷いし、ボタンを押してもクリック感が無い。
Java製GUIアプリをすいすい動かすには、メモリが２Gぐらい必要と思われ。
いくらなんでも、それは遅いのに慣れちゃった人か、ネタだろ。
.NETアプリと同じで立ち上がりの遅さは酷いし、ボタンを押してもクリック感が無い。
Java製GUIアプリをすいすい動かすには、メモリが２Gぐらい必要と思われ。
おいおい
44 ：仕様書無しさん：2005/11/22(火) 14:23:17
Javaがメモリを馬鹿みたく食うのは歴然たる事実だね。
いくらマ板がネタ板だからって立てていいスレと悪いスレがあると思う。
どんな環境でも、と言うからには
PDAでも楽勝でフルがきびきび動くぐらいじゃないとイヤです
PDAでも楽勝でフルがきびきび動くぐらいじゃないとイヤです
>>42
寝言はおまえ自身のPCスペックを晒してベンチマークを
とってから言え。
それからJava SE 5.0 Tigerで作られたSwingアプリケーションを
動かしてから言うことだ。
Tigerで作られたSwingアプリケーションはメモリがたったの512GBでも
十分なパフォーマンスを得られるぞ。
寝言はおまえ自身のPCスペックを晒してベンチマークを
とってから言え。
それからJava SE 5.0 Tigerで作られたSwingアプリケーションを
動かしてから言うことだ。
Tigerで作られたSwingアプリケーションはメモリがたったの512GBでも
十分なパフォーマンスを得られるぞ。
今現在ご家庭にあるXPマシンは
だいたい256じゃないの？
CPUとか液晶とか凝ってるメーカー機でも256多かったし
だいたい256じゃないの？
CPUとか液晶とか凝ってるメーカー機でも256多かったし
今売ってるのはさすがに512以上だが・・・・・
>>48
おいおい、うちの会社ですら2年前から512GBのDELLマシン
を使ってるぞ。
ノートPCも512GB以上が標準搭載されて手頃な価格で当たり前の時代だ。
パソコン一般板や自作PC板では512MBメモリ搭載マシンは
もう古いと言われているくらいだ。
それに512GBメモリなんて安いもんだぞ。6000円程度で買える。
1GBメモリは1万円以内で買える。
http://www.kakaku.com/sku/price/memory.htm
おいおい、うちの会社ですら2年前から512GBのDELLマシン
を使ってるぞ。
ノートPCも512GB以上が標準搭載されて手頃な価格で当たり前の時代だ。
パソコン一般板や自作PC板では512MBメモリ搭載マシンは
もう古いと言われているくらいだ。
それに512GBメモリなんて安いもんだぞ。6000円程度で買える。
1GBメモリは1万円以内で買える。
http://www.kakaku.com/sku/price/memory.htm
えっと…
512GBって、MBの間違いだよね？
釣られた？
512GBって、MBの間違いだよね？
釣られた？
いずれにせよデスクトップ環境用のJAVAアプリケーションは
メインで開いてるウインドウで使いますよ、しか出来ないんだな
メインで開いてるウインドウで使いますよ、しか出来ないんだな
55 ：仕様書無しさん：2005/11/23(水) 01:21:03
512MBでやっとまともに使えるくらいなら、複数のアプリを同時起動した
ら、かなりひどいことになりそうだ。
ら、かなりひどいことになりそうだ。
56 ：仕様書無しさん：2005/11/23(水) 01:30:16
原理上、hello world を表示するだけのプログラムでも VM をロードしなくちゃいけないからな。
プログラムの規模が十分大きくなれば、VM やライブラリの大きさは無視できる
ようになるけど。
プログラムの規模が十分大きくなれば、VM やライブラリの大きさは無視できる
ようになるけど。
だからVM共有化の話があるわけで。Mustangには入るのかな？
あとEclipseでもメモリは128MBくらいしか使わんよ
あとEclipseでもメモリは128MBくらいしか使わんよ
58 ：仕様書無しさん：2005/11/23(水) 11:35:43
> あとEclipseでもメモリは128MBくらいしか使わんよ
動くってだけで512は必要じゃない？
他のソフトだって使うし、仕事で使うならやっぱ最低１Gは欲しくと思う俺ガイル。
-vmargオプションだっけか？指定してる？
動くってだけで512は必要じゃない？
他のソフトだって使うし、仕事で使うならやっぱ最低１Gは欲しくと思う俺ガイル。
-vmargオプションだっけか？指定してる？
※XPは256も使いません
XPは128MBくらいだな
他のソフトでさらに128MBくらい使うので
Eclipse使うのに512MBはほしい
他のソフトでさらに128MBくらい使うので
Eclipse使うのに512MBはほしい
63 ：仕様書無しさん：2005/11/23(水) 15:23:58
今 Visual Studio.net を起動して新規 C# アプリケーションを作成した時点で
消費メモリは 50MB くらい。
消費メモリは 50MB くらい。
>>56
>>58
VM共有化、つまりアプリケーションを起動するたびに
VMをいくつも起動してしまうという問題は
Java SE 5 Tiger で解決しているよ。
Mustangでは２回目以降にアクセスしたJavaアプリが
バイトコードからネイティブコードに変換されるので
Ｃとほぼ変わらない速さ、場合によってはCでかかれたものより
高速に動かすことができるようになる。
>>57
Eclipseユーザの間では512MBは当たり前みたいだぞ。
>>59
-vmargs -Xmx256m な
をeclipse.exeのショートカットのプロパティに追加している。
もしくはこれをeclipse.iniに書いておくと。
漏れの場合 -DproxyHost=aaa -DProxyPort=3128 -Duser.name="aaaa"
みたいなのも追加しているが。
>>58
VM共有化、つまりアプリケーションを起動するたびに
VMをいくつも起動してしまうという問題は
Java SE 5 Tiger で解決しているよ。
Mustangでは２回目以降にアクセスしたJavaアプリが
バイトコードからネイティブコードに変換されるので
Ｃとほぼ変わらない速さ、場合によってはCでかかれたものより
高速に動かすことができるようになる。
>>57
Eclipseユーザの間では512MBは当たり前みたいだぞ。
>>59
-vmargs -Xmx256m な
をeclipse.exeのショートカットのプロパティに追加している。
もしくはこれをeclipse.iniに書いておくと。
漏れの場合 -DproxyHost=aaa -DProxyPort=3128 -Duser.name="aaaa"
みたいなのも追加しているが。
>>60
もれの場合XPでLunaスキンを無効にして
Win2000のときとかわらないような奴にして
Windowsの「テーマ」サービスを停止させている。
これである程度高速化する。
詳しくはWindows処方箋にて
もれの場合XPでLunaスキンを無効にして
Win2000のときとかわらないような奴にして
Windowsの「テーマ」サービスを停止させている。
これである程度高速化する。
詳しくはWindows処方箋にて
eclipseのvmargsはデフォだな。ある程度大きいもの作ってるといきなりeclipseがこける。
JAVA製GUIアプリを動かすPCの推奨スペックっていかほど？
皆はどんなPC使ってるん？
皆はどんなPC使ってるん？
>>67
CPU：出来るだけ速いやつ
メモリ：積めるだけたくさん
HDD：容量でかいほど素敵
Javaは言語としては好きなんだが、
.netじゃないC++なんかと比較すると、
かなりハードのスペックを要求するのは間違いないな…
個人的にはC#に期待してたんだが、
そのもっさり感に幻滅したし。
CPU：出来るだけ速いやつ
メモリ：積めるだけたくさん
HDD：容量でかいほど素敵
Javaは言語としては好きなんだが、
.netじゃないC++なんかと比較すると、
かなりハードのスペックを要求するのは間違いないな…
個人的にはC#に期待してたんだが、
そのもっさり感に幻滅したし。
>>69 俺としては十分だと思う。
Java 5.0ならswingのGUIアプリもサクサク動くよ。
Java 5.0ならswingのGUIアプリもサクサク動くよ。
MacのJRE5.0 でメモリ256MBしか積んでないけど
起動が少し遅い以外はレスポンスでイラっとくるようなことはないよ。
eclipseサクサク動かすには無理あるけど。
javaw.exeがだいたい30～60MBくらい食うから
WinでXPだと512欲しいけど、それ以外なら384MBもあれば余裕。
起動が少し遅い以外はレスポンスでイラっとくるようなことはないよ。
eclipseサクサク動かすには無理あるけど。
javaw.exeがだいたい30～60MBくらい食うから
WinでXPだと512欲しいけど、それ以外なら384MBもあれば余裕。
73 ：仕様書無しさん：2005/11/25(金) 12:14:03
>>69
おれPentiumM1.66GHz搭載したノート持ってるんだけど
それでJavaはメモリ512MBで問題なく動く。
Sempron 2600+と
Pentium M 1.66GHzってどっちが早い？
ノートPCのCPUはよくよーわからんて
Mはかなり早く2GHz以上に相当するらしいが
おれPentiumM1.66GHz搭載したノート持ってるんだけど
それでJavaはメモリ512MBで問題なく動く。
Sempron 2600+と
Pentium M 1.66GHzってどっちが早い？
ノートPCのCPUはよくよーわからんて
Mはかなり早く2GHz以上に相当するらしいが
75 ：仕様書無しさん：2005/11/25(金) 18:18:08
>>74
その辺りのCPUは全く問題ないとして、、
（ベンチではPentiumM1.66が勝つと思う）
500MHz以下で動いてる人っているかな？
PentiumⅢ 800MHzだと普通に動いたけど
それ以下のスペックのPCが無い（あったけど処分した）
からわからん。
その辺りのCPUは全く問題ないとして、、
（ベンチではPentiumM1.66が勝つと思う）
500MHz以下で動いてる人っているかな？
PentiumⅢ 800MHzだと普通に動いたけど
それ以下のスペックのPCが無い（あったけど処分した）
からわからん。
ブラウザで閲覧していて、急に重くなったかと思うとタスクバーに
コーヒーカップが現れた瞬間に殺意を覚える。
コーヒーカップが現れた瞬間に殺意を覚える。
Web閲覧の注意はJAVAのほうはまず確実にオフ推奨されてるしな
まぁ大抵はFlashで済むし 役立たないよな・・・・
まぁ大抵はFlashで済むし 役立たないよな・・・・
>>75
昔Eclipse2.0をClassicAthlon 750MHz メモリ256MBで
動かしてることがあったが、最初だけ軽くて
プラグイン大量にいれてプロジェクト内にファイル沢山いれてると、
あれは重たかった。
Classic Athlon は二次キャッシュがCPUの外側にあるので
その分パフォーマンスが低下し実際のクロック数が3分の1以下に
なると言われていた。
実際のところそのとおりで
後から出たAthlon Thunderbirdのほうが早かった。
今ではAthlon XP 3200+ を使っているから関係ないが。
昔Eclipse2.0をClassicAthlon 750MHz メモリ256MBで
動かしてることがあったが、最初だけ軽くて
プラグイン大量にいれてプロジェクト内にファイル沢山いれてると、
あれは重たかった。
Classic Athlon は二次キャッシュがCPUの外側にあるので
その分パフォーマンスが低下し実際のクロック数が3分の1以下に
なると言われていた。
実際のところそのとおりで
後から出たAthlon Thunderbirdのほうが早かった。
今ではAthlon XP 3200+ を使っているから関係ないが。
>>77
そのJavaはMS製Javaじゃないかな。
MS製のJavaはセキュリティを無視したJavaで偽Javaってところ。
JVMもMS製だと信用できない。しかもＩＥは
Javaを、ActiveXの一部だと見なしてしまっている。
VJ++で作られた似て非なるMS製Javaであるが、これはセキュリティ上欠陥があるから
オフに推奨されてしまう。
だが、本当のJavaはオフにしなくても問題ない。サンドボックスがあるし
署名機能がある。
今なら、最新のSun 純正Javaなら問題なし。
セキュリティにも強いし。
それにJavaWebStartを起動するとJavaのインストールを促される。
だがこれはJavaAppletではないので、
MS IEによってActiveXと勘違いされてしまうとかのセキュリティじょうの
問題もない。
そのJavaはMS製Javaじゃないかな。
MS製のJavaはセキュリティを無視したJavaで偽Javaってところ。
JVMもMS製だと信用できない。しかもＩＥは
Javaを、ActiveXの一部だと見なしてしまっている。
VJ++で作られた似て非なるMS製Javaであるが、これはセキュリティ上欠陥があるから
オフに推奨されてしまう。
だが、本当のJavaはオフにしなくても問題ない。サンドボックスがあるし
署名機能がある。
今なら、最新のSun 純正Javaなら問題なし。
セキュリティにも強いし。
それにJavaWebStartを起動するとJavaのインストールを促される。
だがこれはJavaAppletではないので、
MS IEによってActiveXと勘違いされてしまうとかのセキュリティじょうの
問題もない。
DB本体よりインストーラのほうが重たいOracleﾜﾛｽ
本体も9i以降すさまじいよ・・・
>>83
逆に余裕な人のスペック知りたいな。
逆に余裕な人のスペック知りたいな。
頻繁に実行するわけではないソフトの
応答速度が重視されないのは当然の事かと
応答速度が重視されないのは当然の事かと
そんな理屈つけなくても、Oracleのインストーラーは重いでいいじゃん。
Oracleのインストーラーが重い＝Javaが重いって言う訳じゃないんだしさ。
Oracleのインストーラーが重い＝Javaが重いって言う訳じゃないんだしさ。
90 ：仕様書無しさん：2005/11/29(火) 11:26:41
ウィルススキャンを入れておくと恐ろしく遅くなるな＞Java AP
DBA Studioとかも重い。
周辺ツールもJava化したものは殆ど使えない＜Oracle
周辺ツールもJava化したものは殆ど使えない＜Oracle
>>85
OTN知らないの？
OTN知らないの？
Oracleってフリーで使えるようになりませんでしたっけ。
ttp://itpro.nikkeibp.co.jp/article/USNEWS/20051102/223913/
ttp://itpro.nikkeibp.co.jp/article/USNEWS/20051102/223913/
>>94
今は日本語対応なしだから、日本人は来年までお預けだけどね。
今は日本語対応なしだから、日本人は来年までお預けだけどね。
Oracleのアニンストーラーは糞でOracleをヴァージョンアップするには
OSのクリーンインストールが必要だとか聞いたことがあるんですが、
悪質なデマですよね？
OSのクリーンインストールが必要だとか聞いたことがあるんですが、
悪質なデマですよね？
>>92
そんなことで素人扱いするとは失礼な奴だな
そんなことで素人扱いするとは失礼な奴だな
98 ：仕様書無しさん：2005/11/29(火) 20:26:43
99 ：仕様書無しさん：2005/11/29(火) 20:52:56
重い重いってちゃんと量ったの?
俺、ノートPCにインストして重さ量ってみたけどかわらんかったよ?
よっぽどいい量り使わないとわからないくらいの違いだよ!!
俺、ノートPCにインストして重さ量ってみたけどかわらんかったよ?
よっぽどいい量り使わないとわからないくらいの違いだよ!!
oracle8iってさー、pen4で動かないんだよ。
そうか、Javaが重いんじゃなくて、
Oracleが重かったんだよ！！！！！１１
Oracleが重かったんだよ！！！！！１１
かなりJava好きの俺だが、全面的に軽いとは言えないよ。
Swingでグラフィックビューア作ってみ。
絶対にネイティブに勝てないから。
Swingでグラフィックビューア作ってみ。
絶対にネイティブに勝てないから。
ネイティブと比べるのは気の毒だと思うが。
.NETより速い？
.NETより速い？
いや、.NETの方が軽いと思うよ。
WIndows上なら.NETで決まりだな。
WIndows上なら.NETで決まりだな。
>>94
9i/10g 製品版でも、評価目的であれば OTN からダウンロード可。
>>96
Oracle をアンインストールするには、
インストーラですべての製品を削除した後
“手動で” レジストリとファイルを削除しないといけない。
9i/10g 製品版でも、評価目的であれば OTN からダウンロード可。
>>96
Oracle をアンインストールするには、
インストーラですべての製品を削除した後
“手動で” レジストリとファイルを削除しないといけない。
ネイティヴには勝てないよそりゃ・・・。
.NETよりも若干もっさりしてることも確かだと思う。
ようは適材適所ってこった。
.NETよりも若干もっさりしてることも確かだと思う。
ようは適材適所ってこった。
ネイティブの速度には勝てなくても、JPEGデコーダがクソのろいとか、
画面いっぱいにイメージの描画をすると明らかに遅いとか、
もっと何とかならないか、と思うよ。
試しに同じようなのをQuickTimeで実装したらあまりに速くて笑ったし。
画面いっぱいにイメージの描画をすると明らかに遅いとか、
もっと何とかならないか、と思うよ。
試しに同じようなのをQuickTimeで実装したらあまりに速くて笑ったし。
以前遊びでお絵かきソフトを作ってみたことがあるが、Java (Swing) と
C++ (MFC) とでは同じようなコードを書いているはずなのに、動作速度が
全然違うのな。
C++ (MFC) とでは同じようなコードを書いているはずなのに、動作速度が
全然違うのな。
110 ：仕様書無しさん：2005/12/01(木) 01:47:26
っていうか>>1が一番重たい
デブはこれだから自己管理能力がないから
メモリ管理能力を過信してガーベッジコレクタなんて
いらないと言いだす。メモリ管理もろくにできないくせに
デブな>>1はいっちょまえに「ガーベッジコレクタなんていらね」
なんていってんじゃねえよ。
キモヲタデブはこれだから40歳代でメモリリークして早死にする。
デブはこれだから自己管理能力がないから
メモリ管理能力を過信してガーベッジコレクタなんて
いらないと言いだす。メモリ管理もろくにできないくせに
デブな>>1はいっちょまえに「ガーベッジコレクタなんていらね」
なんていってんじゃねえよ。
キモヲタデブはこれだから40歳代でメモリリークして早死にする。
111 ：仕様書無しさん：2005/12/01(木) 01:49:54
>>103
開発に使用したJavaのバージョンはいくつだ？
Tigerで動かせばかなり高速化するし
コンパイルもTigerでやり直せばさらに早くなる。
あとはメモリの扱い次第。
画像扱うってことはFlyWeightパターンとか上手に
使ってるんだろな？
開発に使用したJavaのバージョンはいくつだ？
Tigerで動かせばかなり高速化するし
コンパイルもTigerでやり直せばさらに早くなる。
あとはメモリの扱い次第。
画像扱うってことはFlyWeightパターンとか上手に
使ってるんだろな？
>>111
いや C/C++ だとデザパタとか特に考慮しなくてもそれなりに速いから。
よっぽど巨大なデータを扱わない限りは。
（もちろんそこに高速化チューニングを施せばさらに速くなる）
C/C++ の感覚でこれくらいならまあ大丈夫かなと思って Java で実装すると
意外にもっさりしててびっくりする。
いや C/C++ だとデザパタとか特に考慮しなくてもそれなりに速いから。
よっぽど巨大なデータを扱わない限りは。
（もちろんそこに高速化チューニングを施せばさらに速くなる）
C/C++ の感覚でこれくらいならまあ大丈夫かなと思って Java で実装すると
意外にもっさりしててびっくりする。
nativeのCと、VMで動いてるJavaを比較する時点で
そもそも比較レベルがおかしいってことにいい加減気づけよ
そもそも比較レベルがおかしいってことにいい加減気づけよ
気がついていてわかってやっている人と、気が付いていない人の双方がいる様に思えるな
インタプリタ言語が重いのはあたりまえだろ
>>115
「実行時コンパイル」というメカニズムもまた、あたりまえですね。
「実行時コンパイル」というメカニズムもまた、あたりまえですね。
画像処理に関してはDirextXが動かないことがJavaで遅い原因
118 ：仕様書無しさん：2005/12/11(日) 09:29:57
119 ：仕様書無しさん：2005/12/11(日) 11:40:05
少なくともEJBは重い。
120 ：仕様書無しさん：2005/12/11(日) 12:05:55
重いのはJAVA厨の頭の中
ごみの指向で脳みそ満タン
パーより始末が悪い
ごみの指向で脳みそ満タン
パーより始末が悪い
ものすごい知的な煽り。
すごく馬鹿そうな煽り
123 ：仕様書無しさん：2005/12/11(日) 14:05:19
>>112
> >>111
> いや C/C++ だとデザパタとか特に考慮しなくてもそれなりに速いから。
> よっぽど巨大なデータを扱わない限りは。
>>111==>>103が人の話をちゃんと聞いてるかどうか不明だが
C++だとデザインパターンを考慮しなくてもそれなりに速い？
それをやらなくても開発速度が速いのではなく実行速度が速くなると？
当たり前だろうが。デザインパターンを使わないで
一つのクラスに全ての処理を書いてしまえば若干速くなる。
その代わり開発速度は徐々に衰えてゆく。
はてはて>>111==>>103が具体的に遅いと主張しているJavaのバージョンを
明記しないで意味不明な適当な返答をして誤魔化していると思われる点について
> >>111
> いや C/C++ だとデザパタとか特に考慮しなくてもそれなりに速いから。
> よっぽど巨大なデータを扱わない限りは。
>>111==>>103が人の話をちゃんと聞いてるかどうか不明だが
C++だとデザインパターンを考慮しなくてもそれなりに速い？
それをやらなくても開発速度が速いのではなく実行速度が速くなると？
当たり前だろうが。デザインパターンを使わないで
一つのクラスに全ての処理を書いてしまえば若干速くなる。
その代わり開発速度は徐々に衰えてゆく。
はてはて>>111==>>103が具体的に遅いと主張しているJavaのバージョンを
明記しないで意味不明な適当な返答をして誤魔化していると思われる点について
124 ：仕様書無しさん：2005/12/11(日) 14:29:45
Javaとネイティブの差はDB管理コンソールの起動時間で顕著
M$のS$$$$$$$r管理コンソールの起動時間0.1秒
O$$$$Eの管理コンソールの起動時間 ????秒の差
コードを最適化しても埋められないこの差
いくらJAVAが優れるいると触れ回っても説得力なし
そんなにJAVAが優れているなら起動時間で互角になるように
チューニングしてみせてくれよ。そのときは認めてやるから。
絶対に無理だけどなw
M$のS$$$$$$$r管理コンソールの起動時間0.1秒
O$$$$Eの管理コンソールの起動時間 ????秒の差
コードを最適化しても埋められないこの差
いくらJAVAが優れるいると触れ回っても説得力なし
そんなにJAVAが優れているなら起動時間で互角になるように
チューニングしてみせてくれよ。そのときは認めてやるから。
絶対に無理だけどなw
125 ：仕様書無しさん：2005/12/11(日) 14:33:45
>>124
確かJDK1.6あたりで、常駐Javaデーモンを作っといて、JVMの初期化を
済ませといて、あとはforkみたいなことして各アプリを起動する、とい
う方針が採用されるような。
そうなったら、OS起動時にJVM初期化の時間が取られるようになるけど、
Javaアプリケーション起動時の時間はネイティブアプリ起動と大して
変わらなくなりそうなきがする。
確かJDK1.6あたりで、常駐Javaデーモンを作っといて、JVMの初期化を
済ませといて、あとはforkみたいなことして各アプリを起動する、とい
う方針が採用されるような。
そうなったら、OS起動時にJVM初期化の時間が取られるようになるけど、
Javaアプリケーション起動時の時間はネイティブアプリ起動と大して
変わらなくなりそうなきがする。
126 ：仕様書無しさん：2005/12/11(日) 14:39:15
デザインパターンの基礎から勉強しろ。
デザインパターンと速度が直接関係するわけねーじゃん。
パフォーマンスを最重要視しているデザインパターンを列挙してみな。
できねーだろ。
大抵のデザパタは、汎用的な設計でチューニングは眼中にないんよ。
デザインパターンと速度が直接関係するわけねーじゃん。
パフォーマンスを最重要視しているデザインパターンを列挙してみな。
できねーだろ。
大抵のデザパタは、汎用的な設計でチューニングは眼中にないんよ。
127 ：仕様書無しさん：2005/12/11(日) 14:50:54
>>125
JRE をインスコしただけで常駐して、例え Java プログラムを起動してなくても
CPU やメモリを消費するのか・・・。
なんかヤだな。
まあ窓の手や TweakUI あたりが速攻対応して OFF にできるようにしてくれそうだけど。
JRE をインスコしただけで常駐して、例え Java プログラムを起動してなくても
CPU やメモリを消費するのか・・・。
なんかヤだな。
まあ窓の手や TweakUI あたりが速攻対応して OFF にできるようにしてくれそうだけど。
そうなったらJREアニンスコだな。
正直言って入っていなくても困らんから。
正直言って入っていなくても困らんから。
131 ：仕様書無しさん：2005/12/11(日) 17:32:37
>>130
RPCがからんでいる分散アプリケーションで、J2EEパターンに記載されている
ようなことを気をつけないでコーディングすれば、ナニで書いても遅くなるに
決まってるんだが。言語関係無いよあれ。
RPCがからんでいる分散アプリケーションで、J2EEパターンに記載されている
ようなことを気をつけないでコーディングすれば、ナニで書いても遅くなるに
決まってるんだが。言語関係無いよあれ。
>>131
あ、ごめん、だから、そこまでの話をしてなくて、単純に緩い突込みだ。
あ、ごめん、だから、そこまでの話をしてなくて、単純に緩い突込みだ。
133 ：仕様書無しさん：2005/12/13(火) 01:29:27
なんでもいいけど、デザパタって「デザートにパスタ」の略か？
デザートにパンナコッタじゃね？
>>124
SQLServerとOracleを選ぶなら
賢い奴はOracleを選ぶ。
そんな理由だけでSQLServerを選ぶのは
非常にみっともないことだよ。
だいいち、GUIなんかに頼らずシェルを使って
自分で処理するのが当たり前だ。そんなものに頼ること自体浅はか
SQLServerとOracleを選ぶなら
賢い奴はOracleを選ぶ。
そんな理由だけでSQLServerを選ぶのは
非常にみっともないことだよ。
だいいち、GUIなんかに頼らずシェルを使って
自分で処理するのが当たり前だ。そんなものに頼ること自体浅はか
140 ：仕様書無しさん：2005/12/13(火) 17:54:59
JMeterって糞重い
142 ：仕様書無しさん：2005/12/14(水) 01:13:59
いくつかツール動かして開発してて、さて、WTK起動するかってメニューで
起動したが、音沙汰なし。
トイレに行って帰ってきたら、起動中画面が出てて、しばらくメール書いて
たら、やっと起動した。
Javaって一体。。。
起動したが、音沙汰なし。
トイレに行って帰ってきたら、起動中画面が出てて、しばらくメール書いて
たら、やっと起動した。
Javaって一体。。。
>>141
Java厨のﾏﾝｾｰするJakartaですらあのざま
Java厨のﾏﾝｾｰするJakartaですらあのざま
そういや、大昔にHotJavaとかいうゴミみたいなブラウザがあったな。
IEをゴミ扱いするJava厨の諸君よ。ここはひとつ、Javaでブラウザを
作ってみないか？セキュリティ万全のJavaなら、IEのような穴だらけではなく
完璧なブラウザが作れるだろう。
IEをゴミ扱いするJava厨の諸君よ。ここはひとつ、Javaでブラウザを
作ってみないか？セキュリティ万全のJavaなら、IEのような穴だらけではなく
完璧なブラウザが作れるだろう。
IEはゴミだけど、Javaでブラウザは無理がある。
以前openoffice使ってたけど重かった。
体感的にjavaで作られたプログラムは重いような気がするので
あんまり好きじゃないな。
体感的にjavaで作られたプログラムは重いような気がするので
あんまり好きじゃないな。
OpenOfficeは一部Javaを使ってるが、ほぼC++だよ。
重いのはJavaのせいじゃない。
重いのはJavaのせいじゃない。
148 ：仕様書無しさん：2005/12/14(水) 21:16:20
Javaは遅いね。
客からクレームでまくりで困ってます。
客からクレームでまくりで困ってます。
マジで。
お前の実装が悪いんだよ
株関係はどこも大変だよ。マジで。
152 ：仕様書無しさん：2005/12/14(水) 22:39:26
Javaって、マジで使えない。
C並に速いって話だったけど、全然遅い。リソース食いまくるし。
オブジェクト指向でPerlと違ってコードの保守性が良いって話しだったけど、
ﾄﾞｶﾀどもはフレームワークの吐くメソッドの中にどこからかかっぱらってきた
コードをペーストするだけ。数千行のメソッドなんてありえない。
O/Rマッピングとか使うから、DBのチューニングをしようにもどんなSQLが
どんなタイミングで発行されているのかわかりにくい。
マジで酷い。何とかしてくれ。
C並に速いって話だったけど、全然遅い。リソース食いまくるし。
オブジェクト指向でPerlと違ってコードの保守性が良いって話しだったけど、
ﾄﾞｶﾀどもはフレームワークの吐くメソッドの中にどこからかかっぱらってきた
コードをペーストするだけ。数千行のメソッドなんてありえない。
O/Rマッピングとか使うから、DBのチューニングをしようにもどんなSQLが
どんなタイミングで発行されているのかわかりにくい。
マジで酷い。何とかしてくれ。
数千行のメソッドなんてマジでありえない。COBOL/VB並。
誰か助けて
誰か助けて
昔インド人の書いたソースに//GiveUpって書いてあった(実話)
>>142
パフォーマンスが鈍っている考えられる理由
●マシンスペックが重たい。CPUが足りない。
●メモリが足りない。
●無駄なサービスを起動している。
●JVMのバージョンが古い。
●バイトコードをコンパイルしたコンパイラのバージョンが古い。
●メモリの規格が古い。DDR SDRAMではなくただのSDRAM DIMMまたはSDRAM SIMM時代のもの。
●メモリのキャッシュレイテンシがでかい。
●メモリがPC3200以上でない。いまだにPC100, PC133程度のレベル。
●余計な常駐プログラムが起動している。
●余計なスパイウェアが起動している。Notron Internet Security, Systemworksなどで駆除せよ。
●無駄に重たいソフトを大量に起動している。
●レジストリにゴミが大量に残っている。
●Java起動オプションの最大ヒープメモリサイズを32MB未満に設定している。
●そのプログラムを作った者の腕が悪い。
●他のJava以外のプログラムがメモリリークを引き起こしている。
パフォーマンスが鈍っている考えられる理由
●マシンスペックが重たい。CPUが足りない。
●メモリが足りない。
●無駄なサービスを起動している。
●JVMのバージョンが古い。
●バイトコードをコンパイルしたコンパイラのバージョンが古い。
●メモリの規格が古い。DDR SDRAMではなくただのSDRAM DIMMまたはSDRAM SIMM時代のもの。
●メモリのキャッシュレイテンシがでかい。
●メモリがPC3200以上でない。いまだにPC100, PC133程度のレベル。
●余計な常駐プログラムが起動している。
●余計なスパイウェアが起動している。Notron Internet Security, Systemworksなどで駆除せよ。
●無駄に重たいソフトを大量に起動している。
●レジストリにゴミが大量に残っている。
●Java起動オプションの最大ヒープメモリサイズを32MB未満に設定している。
●そのプログラムを作った者の腕が悪い。
●他のJava以外のプログラムがメモリリークを引き起こしている。
違う違う。重いのは開発環境じゃないよ！JSP/Servletのほうだよ。
アクセスの集中するようなサイトじゃとてもつかえないよ？
アクセスの集中するようなサイトじゃとてもつかえないよ？
160 ：仕様書無しさん：2005/12/15(木) 09:00:50
LinuxでのgccとJavaを比べた場合を考えてみよう。
たとえば速度重視のルーターファームのようなプログラム。
これはJavaは無理だ。Cでも上手く組まないと厳しい。
次に電話の交換機。
これは上手く作ってチューニングもすれば、どうにかいける。
ただ作るアプリだけでなく、JavaVMの動作やチューニングについても知っている必要がある。
次にデパートの売上管理など。
これはJavaで十分だ。チューニングもメモリ増やすぐらいで十分。
次にWEBサイト。
むしろJavaの方がいい。はっきりいってスピードは問題ない。
問題があるとしたらアプリの作りの問題だ。
多分多くの人は、デパートの売上管理やWEBサイトをやっていると思うので、
スピードに問題があるとしたら言語の限界性能でなく、作りの問題だろう。
交換機をやっている人も一部には多いと思うが、ここが分かれ目って所かな。
つまり業務系でCやっていた人はJavaに変わったって事かな。
ファーム系の一部にJavaの波が押し寄せ、ファームのC使いが慌てているのだろう。
「Javaって重くね？」と言う言葉は、「ファーム系C使いのJavaをやらない理由」に良く聞かれる。
たとえば速度重視のルーターファームのようなプログラム。
これはJavaは無理だ。Cでも上手く組まないと厳しい。
次に電話の交換機。
これは上手く作ってチューニングもすれば、どうにかいける。
ただ作るアプリだけでなく、JavaVMの動作やチューニングについても知っている必要がある。
次にデパートの売上管理など。
これはJavaで十分だ。チューニングもメモリ増やすぐらいで十分。
次にWEBサイト。
むしろJavaの方がいい。はっきりいってスピードは問題ない。
問題があるとしたらアプリの作りの問題だ。
多分多くの人は、デパートの売上管理やWEBサイトをやっていると思うので、
スピードに問題があるとしたら言語の限界性能でなく、作りの問題だろう。
交換機をやっている人も一部には多いと思うが、ここが分かれ目って所かな。
つまり業務系でCやっていた人はJavaに変わったって事かな。
ファーム系の一部にJavaの波が押し寄せ、ファームのC使いが慌てているのだろう。
「Javaって重くね？」と言う言葉は、「ファーム系C使いのJavaをやらない理由」に良く聞かれる。
161 ：仕様書無しさん：2005/12/15(木) 09:18:04
すまん、昨日の書きかけをUPしたんで、WEBで遅いって言っている人のメッセージを見てなかった。
WEBで遅いって言っているのはスキルのなさを告白しているだけだから気をつけた方がいいよ。
あとWEBでアクセス集中の時はエラーにするんだよ。
業務系でエラーにできないようなのはキューにしてね。
Jspで遅いって言っている人は実環境で運用する時、Jspはコンパイルしておくように。
WEBで遅いって言っているのはスキルのなさを告白しているだけだから気をつけた方がいいよ。
あとWEBでアクセス集中の時はエラーにするんだよ。
業務系でエラーにできないようなのはキューにしてね。
Jspで遅いって言っている人は実環境で運用する時、Jspはコンパイルしておくように。
162 ：仕様書無しさん：2005/12/15(木) 09:38:49
Webでレスポンスタイムが遅いっていっているシステムをのぞいてみたら、
1リクエストでループ内部で30000回、SQLリクエストを投げていました…
こういうことってよくあるんでしょうか？
可読性優先の設計書の記載をそのままソースコードにしちゃうと、RPCが
発生する(=オーバーヘッドが大きい)呼び出しをループ内部に埋めることに
なっちゃう、なんてのはよくあることと思うけど、そういうことをわかって
いる人がチェックしないものなんですかね？
1リクエストでループ内部で30000回、SQLリクエストを投げていました…
こういうことってよくあるんでしょうか？
可読性優先の設計書の記載をそのままソースコードにしちゃうと、RPCが
発生する(=オーバーヘッドが大きい)呼び出しをループ内部に埋めることに
なっちゃう、なんてのはよくあることと思うけど、そういうことをわかって
いる人がチェックしないものなんですかね？
163 ：仕様書無しさん：2005/12/15(木) 09:56:05
WEBで遅くないって言っているのは神経が麻痺しているのを告白しているだけだから
気をつけたほうがいいよw
気をつけたほうがいいよw
164 ：仕様書無しさん：2005/12/15(木) 10:04:10
最近のリッチクライアントって、クライアントプロセスの起動を
ブラウザが行うっていうだけで、要するにC/Sなんでしょ？
なんで昔の枯れたやり方に回帰しないで、ブラウザ上でのクライ
アント起動を選択しようとする流れになるんだか、分けわかんな
いんだけど。
「新技術=売りになる」マーケティング馬鹿(中身なし)の情報操作
なんじゃないかと思うんだよなあ…
VBでいいじゃんよ。
ブラウザが行うっていうだけで、要するにC/Sなんでしょ？
なんで昔の枯れたやり方に回帰しないで、ブラウザ上でのクライ
アント起動を選択しようとする流れになるんだか、分けわかんな
いんだけど。
「新技術=売りになる」マーケティング馬鹿(中身なし)の情報操作
なんじゃないかと思うんだよなあ…
VBでいいじゃんよ。
165 ：仕様書無しさん：2005/12/15(木) 10:22:31
いやだからさ
Webサービスをネイティブリッチクラインとが直接使う時代がくれば
JAVAは便所のうんこになる。流されてばいばい。
Webサービスをネイティブリッチクラインとが直接使う時代がくれば
JAVAは便所のうんこになる。流されてばいばい。
>>162
それに対する修正は当然行われるべきリファクタリングで、それはチューニング
とすら呼ばれない。
発見、変更範囲の局所化、修正とどれをとっても容易く、特別な人員は要らない。
それすら行われないまま納品されるのは、開発陣のレベルが異常に低かったと
しか言い様がない。
それに対する修正は当然行われるべきリファクタリングで、それはチューニング
とすら呼ばれない。
発見、変更範囲の局所化、修正とどれをとっても容易く、特別な人員は要らない。
それすら行われないまま納品されるのは、開発陣のレベルが異常に低かったと
しか言い様がない。
167 ：69式フリーPG ◆hND3Lufios ：2005/12/15(木) 21:02:35
>>164
クライアントのスマート化/ダム化という流行は交互に訪れる。
別スレで「これって壮大な詐欺なんじゃ？」って書いた事があるんだけど、そういう事ｗ
集中型/分散型、インソーシング/アウトソーシング、ビルド/レントなんかも交互にや
ってくる辺りが同じく詐欺くせぇｗ
それはそれとして、WEBアプリはダム化の流れなんだろうと思う。
ただ、実務上MS Officeは手放せないってところも多くて、そうすると一部のアプリだ
けダム化という訳分からん状況になる(て言うか、なってる)。
日本ユニシスがITJだったかDoMだったかで「管理コストってインストール費用の事
か？ｗ」みたいな記事を(勿論、もっと上品な表現で)書いてたが、実際「C/Sはレガ
シーでWEBはモダン」というイメージ戦略の賜物なんだろう。
余談だが、この日本ユニシスという会社は、WEBでC/Sやって何が悪い？と最初に
豪語した企業だ。最初は、何か馬鹿な事を言ってる奴が居るなとか思ってたけど
今思うと裸の王様に出てくる少年だったのかも？とも思える。
クライアントのスマート化/ダム化という流行は交互に訪れる。
別スレで「これって壮大な詐欺なんじゃ？」って書いた事があるんだけど、そういう事ｗ
集中型/分散型、インソーシング/アウトソーシング、ビルド/レントなんかも交互にや
ってくる辺りが同じく詐欺くせぇｗ
それはそれとして、WEBアプリはダム化の流れなんだろうと思う。
ただ、実務上MS Officeは手放せないってところも多くて、そうすると一部のアプリだ
けダム化という訳分からん状況になる(て言うか、なってる)。
日本ユニシスがITJだったかDoMだったかで「管理コストってインストール費用の事
か？ｗ」みたいな記事を(勿論、もっと上品な表現で)書いてたが、実際「C/Sはレガ
シーでWEBはモダン」というイメージ戦略の賜物なんだろう。
余談だが、この日本ユニシスという会社は、WEBでC/Sやって何が悪い？と最初に
豪語した企業だ。最初は、何か馬鹿な事を言ってる奴が居るなとか思ってたけど
今思うと裸の王様に出てくる少年だったのかも？とも思える。
>>159
解決方法
●JVMのバージョンを5.0以上にする。
●Tomcatのバージョンを5.5以上にする。
●5.0以降のコンパイラでコンパイルする。
●Servletから呼び出すユーティリティクラスは拡張子classの
ままにしておくのではなく一つのjarにまとめて圧縮しておく。
●Servlet, web.xmlがあるwebappsに置いているコンテキストディレクトリは
拡張子warのファイル(Web Archive)にまとめておく。
●RDBMSだけでできることはできる限りRDBMSに任せる。
●java.lang.ref.SoftReferenceを使う。
●Tomcatを起動する前にあらかじめJSPをコンパイルしておく。
●重たいロジックはServlet, JSP上には書かず、
Servlet, JSPとは関係ないユーティリティクラスに委譲する。
●Servletクラスが持つフィールドをを他のユーティリティクラスに
委譲しServletオブジェクトを軽くする。
●Lazy Load ルールを適用して一気に呼び出しをせず、
必要なときにだけ必要なものを呼び出せるようにする。
●設計を考え直す。
●プロファイラでボトルネックを探す。
●サーバ用メモリを増設しておく。起動オプションに-server, -Xmx1024mなどを指定しておく。
●データベースアクセスにはTomcatのデータソース機能を使い、server.xmlに
あらかじめ必要なものを記述しておく。
●複数のクラスに重複する共通部分がある場合はその共通部分を一つのクラスに
委譲する。(当たり前のことか)。
●volatileを使う。
解決方法
●JVMのバージョンを5.0以上にする。
●Tomcatのバージョンを5.5以上にする。
●5.0以降のコンパイラでコンパイルする。
●Servletから呼び出すユーティリティクラスは拡張子classの
ままにしておくのではなく一つのjarにまとめて圧縮しておく。
●Servlet, web.xmlがあるwebappsに置いているコンテキストディレクトリは
拡張子warのファイル(Web Archive)にまとめておく。
●RDBMSだけでできることはできる限りRDBMSに任せる。
●java.lang.ref.SoftReferenceを使う。
●Tomcatを起動する前にあらかじめJSPをコンパイルしておく。
●重たいロジックはServlet, JSP上には書かず、
Servlet, JSPとは関係ないユーティリティクラスに委譲する。
●Servletクラスが持つフィールドをを他のユーティリティクラスに
委譲しServletオブジェクトを軽くする。
●Lazy Load ルールを適用して一気に呼び出しをせず、
必要なときにだけ必要なものを呼び出せるようにする。
●設計を考え直す。
●プロファイラでボトルネックを探す。
●サーバ用メモリを増設しておく。起動オプションに-server, -Xmx1024mなどを指定しておく。
●データベースアクセスにはTomcatのデータソース機能を使い、server.xmlに
あらかじめ必要なものを記述しておく。
●複数のクラスに重複する共通部分がある場合はその共通部分を一つのクラスに
委譲する。(当たり前のことか)。
●volatileを使う。
>>162
> Webでレスポンスタイムが遅いっていっているシステムをのぞいてみたら、
> 1リクエストでループ内部で30000回、SQLリクエストを投げていました…
とんでもないコードだな。
そいつはSQLのことをよくわかってないんじゃないのか？
SQLのことをよく勉強すればループがカウントするたびにクエリを
投げるなんて非効率なことまずしない。
> Webでレスポンスタイムが遅いっていっているシステムをのぞいてみたら、
> 1リクエストでループ内部で30000回、SQLリクエストを投げていました…
とんでもないコードだな。
そいつはSQLのことをよくわかってないんじゃないのか？
SQLのことをよく勉強すればループがカウントするたびにクエリを
投げるなんて非効率なことまずしない。
>>164
最初の1,2文を呼んだだけでリッチクライアントのことを解ってないような。
今までブラウザからサーバに転送する作業を
行っていたものが、毎回サーバに転送するコストを省けてGUI側だけで
行えるものはGUIに任せるってものだよ。
サーバに負担をかけずかつパフォーマンスも良い
2chブラウザもリッチクライアントの一種だね。
ちょっとページを切り替えるためだけにサーバにリクエストを転送せずに
済むからパフォーマンスが良い。
最初の1,2文を呼んだだけでリッチクライアントのことを解ってないような。
今までブラウザからサーバに転送する作業を
行っていたものが、毎回サーバに転送するコストを省けてGUI側だけで
行えるものはGUIに任せるってものだよ。
サーバに負担をかけずかつパフォーマンスも良い
2chブラウザもリッチクライアントの一種だね。
ちょっとページを切り替えるためだけにサーバにリクエストを転送せずに
済むからパフォーマンスが良い。
RSSリーダなんかもリッチクライアントの一種。
今までHTMLブラウザだけでニュース記事を読んで
非常に読みづらかったものが
一覧性が高まって一括で記事をダウンロードすることで
簡単に複数の記事をメールのように素早く読み回せるようになった。
従来なら記事を捲るたびにリンクをクリックして
そのことをサーバに転送してその場で記事がダウンロードされるのを
待たなければならなかった。
今までHTMLブラウザだけでニュース記事を読んで
非常に読みづらかったものが
一覧性が高まって一括で記事をダウンロードすることで
簡単に複数の記事をメールのように素早く読み回せるようになった。
従来なら記事を捲るたびにリンクをクリックして
そのことをサーバに転送してその場で記事がダウンロードされるのを
待たなければならなかった。
173 ：69式フリーPG ◆hND3Lufios ：2005/12/15(木) 21:30:05
10年位前のVBやMS-Accessのコードは酷かった。
マジでSQLを何千回も投げて固まるようなのがゴロゴロしてた。
さすがに最近ではこなれてそう酷いのは見なくなったけど、やはりいつの時代も
おばかさんは居るもので、今はそういうおばかさんを引きつけてやまないのはJava。
流行モノに厨と似非業者が群れる。Javaが本当にいい感じになるのは、10年後かな。
マジでSQLを何千回も投げて固まるようなのがゴロゴロしてた。
さすがに最近ではこなれてそう酷いのは見なくなったけど、やはりいつの時代も
おばかさんは居るもので、今はそういうおばかさんを引きつけてやまないのはJava。
流行モノに厨と似非業者が群れる。Javaが本当にいい感じになるのは、10年後かな。
174 ：仕様書無しさん：2005/12/15(木) 22:38:14
10年後にはJAVAはないと予言する。
爺の知ったかはありがたくて泣けてくるよ。
>>176
本筋に反論できない間抜けにも泣けて…いや、笑うところか？
本筋に反論できない間抜けにも泣けて…いや、笑うところか？
Access/VBでのC/S時代もODBCに生のSQLが隠蔽されてチューニング
しにくいという問題点があったのだが、現代ではO/Rマッピングに隠蔽されて
同じことになってる。
jakartaのtorqueなんかの陰でどんなSQLが投げられているのか全く意識せずに、
ﾄﾞｶﾀはメソッドをﾊﾞｼﾊﾞｼ呼んでOracleにDOS攻撃。
しにくいという問題点があったのだが、現代ではO/Rマッピングに隠蔽されて
同じことになってる。
jakartaのtorqueなんかの陰でどんなSQLが投げられているのか全く意識せずに、
ﾄﾞｶﾀはメソッドをﾊﾞｼﾊﾞｼ呼んでOracleにDOS攻撃。
180 ：仕様書無しさん：2005/12/15(木) 23:08:57
いつの時代も問題の本質は何も変わっていない。
ただ、厨の集積所がVBからJavaに変わっただけ。
ただ、厨の集積所がVBからJavaに変わっただけ。
マジでVBも無くなりそうな勢いだね
M$はツールタダで配ってるけど、もう手遅れ。
M$はツールタダで配ってるけど、もう手遅れ。
182 ：仕様書無しさん：2005/12/15(木) 23:55:56
VB はもともとはホビイスト向けのおもちゃ言語だったわけだしな。
元の居場所に戻っただけだよ。
元の居場所に戻っただけだよ。
183 ：仕様書無しさん：2005/12/15(木) 23:58:38
>>173
> 10年位前のVBやMS-Accessのコードは酷かった。
> マジでSQLを何千回も投げて固まるようなのがゴロゴロしてた。
> さすがに最近ではこなれてそう酷いのは見なくなったけど、やはりいつの時代も
> おばかさんは居るもので、今はそういうおばかさんを引きつけてやまないのはJava。
ループ内でクエリを何千回も回す奴が馬鹿だか
それがJavaとは関係ないわけだが。
Javaが馬鹿だと思えるのかね。JavaとPHPとの違いもわからず根拠もなく
とにかくPHPやC++にリプレースすればパフォーマンスが上がって
コストが削減できて顧客満足度が増大すると妄信してC++やPHPを
押しつける奴のほうがよっぽど馬鹿だよ。
PHPはかなりのおばかさんだね。Javaは遅いからCに切り替えるだけで
コストもかからず速くなるんだと勘違いしている香具師もかなりもお馬鹿さんだがね。
それからPojoマンセーしてEJBやJBoss叩いてる奴もおばかさんだね。
> 10年位前のVBやMS-Accessのコードは酷かった。
> マジでSQLを何千回も投げて固まるようなのがゴロゴロしてた。
> さすがに最近ではこなれてそう酷いのは見なくなったけど、やはりいつの時代も
> おばかさんは居るもので、今はそういうおばかさんを引きつけてやまないのはJava。
ループ内でクエリを何千回も回す奴が馬鹿だか
それがJavaとは関係ないわけだが。
Javaが馬鹿だと思えるのかね。JavaとPHPとの違いもわからず根拠もなく
とにかくPHPやC++にリプレースすればパフォーマンスが上がって
コストが削減できて顧客満足度が増大すると妄信してC++やPHPを
押しつける奴のほうがよっぽど馬鹿だよ。
PHPはかなりのおばかさんだね。Javaは遅いからCに切り替えるだけで
コストもかからず速くなるんだと勘違いしている香具師もかなりもお馬鹿さんだがね。
それからPojoマンセーしてEJBやJBoss叩いてる奴もおばかさんだね。
>>177
何が言いたいんのかわからないが
> 最近のリッチクライアントって、クライアントプロセスの起動を
> ブラウザが行うっていうだけで、要するにC/Sなんでしょ？
この発言からして>>164がリッチクライアントというものがどういうものか
わかってないことは明白なわけだが。
何が言いたいんのかわからないが
> 最近のリッチクライアントって、クライアントプロセスの起動を
> ブラウザが行うっていうだけで、要するにC/Sなんでしょ？
この発言からして>>164がリッチクライアントというものがどういうものか
わかってないことは明白なわけだが。
>>180
> いつの時代も問題の本質は何も変わっていない。
> ただ、厨の集積所がVBからJavaに変わっただけ。
残念だがそれはクライアントサイドJavaだけに限る。
サーバサイドではVB厨の居所はない。
サーバサイド開発はGUI開発に比べ高いスキルを要求する。
最近、Eclipseに並んでNetBeansが話題になっている。
100%PureJavaなのに若干ネイティブを使っていてSwing/AWT
よりも軽いSWTを使っているから高速と言われていたＥｃｌｉｐｓｅよりも
NetBeansは速い。Javaを使っているとは思えないくらいに。
SunがVB開発者をJavaに惹き付けるという戦略を行っているようだが、
もしかすると、これはうまくいっているのかも知れない。
Eclipseが人気を博した影響でVB系開発環境の売上げは落ちてしまっている。
VS.NETの売上げも低迷している。そこでM$は焦ってVS.NET 2005 Expressを
一年間だけ無料で配布した。
ゆえにJavaの世界に厨が増えるのはこれからだよ。
だがJavaはVBよりも堅い言語なので厨にも堅牢さが増して賢い質の高い、
開発者が業界に増えることに期待したい。この現象によって
厨が質の高い開発者に成長するのではと期待したい。
> いつの時代も問題の本質は何も変わっていない。
> ただ、厨の集積所がVBからJavaに変わっただけ。
残念だがそれはクライアントサイドJavaだけに限る。
サーバサイドではVB厨の居所はない。
サーバサイド開発はGUI開発に比べ高いスキルを要求する。
最近、Eclipseに並んでNetBeansが話題になっている。
100%PureJavaなのに若干ネイティブを使っていてSwing/AWT
よりも軽いSWTを使っているから高速と言われていたＥｃｌｉｐｓｅよりも
NetBeansは速い。Javaを使っているとは思えないくらいに。
SunがVB開発者をJavaに惹き付けるという戦略を行っているようだが、
もしかすると、これはうまくいっているのかも知れない。
Eclipseが人気を博した影響でVB系開発環境の売上げは落ちてしまっている。
VS.NETの売上げも低迷している。そこでM$は焦ってVS.NET 2005 Expressを
一年間だけ無料で配布した。
ゆえにJavaの世界に厨が増えるのはこれからだよ。
だがJavaはVBよりも堅い言語なので厨にも堅牢さが増して賢い質の高い、
開発者が業界に増えることに期待したい。この現象によって
厨が質の高い開発者に成長するのではと期待したい。
>>183
彼(69式フリー君)はC/C++時代に慣れ親しんだ人間だから
最近のJava案件の多さにがっかりしてやりたくもないJava開発に
手を出さないと飯を食っていけないことに
苛立っているだけだよ。
C/C++を苦労して覚えた人間からすると
なぜ今更Javaなんて言語を覚えなくちゃいけないんだ
って気分になるらしい。その影響と最近のJavaとEclipseの
人気が彼らのような人間を焦らせてこんなスレが立ってしまうんだろう。
彼(69式フリー君)はC/C++時代に慣れ親しんだ人間だから
最近のJava案件の多さにがっかりしてやりたくもないJava開発に
手を出さないと飯を食っていけないことに
苛立っているだけだよ。
C/C++を苦労して覚えた人間からすると
なぜ今更Javaなんて言語を覚えなくちゃいけないんだ
って気分になるらしい。その影響と最近のJavaとEclipseの
人気が彼らのような人間を焦らせてこんなスレが立ってしまうんだろう。
>>179
> Access/VBでのC/S時代もODBCに生のSQLが隠蔽されてチューニング
> しにくいという問題点があったのだが、現代ではO/Rマッピングに隠蔽されて
> 同じことになってる。
> jakartaのtorqueなんかの陰でどんなSQLが投げられているのか全く意識せずに、
いまどきお前みたいにO-Rマッピングの話題でtorqueしか
持ち出せないのはモグリ。
O-Rマッピングがチューニングしにくいというなら
CayenneやHibernateを使いこなしてから文句を言ってくれ。
CayenneはGeneration Gapパターンというデザインパターンを
使っていて、コードの修正が容易だ。
HibernateはHQLというSQL文をJavaソースコードに直接書いて
パフォーマンスを高めることができる。
JavaOne Tokyo 2005でHibernate + Struts + PostgreSQLという組み合わせの
国際特許出願システムを開発した事例についてのセッションがあったが
Hibernateを使った結果、従来のJDBCべた書きよりもパフォーマンスが落ちて
読み込みだけで10秒もかかって全体のコード量が増えたと言っていた。
だが実際にはコードに関しては
自動生成コードを除くと自分で書いたコードは以前よりも最小限に済んだという
それだけは確実だ。開発効率は確実に上がった。
パフォーマンスのほうだが、Hibernateを使ったら重たくなったのかと思っていたが
ビューを作っただけで即座に解決した。パフォーマンスは10秒から1秒に
下がったという。
今そのセッションを見たときに書いたメモをここに書き写してみた。
> Access/VBでのC/S時代もODBCに生のSQLが隠蔽されてチューニング
> しにくいという問題点があったのだが、現代ではO/Rマッピングに隠蔽されて
> 同じことになってる。
> jakartaのtorqueなんかの陰でどんなSQLが投げられているのか全く意識せずに、
いまどきお前みたいにO-Rマッピングの話題でtorqueしか
持ち出せないのはモグリ。
O-Rマッピングがチューニングしにくいというなら
CayenneやHibernateを使いこなしてから文句を言ってくれ。
CayenneはGeneration Gapパターンというデザインパターンを
使っていて、コードの修正が容易だ。
HibernateはHQLというSQL文をJavaソースコードに直接書いて
パフォーマンスを高めることができる。
JavaOne Tokyo 2005でHibernate + Struts + PostgreSQLという組み合わせの
国際特許出願システムを開発した事例についてのセッションがあったが
Hibernateを使った結果、従来のJDBCべた書きよりもパフォーマンスが落ちて
読み込みだけで10秒もかかって全体のコード量が増えたと言っていた。
だが実際にはコードに関しては
自動生成コードを除くと自分で書いたコードは以前よりも最小限に済んだという
それだけは確実だ。開発効率は確実に上がった。
パフォーマンスのほうだが、Hibernateを使ったら重たくなったのかと思っていたが
ビューを作っただけで即座に解決した。パフォーマンスは10秒から1秒に
下がったという。
今そのセッションを見たときに書いたメモをここに書き写してみた。
189 ：仕様書無しさん：2005/12/16(金) 00:30:23
ODBCを使ったらコーディング量が減って開発効率があがり、パフォーマンスもおちません。
ExecuteSQLで生のSQLも使える。
10年前からだけど。
ExecuteSQLで生のSQLも使える。
10年前からだけど。
190 ：仕様書無しさん：2005/12/16(金) 00:31:33
重くないJava使ってるアプリかサイトってどっかにある？
あったら教えて、使ってみたいから
あったら教えて、使ってみたいから
O-Rマッピングを使ったからといって
なんでもかんでも重たくなるってわけじゃないんだな。
なんでもかんでも重たくなるってわけじゃないんだな。
>C/C++を苦労して覚えた人間からすると
>なぜ今更Javaなんて言語を覚えなくちゃいけないんだ
このへん、よくわからん。
C++→Javaはめちゃ楽だぞ。その逆は地獄だけども（ｗ
>なぜ今更Javaなんて言語を覚えなくちゃいけないんだ
このへん、よくわからん。
C++→Javaはめちゃ楽だぞ。その逆は地獄だけども（ｗ
PCのスペックが低いせいだとかいってるやつはおかしいんじゃね？
Javaって何年前の言語だ？前世紀だぞ？
Javaって何年前の言語だ？前世紀だぞ？
194 ：仕様書無しさん：2005/12/16(金) 00:43:42
流行すると厨があつまり業界誌とよってたかってグダグダになってしまうってのは同意
VBとDelphiを比較なら分かるが、
JavaとVBを比較って何か違和感が。
JavaとVBを比較って何か違和感が。
>>190
JavaWebStartで起動する2chブラウザがあったと思う。
しかも紹介したのは2chねらで作者本人。
彼のレスはどこにあったかなー
わすれちまった
あれ本当にJavaで作られたことが信じられなかった。
JavaWebStartで起動する2chブラウザがあったと思う。
しかも紹介したのは2chねらで作者本人。
彼のレスはどこにあったかなー
わすれちまった
あれ本当にJavaで作られたことが信じられなかった。
>>192
> >C/C++を苦労して覚えた人間からすると
> >なぜ今更Javaなんて言語を覚えなくちゃいけないんだ
>
> このへん、よくわからん。
> C++→Javaはめちゃ楽だぞ。その逆は地獄だけども（ｗ
プライドが高いC++厨がJavaをやり始めたら新たにAPIを覚えなおさない
といけないのがかったるいっていう言い訳は良く聞く。
だが彼らがJavaを嫌がる最もな理由は
C++では実行時エラーにもコンパイルエラーにも
ならかなったことがJavaではちょっとしたことで
エラーになってしまうことにイラつくというのがある。
多重継承ができないこと配列に負のindexやmaxを越えた
indexを使ってアクセスできないことに不満を感じる者多数。
慣れない言語にかなりイラつく人がいたってことはよく聞く。
テンプレート(今ではTypesafeなテンプレートとしてGenericsが使えるが)や
演算子オーバロード、プリプロセッサが使えないこともかなりイラつかせたようだ。
> >C/C++を苦労して覚えた人間からすると
> >なぜ今更Javaなんて言語を覚えなくちゃいけないんだ
>
> このへん、よくわからん。
> C++→Javaはめちゃ楽だぞ。その逆は地獄だけども（ｗ
プライドが高いC++厨がJavaをやり始めたら新たにAPIを覚えなおさない
といけないのがかったるいっていう言い訳は良く聞く。
だが彼らがJavaを嫌がる最もな理由は
C++では実行時エラーにもコンパイルエラーにも
ならかなったことがJavaではちょっとしたことで
エラーになってしまうことにイラつくというのがある。
多重継承ができないこと配列に負のindexやmaxを越えた
indexを使ってアクセスできないことに不満を感じる者多数。
慣れない言語にかなりイラつく人がいたってことはよく聞く。
テンプレート(今ではTypesafeなテンプレートとしてGenericsが使えるが)や
演算子オーバロード、プリプロセッサが使えないこともかなりイラつかせたようだ。
>>192
> >C/C++を苦労して覚えた人間からすると
> >なぜ今更Javaなんて言語を覚えなくちゃいけないんだ
>
> このへん、よくわからん。
> C++→Javaはめちゃ楽だぞ。その逆は地獄だけども（ｗ
C → Java
C → C++
と比べたら
C++ → Java
なんて大した地獄じゃないぞ。
C → Java → C++
なんてあまりにも効率的でお勧めしたいくらいすんなりいくからな。
つまり、みんなオブジェクト指向で躓くってこと。日本人が苦手とする分野かもね。
> >C/C++を苦労して覚えた人間からすると
> >なぜ今更Javaなんて言語を覚えなくちゃいけないんだ
>
> このへん、よくわからん。
> C++→Javaはめちゃ楽だぞ。その逆は地獄だけども（ｗ
C → Java
C → C++
と比べたら
C++ → Java
なんて大した地獄じゃないぞ。
C → Java → C++
なんてあまりにも効率的でお勧めしたいくらいすんなりいくからな。
つまり、みんなオブジェクト指向で躓くってこと。日本人が苦手とする分野かもね。
>>196
流行ってるだけだったらすぐに滅びるよ。
JavaがAppletで大ブレイクして「流行って」と言われてから
もう10年も経っているわけだが。
あれからもうJavaテクノロジも十分枯れてきたし
今更「流行ってる」なんて言うのは10年前の時代遅れな人間だよ。
流行ってるだけだったらすぐに滅びるよ。
JavaがAppletで大ブレイクして「流行って」と言われてから
もう10年も経っているわけだが。
あれからもうJavaテクノロジも十分枯れてきたし
今更「流行ってる」なんて言うのは10年前の時代遅れな人間だよ。
>>193
そのおかしな奴が持ってるマシンが10年前のものなんじゃね？w
いまから10年前というと丁度Windows95が発売された時期だから
10年というのは大袈裟すぎて見えるけどw
少なくとも5年前程度のマシンを使って遅いといっているのは
間違いなし。それかメモリが少なくてJVMのバージョンも低い
数年前のものを使っているだけだよ。
彼らは新しいコンピュータも新しいJavaも知らないんだよきっと
そのおかしな奴が持ってるマシンが10年前のものなんじゃね？w
いまから10年前というと丁度Windows95が発売された時期だから
10年というのは大袈裟すぎて見えるけどw
少なくとも5年前程度のマシンを使って遅いといっているのは
間違いなし。それかメモリが少なくてJVMのバージョンも低い
数年前のものを使っているだけだよ。
彼らは新しいコンピュータも新しいJavaも知らないんだよきっと
>>189
ADO.NETと間違えて無いかw
ADO.NETと間違えて無いかw
>>202
他の言語なら10年前のPCでも快適に動作するソフトが作れる。
でもJavaは無理。絶対無理。
ソフト開発者もあきらめちゃってるから最悪。
普通の開発者なら「重い」って言われたら改善しようとするけど
Java開発者は「Javaだから」でおしまい。最悪。
他の言語なら10年前のPCでも快適に動作するソフトが作れる。
でもJavaは無理。絶対無理。
ソフト開発者もあきらめちゃってるから最悪。
普通の開発者なら「重い」って言われたら改善しようとするけど
Java開発者は「Javaだから」でおしまい。最悪。
205 ：仕様書無しさん：2005/12/16(金) 01:27:56
206 ：仕様書無しさん：2005/12/16(金) 01:31:15
10年前に戻ってありがたがられとけｗ
ぶっちゃけ、ソフトウェア開発現場では、ここ５年間のハードウェアの進歩を
必要としてるのってJava関連くらいだよな。
まあ、Javaでも秀丸+JDK+Antなら2000年頃の1GHz/512MBで何とかなるけどさ。
必要としてるのってJava関連くらいだよな。
まあ、Javaでも秀丸+JDK+Antなら2000年頃の1GHz/512MBで何とかなるけどさ。
209 ：仕様書無しさん：2005/12/16(金) 08:32:28
C++ 製なら、最も重量級なソフトのひとつと思われる MS Office 2003 ですら、
Pentium 233MHz （Pentium III 推奨）に 128MB のメモリで動作することが
保証されてるのにねえ。
Pentium 233MHz （Pentium III 推奨）に 128MB のメモリで動作することが
保証されてるのにねえ。
210 ：仕様書無しさん：2005/12/16(金) 09:05:16
もしかしてJavaをJavaアプレットの事だと思っている人がいるのかと思った。
Javaアプレットの場合は、「Javaアプレット」または「アプレット」と記述して、
単にJavaとある場合は「普通のJava」や「Javaサーブレット」を示すでいいよな。
WEBが遅いとかVBの方がいいとか言ってるのは、アプレットと比べての事かな？
それなら話は分かるが。
Javaアプレットの場合は、「Javaアプレット」または「アプレット」と記述して、
単にJavaとある場合は「普通のJava」や「Javaサーブレット」を示すでいいよな。
WEBが遅いとかVBの方がいいとか言ってるのは、アプレットと比べての事かな？
それなら話は分かるが。
211 ：仕様書無しさん：2005/12/16(金) 09:21:15
そういえば、ORマッピングやEJBやWEBサービスマンセーとか言っている奴は何者だろう？
特に業務でHibernateやWSIなんか使っている奴は、俺以外にいるのかね。
どうも雑誌の特集を見ただけで、使いこなした気分になっちゃってる奴が多くて困る。
誰かORマッピングとEJBとWEBサービスの利点を教えてくれよ。
特に業務でHibernateやWSIなんか使っている奴は、俺以外にいるのかね。
どうも雑誌の特集を見ただけで、使いこなした気分になっちゃってる奴が多くて困る。
誰かORマッピングとEJBとWEBサービスの利点を教えてくれよ。
212 ：仕様書無しさん：2005/12/16(金) 09:35:06
JAVA厨ってパフォーマンスの事言われると
長文で必死に解説つけるw
長文で必死に解説つけるw
流行している（IT系雑誌がネタとして流行をつくる）
↓
似非業者がプレゼンなどでセールストークに使う
↓
人不足
↓
人集め
↓
厨が集まる
↓
求人が多いとの認識が世間に広まる
↓
さらに厨が集まる。
↓
独習本が売れてIT系出版業界ｳﾏｰ
↓
さらに厨が集まる。
↓
あっちこっちでデスマ。エンドレスプロジェクト
↓
似非業者がプレゼンなどでセールストークに使う
↓
人不足
↓
人集め
↓
厨が集まる
↓
求人が多いとの認識が世間に広まる
↓
さらに厨が集まる。
↓
独習本が売れてIT系出版業界ｳﾏｰ
↓
さらに厨が集まる。
↓
あっちこっちでデスマ。エンドレスプロジェクト
214 ：仕様書無しさん：2005/12/16(金) 12:01:22
それはVBですか?JAVAですか?
216 ：仕様書無しさん：2005/12/16(金) 12:16:05
>あっちこっちでデスマ。エンドレスプロジェクト
ｳﾋｬﾋｬﾋﾋｬｰ
どこの話聞いてもこのとおりだなーJAVAって
だまされたお客様がかわいそうだとマジで思う今日このごろ
ｳﾋｬﾋｬﾋﾋｬｰ
どこの話聞いてもこのとおりだなーJAVAって
だまされたお客様がかわいそうだとマジで思う今日このごろ
そんなにJAVA使いたいなら
JAVA前提のデスクトップOS開発して
その中でシコシコやってください
JAVA前提のデスクトップOS開発して
その中でシコシコやってください
派遣が残業してくれるのが、派遣会社は一番儲かると聞いたことあるな。
もちろん派遣社員に残業手当を払うのだけど、モチロンそれからもピンハネ
してるわけで、新規で放り込むのと違って営業する必要ないからね
もちろん派遣社員に残業手当を払うのだけど、モチロンそれからもピンハネ
してるわけで、新規で放り込むのと違って営業する必要ないからね
だからさ…
Javaがハードスペックを要求するという意味で重いのは
戦略の一端にきまってんじゃん。
考えても見ろよ。
一押ししてるのは、IBMとかのハード売ってる連中だろ？
言語として良いっていうのもあるが、
ハードで儲けている連中にとっては、
客にハードを買わせるいい餌になるわけだ。
当然それに気づいてて煽りあってるんだよな？
Javaがハードスペックを要求するという意味で重いのは
戦略の一端にきまってんじゃん。
考えても見ろよ。
一押ししてるのは、IBMとかのハード売ってる連中だろ？
言語として良いっていうのもあるが、
ハードで儲けている連中にとっては、
客にハードを買わせるいい餌になるわけだ。
当然それに気づいてて煽りあってるんだよな？
220 ：仕様書無しさん：2005/12/16(金) 12:30:12
Cと変わらないくらい速いって皆言ってるのにあほかおまえは。
>>219
遅いのは古いJVMを使ってるアホだ。消えろ。
遅いのは古いJVMを使ってるアホだ。消えろ。
222 ：仕様書無しさん：2005/12/16(金) 12:47:20
パフォーマンスの言い訳JAVA厨がなぜか必死ですw
ActiveBasic最強
お前が書けよ。糞プロパ。
書けるものなら
書けるものなら
VCのクラスウィザードで、CRecordsetクラスの派生クラスを作ると、
SQLを書かなくてもすむよ。そのテーブルやビューを参照・更新するための
クラスを全自動で作ってくれる。コーディングは不要。
後はインスタンス化してメソッドを呼ぶだけ。
10年前のVC4の時代からあったけどね。
SQLを書かなくてもすむよ。そのテーブルやビューを参照・更新するための
クラスを全自動で作ってくれる。コーディングは不要。
後はインスタンス化してメソッドを呼ぶだけ。
10年前のVC4の時代からあったけどね。
227 ：仕様書無しさん：2005/12/16(金) 16:30:01
消えろ
>>225
自分で書くほど暇だったら外注いらないやん？
自分で書くほど暇だったら外注いらないやん？
重いというだけでJavaを嫌っているなら間違いだね。
もっと他に叩くべきところがある。
もっと他に叩くべきところがある。
思わせぶりなことだけ言って逃げるな。
231 ：仕様書無しさん：2005/12/17(土) 08:24:51
enumがないまま10年以上文句いわなかったJAVA厨とかw
Javaはプロパティを実装できないって本当？
233 ：仕様書無しさん：2005/12/17(土) 10:38:38
Javaってnamespaceつかえるの?
使えね
235 ：仕様書無しさん：2005/12/17(土) 11:18:28
なんか上の方で極端なアホプログラムを出して作り方が悪いから
みたいなことを言ってるけど、Java がアホみたいに遅いのは事実だよ。
Ｃより早いみたいな妄想を語ってるけど、構造的にそんなわけねぇだろ？
VMがいつも間にいるのとネイティブを比較して普通に考えろ。
Java はアホみたいに遅い言語だけど、仕事が多いからやってます。
客もあきらめてるからいいけどね。
まぁ高いハードが売れるからIBMとかは儲かってウハウハでしょう。
ただそんだけのクソ言語でしかない。
みたいなことを言ってるけど、Java がアホみたいに遅いのは事実だよ。
Ｃより早いみたいな妄想を語ってるけど、構造的にそんなわけねぇだろ？
VMがいつも間にいるのとネイティブを比較して普通に考えろ。
Java はアホみたいに遅い言語だけど、仕事が多いからやってます。
客もあきらめてるからいいけどね。
まぁ高いハードが売れるからIBMとかは儲かってウハウハでしょう。
ただそんだけのクソ言語でしかない。
236 ：仕様書無しさん：2005/12/17(土) 11:21:24
くそ言語というよりクソ環境。
サーバサイドなんか決まった環境でしか動かないんだから
ネイティブコンパイルにすりゃあいいじゃないか？
そんな簡単なことやらずにいるのは、高いハード売りたいだけ。
サーバサイドなんか決まった環境でしか動かないんだから
ネイティブコンパイルにすりゃあいいじゃないか？
そんな簡単なことやらずにいるのは、高いハード売りたいだけ。
237 ：69式フリーPG ◆hND3Lufios ：2005/12/17(土) 11:28:05
VMってコン○ームみたいだな。
安全だけど遅い。
やっぱ生が一番だお。
安全だけど遅い。
やっぱ生が一番だお。
238 ：仕様書無しさん：2005/12/17(土) 11:31:29
239 ：仕様書無しさん：2005/12/17(土) 11:39:02
235 だが、俺がいつJavaを擁護した？
240 ：仕様書無しさん：2005/12/17(土) 11:42:31
どうしてJavaって実行時か配置時にネィティブにコンパイルしないの？
>>240
するよ、だからやたら起動が遅いんだよ
するよ、だからやたら起動が遅いんだよ
まったく、、、おまいらときたら土曜日の午前中から、、、
本当にソフト馬鹿なんだな。嬉しくなるよｗ
本当にソフト馬鹿なんだな。嬉しくなるよｗ
243 ：仕様書無しさん：2005/12/17(土) 11:48:17
まぁ、Javaが遅くてもいいや。
仕事だし、客も「しょうがないなぁ。Javaだし。」で納得してくれるから
いつでもごまかせます。これほど楽なもんはない。
仕事だし、客も「しょうがないなぁ。Javaだし。」で納得してくれるから
いつでもごまかせます。これほど楽なもんはない。
244 ：仕様書無しさん：2005/12/17(土) 11:50:50
それにタダだ。開発環境やらツールやらタダだし、
レスポンスを気にしなければなんでも作れる。
遊びと仕事の区別がつかなくなるくらいに面白いから、
残業や休日出勤なんてへっちゃらさ。
レスポンスを気にしなければなんでも作れる。
遊びと仕事の区別がつかなくなるくらいに面白いから、
残業や休日出勤なんてへっちゃらさ。
245 ：仕様書無しさん：2005/12/17(土) 11:53:25
いろんなコミュニティがあって次から次へといろんなオモチャ出してくれて
飽きない。うれしくって精子がでらぁ。
飽きない。うれしくって精子がでらぁ。
タダというのは重要だな。
ﾄﾞｶﾀにとっては。
ﾄﾞｶﾀにとっては。
今年開業したフリーランスですが、なかなか案件が無く、偽装請負社員時代より
生活が逼迫しています。ぶっちゃけ、年金払ってません。
Javaはいいですね。僕みたいに勉強時間が山ほどあるのにお金が無い身としては、
将来に向けて勉強するのにもってこいです。
生活が逼迫しています。ぶっちゃけ、年金払ってません。
Javaはいいですね。僕みたいに勉強時間が山ほどあるのにお金が無い身としては、
将来に向けて勉強するのにもってこいです。
248 ：仕様書無しさん：2005/12/17(土) 12:06:00
2chはCで書かれたCGIだろ。やっぱCが一番だな
249 ：仕様書無しさん：2005/12/17(土) 12:06:38
きっと20年後にはN-88BASICの様に愛される存在になると思う。
251 ：仕様書無しさん：2005/12/17(土) 12:11:59
もう充分愛してるさ。
かわいさ余って憎さ１００倍。
かわいさ余って憎さ１００倍。
ﾜﾛﾀ
253 ：仕様書無しさん：2005/12/17(土) 12:17:58
あぁ、俺はこれから会議さ。
遅いからなんとかしろってさ。また吊るし上げさ。
おれ晩飯も朝飯も食ってない。
コーヒーカップ見るだけで泣けてくる。
遅いからなんとかしろってさ。また吊るし上げさ。
おれ晩飯も朝飯も食ってない。
コーヒーカップ見るだけで泣けてくる。
254 ：69式フリーPG ◆hND3Lufios ：2005/12/17(土) 12:24:49
ｶﾞﾝｶﾞﾚ
まったく、オープンソースのcgicですら営利目的には金を要求している
この世知辛いご時世にサン・マイクロシステムズの優しさと思いやりは
五臓六腑にしみわたるねぇ。
この世知辛いご時世にサン・マイクロシステムズの優しさと思いやりは
五臓六腑にしみわたるねぇ。
256 ：仕様書無しさん：2005/12/17(土) 12:34:47
友好国である中国の人たちが一生懸命作ってくれたプログラムさ。
なんとかしなきゃ。
破壊活動じゃないよね？
あぁ。呼んでる。怒鳴ってるよ。
なんとかしなきゃ。
破壊活動じゃないよね？
あぁ。呼んでる。怒鳴ってるよ。
>>232
MSが導入を主張した時にSUNがVMの実装に与える影響について
何か反論してたのは確かだけど、何て言ってたかは覚えてない(て
言うか、英語だったんで見出ししか読んでないｗ)。
でも、私的にはプロパティは凄く欲しい機能。
演算子オーバーロードにしてもそうなんだけど、Javaでは演算子
が使えないばかりにコードが汚くなる。
１．age.setValue(sage.getValue() + hoge.getValue());
２．age.value = sage.value + hoge.value;
１と２だと後者の方が明らかに読みやすい。
MSが導入を主張した時にSUNがVMの実装に与える影響について
何か反論してたのは確かだけど、何て言ってたかは覚えてない(て
言うか、英語だったんで見出ししか読んでないｗ)。
でも、私的にはプロパティは凄く欲しい機能。
演算子オーバーロードにしてもそうなんだけど、Javaでは演算子
が使えないばかりにコードが汚くなる。
１．age.setValue(sage.getValue() + hoge.getValue());
２．age.value = sage.value + hoge.value;
１と２だと後者の方が明らかに読みやすい。
俺的にはスタック上に取れる構造体（クラス）も欲しいな。
座標とか日付時刻みたいなのは演算用とかで一時的に使うような場合が
結構あるけど、そんなのまでヒープにとってガベコレに面倒みてもらうなんて
馬鹿すぎる。
座標とか日付時刻みたいなのは演算用とかで一時的に使うような場合が
結構あるけど、そんなのまでヒープにとってガベコレに面倒みてもらうなんて
馬鹿すぎる。
座標計算を多量に要するGUI関連でJavaが遅いことの原因かも。
726 名前：デフォルトの名無しさん 投稿日：2005/12/14(水) 22:48:45
http://weblogs.java.net/blog/opinali/archive/2005/11/mustangs_hotspo_1.html
Mustang b59 から HotSpot client VM のレジスタ割り当ての最適化が改善されて、
Mustang b58 以前と比べて 1.5倍程度の速度で動くようになったらしい。
http://weblogs.java.net/blog/opinali/archive/2005/11/mustangs_hotspo_1.html
Mustang b59 から HotSpot client VM のレジスタ割り当ての最適化が改善されて、
Mustang b58 以前と比べて 1.5倍程度の速度で動くようになったらしい。
263 ：仕様書無しさん：2005/12/17(土) 13:03:35
全部プリミティブ型で実装すれば速くなるよ。
JAVA厨の程度がしれるな。
266 ：仕様書無しさん：2005/12/17(土) 13:44:25
皮だけJavaで適当に作って、あとJNIでC/C++で書けばいんじゃまいかｗｗ
むしろC言語厨の程度が知れる。
とにかく構造体や値型を使えば速くなると妄信してる程度だからな。
そんなものを長い配列でメソッド引数に直接渡したらどうなるか
想像できないんだろうか
とにかく構造体や値型を使えば速くなると妄信してる程度だからな。
そんなものを長い配列でメソッド引数に直接渡したらどうなるか
想像できないんだろうか
ﾜﾛﾀ
>>204
> >>202
> 他の言語なら10年前のPCでも快適に動作するソフトが作れる。
> でもJavaは無理。絶対無理。
残念ながら、C/C++でも無理なケースが多い。
とくに10年前に書いたソフトが今動かない
というのは腐るほどある。
それがJavaでは言語の特性上、比較的容易に動かせる。
10年前に使ったソフトは捨てないといけない。
だがJavaではその必要もC/C++で作られたアプリほどほとんどない。
ほとんどアップデートするだけで済む。
そもそも、どのPCメーカーもソフトウェアメーカーも
10年前のPCなんか捨てろというのが本音だ。
だからそんなことを今更持ち出しても説得力がない。
あのマイクロソフトですら古いPCを嫌がっているのだから。
次期Windows Longhornは10年前のPCでは動かないことはほぼ確実。
> >>202
> 他の言語なら10年前のPCでも快適に動作するソフトが作れる。
> でもJavaは無理。絶対無理。
残念ながら、C/C++でも無理なケースが多い。
とくに10年前に書いたソフトが今動かない
というのは腐るほどある。
それがJavaでは言語の特性上、比較的容易に動かせる。
10年前に使ったソフトは捨てないといけない。
だがJavaではその必要もC/C++で作られたアプリほどほとんどない。
ほとんどアップデートするだけで済む。
そもそも、どのPCメーカーもソフトウェアメーカーも
10年前のPCなんか捨てろというのが本音だ。
だからそんなことを今更持ち出しても説得力がない。
あのマイクロソフトですら古いPCを嫌がっているのだから。
次期Windows Longhornは10年前のPCでは動かないことはほぼ確実。
おまい、TeraTermがいつのソフトか知っているか？
>>211
> 誰かORマッピングとEJBとWEBサービスの利点を教えてくれよ。
おいおい、自分で使っていて利点がわからないのか？
O-RマッピングはDBテーブルの名前がカラムの設定などを
変更しても
ソースコードに直接与える影響を最小限に抑えられて
さらにマッピング部分のコードを自動生成してくれるので開発効率が高まる。
EJBもXDoclet使っておなじようなことをやっているわけだがPOJOでないという特徴がある。
Web Servicesは通信フォーマットを統合することでことなるプラットフォーム上で
動くサーバ間でWS-BPELのような言語を使って
の上位層でのデータ通信の互換性を保つために考えられている。
> 誰かORマッピングとEJBとWEBサービスの利点を教えてくれよ。
おいおい、自分で使っていて利点がわからないのか？
O-RマッピングはDBテーブルの名前がカラムの設定などを
変更しても
ソースコードに直接与える影響を最小限に抑えられて
さらにマッピング部分のコードを自動生成してくれるので開発効率が高まる。
EJBもXDoclet使っておなじようなことをやっているわけだがPOJOでないという特徴がある。
Web Servicesは通信フォーマットを統合することでことなるプラットフォーム上で
動くサーバ間でWS-BPELのような言語を使って
の上位層でのデータ通信の互換性を保つために考えられている。
274 ：仕様書無しさん：2005/12/17(土) 17:51:24
>>216
それは携帯電話開発くらいだな。
だが言語がJavaより速いとされるC/C++で開発可能な
BREWはもっと悲惨。BREW開発のデスマプロジェクトを
この目で見てしまったからま。KDDIの下請けの下請けの企業で
ある携帯アプリの開発をしていたのを見たときのすさまじさといい。
ソースコードは酷かったクラスも構造体もろくに使えず
グローバル変数だらけ。コードは肥大化して
番号.c という名前のファイルが同じディレクトリ大量に存在し
それぞれどんな関数が入っているのか一目でわからないという汚らしさ。
あれは酷いものだった。
C/C++できると豪語してる連中があんなコードを書いてしまうのだから
呆れたものだよw
それは携帯電話開発くらいだな。
だが言語がJavaより速いとされるC/C++で開発可能な
BREWはもっと悲惨。BREW開発のデスマプロジェクトを
この目で見てしまったからま。KDDIの下請けの下請けの企業で
ある携帯アプリの開発をしていたのを見たときのすさまじさといい。
ソースコードは酷かったクラスも構造体もろくに使えず
グローバル変数だらけ。コードは肥大化して
番号.c という名前のファイルが同じディレクトリ大量に存在し
それぞれどんな関数が入っているのか一目でわからないという汚らしさ。
あれは酷いものだった。
C/C++できると豪語してる連中があんなコードを書いてしまうのだから
呆れたものだよw
>>231
そもそもJavaのenumとCのenumとは仕組みが違うからな。
10年前にいきなりタイプセーフでないenumをJavaに導入していたら
汚れたソースコードが乱立してとんでもないことになっていただろう。
そもそもJavaのenumとCのenumとは仕組みが違うからな。
10年前にいきなりタイプセーフでないenumをJavaに導入していたら
汚れたソースコードが乱立してとんでもないことになっていただろう。
>>274
iアプリもそんな感じだよｗ
iアプリもそんな感じだよｗ
278 ：仕様書無しさん：2005/12/17(土) 18:05:47
>>276
経験を積んでいればBREWほどでもないみたいだがな。
BREWは容量制限が厳しすぎて使い物にならない上に
CPによる検証に時間とお金がかかる。
しかも作ったアプリはKDDIのサーバに置かないといけない。
これほどやりづらいものはほかにない。
経験を積んでいればBREWほどでもないみたいだがな。
BREWは容量制限が厳しすぎて使い物にならない上に
CPによる検証に時間とお金がかかる。
しかも作ったアプリはKDDIのサーバに置かないといけない。
これほどやりづらいものはほかにない。
279 ：仕様書無しさん：2005/12/17(土) 18:05:54
280 ：仕様書無しさん：2005/12/17(土) 18:06:00
282 ：仕様書無しさん：2005/12/17(土) 18:06:14
>>269
配列が値型だったら遅くなる
配列が値型だったら遅くなる
283 ：仕様書無しさん：2005/12/17(土) 18:06:20
>>235
Javaで仕事をしているならいいんじゃないか。
Javaがアホみたいに遅いというならC++がその問題を
解決する大小としてバグを生みやすい危険なコードをアホみたいに
量産してシステムを停止させて顧客から大きな損害を受けるということだな。
高いハードが売れるためにJavaが存在するって？
それはマイクロソフトの次期Windows Longhornにも言えることだろう。
客が諦めてる？ わかってないな。
客が何をトレードオフにしているかを。
Javaで仕事をしているならいいんじゃないか。
Javaがアホみたいに遅いというならC++がその問題を
解決する大小としてバグを生みやすい危険なコードをアホみたいに
量産してシステムを停止させて顧客から大きな損害を受けるということだな。
高いハードが売れるためにJavaが存在するって？
それはマイクロソフトの次期Windows Longhornにも言えることだろう。
客が諦めてる？ わかってないな。
客が何をトレードオフにしているかを。
284 ：仕様書無しさん：2005/12/17(土) 18:06:28
>>236
> くそ言語というよりクソ環境。
> サーバサイドなんか決まった環境でしか動かないんだから
セキュリティのことわかってないな。
そんなに気になるならC/C++でServletを超えるサーバサイド開発をしてみてくれ。
いまどきCGI + CなんてみっともないことをしてもJavaに見られる
高品質なソフトウェアを作ることはできないぞ。
> ネイティブコンパイルにすりゃあいいじゃないか？
起動時にすでにネイティブでコンパイルしているんだが。
Tomcatの仕組みをよく理解することだ。
一度起動すればしばらくはTomcatを再起動することはない。
その状態が何年も続くことだってあるわけだ。
> くそ言語というよりクソ環境。
> サーバサイドなんか決まった環境でしか動かないんだから
セキュリティのことわかってないな。
そんなに気になるならC/C++でServletを超えるサーバサイド開発をしてみてくれ。
いまどきCGI + CなんてみっともないことをしてもJavaに見られる
高品質なソフトウェアを作ることはできないぞ。
> ネイティブコンパイルにすりゃあいいじゃないか？
起動時にすでにネイティブでコンパイルしているんだが。
Tomcatの仕組みをよく理解することだ。
一度起動すればしばらくはTomcatを再起動することはない。
その状態が何年も続くことだってあるわけだ。
285 ：仕様書無しさん：2005/12/17(土) 18:06:35
>>244
> それにタダだ。開発環境やらツールやらタダだし、
そいつは説得力ないな。Java開発環境にだってWSADなど高価なものは沢山ある。
C/C++にもタダの開発環境やツールが存在する。
> 遊びと仕事の区別がつかなくなるくらいに面白いから、
> 残業や休日出勤なんてへっちゃらさ。
C/C++プロジェクトででそういう悲惨な光景をよく目にするわけだが。
> それにタダだ。開発環境やらツールやらタダだし、
そいつは説得力ないな。Java開発環境にだってWSADなど高価なものは沢山ある。
C/C++にもタダの開発環境やツールが存在する。
> 遊びと仕事の区別がつかなくなるくらいに面白いから、
> 残業や休日出勤なんてへっちゃらさ。
C/C++プロジェクトででそういう悲惨な光景をよく目にするわけだが。
286 ：仕様書無しさん：2005/12/17(土) 18:09:11
さあ！もりあがってきますた！
実際問題、サーバモードで起動したJavaは別に重くないわな。
サーバーといえばとっととVMの64ビット化してほしいね、メモリーが足りなくなってしばしばダウンするんだが・・・・
久々にメモリー食わないC++版が安定動作していて愉快なんですけどw
久々にメモリー食わないC++版が安定動作していて愉快なんですけどw
重いよ
290 ：仕様書無しさん：2005/12/17(土) 18:55:57
そもそも、JavaってSparcアーキテクチャの優位性をあっぴーるするための道具だった気がする。
それがいまじゃx86の独断場になってぐだぐだ通り越して意固地になってるんだろ？
それがいまじゃx86の独断場になってぐだぐだ通り越して意固地になってるんだろ？
sparcとろいよねぇ
292 ：仕様書無しさん：2005/12/17(土) 19:09:46
だーから昔つうとろうが
293 ：仕様書無しさん：2005/12/17(土) 22:36:03
294 ：仕様書無しさん：2005/12/17(土) 22:38:54
サーバーモードで起動する場合には、デフォルト起動とは違い、
ＶＭが確保するメモリ量が多いからではないですか？
ただ単に配分されるリソース量が多いから。
ＶＭが確保するメモリ量が多いからではないですか？
ただ単に配分されるリソース量が多いから。
295 ：仕様書無しさん：2005/12/17(土) 22:41:30
tomcaｔの起動時にネイティブにコンパイルするなら
なんでＶＭが必要なのさ？
なんでＶＭが必要なのさ？
296 ：仕様書無しさん：2005/12/17(土) 22:42:25
ネイティブとバイトコードを混同してませんか？
297 ：仕様書無しさん：2005/12/17(土) 22:51:22
ただ単にJavaで組めばセキュリティが高いなどという話は初耳です。
クロスサイトスクリプト対策やらなんやら自分達で工夫してやっと
セキュリティが高まるのでは？それは他の言語も同じでは？
またＦＷやＢｉｇＩＰやら使って色々対策やってますけどね。
クロスサイトスクリプト対策やらなんやら自分達で工夫してやっと
セキュリティが高まるのでは？それは他の言語も同じでは？
またＦＷやＢｉｇＩＰやら使って色々対策やってますけどね。
298 ：仕様書無しさん：2005/12/17(土) 22:55:53
もしかしてあなたのいうセキュリティが高いというのは
テスト不足でメモリ破壊してシステム壊すようなプログラムを
作れないからという事ですか？
でもJavaで作ったプログラムでもVM再起動しなきゃならないような
エラーが発生することありますよ。
テスト不足でメモリ破壊してシステム壊すようなプログラムを
作れないからという事ですか？
でもJavaで作ったプログラムでもVM再起動しなきゃならないような
エラーが発生することありますよ。
299 ：仕様書無しさん：2005/12/17(土) 23:05:37
私は最近は主にJavaで仕事してますが、
「いまどきCGI + Cなんてみっともないことをしても」の発言には
疑問を感じます。
何がどう「みっともない」のか教えていただきたい。
「いまどきCGI + Cなんてみっともないことをしても」の発言には
疑問を感じます。
何がどう「みっともない」のか教えていただきたい。
300 ：仕様書無しさん：2005/12/17(土) 23:05:50
301 ：仕様書無しさん：2005/12/17(土) 23:10:14
配列の表現方法はどの言語でもJavaでいう参照型( Cではポインタ）ではないでしょうか？
302 ：仕様書無しさん：2005/12/17(土) 23:33:35
開発効率を無視するなら、CGI + C は十分いけてると思うが・・・。
みっともないつーやつは、感覚で言ってんだろ。相手にしなくてよし。
みっともないつーやつは、感覚で言ってんだろ。相手にしなくてよし。
>>288
64bits版JavaならすでにSunのサイトからダウソできるよ
64bits版JavaならすでにSunのサイトからダウソできるよ
304 ：仕様書無しさん：2005/12/17(土) 23:44:14
>>284
>そんなに気になるならC/C++でServletを超えるサーバサイド
>開発をしてみてくれ。
超えられないとでも思ってるのか？確かに君には無理だろうが・・・。
Servlet ってそんなに偉いのか？OSならともかくこの程度のもの
C++で素で書けるぜ。Java屋はそもそも設計・コーディングが他力本願
なんでいけねぇ。
世の中には、君の想像を超える能力を持ってる奴がいるという事を
お忘れなく。みんながJavaだ／Servletだ言ってくそ遅いシステム
組んでいるうちにそれを超えるシステム組んで金儲けしてるところ
いくらでもある。
Java厨よ、誰を儲けさせるために仕事をしてるんだい？
>そんなに気になるならC/C++でServletを超えるサーバサイド
>開発をしてみてくれ。
超えられないとでも思ってるのか？確かに君には無理だろうが・・・。
Servlet ってそんなに偉いのか？OSならともかくこの程度のもの
C++で素で書けるぜ。Java屋はそもそも設計・コーディングが他力本願
なんでいけねぇ。
世の中には、君の想像を超える能力を持ってる奴がいるという事を
お忘れなく。みんながJavaだ／Servletだ言ってくそ遅いシステム
組んでいるうちにそれを超えるシステム組んで金儲けしてるところ
いくらでもある。
Java厨よ、誰を儲けさせるために仕事をしてるんだい？
307 ：仕様書無しさん：2005/12/17(土) 23:55:58
>>297
> ただ単にJavaで組めばセキュリティが高いなどという話は初耳です。
> クロスサイトスクリプト対策やらなんやら自分達で工夫してやっと
> セキュリティが高まるのでは？それは他の言語も同じでは？
わかってないな。他の言語ではその苦労に無駄に時間を金を
費やす羽目になってしまう。クロスサイト程度を阻止できた程度で
セキュリティが高まる？ 甘いんだよ。
CGI + Perl/Cで作られたものと比較してみるといい。
勝手に特定のメモリ番地にアクセスするのも変更するのも論外。
メモリリークの危険性は無視できない。
> またＦＷやＢｉｇＩＰやら使って色々対策やってますけどね。
当たり前だ。
> ただ単にJavaで組めばセキュリティが高いなどという話は初耳です。
> クロスサイトスクリプト対策やらなんやら自分達で工夫してやっと
> セキュリティが高まるのでは？それは他の言語も同じでは？
わかってないな。他の言語ではその苦労に無駄に時間を金を
費やす羽目になってしまう。クロスサイト程度を阻止できた程度で
セキュリティが高まる？ 甘いんだよ。
CGI + Perl/Cで作られたものと比較してみるといい。
勝手に特定のメモリ番地にアクセスするのも変更するのも論外。
メモリリークの危険性は無視できない。
> またＦＷやＢｉｇＩＰやら使って色々対策やってますけどね。
当たり前だ。
業務系は単純作業だからやることの増えるCで組むほうが工期が延びる。
そんなこともわからんのか。
そんなこともわからんのか。
車輪の再発明か。
ま、世の中には暇なやつがいるもんだ。
うらやましい限り。
ま、世の中には暇なやつがいるもんだ。
うらやましい限り。
313 ：仕様書無しさん：2005/12/18(日) 00:03:12
314 ：仕様書無しさん：2005/12/18(日) 00:04:12
>>310
スマソ。俺、業務系じゃないわ。。。
スマソ。俺、業務系じゃないわ。。。
315 ：仕様書無しさん：2005/12/18(日) 00:06:55
316 ：仕様書無しさん：2005/12/18(日) 00:09:27
>>299
2chブラウザ程度のシステムに使うなら気にしなくて済むことでも
ミッションクリティカルの世界ではみっともないどころか、
あまりにも顧客に対する信用を大幅に失いかねないリスクを背負う可能性があるってことだろ。
ちっちゃシステムを作るなら そりゃC + CGIでもいいだろさ。
だがオンライントレーディングシステムで下手に作ったらどうなるか？
ちょっとしたミスですら株価に影響がでてしまうので許されない。
そんな環境下ではC/C++の立場はあまりにも弱いってことをお忘れ無く。、
2chブラウザ程度のシステムに使うなら気にしなくて済むことでも
ミッションクリティカルの世界ではみっともないどころか、
あまりにも顧客に対する信用を大幅に失いかねないリスクを背負う可能性があるってことだろ。
ちっちゃシステムを作るなら そりゃC + CGIでもいいだろさ。
だがオンライントレーディングシステムで下手に作ったらどうなるか？
ちょっとしたミスですら株価に影響がでてしまうので許されない。
そんな環境下ではC/C++の立場はあまりにも弱いってことをお忘れ無く。、
>>290
意気地なってるほど必死だったら
なぜこんなにJavaの仕事だらけなんだ。
その現実をちゃんと直視してるか。
Javaは家電製品を制御するために
生まれたものだからな。
その動きを示すために組み込み分やで携帯電話でやっとJavaが
使えるようになった。JavaCardなどにも動きが出ている。Jini。
意気地なってるほど必死だったら
なぜこんなにJavaの仕事だらけなんだ。
その現実をちゃんと直視してるか。
Javaは家電製品を制御するために
生まれたものだからな。
その動きを示すために組み込み分やで携帯電話でやっとJavaが
使えるようになった。JavaCardなどにも動きが出ている。Jini。
>>307
君に。誰もが使ってくれるOSやVM, Servlet同等の機能を
持つものをServletを書くことよりも
素早く書けるのとでもいうのかね。
Tomcatを既存のソースコードも見ずにライブラリも引用せずに
一からすべて書く事ができるというのかね？
しかも全部一人で。何年もかけて作られたLinuxのようなOSを全部一人で、
しかも限られた時間で書けるというなら書いてみるといい。
それができなきゃどんなに意地をなってそんな発言を
したってC++に優位性があることを証明することはできない。
君を見ていると、他人の権威や実力を傘に着ているだけの
口先だけで何もできない人間だって事がよくわかる。
君に。誰もが使ってくれるOSやVM, Servlet同等の機能を
持つものをServletを書くことよりも
素早く書けるのとでもいうのかね。
Tomcatを既存のソースコードも見ずにライブラリも引用せずに
一からすべて書く事ができるというのかね？
しかも全部一人で。何年もかけて作られたLinuxのようなOSを全部一人で、
しかも限られた時間で書けるというなら書いてみるといい。
それができなきゃどんなに意地をなってそんな発言を
したってC++に優位性があることを証明することはできない。
君を見ていると、他人の権威や実力を傘に着ているだけの
口先だけで何もできない人間だって事がよくわかる。
319 ：仕様書無しさん：2005/12/18(日) 00:09:43
>>302
> 開発効率を無視するなら、CGI + C は十分いけてると思うが・・・。
それで納品された製品が安全に動く確率はどんなところだろうな。
2chの一部をCで書き直したみたいなことができた程度だとしても
それと同じ事が金融システム開発、機密情報、個人情報を
厳重に管理しないと逝けないシステムを開発するときでもうまくいくか
どうか。かなり無理があるだろうね。顧客からの信用を
大幅に失う恐れが非常に大きい、無謀だと言い切れる非常に大きなリスクだ。
> 開発効率を無視するなら、CGI + C は十分いけてると思うが・・・。
それで納品された製品が安全に動く確率はどんなところだろうな。
2chの一部をCで書き直したみたいなことができた程度だとしても
それと同じ事が金融システム開発、機密情報、個人情報を
厳重に管理しないと逝けないシステムを開発するときでもうまくいくか
どうか。かなり無理があるだろうね。顧客からの信用を
大幅に失う恐れが非常に大きい、無謀だと言い切れる非常に大きなリスクだ。
リリース後の手のかから無さはC/C++のほうが上でね？
Javaの場合は遅いからソースを開いたらとんでもない糞コードだったとか、
テストにかからない曖昧な仕様がぐだぐだだったとかそんなことばかり。
いや、たぶん言語の問題というよりPGのスキルの問題なんだろうけどさ。
C/C++で集まる人はかなり経験豊かなんで組むコードの品質も高いし、
仕様書の曖昧さとか矛盾点とかに早い段階で気づいたり対策したりを
当たり前のようにこなす。
JVMというのがそういうDQN PGのコードが暴れるのを抑えるための檻で、
人手不足のこの業界ではそういうDQNも動員できるような言語が求められて
いたとは思うけどさ。
Javaの場合は遅いからソースを開いたらとんでもない糞コードだったとか、
テストにかからない曖昧な仕様がぐだぐだだったとかそんなことばかり。
いや、たぶん言語の問題というよりPGのスキルの問題なんだろうけどさ。
C/C++で集まる人はかなり経験豊かなんで組むコードの品質も高いし、
仕様書の曖昧さとか矛盾点とかに早い段階で気づいたり対策したりを
当たり前のようにこなす。
JVMというのがそういうDQN PGのコードが暴れるのを抑えるための檻で、
人手不足のこの業界ではそういうDQNも動員できるような言語が求められて
いたとは思うけどさ。
Javaは家電製品を制御するために
生まれたものだからな。
生まれたものだからな。
323 ：仕様書無しさん：2005/12/18(日) 00:12:30
Javaの応用分野って限られてるってことか・・・・。
寂しいね。
寂しいね。
>>310
たまにマ板で業務系＝単純作業という偏見を持つ馬鹿を
見かけるがその正体はお前のことだったのか。
いずれにしても、まだまだわかってないな。
ミッションクリティカルでない、お金の勘定もしなくてもよい
たいしたことがない業務系なら単純作業で済んでしまうケースもあるが
ミッションクリティカルな業務で1円でも間違えたらアウト、信頼を
失う、会社を倒産させるかも知れないほど危機的な状況に陥れるかもしれない
業務系開発は単純作業というわけにはいかないことをお忘れ無く。
たまにマ板で業務系＝単純作業という偏見を持つ馬鹿を
見かけるがその正体はお前のことだったのか。
いずれにしても、まだまだわかってないな。
ミッションクリティカルでない、お金の勘定もしなくてもよい
たいしたことがない業務系なら単純作業で済んでしまうケースもあるが
ミッションクリティカルな業務で1円でも間違えたらアウト、信頼を
失う、会社を倒産させるかも知れないほど危機的な状況に陥れるかもしれない
業務系開発は単純作業というわけにはいかないことをお忘れ無く。
ちなみにオンライントレードのシステム屋さんは来年の正月は無いですよ。マジで。
個人売買が激増した今年、Javaのシステムはもう一杯一杯なんだ。
個人売買が激増した今年、Javaのシステムはもう一杯一杯なんだ。
326 ：仕様書無しさん：2005/12/18(日) 00:17:01
業務系開発は単純作業にしたいんだろ？Javaは？
複雑な開発スタイルがすばらしいとでも思ってるのか？
意味不明だろ。
複雑な開発スタイルがすばらしいとでも思ってるのか？
意味不明だろ。
JVM = コンドーム
JVM = 檻
JVM = 拘束具
DQNを抑えるためには不可欠
JVM = 檻
JVM = 拘束具
DQNを抑えるためには不可欠
328 ：69式フリーPG ◆hND3Lufios ：2005/12/18(日) 00:20:56
生が一番ですたい
>>320
> リリース後の手のかから無さはC/C++のほうが上でね？
残念ながらバグの多さ顧客からの苦情の殺到が来るところから
手のかかりやすさはC/C++のほうが上。オーバフローの指摘も
なく例外処理もろくに使えない、お粗末なヘッダファイルやプリプロセッサ
や演算子オーバロードtypedefでスパゲティ化が発生しやすい環境下の言語。
C/C++顧客からの仕様変更にも耐えにくい言語でもある。
とくにCの場合オブジェクト指向言語ではないので仕様変更に弱い。
バグ修正にも弱い。一度作ってしまったら二度と変えるわけにはいかない、
ということになっていつまでも古くさいバグが残った関数を使い続ける羽目になる。
> リリース後の手のかから無さはC/C++のほうが上でね？
残念ながらバグの多さ顧客からの苦情の殺到が来るところから
手のかかりやすさはC/C++のほうが上。オーバフローの指摘も
なく例外処理もろくに使えない、お粗末なヘッダファイルやプリプロセッサ
や演算子オーバロードtypedefでスパゲティ化が発生しやすい環境下の言語。
C/C++顧客からの仕様変更にも耐えにくい言語でもある。
とくにCの場合オブジェクト指向言語ではないので仕様変更に弱い。
バグ修正にも弱い。一度作ってしまったら二度と変えるわけにはいかない、
ということになっていつまでも古くさいバグが残った関数を使い続ける羽目になる。
> Javaの場合は遅いからソースを開いたらとんでもない糞コードだったとか、
それは言語のせいではなく開発者のスキルの問題。
そこでJavaからC/C++にリプレースしたところでも
開発者の腕が悪ければ全く同じ問題に出くわす。
> C/C++で集まる人はかなり経験豊かなんで組むコードの品質も高いし、
> 仕様書の曖昧さとか矛盾点とかに早い段階で気づいたり対策したりを
> 当たり前のようにこなす。
その根拠があるなら示して貰いたいよ。
BREW開発している連中のコードはどいつもこいつもスパゲティコードで
品質は最悪だったぞ。C++を使ってるコードは一つもなくCのファイル名は
すべて番号だけのものでどこにどういう関数があるのか一目でわかるようには
なっていなかった。しかもグローバル変数の数は何千にも上る。
あれは最悪だ。みなデスマーチに陥り、5000万の赤字を出した。
> JVMというのがそういうDQN PGのコードが暴れるのを抑えるための檻で、
そんな発言も負け惜しみにしかみえないな。
そんなにC++が凄いなら5000万の赤字なんて出さないはずだが。
C++プログラマの大半が優秀？それも幻想。仕事ができないただのオタク、
Geekに成り下がっているだけじゃないのか。
>>323
そんなFUD攻撃を必死にしてもな
そんなFUD攻撃を必死にしてもな
>>328
DQN消えろ
DQN消えろ
334 ：仕様書無しさん：2005/12/18(日) 00:25:53
Java屋の業務系の開発者の視野の狭さにはビビル（俺の友人の事ね）。
だから、業務系システムのトラブルは後を絶たない。
忙殺されて一杯一杯なのはわかるが・・・。
ここの業務系の２ちゃんねらーも２ちゃんねる来てる暇あったら、
信頼性の高いシステム作ってみんなの暮らしを楽にしてくれ。
それか、休みくらいリフレッシュしな。子供と遊ぶとか。
余計なお世話だが。。。。
だから、業務系システムのトラブルは後を絶たない。
忙殺されて一杯一杯なのはわかるが・・・。
ここの業務系の２ちゃんねらーも２ちゃんねる来てる暇あったら、
信頼性の高いシステム作ってみんなの暮らしを楽にしてくれ。
それか、休みくらいリフレッシュしな。子供と遊ぶとか。
余計なお世話だが。。。。
>>258
よく分からないけどMustangのエスケープ分析で望みどおりの動作をするようになるんじゃない？
Javaの理論と実践: パフォーマンスに関する都市伝説を再検証する
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml
よく分からないけどMustangのエスケープ分析で望みどおりの動作をするようになるんじゃない？
Javaの理論と実践: パフォーマンスに関する都市伝説を再検証する
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml
小泉改革の欺瞞は、プログラミング言語で考えると簡単。
郵政民営化を、オブジェクト指向に置き換えれば、すぐわかる。
小泉改革は、CからC++への進化。
Cとの互換性を重視したため、その意味ではある種芸術的な設計だが、おか
げで非常に複雑。そもそもガベージコレクションがない時点で小泉同様骨抜き
改革なんだから、オブジェクト指向言語としては中途半端。結局大した生産性
向上はない。
民主党はCからJavaへ。スクリプト言語でいえば、Rubyに行くこと。ここで
Perlに行くのは、だいぶ小泉改革。＼(^O^)／
だって何年経ってもPerl 6が出ないもんね。改革は進まない。
ちんたらしてるから、Pugsのように、関数型言語HaskellでPerl6互換のもの
を勝手に作っちゃう頭のいい連中にあっさりやられてる。＼(^O^)／
郵政民営化を、オブジェクト指向に置き換えれば、すぐわかる。
小泉改革は、CからC++への進化。
Cとの互換性を重視したため、その意味ではある種芸術的な設計だが、おか
げで非常に複雑。そもそもガベージコレクションがない時点で小泉同様骨抜き
改革なんだから、オブジェクト指向言語としては中途半端。結局大した生産性
向上はない。
民主党はCからJavaへ。スクリプト言語でいえば、Rubyに行くこと。ここで
Perlに行くのは、だいぶ小泉改革。＼(^O^)／
だって何年経ってもPerl 6が出ないもんね。改革は進まない。
ちんたらしてるから、Pugsのように、関数型言語HaskellでPerl6互換のもの
を勝手に作っちゃう頭のいい連中にあっさりやられてる。＼(^O^)／
337 ：仕様書無しさん：2005/12/18(日) 00:31:53
JVMが檻だとかコンドームだとかいってる69式フリーPGとかいう奴は
トンカチすらも使わず素手だけで
釘を打つことができると叫んでいる40代中国人の某警官みたいだな。
あまりにも馬鹿すぎるんだよ。
そんなことを自慢して何になる。トンカチを使わずに素手(C言語)だけで
一度に何百本もの釘を連続して長時間かけて打つことができるというならわかる。
だが実際にはそうではない。素手(C言語)だけで巨大かつ信頼性あるのを作るには
トンカチで釘を打つよりも時間がかかる。素手(C言語)で釘を打つには
非常に大きな体力を消耗する。しかも顔を真っ赤に染めて馬鹿みたいに大きな
かけ声を上げながら素手で釘を叩いて板に打ち付ける。
それを見た後輩の警官は始めは凄いと感嘆するが
２回目以降は白ける。中にはそれを見て笑う者もいる。
後輩に笑われたから悔しいのでもう一度釘を打とうとする。
だがそれでも笑われる。認めて貰うまで必死にこのスレのC言語厨のように
馬鹿みたいに叫びながら釘を打つ。そんな馬鹿な中国人にそっくりなんだよC言語厨は。
トンカチすらも使わず素手だけで
釘を打つことができると叫んでいる40代中国人の某警官みたいだな。
あまりにも馬鹿すぎるんだよ。
そんなことを自慢して何になる。トンカチを使わずに素手(C言語)だけで
一度に何百本もの釘を連続して長時間かけて打つことができるというならわかる。
だが実際にはそうではない。素手(C言語)だけで巨大かつ信頼性あるのを作るには
トンカチで釘を打つよりも時間がかかる。素手(C言語)で釘を打つには
非常に大きな体力を消耗する。しかも顔を真っ赤に染めて馬鹿みたいに大きな
かけ声を上げながら素手で釘を叩いて板に打ち付ける。
それを見た後輩の警官は始めは凄いと感嘆するが
２回目以降は白ける。中にはそれを見て笑う者もいる。
後輩に笑われたから悔しいのでもう一度釘を打とうとする。
だがそれでも笑われる。認めて貰うまで必死にこのスレのC言語厨のように
馬鹿みたいに叫びながら釘を打つ。そんな馬鹿な中国人にそっくりなんだよC言語厨は。
338 ：仕様書無しさん：2005/12/18(日) 00:34:33
Java、C/C++を使っている僕はどちらの味方をすればいいでしょうか？
>>336
またバカが湧いてきた。
またバカが湧いてきた。
>>334
作り話に必死だな。
仮にもしそれが実話だとしても、そいつのスキルは
たかが知れている。本当にJavaに熟練してる奴なら
テストを怠らずにやり、自動化ツールを積極的に使う。
忙殺されてるってことは設計があまりにも甘すぎたことと
テストをしっかりやってなかったこととAntやXDocletなどを
使って自動化ビルドスクリプトをちゃんと書かなかったことに起因する。
今までそういう状況に陥った奴の経歴を見てみると
C/C++開発経験はあるがJava開発経験は浅い。そして40代。
そんな奴ばかり。Cで携帯電話開発を必死にやってきた奴が
サーバアプリ開発をするとこうなる。めもりはたっぷり余裕があるのに
ソースコードは汚くなる。
作り話に必死だな。
仮にもしそれが実話だとしても、そいつのスキルは
たかが知れている。本当にJavaに熟練してる奴なら
テストを怠らずにやり、自動化ツールを積極的に使う。
忙殺されてるってことは設計があまりにも甘すぎたことと
テストをしっかりやってなかったこととAntやXDocletなどを
使って自動化ビルドスクリプトをちゃんと書かなかったことに起因する。
今までそういう状況に陥った奴の経歴を見てみると
C/C++開発経験はあるがJava開発経験は浅い。そして40代。
そんな奴ばかり。Cで携帯電話開発を必死にやってきた奴が
サーバアプリ開発をするとこうなる。めもりはたっぷり余裕があるのに
ソースコードは汚くなる。
テストは仕様に則しているかどうか確認することは出来るが、
仕様が妥当かどうかの確認は出来ない。
仕様が妥当かどうかの確認は出来ない。
343 ：仕様書無しさん：2005/12/18(日) 00:40:01
業務系の人達へ。
上司に同じ事言われたかも試練が繰り返しとく。
熱くなるなって。開発者の資質が問われるぞ。
間違いが許されないシステムを書くなら常に冷静でいろよ。
（ここでストレス発散しているなら付き合ってやるが・・・。）
上司に同じ事言われたかも試練が繰り返しとく。
熱くなるなって。開発者の資質が問われるぞ。
間違いが許されないシステムを書くなら常に冷静でいろよ。
（ここでストレス発散しているなら付き合ってやるが・・・。）
344 ：仕様書無しさん：2005/12/18(日) 00:42:04
>>340
お前の事言ってないよ。自意識過剰君。
お前の事言ってないよ。自意識過剰君。
テストは仕様に則しているかどうか確認することは出来るが、
仕様が妥当かどうかの確認は出来ない。
経験豊かな技術者にはそれができる。
ツールや言語で解決できる問題ではない。
厨はいやだねぇ。
仕様が妥当かどうかの確認は出来ない。
経験豊かな技術者にはそれができる。
ツールや言語で解決できる問題ではない。
厨はいやだねぇ。
346 ：仕様書無しさん：2005/12/18(日) 00:49:18
>>340
悪い。俺の友人は、ＰＧ卒業してる。ちなみに、30代前半。
出来の悪いＰＧを使って苦しんでる立場。
良い人材がいなくて困ってる。
友人に、部下が無能なんじゃなくて、理想論ばっかで部下が
付いてきてないって指摘してるんだが・・・。聞き入れてない。
常に自分の意見は正しいから皆従うべきだって思ってるのよね。
で、仕事のし過ぎでそいつもこないだ倒れた。少しは現実見れる
ようになったようだった。
悪い。俺の友人は、ＰＧ卒業してる。ちなみに、30代前半。
出来の悪いＰＧを使って苦しんでる立場。
良い人材がいなくて困ってる。
友人に、部下が無能なんじゃなくて、理想論ばっかで部下が
付いてきてないって指摘してるんだが・・・。聞き入れてない。
常に自分の意見は正しいから皆従うべきだって思ってるのよね。
で、仕事のし過ぎでそいつもこないだ倒れた。少しは現実見れる
ようになったようだった。
仕事出来なさそうな友人だな。。。
348 ：仕様書無しさん：2005/12/18(日) 00:59:26
>>345
激しく同意。
膨大な数のテストをこなすには便利だが、テストの品質は、経験がものを
言う。小規模開発ではツールも便利だが、大規模な開発になると、全てが
分業、テストも分業。テストをツールで効率化できるにも限界がある。
テストをなめてはいけないぜ。
激しく同意。
膨大な数のテストをこなすには便利だが、テストの品質は、経験がものを
言う。小規模開発ではツールも便利だが、大規模な開発になると、全てが
分業、テストも分業。テストをツールで効率化できるにも限界がある。
テストをなめてはいけないぜ。
未熟者の俺はテストケース考えるのも、テストデータ作るのも苦労するが。
予めある程度のテストケースを考えた上での設計とコーディングをすべき
なのだろうけど、最初にイメージしていたもの通りに開発が進んだ試しがない。
予めある程度のテストケースを考えた上での設計とコーディングをすべき
なのだろうけど、最初にイメージしていたもの通りに開発が進んだ試しがない。
351 ：仕様書無しさん：2005/12/18(日) 01:06:57
>>347
だから、俺は、
業務系＝仕事ができない
と思ってる節がある。
某有名企業で給料は破格なんだが、仲間内ではあまり認められてない。
仕事し始めてからそいつは変わったよ。
業務系 -> 多忙 -> 人格崩壊
だから、俺は、
業務系＝仕事ができない
と思ってる節がある。
某有名企業で給料は破格なんだが、仲間内ではあまり認められてない。
仕事し始めてからそいつは変わったよ。
業務系 -> 多忙 -> 人格崩壊
そう、テストで出来ることはコードが仕様に従っているかどうかを確認するだけなんだよな。
仕様が要求仕様を満たしているかどうかを確認することは出来ないし、
まして要求仕様が顧客の要求を満たしているかの確認など出来るわけが無い。
それ以前にそのテスト自体が妥当であるかもテストでは確認出来ない。
そしてデスマや運用開始後のトラブル（今回のみずほの件もそうだが）の
原因はコーディング以前の要求定義や設計段階にある。
つまりテストでは解決出来ない。
テストテストと連呼していれば品質が上がると思っているのは
無能の証である。君の会社にもそんなGM/PMやPLがいないか？
はっきりいって責任転嫁である。
仕様が要求仕様を満たしているかどうかを確認することは出来ないし、
まして要求仕様が顧客の要求を満たしているかの確認など出来るわけが無い。
それ以前にそのテスト自体が妥当であるかもテストでは確認出来ない。
そしてデスマや運用開始後のトラブル（今回のみずほの件もそうだが）の
原因はコーディング以前の要求定義や設計段階にある。
つまりテストでは解決出来ない。
テストテストと連呼していれば品質が上がると思っているのは
無能の証である。君の会社にもそんなGM/PMやPLがいないか？
はっきりいって責任転嫁である。
353 ：仕様書無しさん：2005/12/18(日) 01:16:52
うちは、テストのスペシャリスト集団がいるよ。
単体テストは、
「ユースケース＝テストケース」「テストできない設計はするな」
で乗り切れるんだが。所詮身内のテスト。
第三者検証は別次元の話さ。
自分で考えたテストは通るの当たり前なんで価値ないんよ。
テストのスペシャリスト集団は、仕様書・設計書からチェックして、
抜けを探して、意地悪極まりないテストをしまくるんよね。。。。。
JAVA および JAVA の開発環境が解決できる問題は全体の数十パーセント
に過ぎないって事を肝に銘じておくといいよ。
開発スタイルは時代と共に変わるんでJAVAで立ち止まるわけにはいかんのよ。
単体テストは、
「ユースケース＝テストケース」「テストできない設計はするな」
で乗り切れるんだが。所詮身内のテスト。
第三者検証は別次元の話さ。
自分で考えたテストは通るの当たり前なんで価値ないんよ。
テストのスペシャリスト集団は、仕様書・設計書からチェックして、
抜けを探して、意地悪極まりないテストをしまくるんよね。。。。。
JAVA および JAVA の開発環境が解決できる問題は全体の数十パーセント
に過ぎないって事を肝に銘じておくといいよ。
開発スタイルは時代と共に変わるんでJAVAで立ち止まるわけにはいかんのよ。
プログラマー ： 大体SEなんかプログラムの中身を全く分かってないくせに
何でも客の要望を出来る出来る言ってきて、中身分かってないから
どれぐらいのボリュームになるのかも分からない。
そんな状態で勝手に客と納期も決めてくる。
明らかに割に合ってない見積もりも平気で出す。
SE連中のせいで、プログラマーが苦労するんだよ。。。
SE ： プログラマーなんかそれしか出来ないんだから、さっさと言われた通りにしろよ。
お前らたったそれだけ作るのにどんだけ時間かかってんだよ。
しかもデモ中とかに平気でバグるような状態で出来たとか言ってんじゃねえよ。
お前らのせいで、俺たちがどんだけ客に頭下げないといけないと思ってんだよ。
プログラマーとSEにどっちが上か下かなんて無いと俺は思うんだが
何かと衝突があるようだ。。。
何でも客の要望を出来る出来る言ってきて、中身分かってないから
どれぐらいのボリュームになるのかも分からない。
そんな状態で勝手に客と納期も決めてくる。
明らかに割に合ってない見積もりも平気で出す。
SE連中のせいで、プログラマーが苦労するんだよ。。。
SE ： プログラマーなんかそれしか出来ないんだから、さっさと言われた通りにしろよ。
お前らたったそれだけ作るのにどんだけ時間かかってんだよ。
しかもデモ中とかに平気でバグるような状態で出来たとか言ってんじゃねえよ。
お前らのせいで、俺たちがどんだけ客に頭下げないといけないと思ってんだよ。
プログラマーとSEにどっちが上か下かなんて無いと俺は思うんだが
何かと衝突があるようだ。。。
355 ：仕様書無しさん：2005/12/18(日) 01:23:01
>>352
>原因はコーディング以前の要求定義や設計段階にある。
>つまりテストでは解決出来ない。
だから？君ならどうやって解決するんだ？
要求定義や設計が正しい事をどうやって証明するんだ？
非現実的な話は価値がないぜ。
（言いたい事は激しく良く分かるが・・・。）
耐震性偽装問題とかでチェック機関に責任が無いといってる
よーなもんだぜ。全員有罪さ。
俺たちは、テストチームに何度も助けられてるよ。
開発の前工程で全てができるとでも思ってるのか？
小手先のテクばかりじゃなくてチーム開発を理解した方がいいぞ。
>原因はコーディング以前の要求定義や設計段階にある。
>つまりテストでは解決出来ない。
だから？君ならどうやって解決するんだ？
要求定義や設計が正しい事をどうやって証明するんだ？
非現実的な話は価値がないぜ。
（言いたい事は激しく良く分かるが・・・。）
耐震性偽装問題とかでチェック機関に責任が無いといってる
よーなもんだぜ。全員有罪さ。
俺たちは、テストチームに何度も助けられてるよ。
開発の前工程で全てができるとでも思ってるのか？
小手先のテクばかりじゃなくてチーム開発を理解した方がいいぞ。
356 ：仕様書無しさん：2005/12/18(日) 01:23:39
ﾚﾋﾞｭｰってなんのためにあるの
Javaの話しろよ。C厨の爺ども。
ここはテストの話題でつかo(･_･= ･_･)o ｷｮﾛｷｮﾛ
>>356
ﾚﾋﾞｭｰが機能していればいいんだけどね。
ﾚﾋﾞｭｰが機能していればいいんだけどね。
360 ：仕様書無しさん：2005/12/18(日) 01:29:43
>>357
そういう時は、自分でネタをふる。
そういう時は、自分でネタをふる。
いや、なかなか面白い話題だった。
362 ：仕様書無しさん：2005/12/18(日) 01:34:35
Javaってマルチスレッド処理得意なの？
漠然としたネタでスマソ。
漠然としたネタでスマソ。
363 ：仕様書無しさん：2005/12/18(日) 01:37:02
Javaは言語仕様としてマルチスレッドが組み込まれている。
得意というより、それが前提といったほうが適切だろう。
とってつけたようなC/C++のマルチスレッドとは次元が違う。
得意というより、それが前提といったほうが適切だろう。
とってつけたようなC/C++のマルチスレッドとは次元が違う。
swingはシングルスレッドだぞ。
365 ：仕様書無しさん：2005/12/18(日) 01:39:57
言語としての美しさはJAVAに軍配が上がるのは納得なんだけど。
パフォーマンスとか細かな制御はどうなのかな？って思って。
Win32 でいうと、クリティカルセクションとミューテックスとか
選べるけどJavaは選べないし。
パフォーマンスとか細かな制御はどうなのかな？って思って。
Win32 でいうと、クリティカルセクションとミューテックスとか
選べるけどJavaは選べないし。
ミューテクスはJavaいけますぞ。
Winだとミューテクス、Linuxだと変なレジストリらしい。
Winだとミューテクス、Linuxだと変なレジストリらしい。
367 ：仕様書無しさん：2005/12/18(日) 01:49:00
Java + Windows だと、(Win用語で言う)ミューテックスで実装されている
という意味ですか？
という意味ですか？
yes
369 ：仕様書無しさん：2005/12/18(日) 08:21:33
>>317 家電製品のために生まれただ？はあ？
家電製品というものをまるでわかってないＳｕｎが１９９０年代に抽象概念先行で作り出したのがＪａｖａだろ。
当時乗せられて実装試みた連中がどれだけ痛い目見たかわかっていってるのかおまいは？
社内的にとかな。PersonalJavaがどうなったか言うのもいやだ。
概念はまるっきりＴＲＯＮ構想のパクリ。無理矢理ＰＣ＆ＷＳ系の劇重システムに乗せて動かしてみたってだけだった。
こんなもの何に使うんだろうな全く。つうとこで、結局ＤＢのフロントエンドに使うようになってきた。VB代わりにな。
その流れで、携帯電話でＪａｖａ乗せ始めただけ。携帯電話自体の制御にＪＡＶＡＶＭなんもかんでないだろ！
プロトコルスタックがＪＡＶＡ実装されてるか？単にアプリの一つとして載ってるだけだ。程度の低いPGに
がちゃがちゃやられてもシステムおかしくならないように、厳重な砂場作ってな。DBサーバーのフロントエンドとして。
Java=組み込みみたいにいまさらいうのはやめれ。あほかと。
VM自体はシングルスレッドで動くことも多いだろそれに。擬似的にマルチスレッドやってるだけの。
ネイティブOS的にはシングルプロセス、シングルスレッドの１アプリにすぎない実装も多かろう。
家電製品というものをまるでわかってないＳｕｎが１９９０年代に抽象概念先行で作り出したのがＪａｖａだろ。
当時乗せられて実装試みた連中がどれだけ痛い目見たかわかっていってるのかおまいは？
社内的にとかな。PersonalJavaがどうなったか言うのもいやだ。
概念はまるっきりＴＲＯＮ構想のパクリ。無理矢理ＰＣ＆ＷＳ系の劇重システムに乗せて動かしてみたってだけだった。
こんなもの何に使うんだろうな全く。つうとこで、結局ＤＢのフロントエンドに使うようになってきた。VB代わりにな。
その流れで、携帯電話でＪａｖａ乗せ始めただけ。携帯電話自体の制御にＪＡＶＡＶＭなんもかんでないだろ！
プロトコルスタックがＪＡＶＡ実装されてるか？単にアプリの一つとして載ってるだけだ。程度の低いPGに
がちゃがちゃやられてもシステムおかしくならないように、厳重な砂場作ってな。DBサーバーのフロントエンドとして。
Java=組み込みみたいにいまさらいうのはやめれ。あほかと。
VM自体はシングルスレッドで動くことも多いだろそれに。擬似的にマルチスレッドやってるだけの。
ネイティブOS的にはシングルプロセス、シングルスレッドの１アプリにすぎない実装も多かろう。
Javaなんて最近までは全然使われてなかっただろ。
なぜって、クソ重いからだ。JRE入れなきゃ動かないし。
最近はハードの性能も向上してきたからそれなりに動くようになり、
一応それなりに使える言語にはなったってだけ。
オープンな言語だからこそ開発環境が充実してるとも言うけど、
逆に乱立による混乱も見受けらたしなぁ、
最近はeclipseがメインになってきたけど、プラグインは相変わらず乱立。
そんなことよりJavaなのにOO設計できねーような奴が乱立してるのが問題かな。
なぜって、クソ重いからだ。JRE入れなきゃ動かないし。
最近はハードの性能も向上してきたからそれなりに動くようになり、
一応それなりに使える言語にはなったってだけ。
オープンな言語だからこそ開発環境が充実してるとも言うけど、
逆に乱立による混乱も見受けらたしなぁ、
最近はeclipseがメインになってきたけど、プラグインは相変わらず乱立。
そんなことよりJavaなのにOO設計できねーような奴が乱立してるのが問題かな。
371 ：仕様書無しさん：2005/12/18(日) 09:49:58
JavaなのにOOできないんじゃない。
JavaみたいにDQN保護対策がしてあるものじゃないと仕事させられない厨が多いだけだろ
JavaみたいにDQN保護対策がしてあるものじゃないと仕事させられない厨が多いだけだろ
でも結局Java使うんでしょ?
お前ら。
お前ら。
コン猿に言え
374 ：仕様書無しさん：2005/12/18(日) 13:26:34
Java も C/C++も仕事柄使うけど、Java は楽だって正直思う。
ど素人でも（コンピュータの仕組みを知らなくても）動くコード書ける。
だから、プログラマー不足の解消に役に立ってると思う。
C++に比べれば勉強しやすいし、金もかからない。
（それに、C++を知っていれば、１日でJavaなんてマスターできるしね。）
だから、平均的なレベルの(Java)プログラマは重いアプリをつくりがち。
で、Java が重いのは、糞プログラマーが悪いという奴がいるが、
糞プログラマーを世に送り出しているのもJavaなんで、
「Java って重くね？」と問われるとYes と答える事にしている。
ど素人でも（コンピュータの仕組みを知らなくても）動くコード書ける。
だから、プログラマー不足の解消に役に立ってると思う。
C++に比べれば勉強しやすいし、金もかからない。
（それに、C++を知っていれば、１日でJavaなんてマスターできるしね。）
だから、平均的なレベルの(Java)プログラマは重いアプリをつくりがち。
で、Java が重いのは、糞プログラマーが悪いという奴がいるが、
糞プログラマーを世に送り出しているのもJavaなんで、
「Java って重くね？」と問われるとYes と答える事にしている。
>>365
java.util.concurrent
java.util.concurrent
377 ：仕様書無しさん：2005/12/18(日) 14:15:27
個人的には、せめて CASL が書ける程度のハードウェア知識は、プログラマを
はじめとした IT 技術者は常識として持っていてほしいなあ。
建築士みたいに試験にパスした人間だけが仕事できるのがまあ理想ではあるな。
ただそれでも姉歯みたいなのは出てくるが、姉歯だって専門知識を
持った上で偽装してたわけで、何も知らないまま重いアプリを作る
無知プログラマとは程度が違うわな。
はじめとした IT 技術者は常識として持っていてほしいなあ。
建築士みたいに試験にパスした人間だけが仕事できるのがまあ理想ではあるな。
ただそれでも姉歯みたいなのは出てくるが、姉歯だって専門知識を
持った上で偽装してたわけで、何も知らないまま重いアプリを作る
無知プログラマとは程度が違うわな。
378 ：仕様書無しさん：2005/12/18(日) 14:18:33
今どきJavaが遅いっていう香具師は
かなり古い香具師
(エセ)団塊ジュニア世代(30代)や新人類世代に多い。
古い時代のデータを元にJavaは遅いと連呼しているだけで
今まで以上に高速なJava SE 5 が普及した今じゃあてにならない。
J2SE1.3とJava SE 5とでは速度が格段に違うってことに気づけ30代のオッサンども
かなり古い香具師
(エセ)団塊ジュニア世代(30代)や新人類世代に多い。
古い時代のデータを元にJavaは遅いと連呼しているだけで
今まで以上に高速なJava SE 5 が普及した今じゃあてにならない。
J2SE1.3とJava SE 5とでは速度が格段に違うってことに気づけ30代のオッサンども
CをマスターしてればC++は1週間でマスターできる
C/C++をマスターしてればJavaは3日でマスターできる
しかしこのマスターの度合いは最初のCの何をマスターしているかに依存する
Cの標準APIを1/3しか知らなければ、Javaでも1/3しか使えないことになる
C/C++をマスターしてればJavaは3日でマスターできる
しかしこのマスターの度合いは最初のCの何をマスターしているかに依存する
Cの標準APIを1/3しか知らなければ、Javaでも1/3しか使えないことになる
Javaが使えるかどうかは、APIを知っているかどうかにかなり
依存すると思われ。
文法を全て知る事がマスターと言うならそんなに難しい事じゃないが
可読性やレスポンスやモジュール強度を考えたコーディングは慣れが必要やね。
380が言っている期間が慣れるまでの期間と言うならば
妥当な期間ではないが、可能な期間かもしれない。
依存すると思われ。
文法を全て知る事がマスターと言うならそんなに難しい事じゃないが
可読性やレスポンスやモジュール強度を考えたコーディングは慣れが必要やね。
380が言っている期間が慣れるまでの期間と言うならば
妥当な期間ではないが、可能な期間かもしれない。
382 ：仕様書無しさん：2005/12/18(日) 14:47:54
俺、昔、C++しか知らなかったけど、
Javaチームのヘルプに借り出されて、
数日でマスターできたぞ。
すげー分かりやすい言語じゃん！って感動した覚えがある。
STL を使いこなせる中級レベルの C++ プログラマなら、eclipse の
助けがあればスイスイ習得できるんじゃねーか？
俺で数日（一日8時間に換算すると一週間ちょっと）だから、
ハイレベルな野郎なら１日もあれば十分だろ。
APIなんてコツ掴めば検索に時間かからんしね。
Cはじめてやったときなんて、情報集めるだけで死にそうだったぜ。
俺Java好きよ。クリエイティブな仕事に専念できるからね。
近代的な言語はこうでなくっちゃね。
Javaチームのヘルプに借り出されて、
数日でマスターできたぞ。
すげー分かりやすい言語じゃん！って感動した覚えがある。
STL を使いこなせる中級レベルの C++ プログラマなら、eclipse の
助けがあればスイスイ習得できるんじゃねーか？
俺で数日（一日8時間に換算すると一週間ちょっと）だから、
ハイレベルな野郎なら１日もあれば十分だろ。
APIなんてコツ掴めば検索に時間かからんしね。
Cはじめてやったときなんて、情報集めるだけで死にそうだったぜ。
俺Java好きよ。クリエイティブな仕事に専念できるからね。
近代的な言語はこうでなくっちゃね。
383 ：仕様書無しさん：2005/12/18(日) 14:49:24
>> 379
内緒にしとけ。世の中は広い。
お前とどうレベルの人間しかこの世にいないなら
今のITの発展はない。
内緒にしとけ。世の中は広い。
お前とどうレベルの人間しかこの世にいないなら
今のITの発展はない。
384 ：仕様書無しさん：2005/12/18(日) 14:54:05
Java使いは、Javaを難しいと思ってるのか？
Javaは簡単だから価値があるんじゃないのか？
C++みたいに習得に時間がかかる言語は糞だと思ってるんじゃないのか？
OOを理解していたら、すんなり使える言語および開発環境がそろっている
のがすばらしいのじゃないのか？
ワード使えたって芥川賞取れないだろ。
C++は単に使うだけなのに苦労するからそこが弱点なんだと
思うがいかがかな？使いづらいワープロソフト使えるからって
自慢になるのか？
Javaは簡単だから価値があるんじゃないのか？
C++みたいに習得に時間がかかる言語は糞だと思ってるんじゃないのか？
OOを理解していたら、すんなり使える言語および開発環境がそろっている
のがすばらしいのじゃないのか？
ワード使えたって芥川賞取れないだろ。
C++は単に使うだけなのに苦労するからそこが弱点なんだと
思うがいかがかな？使いづらいワープロソフト使えるからって
自慢になるのか？
385 ：仕様書無しさん：2005/12/18(日) 14:57:18
>>379
ｗの数は動揺のレベルをあらわすと学校で習わなかったか？
ｗの数は動揺のレベルをあらわすと学校で習わなかったか？
386 ：仕様書無しさん：2005/12/18(日) 15:01:31
おいおい
とにかくJAVAはもうすぐなくなるよ
とにかくJAVAはもうすぐなくなるよ
>>1のようなローエンドユーザーからすれば、
WindowsXP上で動いてるクライアントアプリしか目に入らないだろう。
WindowsXP上で動いてるクライアントアプリしか目に入らないだろう。
388 ：仕様書無しさん：2005/12/18(日) 15:04:02
>>378 おもしろい冗句だが、ハードアーキテクチャの進歩とホストOSの進歩に依存してるんだよ厨。
嘘だと思ったらおまいのいう最新環境をP2とかP3アーキテクチャのマシンで動かしてみろよボケ。
http://www.amazon.co.jp/exec/obidos/ASIN/489471356X/qid=1134885593/sr=8-1/ref=sr_8_xs_ap_i1_xgl/250-7401486-7502641
あとこのくらいは嫁よ。本質わかってねーのに上っ面だけぐだぐだ言われた日にはもうね・・・
嘘だと思ったらおまいのいう最新環境をP2とかP3アーキテクチャのマシンで動かしてみろよボケ。
http://www.amazon.co.jp/exec/obidos/ASIN/489471356X/qid=1134885593/sr=8-1/ref=sr_8_xs_ap_i1_xgl/250-7401486-7502641
あとこのくらいは嫁よ。本質わかってねーのに上っ面だけぐだぐだ言われた日にはもうね・・・
389 ：仕様書無しさん：2005/12/18(日) 15:05:52
390 ：仕様書無しさん：2005/12/18(日) 15:12:22
>>378
Javaが早いとでも言うのか？
構造的にお世辞にも早いとはいえないだろ。
Javaは速さを売りにしてないのに何故こだわるんだ？
早いってのは、昔のJavaに比べて早いってだけ。
一昔、Windowsが重くて使えない糞ＯＳだった時代があって、
ＰＣの性能向上で、Windowsがシェアを握ったが、
おんなじことだろ。他力本願で早くなってるだけで本質的には
おせーんだよ。
ただ、他力本願で性能向上するというパターンで成功したケースは
結構あるんでそのこと自体を悪い事だとは思わん。
本を読め。ちゃんと勉強しろ。
２ちゃんでは許されるが、プロの世界でJavaが早いって言ったら
大笑いされるか、「ハイハイ分かったからあっち行って」扱いだぜ。
Javaが早いとでも言うのか？
構造的にお世辞にも早いとはいえないだろ。
Javaは速さを売りにしてないのに何故こだわるんだ？
早いってのは、昔のJavaに比べて早いってだけ。
一昔、Windowsが重くて使えない糞ＯＳだった時代があって、
ＰＣの性能向上で、Windowsがシェアを握ったが、
おんなじことだろ。他力本願で早くなってるだけで本質的には
おせーんだよ。
ただ、他力本願で性能向上するというパターンで成功したケースは
結構あるんでそのこと自体を悪い事だとは思わん。
本を読め。ちゃんと勉強しろ。
２ちゃんでは許されるが、プロの世界でJavaが早いって言ったら
大笑いされるか、「ハイハイ分かったからあっち行って」扱いだぜ。
どんな言語でも3日とか1週間でマスターできるわけない。
1年でも無理だ。
ただ使えるのと使いこなすのに差がないとでも言うのか
1年でも無理だ。
ただ使えるのと使いこなすのに差がないとでも言うのか
392 ：仕様書無しさん：2005/12/18(日) 16:16:07
>>391
正確に言うと。
出来る奴は一週間でもマスターできる。
出来ない奴は何十年やってもマスターできない。
プログラマーとかアーキテクトには適正ってのがある。
俺、大学で教えてるけど、初めはズブの素人であっても、出来る生徒は
一週間でマスターしてる。
出来る生徒は20人に1人程度だから、一般的に言えば、391は正しいんだが。
ただ、C++を既に使いこなせている人からすると、Javaは一週間もあれば
十分だと思うけど・・・。一般的には違うのかな？
オブジェクト指向が頭に入ってたら言語の違いって誤差じゃない？
（いいすぎかな・・・。）
正確に言うと。
出来る奴は一週間でもマスターできる。
出来ない奴は何十年やってもマスターできない。
プログラマーとかアーキテクトには適正ってのがある。
俺、大学で教えてるけど、初めはズブの素人であっても、出来る生徒は
一週間でマスターしてる。
出来る生徒は20人に1人程度だから、一般的に言えば、391は正しいんだが。
ただ、C++を既に使いこなせている人からすると、Javaは一週間もあれば
十分だと思うけど・・・。一般的には違うのかな？
オブジェクト指向が頭に入ってたら言語の違いって誤差じゃない？
（いいすぎかな・・・。）
>>377
情報工学科の大学を卒業すれば
みな必ずやるよ。
俺はJava推進派だが大学情報工学科で
CASLもやったZ80も弄った。
C/C++も弄った。PrologやMATLAB, Adaも弄った。
どれも知っておいて損はしないものだが
はまり過ぎて仕事や本来の目的に支障を来すところまで来てしまっては
某症候群に陥ってしまうぞ
情報工学科の大学を卒業すれば
みな必ずやるよ。
俺はJava推進派だが大学情報工学科で
CASLもやったZ80も弄った。
C/C++も弄った。PrologやMATLAB, Adaも弄った。
どれも知っておいて損はしないものだが
はまり過ぎて仕事や本来の目的に支障を来すところまで来てしまっては
某症候群に陥ってしまうぞ
>>381
Javaちょっと知っていてもHibernateやXDoclet, AntやMaven
を見ただけで疲弊してしまう香具師がいる。
「まだ覚えるのがあるのか」、と。
たった3日や一週間じゃ即戦力にはならずろくなもんが作れない。
オブジェクト指向のことをわかったつもりになって
やたらと継承しまくる馬鹿とかが多すぎる。
お陰でクラス内が所有するメソッド数がとんでもないことに。
いずれにしても経験が必要。
Javaちょっと知っていてもHibernateやXDoclet, AntやMaven
を見ただけで疲弊してしまう香具師がいる。
「まだ覚えるのがあるのか」、と。
たった3日や一週間じゃ即戦力にはならずろくなもんが作れない。
オブジェクト指向のことをわかったつもりになって
やたらと継承しまくる馬鹿とかが多すぎる。
お陰でクラス内が所有するメソッド数がとんでもないことに。
いずれにしても経験が必要。
情報処理は今後二度と触らないだろうという理由でCASLで取った。
プログラムそのものはCで弄くるのが好きだが、
GUIアプリはWin32APIの仕様が汚くて触る気になれなかった。
Javaだとそこらへんが綺麗に思えてGUIならJavaという感じになった。
C++&Win32APIでアプリ作ろうと思える人は素直に尊敬するよ。
俺は無理、真面目にソース書いても尋常じゃなく汚く見える。
プログラムそのものはCで弄くるのが好きだが、
GUIアプリはWin32APIの仕様が汚くて触る気になれなかった。
Javaだとそこらへんが綺麗に思えてGUIならJavaという感じになった。
C++&Win32APIでアプリ作ろうと思える人は素直に尊敬するよ。
俺は無理、真面目にソース書いても尋常じゃなく汚く見える。
FlashのActionScripterだった俺でも余裕でJavaで食えてるぞ
Javaが難しいとか行ってる奴は単に脳みそがテュルテュルなだけ。
Javaが難しいとか行ってる奴は単に脳みそがテュルテュルなだけ。
397 ：仕様書無しさん：2005/12/18(日) 17:36:35
>>392
> >>391
> 正確に言うと。
> 出来る奴は一週間でもマスターできる。
> 出来ない奴は何十年やってもマスターできない。
> プログラマーとかアーキテクトには適正ってのがある。
>
> 俺、大学で教えてるけど、初めはズブの素人であっても、出来る生徒は
> 一週間でマスターしてる。
> 出来る生徒は20人に1人程度だから、一般的に言えば、391は正しいんだが。
>
> ただ、C++を既に使いこなせている人からすると、Javaは一週間もあれば
> 十分だと思うけど・・・。一般的には違うのかな？
仕事でそれで使い物になる奴はごく僅かだよ。
その程度ではJavaの仕事で最も多いとされるServlet + JDBC開発を
やらせても何かしら手こずることは間違いない。そして納期がいつもより大幅に遅れると。
> オブジェクト指向が頭に入ってたら言語の違いって誤差じゃない？
> （いいすぎかな・・・。）
言い過ぎ。「生徒」ということは中高生にでも教えているのかな？
同じオブジェクト指向言語でも言語が違えば特徴は大きく異なる。
恐らくC++言語を習得してもJavaが初心者な者はsuper()やthis()の扱いで戸惑うだろう。
それから多重継承できないこと。多重継承の代わりをどうやて実装するかで頭を悩ますだろう。
コンピュータの性能が向上した最近なら悩ますこともないが。
> >>391
> 正確に言うと。
> 出来る奴は一週間でもマスターできる。
> 出来ない奴は何十年やってもマスターできない。
> プログラマーとかアーキテクトには適正ってのがある。
>
> 俺、大学で教えてるけど、初めはズブの素人であっても、出来る生徒は
> 一週間でマスターしてる。
> 出来る生徒は20人に1人程度だから、一般的に言えば、391は正しいんだが。
>
> ただ、C++を既に使いこなせている人からすると、Javaは一週間もあれば
> 十分だと思うけど・・・。一般的には違うのかな？
仕事でそれで使い物になる奴はごく僅かだよ。
その程度ではJavaの仕事で最も多いとされるServlet + JDBC開発を
やらせても何かしら手こずることは間違いない。そして納期がいつもより大幅に遅れると。
> オブジェクト指向が頭に入ってたら言語の違いって誤差じゃない？
> （いいすぎかな・・・。）
言い過ぎ。「生徒」ということは中高生にでも教えているのかな？
同じオブジェクト指向言語でも言語が違えば特徴は大きく異なる。
恐らくC++言語を習得してもJavaが初心者な者はsuper()やthis()の扱いで戸惑うだろう。
それから多重継承できないこと。多重継承の代わりをどうやて実装するかで頭を悩ますだろう。
コンピュータの性能が向上した最近なら悩ますこともないが。
Javaをわざわざ高尚にしたがる奴は
周囲に追いついていくだけでいっぱいいっぱいなんだけ
> その程度ではJavaの仕事で最も多いとされるServlet + JDBC開発を
> やらせても何かしら手こずることは間違いない。そして納期がいつもより大幅に遅れると。
仮定に仮定を重ねてるだけ、妄想だけで人生過ごせたら楽でいいよねｗ
周囲に追いついていくだけでいっぱいいっぱいなんだけ
> その程度ではJavaの仕事で最も多いとされるServlet + JDBC開発を
> やらせても何かしら手こずることは間違いない。そして納期がいつもより大幅に遅れると。
仮定に仮定を重ねてるだけ、妄想だけで人生過ごせたら楽でいいよねｗ
400 ：仕様書無しさん：2005/12/18(日) 17:49:53
学生アルバイトとしてJavaだけでいきなり高い時給で稼いだ
時期もおれにはあったもんだ。
だが当時は大したスキルはなかった。
今なら当たり前な直列化やthisのこともJSPのこともServletの仕組みも詳細に
ろくにわからずにプログラミングしていたのだ。
それでソースコードは汚れ納期は半年も遅れた。
だが周りにいる社員もJavaのことが全く解らない状態だった。
PerlやCには詳しいがJavaが解らないという香具師。
Cに詳しいせいか、Javaでは心配しなくても良いような
余計なことまで心配して開発に手こずる香具師が上司でありリーダーだった。
UNIXにはやけに詳しいがJavaのような見慣れない言語には全然詳しくない
と言う状態の彼だったのだ。
C++やCができればJavaもできるという香具師は限られている。
CやC++の何ができたかにもよってくる。
どんなコンパイラとどんな開発環境を使ったか、どんなものを作ってきたかで
Javaに適しているか適していないかが大きく異なってくる。
とくにシステム開発系やハードウェア系はJavaに適していないケースが多く
オブジェクト指向の理解に戸惑うケースが多い。
だが昔からC++でGUIを開発していた者、STLやBoostを使いこなしていたものなら
Javaへの理解は素早いだろう。これらのAPIを使いこなしていれば
本当に3日で覚えられる可能性は否定できない。
ActionScriptはほとんど完璧に近いくらいオブジェクト指向してるのは内緒
402 ：仕様書無しさん：2005/12/18(日) 18:00:04
>>399
ほほう、妄想だと思うのか。
実際にその現場をこの目で見たんだが。
4年前の話だがな。
今ならもっとましな環境にはなっているだろうが、
せっぱ詰まってると新人にやらせてもその程度のことしかできない。
クラスパスの意味がわからなかったりするのが特に多い。
で、Cに熟練した奴がJavaをやれば
うまくいくだろう、と思いたくなるが、
これも落とし穴が多い。
最初は良いんだがだんだんソースコードが汚くなる。
そして顧客に催促されるとますますソースコードは汚れる。
重複コードが多い。
テスト用メソッドを同じクラスに書く(C言語時代の悪い癖をJavaに持ち込んだ結果)。
クラス名やメソッド名は名前を見ただけでひとめでわかるようなものではなく
わざと本人だけが素早く理解できるようにしている。コメントはろくにかかない。
(せめてJavadocコメントくらいは書けや)。
クラスの行数は数万を軽く超える糞コード。
メソッド行数も平気で5000行を越えるスパゲティコード。無駄が多すぎるとクラスの
ファイルサイズがでかくなるし迷惑。引き継ぎ人が一番その迷惑を受ける。
ほほう、妄想だと思うのか。
実際にその現場をこの目で見たんだが。
4年前の話だがな。
今ならもっとましな環境にはなっているだろうが、
せっぱ詰まってると新人にやらせてもその程度のことしかできない。
クラスパスの意味がわからなかったりするのが特に多い。
で、Cに熟練した奴がJavaをやれば
うまくいくだろう、と思いたくなるが、
これも落とし穴が多い。
最初は良いんだがだんだんソースコードが汚くなる。
そして顧客に催促されるとますますソースコードは汚れる。
重複コードが多い。
テスト用メソッドを同じクラスに書く(C言語時代の悪い癖をJavaに持ち込んだ結果)。
クラス名やメソッド名は名前を見ただけでひとめでわかるようなものではなく
わざと本人だけが素早く理解できるようにしている。コメントはろくにかかない。
(せめてJavadocコメントくらいは書けや)。
クラスの行数は数万を軽く超える糞コード。
メソッド行数も平気で5000行を越えるスパゲティコード。無駄が多すぎるとクラスの
ファイルサイズがでかくなるし迷惑。引き継ぎ人が一番その迷惑を受ける。
>>401
中身はJavaScript似だろ。
いずれにせよあれをオブジェクト指向と呼ぶには苦しいものがある。
オブジェクトを作った後でフィールドをあとからいくらでも追加できる仕様は
オブジェクト指向言語として最悪。クラスの契約をいくらでも簡単に
無視できるのは真のオブジェクト指向じゃない。
中身はJavaScript似だろ。
いずれにせよあれをオブジェクト指向と呼ぶには苦しいものがある。
オブジェクトを作った後でフィールドをあとからいくらでも追加できる仕様は
オブジェクト指向言語として最悪。クラスの契約をいくらでも簡単に
無視できるのは真のオブジェクト指向じゃない。
404 ：仕様書無しさん：2005/12/18(日) 18:02:56
Teach Yourself Programming in Ten Years 日本語訳
"プログラミングを独習するには10年かかる
著者： Peter Norvig
日本語訳： yomoyomo、竹中明夫"
http://www.yamdas.org/column/technique/21-daysj.html
"プログラミングを独習するには10年かかる
著者： Peter Norvig
日本語訳： yomoyomo、竹中明夫"
http://www.yamdas.org/column/technique/21-daysj.html
Eclipse激重だよな…
ローカルAPP鯖と同時立ち上げるとストレス感じる
SWT使うくらいなら素直のOSﾈｲﾃｨﾌﾞで作って欲しかった…
OS関係なしに動けるのがEclipseのねらいだって事は分かるけど…
流れ読めなくてごめんね
ローカルAPP鯖と同時立ち上げるとストレス感じる
SWT使うくらいなら素直のOSﾈｲﾃｨﾌﾞで作って欲しかった…
OS関係なしに動けるのがEclipseのねらいだって事は分かるけど…
流れ読めなくてごめんね
406 ：仕様書無しさん：2005/12/18(日) 18:04:26
>>392 大学で教えてるってあたりが眉唾。
実際大学で教わってきたことってのは大体じゃまになる。小手先の言語知識教え込んで来るぐらいなら
何も教えないか、学術計算用の特殊言語でもやっててくれたほうが頭の切り替えが早くていい。
大学教育には一部を除いて何も期待できないし、企業側も期待していないはず。
社会人不適正だから学校に残ってるって現実を忘れたらアウト。
むろん、基本的な論理学とかOS機構とかコンパイラとかシステムプログラムとかアーキテクチャ
あたりのことを教え込んでくれるならまあ歓迎かと。
大学教授にしたところが、たいていは単なる翻訳マシーンになってるんだし、翻訳機は翻訳に注力して
くれた方が世の中のためだね。いっそ学生を翻訳機に使ってもいいと思うぞ。
JavaとかVBは平和に習得しやすいことになってるから、覚えておいてもいいがな。
実際大学で教わってきたことってのは大体じゃまになる。小手先の言語知識教え込んで来るぐらいなら
何も教えないか、学術計算用の特殊言語でもやっててくれたほうが頭の切り替えが早くていい。
大学教育には一部を除いて何も期待できないし、企業側も期待していないはず。
社会人不適正だから学校に残ってるって現実を忘れたらアウト。
むろん、基本的な論理学とかOS機構とかコンパイラとかシステムプログラムとかアーキテクチャ
あたりのことを教え込んでくれるならまあ歓迎かと。
大学教授にしたところが、たいていは単なる翻訳マシーンになってるんだし、翻訳機は翻訳に注力して
くれた方が世の中のためだね。いっそ学生を翻訳機に使ってもいいと思うぞ。
JavaとかVBは平和に習得しやすいことになってるから、覚えておいてもいいがな。
>>390
そんな誤差の範囲内に収まる速度なんぞ
大概の顧客からすれば大したことは無くなってきている。
あとはロジックやアルゴリズム、ハードウェアの問題として片づけることができる
までに状況は好転している。無理してCやアセンブラを導入しなければ
ならない機会は本当にごく稀にまでなってきた。
Javaが抱えている問題は、あとは組み込み分野くらいだ。
そんな誤差の範囲内に収まる速度なんぞ
大概の顧客からすれば大したことは無くなってきている。
あとはロジックやアルゴリズム、ハードウェアの問題として片づけることができる
までに状況は好転している。無理してCやアセンブラを導入しなければ
ならない機会は本当にごく稀にまでなってきた。
Javaが抱えている問題は、あとは組み込み分野くらいだ。
Prototype, Flyweight, Compositを駆使するのが当たり前であるFlashはOOPの勉強に最適。
プログラマになってみて改めて設計を見ると感動すら覚える。
プログラマになってみて改めて設計を見ると感動すら覚える。
>>405
今話題のSun Java Studio Enterpriseをおすすめします。
EclipseのライバルであるNetBeansのエンタープライズ版なんだけど
なんと今では無料（会員登録いるけどね）
Eclipseに比べてプラグインは少なめだけどプロファイラでがんがんチューンできるよ
今話題のSun Java Studio Enterpriseをおすすめします。
EclipseのライバルであるNetBeansのエンタープライズ版なんだけど
なんと今では無料（会員登録いるけどね）
Eclipseに比べてプラグインは少なめだけどプロファイラでがんがんチューンできるよ
410 ：仕様書無しさん：2005/12/18(日) 18:12:50
>>407 そういっておまいも.NETはしっかり押さえてるんだろうな？ｗ
411 ：仕様書無しさん：2005/12/18(日) 18:14:49
> JavaとかVBは平和に習得しやすいことになってるから、覚えておいてもいいがな。
そこでJavaとVBとを一緒にあつかい馬鹿思考が理解できないな。大学の話をしているのに
いきなりVBか。大学ではJavaを教えてきているところが確実に増えているわけだが。
VBはもはや論外。VB開発者すら縮小している。
時代はC#＆#Developだろ！
>>405
Eclipseが重たくなる原因は
１．ワークスペース内にあるファイル数が多い。
２．ソースコードの警告数が何万件と多い。
３．変なプラグインを大量に入れている。
２．の警告が一番遅くなる原因だったりするケースがある。
ソースコードがそれだけ汚れていることをも
示しているだけでなくEclipseを遅くしている原因にもなっている。
これらのうちどれかを改善すれば速くなる。
それからJava VMはJava SE 5 Tigerを使って
起動することをお勧めする。
Eclipseが重たくなる原因は
１．ワークスペース内にあるファイル数が多い。
２．ソースコードの警告数が何万件と多い。
３．変なプラグインを大量に入れている。
２．の警告が一番遅くなる原因だったりするケースがある。
ソースコードがそれだけ汚れていることをも
示しているだけでなくEclipseを遅くしている原因にもなっている。
これらのうちどれかを改善すれば速くなる。
それからJava VMはJava SE 5 Tigerを使って
起動することをお勧めする。
414 ：仕様書無しさん：2005/12/18(日) 18:20:03
>>397
おれは392じゃあないが、C++を使いこなせる奴（オブジェクト指向を理解している奴）は
Javaに移っても戸惑うことは無いよ。戸惑う奴はちゃんと理解できていないだけ。
ただ392の言う素人が１週間でマスターってのは無理だと思うけどね。
392の言うマスターってのはなんとなく使えるって程度なんだろうね。
おれは392じゃあないが、C++を使いこなせる奴（オブジェクト指向を理解している奴）は
Javaに移っても戸惑うことは無いよ。戸惑う奴はちゃんと理解できていないだけ。
ただ392の言う素人が１週間でマスターってのは無理だと思うけどね。
392の言うマスターってのはなんとなく使えるって程度なんだろうね。
415 ：仕様書無しさん：2005/12/18(日) 18:25:00
> 大学教育には一部を除いて何も期待できないし、企業側も期待していないはず。
どこの零細企業だ？ ワンマン経営者の我が儘で動いているちっちゃい会社じゃそうだろうな。
研究期間が揃ってる大手企業じゃそうもいかないんだがな。
> 社会人不適正だから学校に残ってるって現実を忘れたらアウト。
それは言い過ぎだ。対人能力を高めるために学生アルバイトとして社会経験を積むために頑張っている者もいる。
> むろん、基本的な論理学とかOS機構とかコンパイラとかシステムプログラムとかアーキテクチャ
> あたりのことを教え込んでくれるならまあ歓迎かと。
情報工学科を卒業しているならその程度のことはどこの大学でもやっている。
> 大学教授にしたところが、たいていは単なる翻訳マシーンになってるんだし、翻訳機は翻訳に注力して
> くれた方が世の中のためだね。いっそ学生を翻訳機に使ってもいいと思うぞ。
それは文系のとくに社会学系の大学教授だろう。
理系だとそうでもないぞ。たしかに変なのはいるが嘘は教えない。教官同士で教えたことに
問題がないかどうかお互いに監視し合ってもいる。
そのC++使いこなせるって奴の存在が幻想なんだよね
417 ：仕様書無しさん：2005/12/18(日) 18:27:32
>>415
嘘の研究を発表する学者がいるけど・・・
嘘の研究を発表する学者がいるけど・・・
418 ：仕様書無しさん：2005/12/18(日) 18:30:42
>>406
> >>392 大学で教えてるってあたりが眉唾。
> 実際大学で教わってきたことってのは大体じゃまになる。小手先の言語知識教え込んで来るぐらいなら
ちょっとまった、おまいは大学で何を教わり今どんな仕事をしているのか。
大学学部ではそうだが、大学院を行った者からすれば大抵のことは邪魔にはなりやせんよ。
この業界ではたまたま大学で教わったことと仕事とが合致せず邪魔になるケースが多いみたいだが
そうではない人間もいる。専門知識を生かした仕事ってのはIT業界にもかならずある。
画像工学やデジタル信号処理を使った研究をしてきた者がそれに関する仕事をして大学で教わったことが
しっかりと役立ったと言うケースもある。彼は今でも数学を仕事で使いこなしており
ハードウェア開発に役立てている。
> 何も教えないか、学術計算用の特殊言語でもやっててくれたほうが頭の切り替えが早くていい。
学術計算用の特殊言語というと、MathematicaやMATLAB、SASやR言語のことか。
あればかりやってる研究室の香具師らは、残念ながら、オブジェクト指向を最も苦手と
する香具師らだ。入力と出力さえ決まればほかは要らないという考えに固執しすぎるので
「状態」という概念を思いつかずオブジェクト指向設計をろくに考えることができない体質になっている。
> >>392 大学で教えてるってあたりが眉唾。
> 実際大学で教わってきたことってのは大体じゃまになる。小手先の言語知識教え込んで来るぐらいなら
ちょっとまった、おまいは大学で何を教わり今どんな仕事をしているのか。
大学学部ではそうだが、大学院を行った者からすれば大抵のことは邪魔にはなりやせんよ。
この業界ではたまたま大学で教わったことと仕事とが合致せず邪魔になるケースが多いみたいだが
そうではない人間もいる。専門知識を生かした仕事ってのはIT業界にもかならずある。
画像工学やデジタル信号処理を使った研究をしてきた者がそれに関する仕事をして大学で教わったことが
しっかりと役立ったと言うケースもある。彼は今でも数学を仕事で使いこなしており
ハードウェア開発に役立てている。
> 何も教えないか、学術計算用の特殊言語でもやっててくれたほうが頭の切り替えが早くていい。
学術計算用の特殊言語というと、MathematicaやMATLAB、SASやR言語のことか。
あればかりやってる研究室の香具師らは、残念ながら、オブジェクト指向を最も苦手と
する香具師らだ。入力と出力さえ決まればほかは要らないという考えに固執しすぎるので
「状態」という概念を思いつかずオブジェクト指向設計をろくに考えることができない体質になっている。
あの・・・制御系でもない限り、Cで組んでもある程度オブジェクト指向の下地は付いてますよ。
422 ：仕様書無しさん：2005/12/18(日) 18:39:05
２、３年経験のJava厨がリフレクションが遅いから使うなってさ。
実行コストがかかることは理解してるよ、しかし、Javaでリフレクション
を使えば、実装コストの低減が見込める。それに、リフレクションは
サーバサイドのフレームワークでは多用される技術だ。
時代は変わるんだよ、資格保有者だかなんだか知らねぇーが、
ふざけた口きくんじゃねーぞ。ｺﾞﾗｧ
実行コストがかかることは理解してるよ、しかし、Javaでリフレクション
を使えば、実装コストの低減が見込める。それに、リフレクションは
サーバサイドのフレームワークでは多用される技術だ。
時代は変わるんだよ、資格保有者だかなんだか知らねぇーが、
ふざけた口きくんじゃねーぞ。ｺﾞﾗｧ
423 ：仕様書無しさん：2005/12/18(日) 18:42:07
>>415 熱くなってるのはわかるが、研究機関とやらの実態もひどいもんだぞ？
実際金を稼ぎ出さないといけないから、研究結果はどこぞに「展開」しなければならなくなる。
これがひどい作業で、とにかく人海戦術でバグたたきだし、半ばリバースでドキュメント作り・・・
なんつうか最悪のデスマと化す。
社会人不適正だから学校に残ってるのは お ま い ら 指 導 者 だ。
研究者の中には優秀な方もいる。だがしかし、お偉い顔で他人様の成果を吹き込んでるだけの屑は
はっきり言っていらね。
国立大の情報工学科を出たのを回されたことがあったが、ひどいもんだった。実務には全く関係のない
観念と論理の世界（記号論とかメタ論理なお話には熱くなってたがな）で生きてきたらしく、
高専とか専門卒のやつの方が当座使えた。
理系にも屑とかごろつきとかしか言いようのない「教官」（断じて研究者じゃない）はごろごろいる。
大学閥に従って、関連のある学校に天下ってるのなんか手のつけようがないらしいしな。
学生馬鹿にする（母校じゃないからな）、まともな指導しない（馬鹿にしてるからな）、果ては助手に丸投げで
自分はどっかに逐電してるのまでいる。漏れが聞いた話では、院生（女性な）とラブホから出てきたところを
掃除のバイトしてた２部学生に見つかったのまでいたそうだ。どうなったかはしらねが。
大学の「教員」は指導者面してこんなとこ書き込んでねえで自分のリファクタリング汁。
実際金を稼ぎ出さないといけないから、研究結果はどこぞに「展開」しなければならなくなる。
これがひどい作業で、とにかく人海戦術でバグたたきだし、半ばリバースでドキュメント作り・・・
なんつうか最悪のデスマと化す。
社会人不適正だから学校に残ってるのは お ま い ら 指 導 者 だ。
研究者の中には優秀な方もいる。だがしかし、お偉い顔で他人様の成果を吹き込んでるだけの屑は
はっきり言っていらね。
国立大の情報工学科を出たのを回されたことがあったが、ひどいもんだった。実務には全く関係のない
観念と論理の世界（記号論とかメタ論理なお話には熱くなってたがな）で生きてきたらしく、
高専とか専門卒のやつの方が当座使えた。
理系にも屑とかごろつきとかしか言いようのない「教官」（断じて研究者じゃない）はごろごろいる。
大学閥に従って、関連のある学校に天下ってるのなんか手のつけようがないらしいしな。
学生馬鹿にする（母校じゃないからな）、まともな指導しない（馬鹿にしてるからな）、果ては助手に丸投げで
自分はどっかに逐電してるのまでいる。漏れが聞いた話では、院生（女性な）とラブホから出てきたところを
掃除のバイトしてた２部学生に見つかったのまでいたそうだ。どうなったかはしらねが。
大学の「教員」は指導者面してこんなとこ書き込んでねえで自分のリファクタリング汁。
424 ：仕様書無しさん：2005/12/18(日) 18:44:19
>>422
フレームワークでの使用は別問題でしょ。
基盤フレームワーク作っているならわかるが
通常のwebアプリにリフレクションが必要とは思えない。
そんなことも知らずにうれしそうにリフレクションを使ってる４２２は無能だと思う。
フレームワークでの使用は別問題でしょ。
基盤フレームワーク作っているならわかるが
通常のwebアプリにリフレクションが必要とは思えない。
そんなことも知らずにうれしそうにリフレクションを使ってる４２２は無能だと思う。
425 ：仕様書無しさん：2005/12/18(日) 18:46:05
>>421
制御系だろうが、ＣＯＢＯＬＥＲだろうが、素養のある奴はそれなりの
プログラムが書けるもんだが、ない奴はどんな言語を使おうが、１本道路
見たいなプログラムを書く。最近、PL/SQLをやった、初めてなんで参考に
なるプログラムくださいと言ったら、まさに一本道。えーPL/SQLで蛸なの
と思い、ググッたらきちんと構造化できるやん。そんなプログラムを
１００本近くも作るから、顧客から文句言われるんだよ。
制御系だろうが、ＣＯＢＯＬＥＲだろうが、素養のある奴はそれなりの
プログラムが書けるもんだが、ない奴はどんな言語を使おうが、１本道路
見たいなプログラムを書く。最近、PL/SQLをやった、初めてなんで参考に
なるプログラムくださいと言ったら、まさに一本道。えーPL/SQLで蛸なの
と思い、ググッたらきちんと構造化できるやん。そんなプログラムを
１００本近くも作るから、顧客から文句言われるんだよ。
426 ：仕様書無しさん：2005/12/18(日) 18:48:34
>>420 ヒートアップしすぎだな。メッキがはがれてるぞ。文脈がおかしい。
ことソフトに関する限り、国内の学者様が役に立ってる例は「無い」
唯一TRON教の教祖と弟子の方々が孤塁を守っていらっしゃるが、あのくらい「一般の技術者にとって役立つ」
「道を示し人を導く」例は、ほかの翻訳「研究者」にはないだろ？
みーんなそろいもそろって翻訳とローカライズと新趣向紹介をやってるだけだ。
卓越した英語力を駆使してな。
独創性なんか微塵もない。Javaなんか最たるものだろ。
ことソフトに関する限り、国内の学者様が役に立ってる例は「無い」
唯一TRON教の教祖と弟子の方々が孤塁を守っていらっしゃるが、あのくらい「一般の技術者にとって役立つ」
「道を示し人を導く」例は、ほかの翻訳「研究者」にはないだろ？
みーんなそろいもそろって翻訳とローカライズと新趣向紹介をやってるだけだ。
卓越した英語力を駆使してな。
独創性なんか微塵もない。Javaなんか最たるものだろ。
427 ：仕様書無しさん：2005/12/18(日) 19:31:33
ここのスレ、自分の物差しでしか見ない奴が多すぎる。
自分の周りで起こっていることが、あらゆるところで起こっていると
思っているんだろう。
今時、一人で開発している奴はおらん。チームで開発してるんだろ。
いちいち揉めてたら開発が立ち行かなくなるじゃない？
コンピュータとのコミュニケーション能力ばっか目が行ってるようだけど
、人とのコミュニケーションが出来ない奴は業界には必要ないんよ。
一生プログラマやり抜くつもりなら良いんだが・・・。
プログラマの給料は安いぜ。
自分の周りで起こっていることが、あらゆるところで起こっていると
思っているんだろう。
今時、一人で開発している奴はおらん。チームで開発してるんだろ。
いちいち揉めてたら開発が立ち行かなくなるじゃない？
コンピュータとのコミュニケーション能力ばっか目が行ってるようだけど
、人とのコミュニケーションが出来ない奴は業界には必要ないんよ。
一生プログラマやり抜くつもりなら良いんだが・・・。
プログラマの給料は安いぜ。
ＰＧだって人とのコミュニケーション能力は必要だべ。
能力が低いＰＧほど必要だ。
超能力かよってぐらい強力なＰＧなら、コミュニケーション能力の欠如も許される。
能力が低いＰＧほど必要だ。
超能力かよってぐらい強力なＰＧなら、コミュニケーション能力の欠如も許される。
429 ：仕様書無しさん：2005/12/18(日) 20:52:20
神の域に達しているプログラマを知っている。
ただし、そいつの声を聞いたやつはいない。
一日中黙ってる。全神経をＰＧにつぎ込んでいるんだろう。
出世はしてないが恐れられている。
ただし、そいつの声を聞いたやつはいない。
一日中黙ってる。全神経をＰＧにつぎ込んでいるんだろう。
出世はしてないが恐れられている。
そういう存在になりたいな
なりたくねーよ
アクティブでハイセンスで株でボロい定時プログラマーがいい
アクティブでハイセンスで株でボロい定時プログラマーがいい
432 ：仕様書無しさん：2005/12/18(日) 21:12:38
俺の事か。。。
>>432 え？どっち？ｗ
434 ：仕様書無しさん：2005/12/18(日) 21:15:05
そういう存在のほう
なんだ廃人のことか、期待して損した
436 ：仕様書無しさん：2005/12/18(日) 21:25:16
神さまレベルのＰＧは、見ただけでソフトを移植したりできるみたい。
贋作作るのは確かにうまい。
ただ、オリジナリティーさえあれば金儲けができるんだが・・。
贋作作るのは確かにうまい。
ただ、オリジナリティーさえあれば金儲けができるんだが・・。
437 ：仕様書無しさん：2005/12/18(日) 21:54:50
わかったよ。職場に寝袋持ち込んで神になれ。
俺はお断りだｗ
俺はお断りだｗ
438 ：仕様書無しさん：2005/12/18(日) 21:55:52
439 ：仕様書無しさん：2005/12/18(日) 22:53:51
440 ：仕様書無しさん：2005/12/19(月) 00:28:33
上の方に出てたSun Java Studio Enterpriseっての、今落として起動してみたんだけど…
サンプルプロジェクト開いただけでワーキングセット200MB、仮想メモリ含めると343MBメモリ
食うってすげーなコレｗ
確かにEclipseの緩慢な動作からすると随分キビキビ動く印象はあるけど、メモリがたっぷり
あればの話だな。明日試してみるけど、512MBしかメモリ積んでないのにローカルで
WebLogicも動かさなきゃいけない(その他資料参照でExcel/Word、DB編集でAccessも
起動してる)職場PCだと、多分ページングの嵐で使い物にならないだろう。
これだからJava(のクライアント)アプリはなー
リソースたっぷりな鯖機で動くServletなら作るの楽だし、C/C++みたいに他のメンバーの開発
物との間のバイナリ互換性にピリピリにしなくていいしで無茶苦茶楽、Javaマンセーと言いたく
なるけど、いかんせんメモリ食い過ぎ。
いくらJITの性能が上がって処理速度が速くなってもFull-GC頻発してたら何の意味も無い。
しかも1アプリでこの有様じゃ複数のJavaアプリ起動したら何GBメモリ用意すりゃいいんだ
っての。クライアントで普及しない訳だよな。
サンプルプロジェクト開いただけでワーキングセット200MB、仮想メモリ含めると343MBメモリ
食うってすげーなコレｗ
確かにEclipseの緩慢な動作からすると随分キビキビ動く印象はあるけど、メモリがたっぷり
あればの話だな。明日試してみるけど、512MBしかメモリ積んでないのにローカルで
WebLogicも動かさなきゃいけない(その他資料参照でExcel/Word、DB編集でAccessも
起動してる)職場PCだと、多分ページングの嵐で使い物にならないだろう。
これだからJava(のクライアント)アプリはなー
リソースたっぷりな鯖機で動くServletなら作るの楽だし、C/C++みたいに他のメンバーの開発
物との間のバイナリ互換性にピリピリにしなくていいしで無茶苦茶楽、Javaマンセーと言いたく
なるけど、いかんせんメモリ食い過ぎ。
いくらJITの性能が上がって処理速度が速くなってもFull-GC頻発してたら何の意味も無い。
しかも1アプリでこの有様じゃ複数のJavaアプリ起動したら何GBメモリ用意すりゃいいんだ
っての。クライアントで普及しない訳だよな。
Java厨の反論まだ？
まあ重いのは事実だし。
けど使われてる。
Java嫌いなのは解らんでもないけど、自分の好みだけで動く奴こそ厨房だと思う。
けど使われてる。
Java嫌いなのは解らんでもないけど、自分の好みだけで動く奴こそ厨房だと思う。
443 ：仕様書無しさん：2005/12/19(月) 09:13:10
重いのは事実として適材(俺はないとおもうが)適所に我慢して使う
ならば許せる範疇だが
ネイティブと同じパフォーマンスだと連呼する糞厨だけは許せないな
真実を真実として語れよ糞厨、も前の脳内プロファイラはJavaの時だけ
クロックスピードが1k倍になるのか
ならば許せる範疇だが
ネイティブと同じパフォーマンスだと連呼する糞厨だけは許せないな
真実を真実として語れよ糞厨、も前の脳内プロファイラはJavaの時だけ
クロックスピードが1k倍になるのか
444 ：仕様書無しさん：2005/12/19(月) 10:06:34
３日や１週間でマスターってそんな言葉を軽々しく使うのっておかしいぞ。
確かに、ここに書き込んでる奴らでそれを言う資格のある奴もいるのかも
しれないけど、大半の奴らはきっと言うべきじゃないぞ。
お前ら、１週間とかでwindowsのプログラムとか組めるのかよ。
何でも極めるのってすさまじい努力と時間が必要だと俺思うんだけど。。
確かに、ここに書き込んでる奴らでそれを言う資格のある奴もいるのかも
しれないけど、大半の奴らはきっと言うべきじゃないぞ。
お前ら、１週間とかでwindowsのプログラムとか組めるのかよ。
何でも極めるのってすさまじい努力と時間が必要だと俺思うんだけど。。
445 ：仕様書無しさん：2005/12/19(月) 10:17:26
C++ -> Javaならば
言語仕様ならば0.5日でOK
APIを学習するのはそれなりに時間がかかる
APIドキュメントは機能からの逆引きができない糞文書だしね
grepを使って機能からの逆引きをよくしたなあ
言語仕様ならば0.5日でOK
APIを学習するのはそれなりに時間がかかる
APIドキュメントは機能からの逆引きができない糞文書だしね
grepを使って機能からの逆引きをよくしたなあ
446 ：仕様書無しさん：2005/12/19(月) 10:24:30
447 ：仕様書無しさん：2005/12/19(月) 10:39:51
Javaのメモリ食いは最新技術をつきつめる人々への冒涜だし
技術の後退に向かう手法ともいえる。メモリつみゃーいー
だろの軽い尻の馬鹿女という感じかな
技術の後退に向かう手法ともいえる。メモリつみゃーいー
だろの軽い尻の馬鹿女という感じかな
448 ：仕様書無しさん：2005/12/19(月) 10:41:25
C/C++はスリムでシャープでレスポンス抜群な浅田まおちゃんという感じかな
449 ：仕様書無しさん：2005/12/19(月) 10:55:15
webの貧弱なUIのままでいいならともかくとして
リッチクライアントを目指そうと思うと
マシンスペックの物理的な向上は否めんと思うが。
つまり
技術をつきつめる == マシンの性能がついてこない
ってパターンもあると思われるので
447の言う事は一概にそうとは言い切れないと思う。
もちろん
技術をつきつめる == 複雑な処理を小さいマシンで軽快にこなす
ってパターンもたくさんるし、むしろこのパターンのが
多いとも思う。電化製品とかもドンドン小さくなっていったり
してるしね。
リッチクライアントを目指そうと思うと
マシンスペックの物理的な向上は否めんと思うが。
つまり
技術をつきつめる == マシンの性能がついてこない
ってパターンもあると思われるので
447の言う事は一概にそうとは言い切れないと思う。
もちろん
技術をつきつめる == 複雑な処理を小さいマシンで軽快にこなす
ってパターンもたくさんるし、むしろこのパターンのが
多いとも思う。電化製品とかもドンドン小さくなっていったり
してるしね。
450 ：仕様書無しさん：2005/12/19(月) 11:00:46
>>449
というか、膨れ上がるフレームワークオブジェクト
膨大なつかいぱなしメモリをfreeするタイミングの最適化ができないVM
メモリを大量に使うとシリアライズされたメモリのリストアでまた時間が
かかる。(EJBパッシベート)
使いもしないクラスのインスタンスをどんどん生成するJAVA厨に
問題があるのよ。どんなにメモリをつんでもつんだ最大値が限界値であり
JAVA厨はその限界値を全く意識してくれない馬鹿ぞろいなのが問題。
というか、膨れ上がるフレームワークオブジェクト
膨大なつかいぱなしメモリをfreeするタイミングの最適化ができないVM
メモリを大量に使うとシリアライズされたメモリのリストアでまた時間が
かかる。(EJBパッシベート)
使いもしないクラスのインスタンスをどんどん生成するJAVA厨に
問題があるのよ。どんなにメモリをつんでもつんだ最大値が限界値であり
JAVA厨はその限界値を全く意識してくれない馬鹿ぞろいなのが問題。
451 ：仕様書無しさん：2005/12/19(月) 11:08:03
まるで体脂肪率200%のデブがさらに大食していくようだな>JAVA
そして、いーんだよベルトゆるめれば(メモリつめば)大丈夫
そして、いーんだよベルトゆるめれば(メモリつめば)大丈夫
452 ：449：2005/12/19(月) 11:12:47
ん～確かにガベージコレクションがVM任せなJavaは
Cとかに比べてメモリ管理が雑なのは確かだな。
使いもしないインスタンスを作っているPGも
けっこういる。staticやsingletonとかうまく使えよとも思う。
平気でOutOfMemory出す奴達も見てきた。
PGのせいで無駄が多くなると言う事に関しては否定はしない。
Cとかに比べてメモリ管理が雑なのは確かだな。
使いもしないインスタンスを作っているPGも
けっこういる。staticやsingletonとかうまく使えよとも思う。
平気でOutOfMemory出す奴達も見てきた。
PGのせいで無駄が多くなると言う事に関しては否定はしない。
平気でっていうかなんというか
「OutOfMemoryを出さない事を目的として」
最適化するPGはそれこそクズだと思うのだが。
「OutOfMemoryを出さない事を目的として」
最適化するPGはそれこそクズだと思うのだが。
ちげぇよ
わっけわかんねぇ意味ないループとかし倒して
落ちたりするんだよ。ったく
わっけわかんねぇ意味ないループとかし倒して
落ちたりするんだよ。ったく
そんなのインスタンスとか関係ｎ（ｒｙ
ループの中で使い捨てのnewしまくりとか。
かくして、バカの尻拭いのため、日夜JVMは戦いつづけているのである。
これからも頑張ってくれ＜JVM
460 ：仕様書無しさん：2005/12/20(火) 09:46:56
Stringに延々と += してたらOutOfMemory なるぜ。
461 ：仕様書無しさん：2005/12/20(火) 10:12:03
>>460
Java5だとそれもJVMが勝手に大替してくれる。
Java5だとそれもJVMが勝手に大替してくれる。
>>452
つ[java.lang.ref.SoftReference]
つ[java.lang.ref.SoftReference]
なんかググってたらすごいの見つけた。
>すくなくとも、Java は問題ではない。開発言語を使う側に問題がある。自称Javaプログラマ、SE さようなら！
>尻拭き部隊はホトホト疲れてしまいます。
>また、言語を問わずJava にバグがあるのは、仕方の無い事です。
>例えば、Java 1.5.0(ビルド1.5.0_02-b09)では、split などおかしい。
>_dataStr = "A,B,C,D";
>STRING[] _data = _dataStr.split(",")；
>のけっかは、
>先頭の「A」が抜け、
>_data[1] ==> B
>_data[2] ==> C
>_data[3] ==> D
>となります。
>ので、わたしはこうします。
>_dataStr = "A,B,C,D";
>_dataStr = "," + _dataStr;
>すると、
>_data[1] ==> A
>_data[2] ==> B
>_data[3] ==> C
>_data[4] ==> D
>と、正常になります。
>言語はだましだまし使うのが常識だと、私は思っています。
>すくなくとも、Java は問題ではない。開発言語を使う側に問題がある。自称Javaプログラマ、SE さようなら！
>尻拭き部隊はホトホト疲れてしまいます。
>また、言語を問わずJava にバグがあるのは、仕方の無い事です。
>例えば、Java 1.5.0(ビルド1.5.0_02-b09)では、split などおかしい。
>_dataStr = "A,B,C,D";
>STRING[] _data = _dataStr.split(",")；
>のけっかは、
>先頭の「A」が抜け、
>_data[1] ==> B
>_data[2] ==> C
>_data[3] ==> D
>となります。
>ので、わたしはこうします。
>_dataStr = "A,B,C,D";
>_dataStr = "," + _dataStr;
>すると、
>_data[1] ==> A
>_data[2] ==> B
>_data[3] ==> C
>_data[4] ==> D
>と、正常になります。
>言語はだましだまし使うのが常識だと、私は思っています。
>_dataStr = "A,B,C,D";
>STRING[] _data = _dataStr.split(",")；
>のけっかは、
>先頭の「A」が抜け、
>_data[1] ==> B
>_data[2] ==> C
>_data[3] ==> D
_data[4] ==> IndexOutOfBoundsException
>となります。
>STRING[] _data = _dataStr.split(",")；
>のけっかは、
>先頭の「A」が抜け、
>_data[1] ==> B
>_data[2] ==> C
>_data[3] ==> D
_data[4] ==> IndexOutOfBoundsException
>となります。
⊂⌒~⊃｡Д｡）⊃ テメーの尻拭いにホトホト疲れるわい
470 ：69式フリーPG ◆hND3Lufios ：2005/12/20(火) 20:47:53
うん。
友人を見てるとマジで可哀相だと思う。
Javaが悪いわけじゃないんだけどねぇ。。。
友人を見てるとマジで可哀相だと思う。
Javaが悪いわけじゃないんだけどねぇ。。。
471 ：仕様書無しさん：2005/12/20(火) 20:50:54
はいはい、ﾜﾛｽﾜﾛｽ
>>467
これじゃCも使えないじゃない
これじゃCも使えないじゃない
変数名にアンスコ入れるなｗ
476 ：仕様書無しさん：2005/12/20(火) 22:38:20
なんかWindowsアプリとアプレットとサーブレットが混じってないか？
JavaはWindowsアプリとアプレットは、「かなり遅い」で「良いマシン（CPU:1G,MEM:256M以上）
でないと使用に耐えない」ため、「C++やVBの勝ち」でいいんだろ。
サーブレットはCよりは遅いが、運用上問題ないスピードなので、使い安さから「Javaの勝ち」
でいいんだろ。
何か問題あるのか？
JavaはWindowsアプリとアプレットは、「かなり遅い」で「良いマシン（CPU:1G,MEM:256M以上）
でないと使用に耐えない」ため、「C++やVBの勝ち」でいいんだろ。
サーブレットはCよりは遅いが、運用上問題ないスピードなので、使い安さから「Javaの勝ち」
でいいんだろ。
何か問題あるのか？
>>474
なんでアンスコなんでだめなん？
なんでアンスコなんでだめなん？
サーブレットはPHPの勝ち！
>>479
OracleのJDBCドライバはしっかりアンスコ使ってたけど・・・
OracleのJDBCドライバはしっかりアンスコ使ってたけど・・・
482 ：仕様書無しさん：2005/12/21(水) 00:37:04
>クラス名を小文字とかから始めてるソースとかきっついだろ?
それされると混乱するからな…
でも、アンスコ入りで混乱することはないﾄｵﾓｳ。単に慣れてないとキモイというだけで。
PL/SQLも頻繁に書いているおいらには違和感全くなし。
それされると混乱するからな…
でも、アンスコ入りで混乱することはないﾄｵﾓｳ。単に慣れてないとキモイというだけで。
PL/SQLも頻繁に書いているおいらには違和感全くなし。
getter/setter専用のprivateフィールドだけをアンダースコートにするか
逆にそれら以外をアンダースコートにする。ようは統一しちゃえばいい。
逆にそれら以外をアンダースコートにする。ようは統一しちゃえばいい。
>>476
お前さんの良いマシンは何年前の話ですか？
お前さんの良いマシンは何年前の話ですか？
>>484
同意すんなツッコめ。テニスウェアかよ！みたいにツッコめ。
同意すんなツッコめ。テニスウェアかよ！みたいにツッコめ。
>>485
確かにｗ
確かにｗ
いや、アンダースコート気にいったｗ
>>483
Javaコーディング規約にはそんなのはないな
Javaコーディング規約にはそんなのはないな
>>476
CGI + CだったらHTTPサーバ経由でのチャット作りではServletのほうが
速いぞ。
CGIの仕組みの問題ではあるが。
CGIの部分を自作できないことにはどうにもならんな。
多くのCプログラマがCGI部分を自作して改良してServletのサーバへの
リクエスト/レスポンス速度を上回らせるのはそう簡単なことではない。
CGI + CだったらHTTPサーバ経由でのチャット作りではServletのほうが
速いぞ。
CGIの仕組みの問題ではあるが。
CGIの部分を自作できないことにはどうにもならんな。
多くのCプログラマがCGI部分を自作して改良してServletのサーバへの
リクエスト/レスポンス速度を上回らせるのはそう簡単なことではない。
492 ：仕様書無しさん：2005/12/21(水) 08:48:20
そこでFastCGI
493 ：仕様書無しさん：2005/12/21(水) 08:55:33
ISAPIならば無敵
494 ：仕様書無しさん：2005/12/21(水) 09:25:19
>491
確かにWEBサーバ+CのCGIならサーブレットの方が早いが、比べるとしたらWEBサーバ使わずに全部自作だろう。
HTTPのWEBサイトなどに限定すると、通信系のC使いから文句が出るぞ。
多くのCプログラマがやろうとしているが難しい？
通信系のC使いならソケット使ってポーリング部自作なんて、普通にやるんじゃないか？
今俺の回りの人間だけでも、それができるC使いは30人はいる。
確かにWEBサーバ+CのCGIならサーブレットの方が早いが、比べるとしたらWEBサーバ使わずに全部自作だろう。
HTTPのWEBサイトなどに限定すると、通信系のC使いから文句が出るぞ。
多くのCプログラマがやろうとしているが難しい？
通信系のC使いならソケット使ってポーリング部自作なんて、普通にやるんじゃないか？
今俺の回りの人間だけでも、それができるC使いは30人はいる。
495 ：仕様書無しさん：2005/12/21(水) 09:31:19
ところでPHPって結構いいの？
特に平行処理時のパフォーマンスについて聞きたい。
どのぐらいのアクセスまで耐えられる？
あと話は飛ぶが俺の感覚では「良いパソコン」は、
CPUが1G越えで、メモリが256越だけどどうよ？
特に平行処理時のパフォーマンスについて聞きたい。
どのぐらいのアクセスまで耐えられる？
あと話は飛ぶが俺の感覚では「良いパソコン」は、
CPUが1G越えで、メモリが256越だけどどうよ？
496 ：仕様書無しさん：2005/12/21(水) 09:35:41
>>464
String += 使わないって一切つかっちゃだめってこと？
StringBufferは長い文字列連結の時だけでいいかと思ってたけど、
サーバーアプリだとゴミがたまるのは致命的だから
一切使わないくらいの勢いでやるべきかな？
String += 使わないって一切つかっちゃだめってこと？
StringBufferは長い文字列連結の時だけでいいかと思ってたけど、
サーバーアプリだとゴミがたまるのは致命的だから
一切使わないくらいの勢いでやるべきかな？
ちょっとしたログ出力の編集くらいでは+使うけど、まぁその程度だな。
499 ：仕様書無しさん：2005/12/21(水) 10:17:20
小さなことからこつこつと。
細かい習慣付けと努力が、普通になんともなく動くアプリの第一歩です。
細かい習慣付けと努力が、普通になんともなく動くアプリの第一歩です。
>>495
>CPUが1G越えで、メモリが256越だけどどうよ？
良いPCの定義だったら、
その辺のsofmapなんかで普通に買えるパーツで
最高スペックを寄せ集めたレベルじゃないか？
CPUは3GHzくらい余裕で行くだろうし、
メモリは普通に1Gは越えるだろう？
てか、俺が使ってるPCは最低でもメモリ1G積んでるけど。
>CPUが1G越えで、メモリが256越だけどどうよ？
良いPCの定義だったら、
その辺のsofmapなんかで普通に買えるパーツで
最高スペックを寄せ集めたレベルじゃないか？
CPUは3GHzくらい余裕で行くだろうし、
メモリは普通に1Gは越えるだろう？
てか、俺が使ってるPCは最低でもメモリ1G積んでるけど。
502 ：仕様書無しさん：2005/12/21(水) 11:57:58
JAVAは最新の良いPCでも動作が重い
ネイティブは7～8年前の古いPCでもスコスコ動く
でいいんでねえの
ネイティブは7～8年前の古いPCでもスコスコ動く
でいいんでねえの
いまどきのコード補完機能があるIDEで_がダメとかクラスは大文字からでないとダメとか
ハンガリアンみたいなこといってんじゃねーよ
ハンガリアンみたいなこといってんじゃねーよ
>>503
「規約」という単語も知らんのか…
「規約」という単語も知らんのか…
>>503
Lispを使いたまえ
Lispを使いたまえ
>>503
コード補完機能あるからクラス名を小文字で始めても影響ないって事か？
全然関係ないしｗ
お前痛すぎて終わってるなｗ
IDEって言葉覚えたてだからって、張り切ってんじゃねぇよｗ
いやーお前ほんますごいわ(・∀・)ﾆﾔﾆﾔ
βακα..._φ(ﾟДﾟ )
コード補完機能あるからクラス名を小文字で始めても影響ないって事か？
全然関係ないしｗ
お前痛すぎて終わってるなｗ
IDEって言葉覚えたてだからって、張り切ってんじゃねぇよｗ
いやーお前ほんますごいわ(・∀・)ﾆﾔﾆﾔ
βακα..._φ(ﾟДﾟ )
508 ：仕様書無しさん：2005/12/21(水) 22:54:08
いやいや、職業プログラマの言う「良いパソコン」って意味だよ。
ユーザやゲーマーの言う良いパソコンじゃなくて。
良いパソコン＝自分の作ったプログラムが快適に動くパソコン
事務処理の客先では400-800MHzぐらいのが動いている事もあるだろう？
>497
最近のJavaコンパイラは実行中に最適化するから、
StringBufferだの+だの気にする必要ないよ。
ユーザやゲーマーの言う良いパソコンじゃなくて。
良いパソコン＝自分の作ったプログラムが快適に動くパソコン
事務処理の客先では400-800MHzぐらいのが動いている事もあるだろう？
>497
最近のJavaコンパイラは実行中に最適化するから、
StringBufferだの+だの気にする必要ないよ。
509 ：69式フリーPG ◆hND3Lufios ：2005/12/21(水) 23:37:05
漢なら黙ってFastCGI+C/C++
あ、libstdc++.aはでぶってるからな。stripを忘れずに。
あ、libstdc++.aはでぶってるからな。stripを忘れずに。
510 ：仕様書無しさん：2005/12/21(水) 23:39:33
こないだ見かけた知ったか馬鹿
new StringBuffer("AAA").append("BBB").append("CCC")...toString();
もうアホかと。馬鹿かと。
"AAA"+"BBB"+"CCC"はさすがにコンパイラが最適化してくれるでそ。
new StringBuffer("AAA").append("BBB").append("CCC")...toString();
もうアホかと。馬鹿かと。
"AAA"+"BBB"+"CCC"はさすがにコンパイラが最適化してくれるでそ。
>>509
おっさんは業務系なのか制御系なのかはっきりしろ
おっさんは業務系なのか制御系なのかはっきりしろ
いやー、よく釣れるスレだな。
VBが叩く価値無くなったから、Javaにターゲットが移行したと思われる。
ちゃうちゃう。
厨の居住地がVBからJavaに移っただけ。
厨の居住地がVBからJavaに移っただけ。
おいおい、バージョンによってコーディングスタイルまで変えないと最適化されないのか？
明確じゃないだけCよりも職人芸が要求されそうな感じ。かえって難解なんじゃね？
明確じゃないだけCよりも職人芸が要求されそうな感じ。かえって難解なんじゃね？
"AAA"+"BBB"+"CCC"は"AAABBBCCC"としてコンパイルされた
519 ：仕様書無しさん：2005/12/22(木) 09:15:29
Javaって馬鹿に安全な機能を提供して墓穴を掘った言語の代表だなw
ガベコレとかそうだよな。
あれがどういうタイミングで開放するか意識して気を配ってコーディング
するくらいなら、てめえで明示的にfreeなりdeleteするほうがシンプルで簡単。
あれがどういうタイミングで開放するか意識して気を配ってコーディング
するくらいなら、てめえで明示的にfreeなりdeleteするほうがシンプルで簡単。
521 ：仕様書無しさん：2005/12/22(木) 09:23:59
いやいやJavaの考えとしては「古い物は捨てて行く」のが基本なんだよ。
今のコンパイラで最適なコーディングをする。昔の常識も捨てて行く。
そこが脳老人には受け入れられ難い所かな。
今のコンパイラで最適なコーディングをする。昔の常識も捨てて行く。
そこが脳老人には受け入れられ難い所かな。
522 ：仕様書無しさん：2005/12/22(木) 09:25:30
バージョンによって#ifdef - #endif すればいいじゃない。
523 ：69式フリーPG ◆hND3Lufios ：2005/12/22(木) 09:29:22
いや、IBMのJDKにあわせて1.3に留めておくってのもありかと。
524 ：仕様書無しさん：2005/12/22(木) 09:38:08
ガーベージコレクションもJavaVMのオプションで最適な方法を選べるから気にしなくていいよ。
525 ：仕様書無しさん：2005/12/22(木) 09:39:38
>522
Javaにコンパイラ制御などの洒落た機能はありませんw
Javaにコンパイラ制御などの洒落た機能はありませんw
526 ：仕様書無しさん：2005/12/22(木) 09:42:45
いやいやJavaの考えとしては「馬鹿のために作るだから」いいかげんが基本なんだよ。
今の馬鹿に最適な機能を提供する。昔の馬鹿を捨てて行く。
そこがJa馬鹿には理解できない所かな。
今の馬鹿に最適な機能を提供する。昔の馬鹿を捨てて行く。
そこがJa馬鹿には理解できない所かな。
>>517
そんなこと言ってたらC++が使えんぞ。
そんなこと言ってたらC++が使えんぞ。
ガベコレ理解できないやつの脳が理解できない。
オブジェクトがどのスレッドからも到達不能になったら解放されるが、
それがどのタイミングかはわからない。
だから解放のタイミングに依存しないコードを書く。
これだけのことが何でわからないんだ？
オブジェクトがどのスレッドからも到達不能になったら解放されるが、
それがどのタイミングかはわからない。
だから解放のタイミングに依存しないコードを書く。
これだけのことが何でわからないんだ？
誰かが片付けるだろうとポイ捨てできる神経が理解出来ない。
ゴミや吸殻を捨てるDQN並みの神経だな。
ゴミはゴミ箱に。吸殻は灰皿に。
ゴミや吸殻を捨てるDQN並みの神経だな。
ゴミはゴミ箱に。吸殻は灰皿に。
530 ：仕様書無しさん：2005/12/22(木) 10:35:40
>オブジェクトがどのスレッドからも到達不能になったら解放されるが
非力なVMくんは悲鳴をあげている。。
ガベコレのスレッドを動かそうとしても馬鹿厨がふんだんに糞クラスを
インスタンス化するからCPUの負荷が100%で物理メモリも余裕が無い。
開放しようと動作を試行するがガベコレスレッドは動けない。
非力なVMくんは悲鳴をあげている。。
ガベコレのスレッドを動かそうとしても馬鹿厨がふんだんに糞クラスを
インスタンス化するからCPUの負荷が100%で物理メモリも余裕が無い。
開放しようと動作を試行するがガベコレスレッドは動けない。
531 ：仕様書無しさん：2005/12/22(木) 10:36:36
センター街に座り込んでるDQNいるだろ？
ああいう連中は片付けろといってもそれが出来ない。
整理整頓、清掃、何も出来ない。
先天的に脳に障害があるとしか思えないが、人手不足のこの業界では、
そんな連中でも現場に放り込むしかない。
そのための言語がJAVA
ああいう連中は片付けろといってもそれが出来ない。
整理整頓、清掃、何も出来ない。
先天的に脳に障害があるとしか思えないが、人手不足のこの業界では、
そんな連中でも現場に放り込むしかない。
そのための言語がJAVA
素朴な疑問
JVMはオブジェクトがどこからも参照されなくなったとどうやって判断してるの？
もしかして、オブジェクトが何千何万と増えたらその監視のための負荷が上がるの？
JVMはオブジェクトがどこからも参照されなくなったとどうやって判断してるの？
もしかして、オブジェクトが何千何万と増えたらその監視のための負荷が上がるの？
533 ：仕様書無しさん：2005/12/22(木) 10:40:46
どこからも参照されなくなったらの仕様がまたいいかげんだなw
オブジェクト全般をスキャンしないと参照のリンクを確認できないよな
馬鹿のための馬鹿言語
オブジェクト全般をスキャンしないと参照のリンクを確認できないよな
馬鹿のための馬鹿言語
534 ：仕様書無しさん：2005/12/22(木) 10:43:15
バカでも使えるIDEを提供してバカが集まり厨だらけになったのがVB
バカでも安全な機能を提供してバカが集まり厨だらけになったのがJAVA
バカでも安全な機能を提供してバカが集まり厨だらけになったのがJAVA
535 ：仕様書無しさん：2005/12/22(木) 10:46:09
Java厨とVMの関係って
ごみを路上に放り投げる馬鹿が100人いて一人でごみ掃除するかわいそうなVM
ごみを路上に放り投げる馬鹿が100人いて一人でごみ掃除するかわいそうなVM
536 ：仕様書無しさん：2005/12/22(木) 10:51:40
S○Nはいくら馬鹿でも少しはVMの事気遣ってくれると思ってた。
しかし現実の馬鹿はデリカシーのかけらもなくやりたい放題で
パフォーマンスが出なかった。でいいかな。
しかし現実の馬鹿はデリカシーのかけらもなくやりたい放題で
パフォーマンスが出なかった。でいいかな。
最近はEclipseというバカでも使えるIDEまで出てきてバカにターボがかかってます。
538 ：仕様書無しさん：2005/12/22(木) 11:08:06
早くJava厨の長文な反論がみたい
現実世界とPCのメモリの中の区別も付かなくなったか。
そろそろ死んだ方がいいんじゃないか?
ついでに言えば、今のVMのガベコレ方式は使い捨てされるようなオブジェクトを
解放するのに時間はくわねえよ。
少しは勉強しろよ。
そろそろ死んだ方がいいんじゃないか?
ついでに言えば、今のVMのガベコレ方式は使い捨てされるようなオブジェクトを
解放するのに時間はくわねえよ。
少しは勉強しろよ。
540 ：仕様書無しさん：2005/12/22(木) 11:45:58
はー昔のガベコレはやっぱり無駄だったんだな
つうかそんなに基本仕様を大幅に変更するほど初期仕様は
いいかげんだったのかw
つうかそんなに基本仕様を大幅に変更するほど初期仕様は
いいかげんだったのかw
541 ：仕様書無しさん：2005/12/22(木) 11:49:10
>>539
今ってどれよ?VMのバージョンのいくつからだよ
今ってどれよ?VMのバージョンのいくつからだよ
そんな仕様にも関わらずPentium 100MHz辺りで使わせようとしたSunは稀代の詐欺師。
543 ：仕様書無しさん：2005/12/22(木) 11:52:24
騙された奴はバカ
それでアプレットと称してブラウザの上でぐりんぐりんと絵を動かして、
ブラウザがOSになるとかほざいてたらしいよ。
ブラウザがOSになるとかほざいてたらしいよ。
つうか、アプレット程度の小さいソフトが前提だったんだろう。
常時連続稼動して何千何万というオブジェクトを扱うことなんて想定外だったのでは。
常時連続稼動して何千何万というオブジェクトを扱うことなんて想定外だったのでは。
546 ：仕様書無しさん：2005/12/22(木) 12:19:56
おまいら全員が馬鹿って事に早く気付け
馬鹿が馬鹿に馬鹿と言ってるだけ。
かわいそすぎる。。。
馬鹿が馬鹿に馬鹿と言ってるだけ。
かわいそすぎる。。。
バカと言う奴がバカ。
548 ：仕様書無しさん：2005/12/22(木) 12:27:53
子供の喧嘩みたいだなw
549 ：仕様書無しさん：2005/12/22(木) 12:28:29
Javaは民主党
by 中村正三郎
by 中村正三郎
最初に馬鹿と言ったC厨が一番バカ。バカッ
普通アプリって巨大化するよな？
スマートなメモリ解放手段使っていたら結局パフォーマンスが
落ちる一方って事？
漏れの知ってる限りJavaって大規模な開発に使われるはずなんだけど・・・。
スマートなメモリ解放手段使っていたら結局パフォーマンスが
落ちる一方って事？
漏れの知ってる限りJavaって大規模な開発に使われるはずなんだけど・・・。
ＣＯＢＯＬなら落ちません。
553 ：仕様書無しさん：2005/12/22(木) 12:47:47
C厨とJava厨仲良くしろよ。
554 ：仕様書無しさん：2005/12/22(木) 14:10:45
SUN of a bitch !!
555 ：青葉台：2005/12/22(木) 17:59:28
ｇｇｇｇ
556 ：仕様書無しさん：2005/12/22(木) 18:24:46
Eclipseが重くてけっきよく秀丸
557 ：仕様書無しさん：2005/12/22(木) 18:34:55
統合開発環境ってどれもそうだね。
PCスペック上がっても、最上位スペックに合わせて作ったようなコード補完とか入れまくられるから、結局重い。
PCスペック上がっても、最上位スペックに合わせて作ったようなコード補完とか入れまくられるから、結局重い。
558 ：仕様書無しさん：2005/12/22(木) 18:40:52
おいこら。
お前ら、今月号のＣマガジン読んだか？
GCJの記事がある。よく読め。
sunのJVMでもGCJのネィティブでもg++のネィティブでも大差ないぞ。
お前ら、今月号のＣマガジン読んだか？
GCJの記事がある。よく読め。
sunのJVMでもGCJのネィティブでもg++のネィティブでも大差ないぞ。
GCJのCって何？
>>421
> あの・・・制御系でもない限り、Cで組んでもある程度オブジェクト指向の下地は付いてますよ。
関数ポインタ使った程度でオブジェクト指向っていってもな。
『アジャイルソフトウェア開発の奥義』にかいてある「オブジェクト指向の設計原則」
をろくに守ることができないだろ
> あの・・・制御系でもない限り、Cで組んでもある程度オブジェクト指向の下地は付いてますよ。
関数ポインタ使った程度でオブジェクト指向っていってもな。
『アジャイルソフトウェア開発の奥義』にかいてある「オブジェクト指向の設計原則」
をろくに守ることができないだろ
>>497
速度
StringBuilder#append() > StringBuffer#append() > +=
>>498
+はいいんだ。若干遅いが、
だが+=はもっと遅い。何度も+=するんだったらappend()使えってこった
速度
StringBuilder#append() > StringBuffer#append() > +=
>>498
+はいいんだ。若干遅いが、
だが+=はもっと遅い。何度も+=するんだったらappend()使えってこった
562 ：仕様書無しさん：2005/12/22(木) 19:00:35
降臨かっ
>>520
> ガベコレとかそうだよな。
> あれがどういうタイミングで開放するか意識して気を配ってコーディング
> するくらいなら、てめえで明示的にfreeなりdeleteするほうがシンプルで簡単。
それが落とし穴だな。
プログラムが複雑化するとfreeやdeleteをどこで使うかのタイミングを
掴むのが難しくなる。
プログラムを拡張するたびにdeleteの実装を変更するなんて
大変なこったな。
やってる作業は人間的でないしその分開発コストが無駄に増大する。
> ガベコレとかそうだよな。
> あれがどういうタイミングで開放するか意識して気を配ってコーディング
> するくらいなら、てめえで明示的にfreeなりdeleteするほうがシンプルで簡単。
それが落とし穴だな。
プログラムが複雑化するとfreeやdeleteをどこで使うかのタイミングを
掴むのが難しくなる。
プログラムを拡張するたびにdeleteの実装を変更するなんて
大変なこったな。
やってる作業は人間的でないしその分開発コストが無駄に増大する。
>>556
つ[DDR SDRAM DIMM PC3200 CL2 2GB] * 2枚 デュアル
つ[DDR SDRAM DIMM PC3200 CL2 2GB] * 2枚 デュアル
569 ：仕様書無しさん：2005/12/22(木) 19:10:21
ひとりでごくろうさん
Cは馬鹿を泣かすためにある言語。
コンパイラが変わって動かなかったプログラムを
C言語注は今日も泣きながら必死に修正している毎日。
コンパイラが変わって動かなかったプログラムを
C言語注は今日も泣きながら必死に修正している毎日。
ＥｃｌｉｐｓｅってIBM製なのか？
元々はIBM製だろうけど
元々はIBM製だろうけど
C厨＝幼稚園生
C言語＝ウィルス言語
C言語厨は中国人
C言語厨は原始的
576 ：仕様書無しさん：2005/12/22(木) 19:15:25
>>508
> いやいや、職業プログラマの言う「良いパソコン」って意味だよ。
> ユーザやゲーマーの言う良いパソコンじゃなくて。
> 良いパソコン＝自分の作ったプログラムが快適に動くパソコン
> 事務処理の客先では400-800MHzぐらいのが動いている事もあるだろう？
そんな古いマシンけっ飛ばして破壊してしまえ。
脳みそが腐ったしわがれたお爺さんには理解できないだろうが
今は3GHzが当たり前の時代なんだよ。
っていうかファイルサーバやルータとして使えよw
> いやいや、職業プログラマの言う「良いパソコン」って意味だよ。
> ユーザやゲーマーの言う良いパソコンじゃなくて。
> 良いパソコン＝自分の作ったプログラムが快適に動くパソコン
> 事務処理の客先では400-800MHzぐらいのが動いている事もあるだろう？
そんな古いマシンけっ飛ばして破壊してしまえ。
脳みそが腐ったしわがれたお爺さんには理解できないだろうが
今は3GHzが当たり前の時代なんだよ。
っていうかファイルサーバやルータとして使えよw
プリプロセッサの代替はVelocityで補いましょう
579 ：仕様書無しさん：2005/12/22(木) 19:39:03
まーバブル世代と思われるC言語厨の書き込みが目立つスレですねぇー
まぁ、メモリを節約することだけに全忠誠心をつぎ込んで
血吐きながら20世紀を生きてきたのに
その組み込みの仕事までメモリ管理ドンブリ勘定のJavaに獲られて
「いや、Cじゃないとメモリの最適化が・・・」
「メモリなんて足りなきゃ増やしゃいいだけだから」
と切り捨てられてるのを見てると可哀想にはなってくる。
血吐きながら20世紀を生きてきたのに
その組み込みの仕事までメモリ管理ドンブリ勘定のJavaに獲られて
「いや、Cじゃないとメモリの最適化が・・・」
「メモリなんて足りなきゃ増やしゃいいだけだから」
と切り捨てられてるのを見てると可哀想にはなってくる。
ﾊｲﾊｲ、ﾄﾞﾝﾄﾞﾝｷﾘｽﾃﾙﾖｰ
582 ：仕様書無しさん：2005/12/22(木) 20:23:40
>576
おいおい、お客様のマシンを捨ててしまう訳にはいかないだろう？
それとも客に「私のプログラムは遅いので、3GHマシンでないと動きません」って言うのかな？
おいおい、お客様のマシンを捨ててしまう訳にはいかないだろう？
それとも客に「私のプログラムは遅いので、3GHマシンでないと動きません」って言うのかな？
オブラートに包んで言うんじゃね。
584 ：仕様書無しさん：2005/12/22(木) 20:49:46
実際、ガーベージコレクションは早くなった。
IBMの技術者が入ってきたあたりから、かなり良くなっている。
ガーベージコレクションと言ってもすでに簡単な処理ではなくなっている。
世代管理とかパラレル実行とか、一応資料も出ているので調べてみると面白い。
ただ重要なのは「そんな事全然知らなくても恩恵にあずかれる」って事だよ。
あとC使いは馬鹿ではない、頭がかたいだけ。
Java使いは、ここに来ているJava使いのほとんどがC使いだったろうから、C使いが悪口言っても無駄。
IBMの技術者が入ってきたあたりから、かなり良くなっている。
ガーベージコレクションと言ってもすでに簡単な処理ではなくなっている。
世代管理とかパラレル実行とか、一応資料も出ているので調べてみると面白い。
ただ重要なのは「そんな事全然知らなくても恩恵にあずかれる」って事だよ。
あとC使いは馬鹿ではない、頭がかたいだけ。
Java使いは、ここに来ているJava使いのほとんどがC使いだったろうから、C使いが悪口言っても無駄。
そりゃ現場を知らぬからいえることだな。
っていうか、パッケージ売りならともかく
新品のPCくらい買えないような客としか取引できないのか？
藻前のソフトはPC1台以下の価値しかないってことかｗ
新品のPCくらい買えないような客としか取引できないのか？
藻前のソフトはPC1台以下の価値しかないってことかｗ
減価償却
>>582
「可動部分は消耗品なんで止まって困るシステムでは使いまわしは避けた方がいいですよ。」
って言ってる。
消耗品のホットスワップとかまで考えてるような所なら
そもそもそんなケチ臭いこと聞かれることすら無いし。
そもそもわざわざ遅いPC買うことってないな。
別に大して値段変わらんし。
悪環境化で観測装置に繋ぐとかでもないと。
「可動部分は消耗品なんで止まって困るシステムでは使いまわしは避けた方がいいですよ。」
って言ってる。
消耗品のホットスワップとかまで考えてるような所なら
そもそもそんなケチ臭いこと聞かれることすら無いし。
そもそもわざわざ遅いPC買うことってないな。
別に大して値段変わらんし。
悪環境化で観測装置に繋ぐとかでもないと。
589 ：仕様書無しさん：2005/12/22(木) 22:41:26
i815時代までは実用にならなかったって告白が書き込まれているのは
こちらのスレですかな？
こちらのスレですかな？
うち未だに監視用端末Celeron 500MHzだお
Applet起動するのに1分以上かかるお
Applet起動するのに1分以上かかるお
591 ：仕様書無しさん：2005/12/22(木) 23:41:46
Javaは遅い。実際そーなんだから仕方が無い。
だから悪いとは思わん。
実行速度が速いだけでもてはやされる時代でもなかろうに。
だから悪いとは思わん。
実行速度が速いだけでもてはやされる時代でもなかろうに。
Webで言うところの3秒ルールみたいなのはあるだろ
クライアントのリソース使う以上は一瞬で遷移してもらわねば
クライアントのリソース使う以上は一瞬で遷移してもらわねば
このスレ、５割くらいは嘘。知ったかぶりが笑える。
594 ：仕様書無しさん：2005/12/23(金) 00:03:35
595 ：仕様書無しさん：2005/12/23(金) 00:15:42
Javaが重いから、規約に従ったコードに書き直せだぁ？
おまいの設計したＤＢの同じレコードにアクセスするコストに較べたら雲泥の差だろ
おまいの設計したＤＢの同じレコードにアクセスするコストに較べたら雲泥の差だろ
596 ：仕様書無しさん：2005/12/23(金) 00:23:35
規約に従えばオブジェクト指向でつか？
規約は、規約マニアが趣味で守るものでは無いのでつか？
ソースが綺麗とは規約を守ることを言うのでつか？僕は、設計が綺麗な
方がＨＡＰＰＹになれると思いまつ。
規約を重視する人に優秀な人はいなかったでつ。
規約は、規約マニアが趣味で守るものでは無いのでつか？
ソースが綺麗とは規約を守ることを言うのでつか？僕は、設計が綺麗な
方がＨＡＰＰＹになれると思いまつ。
規約を重視する人に優秀な人はいなかったでつ。
たまたま、お前が会ってきた奴らの中に
優秀な奴がいなかっただけ。
設計が綺麗だとソースも綺麗になるだろうが。
お前が知ってる最低レベルの小さな世界だけを見て全てと思うなよ。
大体、全員が優秀な奴らだったら
規約そのものが出来たりしねぇんだよ。
お前らみたいな奴がいるから
最低限これだけは守ってねって言う
規約みたいなもんが出来るんだろうが。
ちょっとかじっただけの偽装派遣はさっさと転職しろよ。
優秀な奴がいなかっただけ。
設計が綺麗だとソースも綺麗になるだろうが。
お前が知ってる最低レベルの小さな世界だけを見て全てと思うなよ。
大体、全員が優秀な奴らだったら
規約そのものが出来たりしねぇんだよ。
お前らみたいな奴がいるから
最低限これだけは守ってねって言う
規約みたいなもんが出来るんだろうが。
ちょっとかじっただけの偽装派遣はさっさと転職しろよ。
linuxのソースは汚いよな。設計も汚いかどうか知らないが。
599 ：仕様書無しさん：2005/12/23(金) 09:11:30
全部
おうろなミンチー が書いたw
おうろなミンチー が書いたw
600 ：仕様書無しさん：2005/12/23(金) 11:09:38
JITに落ちた糞JAVAコードってJNI経由でVMとやりとりするのか?
もしそうだとしたらJITも糞糞糞だなw どうあがいてもオーバヘッドと無駄の塊
もしそうだとしたらJITも糞糞糞だなw どうあがいてもオーバヘッドと無駄の塊
602 ：仕様書無しさん：2005/12/23(金) 11:40:34
603 ：仕様書無しさん：2005/12/23(金) 12:04:44
604 ：仕様書無しさん：2005/12/23(金) 12:34:27
C厨ってどうしようもねえなぁｗｗｗｗ
どうせバブル入社のボンクラだろｗｗｗｗ
どうせバブル入社のボンクラだろｗｗｗｗ
着メロにEarth Wind & Fireとか設定してそう。。。。
606 ：仕様書無しさん：2005/12/23(金) 12:49:02
似たような思想だろ。
動的にバイトコードをコンパイルして実行させるか
動的におまいらを動員して厨プログラムくませるかの違いでしかない。
動的にバイトコードをコンパイルして実行させるか
動的におまいらを動員して厨プログラムくませるかの違いでしかない。
>>600は知らず知らずのうちにJavaだけでなく.NETやPerl6をも批判している
ことをわかってないようです
ことをわかってないようです
>>582
実際、マイクロソフトはそうやって儲けているわけだが。
お前はマイクロソフトが馬鹿な客をどれだけ切り捨てているかわかってないな。
次期Windwos Longhornではますます多くの客を切り捨てるのだが、
それと同時に古い客に新しいマシンを買わせるように促している。
古いマシンを使っているのは時代遅れだという認識を持たせるのだ。
マイクロソフトがLonghornを売り出すことを利用して
デスクトップJavaにも優位に働かせることもできるというわけだ。
マイクロソフトがWindowsを出したおかげでメモリが馬鹿売れする、PC
が馬鹿売れする、ビデオカードが馬鹿売れするという話はよくあることだろう。
新しいマシンを買わせる戦略と同時にリテラシを高める効果もある。
実際、マイクロソフトはそうやって儲けているわけだが。
お前はマイクロソフトが馬鹿な客をどれだけ切り捨てているかわかってないな。
次期Windwos Longhornではますます多くの客を切り捨てるのだが、
それと同時に古い客に新しいマシンを買わせるように促している。
古いマシンを使っているのは時代遅れだという認識を持たせるのだ。
マイクロソフトがLonghornを売り出すことを利用して
デスクトップJavaにも優位に働かせることもできるというわけだ。
マイクロソフトがWindowsを出したおかげでメモリが馬鹿売れする、PC
が馬鹿売れする、ビデオカードが馬鹿売れするという話はよくあることだろう。
新しいマシンを買わせる戦略と同時にリテラシを高める効果もある。
610 ：仕様書無しさん：2005/12/23(金) 14:23:45
>>586
Javaを使う顧客の大半はおまいが想像するような貧乏個人エンドユーザではなく
金持ってる教育機関や金融系企業なので高価なPCとサーバを持ってる金持ち顧客なので
ぼろいＰＣのことなど考えなくてもよいのさ。
無料の個人用ソフト人気が高まってパッケージソフトウェアの
売り上げが低迷している中で
いまどき、パッケージ開発で金儲けしようと考えること自体が時代遅れで愚かだよ。
今パッケージは無料で配布してその分の負担は他のところで補うというのが
新しいビジネスモデルだ。
携帯電話だって二年おきに買い換えるし
PCも三年おきに買い換えるものだ。
あの売り上げトップのDELLコンピュータですら、PCは二年おきに
買い換えることを目安にしろと言っている。
Javaを使う顧客の大半はおまいが想像するような貧乏個人エンドユーザではなく
金持ってる教育機関や金融系企業なので高価なPCとサーバを持ってる金持ち顧客なので
ぼろいＰＣのことなど考えなくてもよいのさ。
無料の個人用ソフト人気が高まってパッケージソフトウェアの
売り上げが低迷している中で
いまどき、パッケージ開発で金儲けしようと考えること自体が時代遅れで愚かだよ。
今パッケージは無料で配布してその分の負担は他のところで補うというのが
新しいビジネスモデルだ。
携帯電話だって二年おきに買い換えるし
PCも三年おきに買い換えるものだ。
あの売り上げトップのDELLコンピュータですら、PCは二年おきに
買い換えることを目安にしろと言っている。
会社や教育機関だからこそ、３，４年前のPCが現役なわけで。。。
612 ：仕様書無しさん：2005/12/23(金) 14:59:54
長文の説明w
>>610
おまえ金融の現場見たことないだろ？
おまえ金融の現場見たことないだろ？
そこでFastCGI
615 ：仕様書無しさん：2005/12/23(金) 17:00:27
>>610
Java は遅いけどＰＣが早いという事でよろしいですか？
ＰＣが早ければ、CもLispもPerlもC#も・・・はやくなりますが・・・。
Java は遅い！でもＰＣが早いので問題にならないって事でいいですか？
3年も経てばＰＣだけじゃなくてJavaのバージョンもOSも変わりますね。
全ての金融機関が数年のサイクルでシステムを入れ替える事は無いと
思うんですけど。脳内さんですか？
Java は遅いけどＰＣが早いという事でよろしいですか？
ＰＣが早ければ、CもLispもPerlもC#も・・・はやくなりますが・・・。
Java は遅い！でもＰＣが早いので問題にならないって事でいいですか？
3年も経てばＰＣだけじゃなくてJavaのバージョンもOSも変わりますね。
全ての金融機関が数年のサイクルでシステムを入れ替える事は無いと
思うんですけど。脳内さんですか？
今ふと思ったのだが、C/C++で工数をかけて丁寧に高品質な金融機関向けの
システム構築を出来たら金になるかもな。
特にオンライントレード関係のところ。基本はなるべく共通で、必要に応じて
追加やカスタマイズを施すような形でどうだろうか。
システム構築を出来たら金になるかもな。
特にオンライントレード関係のところ。基本はなるべく共通で、必要に応じて
追加やカスタマイズを施すような形でどうだろうか。
景気回復のきざしが見えてきた昨今、もう開発が低コストですむからって
時代は終わりつつあると思う。元来は高品質なものを好む国民性だ。
TeraTermにしろBecky!にしろ世界に通用する和製ソフトは、シンプルで
安定し高速コンパクトなモノ。製造業の製品に通じるものがある。
大規模開発でも、頭数そろえてﾄﾞｶﾀを大量投入し、低品質コードを
短納期で納めるような形態は日本人には向かないのではないか。
時代は終わりつつあると思う。元来は高品質なものを好む国民性だ。
TeraTermにしろBecky!にしろ世界に通用する和製ソフトは、シンプルで
安定し高速コンパクトなモノ。製造業の製品に通じるものがある。
大規模開発でも、頭数そろえてﾄﾞｶﾀを大量投入し、低品質コードを
短納期で納めるような形態は日本人には向かないのではないか。
エンドレスプロジェクトをアジャイル開発と正当化する馬鹿は氏んでください
619 ：仕様書無しさん：2005/12/23(金) 17:17:28
さあ、JavaとVBを捨てよう。
620 ：仕様書無しさん：2005/12/23(金) 17:46:42
>>616
Javaで、COBOL風、C風味のコピペプログラムをバグバクでつくるのが金になるんだよ。
発注元の素人がみても、なんだこのプログラムはJavaか？と言われる程の糞プログラム
作って、さて次は改良しましょか？人ふやせますぅ？と言ってる馬鹿営業がいる。
なんか、発注元からプログラムが長いとかクレームきてると聞いたんで、１０分１の
コードでプログラム作ったら、怒られたよ。弊社のプログラムに合わせろってさ。
だって、そのプログラムにクレーム来てんだろが、ｺﾞﾗｧ
Javaで、COBOL風、C風味のコピペプログラムをバグバクでつくるのが金になるんだよ。
発注元の素人がみても、なんだこのプログラムはJavaか？と言われる程の糞プログラム
作って、さて次は改良しましょか？人ふやせますぅ？と言ってる馬鹿営業がいる。
なんか、発注元からプログラムが長いとかクレームきてると聞いたんで、１０分１の
コードでプログラム作ったら、怒られたよ。弊社のプログラムに合わせろってさ。
だって、そのプログラムにクレーム来てんだろが、ｺﾞﾗｧ
金融系はリプレースが長いからな
むしろすぐに拡張・改造が必要になるほうがSIerには喜ばれる。
ソフト屋サンとユーザーは、バグが少なく高品質で手離れがよく
運用保守に手間がかからないものが嬉しいだろうけどさ。
むしろすぐに拡張・改造が必要になるほうがSIerには喜ばれる。
ソフト屋サンとユーザーは、バグが少なく高品質で手離れがよく
運用保守に手間がかからないものが嬉しいだろうけどさ。
622 ：仕様書無しさん：2005/12/23(金) 18:10:38
>>616
鋭いねー。
そうそう、確かに最近言語が増えてきてC/C++言語プログラマーが枯渇している
うちの会社、JavaとC++のチーム歩けど、Javaチームは年齢のバランスが良いんだ
C/C++チームは、おっさん or 若すぎしかおらん。Javaが流行った時代に、
Cプログラマが育たなかったと思われる。
うちの会社プログラマー雇ってるけど、Javaプログラマーの方が安いよ。
C/C++プログラムでやろうとしていることってJavaでできない事なわけで、
難易度が高いんよね。だから、C/C++の方が儲かるぜ。
業務系、金融系でJavaなら使い捨てできるほど人材がいるかもしれないが
リアルタイムシステム（全てがオーダーメイド）のプログラマーは、
扱いが違うぜ。
鋭いねー。
そうそう、確かに最近言語が増えてきてC/C++言語プログラマーが枯渇している
うちの会社、JavaとC++のチーム歩けど、Javaチームは年齢のバランスが良いんだ
C/C++チームは、おっさん or 若すぎしかおらん。Javaが流行った時代に、
Cプログラマが育たなかったと思われる。
うちの会社プログラマー雇ってるけど、Javaプログラマーの方が安いよ。
C/C++プログラムでやろうとしていることってJavaでできない事なわけで、
難易度が高いんよね。だから、C/C++の方が儲かるぜ。
業務系、金融系でJavaなら使い捨てできるほど人材がいるかもしれないが
リアルタイムシステム（全てがオーダーメイド）のプログラマーは、
扱いが違うぜ。
金融系のシステムはあまりパフォーマンスを要求されてこなかったのだが、
近年のインターネットの普及で処理能力を問われるようになってきつつある。
実際、昨年は遅延やダウンなどトラブルを頻発させたところも多い。
今こそ、パフォーマンスも安定性も重視した、高品質システムが求められて
いると思うんだ。コボルのおっさんやJavaドカタの人海戦術で金になった時代は
終わったよ。
近年のインターネットの普及で処理能力を問われるようになってきつつある。
実際、昨年は遅延やダウンなどトラブルを頻発させたところも多い。
今こそ、パフォーマンスも安定性も重視した、高品質システムが求められて
いると思うんだ。コボルのおっさんやJavaドカタの人海戦術で金になった時代は
終わったよ。
625 ：仕様書無しさん：2005/12/23(金) 18:19:04
さあ、C++で既存システムを書き換えよう。
コンパイラはもちろんIntel C++だ。VisualなんとかやGCCのような安物を使ってはいけない。
コンパイラはもちろんIntel C++だ。VisualなんとかやGCCのような安物を使ってはいけない。
Javaっていってもさ、結局はメモリ上のインスタンスの寿命とか、
スレッド間のスケジューリングとか分散オブジェクト設計時の注意
事項とか、そんなことは知っていないとまともな企業システムの設計
できないはずなんだけどさ、
何で皆そういうここと知らないんだよ…orz
スレッド間のスケジューリングとか分散オブジェクト設計時の注意
事項とか、そんなことは知っていないとまともな企業システムの設計
できないはずなんだけどさ、
何で皆そういうここと知らないんだよ…orz
>>626
誰に言ってるの？
誰に言ってるの？
>>627
向かいの席に座ってるおっさんｗ
向かいの席に座ってるおっさんｗ
629 ：仕様書無しさん：2005/12/23(金) 18:27:02
ｗ
631 ：仕様書無しさん：2005/12/23(金) 20:02:19
632 ：仕様書無しさん：2005/12/23(金) 20:05:43
>>624
詭弁術に実に必死だな。
そう思うならC++で動くServletやEJBを作ってから
いってくれ。ちゃんとどんなサーバOSでも動かせるようにな。
C++を使うのはOSネイティブだから魅力があると思っているようだが、
ぜひとも数々のサーバOSを切り替えても問題なく動くC++版Servletフレームワークを
作ってくれてみたまえ。
ﾄﾞｶﾀとかいってるあたり、
ただJavaが気に入らないだけってことは図星のようだな。
詭弁術に実に必死だな。
そう思うならC++で動くServletやEJBを作ってから
いってくれ。ちゃんとどんなサーバOSでも動かせるようにな。
C++を使うのはOSネイティブだから魅力があると思っているようだが、
ぜひとも数々のサーバOSを切り替えても問題なく動くC++版Servletフレームワークを
作ってくれてみたまえ。
ﾄﾞｶﾀとかいってるあたり、
ただJavaが気に入らないだけってことは図星のようだな。
>>624
システムのダウンをなにもかもJavaのせいにしているようだが
実際の所、すべてのシステムにJavaを使っているとは
限らないわけだが。COBOLをそのまま使っているところもあれば
Fortran + COBOLの組み合わせで動いているものもあるわけだ。
そこでC++に何もかも置き換えたらもっと酷いことになりかねないな。
システムのダウンをなにもかもJavaのせいにしているようだが
実際の所、すべてのシステムにJavaを使っているとは
限らないわけだが。COBOLをそのまま使っているところもあれば
Fortran + COBOLの組み合わせで動いているものもあるわけだ。
そこでC++に何もかも置き換えたらもっと酷いことになりかねないな。
634 ：仕様書無しさん：2005/12/23(金) 20:12:58
Javaが重いというか
今頃になってそういうこと連呼するC言語厨がかなり重たい。
5年前の化石化した人間か？
今頃になってそういうこと連呼するC言語厨がかなり重たい。
5年前の化石化した人間か？
635 ：仕様書無しさん：2005/12/23(金) 20:14:59
>>617
> TeraTermにしろBecky!にしろ世界に通用する和製ソフトは、シンプルで
ﾌﾟｯ いつの時代の人間だ(ﾜﾗ
バブル世代じゃあるまいしPuttyとThunderbirdの時代にそんな
時代遅れなソフト紹介する奴はモグリだぞw
> TeraTermにしろBecky!にしろ世界に通用する和製ソフトは、シンプルで
ﾌﾟｯ いつの時代の人間だ(ﾜﾗ
バブル世代じゃあるまいしPuttyとThunderbirdの時代にそんな
時代遅れなソフト紹介する奴はモグリだぞw
636 ：仕様書無しさん：2005/12/23(金) 20:20:42
>>615
Javaはアップデートするたびに高速化しているし
C#やPerlとJava、どっちが速いかというと
プログラムの作り方によって変わってくるのでこっちの言語が
常に速い、常に遅い、とは言い切れないんだなこれが。
Perlだけで金融システムを作るのは
今のところ現実的ではないな。型に甘い言語である以上、
デバッグしづらくPerlはソフトウェアの信頼性を落とす。
C#はいまサーバサイドでは実績も信頼も積んでいない。
Javaサーバに使われているTomcatも
アップデートするたびに高速化している。
Tomcatを再起動しなくても
それにシステムを入れ替えることができる仕組みも
ちゃんと揃っている。
Javaは比較的そういうことが容易だ。
Tomcatのwebappsディレクトリに新しいWARファイルを
コピーするのも、Tomcatを起動せずに
実行することができる。これをホットデプロイと呼ぶ。
Javaはアップデートするたびに高速化しているし
C#やPerlとJava、どっちが速いかというと
プログラムの作り方によって変わってくるのでこっちの言語が
常に速い、常に遅い、とは言い切れないんだなこれが。
Perlだけで金融システムを作るのは
今のところ現実的ではないな。型に甘い言語である以上、
デバッグしづらくPerlはソフトウェアの信頼性を落とす。
C#はいまサーバサイドでは実績も信頼も積んでいない。
Javaサーバに使われているTomcatも
アップデートするたびに高速化している。
Tomcatを再起動しなくても
それにシステムを入れ替えることができる仕組みも
ちゃんと揃っている。
Javaは比較的そういうことが容易だ。
Tomcatのwebappsディレクトリに新しいWARファイルを
コピーするのも、Tomcatを起動せずに
実行することができる。これをホットデプロイと呼ぶ。
ＥＪＢって実用になるのか？
639 ：仕様書無しさん：2005/12/23(金) 21:54:31
JavaがCよりも速いというか
今頃になってもそういうこと連呼するJAVA厨がかなりうっとおしい。
論理思考もできない化石化した人間か？
今頃になってもそういうこと連呼するJAVA厨がかなりうっとおしい。
論理思考もできない化石化した人間か？
642 ：仕様書無しさん：2005/12/23(金) 23:38:16
えーっと、C++で書いてあるWindowsどんどん重くしてPC進化させてくれてるから
糞重いJavaもそのおこぼれでどーにか使えるようになってきたってことでいい？ｗ
糞重いJavaもそのおこぼれでどーにか使えるようになってきたってことでいい？ｗ
そうか？OSは1GHz超えた辺りで飽和したと思うぞ。
644 ：仕様書無しさん：2005/12/24(土) 00:50:21
このすれ読み直せ
>>644
いやHotSpotの出始めはSUNだって速いって言ってた。
いやHotSpotの出始めはSUNだって速いって言ってた。
647 ：仕様書無しさん：2005/12/24(土) 00:59:29
>>642
昔のソフトはパフォーマンスがかなり重視されたが、最近はＯＳからして
糞重い。これを進化というのかどうかはわからんが・・・。
ハードウェアのパワーアップによって、ソフトウェアのパフォーマンスの
重要性が小さくなってきたのは確かだなー。
ただ、未だにパフォーマンスが要求される分野もある訳で、そういうところ
ではJavaは眼中にすらないな。
最近のプログラマーは、メモリ使用量、実行ファイルのサイズ、パフォーマンス
に無頓着・・・、納期、開発効率を重視する時代になったという事だろう。
昔のソフトはパフォーマンスがかなり重視されたが、最近はＯＳからして
糞重い。これを進化というのかどうかはわからんが・・・。
ハードウェアのパワーアップによって、ソフトウェアのパフォーマンスの
重要性が小さくなってきたのは確かだなー。
ただ、未だにパフォーマンスが要求される分野もある訳で、そういうところ
ではJavaは眼中にすらないな。
最近のプログラマーは、メモリ使用量、実行ファイルのサイズ、パフォーマンス
に無頓着・・・、納期、開発効率を重視する時代になったという事だろう。
今のマシンだとDOSは糞はやいらしいな
タイマなしでCPU負荷で時間調節してるゲームは一瞬でゲームオーバー
タイマなしでCPU負荷で時間調節してるゲームは一瞬でゲームオーバー
納期、開発効率を重視とか調子こいた言い訳だけうまいよな
JAVA房ってさ。その割に自分達が使ってるｵｰﾌﾟﾝ等のミドルウェア
簡単なバグすら直せないんだもんな。お前らって頭ついてるだけだよね？
JAVA房ってさ。その割に自分達が使ってるｵｰﾌﾟﾝ等のミドルウェア
簡単なバグすら直せないんだもんな。お前らって頭ついてるだけだよね？
Javaって本当に開発効率高いか？
ツールとかライブラリの種類が多すぎてバージョンアップも多いし、
プロジェクトの度に覚えることが多くて、所謂枯れた状態になかなかならないと思う。
ツールとかライブラリの種類が多すぎてバージョンアップも多いし、
プロジェクトの度に覚えることが多くて、所謂枯れた状態になかなかならないと思う。
651 ：仕様書無しさん：2005/12/24(土) 01:07:01
653 ：仕様書無しさん：2005/12/24(土) 01:11:01
Javaで作られた、為替証拠金取引のソフトがあるけど、すごい。
Javaアプリであそこまで作れるんだ、って驚いた。
今はデモ（バーチャル取引）で遊んでるよ。
Javaアプリであそこまで作れるんだ、って驚いた。
今はデモ（バーチャル取引）で遊んでるよ。
654 ：仕様書無しさん：2005/12/24(土) 01:12:54
俺、C/C++もやるが、Javaは開発効率良い。
OS固有のややこしい話とかほぼ無視で、Javaの閉ざされた世界だけを
知っていれば良い。ツールもフリーで入手できるから、コミュニティーが
育ちやすい。情報も入手簡単。
客には、Javaではちょっと無理です。。。。という言い訳が立つ。
C/C++だと何でもできると思われがちでしんどいし、OS変わると開発環境
が様変わりするのもしんどい。VisualStudioはUnixは動かんしな。
OS固有のややこしい話とかほぼ無視で、Javaの閉ざされた世界だけを
知っていれば良い。ツールもフリーで入手できるから、コミュニティーが
育ちやすい。情報も入手簡単。
客には、Javaではちょっと無理です。。。。という言い訳が立つ。
C/C++だと何でもできると思われがちでしんどいし、OS変わると開発環境
が様変わりするのもしんどい。VisualStudioはUnixは動かんしな。
655 ：仕様書無しさん：2005/12/24(土) 01:15:25
棒ランドとかウォーリャー使えば？
というかですね、VSが凄すぎて他を今更触りたくないというのはあると思うのですよ。
VS級のクロスコンパイラがあるなら、私もそれ使いたい。
VS級のクロスコンパイラがあるなら、私もそれ使いたい。
EmacsとIntel C++使っとけ
>>654
Javaの仕事が多いという時代に
Javaに閉ざされた世界もなにも
ないわけだが。
今ブログが流行ってるように、
従来のHTMLオンリーでFTPアップロードで
サイト構築よりもブログツールをバリバリ
使ってCMSから直接サイトを更新するほうが
効率が良い。
自動化っていうのはそういうもんだよ。
JavaはC++に自動化ツールをつけたような言語だ。
さらにJavaでは開発効率を高めるために
AntやXDoclet, JUnit, Mavenといった自動化ツールを
積極的に使う機会がある。これらを使わないと
ソフトウェア開発の効率を高めることができない。
Javaの仕事が多いという時代に
Javaに閉ざされた世界もなにも
ないわけだが。
今ブログが流行ってるように、
従来のHTMLオンリーでFTPアップロードで
サイト構築よりもブログツールをバリバリ
使ってCMSから直接サイトを更新するほうが
効率が良い。
自動化っていうのはそういうもんだよ。
JavaはC++に自動化ツールをつけたような言語だ。
さらにJavaでは開発効率を高めるために
AntやXDoclet, JUnit, Mavenといった自動化ツールを
積極的に使う機会がある。これらを使わないと
ソフトウェア開発の効率を高めることができない。
>>650
> Javaって本当に開発効率高いか？
> ツールとかライブラリの種類が多すぎてバージョンアップも多いし、
ライブラリの多さはC/C++と比べたらたいしたことがないよ。
ライブラリを簡単にダウンロード/インストールするにはApache Mavenを使うといい。
有名なものはMaven Repo Searchを使って簡単に検索することができる。
バージョンアップもC/C++のコンパイラの乱立に比べたらたいしたことがない。
0.1バージョン毎の上位互換性(1.4から5.0もO.K.)だけはしっかりと保たれている
からとくに問題は無い。
> プロジェクトの度に覚えることが多くて、所謂枯れた状態になかなかならないと思う。
だからJavaを侮っているととんでもないことになるわけだ。
このすれのC/C++屋がそのことにどれだけ気づいている事やら。
高をくくって酷い目に遭わなければいいのだが。
それからAntやMavenは積極的に使え。Servlet, Struts, EJB, Hibernate, JBoss開発には
必ずXDocletを使うこと。JUnitも使うこと。これらを使いこなさなければeXtreme Programming
による開発効率を高める行為を実践できない。
さらにEclipseを使うともっと開発効率が上がる。
> Javaって本当に開発効率高いか？
> ツールとかライブラリの種類が多すぎてバージョンアップも多いし、
ライブラリの多さはC/C++と比べたらたいしたことがないよ。
ライブラリを簡単にダウンロード/インストールするにはApache Mavenを使うといい。
有名なものはMaven Repo Searchを使って簡単に検索することができる。
バージョンアップもC/C++のコンパイラの乱立に比べたらたいしたことがない。
0.1バージョン毎の上位互換性(1.4から5.0もO.K.)だけはしっかりと保たれている
からとくに問題は無い。
> プロジェクトの度に覚えることが多くて、所謂枯れた状態になかなかならないと思う。
だからJavaを侮っているととんでもないことになるわけだ。
このすれのC/C++屋がそのことにどれだけ気づいている事やら。
高をくくって酷い目に遭わなければいいのだが。
それからAntやMavenは積極的に使え。Servlet, Struts, EJB, Hibernate, JBoss開発には
必ずXDocletを使うこと。JUnitも使うこと。これらを使いこなさなければeXtreme Programming
による開発効率を高める行為を実践できない。
さらにEclipseを使うともっと開発効率が上がる。
VSはコンパイラも確かにすごいがgccを突き放すほど圧倒的というわけでもない。
だがデバッガだけは別。VSのIDEデバッガだけは圧倒的にすごい。
だがデバッガだけは別。VSのIDEデバッガだけは圧倒的にすごい。
664 ：仕様書無しさん：2005/12/24(土) 03:13:27
おまい、燃料電池がどんなものか知っているか？
Eclipseってプラグイン入れるとまた遅くなるんだよな。
ただでさえ遅いのに。。。ネィティブ化出来ないもんかねぇ。。。
ただでさえ遅いのに。。。ネィティブ化出来ないもんかねぇ。。。
とりあえず、このスレを読んでJAVAが重いことだけはわかった。
日本人でJakarta Projectのバグ
修正してるやつってほとんどみたことないぞ
3人は知ってる。（これ会社元同僚だからだが
ほかここ12ヶ月間みたことないぞ。ソースに反映されてないと
思うぞ。勝手修正終わりだろ？そんなDQNしかいねぇんだよ
JAVAには
修正してるやつってほとんどみたことないぞ
3人は知ってる。（これ会社元同僚だからだが
ほかここ12ヶ月間みたことないぞ。ソースに反映されてないと
思うぞ。勝手修正終わりだろ？そんなDQNしかいねぇんだよ
JAVAには
>>664
パワーアップする
パワーアップする
669 ：仕様書無しさん：2005/12/24(土) 05:10:18
そいや、Javaが重いからＰＬ／ＳＱＬで作りましょうと提案してる会社があったなぁ。
なんか、違和感を感じたよ。
なんか、違和感を感じたよ。
コンシューマーゲーム、ネットゲーム作るときの開発言語はC/C++オンリーだ。
javaなんて使わない、むしろ使えない。
これが何を意味するか分かるな？
javaなんて使わない、むしろ使えない。
これが何を意味するか分かるな？
なんつーか、Javaしかやった事ない野郎って妙な原理主義者が多いんだよね。
フレームワーク至上主義というか。>>658-659とか典型。
俺の会社での不毛なやり取り例
「コネクション閉じる箇所の例外処理とか冗長だからひとつのメソッドにまとめましょう」
「駄目だ、全部1メソッドの中で書いておかないとみんな混乱するだろ」
DBUtils1.0リリース
「これからはコネクション閉じる箇所はDBUtils使うように。自前でやんなよ」
DBUtilsソース確認してみる→「俺が書いてたコードと同じじゃん('A`)」
jakartaを信奉するのは別に悪い事じゃないと思うけど、
こんな単純な処理の方針ぐらい自社で判断しろよ！
フレームワーク至上主義というか。>>658-659とか典型。
俺の会社での不毛なやり取り例
「コネクション閉じる箇所の例外処理とか冗長だからひとつのメソッドにまとめましょう」
「駄目だ、全部1メソッドの中で書いておかないとみんな混乱するだろ」
DBUtils1.0リリース
「これからはコネクション閉じる箇所はDBUtils使うように。自前でやんなよ」
DBUtilsソース確認してみる→「俺が書いてたコードと同じじゃん('A`)」
jakartaを信奉するのは別に悪い事じゃないと思うけど、
こんな単純な処理の方針ぐらい自社で判断しろよ！
673 ：仕様書無しさん：2005/12/24(土) 11:33:48
>そいやJavaが重いからＰＬ／ＳＱＬで作りましょうと提案してる会社があったなぁ。
その会社は優良な会社と思われる。遅いものは遅いと言っている。顧客をだまさない。
その会社は優良な会社と思われる。遅いものは遅いと言っている。顧客をだまさない。
PL/SQLだと技術者の習熟度も高いしな。
Javaは「俺のマシン」では遅い。
誰がなんと言おうともこれは事実だ。
だからJavaは重い。
嗚呼、金がほしい。
誰がなんと言おうともこれは事実だ。
だからJavaは重い。
嗚呼、金がほしい。
676 ：仕様書無しさん：2005/12/24(土) 12:05:44
Javaは「金持ちな最新スペックのメモリ2G積んだ俺のマシン」でもいつでも遅い。
誰がなんと言おうともこれは事実だ。
だからJavaは重い。
誰がなんと言おうともこれは事実だ。
だからJavaは重い。
677 ：仕様書無しさん：2005/12/24(土) 12:07:06
重い？それが何？
そんなに軽いのがよければ、MS-DOSとMASMで開発すれば良いじゃない。
そんなに軽いのがよければ、MS-DOSとMASMで開発すれば良いじゃない。
678 ：仕様書無しさん：2005/12/24(土) 12:15:58
ご丁寧にコンパイルまでしてバイナリになっいてるのに遅いのは世界中でJAVAだけ
たしかに・・・・
>>673
まともな会社なら、PL/SQL で書けるものは最初から PL/SQL で書くだろう。
まともな会社なら、PL/SQL で書けるものは最初から PL/SQL で書くだろう。
いや、まあ、いいや。
682 ：仕様書無しさん：2005/12/24(土) 12:24:45
オラクルもJavaをネイティブに変換するツールを提供していたよね
遅いのは自明の事実だからこんなツールを提供してくれている。
まあオラクルならばPL/SQLで組むのが吉。
遅いのは自明の事実だからこんなツールを提供してくれている。
まあオラクルならばPL/SQLで組むのが吉。
683 ：仕様書無しさん：2005/12/24(土) 14:50:49
>>672
今の仕事、出先企業のオリジナルフレームワークがEJB使ってるんだけどさ、
そのフレームワークの最新版はSpringベースで作り直しする予定らしいんだわ。
で、いまそのフレームワーク使って開発してるんだけど、EJB使ってることに
よるデメリットが大きいので、DIコンテナを独自で導入したいとおもったら、
フレームワークの管理チームが一言「そんな事勝手にしたらサポートしませんよ」
おまえら一体何がしたいんだと。自分でものが考えられないアフォの集団なんだ
と思った。某大企業のシステム部門にて。
今の仕事、出先企業のオリジナルフレームワークがEJB使ってるんだけどさ、
そのフレームワークの最新版はSpringベースで作り直しする予定らしいんだわ。
で、いまそのフレームワーク使って開発してるんだけど、EJB使ってることに
よるデメリットが大きいので、DIコンテナを独自で導入したいとおもったら、
フレームワークの管理チームが一言「そんな事勝手にしたらサポートしませんよ」
おまえら一体何がしたいんだと。自分でものが考えられないアフォの集団なんだ
と思った。某大企業のシステム部門にて。
EJBって使い物になる？
アプリケーション鯖が複数必要なら必須かと。
686 ：仕様書無しさん：2005/12/24(土) 15:06:47
>>684
EJB SessionBeanが活躍するのは分散オブジェクトをやりたいとき。
でもって、いまのJ2EEサーバーサイドって、Servletコンテナだけで
用が足りることが多いので、EJB使うメリットない場合がおおいんだ
よねえ…
EntityBeanはぶっちゃけ使えない。MessageDrivenBeanは非同期処理
やりたいときに辛うじて使い道がある。といったところかな。
EJB SessionBeanが活躍するのは分散オブジェクトをやりたいとき。
でもって、いまのJ2EEサーバーサイドって、Servletコンテナだけで
用が足りることが多いので、EJB使うメリットない場合がおおいんだ
よねえ…
EntityBeanはぶっちゃけ使えない。MessageDrivenBeanは非同期処理
やりたいときに辛うじて使い道がある。といったところかな。
>>666
10年前の思考を鵜呑みにするとは情けない。
テレビばかりみて嘘を信じているのと同じくらい危険
テレビが発信している情報の8割は嘘なんだから。
そして2chの嘘はもっとひどい。
とにかく自分で実際に動かして自分の目で確かめる
ことが確実。
10年前の思考を鵜呑みにするとは情けない。
テレビばかりみて嘘を信じているのと同じくらい危険
テレビが発信している情報の8割は嘘なんだから。
そして2chの嘘はもっとひどい。
とにかく自分で実際に動かして自分の目で確かめる
ことが確実。
688 ：仕様書無しさん：2005/12/24(土) 15:12:01
>>686
ぽじょぽじょばっかりいってると
仕事なくなるぞ。
「EJBはいらないこれからの時代はPOJOだ！」
と主張した人が社会的に抹殺されたという話を聞いたことがある。
セミナーでEJBはいらないというと本当に仕事が来なくなる。
ぽじょぽじょばっかりいってると
仕事なくなるぞ。
「EJBはいらないこれからの時代はPOJOだ！」
と主張した人が社会的に抹殺されたという話を聞いたことがある。
セミナーでEJBはいらないというと本当に仕事が来なくなる。
689 ：仕様書無しさん：2005/12/24(土) 15:15:41
>「EJBはいらないこれからの時代はPOJOだ！」
>と主張した人が社会的に抹殺されたという話を聞いたことがある。
APサーバうってる既得権益層の圧力？
>と主張した人が社会的に抹殺されたという話を聞いたことがある。
APサーバうってる既得権益層の圧力？
UNIXでCORBAは覚えるだけ無駄だとか言うと干されそうな気がする
EJBってようはそういうポジション？
EJBってようはそういうポジション？
>>672
君の僻みはもうわかったから
まずJavaしかやったことが無い野郎
という者が現実に存在することを証明してみよう。
最初の「全部一メソッドの中で書いておかないとみんな混乱する」
とは一体具体的にどういうものなんだろう。もっと詳しく説明してもらえないか。
何を全部一メソッドの中に書くのか？
複数のチームが入り乱れる開発では共通化を
促すために外部の有名どこのAPIで混乱を避けることができる。
君が作ったコードとDBUtilsとコードがまったく同じだというなら
そのコードを見せてもらいたいものだ。
まったく同じだというなら君よりも一般に広く知られているDBUtilsの
コードのほうが信用できる。そうは思わないかね？
君の僻みはもうわかったから
まずJavaしかやったことが無い野郎
という者が現実に存在することを証明してみよう。
最初の「全部一メソッドの中で書いておかないとみんな混乱する」
とは一体具体的にどういうものなんだろう。もっと詳しく説明してもらえないか。
何を全部一メソッドの中に書くのか？
複数のチームが入り乱れる開発では共通化を
促すために外部の有名どこのAPIで混乱を避けることができる。
君が作ったコードとDBUtilsとコードがまったく同じだというなら
そのコードを見せてもらいたいものだ。
まったく同じだというなら君よりも一般に広く知られているDBUtilsの
コードのほうが信用できる。そうは思わないかね？
>>690
分散オブジェクトを理解できない低脳扱いされちまうってわけか。ｲﾔﾝ。
分散オブジェクトを理解できない低脳扱いされちまうってわけか。ｲﾔﾝ。
>>689
そんな単純なもんではないかと。
汎用性を考えるとTomcat単体よりEJBつけたほうが
拡張しやすい。くだらない単なるダウンロードするだけのサーバなら
EJBもいらないだろうが。そうでないなら信頼性の強いものを
選ばないといけないわけで。金融系ではとくにEJBは重宝する。
そんな単純なもんではないかと。
汎用性を考えるとTomcat単体よりEJBつけたほうが
拡張しやすい。くだらない単なるダウンロードするだけのサーバなら
EJBもいらないだろうが。そうでないなら信頼性の強いものを
選ばないといけないわけで。金融系ではとくにEJBは重宝する。
金融系なんて初めからクラスタ前提だろ
ひさびさに@ITを見たけど、やっぱJavaのとこはパフォーマンスに関する
話題だらけだな。
話題だらけだな。
>>697
なんかGUIの質問増えてない？HTMLベースのUIは廃れ気味？
なんかGUIの質問増えてない？HTMLベースのUIは廃れ気味？
チューニングにネックのあるJava
コーディングにネックにあるC/C++
やっぱ時代はD言語を求めている
コーディングにネックにあるC/C++
やっぱ時代はD言語を求めている
702 ：仕様書無しさん：2005/12/25(日) 00:26:10
GCはもまいらの自由にはならんぞ、出直して来い。
703 ：仕様書無しさん：2005/12/25(日) 03:10:24
重いとか抽象的なのもうやめましょうよ。
以下のＪＡＶＡとＣの処理の違いだけを整理して、あとは各自どちらが早いのか信じればいいのです。
ＪＡＶＡ：ＪＡＶＡプログラム -> バイトコード -> ＯＳによるネイティブコード実行
C ：Ｃプログラム ->ＯＳによるネイティブコード実行
以下のＪＡＶＡとＣの処理の違いだけを整理して、あとは各自どちらが早いのか信じればいいのです。
ＪＡＶＡ：ＪＡＶＡプログラム -> バイトコード -> ＯＳによるネイティブコード実行
C ：Ｃプログラム ->ＯＳによるネイティブコード実行
馬鹿？
ＪＡＶＡプログラム -> バイトコード
コンパイラの処理は実行性能に関係ないぞ。
バイトコード -> ＯＳによるネイティブコード実行
JITコンパイル自身は実行性能と関係無いぞ。
Ｃプログラム -> ＯＳによるネイティブコード実行
だからコンパイラの処理は実行性能に関係無いってば。
ＪＡＶＡプログラム -> バイトコード
コンパイラの処理は実行性能に関係ないぞ。
バイトコード -> ＯＳによるネイティブコード実行
JITコンパイル自身は実行性能と関係無いぞ。
Ｃプログラム -> ＯＳによるネイティブコード実行
だからコンパイラの処理は実行性能に関係無いってば。
つうかね
Javaの開発は遅い
ｺｰﾃﾞｨﾝｸﾞがﾀﾞﾙｲ
素人に作らせると後でﾄﾝﾃﾞﾓﾊｯﾋﾟｰにな事になる
Javaの開発は遅い
ｺｰﾃﾞｨﾝｸﾞがﾀﾞﾙｲ
素人に作らせると後でﾄﾝﾃﾞﾓﾊｯﾋﾟｰにな事になる
706 ：仕様書無しさん：2005/12/25(日) 03:34:28
コンパイラの処理の結果は関係あるけどな。
JITコンパイルは実行時性能に関係あんだろ。あほう
>>707
クラスロード時のコストだけちゃうん。
クラスロード時のコストだけちゃうん。
709 ：仕様書無しさん：2005/12/25(日) 04:05:58
じっこうするためにろーどせんといかんやん？
でもおまいら、ブラウザ設定でJava無効にしてるよな？
>>691
具体的に言うと、SQLのConnection確保と開放だね。
getConnection()とclose(resultset,preparedStatement,connection)
っていうメソッドを作って、コネクションの取得とそれに関連するオブジェクトを開放する
処理を全部1クラスにまとめてそれを各メソッドで
method(){
Connection conn=getConnection();
try{
logic();
}finally{
closeConnection(resultSet,statement,conn);
}
}
っていう風に書きたかっただけなんだけどな。こうしないとfinally句に無駄な定型文が入りすぎる。
こんな低レベルな処理ですらJakartaに頼るって発想がおかしいよ。
もちろんDBUtilsがリリースされたから今後はそれを使うけど、
そーゆーちょっとした発想を全部Jakartaがライブラリとしてリリースしないと使えないっていう
思考停止ぶりを批判しているだけだよ。
おんなじアイデアを
社内の奴の提案→実績ないよ無理無理
Jakartaライブラリ→こいつはすげえぜ！みんなこれ使えよ！
っていう態度が主流を占めすぎていると、もしそのアイデアが優れたものであって、
他のオープンソース集団が思いつきもしないものだったら、そのアイデアは無駄に捨てられてしまうだろ？
Java厨はフレームワークですべてまかなおうとしすぎて、自分の発想を低く見すぎだ。
フレームワークなんてソース見たらたいしたことないのに、みんな名前だけですごいものと思いすぎてる。
具体的に言うと、SQLのConnection確保と開放だね。
getConnection()とclose(resultset,preparedStatement,connection)
っていうメソッドを作って、コネクションの取得とそれに関連するオブジェクトを開放する
処理を全部1クラスにまとめてそれを各メソッドで
method(){
Connection conn=getConnection();
try{
logic();
}finally{
closeConnection(resultSet,statement,conn);
}
}
っていう風に書きたかっただけなんだけどな。こうしないとfinally句に無駄な定型文が入りすぎる。
こんな低レベルな処理ですらJakartaに頼るって発想がおかしいよ。
もちろんDBUtilsがリリースされたから今後はそれを使うけど、
そーゆーちょっとした発想を全部Jakartaがライブラリとしてリリースしないと使えないっていう
思考停止ぶりを批判しているだけだよ。
おんなじアイデアを
社内の奴の提案→実績ないよ無理無理
Jakartaライブラリ→こいつはすげえぜ！みんなこれ使えよ！
っていう態度が主流を占めすぎていると、もしそのアイデアが優れたものであって、
他のオープンソース集団が思いつきもしないものだったら、そのアイデアは無駄に捨てられてしまうだろ？
Java厨はフレームワークですべてまかなおうとしすぎて、自分の発想を低く見すぎだ。
フレームワークなんてソース見たらたいしたことないのに、みんな名前だけですごいものと思いすぎてる。
あたりまえだ。おまえみたいな低級ドカタの俺様ライブラリより
Jakartaが優れているに決まっている。おまえの俺様ライブラリなど
選択の余地など無い。問答無用でJakartaを使え。どんな場合でも。
たったそれだけのことで幸せになれる。
Jakartaが優れているに決まっている。おまえの俺様ライブラリなど
選択の余地など無い。問答無用でJakartaを使え。どんな場合でも。
たったそれだけのことで幸せになれる。
バカは余計なことを考えるな。ただ使っとけ。
つくろうなどと考えたら駄目だ。
つくろうなどと考えたら駄目だ。
ｳﾜｧｧｧﾝ!!
そーゆー奴らが多いから業務でJavaやってる奴らは嫌なんだよう。
フレームワークが出るまでは平気でめんどくさいことさせやがる。
そーゆー奴らが多いから業務でJavaやってる奴らは嫌なんだよう。
フレームワークが出るまでは平気でめんどくさいことさせやがる。
715 ：仕様書無しさん：2005/12/25(日) 11:56:01
それがJava厨クオリティ
Java厨が俺様クラスライブラリをそれぞれ作り出したら大変なことになるじゃんよ。
何のための構造化言語なんだ…
>>711
分かる！分かるぞ、その気持ち。
俺も自前で起こしてたコンフィギュレーションフレームワークを
CommonsのConfigurationに置き換えさせられたよ｡･ﾟ･(ﾉД`)･ﾟ･｡
その頃はXMLのりローディングストラテジすらまともに実装され
てなくて、未完成なのは明らかだったのにorz
おまけに、自社内で使う気は全くないくせして業務中に書いた
ソースコードの権利は会社にあるとか言ってオープンソース化
も許可されないし、オプソは喜んで使うが自社のソースは絶対
にオプソ化しないってハッキリ言って盗人じゃんヽ(`Д´)ﾉｳﾜｧｧ
分かる！分かるぞ、その気持ち。
俺も自前で起こしてたコンフィギュレーションフレームワークを
CommonsのConfigurationに置き換えさせられたよ｡･ﾟ･(ﾉД`)･ﾟ･｡
その頃はXMLのりローディングストラテジすらまともに実装され
てなくて、未完成なのは明らかだったのにorz
おまけに、自社内で使う気は全くないくせして業務中に書いた
ソースコードの権利は会社にあるとか言ってオープンソース化
も許可されないし、オプソは喜んで使うが自社のソースは絶対
にオプソ化しないってハッキリ言って盗人じゃんヽ(`Д´)ﾉｳﾜｧｧ
ドカタの分際で何を言っちゃってんの？
>>711
えーと、それって基本中の基本じゃね？
漏れはC++だが、そういった関数にDB接続確認のロジックも入れて、
(当然DBExceptionで接続確認失敗かどうかの判定も入れる)
DB処理を流す前にやるのがデフォだと思ったんだが、
・・・ごめん俺ってJavaやってる人達の事誤解していたよ。
純粋なコボラーの後継者なんですね・・・。
えーと、それって基本中の基本じゃね？
漏れはC++だが、そういった関数にDB接続確認のロジックも入れて、
(当然DBExceptionで接続確認失敗かどうかの判定も入れる)
DB処理を流す前にやるのがデフォだと思ったんだが、
・・・ごめん俺ってJavaやってる人達の事誤解していたよ。
純粋なコボラーの後継者なんですね・・・。
722 ：仕様書無しさん：2005/12/25(日) 14:50:34
ばかどもはコネンションプールもできねのえのかw
あるものを作る必要ないだろ。バカ
724 ：仕様書無しさん：2005/12/25(日) 15:53:05
>>713
もしかして、先輩でつか。
この前、そういわれましたよね。
漏れが作った、あらゆるＤＢ処理対応でき、個々の実装はたったの２０行で済むクラスを
わざわざ半月かけて、書き直おさせたのですよね。
余りにもアホらしさに反論する気にもなれず、もちろん強力な理由（セキュリテイ対応、メンテナンス容易、コーディング不要など）
があるのですがね。さて、転職の季節ですかね。
もしかして、先輩でつか。
この前、そういわれましたよね。
漏れが作った、あらゆるＤＢ処理対応でき、個々の実装はたったの２０行で済むクラスを
わざわざ半月かけて、書き直おさせたのですよね。
余りにもアホらしさに反論する気にもなれず、もちろん強力な理由（セキュリテイ対応、メンテナンス容易、コーディング不要など）
があるのですがね。さて、転職の季節ですかね。
725 ：仕様書無しさん：2005/12/25(日) 16:49:34
726 ：仕様書無しさん：2005/12/25(日) 17:11:32
>>725
先輩、ＪＤＢＣの層が各固有ＤＢを意識しますか。
漏れの作ったクラスはＪＤＢＣのラッパですよ。
さらに抽象化した奴。
単純といえば単純ですが、実装は大幅に減る。
まぁ先輩にはお気に召さないだろうけど。
先輩、ＪＤＢＣの層が各固有ＤＢを意識しますか。
漏れの作ったクラスはＪＤＢＣのラッパですよ。
さらに抽象化した奴。
単純といえば単純ですが、実装は大幅に減る。
まぁ先輩にはお気に召さないだろうけど。
727 ：仕様書無しさん：2005/12/25(日) 17:30:18
J厨同士で喧嘩するなよ。なかよくしな。
「僕の考えた●●」が邪魔扱いされるのは
大抵の場合レヴューとドキュメントの不足だけが原因だと思うが。
719みたいなバカがプロジェクトチームにいたら椅子蹴り上げるところだな。
大抵の場合レヴューとドキュメントの不足だけが原因だと思うが。
719みたいなバカがプロジェクトチームにいたら椅子蹴り上げるところだな。
729 ：仕様書無しさん：2005/12/25(日) 18:16:36
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
レヴュー レヴュー レヴュー レヴュー レヴュー レヴュー
カネボウ
車輪の再発明とか言うやつに限って、
大抵コピペしたソースコードだったり、ライブラリー使っても
地雷を踏むような真似するんだよな～。
車輪が便利だからって、それを使いこなすには中身しらにゃ
ならんのに・・・。
大抵コピペしたソースコードだったり、ライブラリー使っても
地雷を踏むような真似するんだよな～。
車輪が便利だからって、それを使いこなすには中身しらにゃ
ならんのに・・・。
でた車輪ｗ
そういう奴に限って車輪で浮かぼうとするんだよね実際。
そういう奴に限って車輪で浮かぼうとするんだよね実際。
ライブラリにまとめてあれば不具合の対処も楽なのに、アホは
汎化能力が無いのか、作業が面倒くさいのか、プロジェクトを跨いで
同じコードをコピペしまくり、不具合をとんでもない規模で拡散させる。
しかも微妙に修正してあるので、grepをかけまくっても拾えないものもあったり。
汎化能力が無いのか、作業が面倒くさいのか、プロジェクトを跨いで
同じコードをコピペしまくり、不具合をとんでもない規模で拡散させる。
しかも微妙に修正してあるので、grepをかけまくっても拾えないものもあったり。
派遣にゃ関係ない。＜ライブリラリ
余計な作業する奴はアホだ。
余計な作業する奴はアホだ。
737 ：仕様書無しさん：2005/12/25(日) 19:25:32
>>726
俺も経験があるから分かるけど、
大抵の場合はアプローチがヘタなだけだと思う。
大きいＰＪの場合、方式を統一するのは結構なエネルギーを使う。
開発中だけでなく、後々のメンテやバージョンアップでも
同じ方式を取らせようと思ったら規約化とかが必要だ。
そういう面倒なことをやるために
「便利だから」
という実績のない理由よりも
「Ｊａｋａｒｔａから提供されている」
という方が皆を納得させるのには都合がよかったのではないのか？
とその先輩を擁護してみる。
もちろん、その先輩が無能で君の提案の意味を理解できなかった
可能性は否定しない。
俺も経験があるから分かるけど、
大抵の場合はアプローチがヘタなだけだと思う。
大きいＰＪの場合、方式を統一するのは結構なエネルギーを使う。
開発中だけでなく、後々のメンテやバージョンアップでも
同じ方式を取らせようと思ったら規約化とかが必要だ。
そういう面倒なことをやるために
「便利だから」
という実績のない理由よりも
「Ｊａｋａｒｔａから提供されている」
という方が皆を納得させるのには都合がよかったのではないのか？
とその先輩を擁護してみる。
もちろん、その先輩が無能で君の提案の意味を理解できなかった
可能性は否定しない。
part2ができそうな勢いだな
確かに、こういうのは宗教対立を招きがち。
俺はああいうスタイルがいい。俺は気にいらねぇとか好き勝手なこといって。
ところが"Jakarta"といえばどんな厨も黙り込むもんな。
俺はああいうスタイルがいい。俺は気にいらねぇとか好き勝手なこといって。
ところが"Jakarta"といえばどんな厨も黙り込むもんな。
strutsはくそ
>>740をつまみだせ
742 ：仕様書無しさん：2005/12/25(日) 19:51:01
う～ん。実に低レベルだ。呆れた。
何ヌルイこと言ってんだ。ここで始末してしまえ。
俺の会社のソースレビュー中の悲惨な話
「君ぃ！なんだねこの部分の実装は。まるで意味がわからんじゃないか。
こんなところに、アクセス修飾子も書かれていないメソッドまである！」
「はい、そこの部分の実装は汎用的な箇所をテンプレートとしてまとめ、
固有の処理をコールバックさせる設計にしております。
その修飾子の無いメソッドはコールバック用に可視性をパッケージプライベートにしているのです」
「そ、そんな複雑な設計、お前は書いてて楽しいかもしれないけど、他の奴らが読めないだろ！
そーゆーのはグループ開発ではご法度なんだよ！わかりやすく書き直せ」
「はい('A`)」
かくして、各クラスにコピペコードは広がっていくのであった。
オラしらね。
「君ぃ！なんだねこの部分の実装は。まるで意味がわからんじゃないか。
こんなところに、アクセス修飾子も書かれていないメソッドまである！」
「はい、そこの部分の実装は汎用的な箇所をテンプレートとしてまとめ、
固有の処理をコールバックさせる設計にしております。
その修飾子の無いメソッドはコールバック用に可視性をパッケージプライベートにしているのです」
「そ、そんな複雑な設計、お前は書いてて楽しいかもしれないけど、他の奴らが読めないだろ！
そーゆーのはグループ開発ではご法度なんだよ！わかりやすく書き直せ」
「はい('A`)」
かくして、各クラスにコピペコードは広がっていくのであった。
オラしらね。
745 ：仕様書無しさん：2005/12/25(日) 20:03:42
皆さんはホントに汎用機系COBOLer の継承者になるつもりなんですか？
それでいいんですか？技術者としての意地はないのか？
それでいいんですか？技術者としての意地はないのか？
746 ：仕様書無しさん：2005/12/25(日) 20:05:49
>>745
じゃぁどぅすりゃいいのさぁ
じゃぁどぅすりゃいいのさぁ
もうOOって破綻してると思うのは俺だけか。
748 ：仕様書無しさん：2005/12/25(日) 20:10:07
>>746
知らんがな。
知らんがな。
いやあドカタですね？
てかさあ、妙に練りまくったクラス作ろうとするのやめねえ？
逆に効率悪くてイライラしてくるんだよね。
適当で良いじゃん
どうせそんなに金のかかったプロジェクトて滅多に無いんだし。
逆に効率悪くてイライラしてくるんだよね。
適当で良いじゃん
どうせそんなに金のかかったプロジェクトて滅多に無いんだし。
たとえばどんな？
753 ：仕様書無しさん：2005/12/25(日) 22:07:38
確かに巧妙に抽象化してるけど、それを利用する時は限りなくシンプル、
たぶんそんなコードを読もうとして、全く理解できなかったのでは?
で、子分の新人ＰＧに聞いて、「処理が重い」とか吹き込まれ、書き直せとか言うのだろう。
たぶんそんなコードを読もうとして、全く理解できなかったのでは?
で、子分の新人ＰＧに聞いて、「処理が重い」とか吹き込まれ、書き直せとか言うのだろう。
754 ：仕様書無しさん：2005/12/25(日) 22:12:58
>>747
ＯＯはとっくに破綻してる。
ＯＯは、ソフト開発のセンスのない奴のためのものだろ。
こういうこと言うと、アスペクトを補完的に使えばいいという分かってない
奴が現れるが・・・。
アプリケーション設計、アーキテクチャ設計、コンポーネント設計いろいろ
あるが、ＯＯはそのうちの一部を解決しているにすぎない。
ＯＯは万能ナイフではない。
アプリケーション設計をコンポーネント設計と同じ脳みそで考える
と妙に練りまくった生産性の低いクラスが出来てしまう。
ＯＯはとっくに破綻してる。
ＯＯは、ソフト開発のセンスのない奴のためのものだろ。
こういうこと言うと、アスペクトを補完的に使えばいいという分かってない
奴が現れるが・・・。
アプリケーション設計、アーキテクチャ設計、コンポーネント設計いろいろ
あるが、ＯＯはそのうちの一部を解決しているにすぎない。
ＯＯは万能ナイフではない。
アプリケーション設計をコンポーネント設計と同じ脳みそで考える
と妙に練りまくった生産性の低いクラスが出来てしまう。
実際重いのは良くないと思う
COBOLで書けば良いのに
クラスライブラリとして、標準ライブラリを階層化してわかりやすくすることには
意味あるかもしれないけど、インスタンスとかデザインパターンとかイテレータ
なんてのはバグの温床じゃね？COBOLの後継として金融とか基幹業務を
担うにはさ。そもそもそんなにたいそうな複雑なことしないよ。COBOLは。
意味あるかもしれないけど、インスタンスとかデザインパターンとかイテレータ
なんてのはバグの温床じゃね？COBOLの後継として金融とか基幹業務を
担うにはさ。そもそもそんなにたいそうな複雑なことしないよ。COBOLは。
758 ：仕様書無しさん：2005/12/25(日) 22:40:34
おいおい。インスタンスとデザインパターンとイテレータを同列に扱っちゃ
だめだぞ。これらは違う生き物だからね。イテレータくらいは使ってあげようよ。
デザインパターンは、適切に使わないとリスクを伴うよん。実際の設計は
デザパタほど簡単じゃないから使えない事が多いよ。
だめだぞ。これらは違う生き物だからね。イテレータくらいは使ってあげようよ。
デザインパターンは、適切に使わないとリスクを伴うよん。実際の設計は
デザパタほど簡単じゃないから使えない事が多いよ。
759 ：仕様書無しさん：2005/12/25(日) 22:41:48
>>757
昔のＣＯＢＯＬと同じことだけしてればいいならそれもよかろう。
だが、今は時代が違う。銀行業務も複雑になっており、
昔よりも短期間での開発が要求される。
だから開発でもモデルを作成して使いまわすことが必要になる。
昔のＣＯＢＯＬと同じことだけしてればいいならそれもよかろう。
だが、今は時代が違う。銀行業務も複雑になっており、
昔よりも短期間での開発が要求される。
だから開発でもモデルを作成して使いまわすことが必要になる。
実際は使いまわせてないけどなｗ
ヘタに使いまわして一部だけ更新になった時が最悪なんだよ。
それこそ数回コピペすりゃ良いだけの物のために
クラス再設計でよけいな手間かけることになりかねない。
それこそ数回コピペすりゃ良いだけの物のために
クラス再設計でよけいな手間かけることになりかねない。
さっさとコピペしろ。時間の無駄
763 ：仕様書無しさん：2005/12/25(日) 23:08:25
重い。とてつもなく重い。
既にリリースから10年も経っているのに、進歩が物凄く遅い。
既にリリースから10年も経っているのに、進歩が物凄く遅い。
バグフィックスも遅いしな。
だーね。.netには足元にも及ばないね
.neetはもっと糞
クラス単体のテストツールにロクなの無いからバグの温床になる。
junitがあるだろ。ばか
769 ：仕様書無しさん：2005/12/25(日) 23:32:22
しかも忘れたり
忘れるって…
どうせｺﾋﾟﾍﾟ＆後でbugfixするなら、
検索して置換するとか、なんか手を打てよ。ｗ
どうせｺﾋﾟﾍﾟ＆後でbugfixするなら、
検索して置換するとか、なんか手を打てよ。ｗ
めんどくせ
ばれなきゃいいだろ。どうせ保守はポチ社員がやるって。
775 ：仕様書無しさん：2005/12/26(月) 00:08:08
ひっど～い。
776 ：仕様書無しさん：2005/12/26(月) 00:08:18
いや、いかにオールドタイプでも
まともなやつなら共通サブルーチンくらいは考えるはず
コピペとは、、、、
まともなやつなら共通サブルーチンくらいは考えるはず
コピペとは、、、、
うぜ
結局これは、Javaがどうこうという話ではなくなってるよな。
むしろ思考レベルが一段下の同僚・上司と共にグループ開発をする際の難しさというか。
むしろ思考レベルが一段下の同僚・上司と共にグループ開発をする際の難しさというか。
派遣だから関係ないもん。
将来も考えたコーディングして欲しければ金よこせ。
将来も考えたコーディングして欲しければ金よこせ。
金もらって書き方教えてもらわないと駄目なくせに何言ってんだ
781 ：仕様書無しさん：2005/12/26(月) 00:42:07
なんか強烈に低次元な話になってきたな
お前ら本当に贅沢な奴だな
共同作業で仕事させて貰えるだけでもありがたく思えよ。
共同作業で仕事させて貰えるだけでもありがたく思えよ。
783 ：仕様書無しさん：2005/12/26(月) 00:49:18
んじゃ社員だけでやれよ
784 ：仕様書無しさん：2005/12/26(月) 01:37:17
けっきょくOOどころか構造化すら知らない派遣PGが暴れてただけか
あほくさ
あほくさ
785 ：仕様書無しさん：2005/12/26(月) 01:42:08
テンプレートベースのコーディングのどこが悪いの？
787 ：仕様書無しさん：2005/12/26(月) 01:52:46
おいおいまじかよ。
コボラを笑えなくなってきた。
コボラを笑えなくなってきた。
理想は分かるけど
結局、早く成果を出すやつが優秀なんだよ。
分かれよ、子供じゃないんだから。
結局、早く成果を出すやつが優秀なんだよ。
分かれよ、子供じゃないんだから。
>>788
ある面では真実だな。
とりあえずの作業用に動けばいいscriptでOOするのは、
コストを考えると得策でないケースもあるかもしれん。
とはいえ、OOしてコピペコードと同じかそれ以上の、
作業スピードと結果、メンテナンス性を出せればいいわけで。
ある面では真実だな。
とりあえずの作業用に動けばいいscriptでOOするのは、
コストを考えると得策でないケースもあるかもしれん。
とはいえ、OOしてコピペコードと同じかそれ以上の、
作業スピードと結果、メンテナンス性を出せればいいわけで。
それができないのがJava厨
SEもいい奴見つけたと喜んでるさ
SEもいい奴見つけたと喜んでるさ
まぁｵﾚ様は全部ｺﾋﾟﾍﾟですがね
792 ：仕様書無しさん：2005/12/26(月) 07:35:11
X, C, Vキーがてかてかの俺様が来ましたよ。
793 ：仕様書無しさん：2005/12/26(月) 08:01:48
コピペ厨が意外に多いね
新規開発と、それの保守では
実は後者の方がコストが掛かっているって話もあるんだよね
コピペコードの嵐を作り逃げされた後を
メンテする辛さと来たら・・('A`)
新規開発と、それの保守では
実は後者の方がコストが掛かっているって話もあるんだよね
コピペコードの嵐を作り逃げされた後を
メンテする辛さと来たら・・('A`)
どちらにしても新規開発時はかかわってないのに
保守だけやらされるのはつらい。
保守だけやらされるのはつらい。
795 ：仕様書無しさん：2005/12/26(月) 19:52:48
つーかコピペはJavaとかCとかの問題じゃないだろう。
単に素人なだけだ。
単に素人なだけだ。
他人のコードを読むのはつらい。
コードから仕様を読み取るのはつらい
つーか時間掛かる。でも時間はくれない。
つーか時間掛かる。でも時間はくれない。
コードを読む時間を要求する方向で再検討してはどうか
799 ：仕様書無しさん：2005/12/26(月) 20:17:54
ｧ _, ,_ ｧ,､
,､'` （ ﾟ∀ﾟ） ,､'`
'` ( ⊃⊂) '`
Javaで作った銀行のシステムなんざ、コピペだらけの素人コード。
こんな銀行には金は預けない。ﾄﾞｺｶｲﾜﾅｲｹﾄﾞ
,､'` （ ﾟ∀ﾟ） ,､'`
'` ( ⊃⊂) '`
Javaで作った銀行のシステムなんざ、コピペだらけの素人コード。
こんな銀行には金は預けない。ﾄﾞｺｶｲﾜﾅｲｹﾄﾞ
まあ、調理場見たら料理は食えんわな。
大して変わらんとこでも、内情知らなけりゃ結構平気。
大して変わらんとこでも、内情知らなけりゃ結構平気。
コピペ素人はJavaとVBの専売特許。
JavaやVBが悪いわけではない。
素人を呼び寄せる敷居の低さと煽るIT出版界が悪い。
JavaやVBが悪いわけではない。
素人を呼び寄せる敷居の低さと煽るIT出版界が悪い。
この人何厨だろう?
なんで嫌味の方にマジレスするんだろ？('A`)
>>805
え、嫌味には皮肉で返すんだろ？
え、嫌味には皮肉で返すんだろ？
807 ：仕様書無しさん：2005/12/26(月) 23:50:05
リファクタリング
Java厨が初期設計の甘さを言い訳する仕組み
Java厨が初期設計の甘さを言い訳する仕組み
所謂造りなおしのこと。無駄な工数。
809 ：仕様書無しさん：2005/12/27(火) 00:53:22
おいおい、リファクタリングやった事ないのか？
あらゆる言語でリファクタリングは有効だと思うが。
あらゆる言語でリファクタリングは有効だと思うが。
810 ：仕様書無しさん：2005/12/27(火) 01:12:27
811 ：仕様書無しさん：2005/12/27(火) 02:01:23
技術者は貪欲であるべきだと思うぜ。
薄く理解して排除するには惜しい技術やテクニックはごまんとあるんだから。
薄く理解して排除するには惜しい技術やテクニックはごまんとあるんだから。
> 技術やテクニック
ですか、相変わらずタメになるよな
ですか、相変わらずタメになるよな
813 ：仕様書無しさん：2005/12/27(火) 05:13:41
PDFより１００倍軽い
ゆえに、リファクタリングっていうのが分かってるかどうかアヤスイんじゃねえか
と感じる俺がここにいる
と感じる俺がここにいる
特許庁の特許電子図書館がJavaから普通のcgiっぽくなってるんだけど
>>815
何を皮肉ってるのかよくわかんねぇよ
何を皮肉ってるのかよくわかんねぇよ
JavaのWebアプリってアクセスが集中すると
すぐ落ちるよね。あれなんとかならないかな。
ASPやPHPのほうが全然堅牢
すぐ落ちるよね。あれなんとかならないかな。
ASPやPHPのほうが全然堅牢
819 ：仕様書無しさん：2005/12/27(火) 08:28:53
コボラーってのは「コボルが出来る人」って意味じゃなくて、
「長年やってもコボルしか出来ない人」って意味だろう。
そしてコボルは素人でも1カ月でマスター出来る言語なので、
1年以上プログラマやっていてもコボルしか出来ない人を
向上心の無い古びたプログラマと言う意味で「コボラー」と言うんだろう。
つまり普通の人なら3年でマスター出来るCを、5年以上やっていてもCしか出来ない人や
普通なら1年半でマスター出来るJavaを、3年以上やっていてもJavaしか出来ない人こそ
真のコボラーの継承者と言えるだろう。
「長年やってもコボルしか出来ない人」って意味だろう。
そしてコボルは素人でも1カ月でマスター出来る言語なので、
1年以上プログラマやっていてもコボルしか出来ない人を
向上心の無い古びたプログラマと言う意味で「コボラー」と言うんだろう。
つまり普通の人なら3年でマスター出来るCを、5年以上やっていてもCしか出来ない人や
普通なら1年半でマスター出来るJavaを、3年以上やっていてもJavaしか出来ない人こそ
真のコボラーの継承者と言えるだろう。
820 ：仕様書無しさん：2005/12/27(火) 08:32:31
アマゾンもCGIじゃなかったっけ？
有名サイトでJavaってどこ？
有名サイトでJavaってどこ？
Javaで成功させるにはなるべくオブジェクト指向に
しないことだよね。
しないことだよね。
正直、堅牢さよりも複雑なロジックを書けるところに意味があるんだろうな。Java.のWebアプリは。
けど、全然そんなアプリ無い。
けど、全然そんなアプリ無い。
825 ：仕様書無しさん：2005/12/27(火) 09:01:57
ぶっちゃけ、言語以前にwebアプリに複雑なことさせたら失敗する。
Javaはオーバースペック
Javaはオーバースペック
826 ：仕様書無しさん：2005/12/27(火) 09:07:18
>825
いえてる
いえてる
でも業務系って複雑なワークフローを回す必要があるから
ワークフロー系のJ2EEミドルウェアはよく使うよ。
技術的に複雑っていうより、しちめんどくせぇ複雑さだけど。
ワークフロー系のJ2EEミドルウェアはよく使うよ。
技術的に複雑っていうより、しちめんどくせぇ複雑さだけど。
客のいいなりの業務仕様を鵜呑みにするとそうなる。
業務改善を含めて提案できないと地獄。業務系(ﾜﾗ
業務改善を含めて提案できないと地獄。業務系(ﾜﾗ
いや、業務改善は提案できても客の人事組織を改善するのは
情報化推進部門には権限がねーんだわ。
人事組織にひもづくようなワークフローを構築する時には
大なり小なりめんどくせぇ。
情報化推進部門には権限がねーんだわ。
人事組織にひもづくようなワークフローを構築する時には
大なり小なりめんどくせぇ。
>> 817
どうでもいいことだが、技術とテクニックって
同じ意味だからじゃないか？
どうでもいいことだが、技術とテクニックって
同じ意味だからじゃないか？
technology と technique だろ、ボケ
戦略と戦術の違いみたい。> technologyとtechnique
ワークフローなんざサイボウズの回覧板使えば十分だろ。
天才
835 ：仕様書無しさん：2005/12/28(水) 00:07:53
Java 厨に Java の話をさせると二言目には業務系云々の話しか出てこないのが
なんともｗ
なんともｗ
836 ：仕様書無しさん：2005/12/28(水) 00:12:51
業務系とか基幹系とかって、あほみたいに単純なソフトがアホみたいな量あるだけじゃん
COBOLの伝統？
COBOLの伝統？
838 ：仕様書無しさん：2005/12/28(水) 09:47:00
なんで業務系ソフトって、ワードやエクセルみたいに共通化してみんなが
それに合わせる、というふうにならないのかねえ。
なんか、プログラミングで一番やってはいけない車輪の再発明を壮大に
繰り返しているようで、プログラマの労働力を無駄遣いしているだけの
ような気がする。
それに合わせる、というふうにならないのかねえ。
なんか、プログラミングで一番やってはいけない車輪の再発明を壮大に
繰り返しているようで、プログラマの労働力を無駄遣いしているだけの
ような気がする。
839 ：仕様書無しさん：2005/12/28(水) 10:06:12
世の中、各部門が勝手にExcelマクロとかMDBで業務してるから効率悪いんだが。ｗ
共通化できるのはExcel本体とマクロ仕様であって、業務ロジックの共通化は不可能。
まあ、外国みたいにそもそもの業務体系すらない部分にパッケージ適用するのは楽だけどね。
ソフトが業務を強制するようなことが日本には馴染まない。
共通化できるのはExcel本体とマクロ仕様であって、業務ロジックの共通化は不可能。
まあ、外国みたいにそもそもの業務体系すらない部分にパッケージ適用するのは楽だけどね。
ソフトが業務を強制するようなことが日本には馴染まない。
他と同じ業務をしていては勝ち残れない
>>705
> つうかね
> Javaの開発は遅い
> ｺｰﾃﾞｨﾝｸﾞがﾀﾞﾙｲ
> 素人に作らせると後でﾄﾝﾃﾞﾓﾊｯﾋﾟｰにな事になる
君のいうとおり素人に使わせれば開発は遅いさ。
開発効率を高めるためAntくらいは使いこなせないとJava開発者として失格。
あとはEclipseとあわせてCheckstyleやFindBugsやMavenなどを
組み合わせると最適。
> つうかね
> Javaの開発は遅い
> ｺｰﾃﾞｨﾝｸﾞがﾀﾞﾙｲ
> 素人に作らせると後でﾄﾝﾃﾞﾓﾊｯﾋﾟｰにな事になる
君のいうとおり素人に使わせれば開発は遅いさ。
開発効率を高めるためAntくらいは使いこなせないとJava開発者として失格。
あとはEclipseとあわせてCheckstyleやFindBugsやMavenなどを
組み合わせると最適。
843 ：仕様書無しさん：2005/12/28(水) 11:29:59
AntやEclipceが使えることが技術と思うってのも・・・。
ツールの使い方ってあくまで小手先。
ツールの使い方ってあくまで小手先。
ツールが使えるのもひとつのぎじゅつだね
だって、ツールの使い方覚えるのも時間かかるじゃん
だって、ツールの使い方覚えるのも時間かかるじゃん
845 ：仕様書無しさん：2005/12/28(水) 11:42:46
技術っていうか技能でしょ？
ライン工が冶具の使い方を覚えるのと同じ。
本質的なそのものの仕組みではなく、組み立てる為の手立て。
ライン工が冶具の使い方を覚えるのと同じ。
本質的なそのものの仕組みではなく、組み立てる為の手立て。
>>845
そういう道具の存在も使い方もわからないような
技術云々を語る資格もないレベルの無能工員がプロと
あまり変わらない工賃で労働しているのが問題ですな。
十羽一からげで1人月〇万円の世界って恐ろしい。
そういう道具の存在も使い方もわからないような
技術云々を語る資格もないレベルの無能工員がプロと
あまり変わらない工賃で労働しているのが問題ですな。
十羽一からげで1人月〇万円の世界って恐ろしい。
そうそう。俺なら1人月1000万でも全然安いと思う。
848 ：仕様書無しさん：2005/12/28(水) 11:51:05
850 ：仕様書無しさん：2005/12/28(水) 12:01:42
>>711
> >>691
> そーゆーちょっとした発想を全部Jakartaがライブラリとしてリリースしないと使えないっていう
> 思考停止ぶりを批判しているだけだよ。
Jakarta で提供したもの以外は使えない、使いたくない、あとから自分で補足すらしないというなら
確かに思考停止だが、Jakarta製品を使う者が全員そういう奴だとは限らないし
そんなことだけでJakarta 製品を使うこと自体を批判するのは被害妄想強すぎに見える。
> おんなじアイデアを
> 社内の奴の提案→実績ないよ無理無理
> Jakartaライブラリ→こいつはすげえぜ！みんなこれ使えよ！
> っていう態度が主流を占めすぎていると、もしそのアイデアが優れたものであって、
> 他のオープンソース集団が思いつきもしないものだったら、そのアイデアは無駄に捨てられてしまうだろ？
> Java厨はフレームワークですべてまかなおうとしすぎて、自分の発想を低く見すぎだ。
> フレームワークなんてソース見たらたいしたことないのに、みんな名前だけですごいものと思いすぎてる。
すまん、これを読んでからやっぱり君の被害妄想が激しいことがよくわかった。
君が想像している会社関係者は「Jakarta製品だけを使え。自分のアイデアは捨てろ」という人物で
君は「Jakarta製品は一切使うな。自分のアイデアを重視しろ」という人物なんだね。
君の脳みその一部を分析するとこうなる。
それにしてもどちらの人物も両極端だが
「Jakarta製品は使っても使わなくてもいい。自分なりのアイデアをソースコードに取り入れてもいい」
と言う人間だっているってことを忘れていないか？
「Jakartaをベースにして自分の発想を追加する」という「発想」は君にはないのか？
> >>691
> そーゆーちょっとした発想を全部Jakartaがライブラリとしてリリースしないと使えないっていう
> 思考停止ぶりを批判しているだけだよ。
Jakarta で提供したもの以外は使えない、使いたくない、あとから自分で補足すらしないというなら
確かに思考停止だが、Jakarta製品を使う者が全員そういう奴だとは限らないし
そんなことだけでJakarta 製品を使うこと自体を批判するのは被害妄想強すぎに見える。
> おんなじアイデアを
> 社内の奴の提案→実績ないよ無理無理
> Jakartaライブラリ→こいつはすげえぜ！みんなこれ使えよ！
> っていう態度が主流を占めすぎていると、もしそのアイデアが優れたものであって、
> 他のオープンソース集団が思いつきもしないものだったら、そのアイデアは無駄に捨てられてしまうだろ？
> Java厨はフレームワークですべてまかなおうとしすぎて、自分の発想を低く見すぎだ。
> フレームワークなんてソース見たらたいしたことないのに、みんな名前だけですごいものと思いすぎてる。
すまん、これを読んでからやっぱり君の被害妄想が激しいことがよくわかった。
君が想像している会社関係者は「Jakarta製品だけを使え。自分のアイデアは捨てろ」という人物で
君は「Jakarta製品は一切使うな。自分のアイデアを重視しろ」という人物なんだね。
君の脳みその一部を分析するとこうなる。
それにしてもどちらの人物も両極端だが
「Jakarta製品は使っても使わなくてもいい。自分なりのアイデアをソースコードに取り入れてもいい」
と言う人間だっているってことを忘れていないか？
「Jakartaをベースにして自分の発想を追加する」という「発想」は君にはないのか？
851 ：仕様書無しさん：2005/12/28(水) 12:02:17
つーか、素人に作らせると問題ってのは、「C vs Java」って話じゃないよな。
「Perl vs Java」？「PHP vs Java」？
あとJavaがアクセスが集中すると落ちやすいてのは、何と比べての話？
「Perl」じゃないよな？「C」か？
「Perl vs Java」？「PHP vs Java」？
あとJavaがアクセスが集中すると落ちやすいてのは、何と比べての話？
「Perl」じゃないよな？「C」か？
852 ：仕様書無しさん：2005/12/28(水) 12:04:01
>>843
使いこなせない奴が多いから
ここで啓蒙しておかないと
数々のJavaプロジェクトがこれから
ますます悲惨なものになる。
せっかくすばらしい技術を使っているにも
かかわらず使いこなせないのはどうにかしていると思ってね。
今まで三社でJavaの仕事をやってきたが
Antのような自動化ツールの価値がわからない香具師が
実に多いこと。Antは知らないと損をすることが多いですマジで。
使いこなせない奴が多いから
ここで啓蒙しておかないと
数々のJavaプロジェクトがこれから
ますます悲惨なものになる。
せっかくすばらしい技術を使っているにも
かかわらず使いこなせないのはどうにかしていると思ってね。
今まで三社でJavaの仕事をやってきたが
Antのような自動化ツールの価値がわからない香具師が
実に多いこと。Antは知らないと損をすることが多いですマジで。
854 ：仕様書無しさん：2005/12/28(水) 12:07:04
a
>>844
ＡｎｔやEclipse慣れればどうってことないよ。
それにAnt覚えたからといって
いずれ不要になる恐れもわりとすくない。
Jakartaプロジェクトのブツは覚えて損にならないものが多い。
Jakartaプロジェクト自体、Antで開発されているものだから。
最近ではAntに加え、MavenやGump, Forrestなども使われていたりする。
ＡｎｔやEclipse慣れればどうってことないよ。
それにAnt覚えたからといって
いずれ不要になる恐れもわりとすくない。
Jakartaプロジェクトのブツは覚えて損にならないものが多い。
Jakartaプロジェクト自体、Antで開発されているものだから。
最近ではAntに加え、MavenやGump, Forrestなども使われていたりする。
856 ：仕様書無しさん：2005/12/28(水) 12:09:43
>>852
なんつうのかな・・・それがどうした？って思うよ。
基本的なコンパイルはEclipceで出来るし、大規模システムならば各自がやることではない。
ビルド手順などは管理者が考えることだ。
で、Antは知ってればそれはこしたことはないけど、じゃあ必須か？って思ったときに使うときに覚えれば十分と思うけどね。
なんつうのかな・・・それがどうした？って思うよ。
基本的なコンパイルはEclipceで出来るし、大規模システムならば各自がやることではない。
ビルド手順などは管理者が考えることだ。
で、Antは知ってればそれはこしたことはないけど、じゃあ必須か？って思ったときに使うときに覚えれば十分と思うけどね。
858 ：仕様書無しさん：2005/12/28(水) 12:10:49
ForrestGump萌え。
>>858
855にならんでいるのはみんなツールじゃないですか？
855にならんでいるのはみんなツールじゃないですか？
>>850
俺もちゃんと>>691で
> もちろんDBUtilsがリリースされたから今後はそれを使うけど、
って書いてあるだろ？同じアイデアがJakartaでリリースされてるんなら
信頼性の面でそちらを使う事に依存はないよ。
時には>>719みたいにぽっと出のJakartaリリースよりも
俺様フレームワークが優れている時も往々にしてあったりするみたいだけど。
俺はJakartaに現在存在しないナイスアイデアを、現場の人間が思いついても
理解のない上司によって捨て去られる事が悲しいって言ってるんだよ。
まとめると
俺の上司は「Jakarta製品だけを使え。自分のアイデアは捨てろ」で
俺は「Jakarta製品は使うけど、Jakartaにないナイスアイデアを思いついたらそれも積極的に使おうぜ」
っていうスタンスなんだよ。
お前は馬鹿の一つ覚えみたいにEclipse,Ant,Maven,Findbugs,Checkstyleって言ってる奴だろうけど、
俺はそーゆープロダクトを使うのも賛成だが、
お前はもうちょっとプログラムそのものについても深く考えたほうがいいんじゃないかと思うぜ。
俺もちゃんと>>691で
> もちろんDBUtilsがリリースされたから今後はそれを使うけど、
って書いてあるだろ？同じアイデアがJakartaでリリースされてるんなら
信頼性の面でそちらを使う事に依存はないよ。
時には>>719みたいにぽっと出のJakartaリリースよりも
俺様フレームワークが優れている時も往々にしてあったりするみたいだけど。
俺はJakartaに現在存在しないナイスアイデアを、現場の人間が思いついても
理解のない上司によって捨て去られる事が悲しいって言ってるんだよ。
まとめると
俺の上司は「Jakarta製品だけを使え。自分のアイデアは捨てろ」で
俺は「Jakarta製品は使うけど、Jakartaにないナイスアイデアを思いついたらそれも積極的に使おうぜ」
っていうスタンスなんだよ。
お前は馬鹿の一つ覚えみたいにEclipse,Ant,Maven,Findbugs,Checkstyleって言ってる奴だろうけど、
俺はそーゆープロダクトを使うのも賛成だが、
お前はもうちょっとプログラムそのものについても深く考えたほうがいいんじゃないかと思うぜ。
>俺はJakartaに現在存在しないナイスアイデアを、現場の人間が思いついても
>理解のない上司によって捨て去られる事が悲しいって言ってるんだよ。
ナイスアイデアの成果を保守する体制がねえ…
Jakartaなら当分Jakartaがある程度保守してくれるだろうけどさ…
ｱﾅﾀのナイスアイデアをSourceforgeで公開して、オプソの好事家に
メンテをお願いしてみてはいかがでしょうか。
>理解のない上司によって捨て去られる事が悲しいって言ってるんだよ。
ナイスアイデアの成果を保守する体制がねえ…
Jakartaなら当分Jakartaがある程度保守してくれるだろうけどさ…
ｱﾅﾀのナイスアイデアをSourceforgeで公開して、オプソの好事家に
メンテをお願いしてみてはいかがでしょうか。
>>850
・・・、いや単純に車輪の再生産をしないために処理を一つの関数
に纏めるという処理を提案した所蹴られて、結局導入したライブラリー
でも同じ処理をしていたという落ちなんだが・・・。
つまり、共通化できうるロジックを蹴って後から導入したライブラリー
で後付でロジックの共通化が 結果的に 反映されたっつー事を言いたかった
と思うぞ。
無論、ライブラリーでの導入と独自のロジックによるコスト計算は無視
しての話だが。
・・・、いや単純に車輪の再生産をしないために処理を一つの関数
に纏めるという処理を提案した所蹴られて、結局導入したライブラリー
でも同じ処理をしていたという落ちなんだが・・・。
つまり、共通化できうるロジックを蹴って後から導入したライブラリー
で後付でロジックの共通化が 結果的に 反映されたっつー事を言いたかった
と思うぞ。
無論、ライブラリーでの導入と独自のロジックによるコスト計算は無視
しての話だが。
Java厨は車輪につぶされる線路の砂利
865 ：仕様書無しさん：2005/12/28(水) 19:26:21
オープンソースのモジュールを修正して使うってのは、はっきり言って止めた方がいい。
使うか使わないかどちらかにしてくれ。
Strutsを改造した怪しいフレームワークを使わされた事があったが、非常に困った。
Strutsの経験は役に立たないし、客の要望も半端にしか実現出来ないし、
無駄なコードは増えるし、バージョンアップどころか、再インストールで動かなくなるし。
で製造工程でいなくなったくせに、改造フレームワークを自慢するのは止めてくれ、マジで。
使うか使わないかどちらかにしてくれ。
Strutsを改造した怪しいフレームワークを使わされた事があったが、非常に困った。
Strutsの経験は役に立たないし、客の要望も半端にしか実現出来ないし、
無駄なコードは増えるし、バージョンアップどころか、再インストールで動かなくなるし。
で製造工程でいなくなったくせに、改造フレームワークを自慢するのは止めてくれ、マジで。
866 ：仕様書無しさん：2005/12/28(水) 19:27:39
>864
どういう意味？
どういう意味？
867 ：仕様書無しさん：2005/12/28(水) 19:30:18
どうしてネィテブコンパイルしないんだ？
そんなことVBですらできるぞ
そんなことVBですらできるぞ
868 ：仕様書無しさん：2005/12/28(水) 20:43:03
そうだ！
バイトコードをネィティブにコンパイルして、JVM無しでも実行できるようにする
ツールを開発したら売れるんじゃないか？
バイトコードをネィティブにコンパイルして、JVM無しでも実行できるようにする
ツールを開発したら売れるんじゃないか？
870 ：仕様書無しさん：2005/12/28(水) 22:21:38
>>868
んなもん、すでにあるわけだが。もちろんただ。
んなもん、すでにあるわけだが。もちろんただ。
すげえ！なんていうの？
>>861
基本的には同意なんだが、俺としては更にもう一歩先を主張したい。
今の役職者はオープンソースをソース付きフリーウェア(無料ソフト)だと思ってる。
参加しようという意識が全くない。
置き換えを命じられたコンフィギュレーションフレームワークには、Commonsにコ
ントリブできる部分やソースコード付きでプロポーズできる部分が有った。
オープンソースプロジェクトとして立ち上げてみるのも面白そうだった(会社の紐付
きでも業務外として俺個人でもどっちでも構わなかった)のに、全部丸ごと握り潰さ
れた。
別に俺は我侭で言ってるわけじゃない。もしそれがCommonsに採用されるなりオ
ープンソースプロジェクトとして認知されるなりすれば、それは自社の良いアピー
ルになるだろうし、更に何らかの幸運が重なって発展していけば、最少の手数で
希望の実装が手に入るという奇跡まで得られたのに・・・・・・
今の役職者には、そういう部分が全く見えてないんだよな。
そのくせ「最近Seasarとかいう日本発のオープンソースプロジェクトがあるらしい
な。お前らの中にはアレくらいの仕事ができる奴は居ないのか？」とか言いやが
る。それを潰してるのはお前だっつ～の！！！orz
基本的には同意なんだが、俺としては更にもう一歩先を主張したい。
今の役職者はオープンソースをソース付きフリーウェア(無料ソフト)だと思ってる。
参加しようという意識が全くない。
置き換えを命じられたコンフィギュレーションフレームワークには、Commonsにコ
ントリブできる部分やソースコード付きでプロポーズできる部分が有った。
オープンソースプロジェクトとして立ち上げてみるのも面白そうだった(会社の紐付
きでも業務外として俺個人でもどっちでも構わなかった)のに、全部丸ごと握り潰さ
れた。
別に俺は我侭で言ってるわけじゃない。もしそれがCommonsに採用されるなりオ
ープンソースプロジェクトとして認知されるなりすれば、それは自社の良いアピー
ルになるだろうし、更に何らかの幸運が重なって発展していけば、最少の手数で
希望の実装が手に入るという奇跡まで得られたのに・・・・・・
今の役職者には、そういう部分が全く見えてないんだよな。
そのくせ「最近Seasarとかいう日本発のオープンソースプロジェクトがあるらしい
な。お前らの中にはアレくらいの仕事ができる奴は居ないのか？」とか言いやが
る。それを潰してるのはお前だっつ～の！！！orz
日本語勉強しなおして来い
オプソなんて流行らないからやめておけ。後3年も持たないぞ
税金投入されなくなったら日本じゃ誰も使わない。ゴミになるだけ
税金投入されなくなったら日本じゃ誰も使わない。ゴミになるだけ
http://www.get-u.com/
重すぎ。CGIのころは軽かったのに。
重すぎ。CGIのころは軽かったのに。
877 ：仕様書無しさん：2005/12/29(木) 16:50:40
オープンソースを積極的に使うのは構わないが、無理に参加する必要はないだろう。
技術と時間のある奴がやればいいんだよ。
半端な奴が作ったのを雑誌が取り上げて、偽コンサルの目に入ったらどうする。
技術と時間のある奴がやればいいんだよ。
半端な奴が作ったのを雑誌が取り上げて、偽コンサルの目に入ったらどうする。
>>872
仕事とプライベートの区別くらいちゃんとつけろ。
仕事とプライベートの区別くらいちゃんとつけろ。
879 ：仕様書無しさん：2005/12/29(木) 17:23:55
「最近Seasarとかいう日本発のオープンソースプロジェクトがあるらしいな。
お前らの中にはアレくらいの仕事ができる奴は居ないのか？」
「半年有給休暇をくれれば作ります。」
と言ってやれ。
お前らの中にはアレくらいの仕事ができる奴は居ないのか？」
「半年有給休暇をくれれば作ります。」
と言ってやれ。
>>878
最近ははてなみたいに区別があいまいな企業が注目されてるけどな
最近ははてなみたいに区別があいまいな企業が注目されてるけどな
881 ：仕様書無しさん：2005/12/29(木) 18:31:10
Javaが重いって、いつの時代の話をしてるんだ？
爺ども
爺ども
Javaが重いというよりJavaで構築されたサイトが重い。
軽く作れるはずなのにオブジェクト指向のせいで重くなる。
Webにオブジェクト指向は不向き。
軽く作れるはずなのにオブジェクト指向のせいで重くなる。
Webにオブジェクト指向は不向き。
883 ：仕様書無しさん：2005/12/29(木) 18:35:34
Javaは重いし、おろうなミンチーのような馬鹿が
糞コードでさらに重くするんだなこれが
糞コードでさらに重くするんだなこれが
昔よりは重く感じないが軽いとはいえねぇ。
大抵マシンスペックをさらすと貧乏人ってくるんだよ。Java厨は。
大抵マシンスペックをさらすと貧乏人ってくるんだよ。Java厨は。
885 ：仕様書無しさん：2005/12/29(木) 19:20:18
このスレは携帯開発者の怨念が渦巻いているな
886 ：仕様書無しさん：2005/12/29(木) 19:31:41
貧乏人とオブジェクト指向が理解できないバカ収容所
887 ：仕様書無しさん：2005/12/29(木) 20:02:35 BE:23175348-
C言語だよ今の時代。
プレステとかにも使われてるだろ？
プレステとかにも使われてるだろ？
888 ：仕様書無しさん：2005/12/29(木) 20:05:05
おまえあほ
890 ：仕様書無しさん：2005/12/29(木) 21:17:59
これはJavaなんだけどすごいとオモタ
http://media.spikedhumor.com/8944/Jingle_Bells_Reversed.swf
クリスマスソングを逆転して聴くとこんなメッセージが隠されていたとは・・・
http://media.spikedhumor.com/8944/Jingle_Bells_Reversed.swf
クリスマスソングを逆転して聴くとこんなメッセージが隠されていたとは・・・
>>890
Javaじゃないし心理的ブラクラ
Javaじゃないし心理的ブラクラ
892 ：仕様書無しさん：2005/12/29(木) 22:15:05
ログインもActiveXだっけ？？？？？？？？？
いいかげんなこというなよ。
いいかげんなこというなよ。
Javaのせいじゃねえよ。バカ。ソースもってこい。
895 ：仕様書無しさん：2005/12/29(木) 22:31:17
おい。Java厨ども。
マジで正月に何とかできなかったら、来年には完全に破綻するぞマジで。
今頃はﾃﾞｽﾏでレスする余裕も無いだろうがなｗｗｗｗｗｗｗ
マジで正月に何とかできなかったら、来年には完全に破綻するぞマジで。
今頃はﾃﾞｽﾏでレスする余裕も無いだろうがなｗｗｗｗｗｗｗ
>>874
Commonsに取り込んでもらうのは難しいかもしれないが、独自にオープン
ソースとして公開するだけなら別に敷居は高くない。
>>877
独自ライブラリがある時点においてオプソなライブラリより高品質多機能
だったとしても、自分自身のリソースを殆ど消費する事なく何処かの誰か
によって保守され拡張されていくオプソなライブラリとは競争にならない。
特定の独自ライブラリや独自フレームワークをオプソ化するのに、大した
技術や時間は要らない。
オプソ化して、それを面白いと感じて参加してくれる人が現れれば御の字
だし、誰からも相手にされなくて結局自分独りで保守する事になったとして
も、それはオプソ化しなかった場合と同じってだけで特に何も失ってない。
俺はやっぱりオプソは使うものではなく参加するものだと思うね。
>>879
「貴方がオープンソースの意味と利点を理解して、公開の許可をくれさえ
すれば、公開可能なライブラリやフレームワークは既に幾つか存在して
ます。」と言いたいｗ
Commonsに取り込んでもらうのは難しいかもしれないが、独自にオープン
ソースとして公開するだけなら別に敷居は高くない。
>>877
独自ライブラリがある時点においてオプソなライブラリより高品質多機能
だったとしても、自分自身のリソースを殆ど消費する事なく何処かの誰か
によって保守され拡張されていくオプソなライブラリとは競争にならない。
特定の独自ライブラリや独自フレームワークをオプソ化するのに、大した
技術や時間は要らない。
オプソ化して、それを面白いと感じて参加してくれる人が現れれば御の字
だし、誰からも相手にされなくて結局自分独りで保守する事になったとして
も、それはオプソ化しなかった場合と同じってだけで特に何も失ってない。
俺はやっぱりオプソは使うものではなく参加するものだと思うね。
>>879
「貴方がオープンソースの意味と利点を理解して、公開の許可をくれさえ
すれば、公開可能なライブラリやフレームワークは既に幾つか存在して
ます。」と言いたいｗ
897 ：仕様書無しさん：2005/12/30(金) 00:11:02
重いとか抽象的なのもうやめましょうよ。
以下のＪavaとＣの処理の違いだけを整理して、あとは各自どちらが早いのか信じればいいのです。
<JAVA>
①バイトコードをＪａｖａＶＭが実行：ＪＩＴコンパイル（ネイティブコードを生成）
②ネイティブコードをＣＰＵ（ハードウエウ）が実行
＜Ｃ＞
①ネイティブコードをＣＰＵ（ハードウエア）が実行
以下のＪavaとＣの処理の違いだけを整理して、あとは各自どちらが早いのか信じればいいのです。
<JAVA>
①バイトコードをＪａｖａＶＭが実行：ＪＩＴコンパイル（ネイティブコードを生成）
②ネイティブコードをＣＰＵ（ハードウエウ）が実行
＜Ｃ＞
①ネイティブコードをＣＰＵ（ハードウエア）が実行
信仰の問題じゃないし、ネイティブより早いと思ってるカスは針でくれ。
針でくれって何だべ？
Javaの息づかいを感じていれば、Cより速くなるはずだ。
どんなにいい事いってもJavaは遅いのには変わりない。
同じような事をしている.Netより明らかに遅い時点で終わってる。
どんな環境でも同様に動作可能なことよりパフォーマンス重視した
サイト構築できないJavaは06年に廃業して欲しいよ。
同じような事をしている.Netより明らかに遅い時点で終わってる。
どんな環境でも同様に動作可能なことよりパフォーマンス重視した
サイト構築できないJavaは06年に廃業して欲しいよ。
クライアントアプリでも全然使えない。速くなったといっても
結局JavaVMのバージョンアップはユーザー側の仕事なので
かならずしもユーザーが最新のVMをインストールしてくれてる
とは限らない。
結局JavaVMのバージョンアップはユーザー側の仕事なので
かならずしもユーザーが最新のVMをインストールしてくれてる
とは限らない。
903 ：仕様書無しさん：2005/12/30(金) 06:13:23
JavaがCより速い場合があることは、様々なサイトで言及されてるよ。
このスレのあほどもには現実を見ていないか
情報収集能力が90年代から停滞している爺だろ。
このスレのあほどもには現実を見ていないか
情報収集能力が90年代から停滞している爺だろ。
>>903
ソースキボン。
ソースキボン。
色々な業務があって、色々なプロジェクトがあって、
色々な事情を抱えていて、色々な予算枠がある。
その中で最適なものを選べばよい。
速さを要求されるＰＪがあってＪａｖａで実現できないのであれば、
Ｊａｖａ以外を選択すればいい。
ただそれだけのこと。
色々な事情を抱えていて、色々な予算枠がある。
その中で最適なものを選べばよい。
速さを要求されるＰＪがあってＪａｖａで実現できないのであれば、
Ｊａｖａ以外を選択すればいい。
ただそれだけのこと。
906 ：仕様書無しさん：2005/12/30(金) 09:29:10
それを実現するのがプロ
javaの遅さはなんでもかんでもヒープにオブジェクト作成することからだろう
909 ：仕様書無しさん：2005/12/30(金) 10:33:00
インスタンスを使いまわせば無問題。
こんなのはFAQだよ。初心者君。
こんなのはFAQだよ。初心者君。
ローカルスコープの中でしか使わないものをヒープに取る愚
それをグローバルに使いまわそうとする愚
それをグローバルに使いまわそうとする愚
911 ：仕様書無しさん：2005/12/30(金) 10:52:09
C厨のグローバル変数を馬鹿にするくせに
JAVAの全体グローバル操作な仕様に気づいていない
馬鹿JAVA厨
それはおろうなミンチーw
JAVAの全体グローバル操作な仕様に気づいていない
馬鹿JAVA厨
それはおろうなミンチーw
言われてみればそうだな。
インスタンスをヒープにしか取れないってことは全てのインスタンスが
グローバルに存在するってことだもんな。
ただ、それへの参照をローカルにしてるってだけで。
インスタンスをヒープにしか取れないってことは全てのインスタンスが
グローバルに存在するってことだもんな。
ただ、それへの参照をローカルにしてるってだけで。
>>908-910
今時のガベコレがそのような物が問題になることは無いよ、
アセンブラが分かるなら、メモリーをスタック上にとるにしてもまずspを更新してスタックフレームを作るだろ。
そこでスタックフレーム相対のアドレスとしてローカルスコープのメモリとして認識する。
この工程と今すぐ確保可能なメモリー領域の先頭を取得する速度は殆ど変わらない。
もし、ローカルスコープを超えて生き延びたらその時点で長期生存オブジェクトとして認識する。
なら速いかといえばそうでもない、もっと別なところにメモリーアクセスの遅さの原因があるんだよ。
ただしちょっと君らには難解だろう、まあ勉強することだ。
今時のガベコレがそのような物が問題になることは無いよ、
アセンブラが分かるなら、メモリーをスタック上にとるにしてもまずspを更新してスタックフレームを作るだろ。
そこでスタックフレーム相対のアドレスとしてローカルスコープのメモリとして認識する。
この工程と今すぐ確保可能なメモリー領域の先頭を取得する速度は殆ど変わらない。
もし、ローカルスコープを超えて生き延びたらその時点で長期生存オブジェクトとして認識する。
なら速いかといえばそうでもない、もっと別なところにメモリーアクセスの遅さの原因があるんだよ。
ただしちょっと君らには難解だろう、まあ勉強することだ。
いや、速度の問題じゃなくてスコープの話だろ。
915 ：仕様書無しさん：2005/12/30(金) 11:30:45
どうでもいいがJAVAは死滅確定だな
916 ：仕様書無しさん：2005/12/30(金) 11:35:12
Javaがスタックを使ってないって、C厨は本当にバカだな。
もうアルツハイマーなんだろうな。
教えてやるよ。タダでいいよ。
JVMはスタックマシンなんだ。よく覚えておけ。
もうアルツハイマーなんだろうな。
教えてやるよ。タダでいいよ。
JVMはスタックマシンなんだ。よく覚えておけ。
よしんばJavaがCと同等の速度で動くとしても、Javaが起動する前にCは仕事を終えているだろう。
918 ：仕様書無しさん：2005/12/30(金) 11:57:46
919 ：仕様書無しさん：2005/12/30(金) 12:48:57
Java厨ってなぜか起動時間をカウントにいれないんだよなあw
だって、サーバは一回起動すれば終わりだから。
921 ：仕様書無しさん：2005/12/30(金) 12:58:50
重いとか抽象的なのもうやめましょうよ。
以下のＪavaとＣの処理の違いだけを認識して、適材適所で使い分ければいいのです。
（もちろん、開発の効率性とかマルチプラットフォーム対応へのメリット、セキュリティは別スレで。
ここでの議論は、Javaは他の言語と比較して重いか？という実行速度の問題にフォーカスしてるということは忘れないで）
<JAVA>
①バイトコードをＪａｖａＶＭが実行：ＪＩＴコンパイル（ネイティブコードを生成）
②ネイティブコードをＣＰＵ（ハードウエウ）が実行
＜Ｃ＞
①ネイティブコードをＣＰＵ（ハードウエア）が実行
以下のＪavaとＣの処理の違いだけを認識して、適材適所で使い分ければいいのです。
（もちろん、開発の効率性とかマルチプラットフォーム対応へのメリット、セキュリティは別スレで。
ここでの議論は、Javaは他の言語と比較して重いか？という実行速度の問題にフォーカスしてるということは忘れないで）
<JAVA>
①バイトコードをＪａｖａＶＭが実行：ＪＩＴコンパイル（ネイティブコードを生成）
②ネイティブコードをＣＰＵ（ハードウエウ）が実行
＜Ｃ＞
①ネイティブコードをＣＰＵ（ハードウエア）が実行
そうして、いつのまにか起動の遅いWindows+IISよりはるかに起動に
時間を要するLinuxサーバを作り上げるJAVA厨なのであった。
7～8年前に「winは起動が遅いから糞！linuxなら一瞬！」と言っていたことは
すっかり忘れてしまって。
時間を要するLinuxサーバを作り上げるJAVA厨なのであった。
7～8年前に「winは起動が遅いから糞！linuxなら一瞬！」と言っていたことは
すっかり忘れてしまって。
IIS最強だよね
いやトレンドはVMWareの上にLinux仕立ててJavaる真性マゾだろｗｗ
檻の中の箱庭だなｗｗｗｗ
>>922
iisサービスの起動時間=tomcat/J2EEコンテナサービスの起動時間。
ほとんど変わらない。
ただ、Javaは構成上、strutsのような巨大configファイルをローディングするため、
Webアプリの起動に時間が掛かる・・・。
と、思ってたら.netで同じくらい起動に時間が掛かるまるでJavaのようなデザインの
Webアプリを作る羽目になりましたとさ。
各Webアプリの起動にかかる時間を考えれば、サービスの起動時間なんてないようなもの。
まあ、よくよくJavaの真似をするように出来てるよな、.net。
これだけJavaにそっくりだと、さすがのMS盲信者も拒否反応がでるかと思いきや。
どっこい、MSが出すものになら、よろこんで飼いならされるんだから、他に選択肢がない人間は大変だよな。
iisサービスの起動時間=tomcat/J2EEコンテナサービスの起動時間。
ほとんど変わらない。
ただ、Javaは構成上、strutsのような巨大configファイルをローディングするため、
Webアプリの起動に時間が掛かる・・・。
と、思ってたら.netで同じくらい起動に時間が掛かるまるでJavaのようなデザインの
Webアプリを作る羽目になりましたとさ。
各Webアプリの起動にかかる時間を考えれば、サービスの起動時間なんてないようなもの。
まあ、よくよくJavaの真似をするように出来てるよな、.net。
これだけJavaにそっくりだと、さすがのMS盲信者も拒否反応がでるかと思いきや。
どっこい、MSが出すものになら、よろこんで飼いならされるんだから、他に選択肢がない人間は大変だよな。
927 ：仕様書無しさん：2005/12/30(金) 13:12:23
不思議なのはこれだけ開発環境が悪いJavaでも
なぜか擁護する厨がいる事だ。マゾ説はあたりなのかも。
なぜか擁護する厨がいる事だ。マゾ説はあたりなのかも。
928 ：仕様書無しさん：2005/12/30(金) 13:13:30
ただのものなら、よろこんで飼いならされるんだから、他に選択肢がないJava厨は大変だよな
Javaより速いからな。
930 ：仕様書無しさん：2005/12/30(金) 13:16:56
Port 80番の性能だけでもApacheよりIISのほうがレスポンスが良い
931 ：仕様書無しさん：2005/12/30(金) 13:19:53
.NETなんてどうでもいいし関心ないし。
とりあえずこのスレではあまり話題にすらなってないのに突然語りだす不思議。
とりあえずこのスレではあまり話題にすらなってないのに突然語りだす不思議。
932 ：仕様書無しさん：2005/12/30(金) 13:21:04
ネイティブに激しいコンプレックスがあるからなw
マルチプロセッサになるとさらに差がでる。＜IISとApache
Delphiが最強（だった）
935 ：仕様書無しさん：2005/12/30(金) 13:24:12
>tomcat/J2EEコンテナサービス
おいおいせめてWASとか金のかかるJ2EEコンテナを言ってくれよw
ほんとうに乞食しかいねえなw
おいおいせめてWASとか金のかかるJ2EEコンテナを言ってくれよw
ほんとうに乞食しかいねえなw
IIS + ISAPI
これは速い。マジで。自分的にはNAのGTOより速いので大満足です。
これは速い。マジで。自分的にはNAのGTOより速いので大満足です。
937 ：69式フリーPG ◆hND3Lufios ：2005/12/30(金) 13:32:10
漢なら黙ってgccでApache modue
938 ：仕様書無しさん：2005/12/30(金) 13:33:15
IIS + ISAPI 最強だな
ISAPIはなんせdllだからなー。IISのプロセス内でIISのスレッドで動くんだもの。
そりゃ速いよ。
そりゃ速いよ。
940 ：仕様書無しさん：2005/12/30(金) 13:46:52
ISAPIと対極にあるのがJAVA
941 ：仕様書無しさん：2005/12/30(金) 13:50:52
Java厨もISAPIに話がおよぶと音なしか
理解の範疇はせいぜい.NETあたりまでだろうからな
理解の範疇はせいぜい.NETあたりまでだろうからな
943 ：仕様書無しさん：2005/12/30(金) 14:03:05
CGIベースのC++と比較だろ、それでも信憑性はあまりないがw
Java側はクラスオブジェクトをヒープに読み込んだ後の比較だろうがどうせ
捏造されたスペックに喜ぶ前にJavaで作成されたクライアントツールの
起動時間を5秒以内にしてくれよ。そうしたら認めてやるってば。
ISAPIと比較すればすべて糞でなJAVA、古臭い仕様のまま遅くなるばかり。
Java側はクラスオブジェクトをヒープに読み込んだ後の比較だろうがどうせ
捏造されたスペックに喜ぶ前にJavaで作成されたクライアントツールの
起動時間を5秒以内にしてくれよ。そうしたら認めてやるってば。
ISAPIと比較すればすべて糞でなJAVA、古臭い仕様のまま遅くなるばかり。
944 ：仕様書無しさん：2005/12/30(金) 14:10:00
なんかスペック信じて実際を知らず
仏作って魂いれずみたいだな
またはカタログ馬鹿でカタログスペックで買い物する能無し
仏作って魂いれずみたいだな
またはカタログ馬鹿でカタログスペックで買い物する能無し
確かJava1.6あたりで1VMで複数のアプリ動かせるようになるんだよな？
IEみたいに事前にOSに組み込まれててロードされてるから
起動が早いのなんて糞の自慢にもならねぇのに。
これでJavaが早くなったと粋がる奴らが目に見えるようだ。
IEみたいに事前にOSに組み込まれててロードされてるから
起動が早いのなんて糞の自慢にもならねぇのに。
これでJavaが早くなったと粋がる奴らが目に見えるようだ。
946 ：仕様書無しさん：2005/12/30(金) 14:22:26
もとがひどく遅いのになれているから
劇速に感じるのだろう
劇速に感じるのだろう
自慢にはならないが
起動が遅いのは十分な欠点
起動が遅いのは十分な欠点
949 ：仕様書無しさん：2005/12/30(金) 15:05:30
起動が遅い=サーバ上でのパフォーマンスも悪い
name c++ javaclient javaserver
-----------------------------------------------------------------
ackermann(3,13) 15933 322302 . 480864
fibo(30) 69648 371089 . 542648
heapsort(1000000) . . . 1402123 . 3001098 2964444
matrix(100000) 17408078 64457672 40367229
methcall(1000000000) 29113603 . 52042542 6168848
nestedloop(45) . 17175 93347307 40207018
objinst(100000000) . 110759902 21699965 20930075
random(300000000) .. 29836747 85348630 . 49170631
strcat(5000000) . 1141440 3563221 3264548
sumcol < sumcol-in 1690210 2078145 1891243
wc .. 21854 327249 . 500687
いくつかベンチマークを走らせて見た。
VC8はやｗJava1.5おそｗ
-----------------------------------------------------------------
ackermann(3,13) 15933 322302 . 480864
fibo(30) 69648 371089 . 542648
heapsort(1000000) . . . 1402123 . 3001098 2964444
matrix(100000) 17408078 64457672 40367229
methcall(1000000000) 29113603 . 52042542 6168848
nestedloop(45) . 17175 93347307 40207018
objinst(100000000) . 110759902 21699965 20930075
random(300000000) .. 29836747 85348630 . 49170631
strcat(5000000) . 1141440 3563221 3264548
sumcol < sumcol-in 1690210 2078145 1891243
wc .. 21854 327249 . 500687
いくつかベンチマークを走らせて見た。
VC8はやｗJava1.5おそｗ
952 ：69式フリーPG ◆hND3Lufios ：2005/12/30(金) 15:24:11
VCは速いよ。
Win上でならIntel C++の次に速いのがVCかな。
Win上でならIntel C++の次に速いのがVCかな。
953 ：仕様書無しさん：2005/12/30(金) 15:26:11
954 ：仕様書無しさん：2005/12/30(金) 15:30:57
Javaクライアントよりも劇的に速くないんだな
糞サーバってw
糞サーバってw
956 ：仕様書無しさん：2005/12/30(金) 15:36:39
Object creationがC++よりも3倍以上速いなんてどっちが捏造だかw
957 ：仕様書無しさん：2005/12/30(金) 15:45:50
>>951
なんだそりゃ。大きいほうが速いのかｗｗｗｗｗ
なんだそりゃ。大きいほうが速いのかｗｗｗｗｗ
>>957
単位はマイクロ病。小さい方が速い
単位はマイクロ病。小さい方が速い
959 ：仕様書無しさん：2005/12/30(金) 15:48:35
こんなとこで油売ってないでチューニングに精を出せ。
正月明けにパフォーマンスが改善されてなかったら大問題だからな。
わかったな。
正月明けにパフォーマンスが改善されてなかったら大問題だからな。
わかったな。
961 ：69式フリーPG ◆hND3Lufios ：2005/12/30(金) 15:58:55
ところで、lighttpdについて詳しい日本語サイト無いかな。
963 ：仕様書無しさん：2005/12/30(金) 16:45:05
Cでも初期化時にビッグバッファ割り当てて
再配置ロジック使えばもっと高速
再配置ロジック使えばもっと高速
964 ：仕様書無しさん：2005/12/30(金) 16:49:11
ようするにC++の負けなんだろ？
素直に認めて、謝罪すべきところは謝罪すべきじゃないか。
C++のほうがおそかったです。申し訳ありません。反省しています。
これを教訓として真摯に受け止め、これからは謙虚に書き込むことを心がけたいと誓います。
と書け。人として恥ずかしいぞ。
素直に認めて、謝罪すべきところは謝罪すべきじゃないか。
C++のほうがおそかったです。申し訳ありません。反省しています。
これを教訓として真摯に受け止め、これからは謙虚に書き込むことを心がけたいと誓います。
と書け。人として恥ずかしいぞ。
言語としての本質の仕様部分と、そういう小手先を同列に語ったら切が無い。
966 ：仕様書無しさん：2005/12/30(金) 17:09:36
重いとか抽象的なのもうやめましょうよ。
ＪavaとＣの処理の違いだけを認識して、適材適所で使い分ければいいのです。
（もちろん、開発の効率性とかマルチプラットフォーム対応へのメリット、セキュリティは別スレで。
ここでの議論は、Javaは他の言語と比較して重いか？という実行速度の問題にフォーカスしてるということは忘れないで）
<JAVA>
①バイトコードをＪａｖａＶＭが実行：ＪＩＴコンパイル（ネイティブコードを生成）
②ネイティブコードをＣＰＵ（ハードウエウ）が実行
＜Ｃ＞
①ネイティブコードをＣＰＵ（ハードウエア）が実行
★英語をしゃべれるＡさんと会話するのに下の①と②どちらが会話の進行がはやいと思いますか？
①英語を話せるＢさんが直接英語でＡさんと話す。
②英語を話せないＣさんが日本語を話し、Ｄさんという翻訳者を通じてＡさんと話す。
以上です。
ＪavaとＣの処理の違いだけを認識して、適材適所で使い分ければいいのです。
（もちろん、開発の効率性とかマルチプラットフォーム対応へのメリット、セキュリティは別スレで。
ここでの議論は、Javaは他の言語と比較して重いか？という実行速度の問題にフォーカスしてるということは忘れないで）
<JAVA>
①バイトコードをＪａｖａＶＭが実行：ＪＩＴコンパイル（ネイティブコードを生成）
②ネイティブコードをＣＰＵ（ハードウエウ）が実行
＜Ｃ＞
①ネイティブコードをＣＰＵ（ハードウエア）が実行
★英語をしゃべれるＡさんと会話するのに下の①と②どちらが会話の進行がはやいと思いますか？
①英語を話せるＢさんが直接英語でＡさんと話す。
②英語を話せないＣさんが日本語を話し、Ｄさんという翻訳者を通じてＡさんと話す。
以上です。
コンパイラが小手先を使いまくった結果早くなりつつあるのがJavaだけどな。
はっきりいってGCのアルゴリズムとか進歩が遅すぎるぜ。
はっきりいってGCのアルゴリズムとか進歩が遅すぎるぜ。
>>966
CPU毎の最適化を抜かしてないか？
<Java>
そのCPUにとって最適なネイティブコードを生成
<C>
事前コンパイルする時に最大限サポートの多い命令セットを使用する（事が多い）
これはお前の言ってる英語の例えを使うなら
・現代人にはちゃんと現代の言葉で話しかける
・現代人にも何とか理解できる江戸時代の言葉で話しかける
って事になるんだが、どっちが話が早いと思いますか？
CPU毎の最適化を抜かしてないか？
<Java>
そのCPUにとって最適なネイティブコードを生成
<C>
事前コンパイルする時に最大限サポートの多い命令セットを使用する（事が多い）
これはお前の言ってる英語の例えを使うなら
・現代人にはちゃんと現代の言葉で話しかける
・現代人にも何とか理解できる江戸時代の言葉で話しかける
って事になるんだが、どっちが話が早いと思いますか？
最近、江戸時代の言葉で話しかけられることが多くて困る。
つーか、Linuxなんて現代の語彙がどんどん増えてる
今でも江戸時代でごり押ししてるプログラムがほとんどだからな。
ひどいやつなんてソースからコンパイルするときにわざわざi386アーキを選択しやがる。
最新の使え。
今でも江戸時代でごり押ししてるプログラムがほとんどだからな。
ひどいやつなんてソースからコンパイルするときにわざわざi386アーキを選択しやがる。
最新の使え。
973 ：仕様書無しさん：2005/12/30(金) 17:57:14
あのさあ、
虚しくない？
虚しくない？
プログラムなんて５年も動けば沢山。
３年しないうちに業務屋が次のアプリ作りませんか、ってな話をもってくら。
３年しないうちに業務屋が次のアプリ作りませんか、ってな話をもってくら。
975 ：仕様書無しさん：2005/12/30(金) 18:00:33
重いとか抽象的なのもうやめましょうよ。
ＪavaとＣの処理の違いだけを認識して、適材適所で使い分ければいいのです。
（もちろん、開発の効率性とかマルチプラットフォーム対応へのメリット、セキュリティは別スレで。
ここでの議論は、Javaは他の言語と比較して重いか？という実行速度の問題にフォーカスしてるということは忘れないで）
(>>569がいうようにＣでもコンパイルされた命令セットによって実行速度に違いがあるようなので、
以下のように”認識（整理）”してみました。くりかえしますが、この違いを認識して、適材適所で使い分ければいいのです。）
①<JAVA>
１．バイトコードをＪａｖａＶＭが実行：ＪＩＴコンパイル（ネイティブコードを生成） ※命令セットはＣＰＵに最適化されている。
２．最適化されているネイティブコードをＣＰＵ（ハードウエウ）が実行
②＜Ｃ＞ ：命令セットがＣＰＵに最適化されていない場合
１．ＣＰＵに最適化されていないネイティブコードをＣＰＵ（ハードウエア）が実行
③＜Ｃ＞ ：命令セットがＣＰＵに最適化されている場合
１．最適化されているネイティブコードをＣＰＵ（ハードウエア）が実行
★英語をしゃべれるＡさんと会話するのに下の①と②と③どちらが会話の進行がはやいと思いますか？
①英語を話せないＤさんが日本語を話し、Ｅさんという翻訳者を通じてＡさんと話す。
②ラテン語を話せるＣさんが直接英語でＡさんと話す。
③英語を話せるＢさんが直接英語でＡさんと話す。
以上です。
ＪavaとＣの処理の違いだけを認識して、適材適所で使い分ければいいのです。
（もちろん、開発の効率性とかマルチプラットフォーム対応へのメリット、セキュリティは別スレで。
ここでの議論は、Javaは他の言語と比較して重いか？という実行速度の問題にフォーカスしてるということは忘れないで）
(>>569がいうようにＣでもコンパイルされた命令セットによって実行速度に違いがあるようなので、
以下のように”認識（整理）”してみました。くりかえしますが、この違いを認識して、適材適所で使い分ければいいのです。）
①<JAVA>
１．バイトコードをＪａｖａＶＭが実行：ＪＩＴコンパイル（ネイティブコードを生成） ※命令セットはＣＰＵに最適化されている。
２．最適化されているネイティブコードをＣＰＵ（ハードウエウ）が実行
②＜Ｃ＞ ：命令セットがＣＰＵに最適化されていない場合
１．ＣＰＵに最適化されていないネイティブコードをＣＰＵ（ハードウエア）が実行
③＜Ｃ＞ ：命令セットがＣＰＵに最適化されている場合
１．最適化されているネイティブコードをＣＰＵ（ハードウエア）が実行
★英語をしゃべれるＡさんと会話するのに下の①と②と③どちらが会話の進行がはやいと思いますか？
①英語を話せないＤさんが日本語を話し、Ｅさんという翻訳者を通じてＡさんと話す。
②ラテン語を話せるＣさんが直接英語でＡさんと話す。
③英語を話せるＢさんが直接英語でＡさんと話す。
以上です。
確実なこと：
LinuxやJavaで実験されておまいらが人柱となった試みは
しばらくするとＭＳが取り込んで使い物になるようにしてくださる。
ああ、ありがたやありがたや。
LinuxやJavaで実験されておまいらが人柱となった試みは
しばらくするとＭＳが取り込んで使い物になるようにしてくださる。
ああ、ありがたやありがたや。
と、MS工作員が申しております。
978 ：仕様書無しさん：2005/12/30(金) 18:05:12
話を聞く気が毛頭なくて、結果が頭の中で確定しているだけの
馬鹿に、妄想に対する反論吐くのは、いくらそれが正論であって
も時間の無駄。
あんたら、現実でいくらでも経験積みでしょう…
馬鹿に、妄想に対する反論吐くのは、いくらそれが正論であって
も時間の無駄。
あんたら、現実でいくらでも経験積みでしょう…
何意味不明なこといっちゃってるの？
ぶっちゃけ、ハードウェアの限界が見え始めた昨今、これからはソフトウェアが
軽くなる方向で見直されると思う。
あと、マルチプロセッサ対応な。linuxはこれが致命的に駄目だ。
軽くなる方向で見直されると思う。
あと、マルチプロセッサ対応な。linuxはこれが致命的に駄目だ。
ハードはまだまだよくなると思うが・・・。
>>980
でもOSはどんどん重くなるんだよな・・・
でもOSはどんどん重くなるんだよな・・・
983 ：仕様書無しさん：2005/12/30(金) 18:49:44
>>982
MSのそれは単なる病気。OSを金儲けの道具にする発想の人たちの出力。
MSのそれは単なる病気。OSを金儲けの道具にする発想の人たちの出力。
984 ：仕様書無しさん：2005/12/30(金) 18:50:35
いや、プロセッサは限界に近い。
電子に頼っている限りこれ以上のクロックアップは無理。
電子に頼っている限りこれ以上のクロックアップは無理。
Redhatの6辺りとFedraを比較すれば、より重傷なのはLinux。
真面目にWindows ライト版作ってくれ。
987 ：仕様書無しさん：2005/12/30(金) 18:56:02
なんでOSはシンプルなコア＋選択可能で常に導入/削除可能なオプションという
形式にはならないんでしょうか？
形式にはならないんでしょうか？
988 ：仕様書無しさん：2005/12/30(金) 18:58:13
ということはJavaもこれが限界か。。。
あとはメモリをﾊﾞｼﾊﾞｼ積むしかないな。
あとはメモリをﾊﾞｼﾊﾞｼ積むしかないな。
そうかい？Winは2000あたりで歯止めがかかっているようだが。
>>989
えええ?XPProなんかイニシャルの使用量馬鹿でかいっすよ!?
えええ?XPProなんかイニシャルの使用量馬鹿でかいっすよ!?
それでも速いＩＩＳ
Tomcatほどじゃねえよ
993 ：仕様書無しさん：2005/12/30(金) 19:16:36
俺様がJavaを極めてニートを脱出しようともがくスレ
http://pc8.2ch.net/test/read.cgi/tech/1129883232/
http://pc8.2ch.net/test/read.cgi/tech/1129883232/
次スレは？
>>856
> >>852
> なんつうのかな・・・それがどうした？って思うよ。
> 基本的なコンパイルはEclipceで出来るし、大規模システムならば各自がやることではない。
プロジェクトにもよるがな。XDocletを使うならAntでbuild.xmlを自作する。
> ビルド手順などは管理者が考えることだ。
その管理者が理解できないことがあるんだよ。
実際に開発したものにしかわからない作りになっているとか。
もしビルドに失敗したときもっとも速くバグを究明し
直すことができる者は実際に開発に関わった者達だ。
> で、Antは知ってればそれはこしたことはないけど、じゃあ必須か？って思ったときに使うときに覚えれば十分と思うけどね。
サーバで動かすときは必須になることがある。
XDocletを使うなら間違いなく必須だが。
> >>852
> なんつうのかな・・・それがどうした？って思うよ。
> 基本的なコンパイルはEclipceで出来るし、大規模システムならば各自がやることではない。
プロジェクトにもよるがな。XDocletを使うならAntでbuild.xmlを自作する。
> ビルド手順などは管理者が考えることだ。
その管理者が理解できないことがあるんだよ。
実際に開発したものにしかわからない作りになっているとか。
もしビルドに失敗したときもっとも速くバグを究明し
直すことができる者は実際に開発に関わった者達だ。
> で、Antは知ってればそれはこしたことはないけど、じゃあ必須か？って思ったときに使うときに覚えれば十分と思うけどね。
サーバで動かすときは必須になることがある。
XDocletを使うなら間違いなく必須だが。
フレームワークにマンセーしてるやつらってさ、
使うだけで満足してる奴が多くないか？
「俺今最新の技術使っちゃってるよー！！」
て自己陶酔してる。
使うだけで満足してる奴が多くないか？
「俺今最新の技術使っちゃってるよー！！」
て自己陶酔してる。
>>861
> >>850
>
> お前は馬鹿の一つ覚えみたいにEclipse,Ant,Maven,Findbugs,Checkstyleって言ってる奴だろうけど、
> 俺はそーゆープロダクトを使うのも賛成だが、
> お前はもうちょっとプログラムそのものについても深く考えたほうがいいんじゃないかと思うぜ。
馬鹿の一つ覚え？ 当たり前のように頻繁に使っているものだが。
Checkstyleで警告を大量に出すコードはプログラマとしてサイテーだね。
言っておくが、CheckstyleやFindBugsを使えばプログラミングスキルも向上するぞ。
プログラムそのものについももちろん考えているぞ。
> >>850
>
> お前は馬鹿の一つ覚えみたいにEclipse,Ant,Maven,Findbugs,Checkstyleって言ってる奴だろうけど、
> 俺はそーゆープロダクトを使うのも賛成だが、
> お前はもうちょっとプログラムそのものについても深く考えたほうがいいんじゃないかと思うぜ。
馬鹿の一つ覚え？ 当たり前のように頻繁に使っているものだが。
Checkstyleで警告を大量に出すコードはプログラマとしてサイテーだね。
言っておくが、CheckstyleやFindBugsを使えばプログラミングスキルも向上するぞ。
プログラムそのものについももちろん考えているぞ。
>>872
> >>861
> 今の役職者はオープンソースをソース付きフリーウェア(無料ソフト)だと思ってる。
> 参加しようという意識が全くない。
> 別に俺は我侭で言ってるわけじゃない。もしそれがCommonsに採用されるなりオ
> ープンソースプロジェクトとして認知されるなりすれば、それは自社の良いアピー
> ルになるだろうし、更に何らかの幸運が重なって発展していけば、最少の手数で
> 希望の実装が手に入るという奇跡まで得られたのに・・・・・・
> 今の役職者には、そういう部分が全く見えてないんだよな。
まあなんと保守的で時代遅れな考えに縛られている会社なんでしょう。
とりあえず、オープンソース化を実行することによって
Eclipseの開発に関与しているIBMや日立、富士通のような成功事例を説明してみてはどうだろう。
そこの会社がプログラマというものをどういう人間だと思っているのか
気になるところだが。プログラマを使い捨て程度にしか思っていないなら
こちらから先回りだ。
面白い戦術がある。会社よりも先回りして自宅でライブラリを開発して
自分の名前を入れてSourceforgeに公開する。
Commonsなどにコントリビュータとしてパッチを送り続ける。
それでオープンソースプロジェクトに自分の名前を連ねておいて
それから自社にそのオープンソース製品を取り入れる。
そう簡単なことではないが、うまくいけば転職してもそのソフトを開発し続けることができる。
うまくいけば知名度が向上したことにより、
IBMや富士通などのオープンソース開発チームに加えさせて貰えるかも知れない。
オープンソース開発にうまく関われば自身がプログラマとして
使い捨てにされる可能性が大幅に下がること間違いなしだ。
JakartaやEclipse, GNUなら、まずは英語力を鍛えないといけないが。
> >>861
> 今の役職者はオープンソースをソース付きフリーウェア(無料ソフト)だと思ってる。
> 参加しようという意識が全くない。
> 別に俺は我侭で言ってるわけじゃない。もしそれがCommonsに採用されるなりオ
> ープンソースプロジェクトとして認知されるなりすれば、それは自社の良いアピー
> ルになるだろうし、更に何らかの幸運が重なって発展していけば、最少の手数で
> 希望の実装が手に入るという奇跡まで得られたのに・・・・・・
> 今の役職者には、そういう部分が全く見えてないんだよな。
まあなんと保守的で時代遅れな考えに縛られている会社なんでしょう。
とりあえず、オープンソース化を実行することによって
Eclipseの開発に関与しているIBMや日立、富士通のような成功事例を説明してみてはどうだろう。
そこの会社がプログラマというものをどういう人間だと思っているのか
気になるところだが。プログラマを使い捨て程度にしか思っていないなら
こちらから先回りだ。
面白い戦術がある。会社よりも先回りして自宅でライブラリを開発して
自分の名前を入れてSourceforgeに公開する。
Commonsなどにコントリビュータとしてパッチを送り続ける。
それでオープンソースプロジェクトに自分の名前を連ねておいて
それから自社にそのオープンソース製品を取り入れる。
そう簡単なことではないが、うまくいけば転職してもそのソフトを開発し続けることができる。
うまくいけば知名度が向上したことにより、
IBMや富士通などのオープンソース開発チームに加えさせて貰えるかも知れない。
オープンソース開発にうまく関われば自身がプログラマとして
使い捨てにされる可能性が大幅に下がること間違いなしだ。
JakartaやEclipse, GNUなら、まずは英語力を鍛えないといけないが。
1000 ：仕様書無しさん：2005/12/30(金) 21:32:25
おわり
1001 ：１００１：
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。
もう書けないので、新しいスレッドを立ててくださいです。。。