ロンドン在住のRailsエンジニア、井上真氏が自身の体験を振り返りながら、初中級者向けにRails関連のエッセイ、技術トピックをお届けします。連載第2回目は、体験談を交えたRailsの学び方についてです。
自身でもスタートアップを起こし、その後Y Combinatorという投資会社を作り上げたポール・グラハムは、数々のスタートアップやテクノロジーに関するエッセイで有名です。その彼が「どうやってプログラミングを学べば良いの?」という質問に対し、「Programming FAQ」(日本語訳)という文書で、以下のように勧めています。
Railsに限らず、プログラミングというのは何冊本を読んでもそれだけで上達するものではありません。実際に手を動かしてコードを書く必要があります。いま考えると私もポール・グラハムと似たような手順を踏んでいたのですが、ちょっと独自な部分もあったので色々ご紹介したいと思います。
締め切りとか目標が設定されないとやる気が出ないタイプの方は、とりあえず何か発奮材料を探すのをお勧めします。私の場合はAward on Railsというプログラミング・コンテストが日本で開催されると知り、さっそく申し込んでみることにしました。
残念ながらAward on Railsは2008年以降開催されていないようですが、現在でもいくつかプログラミング・コンテストがあります。
ほかにもITベンダが自社のプロダクトを使ったプログラミング・コンテストや、イベントの間に開催されるハッカソンなどあります。
「でもハッカソンとかプログラミング・コンテストとかって、年中あるものでもないでしょ?」と思われる方もいらっしゃるでしょう。そういう場合は自分で企画してみるのはどうでしょうか?
日本では開発合宿というのが流行っていると聞き、自分でも似たようなことをしたいと思い、2007年にスコットランドで“Code Retreat”というイベントを知人と一緒に企画しました。「Retreat」というのは、本来は「退却」を意味するのですが、この場合は「静養先」と訳すべきでしょうか。「コードを書いて英気を養う」なんて、ギークならではの発想だと思います。
話はAward on Railsにもどります。私の場合はまずチュートリアルで作ったブログシステムのコメント機能をカスタマイズすることから始まりました。その頃は見よう見まね(半分コピー&ペースト)でコードを書き始め、最初の3週間ほどはさくさく開発できました。2〜3日に一度のペースで機能を追加して行き、5月の半ばには6割がた出来上がったと思います。
ただ6割方出来た作品を見ても、いまいち見栄えがしません。「この機能はほかのブログにはない独自機能だろう」と思っていたものが、探してみるとふつうににあることが発覚。またテストとかもせずに一気に作り上げたのと、コピー&ペーストしまくったおかげで、バグがたくさんの、自分でもどうやって動いているか分からないスパゲティ・プログラムになってしまいました。
DRY(Don’t Repeat Yourself)を掲げるRailsを使って、良くもこんな汚いコードが出来上がったと自分でも感心したものです。
そこで、作りかけの作品は捨てて、新たなアイデア(でもコンセプトは同じところからきているのですが)を元に作り始めることにしました。
またイチから始めようと思ったのは良いのですが、自分のスキルの限界も感じ始めていました。そして、コンテストの期限もどんどん迫ってきます。そこで思い付いたのが、一緒にプロジェクトを推進する共同開発者を探すことです。でも、そんな簡単に開発者なんて見つかるものなのでしょうか? 答えはユーザーグループにあります。
Railsを始めたばかりの頃、職場の同僚にその素晴らしさを話しても「あっそう」といった感じで流された覚えがあります。そこで、地元のユーザーグループを探して参加してみることにしました。私が参加したのはLondon Ruby User Group (通称LRUG)です。
LRUGでは毎月第2週の月曜日に開催されます。6時半から8時ぐらいまでは会議室でだいたい2つくらいのプレゼンテーションを聞き、その後パブになだれ込むといった感じです。
初めて参加した日のプレゼンの内容は素人には高度すぎてチンプンカンプンだったのですが、いろいろと良い刺激を受けました。
その後のパブで、ほかの参加者にプログラミングに関する色々な質問やお勧めの書籍などを聞くと、丁寧に答えてくれる人がいたので、その彼を誘ってみることにしました。
誘い文句は「このコンテストはMatz(Rubyの開発者、まつもとゆきひろさん)がコードを見るみたいだよ」。もちろん優勝賞金100万円のことも言いました。
ただ、ここで重要なことがあります。できる人をその気にさせる場合、金銭的なことよりも、いかに自分の作ろうとしているアイデアが技術的にチャレンジングかをアピールすることのほうが重要です。案の定、最初のブログシステムに関しては「どこにでもありそうだし、その中で作ろうとしている機能の1つは、あっても使わないと思うよ」と率直な感想をもらいました。でも、新しいアイデアのほうは結構気に入ってくれて、一緒に開発することになりました。
では、共同開発者に気に入ってもらったアイデアとは、どういったものだったのでしょう。以下が出来上がったアプリを応募した際の紹介文です(リンク)。
〜 Blogコメントに市民権を!!〜
commect.usでは、日頃おざなりにされがちなコメント(Comment)を集める(Collect)ことで、皆さんのブログと読者をつなげる(Connect)ことができるようなサービス(commect.us)を目指しています。
なかなか意欲的な紹介文だったと思います。
自分の書いたコメントを投稿するとき、そのコピーをデータベースで保存。後で自分がいままで書いたコメントの一覧を表示するシステムを3週間、しかも平日の夜や週末を利用して作り上げました。
残念ながら、コンテストでは何も賞を得ることは出来ませんでしたが、この経験を通して得られたものは非常に多かったと思います(ちなみにそのとき大賞を受賞されたのは、現在日本でRails開発の一線に立つ株式会社万葉の大場寧子さんです)。
Railsのフレームワークを通してMVC(Model、View、Controller)、COC(Convention over Configuration)、TDD(Test Driven Development)の雛形を得ることは出来ますが、それを本当に活用するには独学は結構難しいと思います。例えば、「このロジックはControllerとModelのどちらに書けば良いのだろう」「PostやCommentとか明らかなものを別々のModelとして分けるのは分かるけれど、それよりもっと複雑なModelはどう分ければ良いのだろう」などといった具合です。
私の共同開発者は、Railsこそ初めてでしたが、Javaプログラマとしての経験が十分ありました。そしてXP(Extreme Programming)という、いまでいうアジャイル開発の基礎となる開発手法を重んじている人でもありました。彼と一緒にペアプログラミングやテスト駆動開発(アプリケーションプログラムを書く前に、まずそのアプリケーションをテストするコードを先に書く方法)を用い、2人で試行錯誤しながら学んでいくことが出来ました。
そして、Railsの世界にハマればハマるほど分かってきたのは、Ruby on Railsというフレームワークを作り上げている土台の、Ruby言語への理解の重要性です。Rubyの学習方法については、次回のテーマとしたいと思います。
Copyright © ITmedia, Inc. All Rights Reserved.