I submitted a talk titled 3 Secrets to Effective Nomading. Check out the description and, if you feel it’s compelling and would want to hear it, please consider voting for it.

And by all means, if you have an idea for a talk, submit it!

I’m really looking forward to presenting again at RubyRX. I’ll be giving two talks this year. Git with Ruby will explore the Git source control system and how Ruby can take advantage of it. In Which Ruby Testing Framework Should I Use? we’ll briefly examine several leading testing frameworks and study the pros and cons of each. You’ll leave fully prepared to pick the best framework for your next project.

Let me know if you’re coming to the conference this year and we can link up in Reston. If you haven’t registered yet, what are you waiting for? RubyRX is a chance to network with the best and brightest developers in the area, and hear from thought leaders like Andy Hunt, Rich Kilmer, Joe O’Brien, and Chad Fowler. It’s a great way to keep your skills sharp in a down year.

In its initial version, Lindo assumed that your app was running at localhost:3000 (a fair assumption given the prevalence of Mongrel last year). Now that Passenger is on the scene, something better needed to be done. The reliance on a running app server was a disadvantage to begin with. Now Lindo doesn’t require anything to be running. It dumps the HTML to disk, fixes any relative asset URLs, and opens the file using your default browser.

Once you’ve written your first test with the assistance of Lindo, you won’t want to go back!

Lindo was developed by my company, Adeptware, and can be pulled from GitHub. I’ve also posted a brief introduction to Lindo and some basic installation instructions.

I really enjoyed the experience. If you’re at all interested in learning more about Radiant, or helping to contribute, I encourage you to consider attending the next hack night. Make sure you’re on the raleigh.rb mailing list to receive notification when it gets scheduled.

Have you ever wanted to force your users off your app if they go idle for a certain period of time? Many online banking sites use this technique. If your app is used on any kind of public computer system, this type of functionality is essential for maintaining the privacy of your data.

After installing the plugin, a small snippet of JavaScript is placed on each page. The JS polls the server every minute to see if the session is still active. If the user has been idle for at least an hour, they are immediately redirected to a timeout page. The session will not timeout as long as the user keeps clicking around. The timeout and polling intervals are both configurable.

The plugin is dead simple to install and configure. To get started:

script/plugin install git://github.com/pelargir/auto-session-timeout.git

Then hit the README for step-by-step instructions.

My initial goal with Fuelinator is to make mileage entry dead simple and to provide some compelling new features… for example, alerts via email or SMS when my vehicle’s mileage changes suddenly. This helps me track down maintenance problems early and gives me valuable information about what does and doesn’t improve my gas mileage. For example, I changed my air filter and inflated my tires last week. If my mileage changes drastically this week, I want to know. Now, Fuelinator will tell me.

The ultimate goal is for Fuelinator to save its users gobs of money on their gas bills. I haven’t made Fuelinator public yet, but if you’d like to participate in the beta program make sure you sign up. It’s going to be a fun ride!

>> a = [[1,2], [3,4], [5,6]]
>> puts a.transpose.inspect
[[1, 3, 5], [2, 4, 6]]

Each row becomes a column, essentially. This is fine and dandy for polite arrays. If one of the rows in the original array is not as long as the others, though, Ruby chunders thusly:

>> a = [[1,2], [3,4], [5]]
>> a.transpose 
IndexError: element size differs (1 should be 2)
  from (irb):3:in `transpose'
  from (irb):3

That ain’t pretty, especially if the intent behind using transpose is to render data in a nice columnar fashion. For example, what if we wanted to render a list of high school courses in columns, one column per semester? Grouping the courses by semester and then transposing would do the trick, but only if there were exactly the same number of courses taken each semester. If even one semester differs, Ruby will blow up. What we really want is for Ruby to just ignore the fact that each grouping may have differently sized arrays and transpose anyway, filling in the empty spaces with nils.

Here’s how to do just that:

class Array
  def safe_transpose
    result = []
    max_size = self.max { |a,b| a.size <=> b.size }.size
    max_size.times do |i|
      result[i] = Array.new(self.first.size)
      self.each_with_index { |r,j| result[i][j] = r[i] }
    end
    result
  end
end

Now we call safe_transpose on our matrix of courses and Ruby does the right thing. It calculates the length of the longest row and uses that as the baseline to perform the transposition. So our original example becomes:

>> a = [[1,2], [3,4], [5]]
>> puts a.transpose.inspect
[[1, 3, 5], [2, 4, nil]]

Nice and neat. Caveats: the code above hasn’t been refactored or tested. Your mileage may vary. If you see a better way to do this, let me know and I’ll post an update.

should route users's 'destroy' action correctly
 
The recognized options <{"action"=>"show", "id"=>"1",
"controller"=>"users"}> did not match <{"action"=>"destroy", "id"=>"1",
"controller"=>"users"}>, difference: <{"action"=>"destroy"}>

Turns out that rspec’s route_for method behaves differently when run against Rails 2.2+ due to the routing changes. The controller in question is setup as a resource, so the “destroy” action must be called via an HTTP DELETE, not a GET.

The failing line in the test looked like this:

route_for(:controller => 'users', :action => 'destroy', :id => 1).should == '/users/1'

The fix was simple enough:

route_for(:controller => 'users', :action => 'destroy', :id => 1).should == {:path => '/users/1', :method => :delete}

Hope this helps anyone who is experiencing the same problem.