アカウント名:
パスワード:
>住宅金融支援機構サイトではカード番号と有効期限に加えセキュリティコード
セキュリティコード漏洩は言い訳がきかぬ。
セキュリティコードは本来はカード会社以外が保管する必要もないはずだが...これはダメすぎる
元Q2屋がやられたんかw
ＧＭＯペイメントって言う名前をみて、ちょっと嫌な予感はしたんだけど流石に東京都もそれなりの審査はしてるんじゃないかと思ったんだが、ダメだったか・・・。
年末のカゴヤの件 [kagoya.jp]に続いて、またってのは痛すぎるし、面倒くさすぎる・・・。よりによって、カードも違うので、もう一回手続きかよ・・・。こんどはあっちこっちの定期引き落としになってるからものすごい手間だぞ。
＃業務委託者の責任もあると思うのだが、どうなんだろ？
与信関係ライブラリーのガイド・マニュアルにはセキュリティコードは保存するなと書いてありそうな気がするのだが……
基本的なことすらできてないのはセキュリティ意識以前だろう。
クレジットカード業界のセキュリティ基準 PCI DSS（Payment Card Industry Data Security Standard）の『Payment Card Industry（PCI）データセキュリティ基準 要件とセキュリティ評価手順バージョン 3.0』には「機密認証データは承認後、たとえ暗号化していても保存してはなりません。」とはっきり書いてあります。（CAV2/CVC2/CVV2/CID〔いわゆるセキュリティコード〕は機密認証データに含まれることも書いてあります）日本語版はv3.0が最新のようですが、その１０ページに書いてあります。ちなみにPCI DSSのドキュメントはメールアドレス登録で見れます。
追伸。業務委託している側（トヨタファイナンス？）にも責任ありです。
『PCI DSS 要件はアカウントデータ（カード会員データや機密認証データ）が保存、処理、または送信される組織と環境に適用されます。一部の PCI DSS 要件は支払業務や CDE 管理をアウトソースしている組織にも適用されます。CDE や支払業務を第三者にアウトソースする組織はまた、アカウントデータが 第三者により PCI DSS 要件に従って保護されていることを確認する責任があります。』
トヨタファイナンスは完全にアウトでしょう。ロゴや名前を出してる東京都も確認義務があって然るべきと思います。『委託先がやっちまったよ、ごめんね』では済まない。なんとかファイナンスとか、なんとかペイメントとか、いかにも金融取引・支払い業務を専門にやる社名の業者なのだから。
よくみると、GMOペイメントゲートウェイの言い訳文 [gmo-pg.com]の下の方には
「GMOペイメントゲートウェイのサービスはPCI DSSに完全準拠しております。」
とか書いてあって、もう笑うしかないですね。
トヨタファイナンスの方も2.0だけどカード会員用インターネットサービスにおいて「PCI DSS ver.2.0」準拠認定を取得 [toyota-finance.co.jp]とかあるので、こちらもなんだか。
それより気になったのは、同じトヨタファイナンスーＧＭＯペイメントゲートウェイの枠組みで、三重県自動車税 [toyota-finance.co.jp]、愛知県県税 [toyota-finance.co.jp]、大分県自動車税 [toyota-finance.co.jp]、福岡県自動車税 [toyota-finance.co.jp]、福岡市税 [toyota-finance.co.jp]なんかもやってるみたいなのだが、こちらは大丈夫なのだろうか？
いや、“流出した可能性がある、だがそれは保存していたからではないいい。メモリ内ならセーフなんだからあ”という解釈が・・
その解釈ができる可能性ってあるよね。そのほうが現実的。
いや、Javaは無難な選択というかそこ本質でなくて、Struts使っているっていうところがなんとも。
多分セキュリティを知らない、っていうかセキュリティは英語なんですか？レベルで知らないというか、そもそも自分が派遣された会社の仕事内容を全くしらないというか出社すらしない人が意思決定という名の放置プレイしてるんじゃないですかね。
Javaが無難な選択と思っちゃうような人って往々にしてJavaだけしか知らない人だからねぇ・・・
Javaだけしか知らない人達しか揃えられない、かもしれん。
#Javaで作るのは難しい、と誰かが言ってたなあ
「Javaも名前しか知らない」なんだな。良くてC,COBOL（これも名前だけ）。基本的に一行も読めない。ガチで。
♯Jar Hellなモノしか見たこと無いな
#3174724ですが、なんか話かみ合ってないけど、javaっていう言語の話でなく、Strutsのウンコ具合が問題なのであって。https://srad.jp/comment/3174677 [srad.jp]
java出来る人とPHP出来る人、そなたが沼に落としたのはどちらか？って聞かれたら、「単価の安い人です」って言っちゃうな。どっちもどっちだし。
javaいいですよ？ scalaたのしー。※ VMの感想です。
良く考えてもJavaは無難なところが話題をややこしくするかもね。※ パフォーマンス、エコシステム、言語の寿命とかを考えるとこのシステムならJavaで作る方が楽。RubyやPHPだとバージョンアップがめんどい。
なぜ、保存しないはずのセキュリティコードが流出とかされるのだろう。システム組むときに、誰も注意しないのだろうか。
保存してなくても入力フォームに攻撃者のサイトに入力内容を送信するJavaScriptを埋め込まれたりしたら普通に漏れる。あとはバックエンドの決済システムへ入力されたカード情報を流す部分に細工されるとか。ただ、今回の場合はすぐに具体的な数字が出てるので、ガチで保存してたっぽい気がするけど。
1枚再発行で1000円かかるから人件費と送料と合わせて5000円として36億円ねボーナス返上でよろしく
最終的には運営を委託されているGMOペイメントがかぶるような気がするんだが……
都税クレジットカードお支払サイトの方は、サイトの作りに問題があって責任の所在が（外部からは）不明確になっているとう問題があるようです。
高木浩光＠自宅の日記 - 「都税クレジットカードお支払サイト」流出事件の責任は誰がとるのか [takagi-hiromitsu.jp]
さすがに堂々とDB等に保存したりはしてない気はするけど、LOGに出してたのが抜かれたりしたのかな。
securityCode.csvに平文で保存に1票
パスワード平文よりひどいというか、故意を疑うレベルですね。
「リモートから任意のコードを実行」なのだから、「まず直ちにシステムを停止せよ」とアナウンスすべきなんじゃ。ヤバさがちゃんと伝わってないよ。。
とか書いても、「じゃあ週明けの月曜日にやりますわ」となりそうな悪漢。
そもそも開発者がこんなん
https://www.scutum.jp/information/waf_tech_blog/2014/04/waf-blog-036.html [scutum.jp]
いくらヤバさが伝わっても、「でもそれ(=運用すること)で金もらってるんだから(絶対に止めない)」っていう管理職やら経営者やらが多数いる以上、どうしようもないでしょうね。
できることは保身だけ。
「リモートから任意のコードを実行」と言っても、たいていは「悪意あるユーザが○○にアクセスできる状態であれば」といった前提条件付きのことも多いし。
で今回、自分もその類だと思っていて、ファイルアップロード処理が云々とかあるから、ファイルアップロードできる状態に限定されるのかとも思っていた。StrutsのMLに流れた修正版のリリースアナウンスも、"This release addresses one potential security vulnerability" なんて表現になっていた。正直、PoCコード見るまで緊急性を感じなかった。
「直ちにシステムを停止」という言い方が乱用されても困るけど、「『直ちにシステムを停止』してもいいぐらいのレベル」であることが伝わる必要があるのは同意。
DBには保存してなくても、ついログに出力しちゃってたりする事もあるからほんと気をつけないとだめだよね。
うっかりどっかに残ってしまうのを防ぐアイデアってあるんだろうか。SQLインジェクション防ぐならプリペアードステートメント使うのがセオリーとかXSS防ぐならテンプレートエンジンを正しく使うとかそんなノリで。
Unixの伝統として、書ける権限あるなら読めるのが普通、って感覚が良くない気がする。ログなんて本当はアプリは書き込み権限だけでいいんだよ。
誤ってログに機密情報を出力してしまうのは、そのアプリの権限の問題ではないでしょう。
そもそも「書ける」ということは「書き込む情報を持っている」わけですから、書き込んだ先をアプリから読めなくしたところで意味がないです。
やるとすれば「ログも機密情報の一部とみなして、暗号化するか権限をきちんと設定する」になるのでは。
以前のプロジェクトでは、ログを含めDB以外に機密情報を出さないようにするため、受け入れ時にソースコードの静的解析ツールを走らせて、機密情報のクラスの何か(メソッド、フィールドほか)をログクラスのパラメータに与えているのを調べさせて、引っかか
二軍の昇格組がまず慣れるために行う責任は軽くそれでいてセキュアに留意しないと簡単に破たんするもっと適当なWebシステム開発案件が有ればいいんだよ。
http://takagi-hiromitsu.jp/diary/20170310.html [takagi-hiromitsu.jp]
げげ、これまじか？東京都の業務委託だと信じきって使ったのだが。ほとんど詐欺に近いな・・・。
クレカもネットバンクも個人的に許容できるリスク内の金額で、メインバンクは別に複数持つ地域の信金とかあまりネットワークと繋がっていない金融機関をメインバンクに使うとなお良い
＞地域の信金とかあまりネットワークと繋がっていない金融機関をメインバンクに使うとなお良いはい？
すみません、そのように仰るのならば、Javaに取って代わる、時流に乗って、セキュリティーの強固な開発手段をお示し願います。
とりあえずJavaとPHP以外で選んでおけば多少はマシでしょ
常識的に考えてAdaとRPG以外いらんでしょ仕事で使うブログラミング言語なんて煽りでもなんでもなく遊びじゃないんだからさ
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倍とか書いてれば多少は説得力あったが。
改良されてるから多少の生産性の向上はあるがフレームワークの蓄積の差は埋められないぜ。
その生産性向上のフレームワークが穴になってるわけだが。
今、IIS WebAPIでツールを作っているのですが、こちらは、★MVVMパターンで、HTMLのストリームを修正する度、ViewModelを静的に修正しないといけない ただし、ViewModelを静的に修正すれば、魔術的なRefrection?でバインドは全て自動。★（Data)Modelは、Code Firstでやっぱり静的。ですが、#3174677のWAFの方の記事を読む限り、Strutsでは、クラスローダーを多機能にし、★ブラウザ側からViewModelを動的に修正出来る。★ブラウザ側からControlerも動的に修正出来る。★（Data）Modelも修正出来そう。みたいです。 設計思想の違いだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
物事のやり方は一つではない -- Perlな人
はいあうと～ (スコア:2, 興味深い)
>住宅金融支援機構サイトではカード番号と有効期限に加えセキュリティコード
セキュリティコード漏洩は言い訳がきかぬ。
Re:はいあうと～ (スコア:1)
セキュリティコードは本来はカード会社以外が保管する必要もないはずだが...
これはダメすぎる
Re: (スコア:0)
元Q2屋がやられたんかw
Re: (スコア:0)
ＧＭＯペイメントって言う名前をみて、ちょっと嫌な予感はしたんだけど流石に東京都も
それなりの審査はしてるんじゃないかと思ったんだが、ダメだったか・・・。
年末のカゴヤの件 [kagoya.jp]に続いて、またってのは痛すぎるし、面倒くさすぎる・・・。
よりによって、カードも違うので、もう一回手続きかよ・・・。
こんどはあっちこっちの定期引き落としになってるからものすごい手間だぞ。
＃業務委託者の責任もあると思うのだが、どうなんだろ？
Re: (スコア:0)
与信関係ライブラリーのガイド・マニュアルには
セキュリティコードは保存するなと書いてありそうな気がするのだが……
基本的なことすらできてないのはセキュリティ意識以前だろう。
Re:はいあうと～ (スコア:4, 参考になる)
クレジットカード業界のセキュリティ基準 PCI DSS（Payment Card Industry Data Security Standard）の
『Payment Card Industry（PCI）データセキュリティ基準 要件とセキュリティ評価手順バージョン 3.0』
には「機密認証データは承認後、たとえ暗号化していても保存してはなりません。」とはっきり書いてあります。
（CAV2/CVC2/CVV2/CID〔いわゆるセキュリティコード〕は機密認証データに含まれることも書いてあります）
日本語版はv3.0が最新のようですが、その１０ページに書いてあります。
ちなみにPCI DSSのドキュメントはメールアドレス登録で見れます。
Re: (スコア:0)
追伸。業務委託している側（トヨタファイナンス？）にも責任ありです。
トヨタファイナンスは完全にアウトでしょう。ロゴや名前を出してる東京都も確認義務があって然るべきと思います。
『委託先がやっちまったよ、ごめんね』では済まない。なんとかファイナンスとか、なんとかペイメントとか、いかにも金融取引・支払い業務を専門にやる社名の業者なのだから。
Re:はいあうと～ (スコア:2, 興味深い)
よくみると、GMOペイメントゲートウェイの言い訳文 [gmo-pg.com]の下の方には
とか書いてあって、もう笑うしかないですね。
トヨタファイナンスの方も2.0だけどカード会員用インターネットサービスにおいて「PCI DSS ver.2.0」準拠認定を取得 [toyota-finance.co.jp]とかあるので、こちらもなんだか。
それより気になったのは、同じトヨタファイナンスーＧＭＯペイメントゲートウェイの枠組みで、三重県自動車税 [toyota-finance.co.jp]、愛知県県税 [toyota-finance.co.jp]、
大分県自動車税 [toyota-finance.co.jp]、福岡県自動車税 [toyota-finance.co.jp]、福岡市税 [toyota-finance.co.jp]なんかもやってるみたいなのだが、こちらは大丈夫なのだろうか？
Re: (スコア:0)
いや、“流出した可能性がある、だがそれは保存していたからではないいい。メモリ内ならセーフなんだからあ”という解釈が・・
Re:はいあうと～ (スコア:1)
その解釈ができる可能性ってあるよね。そのほうが現実的。
Re: (スコア:0)
いや、Javaは無難な選択というかそこ本質でなくて、Struts使っているっていうところがなんとも。
多分セキュリティを知らない、っていうかセキュリティは英語なんですか？レベルで知らないというか、
そもそも自分が派遣された会社の仕事内容を全くしらないというか出社すらしない人が意思決定という名の
放置プレイしてるんじゃないですかね。
Re: (スコア:0)
Javaが無難な選択と思っちゃうような人って往々にしてJavaだけしか知らない人だからねぇ・・・
Re: (スコア:0)
Javaだけしか知らない人達しか揃えられない、かもしれん。
#Javaで作るのは難しい、と誰かが言ってたなあ
Re: (スコア:0)
「Javaも名前しか知らない」なんだな。
良くてC,COBOL（これも名前だけ）。
基本的に一行も読めない。ガチで。
♯Jar Hellなモノしか見たこと無いな
Re: (スコア:0)
#3174724ですが、なんか話かみ合ってないけど、javaっていう言語の話でなく、
Strutsのウンコ具合が問題なのであって。
https://srad.jp/comment/3174677 [srad.jp]
java出来る人とPHP出来る人、そなたが沼に落としたのはどちらか？
って聞かれたら、「単価の安い人です」って言っちゃうな。どっちもどっちだし。
javaいいですよ？ scalaたのしー。
※ VMの感想です。
Re: (スコア:0)
良く考えてもJavaは無難なところが話題をややこしくするかもね。
※ パフォーマンス、エコシステム、言語の寿命とかを考えるとこのシステムならJavaで作る方が楽。RubyやPHPだとバージョンアップがめんどい。
いつも思うのだけど (スコア:0)
なぜ、保存しないはずのセキュリティコードが流出とかされるのだろう。
システム組むときに、誰も注意しないのだろうか。
Re: (スコア:0)
保存してなくても入力フォームに攻撃者のサイトに入力内容を送信するJavaScriptを埋め込まれたりしたら普通に漏れる。
あとはバックエンドの決済システムへ入力されたカード情報を流す部分に細工されるとか。
ただ、今回の場合はすぐに具体的な数字が出てるので、ガチで保存してたっぽい気がするけど。
Re: (スコア:0)
費用は住宅金融支援機構へ請求となるのだろうね
Re:いつも思うのだけど (スコア:1)
1枚再発行で1000円かかるから人件費と送料と合わせて5000円として36億円ね
ボーナス返上でよろしく
Re: (スコア:0)
最終的には運営を委託されているGMOペイメントがかぶるような気がするんだが……
Re: (スコア:0)
都税クレジットカードお支払サイトの方は、サイトの作りに問題があって責任の所在が（外部からは）不明確になっているとう問題があるようです。
高木浩光＠自宅の日記 - 「都税クレジットカードお支払サイト」流出事件の責任は誰がとるのか [takagi-hiromitsu.jp]
Re: (スコア:0)
さすがに堂々とDB等に保存したりはしてない気はするけど、LOGに出してたのが抜かれたりしたのかな。
Re: (スコア:0)
securityCode.csvに平文で保存
に1票
Re: (スコア:0)
パスワード平文よりひどいというか、故意を疑うレベルですね。
脆弱性アナウンスにも問題がある (スコア:0)
「リモートから任意のコードを実行」なのだから、「まず直ちにシステムを停止せよ」とアナウンスすべきなんじゃ。
ヤバさがちゃんと伝わってないよ。。
とか書いても、「じゃあ週明けの月曜日にやりますわ」となりそうな悪漢。
Re:脆弱性アナウンスにも問題がある (スコア:3, 興味深い)
そもそも開発者がこんなん
https://www.scutum.jp/information/waf_tech_blog/2014/04/waf-blog-036.html [scutum.jp]
Re: (スコア:0)
いくらヤバさが伝わっても、
「でもそれ(=運用すること)で金もらってるんだから(絶対に止めない)」
っていう管理職やら経営者やらが多数いる以上、
どうしようもないでしょうね。
できることは保身だけ。
Re: (スコア:0)
「リモートから任意のコードを実行」と言っても、
たいていは「悪意あるユーザが○○にアクセスできる状態であれば」
といった前提条件付きのことも多いし。
で今回、自分もその類だと思っていて、ファイルアップロード処理が云々とかあるから、
ファイルアップロードできる状態に限定されるのかとも思っていた。
StrutsのMLに流れた修正版のリリースアナウンスも、
"This release addresses one potential security vulnerability" なんて表現になっていた。
正直、PoCコード見るまで緊急性を感じなかった。
「直ちにシステムを停止」という言い方が乱用されても困るけど、
「『直ちにシステムを停止』してもいいぐらいのレベル」であることが伝わる必要があるのは同意。
保存するつもりはなくても (スコア:0)
DBには保存してなくても、ついログに出力しちゃってたりする事もあるから
ほんと気をつけないとだめだよね。
うっかりどっかに残ってしまうのを防ぐアイデアってあるんだろうか。
SQLインジェクション防ぐならプリペアードステートメント使うのがセオリーとか
XSS防ぐならテンプレートエンジンを正しく使うとか
そんなノリで。
Re:保存するつもりはなくても (スコア:1)
Unixの伝統として、書ける権限あるなら読めるのが普通、って感覚が良くない気がする。
ログなんて本当はアプリは書き込み権限だけでいいんだよ。
Re: (スコア:0)
誤ってログに機密情報を出力してしまうのは、そのアプリの権限の問題ではないでしょう。
そもそも「書ける」ということは「書き込む情報を持っている」わけですから、
書き込んだ先をアプリから読めなくしたところで意味がないです。
やるとすれば「ログも機密情報の一部とみなして、暗号化するか権限をきちんと設定する」になるのでは。
以前のプロジェクトでは、ログを含めDB以外に機密情報を出さないようにするため、
受け入れ時にソースコードの静的解析ツールを走らせて、機密情報のクラスの何か(メソッド、フィールドほか)を
ログクラスのパラメータに与えているのを調べさせて、引っかか
Re: (スコア:0)
アホが書いたcommons loggingのアホな設定がコピペで蔓延してるだけだと思うぞ
Re: (スコア:0)
二軍の昇格組がまず慣れるために行う責任は軽くそれでいてセキュアに留意しないと簡単に破たんする
もっと適当なWebシステム開発案件が有ればいいんだよ。
ひろみちゅ砲 (スコア:0)
http://takagi-hiromitsu.jp/diary/20170310.html [takagi-hiromitsu.jp]
Re: (スコア:0)
げげ、これまじか？
東京都の業務委託だと信じきって使ったのだが。
ほとんど詐欺に近いな・・・。
決済関連情報は全部流失前提で使ったほうが良いね (スコア:0)
クレカもネットバンクも個人的に許容できるリスク内の金額で、メインバンクは別に複数持つ
地域の信金とかあまりネットワークと繋がっていない金融機関をメインバンクに使うとなお良い
Re: (スコア:0)
＞地域の信金とかあまりネットワークと繋がっていない金融機関をメインバンクに使うとなお良い
はい？
Re: (スコア:0)
すみません、そのように仰るのならば、
Javaに取って代わる、時流に乗って、セキュリティーの強固な開発手段をお示し願います。
Re: (スコア:0)
とりあえずJavaとPHP以外で選んでおけば多少はマシでしょ
Re: (スコア:0)
常識的に考えてAdaとRPG以外いらんでしょ仕事で使うブログラミング言語なんて
煽りでもなんでもなく
遊びじゃないんだからさ
Re: (スコア:0)
Javaだからじゃなくってフレームワークの脆弱性なので
その他のフレームワークでも起こりえることなので言語のせいじゃありません
Re: (スコア: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)
今、IIS WebAPIでツールを作っているのですが、こちらは、
★MVVMパターンで、HTMLのストリームを修正する度、ViewModelを静的に修正しないといけない
ただし、ViewModelを静的に修正すれば、魔術的なRefrection?でバインドは全て自動。
★（Data)Modelは、Code Firstでやっぱり静的。
ですが、
#3174677のWAFの方の記事を読む限り、Strutsでは、クラスローダーを多機能にし、
★ブラウザ側からViewModelを動的に修正出来る。
★ブラウザ側からControlerも動的に修正出来る。
★（Data）Modelも修正出来そう。
みたいです。
設計思想の違いだと思います。