Wednesday, 4 December 2013

London Code Dojo 29

Monday was London Code Dojo 29 and this time we were in Shoreditch in office. Not the most productive dojo but I learnt some philosophical lessons about myself and my code!


The kata for the night was "Rock Scissors Paper" but this time there was a twist in that we had to implement HTTP servers to play the game. The idea was that you would have two "player" servers which responded to requests with a move. On top of this you would have a "referee" server presiding over a game and deciding who won.

The specification was a little bit vague beyond this and we wasted a fair amount of time getting to grips with the problem. Overall I felt the added complexity of dealing with HTTP hindered the learning experience. I paired with Ian and what code we did manage to produce is here:


Understand the scope of the problem

Getting a grasp of the problem at hand is incredibly hard in almost any situation beyond the very simple. Accepting the fact that you are unsure on how to proceed and having an "iteration zero" for setup and learning is invaluable. On the flip side this needs to be balanced with over-designing the problem...

Dealing with new technology REALLY slows you down

I have rarely dealt with writing RESTful services in Java from scratch and approaching the problem was difficult. I reckon we lost a good half an hour getting our heads around whether we had to deal with HTTP errors and what level of testing to start with.


Discover a solution with small steps
When pairing with someone new, even if you are both used to approaching a problem top-down with overarching integration tests, it can be more productive to take some small steps to begin with. This way you can get used to each other's TDD quirks and flesh out any misunderstandings. 

Focus hard on learning

As with most things, it can be very easy to get caught up in what you are doing and lose sight of why you are doing it. In dojo's I am still far too focussed in the problems and not thinking hard enough on good practice. Perhaps next time I will make a plan for how I am going to learn and see if I can strictly stick to it...

Saturday, 14 September 2013

Uncle Bob: Demanding Software Professionalism

On Thursday I had the pleasure of seeing Uncle Bob for the first first time at his talk: Demanding Software Professionalism.

Previously I had only heard the legends about this man, never making the conscious effort to read/watch more about him. This meant hearing him talking about his beliefs and ideals firsthand was both novel and humbling.

The premise for the talk was all around how software engineers should be expected to be more professional. As is the norm with Software Craftsmanship, this isn't through pushing methodologies but sharing ideologies. We should all believe in a steady work rate, never shipping s*%t and being highly flexible to change (amongst other things!)

Combined with the LSCC Roundtable the night before, I really felt inspired to "be better". At the end of the event, I picked up a coding challenge. I completed the work, trying hard to keep in mind Simple Design and strictly following TDD.

I've toyed with the idea of trying to make it more complicated with sophisticated error handling and introducing some functional programming to the mix. However the concept of "less code is better code" has hit home and I'm happy with it.

Feedback is definitely welcome and would be much appreciated!

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." 

Sunday, 21 July 2013

Skimmer's Guide - Functional Programming for Java Developers

“Multithread programming requiring synchronised access to shared mutable state is the assembly language of concurrency.”


Dean Wapler brings to us "Functional Programming for Java Developers". Although two years old now, the book touches on concepts that are still highly relevant both today and upon the introduction of Lambdas to Java.

We begin with why functional programming is so important and look at actual techniques we can utilise. Immediately after we are encouraged to apply our learning in handy and thought provoking exercises. This format is followed in each of the following chapters and really helps to reinforce learning!

How we model our data and operate with it is the next focus, introducing the "functional power tools" that are filter, map and fold. Along with the following section on functional concurrency, these two form an incredible bounty of invaluable information.

Recapping on everything we have learnt, we look at how to improve our object orientated programming and where to go from here.


Declarative vs Imperative Programming (p. 7) 
Highlighting the key difference between functional and object-orientated programming using a well thought out factorial example.

The Actor Model (p. 41) 
Fantastic coverage of this concurrency tool which is short and sharp, very useful for beginners.


Why Functional Programming? (p. 1 - 5) 
Concise chapter on why Functional Programming actually matters.

Combinator Functions: The Collections Power Tools (p. 29) 
A brilliant section on tools that are crucial in any functional language: filter, map and fold. Covers both what these tools do and learning more through actually implementing them for a custom List data structure.


Whilst this book is a great introduction to the basics, it lacks any great depth. Published in 2011, the available functional programming tools of the time (such as GS Collections and Google Guava) are surprisingly absent.

In my view, what is lacking in depth is made up for by having such a broad coverage in only 72 pages. This book forms a good bridge for those starting with functional programming to take toward exploring specific topics/tools in greater depth.

Wednesday, 10 July 2013

Recycling Time

Inspired by Sandro Mancuso's Software Craftsmanship book.

"… I would but I don't have the time" 

How many times do we lie to ourselves with this line? We all waste time, in one form or another. However if we really wanted to, we could "recycle" time that is used up by other day-to-day things.

Commuting is a brilliant example of this. I spend half an hour every morning and evening travelling on the London Underground. Previously I would fill this by playing random Android games or reading manga. When I joined the LJC Book Club, suddenly I had to find time to read everyday. So now on my tube journey, instead of pulling out my phone, I pull out a book instead.

Other examples of times that could be recycled include:

  • While cooking/eating... 
  • While waiting for people to arrive to meetings, at the doctors, etc...
  • Over your lunch break at work 
  • Before/after your marathon gaming session ;) 

Having said all of this, it is important to note that everything should be done in moderation. We can't be productive every waking hour of every day! In fact, doing things to unwind is critical to our productivity.

If you are tickled by this idea, highly recommend you give Sandro's book a go!

Wednesday, 19 June 2013

Skimmer's Guide - Behaviour Driven Development with JavaScript

“BDD has many different aspects. Which of them are important depends on your perspective.”


Marco Emrich brings us a mature and enlightening insight into Behaviour Driven Development with JavaScript. Absolutely rammed full of excellent information, the book is nevertheless extremely well paced and reads very easily.

Beginning in earnest with a quick refresher on JavaScript, we are soon introduced to Jasmine, our JavaScript BDD weapon of choice ;) The underlying mechanics of BDD are explored (i.e. Red-Green-Refactor) before we are shown novel ways of generating data for our tests.

Particular attention is then spent on advising us how to organise/write our tests to maximise readability/maintainability. Following this we dive into Outside-In Development and how we can use it to flush out uncertainty. Use cases of the various types of 'test doubles' are covered, extensively so for mocks.

We finish by addressing the difficult question of "what is BDD?", bringing together everything we learnt into a formal methodology. The most important aspects are brought into focus and pointed in the direction of possible next steps into the BDD world.


JavaScript refresher (p. 7) 
Covering modern and functional aspects of JavaScript, this introductory chapter is incredible helpful for anyone rusty with JavaScript. Anyone experienced in JavaScript should probably simply skim/skip this though. 

Specs should be readable (p. 27) 
Great coverage of the DAMP/DRY principles here and throughout the chapter. Sound advice with warnings every developer should heed! 

Organising by feature or by fixture (p. 35) 
Interesting techniques for keeping tests cohesive and making them read naturally, through intelligent organisation and custom code tools. 

Using test doubles (p. 53) & Advantages and disadvantages of mocks (p. 61) 
Fantastic coverage on how and when to use dummy, stub and mock objects, including views on the pros and cons of mocking. 

Vocabulary (p. 61) 
A resonating account of the pitfalls of TDD for beginners and how an improved vocabulary better enables proper testing. 


Baby Steps (p. 23) 
Wonderful teaching on the importance of having a "tight feedback loop". Emphasis it placed on how the longer it takes to find a problem, the harder it is to solve it. Taking baby steps when changing code will let you go faster! 

Triangulation (p. 42) 
A wonderful technique for "faking it until you make it", forcing you to test all the relevant paths through your code. 

Gerkin language (p. 66) & Goals and benefits (p. 67) 
Covers the fabled "Given Then When" syntax of BDD and how it isn't necessarily central to BDD.


At less than £2.60 ($3.99) this book is insanely good value and I would highly recommend it to anyone starting to learn BDD, even if they have limited JS experience. Despite centring around JavaScript, the core concepts of BDD are covered magnificently and can be applied to any language. 

Highly accessible and easy to reference, this book definitely warrants inclusion on any developer's digital bookshelf.

Saturday, 1 June 2013

Epiphany Of Ignorance

As you can tell by the plethora of updates recently, I have been busy beavering away on various projects and interests. Recently some revelations have really struck home and I've come to realise the vastness of my own ignorance. Here is a random selection of them :)


Confidence, or the lack of it, has been a major issue for as long as I can remember. Recently I have been effectively devoid of it, for no real good reason. For this reason I really have to focus on getting back in touch with my own innate abilities. This means trusting in myself and striving to realise my real potential (thanks to Kenric, Barry and Matt for helping me see this)!


Fooling yourself is an easy thing to do though, I need to know my current limitations. As I learnt the hard way, cargo cultism can creep up on you without you even knowing it. My experience of TDD up to now was very much limited to using it as a tool for catching bugs and evolving established designs. When it comes to using Test Driven Design to rapidly build clean code out of uncertainty, my fundamentals just aren't quite polished enough yet (thanks to Sandro and the LSCC for enlightening me)!

Basic Mastery

Sweating the small things can actually be really important, in my case mastering the basics is fundamental to building a strong foundation. There are so many metaphors and allegories I could use for this, my favourite is from Bruce Lee:

"Before I learned the art, a punch was just a punch, and a kick, just a kick. After I learned the art, a punch was no longer a punch, a kick, no longer a kick. Now that I understand the art, a punch is just a punch and a kick is just a kick."

Right now I am still working hard on learning... One of the best lessons I have learnt so far goes hand in hand with mastering the basics and that is the "Single Responsibility Principle". This applies to so many things in life, it is better to be an expert at one thing than to do many things badly (many thanks to Ben and Martijn for showing me the light on all of this)!


Practice really does make perfect. Not just any practice though, you really have to practice perfection. Getting it wrong is fine but it is always important to remember practicing is not for getting it right, it is for never getting it wrong. For instance, you practice arithmetic so you can practice calculus without worrying you got the basics wrong (thanks to Nigel for this, may you guide me for years to come)!

Faster Feedback

Achieving a long-term goal isn't done by doing a long task over time and slogging it out. Fast feedback is critical. This means doing things successfully consists of doing smaller things which aim you the right way and more importantly can tell you if you are succeeding (thanks to Kevlin for sharing the time to inspire me, you're simply awesome)!

Tuesday, 28 May 2013

Finger Eleven - Them vs. You vs. Me

~ Sometimes so it reminds me… ~ 

Third studio album from Finger Eleven released in 2007, so I'm only 6 years late ;)

Unlike the previous two albums, which I listened to non-stop for 2 years of my life, this album doesn't have many songs I actually like enough to listen to regularly. The sound is still very much Finger Eleven though. My main gripe is that too many of the tracks don't settle on a melodic or heavy tempo which ends up spoiling them.

Anywho, three great songs that have made it into my regular playlist:

The opening track on the album, it has a steady beat that builds nicely and I enjoy the energy :)

I'll Keep Your Memory Vague
This is an absolutely beautiful song which is my favourite track of the album. It has a brilliant melodic quality and I find the lyrics to be poetic and really emotive.

Sense of a Spark
This track has a nice homage to Stay in Shadow and I like the neat little rift at the introduction.

Monday, 27 May 2013

Live Templates

One of my favourite features of IntelliJ is Live Templates because it enables me to be more productive and makes my work a lot more enjoyable. In this post I want to share with you:
  1. An introduction to Live Templates
  2. How it makes me more productive
  3. Why I really enjoy using them!

What are Live Templates?

In a nutshell, Live templates are short-cuts for writing code. They can be incredibly simple but are also very powerful, allowing developers to quickly and reliably produce commonly used code constructs (such as for loops, covered later).

[A more detailed explanation and documentation can be found here:]

To find Live Templates within IntelliJ, open up the Settings (Default shortcut: Ctrl + Alt + S)

Above you can see the setting window and some pre-defined Live Templates. So how do you actually use them?

Gaining productivity

Using Live Templates is incredibly simple and there are many pre-defined ones we can you right now. One of the best ones that everyone one can mostly likely benefit from is the "iter" or for-each Live Template.

Suppose we have the following code:

  1. Collection<String> listOfNames = getFriendNameList();  
  2. // I want to wish all my friends a Merry Christmas  
Figure 2.1 - Initial code

Normally the next step would be you would start typing out a for-each loop manually. However, what you can do instead is:

  1. Collection<String> listOfNames = getFriendNameList();  
  2. // I want to wish all my friends a Merry Christmas  
  3. iter // type out "iter"  
Figure 2.2 - About to use the for-each live template

Now hit the "Tab" key and...

Hey presto! IntelliJ has constructed a for-each loop for you using your Collection! Note that IntelliJ automatically highlights the collection and you can navigate up and down between multiple collection candidates.

Hitting enter will then allow you to rename your item variable:

Again IntelliJ jumps straight to the variable and you can give it a sensible name. Finally hitting enter will pop you inside the loop, ready for you to start coding:

Here I used the "sout" Live Template to quickly produce the println statement, try this yourself!

This is a really simple example but it highlights how you can use Live Templates to automate the mundane loop construction and launch straight into the important functionality xD

Sidestepping the mundane!

Sometimes a coding task can be pretty repetitive and typing out the same sort of code over and over gets pretty mundane pretty quickly. This is where custom Live Templates can come into play quite nicely!

Let's begin with a simple example, creating a Logger.

Above you can see my custom "logg" Live Template which does three things:

  1. Constructs a Logger variable called log.
  2. Automatically imports org.apache.log4j.Logger
  3. Detects what class I am in and places it in the constructor argument.

Firstly you can see that the code is simply a variable declaration, which is what is inserted when I type "logg" and hit Tab.

Note the fully qualified Logger classpath, this is so that IntelliJ knows to import the log4j Logger. You can see on the bottom right of Figure 3.1 that I have checked "Shorten FQ names" which means the produced code will only have the simple name.

Finally I have used a Template variable "$CLASS_NAME$" to insert the classname. This is done by the "Edit variables" button which pops up the "Edit Template Variables" dialog. You can see I used one of the built in functions to return the classname.

[Read more about Template variables here:]


Live templates are fantastic and enable developers to spend less time writing scaffolding code and more time focused on the actual business logic and functionality. Although I only really found out about them relatively recently, I have woven it into the way I work and enjoying them ever since :)

For all those that use IntelliJ but haven't tried out Live Templates, I hope I have pipped your interest!