With a coffee by my side, I’m about to start this week’s weekend challenge, but I feel like I need to recapitulate what happened this week. Because it feels like a lot!
Part of our weekly challenge was also about using and creating APIs. We’d used the Twilio API in week 2 to get sent a text for a successfully placed order, so I knew APIs were roughly about using other services data or functionality, but that was about it. So I was quite happy that this week, we took API keys apart and had a more closer look, to e.g. get the current weather in my hometown Markkleeberg (was pretty cold); and even created our own API using Sinatra, to store the temperature the user had set on in our interactive thermostat application. To handle the requests we used jQuery’s AJAX methods, also a first 🙂
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!”).
At home, we had a little four-legit visitor last night, which kept us awake for quite some time before we could finally catch him (see below for a picture).
So with my beauty sleep interrupted, I was tired and unmotivated today and couldn’t really get myself to code, which is quite unusual.
I think right now, the constant coding and learning of new things feels very overwhelming, and it is quite crowded in my head. I’ve been programming every day for the past 7 weeks. In the past 4 for probably at least 7 hours a day during the week and who knows how many hours during weekends. Constant learning, pairing, failing/passing/rewriting tests.. This has definitely caught up with me now and I can feel it.
So for me, this Easter weekend feels like a bit of a breather. Even though, not for very long… since next week will be shorter and we’ll have less time to solve the weekly challenge, but there you go! It’s not like I hadn’t been warned about the most intense, but best 12 weeks ever!
As mentioned in my previous post, this week we’ve started with the ruby web framework Sinatra. We’ve also finally started writing actual feature tests, using Capybara. So far all the feature tests were running a file with the methods of the programme in PRY. Now I can specify on a website which button click and which text should appear, seems way more advanced 😛
One important message from this week was: DO NOT USE GLOBAL VARIABLES. THEY’RE EVIL.
We had to promise to each other to not use them again, after this week. We’ve only used them in the beginning of the week before being introduced to class methods, which can do the same job, it seems like. (Memo to self: Need to work on my tech lingo to impress future employers…).
Another takeaway was: There is no such thing as a ‘page’ – it is way more than that. Not just a simple, static HTML file with in-line CSS! That’s so 1999.
Lastly, for the weekend challenge, our task was to build a rock, paper, scissors game. I’m currently trying to deploy that to Heroku, which wasn’t part of the challenge but I want to show my game off to the family. Will share it here as well, as soon as I’ve figured out why my rake is being aborted 😡 !! Here is the link: https://rockpaperscissors-anne.herokuapp.com.
Sorry for the caps. This is so weird, on one side, it feels like I’ve always done this but on the other, it feels not long at all, haha.
Anyways, this week we’re going to start on web stuff: The ruby web framework Sinatra, Heroku and some HTML/CSS. This gives me massive comfort, as I’ve got some experience with that, especially the HTML/CSS I don’t have to stress out. I believe in week 8, we’ll be doing some more advanced HTML/CSS, and then it will probably get a bit crazy.
Yesterday morning, we had our code review and this time, because my mentor let me know that he wouldn’t be there, I grabbed one of the alumni helpers, who looked through my code. This was super helpful, as it showed me exactly where I need to improve my code.
I will probably try and get another mentor, as mine has already graduated and seems too busy to come in. This is a bit annoying, but I’ve already spoken to a coach about this and hope we can find a new mentor, otherwise, I always have to grab a helper, which wouldn’t be ideal but ok.
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.
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…)
The most I took from this day was probably the pairing experience. My partner was already ahead of me and so we had to come to an agreement on the pace with which we both were happy with.
That’s the difficult part with pair programming, you have to move at the slowest partner’s paste. Or else, it’s really only one person writing the programme.
I have made the mistake to not speak up, when it’s going to quickly, because I’m busy trying to understand how it works. So I might just say yes, to not have to talk to the person and get another minute or so to think about the issue. This, I’ve learnt today, is not really helpful. Neither for my partner not for myself.
Today, my pair partner and I got to the harder parts of the Oystercard challenge. It took pretty much all day, a ping pong session, a hula hoop session and many biscuits but we got there in the end and it felt really good!
Part of the challenge was extracting a new class out of an existing one. So far we only had a class for our oystercard and for the station, and our oystercard was storing all of our journeys, doing the fares-pretty much everything. So to follow the single responsibility principle, we extracted the journeys to have its own class. Previously we had stored the start and the journey in a hash and pushed the hash in an array. Now we had our new shiney journey class and could store the info for each journey inan object.
It’s funny how, once you’ve done it, you think “oh yeah that makes sense, why did I even bother with an hash at all?”. Hindsight, huh?