Ruby on Rails: 2007年11月アーカイブ
今年のゴールデンウィークから、ちょっとずつ作ってきたWebサービス「今読ミ imayomi」。URLは超シンプル。imayomi.jp
どういうのかというと、「今、こんな本読んでるよ！」とアピったり、最近読まれているのから面白そうな本を見つけたり、そんなサービス。
まだ私の知人に試しに使って貰ってるだけの状態ですが…
これで、ほぼ全機能だったりします。目指すは簡単だけど、なんか面白い。
内部はと言うと
Amazon完全異存体質。
うわさの簡単フレームワーク、Ruby on Railsでも初めて作ると大変だった。
DBは普通にMySQL。
デザインはhachimituさん
ただし今のところかなり貧弱なインフラで稼働しているので、まだ本当にひっそりとした告知にとどめないと危ないといった案配です。
このエントリーを見つけた、あなた、試しに使ってみていただけないでしょうか。
先日の条件付きテーブル間リレーションシップの続きであります。
Migrationはこんな感じか。
これで、self.up 時に、books テーブルに格納されていたコメントが、新しい comments テーブルに移行できる。self.down はその逆である。
ここで少し、道草するが、最初、上記の Migration コードで正しく新スキーマに変わって安心していたのだが、そのまま開発が進んだあと self.down してみたくなってやってみると、全然動かない。まったく正しそうに見えるのに、おかしいなと散々悩んだあげく、Bookクラスの関連定義の所為だった。
つまり Book モデルの関連が開発が進んだ状態なので Comments モデルと has_one/belongs_to 関連がり、それが邪魔して動かなかったわけだ。しかし本当に self.down する際には、新しいモデルの状態でバージョンダウンが動くはずだ。上記のコードで言うと、self.downの 中で
としているところで、book.comment は comments テーブルの参照として定義されているのがいけない。
原因が分ったらハッとひらめいた。Railsのモデルクラスは ActiveRecord::Base さえ継承していれば、完全な ActiveRecord として動くのであるから、Migration の定義に先立って
と書いておくだけで、純粋にスキーマのメタ情報でのみ動くはずだ。
そしてこの方法は、ちゃんとうまくいく。
しかし、ここまでやってみて、はたと気づいたのだが、あれか。
バージョン管理システムからソースコードを先にMigrationをコミットした状態にまで戻してから、db:migrate VERSION=x すれば良いのだった。まだコミットしたくない開発中のコードがローカルにあると少し面倒だが、どう考えてもこれが自然であった…
続く…
関連付けるテーブルは同じなのだが、条件によって別のオブジェクトとして関連付けるレコードを決定する方法がないか探してみた。
具体的に言うと、現在、次のようなテーブルがあって、
本のタイトル（簡単のために本の情報をタイトルだけとしている）とコメントが格納できます。ここでコメントの種類が増えて、ネタばれコメントを追加したくなったとする。
一番素朴な方法は、booksテーブルにnetabareカラムを直接追加してcommentカラムと同じ様に持てばいいわけだが、そもそもコメントは本の情報ではないし、ネタばれコメントにいたっては更にそうだ。
そこでコメントを別テーブル化したくなる。
とかするわけであるが、これだとモデルクラスとテーブルが2つ増える。
コメントとネタばれは、ユーザの用途は違うがDBに持つ情報としてはほぼ同じであるので、commentsテーブルは共通にできないだろうか。
has_one, belongs_toのリファレンスを見ると、その為に使えそうな:conditionsというオプションが存在した。
commentsテーブルは共通とし、comment_typeというカラムを用意し、これが1の場合、通常のcomment、2の場合ネタばれコメントとして進めてみる。まずはマイグレーションの作成だ。現在コメントはbooks.commentに格納されているので、データの移行も考えた頑張ったマイグレーションを作成する必要がある。
新テーブルcommentsの追加 books.commentからcommentsにcomment_type=1でデータ移行 books.commentカラムの削除 commentsテーブルにbook_id,comment_typeの複合インデックス
ちょっと前になるが、RailsによるアジャイルWebアプリケーション開発 第2版
Rails本はこの第1版に始まり、いろいろ買ったが、やはり一番参照したのはこの第1版だった。内容が古い分（0.9～1.0あたりか）、Railsの基本を知るのにとても良かったと思う。
Rails開発のコツもだいたい理解したし、あとはWebの情報でほぼ大丈夫だろうから第2版はいらないかなと思っていたのだが、本屋で手に取ってみると欲しくなる（笑）内容は第1版とほとんど同じで、最初に実際にWebアプリケーションをアジャイルに開発しながらの様子を実況風に説明し（全体の1/4程度）、その後、各機能の詳しい説明となっている。Railsのバージョンも今、最も使われているであろう1.2が中心なので直接コードのサンプルが役に立つと思われる。
ただ現在もRailsは進化の途中なので、新しいとは言っても、すでに古くなっている部分もある。そこは書籍の弱点でいかんともしがたいが、初めてRailsをやってみようという方のための参考書としてはこれが一番と断言できる。
さて私はなんでまた、そんな第2版を買ってしまったのかというと、まず第1版には索引に大きな不満があった。本の内容は非常に素晴らしかったが、索引は全く使えなかったのだ。なにか調べようとしても索引から知りたい事へたどり着けない。それが最も気になっていたので、本屋で第2版を手に取った際も、真っ先にチェックしたのは索引だ。
今回の索引は良くできている（というかこれが普通かも知れないが…）。第1版で索引に割かれているページ数は13ページに対して、第2版では倍増、とまではいかないも23ページ。しかしフォントが小さくなっていることと、余白が少なくなっていることも鑑みると、おそらく倍以上の情報量となっているはずだ。また第1版では技術本としてはあり得ないほど、リファレンス的な使い方ができなかったのが、第2では本文で説明されているほぼ全てのメソッド名や名前がちゃんと載っている。おそらく第1版以降に数多く出版されたRails本の中でも、最も優れた索引だと思う。
また、第1版では付録であったマイグレーションの説明が、ちゃんと1章割かれていたり、概要の1節だったActiveSupportの説明にやはり1章割かれていたり、RJSの説明が増えていたり。
さらに以前（と言っても1年ちょっとしか経ってない）とは流行が変わってしまったRailsの本番環境についての説明も大きく修正されていて使えるものになっている。
全体のボリュームも100ページ以上、繰り返すが余白が少なくなっていることも考えると内容はかなり増えていると思われるが、驚いたことに本の厚さは薄くなっている。これは紙を薄くして実現したようだ。ページの捲り心地やキーボードの手前に開いた状態で置いて参照する際にも安定しやすく、地味だが良い改良点だと思う。値段は\3,800-から\4,200-へ上がってしまったが、内容を考えれば全く不満はない。
長々と書いてしまったが、そんなわけで、新しいRailsによるアジャイルWebアプリケーション開発 第2版
