Recently, the subject of build tools and systems has come up again at Ephox and it appears the topic is rising up again around the internet. As part of this I’ve been reading up on and playing with a bunch of build tools to get a feel for their benefits and limitations, so it seemed worthwhile writing up what I find as I go along.

The Projects

Which build tool suits best clearly depends on the type of project you’re working with. I’m currently playing with three quite different projects:

If you’ve tried to set up Alfresco 3.2 and use the WCM component, you’ve probably run into one or more1{#footlink1:1260264856408.footnote} of these problems:

1. When you click “Preview Website” you get an unable to connect message.

   • You need to start the virtualization server that provides the previews or configure it’s IP correctly.

2. When you click “Preview Website” you get a blank page and the browser is “connecting” forever.

   • You did the right thing and entered a root password other than ‘admin’ in the installer and now you’re being punished for it. Go and update the virtualization server configuration and give it the admin password you entered.

3. When you click “Preview Website” you get a response immediately that just reports “Virtual website not found”.

Andrew Shebanow in Open Government and PDF:

The issue at hand is not whether governments should pick HTML or PDF. The issue at hand is whether governments are capable of publishing information at all. Show me an HTML creation tool that creates high quality, standards conformant markup from a Word document or any of the zillions of editing tools that government employees use. Now add in all the tools used by people who submit documents to the government. And all the versions of those tools released in the last 20 years. Now make sure that the HTML/XML works correctly even when the user doesn’t have the right browser or the right fonts installed. I’ve actually worked with a number of government departments who were looking to move more content online and the content conversion problem is definitely a time consuming and challenging part of the problem. That’s precisely why I wind up getting involved, since EditLive! lets you easily copy and paste content from Word documents and produce clean, compliant XHTML. It can even (optionally) strip out inline formatting and leave just the structure like headings, tables and lists.

I swear, some days you just want to reach into the screen and strangle the blogger on the other end. Jeff Atwood complains that his users commonly fail to read all the helpful hints on how to use their overly complicated, what you see isn’t what you get editor on Stack Overflow:

The ask question page is already dangerously close to cluttered with helpful tips, but apparently these helpful buttons, links, and text are all but invisible to a large segment of the user population. Sure, you could argue that Super User tends to attract less sophisticated users, but I see the exact same problem with programmers on Stack Overflow. As new users, a significant percentage of them can’t figure out how to format code, even though there’s not only a toolbar button that does it for you, but help text on the right explicitly describing how to do it manually. (Just indent 4 spaces. Spoiler alert!) So essentially, users don’t find the editor intuitive and the solution they’ve gone with up until now is to add more and more help text to try and teach the user how to use the unintuitive editor. It’s not working. The obvious solution is to escalate the arms race:

Having become quite interested in languages that support deployment on both Java and .NET, then diving into Scala to find it’s a good language, the obvious next step is to try using Scala on .NET. I found a little time over the weekend to try that out with good success. Notably, I haven’t tried this in a real project yet so there may yet be some significant catches, but so far it looks really quite promising.

When I was in Australia visiting Ephox’s awesome engineering team recently, it was suggested that we should be seriously looking at using Scala for some or all of the server side development we have coming up. The key benefit that was described to me was based on productivity – I certainly think that has merit but I’m somewhat more interested in it being a potential solution to the new cross platform problem1{#footlink1:1255615173985.footnote}. Options like JRuby and Jython are also a possibility in this space, but Scala fits more nicely into a Java programmers mind-set and is designed with the JVM in mind, so while it pushes a lot of boundaries, ultimately it fits with the JVM and Java very nicely2{#footlink2:1255615348893.footnote}.

I’ve spent the last couple of weeks in Australia for my baby sister’s wedding and while I was there I worked out of Ephox’s Brisbane office where our engineering team is based. It’s been nearly 18 months since I left there to move over to the UK and this is the first trip back since. What was most striking about the trip is just how awesome the team is down there. Technically speaking they are one of the most talented groups of engineers you’re ever likely to come across and pull off some seriously amazing stuff, but more importantly they are a truly great team.

When I first started professional programming, Java was reasonably young and was being hailed as a work of genius with it’s cross platform deployment capabilities. Programming was going to be revolutionised forever and all programs would run on any OS1{#footlink1:1253859827521.footnote}. Then Java wound up being most popular on the server side and liberated server code from the choice of OS more than the desktop side2{#footlink2:1253860194622.footnote}.

Server OS’s started to compete mostly on how well they were a server rather than what programs ran on them because what really mattered was that you could run the Java stack. In other words, Java became the platform that people deployed their applications to. It shouldn’t come as a surprise that a single platform didn’t stand unchallenged for long. .NET sprang up as the big enterprise competitor to Java and all of a sudden you had to choose sides again.

The relentless addition of cool features in HTML5 is getting a lot of web developers excited and there’s really no doubt that it will be a huge step forward for the web. The more I follow the WhatWG mailing list though, the more I think we’re long past the era where it was considered safe to visit web pages. I’m not talking about browser security holes which have been around for a fair while and certainly do pose a risk, I’m talking about the things that are actually by design.

I keep seeing otherwise intelligent people1{#footlink1:1251967506123.footnote} encounter problems with software but never actually report them to anyone who could fix them. For commercial software opening a support ticket takes just a few minutes and usually gets the issue resolved pretty quickly so you can stop wasting time suffering through it or complaining about it. For open source software it’s often a bit more difficult – you need to join the users mailing list and ask questions there, follow up if you don’t get a response and maybe even put together a solid bug report. Still nothing ominous.

Every so often while using NetSuite, it pops up and asks me to fill in a quick little survey – basically how likely are you to recommend NetSuite and why? This is annoying when your in a rush but on balance not a bad way for them to ensure their customers are happy.

There’s just one catch – every single time I tell them that I’d never recommend NetSuite and that they should improve product quality, specifically they should handle escaping XML tags correctly. As a company that makes HTML editors, we quite often send and receive emails that talk about HTML tags rather than just including them. Unfortunately, NetSuite for the past 5 years or more has happily messed these emails up and we’ve had to come up with complicated ways to get the original email text back out. We’ve reported this to them on multiple occasions and at one point had to actually put in a XSS exploit to get them to understand how big a problem it was. Over time they’ve shifted where the correct HTML will appear in the system, but never actually fixed it entirely.

I really don’t understand why companies don’t think Google has made their apps enterprise ready. I’ve been playing with the premium version of Google Apps the last few days and it shows all the important characteristics of enterprise software:

Innocent Looking Settings That Break Everything

Google has this in spades. My favorite is the fact that if you happen to disable a service such as e-mail, all the settings continue to apply, but disappear from the admin dashboard. The net result for me was that all the Google Apps suddenly failed to send any e-mail (but e-mail from every other source worked perfectly).