Another athletic restart on our Battleships challenge today. As usual, all goes well, my pair programming partner today and I had paired before on the precourse on a test-driven development exercise so we totally meshed, supporting and urging eachother on. She's just as laid back as me so it was a very pleasant day but we did get a lot done. Our coach has been doing incremental tutorials on how to make Battleships in Ruby testing with Rspec so we decided to follow those, pausing at key moments to see if we could write and solve the tests he suggested for ourselves.
The day ended with our wellness guru taking us to the pub for drinks.

(Here's some of our cohort outside Makers Academy before heading off to the pub)
If you're really interested, there's some code after the break!

This week's pair-programming exercises have been to recreate the Battleships game. My partner has some experience coding so it's gone very well. There is always a concern that a disparity in skill can lead to problems when pairing but by and large I haven't found this to be the case. If I'm a bit ahead of someone else I learn so much by explaining what I'm doing to them and when I've paired with someone that is ahead of me I learn so much from them, it's a win-win! My personal accomplishment for the day was initializing a hash to represent our game board.

 1 def initialize
 2   @grid = {}
 3   ('A'..'J').each do |letter|
 4     (1..10).each do |number|
 5       @grid[(letter + number.to_s).to_s] = 'E'
 6     end
 7   end
 8 end
 9 # creating a 10 x 10 grid of hashes with lettered and numbered
10 # keys with changeable values to define status of the cells

Had my code review today for the Ruby BDD airport-challenge and I'm pretty pleased about it. My new coach is not known for handing out complements so in light of that I think I can breathe a sigh of relief. I am very glad I actually spent Sunday night revamping my tests and code, had I not done that today would have had a very different outcome.

Hey, Sorry to be quite harsh. Despite what it sounds like this is really good. You just need to neaten it up a bit and it would be perfect. I'm impressed with some of your code but just try to make sure that everything is consitant (sic) and has purpose. Really good :checkered_flag:

Full feedback after the break.

Work continues on the Airport Challenge. I'm mostly happy with my first iteration and am fairly confident about my code review tomorrow morning. This was a an exercise is perfect syntax, brought to you by Rubocop.

 1 Running RuboCop...
 2 Inspecting 7 files
 3 .......
 4 7 files inspected, no offenses detected
 5 Airport
 6   knows when a plane is in the air
 7   knows when a plane is in the airport
 8   can order a plane to take off
 9     should respond to #order_plane_takeoff
10   can respond to a plane wanting to land
11     should respond to #landing_permission
12   traffic control
13     a plane cannot land if the airport is full
14   weather conditions
15     can be both sunny and stormy
16     a plane cannot land when it is stormy
17     a plane cannot takeoff when it is stormy
18 Grand Finale
19   6 planes can be created
20   airport knows planes are in the air
21   6 planes can land at specified airport
22   airport knows planes are in the airport
23   plane is denied landing permission when airport is full
24   6 landed planes have status: landed
25   after all 6 planes takeoff there are no more landed planes
26   after all 6 planes takeoff their status is 'flying'
27 Plane
28   has a 'flying' status when created
29   is located in the air when created
30   can 'request to land' at airport
31   responds to 'land'
32   has a status of 'landed' after landing
33   does not respond to 'land' after landing
34   responds to 'takeoff'
35   can 'request to takeoff'
36   changes its status to 'flying' after takeoff
37   does not respond to 'takeoff' after takeoff
38 Finished in 0.02523 seconds (files took 0.40916 seconds to load)
39 26 examples, 0 failures

So yesterday we started our weekend challenge. Being able to apply our knowledge to a similar yet different real-world challenge so quickly is a great learning experience. The plan of attack was to use the user-stories to come up with an outside-in, behaviour-driven design approach to coding, feature tests first, then unit tests, then watch them fail, then create the necessary application code to make them pass.

 1 require 'capybara/rspec'
 2 require 'airport'
 3 feature 'grand finale' do
 4   scenario 'all planes can land and all planes can take off' do
 5     airport = Airport.new
 6     planes = []
 7     6.times { planes << Plane.new  }
 8     planes.each { |plane| airport.landing_permission plane }
 9     expect(airport.landed_planes.length).to eq 6
10     airport.landed_planes.each do |plane|
11       expect(plane.status).to eq 'landed'
12     end
13     planes.each_with_index do |plane|
14       airport.request_plane_to_takeoff plane
15     end
16     expect(airport.airborne_planes.length).to eq 6
17     expect(airport.landed_planes.length).to eq 0
18   end
19 end

(Watch me unjumble my unreadable and poorly designed Rspec/Ruby test code)

Yesterday we wrapped up on our Boris Bike challenges and today we had a review of how our week had progressed. Lots of good points raised at the stand-up and we broke off into our smaller bytes for a break-down of the issues people felt stood out for them, both in terms of coding and their experiences at Makers Academy so far. After that we were issued our weekend challenge, to design a system to manage an airport, using all the outside-in behaviour-driven design techniques we had learnt this week. I write this post as I'm sitting in the train on the way home after a 13-hour day, but time flies so quick. The only thing that keeps us going so far is the energy, passion and genius exhibited by everyone at Makers.

(A scrum that the seniors held for us juniors)

Today I got a chance to do an athletic restart on our Boris Bikes behaviour-driven design challenge, that’s when you start right from the beginning again, discarding all your code and tests from the previous day and see how much better you can do or further you can go. The intention was to switch pairs to get more experience in pair-programming with new partners but we were an odd number of students at the Academy so I formed a triplet with two others and it went much better than expected!

(A typical breakout session to discuss issues raised during stand up)

The plan was to do an athletic restart of our behaviour-driven design (BDD) for the Boris Bikes challenge but since my pair-programming partner was not going to be here tomorrow because of his final exams we decided to carry on and finish the exercise. If we're meant to be agile then let's be agile!

 1 require 'garage'
 2 describe Garage do
 3   subject { described_class.new(capacity: 20) }
 4   it 'can set a default capacity on initialising' do
 5     expect(subject.capacity).to eq(20)
 6   end
 7   it "can fix broken bikes" do
 8     garage = Garage.new
 9     working_bike = double :working_bike, broken?: false
10     broken_bike  = double :broken_bike,  broken?: true
11     garage.dock(working_bike)
12     garage.dock(broken_bike)
13     expect(broken_bike).to receive(:fix)
14     garage.fix_broken_bikes
15   end
16 end

So far, the one word I would use to describe our experience and our learning at Makers Academy is 'Agile'. The previous cohort had two structured hour-long lessons every day with time inbetween to do the exercises and practice implementing the code and processes they were introduced to. Things would be different for us.

 1 require 'bike'
 2 describe Bike do
 3   it { is_expected.to respond_to :broken? }
 4   context 'when created' do
 5     it { is_expected.to_not be_broken }
 6   end
 7   it 'can break' do
 8     subject.break
 9     expect(subject).to be_broken
10   end
11   it 'can be fixed' do
12     subject.break
13     subject.fix
14     expect(subject).not_to be_broken
15   end
16 end

Here we are at last! We had an 8.30am meet up time at Makers HQ where we could have breakfast and socialise with our fellow cohort. Kick-off was at 9.30am, we got to meet the team and each other. The rest of the day was about setting the stage for the 12 weeks to come. (Our first lunchtime talk from the CTO of Made.com)

Today was the final day of our four-week long precourse and it's been a very steep learning curve so far. Now we are prepared to go through our 12-week preparation at Makers Academy to become ace coders with all the hot skills new tech wants. But the pre-preparation didn't begin here.

1 puts "Hello, World!"
2 puts "How original..."