Link roundup

• Announcing Trinidad: In-process test runner for FitNesse wiki pages
• Rake Stats: How to log Rails 'rake stats' command output over time and add extensions to it into CruiseControl
  
• Clarke Ching's "Rocks into Gold": a biztech parable for software developers who want to Survive - and then Thrive – through the Credit Crunch.
  
• Hiring Software Developers: The Agile Aptitude Test
• Agile Payback: The adoption of agile programming methods has proved one of the most effective and popular strategies of the past year
• Anthrax and Standups: Slightly old but relevant post from Brian Marick on story-based standups
• Playgrounds & a Thought on Testing

Asynchrony honorably mentioned as Great Place to Work

St. Louis Magazine has an article that notes something that those of us who work at Asychrony already knew: Asynchrony is a great place to work. We received an honorable mention in the publication's January issue highlighting the area's Great Places to Work. Sure, our "Employees play Halo on two 40-inch TVs," but we're got several of the other perks that other companies have, and some that they don't. Like flexible childcare, pet-friendliness, FFASHH, and, of course, the free lunches. That chinese food in the first-floor refrigerator was for everyone, right?

Defense Systems highlights Asynchrony's SOA work at USTRANSCOM

Defense Systems magazine had a good article about Asynchrony's SOA work at USTRANSCOM. Here's a snippet with a quote from Steve:

The prescriptive architecture is due for delivery in the fall of 2009, said Steve Elfanbaum, Asynchrony’s president. But it won’t take the full length of the contract for new Web-based capabilities to come out, or for the transition architecture to be fully defined.

“People (in USTRANSCOM) are already clamoring for new services and want to use what we have now,” he said. “So as things come out of this process, as the various templates and standards fall out, we’ll start to use those as soon as we can.”

That's textbook agile philosophy, providing value as soon as possible. Who says government contracts can't be done agilely (or at least more agilely)?

Link roundup

• Retrospective facilitation -- John Wilger
• Kanban introduction -- Eric Landes (podcast)
• "How we develop software at Socialtext" (video)
• Getting Real About Agile Design
• Working through Screens (ebook on user interaction)
• Agile Philanthropy
  

Environmentally friendly, reusable story cards

Besides conversation, nothing beats the tactile, low-fi index card for communicating story information. And for environmentally friendly story cards, nothing beats this invention (well, we're not really sure it's an invention in the strictest sense) by Asynchronite Dan King: The Lamindex Story Card. As the name implies, it's a laminated index card that can be used and reused for countless stories and countless projects.




They're relatively cheap to make (just go to Kinko's if you don't have your own laminator or teacher friend), though Dan advises getting the "special kind" of laminate for easy cleaning.

The Toilet Paper (Installment 25): Single-Responsibility Principle (SOLID, part 2)

A class should have exactly one reason to change

The Single-Responsibility Principle (SRP) helps you create classes that are resilient in the face of requirements changes. Put more simply, the SRP guides you in creating individual classes that are highly focused on a single implementation concept, so that each individual class is less likely to be affected by each requirements change. Each class is very limited in what it knows how to do and what it knows about, so an individual requirement change is less likely to affect that class. As a result, classes that change less often and accumulate less code are less likely to accumulate bugs as well. They can be tested thoroughly and raise the overall quality of your application.

Let's look at an example. Suppose we have a Product class that models information and behavior associated with some widget we're selling. It might look something like this:

public class Product {
 public String Name { get; private set; }
 public String Sku { get; private set; }
 public Money ShippingCharges(Destination dest) {…}
 public Money CalculateDiscount(Contract contract){…}
}

Assuming that the implementations of how to calculate shipping charges and discounts are inside both of those methods, this class clearly has multiple responsibilities – three, in fact. First, it models a product, which has properties, shipping charges and discounts. But this class also charges shipping and calculates discounts. This may not seem that important, but it means that this particular class is harder to understand and changes more often than would otherwise be necessary. The biggest shortcoming, however, is that the logic for these calculations is hidden inside the Product class, making these non-trivial bits of code harder to find and harder to test independently.

To solve this, refactor this class so that it delegates the responsibility of how doing the calculations are done to two other, more specialized classes, such as ShippingChargeCalculator and PriceDiscounter. That would leave you with three classes, each of which has one reason to change, decreasing the complexity of the system and increasing maintainability, flexibility, and testability.

You can find much more on the SRP on Google. Try searching for "ActiveRecord Single-Responsibility Principle" for hours of enjoyment!

Link roundup

Product Ownership

• Becoming a Great Scrum Product Owner (eBook)

Testing

• Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (book)
• JNarrate: Tool that allows you to write acceptance tests with code using a fluent API
• Craft of Software blog: Matt Heusser's new blog for testers
• Software Craftsmanship: Google group
  

Best Practices

• Linda Rising podcast on Retrospectives
• Kanban and Retrospectives
  

Agile

• “Seven Years Later: What the Agile Manifesto Left Out” presentation by Brian Marick at Agile Development Practices

Asynchrony Principals Aging Like Fine Wine

First image is from around the time of our 1999 start-up. The second is the 2009 version.

Using JavaScript to check if an image is loaded

I had an interesting problem the other day. The project I'm on is a real estate listing website. It's very Web 2.0, using AJAX calls to provide the user with a rich experience. We use the Prototype Library for all our AJAX calls and DOM manipulation.

So the problem came about with the enlarged photo browsing portion of the site. Each listing has at least one photo associated with it. If the listing has more than one photo, then the user can browse through the photo with simple NEXT & PREVIOUS links. Under the scene, when the user presses one of the links we make a simple AJAX call to load the next image and swap out the div the image belongs to.

The problem came about when we were testing in IE. The footer would sometimes appear right over the image. IE wasn't recognizing that one of the div elements was supposed to grow to match the size of the image inside it. The simple fix was to set the Height of the problem div to the Height of the child div that is holding the image. To do this all I had to do was call this method in the "onComplete" section of my AJAX call.

This worked in most cases but there were still times when the footer tag would appear in the middle. With the help of firebug lite, and Nate Young, I realized that my method was being called before the image was finished loading. The solution was loading the image and checking the "complete" on the image object. If the image isn't finished, just make a simple recursive call.

function moveFooter(){
  if ($('enlargedImageDiv') && $('imageContainer')){
    var image = 
      new Image($('imageContainer').siblings[0]);
    if(image.complete) {
      Element.setStyle($('enlargedImageDiv'), {
        height:$('imageContainer').getHeight()+41
      });
    }else{
      moveFooter()
    } 
 }
}