Today we resumed work on the extended Chitter challenge. We created a nice interface and sorted out some of the navigation issues, so the whole thing looks like more of a working product now. We definitely learnt a lot from the project, even if it was slow progress. One of the most difficult things is working out the correct datamapper commands for your normal SQL processes. Having barely touched upon joining SQL tables in this course didn’t help matters! As always, we’d been given just enough information to go away and find the solutions for ourselves.

This evening I made the finishing touches to my Chitter repo, correcting things like the below

validates_uniqueness_of :email, :username

which became the last part of this line

property :email, String, unique: true

Want to know why? Well, the first statement only validates the uniqueness of an email address on the application level, whereas the latter checks it at the database level. This means any data entered directly, or a duplicate entry happening at the very same moment would not be rejected and you may end up with two of the same email address in your database. Not ideal really.

Other fixes involved moving a couple of stray bits of logic away from the display files and into the backend where they belong, and making sure that a full time object is stored in the database for each peep instead of the ‘pretty time’ string I had created. As usual, the time is made pretty on the front end, where the display logic lives. This is the third time I’ve had cause to mention separation of display logic and backend logic in recent posts. It does seem to be a major theme these days now that we’ve moved into full stack development.

Another silly thing I’d done was duplicate the username in both my user and peeps tables (lets just call peeps messages from now on, since peeps is such a silly word). This is uneccessary information since the tables are associated by a key already. The correct way to pull the username for a particular message out is to
• look through the Message table to find that message’s associated user ID
• find that user ID in the Users table and pull out the associated username
It sounds a bit longwinded but it’s really not, and it’s better than having a messy database.

I discovered a cool gem called Timecop which can actually freeze time! In a testing sense that is. One of its many functions is to stub the time with a value you give it, so that your tests can be accurate and don’t depend on the real time, which by its very nature changes a lot.

Timecop.freeze(Time.local(2015))
post(peep)
expect(page).to have_content("00:00 01/01/2015")
Timecop.return

After that I had a look through my bowling challenge again, and converted it to a bowling scorecard which relies on user input instead of random numbers. This was a fairly painless process and took about 5 minutes! It’s very satisfying seeing my 37 red tests go green in such a short space of time. The next tasks for my ever evolving bowling project are creating an interface and adding in something which outputs the score obtained by each round. At the moment strike bonuses are being simply added into the pot rather than attributed to the appropriate rounds. More on this another day though..

Nat x