Friday, 31 January 2014

London Code Dojo 30

Monday was London Code Dojo 30 and this time we were back in Barbican with the lovely people at valtech

WHAT WENT DOWN

The kata for the evening was based upon Fibonacci numbers... but with a twist! The problem was centred around Fibonaccimal Numbers (link) which use the Fibonacci numbers as a base for representing numbers. So taking 1, 2,3,5 and 8 as a base, we can represent 9 as 10001 or 01101. As you can see, some numbers can have multiple representations and this added to the complexity of the problem. For the majority of the evening I paired with Rob and I found it really valuable getting his insight into the problem! The code we produced for the night can be found here: https://github.com/arkangelofkaos/CodeDojo30_Fibonacci

MY IMPRESSIONS

Nothing beats a good plan

More so then anything else, I came to appreciate the value of having a solid plan. Having a high level design which everyone agrees will solve the problem is incredibly important. Test driving code doesn't magically produce well designed algorithms.


LESSONS LEARNT

Decompose complexity into simple functions

Functional concepts supplement object oriented coding in a fantastically seamless way. When dealing with collections or calculations it is surprising how  higher order functions like map and reduce translate to how you naturally think about the problems.

For instance, to produce all the Fibonaccimal representations of a number, you can use a two step process:
  1. Find all unique ways to express that number as a sum of different Fibonacci numbers 
    • For example: 3 is [3] and [2+1]
  2. Translate each way into the corresponding Fibonaccimal 
    • [3] is 100 and [2+1] is 011
These steps are both mapping a number to a list of lists, then each list to a String. This is reflected in the code below:
return sumsCalculator.fibonacciSumsFor(number) // Step 1
                             .parallelStream()
                             .map(toStringCalculator::fibonacciSumToString); // Step 2

Suddenly I've decomposed an abstract problem into two concrete functions which I understand and can test drive!

Perhaps this is the crux behind solving all problems. Reduce the complexity until the solution is series of simple steps. Needless to say, making things simple is not simple... But there in lies the rub :)

Monday, 20 January 2014

Skimmer's Guide - Head First Design Patterns - Introduction

“Our goal was to make the book weigh less than the person reading it... Our focus is on the core patterns that matter...”

FOREWORD

I've recently started reading this book along with a few others in the LJC Book Club. As we read the book, I will be producing a series of Skimmer's Guide posts for each significant section of the book. Introduction to Design Patterns, the next section, is here. If you are interested, please join the discussion on our Google+ community

WHAT IS THE ABOUT? 

We start our reading of Head First Design Patterns with a gentle and enlightening introduction to the Head First world. Their approach is really intriguing and it is refreshing how much they are vested in helping the reader learn. Everything is to the point and we are immediately told who this book is and isn't for. Our goal in reading this book is stately clearly: learning that design patters are all about reusing experience and creating flexible code.

Despite the daunting size of this book (it is very heavy), the writing style and format makes it very easy and enjoyable to read. If you have experience with Head First books in the past, the introduction could be skipped although I highly recommend giving it a quick skim in the least.

WHAT STOOD OUT? 

Taster - Table of contents
Surprisingly enough, the novel table of contents work really well as a taster for things to come. Much like the rest of the book, the entertaining writing style brings the book to life :)

IF YOU READ NOTHING ELSE... 

Tricking your brain into retaining knowledge
One of the very first concepts covered in the book, this is the art of learning how to best learn. Absolute must read as the techniques covered are applicable to learning in all walks fo life.

CONCLUSION

Beginning to read this book has been a wonderful foray into the Head First world and has whetted my appetite for more. Looking forward to sinking my teeth into the world of design patterns in the next part :D

Wednesday, 4 December 2013

London Code Dojo 29

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

WHAT WENT DOWN

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: https://github.com/arkangelofkaos/CodeDojo29_RockScissorsPaper

MY IMPRESSIONS

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.


LESSONS LEARNT

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