[{"title":"Capybara ate Swinger","_score":null,"link":"http://jeffkreeftmeijer.com/2011/capybara-ate-swinger","content":"\n      \n         About three months ago, I released Swinger to add RSpec driver swapping to Capybara. \n \n This idea wasn\u2019t new, Capybara had doing it for Cucumber for quite some time. Cucumber has this nice tagging thing that allows you to hook in and do cool stuff like that. \n RSpec didn\u2019t have a feature like that until 2.0, when it released the metadata feature. That made it possible to pass arbitrary metadata to examples or example groups, allowing you to tag examples. Like in Cucumber. But better. \n Using that, I built Swinger for a big project we were working on at 80beans. It was still a bit of a monkey patch, since RSpec didn\u2019t really provide a way to access an example\u2019s metadata in the around hook, but it worked pretty well. \n Not long after relasing it as a separate gem, I turned Swinger into a Capybara pull request. It was still a monkey patch, so @dchelimsky did a patch for RSpec to expose the metadata in around hooks, which made it possible for @jncoward to eventually built a cleaner version of the driver swapping idea into Capybara. \n Driver Swapping in Capybara, without the crap \n Now, since Capybara version 0.4.1 0.4.1.1, it supports driver swapping out of the box. Here\u2019s how to get it working. \n First, in the file where you set up Capybara (that\u2019s spec/acceptance/acceptance_helper.rb if you\u2019re using Steak). Include Capybara\u2019s RSpec helper file: \n  require 'capybara/rspec'\n \n \n Now, just like with Swinger, you can tag your examples with a specific :driver: \n  it \"does fancy stuff\", :driver => :selenium do\n  # test fancy stuff\nend\n \n \n Of course you can also use this on example groups: \n  context \"fancy stuff\", :driver => :rack_test do\n  # fancy examples\nend\n \n \n If you set Capybara.javascript_driver, you can even tag examples that need a javascript capable driver like this: \n  Capybara.javascript_driver = :selenium\n\nit \"does fancy stuff\", :js => true do\n  # test fancy stuff\nend\n \n \n This officially means I stopped maintaining Swinger and I urge you to update Capybara to 0.4.1.1. Thanks to everyone who helped out building Swinger and getting it into Capybara, it certainly made my test suites a lot faster. \n      \n    ","summary":"Remember Swinger, the Capybara RSpec driver swapper? Capybara can now swap drivers out of the box.","published_on":"2011-02-06T23:00:00Z"},{"title":"Capybara driver swapping on RSpec with Swinger","_score":null,"link":"http://jeffkreeftmeijer.com/2010/capybara-driver-swapping-on-rspec-with-swinger","content":"\n      \n         Swinger is not maintained anymore, since its functionality is built into Capybara. Check out Capybara ate Swinger for more information. \n If you\u2019ve been doing the acceptance testing dance for a while, you probably know it can get slow pretty fast. Not necessarily in every driver, but since you wanted awesome javascript stuff in your application you\u2019ve equipped Capybara with Selenium to actually run your tests in an actual browser. Ouch. \n The javascript interaction in your application is minimal, but can\u2019t be tested without Selenium. The worst part is that it\u2019s only ten specs. Wouldn\u2019t it be awesome to only use Selenium for those instead of the whole suite? \n \n If you\u2019re using Cucumber, Capybara\u2019s got your back, making it possible to use Cucumber\u2019s tagging feature to simply specify which driver you want to use per example, effectively allowing your Capybara to have multiple partners in one session. \n But since you like to think you\u2019re a rebel and rather test your application in pure Ruby, you\u2019re using plain RSpec (maybe even with Steak). So you need to do stuff like this when you want to switch drivers: \n  # `scenario` is an alias for `it`, provided by Steak\n\nscenario 'get a nice greeting' do\n  Capybara.current_driver = :selenium\n  visit homepage\n  page.should have_content 'Welcome'\n  Capybara.reset_current_driver\nend\n \n \n Swinger \n Swinger is a really simple Capybara extension that aims to make this a bit less horrible to look at. Using the new metadata feature in RSpec 2, you can simply set your :driver per scenario or context: \n  scenario 'get a nice greeting', :driver => :selenium do\n  visit homepage\n  page.should have_content 'Welcome'\nend\n\ncontext 'when logged in', :driver => :rack_test do\n\n  scenario 'get a nice greeting' do\n    visit homepage\n    page.should have_content 'Welcome back'\n  end\n\n  scenario 'see the logout link' do\n    visit homepage\n    page.should have_content 'Logout'\n  end\n\nend\n \n \n It also adds the using_driver method to Capybara, allowing you to execute a block using a specific driver. This is especially useful when you\u2019re (still) not on RSpec 2 and can\u2019t use the new metadata feature: \n  scenario 'get a nice greeting' do\n  Capybara.using_driver :selenium do\n    visit homepage\n    page.should have_content 'Welcome'\n  end\nend\n \n \n Installing Swinger is easy. Simply add it to your Gemfile and require it in spec_helper.rb. \n A patch for Capybara? \n Let me know how you like it and be sure to create an issue on Github, send me a Github message or an email if you have any ideas or run into any issues. Of course you can always fork the project and send me a pull request or a patch via email. \n Oh, one last thing: I know this is a pretty minimal gem, but I wanted to just get it out there to use it myself and see if it needs any improvement before maybe turning it into a patch for Capybara. \n Would you like this to be part of Capybara or do you prefer keeping this a separate gem? Please let me know! \n      \n    ","summary":"Introducing Swinger: a really simple extension that allows your Capybara to have multiple partners in one session.","published_on":"2010-10-31T23:00:00Z"},{"title":"Acceptance testing using Capybara's new RSpec DSL","_score":null,"link":"http://jeffkreeftmeijer.com/2011/acceptance-testing-using-capybaras-new-rspec-dsl","content":"\n      \n         I\u2019ve been using Steak for almost a year now. It\u2019s an RSpec extension by @cavalle to allow you to get up and running doing acceptance testing. Since then I wrote and talked about it a lot and it definitely helped me to get into acceptance testing without having to get out of RSpec and writing tests in English. \n What a lot of people don\u2019t know is that Steak is nothing more than a bunch of aliases and generators. This doesn\u2019t mean that it doesn\u2019t make your work easier or that it\u2019s a scam, but it\u2019s not a completely separate testing library. It\u2019s essentially just a tool to make it easier to get Capybara running on RSpec. \n  Carnivore Capybara!!!1 Roaargh! \n Back when Steak was first released, Capybara didn\u2019t have any of the nice RSpec helpers it does now. A lot has changed since. Besides the helpers, it got its own RSpec acceptance testing DSL recently, essentially eating Steak\u2019s functionality and turning it into a complete acceptance testing solution (on top of RSpec). \n Acceptance testing with Capybara \n The DSL is\u2019nt officially released yet, but it will be available in Capybara 1.0. Right now, you\u2019ll have to get it from git if you want to use it. \n Let\u2019s say you\u2019re working on a Rails project using Bundler. Simply add RSpec and Capybara to your Gemfile: \n  group :test do\n  gem 'rspec-rails'\n  gem 'capybara', :git => 'git://github.com/jnicklas/capybara.git'\nend\n \n \n After running bundle install, set up RSpec like you\u2019re used to: \n  $ rails g rspec:install\n      create  .rspec\n      create  spec\n      create  spec/spec_helper.rb\n \n \n Capybara doesn\u2019t have any generators for its new DSL, but that shouldn\u2019t be a problem. Setting it up is quite easy, just add a file named spec/acceptance/acceptance_helper.rb. In this file, we\u2019ll require spec/spec_helper.rb to make RSpec available. We\u2019ll also require Capybara\u2019s RSpec helper file: \n  require 'rspec'\nrequire 'capybara/rspec'\n \n \n Capybara will now automatically hook into RSpec and allow you to write your first test. See? I told you we weren\u2019t going to need any generators. Let\u2019s write a spec named spec/acceptance/articles_spec.rb: \n  require 'acceptance/acceptance_helper'\n\nfeature \"Articles\", %q{\n  In order to have an awesome blog\n  As an author\n  I want to create and manage articles\n} do\n\n  background do\n    Article.create!(:title => 'One')\n    Article.create!(:title => 'Two')\n  end\n\n  scenario \"Article index\" do\n    visit '/articles'\n    page.should have_content('One')\n    page.should have_content('Two')\n  end\n\nend\n \n \n As you can see, we\u2019re using methods like feature, background and scenario instead of context, before and example, just like we did in Steak. Now, you can run your new spec like any other RSpec test: \n  $ rspec spec/acceptance/articles_spec.rb\n \n \n There you go. A complete acceptance testing solution including the acceptance testing slang, without generators and just a couple of lines of code. What do you think? Do you have any ideas to make this more awesome? Definitely let me know! \n      \n    ","summary":"Capybara turned carnivore and devoured Steak.","published_on":"2011-02-20T23:00:00Z"},{"title":"Steak: because Cucumber is for vegetarians!","_score":null,"link":"http://jeffkreeftmeijer.com/2010/steak-because-cucumber-is-for-vegetarians","content":"\n      \n         Capybara has an RSpec DSL now, allowing you to steak-acceptance testing without Steak. Be sure to read Acceptance testing using Capybara\u2019s new RSpec DSL too. \n I\u2019m not going to tell you why you should write acceptance (or integration) tests, but you should. I used Cucumber for a while now and I love it, but I think writing my tests in a business-readable domain-specific language and translating them into Ruby using step definitions is a bit too much sometimes. And I\u2019m not a vegetarian. \n Luckily, we have Steak by @cavalle: \n \n \n \u201cSteak is like Cucumber but in plain Ruby. No explicit givens, whens or thens. No steps, no English, just Ruby: RSpec and Steak. That\u2019s all.\u201d \n \n Right now the stable version of Steak only works with Rails 2.x and RSpec 1.x, but there\u2019s a Rails 3 branch where some work is being done to support Rails 3.x and RSpec 2.\u00d7. I\u2019ve been using that one, but this article should also be fine for you when you\u2019re on Rails 2.\u00d7. \n Installation \n OK, throw this into your Gemfile (I\u2019m specifying the 0.4.0.a4 release here, that\u2019s the most recent alpha release from the rails3 branch). Also, I\u2019ll be using Capybara for this example: \n  group :test do\n  gem 'steak', '0.4.0.a4'\n  gem 'capybara'\nend\n \n \n And install your bundle: \n $ bundle install \n Or \u2014 if you\u2019re using Rails 2.x \u2014 put this in config/environment.rb (Just using the stable Rails 2 release of Steak here): \n  config.gem 'steak'\nconfig.gem 'capybara'\n \n \n And run: \n $ rake gems:install RAILS_ENV=test \n Now you can use the Steak generators to set everything up. You have to specify which driver you\u2019re using (Steak also has a generator for Webrat): \n $ rails generate steak --capybara # or -- webrat \n Please remember to use script/generate instead of rails generate when on Rails 2.\u00d7. \n The generator created the spec/acceptance directory in your project, in which you can find acceptance_helper.rb and the support directory. The support directory holds paths.rb \u2014 which should be familiar if you\u2019ve used Cucumber before \u2014 and helpers.rb. \n Acceptance specs \n Now, let\u2019s write our first acceptance spec \u2014 no, we\u2019re not calling it a \u201cfeature\u201d. It\u2019s a spec. \u2014 by using another generator (I\u2019m creating an articles spec here): \n $ rails generate acceptance_spec articles \n Steak generated spec/acceptance/articles_spec.rb, which looks like this: \n  require File.dirname(__FILE__) + '/acceptance_helper'\n\nfeature \"Feature name\", %q{\n  In order to ...\n  As a ...\n  I want to ...\n} do\n\n  scenario \"Scenario name\" do\n    true.should == true\n  end\n\nend\n \n \n If you\u2019re a Cucumber user, the feature description should look familiar. I\u2019ll try to describe what I\u2019m doing like this: \n  feature \"Articles\", %q{\n  In order to have an awesome blog\n  As an author\n  I want to create and manage articles\n} do\n \n \n Great. On to our first scenario. In the articles index we want to show all articles in a list. \n  scenario \"Article index\" do\n  Article.create!(:title => 'One')\n  Article.create!(:title => 'Two')\n  visit article_index\n  page.should have_content('One')\n  page.should have_content('Two')\nend\n \n \n First, I create two articles called \u201cOne\u201d and \u201cTwo\u201d (please, use a tool like Machinist for that). Then I visit article_index and check if the article titles show up. Really simple. \n The last thing to do to get this thing running is to create the path for article_index in spec/acceptance/support/paths.rb: \n  module NavigationHelpers\n  def homepage\n    \"/\"\n  end\n\n  def article_index\n    \"/articles\"\n  end\nend\n \n \n Simple, right? I\u2019m not going to walk you through building and testing this application here right now, but I think you get the point. \n Minimalist acceptance testing \n Steak just provides some aliases (like scenario and feature) for RSpec\u2019s methods \u201cproviding you with the language of acceptance testing\u201d. Here\u2019s a snippet from  Steak\u2019s library: \n  module Spec::Example::ExampleGroupMethods\n  alias scenario example\n  alias background before\nend\n\nmodule Spec::DSL::Main\n  alias feature describe\nend\n \n \n So, if you know your RSpec, the only thing you\u2019ll have to do is dive into Capybara (or Webrat) for a bit and you\u2019ll be writing acceptance specs in no time. \n Running your spec \n You might have guessed, but running your acceptance specs is exactly the same as running any other spec. After all, it\u2019s just a minimal layer on top of RSpec: \n $ spec spec/acceptance/articles_spec.rb \n Cucumber vs Steak? \n Cucumber is highly focused on creating a business-readable DSL, and does so perfectly. I understand the thought behind making stakeholders able to read what\u2019s going on in their projects, but I wonder how many people actually do this. Also, one might argue that \u2014 from a Ruby programmer\u2019s perspective \u2014 Steak\u2019s specs are in fact more readable than Cucumber\u2019s. \n Steak takes away the extra step of translating everything from English to Ruby and is incredibly easy to learn (especially when you have some RSpec experience). It\u2019s completely incomparable to Cucumber though and which one to choose is simply a matter of taste. And I love me some Steak. \n      \n    ","summary":"Minimalist acceptance testing using pure Ruby with Rspec, Steak and Webrat or Capybara.","published_on":"2010-05-02T22:00:00Z"},{"title":"Introducing Tapir: Simple search for static sites","_score":null,"link":"http://jeffkreeftmeijer.com/2011/introducing-tapir-simple-search-for-static-sites","content":"\n      \n         \nNote: I stopped working at 80beans, so I can\u2019t help you with any issues anymore. You can always send an e-mail to Tapir\u2019s support e-mail address if you need help, though.\n \n Static site generators like Jekyll allow you to generate your whole website or blog as static HTML files and put it online without having to use a database or even building an actual application. \n While being static has a lot of advantages, it can be quite a pain in some situations. Since you don\u2019t have a database, you can\u2019t build a commenting system so your readers can comment on what you write, for example. Some other things are analytics and contact forms. Luckily, there are really nice solutions \u2014 like Disqus, Google analytics and Wufoo \u2014 that allow you to implement these features using a simple javascript snippet. \n A feature I really wanted in my website was search, since the archive grew quite a bit and it became impossible to find an article without knowing its title, so I started looking for a solution I could use. \n \n After asking around, it turned out Google\u2019s custom search is still the most used out there. The problem I ran into was that it takes you off the website you were searching on and takes you to a Google results page (complete with slightly irrelevant ads). \n I wanted a more elegant solution, with a nice JSON API that would allow me to build a search feature on my website using only javascript, but I found out that most of the existing search engines didn\u2019t have an API, made me put their logo on my website or gave me a request limit. \n After discussing this at 80beans, we decided to get some beers, order dinner and throw something together ourselves. After a couple of hours, we had a working prototype and we asked @ivanasetiawan to draw us an awesome Tapir and create a nice design for the website. We took a week to tweak and test the application before we released it into the wild. \n Tapir, go! \n Tapir is a simple application that indexes your RSS feed and uses Tire (which is powered by Elasticsearch, which is powered by Lucene) to index and search it. It gives you a straightforward JSON API that returns the results. \n After signing up and getting your token, you\u2019ll be able to use this API to search your site. For example, here\u2019s one of my results when searching for \u201cCapybara\u201d: \n [\n  {\n      \"title\":\"Capybara ate Swinger\",\n      \"published_on\":\"2011-02-07T05:00:00Z\",\n      \"content\": [the full article content],\n      \"link\":\"http://jeffkreeftmeijer.com/2011/capybara-ate-swinger\",\n      \"summary\":\"Remember Swinger, the Capybara RSpec driver swapper? Capybara can now swap drivers out of the box.\",\n      \"_score\":61.15513\n    }\n  ] \n Tapir will check your feed every fifteen minutes to see if there\u2019s anything new to index, but of course you can also ping it to update your search results immediately. \n Using that, you can build your own search feature, which requests its results from Tapir\u2019s API. If you want to give it a go, check out the one I implemented. \n What\u2019s next? \n Over the last week we\u2019ve been busy tweaking the search results and making the application more usable. We have a couple of plans to make Tapir more awesome, but we definitely need your help. If you start using Tapir, have a great idea or if you run into any issues, @tapirgo would be glad to hear about it or try help you out. \n While we built Tapir to search static sites, you can use it for anything that has an RSS feed, of course. @thedjinn created a news search that searches multiple feeds, like CNN and the Dutch NOS. If you end up doing something awesome we hadn\u2019t thought about before, be sure to let us know. \n Now, what do you think of Tapir? \n      \n    ","summary":"Wouldn't it be nice to have a service that indexes your RSS feed and allows you to search it using a JSON API?","published_on":"2011-05-08T22:00:00Z"},{"title":"Ever heard of Capybara's save_and_open_page method?","_score":null,"link":"http://jeffkreeftmeijer.com/2010/ever-heard-of-capybaras-save_and_open_page-method","content":"\n      \n         Every once in a while, when running acceptance tests, you get this weird failure and Capybara can\u2019t really tell you what\u2019s wrong either: \n  1) User registration should register successfully\n   Failure/Error: fill_in 'username', :with => 'jkreeftmeijer'\n   cannot fill in, no text field, text area or password field with id, name, or label 'username' found\n   # ./spec/acceptance/user_registration_spec.rb:46\n \n \n All we know now is that there\u2019s no \u201cusername\u201d field on the page, which doesn\u2019t really tell us anything. We could start our server and browse to the page manually or \u2014 when using Selenium \u2014 add a sleep right before the spec fails to get a quick glance at what\u2019s going wrong. Nasty. Don\u2019t do that. \n save_and_open_page \n When going through Capybara\u2019s source last week, I found the save_and_open_page method which does a great job at fixing this issue. As the name implies: it saves the page \u2014 complete with styling and images \u2014 and opens it in your favorite browser: \n  it 'should register successfully' do\n  visit registration_page\n  save_and_open_page\n  fill_in 'username', :with => 'jkreeftmeijer'\nend\n \n \n I hope this helps someone, it would have saved me a lot of time. \n      \n    ","summary":"For when you really need to see what's going on in your acceptance test.","published_on":"2010-11-17T23:00:00Z"},{"title":"Fuubar on RSpec 1.3.x, Cucumber & MiniTest","_score":null,"link":"http://jeffkreeftmeijer.com/2010/fuubar-on-spec-13x-cucumber-minitest","content":"\n      \n         Last week, I released an RSpec progress bar formatter called Fuubar and some cool stuff has happened since. \n Version 0.0.2 was released, which uses ruby-progessbar instead of progressbar and prints the bar using ==== instead of oooo. @iain_nl moved the progress bar two spaces to the right, a couple of bugs were squashed and Fuubar is eating its own dog food by using itself as its default formatter now. \n RSpec 1.3.x \n With a lot of help from @__NeX__, Fuubar got RSpec 1.3.x support today. It\u2019s in a separate legacy branch and it\u2019s not released as a separate gem right now. \n Installing it for RSpec 1.3.x should still be quite easy. Since you need to pull it in from git, you need to specify the repository url and branch name in your Gemfile: \n    gem 'fuubar', \n    :git => 'git://github.com/jeffkreeftmeijer/fuubar.git', \n    :branch => 'legacy'\n \n \n If you want to use Fuubar as your default formatter, put this in your spec/spec.opts file: \n --format Fuubar\n--color \n Cucumber and MiniTest \n A bunch of work has been done to build a Fuubar-like formatter for MiniTest by @mike_mayo, who has been building it into his MiniTest fork. Keep an eye on his blog for more information about the project. \n Also, there\u2019s a ready-to-use gem called fuubar-cucumber, released by @martinciu, so you can even use Fuubar when you\u2019re on Cucumber for acceptance testing. \n I\u2019m excited to see where this is going, Fuubar\u2019s being used in a couple of projects already (most notably Capybara and infinity_test) and nice ideas are popping up. Thanks for helping out, using it and spreading the word, everyone! \n Now, what would you like to see in Fuubar in the near future? \n      \n    ","summary":"Last week I released an RSpec progress bar formatter called Fuubar. Now it's running on RSpec 1.3.x, MiniTest and Cucumber.","published_on":"2010-11-21T23:00:00Z"},{"title":"Making RSpec stop operation immediately after failing","_score":null,"link":"http://jeffkreeftmeijer.com/2010/making-rspec-stop-operation-immediately-after-failing","content":"\n      \n         Imagine you\u2019re running your whole RSpec spec suite and the first or second spec fails. You have about two hundred specs to go, but you want to dive in and fix that first failure right away. You\u2019d probably interrupt the run to get the failure details to go fix them, right? \n While this works most of the time (you might get some problems interrupting the run when using Selenium) wouldn\u2019t it be awesome if RSpec could automatically stop and output when running into the first failure? \n \n Aside from a three year old thread in the rspec-users group, I couldn\u2019t find a lot of useful data. So I set out to write something myself. \n Fail-fast \n I started poking around in the RSpec source and accidentally stumbled on RSpec\u2019s generated documentation on Relish, where I found the fail_fast configuration option that got introduced in rspec-core 2.0.0.rc. It actually does exactly what I wanted to achieve. \n The fail_fast option will cause RSpec to immediately stop running your specs and output the failure details whenever it fails for the first time, giving you a nice speed boost when trying to fix some spec fails. Usage is pretty straightforward: \n  # spec/spec_helper.rb\n\nRSpec.configure do |c|\n  c.fail_fast = true\nend\n \n \n Command line support \n Since you probably still want to run your whole spec suite without using the fail_fast option from time to time, setting it in spec/spec_helper.rb isn\u2019t really a great option. So I added a command line option so you can use it whenever you want: \n  $ bundle exec rspec spec/ --fail-fast\n.F\n\nFailures:\n  1) Swinger should set the Capybara driver\n     Failure/Error: Capybara.current_driver.should_not == :rack_test\n\nFinished in 0.00479 seconds\n2 examples, 1 failure\n \n \n The --fail-fast option was only released yesterday as a part of RSpec 2.1, so don\u2019t forget to update. \n      \n    ","summary":"Discovering RSpec's fail_fast configuration option and command line argument","published_on":"2010-11-07T23:00:00Z"},{"title":"Setting up MongoDB, MongoMapper, GridFS, Devise & Carrierwave on OSX","_score":null,"link":"http://jeffkreeftmeijer.com/2010/setting-up-mongodb-mongomapper-gridfs-devise-carrierwave-on-osx","content":"\n      \n        \n           This is a guest post written by @matsimitsu. Robert is a Ruby programmer at 80beans and a serious MongoDB fanatic.\n          \nSorry, this article is a bit outdated. Lucky for you, @antekpiechnik wrote a really nice guide in which he uses Mongoid and Rails 3. Be sure to check that out too!\n \n For a little side project I wanted to experiment with MongoDB and GridFS on Rails 2.3.5, but it took me a while to get everything up and running. \n It wasn\u2019t really a problem with Mongrel, but as soon as Apache and Passenger came in the picture the problems began. \n The gems \n Development setup: \n  config.gem 'carrierwave'\nconfig.gem 'devise'\nconfig.gem 'mongo_mapper', :version => '0.7.0'\nconfig.gem 'mongomapper_ext'\nconfig.gem 'will_paginate'\n \n \n If you want to use GridFS with MongoDB, make sure you use MongoMapper 0.7.0, because later versions cause: \n mongo/GridFS not found \n Test setup: \n  config.gem 'rspec', :lib => 'spec'\nconfig.gem 'rspec-rails', :lib => 'spec/rails'\n\nconfig.gem 'machinist_mongo',\n  :version => '1.1.0',\n  :lib => 'machinist/mongo_mapper'\n\nconfig.gem 'faker'\nconfig.gem 'steak'\nconfig.gem 'capybara'\n \n \n MongoMapper \n To use MongoMapper add the following to your config/initializers: \n  # config/initializers/mongo_mapper.rb\n\n# load YAML and connect\ndatabase_yaml = YAML::load(File.read(RAILS_ROOT + '/config/database.yml'))\nif database_yaml[Rails.env] && database_yaml[Rails.env]['adapter'] == 'MongoDB'\n  mongo_database = database_yaml[Rails.env]\n  MongoMapper.connection = Mongo::Connection.new(mongo_database['host'], 27017, :pool_size => 5, :timeout => 5)\n  MongoMapper.database =  mongo_database['database']\nend\n\nif defined?(PhusionPassenger)\n   PhusionPassenger.on_event(:starting_worker_process) do |forked|\n     MongoMapper.connection.connect_to_master if forked\n   end\nend\n \n \n The PusionPassenger section can be removed if you are not planning to run this on Apache and Passenger. \n If you do plan to run it, make sure this is in your config. It will make sure new spawned Apache children still have a MongoDB database connection and prevent you from pulling out all your hair. \n You can now setup your config/database.yml config. Example: \n  # config/database.yml\n\ndevelopment:\n  adapter: mongodb\n  database: mmyapp_development\n  host: localhost\n \n \n Devise \n Setting up Devise is pretty easy, just use the following snippet: \n  # config/initializers/devise.rb\n\nDevise.setup do |config|\n  config.mailer_sender = \"info@example.com\"\n  config.orm = :mongo_mapper\nend\n \n \n And use it in your (user) model: \n  class User < Base\n  include MongoMapper::Document\n  include MongoMapperExt::Slugizer\n\n  devise :registerable, :database_authenticatable, :recoverable, :rememberable, :trackable, :validatable\nend\n \n \n Since we are on MongDB you can skip the migrations! \n Carrierwave \n Next up is image uploading, I used Carrierwave. \n Again some configuration, this time make sure that the application_#{Rails.env} is consistent with your database.yml file. \n  # config/initializers/carrierwave.rb\n\nCarrierWave.configure do |config|\n  config.grid_fs_database = \"application_#{Rails.env}\"\n  config.grid_fs_host = 'localhost'\n  config.grid_fs_access_url = \"/GridFS\"\n  config.storage = :grid_fs\nend\n \n \n With Carrierwave configured we can now implement it in our model. \n An example is: \n  class Photo\n  require 'carrierwave/orm/mongomapper'\n  include MongoMapper::Document\n\n  mount_uploader :image, ImageUploader\nend\n \n \n Note the mount_uploader. This will tell Carrierwave to look for a file called image_uploader in /app/uploaders/. \n That file should contain some of the following: \n  # app/uploaders/image_uploader.rb\nclass ImageUploader < CarrierWave::Uploader::Base\n  include CarrierWave::ImageScience\n\n  storage :grid_fs\n\n  def store_dir\n    \"files/#{model.id}\"\n  end\n\n  def extension_white_list\n    %w(jpg jpeg gif png)\n  end\n\n  version :small_thumb do\n    process :resize_to_fill => [100,100]\n  end\nend\n \n \n A couple of things are important here, first the storage :grid_fs. It will tell Carrierwave to store the files in GridFS. \n Next is the def store_dir. This is used to generate the path to the images. \n /GridFS/files/[ID]/[filename].[ext] \n Note that the path is prefixed with /GridFS. This is the value we have set in the config of Carrierwave. \n To serve out the files from Rails we are using a GridFS metal. This will increase the speed of image serving. \n  # app/metal/grid_fs.rb\n\n# Rails metal to be used with Carrierwave (GridFS) and MongoMapper\n\nrequire 'rubygems'\nrequire 'mongo'\nrequire 'mongo/GridFS'\n\n# Allow the metal piece to run in isolation\nrequire(File.dirname(__FILE__) + \"/../../config/environment\") unless defined?(Rails)\n\nclass GridData < Rails::Rack::Metal\n  def self.call(env)\n    if env[\"PATH_INFO\"] =~ /^\\/GridFS\\/(.+)$/\n      key = $1\n      if ::GridFS::GridStore.exist?(MongoMapper.database, key)\n        ::GridFS::GridStore.open(MongoMapper.database, key, 'r') do |file|\n          [200, {'Content-Type' => file.content_type}, [file.read]]\n        end\n      else\n        [404, {'Content-Type' => 'text/plain'}, ['File not found.']]\n      end\n    else\n      [404, {'Content-Type' => 'text/plain'}, ['File not found.']]\n    end\n  end\nend\n \n \n An important thing to note is the regex part: \n if env[\"PATH_INFO\"] =~ /^\\/GridFS\\/(.+)$/ \n The GridFS in the regex is the same as in your Carrierwave config! \n OSX and open files \n At some point when I began stress testing MongoDB by requesting a lot of files from GridFS. MongoDB would become unresponsive and eventually crash the Rails application. \n After a deep dive into the logs I found out that MongoDB has a lot of files open. More then the 256 that OSX wil allow by default. \n To fix this use the following from serverfault, it will basically set the open files limit a lot higher for OSX. \n To change any of these limits, add a line (you may need to create the file first) to /etc/launchd.conf, the arguments are the same as passed to the launchctl command. For example: \n sudo echo \"limit maxfiles 1024 unlimited\" > /etc/launchd.conf \n However launchd has already started your login shell, so the simplest way to make these changes take effect is to restart our machine. \n That\u2019s it! \n Well that\u2019s it! you should now have a working Rails 2.3.5 stack with MongoMapper, files served from GridFS, authentication from Devise and image uploading with Carrierwave. \n      \n    ","summary":"This would have saved me a lot of trouble.","published_on":"2010-05-16T22:00:00Z"}]