With the arrival of HTML 5 (which commonly means more than just HTML), web development has become even more of a joy that it used to be. Clean semantics in HTML, elegance through CSS, new scripting possibilities, it’s all there. This blog post describes two new features, offline applications and name/value storage, which allow developers to make web applications available offline.

The past years, we’ve seen two new terms become popular: REST (REpresentational State Transfer) and DDD (Domain Driven Design). However, where DDD is often used to prevent an Anemic Domain (now considered an anti-pattern), a domain model for REST is often anemic. This blog post explains how we can reconcile these opposites.

When starting a new project, its common to create an "Instant Developer Experience": a new developer can get started by issuing two commands: get the code, and build&run the application. The only things needed are Java, Maven and an IDE.

Have you ever needed to simultaniously develop in several modules? Did those modules have their own trunk/tags/branches in subversion, their own release cycle, etc.? Did everything build with a single Maven command?

Controlling complexity is the essence of computer programming.

— Brian Kernigan in [Kernighan-Plauger]

If you drop XML and configure your Spring web application in Java, you’ll still want to test your application. In fact, you can now also test your configuration.
A previous blog post describes how.

For REST webservices, integration tests have become superfluous. Not that testing them is not important (it is), but because we can fully test them using component tests.
This post continues our series to replace our Spring XML configuration with code and to fully test it and the code that uses it. As a finale, I’ll demonstrate how to test REST webservices during the unit/component test phase, thus reducing the amount of time spent testing.

Since Spring 3.0, configuration of your application context is possible in Java (using the @Configuration annotation). But it is only now maturing to a point where you can fully configure your web application, with the coming release of Spring 3.1 (milestone 2 was released just a few days ago). This blog post describes how.

A familiar problem when implementing a REST server, is that your framework limits what you can do. Sometimes, this problem can be mitigated (not solved) by reformulating (i.e. changing) your business needs. For example, you can reformulate save multiple changes to an invoice and its invoice lines with one click on a save button to save each of multiple changes to an invoice and its invoice lines as separate UI actions. Unfortunately, this change increases your audit trail and thus technology trumps business needs.