I also use DJ to send out emails, and a typical asynchronous call sending a message from one user to another – scheduling a delayed job – used to look like this:

UserMailer.send_later(
  :deliver_message,
   @recipient,
  current_user,
  params[:message]
)

Since darebusters.com is an internationalized website currently offering users the choice between English and German, this has proved a slight challenge, however. We have the usual internationalization (i18n) bells and whistles: Flags to select the language, and remembering the user’s language selection in session, cookie and in the users database table. By default, a delayed job will simply run with the default locale of the site. It has no way of accessing the context it was invoked in, so it cannot set the locale from session or cookie. The job only knows what it can work it from the arguments it was created with.

It looks like an easy problem to solve. DJ shouldn’t have to know about locales, the code should just set I18n.locale from @recipient.locale. That’s exactly how I initially thought I had solved it: In the UserMailer.message method I set the locale, and then passed parameters to render the mail. The catch is, however, that I use a slight hack to get support for localized ActionMailer templates, i.e. when the locale is set to de it will render the message.de.text.plain.erb view rather than the message.en.text.plain.erb view. The template to render is selected before UserMailer.message is invoked, so at that time it’s too late to set the correct locale. In fact, I needed the entire job to run in a locale specified when the job as scheduled.

For this purpose, I created a custom delayed method to be invoked by DJ: LocalizedJob.

This code should be placed in /lib/. I want the send_later_with_i18n to be available on all objects just like DJ’s own send_later, so I also also created an initializer to extend the Object class:

This code should be placed in /config/initializers/. I am now able to replace all my send_later calls with send_later_with_i18n calls, storing the required locale with job to be extracted when it’s run:

UserMailer.send_later_with_i18n(
  :deliver_message,
  @recipient.locale,
  @recipient,
  current_user,
  params[:message]
)

So on darebusters.com, Germans get all their mails in German – no matter what locale the sender used (although the actual message written by the sender is of course not translated ;) – and everyone else gets mails in English. Now that was a real Ruby fairytale.

Bundler (Github | Website) is the new way to manage gem dependencies in Rails and other Ruby applications. If you haven’t heard about it, there is (of course) a great introduction at Railcasts. It’s pretty easy and straight-forward to use, especially if you are used to the config.gem format of Rails.

However, one very common use case in Bundler’s Gemfile that is not explicitly documented anywhere I’ve seen, is how to configure gems to be installed in both development and test environments, but not in staging and production environments. You have probably seen the examples of how you can assign a gem to a specific environment using the :group option or method. So you’d probably write something like this:

group :test do
  gem "rspec-rails", ">= 2.0.0.beta.1"
end

group :development do
  gem "ruby-debug"
end

The gems you don’t need on the server are usually all those related to testing, debugging and perhaps generating fake data and so on. But wait a minute. You also need the RSpec in the development environment so you can use it’s generators, right? And you need Ruby Debug in the test environment so you can put breakpoints in your tests.

Luckily there is a very easy, and – once you know it – obvious solution to this: You can pass multiple environments to the group method, just like this:

group :development, :test do
  gem "rspec-rails", ">= 2.0.0.beta.1"
  gem "ruby-debug"
end

And that's probably the only grouping of gems you'll need in many Rails projects. Most gems installed and required in all environments, and a few just in the development and test environments. Happy Rails 3 coding.

Community Day in Copenhagen is back again this year, so reserve May 27 if you are near Copenhagen and like free tech-talks, networking and beer. This year Daniel Frost, the Microsoft evangelist that makes it happen, has involved me and several other developers actively in the planning of the day. With CD ‘10 we have raised the level of ambition – bigger venue, more people, more talks and if course more fun.

We will have 20 sessions distributed on four concurrent tracks covering a surprisingly wide number of topics – very few of the talks are on Microsoft-technologies, in fact so few that we might loose a few of those .NET consultants who thinks anything non-MS are not worth listening to ;) Still, if you are doing anything at all related to the web (and most of us are, right?) you will surely find topics such as HTML 5, Single Sign On, Azure, Advanced jQuery etc. interesting.

I will be giving a talk with the rather bold title “Replace ASP.NET with IronRuby on Rails”. It will give me an excuse to seriously dive into IronRuby and how to make a Rails site talk fluently with .NET libraries and assemblies. Coming from a serious amount of ASP.NET development myself, I really think a lot of web-based .NET projects could benefit from Ruby on Rails. The only time I was really happy with ASP.NET was when I switched to that from classic ASP – but since then, it hasn’t evolved that much. Granted, ASP.NET MVC has rescued developers from the annyoing “webform” structure, but it still has a long way to go.

I’m getting ahead of myself here, come watch the session – sign up for Community Day ‘10 now!

For me, the situation is like this: My standard version of Ruby on my development machine is 1.8.7. I deploy to many different environments, some (the ones I have a degree of control over) runs 1.8.7 and others (such as Heroku and some customer’s servers) runs 1.8.6. I can test and code away happily only to get some ugly exceptions when I deploy because I have called count on an array instead of length. Further, I also want to play with the new features of Ruby 1.9 and run Rails 3 on it. And that’s not to mention that I also use alternative Ruby implementations such as JRuby for projects where I need to tap into Java libraries.

So that’s at least four different versions and implementations of Ruby I want to use at various times. I need to compile gems separately for each of them, and I don’t want them to clutter up my default and very functional Ruby 1.8.7 installation which I still use most of the time.

Ruby Version Manager (rvm) to the rescue! This very welcome open source project allows us to easily install, manage and switch between multiple Ruby versions and implementations with a single command. The software itself is also easy to install:

sudo gem install rvm
rvm-install

Once you have followed the instructions and pasted the line of script into the correct file and restarted (or sourced) your shell, I recommend that you upgrade to the edge version of rvm by running this command:

rvm update --head

This gives you access to the newest versions of the installation scripts, and that is needed if you for instance want to install JRuby:

rvm install jruby
rvm jruby

That second line is all you need to switch between ruby implementations – here we switch to JRuby. Note that this is not a system-wide change – the switch is done simply by changing a few environment variables in your current shell so ruby, rake and so on now refers to the JRuby versions.

One gotcha is that gem will installed the wrong place if you have the —user-install flag in your .gemrc file. The only current resolution I know is to remove the flag.

Never the less, I will highly recommend that you install Ruby Version Manager and play with different Ruby version and implementations – it has never been easier.

Enjoy the new decade – take care of our world.

For some reason – and I am sure people with a bit more insight into the human psyche than me can tell you exactly why – videos where people do something really stupid, disgusting, dangerous or daring are amongst the most popular. But what reward do the people who makes these videos get for their hard work? A lot of views and comments on Youtube? That’s nice, sure, but couldn’t we get something even better if the makers actually earned some money on entertaining the rest of us?

darebusters.com is where this is happening right now. We have created a platform where people who wants to show how truly talented or crazy they are rewarded for their hard work in cash – we call them darebusters. darebusters.com is not the next Youtube or Vimeo – rather, it is intended to be a sprouting community of people with crazy ideas for dares, people willing to sponsor those dares on video and – of course – the darebusters making it all happen.

Here is how it works: A darebuster uploads a teaser video where he explains what kind of dare he has in mind – or a user suggests a dare for somebody else to complete. Either way, the dare now has a certain time period to collect the required amount of money through micropayments from other users who thinks that idea is cool enough to support. When the amount is reached, the darebuster must now complete the dare and the ratings the completion video receives decides how much money the he gets out of it.

The business model for darebusters.com is simple – there is no subscription fee or price tag for watching specific videos. Rather, users are required to sponsor a dare at least every two weeks to continually have access to all completion videos. This way, the users decides which dares are really worth making and a higher quality of entertainment is reached.

I am a founding partner of darebusters.com and I have developed the entire site in Ruby on Rails during the last couple of months (well, except for the fantastic graphical design). We are currently testing the site in a closed beta, but if you signup for a beta invitation or contact me, we will let you in to play around with it: darebusters.com.

Many of the applications we build send out a lot of emails, and for some, it is a critical part of the system. Lokalebasen is such an application, and the people behind wanted to monitor all outgoing mail, whether generated by a page request, a cron job, an administrator or anything else.

I built a clever little monkey-patch for the Ruby on Rails ActionMailer that makes sure that all outgoing emails has a certain email address put on BCC. This is not visible to the recipient, but it allows you to keep an archive of all outgoing mail, which is certainly useful – especially for support and bug-tracking.

Drop this into your lib-folder (remember to change the email address):

- and be sure to enable it by adding this line to environment/production.rb (you probably don’t want to BCC mails sent in development and test mode):

ActionMailer::Base.send(:include, BccAllMails)

Finding myself in the need of a webshop, I decided to try to deploy Spree to Heroku. It wasn’t too hard, but it did take a few tricks to get Spree running on a server that doesn’t allow you to write to the file system.

I can’t say I have too much hands-on experience with Spree yet, but it seems to be have borrowed its extension concept from Radiant CMS, which happens to be one of my areas of expertise. So I put together an extension for Spree that will easily allow you to deploy the e-commerce system to Heroku.

Just follow the instructions in the README on Github.

I use Heroku for Capistrano, once that has been setup with the right recipes and the server has been setup to corporate and serve our web application properly. But that can also take some time, especially on a brand new server.

I did miss one important feature of Capistrano when I started using Heroku: Rollback. Writing cap deploy:rollback has saved my behind many, many times. Granted, it has often been because of bad server configuration which shouldn’t happen with Heroku, but there has also been cases of genuine bugs resulting in all pages returning errors. When we do mess up, it is really nice to have the application back up in a matter of seconds, and then being able to take you to fix the error – perhaps even do the right thing and write a failing test for that particular bug before you fix the error.

With Heroku you don’t get rollback per se, as the application always displays the HEAD version of the master branch in the git repository on Heroku’s servers. However, with git we have the ability to roll back to the state of every single commit ever done. It’s just not very convenient having to figure out which commit was your last one working, especially not in a situation where your application is down. Also, we need this to be automated like everything else.

The solution I came up with was to tag each release with a timestamp – just like Capistrano names its release directories. This gives me a series of tags that should all point to successful deployments, and when my hour of distress arise, I can simply tell the master branch on Heroku to point to the previous release. If I further delete the tag of my current release, I have effectively rolled back to my previous release, and hopefully my application is now up and running again.

If you want this functionality in your Heroku application, just copy the above code into a .rake in your lib directory. You deploy your application with this command rake deploy and roll back with rake rollback.

Please note that the script also runs migrations on each deploy, but feel free to delete that line. Suggestions and improvements are very welcome. Enjoy.

Update: Nicola Junior Vitto pointed out that my rollback code was not working correctly, and managed to fix it. His fork of the deployment script also features support for both a production and a staging environment – I’ve updated mine so rollback work, but kept it more simple without support for multiple environments.

Howver, TDD’s basic rule of always writing a failing test before writing any new code, doesn’t always leave me feeling very productive. For this reason I have mostly abandoned testing views in isolation (as made possible by RSpec’s view tests), as well as testing Rails helpers with the exception of complicated helper methods with some business logic in them. I still tests views by, behold, viewing them in the browser, and I haven’t been swept away by Cucumber, Webrat, Selenium and their fellow high-level test frameworks yet – but I am open.

I can skip view-testing without feeling too bad about it (wonder how many potential customers that statement scared away), but although I live and breath by the Skinny Controller – Fat Models notion, I still find functional testing of my controllers to be a must in Rails TDD. Unfortunately, I have never really gotten along with RSpec’s default way of testing controllers. It feels bloated, and the RSpec mocking framework seems to – yes – mock me as I add more and more stubs and expectations to avoid tests from failing. So in my research for testing frameworks, I knew I had to find a better way to feel productive and happy about writing controller code again.

Many people hate test fixtures in a very intense and passionate way. I actually kind of like them, I just think they are a bit too stupid and hard to maintain. I also love all the good stuff coming from the thoughtbot guys, and their alternative to Rails’ fixtures – Factory Girl – is really, really good. Not just because it has a pretty name and a fancy syntax, but because it is really nothing more than Rails’ fixtures done right.

I am getting ahead of myself here. Testing seems to be something people have very different opinions about, and as such I don’t the perfect mix of testing frameworks for everyone exists. RSpec has probably come closest, and I am sticking with in my test setup while adding and replacing parts of it with newer and better solutions. The mix has come like this:

• RSpec as the overall testing framework
• RR (DoubleRuby) for mocking and stubbing
• Shoulda to get sweet test macros
• Factory Girl to create test data
• Stubble for easing my controller spec pains

Do I really need five testing frameworks to be productive with TDD? Not at all, Rails is bundled with all I need to do TDD. But along the way, I have seen the need to make my tests DRY’er, more readable and easier to maintain, and these frameworks help me with that in different ways. I have already touched on the RSpec vs. TestUnit issue: It comes down to personal taste, and RR, Shoulda, Factory Girl and Stubble all works with both of these frameworks – isn’t that nice?

I initially chose to try RR because it seemed to be what the cool kids are using at the moment (and that often turns out to be good), but now that I am getting into it, I am really starting appreciate its compact syntax and advanced features. You could argue that RR’s syntax:

  mock(User).find { @user }

- is much harder to read than, say, RSpec’s mocking syntax:

  User.should_receive(:find).and_return(@user)

- but I’d say that RR’s syntax is actually more “Ruby-ish” than RSpec’s. If you really understand Ruby, RR will most likely appeal to you.

I use Shoulda mainly to get DRY’er tests that are easier to read, than when I write macros myself. Shoulda has defined a set macros that are quickly becoming a standard, and as something quite new, they also exists as RSpec matchers. Statements such as:

  it { should validate_presence_of(:state) }

- simply makes TDD faster and more enjoyable, because it would feel wrong to have to write 3-5 lines of test code to test a single line of Rails code.

I can’t say if Factory Girl is better than, say, Machinist (which is actually heavily inspired by the former, according to the creator), but it is without a about much better than Rails’ fixtures from maintenance point of view, the syntax is pretty and it feels productive to use.

If you already knew about everything else mention in this article, chances are that Stubble will still be news to you. Not even released in a version 0.0.1 yet, this project is a small testing framework aimed at making stubbing and mocking in controller tests much easier. When the author, David Chelimsky – who is also behind RSpec – mentioned this in passing at a presentation at RailsConf 2009, my curiosity was immediately piqued. Could this be solution to functional testing woes? Short answer: I’m not really sure yet. It’s still too early to say. Currently, I can only get Stubble to work in very simple cases like this:

  describe "on GET to :show" do
    def do_get(params = {})
      stubbing(Teaser) do |teaser|
        get :show, {:id => teaser.id}.merge(params)
        yield(teaser)
      end
    end

    it { do_get { |teaser| should assign_to(:teaser).with(teaser) } }
    it { do_get { |teaser| should render_template('show') } }
  end

- where I have even had to wrap the stubbing, which is the core of Stubble, in my own method to get the compact testing style I like. I don’t think I use Stubble in the way it is intended, but I’d like to be able to simply wrap do my entire outer describe in the stubbing statement, this having the magical teaser variable available in all my tests, helper methods and before-statements. Also, I have not yet managed to mock or stub anything on the magical teaser variable, so if I for example want to verify that some method is called on teaser, I can’t use Stubble in that test. Again, to be fair, Stubble is in very early development, and I still need to learn about it, but if these two problems are solved, I think Stubble is going to ease a lot of my controller testing pain.

If you, dear reader, feel that you have a better, or simply different, mix of testing frameworks, I’d love a comment from you about your choices and reasons for going with one thing over the other.

]]> http://casperfabricius.com/site/2009/07/25/test-driven-rails-development-with-rspec-rr-shoulda-factory-girl-and-stubble/feed/ 2