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.

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.

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

vendored_rails = File.dirname(__FILE__) + '/../../../../vendor/rails'
if File.exists?(vendored_rails)
  Dir.glob(vendored_rails + "/**/lib").each { |dir| $:.unshift dir }
else
  gem 'rails', "=#{ENV['VERSION']}" if ENV['VERSION']
end

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.

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.

Ruby, my hammer, is starting to make everything look a nail!

Remember this is GitHub, don’t like what I have done, then fork off!

UPDATE:
If you are getting an error running the ar_sendmail binary, this is due to GitHub to setting the permission on gem binary files incorrectly. The error would be

/usr/bin/ar_sendmail:19:in `load': no such file to load -- ar_sendmail (LoadError)
	from /usr/bin/ar_sendmail:19

To fix it you need to run this ugly (please let me know a better way to get a gem path!!)

GEMS_PATH=`gem env path`
GEM_NAME='adzap-ar_mailer'
sudo chmod 755 $GEMS_PATH/gems/$GEM_NAME*/bin/*

Now you should be able to execute it as a normal user.

UPDATE 2:
Fixed the update fix and made it version non-specific

UPDATE 3:
GitHub fixed the file permissions issue so the work around is not needed anymore.

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.

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.

$:.unshift Gem.searcher.find('actionpack').full_gem_path
  + '/lib/action_controller/vendor/html-scanner'

This finds the actionpack gem to get the full path. Then with the path to the html-scanner folder, adds it to the loadpath ($:). Now no more pesky load errors.

If there is a cleaner way, let me know.

My first changes were to remove the requirement for the year and month to be passed in as options. These now default to the current month and year if not included in the options hash.

I have also added the :month_name_text option to override the default text for the month name. The month name is basically the calendar header so this makes it possible to include the year in the header for clarity.

Now that I have forked it, I removed the gem spec files as it will not be published as a gem as that would confuse everyone and just isn’t the done thing.

Feel free to use and fork of course, these are just my preferences and maybe more to come. Thanks of course go to the original authors and contributors of the plugin.