eneylon

Archive for the ‘code’ Category

Over the moon

In code, meetings on April 5, 2008 at 5:02 am

I’m at Over the Air at Imperial College London, an event for mobile developers, and writing this after getting just two hours sleep. I don’t usually think of myself as a mobile developer, despite having built a proof of concept for mobile communications for an international charity back in the early noughties and, more recently, having architected a real-time sms based auctioning system for use at a charity event by my previous employer. My collaborator on that project is now entrenched in the mobile development market – so it had real benefits to at least one of us! For both those projects, a services company called kapow were used. I’ve toyed with the idea of buying a GPRS modem such as the Wavecom Fasttrack Extreme but never had the spare cash.

Since then, most major mobile brands have released their own development kits, yet these seem to fall consistently short of my expectations. As a server-side developer, I look for problems that lend themselves to some processing on a more traditional computing environment. Not for me the offers of free hardware to develop for (and there have been a few at this event). But the reality of server side offerings leaves a lot to be desired. BT are stuck in the 90s with their insistence on use of obscure and poorly documented sandpit certificates for developers. Vodafone’s Betavine offering really annoyed when I realised that they want users to register with them as well as developers – double lock-in! It seems that the culture of the mobile company is far behind where mainstream open software solutions have got to (albeit with some notable, but marginal, exceptions – such as Android).

After deciding that developing with any of the SDKs meant either being too locked-in or having no users, I took advice that was offered by an Alan Stokes in the early 90s and went for a walk – to get a new perspective. It worked. After a short stroll (wouldn’t want to miss anything exciting) I returned with a new approach. Taking my frustrations with the available SDKs to heart, I decided to plunge in directly and build my own. Knowing that one of the key services that mobile phones can address is location-based services, I though that a GPS data to postcode service would form a central piece in such an offering. So I set about writing one.

The UK postcode database can be licensed for use in mobile applications, but is not in the realm of the amateur developer, so I looked at using the user-generated content at freethepostcode.org to provide a service to users that would tell them their nearest known postcode and how useful that information is (likelihood of relevance based on distance) given latitude and longitude details. It’s actually an exercise in optimising data structures for querying and was a very enjoyable problem to solve.

However, there’s always a however isn’t there, just as I was about to start testing my code I was visited by a couple of people. The first was a business -head from Nokia who was fishing for developer effort. He was a nice guy, but didn’t get the message that I’m a professional-user developer rather than a consumer-user developer. But we had a good conversation and, if I ever want, I think there might be a future in that mobile market. My second visitor enquired what I was working on and when I explained he asked if i knew of the geocoder activity. Not I, was the response, so we went a-surfin. Sure enough, my first milestone on a comprehensive service stack for mobile development has been truly nailed for some time now. Plans for early retirement have been put on ice.

Driving through my disappointment and not being the radical I hoped (and after being asked by aforementioned dream-breaker if I had seen programmableweb.org as he went to devastate someone else), I continued with the testing and shortly thereafter had my proof-of-concept-that-I-can’t-now-show running like a dream. Satisfaction, but with nothing innovative really (except that the code is available if anyone wants).

With Torchwood (and a made-the-same-day tribute) projected in high definition at midnight to an audience of excited developers it literally was a slumber party for geeks. Back to planet reality later today (in time for Doctor Who I hope) …

Advertisements

Collaborative Review

In code on October 31, 2007 at 8:44 pm

Making documents available for review is an obvious use of the web. But what is the best way to capture feedback on the document in a way that can be processed by the document author(s). One approach is to distribute the content and get users to track changes; but that minimises the benefit to the reviewers of work already done (since comments are not visible to other reviewers as they are created).

Far better would be to use the document’s structure to capture comments in an online system and publish comments as they are received. This approach has the advantage of allowing reviewers to build upon each others expertise and would seem to expose the document creators to a more rigorous review.

Using structured document technologies affords direct benefits of modularity, identification, selection, etc. But these abstract notions are not meaningful to users who do not equate the rigorous structuring of documents with new capabilities. The analogy with writing computer programs should not be lost here. Good system design minimises user work and maximises benefits to users. It really is that simple. 

Now to build that collaborative review system …..

Time Please

In code on September 11, 2007 at 8:38 pm

Java has got its date and time support into a complete mess. For a language that’s only a dozen years old (I remember looking at the aplha release in 1995, so from my perspective it’s about to become a teenager), there wasn’t too much thought given to handling one of the fundamental capabilities of computer systems. I’m not sure what the architectural considerations were employed when constructing this solution, but it is not good. In particular, it is hard to simply access a date: the constructors are abstract because the designers want people to use calendars as the primary way to access the date! Using Calendar as the computation object is anti-intuitive.

Fortunately help is at hand. Joda-Time provides a quality replacement for the Java date and time classes. It’s being used as the basis for the new Java Date and Time API (JSR310 for the code geeks out there) and the hope is that this will make it into Java 7. Whether it is the future implementation or not is moot – it provides fanastic date and time handling capabilities out of the box and it is here, now.