Java Web Application Framework総合　ver2

Java Web Application Framework総合　ver2 at TECH

[前50を表示]
150:デフォルトの名無しさん
13/12/09 21:51:40.90
>>149
その構成でログインや認証ってどうやります？

151:149
13/12/09 22:32:02.72
>>150
（要件のリッチ度によるが、) ユーザ認証・認可はアプリのレイヤではやりたくない。

ユーザ認証や認可は、JAASやSSO とブラウザ (とユーザ) の間で、勝手に解決してもらって、
アプリからは、何も考えずに req.getRemoteUser() なり req.getUserPrincipal()
でアカウント名や権限グループが取れるのが ... [作り手]としては理想。

そうなるように、よくよく費用対効果を説明して、お客さんに勘弁してもらうと、
後々双方とも幸せになれる。
（認証・認可を作りこむと、テストケースが爆発 ... の割にはユーザビリティ
の向上はごくわずか）

あと、JAAS の認証は多少融通が効きます。（３回失敗で５分ロックなど)
Glassfish、JBOSS なら既存の認証モジュールを参考に自作の認証モジュール
を作って差し替えることができる。
商用のコンテナの場合でも聞けば、やり方を教えてくれるはず。

152:デフォルトの名無しさん
13/12/09 23:40:25.11
>> 151
そういえば、Glassfishの商用版がなくなったらしいね

>>138
> ASP.netは安いものだよ。
> .NETが高いとか言ってるようではそのSIerのレベルは怪しい。
おれも、そう思うわ

153:デフォルトの名無しさん
13/12/10 05:20:10.23
どうしてもJavaでなければいけない理由がないなら
フルスタックのフレームワークでやるほうがはるかに楽だよな
3大人気の、ASP.net、Ruby on Rails、Djangoあたりで

いろんなライブラリを組み合わせなければいけないJavaはめんどくさい
保守のコストもかかる

154:デフォルトの名無しさん
13/12/10 05:29:18.25
フルスタック必要ならGrailsで良いじゃん。Javaの資産使えるし。

155:デフォルトの名無しさん
13/12/10 08:41:45.63
>>153
おまえなんでこのすれにいるの？

156:デフォルトの名無しさん
13/12/10 09:18:24.81
たしかにw

157:デフォルトの名無しさん
13/12/10 09:35:55.95
>>155-156
言語はJava8でいくらかましになるが、
まともなフルスタックのフレームワークすらないJava

Javaの痛いところつかれて反論できなくなって人格攻撃か
なさけない奴らだな

158:デフォルトの名無しさん
13/12/10 10:44:07.22
>>157
すれちだろ

159:デフォルトの名無しさん
13/12/10 13:37:54.00
>>157
Javaが嫌なら、スレから出て行けよ
スレタイも読めないのかこの池沼は

160:デフォルトの名無しさん
13/12/10 16:42:40.75
ASP.netくんの言いたい「フルスタックフレームワーク」が何を指すのかようわからんが・・・

デプロイ環境からORM、View生成まで、ウェブアプリケーション開発に必要なものが全部
揃っているAPI Frameworkと言う意味ではJavaEEと標準実装であるGlassfishがそうだろう。
Rails風のCoC重視でコマンドラインも併用したRAD環境であればGrailsやRooがある。

161:デフォルトの名無しさん
13/12/10 17:25:48.81
>>160
GrailsはGroovyだからJavaと主張するには無理がある
GroovyなんてJavaの負の部分を引きずった醜い世界

JavaEEはWebアプリケーションフレームワークというよりライブラリ
「フルスタック」とはなにか分からないのもJavaしか知らないからだろうな

162:デフォルトの名無しさん
13/12/10 18:28:47.80
>>161
>GrailsはGroovyだからJavaと主張するには無理がある

使ってから言えばよいのに。

163:デフォルトの名無しさん
13/12/10 18:47:04.53
>>162
Grailsは使ったことある
動作ももっさりだった
これでもJavaの中ではましなのかもしれないが
他の言語の人気フレームワークより使いづらかった

あと中身はSpringがベースでしょう
軽く触ったからそれくらはしってる

164:デフォルトの名無しさん
13/12/10 20:29:35.41
ASP.netってVS無しでまともに開発できんの？
マカーでIntelliJユーザなんだが。

165:デフォルトの名無しさん
13/12/10 20:39:44.95
まかーはすれちもわからんのか

166:デフォルトの名無しさん
13/12/10 21:45:56.04
Glassfishって使い勝手とかどうなんでしょう？

167:デフォルトの名無しさん
13/12/10 22:16:07.56
ASP.netはスレチだが開発環境の広さという意味ではASP.netとそれ以外では歴然と差があるな。
JavaもEclipseが走れば開発環境は何でもよいという人も少なくないのでは。

168:デフォルトの名無しさん
13/12/10 22:23:58.35
>>167
すれち

169:デフォルトの名無しさん
13/12/10 22:27:56.81
Javaの開発環境の広さはスレチじゃないと思うが。というか実際何使って開発してる？

170:デフォルトの名無しさん
13/12/10 22:38:21.63
>>167
すてまおつ

171:デフォルトの名無しさん
13/12/10 22:40:54.87
>>169
パソコン

172:デフォルトの名無しさん
13/12/10 22:43:29.33
>>169
窓

173:デフォルトの名無しさん
13/12/10 22:46:37.34
>>169
キーボード

174:デフォルトの名無しさん
13/12/11 01:23:11.07
>>169
Eclipse

175:デフォルトの名無しさん
13/12/11 01:47:27.90
>>169
Vi

176:デフォルトの名無しさん
13/12/11 01:51:32.47
>>169
TOTO製

177:デフォルトの名無しさん
13/12/11 16:19:52.57
>>166
使い勝手を気にする用途に使ってるやつはいないだろう

178:デフォルトの名無しさん
13/12/11 19:39:42.11
GlassFishが商用サポート切るとかたまったもんじゃないな
JerseyからRESTEasyに切り替えないといけなくなりそうだ

179:デフォルトの名無しさん
13/12/11 19:45:15.93
やっぱasp.netが一番いいな

180:デフォルトの名無しさん
13/12/11 20:37:30.52
>>179
ポエムは真板へ

181:デフォルトの名無しさん
13/12/11 23:28:37.07
>>179
Web Froms時代はいまいちだったけど
ASP.net MVCは最高だよな

182:デフォルトの名無しさん
13/12/11 23:32:27.89
>>181
すれち

183:デフォルトの名無しさん
13/12/11 23:34:15.13
MS厨はなぜ粘着するのでしょうか？

184:デフォルトの名無しさん
13/12/11 23:45:27.57
ステマ

185:デフォルトの名無しさん
13/12/11 23:47:27.13
>>182-183
>>171-176のような無駄レスは文句をいわないくせに
ASP.netの文字が出ると感情的に批判してくるのな

186:デフォルトの名無しさん
13/12/11 23:51:42.85
>>185
ここでやってくれ、さようなら
ｽﾚﾘﾝｸ(win板)

187:デフォルトの名無しさん
13/12/11 23:57:24.28
>>186
開発と関係ない板のURLはって馬鹿じゃないの？
少しはJavaの話でもすれば？

188:デフォルトの名無しさん
13/12/12 00:06:14.84
すれちに馬鹿といわれちゃった、わーん！！！

189:デフォルトの名無しさん
13/12/12 00:07:31.28
ておばちゃんか、しょうがねーな

190:デフォルトの名無しさん
13/12/12 10:16:01.45
真性のカスだなｗ

191:デフォルトの名無しさん
13/12/15 20:46:37.58
URLﾘﾝｸ(news.mynavi.jp)
Spring Framework 4.0正式版リリース - Java 8、Java EE 7に対応

192:デフォルトの名無しさん
13/12/18 00:19:57.11
すれちだろ

193:デフォルトの名無しさん
13/12/18 00:33:41.58
GlassFish使っててJBossへの乗り換えを検討してる所は少ないの？
JerseyMVCとか試そうかと思ってた矢先だったからなぁ

194:デフォルトの名無しさん
13/12/20 12:37:54.79
一生プログラマーでいたいならフルスタックとかで楽すればいいよｗ

195:デフォルトの名無しさん
13/12/22 00:56:53.89
あんだけ某関係者の人がTomcatはオワコンこれからはGlassFishとかとDisってたのに
いつの間にかGlassFishの方がオワコンになっていたのか。

まあ、今もTomcat使って古いフレームワーク（StrutsとかSAとか）で動かしてる（爆）だからどうでもいいけど。

196:デフォルトの名無しさん
13/12/22 02:58:54.87
Java自体が終わりそうだけどね
ライブラリがクソすぎる

197:デフォルトの名無しさん
13/12/22 07:51:22.48
>>196そうか残念、さようなら

198:デフォルトの名無しさん
13/12/22 08:45:35.32
asp.netが強すぎるからな

199:デフォルトの名無しさん
13/12/22 09:49:22.90
>>198
そうか、どうでもいいけど、さようなら

200:デフォルトの名無しさん
13/12/22 13:04:11.82
Tomcatは起動が重いんだよな。
Jettyが軽くていい感じなんだけど、Tomcatに比べて日本語情報が少ない感じ。
JDBC使うのに、JNDI周りの情報も少ない。

201:デフォルトの名無しさん
13/12/22 17:38:03.86
JBossが最強だろ

202:デフォルトの名無しさん
13/12/22 18:44:49.04
ローカル試験で使う分にはWinstoneも軽くて良いですよ。
なにせjarファイル1個で動いて、160kbくらいだし

203:デフォルトの名無しさん
13/12/22 20:04:05.19
JSON返すだけとかなら、Netty直利用とかも良いですよ。

まあ、ネタはおいといて、Jetty組み込んででExecutable WAR配布とか、利用側はお手軽で良いな。
Javaでもセルフホストしやすい軽量スタックとか、そっちが流行らないかな～。

204:デフォルトの名無しさん
13/12/22 20:05:57.66
組み込みサーバー＋JavaFXは今後の選択肢として大いに有り得るらしい
JAX-RSとCDIが使えないほどの軽量サーバーならちょっと勘弁だが

205:デフォルトの名無しさん
13/12/22 20:08:51.41
JAX-RSの実装もCDIの実装も、アプリケーション中に含めて組込サーバーといっしょに配布するで良いじゃん。

206:デフォルトの名無しさん
13/12/22 20:25:15.91
JBoss覚えるか。どう考えても最強だわ

207:デフォルトの名無しさん
13/12/22 20:39:18.03
jbossって起動に10分掛かるだろ

208:デフォルトの名無しさん
13/12/22 20:42:11.68
情弱乙

209:デフォルトの名無しさん
13/12/22 20:43:02.29
WildFly

210:デフォルトの名無しさん
13/12/22 20:59:18.59
richfacesでイベントを呼び出せない、俺涙

211:デフォルトの名無しさん
13/12/22 22:29:12.90
>>209
8.1が出てからだろ

212:デフォルトの名無しさん
13/12/23 15:42:07.91
>>209
WildFlyってRHELとFedoraの関係なんだろ？
名前変えられると、テンション下がるわー

213:デフォルトの名無しさん
13/12/23 16:25:18.46
>>212
横だけど、間違ってる、名前の問題だけ

214:デフォルトの名無しさん
13/12/23 16:31:32.49
むしろASがエンタープライズで使えない誤解すら生んだろうね

215:デフォルトの名無しさん
13/12/24 20:16:25.04
JSFで画面作ってる時に、URLﾘﾝｸ(java.sun.com) ってのを使うけど
これ、primefaceとかrichfacesと何が違うの？

216:デフォルトの名無しさん
14/03/10 05:55:51.25
age

217:デフォルトの名無しさん
14/03/10 07:39:49.81
3年ニートしてる間にseasar2ってオワコンになってたのかよ
使われなくなるのって開発ストップしたからバグとかセキュリティホールが見つかっても
修正されないからって意味合いが大きいからなん？

218:デフォルトの名無しさん
14/03/10 15:24:45.00
作りが悪いからに決まってるじゃん
名前が違うだけのspringだし
独創性がないから宣伝はspringの悪口だけ
目玉のHotDeployはバグバグで動かないのにサクサク開発()

とどめに後発のPlay Frameworkがもっと高い技術力とサポートで
同じようなことしてるからまるで存在意義がない

219:デフォルトの名無しさん
14/03/10 18:54:22.97
スプリングググったらver4まで出ててワロタｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
初代スプリング触ったときゴミすぎで2度と触りたくないと思ったけど進化してたんだな

220:デフォルトの名無しさん
14/03/10 20:45:17.51
SpringMVC、使いやすいよ。
RESTと親和性高いし。
もうこれ以外使うきしない。

221:デフォルトの名無しさん
14/03/10 20:54:36.49
俺はPlayを使うね！！

222:デフォルトの名無しさん
14/03/11 02:51:10.09
javaしかやったことないから他の言語のwebアプリ状況がどんなもんか知らんけど
純粋にjava嫌いな層ってフレームワーク多すぎていろんところで開発スタイルバラバラすぎるからじゃねーの
勤勉でもないから触ったことないフレームワーク使ってるとお作法覚えるのもたりーんだよな

223:デフォルトの名無しさん
14/03/11 03:14:13.37
>>222
javaやったことなくてそろそろ手を付けようかなと思ってこのスレ見てるけど、
設定含めすべてにおいてめんどくさそうだからじゃね。
もちろんフレームワークの選別とか作法とかも分からないってのはあるが。

224:デフォルトの名無しさん
14/03/11 07:23:44.74
めんどくさいというイメージはだいたいStrutsのせい

225:デフォルトの名無しさん
14/03/11 07:42:49.43
ASP.NETが神すぎる

226:デフォルトの名無しさん
14/03/11 12:51:19.90
型コンバートやバリデーションをコントローラでやって
アノテーションつけまくる最近のスタイルが嫌いだ

227:デフォルトの名無しさん
14/03/11 17:07:04.92
Convention over Configurationとかってまだ流行ってんの？

228:デフォルトの名無しさん
14/03/11 17:20:32.04
Java言語をマスタしても、フレームワークのお作法覚えないとダメだし
フレームワークも色々で、プロジェクトによっては勉強しなおさないといけないし
言語だけマスタしてた時に比べて、大変だよね。

229:デフォルトの名無しさん
14/03/11 17:28:37.61
>>227
Play frameworkは、さほどCoCにこだわってないように見えるね。
ルーティングは、routeファイルに必ず書くし。

230:デフォルトの名無しさん
14/03/11 19:30:14.12
>>228
チームで開発するときはアーキテクトさんが更にもう一枚「オレオレフレームワーク」でくるんで使わせるのではないか？

設定ファイル等々にしても集中管理するから末端プログラマが触る機会なんてないはず
プログラマに素のままのフレームワークを使わせるなんて危険すぎるが

231:デフォルトの名無しさん
14/03/11 22:35:21.22
一周まわって、フレームワークなしのサーブレットに、必要最低限の機能を持つ基底クラスだけ自分で作って使うのがベストだと思う。

232:デフォルトの名無しさん
14/03/11 22:58:08.03
>>230
オレオレ作った場合、プログラマに使い方を説明してる？

233:デフォルトの名無しさん
14/03/11 23:54:00.32 Y7xUI5Hj
>>232
APIドキュメント、サンプルプログラム、コメント付き各種設定ファイルなど一通り揃えて、取り合えずば簡単に動くものを用意
説明用の資料パワポや説明会は必要に応じて。

234:デフォルトの名無しさん
14/03/14 00:09:52.72 K0sLkIAE
更新止まったActiveObjectsやBeanKeeperの後継とかなくて
結局JPA + Hibernateに落ち着くのか

235:デフォルトの名無しさん
14/03/14 00:16:16.03 BtBBLClg
Seamってまだ息してんの？ｗ

236:デフォルトの名無しさん
14/03/14 03:00:36.47 vTPAugkR
JAX-RSはフォームデータを渡した場合は@FormParamで受け取るしかない？
Servlet感覚で可変のフォームデータを受け取ってパースしたかったんだけど…

237:デフォルトの名無しさん
14/03/15 15:19:19.23 K2uN+xbt
アノテーションもりもりMVCとかO/Rマッパー考えたやつはセンスないな
素直にServletとJDBCで十分じゃまいか

238:デフォルトの名無しさん
14/03/15 15:32:33.28 JfWd/5x0
>>237
狂おしいほど同意

239:デフォルトの名無しさん
14/03/15 15:33:42.26 ODzNcjwn
servletでmemcached使いたいんですが
MemCachedClient mcc = new MemCachedClient();
mcc.set("name", "Naoki Takezoe");
ってやったあとmccのインスタンスはどこにしまっておけばいいんですか？

240:デフォルトの名無しさん
14/03/15 16:16:57.22 ha3L2y5+
>>238
開発者が100人位いるような大規模開発だとどうするの？
皆が勝手にConnection.prepareStatementとかやるわけ？

241:デフォルトの名無しさん
14/03/15 16:27:57.63 q7u7Ew65
100人も集めて何作ってるんだよｗ

242:デフォルトの名無しさん
14/03/15 16:33:36.62 4evGY2gy
案件規模とかそういうのはどうでもいいんだけど、
IDEの恩恵に頼って楽してコード書きたいから、そもそも今更自前でSQL書きたいとは思わないな。

あの書きづらい読みづらい、毎回同じような記述するだけのSQL文を構築していく作業って、
なんかこうテキストエディタでコーディングするのが好きな人向けな感じ。
あんなものは、パフォーマンスチューニングが必要になってから、必要最低限だけ書きゃいいのにな。

それにServletとかJDBCみたいなクソ仕様は、二度と触りたくないなｗ
あのあたりは、なんかもうかなりレガシーコードの塊になってしまってて、時代に沿ってない内容になりすぎてる。
インターフェイスの設計に失敗してる箇所が多くて、ラッパー噛まして使うのが前提みたいな状態。

243:デフォルトの名無しさん
14/03/15 16:44:35.64 JfWd/5x0
多くて3人くらいだわ

244:デフォルトの名無しさん
14/03/15 16:51:05.57 4evGY2gy
Seasar2はSAStruts+S2JDBC、S2JUnitくらいしか触ってたことないが、
- ドキュメントが総じてクソい、ほぼメンテされてない
- できることが少ないわりに何パターンかあったりして説明が乏しい
- フォームのバリデーションより先に処理を挟みたいなら有志の拡張かフィルター使うしかない
- 設定ファイルを減らすための命名規約の呪いがパッケージを強要したりクラス名を制限したりしてくる
- JPA実装してるけど一部しかサポートしてない
- 自動投入用のテストデータのフォーマットがExcel
- おまけにキモっぽいHotDeployはバグ多すぎ

殆ど良かったイメージが残ってないな。

最近なら、Servlet使うならSpring、使わないならPlayの2択でだいたいなんとかなりそうな気がする。

245:デフォルトの名無しさん
14/03/15 16:58:45.19 ha3L2y5+
>>241
大企業の基幹システム開発なら100人規模なんてザラ

246:デフォルトの名無しさん
14/03/15 18:28:18.81 Z5g2rNsd
>>245
そういう案件だとザラだけど高確率で炎上じゃね
そんなに人使う必要がある時点で発注側にも問題アリだよ

247:デフォルトの名無しさん
14/03/15 19:19:45.31 ha3L2y5+
>>246
どんなに大規模な基幹系でも、高々10人、20人程度で開発しきれるはずと申すか？

248:デフォルトの名無しさん
14/03/15 19:26:41.17 JfWd/5x0
どんなに大規模でもサブシステムに分割できるはず

249:デフォルトの名無しさん
14/03/15 19:30:27.26 ha3L2y5+
サブシステムことに開発標準を作ると申すか？

250:デフォルトの名無しさん
14/03/15 19:40:36.57 JfWd/5x0
開発標準とは何かな
そんなもの見たことないけど

251:デフォルトの名無しさん
14/03/15 20:11:03.06 K2uN+xbt
RDBでSQLのWHEREを書かないで、KVSみたいに全部javaで書くライブラリを作ってみる
URLﾘﾝｸ(ideone.com)

252:デフォルトの名無しさん
14/03/15 20:45:31.84 nOYr2Orx
何でみんなそんなにSQLを嫌ってるの？
SQL書けばええやん。

253:デフォルトの名無しさん
14/03/15 21:31:07.36 rh2Bnj0w
同意。
トラブったときはSQLのほうが圧倒的に楽
昔Hibernateで痛い目にあった。。。

254:デフォルトの名無しさん
14/03/15 21:46:03.69 LN7VnBH1
>>241

255:デフォルトの名無しさん
14/03/15 22:33:43.53 qWn8sJ/I
引用アラシ発見

256:デフォルトの名無しさん
14/03/15 22:51:59.47 xO9GlIgR
apacheのdbutilsが程よくJDBCをラップしてくれて好きだった
DBアクセスは自分でSQL書く方が好み
どっちも個人的な好みだから他人には強要しないけど

257:デフォルトの名無しさん
14/03/15 22:55:50.30 JfWd/5x0
フレームワーク厨は強要してくるからなー

258:デフォルトの名無しさん
14/03/16 00:26:39.56 UxgGr0B4
くだらない問い合わせはORマッパー通した方がくだらない間違いも起こりにくいだろ
複雑な問い合わせだけはSQL直書きするようにすればいいだけやん
目糞鼻糞だけど

259:デフォルトの名無しさん
14/03/16 05:05:07.42 1NSc6s95
SQLで書けば、コード量は多めでも、読解難度は低い。
ORMを駆使すると、コード量は少なめで、読解難度が高くなる。

他人が書いたコードを引き継いだ時に殺意を覚えるのは、後者。
特に、とっくに廃れたORMの場合。

260:デフォルトの名無しさん
14/03/16 05:18:27.85 cHCjLYAE
流れるようなインターフェース()の悪口はそこまでだ

ｵﾚｵﾚ色が強いと大変ね

261:デフォルトの名無しさん
14/03/16 06:28:50.92 UxgGr0B4
おまえらはORマッパーが出来た背景を少しは調べたほうがいい
2、3人で開発するなら知らんけどそれなりの規模で大量のオナニーSQL文見せられてもかなわんだろ

262:デフォルトの名無しさん
14/03/16 06:38:36.02 Z6fLevpG
Oracle使った時SQLは全部ストアドに書くとかやったことあるわ
SELECTのReturnはXML
あれもある意味O/Rマッパーなんだろうか

263:デフォルトの名無しさん
14/03/16 09:03:49.32 axl38rZU
SQLをまったく意識しなくてよくなるようなまっぱができれば使いたいが

264:デフォルトの名無しさん
14/03/16 09:17:10.22 AdE6gbYt
O/Rマッパー黎明期から期待に胸を膨らませて追っかけてきたけど
保守段階までトータルで見ると、少なくとの日本の人月ベースで
コスト計算する業界では見合わないと思ってる。

初期HibernateのHQLなんかも設計思想はものすごく好きだった。
Torque、Castorなんかも試した。Torqueはクラス数が爆発しがちで
仕様がコロコロ変わる案件で地獄をみた。
Cayenneも良かったな。旧NeXT製のEOF(Enterprise Object Framework)
なんかの流れを彷彿とさせる設計は美しかったが、
日本ではマイナーで使える技術者が育たず広がらなかった。

とはいえ、素のJDBC使うのはめんどいし、もはやS2系は死んだ。
個人的に残された希望は枯れたMyBATISくらいかな。
SQLの透過性とシンプルにも使えるO/Rマッピングの融合がバランスいいよ。

265:デフォルトの名無しさん
14/03/16 09:28:37.06 axl38rZU
業務アプリなんかだと結局メイン部分はパフォーマンスや
堅牢性が大事になってきてSQLで書かないといけない。
まっぱが使えるのはマスタメンテくらいになる。
マスタメンテくらいのSQLなら別に複雑でもないからまっぱにする意味もない。
つまり使い道が無い。パフォーマンスや堅牢性も備えてはじめて使えるようになる。

266:デフォルトの名無しさん
14/03/16 09:48:24.48 AdE6gbYt
だよな。複雑なビジネスロジックをオブジェクト操作で
動的にSQL作るような仕組みだと、仕様変更とかバグ修正の場合に
マジックハンドでモノを掴むみたいな感じになるよ。
SQLならものの数分で終わるような対応が丸一日かかったり。

ただ、O/RマッピングとSQLの動的生成は違うものだから
ここは混同しちゃいかんな。
生JDBC使ったって最後はbeanにマッピングされるわけだし。

267:デフォルトの名無しさん
14/03/16 10:12:47.25 gY7mojcT
JPAは再帰処理がないのが不満に思えたが
昨今の大規模環境ってJOIN禁止ルールとかあるみたいだし気にしなくていいのかな？

268:デフォルトの名無しさん
14/03/16 17:26:09.65 Z6fLevpG
JOIN禁止ってマジ話？
そんなプロジェクトに放り込まれたらプロマネ殴り倒す自信あるよ

269:デフォルトの名無しさん
14/03/16 18:32:30.12 /+q7XY+7
一部のコンシューマーサービスにおける設計の話を一般論扱いされても。
それにむしろ、そういうケースではMicro-ORMだろうし。

270:デフォルトの名無しさん
14/03/16 18:53:19.88 Va0mC41/
指定数表以上の結合禁止、右外部結合禁止は見たことあるが、
結合そのものを禁止しているところは見たことないな。

271:デフォルトの名無しさん
14/03/16 19:00:58.43 axl38rZU
まあ将来的には結合なんてしなくてよくなるのが理想だよ。
だからまっぱは理想なんだけど今のハードではまだまっぱには無理がある

272:デフォルトの名無しさん
14/03/16 19:36:35.66 rxfO/+Tv
逆だろ、将来的にはいくら結合しまくっても性能が劣化しないのが理想だよ

273:デフォルトの名無しさん
14/03/16 19:41:36.95 zMPxA87q
結合時の性能劣化がなくなるよりも先にＲＤＢが廃れそうだなｗ

274:デフォルトの名無しさん
14/03/16 19:44:29.10 axl38rZU
え？結合なんかしたらSQLみたいじゃん

275:デフォルトの名無しさん
14/03/16 19:53:56.08 /+q7XY+7
抽象度が高くかつ表現力のあるマッピングAPIが、現状の言語仕様やHW的な限界で現実的ではないという話と、
リレーショナルモデルを相手にする以上、結合を考えないなんて意味がない話だし、本質的に性能劣化は発生する
みたいな話が混在してね？

276:デフォルトの名無しさん
14/03/16 23:08:47.31 AdE6gbYt
ソーシャルゲーム業界だと、たいがいJOIN禁止だな
詰めSQLやるようなチューニングはしない
大規模構成のMySQLをmemcachedとあわせてKVS的に使ったりって感じ
大規模にサーバまたいでデータ結合やったりするからJOINなんか使ってたら
保守できなくなる

277:デフォルトの名無しさん
14/03/17 03:54:31.81 CvNwiWhQ
ORM使いにくいって感じる状況、ORMへの知識不足が原因じゃなけりゃ、
大元のDB設計とかがいまいちだったりする感じのこともけっこうありそうな

そもそも、言うほどパフォーマンスに問題が合ってSQL書かないと行けないような自体って起きるかなぁ
そういうのって、どっかうまいこと作れてないか、
体感できない性能差を突き詰めたいだけでチューニングを行なってる人かのどっちかってことも少なくない気がする

278:デフォルトの名無しさん
14/03/18 02:18:31.77 tRXj2H8I
ORMはEager fetch, Lazy fetchの問題を解決不可能なんだよ

279:デフォルトの名無しさん
14/03/18 09:36:03.49 isJ/4bi8
>>277
DB設計が大元ってｗ
ORMを理解してないのはお前だろ
ORMを使う動機はドメインモデルをRDBに永続化することなのに
なんでDB設計が先にくるんだよアホかｗｗｗｗ

ていうかみんなわかってなさすぎｗ
テーブルモジュールで設計していながらORM語ってんだろ？ｗｗ

280:デフォルトの名無しさん
14/03/18 11:18:48.08 +SzQB6tf
>>279
世の中の全てがモデルファーストでシステムを全て作れるわけではないし(そんなの本当に新規開発だけ)
パフォーマンスのために非正規化したりテーブル設計を崩すこともある

他システム連携があったりすると、そのDBにアクセスしてくるのはJavaだけとは限らない

もうちょっと世の中でいろんな経験をしてごらん。
見えなかったものが見えてくるよ

281:デフォルトの名無しさん
14/03/18 16:21:01.00 SyPosiOD
次の仕事でPlay使うかもしれんとここ数日予習してるんだけどさ、
何か凄いstaticだらけで違和感覚えるんだが、
これはこういうものだと思って慣れるしかないの？
テストとかしずらくね？

工夫すれば一応DI使えるみたいだけど、entity注入するのはそれはそれで変な気もするし…

282:デフォルトの名無しさん
14/03/18 19:40:51.38 Xfw7AJmq
常に新規開発でDBを好き勝手やれるならそもそもこんな話してないわ
システムリプレイスするけどDBはそのままとか
DB設計は他社とかそんなんばっか

>>281
Playはそういうもんだと諦めたまえ

283:デフォルトの名無しさん
14/03/18 21:02:44.46 SyPosiOD
>>282
サンクス。気にはなるがやっぱフレームワークの流儀に従うべきか…。

284:デフォルトの名無しさん
14/03/23 16:44:03.33 oyP9q9vp
Javascriptに対してGAEができるなら
ORMにも似たようなのないの？

285:デフォルトの名無しさん
14/03/23 16:44:45.76 oyP9q9vp
間違えた！　GAEではなく、GWTです。

286:デフォルトの名無しさん
14/03/26 04:52:17.35 j07vAV4n
HSQLでfunctionつくるの楽しいわ

287:デフォルトの名無しさん
14/03/27 10:11:37.22 9TpQSSF6
プログラミング言語「Hack」登場 - 米Facebookが発表
URLﾘﾝｸ(news.mynavi.jp)

動的な型付け言語がもたらす開発の手軽さと、静的な型付け
がもたらすエラーチェックの完全性の高さなどの双方の利点を
得ることを目指して開発されているという。

これはJavaより有望かもしれない

288:デフォルトの名無しさん
14/03/27 13:18:35.80 V1uU5d7+
ああほんと。電動歯ブラシぐらいのエロティシズムを感じるよ
Oculusなんて買収して、どんなイノベーションを見せるんだろうね

289:デフォルトの名無しさん
14/03/27 22:05:13.54 53iNYuED
所詮はペチパーだろ

290:デフォルトの名無しさん
14/03/28 12:49:21.10 QHWMvAHr
PHPのDartみたいなもんじゃん。糞杉ワロタ

291:デフォルトの名無しさん
14/03/29 17:52:04.29 lqk81omC
Javaのスレとしては、というかPHPのスレ以外もれなくだと思うが
まずPHPをベースにするのをやめろと言わざるを得ない

292:デフォルトの名無しさん
14/03/29 19:25:52.45 ZB5YY77p
facebookが内製用に使うぶんには有効なんだろうけど
こういうのって外部の開発者が採用しても
大抵の場合はメリット出ないよね

293:デフォルトの名無しさん
14/03/30 17:09:49.38 jhRCncdW
CGIレンタルサーバーの都合(安さ)を考えて
Java, C#をベースとした言語から => PHP, Perlに変換するとか
そういう話ではないんだね

294:デフォルトの名無しさん
14/04/11 23:22:52.67 n3O3RPz1
Seasar2を使ってるところってもうないの？
新規案件ではSeasar2は選択肢にも入らないのでしょうか？

295:デフォルトの名無しさん
14/04/11 23:35:33.19 Pv1Uj3xG
そんなもん使うぐらいならStruts使えって言われる

296:デフォルトの名無しさん
14/04/11 23:49:08.61 HW4sCI/6
Seasarプロジェクト自体がもうオワコンだしねぇ。
今後を見据えたら、Java8でSpringでしょ。

297:デフォルトの名無しさん
14/04/12 00:10:02.61 SAIw86Ow
Playだ、Playを使うんだ

298:デフォルトの名無しさん
14/04/12 00:14:19.11 qS4Q8Ow0
Freemarkerもなかなかいいよ。

299:デフォルトの名無しさん
14/04/12 01:02:21.33 r3JAB95t
出来が良い悪い以前に日本のプロダクトは長続きしないな

300:デフォルトの名無しさん
14/04/12 01:18:14.99 D3xQkXal
支える人が少ないからな

301:デフォルトの名無しさん
14/04/12 08:35:02.06 NN09N+xI
この記事最近のだけど今頃脱Strutsとか言っててちょっとポカーンなんだが
保守作業とかならわかるが新規プロジェクトでいまだにStruts1.x系選択するところとかあんの？
SAStrutsっていうならわかるけど書いてないし
URLﾘﾝｸ(gihyo.jp)

Seasar2ってORMデフォルトでついてるからなんだかんだ言って開発しやすい

302:デフォルトの名無しさん
14/04/12 10:07:33.97 SAIw86Ow
新しいフレームワークは分からんとか言われて去年Struts1.3で作らされた

303:デフォルトの名無しさん
14/04/12 11:05:52.31 qS4Q8Ow0
脱Struts→HTML5

SIer的には物凄くハードル高いと思うよ。
HTML5と一口に言っても、その意味が内包している
要素技術って膨大だからな。

これからはHTML5だ！と鳴り物入りで一度は方針転換したのに
サーバーサイドでHTML生成するような実装してた開発者が
クライアントサイドでDOM生成する実装に馴染めず
結局モトサヤでStruts使い続けてる会社いくつも知ってる

バックエンド開発とフロントエンド開発で体制分けたのはいいけど
コミュニケーションロスやお互いの作業待ちでスタックしまくる
プロジェクトとかも。

プロジェクト管理や設計のやりかたが今までと同じで
それを変えられないってのがうまくいかない最大の要因な気がする。

304:デフォルトの名無しさん
14/04/12 11:09:01.50 hPdTJsHF
業務アプリごときJSF2で困ることがない

305:デフォルトの名無しさん
14/04/12 11:58:38.19 qS4Q8Ow0
まぁそれも１つあるよな。
業務アプリに見栄えのするUI/UXの必要性なんて
そもそもユーザーが求めてないわけだし。

306:デフォルトの名無しさん
14/04/12 12:10:13.70 ONqK3e5x
ほんそれ
客にオナニーみせつけんなって話し

307:デフォルトの名無しさん
14/04/12 19:48:03.14 r3JAB95t
JSF2とSpringMVCなら後者で

308:デフォルトの名無しさん
14/04/12 20:35:30.10 g8OqBVnG
用途によるよ。
業務アプリと一口にいっても、グリッドとフォームだらけのLOBアプリならJSFで良いし、
それとは別に情報ポータル/分析系みたいなものもあって。
後者については実際ソーシャル系みたいなニーズが求められるから。

っとSI屋で後者をメインにやっている人より。

つーか、前者みたなものをシコシコ作っていて、何が楽しいんだと思ったりはする個人的な意見ですが。

309:デフォルトの名無しさん
14/04/12 21:16:25.65 SAIw86Ow
前者みたいなの作ってて楽しくもなんともないけど仕事あるだけマシと思ってる

310:デフォルトの名無しさん
14/04/12 21:20:03.72 ONqK3e5x
俺も楽しいことは趣味でやってる

311:デフォルトの名無しさん
14/04/12 22:27:17.38 rg8ub121
仕事

312:デフォルトの名無しさん
14/04/12 23:54:13.53 r3JAB95t
JSFはブラックボックス

313:デフォルトの名無しさん
14/04/13 12:09:15.45 IgSj2Mvb
動けばいいのよ
保守するのは自分じゃないし

314:デフォルトの名無しさん
14/04/13 12:46:33.29 pKpG+lHA
やっぱり今から勉強するならspringが無難だよね。

315:デフォルトの名無しさん
14/04/13 17:12:24.83 ifFweta+
>>313
お前、お前みたいな奴が、お前な、マジでお前
お前ーー！

316:デフォルトの名無しさん
14/04/13 19:33:38.13 FZex5Lh6
仕事だからとか、意外とみんな真面目なんだな。

317:デフォルトの名無しさん
14/04/13 22:52:01.73 6wRC3zPh
URLﾘﾝｸ(gihyo.jp)

>>301の記事に２つの方法が書かれているけど
それぞれのメリット、デメリットはどういう感じなの？
「次世代型」はJavaScript有効化必須として
開発の生産性はどちらのが上？

「Oracleエバンジェリストの寺田氏は，Java標準によるWeb開発を，
次世代型と従来型の2種類に分類しました。

次世代型：クライアントとサーバ間をデータのみで通信し，画面の
生成から表示までをクライアントで行う方式。
従来型：サーバ側でデータを埋め込んだ画面を生成し，クライアント
では表示のみを行う方式。」

318:デフォルトの名無しさん
14/04/14 00:44:17.72 S4Y/C9C3
>>317
次世代型って>>303みたいなの？
今の時点での生産性なら従来型じゃね
次世代型とか慣れるのに苦労しそう

319:デフォルトの名無しさん
14/04/14 00:47:17.09 VmjrJFRy
>次世代型：クライアントとサーバ間をデータのみで通信し，画面の
>生成から表示までをクライアントで行う方式。

Oracleの中の人ですら、まだこんなこと言ってんだもんな。
認識の周回遅れも甚だしい。
そりゃ日本のSIerが斜陽産業化するわけだわ。

320:デフォルトの名無しさん
14/04/14 00:48:12.31 K3Aga8vq
>>319
じゃあ本当の次世代型は？

321:デフォルトの名無しさん
14/04/14 00:49:40.99 vxOO2AsC
>>318
>>317のURLに書いてある「次世代型」。

生産性が低いなら海外で人気になったりしないと思う
なんで日本だけStruts使ってる化石企業ばかりなんだろう

両方とも経験ある人の意見が聞いてみたい。

322:デフォルトの名無しさん
14/04/14 00:50:10.04 Bgbj7M78
XML+XSLTで昔からできたのに全然普及しなかったな

323:デフォルトの名無しさん
14/04/14 01:09:57.18 VmjrJFRy
>>320
Oracleの中の人の認識だと、まだajax使ったREST+JSON止まりなんだろう。
もうすでに、pjax+pushStateがメインで、今までのjsonベースの仕組みは
補助的に使う感じの動きになってきてる。

特にクライアントがモバイルの場合、SPA構成だとpjax+pushStateにしないと
いろいろ画面遷移周りの実装が複雑になりがちだし、
業務アプリ以外の外向けWebサービスなんかの場合は、サーバからJSONだけ
返してもらってクライアントでDOM生成する設計だと、SEO対策的にも高コスト。

とはいえ、イントラ系業務システム限定なら、REST+JSONでも何ら問題ないけど
だったらStruts1.x（）でもいいだろって話になる

324:デフォルトの名無しさん
14/04/14 01:19:47.94 Bgbj7M78
pjaxも所詮RESTじゃん
JSFと違ってJAX-RSにVIEW実装なんて定義してないぞ

325:デフォルトの名無しさん
14/04/14 02:26:03.09 3UflCQPn
次世代型って要はAjaxとJQueryでUI手書きかGWTってことでしょ。
旧来型には、javascriptを隠蔽するJSPタグライブラリとか
Wicketコンポーネントなんかがこちらに含まれるのかな。

326:デフォルトの名無しさん
14/04/14 04:19:53.32 K3Aga8vq
>>323
元々PushState + Ajax = Pjaxじゃねーの？
そのPjaxにもう一回PushState加えるってどういうことだよ？w

327:デフォルトの名無しさん
14/04/14 18:51:03.43 0uxeI5tF
10年前からメンテしてるサイトは素のServlet/JSPで作ったが
流行に乗ってstrutsとか導入しなくてよかった。
長期開発・運用だと技術スタックは小さいほどいいね。
仕事だと「最新の開発手法」とやらの圧力が高くて抗えないけど・・

328:デフォルトの名無しさん
14/04/14 19:02:38.25 xOOCf4Oc
Servlet使ってるところのソースは大抵糞コードだから読まされる立場だとうんざりするけどな

329:デフォルトの名無しさん
14/04/14 20:01:34.37 K3Aga8vq
このスレっていつもループしてるよね・・・
適当に上の方へ戻っても話がつながって読める

330:デフォルトの名無しさん
14/04/14 21:13:37.20 A+X5vC8x
まったくなｗ

331:デフォルトの名無しさん
14/04/15 00:54:06.51 fDug8lKN
>>325
jQuery手書きは旧世代だね。
AngularJSはjQuery使わないし、Backbone.jsでもテンプレートエンジンや
Marionettoとかのプラグイン使えばjQueryは隠蔽されるのが現世代。
AngularJSやBackbone.js使えば意識するまでもなくPushStateも使われるんだが、
>>323は何を次世代だと言ってるんだろうか？
ブラウザ側から見た新世代はWebComponents抜きには語れそうにない。
SEO含めた取り組みはRendrのやり方が新世代になりそう。

332:デフォルトの名無しさん
14/04/15 01:04:58.06 W7pkbwhx
Oracleの人は立場上、自社のJava EE7を推したいわけでしょうから
Java EE7標準を使った開発が、オラクルの言う「次世代型」でしょう

>>323
＞だったらStruts1.x（）でもいいだろって話になる
よくないでしょう
>>301の記事内でも指摘されているように
セキュリティ上の理由で、メンテナンス終了したStrutsはもう新規に使えない。

>>331
Javaはいろいろやり方があってわけがわからないよ
その辺の新しい開発方法をわかりやすくまとまめてあるサイトや本は
ありますか？

333:デフォルトの名無しさん
14/04/15 01:16:41.62 QjDXpoj9
phpだとcakephpが個人・学生から企業まで定番化してるっぽいけど
jsf2とかspringmvcがその地位には立てそうにないなー

334:デフォルトの名無しさん
14/04/15 01:26:31.68 fDug8lKN
>>332
わけがわからないのはJavaじゃなくてJavaScriptのことだと思うけど、
とりあえず一つ追っかけるなら、今だとAngularJSがいいんじゃないかな。
読んでないけど日本語の本も一つ出てるし、来月にはオライリーの翻訳本も出る予定。

335:デフォルトの名無しさん
14/04/15 01:56:57.27 v7jURM3H
JavaScriptは、後から後から話題になる要素技術がどんどん出てきて
トレンドが変わっていく
アメリカではそういうの自分たちでどんどん作って送り出すけど
日本じゃそれを表向きはドヤ顔で、内心ヒーヒー言いながら追いかけて
疲弊するだけ
不毛すぎる

336:デフォルトの名無しさん
14/04/15 02:22:34.80 1MwGXkoj
そろそろ表向きドヤ顔もできない感じになってきたわ
Webアプリやりたくねぇよ

337:デフォルトの名無しさん
14/04/15 07:34:40.23 dqyEhytG
Web系はドヤってなんぼだろw
黙々と作業だけしてたら底辺臭が滞留してきちゃうからね

338:デフォルトの名無しさん
14/04/15 08:14:59.36 v7jURM3H
去年辺りまではbackbone.jsがオススメされて
今年はAngularJSがはやってるよね
来年はまた別のものが流行して
再来年にはまた別のトレンドが来る
一貫してるのはなんだかんだでjQueryがデファクト

339:デフォルトの名無しさん
14/04/15 15:28:26.34 okfDyzRj
ドヤ顔で講釈垂れてもな・・・
職場の人間は正直だと思うぞ

340:デフォルトの名無しさん
14/04/15 20:31:58.52 2GI32+no
最近の流行はJsViewsじゃないの？

341:デフォルトの名無しさん
14/04/16 01:13:38.68 JEVwiYNE
>>335,338
Javaも以前は同じだったじゃん
2000年にStruts 1.0とTapestry 1.0、2001年にWebWork 1.0、
2003年にJSF 1.0、2005年にWicket 1.0、2006年にClick 1.0…
ORMやDIコンテナも含めるとあの頃のJavaは今のJSよりもいそがしかった気がするけどな。

あとアメリカ人がみんな「自分たちで送り出す」なんて思ってないだろう。
ひがやすをがSeasar2を出したからって日本人がみんなそう思わないのと同じで。

342:デフォルトの名無しさん
14/04/16 01:13:43.98 F5idbQac
jQuery以外はdartでも触ってたほうが良さそう

343:デフォルトの名無しさん
14/04/16 01:15:52.69 F5idbQac
ひがやすを & やねうらをは兄弟らしい

344:デフォルトの名無しさん
14/04/19 04:47:43.50 FUH9Y5av
こういうの見ると、継続的なサポート力というのは重要だなあと。
5年後はすたれてそう・・みたいなフレームワークへの依存は避けたい・・

Apache Struts2 脆弱性に注意、IPA
URLﾘﾝｸ(news.mynavi.jp)

345:デフォルトの名無しさん
14/04/19 09:22:13.99 0YBgM8kF
Struts2は後年にフレームワークの歴史における失敗作として語り継がれそう
やはり兄より優れた弟など存在しないんだ

346:デフォルトの名無しさん
14/04/19 10:16:08.10 Ak5/X6S3
Struts3ってどうなったんだ？

347:デフォルトの名無しさん
14/04/19 12:31:51.21 mSHOuAyg
正直もうJava EE一本化でいいんじゃないのか
標準だからStrutsやSeasarみたいに数年でオワコンにはならんし

348:デフォルトの名無しさん
14/04/19 21:06:21.46 w81l5j3j
アクションベースのWeb FW、モダンなテンプレートエンジン、Micro-ORM
…を熟れるレベルまで標準化してくれるなら、そしたらEEでも良いよ、
っという意見は昔からあるけどな。

349:デフォルトの名無しさん
14/04/22 20:51:03.30 rtReb1s3
NodejsやAngularJS使っている開発でyeoman入れている人いる?

350:デフォルトの名無しさん
14/04/23 21:47:01.86 bQZ6NqwX
例えば、Strutsを避ける
URLﾘﾝｸ(www.scutum.jp)

Struts2は根本的設計がまずかったり今のメンテナにとって
やる気のでないプロダクトだったりって状態なのかねえ
SIerが貢献することもなく使い続けて情報漏洩しまくらないといいが

>>349
JSの話題はここでは返事もらえないと思うよ

351:デフォルトの名無しさん
14/04/24 01:22:07.08 uw+Asd59
node.js使ったサーバーサイド開発やってるのに
未だにJavaとJavaScriptの違いが解らないアホがいるってのが驚きだわ

352:デフォルトの名無しさん
14/04/24 01:26:25.43 FuqK6IF4
>>350
そのエントリ書いた人、StrutsとStruts2は全くの別物だってことと、
Struts2は少なくとも日本じゃポピュラーじゃないってことを知らなさそう

353:デフォルトの名無しさん
14/04/24 22:11:08.66 MRzySO8u
今更?。Struts2は出た当初から致命的な脆弱性がある欠陥品だと言われていたでしょ。
MBSDで暫定的なものであるが、サーブレットフィルタのソースコードを公開したよ。
URLﾘﾝｸ(www.mbsd.jp)

354:デフォルトの名無しさん
14/04/24 22:42:18.68 MRzySO8u
最近、JavaEEやspringMVCからJavascriptへ
トレンドが移行している印象を受けるね。

JavaSE8もあまり話題にならないけど、どうなの?

355:デフォルトの名無しさん
14/04/24 23:17:35.98 cbIcERKc
【IT】サイト構築ソフト・ストラッツ1(Struts 1)に欠陥　パッチなく官公庁などサイバー攻撃の恐れ [4/24]
ｽﾚﾘﾝｸ(newsplus板)

Struts 1.x使っていた時代遅れ企業終了

>>354
その印象を持ったのはどういう理由？
Java開発案件が減ってJSが増えてる？

356:デフォルトの名無しさん
14/04/25 22:40:29.27 FYFW/3hR
>>355
開発案件に影響は出ていないが、技術的な部分が日進月歩なので表面化しつつある。
WebがHTML5に向かう中で、Javaが担う機能を、どこまでJavascriptで
担えるかというところで微妙になってきた。
基幹業務システムをJavascriptで作る時代がきそうだと。

357:デフォルトの名無しさん
14/04/26 10:22:26.71 /UOqj8HA
乱暴に言えば基幹システム＝DBアクセスだから、サーバサイド開発をゼロにするって無理だろ
JavaScriptから直接SQL叩くことを許可するのか？

358:デフォルトの名無しさん
14/04/26 12:23:42.67 lOzkg/HI
>>357
クライアントではなくてサーバーサイドJavascriptの話をしているのだから
それ的外れな指摘だよ

>>356
Javascriptって、もともとDOM(xml/html)を操作して
画面UIを操作するためにあるような、それくらいしか能がない言語でしょ。
サーバーサイドには機能面で非力すぎるし、また独自仕様乱立とか始めるのがオチ。

359:デフォルトの名無しさん
14/04/26 14:17:54.62 0Ekcs7fW
>>356
＞基幹業務システムをJavascriptで作る時代がきそうだと

これは絶対に来ない
もし基幹業務をJSで作ったとしたら大バカ企業

動的言語は大規模開発だと開発生産性が落ちる。
このデメリットが大きいからFacebookなどもPHPを
静的言語に魔改造しようとしてきた。

JavaがゴミみたいなWebフレームワークしかないのに
大規模サイトで使われてきたのは、静的言語で、
ライセンスが比較的自由だからだろう

360:デフォルトの名無しさん
14/04/26 14:50:52.36 9olkSe8L
サーバーサイドJavaScriptといえばIBMがこういう記事出してるな。
URLﾘﾝｸ(www.ibm.com)
それにIBMのBlueMixなんかは基幹系開発も用途に含むPaaS環境だけど
node.jsやRubyも対象にしてる。

まぁ日本のイントラ基幹系は業界的にも従事する人間の考え方的にも
頭が硬くて柔軟性に欠けるから、node.jsベースの開発なんて無理だろうけど
B2CとかのエンドユーザーがコンシューマーだったらサーバーサイドJavaScriptは
ぼちぼち盛り上がってるんじゃね。

JDK1.0が出た当時だって、動きのあるホームページ作るものでしょ的な
イメージばかりで将来まさかJavaがビジネス基幹系に使われるように
なるなんて誰も想像しなかったわけで。

静的型付けができないとか型推論とか言語仕様的にはJavaScriptそのものは
いろいろ欠点あるけど、CoffeeScript/TypeScript/HaxeとかのAltJSを使えば解決できる。

361:デフォルトの名無しさん
14/04/26 16:46:48.48 Gh1hsEgS
JavaScriptもこんな流行るとは思わんかったよ

362:デフォルトの名無しさん
14/04/26 17:49:10.55 A9kxPHhN
現状ではpaypalの開発が代表的かな。
URLﾘﾝｸ(www.infoq.com)

363:デフォルトの名無しさん
14/04/26 20:18:05.95 lOzkg/HI
node.jsでサーバー書くより
ブラウザでjavaなりc#が動いてくれたほうがよっぽどありがたい

364:デフォルトの名無しさん
14/04/26 21:29:20.02 ro7ZL/nR
>>357-358
SQLではないけどAWSのDynamoDBはブラウザのJSから直接アクセスするための機能が
既に備わってるからあながちあり得ないって事はない

URLﾘﾝｸ(aws.typepad.com)

セキュリティ的には現在のアプリサーバのように一つの権限で全ユーザの情報に
アクセスしてる方がリスクが高いという考え方もできなくはないしね

>>360
そうそう、世紀末くらいまではJavaに対しても>>359みたいな意見が普通だったよね
OSでいえばLinuxもそうだし、その前はWindows、更に前はUnixも基幹系では
使えないって意見が多数派だった
ハードでもPC(x86)サーバもUNIX(RISC)サーバも最初は同じ
それでも使う人達がでてくることでいずれ使えるようになってく
繰り返される歴史からはJSで基幹系作る日が来ないとはとても言えない
個人的に作りたいかどうかは別の話だがw

>>362
世界規模の決済系で使われてるってのは実績としてでかいよね

>>363
Dartがブラウザに乗れば一応それらに近いんじゃないかな

365:デフォルトの名無しさん
14/04/26 21:42:46.56 ro7ZL/nR
あと動的言語かどうかはもちろん、生産性も基幹系で使うかどうかにはたいして影響ないよ
今基幹系で使われてる言語でもCやCOBOLは弱い片付けの言語だし生産性も高くない
それよりベンダのサポートとか人の集めやすさとか世界中で使われてる実績とか
技術とは無関係なところで決まりやすい(それを肯定したいわけじゃないが現実としてね)

366:デフォルトの名無しさん
14/04/26 22:40:13.33 0Ekcs7fW
>>365
大規模開発での静的言語の優位性を否定するとかありえないわ

それとベンダサポートが重要なのはそのとおりだが
人気のある静的言語ほど大手のベンダーが関与してる割合が高い
C#もJavaもそう

動的言語はコンパイラ開発不要で個人レベルでも
作れるからOSSで言語が乱立する
頻繁に不要な仕様変更が入りメンテナンスコストが高くなる
開発生産性というのはバージョンアップなどのコストも含めての話

367:デフォルトの名無しさん
14/04/26 23:26:36.12 ro7ZL/nR
>>366
優位性を否定してるんじゃなくて、その優位性が重要な要素とはならないって言ってる
まぁ、スレ違い気味だしわかれとはいわんよ

次ページ