The Daily Parker

Here's a hint: the problem is between chair and receiver.

Bruce Schneier linked today to this excellent essay on the unseen dangers of mobile phones:

About four seats away is a gentleman (on this occasion pronounced 'fool') with a BlackBerry mobile device and a very loud voice. He is obviously intent on selling a customer something and is briefing his team. It seems he is the leader as he defines the strategy and assigns each of his unseen team with specific tasks and roles.

Eventually, he starts to close down the conversation. Relief might be here at last! Oh no, he goes on to announce the conference number and the pass code - and say he will see them all on the conference call in a minute.

My colleague Cameron Beatley sent me this handy chart:

Quick Guide to Programming Languages

The proliferation of modern programming languages (all of which seem to have stolen countless features from one another) sometimes makes it difficult to remember what language you're currently using. This handy reference is offered as a public service to help programmers who find themselves in such a dilemma.

Task

Shoot yourself in the foot.

Comparison

C

You shoot yourself in the foot.

C++

You accidentally create a dozen instances of yourself and shoot them all in the foot. Providing emergency medical assistance is impossible since you can't tell which are bitwise copies and which are just pointing at others and saying, "That's me, over there."

FORTRAN

You shoot yourself in each toe, iteratively, until you run out of toes, then you read in the next foot and repeat. If you run out of bullets, you continue with the attempts to shoot yourself anyways because you have no exception-handling capability.

Pascal

The compiler won't let you shoot yourself in the foot.

Ada

After correctly packing your foot, you attempt to concurrently load the gun, pull the trigger, scream, and shoot yourself in the foot. When you try, however, you discover you can't because your foot is of the wrong type.

COBOL

Using a COLT 45 HANDGUN, AIM gun at LEG.FOOT, THEN place ARM.HAND.FINGER on HANDGUN.TRIGGER and SQUEEZE. THEN return HANDGUN to HOLSTER. CHECK whether shoelace needs to be re-tied.

LISP

You shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds the gun with which you shoot yourself in the appendage which holds...

FORTH

Foot in yourself shoot.

Prolog

You tell your program that you want to be shot in the foot. The program figures out how to do it, but the syntax doesn't permit it to explain it to you.

BASIC

Shoot yourself in the foot with a water pistol. On large systems, continue until entire lower body is waterlogged.

Visual Basic

You'll really only appear to have shot yourself in the foot, but you'll have had so much fun doing it that you won't care.

HyperTalk

Put the first bullet of gun into foot left of leg of you. Answer the result.

Motif

You spend days writing a UIL description of your foot, the bullet, its trajectory, and the intricate scrollwork on the ivory handles of the gun. When you finally get around to pulling the trigger, the gun jams.

APL

You shoot yourself in the foot, then spend all day figuring out how to do it in fewer characters.

SNOBOL

If you succeed, shoot yourself in the left foot. If you fail, shoot yourself in the right foot.

Unix

ls
foot.c foot.h foot.o toe.c toe.o
% rm * .o 
rm:.o no such file or directory
% ls
%

Concurrent Euclid

You shoot yourself in somebody else's foot.

370 JCL

You send your foot down to MIS and include a 400-page document explaining exactly how you want it to be shot. Three years later, your foot comes back deep-fried.

Paradox

Not only can you shoot yourself in the foot, your users can, too.

Access

You try to point the gun at your foot, but it shoots holes in all your Borland distribution diskettes instead.

Revelation

You're sure you're going to be able to shoot yourself in the foot, just as soon as you figure out what all these nifty little bullet-thingies are for.

Assembler

You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.

Modula2

After realizing that you can't actually accomplish anything in this language, you shoot yourself in the head.

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.