Skip to content

Instantly share code, notes, and snippets.

@tai2

tai2/railsdm.md

Last active December 7, 2018 07:45
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tai2/f6653c064ceff7f7cdf9e2eacfcab8b8 to your computer and use it in GitHub Desktop.
Save tai2/f6653c064ceff7f7cdf9e2eacfcab8b8 to your computer and use it in GitHub Desktop.
Download ZIP
railsdmメモ
Raw
railsdm.md

Rails Developers Meetup 2018 Day 4 Nouvelle Vague https://techplay.jp/event/702297

聴講者の頭に植え付けたい概念

  • おまかせとアラカルト

台本

「Rails is omakase」っていう言葉は聞いたことありますか? The Rails Doctrine、日本語だと「Railsの基本理念」っていうドキュメントがあって、 そのなかで原則のうちのひとつとして挙げられてるやつです。

このセッションでは、おまかせな環境と、 その反対のアラカルトな環境を対立させます。 それから、このテーマについて考えるための「観点」を10個列挙します。 で、列挙しながら、こいつらを比較していきます。 比較することで、Railsがどういうものなのか、改めて考えてみる、 っていうのがねらいです。

それじゃあ、まずは「メニューはおまかせ」という原則のおさらいです。

DHHはエッセイで次のように表現していました:

料理人のチームが素材を選び、APIを設計し、きみのかわりに食べる順番を決める。
それらは、なにがおいしいフルスタックフレームワークの足しになるかという、かれらの考えにもとづいている。

おまかせな環境では、ユーザーである開発者は、個別にパーツを選択するっていうことがありません。 シェフであるところのライブラリ作者が、かわりに一から十まで決めてくれるからです。

おまかせ環境を使っておけば、「ある意味では」熟練の経験は不要です。 「ある意味で」というのは、熟練の経験が必要なこともあるっていうことですが、これはあとで説明します。

席に座って、シェフが料理を作るのを見ながらですね、口をポカーンと空けて待っていれば、 それだけで、おいしい食事を楽しめてしまうんです。 ただし、シェフの好みが自分の口に合わないということも考えられます。 そういうときは、まー、ちょっと困っちゃいますよね。

ともかく、Railsっていうおまかせメニューを受けいれちゃえば、もうそれだけで、 完全に動作するWebアプリケーションを作ることができちゃいます。

ORマッパー、URLルーティング、テンプレートエンジン、メール送信、ジョブ管理などなどなど、 開発に必要なものは、最初っからぜんぶメニューに入ってるわけですからね。

おまかせのちょうど反対に、アラカルトな環境があります。 アラカルトな環境では、自分で、メニューに載っている料理、 つまり、さまざまなパッケージの一覧を把握して、 その中から自分の好みに合った一品を逐一選んでいきます。

モジュールがどのように作られているかを気にする必要はない。
知らなきゃいけないのは、�レゴの城を作るために、レゴブロックをどう使うかだけだ。

これは、アラカルト派の著名なクリエイターsindresorhusさんの言葉です。

Express.jsというライブラリは聞いたことありますかね? これは、Node.jsで最もポピュラーなWebアプリケーションのためのパッケージです。 これは、典型的なアラカルト環境です。

Express.jsには、

  • ルーティング機能と
  • リクエスト・レスポンスオブジェクト
  • そしてミドルウェアの仕組みが含まれます

ですが、提供する機能はほんとうにそれくらいのものです。 Node.jsランタイム上の非常に薄いレイヤーになっています。 ですから、これだけではちゃんとしたアプリは作れません。

ストレージ層はSequelizeにするのか、mongooseを使うのか、それともRealmを使うのか。 Viewのレンダリングは、Pugなのか、Mustacheなのか、EJSなのか。 ログ出力、メール送信、ジョブ管理なども考えなくちゃいけません。

アラカルト環境では、デフォルトの選択肢がありません。 なので、こういったことを逐一自分で調べ、比較し、選択しなくっちゃいけません。

もちろん、ある程度定番の選択肢は存在します。 しますが、すくなくとも、それが何なのかは調べる必要があります。

一方、Railsはどうでしょう? 公式に乗っかれば、とにもかくにもアプリケーションを作りはじめられます。 アラカルトとはずいぶん違いますね。

さて、ここまでで「おまかせ」と「アラカルト」の基本的な概念はわかりました。 次は、もう少し詳しくこれらを比べていきます。 10個の観点から、どちらに分があるのか考えてみましょう。

Round 1 インテグレーションコスト

最初は、インテグレーションコストです。 コンポーネントを組み合わせて繋げるときの話ですね。

おまかせ方式では、フレームワーク提供者ががんばってくれます。 ユーザーのかわりに、組み合わせたときの動作テストをしてくれます。 また、最初から、組み合わせて使うときのことを考えて設計してくれてるはずです。

仮に、モジュールの組み合わせで起きる問題があるとします。 同じフレームワークのユーザーなら、同じ問題に遭遇する確率が高いです。 なんでかというと、フレームワークのメニューが同じだからです。 だから、問題に対処するのに、多くの人が力を合わせて取り組めます。 いわゆる「目玉の数さえ十分あれば、どんなバグも深刻ではない」というやつです。

他方、アラカルト方式ではどうでしょう。 ライブラリは単体での動作確認はきっとしています。 でも、他のライブラリと組み合わせたときのテストは? していないかもしれません。

ライブラリAとBを使いたいときに、 組み合わせて使うために必要な機能が足らなかったり、 インターフェイスが十分に柔軟でなかったりすることもあります。 そういうときは、ライブラリ側の機能追加や修正が必要になってしまうかもしれません。

また、アラカルトでは、自分と同じ組み合せを選んでいる人はすくないです。 すくなくとも、おまかせほどは多くないでしょう。 問題が、自分だけの組み合わせで発生するなら、自力でなんとかして解決するしかありません。

したがって、定義からほとんど自明なことではありますが、 インテグレーションコストでは、おまかせが上なんじゃないでしょうか。

Round 2 アプリ設計の自由度

次は、アプリ設計の自由度についてです。

Railsにおけるおまかせの概念では、必要な部品をすべて提供します。 同時に、オプションで、他の部品に置き換えることも許しています。

たとえば、自動テストを書くときに、デフォルトのminitestを使わず、rspecを使っている人は多いと思います。 ERBを使わずにHAMLを使う人、 Active Jobを使わずにSidekiqのAPIを直接使う人、 Acitve Storageを使わずに他のファイルアップローダーを使っている人などもいるでしょう。

Active Recordでさえ必須というわけではないです。 trailblazerを使ってアーキテクチャそのものを変形させることさえできてしまいます。 こういったことはすべて、各コンポーネントの独立性がきっちりと保たれているからこそです。

では、Railsのおまかせは、アラカルトと同じくらい自由なのでしょうか? おまかせには、さながら新体操の金メダリストのような柔軟性が、あると言えるのでしょうか。

Railsの設計がどれだけ柔軟でも、変えられない部分もあると思います。 たとえば、CoCっていう根本的な概念は変えられません。 仮にActive Recordのみ取り出してSinatraから使ったとします。 それはもはやRailsと言えるのでしょうか。きっと言えないでしょう。
内包されるコンポーネントが組み合わさってこそのRailsなのです。

アラカルトでは、どのようにレゴブロックを組み合わて、どのように繋げるのか。 また、ブロックのない部分を自分のコードでどのように埋め合わせるのか。 こういったことをトップダウンで縛りつけるような圧力がありません。

というわけで、アプリ設計の自由度はアラカルトの勝ちです。

Round 3 要求されるスキル

3番目の話題は、要求されるスキルです。

おまかせでは、シェフがユーザーの代わりにメニューを考えてくれます。 ということは、おまかせなら、ユーザーのスキルが低くても使えるっていうことなんでしょうか? たしかに、Railsの基本理念において、そのようなことがほのめかされています。 いわく、自信を持ってツールを選択するのは大変なことであり、 おまかせはユーザーがエキスパートであることを要求しない、だそうです。

ですが、同時に、正反対のことも述べられています。 Railsは、研ぎ澄まされたナイフを意図的に提供するものである、と書かれているんです。 怖いですねえ、恐しいですねえ。

それは、ともすれば、自分自信の身体をも傷つけかねないナイフです。 こういったものの代表例として、モンキーパッチや、Concernが挙げられます。 モンキーパッチの危険性は言うまでもないですし、Concernはモデルの肥大化を招きます。 私見ですが、Concernは可読性を著しく下げてしまうので、あまり使いたくありません。

しかし、プログラマーは、こういう難しい道具の使いかたを身につけられるはずだ、 って言うんですよ、Railsは。

Railsは、単なるお客さんのためのものではないんです。 シェフや、すくなくともシェフになろうとしている人のための道具なのです。

おまかせは、あくまでもメニューを用意してくれるだけです。 スキルが低くても正しく使える、ということとはあまり関係がないとぼくは思います。

アラカルト環境では、自分で選択肢を比較検討できる十分なスキルが必要になります。 ただ、公式メニューがなくても、他の誰かが考えてくれたフルコースの記事とか、サンプルコードだとかは手に入ります。 非公式なレシピでカバーすることは十分に可能だと思います。

要求されるスキルについては、おまかせだから要求スキルが低いとも、その逆とも言えないと思います。 Railsみたいに、メニュー自体が高いスキルを要求するっていうこともあるわけですからね。 ということで、ここは引き分けです。

Raound 4 知識・ノウハウの伝搬

次の観点は、知識・ノウハウの伝搬です。

多くの人が同じものを使うことが、おまかせのメリットのひとつです。 共通の知識や経験を持った人がたくさんいると、プロジェクトに良い効果があります。 運営する側にとっては、参加してくれるメンバーを探しやすくなりますし、 個々の開発者にとっては、参加するハードルを引き下げてくれます。 開発ノウハウなども、得られやすくなると期待できますし、 問題に遭遇したときには、多くの人と共有できます。

一方、アラカルトでは、環境は共有されるものというよりは、個人のものという側面が強いです。 だから、知識が分散して、みんなで力を合わせづらくなります。 問題が自分固有のものになってしまう可能性は、相対的に高いと言えるでしょう。

そう考えると、知識・ノウハウの伝搬は、おまかせのほうがうまくいきそうです。

Raound 5 バージョンアップのしやすさ

5番目は、バージョンアップのしやすさについて。

おまかせソフトウェアは、リリースのタイミングを全体で統一しているものが多いです。

Railsは、コンポーネントが独立していて、個別にパッケージ化されています。 Railsのようになっていれば、リリースを全体で統一する必然性は、ないようにも思えます。 ですが、ともかく統一されているものが大半のようです。

たとえば、PythonのフルスタックフレームワークであるDjangoでは、全体が一つの配布単位になっています。 これは、Railsとは異なる点です。

本質的に巨大である以上、リリースのコストが大きくなります。 個々の機能単位で実装が完了しただけではダメです。 全体で歩調を合わせる必要があります。 ですから、完成している機能をユーザーに届けられるタイミングが遅くなります。

一方、アラカルトではどうでしょうか? 個々の小さなコンポーネントレベルでテストが完了すれば、即リリースできます。 リリースサイクルを小さくしやすいと言えるでしょう。

以上は提供する側の視点ですが、逆に、ユーザー側に立ってみても同じことが言えます。 おまかせはリリース単位が大きいので、アプリがバージョンアップに追従するのも、必然的にたいへんになります。 アラカルトであれば、コンポーネントごとに、インクリメンタルにバージョンアップと検証をしていくことも容易でしょう。

ですから、バージョンアップのしやすさについては、アラカルトの勝ちです。

Round 6 陳腐化への耐性

次のトピックは、陳腐化への耐性です。

アラカルトの特徴として、個々のパーツがダメになったとしても、開発を続けやすいという議論があります。 ダメになったパーツだけ置き換えれば開発を継続できるからです。 もし、利用しているテンプレートエンジンの開発が、ある日突然止まってしまったら? そういう場合でも、別のテンプレートエンジンに差し替えればいいので、ダメージが軽くて済む、というロジックです。

おまかせ環境の場合、ひとつのライブラリへの依存度が極めて大きくなります。 もしそれが陳腐化してしまったら、アプリケーションが取れる選択肢は限られています。

たとえば、Seasar2という一時期国内でかなりの人気を誇ったWebフレームワークがあります。 ですが、残念ながら、2016年に終わりを迎えました。 当時を振り返って、それがいつか終わるとは思いもしなかった、という声もあります。

これは、フレームワークというものと切っても切り離せないリスクだと思います。 おまかせ環境を選択するということは、その環境と運命を共にすることであると言っても、過言ではありません。

陳腐化への耐性という点では、アラカルトのほうがマシなように思えます。

Round 7 コミュニティー

次はコミュニティーという観点から見てみます。

いまどきの開発において、コミュニティーの存在は切っても切り離せません。 それは、おまかせであれ、アラカルトであれ同じです。

ですが、コミュニティーの育て易さ、コミュニティーが協調する力では、 おまかせに若干の分があるのではないでしょうか。 提供する機能が多いほど、ユーザーを獲得しやすくなると考えられるからです。

アラカルトにおいても、たとえばExpressコミュニティー、Reactコミュニティーといったものは存在します。 ですが、Railsコミュニティーほどに集中した力はないのではないでしょうか。

アラカルトは、コミュニティーといっても、最低限の共通基盤しか持ちません。 他のコンポーネントも組み合わせて使っている、雑多なユーザーのあつまりです。 個々のユーザーが使っているものはバラバラです。 つまり、コミュニティーのリソースは、相対的に分断されていると言えるでしょう。

すこし視点をずらして見てみましょう。 いくつかの仮定をしてみます。 開発者の人数と、個々の開発者が貢献できる時間は固定とします。 つまり全体としての開発リソースは固定です。 ですから、各種プロジェクトは有限のリソースを奪いあっている状況になります。

ここで、2つの状況を考えます。 ひとつは、おまかせ環境で、多くのユーザーがだいたい似たようなコンポーネントを使っている状況。 もう一つは、アラカルト環境で、どのユーザーもバラバラのコンポーネントを使っている状況。 これらを比べると、どうでしょう。 開発者のリソースが集中しやすいのはおまかせ環境になるはずです。 ある意味では、開発者のリソースを効率的に活用しているとも言えます。

ユーザーに選択を強制しないのがおまかせです。 そこでは、多くの人が同じものを使っていると想定するのは自然なことです。 選択が強制されるなら、必然的に多様性は高まり、逆に、集中の力は弱まるでしょう。

コミュニティーの力を強めるという点では、おまかせに分があると言えるのではないでしょうか。

Round 8 ライブラリ開発コスト

次のトピックです。 今度は利用者ではなく、それを開発する側に立って、開発コストという面から見てみます。

インテグレーションコストで話したことや、 バージョンアップのしやすさで話したこととも関係しますが、 開発の大変さはおまかせのほうが上でしょう。

提供する機能がたくさんあるのだから、あたりまえです。 それら個々の機能が互いに連携しあうのであれば、なおさらです。

あるおまかせ環境にコンポーネントXとYがあるとします。 そして、XはYに依存しているとします。 この場合、Yに破壊的変更を加えれば、Xにも修正を加えてテストを行う必要があります。 連携したときに、全体としてうまく動くのかどうかまで、面倒を見なければいけないのです。

対して、アラカルトは気楽なものです。 基本的に、単体でうまくいくかどうかだけを考えればいいわけですから。 さきほどと同様に、XとYがあるとします。 しかし、Yの開発者はXのことを気にせず修正できます。 それはXの開発者が気にすればいいことだからです。

コンポーネントをアプリケーションというひとつのものにインテグレートする苦労は、 利用者側に委ねられているわけです。

また、新規の開発者が参入しやすいのもアラカルトでしょう。 小さいモジュールなら、パッチを送るのが簡単だからです。 フレームワークの全体像を把握したり、波及効果を気にする必要はありません。

開発する側からすれば、気楽に取り組めるのはアラカルトと言えます。

Round 9 ライブラリの見つけやすさ

次は、ライブラリの見つけやすさについてです。

おまかせよりもアラカルトのほうが検索がしやすい、という議論があります。 おおきなパッケージよりも小さなパッケージのほうが検索しやすい、という主張です。

たとえば、キーワード補完を実装したいとします。 そこで、これをサポートしてくれるUIライブラリを探しはじめました。

npmで“autocomplete”というキーワードを検索してみます。 すると、

  • autocomplete
  • downshift
  • algoliasearch
  • match-sorter

などが出てきます。

実は、かの有名なjquery-uiにもautocomplete用のウィジェットが含まれます。 ですが、検索では箸にも棒にもかかりません。 “accordion”というキーワードでも同様です。

jquery-uiは雑多なウィジェットの寄せ集めですが、 欲しい機能から、これに辿りつくのは困難ということです。

パッケージに含まれる機能が多くなるほど、特定のキーワードからそこに辿りつくのは難しくなると言えます。 すべての機能をキーワードで的確に表現するのは、不可能とは言わないまでも、かなりめんどうだからです。

単機能で的を絞ったアラカルトパッケージなら、こうはなりません。 その特徴を限られたキーワードだけで表現することも容易になるでしょう。 したがって、ライブラリの見つけやすさはアラカルトの勝ちです。

Round 10 問題領域の定義

最後は、ライブラリが対象とする、問題領域の定義について。

おまかせ的な巨大なパッケージでは、 どの機能を入れるのか、あるいは入れないのか、という議論が紛糾しがちです。 本質的には独立した機能をたくさん含んでいるからです。

おまかせでは、何が含まれるべきなのか、という問いへの答えが千差万別で、主観的なものになりがちです。 DHHもエッセイの中でそのことには言及しています。 彼は、好みに合わないなら、その部分を差し替えて使うか、黙って立ち去さるべきだ、という立場を明確にしています。

Node.jsにlodashというパッケージがあります。 これは、単に便利関数の寄せ集めです。 ですから、自分のユースケースをサポートして欲しい、というissueがしばしば上がって来ます。 なにがlodashに入るべき関数で、何がそうでないかは明確ではありません。 ちなみにlodashでは、リクエストのうち+1 voteが多いissueを見て、新機能を決めているようです。

解決すべき問題が小さく限定されていれば、そのような問題は起こりづらいでしょう。 問題領域の定義は、アラカルトのほうが容易であると言えます。

まとめ

以上、おまかせ方式とアラカルト方式に関する10個の側面について見てきました。 まとめます。

おまかせが勝ったのは:

  • インテグレーションコスト
  • 知識・ノウハウの伝搬
  • コミュニティー

アラカルトが勝ったのは:

  • アプリ設計の自由度
  • バージョンアップのしやすさ
  • 陳腐化への耐性
  • ライブラリ開発コスト
  • ライブラリの見つけやすさ
  • 問題領域の定義

引き分けは:

  • 要求されるスキル

という結果になりました。

こうして並べてみると、みんなで同じものを使う大きなものと、 個々人が別々のものを使う小さなものの違いが出ているような気がします。

比較する側面

  • インテグレーションコスト ✅
  • アプリ設計の自由度 ✅
  • 要求されるスキル ✅
  • 学習コスト ✅
  • 知識・ノウハウの伝搬 ✅
  • バージョンアップのしやすさ ✅
  • 陳腐化への耐性 ✅
  • コミュニティー ✅
  • ライブラリ開発コスト ✅
  • 検索性 ✅
  • 問題領域の定義 ✅

アウトライン

  • おまかせ(な開発環境)とはなにか
    • 代表例(Rails,Hanami,Meteor,Sails)
    • シェフがメニューを決める
    • 全体としての体験や整合性はある程度保証されている
    • モジュール選択コストが相対的に低い
    • インテグレーションコストを内包している
    • おまかせメニューの開発は大変(開発者視点)
    • 全体の方針には従うしかない(CoCとか)
    • 趣味が合わない部分は差し替えられる(それが可能ならば)
    • シェフが料理をやめたら、食べるものがなくなる
    • 余計なことを考えなくていい
    • 対象ユーザー: 自分で選別できない初心者(ほんとか?) → 自分で選ぶのがめんどくさい人(そんなにはずれてなさそう) → すくなくともrails自体はそんなに初心者向けではないと思う(Sharp knives)
    • 学習コストはそれなりにかかる
    • バージョンアップへの追従は相対的に簡単(性格には「メニュー」のポリシーに依存する)
    • 一度覚えたらある程度長く使える(嘘くさい e.g. PHP)
    • 開発に必要な情報は公式ドキュメントにまとまっている
    • ある程度思考停止できる
    • おまかせメニューはそんたにたくさんあるわけじゃないので、自分に合うものがひとつも見つからないかもしれない
    • おまかせOSSは、必然的に苦情を受けやすい
    • バージョンアップがしずらい(互換性壊れるからしたくないとき、全体が犠牲になる)
    • 気軽に思い付きを試すのが相対的にやりづらい(Push up a big tentを謳っているにも関わらず)
    • パッケージとしてのリリースエンジニアリングに本質的なデメリットがある。おまかせパッケージは全部まとめてリリースしなきゃならない。
    • まかせソフトウェアは肥大化していく運命にある
    • おまかせは異なる開発者の「共通言語」になる → コミュニティーの強化
    • セキュリティーの問題は起こしにくい
    • ファイル数がすくなく済む?
  • アラカルト(な開発環境)とはなにか
    • 代表例(Sinatra,Roda,Express,Koa)
    • 自分でメニューを作る
    • 開発者ごとに異なる体験なので、全体としての総合的な整合性は自分で検証する必要がある
    • モジュール選択コストが相対的に高い
    • インテグレーションコストを自分で払う必要がある
    • アラカルトメニューの開発は簡単(開発者視点)
    • 自分の趣味に合った環境を構築できる
    • 部分的に差し替えていくことができる(それが可能ならば)
    • メニューの料理がなくなったら、その料理を他から調達すれば良い
    • 非本質的なことまで自分で考えて決めなきゃならないこともある
    • 対象ユーザー: ある程度経験積んだ人(ほんとか?) → 自分に合わせて選びたい人
    • 個々のモジュール自体の学習コストは高くないが、全体としては高くなるかもしれない
    • バージョンアップへの追従は相対的にたいへん
    • モジュールの流行り廃りが速く、個々のモジュールの寿命が短い?(嘘くさい)
    • 開発に必要な情報のすべてが公式ドキュメントにまとまっているわけではないので、自分で探す必要がある
    • 細部の意味を考えることをある程度強制する
    • 自分に合うものが比較的見つけやすい。不足している「レゴブロック」は自分で作って埋めてもいい
    • アラカルトOSSは、気に食わなかったら他を探せばいいだけなので、苦情を受けにくい
    • 段階的にバージョンアップしていきやすい(個別にバージョンアップできるので)
    • アラカルトは思い付きをすぐ試すのに向いてる
    • アラカルトは肥大化に抵抗する手段になる
    • アラカルトは開発者間の知識の分断を招く
    • セキュリティーの問題を起こしやすい(event-streamの件やleftpadの件など)
    • ファイル数が多くなる(npmの場合顕著、というかこれはnodeの問題かも)
  • 標準ライブラリというものは、ある意味「おまかせ」
    • なので言語や環境の「性格」が標準ライブラリには現れている
    • この意味でNode.jsはあきらかにミニマリスト・アラカルト指向
    • Ruby,Pythonは節操がない
    • PHPはWebアプリ用の機能が手厚い
  • パッケージマネージャの性質によってアラカルトを支え易さに違いがある
    • npmはbundlerよりもアラカルト向き
    • npmはモジュールごとに依存関係が閉じているので依存解決でconflictが起きない
    • rubyは、モジュールシステムの性質によりアラカルトなモジュールを配布しづらい。単一メソッドのみのモジュールをgemとして気軽にポンポン公開できるような仕組みにはなっていない。
  • アラカルトならclumsy partsを置き換えながら作っていけるというのは本当か?
    • おそらくアラカルトならやりやすくなるが、十分条件ではない
  • npmの依存解決アルゴリズムや、Nodeの標準ライブラリが持つアラカルト指向が、Express.jsというアラカルト指向なライブラリが支配的であることに繋っているのかもしれない
  • ノウアスフィアの開墾とおまかせ指向なライブラリの関係
    • おまかせ指向ライブラリはノウアスフィアにおいて名声を獲得し易い(これはExpressが人気高いことと矛盾しないか?)
    • ノウアスフィアの開拓という意味ではおまかせに分がありそう
  • github,npm時代において「おまかせ」ライブラリはもう不要なのか?
    • ワンストップのパッケージという利便性
    • コミュニティーの集中がもたらすパワー
      • ノウアスフィアにおける評判ゲームでは、おそらく「おまかせ」のほうが有利なので
  • 結論
    • 「おまかせ」か「アラカルト」かは開発者の趣味の問題

メモ

  • 他の考えかた(アラカルト)と対比することで、Railsがどんなものかを浮き彫りにする
  • コミュニティーのリソースは一定でそれをどう配分するかという切り口で考えてみると? → パッケージは、コミュニティーという有限のリソースを奪い合っていると仮定する(思考実験)
  • いかにたくさんの仮説(とできれば検証)を示せるかが重要になりそう
  • おまかせ or アラカルト診断フローチャートとかどう?
  • 小さなモジュールはイノベーションを加速させる → でもRailsでイノベーションが起きていないとは言えない。なぜか → RailsにおいてNodeフロントエンドのような喧騒が起きていないことは確か
  • nodeの標準ライブラリはどのような原則にもとづいて選定されている? → とくに明文化されたものはなさそう。isaacとかsubstackが初期に語っているのはある。
  • Railsのモジュールシステム(おまかせ)の限界について(いくらsubstituionがゆるされると言っても、それができない部分はあるはず)
  • bundlerとnpmのインストールアルゴリズムは概念が違う(npmは階層構造を許す → https://twitter.com/aras_p/status/883292703953387520)
  • nodeの小さなモジュール文化はnpmのアルゴリズムに支えられている(node_modulesの肥大化という代償を払って)
  • Nodeのスモールモジュールを支えているものはなにか、どこから発生しているか → isaacが述べたようなコミュニティーの傾向、nodeの標準ライブラリが小さいこと、npmのinstallおよびrequireアルゴリズム
  • 多様性と力の分散 c.f. 何がLinuxデスクトップを殺したか
  • Railsが支配的なのは、「おまかせ」と何か関係があるか? → 直接的な因果関係はなさそう。あっても間接的な影響でわかりづらい。 → 思うにRailsが支配的で強いのは、dhhという個人のパワーとbasecampによる支えがあるから。
  • Railsがbasecampを持っているがゆえの強さ
  • Nodeのアラカルト指向は、あきらかにコミュニティーのfragmentation(=パワーの低下)に影響している
  • アラカルトなら個々のレゴブロックがダメになってもかんたんに入れ替えられるというのは本当か? → クリーンアーキテクチャならあるいは
  • Railsが有名であるがゆえの貢献しやすさ、貢献することのメリット
  • Ruby界ではRailsが支配的、Node界ではExpressが支配的 → そう考えると、Nodeにアラカルト文化が根付いているから支配的なフレームワークが云々、みたいな話はできなさそう → 「Nodeにアラカルト文化があるからSailsやMeteorではなくExpressが選ばれる」は、論理的には矛盾してない(が、事実かというと…)
  • おまかせなエコシステムなどというものは存在しない。もし存在したら、それはもはやエコシステムではない。
  • Railsがあるせいで、他の試みがまったく出なくなっている、とまでは言えない(多少の影響はあるのかもしれないが)
  • ExpressはNodeの超薄いラッパーで、ほとんど自前機能を持っていない(ミドルウェアシステムの提供という意味が一番大きい)
  • NodeにおいてExpressが支配的なのは、アラカルト文化が根付いているからかどうか
  • Nodeのアラカルト文化がなかったら、フロントエンドのツール乱立は起きなかったか? → なんとも言えない。おそらく関係がない。 → ただ、いろいろなものが次々と出てくるのはNodeの文化として歓迎すべきことではある。 → Nodeがめちゃくちゃモジュールを作ってpublishしやすい環境であることは確か。(Javaなどと比べて)
  • アラカルトは、試行錯誤の回数はたしかに増えるかもしれないが、それをまとめる仕組みがないから、あまり成果を集積できてないのではないか
  • おまかせでないと達成できないことは何か
    • 全体としてのクオリティー・一貫性
  • アラカルトでないと達成できないことは何か
    • 試行錯誤の数
  • 依存こそオープンソースの本質
  • 他人の書いたパッケージを使う(車輪の再発明しない)のは良いというのは、信仰か?
  • なにが「パッケージ」になるべきか、「パッケージ」とは何か → 凝集性
  • 「おまかせ」とは、本来疎結合なものをパッケージングして提供するもの → Active Job、Action Mailer, Action Cableは本来まったく無関係で疎結合な機能 → これらをまとめてRailsという名前でパッケージングする意味とは?
  • 荒木飛呂彦とかホメロスみたいな比喩をたくさん入れたい
  • おまかせはNIH(Not Invented Here)をまねきやすい

キーワード

  • アラカルト(à la carte)ソフトウェアとおまかせソフトウェア
  • 標準ライブラリのポリシー ◯
  • 信頼・信頼の分散 ◯
  • 開発者リソースの集中と分散 ◯
  • 単一性・多様性 ◯
  • 依存地獄 ◯
  • 高凝集・疎結合
  • 論理的凝集と機能的凝集
  • コミュニティーの自発性と自由
  • リバタリアニズム
  • アナーキズム △
  • モジュールの自由市場的混沌 △
  • フロントエンドの混乱とアラカルトなnode文化 △
  • BDFL
  • JavaScriptとpolyfill
  • モノリシックカルチャーと権威の影響力
  • UNIX哲学
  • Ruby標準ライブラリ vs Node.js標準ライブラリ
  • mostly anarchic dictatorship
  • The node/npm ethos
  • コミュニティーへの貢献の大小
  • 所有権と評判によるインセンティブ
  • ESRの評判ゲーム論
  • 名声と承認欲求
  • レゴブロックと大きな城
  • パーキンソンの法則
  • SimpleとEasy ×
  • モジュールの共産主義 ×

引用

  • “swapping out clumsy parts as we go along”
  • “Rails is tailor made for Basecamp.”
  • “easier to break things” by substack
  • “The node/npm ethos is that we should push most all of the decisions about how apis and modules work into userspace so that core can focus on doing a small set of things well.”
  • “Freedom must include the freedom to make mistakes, to disagree, to make requests and hear "no" as an answer, or to say "no" to requests, or else we're doomed.”
  • “Much of the pain in software comes not from the individual components, but from their interaction.”
  • “Rather than write any functions or code, it seems that they prefer to depend on something that someone else has written.”

参考

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment