Masatomo Nakano Blog - Web開発を極める

Rails 3 + mongoDB + haml + RSpec + jQuery のインストール - 1

2010-07-11T02:44:07Z

会社用の、小物Webアプリを作ろうかと思い、せっかくなのでRuby on Rails 3でmongoDB使ってみようかな、と思い、とりあえず環境を作るところまでのメモ。

Rails 3 のインストール

とりあえず Rails 3 のインストール。現在の最新のbeta4を入れる。Bundlerで。Bundler自体のバージョンが0.9.26以上でないとダメみたいなんで、もしそれ未満しか入っていない場合にはBundlerのインストールからする。

プロジェクトのトップディレクトリとなるところを作成し、そこにGemfileを作る。

$ mkdir ~/workspace/hoge_prj
$ cd ~/workspace/hoge_prj

Gemfile

source 'http://rubygems.org'
gem "rails", "3.0.0.beta4"

rails 3のgemのインストール

$ bundle install

railsコマンドでrailsプロジェクトを作成する。

$ bundle exec rails new . --skip-activerecord --skip-testunit

このコマンド自体がGemfileをもう一度作る。上書きしてしまえばいい。MongoMapperを使う予定なので --skip-activerecord 、rspecを使う予定なので --skip-testunit を指定した。

次に、自分が必要なライブラリをGemfileに追加して、もう一回 bundle install する。

今回は、

gem "mongo_mapper"
gem "bson_ext"
gem "rails3-generators"
gem "haml"
gem "rspec-rails", ">= 2.0.0.beta.13", :require => nil
gem "factory_girl", :require => nil

を追加した。 rspec / haml / factory_girl は普段も使ってるのであまり考えずにそのまま使ってみる。Rails 3では、rspec 2が必要らしい。

$ bundle install

次に、config/application.rb を開いて、

config.generators do |g|
  g.orm :mongomapper
  g.template_engine :haml
  g.test_framework  :rspec, :fixture => true
  g.fixture_replacement :factory_girl, :dir => "spec/factories"
end

をそれっぽいところに書く。

rspecとhaml、jqueryの関連ファイルを作成する。

$ ./script/rails g rspec:install
$ ./script/rails g haml:install 
$ ./script/rails g jquery:install

mongoDBの接続情報が必要なので、それを config/mongodb.yml とかに書き、それを読ませるinitializerも書く。

今回は Mac上にインストールしたmongoDB を使っている。

config/mongodb.yml

base: &base
  adapter: mongodb
  host: localhost

development:
  <<: *base
  database: hoge-development

test:
  <<: *base
  database: hoge-test

production:
  <<: *base
  database: hoge-production

config/initializers/mongodb.rb

db_config = YAML::load(File.read(Rails.root.join("config", "mongodb.yml")))

if db_config[Rails.env]
  mongo = db_config[Rails.env]
  MongoMapper.setup(db_config, Rails.env, :logger => Rails.logger)
end

これで、ほぼインストール完了。 rails3-generators のおかげで mongo_mapper を使った scaffold を作ることもできる。

$ ./script/rails g scaffold entry title:string body:string
      invoke  mongomapper
      create    app/models/entry.rb
      invoke    rspec
      create      spec/models/entry_spec.rb
      invoke      factory_girl
      create        spec/factories/entries.rb
       route  resources :entries
      invoke  scaffold_controller
      create    app/controllers/entries_controller.rb
      invoke    haml
      create      app/views/entries
      create      app/views/entries/index.html.haml
      create      app/views/entries/edit.html.haml
      create      app/views/entries/show.html.haml
      create      app/views/entries/new.html.haml
      create      app/views/entries/_form.html.haml
      invoke    rspec
      create      spec/controllers/entries_controller_spec.rb
      create      spec/views/entries/edit.html.haml_spec.rb
      create      spec/views/entries/index.html.haml_spec.rb
      create      spec/views/entries/new.html.haml_spec.rb
      create      spec/views/entries/show.html.haml_spec.rb
      create      spec/helpers/entries_helper_spec.rb
      create      spec/routing/entries_routing_spec.rb
      invoke      rspec
      create        spec/requests/entries_spec.rb
      invoke    helper
      create      app/helpers/entries_helper.rb
      invoke      rspec
Plural version of the model detected, using singularized version. Override with --force-plural.
      invoke  stylesheets
      create    public/stylesheets/scaffold.css

とりあえず、コンソールからレコード (mongoDB風に言うとドキュメント)が作成できるか確認してみる。

% ./script/rails console
Loading development environment (Rails 3.0.0.beta4)
irb(main):001:0> Entry.create!(:title => "HOGEHOGE", :body => "Hello")
=> #<Entry created_at: Wed, 30 Jun 2010 22:24:06 UTC +00:00, body: "Hello", title: "HOGEHOGE", updated_at: Wed, 30 Jun 2010 22:24:06 UTC +00:00, _id: BSON::ObjectID('4c2bc406a90e08bf25000001')>
irb(main):002:0>

簡単！

本当に保存されたか、mongoシェルで確認してみると、

% ~/somewhere/mongodb-osx-x86_64-1.5.3/bin/mongo
MongoDB shell version: 1.5.3
connecting to: test
type "help" for help
> use hoge-development
switched to db blog-development
> db.entries.find()
{ "_id" : ObjectId("4c2bc406a90e08bf25000001"), "created_at" : "Wed Jun 30 2010 23:24:06 GMT+0100 (BST)", "title" : "HOGEHOGE", "body" : "Hello", "updated_at" : "Wed Jun 30 2010 23:24:06 GMT+0100 (BST)" }
>

入ってる！

サーバを起動して、画面でも見てみる。

config/route.rb に、

resources :entries

と、とりあえず書いて、

$ ./script/rails server

ブラウザで http://localhost:3000/entries/ を開いて確認。

なんとも面白くないいつもの scaffold がちゃんとmongoDBで動いているのが確認できる。

とりあえずここまでで、RSpec / factory_girl あたりを次回。

参考：
http://www.mongodb.org/display/DOCS/Rails+3+-+Getting+Started
http://paulbarry.com/articles/2010/01/13/customizing-generators-in-rails-3
http://groups.google.com/group/mongomapper/browse_thread/thread/cd89810b98eb7abf
http://github.com/rspec/rspec-rails
http://stackoverflow.com/questions/3004489/mongodb-initialization-error-in-rails

Rails 3 + mondoDB + HAML + Rspec + Jquery のインストール - 2

2010-07-11T02:44:07Z

前回の続き。

主に FactoryGirl と MongoMapper の話。基本的に何も考えなくてもそのまま使えるのだけど。

まず、設定。

spec_helper.rb で、

config.use_transactional_fixtures = true

を

config.use_transactional_fixtures = false

にする。そうしないと、ActiveRecord::TestFixtures が呼ばれてしまうのだけど、ActiveRecordを入れてないので落ちる。

そもそもMongoDBにはトランザクションとかないのでfalseでいい。

後は、ActiveRecordで使う場合と同じように、FactoryGirlの定義の読み込みを spec_helper.rb の中で行う。

Factory.find_definitions

mongoDBにはトランザクションがないので、テストの前にデータを自分で消しておいたほうがいいだろう。

config.before(:each) do
  MongoMapper.database.collections.each {|collection| collection.remove}
end

全体的にはこんな感じ。generatorが作ったものに、上記変更を入れただけ。

Dir["#{File.dirname(__FILE__)}/support/**/*.rb"].each {|f| require f}

require 'factory_girl'
Factory.find_definitions

RSpec.configure do |config|
  # == Mock Framework
  #
  # If you prefer to use mocha, flexmock or RR, uncomment the appropriate line:
  #
  # config.mock_with :mocha
  # config.mock_with :flexmock
  # config.mock_with :rr
  config.mock_with :rspec

  # config.fixture_path = "#{::Rails.root}/spec/fixtures"

  # If you're not using ActiveRecord, or you'd prefer not to run each of your
  # examples within a transaction, comment the following line or assign false
  # instead of true.
  config.use_transactional_fixtures = false

  config.before(:each) do
    MongoMapper.database.collections.each {|collection| collection.remove}
  end
end

試しに一個テストを書いてみる。

まず、generatorがEntryクラスのFacotryの雛形も作ってくれているので、それの確認。

File: spec/factories/users.rb

Factory.define :entry do |f|
  f.title "MyString"
  f.body "MyString"
end

簡単なお試し用のテストを書いてみる。(テスト自体に意味はない)

describe Entry do
  it "should create 10 entries" do
    10.times { Factory(:entry) }
    Entry.count.should == 10
  end
end

書いたテストの実行

$ bundle exec rspec spec/models/entry_spec.rb
.

Finished in 0.03308 seconds
1 example, 0 failures

すばらしい！

FactoryGirlで、MongoMapper::Document同士のassociationも問題なく書ける。(ただし、MongoMapper::EmbeddedDocument から親Documentへのassociationはうまく作ってくれなかった(正格には作ってくれるんだけど、Saveされない))

こんな感じで、Rails 2 + ActiveRecord時代とほとんど変わらない環境が Rails 3 + MongoMapper で、できたかな。

最近のmongoDB翻訳

2010-07-08T01:15:06Z

しばらくさぼってたんですが、ちょっとずつ再開してます。

ただ、オリジナルのドキュメントの更新頻度がずいぶんと高いので、しばらくは新規のドキュメントはやらずに、既存のドキュメントに追従していくだけにしようと思ってます。とりあえず導入の部分から、ある程度使いこなせるまでの部分だけに集中しようかな、と。

思っていたよりあちこちからリンクされているようで、変に古いドキュメントがあるのは逆にmongoDBにとってマイナスなんで。

とりあえず、以下の超基本ドキュメントを最近更新しました。

Mac OS X で mongoDB

2010-07-01T21:55:40Z

出張とか旅行で家を空ける機会が多かったので久しぶりになってしまった。

普段はFreeBSDをサーバ用途で使っているのだけど、Macでも手軽に実行できるので紹介してみる。ダウンロードして展開する以外、特にインストール作業いらない。もろもろなパッケージ管理ツールみたいなものを使ってもいいけど、遊ぶぐらいならこれで十分かな。

とりあえず、ここから適当にダウンロード。(OS X 64-bit の 1.5.X とか)

次に、mongoDBのデータを入れるディレクトリを作成。

$ mkdir /somewhere/mongodb_data

後は、ダウンロードして展開したmongodを実行するだけ。

$ /foo/bar/mongodb-osx-x86_64-1.5.3/bin/mongod --dbpath=/somewhere/mongodb_data

オプションを何もつけないとフロントエンドで実行される。バックグランドで実行したい場合には、 --fork --logpath=/somewhere/mongodb.log とか付ける。

接続できるか、mongoコマンドで確認

$ /foo/bar/mongodb-osx-x86_64-1.5.3/bin/mongo
MongoDB shell version: 1.5.3
connecting to: test
type "help" for help
>

エラーが出ないでプロンプトが出たら完了。

後はチュートリアルをやってみるもよし、お好みの言語でいじるもよし、mongoライフを楽しみましょう。

今週のMongoDB翻訳

2010-03-27T03:05:39Z

日本滞在中でいまいち調子が狂う。今週は更新のみ。

チュートリアル - 内容的に大きな変更なし。ObjectIDの作成に、ObjectID() を使うようになった。
コネクション - 内容的に大きな変更なし。
アップデート - $ ポジションオペレータが追加
インデックス - ドキュメント自体をインデックスとして使うところの更新

TDDを真面目にやってみて気付いたこと

2010-03-23T01:02:03Z

何を今更、なことかもしれないないのだけど、もしかしたらこれを知ることでTDD(Test-driven development)をやることのハードルが一気に下がる人がいるかな、と思ってメモ。特に、ある程度プログラマとして経験があるけど、どうもTDDは慣れないという人向き。

“TDDとは、TDD以前に脳内や機上でやっていたことをコードに落とすことに過ぎない”

このことが解ってから、TDDをするのが一気に苦痛ではなくなり、むしろ楽しくなった。

TDDでなくても、コーディングをするとき、temporaryなテストコードを書いたり、目視でのチェックはしたりするものだろう。たとえば、一時的に変数の値をハードコードして挙動を変えてみて、それを目視で確認したり、printデバッグとかもその一部だ。

つまり、このtemporaryなコードや目視している部分をpermanentにするのがTDDで書くテストコードだということがわかった。

TDDであろうが、なかろうが、考えないといけないこと、やらないといけないことはたいして変わらない。たいして変わらないなら、テストコード書いておいた方が得。

テストコードがあれば、チーム内で技術や知識の共有もテストコードを通じてしやすくなるし、コードレビューだって、コードとテストがセットの方がやりやすいだとやりやすい。

単純に、テストファーストでやらないのは色々と損だよね。って感じ。

後は、おまけみたいなものなんだけど、自分でTDDしたり、人のTDDでしたコードを見たりして、いくつか思ったことをメモ。

1. TDDでコードや設計がきれいになるのは、プログラマをさぼらせないから

いいコードでないとテストが書きにいので、「いいコードを書くのをさぼれない」ってことになって、結果的にきれいなコードにはなりやすい。人はさぼるものなので、これ重要。

2. TDDのUnit Testは自作自演

TDDでは、テストコードを書く人と実際のコードを書く人は通常同じなので、どうしても自分の都合のよいテストコードを書いてしまいがち。また、仕様を誤解してても、その誤解したままのテストコードになって、テストは通る。もちろん、自作自演だからこそ、1.の恩恵を得れる。

3. ある程度の範囲に影響するリファクタリング時の動作の保証は微妙

Unit Testは、どちらかというとホワイトボックス的なテストなので、リファクタリング時にもあわせて変えないといけないことも多い。そのため、ある程度の範囲を直す場合、Unit Testだけでは不十分。動作の保証という意味ではブラックボックス的なcucumberみたいなテストも組み合わせないと厳しい。(もちろん自動化以外のテストも必要だけど、これは別の話)

これはTDDってよりUnit Testの話か。

4. テスト自体の知識も大切

当然なんだけど、TDDをするようなツールの知識だけではなくて、ある程度のテストの知識がないと良いテストは書けない＝良いTDDはできない。テストの知識ってのはCOBOLの時代(もっと前かな)から変わってないような知識。境界値チェックとか(ちなみに、こういうの勉強するのに情報処理試験の勉強ってなかなか侮れない)。

単純な例を挙げると、ある条件での平均値を求める、と言ったコードに対するテストで、テストコードで使うテストデータがその「ある条件」のものしか用意してなく、「ある条件」以外のものを用意してないといったケース。この場合実際のコードの方に「ある条件」が抜けていてもテストは通ってしまう。超基本なんだけど、それすらできてないテストを見かける。

単体テスト仕様書を何百枚も手書きしていた世代のノウハウをゲットすべき(関係ないけど、Key-Value Storeな方面でもあの世代のノウハウって役に立ちそう)。

ちょっと逸れるけども、知識どうこうではなくて、手を抜いてしまっているダメなテストももちろんダメ。

たとえば、Rubyとrspecでの例になってしまうが、 foo.should_not be_nil を安易に使いすぎるとか。foo.should == something とちゃんと書けるようなケースなのに、should_not be_nil で手を抜く。

他にも、Mock/Stubを使いすぎて、何もテストしてない状態になっている、とか。笑い話みたいだけどたまにある。

こういうのは「自分が何をテストしているのか」というのをしっかり意識しないと陥りがち。

そういえば、「TDDは品質のためじゃない！」と、でかい声で言ってる人でも、多分このぐらいのことは当然やってる人たちなんだろうけど、なんか誤解は与えそうだね。とは思った。

今週のMongoDB翻訳

2010-03-20T04:29:22Z

地道にやってます。

新規

更新

集約 (aggregation)
他にもあった気もする

aboutの下とcontributorsの下をやりたいんだけど、手が回らない。

Flash嫌い？

2010-03-16T02:23:08Z

今の会社に入るまで、自分も普通にFlashが嫌いだったのだけど、自分が関わるようになって「まー、ありかな」と思うところもあるのでメモ。アニメーションとかゲームとかでばりばりFlashっていう方面ではなくて、アプリケーションの一部としてFlashを使う話。

まず自分のFlashに対する経験を書いてみる。

Flashとバックエンド(サーバサイド)の間に立ってコミュニケーションをするモジュールをFlexで作った。というのが一番技術的にFlashに近づいたところかな。

これを作る前はFlashが直接バックエンド(またはJavascript経由でバックエンド)と直接コミュニケーションしていたんだけど、色々と問題(実装したFlash毎に通信方法が違ったり、通信環境のエラー処理をFlash側にそれぞれ書かなかったりいけなかったり)が出てきたので間にデータハンドリング用の層を作った。また、Flashから直接サーバサイドやJavascriptとやりとりするのを禁止にして、Flashのプログラマの人がpureなFlashの制作に集中できるようにした。

それと、ActionScriptというところで言うとAdobe Flexでそれなりの規模のアプリケーションは作ったことはある。

そんな感じなので、ActionScriptはそれなりにわかるけど、Flash固有のこと(タイムラインとか)はよくわかってないと言った感じ。でも、なんとなくFlashがどう動いているかというのはわかっているつもり。それと、それなりの数のFlashのプログラマと一緒に働いてきて、Flash開発とFlashの開発者の人の傾向みたいなものもなんとなくわかっているつもり。

で、自分が感じている開発視点でのFlashの強みは、

生産性は高い？これは正直微妙なところもある。ただ、HTML+Javascript+CSSが好き(でFlashが嫌い)な人は「それ、HTMLでもできるよ」ってすぐ言うのだけど(エフェクトとかね)、やっぱり生産性、保守性という面ではまだまだFlashには敵わないかな、とは思っている。もちろんFlashが得意なところに限る。テキスト処理みたいな苦手なところで使うと一気に生産性ダウン。
人材を確保しやすい。これも微妙か。数年前は、html+Javascript+cssで、きれいに動きを付けられる人を探すのは、Flashな人を探すより大変だった。最近はそうでもないのかなー。
オーディオやビデオの再生や録画と言ったところはまだまだFlashでしか(簡単に)できないことも多い。
ブラウザ間の互換性を(あまり)気にしなくていい。

弱いところは、

テスト系のツールが遅れてる。Unit Testがあるぐらい？画面系の自動テストも、商用含めいくつかあるみたいだけど、あまり標準的なものもなく、結局未だに手でテストしてる。TDDだBDDだ言って盛り上げっているところから見ると、あれ？って感じ。
SCMが使いづらい。Flashだとまだバイナリファイルで管理している部分(fla)があって、SCMでの管理が非常にしづらい。Flexならほぼ全部テキストベースのコードで行けるのだけどね。このご時世に「いつの間にかファイルが先祖返りしてた」とかありえない。
バックエンドのことまで考えられる技術者が少ない？これはもう半分諦めて、インタフェースの部分はバックエンドの技術者が作ってしまった方がよさそう。
テキスト系が弱すぎる。Flashというより、Flash Playerの問題か。この時代に、もっさり感のあるテキスト入力とかちょっと考えられない。
ブラウザ間の互換性はあまり気にしなくていいけど、Flash Playerのバージョン間の互換性は知っておく必要がある。

うーん、「みんな悪く言うけど、Flashそれなりにいいもんだよ！」と思って書き始めたんだけど、こうやって書き出すと悪いところが目立つようになってしまった。あらら。

今後は、Flashが強いところをピンポイントでモジュールとして作り、htmlとJavascriptの中でそれを調和させつつうまく使う、というのが正解なんだろうな。Adobeの中の人も同じようなこと言ってたような気がするけど。で、その辺のいい感じのフレームワークみたいのがあればいいのにね。

そうなってくると、Flash技術者の人はhtmlとかJavascript/CSSの知識も持っていないとツラそう。いかにhtmlと協調して、違和感なく動くようなFlashモジュールを作れるか、というのがポイントになってくるので。

なんとなく、メモっておきました。