January 31st, Ubud, Bali
After four ridiculously challenging weeks, dozens of cups of coffee, hundreds of hours in front of a computer, and thousands of lines of code, I've finally completed the first segment of Ruby On The Beach in beautiful Bali. This was another massive week of learning about Rails, as we finally began to produce some functional applications and applying the major concepts that we've been exploring for the last month. Today's class even consisted of a massive milestone in our coding journey...deploying a functional application to the internet. Check it out! (Yes, it is undeniably pointless)
My reward? A week off to relax on the pristine beaches of the Gili Islands and do some exploring in remote corners of Bali. This is one of the most unique aspects of Ruby On The Beach's philosophy: just when you think your brain can't possibly hold any more information because it's been grinding non-stop for almost a month, there's a week-long break built into the curriculum to explore our tropical paradise and think about anything besides code. Mentally and physically, I'm going to take full advantage of this opportunity to reset before hitting the ground running for another month long sprint of learning and building.
Week four was particularly challenging because we finally began to wield all the different tools in our programming tool belt and start solving real world problems. One of my favorite projects was almost entirely open-ended: provided with a variety of different data types about the music industry, how would you go about structuring a database to accomplish prospective user goals? After we split into three development teams, each group ran in wildly different directions and started hacking together solutions.
Ultimately, my group settled on the relationship between Artists and Agents. How could we make it easier for new musicians to get discovered and sign with a record label? We quickly pared all of the possibilities into a minimum viable product: artists should be able to upload new music, then agents can vote whether or not they like each song. The resulting application, MusicLink, ended up feeling a whole lot like "Tinder for Music." We had a blast collaborating to build the product; the feeling when all the tiny pieces finally coalesced into a working prototype was truly spectacular.
By focusing on my new mantra of "break time is NOT screen time", I was able to boost my productivity score on RescueTime by 8% this week while taking plenty of mind de-cluttering breaks walking around our gorgeous villa.
My daily habits took a step back this week as I spent way too much time in front of the computer and stressing about unmanageable code blocks. I'm aiming to kick these goals in the butt upon my return from our week off.
What Goes Where? Routes in Rails
Without being consciously aware of it, you send hundreds of HTTP requests on the internet every day. Let's break down how it works with Ruby On Rails and how applications know which actions to perform where. At a basic level, four HTTP verbs tell servers what to do with data sent from every web page.They are:
- GET: Let's go "get" some data from the database.
- POST: Take some information from the user and "post" it to the database.
- PATCH: Update an existing entry in the database.
- DELETE: Destroy that data!
Every time you load a web page using data, one (or more) of these four verbs is being called. In Rails, there are seven basic actions that handle these four types of requests. Revisiting the basic twitter clone I constructed using scaffolding in last week's post, our tweets_controller file already looks something like this:
What we're really interested with here are the seven methods (or actions) in the file. These are all the things we can do to tweets. They are: index, show, new, edit, create, update, and destroy. Wait a second! Why are there seven actions, but only four verbs? Well, each verb can actually help us perform multiple actions. For example, the GET verb is versatile enough to handle the following methods:
- Index: Get and show all of the tweets from the database
- Show: Get and show just one specific tweet from the database
- New: Get the information to begin creating a new tweet
- Edit: Get a specific tweet from the database so we can edit it
One of the most helpful resources in Rails is the ability to view all of our routes in the terminal. By running rake routes, we can see which HTTP verb responds to which controller method.
Notice how GET is paired with four different Controller Actions. Thus, when we visit localhost:3000/tweets/new, we're running the new method within the tweets controller. Don't just take my word for it! Check out the server's output after I navigate to the "tweets/new" page.
For each URL navigated to within the site, Rails follows the convention of Controller#Action, as you can see in rake routes. But we can also set up custom routes! In this scenario, you could just navigate to the routes.rb file in Rails and append it with:
get '/newtweet', to: 'tweets#new'
This just tells our application that when someone navigates to Twitter.com/newtweet, it should run the action New within the controller Tweets. This ability to create custom routes becomes incredibly helpful if you want a more complex application with multiple controllers to have simple and intuitive URLs. Hopefully, you should now have a basic understanding of how applications respond internally when prompted with various URLs and user actions.