Rails Tips for Designers, Part 1

After working with Ruby on Rails for a few years and spending the past 2 months knee deep in it for 8-10 hours a day, I’ve learned a few things about working in Ruby on Rails. I owe my basic understanding to Jonathan and Sean from when I was working with them on Voomaxer.

The Tips

1. Work with smart programmers who are also good teachers

The lead developer at Bleacher Report is both a great developer and a great teacher. This is the single most important thing for making working with Rails (or any language) easy. Whenever I have a problem (which is regularly) I say “Hey Tung, how do I ________?” The other engineers are equally helpful and very smart.

If you don’t have access to smart coworkers, try talking with developers regularly on IRC or in forums. Many of them are very willing to help out if you are genuinely curious and don’t ask basic questions that you’d find quickly using Google.

If people can’t explain something so that you can understand it, chances are they don’t really know what they’re talking about. Experts are good at explaining things to non-experts.

2. Stay organized

A brand new Rails project is setup to keep the developers organized. The MVC pattern is great for keeping programmers from putting too much logic in a view or writing a bunch of SQL alongside a bunch of logic. It is not so good at keeping designers organized.

Namespace your images using folders. If I have a button that goes on the sign up form, I put it in a directory that looks like this:

/public/images/forms/signup/signup.jpg

But more often than not I use sprites, which I would keep in /sprites/buttons.jpg.

I do the same thing for stylesheets. As an example there is certain CSS that is loaded on every single page of the site (i.e. the header). I would keep that in it’s own file:

/public/stylesheets/common/header.css

Under the /common/ you would include all of the CSS files that are loaded on every page of the site, my stylesheets directory looks like this:

/public/stylesheets/common/reset.css
/public/stylesheets/common/base.css
/public/stylesheets/common/grid.css
/public/stylesheets/common/header.css
/public/stylesheets/common/sidebar.css

/public/stylesheets/articles/article.css
/public/stylesheets/articles/comments.css

/public/stylesheets/widgets/widget_1.css
/public/stylesheets/widgets/widget_2.css
...

Wait! Don’t you have to write 20 different links to external CSS stylesheets in the header if you do this? No. You use asset packaging, which takes all these stylesheets, removes the white space, and turns them into one stylesheet that loads nice and fast.

<%= stylesheets_link_merged :base %>

If your development team is not using asset packager, suggest it to them - there are many benefits beyond organizing your CSS. Also, I know that you are probably thinking this organization is a bit anal retentive and causes more pain in the long run, but if you’re working on a site of moderate size it’s just as annoying to scroll through 7,000 lines of CSS.

3. <%= and <% are different.

This is insanely obvious to every engineer. To me, this was not obvious. It turns out code that looks like this:

<%= %>

Actually spits something out onto the page. You wrap your Rails link helpers with <%= because it will actually spit out the results into the HTML. If the code begins with:

<% %>

Then it does not actually output anything that the user or browser can see but is parsed by Rails - if/else statements, loops, etc. will go in these tags.

4. Break things regularly

A lot of what I’ve learned comes from when I try to do something on my own without asking a developer. It usually breaks. I usually then have to reverse engineer what I broke and figure out how to fix it. Guess what? After I do this I understand why it broke and why the code was written a certain way.

This is a great way to learn any programming language. Actually, since starting work, this is how I’ve learned most of what I know about our Prototype. I will probably use the same method to learn more about Ruby and Rails. Just remember not to check in broken code - version control will identify you as the culprit.

The Hype

There was (and is) a lot of hype around Ruby on Rails. (Did you know 37signals uses it for Basecamp?!) You can read millions of blog posts about it and buy all sorts of books with advanced Rails recipes. People argue until they’re blue in the face about whether Ruby is faster than this or Rails is faster than that.

Guess what? When you’re working on a team that just wants to push a kickass product out the door, no one thinks about these things. People code in whatever language makes them happy and seems like the best tool to get the job done. The people building real, useful products in Ruby often don’t have the time to hang out on message boards arguing about millisecond differences in response time.

The truth is, Ruby on Rails is good enough for most web apps. Tung (our lead developer) answered the question “Does Ruby on Rails scale?” with another question: “How good is your code?” I think he heard that somewhere else, but I don’t know (or care) where.