2009: Branches + JSUnit + CI + IE = :-(

Wednesday, March 25, 2009

Interesting Things

Branches + JsUnit + CI + IE = :-( : Apparently it is difficult to manage IE’s cache in CI. One project apparently has a bat file on CI that clears the cache every 30 minutes. Another team solved this by making the cache directory read only. Often browser/OS combinations have some technique for disabling caching.
Test Swarm Alpha: this is a crowd sourced javascript testing solution (think seti@home for javascript testing) being developed by John Resig.

Ask for Help

“AR attribute appears to be skipped by text field helper?!” Apparently the model method is bypassed by the text field helper if a column of the same name is present in the underlying table. This was experienced in Rails 2.2.

Others have apparently experienced this in the past but a clear answer did not surface.

Safari 4 "Zoom Text Only" fixes Google Reader and GMail

Alex Chaffee

Tuesday, March 24, 2009

Problem: every since I upgraded to Safari 4 I’ve been annoyed that zooming in and out seems to confuse GMail and and Google Reader. When you zoom out, GMail refuses resize its panels, leaving a big blank space on the right side; when you zoom in, Google Reader loses its button panel at the bottom of the main area if you’re in a feed with a lot of entries.

Solution: go to the “View” menu and select “Zoom Text Only”.

New problem: the other setting is cooler for other sites, since it magnifies images and keeps non-fluid layouts from wrapping stupidly when you really need the text to be a little bit bigger. I wish there were a way to set it per site, but it’s a global setting. Oh well, no big deal, at least now I know where it is if it comes up.

Standup 3/24/2009: Browser History with Javascript and Page Based Json

Pivotal Labs

Tuesday, March 24, 2009

Interesting Things

Browser History with Javascript and Page Based Json: One of our projects solved the vexing problem of browser history for a page that has initial page provided json with subsequent ajax updates. A simple page back operation will display the originally downloaded data, not the updated data. The solution is to add a unique id for each page, and store these ids in a cookie. When an ajax request updates the page it removes its page id from the cookie. When you use the back button, each page checks to see if its unique id is in the cookie, and if it is not, it forces a reload.
Really Simple History was mentioned as another way to manage javascript/ajax history.
Rubymine Build 784 has the Weirdest. Bug. Ever.: This may only be a problem if you work on a mac and you need to enter capital letters in rubymine dialogs like find and replace ;-). Many of us are fans of intellij/rubymine, but we wish they had a better test process. To be fair, rubymine is in public preview, so expect the occasional bug or two.

Integrating Performance Optimization with the Rails Development Process

Tuesday, March 24, 2009 | Run time: 45:19

Lew Cirne, CEO of New Relic, outlines how they use their own RPM product to maintain and improve the performance of their application, which processes billions of transactions per month with the average response time under 40ms.

Pivots Speak on Scalable Teams

Pivotal Labs

Friday, March 20, 2009

Last week, Wolfram Arnold of RubyFocus interviewed Edward Hieatt, our VP of Engineering, and Davis Frank, one of our engineers, to try to get at the heart of how you build a scalable software development team.

The interview is posted on RailsLab, at
http://railslab.newrelic.com/2009/03/18/scalable-teams-part-1-communication

It’s a nice piece. We look forward to the second installment.

Inspect running ruby processes using xray and kill -3

Pivotal Labs

Friday, March 20, 2009

We made a code change and deployed to demo, and all the sudden some of our ruby processes were eating a ton of CPU against our full dataset.

In the java world you can send a SIGQUIT to any running java process and get a thread dump. Go ahead, run a java process and kill -3 it.

You can get this in the ruby world by using xray:

sudo gem install xray

Drop this into your code:

require "xray/thread_dump_signal_handler"

Now:

kill -3 <ruby pid>

Look in the log file where you’re sending stdout. You’ll see something like:

=============== XRay - Done ===============
/usr/lib64/ruby/gems/1.8/gems/eventmachine-0.12.0/lib/eventmachine.rb:224:in `call'
    _ /usr/lib64/ruby/gems/1.8/gems/eventmachine-0.12.0/lib/eventmachine.rb:224:in `run_machine'
    _ /usr/lib64/ruby/gems/1.8/gems/eventmachine-0.12.0/lib/eventmachine.rb:224:in `run'
    _ /usr/lib64/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/backends/base.rb:57:in `start'
    _ /usr/lib64/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/server.rb:150:in `start'
    _ /usr/lib64/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/controllers/controller.rb:80:in `start'
    _ /usr/lib64/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:173:in `send'
    _ /usr/lib64/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:173:in `run_command'
    _ /usr/lib64/ruby/gems/1.8/gems/thin-1.0.0/lib/thin/runner.rb:139:in `run!'
    _ /usr/lib64/ruby/gems/1.8/gems/thin-1.0.0/bin/thin:6
    _ /usr/bin/thin:19:in `load'
    _ /usr/bin/thin:19

(that’s thin patiently waiting to service the next request)

A one-line code drop-in results in a powerful new inspection tool. Pretty neat.

For bonus points:

ps ax | grep "thin server" | grep -v grep | awk '{print $1}' | xargs kill -3

For more bonus points, stick this in a capistrano task and grab the thread dumps from your logs, and you’ll have a cluster-wide snapshotting tool.

We kill -3′d our CPU-eating thins and discovered a directory scan problem introduced by a recent code change – totally obvious from the thread dump. Now we’re nailing it down with a failing perf unit test and fixing the problem.

Standup – 03/20/2009

Pivotal Labs

Friday, March 20, 2009

Help

SMTP monitoring – Is there a simple way to set up a rails app to receive email and act on it? Suggested solution was to set up something with action mailer and script/runner to do an action whenever an email is detected.

Git ambiguous SHA1 – A CI box was blowing up and complaining of an ambiguous SHA1 tag when trying to build a project. The 6 character shortened tag was apparently not recognize as unique enough even though nothing else in the git log had the same string. The team got around it by giving it a 7th character for that build but has no idea what could have caused it.

Complex RJS example – Does anyone have suggestions for where to look for good, easy to test complex uses of RJS? What is a good structure for your code and tests?

Replacing Fixture Scenarios – Fixture scenarios are blowing up on a project when trying to use Polonium. Anyone know of a good replacement?
Suggestions:

Check out Dataset
Could just be a load order issue?
Rewrite with standard fixtures or try Fixture Scenario Builder

Interesting

Xray – You can use the Xray Gem to get a java style thread dump when you kill -3 a ruby process. It can be really helpful for figuring out what’s causing your thin/mongrel processes to thrash. update: See Steve’s Post for more info.

Standup – 3/19/2009

Pivotal Labs

Friday, March 20, 2009

Help

One of our teams ran into an issue with javascript in their staging environment so they turned on asset package caching in development to try and hunt it down. It was a hassle to remove the all.js and all.css files over and over when developing in order to get Rails to regenerate them. Is there a better way? The suggested solution was to just shell out before each request in development mode with rm public/stylesheets/all.js

Interesting

Desert, Rails 2.3 and some pivotal plugins aren’t playing together very nicely at the moment, but it’s being worked on and should be resolved fairly soon. For now if you’re using Desert you probably shouldn’t upgrade.

Rochambeau!!! Story estimation as representative democracy

David Goudreau

Thursday, March 19, 2009

Here at Pivotal Labs we use our iteration planning meetings to not only hash out what we’re going to work on in the upcoming iteration but to estimate any unestimated stories that are within striking distance of the upcoming iteration. (We often estimate 1 iteration + 1 week of stories in case we end up delivering more stories than our iteration expects us to).

Over the past couple of projects I’ve been involved in estimating stories truly as a team – no ‘team lead’ fiats, no hour-long conversations about every possible implementation under the sun. We’ve adopted the Rochambeau approach to help get a fairly quick gut-check estimation of a story from all developers at once. Also known as Rock-Paper-Scissors, the way this works is as follows:

Discuss an unestimated story for up to 5 minutes
Then, 1-2-3 and VOTE!

This approach has served us in a couple of ways:

The expectation for the developer is that we’re looking for a rough estimate, not a precise measurement. This cuts down on endless technical one-upmanship.
The expectation for the customer is that developers have to have 1) general consensus among themselves about the risk/time/complexity of the story and 2) a defendable explanation of their estimation.

On my current project we use a 0,1,2,4,8 point scale for estimates, so each developer has 5 options to vote with. Even with this many possibilities, most stories end up with a clear general consensus and we go with that as the estimation, but in cases where there’s a 50-50 split OR an estimation round where people’s estimates are more than 1 level away from someone else in the group (for example, Paul votes for 1 point, George & Ringo vote for 2 points, and John votes for 4 points), that’s a strong indicator that developer’s assumptions are not all in line and that further clarification is required.

An added bonus is that the customers get to watch the developers vote in a concrete fashion and defend their estimates. That helps to bring the process more to life for them and to understand the concerns that we as developers have to regularly wrestle with. They also just love watching developers play RPS, I’ve come to discover.

For more information, check out this blog post for a discussion of team voting, spicy food, and photos.

iPhone Interface for Pivotal Tracker

David Stevenson

Thursday, March 19, 2009

I’ve been wanting to use Pivotal Tracker on my iPhone, so I wrote a little proof of concept using the Tracker API. I thought that a native application would be much more difficult than a skinned web application using ActiveResource.

I tried out Dashcode, Apple’s recommended iPhone-compatible front-end web development tool, but was disappointed. I basically found myself developing the entire application in javascript, actually using XMLHttpRequest to talk directly to the API. This would have been pretty neat if I could have pulled it off, but I’d rather develop a data-heavy application in rails than javascript.

I ended up using simple CSS to skin the application called UiUI. It’s the best looking iphone UI I’ve seen, with tons of elements to choose from. It’s missing effects, of course, being only CSS. I also used Heroku, a free and scalable rails deployment environment to host my application. With it, I was up and running with a functional tracker application in under 3 hours. Since then, I’ve added the ability to create and update stories.

Check it out, let me know what you think:
http://itracker.heroku.com

If you’re not on an iPhone, be sure to use Safari. It doesn’t look great in Firefox or IE.