David Keen

In a previous article I described how to load test data that your ScalaTest Play Framework functional tests might need using Play Framework’s Evolutions. This made use of the SimpleEvolutionsReader class and defining evolutions in the test setup code.

Recently I wanted to also load some test data from a file and so turned to the ClassLoaderEvolutionsReader class which loads resources from the class path.

The trouble was I wanted to apply the schema from my standard evolution files first and then load the test data. The ClassLoaderEvolutionsReader requires evolutions revisions to start at 1 which would conflict with the standard application evolutions already applied.

So I wrote a custom SingleRevisionClassLoaderEvolutionsReader that reads a single revision from the class path.

https://gist.github.com/davidkeen/df83d5716bb72073df4fb5834f727d2d

You can then place your evolution files in /test/resources/evolutions/default/ and apply them after your standard evolutions in your test setup, for example, if your test data was in a file called 100.sql :

// Load the database schema
Evolutions.applyEvolutions(db)

// Load the test data
Evolutions.applyEvolutions(db, SingleRevisionClassLoaderEvolutionsReader(revision = 100))

Java enums are handy things. Often used as an effective replacement for simple int constants you can also add methods and fields and make them implement arbitrary interfaces.

Joshua Bloch has lots of interesting things to say about them in his excellent book, Effective Java. Item 34 describes a way to emulate extensible enums with interfaces but having an enum implement an interface can also be a simple way to split a large, unwieldy enum into smaller parts.

Consider a simple enum that contains a code and a message:

public enum Code {
    
    CODE_A("alpha"),
    CODE_B("bravo"),
    CODE_Y("yankee"),
    CODE_Z("zulu");

    private final String message;

    public String getMessage() {
        return message;
    }
}

Perhaps you have hundreds of codes associated with different parts of your application but you want to do some common processing of them. Rather than maintaining a big enum full of all the codes in your system you could extract an interface and have your enums implement it. The enums could then be much smaller and placed with or near the code that uses them directly.

Here’s the Code interface:

public interface Code {
    String getMessage();
}

Your smaller enums would implement it:

public enum EarlyCode implements Code {
    CODE_A("alpha"),
    CODE_B("bravo");

    private final String message;

    @Override
    public String getMessage() {
        return message;
    }
}

The only downside is you can’t share behaviour (at least no more than Java 8 allows for interfaces with default and static methods) but in this case it doesn’t matter because the amount of code is small.

Have you ever noticed misspelled HTTP response headers?

$ http -h http://www.dmoz.org/Computers/Programming/Languages/Python/Books/
HTTP/1.1 200 OK
Connection: close
Content-Encoding: gzip
Content-Language: en
Content-Length: 9907
Content-Type: text/html;charset=UTF-8
Cteonnt-Length: 33416
Date: Tue, 12 Apr 2016 12:26:06 GMT
Server: Apache

That ‘Cteonnt-Length’ sure looks weird!

According to this StackOverflow answer, the jumbled header contains the uncompressed size of the response and, sure enough, it does seem to be the case. But why?

It seems like this is a trick employed by hardware appliances (eg Citrix NetScaler) to ‘remove’ a header without affecting the check-sum value.

It is common when working with git to use lots of branches. Occasionally you might accidentally commit to the wrong branch but thankfully git makes it easy to put these commits in the right place.

It’s worth noting that the fixes described here are only for when you haven’t pushed anything to a remote branch otherwise you will be changing history that someone else might have already pulled.You don’t want to do that.

There are two scenarios we will consider.

Move recent commits into new <branch> instead of <master>

This is when you made a couple of commits to master but now realise they should have been split into a separate branch.

This is easy to fix: first make a copy of the current state of your master branch, then roll it back to the previous commit. For example, if the commit hash before your changes was a6b4c974:

git branch <branch>
git reset --hard a6b4c974
git checkout <branch>

Accidentally committed on <master> instead of <branch>

This is when you should have committed to an existing branch but accidentally committed to master; a similar situation to the first but requires some different voodoo to fix.

Again, we make a copy of the current state in a tmp branch and reset master. Then we use the three argument form of git rebase –onto to remove the offending commits. We want to get the commits that are now in <tmp> into <branch>. We want to make <branch> the new base of <tmp> starting at the point where <tmp> diverged from master. We then merge these changes into <branch> where they should have been committed originally.

git branch <tmp>
git reset --hard a6b4c974
git rebase --onto <branch> <master> <tmp>
git checkout <branch>
git merge <tmp>
git branch -d <tmp>