Contact Us

Use the form on the right to contact us.

You can edit the text in this area, and change where the contact form on the right submits to, by entering edit mode using the modes on the bottom right. 


123 Street Avenue, City Town, 99999

(123) 555-6789


You can set your address, phone number, email and site description in the settings tab.
Link to read me page with more information.


maven-polyglot and IntelliJ

Mark Thomas

IntelliJ doesn't have support yet for non-XML Maven POMs, but all if not lost if you want to use them with your favourite IDE.  The polyglot-translate-plugin provides a good workaround by generating a pom.xml which IntelliJ can use based on your Ruby/Groovy/Clojure etc. POM.

For example, if you are using Ruby then you can run the following command to generate a pom.xml:

mvn io.takari.polyglot:polyglot-translate-plugin:translate -Dinput=pom.rb -Doutput=pom.xml

If you want to avoid typing out the parameters each time you run the translate goal, then you can move the plugin settings to your pom.rb:

build do
	plugin_management do
		plugin 'io.takari.polyglot:polyglot-translate-plugin' do
			configuration('input' => 'pom.rb', 'output' => 'pom.xml')

Your pom.xml can then be generated with:

mvn io.takari.polyglot:polyglot-translate-plugin:translate

There is an open feature request to add maven-polyglot to IntelliJ: 

Fifty Quick Ideas to Improve Your User Stories

Mark Thomas

I've just finished reading Fifty Quick Ideas to Improve User Stories by Gojko Adzic and David Evans.  It's one of the best tech books I've read recently, and probably the most useful book I've ever read on writing good user stories.

The book is split in to five sections covering ideas for Creating Stories, Planning with Stories, Discussing Stories, Splitting Stories and Managing Iterative Delivery.  Each idea summarises key benefits and how to make it work.  The content is accessible, but the reason I liked it so much is that it's also very practical. The ideas reflect some of the politics and biases that exist in real teams and suggest good ways to work with the environment to make improvements.

The authors have published a useful mind map which acts as an outline of the book, and also a good reminder to print out and stick up on a wall.  Here are a couple of my own take-aways which hopefully will give you a feel for what to expect:

When writing a story, describe the change in user behaviour that your system is trying to produce.  After implementation, test to make sure that you've achieved the desired change in behaviour.

  • Multi-disciplinary delivery teams have a lot of knowledge.  You can unleash their creativity by telling them what you are trying to achieve rather than giving them a solution up-front.  Once teams agree an approach and deliver it, we often declare victory.  The authors make the point that we should plan up-front how we can test that we've achieved the behaviour change that we're looking for, and post implementation check that we actually have.
  • Thinking about how to measure success helps to refine thinking about potential solutions, and like TDD makes us design in testability so that we can easily get at the right business metrics to measure success.  Analysis of results can measure success but also help us to plan next steps, and iteratively build improvements through learning.  

Budget instead of estimate

  • I've struggled in the past with estimation.  The authors suggest that in a high-trust environment rather than asking 'how long will it take?', it might be better to ask 'how much can you afford to pay for it?' and then use the answer as a constraint for a delivery team when they are coming up with potential solutions.
  • Delivery teams often try to guess 'how much can you afford' as a way of choosing an 'acceptable estimate' when a reliable estimate is difficult to produce, but not always as an explicit talking point with business decision makers.  Having that conversation up front seems sensible to me, and I suspect could lead to much better back and forth conversation between stakeholders around potential solutions.  This may be particularly true in teams that tend to offer gold plated solutions, when for a given business requirement something quick and dirty may be more commercially sensible.

The book is available on Amazon.

Fifty Quick Ideas to Improve Tests is on the way in March which should make a nice follow-on read.

Cross posting to the Working Code blog

Adding local docsets to Xcode

Mark Thomas

I've been playing around with core-plot, a graphing library for MacOS/iOS, which ships with a local dotset.  A normal double click on the docset from Finder wasn't enough to read it, after a bit of Googling the solution seems straightforward:

  1. Shutdown Xcode.
  2. Copy the .docset in to ~/Library/Developer/Shared/Documentation/DocSets
  3. Restart Xcode.

If you want to check that Xcode has picked up the new docset then look in Xcode Preferences under Downloads.

Sonar: Understanding your codebase

Mark Thomas

Large code bases can be difficult to understand, particularly for a new joiner to a team. Reading code is a great way to get the detail, but getting a high-level view can sometimes be hard. There are a range of open source tools that can provide Information about code coverage, design attributes and complexity, but it is often hard to extract the useful information from the volume of data produced by these tools. Critically it can sometimes be hard to visualise how this key information changes over time, and so get an idea of how your codebase is evolving. I've been experimenting recently with Sonar. Sonar provides a neat dashboard for viewing data about your project generated by tools such as PMD and Findbugs. It is fed by a build task that runs these tools in your build and uploads data in to the Sonar database. The really cool part of this, is that over time you can use Sonar to see trends in your codebase.

Sonar - Tapestry 5 Demo
Sonar - Tapestry 5 Demo

Take a look at this demo site for an example showing Tapestry 5 metrics: Between January and March you can see an increase in complexity but a decrease in code coverage. Through Sonar's different views, you can look at projects from a module, package or class level and understand hotspots that are contributing to the trend. It really is quite a valuable tool.

How do I set it up

If you use Maven then it is easy, just set up a server and then run:

mvn sonar:sonar

Non Maven users aren't left out, check out Sonar Light mode.

Functional Programming Fundamentals

Mark Thomas

I've been interested in functional programming for a while, and after spending the last 12 months or so working with Scala I can really see a difference in the way I think about solving problems. So, when an email dropped in to my inbox a few weeks ago about an 'Introduction to F#' presentation by Phillip Telford at work, I jumped at the chance to attend. Phillip is a Architectus Oryzus at Trayport working on trading solutions for financial markets, before that he worked at Microsoft Research. He talked us through the basics of F# and showed off the language in a basic Twitter application and then a simulator of the Mastermind board game. Both of the applications were extremely concise and elegant, I was certainly impressed and enjoyed making the comparison with Scala.

There has been a steady flow of F# adoption in the financial services sector, I know of a couple of banks who are using F# in production applications. That combined with Phillip's presentation has been enough to get me interested in learning more. Being a Microsoft technology, I started my search for more information at MSDN and found an absolute gem in Microsofts Deep Dive lecture series.

Dr. Erik Meijer has an online lecture series covering Functional Programming Fundamentals. I'm up to Chapter 5 now and am really enjoying it. It does cover a few things I know but the focus on pure functional development is giving me a really valuable perspective. That, and I'm getting a good opportunity to learn Haskell which I'm really starting to like.

For any budding F# developer, or someone who wants to know more about functional programming I highly recommend Fundamentals of Functional Programming.

Accessing OS X shared files from Vista

Mark Thomas

I ran in to a problem trying to access folders shared on my Mac laptop with SMB from a Vista PC. Each time I tried to access a folder I got an authentication error. After a bit of digging on the web, it seems that Vista will only use the NTLMv2 authentication method when trying to connect to SMB file shares, the default configuration of Samba on Leopard does not support NTLMv2. There is a fairly easy workaround, on the Vista machine:

  1. Open Administrative Tools in Control Panel
  2. Select 'Local Security Policy'
  3. Under 'Local Policies' choose 'Security Options'
  4. Find 'Network Security: LAN Manager Authentication Level'
  5. Change the setting from 'Send NTLMv2 response only' to 'Send LM & NTLM - use NTLMv2 if negotiated.
  6. Click OK

I'm not that familiar with Vista so I don't know if the Vista version makes a different, I am running Vista Ultimate with SP1.

Scala: Case Classes

Mark Thomas

Scala's case classes are regular classes with a twist. They are designed to support pattern matching without having to write excessive amounts of boilerplate code. As a developer, I want to understand how and when case classes should be used.

How are case classes declared?

By prefixing the declaration of a class with the word 'case'. e.g.

case class Person(firstName: String, lastName: String)

How do case classes differ from regular classes?

The compiler will automatically do a few things for case classes:

Generate an accessor methods for each of the constructor parameters
For each of the constructor parameters that is not already marked with a val or var modifier, a val modifier will be inserted. In effect, this will generate accessors for all of the constructor parameters.

Generate an extractor object
The compiler will also generate an extractor object. This supports pattern matching and means that 'new' is not required to create a new instance of a case class, so the following is valid:

val mark = Person("Mark", "Thomas")

The compiler interprets a 'Person(' as a call to 'Person.apply'.

Generate equals, hashcode and toString methods
Two instances are considered equal if they belong to the same case class and each of the constructor arguments is equal according to their equals method. The hashCode is guaranteed to match if the hashCodes of the constructor members of the two instances match. And, the toString method will do something sensible :-)


How do case classes help in pattern matching?

The auto-generated extractor can be used with match to match on constructor arguments. You can match on some or all of the constructor arguments, and decompose the case class back to those arguments. For example:

person match {
	case Person(firstName, "Thomas") => println("Hi " + firstName)
	case _ => println("Hello friend - " + person)

When are case classes useful?

A quick Google search on 'case classes' reveals some controversy around two points: whether case classes can lead to over-use of the match statement breaking encapsulation, and whether case classes are needed at all given that there pattern matching abilities can be provided with just extractors alone.


The argument goes that using match is not an object-oriented approach to development, and we've exposed our constructor parameters for no good reason. In the example above, an alternative approach could have been to add a 'greet' method to Person to encapsulate the behaviour of formulating the greeting inside the Person class. This is a valid concern and was my first concern when I thought about using case classes, however as Martin Odersky points out in a blog post there are times when 'decomposition on the outside' can be more preferable to 'decomposing on the inside'. Or put another way, where a solution based on OO-decomposition can be less readable or more contrived than one that is not. From Martin's post this is my favourite illustration of where pattern matching, based on type, can lead to a good solution:

try {
} catch {
  case ex: IOException => "handle io error"
  case ex: ClassCastException => "handle class cast errors"
  case ex: _ => "generic recovery"

We can't put the recovery code in to the exception class because it is context dependent, and whilst we could probably do something clever with the visitor pattern it would be painful. Martin identifies two cases where he believes that 'decomposition from the outside' is preferable to 'decomposition from the inside':

  1. when a computation rule involves several objects
  2. when a computation cannot usefully be defined as a member of the class on which we want to differentiate

Switch statements are not inherently bad but they are easy to abuse, the key as developers is understanding the best way of decomposing your problem domain and choosing the best solution for your situation.

Are case classes needed?

On this I'm not sure. Pattern matching can be enabled using extractors alone, but in some cases where data encapsulation is not a concern then they can provide a convenient approach. I hope that as my experience with Scala increases, I will be able to better answer this question.

Other uses for case classes?

Case classes provide a good way of implementing the visitor pattern because they provide a way of doing multiple-dispatch. I'll save that for another post.