Ruby on Railsのマイナス面と注意事項[終了]

これはRoRバッシングのオープニングガンビットではありません-正直です！

私はRubyとRailsフレームワークを学んでいます。一見したところ、かなりクールで、PHPに比べて素晴らしい経験に思えます。（実際、C＃と.NETでの幸せな日々を思い出させてくれます。）

しかし、これに入ると、私はこのフレームワークまたは言語の経験がなく、興味があります-現在の欠点や、あなたが始めたときに知っていたかったことは何ですか？

（これはコミュニティwikiにすべきでしょうか？）

これは、Railsでの経験学習、学習の継続、および比較的単純なアプリケーションの作成によるものです。

1）学習曲線

Railsは一見シンプルです。チュートリアル、ビデオ、および本はすべて、動作する（い場合は）アプリケーションをどれだけ迅速に取得できるかを示していますが、これらは実際にはほんの一面です。彼らは、コード生成と「足場」に大きく依存する傾向があります。これは、学習するときは確かに良いツールですが、その有用性はすぐに失われます。

Railsをマスターするのは難しいです。非常に基本的なこと（これについては後で説明します）を超えると、宣伝されている非常に単純化された「デモアプリ」機能以上のことを行う必要がある場合、壁に突き当たります。学習しながらRubyの基本的な知識を習得できますがDRY、Railsの制約の外に行く必要がある場合は、Rubyをすぐに拾う必要があります。

Railsは、私が愛情を込めて呼び出すのが好きなように、数値プログラミングによるペイントです。慣習に100％を固守する（つまり、線の中にとどまり、使用するよう指示された色を使用する）場合、適切なアプリケーションをすばやく簡単に作成できます。しかし、あなたが逸脱しなければならない場合、Railsはあなたの親友からあなたの最悪の敵に行くことができます。

2）ハンマーしか持っていないとき...

Railsは非常に単純なCRUDアプリケーションを実行します。問題は、アプリがデータベースからの読み取り/書き込み以上のことを行う必要がある場合に発生します。今、記録のために私が使用した最後のRailsバージョンは2.3.4だったので、その後物事が変わったかもしれませんが、ビジネス要件が変わったときに大きな問題に遭遇したため、アプリケーションに小さなワークフローシステムを組み込み、統合する必要がありましたレガシーPHPアプリケーション。「1つのフォーム、1つのモデル」というRailsの規則は、些細なアプリやデータ入力アプリケーションではうまく機能しますが、処理ロジックを実行したり、ワークフロー、または一般的な「ユーザーがデータを入力する」いくつかのテキストフィールドで、[送信]をクリックします。それはできますが、決して「簡単」ではありません。

また、Railsは、データアクセスの推奨される方法を使用していない他のアプリケーションとうまく連携することを好みません。「Web 2.0」スタイルのAPIを持たないアプリケーションとインターフェースする必要がある場合は、Railsを使用する代わりに、Railsを回避する必要があります。繰り返しになりますが、これは私に起こったことであるため、ここでの経験から話しています。

3）新しい

最後に、Railsは多くの分野で依然として「ブロックの新しい子供」です。これは個人的な使用や「クールだと思う」タイプのシナリオには関係ありませんが、Railsのある場所にいない場合は、私の仕事でRailsを使用することを好む人として話してください。広範囲に渡って、Rails開発者としてのフルタイムの仕事を見つけることは非常に困難です。依然として大部分は「ヒップで新しいスタートアップ」の領域であり、ほとんどの大都市圏の主要なプレーヤーではありません。この点であなたの走行距離は異なるかもしれませんが、私の地域（Tampa）Railsは本質的に存在しないことを知っています。

4）火と動き

Railsは常に変化しています。これは良いことでも悪いことでもあります。コミュニティは新しい概念を進化させ、受け入れるため、それは良いことです。コミュニティが進化し、新しい概念を受け入れるため、それは悪いことです。Railsの初心者にとっては非常に圧倒的です。通常、問題に遭遇して見回すと、修正するためにそのような宝石を推奨している人や、とにかくその方法が悪いと言っている人が表示されます。それを使用する、これはより良い方法です...そして、あなたはRailsの認知度に遅れずについていくためにRailsと一緒に学ぶための追加のツールのランドリーリストを持つことになります。以下のようなものGit、BDD/RSpec、Cucumber、Haml/Sass、そして他の多くの宝庫がすべて浮かんでいて、Railsランドの「物事を行う正しい方法」として推し進められ、経験から言えば、Rails に加えて12個以上の技術を学ぼうとして圧倒されるかもしれません。標準のRailsツールキットを使用すると「間違っている」と感じるためです。

これは、Rails 3.1によってさらに複雑になり、すべてのSassとCoffeeScriptがデフォルトになっているため、Railsの初心者はRubyとRailsだけでなく、Sass（CSSを知っていれば間違いなくシンプル）とCoffeeScript（クレイジーではないが確かに学ぶ必要があります生のJavaScriptとはかなり異なります）開始するには最低限必要ですが、Gitを想定することもできます。RSpecや友人、そして通常は12個以上のgemを考慮に入れなくても、Railsアプリケーションを本格的に書き始める前に、4つの異なることを学ぶ必要があります。これをC＃、Java、またはHTML / CSS / JavaScript / SQLの知識が変わらないPHPなどの言語と比較し、言語自体とおそらくフレームワークのニュアンスを習得すればよいだけです。

ドキュメンテーション。

一方でRailsのガイドは、（一般やRuby、）素晴らしい学習リソース、Railsのあるライブラリ参照がナビゲートすることは容易ではありません。belongs_to方法についてもっと学びたいとしましょう。ActiveRecord::Baseサブクラス（モデル）で使用されますが、ActiveRecord::Baseドキュメントには記載されていませんが、クラスがインポートするミックスインに記載されています。基本的に、1つの場所でオブジェクトに使用できるすべてのメソッドの包括的なリストを表示することはできません（irbオブジェクト自体を起動して確認する場合を除く）。

Rubyのような非常に動的な言語では、使用しているメソッドがどこから来たのかを伝えるのは簡単ではありません。特に、新しいテクノロジースタックを把握しようとするプログラマーを学習する場合には、問題になる可能性があります。

Ruby on Railsには重要な学習曲線があります。最初に言語の奇妙さを学び、次にフレームワークを学び、次にRailsの物事のやり方を学び、次に一般的に使用される多くのGemsについて学びます。

しかし、それらのことを学んだとき、それは驚くほど自然に起こります。実際、他のフレームワークは負担のように感じ始めます。

Railsは非常にTDD / BDD指向です。そうでない場合は、有能なRailsプログラマになる前に、さらに2つのことを学ぶ必要があります。バックアップするコンパイラとIDEがないので、テストカバレッジは非常にフォールバックです。

私も含めて、多くのTDD支持者は、この1つをRoRの強みの1つであると同時に、その呪いも考慮するだろう。TDDの記述を開始すると、テストカバレッジが提供するセキュリティは、コンパイラが提供するセキュリティよりも優れていることがわかります。コンパイラを喜ばせるためだけにコードを書かなければならないのは負担になります。

TDDはRoRの追加タスクのようなものではなく、唯一の作業方法のようなものです。

Railsには深刻なパフォーマンス上の問題が1つあります：ほとんどのフレームワークが行うようにスレッド化するか、Node.jsやTwisterのような他のリクエストをブロックイベントが解放できるようにするのではなく、各リクエストは現在アクティブなものの後ろにキューイングされます。これは、応答時間を速くするためにコーディングする必要があることを意味しますが、ほとんどの場合、これは非常に簡単です。

また、Railsはコンテンツシステムを非常にうまく処理できるように設計されています。これは公平な点でインターネットの多くです。Webゲームやeコマースシステムなど、もう少し複雑なことをするということは、新しい宝石を学ぶことを意味します。あなたはすぐにすべての宝石がそこにあることを学びますが、あなたがやりたいことを曖昧にするほど、良いドキュメントを見つけることは難しくなります。

私の個人的な経験では、大きな頭痛の種は互換性に関するものです。

いつ：

• あるxプロジェクトが展開レールは、
• 各プロジェクトはygemを使用します。
• nレールにはいくつかのバージョンがありますが、
• プラスm宝石のバージョンがインストールされ、
• severalルビーのバージョン、
• 実動マシンとしての単一のLinuxボックス上。
• プログラマーは別のOS X開発ノートブックで作業します。

アップデートに贅沢を持っていない/物事のほとんどをアップグレードするフリーランサーとして、多くの直面する互換性の問題を ...変数上からしばらくrails、gemsとruby進化/変化し続けます。

速度は間違いなく問題です。Rubyの極端な柔軟性は、パフォーマンスに大きな打撃を与えます。

水平方向のスケーリングは非自明なタスクです。ただし、そのタスク用に特別に設計されたテクノロジーは例外で、通常は単純さと引き換えに適切にスケーリングします。
テクノロジーBの場合よりもテクノロジーAの方がマシンごとに100倍のリクエストを処理できる場合、追加できる時間枠で単一のサーバーからデータを提供できると考える理由がある場合は、テクノロジーAの使用を検討する価値がありますその後の並列化。
2009年、stackoverflowは1つのWebサーバーから引き続き提供されました。もちろん、これはもうオプションではありません。しかし、スケールアウトを心配する前に、単一のインスタンスで多くのユーザーにスケールアップできるテクノロジーから始めたのは良かったと思います。

それに比べて、RoRは本当に遅いです。単純な要求を処理する時間は非常に長いため、多くのクライアントを処理することは問題です（これはすべて、より高速な代替手段に関連して見られることです）。

あいまいな方向性のために、Web開発に適した他のさまざまな言語をRubyと比較するいくつかの数値を以下に示します。

• 行く
• クロージュア
• JavaScript V8（node.js）
• JRuby（忘れられない代替案-問題の分野に応じて、JRubyはRailsアプリの速度を上げるための良い選択か悪い選択かもしれません）
• スカラ
• Java
• C＃

これはJavaのフレームワークXを使用する場合、RoRよりも正確に200倍速いという意味ではないことに注意してください。ただし、これらのベンチマークで測定された速度の違いは、アプリの全体的なパフォーマンスに重要な影響を及ぼします。

Railsには深刻なパフォーマンス上の問題が1つあります：ほとんどのフレームワークが行うようにスレッド化するか、Node.jsやTwisterのような他のリクエストをブロックイベントが解放できるようにするのではなく、各リクエストは現在アクティブなものの後ろにキューイングされます。これは、応答時間を速くするためにコーディングする必要があることを意味しますが、ほとんどの場合、これは非常に簡単です。

これは非常に見当違いだと思います。Railsはマルチスレッドモードで実行できます。マルチスレッドモードで実行する場合は、GILをリリースするIOライブラリ（たとえば、「mysql2」gem）のみを使用する必要があります。そうしないと、無意味になります。

jRubyを使用している場合は、シングルレールプロセスをマルチスレッドモードで実行するだけで、利用可能なすべてのCPUパワーを完全に活用できます。ただし、MRI（Ruby 1.8.xまたは1.9.x）を使用している場合、CPUを完全に利用するには複数のプロセスを実行する必要があります（node.jsの場合も同様です）。

• Railsには、複雑さを隠す隠れた機能がたくさんあります。（ActiveRecordアソシエーション、検証/保存ライフサイクル全体、提供されたヘッダーに基づくリクエストデータの解釈）始めたばかりのとき、これは素晴らしいです。成長するにつれて、アプリを物事を処理する「Railsの方法」に適合させ始めることがわかります。これは良い場合もあれば、無害な場合もありますし、実際にしようとしていることに対して直感に反する場合もあります。すべてのデータベーステーブルをオブジェクトとしてモデル化する必要はありません。検証手順は他の場所で行う必要がある場合があります。多くのRailsプログラマーは、フレームワークと戦うことを避けます（通常は賢明です）が、これの長期的な影響は... Railsの習慣を、それらが必ずしも必要とされない場所に運びます。

• コミュニティには、「魔法」と呼ばれるソフトウェアを書く習慣があります-魔法のように機能するライブラリをキャッシュします！魔法のように速くなるイベントI / O！魔法の魔法！通常、ここにあるのは、非常に魅力的なAPIが不足している技術的なソリューションに提供されており、その事があなたの意図することをする非常にきれいな例にだまされており、後でそれが不完全なソリューションをカバーしていることを発見することです。このサイクルは非常に一定であり、それを順を追って学ぶことはできますが、依存している多くのコードを読むという考えを確実に理解する必要があります（良いことです！）。Railsコミュニティの魔法のソリューションは、READMEが示唆するほど魔法ではない、と私は言っています。

• 上記の結果：Railsを使用するほど、そのソースを読む必要があります。フレームワークの内部構造をよく理解するほど、長期的には幸せになります。これは実際にはRails固有ではありませんが、ここでの経験から話しています。メソッド名は、実際には得られないものを約束することがあります。

• 貨物カルト主義はRailsの問題ですが、おそらくすべてのフレームワーク/ langコミュニティの問題です。Railsでは（私には）より顕著であるようです。そのため、Railsコードに奇妙な世代の外観を与える傾向があります-さまざまなRailsプロジェクトで作業するにつれて、作成された期間を裏切る傾向がある特定の傾向に気付くでしょう。その声明から推測できるように、コミュニティは新しいソリューションの採用と古いソリューションの廃止を非常に速く進める傾向があります。日常的に経験するコードの一部を理解するためだけに、Rubyニュースの真上にいる必要があります。

• 一般的に言えば、データの同時実行性の問題は通常、コミュニティによって十分に対処されていないと思います-アプリを成長させると、データを分割し、物理的にリモートの変更をロールバックし、データへのアクセスをロックする必要がある時点に達すると、ソリューションはもう少し手作業で調整します。これにより、見栄えの良いRailsの一部が、精度の技術的な必要性によってすべて汚されます。Railsはあなたがウェブアプリで抱えるすべての問題を解決するわけではありません、私は言っていると思います、そしてクリエーターは確かにそのメッセージを説教していませんが、それが暗示されていると思わせるのは簡単です。

見方によっては、Railsの変更速度が警告になる場合としない場合があります。物事は、解決策を吸って必要としているものからさらに多くのものが奪われているため、年ごとに幾分急進的に変化します。

あなたが活発な開発をしているなら、しかしあなたはこれの脈動に指を持つでしょう。