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.


2017 - Year in Review

Mark Thomas

The Christmas sermon at our local church, really helped me to step back and reflect on 2017.  I was too busy to really notice at the time, but in hindsight 2017 was a year of change.

So, what changed?  There were two big changes in my personal life:

  • After three years of studying hard, my wife, Le'Nise, set up her own business.  Le'Nise is passionate about health and well-being, so if you need help with your goals for 2018 then definitely check out Eat Love Move.
  • My son started at school.  I can't believe that he is 4 years old already.  Watching children learn is fascinating, they are very flexible, open-minded and they pick up new concepts incredibly quickly.  Seeing a child learn something, like reading, that you take for granted teaches you a lot about how to learn.

And a lot happened professionally:

  • I started the year consulting at a bank, with lots of highlights:
    • First Kotlin app in production :-)
    • Lots of important changes delivered for the business.
    • Several of the components in our team’s platform were very performance critical.  We introduced InfluxDB and Grafana to replace an older Graphite stack.  This led to massive simplification, and the much better visualisation tools to help us to really understand what was happening in production.
    • I spent lots of time thinking about Operations, and worked on pushing out Consul (to support service discovery) and Ansible (to help standardise our deployment approaches).  This is the first team where I've worn a DevOps hat for a while and it was fun.  I’m a better developer because of this.
  • Alongside that, I worked with a really interesting start-up looking at ways to use Blockchain to improve Treasury management.  This was a great learning experience.
    • We partnered with IBM to look at Hyperledger Fabric, and spent 6 weeks with one of their technical experts.  I have a much better idea now of the practical issues and benefits of applying Blockchain to a business problem.
    • After years spent writing predominantly server side code, I built a modern web UI to demonstrate some of our ideas.  Lots of fun with React.
    • It's difficult to say whether a concrete offering will come from this.  But, I've learnt a lot about how to approach a startup, and some solid technical skills.
  • There are some benefits to being married to a software developer.  When my wife started her business, she had lots of interesting ideas for helping clients using technology.  We've been working together on implementing them.
    • The first priority was to provide a way for clients to pay for services.  We settled on using Stripe.  From a developer's perspective, it's pretty good, and it's reasonably priced.  The Stripe Checkout components made it really easy to get something live very quickly.  Definitely check it out if you need an easy to implement checkout.
    • Using Elm I built out a simple client web site with Stripe integrated and deployed.  Elm has been great.  I spent some time last year with Clojure + Reagent, and more recently with React and Javascript.  Elm seems to have just enough to be useful and is opinionated enough that it's easy to work out how to build out features.  I'll write up more detailed thoughts another time.
    • We deployed everything on Heroku.  It's my first experience with Heroku, but we needed fast time to market and it was great for that.  I was able to get the app deployed within a few hours, and loads of functionality comes for free: automated DB backups, log archiving/searching, metrics collection.  If you want to get up and running fast, it's worth checking out. 
  • Towards the end of the year, I started a new role at a Commodities Trading Firm.  The firm is moving from an environment of predominantly vendor products, to bespoke software solutions.  It's early days, but it feels like we can make a big difference going forward.

Balancing a full time day job, working with a startup, and building out software to support my wife’s business really helped me to focus and make the best use of my free time.  This may prove to be the most useful skill I learnt all year.

Quite a year!  

I'll post again with some thoughts on 2018 later, but for now Happy New Year!

Kotlin from JetBrains - try it now!

Mark Thomas

I love interviewing new developers.  It's a chance to chat with people who you don't know, and to explore ideas with someone who has different experiences and biases to yourself.  Hiring is hard, and in the past I've tried (and been tested myself) in many different ways.  At my current client, we're trialling an at-home coding exercise.  We are using a fairly straightforward problem involving a marketplace where participants can bid and offer, and the market will try to satisfy orders subject to some rules.  The idea is to send the candidate the problem and ask them to send in a solution giving an indication of how long it took them.

If the code looks good we do a pairing interview to explore the solution and work on some extensions.  It's an interesting way to figure out how someone thinks and just to see if they can produce something of high quality when they aren't pressured.

I decided to give the test a try myself to understand how difficult it is and then I remembered that I'd been meaning to try Kotlin ... Kotlin is a statically typed programming language from JetBrains.

My considered opinion after two hours writing Kotlin is that it's awesome!

To get started I had a quick look through the Kotlin language reference to get the basics, and then fired up a new Gradle based Kotlin project in IntelliJ.  I'm targeting the JVM and so everything was fairly familiar to me.  Gradle downloaded JUnit and Hamkrest (the Kotlin port of Hamcrest) and I started  TDDing my way to a solution.

The first and most obvious thing I noticed was the lack of boiler plate code.  I could create simple immutable classes in one line (see Data Classes in Kotlin), and get basic things like equality, hashcodes, toString methods for free.  The collections libraries worked well and as you'd expect from JetBrains, the IDE support is very good.  The solution I was left with was both expressive and simple.  Surprisingly given my complete lack of Kotlin experience, I think I probably got to a solution faster than I would have done in Java which I've been using for years.

For me part of the excitement is a feeling that Kotlin might be a good fit for Enterprise dev teams who use Java now.  The transition is easy, and the tool support combined with JetBrains backing may make Kotlin an easier sell than some of the other alternatives.  Time will tell.

I'll spend more time with it and develop my thoughts, but I'd definitely recommend that others take a look.  You can even try online here.

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.