Device Fragmentation and Java

The topic at December’s London Mobile Monday meeting was “Device Fragmentation and Java”. I think it’s another phrase for “diversity”, with a few “challenges”:

1. Different user interfaces: different screen sizes, for example.
2. Different capabilities: some devices have Bluetooth support some don’t; some devices will play some media formats, but not others; differences in performance characteristics…
3. JCP specification that aren’t tight enough, leading to different interpretations of the APIs.
4. Configuration issues: handsets not configured for data access, or the operators messing with data as it goes through the network, or different behaviours depending on the tariff the customer is on (apparently).
5. Bugs.

The first couple of issues aren’t going to go away, and applications are always going to have to adapt to the capabilities and the format of the device. Is that such a bad thing? A big screen and a keyboard lends itself to a different UI to a smaller touch screen. From the business perspective, though, the question is: at what point is all the testing going to kill you?

d.Construct 2005

The “UK’s first grassroots Web 2.0 conference” took place last week, right on my door step. It was held in a converted church, so insert your own congregation/peaching puns here.

As Andy Budd pointed out in the opening presentation, you can’t have a Web 2.0 conference without a discussion of what Web 2.0 is. Andy’s pitch was that, yes, it’s a buzz word, but words are useful to have to communicate a bag of related ideas. Although none of the technology is new, having a Web 2.0 state of mind means thinking in terms of richer more pleasurable user experiences, open formats, community involvement, and not being scared of JavaScript. Regarding the technology, he made a compelling analogy to steam engines: invented in 1st century, but not put to serious use until the industrial revolution of the 18th.

SiteMesh

Most of the templating I’ve done for the web has been with Tiles but lately I’ve used SiteMesh. I’m drawn to the simplicity: using it, at least the way I’ve been using it, means removing elements from pages you write rather than having to add anything special in. I’ll explain…

When I’ve used Tiles I add bits of magic to any page to make sure the right template shows up. It works, it’s powerful. The SiteMesh approach is to provide a decorator for plain pages. This makes it framework agnostic, simply taking whatever output it gets and decorating on whatever presentation mark up you want. It’s liberating writing very simple pages, and not having to sprinkle tags all over the place.

OpenAMF

I’ve been fortunate to be involved in a project that makes use of OpenAMF. Although I didn’t spend a lot of time with the technology, it is an interesting proposition.

AMF is the binary wire protocol for RPC calls between a Flash player and a server. OpenAMF is a Java-based open source implementation, providing an alternative to Macromedia’s Flash Remoting MX (and also therefore providing a saving of something like £750 per CPU).

Messaging at the BBC

The BBC were at etech this year describing some of the funky mobile things they’re getting up to. The ten hour takeover, for example.

The approach we’re taking with our messaging services looks to be very similar to the approach the BBC are using. This is a nice reassurance given that the BBC team have to deal with breakfast radio stars who get their audience to text in 14,000 message at once.

You can get the audio on-line, but you’ll also want the presentation (7M PDF) to look at. It’s great work, and well presented.

To code or not to code

Open source is well on the way to overturning any lingering not-invented-here attitudes for software components.

In the past it was always easier to write it yourself: it’d do what you want; you’d know it’d work. Compare that with talking to a vendor, having someone from sales visit, doing an evaluation, getting the funding approved… in many cases it’s not worth the hassle.

If you need some software function today, you can google around, figure out which projects have some momentum, check the licensing and try it. That’s great, but the more interesting thing is how open source projects can embody the best practices, or at least a very reliable implementation. In those cases you need a good reason not to be using an open source implementation by default. (Such reasons do exist.)

JavaOne 2005

JavaOne was useful, as usual. Here’s the list of things I found interesting or need to look into further:

The mobility general session was packed full of information. The main news was progress on MSA (Mobile Service Architecture, JSR-248 and JSR-249) initiative. This strand of work irons out some of the weirdness between consumer and enterprise Java ME stacks, will support more capable handsets and will reduce variability. For example, the MSA group will tighten up some of the specifications and will reduce the number of options handsets manufacturers can leave out.

Cobertura

Code coverage: running unit tests in such a way as to be able to tell how much of your source code is being exercised by those tests.

It’s a very useful thing to do and there are quite a few tools out there to help. Some time back Goul introduced me to what I think of as the market leader: Clover from Cenqua. There are now lots of open source alternatives, so I thought I’d try the best one out to see how well it works.

Common Development and Distribution License

This blog is about software licensing based on my personal reading of license agreements and should not be taken as advice of any kind. If you intend to act or not act based on the contents of this blog you do so at your own risk.

The OSI have approved Sun’s Common Development and Distribution License (CDDL) so I thought I’d take a look and see what all the fuss is about.

When I license software I’ve usually gone for the GPL, occasionally the LGPL, or a custom commercial license (which brings joy to our solicitors).

Sleepycat: Berkeley DB Java Edition

I recently had a look at Sleepycat Software’s Berkeley DB Java Edition. What’s on offer is a transactional data store that can be embedded inside an application, including inside web applications. Compared to other embedded products, this one has been around forever, so it should be bullet proof.

I think of the Berkeley DB as more-or-less a persistent hash table. One object is a key, another is the content, and the rest is all put and get against a transaction ("extends TupleBinding" is the magic needed on a class). It’s fast, it’s reliable and it’s simple to use. The lack of external dependencies (no server to worry about) means it’s a doddle to write unit tests for. There is a little bit of serialization/deserialization code to write, but even that’s pretty easy.

Amazon Simple Queue Service

Some months back I received email from Amazon announcing the beta launch of their queue service. I’ve just checked, and it’s still in beta.

The idea is that you can create a queue on Amazon servers and then place messages in the queue and consume messages from the queue. Messaging has been around for quite a while, so what’s interesting here? Well, what we have is a company that has invested in an impressive (I assume!) network and hardware infrastructure for the sale of books, and on the back of this they are offering a software service – and now I get to piggy back on the level of service offered by their investment.

Change reporting

How to communicate code changes? I could send email, I could maybe read some of the reports from CruiseControl, or I could look at Fisheye (or an open source alternative, such as CvsChangeLogBuilder).

FishEye is nice, but I don’t find the need for most of what it can do. What I do use is a text and RSS feed of CVS commit messages. Sure, FishEye does that, but as that’s all I want I’ll save my US$999 and use a Perl script called cvs2cl that does the job.