Nathan Humbert's Blog

Rails Code QA Update

2011-09-08T15:08:00.000-07:00

I just released an updated version of Rails Code QA which now supports rails 3.0 and 3.1 as well as ruby 1.8.x and ruby 1.9.x

Installation
If you are using ruby 1.8.x all you need to do to install rails_code_qa in your rails 3.x app is add the following line to your Gemfile.

gem "rails_code_qa"

If you are using ruby 1.9.x you will also need to add the following to your test/test_helper.rb file

require 'simplecov'
SimpleCov.start 'rails'

Code Coverage
Rails Code QA takes care of picking which code coverage tool to use based on the version of ruby you are using. If you are using ruby 1.8.x code coverage is calculated using rcov and if you are using ruby 1.9.x coverage is calculated using simplecov.

Static Code Analysis
Rails Code QA also runs flog and flay to help you find other issues in your apps code.

Resources

Sitemap testing with doublecheck

2011-03-28T16:33:00.000-07:00

I hate releasing a new version of a site and finding out a few days later that I broke some of the pages. So I wrote the Doublecheck gem to help with post release testing.

Doublecheck

Doublecheck pulls a sitemap file and checks each URL listed, outputing a list of URL's for each HTTP status code that is encountered.

Installation

$ gem install doublecheck

Usage

$ doublecheck http://example.com/sitemap.xml

Notes

Get the code: github.com/nathanhumbert/doublecheck

Doublecheck is pretty simple at this point, it does one request at a time, so large sites may take a substantial amount of time to process.

Google's webmaster tools will eventually let you know if one of your pages has a problem, but it isn't a particularly fast way to find issues on your site.

Using Sinatra with Bundler to deploy on Heroku

2011-02-15T21:50:00.000-08:00

I decided to try using sinatra for a small project I started the other day. I normally work in rails and host my personal projects on heroku. Since rails 3 came out I have also gotten hooked on bundler. I could not find any single source that documented how to use all of these together nicely. Here is how I got it to work.

Gemfile

The gemfile is pretty basic, set a source for gems and include the sinatra gem.

source :rubygems
gem 'sinatra'

config.ru

This is the rackup config file which sets the app up to run in rack.

require 'rubygems'
require 'bundler'

Bundler.require

require './myapp'

run MyApp

myapp.rb

This is the sinatra file. Note that I defined a class (MyApp). This is very important because our config.ru needs the class as a handle for the 'run MyApp' call. An alternative would be to use "run Sinatra::Application" in your config.ru file.

class MyApp < Sinatra::Base
  get '/' do
    'Hello world!'
  end
end

Running locally

First make sure rack is installed, then run the following commands in the root folder and the app should be up and running locally.

bundle install
rackup

Deploying to Heroku

Just run the following commands in the root folder and the app should be up and running on Heroku.

git init
git add .
git commit -m 'Initial version of MyApp'
heroku create
git push heroku master

Additional resources

Easy data caching in Rails 3

2011-01-23T19:00:00.000-08:00

Three common forms of caching

There are 3 types of caching that are very commonly talked about in the rails community; page caching, action caching, and fragment caching. All of these are well documented and are great ways to cache varying amounts of content for your pages.

Is that all the caching I need?

Caching at the view level is great but it isn't necessarily the best fit for every situation. In some cases it may be easier to cache data at a lower level. Perhaps you want to cache the results of an external data request for a given period of time. None of the view caching methods would be a really great fit.

Lower level data caching

Rails 3 actually has a great method for caching data at a lower level than the view. It even uses the same caching store as action and fragment caching. ActiveSupport::Cache::Store allows you to store any serializable Ruby object. Rails even provides an already initialized cache store via Rails.cache.

Example usage and code

I used this on www.checkthesock.com to cache METAR queries. I was using current_metar a gem I built that pulls metar data from ADDS. I made a model called CachedMetar to return cached results to the rest of my application.

Code walk through

This model basically returns the result of the block argument to Rails.cache.fetch the first time it is called. Any time it is called within the next 5 minutes it returns the value that was cached the first time. Everywhere I had previously been calling CurrentMetar::Metar.get_metar("ICAO code") I switched to call CachedMetar.metar("ICAO code") and that was all it took.

Testing

Testing is actually surprisingly easy. I used shoulda and mocha and here is what I ended up with.

Reference

SEO friendly maps with jQuery

2011-01-21T15:00:00.000-08:00

In my free time I am working on a social networking site for RC pilots. I have information pages for various RC airfields and I was looking for a good way to display a listing of the fields. Putting markers on an embedded google map is a great way to display this type of data to users. The method I have seen recommended for this is to make separate list and map views. I don't really think that is a great user experience though.

The main reason making two pages is suggested is that maps require many lines of code and JavaScript functions that will dilute your content. The solution I arrived at was to use as little javascript as possible to generate my map. I ended up accomplishing this by using javascript to parse the content of the page to generate the markers.

To be able to easily parse out the data I wanted to display on the map I ended up making my own microformat. I put a class of field on the div that contained each field I was showing on the page. In that div I put the content that I wanted to display in the information popup for each marker. Then in that div I put two spans that contained the latitude and longitude and gave them each a class. The results ended up looking like this:

Then I wrote some javascript to parse this microformat and generate markers for my map. I used jQuery selectors to select each field in the html. For each field the latitude, longitude, and html contents are selected. Then the add_marker method is called to setup the marker with that data. After the marker is created I hide the field div.

Users with javascript will see a map with a bunch of markers that have an information bubble when clicked on. Users that do not have javascript enabled will see a list of field information. The textual content is the same for both users, the users with javascript just get an improved experience.

Go to www.checkthesock.com/fields to see the end result.

Getting over assert_difference

2010-09-20T07:00:00.000-07:00

For quite a while now I have been using assert_difference or its close cousin from shoulda should_change. When I recently updated to a recent version of shoulda I noticed that they had deprecated should_change. The note in the shoulda documentation says the following: "This macro was deprecated because these tests aren’t as valuable as alternative tests that explicitly test the final state."

Ok, now what to do? assert_change is super easy to use, but does it really ensure that the desired action is actually happening? For example:

This example test asserts that the number of User objects in the database has increased by 1. No real guarantee that it was actually the User object we were interested in creating.

Lately I have been trying to be a little more explicit about what is actually happening. It is taking a little while to get used to doing things this way but the results have been satisfying. Here is an example:

This example test asserts that a User object is getting assigned to the @user instance variable and that User object is no longer a new record.

Code Readability: Quick, Millions or Billions?

2010-09-08T07:00:00.000-07:00

3193490646

It is really easy to get the order of magnitude wrong on a number in code. I had settled into the habit of carefully counting my digits to make sure it was right until one of my co-workers pointed out a neat feature of ruby.

Ruby allows underscores to be inserted into numbers between any two digits. The underscores are purely cosmetic and do not affect the value of the number. This feature allows a developer to use underscores as an accountant might use commas.

3193490646      # standard representation of a number in ruby
3_193_490_646   # same value, much more readable

One less excuse for order of magnitude errors when using ruby.

A little looking around did not find any similar functionality in other languages, I checked into C/C++, Smalltalk, Python, Perl, PHP, Java, Javascript, Lisp, and Erlang. I am very curious to know if anyone knows of another language or particular implementation of one of the listed languages that supports similar functionality.

Thanks to Dallas Reedy for introducing me to this awesome feature of Ruby

Rails Code Stats gem

2010-04-04T22:15:00.000-07:00

When rails 2.2 came out it added some syntactic sugar by implementing a declarative block syntax for tests. The syntax for this looks like this:

test "make sure something really critical happens" do
  #code that tests for something really critical
end

While this syntax update is great some of the tools that come with rails still haven't been updated to handle it nicely. The stats rake task which outputs basic code statistics such as lines of code and methods per class still doesn't count these tests. In the past I just copied the rake tasks code and made a new rake task that could handle the new syntax as well as the format shoulda uses. After I started playing around with rails 3 and figured out how to put rake tasks in a gem I decided to write a gem that would generate an improved stats output.

Introducing Rails Code Stats

For this gem I didn't just copy the code and slightly improve the output. I refactored the code to clean things up as well as making it easier to extend functionality. One of the main changes was separating the code that calculates the stats from the code that displays the stats. Currently it still just outputs to the command line, but I intend to add the ability to have it output a HTML version as well. In addition to the new test syntax introduced in rails 2.2, I also added support for shoulda's test syntax and improved the code so that it should be quite trivial to add support for another test method syntax. Installing this plugin is as easy as adding the following to your rails 3 applications Gemfile.

gem 'rails_code_stats'

I am contemplating suggesting to the rails core team as an alternative to the current rails stats task. It seems that it fits with where rails 3 is trying to go, if you can easily swap out DB persistance layers and javascript engines why not modularize the code statistics tool as well. Please comment if you have any suggestions on improving this gem.

Rails 3: Code coverage with rcov

2010-03-15T22:09:00.000-07:00

UPDATE: Added support for ruby 1.9 and rails 3.1

I use rcov to make sure I have 100% test coverage on my rails projects. In earlier versions of rails I used the rails_rcov plugin to accomplish this task. Since rails 3 allows rake tasks to be imported by gems, I decided to write a gem with a rake task that reports on code coverage.

rails_code_qa

Currently rails_code_qa runs the unit, functional, and integration tests for a Rails 3 app. It generates 2 different coverage reports. Unit test coverage is calculated on models, helpers, and lib; functional test coverage is calculated on the controllers. Coverage is not calculated on integration tests. In my experience I have found this to be a good way to calculate coverage because it encourages you to write unit tests that cover your core code very well.

Install

All you need to do to install rails_code_qa in your rails 3 app is add the following line to your Gemfile.

gem "rails_code_qa"

Then update the bundle for the rails app with the following command.

bundle install

Bundler automatically pulls from rubygems.org and installs any dependencies (rcov) that rails_code_qa needs.

Usage

rails_code_qa adds a few useful rake tasks to your rails app.

rake rcqa              #all tests with coverage reports  
rake rcqa:units        #unit tests with coverage
rake rcqa:functionals  #functional tests with coverage

Future
I plan to add other code quality tools to this gem in the future. Likely candidates include flog, flay, and roodi. Feel free to leave a comment if you know of another code quality tool that you think I should include.

Rails 3: Heroku

2010-03-07T21:11:00.000-08:00

Last week I was pleased to discover that Heroku now supports the rails 3 beta. To use it you have to switch the application stack. The main Heroku stack (Argent Aspen) runs ruby 1.8.6 which does not work with Rails 3. Heroku enabled a new stack (Badious Bamboo) which runs either Ruby Enterprise Edition 1.8.7 or MRI 1.9.1 which both support Rails 3.

To get your Rails 3 app running on Heroku you need switch to your stack by following the Heroku stacks documentation. After you have the correct stack set up you need to make sure you have all of your gems set up in your Gemfile. I ran into issues because I use SQLite during development and I didn't have the required pg gem set up in my Gemfile.

That is all there is to getting up and running. I tried out a few of the add-ons, none of them seemed to break my app, but they did not all work quite right. The New Relic add-on reported on deployments but it still has not registered a single request.

Update: Rails 3 beta2 breaks on heroku when the New Relic add-on is added.

Rails 3: Loading rake tasks from a gem

2010-02-16T22:11:00.000-08:00

Several times in the last year I have wished that a gem could have rake tasks that would be loaded into a Rails app. I looked into it several times but kept running into dead ends with Rails 2. Since the Rails 3 beta came out I decided to try again, this time with much more success.

Basically you are trying to include a rake task in your rails app, the tricky part is you are trying to include the rake task from the gem it is inside of, which itself is being included in the rails app.

Gem file structure

my_plugin.gemspec
lib/my_plugin.rb
lib/my_plugin/railtie.rb
tasks/my_plugin.rake

lib/my_plugin.rb

module MyPlugin
  require 'my_plugin/railtie' if defined?(Rails)
end

This file is automatically included as part of including the gem using bundler. All we need to do in this file is require our railtie.

lib/my_plugin/railtie.rb

require 'my_plugin'
require 'rails'
module MyPlugin
  class Railtie < Rails::Railtie
    railtie_name :my_plugin

    rake_tasks do
      load "tasks/my_plugin.rake"
    end
  end
end

In this file we create a railtie class inside of our module, our new class has to be a descendant of the Rails::Railtie class. The 'rake_tasks' method is defined in the Rails::Railtie class, it takes a block that it then runs during the initialization of the rake environment in your app.

lib/tasks/my_plugin.rake

desc 'my plugins rake task'
task :do_something do
  puts "the rake task did something"
end

Just a really simple rake task.

Using your new rake task
After you have built your gem and included it in your rails app using bundler the task is integrated just like any of the default rails tasks.

$ rake -T
# ...
# rake doc:rerails    # Force a rebuild of the RDOC files
# rake do_something   # my plugins rake task
# ...

$ rake do_something
# the rake task did something

Resources
http://weblog.rubyonrails.org/2010/2/9/plugin-authors-toward-a-better-future
https://gist.github.com/af7e572c2dc973add221

Rails 3 beta: First impressions on a new app

2010-02-07T14:37:00.000-08:00

Initial application creation
Initial application creation is as easy as it has always been. The output is formatted a little better and you can create an app with a path instead of just a subdirectory name. A .gitignore file is created automatically as well as a few .gitkeep files on directories that don't start out with files in them, a really nice touch for those of us who use git.

script/* replaced by script/rails
This takes a little getting used to if you are used to the old script commands. Stuff like "script/console" doesn't work any more, it has been replaced by "rails console" or "rails c" if you prefer the shorthand version. "rails --help" will be your friend until you get used to the new commands.

Generators
The new generator system seems to be very well thought out and has all kinds of great new features if you want to modify templates or write your own generators. Even if you are just running the default generators things have improved a bit. The default templates have improved, for example div tags instead of p tags and use of a form partial instead of duplicating code in the edit and new views.

Testing
Testing out of the box does not seem to have changed much. The main thing I noticed is that most of the major testing tools are not yet working with the rails 3 beta. I tried out shoulda, rspec, and cucumber all without success.

Interesting Rails Methods: update_attribute

2009-12-28T07:00:00.000-08:00

Method: update_attribute
Module: ActiveRecord::Base
Documentation: Updates a single attribute and saves the record without going through the normal validation procedure. This is especially useful for boolean flags on existing records.

Notes:
This method actually does far more than just update an attribute. It updates the whole object without validations. This is fine if you just retrieved the object from the database but it can be a disaster if you have modified other attributes on the object.

Given:


Article.find(1)
#<Article id:1 title:"title" body:"first article">

Safe usage of update attribute:


article = Article.find(1)
article.update_attribute(:title, "new title")
Article.find(1)
#<Article id:1 title:"new title" body:"first article">

Unsafe usage of update attribute:


article = Article.find(1)
article.body = ""
article.update_attribute(:title, "new title")
Article.find(1)
#<Article id:1 title:"new title" body:"">

4 Ruby gems that will improve your rails app

2009-10-07T22:00:00.000-07:00

These four gems have helped my team improve the quality of our code. We weren't writing bad code before but these tools made it possible for us to take our code to the next level.

Flog

Flog helps you analyze the complexity of your methods. It looks at the number of assignments, branches, and calls in a method and creates a complexity score for each method. The lower the score the less complex the method is, generally making it easier to read, test, and refactor.

Flay

Flay analyzes code for duplication. It looks for structural similarities so things like variable names and whitespace won't keep it from detecting duplication in your code.

Roodi

Roodi parses your code and gives warnings on several different code design issues. Roodi includes a few different measures of code complexity such as cyclomatic complexity, line count, and parameter count as well as some useful lint style checks.

Rcov

Rcov is a code coverage tool for ruby, it shows you what code was run during your tests. While that doesn't guarantee that you tested all of your boundary conditions it does go a long ways in giving you confidence in your test coverage. My teams threshold for code coverage is 100%, anything less is treated the same as a failing test. If you are planning on using rcov with a rails app I would suggest the rails_rcov plugin.

Bonus FREE rails plugin

When my team runs tests on our apps we use rails_quality a plugin I wrote that runs all four of these gems during the testing process. Any output that is outside of the thresholds we have set is treated the same as a failing test. I would recommend this practice to anyone. It will make your code better and it pays off way earlier in the development cycle than you expect.

Upgrading rails apps without downtime

2008-10-30T23:50:00.000-07:00

I recently worked on an application that took messages from internal applications and queued them up before sending them to an external vendor. The application was built because the messages were important enough that loosing any messages sent during vendor downtime was not an option. Since all applications involved were using rails it was an obvious choice to develop the queuing app in rails and use a REST api to transfer the data into the queue.

The queue app went together quite nicely and everything was going smoothly until it went live and updates were needed to fix some bugs. Since the queuing app was the method for handling downtime outside of the main application it wasn't safe for the queue to go down while the main application was still up. Out of necessity I quickly came up with a solution.

The final solution consists of running more than one mongrel cluster, preferably on different servers. Proxy to all of those clusters from the apache instance that is serving the main application. This provides redundancy as far as the mongrel clusters are concerned and if the main apps apache server is down the application won't be generating any messages to be queued.

To upgrade the queuing app without downtime upgrade the code behind one of the clusters and restart that cluster, repeating until all clusters have been upgraded. This works very nicely, but it does require careful development to ensure that each update is compatible with the previous version of the application.

Using inject/reduce to create hashes in ruby

2008-09-14T10:17:00.000-07:00

I have been using map and reduce/inject (reduce is the new name for inject in ruby) quite a bit lately and learning quite a bit in the process. Map was pretty easy, inject on the other hand has been giving me some trouble. Recently I have been playing around with using inject with hashes, what follows is some of what I learned.

Given the following structure:

old_structure = [['username', 'bob'], ['password','secret']]

Converting to the following more appropriate structure can be done several ways:

new_structure = {'username' => 'bob',  'password' => 'secret'}

Method 1: Without using inject


new_structure = {}
old_structure.each do |element|
 hash[element[0]] = element[1]
end

Method 2: Using inject


new_structure = old_structure.inject({}) do |results, element|
 results[element[0]] = element[1]
 results
end

Method 3: Using inject with a little cleaner syntax


new_structure = old_structure.inject({}) do |results, element|
 results.merge( { element[0] => element[1] } )
end

Easy password hashing in rails 2.1

2008-08-26T22:09:00.000-07:00

I was working on a simple authentication system for a new project and got to the point where I needed to hash the password before storing it. I realized that this was a great opportunity to use the new dirty objects functionality that came out in rails 2.1.

First off, a quick explanation of dirty objects. Dirty objects provides the ability to tell what attributes of a model object have changed. For example, given an active record object "foo" with an attribute "bar", dirty objects adds a method "foo.bar_changed?" which returns true if the attribute "foo.bar" has been changed since the object "foo" was pulled from the database.

In the past when changing a password there has never been a really simple/elegant way to detect when the password had been changed and only then, hash the password. Now it is trivially simple. Adding the following few lines of code to the model does the job quite nicely.


after_validation :hash_password

def hash_password
 if self.password_changed?
   self.password = Digest::MD5.hexdigest(self.password)
 end
end

Now, whenever the password in the object is modified, whether it is via a form submission or just updating the object in script/console, save the object and the password will be hashed before it is stored. If there are any validations that don't pass the object will not be saved and the password will be the same as it had been.

Choosing good gems/plugins for your rails app

2008-08-21T20:01:00.000-07:00

Over the past few months I have been working on upgrading some of the rails applications I have been working on. I have been having quite a bit of trouble and a large portion of the issues stem from the gems and plugins that were used. In the past I have not had that much trouble with plugins and gems making upgrades difficult, so I sat down and tried to come up with some guidelines for picking plugins. These are the guidelines I came up with.

My plugin/gem selection guidelines:

Does it have a well defined goal?
Does it do something substantial?
Does it have a good record?

Does the plugin/gem have a well defined goal?
If the plugin you are evaluating does everything, that isn't necessarily a good thing. A plugin that does everything will likely to be harder to debug and has a higher chance of conflicting with something. A plugin that does one thing has a much better chance of doing that one thing very well.

Does the plugin/gem do something substantial?
If the task at hand is pretty simple it may be better to write the code yourself. When you are faced with a rails update, maintaining a few extra lines of code could end up being a lot easier than finding the latest version of the plugin and making sure the new version is compatible with your application.

Does the plugin/gem have a good record?
Does the plugin appear to be well maintained or has it been years since it was updated? Does it only have one contributor or does it have a good community built around it?

Example 1: Chronic (chronic.rubyforge.org)
Does Chronic have a well defined goal?
Yes, Chronic is a natural language date/time parser.
Does Chronic do something substantial?
Yes, it would take a lot of work to write a natural language date/time parser.
Does Chronic have a good record?
It looks pretty good, it has been around for a couple years, quite a few people seem to be using it, and it has survived several rails upgrades without big issues.

Looks like Chronic meets the guidelines fairly well. I have been using Chronic quite successfully for about a year and a half.

Example 2: Facets (facets.rubyforge.org)
Does Facets have a well defined goal?
No, it is an attempt to do just about everything.
Does Facets do something substantial?
Not really, it does a lot, but it is made up of lots of little pieces.
Does Facets have a good record?
Yes and no, it has a substantial community behind it which is good, it has been around for a little while which is good, but it has also had some very large structural changes which made different versions incompatible.

Looks like Facets doesn't meet the guidelines, based on that I would not choose to use Facets in one of my rails apps. Facets is a gem that came built into some apps that I work with, I have had a lot of problems with Facets and how it was used.

Example 3: file-tail (file-tail.rubyforge.org)
Does file-tail have a well defined goal?
Yes, it allows you to tail a file without having process the output of a system tail application.
Does file-tail do something substantial?
Yes, it would be a bit of work to write your own tail library in ruby.
Does file-tail have a good record?
Yes and no, it has been around for quite some time and seems to be very stable, but it doesn't have a big community and I haven't found many people that talk about using it.

File-tail doesn't meet all the guidelines perfectly but it should be reasonably safe. I recently used File-tail in an application and it has performed very well so far.

Issue with CSV files and excel

2008-08-11T21:17:00.000-07:00

I ran into an interesting bug with MS excel the other day. Turns out several versions of excel have issues with CSV files which have ID in capital letters as the first two characters of the file. Excel throws an error, "SYLK: File format is not valid".

One of my coworkers ran into the error when they tried to open a report I had sent them. It took a bit of time to track down, and made me question my ability to generate CSV files for a little while, but at least it was an easy fix. I just changed the first two characters "ID" to "id".

The two things I thought was really entertaining about this bug are first, you can export an excel file which had "ID" in the first cell to create an invalid SYLK file and second SYLK files are a Microsoft file format.

If you are interested in some more details here are a couple reference links:
Microsoft Support page
Wikipedia article on SYLK files

Using rails routing for easy search engine friendly URL changes

2008-06-14T12:30:00.000-07:00

In this entry I am going to show how to, in a very search engine friendly way, update a URL for a particular page in a rails website. The rails routing system provides named routes, which are a very nice way to change the URL for a particular page and have all of your links update without having to change code in a bunch of different places. That is a great start on moving a page, but it doesn't take care of any links from outside of your site that might be pointing at the old URL. The best way to handle that is to make it so that the old URL redirects to the new URL, your end users won't notice a difference but the search engines bots will take note and update their indexes.

First off if you are not familiar with routing and named routes in rails you might want to read up on it. The rails API docs have some pretty good material on routes located at http://api.rubyonrails.org/classes/ActionController/Routing.htm

Lets pretend we are moving "http://example.com/users/signup" to "http://example.com/signup". Our original named route might look something like this:


map.signup '/users/signup', :controller => 'users', :action => 'signup'

And the code for a link that pointed to it would look something like this:


<%= link_to 'Signup', signup_url %>

To change our URL we would simply change the named route to look like this:


map.signup '/signup', :controller => 'users', :action => 'signup'

All of the links that used the named route would automatically change to link to the new URL but the old URL would stop working. To change that we could add the following to the routes file


map.signup_old '/users/signup', :controller => 'users', :action => 'signup', :old_url => true

This would allow the old URL to work, but it would be best if we made it so that it redirected to the new URL so that search engines would switch over to the new URL faster. Notice that there is an additional parameter that is defined on the end of the second route, this makes it so that we can easily differentiate what URL a visitor arrived on the page with.

Now all we have to do is make a method we can use in a before filter that redirects the user to the same action, the redirect will automatically use the first route we defined (as long as we leave them in that order in the routes file). In the users controller we would add the following code:


before_filter :redirect_to_new_url

def redirect_to_new_url
if params[:old_url] == true
  headers["Status"] = "301 Moved Permanently"
  redirect_to({:action => action_name})
end
end

The lines in the route file would look like this:


map.signup '/signup', :controller => 'users', :action => 'signup'
map.signup_old '/users/signup', :controller => 'users', :action => 'signup', :old_url => true

Once you have this in place you only have to add a new route to move a URL in a search engine friendly way, and when you decide that all the external links and search engines are updated all you have to do is get rid of the route that points to the old URL.

What DRY is really about

2008-06-01T12:29:00.000-07:00

Lets start with what the acronym DRY stands for, Do not Repeat Yourself. That sounds like a pretty good idea, it makes sense, but what are we really trying to accomplish by keeping our code DRY? Ok, that was a rhetorical question but I know someone out there would probably respond by saying "Not repeating ourselves!", to which the audience would chuckle because everyone knows that isn't what DRY is about. DRY is really about making high quality maintainable code.

Lately I have been finding things in the code base that I am working with that indicates that some programmers have taken DRY way too literally and use it in places that reduce code readability and maintainability. For example I found something similar to the following ruby on rails code a while back.


if something == true
 temp_var = {:action => "foo"}
else
 temp_var = {:action => "bar"}
end
redirect_to {:controller => "main"}.merge(temp_var)

In this example of code, they are essentially avoiding a tiny bit of duplication, defining the controller. The thing is this code is more difficult to understand than the following.


if something == true
 redirect_to :controller => "main", :action => "foo"
else
 redirect_to :controller => "main", :action => "bar"
end

In the second example there is a slight bit of duplication, but it is also easier to figure out what the code is doing as you read through your if statement. That increased readability makes the code just a little easier to maintain. Additionally if you were thinking about changing this code there is a good chance that you would be changing the controller argument for only one of the two redirect calls, in which case the second code example is much simpler to edit. Of course there is another option, if the person writing this code originally had been aware of some additional functionality that the rails framework offers they would have used a named route which would get rid of all of the duplication while maintaining great code readability.


if something == true
 redirect_to foo_url
else
 redirect_to bar_url
end

Now that you know DRY isn't just about not repeating yourself, take a little extra time before removing duplication and think about whether the change gets you closer to the goal of having readable and maintainable code. If the change doesn't make your code easier to maintain consider leaving the duplication or even better do some research and find a solution that gets rid of the duplication without making things harder to read or maintain.

My first open source rails plugin: SafeDevEmail

2008-01-31T12:27:00.000-08:00

I just finished up the initial version of my first open source rails plugin. It is a fairly simple plugin which allows you to configure an email address that will receive all emails sent from your rails app while it is in development mode.

The plugin is available at code.google.com/p/safedevemail/.

To get started all you need to do is drop the plugin in your vendor/plugins directory and edit your mailserver settings in evironment.rb

Config Examples:

SMTP


ActionMailer::Base.smtp_settings = {
 :address  => "smtp.example.com",
 :port  => 25,
 :domain  => "www.mywebsite.com",
 :dev_mailto => "developer@mywebsite.com"
}

Sendmail


ActionMailer::Base.sendmail_settings = {
 :dev_mailto => "developer@mywebsite.com"
}

Lazy Migrations

2008-01-17T12:13:00.000-08:00

I was working on americanwinery.com and one of my coworkers asked me about a model that they hadn't seen before. Turns out it was from the early days of the site and it was never even used in production. It was a great candidate for a little code cleanup, so I removed the model and tests and started in on the migration to remove the table.

When I write migrations I generally make a point of making them reversible, so as I was looking for the original migration to copy the structure of the table I thought it would be much easier to just call the "up" from the original migration in the "down" of the migration I was working on. It was an interesting thought, turns out it is pretty easy to do.

For example, lets say you have a migration that creates a table named articles and it looks something like this:


class CreateArticles < ActiveRecord::Migration
  def self.up
    create_table :articles do |t|
      t.text :title, :body
      t.timestamps
    end
  end

  def self.down
    drop_table :articles
  end
end

A few days/months/years later you realize that you don't use that table and you decide to write a migration to get rid of it, here is what I would suggest:


class DropArticles < ActiveRecord::Migration
  def self.up
    CreateArticles.migrate("down")
  end

  def self.down
    CreateArticles.migrate("up")
  end
end

That is all there is to it. If you want to do a little more reading on this subject you can check out the API documentation (http://api.rubyonrails.org/classes/ActiveRecord/Migration.html)