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 »

Share

Development teams new to Scrum are introduced to a number of mandatory aspects that come with the framework. One of these is the Daily Scrum, or often referred to as the Daily Standup (meeting) or Standup in short. The purpose of this meeting is to synchronize the status of the development team and to do this in a short and focused manner. In this post I’d like to discuss an anti-pattern I see observing and being part of Daily Scrum meetings and how to overcome it.
Continue reading »

Share

I am a big fan of Big Visible Charts, also referred to as Information Radiators. By radiating information using such charts everything is visible and people can use that information to act upon it. Recent observations made me realize that not all charts are visible though. Even when they are big and in your face.
Continue reading »

Share

While implementing a simple event store for an example application I needed to serialize JSON data to binary arrays and turn those bytes back into the original JSON. Obviously, that’s a piece of cake!

Continue reading »

Share

I’ve been coding in Ruby on Rails for the past couple of months. It was a fun and sometimes tough journey (and still is sometimes) learning a new language and platform. My main background is Java, but last year I was fed up with that. It was too hard to do simple stuff. I reckoned that there should be an easier way. Plus, learning a new language broadens your vision and it helped me to improve my programming skills. This blog post is the first of a series (probably, if there’s enough interest) towards implementing a Rails application. I’d like to give you a heads up of what I discovered head first.
Continue reading »

Share

Recently I conducted a code review for one of our customers. They already are using A3 reports internally as problem solving and report tool. I really like A3, so I thought why not try if a code review fits in a A3 report.
Continue reading »

Share

This is the fifth and final part of this series. The previous parts consist of:

  1. a not totally trivial example implemented using JPA and Scala
  2. an event sourced implementation using explicit state changes
  3. a straightforward translation of the mutable event sourced implementation into an immutable implementation
  4. encoding domain knowledge into the type system to make the domain easier to understand and reduce the number of runtime error checks

In this last part we’ll reduce the boilerplate code related to handling events and as a bonus we’ll also make handling validation a bit nicer. But before we take a deep dive into the code, let’s consider the design of the last three Invoice implementations.
Continue reading »

Share

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 »

Share

We’re already on the fourth part of this series. The previous parts consist of:

  1. a not totally trivial example implemented using JPA and Scala
  2. an event sourced implementation using explicit state changes
  3. a straightforward translation of the mutable event sourced implementation into an immutable implementation

In this part we’ll explore how we can improve on the original design now that the invoice is immutable.
Continue reading »

Share

In part 1 we looked at a stereotypical implementation of an Invoice domain class. In part 2 we introduced event sourcing to extract the durability and reporting concerns from the behavioral requirements and to move closer to making the Invoice immutable. In this part we’ll explore the first implementation of an immutable Invoice.
Continue reading »

Share
© 2012 Zilverblog Suffusion theme by Sayontan Sinha