Learning Outcomes - 23rd March

The past few days I’ve focused my learning on 2 main outcomes.

1. Persisting Data
   I used two approaches for persisting the data:
   
   a) Files
   I stored the state of every game in a JSON file with an ID as the key for differentiating each game. One of the setbacks with this approach was that the app may not have permission to write to the File System of the computer.
   
   While testing this, I initially used checks like `File.exists?(@filename)` to assert that the file was created. This would break the code in case I changed the naming convention of the files.
   
   To address the above issues, I decided to use FakeFS which doesn’t actually create the directories so, therefore, the tests would pass even on an environment without write permissions to the file system.
   
   b) Data Structures
   The second approach I used to persist the data was using data structures, particularly a hash.
   This wasn’t something new but it made the application easier to test, decoupling the implementation with tests which is something that I am still learning to master.
   

2. Debugging
   The second outcome I’ve focused on is debugging techniques. I’ve learnt to do this in 2 ways:
   
   a) Shortening the feedback loop
   While trying to install the tic tac toe gem in the web API gem, I realised I had to constantly change some implementations to create further abstractions, etc. So the process was make the change in the tic tac toe gem, build the gem, re-install the gem, update the gem in the web API gem, then test it out. Only to find that it fails and I had to repeat the cycle.
   
   To shorten the feedback, I learnt some few commands that allowed me to edit the installed gem and update it directly from the path in which it installed, this changed the cycle from 4 or so steps to 2, thus increasing my efficiency.
   
   Some of the commands are:
   $gem list - lists all the installed gems
   $gem env - which lists the paths of installed gems
   $vi <filename> - creates a temp .swp file that allows you to edit the files.
   
   b) Reading the error messages
   I learnt the importance of this after being stuck on a problem for about 4 hours only to realise that the error message was providing all the information I needed to resolve this. The one key thing I was missing was how to get to the error messages.
   
   While refactoring the code, the tests began to fail and I couldn’t figure out why. The problem was that the assertions I made of the response from a RESTFUL action were what was failing but I couldn’t find out exactly why. I learnt that there is a way to log errors. In Sinatra, you use puts last_response.errors to print them to the console.
   
   This line eased my refactoring process, by pinpointing the line where the break occurred with a descriptive error message.

My next goals are to focus on Null Object Pattern, Abstraction and Polymorphism.