• JQuery Events/live + ScrewUnit = :-(. ScrewUnit swaps the DOM "out from under" the elements that Events/live is watching, which messes with ScrewUnit. Call die on the DOM elements that live events are watching.

• ScrewUnit + CI + IE = :'-( Also, When ScrewUnit suites become large, they trigger IE's "slow script" warning, which can freeze your continuous integration build. Check out the Registry Hack to set your own timeout.

• We have a fan of Thor in the house: "Map options to a class. Simply create a class with the appropriate annotations, and have options automatically map to functions and parameters." Which, as is (not) obvious, indicates that Thor is a replacement for rake.

Interesting Things

• You can never return: ... except when you can. From a block, that is. Returning from a block rarely works:

  result = ['one', 'two'].each do |x|
   return x
  end
  => LocalJumpError: unexpected return
  

  But, you can pass next and break arguments, which will allow you to assign return values from the block:

  result = ['one', 'two'].each do |x|
    break(x)
  end
  => "one"
  
  
  result = ['one', 'two'].each do |x|
    next(x)
  end
  => ["one", "two"]
  

You can return from a lambda, though.

• Check out Google Page Speed, which is like Yahoo's YSlow, only "better."

  Page Speed is an open-source Firefox/Firebug Add-on. Webmasters and web developers can use Page Speed to evaluate the performance of their web pages and to get suggestions on how to improve them.

• Like chef? Love capistrano? Check out chef-deploy, which "... Uses the same directory layout as capistrano and steals the git remote cached deploy strategy from cap and adapts it to work without cap and under chef."

• SFTUG FTW! Another successful SF Tracker User Group Meetup on 06/24. Watch for future events on the Meetup site.

Ask for Help

"Does anyone have Nginx URL rewriting fu?"

The pretty documentation is actually quite hard to work with. Does anyone else have a good reference?

Interesting Things

• Pivotal in the New York Times: Regarding Palm Pre development and our own Tweed:

Some developers who were granted early access to Palm's new operating system said it was worth the wait. "We find it's the easiest one to develop for," said Christian Sepulveda, vice president for business development at Pivotal Labs. "It allows for a richer experience, like having a pop-up menu and background processing, which is helpful."

Mr. Sepulveda's company developed four of the first programs available for download through Palm’s app store, including an item for Twitter called Tweed.

• The next SF Ruby Meetup will be held here at Pivotal Labs. Sign up) and attend!
• BART strike warning! In the Bay Area we take our commute options seriously. Here are your options if BART goes on strike

Ask for Help

"Has anyone implemented mutli-table (class table) inheritance in Rails, as apposed to single table inheritance (STI)?"

• There are some plugins that nobody has tried, such as inherits_from
• What about a view to represent the super set of tables and rows?

"We're looking for a dead-simple, drop-in JS rating or 'starting' plugin."

Check out the start-rating jQuery plugin. Any other suggestions?

Interesting Things

• RubyMine 1.1 + Latest Mac OS X Java Upgrade + configuring RubyMine to work with Java 1.6 = Complex FAIL. We downgraded to RubyMine 1.0.5 and it works again.

On April 29, 2009 Pivotal Labs hosted the inaugural San Francisco Pivotal Tracker User's Group. It was a great success! As an avid Pivotal Tracker user (and sometimes developer) for over 3 years I am very interested in making Tracker a better product and teaching others how to use Tracker to improve their organization.

Here are a few thoughts I took away from the meeting, and a few tips and tricks.

Pivot Corey gave a brown-bag lunch talk titled "There is No Such Thing as a CSS Class" (slides and notes) where he describes establishing a project specific "CSS System." This excellent presentation complements the "Consistent and Effective CSS" talk (video and live demo available) given by Pivots Corey, Ryan, and Chris.

At Pivotal, we are passionate about test driven development, keeping things DRY, and writing readable and understandable code. Satisfying all of these desires can be challenging, especially when writing test code. In particular, ActiveRecord extensions present several challenges: which models using an extension should we test? How do we both test our extension in isolation while also testing all model's usage of that extension? Is it even worth it?

The answer is yes, it is worth it, and it's also fairly easy, readable, understandable, and DRY. I will present both a common problem and a solution, using a cumulation of technologies and techniques from multiple Pivotal projects, in particular using acts_as_fu to create laser-targeted, isolated, and disposable ActiveRecord models for testing extensions and RSpec shared behaviors to minimize the amount of duplicated test code.

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.