This blog is moving

This blog is moving to http://onth.at/blog.

I'm doing this to better aggregate it with my photography, and to gain greater control over how content is presented. It is very much a work in progress. Any feedback is welcome.

Design Patterns in memory managed languages

A lot of the work I am currently doing revolves around a legacy Delphi codebase. Delphi is an objected oriented language based on the Pascal syntax - and it requires the programmer to manage memory. As such, it has been an interesting challenge to attempt to apply modern design patterns to such a codebase. Languages such as Java and Ruby don't require the programmer to free up objects after they are no longer required, and as such many of the patterns we use in these languages need to be modified in order to apply them in a language such as Delphi.

For example, the following is a common pattern in constructor overloading:

class Foo {
    field Bar bar;

    constructor Foo() {
        this(new DefaultBar());
    }

    constructor Foo(Bar bar) {
        this.bar = bar;
    }
}

Constructor overloading in this manner allows the user to inject custom behaviour if desired, or make use of a default implementation. However, in a memory managed language, what should the destructor do? If bar was initialised using the first constructor, then Foo, is responsible for the clean up of bar. However, if bar was injected, then traditionally, the calling method is responsible for the clean up of bar. One option is getting Foo to remember whether bar was initialised or injected. However this is messy and obscures business logic occurring in Foo. Another alternative always make Foo responsible for the clean up of bar. This fits nicely with another pattern than needs to be adapted for a memory managed language - the Factory pattern.

class FooFactory {
    Foo createFoo() {
        Bar bar = new MarsBar();
        return new Foo(bar);
    }
}

In this case, FooFactory cannot be responsible for the destruction of Foo. Instead, that responsibility becomes that of the method which called FooFactory. Also, Foo becomes responsible for the destruction of bar as well.

Therefore, to properly make use of dependency injection in memory managed languages, certain concepts must be challenged. The method that creates an object is no longer its clear owner. When applying dependency injection in languages such as this, it is more important than ever to use sensible domain objects and abstractions. This makes it clear who owns any given object, and therefore who is responsible for its destruction.

Transactions around database tests

A database is probably the most common integration point found in software development. Therefore, testing that integration point is key. Ensuring that your queries work and that object relational mapping is configured correctly is key to making sure that the database schema maps to what your application expects.

The best way to test this is to write tests around your repositories to test that queries return expected results, and that your objects are loaded and persisted as expected.

For example:

@Test
public void shouldPersistBook() {
    BookRepository repository = new BookRepository();
    Book book = new BookBuilder()
                       .title("War of the Worlds")
                       .author("H. G. Wells")
                       .toBook();
    
    repository.save(book);
    
    List<Record> records = executeQuery("SELECT * FROM book WHERE title = 'War of the Worlds'");

    assertTrue(records.size() == 1);
}

However, there is a problem with this. After running this test, the database will have been modified. Assuming that title is the primary key for this table, this test will fail the second time it is run. An even worse scenario is that the test could pass even if the save method did nothing.

Therefore, it is sensible to make all tests occur within a transaction. This can be implemented in the setup and tear down of any database tests:

@Before
public void setUp() {
    executeStatement("START TRANSACTION");
}

@After
public void tearDown {
    executeStatement("ROLLBACK");
}

This of course only works if your repositories do not use any DDL statements that update the schema, or call commit explicitly. However doing either of these things is very bad, particularly the first, as your application should never be making schema changes. This makes your schema volatile and breaks any transactional wrapping your application may wish to enforce.

Problems cloning from github?

When cloning from github, myself and others have been receiving the following error:

$ git clone http://github.com/rails/rails.git
Initialized empty Git repository in ./rails/.git/
got 41af6d9a78446a5219a321cf638945b1608cefd8
walk 41af6d9a78446a5219a321cf638945b1608cefd8
Getting alternates list for http://github.com/rails/rails.git
Getting pack list for http://github.com/rails/rails.git
Getting index for pack 1f58330b738a4c1046b0da9b07830f2d658e5169
got 95a5e284c6504e28802aa3a8168a8b7cc450a0e5
got fe2f383cf3c0aa6901487c398b9ae8ffce03ecbd
error: Unable to get pack index http://github.com/rails/rails.git/objects/pack/pack-1f58330b738a4c1046b0da9b07830f2d658e5169.idx

Getting index for pack fc8e2c8270c16a9a2d401f1f44ddd4e5eb3ec1ce
Getting index for pack afc0d5bc07e84621fd69897165322a40cb9179c2
Getting index for pack 0dc33522bcfc9731cb6b414e4665ec9acb74e0a4
error: Unable to find 5b3f7563ae1b4a7160fda7fe34240d40c5777dcd under http://github.com/rails/rails.git
Cannot obtain needed object 5b3f7563ae1b4a7160fda7fe34240d40c5777dcd
while processing commit 41af6d9a78446a5219a321cf638945b1608cefd8.
fatal: Fetch failed.

Turns out that github sometimes has problems with cloning over http. Using git as the protocol seems to be less error prone and much quicker:

$ git clone git://github.com/rails/rails.git

Time lapse videos with the LX3

Time lapse videos are a particular interest of mine, which is clear from my previous posts on the topic. In the past I've always used my DSLR to capture the images for these videos, but I've found that it is not always the perfect solution.

For example, when making a time lapse video of a project at work, I had my DSLR set up on a tripod taking images every few seconds. While the team was very interested in the outcome of the video, the constant clicking of a shutter began to really grate on some, and I had to stop recording after a short space of time.

My Panasonic LX3 does not suffer from the same issue. It's much smaller and importantly much quieter. However, it lacks any means to trigger it remotely or on a timer. It does however offer a continuous shooting mode, taking images every half a second or so, until the memory card is full or the battery runs out. However, to use this mode, the shutter button must remain depressed.

Therefore I went searching and found a stockist for this online:



Combined with a cable release, you get this:



And as a result I was able to produce this:



link

The biggest drawback is that I am not able to control the interval at which images are taken. But I find this to be an acceptable trade off for the gains in quietness and portability.