After a busy weekend coding, I managed to get a simple Twitter application working. It’s not anything to look at, but it fulfils the basic functionality requirements, and that’s all that matters for now. Having said that, I’m building up quite a few projects where the functionality has been completed, but the design leaves much to be desired. I better start practising soon since how a site or app looks is incredibly important with regards to how long your potential users want to stick around for.
I paced myself and worked methodically through the task, taking full advantage of the Friday to Sunday time limit. There were a few stumbling points, as is inevitable when completing a task of this nature, but one set of failing tests took me a good few hours to decipher. My first test was to ascertain that previously submitted ‘peeps’ (i.e. tweets), could be viewed on the homepage by anyone who visited it, whether they were logged in or not. Later on, I had to attach a user to peeps, in order to display the username of the person who wrote the peep beside the message. After writing this test and passing it, my first test began to fail. I thought I had broken the code somewhere, but couldn’t find the problem. It was only after going into my database that I discovered the problem. I had fundamentally changed the properties held by instances of the Peep class. They now all had to have a user id, and since the initial test peep didn’t have a user attached to it, that property was coming up as ‘null’, causing the test to fail. When in doubt, check the database.
Next step is to apply the same principles to a ‘Rock-paper-scissors-lizard-Spock’ game! Shouldn’t be too tricky, but we’ve got to make sure we get the messages just right: scissors don’t just ‘beat’ lizard, scissors decapitate lizard.