This last week has been the most frustrating of all so far.
On Monday morning, Enrique set the scene for the week by projecting the trailer of ‘Battleship’ onto a large wall at Makers, blasting out the sound of the dramatic music and multiple explosions. I quickly checked the imdb rating. 5.8. Not one to add to the ‘to watch’ list then.
There’s always reason in Enrique’s ways, and we quickly cottoned on that the task of the day would be to implement a game of Battleships, which could then be loaded into a server that was set up to handle the user interface. We were to be in bigger groups than normal; teams of four or five. Initially my team spent some time reading through the accompanying notes, before coming together to discuss potential approaches. This is the point at which we realised that the problem was far harder than we had imagined, and this is often the case when I’ve had to approach a new coding problem: in my head, I think I can visualise how it’s going to work, but once I start trying to articulate it to someone else, I realise that I have no clue of how the whole thing is going to come together.
The first thing we had to make a decision on was how a new 10×10 grid would be populated with ships. Is the board grid initialised with the ships already there, or does the player take an empty grid and place the ships? The former seemed more straightforward. The second thing was how we were to handle the ‘ship’ objects – were they just represented by ’s’ characters, or should we create a Ship class? We opted for the former again. If we managed to get it working with single characters, surely it wouldn’t be so hard to include actual Ship objects, right? Right?
Well, rarely is something ever as easy as it seems in coding. But we shouldn’t expect it to be. The teachers have thought long and hard about projects that will be sufficiently challenging for everybody. After hours of working at it, our team had gotten into a muddle, unsure of what exactly each class was meant to be doing, and how each of them interacted. This really made me see the importance of planning out your project before writing a single line of code. Sometimes I think to myself “well, I’m not entirely sure how that will work out, but I’ll worry about it when I get there…” Bad, bad move…
…as I learnt, when Michael and I did the same thing when approaching the second task of the week, a Sudoku solver. To our credit, we did spend at least 30 minutes discussing the problem before writing any code, but rather than thinking about whether we’d fully thought it through, we thought ‘we’ve been thinking for 30 minutes. That’s good!’
Michael and I worked hard on our Sudoku problem for three days, but we were doomed to failure because of the bad design decisions we made at the very beginning. A couple of good approaches would involve either making your grid do all of the work, or making your cells do all of the work. For some reason, Michael and I decided that an approach half-way between the two was a good idea: the cells knew some information about themselves, but only the grid knew everything about all of the cells, and so it was the grid’s job to ‘help’ each cell solve itself, by providing it with vital missing information. That last sentence was probably confusing to follow. It’s indicative of how difficult it was to follow the code we’d written. So, I came to the end of the week with two messy unfinished projects. Things did not bode well for the Friday challenge, and I wasn’t in a great headspace to start something new.
The challenge came in two parts this week. The first was to reopen the Array class and rewrite the inject method. The second was to write a Takeaway class, where you could print a list of dishes, and a customer could place an order, receiving an error if the order total was incorrect, or receiving a friendly text if all details were correct. I was unsure where to start, but made myself a promise given how the week had gone: I would not write a single line of code until I had thought about how the whole project would unfold, given passing tests. So, it meant it was almost two hours before I wrote any code, and in that time I had done a lot of reading, thinking, and writing. This method was to pay off. It didn’t take me long before I had a working inject method and could start working on part two.
I found writing the Takeaway class tricker, especially implementing the Twilio API and Time class into my rspec tests, but after persevering for two days, I managed to get the whole thing working. It was very satisfying to run the programme and moments later receive a text to my phone, complete with my custom message!
Well, I think I’ve successfully completed the challenge, but Enrique may think differently. I’ve just sent it off to him, so I’ll have to wait and see…