In other, non-Rails Ruby projects it’s almost as simple: repeat the steps above and then include the require 'rubygems'; require 'bundler/setup' lines in your code.

But what about your standalone Ruby scripts (like this one)? Gem versioning is still very important so you aren’t bitten by incompatible library versions when you have to reinstall your whole system six months from now. So what do you do?

Well as it turns out, Rubygems itself still has the ability to force gem versioning:

By using the gem method and passing in the proper version string (using, of course, ~> instead of >=) Rubygems ensures that when that gem is next required, it will conform to that versioning string. And if it’s unable to find an installed gem that matches that string, it will raise a LoadError.

I can’t stress enough how important it is to implement and respect proper semantic versioning in all aspects of development. It’s a tiny amount of extra work up front to save you potentially hours of headaches further down the road. Just do it!

“Don’t worry about it. Start. Begin,” he replied.

He was right. I had made a classic mistake and in doing so I was ignoring our work processes with my own pet project idea.  I had ‘gone huge’ with the idea from the very beginning. I was planning user accounts, graphs, how to handle variant covers (a recent favorite variant for Green Lantern 51), and complex relationships for keeping a single master library of existing comic issues that would be separate from each user’s collection and reading log. Don’t get me wrong, it is good to be passionate about your idea and to know what challenges may be in your future but do not let that get in the way of getting your project going. Start small. Do the simplest thing possible. Constantly adapt your plans to your application’s needs. Be Agile.

That day I stopped mulling about things like how to order numbers that sometimes had letters on the end (see Batman 700U) and took my project agile. I started by building the simplest thing possible. I got going with no users, just an entry form with blank fields for comic title, issue number and date. Since then I’ve added a pop-up date selector, notes fields, the ability to enter ranges at one time, different collection views and a few other features. It has been almost a month but I’ve only worked on my application for 15-20 hours, at least 10 of them in the last couple of days. The ComicReads application is usable. It rocks! You could clone the ComicReads github repo, rake create & migrate your database, run ‘script/server’, and be ready to log your own collection but I don’t expect you to do so.

The most exciting part is that I have stopped logging my comic reading on notecards this past weekend and am now exclusively using my new application on my virtual machine. I haven’t added users yet, switched to mysql or solved several sticky issues— but I’m on my way. By starting with the features I needed— the ability to log the simplest and most essential parts of my comic book reading— I’ve made my project more exciting. Now that I have a working version, I find myself trying to work on it more and more. One day I will add user support, grab a URL, get a better design, and throw the system up for public use. Not this week though, I’ve got too much else to do.

Go ahead and get started. Begin! Throw out the users, forget connecting your application to twitter or facebook accounts, don’t worry about which database you are going to need, just go for it. Start by solving the problems that make your application interesting.

We took a look at the documentation and the library seemed to implement the same functionality as ruby’s standard library and then some. It even supports punycode! We installed the gem and tested it in irb with the URLs that had given us problems. It worked perfectly.

For the most part, just config the gem in your environment.rb file and append “Addressable::” before any instance of “URI.” in your code. Instead of “URI.parse(url)” you’ll now have “Addressable::URI.parse(url)”. But be sure to take a glance at the documentation because there are a few methods that don’t exist one-to-one in the libraries. For example: instead of calling URI.decode you would call Addressable::URI.unencode.’

We decided to run a test using ruby’s built in Benchmark library and compare the parse methods in each since that was the method used most often in our code. We started by requiring all the neccessary bits and whipping up an array of 1 million random URLs.

array = (1..1000000).map {
  "http://cloudspace.com/#{rand}?#{rand}=#{rand}\##{rand}"
 }

require 'rubygems'
require 'uri'
require 'addressable/uri'

Then here is the code to run the benchmark:

Benchmark.bmbm do |x|
  x.report("uri") { array.each { |u| URI.parse(u) } }
  x.report("add") { array.each { |u| Addressable::URI.parse(u) } }
end

And here is the result (the values are in seconds):

Rehearsal ---------------------------------------
uri  65.660000  23.670000  89.330000 ( 97.630597)
add 128.030000  22.270000 150.300000 (161.927209)
---------------------------- total: 239.630000sec

          user     system      total        real
uri  65.170000  23.140000  88.310000 ( 93.674252)
add 127.920000  22.600000 150.520000 (166.662719)

With a little bit of math on our own

Addressable takes almost twice as long as URI to parse the URLs. In our case, the time difference is still a minimal concern considering the benefits of having the URLs parsed to the more modern RFC. So we went for it and it is working great for us! Thanks Sporkmonger!

Then /^it should return a response code of "(.+)"$/ do |resp_code|
  response.code.should == resp_code
end

Then in your feature file you can use this step in multiple tests

Then it should return a response code of "301"
Then it should return a response code of "200"

Once you’ve built up a good step dictionary for your project you’ll absolutely squeal with delight the first time you write a new scenario using existing step definitions without opening the step definition file to make new steps.

As your library grows you’ll find yourself repeating the same series of steps in different scenarios. When this happens, you have identified a common task sequence that can be combined into a single “meta step”. It is important to keep separate steps for each of these tasks (see the Conjunction Step Anti-Pattern in the cucumber wiki) but its also nice to create a single meta step to help DRY up your code.

As a simple example, lets say you notice that you often check for both a response code of 200 and a “successfully updated” message on the page with these two steps:

Then it should return a response code of "200"
And the response body should contain "successfully updated"

You could add this single step to wrap it up:

Then /^it should be a successful update$/ do
  Then "it should return a response code of \"200\""
  And "the response body should contain \"successfully updated\""
end

This is a simple and useful tip that’s easy to implement, and you can start using this today, even on a project that’s been around for a while. Keep your code simple, and yourself sane.

If they need even more convincing, talk to them about the speed at which the Rails group is adding amazing new extremely useful features. Default Scoping, Only & Except Routing, Object.try and even better Conditional Get Support are all post 2.0 rails features that have been released in the recent months. (Ryan Daigle’s blog “Ryan’s Scraps” is a great place to keep up with the newest Edge Rails features, even the official Ruby on Rails blog links to his new feature explanations.)

Need even more convincing? Tell them about the stunningly active Rails community of developers: the blogs, the podcasts, the screencasts, the conferences and the user groups. Even the IRC channel rocks (#rubyonrails on freenode). A community this involved is sure to thrive.

This month Matthew Williams will be talking about Ruby Rad (using Arduinos to control electronic in Ruby). So if you ever wanted to build a robot, or maybe just your own personal electronics, you won’t want to miss this meeting. Matthew will have live demos of his electronics in action which should be fun to see.

Exciting!

Michael and I already picked up tickets to the conference.  The very awesome Gregg Pollack of Orlando’s own Ruby User Group will be giving the very first presentation of the conference. Tickets are gonna go fast, so if you’re in the Ruby/Rails scene, sign up soon. And, if you go, look for us. We’ll be the cool kids in the back of the room.