I mentioned Friday that I've completely refactored the section of the Inner Drive Extensible Architecture™—the Idea™—that handles quantitative functions. (I've also decided to make some SDK documentation available.) The actual design of the IMeasurable classes—Length, Speed and the like—bears more discussion.
What I have, essentially, is a collection of .NET structs that implement IMeasurable, one for each kind of thing you want to measure. The old design had a single struct called Numeric that could represent any kind of measurement at all. The change means that the measurement type is now enforced by the compiler rather than the run-time engine, because instead of this:
Numeric meters = new Numeric(10d, new Meter());
Numeric pounds = new Numeric(10d, new Pound());
Numeric compilesFine = meters.Add(pounds);
> IncompatibleUnitException thrown
You get this:
Length meters = new Length(10d, new Meter());
Mass pounds = new Mass(10d, typeof(Pound));
Length wontCompile = pounds.Add(meters);
> Compiler error: no overload of Mass.Add takes Length as a parameter
One thought I had, though, was: why not make each of the units a measureable type to further constrain the design? So you would have this instead:
Pound pounds = new Pound(10);
Gram grams = new Gram(10, MetricExponent.Kilo);
Pound pounds = pounds + grams;
Simply: that would require either dozens of nearly-identical structs, or I would have had to use classes instead. Remember that a struct can't inherit from anything except System.ValueType. So each struct either has to contain all the relevant code (about 1200 lines of it for each of my IMeasurable classes, including documentation), or it has to compose most of its functionality from other, static objects—which is actually quite difficult in this context.
Structs are small very fast, and immutable, which makes them the best choice for small, fast, immutable things like measurements. I'd rather represent measurements with structs than objects, but I'd also like to avoid writing and unit-testing dozens of nearly-identical classes. So I compromised: representing each type of measurement with its own struct (so there are now only 8 of them), and allow the abstract Unit class to define how the individual units interact.
Check out the Quantitative SDK and let me know what you think.
Usability guru Jakob Nielsen has a new column today reminiscing about the hype of 1997 because it's back in vogue:
The fads and big deals that get the press coverage are not important for running a workhorse website. To serve your customers, it's far better to emphasize simplicity and quality than to chase buzzwords.
There is endless coverage of a few atypical stories in the trade press, mainstream media, and even on specialized Internet-focused websites. Once again, it's worth remembering: your site is different from the ones in big stories. Focus on fixing the basics to get a simple and communicative website. Simple steps don't get hyped, but they drive much more business value for the average site than the issues that everyone writes about.
He includes a sidebar about the fads of 1997 and how they're doing today.
In January, I wrote about framework classes I was working on, and how I wanted to simplify the Inner Drive Extensible Architecture™. I followed up in February with a conundrum concerning how to model the problem. It turned out to be tricky, and time-consuming, and considering I wrote most of it at The Peddler's Daughter in Nashua, N.H., there was a lot of Smithwick's Ale[1] involved.
But today, at last, I've got a new demo.
The demo page has a lengthy explanation of how the new version works, and includes a bunch of source code showing how simple the stuff is to use and to extend. I still have a little polishing to do, but I'll probably be putting the full SDK documentation for the IDEA™ up on the Inner Drive website later this month.
I think this is some of the coolest stuff I've ever written.
[1] I would have linked to the official Diageo site, but it's so annoyingly badly written—it whisks you away to a page requiring your birthdate and it tries to cookie you—that on principle I won't have that as the primary link to this product.
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.