Week three of Makers Academy: Web Development

The third week of Makers has all been concerned with web applications, and building a web-based battle game. I honestly don’t know where the time has gone in the last few days, or how I got to the stage of building the structure of my game after having been introduced to the client-server relationship just four days before. I have learned a lot about the practical applications of the ruby structures we’ve been building in the last three weeks, as well as a great deal about how websites and web-based interactions work. One of the most startling and comforting feelings I encountered at the end of the week was relief that I was finally working in ruby again, after three days of working with totally new ideas. Given that I could barely code in ruby two and a half weeks ago, this feeling was a big relief!

The basics of the web and building an app

I have felt a little overwhelmed with information from all sorts of sources this week. Rather than the study of ruby, which is pretty self-contained and concisely documented, learning about the web has involved picking up all sorts of tidbits of information from a huge range of places. We learned how URLs work and about the client-server relationship on day 1 of this week. Once we had got going and had made our first repository, we learned about get and post requests, which seemed remarkably simple at the time, although I am less sure now that I fully understand how they work. After a few exercises we installed Sinatra and made a start on the fundamentals of our games.

Making a basic game involved using - and trying to absorb - a lot of random snippets of information. Chrome Devtools was opened once, to never be opened again. We used session data to our advantage at one point, and soon erased our use of it from our code. We continued to make use of get and post requests, and to use forms to set parameters, as well as installing and beginning to use Capybara and Selenium. The focus was very much on learning-by-doing, and finding out about the concepts you’re using as you go.

A huge part of this week has been based around feature testing. We used Capybara to build up sequential feature tests of our game on an automated browser. This turned out to be very satisfying. As Capybara is an add-on to Rspec, the format of our testing was similar to that of the last few weeks, and we were able to build up a suite of test cases that left me feeling confident that my code was working. There is nothing quite like a green set of tests! In the initial stages of building the game, we used only the front-end to display information and perform simple logical steps. Things started to get interesting when we started to delve into ruby to make our game work.

Back to Ruby

One of the most rewarding feelings of the week for me came on day 3, when it became clear that the logic required to make our game perform as needed extended beyond the simple framework we had build. We’d need to start programming in ruby, and to build up the structure of our game using objects and methods, to be called from the front-end when needed. I could suddenly visualise what I could do to set this up, how it could work in practice, and the number of ways I could extend or nuance my program to make it awesome. I felt at home in the knowledge that I had the tools to make something work in ruby - even if it was something as simple and contrived as a tiny game. I realised at this point how much I had accomplished in two weeks thinking about and using ruby every day, and it made me excited at how much more I could do in the coming two months.

The best thing about using ruby to build a practical game is that you get to see how it a user can interact with it in practice. Up until this point, the idea of the ‘interface’ of a program had been relatively theoretical. However in order to make this game, there was a clear distinction between the model of the program - the code making it work - and the controller - which provides access to the code from a browser. It made me start to understand how ruby can be used in practice, and gave me my first real glimpse of understanding of the ‘front-end’, ‘back-end’ distinction, which I had only understood in the abstract up until now. This makes me feel that little bit closer to the real world, which I am aware I will re-enter in a few weeks’ time.

There were pitfalls and hazards on this week’s journey. The most striking being the use of global variables. One of our tasks instructed us to make use of a global variable to create instances of our game and player classes. It was made clear that this was for the purposes of simplicity and convenience, and that in the real world, this was terrible coding practice. We soon saw why, and we startled ourselves by witnessing how much could go wrong when our attributes were overwritten due to the misassignment of global variables. Definitely a lesson for the future.

Lessons and highlights

I am continuing to love the course and the people I am doing it with. The imagination of my cohort was evident in the range of hilarious battle-based games we came up with, including Volkswagen vs Polar bears, and my personal favourite, a game where each player boosts the points of the other, until someone wins by healing their ‘opponent’ completely. We had a group retrospective on Wednesday, and one of the key takeaways from the discussion was that it helps to become comfortable with the idea that we are not going to learn everything at once. The amount there is to learn can seem overwhelming at times, and the pressure to synthesise all the new ideas we’re encountering can make it feel like we have to study and work constantly, just to stay afloat. Knowing that everyone feels this way, and that we all have the support of each other makes the course feel so much less overwhelming. A lesson I’ve taken away from this week is that doing our best and learning at our own pace is the right way to approach our work, and will make the journey ahead of us as healthy and exciting as possible.