Thursday, 29 August 2013

London Software Craftsmanship - Robot Tournament

To usher in the new format for LSCC Hands On Sessions we had an all evening session at the Google Campus!


The kata of the night was a straightforward implementation of a TicTacToe robot. The driving principles behind the night were around releasing early and regularly. At the end of each 5 minute round, each pair's robot would play all other robots. Along with doing TDD, this all meant we got fast feedback on how well our code/strategy was performing :)

I was lucky enough to pair with Sandro and it was really interesting working with him! I've forked the original repository and upgraded the code to use Java 8 Lambdas here:


Listening to feedback is invaluable

Actually paying attention to feedback is incredibly important. There were loads of problems with our Java 6/7 setup which regular and quick releases highlighted. Sadly we didn't pay more attention to the problem and we could have solved it sooner!

Focus on value

Whenever you are doing any coding, it is very important to understand why you are doing things and how you can measure the benefit. Software development is very intangible but it is our duty as software craftsman to deliver tangible value!


Design upfront!
I think from now on I'm going to practice the Green Cross Code everything I under take a kata: 

  1. Stop - Think about the problem and check your understanding with your pair.
  2. Look - See if the problem has been solved or has a simple solution.
  3. Listen - Discuss ideas for how to tackle the problem and agree a path only after listening!
  4. Go - Write your first test! :P
A quick sketch of things never hurts either!

Rushing gets you nowhere fast

As the anti-thesis of the above, blindly rushing in "Leeeeroy" style really isn't beneficial at all, especially when time is tight!

Friday, 23 August 2013

Lambdas: Myths & Mistakes

This evening I went along to SkillsMatter to watch Richard Warbuton give his talk "Lambdas: Myths and Mistakes"


  • Always good to have humour in the presentation
  • Great to invoke audience participation
  • Awesome to have well formatted and properly colour coded code
  • Too many "umms" throughout, will be improved with practice.
    • Particularly noticeable when demo'ing the conversion to lambdas for the first time.
  • Perhaps the jump from external iteration to internal iteration was too fast?
    • Speak a little about streams first?
    • However it was good to see a worked example straight away
  • During some parts of the talk, around myths, there seemed a lack of "relevance"
    • Not knowing which section a slide was part of was an issue. ("Is this still related to Myths?")
    • Namely when you were talking about "Differences between expectations"
  • You mentioned "Boxed primitive error messages" for streams(?). Would be better to show people rather than just telling them.
  • Throughout the slides kept being changed accidentally, be wary of this as it can be jarring.
  • When showing a visual example, try to keep the following code example the same.
    • Don't add 1 to 4 visually and then suddenly count numbers in code.
  • You mentioned "simply using .forEach() isn't great", perhaps show a quick example of "a better method".
  • Going through the "count all occurrences in a book" kata. Don't just show the code solution, first talk through the semantics in plain English!
    • Similarly going backwards and forwards across the messed up half solution isn't so valuable.
  • Overall the content was fantastic and pitched at a good level.


  • This talk has left me really hungry to start using Streams and Collectors in anger.
  • Visualising all these abstract concepts really seems like the way to go!

Thursday, 15 August 2013

Are you better than a Coin Toss?

This evening I went along to SkillsMatter to watch Richard Warbuton and John Oliver give their talk "Are you better than a Coin Toss?"


  • Having a backup for the presentation platform (i.e. second laptop/iPad) is tantamount!
  • Test your presentation beforehand! Fail fast!
  • Keep water to hand, fizzy drinks don't help.
  • Always good to adapt (i.e. basic introduction to buy boot up time)
  • Er's & Um's distracting
    • Use a pause before speaking to build confidence and removes need to think mid-flow.
    • This goes away with practice
  • Great to use examples away from the core field (like Moneyball)
  • Generally great to illustrate points with concrete examples
  • Beware of standing in front of the slides and blocking them!
  • Try to speak slowly, looking for cues that your audience has understood you.
  • Great to have humour intermixed into the presentation!
  • Good to reaffirm each others points.
  • P-value diagram didn't really help to illustrate the point to those who don't know about it, try something more universal? Dartboard with % probabilities of hit area?
  • Beware naming things part 1, 2, 3… because it can lead to "we are only on part 2?!" syndrome
  • Avoid reading off slides directly
    • You say what you need to, the slide should only illustrate your point
  • Throughout it felt like a few different slides or an animation could have better illustrated the point
    • On the clustering slide, show actual clusters and why they are good/bad
    • On the elbow slide, show a few elbows and highlight your point
    • Good example is the over/underfitting, the pictures made the point perfectly!


  • Producing useful data analytics is really hard.
  • Using hard data analysis techniques is better than using subjective expert opinions.
    • Science FTW!!!
  • Without concrete and unbiased measurements, algorithms may be not better than randomness.
  • Holy cow how much work does jClarity do with their mad polygot skills!?

Wednesday, 14 August 2013

London Code Dojo 25

Monday was London Code Dojo 25 and it returned to the City, hosted by Maker's Academy I think we all had a really productive dojo!


The kata for the night was "Roman Numerals", implementing a parser which could convert "modern" Roman numerals into their actual Arabic number. The important rule was that only 1 smaller numeral could precede a larger one. Hence IV is valid as 4 but IIV isn't valid for trying to represent 3. 

Overall it was a really interesting and education evening! I paired with Mani for two pomodoros and Damien for the last one, code up here:


Go slow to go fast

When doing TDD, going slowly can help you avoid edge cases later. When we came to implementing "subtracting" numerals, like what you have in IV, Mani pointed out it was "a jump too far". We hadn't implemented V yet and the code could do with a refactor once it was. Overall I think doing the two steps was faster and safer than doing it all in one step.

Tests are code as well!

This is a mantra to follow and appreciate. Our test cases could really have benefitted from using parameterised tests. <LINK?> Learning to use this and keeping to it is definitely a goal for me now :)


Simple is beautiful
The Romans Numeral Kata is very simple and straightforward, which lends itself all the more to practising TDD like you mean it. Even though implementing a solution is trivial, the trick comes in keeping things simple and elegant!

Think Functional!

These dojos allow practice that we normally couldn't get otherwise, practice with Java 8 and Lambdas for example. Parsing Roman numerals is actually a problem which maps well to functional programming ;) Pseudo code reads like English: "turn all numerals into values, negate the ones that precede a higher value, sum them all together". Not sure how to do the second step in Java… yet! XD

Saturday, 10 August 2013

Betterrev - A Better Webrev

One night after the GS Collections talk, I was speaking to Martijn and the conversation touched upon Betterrev, an Open Source project he was working on. Keen to repay Martijn for supporting the LJC Book Club and putting on an awesome DevOxxUK Conference, I offered my assistance.

Before I knew it, I was a member of the AdoptOpenJDK Bitbucket team and told to meet at the jClarity office the following week to do some hacking! Having only dabbled in Open Source before, it was both daunting and really exciting to be diving straight in. However ever since then I've been learning bucket loads and this post will recount many new discoveries xD

What IS Betterrev?

"A friendly, hosted wrapper around webrevs"

In layman terms, Betterrev is going to be a website for managing changes on the OpenJDK project. Currently developers have to use the Webrev tool for generating a report on their changes and submit it manually to the right people. To make a "Better Webrev" which automates a lot of this work, Martijn and others in the AdoptOpenJDK group started Betterrev :)

Currently the goal is to have an alpha version running before Java One. This version would automatically detect Pull Requests against the Bitbucket OpenJDK repositories and generate Webrevs against the Oracle OpenJDK repositories. 

These "webrevs" would then be wrapped up into "Pull Reviews" in Betterrev, which has an automatically managed lifecycle. This gives everyone involved the ability to:
  • Automatically inform the correct people when a change requires their attention.
  • Analyse, in one place, all the different changes and their statuses.
  • Automatically be informed of completion/rejection of changes.
All in all, this will be another step to making improvements to Java quicker and easier to do! :)

Getting Used to git

Having never used Git properly with multiple developers before, I had to get rapidly up to speed with foreign concepts such as "upstream" and generating "pull requests". Luckily I had many people to learn off, my thanks to Kaushal and Mani for all their assistance!

The main concepts I got my head around were:

Forking - Creating & Maintaining

Creating a fork really is as simple as clicking a button on the BitBucket/GitHub. The trick I missed is that to maintain your fork, you need to keep "pulling" changes from the original repo. This can be as simple as adding a new "upstream" remote:

git remote add upstream

To update yourself with the latest changes, simply execute a pull on upstream. Within IntelliJ, this can be triggered with ease. Doing it inside IntelliJ also has the added advantage of letting you use a GUI to manage any potential merge conflicts! :D Once you are happy with it, you can push the changes back to your origin repo on GitHub/BitBucket.

Pull Requests

When you want to get your changes accepted back into the repository you forked, you can generate a Pull Request containing your changes. What is really interesting is how easy they are to create and manage!

Other users may comment on your Pull Request and suggest changes. Should you act on these changes and commit amendments, BitBucket automagically detects them and offers to merge them into your Pull Request! This is freaking awesome! XD

Code reviews - teasing out laziness

On the subject of code reviews, it is awesome working in an environment brimming with technical talent. Being able to get expert feedback on your code is truly invaluable.

Nigel once said to me: "pairing doesn't make you twice as smart, it makes you half as dumb!" Similarly I've found that code reviews make you half as lazy. Late one night I got a bit too happy copy and pasting things in CSS. Come the next code review Martijn called this out and simply commented: "the C is for cascade" ;)

Things like are seemingly minor but very important to catch and call out. Technical debt always finds a way of ruining your day!

Whiteboard to reality

One aspect I found really rewarding was rapidly turning whiteboard drawings into a real running prototype!

Whiteboard Brainstorming & Initial Sketch

Locally running implementation

Given that there isn't really that much there but the sense of accomplishment was neat :)

Playing with bootstrap

Putting that screen all together required me to learn a few new things. Twitter Bootstrap is a nifty tool but I found out there isn't really a "box" tool. Those grey borders had to be manually hacked together with CSS old school style. However learning about the 12 column grid and glyphicons was kool though :)

On the logic/serverside, there was lots to learn in the Play 2 framework. Using Scala within HTML Templates was very novel, Scala code is pleasant and straightforward, if not a little foreign!

Next steps

So now it is just a question of investing more time and helping out where possible!

London Code Dojo 24

Another belated summary, this time of London Code Dojo 24 and with it came a welcome return to the regular format.


This time we were all the way out in Richmond as eBay were kindly hosting us in their office canteen (hurray for free cans of soft drink). The kata for the night was simply to implement the Binary Search algorithm, which I realised I am very rusty at! >.<

The code I paired out with Santa is available here:


Communication is an art
Working and interacting with new people is still very much a challenge for me. I find that I either click straight away with a person or it just feels awkward. Perhaps I should attend the communication dojo in future too!

Teaching is a must have skill
More and more I am finding that I can impart what little wisdom I may have on certain subjects to others! Learning how to effectively teach others is tantamount in the list of skills every developer should have. Something important to keep in mind for parenting as well!!! >.<


Look before you leap
As always, I seem to be reacting to things rather than responding to them. In this kata I ploughed ahead without thinking hard enough about the algorithm or how the steps we were implementing would lead to the solution... This is converse to the sorting kata where we mindlessly copied the QuickSort algorithm. So I suppose the lesson is to plan upfront a little more and to take small educational steps!

How it is done is more important than having it done

I've come to the realisation that I'm still too hung up on "getting things done". In these code dojos, it really doesn't matter if you don't finish ANY of the exercise! The most important thing is to practice how you would do it perfectly. This means that it is absolutely fine to spend time simply clarifying the problem and sketching out a solution, that way everyone knows what is happening!

London Code Dojo 23

A belated summary of London Code Dojo 23 which centred around learning how to use Meteor.

What Went Down

This didn't really follow the traditional format of the London Code Dojo as we were focussing on a single technology and we weren't doing TDD! *shock horror*

Meteor is a new and exciting JavaScript framework for creating web application ridiculously fast. There are some very powerful concepts in there and we were introduced to them through enhancing the Leaderboard example.

I was lucky enough to "pair" with Ole and Dave and the code we hacked out is available here:

My Impressions

The learning curve is brutal
Throughout the night, we kept running into brick walls due to some completely foreign pieces of knowledge you have to have. Meteor is apparently tied quite closely to a MongoDB under the covers, so if you don't know Mongo at all, you are stuffed! Trying to wrap your head around the general data interaction isn't trivial either.

JavaScript is still hard to work with
Having gotten very used to IntelliJ and all the magical help it offers you with Java, using JavaScript still feels really painful. No doubt it is a lack of knowledge on the available tools out there but to me JavaScript still falls down with regards to IDEs and proper debugging tools...

Lessons Learnt

Meteor can deliver feedback fast
The main selling point on Meteor is the sheer speed with which you can develop. Once you have the program running, you can see your code changes take effect in the browser right away. There is no refresh necessary! For simple web applications that you need to throw together quickly for a proof of concept, Meteor is your best bet!

JavaScript is evolving rapidly
With the emergence of so much new and exciting stuff in the JavaScript world, there is a lot to get excited about. AngularJS, Yeoman and Meteor are shining examples of this and I look forward to seeing more great stuff to come :)

Tuesday, 6 August 2013

The Darker Side Of Software Metrics

Tonight I went to go see @sleepyfox give a presentation on software metrics which was renamed at the last minute to "The Darker Side Of Software Metrics".

To summarise, the talk was very much on how software metrics can not only be useless but actually detrimental in software development. Many random pieces of wisdom were dolled out and overall the talk was very amusing and informative.

The recording of the video is in fact already available here, many thanks to the awesome people of Skills Matter!


  • Highly enjoyed the comical style, good comedy is always welcome in a presentation!
  • Great to encourage audience interaction and engagement
    • Be wary one person doesn't dominant this though
  • Some of the jokes may have been either too estorectic or given without context.
    • Perhaps frame jokes so they highlight a point better?
  • Talk lacked structure (from being unfinished), it was hard to follow the overall point on some slides.
    • Perhaps use more "sign-posting" to guide the audience
    • Have clearer overall message before introducing a bunch of quotes/slides?


  • My most important takeaway was the emphasis on how no metrics can ever help you predict the future.
  • Software estimation for this purpose is therefore implied to be futile.
    • The question then is "how do you then hit time requirements for projects?"
  • One of the quotes said "Plans are worthless, but planning is everything."
    • Similarly, perhaps: "Metrics are useless but measuring is everything."