Rails」の第2回目です。Railsで行うプロトタイピング」は、プロトタイプを作成することの有用性と現状のプロトタイプ作成がどのような問題点を持っているか、RoRを使用してプロトタイプを作成することでどのようなメリットがもたらされるかについて解説しました。連載第2回目は、RoRを使ううえで欠かせないRubyについて解説します。Ruby入門者にはこれらの書籍をお勧めします本連載の2回目は、まだまだ知名度が低いRubyに対して読者の方にイメージをつかんでもらうことを目的としています。この記事を通読してもRubyができるようになるわけでは(当然)ありません。今回の記事を通読していただいたうえで、Rubyをキチンと勉強したいと感じられた方には以下の書籍をお勧めします。以下は、WikipediaからのRubyの項の一部抜粋です。Ruby(ルビー)は、まつもとゆきひろ(通称Matz)により開発されたオブジェクト指向スクリプト言語であり、従来Perlなどのスクリプト言語が用いられてきた領域でのオブジェクト指向プログラミングを実現する。(中略)Rubyはクラス定義、ガーベジコレクション、強力な正規表現処理、マルチスレッド、例外処理、イテレータ・クロージャ、Mixin、演算子オーバーロードなどの機能を持つ。オブジェクト指向スクリプト言語とありますが、Rubyはインタープリタで起動するオブジェクト指向言語である、と読み替えることが可能です。上記の豊富な機能を簡単なシンタックスで利用できること、C#、Javaなどと比して比較的学習コストが低いこと、純国産のプログラミング言語であることなどから以前より日本国内ではRubyの注目度は高かったのです。Fowler氏も注目している[*3]などの理由によりRubyは全世界的にホットな言語になりつつあります。People)、http://capsctrl.que.jp/kdmsnr/wiki/bliki/?RubyPeopleどうしてRubyなのか・Javaでなぜいけないの?JavaでWebアプリケーションを作成する際に、最近ではSpring、SeasarのようなDIコンテナを使用することが主流になりつつあります。DIコンテナを使用すると、特定のコンポーネントやフレームワークベンダ製品など環境への依存を外部設定ファイルに外出しし、その依存性をアプリケーションの実行時に解決することができます。この結果、ソースがクリーンになり、可読性の向上、テスト可用性の向上などが期待できます。ところで、筆者はリファクタや修正でクラス名を変更したのに設定ファイルを変更し忘れるということがときどきあります。ビルドしてデプロイして修正個所を確認しようとテストデータを流した時点でデプロイしたアプリケーションが動かなくて、やっと設定ファイルを修正し忘れたことに気付きます。この場合設定ファイルに記述されたクラスがロードできなかったことがその原因なのですが、そもそもJavaのような静的型付け言語ではこういう仕事(クラスの存在チェック)はコンパイラがやってくれるはずだったのではないでしょうか?以下に筆者がよくやってしまう、クラス名を変更したけれど設定ファイル(今回の例はSpring)を修正し忘れるケースを示します。Zakuクラスを作成。ZakuクラスをSpringの設定ファイルに記述します。Zakuクラスのクラス名をGufuに変更します。静的型付け言語と呼ばれています。これに対してRubyは動的型付け言語と呼ばれています。一般に、オブジェクト指向言語では「そのコンテキストで決定されているオブジェクトのクラスにメソッドaが定義されているか」でメソッドの呼び出しの可否が決定します。コンテキストというのは、ちょっと分かりづらいのですが「コード中の文脈」の意味でとらえてください。静的型付け言語ではコンテキストはコンパイル時に決定されるので、つまり言語仕様的に変数の宣言には常に型の宣言が必要になるため、コンパイル時にメソッドの呼び出しの可否を決定することができます。リフレクションを使用する場合この限りではありません。動的型付け言語ではコンテキストは実行時に決定されるため、あるオブジェクトがメソッドaを呼び出せるかは、実行してみないと分かりません。逆にいうと、あるオブジェクトのクラスがなんであれ、メソッドaが定義されていれば、a(という名前を持つメソッド)を実行することができます。動的型付け言語ではコードの妥当性はユニットテストを実行して正しく動作することで担保するというのが定説です。動的型付け言語はほとんどがインタープリタ形式で実行される(Smalltalkのような例外もあります)ため、静的型付け言語で作成しコンパイル済みであるアプリケーションと比べて実行速度において劣る傾向があります。このように静的型付け言語だからすべてダメというわけではなく、それぞれ適材適所があってケースに応じて使い分ければ良い、と筆者は考えています。・結局動かしてみなければ分からないもうお分かりかもしれませんが、DIコンテナを使用した場合、Javaはコンテナから取り出したオブジェクトのクラスを実行時に決定することになります。StrutsのようなWebアプリケーションフレームワーク、HibernateのO/Rマッパーを使用した場合にもいえます。外部設定ファイルはコンパイルの対象にならないので、本来ならコンパイル時に発現するべきクラスの存在チェックエラーなどがコンパイル時には起こりません。ユニットテストあるいはデプロイなどして、動かしてみなければ、正しいかどうか以前に動くかどうかさえ分かりません。これはソースがクリーンになったことに対する静的型付け言語の長所を消してしまうという外部設定ファイルの副作用と考えることができます。・Rubyがアジャイルある程度イテレーションも繰り返して設計がこなれてきても、クラス名の変更やインターフェイスの変更や実装の変更は起こります。アーキテクチャの方向付けでクライアントとの最終成果物のイメージ共有に使用されるプロトタイプを作成しているような場合では、それこそ猫の目のごとく変わっていくことでしょう。JavaではEclipseなどのリッチなIDEを使用することでその負担を軽減しています。Rubyは動的型付け言語の恩恵を受けて、変更点そのものが少なくて済みます。本連載の次回以降に解説しますが、RoRでは設定ファイルが従来のJava/Webアプリケーションよりも断然少なく、かつ簡単に作成、修正することができます。RoRならより短い時間でWebサーバを起動しアプリケーションの動作を確認することができます。称して情報を盗む「ご注意!!OFFICEのプロダクトキーが不正コピーされています。Japanスマートジャパン3Dモデラボキャリア@IT自分戦略研究所エンジニアライフディルバートアプリITmediaねとらぼねこらぼついトピ!ITmediaはアイティメディア株式会社の登録商標です。