$ cd test # from your rails app root
$ ruby unit/a_model_test.rb

As compared to:

$ ruby -I"lib:test" "/usr/local/Cellar/ruby-enterprise-edition/1.8.7-20090928/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/unit/a_model_test.rb"

Definitely a hand to forehead moment when I read that! Found it in a comment here:

https://rails.lighthouseapp.com/projects/16213/tickets/8

*Assumes your ruby command is set up correctly in your shell’s environment, of course.

You do all your work in a feature branch, then pull it into the master branch. There are numerous topics on the web for this.

But there is a problem with this approach. When you run `git pull origin my_branch`, you end up creating merge commits. Some get around this with `git rebase`, but then you end up rewriting commit shas. So how do you get a clean history without messing up the master branch?

Use `–squash`. Here is a simplified example:

git checkout -b my_branch
touch File1
git commit -a -m "File 1"
touch File2
git commit -a -m "File 2"
git push origin my_branch
git checkout master
git pull --squash origin my_branch
git commit -a -m "File 1 and 2"

Note the last two steps. We use –squash to compact the feature branch commits. This leaves all changes in the other branch in an uncommitted state (which you can then do one final review on). We then go ahead and make a commit.

The result? One commit in master, containing all code from the feature branch.

Now, the caveat: If you have multiple developers who made commits on this branch, you probably want to leave the commits apart for credits sake. But if you’re the only one who’s committed, and you don’t mind squashing the history, this works great!

If you prefer to store your MongoDB data all under your home directory, you might find Mislav’s gist suits your needs instead:

http://gist.github.com/265272

If you prefer installing from source, check out this post:

http://shiftcommathree.com/articles/how-to-install-mongodb-on-os-x

Enjoy.

If you don’t yet use New Relic RPM, you can get a Lite account for free by going to newrelic.com, where you can also test drive New Relic RPM on a real application.

Custom request parameters

New Relic does it’s best to record as much information about the current request as possible. The URL, split down into controller, action, id etc, the request referrer, GET and POST data…. but there is data that it doesn’t know about. Things like the current locale, the user who is currently logged in, or custom session params. Thankfully, there is a solution.

New Relic RPM contains a method for adding custom data to each transaction or error that is sent to it’s servers. Utilize this method inside of a before_filter in your application controller, and you’ll be gathering that extra data in no time. Here is the code we use.

# Collect additional debug details for New Relic RPM is available
# Do this after all other before filters so details are present
before_filter :set_new_relic_custom_parameters
def set_new_relic_custom_parameters
  return unless defined?(NewRelic)
  NewRelic::Agent.add_custom_parameters(
    :locale => (I18n.locale if I18n.locale),
    :account => (logged_in? ? current_user.login : 'guest'),
    :return_to => (session[:return_to] if session[:return_to])
  )
end
private :set_new_relic_custom_parameters

Now, whenever RPM sends information about slow web requests or error reports, you’ll have more data to help replicate the issue.

Passenger Queue Wait

Sometimes the slowness might not be your app, but your app server. How do you tell if it’s serving requests fast enough? New Relic RPM now has the ability to report how long your visits were waiting in the ‘queue’, that is, the time between requesting the site and Apache actually processing that request. Getting this working is fairly simple.

RequestHeader set X-REQUEST_START “%t”

Simply set that in either your main apache.conf file, the VirtualHost directive, or a Directory directive.

Also, ensure that the headers Apache module is enabled. On Debian, you can do this by running the following as root.

# a2enmod headers

That’s all it takes. Now, when RPM sends along information, it’ll send how long each request stayed in the queue, and display it at New Relic RPM’s web interface, on all graphs as ‘Queue Wait’. This should give you an indication of whether your application server is performing well.

Important Note: If you run your application across multiple machines, each machine needs this header, and the clock on each machine must be synced with NTP or similar, or you’ll end up with very incorrect queue times. Users who run the entire site off one box need not worry about this issue.

Garbage Collection delays

I’m not going to go into much detail about Ruby Garbage collection here. Google ‘Ruby Garbage Collection’ if you want to know more. Put simply though, in Ruby, while Garbage Collection runs, it stops the processing of your app. This could lead to slow page requests if it garbage collector, or GC, runs multiple times in the same request.

There are ways to tweak this using settings, but how do you know if it’s a problem to begin with? If you use Ruby Enterprise Edition, or another version of Ruby with the Railsbench GC patches compiled in, then all you need is the following line in your application.

GC.enable_stats if defined?(GC) && GC.respond_to?(:enable_stats)

For Ruby on Rails users, you can stick that at the bottom of your config/environment.rb file. Basically, if GC is defined, and responds to the correct method, then use it. RPM will send this information back to New Relic, where you can view how long GC took in each of your requests, and deal with it accordingly.

Conclusion

Well, that’s all for now. Please feel free to share any additional features which help make New Relic even more useful in the comments.

But Github was building gems for some time, and due to it’s continuing popularity, many well known Ruby on Rails developers and companies switched permanently to Github for their gem building/hosting at the time, so it’s likely that quite a few gems you’ve got installed are from Github.

To help transition over from Github to Gemcutter, Maxim Chernyak wrote a great utility called off_github, which looks at your list of gems, and tells you which ones you’re installed from Github, and whether they can be reinstalled from Gemcutter. It saves a lot of time and effort  than having to do it manually. So here’s how to get started….

Firstly, lets get the latest version of Rubygems. This may not be needed for the off_github gem to function, but it pays to keep this up to date to prevent any issues with newer gems. Usually, you’ll want Rubygems version 1.3.0 or higher. At the time of this post, the current version is 1.3.5.

$ gem –version
1.2.1
$ [sudo] gem update –system
……
$ gem –version
1.3.5

Once that’s done, install the off_github gem. To do that, add Gemcutter as a source and run the gem install command.

$ gem sources -a http://gemcutter.org
$ [sudo] gem install off_github

Note: Rubyforge gems now points to Gemcutter, so the gem source adding isn’t technically needed to install off_github. That said, the off_github gem still checks for the Gemcutter source (it’s a bit outdated) and won’t work without it, so to get around it, install it before running, and you can remove it afterwards.

Now go ahead and run the off_github command. If you don’t use sudo to install gems, then be sure to add –no-sudo the end.

$ off_github [--no-sudo]

This’ll go ahead and return a list of gems that were installed from Github, what there Gemcutter gem name is, and the action it’ll take on that gem (usually reinstall). It’ll then ask you if you want to install. Type ‘Y’, hit enter, and then choose y/n/a at each prompt.

If everything went smoothly, you’re all done. You can now go ahead and delete both the Github and Gemcutter sources.

$ gem sources -r http://gems.github.com
$ gem sources -r http://gemcutter.org

So know, you should have Rubyforge as your only gem source.

$ gem sources
*** CURRENT SOURCES ***
http://gems.rubyforge.org

Additional Material:

• http://www.rubypulse.com/episode-0.16_off_github.html
• http://www.rubypulse.com/episode-0.16.1_off_github_revisited.html

For more details, see this blog post, detailing the symptoms.

http://blog.patrick-morgan.net/2008/09/problems-with-ie7-sessions-not-saved-in.html

The following change removes the activation link from the email issued to the user and sends them an email notification that their application has been received.
From the root of your Joomla site, go to /components/com_user/controller.php (approx line 367) and add:

We also need to change…

to:

The next bit of code emails the account activation link and details through to the site administrator, who gets to decide if the application is successful.
From the root of your Joomla site, go to /components/com_user/controller.php (approx line 524) and change to:

We then need to pass both user and admin notifications through to the script that generates and sends emails.
From the root of your Joomla site, go to /components/com_user/controller.php (approx line 548) Added:

Joomla now issues 2 emails when the signup form is submitted, rather than the usual one.

Some final changes are needed to the language files on the site, so that the email notifications make sense. Make the following changes. From the root of your Joomla site, go to

/language/en-GB/en-GB.com_user.ini (approx line 84) and change:

/language/en-GB/en-GB.com_user.ini (approx line 85) and change:

/language/en-GB/en-GB.com_user.ini (approx line 92) and change:

/language/en-GB/en-GB.com_user.ini (approx line 120) and change:

Finally, the User() helper function needs to be updated so that the activation confirmation email is sent to the user in question rather than the user currently logged into joomla (eg site administrator): To do that, go to:

The hack makes it easy to add as many access keys as you need, and you can offer more than just the basic keystroke options set on most government websites.

Experience with Cucumber

Cucumber has been working out really well, and was very easy to get started with.

sudo gem install cucumber
cd ~/Work/app
script/generate cucumber

That’ll install a new environment with the config.gem lines needed. It’ll also setup a features directory. Open that up, and start writing specs for your app. Simple!

Once I had all the basic step definitions for logging in, logging out, and various paths setup for login page, homepage, etc, writing new features was fairly easy, and executing them is just as easy (rake cucumber). Take for example, the following feature relating to session management.

Scenario: Login with correct details
  When I go to login
  And I fill in "Username" with "jane"
  And I fill in "Password" with "test"
  And I press "Login"
  Then I should see "Successfully logged in."

Very straightforward and easy to read. And as such, the natural language of it means clients and other developers are able to see exactly what has been implemented, and that it is working as expected.

It’s running the entire test suite is fairly fast too (granted, it’s still quite small). I’m testing the core functionality of the new application so far, and it only takes ~40s to run all the features when using ‘progress’ output (the  F..F..E  style output that test/unit does). The more verbose ‘pretty’ output is nice, but quickly fills the terminal, so very easy to miss errors as they happen until the end, and also adds processing time (10s cut off when I switched to progress mode).

At one point in development, I had to test outgoing emails. Thankfully, Cucumber has a really great addition, called email-spec by Ben Mabey. Writing a Cucumber feature for these emails was painless. Here is a snippet from one of the password reset features.

Scenario: Request Reset with correct email
  When I request a password reset for "example@example.com"
  Then I should receive an email
  When I open the email
  And I follow "Continue to reset your password" in the email
  Then I should see "Change My Password"

I’ve made a few contributions to the email-spec project, which have been included in the latest release, enabled email testing for people other than yourself  ( When they open the email… Then they should see …  etc). Makes writing tests even easier.

Other Thoughts

I did find that you duplicate a lot when it comes to adding paths because Cucumber is framework independent. For example, if you have a ‘map.resources :events‘ Cucumber won’t provide you with paths like ‘the events index’ or ‘add a new event’ automatically. Would make a handy Cucumber addition though. In addition, because Cucumber uses Webrat, which has no idea how to interact with Javascript, you still need to fall back to the slow Selenium testing if you’re application relies on Javascript.

Conclusion

Cucumber has been really great and I’m happy to keep using it. If you’ve used Cucumber before, or are going to try it, or perhaps your didn’t like it and went with something else, let me know in the comments. I’m always happy to hear other peoples experiences.