なぜRuptaを公開したのか
Ruptaという名前のRubyライブラリをGitHubで公開しました。
Ruptaは、いわゆるWebアプリケーション用のルータライブラリです。ライブラリと名乗るのもおこがましい代物ですが、そうと知りながら公開したのには理由があります。
- フロー状態を体験したかった
- ライブラリの作成・公開を通して様々な知識を身につけたかった
- ルータの一般的な実装に疑問があった
それぞれ詳しく説明します。
フロー状態を体験したかった
私の当面の目標は、Webアプリケーションフレームワークを自作することです。もちろんその先には、自作フレームワークでWebアプリケーションを構築するという目標があります。そのためには既存のフレームワークを使う手もあるのですが、私のやりたいことは少し変わっている（RESTfulかつ非同期なアーキテクチャ）ので、既存のフレームワークを拡張するより自作したほうが満足な結果が得られるのではないかと思っているわけです。
とはいえフレームワークの自作は、私にとってはかなりの努力を要するもので、遅々として進まない状態が続いていました。
そんなときに読んだのが下記の記事です。
−−まったく興味のない、関わろうとしない分野のことに対しては、フローは起きづらいということですね。では、好奇心が掻き立てられ、積極的に関わろうとする分野において、フロー状態が生まれるのはどのようなときでしょう。ある行為について「環境との相互関係」が始まるのには、何が大切なのでしょうか？
浅川：“ 挑戦のレベル”が鍵となります。スポーツでも仕事でも、「何かをしよう」としたとき、その活動に必要とされる能力といま自分のもっている能力が釣り合っていることが、フローを経験するためには必要です。挑戦する内容が難しすぎれば不安になり、簡単すぎると退屈に感じますから。
さらに、“目標の明確さ”も重要です。活動を始めたのはいいけれど、何をすべきかが明確にわかっていなければ、その活動は続きません。また、本当に自分がうまくやれているのかを知ることができなければ、その活動に対する興味も薄れていきます。ですから、自分の行為に対する瞬時のフィードバックも重要となります。
たとえば、テレビゲームがフロー状態を導きやすいのは、初心者でも自分に合ったレベルから始めることができるからです。
「充実感」を感じやすい人、できない人：日経ビジネスオンライン
Webアプリケーションの自作は、私には挑戦レベルが高すぎ、それもあって「本当に自分がうまくやれているのかを知ることができ」ない状態が続いていたのだ、と気づいたわけです。
そこで挑戦レベルを引き下げよう、すなわちフレームワークの構成要素をライブラリとしてひとつひとつ実装していこう、と発想を切り替えました。そして数ある構成要素のうち、もっとも簡単そうだったルータを選んだ次第です。
私は、いい大人になってからはあまり夜更かしをしなくなったのですが、この週末は深夜までRuptaの公開に没頭してしまいました。フロー状態の定義は「自己の没入感覚をともなう楽しい経験」だそうなので、挑戦レベル引き下げの試みはうまくいったようです。
ライブラリの作成・公開を通して様々な知識を身につけたかった
私は仕事ではPHPを使っており、特に成果物を公開しているわけでもありません。Rubyやライブラリ公開にまつわる知識は、プライベートな時間に身につけるしかないのです。
Ruptaの作成・公開を通して、Ruby、RubyGems、RSpec、RDoc、英語、OSSのライセンス、Git、GitHubの知識が、つまみ食い程度とはいえ得られました。これも狙い通りです。
ルータの一般的な実装に疑問があった
一般的なルータの実装は、リクエストされたURIをパースして、実際の処理を行うコントローラクラスやアクションメソッドを決めるというものでしょう。
しかしRESTfulなWebアプリケーションでは、コントローラはともかく、アクションはHTTPメソッド抜きには決められないケースがほとんどなのではないでしょうか。
もちろんルータの中には、HTTPメソッドに対応するアクションを返す（GETならgetメソッドが呼ばれるとみなす）ものもあるでしょう。しかしPOSTの場合、リクエストエンティティ中のパラメータに応じてアクションを変えたいケースもありえます。そのすべてをルータが判断するとなると、ルート名／コントローラ名、マッチさせるURI、HTTPメソッド、パラメータ、アクションメソッドをルーティング定義しなければなりません。アクションメソッドの決定はコントローラに任せるべきではないか、というのがRuptaの背景にある考えです。
予告
次回は、Ruptaを作成・公開するにあたって工夫した点や苦労した点について書こうと思っています。
