Ruby on Rails 4.1でDevOps環境を考慮した体系的な知識を付ける情シスの本棚(8)

エンタープライズ領域での高速なWebアプリケーション開発にも採用され始めているRuby on Rails。最新版である4.1の実践的な解説書が登場した。DevOps環境を前提としたチュートリアルが掲載されているなど、現代的な内容になっている。

» 2014年07月03日 18時12分 公開
[原田美穂@IT ]
※本記事はアフィリエイトプログラムによる収益を得ています

枯れない環境だからこそ発生する問題

●著者:すがわらまさのり、前島真一、近藤宇智朗、橋立友宏●技術評論社●ISBN-10:4774165166●ISBN-13:978-4774165165●発売日:2014/6/6

 Webアプリケーション開発のためのフレームワークとして、日本でも多くのユーザーを持つRuby on Rails(RoR)。RoRは2005年12月にバージョン1がリリースされて以来、多くの人に使われ、現在、バージョン4.1まで成長してきた。今ではWebアプリケーション開発に欠かせないフレームワークの代表格となっている。

 一方で、開発スピードの速さやバージョンアップが利用者を翻弄してきたのも事実だ。有益な実装を速やかに反映するこのツールを使いこなすための実践的な知識が体系的に得られる情報源を求める声は今も少なくない。オンラインで4系の情報をまとめて得られるのは@IT連載「開発現場でちゃんと使えるRails 4入門」など、ごくわずかだ。

 ただ、開発が活発に行われている=枯れていない環境にはよくあることだが、RoRは現場のニーズを素早く取り込んでくれる開発フレームワークであると同時に、体系的な知識が付けにくいという「落とし穴」にはまりがちなものでもある。

 RoRはMVC(Model、View、Controller)モデルを採用している。このため、モデルを理解した上で実装しなければ、フレームワークの目的の1つである効率的な実装と改修が難しくなる。Webアプリケーションを作ろうと考えて、すぐにRoR環境を用意し、MVC分割の利点を理解せずに不用意な実装をしてしまうと、不適切な場所に業務ロジックを書いてしまったり、モデルが肥大化してしまったりといった事態が発生する可能性が非常に高い。

 また、RoRには、テスト工程を効率化する機能が用意されているが、せっかくのテスト支援機能も使いこなせなければ、低品質のアウトプットしかできない可能性もある。デプロイの方法1つを取っても、理解度によって効率や品質が大きく変わってしまうのが、Webアプリケーション開発フレームワークの難しいところだ。

 独学でRoRを使ってみて、このような「落とし穴」にはまって挫折してしまった開発者も多いのではないだろうか。

コミュニティから生まれた、体系的な現場指向のRailsの知恵

 RoRはDRY、YAGNI、あるいは「設定より規約」などの、特徴的な思想に支えられたツールである。こうした思想はハッカーの精神、開発現場の声、コミュニティに蓄積されてきたデザインパターンなどの知識の積み重ねで醸成されたものと言ってよいだろう。

 その点、これまでRoRを使いこなしてきた人たちは、良い先輩から教えてもらったり、勉強会やコミュニティでコードを書いて自然と身に付けたり、といった形でRoRの思想を理解する機会があった幸運な人たちだといえる。「文化」を理解した人にとっては唯一無二といってよいほど、便利で有用なツールになり得るものだからだ。

 本書はそうした「文化」も含めて解説している。Asset PipelineやRailtieといった重要ながら新しい実装のために情報が少ない領域、あるいは、MVCモデルに則したモデル設計方針などを含む情報がまとめられており、今まで体系的に学習しにくかった領域をカバーしている。

 例えば、モデルの設計方針に関して、本書第9章では、次のような言及がある。

複雑な処理が必要なデータは、整合性を維持するためにも複雑なルールがある可能性が高く、関係するモデルの数も増加します。1つのクラスがロジックとデータの永続化の両方について責任を持っているアクティブレコードのアーキテクチャでは、モデルが一気に肥大化する場合があります。

 このように、RoRに少し慣れたころに陥りやすいアンチパターンである「モデルの肥大化」についての注意喚起が示されている。続く解説は、次のようにアンチパターンに陥る原因と、解決方法も示されている。

ActiveRecordモデルが肥大化する主な原因は、RDBのテーブル構造と一体になっていること、そして1つのクラスの中で広範囲の処理ができることです。

…(中略)…

これを解消するためには、RDBに依存しないモデルクラスや、1つの物事についてのみ責任を持つ小さなクラスを作り、複雑化した機能をそれぞれのクラスに抽出していくことが必要です。

 この章では、以降の言及で、コールバッククラスやバリデータクラスの抽出、ActiveModelの個別機能の利用方法といった、幾つかの具体的なパターンも紹介している。

 また第10章では、以下のようにRoRに依存しない最小限のRack対応のWebアプリケーションを例にした解説が展開される。RoRをただ触っているだけでは理解しにくいRackレイヤーとRack Middlewareについて、手を動かしながら学習できるよう配慮されている様子がうかがえる。

class UpcaseAll
  def initialize(app)
    @app = app
  end
  def call(env)
    code, headers, body = @app.call(env)
    body.each{|part| part.upcase! }
    return [code, headers, body]
  end
end
App = lambda do |env|
  [200, {"Content-Type" => "text/html"}, ["Hello, Rack world!"]]
end
use UpcaseAll
run App

 本書を代表とする同シリーズは、体系的かつ現場主義的な情報を盛り込むことで、独学に耐える情報を提供することに尽力した良書といえる。本書もその特徴を発揮しており、アプリケーションの設計からコーディング、テスト、そしてサーバー構築、デプロイから運用までを一気通貫で解説した章を設けており、「良き先輩」の開発状況を横で見るように、一連の流れを追跡できるようになっている。特に8章ではDevOps的な環境を考慮し、Vagrantを使った環境構築やChefによるプロビジョニングの方法、サーバー構成管理、デプロイ方法を、サンプルを交えて丁寧に解説している。

 また最終章では、RackやRailtieによるプラグインの書き方、高度なモデルの設計方法についても言及されており、使いこなすための道筋も示している。

Copyright © ITmedia, Inc. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

AI for エンジニアリング
「サプライチェーン攻撃」対策
1P情シスのための脆弱性管理/対策の現実解
OSSのサプライチェーン管理、取るべきアクションとは
Microsoft & Windows最前線2024
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。