【Java】 Java Web Application Framework 総合

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 12/05 14:16 / Filesize : 201 KB / Number-of Response : 676
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

1 名前：デフォルトの名無しさん [2012/06/03(日) 16:18:39.74 ]: Java用のWeb Application Frameworkについて語るスレッド

海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない
開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを
比較しながら、最高のフレームワークを探してみるスレッド

Web Application Framework　のリスト
en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

特徴の比較
en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features
369 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:26:38.33 ]: >>368
それはさすがに極論すぎて、ORマッパ以前にバグやセキュリティホールの温床になりそうです。

現状Webアプリなどの場合はORマッパがボトルネックになるより、
RDBMSの処理の方がボトルネックになることが多くて、
ORマッパの意義はむしろ昔より重みが増しているように感じられます。
＃つまりCommons DbUtils使ってやれはちょっと...ということです。
＃そして最近のORマッパは結構薄いラッパであることが多く、
＃そんなに重たくありません。

ただ素のSQLやPLSQL/pgSQLなどの手続き言語を併用するのを
否定することではなく、バッチ処理のようなデータベースで処理だと
ORマッパ以前にフロントエンドの処理がボトルネックになることが
あると思います。その場合はそれを選択すればいいだけです。
370 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:37:43.30 ]: >>369
O/Rマッパーを使わないとバグやセキュリティホールの温床になるってのは
技術職、開発会社としてどうなんだ？
俺は条件によってはO/Rマッパーが有効なプロジェクトもあると思ってるが
上記のことは本質とはだいぶ違うと思うのだが。
371 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:40:36.78 ]: SQL生成用クラスを一個つくればいいよね
372 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:45:11.79 ]: >>370
本質じゃないというか言いたいのは「直接JDBC触らせるな」(DbUtils含む)ということですよ。
ORマッパはDAOみたいな機構も持っていることがあるので、
それなら最初からORマッパを使えば?ということです。
そういう汎用性をちゃんと持っているという認識が必要です。

>>371
そうですね。
でもそのサポートもDAOやORマッパがやってくれますけどね。
373 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 19:48:36.82 ]: あと聞きたいのですが、JDBCなどを使っている場合、
java.sql.PreparedStatementをちゃんと使ってますか?
374 名前：デフォルトの名無しさん mailto:sage [2013/03/25(月) 20:04:13.30 ]: SQL生成用クラスでPreparedStatementを使ってバインドしてるよ。
375 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 01:20:56.00 ]: Javaソースの中で文字列連結しながらSQL作るようなのはダメ絶対
376 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 01:40:04.61 ]: 別にダメじゃないだろ
O/RマッパーやPreparedStatementがないと
基本的なセキュリティ対策すらできないことのほうが問題
Javaじゃないと作れない人になってしまうよ
377 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 02:09:42.74 ]: JavaスレだからJavaソースと書いたがどの言語でも同じ
ただしSQLを組み立てるライブラリは除く、を書き忘れた
アプリで文字列連結しながらSQL作るようなのはダメ絶対
378 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 05:36:16.05 ]: >>376
PreparedStatementを積極的に使わない理由が思いつかない。
動的SQLなんて大抵の言語とRDBMSで使えるでしょ。
Javaじゃないと作れない人になってしまう理由がない。
379 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 07:38:05.65 ]: >>376
他の言語もJDBCに相当する機能では、今はPreparedStatement的な手法が主流だし問題ないと思う
380 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 11:20:44.10 ]: 昔は、文字列と、変数の配列(リスト)の2つを受け取って、
SQLをStringBuffer(StringBuilder)で連結しつつ、 ? を埋め込んで、
PreparedStatement 発行したもんだ。
381 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 12:31:12.72 ]: オープンソースJava O/Rマッピングソフト一覧（2013年1月版） | Unofficial DB2 BLOG
ttp://db2.jugem.cc/?eid=2540
382 名前：デフォルトの名無しさん mailto:sage [2013/03/26(火) 22:37:34.34 ]: PreparedStatementってDBサーバ側の機能だからな
>>376の発想がおかしい
383 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 05:23:30.46 ]: >>382
「Javaじゃないと作れない人になってしまうよ」と言っている当人がJavaでしか作ったことがないパターンでは。
384 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:43:10.56 ]: DBとのやり取りにDAOパターンを採用するとき何をどこに入れるかってどうすることが多い？

(1) Aテーブルに対する主キーでの1件取得、全件取得、挿入、更新、削除などの基本的な操作
(2) Aテーブルに対する業務に特化した操作(他業務で使うことはない)
(3) 複数テーブルを結合する複数業務で利用する操作

うちの周りだと下記のようにすることが多いんだけど、保守フェイズに入ると(3)が問題になりがちなんだよね
(1)は全テーブル分用意して共通パッケージに突っ込んでる
(2)は業務ごとにパッケージとDaoクラスを作成してそこに突っ込む
(3)は代表的なテーブルのDao(上記1に該当するもの)に突っ込んで他の業務でも使う
385 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:52:59.87 ]: 開発の規模によるがうちなら⑴と⑶だけかな
⑵は他の業務から使えないのが微妙
386 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 08:54:46.69 ]: 問題の内容忘れてたわ…

問題1. どの業務が使っているかわかりにくいから触るのが怖い
問題2. 最初は(2)のパターンだったけど改修の結果(3)のパターンになった時に共通パッケージに移動しづらい
(移動すると共通Daoを触る全業務の再テストが必要になる)

個人的には問題1はお前保守なんだから調査しろよ、
問題2はそこの客の方針がそうなら移動諦めて各業務Daoで重複させるか再テスト頑張れよ
って思ってて、実際そう伝えたんだけど納得されなくてなあ…

銀の弾丸はなかなかないんだよ
387 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 09:12:01.84 ]: 結局生SQLが一番いいという結果になるな
388 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 11:55:44.21 ]: >>382
その上「基本的なパフォチューすらできない」っていうねw
SQLがどうやって実行されるか気にしたこともないんだろうな
389 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 11:58:16.26 ]: 結局SQLがどうやって実行されるか気にしなければならない
O/Rマッパは使わないほうがいい。
390 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 12:49:51.63 ]: >>388
なんでセキュリティ対策のこと書くとパフォーマンスチューニングについて
わかってないことになるの？議論がめちゃくちゃ
391 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 13:35:29.45 ]: 前から言ってるけどO/RマッパやDAO、DSLか生SQL、どれを選択するのかは使う用途によると思う。
その前提がなくただO/Rマッパは使わないほうがいいというのは、少なくとも今のトレンドに
あっていないことも自覚すべきじゃないかと思う。
#特に国内と国外との違いにいつも愕然とするんですよね。

SQLやその実行過程を理解しガリガリにチューニングしなければならないというのも間違っていないし、
そしてO/Rマッパを使って抽象化・簡略化するのも間違っていないと思う。
何が目的でどういう手段を使うべきかをもうちょっと考察して議論したほうがいいと思う。

PreparedStatementを例に出したのはちょっとしたトラップで、
* PreparedStatementの利点を理解しているか?
* そもそも(たいていの場合)PreparedStatementを直接書くのが間違っているのを認識しているか?
を知りたかったからです(すみません)。
392 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 14:38:38.18 ]: でもJavaの用途はWebがほとんどだからパフォーマンス重視なのは
仕方ない。だから生SQLが一番いい。
393 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 14:49:37.60 ]: >>392
興味本位で聞くのですけど、O/Rマップってどのくらい遅いのですか?
具体的にベンチマークしましたでしょうか?
＃「あおり」じゃないので興味あったらで。

十分選択肢に入るくらい軽くなってますよ。
＃さらにいうと生SQLも書けるのですが(例えばMyBatis)。
394 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:02:22.39 ]: O/Rマッピングはアンチパターン？ | スラッシュドット・ジャパンデベロッパー
ttp://developers.slashdot.jp/submission/42933/
395 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:14:44.15 ]: >>393
びっくりするほど遅い。んで生SQLに書き直さないといけなくなる。
せめて生SQLにしないといけない割合が全体の1割未満なら使ってもいいけど
実際のプロジェクトではマスタメンテのような機能以外は
生SQLになってしまうので使い物にならない。
396 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:29:57.81 ]: どういうケースでどんな理由で遅くなるのか具体例が欲しいな。
397 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 15:40:04.67 ]: >>395
(また言いますけど煽りじゃないです。O/Rマッパ開発者としては現状認識を知りたい。)
生SQLをO/Rマッパに使ってもですか?

私の思う生SQLやストアドプロシージャを使う場面は、
* 長大で複雑ななクエリ(検索)
* バッチ処理など、検索以外にも挿入や更新が多い処理
だと思うのですけど、そういうケースですか?
あとO/Rマッパ(名前およびバージョン)に何使ったのかも気になりますね。

一般的なケースだとあまりボトルネックにならないのですが...。特にWebアプリだと。

>>395
そうそう気になりますよね。参考になりますし。
398 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 16:47:15.90 ]: RailsみたいにORマッパに適したテーブル設計ができていれば、
結構不都合無いパフォーマンスになるんですけどね。
IOの激しいWeb系とかゲームだと設計的に厳しいし、
がちがちの業務系だとそういう設計のできないアホなSEばっかだし、
そもそも設計をフレームワークに合わせるのか、とか不毛な議論が始まるので。。。
小規模なアプリをサクッと作る場合には便利なんですけどねぇ。
399 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 17:42:51.07 ]: 社内システムならDBの負荷はたかがしれてるから
ORM使っても性能上の問題ないよ
開発スピードも上がる。

パフォーマンスが大きく変わるのはメモリ上にDBのデータが
のっているかどうかだろう

WebサービスであってもほとんどORM使って問題ないと思うし
本当に性能が必要な場面はストアドプロシージャ使えばSQLより速くなる。

必死にORM否定してる人は使い方が分からないか、
使いどころがわからないだけ
400 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 17:50:31.65 ]: ストアドプロシージャは使いたくないです。
401 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 18:09:34.30 ]: まぁ2:8の法則だわな。
8割の処理はORMで十分だし、利用頻度が高かったり負荷の高い2割の処理は生SQL。
ってのが常道だと思う。
俺がよく使ってるのはHibernateJPAだけど、速度的には不満は無いね。
むしろDBにきちんと索引張ったり外部キー設計する方が大事だと思う。
402 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 21:02:46.76 ]: ORMいらない、と言っている人間ははよくわからんな。
Micro-ORMで十分、なら理解できるが。
403 名前：デフォルトの名無しさん mailto:sage [2013/03/27(水) 21:14:49.27 ]: ORMと一括りにして議論している時点で程度が知れてる、というべきだな。
404 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 00:33:47.55 ]: 同じSQLでO/Rマッパーだけ遅いなら外すしかないね。
内部のリフレクションとかが遅いんじゃないの？
405 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 01:24:46.14 ]: 問題になる遅さなのそれ。
406 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 01:29:38.75 ]: 生SQLとかORMいらないとか連投してるのは荒らしだろ
現実的にはこのどっちか

・SQLを暗黙的に発行することがあるHibernate含むJPA系のORM
・プログラムで指定したとおりのSQLを発行するMyBatisやSeasar系などのORM
407 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:06:46.51 ]: 生SQLの定義がわからんね
SQL*Plusなんかで直接実行できるSeasarの2way SQLは生SQLなのかどうか
408 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:32:20.33 ]: フレームワークが勝手に作ったSQLを発行するんじゃなくて、
開発者が書いたSQLを流すのが生SQLでいいと思う

MyBatisとかDOMAとかの生SQLベースのマッピングはめんどくさいところもあるけど入門編にはいいと思うわ
409 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:41:14.77 ]: だとするとJPA系を除く多くのORMは生SQLが主なんだが
生SQL君が言いたいのはORMイラネじゃなくJPAイラネなのか？
ORMイラネ君と同一人物かと思ってたんだが
410 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 14:49:50.56 ]: >>407 >>409
ORMはSQLを生成して、SQLを投げるだけだよ
複雑なJOINしない限り、ほとんど性能は落ちない。

生SQLってのは自分でSQL文を書くってことだろう
JPAもORMの一種

ORM要らないって連呼してるひとは、
上のほうでフレームワークも要らないと必死に主張していたひとと同一人物だと思う。
411 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 15:07:49.10 ]: >>410
自分で書いたSQLをORMで実行した場合も生SQLだとしたら、
生SQLが必要だからORMイラネってのはおかしいという話
生SQLが主のORMもたくさんあるわけだから
生SQL君とORMイラネ君が同一人物かどうかはしらんけど
412 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 18:43:58.87 ]: 俺は生SQL書きやすいORMならOK派かな。
Hibernateみたいなのは勘弁。
フレームワークも不要。
413 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 20:20:44.35 ]: MyBatis+標準SQL(SQL92あたり)でいいわ
414 名前：デフォルトの名無しさん mailto:sage [2013/03/28(木) 22:50:54.10 ]: まぁ日本の開発現場ではNIH症候群が蔓延してるからな。
車輪の再発明大好きだし。
415 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 00:30:58.37 ]: おれもMyBATIS＋SQLだな
学習コスト少なめだし、バグがあっても追いやすいし
裏で動的にSQL生成してるようなフレームワークで
いい思いをしたことがない
416 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 05:58:23.38 ]: ＳＱＬ方言だけ吸収してくれれば
417 名前：デフォルトの名無しさん mailto:sage [2013/03/29(金) 07:20:01.88 ]: Hibernateかなぁ。
幸い個々のエンティティに関して比較的単純なCRUDしか必要が無いのでMyBatisでSQL書いた
ところでHibernateが生成するSQLとあまり大差無いものを書くことになったり。

個人的にはエンティティ引っぱってくるときに射影相当の演算や、関連を引っぱってくるのを
LazyにするのかEagerにするのか、固定ではなく場面に応じて簡単に指定出来ると有り難い。
HibernateだとCriteriaに頼ることになるので面倒。
418 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 09:24:08.73 ]: >>415
どれでも発行SQLだけ確認やログ出しも出来るし
2WAYならチェックした上でマズいの手書きできる
フレームワークで統一性のない動的生成ルールが面倒だけどな

それよりもDTO周りの議論に戻ってくれ
俺も今DTO増殖中で疲れてる
419 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 10:34:49.59 ]: DTOはある程度割り切って共有で結論出てなかったっけ
割り切り共有＋継承＋テーブル定義とにらめっこ、
すればそこまで増殖しないと思うが。
420 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:05:35.15 ]: DTOのクラスが増えるのが嫌なら、全部Mapに突っ込んでしまえば？ｗ
421 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:07:19.28 ]: Mapでええやろ
422 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 13:37:01.55 ]: mapでいいならJavaじゃなくていいだろ
getterがあるからキーの文字列を意識しないで済んでるのに
423 名前：デフォルトの名無しさん mailto:sage [2013/03/30(土) 19:32:32.72 ]: MapとDTOは使い分ければ良いと思うけどなぁ。
424 名前：デフォルトの名無しさん [2013/03/31(日) 10:16:31.71 ]: Java系のフレームワーク、海外ではGrailsがすごい人気高くて驚いた
Java系だとGrailsはトップ3に入ってる

Java系でサクサク開発できるのはGrailsとPlayみたいだ
Javaの方言のGroovyだからといってGrailsを敬遠しないほうがよさそう
425 名前：デフォルトの名無しさん mailto:sage [2013/03/31(日) 11:10:40.80 ]: GroovyはJavaの資産は使えるなら積極的に使おうって姿勢かな
426 名前：デフォルトの名無しさん mailto:sage [2013/03/31(日) 22:08:24.97 ]: GroovyはJavaの方言というかJavaプラスアルファぐらいに考えた方が良いと思う。
Javaの文法にRuby風の文法やメソッドも付け加えた感じで、両方を混ぜて書ける。
JavaとRuby両方の素養がある人だとすごく便利だと思うよ。

Grailsだと根っこのドメインロジックはJava風にカッチリ書いたりそれこそJavaとして書いて、
逆にGSP(Grails版JSPみたいなもの)に埋め込むコードとか簡単なコントローラーはGroovyの
文法駆使して簡単に書く。
427 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 00:51:09.20 ]: Groovy、Rubyほどギークでもない人でもゆるく書けるし、scalaより難しくないので、もっと流行ってもいいと思うんだけどな。
といいつつ周りではやっとこさ少しずつ広がってきて、以下のようなことをやるような人が増えてきた。
→納品物(webアプリケーション本体)はJavaだが、UTコード、内部ツールはGroovy、など。
　ビルドはgradle、とか。

といいつつRubyに素養がある人はRubyでやっちゃうんだよな。
428 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 02:41:51.01 ]: JavaのView層はいつまでも安定しないね
似たようなコードの書き方、次から次に覚えないといけないのはきつい
他の言語はほとんど安定してるのになあ
429 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 03:21:29.18 ]: Grailsは確かにもっと流行っても良い気はする。
会社でやっているプロジェクトも最近ようやくGrails2.2.1にバージョンアップして依存性管理を
Mavenに移行出来たので他のプロジェクトとの連携がよりやりやすくなった。
430 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 07:00:39.53 ]: フレームワーク使わない人ってURLマッピングはどうやっているのだろう。

例えばクエリーを使ったレガシーなaaa/product_comment?id=12345&comment=6789みたいな
URLではなく、よりRESTfulなaaa/product/12345/comment/6789みたいなURLを使う場合。

フレームワーク無しの生Servertだと毎度自前でpathをパースしたりサブリソース毎に条件分岐したりと
手作りできるにせよ無駄に面倒だと思う。
431 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 11:03:54.12 ]: >>430
mod_rewrite
432 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 11:09:20.88 ]: 自前でパースしないと遅いしな
433 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 17:14:29.59 ]: 面倒を厭わない人たちなのはよく解った。
434 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 17:20:23.50 ]: >>433
面倒を避けようとしてさらに面倒なことになってる印象。
435 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:00:58.98 ]: でもSEO対策が入ってくるとできあいのフレームワークじゃ難しいんだよな
みんなどうしてるか、そっちのが気になるわ
436 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:09:02.05 ]: JSFだのASP.NETだのはイントラじゃなきゃ難しいな
437 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:22:26.68 ]: >>435
どうやってタグを吐くかだから
フレームワークは無関係
438 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:48:03.67 ]: JSP&Servletだけで十分フレームワーク
439 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 22:50:16.68 ]: URLについては、Struts時代はRouter自作。
Spring MVCでは無問題。
440 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 23:33:39.56 ]: >>441
すいません。jspは文字コードを使い分けたいので、そのやり方はダメなんです・・・。
あくまで違う文字コードでの受け渡しでやりたいんです。
443 名前：デフォルトの名無しさん mailto:sage [2013/04/01(月) 23:41:07.31 ]: Java内部の文字列処理はUTF-16だよ
サーブレットの文字コードって表現が既におかしいんじゃない？

JSPのcharsetもSJISにしたいなら
req.setCharacterEncoding("Windows-31J");
とサーブレット側で受ければいい
444 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 00:05:07.91 ]: >>443
サーブレットのソースコードのテキスト文字コードがUTF-8ってことです。

サーブレット側では冒頭で
request.setCharacterEncoding("Shift_JIS");
response.setCharacterEncoding("Shift_JIS");

と書いています
445 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 00:29:51.55 ]: >>443
ああ、サーブレット側でsetCharacterEncodingやsetConentTypeで
Shift_JISを指定するだけで行けました。
サーブレット内での余計な変換処理は要らなかったんですね。
どうもです。
446 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 02:15:06.83 ]: >>438
>JSP&Servletだけで十分フレームワーク

これはマジでそう思う。

ただ他方で機能不足なフレームワークはその上にオレオレフレームワークが育つ格好の培地でもある。
447 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 04:23:34.10 ]: JSPはServletのフレームワークだな。
JSP嫌いだから引っこ抜いちゃうｗ
448 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 04:40:47.74 ]: >JSP&Servletだけで十分フレームワーク

ただしServlet3以降に限る
449 名前：デフォルトの名無しさん mailto:sage [2013/04/02(火) 10:51:31.04 ]: Servlet2.5 と Servlet3 で大きな違いってあるの？
Servlet3はほとんど追いかけてないのですが、
HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい
ぐらいのことしか知らん。
450 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:10:55.48 ]: ないと思うなー。
＞HttpServletののサブクラス作るときにアノテーション付けておけば、web.xmlに書かなくていい
フレームワーク自体を作る側の人にとって嬉しいくらいじゃね？
451 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:15:23.37 ]: そもそもアノテーションとか要らない
452 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:21:53.88 ]: なにいってるんだか
xml地獄を解決するために生まれたのがアノテーションでしょ
453 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:24:32.09 ]: フレームワークさえなければXML地獄もなかったのに
454 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:29:46.34 ]: >>453
GrailsはXML地獄なかったよ

XML地獄のフレームワークはほんと時代遅れ
コードが見づらくなるし、コンパイラで検出できないエラーがでる。
なるべくコードで設定するってのが流行りだし、アノテーションは必須の機能
455 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:31:41.31 ]: じゃあなんでSQLをXMLに外出しするような糞ORマッパを
勧めたりするんだ？
456 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:38:17.94 ]: >>455
アンカーくらいつけてまともな日本語で書けよ
何が言いたいんだ
457 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:43:30.16 ]: フレームワークとかORマッパが嫌い
458 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:47:54.30 ]: >>457
だったらこのスレを見るなよ
459 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 08:53:54.35 ]: いやさすがにわかるだろw
XML地獄を敬遠するくせにSQLはXMLいいのかってことだろ？
Javaの中でしか使わない設定はアノテーションとかでJavaの中に取り込んでいいと思うんだけど、
SQLについてはDBに流して確認とかよくやるから中に入り込まない方がいいな
今の所はSeaser系の2-way SQLが一番その辺り楽にできる
パラメータをSQLコメントに追い出すことで文法エラーにしないのは秀逸だと思った
460 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 09:04:33.36 ]: 海外だとHibernateが第一選択肢でそれ以外は比較的測定限界以下なのに、日本だとMyBatisとか
ガラパゴスフレームワークの類が幅をきかせているのは何か特殊事情があるのかな。
461 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 09:20:17.93 ]: 外出しすれば綺麗だと思うのは間違い
C++になっても変数宣言を関数の先頭でやるくらい汚い
462 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 09:21:15.39 ]: 全部のORMがXML使うわけじゃないし
TypesafeなORMが良ければそういうORMと組み合わせて
使えばいいだけだろ
入れ替えて使えるようにDIとかがあるわけで

うんこフレームワークを体験したからといって
フレームワーク全体を否定するのはアホ

うんこORMを体験したからといって
ORM全体を否定するのは馬鹿
463 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 09:23:53.81 ]: いろいろなフレームワークがあること自体間違い
464 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 10:28:49.35 ]: SQL外出しなオレオレフレームワークは色んな現場で見てきたけど、大体良い思い出が無いなぁ…。
大体SQLだけメンテしようとして、SELECT項目やバインド変数の数間違えてトラブるのが定番だった気がする。
事前にコンパイラみたいなのでチェックできるならいいんだけどね。
465 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 11:36:08.03 ]: とりあえずSeasar信者の受け売りが嫌だ
466 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 11:47:15.81 ]: 色んなフレームワークがあるのは構わんけど、色んな実装があるのは嫌だ。
JAX-RSとかJSF、JPAとか。

つーか、WebやORMのフレームワークで、わざわざ仕様と実装をわける意味がわからん。
結局、実装固有の拡張機能を使わないと使い物にならなかったりするし。
467 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 12:02:47.87 ]: >>466
その無駄な複雑性はJavaの悪いところだし
ORACLEが無能だからだろうな
468 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 13:39:18.89 ]: 継承や委譲を使うべきところまでPOJOがどうのこうのとアノテーションだらけにする
無能な糞フレームワークがあるな。S2なんとかーだけど。
469 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 13:55:01.70 ]: 自分も Hibernate より MyBatis のほうが好きなタイプだが、
Hibernate は嫌われるのに、Rails の ActiveRecord がみんなに受け入れられているのはなぜだろう？

両方とも似たようなタイプなのに
470 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 14:58:00.57 ]: 規約やアノテーションを活用する今のHibernateではなく、XML地獄時代のHibernateのイメージ
があるからじゃないのかな。
471 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 16:26:08.57 ]: ActiveRecordが受け入れられている理由
-> RoRを使用するような用途/データモデルではそれで困らないから

Hibernateが受け入れられない理由
-> Javaがおそらく最も使用されているユースケース/データモデルではそのAPIモデルでは困るから

ソーシャルなWebアプリっぽいもの、DOA世界な帳票とかのLOBアプリでは、APIに求められるインターフェースも違うだろうし。
472 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 19:43:14.80 ]: そういやhibernate entity manager経由でしか触ってないな
今って生hibernateどうなってんだろ
後で試してみるか…
473 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 20:06:18.41 ]: >>471
でもそれだけだと内外差の説明はつかないなぁ。
474 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 20:33:32.91 ]: >>469
RailsのようにConvention over Configurationが徹底した
フレームワークだと、ほとんどORMの設定することなく使える。

Javaの場合、RailsほどCoC重視したフレームワークがまだ少ないから
Hibernateのめんどうなマッピング設定が必要になって、嫌われるのでは

>>470 のいうように、昔のXML地獄のHibernateしか知らない人もいる
のも原因かもしれない。
475 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:17:53.29 ]: >>473

ニホンジンはガイコクジンに比べて帳票ダイスキー、っという説はどうだろう？

- 帳票の出力内容はSQLレベルで複雑な処理を書くのが一番効率的
- その場合、求められるAPIは文字列としてのSQLをそのまま実行できるようなもの
- 日本において、Javaはもっぱらそういうアプリを作る用途で使われている(土方的な)
- そういう現場にHibernateを持って行っても(ﾟДﾟ)ﾊｧ?

国内では受け入れられていない理由が、昔のXML地獄のイメージがあるからとかっていうのは、
自分としては枝葉の話な気がするが。
476 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:21:36.90 ]: >>472
そういやHibernate4はEntityManager/Annotationsがネイティブになって
旧APIとXMLマッピングがその上のラッパーになるってどっかで見たけど
実現してないんだな。今もドキュメントはXMLマッピングから始まる
477 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:44:55.39 ]: >>473
日本のIT業界が世界に取り残される一番大きな理由は
大半が英語ができないからだよ
英語のドキュメントが満足に読めない人ばかり。

日本語の書籍がでて日本語情報が充実してこないと普及しない。
478 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:51:43.05 ]: iBatis/MyBatisなんて日本語の情報が充実してなくても結構使われてるだろ
Springだって使われてる度合いに比べたら日本語の情報は少ないし
Hibernateは使われてない割に情報多い
たいして相関してる気がせんな
479 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 21:55:28.57 ]: ぶっちゃけStringの連結なんてしたくないわ
テキストに書けるならそっちの方がチューニングもしやすいでな
480 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 22:02:27.77 ]: >>478
Batis系はHibernateよりも単純だから英語のドキュメント
読めなくてもなんとかなるからだろう

Hibernateのほうがはるかに高機能な分、覚える概念が多い。
Hibernateの本、日本語のもあるけど今のと違いすぎて役経たないと思う
英語弱者にとって厳しいのがHibernate

ORMにしてもEntityベースでやるのが主流になってるし
SQLに近いBatis系はもう海外では流行ってない。
疑うならwebフレームワークの採用ORM見てみなよ
481 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 22:04:26.47 ]: 内外差以前に海外の実情がわからんのだよな
いつまでもTomcat使ってるのは日本だけと某エバンジェリストが言ってたけど
www.javacodegeeks.com/2013/03/most-popular-application-servers.html
を見ると海外でもTomcat強いしJetty含めてJavaEEじゃない方が主流だよな
海外じゃJSFやJPAが普及してるってのもどこまで本当か…
マーケティングに釣られてるんじゃないかと思うことがある
482 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 22:07:31.15 ]: >>480
> 疑うならwebフレームワークの採用ORM見てみなよ

Playじゃebeanやnormも採用されてる件
483 名前：デフォルトの名無しさん mailto:sage [2013/04/03(水) 22:36:07.96 ]: 英語・日本語にかかわらず、ドキュメント読まなくても使えるシンプルなのがいいのは確かだな
484 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 00:51:54.82 ]: Struts1のEOLが決定しました
www.h3.dion.ne.jp/~alpha-pz/misc2811.html

潮流が変わるきっかけになるかね？
485 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 02:02:52.91 ]: RailsとHibernateが同じようなものというのはない
JavaのフレームワークはXML地獄かアノテーション地獄
Railsなんて学習コストやハマりコストめちゃ低いぞ
486 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 02:21:25.71 ]: こんな簡単なSQLで苦労するところ見ちゃうと学習コストが低いなんて信じられん
qa.atmarkit.co.jp/q/2826
487 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 04:49:50.13 ]: う～ん規約に従っている限りHibernateのアノテーションの量なんてたいしたほどではないと
おもうのだが。規約から外れるとマッピングの記述量が増えるのはRailsも一緒だし。
488 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:30:48.85 ]: >>485
名前だけでなくGrailsはRailsとかなり似てるから楽でいいよ
Javaを知っている人ならGrailsのが学習コストは低いとおもう。

>>484
日本の遅れたIT業界のことだから、ダメなのわかっててStruts2
に移行したりするんだろうなぁ
489 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:35:07.70 ]: >>484
フレームワークなんか使うからこうなる。
490 名前：デフォルトの名無しさん [2013/04/04(木) 07:44:26.43 ]: >>489
お前自身がEOLってことに気づこうな
491 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:49:20.30 ]: Grails、確かに使いやすいのだがRailsに似せるのに頑張りすぎていてかえってJava観点では
アレになっている部分も少なくないと思う。

例えばmappingsやtransientといったORMの定義、staticフィールドにRails風に記述できる
ようになっているけれども、型安全じゃないし正直JPA風のアノテーションの方がシンプルで
良かった。まあHibernateで定義したドメインクラスをインポートすれば良いのだけど。

あとビミョーに謎な振る舞いに悩むこともある。先日もドメインクラスにコンストラクタを定義
して使っただけでDIが動かなくなって暫し悩んだ。
492 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:49:35.61 ]: >>489
まだこのスレにいたのか
必死にフレームワーク否定してるけど何つかったことあるんだよ
493 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 07:56:46.99 ]: >>488
Javaのフレームワークにはいつも期待を裏切られてるけど
最後の最後ということでやってみるよ。アドバイスありがとう
494 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:05:53.42 ]: 作っては捨て作っては捨て
こんなのシステム開発では使えないよ。
趣味のプログラミングなら好きにやってくれていいけどさ。
495 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:52:46.84 ]: >>494
毎回作り直してる俺々フレームワークのことですね、わかります
496 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:58:09.84 ]: WicketライクなFW普及してくれ～
497 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 08:59:04.31 ]: >>495
受託や派遣ばかりやってるからそういう発想になるんですね。わかります。
498 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 09:18:37.61 ]: >>496
Wicket的な役回りはAngularJSとかブラウザ側でJSの時代だろ
499 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 20:48:10.99 ]: JSFってFacelets+CDIだけやれるっけ？
バッキングビーンの思想は素晴らしいけど管理ビーンとCDIが別れてるのが糞すぎる
501 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:33:20.22 ]: javascriptの時代が来る気がする
最近のjavascriptのライブラリは凄まじすぎるわ
jqueryuiとか、datatablesとか、jquery.sheetとか
マジでなんでもできるんだな
サーバーサイドもNode.jsになるんじゃないかな
ブラウザの開発ツールやらcloud9やらと、開発環境も整いつつあるし
Javaは下火になりそう
502 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:35:35.96 ]: フレームワーク乱立のせいだな
503 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:41:00.19 ]: >>501
その3つどれもただのjQueryのプレゼンテーション層よりの機能じゃないか
jQueryは他の言語のフレームワークでも連携させて使えるし、
サーバサイドが強いJavaとは強みのあるエリアがちがうよ

本格的なオブジェクト指向言語にすらなれてないJavascriptで
開発なんてしたくない
504 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:54:27.01 ]: >>501
phpと争って削ってくれたらそれで十分な感じかな
あいつらだけはマ名乗ったらいかんレベル
505 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 22:59:26.63 ]: apache cgi javaとかあればなー
506 名前：デフォルトの名無しさん mailto:sage [2013/04/04(木) 23:23:40.46 ]: >>503
それがさ、今single page applicationとかってのが流行ってるらしくて
サーバーサイドのコントローラの機能をクライアント側が吸収し始めてるんだよ
ライブラリさえあれば普通に本格的なオブジェクト指向言語だし
backbone.jsとかember.js見て驚愕した
requirejsやらcommonjsやらでモジュールもできるし、ビルドツールもある
qunitとかphantom.jsとかでテストも完備
サーバーサイドでormっぽいことも出来るみたいだし
nodejsdb.org/
ちょっと首を突っ込みはじめたんだが、マジで最強かも
ものすごいコミュニティができつつある
507 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:10:40.11 ]: Javaのフレームワーク関連で
こんなにもたくさんの名前が出て来ること自体が異常
他の言語はここまで乱立してないから入りやすい
508 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:24:26.24 ]: >>507
javaはまだマシだと思う
ほとんどspring一択だし、そこにplayあたりが割り込もうとしてるくらい
ぶっちゃけjeeだけってのもありだし
この点ではjavascriptのライブラリの乱立が一番ひどい
509 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 00:51:39.39 ]: springjs
hibernatejs
なんかつよそう
jsf も js が付いていることに気がついた。でもうんこ
510 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 01:11:50.38 ]: 選択肢が無い方が幸せって人もいるけど俺はいやだな
511 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 06:32:32.04 ]: 趣味の自分プロダクトならそれでいいけど
フレームワークがコロコロ変わると
チームメンバーが大変だろう
512 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 06:47:37.60 ]: そこまでころころは変わらない。
513 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 07:02:04.46 ]: オレオレフレームワークで検索するとPHP率が結構高いのね。
514 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 08:05:54.47 ]: Javascriptは「Javascriptへコンパイルする言語」の乱立が酷いけどな
515 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 09:36:15.65 ]: >>508
DIコンテナとして下のレイヤーでSpringを使ってるのは多いみたいだね
GrailsもSpringをベースにして、HibernateやGroovyや
独自テンプレートエンジンなどを組み合わせたものだった。
VMwareがGrailsのバックについてるからSpringベースなのは当然かもしれないが。

>>510
選択肢は多いほうがいいね
ドキュメントが整備されているという条件つきだけど。

JSはドキュメントも十分にないようなライブラリが1万以上あってカオスだわ
516 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:15:07.30 ]: 2年前は、こんなにJSのフレームワークがいっぱい出てくるとは思わなかったわ

たんにデコレーションする JQueryとprototype js と ext js しか知らなくて、
Backbone JS みたいにクライアントサイドでロジックまで制御するようなフレームワークが
出てくるなんて思わなかった(自分のスキルが低いのだろうが)
517 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:17:44.83 ]: 俺はフレームワーク嫌いだからjQueryすら使わない
518 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:33:11.41 ]: JSはただのライブラリであってフレームワークではないだろ
519 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 11:41:08.76 ]: ネイティブが好き
520 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 13:47:27.52 ]: Javaのフレームワークの乱立について指摘されてるのに
JSのほうがもっと酷いからJavaの乱立はOK、というのはいかがなものか
521 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 13:53:42.65 ]: >>518
MVCフレームワークが乱立してるよ
todomvc.com/
522 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:46:14.82 ]: Node.jsはCPUを使う処理には弱いと書いてあるね。
シングルスレッドでしか使えない弱点が痛い。

グリーの宣伝（人材募集）みたいになっててアレな記事だけど。
codezine.jp/article/detail/6461?p=2

メリットはリアルタイム処理が強いことくらいかな
でもソーシャルゲームとかチャットのようなリアルタイム性が
必要ないなら、Node.jsを使う意味は見当たらない。

JSは細かいライブラリが大量にあって情報追いかけるのがひたすらめんどくさいわ
現状は汎用的に使えるサーバサイドフレームワークって感じじゃなくて
リアルタイム処理が必要な場面で使うものに見える。
523 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:49:07.16 ]: 従来サーバ側のWebフレームワークが担ってきた役割、特にビューは
クライアント側（JSに限らずObjCやJava含む）への移動が始まってる
だからサーバ側もJAX-RS的なものでAPIだけ作る流れ
これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる）
524 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:52:50.13 ]: >>522
今はJavaでもNettyがあるし、その上に作られたNode.js風のVert.xもある
Netty上に作られたErlang風のAkkaもあり、Akka上に作られたPlay!もある
技術的にはNode.jsを選ぶ理由はない
525 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:56:37.52 ]: JAX-RSは地味によいものだと思う。
526 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 14:59:55.89 ]: シングルスレッドとかありえねー
527 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:18:49.66 ]: 逆だろ、単体ではシングルスレッドにしておき、
CPUコア数に応じてスケールさせたければ、プロセスを複数立ち上げておいて、
フロントのロードバランサーなりリバースプロクシで分散させればよい。

Nodeにしろ、こういったのは、パフォーマンスを上げるために、マルチスレッドではなく
RubyのEventMachineみたいにイベント駆動にすることでパフォーマンスを上げようとするアプローチなんじゃないの？

って書いてて自分でも理解してないのだが、
マルチスレッドにしつつ、各スレッドは EventMachine 形式にしたら、もっといいんじゃないの？
と思うんだけど、併用できないんですか？
528 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:35:47.71 ]: 逆とか意味不明。シングルスレッドとか糞
529 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:44:10.18 ]: シングルスレッドにはシングルスレッドの良さがある
同時1万接続をすいすい捌いてもメモリ256MBでおつりが来る
これはマルチスレッドじゃ無理
クラウド（PaaS）ではこれがコスト面で効いてくる場合がある
要は適材適所の一つ
530 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:45:51.78 ]: >>523
Viewがクライアント側に移動が始まっている、の意味がさっぱりわからんですわ。

例えばCRUDのうち、データ取得する(SELECT的)処理をするとして
AP serverは、DBから得た結果を、htmlとマージして最終的にブラウザに
渡す必要があるのは何ら変わってないでしょう？
要するにTemplateにデータを合成して、レスポンスを返す処理。

実際に、今の主流のMVCのフレームワークでも
そういったViewのテンプレート処理を持ってるし、使ってるでしょう。

Node.jsをプッシュしてたひとと同じだと思うけど、「使われている事例がある」
というだけなのに、すべてそうなっていくかのように主張しているように見える。
531 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:50:45.64 ]: >>529
ないない。
DB絡んだら1万同時接続なんて1台じゃ無理だし
シングルスレッドならなおさら無理。
さらに256MBで足りるなんて妄想もいいところ

1万接続で256MBとか馬鹿な主張はいいかげんにしろといいたい
532 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 15:58:18.20 ]: シングルスレッドはマルチスレッドになれないけど
マルチスレッドはシングルスレッドになれるんだから
シングルスレッドのほうがいいなんてありえない。
533 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:02:24.39 ]: >>530
HTMLを返す必要がなくなってきてるってこと
JSONだけ返しておけばあとはクライアント側でレンダリングする
だからクライアント側のMVCフレームワークが注目なわけ
君だいぶ遅れてるみたいだから少しはキャッチアップしておいて損はないと思うよ
534 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:15:06.17 ]: >>531
Node.jsじゃDB接続もノンブロッキングだし1スレッドで十分
DBとのやり取りってアプリ側はSQL投げて返ってくるまで待つだけじゃん？
だから影響はないよ
もちろんDB側がボトルネックじゃない前提で

>>532
用語の使い方の問題だな
シングルスレッド: イベントループで複数の接続を扱うアーキテクチャ
マルチスレッド:　接続毎にワーカースレッドを使うアーキテクチャ

まともな議論にならないなら用語変えた方がいいかもね
実際はNode.jsだってマルチスレッドだよ
イベントループ以外のスレッドは持ってる

別にNode.jsプッシュしてるつもりはないんで
必要に応じて使ってるだけ
535 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:19:45.99 ]: >>533
遅れてるとか馬鹿にしてるだけで答えになってないよ。
最終的にブラウザで表示されるhtmlはどうするんだよ
HTMLを返す必要はなくなってきてなんてないから
536 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:21:03.02 ]: bodyタグの中身は空でjsで全部書くってことでしょう。
537 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:24:45.46 ]: >>536
それ非効率極まりないね

あとJS無効にされてたらなにもレンダリングされないじゃないの。

プライベートブラウジング機能が搭載されてきてるから
JS無効になってるなんてケースは増えてる。
538 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:27:03.82 ]: フレームワークを使う人は開発効率のみ優先だから。
539 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:30:26.06 ]: >>523 >>533
それはないと断言できる
プログラムの前にキミはWebがわかってない
540 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:38:33.99 ]: >>539
同意。
他人を遅れてると馬鹿にして上から目線で発言してるわりに
アーキテクチャと利点、欠点などがわかってないわ
542 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:39:43.33 ]: フレームワーク厨はフレームワークさえ使えればなんでもいいんだよ。
君らもフレームワークをありがたがってないでネイティブに回帰すべき。
543 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:43:38.62 ]: >>535
最初は静的なHTMLで始まる（Javaで返す必要はない）
そこからロードされたJSがサーバからJSONを取得する
JSONで得た情報をJSでレンダリングする
そのためのJSで書かれたテンプレートエンジンもたくさんある
うちはHandlebars使ってる

まだそこまで極端なケースは少ないけど方向はこっち
（Twitterみたいに後戻りするケースもあるし流動的かもしれんが）
スマホのネイティブアプリとサーバ側が共有しやすいメリットも大きい
つかうちはスマホアプリが先で後からブラウザ対応が増えてきてる

ちなみに業務系はオンプレのJavaでStrutsベースのオレオレ、
それとは別にAWSでPHP、RoR、Node.jsを使ったサービスを並行してやってる
わかってないといわれるならそうなんだろう
544 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 16:49:34.93 ]: そうやって間違った方向に進んでしまうのがIT業界の悪いところだな。
545 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 17:16:33.84 ]: >>540 >>543
Google mapとかの地図サイトのように
ページの一部分を頻繁に読み込むようなサイトなら
JSは使うだろうし、それくらいは当然知ってます。
ページ全部を毎回読み込むのは非効率だし

ただ、MVCのある機能がブラウザ側に移動したというより、サーバとクライアントが
協調して動作するようなシステムが出てきたってだけの話だと思う。
結局、サーバサイドのフレームワークがなくなることはありえない。

>>523は、「分散」とかではなく「移動」といったうえで
「これでやっとStrutsとJSPの時代が終わる（JSFは始まらずに終わる）」
なんて結論づけたから噛みついたわけ。

Strutsがクソなのは知ってるけど、そこからサーバサイドのMVCフレームワークが
なくなっていくという話につなげられると
まったく同意しかねる、ということ。

Ajax, jQuery必須にしてしまえば、ブラウザでJS切ったら使い物にならないし
有効であってもバージョンの互換性でエラーが出る。
開発のコストも無駄にかかる。デメリットも大きい。
だから全般的に移行することはありえない。
デメリットを補ってあまりあるメリットがあれば使われる、というだけ

サーバだけでやるのか、サーバ＋クライアントでやるのか、
使い分けの問題であって、サーバのみでやるのが遅れているわけでもない。
セキュリティ上の理由でクライアントサイドで処理できないこともある。
546 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 17:20:06.75 ]: まったくだ。ニコ動もクライアントでいろいろやりすぎて
糞使いにくくなってる。
つまり何事もネイティブで考えることが必要だ。
547 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 18:58:11.74 ]: 中の人にはソレが段々と見えんくなってくるのでしょう。
548 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 19:24:11.12 ]: JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。

ちなみにうちは、jQueryの利用的なことから一歩進んで、JSフレームワークのLOBアプリへの適用もやりはじめた。
今までJSで個別に処理を記述していたところを、フレームワークを使って、
RESTなAPIの結果でObserverなVMのメンバを更新、バィンディングでHTMLの表示を更新というレベルだけど。
549 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 20:45:01.83 ]: >>548
> JAX-RSを持ち上げる人が多いけどさ、他に比べればマシというだけであって、まだまだだと思うよ。

どの辺がまだまだ?
550 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 21:28:07.76 ]: >>545
もちろん、なかなか消えはしないだろうけど、
徐々にviewの部分が移行していく流れだと思う
下手すると、cの部分も
本当に最後まで残るのは、モデル層だけだろう
551 名前：デフォルトの名無しさん mailto:sage [2013/04/05(金) 21:41:16.25 ]: 今後流れがjavascriptに来るだろうというのは
確実に分かる
現在のライブラリの乱立がその徴候
今はその動きの中にいる人だけが気がついてる状態だが
これがやがて、本流になる
552 名前：デフォルトの名無しさん mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 00:35:34.78 ]: 今後はクセモノであるHTTPセッションを
クライアント側メモリに持ち込むのも増えていくだろうけど、
クライアントがスマフォとかだと大きいキャッシュデータとか無理だし
サーバー側でセッション作る必要がある。
554 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:04:28.16 ]: インタラクティブな処理が必要な場合に、
クライアントサイドでのタスクを増やすってのがJSの使いどころ

このスレのJSやnode.js推してる人は、すべてクライアントサイドで
やる方向にいくと思ってるところが大間違い。
デメリットがわかってない。
必要のない場所でまでJSでやったら開発コストも増すし
ブラウザの互換性というやっかいな問題が現れる。
555 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:06:01.26 ]: ダイナミックHTML時代のままで大いに結構
Ajaxまでは求めちゃいないよ
556 名前：keisuken mailto:sage [2013/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 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:30:00.65 ]: HTMLを返す処理はなくならないが
フレームワークの要不要はまた別問題だな
俺はいらんと思うけど
558 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:33:29.51 ]: ブラウザで多くをやる方法は限界やデメリットがある以上、
サーバ側のフレームワークにとって代わることはない。

JavaのWebフレームワークのスレなのにスレ違いのレスばっかりになってる。
559 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:34:45.31 ]: >>553
>今後はクセモノであるHTTPセッションを
>クライアント側メモリに持ち込むのも増えていくだろうけど、

セキュリティホール確定。
クライアント側は当然偽装し放題ですよ。

ちなみに自分は常にJavaScriptはOFF（もちろんJavaAppletだのFlashだのも）
なので、見えないページはムカつきつつ閉じてます。
わざわざ開く価値なんてないし。
560 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 01:36:37.41 ]: >>558
JAX-RSだってJavaのWebフレームワークだからこの流れはスレ違いじゃない
自分の意見と違うからって排他的にならないでほしいね
561 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:12:52.30 ]: >>559
いまどきJavaScriptをOFFとかありえないだろ。
商品リストのページングとかSession+Ajaxでやっていたようなものにも
クライアント側が操作しても問題ないようなデータは結構あるぞ。
562 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:19:09.71 ]: >>559個人がどうするかは>>559の自由だから放っておいてやれw
ようはJS無効にしてるユーザを救うことによって得られる
利益とかかるコストをそれぞれのサイトがどう評価するかだ
563 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:24:58.73 ]: クライアントJavaScriptでバリデーションをするとか嫌だな。
たとえば登録フォームだとパスワード半角英数8桁とか以外にも
同じ名前が既に登録されているのかとかチェックするときがありうる。
そうなるとデータベースとバリデーションが関連するわけで、
Ajaxを通すのは良いとしてもバリデーション自体は鯖側で行うべきだ。
564 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 02:51:01.86 ]: クライアントから投げられる値なんて基本的に信頼できないからサーバ側でのバリデーションは
いつまでたっても必須だよ。ただsubmitする前にキー入力に応じてダイナミックにバリデーション
したい場合などはJavaScriptを使ってブラウザ上で「仮」バリデーションする場合もあるというだけ。

ただこれするには同じバリデーションロジックをJavaとJavaScriptでそれぞれ書くことになるので
二度手間になる。この点でGWTは地味に便利だった。Javaで書いたロジックをJavaScriptに変換して
ブラウザ上で使うから二度手間にならないし、Java上でロジックを書き換えるとそのままクライアント
側のロジックにも反映されるからロジックの同期も楽。

というわけでJavaからJavaScriptへのコード変換はそろそろjavaxとして仕様化すべきだと思う。
あるいはJava -> JavaScriptの変換を行う定番トランスレーターがデファクトで決まるのでも良い。
565 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 04:45:17.33 ]: >>564
で、だったらはじめからサーバーもjavascriptで書けばいいじゃん
という流れになったりしてな
node人気が出てきたみたいだし
566 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:06:19.09 ]: >>563-564
そうそう。
セキュリティ上の理由で、サーバ側でやらないといけないもの
があると書いたのはそういうValidationとか。

クライアントサイドのValidationは仮のチェックだね
レスポンスを高めるだけのものでしかない。

クライアントに渡した時点で汚染された（信頼できない）データに
なってしまうし、再度DBに入ってくるようなデータは渡したくない。

全部クライアントサイドでやる流れ、とか言ってる人は
セキュリティの観点が頭にない。
567 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:17:19.79 ]: >>566
バッカだねぇ、「全部」クライアントでやる流れなんて誰が書いた？
サーバ側でバリデーションが必須なんて当たり前すぎて議論の余地無しだよ
JAX-RS使うとバリデーションできないとでも思ってる？
BeanValidatorはMVCフレームワークと密結合してるとでも思ってる？
レベル低すぎて相手にするのやめようと思ったけど想像以上の低さに驚いたよ
568 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:24:52.99 ]: つーか「StrutsとJSPの時代が終わる」と書いた>>523でもJAX-RSのこと書いてるのに
なんで>>545みたく「サーバサイドのフレームワークがなくなることはありえない」
なんて的外れの反論しちゃうのかねぇ
あげくに「全部クライアントでやる流れ」とか誤読どころの話じゃないだろ
こんな文盲で仕事できるのかね？
569 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:26:42.29 ]: >>567
自分の発言読み返してみろよ
そう読み取られてもおかしくない表現してる

>>523なんてアホ発言そのもの
他にもnode.jsの時代になってるだの妄想垂れ流しすぎ
570 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:27:53.82 ]: >>568
おまえはJSスレに帰れよ
完全にスレ違い
571 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:29:14.15 ]: 一度スマホのネイティブアプリとだけつながるサービスの開発でもやってみると
（何が必要か考えるだけでも）知見も広がっていい経験になるんじゃないすかね？
572 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:32:39.84 ]: >>569
具体的に指摘してみろよ
どこに「全部クライアントでやる流れ」と読み取られておかしくない発言がある？
Node.jsの時代になってるってのもどこにある？
573 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:43:39.54 ]: >>572
誤解されてもおかしくない表現力だよ
他の人もそうとらえてる人がいる。

>>543もあんただろうけど滅茶苦茶

＞最初は静的なHTMLで始まる（Javaで返す必要はない）
それができない場面もあることはすでに書かれていたよな？

＞まだそこまで極端なケースは少ないけど方向はこっち
ほら、ここで自分でいってるだろう。
使えない場面がたくさんあるのに「方向はこっち」とか言ってる。

あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。
自分ではないいうのなら自分のレス番号全部書くなりトリップつけないとわからない。
この板はIDでないから
574 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 06:55:48.45 ]: >>573
> 他の人もそうとらえてる人がいる。

他の人じゃなくてさ、君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ

> それができない場面もあることはすでに書かれていたよな？

できない場面「も」あるから何？

> 使えない場面がたくさんあるのに「方向はこっち」とか言ってる。

「たくさん」っていうのは君の主観だね

> あと話の流れからみてnode.js推してる人とあんたは同一人物と判断してる。

そもそもどのレスがNode.js推しなんだよ？
ちなみに>>524は俺だよ。Node.js推してるように読めるか？
575 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:03:44.94 ]: >>574
>>524は別人だと思ったよ
俺とかいわれてもIDでないしわからない。

＞君がどの表現から「全部クライアントでやる流れ」と読み取ったのか教えてよ

散々書いただろ。めんどくさいやつだな

あんたの発言がどのレスだか判別つかないことくらいわかってくれ。
俺のレスもすべてはわからないだろう。
576 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:25:47.54 ]: >>575
「散々書いた」ってどこにあるんだよw
具体的に指摘する気はないみたいだからこれ以上は追求しないが、
勝手に拡大解釈して文句をつけるのはもうやめてくれ
577 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:33:12.04 ]: >>576
散々書いたってわからないって？
俺もお前のレスがどれだかわかんないのよ
IDでないから
そういうしょうもない掲示板でまともな議論なんてできないの
578 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:37:32.20 ]: >>577
あぁ、続ける気なんだ
別に「俺の」じゃなくていいからさ、君がどのレスのどの表現から
「全部クライアントでやる流れ」と読み取ったのか教えてよ
寝ぼけててもできる簡単なお仕事だろ？
579 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:42:19.34 ]: >>572
「APIだけ作る流れ」
「HTMLを返す必要がなくなってきてる」
580 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:42:23.42 ]: >>576
ちなみに俺は「君が」書いたレスかどうかは「気にしないで」読み返したけど
どこに「散々書いた」のか見つけられなかったよ
突然飛躍してるレスしか見あたらない
581 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:47:57.92 ]: >>578 >580
しつこいなぁ、あんたも
「続ける気なんだ」どころか真逆だわ
IDでないしょうもない掲示板でまともな議論なんてできないってかいたろうに

IDでないんだから違う相手に反論してるなんてことあるだろ？
だからこれだけレスもついたし、検証作業なんてやりたくないの。
全員が正直に自分のレスを書いてトリップ書いたりしないと今となってはわからない。
582 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:49:57.54 ]: >>579
それかよ（失笑）
Twitterが「API」も提供してのはもちろん知ってるだろ？
Twitter4Jとかあることくらいは知ってるだろ？
そのAPIはHTML返さないのも知ってるだろ？
じゃあTwitterのAPI叩くとTwitterのサーバじゃバリデーションも行わず、
「全部クライアントでやる」と思ってる？
違うだろ？冷静に考えてみてくれ
583 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:52:13.77 ]: >>581
別に違う相手でも構わないよ
>>579にしたってさっきまでの誰かと同じかどうかはどうでもいい
それで議論できないなら半年ROMってろ
584 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:54:41.95 ]: >>580
581 だけど>>579の人とは別人だぞｗ
ほら、他の人も、サーバサイドが不要になりつつあると解釈してるだろ？
だれかJS押しの必死な人がいるように見えるわけ。
でも、IDでないから同一人物かすらもうわからないわけ。
くだらないだろ？

無意味なレスばっかりになってる上にスレ違いだから、
クライアントJSの話題はJSのスレでやってくれ
585 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:56:09.01 ]: >>582
スレ違い。荒らしになってる。
冷静にスレタイを読めとしか言えない
586 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 07:59:59.38 ]: >>582
喧嘩してるとこ横レスして混乱させてすまんかった

JSONを返す流れについていってないやつは遅れてるとか
HTMLを返す仕事してるやつを小馬鹿にする発言もあったしなあ

じゃあバリデーションやデータの受け渡し以外は
全部クライアント側でやる流れってことでいいの？
587 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:01:53.46 ]: >>585
JAX-RSはWebフレームワークだからスレ違いじゃないだろ
それともここはHTMLを返すフレームワーク限定なのか？
スレタイにも>>1にもそんなこと書いてないのに？自治厨？
588 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:10:29.51 ]: >>587
スレ違いといってるのはクライアントサイドのJS

フレームワークという言葉を拡大解釈して、
スレ違いではないと強弁するのはやめたほうがいい
589 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:25:56.10 ]: >>588
俺のに限らずクライアントJSの話が主のレスなんてほとんどないだろ
どのレスがスレ違いなんだよ

「フレームワークって用語を拡大解釈」ってJAX-RSに対して言ってる？
590 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:26:15.04 ]: サーバーサイドで書かれていたビューロジックやコントローラー内の一部のロジックがJavaScriptで
クライアントサイドに書かれるようになりつつあるのは誰も否定しないと思う。

ではそれがどこまで行くのか、と考えると、まずビジネスロジックを実装したモデルやサービス層は
当面はサーバーサイドに留まる。クライアントの正直さを保証する仕組みが無いので。

ではそれ以外はクライアントに移るのかと問われると、それもやや期待過剰かなと個人的には思う。

正直今のHTML5やモバイルアプリからガンガンREST云々を叩いてクライアント側で動的に表示を
更新する仕組みは一昔前のRIAの流行の再放送を見る感じなんだよね。Flashその他でUIを作って
サーバー側をRPCで叩きまくった時代の(当時はBlazeDSとかSOAPとかだったけど。SOAP好き)。
サーバーからはJSONだけ返してHTMLはクライアントで組み立てる、というのも死産に終わった
クライアントサイドXSLTの夢を思い出させる。

なので問題点も未だに概ね共通していて、一つは検索サイトにインデックスされない、もう一つは
ハイパーリンクが難しい(モバイルアプリなんかは特にそう)。画面状態をURLに対応づける仕組みは
RIAの時代からあったけれども、それには単にUI作る以外の一手間が必要なことは今も昔もそれほど
変わらないし、DOMをグリグリいじくるのに夢中でその辺無頓着な開発者も多いような。
REST API等々使ってインタラクティブなWeb UIを作るのは簡単。でもREST APIにどっぷり依存
しながらそれ自体は全然RESTではないウェブアプリも少なくない。
さらにクライアントサイドでのHTML変換よりサーバーサイドでやった方が安全確実しかも簡単
でしょ、というのXSLTでの教訓。

このあたりの過去の教訓をちゃんと意識しないと、流行はともかく定着はしないと思う。
591 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:30:14.26 ]: 丁度今、JS側で色々やろうとして結果として中途半端な構成になっているプロジェクトに入ったので
JS側のFWを調べているところなんだだけど、正直、まだ時期早々だと感じている

View構築に関してサーバサイドFWからの依存を排除したい理由は
どうもネイティブアプリ化を睨んでいるみたいで、その主旨は理解したんだけど
まだ、そういった要件に完璧に応えてくれるデファクトなFWが存在していない
backbone.jsでは機能が足りないし、jQuery mobileは逆にサーバサイドに依存して作った方がやりやすいし
JSによるView機能も色々触ったけど、国際化等まで考え始めたらサーバから色々情報を渡さないといけないし、
結局、クライアント側でやるのは不便としか感じなかった
「できる」んだけど、「仕事としてしっかりできる」レベルには、どのFWも至っていないという印象

他にも、もっと多機能なFWもあるんだろうけど、そういうのはjQuery以外の独自ライブラリ依存だったりして
まだまだ取り組むのにはリスクが大きい感が否めない

以前のプロジェクトでは、何もかもJSでやるのではなく、
Viewはサーバサイド任せにしてイベント関連のみJSでやっていたけど
今はそういう作り方の方が断然楽だと感じる。自分がサーバサイド暦が長いせいもあるだろうけど
592 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:33:44.14 ]: >>589で「俺のに限らずクライアントJSの話が主のレスなんて
ほとんどないだろ」って書いた俺涙目w
593 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:37:56.40 ]: いいんじゃないの？
今はクライアントJSまで考慮しないとどうしようもないんだから
どうせスレ違いに拘ってるのは一人だけだろうし
594 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:43:45.27 ]: >>589
ずっと上から読み返してみ？
サーバサイドのフレームワーク不要論を唱えだした奴いるだろ
>>579 の引用がその一例

その不要論を言いだすと、Java不要論になるし
このスレも全否定だし、
スレ住人が携わっているであろうサーバサイド開発も全否定になる。

要するに、このスレもスレ住人の仕事もJavaも全否定になるから、
サーバサイドフレームワーク不要論は反論されるし、
スレ違いだと言われるわけ。

比較のためにRailsとか他の言語のフレームワークの話題でることも
あるけど荒れなかった。

違いはなにかというと、ここのスレと住人を全否定したかどうか、
だと思う。
595 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 08:57:23.38 ]: >>594
>>572は>>523からの引用だが、それのどこが「サーバサイドの
フレームワーク不要論を唱えだした」？
JavaでJAX-RSでAPIを提供するサービスを作る流れっていうのが
「Java不要論になる」？「サーバサイド開発も全否定」？
頭おかしいんじゃね？
596 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:08:47.77 ]: >>595
JSON返す流れになってるだのアホなこといってるのは
サーバサイドFW不要論そのものだろ

サーバサイド不要論唱えてる奴はいたわけ
このしつこさからしておまえの可能性高いけど
597 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:11:00.43 ]: >>595
頭おかしいだの遅れてるだの口が悪い
598 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:15:15.54 ]: >>596
JSON返すと「サーバサイドFW不要論」wwwwwwww
ダメだこいつw
俺とは「サーバサイドFW」の定義が違うようだが、
俺だけとじゃなくてこのスレ住人、Java開発者、Web開発者、
その他多くと違う定義だよそれ
負けたよ、さすがにもう相手にできないわwww
599 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:18:21.51 ]: >>598
お前来てから荒れた。出てけ
このスレは遅れていて、相手にできないんだろ
はよでてけ
600 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:19:53.00 ]: 荒らしはLLスレにいたやつと同じにおいがする
これからはJavascriptの時代だってしつこいのなんの
601 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:22:13.99 ]: このスレの連中は真面目に相手しすぎだわ
602 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:31:31.35 ]: >>601
まったくだ
俺は>>563の時点で目眩がしたわｗ
CGI全盛時代のスレかと思ったよ
603 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:42:25.02 ]: でも流行りに流されたほうが金になるというのもまた事実
604 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:53:37.29 ]: Javascriptがもう少し機能的にもデザイン的にも優れものだったら、
プリミティブ型が使えて静的型・型推論・LINQ・JAXBとか持ち合わせていたら
「これからはJavascriptの時代だ」でも別にいいけどね。
ログ出力すらブラウザ互換性云々いってる糞言語は書きたくないし、
Dartとかも出力対象のJavascriptが糞すぎて未来が絶望的だろう。

WicketはJavaコンポーネントにJavascript自動生成させることで隠蔽し、
Javascriptを開発者から少しでも消し去ろうとした素晴らしいＦＷだった。
Javascriptフレームワークが乱立する現状とは逆の立場で流行らなかったが。
605 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 09:58:25.30 ]: >>591
> どうもネイティブアプリ化を睨んでいるみたいで、

うちじゃ最初のターゲットがスマホアプリだけってケースが増えてる
先週ローンチしたサービスもそう（Webサイトはあるが静的コンテンツのみ）
だからブラウザ対応する場合も同じAPI叩くだけでやりたいって意見は強いね
SEO担当部署は抵抗してるが、検索サイトからの流入どころかブラウザで
アクセスする人が激減してるのが現実（もちろんサービスによるだろう）
LINEの成功もあってブラウザ対応はいらないってケースも増えそう
606 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 10:07:04.86 ]: >>591
クライアントJSのMVCフレームワークが乱立してるわけだけど、
世界的には一番話題になってそうでリッチなAngularJSよりも、
日本じゃシンプルなBackbone.jsが人気あるように見えるのは、
JSFとStrutsを見てるようで興味深いw
607 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 10:22:53.57 ]: >>606
apachcommons的なのなんて乱立なんてもんじゃない
手軽環境で誰でも書けるしハブとかあるからゴミが多くてフルパックじゃないとスタンダードになりえない
馬鹿でも書けるから調べて類似見つけて拡張依頼やコミッタ申請なんて事も少ない
アンドロマーケットと一緒
608 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 11:33:00.31 ]: XML+XSLTが攻守最強だな
リッチクライアントでもブラウザでも行ける
609 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 11:34:57.01 ]: もうそういうのやめてくれ
ネイティブが一番いい。
610 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 16:34:25.16 ]: とりあえずJAX-RSに関してはあまり否定的な意見は出てこないな。
611 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 22:01:52.60 ]: 評価保留って感じじゃないの、2.0になってから本番な感じだし
612 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 22:08:36.83 ]: JAX-RSの否定ではないが、各実装固有の機能を使わないと微妙、っという点は多々ある。
613 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 22:14:28.20 ]: JAX-RSはシンプルでいい
標準だけじゃ足りないって意見はあるが重厚よりはいい
各実装の独自機能も自前で作るよりはいい

JAX-RS 2.0（JSR 399）見たけどフィルターや
インターセプターが標準に含まれてるね
Bean Validationとの連携も入ってた
JerseyのViewable的なものは見あたらない

JSONが相変わらずJAXBなのだけ残念だわ
Java API for JSON Processing（JSR 353）はどうしたと
思ったら、あれマッピングは含まれてないんだと
Jerseyのjson.POJOMappingFeatureを使い続けることになりそうだ
614 名前：デフォルトの名無しさん mailto:sage [2013/04/06(土) 22:35:44.41 ]: JAX-RSに限らないんだけど、JSRと実装とか馬鹿な事はさっさとやめて、今ある各実装の良いとこどりしたMVC機能も持った単一の実装を作ってよ。
そしたらSpring MVCから乗り換えるのに。
615 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:45:35.77 ]: サーバーサイドはvalidation等のセキュリティ関連と、
データベースだけ残るだろ
あとは全部クライアントサイドに行く
それにサーバーサイドもjavaがやってる部分はnode.jsに置き換わるよ
616 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:48:56.77 ]: ないない。Javaが持つ膨大なライブラリをカバーするのに何年かかんだよ
617 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:51:23.43 ]: もう既にカバーしてるし、できないこともたくさんできてしまってる
618 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:53:08.10 ]: 釣る気満々のレスに速攻で釣られるなよ
619 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:55:43.89 ]: >>615
またJS信者湧いてるのかよ
620 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 00:59:31.13 ]: node.jsなんてlibuvだけだろ
621 名前：デフォルトの名無しさん mailto:sage [2013/04/07(日) 01:08:38.35 ]: ここ見てオシッコちびるなよ？
www.nodecloud.org/
622 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 07:24:36.04 ]: Javascript云々のくだらない流れで過疎ったぞ
623 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 10:27:17.03 ]: 【超速報】 Java8、仮想マシンに.NET/Mono採用検討開始　－　プログラミング界に激震
engawa.2ch.net/test/read.cgi/poverty/1365643043/
624 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 10:43:32.25 ]: Mono、のちのちMS.netランタイムでjarが動くようになるなら
Javaデスクトップアプリケーションにはありがたいなぁ。
625 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 10:49:37.28 ]: でも .class → JVM → .NETランタイム(CLR)ということで、変換が二重になってパフォーマンスが悪い、
ということにはならないのかな。
626 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 10:52:56.26 ]: 何事もネイティブが一番
627 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 12:21:34.13 ]: IKVMはありえんよ、最悪の選択肢
628 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 17:51:08.92 ]: 最良の選択肢はjavascript
629 名前：デフォルトの名無しさん mailto:sage [2013/04/11(木) 19:46:00.52 ]: マルチパラダイム対応が一番。
Java、Scala、Groovyを自在に混ぜて使えばよいし、それはさほど難しくない。
630 名前：デフォルトの名無しさん mailto:sage [2013/04/12(金) 01:22:11.91 ]: ScalaとかGroovyとかいらんよ
Java周辺は勉強してもすぐ消えていくから信用ならない
631 名前：デフォルトの名無しさん mailto:sage [2013/04/12(金) 01:57:44.58 ]: ScalaやGroovyをちょっと勉強してみたら
とてもそうは思えなくなる
やっぱり利便性が全然違う
632 名前：デフォルトの名無しさん mailto:sage [2013/04/12(金) 07:12:38.76 ]: >>622
JS推してたうざいやつのせいだな

>>623
Monoはまず品質をなんとかしてほしいわ
MS純正版との互換性がなさすぎてMono版のASP.net MVCは
使いものにならなかった。
633 名前：デフォルトの名無しさん mailto:sage [2013/04/24(水) 21:18:24.48 ]: Java8延期された
Java 8 Delayed to 2014 by Ongoing Security Woes
www.infoq.com/news/2013/04/Java_8_Delayed
634 名前：デフォルトの名無しさん mailto:sage [2013/04/26(金) 23:42:43.59 ]: >>632
どうやったらlinuxServer＋ASP,netとかアホな構成を選べるのかわからんけど実務で使ってるアホいるんだぜ？
635 名前：デフォルトの名無しさん mailto:sage [2013/04/27(土) 23:37:45.83 ]: EE7がそろそろ？
636 名前：デフォルトの名無しさん mailto:sage [2013/04/28(日) 23:31:36.49 ]: JavaEE使いづらいよママン…
637 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 08:26:27.28 ]: 使いづらいものをなんでわざわざ使おうとするの？、Mなの？
638 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 09:28:07.82 ]: >>637
フレームワークの選択権限俺じゃないんだよ・・・。
そりゃ俺ならSpringMVCかSASｔrutsにするよ…。
639 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 11:26:27.70 ]: 上がアホだとどうしようもないよな
640 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 11:28:42.07 ]: ﾌﾟｯ､バーカｗ
641 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 12:00:06.81 ]: >>640
なんだこいつ
642 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 14:01:22.83 ]: >>638
SpringもJavaEEつかってるんじゃないの？
643 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 17:22:34.76 ]: なに言ってんだおまえは…。
644 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 20:09:51.80 ]: >>642
・・・
開発をSpringMVCでやるかSAStrutsでやるか
標準のJavaEEでやるか？っていう話だと言えばいいのか？
SpringMVCの中身の話ではない。
単に何で開発したいかと言うことだ。
645 名前：デフォルトの名無しさん mailto:sage [2013/04/29(月) 20:25:40.36 ]: >>644
SAStrutsなんて日本でしか使われてないやつでしょ？
新規でそんなの使う意味がわからない
646 名前：デフォルトの名無しさん [2013/04/29(月) 20:29:28.26 ]: dev.worksap.co.jp/Members/inoue_se/archives/38

JavaOne参加者は、JavaEE利用者とSpring利用者が半々くらいだったらしい。

JavaEEはJavaEE5以降でSpringを取り入れてきているとも書かれてる。
純正JavaEEでやる人がまた増えてきてるということじゃないの
647 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 17:20:11.87 ]: >>645
世界で戦ってるわけでもあるまいが…。
648 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 17:53:07.34 ]: Authentication/Authorizationには皆さん何使ってる？

社内システム用にSpring Securityを使い始めたもののなんか微妙。
649 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 19:04:34.20 ]: Spring使ってるけどSpring Securityは微妙。
認証・承認って、結局システム固有の要素が入ることがほとんどなので、自分はそこはいつも自前。
650 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 19:08:13.20 ]: 今更SAStrutsを奨めもしないけど、海外でどうだからという話は無視して良いと思う。
禿とかがそういうdisりをしたりもするけど。

自分のニーズにあったものを選択するのが基本。

それに海外ではどうこういうなら、海外の人は細かい部分にルーズだ、みたいな話だってあるし。
それでJSFやJPA実装の細かい部分が微妙だったりとか。
651 名前：デフォルトの名無しさん mailto:sage [2013/05/01(水) 20:26:41.12 ]: さてJavaEE7きましたよ。
652 名前：デフォルトの名無しさん mailto:sage [2013/05/02(木) 13:40:33.64 ]: >>651
どこにきたの？
www.oracle.com/technetwork/java/javaee/downloads/index.html
653 名前：デフォルトの名無しさん mailto:sage [2013/05/02(木) 14:39:16.33 ]: https://blogs.oracle.com/theaquarium/entry/java_ee_7_platform_completes
654 名前：デフォルトの名無しさん mailto:sage [2013/05/10(金) 10:39:23.30 ]: >>650
細かい部分にルーズにしては、国産FWが少ないし
Springに比べてS2Forumのアーティクルは少ねぇよなぁ

ほんとに海外について知ってるつもり?
655 名前：デフォルトの名無しさん mailto:sage [2013/05/10(金) 11:33:01.75 ]: 良いものは海外でも流行る。
日本限定のマイナーなフレームワークなんかつかうと
すぐにメンテ終了になってしまう
656 名前：650 mailto:sage [2013/05/10(金) 12:38:17.38 ]: 俺は「世界ではJava EEが標準です(ｷﾘｯ」みたいな発言を真に受けたり引用したりするのはやめれというだけで。
別に国産FWが良いと思っているわけじゃないよん。
657 名前：デフォルトの名無しさん mailto:sage [2013/05/10(金) 13:07:44.12 ]: 俺が作ったフレームワークがどう考えても最高
658 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 09:13:44.19 ]: >>656
何でやめなくちゃいけないんだ？
事実は事実のまま捉えろよ
659 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 10:26:19.98 ]: JavaEEは最高のフレームワークです(ｷﾘｯ
ほかのフレームワークを使っている奴らは無知なだけのｶｽ
660 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 10:35:01.25 ]: フレームワークがないと作れないやつって不幸だな
661 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 15:17:14.27 ]: 標準って用語は多重定義されてるからな
JavaEEが標準仕様なのは事実だしデファクト標準じゃないことも事実
662 名前：デフォルトの名無しさん mailto:sage [2013/05/11(土) 15:41:42.22 ]: 依存性管理はそろそろデジュール標準でいって欲しいな。
そんで依存性ツリーを持たないAntプロジェクトとか撲滅して欲しい。

現状リポジトリはほぼMavenリポジトリがデファクトで、依存性解決はMavenの他に
ivyやGradle等といった複数の実装があるわけだけど、実装毎に微妙に解決した結果
が異なったりとか依存性の記法が異なるとかちょい勘弁。

って何時だよProject Jigsaw使えるようになるの。
663 名前：デフォルトの名無しさん mailto:sage [2013/05/17(金) 20:56:32.32 ]: うちなんて未だにApache Ant + CVSだよ
今年の予定がSubversionの適用とか10年遅れてるわ
664 名前：デフォルトの名無しさん mailto:sage [2013/05/17(金) 21:51:50.52 ]: もうSubversionはスキップしていいでしょw
GitやMercurialにすればよいのに。
665 名前：デフォルトの名無しさん mailto:sage [2013/05/18(土) 01:26:59.84 ]: >>663
昨年までEclipseとファイルコピーで何とかしてた俺よりましだな。
さすがに最近Git入れたけど。
666 名前：デフォルトの名無しさん mailto:sage [2013/05/20(月) 08:38:34.64 ]: CVSと用語の使い方が似ているとか長く使われて実績があるって意味ではSubversionもありはありだけど、それ以外に取り柄が無いよなぁ
分散リポジトリは概念説明からスタートだからめんどくさいとかあるのかな
構成管理担当のスキル不足で使いこなせないなんて笑えない理由だったら笑うがw
667 名前：デフォルトの名無しさん mailto:sage [2013/05/20(月) 22:57:38.89 ]: トラブルが起こらないという意味ではsubversionで十分かもな
Mavenとかだと、やれプロキシの設定だの、レポジトリが無いだの、
新しく入ったメンバーが自分で設定できないだの、
依存性が解決できないだのと、問題がつきもの
668 名前：デフォルトの名無しさん mailto:sage [2013/05/21(火) 02:38:48.74 ]: とのVCS(Subversion, Git, Mercurial, etc.)を使うかと、どのビルドツール
(Ant, Maven etc.)を使うかは基本的には直交した問題じゃないかな。

経験上ビルドツールに関してはMavenを使った方が新人対応も楽。なにせ手動で
インストールする必要のあるものを圧倒的に減らせるので開発環境の立ち上げが
楽だしメンバー間でのバージョンの同期もし易い。
Mavenの設定と言ってもひな形のsettings.xmlをコピペして社内Artifactory使う
クレデンシャルの設定だけを個々人で書き換えてもらう定型作業なので、ちゃん
と話を聞かなかったり勝手に先走る新人を除いてははまった経験もあまりない。

新人対応の面でMavenを避ける理由はあまり思いつかないかなぁ。単純に社内の
プロジェクトがAntベースか既にMavenizeされているかの問題ではないかと。

新人対応に関してはむしろVCSが問題で、GitやMercurialを使った経験のない
新人は戸惑う事が多い。updateやcommitだけしてpullやpushを忘れるのは定番
として、ブランチを切って開発するスタイルに慣れていないことが多いので。
こちらはJira等を使ったチケットベースの開発のサイクルとセットにして最初
から丁寧に手順を伝える必要がある。
669 名前：デフォルトの名無しさん mailto:sage [2013/05/21(火) 04:14:23.88 ]: 手動でインストールって何のことだ
eclipseのフォルダごとコピーして終わりだわw
670 名前：デフォルトの名無しさん mailto:sage [2013/05/21(火) 05:31:35.94 ]: >手動でインストールって何のことだ

まずはScalaコンパイラやGrailsといったビルド環境。
これらはMaven Pluginが勝手にビルド環境をダウンロードしてくれるのでScala等を
インストールしてEclipseに登録したりせずともプロジェクトのビルドはすぐ出来る。

実際にScalaやGroovyでの開発担当が回ってきた場合は結局Scala等をインストールして
Eclipseにプラグイン入れないと不便だけれども、その場合もMavenを使って実行する
ビルドやテストでは必ずpomに書かれたバージョンのビルド環境が使われるのは便利。
Jenkins等でビルドするのにもJenkinsにプラグイン入れるよりMaven任せが楽だと思う。

もう一つは複数のプロジェクトで横断的に使われるフレームワークやcommons、log4j
といったライブラリのJar。これらのJarをローカルにインストールしてクラスパスを
通しておく方式は手間だし開発者間でバージョンの同期がとれない。
プロジェクトのlibフォルダにJarを放り込んでVCSで同期する方式だとプロジェクト間
で違うバージョンのJarが使われているとやはり面倒で、そのチェックも大変。

というか膨大な数のJarに依存する昨今のJavaフレームワークを依存性解決ツール無し
で使うのは無駄に大変だと思う。
671 名前：デフォルトの名無しさん mailto:sage [2013/05/21(火) 08:17:14.09 ]: え、scalaやgradleなんて何から何までeclipseプラグインが用意してくれるし、
eclipseプラグインはローカルフォルダごとコピーすればついてくるがな
672 名前：デフォルトの名無しさん mailto:sage [2013/05/21(火) 09:38:09.94 ]: GradleじゃなくてGrailsね。
Scala IDEはともかくSpringToolSuiteは手動でGrailsを落としてきてEclipseに登録する必要が
あるし、何れにしても本格的に開発するときはコマンドラインツールやIDEの支援がないと何かと
不便なので結局これらやプラグインは手動でインストールすることにはなる。

ただEclipseプラグインに頼った場合は適切に設定されたEclipse環境が無いとビルド出来ないけど、
Mavenプロジェクトは基本的にはmavenが走れば概ね無難にmvn単体でビルド出来る。これ重要。
なので素のEclipseでもm2eclipseだけ入れてもらえればあとはプロジェクトをチェックアウトする
だけで無難にEclipse上でもビルド出来る。Eclipse等とは無関係にビルドに必要な情報は全部pom
に集約されているから環境の違いによるブレが少ない。便利だと思うけれどもなぁ。

Eclipseフォルダのコピーはやらないなぁ。人によって設定も必要なプラグインも異なるし。
プロジェクト内の.projectとか.settingsの類も基本的にはバージョン管理から外す。
673 名前：デフォルトの名無しさん mailto:sage [2013/05/22(水) 01:17:21.75 ]: 複数人開発するならMavenで管理するがいいと思うけど、
1人身開発だとあんまり利便性がない気がする・・・。

まあ、一人で開発してる俺みたいなのは少数派なんだろうけど。
単に開発者いないだけだし。
674 名前：デフォルトの名無しさん mailto:sage [2013/05/22(水) 04:34:46.93 ]: 一人で開発する場合も依存性管理は便利だけど。
ライブラリのパッケージを手動で落としてきて展開してJarをコピったり
プロジェクトのビルドパスに登録したりとかもう今更。

Eclipseプラグインをupdateサイトからではなく手動でzip落としてきて
インストールしたり、aptの類を使わずにtarballに固執する程度には
使わないのは勿体ないなぁと思う。

確かに凝ったビルドをし出すと俄然ややこしくなるしモジュールの切り分け
などに頭を使うけど、その他の大多数の定型的なビルドに関してはMavenは
すごく楽だと思う。
675 名前：デフォルトの名無しさん mailto:sage [2013/06/04(火) 23:22:07.93 ]: Mavenはリポジトリ整理してくれ、マジで

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef