Its amazing how good it feels to overcome challenges as I learn web development!
Over the past couple of sessions with John Davison at AirPair, the main theme has been rooted in concurrency. Today I want to share how I, through John’s direction, was able to overcome the challenge of pushing my EventOrchid rails application to Heroku. The focus will be on 2 areas:
- Our local server log
- And our Heroku logs
Reading our local server logs
The first place a newbie rails developer learns to solve their problems is probably google, which hopefully pulls up an associated stack overflow question. After some recent instruction however, it can be substantially more time efficient to start off my debug by looking at the server logs. The logs can look a bit overwhelming when you have your first peak or two at it. At least that was the case for me, but after several attempts at browsing them, one can sort of notice where to place closer attention and where to breeze by, at least initially.
Take a look:
The above screen shot simply shows that our project has started up. The ‘Processing by StaticPagesController#index as HTML’ line towards the upper portion of the image is just a log representing that the application has tried to access the
root_path. It then renders the associated layout views and returns a status 200, which means the following: Lets create a routing error for the purpose of showing how the logs can guide us towards isolation of our software error. We can just comment out the root to: “static_pages#index line from our routes in config/routes.rb. Now with that commented out temporarily, lets check what the log will show upon trying to access our application’s home page. After the
GET request for our
root_path, our local server logs display an
ActionController::RoutingError and shows which route isn’t being accessed properly. The stacktrace underneath all of that, shows all the files taking part during the process of serving our home page to the client.
Reading our Heroku Logs
Well thats great Ramon! But how does looking at my local logs help me debug Heroku? There are similarities that will hopefully become apparent shortly, but you would be mostly correct. There are a small series of different steps to display Heroku server output. Lets get into it.
Just as we would for our local server. Getting started with a look into our Heroku logs, will have us starting off by opening a new tab in our Terminal. On a mac, if our terminal is already open, we can create a new terminal tab by hitting
command or apple key, plus the
T key on our keyboard. Now we just change directory to our application which could look something like this
Your rails app folder name and application name will most likely be slightly different. Once we’ve done that we can type
heroku logs --tail into our terminal and we’d get output that could look something like this:
Heroku logs --tail, specifically the
--tail argument is called a realtime tail. Here’s a quote from the Heroku docs.
Similar to tail -f, realtime tail displays recent logs and leaves the session open for realtime logs to stream in. By viewing a live stream of logs from your app, you can gain insight into the behavior of your live application and debug current problems.
The Heroku docs link above the blockquote is a link to the Heroku Docs, and is an easy to follow resource for answering most, if not all, Heroku on Rails questions. There are also quite a few more commands available to peruse at our leisure, but are outside the scope of this blog post.
John Davison, one of my AirPair mentors has been very instrumental in helping me feel more comfortable making sense of logs. In fact, if you’re even remotely thinking of using AirPair or learning Ruby/Rails for the first time, consider scheduling an hour or two with him. You will feel like another dimension has been opened in your understanding of web development, and problem solving in general. My next post will be based on our session today.