【Java】 Java Web Ap ..
430:デフォルトの名無しさん
13/04/01 07:00:39.53
フレームワーク使わない人ってURLマッピングはどうやっているのだろう。
例えばクエリーを使ったレガシーなURLﾘﾝｸ(aaa)みたいな
URLではなく、よりRESTfulなURLﾘﾝｸ(aaa)みたいなURLを使う場合。
フレームワーク無しの生Servertだと毎度自前でpathをパースしたりサブリソース毎に条件分岐したりと
手作りできるにせよ無駄に面倒だと思う。
431:デフォルトの名無しさん
13/04/01 11:03:54.12
>>430
mod_rewrite
432:デフォルトの名無しさん
13/04/01 11:09:20.88
自前でパースしないと遅いしな
433:デフォルトの名無しさん
13/04/01 17:14:29.59
面倒を厭わない人たちなのはよく解った。
434:デフォルトの名無しさん
13/04/01 17:20:23.50
>>433
面倒を避けようとしてさらに面倒なことになってる印象。
435:デフォルトの名無しさん
13/04/01 22:00:58.98
でもSEO対策が入ってくるとできあいのフレームワークじゃ難しいんだよな
みんなどうしてるか、そっちのが気になるわ
436:デフォルトの名無しさん
13/04/01 22:09:02.05
JSFだのASP.NETだのはイントラじゃなきゃ難しいな
437:デフォルトの名無しさん
13/04/01 22:22:26.68
>>435
どうやってタグを吐くかだから
フレームワークは無関係
438:デフォルトの名無しさん
13/04/01 22:48:03.67
JSP&Servletだけで十分フレームワーク
439:デフォルトの名無しさん
13/04/01 22:50:16.68
URLについては、Struts時代はRouter自作。
Spring MVCでは無問題。
440:デフォルトの名無しさん
13/04/01 23:19:13.95
jspの文字コードがshift_jisで、サーブレットの文字コードがutf-8で書かれている場合、
jsp → サーブレット → jsp でformパラメータの受け渡しで日本語が文字化けしないようにするには
どうしたらいいでしょうか？
サーブレット側で
変数 = new String(request.getParameter("パラメータ名").getBytes("Shift_JIS"), "UTF-8"));
としてPOSTパラメータを受け取ってUTF-8として処理し終わった後、
変数 = new String(変数.getBytes("UTF-8"), "Shift_JIS");
としてShift_JISに戻して
request.setAttribute("jspで受け取るパラメータ名", 変数);
としたのですが文字化けしてしまいます。
441:デフォルトの名無しさん
13/04/01 23:30:22.30
>>440
JSPの先頭
<%@ page contentType="text/html; charset=UTF-8" pageEncoding="Windows-31J" %>
Servlet
req.setCharacterEncoding("UTF-8");
こうだったかな。JSPファイルもUTF-8にしちゃえば管理も楽だと思うのだけどねぇ
442:デフォルトの名無しさん
13/04/01 23:33:39.56
>>441
すいません。jspは文字コードを使い分けたいので、そのやり方はダメなんです・・・。
あくまで違う文字コードでの受け渡しでやりたいんです。
443:デフォルトの名無しさん
13/04/01 23:41:07.31
Java内部の文字列処理はUTF-16だよ
サーブレットの文字コードって表現が既におかしいんじゃない？
JSPのcharsetもSJISにしたいなら
req.setCharacterEncoding("Windows-31J");
とサーブレット側で受ければいい
444:デフォルトの名無しさん
13/04/02 00:05:07.91
>>443
サーブレットのソースコードのテキスト文字コードがUTF-8ってことです。
サーブレット側では冒頭で
request.setCharacterEncoding("Shift_JIS");
response.setCharacterEncoding("Shift_JIS");
と書いています
445:デフォルトの名無しさん
13/04/02 00:29:51.55
>>443
ああ、サーブレット側でsetCharacterEncodingやsetConentTypeで
Shift_JISを指定するだけで行けました。
サーブレット内での余計な変換処理は要らなかったんですね。
どうもです。
446:デフォルトの名無しさん
13/04/02 02:15:06.83
>>438
>JSP&Servletだけで十分フレームワーク
これはマジでそう思う。
ただ他方で機能不足なフレームワークはその上にオレオレフレームワークが育つ格好の培地でもある。
447:デフォルトの名無しさん
13/04/02 04:23:34.10
JSPはServletのフレームワークだな。
JSP嫌いだから引っこ抜いちゃうｗ
448:デフォルトの名無しさん
13/04/02 04:40:47.74
>JSP&Servletだけで十分フレームワーク
ただしServlet3以降に限る
449:デフォルトの名無しさん
13/04/02 10:51:31.04
Servlet2.5 と Servlet3 で大きな違いってあるの？
Servlet3はほとんど追いかけてないのですが、
HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい
ぐらいのことしか知らん。
450:デフォルトの名無しさん
13/04/03 08:10:55.48
ないと思うなー。
＞HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい
フレームワーク自体を作る側の人にとって嬉しいくらいじゃね？
451:デフォルトの名無しさん
13/04/03 08:15:23.37
そもそもアノテーションとか要らない
452:デフォルトの名無しさん
13/04/03 08:21:53.88
なにいってるんだか
xml地獄を解決するために生まれたのがアノテーションでしょ
453:デフォルトの名無しさん
13/04/03 08:24:32.09
フレームワークさえなければXML地獄もなかったのに
454:デフォルトの名無しさん
13/04/03 08:29:46.34
>>453
GrailsはXML地獄なかったよ
XML地獄のフレームワークはほんと時代遅れ
コードが見づらくなるし、コンパイラで検出できないエラーがでる。
なるべくコードで設定するってのが流行りだし、アノテーションは必須の機能
455:デフォルトの名無しさん
13/04/03 08:31:41.31
じゃあなんでSQLをXMLに外出しするような糞ORマッパを
勧めたりするんだ？
456:デフォルトの名無しさん
13/04/03 08:38:17.94
>>455
アンカーくらいつけてまともな日本語で書けよ
何が言いたいんだ
457:デフォルトの名無しさん
13/04/03 08:43:30.16
フレームワークとかORマッパが嫌い
458:デフォルトの名無しさん
13/04/03 08:47:54.30
>>457
だったらこのスレを見るなよ
459:デフォルトの名無しさん
13/04/03 08:53:54.35
いやさすがにわかるだろw
XML地獄を敬遠するくせにSQLはXMLいいのかってことだろ？
Javaの中でしか使わない設定はアノテーションとかでJavaの中に取り込んでいいと思うんだけど、
SQLについてはDBに流して確認とかよくやるから中に入り込まない方がいいな
今の所はSeaser系の2-way SQLが一番その辺り楽にできる
パラメータをSQLコメントに追い出すことで文法エラーにしないのは秀逸だと思った
460:デフォルトの名無しさん
13/04/03 09:04:33.36
海外だとHibernateが第一選択肢でそれ以外は比較的測定限界以下なのに、日本だとMyBatisとか
ガラパゴスフレームワークの類が幅をきかせているのは何か特殊事情があるのかな。
461:デフォルトの名無しさん
13/04/03 09:20:17.93
外出しすれば綺麗だと思うのは間違い
C++になっても変数宣言を関数の先頭でやるくらい汚い
462:デフォルトの名無しさん
13/04/03 09:21:15.39
全部のORMがXML使うわけじゃないし
TypesafeなORMが良ければそういうORMと組み合わせて
使えばいいだけだろ
入れ替えて使えるようにDIとかがあるわけで
うんこフレームワークを体験したからといって
フレームワーク全体を否定するのはアホ
うんこORMを体験したからといって
ORM全体を否定するのは馬鹿
463:デフォルトの名無しさん
13/04/03 09:23:53.81
いろいろなフレームワークがあること自体間違い
464:デフォルトの名無しさん
13/04/03 10:28:49.35
SQL外出しなオレオレフレームワークは色んな現場で見てきたけど、大体良い思い出が無いなぁ…。
大体SQLだけメンテしようとして、SELECT項目やバインド変数の数間違えてトラブるのが定番だった気がする。
事前にコンパイラみたいなのでチェックできるならいいんだけどね。
465:デフォルトの名無しさん
13/04/03 11:36:08.03
とりあえずSeasar信者の受け売りが嫌だ
466:デフォルトの名無しさん
13/04/03 11:47:15.81
色んなフレームワークがあるのは構わんけど、色んな実装があるのは嫌だ。
JAX-RSとかJSF、JPAとか。
つーか、WebやORMのフレームワークで、わざわざ仕様と実装をわける意味がわからん。
結局、実装固有の拡張機能を使わないと使い物にならなかったりするし。
467:デフォルトの名無しさん
13/04/03 12:02:47.87
>>466
その無駄な複雑性はJavaの悪いところだし
ORACLEが無能だからだろうな
468:デフォルトの名無しさん
13/04/03 13:39:18.89
継承や委譲を使うべきところまでPOJOがどうのこうのとアノテーションだらけにする
無能な糞フレームワークがあるな。S2なんとかーだけど。
469:デフォルトの名無しさん
13/04/03 13:55:01.70
自分も Hibernate より MyBatis のほうが好きなタイプだが、
Hibernate は嫌われるのに、Rails の ActiveRecord がみんなに受け入れられているのはなぜだろう？
両方とも似たようなタイプなのに
470:デフォルトの名無しさん
13/04/03 14:58:00.57
規約やアノテーションを活用する今のHibernateではなく、XML地獄時代のHibernateのイメージ
があるからじゃないのかな。
471:デフォルトの名無しさん
13/04/03 16:26:08.57
ActiveRecordが受け入れられている理由
-> RoRを使用するような用途/データモデルではそれで困らないから
Hibernateが受け入れられない理由
-> Javaがおそらく最も使用されているユースケース/データモデルではそのAPIモデルでは困るから
ソーシャルなWebアプリっぽいもの、DOA世界な帳票とかのLOBアプリでは、APIに求められるインターフェースも違うだろうし。
472:デフォルトの名無しさん
13/04/03 19:43:14.80
そういやhibernate entity manager経由でしか触ってないな
今って生hibernateどうなってんだろ
後で試してみるか…
473:デフォルトの名無しさん
13/04/03 20:06:18.41
>>471
でもそれだけだと内外差の説明はつかないなぁ。
474:デフォルトの名無しさん
13/04/03 20:33:32.91
>>469
RailsのようにConvention over Configurationが徹底した
フレームワークだと、ほとんどORMの設定することなく使える。
Javaの場合、RailsほどCoC重視したフレームワークがまだ少ないから
Hibernateのめんどうなマッピング設定が必要になって、嫌われるのでは
>>470 のいうように、昔のXML地獄のHibernateしか知らない人もいる
のも原因かもしれない。
475:デフォルトの名無しさん
13/04/03 21:17:53.29
>>473
ニホンジンはガイコクジンに比べて帳票ダイスキー、っという説はどうだろう？
- 帳票の出力内容はSQLレベルで複雑な処理を書くのが一番効率的
- その場合、求められるAPIは文字列としてのSQLをそのまま実行できるようなもの
- 日本において、Javaはもっぱらそういうアプリを作る用途で使われている(土方的な)
- そういう現場にHibernateを持って行っても(ﾟДﾟ)ﾊｧ?
国内では受け入れられていない理由が、昔のXML地獄のイメージがあるからとかっていうのは、
自分としては枝葉の話な気がするが。
476:デフォルトの名無しさん
13/04/03 21:21:36.90
>>472
そういやHibernate4はEntityManager/Annotationsがネイティブになって
旧APIとXMLマッピングがその上のラッパーになるってどっかで見たけど
実現してないんだな。今もドキュメントはXMLマッピングから始まる
477:デフォルトの名無しさん
13/04/03 21:44:55.39
>>473
日本のIT業界が世界に取り残される一番大きな理由は
大半が英語ができないからだよ
英語のドキュメントが満足に読めない人ばかり。
日本語の書籍がでて日本語情報が充実してこないと普及しない。
478:デフォルトの名無しさん
13/04/03 21:51:43.05
iBatis/MyBatisなんて日本語の情報が充実してなくても結構使われてるだろ
Springだって使われてる度合いに比べたら日本語の情報は少ないし
Hibernateは使われてない割に情報多い
たいして相関してる気がせんな
479:デフォルトの名無しさん
13/04/03 21:55:28.57
ぶっちゃけStringの連結なんてしたくないわ
テキストに書けるならそっちの方がチューニングもしやすいでな
480:デフォルトの名無しさん
13/04/03 22:02:27.77
>>478
Batis系はHibernateよりも単純だから英語のドキュメント
読めなくてもなんとかなるからだろう
Hibernateのほうがはるかに高機能な分、覚える概念が多い。
Hibernateの本、日本語のもあるけど今のと違いすぎて役経たないと思う
英語弱者にとって厳しいのがHibernate
ORMにしてもEntityベースでやるのが主流になってるし
SQLに近いBatis系はもう海外では流行ってない。
疑うならwebフレームワークの採用ORM見てみなよ
481:デフォルトの名無しさん
13/04/03 22:04:26.47
内外差以前に海外の実情がわからんのだよな
いつまでもTomcat使ってるのは日本だけと某エバンジェリストが言ってたけど
URLﾘﾝｸ(www.javacodegeeks.com)
を見ると海外でもTomcat強いしJetty含めてJavaEEじゃない方が主流だよな
海外じゃJSFやJPAが普及してるってのもどこまで本当か…
マーケティングに釣られてるんじゃないかと思うことがある
482:デフォルトの名無しさん
13/04/03 22:07:31.15
>>480
> 疑うならwebフレームワークの採用ORM見てみなよ
Playじゃebeanやnormも採用されてる件
483:デフォルトの名無しさん
13/04/03 22:36:07.96
英語・日本語にかかわらず、ドキュメント読まなくても使えるシンプルなのがいいのは確かだな
484:デフォルトの名無しさん
13/04/04 00:51:54.82
Struts1のEOLが決定しました
URLﾘﾝｸ(www.h3.dion.ne.jp)
潮流が変わるきっかけになるかね？
485:デフォルトの名無しさん
13/04/04 02:02:52.91
RailsとHibernateが同じようなものというのはない
JavaのフレームワークはXML地獄かアノテーション地獄
Railsなんて学習コストやハマりコストめちゃ低いぞ
486:デフォルトの名無しさん
13/04/04 02:21:25.71
こんな簡単なSQLで苦労するところ見ちゃうと学習コストが低いなんて信じられん
URLﾘﾝｸ(qa.atmarkit.co.jp)
487:デフォルトの名無しさん
13/04/04 04:49:50.13
う〜ん規約に従っている限りHibernateのアノテーションの量なんてたいしたほどではないと
おもうのだが。規約から外れるとマッピングの記述量が増えるのはRailsも一緒だし。
488:デフォルトの名無しさん
13/04/04 07:30:48.85
>>485
名前だけでなくGrailsはRailsとかなり似てるから楽でいいよ
Javaを知っている人ならGrailsのが学習コストは低いとおもう。
>>484
日本の遅れたIT業界のことだから、ダメなのわかっててStruts2
に移行したりするんだろうなぁ
489:デフォルトの名無しさん
13/04/04 07:35:07.70
>>484
フレームワークなんか使うからこうなる。
490:デフォルトの名無しさん
13/04/04 07:44:26.43
>>489
お前自身がEOLってことに気づこうな
491:デフォルトの名無しさん
13/04/04 07:49:20.30
Grails、確かに使いやすいのだがRailsに似せるのに頑張りすぎていてかえってJava観点では
アレになっている部分も少なくないと思う。
例えばmappingsやtransientといったORMの定義、staticフィールドにRails風に記述できる
ようになっているけれども、型安全じゃないし正直JPA風のアノテーションの方がシンプルで
良かった。まあHibernateで定義したドメインクラスをインポートすれば良いのだけど。
あとビミョーに謎な振る舞いに悩むこともある。先日もドメインクラスにコンストラクタを定義
して使っただけでDIが動かなくなって暫し悩んだ。
492:デフォルトの名無しさん
13/04/04 07:49:35.61
>>489
まだこのスレにいたのか
必死にフレームワーク否定してるけど何つかったことあるんだよ
493:デフォルトの名無しさん
13/04/04 07:56:46.99
>>488
Javaのフレームワークにはいつも期待を裏切られてるけど
最後の最後ということでやってみるよ。アドバイスありがとう
494:デフォルトの名無しさん
13/04/04 08:05:53.42
作っては捨て作っては捨て
こんなのシステム開発では使えないよ。
趣味のプログラミングなら好きにやってくれていいけどさ。
495:デフォルトの名無しさん
13/04/04 08:52:46.84
>>494
毎回作り直してる俺々フレームワークのことですね、わかります
496:デフォルトの名無しさん
13/04/04 08:58:09.84
WicketライクなFW普及してくれ〜
497:デフォルトの名無しさん
13/04/04 08:59:04.31
>>495
受託や派遣ばかりやってるからそういう発想になるんですね。わかります。
498:デフォルトの名無しさん
13/04/04 09:18:37.61
>>496
Wicket的な役回りはAngularJSとかブラウザ側でJSの時代だろ
499:デフォルトの名無しさん
13/04/04 11:52:00.96
>>493
まだGrailsのチュートリアルやってるレベルだけど
最新の2.2.1はエラー出たから、2.2.0で試すのがいいかもしれない。
v2.2.1だと、controller作成時に下のようなエラー出る
2.2.0なら大丈夫。
grails> create-controller hello
| Error Error running script create-controller hello: _GrailsCompile_groovy$_run_closure1
(Use --stacktrace to see the full trace)
grails>
指示通り、--stacktraceしてみると、
grails> --stacktrace
| Error Error running script --stacktrace: Cannot invoke method findAll() on null object (NOTE: Stack trace has been fil
tered. Use --verbose to see entire trace.)
java.lang.NullPointerException: Cannot invoke method findAll() on null object
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1243)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1243)
| Error Error running script --stacktrace: Cannot invoke method findAll() on null object
500:デフォルトの名無しさん
13/04/04 20:48:10.99
JSFってFacelets+CDIだけやれるっけ？
バッキングビーンの思想は素晴らしいけど管理ビーンとCDIが別れてるのが糞すぎる
501:デフォルトの名無しさん
13/04/04 22:33:20.22
javascriptの時代が来る気がする
最近のjavascriptのライブラリは凄まじすぎるわ
jqueryuiとか、datatablesとか、jquery.sheetとか
マジでなんでもできるんだな
サーバーサイドもNode.jsになるんじゃないかな
ブラウザの開発ツールやらcloud9やらと、開発環境も整いつつあるし
Javaは下火になりそう
502:デフォルトの名無しさん
13/04/04 22:35:35.96
フレームワーク乱立のせいだな
503:デフォルトの名無しさん
13/04/04 22:41:00.19
>>501
その3つどれもただのjQueryのプレゼンテーション層よりの機能じゃないか
jQueryは他の言語のフレームワークでも連携させて使えるし、
サーバサイドが強いJavaとは強みのあるエリアがちがうよ
本格的なオブジェクト指向言語にすらなれてないJavascriptで
開発なんてしたくない
504:デフォルトの名無しさん
13/04/04 22:54:27.01
>>501
phpと争って削ってくれたらそれで十分な感じかな
あいつらだけはマ名乗ったらいかんレベル
505:デフォルトの名無しさん
13/04/04 22:59:26.63
apache cgi javaとかあればなー
506:デフォルトの名無しさん
13/04/04 23:23:40.46
>>503
それがさ、今single page applicationとかってのが流行ってるらしくて
サーバーサイドのコントローラの機能をクライアント側が吸収し始めてるんだよ
ライブラリさえあれば普通に本格的なオブジェクト指向言語だし
backbone.jsとかember.js見て驚愕した
requirejsやらcommonjsやらでモジュールもできるし、ビルドツールもある
qunitとかphantom.jsとかでテストも完備
サーバーサイドでormっぽいことも出来るみたいだし
URLﾘﾝｸ(nodejsdb.org)
ちょっと首を突っ込みはじめたんだが、マジで最強かも
ものすごいコミュニティができつつある
507:デフォルトの名無しさん
13/04/05 00:10:40.11
Javaのフレームワーク関連で
こんなにもたくさんの名前が出て来ること自体が異常
他の言語はここまで乱立してないから入りやすい
508:デフォルトの名無しさん
13/04/05 00:24:26.24
>>507
javaはまだマシだと思う
ほとんどspring一択だし、そこにplayあたりが割り込もうとしてるくらい
ぶっちゃけjeeだけってのもありだし
この点ではjavascriptのライブラリの乱立が一番ひどい
509:デフォルトの名無しさん
13/04/05 00:51:39.39
springjs
hibernatejs
なんかつよそう
jsf も js が付いていることに気がついた。でもうんこ
510:デフォルトの名無しさん
13/04/05 01:11:50.38
選択肢が無い方が幸せって人もいるけど俺はいやだな
511:デフォルトの名無しさん
13/04/05 06:32:32.04
趣味の自分プロダクトならそれでいいけど
フレームワークがコロコロ変わると
チームメンバーが大変だろう
512:デフォルトの名無しさん
13/04/05 06:47:37.60
そこまでころころは変わらない。
513:デフォルトの名無しさん
13/04/05 07:02:04.46
オレオレフレームワークで検索するとPHP率が結構高いのね。
514:デフォルトの名無しさん
13/04/05 08:05:54.47
Javascriptは「Javascriptへコンパイルする言語」の乱立が酷いけどな
515:デフォルトの名無しさん
13/04/05 09:36:15.65
>>508
DIコンテナとして下のレイヤーでSpringを使ってるのは多いみたいだね
GrailsもSpringをベースにして、HibernateやGroovyや
独自テンプレートエンジンなどを組み合わせたものだった。
VMwareがGrailsのバックについてるからSpringベースなのは当然かもしれないが。
>>510
選択肢は多いほうがいいね
ドキュメントが整備されているという条件つきだけど。
JSはドキュメントも十分にないようなライブラリが1万以上あってカオスだわ
516:デフォルトの名無しさん
13/04/05 11:15:07.30
2年前は、こんなにJSのフレームワークがいっぱい出てくるとは思わなかったわ
たんにデコレーションする JQueryとprototype js と ext js しか知らなくて、
Backbone JS みたいにクライアントサイドでロジックまで制御するようなフレームワークが
出てくるなんて思わなかった(自分のスキルが低いのだろうが)
517:デフォルトの名無しさん
13/04/05 11:17:44.83
俺はフレームワーク嫌いだからjQueryすら使わない
518:デフォルトの名無しさん
13/04/05 11:33:11.41
JSはただのライブラリであってフレームワークではないだろ
519:デフォルトの名無しさん
13/04/05 11:41:08.76
ネイティブが好き
520:デフォルトの名無しさん
13/04/05 13:47:27.52
Javaのフレームワークの乱立について指摘されてるのに
JSのほうがもっと酷いからJavaの乱立はOK、というのはいかがなものか
521:デフォルトの名無しさん
13/04/05 13:53:42.65
>>518
MVCフレームワークが乱立してるよ
URLﾘﾝｸ(todomvc.com)
522:デフォルトの名無しさん
13/04/05 14:46:14.82
Node.jsはCPUを使う処理には弱いと書いてあるね。
シングルスレッドでしか使えない弱点が痛い。
グリーの宣伝（人材募集）みたいになっててアレな記事だけど。
URLﾘﾝｸ(codezine.jp)
メリットはリアルタイム処理が強いことくらいかな
でもソーシャルゲームとかチャットのようなリアルタイム性が
必要ないなら、Node.jsを使う意味は見当たらない。
JSは細かいライブラリが大量にあって情報追いかけるのがひたすらめんどくさいわ
現状は汎用的に使えるサーバサイドフレームワークって感じじゃなくて
リアルタイム処理が必要な場面で使うものに見える。
523:デフォルトの名無しさん
13/04/05 14:49:07.16
従来サーバ側のWebフレームワークが担ってきた役割、特にビューは
クライアント側（JSに限らずObjCやJava含む）への移動が始まってる
だからサーバ側もJAX-RS的なものでAPIだけ作る流れ
これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる）
524:デフォルトの名無しさん
13/04/05 14:52:50.13
>>522
今はJavaでもNettyがあるし、その上に作られたNode.js風のVert.xもある
Netty上に作られたErlang風のAkkaもあり、Akka上に作られたPlay!もある
技術的にはNode.jsを選ぶ理由はない
525:デフォルトの名無しさん
13/04/05 14:56:37.52
JAX-RSは地味によいものだと思う。
526:デフォルトの名無しさん
13/04/05 14:59:55.89
シングルスレッドとかありえねー
527:デフォルトの名無しさん
13/04/05 15:18:49.66
逆だろ、単体ではシングルスレッドにしておき、
CPUコア数に応じてスケールさせたければ、プロセスを複数立ち上げておいて、
フロントのロードバランサーなりリバースプロクシで分散させればよい。
Nodeにしろ、こういったのは、パフォーマンスを上げるために、マルチスレッドではなく
RubyのEventMachineみたいにイベント駆動にすることでパフォーマンスを上げようとするアプローチなんじゃないの？
って書いてて自分でも理解してないのだが、
マルチスレッドにしつつ、各スレッドは EventMachine 形式にしたら、もっといいんじゃないの？
と思うんだけど、併用できないんですか？
528:デフォルトの名無しさん
13/04/05 15:35:47.71
逆とか意味不明。シングルスレッドとか糞
529:デフォルトの名無しさん
13/04/05 15:44:10.18
シングルスレッドにはシングルスレッドの良さがある
同時1万接続をすいすい捌いてもメモリ256MBでおつりが来る
これはマルチスレッドじゃ無理
クラウド（PaaS）ではこれがコスト面で効いてくる場合がある
要は適材適所の一つ
530:デフォルトの名無しさん
13/04/05 15:45:51.78
>>523
Viewがクライアント側に移動が始まっている、の意味がさっぱりわからんですわ。
例えばCRUDのうち、データ取得する(SELECT的)処理をするとして
AP serverは、DBから得た結果を、htmlとマージして最終的にブラウザに
渡す必要があるのは何ら変わってないでしょう？
要するにTemplateにデータを合成して、レスポンスを返す処理。
実際に、今の主流のMVCのフレームワークでも
そういったViewのテンプレート処理を持ってるし、使ってるでしょう。
Node.jsをプッシュしてたひとと同じだと思うけど、「使われている事例がある」
というだけなのに、すべてそうなっていくかのように主張しているように見える。
531:デフォルトの名無しさん
13/04/05 15:50:45.64
>>529
ないない。
DB絡んだら1万同時接続なんて1台じゃ無理だし
シングルスレッドならなおさら無理。
さらに256MBで足りるなんて妄想もいいところ
1万接続で256MBとか馬鹿な主張はいいかげんにしろといいたい
532:デフォルトの名無しさん
13/04/05 15:58:18.20
シングルスレッドはマルチスレッドになれないけど
マルチスレッドはシングルスレッドになれるんだから
シングルスレッドのほうがいいなんてありえない。
533:デフォルトの名無しさん
13/04/05 16:02:24.39
>>530
HTMLを返す必要がなくなってきてるってこと
JSONだけ返しておけばあとはクライアント側でレンダリングする
だからクライアント側のMVCフレームワークが注目なわけ
君だいぶ遅れてるみたいだから少しはキャッチアップしておいて損はないと思うよ
534:デフォルトの名無しさん
13/04/05 16:15:06.17
>>531
Node.jsじゃDB接続もノンブロッキングだし1スレッドで十分
DBとのやり取りってアプリ側はSQL投げて返ってくるまで待つだけじゃん？
だから影響はないよ
もちろんDB側がボトルネックじゃない前提で
>>532
用語の使い方の問題だな
シングルスレッド: イベントループで複数の接続を扱うアーキテクチャ
マルチスレッド: 接続毎にワーカースレッドを使うアーキテクチャ
まともな議論にならないなら用語変えた方がいいかもね
実際はNode.jsだってマルチスレッドだよ
イベントループ以外のスレッドは持ってる
別にNode.jsプッシュしてるつもりはないんで
必要に応じて使ってるだけ
535:デフォルトの名無しさん
13/04/05 16:19:45.99
>>533
遅れてるとか馬鹿にしてるだけで答えになってないよ。
最終的にブラウザで表示されるhtmlはどうするんだよ
HTMLを返す必要はなくなってきてなんてないから
536:デフォルトの名無しさん
13/04/05 16:21:03.02
bodyタグの中身は空でjsで全部書くってことでしょう。
537:デフォルトの名無しさん
13/04/05 16:24:45.46
>>536
それ非効率極まりないね
あとJS無効にされてたらなにもレンダリングされないじゃないの。
プライベートブラウジング機能が搭載されてきてるから
JS無効になってるなんてケースは増えてる。
538:デフォルトの名無しさん
13/04/05 16:27:03.82
フレームワークを使う人は開発効率のみ優先だから。
539:デフォルトの名無しさん
13/04/05 16:30:26.06
>>523 >>533
それはないと断言できる
プログラムの前にキミはWebがわかってない
540:デフォルトの名無しさん
13/04/05 16:31:51.49
>>530
ViewはもともとウェブアプリケーションフレームワークによるHTML生成とウェブブラウザにる
レンダリングの共同作業だったわけだけど、書かれるロジックがどんどんブラウザ側のJavaScript
に引っ越ししつつあるというのは自分も解る。
ただ個人的にはウェブアプリケーションフレームワークでViewと呼ばれている部分よりもController
と呼ばれている部分に書かれていたロジックがお引っ越ししている印象。
ウェブアプリのMVCは本来のMVCとは違うとかMVC2とか細かいツッコミは別として、大まかに
ウェブアプリのCはURLマッピングで振り分けられたHTTPリクエストに応じてアクションを起こす
役割と、Vで表示されるデータをお膳立てするビューロジックの一部を担ってきたように思う。
これが前者に関しては最近はブラウザ上でSubmitボタンを押しても直接POSTリクエストが飛ぶの
ではなく、ブラウザ上でJavaScriptがRESTリソース、言うなればMにアクセスするリクエストを
組み立ててAjaxでやりとりしてHTMLを書き換える。この場合ウェブアプリ側のCというのはURL
にRESTリソースをバインドする程度のすごく薄いものになる。
後者に関しても例えばMの中に1万件あるデータをある属性で並べ替えて20番目から29番目を表示、
といったページングのためのビューロジックは大抵Cの中に書かれていた。ただこのロジックも最近
ではJavaScriptで書いて、AJAXをつかって動的にサーバから表示に必要なデータを取得する場合
も多いと思う。これもサーバ上のCからブラウザ上のJavaScriptにお引っ越ししている例。
541:デフォルトの名無しさん
13/04/05 16:38:33.99
>>539
同意。
他人を遅れてると馬鹿にして上から目線で発言してるわりに
アーキテクチャと利点、欠点などがわかってないわ
542:デフォルトの名無しさん
13/04/05 16:39:43.33
フレームワーク厨はフレームワークさえ使えればなんでもいいんだよ。
君らもフレームワークをありがたがってないでネイティブに回帰すべき。
543:デフォルトの名無しさん
13/04/05 16:43:38.62
>>535
最初は静的なHTMLで始まる（Javaで返す必要はない）
そこからロードされたJSがサーバからJSONを取得する
JSONで得た情報をJSでレンダリングする
そのためのJSで書かれたテンプレートエンジンもたくさんある
うちはHandlebars使ってる
まだそこまで極端なケースは少ないけど方向はこっち
（Twitterみたいに後戻りするケースもあるし流動的かもしれんが）
スマホのネイティブアプリとサーバ側が共有しやすいメリットも大きい
つかうちはスマホアプリが先で後からブラウザ対応が増えてきてる
ちなみに業務系はオンプレのJavaでStrutsベースのオレオレ、
それとは別にAWSでPHP、RoR、Node.jsを使ったサービスを並行してやってる
わかってないといわれるならそうなんだろう
544:デフォルトの名無しさん
13/04/05 16:49:34.93
そうやって間違った方向に進んでしまうのがIT業界の悪いところだな。
545:デフォルトの名無しさん
13/04/05 17:16:33.84
>>540 >>543
Google mapとかの地図サイトのように
ページの一部分を頻繁に読み込むようなサイトなら
JSは使うだろうし、それくらいは当然知ってます。
ページ全部を毎回読み込むのは非効率だし
ただ、MVCのある機能がブラウザ側に移動したというより、サーバとクライアントが
協調して動作するようなシステムが出てきたってだけの話だと思う。
結局、サーバサイドのフレームワークがなくなることはありえない。
>>523は、「分散」とかではなく「移動」といったうえで
「これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる）」
なんて結論づけたから噛みついたわけ。
Strutsがクソなのは知ってるけど、そこからサーバサイドのMVCフレームワークが
なくなっていくという話につなげられると
まったく同意しかねる、ということ。
Ajax, jQuery必須にしてしまえば、ブラウザでJS切ったら使い物にならないし
有効であってもバージョンの互換性でエラーが出る。
開発のコストも無駄にかかる。デメリットも大きい。
だから全般的に移行することはありえない。
デメリットを補ってあまりあるメリットがあれば使われる、というだけ
サーバだけでやるのか、サーバ＋クライアントでやるのか、
使い分けの問題であって、サーバのみでやるのが遅れているわけでもない。
セキュリティ上の理由でクライアントサイドで処理できないこともある。
546:デフォルトの名無しさん
13/04/05 17:20:06.75
まったくだ。ニコ動もクライアントでいろいろやりすぎて
糞使いにくくなってる。
つまり何事もネイティブで考えることが必要だ。
547:デフォルトの名無しさん
13/04/05 18:58:11.74
中の人にはソレが段々と見えんくなってくるのでしょう。
548:デフォルトの名無しさん
13/04/05 19:24:11.12
JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。
ちなみにうちは、jQueryの利用的なことから一歩進んで、JSフレームワークのLOBアプリへの適用もやりはじめた。
今までJSで個別に処理を記述していたところを、フレームワークを使って、
RESTなAPIの結果でObserverなVMのメンバを更新、バィンディングでHTMLの表示を更新というレベルだけど。
549:デフォルトの名無しさん
13/04/05 20:45:01.83
>>548
> JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。
どの辺がまだまだ?
550:デフォルトの名無しさん
13/04/05 21:28:07.76
>>545
もちろん、なかなか消えはしないだろうけど、
徐々にviewの部分が移行していく流れだと思う
下手すると、cの部分も
本当に最後まで残るのは、モデル層だけだろう
551:デフォルトの名無しさん
13/04/05 21:41:16.25
今後流れがjavascriptに来るだろうというのは
確実に分かる
現在のライブラリの乱立がその徴候
今はその動きの中にいる人だけが気がついてる状態だが
これがやがて、本流になる
552:デフォルトの名無しさん
13/04/06 00:15:09.70
サーバーサイドがhtmlではなくxmlでデータを返すに留まり
Ajaxで何でもやるなら既存のMVCフレームワークの延長でもできそうだな。
(ViewがXMLになり、XML/HTMLは互換性がある)
GWTとかPlayみたいなオレオレ色の強い独善的FWよりそっちがいいかもしれん。
だがサーバーにフレームワークが必要ないって意味不明。
クライアント側でjavascriptがJSONからHTML組み立てる言われても
誰がクライアントに渡すJSON/XMLを作るんだ？
まさかクライアント側のjavascriptがSQL発行してjson作るのだろうか？
553:デフォルトの名無しさん
13/04/06 00:35:34.78
今後はクセモノであるHTTPセッションを
クライアント側メモリに持ち込むのも増えていくだろうけど、
クライアントがスマフォとかだと大きいキャッシュデータとか無理だし
サーバー側でセッション作る必要がある。
554:デフォルトの名無しさん
13/04/06 01:04:28.16
インタラクティブな処理が必要な場合に、
クライアントサイドでのタスクを増やすってのがJSの使いどころ
このスレのJSやnode.js推してる人は、すべてクライアントサイドで
やる方向にいくと思ってるところが大間違い。
デメリットがわかってない。
必要のない場所でまでJSでやったら開発コストも増すし
ブラウザの互換性というやっかいな問題が現れる。
555:デフォルトの名無しさん
13/04/06 01:06:01.26
ダイナミックHTML時代のままで大いに結構
Ajaxまでは求めちゃいないよ
556:keisuken
13/04/06 01:24:33.06
ちょっと勘違いもあるかなと思うけど、今後は両方で進んでいくことはほぼ間違いないと思うけどな。
* ブラウザがFORMでPOSTしサーバがHTMLを返す
* ブラウザがAjaxでPOSTしサーバがJSON/HTMLを返す(JSONの場合はJavaScripotがDOMなどに適用する)
RESTful坊は後者に偏りがちで
* ブラウザの処理が重たくなる
* JavaScriptに対応していない端末で動かない
という欠点もあるんだけど
* サーバ側がかなりシンプルになる(Web APIの提供)
* 場合によってはレスポンスデータが小さくなる
などの利点もあって別に間違った方法でもないし、実際そういうサイトはいくらでもある。
JavaScriptでの開発が煩雑になり、開発しにくくなるというのも間違っていないのだが、
Wicketみたいにある程度フレームワークが解決してくれることもあるし、
今時のJavaScriptライブラリ/フレームワークは昔より良くできていることが
多いので案外どうにでもなっちゃう印象ですね。
特にスマートフォン対応だとむしろJavaScriptを使わないことが(主にレスポンシブや
アニメーション, レイテンシなどで)しょぼく感じてしまうケースもあるので
もう無視できなくなってると思う。
557:デフォルトの名無しさん
13/04/06 01:30:00.65
HTMLを返す処理はなくならないが
フレームワークの要不要はまた別問題だな
俺はいらんと思うけど
558:デフォルトの名無しさん
13/04/06 01:33:29.51
ブラウザで多くをやる方法は限界やデメリットがある以上、
サーバ側のフレームワークにとって代わることはない。
JavaのWebフレームワークのスレなのにスレ違いのレスばっかりになってる。
559:デフォルトの名無しさん
13/04/06 01:34:45.31
>>553
>今後はクセモノであるHTTPセッションを
>クライアント側メモリに持ち込むのも増えていくだろうけど、
セキュリティホール確定。
クライアント側は当然偽装し放題ですよ。
ちなみに自分は常にJavaScriptはOFF（もちろんJavaAppletだのFlashだのも）
なので、見えないページはムカつきつつ閉じてます。
わざわざ開く価値なんてないし。
560:デフォルトの名無しさん
13/04/06 01:36:37.41
>>558
JAX-RSだってJavaのWebフレームワークだからこの流れはスレ違いじゃない
自分の意見と違うからって排他的にならないでほしいね
561:デフォルトの名無しさん
13/04/06 02:12:52.30
>>559
いまどきJavaScriptをOFFとかありえないだろ。
商品リストのページングとかSession+Ajaxでやっていたようなものにも
クライアント側が操作しても問題ないようなデータは結構あるぞ。
562:デフォルトの名無しさん
13/04/06 02:19:09.71
>>559個人がどうするかは>>559の自由だから放っておいてやれw
ようはJS無効にしてるユーザを救うことによって得られる
利益とかかるコストをそれぞれのサイトがどう評価するかだ
563:デフォルトの名無しさん
13/04/06 02:24:58.73
クライアントJavaScriptでバリデーションをするとか嫌だな。
たとえば登録フォームだとパスワード半角英数8桁とか以外にも
同じ名前が既に登録されているのかとかチェックするときがありうる。
そうなるとデータベースとバリデーションが関連するわけで、
Ajaxを通すのは良いとしてもバリデーション自体は鯖側で行うべきだ。
564:デフォルトの名無しさん
13/04/06 02:51:01.86
クライアントから投げられる値なんて基本的に信頼できないからサーバ側でのバリデーションは
いつまでたっても必須だよ。ただsubmitする前にキー入力に応じてダイナミックにバリデーション
したい場合などはJavaScriptを使ってブラウザ上で「仮」バリデーションする場合もあるというだけ。
ただこれするには同じバリデーションロジックをJavaとJavaScriptでそれぞれ書くことになるので
二度手間になる。この点でGWTは地味に便利だった。Javaで書いたロジックをJavaScriptに変換して
ブラウザ上で使うから二度手間にならないし、Java上でロジックを書き換えるとそのままクライアント
側のロジックにも反映されるからロジックの同期も楽。
というわけでJavaからJavaScriptへのコード変換はそろそろjavaxとして仕様化すべきだと思う。
あるいはJava -> JavaScriptの変換を行う定番トランスレーターがデファクトで決まるのでも良い。
565:デフォルトの名無しさん
13/04/06 04:45:17.33
>>564
で、だったらはじめからサーバーもjavascriptで書けばいいじゃん
という流れになったりしてな
node人気が出てきたみたいだし
566:デフォルトの名無しさん
13/04/06 06:06:19.09
>>563-564
そうそう。
セキュリティ上の理由で、サーバ側でやらないといけないもの
があると書いたのはそういうValidationとか。
クライアントサイドのValidationは仮のチェックだね
レスポンスを高めるだけのものでしかない。
クライアントに渡した時点で汚染された（信頼できない）データに
なってしまうし、再度DBに入ってくるようなデータは渡したくない。
全部クライアントサイドでやる流れ、とか言ってる人は
セキュリティの観点が頭にない。
567:デフォルトの名無しさん
13/04/06 06:17:19.79
>>566
バッカだねぇ、「全部」クライアントでやる流れなんて誰が書いた？
サーバ側でバリデーションが必須なんて当たり前すぎて議論の余地無しだよ
JAX-RS使うとバリデーションできないとでも思ってる？
BeanValidatorはMVCフレームワークと密結合してるとでも思ってる？
レベル低すぎて相手にするのやめようと思ったけど想像以上の低さに驚いたよ
568:デフォルトの名無しさん
13/04/06 06:24:52.99
つーか「StrutsとJSPの時代が終わる」と書いた>>523でもJAX-RSのこと書いてるのに
なんで>>545みたく「サーバサイドのフレームワークがなくなることはありえない」
なんて的外れの反論しちゃうのかねぇ
あげくに「全部クライアントでやる流れ」とか誤読どころの話じゃないだろ
こんな文盲で仕事できるのかね？
569:デフォルトの名無しさん
13/04/06 06:26:42.29
>>567
自分の発言読み返してみろよ
そう読み取られてもおかしくない表現してる
>>523なんてアホ発言そのもの
他にもnode.jsの時代になってるだの妄想垂れ流しすぎ
570:デフォルトの名無しさん
13/04/06 06:27:53.82
>>568
おまえはJSスレに帰れよ
完全にスレ違い
571:デフォルトの名無しさん
13/04/06 06:29:14.15
一度スマホのネイティブアプリとだけつながるサービスの開発でもやってみると
（何が必要か考えるだけでも）知見も広がっていい経験になるんじゃないすかね？
572:デフォルトの名無しさん
13/04/06 06:32:39.84
>>569
具体的に指摘してみろよ
どこに「全部クライアントでやる流れ」と読み取られておかしくない発言がある？
Node.jsの時代になってるってのもどこにある？
573:デフォルトの名無しさん
13/04/06 06:43:39.54
>>572
誤解されてもおかしくない表現力だよ
他の人もそうとらえてる人がいる。
>>543もあんただろうけど滅茶苦茶
＞最初は静的なHTMLで始まる（Javaで返す必要はない）
それができない場面もあることはすでに書かれていたよな？
＞まだそこまで極端なケースは少ないけど方向はこっち
ほら、ここで自分でいってるだろう。
使えない場面がたくさんあるのに「方向はこっち」とか言ってる。
あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。
自分ではないいうのなら自分のレス番号全部書くなりトリップつけないとわからない。
この板はIDでないから
574:デフォルトの名無しさん
13/04/06 06:55:48.45
>>573
> 他の人もそうとらえてる人がいる。
他の人じゃなくてさ、君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ
> それができない場面もあることはすでに書かれていたよな？
できない場面「も」あるから何？
> 使えない場面がたくさんあるのに「方向はこっち」とか言ってる。
「たくさん」っていうのは君の主観だね
> あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。
そもそもどのレスがNode.js推しなんだよ？
ちなみに>>524は俺だよ。Node.js推してるように読めるか？
575:デフォルトの名無しさん
13/04/06 07:03:44.94
>>574
>>524は別人だと思ったよ
俺とかいわれてもIDでないしわからない。
＞君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ
散々書いただろ。めんどくさいやつだな
あんたの発言がどのレスだか判別つかないことくらいわかってくれ。
俺のレスもすべてはわからないだろう。
576:デフォルトの名無しさん
13/04/06 07:25:47.54
>>575
「散々書いた」ってどこにあるんだよw
具体的に指摘する気はないみたいだからこれ以上は追求しないが、
勝手に拡大解釈して文句をつけるのはもうやめてくれ
577:デフォルトの名無しさん
13/04/06 07:33:12.04
>>576
散々書いたってわからないって？
俺もお前のレスがどれだかわかんないのよ
IDでないから
そういうしょうもない掲示板でまともな議論なんてできないの
578:デフォルトの名無しさん
13/04/06 07:37:32.20
>>577
あぁ、続ける気なんだ
別に「俺の」じゃなくていいからさ、君がどのレスのどの表現から
「全部クライアントでやる流れ」と読み取ったのか教えてよ
寝ぼけててもできる簡単なお仕事だろ？
579:デフォルトの名無しさん
13/04/06 07:42:19.34
>>572
「APIだけ作る流れ」
「HTMLを返す必要がなくなってきてる」
580:デフォルトの名無しさん
13/04/06 07:42:23.42
>>576
ちなみに俺は「君が」書いたレスかどうかは「気にしないで」読み返したけど
どこに「散々書いた」のか見つけられなかったよ
突然飛躍してるレスしか見あたらない
581:デフォルトの名無しさん
13/04/06 07:47:57.92
>>578 >580
しつこいなぁ、あんたも
「続ける気なんだ」どころか真逆だわ
IDでないしょうもない掲示板でまともな議論なんてできないってかいたろうに
IDでないんだから違う相手に反論してるなんてことあるだろ？
だからこれだけレスもついたし、検証作業なんてやりたくないの。
全員が正直に自分のレスを書いてトリップ書いたりしないと今となってはわからない。
582:デフォルトの名無しさん
13/04/06 07:49:57.54
>>579
それかよ（失笑）
Twitterが「API」も提供してのはもちろん知ってるだろ？
Twitter4Jとかあることくらいは知ってるだろ？
そのAPIはHTML返さないのも知ってるだろ？
じゃあTwitterのAPI叩くとTwitterのサーバじゃバリデーションも行わず、
「全部クライアントでやる」と思ってる？
違うだろ？冷静に考えてみてくれ
583:デフォルトの名無しさん
13/04/06 07:52:13.77
>>581
別に違う相手でも構わないよ
>>579にしたってさっきまでの誰かと同じかどうかはどうでもいい
それで議論できないなら半年ROMってろ
584:デフォルトの名無しさん
13/04/06 07:54:41.95
>>580
581 だけど>>579の人とは別人だぞｗ
ほら、他の人も、サーバサイドが不要になりつつあると解釈してるだろ？
だれかJS押しの必死な人がいるように見えるわけ。
でも、IDでないから同一人物かすらもうわからないわけ。
くだらないだろ？
無意味なレスばっかりになってる上にスレ違いだから、
クライアントJSの話題はJSのスレでやってくれ
585:デフォルトの名無しさん
13/04/06 07:56:09.01
>>582
スレ違い。荒らしになってる。
冷静にスレタイを読めとしか言えない
586:デフォルトの名無しさん
13/04/06 07:59:59.38
>>582
喧嘩してるとこ横レスして混乱させてすまんかった
JSONを返す流れについていってないやつは遅れてるとか
HTMLを返す仕事してるやつを小馬鹿にする発言もあったしなあ
じゃあバリデーションやデータの受け渡し以外は
全部クライアント側でやる流れってことでいいの？
587:デフォルトの名無しさん
13/04/06 08:01:53.46
>>585
JAX-RSはWebフレームワークだからスレ違いじゃないだろ
それともここはHTMLを返すフレームワーク限定なのか？
スレタイにも>>1にもそんなこと書いてないのに？自治厨？
588:デフォルトの名無しさん
13/04/06 08:10:29.51
>>587
スレ違いといってるのはクライアントサイドのJS
フレームワークという言葉を拡大解釈して、
スレ違いではないと強弁するのはやめたほうがいい
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4389日前に更新/201 KB
担当:undef