Big Bee Consultants Ltd

Hudson is a continuous-integration build server which is easy to install and works well.  An earlier article compared Hudson with Cruise Control.  This article goes on to discuss how Hudson operates with source code stored in a Subversion repository.

Google's Go Language has been making news since the publicity launch in November '09.  Go combines the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++.

Cruise Control is a well-established continuous integration (CI) server and is doing a good job. So why would we even consider using something else – and all the upheaval of changing? The author was fortunate to operate the two systems side-by-side for a while for a busy development team. This review presents a comparison with Hudson and will attempt to provide some answers.

It's nearly a decade since W3C produced the first XHTML standard. In all that time, very few sites adopting it have gone as far as to serve the preferred MIME type (application/xhtml+xml). This is because it has been difficult to do well, and text/html sort-of works, so most website administrators don't bother. Here are some tips to make things easier.

A particularly important objective for developers producing of concurrent systems is to produce designs that always give consistent results and cannot deadlock (see The Four Horsemen on why this can be difficult).

XML documents typically refer to external entities, for example the public and/or system ID for the Document Type Definition. These external relationships are expressed using URIs, typically as URLs. However, if they're absolute URLs, they only work when your network can reach them. Relying on remote resources makes XML processing susceptible to both planned and unplanned network downtime. Conversely, if they're relative URLs, they're only useful in the context where the were initially created. For example, the URL "../../xml/dtd/docbookx.xml" will usually only be useful in very limited circumstances. One way to avoid these problems is to use an entity resolver (a standard part of SAX) or a URI Resolver (a standard part of JAXP).

Test-driven development (described on Wikipedia) is now widely accepted as the preferred way to develop software, especially Java software. I'm an enthusiastic supporter of this predilection - but there is a problem people seem often to overlook. I call it the Four Horsemen (also on Wikipedia) because there are four potentially major dynamic problems unreachable by testing alone.

The problems are:

'final' - underused or overrated?

I've always been one of those perhaps slightly annoying people who don't easily accept propositions that seem overly intricate. It's not that I'm a stroppy person - I'm pretty relaxed really - I just don't like wastefulness, and that can mean I'm unhappy when I see other people wasting their time doing things the hard way.

I wrote about the Spring Framework Mission Statement earlier. This article follows it by examining the second Spring mission statement bullet, which concerns the use of interfaces in Java:

• It's best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero.

Everyone knows this is a Good Thing - but why is it good?