Ruby on Railsの驚異的な人気は、主に適切なタイミングで新しいトレンドとテクノロジーに移行したことによるものです。
しかし、残念なことに、長期にわたる技術的な利点は無関係になります。 したがって、RoRが関連性を維持し続けるだけでなく、その影響力とコミュニティを拡大する方法の詳細な説明が必要です。
私の提案は、相反する合意が無敵の要因であり、今も残っているということです。
この契約は過去10年間にわたって積極的に開発されてきましたが、基本的な考え方のほとんどは触れられていません。 私はこれらのアイデアの基本的な独自性のふりをしません。 Railsの主な成果は、プログラミングとプログラマーの性質について非標準的なアプローチと世界観を持つ人々の強力なコミュニティをまとめることです。
そこで、Rails契約の9つの最も重要な柱と、謙虚な召使がそれらをどのように認識しているかを以下に示します。
- プログラマーの喜びのための最適化
- 構成合意
- メニューはおまかせ
- パラダイムの欠如
- 美の教団コード
- 鋭い刃
- 統合システムを評価する
- 安定性よりも進歩
- 大きなテントを建てる
プログラマーの喜びのための最適化
Ruby on RailsはRubyなしでは存在しません。そのため、契約の最初の柱はRubyのソースそのものから来たのは論理的です。 Rubyは、他の多くのプログラミング言語とは異なり、台座での開発の喜びを高めます。
Pythonが「望ましいものを実装する唯一無二の方法」があると自慢できるなら、Rubyは表現力と簡潔さを楽しんでいます。
Javaがプログラマーを積極的に保護していたのに対して、Rubyは学習の最初のステップにロープとスターターキットを落とし、Smalltalkは確立された文化の整合性を突破し、Rubyはキーワードと構成を熱心に蓄積しました。
Rubyは他のアイデアを優先するため、違います。 そして、これらのアイデアの1つは、開発中にプログラマに幸福をもたらすことです。 他のプログラミング環境と比較して彼を際立たせたレース、プログラマーが誰であり、何をすべきかという認識。
Rubyは、実現するだけでなく、プログラマーの感情のパレット全体に対応するようにも設計されています。 不十分、空想、喜びのいずれかです。 Matzは驚くべき複雑さのアイデアの実現を提供しました。その本質は、開発環境がプログラマーのアシスタントでなければならないということです。 Rubyは、一見シンプルで明確に見えるものが、背中の後ろに手を縛られたアクロバティックなスタントであるケースの1つです。 これらの決定に対して支払う必要があります（これをすべてリバースエンジニアリングしようとしたJrubyチームに問い合わせてください）。
それは、プログラミングの本質とRubyへの愛からほど遠いプログラマーの役割の代替ビジョンの世界への小さな入門でした。 Rubyは使いやすさだけでなく、ブロックの美観だけでなく、これがなければ単一の技術的成果はありません。 それは新しいビジョンでした。 他の文化、専門家コミュニティ全体の観点から疎外された人々のための場所。
Rubyに没頭することは、私の心を完全に満たす魔法の手袋の発見であると説明します。 私が想像できる最高の。 このイベントは、「私はプログラムが必要だからプログラムを作成する」というパラダイムから「愛と自己表現でプログラムを作成する」というパラダイムになりました。 Mihaly Csikszentmihalyiの仕事に精通している人にとって、Rubyコミュニティへの影響を過大評価することは困難です。
Rubyが私と私の人生を変えたと言っても過言ではありません。 私にとっては一種の啓示でした。 彼は私の心に浸透し、マッツの創造のためのサービスとしての使命を果たす助けを求めました。 彼の創造物を広め、その利点について話すために。
今、私はあなたのほとんどが信じられない思いで頭を振るのを想像することができます。 私はあなたを非難しません。 上で説明したように、私はプログラミングは単なるツールであるという概念の中に住んでいました。もしあなたがあなたの場所にいれば、これも信じず、ある種のカルト言語のトップから笑いました。 しかし、このために私は自分自身や他者に正直でなければなりません。
いずれにせよ、質問はRuby on Railsとは何か、そしてその原則とアイデアに導かれ、どのように進化し続けるのか？ この質問に答えるには、初期のRubyを書くときによく使われていた原則の1つ、最小驚きの原則（PoLS）を与えるのが適切だと思います。 Rubyは期待どおりに動作するはずです。
Pythonとは対照的に、これは簡単に説明できます。
$ irb irb(main):001:0> exit $ irb irb(main):001:0> quit $ python >>> exit User exit() or Ctrl-D (ie EOF) to exit
Rubyは、インタラクティブコンソールを終了するというプログラマーの明確で明白な要望を満たすために、両方のコマンドをサポートしています。 一方、Pythonは、プログラマーの意図を知っていることは明らかですが（エラーメッセージが表示されるため、これは明らかです）、プログラマーが行うべきことを示しています。 これは、PoLSの原理がどのように機能するかを示す非常にシンプルで説明的な例です。
PoLSがRubyコミュニティから支持されなくなった理由は、主観的なアプローチです。 しかし、彼が誰に好意を失ったのかは驚くべきことです。 まあ、この男はマッツです。 そして、彼と同じように驚いた人々。 Rubyコミュニティがそのランクを補充するとすぐに、人々は数え切れないほどの文字の原因となるいくつかの異なることに驚き始めました。
繰り返しますが、これはRuby on Railsとどのように関係していますか？ Railsは、同じ原則とBig Big Smile（DHH）原則を使用して設計されています。
APIは細心の注意を払って設計されているため、ますます笑顔になります。 このように言えば、コミカルで自己陶酔的に聞こえますが、第一印象に反対するのは難しいです。
Ruby on Railsの作成は、かなり自己陶酔的なスタートです。 どちらのプロジェクトも、一人のクリエイターの心から生まれました。 しかし、私は自分の動機をMatzに投影している可能性が非常に高いので、私が知っていることをアピールさせてください。私は主に自分でRoRを作成しました。 快適に設計するために、RoRの核となる価値は、人生をもっと楽しむことです。 毎日のルーチンを自分で取り除きます。
マッツのように、私は時々行き詰まりました。 そのような例の1つは、PersonクラスをPeopleの名前に変換するために英語の多くの不正確さを理解するInflectorクラスです。Analysisの AnalysisテーブルとComment to Comments。 このシステムの振る舞いは、Railsの手に負えない部分として認識されていますが、このトピックに関しては、合意が作成されたばかりのときに論争が激化することがありました。
知覚するのに少し少ない労力で済む別の小さな例：
ああひどい、配列＃2番目＃5番目（そして誰かが#forty_twoによく気づいて、良いトローリング）。 これらのエイリアスは、配列＃[1]配列＃[2]および配列＃[41]を書くことができれば、なぜこんなに多くの添えものがあるのかと嘆いた一部の人々にとって非常に不快でした。
両方の決定により、私は今日まで笑顔になります。 コンソールのテストケースとして3番目に、人々に書いてうれしいです。 いいえ、これは論理的ではありません。 効果的ではありません。 しかし、それは私に笑顔を与え、私の人生を豊かにするための原則に従い、そして今後12年間のRailsへの私のさらなる貢献を正当化します。
パフォーマンスの最適化とは異なり、開発のユーザビリティとプログラマーの幸福度を測定することは困難です。 これにより、この事業はほとんど本質的に非科学的になりました。 プログラマーは、AがBよりもカテゴリー的に優れている場合に、明確な結論を導き出すことができる測定可能な問題について議論し、操作するように教えられます。
しかし、幸福の追求は小さなことで測定することは困難ですが、これは総計でより明確に見ることができます。 RubyとRailsには、まさにそのような目標を追求する大きなコミュニティがあります。 彼らはより波乱に満ちた人生を誇り、これはポジティブな感情の組み合わせであり、彼らの勝利は明らかです。