We ran into a font rendering problem when using Bootstrap, related to text-rendering: optimizelegibility.

We’re not quite sure which component(s) are at fault, but this is Chrome (with the inspector not open) 18.0.1025.168, Ubuntu 10.10, Neue Helvetica 67 Condensed Medium and Bootstrap 2.0.2. The symptom is that there is not enough space between text with some decoration (such as color change, underline, etc) and the surrounding text.

Here is an example:

<h2 style="font-size: 36px; font-family: 'HelveticaNeueW01-67MdCn 692710'">Facebook permissions 
  <u>are required</u>
   for using NeedFeed.</h2>

which rendered as:

The fix was to get rid of text-rendering: optimizelegibility, which Bootstrap currently applies to headings. We’ve seen some issues on this, like Text rendering fix for Android (and arguably for Windows) and Safari Eliminates Word-Spacing for H1 Tag That Uses Typekit, but aren’t really sure whether to point a finger at Chrome, the font, Bootstrap, aliens, some other component, or all of the above.

At least for now we just added the following rule to our CSS:

h1, h2, h3, h4, h5, h6 {
  text-rendering: auto;
}

We use Koala to make calls from NeedFeed to Facebook’s API. Sometimes, the Facebook API doesn’t work as we expect and we want to look at all the requests and responses.

It has been a pleasantly warm spring in San Francisco. In unrelated news, our network has been experiencing 10-40% packet loss. But wait! It turns out they are related after all:

That’s a shelf of office networking gear. Sitting on top of our DSL hub is an icepack. Which seems crazy, but let me explain.

The last week or so we’ve been experiencing intermittent packet loss. We’re in an old building where we’ve had trouble with both interior wiring and with the connection to our ISP, so I assumed that it was yet another related issue. I called the ISP and they offered to send a loaner modem to debug things. But swapping the modem didn’t make a difference. Frustratingly, the problem would often disappear during debugging.

To get more data, I set up SmokePing, a tool that lets you track latency and packet loss over time. It produces pretty graphs like this (color indicates level of packet loss):

Packet loss looks surprisingly variable and on a daily cycle. But why? At first I thought it was usage. But no, we start work earlier than noon and are out of here before midnight. Thinking it might be temperature, I went back and experimented.

Eventually I discovered that the problem was on our side of things, and specifically was the DSL hub. But I have never seen a hub fail like this; generally they work or they don’t. So I went to the fridge, got an ice pack, and plopped it on top of the hub. Within 10 minutes, we went from 20% packet loss to 0%.

That seemed crazy, so I got a cup of hot water and set the hub on top. Five minutes later we were up to 40% packet loss. Just to be sure I put the ice pack back on: quickly everything was fine again. I wrapped the icepack in paper towels, put it back so everybody could work, and went to buy a couple new hubs. Problem solved!

If anybody would like a very quirky thermometer, let me know. It’d give you an incentive to get off the computer when it’s especially nice out.

– William Pietri

Sending emails that look pretty is hard. We’ve put a lot of time into making ours look as great as possible on the outside, but we also have a neat trick for keeping code prettier on the inside.

Our application sends HTML emails, and recently we noticed that gmail wasn’t showing our links (which are styled to look like buttons, with a dark background, white text, and css3 roundy corners).

The original, inline css looked like this (newlines added for readability, but otherwise copy-pasted from what our code generated):

<td class="button" colspan="2" style="font-family: Helvetica;
font-weight: normal; text-align: left;
-moz-border-radius: 4px; -o-border-radius: 4px; -webkit-border-radius: 4px;
background: -webkit-gradient(linear, left top, left bottom, from(#95c620), to(#6d9432));
background: -webkit-linear-gradient(top, #95c620, #6d9432);
background: -moz-linear-gradient(top, #95c620, #6d9432);
background: o-linear-gradient(top, #95c620, #6d9432);
background: linear-gradient(top, #95c620, #6d9432);
background-color: #84AA1F;
border: 1px solid #6d9432; border-radius: 4px;
font-size: 14px; margin-top: 20px;
padding: 12px; text-align: center;vertical-align: top;">

Gmail helpfully stripped all of these styles.

Does the .count.count at the end of this rails3 code look like a typo?

Country.group(:continent).having('sum(population) > 400').count.count

Since we’ve received many requests for more information about our custom-built pair-programming desks, here are some pictures. If you like them, you can contact the guy who built them for us, Jeremiah Nielson. Thanks to Josh Susser for the idea.

UPDATE More info about the desks: each desk has 6 IKEA Vika Byske legs and 2 Humanscale M8 monitor arms which are strong enough to hold an iMac. (For development, we’re currently using custom-built Linux boxes with dual-DisplayPort video cards but we plan to switch to iMacs one day, hence the requirement that the monitor arms support an iMac.) We tried Dell 27” monitors but prefer the Apple 27” display because we find that the picture looks nicer and the glass screen holds up better than the plastic Dell screen. We also have some IKEA wire baskets under each desk to handle cables.

Like pairing? Work with us.

Just a little trick to share today. We use awesome_print in our app in place of puts or p or inspect. It’s awesome. One thing that makes it even better is being able to find out where you left your print statements before committing and having a link to them through your IDE. Here’s how we do it in RubyMine:

Create a Live Template bound to “pap”:

puts "#{__FILE__}:#{__LINE__}\n===> $A$:"; ap $A$

Voilà!

While writing an integration test, we ran into a little problem with Facebook giving us an OAuthException.

We wanted to share a little trick for speeding up our database-backed tests during development. When we watched things closely, we discovered that the CPU wasn’t working very hard; the problem was all disk activity, disk seeks in particular. We could have solved this by getting a good SSD. But there’s a much cheaper way!