It's been a few months since I made a post about toilet paper. I hadn't run out or anything, but I just had to buy it. I think whoever named the brands really missed out on an opportunity here, possibly naming the single ply rolls "Ambivalent end", and the four-ply rolls "Deliriously happy end". I'm not obsessed.

No talk about PhDs today. I'm currently waiting to head out to a "British night" out at Karlstorbahnhof. I'm settling on a theory that the Brits know how to make not only a variety of types of music, but also do it really well. I'm looking forward to it. I've been put in the mood to go there after watching the fourth episode of the IT Crowd, a new series from Channel 4 and one creator of Father Ted, Graham Linehan. This fourth episode was particularly good for the presence of Noel Fielding. I won't spoil it, but his character is absolutely hilarious - sending up yet another musical subculture. I'm hoping that it continues to improve, as it might well end up being a favourite series of mine, simply for the mix of ludicrous British humour, and the pure geekyness of it all. Heck, I even spotted a FSM in the background of this last episode. Thanks to the magic of the internet, I'm able to watch the series, although it would be nice to see it in HD, and not some blurry WMA format.

Update - 12/02/06: The next day...

It turns out the British night wasn't really very much of a British night, but it was still a good night out. Beyond recovering from the night out, I've been spending my time today writing stuff in Ruby (and writing longwinded blog posts). I've made a post in the past about Ruby, so I won't go in to many details, but it suffices to say that I'm impressed by the ease of programming in the language.

The reason I bring up the ease of programming is that I'm currently tearing my increasingly long hair out at Java. I've got a nagging feeling that Java is probably not suited to this project. The main reasons we chose Java was that it's cross-platform, object oriented (although most languages have OO aspects to them), and has some nice libraries available. The big problem is, none of us are Java gurus. On top of that, we're trying to write a web-app that mixes up lots of XML, database connectivity, and some scientific applications. The general approach to get it working is to use as many libraries and frameworks as possible to take the drudgery out of doing standard application work. For someone who has been out of the Java stable for a few years, it's quite a task looking at the various application frameworks and stacks out there. Do we go with a J2EE stack? Out of that, which implementations do we choose? Can we mix and match components from different frameworks? Then, once you actually make a choice about which bits of frameworks you want to use, you then spend a few weeks deciphering the APIs trying to figure out how to do what you want to do. I'll give you an example of how this works in practice. See if you can keep up with all the acronyms and buzzwords here, it's a bit ridiculous.

I'm trying to write a SOAP wrapper around some existing applications written in PHP. I've given up trying to upgrade the PHP to have SOAP capabilities (Biochemists don't usually make the best programmers), so since we needed to get some SOAP functionality anyway for EUROCarbDB, I decided to have a go at it using Java. I then proceeded to spend two weeks evaluating Java SOAP frameworks, basically comparing the J2EE JAX-RPC and XFire. I ended up going for XFire for the simple reason that it was a lot easier to set up a simple SOAP server using it. The whole J2EE framework had far too great an overhead for me to even try it out, requiring me to learn a whole bunch of extraneous rubbish which will be promptly forgotten once the SOAP component is finished. Now, I'm certain that the J2EE frameworks are very powerful and all that, but they make it really hard to do anything without having a 4 week certification course, or using one of their IDEs to do all the development (Eclipse is a beast of an IDE. It turns my poor powerbook into a stuttering mess as it eats up all the RAM). In the end though, what I'm doing is not that complicated, and that's why I like the XFire approach. Copy the dependency jar files in to your servlet directory, add one (!) configuration file, set up the servlet, and then start writing your classes which provide the SOAP interface. Braindead simple (well, except for when I couldn't figure out where the configuration file really was meant to live). It generates all the WSDL and performs all the magic necessary to make it work. No external commands needing to be run to create the WSDL or other esoteric pieces of knowledge needed - it just works.

Now that I've got something vaguely approximating a SOAP server running, I have to write a database querying component, which will take in a SOAP request, and then somehow figure out how to query the database using it. The querying is bread and butter stuff for database backed applications. I should just be able to take an existing library, and have something set up in five minutes right? Not quite. I decided to use an ORM layer to avoid me having to write all the object population methods, and settled on looking at a JDO implementation and Hibernate. Maybe there are more ORM layers out there, I don't honestly know, because the documentation out there for them is indigestible. I'm currently going with Hibernate as an ORM. Not because it matches my requirements in terms of functionality, but because it's the only framework where I've found a way to reverse engineer java code from the database. Should things really be so hard?

This is where the issue of language strictness comes in. In a language with less strong typing, you could achieve all of this quite easily. Java seems to tie your hands up quite a bit, and not really allow you to get on with the business of writing your application. It doesn't really help that I don't have 5 years experience writing commercial Java applications. For a language like Perl, I'm a lot more familiar with how to do stuff - in the end, the learning curve for doing Java programming at a comparable level of complexity to that of a perl application is quite steep for me.

When you're working on a project whose requirements are not clearly defined, users not consulted, and scope ever expanding, it seems like Java is not the best language to do the work in. Instead, we should be basically rapidly prototyping the application - and not going for a perfect codebase on the first go. Of course, the decision has been agreed upon for the language to be used, and there's little bits of code being written right now. Is it bad form to accept that a bad decision was made about code language? I'll be the first to admit that my lack of experience in running large scale programming projects (let alone ones based in academia) probably hindered me when I was thinking about which language to use. Should we subscribe to parts of the Agile philosophy? Or do we stick with the current way in a language that is going to make us pay for it?