Numeric keypads; what is the point?

As I hinted the other day, I've recently had some stress/RSI symptoms in my arm. Nothing too serious, just definitely worth fixing ASAP. I'm by no means crippled with RSI or anything, but I am on a mini-crusade for programmer-health, and want to help others avoid unnecessary stress / irritation.

I had a very productive session with a physiotherapist today, who made some really constructive and pragmatic points (for example, demonstrating quite simply and clearly that the curve on my corner-desk points the wrong way, and simply swapping to a mirrored desk could help hugely).

But one startling point she made while observing me; as a programmer, I move frequently between the keyboard (in my case a decent ergonomic split jobbie) and the mouse (now a shiny new "vertical" model) - code a few lines, use the mouse to click a few buttons, test a few things via the UI - rinse, repeat.

Sure, I use the keyboard shortcuts, but I would struggle to remember the hundreds of magic key-presses and "chords" that drive Visual Studio.

Very rarely do I use the numeric keypad. Heck, I also use a laptop, and the only time I find myself looking for Num Lock is when my password inexplicably doesn't work. Yet every time I move between keys and mouse I have to travel this pointless distance.

Lets not do that

Numeric keypads; absolutely useless. Underused, oversized, badly placed, and they don't agree with 'phones on which way the numbers should go.

She gave me a tip to simply try a keyboard without one, letting me have the mouse much closer. You can pick up a "Goldtouch" ergonomic keyboard (sans keypad) for about GBP25 at Amazon. This is so simple and so obvious that I'm just stunned that people insist on still including it, even on "ergonomic" keyboards. If it is so ergonomic, why is it causing unnecessary travel?!?!

If you want a keypad (and I do find them handy occasionally), then buy a USB keypad (like they sell for laptops) - roughly GBP10, and that is for the models that double as a handy USB hub. If you're right-handed, stick it on the left, or on the far side of the mouse - whichever you prefer and find most comfortable. Plus you can move it to either side if a "sinister" shows up at your desk.

Join the revolt! I invite you to ditch (or move) your keypad today!

protobuf-net vs NetDataContractSerializer

In a user-group meeting yesterday, I was talking briefly (in a “grok” session) about “protocol buffers” (protobuf-net in particular), and I was asked a question about the comparison to NetDataContractSerializer. I didn’t have the answer to hand (I only had numbers vs DataContractSerializer), so promised to find out…

First; note that the key difference between DataContractSerializer and NetDataContractSerializer is (as I understand it) that NetDataContractSerializer includes more type metadata. This makes it possible to do a few things involving “object” and unanticipated subclasses (which can be useful), but renders it .NET-specific (and less version-tolerant).

The test

As per my existing test rig, I test 1000 iterations of a moderately large extract from the Northwind sample database (into some pretty-standard POCO types); I simply extended this rig to incude NetDataContractSerializer. For completeness, I have 3 variants of the tests, tested separately each against a different set of serializers:

1. LINQ-to-SQL generated classes with serialization enabled at the data-context; suitable for protobuf-net, DataContractSerializer and DataContractJsonSerializer
2. as the first test, but with the LINQ-to-SQL bits hacked out and [Serializable] added (to make it suitable for the core binary .NET serializers); suitable for protobuf-net, NetDataContractSerializer, DataContractSerializer, DataContractJsonSerializer, BinaryFormatter and XmlSerializer
3. as second test, but with ISerializable and IXmlSerializable implemented to support BinaryFormatter and XmlSerializer via protobuf-net

The numbers and analysis

Since only the second test supports NetDataContractSerializer, that is the one I’ll focus on (with results from the 3rd test included for interest only, marked *); here’s the numbers:

Serializer	Size (bytes)	Serialize (ms)	Deserialize (ms)
protobuf-net	133,010	10,769	23,511
NetDataContract Serializer	992,203	29,343	91,453
DataContract Serializer	772,406	16,272	66,755
DataContractJson Serializer	490,425	29,604	135,125
BinaryFormatter	276,366	67,151	56,253
XmlSerializer	1,043,137	29,257	38,528
BinaryFormatter*	133,167	12,095	24,653
XmlSerializer*	177,410	12,189	31,827

Some interesting points; firstly, for my sample data it is a myth that WCF’s binary type-centric serializer (NetDataContractSerializer) is going to improve things over xml (DataContractSerializer). Both in terms of bandwidth and processing time it is worse on every front. The biggest advantage of NetDataContractSerializer (in this case) is that the type model is more flexible in terms of interfaces, “object” and unknown subclasses; but this also makes it entirely non-interoperable. Of course, some details of the SOAP envelope used by the binary type-centric WCF transport may be more efficient – but I’m looking at payload for these tests.

Secondly (and fortunately for me) it yet again proves that google know how to do data transport; with protobuf-net being the clear winner for both bandwidth and processing time.

But for me, another point that I’d like to highlight is versatility and compatibility; the same classes can be used happily by a wide range of serializers (above), and presumably a few others too. For the record, the entities in the above test don’t even have any protobuf-net-specific attributes (the outer-most wrapper does have them, but only because at some point in the distant past I wanted a way to compare/contrast some protocol-buffers-specific details, which can only be controlled via the custom attributes).

Other thoughts

As with all performance tests, your specific environment and data may be an important factor. But based on the above numbers it may be reasonable to assume that protobuf-net stands a good chance of holding its corner.

Finally; following some unrelated conversations at the same user-group (they kept me pretty busy), I stress that tight serialization is only part of the story:

• It can help reduce bandwidth costs and CPU costs associated with (de)serialization, but it won’t help if latency is your issue; protobuf-net makes no claim to change the speed of light.
• While protocol buffers may be supported on a range of platforms, it is by no means ubiquitous; if your biggest demand is portability, perhaps use SOAP/WSDL (or offer both SOAP and protobuf-net on separate endpoints).
• By itself it won’t solve all your disconnected woes; although it can presumably be used in tandem with any message-queue based solution you might dream of.

The Most Important Programming Book

A holy war, you might think, for any of author / architecture / language. But for full-time professional geeks, how about a book that is much more important than any of these mere implementation details:

You might be thinking “huh?”, but as IT professionals (and programmers in particular), we are hugely exposed to RSI in our professional life. Don’t underestimate the risks; we do this job to pay the mortgage/rent, after all.

I switched to an ergonomic keyboard years ago (one of the Microsoft models with the split key groups), after a warning shot – but the importance of things like correct posture / equipment is huge. But my point here: don’t wait to be a sufferer: take preventative steps now to avoid problems (and pain) later. Even those fancy vertical / air mice are a snip compared to just a few days off work.

Stickers – now what to do with them?

For any stackoverflow users, the stickers are real – Jeff was kind enough to send mine directly, rather than wait for DevDays. I knew that ♦ would be useful!

Compulsory wooden-table shot:

They’re a little smaller than I expected, being only slightly longer than my mobile ‘phone. Now… if only I can think of what to do with them… so far, I’m wondering if they might make serviceable plasters (band-aid if that doesn’t translate). Or (edit) maybe a laptop-chassis emergency repair kit? (my last laptop survived 2 large cracks for a considerable time). Or I might drag them along to a user-group and see if there are any takers.

All other suggestions welcome…