Tomas Varsavsky

Steve Yegge (one of my favourite bloggers) recently posted about the maintenance problems exhibited by a large Java code base. I agree that software bloat is one of the biggest problems in our industry right now.

His proposed solution is to re-implement the 500,000 lines of Java code into 150,000 lines of a more concise language such as Ruby or JavaScript (ES4). This approach seems misguided to me because software complexity is not directly proportional to number of lines of code. The fact that 5 lines of Java can sometimes be compressed into 1 line of Ruby does not make the logic less complex or easier to maintain if they are essentially doing the same thing. In fact, I would argue that often 1 line of clever Ruby is actually less maintainable that 5 lines of Java because it requires a deeper understanding of what’s going on underneath the covers.

A good case study is Perl where developers seem to be a mind set of “how clever can I be” and write one liners that become indecipherable even by the author within days. You might be able to get away with this if you’re a gun developer working on your own but not if you’re working in an average team of average developers. I think Ruby has actually struck a nice balance between readability and conciseness and this is one of the reasons why its popularity has surged. Still, the thought of a 150,000 line Ruby code base scares me and would keep me up at night if it was left in the hands of average developers.

A code base with 1000 Java classes is just a complex as a code base with 1000 equivalent Ruby classes even if the number of lines per class is less. Reducing complexity and therefore increasing maintainability is all about applying good software engineering principles and frequent doses of my favourite refactoring — Delete.

In my current project we have some deployment scripts written in Ant. We can deploy a new version of the application as built by CruiseControl by running the command “ant deploy-war -Dwarfile=http://cruise-box/artifacts/killer_app/BUILD_TIMESTAMP/killer_app.war“.

Most of the time we want to deploy the latest successful build. We manually get the timestamp of the build from the CruiseControl dashboard and substitute it into the command above. It would be nice to default the warfile property to the latest successful build. For that we need CruiseControl to give us a well known link to the latest successful build.

I solved this problem using symbolic links. We can do this because our CruiseControl server runs on Linux but we could have achieved a similar result with a file system copy or an artifact publisher under Windows. I created the following helper Ant script to create a symbolic link using the Symlink task.

I then added a call to the helper script in the CruiseControl config.xml as an Ant publisher executed after a successful build.

I had to do it in an Ant script rather than calling the ln command directly with an execute publisher because I couldn’t work out how to access the build timestamp from within CruiseControl’s config.xml.

We can now access the latest successful build through the URL http://cruise-box/artifacts/killer_app/latest-successful/killer_app.war. The last step is to default the warfile property in our deployment scripts to this URL. We can now run “ant deploy-war” to deploy the latest successful build, or provide the property as before to deploy a different build.

LOLCODE - Finally, a Domain Specific Language for the masses! Here’s a couple of examples taken from the website:

There’s nothing like a joke that takes 15 years of education and work experience to appreciate.

I spent this week doing a proof of concept time-boxed to one week for a client that wants a new corporate intranet. The first step was to choose a technology stack.

I have experience with some heavy weight commercial Content Management and Portal products that play in this space but all of these are expensive and probably an overkill for a intranet. The majority of the client’s requirements are to do with basic web content management so I went on the prowl for Java open source solutions to the problem. I spent around three to four hours installing and playing around with some open source products that have enterprise level support available through backing companies.

OpenCms 7 — OpenCms is a web content management system and nothing more. It was trivially simple to install and get going with MySql. It gives you a tree view of your web projects and you can go about managing content in the same way that you would in a file system. You do your work in an “offline project” and publish changes in batch when ready. I found changing the look and feel and layout non intuitive at first but it was ok once I worked out that my site was based on the “templateone” module and most of the styling and layout could be driven from properties in the document tree. OpenCms supports XML content that you can define and author through an automatically generated web form and then access from JSPs. The bundled documentation is good and finding help online is easy.

Alfresco Community 2.1 + Web Content Management extension — Alfresco is a lot more than web content management system. At it’s core it is a document management and collaboration tool that is trying to compete with products like Microsoft Sharepoint. It has team spaces where users can author, manage, version control and share documents as well as participate in discussion forums. Users can access the content repository through a sleek looking web interface or directly from Windows using various plugins. Content can also be accessed through a web service API. The Web Content Management extension adds the ability to create web projects and publish web content. A really cool feature is the ability to deploy dynamic web projects (i.e. WAR files) that are developed outside of Alfresco. I tried this out by creating a simple web application using Sitemesh to control the layout. As a Java developer I found this much more in tune to my way of developing software. In terms of support there’s a website, a wiki and forums but I found it very hard to get useful information. Even something basic like installation instructions are incomplete and all over the place. Alfresco is more feature rich than OpenCms and with that comes extra complexity which led to frustrating attempts at implementing more complex things like XML based web content. Overall I was quite impressed with Alfresco and can see the potential to do some really cool stuff in it. Unfortunately, due to the learning curve, lacklustre documentation and short amount of disposable time I abandoned Alfresco as an option. I will re-visit it when I have more time.

Liferay 4.3 — Liferay is an open source Portal product. I have a healthy dose of skepticism towards Portal products brought about by a few bad project experiences. Liferay was easy to install and get going, it comes bundled with Tomcat and runs on HSQLDB by default. Liferay comes with a lot of collaboration Portlets like wikis, forums, news, document sharing and calendars out of the box although I get the feeling that they are all quite basic. For example, the wiki Portlet is very simple and lacks a lot of the features that one would expect in a fully fledged wiki product like Confluence. A core feature of any Portal product is the ability for each user to create their own mash-up of Portlets and Liferay supports that well. I found the administration Portlets to be slow and hard to navigate around. Overall I was impressed with the breadth of Liferay but not so much with the depth. I abandoned it as an option, mostly because it’s feature rich in all the wrong places and a general belief that Portals are evil.

In the end I chose OpenCms as “the simplest thing that works” and spent 2.5 days spiking an Intranet on it. In that time I was able build:

• A branded intranet
• News page
• Job board
• General web content pages
• Document attachments
• A tree view of documents
• Integration to a Java based forum through an iframe
• Some rich ajaxy pages using Ext JS

A work colleague of mine and I constantly banter about his refusal to embrace Facebook. He cites the ridiculousness of it as his primary reason. I’m starting to see his point.