The Daily Parker

There's a privacy bug in Mozilla that has ended at least one relationship.

About a month ago, I promised to write about traveling for business. I only now have a little time to do so.

One question I get from many who live near my client (in Merrimack, N.H.) is, why do I fly into Boston Logan instead of Manchester? Simply put, it's faster and cheaper.

Faster, because the trip from my home to O'Hare takes about 30 minutes, while the trip to Midway would take closer to 90. That is significantly greater than the difference between travel times to Logan (60 minutes) and Manchester (20).

Cheaper, for many reasons. Chicago (O'Hare) to Boston is served by four or more major carriers; Chicago (Midway) to Manchester by only one. Consequently, it's often, but not always, cheaper to fly to Boston. Next week, for example, my fare on American is $134; this week it's $168. Compare with Southwest's minimum for any round-trip, which seems to be $198. Even when my fares are higher at more popular times, like at the end of April ($313), they're also higher into Manchester.

Finally, Logan gives me more options, should weather or airline management affect the flight schedule. American has 8 non-stop flights daily in each direction; Southwest only has 3.

So, Logan it is.

Back in the day, when computer pointing devices had little spheres that rolled around table tops to move the on-screen pointer, I used to joke about "dirty mouse balls" requiring a thorough and intimate cleaning of the afflicted device.

Apparently mouse balls are much more important than I thought. Maybe I should re-think my switch to optical pointing devices...

Very funny, but possibly offensive 3rd Annual Nigerian Email Conference website.

I'm not sure what Anne thinks, but as long as I'm commuting to New Hampshire, maybe we should get these Wi-Fi wine glasses:

Jackie Lee and Hyemin Chung, experts in human-computer interaction...have incorporated a variety of coloured LEDs, liquid sensors and wireless (GPRS or Wi-Fi) links into a pair of glass tumblers. When either person picks up a glass, red LEDs on their partner's glass glow gently. And when either puts the glass to their lips, sensors make white LEDs on the rim of the other glass glow brightly, so you can tell when your other half takes a sip. Following tests in separate labs, Lee says the wireless glasses really do "help people feel as if they are sharing a drinking experience together."

Awww...

MSNBC is reporting today that thieves have stolen a batch of PINs from a retailer—PINs the retailer shouldn't have stored in the first place:

Criminals have stolen bank account data from a third-party company, several banks have said, and then used the data to steal money from related accounts using counterfeit cards at ATM machines.

The central question surrounding the new wave of crime is this: How did the thieves managed to foil the PIN code system designed to fend off such crimes? Investigators are considering the possibility that criminals have stolen PIN codes from a retailer, MSNBC has learned.

In recent weeks, Bank of America, Wells Fargo, Washington Mutual and Citibank have all reissued debit cards after detecting fraudulent activity. Smaller banks, such as Ohio-based National City Bank and Pennsylvania-based PNC Bank, have taken similar steps.

Bruce Schneier reported on this Monday, but now the scope of the crime is becoming more apparent.

So how did the thieves get the customers' PINs? It appears that a retailer stored them along with other credit-card data in its database, and the thieves stole the database:

[Gartner analyst Avivah Litan] says many merchants incorrectly store PIN information they should be destroying after customers enter the secret code on PIN pads in stores around the country. While the information is often encrypted into something called a PIN block, the keys necessary to decrypt the information are often stored on the same network, she said. That makes stealing the PINs as easy as breaking into an office computer using a password a careless employee has taped to the screen.

The thing is, the retailers have no need to store the PINs:

While storing PINs is against network rules, many retailers inadvertently store the information, said Mike Urban, who runs Fair Isaac Inc.'s ATM fraud detection program called CardAlert. It ends up accidentally saved in temporary files and other software nooks and crannies.

ZDNet has this story too.

The solution to this problem, long known to concientious software developers, is never to keep secrets unless they're absolutely necessary. I tell my clients all the time that neither I nor anyone else should ever know their passwords, for for example.

It will be interesting, and important to every consumer, to see how liability for this event is apportioned. Sadly, most courts and legislators are woefully ignorant of the technology, which should lead to some fascinating legal work in coming months.

Until this issue gets resolved, which could take weeks, I urge people to be very careful using point-of-sale debit card readers. And if you suspect unauthorized activity on your bank account, call your bank immediately.

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.