Here’s a quick recap from last week:
The most important things I learnt, were being clear and open in communicating with your pair partner. It makes a huge difference and the pairing experience with them a lot better. Otherwise, it’s 8 hours of ego battling, which isn’t why I’m doing this course.
On the technical side, is probably dependency inversion, which seemed hard to grasp at first, as our projects are so small, and I could easily just use the actual class. However, I’ve learnt it’s about maintainability and writing scalable code.
I’ve also started reading Sandi Metz’s Practical Object-Oriented Design in Ruby, which seems very helpful so far.
I’ve probably struggled most with getting my head around mocking in rspec, when to do it, when not to do it. It can feel like I’m just cheating my way through my rspec….
For this week, I want to give more feedback to my partners. I’ve noticed some pairs have been giving each other feedback during the day (just before lunch), so I might start doing that as well. Just to see how my partner is feeling and tell them how I feel / am getting on.
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 🙂
It seems this whole week the pairing is the most intense aspect of the course. As we pair with a new partner everyday, there are two code bases to choose from everyday, and we always use the code base that is behind. This helps a) the person to not miss anything and b) requires the partner who’s ahead to explain and redo some of the exercises and think about it again.
Today’s difficulty was, that we weren’t starting with my code base. This was the first time in the past two weeks. So far, I always had my code which I’ve been working on for a few days, I’d know what it does, where and why. However, looking at someone else’s code is a whole new story.
So I had already done some of the exercises we were doing and so I knew the answers to some of the problems, but me telling my partner my previous solution isn’t going to help anybody… So this clearly showed me, the knowledge gaps I have to fill. (RSpec as usual…)
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.
Last day before the weekend challenge. As mentioned in my previous post, I had redone this week’s challenge and was only about half way through the challenge by the end of Thursday.
Even though the time pressure to finish the challenge was on, I really tried to focus on understanding it.
I also felt that the day was quite disrupted. I go to meditation at 2, which takes 30min. Then there was a marketing photo shoot of the female students for the international women’s day which took up another half and hour (we didn’t have to go but of course I want to promote female devs). Additionally, on Friday’s our cohort has a retrospective where we discuss our week (what we’ve done, learnt etc.). And it also turns out that after the retro the Makers HQ gets into a casual Friday mood (beers, loud chatter, etc). I have to admit I felt a bit stressed and would have preferred a quieter space to work in…
Obviously this wasn’t completely unself-inflicted stress. If I had finished the challenge of course I would have happily joint the Friday celebrations.
So even though, it was helpful to redo the challenge, I lost a day. So from now on I really have to be thorough from the start and make sure when I’m home that I’ve completely understood what was covered that day, so I can focus on moving forward when I’m at Maker’s during the day.
I’m no longer working 9-5, there is no denying!
I hadn’t been quite happy with my knowledge and understanding of the course materials this week, i.e. how rspec works. Therefore I asked my pair partner if we could start from scratch and redo the hole thing!
He had actually redone it the previous day and so I’m very grateful that he started a third time. 🙂 It was definitely a good decision for me as we went through the tasks slowly to make sure to know what every line meant.
The only downside was obviously that we were now behind. I think he’d stayed on after 6, which is what I should’ve done as well I think (oh hinesight)…
The challenge on Wednesday for me were two things:
- Pairing with a new partner, who was more experience than me and therefore had a better and quicker grasp of the concepts we’ve been introduced to.
- Realising how I rushed through RSPEC/documentation the day before and not actually understanding it.
So most of the day I felt like even though we were pairing, and changing who was typing, I didn’t do as much thinking of my own as I would have liked. I probably should have stopped my partner more and just take the time to re-read the documentation, have a few more examples etc. That being said, he was very good as making his thoughts clear and explaining the processes, which was definitely very valuable.
I still felt a bit unsatisfied as I felt way behind my pair (not gonna lie: not an amazing feeling).
So Wednesday evening, after a quick half pint in the Maker’s local and a cheeky Japanese at home, I sat down and started re-reading rspec documentation.
RSPEC I WILL GET YOU!
My second day at Maker’s was our first day of coding. Everyone was randomly assigned a partner and with them we were working through our weekly challenges. For most of us, it was the first time to actually code with a partner for this long. The difficulty with pair programming is to clearly communicate how you think the problem should be solved. However, there were a few cases where I wasn’t even sure how to solve it, let alone tell my partner what I thought is the best way.
We also did more TDD, where you write your tests first before you write an actual line of code. Technically this makes sense, however, sometimes it felt like the instructions and so the tests we were supposed to write, were taking so long, as the steps were so tiny that it could be a bit frustrating. I think I’m just too used to the process of getting stuff done the quickest way possible, and taking small steps isn’t usually the case then.