Your browser is no longer supported! Please upgrade your web browser now.
Code posts:

Server Management Made Simpler

Many people assume that under the hood there are mystical unicorns and magical elves powering Harvest, but the reality is that we simply use regular servers in a datacenter to bring our applications to you. No elves involved. Anyone who has ever had to look after more than a few servers knows that getting all the servers into line is a bit like herding cats, and can be time consuming. It’s always important to know exactly what state your server configurations are in, and usually very important to know that all servers are in the same configuration state at all times.

It’s no secret that many of the fine folks who work on Harvest are Ruby experts (and thus quite easy on the eye). So when looking around at tools we could use to make our servers simpler to manage, we decided to try Chef. If you are not familiar with Chef, it comes from the folks at Opscode and is a powerful tool to manage server configurations, and perform common system administration tasks on a set of servers. Chef is written in Ruby and allows you to accomplish a fair amount of your system administration tasks by writing Ruby recipes to execute on remote servers. Chef makes system administration a bit more like application programming, in a sense.

While we work on getting Chef into daily use, and indeed while we improve our systems platform in general, we plan to share some of our experiences with Harvest users and readers of this blog. You can read up on some of the details of how we got Chef up and running quickly, a little look at how a Chef cookbook, recipe and role work together and we plan to bring you some more details in future posts. We’d love to hear from any Harvest users who are using Chef, or doing interesting systems or server management work (and invoicing clients via Harvest, naturally). What systems projects have you been working on?

How to Fix Dropdown Problems on Internet Explorer

Lately we found ourselves caught in some nasty dropdown problems. Some of our customers who use Internet Explorer were unable to to read their full project and task names on the new timesheet. Apparently it’s a browser bug specific to Microsoft’s Internet Explorer. All you need to do is Google “IE select box problem” and you’ll see the legions of disgruntled developers this control has left in its wake.  What follows is a recounting of our experience and our solution.

The Problem

Before the timesheet redesign, we did not specify a width on the Project and Task dropdowns.  For some users with really long project/task names, this meant their select boxes would extend past the right edge of their browser window.

The logical fix is to constrain the width of these select boxes. Well-behaved browsers have no problem with this approach. Internet Explorer, however, interprets a width on the select tag very literally.  The select box and all of the options are limited to the specified width, regardless of whether this truncates 90% of the option text.  For our users with long project/task names, this made the dropdown practically useless.

ie_select

The Solution

As with many of IE’s problems,  there are several workarounds out there, and unfortunately none of them are perfect.  We looked at three common approaches for solving this problem before we settled on the one we’re using now.

  1. Dynamically re-size the dropdown on mouseover.  The main problem with this approach is that (like anything triggered on mouse-over) the user experience can be very disruptive and seem “jumpy”.
  2. Custom select box, made from unordered lists and complex event handling.  Scott Darby’s stylish-select plugin for jQuery is a great example of this.  We gave this one a shot, but the custom select box does not retain browser’s default behavior with select, such as tabbing and using key stroke to jump to a certain selection.
  3. What ended up saving the day was this idea from Doug Boude.  It is surprisingly simple: re-size the select box on click, and set overflow: hidden on a containing div.  The hidden overflow will prevent the select from interfering with other controls to the right, while still allowing the full options to be displayed below.

Doug’s original solution required you to know the full width of your select box. Ours would need to compute this dynamically, so we wrote a simple Prototype.js class to encapsulate the event handling and to calculate the width of the select box.  You can check out a demo of the solution with code and some notes on how to use it for your problematic select boxes.  Disclaimer: this solution works best in IE7 and IE8. We do not recommend using it in IE6.

Hope you find this useful!

FutureRuby: A Programming Conference with Breadth

Just over a week ago I attended FutureRuby in Toronto, Ontario, Canada. From the single track of talks to the significant-other program to the unique post-conference parties, I have never participated in a better conference. I was especially pleased that four talks were being presented by Harvest customers.

The breadth of discussion at FutureRuby was incredible. If you are able to find a similarly diverse field of talks in a conference remotely near your area of expertise, I highly recommend it. You will be surprised to find how easily you can relate disparate topics to your career.

A quick rundown of presentations by Harvest customers after the jump.

Continue reading…

Ruby Denial of Service patch breaks BigDecimal to_f method

Harvest is built on the Ruby on Rails web framework, as such we constantly monitor for security issues with the framework and the language itself. A Ruby Denial of Service (DoS) vulnerability was announced almost 24 hours ago. The security of Harvest accounts is our top priority. All Harvest services were upgraded quickly to close this security hole.

Dee Zsombor, one of the Harvest’s prime hackers, uncovered further issues with the fixed Ruby version 1.8.7, which is patch level 173. This upgrade includes a flawed BigDecimal#to_f coercion method:

BigDecimal("10.03").to_f
=> 10.3

We are fairly confident Harvest users are not interested in this bizzaro-world version of rounding.

If you are running a Rails application and you have applied the Ruby 1.8.7 DoS patch, we’ve got the fix for you. Place the following hack in your environment.rb file (or an initializer if you prefer):

if BigDecimal("10.03").to_f != 10.03
 class BigDecimal
   def to_f
     self.to_s.to_f
   end
 end
end

If your interpreter is broken like ours was, this will cure what ails it. Big thanks to Dee for writing up this fix.

Be Defensive When Developing Against the Twitter API

Our humble apologies for yesterday’s hiccup, which saw thousands of Twitter expense and time entries duplicated in Harvest accounts which were linked to Twitter. We most regret the thousands of emails we delivered to your inboxes. The good news is that all duplicate entries have been rolled back and things are back in order.

Our code depended on Twitter’s API to filter out direct messages that had already been processed by Harvest. As of yesterday afternoon, we no longer depend on Twitter’s filtering options. Going forward, this type of failure in Twitter’s API will not impact Harvest users.

For those who are technical and curious, we’ve decided to get into the details a bit and let you know how it happened, and how we’re preventing it from happening in the future.

Continue reading…