Friday, January 30, 2009

Link roundup

Thursday, January 29, 2009

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?

Wednesday, January 28, 2009

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)?

Wednesday, January 21, 2009

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.

Friday, January 09, 2009

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!

Wednesday, January 07, 2009

Link roundup

Product Ownership
Best Practices

Monday, January 05, 2009

Asynchrony Principals Aging Like Fine Wine

We Get Better Looking Each Day

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

Thursday, January 01, 2009

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'), {