Day 15 – Test No.3

I’m making progress. I think.

Today’s test required us to create a model similar to this week’s Boris Bikes exercise. We had to model airplanes in an airport and apply the rspec skills we learned this week.

Since the last four posts of this blog have referred to Boris Bikes in some way, it was pretty crazy that the test only lasted four hours! The model wasn’t as complicated or involve as many classes as Boris Bikes but staying true to Makers Academy testing style, it required us to use a function of rspec that we hadn’t covered before. Cue Google.

I managed to get all my tests to pass and write the corresponding features so as long as I didn’t get the wrong end of the stick, the test will have gone alright – Enrique has the pleasure of marking our work this weekend!

While everyone hates tests, today’s was really useful since it gave me a chance to apply and try to mimic Enrique’s approach to modelling: keep it simple and write short methods that preferably do only one thing. We’ll see how that worked out when I get the rest back on Monday.

In the meantime, here’s to the weekend!

Gem of the day: Assigning a variable to a selection of an array basically takes a snapshot of the values of that array at the point of the assignment. That variable will not update! So deleting something from that variable’s array will mean it no longer satisfies the original selection conditions.  (Sounds obvious, I know, but I’d never connected the dots until this week)

Day 14

Finally finished Boris Bikes today. It’s not pretty but it’s functional (at least as far as rspec and I can tell).

We managed to get Enrique to show us in the afternoon how Boris Bikes is done from beginning to end. He put his screen up using the projector in the boardroom and it was a masterclass in cool, efficient code writing. One of the keys to mastering a skill is to be mentored by an actual master, and what better way than seeing how something is done well in practice.

He coded most of it in an hour while explaining snippets of code to us here and there. The quality and speed of his coding is definitely something to aspire to and it’s always nice to have something to aim for.

We got given homework for this weekend already and that’s to write a test for each method in Ruby docs in the String, Array, and Hash classes. With just over 260 methods, that’s definitely going to take a while. I’m planning on giving Boris Bikes another stab again this weekend in any event so the method tests might have to be an ongoing/lifetime thing!

Tomorrow’s Friday which means test day. It’s going to be on rspec so I wouldn’t at all be surprised if we got assigned something like Boris Bikes part 2. What was that about practice makes perfect? I’ll believe it once I’ve gotten some sleep!

On another note, Makers Academy now do fortnightly open houses (they call them happy hours) on Thursday evenings if you want to find out more about the course and speak to some current students. Check it out – Makers Academy Happy Hour

Gem of the day: Don’t be afraid to create more methods within a class definition. Methods should be succinct and ideally do just one thing. That’s way, they’re easy to read, refactor and develop.

Day 13 – I hate Boris Bikes

More rspec and Boris Bike modelling today and it didn’t go all to well. After struggling to write concise tests and the corresponding code which would make them pass, I found that my classes weren’t linked together! My cyclist, when he rented a bike, didn’t interact with my docking station which might not have had any bikes to rent in the first place!

I’d been wondering yesterday how all the classes were going to fit together but I just assumed it was something we’d work on later. I want to say I got completely the wrong end of the stick but the information given for the task was intentionally ambiguous, I think. On one hand, approaching the task this way will make sure that the lessons being taught stick. On the other hand, it can be pretty discouraging to work on something for a couple of days and not really know what you’re doing. It can be pretty discouraging.

I wouldn’t say I’m discouraged so much as frustrated that I’ve had to do thongs the hard way. I’m starting to doubt how effective being chucked all the way into the deep end is…

On another note, we had a guest speaker come in today to give a talk on remote paired programming. Makers Academy has a lunchtime talk by speakers in the industry every week or so.

For those who aren’t familiar with the concept, paired programming involves two programmers partnering to write code on the same computer. It often involves a dual screen set up with a keyboard and mouse being passed back and forth as the programmers need them.

The idea behind paired programming is that it reduces the errors and mistakes made in code, and can lead to better code being written. There have been a couple of studies which have found evidence to support this, and paired programming is now commonly used in the industry.

Today’s talk was on how paired programming can be moved from something live, to something remote – taking place over the internet. The practice of paired programming, let alone remote paired programming, is still pretty new so the tools available still aren’t sophisticated. Tools like ScreenHero seem to be commonly used, although it doesn’t support more screen sharing with more than two people, nor does it support linux.

I know paired programming can be useful, but when you’re just starting out, it can be hard to vocalise what you’re thinking/struggling with, and it’s difficult when one or both of you needs time to just think about things before coding anything.

Gem of the day: Starting a project all over again can be a great way to cement new concepts and get you in the practice of writing cleaner code.

Day 12 – A note on learning styles

Phew. Today’s been another difficult day. The whole of it was spent on applying rspec to the creation of our Boris Bike model.

I struggled with everything from learning the syntax of rspec to figuring out the scope of the tests to write.

Gem of the day: Figure out what you need to understand. The rest is just syntax which you need to memorise.

For beginners especially, it can be hard to know where to concentrate your efforts. When everything is new to you, it can be hard to figure out which things are just semantics (they just are the way they are – do you prefer chocolate or vanilla?), and which are fundamental concepts which need to be grasped.

There was a lot of pestering of Enrique, our teacher, but he was hardly surprised nor impatient. In fact, I’m certain he has made a conscious decision not to give us all of the available information before beginning the exercise, simply because you remember something better after trying to implement it unsuccessfully for the hundredth time before succeeding.

Whether that’s always true is the subject of a post for later this week. What do you think?

Do you prefer to be chucked into the deep end with a lifeguard on hand to intervene when you start sinking? Or do you prefer to start off in the shallow end and work your way up? And is one necessarily better than the other?

Given that today (and indeed the last few weeks of the course) has involved the former – the sink or swim method – this question about teaching styles is certainly on my mind tonight.

Oh and rspec, I’m probably going to dream about that tonight. Scary.

Day 11

Today was pretty slow but I guess that’s the way it is with testing when you’re not used to it!

The morning started off with a Q&A session with our new teacher (the cohort he was teaching graduated last week and our teacher before that left to take up a new job).

The Q&A session was a really good opportunity to get any questions we had about Ruby answered. Apart from one or two things, my cohort didn’t have too much to ask, though. I figure that’s either because we still don’t know what we don’t know, and/or it is the practical application which we need to work on (and which will probably help with the first thing). I’m going to say it’s both..

Keeping with the traditional notion of language analogy, knowing how to string sentences together doesn’t make you capable of writing a novel, let alone a good one! And so, I’m pretty keen to keep applying my fledgling Ruby skills to some problems. That’ll have to wait till next week though, Week 3 is all about testing.

After the Q&A session, the rest of the day was taken up by an intro to Rspec, a behaviour driven development framework for Ruby, and getting started with our main problem with this week – Boris Bikes.

The assignment is to model the components involved in Boris Bikes (docking station, bikes, vans, garages – to repair the bikes, etc) using classes and inheritance and delegation where appropriate. Oh, and we have to write a test before writing a single piece of code.

Rspec, like any new programming framework, takes some getting used to and it was pretty slow going today. Since the approach of BDD and TDD is so new to me (like most things), I’m still trying to understand at what level and what detail to test. Do we write a test to ensure that our bike class has a state saying if it is broken or not, or is it enough to test that a method can be used to get the bike’s state?

When I start connecting the dots on this one, I’ll let you all know!

Let me know if you have any non rspec questions in the meantime!

Day 10

The main event today was the graduation of the April cohort. They mostly collaborated on a rails project called Journals which was a travel blogging app. It was pretty cool to hear what they’d been working on the last two and a half weeks, and to also see what I suppose you could call the alpha version of the site.

During the presentation, they covered the technology behind the app as well as possible features that could be added to it in the future. They also considered how it could be monetised.

One of the guys from the graduating cohort runs his own coffee business called Bean&Ground which is a subscription based coffee site. So he branched off from the travel blog app during the last week and worked on a site redesign for his company, incorporating things like payment with Stripe and user options for changing their address/subscription etc. Pretty cool to see what he’s learned applied directly to a real world problem and which will be implemented pretty soon.

There weren’t as many recruiters as I thought would be there and there are still some graduates of previous cohorts who are searching for jobs. Someone from the first cohort landed his target developer job though so Makers is clearly teaching valuable skills. I’m just hoping the industry values these skills and can see past the no cs degree, no job requirement.

We’ve got a new teacher next week and the focus will be on object oriented programming. More on that in the next blog post.

This weekend is going to (ideally) be spent going through the Koans and Learn Ruby the Hard Way again. That’s what you get when you ask a teacher how you should be spending your weekend!

Day 9 – Simplicity

Gem of the day: Getting your code to work for the current requirements isn’t the end of it. Just as important is making the code readable and as straightforward as possible.

Note to self: avoid nested loops if at all possible. There’s almost certainly a more readable way to write the necessary code and that’ll make all the difference when it comes to revisions and collaboration!

Now that’s out of the way… We got set a pretty simple problem to do today – FizzBuzz. The idea is to go through numbers 1 to 100 and print Fizz for those numbers divisible by 3, Buzz for this divisible by 5, FizzBuzz for those divisible by both, and just the number otherwise. Easy enough, right?

I used an if statement and was pretty happy with my code and started to think about ways to make it more efficient. I wondered if assigning the value of the statement divisible by x would increase the speed of the code since when it comes to checking for FizzBuzz you wouldn’t have to do the two checks (divisible by 3 and divisible by 5 again).

I asked one of the teachers, Enrique, about it and he suggested rewriting the code altogether! He said not to worry about speed too much since you need to understand how each bit of code interacts with the computer on a machine level to truly optmizie code, and to instead focus on making the code readable. So rather than have

if x % 3 == 0

I should write a method (or a function as it’s more commonly referred to in other languages) which stated explicitly what was being done and to call it something like 

is_divisible_by_three

That definitely made me revisit the way I’ve been approaching coding (best to catch these things early!) and I’m now trying to focus on writing clean and understandable code. If I can’t explain the code to someone then I guess that means it’s not fit for purpose. Well, it is, but only if the code is to exist in isolation and the requirements of it never change – definitely not going to happen in today:a world. What problems exist in isolation these days anyway?

Consequence of that little morning lesson/paradigm shift was the rewriting of my solution to the anagrams solution. I worked on it with another student and that in itself was really helpful. When you need to explain what you’re doing, you tend not to code random @&£# (like three or four nested loops!).

The April cohort graduates tomorrow! I’m looking forward to seeing their final projects and getting a chance to meet with some of the hiring partners.

Oh, and I’ve got a test tomorrow on Git.

Day 8

Day 7 – I have a lot more to learn

Do you ever have those days when you think you’re starting to get something only to discover you didn’t really know very much at all?

Today was one of those days. And that’s a good thing. At the very least, it prepares me for the volume of things which I still have left to learn and helps me avoid the perils of the unknown unknowns in my educational journey.

After finishing off the Koans yesterday, I spent the morning tackling a sample interview question (available on GitHub) which required you to sort words of an array into anagram groups (i.e. words comprised of the exact same letters).

So [‘rats’, ‘star’, ‘tar’] would become [[‘rats’, ‘star’], ‘tar’]

It sounded easy enough, at least for a human to do whilst the array size is small, but in practice I found it pretty challenging. It took me just under 3 hours to figure out which is a lot longer than the average interview! Nevertheless, solving it helped me with two things.

It

a) put me in my place and reminded me how much more I have to learn – I’ve only been doing this for a week and a bit!

and

b) reemphasised (yet again) the importance of TDD.

In the afternoon, one of the teachers, Ben, gave us a talk about the different software development methods like Waterfall and Agile. It was great to hear how the two contrasted with each other and to hear about tools that are associated with them. One of the things Ben covered was Kanban which I hadn’t heard of before.

Kanban is a tool used in software developement. It’s key feature is an information radiator – commonly a whiteboard with post-its – which is easily accessible to all involved in the project and which display various tickets/tasks at their current stage as they move through the flow of the process.

Let me finish this post with what Kanban might look like in practice (the red numbers indicate how many tickets can be in a specific stage at any one time)

Kanban in practice

Day 6 – Progress and TDD

Back to the Ruby Koans today and we got set the task of completing them all by the end of this week. For those who haven’t heard of them, Ruby Koans are a great intermediate/advanced introduction to the Ruby language. It covers all the basic stuff like arrays, symbols, methods, but rather than deliver the content to be learned passively (i.e. by reading it), it uses tests which you have to make pass to get to the next exercise (Koan) in the set.

The method of education used by the Koans, a test-based approach, is intentionally in-line with the prevailing software development methodology used today – namely, Test Driven Development or TDD. The idea behind TDD is to write tests before you write any feature you want to implement.

Ok, so how does that work in practice?

For example, if I want to add a feature to my program that adds an array of numbers together, rather than jump head first into trying to write code that implements this feature, I first write a test (or for more complicated features, a series of tests) which will check if my code does what it is supposed to do.

I then run the test and watch it fail. The test will fail because I haven’t written the code to implement the feature yet.

I then write the code which makes the test pass. I refactor the code. Repeat until all applicable tests pass.

******************************************************************

Why bother with TDD?

I agree that TDD can slow you down in some instances, such as when you’re writing trivial code like a feature to add two numbers together. However, with more complex problems, TDD requires you to take a step by step (or rather, test-by-test) approach which helps you break the problem down into manageable chunks,  and it also encourages early bug detection in your code. Better to detect bugs in your code ASAP, rather than 5 months down the line when the code base has increased by a factor of 10!

So doing the Koans today really hit home how important TDD is to writing code that works. I’d been stuck on a particular exercise when I attempted the Koans a few weeks ago (it was on our pre-reading list) but once I started writing code which focused on making each test pass, I

a) stopped trying to figure out what ALL of my code was going to look like before writing it

and

b) managed to get onto the next exercise!

One last thing to note is that although there is an online version of the Koans available, it really is worthwhile (and easier) to download the code and run it on your own computer. Firstly, because you’re able to format your code so that it is easier to read (no tabs in HTML input forms) and second, because it replicates and encourages realistic TDD practices – run test, watch it fail, write code to pass the test, repeat.

******************************************************************

I stayed a little later tonight to finish all of the Koans – what can I say, I was encouraged by my little piece of success – and so will get a chance to apply some of my Ruby knowledge to figuring out actual problems on my own this week. As it always is with languages (both regular and programming), my reading/understanding of other people’s code far outstrips my writing ability.