2008

We’ve released the first version of the Tracker API. It’s a RESTful HTTP XML interface, uses a simple, token-based authentication mechanism, and allows you to query as well as update stories in your projects.

To get started with the API, read through the API Help page (it includes examples), and create a token on your Profile page.

We plan to enhance the API and add support for more operations and formats (including JSON) based on your feedback. Please let us know what you’d like to see added, either by email or via Satisfaction.

Standup 10/24/2008: Floating point number formatting and you

Adam Milligan

Friday, October 24, 2008

Interesting Things

We have a project that generates a lot of highly precise floating point numbers. However, we primarily want to display these numbers with only two decimal places of precision. In addition, we want to display these numbers with standard comma delimiters to the left of the decimal point.

Sadly, the Ruby #sprintf method provides the former functionality, but not the latter. What to do? Use a Rails helper, of course.

The NumberHelper from ActionView provides some useful functionality, so we used that. As it turns out, we found the best way to get the formatting we want to be using the #number_to_currency function with no denomination.

Also, rather than mixing the entire helper into the Float class for just one method, we chose to mix the helper into a nested class and expose only the functionality that interests us. The result looks something like this:

class Float
  class RailsNumberHelpers
    extend ActionView::Helpers::NumberHelper
  end

  def formatted
    s = Float::RailsNumberHelpers.number_to_currency(self, :unit => '', :precision => 2).chomp('0')
  end
end

Standup 10/23/2008: ARMailer warning!

Adam Milligan

Thursday, October 23, 2008

Interesting Things

ARMailer and ExceptionNotifer: A match not so much made in heaven.

If you use the ExceptionNotifier plugin (and if you don’t, why not?) and you install the ARMailer plugin, your app will stop sending the exception notifications. You have been warned. Initial reports suggest that fixing the problem is relatively straightforward.

For those not in the know, ARMailer is a plugin that queues all outbound email in your database, to be sent later by a cron job or something similar. Good for not clogging up your server with email processing during peak load.

Ask for Help

“Is it okay to load a Flash widget multiple times on a single page?”

General murmuring led to the conclusion that this works fine.

Standup 10/20/2008: Preventing Flash from Reloading

Joe Moore

Monday, October 20, 2008

Interesting Things

We discovered why a Flash widget was reloading itself: changes the CSS position value. We were hiding the Flash widget by moving it’s containing div off the page with position: absolute; left: -9000, and removing the class that had those values to show it again. It turns out that changing that position value causes the Flash to reload. By keeping the position:absolute setting when we both show and hide our container div, the Flash no longer reloads.

Ask for Help

“When using Rails’s date_select helper, is there a corresponding helper method to turn that date format into a Date object in the controller?”

Some Snippets are available, but how about a Rails built-in solution?

Standup 10/17/2008: treetop

Pivotal Labs

Friday, October 17, 2008

Interesting Things

Treetop – Ruby-based DSL for text parsing
Some projects tried jRails and prefer to use jQuery directly instead jRails is jQuery for Rails

OpenView conference

Edward Hieatt

Thursday, October 16, 2008

OpenView Venture Partners

Ian McFarland and I attended a 2-day Development Forum hosted by OpenView Venture Partners last week in Boston. It’s the second year that Pivotal Labs has participated in the event. Open View has a portfolio of companies from all over (Europe, Australia, the US), each of which has been working on implementing Scrum over the past year. The engineering staff from 10 portfolio companies attended the event. Jeff Sutherland (amongst other things the co-creator of Scrum) is a Senior Adviser to OpenView; he provides advice and guidance to the portfolio companies as they progress through their Scrum adoption, and he gave a talk at the Forum. Pivotal Labs was invited to speak and lead a discussion of on 2 core topics: Developer Testing and the Principles of Build.

Status & Issues

First, we heard from each company on how they were doing with their adoption of Scrum and on the following two questions on the subject of technical developer practices:

The goal of every sprint is to have fully tested quality software product ready to go live with customers. Where are you now with relation to this and what stands in your way of getting there?
The goal of every development team should be to have one piece of software code globally, and all work and testing is done on this one piece of code, with multiple builds with built-in testing done in a given day. Where is your team in relation to this goal and what stands between you and getting there?

The 10 portfolio companies come from a disparate set of industries and technical domains, so Ian and I were very interested to hear each of their histories with Scrum and the current issues they were facing with respect to these 2 questions on developer practices. Some were at a fairly advanced stage – they had good test coverage and a stable CI setup – and some were just getting started. The most frequently stated barriers to achieving the goals of fully tested software that’s ready to release were:

A perception that the team wasn’t big enough to allow for writing tests
An assumption that ongoing developer testing could potentially slow the team down
An assumption that adding tests to a code base would mean first stopping and covering all the untested code so far with tests, and that therefore it meant stopping for a long period to retrofit tests
A question of whether clients even wanted frequent releases (e.g. once per week) of the software
A perception that the team wasn’t big enough to allow for pairing
A lingering assumption that QA and not Developers should be responsible for generating all test coverage

Pivotal Labs’ talks

Developer testing

Pivotal’s first talk was on developer testing. There were two main points we wanted to make:

The best way we know to get a big jump in quality and to be able to frequently release new versions of software is to rethink who is responsible for testing.

Rather than the traditional model of a QA team being almost solely responsible, consider a shift towards the whole team being responsible, and in particular a much greater emphasis on developers owning quality. For many developers it’s a radical shift.

The most effective way we’ve seen for developers to own quality is through the disciplined and sustained practice of TDD.

During the talk I gave a demo of a simple example of strict TDD, which gave rise to some useful conversations; as expected, the reactions varied from “yes, that’s what we do” to “that makes no sense!”. Having coded solely with strict TDD for almost 9 years now, and being around Pivots who exclusively test-drive also, it’s always interesting to hear reactions of people coming to TDD for the first time. The idea that tests are the center of the development effort, and that code is to some extent expendable, is a radical shift in thinking. We also touched on the benefits TDD brings in addition to reducing regressions. I find that a useful question to ask is what TDD stands for: “Test Driven Development” or “Test Driven Design”. The notion that TDD helps in designing your object model brought up some interesting discussions (for example, mock objects came up).

We also tried to address the barriers to adoption that had been brought up:

When introducing tests to a legacy code base, rather than trying to immediately cover everything with tests right away, we suggested:
“Stop the rot” – from now on, attempt to test-drive everything, including bug fixes
Spend time each iteration/sprint adding some coarse-grained, high-level tests around the legacy code
Once there’s at least a basic safety net in place, spend time refactoring towards unit-testability
Gradually introduce unit tests over time, with the goal being high test coverage at the unit level
Certainly with a small team there may not be bandwidth for an explicit traditional full-time QA role. We pointed out that with developer testing there’s no tester-developer separation: every developer is a tester, so testing isn’t gated by team size at all.

We made two points about speed when doing TDD:

It can certainly take some time to get proficient and achieve the same short-term speed you had before. However, in our experience, if a team has a member who’s done it before, or whose role it is to advocate for constant TDD, the team members start to get the hang of it much faster than you might expect – 3 weeks or less in many cases.
Independent of whether coding a certain feature is faster or slower, the medium- to long-term benefits (catching regressions instantly) are invaluable.
There was an interesting discussion of why we’re so interested in pushing for frequent releasability even on projects whose clients are known not to want frequent releases. The consensus was that even if there’s no actual need or desire to release frequently, the act of trying to get to that point brings lots of benefits. There are fewer surprises when a real release comes due; the “last-mile” problem is often reduced; people integrate their changes with the main trunk of development more frequently, so there’s less merge hell, etc.

Build

Our second talk was on build. As an ideal to shoot for, we promoted what Pivotal Labs does:

Checkins prompt a build (clearly, this helps to identify which changes broke what)
A broken build is an anomaly – teams should immediately stop and fix a broken build
Keeping the build fast is critical, so that it stays relevant
The build must be easily visible to the whole team. At Pivotal we have 2 large TVs on the wall that clearly show the build status of all our projects

There was a good deal of discussion over how to get started with a build. Some ideas that were brought up were:

You don’t need tests to have a build. Compiling and packaging your code with each checkin, and making sure everything works is still very useful information
If your build is flaky (i.e. some tests fail seemingly at random), immediately detach the flaky tests to keep the build stable. Work on the flaky tests in isolation. The team needs to trust the build’s status.
If your build is slow, break out a slower suite of tests and run it in a separate process that runs less frequently. Work towards high coverage with fast unit tests so that the status of your fast build is meaningful.

Hopefully our talks were useful. Certainly they sparked plenty of discussion!

Thanks to Jeff Sutherland, Igor Altman and Steve Rabin of OpenView for inviting Pivotal Labs to speak.

Below are our two presentations.

Pivotal Labs Open View Presentation Quality Assurance And Developer Testing

View SlideShare presentation or Upload your own.

Pivotal Labs Open View Presentation Continuous Build

View SlideShare presentation or Upload your own.

Standup 10/15/2008: this_method; dynamically creating tables for testing

Joe Moore

Wednesday, October 15, 2008

Where am I? — Ever need to find the name of the method you are currently within? Here’s a this_method method! The magic is in the REGEX, of course.

module Kernel
  private
  def this_method
    caller[0] =~ /`([^']*)'/ and $1
  end
end

One project wanted to test a very ActiveRecord-specific Module in an isolated, generic way. After spending time researching techniques of mocking and stubbing the many, many ActiveRecord methods that would be touched, they decided to just dynamically create an ActiveRecord and a DB Table for it on the fly! They even used single table inheritance (STI)

  describe "MyMagicModule Mixin" do
    before(:all) do
      ActiveRecord::Base.connection.create_table "some_base_models",
                                                   :force => true do |t|
        t.string   "name"
        t.string   "type"
        t.integer  "some_model_b_id", :limit => 11
      end
    end

    after(:all) do
      ActiveRecord::Base.connection.drop_table "some_base_models"
    end


    class SomeBaseModel < ActiveRecord::Base;end

    class SomeModelA < SomeBaseModel
      include MyMagicModule

      belongs_to: :some_model_b
    end

    class SomeModelB < SomeBaseModel
      include MyMagicModule
    end

    it 'should use special belongs_to stuff from MyMagicModule' do
       model_a = SomeModelA.create!(
                        :name=> "Model A",
                        :some_model_be => SomeModelB.create!(:name => "Model B"))
       # test the functionality from MyMagicModule
    end
  end

Standup 10/14/2008: Database Migrations

Pivotal Labs

Tuesday, October 14, 2008

Interesting Things

Rake migrations check if a migrations table is in sync with migration file and it does not really check what the state of the data in database.

Ask for Help

“Can we use migrations to load static data into an application”

People usually create a separate rake task to bootstap. Mixing it with migration was not working well before.