I’ve been using Sinatra for more and more projects, but there came a point this week when I realised that I was in danger of accidentally upgrading gem versions without testing first.

Dependencies in crisis

You see, my applications all use the system gems, and require "gem_name" to load the most recent local version.

As the number of applications on the server grew, I found that this had the effect of automatically upgrading all my applications whenever I upgraded a gem, whether intentional or otherwise.

Now I like to take advantage of bug fixes and new features of the latest releases whenever possible, but I don’t necessarily want to upgrade every application in a single mammoth coding session, or have to hold back the deployment of a new application until the others have been upgraded and fully tested.

Gem and version dependency control

It dawned on me that I needed some control over both the actual gems and the versions each application used.

Simplicity

The simplest approach is to control what it available in the application load path before loading it in the usual way, and these are the commands for the job.

gem "gem_name", "gem_version" require "gem_name"

I tried this with some success, and quite a few of my applications are still using this method for now. But I decided to try using Bundler as a long term solution.

Bundler

If you want to know about Bundler I suggest you try the github repository or some of the posts on Yehuda Katz blog.

I found it pretty easy to integrate with Sinatra by following these instructions, and my Gemfile looked like this.

source "http://rubygems.org" gem 'sinatra', '1.0' gem 'haml', '3.0.13' group :test do gem 'rspec', '1.3.0', :require => 'spec' gem 'rspec-rails', '1.3.2' gem 'cucumber', '0.8.3' gem 'cucumber-rails', '0.3.2' gem 'webrat', '0.7.1' end

Testing with WEBrick went like clockwork, working smoothly with both RSpec and Cucumber, but when I tried to get things running on Passenger this is what I saw.

This had me stumped for quite a while. I reinstalled Bundler; checked out the installation of Passenger, my $GEM_PATH, and the Ruby environment; nothing worked.

The solution turned out to be much simpler than all that: add the Bundler gem to the Gemfile dependencies.

gem 'bundler', '0.9.26' gem 'sinatra', '1.0' gem 'haml', '3.0.13'

I wish it had occurred to me earlier, but the simple ones never do. Anyhow, my Passenger deployments work perfectly, and I’ll be migrating all my Sinatra apps over to Bundler.

Capistrano integration

And if you, like me, want to use Bundler to manage dependencies during Capistrano deployment, you might like to try these useful recipes.

There’s no better way to learn a new language than to actually use it in real life. My Nature Notes started as a project for my partner in PHP, CodeIgniter actually, but progress was slow due to an enjoyment deficit.

Testing is the main reason that I grew unhappy with PHP, most of the tools were there, but the integration was patchy: the basics are all there in Ruby and it’s associated development frameworks and integrating new packages via ruby gems or plugins is simple.

I started using the built-in Rails testing tools, but for no particular reason I’ve moved on to RSpec for unit and functional Rails model and standalone Ruby code testing coupled with Cucumber based integration testing. I’ve found that I need both.

Cucumber tests try to exercise the whole software stack – views, controllers, models and even the database. The use of natural language makes it easier to translate user stories into the appropriate tests, though it still needs some discipline to ensure that the edge cases are covered: I don’t think clients could write these as acceptance tests.

Involving the whole stack makes tests a little brittle, how specific is too specific? I’ve managed to break tests by removing fullstops (periods) from the rendered HTML!

I think that this is where unit and functional testing with RSpec at the model level is indispensable. I test model associations, validations and custom business logic in that order, I draw the limit at all the ActiveRecord CRUD functionality.

I’ve found that the development environment hasn’t really changed in the move, the same basic toolkit does PHP and Ruby.

I regularly use several code version control systems including Subversion, Git and Mercurial. Recently though I’ve increasingly turned to Git and GitHub. Like most good tools the more you use it the more attached you become, so I’ll have to force myself to use the equally fine Mercurial again soon. I love these distributed tools.

TextMate is my editor of choice for Rails development. I’ve tried to use Netbeans IDE, I use this for Java, but it seems like overkill. TextMate is quicker, simpler and provides the tools I need via the a range of bundles.

I have to admit that the code syntax highlighting is the most useful feature because I like using the command line too much, but I’m increasingly using code completion and I’m going to try the Zen coding bundles for HTML and CSS, I don’t like the default tools much.

That’s a round up of my current practice, more about the resulting software once I’ve decided to move on to a public beta.

I’ve used Ruby for scripting, and deploying PHP applications with custom Capistrano recipes for years now, but I’ve never tried any of the available web frameworks.

This week I switched to Ruby on Rails, and I’ve accomplished more in a couple of days than in a couple of months with CodeIgniter.

I’m not trying to claim that there’s anything fundamentally wrong with PHP, so don’t beat me up over it, but I find working with Ruby and Java much more intuitive, enjoyable and productive: it’s a personal choice, I feel more inspired.

I’m particularly loving the default support for unit, functional and integration testing; I now feel in control of my code and I’ve yet to explore the full range of testing frameworks and approaches available for Rails.

I know that CakePHP mirrors Rails functionality very closely, but I’m afraid it’s the PHP language that I find too ugly to love – personal choice again, don’t shoot – consequently this is one developer who may have written his last line of PHP code…… maybe.

I’m now hoping to have the first release of the nature and wildlife recording application I’ve been promising Clare for…… much too long, up and running in the next couple of weeks.