What’s it all about?

This was the fourth and final week of the pre-course. To round off our learning the focus this week was pair programming and test driven development (“TDD“).

What did I do?

To complete this week I had to:

1.  Pair program with one of my cohort (remotely or in person) to complete the classic Fizzbuzz coding challenge using RSpec to apply and understand basic Test Driven Development (“TDD”) concepts.

3. Score 100 – 150 points on Codewars.

4. Finish any outstanding tasks/challenges from the previous weeks – luckily for me I had nothing outstanding!)

Ok, before we begin: what the heck is FizzBuzz?

FizzBuzz is a really simple coding challenge.  You write a program that does the following:

  1. It returns the word “Fizz” for numbers that are multiples of 3
  2. It returns the word “Buzz” for numbers that are multiples fizzbuzzof 5
  3. It returns the word “FizzBuzz” for numbers that are multiples of 3 and 5

Check out this GitHub repo to see how my pair (Riya) and I solved this problem, including our TDD unit tests.

What did I learn?

This week was less chockablock than the previous two weeks. This was great.  It allowed me to decompress a little and consolidate some areas that I had found more challenging, e.g. remembering the various ways to iterate and manipulate arrays and hashes.

The key learning I took away this week was:

  1. How to effectively pair program to solve coding challenges.
  2. How to use TDD to develop code and solve challenges.
  3. Further depth of understanding regarding iteration and manipulation of arrays and hashes.

My highlights

Pair Programming

Week 4 was our first intro to proper pair programming.  For the entirety of the PreCourse we were encouraged to meet up with our cohort and mentor where possible (more about mentors at Makers Academy in this post) to pair program.  At this point in the PreCourse I had already met up with some of my cohort at Google campus during week 2, however, I hadn’t yet done proper pair programming.

This week I got to understand b76636cb-6f61-4cb9-886e-325c1f88bf5awhat pair programming really means.  My first ever pair was Riya!  We couldn’t catch up in person so we used ScreenHero, which is a remote pairing app that allows you to share and use each others screens over the internet.

What’s pair programming?

Pair programming is an agile software development technique in which two programmers work together to develop code.

Each person has a specific role.  One person downloadis the driver and the other is the navigator.  Much like driving and navigating in the car, the navigator instructs the driver what to type when and where to develop the code and the driver does the actual typing.  Every so often the roles switch and the driver becomes navigator and vice versa.

Without going into reams of theory, essentially this is the old saying two heads are better than one in action.

Why is pair programming useful and why do Makers use it?

I’m not going to reinvent the wheel on this one: Makers Academy have already written a succinct piece on both these questions – read it here!

How did I find pair programming?

I thoroughly enjoyed pair programming with Riya and using basic TDD and RSpec to develop our coding solution to the FizzBuzz challenge.

I was going to write more about TDD and RSpec here, but coming back to this post I decided to move that content to this post, which covers it in more detail.

So back to the program (get it?), what did I enjoy about pair programming?

I liked the fact that one person focuses intently on figuring out the TDD tests and minimum code to pass those tests while the other types.  That, combined with swapping roles every 15-20 mins keeps both people fresh and focussed.

As a result we were hyper efficient and breezed through the task.

We also learned a lot from each other, for instance I learned an alternative way to solve the FizzBuzz challenge using case statements, which was not something I had really come across up until that point.

pair-programming-meme

Test Driven Development (“TDD”)

What is TDD?

Before writing any application code (i.e. the code that your program will comprise), you must first write tests that fail.  Next you write the absolute minimum code to make the test past.  Finally you refactor.  TDD can be summarised by the below diagram.

tdd_flow

Refactoring is code speak for improving the code.   This usually involves redesigning the code to adhere to design best practices (e.g. single responsibility for all methods and classes etc), eliminate redundancies and duplication and improve readability etc.

What are the benefits of TDD?

  1. Writing tests first makes you consider exactly what you want from your code
  2. Creates a detailed specification for your code.
  3. Less time spent debugging
  4. Allows design to adapt and evolve to your changing understanding of the problem.
  5. Forces you to keep everything as simple as possible – you only write the minimum code to pass the test at each stage in the development process
  6. Forces you to write the smallest test cases to ensure at each stage you are focused on only one thing at a time, which helps adherence to design best practices such as the single responsibility principle.
  7. Helps create loosely coupled code, i.e. by focussing on one small thing at a time you reduce the chance of designing code blurs responsibilities between classes and methods.
  8. Creates SOLID code, which is a mnemonic for object oriented design principles.
  9. The resulting unit tests are simple and act as documentation for the code (more on this in my later post about week 1 of the main course).

Why does Makers Academy teach us to code using TDD from the get go?

Makers Academy’s ethos is to teach students coding and development best practices from day 1.  Like most things, it’s easy to pick up bad habits and much harder to overcome them.

Further, TDD is widely used throughout the tech industry and in AGILE methodologies for rapid prototyping of businesses and Minimal Viable Product (“MVP“).  Being able to do TDD as a junior developer is essential and surprisingly not all junior developers are able to understand and apply TDD skills.  Having these skills from day 1 will help us secure better roles at the end of the course and, both during and after the course help ensure we write decent code.

Getting better at more complicated Codewars Katas

I smashed through a tonne of Codewars Katas this week, including some that I felt pretty pleased with myself about.  One of my favourites is this one, which requires you to write a program that translates Morse code into English.  This is how I solved it:

Screen Shot 2016-05-31 at 20.37.15.png

Lines 4 – 45 create a hash of key/value pairs where the key is the alphanumeric character or special character and the value is the corresponding Morse code.  Lines 47 and 49 encapsulate the translator method that takes one argument, a string of morse code.  Within that method on line 48 I do a bunch of things to translate that Morse code string into a string of English words.

First, I split the morse code string into an array of words in Morse code using morseCode.split("  ").  In Morse code words are separated by two blank spaces, hence I use split("  ") to split the string at each double space.  This returns an array of words in Morse code.

Second, I use .map to iterate over each element in the array and execute the first block of code, which begins {|x| x.split(" ").  That returns an array of letters for each word in Morse code as each letter in a Morse code word is separated by a single space.

Third, the array of letters in Morse code is then iterated using .map to execute the second nested block of code, {|y| @morse_dict.key(y)}, which essentially translates each letter in each word into its corresponding alphanumeric or special character. It does this by using the Morse code as the value to look up the corresponding key, i.e. the alphanumeric or special character in the hash that corresponds to it.

Fourth, each alphanumeric or special character is then joined back together using .join("") to return an array of English words.

Finally, the array of English words is then joined back into a single string using .join(" ") and .lstrip used to remove any blank spaces at the beginning of the string (if any).  The upcaseupcase the resultant string!

How did I feel at the end of week 4?

Week 4 was much easier than weeks 2 and 3.  I managed to complete the pair programming/TDD exercise with Riya on Tuesday and finally racked up 150 points on Codewars by Wednesday evening.

As such, that left me with the remainder of the week to brush up on areas I’d found more challenging or fiddly.  In particular I revised Git, Github and version control by completing the excellent git immersion tutorial.  Well worth a look if you want to better versed in the more complex git functionality or simply gain fluency in the basics.

As much as I pushed myself to keep coding and coding and coding, toward the end of the week my brain started to feel like I was OD’ing on code and in need of a break.

tumblr_lhrlf6ytWu1qh4nf6o1_500.gif

Late Thursday afternoon I decided very last minute to join my girlfriend and climbing friends on the awesome Boulderbus that weekend.  A few clicks later and I was booked onto the Boulderbus for that weekend.  I’m glad I did as I really needed to take a few days off to decompress and refresh before starting the main course the following Monday.  Also, it was probably the last chance to go bouldering in France before the end of the course as each weekend during the main course we have solo coding projects to complete.

Below is a few snaps from the Boulderbus trip to Fontainbleau in France.  If you don’t know what on earth I’m on about when I talk about the Boulderbus, bouldering and Fontainbleau then check out out the blurb after the slideshow!

This slideshow requires JavaScript.

Boulderbus

If you’re into climbing and/or bouldering, the Boulderbus is an awesome way to travel to Fontainbleau in France.

Fontainbleau is one of the best places in the world to boulder outdoors.  It’s run by a super cool dude, named Ian, who is a fantastic climber and general all round nice guy.  Ian’s been going to Font since about 1996 if I remember rightly and has been running the Boulderbus for around 10 years.

No matter your ability, whether your a Font virgin or Font veteran, Ian will happily help guide you to the best spots to match your ability and desire.

Basically Ian organises a deluxe touring coach that takes you from Mile End Climbing Wall in London to Font and you stay overnight in the coach at a campsite located in the forrest right next to some of the best climbing spots in Font.  The coach is really fun and has lounges with TV/sound system and sometimes games consoles, a kitchen and sleeping berths.  Highly recommended and a great way to make new friends – my girlfriend and I went last year for the first time and went again this year with people we met on the trip last year!

In terms of a sample itinerary check out this page on Ian’s website.  Prices and booking are available here.  They also organise hire of boulder mats if you’ve not got your own.  If you’re a Facebook person, also check out and like his Facebook page.

Advertisements