104
Help us understand the problem. What are the problem?

posted at

updated at

The Rails Doctrine(日本語訳)

(訳者注: 原文は https://rubyonrails.org/doctrine/ です。しばらく寝かして問題なさそうであれば本家に投げようかと思っています。おかしいところがあればコメント・編集リクエストをお待ちしております。)

The Rails Doctrine

By David Heinemeier Hansson in January, 2016

Ruby on Railsの驚異的な台頭は、斬新な技術とタイミングによるところが少なからずあります。しかし、技術的な優位性は時間の経過とともに失われていきますし、タイミングの良さだけでは長期にわたってムーブメントを維持できません。そのため、Railsがどのようにして的確さを維持してきたのかだけでなく、どのようにしてそのインパクトとコミュニティを成長させてきたのかについて、より広範な説明が求められています。私が提唱するのは、永続的な実現要因は、今も昔も物議を醸しているドクトリン(信条)にあるということです。

このドクトリンは過去10年の間に進化してきましたが、その最も強力な柱のほとんどは開発当初からのものでもあります。私はこれらの考え方の根本的なオリジナリティを主張していません。Railsの主な成果は、プログラミングとプログラマーの本質についての異端的な考えを手広く集めたものを中心に、強力な部族を団結させ、育成したことです。

以上のことを踏まえて、Railsのドクトリンとして最も重要な9つの柱を以下に紹介します。

  • プログラマーの幸せへの最適化 Optimize for programmer happiness
  • 設定より規約 Convention over Configuration
  • メニューは「おまかせ」 The menu is omakase
  • 唯一のパラダイムはない No one paradigm
  • 美しいコードの称賛 Exalt beautiful code
  • 鋭利なナイフの提供 Provide sharp knives
  • 統合されたシステムであることを重視 Value integrated systems
  • 安定性よりも進歩 Progress over stability
  • 大きな傘を広げる Push up a big tent

プログラマーの幸せへの最適化 Optimize for programmer happiness

RubyなしではRailsは存在しません。そのため、最初の信条の柱がRubyを作る動機の核心から直接導き出されたものであることは当然のことです。

Rubyの独特な特徴は、プログラマーの幸せを台座に据えたことでした。それ以前のプログラミング言語やエコシステムを牽引してきた他の多くの競合する有効な懸念事項よりも優先して、です。

Pythonが「何かをするための方法は一つしかない」を長所として掲げるのに対し、Rubyは表現力と繊細さを追求してきました。Javaがプログラマーを自分たちから強制的に保護することを主張していたのに対し、Rubyは初学者向けキットに鋭利なナイフ一式を入れていました。Smalltalkがメッセージパッシングの純粋さを追求していたのに対し、Rubyはキーワードやコンストラクトを貪欲に蓄積していきました。

Rubyが他の言語と異なっていたのは、Rubyが異なるものを大切にしていたからです。そして、それらの多くはプログラマーの幸せへの憧れにつながるものでした。Rubyのポリシーは、他の多くのプログラミング環境だけでなく、プログラマーとは何か、どのように行動すべきかという主流の認識とも対立していました。

Rubyはプログラマーの感情を認識するだけでなく、それを受け入れ、高めようとしました。それが不完全であろうと、気まぐれであろうと、喜びであろうと。Matzは、驚くほど複雑な実装のハードルを飛び越えて、機械が人間の共犯者を見て笑っているように見えたり、お世辞を言っているように見えたりするようにしました。Rubyは、私たちの心の目にはシンプルで明確で美しく見えるものが、実際には床下配線のアクロバティックな混乱であるような錯覚に満ちています。これらの選択は容易に達成されたものではありませんでした(この魔法のオルゴールをリバースエンジニアリングしようとしたことについてはJRubyのクルーに尋ねてみましょう!)。それこそが、彼らが賞賛に値する理由です。

私のRubyへの恋心を決定づけたのは、プログラミングとプログラマーのための新たなビジョンへの真摯な姿勢でした。それは単に使いやすさだけではありません。ブロックの美学だけでもありません。また一つの技術的な成果でもありません。それはビジョンでした。カウンターカルチャーでした。既存のプロのプログラミングの型にはまってしまった人たちが、同じような心を持った人たちと仲間になるための場所でした。

私は以前、このRubyの発見を、自分の脳に完璧にフィットする魔法の手袋を見つけたと表現したことがあります。それまで自分に合った手袋として期待していたあらゆる想像を上回るものでした。しかし、それ以上のものでした。「プログラムが必要だったからプログラミングする」から、「知的なエクササイズと表現の手段としてのプログラミングが気に入ったからプログラミングする」へと、私自身の変化を示す出来事だったのです。それは、フローの源泉を見つけて、それを自由にオンにすることができるようになったことでした。チクセントミハイの仕事をよく知っている人にとっては、このインパクトは言い過ぎではないでしょう。

Rubyは私を変え、私のライフワークへの道を切り開いてくれたと言っても過言ではありません。それほど深い啓示でした。それは私にMatzの創造物に奉仕して宣教活動をするという召命を吹き込みました。この深遠な創造とその恩恵を広める手助けをするために。

皆さんの多くが信じられずに首を振っているのは想像できます。私はあなたを責めるつもりはありません。もし私がまだ「プログラミングはただの道具」というパラダイムの下で生きていたときに、誰かが上記の経験を説明してくれたら、私も首を横に振っていたでしょう。そして、宗教的な言葉を使った大げさな表現には笑っていたでしょう。しかし、これが真実であるためには、一部の人やほとんどの人が不快に思うようなことであっても、正直でなければなりません。

それはさておき、このことはRailsにとって何を意味し、この原則はどのように進化の指針となり続けるのでしょうか? その問いに答えるためには、初期の頃にRubyを説明するのによく使われていた別の原則、「驚き最小の原則」を見てみるのが有益だと思います。Rubyはあなたが期待するように振る舞うべきです。これはPythonとの対比で簡単に説明できます。

    $ irb
    irb(main):001:0> exit
    $ irb
    irb(main):001:0> quit

    $ python
    >>> exit
    Use exit() or Ctrl-D (i.e. EOF) to exit

Ruby は exitquit の両方を受け入れ、プログラマが対話型コンソールを終了したいという明らかな欲求に対応しています。一方、Python は、(エラーメッセージを表示しているため) 何を意味しているのか明らかに分かっているにもかかわらず、要求されたことを適切に行う方法をプログラマに指示します。これは、小さいとはいえ、「驚き最小の原則」のかなり明確な例です。

「驚き最小の原則」が Ruby コミュニティの支持を得られなくなった理由は、この原則が本質的に主観的だからです。誰にとって驚きが最小なのでしょうか? まあ、Matzにとってですね。そして、彼と同じように驚いている人たちです。Ruby コミュニティが成長し、Matz とは異なることに驚く人の割合が増えていくと、メーリングリストでは、この原則は実りのない自転車小屋の議論の源になっていきました。そこで、XさんがYという挙動に驚いたかどうかについて、どこにも行かないような議論をさらに招くことを避けるために、この原則は背景に消えていったのです。

では、繰り返しになりますが、これがRailsと何の関係があるのでしょうか。まあ、Railsは「(Matzにとっての)驚き最小の原則」と似たような原理で設計されています。「(DHHにとっての)微笑み最大の原則」という原則は、まさにブリキに書いてある通りです。私をもっともっと広く笑顔にしてくれるようなものに細心の注意を払って設計されたAPIです。このように書き出すと、ほとんどコミカルなナルシストのように聞こえますし、私でさえ、その第一印象に反論するのは難しいと思います。

しかし、RubyやRailsのようなものを作るということは、少なくともその最初の段階では、深く自己愛的な献身の賜物なのです。どちらのプロジェクトも、一人のクリエイターの頭の中から生まれたものです。しかし、おそらく私はここでMatzに自分の動機を投影しているのかもしれないので、私の宣言の範囲を私が知っていることに絞ってみます。私は私自身のためにRailsを作りました。まず第一に、私を笑顔にするために。Railsの実用性は、私の人生をより楽しいものとするためにRailsに持たせた、その能力に従属するものでした。Web情報システムへの要求やリクエストをこなす日々の労苦を豊かにするために。

Matzのように、私も時折、自分の主義主張を貫くためにふざけたことをしました。その一例が、PersonクラスをPeopleテーブルに、AnalysisクラスをAnalysesに、そしてCommentクラスをCommentsにマッピングするのに十分な英語のパターンと不規則性を理解しているクラスであるInflectorです。この動作は現在ではRailsの疑う余地のない要素として受け入れられていますが、まだドクトリンとその重要性がまとまっていなかった初期の頃には、論争の火種が猛威を振るっていました。

実装の労力はそれほどかからなかったものの、ほぼ同じくらいの騒動を引き起こした別の例を紹介します。Array#secondから#fifthまで(および#forty_twoは荒らし対策として)です。これらのエイリアスアクセサは、Array#[1]Array#[2](及びArray[41])のように書くことができるものの肥大化(及び文明の終焉に近いもの)として非難され、たいへん声高な支援者に深く不快感を与えました。

しかし、この二つの決定は今でも私を笑わせてくれます。テストケースやコンソールでpeople.thirdを書く楽しさを満喫しています。もちろん、この楽しさは論理的ではありません。効率的ではありません。病的かもしれません。しかし、それは私を笑顔にし続け、こうして原則を満たし、私の人生を豊かにし、12年間のサービスの後にRailsに関わり続けていることを正当化するのに役立っています。

パフォーマンスの最適化とは異なり、幸福度の最適化を測定するのは困難です。そのため、ほとんど本質的に非科学的な努力になっています。ある人にとっては重要性が低く、イライラさせてしまっているかもしれません。プログラマは、測定可能なものを議論し、征服するように教えられています。明確な結論があり、AがBよりも優れていると断言できるものを、です。

とはいえ、幸せの追求はミクロレベルでは測定が困難ですが、マクロレベルで観察するとはるかに明確になります。Ruby on Railsコミュニティには、まさにこの追求のためにここにいる人たちがたくさんいます。彼らは、より良い、より充実した仕事人生を自慢しています。このような感情の集合体の中で、勝利は明らかなのです。

というわけで、結論です。幸せのために最適化することは、おそらくRuby on Railsの最も形成的な鍵なのです。そして今後もそうあり続けるでしょう。

設定より規約 Convention over Configuration

Railsの初期の生産性のモットーの1つは、次のようなものでした。「あなたは美しくてユニークな雪の結晶ではない」というものです。空虚な個性を手放すことで、平凡な意思決定の煩わしさを跳ね除け、本当に重要な分野ではより速く進歩することができると仮定しています。

データベースの主キーがどのような形式で記述されているかなんて誰が気にするでしょうか? それが "id"、"postId"、"posts_id"、または "pid"であるかどうかは本当に重要でしょうか? これは繰り返し審議する価値のある決定なのでしょうか? いいえ、そうではありません。

Railsのミッションの一部は、Web用の情報システムを作成する開発者が直面する、分厚くて増え続けている反復的な意思決定のジャングルに鉈を振るうことです。このような意思決定は何千もありますが、本来は一度で済むことですし、誰かが代わりにやってくれるのであれば、それに越したことはありません。

設定より規約への移行は私たちを熟考から解放するだけでなく、より深い抽象化を育むための豊かな土壌を築いてくれます。
Person クラスが people テーブルへマッピングされるのを期待できるなら、同様の変化を用い Person クラスへマッピングされることを期待してアソシエーションを has_many :people と宣言できます。優れた規約の力は幅広い用途で役に立つのです。

しかし、エキスパートの生産性向上だけでなく、初心者の参入障壁を下げることもできます。Railsには、初心者が知らなくても恩恵を受けられるような規約がたくさんあります。すべてのものがなぜそのようになっているのかを知らなくても、素晴らしいアプリケーションを作ることは可能です。

フレームワークが分厚い教科書に過ぎず、新しいアプリケーションが白紙の紙切れに過ぎないのであれば、そんなことは不可能です。どこからどのように始めればいいのかを把握するのには、膨大な努力が必要です。始めるための戦いの半分は、引っ張るべきスレッドを見つけることです。

すべてのピースがどのように組み合わされているのかを理解している場合も、同じことが言えます。変更する際、変更後の状態がいつでも明確であれば、私たちは、その前のすべてのアプリケーションと同じか、非常に似ているアプリケーションの多くの部分を、駆け足で通過することができます。すべてのもののための場所、すべてが備わっている場所。制約は、最も有能な心をも解放します。

しかし、何事もそうですが、慣習の力には危険がないわけではありません。Railsがこれだけ多くのことをあまりにも取るに足らないようにみせていると、アプリケーションのあらゆる側面は既成のテンプレートで作れるのではないかと考えがちです。しかし、構築する価値のあるほとんどのアプリケーションには、何らかの方法でユニークな要素があります。それは5%や1%に過ぎないかもしれませんが、そこに存在しています。

難しいのは、いつ慣習から逸脱するかを把握することです。逸脱した特殊性は、いつ、遠出を正当化するのに十分なほど重大なものなのでしょうか? 私は、美しくユニークな雪片になりたいという衝動のほとんどは、十分に考慮されておらず、Railsから外れて行くことのコストが過小評価されていると主張しますが、慎重に検討するまでもないこともあるでしょう。

メニューは「おまかせ」 The menu is omakase

何が美味しいか分からないのに、レストランで何を注文すればいいのか、どうやってわかるのでしょうか? そうですね、シェフに選んでもらえば、何が「美味しいもの」かわからないうちから、たぶん「美味しいもの」にありつけます。それが「おまかせ」です。料理の達人でなくても、暗中模索の運任せでなくても、美味しいものを食べるための方法なのです。

プログラミングにとって、他の人にスタックの組み立てを任せるというこのプラクティスの利点は、「Convention over Configuration」から得られるものと似ていますが、さらに高いレベルでのものです。CoCが個々のフレームワークをどのように使うのがベストなのかということで占められているのに対し、おまかせはどのフレームワークをどのように組み合わせて使うのかということに関心があります。

これは、利用可能なツールを個々の選択肢として提示し、個々のプログラマに決定する特権(と負担)を与えるという崇高なプログラミングの伝統と対立しています。

「仕事に最適なツールを使え」という言葉を聞いたことがあるでしょうし、うなずいたこともあるでしょう。これは議論の余地がないほど基本的なことのように聞こえますが、「最高のツール」を選べるかどうかは、自信を持って「最高」を決められるほどの根拠にかかっています。これは見た目よりもずっと難しいことです。

これは、レストランでのディナーの問題に似ています。そして、8品の食事の各コースを選ぶように、個々のライブラリやフレームワークを選ぶことは、独立して行う仕事ではありません。どちらの場合も、目的はディナーやシステム全体を考慮することです。

そこでRailsでは、道具箱の中から好きなツールをそれぞれ選ぶというプログラマーの個人的な特権である善の一つを減らすことにしました。より大きな善、「何にでも使えるより良いツールボックス」のためにです。その結果、多くの利益を得ることができました:

  1. 数は安全性を生む: ほとんどの人が同じデフォルトの方法でRailsを使っているとき、私たちは同じ経験を共有しています。このような共通の基盤があると、人に教えたり助けたりするのが格段に容易になります。アプローチについての議論の基礎を築くことができます。昨日の夜7時にみんなで同じ番組を見たので、次の日にはその話をすることができます。それはより強いコミュニティの感覚を育みます。

  2. みんなで同じ基本ツールボックスを完成させる: フルスタックフレームワークであるRailsには多くの動作部品があり、それらがどのように連携して動作するかは、単体で何をするかと同じくらい重要です。ソフトウェアの痛みの多くは、個々のコンポーネントではなく、その相互作用から生じます。同じように構成され、同じように失敗するコンポーネントの共通の痛みを和らげることに全員で取り組めば、痛みを経験することは少なくなります。

  3. 置き換え可能だが、置き換えなくともよい: Railsはおまかせスタックですが、特定のフレームワークやライブラリを他の物で置き換えることはできます。ただ、それは必須ではありません。つまり、特別な違いを好むような明確で個人的なパレットを開発するまで、そのような決定を遅らせることができるということです。

なぜなら、Railsを使い始めて今でも使い続けている、最も経験豊富で熟練したプログラマーでさえ、メニューのすべてに反対しているわけではないはずだからです(もしそうであれば、おそらくRailsに留まっていなかったでしょう。) そのため、彼らは真摯に代替品の選別を行い、その後、他の人々と同様に残りの部分を楽しむようにしています。

唯一のパラダイムはない No one paradigm

一つの中心的なアイデアを掲げて、そこから論理的帰結としてアーキテクチャの基盤を導こうとする強く熱心な主張があります。このような規律には純粋さがあるため、プログラマーが自然とこの明るい光に惹かれるのは明らかです。

Railsはそうではありません。一枚の完璧な反物ではありません。キルトです。多くの異なるアイデアやパラダイムの複合体です。その多くのものは、単独で一つ一つ対比させれば、通常は対立していると見られるようなものかもしれません。でも、私たちがやろうとしているのはそのような対立ではありません。それは、唯一の勝者が宣言されなければならない、優れたアイデアの選手権ではないのです。

Rails MVCの中のビューを構築しているテンプレートを見てみましょう。デフォルトでは、これらのテンプレートからコードを抽出されたヘルパーは、すべてを大きな鍋に突っ込まれた関数にすぎません! 名前空間すら一つにまとめられています。なんと衝撃的で恐ろしいことでしょう、昔ながらのPHPのスープのようなものです!

しかし、ビューテンプレートの多くの抽象化がそうであるように、相互作用をほとんど必要としない個々の関数を提示するという点では、PHPは正しかったと私は考えています。そして、この目的のためには、単一の名前空間、メソッドの大きな鍋は、合理的な選択であるだけでなく、優れた選択でもあります。

だからといって、ビューを構築する際に、よりオブジェクト指向的なものに手を伸ばしたくなることもないわけではありません。プレゼンターのコンセプトは、相互に依存している多くのメソッドとその下にあるデータをラップすることで、依存関係によって酸っぱくなってしまったメソッドのスープの完璧な解毒剤になることがあります。しかし、これは一般的に適合するものではなく、稀に適合するものであることが示されています。

一方、私たちは通常、MVCにレイヤー化されたケーキのうちのモデルについては、オブジェクト指向の素晴らしさの最高の砦として扱っています。オブジェクトにちょうど良い名前を見つけ、凝集度を高め、結合度を減らすことがドメインモデリングの面白さです。ビューとは全く違うレイヤーなので、私たちは別のアプローチをとっています。

しかし、ここでも私たちはシングルパラダイムのドグマを支持していません。Railsのconcerns、Rubyのミックスインの特殊版は、個々のモデルに非常に広い拡張を与えるためによく使われています。これは、関係するメソッドが相互作用するデータやストレージに直接アクセスできるようにすることで、アクティブレコードパターンによく合っています。

Active Recordフレームワークの基礎でさえも、一部の純粋主義者を怒らせています。私たちは、データベースと直接連動するために必要なロジックを、ビジネスドメインのロジックと混ぜてしまっています。なんという境界の侵犯! その通りですね。これは、ドメインモデルの状態を維持するために、事実上常に何らかのデータベースとつながっているウェブアプリを実現するための実用的な方法であることが明らかになったためです。

思想的に柔軟であることが、Railsがこのような幅広い問題に取り組むことを可能にしています。ほとんどの個別のパラダイムは、問題空間のある範囲内では非常にうまく機能しますが、自然な範囲を超えて適用されると、厄介なものになったり、硬直化したりします。たくさんの重複するパラダイムを適用することで、私たちは側面をカバーし、後方をガードします。最終的にできるフレームワークは、個々のパラダイムが許容していたであろうよりもはるかに強力で、より有能なものになります。

さて、プログラミングについての多くのパラダイムとこのような多元的な関係を持つことの代償は、概念的なオーバーヘッドです。オブジェクト指向プログラミングを知っているだけではRailsを楽しむことはできません。手続き的な経験や関数的な経験も十分に積んでいる方が望ましいのです。

これはRailsの多くのサブ言語にも当てはまります。私たちは、例えばビューのためのJavaScriptや、時折複雑なクエリのためのSQLを学ばなければならないことから、あなたを遮ろうとはしていません。少なくとも、可能性のピークに達するまでは。

学習の負担を軽減する方法としては、フレームワークのあらゆる側面を理解する前に、簡単に始められるようにすることが挙げられます。怒涛のハローワールドが用意されているのはこのためです。あなたのためのテーブルはすでに準備されていて、前菜が並べられています。

本当の価値のあるものを早い段階で提供することで、Railsの実践者に早くレベルアップしてもらおうという考えです。彼らの学習の旅を障害ではなく、楽しめるものとして受け止めてください。

美しいコードの称賛 Exalt beautiful code

私たちは、コンピュータや他のプログラマーに理解されるためだけにコードを書くのではなく、あたたかな美しさの光を浴びるためにコードを書きます。美的に優れたコードはそれ自体が価値であり、精力的に追求されるべきものです。だからといって、美しいコードが常に他の懸念事項に勝るというわけではありませんが、優先順位のテーブルに完全に座るべきです。

では、美しいコードとは何でしょうか? Rubyではたいていの場合、ネイティブのRubyイディオムと各ドメイン固有言語の力との間のどこかにあります。これは曖昧な基準ですが、取り組んでみる価値は十分にあります。

以下はActive Recordの簡単な例です。

  class Project < ApplicationRecord
    belongs_to :account
    has_many :participants, class_name: 'Person'
    validates_presence_of :name
  end

これは DSL のように見えますが、実際にはただのクラス定義で、シンボルとオプションを取る 3 つのクラスメソッドを呼び出しています。派手なものは何もありません。しかし、確かに見事です。確かにシンプルです。この数少ない宣言から、膨大な量のパワーと柔軟性を得ることができます。

美しさの一部は、これらの呼び出しが以前の原則を尊重していることから来ています。 belongs_to :account を呼び出すとき、外部キーは account_id と呼ばれ、それが projects テーブルにあることを前提としています。participantsアソシエーションの役割の指定としてclass_namePersonを必要とする場合、そのクラス名の定義を必要とするだけです。そこから我々は、再び、外部キーと他の設定ポイントを導出します。

データベースマイグレーションシステムからの別の例を見てみましょう。

    class CreateAccounts < ActiveRecord::Migration
      def change
        create_table :accounts do |t|
          t.integer :queenbee_id
          t.timestamps
        end
      end
    end

これがフレームワークの力の本質です。プログラマは特定の規約に従ってクラスを宣言します。例えば、#changeを実装したActiveRecord::Migrationのサブクラスのように、フレームワークはその周りのすべての下回りをつなげ、これが呼び出すべきメソッドであることを知ることができます。

こうして、プログラマの書くべきコードは非常に少なくなります。マイグレーションの場合、rails db:migrateを呼び出してデータベースをアップグレードして新しいテーブルを追加するだけでなく、別の呼び出しでこのテーブルを削除することもできます。これは、プログラマーが同様のことを実現するために、自分自身で呼び出すライブラリを使ってワークフローをつなぎ合わせるのとは大きく異なります。

しかし、美しいコードはもっと些細な場合もあります。何かを可能な限り短くしたり、強力にしたりすることよりも、宣言のリズムが流れるようにすることの方が重要なのです。

以下の2つの文も同じことを行います。


    if people.include? person
      

    if person.in? people

しかし、フローとフォーカスは微妙に異なっています。最初の文では、焦点はコレクションにあります。それが主語です。2つ目の文では、主語は明らかに人です。2つのステートメントの間には長さの差はあまりありませんが、条件がその人についてのものである場所で使われると、2つ目のステートメントの方がはるかに美しく、私を笑顔にしてくれる可能性が高いと主張します。

鋭利なナイフの提供 Provide sharp knives

Rubyは機能の引き出しの中に鋭いナイフをたくさん含んでいます。それは偶然そうなったのではなく、そのように設計されたためです。最も有名なのはモンキーパッチング、既存のクラスやメソッドを変更するものです。

この力は、普通の人間であるプログラマーには扱えないと揶揄されてきました。より制限の多い環境から来た人たちは、言語の利用者にこういった機能を与えるような絶大な信頼は、Rubyを破滅させる様々な災難を引き起こすことを想像していました。

もし何でも変更できるのであれば、String#capitalize を上書きして "something bold".capitalize"Something bold" ではなく "Something Bold" を返すようにすることを止める仕組みがあるでしょうか? このような変更はローカルアプリケーションではうまくいくかもしれませんが、元の実装に依存する様々な補助コードを壊してしまうことになります。

「何もない」、というのが答えです。あなたが鋭いナイフを使うのを理性によって止めさせるための、プログラム的な仕掛けはRubyにはありません。私たちはそのような良識を、慣習によって、ナッジによって、そして教育によって強制しています。キッチンで鋭いナイフを使うことを禁止し、トマトを切るのにもスプーンを使うことを強制したりするのではありません。

なぜなら、モンキーパッチの裏側にあるのは、2.day.previous(現在から2日前の日付を返す)のような驚異的な偉業を成し遂げる力だからです。今、あなたはそれが割りに合わない取引と思うかもしれません。プログラマーがString#capitalizeを上書きするのを防ぐためなら2.days.previousを失うことを望むかもしれません。もしあなたがそのようなスタンスであれば、あなたはRubyには向いていないかもしれません。

しかし、コアクラスやメソッドを変更する力が言語としてのRubyを破滅させたと主張するのは難しいでしょう -- ある程度のセキュリティのためであればそのような自由を手放してしまう人でさえも。それどころか、この言語が繁栄したのは、プログラマーの役割についての異なる急進的な視点を提供したからに他なりません。鋭利なナイフを渡しても信頼するということです。

そして、単に信頼するだけでなく、そのような有能なツールの使い方を教えることができたのです。ほとんどのプログラマーは、指を切らずに鋭いナイフを使いこなすことができる、より優れたプログラマーになりたいと思っているだろうと仮定することで、職業全体を向上させることができるということです。それは信じられないほど野心的な考えであり、他のプログラマーについての多くのプログラマーの直感に反しています。

なぜなら、鋭利なナイフの価値が争われるとき、それは常に他のプログラマーについてのものだからです。私はまだ一人のプログラマが手を挙げて「自分のこの力は信用できないから、この力を奪ってくれ!」と言うのを聞いたことがありません。それはいつも「他のプログラマーがこれを悪用すると思う」というものです。その父権主義的な路線を魅力に感じたことは、私にはありません。

そこでRailsの話になります。フレームワークで提供されるナイフは、言語で提供されるナイフほど鋭くはありませんが、それでも切りたくてたまらない人はたくさんいます。このようなツールをキットの一部として提供することに謝罪はしません。実際には、私たちは、仲間のプログラマーの願望に十分な信頼を持っていることを祝うべきなのです。

Railsの多くの機能は、時間の経過とともに「自由度が高すぎる」として議論されてきました。しかし、現在流行している例として、concerns機能があります。これはRubyの組み込み機能であるモジュールに加えたシンタックスシュガーの薄い層で、1つのクラスで複数の、関連しながらも独立して理解される関心事(concernsの名前の由来です)をカプセル化できるように設計されています。

concernsは、プログラマーがオブジェクトを肥大化させてしまいかねない、ごちゃごちゃしたものを詰め込むための新しい引き出しのセットを提供してしまっている、という批判があります。そして、それは本当です。concernsは確かにそのように使うことができます。

しかし、concernsのような機能を提供しないことは壮大な誤りです。この力を温和な手で使っても、概念の部分的分離を巧みに行うことができれば、プログラマーは素晴らしいアーキテクチャへの道を歩むことになるでしょう。もしあなたが過剰なconcernsからキッチンシンクを守ることを信頼できないのであれば、まばゆい優雅の指針を手に入れることはできないでしょう。

鋭いナイフを振り回すことを学んでいないプログラマーは、まだメレンゲを作ることはできません。ここでは最適な言葉として「まだ」と言っておきます。私は、すべてのプログラマには、権利とまではいかないまでも、完全に有能なRubyとRailsのプログラマになる道があると信じています。そして、有能というのは、コンテキストに応じて、引き出しの中のさまざまな、時に危険なツールをいつ・どのように使うべきかを知っている、という意味です。

だからといって、彼らがそこにたどり着くのを助ける責任を放棄しているわけではありません。言語とフレームワークは、誰もが専門家になれるように手助けし、導く忍耐強いチューターでなければなりません。一方で、そこに至る唯一の信頼性の高いコースは間違いだらけの場所--間違って使用されるツール、血、汗、そしておそらく涙--をうまく通過することを認識しています。他の方法は単にありません。

Ruby on Railsは、シェフになりたい人とシェフになった人のための環境です。最初は皿洗いから始めるかもしれませんが、努力を重ねればキッチンを運営することもできるようになります。その旅の一環として、業界最高のツールを使わせるほどあなたを信頼できないと誰にも言わせないようにしましょう。

統合されたシステムであることを重視 Value integrated systems

Railsは様々な文脈で利用できますが、その初恋は統合システムーー壮大なモノリス! すなわち問題全体に対処できるシステム全体ーーを作ることです。つまり、Railsはライブアップデートを行うために必要なフロントエンドのJavaScriptから、本番でデータベースをどのようにバージョン間で移行するかまで、すべてに関わっているということです。

これまで議論してきたように、これは非常に広い範囲ですが、一人の人間が理解するのが現実的ではないというほどではありません。Railsは特に、ジェネラリストの個人がこれらの完全なシステムを作れるようにすることを目指しています。その目的は、専門家を小さなニッチ分野に隔離し、永続的な価値を持つものを構築するためにそのような完全なチームを必要とすることではありません。

このように個人に力を与えることに焦点を当てているのが、統合されたシステムなのです。統合システムでは、たくさんの不必要な抽象化を削減し、レイヤー間の重複を減らし(サーバーとクライアントの両方のテンプレートのような)、何よりも、どうしても必要になるまでは、システムを分散することを避けることができます。

システム開発における複雑さの多くは、AとBの間の呼び出し方法を制限する新しい境界を導入することに由来します。オブジェクト間のメソッド呼び出しは、マイクロサービス間のリモートプロシージャコールよりもはるかに単純です。分散の巣穴に足を踏み入れた人たちを待ち受けるのは、失敗状態や待ち時間の問題、依存関係の更新スケジュールなど、まったく新しい世界の苦痛です。

この分散が必要な場合も時にはあります。他の人がHTTPで呼び出せるようなAPIをWebアプリケーションに作りたいのであれば、それを我慢してこれらの問題の多くに対処しなければなりません(リクエストをアウトバウンドで送るよりもインバウンドで処理する方がはるかに簡単ですが、あなたのダウンタイムは他の誰かの障害状態です!)。しかし、これは少なくとも、あなた自身の個人的な開発経験に与えられた、限定的なダメージです。

もっとひどいことは、システムが早まって分散化されてしまい、サービスや、あるいはマイクロサービスに分断されてしまうことです。このような状況は、モダンなインターネットアプリケーションを作りたければ、単に何度もシステムを構築しなければならないという誤解から始まっていることも多くあります。サーバ側で一度、JavaScriptクライアント側で一度、ネイティブモバイルアプリケーションのそれぞれで一度、などです。これは自然の法則に則ったことではなく、そうである必要はありません。

アプリケーション全体の大きな塊を複数のアプリやアクセスにまたがって共有することは完全に可能です。ネイティブモバイルアプリに埋め込まれたものと同じコントローラとビューのしくみをデスクトップウェブで使用することも同様です。壮大で見事なモノリスこと統合システムの中に、可能な限りのことを集中させることができるのです。

これはすべて、スピード、ユーザーエクスペリエンスなど、開発者を早まった分散化に誘導しがちな点については何も妥協することなく実現されています。

これこそが、私たちが求める「ほとんどすべてのものを備え持つ」ことなのです。使いやすく理解しやすい統合された単一のシステムによる、個別にチューニングされた分散アプリケーションの力です。

安定性よりも進歩 Progress over stability

Railsのように10年以上前から存在しているシステムでは、自然と硬直化に向かう傾向があります。どんな変更でも、過去の挙動に依存していた誰かにとって、問題になる可能性はいくらでもありえます。そして、実際にそれが当てはまる当人にとっては公平な理由です。

しかし、あまり保守的な声に耳を傾けすぎてしまうと、その反対側に何があるかが見えなくなってしまいます。私たちは、進化と成長のために、時にはあえて壊したり、やり方を変えたりしなければなりません。この進化こそが、これからの(数?)十年にわたってRailsが生存と繁栄に適した状態を維持することになるのです。

これは論理的には理解しやすいですが、これを受け入れて実践するのははるかに難しいことです。特に、Railsのメジャーバージョンでの下位互換性のない変更が原因で、自分のアプリケーションが壊れてしまった場合はなおさらです。そのようなときこそ、私たちは安定性よりも進歩を大切にし、壊れたものをデバッグして、それを解明し、時代とともに歩んでいく強さを与えてくれる、この価値を覚えておく必要があるのです。

これは、必要のない、あるいは過剰なダメージをいたずらに与えてもよいということではありません。2.xから3への大規模なRailsの移行は、その当時の関係者の多くに傷跡として今でも残っています。実に大変なことでした。深刻な大変動により、多くの人たちが3へ移行できず2.xに長い間取り残され、納得できないほど不快な思いをしました。しかし、大局的には、やはり実行する価値のあることでした。

これは、私たちがこれからも続けていかなければならない厳しい交渉です。今日行った変更によって、5年後のRailsはより良い状態になっているでしょうか? ジョブキューやWebSocketsのような別の問題領域を採用したほうが、数年後のRailsの利益になるのでしょうか? もしそうだとしたら、それを取り入れて作業しようではありませんか。

この作業はRails自体だけでなく、より大きなRubyコミュニティでも行われる必要があります。Railsは、Rubyコミュニティの人々がより新しいバージョンを採用するように促すことで、Rubyの進歩を支援する最前線に立つべきです。

これまでのところ、私たちはこの点では非常によくやっています。私が始めたときから、Ruby 1.6、1.8、1.9、2.0、2.1、2.2、2.3、2.4、2.5、そして現在は2.6へと移行してきました。この間、多くの大きな変更がありましたが、RailsはRubyの後ろ盾となり、誰もがより速くプログラムを利用できるようにするために存在していました。これは、RailsがRubyの主要な普及者としての特権と義務の一部です。

これは補助ツールチェーンにも当てはまります。Bundlerはかつて物議をかもしたアイデアでしたが、未来を共有するための礎となるものだとRailsが主張したことで、今日では当たり前のように使われるようになりました。アセットパイプラインや、永続的なコマンドプロセスであるSpringなどについても同じことが言えます。これら3つはいずれも、成長の痛みを経験したか、あるいは今も経験していますが、長期的に見て価値があることが明らかであるため、私たちはそれを押し通してきました。

進歩とは、最終的にはほとんどの場合、変化を推し進めようとする人々と、その意欲にかかっているのです。Rails CoreRails Committersのようなグループに終身の席がないのはこのためです。どちらのグループも、フレームワークの進歩に積極的に取り組んでいる人たちのためのものです。ある人にとっては、そのような進歩への関与はわずか数年で終わり、私たちは彼らのサービスに永遠に感謝するでしょうが、他の人にとっては何十年も続くかもしれません。

同様に、このことはコミュニティの新しいメンバーを歓迎し、奨励し続けることが非常に重要な理由でもあります。私たちは、より良い進歩を遂げるために、新鮮な血と新鮮なアイデアを必要としています。

大きな傘を広げる Push up a big tent

多くの物議を醸すアイデアを持つRailsは、すべての人に常にすべての信条を完全に尊重することを求めれば、すぐに偏った思想の隠者による孤立した集団になる可能性があります。だから私たちはそうしません!

私たちには意見の相違が必要です。方言が必要です。思想や人物の多様性が必要です。このアイデアのるつぼの中にこそ最高の共有物があるのです。多くの人々が、コードや考察に基づく議論を通じて、協力しています。

このように、このドクトリンでは理想化された形を説明していますが、日常の現実はもっと繊細な(そして興味深い)ものです。Railsがこのような大規模なコミュニティを一つの傘のもとで支えることができるのは、リトマス試験がない(あったとしてもほとんどない)からです。

私がしばしば重大な不満を表明してきたテスト用DSLであるRSpecの継続的な成功は、完璧な証拠です。私はなぜこれではいけないと思うのか、顔を真っ赤にしてわめき散らすことができますが、にも関わらずRSpecは依然として花を咲かせ、繁栄することができます。その点の方が遥かに重要なのです!

APIとしてのRailsの到来についても同じことが言えます。私の個人的な焦点とこだわりは、ビューを含む統合システムにありますが、クライアントとサーバを分割したいと考えている人にも、Railsがうまくいく余地があることは間違いありません。私たちはこれを二次的なミッションとして共存できる限り受け入れるべきであり、それは確実に可能だと信じています。

大きな傘を広げるということは、すべての人に万能であろうとすることではありません。すべての人を歓迎し、自分の飲み物を持ってくることを許可するということです。他の人にも参加してもらうことで、私たちの魂や価値観を失う必要はありませんし、おいしい飲み物の新しい混ぜ方も学べるかもしれません。

これはタダではできません。歓迎するための努力が必要です。特に、あなたの目標が、すでにコミュニティの一部になっている人たちと同じような人たちをより多く集めることだけではないのであれば、なおさらです。参入障壁を下げることは、常に真剣に取り組むべき仕事です。

ドキュメントのスペルミスの修正を始めた人が、次の素晴らしい機能を実装することにいつなるかは誰にもわかりません。しかし、あなたが微笑んで、どんな小さな貢献にも感謝を示すことで、モチベーションを高めさせ、その可能性も生まれるかもしれません。

Register as a new user and use Qiita more conveniently

  1. You can follow users and tags
  2. you can stock useful information
  3. You can make editorial suggestions for articles
What you can do with signing up
104
Help us understand the problem. What are the problem?