"Head First" Book Sometimes Makes My Head Hurt

I’m helping out with a study group for "Head First Design Patterns," which just finished chapter 6. On the whole, it’s a pretty good introduction to software design patterns – way more accessible than the seminal work by the Gang of Four; however, the examples sometimes make my head hurt. I can’t imagine what they’re doing to the heads of the beginners in the group. Coming up with decent examples is the hardest thing to do in expository writing, and I certainly give the authors an E for effort in creativity, but I wish they had been a little less concerned with making their examples "hip" and a little more concerned with making them appropriate.

To wit, the whole pizza store analogy in chapter 4 (to illustrate factory method and abstract factory) is flawed. For one thing, that’s just not the way you’d model a pizza business in any actual software that I can imagine. For another, the differences between a New York pizza factory and a Chicago pizza factory are too subtle/trivial to make for an effective illustration of why you would need to subclass anything (much less use a factory to manage the subclasses). A much better example, as everyone in my group agreed, would have been an application that needs to offer up a consistent set of functionality to users who are accessing it in wildly different ways: one’s in a web browser on a desktop, another is running a cell phone app, another is using a touch-tone phone, and yet another is using a voice-activated headset. All the client code knows is that, for example, it needs to ask a multiple-choice question and obtain the answer. It’s up to an abstract factory to provide the client with a set of classes that can do that, in the context of the selected user-interface, in whatever way is necessary.

To a lesser degree, the Starbucks coffee example at the beginning of the book suffers from the same too-hip-to-be-effective syndrome, although I do think that the remote-control example for the Command pattern in chapter six is dead on.

For any novice who is reading this book without the benefit of a study group, I highly suggest that you find at least one other programmer who is experienced in design patterns to explain why/if/how the examples are lacking.

Wax On, Wax Off – Red Bar, Green Bar

TDD has become as automatic for me as breathing. It’s a beautiful thing when you get to start a new project from scratch and can write every line of code test-first. These days, however, I’m working on a legacy app with very little in the way of unit tests, and it feels as if I’m working at 5,000 meters above sea level and struggling for every breath of rarified atmosphere.

So I can only imagine how it seems to the rest of my team, for whom automated unit testing is a new concept. The level of drudgery involved in retrofitting a legacy app with a test harness rivals the chore of waxing Mr. Miyagi’s deck. All I can tell my teammates is that it’s good practice. Soon, writing unit tests becomes a habit, and then, eventually, it becomes pure instinct. Attack from the right? Wax On! Attack from the left? Wax Off! Add a new feature? HTTP-Unit! Change a business rule? JUnit! Keep it up, and that black belt will arrive in no time.

Copying SQL Records within the Same Table

I discovered a neat trick for copying a record, or set of records, within the same SQL table today. For example, say you have 20 employees listed in department A, and you want to clone all 20 records to also be listed under department B.

You may or may know that this can be done with a single INSERT INTO statement if you use an embedded SELECT statement in place of the VALUES clause. The hard part is that you cannot just use SELECT * FROM table WHERE ... becuase the * would pick up the key field (e.g. DepartmentID) along with all the rest. So, you have to list every field in the table by hand, except DepartmentID. You would specify the new value as a constant ("B") instead.

The "trick" is that you can probably find a tool that will generate the INSERT and SELECT statements for you. In my case, I'm using the Query Analyzer that comes with Microsoft SQL. In the explorer pane, navigate to the table. First, right-click and choose the option to generate an INSERT script and send it to the clipboard. Paste it into your favorite editor. Next, right-click and choose the option to generate a SELECT script and send it to the clipboard. When you paste this snippet into the editor, do it so that it replaces the VALUES... part of the INSERT statement. Finally, change the field name of the key field in the SELECT statement to the appropriate constant.

Quick, Easy, Free UML Diagrams of Java Classes

I sure do love it here in the Java open-source community!

I read in Martin Fowler's blog that there's a cool open-source tool, called UMLGraph, he's been playing with for rendering UML class diagrams. If Fowler says it's worth checking out, then that's good enough for me. What the heck? I'll give it an hour.

So, I installed the tool itself (a JavaDoc Doclet -- just one jar), and I installed the free executable from AT&T Labs that actually does the rendering. I added a JavaDoc command to my Ant build script, and I added a call to the AT&T tool. Walla! Pretty UML diagrams to go with my program! It couldn’t be any simpler.

Not that I'll ever wait until the end of a project and generate reams of UML documentation to sit on a shelf -- what this will allow me to do is start to write new Java code, without any meat on the bones yet, and immediately get diagrams as I go to show off at design reviews and whatnot. Don’t like the way the design looks? I'll just take advantage of the Eclipse refactoring tools, and then re-render the diagrams. Is that slick, or what? No need to pay for a Rational Rose license, nor go though contortions to install it. No need to learn how to use the Rose UI. And, best yet, no need to "transcribble" (transcribe with possible errors) the design into code -- it's already code.

Note that I've only played with UMLGraph's class diagrams thus far. There's also a way to draw sequence diagrams, but it doesn’t work off of the Java source. You have to use something called the PIC language, so that's not as slick, but I'm not complaining. Being able to render class diagrams quickly and easily (and cheaply) is a tremendous boon. I couldn't wait to spread the word.

Oh, and back to why I love the Java open-source community: Fowler's blog entry wasn't even a day old when the UMLGraph people changed the front page of their site to reference the suggestions for improvement that Fowler made. I wouldn't be surprised if the team has acted on them already.

User Interfaces for Infrequent Tasks

Paraphrasing an article by Barbara Nelson of Pragmatic Marketing, good software may very well be complex, but that complexity needs to be hidden from the user as much as possible. Nelson cites Intuit’s Quicken as a prime example. "They learned what regular people needed by spending time in people's homes, watching how they managed their home finances. Quicken was the first finance package to use the checkbook metaphor, something regular people already understood. Quicken was hugely successful, and even with dozens of competitors, managed to gain 75% market-share because it was easier to use. It was the first product to take a customer-oriented view instead of a data-centric view."

One way to hide complexity is through a guided UI (a.k.a. a wizard or an interview). A common misconception is that a wizard makes a good UI for novices, when in fact they are more properly employed to address infrequent tasks, and should have nothing to do with whether or not the user is a novice. Novices aren't novices for very long (when performing a frequent task). Writing a guided UI for a frequent task is bad, because it eventually bogs the user down. On the other hand, a guided UI is perfect for an infrequent task, especially a complicated, critical, or finicky one, no matter whether the user is generally regarded as a novice, intermediate, or advanced. You might say that when it comes to infrequent tasks, every user is always a novice.