レール上の開発者は、同僚、つまりコーヒー愛好家を過去の名残としてよく見ます。 また、Javaの愛好者は、Ruby on Railsを、主要なソフトウェア開発プロジェクトでは役に立たないおもちゃだとよく言います。 両方の技術を集中的に使用したコンサルタントとして、真実はどこかにあることを知っています。 この一連の国境を越えて、私は別の比較をしたいと思います。 特定の言語やテクノロジーを調べる代わりに、現在のプロジェクトに焦点を当て、過去に取り組んだJavaプロジェクトと比較します。 （この機会に、Crossing Bordersシリーズの以前の記事で、ここで詳しく説明しているトピックについて説明します）。 この記事では、まず、Railsを使用してデータベースベースのWebアプリケーションを開発する場合の欠点と潜在的な利点について説明します。
ビジネスチャレンジ
Ruby on RailsもJavaも、問題に対する唯一の適切なソリューションではありません。 成功の可能性を高めるには、ビジネスタスクを慎重かつ徹底的に検討し、環境を理解し、チームを知る必要があります。 その後のみ、問題を解決するための適切な言語を選択できます。
昨年、Arvando Systemsは、ドナーと非営利団体を結びつけるのに役立つ新製品ChangeingThePresent.orgを開発するチームのリーダーとして私を雇いました。 多くのインターネット企業と同様に、顧客が購入するわかりやすい製品を販売しています。 しかし、他の企業とは異なり、「製品」は機会（または贈り物）であり、たとえば癌研究者に1時間50ドルを支払う、盲人を30ドルで助ける、または1エーカーの月齢20エーカーを保護します。
野心的な計画と長期的な複雑さ（プロジェクトの開発全体の複雑さ）という2つの主な課題がありました。
私たちは9月に開発を開始し、クリスマス休暇のために良い利益を得るために11月までに開発を終えなければなりませんでした（実際、2週間遅れました）。 Javaベースのソリューションには6〜18か月かかることがわかっていました。 生産性は非常に重要でした。 Javaソリューションはこの要件を満たしていませんでした。
私たちが直面している課題を考えると、1日あたり100万回のコールのトラフィックを引き付けることができることがわかっていました。 成功するには、1日に数十万件のヒットに対処する必要があったため、スケーラビリティが重要でした。 これは、Javaの使用を示しています。
最後に、サイトの立ち上げ後も、すべてが始まったばかりであることがわかりました。 すべての計画のわずか3％から始めたいと考えていました。 したがって、私たちが使用するテクノロジーは、複雑さの面と負荷の面の両方でスケーリングする必要がありました。
高レベル言語としての機能を備えたRubyと、構成の必要性を減らし、よりシンプルで統合されたプログラミングモデルを備えたRailsは、複雑さの点でより優れた拡張性があると考えました。
しかし、時間とスケーラビリティは私たちに反し、他の要因は私たちに役立ちました。 私たちには絶対に純粋な状態がありました。私たちはどんなテクノロジーでも、私たちが望むどんなチームでも選ぶことができました。 プロジェクト、文化、およびテクノロジーの完全なセットを定義できます。 一般的に、完全な選択の自由がありました。
Javaは優れた汎用言語です。 組み込みシステムやモバイルデバイスなどの新機能に常に焦点を当てています。 Javaは、さまざまな要件の組み合わせにも優れています。 生産性が高く、人気があり、市場で十分にサポートされています。 しかし、このシリーズで見たように、データベースベースのWebアプリケーションをゼロから開発するには、Javaが必ずしも最良の選択であるとは限りません（記事「動的型付け言語でのWeb開発戦略」を参照）。
対照的に、Ruby on Railsは新しいフレームワークです。 トラフィックの多いサイトにRailsを使用した人は多くなく、Railsでのプロジェクトのマルチレベル開発の経験はほとんどありません。 しかし、RailsはデータベースベースのWebアプリケーション向けの非常に生産的なフレームワークです。 最後に、私たちの積極的なスケジュールにより、長期プロジェクトのRails開発の経験がなく、膨大な実装が存在するにもかかわらず、Ruby on Railsを選択することになりました。
決定を下した後、プロジェクトの優秀な開発者をすぐに採用しました。 また、私たちの生産性は予想以上に素晴らしいこともわかりました。 最初は安定性に問題があったため、テスト作業を2倍にしました（記事「統合フレームワークのテスト、パート1」およびパート2を参照）。 倍増して以来、私たちは想像を絶するほど安定性を高めてきました。
哲学
各フレームワーク開発者は、フレームワークの哲学を作成する一連の仮定を使用して作業します。 この哲学の限界を克服する方法を学び、あなたは幸せなプログラマーです。 それらと戦うとあなたは押しつぶされたように感じるでしょう。 RailsとJavaの哲学はまったく異なります。
Railsは、Rubyの動的な性質を幅広く利用する統合フレームワークです（記事「Ruby on Railsの秘密のソースは何ですか？」を参照）。 Rails開発者は、このシリーズの以前の記事で見たように、開発ツールをサポートする新しいツールを導入するのではなく、フレームワークの機能を強化して、開発ツールをサポートし、多くの場合、Webアーキテクチャを簡略化して表示します。 Java開発者は、多くの場合、環境の各部分をまとめて、永続システム、Webシステムを個別に選択し、それらを統合する必要があります。 多くの場合、主要なタスクを簡素化するために開発ツールに依存しています。 Webアーキテクチャは、開発の観点からはより複雑なようです。
完全統合
Javaは、永続性やビューの編成などの1つの小さな問題を解決することを目的としており、Railsは統合環境です。
Rails開発者にとっての利点は、多くの本質的に異なるフレームワークを統合する問題を解決する必要がないことです。
ほとんどのHibernate開発者は、Java Webフレームワークとのリンクを時期尚早に破るというtrapに陥ります。 Railsビューフレームワークは、Railsオブジェクトを保存するためのフレームワークであるActiveRecordとの統合を想定してゼロから構築されています。 Webサービス、構成、およびプラグイン用のRailsフレームワークでの作業と同じ経験ができます。 Javaは多くの本質的に異なるフレームワークをサポートし、これらすべてを統合するためのさまざまなアプローチを採用しています。
Java開発者の利点は選択肢です。 フレームワークをゼロから構築する必要がある場合は、iBATISなどのデータベースまたはJava用の多くのJDBCベースのラッパーフレームワークと統合するためのSQLベースのソリューションを検討できます。 逆に、データベーススキーマから始める場合は、HibernateなどのORMフレームワークを検討できます。 Railsを使用する場合、唯一の主な選択肢はActiveRecordです。 これは、より多くの選択肢を提供するJavaフレームワークが、プロジェクトを統合するための最適なソリューションを提供する場合があることを意味します。 しかし、プロジェクトをゼロから開発していたため、選択は大きな問題ではありませんでした。
動的言語
Railsの哲学の次の主要なコンポーネントは、動的プログラミング言語です（記事「Javaモデルを超えた戦略の入力」を参照）。 Javaツールは、Javaタイピングモデルによって提供される追加情報を活用しようとします。 ツールはエラーを検出し、コードを効果的に再構築またはリファクタリングできます。 Railsは、プログラミング言語の利点も効果的に組み合わせています。 Rubyは、ドメイン固有言語（DSL）を作成するための理想的な言語です（記事「Active RecordおよびJavaプログラミングのドメイン固有言語」を参照）。 Railsでは、モデルオブジェクト間の関係の作成から、ステートマシンやサーバーにアップロードされた画像などの任意のコンポーネントの定義まで、すべてにDSLを集中的に使用しています。 多くの場合、動的言語はより理解しやすいため、RailsプロジェクトはJavaのプロジェクトよりも簡潔で、ユーザーはコードと構成の両方をより明確に書くことができます。 ChangingThePresent.orgでは、トッププログラマーの生産性が向上し、経験豊富なプログラマーを雇う必要がないことに気付きました。 これから嬉しいです。
典型的なJavaプログラマーはIDEに忠実にコミットしており、正当な理由があります。 IDEは彼にコード補完を提供します
一般的なエラーを排除し、インクリメンタルコンパイルを提供して、コーディング、コンパイル、配置、およびテストサイクルを高速化します。 近年、開発環境では、コンパイルサイクルと静的型付けによって提供されるさらに多くの情報を使用し始めています。 IDEは、コードのテキスト表現の代わりに、またはそれに加えて、抽象構文ツリーを編集しています。 この戦略により、動的に型付けされた言語に対して同じメソッドを使用して入手するのがはるかに困難な強力なリファクタリングツールを作成できます。
静的型付けを使用すると、優れた開発ツールを入手できますが、欠点もあります。 静的型付けにはコンパイラが必要であり、コンパイル手順は生産性を完全に台無しにする可能性があります。 Railsを使用すると、コードの行を変更してブラウザーを再起動し、変更の結果をすぐに確認できます。 Javaプログラマーとは対照的に、ほとんどのRubyプログラマーは優れたテキストエディターのみを使用します。 Ruby on Railsの最も人気のあるエディターであるTextMateは、構文を強調し、コードを補完し、一般的に使用されるコンストラクトに対する優れたテンプレートサポートを備えています。 また、エディターはRailsの基礎となる単純なRubyスクリプトを作成するのに十分です。 本格的なデバッガーの代わりに、指定されたアプリケーションを停止し、Rubyインタープリターに送信するブレークポイントスクリプトを使用します。Rubyインタープリターでは、メソッドを呼び出し、変数の値を表示し、実行を続行する前にコードを変更することさえできます。
シンプルなアーキテクチャ
Webアプリケーションの典型的なJavaアーキテクチャには、ドメインオブジェクト、データアクセスオブジェクト、ビジネスレベルAPIを提供するファサードレベル、コントローラーレベル、ビューレベルがあります。 このアーキテクチャは、Smalltalkで最初に使用された従来のモデルビューコントローラアーキテクチャよりもわずかに複雑です。 対照的に、RoRはActiveRecordパターン、コントローラーレベル、およびビューレベルを使用する1つのモデルレベルを使用します。 Railsのアプローチが大好きです。 理解しやすく、複雑さやエラーを追加するスペースが少なくなります。
構成ではなく配置（契約）
Javaフレームワークは多くの場合XML構成を使用しますが、レールは主に規則を使用して構成を可能な限り回避します。 プログラマーが何かを構成する必要がある場合、RailsはRubyに依存します。多くの場合、構成にはDSLの形式が使用されます。 最初から開発する場合、構成ではなく配置が理にかなっています。 この戦略により、多くのコード行が短縮され、記述しなければならないコードが簡素化されます。 Javaで行う必要がある構成の1/10を使用していると考えました。 私たちは時々柔軟性を失いますが、この欠陥が買収を超えるほどではありません。
要約すると、railフレームワークの哲学は、changeingthepresent.orgを作成する問題を解決するのに優れています。 統合されたスタックにより、不必要な統合を自分で行うことなく、フレームワークからより多くの機能を取得できます。 構成ではなく配置の哲学により、時間を節約できます。 動的言語により、経験豊富な開発者はより多くのパワーと柔軟性を得ることができ、より少ないコードでより高度なアイデアを表現できます。 このフレームワークは、私のチームの能力だけでなく、私たちが解決しようとしているビジネスタスクとも一致しています。
持続性
JavaおよびRuby用の最も一般的なストレージフレームワークは、他のすべての機能よりもはるかに優れた違いを示しています。 Java開発者は通常、Hibernateを使用します。 Hibernateでは、既存のモデルと既存のスキーマを取得し、アノテーションまたはXMLを使用してそれらの間の対応を設定します。 Hibernateクラスは、各オブジェクトが1つの共通の基本クラスによって生成されるPOJOです。 ほとんどの構成は、アノテーション、XML、または両方の組み合わせを使用して明示的に行われます。
一方、ActiveRecordはラッパーフレームワークです。つまり、各クラスは既存のクラスをラップします（ 「アクティブレコードの探索」を参照）。 ActiveRecordは、テーブル内の各列の属性など、関連付けられたテーブルのコンテンツに基づいて、モデルオブジェクトに機能を自動的に追加します。 すべてのクラスは、共通の基本クラスから継承します。 ActiveRecordは、主に一般的に受け入れられている規則によって構成されています。 例：
- ActiveRecordはクラス名に基づいてテーブルを検索します。クラス名は複数形で示されます
- 主キー名はidです。
- リストのソート順は、位置と呼ばれるフィールドによって決まります。
ORMは、オブジェクトモデルを考慮して既に開発された既製の回路がある場合に最適なソリューションです。 ただし、アプリケーションのデータベーススキーマを明示的に設計する場合、多くの場合、ORMフレームワークは必要ありません。 ActiveRecordは私たちにとって大きな利点だと考えています。 必要に応じてSQLを使用してリレーショナルデータベースを使用することも、必要に応じてSQLの上に留まることもできます。
移行
Railsの移行により、2つのバージョンのスキーマと、コードに含まれるデータの違いを示すことができます（ 「Railsの移行」を参照）。 各移行には名前と番号が付けられます。 いつでもスキーマのバージョンからバージョンに切り替えることができます。
移行にはいくつかの特別な利点があり、次のことが可能です。
- 不良コードを削除すると、回路の古いバージョンを復元します
- SQLではなくコードでスキームを設定します。これは私たちにとってより便利です
- ほとんどの場合、データベースに依存しない
ただし、移行には制限があります。 2人の開発者が同時に移行を作成する場合、数値が混乱する可能性があるため、手動で介入する必要があります。 効果的なコミュニケーションにより、これらの問題を最小限に抑えます。チームメンバーは、移行が必要な新しいモデルを構築するときに発言します。 ただし、このモデルは通常、少数の開発者に依存するか、移行の一部に影響します。
ActiveRecordには他にも欠点があり、そのいくつかは意図的なものです。 Railsの創設者は、制約と構成はデータベースではなくアプリケーションに設定されていると考えており、これは副作用を引き起こします。 ActiveRecordはビューをあまり使用しません。作成プロセスは、回路を複製し、テストデータをコピーし、テストを実行しますが、正しくコピーしません。
ActiveRecordには、参照整合性に関する場合もあります。これは、一部の種類の関連付けでは複数のデータベーステーブルを使用できるためです。 複雑なモデルの集中的なロードは非常に複雑であり、複数の行を組み合わせる必要がある場合にSQLが必要になることがよくあります。 継承は制限されています。ActiveRecordでは、 singe table inheritenceと呼ばれるマッピング戦略を使用せざるを得ませんが 、これは常に最適とは限りません。
すべてのストレージ戦略は妥協の絡み合いです。 ActveRecordは効果的な妥協点で攻撃すると信じていますが、単純さという点では罪を犯します。 したがって、ActiveRecordと移行は、私たちにとって大きなプラスです。 ソリューションを迅速に作成でき、必要なときにパフォーマンスを向上させるためにSQLに十分にアクセスできます。 しかし、ActiveRecordが常に勝つとは限らない既成のスキームを持つプロジェクトでRailsを使用することは健全です。 JavaフレームワークのiBATISポートであるRBatisなど、代替ストレージモデルが開発されています（リソースを参照）。 しかし、RBatisがどれほど効果的であるかを言うのは時期尚早です。
おわりに
私のチームと私の状況にとって、Ruby on railsは非常に効果的であることが判明しました。 私たちは3か月しか住んでいないので、プロジェクトの規模がどれほどうまくいくかはまだわかりません。 トラフィックが確実に増加しました。 しかし、生産性については知っています。
Javaソリューションを提供する競合店とは異なり、チームはより低い予算を必要とする道を進んだことを知っています。 私たちの生産性にも満足しています。
Crossing Bordersシリーズでは、Javaのソリューションの範囲外の言語とソリューションを紹介しました。 結局のところ、プログラマーは職人です。 経験豊富な職人のキットには、あらゆる状況に適した幅広いツールが含まれている必要があります。 資金に加えて、あなたが見た視点は、あなたが使用できる新しいアイデアを提供します。 現在でも、フレームワーク開発者はSeaside、Rails、さらにはJavaフレームワークのJavaScriptの技術を使用しています。 同じことをして国境を越えるチャンスを探してください。
著者について
ブルース・テイトは、テキサス州オースティンの父親であり、マウンテンバイカーであり、カヤッカーです。 WellGood LLCのCTOおよびChangingThePresent.orgのチーフアーキテクト。 また、Joltの勝者であるBetter、Faster、Lighter Javaを含む3つのベストセラーJava書籍の著者でもあります。 彼は最近、JavaからRuby on Rails：Up and Runningをリリースしました。 IBMで13年間働いた後、軽量の開発戦略とRubyおよびRuby on Railsアーキテクチャを専門とするコンサルティング会社RapidRedを設立しました。