Symphonious

XML databases and the standards to work with them (primarily XUpdate and XQuery) are just plain crap.  Why is it that I need to learn two completely different languages which utilize two completely different programming styles to work with a database?  Why is it that I can’t seem to convert between a String and XML nodes in either of those languages?  I mean, wouldn’t seem obvious that when working with an XML database someone might have some XML coming in as a parameter and want to deal with it as XML instead of as a String - say to put it into the database?  Isn’t it obvious that someone might want to get a part of the XML file they’re processing using XSLT as a string instead of a node-set?  I don’t mean get the text nodes within the XML fragment, I mean all the element declarations and namespaces etc, etc.  Sure they’re more than just random text but if you wanted to output it so it could be edited it would be nice to be able to without jumping through hoops.

And don’t even get me started on Cocoon serializers….  I know I don’t fully understand the technology I’m working with here and maybe I’m missing something obvious but the documentation definitely doesn’t help make it clear.  eXist has the barest of documentation (Xindice failed to compile) and Cocoon has wonderfully comprehensive documentation which provides all the building blocks of information you could ever want with practically no hints on how to put it together effectively.

There’s some really awesome technology in all this stuff but it absolutely drives you nuts trying to work out how to use it.  Someone really should take Cocoon and build a GUI-based building blocks tool out of it.  Most of the required components are already there (though database access seems to need some work), just put a clean, effective UI on it and you’ve got a wonder product.  Make sure you sort out the nightmare of configuring URL prefixes between Cocoon, Tomcat, Exist and whatever else winds up in the stack.  Just make it work without the swearing and cursing.

It would be really nice to be able to subscribe to an RSS feed for a limited time.  There’s two reasons for this. Firstly so that you can subscribe to the comments RSS feed for a particular article you won’t to track the discussion for but then have it drop out of your feeds once the conversation dies down (this might be best implemented as auto-unsubscribe after x days of inactivity).

Secondly, so that you can try out a new blogger and see how they go for a week or two.  If they have some interesting stuff to say you choose to keep them around and if it’s boring you drop them from your RSS feeds.  This is probably a confirm subscription in x days kind of option.  It should be done in a passive way though so when there are feeds up for review a button lights up in the UI that I can click when I have time to review the list and decide which to toss and which to keep.  That way when I come across an article in a blog I don’t normally read I could put it on a trial subscription to see if there are any interesting follow-ups or if it was just a once off stroke of genius.  While I could do that now I quickly lose track of what I’m actually subscribed to and don’t have time to think about whether to unsubscribe from a feed while I’m flicking through the morning deluge of entries.

Oh and while I’m thinking of features - how about a strip duplicates feature?  There’s a few blogs that I get multiple times because they are syndicated into different places.  It would be nice if my RSS reader did an MD5 on the body of each entry and hid onces that were duplicates somehow.

A couple of people commented on my beautful code entry saying that the IDE should take care of code formatting and indentation and that ‘beautiful code’ is mostly about design.  I’d have to disagree, beauty is only skin deep.  The design of code doesn’t make it beautiful, it makes it maintainable - it makes it work.

You’ll have to excuse the inherent sexism in the following analogy - it happens to be the best one I can think of.

Assume you’re a guy looking for a wife.  You develop a set of requirements for your wife.  She has to be able to cook, clean and sew for instance.  You could go out and find an ugly wife who can cook, clean and sew and live happily with all your requirements met.  However, more (stereotypically) likely, you’ll go out looking for a beautiful wife who can cook, clean and sew.  Why?  The appearance of your wife doesn’t affect how well your dinner is cooked, how clean your house is or how many holes there are in your socks.  In fact, a beautiful wife comes with some drawbacks because she wastes hours each morning putting on makeup and cleansers and what-not.  Why on earth then would you want a beautiful wife?  The pay-off comes when someone else looks at your wife - they recognise how beautiful your wife is and assume there’s something fantastic about you that would make such a beautiful wife want you.

On the other hand, you’d be a fool to go out and get a beautiful wife if she couldn’t cook to save herself.  The underlying design is important, it’s more important than beauty, but that doesn’t mean you should just ignore beauty all together.

Code beauty is more than just indenting too.  The most important part of beautiful code is the comments.  Every method should have a good comment on it and every class variable.  It doesn’t matter how clean the design of the code is - most of the time you’re not looking at it, you’re off in some other method wanting to know what some method call does.  With good comments you hover your mouse over the method call and the IDE helpfully tells you what the method does.  Without good comments the IDE helpfully tells you the method signiture and then you have to interrupt your thought pattern and go and look at the code to this other method to find out about it then any methods it calls and finally you come back to where you were and try to remember what you were working on.

It’s okay to leave the formatting of code to your IDE (I use Jalopy a lot for code formatting) but that only gets you average looking code - not beautiful code.  Beautiful code takes effort and that effort is rewarded by higher productivity, greater sense of pride in your work, greater respect from others who read the code and most importantly it develops a culture of writing great code which is both beautiful and functional.

Just like most guys are more inclined to hold the door open for a beautiful girl, people tend to take shortcuts if the code looks messy already but people take more care to do things right when the code is beautiful.

And for female readers who don’t appreciate the analogy, try replacing beautiful wife with hansome husband and cooking, cleaning and sewing with mowing, handiwork and car repairs.

According to Google, I’m now the Object.equals() guy (for those who read via RSS only, I notice this because of the Google search that displays on the front page).

Any half-decent coder will agree that writing readable code is important and that good comments are a part of that.  More and more I’m getting the impression that that’s not enough.

Code should be a thing of beauty.  Not necessarily "oh that’s a beautiful algorithm" and definitely not "oh wow that’s clever" but beautifully laid out with every blank line considered for meaning and well thought out comments everywhere.  Every construct and every line should match the selected coding style and real thought should be put into why that particular coding style was selected.

All that sounds like a waste of time and productivity - you don’t need to go that far for the code to be maintainable and in fact I suspect that in the simple case writing beautiful code does cost productivity even in the long run.  The reason I think you should do it anyway is the classic slippery slope argument.  If you let the odd thing slip because they don’t really matter then you are more and more tempted to let something else slip.  You don’t feel bad if that method isn’t commented because there are already a couple of other methods in that file without comments.  You don’t care if that line you just wrote isn’t as clear as possible because the rest of the method is a little complex anyway.

More importantly though, you lose the ability for tools like Checkstyle to really benefit you.  If you have thousands of checkstyle errors and warnings throughout the codebase it’s difficult to notice that the code you just added creates a new one.  If the codebase is nice and clean though, being the person who creates the only checkstyle error isn’t much fun so you tend to avoid doing it.  Classic broken window stuff - as soon as one window is broken the rest of the windows rapidly get broken.

The other big advantage of writing beautiful code is that it demonstrates good coding practices to anyone who reads that code and anyone who reads beautiful code immediately has a high level of respect for the programmer and for the codebase.  They’re more likely to take time to understand problems and contribute fixes if they respect the codebase rather than seeing a mass of uncommented code, swearing at the programmers and going off to find a better written tool.

The best advice I can give then is to install the checkstyle plugin for whatever IDE you use (or something equivalent), tweak the configuration to suit your tastes (but don’t disable rules without carefully justifying why that rule provides no benefit) and then make sure that as you code you avoid even the smallest of warnings.  Your code will thank you for it and those who read your code will be worshipping at your feet in no time.