I have been going to the Recent Object-Oriented Trends (ROOTS) conference in Bergen for the last seven years, the last two years as a member of the program committee. It always strikes me how this conference gives me a different view on what I thought I knew, instead of just teaching a few new programming tricks.
The conference is a well-kept secret. The intimate and conversational atmosphere gives everyone attending a chance to discuss software developments with some of the great minds of our field.
Many people enjoy splitting testing up in a myriad of test types: Acceptance Tests, Functional Tests, Integration Tests, Performance Test, Technical Tests, Unit Tests. I have myself been guilty of such terminology as “embedded integration tests” and “requirement tests”. However, what unites the tests are more important than what divides them. The divisions are fuzzy, and they should be.
All tests have but two purposes: To tell you if you’ve completed a new requirement, and to ensure that you haven’t broken something that worked. There are three fundamental properties of a good test suite: Coverage, Robustness and Speed.
The idea of effective reuse is a pervasive one. Software organizations have searched for ways to avoid “reinventing the wheel” for as long as there has been a software industry. But all research on research on reuse indicates that it is much more expensive than people expect. There are a few delicate balances that a reuse effort needs to observe. The ones I’ve notices the most have been Quality versus Expediency and Control versus Evolution. How can we deal with these forces and come out ahead?
After spending more time than I care to indulge trying to get commercial application servers to behave, I finally decided to Do the Simplest Thing that Could Possibly Work, and create a new application server from scratch. Well, not really a full application server. For 90 % of the Java applications out there, all that you really need is Servlets, so I limit myself to that. And not really from scratch. The servlet functionality is provided by jetty, the application is built using Maven, the startup script is generated with the Maven Appassembler Plugin, and the final package is constructed using Maven Assembly Plugin.
The result is a project that lets me construct and release zip-files that can be copied onto an server host, extracted, and started up with a single script. With some help from my friends, I’ve added a few bells and whistles to make it as complete as possible. However, this article describes the simplest possible “Maven application server” that you can start with. You can find the application code in my subversion repository.
Last night, I worked until after midnight trying to get our application up and running after some seemingly inconsequential changes in Spring-XML configuration. Our application consists of a total of 32 modules (including 6 wars and one “server” module that packages them, and 11 modules that are shared with other projects). Most of these modules have Spring-XML fragments that are included in a few different ways, with the result that a nobody on the team actually understands how it fits together. My conclusion is that Spring-XML is at least as bad as the old ejb-jar.xml and similar regimes that is has tried to replace, and that it might be a sufficient reason to recommend not using Spring at all.