The Problems with Tablets

Tablets are a true revolution in computing and are on course to outsell PCs this year. However, they suffer from a couple of major problems:

Ergonomics

The human body wasn't designed to allow people to look at their hands for long periods of time. Which, give or take, is what tablets require their users to do. Sure you can rest them on a stand, but whenever you need to interact with them for a while you'll either get arm fatigue or neck ache.

The Keyboard

Have you ever seen someone trying to type on an tablet whilst standing (such as when commuting on a train)? It's like watching my mum trying to write an email using a single pointy finger.

The problem is the keyboard presented, a standard issue Qwerty, was not designed to be used by one hand.

Inspired by Dvořák's research on letter frequency while also attempting to minimise the distance required to tap on keys (see Fitt's Law) I've designed a single-handed tablet keyboard, the right-handed version is presented below:

Your fingers should rest over the Space, e, t, i and u.

After creating a quick prototype in JavaScript, it's evident that my design suffers from the same problems as Dvořák's keyboard: typing is slowed down massively due to the unfamiliar layout.

Enter version 0.2:

By arranging the keys in a standard qwerty order, the keyboard is instantly usable and initial typing speed is increased.

Due to the colocation of keyboard and screen, it may not easily be possible to solve the ergonomics issue (although Microsoft could be on to something with their Surface). As for the keyboard, if the tablet had a way of realising that it was being held by a single hand, auto-switching to my layout may reduce the frustration of some commuter typists.

Major DB changes? Migrate, Duplicate or Deprecate

So you have a shiny new database technology, or it's time to make a major upgrade, or you just need to refactor. For whatever reason you want to move a large chunk of data into db_new_table. How do you cope with this? On a live system??

I see 3 options: Migrate, Duplicate or Deprecate.

Migrate

Migration is the act of coding up a script to dump any data from your legacy database table(s) into your new one(s) Migration, done properly, will give you the least grief in the long term as there will be no legacy tables to maintain in the future.

It may even present an interesting programming challenge.

This method is loved by developers due to the fun scripting problem and removal of legacy chod. It's also hated by the bean counters because of the  large risk of the migration script coder not knowing about some fringe case or other. What happens if it works on your Beta system but all goes bad when released to the wild? Migration is difficult to back out once you start using the new tables.

Duplicate

Duplication is the act of running the old and new databases side by side. Both are written to, and when you come to read, you check the old one first, then the new one. At some point, when you're happy that you are storing the same data in both places, you stop writing to the old one and you start to read from the new location first.

Duplication is a relatively safe way of introducing a major database change with just one slight concern: that you may never be able to retire the old storage method. This technique works well for "temporary" data (who really cares about a deleted email from 2 years ago?)

And if you are storing "temporary" data, this may lead on to deprecation.

Deprecate

To deprecate is to cleanse. Switching off the old system entirely and rolling with just the new one.

If you have a table that is cleaned out on a daily, weekly or monthly basis (such as one used in fast profit and loss calculations) deprecation is as easy as disabling the old interface and enabling the new one. A single config bit flip.

Most often you'll need a combination of these techniques though, such as before deprecation you may migrate some of yesterday's data into your new profit and loss table to check the numbers still add up correctly. Or you may want to migrate your data and then write to both systems - duplicate - until you have confidence. This will ultimately lead to deprecation.

Whichever method you chose will depend on the risk of it all going wrong, how much time you have to do it, and the nature of the data stored.

Pair Programming with Google Wave Part II

It seems that my "Pair Programming with Google Wave" prophecy has come true.

It was such an obvious idea that it was only a matter of time - even if it wasn't how I imagined the technology to be used.

KISS Vs DRY

In my last post I talked about the expert programmer knowing when not to implement a feature or widget, so as to keep the product and codebase as maintainable as possible.

This idealogy stems from two of the core principles of good software development practice: KISS - Keep it simple, stupid. And DRY - Don't Repeat Yourself.

But it turns out that these two fundamental practices are occasionally locked in a violent and bloody conflict.

DRY often requires you to enhance the complexity of the software, violating KISS.

Consider the case where you could either implement a new module - and with it a new interface - or attempt to re-use an existing module with a fixed interface.

The first option would be the easiest to code as you have free reign over the interface definition, sticking to KISS. But it would violate DRY.

The second option may require quite a bit of work in coding up a wrapper and violating KISS. But it would conform to DRY.

In this example, which method you choose depends on a number of factors and although the second option is normally the correct one, it won't always be.

How to be a Guru

To be a true master - a Guru - in the art of software development you do not need to know what feature must be added.

Recognise instead what should be left out.

Go on, ask.

I think we've all been there, spending a couple of days battling with an SDK to get it to do something slightly different, something slightly leftfield. Something slightly risqué.

We keep battling away, Googling and re-Googling, heading further into the SDK's proverbial dusty corners, not knowing if the classes and methods that we're searching for will even do the job.

And then finally we crack and ask someone for help.

What do we expect to get from asking?

Someone to tell us that we just need to call the Foo::Bar() method?

If we're lucky this is exactly what will happen.

If we're less lucky we'll be told to explore another dusty crevice requiring further Google action.

But most likely, we'll be given some advice that will help us to look at the problem in a different way:
Perhaps we don't need the gui to do that funky trick, and it would actually be far move user friendly if it behaved in another, more standard way.
Perhaps we shouldn't try and make that library function totally generic and rewriting it to solve a specific issue is perfectly acceptable.

Whatever happens, we shouldn't see asking for help as a weakness, but rather as an opportunity to better ourselves by learning from our peers.

Startup Incubator is Looking for you

Red Gate Software are prepared to help out start-ups by offering good people a desk, money, accommodation and even free food.

All they want in return after the initial 10-week development period is a chunk of equity.

But the point is they're prepared to take a gamble and invest in good developers, giving them everything they need to make great software - but with no risk.