After a week of making a basic web app, our weekend challenge was to build a game that allowed a user to play rock paper scissors against a computer. I felt happy with the process I went through to make it, and was pleased with my result, even if it didn’t look as shiny as some of those that were presented. One of the biggest benefits I have gained from the web challenges is feeling much more comfortable with test driven development. Whenever I set up a directory for a web app, one of the first things I do is write my initial test cases based on what I expect my program to do. The fact that I need to write both feature and unit tests means that I am very aware of how I need my software to behave, both behind the scenes and for the end-user.
Since the end of last week I’ve learned more specific things with regard to writing good code. This largely came out of the process of refactoring code that I had already written to make it more elegant and less prone to bugs:
- I learned how to get rid of global variables, which was very satisfying when I eventually achieved it. Initially our app from last week was full of references to a global variable, and it took a bit of thinking to work out how to avoid this. Getting rid of global variables seems to play a role in a bigger picture of the best practices of how to refer to objects. Knowing when and how to instantiate an object, and how to subsequently refer to it is a constant battle when developing pieces of software with component parts. I feel like I am gradually getting better at recognising which types of object instantiation and reference are most hazardous, as well as ways to mitigate these problems when they occur. Refactoring my code has been a great exercise in getting me to think ‘how can I wrap this object in a method, such that I can still use it for its designed purpose?’ or ‘how can I call a method on a class instance while minimising the risk of dependency?’ I hope these things will help to make me a better programmer.
- I have found the range of neat tricks available pretty exciting, especially when making a game that requires logic at the controller level as well as the model level. At first, each request definition had looked like a container for sequential instructions. In a way they are, but there are a range of nice tricks you can use within them, such as choosing which page to render based on the output of a function; both elegant and a nice way of extracting logic from the controller and adding it to the model.
We had some awesome displays in the presentation of people’s weekend challenges. Gifs abounded, as well as a result display which Rickrolled the user, no matter what their outcome. When we discussed feedback on the designs, the only piece I might have questioned was the advice to remove modular arithmetic from the model in a game of Rock, Paper, Scissors, Lizard, Spock (etc), in favour of a rules display featuring hashes and arrays. The rationale of the developer for using modular arithmetic was that it could be easily extended to accommodate thousands of choices (god forbid), however Roi’s claim was that it was not very readable, and as such, it would be best to optimise for how interpretable a future developer would find it. I suppose the best way to approach this case is to exercise common sense and allow for extendability only if this is a plausible possibility, and to maximise readability by default. What remains of the mathematician in me is still a little dismayed about this, but I’ll get over it.
One of the strongest convictions I have reached since starting at Makers has been that I have been much more excited about back end design than front end design. This seems to be an opinion I share with lots of the other students I have spoken to about it. I shouldn’t be surprised. We signed up to a programming course in Ruby to discover that we’re happiest when programming in Ruby. I’m aware that I am still in the very early stages of my journey, but I think this is an important conviction to have come to. I plan to watch closely in the coming weeks to see if my feelings change or get stronger.
At the end of the day we started working on databases, which is a unit I am feeling pretty confident about. We’ll see what comes our way this week, but my hope is that the work is interesting and plays to my strengths. I look forward to my next retrospective, and to the things I will learn about the course and myself in the coming week.
Things I have learned in three weeks
On a broader level, since starting Makers I feel like I have learned a huge amount about the following:
- Test Driven Development
- Ruby: It is starting to feel familiar to me, and when I learn about a new project, I get a sweeping feeling of relief when I hear ‘the back end is written in Ruby’ or even ‘there’s an interface which interprets the whole thing in Ruby’. I think this feeling of comfort is coming hand-in-hand with a greater sense of confidence.
- Design principles and best practices: I’m very glad that these are drilled into us so forcefully, and I am gradually understanding how they will help us as future developers. Just now I looked at some of my Codewars challenge solutions from before I started the course, and my god they are awful. I think it proves how much you can do in two weeks.
- The basics of developing things for the web: My knowledge of this is still in its earliest stages, but is a concrete and practical skill that I foresee being valuable.
One thing I need to be aware of at this stage is remembering to stay aware of the basics. Learning about design principles and file structures will only get you so far if you have forgotten how a hash works! Ultimately this will come down to making sure that I practice, and I plan to do a lot of that in the coming weeks.