アカウント名:
パスワード:
もはや時代遅れ
Javaだからじゃなくってフレームワークの脆弱性なのでその他のフレームワークでも起こりえることなので言語のせいじゃありません
ここまで即死レベルで致命的な脆弱性が頻発するその他のフレームワークってありましたっけ。
http://jvndb.jvn.jp/ja/contents/2016/JVNDB-2016-001980.html [jvndb.jvn.jp]http://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-001320.html [jvndb.jvn.jp]とか
RCE系はコーディング上の問題が多いから・・・
「流行りの言語」って、どれもセキュリティは二の次というか、構造的にセキュリティホールが多いよね。同時にそれを習得するエンジニアは経験の浅い人たちなので二重に危険。
ゲームを作るんだったら「生産性の高い言語＋元気で安い若いエンジニア」の組み合わせは最強だと思うけど、ミッションクリティカルなシステムには適合しないかな。フレームワークを全否定するつもりはないけど、そのフレームワークが持つ特性を理解できて、中でどんな処理が行われてるのか想像できるレベルのエンジニアでないと・・・(それができれば少なくともStrutsを採用しようとは思わない)
Javaは生産性低いけどな
Javaが良いと思ってはいないが生産性が低いと言い切れるほど他に高い言語あるか？
言語の記法とかもあるがIDE(RAD)・ライブラリー・フレームワークの充実具合で差が出るし。
RPGツクールみたいに特定用途に特化しない限りはC#やJavaあたりが生産性ではトップクラスだと思うが。
馬鹿の一つ覚えのように.stream(笑)とか書かなくて済むKotlinの方が114514倍生産性高いよ。Scalaでもいいけど。だからみんなJava以外のJVM言語にとっくに切り替えてる。まだJavaを使ってるのはクソSIerぐらい。
114514倍とか書いてる時点で脳たりの中二病と言うことはよくわかった。1.2倍とか1.5倍とか書いてれば多少は説得力あったが。
改良されてるから多少の生産性の向上はあるがフレームワークの蓄積の差は埋められないぜ。
その生産性向上のフレームワークが穴になってるわけだが。
ハテナ多すぎる……。
たぶん文字化け(すっとぼけ)
おい、文字化けしてるぞ。
まったくこれだから新しいツールやフレームワークは使いたくないんだ。確かに１００％完成してれば高い効率を発揮するんだろうが、どいつもこいつも作りかけのアルファ版の域を出やがらねぇ。ちょっと突っ込んだことしようとすると「未実装」と「バグ」の嵐だ。枯れた環境なら誰かしら対策してるってのに。次から次へと新しいもの持ってくるからその度に一からやり直しだ。「技術の蓄積」ってのを何だと思ってやがんだろうね。
開発環境なぞ『C言語』で十分だっての。
それにしてもこの文字化けは酷いな。何書いてあるのかさっぱりわかんねぇ。何使って書けばこうなるんだ？おい、エディタはvi使えって言ってあっただろ。いろんな文字コードに対応したエディタなんて使うから文字化けすんだよ。とっかえひっかえ新しいツール試す暇があったらvi覚えろ。
# という先輩の小言を何十年も聞かされてきましたが何か？
今、IIS WebAPIでツールを作っているのですが、こちらは、★MVVMパターンで、HTMLのストリームを修正する度、ViewModelを静的に修正しないといけない ただし、ViewModelを静的に修正すれば、魔術的なRefrection?でバインドは全て自動。★（Data)Modelは、Code Firstでやっぱり静的。ですが、#3174677のWAFの方の記事を読む限り、Strutsでは、クラスローダーを多機能にし、★ブラウザ側からViewModelを動的に修正出来る。★ブラウザ側からControlerも動的に修正出来る。★（Data）Modelも修正出来そう。みたいです。 設計思想の違いだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
Javaなんか使うからこういうことになる (スコア:-1)
もはや時代遅れ
Re: (スコア:0)
Javaだからじゃなくってフレームワークの脆弱性なので
その他のフレームワークでも起こりえることなので言語のせいじゃありません
Re:Javaなんか使うからこういうことになる (スコア:0)
ここまで即死レベルで致命的な脆弱性が頻発するその他のフレームワークってありましたっけ。
Re: (スコア:0)
http://jvndb.jvn.jp/ja/contents/2016/JVNDB-2016-001980.html [jvndb.jvn.jp]
http://jvndb.jvn.jp/ja/contents/2013/JVNDB-2013-001320.html [jvndb.jvn.jp]
とか
RCE系はコーディング上の問題が多いから・・・
Re:Javaなんか使うからこういうことになる (スコア:1)
「流行りの言語」って、どれもセキュリティは二の次というか、構造的にセキュリティホールが多いよね。
同時にそれを習得するエンジニアは経験の浅い人たちなので二重に危険。
ゲームを作るんだったら「生産性の高い言語＋元気で安い若いエンジニア」の組み合わせは最強だと思うけど、
ミッションクリティカルなシステムには適合しないかな。
フレームワークを全否定するつもりはないけど、そのフレームワークが持つ特性を理解できて、中でどんな
処理が行われてるのか想像できるレベルのエンジニアでないと・・・
(それができれば少なくともStrutsを採用しようとは思わない)
Re: (スコア:0)
Javaは生産性低いけどな
Re: (スコア:0)
Javaが良いと思ってはいないが
生産性が低いと言い切れるほど他に高い言語あるか？
言語の記法とかもあるが
IDE(RAD)・ライブラリー・フレームワークの充実具合で差が出るし。
RPGツクールみたいに特定用途に特化しない限りは
C#やJavaあたりが生産性ではトップクラスだと思うが。
Re: (スコア:0)
馬鹿の一つ覚えのように.stream(笑)とか書かなくて済むKotlinの方が114514倍生産性高いよ。Scalaでもいいけど。
だからみんなJava以外のJVM言語にとっくに切り替えてる。まだJavaを使ってるのはクソSIerぐらい。
Re: (スコア:0)
114514倍とか書いてる時点で脳たりの中二病と言うことはよくわかった。
1.2倍とか1.5倍とか書いてれば多少は説得力あったが。
改良されてるから多少の生産性の向上はあるが
フレームワークの蓄積の差は埋められないぜ。
その生産性向上のフレームワークが穴になってるわけだが。
Re: (スコア:0)
ハテナ多すぎる……。
Re: (スコア:0)
たぶん文字化け(すっとぼけ)
Re: (スコア:0)
おい、文字化けしてるぞ。
まったくこれだから新しいツールやフレームワークは使いたくないんだ。
確かに１００％完成してれば高い効率を発揮するんだろうが、
どいつもこいつも作りかけのアルファ版の域を出やがらねぇ。
ちょっと突っ込んだことしようとすると「未実装」と「バグ」の嵐だ。
枯れた環境なら誰かしら対策してるってのに。次から次へと新しいもの持ってくるからその度に一からやり直しだ。
「技術の蓄積」ってのを何だと思ってやがんだろうね。
開発環境なぞ『C言語』で十分だっての。
それにしてもこの文字化けは酷いな。何書いてあるのかさっぱりわかんねぇ。
何使って書けばこうなるんだ？おい、エディタはvi使えって言ってあっただろ。
いろんな文字コードに対応したエディタなんて使うから文字化けすんだよ。
とっかえひっかえ新しいツール試す暇があったらvi覚えろ。
# という先輩の小言を何十年も聞かされてきましたが何か？
Re: (スコア:0)
今、IIS WebAPIでツールを作っているのですが、こちらは、
★MVVMパターンで、HTMLのストリームを修正する度、ViewModelを静的に修正しないといけない
ただし、ViewModelを静的に修正すれば、魔術的なRefrection?でバインドは全て自動。
★（Data)Modelは、Code Firstでやっぱり静的。
ですが、
#3174677のWAFの方の記事を読む限り、Strutsでは、クラスローダーを多機能にし、
★ブラウザ側からViewModelを動的に修正出来る。
★ブラウザ側からControlerも動的に修正出来る。
★（Data）Modelも修正出来そう。
みたいです。
設計思想の違いだと思います。