RSpec: How to stub a random variable (make the weather as you need it to be)


In our last challenge there was an airport that gave or declined landing permission for planes based on the weather. There was no real weather forecast, I just generated a random weather:

def generate_weather
[:sunny, :sunny, :sunny, :stormy].shuffle.first

The Ruby-method .shuffle randomly mixes the values within the array and .first than takes the first value out.

RSpec test: force the function return a specific value

I implemented an if-statement in my landing- and take-off-procedures. So that a plane could only land if weather was sunny. But the if-statement made the tests randomly fail I had written to check those methods. Very annoying. Red type all over my terminal.

Luckily RSpec gives you the possibility to stub methods. I didn’t quite understand how that works. But now that I have understood I try to explain it out of a beginner’s perspective:

If I want my generate_weather method (above) for testing-purposes to return always :stormy, I set the following line in the beginning of my RSpec-Test:

expect(plane).to receive(:generate_weather).and_return(:stormy)

Translation: If the method generate_weather is sent to the object plane, it will return :stormy – no matter what generate_weather actually generated.

Syntactic sugar, cold rooms – I’m getting used to it (week 1/12)


My first week at Makers is over. And if I keep learning new things at that pace I might actually be a Maker in the end. We have started with Test-driven development and the attempt to program a bike rental service. Yesterday I was sitting in a cafe in Kentish Town writing code for this weekend’s challenge. It’s similar to „Boris Bikes“ but now I have to manage airplane traffic around an airport.

It’s so much fun to solve those little problems and see my tests pass. But it has taken me a while to get going. Every time I started feeling comfortable with one of the new concepts last week, there was a lecture leaving me puzzled again. I had just understood how to get bikes out of my virtual docking station into the van, when our coach Ben told us about Encapsulation and public interfaces. That said my van was no longer allowed to go get the broken bikes. It is supposed to tell the docking station to release the bikes and dock them afterwards. Sounds like a minor change but it actually made me rethink and write my whole code again.

There have been „duck types“, „polymorphism“, ruby’s „syntactic sugar“ classes, methods and modules. Doubles, instance variables getters and setters. I don’t want to bore you with this stuff. But it’s really cool how it all starts playing together.

There was some „real life“ this week as well. I got used to the draughty house I’m staying at. I saw a group of Hare Krishnas dancing around Trafalgar Square, started tracking down London’s best independent coffee venues and got to know my fellow students. A wide range of talent and experience starting with former lawyers, designers and ending with Costas who has made his living playing Poker before.

Oh. And I’m looking for a place to stay somewhere in London. From February 27th until April 6th. Your hints are very welcome!

TDD – My first major obstacle


For someone like me, new to development, it sounds really strange to write a test before having a function or product ready. But anybody at Makers Academy is a 100% convinced that the so called technique of “Test Driven Development” (TDD) is absolutely essential for writing good, maintainable code.

What it is and how it works (non-technically spoken)

In TDD developers at first break their problem down into objects and actions. In our first week’s project we are dealing with the famous London „Boris Bikes”. Those can be rented and occasionally they have to be fixed. There are some more objects like a van that comes to fetch broken bikes and so on… but let’s focus on those bikes at first.

The project is not about building a shiny website on which people can rent bikes. It’s about inventing a model that reflects those processes in Ruby-code. I can make up a (code-)bike by writing:

class Bike

bike1 =

Between “Bike” and “end” I can later on define, that our virtual bikes are initially in good conditions, until someone calls my newly invented “method” called “break!“ that breaks the bike (even though you might be interested in how people break the bikes – that’s [again] not part of the game). Building those objects and features doesn’t seem to be so difficult at first. But actually it’s really hard to find the details, the program should in the end focus on. I found myself thinking about the users and what they do when their bikes break somewhere on the way. But that’s not part of my project.

Back to TDD. Before we are allowed to invent our tiny complexity-reduced world, our coaches Stephen and Mihai expect us to write tests that will check the code we write.

Irritating „natural language“

I don’t know many developers but the ones I have heard talking about code were really excited about programming language that actually reads like English. From my perspective this is a very silly thing. I want to learn a language that my computer understands but this language turns out to be some awkward dialect of English. It’s good that I can guess what a method called “concatenate“ does or what happens when I use operators like „if“, „else“ or „unless“. But there are so many ways to say that the docking station for bikes is full that are easier to guess than that one:

it 'should not accept a bike if it\'s full' do
expect(lambda { station.dock(bike) }).to raise_error(RuntimeError, 'Station is full')

I trust them…

Stephen would most probably say that this code needed some refactoring to be better readable and that there are a 1000 different ways to “say” this in code. I have decided to trust him and the other teachers. Obviously people can learn how to read and write this language fluently. And I really want to learn that as well.

“know_code? if false – keep_reading. else ‘hurray!’“

Why we came…


„You have paid a whole lot of money, firstly to learn how to learn, and secondly, to learn how to code“ – Ruben Kostucki (@rubenkostucki), placement officer at Makers Academy.

After his and some other introducing talks, we started with what I came for: coding. I am sure that learning how to code will be hard. Hopefully the learning skills, Ruben was talking about, will make that doable.

Let’s go!


It’s 8.15 am. Within 15 minutes I will start a 12-week-programming-bootcamp at Makers Academy in London.

I’ve come quite a long way. I’ve resigned from my job as an editor for Oberhessische Presse. I’ve left my dear colleagues and my beloved flat in Marburg. But I’m sure it’s worth it. Within the upcoming eight month I want to explore new ways of making online journalism. And learning how to program is my first step.

„Breakfast is ready“ they write on Slack. Let’s go!