Showing posts with label Code Dojo. Show all posts
Showing posts with label Code Dojo. Show all posts

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 :)

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

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!

WHAT WENT DOWN

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

MY IMPRESSIONS

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 :)


LESSONS LEARNT

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

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.


WHAT WENT DOWN

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

MY IMPRESSIONS

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


LESSONS LEARNT

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

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, 16 April 2013

London Code Dojo 22

Another outing to the London Code Dojo and I've come away with a treasure trove of lessons... now just to remember and apply them!

What Went Down


The dojo was a Checkout scenario, where we were given various fruits as input and we had to return the running total cost.

Whilst the problem was fairly straightforward, the challenge came in handling the shortened 15 minute pomodoro time limit and "requirements changes" in the middle of them!

Before the dojo, I set myself the goal of ensuring I did TDD like I meant it, which I had neglected in my previous dojo. This time I was pairing with Alexandra and I've posted my refactored take on what we did on GitHub (https://github.com/arkangelofkaos/CodeDojo22_Checkout). Once again I have used Java 8 in the code, luckily the collection manipulation leant itself nicely to Lambdas XD

My Impressions & Lessons Learnt

  • Practise is tantamount to improvement, even after the last few dojos I can see that I am improving (long way to go still!)
  • Advice on how to become a master at anything: "All you need to do is not give up!" (Keep practising!)
  • Simple design is incredibly powerful but incredibly difficult to get right.
    • In my experience, I still need to do a little design upfront, due to my lack of experience :P
  • I still need to be more disciplined in refactoring after EVERY test pasts.
    • Don't let technical debt build up, ever.
  • Ensure tests are not fragile, remember tests are code too!
  • Single Responsibility Principle is your friend, brilliant for creating "agile" code.
  • As a goal, I want to do the Gilded Rose Kata which covers "Anti-If patterns"
  • Pairing isn't supposed to make you twice as smart but half as stupid! :D
  • Failing all else: KISS XD

Sunday, 7 April 2013

London Code Dojo 21

My second outing to the London Code Dojo and I am kicking myself for leaving early :(

What Went Down


The dojo was a completely new exercise as expected but rather surprisingly it was a completely different set of rules! This time there was no super strict TDD rules but we were dealing with a slightly more complex problem.

The challenge was to generate 100,000 random numbers and sort them into order ourselves, with our own sorting algorithm! Everyone break out the panic sort ;) I had the pleasure of pairing with Rupert Wood and we just copied the wiki version of in memory quick sort >.<

Our goal was to make code as readable as possible and I think we managed that fairly well. The code is now up on GitHub (https://github.com/arkangelofkaos/CodeDojo21_RandomNumbers). See the initial commit for the raw version of what Rupert and I managed.

My Impressions & Lessons Learnt

  • As mentioned, I had to leave early which really sucked as I missed the last part and the really important retrospective. Never again!
  • I should prepare more and be more active in moving out of my comfort zone.
  • Need to be stricter with the TDD!
  • Since the dojo I spent a night refactoring the code and introducing Java 8 Lambdas to the equation :) This is also on the GitHub (https://github.com/arkangelofkaos/CodeDojo21_RandomNumbers).
  • My goal now is to learn how to implement a super fast parallel array sort! XD

Monday, 11 March 2013

London Code Dojo 19

*update* Added my basic Scala implementation of FizzBuzz here: https://github.com/arkangelofkaos/FizzBuzz

Recently I was introduced to the London Code Dojo by a good friend and on Monday I attended my first code dojo!

What is the Code Dojo?

dojo is a place to practice an art and a code dojo is no different! The purpose of it is to allow developers to practice and learn. The first rule of code dojo is you are there to "do it right"!

Everyone has probably heard it takes practice to make perfect and in theory you need to do 10,000 hours of practice to become an expert in anything! This practice has to be done properly though, specifically it must:
  • Be focussed
  • Be goal-Directed
  • Be stretching (aka not easy)
  • Include continuous feedback
  • Include self-reflection
To get this kind of practice at the dojo, we all participate in a kata. This is basically a coding exercise with very specific rules.
  • The goal is to do things correctly, not to simply get everything done.
  • You must do Test-Driven Development (this is taken to the extreme)
  • You must do pair programming
  • You must commit/revert every 5 minutes!
  • Commits must be meaningful with a simple and descriptive one-line comment.
  • After 20 minutes a quick retrospective is held and new requirements maybe added.

My Impressions & Lessons Learnt

Our Kata for the night revolved around implementing Fizz Buzz, which is non-trivial given the TDD constraints.

The dojo really gave me a baptism of fire. As no one wanted to write in Java,  I took it upon myself to try to code in Scala for the very first time. Simply reading the Scala chapter in my book club book had given me a decent start though :) Apologies to my pairing partners for the frustration!

@sleepyfox who runs the dojo made a great pitch for TDD and how it saves time in developing long AND short projects! From my point of view, I suppose it follows the whole "fail fast" methodology. Mistakes are always made and by doing TDD you ensure you catch mistakes quickly, rather than having to hunt for them.

However I still reckon the age old "it depends" answer applies to whether or not you should use TDD. Part of my 'homework' is to research "Spike and Stabilise" which sounds interesting...

One thing I did get pulled up on was my when I answered too quickly. Remember: "Respond don't react!". Polymorphism is not necessarily always the answer to replacing a bunch of "if - instanceof" statements!

My favourite phrase for the evening was: "If you are 'refactoring' but everything ends up broken, you are actually 'ref**ktoring' your code" XD

The biggest takeaway was the emphasis on ALWAYS being simple, concise and expressive. Doing things in a complicated fashion is easy, any idiot can do it. But being simple is tough, in both your code and your commit comments.

Really learnt a lot from the dojo and look forward to future ones!