The Daily Parker

Like the journeymen of old, I have packed up my tools and traveled far from home to practice my craft. Unlike the journeymen of old, I can go home every weekend.

So, I have a new cube, a new team, and a room at the nearby Extended Stay America. As I get settled, I'll write more on a few subjects familiar to the thousands of other software developers who find themselves in similar circumstances:

• Work/Life balance when your life is there, you're here, and you bill by the hour (i.e., the importance of finding a good brewpub);
• Why East Bumble pays better than Chicago or New York;
• Agile software development on two cups of coffee a day; and
• How to feel peaceful at O'Hare first thing Monday morning.

At this precise moment, however, I need to obtain a Brita pitcher and a clock with a radio (do I really want to have to futz with streaming audio just to hear Morning Edition?) from the local Target. Then, I'm off to find a brewpub.

Just this morning I wrote about choosing a class over a struct to take advantage of inheritance and abstractness. It turns out, I was wrong.

Well, not that wrong. It's just that this particular design doesn't actually derive that many benefits from inheritance.

First, there will still be a lot of redundant code. The IEquatable<T> and IComparable<T> interfaces both require implementation in concrete classes, so all of the measurement classes would have nearly identical CompareTo and Equals methods. Also, all of the arithmetic operators come in three flavors:

public static bool operator ==(double a, ConcreteClass b)
public static bool operator ==(ConcreteClass a, double b)
public static bool operator ==(ConcreteClass a, ConcreteClass b)

...so all of those need to be in each of the concrete implementations (even if they call the same code in the base class).

And, of course, the Explicit and Implicit operators have to be customized for each class.

Redundancy. I hate it. But it's necessary for this kind of design.

Second, as it turns out, the implementation differs significantly enough between the measurement classes in one key respect that they really can't use a common base class. The problem is, some measurements are actually aggregations of other measurements.

Area, for example, is a length times a length. Volume is either three lengths or a length times an area. Don't even get me started on how to represent velocity.

In my first implementation of representing measurements (still visible as of this writing), I finessed the problem of multi-dimensional values by creating multi-dimensional units, like MeterSquare and PoundSquareInch. That created a real headache in the implementation of conversions, because while converting meters to feet is a simple mulitplication, converting liters to cubic inches is only linear if you proliferate your inch class into square and cubic dimensions.

In other words, despite my goal of having a simple conversion mechanism, I had to write specific conversions for multidimensional measurements anyway, which I managed by putting the knowledge of how to convert units into the units themselves rather than in the measurements where (I think) they belong.

The only way to do that and retain some extensibility was to require each unit to know how to convert itself to a base unit: square meters for area, for example. This, in turn, introduced rounding errors for broad conversions within measurement systems that prevent round-trip conversions from working. In other words, if you convert a very small value to a very big value by using an intermediary, you can't convert the big value back to the same small value. For example, there are exactly 4,014,489,600 square inches in a square mile, but if you convert to square meters first you get 4,014,489,340.464 instead. That's just embarrassing.

In sum, despite what I wrote this morning, I'm throwing out the work that resulted from it and going back to structs for my measurement classes.

I've encountered a problem familiar to veteran C# developers: whether to use a class or a struct for a particular design. So I'm going to follow my own advice and develop first for elegance and second for execution speed.

The specifics: As I mentioned earlier, I'm re-writing the way the Inner Drive Extensible Architecture handles measurements. I've identified 16 scenarios in which I use measurement classes, and I want them to be as intuitive as possible. So, for example, scenario #1 is "instantiate a new measurement:"

Length meters = new Length(15, typeof(Meter));
meters.ToString() == "15 m"

Another scenario is "add two measurements:"

longLength = length1 + length2;

I also expect to use the items in lists:

SortedList<Length> lengths = new SortedList<Length>();

This last scenario requires that the Length class implement IComparable (or IComparable<T>), on the one hand, and that it be lightweight, on the other.

Here's where the class v. struct problem comes in. Structs are lightweight, because the .NET runtime places them on the stack directly instead of placing pointers to them on the stack. In other words, using a class requires indirection, and that takes enough time for you to notice if you're dealing with hundreds or thousands of them.

Therefore, my first attempt, which I am discarding, was to create the measurement classes (Length, Volume, Mass, etc.) as structs.

I soon ran into several problems that convinced me to create an abstract Measurement class that the individual types of measurement will inherit from:

1. Lots of duplicate code. Adding, subtracting, equality, assignment—they're the same, with minor and specific differences, for each of the measurement types. You can't easily share code between structs. Using inheritance, about 90% of the code can go into the abstract class.
2. Validation in multiple constructors. I need to validate the initial data used to create measurements, so that attempting to create a length of Fahrenheit throws an exception. Since the entire struct must be initialized before control leaves the constructor, this requires that I put validation code in several places, depending on how the constructors work.
3. Finally, now that .NET allows property setters and getters to have different visibility (public get with protected set), it's much easier to make classes immutable without making them structs.

If there's a tremendous performance hit, I'll worry about that when the design is stable.

Software security expert Bruce Schneier reports on a database error in nearby Porter County, Ind., that has cost the county millions of dollars, and what that means to software design:

A house erroneously valued at $400 million is being blamed for budget shortfalls and possible layoffs in municipalities and school districts in northwest Indiana.

[...]

County Treasurer Jim Murphy said the home usually carried about $1,500 in property taxes; this year, it was billed $8 million.

From Paul Krugman's column (sub.req.) this morning:

This administration is all politics and no policy. It knows how to attain power, but has no idea how to govern. That's why the administration was caught unaware when Katrina hit, and why it was totally unprepared for the predictable problems with its drug plan. It's why Mr. Bush announced an energy plan with no substance behind it. And it's why the state of the union—the thing itself, not the speech—is so grim.

And this little tidbit from Poynter Online correspondent Alan D Abbey:

I ran across this brief couplet upon perusing "The Norton Book of Light Verse" with my son, who needed a short poem for something he is doing in school. It's a nice comment on the current media environment, and the explosion in volume, at least, of content and brands. It's by 17th-century physician and poet Samuel Garth, and it goes like this:

"What frenzy has of late posssess'd the brain
"Though few can write, yet fewer can refrain."

Heh.

One of my clients has had a recurring server issue caused, it seems, by McAfee Anti-Virus. So we're switching to Symantec.

The problem has been that, for quite some time, the naPrdMgr.exe process (which handles product updates) has gone into a death-spiral, consuming 100% of CPU cycles and making the server totally unresponsive to anyone else. I've finally gotten in touch with McAfee, and they said the client's license has expired.

OK, so how does an expired license crash a server? When McAfee Anti-Virus doesn't have a current license, and it attempts to get an update from home, it crashes. Yes. It crashes. This behavior is a known defect, but they won't fix it for us unless we renew the license. So until we pay them we can't fix our server, and every day, like poor Mr. Bix[1], I have to fix it.

Now, let me explain how Symantec does this, because I think it's instructive, and I've just updated my own virus protection in this fashion:

1. Forty-five days before the license expires, the server itself sends an email to the administrator, right there on site, and pops up a helpful box when you log into the server for any purpose.
2. To update the license, you pay your fee, then they email you a license certificate.
3. You go online and enter the certificate number, then they email the license to you. This two-step process seems cumbersome, but it helps ensure the right person gets both files, and the files aren't misplaced.
4. You go to the server, log into the virus console, and slurp up the license. Boom: done.

So instead of giving McAfee more money, we're switching to Symantec.

[1] I refer, of course, to the following passage from Did I Ever Tell You How Lucky You Are? by Dr. Seuss:

And poor Mr. Bix! 
Every morning at six,
poor Mr. Bix has his Borfin to fix! 

It doesn't seem fair. 
It just doesn't seem right, 
but his Borfin just seems 
to go shlump every night. 

It shlumps in a heap, 
sadly needing repair. 
Bix figures it's due 
to the local night air. 

It takes him all day to un-shlump it. 
And then....

The night air comes back 
And it shlumps once again!

So don't you feel blue. 
Don't get down in the dumps. 
You're lucky you don't 
Have a Borfin that shlumps.

I can't believe I forgot to post about the Weather Now Beta launch Tuesday evening.

I'll have more details later, including a list of why the new application is so much cooler than the current one, but right now I'm trying to figure out why a client's server keeps horking every day.

We were dark for over 6 hours today because someone at SBC did something, though no one seems to know who or what. The result was that the Inner Drive Technology World Headquarters had no phone or Internet service from 9:15 am CT/15:15 UTC until 3:30 pm CT/21:30 UTC.

Sadly, this came on the first day of our Weather Now beta launch, which shows off some of our coolest stuff ever. (At this writing it's still a few hours behind, with weather from lunchtime today, but it's catching up as fast as it can.)

One of my friends asked, "How can they do that?" Well, like I said...they're the phone company.

Genius Boy here just spent ten minutes debugging a class because I used the private field directly inside the class, instead of the property accessor method.

Here's what the property looked like:

public string FileSpec
{
	get { return _fileSpec; }
}
private string _fileSpec;

Notice there's no set method. The file spec is set only in the constructor, and is immutable at runtime. That means that throughout the class I had code like this:

if (File.Exists(_fileSpec))
{
	_cache.Load(_fileSpec);
}

The problem? Well, the private data could contain any number of tokens representing disk or remote folders, which wasn't a requirement when the class was first built.

The solution? C# 2.0 gives you the power to create an accessors of different visibilities, like this:

public string FileSpec
{
	get { return _fileSpec; }
	private set
	{
		_fileSpec = DeTokenize(value);
	}
}

The constructor now looks like this:

public MyClass(string fileSpec)
{
	FileSpec = fileSpec;
}

And then the code that uses the value can do this:

if (File.Exists(FileSpec))
{
	_cache.Load(FileSpec);
}

All better.

First, New York Times columnist Bob Herbert has a great column today (sub.req.):

[The President's] breathtaking arrogance is exceeded only by his incompetence. And that's the real problem. That's where you'll find the mind-boggling destructiveness of this regime, in its incompetence. ... [T]he plain truth is that he is the worst president in memory, and one of the worst of all time.

Second, I've been ambivalent about the Times charging $49.95 per year to read most of its content, but I think more and more that it's fair. I don't know, though. I pay it, because I read Krugman and Dowd every week, and I like occasionally reading the Magazine. What are other people's thoughts on this?