The bigger the phone, the better

I have just had the opportunity to play/work with two of the new Nokia smartphones: the 7710 and the Communicator 9500.

Now, first off, I would like to make it clear that these two phones are targeted to very different markets, but still share many communalities.

The 7710 is a 'cool' phone with stereo headphones, FM radio ( called Visual Radio), and is generally targeted as a general replacement for everything that ails you; the Communicator, is as many of you know, a all-in-one communication device for the business user who needs to email/surf the web and generally stay in touch around the world.

New job

Today is the 3rd day at my new job - and so far, it is a real break from my last gig (can a 2.5 year position be called a gig?) The code base is an order of magnitude cleaner than the last codebase, is driven by hibernate, spring, and struts and was done more or less correctly, with no massivly visible lacunae.

To all future managers of software groups - your team wants to make good code. Your team wants to make good code for a good reason, and it is not an abstract geeky reason, although the two are often correlated. Good code leads to fast development and fast learning.

At my last company, it took me several months to get up to speed with enough of the code base to make additions to the system. At my new company, it took me about 3 hours before I was coding and being productive. That is a lot of money the company saved by giving their coders time to fix broken code. Right now, my old company is desperately trying to train someone to even understand their system... good luck.

AOP and caching

I was recently developing a new AJAX based system for picking a drug from a long list of potentials (this sounds a lot more fun/dodgy/illegal than it really was). Specifically, there are two drop down lists - picking an element from the first select list makes the page look up the entry from the server.

In itself, this is rather unexciting, but i got a chance to code in what is IMHO a rather elegant manner:

I used JSON for the javascript-server client communication, and spring+hibernate for all server side interaction. Now, at this point, we are still talking a decent implementation. The part that I really liked was using AOP for method level caching.

Since the response time of the system needs to be as close to seamless as possible, I needed to make sure that round-trips to the database happened as infrequently as possible. There are, of course, two ways this can be accomplished: the first would be to code a caching mechanism at the service layer, and the second was to use AOP to put it in declaritavly after the rest of the code worked.

I looked around for a few minutes on the spring web site and found a couple of EHCache based method caches, stuck them into my working application, and presto: the time delay that had been due to database look-up was entirely removed. It actually seemed faster than normal javascript.

AOP, when used correctly, is a truly beautiful technology. On a side note, a friend and I did some performance testing of reflection in JDK 1.4 and 1.5. End result: don't worry about it, unless you are in a endless loop. I will post more about that later.