Pair programming is the subject of endless discussion and debate. How often should we pair -- 25%, 50%, 75%, or even 100% of our development day? Should we pair on remedial tasks as well as feature development? What about infrastructure work or research? Is pair programming valuable at all, or should we kick that hippie kumbaya crap to the curb, put on our headphones, and get some real work done?

Personally, I'm somewhere in the 95%-pairing range. Simple stories and bug fixes have a way of becoming complicated (or implemented sloppily) when soloing. Infrastructure is a notoriously siloed realm and spreading that knowledge around can only help everyone. Investigating production database issues, estimating stories, writing CSS, chopping up images using Fireworks -- share the love!

So what is the last 5% for? Futzing.

Futzing Around

I'm "futzing around" when I'm not doing anything important, maybe even wasting time, at least from a pure productivity perspective. Interestingly, while I'm not implementing features or fixing bugs, I'm expanding my mind. I'm learning in a way that is not conducive to pair programming or any interaction at all with other people: I'm exercising my personal way of learning that that is unique to me. Here's an example:

On my current project, we're using very advanced, powerful CSS selectors that blow my mind. While I understand what we are implementing and can see the immediate affect upon the application, it is impossible for me to grok the enormity of these techniques even though my pair is a master and great teacher. I'm learning, but not necessarily understanding. Collectively we are not in a teaching mode, we're in a cranking-out-awesome-stuff mode. Now, I am not suggesting that we are hacking or moving too fast to learn -- on the contrary, we are both learning much, and I often ask my pair to slow down and explain what the hell .div:first-child:not(.row) + .row is doing. Our joint mission, though, is to get stuff done, not to explore every CSS pseudo selector. I'll futz around with that later.

Flipping Switches

When I'm learning something new, especially when it's complicated, I eventually need to futz with it by myself, with nobody looking over my shoulder. I need to flip all of the switches, break it, fix it, break it again the same way, fix it, throw in a little salt and pepper and try again. I need to try every parameter individually, then try to combine them. I need to hack and not feel bad about it. I need to do stupid stuff that could never possibly work because, even if I'm told such, I need to try it myself. Finally, I need to do this for 30 minutes until the "ah ha!" moment hits me and all of the tumblers fall into place in my mind.

Why don't I do this with a pair? Because I must be in the driver's seat the entire time with no consideration for pair programming etiquette: talking things through, taking turns, letting my pair try his ideas -- no way. I need those brain cycles to figure this stuff out, to make the mental connections that are shorting out. I don't know what I don't know, and I need to find out for myself, in my own dumb way, by futzing around and making mistakes. Finally, I need to more than learn: I need to understand. When I'm done, I will use that new understanding during the other 95% of my development time to help my team build the best products we possibly can, and encourage them to futz around a bit on their own, too.

As a developer of web apps, I'm inevitably running 3 or 4 browsers, each with 10 tabs open containing my application under development, Google searches, gotapi (pronounced "got a pie?" of course!), design wireframes, and all kinds of other very important stuff. And in one of those tabs, somewhere, is Pivotal Tracker. Browsers and tabs are great, but sometimes you just want an Application -- notice the capital "A."

Fluid to the rescue! Fluid lets you create Site Specific Browsers, which "provide a great solution for your WebApp woes." In a nutshell, Fluid makes a custom WebKit browser that, when launched, opens just the site you configured it to open, such as Gmail, Pandora, or even Pivotal Tracker. I love that I can maximize the Pivotal Tracker app and boost the font 3 or 4 levels, filling a screen with Tracker goodness without the clutter or navigation buttons, bookmark bars, or tabs. And where is Tracker? Just command-tab!

Here's how to create a Fluid application for Pivotal Tracker.

1. Download and install Fluid
2. Download the Fluid Icon for Pivotal Tracker
3. Launch Fluid
4. Enter the following:
   • URL: http://www.pivotaltracker.com
   • Name: Pivotal Tracker
   • Location: pick one!
   • Icon: pick 'Other...' then find the tracker icon you downloaded earlier
5. Click Create, then launch it!

Once launched, open the Pivotal Tracker preferences and change the Window Style to "HUD (Black)" under Appearance Preferences Why? Because it looks cool.

Update

Here is the Fluid icon, upon request.

Interesting Things

• application.rb vs. application_controller.rb: As we all know, ApplicationController breaks with Rails convention and lives in the application.rb file, not application_controller.rb. Be careful if you create an application_controller.rb file of your own, as this can confuse Rails class loading and might result in Rails deciding not to load application.rb.

• Google Webmaster Tools: Note that if you are using Google Webmaster Tools that statistics are different for www.example.com and example.com (sans www).

• Nested Model Forms are coming in Rails 2.3! There is even a patch in progress.

Interesting

• libxml 0.96 and 0.97 leak massive amounts of memory. Don't forget that libxml has other problems, too, as mentioned by us before. That said, it's our go-to XML parser.

• Several teams have had success with the IE6 PNG fix "DD_belatedPNG" by Drew Diller. But, do not attempt with <tr> or <td> elements, though <td><span>...</span></td> does work.

• Want to speed up ruby? Who doesn't? Check it out: when you do not set the TZ environment variable, ruby shells out several times per second to see if the timezone has changed. To avoid this, run the following:

$ export TZ=:/etc/localtime 

Thank you Joe Damato!

• One project recently switched to Passenger with great success. Hundreds of mongrel processes are now gone, deploys are easier and speedier, and the site is faster. WIN!

Interesting Things

• Rails reminder: flash[:notice] = "Good Job" will survive a redirect, while flash.now[:notice] = "Good Job" will not. In general, flash.now is used when you render a template without a redirect, such as when a form submit has validation errors.
• Good Books: Several folks have recommended JavaScript: The Good Parts.
• Pro bono: Would anyone like to help out KUSF for free? Their new website project has been stalled for a year.

Ask for Help

"How do you get Selenium to work with Firefox 3?"

If you know how, pull the jar files out of a later release and use those. Good luck!

Interesting Things

• Engine Yard has made some changes to their ssh-key setup:

  ...any non-approved keys will be removed from the root user's authorized_keys file. It should be noted that customers should not log in directly as root but rather should log in as their user and use sudo for any commands that need super user privilege. If you are currently using the root user to log in and have your key in roots authorized_keys file it will be removed when this change is made.

  If you are having any ssh problems, contact them.

Interesting Things

• Pivotal Tracker tip: as the Holiday Season approaches, you can edit your Team Strength to account for vacationing team members. For example, if you are missing 1 out of a team of 4 next week, set next week's Team Strength to 75%

  

• Rescuing inside a transaction: ActiveRecord relies on catching a Rollback error in order to perform transaction rollbacks. If you are performing a begin..rescue block within a transaction, make sure you either (a) specify the Exception or Errors you want to catch, or (b) re-raise the Rollback error if caught.

• Bring it! The Pivot Pong Tournament of Champions is on! Games will be played on the Pivotal breakfast tables/ping pong table.

  

Ask for Help

"What is the life-cycle of test fixtures when using transactional fixtures?"

1. The testing framework clears the database of all data within tables that have fixtures files defined.
2. A test/spec file is loaded and all fixtures declared within it (or all if fixtures :all is declared) are loaded into the database.
3. A transaction is started.
4. The test/spec runs.
5. The transaction is rolled-back.
6. Repeat!

• One team discovered a jaw-dropping issue with has_many :through. Given the following:

  class User < ActiveRecord::Base
    has_many :user_photos
    has_many :photos, :through => :user_photos
  

  • a_user.photos.create will create and persist both a Photo object and the UserPhoto join object
  • photo = a_user.photos.build followed by photo.save will create and persist the Photo object only, and will not persist an appropriate UserPhoto join object.

• Rails 2.2: Test::Unit::TestCase extentions have been removed from Rails Core and are now in ActiveSupport::TestCase. As stated in the Groups Thread about this, use ActiveSupport::TestCase instead of Test::Unit::TestCase in test/test_helper.rb.

Interesting Things

• We recently updated Pivotal Tracker's extensive JSUnit test suite to be compatible with the Google Chrome browser. Check out the extensive Notes on Google Chrome Compatiblity post by Pivot Chad.

• ActiveScaffold + Rails 2.2 = BOOM. ActiveScaffold will work with Rails 2.1 if you get the version from github. Read about it.

• Rails 2.2 + Rspec 1.11 = FAIL

Here's a hot Fluid icon for Pivotal Tracker. Thanks, Ted!

Check out a couple of other icons in this Flickr upload.