Grails（今）は価値がありますか？
私はこれが duplicate であることを知っていますが、Grailsの世界は1年以上前に質問されて以来かなり進んでおり、EclipseでのIDEサポートもそうですなので、やみくもに閉じないでください。
私は答えはイエスだと思い、 Grails 1.2. を使用して新しいプロジェクトに着手し、 STS Eclipse Integration のGroovy/Grailsビットをいじりました。
1年のGrailsの進化の後で、答えが明確に混同されていたので、この問題を再検討する価値があると思います。
したがって、経験豊富なJava Web開発者として、これらの質問があり、私の仮定に挑戦していただければ幸いです。
- Rubyと比較して、Grailsは価値があるのでしょうか、それとも自分でロールしますか？
- バギースタートを乗り越えましたか？
- それは本当に迅速な開発のメリットをもたらしますか？ （私は今私が苦労していることを認めます私はリストとページ指向ではない私の注文のアプリを作るために広範なベースライン設定を過ぎています）
- 実際のプロダクションアプリで機能しますか？ （重く感じる）
- Eclipseプラグインは以前よりも優れていて、目的に適合していますか？ （まだ考えていません）
ありがとう
編集：私は進むにつれて学んでおり、フレームワークの機能自体ではなく、フレームワークでの生活についていくつかの重要な不満を持っています。これらは考慮事項であり、私の経験と意見に基づくものであり、Grailsを使用するかどうかを決定しようとしている人を助けるので、これらを追加します。私はまた、フレームワークに関する経験の欠如を示している可能性があります。そのため、これは徹底的な批判を意味するものではありません。私は経験豊富な開発者であり、これは私が見つけたものです：
デバッグは本当に難しいです。実際、特にフレームワークの初心者としてはほとんど不可能です。これは、信頼できるデバッガのフレンドが最も必要な場合です。コードの一部で構文エラーの問題を追跡して、スタック内のどこかでサイレント障害を引き起こすドメインフィールドを参照するのに費やす時間よりも長い時間を費やしてきました。
ロギングは率直に言ってひどいです。 「便利なものは何もない」と「無用なものが非常に多い」という2つのモードがあります。 1ページのリクエスト後のデバッグログは128Mbで、エラーについては何も含まれていません。私の考えでは、伐採の問題全体をフレームワークで再検討する必要があります。
STS Eclipse IDE is are marginal valueです。構文の強調表示以外はあまり使用されません。美化されたエディターになるようにコードをデバッグします。コードヒントはパッチが適用され、私が見る限りGSPのサポートはまったくありません。また、デスクトップ上で最も遅いEclipseプラグインです。私はテキストエディター（すべてのオンラインチュートリアルビデオもそうであることに気付くでしょう）といくつかのカスタム構文の強調表示に戻りました。
パフォーマンスについて深刻な懸念があります。少し早すぎるとは言えませんが、休止状態のためにデータベースを調整していることに気づいています。おそらくそれは予想されることですが、パフォーマンスの高いクエリを生成するための規則では、ドメインモデルをシンプルに保つ必要があります。
最後に、論理ドメインモデルと物理データベースモデルが同一でなければならないという慣例は、スマートなデフォルトではなく、現実の世界ではそうなる可能性は低いです。私はあなたが2つを分離できることを知っていますが、慣習が拡張された場合には回避できると思う複雑さの度合いを作成します。構成と 実際に機能させるために必要なこと に関するドキュメントが不十分です。
私は今4か月以上Grailsを使用しています。Grailsとその使いやすさについて私の個人的な気持ちを伝えたいと思います。
Rubyまたは他のロールはあなた自身のものです）
もちろん、答えは「はい」でも「いいえ」でもありません状況によって異なります。それはあなたの要件に依存します（Java Worldにいる必要がありますか）、あなたの好みにも依存します（ドメイン指向の開発を好みますか、Groovyを好みますか...） ？ただし、GrailsはRailsに代わる重大な代替手段であると私は答えることができます。Railsアプリケーションであれば、Grailsでも同様に実行できます。ただし、プロジェクトの性質によっては、 、多少時間がかかる場合があります。繰り返しますが、Railsに慣れているが、Grailsに慣れていない場合は、Railsがより安全なオプションです。
バギースタートを乗り越えましたか？
はい。私の最初のメッセージ（このWebサイトまたは他のサイト）を見ると、Grailsのバグについて多くの不満がありました。ただし、GrailsはEdgeで少し荒れていて（たとえば、ドメイン継承の使用が多すぎないこと）、フレームワークに慣れれば、それほど大きな驚きは発生しないことを覚えておく必要があります。 Grailsにバグがないわけではありません。それは確かにRailsを超えています。しかし、それはバギーよりも使いやすいでもあります。そのためのアドバイス：できるだけ少ないプラグインを使用。それらの多くはバグが多く、一部は相互に互換性がないためです。そのため、Grailsプラグインが最新で、煩わしくなく、（自分で）テストされていることが確実でない限り、Grailsプラグインを含めないでください。
それは本当に迅速な開発のメリットをもたらしますか？
はい。 DB設計を扱う必要はほとんどありません。構成に関する規約により、構成は最初からほぼ完了しています。アプリケーションは簡単にメンテナンスできます。私が目にする唯一の欠点は、他のテクノロジーほどリッチではないフロントエンド開発です（RailsまたはASPなど）。
実際のプロダクションアプリで機能しますか？
まだウェブサイトを公開していなかったので私には言えませんが、sky.comがGrailsを使用しており、サイトが大量のトラフィックを引き付けているため、かなり自信があります- 1日あたり約700万ページビュー。この場合も、パフォーマンスはアプリケーションアーキテクチャと設計の決定に大きく依存します。
Eclipseプラグインは以前よりも優れていて、目的に適合していますか？
わからない私はIntelliJを使用していますが、Grailsのレルムに表示される不平を言うメッセージによると、1年前と比べてそれほど良くはないようです。
お役に立てば幸いです。
Railsプロジェクトを最近開始し、Grailsでいくつかのことを行っていました。
Railsの私の主なことは、開発者に対して完全に不透明なものがたくさんあることです（私はそれが嫌いです）、これを追加し始めると増加する傾向がありますplugins/generators/libs/ etc、それらを組み合わせるには、何かをパッチする必要があるためです。 Rails + pluginsは巨大なDSLハックであり、plugins + versions。
Grailsを使用すると、エコシステムははるかに小さくなりますが、すべてが比較的一貫している傾向があります。 DSLアプローチはあまり使用されていません。conventional-but-boring設計（つまり、DSLの代わりにクラス、インターフェースなどを使用する）を使用することで、配管のしくみを理解するのがはるかに簡単になります。
1対1の比較を行うと、次のようになります。
- 言語の実装：私はGroovyよりもRubyを好みますが、私は知りませんRubyよくわかります。Groovyは良いように感じます-いくつかの機能が構文の上に溶接されている、意図が悪い実装言語私はいくつかのハックを許可するためだけにあるように見えるいくつかの特別なクラスを参照しています。
- フレームワーク機能：Railsはこれよりはるかに先です。Railsのほとんどの側面を構成できます（レイアウト：テンプレート、 css/jsパッカー、検証、テストフレームワークなど）いくつかの方法で、Grailsはこれに遅れをとっていますが、ほとんどのユースケースには十分に柔軟です。
- プラグイン：Railsには、祝福や悪夢と見られる大量のプラグインがあります。一部のプラグインは維持されておらず、一部のプラグインは一部の機能でうまく機能しないか、プラグインとフォークがたくさんあります。私は基本的で最もよく使われるプラグイン（authlogic、hamlなど）に固執することを学んでいます
- Testing：Railsにはテストする方法がたくさんありますが、これは必ずしも良い方法ではありません。一部のテストフレームワークは、一部のプラグインなどではうまく機能しません。Grailsは少ないプラグインをテストしますが、主なプラグインのいくつかとよりよく統合する傾向があります（統合するプラグインがそれほど多くないため）
- データベース：Grailsが勝利はるかに。
- 私は私のdbをハッキングするよりも私のドメインクラスをモデル化することを好みます。
- Hibernate（内部で使用されます）は、そのRails対応物から数年離れています。RailsのデータマッパーはActiveRecord）、私はそれが十分に成熟していないと感じています。Grailsにもプラグインを介した移行があります。
- Hibernateの優れたキャッシュ実装（JBossキャッシュ、EhCacheなど）があり、屋根を介してパフォーマンスを向上させることができます
- ライブラリ：RubyにはNoSQLやクラウドサービスなどの新しいもののためのライブラリがたくさんありますが、Javaには膨大な数のExcel処理などの古いもの用のライブラリ。Javaライブラリは通常Rubyよりもはるかに高速であることを忘れないでください
- 最先端：Railsはより誇大宣伝であり、その背後にリソースが増えることになります。つまり、MongoDBまたはRiakをRailsと統合しようとすると、 Grailsは遅れをとっています。主な理由は、Grailsがあまり人気がないため、コミュニティがNoSQLなどの最新のEdgeのものをすべて使用するのではなく、日常の問題の解決に集中する傾向があるためです
次に例を示します。
- ほとんどのGrailsプラグインは、モデルやサービスの形式でコードを生成します。残りは通常ライブラリによって処理されます。モデル/サービスコードを検査して、それが何をするかを確認し、変更することができます。
- ほとんどのRailsプラグインは通常、Rails APIと接続します。これは、いくつかの関数を呼び出したり、モジュールを含めたりして、プラグイン独自のDSLを使用することを意味します。これは素晴らしいうまくいくときですが、壊れたときは恐ろしいことであり、いくつかのものにパッチを適用したり、別のプラグインやプラグインのバージョンをインストールしたりする必要があります。より熟練していると思いますRails devはこれに慣れていますが、私はそうではありません。
結論：
- Edgeのブリーディングが必要な場合は、時々のパッチ適用を気にせず、大規模なコミュニティを支持し、ActiveRecordスタイルのDBを使用することを気にせず、Railsを使用してください。その上、Ruby言語はとてもエレガントなので
- DSLではなくクラスインターフェースの設計を好む場合、モデルによるアプリのモデル化を好む場合は、絶妙な機能は必要なく、Javaエコシステムに慣れているGrails
それは非常に価値があります！
私たちはいくつかのプロジェクトでGrailsを使用していますが、そのすべてが次の理由で大きな成功を収めています。
簡単-これは、これまでに使用した最も簡単なフレームワークの1つです。
レガシーコードの再利用-私たちがしなければならないのは、レガシーコードを取得し、それをlibまたはsrcフォルダーにスローするだけです。私たちにとっては素晴らしい。
レガシーデータベース構造-レガシーデータベースでデータの視覚化を生成したい場合に最適なツールです。
今、実行可能性について：
バグ：バージョン1.1以降、あまり多くのバグに直面していません（バージョン1.0はバグが多すぎたため）
ツール：この面でNetbeansは本当に改善されていますが、Intellij IDEA（偉大なサポート！）のような他のツールにさえ近づいていません。）Eclipseについても同じことが言えます。
移植性：プロジェクトで単一の問題に直面することはありませんでした。
現在、6ダースのGrailsアプリケーションが本番環境で稼働しており、GrailsはJavaフレームワークとは異なり、ある程度の学習時間が必要ですが、アジャイル技術を使用したため、成果を上げています。詳細：
- IntelliJを使用しています。それほど高価ではなく、数週間で返金されます。
- 自動テスト、継続的インテグレーション、リファクタリングは、すべての動的言語コードと同様に必須です。すでにTDDを実践しているか、少なくとも適切なテストコードカバレッジを持っている場合、追加の作業はありません。
- HibernateにはデフォルトでGrailsが付属していますが、他の永続フレームワークを使用することもできます。今日利用できる他の5つの永続化プラグインがあります
- ロギングは、Graeme Rochersの考えでは明らかに問題ではありませんでしたが、着実に改善されています。ただし、エラーがログに記録されないという問題には直面していません（コードで例外を正しくキャッチする必要があります）。
- デバッグは明らかにレーダーではありませんでした（しかし、これは改善されていません）。とにかくデバッグに依存しません。
これは、すべての新しいテクノロジーと同様に、プロトタイプ、コードレビュー、ペアプログラミングを作成することをお勧めします。また、いくつかのコンサルティングも使用することをお勧めします。
それは非常に価値があります。私は1年以上使用していて、とても気に入っています。私はこれらの種類のradツールを避けていましたが、それが私の仕事のやり方を変えました。 1.2リリースでは、スタックトレース情報が改善され（特にGSPの場合）、さらに改善されました。
スケーリングに関する唯一の問題は、休止状態とそのキャッシュです。これは実際にはGrailsの問題ではありません。私が一般的に休止状態を好まない場合でも、GrailsがGORMでそれをラップする方法は、私にとって芸術作品です。基準のクロージャの側面は、使用すると素晴らしいです。
GrailsとRailsの両方の専門家で、Grailsを好む人をまだ見つけていません。
両方をよく知っている場合は、ほぼ間違いなくRailsを選択します。
Grailsは通常、プラットフォームの変更を恐れているJava=開発者にアピールします。
この場合、古くなったレガシーjvmにアジャイルアプローチを採用するには、JRubyがおそらくより良い方法だと思います。
最近プロジェクトでGrailsを使用したので、標準のJ2EEアプリケーション開発と比較した経験を共有したいと思います。
それは本当に迅速な開発のメリットをもたらしますか？
確かにそうです。足場のパスが早く残され、慣例が独自のニーズに優先される場合でも、多くの異なるテクノロジーを気にする必要がないため、起動期間は非常に短くなります。そのような軽量性により、作業が速くなるだけでなく、より正確でクリーンになります。
タグの作成はこれまでになく簡単になりましたが、JSFでは最初に、それが価値があるかどうかを慎重に検討しましたが、Grailsではそれを行います。テスト駆動で作業し、高いカバレッジ率を達成することも非常に簡単です。ただし、さまざまなテストケースやモック戦略が一貫しておらず、バグが多い場合があります。
JavaからGroovyへの切り替えは大きな喜びです。リストとマップのリテラル、クロージャー、ビルダーを用意して、Javaコンパクトで意味のある焦点の合ったコードを記述します。
開発速度を遅くするのは、私たちが使用しているIntelliJプラグインにも当てはまる、それほど完璧ではないIDEサポートです。悪い場所に散らばっている、しばしば古くて間違った文書さえも（「検索が終わった」という約束を守って）、急速な発展の邪魔になります。そのため、ソースコードの読み取りにフォールバックする必要がよくありました-その後、基になるSpringクラス階層に怯えていました。
デバッグは本当に難しいです。これが大きな問題であることに気づいたことはありません。デバッガーを接続してウォークスルーするか、大量のprintln/logsをコードに貼り付けて、何が起こっているのかを把握できます。
ロギングは率直に言ってひどいです。スタックトレースは一般的に4ページの役に立たない情報を提供することに同意します。しかし、そのような素晴らしいフレームワークに支払うための小さな価格です。
STS Eclipse IDEは限界値です。 EclipseはGrailsのサポートが不十分です。可能な場合はIntelliJを使用してください。 IntelliJの現金は喜んで払います。
Grailsを10近くのアプリケーションで使用した3年間の経験を紹介します。 Ruby on Railsと比較することはできませんので、他の質問にお答えします。
バギースタートを乗り越えましたか？
- はい、あります。 Grails 2.0.4/2.2.4でいくつかのGrailsバグを経験しました。
それは本当に迅速な開発のメリットをもたらしますか？
- Java世界で基本を知るのに1週間以上かかるので、メンテナンスも簡単です。そして、習得も簡単で、開発も簡単です。あなたはあなたのDBについてあまり心配する必要はありません-あなたのマックであることを確認してください
Eclipseプラグインは以前よりも優れていて、目的に適合していますか？
- IDEを慎重に選択してください。Eclipseは非常に役立ちましたが、クラッシュして予想以上に問題が発生します。IntelliJに行ったところ、トライアル月に、より良い選択のように思われました。最近、 Sublime Text、いくつかのプラグイン、古いコマンドラインを使用しています。IDEに行くのは特別な状況のみです。たとえば、デバッガを使用する場合などです。
実際のプロダクションアプリで機能しますか？
- ちょっと重いです。モデルを作成する前に、設計の選択について多くのことを調べてください。 Grailsの優れたデザインについて多くの研究を行ってください。 2年前にやったことのほとんどは、経験を積んでいるので、今はもっと良くする方法を実感できます。実際の本番環境のアプリをうまく処理しますが、Hibernateを実行するミスによっては、本当に頭痛の種になる可能性があります。
私は1.0ベータのごく初期からGrailsを使用しており、Groovy/Grailsを真剣に始めることをお勧めできるのは、Javaショップから来た場合のみです。
あなたがJavaショップであり、Ruby Railsを検討している場合は、Grailsを停止します。Grailsが機能しない場合は、いつでもRailsを開始できます。
Grails Eclipseプラグインはがらくたです。理由もなくクラッシュし、Groovyの柔軟性を実際にはサポートしていません。 NetBeansとIntelliJははるかに優れていると噂されていますが、まだ試していません。
それは実行されますか？もちろんそうです。問題に十分な数のサーバーをスローする限り、RubyのRailsでもパフォーマンスを発揮します。ただし、GrailsがさまざまなJavaフレームワークとどのように比較されるのかはわかりません。
それは本当に迅速な開発のメリットをもたらしますか？まあ、私はまだ多くの良いRuby/Railsのものが欠けています。日付と列挙型の要求パラメーターは自動的に認識されません（その場合、Railsにも日付に関する問題がいくつかあります）。TimeCategoryは標準構成の一部であるはずですが、そうではありません。しかし、設定がほとんど必要ないものもたくさんあります。
Railsがどこにあるかは完全ではありませんが（特にRails 3を楽しみにしています）、多くのJavaフレームワークを使用するよりもはるかに快適です。それでも、地表の下の魔法はRailsよりもはるかに深くなります。たとえば、Constraintsのシステムは非常に強力ですが、不可解なSpringの巨大なレイヤーの上に構築されており、同じパワーを少し異なる方法で使用したい場合は、非常に柔軟性がありません。 Railsは、IMEで転覆するのが簡単です。
その価値はありますか？はい。それは他のものよりも良い選択ですか？場合によります。
自分で試してみることをお勧めします。 Grailsの柔軟性と開発速度が大好きです。しかし、あなたが見ることができるように他の人々の経験は異なります。 Javaプラットフォームを使用してクライアント用の迅速なアプリケーションを開発できるようにしたいのですが、Grailsが非常にうまく機能することがわかりました。
また、フロントエンドは非常に柔軟に開発できることがわかりました。また、常識を使い、プラグインを慎重に選択する必要があるとも思います。私はspringsourceでサポートされているプラグインを使い続けます。
私の経験では、Grailsはいくつかの非常に魅力的な機能をテーブルに持ち込んでいるため、学習して使用する価値があります。
- 俊敏性-従来のJ2EEプロジェクトに実装するのに数週間かかっていたものは、通常、1日の作業でGrailsプラグインシステムを使用します。 ajax、jquery ui、acegi、落ち着いた実装、スケジューラシステムなど、多くのもの
- 他のランタイムシステムとその特異性を学習する必要性を軽減するJVMでの実行
Javaライクシンタックスとグルーヴィーなシンタックスシュガー。両方の長所のように。 Javaのような新しい言語の構文を学習する代わりに、すぐにRubyで始めることができます。その後、ゆっくりと、堅牢で簡単で直感的なGroovy構文に移行できます。
プロジェクトマネージャーにとって、何らかの理由（上からの抵抗、新しいテクノロジーの採用など）でGrailsを「使用しない」という説得力のある理由がない限り、Grailsを使用できない理由はありません。少なくとも試した。
デバッグに関する懸念に答えるには、それほど難しくありません。 Netbeans IDEを使用すれば、デバッグは簡単です。それで、もう1つ指摘しておきます。すべてのIDEでいくつかの実験を行った後、Netbeansがその仕事を行うのに最も適していることがわかりました。コード補完、構文の強調表示、デバッグなどのサポートが向上しています。私の意見では、STSはそのために十分ではありません。
Eclipseプラグインに関しては、まだ道は進んでいますが、Spring Source（SpringSource Tool Suite）のEclipseバージョンを使用できます。
http://www.springsource.com/products/sts
以前のプラグインバージョンと比べてかなりまともで、Spring Sourceがgrailsとgroovyを担当する会社を買収したので、STSがすぐに良くなると期待できます。
Eclipseプラグインは以前よりも優れていて、目的に適合していますか？
昨年に比べて大幅に改善されました。 12月にロンドンのGroovy＆Grails Exchangeに参加しました。記録されたEclipse/SpringSource STSでのGroovy＆Grailsの統合に関する素晴らしい講演がありました。 video を参照してください。
私の見解では、Eclipseは多くの根拠を得ました。現在IntelliJは少し進んでいるようですが、今後数か月以内に変更される可能性があります。
個人的には、私はRoRを学び、いくつかのホームプロジェクトで使用しましたが、主にJVMで実行されているためGrailsに切り替えました。したがって、Javaパフォーマンス/プロファイリングプログラム。問題になる前に、コードのボトルネックを特定するのに役立ちます。
一般的に、RoRとGrailsで使用されているIDEの品質にそれほど大きな違いはありません。公平を期すために、私はLinuxでプログラミングをしていて、RoR開発用にTextMateを試していません。 RoRを使用していたときは、Netbeansを使用していました。
現在、私はSTSを使用してプログラミングを行っており、Grailsを使用できることを楽しみにしています。ただし、メソッドの検出/完了をより効率的に機能させることができます。
私はフルタイムですJava開発者ですが、趣味のプロジェクトにはRailsを使用します。1年前の職場でのプロジェクトのGrailsを評価しました。Grailsの私の経験少しがっかりさせられたので、Railsの調査を始めたのはこのためでした。両方の印象を使用したのは、グルービーが言語としてそれほど遠くないとしてもRuby言語として、Railsは、Grailsよりも大幅に改善されたエクスペリエンスを提供します。非常に簡単に言えば、Railsは、特に利用可能な優れた宝石の数を考慮に入れると、はるかに現実の問題を解決するようです。検索、バージョン管理、RSS、非クラッドアプリの提供、クラウドサービスとの統合などを考えています。GrailsはおおよそRails 1。 x。今月末までにRails 3がリリースされているはずです。実際にRails作業中の使用に移行することにしました。最後に、grailsは、Java開発者にとっては、より簡単に入手できます。しかし最終的には、より広範なプロジェクト要件をカバーするための改良が欠けています。
バギースタートを乗り越えましたか？
それはまだ恐ろしいです。私は彼らの出発点を知りませんが、Grails 2からGrails 3への移行は依然として悪夢であり、彼らが解決する以上にうまく機能していません。
それは本当に迅速な開発のメリットをもたらしますか？
Javaあなたはテストから何かを出力するためにそのような時間を費やすことはないでしょう） 。
実際のプロダクションアプリで機能しますか？
Grailsで何かを構築している有名な会社はまだ1つも知りません。
Eclipseプラグインは以前よりも優れていて、目的に適合していますか？
なぜ誰もがまだEclipseを使用している理由はわかりませんが、Grails 3のIntelliJサポートは使用できません。
だから、主な質問に答える：
Grails（今）は価値がありますか？
Microsoft Accessライセンスを購入する余裕がない場合は、たぶん。実際のプロジェクトでは、Grailsから離れます。実際、それは死産児に過ぎません。
メモリ使用量とジョブマーケットという2つの考慮事項を指摘しておきます。 Grailsアプリケーションは、特に開発モードで多くのメモリを消費します。中規模アプリケーションでは600 Mb。プロダクションモードでデプロイした場合（例： Tomcatのwarファイルでは、使用量は約500 MBになる可能性があります。これは、Javaの使用から一部継承されています。
就職市場について、そして私が読んだ限りでは、Grailsプログラマーの求人発表における需要は、たとえばDjangoおよびRuby on Rails。
私はノーと言うでしょう。特に何かをプロトタイプ化したい場合は特に、ほとんどの用途にとって、まだ肥大化しています。 Webアプリケーションを作成するために、そのすべてのコード、grailsにバンドルされているすべての依存関係は必要ありません。 Webアプリケーションを公開するたびにSpringを使用する必要はありません。依存関係に満ちた世界全体をスタックに追加する前に、達成しようとしていることを確認してください。私はあなたのアプリケーションが何で構成されているかを知ることが重要だと思います。
Rubyのシナトラのように、ずっと軽いratpackのようなものを見ることをお勧めします。
2013年末の私の経験から。
長所
- プラグインをほとんど使用せず、Grailsのno-sとnever-sのセットを制限する場合、それは非常にスムーズな開発体験です
短所