I was browsing through Netflix trying to find something to fill the room with white noise while I studied when I decided on Fantasia. At one point during the movie, the conductor turns towards the audience to explain the concept behind one of the pieces; Sorcerer’s Apprentice. An apprentice tried to use magic that he couldn’t control and wasn’t stopped until his master came to fix the situation. I think programming has a lot of these situations and the scariest mistake for me is deployment.

Even little tests apps scare me because of the possibility that I’m sharing api keys or passwords. Right now, the only key I’m using that shouldn’t be in the repository is the SECRET_KEY_BASE generated by rake secret. I’m currently learning about the use of dotenv which extracts the key into a .env file and substitutes an environment variable in config/secrets.yml. Before this method, I wouldn’t commit the secrets.yml into the repository.

With a particular app, I was having problems with deploying it after I updated the gems. I incrementally updated Rails and Ruby versions making sure that all the tests pass. Because of this process, I was sure that the problem involves the database or gem/feature I added but didn’t test. The app was hosted on heroku and the first thing I did was look at the log by running heroku logs --tail. I wasn’t sure what the error message was saying so my first instinct was to reproduce the situation on my computer.

Before this, I was using vagrant to configure my environment and the Vagrantfile was configuring the database for me. Now that I’ve installed Ubuntu Gnome on my computer, I needed to create a Postgres database for a local development environment along with an associated user. After installing Postgres, I created a database and an associated user for the app.

Postgres commands I needed to use: Stackoverflow link

create user username with password 'password';

alter user username superuser;

create database projectname_development;

grant all privileges on database projectname_development to username;

Fixing the problem

After going through these steps and connecting Postgres with the development environment by editing the database.yml file, I found the same error recorded at the heroku logs. The error message was saying that it was using a Ruby version 2.2.0 when I was using 2.2.1 and that there was a problem parsing the yaml file of the Jekyll blog. I was able to fix it on my computer by resetting rvm and making sure it was using the correct Ruby version, but I didn’t know how to do the same thing for heroku. Based on the messages during deployment, the problem seems like it originates from my Gemfile.lock file. I originally started working on the app in a Windows environment, migrating it to a virtual machine through Vagrant, and then to an Ubuntu laptop now. Heroku had to redo bundle install after each deployment because of the fact that it doesn’t use the Gemfile.lock file due to the Windows line endings.

I deleted that file and reran bundle install. Also, since the bloggy gem was throwing the error and I was already planning to remove it in the future, I decided to uninstall it as well. I’m aiming to add a different blogging engine or a basic Rails one so that the layouts would not be separate from the Rails app. This way, I would be able to write unit tests for it in the future. Jekyll is a static site generator and I don’t know how to create a proper test for it besides making sure that jekyll build wasn’t throwing any errors. Afterwards, heroku run rake db:migrate was successful and the app was running again.

Links I’ve been reading

• Ruby 2.1 - Fun with underscores, ampersands and asterisks: I’ve used asterisks as a splat operator and ampersands for blocks but this is the first time that I’ve seen underscores used to fill in for an unneeded argument.

• A Closer Look at Test Spies: This article is exploring the use of the spy method instead of double to set up tests. The main difference is using the spy method would automatically spy on all methods without having to stub it out. The main issue is that stubbing is usually a good indicator of the class’s design. You should’t have to stub multiple methods to pass a test for classes that are designed well because it would have to many responsibilities

• Hooks: I’ve only seen extended and included as hooks and this blog post provides a whole list of hooks used in Ruby.

• Understanding Rack Apps and Middleware: This is an in-depth post about Rack. I’ve read about them from different articles before but this one incorporates a lot of information into a single post.

• Nginx Guide: Introduction: This article is an introduction of what Nginx is and its advantages. I’m not familiar with how servers are set up because Heroku handles it’s management but it’s something I want to learn more about in the future.

• Animation Principles for the Web: This article applies Disney’s 12 Principles of Animation to CSS. I was introduced to those CSS properties in Upcase’s CSS trails and this article was trying to illustrate how to use those properties effectively.

• Ruby on Rails Podcast: Darrell Silver from Thinkful: I was listening to this podcast and the part where Sean Devine talked about his experience trying a service that helps beginners resonated with me. He talked about the other person’s guilt because they had been working so much and they felt like they should already know the answer. Even though the solution was technically simple, the host was saying most of the problem was dealing with that guilt and leading them to a place where they could program again.