If somebody asked me if I used transactions much in MySQL, I would probably have said no… however, now that I don’t have them I realise just how much I used them. Things that just work when using ActiveRecord such as creating a record and ensuring that an associated record gets created is sooo much harder.

MongoDB has “Atomic Operations” which means if you have an embedded relationship, all is good and the database will be rolled back if the entire document does not save. As soon as you have two top level collections and need to ensure that a record is created in both, things get a little hairy.

There seems to be a great deal of “if you need transactions just use a RDBMS” talk but what if you need a flexible schema and transactions, the last thing you want to manage is some kind of EAV system like Magento.

I’ve created a thread on the Mongo User forum with a typical example so feel free to join in the discussion. I’d love to hear experienced Mongo user’s views on how to overcome these kinds of situations and what kind of applications people are running with MongoDB.

If you’ve not tried it yet, head over to the Pow website and get it installed with:

curl get.pow.cx | sh

Happy new year everyone!

Dennis Reimann has posted a nice alternative here using Capybara… thanks Dennis.

OpenSSL::SSL::SSLError (hostname was not match with the server certificate)

After some Googling I found the “enable_starttls_auto” option in ActionMailer, setting this to “false” in the relevant environment file fixed the problem:

  config.action_mailer.smtp_settings = {
    :address => '...',
    :user_name => '...',
    :domain => '...',
    :password => '...',
    :authentication => :login,
    :enable_starttls_auto => false
  }

This option apparently “Enables SMTP/TLS (STARTTLS) for this object if server accepts”. Not being up on my “SMTP/TLS”‘s, I have no idea what this means but it solves the problem.

Hope this saves someone some time.

In the past I have used FakeWeb, however it becomes a little hairy when you need to stub a response based on request body. I came across a couple of alternatives, firstly WebMock which looks promising but then Artifice from the mighty Yehuda Katz caught my eye…

Artifice lets you “replace the Net::HTTP subsystem of Ruby with an equivalent that routes all requests to a Rack application”. I like the simplicity of this solution as you can in essence use a Rack application to replace the responses of the service you are testing.

An Example

First we create a simple Rack application to stand in for the server we are interacting with.

app = proc do |env|
  [200, { "Content-Type"  => "text/html" },
    ["Hello world: #{env.inspect}"]
  ]
end

Then we simply use Artifice’s “activate_with” method to wrap any requests.

Artifice.activate_with(app) do
  response = Net::HTTP.start("google.com") do |http|
    http.post("/the_url", "foo=bar")
  end
  puts response.body
end

This allows for a Rack app to be used as a stand in for a complete API, it could be a Sinatra app for example allowing for easy route handling. We could go so far as to have a series of Rack apps that can be used as stand-ins for common API’s.

I have lately been using Pickle when writing Cucumber features, however I have come to the conclusion that this is a bad idea. The reason being that when using Pickle, you create entries directly, whereas the whole point of Cucumber is that it is for high level integration testing.

What I do now, is to create any entries by filling out and submitting the relevant forms with a step definition, for example I may have the following:

Given an admin has created the following products
  | Name    | Variants                                  | Featured |
  | T-Shirt | Small: 10.99, Medium: 12.99, Large: 14.99 | Yes      |
  | Keyring | Default: 2.99                             | Yes      |

I would then write a step definition for this that would log in as the admin user, break this table appart and fill in the relevant forms.

I would go so far as to say that using factories at all in features is a bad idea and instead everything should happen via the user interface for better coverage. For any data that is known to exist when the app is deployed via ‘rake db:seed’, this can be loaded in the ‘env.rb’ file e.g.

load 'seeds.rb'

Update 11/2/2010: Sometimes this is simply not practical due to slowdown which is a shame, as noted by Amos in the comments.

Devise uses Warden, which is an authentication solution build on Rack making it extremely flexible and usable across multiple frameworks e.g. Rails/Sinatra. Also, Devise is extremely modular meaning to can easily write custom “strategies” for specific behaviour.

I have used Clearance in the past which is great if you want an engine that will just work. Devise however is by far the most flexible and extensible solution that I have come across with the same ease of use as Clearance. The only thing that you don’t get with devise that you do with Clearance is the signup stage, however as this is normally custom on a per-app basis I can live with this.

One more thing to note is that Devise lets you have multiple auth systems in play e.g. one for users and one for admins.

You can grab our plugin to enable “UnitRecord”:http://unit-test-ar.rubyforge.org/ when using “Autotest”:http://rubyforge.org/projects/zentest below:

“http://svn.soniciq.com/public/rails/plugins/iq_autotest”:http://svn.soniciq.com/public/rails/plugins/iq_autotest

By default, running autotest in the Rails directory will run the unit tests. To run the functional tests, do: AUTOTEST='functional' autotest

I hope this saves some people some time!!

These are exiting times with projects like “Propel’r”:http://propelr.com in the pipeline, along with the ever-growing opportunities for new and interesting client projects.

If you are a highly motivated developer and can see yourself in a Ruby on Rails position in sunny (sometimes) Bournemouth, UK then “apply at 43folders”:http://jobs.43folders.com/job/6a5255713e8351a5eb2efef7805b7629/?d=1.

require 'rcov/rcovtask'
 
desc 'Measures test coverage using rcov'
namespace :rcov do
  desc 'Output unit test coverage of plugin.'
  Rcov::RcovTask.new(:unit) do |rcov|
    rcov.pattern    = 'test/unit/**/*_test.rb'
    rcov.output_dir = 'rcov'
    rcov.verbose    = true
  end
 
  desc 'Output functional test coverage of plugin.'
  Rcov::RcovTask.new(:functional) do |rcov|
    rcov.pattern    = 'test/functional/**/*_test.rb'
    rcov.output_dir = 'rcov'
    rcov.verbose    = true
  end
end

You can now simply run rake rcov from inside your plugin directory which will generate an rcov directory with the results. Open rcov/index.html (if you are on OSX this will open automatically) in a browser to view the results.

Thanks to “Mike Clark”:http://clarkware.com/cgi/blosxom for his “Rcov rake task for Rails”:http://clarkware.com/cgi/blosxom/2007/01/05#RcovRakeTask which this task is based on.

*Update (11-11-08):* Changed code to use the RcovTask class.