RSpec is going through a transition with a huge refactoring for version 2. It’s currently only in beta, but if you want to get the jump on things with RSpec 2.0 there are a few changes worth knowing to ease the upgrade path.

The rake tasks have changed a little. There has been a namespace change and consequently a filename change. This is what you need to get them working again.

Nothing difficult there, but tricky enough to need to go digging through the source, while the docs for this version are scarce.

A significant change is that you must now use a file named .rspec in the root of your project to declare the spec options. This file used to be named spec.opts. Previously you were able to add spec options in the rake task block as well as the spec.opts file. This change removes the possible duplication giving you only one way.

Oh yes, one more thing to note. The binary for RSpec 2.0 is now called rspec. That might save you some wasted time also.

For anyone who has used cron before I am sure there have been occasions where you have buggered it up and run the task too few or too many times or at the completely wrong time. I know I have. Its not the cron is terribly hard its just sometimes is not the best mental map for specifying a repeating interval.

Well as a fun summer project I thought I would create a Ruby DSL for cron to generate the intervals using a more natural syntax to help avoid mistakes. The result is Cronos. Its influenced by the Active Support time helpers so you can chain together English like commands that you would likely use when describing a repeating interval.

It would be great to see Cronos integrated it into other cron tools for Ruby as to extend them with DSL to generate just the interval part. The CronEdit project is one that might find it a useful addition.

Its a first crack and its not magical at all so you can easily jump in and fiddle and perhaps improve it. The code is up on GitHub (where else?!).

UPDATE:
Examples were confusing so clarified the output of each statement irb style.

Hampton Catlin the creator of make_resourceful has let his thoughts on pagination known and in summary he is not a fan. Hence there is no DRY way to add pagination to m_r without overriding the defaults methods repeatedly.

I am not so anti pagination and often find it mildly useful. But mostly my clients want it regardless. So I have abtracted my pagination solution for m_r into a plugin called funnily enough make_resourceful_with_pagination. Now it may sound like a fork of m_r but it is in fact an “evil-twin” plugin, which is a plugin pattern invented by Chris Wanstrath of GitHub. So basically you need to install both m_r and my plugin.

It works with will_paginate by default but should also work with paginating_find or any pagination that acts on the model. You just need to tweak the global options. It won’t work with classic pagination, but frankly I don’t see the appeal of that anyway.

For a while I have sitting on this plugin called mocked_fixtures. I wrote most of it a few months ago and added a few things here and there but just hadn’t got round to releasing it.

Basically it loads your fixtures files as mock model objects with the values from the fixture stubbed out on the mock. It saves you having to stub lots of attribute methods on your mocks with values that could have just as happily come from your fixtures. After all if you are still using fixtures then they often have a fair bit of thought behind them. So why not use them again but practice some good test isolation and remove the database from the picture.

I am using it in projects, mostly in controller and view specs to save myself a ton of stubbing code to get a passable mock object to use. Of course you can alter the mock object after you have created it to further customise it, after all it is just a mock.

The problem is I don’t how useful people will find it, given this huge push towards complete fixture replacements with FactoryGirl, model_stubbing , unit-record and the like. Its not an answer to those or even one in the herd since it still relies on fixtures.

Its really for those who like fast tests, test isolation and still use fixtures. I will be interested to see if it gets used.

I am not even going to go in depth here coz the readme does just that. So if you want to have a look then go to the source.

Dev mojo

After reading the great posts by Geoffrey “PeepCode” Grosenbach and Manfred Stienstra about using Phusion Passenger for development I had to give it a try. My doctor she’d never heard of mod_rails but gave me antibiotics for it just in case.

After little bit of setup I can say I am much happier with this dev rig than the old ‘script/server’ style. Just open a browser and the app is just waiting to serve you. Nice and agile or something.

Bugger no debugger!

One thing was missing for me though. With no –debugger switch to play with, I needed an alternative. Fortunately the brilliant ruby-debug has the solution with remote debugging. The tricky part was turning remote debugging on or off easily so we didn’t destroy our new dev mojo with onerous meddling in an environment file.

Keepin’ it real (easy)

So your working away and you run into a tough bug in some action or corner of your app. You need to break out the debugger. So the most straight forward way I have found is doing this

rake restart DEBUG=true

But how does it work. Here is a little something I prepared earlier.

In the style of passenger’s restart.txt the restart task also creates debug.txt in the tmp folder if the DEBUG switch is set to true.

Then in development.rb we look for the debug.txt file which triggers ruby-debug to be loaded. We set the ‘wait_for_connection’ option to true which gives us a chance to connect to the remote debugger when the app restarts. Finally start the debugger and clean up the debug.txt file.

From here you refresh the browser and it will it get stuck loading the page. This is because the app is waiting for you to connect to the remote debugger session. In a terminal type

rdebug -c

Once its running you can add and remove debugger statements in the code without needing to restart the debugger or the app. Now you just use the debugger as normal.

If you close the terminal or exit the debug session you can’t reconnect with it. You must do a restart with the DEBUG switch again. Once you cancel the debug session the app won’t drop into the debugger when it hits ‘debugger’ statements any more. So you can continue as normal until you need the debugger again and do a restart.

There you go, thats pretty neat and tidy and agile and whatever.

UPDATE:
I should probably mention that for ease of use and efficiency when using ruby-debug in remote mode you should probably use the ‘set autoeval’ setting. To do that create a file called .rdebugrc in your home directory and put this these lines in for good measure:

When I create a plugin I set up the tests or specs to be able to run stand-alone, that is not inside Rails app. But when you want to try the plugin out inside a real app, it can help to be able run the specs against vendored version of Rails if the application has one.

So to neatly auto-detect if the plugin is in an app with vendored Rails and to use that Rails for testing, I hacked this little snippet

This checks for the Rails folder in vendor with extra care by going up to where the app root would be and down through ‘vendor/rails’, rather than directly to the rails. If a vendored Rails is found it puts each module’s parent folder at the front of the load path to make sure its used ahead of the gems.

For a bonus it also allows you to specify a version of the Rails gem if you want, by setting the VERSION parameter on the command line, when not inside an app.

Afterwards you just require the Rails parts you need as usual.

require 'active_support'
require 'active_record'

If the vendored rails exists the the libraries are required from there, otherwise the gems are used. Stick it in the top of your test or spec helper.

Now that GitHub has a gem server it allows the process of managing your own fork or customisation of a gem ridiculously easy. No need for your own gem server or shipping around gem files, just put it up on github and nominate it as a gem in the project config. GitHub will automatically compile the gems using a gemspec file if present. All the info you need is here so I won’t recap it any further.

A gem which I find essential for Rails apps which send out emails is ar_mailer by Eric Hodel of Seattle Ruby Brigade and Ruby Hitsquad fame and now the maintainer of RubyGems. But there a couple of things missing. One is the need for pid files to be generated when running as a daemon to allow effective management with monitoring tools and such.

Well there just so happened to be a patch by Dylan Egan in the ar_mailer forums to add this feature, but it has been overlooked for a long time. So I thought this would be a good chance to fork it and use the GitHub gem system as well. Its now forked it and patched with some tweaks to get it working and a few fixes for the tests which broke due to changes in the latest ZenTest gem.

The project for the gem is here. To use the new gem you need to remove the old one because of the way github names your gems. It uses github username as a prefix to the gem name. This means the old gem will be loaded instead of the new gem when required in your app. But the binary will be used from the new gem causing nasty problems.

To install, first add GitHub as a gem source

sudo gem sources -a http://gems.github.com

Then

sudo gem install adzap-ar_mailer

Now when the binary is run in daemon mode you will get the pid file you need. You can specify the pid file location in the command options like so

ar_sendmail -d -p ./log/ar_sendmail.pid

Any relative paths are expanded from the app directory. You can of course use an absolute path if you wish. The file gets removed on exit as you would expect.

The other major addition is not as visible. Its a Ruby based init.d script for managing mailer startup for one or more apps. It uses a yaml based config file where you specify the app settings for each app that needs a mailer instance running. See the README and demo config for more info.

My date_time_text_field_helpers plugin allows you to use text input fields for dates and times instead of the Rails standard select dropdowns. The plugin was up on Google Code but since I am mostly using git now, I just had to bring it over GitHub.

Updates will only be pushed to git from now on. The Google Code page will stay up for a while, until such time that I remember to pull it down.

If you haven’t seen it yet, Google has a project in its labs for the navigation of search results with keyboard shortcuts. Its great for geeks who love the keyboard.

Well a reader at LifeHacker knocked out the search plugin for Firefox. I took that and tweaked it for the Australian search engine for those times you need sumthin a little more local. So download it and stick it in your Firefox profile searchplugins folder. Then change the search engine in the search bar to be ‘Google by keyboard (AU)’.

Remember it doesn’t search in au domain by default, it just means the search results will have the ‘pages from Australia’ radio button under the Google search box.

When writing Rails plugins I like to be able to test them as a stand-alone library rather than inside a specific Rails project. I find it more productive and it avoids clashes with other plugins. It also allows you to test it against multiple rails versions.

One frustration I have had is when just want to use ActionView in your tests, because you might be writing a view plugin, if you require ‘action_view’ you get the following error:

MissingSourceFile: no such file to load -- html/document

This is because the path to the html-scanner library has not been added to the loadpath. This only happens in ActionController. But if we don’t need or want the overhead of ActionController the following line will include html-scanner in the loadpath and all will be well.