このいくつかの宣言から計り知れない力と柔軟性を感じます。美しさの一部は、これらの呼び出しが、前述の「設定より規約」のような原則を守っていることに起因しています。:accountを呼び出すとき、私たちは、外部キーの名前がaccount_idであり、それがprojectsテーブルにあると仮定しています。participantsに関連付けされるclass_nameにPersonを指定する必要がある場合でも、そのクラス名の定義さえあればいいのです。そこから、外部キー及びその他の設定ポイントが再び導き出されます。次に、データベースのマイグレーションシステムから別の例を示します。:queenbee_idt.timestampsendendendこれが、フレームワークの真骨頂です。プログラマは、一定の規則に従って、#changeを実装しているActiveRecord::Migrationのサブクラスとなるようにクラスを宣言します。すると、フレームワークは、それをひと通り全部調べて、これが呼び出すメソッドだと認識します。このとおり、プログラマは、ほとんどコードを書く必要がありません。マイグレーションの場合には、Railsのdb:migrateを呼び出して、この新しいテーブルを追加してデータベースをアップグレードすることもできますし、反対に、別の呼び出しでこのテーブルを削除することもできます。プログラマがこれを全て実現させ、自分自身で呼び出すライブラリからワークフローをまとめ上げるのとは、随分違います。美しいコードは、あまり目立たないときもあります。できるだけ短くて強力なコードにするより、宣言のフローを繰り返すのです。次の2つのステートメントは同じ操作を行います。peopleしかし、フローとフォーカスが微妙に異なっています。最初のステートメントでは、フォーカスが当たっているのはコレクションで、それが対象です。2番目のステートメントでは、対象は明らかにpersonです。2つのステートメントの長さはそれほど変わりませんが、personに関する条件式の場合は、私は、2番目の方がはるかに美しく、ほほ笑みたくなると強く主張します。統合システムを尊重するRailsはいろいろな状況で使うことができますが、一番気に入っているのは、統合システムを作ることです。問題全体に対処する完全なシステム。これは、Railsが、ライブアップデートを行うために必要なフロントエンドJavaScriptから、稼働環境でデータベースをあるバージョンから別のバージョンに移行する方法まで、全てに関わっていることを意味します。今まで議論してきたように、これは非常に範囲が広いですが、1人の人間が理解しきれないほど広くはありません。具体的に言うと、Railsは、個人のジェネラリストが、こういう完全なシステムを作れるようにしようと努めています。その目的は、スペシャリストを小さなニッチに隔離し、「永続的な価値のあるものを構築するためには、前述のようなジェネラリストだけからなるチームが必要だ」とすることではありません。統合システムに目を向けるのは、個人に能力を与えることに重点を置いているからです。統合システムでは、多くの無駄な抽象化を省き、(サーバとクライアントの両方にあるテンプレートのように)層の間の重複を減らし、何よりもまず、完全に確信が持てるまでシステムを分散させないようにすることができるのです。システム開発における複雑化の多くは、「要素間に新しい境界を導入することによって、AとBの間で通信を行う方法が制限される」といったことに起因します。オブジェクト間のメソッド呼び出しは、マイクロサービス間のリモートプロシージャコールよりも、はるかに簡単です。マイクロサービス間のリモートプロシージャコールは、障害状態、待ち時間の問題、あえて分散の泥沼に入ろうとする者を待ち受ける依存関係の更新スケジュール......などとという、全く新しい苦痛に満ちた世界です。時には、この分散も必要です。他の人がHTTP経由であなたのWebアプリケーションを呼び出すことができるAPIを作成したいのなら、それらの問題に対処しながら、がんばってやるしかありません(インバウンド要求を処理するほうが、アウトバウンド要求を送信するよりもずっと簡単ではありますが、あなたのシステムの停止時間が、誰か他の人の障害状態になるということです)。それは、少なくともあなた自身の個人的な開発経験に限られたダメージです。悪いのは、システムをサービスに分解するのが早すぎる場合です。マイクロサービスの場合は、もっと大変です。この原動力は、しばしば、最新のインターネットアプリケーションがほしい場合には、ひたすら何度も繰り返しシステムを構築する必要があるという誤解から始まっています。サーバ側で一度、JavaScriptMVCのクライアント側で一度、各ネイティブモバイルアプリケーションで一度ずつ、などなど。これは、自然の摂理ではありません。する必要はないのです。複数のアプリケーションとアクセスの間で、アプリケーション全体の大部分を共有することは完全に可能です。ネイティブモバイルアプリケーションに埋め込まれたのと同じコントローラとビューをデスクトップのWeb用に使用することも可能です。華麗で壮大なモノリス、つまり統合システムの中では、できる限り一元化することも可能なのです。それどころか、速度も、ユーザエクスペリエンスも、またはその他の属性(開発者に不当に早すぎる分散をさせようとするようなもの)も、あきらめる必要はありません。私たちが求めているものをほぼ全て兼ね備えたもの。それが、1つの統合システムとしての使いやすさと分かりやすさを備え、個別にチューニングされ分散されたアプリケーションの力なのです。安定性より進歩を重視するRailsのように10年以上も活用されているシステムは、自然と固定化していく傾向にあります。以前の振る舞いを頼りにしていた人、頼りにしていた場では、どんな変更でも問題になる可能性があるのは当然です。その理由も、各自にとってはもっともなものです。いえ、保守的な意見に耳を傾け過ぎていると、逆の立場が見えなくなってしまいます。進化と発展のためには、時には思い切って慣習を破り、変化を取り入れる必要があります。その進化があってこそ、Railsはこれまでの(そしてこれからの?)10年も存続し普及してくることができたのです。これは理屈として理解するのは非常に簡単ですが、実際問題として受け入れるのはかなり難しいことです。Railsのメジャーバージョンで後方互換性のない変更があったために、自分のアプリケーションが使えなくなった場合はなおさらです。そのような時には、安定性より進歩を重視するという価値を思い出す必要があります。欠陥をデバッグして解決し、時代と共に前進する勇気を持つためです。いやおうなしに不必要な打撃や過度の打撃を負わせても仕方ない、という意味ではありません。3への大移行に携わった人は、その時の傷痕がいまだに消えずにいます。2.xの世界に長い間多くの人を置き去りにした大変革で、納得以上に失望を感じた人もいました。大局的に見れば、やはり価値のあることでした。これは、私たちが続けていかなくてはならない厳しい取引です。答えがイエスなら、早速真剣に取り掛かりましょう。上記の作業はRails自体だけでなく、さらに大きなRubyのコミュニティにも発生するものです。Railsは、構成要素にRubyの新しいバージョンを素早く採用することで、Rubyの発展のために先頭を切って貢献するべきです。この点について、今まで私たちは非常によく対応してきました。2.3となっています。その間、大きな変更はたくさんありましたが、RailsはRubyの後ろ盾のもとに存在し、人々がプログラムをより早く理解するのに役立っています。それは、Rubyの主な普及役を務めてきたRailsの特権と責務の一部です。このことは、関連する補助的ツールにも当てはまります。Bundlerの概念はかつて物議をかもしましたが、Bundlerは共通の未来にとって不可欠なものであるとRailsが主張したことで、今では当然のツールとなっています。同じことはアセットパイプラインや、永続的なコマンドプロセスを提供するSpringにも当てはまります。これら3つでは全て、過去あるいは現在でも苦労の増加を経験していますが、長期的に見て価値のあることは明らかだったからこそ、続けてくることができました。進歩とは結局、変化を推し進めようとする人とその意志によるところが大部分です。Committersなどに無期限のメンバーはおらず、どちらもフレームワークを向上させるために積極的に活動している人たちのためのグループとなっています。中には数年間だけ携わるメンバーもいるでしょうが、私たちはそのような人のサービスもずっと歓迎していきますし、一方では、何十年にわたり継続する人もいるかもしれません。コミュニティの新メンバーを歓迎し促すことが大変重要な理由も、そこにあります。進歩をより良いものにするためには、新しい風と新しいアイデアが必要なのです。テントを押し上げるRailsには異論のあるアイデアがたくさん取り入れられているので、もしあらゆる考え方に対して完全に従うよう常に皆さんに求めていたら、Railsは思想的な隠者が集まるグループとしてすぐに孤立してしまうでしょう。それはありません!私たちには、意見の違いが必要です。多様な思考、多様な人々が必要です。このアイデアのるつぼこそ、誰もが共有できる最良の場所となるでしょう。コードや進行中の議論に対して、たくさんの人が自分の意見を出せるような場です。そんなわけで、この基本原則は理想形を示していますが、日々の現実はもっとニュアンス豊か(で興味深いもの)になっています。Railsが1つのテントの下にこれほど大きなコミュニティを抱えることができるのもまさに、リトマス試験の類がたとえあったとしても非常に少ないからです。テスト用のDSLであるRSpecに対して私は何度も大きな不満を表明しているのですが、このRSpecが成功を続けていることが何よりの証拠です。私は自分がRSpecに反対する理由についてとことん主張でき、一方でRSpecは今もなお成功し発展することができます。その事実の方がずっと重要なのです。同じことは、RailsがAPIとして使われるようになったことにも当てはまります。私が個人的に注目し力を入れているのはビューを含む統合システムですが、クライアントとサーバを前もって分散したいと考える人にとってRailsが役立つ余地も間違いなくあります。この点については、副次的な用途として共存できる限りは受け入れるべきで、それはきっと可能だと思っています。大きなテントを張るというのは、みんなに気に入られようとすることではありません。パーティーに来る人は誰でも歓迎し、飲み物も持参OKにするというだけなのです。他の人たちの参加を促すからといって、私たちの精神や価値観は何一つ損なわれてはいけませんが、今まではなかったおいしい飲み物をちょっと加える方法が学べる可能性は十分あります。これは代償なしに実現できることではありません。歓迎的な環境を保つ努力が必要です。コミュニティの既存メンバーと同じような人をさらに集めることだけが目的でない場合は、なおさらです。敷居を低くすることは、私たちが常に真剣に考えるべき仕事です。隣で単にドキュメントのミススペリングの校正を始めようとしている人が、いつ次の素晴らしい機能を実装することになるかは分かりません。どんなささやかな貢献に対しても喜んで感謝を伝えていくことで、モチベーションにつながり、その瞬間に立ち会えるチャンスが得られるようになるのです。ツイート翻訳に対するフィードバックがございましたら、メールまたはGitHubのIssueよりお寄せください。Ltd.リクルートグループサイトへ。