Recently I had to adapt some older Java code to support a new requirement: an existing CSV report needed to include a user’s email address, translated from the user id. Pretty simple, but how does the CSV report generator translate the user id to an email address?
Continue reading Picking the right abstraction
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 Play! 2.0: A First Impression
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 Spring testing on steriods
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
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 Option[Scala]… a better null?
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 Fixing date in test using JUnit MethodRule
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 Organizing test code in Java