Here’s another interesting boat that I’ve noticed moored outside my flat a few times. It’s the Thames Vitality, one of two oxygenation barges built for Thames Water by McTay Marine.

The Thames’s oxygen levels can plummet after heavy rain when storm pipes overflow and these boats are used to replenish oxygen levels in the river. This process helps to prevent many fish deaths but the long term solution is to replace the old Victorian system with one that doesn’t allow sewage to drain into the river.

JIRA Agile has come a long way from the days of the GreenHopper plugin. It’s now pretty well integrated into JIRA and I’ve found it great for running an Agile workflow.

JIRA Agile supports both Scrum and Kanban boards so you can manage your tickets using whichever methodology you prefer but what if different parts of your team want or need to work in different ways? With JIRA Agile you can have multiple boards so tickets flow through different teams in different ways.

Maybe your developers are using Scrum with week long sprints. They want a standard Scrum board where they can take tickets from the To Do column, move them into In Progress when work starts and then to Done when complete.

But perhaps weekly sprints don’t really suit the planning workflow of your product team. They would prefer to use a Kanban approach of managing their work in progress.

Ideally we want to be able to create tickets on the product team’s board and move them into the developers’ board when they are at a suitable stage of readiness. By mapping statuses you can have a kind of combined Kanban/Scrum process.

Product Board

This is a Kanban board with 5 columns: Backlog, Requirements, Ready for development, Test and Ready for release. Each column is mapped to the following respective Statuses: IDEA, REQUIREMENTS, TO DO, RESOLVED and CLOSED. The IN PROGRESS status is left unmapped so tickets in this state will not show up on the board.

The product team can work on tickets in the Backlog and Requirements phases before moving them to the Ready for development column which will cause them to show up in the Development Scrum board (as we will see).

Once the developers have completed a ticket it can be moved into the RESOLVED state and it will then reappear on the Product board in the Test column. When the product owner is happy that the requirements have been met it can be moved to the Ready for release column.

Development Board

This is a Scrum board with the standard three columns: To Do, In Progress and Done. Some tickets may not need to be sent back to product for review and can be closed directly so the Done column has both RESOLVED and CLOSED statuses.

Scrum Board
Scrum development board

When planning a sprint, the Development board will only show those tickets with a status of TO DO in the backlog. Tickets that are still being prepared by the product team (IDEA and REQUIREMENTS) are left unmapped so won’t show up until they are ready to be scheduled into a sprint. Once a ticket is moved into the RESOLVED state it will reappear on the Product board.

By combining Scrum and Kanban boards you can create a hybrid workflow that better suits the needs of the people actually working on the tickets. You don’t need to force everyone into a single way of working.

In a previous post I showed a way to calculate the total distance of a GPX track using Scala’s foldLeft. Continuing my current hobby of exploring the new Java 8 lambdas and streams API I thought I would see how the functional approach translated to Java.

To recap, a GPX track is just a sequence of latitude, longitude pairs. The first problem is that Java doesn’t have Scala’s handy tuples so we need a custom class to represent a point.

My first thought was to use the reduce method on the Stream interface but given the slightly more complicated requirement to keep track of both the total distance and the previous point I ended up implementing a custom Collector. From the Javadoc a Collector is:

A mutable reduction operation that accumulates input elements into a mutable result container, optionally transforming the accumulated result into a final representation after all input elements have been processed. Reduction operations can be performed either sequentially or in parallel.

The Collector interface has three type parameters: T is the type of input elements to the reduction operation, A is the mutable accumulation type of the reduction operation and R is the result type of the reduction operation.

In our case, the input elements are Points and the result type is a Double (distance in miles). We just need a mutable accumulation type to keep track of the total distance and the last point in the track. Here it is:

So we have an input type and an accumulation type. Now we can implement the Collector which uses the haversine formula to calculate great circle distance between each point in the track and put it all together:

So given that we need to implement a Point class and a custom Collector the end result isn’t quite as concise as Scala but it’s still a nice functional way of processing the list. Unfortunately we can’t take advantage of parallel streams as the points have to be processed in order. The more I use Java 8’s new streams and lambdas the more I like them and Collectors are a nice way of customising reduction.


In a previous post I gave a way of generating random test mobile numbers (Ofcom approved!) using Scala iterators.

Now that Java 8 gives us lambdas and streams I thought I would see what those generators might look like in Java.

Here’s the mobile generator:

Nice, still a one-liner.

Generating pseudo MAC addresses is a little bit more trouble. This supplier uses another nested stream to generate the random hex array.

You use these Supplier functions with the static generate method of Stream. Because the generators create infinite streams we use limit to just get a few values. Eg:


Living on The River I see lots of interesting boats pass my window but today was the first warship. It must have been on it’s way to Henley on Thames for the Traditional Boat Festival this weekend. Motor torpedo boat MTB 102 is a pretty little boat with an interesting history.

MTB 102 was launched in 1937 and was the fastest vessel in the Royal Navy with a top speed of 48 knots. From 1939-40 she was stationed in the English Channel and took part in the evacuation of Dunkirk. When Rear Admiral Wake-Walker’s destroyer, HMS Keith, was disabled by a Stuka he transferred to MTB 102 and for the last two nights of Operation Dynamo MTB 102 became the smallest vessel ever to serve as a flagship for the Royal Navy. There was no Rear Admiral’s flag onboard so they made one from a dishcloth and red paint. She was the third to last vessel to leave Dunkirk.

In 1944 she carried Winston Churchill and General Eisenhower to review the fleet for Operation Overlord, the invasion of Normandy.

In 1976 she was used in the (awesome) film The Eagle Has Landed.

You can read more about her at the MTB 102 Trust website.