What have I been up to?

Little bit of this, little of that. Little of the other.

Well, quite a lot of this and that actually. The bullet points are probably easier:

  • Testing REST APIs written in Java using Spring Boot (with Apache Camel and some other stuff)
  • Using the RestAssured library
  • With a builder pattern that utilises POJOs
  • To allow requests and responses to be built quickly
  • And run first in a Docker environment
  • To prove that the deployed WebSphere Liberty artifacts work
  • Before being pulled from GitHub by Jenkins
  • Where the code then enters the CI pipeline
  • If everything is successful on that Git branch the code is merged to a develop build
  • Which is then merged to release every week or so
  • Both dev and release branches are pushed to Artifactory

That’s kinda it, though it doesn’t really show the complexity of the development approach. We have a shitload of APIs in production, more in development, and they integrate with one another to greater or lesser extents.

The vast majority of our testing is automated, both by developers and testers. We write three layers of tests:

  • Unit – self-explanatory, tests a unit of code
  • Component – tests that exercise different components of the code in conjunction with one another
  • Black box – tests that prove contracts between different functional layers e.g. Between the service layer and a database

If the API integrates with other APIs or with backend legacy systems (and there are a lot of those) then a tester or developer will also write integration tests that exercises the contract between the two (or more) systems. These can range from pretty simple to quite complex depending on the functionality we want to check. Remember that these tests are primarily change indicators. The aim isn’t to excercise every feature and hit every permutation – this should have already been done at a lower level. The aim is to ensure that all of our assumptions about the interfacing system were correct.

The final element of testing is exploratory. Testers are encouraged to play around with the feature in an attempt to find unintended consequences. This step is a lot of fun, although I’ll admit that doing this in an environment where you’re encouraged to find automated means of improving your testing adds to the fun element. Utilising an existing automated framework to further explore a product helps speed up the process.

On top of this is performance testing, security testing, TVT and BVT – all carried out by specialist team members. We carry out some basic SIT testing after the war is deployed to ensure everything plays nice, but the aim is to test as much as we can at lower levels where it’s far less expensive (time, code, execution, money, whatever).

The approach we’re using focuses heavily on agility. We have a few things that we do for every epic:

  • Product inception – what we’re building, the value of it and how we’re going to build it
  • Two week sprints
  • Sprint planning sessions before each sprint
  • A kickoff for each card and a subsequent walk through at the completion of development
  • Fortnightly show cases – “We built this cool stuff” sessions for anyone interested

Does that sound like a lot of meetings? It’s really not. The team I work in is made up of three developers, a BA and a delivery lead.

  • We practice rapid inceptions; they combine architectural discussion, acceptance criteria determination, complexity evaluation (from which we derive points) and feature ordering, where we decide which features need to be built first
  • Two weeks appears to be optimum for the moment, though we could probably move to a week if there was a need to. But there isn’t
  • Sprint planning essentially boils down to “Who wants to work on what first?”
  • Kickoffs are quick, if only because they usually involve a discussion on what’s going to be built and what kind of testing – and at which layer – we’ll need to use in order to prove that the code meets the acceptance criteria of the card. If there is too little agreement on what’s going to be built, or the acceptance criteria are not clear, we can bounce the card into the backlog or have a more robust chat with our BA
  • Showcases are pretty good fun – we’re finding new ways to make them more entertaining. Plus, they involve beer and snack so, winning

There’re more than 70 people working on the service engine platform (as NAB likes to call it) and that doesn’t include the teams that make up development for our biggest consumer, the mobile development team. Most of the delivery teams are of a similar size and ratio and there are eight (nine?) teams carrying out work on the service engines. We’re growing to the point where we’re starting to adopt a nomenclature and structure similar to the one Spotify use.

In short, I’m having a LOT of fun. I get to work with great people every day, helping to solve complex problems in a supportive, highly technical and above all interesting environment.



It’s not software, but it’s my blog, so fuck it…

I do a bit of photography in my spare time (some of it’s here) and one of the things I’d like to do more of is astrophotography. Unfortunately, finding clear skies uncluttered by city lights is somewhat tricky where I live and usually involves a fair bit of driving.

If you want to shoot the stars but don’t know where to start, you can’t go past Lonely Speck’s guide.


On new things

Sometimes I find it hard to believe I’ve managed to land myself in a job where I get to learn something new every. Single. Fucking. Day.

If I was going to describe my dream job prior to this, I would’ve said something like this, maybe if I was lucky. But I always thought that “new things” was something you had to dole out, maybe get a couple a month.

But every day? This is pretty amazing.


There’s this image in my head

creative process

Yeah, that’s it.

It’s been a very long time since a job has had me alternating between “I don’t know what the fuck I’m doing” and “This stuff is fucking awesome!” so quickly.

But this place rocks :)


Two weeks with the Apple Watch

watch shot

It’s been over two weeks – 16 days actually – since I started wearing Apple’s latest piece of beautiful tech on my wrist. Has it changed my life? No. Has it made me realise just how bad my sedentary, day-at-the-desk working life was getting? Absolutely. Has it turned me into a calorie counting, exercise biking, cross training, cardio fitness freak? LOL, fuck no.

What it has made me do though is take more of an interest in my health, something I didn’t really expect to get out of it.

High points:

  • Activity tracking. I’ve never been a fan of walking, except to get from point a to point b, but the visibility the watch gives me has prompted me to get out and walking more
  • Workout tracking. Kind of the same as above, but the watch allows you to track a period of walking, running, cycling, etc. with greater detail and gives you all the tools to track your progress over time
  • Notifications. I don’t have my phone out and on the table, desk, whatever as much as I used to. I can check MMS, email, and screen incoming phone calls without ever taking my phone out of my pocket
  • Battery life. Yeah, weird I know, but it’s nearly midnight, I’ve had the thing on my wrist all day from 7am onwards and the battery just dipped below 50%. It tracks my steps taken and my heart rate on a constant basis, I send and receive texts from it, and the battery life isn’t shit



BDD with JS

About 6 months ago when I started this job and I was trying to find my feet with a lot of unfamiliar tech, I came across this in my quest to get my head around BDD with CucumberJS. When I had no idea about JavaScript or much of an idea about how to do BDD well, it was all a bit much.

Now however it actually explains a lot of what I’m involved in. I’m using Chai instead of Mocha but the ideas are the same, just different syntax. Sometimes I wish we weren’t using Chai and rather had implemented something like Mocha or Jasmine but we didn’t because reasons. And those reasons were arrived at well before I got here.

Have a read if you’re stuck. I’m gradually coming around to the idea that JavaScript works really well when you’re testing JavaScript, in particular Angular with it’s asynchronous behaviour.


Spring things

Work has me doing a lot of stuff with REST services developed using the Spring framework. We’re using REST Assured to do the testing of the services even before we get a UI layered on top so I’ve been learning quite a bit.

I’ve heard that some of the best advice others have received for learning to code has been to find a problem and work out how to solve it with the code you’re learning. I have a specific problem I want to solve and my initial thought was to do so using Javascript (hence earlier posts on the subject). This however promised to be far more complex than needed. That’s where REST services come in.

Spring provide a handy set of guides and seems to be a nice, out of the box solution to all your RESTful needs. Granted, I don’t know if it’s the best solution to my problem., but it’s something I work with day to day and I’m familiar with it. I’ll use Gradle to build the project (because omfg it’s so much better than maven) and then layer on a front end once I can get the service playing back and storing data.


My git cheat sheet

I wrote this while I was getting the hang of using git in my current role. Over time I’ve added to it but to be honest, I rarely have to refer to it now.

If you’re wondering at the shorthand ‘g’ rather than ‘git’ it’s because I use oh-my-zsh with the git plugin (the dev VM I use at work runs Ubuntu and it also plays nice with OS X. Windows users can suck it). You can get a similar result by aliasing git commands.

Initial Setup

g clone
g pull

If you don’t know those two, stop reading now.



Handy Sublime Text addons

You need to be a bit careful with these as adding lots of them can really slow Sublime Text down.

I found this list of handy addons while looking around for a way to get grunt running from within ST. It starts off with installing the excellent Package Control which makes installing and managing addon packages sooooo much easier. Trust me on this. I found it only after an annoying process of manually installing an addon. With Package Control those days are gone for good.

Now that was a weird sentence to write.


Git Guide

Handy guide full of Git goodness.

If you’ve never used Git before, this is a great intro. Codeschool runs a course where you can try git out if you want to learn some basics.