13/07/21 NY:AN:NY.AN
Java用のWeb Application Frameworkについて語るスレッド
海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない
開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを
比較しながら、最高のフレームワークを探してみるスレッド
前スレ
ｽﾚﾘﾝｸ(tech板)
Web Application Framework のリスト
URLﾘﾝｸ(en.wikipedia.org)
特徴の比較
URLﾘﾝｸ(en.wikipedia.org)
2:デフォルトの名無しさん
13/07/21 NY:AN:NY.AN
【関連スレッド】
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.5
ｽﾚﾘﾝｸ(tech板)
【DI】Java Spring Frameworkを語るスレ 5.0
ｽﾚﾘﾝｸ(tech板)
以上、テンプレ終わり。
需要があるかわからんけど立ててみた。
3:デフォルトの名無しさん
13/07/21 NY:AN:NY.AN
>>1乙
ASP.NETの話題が増えてたしスレタイからJava外してもよかったかもな
あるいはASP.NETは専スレ立ててそっちでやってもらうか
4:デフォルトの名無しさん
13/07/21 NY:AN:NY.AN
どう考えてもASP.NETが他所でやるべきだろ
5:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/07/21 NY:AN:NY.AN
１アクション１メソッドで中に何百ステップ書かれてようと気にしない
量産型PGで生産性に拘るなら当然の選択
7:デフォルトの名無しさん
13/07/21 NY:AN:NY.AN
>>2に追加
△△もっとStruts2の良さを教えてくださいSsssion6
ｽﾚﾘﾝｸ(tech板)
【Java】Play framework【Scala】
ｽﾚﾘﾝｸ(php板)
Tapestryについて語ろうよ！
ｽﾚﾘﾝｸ(tech板)
【Java】Wicket【HTML】
ｽﾚﾘﾝｸ(tech板)
8:デフォルトの名無しさん
13/07/21 NY:AN:NY.AN
>>3-4
ASP.NETとASP.NET MVCのスレはすでにある。
ここはそのままでいいよ
ASP.NET系は一番人気あるフレームワークだから、
どういうスレタイにしてもASP.NET系の話題は出てくる。
ASP.NET MVC
ｽﾚﾘﾝｸ(php板)
【質問】ASP.NETスレ Part7【雑談】
ｽﾚﾘﾝｸ(php板)
【消しゴム】MONOを使ってみるスレ4【じゃない】
ｽﾚﾘﾝｸ(tech板)
>>1 乙
9:デフォルトの名無しさん
13/07/21 NY:AN:NY.AN
結局生ServletとかJSPとか言っているのは開発にスケールもスピードも求められて
いなくて、そのくせ一度作ったサービスを見直しもリニューアルもせず延々と延命
させ続ける客相手の受託開発メインってことかなぁ。面白く無さそう。
10:デフォルトの名無しさん
13/07/22 NY:AN:NY.AN
最近angularjs + playframework2(scala,coffeescript,less)を使い始めたんだけど、すごく使いやすいよ。
.NET MVCと比べても作業効率が高い。でも、scalaだとスレ違いか。
11:デフォルトの名無しさん
13/07/22 NY:AN:NY.AN
Scalaはいずれ抑えたいけど業務アプリだと出番がないな
12:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
Struts1使ってるやつがビジネスセンスどうのこうのw
利益率上げたければ生産性低いStrutsはないだろ
13:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
ScalaはJavaの代替として考えた時期もあったが
うんこフレームワークしかないのでやめた
Play!はsessionがなかったりかなり変なフレームワークで
汎用的に使えるものじゃなかった。
Lift はものすごく使いづらくひどいものだった。
Scalaはコンパイルが遅いのも問題でイライラした。
けっきょく、ASP.NET MVCが最強だった
14:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
ScalaがSession持ってたまるか
何のための関数型なんだか
15:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
ぜんぜんレイヤーが違うじゃん
どんな言語でもセッションは必要だろ
16:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
>>5
商用のなんて使ってもバグなんて直してくれないだろうに……
というのがＯＳＳに流れてついてきた奴の流れじゃろ。
17:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
playframeworkは基本ステートレスだけど、セッション持ってるよ。
まぁ、servletとは全く別物だから取っ付きにくいかもだけど、playの方が扱いやすい。
一言で言うと、Java on Rails。試してみて損は無い。
scalaがコンパイル遅いのは同意。
18:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
play2のview templateがクソだけど、
angularjsと一緒に使うことで生まれ変わる。
19:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
自社プロダクトだからスケールやスピードよりも
より安定してより細かい制御が作りこめて寿命が長くないといけないから
やっぱりJSP&Servletがいいかな。
20:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
Java on RailsをのたまうならGrailsを無視するな～
21:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
Scalaは気になるんだけど、コンパイルの遅さとか、その辺については実際どうなの？
実際に使っている人の話が聞きたいけど。
あと、個人的にはPlayよりScalatraが気になるかな。
22:デフォルトの名無しさん
13/07/23 NY:AN:NY.AN
Scalaは戀塚氏のお気に入り
23:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
JAX-RSはCDIのConversationScopedと組み合わせると業務でも行けそうだ
24:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
Scala推せば通ぶれる、という雰囲気があるのは確か
25:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
ConversationScopedと組み合わせなくても普通に業務で使っているけれどもね > JAX-RS
26:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
>>21
scalaはコンパイルが本当に遅い。ここはなんとかして欲しい。
まぁコンパイルの遅さを差し引いいても、開発効率やメンテナンス効率が高いから全体で見るとそれ程問題ない。
コンパイルなんてほっとけば終わってるし。
Scalatraも使いやすい。Servlet派の人はこっちの方がいいかもね。
>>20
Grails？GroovyはGradleレベルのちょっとした物書くにはいいけど、
本格的なプロジェクトでは使いたくないな。
Groovyの作者もScalaを知ってたらGroovyなんて作らなかったって言ってるからね。
URLﾘﾝｸ(www.infoq.com)
27:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
>>26
印象論や伝聞だけで敬遠されているのならやや勿体ないな > Grails
Grailsの良いところはGroovy云々以前にまずSpring MVCベースのフルスタックの
フレームワークとして一番普及していてメンテもされていること。
Javaで書かれたSpringベースの成果物にWebのUIを与えるのに一番の近道。
あとGroovyに関してはこれで大切なロジックを書くことまでは期待していない。
うちの会社もバックエンドやGrailsで使うにしても抽象クラスの類はJavaでカッチリ
書いている。
あとGroovyはグルー言語としてとても優れていて、Javaでカッチリ書かれたものを
Groovyでサクッと拡張してからデプロイするといった用途に便利。
28:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
おいときますね
下2行は辞めた先輩が実際に歌った歌詞だよ☆ミ
ヤバ 破綻した グルーで補修した
それだけで なんか達成感
大事なのは QCD あと利益率ゥゥゥゥゥッ⁈
コストを 下げなきゃ 基盤の意味がない
29:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
結局普及に失敗したものは廃れる運命だからな
30:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
Hibernate同様にGrailsも認知度の日本国内外の差は妙なところだなぁ。
URLﾘﾝｸ(www.slideshare.net)
PlayとGrailsの比較とか。
URLﾘﾝｸ(www.slideshare.net)
31:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
Scalaやっている人は、参考までに使っているツール(IDE、他)を教えてくれないかな？
32:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
>>31
Eclipseベースは古いバージョンしかつかえない
Scalaスレ情報では
ScalaのIDEはIntelliJ IDEAが一番人気らしいよ
自分で使った感じでもIDEAが一番ましだった。
compile遅いうえに、よいフレームワークがなかったから
俺はscala自体捨てた
言語はJavaよりましだけどライブラリ、フレームワークといった
エコシステムが充実していない。
ScalaはOSSも盛り上がりに欠けている。
33:デフォルトの名無しさん
13/07/24 NY:AN:NY.AN
ScalaはCPUリソースを使い切るような環境でもなければ出番が無さそう
AWSにデプロイできるScalaベースのソーシャルアプリとか出たら話は変わるかも
34:デフォルトの名無しさん
13/07/28 NY:AN:NY.AN
寺田氏曰くGF4はまだ安定版じゃないとのことだがJerseyの2系(今は2.1)も同じかな？
35:デフォルトの名無しさん
13/07/30 NY:AN:NY.AN
roadmapを見るに今年中に4.0.1が出るらしいが
本番で来年出るらしい4.1からかな、商用サポート始めるみたいにあるし
36:デフォルトの名無しさん
13/08/06 NY:AN:NY.AN
The Curious Coder’s Java Web Frameworks Comparison:
Spring MVC, Grails, Vaadin, GWT, Wicket, Play, Struts and JSF
URLﾘﾝｸ(zeroturnaround.com)
ここでもGrails...
Documentationが評価5だけど確かにGrailsの公式リファレンスは使いやすい。
37:デフォルトの名無しさん
13/08/06 NY:AN:NY.AN
JSFが23%ってヤツら狂ってるな
38:デフォルトの名無しさん
13/08/06 NY:AN:NY.AN
URLﾘﾝｸ(taichi.hatenablog.com)
Groovyの基礎的な文法を紹介する所から丁寧に書きました。
だそうだ
39:デフォルトの名無しさん
13/08/06 NY:AN:NY.AN
毎日何かが半額のmanningが今日はGroovy関係
プロモーションコードはdotd0806
Gradle in Action
URLﾘﾝｸ(www.manning.com)
Grails in Action, Second Edition
URLﾘﾝｸ(www.manning.com)
40:デフォルトの名無しさん
13/08/06 NY:AN:NY.AN
制作者がScalaを知ってたら作らなかったとか言ってた言語なのに人気あるんか
41:デフォルトの名無しさん
13/08/07 NY:AN:NY.AN
Scalaを知っていたら敢えて新しい言語を作るまではしなかっただろう
というだけの話で、Groovyが劣っているとかそういう話じゃないだろ
42:デフォルトの名無しさん
13/08/07 NY:AN:NY.AN
Java知っていれば学習コストはかなり低そうだからな～ > Groovy
43:デフォルトの名無しさん
13/08/07 NY:AN:NY.AN
>>40-41
Scalaもコンパイル遅いし大したことないよ
たいして人気もでてない
44:デフォルトの名無しさん
13/08/07 NY:AN:NY.AN
>>40
Grailsだから流行ったフレームワークではなく、まず良く出来たフレームワークが
あって、それを使うことからGroovyを再発見した人も多いのでは。
RailsやPlay!もそうだよね。人気のあるフレームワークがその言語の新規ユーザを
増やす呼び水になっている。
フレームワークとしてはGrailsは良く出来ていると思う。でかいけどね。
45:デフォルトの名無しさん
13/08/09 NY:AN:NY.AN
Glassfish3.1.22なんだけどj_security_checkで認証すると
認証前のリクエストがPOSTだった場合でも認証後に再びPOSTされるんだよな。
なんかChrome見ると302の後にChromeはちゃんとGETでアクセスしてるから
Glassfishが認証フィルタあたりで何かきもいことやってるんだろうけど
HttpServletRequest#login使った手組だとどうにも再現できん。
46:デフォルトの名無しさん
13/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
13/08/10 NY:AN:NY.AN
最後の一行間違った
Glassfishは307を使ってるとか？
48:デフォルトの名無しさん
13/08/10 NY:AN:NY.AN
Glassfishは302を返してるよ。メジャーなブラウザは302にGETを返すらしい。
あとChromeは303にはGET、307には前回と同じメソッドとこちらはちゃんとしてくれる。
どうもGlassfishはj_security_checkの段階ではなく、
次のリクエストで認証してるみたい（Set-Cookieのタイミングがここ）
BASIC認証と動きを合わせるためにきもいことしてるんだろうなぁ
JBOSS ASとかも後で確認する
49:デフォルトの名無しさん
13/08/10 NY:AN:NY.AN
きもいきもい言いすぎ
どうしたのってば
50:45
13/08/10 NY:AN:NY.AN
どうやらこの現象はTomcat側にmaxSavePostSizeってプロパティで設定できるらしいね
Glassfishはどうやって設定するのかまだ分からないけど、JBoss AS7.1.1は無効にしてるっぽい
51:デフォルトの名無しさん
13/08/23 NY:AN:NY.AN
wicketはダメ？
52:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
Viewをサーバ側で動的に生成する仕組みが
そもそもオワコンになってきてる気がする
MVCのMCだけサーバ側で担当してVはHTML5+JS+CSS3
連携はJSONかpjaxで。
53:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
WPFはWebのページアプリの概念を取り込んだが
Webは逆にSDIアプリの概念にシフトし始めてるのかもな
54:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
>>52
またそうやって「JSON返すのはサーバサイドFW不要論そのもの」
「その不要論を言いだすと、Java不要論になるしこのスレも全否定だし、
スレ住人が携わっているであろうサーバサイド開発も全否定」厨を煽る作戦ですね
55:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
誰が一番煽っているんだか
56:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
(・ω<) ﾃﾍﾍﾟﾛ
57:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
サーバ側はJSONだけを返せればそれで良い、…そう思っていた時期が、私にもありました(´・ω・`)
58:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
HTMLフラグメントをサーバから非同期で返す
pjaxてのがあるのか。よさげだな。
59:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
狭義(jQueryプラグイン)のPjaxは何年か前に話題になっただけでオワコン臭
60:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
よくわからんがInnerHTMLに直接代入できるテキストをくれる感じか
61:デフォルトの名無しさん
13/08/25 NY:AN:NY.AN
javascriptでJSONパースしてはめてくって処理が要らなくなるのはええね
62:デフォルトの名無しさん
13/08/26 NY:AN:NY.AN
pjaxは結局動的にHTMLフラグメントを生成するのに従来同様にJSPの類を使う事になる。
なので静的なページが中心で一部だけ動的にしたい場合など無理にJSONでやりとりするより
楽だし、動的でかつクローラブルでハイパーリンク可能にするのもJSON使う場合より手間は
少ない。
63:デフォルトの名無しさん
13/08/26 NY:AN:NY.AN
>>57
一度挑戦したが結局挫折したわー。
最近のサーバーの性能だとよっぽど大規模なユーザー数のアプリじゃないと
そこまでするメリットがない上に実例がなくてだるい。
64:デフォルトの名無しさん
13/08/26 NY:AN:NY.AN
JSONで済む割合はサイト毎に全然違うしょ
スマホネイティブアプリ向けサイト＞＞＞＞シングルページアプリ向けサイト＞＞＞＞旧来的なサイト
65:デフォルトの名無しさん
13/08/26 NY:AN:NY.AN
つーかね、HTMLのフラグメント返した方が更新が綺麗だったり、仕組みが単純だったり、JSONよりそっちの方が良いや、ってなっちゃったりもして。
66:デフォルトの名無しさん
13/08/26 NY:AN:NY.AN
サーバ側でやる処理と、クライアント側でやる処理を
どこで区切るかってだけの話だよね
スマホ向けWebアプリだと、意外とJSONのほうが小回り利いたりする
67:デフォルトの名無しさん
13/08/27 NY:AN:NY.AN
HTMLのフラグメントっていうのは、partial view というか、部分的なHTMLのこと？
(<div> のなかみだけ、とか)
JS で innerHTML でさしかえる用、とか。
68:デフォルトの名無しさん
13/08/28 NY:AN:NY.AN
そんなイメージ
jQuery使うようになってからは素のJS書かなくなって
innerHTMLとかもう遠い昔
69:デフォルトの名無しさん
13/08/29 NY:AN:NY.AN
サーバサイドの人がJSP書きながらちょっとjQuery使うだけならPjaxいいかもね
クライアントサイドの人はBackboneやAngular、つまりテンプレートエンジンや
データバインディング使うから無用だけど
70:デフォルトの名無しさん
13/08/29 NY:AN:NY.AN
TwitterがHTMLのフラグメントを使う様にしたとかいう話ってなかったっけ？
あれって、どういう理由でそうなったの？
71:デフォルトの名無しさん
13/08/29 NY:AN:NY.AN
初回表示が遅くなった対策に一発目はHTML返すよう戻したって話？
表示後は今でもJSON(コンテントタイプはtest/javascriptでgzip圧縮されてる)でタイムライン更新してる
72:デフォルトの名無しさん
13/08/29 NY:AN:NY.AN
デザインサイドだとどの程度ライブラリに依存するのがトレンドなんだい？
jQuery + Normalize.css あたりで頑張るのか、Twitter Boostrapとか使うのか
73:デフォルトの名無しさん
13/08/30 NY:AN:NY.AN
>一発目はHTML返す
HTMLに<script>タグで囲んだJSON一緒にくっつけて
返すとかはよくやるな。リクエスト減らす目的で。
Boostrapは便利なんだけど、アレ使うとLook&Feelがまんま
Boostrapテイストになっちゃうんで、デザインちゃんと
考えてるプロジェクトだと意外と使わない。
CSSの学習素材としては素晴らしいが。
HTML5-Boilerplate + jQuery + 独自CSSって感じかな。
Normalize.cssも使う。
74:デフォルトの名無しさん
13/09/09 05:42:14.14
クライアントサイドでもサーバーサイドでもどちらでも良いけれども、JSONとか
使うREST APIを開発するにあたって認証はどの方式を使っている?
75:デフォルトの名無しさん
13/09/09 10:53:11.74
>>74
サーバサイドの REST API の場合は、クライアントがブラウザとは限らないため、
完全なステートレスでの利用を前提にハンドシェイク後にキーを発行して、
クライアントは受け取ったキーを常にパラメータとして付与しながら API を叩く
仕様にしてる。
一旦キーが発行された後は、サーバ側では、渡されたキーと接続先アドレスを
使って認証の判定をしている。自分のシステムの場合は、複数のツール/システム群から
順に連携して叩かれる事もありうるから user-agent の判定とかはあえて行っていない。
あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、
使われていないキーは一定期間が経過したらどんどん失効（削除）させてる。
実運用では律儀に終了処理なんて呼んでくれない奴の方が多いからね。
誰もが使えてもいい公共性のある API なら、そもそもそんな仕掛けも要らないだろうけれど、
緩い個体の識別から、サーバ側に登録された ID が持つ権限内容との紐付けをした上での
識別までハンドシェイク部分の作り方次第で自由に切り替えられるから、自分が最近作った
システムは大枠としてはどれもそういう作りにしてるかな？
76:デフォルトの名無しさん
13/09/09 11:22:00.96
>>75
> サーバ側では、渡されたキーと接続先アドレスを使って認証の判定をしている
接続元IPアドレスを認証に使うのは、IPアドレスの偽装もあり得るので危険なのでは？
と思ったが、 >>75 さんの環境がイントラ内とかだったら、わりきってそれもありかな、と思った。
(イントラネット内で、ちゃんとIPアドレスや、それがどんなサーバなりスイッチか、などが管理されていれば)
77:デフォルトの名無しさん
13/09/09 12:57:39.68
IPアドレスは保険みたいなもんで認証の主はキーでしょ？
78:デフォルトの名無しさん
13/09/09 13:53:43.53
AWS方式でリクエストをHMACで署名。
79:デフォルトの名無しさん
13/09/09 16:01:47.48
巷のAPIはSSLを使った上でAPI Keyでリクエスト署名ってパターンが多い気がする。
うちもそうしている。
HTTP Method name + Request Path + Timestamp + bodyからHMAC-SHA1計算して
HTTPヘッダに埋め込む。
ただこれだとクライアントの開発時にAPIをテスト目的でcurlとかで叩くことが
面倒なので、同じキーでBasic認証も出来るようにしている。
80:デフォルトの名無しさん
13/09/09 23:53:31.08
SSL+BASICじゃダメなの？
81:デフォルトの名無しさん
13/09/10 00:51:23.89
サーバではコミットしたけどクライアントで反映失敗とか
セッションハイジャックをかんがえると
OTPとはいかないまでもシリアル値くらいないとダメな場合もある。
82:デフォルトの名無しさん
13/09/10 04:06:22.73
>>80
認証だけなら良いと思うよ。SSLをかましているのであれば。
ただSSL経由とはいえ秘密鍵を平文で投げたくない、かつステートレスにしたい
のであれば自ずとリクエストと秘密鍵から計算したハッシュ値で署名するという
解決策にたどり着く。
仮にリクエストがのぞき見されても秘密鍵は漏れないし、ハッシュ値を計算する
データの中にタイムスタンプを含めておけばリプレイ攻撃にも多少は強くなる。
83:デフォルトの名無しさん
13/09/10 07:09:16.75
なるほど、勉強になります。
84:デフォルトの名無しさん
13/09/10 18:00:55.33
>>82
>>75と同じ人だよね？
>>75じゃサーバからクライアントにキーを渡すことになってるけど、それが秘密鍵？
だとしたらレスポンスのぞき見されたら秘密鍵漏れない？
「SSL経由とはいえ秘密鍵を平文で投げたくない」になってるのか疑問なんだが
さらに、「かつステートレスにしたい」と続いてるが>>75の以下を見るにステートレスに
なってなくね？
> あとは通常のサーバセッションと同じく、サーバ側のスレッドでキーを定期的に監視し、
85:デフォルトの名無しさん
13/09/10 19:20:04.33
>>84
違う人です。すまん。
86:デフォルトの名無しさん
13/09/10 20:34:00.07
>>85
別人か、正直すまんかった
それでクライアントの秘密鍵ってどう扱ってる？
サーバから渡すんじゃ「SSL経由とはいえ秘密鍵を平文で投げたくない」は難しそうなんだが
クライアントがイントラ内の別サーバなら楽だけどJSとかだと…
87:デフォルトの名無しさん
13/09/10 21:25:30.82
>>86
API Keyはセッション毎の使い捨てではなく永続的なものね。
うちのシステムでは顧客、というかデベロッパにはまずユーザ登録をしてもらって、あとは
Webブラウザから管理ダッシュボードにログインしてAPI Keyを好きなだけ生成したり既存の
キーを無効にしたり出来る。
秘密鍵の文字列はまぁ、管理ダッシュボードのWeb画面からコピペw
でもAPI Keyを使った認証を提供しているサービスはこのやり方が多いと思う。
88:デフォルトの名無しさん
13/09/18 22:43:53.60
画面をさくさくっと作っていきたいんですが、なんかいいフレームワーク無いですかー？
89:デフォルトの名無しさん
13/09/29 11:59:59.03
>>88
ASP.NETがおすすめ
90:デフォルトの名無しさん
13/09/29 17:43:57.35
貴方が書き込んだのはこの銀のループするスレですか?
それともこちらの金の過疎るスレですか?
91:デフォルトの名無しさん
13/09/30 08:36:15.59
>>88
好きなもの使いなはれ
URLﾘﾝｸ(en.wikipedia.org)
92:デフォルトの名無しさん
13/10/01 14:51:21.87
Grails2.3か。
新機能はともかくivyを捨ててMavenと同じ依存性解決エンジンを使うように
なるのが嬉しいな。SNAPSHOTやclassifier周りのタコな動作がようやく解決。
93:デフォルトの名無しさん
13/10/08 21:16:15.34
Struts2もSpring2もまだ現役だというのにSeasar2ときたら…
94:デフォルトの名無しさん
13/10/09 22:00:27.05
やっぱり日本産は駄目だな！
95:デフォルトの名無しさん
13/10/09 22:03:15.11
ひとめぼれ、うまー
96:デフォルトの名無しさん
13/10/09 23:27:12.84
>>93
うちSeasar2バリバリ現役です・・・。
Spring2はいいとして、Struts2なんて欠陥品だろ。
97:デフォルトの名無しさん
13/10/09 23:31:27.53
>>95
時代は今、コシヒカリですよ！
URLﾘﾝｸ(i.imgur.com)
98:デフォルトの名無しさん
13/10/10 00:42:32.12
そこでStruts1.2が現役な私の会社の出番ですよ。
99:デフォルトの名無しさん
13/10/13 16:00:34.45
>>93
今更GWTに手を出そうとしてる人でしょ？
100:デフォルトの名無しさん
13/10/13 16:12:20.17
>>94
そのとおり
SpringはRod Johnson抜けても続いてる
個人に依存しないビジネスとして成立してるわけ
日本はいつまでも個人のモチベーション頼み
そのくせ応援しないですぐdisる
OSSで身を立てるにはこの国は地獄だぜヒャッハー
101:デフォルトの名無しさん
13/10/13 18:14:47.77
>そのくせ応援しないですぐdisる
スマホアプリのストアのレビュー見ててもそう感じるな。
AppStore、GooglePlayともに。
無料アプリなのに、ちょっとバグがあるとか自分の端末では
動かないってだけで、鬼の首を取ったようなdisりかた。
スマホ向けアプリ作るのは海外向けがいいな。
国内市場向けに作っても旨みは少ない。
102:デフォルトの名無しさん
13/11/08 16:41:59.01
某ブログでそろそろSeasarは終わりでいいよね、JavaEEも悪くないという話をやっているけど
日本でSpring等々ではなく和製FWが広まって萎んで今微妙な状況になっているのはつくづく
ドキュメントやコミュニティの言葉の壁の問題なのだなぁと思う。
103:デフォルトの名無しさん
13/11/08 19:29:03.36
>>102
盛り上がったのは普通にseasarの出来がよかったからだし、衰退したのは開発ストップしたからだろ
104:デフォルトの名無しさん
13/11/08 22:11:18.14
SpringMVCでweb開発してるけど、いったん設計と実装の仕組み整えちゃえば
あとは仕様が増えても基本的に、コントローラ、インタフェース、サービス
周りのコピーでガンガンいけるから、自分的にはSpring一択だな。
105:デフォルトの名無しさん
13/11/09 02:04:11.76
>>102
クライアント側の新しい機能ならほしいかもしれないが、
サーバー側の開発って別にそんな新しい機能いらないんじゃないかねってのはある。
あえて新しくする必要がないというと叩かれるのかもしれんがそんな感じ。
106:デフォルトの名無しさん
13/11/09 09:09:47.92
Struts1.2＋内製フレームワークをJava5で動かしている弊社が最強です。
107:デフォルトの名無しさん
13/11/09 09:18:39.71
webアプリだとサーバ側はたしかに、だいたいやること決まってきてるしな。
モデル側処理とか認証周りとかバッチとかサブシステム連携とかviewに必要な情報の生成くらい。
フロント側は最近はブラウザの表現力と処理能力上がってるから
JSPとかのサーバーサイドテンプレート使うよりは、jQuery使ったり
Backbone.jsやAngulerJSみたいなフロントエンドMVC使うケース増えてる。
サーバーサイドとはRESTでやりとりできればいいし。
108:デフォルトの名無しさん
13/11/09 12:10:01.79
>>102-103
開発を継続する人材が集まらないのは言葉の壁の問題といえるな
109:デフォルトの名無しさん
13/11/22 03:31:52.24
Vaadinってどうなの？
110:デフォルトの名無しさん
13/11/22 13:52:04.12
>>104
SpringMVC関係なくね？
111:デフォルトの名無しさん
13/11/26 23:06:10.99
>>109
それ、俺も知りたい
vaadin日本語ドキュメント少なすぎて涙出るよねー
皆さんは画面をどうやって作ってますか？使っているフレームワークを教えて頂きたいのですが
デザイナーに丸投げしているって回答以外にあったら教えて頂きたい
GWTをここ数ヶ月勉強してみたのですが、GWTは微妙な気がします
112:デフォルトの名無しさん
13/11/29 23:28:49.51
自分の場合、今は画面はサーバサイドで作らなくなった。
HTML5+CSS3であれこれやってる。
こういう画面デザインの事例見てると、綺麗に作るには
画面は画面でちゃんと作りたくなる。
URLﾘﾝｸ(www.pinterest.com)
URLﾘﾝｸ(pttrns.com)
URLﾘﾝｸ(www.uiparade.com)
113:デフォルトの名無しさん
13/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
13/12/01 11:15:32.04
>>112
そんな感じのリッチな画面を作りたいんです。
画面周りを手書きするのはよくあることなので我慢できますが、
javascriptを手動でデバッグするのだけは避けたいなと思いました。だから、GWTを勉強してみました。
結果、GWTは遅すぎてSSDマシンじゃないと厳しいってことがわかりました。
会社では自分の気分でマシンを変更できないので、GWTを使うのは難しいという結論になりました。
>>113
普段、Flexを使って開発しているので、Flexライクなjava frameworkが欲しいなーと思いました。
Flexは非同期処理基本だし、画面周りの制御が難しい(と言うより、処理速度が遅い）のがダメなところですよね。
javafxはflexのパクリだと思うのですが、javafxのweb版みたいなのがあればいいですよね
JSF勉強してみようかなって思いました
115:デフォルトの名無しさん
13/12/02 12:33:50.80
何も分かってないのが良く分かった
116:デフォルトの名無しさん
13/12/03 23:01:57.91
>>115
どこらへんが
117:デフォルトの名無しさん
13/12/04 22:23:08.22
>>114
サーバー側の仕組みに比重を置いてリッチなUI/UXを実現するのは不可能だよ。
見栄えについてはCSS3必須。その見栄えに命を吹き込むのがJavaScript。
サーバーサイドでできる範囲は、HTML5+CSS3+JSが育って実をつけるための
大地と水と肥料を用意すること。
GWTがどうとかって話じゃないことだけは確か。
118:デフォルトの名無しさん
13/12/05 00:11:39.37
>>117
GWTについて知らないでしょ。
知っていればサーバーサイドが云々とか言うコメントは出ない。
119:デフォルトの名無しさん
13/12/05 02:18:51.42
>>118
あー、すまんかった。
GAEと勘違いしてた。
120:デフォルトの名無しさん
13/12/05 11:24:55.81
GWTって今でもメンテされてるの?
GWTが楽ってのは聞いたことがあるけど、結局ブラウザ側のUI/UXを作り込むなら、
jQueryとかを直接使った方がいいと思っているのだけど・・・
121:デフォルトの名無しさん
13/12/05 16:20:11.52
jQuery を直接使って特に問題が起こらないならば、それで実現すれば良いのでは？
GWT などは Java だけで RIA がサポートできる所とかがポイントなわけですから、
（自分は使ったことないからあれですけれど）開発対象、人員、保守性、工期とか
色々踏まえて考えれば、状況次第ではアリな気がしています。
逆に凝った UI が要らなければ、旧来型の使い慣れたフレームワークや
テンプレートエンジンの方が開発も運用も過去資産も含めた実績があるので
トータルで安定するでしょうし、部分的に凝った UI が必要なら、そこだけを
重点的に対策した方が無難だと考えてしまいますね。
122:デフォルトの名無しさん
13/12/05 22:11:40.25
GWTはクオリティの高いUI/UX作るにはいろいろ役不足なイメージしかないな。
jQueryとその周辺プラグインのほうが、世界も広いし圧倒的に充実してるのと
Look&Feelに関しては、CSS3と各種CSSフレームワークで大抵のことはこなせる。
GWT採用しちゃうと、どうしてもGoogle風味から抜けられなくなるでしょ。
123:デフォルトの名無しさん
13/12/06 06:46:40.59
GWTとjQueryはちょっとレイヤーが違うので比較は出来ないかな。
jQueryはイベント周りの昨日とかjQuery UIはあるけれども総体としてはDOMの
直接操作を基本とした低水準(悪い意味じゃ無いよ)のライブラリ。
レイアウトや装飾はHTMLベースで記述して、そこにインタラクションをjQuery
で装飾していくイメージ。
他方でGWTは自身のレイアウト記述とウィジェットライブラリを持った一つ上の
レイヤーのツールキット。基本的には用意された部品を組み合わせて画面を
作る。
スタイリッシュで凝ったUIは作りにくいけれども、事務事務したおっさんくさい
UIを手っ取り早く作るのには結構便利 > GWT
124:デフォルトの名無しさん
13/12/06 11:46:30.47
>>123
これだけ読むとGWTはJSFと競合しそう
125:デフォルトの名無しさん
13/12/07 23:22:13.02
JSFってすごい難しいね
全然分からないや
126:デフォルトの名無しさん
13/12/08 03:06:58.87
FreeMakerがいい感じ
127:デフォルトの名無しさん
13/12/08 08:12:33.17
テンプレートとしてはGSPはええで。
128:デフォルトの名無しさん
13/12/08 16:23:40.46
GSPって、今でもGrails縛りなん？
129:デフォルトの名無しさん
13/12/08 22:34:18.01
JavaSEとJavaEEの違いで、SEにはJDBCが入っているが、EEには入っていない。
これは、EEに含まれているEJBの中にJDBCの機能が入っているからだと、納得してよいでしょうか？
130:デフォルトの名無しさん
13/12/08 22:57:00.51
JavaEEはJavaSEを含んでるから
131:デフォルトの名無しさん
13/12/08 23:02:22.74
>>130
なるほど。ありがとうございます。
132:デフォルトの名無しさん
13/12/08 23:09:42.71
中小企業の現行システム（旧来のクライアントサーバーシステム）を
Webシステム化するのですが、JavaEE＋JSF＋？・・・を考えています。
しかし、JavaEEは、中小企業レベルでは重いかなと心配です。
やはり、JavaSE + Strus2 + ・・・とかで、行うべきでしょうか？
サーバーのハード機能が良くなっているのでJavaEEでも問題ないでしょうか？
133:デフォルトの名無しさん
13/12/08 23:15:42.24
一番いいのはASP.NETだけどJavaじゃないとだめなの？
134:デフォルトの名無しさん
13/12/08 23:20:38.05
>>133
元請けの中小SIerが、Javaを希望してきているのです。
135:デフォルトの名無しさん
13/12/08 23:22:54.72
あー、コレ失敗するパターンやわ。
136:デフォルトの名無しさん
13/12/08 23:26:57.59
言語だけ指定されたとしたら、その元請は馬鹿だなｗ
137:デフォルトの名無しさん
13/12/08 23:34:10.39
>>135,>>136
Javaのシステムを他にも横展開したいようです。
それと、.NET系はコストが掛かるのがネックみたいです。
138:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/12/09 02:55:38.46
既にStrutの蓄積があるならともかく今から始めるなら普通にJavaEEかSpringMVCで
良いんじゃね?
元請けがJavaの経験あるなら彼らがそれを使い回すのは普通に合理的判断だしそこ
に.Net提案したところで干されるだけでしょ。
140:デフォルトの名無しさん
13/12/09 02:59:40.78
>>138
Windows認証とベーシック認証を比べる人にこの分野のアドバイスはあまり聞きたくないと思う。
141:デフォルトの名無しさん
13/12/09 03:16:26.31
>>140
何がおかしい？
認証方法でASP.netのトータルのライセンス料金が
大きく変わるんだから触れるのは当然だろう
Windowsの認証を使わなければ安くなる
あんたこそライセンスなにも知らないんじゃないか
142:デフォルトの名無しさん
13/12/09 05:58:15.33
Java 前提で話が進んでるのに、.NET と騒いで簡単に変わるものなのかな？
.NET の方が上手く扱えて交渉できそうなら、それも一つの解だと思います。
>>132
何を基準に重そうと判断してるのか外野からだと理解できないです。それより、
そのような質問をしてる時点でそもそも自分たちで作れるの？という方が心配・・・。
どんな高性能なフレームワークや素晴らしいアーキテクチャを採用してても
根幹の設計や主要な実装を誤れば低速でポンコツなものに仕上がるでしょう。
開発メンバーのプロジェクトと利用技術に対する理解の方が重要な気がします。
既に自分達で実績を持つ慣れた構成があるなら、それをベースに研究開発的要素を
極力無くすのが着実なゴールを取るための堅実な手法だと考えますが、
そういった構成が無いのであれば、時間のある内にさっさと活用する技術要素を
調査して開発メンバーで制御できる構成にまとめてしまうのが無難でしょう。
他人に言われて選定しても扱えない/向かない技術だった場合、意味がありませんので。
もっと細かいことを評価できる材料が挙げられれば、どのフレームワーク構成が
良いか？とか、具体的なアドバイスも得られやすいかもしれません。
143:デフォルトの名無しさん
13/12/09 07:10:54.44
>>141
認証のプロバイダとメソッドの区別のつかない人がウェブアプリの開発について何が言えるの?
あと中小のクラサバをWebアプリ化って多分イントラ向けでしょ。
普通にCALの購入が必要なパターンだと思うけど。認証方式関係ないし。
144:デフォルトの名無しさん
13/12/09 07:42:50.22
>>133
すれも読めない馬鹿
145:デフォルトの名無しさん
13/12/09 09:05:07.01
>>132 です。
みなさんアドバイスありがとうございます。
JavaEE + SpringMVC + ・・を検討してみます。
JavaSE + Struts + 手作りのDAOもどき の経験しかないので
本当は、JavaEE + SpringMVC + ・・は避けたいのですが・・・・。トホホ。
146:デフォルトの名無しさん
13/12/09 09:44:11.74
自分たちで作れる＝お守りできる技術で作るのが一番。
新規の案件で新規の技術を使うとかリスクの塊じゃん。
新しい技術使いたいなら社内案件とか無難な奴でやっとけ。
ちなみに俺ならWicket+JPAかな、一番慣れてるから。
147:デフォルトの名無しさん
13/12/09 10:22:56.64
>>145
>JavaSE + Struts + 手作りのDAOもどき の経験しかないので
トホホだろうね
148:デフォルトの名無しさん
13/12/09 11:23:30.09
JavaSEでWebアプリって作れるの？
149:デフォルトの名無しさん
13/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:デフォルトの名無しさん
13/12/09 21:51:40.90
>>149
その構成でログインや認証ってどうやります？
151:149
13/12/09 22:32:02.72
>>150
（要件のリッチ度によるが、) ユーザ認証・認可はアプリのレイヤではやりたくない。
ユーザ認証や認可は、JAASやSSO とブラウザ (とユーザ) の間で、勝手に解決してもらって、
アプリからは、何も考えずに req.getRemoteUser() なり req.getUserPrincipal()
でアカウント名や権限グループが取れるのが ... [作り手]としては理想。
そうなるように、よくよく費用対効果を説明して、お客さんに勘弁してもらうと、
後々双方とも幸せになれる。
（認証・認可を作りこむと、テストケースが爆発 ... の割にはユーザビリティ
の向上はごくわずか）
あと、JAAS の認証は多少融通が効きます。（３回失敗で５分ロックなど)
Glassfish、JBOSS なら既存の認証モジュールを参考に自作の認証モジュール
を作って差し替えることができる。
商用のコンテナの場合でも聞けば、やり方を教えてくれるはず。
152:デフォルトの名無しさん
13/12/09 23:40:25.11
>> 151
そういえば、Glassfishの商用版がなくなったらしいね
>>138
> ASP.netは安いものだよ。
> .NETが高いとか言ってるようではそのSIerのレベルは怪しい。
おれも、そう思うわ
153:デフォルトの名無しさん
13/12/10 05:20:10.23
どうしてもJavaでなければいけない理由がないなら
フルスタックのフレームワークでやるほうがはるかに楽だよな
3大人気の、ASP.net、Ruby on Rails、Djangoあたりで
いろんなライブラリを組み合わせなければいけないJavaはめんどくさい
保守のコストもかかる
154:デフォルトの名無しさん
13/12/10 05:29:18.25
フルスタック必要ならGrailsで良いじゃん。Javaの資産使えるし。
155:デフォルトの名無しさん
13/12/10 08:41:45.63
>>153
おまえなんでこのすれにいるの？
156:デフォルトの名無しさん
13/12/10 09:18:24.81
たしかにw
157:デフォルトの名無しさん
13/12/10 09:35:55.95
>>155-156
言語はJava8でいくらかましになるが、
まともなフルスタックのフレームワークすらないJava
Javaの痛いところつかれて反論できなくなって人格攻撃か
なさけない奴らだな
158:デフォルトの名無しさん
13/12/10 10:44:07.22
>>157
すれちだろ
159:デフォルトの名無しさん
13/12/10 13:37:54.00
>>157
Javaが嫌なら、スレから出て行けよ
スレタイも読めないのかこの池沼は
160:デフォルトの名無しさん
13/12/10 16:42:40.75
ASP.netくんの言いたい「フルスタックフレームワーク」が何を指すのかようわからんが・・・
デプロイ環境からORM、View生成まで、ウェブアプリケーション開発に必要なものが全部
揃っているAPI Frameworkと言う意味ではJavaEEと標準実装であるGlassfishがそうだろう。
Rails風のCoC重視でコマンドラインも併用したRAD環境であればGrailsやRooがある。
161:デフォルトの名無しさん
13/12/10 17:25:48.81
>>160
GrailsはGroovyだからJavaと主張するには無理がある
GroovyなんてJavaの負の部分を引きずった醜い世界
JavaEEはWebアプリケーションフレームワークというよりライブラリ
「フルスタック」とはなにか分からないのもJavaしか知らないからだろうな
162:デフォルトの名無しさん
13/12/10 18:28:47.80
>>161
>GrailsはGroovyだからJavaと主張するには無理がある
使ってから言えばよいのに。
163:デフォルトの名無しさん
13/12/10 18:47:04.53
>>162
Grailsは使ったことある
動作ももっさりだった
これでもJavaの中ではましなのかもしれないが
他の言語の人気フレームワークより使いづらかった
あと中身はSpringがベースでしょう
軽く触ったからそれくらはしってる
164:デフォルトの名無しさん
13/12/10 20:29:35.41
ASP.netってVS無しでまともに開発できんの？
マカーでIntelliJユーザなんだが。
165:デフォルトの名無しさん
13/12/10 20:39:44.95
まかーはすれちもわからんのか
166:デフォルトの名無しさん
13/12/10 21:45:56.04
Glassfishって使い勝手とかどうなんでしょう？
167:デフォルトの名無しさん
13/12/10 22:16:07.56
ASP.netはスレチだが開発環境の広さという意味ではASP.netとそれ以外では歴然と差があるな。
JavaもEclipseが走れば開発環境は何でもよいという人も少なくないのでは。
168:デフォルトの名無しさん
13/12/10 22:23:58.35
>>167
すれち
169:デフォルトの名無しさん
13/12/10 22:27:56.81
Javaの開発環境の広さはスレチじゃないと思うが。というか実際何使って開発してる？
170:デフォルトの名無しさん
13/12/10 22:38:21.63
>>167
すてまおつ
171:デフォルトの名無しさん
13/12/10 22:40:54.87
>>169
パソコン
172:デフォルトの名無しさん
13/12/10 22:43:29.33
>>169
窓
173:デフォルトの名無しさん
13/12/10 22:46:37.34
>>169
キーボード
174:デフォルトの名無しさん
13/12/11 01:23:11.07
>>169
Eclipse
175:デフォルトの名無しさん
13/12/11 01:47:27.90
>>169
Vi
176:デフォルトの名無しさん
13/12/11 01:51:32.47
>>169
TOTO製
177:デフォルトの名無しさん
13/12/11 16:19:52.57
>>166
使い勝手を気にする用途に使ってるやつはいないだろう
178:デフォルトの名無しさん
13/12/11 19:39:42.11
GlassFishが商用サポート切るとかたまったもんじゃないな
JerseyからRESTEasyに切り替えないといけなくなりそうだ
179:デフォルトの名無しさん
13/12/11 19:45:15.93
やっぱasp.netが一番いいな
180:デフォルトの名無しさん
13/12/11 20:37:30.52
>>179
ポエムは真板へ
181:デフォルトの名無しさん
13/12/11 23:28:37.07
>>179
Web Froms時代はいまいちだったけど
ASP.net MVCは最高だよな
182:デフォルトの名無しさん
13/12/11 23:32:27.89
>>181
すれち
183:デフォルトの名無しさん
13/12/11 23:34:15.13
MS厨はなぜ粘着するのでしょうか？
184:デフォルトの名無しさん
13/12/11 23:45:27.57
ステマ
185:デフォルトの名無しさん
13/12/11 23:47:27.13
>>182-183
>>171-176のような無駄レスは文句をいわないくせに
ASP.netの文字が出ると感情的に批判してくるのな
186:デフォルトの名無しさん
13/12/11 23:51:42.85
>>185
ここでやってくれ、さようなら
ｽﾚﾘﾝｸ(win板)
187:デフォルトの名無しさん
13/12/11 23:57:24.28
>>186
開発と関係ない板のURLはって馬鹿じゃないの？
少しはJavaの話でもすれば？
188:デフォルトの名無しさん
13/12/12 00:06:14.84
すれちに馬鹿といわれちゃった、わーん！！！
189:デフォルトの名無しさん
13/12/12 00:07:31.28
ておばちゃんか、しょうがねーな
190:デフォルトの名無しさん
13/12/12 10:16:01.45
真性のカスだなｗ
191:デフォルトの名無しさん
13/12/15 20:46:37.58
URLﾘﾝｸ(news.mynavi.jp)
Spring Framework 4.0正式版リリース - Java 8、Java EE 7に対応
192:デフォルトの名無しさん
13/12/18 00:19:57.11
すれちだろ
193:デフォルトの名無しさん
13/12/18 00:33:41.58
GlassFish使っててJBossへの乗り換えを検討してる所は少ないの？
JerseyMVCとか試そうかと思ってた矢先だったからなぁ
194:デフォルトの名無しさん
13/12/20 12:37:54.79
一生プログラマーでいたいならフルスタックとかで楽すればいいよｗ
195:デフォルトの名無しさん
13/12/22 00:56:53.89
あんだけ某関係者の人がTomcatはオワコンこれからはGlassFishとかとDisってたのに
いつの間にかGlassFishの方がオワコンになっていたのか。
まあ、今もTomcat使って古いフレームワーク（StrutsとかSAとか）で動かしてる（爆）だからどうでもいいけど。
196:デフォルトの名無しさん
13/12/22 02:58:54.87
Java自体が終わりそうだけどね
ライブラリがクソすぎる
197:デフォルトの名無しさん
13/12/22 07:51:22.48
>>196そうか残念、さようなら
198:デフォルトの名無しさん
13/12/22 08:45:35.32
asp.netが強すぎるからな
199:デフォルトの名無しさん
13/12/22 09:49:22.90
>>198
そうか、どうでもいいけど、さようなら
200:デフォルトの名無しさん
13/12/22 13:04:11.82
Tomcatは起動が重いんだよな。
Jettyが軽くていい感じなんだけど、Tomcatに比べて日本語情報が少ない感じ。
JDBC使うのに、JNDI周りの情報も少ない。
201:デフォルトの名無しさん
13/12/22 17:38:03.86
JBossが最強だろ
202:デフォルトの名無しさん
13/12/22 18:44:49.04
ローカル試験で使う分にはWinstoneも軽くて良いですよ。
なにせjarファイル1個で動いて、160kbくらいだし
203:デフォルトの名無しさん
13/12/22 20:04:05.19
JSON返すだけとかなら、Netty直利用とかも良いですよ。
まあ、ネタはおいといて、Jetty組み込んででExecutable WAR配布とか、利用側はお手軽で良いな。
Javaでもセルフホストしやすい軽量スタックとか、そっちが流行らないかな～。
204:デフォルトの名無しさん
13/12/22 20:05:57.66
組み込みサーバー＋JavaFXは今後の選択肢として大いに有り得るらしい
JAX-RSとCDIが使えないほどの軽量サーバーならちょっと勘弁だが
205:デフォルトの名無しさん
13/12/22 20:08:51.41
JAX-RSの実装もCDIの実装も、アプリケーション中に含めて組込サーバーといっしょに配布するで良いじゃん。
206:デフォルトの名無しさん
13/12/22 20:25:15.91
JBoss覚えるか。どう考えても最強だわ
207:デフォルトの名無しさん
13/12/22 20:39:18.03
jbossって起動に10分掛かるだろ
208:デフォルトの名無しさん
13/12/22 20:42:11.68
情弱乙
209:デフォルトの名無しさん
13/12/22 20:43:02.29
WildFly
210:デフォルトの名無しさん
13/12/22 20:59:18.59
richfacesでイベントを呼び出せない、俺涙
211:デフォルトの名無しさん
13/12/22 22:29:12.90
>>209
8.1が出てからだろ
212:デフォルトの名無しさん
13/12/23 15:42:07.91
>>209
WildFlyってRHELとFedoraの関係なんだろ？
名前変えられると、テンション下がるわー
213:デフォルトの名無しさん
13/12/23 16:25:18.46
>>212
横だけど、間違ってる、名前の問題だけ
214:デフォルトの名無しさん
13/12/23 16:31:32.49
むしろASがエンタープライズで使えない誤解すら生んだろうね
215:デフォルトの名無しさん
13/12/24 20:16:25.04
JSFで画面作ってる時に、URLﾘﾝｸ(java.sun.com) ってのを使うけど
これ、primefaceとかrichfacesと何が違うの？
216:デフォルトの名無しさん
14/03/10 05:55:51.25
age
217:デフォルトの名無しさん
14/03/10 07:39:49.81
3年ニートしてる間にseasar2ってオワコンになってたのかよ
使われなくなるのって開発ストップしたからバグとかセキュリティホールが見つかっても
修正されないからって意味合いが大きいからなん？
218:デフォルトの名無しさん
14/03/10 15:24:45.00
作りが悪いからに決まってるじゃん
名前が違うだけのspringだし
独創性がないから宣伝はspringの悪口だけ
目玉のHotDeployはバグバグで動かないのにサクサク開発()
とどめに後発のPlay Frameworkがもっと高い技術力とサポートで
同じようなことしてるからまるで存在意義がない
219:デフォルトの名無しさん
14/03/10 18:54:22.97
スプリングググったらver4まで出ててワロタｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
初代スプリング触ったときゴミすぎで2度と触りたくないと思ったけど進化してたんだな
220:デフォルトの名無しさん
14/03/10 20:45:17.51
SpringMVC、使いやすいよ。
RESTと親和性高いし。
もうこれ以外使うきしない。
221:デフォルトの名無しさん
14/03/10 20:54:36.49
俺はPlayを使うね！！
222:デフォルトの名無しさん
14/03/11 02:51:10.09
javaしかやったことないから他の言語のwebアプリ状況がどんなもんか知らんけど
純粋にjava嫌いな層ってフレームワーク多すぎていろんところで開発スタイルバラバラすぎるからじゃねーの
勤勉でもないから触ったことないフレームワーク使ってるとお作法覚えるのもたりーんだよな
223:デフォルトの名無しさん
14/03/11 03:14:13.37
>>222
javaやったことなくてそろそろ手を付けようかなと思ってこのスレ見てるけど、
設定含めすべてにおいてめんどくさそうだからじゃね。
もちろんフレームワークの選別とか作法とかも分からないってのはあるが。
224:デフォルトの名無しさん
14/03/11 07:23:44.74
めんどくさいというイメージはだいたいStrutsのせい
225:デフォルトの名無しさん
14/03/11 07:42:49.43
ASP.NETが神すぎる
226:デフォルトの名無しさん
14/03/11 12:51:19.90
型コンバートやバリデーションをコントローラでやって
アノテーションつけまくる最近のスタイルが嫌いだ
227:デフォルトの名無しさん
14/03/11 17:07:04.92
Convention over Configurationとかってまだ流行ってんの？
228:デフォルトの名無しさん
14/03/11 17:20:32.04
Java言語をマスタしても、フレームワークのお作法覚えないとダメだし
フレームワークも色々で、プロジェクトによっては勉強しなおさないといけないし
言語だけマスタしてた時に比べて、大変だよね。
229:デフォルトの名無しさん
14/03/11 17:28:37.61
>>227
Play frameworkは、さほどCoCにこだわってないように見えるね。
ルーティングは、routeファイルに必ず書くし。
230:デフォルトの名無しさん
14/03/11 19:30:14.12
>>228
チームで開発するときはアーキテクトさんが更にもう一枚「オレオレフレームワーク」でくるんで使わせるのではないか？
設定ファイル等々にしても集中管理するから末端プログラマが触る機会なんてないはず
プログラマに素のままのフレームワークを使わせるなんて危険すぎるが
231:デフォルトの名無しさん
14/03/11 22:35:21.22
一周まわって、フレームワークなしのサーブレットに、必要最低限の機能を持つ基底クラスだけ自分で作って使うのがベストだと思う。
232:デフォルトの名無しさん
14/03/11 22:58:08.03
>>230
オレオレ作った場合、プログラマに使い方を説明してる？
233:デフォルトの名無しさん
14/03/11 23:54:00.32 Y7xUI5Hj
>>232
APIドキュメント、サンプルプログラム、コメント付き各種設定ファイルなど一通り揃えて、取り合えずば簡単に動くものを用意
説明用の資料パワポや説明会は必要に応じて。
234:デフォルトの名無しさん
14/03/14 00:09:52.72 K0sLkIAE
更新止まったActiveObjectsやBeanKeeperの後継とかなくて
結局JPA + Hibernateに落ち着くのか
235:デフォルトの名無しさん
14/03/14 00:16:16.03 BtBBLClg
Seamってまだ息してんの？ｗ
236:デフォルトの名無しさん
14/03/14 03:00:36.47 vTPAugkR
JAX-RSはフォームデータを渡した場合は@FormParamで受け取るしかない？
Servlet感覚で可変のフォームデータを受け取ってパースしたかったんだけど…
237:デフォルトの名無しさん
14/03/15 15:19:19.23 K2uN+xbt
アノテーションもりもりMVCとかO/Rマッパー考えたやつはセンスないな
素直にServletとJDBCで十分じゃまいか
238:デフォルトの名無しさん
14/03/15 15:32:33.28 JfWd/5x0
>>237
狂おしいほど同意
239:デフォルトの名無しさん
14/03/15 15:33:42.26 ODzNcjwn
servletでmemcached使いたいんですが
MemCachedClient mcc = new MemCachedClient();
mcc.set("name", "Naoki Takezoe");
ってやったあとmccのインスタンスはどこにしまっておけばいいんですか？
240:デフォルトの名無しさん
14/03/15 16:16:57.22 ha3L2y5+
>>238
開発者が100人位いるような大規模開発だとどうするの？
皆が勝手にConnection.prepareStatementとかやるわけ？
241:デフォルトの名無しさん
14/03/15 16:27:57.63 q7u7Ew65
100人も集めて何作ってるんだよｗ
242:デフォルトの名無しさん
14/03/15 16:33:36.62 4evGY2gy
案件規模とかそういうのはどうでもいいんだけど、
IDEの恩恵に頼って楽してコード書きたいから、そもそも今更自前でSQL書きたいとは思わないな。
あの書きづらい読みづらい、毎回同じような記述するだけのSQL文を構築していく作業って、
なんかこうテキストエディタでコーディングするのが好きな人向けな感じ。
あんなものは、パフォーマンスチューニングが必要になってから、必要最低限だけ書きゃいいのにな。
それにServletとかJDBCみたいなクソ仕様は、二度と触りたくないなｗ
あのあたりは、なんかもうかなりレガシーコードの塊になってしまってて、時代に沿ってない内容になりすぎてる。
インターフェイスの設計に失敗してる箇所が多くて、ラッパー噛まして使うのが前提みたいな状態。
243:デフォルトの名無しさん
14/03/15 16:44:35.64 JfWd/5x0
多くて3人くらいだわ
244:デフォルトの名無しさん
14/03/15 16:51:05.57 4evGY2gy
Seasar2はSAStruts+S2JDBC、S2JUnitくらいしか触ってたことないが、
- ドキュメントが総じてクソい、ほぼメンテされてない
- できることが少ないわりに何パターンかあったりして説明が乏しい
- フォームのバリデーションより先に処理を挟みたいなら有志の拡張かフィルター使うしかない
- 設定ファイルを減らすための命名規約の呪いがパッケージを強要したりクラス名を制限したりしてくる
- JPA実装してるけど一部しかサポートしてない
- 自動投入用のテストデータのフォーマットがExcel
- おまけにキモっぽいHotDeployはバグ多すぎ
殆ど良かったイメージが残ってないな。
最近なら、Servlet使うならSpring、使わないならPlayの2択でだいたいなんとかなりそうな気がする。
245:デフォルトの名無しさん
14/03/15 16:58:45.19 ha3L2y5+
>>241
大企業の基幹システム開発なら100人規模なんてザラ
246:デフォルトの名無しさん
14/03/15 18:28:18.81 Z5g2rNsd
>>245
そういう案件だとザラだけど高確率で炎上じゃね
そんなに人使う必要がある時点で発注側にも問題アリだよ
247:デフォルトの名無しさん
14/03/15 19:19:45.31 ha3L2y5+
>>246
どんなに大規模な基幹系でも、高々10人、20人程度で開発しきれるはずと申すか？
248:デフォルトの名無しさん
14/03/15 19:26:41.17 JfWd/5x0
どんなに大規模でもサブシステムに分割できるはず
249:デフォルトの名無しさん
14/03/15 19:30:27.26 ha3L2y5+
サブシステムことに開発標準を作ると申すか？
250:デフォルトの名無しさん
14/03/15 19:40:36.57 JfWd/5x0
開発標準とは何かな
そんなもの見たことないけど
251:デフォルトの名無しさん
14/03/15 20:11:03.06 K2uN+xbt
RDBでSQLのWHEREを書かないで、KVSみたいに全部javaで書くライブラリを作ってみる
URLﾘﾝｸ(ideone.com)
252:デフォルトの名無しさん
14/03/15 20:45:31.84 nOYr2Orx
何でみんなそんなにSQLを嫌ってるの？
SQL書けばええやん。
253:デフォルトの名無しさん
14/03/15 21:31:07.36 rh2Bnj0w
同意。
トラブったときはSQLのほうが圧倒的に楽
昔Hibernateで痛い目にあった。。。
254:デフォルトの名無しさん
14/03/15 21:46:03.69 LN7VnBH1
>>241
255:デフォルトの名無しさん
14/03/15 22:33:43.53 qWn8sJ/I
引用アラシ発見
256:デフォルトの名無しさん
14/03/15 22:51:59.47 xO9GlIgR
apacheのdbutilsが程よくJDBCをラップしてくれて好きだった
DBアクセスは自分でSQL書く方が好み
どっちも個人的な好みだから他人には強要しないけど
257:デフォルトの名無しさん
14/03/15 22:55:50.30 JfWd/5x0
フレームワーク厨は強要してくるからなー
258:デフォルトの名無しさん
14/03/16 00:26:39.56 UxgGr0B4
くだらない問い合わせはORマッパー通した方がくだらない間違いも起こりにくいだろ
複雑な問い合わせだけはSQL直書きするようにすればいいだけやん
目糞鼻糞だけど
259:デフォルトの名無しさん
14/03/16 05:05:07.42 1NSc6s95
SQLで書けば、コード量は多めでも、読解難度は低い。
ORMを駆使すると、コード量は少なめで、読解難度が高くなる。
他人が書いたコードを引き継いだ時に殺意を覚えるのは、後者。
特に、とっくに廃れたORMの場合。
260:デフォルトの名無しさん
14/03/16 05:18:27.85 cHCjLYAE
流れるようなインターフェース()の悪口はそこまでだ
ｵﾚｵﾚ色が強いと大変ね
261:デフォルトの名無しさん
14/03/16 06:28:50.92 UxgGr0B4
おまえらはORマッパーが出来た背景を少しは調べたほうがいい
2、3人で開発するなら知らんけどそれなりの規模で大量のオナニーSQL文見せられてもかなわんだろ
262:デフォルトの名無しさん
14/03/16 06:38:36.02 Z6fLevpG
Oracle使った時SQLは全部ストアドに書くとかやったことあるわ
SELECTのReturnはXML
あれもある意味O/Rマッパーなんだろうか
263:デフォルトの名無しさん
14/03/16 09:03:49.32 axl38rZU
SQLをまったく意識しなくてよくなるようなまっぱができれば使いたいが
264:デフォルトの名無しさん
14/03/16 09:17:10.22 AdE6gbYt
O/Rマッパー黎明期から期待に胸を膨らませて追っかけてきたけど
保守段階までトータルで見ると、少なくとの日本の人月ベースで
コスト計算する業界では見合わないと思ってる。
初期HibernateのHQLなんかも設計思想はものすごく好きだった。
Torque、Castorなんかも試した。Torqueはクラス数が爆発しがちで
仕様がコロコロ変わる案件で地獄をみた。
Cayenneも良かったな。旧NeXT製のEOF(Enterprise Object Framework)
なんかの流れを彷彿とさせる設計は美しかったが、
日本ではマイナーで使える技術者が育たず広がらなかった。
とはいえ、素のJDBC使うのはめんどいし、もはやS2系は死んだ。
個人的に残された希望は枯れたMyBATISくらいかな。
SQLの透過性とシンプルにも使えるO/Rマッピングの融合がバランスいいよ。
265:デフォルトの名無しさん
14/03/16 09:28:37.06 axl38rZU
業務アプリなんかだと結局メイン部分はパフォーマンスや
堅牢性が大事になってきてSQLで書かないといけない。
まっぱが使えるのはマスタメンテくらいになる。
マスタメンテくらいのSQLなら別に複雑でもないからまっぱにする意味もない。
つまり使い道が無い。パフォーマンスや堅牢性も備えてはじめて使えるようになる。
266:デフォルトの名無しさん
14/03/16 09:48:24.48 AdE6gbYt
だよな。複雑なビジネスロジックをオブジェクト操作で
動的にSQL作るような仕組みだと、仕様変更とかバグ修正の場合に
マジックハンドでモノを掴むみたいな感じになるよ。
SQLならものの数分で終わるような対応が丸一日かかったり。
ただ、O/RマッピングとSQLの動的生成は違うものだから
ここは混同しちゃいかんな。
生JDBC使ったって最後はbeanにマッピングされるわけだし。
267:デフォルトの名無しさん
14/03/16 10:12:47.25 gY7mojcT
JPAは再帰処理がないのが不満に思えたが
昨今の大規模環境ってJOIN禁止ルールとかあるみたいだし気にしなくていいのかな？
268:デフォルトの名無しさん
14/03/16 17:26:09.65 Z6fLevpG
JOIN禁止ってマジ話？
そんなプロジェクトに放り込まれたらプロマネ殴り倒す自信あるよ
269:デフォルトの名無しさん
14/03/16 18:32:30.12 /+q7XY+7
一部のコンシューマーサービスにおける設計の話を一般論扱いされても。
それにむしろ、そういうケースではMicro-ORMだろうし。
270:デフォルトの名無しさん
14/03/16 18:53:19.88 Va0mC41/
指定数表以上の結合禁止、右外部結合禁止は見たことあるが、
結合そのものを禁止しているところは見たことないな。
271:デフォルトの名無しさん
14/03/16 19:00:58.43 axl38rZU
まあ将来的には結合なんてしなくてよくなるのが理想だよ。
だからまっぱは理想なんだけど今のハードではまだまっぱには無理がある
272:デフォルトの名無しさん
14/03/16 19:36:35.66 rxfO/+Tv
逆だろ、将来的にはいくら結合しまくっても性能が劣化しないのが理想だよ
273:デフォルトの名無しさん
14/03/16 19:41:36.95 zMPxA87q
結合時の性能劣化がなくなるよりも先にＲＤＢが廃れそうだなｗ
274:デフォルトの名無しさん
14/03/16 19:44:29.10 axl38rZU
え？結合なんかしたらSQLみたいじゃん
275:デフォルトの名無しさん
14/03/16 19:53:56.08 /+q7XY+7
抽象度が高くかつ表現力のあるマッピングAPIが、現状の言語仕様やHW的な限界で現実的ではないという話と、
リレーショナルモデルを相手にする以上、結合を考えないなんて意味がない話だし、本質的に性能劣化は発生する
みたいな話が混在してね？
276:デフォルトの名無しさん
14/03/16 23:08:47.31 AdE6gbYt
ソーシャルゲーム業界だと、たいがいJOIN禁止だな
詰めSQLやるようなチューニングはしない
大規模構成のMySQLをmemcachedとあわせてKVS的に使ったりって感じ
大規模にサーバまたいでデータ結合やったりするからJOINなんか使ってたら
保守できなくなる
277:デフォルトの名無しさん
14/03/17 03:54:31.81 CvNwiWhQ
ORM使いにくいって感じる状況、ORMへの知識不足が原因じゃなけりゃ、
大元のDB設計とかがいまいちだったりする感じのこともけっこうありそうな
そもそも、言うほどパフォーマンスに問題が合ってSQL書かないと行けないような自体って起きるかなぁ
そういうのって、どっかうまいこと作れてないか、
体感できない性能差を突き詰めたいだけでチューニングを行なってる人かのどっちかってことも少なくない気がする
278:デフォルトの名無しさん
14/03/18 02:18:31.77 tRXj2H8I
ORMはEager fetch, Lazy fetchの問題を解決不可能なんだよ
279:デフォルトの名無しさん
14/03/18 09:36:03.49 isJ/4bi8
>>277
DB設計が大元ってｗ
ORMを理解してないのはお前だろ
ORMを使う動機はドメインモデルをRDBに永続化することなのに
なんでDB設計が先にくるんだよアホかｗｗｗｗ
ていうかみんなわかってなさすぎｗ
テーブルモジュールで設計していながらORM語ってんだろ？ｗｗ
280:デフォルトの名無しさん
14/03/18 11:18:48.08 +SzQB6tf
>>279
世の中の全てがモデルファーストでシステムを全て作れるわけではないし(そんなの本当に新規開発だけ)
パフォーマンスのために非正規化したりテーブル設計を崩すこともある
他システム連携があったりすると、そのDBにアクセスしてくるのはJavaだけとは限らない
もうちょっと世の中でいろんな経験をしてごらん。
見えなかったものが見えてくるよ
281:デフォルトの名無しさん
14/03/18 16:21:01.00 SyPosiOD
次の仕事でPlay使うかもしれんとここ数日予習してるんだけどさ、
何か凄いstaticだらけで違和感覚えるんだが、
これはこういうものだと思って慣れるしかないの？
テストとかしずらくね？
工夫すれば一応DI使えるみたいだけど、entity注入するのはそれはそれで変な気もするし…
282:デフォルトの名無しさん
14/03/18 19:40:51.38 Xfw7AJmq
常に新規開発でDBを好き勝手やれるならそもそもこんな話してないわ
システムリプレイスするけどDBはそのままとか
DB設計は他社とかそんなんばっか
>>281
Playはそういうもんだと諦めたまえ
283:デフォルトの名無しさん
14/03/18 21:02:44.46 SyPosiOD
>>282
サンクス。気にはなるがやっぱフレームワークの流儀に従うべきか…。
284:デフォルトの名無しさん
14/03/23 16:44:03.33 oyP9q9vp
Javascriptに対してGAEができるなら
ORMにも似たようなのないの？
285:デフォルトの名無しさん
14/03/23 16:44:45.76 oyP9q9vp
間違えた！ GAEではなく、GWTです。
286:デフォルトの名無しさん
14/03/26 04:52:17.35 j07vAV4n
HSQLでfunctionつくるの楽しいわ
287:デフォルトの名無しさん
14/03/27 10:11:37.22 9TpQSSF6
プログラミング言語「Hack」登場 - 米Facebookが発表
URLﾘﾝｸ(news.mynavi.jp)
動的な型付け言語がもたらす開発の手軽さと、静的な型付け
がもたらすエラーチェックの完全性の高さなどの双方の利点を
得ることを目指して開発されているという。
これはJavaより有望かもしれない
288:デフォルトの名無しさん
14/03/27 13:18:35.80 V1uU5d7+
ああほんと。電動歯ブラシぐらいのエロティシズムを感じるよ
Oculusなんて買収して、どんなイノベーションを見せるんだろうね
289:デフォルトの名無しさん
14/03/27 22:05:13.54 53iNYuED
所詮はペチパーだろ
290:デフォルトの名無しさん
14/03/28 12:49:21.10 QHWMvAHr
PHPのDartみたいなもんじゃん。糞杉ワロタ
291:デフォルトの名無しさん
14/03/29 17:52:04.29 lqk81omC
Javaのスレとしては、というかPHPのスレ以外もれなくだと思うが
まずPHPをベースにするのをやめろと言わざるを得ない
292:デフォルトの名無しさん
14/03/29 19:25:52.45 ZB5YY77p
facebookが内製用に使うぶんには有効なんだろうけど
こういうのって外部の開発者が採用しても
大抵の場合はメリット出ないよね
293:デフォルトの名無しさん
14/03/30 17:09:49.38 jhRCncdW
CGIレンタルサーバーの都合(安さ)を考えて
Java, C#をベースとした言語から => PHP, Perlに変換するとか
そういう話ではないんだね