Dev Academy: Week 7 – Object-Oriented Design in Ruby

This week was focusing on Object Oriented Design. We had 5 challenges to do:

  1. Drawer Debugger
  2. Pez Dispenser
  3. Bingo Board Part Two
  4. Refactoring for Code Readability – on previous weeks challenge Validate a Credit Card Number
  5. Virus Predictor.

And I have just realised as I have started writing this post that Object Oriented Design hasn’t actually be explained to us. So, as I have been doing a lot in the last 7 weeks, I have googled what OOD is. Some definitions and links:

Object-oriented design is a programming paradigm that began in the late 60’s as software programs became more and more complex. The idea behind the approach was to build software systems by modeling them based on the real-world objects that they were trying to represent. For example, banking systems would likely contain customer objects, account objects, etc. Today, object-oriented design has been widely adopted by businesses around the world. When done properly, the approach leads to simpler, concrete, robust, flexible and modular software. When done badly, the results can be disastrous.

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Wikipedia,

It’s a process of planning a software system where objects will interact with each other to solve specific problems. The saying goes, “Proper Object oriented design makes a developer’s life easy, whereas bad design makes it a disaster.”

A link to a possibly useful book on the subject:

Practical Object-Oriented Design in Ruby (POODR) is a programmers tale about how to write object-oriented code.


Another book with an interesting title:

The Bastards Book of Ruby: A Programming Primer for Counting and Other Unconventional Tasks

Object-Oriented Concepts – A primer on object-oriented design and using it to organize your code.

In a nutshell, object-oriented programming sees the world as data, modeled in code by “objects.” In OOP, the programmer focuses on the content of that object and how that object behaves (i.e. methods).

So it’s worth becoming acquainted with OOP because it is a design pattern especially suited for programming with data. The practical benefit is that it can vastly reduce the amount of code you have to write and the number of errors of inconsistency to debug.

I guess I have a bit of an idea now and in the Treehouse tutorials we did make a bank account class, so can see the link to the first definition above. Do you have a good definition or explanation of what OOD is? And any good examples?

What have I learnt / done this week? Well, I feel more confident with writing methods, classes and how the methods interact with each other. I am starting to become more comfortable with breaking a problem down into more than one or two methods. I can see the relevance of doing this. I have learn about user stories:

… and used them in solving a problem and wrote some nice code, I think.

Screen Shot 2015-04-17 at 5.10.31 pm

Still not sure about what attr_reader, attr_writer and attr_accessor do, as it seems I can either have them in or not and my file still works?! For example in the above code having attr_accessor :flavours just above the initalize method, it will work. Anyone got a good explanation of what it a attr does and when it is used?? Perhaps I am just doing something fundamentally wrong in my code?

I have enjoyed solving the problems this week. Two were ones we did last week that we built on or refactored and the other three weren’t too difficult, although did do some work on the Virus Predictor challenge with another person from my cohort.

Another member of my cohort shared a link at this book – the (Poignant) Guide to Ruby –  and link to PDF. Even though this seems to have bee written by someone who is all over the place (the cartoons and long rambling paragraphs), the core part of the book explains what Ruby code is doing in a very simple way. For example:

Screen Shot 2015-04-17 at 5.52.32 pm

Two weeks left until the start of Phase 1 and the nine weeks of bootcamp. It will be coding from 9am till 6pm Monday to Friday plus probably lots of evenings and lots of weekends. I expect I will be very antisocial over this time. What will be good is that I will be based in at Enspiral Dev Academy in Cuba St and there will be lots of people around that I can get help from. Also, I hope I will be able to help some people as well, even though I have a big dose of the imposter syndrome – post on that shortly.

Ending question, what resources do you use, recommended for learning everything Ruby?


Dev Academy: Week 5 – Algorithms and Week 6 – Classes = lots of hard work!


Week 5 of Dev Academy was about building on what we covered in Week 4.

Last week you built up a toolkit of ruby methods. You practiced with them and gained a good intuition of how they work, what they’re used for, and so on. This week you’ll use that toolkit to solve some more complex problems.


This week also involved reflecting on each of the challenges and how you went. I found this part extremely useful. Over the week I worked on improving how I wrote pseudocode and actually taking more time to understand a problem instead of diving in quickly.

I am still at a point where once I get an idea in my head about how to solve a problem, I don’t take the time to think about other ways to solve it. This is something I need to work on – to improve my lateral thinking. I think as I become more confident in my understanding and use of code, my lateral thinking will improve. It is also something I will look to focus on in particular over the next couple of weeks.


In each of our challenges, once we solve it with an initial solution we then are asked to refactor it. I’m still doing this at a basic level (or at least what I think is a basic level). At the beginning of each week we get given examples of possible solutions to the previous weeks challenges, which proved interesting for the challenges in Week 5. I learnt a lot of cool things that you can do in Ruby to reduce down your code.

For example this loop:

Screen Shot 2015-04-12 at 5.06.19 pm

For if / else conditional statements, for this:

Screen Shot 2015-04-12 at 5.07.49 pm

And then you can ‘chain’ together lots of methods:

Screen Shot 2015-04-12 at 5.09.42 pm

So, this:

  • takes a number
  • converts it to a string
  • reverses it
  • turns it into an array of characters
  • splits the array into groupings of 3 (slices it)
  • turns it into an array
  • then maps it (copies it) to a new array while joining  the sub arrays together and putting a comma in between
  • then reversing it back.

Another challenge in Week 5 was the Accountability Group Creator!

In this challenge, you are going to make a method that takes an array of names (you’ll want to make a list from the people in your cohort) and outputs a list of accountability groups for three different units. You should try to get everyone into an accountability group of 4, but it’s your decision how to deal with cohorts not easily divisible by four.

This was a fun challenge to do but more importantly I could see the link to the possibility of making a product that I have used. While teaching Physical Education you need to split a class into teams. I discovered Team Shake, where you enter in your class list, how many teams you want or how many students in a team. You can also rank your students by ability level and then decide if you would like same ability teams or different ability teams.

2_IMG_4314 (1)

It was great to see how the Accountability Group Creator challenge links in with an actual app I have used.


Week 6 we started exploring Classes by firstly doing either the Treehouse Ruby Objects and Classes tutorials or Codecademy: Ruby (Object-Oriented Programming Pt. 1 and Pt. 2). I actually decided to do both and luckily they didn’t take ages and was worthwhile doing both as they covered things slightly differently.

We then got into challenges where we had to write classes! I found parts of this week quite hard and other parts not so difficult. The Bingo Board challenge I got really confused with and got myself all tied up in knots but some good learning came out of it for me. I used IRB (interactive ruby) really well to help me figure out what I was doing wrong, which I hadn’t done to this extent before. I have gotten better at understanding error messages, thats got to be handy in the future! With the Bakery Challenge I think I  finally got a good handle on hashes and how to access the values and keys separately.

I have also started using a visual diary and writing down code things so I can use as a reference over the next few months. There is no way I am going to be able to keep everything in my head!

The last two weeks have been really busy and full on (so much I didn’t do a blog post at the end of Week 5). Part of this was due to being sick at the start of Week 5 and during Week 6 I had a couple of days where I couldn’t do much coding. So, feeling pretty good with what I have been able to achieve over these two weeks.

Tomorrow begins the last unit of Phase 0. I think what we will be covering is Object Oriented Design, Databases, and Review. Three weeks until bootcamp!

Minion-220 (1)

Why Learning to Code is So Damn Hard – Viking Code School Blog

Why Learning to Code is So Damn Hard – Viking Code School Blog post

Screen Shot 2015-04-12 at 4.00.05 pm

Came across this blog and post via twitter. Makes for a fascinating read considering that I have embarked on this journey of learning to code.

I knew that this journey was going to be more than full on and very difficult. It is quite nice to know that it is recognised as really hard and it also gives some ideas on how to get through it – section titled “How to Make it Through Alive”!!

I am hoping I will be alive come July 3rd!?!