Pelargir

vizres renders the body of an HTTP response from inside a Rails functional test. It used to be a plugin, but now it’s a gem. Why? Because Rails gems are the new hotness. Now go get it.

I’m at the Ruby Hoedown in Huntsville this weekend. Being around so many brilliant geeks encouraged me to release a gem I’ve had sitting in the hopper for several weeks.

finder_filter encapsulates a pattern I find myself using quite frequently in Rails. Namely, looking up an instance variable before an action. For example:

class UsersController < ActionController::Base
  before_filter :find_user, :only => [:show, :edit]
  
  def show
    # do something with @user
  end
  
  def edit
    # do something with @user
  end
  
  def find_user
    @user = User.find(params[:id)
  end
end

Sticking the finder in a before filter keeps the code DRY, but it still takes several lines to do this. finder_filter reduces this to a single line of code:

class UsersController < ActionController::Base
  finder_filter :only => [:show, :edit]
  
  def show; end
  def edit; end
end

There are other options to customize the column and param used in the lookup. Check out the README for full details.

To install the gem on your system:

gem sources -a http://gems.github.com
sudo gem install pelargir-finder_filter

Then open environment.rb in your Rails app and add the gem as a dependency in your initializer block:

Rails::Initializer.run do |config| 
  config.gem "pelargir-finder_filter"
  ...
end

If you have any comments or suggestions, I’d love to hear from you. Contact me through the finder_filter project on GitHub.

BarCampRDU 2008 came and went. It was quite enjoyable. There wasn’t as much grub as last year, but I thought the topics were more interesting.

I gave a talk on pair programming during the afternoon. It really became more of a group discussion, which was exactly what I was hoping for. Some attendees have requested the slides so I’ve attached them to this post as a PDF.

The slides have been edited somewhat. I gave this same presentation at Agile ITX last month and it was an hour and a half long. I had to cut out a few things for BarCamp. But the central ideas are still there.

Want to pick a certain set of key/value pairs from a Ruby hash? You might do this:

hash = {:foo => "bar", :bar => "baz", :baz => "boo"}
hash.select { |k,v| [:foo, :bar].include?(k) }
 
# returns [[:foo, "bar"], [:bar, "baz"]]

Kind of messy. We can do better by reopening the Hash class this way:

class Hash
  def pick(*values)
    select { |k,v| values.include?(k) }
  end
end

Now our selection works like this:

hash = {:foo => "bar", :bar => "baz", :baz => "boo"}
hash.pick(:foo, :bar)
 
# returns [[:foo, "bar"], [:bar, "baz"]]

Ruby is a wonderful language. This is one small example of how having access to existing classes can be incredibly powerful. With this power comes great responsibility. Wield your power wisely.

I’ll be speaking at the Agile ITX conference in Reston, Virginia on June 27th. My presentation is titled Pragmatic Pair Programming and is based on the many diverse pairing experiences I’ve had over the past six years. Mention pair programming in any crowd of programmers and you’ll get two responses: adoration or outright hatred. Why is pairing so controversial? Does it have any tangible benefits? That’s what we’ll be exploring together. Agile ITX is shaping up to be a great conference with many top-notch presentations. I’m excited about getting the chance to participate. Hope to see you there.

I’m a freelance software developer which means I generally work from home unless a client needs me to be on-site. I don’t mind being alone to a certain extent, but after a few straight weeks it can get pretty lonely.

Recently, I’ve started doing what I’ve termed “nomadic programming.” Namely, spending the day roaming between various wi-fi hotspots instead of working from home. This has worked really well for me. So well, in fact, that I think the concept needs to start spreading.

Now I realize there are many freelancers out there who already do something similar to what I’m describing. I think it’s worth “formalizing” the process, though, by laying out the pros and cons of nomadic programming, and then giving some advice on how to actually go about doing it.

nomad [noh-mad]: (1) a member of a people or tribe that has no permanent abode but moves about from place to place, usually seasonally and often following a traditional route or circuit according to the state of the pasturage or food supply. (2) any wanderer; itinerant.

Why be a nomad? Why not stay at home? While staying at home has its benefits, here are some reasons why a nomadic lifestyle might be a better fit for you:

• It zaps loneliness. Let’s face it, being at home by yourself isn’t the most exciting of propositions. Many of us have families and that helps a lot with the loneliness factor. For those of us who don’t, getting out into an environment with other people can defeat that pervasive sense that we are the only person left on earth. (Anyone who has seen “I Am Legend” will know what I’m talking about.)
  
  
• It increases focus. This may seem counter-intuitive at first glance, but let me explain. When I’m at home, the temptation is to wander over to the kitchen for a snack, pop in a DVD, or conveniently set aside my work to get to those chores I’ve been meaning to do. The primary reason this happens is because my surroundings are familiar. It can be hard to focus on work at home because we’re used to doing so many other things there… relaxing with the family, mowing the lawn, picking up after the kids, sleeping, etc. If you’re anything like me, you have a natural tendency to procrastinate and substitute household activities for billable work. Nomadic programming kills this temptation. It places us in an entirely new environment with a new set of stimulations. It snaps us out of “being at home” mode. We can’t very well be tempted to grab a spot on the couch and turn on the TV when our home is several miles away. I’ve found that placing myself in fresh environments every so often greatly increases my ability to focus on the task at hand.
  
  
• It boosts productivity. Hand in hand with focus goes productivity. I get so much more done in a new environment than I do at home. I’m not completely sure why this is yet, but part of it probably has to do with the way our minds work. When we get used to routine, time passes more slowly. We get bored. We get distracted. In a new environment, our minds have to be alert to take in the new stimulation that’s being provided. This alertness yields greater productivity gains. On Monday this week, I spent three hours in the morning coding by myself. I then spent three hours during the afternoon coding with a friend at Bruegger’s. I was twice as productive during the afternoon as I was during the morning. This isn’t because I’m not a morning person. It’s because being away from home and interacting with a good friend yanked my mind out of the routine it had slipped into, and the code flowed more freely as a result.
  
  
• It’s a great way to network. With the aid of new location-aware tools (which we’ll cover shortly), nomadic programming is a fantastic way to meet new people that you otherwise wouldn’t have been exposed too. Let’s face it, the only people we interact with at the local user groups are other programmers just like ourselves. Contrast this with the coffee shop or the park. There is potential to run into a fellow entrepreneur, an insurance salesman, an airline pilot, a night stocker from the grocery story, the guy or gal who delivers our mail, etc. Exposure to a whole new set of people becomes not just possible, but likely. This is, again, an area where routine can work against us. If we get used to being around the same set of people all the time, it has the potential to kill not only our networking skills, but also our chances of meeting people that will stimulate our minds in ways that would not otherwise be possible. We shouldn’t just be learning from fellow geeks, folks. We should be branching out and learning from all sorts of people. Nomadic programming enables this kind of networking to occur naturally.
  
  
• It’s just plain fun! Spending your morning sipping a latte, making a new friend, then choosing to migrate over to Panera together to grab lunch and share ideas can be downright enjoyable. It’s not all about cranking out the code to meet the deadline, folks. If your work is never fun, you’re in the wrong career. Being a nomad can make programming fun again.

These are just a few of the many positive aspects of nomadic programming. What about the downsides, though? It can’t all be a stroll through the flower bed, can it? No, it can’t. There are some bees waiting to sting us:

• It can be time consuming. Being a nomad requires travel time between the different places you visit. Depending on how far you travel, this can eat up time that could otherwise be used for billable work.
  
  
• It can be expensive. Many places that offer free wi-fi right now are businesses that expect to turn a profit, and rightly so. It’s not ethical to take advantage of a work location without making it worthwhile for the people providing that location. This means that when you visit a coffee shop, you should order something (preferably something other than water). Add small dining costs like this to the gas you blew getting here and the expense can begin adding up.
  
  
• It can distract from more important things. For those of us with families, it can be easy to get carried away with being a nomad and start routinely staying out quite late. Midnight coffee shops don’t help here. It’s very tempting to just keep working, especially if you’re having good, productive interaction with fellow nomads. This can quickly begin eating away at the time you should be spending with your family. It can be equally tempting to start skipping out on home chores, responsibilities at church, etc.

While the downsides to being a nomad are real, they can definitely be managed. Wi-fi is getting fairly common, even in more rural areas, so travel time can often be limited. Expenses can be kept down by ordering cheaper items and putting in an extra hour of billable work to make up for what you’ve spent. Distraction is a harder nut to crack, but it can definitely be overcome with a dose of self discipline and some verbal accountability to your family and friends.

When balanced against the advantages, it’s clear that nomadic programming is a good thing overall. So once we decide the benefits are worth it, how do we actually go about being a nomad? There are a few simple, easy guidelines to follow and several tools that can make the process easier and more fun. We’ll find out what to do (and just as importantly, what not to do) in my next post.

In the meantime, drop a comment and let us know if you’re doing nomadic programming.

After spending nearly an hour tracking down where a particular TextMate bundle was coming from, I have surmised that there are no less than four places on my Mac’s hard drive where bundles may be lurking. In no particular order, they are:

~/Library/Application Support/TextMate/Pristine Copy/Bundles
~/Library/Application Support/TextMate/Bundles
/Applications/TextMate.app/Contents/SharedSupport/Bundles
/Library/Application Support/TextMate/Bundles

I just ran into a problem configuring a Rails app to deliver email through Google’s SMTP servers. ActionMailer doesn’t support TLS/SSL which is required by Google. Fortunately, the action_mailer_optional_tls plugin provides this functionality.

I wanted to host my SMTP settings in an external YAML file so I wouldn’t end up checking my username and password into the repository. (The YAML file is placed on the production server and a softlink is created during each deploy.) For some reason, I kept getting “connection refused” messages whenever I tried to send email with this configuration:

# smtp.yml
production:
  address: smtp.gmail.com
  port: 587
  tls: true
  domain: foo.com
  authentication: :plain
  user_name: someone@foo.com
  password: secret
 
# production.rb
smtp = YAML::load(File.open("#{RAILS_ROOT}/config/smtp.yml"))
ActionMailer::Base.smtp_settings = smtp[Rails.env]

The problem was the hash returned by YAML. The keys were strings, whereas ActionMailer was expecting the keys to be symbols. The fix was to make the hash use indifferent access:

...
ActionMailer::Base.smtp_settings = smtp[Rails.env].with_indifferent_access

That cleared up the “connection refused” problem. Now my app is sending email like a champ.

railspdf is a plugin that adds templating support for the pdf-writer gem to Rails. The project was last updated in January of 2007, but worked fine up until the 2.1.0 release of Rails which broke several things.

I’ve forked the project on GitHub and tweaked it to run under 2.1.0. I also added support for custom helpers. Your PDF templates can now call methods in helpers with the same name as your controller (which is the expected behavior anyway). I’ve also started maintaining a CHANGELOG.

OS X seems to get confused when I disconnect my MacBook from an external monitor. This confusion sometimes leads to the hot corners feature not working. This is definitely a bug in Leopard that needs fixing. Until that happens, restarting the Dock is a quick solution to the problem. This can be done through the Activity Monitor, but I think it’s easier to just run this script which I stole and modified:

#!/bin/sh
DOCKPID=`ps aucx| grep Dock | awk '{ print $2; }'`
kill $DOCKPID