Friday, March 31, 2006

Boston Marathon Countdown

The 110th Boston Marathon is just over two weeks away. Race day is Monday, April 17. After months of training, most entrants are tapering. The hard work is done. Now it's time to cut back on the mileage, pray for good weather ("It can't be hot four years in a row."), keep a positive attitude, and try not to go stir-crazy. I've never run a marathon, so I've never experienced the mental stress of the marathon taper, but I know the signs. It can be a tough time for runners of all abilities. Hang in there, everyone.

Lots of people are excited about this year's elite field of runners. Hailu Negussie of Ethiopia will be back to defend his 2005 title. As usual, there will be a strong contingent of Kenyans. But the buzz is all about the American field. Alan Culpepper (fourth place in 2005) and Meb Keflezighi will lead the strongest American field in years. Could this be the year an American takes first in the men's race?

Boston Marathon Leader BoardLuckily I'll have a front-row seat -- well, not a seat really. Just like last year, I'll be working the leader board with my brother and sisters. We just received confirmation of our assignment this week. I can't wait.

Wednesday, March 29, 2006

JavaScript Utility for Fixing URLs

Yesterday, I cancelled my dial-up ISP account. If you've been through the change-of-ISP experience, you know it can be tedious. I forwarded my email to a new account and I dutifully notified dozens of people and companies about my new email address. The last problem to solve was moving the many images stored on the web space provided by my old ISP. I've posted many Runtime Log entries that refer to those images. To avoid broken links in my blog's archives, I had to move the images to a new home.

Actually, the easy part was copying the image files to a new location on the web. The harder part was figuring out how to fix the references to those images in old posts. I could have edited each post by hand, but that would have been tedious and error prone. Even worse in my estimation is the edits would have caused Blogger to update my RSS feed. The old posts would look like they had been updated, when in fact I had just changed a URL or two.

I decided a better approach would be to leave the old posts alone and fix image URLs as each blog page is loaded into the browser. With help from a friend (thanks, Terry!), I wrote a few lines of JavaScript. The code is in a file called fixer.js.

To execute the code, I made two changes to my blog template. I added a <script> tag to the header:
<script type="text/javascript" src="http://mysite/fixer.js" />

Then I added an onload attribute to the <body> tag:
<body onload="fixImagesAndLinks('oldsite', 'mysite')">

Voila! The old URLs are now magically fixed. In a way, this is a kludge. I wouldn't recommend this approach for a production web application, but this is just a hobbyist-type blog. Sometimes a kludge is the right tool for the job.

Friday, March 24, 2006

Tenants Wanted, Apply within


Not Enough Enterprise

It's been a while since I tuned into The Daily WTF. (Warning: Regular readers of The Daily WTF may experience serious misgivings about the state of the art of software development.) It's probably not healthy keep up with all the insanity at WTF, but Bitten by the Enterprise Bug really made me laugh:
... their system wasn't the greatest, but it was fairly documented, easy to work with, and, most importantly, did the job. But one thing it lacked, so said upper management, was "enterprise." And that is something that no system should be with out.
Time to bring in the enterprise consultants!

Monday, March 20, 2006

You Are What You Post

Have you ever regretted a comment you posted to someone's blog? Do you wish you could erase your posts from that alt.anarchism discussion way back in 1992? According to You Are What You Post, you should be concerned:
... because today there are two of you. There's the analog, warm-blooded version ... Then there's the online you, your digital doppelganger; that's the one that is growing larger and more impossible to control every day.

Googling people is also becoming a way for bosses and headhunters to do continuous and stealthy background checks on employees, no disclosure required.

This is a good reminder to be careful what you say on the Net and how you say it. I am not advocating self-censorship, but it's worth looking down the road before you post. Are you sure you won't regret your words five years from now?

Friday, March 17, 2006

The Evolution of Software Design

I think Software Development's Evolution toward Product Design* is an important essay. The author, Danc at Lost Garden, gets a lot of things right. His four distinct eras of software development sound about right to me. I don't quite remember "The Technocrat Era", but I lived through the "Early Business" and "Late Business" eras. I know first hand many products of those eras confounded users' expectations.

On the other hand, I think Danc is being unfair when he implies each product of those bygone eras was nothing more than "a pile of poo". His artist's rendition is very funny, but it's still unfair. Danc is also too sanguine about the glories of the "Product Design Era".

Danc seems to believe the key to successful software development is to involve people in berets (artists and designers) early in the project life cycle. He refers to a so called "Production Pipeline" in which the people in berets lay the ground work for pliant programmers. To be fair, Danc doesn't think this will be easy:
Unfortunately, many companies that attempt to adopt a product design philosophy will also fail, despite their best efforts. Cultural change is hard work. To adopt product design you must alter the most basic DNA of the company's values.
It's true we need cultural change and he's right it won't be easy, but inertia is not the only problem. In my opinion, the bigger problem is the people in berets don't have all the answers. They certainly don't always agree on the answer.

For example, many designers are orthodox User Centered Design (UCD) disciples. They design products for user personae and insist the software must always adapt to the user. They can cite chapter and verse from the high priests of UCD including Alan Cooper and Don Norman. But Don Norman himself recently broke ranks with UCD orthodoxy. In Human-Centered Design Considered Harmful, Norman dropped some bomb shells:
HCD asserts as a basic tenet that technology adapts to the person. In [Activity-Centered Design], we admit that much of human behavior can be thought of as an adaptation to the powers and limitations of technology. Everything, from the hours we sleep to the way we dress, eat, interact with one another, travel, learn, communicate, play, and relax. Not just the way we do these things, but with whom, when, and the way we are supposed to act, variously called mores, customs, and conventions.

People do adapt to technology. It changes social and family structure. It changes our lives. Activity-Centered Design not only understands this, but might very well exploit it.

Now consider the method employed by the Human-Centered Design community. The emphasis is often upon the person, not the activity. Look at those detailed scenarios and personas: honestly, now, did they really inform your design? Did knowing that the persona is that of a 37 year old, single mother, studying for the MBA at night, really help lay out the control panel or determine the screen layout and, more importantly, to design the appropriate action sequence? Did user modeling, formal or informal, help determine just what technology should be employed?

I think Norman's Activity-Centered Design principles are much saner than strict UCD, but the art of user interaction design is still evolving. The people in berets don't have a silver bullet. It is unlikely they ever will. User interaction design, like software architecture, is hard work. It will be another era or two or three before we get it right even most of the time.

* via Ned

Monday, March 13, 2006

Google Mars

What's the significance of today's banner on the Google home page? Click on the banner and be amazed. It takes you to a new Google Mars service where you can explore the Martian surface.

Since most of us aren't familiar with Martian geography, Google Mars lets you browse by Regions, Spacecraft and Stories. To see what I mean, click the links at the top left of the Google Mars page. Very cool.

Sunday, March 12, 2006

NH Moose Rescued from Swingset

On Friday, Don Valliere rescued a moose from a swingset in Milan, NH.
"It didn't like the idea too much that I stayed close to it, but it stayed calm," Valliere said Friday. "The only thing I was nervous about was getting bit."

Sunday, March 05, 2006

Jumping on the Broadband Wagon

Believe it or not, we used the same dial-up service at home for almost ten years. Until about a year ago, this was just fine. We didn't need more bandwidth. Like most things in life, the situation became untenable by degrees. It's amazing how we tolerated the slow loading of web pages and the glacial speed of retrieving mail messages stuffed with (often unsolicited) digital images. That wasn't a huge problem. The straw that broke the camel's back was the unavailability of our phone service while connected to the Net. With the phone tied up for an hour or two each day, there was no denying it. We had a (gasp) bandwidth problem.

I considered subscribing to digital cable and adding high-speed Internet to my cable service. One look at the monthly rate and I changed my mind. Instead we went with DSL. At least in my area, Verizon Online DSL is much cheaper than cable. Verizon shipped my DSL modem a few days after I placed the order. Just a few days after that, they enabled DSL service. The installation was incredibly easy. The Verizon installation disk includes very simple, audio setup instructions. We were connected in less than an hour.

Part of my motivation for getting broadband, was to have faster access to my company's Virtual Private Network (VPN). Getting to the VPN over DSL proved to be a little more difficult. When I authenticated with the VPN, my client went into an endless loop supposedly "exchanging keys with the VPN server". After googling for help and coming up empty handed, I finally consulted some colleagues at work. The solution was to upgrade my VPN client and switch from IPSec to SSL. I don't understand all the trade-offs of IPSec vs. SSL, but it's clear SSL is compatible with more DSL modems, cable modems and wireless routers.

So I am up and running. Broadband will make it possible for me to work more hours from home. When I'm not working, my family and I can now enjoy educational videos like Einstein Robot. This is progress? The only thing better would be to have a wireless router so I can work and watch streaming videos from any room in the house. I can't wait. If you can recommend a good wireless router, please let me know.

Wednesday, March 01, 2006

Getters, Setters and Object Orientation

As I read Martin Fowler's Getter Eradicator essay, I wondered for a moment what I was missing. As Fowler says:
[One] sign of trouble [in OO design] is the Data Class - a class that has only fields and accessors. That's almost always a sign of trouble because it's devoid of behavior. If you see one of those you should always be suspicious. Look for who uses the data and try to see if some of this behavior can be moved into the object. In these cases it can be useful to ask yourself 'can I get rid of this getter?' Even if you can't, asking the question may lead to some good movements of behavior.
The problem is my work lately has been full of Data Classes, or what my colleagues and I call Value Objects. A value object is nothing but a bag of properties with getters and setters. A value object is almost devoid of behavior. It is usually passed to or returned by a service that implements the behavior. I found myself wondering, "Is this a bad thing?"

Fowler's essay refers to an even better essay by Allen Holub called Why Getter and Setter Methods Are Evil. Holub warns the reader about violating encapsulation with getters and setters and then back-peddles. There are some valid uses for getters and setters. For example:
The vast majority of OO programs runs on procedural operating systems and talks to procedural databases. The interfaces to these external procedural subsystems are generic by nature. Java Database Connectivity (JDBC) designers don't have a clue about what you'll do with the database, so the class design must be unfocused and highly flexible. Normally, unnecessary flexibility is bad, but in these boundary APIs, the extra flexibility is unavoidable. These boundary-layer classes are loaded with accessor methods simply because the designers have no choice.
That perfectly describes my recent work. I have been working on an abstract, highly flexible Service Provider Interface (SPI). Since I can't force reuse of behavior, I have to define transparent value objects and defer the behavior to each service provider.

All well and good, but Fowler and Holub have reminded me this is not Object Orientation. I guess it is closer to Service Orientation. I am reluctant to call it that only because there is so much other baggage associated with Service Oriented Architecture. In any case, the point is this: Use of getters and setters can be a bad habit. Although I continue to work on my SPI, I occasionally venture up into the Object Oriented layers above my interface. When I do, I'll be on the lookout for inappropriate getters and setters.