Java Web Application Framework総合 ver2
■ このスレッドは過去ログ倉庫に格納されています
【関連スレッド】
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/
以上、テンプレ終わり。
需要があるかわからんけど立ててみた。 >>1乙
ASP.NETの話題が増えてたしスレタイからJava外してもよかったかもな
あるいはASP.NETは専スレ立ててそっちでやってもらうか ASP.NETはJavaみたいにフレームワーク同士の組合せとかあんまり無くって、
ASP.NET MVCか、古い方のASP.NETくらいしか無いからな。
JavaはWeb層、DIコンテナ、OR/Mと色んな組合せがあるから、
難しい反面、語ることも色々あるんだよね。
と言いつつ、Struts1.xを仕事で使ってるんだけどね。
ちょこちょこカスタマイズしながら。
フレームワークを上手く使えば量産型PGを大量に投入できるので、
工数削減に寄与できるんだよね。
JSP/Servletしか使わないとか、オレオレフレームワークとか言ってるのは、
ビジネスセンス疑いますよ、ええ。
あと、どうせオプソのサポートなんて合って無い様なもんなんだし、
自前でコード読んでサポートできる技術力は会社に一人くらいは必須だよね。 １アクション１メソッドで中に何百ステップ書かれてようと気にしない
量産型PGで生産性に拘るなら当然の選択 >>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 乙 結局生ServletとかJSPとか言っているのは開発にスケールもスピードも求められて
いなくて、そのくせ一度作ったサービスを見直しもリニューアルもせず延々と延命
させ続ける客相手の受託開発メインってことかなぁ。面白く無さそう。 最近angularjs + playframework2(scala,coffeescript,less)を使い始めたんだけど、すごく使いやすいよ。
.NET MVCと比べても作業効率が高い。でも、scalaだとスレ違いか。 Scalaはいずれ抑えたいけど業務アプリだと出番がないな Struts1使ってるやつがビジネスセンスどうのこうのw
利益率上げたければ生産性低いStrutsはないだろ ScalaはJavaの代替として考えた時期もあったが
うんこフレームワークしかないのでやめた
Play!はsessionがなかったりかなり変なフレームワークで
汎用的に使えるものじゃなかった。
Lift はものすごく使いづらくひどいものだった。
Scalaはコンパイルが遅いのも問題でイライラした。
けっきょく、ASP.NET MVCが最強だった ScalaがSession持ってたまるか
何のための関数型なんだか ぜんぜんレイヤーが違うじゃん
どんな言語でもセッションは必要だろ >>5
商用のなんて使ってもバグなんて直してくれないだろうに……
というのがＯＳＳに流れてついてきた奴の流れじゃろ。 playframeworkは基本ステートレスだけど、セッション持ってるよ。
まぁ、servletとは全く別物だから取っ付きにくいかもだけど、playの方が扱いやすい。
一言で言うと、Java on Rails。試してみて損は無い。
scalaがコンパイル遅いのは同意。 play2のview templateがクソだけど、
angularjsと一緒に使うことで生まれ変わる。 自社プロダクトだからスケールやスピードよりも
より安定してより細かい制御が作りこめて寿命が長くないといけないから
やっぱりJSP&Servletがいいかな。 Java on RailsをのたまうならGrailsを無視するな〜 Scalaは気になるんだけど、コンパイルの遅さとか、その辺については実際どうなの？
実際に使っている人の話が聞きたいけど。
あと、個人的にはPlayよりScalatraが気になるかな。 JAX-RSはCDIのConversationScopedと組み合わせると業務でも行けそうだ Scala推せば通ぶれる、という雰囲気があるのは確か ConversationScopedと組み合わせなくても普通に業務で使っているけれどもね > JAX-RS >>21
scalaはコンパイルが本当に遅い。ここはなんとかして欲しい。
まぁコンパイルの遅さを差し引いいても、開発効率やメンテナンス効率が高いから全体で見るとそれ程問題ない。
コンパイルなんてほっとけば終わってるし。
Scalatraも使いやすい。Servlet派の人はこっちの方がいいかもね。
>>20
Grails？GroovyはGradleレベルのちょっとした物書くにはいいけど、
本格的なプロジェクトでは使いたくないな。
Groovyの作者もScalaを知ってたらGroovyなんて作らなかったって言ってるからね。
http://www.infoq.com/jp/news/2009/07/scala-replace-java >>26
印象論や伝聞だけで敬遠されているのならやや勿体ないな > Grails
Grailsの良いところはGroovy云々以前にまずSpring MVCベースのフルスタックの
フレームワークとして一番普及していてメンテもされていること。
Javaで書かれたSpringベースの成果物にWebのUIを与えるのに一番の近道。
あとGroovyに関してはこれで大切なロジックを書くことまでは期待していない。
うちの会社もバックエンドやGrailsで使うにしても抽象クラスの類はJavaでカッチリ
書いている。
あとGroovyはグルー言語としてとても優れていて、Javaでカッチリ書かれたものを
Groovyでサクッと拡張してからデプロイするといった用途に便利。 おいときますね
下2行は辞めた先輩が実際に歌った歌詞だよ☆ミ
ヤバ 破綻した グルーで補修した
それだけで なんか達成感
大事なのは QCD あと利益率ゥゥゥゥゥッ⁈
コストを 下げなきゃ 基盤の意味がない Scalaやっている人は、参考までに使っているツール(IDE、他)を教えてくれないかな？ >>31
Eclipseベースは古いバージョンしかつかえない
Scalaスレ情報では
ScalaのIDEはIntelliJ IDEAが一番人気らしいよ
自分で使った感じでもIDEAが一番ましだった。
compile遅いうえに、よいフレームワークがなかったから
俺はscala自体捨てた
言語はJavaよりましだけどライブラリ、フレームワークといった
エコシステムが充実していない。
ScalaはOSSも盛り上がりに欠けている。 ScalaはCPUリソースを使い切るような環境でもなければ出番が無さそう
AWSにデプロイできるScalaベースのソーシャルアプリとか出たら話は変わるかも 寺田氏曰くGF4はまだ安定版じゃないとのことだがJerseyの2系(今は2.1)も同じかな？ roadmapを見るに今年中に4.0.1が出るらしいが
本番で来年出るらしい4.1からかな、商用サポート始めるみたいにあるし 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の公式リファレンスは使いやすい。 毎日何かが半額のmanningが今日はGroovy関係
プロモーションコードはdotd0806
Gradle in Action
http://www.manning.com/muschko/
Grails in Action, Second Edition
http://www.manning.com/gsmith2/ 制作者がScalaを知ってたら作らなかったとか言ってた言語なのに人気あるんか Scalaを知っていたら敢えて新しい言語を作るまではしなかっただろう
というだけの話で、Groovyが劣っているとかそういう話じゃないだろ Java知っていれば学習コストはかなり低そうだからな〜 > Groovy >>40-41
Scalaもコンパイル遅いし大したことないよ
たいして人気もでてない >>40
Grailsだから流行ったフレームワークではなく、まず良く出来たフレームワークが
あって、それを使うことからGroovyを再発見した人も多いのでは。
RailsやPlay!もそうだよね。人気のあるフレームワークがその言語の新規ユーザを
増やす呼び水になっている。
フレームワークとしてはGrailsは良く出来ていると思う。でかいけどね。 Glassfish3.1.22なんだけどj_security_checkで認証すると
認証前のリクエストがPOSTだった場合でも認証後に再びPOSTされるんだよな。
なんかChrome見ると302の後にChromeはちゃんとGETでアクセスしてるから
Glassfishが認証フィルタあたりで何かきもいことやってるんだろうけど
HttpServletRequest#login使った手組だとどうにも再現できん。 HTTPの仕様上、302はメソッドを変えずにリダイレクトするのが正しい(前がPOSTなら後もPOST)
しかしほとんどのブラウザは常にGETでリダイレクトするのでHTTP 1.1で303と307が追加された
303は常にGETでリダイレクトする (現実の302と同じ)
307はメソッドを変えずにリダイレクトする (仕様上の302と同じ)
Glassfishは303を使ってるとか？ 最後の一行間違った
Glassfishは307を使ってるとか？ Glassfishは302を返してるよ。メジャーなブラウザは302にGETを返すらしい。
あとChromeは303にはGET、307には前回と同じメソッドとこちらはちゃんとしてくれる。
どうもGlassfishはj_security_checkの段階ではなく、
次のリクエストで認証してるみたい（Set-Cookieのタイミングがここ）
BASIC認証と動きを合わせるためにきもいことしてるんだろうなぁ
JBOSS ASとかも後で確認する どうやらこの現象はTomcat側にmaxSavePostSizeってプロパティで設定できるらしいね
Glassfishはどうやって設定するのかまだ分からないけど、JBoss AS7.1.1は無効にしてるっぽい Viewをサーバ側で動的に生成する仕組みが
そもそもオワコンになってきてる気がする
MVCのMCだけサーバ側で担当してVはHTML5+JS+CSS3
連携はJSONかpjaxで。 WPFはWebのページアプリの概念を取り込んだが
Webは逆にSDIアプリの概念にシフトし始めてるのかもな >>52
またそうやって「JSON返すのはサーバサイドFW不要論そのもの」
「その不要論を言いだすと、Java不要論になるしこのスレも全否定だし、
スレ住人が携わっているであろうサーバサイド開発も全否定」厨を煽る作戦ですね サーバ側はJSONだけを返せればそれで良い、…そう思っていた時期が、私にもありました(´・ω・`) HTMLフラグメントをサーバから非同期で返す
pjaxてのがあるのか。よさげだな。 狭義(jQueryプラグイン)のPjaxは何年か前に話題になっただけでオワコン臭 よくわからんがInnerHTMLに直接代入できるテキストをくれる感じか javascriptでJSONパースしてはめてくって処理が要らなくなるのはええね pjaxは結局動的にHTMLフラグメントを生成するのに従来同様にJSPの類を使う事になる。
なので静的なページが中心で一部だけ動的にしたい場合など無理にJSONでやりとりするより
楽だし、動的でかつクローラブルでハイパーリンク可能にするのもJSON使う場合より手間は
少ない。 >>57
一度挑戦したが結局挫折したわー。
最近のサーバーの性能だとよっぽど大規模なユーザー数のアプリじゃないと
そこまでするメリットがない上に実例がなくてだるい。 JSONで済む割合はサイト毎に全然違うしょ
スマホネイティブアプリ向けサイト＞＞＞＞シングルページアプリ向けサイト＞＞＞＞旧来的なサイト つーかね、HTMLのフラグメント返した方が更新が綺麗だったり、仕組みが単純だったり、JSONよりそっちの方が良いや、ってなっちゃったりもして。 サーバ側でやる処理と、クライアント側でやる処理を
どこで区切るかってだけの話だよね
スマホ向けWebアプリだと、意外とJSONのほうが小回り利いたりする HTMLのフラグメントっていうのは、partial view というか、部分的なHTMLのこと？
(<div> のなかみだけ、とか)
JS で innerHTML でさしかえる用、とか。 そんなイメージ
jQuery使うようになってからは素のJS書かなくなって
innerHTMLとかもう遠い昔 サーバサイドの人がJSP書きながらちょっとjQuery使うだけならPjaxいいかもね
クライアントサイドの人はBackboneやAngular、つまりテンプレートエンジンや
データバインディング使うから無用だけど TwitterがHTMLのフラグメントを使う様にしたとかいう話ってなかったっけ？
あれって、どういう理由でそうなったの？ 初回表示が遅くなった対策に一発目はHTML返すよう戻したって話？
表示後は今でもJSON(コンテントタイプはtest/javascriptでgzip圧縮されてる)でタイムライン更新してる デザインサイドだとどの程度ライブラリに依存するのがトレンドなんだい？
jQuery + Normalize.css あたりで頑張るのか、Twitter Boostrapとか使うのか >一発目はHTML返す
HTMLに<script>タグで囲んだJSON一緒にくっつけて
返すとかはよくやるな。リクエスト減らす目的で。
Boostrapは便利なんだけど、アレ使うとLook&Feelがまんま
Boostrapテイストになっちゃうんで、デザインちゃんと
考えてるプロジェクトだと意外と使わない。
CSSの学習素材としては素晴らしいが。
HTML5-Boilerplate + jQuery + 独自CSSって感じかな。
Normalize.cssも使う。 クライアントサイドでもサーバーサイドでもどちらでも良いけれども、JSONとか
使うREST APIを開発するにあたって認証はどの方式を使っている? >>74
サーバサイドの REST API の場合は、クライアントがブラウザとは限らないため、
完全なステートレスでの利用を前提にハンドシェイク後にキーを発行して、
クライアントは受け取ったキーを常にパラメータとして付与しながら API を叩く
仕様にしてる。
一旦キーが発行された後は、サーバ側では、渡されたキーと接続先アドレスを
使って認証の判定をしている。自分のシステムの場合は、複数のツール/システム群から
順に連携して叩かれる事もありうるから user-agent の判定とかはあえて行っていない。
あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、
使われていないキーは一定期間が経過したらどんどん失効（削除）させてる。
実運用では律儀に終了処理なんて呼んでくれない奴の方が多いからね。
誰もが使えてもいい公共性のある API なら、そもそもそんな仕掛けも要らないだろうけれど、
緩い個体の識別から、サーバ側に登録された ID が持つ権限内容との紐付けをした上での
識別までハンドシェイク部分の作り方次第で自由に切り替えられるから、自分が最近作った
システムは大枠としてはどれもそういう作りにしてるかな？ >>75
> サーバ側では、渡されたキーと接続先アドレスを使って認証の判定をしている
接続元IPアドレスを認証に使うのは、IPアドレスの偽装もあり得るので危険なのでは？
と思ったが、 >>75 さんの環境がイントラ内とかだったら、わりきってそれもありかな、と思った。
(イントラネット内で、ちゃんとIPアドレスや、それがどんなサーバなりスイッチか、などが管理されていれば) IPアドレスは保険みたいなもんで認証の主はキーでしょ？ 巷のAPIはSSLを使った上でAPI Keyでリクエスト署名ってパターンが多い気がする。
うちもそうしている。
HTTP Method name + Request Path + Timestamp + bodyからHMAC-SHA1計算して
HTTPヘッダに埋め込む。
ただこれだとクライアントの開発時にAPIをテスト目的でcurlとかで叩くことが
面倒なので、同じキーでBasic認証も出来るようにしている。 サーバではコミットしたけどクライアントで反映失敗とか
セッションハイジャックをかんがえると
OTPとはいかないまでもシリアル値くらいないとダメな場合もある。 >>80
認証だけなら良いと思うよ。SSLをかましているのであれば。
ただSSL経由とはいえ秘密鍵を平文で投げたくない、かつステートレスにしたい
のであれば自ずとリクエストと秘密鍵から計算したハッシュ値で署名するという
解決策にたどり着く。
仮にリクエストがのぞき見されても秘密鍵は漏れないし、ハッシュ値を計算する
データの中にタイムスタンプを含めておけばリプレイ攻撃にも多少は強くなる。 >>82
>>75と同じ人だよね？
>>75じゃサーバからクライアントにキーを渡すことになってるけど、それが秘密鍵？
だとしたらレスポンスのぞき見されたら秘密鍵漏れない？
「SSL経由とはいえ秘密鍵を平文で投げたくない」になってるのか疑問なんだが
さらに、「かつステートレスにしたい」と続いてるが>>75の以下を見るにステートレスに
なってなくね？
> あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、 >>85
別人か、正直すまんかった
それでクライアントの秘密鍵ってどう扱ってる？
サーバから渡すんじゃ「SSL経由とはいえ秘密鍵を平文で投げたくない」は難しそうなんだが
クライアントがイントラ内の別サーバなら楽だけどJSとかだと… >>86
API Keyはセッション毎の使い捨てではなく永続的なものね。
うちのシステムでは顧客、というかデベロッパにはまずユーザ登録をしてもらって、あとは
Webブラウザから管理ダッシュボードにログインしてAPI Keyを好きなだけ生成したり既存の
キーを無効にしたり出来る。
秘密鍵の文字列はまぁ、管理ダッシュボードのWeb画面からコピペw
でもAPI Keyを使った認証を提供しているサービスはこのやり方が多いと思う。 画面をさくさくっと作っていきたいんですが、なんかいいフレームワーク無いですかー？ 貴方が書き込んだのはこの銀のループするスレですか?
それともこちらの金の過疎るスレですか? >>88
好きなもの使いなはれ
ttp://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks Grails2.3か。
新機能はともかくivyを捨ててMavenと同じ依存性解決エンジンを使うように
なるのが嬉しいな。SNAPSHOTやclassifier周りのタコな動作がようやく解決。 Struts2もSpring2もまだ現役だというのにSeasar2ときたら… >>93
うちSeasar2バリバリ現役です・・・。
Spring2はいいとして、Struts2なんて欠陥品だろ。 そこでStruts1.2が現役な私の会社の出番ですよ。 >>93
今更GWTに手を出そうとしてる人でしょ？ >>94
そのとおり
SpringはRod Johnson抜けても続いてる
個人に依存しないビジネスとして成立してるわけ
日本はいつまでも個人のモチベーション頼み
そのくせ応援しないですぐdisる
OSSで身を立てるにはこの国は地獄だぜヒャッハー >そのくせ応援しないですぐdisる
スマホアプリのストアのレビュー見ててもそう感じるな。
AppStore、GooglePlayともに。
無料アプリなのに、ちょっとバグがあるとか自分の端末では
動かないってだけで、鬼の首を取ったようなdisりかた。
スマホ向けアプリ作るのは海外向けがいいな。
国内市場向けに作っても旨みは少ない。 某ブログでそろそろSeasarは終わりでいいよね、JavaEEも悪くないという話をやっているけど
日本でSpring等々ではなく和製FWが広まって萎んで今微妙な状況になっているのはつくづく
ドキュメントやコミュニティの言葉の壁の問題なのだなぁと思う。 >>102
盛り上がったのは普通にseasarの出来がよかったからだし、衰退したのは開発ストップしたからだろ SpringMVCでweb開発してるけど、いったん設計と実装の仕組み整えちゃえば
あとは仕様が増えても基本的に、コントローラ、インタフェース、サービス
周りのコピーでガンガンいけるから、自分的にはSpring一択だな。 >>102
クライアント側の新しい機能ならほしいかもしれないが、
サーバー側の開発って別にそんな新しい機能いらないんじゃないかねってのはある。
あえて新しくする必要がないというと叩かれるのかもしれんがそんな感じ。 Struts1.2＋内製フレームワークをJava5で動かしている弊社が最強です。 webアプリだとサーバ側はたしかに、だいたいやること決まってきてるしな。
モデル側処理とか認証周りとかバッチとかサブシステム連携とかviewに必要な情報の生成くらい。
フロント側は最近はブラウザの表現力と処理能力上がってるから
JSPとかのサーバーサイドテンプレート使うよりは、jQuery使ったり
Backbone.jsやAngulerJSみたいなフロントエンドMVC使うケース増えてる。
サーバーサイドとはRESTでやりとりできればいいし。 >>102-103
開発を継続する人材が集まらないのは言葉の壁の問題といえるな >>109
それ、俺も知りたい
vaadin日本語ドキュメント少なすぎて涙出るよねー
皆さんは画面をどうやって作ってますか？使っているフレームワークを教えて頂きたいのですが
デザイナーに丸投げしているって回答以外にあったら教えて頂きたい
GWTをここ数ヶ月勉強してみたのですが、GWTは微妙な気がします >>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 >>112
そんな感じのリッチな画面を作りたいんです。
画面周りを手書きするのはよくあることなので我慢できますが、
javascriptを手動でデバッグするのだけは避けたいなと思いました。だから、GWTを勉強してみました。
結果、GWTは遅すぎてSSDマシンじゃないと厳しいってことがわかりました。
会社では自分の気分でマシンを変更できないので、GWTを使うのは難しいという結論になりました。
>>113
普段、Flexを使って開発しているので、Flexライクなjava frameworkが欲しいなーと思いました。
Flexは非同期処理基本だし、画面周りの制御が難しい(と言うより、処理速度が遅い）のがダメなところですよね。
javafxはflexのパクリだと思うのですが、javafxのweb版みたいなのがあればいいですよね
JSF勉強してみようかなって思いました >>114
サーバー側の仕組みに比重を置いてリッチなUI/UXを実現するのは不可能だよ。
見栄えについてはCSS3必須。その見栄えに命を吹き込むのがJavaScript。
サーバーサイドでできる範囲は、HTML5+CSS3+JSが育って実をつけるための
大地と水と肥料を用意すること。
GWTがどうとかって話じゃないことだけは確か。 >>117
GWTについて知らないでしょ。
知っていればサーバーサイドが云々とか言うコメントは出ない。 >>118
あー、すまんかった。
GAEと勘違いしてた。 GWTって今でもメンテされてるの?
GWTが楽ってのは聞いたことがあるけど、結局ブラウザ側のUI/UXを作り込むなら、
jQueryとかを直接使った方がいいと思っているのだけど・・・ jQuery を直接使って特に問題が起こらないならば、それで実現すれば良いのでは？
GWT などは Java だけで RIA がサポートできる所とかがポイントなわけですから、
（自分は使ったことないからあれですけれど）開発対象、人員、保守性、工期とか
色々踏まえて考えれば、状況次第ではアリな気がしています。
逆に凝った UI が要らなければ、旧来型の使い慣れたフレームワークや
テンプレートエンジンの方が開発も運用も過去資産も含めた実績があるので
トータルで安定するでしょうし、部分的に凝った UI が必要なら、そこだけを
重点的に対策した方が無難だと考えてしまいますね。 GWTはクオリティの高いUI/UX作るにはいろいろ役不足なイメージしかないな。
jQueryとその周辺プラグインのほうが、世界も広いし圧倒的に充実してるのと
Look&Feelに関しては、CSS3と各種CSSフレームワークで大抵のことはこなせる。
GWT採用しちゃうと、どうしてもGoogle風味から抜けられなくなるでしょ。 GWTとjQueryはちょっとレイヤーが違うので比較は出来ないかな。
jQueryはイベント周りの昨日とかjQuery UIはあるけれども総体としてはDOMの
直接操作を基本とした低水準(悪い意味じゃ無いよ)のライブラリ。
レイアウトや装飾はHTMLベースで記述して、そこにインタラクションをjQuery
で装飾していくイメージ。
他方でGWTは自身のレイアウト記述とウィジェットライブラリを持った一つ上の
レイヤーのツールキット。基本的には用意された部品を組み合わせて画面を
作る。
スタイリッシュで凝ったUIは作りにくいけれども、事務事務したおっさんくさい
UIを手っ取り早く作るのには結構便利 > GWT >>123
これだけ読むとGWTはJSFと競合しそう JavaSEとJavaEEの違いで、SEにはJDBCが入っているが、EEには入っていない。
これは、EEに含まれているEJBの中にJDBCの機能が入っているからだと、納得してよいでしょうか？ 中小企業の現行システム（旧来のクライアントサーバーシステム）を
Webシステム化するのですが、JavaEE＋JSF＋？・・・を考えています。
しかし、JavaEEは、中小企業レベルでは重いかなと心配です。
やはり、JavaSE + Strus2 + ・・・とかで、行うべきでしょうか？
サーバーのハード機能が良くなっているのでJavaEEでも問題ないでしょうか？ 一番いいのはASP.NETだけどJavaじゃないとだめなの？ >>133
元請けの中小SIerが、Javaを希望してきているのです。 >>135,>>136
Javaのシステムを他にも横展開したいようです。
それと、.NET系はコストが掛かるのがネックみたいです。 >>132
中小企業でSIerに丸投げするレベルならJavaはやめたほうがいい
Javaには開発生産性の高いフレームワークがないから、
開発のコストが高くつく。
一番高いコストはライセンス料金ではなくて人件費だよ
絶対にASP.netがベストだと思うよ
Windows認証使わずにベーシック認証を使うようにすれば
クライアントアクセスライセンスも要らない。
データベースもMySQLなどのオープンソースを使えばいい。
Windows Server(IIS)のライセンスだけならASP.netは安いものだよ。
>>137
.NETが高いとか言ってるようではそのSIerのレベルは怪しい。
SIerはJava以外はよくわかってない人ばかりなんだと思う。
そいつらの本音はJavaの知識と経験を使いまわしたいだけだよ 既にStrutの蓄積があるならともかく今から始めるなら普通にJavaEEかSpringMVCで
良いんじゃね?
元請けがJavaの経験あるなら彼らがそれを使い回すのは普通に合理的判断だしそこ
に.Net提案したところで干されるだけでしょ。 >>138
Windows認証とベーシック認証を比べる人にこの分野のアドバイスはあまり聞きたくないと思う。 >>140
何がおかしい？
認証方法でASP.netのトータルのライセンス料金が
大きく変わるんだから触れるのは当然だろう
Windowsの認証を使わなければ安くなる
あんたこそライセンスなにも知らないんじゃないか Java 前提で話が進んでるのに、.NET と騒いで簡単に変わるものなのかな？
.NET の方が上手く扱えて交渉できそうなら、それも一つの解だと思います。
>>132
何を基準に重そうと判断してるのか外野からだと理解できないです。それより、
そのような質問をしてる時点でそもそも自分たちで作れるの？という方が心配・・・。
どんな高性能なフレームワークや素晴らしいアーキテクチャを採用してても
根幹の設計や主要な実装を誤れば低速でポンコツなものに仕上がるでしょう。
開発メンバーのプロジェクトと利用技術に対する理解の方が重要な気がします。
既に自分達で実績を持つ慣れた構成があるなら、それをベースに研究開発的要素を
極力無くすのが着実なゴールを取るための堅実な手法だと考えますが、
そういった構成が無いのであれば、時間のある内にさっさと活用する技術要素を
調査して開発メンバーで制御できる構成にまとめてしまうのが無難でしょう。
他人に言われて選定しても扱えない/向かない技術だった場合、意味がありませんので。
もっと細かいことを評価できる材料が挙げられれば、どのフレームワーク構成が
良いか？とか、具体的なアドバイスも得られやすいかもしれません。 >>141
認証のプロバイダとメソッドの区別のつかない人がウェブアプリの開発について何が言えるの?
あと中小のクラサバをWebアプリ化って多分イントラ向けでしょ。
普通にCALの購入が必要なパターンだと思うけど。認証方式関係ないし。 >>132 です。
みなさんアドバイスありがとうございます。
JavaEE + SpringMVC + ・・を検討してみます。
JavaSE + Struts + 手作りのDAOもどき の経験しかないので
本当は、JavaEE + SpringMVC + ・・は避けたいのですが・・・・。トホホ。 自分たちで作れる＝お守りできる技術で作るのが一番。
新規の案件で新規の技術を使うとかリスクの塊じゃん。
新しい技術使いたいなら社内案件とか無難な奴でやっとけ。
ちなみに俺ならWicket+JPAかな、一番慣れてるから。 >>145
>JavaSE + Struts + 手作りのDAOもどき の経験しかないので
トホホだろうね >>145
JavaEE と SpringMVC は、役割がかぶってますよ
JavaEE = JSF2 - EJB3 - JPA2
Spring = SpringMVC - Spring Framework - Hibernate/JPA
Struts2 は、会社を潰したいのでなければやめた方がいい
(喩え話ではなく、中小企業なら本当に潰れます。大きい企業なら
CTO が首になる)
自分が好きにできるなら、
AngularJS - JAX-RS/Websocket - EJB3 - JPA2
かな。 >>149
その構成でログインや認証ってどうやります？ >>150
（要件のリッチ度によるが、) ユーザ認証・認可はアプリのレイヤではやりたくない。
ユーザ認証や認可は、JAASやSSO とブラウザ (とユーザ) の間で、勝手に解決してもらって、
アプリからは、何も考えずに req.getRemoteUser() なり req.getUserPrincipal()
でアカウント名や権限グループが取れるのが ... [作り手]としては理想。
そうなるように、よくよく費用対効果を説明して、お客さんに勘弁してもらうと、
後々双方とも幸せになれる。
（認証・認可を作りこむと、テストケースが爆発 ... の割にはユーザビリティ
の向上はごくわずか）
あと、JAAS の認証は多少融通が効きます。（３回失敗で５分ロックなど)
Glassfish、JBOSS なら既存の認証モジュールを参考に自作の認証モジュール
を作って差し替えることができる。
商用のコンテナの場合でも聞けば、やり方を教えてくれるはず。 >> 151
そういえば、Glassfishの商用版がなくなったらしいね
>>138
> ASP.netは安いものだよ。
> .NETが高いとか言ってるようではそのSIerのレベルは怪しい。
おれも、そう思うわ どうしてもJavaでなければいけない理由がないなら
フルスタックのフレームワークでやるほうがはるかに楽だよな
3大人気の、ASP.net、Ruby on Rails、Djangoあたりで
いろんなライブラリを組み合わせなければいけないJavaはめんどくさい
保守のコストもかかる フルスタック必要ならGrailsで良いじゃん。Javaの資産使えるし。 >>155-156
言語はJava8でいくらかましになるが、
まともなフルスタックのフレームワークすらないJava
Javaの痛いところつかれて反論できなくなって人格攻撃か
なさけない奴らだな >>157
Javaが嫌なら、スレから出て行けよ
スレタイも読めないのかこの池沼は ASP.netくんの言いたい「フルスタックフレームワーク」が何を指すのかようわからんが・・・
デプロイ環境からORM、View生成まで、ウェブアプリケーション開発に必要なものが全部
揃っているAPI Frameworkと言う意味ではJavaEEと標準実装であるGlassfishがそうだろう。
Rails風のCoC重視でコマンドラインも併用したRAD環境であればGrailsやRooがある。 >>160
GrailsはGroovyだからJavaと主張するには無理がある
GroovyなんてJavaの負の部分を引きずった醜い世界
JavaEEはWebアプリケーションフレームワークというよりライブラリ
「フルスタック」とはなにか分からないのもJavaしか知らないからだろうな >>161
>GrailsはGroovyだからJavaと主張するには無理がある
使ってから言えばよいのに。 >>162
Grailsは使ったことある
動作ももっさりだった
これでもJavaの中ではましなのかもしれないが
他の言語の人気フレームワークより使いづらかった
あと中身はSpringがベースでしょう
軽く触ったからそれくらはしってる ASP.netってVS無しでまともに開発できんの？
マカーでIntelliJユーザなんだが。 Glassfishって使い勝手とかどうなんでしょう？ ASP.netはスレチだが開発環境の広さという意味ではASP.netとそれ以外では歴然と差があるな。
JavaもEclipseが走れば開発環境は何でもよいという人も少なくないのでは。 Javaの開発環境の広さはスレチじゃないと思うが。というか実際何使って開発してる？ >>166
使い勝手を気にする用途に使ってるやつはいないだろう GlassFishが商用サポート切るとかたまったもんじゃないな
JerseyからRESTEasyに切り替えないといけなくなりそうだ >>179
Web Froms時代はいまいちだったけど
ASP.net MVCは最高だよな >>182-183
>>171-176のような無駄レスは文句をいわないくせに
ASP.netの文字が出ると感情的に批判してくるのな >>186
開発と関係ない板のURLはって馬鹿じゃないの？
少しはJavaの話でもすれば？ GlassFish使っててJBossへの乗り換えを検討してる所は少ないの？
JerseyMVCとか試そうかと思ってた矢先だったからなぁ 一生プログラマーでいたいならフルスタックとかで楽すればいいよｗ あんだけ某関係者の人がTomcatはオワコンこれからはGlassFishとかとDisってたのに
いつの間にかGlassFishの方がオワコンになっていたのか。
まあ、今もTomcat使って古いフレームワーク（StrutsとかSAとか）で動かしてる（爆）だからどうでもいいけど。 Java自体が終わりそうだけどね
ライブラリがクソすぎる Tomcatは起動が重いんだよな。
Jettyが軽くていい感じなんだけど、Tomcatに比べて日本語情報が少ない感じ。
JDBC使うのに、JNDI周りの情報も少ない。 ローカル試験で使う分にはWinstoneも軽くて良いですよ。
なにせjarファイル1個で動いて、160kbくらいだし JSON返すだけとかなら、Netty直利用とかも良いですよ。
まあ、ネタはおいといて、Jetty組み込んででExecutable WAR配布とか、利用側はお手軽で良いな。
Javaでもセルフホストしやすい軽量スタックとか、そっちが流行らないかな〜。 組み込みサーバー＋JavaFXは今後の選択肢として大いに有り得るらしい
JAX-RSとCDIが使えないほどの軽量サーバーならちょっと勘弁だが JAX-RSの実装もCDIの実装も、アプリケーション中に含めて組込サーバーといっしょに配布するで良いじゃん。 >>209
WildFlyってRHELとFedoraの関係なんだろ？
名前変えられると、テンション下がるわー むしろASがエンタープライズで使えない誤解すら生んだろうね JSFで画面作ってる時に、http://java.sun.com/jsf/core ってのを使うけど
これ、primefaceとかrichfacesと何が違うの？ 3年ニートしてる間にseasar2ってオワコンになってたのかよ
使われなくなるのって開発ストップしたからバグとかセキュリティホールが見つかっても
修正されないからって意味合いが大きいからなん？ 作りが悪いからに決まってるじゃん
名前が違うだけのspringだし
独創性がないから宣伝はspringの悪口だけ
目玉のHotDeployはバグバグで動かないのにサクサク開発()
とどめに後発のPlay Frameworkがもっと高い技術力とサポートで
同じようなことしてるからまるで存在意義がない スプリングググったらver4まで出ててワロタｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
初代スプリング触ったときゴミすぎで2度と触りたくないと思ったけど進化してたんだな SpringMVC、使いやすいよ。
RESTと親和性高いし。
もうこれ以外使うきしない。 javaしかやったことないから他の言語のwebアプリ状況がどんなもんか知らんけど
純粋にjava嫌いな層ってフレームワーク多すぎていろんところで開発スタイルバラバラすぎるからじゃねーの
勤勉でもないから触ったことないフレームワーク使ってるとお作法覚えるのもたりーんだよな >>222
javaやったことなくてそろそろ手を付けようかなと思ってこのスレ見てるけど、
設定含めすべてにおいてめんどくさそうだからじゃね。
もちろんフレームワークの選別とか作法とかも分からないってのはあるが。 めんどくさいというイメージはだいたいStrutsのせい 型コンバートやバリデーションをコントローラでやって
アノテーションつけまくる最近のスタイルが嫌いだ Convention over Configurationとかってまだ流行ってんの？ Java言語をマスタしても、フレームワークのお作法覚えないとダメだし
フレームワークも色々で、プロジェクトによっては勉強しなおさないといけないし
言語だけマスタしてた時に比べて、大変だよね。 >>227
Play frameworkは、さほどCoCにこだわってないように見えるね。
ルーティングは、routeファイルに必ず書くし。 >>228
チームで開発するときはアーキテクトさんが更にもう一枚「オレオレフレームワーク」でくるんで使わせるのではないか？
設定ファイル等々にしても集中管理するから末端プログラマが触る機会なんてないはず
プログラマに素のままのフレームワークを使わせるなんて危険すぎるが 一周まわって、フレームワークなしのサーブレットに、必要最低限の機能を持つ基底クラスだけ自分で作って使うのがベストだと思う。 >>230
オレオレ作った場合、プログラマに使い方を説明してる？ >>232
APIドキュメント、サンプルプログラム、コメント付き各種設定ファイルなど一通り揃えて、取り合えずば簡単に動くものを用意
説明用の資料パワポや説明会は必要に応じて。 更新止まったActiveObjectsやBeanKeeperの後継とかなくて
結局JPA + Hibernateに落ち着くのか JAX-RSはフォームデータを渡した場合は@FormParamで受け取るしかない？
Servlet感覚で可変のフォームデータを受け取ってパースしたかったんだけど… アノテーションもりもりMVCとかO/Rマッパー考えたやつはセンスないな
素直にServletとJDBCで十分じゃまいか servletでmemcached使いたいんですが
MemCachedClient mcc = new MemCachedClient();
mcc.set("name", "Naoki Takezoe");
ってやったあとmccのインスタンスはどこにしまっておけばいいんですか？ >>238
開発者が100人位いるような大規模開発だとどうするの？
皆が勝手にConnection.prepareStatementとかやるわけ？ 案件規模とかそういうのはどうでもいいんだけど、
IDEの恩恵に頼って楽してコード書きたいから、そもそも今更自前でSQL書きたいとは思わないな。
あの書きづらい読みづらい、毎回同じような記述するだけのSQL文を構築していく作業って、
なんかこうテキストエディタでコーディングするのが好きな人向けな感じ。
あんなものは、パフォーマンスチューニングが必要になってから、必要最低限だけ書きゃいいのにな。
それにServletとかJDBCみたいなクソ仕様は、二度と触りたくないなｗ
あのあたりは、なんかもうかなりレガシーコードの塊になってしまってて、時代に沿ってない内容になりすぎてる。
インターフェイスの設計に失敗してる箇所が多くて、ラッパー噛まして使うのが前提みたいな状態。 Seasar2はSAStruts+S2JDBC、S2JUnitくらいしか触ってたことないが、
- ドキュメントが総じてクソい、ほぼメンテされてない
- できることが少ないわりに何パターンかあったりして説明が乏しい
- フォームのバリデーションより先に処理を挟みたいなら有志の拡張かフィルター使うしかない
- 設定ファイルを減らすための命名規約の呪いがパッケージを強要したりクラス名を制限したりしてくる
- JPA実装してるけど一部しかサポートしてない
- 自動投入用のテストデータのフォーマットがExcel
- おまけにキモっぽいHotDeployはバグ多すぎ
殆ど良かったイメージが残ってないな。
最近なら、Servlet使うならSpring、使わないならPlayの2択でだいたいなんとかなりそうな気がする。 >>241
大企業の基幹システム開発なら100人規模なんてザラ >>245
そういう案件だとザラだけど高確率で炎上じゃね
そんなに人使う必要がある時点で発注側にも問題アリだよ >>246
どんなに大規模な基幹系でも、高々10人、20人程度で開発しきれるはずと申すか？ RDBでSQLのWHEREを書かないで、KVSみたいに全部javaで書くライブラリを作ってみる
http://ideone.com/4FZZeN 何でみんなそんなにSQLを嫌ってるの？
SQL書けばええやん。 同意。
トラブったときはSQLのほうが圧倒的に楽
昔Hibernateで痛い目にあった。。。 apacheのdbutilsが程よくJDBCをラップしてくれて好きだった
DBアクセスは自分でSQL書く方が好み
どっちも個人的な好みだから他人には強要しないけど くだらない問い合わせはORマッパー通した方がくだらない間違いも起こりにくいだろ
複雑な問い合わせだけはSQL直書きするようにすればいいだけやん
目糞鼻糞だけど SQLで書けば、コード量は多めでも、読解難度は低い。
ORMを駆使すると、コード量は少なめで、読解難度が高くなる。
他人が書いたコードを引き継いだ時に殺意を覚えるのは、後者。
特に、とっくに廃れたORMの場合。 流れるようなインターフェース()の悪口はそこまでだ
ｵﾚｵﾚ色が強いと大変ね おまえらはORマッパーが出来た背景を少しは調べたほうがいい
2、3人で開発するなら知らんけどそれなりの規模で大量のオナニーSQL文見せられてもかなわんだろ Oracle使った時SQLは全部ストアドに書くとかやったことあるわ
SELECTのReturnはXML
あれもある意味O/Rマッパーなんだろうか SQLをまったく意識しなくてよくなるようなまっぱができれば使いたいが O/Rマッパー黎明期から期待に胸を膨らませて追っかけてきたけど
保守段階までトータルで見ると、少なくとの日本の人月ベースで
コスト計算する業界では見合わないと思ってる。
初期HibernateのHQLなんかも設計思想はものすごく好きだった。
Torque、Castorなんかも試した。Torqueはクラス数が爆発しがちで
仕様がコロコロ変わる案件で地獄をみた。
Cayenneも良かったな。旧NeXT製のEOF(Enterprise Object Framework)
なんかの流れを彷彿とさせる設計は美しかったが、
日本ではマイナーで使える技術者が育たず広がらなかった。
とはいえ、素のJDBC使うのはめんどいし、もはやS2系は死んだ。
個人的に残された希望は枯れたMyBATISくらいかな。
SQLの透過性とシンプルにも使えるO/Rマッピングの融合がバランスいいよ。 業務アプリなんかだと結局メイン部分はパフォーマンスや
堅牢性が大事になってきてSQLで書かないといけない。
まっぱが使えるのはマスタメンテくらいになる。
マスタメンテくらいのSQLなら別に複雑でもないからまっぱにする意味もない。
つまり使い道が無い。パフォーマンスや堅牢性も備えてはじめて使えるようになる。 だよな。複雑なビジネスロジックをオブジェクト操作で
動的にSQL作るような仕組みだと、仕様変更とかバグ修正の場合に
マジックハンドでモノを掴むみたいな感じになるよ。
SQLならものの数分で終わるような対応が丸一日かかったり。
ただ、O/RマッピングとSQLの動的生成は違うものだから
ここは混同しちゃいかんな。
生JDBC使ったって最後はbeanにマッピングされるわけだし。 JPAは再帰処理がないのが不満に思えたが
昨今の大規模環境ってJOIN禁止ルールとかあるみたいだし気にしなくていいのかな？ JOIN禁止ってマジ話？
そんなプロジェクトに放り込まれたらプロマネ殴り倒す自信あるよ 一部のコンシューマーサービスにおける設計の話を一般論扱いされても。
それにむしろ、そういうケースではMicro-ORMだろうし。 指定数表以上の結合禁止、右外部結合禁止は見たことあるが、
結合そのものを禁止しているところは見たことないな。 まあ将来的には結合なんてしなくてよくなるのが理想だよ。
だからまっぱは理想なんだけど今のハードではまだまっぱには無理がある 逆だろ、将来的にはいくら結合しまくっても性能が劣化しないのが理想だよ 結合時の性能劣化がなくなるよりも先にＲＤＢが廃れそうだなｗ 抽象度が高くかつ表現力のあるマッピングAPIが、現状の言語仕様やHW的な限界で現実的ではないという話と、
リレーショナルモデルを相手にする以上、結合を考えないなんて意味がない話だし、本質的に性能劣化は発生する
みたいな話が混在してね？ ソーシャルゲーム業界だと、たいがいJOIN禁止だな
詰めSQLやるようなチューニングはしない
大規模構成のMySQLをmemcachedとあわせてKVS的に使ったりって感じ
大規模にサーバまたいでデータ結合やったりするからJOINなんか使ってたら
保守できなくなる ORM使いにくいって感じる状況、ORMへの知識不足が原因じゃなけりゃ、
大元のDB設計とかがいまいちだったりする感じのこともけっこうありそうな
そもそも、言うほどパフォーマンスに問題が合ってSQL書かないと行けないような自体って起きるかなぁ
そういうのって、どっかうまいこと作れてないか、
体感できない性能差を突き詰めたいだけでチューニングを行なってる人かのどっちかってことも少なくない気がする ORMはEager fetch, Lazy fetchの問題を解決不可能なんだよ >>277
DB設計が大元ってｗ
ORMを理解してないのはお前だろ
ORMを使う動機はドメインモデルをRDBに永続化することなのに
なんでDB設計が先にくるんだよアホかｗｗｗｗ
ていうかみんなわかってなさすぎｗ
テーブルモジュールで設計していながらORM語ってんだろ？ｗｗ >>279
世の中の全てがモデルファーストでシステムを全て作れるわけではないし(そんなの本当に新規開発だけ)
パフォーマンスのために非正規化したりテーブル設計を崩すこともある
他システム連携があったりすると、そのDBにアクセスしてくるのはJavaだけとは限らない
もうちょっと世の中でいろんな経験をしてごらん。
見えなかったものが見えてくるよ 次の仕事でPlay使うかもしれんとここ数日予習してるんだけどさ、
何か凄いstaticだらけで違和感覚えるんだが、
これはこういうものだと思って慣れるしかないの？
テストとかしずらくね？
工夫すれば一応DI使えるみたいだけど、entity注入するのはそれはそれで変な気もするし… 常に新規開発でDBを好き勝手やれるならそもそもこんな話してないわ
システムリプレイスするけどDBはそのままとか
DB設計は他社とかそんなんばっか
>>281
Playはそういうもんだと諦めたまえ >>282
サンクス。気にはなるがやっぱフレームワークの流儀に従うべきか…。 Javascriptに対してGAEができるなら
ORMにも似たようなのないの？ プログラミング言語「Hack」登場 - 米Facebookが発表
http://news.mynavi.jp/news/2014/03/24/416/
動的な型付け言語がもたらす開発の手軽さと、静的な型付け
がもたらすエラーチェックの完全性の高さなどの双方の利点を
得ることを目指して開発されているという。
これはJavaより有望かもしれない ああほんと。電動歯ブラシぐらいのエロティシズムを感じるよ
Oculusなんて買収して、どんなイノベーションを見せるんだろうね Javaのスレとしては、というかPHPのスレ以外もれなくだと思うが
まずPHPをベースにするのをやめろと言わざるを得ない facebookが内製用に使うぶんには有効なんだろうけど
こういうのって外部の開発者が採用しても
大抵の場合はメリット出ないよね CGIレンタルサーバーの都合(安さ)を考えて
Java, C#をベースとした言語から => PHP, Perlに変換するとか
そういう話ではないんだね Seasar2を使ってるところってもうないの？
新規案件ではSeasar2は選択肢にも入らないのでしょうか？ そんなもん使うぐらいならStruts使えって言われる Seasarプロジェクト自体がもうオワコンだしねぇ。
今後を見据えたら、Java8でSpringでしょ。 出来が良い悪い以前に日本のプロダクトは長続きしないな この記事最近のだけど今頃脱Strutsとか言っててちょっとポカーンなんだが
保守作業とかならわかるが新規プロジェクトでいまだにStruts1.x系選択するところとかあんの？
SAStrutsっていうならわかるけど書いてないし
ttp://gihyo.jp/news/report/2013/09/1901?page=1
Seasar2ってORMデフォルトでついてるからなんだかんだ言って開発しやすい 新しいフレームワークは分からんとか言われて去年Struts1.3で作らされた 脱Struts→HTML5
SIer的には物凄くハードル高いと思うよ。
HTML5と一口に言っても、その意味が内包している
要素技術って膨大だからな。
これからはHTML5だ！と鳴り物入りで一度は方針転換したのに
サーバーサイドでHTML生成するような実装してた開発者が
クライアントサイドでDOM生成する実装に馴染めず
結局モトサヤでStruts使い続けてる会社いくつも知ってる
バックエンド開発とフロントエンド開発で体制分けたのはいいけど
コミュニケーションロスやお互いの作業待ちでスタックしまくる
プロジェクトとかも。
プロジェクト管理や設計のやりかたが今までと同じで
それを変えられないってのがうまくいかない最大の要因な気がする。 まぁそれも１つあるよな。
業務アプリに見栄えのするUI/UXの必要性なんて
そもそもユーザーが求めてないわけだし。 用途によるよ。
業務アプリと一口にいっても、グリッドとフォームだらけのLOBアプリならJSFで良いし、
それとは別に情報ポータル/分析系みたいなものもあって。
後者については実際ソーシャル系みたいなニーズが求められるから。
っとSI屋で後者をメインにやっている人より。
つーか、前者みたなものをシコシコ作っていて、何が楽しいんだと思ったりはする個人的な意見ですが。 前者みたいなの作ってて楽しくもなんともないけど仕事あるだけマシと思ってる やっぱり今から勉強するならspringが無難だよね。 >>313
お前、お前みたいな奴が、お前な、マジでお前
お前ーー！ http://gihyo.jp/news/report/2013/09/1901?page=2
>>301の記事に２つの方法が書かれているけど
それぞれのメリット、デメリットはどういう感じなの？
「次世代型」はJavaScript有効化必須として
開発の生産性はどちらのが上？
「Oracleエバンジェリストの寺田氏は，Java標準によるWeb開発を，
次世代型と従来型の2種類に分類しました。
次世代型：クライアントとサーバ間をデータのみで通信し，画面の
生成から表示までをクライアントで行う方式。
従来型：サーバ側でデータを埋め込んだ画面を生成し，クライアント
では表示のみを行う方式。」 >>317
次世代型って>>303みたいなの？
今の時点での生産性なら従来型じゃね
次世代型とか慣れるのに苦労しそう >次世代型：クライアントとサーバ間をデータのみで通信し，画面の
>生成から表示までをクライアントで行う方式。
Oracleの中の人ですら、まだこんなこと言ってんだもんな。
認識の周回遅れも甚だしい。
そりゃ日本のSIerが斜陽産業化するわけだわ。 >>318
>>317のURLに書いてある「次世代型」。
生産性が低いなら海外で人気になったりしないと思う
なんで日本だけStruts使ってる化石企業ばかりなんだろう
両方とも経験ある人の意見が聞いてみたい。 XML+XSLTで昔からできたのに全然普及しなかったな >>320
Oracleの中の人の認識だと、まだajax使ったREST+JSON止まりなんだろう。
もうすでに、pjax+pushStateがメインで、今までのjsonベースの仕組みは
補助的に使う感じの動きになってきてる。
特にクライアントがモバイルの場合、SPA構成だとpjax+pushStateにしないと
いろいろ画面遷移周りの実装が複雑になりがちだし、
業務アプリ以外の外向けWebサービスなんかの場合は、サーバからJSONだけ
返してもらってクライアントでDOM生成する設計だと、SEO対策的にも高コスト。
とはいえ、イントラ系業務システム限定なら、REST+JSONでも何ら問題ないけど
だったらStruts1.x（）でもいいだろって話になる pjaxも所詮RESTじゃん
JSFと違ってJAX-RSにVIEW実装なんて定義してないぞ 次世代型って要はAjaxとJQueryでUI手書きかGWTってことでしょ。
旧来型には、javascriptを隠蔽するJSPタグライブラリとか
Wicketコンポーネントなんかがこちらに含まれるのかな。 >>323
元々PushState + Ajax = Pjaxじゃねーの？
そのPjaxにもう一回PushState加えるってどういうことだよ？w 10年前からメンテしてるサイトは素のServlet/JSPで作ったが
流行に乗ってstrutsとか導入しなくてよかった。
長期開発・運用だと技術スタックは小さいほどいいね。
仕事だと「最新の開発手法」とやらの圧力が高くて抗えないけど・・ Servlet使ってるところのソースは大抵糞コードだから読まされる立場だとうんざりするけどな このスレっていつもループしてるよね・・・
適当に上の方へ戻っても話がつながって読める >>325
jQuery手書きは旧世代だね。
AngularJSはjQuery使わないし、Backbone.jsでもテンプレートエンジンや
Marionettoとかのプラグイン使えばjQueryは隠蔽されるのが現世代。
AngularJSやBackbone.js使えば意識するまでもなくPushStateも使われるんだが、
>>323は何を次世代だと言ってるんだろうか？
ブラウザ側から見た新世代はWebComponents抜きには語れそうにない。
SEO含めた取り組みはRendrのやり方が新世代になりそう。 Oracleの人は立場上、自社のJava EE7を推したいわけでしょうから
Java EE7標準を使った開発が、オラクルの言う「次世代型」でしょう
>>323
＞だったらStruts1.x（）でもいいだろって話になる
よくないでしょう
>>301の記事内でも指摘されているように
セキュリティ上の理由で、メンテナンス終了したStrutsはもう新規に使えない。
>>331
Javaはいろいろやり方があってわけがわからないよ
その辺の新しい開発方法をわかりやすくまとまめてあるサイトや本は
ありますか？ phpだとcakephpが個人・学生から企業まで定番化してるっぽいけど
jsf2とかspringmvcがその地位には立てそうにないなー >>332
わけがわからないのはJavaじゃなくてJavaScriptのことだと思うけど、
とりあえず一つ追っかけるなら、今だとAngularJSがいいんじゃないかな。
読んでないけど日本語の本も一つ出てるし、来月にはオライリーの翻訳本も出る予定。 JavaScriptは、後から後から話題になる要素技術がどんどん出てきて
トレンドが変わっていく
アメリカではそういうの自分たちでどんどん作って送り出すけど
日本じゃそれを表向きはドヤ顔で、内心ヒーヒー言いながら追いかけて
疲弊するだけ
不毛すぎる そろそろ表向きドヤ顔もできない感じになってきたわ
Webアプリやりたくねぇよ Web系はドヤってなんぼだろw
黙々と作業だけしてたら底辺臭が滞留してきちゃうからね 去年辺りまではbackbone.jsがオススメされて
今年はAngularJSがはやってるよね
来年はまた別のものが流行して
再来年にはまた別のトレンドが来る
一貫してるのはなんだかんだでjQueryがデファクト ドヤ顔で講釈垂れてもな・・・
職場の人間は正直だと思うぞ >>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を出したからって日本人がみんなそう思わないのと同じで。 jQuery以外はdartでも触ってたほうが良さそう こういうの見ると、継続的なサポート力というのは重要だなあと。
5年後はすたれてそう・・みたいなフレームワークへの依存は避けたい・・
Apache Struts2 脆弱性に注意、IPA
http://news.mynavi.jp/news/2014/04/18/139/ Struts2は後年にフレームワークの歴史における失敗作として語り継がれそう
やはり兄より優れた弟など存在しないんだ 正直もうJava EE一本化でいいんじゃないのか
標準だからStrutsやSeasarみたいに数年でオワコンにはならんし アクションベースのWeb FW、モダンなテンプレートエンジン、Micro-ORM
…を熟れるレベルまで標準化してくれるなら、そしたらEEでも良いよ、
っという意見は昔からあるけどな。 NodejsやAngularJS使っている開発でyeoman入れている人いる? 例えば、Strutsを避ける
http://www.scutum.jp/information/waf_tech_blog/2014/04/waf-blog-036.html
Struts2は根本的設計がまずかったり今のメンテナにとって
やる気のでないプロダクトだったりって状態なのかねえ
SIerが貢献することもなく使い続けて情報漏洩しまくらないといいが
>>349
JSの話題はここでは返事もらえないと思うよ node.js使ったサーバーサイド開発やってるのに
未だにJavaとJavaScriptの違いが解らないアホがいるってのが驚きだわ >>350
そのエントリ書いた人、StrutsとStruts2は全くの別物だってことと、
Struts2は少なくとも日本じゃポピュラーじゃないってことを知らなさそう 今更?。Struts2は出た当初から致命的な脆弱性がある欠陥品だと言われていたでしょ。
MBSDで暫定的なものであるが、サーブレットフィルタのソースコードを公開したよ。
http://www.mbsd.jp/img/testFilter.java 最近、JavaEEやspringMVCからJavascriptへ
トレンドが移行している印象を受けるね。
JavaSE8もあまり話題にならないけど、どうなの? 【IT】サイト構築ソフト・ストラッツ1(Struts 1)に欠陥 パッチなく官公庁などサイバー攻撃の恐れ [4/24]
http://ai.2ch.net/test/read.cgi/newsplus/1398347971/
Struts 1.x使っていた時代遅れ企業終了
>>354
その印象を持ったのはどういう理由？
Java開発案件が減ってJSが増えてる？ >>355
開発案件に影響は出ていないが、技術的な部分が日進月歩なので表面化しつつある。
WebがHTML5に向かう中で、Javaが担う機能を、どこまでJavascriptで
担えるかというところで微妙になってきた。
基幹業務システムをJavascriptで作る時代がきそうだと。 乱暴に言えば基幹システム＝DBアクセスだから、サーバサイド開発をゼロにするって無理だろ
JavaScriptから直接SQL叩くことを許可するのか？ >>357
クライアントではなくてサーバーサイドJavascriptの話をしているのだから
それ的外れな指摘だよ
>>356
Javascriptって、もともとDOM(xml/html)を操作して
画面UIを操作するためにあるような、それくらいしか能がない言語でしょ。
サーバーサイドには機能面で非力すぎるし、また独自仕様乱立とか始めるのがオチ。 >>356
＞基幹業務システムをJavascriptで作る時代がきそうだと
これは絶対に来ない
もし基幹業務をJSで作ったとしたら大バカ企業
動的言語は大規模開発だと開発生産性が落ちる。
このデメリットが大きいからFacebookなどもPHPを
静的言語に魔改造しようとしてきた。
JavaがゴミみたいなWebフレームワークしかないのに
大規模サイトで使われてきたのは、静的言語で、
ライセンスが比較的自由だからだろう サーバーサイド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を使えば解決できる。 JavaScriptもこんな流行るとは思わんかったよ node.jsでサーバー書くより
ブラウザでjavaなりc#が動いてくれたほうがよっぽどありがたい >>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がブラウザに乗れば一応それらに近いんじゃないかな あと動的言語かどうかはもちろん、生産性も基幹系で使うかどうかにはたいして影響ないよ
今基幹系で使われてる言語でもCやCOBOLは弱い片付けの言語だし生産性も高くない
それよりベンダのサポートとか人の集めやすさとか世界中で使われてる実績とか
技術とは無関係なところで決まりやすい(それを肯定したいわけじゃないが現実としてね) >>365
大規模開発での静的言語の優位性を否定するとかありえないわ
それとベンダサポートが重要なのはそのとおりだが
人気のある静的言語ほど大手のベンダーが関与してる割合が高い
C#もJavaもそう
動的言語はコンパイラ開発不要で個人レベルでも
作れるからOSSで言語が乱立する
頻繁に不要な仕様変更が入りメンテナンスコストが高くなる
開発生産性というのはバージョンアップなどのコストも含めての話 >>366
優位性を否定してるんじゃなくて、その優位性が重要な要素とはならないって言ってる
まぁ、スレ違い気味だしわかれとはいわんよ >>363
silverlightやアプレットやってた人間からすると、それは絶対やだ。 動的言語ってchar1単位で操作したりするの向いてないだろ
もうjavascriptを使うこと自体が目的化してるんじゃないか？ >もうjavascriptを使うこと自体が目的化してるんじゃないか？
フロントエンド系やってる連中は、そんなことを目的にしてたら
デスマーチの深淵に落ちていくことくらいよく解ってるよ。
あいつらはいかに楽をするか自動化をするかってところが目的になってる。
「結果的」にブラウザ上でJavaScriptを動かすために
ローカルPCに仮想環境突っ込んでvagrant, chef, yoemanとかで
環境作って裏ではRubyが動いてたりもうカオス。
でもこの環境構築自体も今やコマンド一発とかそんな世界。
一部分では下手なサーバサイド開発よりも楽できる世界が構築されつつあるが
Webアニメーションとかやってる連中は相変わらず死んでるな。
Androidという魔物に挑んで力尽きていくやつらの亡骸が山積みだ。 そもそもweb系でバイト単位の操作をすることはそんなに無い。
仮にそういうのを意識しないといけないことがあっても大体ライブラリでカバーできてるし。 サーバ側でjavascriptを使うことがメルヘンなのだろう >>371
アプリケーション層で自由度の低い言語ってありえないだろ
構文解析コンテンツとか作れないじゃん
javascriptはかなり貧弱だから
頻繁に他の言語で実装されたプラグイン呼ぶことになる
そもそもjavascript自体が嫌われているのに
UI層と同じ言語を使いたいという動機だけではデメリットのほうが多いよ Google Apps scriptとか技術的にどこまで応用されるのか
見極めないといけないね。 >>373
node.jsだとバイナリデータも扱うこともできるみたいだし、自由度が低いってことは無いと思う。
というか自由度を求めるんなら極端な話Cで全部書けばいいんじゃね？
用途とか目的とかコストとか考えた時、自由度はある程度切り捨てられるものだ。
サーバーサイドでnode.jsやらを使う利点は、学習コストが極端に低いこと。
なんせweb系やるならjavascriptはほぼ必須だから。
とはいえjavascriptで組みたくないってのは同意。 altJS系の動きも、JSをサーバサイドで使うことより
もっと大規模開発に向いた言語でフロントエンドやりたいって人が多いと思う
結果的に1言語で十分になるならいいことかもしれんが ポストJSはDartが一番良さそうだけど（Javaのブラウザ用サブセット同然）
IEのシェアが圧倒的だから、googleの思惑通りにブラウザから
直に動かす言語としては普及させられない
代わりにMSがTypeScriptあたりをごり押しで普及させてくれれば良いのだが
あそこは相変わらず意味不明なことばかりに力を入れているな CoffeeScript, TypeScriptを仕事で使ってみて
結局素のJavaScriptとjQueryに戻ってしまった 今のWebはごちゃごちゃ流行りものをやりすぎなんだよとしか言いようがないな。
大体どれも3年後、5年後には失笑されるような技術ばかり。
実験プロジェクト的なものがこの世に存在する意義はあると思うけど、
それらの拙速な製品への適用はほんと愚かだよ。 ファッションやら家電に車とかで、今これがすごい！流行りはこれ！
みたいにブームを作って商売するのがこの界隈にも増えただけだと思うわ。
HTML5なんかまさにそれだと思う。
需要喚起って意味では良いのかもしれんが完全に手段が目的になってる気がする。
金稼げないと飯は食えんけどさ。 Javaだってそうだったじゃん
Jakartaとかから次々と流行り物が出てきてJavaWorldなんかで特集されてみんなおっかけてたじゃん
Strutsだってそうやって流行ったものじゃん 土台となるjavascriptちゃんとしてればいいけど
phpがjavaの後追いしてるのと同じ不毛さを感じる 例の脆弱性で、ようやくStruts1からの脱却が進みそうですな。
周りの人に聞いてみると、JavaEEが次のフレームワークのファーストチョイスっぽいね。理由は「標準」だかららしい。それじゃOracleの思う壺ですけどね（笑）
OpenSSLの事もあり、OSSのソフトウェアをなるべく避ける風潮が何と無く社内にあり、開発がやり辛くなりそう。 今はJavaEEかSpringの2択のところが多いな。 NEC製のオレオレフレームワーク使わされそう
ググったらオープンソースのフレームワーク組み合わせただけの糞なんだけど
これをIDEとして売り物にしてるっぽい。独自開発環境なんて開発工数減らすどころか増やすだけだろ
マジあほ その手の国産オレオレフレームワークって
たいていなんかの開発案件で使われたものを
「これ、ヨコ展開して製品化しよう！」とかって
上層部が思いついて出来上がる気がする
変にオープンソースをベースにしてたりするから
無駄な初期学習コストが出ちゃうのと何かあった場合に
コミュニティが蓄積してきたノウハウが使えなかったりして困る 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
なにかアドバイスがあればください。お願いします。 >>389
サンプル作って比べるなり評価すればいいじゃん。
JSFについてはJSFがやらなかったか、Java EE自体はやらなかったのため。 >JSFについてはJSFがやらなかったか、Java EE自体はやらなかったのため。
いや、このスレッドで、話が出ていないんすよ。
ctrl + f →JFS 以前にＪＳＦの専用スレが立っていたはず。過去ログ探してみ JSF2.0でprimefaces使うと確かに
簡単に結構リッチな画面が作れそう
ただJSFは仕組み上
サーバリソース食うんで利用者が多いような
サイトには向かない気がする
EE6だと
JAX-RSとjavascriptか
JSF2.0で画面作るんだと思う
前者は大変だがユーザー数だとか作り込む上で制約が少ない
後者はサクッと作れるが制約が多い
といったイメージ
間違ってたらごめん >>391
JSF2 は、ジェット戦闘機の時代に登場した、最強のレシプロ戦闘機っていう感じですかね。
JSF2 は、サーバ側で HTML を作る、Struts、JSF1、Tapestry、Wicket... などの旧来型の
Webアプリの集大成。
でも時代は、クライアントサイドで MVC が完結して、サーバーサイドは API に特化する
という方式に移りつつある。
移行コストが問題。従来型の Web アプリでいいなら、Servlet + JSP の延長線上にある
Spring MVC でいいかとなるし、どうせ新しいことを覚えなきゃいけないなら、
ExtJS + Rest API でやろうかねとなる。 JSFって、戻るボタン押したらログイン画面に飛ばされる奴？ 以前SIerで企業や官公庁向けのWebアプリ開発の仕事してて
今はコンシューマ向けWebサービスの開発してるんだけど
SIerはほんと進歩が無いんだなと感じる。
もっとも、常に「枯れた（安定してる）技術」が重要視される
業界だから、進歩させる必要はないのかもしれないけど
開発者にとってはつまらないんじゃないか。
世間では叩かれまくってるソシャゲ屋なんかは、使ってる
要素技術や仕組み的にはけっこう最先端が多い。
どんどん新しいものを取り込んで実装していく。
不安定なものもあれば、すぐに廃れていくものだったりするんで
これはこれでリスキーだけど、サービス寿命は短いから
これでもいいんだろう。 結局ここでJSFやらJavaEEもおっけーってことかな
スクリプトゴリゴリ書きたくないから
個人的にはJSF2に頑張って欲しい >>397
業務アプリにとっての「技術」は目的ではなく手段に過ぎないからな
目的が達成できるならレガシーな技術で十分
先端追いかけてくれる人たちがいるお陰で、周回遅れで安定した(枯れた)技術を採用できるとも思ってる
確かに技術屋には魅力はないだろうが、そういうもんだろう >>400
最新の技術に拘る訳じゃないが
新しい方が品質、生産性が高い場合もあるんじゃないかなぁ
学習コストっての問題はあるが・・・ >>401
あると思う。
でも数多ある新技術がすべて宣伝通りのレベルに達しているかと言うと、期待はずれの技術もまた多いわけで
その辺はイノベーターさんやアーリーアダプターさん達の成果に頼ることになる JavaでいうとServlet+JSP以外信用できない
フレームワークは穴だらけ
新しいものは信用できない struts普及しすぎたせいで未だにstruts使ってるところ多い感じだ
ドヤ顔で独自フレームワーク開発してますとかほざいたくせにベースにstrutsとか寝ぼけてんのかよ strutsは普及しすぎたが故の脆弱性問題かね
OpenSSLといいIEといいこの手の話最近多いけど
他が安全っつうよりはマイナーなだけな感じ
ただオレオレFWが結局同じ問題を抱えてて
各々対処しないといかんのはダサいね
じゃあjavaEEなのかと言うとよくわからない
標準といえど旧EJBのような失敗作もあるし フレームワークは使ってるってだけでドヤ顔できるかな >>400
日本で業務系アプリやってる奴らは
周回遅れどころか10年以上遅れてるだろう
リリース後に1年もたてば十分に安定した技術になる。
ただ時代遅れで新しい技術についていけていないだけなのに
「枯れている」などという言葉で正当化しようとする
フレームワークの有り無しを論じていたり、Strutsがどうこうとか
日本だけ時間が15年くらい止まっている感じだな >>407
どうした？業務アプリに親でも殺されたのか？ 企業の場合、フレームワークにノウハウを詰め込んでる場合が多いから、土台が古くなってもなかなか変えられない。
下手に変えるとエラい目に会うからな。 ＞strutsは普及しすぎたが故の脆弱性問題かね
JSP系統全体の脆弱性じゃないの
Velocityとかで同じようなことは大丈夫なのかな OGNLとかBeanUtilsとか個別の要素のバグや仕様だから同じことしてたら問題はある 欧米だと、業務系アプリでもどんどん新しい技術採用してるのにな
バックエンドはSpring+MySQLやnode.js+MariaDB、フロントはHTML5ベースで
backbone.jsやAngularJSにしてREST-APIで繋ぎ、サブシステム連携も充分とかさ >>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年初版でした。 asp.netもasp.net MVCっていうサーブレットチックなものが主流になってる。
asp.netもjsfも柔軟性にかける割に生産性もそこまで高くないんだよね 生産性が低いとは思わないけど、まあ、ぎょーむ屋さんがつまんねーLOBアプリをシコシコ作るの専用感はある。 Struts2+Spring DIでStruts2のActionにDIするWebアプリケーションを作ってる。
このアプリの実行時に、DIされるべきフィールドがnullになっててヌルポが発生することがある。
アプリをコンパイルしなおしたらヌルポが発生する場所が毎回変わったりするので原因がよく
わからない。
Tomcatが利用できるメモリ容量を増やしたらヌルポが発生しなかったので、DIに必要な
メモリが足りないのが原因かと思ったんだが、そういうことってありうるのかしら？
みんなTomcatのメモリ容量はどのぐらいにしてる？ >>414
asp.net MVCがサーブレットと同類のわけないだろ
お決まりの処理は最小限のコードで書ける
ASP.net MVCの生産性の方が圧倒的に上
>>413
掌田 津耶乃の本はやめておけ
いろんな言語のフレームワークの本を書いているがどれも評価低い
内容が薄っぺらい、同著者のamazon レビューを見たほうがいい
＞これ以外に、どうして売っていないのか不思議です。
理由はJavaの技術は定番がなく分散してるから
膨大な時間をかけて本を書いても売れない、儲からない
日本語で書いたら日本人しか買わない
どうしても本で学びたければ英語で書かれたものを探したほうがいい >>416
いまさらStrutsとは
ヌルポにメモリが関係あるわけないだろ
物理メモリが足りなければ、HDD/SSDなどの仮想メモリが使われる >>418
うん、おれもStruts使いたくない。
やっぱ関係ないか。再現条件（ヌルポの発生場所）がころころ変わるんで悩んでる。
DIされるべきところがnullになるケースってなんかない？ Spring使ってるのになぜStruts?しかも2とかありえねぇ。
馬鹿なの？アホなの？死ぬの？
SpringMVC使えよ。 決定権がある人間が無能だと
こうやって現場が疲弊する見本だな
中途半端に要素技術を聞きかじってると
こうなるよな >>419 OutOfMemoryErrorをどっかで揉み消してるとか
>>418 PermGen上限を緩めてないなんてのはありがち >>420-422
お察しのとおり、途中から参加したプロジェクトなんで変えようがない。
Spring使うならSpringMVC使え、はもっともなんだろね。
>>423
MaxPermSizeを大きくするとヌルポが起きないので、そこかなーと思ってる。
OutOfMemoryErrorのもみ消しはしてないと思う。 やっぱTomcat使ってるとこ多いよね
javaEE にするならTomEEでいいかな？ Tomcatで十分だろ。意味わからん
オレオレアーキテクトのオレオレフレームとオレオレコンテナとか誰得だよ 将来が有望なWEBアプリのフレームワークって？
JFS2を推したいのだが・・・
他の技術では、HTMLを噛むのでコードが煩雑になりはしないかと躊躇する HTMLをサーバ側で作ってレスポンスに送り出すのか
サーバからは必要な情報だけJSONとかで取得して
ブラウザ側でDOM生成するかで何を使うかが変わってくるな
HTML自体の修正が必要な場合は、個人的好みとしては
後者のほうが修正から反映までの手間が少なくて好きだ。
サーバ側でやると、サーバ側もデプロイしなおしとかあるし >>429
>ブラウザ側でDOM生成する
せっかく、ASP.NETは、サーバー側で要求を受け付けて処理してHTMLを出力するうまい方法（抽象化されたサーバコントロール）を、
実現していたのに（JFS2みたいに）、今からはブラウザ側がHTMLを自分で作成するのですか。
ブラウザ側でHTMLをコントロールするタイプなら、
何が推しですか？
そういうタイプWEBアプリって、サーバーは基本的なプログラムとデータをクライアントに提供して、
クライアントがその基本的なプログラムを処理することで適切なHTMLを自分で組み立てる感じでしょうか。 >>432
ブラウザ側でいろいろやるのは別に良い方法というわけじゃないよ
ただJavaの世界ではサーバサイドのフレームワークが
ろくでもないものばかりだから、そういう開発をやる人が出てきただけ
ASP.netやASP.net MVCに比べると開発に時間もかかるし
ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
セキュリティも低下する >ASP.netやASP.net MVCに比べると開発に時間もかかるし
>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する
いまどきの大手SIerって、こういう時代遅れタイプで占められてるんだよな
だからStruts1が幅を効かせてきたわけだ >>433
>ただJavaの世界ではサーバサイドのフレームワークがろくでもないものばかりだから
>（ブラウザ側でいろいろやる）そういう開発をやる人が出てきただけ
結局は、消極的な理由なんですか。
近年のクライアントのパワーが上がってきたことと、
サーバーの負担を減らすために、クライアントサイドでhtml構成作業を行うようになったのだと思っていた。
あと、ポストバックをなくすために。
>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する
ブラウザ環境で意図した動作をしないというのは困りものだな。
うーむ。
だったら、サーバーサイドのフレームワークとして、JFS2.xに期待するなあ。
なんだって、JDKの標準機能に組み入れられたのでしょ。
JFS2には将来性があると思う。 >>417
>理由はJavaの技術は定番がなく分散してるから
>膨大な時間をかけて本を書いても売れない、儲からない
>どうしても本で学びたければ英語で書かれたものを探したほうがいい
JAVAって、いろいろ分散していて、いったい何が標準なのかぜんぜんわからないですものね。
JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
今後は、日本語で書かれた書籍も増えてくるかもしれないですね。
ほんと、期待しています。
ASP.NETはいいんだけど、運用保守にお金がお金がかかるかかる。ライセンス問題が非常にやっかい。
MSのご機嫌取りしなきゃいけなくなる。アプリの運用を人質にされて、MSに振り回されるのは勘弁。
なので、ASP.NETは将来を見越したら、取り組みたくないんだなあ。 >>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。
一応、そのあたりの差異を吸収することも目的の一部に含むのが
jQueryのようなJSのフレームワークなわけで
サーバーサイドの人間は何かというとJSを目の敵にするけど
どちらも使えたほうが、この先業界内で生き残っていける確率は上がるでしょ
企業的には「フルスタックエンジニア」なんて名前の便利屋や何でも屋を
求めるようになってきてるし。 どうでもいいが「JFS」じゃなくて「JSF」な
JavaServer Faces（JavaとServerの間は空けないのがお約束） >フルスタックエンジニア
それでも、htmlやJAVA SCRIPTを触らなくても良い、高度に抽象化された一元的プログラミングをしたい・・・ >>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。
というかバージョン変わったりブラウザが変わったりすると動作しなくなる可能性があるのはJAVAでも同じことだと思うけど違うの？ >>441
Webアプリでクライアント側のJREは使わないでしょ
サーバサイドでJavaだから、サーバ側のアップグレードしなければ
バージョンアップのエラーは出ない
ブラウザ側でJSを多用するWebアプリは、ユーザのブラウザの種類や
バージョンに依存するようになってしまう
これはJSじゃなくてHTML/CSSの互換性の話だけど
XP時代にIE6用に設計した業務システムを作ってしまい、
悲惨な目にあった企業はたくさんあるのは有名な話。
OSのアップグレードやPCのリプレースもできなくなった。
クライアントブラウザの指定がしやすい業務システムであっても
なるべくサーバサイドでやるほうがあとあと問題は出にくいと思うよ >>442補足しておくと
ブラウザバージョンアップでレイアウトの崩れ程度は起こる可能性は
どの技術でもありうるけど、ブラウザ側でJSを使わなければ
エラー吐くような事態にはならないから新バージョンへの対応もしやすいということ
DartはもうIE9のサポートを打ち切ったらしい
ブラウザのバージョンアップですぐに動かなくなるようではだめだ
DartはJavaScriptに変換する言語ね >>442
ちょっとよく分からない。
サーバーサイドですべて出力するにしろ、ブラウザで動作するものを作るわけだよね？
JREで動作させるものじゃないとすると、結果はHTML出力とかになると思う。
だったらブラウザが新しくなったら動作しなくなるとかあるんじゃないの？ >>443
見てなかった済まない。
しかし昔の業務用アプリならともかく、最近のものでJavascriptを一切使わないってありえないと思うんだけどな。 >>445
このスレは昔ながらの業務アプリしか作らなくて済んでる化石のようなエンジニアの巣窟なの サーバー側で要求を受け付けて処理してHTMLを出力する方式は
wicketでもjsfでもセッション多用でレプリケーションの同期が多発
Playがセッション使わせたくないのもこの辺が原因でしょ >>445
一切使わないなんて言ってないんだけどな
>>442でも「なるべくサーバサイドでやる」とはそういう意味だ
>>446
業務アプリでJSが必須の機能少ないけどな
どういう機能か言ってみなよ
ユーザデータチェックのValidationではJS使うけど
業務アプリでJSでしか実現できない機能を求められることは少ない >>448
いやまあそれ言っちゃうとJSのほうだってなるべくHTMLは書くようになると思うよ。
JSが受け持つ範囲は多くなるけど。
全てのデザインをJSで組むっていうのはまずありえないかなと。HTMLで書くほうが早いし簡単だし。
あと>>446への返信に横入り。
「業務アプリ」で「最低限の機能」しか求められることが少ないって書いてあるけど、それって反論じゃなくて、
書いていることに対して認めているように見えるけど良いの？ >>436
> JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
> 今後は、日本語で書かれた書籍も増えてくるかもしれないですね。
>
> ほんと、期待しています。
JSFが何年も前の1のころからJ2EE (いまで言うJavaEE)の標準になっていたが、結局流行らなかった。
流行るものは、結局標準化どうかではなく、そのプロダクトが使いやすいか(いいものか)どうかなんだよ。 標準だとしてもOracleだぜ？
何だかんだ言ってもMSの方がマシだろ 酷い製造現場に入っちまったわ
少なくとも6年以上は前のフレームワークを使って色々やってるんだが
雛型作り上げるまでのプロセスがむちゃくちゃ 6年前って2008年か… マシな方じゃね？
10年前のJ2EEで止まってる方が酷いと思うわ GWTとかVaadinって意外と使われているのね
Vaadinはそのうち開発頓挫しそうな空気だけど GWTが流行るか、javascriptがdartに進化するべきだった
半端なJSフレームワーク乱立とか糞すぎる なんかもう
フロントコントローラ ： Jersey + 好みのDIコンテナ
テンプレートエンジン ： お好み（Thymeleafがよさげ）
DB ： スクラッチ、ヘルパーライブラリ、ORMお好み
フロントエンド ： 軽量のMVCFWお好みで
こんな感じでいいような気がしてきた（想像）
上手く設計できれば結構いい感じにできそう（想像）
今はWebはPythonとかLL中心でアプリはAndroidやってるからJava資産活用できるしWebもJavaでやりたいって
上に言ってはいるけどなかなか通らない。 ウチはWebはJavaかASP.NETでしかやらせてくれない
物凄く簡単なのでもJava
めんどくさい >>461
その通りなんだけど、 世の中全体としては、
もっと JSフレームワークが乱立して、みんなで右往左往する流れになってるからな・・・
30代後半になったけど、JSの流れにはついて行けなくなった。
jquery を覚えるだけでも精一杯（管理職業務も増えてきてなかなか開発できなくなったってのもあるけど） 結局新しいものは流行らずにStruts1.x & JQueryなんか？ｗ 大手SIerだったら、Struts1.xメインで
jQueryは使ってもほんの一部の機能だけだな >>466
そういうとこは、ユーザの操作に対してDOM書き換えは使わずにページ遷移で応答する感じなの？
もしくはJavaScript直書きのコードでDOM書き換えする？ >>467
業務アプリだとDOM書き換えはほとんど使わない。 だな。
業務アプリだと、UI/UXなんていう部分に意識も無ければ関係もない世界だし。
使い勝手が良かろうが悪かろうが、要件定義書に羅列されたものを
いかに満たしているかどうかがポイント。
そんなことやってるから、SIerは死んだって言われてるわけだけど
別に死んでるわけじゃなくて、そもそものビジネスモデルが違うんだよね
まぁこれからどんどん衰退はしていくだろうけど。 > 業務アプリだと、UI/UXなんていう部分に意識も無ければ関係もない世界だし。
全くそのとおりなんだけど、そんなんでユーザ企業の生産性はどうなってるんだっていうね・・・
SIerだけじゃなく日本の産業全体が衰退するだろこれ SIerはユーザー企業の生産性なんか気にしたこと無いよ
ただでさえユーザー企業からコスト削減を言われるんだから
確定した要件を決められた予算以下でいかに抑えて利益出すかが
最大の目的であって、使い勝手なんか知ったこっちゃない パッケージなんて入れても魔改造で原型を留めていない
そもそも客自体が抜本的に業務を改善する気があまり無い
そんなユーザ企業ばかりだろ
UI/UXとか高尚な話以前の問題だと思うがな そんな構造に嫌気が差してSIerから足洗った
こんな環境にずっといたらもうその会社でしか使えない人材になってしまう。
業務でそこそこ新しい技術を使えてそんなに忙しくないし給料も高い民間（）の会社の方が楽しい ユーザの生産性を最大限に上げたいなら、クライアントがブラウザとかそもそもありえないからｗ まぁEnterprise 2.0 じゃないけど、業務系でも、かんたんな ajax みたいなのは
少しずつ取り入れられてくると思うけどね。
VBの時代に、コード値の入力補助みたいな感じで、
コード値のテキストボックスからフォーカスを外すと、その右側の ReadOnly なフィールドに名称が表示される、とかやったけど
(勘定科目のコードを入力すると、その横に名称が出る、とか)
webでも似たようなことやった。 テキストボックスにコードを入れて onchange() で、そのよこの <div> を更新とか。
あと、めちゃくちゃ工数がかかったけど、Excelのグリッドをブラウザでやったり。 日本のシステム屋ってパッケージ作って売っていこうっていう風潮にはならないよね。
客はパッケージに運用を合わせる気はないし、
現場SEはバッケージ無視で要件聞いて作り直しが当たり前だし、
営業はそれでもパッケージ適用だと言い張って客から十分な費用取ってこないし、
パッケージ作ってる側もコンセプトがないかブレブレで大幅に手を入れないと売れないものしか作らないし >>477
あーExcelのグリッドみたいなのはやったことあるな
二度とやりたくない リッチなビジネスロジックをアジャイルに注入する〜♪
馬鹿な用語や言葉遊び多いよね。作るものは結局帳簿だしｗ システム化するほとんどの業務はExcelで回せる程度の話 エンタープライズ・アップリケーション（Excel） 喰らえ！ディペンデンシー・インジェクショオオオォォオォォォン！！！！！ はぁ・・・ほとんどのメインクラスが1万行越える糞ソース見てると目がおかしくなる
技術的な糧にもならんしホント終わってるプロジェクトだわ あと話を最後まで聞かないですぐ早とちり返答するプロパーにイラッとする ＞メインクラスが1万行越える糞ソース
誰が書くんだろう
「プログラミングなんか重要じゃない」とか逝ってそうな、そいつの顔が浮かぶけど お客様には最適なソリューションを注入させていただきます♪ >>486
「プロパー」という変な和製英語つかってるバカみるとイラッとする >>486がどういう意味で使ってるかよくわからないけどproperとはちがうん？ 和製英語って書いたから誤解されたみたいだな
日本ではそのproperという単語の使い方がおかしいってこと
properは形容詞だし、正社員という意味合いはどこにもない >>491
通じるからいいじゃん。美しい日本語を守る会から来たの？ >>493
その団体は知らない
「私は基本的な英単語もわからない馬鹿です」と宣言するような
「プロパー」なんて言葉を使う必要はないだろう
プログラミングをするならもっと言語の使い方に気を配るべきだと思うわ プロパーだけで正社員を意味してるわけじゃないからｗプロパー社員の略だからｗ のようだ
ttp://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1026097815 >>495
英語の基礎も知らない低学歴か
「プロパー社員」と形容詞的にproperを使っても
意味がおかしいのは変わらない
辞書でproperの意味を調べてみろ >>497
知らねえよｗ
proper employeeとか言い出した外人に文句言ってこいｗ あれか、ミシンとかホチキスとかキャタピラに文句言うタイプかｗｗｗ DBでEAVパターン避けてDDLでテーブル作成ので何か良いORMはないかい？
JPAとJDBC両刀も考えたがソリューションは統一したいんだよな Struts2のタグを勉強したいんですが
良いサイトないでしょうか？ proper は、「(世間の常識に照らして)正しい、適切な」
「世間で認められた」
a proper job は、まともな仕事
properly は、「きちんと」
work properly は、正しく作動する
a temporary worker は、派遣社員(一時的な労働者)
a temporary job は、臨時の仕事
a permanent job は、定職(永久の仕事)
temporarily は、一時的に ここって「Java Web Application Framework」スレですよね？よね？よね？ Struts2勉強中なんですが
<s:textfield>
とか使うと勝手にid属性が出力されてしまうんですが
これを止めることってできないでしょうか？ 何も使ってない。Eager or Lazyはもううんざり >>505
人によってORMの定義が違うんだよな
・広義のORM: JavaBeans/MapとStatement/ResultSetをマッピングする (MyBatisもORMだよ派)
・狭義のORM: オブジェクトモデルとリレーショナルモデルをマッピングする (MyBatisはORMじゃないよ派)
あるいは
・ORMでも操作対象はRDBだからSQL当然 (MyBatisもORMだよ派)
・ORMでは操作対象はオブジェクトだからSQL不要 (MyBatisはORMじゃないよ派)
推測だが>>505は前者、>>507は後者ですでに食い違ってると見た Struts2勉強中って死んだフレームワーク勉強しても時間の無駄だろ JPA/Hibernate系列はフレームワーク
DBUtilsやMyBatisはライブラリだな
前者のくそったれにデータベース乗っ取られると制御不能
（実際には抜け道はあるが、そんなことになるなら始めから使うべきではない） >>509
どこかの馬鹿が採用してそれの面倒見る事になったんだろ… JPAの控えめなバージョンって事で、Ebeanがいいと思う。 struts1.x脆弱性問題の後どうなってる？
まさか新規プロジェクトで採用とかないよね フィルターやbeanutilの修正で対処できるからまだまだstruts1採用 struts1って何ゆえ使われるんだろう
バリデーション関連かな JSF2.2はステートレスなJSFにできるんだろ
Strutsの出る幕ないな 実績あるから何も知らんジジイが押すし
それしかできないやろうとしない人間も多いし Struts 1を重用するような層って、もしこれが無かったら
Servlet API直叩きの自家製フレームワークに逝ってるぜ。多分。 Servlet API直叩きの自家製フレームワークの方が断然よくね？ 新規案件、別に経験者いるわけでもないのにStruts2でやることになった…
Springとかやってみたかったなあ おまいら今新規でWebアプリ作るとしたら何使う？
Playでやりたいと言ったら
お前以外にScala分かる奴いないからダメとか言われたわ >>523
Liftみたいに凝ったことするわけじゃないんで、
scalaっぽく書かないでjavaの延長で十分ですよとでも言いくるめれば？
それはそうと、Grailsの選択肢はないの？ >>523
ASP.net(MVC)かPythonだろう DIはSpring、VIEWはJSFのオレオレフレームワーク >>525
その理由で押し通してきたわ
Grailsは仕事どころか趣味ですら触った事ある奴ゼロなんや
>>526
このスレで聞いてるのだからJavaで頼みますよ… もうjavaはオワコンなんだろうか？
サーバーと開発環境のコストぐらいしかc#に勝ち目ないよね。 Java8とSpringBootでいろいろ楽できそう C#つうか.NETはWindowsでの運用を嫌がるところでは候補にも入らない
monoって言うのは禁止 Windowsを嫌がる客には当たった事ないな
Linux分からないからWindowsにしてくれと言われるぐらい そういう客でJava案件あるのが意外
素直に.NET使わないんだ？ grailsとplay frameworkの両方とも試験採用してみたけど、playの方が好評だったよ。
grailsは細々と変なとこでつまづくから、もうヤダって意見が多かった。 >>535
playはJavaで。
playのデフォルトテンプレート言語は、賛否両論だったが。 マルチ環境向けのテンプレートだとMustacheとかあるな
JavaScriptにも対応してるから資産管理の点で目を付けてるが使ってる奴居る？ >>244
hotdeployはバグってねえよ
ただ、クラスローダのこと良くわかってない奴が適当に作って、パーマネント領域食いつぶしたり、クラスキャスト例外起こしてしまって機能してしないってのはある。 最近はいろいろプロジェクト火を噴いて全然そういうのに興味を持つ時間がないが、
久しぶりに本屋に行ったら既にSpringは4が出ていた。
そもそもSpring触ったことないけど使い勝手いかが？ Struts2について教えてください。
s:iteraterの中でs:checkboxを配置しているのですが
一度チェックを入れた行のチェックを外してポストしても
復活してしまいます。
こんな現象経験ある人いますか？ DWRが凄く使い易いと思ってる初心者ですが、何であんまり人気無いんでしょう？
脆弱なところがあるんですかね。
このスレのプロの皆様方の評価をお聞きしたいです。 そういえばDWRなんてあったな。
いまは、結局作り込むんならサーバサイドの言語に関係なく、クライアント側でjsを直接ゴリゴリ、って感じだけど、
まためぐりめぐってサーバサイドと連携したフレームワークが再び出てくるのかな。 DWTとかWicketはネットワーク圧迫するのが難点だな dropwizardどうかな？
普段androidオンリーなんだけど、apiも同時開発する場合、同じIDE(IntelliJ Idea)上で開発できて良さそうなんだけど。
あとデプロイもなんか楽そうなイメージがある 「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 .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作る理由がない 時代はシングルページのJavaScriptアプリをサーバサイドでも動かすことだけどな Javaがオワコンとか言ってるのはC#土方だろ
だせーから出張してくんな >>549
そんな時代はこない
動的言語で大規模開発は非効率
>>550
ださいのはJavaだろ
ろくなフレームワークないし
.NETがクロスプラットフォーム対応したらJavaなんておしまいだ >>551
> 動的言語で大規模開発は非効率
そのためのTypeScripだろ
C#作者が作ってるのにお前取り残されてるよ ラムダの抜け道としてref入らないかな
↓みたいのを綺麗にやりたいわ
String[] s = new String[2];
get (em -> {
s[0] = findString(em, foo);
s[1] = findString(em, bar);
}); それ絶対refよりLINQの方が簡潔で読みやすく書けるな クロージャの内部に変数を参照渡しされるとバグの元になりやすいから今のままでＯＫ >>554
メソッド参照あればデリゲートいらなくね？なんか不足あるか？ 関数型プログラミングの方向に向かってるんだから今更refもいらん
副作用は甘え 関数型プログラミングなんてまったく流行ってない
ScalaもF#も人気ない WebフロントエンドのGUIというかJavaScriptにFRPの潮流が来てるみたいだから
今年こそ関数型言語の夜明けになるで（白目 Java8のラムダ、Stream、Optionalも関数型からの輸入だし
関数型言語が主流でなくても関数型の考え方は急速に取り入れられている
取り残され君はいつまで経っても気付いてないけどな >>562
取り残されてないわ、Scalaは少しいじったよ
Javaのフレームワークがひど過ぎたからScalaを少し勉強した。
まずScalaの言語がひどい
同じ処理書くにもいろんな書き方がありすぎて無駄に複雑
他人のコード読むときにすごい苦労する
あとコンパイラが産廃、もっさりしすぎ
さらにWebフレームワークが醜い。
当時人気あったLiftとかいうのを触ったが意味不明だった。
もうScala信者なんて絶滅してるんじゃないの
>>563
Haskellとか何年たっても流行らないぞｗ ヴァルハラの値型が取り入れられたらTupleとしてutilパッケージに入れて欲しい
return Tuple.of(1, true, "foo"); とかしたいじゃん >>564
ごまかしすぎｗ
関数型の一部が取り入れられるのと
関数型プログラミング言語が主流になるのはまったく次元が違うぞ
MSがプッシュしたF#でさえ流行らないんだから
関数型言語が主流になるわけがない >>567
まず日本語を読み取る力を付けような
>>560は>>554-555からの流れでJavaという言語にrefが欲しいという意見に対する反論だ
すなわち主題は明白にJavaなんだよ
>>560を丁寧に書くとこうなる
・Javaは関数型プログラミングというスタイルのサポートに向かっている
・副作用が主目的となりやすいrefはそれに反する
・従って今更Javaにrefは不要である
わかるか？
>>560は「関数型プログラミング」と書いただけで「関数型プログラミング"言語"」とは書いてないんだよ
主題はJavaだからな
ScalaもF#も話題にしていない
それは読解力のない>>561が勝手に出してきただけだ
ついでに、Scalaは関数型言語じゃないだろ
あれはJavaよりも関数型の要素を多く取り入れただけのオブジェクト指向言語だ
F#は本格的な関数型言語 うわ、「ついで」の部分しか反応できないくせにドヤ顔！？www
一言「誤読してました、ごめんなさい」って書けないのかよ
小せえなあ サーバー側でviewを生成するフレームワークはもう考え方が古いらしいな
JavaScriptを描くのは嫌だし、GWTがもう少し流行ってくれたら嬉しいのだが ところが一周して今はサーバサイドレンダリングがトレンドだ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)を生成するのが増えてる ホントJavascriptがここまで侵食してくるとは思わなかったわ そらデザイナー方面が侵食してきたらそうなりますわな。 そろそろMS(ASP.NET)信者が「そんな時代は来ない」って書きに来る頃 MSはJSやNode.jsにもすごく力を入れてるから同じようなことは考えてるんじゃないか？
>>553のTypeScriptや>>563のRxJSをやってるし、Node.jsに対しても
・Node Foundationの設立メンバー
・何年も前からAzureでNode.jsをサポート
・Oracleよりずっと前からSQL ServerのNode.js用ドライバを提供
・複数の社員をNode.jsのフルタイム開発者(コミッター)に
という力の入れよう
だからIsomorphicな何かを出してきても全然おかしくない でも、Node.jsをWindowsで動かすのは地獄、と。 >>578
それ何年前の話だよ
今は公式サイトのインストーラ一発でnpmまで入って楽勝だぞ
Javaと同じように運用はLinuxでもWindowsで開発できてる >>573
GWTって海外だとspringについで使われてなかったっけ？
altJSもみんな変換系でコンパイル遅いのにどうしてこんなに差がついた！？ 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/ javaなんかもう使わねーのにパソコンにインストールされてくんなや。
スパムかよ。 playとspringとwicket、結局どれが一番いいのよ？
やっばりplayなの？ >>588
JSFとjava EEを使って、
O/Rマッパーは？ >>590
JPAって、HibernateのHSQL使うのと、あまり変わらなくない？
JPA以外なら？ JavaEE標準にはJPAしかない
SpringでもPlayでもJPAが用意されてる
自分で選べないならJPAだ
俺は全力でJPA避けるけどな >>592
避けて、結局mybatisとか使ってるの？ なんだかんだでseasar2が一番楽でよかったよなー！ O/Rマッパーとか軟弱なもの使わずJDBC
自分でSQL書かないと気が済まないだけとも言う >>597
何を使ってみて、そう思ったの？
Mybatisやs2daoを使ってみて、そんな事を言ってるの？ Doma便利そうに見えるけどすぐにhasOne, hasManyねーのかよって思う。 O/Rマッパーは肝心のselect文が使い物にならないというか
N+1問題が避けられないよね（SQLが直に書けますとか謳う変なのは問題外として） 何が変かわからんがJPAならEntityGraphでググレカス 2年近くも知識を更新せずにドヤ顔する
そんなエンジニアに私はなりたい フロントエンドは2年もかからず枯れるどころか息絶えるモノが多すぎる
作りっぱなしならトレンドのモノに飛び付いてもいいんだけど
後の保守考えると迂闊に採用できない ドッグイヤーは古い--->ラットイヤーは古い--->ITは古い seasarゾンビのステマがうざかったな
あれは存在自体が害悪だった あれってseasarのこと？
それともseasar信者のこと？ ご本尊が逃亡したはずなのにまだ2chでステマを見かける
他に宣伝するところないのかね ★★Java質問･相談スレッド172★★ [転載禁止]©2ch.net
http://peace.2ch.net/test/read.cgi/tech/1419490897/
↑から誘導されたので、こちらにポストします。
----
勉強でspringを使ってwebアプリを作って作っています。
dataSourceのBean定義でパスワードを暗号化して定義する方法は無いのでしょうか？
バージョンは4.1.5です >>618
(1) xml中の暗号化したいものをpropertiesファイルに追い出し、暗号化したvalueを書く
(2) PropertyPlaceholderConfigurerを拡張して(1)を復号化するロジックを追加する
(3) <context:property-placeholder />の代わりに、
<bean id="cryptProp" class="(2)で拡張したクラス>
<property name="location">
<list>
<value>(1)のプロパティファイル</value>
</list>
</property>
</bean> >>619
ありがとうございます。そして亀レス失礼しました。
確認はしてたのですが規制？で書き込めませんでした。
デフォルトでは無いんですね。
実際サービス開始時は基本パスワードベタ書きが普通なんですかね？
まぁプログラムに複合ロジック書いても簡単にデコンパイル出来てしまうからですかね？ リモートログインされた時点でほぼアウトだからでしょ
そっちを防ぐ方に注力したほうがいいという話 うちはこの手の情報は環境変数にすることが多いね
理由はなんらかの手段でwar/jarを盗まれてもそこには情報がないから
621が言ってくれてるように本番サーバにログインされたらもう詰んでるしな >>621
>>622
確かにログインされない事が一番重要ですね。
ログインされた時点で詰んでいるかも知れませんが、パスワードを抜くまでの時間稼ぎになるかなぁと思っていたりしました。
もう少しお話聞かせて頂きたいのが正直なところですが、スレチと私の知識では追い付かない気がしました。
また具体的な疑問が出たら質問させて下さい。 スレチ、無知すまん。
個人的にはアプリケーションサーバに入られるなら、まだ救い道あるかなと思ったりもする。
リモートログインされたらメール飛ばす仕組みにしておいて、DBのパスワード突破されるまでに切断。
そうすりゃデータ抜かれるリスク減るんじゃないかとは思う。
まぁハックするような人に俺が対抗出来るとは思えないけど、やれることはやりたいかな。
無理矢理スレの内容に持って行くなら、そういうのをサポートしてるFWとかあるんかな？ レイヤ7のアプリが頑張る部分とは思えないな
侵入検知ってレイヤ3あたりの仕事じゃね？ みんなそんなレベルまで考えてるのか…
セキュリティとかXSSとかSQLインジェクションぐらいしか考えてないや >>626
考えないよ、考えてくれる人/部署があるから。
客が大手なら定められた基準に乗っかるだけだし、
客が基準持ってないならうちの基準に乗っかる。
どちらもなくて一人で上から下まで全部やる系だと考えるしかないけどさ… 最近のwebアプリなんて2,3人で開発する事も多々あるし、AWSのお陰でエンプラばっかりだったjavaが簡単にwebアプリのサービス立ち上げられるようになった。
そういう意味でも一人が幅広く知識を持つのは自然な流れじゃないかな？
特にJavaの人はエンプラ人月縛りの仕事ばかりしてて、Javaしか出来ないって人が多いんだし。
もちろん俺も偉そうな事は言えないが。 AWSだとVPCあるし、逆に組織としてそいう知識が必要なくなる >>629
踏み台サーバーを守れば良いよ的な考え？ 豚切り失礼
メッセージとかを外に切り出した時に、引っ張るためのキー項目ってどうやってプログラム側で管理するんでしょう
定数クラス？ 列挙？ インタフェース？ それともDB？
あと、国際化とリアルタイム変更反映の要件がない場合に
外に出すと管理するものが増えるだけで楽になる気がしないんだけどどうなのかな 追記
環境毎に値が変わる奴を外に出す価値があるのは理解してるのでそちらは無視してください >>631
リソースバンドル的な話なら、外出し対象メッセージなり何なりをそれまで管理してた方法で
やったらよいというか、プロジェクトによっていろんな都合あるから好きにするのがいいのでは
ぶっちゃけ国際化不要な小規模プロダクトならソース上にベタ書きでいいし DBにそういうの取得するファンクション作ってるけど
ファンクション名自体がキーみたいなもんだからベタ書きって事になるのかな キー項目はべた書きした方がいいと思う
そのメッセージをどこで使っているか調べるときに、 grep すればわかるから。 本番稼働トラブルようやく解決
631です。レスくださった方ありがとうございます
コード値とかメッセージIDとかをPG上でどこに置くのがいいのかなと悩んでました
例えば、
/msg.properties
id001=message
/Msg.java
public static final String FooMsg = "id001";
/Foo.java#doFoo()
String msg = MsgUtil.getMsg(Msg.FooMsg);
// msg = "message"
こんなことするのかなとか この例だとid001って必要無い気がするなぁ
FooMsg = "message";
じゃダメなん？ 上に書いた通りで国際化とかなければ要らない気がしてるんです
直接書いていいんじゃないかなーと >>621
>>622
蒸し返してすまない
リモートログインされた時点でアウトならパスワード設定すら不要なのでは？
と思うと
本番だから複雑なパスワードとか設定してるけど、それが無意味な気がしてきた
内部犯への抑止なのかな
未だに小規模アプリでWebサーバー経由でtomcat使う意味もよく分からない
デファクトだけど理由が分からない事って多いね >>640
複雑なパスワードの設定は対内部も対外部も併せてセキュリティの向上って括りでJIS Q 15001とかISO27001の適用基準の一つ
大手の案件だと入札参加の要件にPマークとかISMS取得が入ってる 俺もニートで体重１２４ｋｇある
無職だから健康診断とかも行ったこと無いし
口から血吐くこともあるし、
たまに外でて歩くと必ずコケるし
絶対どこか悪いんだろうな Railsより生産性の高いフレームワークでてこないかな >>1
デュエル・マスターズ的な非電源TCGの 《 オンラインTCGツクール系 》 ソフト（エディタ）の企画。
例えば、ガチンコ・ジャッジを直ぐにでも導入できる機能を持っておりながら、
当面それを扱わず単純化させておいて、事後的に導入拡張する際に当該システムを
ブロック構造の組み合わせで後付け挿入できるように予めシステム化してある制作ソフト。
既存の非電源TCGを劣らずに再現できるならば大概のニーズに応えられる筈。
バトスピ、ヴァンガ、バディ、ドレノ、フォースｏｆウィル、ウィクロス、ポケカ、デジモン、ゼクス、モンコレ、ガンダム・ウォー、ディメンションゼロ、ライブオン、カードヒーローなど
のシステムを完全再現できるように設計するけど、他に此のTCGの此のシステムは再現希望とか有ったら書いて。
マジック：ザ・ギャザリングの全システムを完全に再現するのは無理だから、此れだけは必用だ！って部分のみリクエストして。
WEB通信での対戦は、個vs個、多数乱戦、チームvsチーム、個vsチームを可能な仕様とする方針。
設計思想は 《 RPGツクール 》 が良いかな？ 他に、優れたエディタ有ったら挙げてみて。
個人や企業などのベンダーが提示する開発費（見積もり）で折り合えば、発注する。
↓
エディタ系ソフト群から基本コンセプトを絞り込む（もちろんオリジナルで優れた新ネタが有れば導入する）。
↓
遊戯王OCGに関しては、タッグフォース、ADS、デュエルオンラインを発注先ベンダーに研究させる。
なるべく前述３つで可能な再現は全て実装させる方向を目指す。 まぁ努力する・・・
バトスピ、ヴァンガ、バディ、デュエマなど、発売済みゲームソフトの存在するケースはベンダーに研究させる。
↓
TCGを再現するテストプレイ ⇒ 更に改良や修正。
↓
機能制限した下位版を５万円以上で発売 ＋ デュエリーグ用に改造した上位版でサーバー稼動＝営業開始。
↑
下位版の改造および商用利用には、別途で当社との契約が必要。
さ〜て、製作を受けてくれるベンダーが見つかるかな？ｗｗ（ｸｽ
http://hayabusa6.2ch.net/test/read.cgi/gameama/1438617407/l50 Railsって開発者のメンテナンスコストが高そうなイメキャラ 別のサーバ１で動いているservlet/JSPの画面をサーバ2で一部取り込みたいのですが、
iframeじゃなくて、サーバサイド間の通信でやるにはどうするのが簡単ですか？
サーバ2のservletからHttpURLConnectionでサーバ１にpostして画面要素を返す専用のJSP書くとかでしょうか？ WEBシステムを作っていて、NON-BREAK-SPACE問題に困っています。
いい解決方法を知っている人はいませんか？
具体的には以下のような事象です。
・JSPではHTML-ESCAPEをかけている。
・この為、WEB画面上では半角スペースが (C2A0)に変換されて表示される。
・それ自体は狙い通りなんだけど、HTTPパラメータとしてNON-BREAK-SPACE入りの文言が入ってくるせいで、
検索に困る。（見た目は同じなのに、一致しない）
何かうまい方法はないありませんか？
Struts2のActionクラスメンバー変数(String)がHTTPパラメータを受け取った時に、
勝手にNON-BREAK-SPACEを半角スペースに変換するような方法でもいいのだが。
あるいはPostgeSQLでNON-BREAKE-SPACEと区別せずに検索するような方法でもあれば。 ee勉強中でjpaで実験しててわからなくなりました
jpa(eclipselink)で
Entity e = new Entity();
e.setId(1);
transaction.begin();
em.persist(e);
e.setId(2);
transaction.commit();
em.find(Entity.class,1).getId();//2
em.find(Entity.class,2).getId();//2
となるのですが動きがわかりません。
em.peraist(e)でem上でid1エンティティが作成されて、その後setid(2)でeのidを2にすると、em上のエンティティもeを参照している？ので2になってコミットされる。
ところがem.findで第2引数に1を渡すとid2のエンティティが取得されます。
どういう動きなんでしょうか。
ご教授願います。 >>648
Entityクラスのidに主キー指定がされてないとかいうオチでは サッカーブッシュ日本代表日程ぷあたん（しゅっちょうまいくろ教育長交代）春文執行40代売上差額シュガーチョコ
https://www.youtube.com/watch?v=NDq1QoJY0nY宇ドナルドアナリストパワーストーンコーチングとしまえん
サッカーブッシュ日本代表日程古本屋よしたけしゅっちょうちょこしゅがー
ディーラー税務署天才開発者死亡詰みヨミドクターマイクロサービス不足
サッカーブッシュ日本代表日程ぷあたんシフト光金さかい強制バイト人権侵害問題
春分資源執行ニューヨーク低原価ぼったステーキソルトレイク福岡横浜新橋奴隷課金パチシフト強制バイト問題新潟米センター生残
コスメ２４チャリティー隠れ40代生活保護プレイボーイバイトレードいたりあん接待問題
マスコミKARDローンケーオーサービス不足婚活パーティー寄付金執行原発ビジネス
FBIチャイニーズタイホテル売上事務所ガチャ決算ガチャキャンペーン（販売報道陣過激派組織向携帯最新情報提供終了
校長発言細心注意ノートン産廃エラー(著作権クレーム中国反応融資高額教育費)(中国捕鯨団体40代社員サッカーコメント
高額入学金ヤフウ新橋大学ヤフウ新橋理事長FX経費 おじや50代資産ガリバズフィード40代エリート 匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
ｆ JavaEE 8に乗っかる予定のMVC1.0はどうでしょうか
SpringやPlayに比べて後発の優位性はありますか LaBee FrameworkはJavaによるWebシステム開発のデファクトスタンダードを目指す、ゼロから作られた国産のJavaフレームワークです。
海外製フレームワーク特有の難解さや情報不足による工数や人員の増大を解消しJavaのWeb開発を効率化する為に作られました。
LGPLライセンスでソースコードをオープンソース公開しており、個人・企業問わずどなたでも無償で利用出来ます。
公式
ttps://www.bee-wkspace.com
twitter - Java LaBeeFramework
ttps://mobile.twitter.com/labeeofficial
(いろんな意味で)生まれてくる時代を間違った超大型新人が来たぞ
もうどこから突っ込んでいいのかわからんレベルでヤバい 国産のオープンソースって成功した事例ほとんどないな
ASP.net MVCにいってしまったんだけど最近の
Java標準のMVC framework事情はどうなってるの？ spring MVCだろうなあ
今はJavaEE7行くかSpring-boot行くかのほぼ2択、もう一つ加えるならPlayも？
スレ違いになるけど、個人的にはバッチも頑張って欲しいんだよなあ…
JBatch？ Spring-batch？ ほかないんかーい！ >>655
何でも最新技術？を使ってればいいってもんでもないし
シンプルで使い易ければ普及する可能性もあるんじゃまいか?
ぶっちゃけDIを使う必要ある案件なんてほとんどないし
フレームワーク選定って上層部のお偉いさんがオナニー思想で選んでて
プログラマは苦労するだけなのよ Windowsだと問題ないのですが、Linuxで実行するとメモリーリークが起こります。
だれか教えて 富士通のxframeworkとかいうやつ使ったことある人感想を教えて欲しい メーカー製のwebフレームワークはただ一つの例外もなく２００％ゴミ
知識がなくても使えるという触れ込みに触発されて馬鹿が採用するが
実際はオレオレ仕様のゴミフレームワークでBtoBでしか使われる用途がなく
想定外の仕様に対して柔軟性がなくコア部分の制御が完全にブラックボックス化しているため
トリッキーなことを使用とした場合、泣き寝入りするハメになる純然たるゴミフレームワーク >>655
GitHub見てみたが、Readmeは英語なのにコード内のコメントは日本語だったり、issueやStarがひとつもなかったり…やる気ゼロやん ☆ 日本の、改憲を行いましょう。現在、衆議員と参議院の
両院で、改憲議員が３分の２を超えております。
『憲法改正国民投票法』、でググってみてください。国会の発議は
すでに可能です。平和は勝ち取るものです。お願い致します。☆☆ Java Frameworkのランキング
https://zeroturnaround.com/webframeworksindex/
Rank Framework Popularity
1 Spring mvc 28.82
2 JSF 15.2
3 Spring Boot 13.35
4 GWT 7.74
5 Grails 6.35
6 Struts 5.4
7 Dropwizard 4.9
8 Play framework 3.26
9 JHipster 2.49
10 jax-rs 2.44 ランキング続き
https://zeroturnaround.com/webframeworksindex/
11 Vaadin 2.15
12 Seam 1.94
13 Wicket 1.91
14 Tapestry 1.9
15 Sparkjava 0.77
16 Vert.x 0.76
17 Rapidoid 0.25
18 Lagom 0.24
19 Ratpack 0.13
JSFのいいところ、悪いところはどんなところ？
JSFはJava EEの標準ということ以外になにかアドバンテージはある？ JSFはJS無しである程度リッチなUIをそこそこ手軽に作ることができるのがメリットかな
GWTも同じ
でも今時はJSF使える人よりJS使える人の方が多いからな…
JSの方が便利なコンポーネントも多かったりするしな… >>671
なるほど
ASP.netをかじったことがある身としては、Javaの世界では
Spring MVCとかJSFでやるのが普通だと思ってた。
HTML, CSSを含まないデータだけブラウザに送って
フロントサイドをJavaScriptでやる方法が主流になってるってことですか？
サーバーサイドでHTML作らない方法に比べて開発生産性は
低くなったりしない？
Reactが流行ってるそうだからチュートリアル初めて見たが意外と難しい。
JSのライブラリ、大量にありすぎてどれを組み合わせればいいのかすらわからん
これはカオスだ >>671
>>672 間違えた。
ブラウザにJSONでデータだけやりとりする方法は、
（Spring MVC, JSFのように）サーバーサイドでHTMLまで作る方法に
比べて開発生産性は低くなったりしない？ 化石のように動きの乏しい画面ならともかく今時当たり前なUI作るならJSでSPAにする方が圧倒的に生産性が高い
Reactで組み合わせに困るならVueの方が入りやすい >>673
むしろ生産性が高まる
プログラムの構造が綺麗になってわかりやすくなる
UIとアプリケーションが疎結合になって製造難度が下がり分業が捗る spring mvcがサーバーサイドでHTML作るとか何言ってんだコイツ・・ （それしかできないとは書いてないのに何言ってんだコイツ・・・） >>674-675
SPAって呼ばれるのか
SPAのメリットであげられいたもの
通常のWeb ページでは実現できないユーザー体験を実現できる。
高速なページ遷移を実現できる。
ネイティブアプリの代わりとして提供することができる。
一方、あげられていたデメリットは
SEOに不利になる。SPAだとクローラーがひろってくれない。
サーバーサイドレンダリング（SSR）が必要？
保守のコストがあがる。JSの深い知識もったエンジニアいないと保守できない。
SPAの良いところもわかったけど、従来型がなくなるほどの
万能な開発手法ではなさそうな気もした。
SEOでデメリットあるのはつらい SEOなんて2013年には解決済みなのにどんだけ周回遅れ・・・
保守がどうこういうのは試しもしないで否定するバカばっかだし
せめてNextかNuxtくらい試してみろって SPAそのものすら知らないレベルなんだから無理もない > ネイティブアプリの代わりとして提供することができる。
これはただのSPAじゃなくてPWAだな
いかにもなアプリに限らず大したUIでもないニュース系やマンガ系でも増えてる
AMPと融合したPWAMPはまだそれほどでもない >>679
ツンデレ回答ありがとう
SEOは気にしなくていいくらいには解決してるってことか。
すでにクローラーは対応していてSSRは必要ないと言ってる人もいて混乱している。
まだReact触り始めたところだがAngularやVue, Nuxtもいじってみる。
TypeSafeじゃないという理由でJS嫌っていたのに
ReactとかAngularもTypeScript対応していたと知った。 GoogleのクローラーはJSに対応してる
ただし少し古いChrome相当なのと日本ではヤフーを無視できないので現状はSSRするのが王道
NextはReact、NuxtはVueでSSRするための土台(IsomorphicとかBffってやつ)
ReactではTypeScriptよりもflowが主流(flowはReactと同じFacebook製だから) 1年以上死んでたスレが何で急にレス付きだしたんだ？
お前らweb新参の木っ端かよ >>683
React, Vue, Angularの比較記事をいろいろ見ているけど
ReactはJSXへの批判が多いみたいだ。
JSXはHTMLとJSがごちゃごちゃでたしかに美しさがない。
あとはVue, Angularに比べてReactパフォーマンスが悪く半分程度とからしい。
Virtual DOMなのに2倍も差がつくとは
https://itnext.io/angular-5-vs-react-vs-vue-6b976a3f9172
Vueは批判があまり見当たらない。
大企業がバックについてないから今後の継続性を心配している人は見かけた程度。
GitHubのスターは一番伸びてるし開発が続けばスタンダードになるかも JSX批判してるのは食わず嫌いだろ
今やCSS in JSも含めて全部JSに一本化だわ そいつはともかくWebAssemblyには期待してる コンテンツ(HTML)とロジック(JS)を分けるのがいいってのは実装(Java)と設定(XML)を分けるのがいいって信じてた頃を思い出すよね
低結合(分離)より高凝集(一体)の方がいい場合も多い 結合度と凝集度は対義語ではない。
むしろ、低結合なら高凝集という関係。 ReactのSSRは確かにすごいのだが、そこまでするくらいなら、そもそも普通のウェブページでよかったのでは。
必要がないものを無理にアプリケーションの体裁にするからSSRが必要になるのでは。
そんな疑問を感じました。 html,css,jsを分けてもdomというグローバルデータで強く結合してるからね
低結合を実現出来てない無意味なモジュール化だった 「そこまでする」と感じるのは実際にやってないからだろ
やってみれば「そこまでする」なんて大袈裟なことではない
むしろ今じゃThymeleafとか非JS(非フロントエンド)なものを使う方がよっぽど「そこまでする」って感じるわ
JPAのCriteriaでSQL組み立てるもどかしさみたいというか
フロントエンドがマークアップ得意なメンバーだけで完結する簡潔なワークフロー最高だし
フロントエンドチームとバックエンドチームがAPIだけで低結合なチーム編成最高だし >>687-688 >>691
デザイナーにとってはJSとHTML,CSSが混在してると
理解できなかったりするだろうし、
デザイナーはJSXはしねと思ってるんじゃないの
>>695
DBがRDBである限り、SQL知識は必要なのは変わらないんでは。
サーバーサイドは相変わらずMySQLとかのRDBばっかりでしょう >>696
会社によって区分は違うかもだけど、うちでのデザイナーは元からhtmlもcssも触らない
彼らはイラレやフォトショを使う
htmlやcssを書くマークアッパー(フロントエンドエンジニア)はjsx大歓迎してる
css in js(styled components)使うようになってから尚更
一つ直すのにファイルを複数編集するのがバカげてるって気付いたらしい いやいや、サーバーで計算した結果をそのままクライアントで引き継げるんだから、ここまでするかって思うでしょ。
でもそのためにHTMLはひどいことになってるし、通信量が増える。
ここまでしなきゃならないなら、結局それアプリじゃなくウェブページだったんでしょって思うわけよ。 >>698が何を言ってるか分からない
誰か別の人解説してくれ >>697
JS, HTML, CSSを触らない人の呼称はグラフィックデザイナーとかじゃない？
昔はWeb designerといったらHTML, CSSのスペシャリストだったし
pixelレベルで希望のデザインを実現する人たちだった。
プログラミングを理解できない従来のWeb designerはSPAの時代には
仕事が減って、フロントエンドエンジニアに仕事をとられつつあるってことかな？
フロントでJS flamework使ってるとプログラミングわからない人は
デザインできないだろうからね >>697
勤務しているのは、自社開発のサービスや製品作ってる会社？
それとも受託開発などでクライアントの指示で開発する会社？
受託開発系の企業はクライアントのいいなりだから、
ReactとかSPAとか新しいフレームワーク、開発手法で統一できないイメージがある。 ホント、ウェブの人はキチガイだわ。
クライアントの言いなりって、クライアントの要求するものを納品するのが当たり前なんだけどな。
SPAのウェブサイトがおかしいと気づくべき。
2chブラウザってあるだろ。
てことは、2chがSPAだったらそれはそれでいいんだよ。
もともと検索するほどの価値がないんだから。
FacebookやTwitterもそうだ。
そんな個人の独り言なんて見たい人がほとんどいない。
だからSPAでも成立するわけだ。 ところが、企業が依頼するウェブサイトはそうじゃないだろ。
ページ一つ一つにコストがかかっていて、しかもそのページを多くの人に見てもらいたいわけだ。
通販のサイトだったら、そりゃ作る方はSPAのほうが楽だろう。
一つ一つの商品は変わっても、同じテンプレートに合わせてページを組み立てるんだから。
だからと言ってSPAを提案して許されるのは小学生までだ。
製作が楽だとしても顧客にはデメリットが多い。
検索できない？ではSSRを導入しましょう。
こういうのは、制作側はもうかるけど顧客は金を失うだけ。
つまり詐欺みたいなもんだ。 顧客は金を稼げるサイトを必要とするのであって、最新のフレームワークを必要としてるわけではない。
こんなの中学生になれば誰でもわかることだ。 コンサルやってる人は、お客さんにはっきり言うべき。
SSRと言い出したらそれは詐欺業者ですよと。 企業もとっくに気がついてるんだよね
単純に集客したいならIT屋以外の業者に広告費を払ったほうが費用対効果がでかいって >>702
繰り返すけど会社によって違うだろうからどっちが正解というものではない前提で
うちではグラフィックデザイナーは情報誌やポスターのデザインしてる人だな
ずっと前からwebデザイナーのメインの仕事はワイヤーフレームを作ること
その道具はイラレ（とフォトショ）
ワイヤーフレームからhtml/css/jsに落とし込むのがマークアッパーと呼ばれてた人達
前はそのhtmlを（サーバサイドの）プログラマがjspなんかに変換してた
html/css/jsが書けるデザイナーもいるけどデザインだけで勝負できないから逃げてる人って扱い
（予算の少ないプロジェクトではデザイナーとマークアッパーを別にするより一人でできる人が重宝される？よく分からん）
今はspaになってワイヤーフレームの後ろはフロントエンドエンジニアと呼ばれるようになった人達が全部やってる
だからデザイナーの仕事は変わってない
仕事が減ったのはサーバサイドでjspいじってた人達だけど歓迎されてるからみんなハッピー >>703
サイトやスマホアプリを大量に提供してる企業グループのシステム部門子会社ってとこかな
ビジネス担当に対しては受託側のように、パートナー（SIer）に対しては発注者のように振る舞ったり曖昧なことも >>710
あなたを批判してるわけじゃないから怒らないで見てほしい。
ワイヤーフレームなんて絵心なくても作れるし、HTML, CSSを知らない人が
ワイヤーフレームというデザインの大枠を作ってる企業がいまでもあることに驚いた。
Webデザイン教えてる専門学校の、デザイン専攻コースであっても
HTML, CSS, JSを教えてない学校はないでしょう。
最終的にブラウザにわたるのはHTML, CSS, JavaScriptなのに
それを知らない人がデザインに関与している、いや関与しているどころか
最も重要な大枠を決定しているというのはちょっと信じられない。
最終的にHTML, CSSで表現しないといけないのに、PhotoShopや
イラストレーターでデータつくるのはものすごく非効率だと思う。 どこからがSPAなのかがずっとピンとこないんだけど、画面遷移なしで画面の一部が動的に切り替わってたら
それを実現させてるのがJQueryだったとしてもSPAなの？ 画面の一部って言い方だとタブやアコーディオン程度も含まれるから当てはまらないな
画面全体の読み込みは最初の一回だけで後はサイトに留まってる間はずっとJSだけで画面を書き換え続けるのがSPAって感じ
実装にjQueryを使うかどうかは関係ない
Gmailとか古くからのSPAはjQuery以前からあるし
ただしjQueryでSPAは生産性も性能も辛いので普通は選ばれない >>712
htmlが書けるのといい文章を書けるのは違うようにcssが書けるのといいデザインができるのは違う
企画段階からデザインを煮詰めるにはhtml/cssを書くよりイラレ使う方が圧倒的に効率がいいし
デザインができていればhtml/cssのコーディングは大勢でできる
css得意な人に期待されるのは見た目的なデザインのセンスではなく大規模でも扱いやすいcss設計というエンジニアリング的な力だし
デザインが得意な人にhtml/cssのスキルは期待しないし必要もない
うちはそういう分業で機能してる
>>696に出て来るようなデザイナーにhtml/css/jsを書かせるせいでreact/jsxやstyled componentsの導入に困ることもない 確かに>>696って「このやり方には欠陥があります」って自白してるようなものだなw >>716
分かりやすい説明をありがとう
これからはこれ基準にして生きていくわ >>717
かなり特殊な企業な気がする。
Webデザイナーの求人サーチしてみたけどHTML, CSSの知識ない人は
論外みたいな求人だったよ。
これだけ人手不足の中であってもHTML, CSSは必須知識みたいな扱いになっていた。
Webデザインの上流やる人は、デザイン力があるのは大前提で、
HTML, CSSの知識も必須という企業のが多いと思う。
CSSとHTMLの知識がなければフォントの種類、サイズすら決められないし、
適切な解像度すら決められない。
アクセシビリティに考慮したデザインも作れない。 >>719 >>714
Single Page Applicationという名前のとおり
HTMLは最初の1回だけ取得するのがSPAだと思う。 >>720
フォントの話は何の冗談だとしか
アクセシビリティはデザイナー程度のhtml/cssの知識じゃ話にならないだろ
wai-aria知ってるだけでも不十分だからうちは専門のスタッフ育て始めてる
普段からスピーチやハイコントラストモード使ってないと気付けないことも多いし
つまりあれだな、うちは半端なゼネラリストよりスペシャリスト志向ってことだなきっと >>720
うちにいるデザイナーさん（社員もパートナーさんもフリーランスもいる）も採用の時はたぶんhtml/css/js書けたと思うよ（今でも書けるかもしれん）
キャリアを積んでく中で優秀な人はhtml/css/jsを書かなくていい立場になっていったんだと思う
確認したことないけどたぶん 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
31W8K ■ このスレッドは過去ログ倉庫に格納されています
