Feb 212012
 

Play! is a web framework for Java and Scala. Play promises to bring the developer productivity of web frameworks like Ruby on Rails to the Java and Scala languages. Of course, it wouldn’t make much sense just to copy Rails. So Play adds its own spin: Play 2.0 is fully statically type checked, giving the developer quick feedback when something doesn’t make any sense.

Now that Play 2.0 is getting closer to final release I took some time to dive in. Here are my first impressions, using the Scala APIs.
Continue reading »

Feb 092011
 

Recently I was involved in another Spring powered Java project and noticed a lot of test specific xml configuration floating around. Typically this is done because (for instance) datasources and such that are not available via JNDI outside a container. Problem that I have with the specific xml configuration is that it is maintenance intensive and well it is more xml… :-) Luckily you almost never have to create the specific XML files to be able to test your application context outside a container.
Continue reading »

Jan 232011
 

Yesterday I watched Graham Tackley’s talk (slides) on moving from Java to Scala at guardian.co.uk. The presentation is well worth watching if you’re considering adding Scala to your project.

One of the highlights for me was to see how easy it is to integrate Scala with the regular Java development and deployment process and how the team’s coding style evolved and improved as their understanding of Scala increased.

Another interesting point was that after a year of using Scala the team’s favorite feature was the Option type.

Option

Anyone new to Scala will quickly encounter the Option type. An Option[T] represents a value that may be present (containing Some value of type T) or is not there (None). Java has a similar facility built right into the language: nulls. So what makes Options so great compared to nulls?
Continue reading »

Jan 142011
 

One of the principles of a good unit test is that they are repeatable. This is especially important if the tests involve dates. Typically this is programmed in the setUp and tearDown of the unit tests. This might lead to duplication if multiple tests depend on such a fixed date. Of course we can abstract this to an Abstract base class, but in the end we all know that reuse via inheritance is a bad idea. JUnit @Rule can be a solution for this.
Continue reading »

Nov 192010
 

A short while back I started to work with Ruby on Rails. Incredible fun and inspiring. One of the (many) things I like is the distinction Rails creates of the different levels of test scopes. It has separate folders to store unit, functional, integration and performance tests.

Now in Java – and using the Maven default folder layout – you get one folder for storing your production code (src/main/java) and one for your test code (src/test/java). That got me to thinking to apply Rails’ way to structure your Java test suite. After a while it can be tricky to organize to test code, so I wanted to give it a shot with Java.
Continue reading »