Maven database migration plugin

I finally got around to testing c5-db-migration -- a database migration plugin for Maven. Essentially, it's tool for managing your database changes. The plugin is very straightforward to use:

1. Copy and paste the plugin configuration to your pom.xml.
2. Add a couple of SQL scripts into your src/main/db/migrations in the format of yyyyMMddHHmmss_some_description.sql
3. And run mvn db-migration:migrate to run the SQL scripts against your database.
   

The plugin tracks your migration in a table called schema_version. It's not as comprehensive as Rail's database migration tool (e.g., it doesn't support downward migrations). Nevertheless, it's simple and unobtrusive.

If you're managing database changes manually through collections of SQL scripts, there's no reason why you shouldn't give this plugin a try.

SpringSource tc Server Developers Edition

At the risk of becoming a SpringSource shrill, check out the video on Spring's Tomcat server for developers.

http://www.springsource.com/products/tcserver/devedition

It's basically a modified version of Tomcat that makes it very easy to profile web applications. It's free but NOT open source.

Saros Pair Programming Plugin for Eclipse

Saros is a pretty impressive open source plugin for Eclipse that allows collaborative editing (i.e., pair programming). It requires only a Jabber server. Check out this 11 minute video of Saros.

Java Beans without getters/setters using lombok

Project Lombok is probably going to be one of the most useful library for Java. The library (requires Java 1.6) provides annotations that generate getters, setters, toString, hashCode, & equals for your POJOs. For example:

@Data // Lombok annotation
public class Person {

private String firstName;
private String lastName;

}

// Now your class has all the getters, setters,
// equals(), hashCode(), and toString()

C#/.NET has had this syntactic sugar built into the language for years but I was ambivalent about the approach. I'm more of a fan of languages with sparse syntax set such as C but the downside is that you end up writing much more boilerplate code. I think Lombok's approach is a nice compromise between bloated language feature set and having verbose code because of sparse language feature set. And it's supposedly supported in Eclipse.

Integration testing with Spring

Watch this Rod Johnson talk if you're not already familiar with rolling back transaction as a means of performing integration tests:

http://www.infoq.com/presentations/system-integration-testing-with-spring

You can probably skip to the 30 minute mark if you're already familiar with the reasons for testing.

Languages for JVM

The Java language is mature and that in the software development world means that it's dying. The Java language was designed around object-oriented programming but the trend now is moving towards more functional programming (which is arguably better suited in concurrent environments). I've been looking at newer languages built on top of JVM: Groovy, Scala, and Clojure.


Groovy is basically a dynamic version of the Java language with some new language features such as closures (a feature in functional programming). In essence, Groovy is "Java scripted" inspired from Python and Ruby.


Scala is an object oriented language with functional language features. It is not a scripting language and has features such as type inference:

var t = new Tiger();

The compiler knows that t is a Tiger -- no need to do:

Tiger t = new Tiger();

This type information is available at compile-time which allows for compile-time optimizations, making Scala on par with native Java performance.


Clojure essentially Lisp-inspired language running on the JVM.


All the above languages do not differ much with their Java interop (i.e., you can pretty much call existing Java code directly). All reduces the verbosity of Java. If I had to learn one language, I would pick Scala. I think Groovy is too small of an evolution over Java (i.e., not much benefits). Clojure just seems to radical for object-oriented developers.

Here's some additional points in no particular order:

- Martin Odersky, father of Groovy, said "I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy." http://java.dzone.com/articles/scala-long-term-replacement

- Scala is available both JVM and .NET. http://programming-scala.labs.oreilly.com/ch01.html

Integration test hell

For those of you spending lots of time fixing up integration tests, J.B. Rainsberger explains why he thinks integration tests are a scam:

http://www.infoq.com/presentations/integration-tests-scam

I think the point he is driving home is that we should be focusing more on comprehensive unit tests rather than comprehensive integration tests. I've started changing how I write my integration tests: They should only be verifying the interactivity of components, rather the expected results of the component.

Let's say that a User Service class (UserService) that calls a User Data Access Object class (UserDAO). The unit tests for UserService should use a mock of UserDao and asserting exact equality with the data and exceptions returned from UserDao properly (-- nothing new here). Your integration tests for UserService should use a real UserDao that is connected database (-- again, nothing new here). However, these types of test should NOT be asserting data and exceptions equality. Rather, these integration tests should just be verifying that some data/exceptions are returned. Integration tests should be testing the seams between the UserService and UserDao components, rather than asserting the equality of the value themselves.

Overally, I recommend watching this talk if you have done lots of unit and integration tests writing and wondering if you are duplicating effort.