Makers Day 6
The weekend challenge was titled ‘Airport Challenge’. This project encapsulated all that we had learned last week; mainly the work on TDD (test driven development). I gave myself Saturday morning off (for no other reason than I couldn’t be bothered), and then saw some messages floating around on Slack stating that the Boris Bikes Challenge’s chapters on Mocks and Doubles etc. were useful for the weekend work. As I hadn’t got to this stage in the Boris Bike Challenge I decided to carry on with that. After an hour, I still didn’t get doubles, so I gave up on Saturday completely — if you can’t learn to tie your laces, don’t get velcros. Just never leave the house. On Sunday I started the airport challenge and really enjoyed the work, despite having to start over after an hour because I was trying to get the Plane class to do all the work, instead of the Airport class which turned out to be much easier. Overall, I was happy with my work on the challenge, despite the fact that I still didn’t understand doubles and RSPEC layouts. Something to continue working on I suppose.
Monday morning started with a code review. My code was generally well received although a comment was made that it had ‘too much’ functionality. Whilst in real-life this may be frowned upon, during my learning I will continue with this as it will add to the experience and challenge me in more ways.
This week’s challenge is titled ‘Oystercard Challenge’. So far it has been a relatively straightforward start — essentially following the steps that we did for the Boris Bike and Airport Challenges. The difference is it is making us take more time in each step at the moment, discussing smaller aspects in greater detail. I must make sure that I am careful not to just skim over some of this because it now seems basic. By going through the challenge step by step I will gain a deeper understanding into the principles which is how I like to go about my learning.
Learning outcomes from today:
Git hub — it is important to make frequent commits, with meaningful messages, to allow for an in depth code review. Also the pull request itself should be thoroughly annotated to provide context to the reviewer/receiver. The README file is essential — it is the first part of the project that someone will see. This file must be clear, brief and purposeful.
RSPEC doubles. I have a script file that contains a class called ‘Airport’, and a spec file where the tests for this class. In the spec file, if I am referencing instances from another class apart from ‘Airport’, that is when I use doubles. The spec file is designed to specifically look at the ‘Airport’ class so doubles will not work for this class.
Goals for this week:
Improve my discipline. I find it too easy to waste away time on meaningless activities. There is nothing wrong with these activities, however I should take care to schedule them.
I will also send my pair programming feedback form to my pair partners immediately after working with them while the experience is fresh in their minds.