【Java】Play framework【Scala】
>>89 >>86 反論するなら理由くらいかけよ 理由を書かない=書けない、だろうが >>84 >>91 v2.0はScalaで書き直したと書かれてるな Python, Groovyに続きJavaも捨てそうだな。 迷走しすぎ 他にJava系で使いやすそうなのないの? Struts2とかSpring MVCはめんどくさいとか聞く。 Java developerはたくさんいるのにRailsやDjangoのような 人気のあるのが出てこないのは何でなんだろな >>92 今のところフレームワークと名の付く物でイイと思ったのはplayぐらい 他は面倒だわ、中々動かないわで フレームワークで生産性向上とか実感できたことがない なんか2.0のチュートリアルは1.2の頃と比べるとやっつけ感が凄いな それはそうと7月くらいに都内で100人気規模の勉強会やるみたいだけど行く人いる? さっきからグダグダ書いてる低脳君は何なのかね。 リスクを言い訳にする底辺エンジニアなら、こんなスレを見る必要もない。 大人しくJSPスレやらStrutsスレにでも行けばいいだけのこと。 >>94 まだ1.24にない機能も多いんでねぇかな 2.2になる頃には充実してるだろう 実際に大した実績ないからそんなにムキになって怒るんだろう? あとエンジニアならリスクに関しては最低限考えようぜ? マイナーなフレームワークなんだからエンジニアの確保や 学習期間も重要な要素だろ。 なーんにも考えてない園児ニアだから自分の趣味に走って プロジェクトを危険な状態に追い込むことになる。 プロジェクトを私物化するんじゃねぇよ。 >>97 どっかの園児ニアが手をださんと実績はできんからのぅ うんそうだね。 頭の悪い君にも、そろそろこのスレに居る理由がないことを理解できる頃だと思うから、 別のスレにいこうね。 >>97 ムキになってるのはお前だろ。 リスクを乗り越えて誰かが使うまで実績なんてのは生まれない。 それが出来るまで何もできない無能集団なら大人しくしてろよ。 他人のプロジェクトが何を選択しようがお前に関係には関係ない。 こういう新しいことを学のが嫌なタイプの人間の耳にもPlayの事が入ってくると言うのはある程度浸透し始めたのかな?という感じだな。 ただ新規案件で導入事例があまり聞こえてこないと言うのは確かにあるね。 それはPlayというより、Javaを使うよりLLを使ってるからではないかな? Scalaに関してはアクター使ってサーバ自身に使われる事が多いみたいだし。 ちなみに俺はPlay2.0&Scala勉強しつつ個人的にサービス立ち上げるつもりだ。 twitterを見てると次のプロジェクトで使うと書いてる人がいるね >>100 リスクに晒してもいいようなショボいプロジェクトならいいんじゃね? 好きなだけ趣味の為にプロジェクトを私物化しなさいよ。 たしかにお前のような人柱がいるおかげで技術の進歩があるのかもしれない。 Play Framworkに色々な実績ができたときに初めて使わせてもらうよ。 まぁ、もし鳴かず飛ばずならスルーさせてもらうが。 エンジニアにも選択と集中って必要だと思うよ。 日々色々な技術が出てくるんだから全て学んでたら体が足りない。 今後必須となることがほぼ確定している技術のみに絞って習得すべき。 >>103 やっと納得できた? Play Framworkはお前にはまだ早い。 数年経ってからまたこのスレに来ればいいと思うよ。 それではさようなら。 フレームワーク導入に弱気になるのはわからないでもないが、それをプロジェクト私物化とは言わないでしょ 採用提案者がケツ拭く覚悟があるのなら構わないんじゃない? そりゃサポートが手厚ければいいけど、フレームワーク自体に流行り廃りはあるもんだし、3年単位ぐらいで状況一新するよ そんなに実績重視するのなら他にしたほうがいい Play2.0のチュートリアルのAnormのところで、値を取得するために構造体?みたいな物をSQLを実行する際に使っていますが、その中で各変数名をチルダで繋いでいます。 このチルダにはどんな意味があるのでしょうか? たしかScalaではビット反転とかだったようなきがするんです... 少なくとも今さらStruts使うくらいならPlayだな Strutsしかできない自称Javaプログラマ、SEなんかが反対してんだろうけどお呼びでないんだよね >>103 必ずこういうことを言う奴がいるが そうやって商機を逃してることにいつになったら気がつくんだ 今までどれだけのチャンスを潰してきたか自覚してないんだろうか >>103 のように、勉強しないことに言い訳するような奴にロクなのはいない。 それ以前にフレームワークの使い方を覚えることがエンジニアの仕事と思ってる時点でたかが知れているが。志が低すぎる。 要件にあったframework使えばいいだけの話じゃないのか? どれを使うかは事前にいくつか検証し比較してから決めるのであれば、playが機能的に満たしてるのなら候補に加えてもいいと思う。 Facebookみたいな趣味レベルからの成功例が出ると普及するかもしれん でもtwitterでScalaが普及することもなかったから難しいな Playはなんどもサポート対象の言語を捨ててきた「実績」があるようだからな PythonやGroovyとPlayで作った奴らは、全員はしごをはずされたわけだ。 システム改修するなら全部作り直しするか、メンテもなく終了したバージョンを使うしかない。 客にとっては一番迷惑な結果だ。 Play 2.0はJavaとScalaを対象言語としたようだが、 コアはScalaで書き直したと書かれている。 また同じように迷走してしまってるわけだ。 Scalaに傾倒していっているのは明らかで、 Javaサポートも雲行きが怪しくなってるのが今の現状かと。 1.2はちゃんと残して行こうってコミュニティで頑張ってるよ。 コミッタに日本人が決まってるし。 そもそも、オープンソースなんだから何かあったら対応できるし誰か有志が頑張ってくれる可能性もある。 LinuxとかOSレベルの解析は大変だけどフレームワーク系なら何とか理解できるでしょ? Scalaに傾倒して行ってるってそれがJavaにとってなんか問題があるのか? ScalaとJavaの関係も理解してないみたいだし、Play自体も触ってないんじゃないの? 触ってすらないのに実績がとかサポートがとか、本当にエンジニアなの? >PythonやGroovy切捨て -> Scala へ むしろjavaも完全に捨ててScala1本にすりゃいいと思うよ。 複数の言語を使うっておかしな話だ。 へっぽこプログラマー的には他のフレームワークも playぐらいラクチンに動くようになるといいんだけどな。 難しすぎなんだよStruts2 一応Struts2は勉強したし、使ってるプロジェクトにも何度か参加したけど 未だに他人が書いたコードを猿真似して書いてるような感覚。 そゆ意味、playは勉強する必要はないかもしんない。 へっぽこプログラマーでもやべぇこれ簡単wwwwって動かせるわけだから Struts2使いこなせます!って人ならすぐ使えるようになるんじゃね。 >>112 むしろこれから使うのは1.2の方だろ 2.0を現場に投入するのはまだ早い 園児ニアが投入しちゃうぞーってのは止めやしないけどさw Scalaってまったく人気ない言語なんだな 46位。 Scalaなんでこんなに人気ないんだろ http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html Playはどこに向かってるのかさっぱりわからないな 3.0はCOBOL用になってるかもしれん 下のスレのJava版あったらいいと思うんだけどどう? Java系フレームワークを総合的に扱うスレ。 【Python】Python Webフレームワーク総合スレ http://kohada.2ch.net/test/read.cgi/php/1329996601/ プロジェクトに投入するにあたって具体的にどこが駄目なのかがロクに出てなくてワラタ 投入しないための言い訳しか書けない馬鹿が暴れてただけだよ。 使う気もないのに、プロジェクトがー実績がーって馬鹿丸出し。 >>120-121 継続性を考えないほうが馬鹿だけどな 使い捨てのコード書くなら使えばいいんじゃないか 海外含めて、高トラフィックのサイトがどこもPlayを採用してない。 そういうことだ >>122 で? そんなことを議論したいなら、別のスレにいけばー? 必死にPlay擁護してるやつがいるな Playの本の著者か?w >>124 ああ、出てきた… 反論出来なくなると信者とかステマしか言えなくなる低脳が。 反論できてないのはおまえだろ 高トラフィックで実績あるサイトはどこよ?? Javaは高トラフィックサイトの定番だからJavaのせいにはできないぞ 30個以上Javaフレームワークあるのになぜあえて実績のないPlayを 採用する必要があるんだ? >>126 君は実に低脳だな。 実績が少ないことなんて分かってるし、他のフレームワークだっていくらでもある。だからなんなの? 最初に書いてやっただろ。 使う気もないのに、プロジェクトがー実績がーって馬鹿丸出の奴が居るって。 実際の性能比較を議論するならまだしも、お前の場合は壊れた鳩時計のごとく実績を連呼するだけ。 自ら馬鹿をさらしに来るなよ間抜け。 >>128 馬鹿はおまえだ 英語が読めればPlayがどんな状況にあるかわかるはずだ おまえは人格批判をしてるだけで、 Play採用のデメリットについてなにひとつ反論できていない >>129 英語は得意じゃないけど頑張って読んでみるから参考URL教えてくれ >>129 ここにいる人は大体がデメリットがある事は理解してると思うぞ? ただそれを自分達で何とか乗り越える気概がある。 それにクリティカルな業務に導入はしないだろうし、しろとあってるわけじゃない。 トラフィックの多いサイトで採用されてるフレームワークって何があんだべ ところで日本のユーザグループのメーリングリストでロゴの投票やってるけど投票したかい? だいたい「高トラフィック」の定義も曖昧だし 「Javaは高トラフィックサイトの定番だからJavaのせいにはできないぞ」に至っては意味不明 よく理解せずに批判してるだけなんだろうな 公式サイトでは「毎秒数千リクエストを容易に捌ける」とあるわけで コレを信じるなら大体のプロジェクトでは問題ないレベルだろう なんでViewにGroovyとか使っちゃってんのかね。 Javaのフレームワークと言いつつScala推しだし。 フレームワークと言いつつAPサーバも作っちゃってるし。 もう作者の壮大なオナニーとしか思えませんわ。 何でってそりゃ使う側が簡単に使えるためにじゃないの? 拡張JPAだってそうじゃん フレームワークってもjsp/servletに乗っかるフレームワークとかならAP鯖いらんけど そうじゃなかったらいるんちゃうの? この人の面白いね。業務でも使ってるらしいけど。 ttp://www.slideshare.net/ikeike443/presentations 1.2系統のひと、IDEはなに使ってる? っていうか、標準のhtmlエディタだとシンタックスでエラーが出るんだが ちゃんと公式サイト読めよ eclipseやnetbeans用のプラグイン同梱してるって書いてあるだろ >>140 Session使えない弱点は致命的だな セキュリティ重要なデータはクライアント側に保持してはいけないし。 >>143 サーブレットで言うセッションはPlayだとキャッシュだよ こうやって公式サイトどころかこのスレさえ読まずに知ったかぶりで批判する奴の多いこと多いこと >>144 キャッシュでは言葉の意味が違うだろう キャッシュといったら常に最新の情報返すとは限らない。 >>145 140の奴がセッションがないって書いてるだろ >>145 おまえは公式サイト読んだのにキャッシュとセッションが同等のものだと思ってるのか? >>146 名前はキャッシュなんだけど、セッションの代わりにも使えるんだよ というか公式でセッションはクッキーだから、大事なものはキャッシュに保存してねって書いてる >>148 え?セッションがcookie? Sessionのためのcookieに保存されているのは、ユーザを 一意に識別するためのIDだけ。 データそのものはサーバ上に安全に保持される。 sessionはステートレスなhttpの弱点を補う大事な仕組みだ。 もし開発者が本当に 「セッションはクッキーだから、大事なものはキャッシュに保存してね」という趣旨の 発言をしているのなら、セッションやセキュリティの基礎知識もないってことだ。 >>145 こうやってsessionの仕組みも知らず、知ったかぶりで>>143 を批判する奴の多いこと多いこと >>149 playにおいて、サーブレットのセッションに相当するのはキャッシュになってるんだよ playのセッションはクッキーに暗号化して保存してるだけだし文字しか保存できない だからサーブレットと同じ使い方しちゃだめよって公式に書いてある >>150 相当するは間違いだな サーブレットのセッションは、セッションIDをクッキーに保存するか 常にセッションIDを付けて通信するって方法で実現してる playの場合は、セッションはクッキーに暗号化して文字入れるだけ クライアントに渡したくない情報は、 キャッシュがサーブレットで言うアプリケーションスコープに相当する使い方できますよってことになってる >>151 公式サイトにサーブレットで言うセッションとほぼ同等の使い方例示してあるよ 要はjsessionidの代わりとなるキーがありゃいいだけじゃん >>149 のように根本的に勘違いしてる人もいるようだが わざわざSessionと言う用語を再定義してややこしくしたplay側にも問題はあると思う わざわざSessionとかいうクラス名にせず最初から素直にCookieクラスにしときゃ誤解も生まれずわかりやすかったんじゃないの そうすりゃ従来のSessionはCacheが肩代わりしますって話だけで済んだはず >>151 結局、サーバー側で、安全にデータを保持する仕組みはないってことか。 >>153 暗号化してCookieに書き込んでいるだけのものをSessionと名づけたのは、 Playに機能がないことをごまかすためにわざと判りにくい名前にしたんじゃないか とりあえず、>>143 に対する回答としては「そういうときはCache使え」でFA 公式サイトもそう言ってるし、>>140 のリンク先の人もはっきりとそう書いてる 公式サイト一通り読んだらこの辺のことは書いてあるんだから、やっぱりよくわかってない人だけがなんやかんやと騒いでるだけなんだろうな それとも日本語訳のページからはこのあたりの情報が丸ごと抜けてたりするのか? >>154 俺の文の後半部分読んでる? サーブレットでいうSessionはPlayではCacheと呼ばれる機能が肩代わりするんだと書いただろ セッションIDのかわりにuuid発行する機能もある これらを組み合わせてSessionと同等のことが一通りできる 日本語でも説明ちゃんとあったぞ http://playdocja.appspot.com/documentation/1.1/cache >>157 URL張るなら最新版はったほうがわかりやすいよ 1.1とか古いのもう新規で使わないでしょ >>157 Cacheは消えてしまうから、保持できてるとはいえないないでしょ 設定した期限まで保持できないと同等とはいえない 複数サーバの場合も同一のデータを返す仕組みもない データベース上にセッションの情報を保持する仕組みもない。 こっちにも書いてあるじゃないか lifetimeを通じてデータを保持できるJava EEとは違うと書いてあるだろ? キャッシュはあくまでもパフォーマンス改善のための仕組みでしかない。 Memcachedなんかもセキュアでないことも知ってるよな? http://www.playframework.org/documentation/2.0.1/JavaCache For any data stored in the cache, a regeneration strategy needs to be put in place in case the data goes missing. This philosophy is one of the fundamentals behind Play, and is different from Java EE, where the session is expected to retain values throughout its lifetime. 似たような物はあれどいつ消えるかわかりませんよか Memcachedがセキュアじゃないのは知らなかったな、同期のための通信が暗号化されてないとか? Cacheで同じような事はできるがステートレスを謳ってるんたから推奨はしてないだろうな。 あとSession(Cookieに保持する文字列)は暗号化じゃなくて改ざんチェックをしてるんじゃなかったかな?暗号化する方法も提供されてたとは思うが。 おいおい、PHPですらSessionあるのにPlayにはねーのかよw 「CacheがSessionの代わりになるんだよ(キリッ」じゃねーよw CacheはCacheだろ。Sessionじゃねーんだよ。 素直にPlayにはSessionありませんって言えばいいのに。 AP鯖も自作してんだからSessionぐらい実装しとけよな。 マジで使えねー。 >>163 分散機能のないPHP標準のセッションとごっちゃにするな恥ずかしい >>1 Java用Webアプリケーションフレームワークの総合スレ立てた 【Java】 Java Web Application Framework 総合 http://toro.2ch.net/test/read.cgi/tech/1338707919/ >>165 でもPlayにはセッション自体がねーんだろ? PHPにも劣るじゃん。 だからMemcachedだって >>161 >Web サーバー? memcached 間のネットワークをモニタすることで こんなことされるような環境にしなきゃいいだけのこと memcachedのこれがセキュリティホールなら、 セッションファイル開いたら中身まんま見れちゃうPHPも十分セキュリティホールだな しかしcacheは保存の保証がないのが痛い 保証がないもんだと思って作ればいいんだろうが PlayでSessionないのは Seasarがホットデプロイで悩んでいた問題を解決するためだろうね。 セッションレプリケーションをなくしたいのなら 代替手段にデータベースもってくるはずだし。 1.* にしか対応していないモジュールは待ってれば 2.0 にも対応しますかね。 oauth とか 2.0 で使えるとよいのになーと思っているのですが。 2,0 は標準の Play の API に OAuth とか OpenID 用のパッケージが入ってる。 誰か見てるかな(´・ω・`)ボスケテ ttps://hello-chapati.dotcloud.com/hello.war/ 困ってる事 ■アクションチェーンをするとhttpsのアドレスからhttpのアドレスに遷移してしまう。 環境 Play Framework 1.2.3 ※1.2.4〜1.2.5でも同様 0.https://hello-chapati.dotcloud.com/hello.war/ にアクセスする。 1.Application.indexアクションで入力画面が表示される。 2.登録ボタンを押すとApplication.registUserアクションにPOSTする。 3.Application.registUserアクションで処理が終わると、 Application.indexアクションへリダイレクト(アクションチェーン)する。 4.入力画面に戻ってくる。 この時なぜかURLがhttp://hello-chapati.dotcloud.com/hello.war/ になってしまう。 ■条件 ・dotcloud上で動かした場合。 ・Apache2にSSLの設定をしてPlayと連携させた場合。 ※PlayのアプリにSSLの設定をしてhttpsにアクセスした場合は、アクションチェーンをさせてもhttpsのままです。 Apache2にSSLの設定して連携する時って Play Frameworkのアプリ側で必要な設定ってあるのでしょうか? ttp://playdocja.appspot.com/documentation/1.2.3/production#server SSLの設定はここを参考にしました。 >>175 ここよりは日本のユーザグループに質問投げた方がいいと思うよ。 >>177 やっぱりあっちのがいいかなぁ。 スタックオーバーフローは日本語がまるで見当たらなかったのでビビって逃げました。 検索してみても、同じ悩みの人がいるかもわからなかったorz スタックオーバーフローなんて、日本語で書いている人誰もいないでしょ @IT が、スタックオーバーフローと同じようなQAサイトを作ったので、そっちで聞いてみたら? http://qa.atmarkit.co.jp/ いっぱい質問を登録してくれって中の人が言っていた。 DotCloud + Play Framework1.2.3-1.2.5 アクションチェーンでhttpsからhttpに移動してしまう。 - QA@IT ttp://qa.atmarkit.co.jp/q/2275 QA@ITに登録してみました。 こちらで回答いただけたらあたらにも反映しようと思うので、 こちらでも引き続き回答募集中です。 >>181 twitter #play_ja で特定したww #play_ja は見ている人も多いから、きっと誰か反応してくれると思うよ。 回答があるといいね。 play 2.0.1 から触りはじめたけどいいね! コードの量が少ない少ない。 驚いてる。 >>181 何気にplayの初質問なんだなw rubyとrailsの質問が多い 「さよなら原発10万人集会」を新聞はどう報道したのか?検証してみた ★政府が隠蔽したいこと ↓ @「坂本龍一 パブコメで声あげよう」 A広瀬隆が原発の再稼働を止めるために電力会社と取引を計画 http://b ●log.goo.ne.jp/yqmcps 歌&作曲&演奏:坂本龍一 http://www.youtube.com/watch?v=w22IhMuwhLw http://www.youtube.com/watch?v=iVTFeozHWcA Playの作者がScalaの会社から金を受け取るようになった2.0からアホになってるな。 2.0の戻り値でokとかnotFoundとかHTTPステータスを意識させるのは改悪というかアホだろ。 ok以外は必要なときに指定できればいい。どんだけ低レベル層のフレームワーク作る気だ。 フレームワークはアホ向きにあるもんだが、作るほうが理論優先で祖結合とか 頭でっかちになってくると、反転してアホになってることさえ気がつかないのか。 いや作者は分かってても、Scalaに金で買収されたから逆らえない罠。 金儲けが悪いとは言わない。ただ2.0はJava EEの匂いがする。 2.0 系で servlet でいう setAttribute("string",object) みたいなことってどうやるの? 業務で使っている人、ウェブサーバは何を使ってますか? サクラで専用サーバだとApacheが入ってるからApacheになるのか それともまんま play framework ? read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる