I’m still trying to get rid of old habits, to shake of my winter hide, so to speak, and create some real Scala in stead of ScaVa (i.e. Java with a Scala syntax). If you’re interested you can bear witness to my struggle on GitHub (ShoppingList on GitHub). This story came about because I asked some colleagues for help. We ended up rewriting loops in several ways.
What I’ll show you is some alternatives to classic loops over collections.

The code is attached here. The example shows how to summarize items in a list. The objects in the list are all instances of class Stuff, a simple value container for a String and an Int. The idea is to summarize Stuffs with the same key to produce a new list:

  val items = List(Stuff("A", 1), Stuff("A", 2), Stuff("B", 3), Stuff("B", 4))

should become

  val expectedResult = List(Stuff("A", 3), Stuff("B", 7))

where Stuff is a simple case class with two attributes:

case class Stuff(val label: String, val number: Int)

Because I’m a long time Java programmer, my first solution looks like this:

  def classicSum = {
    var result: List[Stuff] = List()
    for (item <- items) {
      if (result.size > 0 && item.label == result.head.label) {
        result = Stuff(result.head.label, result.head.number + item.number) :: result.drop(1)
      } else {
        result = item :: result
      }
    }
    assertEquals(expectedResult, result.reverse)
  }
 

Good old looping and a var to collect the result. This works, but it doesn’t say what’s happening. All you see is a loop and some fancy list processing. Note the call to drop(1) allowing you to replace the head of the list with a new instance. I like the drop function and I’ve used it in other programs but here it just obfuscates matters.

The next solution is to go recursive. If you check out the version of ShoppingList as of October/November 2011, you’ll find lots of recursion. My goal at the time was to jam recursion into my head by banning all other forms of looping.
Applied to the list of Stuff instances and the problem at hand, the result is tragic:

  def recursiveSum = {
    @tailrec def sum(listOfPairs: List[Stuff], result: List[Stuff]): List[Stuff] = {
      listOfPairs match {
        case Nil => result
        case head :: tail =>
          {
            val currentHead = if (result.size == 0) { Stuff(head.label, 0) } else { result.head }
            val newResult =
              if (currentHead.label == head.label) {
                Stuff(currentHead.label, currentHead.number + head.number) :: result.drop(1)
              } else { head :: result }
            sum(tail, newResult)
          }
      }
    }
    val result = sum(items, List())
    assertEquals(expectedResult, result.reverse)
  }
 

My next version leverages Scala’s collections to drastically reduce the amount of code. The first attempt passes the test but it is cryptic. In the spirit of the red-green-refactor mantra I’ll show it to you anyway:

  def sumByGroupSolution1 = {
    val groupedByLabel = items.groupBy(_.label)
    val result = groupedByLabel map { t => Stuff(t._1, t._2 map { _.number } sum) }
    assertEquals(expectedResult, result)
  }
 

There! Go and parse that if you need to change this code sometime next year (note: having worked with this code for some time now while writing this blog, I must admit that it grows on you; after a while it doesn’t hurt all that much, sort of like a new pair of shoes). This cryptic piece of mal-ware illustrates the use of three powerfull methods named groupBy, map and sum.
groupBy is in a sense comparable to SQLs group by clause. The Scala version takes a collection and returns a Map. The map’s key is the element used to group by (Stuff.label in my case). The value is a List of elements that have the same key. In this case the items collection contains Stuff instances. I’ve grouped by the label field so the type of groupedByLabel is Map[String, List[Stuff]]. On this Map we have to apply a sum function to add up all Stuff instances in the List of Stuffs. Sum however works on Int’s, so before sum can be applied we have to extract the number field of each Stuff instance. This is done by a map: map {_.number}. The mapping is applied to each Stuff instance in the list of Stuffs that was returned by groupedByLabel.

By factoring out part of the code on line 3 in the example above, we can improve readability:

  def sumByGroupSolution2 = {
	val stuffsGroupedByLabel = items.groupBy(_.label)
    def sumOfStuffsWithTheSameLabel(stuffs: List[Stuff]): Int = stuffs map { _.number } sum
    val result = stuffsGroupedByLabel map { t => Stuff(t._1, sumOfStuffsWithTheSameLabel(t._2)) }
    assertEquals(expectedResult, result)
  }
 

I think this is better because now the result of part of the computation is named. Naming a thing makes it easier to see the algorithm.

The next solution uses more intermediate results. The results of each map or sum operation are stored in a variable that gets a meaningful name. This clarifies the meaning of intermediate results but the amount of code grows.

  @Test
  def sumByGroupSolution5 = {
    val calcSumOfStuff = (stuffs: Seq[Stuff]) => stuffs map { _.number } sum
    val groupedByLabel = items.groupBy { _.label }
    val resultGroupedByLabel = groupedByLabel mapValues { calcSumOfStuff }
    val result = resultGroupedByLabel map { t => Stuff(t._1, t._2) }
    assertEquals(expectedResult, result)
  }

The code shows another Map function named mapValues.

 val resultGroupedByLabel = groupedByLabel mapValues { calcSumOfStuff }

mapValues works on the values of a map only, ignoring the keys. In my case the keys don’t really matter (they’re an artifact of the groupBy call) so I can get away with mapValues rather than map.

Naming things was also the inspiration for the next solution. Now I’m not extracting intermediate results but in this case I’ve named the variables being manipulated:

  def sumByGroupSolution4 = {
    val groupedByLabel = items.groupBy(_.label)
    val result = groupedByLabel map { case (label, stuffs) => Stuff(label, stuffs map { _.number } sum) }
    assertEquals(expectedResult, result)
  }

The case statement as argument to the map makes it possible to introduce two variables to identify the things we’re manipulating. Label and stuffs mean more to me than _1 and _2.

Looking back on my struggle I like this solution best. I think it is both concise and easy to read.

After installing the Android development environment we where faced with the problem of designing our application.

Design
The idea of Quizzz is to show a screen with a picture, from our Xebia face book originally but for now a picture of a bird, and then provide the user with three names to choose from. On a white board it looks like this:

The top left part shows the starting screen: three buttons with random names, one of which is the name of the bird shown in the picture above. If you choose the correct name, you end up in the top right screen. If you press the wrong button, you end up in the lower right screen which shows you the correct answer and a button that takes you to
the top right screen where you can see the picture and name of the bird you selected.

We decided to implement the application as a single Activity. Activities are subsets of an application which can combine into a workflow by going from one activity to another. The back button on the phone takes you to the previous activity (not necessarily the previous content of the screen) so Activities structure the way the user navigates through the app. Because there is no back functionality in our application, we decided to create the whole workflow in one Activity. We use layout switching to present the user with different screens. This isn’t true in general, of course. In later versions we’ll add more Activities and Intentions and such, but for now we’ll keep things simple.

Code
To download the code, visit http://github.com/xebia/quizzz or clone the
repository:

git clone https://github.com/xebia/quizzz
cd quizzz
git checkout release1.0

We defined two layouts, main.xml and result.xml. The first shows the left side of the design and the second the right part of the design (see picture below).

If you start the app, QuizActivity is started. The Android framework calls the onCreate() method to do the required initialization. In our case this includes loading a set of images from a directory. We choose a list of birds common to India as a sample set, but any set of pictures will do.

	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		quizSet = QuizList.fromAssetsDirectory(this, "sets/Birds of India");
		layoutQuestion();
	}

The set of pictures for the quiz is loaded by a helper class named QuizList. The fromAssetsDirectory used the Android platform to load image files from a directory called ‘assets’ in the root of the quizzz project. The list is static now because it gets deployed along with the application. We will change that in a future version.

   public static QuizList fromAssetsDirectory(Context context, String directory) {
        QuizList quizList = new QuizList();
        try {
            String[] list = context.getResources().getAssets().list(directory);
            for (String pictureAssetName : list) {
                quizList.add(new AssetQuizItem(directory + "/" + pictureAssetName));
            }
        } catch (IOException e) {
            //Empty quizset
        }
        return quizList;
    }

The last act of onCreate() is to call layoutQuestion(). This method randomly selects three images from the set loaded before, assigns them to buttons and then hooks up itself in the setOnClickListener() method of each button. The buttons are stored in a HashMap so they can be retrieved later in the onClick() method.

onClick() uses the clicked button as an index in the HashMap mentioned above to find the answer that was chosen by the users and delegates to either layoutIfAnswerIsCorrect() or layoutIfAnswerIsWrong(). Both methods fill in data on a new view based on the answer supplied by the user. The methods end with a block of code that sets up a new Button and a listener to allow the user to take the next step.

Now the app sits and waits for a button to be pressed. Once this happens, the button’s onClickListener() method is executed. This causes onClick() to be called and the app takes appropriate action based on the user’s selection.

Note that we haven’t implemented other Activity life cycle methods (onPause(), onStop() and onDestroy()). We’re leaving this for later.

Result
To test our work we used the emulator in Eclipse. Right-click (or double-tap) the quizzz project in Eclipse and select RunAs -> Android application. Starting the emulator can be slow at times (it seems to use only a single core, this is a touch to realistic in our opinion…) but once started it is fast enough.

Deploying on your phone takes only a little longer. Choose Export -> Android -> Android Application and follow the steps of the wizard.

One thing that took a while to figure out: how to make a screen shot of the desktop of your phone? It turns out there is a function for that: hold down the back button and then press the button next to it.
Android confirms a screen shot has been taken and stores the image in the ScreenCapture directory.

Next steps
Now the basics work, we plan to explore further by adding the following functions (list is in no particular order):

1. Add an options button to load a set of pictures (so we can have the colleague quiz after all).
2. Implement all life cycle methods.
3. Build the app with Maven.
4. Find out how to unit/integration test Android

    val configData: Elem = XML.loadFile(jmsConfigFileName)

configData now holds a parsed version of the file whose name is stored in jmsConfigFileName. This file contains stuff like queue and topic definitions like the fragment below:

<queue name="queueTo">
    <sub-deployment-name>domain</sub-deployment-name>
    <jndi-name>domain/jms/qto</jndi-name>
  </queue>
  <topic name="domainJMSTopic">
    <sub-deployment-name>domain</sub-deployment-name>
    <jndi-name>domain/jms/topic</jndi-name>
  </topic>

My first attempt at retrieving all topic definitions from this config file was this:

  def findTopics(configData: Elem): Set[JmsObject] = {
    val jmsObjects = for (topic <- (configData \\ "topic"))
      yield (new JmsTopic((topic \ "@name").text, (topic \ "jndi-name").text))
    jmsObjects.toSet
  }

I felt really happy about having written this powerful and concise loop. Scala’s for construct is powerful, as well as its XML parsing. To retrieve the queues I added the method below:

  def findQueues(configData: Elem): Set[JmsObject] = {
    val jmsObjects = for (queue <- (configData \\ "queue"))
      yield (new JmsQueue((queue \ "@name").text, (queue \ "jndi-name").text))
    jmsObjects.toSet
  }

The duplication was obvious, so I felt a little less happy with my solution but I couldn’t see an easy way out. Enter my colleague and Scala trainer Urs Peter. He showed me two ways to improve the code.
Our first attempt looks like this:

def buildListOfJmsObjectsFromConfigData[T]
           (configData:Elem, clazz:Class[T], startNode:String): Set[T] = {
    val jmsObjects = for (node <- (configData \\ startNode))
      yield ( clazz.getConstructors.apply(0).newInstance(
                             (node \ "@name").text
                           , (node \ "jndi-name").text).asInstanceOf[T])
    jmsObjects.toSet
  }

Which you can then call like this:

buildListOfJmsObjectsFromConfigData (configData, classOf[JmsConnectionFactory]
           , "connection-factory")

This looked quite Java-ish to me, as well as complex and obfuscated.

Our second attempt removes the loop and uses currying. It looks like this:

def buildListOfJmsObjectsFromConfigData[T]
            (configData:Elem, startNode:String) (f:(NodeSeq) => T): Set[T] = {
     (configData \\ startNode).map(f).toSet
}

This second variant of buildListOfJmsObjectsFromConfigData[T] can be called like this:

      buildListOfJmsObjectsFromConfigData (configData, "topic") {
        node => new JmsTopic((node \ "@name").text, (node \ "jndi-name").text)
      }

This works because the (configData \\ startNode) yields a set of objects on which we call map. Map takes a function as a parameter. The function shown above extracts a JmsTopic object, so we end up with a collection of JmsTopic instances.

I’m happy with our final version. It is concise and clear as well as extensible; way better than my first Java-ish version.

The code is attached here.
I created three versions that are exercised in a unit test. JmsConfigReaderV1 is the first Java-ish version, JmsConfigReaderV2 is the compact but obfuscated solution and JmsConfigReaderV3 is my final attempt.
I’m sure there are lots of opportunities to improve, so I welcome your opinions ans comments.

Evil laughter sounds.

We rely heavily on Fitnesse because it allows us to write specifications for our code in a way that is executable as well as understandable for others. You can even finish test cases before the coding is done so the tests work as part of the definition of done for a user story during a Sprint. The tests helped us to understand what the code was supposed to do, on a much higher level of abstraction than a unit test. This made it easier to find out what should be happening and fix the errors that were introduced by our refactoring. Because the Fitnesse tests make about 20,000 assertions we’re pretty confident the code still does what it did before.

Software depends on other software because we don’t want to build systems from scratch. Each piece of software your code depends on may:
- change the address or name by which it is known
- change the technology it is implemented in
- be unavailable when you need it
- live on a different server or in the same process
- be connected through infrastructure that cannot be trusted
- speak a different language

Names
A name is no more than an abstraction: using an algorithm a name can be translated into something useful.
In networks we’re already used to names: nobody types IP addresses to locate a server on the Internet, we just use an easy to remember name. The mapping of this name to a physical address may change over time, but the rate of this change tends to be much slower than the rate of change for the software that is represented by the name.
Basically, we can get away with a DNS-like registry to translate service names into information that allows software to call a method on a server.
A message broker could be useful, but if all we need is an extended naming service we might as well use a directory. Plumbing software, the code that is used by our business code to call a service, performs a lookup of a service and stores the result. This avoids costly round trips to a broker. Compare this to the way a browser uses a DNS: the name is translated to an IP address and the result is cached until an error occurs. When an error occurs the lookup is executed again and the new result is used until further notice.
This solution is easy, robust, avoids a single point of failure for most calls, allows change etc.
Most software changes location over time, but changes occur at a slow rate. Messages shouldn’t be forced to pass through expensive infrastructure each and every time.

As an example, lets consider the interaction between two applications:
App1 sends a message to a broker via a firewall
The broker sends a message to App2 via a firewall
App2 returns results to App1, using broker and firewall

By the way, App1 and App2 are deployed as two EARs in a single Weblogic instance. This simple form of interaction should not be implemented by the complex process outlined above.

Managing unavailability
Most processes require an answer right here and now, but unfortunately some systems are unavailable during several hours a day. You can accept data and promise to handle the request later. To do this safely you can either store data in a database or put a message on a queue.
Queues are an important piece of middleware that is well understood, widely available on many different platforms (most notably mainframes) and can be configured to never loose a message and be always available.
Therefore I consider queues an essential part of any non-trivial infrastructure.

Security
The basic concepts of security are identity and confidentiality. Within a company infrastructure both are addressed by plain SSL connections. There’s more to security, but we’ll save that for later. My rule is that simple problems require simple solutions, so I’m claiming that SSL will do most of the time.

XML
Angle brackets are performance hogs. XML is inefficient in network bandwidth use and requires costly marshalling and unmarshalling. It may be easy to use for developers, but the cost of infrastructure in terms of servers and networks may easily outweigh the benefits of development efficiency.
I’ll even go one step further: XML was never intended to be used at runtime. Using concepts like XMLSchema we have a powerful, machine readable way to define messages. But does this imply we need all that dead weight between angle brackets all of the time? Again, following the simplicity rule I would rather choose a message format that can be parsed and transported efficiently. Like in the security case there is more to say on this topic later.

Batch processing
Batch processing differs from OLTP. Batches are about hundredths or thousandths of messages each hour or day. If you handle each message as a unique item, looking up the location of the service that should handle it, translate contents to XML, send it to a broker over a network, translate to Esperanto, send to another server over a network, translate to more XML, then call a service, then send the result back the other way around, batches will take down your infrastructure when volume starts to grow.
You may come away with this for OLTP but it will fail miserably for large numbers of messages.
So treat batches with the respect they deserve and design a solution that balances runtime performance and design time efficiency.

The list so far
What we need in infrastructure so far is the list of concepts and tools below:
- a directory that allows software to find other software, even if the target moves
- a mechanism to postpone processing to a later point in time
- a solution to ensure confidentiality and identity
- an efficient message format
- a batch processing strategy that can cope with large numbers of messages

Life isn’t always easy
You may end up composing a service out of smaller services to offer easy access or capture knowledge about how to use services.
Services may not speak the same language.
Sometimes you are forced to encrypt a portion of a message because it is send as part of a larger message that shouldn’t be readable while it passes through infrastructure.

The items above are valid concerns that become important at the fringes of your company or department infrastructure:
Composing services into a larger service stores knowledge and is therefore a useful concept. It also improves efficiency if the services are called over a slow network.

It is useful to standardize on a common dialect to be used throughout the enterprise. If you cannot start from scratch you will need something to translate between dialects. Also, standards are fine for exchanging data with business partners, but they may be to cumbersome to use in the enterprise. So we need something to translate at the borders. Maybe there’s a standard XML format for the exchange of messages in an industry.

In business-to-business message exchange we can imagine a broker service that forwards messages based on characteristics in a header section. The body of the message may be highly confidential, so it should be encrypted. This is where SSL falls short and we need something more sophisticated.

Conclusion
In this article I argued that within an enterprise we rarely need brokers and can get by using simple measures like directories and SSL connections. If the enterprise grows or you start exchanging information with business partners, you may need more sophisticated infrastructure. So, brokers, XML and the full plethora of WS* standards fit nicely in your DMZ but are overkill elsewhere.

Excellent.

Time goes by and you get involved in projects you didn’t write any code for. You look at the technology stack used and you realize they’re using this new fangled TechnologyX. You read the tutorial on the Internet and you think ‘OK, I understand, TechnologyX solves ProblemY, great’. Next time a customer asks you for a solution to ProblemY you tell them the story of this other project where they used TechnologyX. You’re no expert yourself, but you’ve got a colleague who knows all about it. Next problem, please!
In the mean time, in a parallel universe you know nothing about, people start using other technology that also solves ProblemY in radically different ways but since you didn’t stumble on these things you just don’t know. You’ve lost the ability to learn something radically new. You are stuck. Your waistline grows and you have become waste.

I strongly believe there is only one way to grow your professional skills and to keep increasing your value for your customers. You have to continue learning new technology. Not just by reading about it but by experiencing new technology and new techniques first hand.
The process goes like this:

1. Watch the presentation on InfoQ so you can sift out the obviously useless stuff.
2. Read more on technology that passes the filter above so you know to what kind of problems it might be applied.
3. Download the code for technology that might be useful for the problem you are working on or expect to be working on in the near future.
4. Use the new stuff to solve a problem you’ve solved before so you can focus on the technology instead of the business problem at hand (if you feel really un-inspired you can just build yet another PetStore).
5. Apply the new technology to a real life problem in a real project with real developers and a real deadline.
6. Repeat from step 1.

The crucial step in the list above is step 5: without real-life experience and especially without a deadline you will never find out if it works. In particular, you will never find out where technology hurts and where it facilitates. Architecture happens in development teams.

This only leaves one final step: share your knowledge with your peers in other projects so your organization learns. And never ever forget step 5.

Given the ideas in ‘Life..’ we can solve the transfer problem in a generic way that works for transfers between banks and it also works for transfers between accounts stored in the same database, because the problem is far less complex. Applying the concepts described below even if there is only a single banking system involved, makes sense because it allows you to scale the application beyond the boundaries of a single server.

The first thing we need is an entity. In therms of ‘Life…’ an entity is a set of data that is persisted as a unit. This might be my checking account at Bank A with all the transactions against it or the data the bank needs to store about me as a customer. Note that I wrote ‘my checking account’ and ‘me as a customer’. The ‘my’ and ‘me’ are important because in this context the term entity is used to mean a specific collection of data. In the traditional sense of entity relationship diagrams an entity would be the prototype to create many instances of database records, rather like a class is used to create many objects. Pat Helland redefines the term entity to mean ‘a specific instance’. In size an entity would be larger than an object. Account entities would probably contain many objects, like all transactions against the account for the last two years.
Now for the money transfer. In a traditional non distributed application something like this would happen: lock account A; lock account B; after checking the balance and making sure the deduction is OK, deduct amount from A; add amount to B; write to store; commit. Even though the accounts are stored in a single database, this would be classified as a distributed transaction in the sense of the article because it spans the entities account A and account B.
To solve the problem you might buy a humongous IBM beast of a server, but you could also reconsider your software architecture and come up with a solution like the one below (and then you could still buy a humongous IBM server, that doesn’t really matter).

The solution relies on three concepts: entities, messages and activities. We’ve seen entities above, so next in line are messages. Once we’ve deducted an amount from account A, the entity associated with A has to inform the entity that manages account B that it should add the amount to account B. This is done with a message that is handed to the infrastructure. Entities have two layers: a business layer that is blissfully unaware of technology (it is scale agnostic) and an infrastructure layer that is scale aware. The infrastructure layer sends a message to entity B. It starts trying to deliver the message once it is received from entity A. The scale aware layer of entity A may have to hunt down entity B in order to deliver the message. It may fail for technical reasons (entity B is not reachable due to a network failure) or business reasons (the account in entity B is not valid).
The code in entity A must deal with failure in the future: failure may occur some time after the message is sent. This is where the third concept, Activities, come into play. An activity is data about the conversation entity A has with entity B. Once entity A has placed the message on its out-queue, the activity will store this fact. If a success message is received from entity B, the activity is closed. If on the other hand a failure occurred, entity A has all the information it needs to act. A possible action could be to add the amount back to the account and send an email to the customer or log a failure message to the in-box of a bank employee. These actions may require the cooperation of other entities and thus lead to new messages and new activities, each working in its own transactional scope.

To summarize we saw that Entities are a collection of instances of data or objects that make some business sense. An entity has a scale agnostic and a scale aware layer. The scale aware layer deals with the delivery of messages to other entities. The scale agnostic layer stores information on messages sent to another entity in order to handle failures that cannot be automatically resolved by the scale aware layer. A transaction ends with the creation of a message. Interaction with other entities is never part of a transaction because other entities may live on a different server that might be unavailable. Activities store information on the exchange of messages between two entities and can be used by the scale agnostic business layer to handle failure.

Trends in burn down is a measurement of the number of story points implemented in an iteration (if you don’t use story points you can try some other measure like use cases or pages in a requirements document or whatever as long as you can measure for a significant period and the measured entity remains constant over time). If a team works on a system for some time the number of story points in each release will tend to stabilize. This is because the team learns about the subject matter of the system, learns each others capabilities and learns how to translate user stories into technology. So if you plot the number of story points per iteration against time you should find a horizontal line. If the number of story points per iteration goes down, there’s something wrong and you should investigate the cause. More on this below as we discuss complexity.

Trends in bugs is the number of open bugs in Jira or Bugzilla. If the development team implements story points and fixes bugs and the test team tests user stories, the number of bugs found should cancel out the number of bugs fixed. If the number of open bugs goes up this may be because testers test better (or more) and therefore find more bugs. This is actually a good thing (since the point of testing is to find bugs), though it means the team has more work to do. If the test effort remains the same and the number of bugs still goes up and the velocity is constant, the team is producing more bugs and we have a potential problem. Again, more on this below.

Trends in test coverage. The coverage of unit tests should be high (80% or better is our rule of thumb) and remain high during the project. If test coverage drops this may just be sloppiness: nobody cares any more and writing tests is considered to be extra work so it is easy to stop writing tests. This means the team is taking a risk that may lead to more Jira issues later on. But again, there may be another cause, see below.

Trends in complexity is about the average complexity of methods in the system. A generally accepted measurement of complexity is McCabe’s cyclomatic complexity. The actual measure used doesn’t really matter as long as it remains the same during the project. I propose to use the complexity of classes as a measure.

If a project is about to derail we want to know as early as possible. My statement is that complexity is the measurement to track:

1. If complexity goes up it will become harder to implement new features. This leads to lower velocity but not immediately. After a while velocity will go down because it takes longer to implement new features.
2. Complex code will also show more bugs so the ratio of new bugs versus fixed bugs will go up. Again this will take a while, especially if testing is done by a separate test team on a release, instead of by a tester who is part of the team.
3. Writing unit tests for complex code is harder so if you are struggling to get the story implemented because the code base is hard to understand, writing a unit test may be the first activity that gets dropped. At first test coverage will remain the same, but as it gets harder to write tests because complexity is going up, coverage will start to go down.

So, the measurement to watch is complexity as it develops in time. An excellent way to do this is to install Sonar (http://www.sonarsource.org/) and add it to the Maven build on your build server.
The other measures (burn down, bugs and test coverage) are interesting in their own right and serve as supporting evidence, so I suggest to measure them and plot them against time as well.

A Prima Donna is known outside of the software development world as the star of the opera, the one singer who can turn a nice evening out into an unforgettable experience. Sure, other vocalists and dancers are important, but their influence on the overall result is negligible. If the star of the show has an off-day, it doesn’t matter how well the rest of the cast performs; if on the other hand the star of the show is at his or her best, the audience will reward the cast with a standing ovation. Of course, the Prima Donna starts using this status to make demands that may gradually become absurd.

A software development team can suffer from a similar affliction. If one of the developers on the team is much more experienced than his team mates, it is only natural that this person has control over most of the important decisions. He may feel he is the only person on the team capable of setting directions, choosing architecture, modularization, selecting libraries, tools and build infrastructure. Others follow or leave and gradually the imbalance in the team grows. Because the Prima Donna knows best, he will get an important vote in hiring new team members. To defend his position he will favor docile people who are more easily controlled, and the team suffers even more.
The effects on software architecture can be devastating. The Prima Donna doesn’t need understandable code. On a small scale this isn’t so much of a problem, but in a large software project you may end up with unmaintainable spaghetti. Other team members may be unwilling or incapable to make changes to code developed by someone else for fear of breaking something or just because they can’t get their heads around it. Lack of shared ownership of a code base leads to duplication, dead code, more code and more duplication and so on. New developers face a steep learning curve, taking years to become productive.

So how do we get rid of this imbalance?

The first part of the solution is to spread responsibility among groups of team members by setting up feature teams. The main idea is to set up teams that will implement a small part of the system. Each team has representatives from all disciplines necessary to finish the job: designers, business logic experts, DBA’s and service developers are all part of a small team that will implement a feature in all its aspects. Besides allowing you to deploy small features quickly, the consequences are that people are part of a small focused team that will learn to make its own decisions. The team will have more body and will be better equipped to work with the Prima Donna, who gets a new job: keep an eye on the overall consistency of the work done by the feature teams and make sure all features work together well, make sure the architecture remains sound.
A second job for the Prima Donna is trouble shooting: if there are hard to diagnose problems in production it takes in depth knowledge of the system and the platform to find a solution, often under time pressure. This kind of work is the sweet spot of a real Prima Donna’s skills.

The aim is to parse a list of recipes like the one below:

name ZucchiniWithMinceMeat
season summer
category easy
cookingtime 45 minutes
preheat oven at 180 degrees
fry 500 gram mincemeat
fry 1 piece Zucchini
add 1 can mashedTomatoes
add 1 bag groundCheese
bake for 30 minutes

and turning it into a list of groceries like this:

mincemeat 500 gram
Zucchini 1 piece
mashedTomatoes 1 can
groundCheese 1 bag

Scala offers a parser for text named StandardTokenParsers in the package scala.util.parsing.combinator.syntactical. The idea is that a specific parser extends StandardTokenParsers. The parser should provide

  lexical.delimiters ++= List("(", ")", ",", " ", "\n")
  lexical.reserved ++= List("name", "season", "fry", "pack", "can", "bag", "piece", "at", "for", "bottle", "gram", "oven", "preheat", "bake", "serve", "with","add","degrees", "category", "cookingtime")

  def parseCookBook(cookBook:String):CookBook = {
		cookbook(new lexical.Scanner(cookBook)) match {
		  case Success(recipeList, _) => new CookBook(recipeList)
 		  case Failure(msg, _) => throw new ParseErrorException(msg)
		  case Error(msg, _) => throw new ParseErrorException(msg)
		}
  }

  def recipeName: Parser[String] =
    "name" ~ ident ^^ { case "name" ~ name => name }

  def ingredient: Parser[Ingredient] =
	opt(amount) ~ ident ^^
  	{ case Some(amount) ~ ingredient => (new Ingredient(ingredient,amount))
  	  case  _ ~ ingredient => {new Ingredient(ingredient)}
  	}

  def step: Parser[Step] =
	(fryStep | preHeatStep | serveWithStep | addStep | bakeStep) ^^ { case step => step }

  def listOfSeasons: Parser[List[Seasons]] =
    repsep(season ,",") ^^ { listOfSeasons: List[Seasons] => listOfSeasons }
}

  override def toString = {
  	val result:StringBuilder = new StringBuilder("Steps: ") 

   	list.foreach(step => result.append(step).append("\n"))
  	result.toString()
  }

	override def toString = "Steps: " + steps.mkString("\n")

  def findRecipesBySeason(season:Seasons):Seq[Recipe] = {
    recipes.filter(_.seasons.contains(season))
  }

public class Amount {
	private int amount;
	private String unitName;
	public Amount(int amount, String unitName) {
		this.amount=amount;
		this.unitName=unitName;
	}
	// getters and setters omitted for brevity...
}

class Amount (val amount:Int, val unitName:String) {
	override def toString = amount+":"+unitName
}