Ruby on Railsのメリットは何ですか？ 20年のプログラミングの後、私はRailsを使用します

クールエイドが多すぎると、Railsの使用を主張していると、クライアントについて不満を言う人がいるのを時々耳にします。 彼らがリクルーターである場合、彼らはさらに別のRubyonRailsの「primadona」開発者を見つけなければならないことに腹を立てているように感じます。 次に、GitとPHPのこの驚くほど無知な比較に似たものを引き出して、自分たちの主張を証明します。 「彼らは彼らが何を求めているのかさえ知りません」と彼らは言います。

プログラマーとしての私たちにとって、クライアントが手がかりを持っていないように見えることがあります。 私たちはこのようなケースを誇張するのが大好きです。 少し考えてみると、物を作るためにお金をくれている人がどういうわけか限られていて、「うまくいかない」と考えるのは正しくないようです。 実際、ほとんどのクライアントはオプションをうまく知っていると思いますが、それでもRailsを使用することにします。

私の意見では、Railsが多くのプロジェクトやニーズに対して真剣に検討されるのに十分なほど有益である理由を説明しようと思います。

Rubyの利点

Rails自体がなければ、Rubyの利点について誰も知らない可能性があります。 一部の人々は、Rubyを「Rubyにとってとても簡単」で「Railsと呼ばれる輝く鎧の騎士」であり、Railsがなければ「Rubyは無関係だ」と言って軽蔑するのが好きです。 それが本当かどうかは定かではありませんが、このような素晴らしい言語を世界が見逃してしまったら、それは大きな恥だと思います。 事実は次のとおりです。Railsの作者は意図的にRubyを選び、彼の「ワイルド」な賭けは大きな関心を持って報われました。 彼が当時見たもの、他の多くの人が今日見ることができます。 Rubyはどういうわけか、「洗っていない大衆」に説明するのが非常に難しい特別な方法でプログラマーを可能にします。 では、なぜRubyonRailsを使用するのでしょうか。 宣伝されているように、Rubyはプログラマーを幸せにします。

ほとんどの開発者はRubyが便利であることに同意していますが、あまりにも多くの開発者がそれを認識しています。 彼らは、Rubyが許可するすべての自由、誤用の可能性のすべてで何が起こるかについて心配しています。 モンキーパッチで説明しましょう：

 "1".to_i #=> 1 class String def to_i raise 'foobar' end end "1".to_i #=> RuntimeError: foobar

とても簡単です。たった5行のコードで、既存のクラスを取得し、その動作をオーバーライドしました。 Nohtingは神聖であり、文字列でさえありません。 この特定のエラーは簡単に見つけることができますが、事態はさらに不吉になる可能性があります。

 class String def to_i self.to_f - 1.13 end end "2".to_i #=> 0.8700000000000001

ちょうどそのように、Stringクラスにエラーを導入しました。このエラーは、複雑なレイヤーごとにラップされ、レイヤーによって隠される可能性があります。

だから、あなたは考えているかもしれません：みんなと彼らの母親は私の貴重なアプリケーションを台無しにすることができますか？ この動作は確かに恐ろしいように見えますが、実際にはそうではありません。 Rubyを使用して5年間、この動作に関する問題はまったく発生していません。 直感に反しているように見えるかもしれませんが、それでも、道路の真ん中にある細い白い線だけで区切られた反対方向に時速60マイルで車を運転しています。 実際には、どちらも非常にうまく機能します。

もう1つの利点は、Rubyが用途の広いツールであることです。 このように、それは鋭い、ナイフのようなエッジを持っています。 大人はナイフをうまく扱えると思います。子供を保護するのは子供向けです（Tweet）。 そして、ITで子供のように扱われると、PaulGrahamのBlubパラドックスの犠牲者になります。理解できない特定の機能や誰かが危険すぎると言った機能がない方が良いと思います。 もちろん、今日は「RubyonRailsを使用する理由」を尋ねています。 したがって、これはまた別の議論です。 確かに、Rubyは他の言語が持っているいくつかの機能（Lispうーん、うーん）を見逃しています。 全体として、Rubyは「言語の力の連続体」の頂点に近いものです。

Rubyでの最初の数年間は謙虚でした。 他の人のコードを読んだだけで、たくさんのことを学びました。 時々、私は驚いた。 時々、私は怒っていました。 しかし、最終的には、この知識により、以前よりもはるかに効果的にコンピューターと通信できるようになりました。 「私はあなたのために最善を尽くしているだけです。それはあなた自身のためです！」と言いながら、フープを飛び越えるためだけにフープを飛び越えさせる他の「赤いテープ」言語については、ほとんど申し訳ありません。

プラグマティズム

RailsのDNAに可能な限り低いレベルで組み込まれている実用主義には深い敬意が払われています。 この実用主義は、Rubyの利点と組み合わせて、エレガントなソリューションを生み出し、RubyonRails開発コミュニティに同じことをするように促します。 プラグマティズムはRailsのテントとして宣伝されることが多いので、この主張は新しいものではありませんが、私の友人がHibernateが本当にどれほど「クール」であるかを見せてくれたので、ごく最近、それが真実であることを思い出しました。 彼は苦労していた。 そもそもフレームワークのデフォルトであるはずの無数のオプションや構成パラメーターを設定できなかったので、彼の痛みを感じることができました。

年齢とともに、人工的な複雑さの私の基準はますます高くなっています。 私が1989年に11歳でプロダクションコードを書き始めたことを考えると（Clipper Summer '87の隣人のためのプロジェクトから始めて）、不必要な合併症に対する許容度はほぼゼロです。 そして、Railsはその部門で本当に高いスコアを獲得しています。 それは単なる「設定より規約」以上のものです。 私は、Railsコミュニティ内で高く評価され、浸透している実用的な考え方全体について話しています。

表現力

Railsは英語に限りなく近いです（COBOLを使用している場合を除く）。 内部DSLと呼ばれるものを使用し、独自のセマンティクスでRubyを拡張します。 新しい言語を効果的に開発しているため、DSLの構築は常に危険です。 内部であるため、外部パーサーを使用する必要はありませんが、ある意味では新しい言語のように感じられます。 Railsチームは、DSLとのバランスを取り、それが理にかなっている場所で使用し、ほとんどやり過ぎないことで、優れた自制心を示しました。 Railsの経験に関係なく、すべてのプログラマー（および一部の非プログラマーでさえ）はこれを理解できると思います。

 class User < ActiveRecord::Base devise :database_authenticatable, :registerable validates_numericality_of :years_of_experience, :allow_blank => true acts_as_taggable acts_as_taggable_on :certificates, :expertise_kinds validates_presence_of :first_name, :last_name, :email has_many :translations has_attached_file :avatar, :styles => {:small => "240x240>"} has_attached_file :cv ...

実際、Rubyに慣れていない場合、これは奇妙に見えるかもしれません。まるでプログラミング言語ではないかのようです。 かっこなしのメソッド呼び出しであることに気づいたら、準備は完了です。 それでも、Rails DSLは、要件を記述するためのこの特別な言語であるように感じますが、実際には、Rubyの優れた構文のスマートな命名と固有の使用法にすぎません。

コミュニティ

Railsにはコミッターの軍隊があり、それが最高の状態に保たれていることを確認します。 多くのプロジェクトは年齢とともに煮詰められますが、Railsを使用すると、意思決定が必要なときに火花が飛んでいきます。 メンテナは（まだ）本当に気にかけていて、人々にRuby on Railsを使って、その利点を理解してもらいたいと思っています。

Rails自体の下には、Rubyがあり、その手ごわいパッケージマネージャーであるRubyGemsは、パッケージ数の点でCPANに匹敵します。また、CPANの時代を考えると、その主張は（控えめに言っても）非常に印象的です。 Railsは、独自の「Railsプラグイン」を作成しようとしたときに、一時的に脱線しました。 幸いなことに、これは固執しなかったので、RubyGemsは、非常に優秀な個人によってプログラムされたコードの統一された優れたソースのままです。

クールな言語、実用的なWebフレームワーク、および優れたコミュニティ間の相乗効果により、Railsはその部分の合計よりもはるかに優れた結果を得ることができます。

成熟

Railsはブロックの周りにあります。 流行に敏感な方法で、それはもうそれほどクールではありません。 これは、テクノロジースタックを選択する場合に適しています。つまり、実証済みのものが必要です。 そして、Railsはまさにそれです。 私たちは最近、現在利用可能な多種多様なRubyインタープリターとランタイムについて話している記事を書きました。

マーケティング

分かってる。 ITプロフェッショナルとして、私は「深刻な」ことを本当に大切にし、 「キラキラ」を無視する必要があります。 浅く見えるかもしれませんが、それに直面しましょう：

1. 競合他社と比較すると、Railsサイトは見栄えがします。
2. Railsの最初のスクリーンキャストは、当時は息を呑むようなものでした。 今日はそれほど印象的ではないかもしれませんが、Javaについて私たち全員が知っている唯一の理由は、ブラウザでJavaアプレットを実行する可能性について誰もが非常に興奮していることです。 結局のところ、これはそれほど重要ではないことが判明しましたが、それでも、これはJavaをレーダーに乗せました。 同様に、この15分間のブログエンジンのスクリーンキャストは、多くの人々を興奮させた大ヒットでした。

これは虚栄心についてでさえありません。 それはあなたが工場に水を入れるためにあなたができる限り多くの賢い人々を従事させることについてです。 フレームワークを検討する場合、最適な場所は群衆の中にあります。 これらの賢い人々が焦点を当てているフレームワークを選択することは、単にあなたのためにもっと多くの分野がすでにカバーされていることを意味します。 そして、これは私の次のポイントに私をもたらします。

（ではない）車輪の再発明

私には小さなフレームワークが好きです。 特定のフレームワークが何をしているのか、そしてその理由を理解できるのが好きです。 この意味で、Railsはやや肥大化しており、時には圧倒されることさえあります。

ここでのジレンマ：同じものを何度も何度も書きたいですか？ 確かに書き直せるものもありますが、時間がかかります。 Railsに許可すればするほど、機能の書き直しや再実装について心配する必要が少なくなります。

Railsは（彼らが言うように）「バッテリーが含まれています」。 あなたがスパース性に熱心であるか、すべてがどのように機能するかについての広範な知識を持つ必要を感じるならば、これは良いことではありません。 実際には、あなたがあなたの恐れを手放すならば、それはうまくいくようです。 Railsには、必要なほとんどすべてに対して妥当なデフォルトがあり、狭い場所に追い込まれないように十分にモジュール化されています。

結論

もう一度自問してみてください。なぜRubyonRailsを使用するのですか？ Railsは、シングルページJavaScriptアプリケーションと競合する最先端のパブリックWebサイトと、通常は少し「見苦しい」（より一般的で忠実度の低いUIを備えた）複雑なエンタープライズコアシステムアプリケーションの両方に適していますが、これを補います複雑なビジネスルールとロジックが大量にある傷。 その利点は、用途が広く、洗練されたものと強力なものの両方と競争できることです。

一般的な問題のほとんどについて、Railsには、ほぼすぐに使用できるコンポーネントがあり、ドキュメントは常に平均を上回っています（どういうわけか、Railsコアチームは、ドキュメントを書くのはクールだと貢献者を説得しました（私たち全員が知っているとしても）ではありません）、よく書かれた、簡潔で時間の節約になるドキュメントにつながります）。

ユニコーンと金曜日の抱擁を脇に置くと、将来のゲームチェンジャーと次の中道ビジネスサイトの両方に使用できる強力なフレームワークになります。 そして、最高級の宝石のプールを使用すると、コンピュータープログラミングで最も優れたアイデアのいくつかを実装する武器を指先で手に入れることができます。 大騒ぎせずに。