Makers Pre-Course — Week 3

A slightly dull, but comprehensive learning diary for Makers.

Day 11 — Monday 9th November

Feeling at beginning of day: relaxed

Learnt within day:

New learning technique: record screen whilst coding and watch it back on fast forward.

Chapter 8, Question 2: Restructure an array of hashes into a hash of arrays.

Time taken: 1hr. 10mins drafting pseudo code. 50mins coding and testing.

Method: start at the outputs and follow the error messages back.

Crux: can’t use the .push method on hashes, only arrays. This is because arrays auto index. To add to a hash need to type the key value pair hash[new_key] = new_value. This tripped me up.

Chapter 8, Question 3: Restructure an array of hashes into hash of arrays, then iterate through the resulting hash of arrays.

Time taken: 50mins. 15mins pseudo code. 35mins coding and testing.

Crux: got tripped up more by the coding process. Firstly dived into coding before writing out comprehensive pseudo code. Next; ended up writing the hash derivation before the output iteration. In the spirit of working backwards, probably would have been better to manually draft an MVP staging table to test the output script. Then build the script to populate the staging table fully. Being able to test with the output script.

Methods:

• Writing your own methods: Methods are reusable procedures. As a variable is a named object, so a method is a named procedure.
• Calling methods on the main object can be done without the dot syntax.
• When we send an object a message the object invokes a method using that message. Then the object carries out a procedure. Finally the object returns something back to whatever sent the message.
• To designate what the return value should be from a method, use the return keyword.
• An empty method has an implicit ‘return nil’ within it.
• Method parameters are temporary names for objects provided as arguments.

Methods should do one thing, and do it well.

• Abstraction: abstraction makes code easier to work with but less easy to understand what’s going on beneath the hood.
• Picking the right level of abstraction is very difficult.
• Abstraction rules of thumb; 1) Can you name your method in a simple way, without using the word, ‘and’? Does it do one thing and nothing more? 2) Can you name your method after what it returns instead of what it does?

Feeling at end of day: satisfied.

Day 12 — Tuesday 10th November

Feeling at beginning of day: determined

Learnt within day:

Chapter 9, Question 1: Build a solo game of Blackjack with four methods.

Time taken: 1hr 15mins (with a few interruptions)

Method: required to build three methods; run_game formed the structure, calling the other three methods. Wrote pseudo code for run_game first, then the sub methods. Then wrote and tested the code from the output of run_game backwards.

Crux: no syntax issues or conceptual issues. Got tripped up a bit in the structure of my approach. Ideas: write pseudo code forwards from inputs to outputs. Code and test backwards from outputs towards inputs. In drafting pseudo code; re-write method definitions in method; as a reminder of how it works and for future reference. Build up from basic building blocks into full structure. Test an complete each method individually before combining them. Also, check completed pseudo code against specification before diving into coding.

Classes

• Imperative Programming: telling the computer how to do something
• Declarative Programming: telling the computer what to do.
• Telling an object what we want might look like; “average these scores”. This is called declarative programming.
• As programmers we try to abstract our work to a declarative style wherever possible. One route to doing so is: Object oriented programming:
• Declaring your own classes: new classes = new gods.
• Ruby has a class called class. It is the god of all classes. If you use the class keyword on an undefined class it will automatically create it.
• Object Properties: Object state: integer knows about value, string knows about text. Infact a string’s internal characteristics are referred to as properties of the string.
• Instance Variable: is resident in the class instance. Methods that set an object state using instance variables are called setters.
• Mutating Object State: a method can be defined which amends the object state.
• Using initialize to set up instances: Ruby automatically defines the initialize method even if you don’t write it.
• Different Kinds of Variables: instance variables include an @ sign at the beginning. you also have local variables, and method variables. The difference is broadly which objects can see these variables.
• Regular variables are normally referred to as local variables. Local variables are available to anything that wants it.
• The area of a programme in which the variable can be read is called the scope.
• Def and Class are known as scope gates. Ruby files also act as scope gates.

Feeling at end of day: tired.

Day 13 — Wednesday 11th November

Feeling at beginning of day: optimistic

Learnt within day:

Pills:

Arrays:

• an array in programming is an indexed collection of related items.
• indexed collection means things are ordered.
• Can call .first or .last on an array as well. Useful if you don’t know the length.
• You can .sort an array

Symbols:

• symbols are not variables, so you can’t assign anything to a symbol directly.
• however, you can use a symbol as a value.
• symbols are immutable, which means they are memory efficient, as the exact amount of memory is allocated rather than a flexible amount, as per strings.
• alternative hash syntax with symbols. you could write: capitals = { :france = “Paris”, :germany = “Berlin” } or a nice bit of syntactic sugar: capitals = { france: “Paris”, germany: “Berlin”). ‘france:’ and ‘germany:’ are both still symbols despite the colon being at the end.

Chapter 10, Question 1: Build an MVP todo list tool with two classes and five methods

Time taken: 52 mins (22 mins pseudo code, 30 mins TDD)

Method: tried to write the pseudo code as comprehensively as possible. And checked with the spec before then coding. Worked hierarchically defining the classes, and the methods within them. In TDD, tried usual testing of outputs and working back to inputs on the first class, then switched to writing a small test script and trying to fulfill that with the definitions of the class and methods for the second class. The second approach makes much more sense for OOP.

Crux: no major crux, other than starting to get the idea of TDD.

General errors: don’t capitalize variable names. Remember to indent the pseudo code as you go. Good idea to check against spec; copy and pasting spec into methods might be overkill. Make sure to add a space after # for pseudo code.

Feeling at end of day: pleased

Day 14 — Thursday 12th November

Feeling at beginning of day: bit nervous about pairing.

Learnt within day: Pairing, Github Collaboration, TDD and Rspec

Pairing programming:

• Pair programming is the process whereby two people actively collaborate on developing code.
• Key component of pair programming is regular driver/navigator switching.
• Swap every 15mins.
• Take occasional breaks every 90mins.

Github Collaboration:

• It’s possible to collaborate directly with another developer on the same GitHub repository, from respective local repositories.
• One developer sets up local and remote repos.
• Then invites the other developer to collaborate on GitHub.
• Once the invite accepted, the other developer can clone the original GitHub repo onto their local directory.
• Then updates can be committed by both developers directly.

TDD:

• TDD = Test Driven Development
• Process of writing tests first, that should then be resolved to pass through code development.
• The code is developed to pass the tests.
• The tests need to be a representation of the specification.

Rspec:

• Rspec is a ruby library, that supports TDD.
• The software is a testing framework, that enables tests to be written, and then evaluated against the prescribed code base.
• Very Powerful.

Fizzbuzz Challenge:

All these concepts were put to the test in a pair programming challenge to complete a fizzbuzz script (1, 2, fizz, 4, buzz, fizz, 7, 8 , fizz, buzz, 11, fizz, 13, 14, fizzbuzz, ….).

Initially getting the github collaboration working proved to be a challenge. Once we cracked that, we quickly got into a rhythm of clear communication, screen sharing, and sharing workload.

We worked through the challenge twice; first with the support of the learning text. Second time from memory.

Deleting the first fizzbuzz directory proved harder then expected. Some of the files in the .git directory, did not have write permissions. Rather than update (as there were hundreds of these files) deleted the full directory with rm -fr (the f stands for forced removal).

By the second attempt we were getting quicker and into the swing of the process. Pushed ourselves at the end to right a spec that tested a range of inputs.

Feeling at end of day: really enjoyed pair programming, feel knackered now though.

Day 15 — Friday 13th November

Feeling at start of day: buoyant

Gave myself a bit of free time today, but did a bit of recapping string, array, and hash syntax by extending my command line command learner to be able to incorporate separate syntax question and answers files cover each of the additional areas.

Feeling at end of day: good to have a play around.