Foodyn CMS開発日誌

Categories

open all | close all

Tags

テスト | Aptana | Flash | ドキュメント | アクセス制御 | スキンエンジン | フォーム | CSRF | タグ | 国際化 | rake | デュアル・コア | 認証 | Subversion | パソコン | OpenID | RESTful | モデル | 名称 | Migration

Search

Railsを学ぶための本──Rails編

Ruby編はこちら。
(2/5:「基礎Ruby on Rails」などを追加）

Ruby on Railsの本はたくさん出ていますが，一つ気を付けなければいけないのは最新版であるRails 2.0をベースにした本は2008年1月時点では出ていないということ。9ドルで買えるPDF版の解説はありますが，内容はややあっさりめです。日本語の情報となると，Webを検索して断片的に得るような形にならざるを得ないようです。

RailsによるアジャイルWebアプリケーション開発 第2版
Ruby on Railsの開発者であるDavid Heinemeier Hansson氏が書いている本。オフィシャルな解説書といっていいでしょう。第2版はRails 1.2をベースにしており，2.0の目玉であるRESTfulの機能についてもかなりカバーしています。そういう点でも一番進んでいるといえます。難点はボリュームが膨大で，全体像を理解するのが大変なこと。文も割とそっけないです。例えば「Railsではアジャイルでイテレーティブな開発スタイルが推奨されます」といった感じ。こういった文が頭にすっと入っていけないとちょっと辛いかも。サンデープログラマーが1冊目として読むのにはお勧めしません。実力がある人はバリバリ読んでいってください。




Ruby on Rails入門―優しいRailsの育て方
通称「舞波本」。名前の由来は作者のサイトを見れば分かるでしょう。

Amazonのユーザーレビューでは「これは入門書ではない」という意見がいくつか出ています。確かに全くのプログラミング初心者には難しいかもしれませんが，他の言語やWebプログラミングの経験があれば，そんなに難しくないと思います。他の多くの本に書かれているようなチュートリアル形式の例などがないので取っ付きにくそうですが，僕にとってはこの方が逆に体系的に分かりやすく感じられました。特に，Active RecordやURL処理などRailsの中心的部分はよく書けています。ただ，ベースにしているバージョンは古いので，細かく見ていくと，現在では使えなかったり違ってきている部分があります。この本でRailsとはどのようなものかをつかみ，他の資料を見るのが現状ではいいアプローチのように思えます。




Ajax on Rails
Railsの魅力の一つはAjaxが統合されていること。僕はまだこの部分は使っていませんが，上の本やこの本を読むと，とてもよくできているなあと思います。Rucleus（仮）についていえば，今後管理画面を作っていくときにはこの本が相当役に立つはずです。Railsならではのアプリケーションを作るには持っていたい本だと思います。内容もよいです。




Railsレシピ
これも，まだあまり活用していませんが，Railsの初級者を脱するためには必要な本でしょう。内容はこちらのページを参照してください。これもバージョンにはちょっと気をつける必要がありそうです。なお，英語ではAdvanced Rails Recipesという続編も出ています。RESTについても記述されていますが，まだ買っていません。買うならPDF版かな？（ちょっと高いような気がしますが）







基礎Ruby on Rails
教科書的に使うのなら，これが一番無難でしょう。1.2をベースにしている点やRubyの説明が一番充実している点がよい点です。ただ，「舞波本」と比べると面白みに欠けるところがちょっとどうか。記述は平易で，あまり内容を欲張らずに書いているので「RailsによるアジャイルWebアプリケーション開発」で挫折した人でも読みやすいだろうと思います。




はじめよう Ruby on Rails
かんたんRuby on RailsでWebアプリケーション開発
どちらもチュートリアルを中心とした本。入りやすいですが体系的に学ぶには物足りなさそう。個人的にはもっとリファレンスっぽい本の方が好きです。





7日でマスターRuby on Railsで作るWebアプリケ―ション入門
2.0対応ということでちょっと惹かれるものがありますが，内容はかなり乏しいです。7日のうち4日目に初めてDBを使い，5日目にscaffoldを使います。二日くらいでできることを一週間かけてやっている印象。本格的な開発には応用できないと思います。




まだ読んでいない本もいくつかあるので，読んだらここに追加していきます。

Railsを学ぶための本──Ruby編

yuさんのところで紹介されたせいか，いくらかアクセスが増えているようです。作業の方はREST化に基くURLの修正と，URL生成部分の修正で，どうやらURL周りがちゃんと動くようになったというくらいで，機能的な進展はあまりありません。NFLのプレーオフシーズンで作業がはかどらないというのもありますが(^_^;)

ところで，これからRails勉強したいという人もたくさんいると思うので，僕もまだまだ初級者ながら，参考になった本などをいくつか比較紹介したいと思います。

世の中にRails本はたくさん出ているのですが，Railsにいきなり取りかかるよりも，まずはRubyを一通りでも見ておくのがいいと思います(Rails編はこちら)。RubyはPHPと比べると非常に記述力が高く，言語としての機能も豊富です。また，メソッドの引数にカッコを付けなくても構わないなど，文法的な癖も割とあります。他言語からPHPに入ると，機能にとまどうことはあまりないと思いますが（PHP4のオブジェクト指向機能のしょぼさにはちょっと驚きましたが），PHPからRubyだと，文法的に何が起こっているのかわからないことが出てきます。したがって，いきなりRails本を読んでも，どこがRailsによるものでどこがRubyによるものなのか，多分分からないと思うのです。

プログラミングRuby 第2版 言語編
一番，定番と言われているのがこれ。とりあえずこれを持っていれば安心というところはありそうです。ただし，拡張ライブラリの作成方法など，Railsのために勉強するにはややオーバースペックなところがあるのが難点。大きいし，重いし，高いしね。会社や学校などでリファレンス的においておくのならベストだと思いますが，個人だったらここまでは必要ないかも。それから，これ買うならライブラリ編も合わせて買いたくなるのも個人的には減点ポイント。






たのしいRuby 第2版 Rubyではじめる気軽なプログラミング
Rubyではじめる気軽なプログラミングというキャッチコピーに偽りはなく，非常に読みやすく手軽に読み進められる本です。プログラミングが初めてという人でも多分大丈夫でしょう。逆にプログラミング言語経験豊富な人にはちょっと物足りないかも。プログラミング経験が少ない人にお勧め。




Rubyプログラミング入門
この本，Amazonのレビューは低評価ですが，僕としては結構読みやすくいい感じだった本です。確かにAmazonのレビューにあるようにプログラミング入門としては難しいです。逆に他言語の経験がある程度あったら，たのしいRubyよりこちらの方が読み応えや分かった感が強いでしょう。




Rubyプログラミング基礎講座
大学の情報科学の教科書として使うような感じの本です。Webプログラミングをしたいという人にはあまり向かなさそう。これを買うのならたのしいRubyの方がいいと思います。




Rubyレシピブック 第2版 268の技
これはまだ買ってないのですが，次に買う可能性が一番高い本です。簡単に言えばRubyの小技集。こういうことをしたいときにはこう書くのが定番だよ，っていうのが分かります。Rubyらしいプログラムを書きたい人には役立ちそうなテクニックが満載。




Rubyクックブック ―エキスパートのための応用レシピ集
これはまさにエキスパート向け。特に前半のメタプログラミング関連の部分は自分でRailsみたいなものを作りたいと思ったり，Railsってどうやって実現しているのだろうとかってことを考えるような人にはいいと思います。後半はRails関連のレシピもでてきますが，そちらは若干消化不良。既に古くなっている部分もあります。Railsの上で何かを作りたい人にはここまで要らないでしょうが，Rails自体を理解したいとか，Railsの開発に参加したいなら必須の本だと思います。




最後に，ライブラリのリファレンスなどは前述のライブラリ編のほか，オンライン・ドキュメントが役に立ちます。特にWindows HELP形式のものはWindowsユーザーにはかなり便利です。ダウンロードはこちらから。

REST化についての考察（まとめ）

ここではRucleus（仮称）でなぜRESTの設計を取り入れることにしたのか，どういう問題があるのかをまとめておきます。

RESTの意味とそのメリット

Rails 2.0の目玉の一つがRESTfulな設計が簡単になったことですが，RESTの機能自体はRails 1.2で導入されています。僕自身は「RESTってWebサービスのインタフェースの1つでSOAPほど面倒くさくないやつでしょ」ってくらいの認識しかなかったのですが，RESTについて調べると，そういうものではなくてWebアプリケーションの設計思想に近いものだということが分かってきました。

RESTfulなアプリケーションやサービスではURLはリソースを示します。例えばブログやアイテムがリソースです。Railsではモデルすなわちデータベースのテーブルがリソースになります。これに対して「何をするか」という「アクション」はHTTPのverb，すなわち「GET」や「POST」などで表現します。これをリソースのコントローラに対して適用します。つまり，モデルのクラス1つに対してコントローラのクラス1つが対応するような形になります。なおverbとしてHTTPの仕様では「DELETE」，「PUT」（データの更新）が定義されていますが，現在使われているブラウザが送信するのはGETとPOSTしかないため，Railsではフォームに特別なフィールドを作ってDELETE，PUTを実現します。

RESTのもう1つの特徴に内部状態に依存しないということがあります。クッキーやセッション・データによって表示内容を変えることがなく，URL（正確に言えば，HTTPヘッダに含まれる情報）で結果が決まります。これによって，ページ・キャッシュが実現しやすいというメリットがあります。サーバーに内部情報を保存する必要がないため分散処理も容易になります。

また，「respond to」による各種フォーマットのサポートという特徴もあります。例えばRailsのRESTサポートではXMLによる出力を標準的に利用できるようになっています。

これらRESTの特徴はNucleus（Rucleus）となじみがいいものです。例えば，初期の設定ではURLの解釈においてアプリケーションというコントローラにブログやカテゴリーといったリソースの情報を渡して「item」をアクションとしてIDを付けてアクセスするといった形にしていました。それよりはブログやアイテムをリソースとしてアクセスすると考えた方がすっきりします。また2番目の特徴は性能を考えたときにクリティカルになってきます。最後の各種フォーマットのサポートも，スキンを切り替えることでさまざまな出力を行うNucleusのスタイルと相性がいいです。

認証の問題

では，何が問題になって悩んでいたかというと，認証関係とURL周りです。まず，認証ですが，RESTではNucleusが従来やっているようなクッキーを使った認証というのは問題になります。BASIC認証やダイジェスト認証，WSSE認証といったHTTPで定められた認証が必要です。この中でWSSE認証はブラウザがサポートしていないため，JavaScriptでなにやらやる必要があるなど，採用には問題点があります。次にBASIC認証やダイジェスト認証を使ったときですが，いくつかの課題が生じます。①1つのURLでログイン・ユーザーとゲストで違ったページを表示するのが難しい，②ログイン時にダイアログ・ボックスが出るのが格好悪い，独自のページでログインさせたい，③ログアウトが困難，といったものです。

こちらのページにはこれらの条件を満足させてダイジェスト認証を使う方法が記載されていますが，詳しく読んでみると，ブラウザによってやり方を変えなければいけないなど，現実に採用するには難しい部分がかなりありそうです。上の問題で①が機能的に一番ほしいところですが，逆に言えばここだけ我慢すればいいという見方もできます。

URLの問題とその解決法

最後の問題となったのがURL周りです。冒頭に書いたようにRails 2.0ではREST対応のアプリケーションを簡単に作れるようになっていますが，URLに大きな制限を受けてしまいます。例えば，blogidが1のitemidが10というアイテムにアクセスする場合，URLは「blog/1/item/10」といった形式に固定化されてしまいます。ここを独自のURL設計にする方法が分からずに悩んでいたわけです。

現在のURL周りの処理はこんな感じです。例えば /blogname でブログにアクセスする場合
  map.blog ':blogname', :controller => "blogs", :action => 'show'
といった形で「blogs」をコントローラにしてshowというアクションを実行します。blognameからブログを見つける処理はshowの中に記述します。これに各種フォーマット対応をするために次のように追加します。
  map.blog ':blogname.:format', :controller => "blogs", :action => 'show'

アプリケーションのコントローラには
private
  def setblog
    if !params['blogname']
       $NCGlobals['blog'] = Blog.find(CONF['DefaultBlog'])
    else
       $NCGlobals['blog'] = Blog.find_by_bname(params['blogname']) || Blog.find(CONF['DefaultBlog'])
    end
  end
  
  def setcatid
    if params['catid']
       $NCGlobals['catid'] = params['catid'].to_i
    end
  end
  
  def setskin(skinname)
    if (skinname=='')
       $NCGlobals['skin'] = $NCGlobals['blog'].skin
    else
       skin = Skin.find_by_sdname(skinname)
       $NCGlobals['skin'] = (skin) ? skin :$NCGlobals['blog'].skin
    end
  end

public
  def blog(skinname='')
    setblog
    setcatid
    setskin(skinname)
    
    $NCGlobals['skintype'] = 'index'
    $NCGlobals['item'] = Array.new
    $NCGlobals['controller'] = self

    @contents = $NCGlobals['skin'].part($NCGlobals['skintype'])
    @controller = NCParser::DefaultSkinIndex.new $NCGlobals['controller']
    render :action=>'index.html.erb'
  end

といった形でblognameから実際のブログオブジェクトを見つけることなどが記述されます。また，blogs_controllerのshowメソッドは
  def show

    respond_to do |format|
      format.html { blog }
      format.xml  { blog('feeds/rss20') }
    end
  end
といった形になります。このようにしておくだけで /lab.xml というURLでアクセスするとRSS2.0のフィードを生成してくれるようになります。

RESTのルーティングが難しい

作業が進んでいないのは，いまだにRESTfulにしたときのルーティング設定をちゃんと理解していないからです。Railsが用意するネスト付きリソースのルーティングを使えば簡単ですが，そうするとURLがsite/blog/blogid/category/catid/item/itemidという形に固定化されてしまいます。ここを自由に設定してなおかつ，RESTのルーティングの恩恵（具体的にはGETのときのさまざまなフォーマットサポートが簡単にできれば事実上十分なのですが）を受けるにはどうしたらいいか。いろいろドキュメントを読んでいるのですが，2.0関係の資料が少ないこともあり，そのものずばりの回答は出てこない状況です。

いい加減に先に進みたいのですが，肝のところなのでもう少し粘ってみます。難しいなあ…

しつこくRESTについての自分メモ

ユーザー認証情報はWWW-Authenticateヘッダーに入れる。HTTP Digest認証を使うのが良い。
（SSLならBasicでもいいが，いちいちSSL使うよりはDigestでしょう）
ここのページにはクッキーを使わずに，①カスタムログイン・ページを使い，②ログアウトもでき，③認証していないユーザーも見られる，ページの作り方がでている。ちょっとトリッキーだが，一応バイブル的ページのよう。
Zope2/PloneにはクッキーとWWW-authenticateを併用する実装があるそう。

そもそもRESTful Authenticationはどうやっているのか確認していない。→確認したところセッション，Basic認証，クッキーの順で調べていることが判明。認証はRESTfulになっていても，RESTfulなアプリに使うには今ひとつ？

気になるのはクッキーとWWW-Authenticateを併用する方式。WWW-Authenticateでユーザーが確認できれば，クッキー併用は構わないと思うのだけど，それで実装がどれだけ楽になるのだろう。Rubyの実装はないのだろうか。

RESTful Webサービス by オライリー

ほしいけど高い。ウィッシュリストに入れたので後はサンタさんよろしく。

まだRESTで悩んでいたりして

このところちょっと勉強モードが続いていて実装は進んでいません。
Rails2.0のRESTとページキャッシュについて書いてあるページを見たのですが，ページキャッシュを使うとしたら，ユーザーがログインしているときは明示的にURLを変えないといけないのでRESTになっていくような気がします。メリットもあればデメリットもあるし，悩ましいところです。

RESTは時期尚早？

いろいろ調べたところ現在の状況ではまだRESTを全面採用するのはメリットよりもデメリットが大きいような気がしています。最大の理由はURL。RESTを使うとブログやアイテムにそれぞれコントローラを割り当てることになりますが，そうするとURLが http://example.com/blog/1/item/3 みたいな形になってしまいます。これを工夫して http://example.com/blog/mymainblog/item/about_rest みたいにする方法はいくつかのサイトに出ていましたが，本当は http://example.com/mymainblog/about_rest までシンプルにしたいところ。その方法があるのかどうかはクリアになりませんでした（逆に言うとそれができるならREST化してもいいかな，と思います）。

また，もう1つの理由としてブログやCMSでは閲覧が中心となり，CRUD（Create-Read-Update-Delete）のうちRead以外はあまり登場しません。せいぜいコメントくらいです。したがってREST化するメリットが希薄になってしまいます。

一方で，管理画面の方はURLが多少冗長でも問題ありません。CRUDも大事です。したがってそちらはREST化し，ブラウジングはしないという形で進めようかと思います。

RESTでRest

Rails2.0についての開発者のブログを読んでいたら，RESTについて強調しているので，あらためて勉強，っていうか知らなかったですよ，REST。

今のところGETを使う閲覧系しか実装していないから1.2の上でもRESTにはできるはず。将来を考えたらやっぱりそうするべきなんでしょうねえ，と思ってちょっとそちらを調べています。ということで今日もコードはなし。ちょっと休憩（ｒｅｓｔ）。

日本語の資料ではここが一番役に立つのかな。これの原文の英語版はこちら（PDF）。

RESTなアーキテクチャにするにはクッキーにユーザー情報を格納しておくというのはまずいため，のびのびになっている認証にもまた絡んできます。BASIC認証は使っていいよという話もありますが，ブログの場合はログインしていないユーザーにも閲覧できるようにする必要があるためBASIC認証とはちょっと相性がよくなさそう。それともログインが必要なURLにはユーザーIDを入れてしまうとか？ なんだかかえって使い勝手を落としてしまいそうな気もします。

使うのをあきらめたacts_as_authenticatedの派生プラグインでrestful_authenticationというのもあるようですが。どうしましょうかねえ。

Archives

• May, 2008
• April, 2008
• March, 2008
• February, 2008

Login

• ユーザー名: パスワード: このPCを他の人と共用する