Had a teeny bit of a discussion on another blog last night, and I think I should provide a bit more of a discussion on it here. Basically, the premise of the post was that Ruby is great because it does things in a more natural way than Java, with the case of testing whether a string is empty or not, and the potential ramifications for a NullPointerException in Java.
I posed two suggestions to improve from what was suggested in the post, one of which is the better way, and one of which I deemed to be the ‘Ruby-esque’ way (even though I wrote it in Java). What do I deem this to mean? My impression of reading Ruby code, especially that which is posted by people gleefully backing up Ruby’s awesomeness, is that it can be quite hard to read for new programmers, or those new to a project. In addition, I get the feeling some power functions are simply used because they are fun, which leads to developers feeling lost and unsure of the code they are working on.
When developing code you should always choose readability over convenience. Code will be read many, many more times than it is written…
–Practices of an Agile Developer by Venkat Subramaniam Andy Hunt
My main point is that code should be readable first and foremost. When I develop in Eclipse, I have it set to completely restructure all my code such that it follows good programming practices. I share these automatic code formatters with the rest of the developers I work with. This automatically ensures a consistent and easily readable source base. I also have (as mentioned previously) continuous integration builds that tell me when I have missed documentation, or if I have coded in an unsafe or ‘smelly’ way.
As I said on the blog that derived this post, any code can be bad, and most languages can do most things (they are all turing complete). What makes one language better than another shouldn’t be based on how many operations you can cram into one line of code, but on how easily understood the code is picked up by a junior developer that has just joined your team. At the end of the day, compilers/interpreters are smart – leave them to condense down your code. For that junior developer, you should be concerned only with good variable names, documentation where documentation is necessary, and most importantly, not caring about succinctness.
And don’t we all have a little junior developer in all of us? 
The iPhone has me in its grasp – I find myself immensely wanting one, despite the fact I have never had an Apple product before (so I’m by no means a fan boy). I have for a long time wanted an easy to use portable device with WiFi, such that I can check emails and (optionally) keep in touch with friends on MSN Messenger (my IM of choice). I would barely use it as a phone – it would function simply as a music/video player when I’m travelling, and my gateway to emails/chat with friends and colleagues.
But today Vodafone said no to the iPhone. This means that I could import one from the US and unlock, but that leaves me dubious as to the long-term viability of the iPhone, given the talk of potential ‘bricking’. By my rough calculation, one can be purchased from America for $535 ($399US).
The alternative…..well, what are the alternatives? I have tried PDA’s and find that they cause me no end of grief – my last one refused to remember the WiFi passwords for networks I frequently use. Is there a good tool for the job I outline above? What are peoples thoughts on importing and using iPhones?
Java is a funny language – the ease in which code can be decompiled is astonishing. Eclipse plugins exist to make it a simple double-click on a compiled class file.
I spent a fair proportion of time this weekend adding code obfuscation to one of my projects, and it was relatively easy, despite the complexity of the software. Code obfuscation is normally a matter of working out what files to obfuscate, specifying the library code these files depend on, and setting up an ANT task to run it.
In the case of my project, it is somewhat more complex due to its software architecture: it is entirely composed of plugins, which have weak interdependencies. To handle this I developed a few custom ANT tasks to discover each of the plugins, work out their relationships, and then obfuscate appropriately. This is a relatively nice solution, as with the rest of my ANT script, as it means that plugins can be developed with no interaction necessary to reconfigure the build script.
This is particularly nice when it comes to my continuous build server – I get hourly builds (where data has changed in our code repository), and nightly builds regardless that are now fully obfuscated. In addition, my nightly build runs a whole barrage of tests and report generation tools to always keep us informed.
It takes a fair while to set up such a system, but the value is immense – other people involved with this application can download a build that is no more than a day out of date. This allows for frequent testing, as well as the certainty that we can always build our software.
If anyone has suggestions for other things that a continuous integration server should run, then please let me know.
In response to Daniel Lawson’s blog post regarding TouchGraph, I’d like to draw attention to Centruflow, which is a New Zealand based software framework that does precisely what TouchGraph does, but in my opinion better…
I’ll leave my justification for this for another day. I just wanted to get this blog out there to say to everyone: support New Zealand made!
