Archive for the ‘fiddling details’ Category


Give me space


If you ever enter credit card information online, you’ll undoubtedly encounter the peculiar request to omit spaces from credit card numbers, such as on this fairly typical form:

Excluding spaces

Now, as an actual programmer of computery software, I see such requests as completely bizarre. There is absolutely no reason whatsoever why you, the human, should have to carefully avoid pressing the space bar while entering a credit card number. Since the bank, to whom this data will shortly be delivered, is expecting a credit card number, and since the bank defines what those look like, they can scrupulously throw away everything else you, or your space-loving cat, types that isn’t 1, 2, 3, 4, 5, 6, 7, 8, 9 or 0.

It’s so easy, that I’d expect any competent programmer to be able to immediately write a piece of code to do this, off the top of their head, with no bugs. If they couldn’t do this in, say, a technical interview for a programming job at bank, they shouldn’t be hired.

In fact, it’s highly likely that the amount of time and effort necessary to place the warning “(excluding spaces)” in the web page is more than the effort required to adjust the software to remove the spaces for you.

Cleaning up the data you receive, such as removing unnecessary spaces from it, is known as sanitizing the data, and it’s not only trivial, but essential if the bank is to have a chance of running a secure and reliable operation.

In my more cynical moods [not at all encouraged by having actually worked in banking operations, he said rolling his eyes], I see the “excluding spaces” request as meaning “our programmers aren’t so good with the sanitizing and the programming and the stuff, so please help them, thanks so much“.

So, with all that in mind, here are not one, but two, stories of what happens when banks apparently fail to remove spaces from a critical value, with hilarious consequential overdrafts.

If you look at both these stories, the amounts of money the poor saps’ credit cards were charged are suspiciously identical: $23,148,855,308,184,500.00. This is the kind of stupid number that immediately makes me want to view it in base 16 (a technically useful way of representing data), in case that provides a clue as to what’s going on.

In base 16, 2314885530818450000 (with the extra 00 on the end meaning cents) is 2020202020201250. That looks a lot to me as if it’s really meant to be 1250 (for example, meaning $12.50 in binary-coded decimal, commonly used in financial systems to represent numbers precisely), but somehow with a pile of spaces stuck on the front (since 20 is a common computer code for space). This is almost certainly the work of a piece of software between the retailer and the bank, which is wrongly padding the value out to fit a fixed-size field for transport (and probably also wrongly changing the type of it too).

But it’s also a sterling example (sic) of why the receiving system should remove unexpected spaces from something that’s intended to be a number, rather than just passing it on to a program that will mishandle it gloriously.

Of course, it would also, maybe, perhaps, be a good idea to make sure that the withdrawal request doesn’t exceed the size of the world economy. But that’s actually harder than just excluding spaces, since the banks think they can get you to do that for them.


The Future of Web Proof-reading


For better or worse, I’m cursed with the ability to spot typos and spelling errors that normal people miss.

For example, this one on the home page of the Future of Web Apps conference that I’m somehow not attending:

But is it really so hard to see the ‘The The‘ in this rather large graphic?

The offending extra article

Personally, I think that somewhere in the actual future of web apps, there ought to be something that can help with proof-reading as least as well as desktop apps of the actual past can.