bruno fernandez-ruiz

On Friday I received and “Online Banking Card Reader” from NatWest, my bank here in the UK. Let me tell you, it is one of a curious kind.

NatWest issued me a new debit card a few weeks back now, although it was actually not due. The chip in the new card looked slightly different from the one on the last one, but it is still an EPROM with 255 bytes of storage. I have not read its contents yet … I am sure I am bound by some dubious legal agreement not to do it anyway.

The device is roughly the size of a smallish pocket calculator. It is a Xiring device, patented by French company Xiring. The device has a PIN-and-chip reader where you slide your debit card into, and it then prompts you for input. The device has three modes of operation:

* Identity, enter a secret (your PIN) and receive back a secure code.
* Respond, enter a secret and a (reference) number and receive back a secure code.
* Sign, enter a secret, a (reference) number and an amount, and receive back a secure code.

It seems like a useful device, more secure than the current password solution RBS/NatWest has. The only way to do online banking in the future with NatWest will be through this device.

I am not sure about it though. The device is nothing but a fancy electronic challenge/response card, but highly inconvenient to the consumer. The device relies on batteries and it’s very bulky compared to a card you can slot into your wallet.

My bet is that we will see massive pushback.

We have recently moved into a new house. The house is pre-wired with all sort of things one can imagine, for sound, video, network, motion, alarms, etc. It’s really cool! But guess what, all wiring is behind plasterboards, and we don’t have any instructions as of what and where it is. One end of all wires end up in one of the rooms, so I could put a high frequency pulse generator and trace down the wires behind the drywall. Sorted.

Well, not really.

You see, whoever put that wiring in while the house was being built had an idea in mind. The wiring would fit into a particular set of sensors, alarms, and speakers. The builder was also conditioned by what was available in the market, so it planned wiring suitably for a multi-room A/V controller. The thing is, the builder left it “pre-wired”, never finished it. Sort of an optional thing you could do whenever you moved in.

7 years later. Multi-room A/V and control systems have evolved so much that the technology the builder had in mind has been rendered obsolete. 1Gbit network now allows video streaming over CAT5e/CAT6 cables. So you don’t need anymore expensive multi-room controller. I just need good network around the house, and commodity amplifiers in each room where you need sound/image/alarm, etc.

You see, all that wiring the builder put in? Useless.

Moral for us software engineers. Whenever you write a piece of code or implement a new feature always remember to make it obvious. And the best way to make it obvious is to make sure it is used. Don’t write software for the just-in-case scenario.

You see documentation is good, very good, but there is no point documenting a feature that is not obvious. By the time you get to use actually it, it will be obsolete and too complex to make it worth understanding it.

In summary, it will always be easier to find out how things work, than how things could work. Things that work are self-explanatory: they are obvious.

See, I can live with Evolution crashing once in a while. Hell, it’s software, it’s meant to fail. But another thing is when the whole damn thing fails silently and in consequence kills your productivity. Evolution has managed to randomly delete part of my calendars, appointments here and there, and multiple appointments moved in time. End result, missing meetings and looking like a complete idiot. The top of the iceberg happened on Monday when Evolution corrupted one of IMAP folders. Ouch! Pain, I know, I hear you.

I am off Evolution. evolution-data-server is just waaaaaaaaay too buggy. Sometimes I wonder if Novell buying Ximian was actually such a good thing … but anyway that’s another story.

What I am using now? Shh, don’t tell anyone! Kontact, KAnything, KThis, KThat, KSomethingElse … KDE!

Being a Mono/GNOME fanboy, I have set myself a challenge: only use KDE and stick to native KDE apps for a week. Well … I really meant to stick to Konqueror, but after 10 min I had to give up on that - I had forgotten the web does not run on standards - or does it?.

For the good news, I am feeling (surprisingly) productive. KDE apps are extremely well integrated with each other. There is a continous flow of information, your data is easily shared. I actually feel good. Call it Productivity Pr0n.

One thing I am missing badly is something like Tomboy, the Gtk#/Mono personal Wiki. I am trying Basket instead, which happens to be tighly integrated into KOffice. Unfortunately I have not managed to get beagle to index basket notes. I actually tried strigi instead of beagle, but it failed to index 50% of my docs because they were not UTF-8 or latin1. Plus strigi had no stemming. Oh, and that it core dumped at 120k docs … Guys, better fix that for KDE4!

The worse side of KDE so far is configuring anything K related - it is an authentic nightmare! I know it’s intentional, but, really, it’s not my metaphore. I would be happier with sane defaults and not seeing all those other 3 zillion configuration options. I love to have them, but hidden. On KDE’s behalf, KDE actually let’s you configure stuff that you just can’t in Gnome (a good thing). The problem is that you need to be the developer to know which combination of options gets you what you want!

Anyway, I am quite happy so far. Some of the KDE apps, kick ass big time. And my calendar events are not silently flying off all around the place.

Oh, and remember:

$ evolution --force-shutdown