Java Web Application Framework総合　ver2

1 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

Java用のWeb Application Frameworkについて語るスレッド

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

前スレ
http://toro.2ch.net/test/read.cgi/tech/1338707919/

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

特徴の比較
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features

2 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

【関連スレッド】
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5
http://toro.2ch.net/test/read.cgi/tech/1220671877/

【DI】Java Spring Frameworkを語るスレ 5.0
http://toro.2ch.net/test/read.cgi/tech/1322414231/

以上、テンプレ終わり。
需要があるかわからんけど立ててみた。

3 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

>>1乙
ASP.NETの話題が増えてたしスレタイからJava外してもよかったかもな
あるいはASP.NETは専スレ立ててそっちでやってもらうか

4 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

どう考えてもASP.NETが他所でやるべきだろ

5 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

ASP.NETはJavaみたいにフレームワーク同士の組合せとかあんまり無くって、
ASP.NET MVCか、古い方のASP.NETくらいしか無いからな。
JavaはWeb層、DIコンテナ、OR/Mと色んな組合せがあるから、
難しい反面、語ることも色々あるんだよね。

と言いつつ、Struts1.xを仕事で使ってるんだけどね。
ちょこちょこカスタマイズしながら。
フレームワークを上手く使えば量産型PGを大量に投入できるので、
工数削減に寄与できるんだよね。
JSP/Servletしか使わないとか、オレオレフレームワークとか言ってるのは、
ビジネスセンス疑いますよ、ええ。

あと、どうせオプソのサポートなんて合って無い様なもんなんだし、
自前でコード読んでサポートできる技術力は会社に一人くらいは必須だよね。

6 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

１アクション１メソッドで中に何百ステップ書かれてようと気にしない
量産型PGで生産性に拘るなら当然の選択

7 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

>>2に追加

△△もっとStruts2の良さを教えてくださいSsssion6
http://toro.2ch.net/test/read.cgi/tech/1217536023/

【Java】Play framework【Scala】
http://kohada.2ch.net/test/read.cgi/php/1304277057/

Tapestryについて語ろうよ！
http://toro.2ch.net/test/read.cgi/tech/1067531714/

【Java】Wicket【HTML】
http://toro.2ch.net/test/read.cgi/tech/1132407308/

8 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

>>3-4
ASP.NETとASP.NET MVCのスレはすでにある。
ここはそのままでいいよ
ASP.NET系は一番人気あるフレームワークだから、
どういうスレタイにしてもASP.NET系の話題は出てくる。

ASP.NET MVC
http://kohada.2ch.net/test/read.cgi/php/1331013877/

【質問】ASP.NETスレ Part7【雑談】
http://kohada.2ch.net/test/read.cgi/php/1343282128/

【消しゴム】MONOを使ってみるスレ4【じゃない】
http://toro.2ch.net/test/read.cgi/tech/1329023778/

>>1 乙

9 ：デフォルトの名無しさん：2013/07/21(日) NY:AN:NY.AN

結局生ServletとかJSPとか言っているのは開発にスケールもスピードも求められて
いなくて、そのくせ一度作ったサービスを見直しもリニューアルもせず延々と延命
させ続ける客相手の受託開発メインってことかなぁ。面白く無さそう。

10 ：デフォルトの名無しさん：2013/07/22(月) NY:AN:NY.AN

最近angularjs + playframework2(scala,coffeescript,less)を使い始めたんだけど、すごく使いやすいよ。
.NET MVCと比べても作業効率が高い。でも、scalaだとスレ違いか。

11 ：デフォルトの名無しさん：2013/07/22(月) NY:AN:NY.AN

Scalaはいずれ抑えたいけど業務アプリだと出番がないな

12 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

Struts1使ってるやつがビジネスセンスどうのこうのw
利益率上げたければ生産性低いStrutsはないだろ

13 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

ScalaはJavaの代替として考えた時期もあったが
うんこフレームワークしかないのでやめた

Play!はsessionがなかったりかなり変なフレームワークで
汎用的に使えるものじゃなかった。
Lift はものすごく使いづらくひどいものだった。

Scalaはコンパイルが遅いのも問題でイライラした。

けっきょく、ASP.NET MVCが最強だった

14 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

ScalaがSession持ってたまるか
何のための関数型なんだか

15 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

ぜんぜんレイヤーが違うじゃん
どんな言語でもセッションは必要だろ

16 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

>>5
商用のなんて使ってもバグなんて直してくれないだろうに……
というのがＯＳＳに流れてついてきた奴の流れじゃろ。

17 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

playframeworkは基本ステートレスだけど、セッション持ってるよ。
まぁ、servletとは全く別物だから取っ付きにくいかもだけど、playの方が扱いやすい。
一言で言うと、Java on Rails。試してみて損は無い。
scalaがコンパイル遅いのは同意。

18 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

play2のview templateがクソだけど、
angularjsと一緒に使うことで生まれ変わる。

19 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

自社プロダクトだからスケールやスピードよりも
より安定してより細かい制御が作りこめて寿命が長くないといけないから
やっぱりJSP&Servletがいいかな。

20 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

Java on RailsをのたまうならGrailsを無視するな～

21 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

Scalaは気になるんだけど、コンパイルの遅さとか、その辺については実際どうなの？
実際に使っている人の話が聞きたいけど。

あと、個人的にはPlayよりScalatraが気になるかな。

22 ：デフォルトの名無しさん：2013/07/23(火) NY:AN:NY.AN

Scalaは戀塚氏のお気に入り

23 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

JAX-RSはCDIのConversationScopedと組み合わせると業務でも行けそうだ

24 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

Scala推せば通ぶれる、という雰囲気があるのは確か

25 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

ConversationScopedと組み合わせなくても普通に業務で使っているけれどもね > JAX-RS

26 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

>>21
scalaはコンパイルが本当に遅い。ここはなんとかして欲しい。
まぁコンパイルの遅さを差し引いいても、開発効率やメンテナンス効率が高いから全体で見るとそれ程問題ない。
コンパイルなんてほっとけば終わってるし。
Scalatraも使いやすい。Servlet派の人はこっちの方がいいかもね。

>>20
Grails？GroovyはGradleレベルのちょっとした物書くにはいいけど、
本格的なプロジェクトでは使いたくないな。
Groovyの作者もScalaを知ってたらGroovyなんて作らなかったって言ってるからね。
http://www.infoq.com/jp/news/2009/07/scala-replace-java

27 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

>>26
印象論や伝聞だけで敬遠されているのならやや勿体ないな > Grails

Grailsの良いところはGroovy云々以前にまずSpring MVCベースのフルスタックの
フレームワークとして一番普及していてメンテもされていること。
Javaで書かれたSpringベースの成果物にWebのUIを与えるのに一番の近道。

あとGroovyに関してはこれで大切なロジックを書くことまでは期待していない。
うちの会社もバックエンドやGrailsで使うにしても抽象クラスの類はJavaでカッチリ
書いている。

あとGroovyはグルー言語としてとても優れていて、Javaでカッチリ書かれたものを
Groovyでサクッと拡張してからデプロイするといった用途に便利。

28 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

おいときますね
下2行は辞めた先輩が実際に歌った歌詞だよ☆ミ

ヤバ破綻したグルーで補修した
それだけでなんか達成感
大事なのは QCD あと利益率ゥゥゥゥゥッ⁈
コストを下げなきゃ基盤の意味がない

29 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

結局普及に失敗したものは廃れる運命だからな

30 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

Hibernate同様にGrailsも認知度の日本国内外の差は妙なところだなぁ。

http://www.slideshare.net/mraible/comparing-jvm-web-frameworks-devoxx-france-2013

PlayとGrailsの比較とか。
http://www.slideshare.net/mraible/play-vs-grails-smackdown-devoxx-france-2013

31 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

Scalaやっている人は、参考までに使っているツール(IDE、他)を教えてくれないかな？

32 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

>>31
Eclipseベースは古いバージョンしかつかえない

Scalaスレ情報では
ScalaのIDEはIntelliJ IDEAが一番人気らしいよ
自分で使った感じでもIDEAが一番ましだった。

compile遅いうえに、よいフレームワークがなかったから
俺はscala自体捨てた
言語はJavaよりましだけどライブラリ、フレームワークといった
エコシステムが充実していない。
ScalaはOSSも盛り上がりに欠けている。

33 ：デフォルトの名無しさん：2013/07/24(水) NY:AN:NY.AN

ScalaはCPUリソースを使い切るような環境でもなければ出番が無さそう
AWSにデプロイできるScalaベースのソーシャルアプリとか出たら話は変わるかも

34 ：デフォルトの名無しさん：2013/07/28(日) NY:AN:NY.AN

寺田氏曰くGF4はまだ安定版じゃないとのことだがJerseyの2系(今は2.1)も同じかな？

35 ：デフォルトの名無しさん：2013/07/30(火) NY:AN:NY.AN

roadmapを見るに今年中に4.0.1が出るらしいが
本番で来年出るらしい4.1からかな、商用サポート始めるみたいにあるし

36 ：デフォルトの名無しさん：2013/08/06(火) NY:AN:NY.AN

The Curious Coder’s Java Web Frameworks Comparison:
Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts and JSF

http://zeroturnaround.com/rebellabs/the-curious-coders-java-web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-wicket-play-struts-and-jsf/

ここでもGrails...
Documentationが評価5だけど確かにGrailsの公式リファレンスは使いやすい。

37 ：デフォルトの名無しさん：2013/08/06(火) NY:AN:NY.AN

JSFが23%ってヤツら狂ってるな

38 ：デフォルトの名無しさん：2013/08/06(火) NY:AN:NY.AN

http://taichi.hatenablog.com/entry/2013/08/06/171524
Groovyの基礎的な文法を紹介する所から丁寧に書きました。

だそうだ

39 ：デフォルトの名無しさん：2013/08/06(火) NY:AN:NY.AN

毎日何かが半額のmanningが今日はGroovy関係
プロモーションコードはdotd0806

Gradle in Action
http://www.manning.com/muschko/

Grails in Action, Second Edition
http://www.manning.com/gsmith2/

40 ：デフォルトの名無しさん：2013/08/06(火) NY:AN:NY.AN

制作者がScalaを知ってたら作らなかったとか言ってた言語なのに人気あるんか

41 ：デフォルトの名無しさん：2013/08/07(水) NY:AN:NY.AN

Scalaを知っていたら敢えて新しい言語を作るまではしなかっただろう
というだけの話で、Groovyが劣っているとかそういう話じゃないだろ

42 ：デフォルトの名無しさん：2013/08/07(水) NY:AN:NY.AN

Java知っていれば学習コストはかなり低そうだからな～ > Groovy

43 ：デフォルトの名無しさん：2013/08/07(水) NY:AN:NY.AN

>>40-41
Scalaもコンパイル遅いし大したことないよ
たいして人気もでてない

44 ：デフォルトの名無しさん：2013/08/07(水) NY:AN:NY.AN

>>40
Grailsだから流行ったフレームワークではなく、まず良く出来たフレームワークが
あって、それを使うことからGroovyを再発見した人も多いのでは。
RailsやPlay!もそうだよね。人気のあるフレームワークがその言語の新規ユーザを
増やす呼び水になっている。

フレームワークとしてはGrailsは良く出来ていると思う。でかいけどね。

45 ：デフォルトの名無しさん：2013/08/09(金) NY:AN:NY.AN

Glassfish3.1.22なんだけどj_security_checkで認証すると
認証前のリクエストがPOSTだった場合でも認証後に再びPOSTされるんだよな。
なんかChrome見ると302の後にChromeはちゃんとGETでアクセスしてるから
Glassfishが認証フィルタあたりで何かきもいことやってるんだろうけど
HttpServletRequest#login使った手組だとどうにも再現できん。

46 ：デフォルトの名無しさん：2013/08/10(土) NY:AN:NY.AN

HTTPの仕様上、302はメソッドを変えずにリダイレクトするのが正しい(前がPOSTなら後もPOST)
しかしほとんどのブラウザは常にGETでリダイレクトするのでHTTP 1.1で303と307が追加された
303は常にGETでリダイレクトする (現実の302と同じ)
307はメソッドを変えずにリダイレクトする (仕様上の302と同じ)

Glassfishは303を使ってるとか？

47 ：46：2013/08/10(土) NY:AN:NY.AN

最後の一行間違った

Glassfishは307を使ってるとか？

48 ：デフォルトの名無しさん：2013/08/10(土) NY:AN:NY.AN

Glassfishは302を返してるよ。メジャーなブラウザは302にGETを返すらしい。
あとChromeは303にはGET、307には前回と同じメソッドとこちらはちゃんとしてくれる。

どうもGlassfishはj_security_checkの段階ではなく、
次のリクエストで認証してるみたい（Set-Cookieのタイミングがここ）
BASIC認証と動きを合わせるためにきもいことしてるんだろうなぁ

JBOSS ASとかも後で確認する

49 ：デフォルトの名無しさん：2013/08/10(土) NY:AN:NY.AN

きもいきもい言いすぎ
どうしたのってば

50 ：45：2013/08/10(土) NY:AN:NY.AN

どうやらこの現象はTomcat側にmaxSavePostSizeってプロパティで設定できるらしいね
Glassfishはどうやって設定するのかまだ分からないけど、JBoss AS7.1.1は無効にしてるっぽい

51 ：デフォルトの名無しさん：2013/08/23(金) NY:AN:NY.AN

wicketはダメ？

52 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

Viewをサーバ側で動的に生成する仕組みが
そもそもオワコンになってきてる気がする
MVCのMCだけサーバ側で担当してVはHTML5+JS+CSS3
連携はJSONかpjaxで。

53 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

WPFはWebのページアプリの概念を取り込んだが
Webは逆にSDIアプリの概念にシフトし始めてるのかもな

54 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

>>52
またそうやって「JSON返すのはサーバサイドFW不要論そのもの」
「その不要論を言いだすと、Java不要論になるしこのスレも全否定だし、
スレ住人が携わっているであろうサーバサイド開発も全否定」厨を煽る作戦ですね

55 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

誰が一番煽っているんだか

56 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

(・ω<) ﾃﾍﾍﾟﾛ

57 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

サーバ側はJSONだけを返せればそれで良い、…そう思っていた時期が、私にもありました(´・ω・`)

58 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

HTMLフラグメントをサーバから非同期で返す
pjaxてのがあるのか。よさげだな。

59 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

狭義(jQueryプラグイン)のPjaxは何年か前に話題になっただけでオワコン臭

60 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

よくわからんがInnerHTMLに直接代入できるテキストをくれる感じか

61 ：デフォルトの名無しさん：2013/08/25(日) NY:AN:NY.AN

javascriptでJSONパースしてはめてくって処理が要らなくなるのはええね

62 ：デフォルトの名無しさん：2013/08/26(月) NY:AN:NY.AN

pjaxは結局動的にHTMLフラグメントを生成するのに従来同様にJSPの類を使う事になる。
なので静的なページが中心で一部だけ動的にしたい場合など無理にJSONでやりとりするより
楽だし、動的でかつクローラブルでハイパーリンク可能にするのもJSON使う場合より手間は
少ない。

63 ：デフォルトの名無しさん：2013/08/26(月) NY:AN:NY.AN

>>57
一度挑戦したが結局挫折したわー。
最近のサーバーの性能だとよっぽど大規模なユーザー数のアプリじゃないと
そこまでするメリットがない上に実例がなくてだるい。

64 ：デフォルトの名無しさん：2013/08/26(月) NY:AN:NY.AN

JSONで済む割合はサイト毎に全然違うしょ
スマホネイティブアプリ向けサイト＞＞＞＞シングルページアプリ向けサイト＞＞＞＞旧来的なサイト

65 ：デフォルトの名無しさん：2013/08/26(月) NY:AN:NY.AN

つーかね、HTMLのフラグメント返した方が更新が綺麗だったり、仕組みが単純だったり、JSONよりそっちの方が良いや、ってなっちゃったりもして。

66 ：デフォルトの名無しさん：2013/08/26(月) NY:AN:NY.AN

サーバ側でやる処理と、クライアント側でやる処理を
どこで区切るかってだけの話だよね

スマホ向けWebアプリだと、意外とJSONのほうが小回り利いたりする

67 ：デフォルトの名無しさん：2013/08/27(火) NY:AN:NY.AN

HTMLのフラグメントっていうのは、partial view というか、部分的なHTMLのこと？
(<div> のなかみだけ、とか)

JS で innerHTML でさしかえる用、とか。

68 ：デフォルトの名無しさん：2013/08/28(水) NY:AN:NY.AN

そんなイメージ
jQuery使うようになってからは素のJS書かなくなって
innerHTMLとかもう遠い昔

69 ：デフォルトの名無しさん：2013/08/29(木) NY:AN:NY.AN

サーバサイドの人がJSP書きながらちょっとjQuery使うだけならPjaxいいかもね
クライアントサイドの人はBackboneやAngular、つまりテンプレートエンジンや
データバインディング使うから無用だけど

70 ：デフォルトの名無しさん：2013/08/29(木) NY:AN:NY.AN

TwitterがHTMLのフラグメントを使う様にしたとかいう話ってなかったっけ？
あれって、どういう理由でそうなったの？

71 ：デフォルトの名無しさん：2013/08/29(木) NY:AN:NY.AN

初回表示が遅くなった対策に一発目はHTML返すよう戻したって話？
表示後は今でもJSON(コンテントタイプはtest/javascriptでgzip圧縮されてる)でタイムライン更新してる

72 ：デフォルトの名無しさん：2013/08/29(木) NY:AN:NY.AN

デザインサイドだとどの程度ライブラリに依存するのがトレンドなんだい？
jQuery + Normalize.css あたりで頑張るのか、Twitter Boostrapとか使うのか

73 ：デフォルトの名無しさん：2013/08/30(金) NY:AN:NY.AN

>一発目はHTML返す
HTMLに<script>タグで囲んだJSON一緒にくっつけて
返すとかはよくやるな。リクエスト減らす目的で。

Boostrapは便利なんだけど、アレ使うとLook&Feelがまんま
Boostrapテイストになっちゃうんで、デザインちゃんと
考えてるプロジェクトだと意外と使わない。
CSSの学習素材としては素晴らしいが。
HTML5-Boilerplate + jQuery + 独自CSSって感じかな。
Normalize.cssも使う。

74 ：デフォルトの名無しさん：2013/09/09(月) 05:42:14.14

クライアントサイドでもサーバーサイドでもどちらでも良いけれども、JSONとか
使うREST APIを開発するにあたって認証はどの方式を使っている?

75 ：デフォルトの名無しさん：2013/09/09(月) 10:53:11.74

>>74
サーバサイドの REST API の場合は、クライアントがブラウザとは限らないため、
完全なステートレスでの利用を前提にハンドシェイク後にキーを発行して、
クライアントは受け取ったキーを常にパラメータとして付与しながら API を叩く
仕様にしてる。

一旦キーが発行された後は、サーバ側では、渡されたキーと接続先アドレスを
使って認証の判定をしている。自分のシステムの場合は、複数のツール/システム群から
順に連携して叩かれる事もありうるから user-agent の判定とかはあえて行っていない。

あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、
使われていないキーは一定期間が経過したらどんどん失効（削除）させてる。
実運用では律儀に終了処理なんて呼んでくれない奴の方が多いからね。

誰もが使えてもいい公共性のある API なら、そもそもそんな仕掛けも要らないだろうけれど、
緩い個体の識別から、サーバ側に登録された ID が持つ権限内容との紐付けをした上での
識別までハンドシェイク部分の作り方次第で自由に切り替えられるから、自分が最近作った
システムは大枠としてはどれもそういう作りにしてるかな？

76 ：デフォルトの名無しさん：2013/09/09(月) 11:22:00.96

>>75
> サーバ側では、渡されたキーと接続先アドレスを使って認証の判定をしている

接続元IPアドレスを認証に使うのは、IPアドレスの偽装もあり得るので危険なのでは？

と思ったが、 >>75 さんの環境がイントラ内とかだったら、わりきってそれもありかな、と思った。
(イントラネット内で、ちゃんとIPアドレスや、それがどんなサーバなりスイッチか、などが管理されていれば)

77 ：デフォルトの名無しさん：2013/09/09(月) 12:57:39.68

IPアドレスは保険みたいなもんで認証の主はキーでしょ？

78 ：デフォルトの名無しさん：2013/09/09(月) 13:53:43.53

AWS方式でリクエストをHMACで署名。

79 ：デフォルトの名無しさん：2013/09/09(月) 16:01:47.48

巷のAPIはSSLを使った上でAPI Keyでリクエスト署名ってパターンが多い気がする。
うちもそうしている。
HTTP Method name + Request Path + Timestamp + bodyからHMAC-SHA1計算して
HTTPヘッダに埋め込む。

ただこれだとクライアントの開発時にAPIをテスト目的でcurlとかで叩くことが
面倒なので、同じキーでBasic認証も出来るようにしている。

80 ：デフォルトの名無しさん：2013/09/09(月) 23:53:31.08

SSL+BASICじゃダメなの？

81 ：デフォルトの名無しさん：2013/09/10(火) 00:51:23.89

サーバではコミットしたけどクライアントで反映失敗とか
セッションハイジャックをかんがえると
OTPとはいかないまでもシリアル値くらいないとダメな場合もある。

82 ：デフォルトの名無しさん：2013/09/10(火) 04:06:22.73

>>80
認証だけなら良いと思うよ。SSLをかましているのであれば。

ただSSL経由とはいえ秘密鍵を平文で投げたくない、かつステートレスにしたい
のであれば自ずとリクエストと秘密鍵から計算したハッシュ値で署名するという
解決策にたどり着く。
仮にリクエストがのぞき見されても秘密鍵は漏れないし、ハッシュ値を計算する
データの中にタイムスタンプを含めておけばリプレイ攻撃にも多少は強くなる。

83 ：デフォルトの名無しさん：2013/09/10(火) 07:09:16.75

なるほど、勉強になります。

84 ：デフォルトの名無しさん：2013/09/10(火) 18:00:55.33

>>82
>>75と同じ人だよね？
>>75じゃサーバからクライアントにキーを渡すことになってるけど、それが秘密鍵？
だとしたらレスポンスのぞき見されたら秘密鍵漏れない？
「SSL経由とはいえ秘密鍵を平文で投げたくない」になってるのか疑問なんだが
さらに、「かつステートレスにしたい」と続いてるが>>75の以下を見るにステートレスに
なってなくね？

> あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、

85 ：デフォルトの名無しさん：2013/09/10(火) 19:20:04.33

>>84
違う人です。すまん。

86 ：デフォルトの名無しさん：2013/09/10(火) 20:34:00.07

>>85
別人か、正直すまんかった
それでクライアントの秘密鍵ってどう扱ってる？
サーバから渡すんじゃ「SSL経由とはいえ秘密鍵を平文で投げたくない」は難しそうなんだが
クライアントがイントラ内の別サーバなら楽だけどJSとかだと…

87 ：デフォルトの名無しさん：2013/09/10(火) 21:25:30.82

>>86
API Keyはセッション毎の使い捨てではなく永続的なものね。
うちのシステムでは顧客、というかデベロッパにはまずユーザ登録をしてもらって、あとは
Webブラウザから管理ダッシュボードにログインしてAPI Keyを好きなだけ生成したり既存の
キーを無効にしたり出来る。
秘密鍵の文字列はまぁ、管理ダッシュボードのWeb画面からコピペw
でもAPI Keyを使った認証を提供しているサービスはこのやり方が多いと思う。

88 ：デフォルトの名無しさん：2013/09/18(水) 22:43:53.60

画面をさくさくっと作っていきたいんですが、なんかいいフレームワーク無いですかー？

89 ：デフォルトの名無しさん：2013/09/29(日) 11:59:59.03

>>88
ASP.NETがおすすめ

90 ：デフォルトの名無しさん：2013/09/29(日) 17:43:57.35

貴方が書き込んだのはこの銀のループするスレですか?
それともこちらの金の過疎るスレですか?

91 ：デフォルトの名無しさん：2013/09/30(月) 08:36:15.59

>>88
好きなもの使いなはれ
ttp://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

92 ：デフォルトの名無しさん：2013/10/01(火) 14:51:21.87

Grails2.3か。
新機能はともかくivyを捨ててMavenと同じ依存性解決エンジンを使うように
なるのが嬉しいな。SNAPSHOTやclassifier周りのタコな動作がようやく解決。

93 ：デフォルトの名無しさん：2013/10/08(火) 21:16:15.34

Struts2もSpring2もまだ現役だというのにSeasar2ときたら…

94 ：デフォルトの名無しさん：2013/10/09(水) 22:00:27.05

やっぱり日本産は駄目だな！

95 ：デフォルトの名無しさん：2013/10/09(水) 22:03:15.11

ひとめぼれ、うまー

96 ：デフォルトの名無しさん：2013/10/09(水) 23:27:12.84

>>93
うちSeasar2バリバリ現役です・・・。
Spring2はいいとして、Struts2なんて欠陥品だろ。

97 ：デフォルトの名無しさん：2013/10/09(水) 23:31:27.53

>>95
時代は今、コシヒカリですよ！
http://i.imgur.com/sP8Stc9.jpg

98 ：デフォルトの名無しさん：2013/10/10(木) 00:42:32.12

そこでStruts1.2が現役な私の会社の出番ですよ。

99 ：デフォルトの名無しさん：2013/10/13(日) 16:00:34.45

>>93
今更GWTに手を出そうとしてる人でしょ？

100 ：デフォルトの名無しさん：2013/10/13(日) 16:12:20.17

>>94
そのとおり
SpringはRod Johnson抜けても続いてる
個人に依存しないビジネスとして成立してるわけ
日本はいつまでも個人のモチベーション頼み
そのくせ応援しないですぐdisる
OSSで身を立てるにはこの国は地獄だぜヒャッハー

101 ：デフォルトの名無しさん：2013/10/13(日) 18:14:47.77

>そのくせ応援しないですぐdisる

スマホアプリのストアのレビュー見ててもそう感じるな。
AppStore、GooglePlayともに。
無料アプリなのに、ちょっとバグがあるとか自分の端末では
動かないってだけで、鬼の首を取ったようなdisりかた。

スマホ向けアプリ作るのは海外向けがいいな。
国内市場向けに作っても旨みは少ない。

102 ：デフォルトの名無しさん：2013/11/08(金) 16:41:59.01

某ブログでそろそろSeasarは終わりでいいよね、JavaEEも悪くないという話をやっているけど
日本でSpring等々ではなく和製FWが広まって萎んで今微妙な状況になっているのはつくづく
ドキュメントやコミュニティの言葉の壁の問題なのだなぁと思う。

103 ：デフォルトの名無しさん：2013/11/08(金) 19:29:03.36

>>102
盛り上がったのは普通にseasarの出来がよかったからだし、衰退したのは開発ストップしたからだろ

104 ：デフォルトの名無しさん：2013/11/08(金) 22:11:18.14

SpringMVCでweb開発してるけど、いったん設計と実装の仕組み整えちゃえば
あとは仕様が増えても基本的に、コントローラ、インタフェース、サービス
周りのコピーでガンガンいけるから、自分的にはSpring一択だな。

105 ：デフォルトの名無しさん：2013/11/09(土) 02:04:11.76

>>102
クライアント側の新しい機能ならほしいかもしれないが、
サーバー側の開発って別にそんな新しい機能いらないんじゃないかねってのはある。
あえて新しくする必要がないというと叩かれるのかもしれんがそんな感じ。

106 ：デフォルトの名無しさん：2013/11/09(土) 09:09:47.92

Struts1.2＋内製フレームワークをJava5で動かしている弊社が最強です。

107 ：デフォルトの名無しさん：2013/11/09(土) 09:18:39.71

webアプリだとサーバ側はたしかに、だいたいやること決まってきてるしな。
モデル側処理とか認証周りとかバッチとかサブシステム連携とかviewに必要な情報の生成くらい。

フロント側は最近はブラウザの表現力と処理能力上がってるから
JSPとかのサーバーサイドテンプレート使うよりは、jQuery使ったり
Backbone.jsやAngulerJSみたいなフロントエンドMVC使うケース増えてる。
サーバーサイドとはRESTでやりとりできればいいし。

108 ：デフォルトの名無しさん：2013/11/09(土) 12:10:01.79

>>102-103
開発を継続する人材が集まらないのは言葉の壁の問題といえるな

109 ：デフォルトの名無しさん：2013/11/22(金) 03:31:52.24

Vaadinってどうなの？

110 ：デフォルトの名無しさん：2013/11/22(金) 13:52:04.12

>>104
SpringMVC関係なくね？

111 ：デフォルトの名無しさん：2013/11/26(火) 23:06:10.99

>>109
それ、俺も知りたい
vaadin日本語ドキュメント少なすぎて涙出るよねー

皆さんは画面をどうやって作ってますか？使っているフレームワークを教えて頂きたいのですが
デザイナーに丸投げしているって回答以外にあったら教えて頂きたい
GWTをここ数ヶ月勉強してみたのですが、GWTは微妙な気がします

112 ：デフォルトの名無しさん：2013/11/29(金) 23:28:49.51

自分の場合、今は画面はサーバサイドで作らなくなった。
HTML5+CSS3であれこれやってる。

こういう画面デザインの事例見てると、綺麗に作るには
画面は画面でちゃんと作りたくなる。
http://www.pinterest.com/_f7/gui-great-ui-collection/
http://pttrns.com/
http://www.uiparade.com/

113 ：デフォルトの名無しさん：2013/11/30(土) 06:16:21.11

>>111
RIA系の開発プロジェクトでGWTを使った経験があるけれども、メリットはGUIロジックもJavaで
書けるのとサーバ側のAPIを叩く非同期RPCの仕組みの出来が秀逸なこと。
逆にこの二つが無ければ単に重くて面倒なフレームワーク。基本的にJavaの開発者がGUIも作る
ケースでないとあまり意味が無いと思うし、RPCを叩かず静的なページ間の遷移だけのアプリ
であれば他のフレームワークを使った方が楽だと思う。
例えばSwing+AppletとかFlexとかで作っていたRIAをプラグインレスのDHTMLベースに以降する
場合などは開発者のスキルも比較的生かしやすいのでよい候補になると思う。ただ率直な感情
としてはこの領域、今現在もFlex+MXML+ActionScript3の出来の良さは頭一つ飛び抜けていると
思うんだよね・・・フェードアウトしつつあるのがつくづく残念。

今は専らGrails。
画面云々以前に認証やセッション管理やフィルタやロギングといったアプリを作るのに必要な
裏側の機能が手作りしないでも全部入っているフルスタックなので。
Jerseyも使うけど結局は上記のものが必要になってくるので生Jerseyを使うことは無いかな。
Grailsに組み込んで使う。
RESTであってもAJAX用途であればステートレスに拘らずセッション使った方が楽だしねw

114 ：111：2013/12/01(日) 11:15:32.04

>>112
そんな感じのリッチな画面を作りたいんです。

画面周りを手書きするのはよくあることなので我慢できますが、
javascriptを手動でデバッグするのだけは避けたいなと思いました。だから、GWTを勉強してみました。
結果、GWTは遅すぎてSSDマシンじゃないと厳しいってことがわかりました。
会社では自分の気分でマシンを変更できないので、GWTを使うのは難しいという結論になりました。

>>113
普段、Flexを使って開発しているので、Flexライクなjava frameworkが欲しいなーと思いました。
Flexは非同期処理基本だし、画面周りの制御が難しい(と言うより、処理速度が遅い）のがダメなところですよね。
javafxはflexのパクリだと思うのですが、javafxのweb版みたいなのがあればいいですよね
JSF勉強してみようかなって思いました

115 ：デフォルトの名無しさん：2013/12/02(月) 12:33:50.80

何も分かってないのが良く分かった

116 ：デフォルトの名無しさん：2013/12/03(火) 23:01:57.91

>>115
どこらへんが

117 ：デフォルトの名無しさん：2013/12/04(水) 22:23:08.22

>>114
サーバー側の仕組みに比重を置いてリッチなUI/UXを実現するのは不可能だよ。
見栄えについてはCSS3必須。その見栄えに命を吹き込むのがJavaScript。
サーバーサイドでできる範囲は、HTML5+CSS3+JSが育って実をつけるための
大地と水と肥料を用意すること。

GWTがどうとかって話じゃないことだけは確か。

118 ：デフォルトの名無しさん：2013/12/05(木) 00:11:39.37

>>117
GWTについて知らないでしょ。
知っていればサーバーサイドが云々とか言うコメントは出ない。

119 ：デフォルトの名無しさん：2013/12/05(木) 02:18:51.42

>>118
あー、すまんかった。
GAEと勘違いしてた。

120 ：デフォルトの名無しさん：2013/12/05(木) 11:24:55.81

GWTって今でもメンテされてるの?

GWTが楽ってのは聞いたことがあるけど、結局ブラウザ側のUI/UXを作り込むなら、
jQueryとかを直接使った方がいいと思っているのだけど・・・

121 ：デフォルトの名無しさん：2013/12/05(木) 16:20:11.52

jQuery を直接使って特に問題が起こらないならば、それで実現すれば良いのでは？

GWT などは Java だけで RIA がサポートできる所とかがポイントなわけですから、
（自分は使ったことないからあれですけれど）開発対象、人員、保守性、工期とか
色々踏まえて考えれば、状況次第ではアリな気がしています。

逆に凝った UI が要らなければ、旧来型の使い慣れたフレームワークや
テンプレートエンジンの方が開発も運用も過去資産も含めた実績があるので
トータルで安定するでしょうし、部分的に凝った UI が必要なら、そこだけを
重点的に対策した方が無難だと考えてしまいますね。

122 ：デフォルトの名無しさん：2013/12/05(木) 22:11:40.25

GWTはクオリティの高いUI/UX作るにはいろいろ役不足なイメージしかないな。
jQueryとその周辺プラグインのほうが、世界も広いし圧倒的に充実してるのと
Look&Feelに関しては、CSS3と各種CSSフレームワークで大抵のことはこなせる。

GWT採用しちゃうと、どうしてもGoogle風味から抜けられなくなるでしょ。

123 ：デフォルトの名無しさん：2013/12/06(金) 06:46:40.59

GWTとjQueryはちょっとレイヤーが違うので比較は出来ないかな。

jQueryはイベント周りの昨日とかjQuery UIはあるけれども総体としてはDOMの
直接操作を基本とした低水準(悪い意味じゃ無いよ)のライブラリ。
レイアウトや装飾はHTMLベースで記述して、そこにインタラクションをjQuery
で装飾していくイメージ。

他方でGWTは自身のレイアウト記述とウィジェットライブラリを持った一つ上の
レイヤーのツールキット。基本的には用意された部品を組み合わせて画面を
作る。

スタイリッシュで凝ったUIは作りにくいけれども、事務事務したおっさんくさい
UIを手っ取り早く作るのには結構便利 > GWT

124 ：デフォルトの名無しさん：2013/12/06(金) 11:46:30.47

>>123
これだけ読むとGWTはJSFと競合しそう

125 ：デフォルトの名無しさん：2013/12/07(土) 23:22:13.02

JSFってすごい難しいね
全然分からないや

126 ：デフォルトの名無しさん：2013/12/08(日) 03:06:58.87

FreeMakerがいい感じ

127 ：デフォルトの名無しさん：2013/12/08(日) 08:12:33.17

テンプレートとしてはGSPはええで。

128 ：デフォルトの名無しさん：2013/12/08(日) 16:23:40.46

GSPって、今でもGrails縛りなん？

129 ：デフォルトの名無しさん：2013/12/08(日) 22:34:18.01

JavaSEとJavaEEの違いで、SEにはJDBCが入っているが、EEには入っていない。
これは、EEに含まれているEJBの中にJDBCの機能が入っているからだと、納得してよいでしょうか？

130 ：デフォルトの名無しさん：2013/12/08(日) 22:57:00.51

JavaEEはJavaSEを含んでるから

131 ：デフォルトの名無しさん：2013/12/08(日) 23:02:22.74

>>130
なるほど。ありがとうございます。

132 ：デフォルトの名無しさん：2013/12/08(日) 23:09:42.71

中小企業の現行システム（旧来のクライアントサーバーシステム）を
Webシステム化するのですが、JavaEE＋JSF＋？・・・を考えています。
しかし、JavaEEは、中小企業レベルでは重いかなと心配です。
やはり、JavaSE + Strus2 + ・・・とかで、行うべきでしょうか？

サーバーのハード機能が良くなっているのでJavaEEでも問題ないでしょうか？

133 ：デフォルトの名無しさん：2013/12/08(日) 23:15:42.24

一番いいのはASP.NETだけどJavaじゃないとだめなの？

134 ：デフォルトの名無しさん：2013/12/08(日) 23:20:38.05

>>133
元請けの中小SIerが、Javaを希望してきているのです。

135 ：デフォルトの名無しさん：2013/12/08(日) 23:22:54.72

あー、コレ失敗するパターンやわ。

136 ：デフォルトの名無しさん：2013/12/08(日) 23:26:57.59

言語だけ指定されたとしたら、その元請は馬鹿だなｗ

137 ：デフォルトの名無しさん：2013/12/08(日) 23:34:10.39

>>135,>>136
Javaのシステムを他にも横展開したいようです。
それと、.NET系はコストが掛かるのがネックみたいです。

138 ：デフォルトの名無しさん：2013/12/09(月) 02:38:16.30

>>132
中小企業でSIerに丸投げするレベルならJavaはやめたほうがいい
Javaには開発生産性の高いフレームワークがないから、
開発のコストが高くつく。
一番高いコストはライセンス料金ではなくて人件費だよ

絶対にASP.netがベストだと思うよ
Windows認証使わずにベーシック認証を使うようにすれば
クライアントアクセスライセンスも要らない。
データベースもMySQLなどのオープンソースを使えばいい。
Windows Server(IIS)のライセンスだけならASP.netは安いものだよ。

>>137
.NETが高いとか言ってるようではそのSIerのレベルは怪しい。
SIerはJava以外はよくわかってない人ばかりなんだと思う。
そいつらの本音はJavaの知識と経験を使いまわしたいだけだよ

139 ：デフォルトの名無しさん：2013/12/09(月) 02:55:38.46

既にStrutの蓄積があるならともかく今から始めるなら普通にJavaEEかSpringMVCで
良いんじゃね?

元請けがJavaの経験あるなら彼らがそれを使い回すのは普通に合理的判断だしそこ
に.Net提案したところで干されるだけでしょ。

140 ：デフォルトの名無しさん：2013/12/09(月) 02:59:40.78

>>138
Windows認証とベーシック認証を比べる人にこの分野のアドバイスはあまり聞きたくないと思う。

141 ：デフォルトの名無しさん：2013/12/09(月) 03:16:26.31

>>140
何がおかしい？
認証方法でASP.netのトータルのライセンス料金が
大きく変わるんだから触れるのは当然だろう
Windowsの認証を使わなければ安くなる

あんたこそライセンスなにも知らないんじゃないか

142 ：デフォルトの名無しさん：2013/12/09(月) 05:58:15.33

Java 前提で話が進んでるのに、.NET と騒いで簡単に変わるものなのかな？
.NET の方が上手く扱えて交渉できそうなら、それも一つの解だと思います。

>>132
何を基準に重そうと判断してるのか外野からだと理解できないです。それより、
そのような質問をしてる時点でそもそも自分たちで作れるの？という方が心配・・・。

どんな高性能なフレームワークや素晴らしいアーキテクチャを採用してても
根幹の設計や主要な実装を誤れば低速でポンコツなものに仕上がるでしょう。
開発メンバーのプロジェクトと利用技術に対する理解の方が重要な気がします。

既に自分達で実績を持つ慣れた構成があるなら、それをベースに研究開発的要素を
極力無くすのが着実なゴールを取るための堅実な手法だと考えますが、
そういった構成が無いのであれば、時間のある内にさっさと活用する技術要素を
調査して開発メンバーで制御できる構成にまとめてしまうのが無難でしょう。
他人に言われて選定しても扱えない/向かない技術だった場合、意味がありませんので。

もっと細かいことを評価できる材料が挙げられれば、どのフレームワーク構成が
良いか？とか、具体的なアドバイスも得られやすいかもしれません。

143 ：デフォルトの名無しさん：2013/12/09(月) 07:10:54.44

>>141
認証のプロバイダとメソッドの区別のつかない人がウェブアプリの開発について何が言えるの?
あと中小のクラサバをWebアプリ化って多分イントラ向けでしょ。
普通にCALの購入が必要なパターンだと思うけど。認証方式関係ないし。

144 ：デフォルトの名無しさん：2013/12/09(月) 07:42:50.22

>>133
すれも読めない馬鹿

145 ：デフォルトの名無しさん：2013/12/09(月) 09:05:07.01

>>132 です。
みなさんアドバイスありがとうございます。
JavaEE + SpringMVC + ・・を検討してみます。

JavaSE + Struts + 手作りのDAOもどき　の経験しかないので
本当は、JavaEE + SpringMVC + ・・は避けたいのですが・・・・。トホホ。

146 ：デフォルトの名無しさん：2013/12/09(月) 09:44:11.74

自分たちで作れる＝お守りできる技術で作るのが一番。
新規の案件で新規の技術を使うとかリスクの塊じゃん。
新しい技術使いたいなら社内案件とか無難な奴でやっとけ。
ちなみに俺ならWicket+JPAかな、一番慣れてるから。

147 ：デフォルトの名無しさん：2013/12/09(月) 10:22:56.64

>>145
>JavaSE + Struts + 手作りのDAOもどき　の経験しかないので
トホホだろうね

148 ：デフォルトの名無しさん：2013/12/09(月) 11:23:30.09

JavaSEでWebアプリって作れるの？

149 ：デフォルトの名無しさん：2013/12/09(月) 21:25:28.16

>>145
JavaEE と SpringMVC は、役割がかぶってますよ

JavaEE = JSF2 - EJB3 - JPA2
Spring = SpringMVC - Spring Framework - Hibernate/JPA

Struts2 は、会社を潰したいのでなければやめた方がいい
(喩え話ではなく、中小企業なら本当に潰れます。大きい企業なら
CTO が首になる)

自分が好きにできるなら、
AngularJS - JAX-RS/Websocket - EJB3 - JPA2
かな。

150 ：デフォルトの名無しさん：2013/12/09(月) 21:51:40.90

>>149
その構成でログインや認証ってどうやります？

151 ：149：2013/12/09(月) 22:32:02.72

>>150
（要件のリッチ度によるが、) ユーザ認証・認可はアプリのレイヤではやりたくない。

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

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

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

152 ：デフォルトの名無しさん：2013/12/09(月) 23:40:25.11

>> 151
そういえば、Glassfishの商用版がなくなったらしいね

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

153 ：デフォルトの名無しさん：2013/12/10(火) 05:20:10.23

どうしてもJavaでなければいけない理由がないなら
フルスタックのフレームワークでやるほうがはるかに楽だよな
3大人気の、ASP.net、Ruby on Rails、Djangoあたりで

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

154 ：デフォルトの名無しさん：2013/12/10(火) 05:29:18.25

フルスタック必要ならGrailsで良いじゃん。Javaの資産使えるし。

155 ：デフォルトの名無しさん：2013/12/10(火) 08:41:45.63

>>153
おまえなんでこのすれにいるの？

156 ：デフォルトの名無しさん：2013/12/10(火) 09:18:24.81

たしかにw

157 ：デフォルトの名無しさん：2013/12/10(火) 09:35:55.95

>>155-156
言語はJava8でいくらかましになるが、
まともなフルスタックのフレームワークすらないJava

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

158 ：デフォルトの名無しさん：2013/12/10(火) 10:44:07.22

>>157
すれちだろ

159 ：デフォルトの名無しさん：2013/12/10(火) 13:37:54.00

>>157
Javaが嫌なら、スレから出て行けよ
スレタイも読めないのかこの池沼は

160 ：デフォルトの名無しさん：2013/12/10(火) 16:42:40.75

ASP.netくんの言いたい「フルスタックフレームワーク」が何を指すのかようわからんが・・・

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

161 ：デフォルトの名無しさん：2013/12/10(火) 17:25:48.81

>>160
GrailsはGroovyだからJavaと主張するには無理がある
GroovyなんてJavaの負の部分を引きずった醜い世界

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

162 ：デフォルトの名無しさん：2013/12/10(火) 18:28:47.80

>>161
>GrailsはGroovyだからJavaと主張するには無理がある

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

163 ：デフォルトの名無しさん：2013/12/10(火) 18:47:04.53

>>162
Grailsは使ったことある
動作ももっさりだった
これでもJavaの中ではましなのかもしれないが
他の言語の人気フレームワークより使いづらかった

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

164 ：デフォルトの名無しさん：2013/12/10(火) 20:29:35.41

ASP.netってVS無しでまともに開発できんの？
マカーでIntelliJユーザなんだが。

165 ：デフォルトの名無しさん：2013/12/10(火) 20:39:44.95

まかーはすれちもわからんのか

166 ：デフォルトの名無しさん：2013/12/10(火) 21:45:56.04

Glassfishって使い勝手とかどうなんでしょう？

167 ：デフォルトの名無しさん：2013/12/10(火) 22:16:07.56

ASP.netはスレチだが開発環境の広さという意味ではASP.netとそれ以外では歴然と差があるな。
JavaもEclipseが走れば開発環境は何でもよいという人も少なくないのでは。

168 ：デフォルトの名無しさん：2013/12/10(火) 22:23:58.35

>>167
すれち

169 ：デフォルトの名無しさん：2013/12/10(火) 22:27:56.81

Javaの開発環境の広さはスレチじゃないと思うが。というか実際何使って開発してる？

170 ：デフォルトの名無しさん：2013/12/10(火) 22:38:21.63

>>167
すてまおつ

171 ：デフォルトの名無しさん：2013/12/10(火) 22:40:54.87

>>169
パソコン

172 ：デフォルトの名無しさん：2013/12/10(火) 22:43:29.33

>>169
窓

173 ：デフォルトの名無しさん：2013/12/10(火) 22:46:37.34

>>169
キーボード

174 ：デフォルトの名無しさん：2013/12/11(水) 01:23:11.07

>>169
Eclipse

175 ：デフォルトの名無しさん：2013/12/11(水) 01:47:27.90

>>169
Vi

176 ：デフォルトの名無しさん：2013/12/11(水) 01:51:32.47

>>169
TOTO製

177 ：デフォルトの名無しさん：2013/12/11(水) 16:19:52.57

>>166
使い勝手を気にする用途に使ってるやつはいないだろう

178 ：デフォルトの名無しさん：2013/12/11(水) 19:39:42.11

GlassFishが商用サポート切るとかたまったもんじゃないな
JerseyからRESTEasyに切り替えないといけなくなりそうだ

179 ：デフォルトの名無しさん：2013/12/11(水) 19:45:15.93

やっぱasp.netが一番いいな

180 ：デフォルトの名無しさん：2013/12/11(水) 20:37:30.52

>>179
ポエムは真板へ

181 ：デフォルトの名無しさん：2013/12/11(水) 23:28:37.07

>>179
Web Froms時代はいまいちだったけど
ASP.net MVCは最高だよな

182 ：デフォルトの名無しさん：2013/12/11(水) 23:32:27.89

>>181
すれち

183 ：デフォルトの名無しさん：2013/12/11(水) 23:34:15.13

MS厨はなぜ粘着するのでしょうか？

184 ：デフォルトの名無しさん：2013/12/11(水) 23:45:27.57

ステマ

185 ：デフォルトの名無しさん：2013/12/11(水) 23:47:27.13

>>182-183
>>171-176のような無駄レスは文句をいわないくせに
ASP.netの文字が出ると感情的に批判してくるのな

186 ：デフォルトの名無しさん：2013/12/11(水) 23:51:42.85

>>185
ここでやってくれ、さようなら
http://toro.2ch.net/test/read.cgi/win/1146488925/

187 ：デフォルトの名無しさん：2013/12/11(水) 23:57:24.28

>>186
開発と関係ない板のURLはって馬鹿じゃないの？
少しはJavaの話でもすれば？

188 ：デフォルトの名無しさん：2013/12/12(木) 00:06:14.84

すれちに馬鹿といわれちゃった、わーん！！！

189 ：デフォルトの名無しさん：2013/12/12(木) 00:07:31.28

ておばちゃんか、しょうがねーな

190 ：デフォルトの名無しさん：2013/12/12(木) 10:16:01.45

真性のカスだなｗ

191 ：デフォルトの名無しさん：2013/12/15(日) 20:46:37.58

http://news.mynavi.jp/news/2013/12/13/062/index.html
Spring Framework 4.0正式版リリース - Java 8、Java EE 7に対応

192 ：デフォルトの名無しさん：2013/12/18(水) 00:19:57.11

すれちだろ

193 ：デフォルトの名無しさん：2013/12/18(水) 00:33:41.58

GlassFish使っててJBossへの乗り換えを検討してる所は少ないの？
JerseyMVCとか試そうかと思ってた矢先だったからなぁ

194 ：デフォルトの名無しさん：2013/12/20(金) 12:37:54.79

一生プログラマーでいたいならフルスタックとかで楽すればいいよｗ

195 ：デフォルトの名無しさん：2013/12/22(日) 00:56:53.89

あんだけ某関係者の人がTomcatはオワコンこれからはGlassFishとかとDisってたのに
いつの間にかGlassFishの方がオワコンになっていたのか。

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

196 ：デフォルトの名無しさん：2013/12/22(日) 02:58:54.87

Java自体が終わりそうだけどね
ライブラリがクソすぎる

197 ：デフォルトの名無しさん：2013/12/22(日) 07:51:22.48

>>196そうか残念、さようなら

198 ：デフォルトの名無しさん：2013/12/22(日) 08:45:35.32

asp.netが強すぎるからな

199 ：デフォルトの名無しさん：2013/12/22(日) 09:49:22.90

>>198
そうか、どうでもいいけど、さようなら

200 ：デフォルトの名無しさん：2013/12/22(日) 13:04:11.82

Tomcatは起動が重いんだよな。
Jettyが軽くていい感じなんだけど、Tomcatに比べて日本語情報が少ない感じ。
JDBC使うのに、JNDI周りの情報も少ない。

201 ：デフォルトの名無しさん：2013/12/22(日) 17:38:03.86

JBossが最強だろ

202 ：デフォルトの名無しさん：2013/12/22(日) 18:44:49.04

ローカル試験で使う分にはWinstoneも軽くて良いですよ。
なにせjarファイル1個で動いて、160kbくらいだし

203 ：デフォルトの名無しさん：2013/12/22(日) 20:04:05.19

JSON返すだけとかなら、Netty直利用とかも良いですよ。

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

204 ：デフォルトの名無しさん：2013/12/22(日) 20:05:57.66

組み込みサーバー＋JavaFXは今後の選択肢として大いに有り得るらしい
JAX-RSとCDIが使えないほどの軽量サーバーならちょっと勘弁だが

205 ：デフォルトの名無しさん：2013/12/22(日) 20:08:51.41

JAX-RSの実装もCDIの実装も、アプリケーション中に含めて組込サーバーといっしょに配布するで良いじゃん。

206 ：デフォルトの名無しさん：2013/12/22(日) 20:25:15.91

JBoss覚えるか。どう考えても最強だわ

207 ：デフォルトの名無しさん：2013/12/22(日) 20:39:18.03

jbossって起動に10分掛かるだろ

208 ：デフォルトの名無しさん：2013/12/22(日) 20:42:11.68

情弱乙

209 ：デフォルトの名無しさん：2013/12/22(日) 20:43:02.29

WildFly

210 ：デフォルトの名無しさん：2013/12/22(日) 20:59:18.59

richfacesでイベントを呼び出せない、俺涙

211 ：デフォルトの名無しさん：2013/12/22(日) 22:29:12.90

>>209
8.1が出てからだろ

212 ：デフォルトの名無しさん：2013/12/23(月) 15:42:07.91

>>209
WildFlyってRHELとFedoraの関係なんだろ？
名前変えられると、テンション下がるわー

213 ：デフォルトの名無しさん：2013/12/23(月) 16:25:18.46

>>212
横だけど、間違ってる、名前の問題だけ

214 ：デフォルトの名無しさん：2013/12/23(月) 16:31:32.49

むしろASがエンタープライズで使えない誤解すら生んだろうね

215 ：デフォルトの名無しさん：2013/12/24(火) 20:16:25.04

JSFで画面作ってる時に、http://java.sun.com/jsf/core ってのを使うけど
これ、primefaceとかrichfacesと何が違うの？

216 ：デフォルトの名無しさん：2014/03/10(月) 05:55:51.25

age

217 ：デフォルトの名無しさん：2014/03/10(月) 07:39:49.81

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

218 ：デフォルトの名無しさん：2014/03/10(月) 15:24:45.00

作りが悪いからに決まってるじゃん
名前が違うだけのspringだし
独創性がないから宣伝はspringの悪口だけ
目玉のHotDeployはバグバグで動かないのにサクサク開発()

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

219 ：デフォルトの名無しさん：2014/03/10(月) 18:54:22.97

スプリングググったらver4まで出ててワロタｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
初代スプリング触ったときゴミすぎで2度と触りたくないと思ったけど進化してたんだな

220 ：デフォルトの名無しさん：2014/03/10(月) 20:45:17.51

SpringMVC、使いやすいよ。
RESTと親和性高いし。
もうこれ以外使うきしない。

221 ：デフォルトの名無しさん：2014/03/10(月) 20:54:36.49

俺はPlayを使うね！！

222 ：デフォルトの名無しさん：2014/03/11(火) 02:51:10.09

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

223 ：デフォルトの名無しさん：2014/03/11(火) 03:14:13.37

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

224 ：デフォルトの名無しさん：2014/03/11(火) 07:23:44.74

めんどくさいというイメージはだいたいStrutsのせい

225 ：デフォルトの名無しさん：2014/03/11(火) 07:42:49.43

ASP.NETが神すぎる

226 ：デフォルトの名無しさん：2014/03/11(火) 12:51:19.90

型コンバートやバリデーションをコントローラでやって
アノテーションつけまくる最近のスタイルが嫌いだ

227 ：デフォルトの名無しさん：2014/03/11(火) 17:07:04.92

Convention over Configurationとかってまだ流行ってんの？

228 ：デフォルトの名無しさん：2014/03/11(火) 17:20:32.04

Java言語をマスタしても、フレームワークのお作法覚えないとダメだし
フレームワークも色々で、プロジェクトによっては勉強しなおさないといけないし
言語だけマスタしてた時に比べて、大変だよね。

229 ：デフォルトの名無しさん：2014/03/11(火) 17:28:37.61

>>227
Play frameworkは、さほどCoCにこだわってないように見えるね。
ルーティングは、routeファイルに必ず書くし。

230 ：デフォルトの名無しさん：2014/03/11(火) 19:30:14.12

>>228
チームで開発するときはアーキテクトさんが更にもう一枚「オレオレフレームワーク」でくるんで使わせるのではないか？

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

231 ：デフォルトの名無しさん：2014/03/11(火) 22:35:21.22

一周まわって、フレームワークなしのサーブレットに、必要最低限の機能を持つ基底クラスだけ自分で作って使うのがベストだと思う。

232 ：デフォルトの名無しさん：2014/03/11(火) 22:58:08.03

>>230
オレオレ作った場合、プログラマに使い方を説明してる？

233 ：デフォルトの名無しさん：2014/03/11(火) 23:54:00.32 ID:Y7xUI5Hj

>>232
APIドキュメント、サンプルプログラム、コメント付き各種設定ファイルなど一通り揃えて、取り合えずば簡単に動くものを用意
説明用の資料パワポや説明会は必要に応じて。

234 ：デフォルトの名無しさん：2014/03/14(金) 00:09:52.72 ID:K0sLkIAE

更新止まったActiveObjectsやBeanKeeperの後継とかなくて
結局JPA + Hibernateに落ち着くのか

235 ：デフォルトの名無しさん：2014/03/14(金) 00:16:16.03 ID:BtBBLClg

Seamってまだ息してんの？ｗ

236 ：デフォルトの名無しさん：2014/03/14(金) 03:00:36.47 ID:vTPAugkR

JAX-RSはフォームデータを渡した場合は@FormParamで受け取るしかない？
Servlet感覚で可変のフォームデータを受け取ってパースしたかったんだけど…

237 ：デフォルトの名無しさん：2014/03/15(土) 15:19:19.23 ID:K2uN+xbt

アノテーションもりもりMVCとかO/Rマッパー考えたやつはセンスないな
素直にServletとJDBCで十分じゃまいか

238 ：デフォルトの名無しさん：2014/03/15(土) 15:32:33.28 ID:JfWd/5x0

>>237
狂おしいほど同意

239 ：デフォルトの名無しさん：2014/03/15(土) 15:33:42.26 ID:ODzNcjwn

servletでmemcached使いたいんですが
MemCachedClient mcc = new MemCachedClient();
mcc.set("name", "Naoki Takezoe");
ってやったあとmccのインスタンスはどこにしまっておけばいいんですか？

240 ：デフォルトの名無しさん：2014/03/15(土) 16:16:57.22 ID:ha3L2y5+

>>238
開発者が100人位いるような大規模開発だとどうするの？
皆が勝手にConnection.prepareStatementとかやるわけ？

241 ：デフォルトの名無しさん：2014/03/15(土) 16:27:57.63 ID:q7u7Ew65

100人も集めて何作ってるんだよｗ

242 ：デフォルトの名無しさん：2014/03/15(土) 16:33:36.62 ID:4evGY2gy

案件規模とかそういうのはどうでもいいんだけど、
IDEの恩恵に頼って楽してコード書きたいから、そもそも今更自前でSQL書きたいとは思わないな。

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

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

243 ：デフォルトの名無しさん：2014/03/15(土) 16:44:35.64 ID:JfWd/5x0

多くて3人くらいだわ

244 ：デフォルトの名無しさん：2014/03/15(土) 16:51:05.57 ID:4evGY2gy

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

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

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

245 ：デフォルトの名無しさん：2014/03/15(土) 16:58:45.19 ID:ha3L2y5+

>>241
大企業の基幹システム開発なら100人規模なんてザラ

246 ：デフォルトの名無しさん：2014/03/15(土) 18:28:18.81 ID:Z5g2rNsd

>>245
そういう案件だとザラだけど高確率で炎上じゃね
そんなに人使う必要がある時点で発注側にも問題アリだよ

247 ：デフォルトの名無しさん：2014/03/15(土) 19:19:45.31 ID:ha3L2y5+

>>246
どんなに大規模な基幹系でも、高々10人、20人程度で開発しきれるはずと申すか？

248 ：デフォルトの名無しさん：2014/03/15(土) 19:26:41.17 ID:JfWd/5x0

どんなに大規模でもサブシステムに分割できるはず

249 ：デフォルトの名無しさん：2014/03/15(土) 19:30:27.26 ID:ha3L2y5+

サブシステムことに開発標準を作ると申すか？

250 ：デフォルトの名無しさん：2014/03/15(土) 19:40:36.57 ID:JfWd/5x0

開発標準とは何かな
そんなもの見たことないけど

251 ：デフォルトの名無しさん：2014/03/15(土) 20:11:03.06 ID:K2uN+xbt

RDBでSQLのWHEREを書かないで、KVSみたいに全部javaで書くライブラリを作ってみる
http://ideone.com/4FZZeN

252 ：デフォルトの名無しさん：2014/03/15(土) 20:45:31.84 ID:nOYr2Orx

何でみんなそんなにSQLを嫌ってるの？
SQL書けばええやん。

253 ：デフォルトの名無しさん：2014/03/15(土) 21:31:07.36 ID:rh2Bnj0w

同意。
トラブったときはSQLのほうが圧倒的に楽
昔Hibernateで痛い目にあった。。。

254 ：デフォルトの名無しさん：2014/03/15(土) 21:46:03.69 ID:LN7VnBH1

>>241

255 ：デフォルトの名無しさん：2014/03/15(土) 22:33:43.53 ID:qWn8sJ/I

引用アラシ発見

256 ：デフォルトの名無しさん：2014/03/15(土) 22:51:59.47 ID:xO9GlIgR

apacheのdbutilsが程よくJDBCをラップしてくれて好きだった
DBアクセスは自分でSQL書く方が好み
どっちも個人的な好みだから他人には強要しないけど

257 ：デフォルトの名無しさん：2014/03/15(土) 22:55:50.30 ID:JfWd/5x0

フレームワーク厨は強要してくるからなー

258 ：デフォルトの名無しさん：2014/03/16(日) 00:26:39.56 ID:UxgGr0B4

くだらない問い合わせはORマッパー通した方がくだらない間違いも起こりにくいだろ
複雑な問い合わせだけはSQL直書きするようにすればいいだけやん
目糞鼻糞だけど

259 ：デフォルトの名無しさん：2014/03/16(日) 05:05:07.42 ID:1NSc6s95

SQLで書けば、コード量は多めでも、読解難度は低い。
ORMを駆使すると、コード量は少なめで、読解難度が高くなる。

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

260 ：デフォルトの名無しさん：2014/03/16(日) 05:18:27.85 ID:cHCjLYAE

流れるようなインターフェース()の悪口はそこまでだ

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

261 ：デフォルトの名無しさん：2014/03/16(日) 06:28:50.92 ID:UxgGr0B4

おまえらはORマッパーが出来た背景を少しは調べたほうがいい
2、3人で開発するなら知らんけどそれなりの規模で大量のオナニーSQL文見せられてもかなわんだろ

262 ：デフォルトの名無しさん：2014/03/16(日) 06:38:36.02 ID:Z6fLevpG

Oracle使った時SQLは全部ストアドに書くとかやったことあるわ
SELECTのReturnはXML
あれもある意味O/Rマッパーなんだろうか

263 ：デフォルトの名無しさん：2014/03/16(日) 09:03:49.32 ID:axl38rZU

SQLをまったく意識しなくてよくなるようなまっぱができれば使いたいが

264 ：デフォルトの名無しさん：2014/03/16(日) 09:17:10.22 ID:AdE6gbYt

O/Rマッパー黎明期から期待に胸を膨らませて追っかけてきたけど
保守段階までトータルで見ると、少なくとの日本の人月ベースで
コスト計算する業界では見合わないと思ってる。

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

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

265 ：デフォルトの名無しさん：2014/03/16(日) 09:28:37.06 ID:axl38rZU

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

266 ：デフォルトの名無しさん：2014/03/16(日) 09:48:24.48 ID:AdE6gbYt

だよな。複雑なビジネスロジックをオブジェクト操作で
動的にSQL作るような仕組みだと、仕様変更とかバグ修正の場合に
マジックハンドでモノを掴むみたいな感じになるよ。
SQLならものの数分で終わるような対応が丸一日かかったり。

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

267 ：デフォルトの名無しさん：2014/03/16(日) 10:12:47.25 ID:gY7mojcT

JPAは再帰処理がないのが不満に思えたが
昨今の大規模環境ってJOIN禁止ルールとかあるみたいだし気にしなくていいのかな？

268 ：デフォルトの名無しさん：2014/03/16(日) 17:26:09.65 ID:Z6fLevpG

JOIN禁止ってマジ話？
そんなプロジェクトに放り込まれたらプロマネ殴り倒す自信あるよ

269 ：デフォルトの名無しさん：2014/03/16(日) 18:32:30.12 ID:/+q7XY+7

一部のコンシューマーサービスにおける設計の話を一般論扱いされても。
それにむしろ、そういうケースではMicro-ORMだろうし。

270 ：デフォルトの名無しさん：2014/03/16(日) 18:53:19.88 ID:Va0mC41/

指定数表以上の結合禁止、右外部結合禁止は見たことあるが、
結合そのものを禁止しているところは見たことないな。

271 ：デフォルトの名無しさん：2014/03/16(日) 19:00:58.43 ID:axl38rZU

まあ将来的には結合なんてしなくてよくなるのが理想だよ。
だからまっぱは理想なんだけど今のハードではまだまっぱには無理がある

272 ：デフォルトの名無しさん：2014/03/16(日) 19:36:35.66 ID:rxfO/+Tv

逆だろ、将来的にはいくら結合しまくっても性能が劣化しないのが理想だよ

273 ：デフォルトの名無しさん：2014/03/16(日) 19:41:36.95 ID:zMPxA87q

結合時の性能劣化がなくなるよりも先にＲＤＢが廃れそうだなｗ

274 ：デフォルトの名無しさん：2014/03/16(日) 19:44:29.10 ID:axl38rZU

え？結合なんかしたらSQLみたいじゃん

275 ：デフォルトの名無しさん：2014/03/16(日) 19:53:56.08 ID:/+q7XY+7

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

276 ：デフォルトの名無しさん：2014/03/16(日) 23:08:47.31 ID:AdE6gbYt

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

277 ：デフォルトの名無しさん：2014/03/17(月) 03:54:31.81 ID:CvNwiWhQ

ORM使いにくいって感じる状況、ORMへの知識不足が原因じゃなけりゃ、
大元のDB設計とかがいまいちだったりする感じのこともけっこうありそうな

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

278 ：デフォルトの名無しさん：2014/03/18(火) 02:18:31.77 ID:tRXj2H8I

ORMはEager fetch, Lazy fetchの問題を解決不可能なんだよ

279 ：デフォルトの名無しさん：2014/03/18(火) 09:36:03.49 ID:isJ/4bi8

>>277
DB設計が大元ってｗ
ORMを理解してないのはお前だろ
ORMを使う動機はドメインモデルをRDBに永続化することなのに
なんでDB設計が先にくるんだよアホかｗｗｗｗ

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

280 ：デフォルトの名無しさん：2014/03/18(火) 11:18:48.08 ID:+SzQB6tf

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

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

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

281 ：デフォルトの名無しさん：2014/03/18(火) 16:21:01.00 ID:SyPosiOD

次の仕事でPlay使うかもしれんとここ数日予習してるんだけどさ、
何か凄いstaticだらけで違和感覚えるんだが、
これはこういうものだと思って慣れるしかないの？
テストとかしずらくね？

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

282 ：デフォルトの名無しさん：2014/03/18(火) 19:40:51.38 ID:Xfw7AJmq

常に新規開発でDBを好き勝手やれるならそもそもこんな話してないわ
システムリプレイスするけどDBはそのままとか
DB設計は他社とかそんなんばっか

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

283 ：デフォルトの名無しさん：2014/03/18(火) 21:02:44.46 ID:SyPosiOD

>>282
サンクス。気にはなるがやっぱフレームワークの流儀に従うべきか…。

284 ：デフォルトの名無しさん：2014/03/23(日) 16:44:03.33 ID:oyP9q9vp

Javascriptに対してGAEができるなら
ORMにも似たようなのないの？

285 ：デフォルトの名無しさん：2014/03/23(日) 16:44:45.76 ID:oyP9q9vp

間違えた！　GAEではなく、GWTです。

286 ：デフォルトの名無しさん：2014/03/26(水) 04:52:17.35 ID:j07vAV4n

HSQLでfunctionつくるの楽しいわ

287 ：デフォルトの名無しさん：2014/03/27(木) 10:11:37.22 ID:9TpQSSF6

プログラミング言語「Hack」登場 - 米Facebookが発表
http://news.mynavi.jp/news/2014/03/24/416/

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

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

288 ：デフォルトの名無しさん：2014/03/27(木) 13:18:35.80 ID:V1uU5d7+

ああほんと。電動歯ブラシぐらいのエロティシズムを感じるよ
Oculusなんて買収して、どんなイノベーションを見せるんだろうね

289 ：デフォルトの名無しさん：2014/03/27(木) 22:05:13.54 ID:53iNYuED

所詮はペチパーだろ

290 ：デフォルトの名無しさん：2014/03/28(金) 12:49:21.10 ID:QHWMvAHr

PHPのDartみたいなもんじゃん。糞杉ワロタ

291 ：デフォルトの名無しさん：2014/03/29(土) 17:52:04.29 ID:lqk81omC

Javaのスレとしては、というかPHPのスレ以外もれなくだと思うが
まずPHPをベースにするのをやめろと言わざるを得ない

292 ：デフォルトの名無しさん：2014/03/29(土) 19:25:52.45 ID:ZB5YY77p

facebookが内製用に使うぶんには有効なんだろうけど
こういうのって外部の開発者が採用しても
大抵の場合はメリット出ないよね

293 ：デフォルトの名無しさん：2014/03/30(日) 17:09:49.38 ID:jhRCncdW

CGIレンタルサーバーの都合(安さ)を考えて
Java, C#をベースとした言語から => PHP, Perlに変換するとか
そういう話ではないんだね

294 ：デフォルトの名無しさん：2014/04/11(金) 23:22:52.67 ID:n3O3RPz1

Seasar2を使ってるところってもうないの？
新規案件ではSeasar2は選択肢にも入らないのでしょうか？

295 ：デフォルトの名無しさん：2014/04/11(金) 23:35:33.19 ID:Pv1Uj3xG

そんなもん使うぐらいならStruts使えって言われる

296 ：デフォルトの名無しさん：2014/04/11(金) 23:49:08.61 ID:HW4sCI/6

Seasarプロジェクト自体がもうオワコンだしねぇ。
今後を見据えたら、Java8でSpringでしょ。

297 ：デフォルトの名無しさん：2014/04/12(土) 00:10:02.61 ID:SAIw86Ow

Playだ、Playを使うんだ

298 ：デフォルトの名無しさん：2014/04/12(土) 00:14:19.11 ID:qS4Q8Ow0

Freemarkerもなかなかいいよ。

299 ：デフォルトの名無しさん：2014/04/12(土) 01:02:21.33 ID:r3JAB95t

出来が良い悪い以前に日本のプロダクトは長続きしないな

300 ：デフォルトの名無しさん：2014/04/12(土) 01:18:14.99 ID:D3xQkXal

支える人が少ないからな

301 ：デフォルトの名無しさん：2014/04/12(土) 08:35:02.06 ID:NN09N+xI

この記事最近のだけど今頃脱Strutsとか言っててちょっとポカーンなんだが
保守作業とかならわかるが新規プロジェクトでいまだにStruts1.x系選択するところとかあんの？
SAStrutsっていうならわかるけど書いてないし
ttp://gihyo.jp/news/report/2013/09/1901?page=1

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

302 ：デフォルトの名無しさん：2014/04/12(土) 10:07:33.97 ID:SAIw86Ow

新しいフレームワークは分からんとか言われて去年Struts1.3で作らされた

303 ：デフォルトの名無しさん：2014/04/12(土) 11:05:52.31 ID:qS4Q8Ow0

脱Struts→HTML5

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

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

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

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

304 ：デフォルトの名無しさん：2014/04/12(土) 11:09:01.50 ID:hPdTJsHF

業務アプリごときJSF2で困ることがない

305 ：デフォルトの名無しさん：2014/04/12(土) 11:58:38.19 ID:qS4Q8Ow0

まぁそれも１つあるよな。
業務アプリに見栄えのするUI/UXの必要性なんて
そもそもユーザーが求めてないわけだし。

306 ：デフォルトの名無しさん：2014/04/12(土) 12:10:13.70 ID:ONqK3e5x

ほんそれ
客にオナニーみせつけんなって話し

307 ：デフォルトの名無しさん：2014/04/12(土) 19:48:03.14 ID:r3JAB95t

JSF2とSpringMVCなら後者で

308 ：デフォルトの名無しさん：2014/04/12(土) 20:35:30.10 ID:g8OqBVnG

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

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

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

309 ：デフォルトの名無しさん：2014/04/12(土) 21:16:25.65 ID:SAIw86Ow

前者みたいなの作ってて楽しくもなんともないけど仕事あるだけマシと思ってる

310 ：デフォルトの名無しさん：2014/04/12(土) 21:20:03.72 ID:ONqK3e5x

俺も楽しいことは趣味でやってる

311 ：デフォルトの名無しさん：2014/04/12(土) 22:27:17.38 ID:rg8ub121

仕事

312 ：デフォルトの名無しさん：2014/04/12(土) 23:54:13.53 ID:r3JAB95t

JSFはブラックボックス

313 ：デフォルトの名無しさん：2014/04/13(日) 12:09:15.45 ID:IgSj2Mvb

動けばいいのよ
保守するのは自分じゃないし

314 ：デフォルトの名無しさん：2014/04/13(日) 12:46:33.29 ID:pKpG+lHA

やっぱり今から勉強するならspringが無難だよね。

315 ：デフォルトの名無しさん：2014/04/13(日) 17:12:24.83 ID:ifFweta+

>>313
お前、お前みたいな奴が、お前な、マジでお前
お前ーー！

316 ：デフォルトの名無しさん：2014/04/13(日) 19:33:38.13 ID:FZex5Lh6

仕事だからとか、意外とみんな真面目なんだな。

317 ：デフォルトの名無しさん：2014/04/13(日) 22:52:01.73 ID:6wRC3zPh

http://gihyo.jp/news/report/2013/09/1901?page=2

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

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

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

318 ：デフォルトの名無しさん：2014/04/14(月) 00:44:17.72 ID:S4Y/C9C3

>>317
次世代型って>>303みたいなの？
今の時点での生産性なら従来型じゃね
次世代型とか慣れるのに苦労しそう

319 ：デフォルトの名無しさん：2014/04/14(月) 00:47:17.09 ID:VmjrJFRy

>次世代型：クライアントとサーバ間をデータのみで通信し，画面の
>生成から表示までをクライアントで行う方式。

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

320 ：デフォルトの名無しさん：2014/04/14(月) 00:48:12.31 ID:K3Aga8vq

>>319
じゃあ本当の次世代型は？

321 ：デフォルトの名無しさん：2014/04/14(月) 00:49:40.99 ID:vxOO2AsC

>>318
>>317のURLに書いてある「次世代型」。

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

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

322 ：デフォルトの名無しさん：2014/04/14(月) 00:50:10.04 ID:Bgbj7M78

XML+XSLTで昔からできたのに全然普及しなかったな

323 ：デフォルトの名無しさん：2014/04/14(月) 01:09:57.18 ID:VmjrJFRy

>>320
Oracleの中の人の認識だと、まだajax使ったREST+JSON止まりなんだろう。
もうすでに、pjax+pushStateがメインで、今までのjsonベースの仕組みは
補助的に使う感じの動きになってきてる。

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

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

324 ：デフォルトの名無しさん：2014/04/14(月) 01:19:47.94 ID:Bgbj7M78

pjaxも所詮RESTじゃん
JSFと違ってJAX-RSにVIEW実装なんて定義してないぞ

325 ：デフォルトの名無しさん：2014/04/14(月) 02:26:03.09 ID:3UflCQPn

次世代型って要はAjaxとJQueryでUI手書きかGWTってことでしょ。
旧来型には、javascriptを隠蔽するJSPタグライブラリとか
Wicketコンポーネントなんかがこちらに含まれるのかな。

326 ：デフォルトの名無しさん：2014/04/14(月) 04:19:53.32 ID:K3Aga8vq

>>323
元々PushState + Ajax = Pjaxじゃねーの？
そのPjaxにもう一回PushState加えるってどういうことだよ？w

327 ：デフォルトの名無しさん：2014/04/14(月) 18:51:03.43 ID:0uxeI5tF

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

328 ：デフォルトの名無しさん：2014/04/14(月) 19:02:38.25 ID:xOOCf4Oc

Servlet使ってるところのソースは大抵糞コードだから読まされる立場だとうんざりするけどな

329 ：デフォルトの名無しさん：2014/04/14(月) 20:01:34.37 ID:K3Aga8vq

このスレっていつもループしてるよね・・・
適当に上の方へ戻っても話がつながって読める

330 ：デフォルトの名無しさん：2014/04/14(月) 21:13:37.20 ID:A+X5vC8x

まったくなｗ

331 ：デフォルトの名無しさん：2014/04/15(火) 00:54:06.51 ID:fDug8lKN

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

332 ：デフォルトの名無しさん：2014/04/15(火) 01:04:58.06 ID:W7pkbwhx

Oracleの人は立場上、自社のJava EE7を推したいわけでしょうから
Java EE7標準を使った開発が、オラクルの言う「次世代型」でしょう

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

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

333 ：デフォルトの名無しさん：2014/04/15(火) 01:16:41.62 ID:QjDXpoj9

phpだとcakephpが個人・学生から企業まで定番化してるっぽいけど
jsf2とかspringmvcがその地位には立てそうにないなー

334 ：デフォルトの名無しさん：2014/04/15(火) 01:26:31.68 ID:fDug8lKN

>>332
わけがわからないのはJavaじゃなくてJavaScriptのことだと思うけど、
とりあえず一つ追っかけるなら、今だとAngularJSがいいんじゃないかな。
読んでないけど日本語の本も一つ出てるし、来月にはオライリーの翻訳本も出る予定。

335 ：デフォルトの名無しさん：2014/04/15(火) 01:56:57.27 ID:v7jURM3H

JavaScriptは、後から後から話題になる要素技術がどんどん出てきて
トレンドが変わっていく
アメリカではそういうの自分たちでどんどん作って送り出すけど
日本じゃそれを表向きはドヤ顔で、内心ヒーヒー言いながら追いかけて
疲弊するだけ
不毛すぎる

336 ：デフォルトの名無しさん：2014/04/15(火) 02:22:34.80 ID:1MwGXkoj

そろそろ表向きドヤ顔もできない感じになってきたわ
Webアプリやりたくねぇよ

337 ：デフォルトの名無しさん：2014/04/15(火) 07:34:40.23 ID:dqyEhytG

Web系はドヤってなんぼだろw
黙々と作業だけしてたら底辺臭が滞留してきちゃうからね

338 ：デフォルトの名無しさん：2014/04/15(火) 08:14:59.36 ID:v7jURM3H

去年辺りまではbackbone.jsがオススメされて
今年はAngularJSがはやってるよね
来年はまた別のものが流行して
再来年にはまた別のトレンドが来る
一貫してるのはなんだかんだでjQueryがデファクト

339 ：デフォルトの名無しさん：2014/04/15(火) 15:28:26.34 ID:okfDyzRj

ドヤ顔で講釈垂れてもな・・・
職場の人間は正直だと思うぞ

340 ：デフォルトの名無しさん：2014/04/15(火) 20:31:58.52 ID:2GI32+no

最近の流行はJsViewsじゃないの？

341 ：デフォルトの名無しさん：2014/04/16(水) 01:13:38.68 ID:JEVwiYNE

>>335,338
Javaも以前は同じだったじゃん
2000年にStruts 1.0とTapestry 1.0、2001年にWebWork 1.0、
2003年にJSF 1.0、2005年にWicket 1.0、2006年にClick 1.0…
ORMやDIコンテナも含めるとあの頃のJavaは今のJSよりもいそがしかった気がするけどな。

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

342 ：デフォルトの名無しさん：2014/04/16(水) 01:13:43.98 ID:F5idbQac

jQuery以外はdartでも触ってたほうが良さそう

343 ：デフォルトの名無しさん：2014/04/16(水) 01:15:52.69 ID:F5idbQac

ひがやすを & やねうらをは兄弟らしい

344 ：デフォルトの名無しさん：2014/04/19(土) 04:47:43.50 ID:FUH9Y5av

こういうの見ると、継続的なサポート力というのは重要だなあと。
5年後はすたれてそう・・みたいなフレームワークへの依存は避けたい・・

Apache Struts2 脆弱性に注意、IPA
http://news.mynavi.jp/news/2014/04/18/139/

345 ：デフォルトの名無しさん：2014/04/19(土) 09:22:13.99 ID:0YBgM8kF

Struts2は後年にフレームワークの歴史における失敗作として語り継がれそう
やはり兄より優れた弟など存在しないんだ

346 ：デフォルトの名無しさん：2014/04/19(土) 10:16:08.10 ID:Ak5/X6S3

Struts3ってどうなったんだ？

347 ：デフォルトの名無しさん：2014/04/19(土) 12:31:51.21 ID:mSHOuAyg

正直もうJava EE一本化でいいんじゃないのか
標準だからStrutsやSeasarみたいに数年でオワコンにはならんし

348 ：デフォルトの名無しさん：2014/04/19(土) 21:06:21.46 ID:w81l5j3j

アクションベースのWeb FW、モダンなテンプレートエンジン、Micro-ORM
…を熟れるレベルまで標準化してくれるなら、そしたらEEでも良いよ、
っという意見は昔からあるけどな。

349 ：デフォルトの名無しさん：2014/04/22(火) 20:51:03.30 ID:rtReb1s3

NodejsやAngularJS使っている開発でyeoman入れている人いる?

350 ：デフォルトの名無しさん：2014/04/23(水) 21:47:01.86 ID:bQZ6NqwX

例えば、Strutsを避ける
http://www.scutum.jp/information/waf_tech_blog/2014/04/waf-blog-036.html

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

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

351 ：デフォルトの名無しさん：2014/04/24(木) 01:22:07.08 ID:uw+Asd59

node.js使ったサーバーサイド開発やってるのに
未だにJavaとJavaScriptの違いが解らないアホがいるってのが驚きだわ

352 ：デフォルトの名無しさん：2014/04/24(木) 01:26:25.43 ID:FuqK6IF4

>>350
そのエントリ書いた人、StrutsとStruts2は全くの別物だってことと、
Struts2は少なくとも日本じゃポピュラーじゃないってことを知らなさそう

353 ：デフォルトの名無しさん：2014/04/24(木) 22:11:08.66 ID:MRzySO8u

今更?。Struts2は出た当初から致命的な脆弱性がある欠陥品だと言われていたでしょ。
MBSDで暫定的なものであるが、サーブレットフィルタのソースコードを公開したよ。
http://www.mbsd.jp/img/testFilter.java

354 ：デフォルトの名無しさん：2014/04/24(木) 22:42:18.68 ID:MRzySO8u

最近、JavaEEやspringMVCからJavascriptへ
トレンドが移行している印象を受けるね。

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

355 ：デフォルトの名無しさん：2014/04/24(木) 23:17:35.98 ID:cbIcERKc

【IT】サイト構築ソフト・ストラッツ1(Struts 1)に欠陥　パッチなく官公庁などサイバー攻撃の恐れ [4/24]
http://ai.2ch.net/test/read.cgi/newsplus/1398347971/

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

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

356 ：デフォルトの名無しさん：2014/04/25(金) 22:40:29.27 ID:FYFW/3hR

>>355
開発案件に影響は出ていないが、技術的な部分が日進月歩なので表面化しつつある。
WebがHTML5に向かう中で、Javaが担う機能を、どこまでJavascriptで
担えるかというところで微妙になってきた。
基幹業務システムをJavascriptで作る時代がきそうだと。

357 ：デフォルトの名無しさん：2014/04/26(土) 10:22:26.71 ID:/UOqj8HA

乱暴に言えば基幹システム＝DBアクセスだから、サーバサイド開発をゼロにするって無理だろ
JavaScriptから直接SQL叩くことを許可するのか？

358 ：デフォルトの名無しさん：2014/04/26(土) 12:23:42.67 ID:lOzkg/HI

>>357
クライアントではなくてサーバーサイドJavascriptの話をしているのだから
それ的外れな指摘だよ

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

359 ：デフォルトの名無しさん：2014/04/26(土) 14:17:54.62 ID:0Ekcs7fW

>>356
＞基幹業務システムをJavascriptで作る時代がきそうだと

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

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

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

360 ：デフォルトの名無しさん：2014/04/26(土) 14:50:52.36 ID:9olkSe8L

サーバーサイドJavaScriptといえばIBMがこういう記事出してるな。
http://www.ibm.com/developerworks/jp/java/library/j-nodejs/
それにIBMのBlueMixなんかは基幹系開発も用途に含むPaaS環境だけど
node.jsやRubyも対象にしてる。

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

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

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

361 ：デフォルトの名無しさん：2014/04/26(土) 16:46:48.48 ID:Gh1hsEgS

JavaScriptもこんな流行るとは思わんかったよ

362 ：デフォルトの名無しさん：2014/04/26(土) 17:49:10.55 ID:A9kxPHhN

現状ではpaypalの開発が代表的かな。
http://www.infoq.com/jp/news/2014/01/paypal-java-javascript

363 ：デフォルトの名無しさん：2014/04/26(土) 20:18:05.95 ID:lOzkg/HI

node.jsでサーバー書くより
ブラウザでjavaなりc#が動いてくれたほうがよっぽどありがたい

364 ：デフォルトの名無しさん：2014/04/26(土) 21:29:20.02 ID:ro7ZL/nR

>>357-358
SQLではないけどAWSのDynamoDBはブラウザのJSから直接アクセスするための機能が
既に備わってるからあながちあり得ないって事はない

http://aws.typepad.com/aws_japan/2013/11/fine-grained-access-control-for-amazon-dynamodb.html

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

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

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

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

365 ：デフォルトの名無しさん：2014/04/26(土) 21:42:46.56 ID:ro7ZL/nR

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

366 ：デフォルトの名無しさん：2014/04/26(土) 22:40:13.33 ID:0Ekcs7fW

>>365
大規模開発での静的言語の優位性を否定するとかありえないわ

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

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

367 ：デフォルトの名無しさん：2014/04/26(土) 23:26:36.12 ID:ro7ZL/nR

>>366
優位性を否定してるんじゃなくて、その優位性が重要な要素とはならないって言ってる
まぁ、スレ違い気味だしわかれとはいわんよ

368 ：デフォルトの名無しさん：2014/04/27(日) 00:08:06.48 ID:TaRvNbvP

>>363
silverlightやアプレットやってた人間からすると、それは絶対やだ。

369 ：デフォルトの名無しさん：2014/04/27(日) 01:25:17.57 ID:iHo3u08N

動的言語ってchar1単位で操作したりするの向いてないだろ
もうjavascriptを使うこと自体が目的化してるんじゃないか？

370 ：デフォルトの名無しさん：2014/04/27(日) 01:33:26.98 ID:BDQFGh+O

>もうjavascriptを使うこと自体が目的化してるんじゃないか？

フロントエンド系やってる連中は、そんなことを目的にしてたら
デスマーチの深淵に落ちていくことくらいよく解ってるよ。
あいつらはいかに楽をするか自動化をするかってところが目的になってる。

「結果的」にブラウザ上でJavaScriptを動かすために
ローカルPCに仮想環境突っ込んでvagrant, chef, yoemanとかで
環境作って裏ではRubyが動いてたりもうカオス。
でもこの環境構築自体も今やコマンド一発とかそんな世界。

一部分では下手なサーバサイド開発よりも楽できる世界が構築されつつあるが
Webアニメーションとかやってる連中は相変わらず死んでるな。
Androidという魔物に挑んで力尽きていくやつらの亡骸が山積みだ。

371 ：デフォルトの名無しさん：2014/04/27(日) 01:43:14.20 ID:ldpp9/Fe

そもそもweb系でバイト単位の操作をすることはそんなに無い。
仮にそういうのを意識しないといけないことがあっても大体ライブラリでカバーできてるし。

372 ：デフォルトの名無しさん：2014/04/27(日) 11:56:19.52 ID:DSVMBd2h

サーバ側でjavascriptを使うことがメルヘンなのだろう

373 ：デフォルトの名無しさん：2014/04/27(日) 20:26:48.25 ID:iHo3u08N

>>371
アプリケーション層で自由度の低い言語ってありえないだろ
構文解析コンテンツとか作れないじゃん

javascriptはかなり貧弱だから
頻繁に他の言語で実装されたプラグイン呼ぶことになる

そもそもjavascript自体が嫌われているのに
UI層と同じ言語を使いたいという動機だけではデメリットのほうが多いよ

374 ：デフォルトの名無しさん：2014/04/27(日) 20:36:30.94 ID:Y7/VjSrw

Google Apps scriptとか技術的にどこまで応用されるのか
見極めないといけないね。

375 ：デフォルトの名無しさん：2014/04/27(日) 21:28:19.68 ID:ldpp9/Fe

>>373
node.jsだとバイナリデータも扱うこともできるみたいだし、自由度が低いってことは無いと思う。
というか自由度を求めるんなら極端な話Cで全部書けばいいんじゃね？
用途とか目的とかコストとか考えた時、自由度はある程度切り捨てられるものだ。

サーバーサイドでnode.jsやらを使う利点は、学習コストが極端に低いこと。
なんせweb系やるならjavascriptはほぼ必須だから。

とはいえjavascriptで組みたくないってのは同意。

376 ：デフォルトの名無しさん：2014/04/27(日) 22:23:43.64 ID:BDQFGh+O

TypeScriptいいよ

377 ：デフォルトの名無しさん：2014/04/28(月) 09:43:29.05 ID:iyQuG+yT

altJS系の動きも、JSをサーバサイドで使うことより
もっと大規模開発に向いた言語でフロントエンドやりたいって人が多いと思う
結果的に1言語で十分になるならいいことかもしれんが

378 ：デフォルトの名無しさん：2014/04/28(月) 14:01:38.33 ID:xn2yHDgI

ポストJSはDartが一番良さそうだけど（Javaのブラウザ用サブセット同然）
IEのシェアが圧倒的だから、googleの思惑通りにブラウザから
直に動かす言語としては普及させられない

代わりにMSがTypeScriptあたりをごり押しで普及させてくれれば良いのだが
あそこは相変わらず意味不明なことばかりに力を入れているな

379 ：デフォルトの名無しさん：2014/04/29(火) 02:57:59.13 ID:ZSDL+puO

CoffeeScript, TypeScriptを仕事で使ってみて
結局素のJavaScriptとjQueryに戻ってしまった

380 ：デフォルトの名無しさん：2014/04/29(火) 12:31:30.66 ID:97SzX9yM

今のWebはごちゃごちゃ流行りものをやりすぎなんだよとしか言いようがないな。
大体どれも3年後、5年後には失笑されるような技術ばかり。

実験プロジェクト的なものがこの世に存在する意義はあると思うけど、
それらの拙速な製品への適用はほんと愚かだよ。

381 ：デフォルトの名無しさん：2014/04/30(水) 03:20:47.67 ID:2d6NgZQo

ファッションやら家電に車とかで、今これがすごい！流行りはこれ！
みたいにブームを作って商売するのがこの界隈にも増えただけだと思うわ。
HTML5なんかまさにそれだと思う。
需要喚起って意味では良いのかもしれんが完全に手段が目的になってる気がする。
金稼げないと飯は食えんけどさ。

382 ：デフォルトの名無しさん：2014/04/30(水) 03:30:41.63 ID:kmUIe8Mk

Javaだってそうだったじゃん
Jakartaとかから次々と流行り物が出てきてJavaWorldなんかで特集されてみんなおっかけてたじゃん
Strutsだってそうやって流行ったものじゃん

383 ：デフォルトの名無しさん：2014/04/30(水) 06:38:09.24 ID:EevbxBHK

Javaも含めて言ってるんだろ

384 ：デフォルトの名無しさん：2014/04/30(水) 08:39:19.02 ID:cWCT2Qaf

土台となるjavascriptちゃんとしてればいいけど
phpがjavaの後追いしてるのと同じ不毛さを感じる

385 ：デフォルトの名無しさん：2014/04/30(水) 09:10:41.01 ID:3K+DNrAY

例の脆弱性で、ようやくStruts1からの脱却が進みそうですな。

周りの人に聞いてみると、JavaEEが次のフレームワークのファーストチョイスっぽいね。理由は「標準」だかららしい。それじゃOracleの思う壺ですけどね（笑）

OpenSSLの事もあり、OSSのソフトウェアをなるべく避ける風潮が何と無く社内にあり、開発がやり辛くなりそう。

386 ：デフォルトの名無しさん：2014/04/30(水) 10:10:27.63 ID:jTcbfh7J

今はJavaEEかSpringの2択のところが多いな。

387 ：デフォルトの名無しさん：2014/04/30(水) 14:39:09.69 ID:lR7rpqex

NEC製のオレオレフレームワーク使わされそう
ググったらオープンソースのフレームワーク組み合わせただけの糞なんだけど
これをIDEとして売り物にしてるっぽい。独自開発環境なんて開発工数減らすどころか増やすだけだろ
マジあほ

388 ：デフォルトの名無しさん：2014/04/30(水) 17:48:30.62 ID:pr7iIx2Z

その手の国産オレオレフレームワークって
たいていなんかの開発案件で使われたものを
「これ、ヨコ展開して製品化しよう！」とかって
上層部が思いついて出来上がる気がする

変にオープンソースをベースにしてたりするから
無駄な初期学習コストが出ちゃうのと何かあった場合に
コミュニティが蓄積してきたノウハウが使えなかったりして困る

389 ：デフォルトの名無しさん：2014/05/04(日) 07:10:20.23 ID:q7rdqljv

JAVAをつかったWEBアプリを作りたいなとおもっています。

JAVA標準Java EE 6で、JSF2.0を使えば楽にできるものなのかなとおもっています。
ASP.NETのUIコンポーネントモデルと似ているそうです。

今のところ、JSF（Java Server Faces）の話がないのはなぜですか。
JFS 1.Xは不安定らしいが、2は良いらしい。
http://gihyo.jp/news/report/2013/09/1901?page=2

なにかアドバイスがあればください。お願いします。

390 ：デフォルトの名無しさん：2014/05/04(日) 09:48:13.90 ID:qC+tt7X6

>>389
サンプル作って比べるなり評価すればいいじゃん。
JSFについてはJSFがやらなかったか、Java EE自体はやらなかったのため。

391 ：デフォルトの名無しさん：2014/05/04(日) 09:55:34.05 ID:q7rdqljv

>JSFについてはJSFがやらなかったか、Java EE自体はやらなかったのため。

いや、このスレッドで、話が出ていないんすよ。
ctrl + f →JFS

392 ：デフォルトの名無しさん：2014/05/04(日) 13:32:46.94 ID:l8XNhl16

以前にＪＳＦの専用スレが立っていたはず。過去ログ探してみ

393 ：デフォルトの名無しさん：2014/05/04(日) 13:36:42.43 ID:l8XNhl16

あとWebProg板に関連しそうなスレが立っている。

Java EE part1
http://nozomi.2ch.net/test/read.cgi/php/1300634117/

394 ：デフォルトの名無しさん：2014/05/04(日) 13:51:40.57 ID:bN/4cHLX

JSF2.0でprimefaces使うと確かに
簡単に結構リッチな画面が作れそう

ただJSFは仕組み上
サーバリソース食うんで利用者が多いような
サイトには向かない気がする

EE6だと
JAX-RSとjavascriptか
JSF2.0で画面作るんだと思う

前者は大変だがユーザー数だとか作り込む上で制約が少ない
後者はサクッと作れるが制約が多い

といったイメージ
間違ってたらごめん

395 ：デフォルトの名無しさん：2014/05/04(日) 14:11:11.21 ID:kb+QPMa3

>>391
JSF2 は、ジェット戦闘機の時代に登場した、最強のレシプロ戦闘機っていう感じですかね。

JSF2 は、サーバ側で HTML を作る、Struts、JSF1、Tapestry、Wicket... などの旧来型の
Webアプリの集大成。
でも時代は、クライアントサイドで MVC が完結して、サーバーサイドは API に特化する
という方式に移りつつある。

移行コストが問題。従来型の Web アプリでいいなら、Servlet + JSP の延長線上にある
Spring MVC でいいかとなるし、どうせ新しいことを覚えなきゃいけないなら、
ExtJS + Rest API でやろうかねとなる。

396 ：デフォルトの名無しさん：2014/05/04(日) 14:50:26.51 ID:vh5L8gE2

JSFって、戻るボタン押したらログイン画面に飛ばされる奴？

397 ：デフォルトの名無しさん：2014/05/04(日) 15:09:02.38 ID:tBke0zkk

以前SIerで企業や官公庁向けのWebアプリ開発の仕事してて
今はコンシューマ向けWebサービスの開発してるんだけど
SIerはほんと進歩が無いんだなと感じる。
もっとも、常に「枯れた（安定してる）技術」が重要視される
業界だから、進歩させる必要はないのかもしれないけど
開発者にとってはつまらないんじゃないか。

世間では叩かれまくってるソシャゲ屋なんかは、使ってる
要素技術や仕組み的にはけっこう最先端が多い。
どんどん新しいものを取り込んで実装していく。
不安定なものもあれば、すぐに廃れていくものだったりするんで
これはこれでリスキーだけど、サービス寿命は短いから
これでもいいんだろう。

398 ：デフォルトの名無しさん：2014/05/04(日) 23:26:27.01 ID:+PT15341

>>391
JSF 21レス/396レス
だが

399 ：デフォルトの名無しさん：2014/05/05(月) 01:30:48.46 ID:wGBQOVTp

結局ここでJSFやらJavaEEもおっけーってことかな

スクリプトゴリゴリ書きたくないから
個人的にはJSF2に頑張って欲しい

400 ：デフォルトの名無しさん：2014/05/05(月) 01:34:42.59 ID:uhwl8tdd

>>397
業務アプリにとっての「技術」は目的ではなく手段に過ぎないからな
目的が達成できるならレガシーな技術で十分
先端追いかけてくれる人たちがいるお陰で、周回遅れで安定した(枯れた)技術を採用できるとも思ってる
確かに技術屋には魅力はないだろうが、そういうもんだろう

401 ：デフォルトの名無しさん：2014/05/05(月) 02:57:09.05 ID:wGBQOVTp

>>400

最新の技術に拘る訳じゃないが
新しい方が品質、生産性が高い場合もあるんじゃないかなぁ
学習コストっての問題はあるが・・・

402 ：デフォルトの名無しさん：2014/05/05(月) 03:20:29.45 ID:uhwl8tdd

>>401
あると思う。
でも数多ある新技術がすべて宣伝通りのレベルに達しているかと言うと、期待はずれの技術もまた多いわけで
その辺はイノベーターさんやアーリーアダプターさん達の成果に頼ることになる

403 ：デフォルトの名無しさん：2014/05/05(月) 10:46:41.45 ID:XYbGwOBG

JavaでいうとServlet+JSP以外信用できない
フレームワークは穴だらけ
新しいものは信用できない

404 ：デフォルトの名無しさん：2014/05/05(月) 16:22:20.74 ID:eHaIsNXX

struts普及しすぎたせいで未だにstruts使ってるところ多い感じだ
ドヤ顔で独自フレームワーク開発してますとかほざいたくせにベースにstrutsとか寝ぼけてんのかよ

405 ：デフォルトの名無しさん：2014/05/05(月) 23:41:08.23 ID:wGBQOVTp

strutsは普及しすぎたが故の脆弱性問題かね
OpenSSLといいIEといいこの手の話最近多いけど
他が安全っつうよりはマイナーなだけな感じ

ただオレオレFWが結局同じ問題を抱えてて
各々対処しないといかんのはダサいね

じゃあjavaEEなのかと言うとよくわからない
標準といえど旧EJBのような失敗作もあるし

406 ：デフォルトの名無しさん：2014/05/05(月) 23:55:41.61 ID:qgaxSqth

フレームワークは使ってるってだけでドヤ顔できるかな

407 ：デフォルトの名無しさん：2014/05/06(火) 00:36:47.39 ID:/KCtgeyk

>>400
日本で業務系アプリやってる奴らは
周回遅れどころか10年以上遅れてるだろう
リリース後に1年もたてば十分に安定した技術になる。

ただ時代遅れで新しい技術についていけていないだけなのに
「枯れている」などという言葉で正当化しようとする

フレームワークの有り無しを論じていたり、Strutsがどうこうとか
日本だけ時間が15年くらい止まっている感じだな

408 ：デフォルトの名無しさん：2014/05/06(火) 01:51:30.39 ID:HbPu7+SF

>>407
どうした？業務アプリに親でも殺されたのか？

409 ：デフォルトの名無しさん：2014/05/06(火) 10:04:43.41 ID:p+pOalwe

企業の場合、フレームワークにノウハウを詰め込んでる場合が多いから、土台が古くなってもなかなか変えられない。
下手に変えるとエラい目に会うからな。

410 ：デフォルトの名無しさん：2014/05/06(火) 10:11:07.39 ID:mq0PWr6n

＞strutsは普及しすぎたが故の脆弱性問題かね
JSP系統全体の脆弱性じゃないの

Velocityとかで同じようなことは大丈夫なのかな

411 ：デフォルトの名無しさん：2014/05/06(火) 12:34:59.61 ID:ifeVOml8

OGNLとかBeanUtilsとか個別の要素のバグや仕様だから同じことしてたら問題はある

412 ：デフォルトの名無しさん：2014/05/06(火) 15:00:56.09 ID:q8o8j/Sw

欧米だと、業務系アプリでもどんどん新しい技術採用してるのにな
バックエンドはSpring+MySQLやnode.js+MariaDB、フロントはHTML5ベースで
backbone.jsやAngularJSにしてREST-APIで繋ぎ、サブシステム連携も充分とかさ

413 ：デフォルトの名無しさん：2014/05/08(木) 20:14:41.32 ID:QhqRiqXw

>>393
プログラムとWebプログラミングとで板が分かれていたの知りませんでした。

>>394
JSF2.0は、MSのASP.NETみたいにできるそうです。
でも、MSはサービス運用でライセンスにお金が絡んで自由に使えないのでそんな技術は使いたくありません。
未来に自由をもたらすために、javaで行きます。

LAN内向けサービスなら使えそうですね。
リソースの問題も、今後JSFのバージョンがあがっていくにつれて改善されることを期待します。

>>395 >>399
>JSF2 は、... などの旧来型のWebアプリの集大成
今やJDKの標準技術になっているんですよね。

>JSF2に頑張って欲しい
同感です。

>クライアントサイドで MVC が完結して、サーバーサイドは API に特化するという方式に移りつつある。
余計に処理の流れが複雑になりそう・・
サーバの負担は軽くなりそうですね。

JFS2.0の書籍を大型の本屋に探しに行きましたが、一冊だけでした。
掌田津耶乃「EclipseではじめるJavaフレームワーク入門　第4版」が
JFS2.0を使ったプログラム例と詳細な解説が載ってました。

これ以外に、どうして売っていないのか不思議です。　（JFS2.0は、JDKの標準技術なのに。）
オイラリーのは、JSF1.0を対象に書かれていたので、対象外です。2004年初版でした。

414 ：デフォルトの名無しさん：2014/05/08(木) 21:30:25.66 ID:+3i6oIvP

asp.netもasp.net MVCっていうサーブレットチックなものが主流になってる。

asp.netもjsfも柔軟性にかける割に生産性もそこまで高くないんだよね

415 ：デフォルトの名無しさん：2014/05/08(木) 22:39:57.36 ID:2SfqCKIX

生産性が低いとは思わないけど、まあ、ぎょーむ屋さんがつまんねーLOBアプリをシコシコ作るの専用感はある。

416 ：デフォルトの名無しさん：2014/05/09(金) 04:23:02.68 ID:q6CZdclC

Struts2+Spring DIでStruts2のActionにDIするWebアプリケーションを作ってる。
このアプリの実行時に、DIされるべきフィールドがnullになっててヌルポが発生することがある。
アプリをコンパイルしなおしたらヌルポが発生する場所が毎回変わったりするので原因がよく
わからない。

Tomcatが利用できるメモリ容量を増やしたらヌルポが発生しなかったので、DIに必要な
メモリが足りないのが原因かと思ったんだが、そういうことってありうるのかしら？
みんなTomcatのメモリ容量はどのぐらいにしてる？

417 ：デフォルトの名無しさん：2014/05/09(金) 04:36:52.76 ID:zfIj6OAD

>>414
asp.net MVCがサーブレットと同類のわけないだろ
お決まりの処理は最小限のコードで書ける
ASP.net MVCの生産性の方が圧倒的に上

>>413
掌田津耶乃の本はやめておけ
いろんな言語のフレームワークの本を書いているがどれも評価低い
内容が薄っぺらい、同著者のamazon レビューを見たほうがいい

＞これ以外に、どうして売っていないのか不思議です。

理由はJavaの技術は定番がなく分散してるから
膨大な時間をかけて本を書いても売れない、儲からない
日本語で書いたら日本人しか買わない
どうしても本で学びたければ英語で書かれたものを探したほうがいい

418 ：デフォルトの名無しさん：2014/05/09(金) 04:41:29.70 ID:zfIj6OAD

>>416
いまさらStrutsとは

ヌルポにメモリが関係あるわけないだろ
物理メモリが足りなければ、HDD/SSDなどの仮想メモリが使われる

419 ：デフォルトの名無しさん：2014/05/09(金) 05:03:29.99 ID:q6CZdclC

>>418
うん、おれもStruts使いたくない。

やっぱ関係ないか。再現条件（ヌルポの発生場所）がころころ変わるんで悩んでる。
DIされるべきところがnullになるケースってなんかない？

420 ：デフォルトの名無しさん：2014/05/09(金) 08:34:54.37 ID:EM0RixeL

Spring使ってるのになぜStruts?しかも2とかありえねぇ。
馬鹿なの？アホなの？死ぬの？

SpringMVC使えよ。

421 ：デフォルトの名無しさん：2014/05/09(金) 08:58:40.41 ID:E3wsUlgH

決定権無ければそれでやるしかないよね

422 ：デフォルトの名無しさん：2014/05/09(金) 15:31:47.07 ID:dvOOVkmX

決定権がある人間が無能だと
こうやって現場が疲弊する見本だな

中途半端に要素技術を聞きかじってると
こうなるよな

423 ：デフォルトの名無しさん：2014/05/09(金) 16:52:51.17 ID:vziOY5Cd

>>419 OutOfMemoryErrorをどっかで揉み消してるとか
>>418 PermGen上限を緩めてないなんてのはありがち

424 ：デフォルトの名無しさん：2014/05/10(土) 09:12:05.20 ID:1Do2eZKO

>>420-422
お察しのとおり、途中から参加したプロジェクトなんで変えようがない。
Spring使うならSpringMVC使え、はもっともなんだろね。

>>423
MaxPermSizeを大きくするとヌルポが起きないので、そこかなーと思ってる。
OutOfMemoryErrorのもみ消しはしてないと思う。

425 ：デフォルトの名無しさん：2014/05/10(土) 11:23:10.80 ID:gSo5tcfL

やっぱTomcat使ってるとこ多いよね

javaEE にするならTomEEでいいかな？

426 ：デフォルトの名無しさん：2014/05/10(土) 11:50:16.02 ID:ZoW/vxHI

Tomcatで十分だろ。意味わからん
オレオレアーキテクトのオレオレフレームとオレオレコンテナとか誰得だよ

427 ：デフォルトの名無しさん：2014/05/10(土) 12:57:17.13 ID:2YlfM5m7

趣味ならなんでもおｋ

428 ：デフォルトの名無しさん：2014/05/10(土) 13:05:01.57 ID:++ojgnt3

将来が有望なWEBアプリのフレームワークって？

JFS2を推したいのだが・・・

他の技術では、HTMLを噛むのでコードが煩雑になりはしないかと躊躇する

429 ：デフォルトの名無しさん：2014/05/10(土) 16:08:55.06 ID:ReRBG8qB

HTMLをサーバ側で作ってレスポンスに送り出すのか
サーバからは必要な情報だけJSONとかで取得して
ブラウザ側でDOM生成するかで何を使うかが変わってくるな

HTML自体の修正が必要な場合は、個人的好みとしては
後者のほうが修正から反映までの手間が少なくて好きだ。
サーバ側でやると、サーバ側もデプロイしなおしとかあるし

430 ：デフォルトの名無しさん：2014/05/10(土) 16:18:20.94 ID:lrUbXucJ

最近は後者な流れじゃない？

431 ：デフォルトの名無しさん：2014/05/10(土) 16:19:03.56 ID:6O8ipEn6

こいつ一昔前までseasar2押してたタイプだ

432 ：デフォルトの名無しさん：2014/05/11(日) 15:40:23.86 ID:CQcMSGFV

>>429
>ブラウザ側でDOM生成する

せっかく、ASP.NETは、サーバー側で要求を受け付けて処理してHTMLを出力するうまい方法（抽象化されたサーバコントロール）を、
実現していたのに（JFS2みたいに）、今からはブラウザ側がHTMLを自分で作成するのですか。

ブラウザ側でHTMLをコントロールするタイプなら、
何が推しですか？

そういうタイプWEBアプリって、サーバーは基本的なプログラムとデータをクライアントに提供して、
クライアントがその基本的なプログラムを処理することで適切なHTMLを自分で組み立てる感じでしょうか。

433 ：デフォルトの名無しさん：2014/05/11(日) 15:55:27.33 ID:moCMHB5P

>>432
ブラウザ側でいろいろやるのは別に良い方法というわけじゃないよ

ただJavaの世界ではサーバサイドのフレームワークが
ろくでもないものばかりだから、そういう開発をやる人が出てきただけ

ASP.netやASP.net MVCに比べると開発に時間もかかるし
ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
セキュリティも低下する

434 ：デフォルトの名無しさん：2014/05/11(日) 20:28:02.82 ID:UwOOPA9c

>ASP.netやASP.net MVCに比べると開発に時間もかかるし
>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する

いまどきの大手SIerって、こういう時代遅れタイプで占められてるんだよな
だからStruts1が幅を効かせてきたわけだ

435 ：デフォルトの名無しさん：2014/05/12(月) 00:07:44.85 ID:wroz7708

>>433
>ただJavaの世界ではサーバサイドのフレームワークがろくでもないものばかりだから
>（ブラウザ側でいろいろやる）そういう開発をやる人が出てきただけ

結局は、消極的な理由なんですか。

近年のクライアントのパワーが上がってきたことと、
サーバーの負担を減らすために、クライアントサイドでhtml構成作業を行うようになったのだと思っていた。
あと、ポストバックをなくすために。

>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する

ブラウザ環境で意図した動作をしないというのは困りものだな。

うーむ。
だったら、サーバーサイドのフレームワークとして、JFS2.xに期待するなあ。
なんだって、JDKの標準機能に組み入れられたのでしょ。
JFS2には将来性があると思う。

436 ：デフォルトの名無しさん：2014/05/12(月) 00:09:39.92 ID:wroz7708

>>417
>理由はJavaの技術は定番がなく分散してるから
>膨大な時間をかけて本を書いても売れない、儲からない
>どうしても本で学びたければ英語で書かれたものを探したほうがいい

JAVAって、いろいろ分散していて、いったい何が標準なのかぜんぜんわからないですものね。
JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
今後は、日本語で書かれた書籍も増えてくるかもしれないですね。

ほんと、期待しています。

ASP.NETはいいんだけど、運用保守にお金がお金がかかるかかる。ライセンス問題が非常にやっかい。
MSのご機嫌取りしなきゃいけなくなる。アプリの運用を人質にされて、MSに振り回されるのは勘弁。
なので、ASP.NETは将来を見越したら、取り組みたくないんだなあ。

437 ：デフォルトの名無しさん：2014/05/12(月) 00:23:29.96 ID:f+OP7VZY

>>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。

一応、そのあたりの差異を吸収することも目的の一部に含むのが
jQueryのようなJSのフレームワークなわけで
サーバーサイドの人間は何かというとJSを目の敵にするけど
どちらも使えたほうが、この先業界内で生き残っていける確率は上がるでしょ

企業的には「フルスタックエンジニア」なんて名前の便利屋や何でも屋を
求めるようになってきてるし。

438 ：デフォルトの名無しさん：2014/05/12(月) 00:40:16.62 ID:h1G1q1Ck

どうでもいいが「JFS」じゃなくて「JSF」な
JavaServer Faces（JavaとServerの間は空けないのがお約束）

439 ：デフォルトの名無しさん：2014/05/12(月) 00:42:07.47 ID:wroz7708

>フルスタックエンジニア

それでも、htmlやJAVA SCRIPTを触らなくても良い、高度に抽象化された一元的プログラミングをしたい・・・

440 ：デフォルトの名無しさん：2014/05/12(月) 00:43:03.15 ID:wroz7708

>>438
ありがとう

441 ：デフォルトの名無しさん：2014/05/12(月) 01:00:32.81 ID:KacrXp1d

>>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。
というかバージョン変わったりブラウザが変わったりすると動作しなくなる可能性があるのはJAVAでも同じことだと思うけど違うの？

442 ：デフォルトの名無しさん：2014/05/12(月) 01:14:18.80 ID:/hsNV+iO

>>441
Webアプリでクライアント側のJREは使わないでしょ
サーバサイドでJavaだから、サーバ側のアップグレードしなければ
バージョンアップのエラーは出ない

ブラウザ側でJSを多用するWebアプリは、ユーザのブラウザの種類や
バージョンに依存するようになってしまう

これはJSじゃなくてHTML/CSSの互換性の話だけど
XP時代にIE6用に設計した業務システムを作ってしまい、
悲惨な目にあった企業はたくさんあるのは有名な話。
OSのアップグレードやPCのリプレースもできなくなった。

クライアントブラウザの指定がしやすい業務システムであっても
なるべくサーバサイドでやるほうがあとあと問題は出にくいと思うよ

443 ：デフォルトの名無しさん：2014/05/12(月) 01:20:14.46 ID:/hsNV+iO

>>442補足しておくと
ブラウザバージョンアップでレイアウトの崩れ程度は起こる可能性は
どの技術でもありうるけど、ブラウザ側でJSを使わなければ
エラー吐くような事態にはならないから新バージョンへの対応もしやすいということ

DartはもうIE9のサポートを打ち切ったらしい
ブラウザのバージョンアップですぐに動かなくなるようではだめだ
DartはJavaScriptに変換する言語ね

444 ：デフォルトの名無しさん：2014/05/12(月) 01:27:57.76 ID:KacrXp1d

>>442
ちょっとよく分からない。
サーバーサイドですべて出力するにしろ、ブラウザで動作するものを作るわけだよね？
JREで動作させるものじゃないとすると、結果はHTML出力とかになると思う。
だったらブラウザが新しくなったら動作しなくなるとかあるんじゃないの？

445 ：444：2014/05/12(月) 01:30:28.95 ID:KacrXp1d

>>443
見てなかった済まない。
しかし昔の業務用アプリならともかく、最近のものでJavascriptを一切使わないってありえないと思うんだけどな。

446 ：デフォルトの名無しさん：2014/05/12(月) 01:41:02.37 ID:h1G1q1Ck

>>445
このスレは昔ながらの業務アプリしか作らなくて済んでる化石のようなエンジニアの巣窟なの

447 ：>>53：2014/05/12(月) 01:47:49.33 ID:iJz1i67B

サーバー側で要求を受け付けて処理してHTMLを出力する方式は
wicketでもjsfでもセッション多用でレプリケーションの同期が多発
Playがセッション使わせたくないのもこの辺が原因でしょ

448 ：デフォルトの名無しさん：2014/05/12(月) 02:04:03.42 ID:/hsNV+iO

>>445
一切使わないなんて言ってないんだけどな
>>442でも「なるべくサーバサイドでやる」とはそういう意味だ

>>446
業務アプリでJSが必須の機能少ないけどな
どういう機能か言ってみなよ

ユーザデータチェックのValidationではJS使うけど
業務アプリでJSでしか実現できない機能を求められることは少ない

449 ：デフォルトの名無しさん：2014/05/12(月) 03:22:01.12 ID:KacrXp1d

>>448
いやまあそれ言っちゃうとJSのほうだってなるべくHTMLは書くようになると思うよ。
JSが受け持つ範囲は多くなるけど。
全てのデザインをJSで組むっていうのはまずありえないかなと。HTMLで書くほうが早いし簡単だし。

あと>>446への返信に横入り。
「業務アプリ」で「最低限の機能」しか求められることが少ないって書いてあるけど、それって反論じゃなくて、
書いていることに対して認めているように見えるけど良いの？

450 ：デフォルトの名無しさん：2014/05/12(月) 10:18:24.45 ID:NL4i9DSa

そもそも業務アプリなんかWebでやりたくねぇわ

451 ：デフォルトの名無しさん：2014/05/12(月) 10:37:30.53 ID:GdHpjeGh

>>436

> JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
> 今後は、日本語で書かれた書籍も増えてくるかもしれないですね。
>
> ほんと、期待しています。

JSFが何年も前の1のころからJ2EE (いまで言うJavaEE)の標準になっていたが、結局流行らなかった。

流行るものは、結局標準化どうかではなく、そのプロダクトが使いやすいか(いいものか)どうかなんだよ。

452 ：デフォルトの名無しさん：2014/05/12(月) 12:03:24.64 ID:3xPUgV6E

標準だとしてもOracleだぜ？
何だかんだ言ってもMSの方がマシだろ

453 ：デフォルトの名無しさん：2014/05/12(月) 17:15:35.33 ID:YqgznOAd

すれち

454 ：デフォルトの名無しさん：2014/05/13(火) 22:10:38.32 ID:QItZX2Cn

酷い製造現場に入っちまったわ
少なくとも6年以上は前のフレームワークを使って色々やってるんだが
雛型作り上げるまでのプロセスがむちゃくちゃ

455 ：デフォルトの名無しさん：2014/05/14(水) 02:03:31.02 ID:B2iG6znP

6年前って2008年か… マシな方じゃね？
10年前のJ2EEで止まってる方が酷いと思うわ

456 ：デフォルトの名無しさん：2014/05/17(土) 00:35:29.68 ID:PXPFtWqe

技術の蓄積が云々でStruts1

457 ：デフォルトの名無しさん：2014/05/17(土) 02:08:09.45 ID:C6+8ucAK

Struts1内臓の自社製フレームワークだ

458 ：デフォルトの名無しさん：2014/05/24(土) 10:45:14.85 ID:zWM8Vigu

http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-for-2014/9/

459 ：デフォルトの名無しさん：2014/05/24(土) 18:26:53.21 ID:qfxUsSTH

GWTとかVaadinって意外と使われているのね
Vaadinはそのうち開発頓挫しそうな空気だけど

460 ：デフォルトの名無しさん：2014/05/25(日) 20:03:15.10 ID:gGsDT7q8

結論：Flexでおｋ

461 ：デフォルトの名無しさん：2014/05/28(水) 00:27:43.53 ID:9OS265q7

GWTが流行るか、javascriptがdartに進化するべきだった
半端なJSフレームワーク乱立とか糞すぎる

462 ：デフォルトの名無しさん：2014/05/28(水) 03:27:10.38 ID:1YkJU2y3

なんかもう

フロントコントローラ　：　Jersey + 好みのDIコンテナ
テンプレートエンジン　：　お好み（Thymeleafがよさげ）
DB　：　スクラッチ、ヘルパーライブラリ、ORMお好み
フロントエンド　：　軽量のMVCFWお好みで

こんな感じでいいような気がしてきた（想像）
上手く設計できれば結構いい感じにできそう（想像）

今はWebはPythonとかLL中心でアプリはAndroidやってるからJava資産活用できるしWebもJavaでやりたいって
上に言ってはいるけどなかなか通らない。

463 ：デフォルトの名無しさん：2014/05/28(水) 06:46:29.77 ID:sLOdIin8

ウチはWebはJavaかASP.NETでしかやらせてくれない
物凄く簡単なのでもJava

めんどくさい

464 ：デフォルトの名無しさん：2014/05/29(木) 10:16:48.53 ID:bCwfT6SY

>>461
その通りなんだけど、世の中全体としては、
もっと JSフレームワークが乱立して、みんなで右往左往する流れになってるからな・・・
30代後半になったけど、JSの流れにはついて行けなくなった。

jquery を覚えるだけでも精一杯（管理職業務も増えてきてなかなか開発できなくなったってのもあるけど）

465 ：デフォルトの名無しさん：2014/06/08(日) 08:55:00.28 ID:muM/tUAt

結局新しいものは流行らずにStruts1.x & JQueryなんか？ｗ

466 ：デフォルトの名無しさん：2014/06/08(日) 13:24:09.91 ID:IMqXIRgz

大手SIerだったら、Struts1.xメインで
jQueryは使ってもほんの一部の機能だけだな

467 ：デフォルトの名無しさん：2014/06/08(日) 15:38:05.52 ID:2wWwIno8

>>466
そういうとこは、ユーザの操作に対してDOM書き換えは使わずにページ遷移で応答する感じなの？
もしくはJavaScript直書きのコードでDOM書き換えする？

468 ：デフォルトの名無しさん：2014/06/08(日) 20:08:38.84 ID:9DHwTaw1

>>467
業務アプリだとDOM書き換えはほとんど使わない。

469 ：デフォルトの名無しさん：2014/06/08(日) 21:09:27.40 ID:IMqXIRgz

だな。
業務アプリだと、UI/UXなんていう部分に意識も無ければ関係もない世界だし。
使い勝手が良かろうが悪かろうが、要件定義書に羅列されたものを
いかに満たしているかどうかがポイント。

そんなことやってるから、SIerは死んだって言われてるわけだけど
別に死んでるわけじゃなくて、そもそものビジネスモデルが違うんだよね
まぁこれからどんどん衰退はしていくだろうけど。

470 ：デフォルトの名無しさん：2014/06/08(日) 21:40:50.67 ID:GhJMx+U1

> 業務アプリだと、UI/UXなんていう部分に意識も無ければ関係もない世界だし。

全くそのとおりなんだけど、そんなんでユーザ企業の生産性はどうなってるんだっていうね・・・
SIerだけじゃなく日本の産業全体が衰退するだろこれ

471 ：デフォルトの名無しさん：2014/06/08(日) 22:35:46.56 ID:9o67lThF

業務アプリは工数の制約が大きいから仕方ないじゃん

472 ：デフォルトの名無しさん：2014/06/08(日) 23:57:57.03 ID:IMqXIRgz

SIerはユーザー企業の生産性なんか気にしたこと無いよ
ただでさえユーザー企業からコスト削減を言われるんだから
確定した要件を決められた予算以下でいかに抑えて利益出すかが
最大の目的であって、使い勝手なんか知ったこっちゃない

473 ：デフォルトの名無しさん：2014/06/09(月) 00:00:42.59 ID:86AcLmQh

パッケージなんて入れても魔改造で原型を留めていない
そもそも客自体が抜本的に業務を改善する気があまり無い
そんなユーザ企業ばかりだろ
UI/UXとか高尚な話以前の問題だと思うがな

474 ：デフォルトの名無しさん：2014/06/09(月) 03:22:14.41 ID:ruWyYOGX

そんな構造に嫌気が差してSIerから足洗った

こんな環境にずっといたらもうその会社でしか使えない人材になってしまう。

業務でそこそこ新しい技術を使えてそんなに忙しくないし給料も高い民間（）の会社の方が楽しい

475 ：デフォルトの名無しさん：2014/06/09(月) 16:50:04.57 ID:7Qzyu762

ユーザの生産性を最大限に上げたいなら、クライアントがブラウザとかそもそもありえないからｗ

476 ：デフォルトの名無しさん：2014/06/09(月) 17:04:36.04 ID:WQD38f8Z

システム部門の生産性が最大になる

477 ：デフォルトの名無しさん：2014/06/09(月) 17:08:43.74 ID:HqQRpaLI

まぁEnterprise 2.0 じゃないけど、業務系でも、かんたんな ajax みたいなのは
少しずつ取り入れられてくると思うけどね。

VBの時代に、コード値の入力補助みたいな感じで、
コード値のテキストボックスからフォーカスを外すと、その右側の ReadOnly なフィールドに名称が表示される、とかやったけど
(勘定科目のコードを入力すると、その横に名称が出る、とか)
webでも似たようなことやった。テキストボックスにコードを入れて onchange() で、そのよこの <div> を更新とか。

あと、めちゃくちゃ工数がかかったけど、Excelのグリッドをブラウザでやったり。

478 ：デフォルトの名無しさん：2014/06/09(月) 21:18:06.29 ID:+BBgcboW

日本のシステム屋ってパッケージ作って売っていこうっていう風潮にはならないよね。

客はパッケージに運用を合わせる気はないし、
現場SEはバッケージ無視で要件聞いて作り直しが当たり前だし、
営業はそれでもパッケージ適用だと言い張って客から十分な費用取ってこないし、
パッケージ作ってる側もコンセプトがないかブレブレで大幅に手を入れないと売れないものしか作らないし

479 ：デフォルトの名無しさん：2014/06/09(月) 22:32:21.23 ID:86AcLmQh

>>477
あーExcelのグリッドみたいなのはやったことあるな
二度とやりたくない

480 ：デフォルトの名無しさん：2014/06/10(火) 05:51:12.75 ID:ktfRooiL

リッチなビジネスロジックをアジャイルに注入する～♪
馬鹿な用語や言葉遊び多いよね。作るものは結局帳簿だしｗ

481 ：デフォルトの名無しさん：2014/06/10(火) 08:23:28.89 ID:tVDmQHlD

システム化するほとんどの業務はExcelで回せる程度の話

482 ：デフォルトの名無しさん：2014/06/14(土) 06:03:43.72 ID:BupVVlcz

エンタープライズ・アップリケーション（Excel）

483 ：デフォルトの名無しさん：2014/06/14(土) 22:44:17.40 ID:BupVVlcz

ビジネスロジック注入！

484 ：デフォルトの名無しさん：2014/06/16(月) 01:04:21.90 ID:2d0xyXjF

喰らえ！ディペンデンシー・インジェクショオオオォォオォォォン！！！！！

485 ：デフォルトの名無しさん：2014/06/16(月) 18:44:58.88 ID:AxBJea7v

はぁ・・・ほとんどのメインクラスが1万行越える糞ソース見てると目がおかしくなる
技術的な糧にもならんしホント終わってるプロジェクトだわ

486 ：デフォルトの名無しさん：2014/06/16(月) 18:56:58.05 ID:AxBJea7v

あと話を最後まで聞かないですぐ早とちり返答するプロパーにイラッとする

487 ：デフォルトの名無しさん：2014/06/16(月) 22:43:14.49 ID:0QAWs/6q

＞メインクラスが1万行越える糞ソース
誰が書くんだろう

「プログラミングなんか重要じゃない」とか逝ってそうな、そいつの顔が浮かぶけど

488 ：デフォルトの名無しさん：2014/06/17(火) 09:43:15.84 ID:wq60xqCI

お客様には最適なソリューションを注入させていただきます♪

489 ：デフォルトの名無しさん：2014/06/17(火) 10:58:44.64 ID:AlynCjr8

>>486
「プロパー」という変な和製英語つかってるバカみるとイラッとする

490 ：デフォルトの名無しさん：2014/06/17(火) 11:24:22.15 ID:DTyoNsq+

>>486がどういう意味で使ってるかよくわからないけどproperとはちがうん？

491 ：デフォルトの名無しさん：2014/06/17(火) 13:13:06.34 ID:AlynCjr8

和製英語って書いたから誤解されたみたいだな
日本ではそのproperという単語の使い方がおかしいってこと

properは形容詞だし、正社員という意味合いはどこにもない

492 ：デフォルトの名無しさん：2014/06/17(火) 13:28:57.17 ID:0wNIkktH

プロパーは日本語

493 ：デフォルトの名無しさん：2014/06/17(火) 15:05:45.45 ID:1K9Dgk3r

>>491
通じるからいいじゃん。美しい日本語を守る会から来たの？

494 ：デフォルトの名無しさん：2014/06/17(火) 15:20:15.40 ID:AlynCjr8

>>493
その団体は知らない

「私は基本的な英単語もわからない馬鹿です」と宣言するような
「プロパー」なんて言葉を使う必要はないだろう
プログラミングをするならもっと言語の使い方に気を配るべきだと思うわ

495 ：デフォルトの名無しさん：2014/06/17(火) 15:48:39.10 ID:1K9Dgk3r

プロパーだけで正社員を意味してるわけじゃないからｗプロパー社員の略だからｗ

496 ：デフォルトの名無しさん：2014/06/17(火) 16:15:48.62 ID:91YaR+D7

のようだ
ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1026097815

497 ：デフォルトの名無しさん：2014/06/17(火) 17:17:56.95 ID:AlynCjr8

>>495
英語の基礎も知らない低学歴か

「プロパー社員」と形容詞的にproperを使っても
意味がおかしいのは変わらない
辞書でproperの意味を調べてみろ

498 ：デフォルトの名無しさん：2014/06/17(火) 17:58:42.36 ID:1K9Dgk3r

>>497
知らねえよｗ
proper employeeとか言い出した外人に文句言ってこいｗ

499 ：デフォルトの名無しさん：2014/06/17(火) 19:22:19.70 ID:L+TJtcii

パッパラパーはもういいよ

500 ：デフォルトの名無しさん：2014/06/17(火) 23:51:33.26 ID:2RHT1WPi

あれか、ミシンとかホチキスとかキャタピラに文句言うタイプかｗｗｗ

501 ：デフォルトの名無しさん：2014/06/18(水) 00:13:26.13 ID:1CnfDjxn

DBでEAVパターン避けてDDLでテーブル作成ので何か良いORMはないかい？
JPAとJDBC両刀も考えたがソリューションは統一したいんだよな

502 ：デフォルトの名無しさん：2014/06/18(水) 13:21:13.43 ID:wp/txwFE

Struts2のタグを勉強したいんですが
良いサイトないでしょうか？

503 ：デフォルトの名無しさん：2014/06/18(水) 13:29:37.73 ID:LGYjzaR6

proper は、「(世間の常識に照らして)正しい、適切な」
「世間で認められた」
a proper job は、まともな仕事

properly は、「きちんと」
work properly は、正しく作動する

a temporary worker は、派遣社員(一時的な労働者)
a temporary job は、臨時の仕事
a permanent job は、定職(永久の仕事)

temporarily は、一時的に

504 ：デフォルトの名無しさん：2014/06/19(木) 01:51:33.12 ID:Q9g69noQ

ここって「Java Web Application Framework」スレですよね？よね？よね？

505 ：デフォルトの名無しさん：2014/06/19(木) 02:18:02.53 ID:UkjtGgcQ

O/Rマッパー、なに使ってる？

506 ：デフォルトの名無しさん：2014/06/19(木) 12:41:30.91 ID:0NTPrLmU

Struts2勉強中なんですが
<s:textfield>
とか使うと勝手にid属性が出力されてしまうんですが
これを止めることってできないでしょうか？

507 ：デフォルトの名無しさん：2014/06/19(木) 12:41:33.62 ID:jrCofeDy

何も使ってない。Eager or Lazyはもううんざり

508 ：デフォルトの名無しさん：2014/06/19(木) 15:08:31.72 ID:Q9g69noQ

>>505
人によってORMの定義が違うんだよな
・広義のORM: JavaBeans/MapとStatement/ResultSetをマッピングする (MyBatisもORMだよ派)
・狭義のORM: オブジェクトモデルとリレーショナルモデルをマッピングする (MyBatisはORMじゃないよ派)
あるいは
・ORMでも操作対象はRDBだからSQL当然 (MyBatisもORMだよ派)
・ORMでは操作対象はオブジェクトだからSQL不要 (MyBatisはORMじゃないよ派)

推測だが>>505は前者、>>507は後者ですでに食い違ってると見た

509 ：デフォルトの名無しさん：2014/06/19(木) 18:59:19.27 ID:tbGY3C27

Struts2勉強中って死んだフレームワーク勉強しても時間の無駄だろ

510 ：デフォルトの名無しさん：2014/06/19(木) 19:35:24.55 ID:jrCofeDy

JPA/Hibernate系列はフレームワーク
DBUtilsやMyBatisはライブラリだな

前者のくそったれにデータベース乗っ取られると制御不能
（実際には抜け道はあるが、そんなことになるなら始めから使うべきではない）

511 ：デフォルトの名無しさん：2014/06/19(木) 20:21:58.56 ID:Sp1pHGUF

>>509
どこかの馬鹿が採用してそれの面倒見る事になったんだろ…

512 ：デフォルトの名無しさん：2014/06/20(金) 05:46:33.66 ID:krrNrToX

JPAの控えめなバージョンって事で、Ebeanがいいと思う。

513 ：デフォルトの名無しさん：2014/06/23(月) 21:25:21.25 ID:Scct09E3

ビーンがびんびんですっ

514 ：デフォルトの名無しさん：2014/07/09(水) 15:12:19.99 ID:6LMuMalC

struts1.x脆弱性問題の後どうなってる？
まさか新規プロジェクトで採用とかないよね

515 ：デフォルトの名無しさん：2014/07/09(水) 18:20:06.73 ID:8Ks7XEl3

フィルターやbeanutilの修正で対処できるからまだまだstruts1採用

516 ：デフォルトの名無しさん：2014/07/10(木) 21:08:58.55 ID:GIbup2ZZ

struts1って何ゆえ使われるんだろう
バリデーション関連かな

517 ：デフォルトの名無しさん：2014/07/10(木) 21:20:47.17 ID:Xy16njT3

JSF2.2はステートレスなJSFにできるんだろ
Strutsの出る幕ないな

518 ：デフォルトの名無しさん：2014/07/10(木) 22:56:30.84 ID:yls+QHLE

>>516
過去の実績の一点に尽きるのではｗ

519 ：デフォルトの名無しさん：2014/07/10(木) 23:06:50.75 ID:CuKrbI8x

実績あるから何も知らんジジイが押すし
それしかできないやろうとしない人間も多いし

520 ：デフォルトの名無しさん：2014/07/10(木) 23:45:20.75 ID:dGZG7KxU

Struts 1を重用するような層って、もしこれが無かったら
Servlet API直叩きの自家製フレームワークに逝ってるぜ。多分。

521 ：デフォルトの名無しさん：2014/07/11(金) 01:35:50.10 ID:nlFDpd8I

Servlet API直叩きの自家製フレームワークの方が断然よくね？

522 ：デフォルトの名無しさん：2014/07/14(月) 00:02:06.90 ID:OcSExS2c

新規案件、別に経験者いるわけでもないのにStruts2でやることになった…
Springとかやってみたかったなあ

523 ：デフォルトの名無しさん：2014/07/14(月) 02:50:20.64 ID:FEwHED4y

おまいら今新規でWebアプリ作るとしたら何使う？
Playでやりたいと言ったら
お前以外にScala分かる奴いないからダメとか言われたわ

524 ：デフォルトの名無しさん：2014/07/14(月) 06:34:06.69 ID:3EOL/haS

>>522
ナイスID

525 ：デフォルトの名無しさん：2014/07/14(月) 11:40:14.51 ID:dqknatng

>>523
Liftみたいに凝ったことするわけじゃないんで、
scalaっぽく書かないでjavaの延長で十分ですよとでも言いくるめれば？

それはそうと、Grailsの選択肢はないの？

526 ：デフォルトの名無しさん：2014/07/14(月) 13:57:22.20 ID:gu4/WTCd

>>523
ASP.net(MVC)かPythonだろう

527 ：デフォルトの名無しさん：2014/07/14(月) 21:43:00.32 ID:1seA8AHy

DIはSpring、VIEWはJSFのオレオレフレームワーク

528 ：デフォルトの名無しさん：2014/07/14(月) 22:56:02.16 ID:FEwHED4y

>>525
その理由で押し通してきたわ
Grailsは仕事どころか趣味ですら触った事ある奴ゼロなんや

>>526
このスレで聞いてるのだからJavaで頼みますよ…

529 ：デフォルトの名無しさん：2014/07/14(月) 23:12:26.56 ID:ziI78KtJ

もうjavaはオワコンなんだろうか？
サーバーと開発環境のコストぐらいしかc#に勝ち目ないよね。

530 ：デフォルトの名無しさん：2014/07/14(月) 23:32:50.43 ID:0Fs03oG9

Java8とSpringBootでいろいろ楽できそう

531 ：デフォルトの名無しさん：2014/07/14(月) 23:39:43.23 ID:A/Crvp6b

C#つうか.NETはWindowsでの運用を嫌がるところでは候補にも入らない
monoって言うのは禁止

532 ：デフォルトの名無しさん：2014/07/15(火) 01:56:37.33 ID:Nil0H2CV

Windowsを嫌がる客には当たった事ないな
Linux分からないからWindowsにしてくれと言われるぐらい

533 ：デフォルトの名無しさん：2014/07/15(火) 02:29:22.20 ID:0ukaJOqr

そういう客でJava案件あるのが意外
素直に.NET使わないんだ？

534 ：デフォルトの名無しさん：2014/07/15(火) 19:43:35.53 ID:xhqAc3/s

grailsとplay frameworkの両方とも試験採用してみたけど、playの方が好評だったよ。
grailsは細々と変なとこでつまづくから、もうヤダって意見が多かった。

535 ：デフォルトの名無しさん：2014/07/15(火) 20:35:23.52 ID:XdDSHvfr

>>534
scala?

536 ：デフォルトの名無しさん：2014/07/16(水) 18:17:51.86 ID:vXm3Ifxd

>>535
playはJavaで。
playのデフォルトテンプレート言語は、賛否両論だったが。

537 ：デフォルトの名無しさん：2014/07/16(水) 18:53:38.37 ID:pgX414rr

マルチ環境向けのテンプレートだとMustacheとかあるな
JavaScriptにも対応してるから資産管理の点で目を付けてるが使ってる奴居る？

538 ：デフォルトの名無しさん：2014/07/18(金) 22:38:55.29 ID:Ouyc3HJ6

>>244
hotdeployはバグってねえよ
ただ、クラスローダのこと良くわかってない奴が適当に作って、パーマネント領域食いつぶしたり、クラスキャスト例外起こしてしまって機能してしないってのはある。

539 ：デフォルトの名無しさん：2014/07/18(金) 23:46:28.85 ID:ebrrZgfr

問題ひきおこしてサクサク開発♪

540 ：デフォルトの名無しさん：2014/08/06(水) 01:06:07.39 ID:RlrGvYbX

最近はいろいろプロジェクト火を噴いて全然そういうのに興味を持つ時間がないが、
久しぶりに本屋に行ったら既にSpringは4が出ていた。

そもそもSpring触ったことないけど使い勝手いかが？

541 ：デフォルトの名無しさん：2014/08/06(水) 08:57:29.77 ID:3texkp06

SpringBoot最高

542 ：デフォルトの名無しさん：2014/08/25(月) 19:40:34.17 ID:1ho98kiz

Struts2について教えてください。
s:iteraterの中でs:checkboxを配置しているのですが
一度チェックを入れた行のチェックを外してポストしても
復活してしまいます。
こんな現象経験ある人いますか？

543 ：デフォルトの名無しさん：2014/10/12(日) 07:24:14.76 ID:2bnfnHq9

DWRが凄く使い易いと思ってる初心者ですが、何であんまり人気無いんでしょう？
脆弱なところがあるんですかね。
このスレのプロの皆様方の評価をお聞きしたいです。

544 ：デフォルトの名無しさん：2014/10/13(月) 15:18:17.57 ID:ncfHwCYF

そういえばDWRなんてあったな。
いまは、結局作り込むんならサーバサイドの言語に関係なく、クライアント側でjsを直接ゴリゴリ、って感じだけど、
まためぐりめぐってサーバサイドと連携したフレームワークが再び出てくるのかな。

545 ：デフォルトの名無しさん：2014/12/06(土) 16:33:10.16 ID:evyQIgPT

DWTとかWicketはネットワーク圧迫するのが難点だな

546 ：デフォルトの名無しさん：2015/02/09(月) 14:46:05.14 ID:yhC/A2d0

dropwizardどうかな？
普段androidオンリーなんだけど、apiも同時開発する場合、同じIDE(IntelliJ Idea)上で開発できて良さそうなんだけど。

あとデプロイもなんか楽そうなイメージがある

547 ：デフォルトの名無しさん：2015/02/13(金) 20:32:37.69 ID:pjknnY+t

「MyJVNバージョンチェッカ for .NET」で、バージョンをチェックできるソフトウェアは次のとおり。

Adobe Flash Player
Adobe Reader
Adobe Shockwave Player
JRE
Lhaplus
Mozilla Foundation
Mozilla Firefox
Mozilla Thunderbird
QuickTime
Lunascape
Becky! Internet Mail
OpenOffice.org
VMware Player

IPA、脆弱性のバージョンをチェックする「JVNチェッカ」を公開 | マイナビニュース
http://news.mynavi.jp/news/2015/02/13/161/
2015/02/13

548 ：デフォルトの名無しさん：2015/02/17(火) 21:33:32.45 ID:0TG0WuwS

.NETのランタイムがLinuxやMacに移植されることになったから
もうJavaでのWeb開発は下火になりそうだな
OWINもできたしIISを使わずにASP.NET MVC5とかが使えるようになる

http://news.mynavi.jp/news/2015/02/04/229/

Javaは良いWeb FrameworkないからJavaでWeb app作る理由がない

549 ：デフォルトの名無しさん：2015/02/17(火) 21:38:43.03 ID:QX+zKpkK

時代はシングルページのJavaScriptアプリをサーバサイドでも動かすことだけどな

550 ：デフォルトの名無しさん：2015/02/17(火) 22:31:05.95 ID:igbT8vqk

Javaがオワコンとか言ってるのはC#土方だろ
だせーから出張してくんな

551 ：デフォルトの名無しさん：2015/02/17(火) 22:39:39.41 ID:0TG0WuwS

>>549
そんな時代はこない
動的言語で大規模開発は非効率

>>550
ださいのはJavaだろ
ろくなフレームワークないし

.NETがクロスプラットフォーム対応したらJavaなんておしまいだ

552 ：デフォルトの名無しさん：2015/02/17(火) 22:58:19.58 ID:Lj0O1+YE

なんつーか嬉しいけどタイミングが遅いわホント

553 ：デフォルトの名無しさん：2015/02/17(火) 23:02:07.59 ID:0jZbE2oC

>>551
> 動的言語で大規模開発は非効率

そのためのTypeScripだろ
C#作者が作ってるのにお前取り残されてるよ

554 ：デフォルトの名無しさん：2015/02/18(水) 01:32:17.08 ID:J2r+KB+L

JavaにもデリゲートとLINQ欲しいよなあ

555 ：デフォルトの名無しさん：2015/02/18(水) 11:06:31.98 ID:206RiQwb

いらないよー
refとoutだけほしい

556 ：デフォルトの名無しさん：2015/02/18(水) 23:53:10.80 ID:Lyc1fDiN

ラムダの抜け道としてref入らないかな
↓みたいのを綺麗にやりたいわ
String[] s = new String[2];
get (em -> {
s[0] = findString(em, foo);
s[1] = findString(em, bar);
});

557 ：デフォルトの名無しさん：2015/02/19(木) 00:26:38.64 ID:gU64xR0D

それ絶対refよりLINQの方が簡潔で読みやすく書けるな

558 ：デフォルトの名無しさん：2015/02/19(木) 11:01:21.55 ID:7e+hWIQQ

クロージャの内部に変数を参照渡しされるとバグの元になりやすいから今のままでＯＫ

559 ：デフォルトの名無しさん：2015/02/19(木) 18:19:05.55 ID:2/iHs8yP

>>554
メソッド参照あればデリゲートいらなくね？なんか不足あるか？

560 ：デフォルトの名無しさん：2015/02/20(金) 00:09:59.71 ID:NbHNJ6bx

関数型プログラミングの方向に向かってるんだから今更refもいらん
副作用は甘え

561 ：デフォルトの名無しさん：2015/02/20(金) 00:30:06.47 ID:nBCjMlze

関数型プログラミングなんてまったく流行ってない
ScalaもF#も人気ない

562 ：デフォルトの名無しさん：2015/02/20(金) 00:48:55.89 ID:rQRSK5VB

また取り残され君w

563 ：デフォルトの名無しさん：2015/02/20(金) 00:58:22.60 ID:8GWvXfSo

WebフロントエンドのGUIというかJavaScriptにFRPの潮流が来てるみたいだから
今年こそ関数型言語の夜明けになるで（白目

564 ：デフォルトの名無しさん：2015/02/20(金) 01:13:31.35 ID:rQRSK5VB

Java8のラムダ、Stream、Optionalも関数型からの輸入だし
関数型言語が主流でなくても関数型の考え方は急速に取り入れられている
取り残され君はいつまで経っても気付いてないけどな

565 ：デフォルトの名無しさん：2015/02/20(金) 01:20:09.41 ID:nBCjMlze

>>562
取り残されてないわ、Scalaは少しいじったよ
Javaのフレームワークがひど過ぎたからScalaを少し勉強した。

まずScalaの言語がひどい
同じ処理書くにもいろんな書き方がありすぎて無駄に複雑
他人のコード読むときにすごい苦労する

あとコンパイラが産廃、もっさりしすぎ

さらにWebフレームワークが醜い。
当時人気あったLiftとかいうのを触ったが意味不明だった。

もうScala信者なんて絶滅してるんじゃないの

>>563
Haskellとか何年たっても流行らないぞｗ

566 ：デフォルトの名無しさん：2015/02/20(金) 01:23:09.04 ID:MC+61nmD

ヴァルハラの値型が取り入れられたらTupleとしてutilパッケージに入れて欲しい
return Tuple.of(1, true, "foo"); とかしたいじゃん

567 ：デフォルトの名無しさん：2015/02/20(金) 01:59:19.88 ID:nBCjMlze

>>564
ごまかしすぎｗ
関数型の一部が取り入れられるのと
関数型プログラミング言語が主流になるのはまったく次元が違うぞ

MSがプッシュしたF#でさえ流行らないんだから
関数型言語が主流になるわけがない

568 ：デフォルトの名無しさん：2015/02/20(金) 02:18:33.32 ID:rQRSK5VB

>>567
まず日本語を読み取る力を付けような
>>560は>>554-555からの流れでJavaという言語にrefが欲しいという意見に対する反論だ
すなわち主題は明白にJavaなんだよ
>>560を丁寧に書くとこうなる

・Javaは関数型プログラミングというスタイルのサポートに向かっている
・副作用が主目的となりやすいrefはそれに反する
・従って今更Javaにrefは不要である

わかるか？
>>560は「関数型プログラミング」と書いただけで「関数型プログラミング"言語"」とは書いてないんだよ
主題はJavaだからな
ScalaもF#も話題にしていない
それは読解力のない>>561が勝手に出してきただけだ

ついでに、Scalaは関数型言語じゃないだろ
あれはJavaよりも関数型の要素を多く取り入れただけのオブジェクト指向言語だ
F#は本格的な関数型言語

569 ：デフォルトの名無しさん：2015/02/20(金) 02:32:48.94 ID:nBCjMlze

>>568
Scalaはふつうに関数型言語として認識されてるぞ
知らなかったの？取り残されてんねｗ
http://ja.wikipedia.org/wiki/%E9%96%A2%E6%95%B0%E5%9E%8B%E8%A8%80%E8%AA%9E

570 ：デフォルトの名無しさん：2015/02/20(金) 03:26:06.85 ID:rQRSK5VB

うわ、「ついで」の部分しか反応できないくせにドヤ顔！？www
一言「誤読してました、ごめんなさい」って書けないのかよ
小せえなあ

571 ：デフォルトの名無しさん：2015/02/20(金) 07:47:42.13 ID:Gu7jq4Ss

関数型言語、俺かっこいいw

572 ：デフォルトの名無しさん：2015/02/21(土) 10:44:35.75 ID:52mvleut

サーバー側でviewを生成するフレームワークはもう考え方が古いらしいな
JavaScriptを描くのは嫌だし、GWTがもう少し流行ってくれたら嬉しいのだが

573 ：デフォルトの名無しさん：2015/02/21(土) 13:18:00.00 ID:6pp8KZXb

ところが一周して今はサーバサイドレンダリングがトレンドだw
ただしJSのフレームワークをサーバサイドでも使って(isomorphic)、初回表示だけな
Javaでもこんなことする人が…
http://winterbe.com/posts/2015/02/16/isomorphic-react-webapps-on-the-jvm/

GWTはもう諦めろ
JSが.classファイルの位置には来たが、Javaはそのソースの位置を確保出来なかった
今はclass構文なんかが使えるJSの新しい仕様(ES6)や静的型が使えるTypeScriptをコンパイルして、
古いJS(ES5)を生成するのが増えてる

574 ：デフォルトの名無しさん：2015/02/21(土) 14:18:42.14 ID:YYuiHhiK

ホントJavascriptがここまで侵食してくるとは思わなかったわ

575 ：デフォルトの名無しさん：2015/02/21(土) 14:46:05.87 ID:siDyx6mt

そらデザイナー方面が侵食してきたらそうなりますわな。

576 ：デフォルトの名無しさん：2015/02/21(土) 16:05:54.87 ID:0VMa227o

そろそろMS(ASP.NET)信者が「そんな時代は来ない」って書きに来る頃

577 ：デフォルトの名無しさん：2015/02/21(土) 17:02:06.61 ID:6pp8KZXb

MSはJSやNode.jsにもすごく力を入れてるから同じようなことは考えてるんじゃないか？
>>553のTypeScriptや>>563のRxJSをやってるし、Node.jsに対しても

・Node Foundationの設立メンバー
・何年も前からAzureでNode.jsをサポート
・Oracleよりずっと前からSQL ServerのNode.js用ドライバを提供
・複数の社員をNode.jsのフルタイム開発者(コミッター)に

という力の入れよう
だからIsomorphicな何かを出してきても全然おかしくない

578 ：デフォルトの名無しさん：2015/02/21(土) 18:01:34.31 ID:c/IiR1p2

でも、Node.jsをWindowsで動かすのは地獄、と。

579 ：デフォルトの名無しさん：2015/02/21(土) 19:18:23.73 ID:6pp8KZXb

>>578
それ何年前の話だよ
今は公式サイトのインストーラ一発でnpmまで入って楽勝だぞ
Javaと同じように運用はLinuxでもWindowsで開発できてる

580 ：デフォルトの名無しさん：2015/02/22(日) 13:37:52.79 ID:RWAhjQlK

>>573
GWTって海外だとspringについで使われてなかったっけ？
altJSもみんな変換系でコンパイル遅いのにどうしてこんなに差がついた！？

581 ：デフォルトの名無しさん：2015/02/23(月) 00:53:16.04 ID:ecl/DKf3

Playぶっ飛びすぎじゃね？
ビューウザすぎ！

582 ：デフォルトの名無しさん：2015/02/23(月) 01:21:10.18 ID:mnJjrT/b

>>578
Macでおk

583 ：デフォルトの名無しさん：2015/02/23(月) 13:45:55.88 ID:WWKQc62e

Node.jsは、RubyなんかよりよっぽどWindowsで使いやすい
(というかJavaと同様にWindows、Mac、Linuxなどの環境間の差異がない。Rubyがありすぎるともいうが)

あと、ちょうど土曜日に行ってきた↓でも出てきた話が、ちょうどこのスレッドでも流れててびっくりした。
(FRP、React のあたり)
Frontrend Conference - A conference for front-end developer（2015年2月21日開催）
http://frontrend.github.io/conference/

584 ：デフォルトの名無しさん：2015/02/23(月) 13:57:57.72 ID:O9iQ6Hd8

Node.ks　w

585 ：デフォルトの名無しさん：2015/02/23(月) 14:43:05.76 ID:vJ23+Dwb

そりゃ話題は被るでしょ、取り残されてる人を除けば

586 ：デフォルトの名無しさん：2015/02/23(月) 21:28:31.48 ID:t9wkfvj3

javaなんかもう使わねーのにパソコンにインストールされてくんなや。
スパムかよ。

587 ：デフォルトの名無しさん：2015/03/03(火) 22:12:51.01 ID:5JLHvWAD

playとspringとwicket、結局どれが一番いいのよ？
やっばりplayなの？

588 ：デフォルトの名無しさん：2015/03/03(火) 22:20:00.65 ID:V6jvOYpo

JavaEE標準でいい気がしてきた
めんどくさい

589 ：デフォルトの名無しさん：2015/03/03(火) 22:27:39.63 ID:5JLHvWAD

>>588
JSFとjava EEを使って、
O/Rマッパーは？

590 ：デフォルトの名無しさん：2015/03/03(火) 22:31:11.44 ID:Yydy8RKX

JavaEEっていうならJPA一択

591 ：デフォルトの名無しさん：2015/03/03(火) 22:44:47.81 ID:5JLHvWAD

>>590
JPAって、HibernateのHSQL使うのと、あまり変わらなくない？
JPA以外なら？

592 ：デフォルトの名無しさん：2015/03/03(火) 22:54:13.28 ID:Yydy8RKX

JavaEE標準にはJPAしかない
SpringでもPlayでもJPAが用意されてる
自分で選べないならJPAだ

俺は全力でJPA避けるけどな

593 ：デフォルトの名無しさん：2015/03/03(火) 23:00:22.17 ID:5JLHvWAD

>>592
避けて、結局mybatisとか使ってるの？

594 ：デフォルトの名無しさん：2015/03/03(火) 23:07:54.11 ID:Yydy8RKX

Spring JDBCベースのオレオレ

595 ：デフォルトの名無しさん：2015/03/04(水) 00:25:56.03 ID:qfeQbh2b

なんだかんだでseasar2が一番楽でよかったよなー！

596 ：デフォルトの名無しさん：2015/03/04(水) 09:28:41.55 ID:UN0ssHsJ

O/Rマッパーとか軟弱なもの使わずJDBC
自分でSQL書かないと気が済まないだけとも言う

597 ：デフォルトの名無しさん：2015/03/04(水) 10:39:57.14 ID:CfP3NAwM

O/Rマッパーとかゴミしかない

598 ：デフォルトの名無しさん：2015/03/04(水) 15:09:34.54 ID:WhjHWey/

Donaいいと思う

599 ：デフォルトの名無しさん：2015/03/04(水) 21:21:02.50 ID:2IxQHWhp

>>597
何を使ってみて、そう思ったの？
Mybatisやs2daoを使ってみて、そんな事を言ってるの？

600 ：デフォルトの名無しさん：2015/03/04(水) 22:31:27.86 ID:LHVPulYe

だお

601 ：デフォルトの名無しさん：2015/03/04(水) 23:24:44.85 ID:Su4632ys

domaは余計なものがなくてよさそうだな

602 ：デフォルトの名無しさん：2015/03/04(水) 23:25:56.68 ID:BGhI9Q/J

doyaお勧め

603 ：デフォルトの名無しさん：2015/03/05(木) 21:01:37.22 ID:8UwfyP8Y

Doma便利そうに見えるけどすぐにhasOne, hasManyねーのかよって思う。

604 ：デフォルトの名無しさん：2015/03/06(金) 01:13:07.34 ID:3LhkyDVp

mybatis意外は全部ゴミ
これ常識

605 ：デフォルトの名無しさん：2015/03/06(金) 09:26:09.09 ID:1QqSUnwd

以上、塵でした

606 ：デフォルトの名無しさん：2015/03/09(月) 21:25:43.72 ID:mAElm1fs

O/Rマッパーは肝心のselect文が使い物にならないというか
N+1問題が避けられないよね（SQLが直に書けますとか謳う変なのは問題外として）

607 ：デフォルトの名無しさん：2015/03/10(火) 22:16:19.80 ID:qcHiJ2e0

何が変かわからんがJPAならEntityGraphでググレカス

608 ：デフォルトの名無しさん：2015/03/11(水) 00:22:36.92 ID:1uDb2QXI

2年近くも知識を更新せずにドヤ顔する
そんなエンジニアに私はなりたい

609 ：デフォルトの名無しさん：2015/03/11(水) 07:43:37.39 ID:k634rWxZ

２年で古くなるような技術は使わないほうがいい

610 ：デフォルトの名無しさん：2015/03/11(水) 09:42:51.05 ID:hdMW8BEP

フロントエンドは2年もかからず枯れるどころか息絶えるモノが多すぎる
作りっぱなしならトレンドのモノに飛び付いてもいいんだけど
後の保守考えると迂闊に採用できない

611 ：デフォルトの名無しさん：2015/03/11(水) 09:45:59.99 ID:0wRwUdte

ドッグイヤーは古い--->ラットイヤーは古い--->ITは古い

612 ：デフォルトの名無しさん：2015/03/11(水) 09:54:33.08 ID:ccVUCtEJ

>>606
？