February 2009 Archives

Love Data Visualizations?

| Comments

I'm a sucker for data visualization. There's all kinds of emergent patterns in data when you convert it to something visible. So, I'm stoked to have found Many Eyes, a place where people can share visualizations of data. Plus, the data set for each submission is available.

It’s tempting to write classes with a handful of attributes and declare the code “Object Oriented”. Sadly, cranking out data transfer objects isn’t object-oriented design.

Instead of one uber-post with tons of thoughts around all the extra stuff good OO demands, I’m tackling one thing at a time and writing a series of posts on the topic. This first one deals with object equality.

Equality Matters

Even if you’re making a rinky-dink class, think hard about overloading the equality operator.

For example, given a Person class:

class Person:
What does it mean for two Person instances to be equal? Does every attribute have to match? What if everything but favorite_color is the same?

These kinds of questions are important for building an accurate model. It seems reasonable to say that SSN is the deciding factor for equality:

class Person:

    def __eq__(self, other):
        return other.ssn == self.ssn

If a web form is used to create a Person and our app checks this against a list of Person’s from the database, it’s easy (and feels good) to write:

form = {'firstname':flavio,
            'soc_sec_num': 2223339999}

def check_user():
    people_i_know = database.get_friends()
    user = Person(ssn=form.soc_sec_num,

    if user in people_i_know:
        print "Welcome! I know you!"
Though == didn’t appear in the above function, it still gets invoked when in tests for membership in the list (look ma, no looping over objects!). We also didn’t need “favorite color” as an input, since it’s not a factor in equality.

If we don’t overload equality, we need to add favorite_color to the form or write logic to see if the input was “equal enough” to what we got from the database. It’s way easier to define it once in the class itself and take advantage of all the sweet things equality gives you for free.

If you love your classes, show them that love. Give them the gift of equality.

Stay tuned for the next installment of the Care and Feeding of Objects series…

[photo courtesy of bayerNYC]

Basking in the Failures of Others

| Comments

If you’re feeling down, the misery of others can be a nice pick-me-up. WebHosting Unleashed published a list of 11 embarrassing and costly server meltdowns.

My favorite is number seven:

7. In August 2007, hosting service ValueWeb notified customers that their sites would be unavailable for 15 to 18 hours while 3,700 Web site and business application servers were trucked 270 miles to new facilities. In fact, many of these customers were offline for several days.

Of course, one shouldn’t take too much pleasure in the list. The next epic server failure is just waiting to happen.

The order of statements in the Agile Manifesto is important, and first on the list is

Individuals and interactions over processes and tools.

It’s easy to gloss right over it. I did at first; but then I realized that people do the exact opposite all the time. When process improvements are presented, it’s often with the assumption that the new process is an end in and of itself, ignoring the actual problem.

“Our documentation is bad, so from now on all projects need to submit design documentation for approval before development can begin.”

This has almost zero chance of working. With a deadline looming, this rule crumbles under an onslaught of “business need”. Any documentation that does manage to squirt out is crappy.

The “people over process” part of the manifesto tells us that instead of instituting a policy to magically fix the problem, we need to focus on people. We need to win over hearts and minds. Yes, it’s that dramatic and that important. Once the people are convinced that they want a solution, change happens quickly. It’s the whole carrot/stick honey/vinegar thing.

In the previous case, winning hearts means helping people understand how better documentation will benefit them, and to make them want it. Someone’s going to have to talk to all those people. Someone’s going to have to keep at it for as long as it takes.

It’s way easier to declare a policy and walk away than change peoples’ minds, but the policy won’t really get anything done.

I’ve had a few cases where I use the class attribute of an element to rig javascript, only to find that later someone has “improved” the page, changed all the class names, and broken my javascript.
456 Berea St. has a nice post about how the class attribute encompasses more than just CSS.

I’ll also add that microformats are pretty much based entirely on class names being correct. I’ll leave the debate over their utility to others.

Is There a Name for This?

| Comments

Has anyone coined a term describing the following?:

  1. I get an unexpected error when running software, say Apache Tomcat.
  2. I punch the error message into google and get a lot of hits on that string.
  3. Every one of the links points to the message board or mailing list post of someone who has the exact same problem as me.
  4. NONE of the posts have a reply explaining a fix.

If you have any naming suggestions, please share them with the group in the comments.

Sometimes people level the “tests are too expensive” argument. Kent Beck (Mr. Extreme Programming) provides a refreshingly scientific journey into why the lifetime cost of tests is small.

One main point is that most failed test runs are caused by a single failure, and those single failures usually aren’t too hard/expensive to fix.

It’s a good caution against using average failure rates when calculating how much tests hurt you.

[link] Large numbers of failed tests are rare

In a recent Coding Horror post, Jeff suggests that templating frameworks are often more trouble than they’re worth; valuable only in trivial cases:

I think existing templating solutions are going about this completely backwards. Rather than poking holes in HTML to insert code, we should simply treat HTML as code.

Huh? Have we not struggled for years to pull ourselves up out of the muck of generating markup in our code? Jeff goes on:

Templating tends to break down because it forces you to treat code and markup as two different and fundamentally incompatible things.

CORRECT! Code and markup are two different things. They’re different languages! When you write a web app, you’re using one language (Python, Java, Ruby) to generate others (HTML, Javascript). A daunting task, no matter how you slice it. Why smash them together?

By keeping markup very far away from business logic, the core logic is more stable and there’s less temptation to mingle concerns.

Tag soup happens because web development is complex stuff, and there’s really no way around it.

If you don’t like the syntax of a templating system, find one you like better or work to isolate the gross parts. Whatever you do, please don’t push us back to the dark ages of building strings of markup in our code, no matter how seductive your language makes it feel.

Editor Learning Curves

| Comments

emacs learning curve

Daily Vim has a funny set of editor learning curves, with graphs for Notepad, Pico, Visual Studio, vi, and Emacs.
I personally think the vi one should be a little steeper at the beginnig, but then again I’m slower than others.

Lots of big projects start out with marathon meetings; the kind where the business owners go over what they want with the tech team.

This kind of meeting sounds like a good idea because it puts everyone in the same room for a long time; the logic being that if the core members of the project are in the same place at the same time, collaboration is inevitable.

Intuitively we know this isn’t very efficient. These meetings are always painful, which is strange, since everyone attending shares the same goal: a successful project. Still, most of us lurch out beat up and drained. Real collaboration should feel good. Exciting.

The big meeting creates a long-running ping pong match, with each side working to fire the ball back to the other’s court.

In the meeting, stakeholders tell the developers what they want. They know the business case, and they know what they want to do for the solution. It’s easy to get defensive. Questions about corner cases can seem like attacks on the project itself.


When the business owners are describing their requirements, we technologists start cataloging the reasons its impossible to deliver what’s being asked for. The business might dismiss this as harping on details or failure to understand the big picture.


When the meeting ends, everyone heads back to their desks. Developers write up estimates and designs. They may even code a litte. The business owners go back and further refine their ideas and features.

In the next mammoth session the game continues. Devs raise their litany of issues and the business present their updated ideas. The business thinks the devs are nitpicking again, and developers think they’re getting and more meaningless requirements.

The key is to have true collaboration instead of gladiator matches with whiteboards and notepads. Visit the stakeholders outside of the meeting to go over some of the gnarly details. Use it as a mini closed-door summit. Nobody ever has to know what kinds of things you discussed or offered, only that the results were achieved.

The latest installment in the mini-saga of Uncle Bob vs Joel and Jeff; Bob tweeted he should be on the February 10th episode of the Stack Overflow podcast.

I predict a lot of "Oh! You thought I meant THAT? Of course we agree with you on everything!", but who knows, it could devolve into name-calling.

I haven’t been following the somewhat philosophical debate over Google’s karmic positioning, but Daniel Tunkelang has, and has posted a nice summary of a recent debate on the question of Google being evil.

[link] Is Google Evil? The Great Debate

For anyone following the drama between Uncle Bob and the Stack Overflow guys; I just saw this notice that Joel Spolsky has invited Uncle Bob to an upcoming Stack Overflow podcast.

Should be interesting to hear the debate, explanations, backpedaling, etc, if it actually happens.