Sending push notifications directly from a Rails application can be slow and we probably don’t want to have the user waiting until the notification is sent, instead apn_sender can be setup to run a worker which is constantly connected to the apple push notification service. When there are new notifications to send, the notifications are queued up and sent through the always open connection that is maintained by the worker.

apn_sender uses redis as a message queue to keep track of the notifications waiting to be sent, you’ll need to install it before using the gem.

To add apn_sender in your Rails 3 application, just add the gem to your Gemfile. We’re going to need the daemons gem too so we’ll include that as well.

Can’t see this Gist? View it on Github!

Now we can create our daemon which we will be using for sending push notifications, this can be placed anywhere, I’ve put mine in script/apn_sender. Make sure to add execute permission to the file after creating so we can run it.

Can’t see this Gist? View it on Github!

Before the daemon can start running we’ll need to put our iOS push certificate into the application. Instructions for generating the certificates are available at the Apple Developer site. The certificates need to be placed inside of /config/certs and should be named apn_development.pem or apn_production.pem for production.

Once the certificates are in their correct locations, we can start up the daemon. The daemon does not know about the Rails environment so we need to specify this when starting it up. The daemon supports start, stop and restart commands. There is a verbose flag available to output more information (which can be helpful when debugging).

Can’t see this Gist? View it on Github!

Our application is now set up to send push notifications, this can now easily be performed by adding a new notification to the queue. The notify method on the APN class will take a push notification token and then our parameters, we can specify the alert message to show the user, whether or not we want sound as well as the number to display on the badge icon. Anything else we pass to notify will be sent as metadata in the push notification. Here’s an example of creating a notification.

Can’t see this Gist? View it on Github!

The worker should pick up the notification within a few seconds and send it off. The apn_sender has many other features that I haven’t covered, you can view the full documentation over at https://github.com/kdonovan/apn_sender.

ree-1.8.7-2011.02 :132 > Story.joins(:hour_entries).this_week
NoMethodError: undefined method `this_week' for #

The problem was that the .this_week call was being sent to Story rather than to HourEntry. Here’s where Darcy chimed in with the scoped.merge call. It went a little something like this :

Story.scoped.merge HourEntry.this_week

This successfully merged the scope defined by Story with the scope defined by the HourEntry.this_week call and I get all the stories that have HourEntry objects that are returned by the .this_week scope.

The final stage for this call was :

Story.scoped.merge HourEntry.worked_on_by(user).this_week

This then returns all the stories you’ve worked on this week. Add a bit of grouping/distinct and it’s done and done. The additional nice part about this is composing these scopes will allow me to do a lot more in the future, very quickly.

Doing something like :

    Model.reflect_on_all_associations

Will give you all the associations for that model, it’s pretty dirty though and so an easy way to tidy it up is :

    Model.reflect_on_all_associations.collect{ |association|
        association.name.to_s.classify
    }

So, as usual with Rails it was easy as pie, I just am putting this here for future use :)

Edit : Thanks to Darcy for tidying up my previous mess :P

In any case I couldn’t find an explanation of how to get Firebug working with Selenium and Capybara but after some doc reading I got my solution working so I thought I’d post it here.

In my env.rb file I have :

Capybara.register_driver :selenium do |app|
  Capybara::Driver::Selenium
  profile = Selenium::WebDriver::Firefox::Profile.new
  profile.add_extension(File.expand_path("features/support/firebug.xpi"))

  Capybara::Driver::Selenium.new(app, { :browser => :firefox, :profile => profile })
end

Firstly, the problem of being able to have default arguments to a block in ruby. It’s solved nicely in Ruby 1.9 but we’re using 1.8.x on our boxes at the moment. The work around is incredibly simple though and goes something like this :


lambda { |*args|
date = (args[0] || Date.today)
.. remaining code ..
}


That’s all there is to it really. You could go the whole hog with hashed attributes and so on but I think it starts to get a bit smelly if your anonymous functions are taking more than one argument.

The other issue I had was whether a named scope can include a join, and it can.


named_scope :credit_card, { :joins => :subscription, :conditions => "subscriptions.method = 'credit_card'" }


You can hash it all out if you want to, though if it’s all about readability I find the above to be more suitable. However this will also work :


... :conditions { :payment_plans => { :payment_method => "credit_card" } }


The coolest thing about all of this though (and I feel I’m very late to the party here) is that I now get to do things like :


Payment.credit_card.due_on(Date.today)
# or
Payment.credit_card.due_on
# or
Payment.due_on(Date.today + 1.month)


In the above I had just used the default argument to the due_on named scope to be today’s date.

I mean, I’d seen a bunch of tutorials on named scopes and how they worked but hadn’t found a use case in my work. I think it’s finally twigged for me though and will be making use of them a bit more in the future.

We were running into issues with our testing suite running past 15 minutes to run. It caused a number of issues, firstly it disuaded people from running the suite for small changes they thought would be okay, secondly people tended to slow down or not work at all when the suite was running. Given we were building tests into an existing code base and coverage was running generally under 30% this was already really worrying.

We’ve been concentrating primarily on functional testing with RSpec so I went looking for solutions for trying to parallelise RSpec specifically. I tried parallel-tests but I couldn’t get it to work. Then I heard about Specjour on a Hashrocket video so I decided to give that a try. It worked pretty well out of the box, I just had to plug up a wayward plugin, update the rsync config file for the project and change one of the files in the gem to call a different rake task.

Specjour essentially uses Bonjour to find workers on the network and dispatch tests to them and it uses rsync to synchronise the project you’re testing to the remote server. Once the sync has happened then runs the rake task to setup the databases, loads the environment and starts accepting the tests that are dispatched to it.

The instructions will work for the majority of people, I only had some hiccups due to our project. Essentially I gem installed specjour which gave me a specjour executable which I ran to create a dRb server that communicates via Bonjour. Then in my project I added specjour to my Gemfile (all managed via Bundler!) and ran rake specjour.

For me, I ended up having a few hundred failing tests, all to do with the Ruby version of a stack overflow (stack level too deep). It turned out it was caused by a plugin calling alias method chain twice so that the original method ended up being aliased to the replacement method and so there was an infinite loop. Once I applied a fix then we were only down to a few failing tests to do with seed data.

I changed the db_scrub.rb file to perform a different rake task for us as we do require some seed data and then we were on our way.

Previously on my Macbook Pro the suite ran in just over 11 minutes, after turning on a four core iMac and my Macbook Pro I had six workers ready to go and it took about 2.5 minutes to run our tests. I’d really like to crank up the other few iMacs and the 10 or so Macbooks and see what happens then.

I think the only changes we’ll require is to be able to specify which task is run to create the databases, other than that it works perfectly.

In closing I’d say I tried a number of distributed and parallel methods for running our tests and I like Specjour the best. Apparently it will run Cucumber tests as well, I’m hoping to move on to that soon enough.

We are starting with a 27″ iMac and a base Snow Leopard install.

The first step was to install Xcode from the Snow Leopard disc, you’ll find it in the Optional Installs part of the disc.

Ruby and RubyGems comes with Snow Leopard by default so we’ll use them. You’ll likely need to update the RubyGems system :

    sudo gem update --system

Now we can install Rails :

  sudo gem install rails

This will install the latest stable version of Rails. We need a specific version for some of our applications (until we’ve tested it under the newer version) and you can do this by adding the -v switch :

  sudo gem install rails -v=2.3.4

After this we can switch on Apache and install passenger, the module that runs Rails on Apache. So turn on Web Sharing in the Sharing panel of your System Preferences.

  sudo gem install passenger
  sudo passenger-install-apache2-module

This will compile the Apache module and give you some text to paste into your apache conf file to load it. I keep this in a separate config file in /etc/apache2/other/passenger.conf. It should look something like :

  LoadModule passenger_module /Library/Ruby/Gems/1.8/gems/passenger-2.2.8/ext/apache2/mod_passenger.so
  PassengerRoot /Library/Ruby/Gems/1.8/gems/passenger-2.2.8
  PassengerRuby /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby

Next download the Passenger Preference Pane so you can control your Rails sites from the OS X Preferences area. You can get it from http://www.fngtps.com/passenger-preference-pane. You should now be able to run Rails websites on your local machine very easily.

We use Git for our source control and Git X is the best GUI for this on OS X at the moment. You can download Git for OS X from http://code.google.com/p/git-osx-installer/ and you can get GitX from http://gitx.frim.nl/.

I like to use a Pomodoro timer when pairing and the one I like the best for OS X is just called Pomodoro Desktop. It will keep people focussed and also can serve to keep the control swapping in a fairly regular way. You can find out about how Pomodoro works here.

We use Github for our repository and exchange is done via SSH, so you’ll need to generate an SSH key and put that into your Github account.

  ssh-keygen
  cat ~/.ssh/id_rsa.pub

Copy the output and put that into your public SSH keys in Git Hub.

When pairing with Git the ability to have both parties responsible for the work they’re doing is appreciated sometimes. Especially twelve months from now when you can’t remember why you did something. Not that you don’t comment your code, or always write beautifully understandable code. There is a nice gem called hitch. It comes out of Hashrocket and handles the ‘hitching’ and ‘unhitching’ of partners on a machine. We have a pairing station so generally we just want to change the pair that’s in operation, so it works well. You’ll need to be inside a git repository to do the initial setup. I cloned one of our projects and then you issue :

  hitch -m

Which will prompt you for your main email address, this is the email address that all devs in your team receive, or a group email of some sort.

Now to hitch two devs you’d do :

  hitch dev1 dev2

This will prompt you for names of the dev1 and dev2 users so that they’ll be displayed in your commit. It’ll also associate your commits to the email address devs+dev1+dev2@company.com if you setup devs@company.com as the email address when you issued the hitch -m command. If you setup gravatars for all your devs+user1+user2@company.com email addresses then you’ll get a nice picture in Github too.

I think that’s about it really. We obviously just install gems as required and make customisations on a per developer need. We generally use Textmate for editing so this means installing a theme (we use the Railscast theme) and the relevant bundles for Rspec, Haml and Sass.

uninitialized constant ActiveSupport::TimeWithZone

and

no such file to load -- tzinfo

I couldn’t find anything that I’d missed, I’d moved all my gem declarations from the various environment files into my Gemfile and hadn’t had many issues (many) but this was a really odd problem. It was as if part of Rails wasn’t being loaded correctly.

It turns out that you need to include a tzinfo gem for some reason. Don’t ask me how I ran across the solution for this issue, I really can’t remember. It works though.

So if you’re having issues with your app, or tests not passing due to time zone issues in Rails 2.3.x using Bundler then just include :

gem "tzinfo"

In your Gemfile, run another bundle install and away you go. It worked for me, I hope it works for you!

Now most of our controllers require the user to be logged in so writing tests to check this for every controller is annoying and time consuming, more than that it feels dirty. I think this is what some people call a code smell though I’m not up to speed on buzz words. There are also other tasks that are done quite often such as setting up the various types of users we’d like to test as, it would be nice if this were easily put in one place and could be easily pulled in. I guess I was looking for a template of tests that I could share.

It seems that the solution to it is found in Shared Example Groups which I hadn’t heard very much discussion about and it kind of leaves working out how they work to you rather than documenting it too much.

So far I’ve used it simply to make sure that controllers that require are redirecting users appropriately and also for setting up a specific type of user for our system before testing.

I created a directory under /spec/support called example_groups and in there I have a file called login_groups.rb. In that file I have something like the following :

shared_examples_for "customer is logged in" do
  before(:all) do
    @user = Factory(:customer_user)
    @user.customers.push Factory(:customer)
  end

  before(:each) do
    activate_authlogic
    OperatorSession.create(@operator)
  end
end

Now in my spec files when I have a bunch of tests requiring a logged in customer I will include this little snippet :

  it_should_behave_like "customer is logged in"

I get a logged in customer to start playing around with. I have the spec/support/example_groups directory in my include paths for Rspec and so it just all works.

My tests can then start to look like :

describe MerchantsController do
  it_should_behave_like "areas requiring login"

  context "customer logged in" do
    it_should_behave_like "customer is logged in"

    ... insert other tests here ...
  end
end

It means I can swap in another authentication gem/plugin pretty easily and also encapsulates the logic about creating customers, or whatever type of item you want to use, so that if that changes you can swap things in and out with a minimum of fuss.

Just to be clear, example groups aren’t limited to setup tasks or connecting to before/after hooks, you can also include a bunch of tests as well. This allows me to have a bunch of tests to run to make sure that a user does have to be logged in for various controllers and include these tests in on line.

I hope this helps someone, it took a bit of searching and trial and error myself this morning to get it working and find the uses for it that I’ve found. I’m definitely open to better solutions to this sort of issue though.

Given that we thought very little of any consequence had changed it was annoying trying to troubleshoot the problem. Typically you start off thinking it’s something you did, then maybe it’s something someone you know did, then you start to branch out and think that maybe, just maybe, it was a bug elsewhere!

I initially started to check the logs and they seemed perfect, but it wasn’t finding the user record in the database. So I loaded the database in sqlite and lo-and-behold there were no user records to be found. I started a debug session and it reported that the user had in fact been created. I thought it had to be something to do with transactions being used. Trying to insert a record into the database and being told the database was locked confirmed this.

I turned out that the Cucumber gem writer determined that there should be no more global setting for turning on or off transaction support when running tests. Previously transactions were turned off by default in Cucumber, and you’d generally turn them back on if you needed them. This change is annoying because a good chunk of our suite uses Selnium for testing and it requires transactions to be turned off. It’s also a bit odd to reverse a default option and have no way to enable it at all.

Apparently the work around is to tag all the features and scenarios that rely on non-transactional database operations with this new tag of @no-txn. After implementing this, we’ve found it does work and so our tests are back to usual condition.

So if you’re running into problems with your Selenium tests using Cucumber with Rails and your database isn’t updating within a test then check out the ‘@no-txn’ tag and see what happens after you use that.