Reading failing test messages does help

After about four weeks of being at Makers Academy, I am finally coming to terms with writing tests. They actually do seem helpful, haha! I can actually now depend on my tests to tell me, why my programme isn’t working. Before, I didn’t really trust myself to write tests that tell the truth, but during last weekend’s challenge, most of the time, when I just saw a failing test and thought I knew why it was failing but didn’t read the error properly, it would take me ages to figure out what was wrong, just to find out that my tests were screaming at me (for example: “YOU HAVE TWO BUTTONS WITH THE SAME NAME ON THE PAGE! AMBIGUOUS! CHANGE THAT NOW!”).

The fun I have ….

For anyone interested, here’s my turn on creating a twitter clone: https://chittr-here.herokuapp.com (More info can be found on my Github: https://github.com/AnnemarieKohler/chitter-challenge). I didn’t have much time left to do much CSS, so next week during lab week, I want to polish it up a bit more. CSS is dangerous though, before you know it, 3hours have passed to find the perfect border colour…

Week 2: weekend challenge

The weekend challenge for week 2 at Makers, was making a takeaway application. It should allow the user to look at the menu, chose food to buy, see the total and pay for the whole lot, when the payment was successful, the customer should receive a text to their mobile with a confirmation and a time of the delivery. We used a service called Twilio for the texting.

If you’re interested, you can take a look at my attempt here.

First, I was a bit worried about using an API, as we hadn’t done this during the week, but actually the hardest bit, again, was Rspec and mocking out the Twilio/texts, so that there weren’t any texts sent, every time I run my tests. This could be resolved by using dependency inversion and thus injecting the twilio class into my OrderConfirmation class.

I’ve finished it but there are still a few things, I would like to update in the course of this week, such as changing the hard-coded menu and extracting it to a YAML file, or checking for refactoring some of the Ruby as well. The coaches have also provided some of their solutions, so I see if I can learn something from them too 🙂

Week 2 day 1

Today, we were supposed to have our code reviewed by out mentor. Unfortunately, not every mentor showed up, so Ive had a group review with 3 other students and two mentors.

The guys doing the review with us were doing their best but at the end of it, we spent a really long time on it, no one had actually looked at my code and I filled out my review myself..

Later in the day my mentor offered to review my code remotely. So looking forward to that. Our coaches also check our code and message us if there are any red flags. I haven’t received anything so I’m taking this as a good sign for now.

We also had kick off meeting in the afternoon with coaches. There we talked about common errors they’ve found from students and introduced us to this week’s challenge: Building an oystercard programme. Sounds good 🙂

I felt pretty exhausted and kind off worn out today. I guess since I spent pretty much all of my weekend on the challenge, I didn’t really rest. Next weekend, I’m meeting a friend for Brünch which will force me to leave the house and get away from my laptop for a bit.

I also want to try yoga this week. Just to see if I like it 😊.

Week 1: Weekend challenge

Our first weekend challenge is writing an airport programme. The airport can make planes land and take off, when the weather is nice – but be careful when it’s stormy.

The whole week was all about learning Rspec and the test-driven approach. I have to admit, I’m not in love with Rspec. Not at all.

[rant start] I find it still very frustrating to spend ages on figuring out how to write a test, if I can write the actual method for my programme a lot quicker. I just trust in the system that is Maker’s to know best, and will hopefully get used to it (so I’ve been told by seniors – they actually had some kind words for Rspec … these won’t be found in the Feb cohort atm…).

Another thing, which doesn’t make writing the specs any easier, is that Rspec had the brilliant idea to update their syntax. While the new syntax is probably the latest jazz in writing specs, it is SO annoying because much of the resource material is now outdated. And their is so. much. outdated. stuff! Even seemingly great resources like code school, who made a rap song about Rspec, have now outdated should-syntax. An up-to-date resource is, apart from official docs, is betterspecs.org which has been suggested during on of our stand ups. [/rant end]

That felt good, sorrynotsorry about that.

Back to the actual topic: Weekend challenge! It is exactly that, a challenge! Naturally we can use a lot from material we covered during the week, but have to adapt it accordingly. I still find that I often overcomplicate things, and try to do more that I actually should or test things, that don’t need to be tested.. and there is this one test, I shouldn’t pass but get a green…oops. Still working on that. 😛

Tomorrow I think, we’ll get together with our seniors and discuss the code we’re written for the weekend challenge. We’ll see how that goes.

✈️