[表示 : 全て 最新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
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


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

【Java】 Java Web Application Framework 総合



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


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の人とは別人だぞw
ほら、他の人も、サーバサイドが不要になりつつあると解釈してるだろ?
だれか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の時点で目眩がしたわw
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を開発者から少しでも消し去ろうとした素晴らしいFWだった。
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かSAStrutsにするよ…。

639 名前:デフォルトの名無しさん mailto:sage [2013/04/29(月) 11:26:27.70 ]
上がアホだとどうしようもないよな

640 名前:デフォルトの名無しさん mailto:sage [2013/04/29(月) 11:28:42.07 ]
プッ、バーカw

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) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<201KB

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