443 words on earthlingsoft
Rechnungs Checker isn’t dead yet! It’s just that the handful of people known as its ‘user base’ seem to get along well with no dreadful stories about telephone companies changing their file formats having come in for a while.
Instead, one of our users managed to run into an honest-to-goodness problem with the application that made Rechnungs Checker match a phone number with a wrong name from the System’s address book. It’s been a bit of a deliberate problem that I considered to be rather unlikely to come up but now – a few years later – it has. Tough luck I guess! The problem stems from the fact that people may have the same phone number in different area codes – which Rechnungs Checker can handle of course. However, I need to be a bit relaxed when trying to match the numbers because on the one hand people are relaxed when entering them into their address books – using all sorts of separators and combinations of (number) or (areacode)-(number) or +(international prefix)-(area code)-(number).
The phone bill itself contains numbers in all three formats as well – essentially because it just contains the numbers you actually dialled and thus won’t contain the area code for local calls and so on. Because of all this, Rechnungs Checker matches numbers from the back when trying to figure out whose number it is. And that caused the problem for the case when both a local contact and a non-local contact have the same number in their respective aerea codes. I came up with a reasonable heuristic to match the correct contact more reliably but unfortunately I couldn’t test that at first as even with some fiddling and twiddling I couldn’t actually reproduce the problem on my machine (because OS X’s address book doesn’t return contacts in a predictable order and – by bad luck I guess – I ended up always getting Rechnungs Checker to see the correct contact first.
Luckily Wolfgang who reported the problem figured out a way to reproduce it my machine as well (using a huge >1500 entry address book seemed to push things around so we could reliably get the wrong result) – which in turn revealed a stupid bug in my new workaround. But this should be sorted now and up to an exception or two things seem to work all right. I’ll leave figuring those exceptions out to the curious reader.
Further enhancements include updating the URL that Rechnungs Checker sends the user to for reverse lookup of phone numbers, better support for users of the wrong mouse button and the inclusion of the Sparkle framework to notify people of future updates.
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.