Sinatra, Capybara and The Web
Week 5 saw us tackle the wide world of the world wide web. Using our beloved ruby along with some extra tools this week we were able to code and create some simple web apps. Specifically we looked to use:
- Sinatra, an open source software web application library and domain-specific language in Ruby, complete with a trilby hat logo and frequent references to the singer.
- Capybara: Unfortunately not the friendly South American giant rodent, instead a web-based test automation software that simulates scenarios for user stories and automates web application testing for behaviour-driven software development. Useful yes. As cute as the animal? Definitely not.
- Some basic HTML and CSS coding
Lot’s of new tools, new syntax and just generally a lot of new information and thinking to process in a short space of time. At times this was definitely confusing, but overall an enjoyable week.
We began the week with a review of last Friday’s individual challenge. More comfortable with having someone else look over my precious code baby this week, I found the activity even more useful than before. This, in part, was helped by my review partner having done a different challenge to me. It was good to look at someone’s code completely fresh, I had a vague idea what the program should do but hadn’t personally spent hours getting to grips with the intricacies of the challenge. This unfamiliarity meant, not only did I have to review the code, I first had to understand what it was actually trying to do. Like learning any language, being able to read and comprehend text is an important step in developing your own speaking and writing, this is no different in coding. With that in mind, I was pleased with myself in that I not only understood what each part of the code was doing, I could begin to analyse how effective it was and make some tentative suggestions for further improvements. I’m definitely moving up that pyramid of Bloom’s taxonomy!
The week followed the familiar format and after a kick-off workshop in the morning we were straight into our pair challenge for the week. We had decided as a cohort that we preferred to stick with our partner for the whole week, rather than chopping and changing which gave us some time to build a rapport and a pattern to our working style. My partner and I began our new challenge, working through the guidance. Admittedly the first couple of days involved a lot of reading, setting up systems, following walkthroughs and not fully understanding what was going on. By day 3 though, things had started to make a bit more sense.
After we had tackled the introductory content and the setup challenges we were tasked with creating a simple game called Battle. The game would involve two players, they could enter their names, see them displayed on the web page alongside their hit points. The players could then attack each other in turn by pressing a button and eventually decrease each other’s health to zero. Not exactly the next Mortal Kombat but a good exercise.
The main struggles of the week came in keeping track of everything. We quickly found that when building a web app, a good naming and filing system is key. We had our controller (the main app.rb file), other ruby files with code for the elements of our game, a folder of view files containing the html for various pages along with a whole bunch of different feature tests and unit tests in a variety of folders and files. It was easy to get lost pretty quickly. In order to keep our code DRY (don’t repeat yourself) and utilise the MVC pattern (model, view, controller) it was essential we named things accurately and separated logic appropriately. For example, our controller should have as little logic as possible, directing to other ruby class files when appropriate. Similarly our view files should purely contain instructions for how the page would look and should call on code from other files to render the correct players names and health points.
Interestingly I found keeping track of what did what and understanding how changes in one file would affect another to be relatively instinctive. However, when I tried to explain what was happening at each stage and describe the process step by step to my partner, I got a bit lost. Clearly, whilst I felt able to tinker and tweak elements of the code to improve and experiment, I didn’t have a full grasp of what I was doing at each stage. If I had, I’m sure my explanations would have been much more coherent and less like the mad ramblings of an eccentric scientist desperately trying to prove their latest conspiracy theory.
Nevertheless, after arguing with the walkthrough, countless error messages and calls for help to our trainer we did eventually complete the challenge. As it turns out the challenge was aptly named as the whole week did feel a bit like a battle with the code, but I am delighted to say, we won.
Fresh from our paired victory with barely a moment to celebrate, we were straight into the individual challenge of the week; create a web app that lets you play rock, paper, scissors. Sounds simple enough, it’s a straightforward game, there’s a limited number of combinations, the logic should work out. And it did, but perhaps not as clearly and quickly as I had hoped.
I started the day well, quickly implementing the feature allowing players to enter names. Things got a bit tricker when I added the selection of weapons, but I battled through and managed to get that to work. The real challenge brought me back to the struggles of earlier in the week, as I tried to keep my code DRY and separate responsibilities to appropriate files. I did eventually get my game to work, but at times, I again, felt scattered. Despite a workshop on debugging earlier in the week, my method often felt random; change this here, tweak this there, cross your fingers and hope for the best. Ultimately I completed the task, but feel I have improvements to make in terms of my process.
Overall, I enjoyed this week, perhaps more than others before. Despite the frustrations along the way, things often felt instinctive and I rarely met a complete road-block, generally having an idea of the direction to take next even if I couldn’t fully articulate my reasoning. I’ve learnt some good lessons too;
- Keep things tidy and well named,
- Follow a process and stick to it, changing things at whim won’t always see you through
- To teach something without sounding like a crazed conspiracy theorist you need to really understand it.
