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?
There has been a lot of talk about craftsmanship these days. I didn’t care much about the discussion whether we are craftsman or not. To me all that matters is what Uncle Bob says about it in one of his latest blog posts: We are tired of writing Crap.
But was is crap? And how do you know you are making a mess of things? So for your benefit I created the following Crap List. It’s opensource and free of use. It is mainly targeted on Java, but a lot also applies to other ecosystems. Please add as much crap to it as you like.
So here we go…
Continue reading Crap-o-meter
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