The most recent issue of the Norwegian ComputerWorld contains several articles of interest from an open-source point of view. In addition, the subject has come up for discussion at work recently.

Who benefits from open-source? Primarily, it is the consumers of software. Yet the consumers of open-source devote very little resources to developing open-source software themselves. Perhaps they should?

The hardest issue for organizations using open-source contribute time and money to the development of open-source is the fact that it is hard to see that this is money well spent. Chances are that if you develop software for yourself, you’d like to keep it in house instead of helping the competition. And maybe you’d rather just like to wait for someone else to develop it instead. I will not try to address this really difficult problem, and rather ruminate over an ideal situation.

My company develops software that runs banking infrastructure. In order to run this business, we use tools like Spring, Hibernate, Axis, Ant, Maven, and many others. If we spend some money contributing to the further development of these tools, we would ultimately stand to benefit a lot (but so would our competitors).

Both the Norwegian, the Brazilian, and the German governments have recently distanced themselves from Microsoft, and are looking into using Linux and Open-Office in governmental offices. If these governments would spend some money contributing to these open-source efforts, they could ultimately reap the benefits in lower spending on good software. (All this would be a loss for Microsoft, but hey, they’ve got enough money!)

Some of the most popular new gadgets are portable digital music players like the iPod and iRiver (my favorite). Just around the corner is the wide-spread adoption of media servers. One of the most annoying thing about choosing a media server or music player is the software. “Do this partical player support this format? (probably not) Will they keep providing functionality in the future? (probably not)” By opening the source of their media player software, they can allow their own users to improve their product for them. They will also expand the marked for third party software for their products, further enhancing their value.

These examples show ways in which organizations, or society in general can benefit from open-source software. The problem is overcoming the mental barrier and, even harder, do it in a way that doesn’t give your competition a leg up over you. But open source makes sense in the same way as public roads, power grids, and publicly funded basic research. It makes a lot of economic sense to pool our resources together.

I like metadata for some tasks. Luckily for all of us, Commons-Attributes implements metadata for pre-Tiger JDKs. Unluckily, it requires an extra compilation step (with Ant, no less). But no more. I’ve created an extension that does it all in memory.

The class uses both xjavadoc and commons-attributes. Here is an example of usage:

    CommonsMemoryAttributes attributes = new CommonsMemoryAttributes("src");

    Class testClass = AttributeTestClass.class;
    
    public void testClassAttribute() throws SecurityException {
        Collection result = attributes.getAttributes(testClass, AttributeClass.class);
        assertEquals(result.toString(), 1, result.size());
        assertEquals(new AttributeClass("test", 123), result.iterator().next());
        result = attributes.getAttributes(testClass);
        assertEquals(result.toString(), 2, result.size());
    }

The CommonsMemoryAttributes constructor takes the path to the source code. Using xjavadoc, I am able to parse and deal with the class very quickly.

There are still a few wrinkles to be ironed out, but I think it is a good start

The code is available here. All dependencies are handled through Maven, for your conveinience.

How should development teams be organized? Reduce chatty interfaces.

In Lean Software Development Mary Poppendieck describes the seven wastes of production and their analogy in software development. Three of these are: Motion (software analogy: Finding information), Waiting (Waiting), and Transportation (Handoffs). I see these in many projects that I am involved in, or hear about.

One problem many organizations experience is a divergence of software developed by different teams. This is a serious problem, but many organisations choose the other extreme.

In some projects teams specialize in such ways that many component is maintained by a different team. Each delivered user goal (use case, user story, whatever) is realized by a number of teams responsible for different components of the solution. This involves communicating information between the teams, waiting for the other teams to finish their work, and handing off interfaces or code to different teams. In other words, it incurs waste.

Why is this bad?

• A delay from one of the teams will cause waiting for the other teams
• The software interfaces will risk becoming rigid and inefficient
• The administration effort of the coordination will be expensive
• A delay from on team will upset the project plans for the other teams
• Understanding of user goals have to be communicated to more people, potensially causing misunderstandings
• Testing and correcting defects will be harder, since all possible teams will need to be involved

In conclusion, ideally teams should be organised so that delivering one user goal will involve as few people as possible.

When I have been using easyMock Mock Objects for testing I often find it
helpful to intersperse expectations and test code, for example:

  mock.start();
  control.replay();
  server.handleCommand("START");
  control.validate();

  control.reset();
  mock.shutdown();
  control.replay();
  server.handleCommand("STOP");
  control.validate();

Doing this with easyMock requires me to validate and reset the object
frequently. I was thinking: What is stopping me from just calling
doing this:

  mock.start();
  server.handleCommand("START");
  // call from the object-under-test, mock automatically assumes replay mode.

  mock.shutdown();
   // Call from the test-harness puts mock back in record mode.
  server.handleCommand("STOP");
  // Call from object-under-test, mock assumes replay mode again

  control.validate();
  // Validates the last "STOP" call

Of course, the problem is that the object-under-test (in this case,
the server) and the test-code uses the same mock object instance. This
lead me to the following solution: Make two mock objects – one for the
expectiations and one for the actual code. Thus the name DualMock.
Here is a snippet of test code:

   public void testImplicitSetVoidCallable() {
       DualMockControl control = DualMockControl.createMock(IMethods.class);
       IMethods record = (IMethods)control.getRecordMock();
       IMethods replay = (IMethods)control.getReplayMock();

       record.simpleMethod();
       replay.simpleMethod();

       record.simpleMethod();
       replay.simpleMethod();

       control.verify();
   }

The code is not completely developed yet, as I have only used it marginally myself. Let me know through email or a comment if you’d like the code.

(more…)

Spring has shown us how to effectively separate the business logic from data access logic. This allows for easy testing of business logic without having to deal with the database, but it does not provide any easy way to test the DAO code. A new feature in the Hypersonic database might just be what the doctor ordered.

HsqlDb 1.7.2 introduced RES urls. If you access your database with a RES-url, you get an in-memory database initialized with data in a jar file in the class path. Initializing an (especially) cleaning the database is very quick, so this can be used to run a large number of tests in succession. My initial experiments indicate that on average, you can run about 100 queries to the database per second with a full setup between them.

This is a step-by-step approach

1. Start up the hsqldb server in a new directory (e.g. …/hsqldb/data/test)
2. Connect to the database in a normal fashion and initialize the data schema and any static test data. I recommend keeping the amount of test data at a minimum
3. Shut down the database, and pack up directory it was running into a jar file. (E.g. if testdata.jar containing /data/test/testdatabase.properties and /data/test/testdatabase.script)
4. Add the newly created jar to your test classpath
5. In each setUp method in your data-centric tests, get a connection using the url jdbc:hsqldb:res:/path/to/database. (e.g. jdbc:hsqldb:res:/data/test/testdatabase)
6. In each shutdown method, execute the SQL statement “SHUTDOWN” on the database. This ensures that the database is rolled back to a pristine state.
7. The database can be used as normal in your test cases

If you want to modify your database schema or test data, you have to repeat the first four steps in the description. Otherwise, you can just add tests at will.

I have only recently started using this technique, but I am very happy with the results so far.

Finally, here is a bit of test code using HSQLDB res-urls and Spring-JDBC to test a DAO:

public class ProductManagerDaoJdbcTest extends TestCase {
    private ProductRepositoryDaoJdbc dao = new ProductRepositoryDaoJdbc();
    private DriverManagerDataSource datasource = new DriverManagerDataSource();
    
    protected void setUp() throws Exception {
        datasource.setDriverClassName("org.hsqldb.jdbcDriver");
        datasource.setUrl("jdbc:hsqldb:res:/data/test/testdatabase");
        datasource.setUsername("sa");

        dao.setDataSource(datasource);
    }
    protected void tearDown() {
        new JdbcTemplate(datasource).execute("SHUTDOWN");
    }

     /** Check that reference data is present in test database. */
    public void testGetProductList() {
        List l = dao.getProductList();
        Product p1 = (Product) l.get(0);
        assertEquals("Lamp", p1.getDescription());
        Product p2 = (Product) l.get(1);
        assertEquals("Table", p2.getDescription());
    }
}