Jun 282010

Yikes, last week I was too busy working/in-meetings to squeeze in a blog post, so I’ll post a quick one to start of this week.

Since I’ve taken the plunge into developing a test suite for all of my new rails applications (most notable Concerto 2), I’ve struggled with the testing work flow.  Its very natural for me to write a piece of code, refresh my browser, verify the results, and repeat the cycle until I get it right.  The more official testing strategy requires me to write a test + the actual code and make sure the two of them mesh up before I even bother to refresh my browser.

Starting this process was a bit hard for me, probably because my test-writing skills weren’t so hot.  Many times my `rake test` results were failing not because there was an actual bug in my application code, but there was a bug in my testing code.  Unlike the application code which can be viewed in a browser, there really isn’t any way to know if your test is running as expected, so you really have to keep things as simple and straightforward as possible.

If you’re going to be developing in Ruby on Rails and using tests for your application, I’ve found a few tools that help out a lot:

  • autotest – Autotest is a tool that automatically runs the relevant portion of your test suite as you save files.  Essentially, when you save the file foo.rb autotest will automatically run the tests it thinks are related to foo.rb and nothing more.  In rails land, this saves a lot of time waiting for tests to run that are unaffected by a small or incremental change.  You can install some cool plugins to make the output red or green or use growl notifiers if you want… I just use the red/green plugin to spice up my terminals
  • CI Joe – CI Joe is a really simple continuous integration server.  A continuous integration server (automatic testing server) doesn’t make a whole lot of sense for single developer projects, but as more people are contributing and committing code it helps to have an automated system that is making sure the latest commit doesn’t break any tests.  I set this up for Concerto 2 development so everyone on the development team can quickly see if the HEAD is broken or not without having to ssh somewhere, git pull, and rake test on their own.

My one cautionary word about testing: don’t dive in too deeply.  It makes sense to develop really well formed test cases for critical portions of your application or code that is constantly being changed, but I’m not sure there is value in developing 12 tests to validate every possible form input and exact error message wording… at some point your time is better spent developing the application instead of supporting tests.

Jun 162010

Typically when I go to generate some XML-style documents in Ruby on Rails I manually code the XML syntax and manually escape and substitute the strings where I want them. This technique is pretty sloppy in to toss in a view, and relies on your ability to generate well-formed XML off the top of your head. (Its usually the escaping that becomes an issue.)

Thinking back, this the probably the quick and easy technique I picked up from my PHP development projects.  I could hand-code and debug some XML faster than I could find a suitable library, install it, and figure out how to work it.  Sometimes it’s just easier to do things the hard way.

As a rule of thumb, I think the hard way in PHP never translates well into Ruby on Rails.

Yesterday I was struggling to cleanly generate XML in Rails 3 because of the new default sanitation.   Using Builder was easy enough to generate the right XML structure for my KML file, but getting it to output was a challenge.  All of my < tags were getting replaced with < and such, and the raw parameter (<%=raw foo %>) wasn’t cooperating.

I ended up discovering that I could rename my file from show.kml.erb to show.kml.builder, and I wouldn’t have to mess around with any escaping or erb syntax at all. You can check out the code I used in this commit.  It might be just me, but I always struggle to find the appropriate documentation for these little nuances in Rails.  There is tons of code showing how to use Builder to build XML documents, but not one of them mentioned what to name your file.

This technique definitely took me longer than a quick pass through manually plugging in the string would have, but its a lot cleaner.  I don’t have to worry about escaping or generating valid XML, and if performance is an issue I can install a new XML builder to speed things up.

Jun 092010

I just bumped Flagship Geo to use Rails 3 Beta 4 (commit), luckily everything seems to still be working when I run my test suite.   Installing the new version of Rails is pretty easy, you just have to run `gem install rails –pre`.  You might want to sudo if you keep your gems system wide.

I use Passenger to serve most of my rails app on my development server and I had to change around the config a bit to get things working with Beta 4.  Specifically, I had to switch Passenger to treat my application like a Rack application.  I don’t know exactly what this means from an application-architecture standpoint, but I believe its related to the initialization procedures used to boot the application.  To make the switch, I had to edit my public/.htaccess file.  You might need to edit your apache virtual host config if that is where you store your Passenger config info.  The switch is pretty easy, switch every instance of “Rails” to “Rack”:

RackEnv development
RackBaseURI /geo

Also, bundler has been getting on my nerves.  When I upgraded rails, bundler was updated to 0.9.26 which is very confused about its gem locations.  From the command line, everything works great.  I can rake test, ./script/rails console, and do all of that great stuff but when I load my application up in the browser half of my gems can’t be found.  I needed to sudo gem install them to manually make them available system-wide, doing just `bundle install` would install them locally which was good enough for CLI work but didn’t cut it for Passenger.  I believe this might be fixed in bundler 0.10… due out ASAP?

Otherwise, everything is working great.  I look forward to the Rails 3 RC upgrade later in the week… hopefully the upgrade won’t be much harder.

Jun 032010

I’m working on adhering to the HTML 5 standard for things whenever possible in Flagship Geo.  While I haven’t gone all-out just yet and completely standardized things, I recently spent a few minutes working on code to help validate colors.

If you had asked me over the weekend if I care a lot about web-colors I would have said no, but then I discovered a bunch of stuff in the HTML 5 about colors.  There is a special “color” input box (not yet implemented anywhere) which is suppose to help people select colors and there is a pretty thorough section on how to validate what belongs in an official color box.

Since validators in Rails 3 are much more straightforward to implement, I took a few minutes to toss one together that validates simple color strings, i.e those hexadecimal strings that start with a pound sign.  If you’re looking to do something like this in your application, here’s how:


# Validates a hexadecimal color string as defined in the HTML 5 spec.
# This validator only works for the simple case and does not support
# any legacy formats. See http://dev.w3.org/html5/spec/Overview.html#valid-simple-color
# for the format spec.
class HexColorValidator < ActiveModel::EachValidator
  # Verifies a color string is 7 characters long and contains
  # only hex values after the pound sign.
  def validate_each(object, attribute, value)
    unless value =~ /^#[0-9a-fA-F]{6}$/
      object.errors[attribute] << (options[:message] || " is not a properly formatted color string")

… paired with …

class Layer < ActiveRecord::Base
 # Validations
 validates :color, :hex_color => true

In my example, I’m validating the color attribute that exists on the Layer model. You can view the commit on GitHub if you’d like.