Day 34 – Helpful Rails

Getting a bit of a late start today. I wasn’t able to write this post last night because I was too busy playing with Omnigraffle! Omnigraffle is a super cool app for making beautiful diagrams and stuff. Behold, the fruit of my labors, a diagram for Rails MVC architecture:


Now that I know how to Omnigraffle I’ll probably include occasional diagrams in my blog posts. Anyways, let’s get back to Ruby!

My fourth day of Ruby consisted of more full MVC assignments, but with sprinklings of new concepts. For example, the platform included a lecture about Error Driven Development (EDD), which is actually pretty close to what I’ve already been doing. However, with true EDD, development starts with a test of the desired feature as the first step to implementing it! For example, say you want your site to go to a new user page when you visit the url ‘users/new’. The first thing you do is try to go to that route, and of course an error pops up with something like “ERROR: Path doesn’t exist!”. So, then you go make the route and try again and get something like: “ERROR: No controller method!”. So then you go make the controller, and so on until you have the whole feature implemented.

I tried out using legit EDD on a couple assignments and it’s definitely an interesting way to work. Reading so many Rails error messages was good practice for me, and it made me realize that the feasibility of EDD really depends on the quality of a given language/framework’s error messages. Rails is quite helpful in this way, as error messages usually give a good explanation for what is going wrong, even to the point of giving suggestions for what to change. I don’t want to diss Django or anything, but it does seem like Rails has a leg up in this area.

Anyways, the title of this post is referring to more than just helpful error messages, it’s also referring to helper functions! I’ve only begun to scratch the surface of Rails helpers but I already think they’re totally cool. In Rails .erb templates, there are tons of helper functions that you can use to generate HTML tags. For example, say you want to make a link to a specific user’s profile page. If you type it out in HTML it might look something like this:

<a href="/users/#{<%= %>}">View Profile</a>

This example isn’t too much of a pain to type out because the url is pretty simple, but not every route will be so simple. Thanks to Rails’ link_to helper tag, we can replace the whole anchor tag with this:

<%= link_to "View Profile", @user %>

Much cleaner right? The fewer cryptic symbols, the better. This may look pretty magical, but behind the scenes all the link_to helper does is take two or more parameters to create an anchor tag. The first parameter is always a string that will become the body of the link, and if only one other parameter is given, that second parameter will become the url for the link (more than two parameters can be given to specify more options, but I won’t get into that). You might be wondering “but then why did you only pass in @user?”, and the explanation for that has to do with named routes!

Named routes are a hugely important part of any web framework as they facilitate the writing of DRY code. I learned about named routes back in Django, but didn’t really focus on using them to their full potential. Rails takes named routes to a whole other level with the resources helper, which will auto-generate the full set of RESTful routes for a specified controller. I don’t have time to get into this today, but if you’re interested you can read up all about named routes and stuff here. It’s time for me to get back to coding!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s