Foodyn CMS開発日誌

Categories

open all | close all

Tags

Subversion | テスト | 名称 | Migration | Flash | フォーム | カテゴリ | パソコン | Aptana | CSRF | 認証 | タグ | 国際化 | rake | デュアル・コア | JustPosted | RESTful | rubygems | スキンエンジン | ドキュメント

Search

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のrespond_toのところだけ使う方法というのが分からずに苦労していたわけですが，本屋で「RailsによるアジャイルWebアプリケーション開発 第2版」のRESTのところを立ち読みしてみたら，書いてありました。あー，やっぱりこの本も必要かなあ…。高いのと厚いので敬遠していたのですが（ちなみに第1版は読みました）。




具体的にどうするかというとルーティングのところ，例えばアイテムページは
map.item 'item/:itemid', :controller => 'application', :action => 'item'
といった形になっていたわけですが，まずこれを
map.item 'item/:id', :controller => 'items', :action => 'show'
といったRESTのスタイルのコントローラとアクションに書き換えます。
そして，フォーマットの拡張子に対応するために
map.item 'item/:id.:format', :controller => 'items', :action => 'show'
というのを付け加えます。これで，REST対応のscaffoldが生成したItemsControllerのshowメソッドで受けられるようになります。後は
  def show
    @item = Item.find(params[:id])

    respond_to do |format|
      format.html { item }
      format.xml  { render :xml => @item }
    end
  end

といった形でHTML形式が要求されたときはitemメソッド（今のところ従来のままApplicationControllerにあります）で表示します。

標準でlayoutファイルが使われることに気付かず，しばらく悩みましたが，ようやくこれでアイテム・ページを表示できるようになりました。拡張子.xmlを付けたらXMLでも表示できました。後はこれにならってルーティングとコントローラ周りを修正すれば，RESTのスタイルになります。

結局表示のREST対応を考えるだけで1ヶ月近くかかってしまいました。このあたりはあまり情報が多くないので苦労します。

備忘メモ

プロジェクトを作り直す際は，simple_localizationのlanguagesディレクトリにja.ymlを作ること。
orz

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

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

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

やっと方針が固まる

まず，Rails2.0にはいずれするのだから，今の段階で載せ替えてしまいます。
それから，RESTfulにもいずれするのだから，今の段階でしてしまいます。
認証は管理画面だけで入れます。つまりブログ閲覧時には常にゲスト扱いになります。
これで困るのは「edit」リンクが入れられないことと，ユーザーとしてコメントするには管理画面に入る必要があること。
機能的には明らかに低下してしまいますが，認証しているユーザーもそうでないユーザーも見られるページを作るにはまだRESTは実験段階にあると思います。先日紹介したページもじっくり読みましたが，正直言ってかなり無理やり実装している印象でした。そのあたりが成熟してきたら改めて機能を入れたいと思います。
一方，こういう仕様にするメリットとしては，ページ・キャッシュが利用できることが挙げられます。Railsのように「重い」フレームワークを使うとき，キャッシュは動作速度にかなり影響するはずです。特にレンタルサーバーで動かすことを考えたら，機能的なデメリットよりもキャッシュのメリットの方が大きいと判断しました。
このほか，URLに拡張子を付けることで，さまざまなページタイプに対応できるというメリットもあります。例えば.rssを付けたらRSSになったり，.mobileにしたら携帯用のページになったり，といったことがやりやすくなります。

そんなこんなで，今は2.0に乗せかえるという作業をやっと始めたところ。正月休み中に少し形になってほしいところです。

ところで，今回暫定的なプロジェクト名を「Rucleus」としています。ただRubyとNucleusをかけあわせただけ。もっといい名前があったらいつでも変更しますが，とりあえずコード名ということで（笑）。

しつこく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化し，ブラウジングはしないという形で進めようかと思います。

Archives

• December, 2008
• November, 2008
• October, 2008
• September, 2008

Login

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