The Daily Parker

Politics, Weather, Photography, and the Dog

High-tech wine glasses for road warriors?

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."


PINs stolen from retailer; thousands of debit cards recalled

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.

Why a mobile phone might be a huge security risk

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.

Programming languages compared

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.


Shoot yourself in the foot.


You shoot yourself in the foot.
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."
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.
The compiler won't let you shoot yourself in the foot.
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.
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.
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...
Foot in yourself shoot.
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.
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.
Put the first bullet of gun into foot left of leg of you. Answer the result.
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.
You shoot yourself in the foot, then spend all day figuring out how to do it in fewer characters.
If you succeed, shoot yourself in the left foot. If you fail, shoot yourself in the right foot.
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.
Not only can you shoot yourself in the foot, your users can, too.
You try to point the gun at your foot, but it shoots holes in all your Borland distribution diskettes instead.
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.
You try to shoot yourself in the foot, only to discover you must first invent the gun, the bullet, the trigger, and your foot.
After realizing that you can't actually accomplish anything in this language, you shoot yourself in the head.

Have laptop, will travel

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.

Class or struct part 2

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) 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.

Class or struct?

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.

Database error causes $8.1M budget shortfall

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.

State of Delusion

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."