5 Things I've learnt being a scrum master

I've been a scrum master now for about 6 months. Having been involved in scrum previously as a product owner, as well as a developer, moving into this role has really opened my eyes to some of the more political and arguably awkward elements of trying to get rid of impediments.

Stay calm when others aren't 

Something that I think is really key about being a scrum master, you have to be thick skinned. You have to not only push back, but when people whine at you and bring office politics into play, it's vital that you remember exactly what the end game is, to meet the sprint goal!  

I should also point out, this doesn't mean ruling with an iron fist, as a scrum master, you still succeed with the team and fail with the team.  You can tell when something isn't working and using an agile methodology shouldn't be a painful process, it should be motivating.

You are neither a manager, nor just a developer

It's quite an interesting position to be in as from my experience, it's not unrealistic to get your hands dirty in some code while being a scrum master.  You have to be strong enough to fend people off from poaching your team members even if they're higher up the food chain to yourself.  You aren't "in charge" of the team, but you do have a responsibility to push back on poachers.

Don't be afraid to say "no"

If your product owner is telling you to put 60 points into a sprint, when you know the velocity you've been hitting for the past 4 sprints has consistently been 40 points, don't be afraid to say "what you're asking is unattainable".  It's much better to be honest early on and push back.  Blindly saying yes, promising to the customer and then having to deal with the consequences later on isn't where anyone wants to be.

Make sure stand ups are to the point

This might be like telling grandma to suck eggs, but it's vital that stand ups really are short, sharp and to the point.  There's nothing worse than listening to a stand up where everyone in the back of their mind is thinking "I wish s/he'd just get to the point!".  This is a situation where you have to stick to your guns and if people get offended, they get offended.  You have to tell the person, "we don't need to know any of the extra detail, we just need to know from a high level; what it is you're going to achieve today, did you achieve what you set out to do yesterday and importantly, do you have any impediments".

Keep things moving

Sometimes things in a sprint can get stale, tasks can get stuck in one condition, you need to keep them moving!  As an example, If there's a task that's been coded for half a day but not released to testing, find out why.  You never know, the CI server might be down, there might be a problem releasing, you need to get it out before it becomes an impediment.  Keeping the task board fresh and a true representation of what's actually happening in your sprint can really boost morale if you know there's only a few tasks left and you're literally "sprinting" to the finish :)

Jax-RS custom exception handling

One of the nice things about working with JEE is the components available really are pretty standard.  While using JAX-RS, sometimes you need to control how exceptions get processed and fed back to the user.  If an exception is thrown, by default, you'll get some horrible HTTP 500 internal server exception, exposing the internal failings of your web service.

Consider the following gist, this endpoint would be used to view a user based on the Id.

Now, the implementation of this interface would look something like the following, to do the donkey work of actually retrieving the user.

This looks fine, but consider if the userDao was doing some entity business logic, using Query.getSingleResult and the user with this ID didn't exist?

According to the JEE6 API documentation, you'd receive a NoResultException, which would cause an HTTP 500 error exposing your internal server exception, which is definitely something end users shouldn't see. We need to leverage the exception handling of Jax-RS!

First, we need a dumb exception object, appropriately named, which will be what we'll actually throw, consider the code below..

Next, we need to modify our original code to take into account this exception, I've modified the original UserWebService and associated implementation appropriately below.

This will now throw an appropriate exception when a user cannot be found. However, we still need to create a Handler object to convert this exception into an actual JSON response so we get a nice friendly error message. The class below handles this exception and will convert the error message in the exception into a JSON response. The important annotation you'll see on this class is the @Provider annotation.

You'll notice we create an ErrorMessage object to respond to from the web service. This is just a simple dumb object to hold the details of the actual error that'll be marshalled into JSON.

The final step in mapping our exception handler provider to the web-app is to add the following into our web.xml for our webapp.

Now when we call this REST endpoint with a user ID that doesn't exist (let's say "DAG"), we'll happily receive the following JSON response rather than a stacktrace.

Stripping Java string SQL statements automatically

Do you ever get sick of typing out an SQL statement in Java with all the String syntax?

Then, when the statement doesn't work, you have to copy it back into pure SQL to run it to check it works?

This was a pretty common problem for me, so I made a simple syntax stripper http://idavid.co.uk/sqlstripper/ so I could quickly covert from SQL into a Java string and back again.  Consider the following Java String...

String query = "SELECT * " +
"   FROM USERS u" +

"INNER JOIN CODE cd ON cd.userid = u.id " +
"WHERE u.id in ('1','2') ";

This would parse fine if it was being sent into stmt.executeQuery(query)

But it I wanted to run this on SQL server just to see what it produced, I'd have to manually remove all the syntax etc to make it run and generate the following SQL.

SELECT *
FROM USERS u
INNER JOIN CODE cd ON cd.userid = u.id
WHERE u.id in ('1','2')

This is exactly what my SQL stripper does.  It also gives you the ability to paste in an SQL statement into the right hand textbox and convert it into a nicely formatted Java String, so converting the SQL statement above would give...

"SELECT *"
+ " FROM USERS u"
+ " INNER JOIN CODE cd ON cd.userid = u.id"
+ " WHERE u.id in ('1','2')";

Tomcat deployment script

So this weekend I deployed http://www.playerviewer.com (shameless attempt at self promotion!).  I've spent a lot of time with EC2 on Sonar / Jenkins boxes, but never deployed over Tomcat on it in production other than small tests.

One thing I found during the inital deployment that really started to be a constant theme...

stop tomcat, download war, delete old war folder, move war, start tomcat.

This started to become a pain, so I ended up just using a shell script.


So the maven process in my pom is to move my war to a directory, that then gets uploaded to http://www.mysite.com/deploy/ROOT.war and my shell script does the rest.
There are probably much nicer ways to do this such as using ant to ftp the script to the location for the shell script to download it, but it's not really that important.
Also - all the code from player viewer is available open source here

Is private encapsulation always secure?

Suppose you make a method private in Java, experience tells us this is bread and butter stuff and only methods inside this class can access the private methods.  However, in the following example I'll show how setting methods as private isn't always safe.

From here, we can see if we had an instantiated User object, we could just call user.getFirstName(); However - what if we wanted to get the password?  We can use reflection to access this private method.

This is where the Method object in the Java.lang.reflect package is useful.  If I was to reflect this method back into an object, I'm able to set the accessibility of this object.

The accessibility method call is important as it will turn off any encapsulation checks on this method invocation.  We can then simply invoke this method as shown below to result in the password being printed out.


This is one of the many reasons why storing your passwords in plain text in a compiled object, even if you make the methods private, is dangerous.

Hibernate exception timings vs SELECT COUNT(*) to check entity existance

This is something that I've been curious about for some time.  How much faster really is it to throw an exception rather than doing a SELECT COUNT(*) to check if an entity exists?

My initial suspicions are that the SELECT COUNT(*) would in fact be slower due to the database transactions.  However, the time to build up the exception stack for the NoEntityFound is no small fate either.  It's also worth considering if the numbers fluctuate based on the amount of data within the table at that point?

Obviously, the analysis could get much more complicated and it's not my intention to go into the realms of indexes / partitioning / whether the entity is presenting a view of two tables / hibernate caching.  It's more a general curiosity.

So lets begin, here's my entity..


Now I'm going to use an extremely simple HibernateUtil class to get me the session, shown below.


To fire the exception, I'm going to use the .load() method from org.hibernate.Session. I'll also run the following code to see how checking the SELECT COUNT(*) would take...

Here are the results! Using the load method, with the given entity above this takes 1328 milliseconds. SELECT COUNT(*) came in last with 1454 milliseconds, all hail load!
Now something that does seem important is as both methods were pretty dam close, which one is more readable? To be honest, the load does just seem to make sense and catch the exception but you could easily argue exceptions shouldn't control the flow of your application if you're checking existence of an object. Currently, I have 608 entries in the table that the Player entity is hooked up to. Below are the results for the different times.

.load()	SELECT COUNT(*)	number of values in table
1249	1343	1084
1344	1332	2084
1288	1409	51228
1276	1270	104814

What we can see from the results above, interestingly is the amount of data in the table, has pretty much no resemblance to the time either query takes to run.

Parsing ESPN API using Java and Google GSON

For my first post, I'll explain how to parse the ESPN API.  The API documentation can be found at http://developer.espn.com/docs.

Firstly, you'll need to request an API key, then you can start querying the REST API to retrieve the JSON response.  In the following example, I'm going to query simply for all the players in the sport of "Soccer" (dam that Americanism )  that play in the Premier League in England.

From reading the documentation, this is the URL that I need to send requests to (with [apiKey] replaced with the correct value).

http://api.espn.com/v1/sports/soccer/eng.1/athletes?apikey=[apiKey]

Something to bear in mind first of all, there's an offset value that forces you to make multiple queries if you want more than just the 50 results, this is set with a parameter known as offset.  So for instance, to get the results from 51-101 the following query would pull these back.  We'll come back to this later as this can cause some slight issues.

http://api.espn.com/v1/sports/soccer/eng.1/athletes?apikey=[apiKey]&offset=51

Now I've got the description out the way, I'll start the code, it should be noted I'm using GSON to parse the JSON so you'll need to add the following Maven dependency.

Once this has been done and you've ran the maven:install to get the jars downloaded, you can start querying. The code below is simply required to download the JSON from the ESPN API


Now we can start parsing this JSON, because the JSON produced has a lot of redundant data, I decided against parsing it into objects and just queried it raw. This will give us a JsonArray of Athletes and the associated data that can be pulled about them. It should be noted as this point, the response here varies based on your API allowance (free, partner, paid etc). I'll leave the relevant ESPN API page here http://developer.espn.com/docs/athletes#parameters.
Now, as we've got the relevant JsonArray we want, we can just loop through it to return the data about each player. It should be noted a couple of things that may look odd about this code. Firstly, the reason for the sleep is because the API has a limit of how many times a second you can call it, currently as I write this for free you're limited to once every 3 seconds. Secondly, the reason it's in a loop of 650 is to do with the offset I referenced earlier in this post. This means you need to query each 50 players, this seems a little computationally expensive as I'd have thought it'd be easier just to return the 602 players rather than having to do the heavy loading of receiving 12 RESTful calls.
Then, when we put this all together you get the class below, this will loop through every player giving you their first name.
You can download the full project on github https://github.com/david99world/EspnApiParsingExample