As Ian just posted, Pivotal Tracker won a Jolt award tonight. Here are some early pictures from the event.

The Jolt award for Pivotal Tracker

Edward with the Jolt award for Pivotal Tracker

Ian with the Jolt award for Pivotal Tracker
As Ian just posted, Pivotal Tracker won a Jolt award tonight. Here are some early pictures from the event.

The Jolt award for Pivotal Tracker

Edward with the Jolt award for Pivotal Tracker

Ian with the Jolt award for Pivotal Tracker
I’m very pleased to announce that Pivotal Tracker has won the coveted Jolt Award, in the Project Management category.
I want to thank the judges for selecting Pivotal Tracker above a category dominated by Agile project management tools, and for rewarding Tracker for innovation.
I want to thank the community who have used, evangelized, and supported Tracker, and in particular Obie Fernandez, Ward Cunningham, and Nivi; plus everyone over at Engine Yard for hosting the app.
And of course I want to thank and congratulate the development team and visionaries, particularly Dan Podsedly, Alex Chaffee, Rob Mee, Mark Michael, and Edward Hieatt for envisioning and then building the tool that we’ve come to depend on.
We’re interested in running some sort of javascript validation and syntax checking suite on one of our projects. JSLint looks reasonable for the framework and can be run from the command line with Rhino.
If you have experience with or thoughts about the idea, please share.
I came across an interesting post on Overcoming Bias today about the Planning Fallacy. In short, the evidence shows that individual predictions generally occur in a rosy inaccurate world where everything goes according to plan, even when interruptions and setbacks are inevitable:
Buehler et. al. (1995) asked their students for estimates of when they (the students) thought they would complete their personal academic projects. Specifically, the researchers asked for estimated times by which the students thought it was 50%, 75%, and 99% probable their personal projects would be done. Would you care to guess how many students finished on or before their estimated 50%, 75%, and 99% probability levels?
- 13% of subjects finished their project by the time they had assigned a 50% probability level;
- 19% finished by the time assigned a 75% probability level;
- and only 45% (less than half!) finished by the time of their 99% probability level.
As Buehler et. al. (2002) wrote, “The results for the 99% probability level are especially striking: Even when asked to make a highly conservative forecast, a prediction that they felt virtually certain that they would fulfill, students’ confidence in their time estimates far exceeded their accomplishments.”
But it seems one can overcome this bias towards optimism by getting an “outside view” on the problem as it relates to the timelines on previous similar projects:
Buehler et. al. (2002), found that Japanese students expected to finish their essays 10 days before deadline. They actually finished 1 day before deadline. Asked when they had previously completed similar tasks, they responded, “1 day before deadline.” This is the power of the outside view over the inside view.
So there is a fairly reliable way to fix the planning fallacy, if you’re doing something broadly similar to a reference class of previous projects. Just ask how long similar projects have taken in the past, without considering any of the special properties of this project. Better yet, ask an experienced outsider how long similar projects have taken.
Pivotal Tracker, unlike other project management software, is built on exactly this idea of the outside view, via points and emergent iterations:
Tracker calculates future iterations based on historical performance. Focus on prioritizing and completing your stories; let Tracker take care of planning future iterations, based on actual progress.
It’s gratifying to see that the emergent iterations are not just easier for the user, as there’s no need to manually specify them – they’re also more likely to be accurate, as they’re based on an external view of your own progress. Yet another reason to look to Tracker for your project management needs.
image.crop!().resize!()
An EngineYard-hosted project had an issue with monit attempting to restart
mongrel too often. It turned out that the mongrel processes were not
dropping pid files soon enough. The EngineYard-suggested fix:
Using Cucumber to test Capistrano deployment:
cap --dry-run will run Capistrano without completing the actual task
(e.g., deployment). Cucumber can then be used to write some nice,
story-like deployment expectations that search the Capistrano output to
document your project’s deployment process and ensure the documentation
remains valid. Something like:
Feature: Deployment
In order to deploy the application
As an administrator
I should run Capistrano commands
Scenario: Deploying
Given I am working from the RAILS_ROOT directory
And the parent directory is a Git repository
When I run a deployment task
Then 'scm_user' for the deployment should be derived from the Git config for the remote origin
Scenario: Deploying to demo
Given I am working from the RAILS_ROOT directory
When I run 'cap demo deploy'
Then the deploy should succeed
And the deployed code matches the latest 'web/stable' tag
And the deployed code should be marked with a new 'web/demo' tag
More on this to come.
Using Selenium to ensure unique IDs in your DOM:
# ----------------------------------------------------------------------
# The examples below illustrate the technique with the Prototype and
# jQuery libraries, respectively. Both use Pat Nakajima's selenium
# helper for executing javascript in the tested browser window.
#
# For more on that helper, see:
# http://pivotallabs.com/users/patn/blog/articles/717-run-javascript-in-selenium-tests-easily-
# ----------------------------------------------------------------------
# ----------------------------------------------------------------------
# with prototype
# note the exception catching... prototype chokes on invalid IDs
# e.g., "invalid_id[][]"
# ----------------------------------------------------------------------
def assert_unique_ids
audit_json = run_javascript <<-JS
audit_ids = function() {
var results = {};
$A($$('*[id]')).each(function(element) {
if(element.id.replace(' ', '').length > 0) {
try {
if($$('#' + element.id ).length > 1) {
if( ! results.duplicates) {
results.duplicates = {};
}
var count = results.duplicates[element.id] || 0;
count ++;
results.duplicates[element.id] = count;
}
}
catch(err) {
// uncomment to capture invalid IDs
// var invalid = results.invalid || [];
// invalid.push(element.id);
// results.invalid = invalid;
}
}
});
return ($H(results).toJSON());
}
audit_ids();
JS
assert_equal({}, JSON.parse(audit_json)), 'Expected no duplicate IDs')
end
# ----------------------------------------------------------------------
# with jQuery
# additionally depends on the jquery-json plugin:
# http://code.google.com/p/jquery-json/
# ----------------------------------------------------------------------
def assert_unique_ids
audit_json = run_javascript <<-JS
audit_ids = function() {
var results = {};
$('*[id]').each(function() {
if(this.id.replace(' ', '').length > 0) {
if($('*[id=' + this.id + ']').length > 1) {
if( ! results.duplicates) {
results.duplicates = {};
}
var count = results.duplicates[this.id] || 0;
count ++;
results.duplicates[this.id] = count;
}
}
});
return $.toJSON(results);
}
audit_ids();
JS
assert_equal({}, JSON.parse(audit_json)), 'Expected no duplicate IDs')
end
We use Cruise Control on our Continuous Integration server and we have several ways of getting alerts about the status of the build, including email, RSS and the Cruise Control web interface.
Recently we noticed that the web interface and the rss feeds were taking very long to respond, on the order of 1 minute or more. After poking around, we realized that we had hundreds of serialized builds still on disk.
$ cd ~/OurCruiseDirectory/projects/OurProject
$ rm -r build-*
Then, to make sure this doesn’t happen again, we edited our OurCruiseDirectory/site_config.rb site_config.rb to decrease the number of builds we keep:
BuildReaper.number_of_builds_to_keep = 20
So it appears that the time Cruise Control responses take is directly proportional to the number of builds saved on the server.
How do you make a Mac not sleep?
Use the Energy Saver section of the System Preferences.
RubyMine 749 is out. Many of the existing bugs have been fixed, but a few new ones have been found. Notably, running specs with a “#” character in the describe string has problems.
The USPS has a nifty web service for addresses. The zip code lookup (which gives you zip+4) and the address standardization services were found to be useful.
If you’re using ack in project for textmate, be sure to edit your .ackrc file to include any non-standard file types you’re using.
A project had a dramatic speed up in their test suite by mocking out ActionMailer in tests. Something to consider if your tests cause a lot of email side effects.
field_named wasn’t working for us when using Webrat to drive Selenium. Our fork with the simple fix can be found here.
If you use Pivotal Tracker for open source projects, and would like to increase visibility into what your team is working on, you can now do so by making your Tracker project public.
As a project owner, you can enable public access for your project on the Project Settings page, by selecting the Public Access checkbox. The public URL to the project is to the right of the checkbox, in the format http://www.pivotaltracker.com/projects/xxx, where xxx is the id of the project. You can also append a dash to that URL, with a more descriptive name of your project, for example http://www.pivotaltracker.com/projects/xxx-My-Cool-Project.
Anyone you give the project URL to will be able view stories in your project, without having to sign in to Tracker. They’ll also be able request project membership by clicking the “Join This Project” button.