First Draft: A Guide to Learning Rails

Did Rails make sense to you right away? On your second day, were you building whole web apps in 15 minutes?

If so, go away. Get! The rest of us need to talk in private.

Now, for at least some of us -- for some undeniable X% of coders-- learning Rails is hard. There's a general unwillingness or inability in the hyper-enthusiastic, terrifyingly evangelical Rails community to acknowledge this –that their beloved, simple, elegant Rails can sometimes just maybe for certain people be hard to learn. That enthusiasm seems to interfere with the community's ability to provide straightforward overviews of the framework's most essential elements, which of course makes the learning even harder.

This tutorial will proceed from a couple of premises.

Premise #1: Rails is not forgiving or flexible. So a loose, chatty tutorial is not going to help. For Rails, you need a series of fear-inspiring edicts.

Premise #2: Learning Rails in pieces, building as you go, will lead to awful code. All the major elements of the framework are interdependent, and so you need to know about (and really understand) features long before you use them.

For each feature of Rails you do not fully comprehend, many, many other features of Rails will simply fail to function or will be completely unavailable to you. The effect is cumulative. Worse, you may not even know you have a problem, and if you do you won't know what to Google on, because the problem you barely know you have involves some feature you've overlooked or forgotten (e.g. "How can I validate attributes in my models so I can get all this if/else code out of my controllers?")

THIS IS NOT A GUIDE TO RAILS. IT IS A GUIDE TO LEARNING RAILS.

The running theme here is (slightly) delayed gratification. Whether we're talking about migrations, dependencies or tests, doing something the way Rails wants you to do it may take 20% longer, but will save you dozens or hundreds of hours down the line.

1. Learn how to set up your DB properly, or Rails will punish you forever.
   • Go ahead and learn migrations first. Don t kid yourself that this is optional. Don't fire up your favorite db interface to save a few minutes.
   • Start fresh; don't use the schema of a legacy db. Name tables and columns religiously in Rails style, or Rails will be a living hell for you and you won't even know why.
2. Learn how to set up your models properly, or Rails will punish you forever.
   • Learn relationships before even touching a controller or view. Use script/console to test your understanding.
   • Using the console, become adept at find, and all the variations of find.
   • Similarly, learn how to validate attributes in models before you do any coding in controllers or views.
3. Learn what goes in controllers: as little as possible.
   • If you're doing a lot of coding in your controllers, you're probably not doing Rails.
   • Controllers are for two things: getting data to (and from) the views, and redirecting users.
   • But do use the controllers to make all the data you need --in all the combinations you may need it-- available to your views.
4. Stay out of your browser.
   • Test your relationships, your finds and your functions with script/console.
   • Test your site with integration tests.
5. Learn what goes in your views: not code.
   • Heavy lifting belongs back in the models.
   • Formatting data for display? This belongs in a helper.
   • Re-usable sections go in partials.
   • Use form helpers, not html, to build forms.

Check out the smokin’ art!

My ex-wife, the fabulously talented Karen Combs, just got written up in design*sponge"...i'm in love. with a wallpaper company. i thought i’d seen the best of the best in wallpaper but thanks to corbett at variegated i've discovered a fantastic new designer, karen combs of nama rococo." Check out the rave reviews in that design*sponge comments section, too. Go Karen! Go Karen!

A Modest Proposal: University Web 2.0

One of the emptiest-sounding buzzwords floating around today is “Web 2.0″. But of course it does refer to a real set of tools and attitudes, summarizable more or less as “make the web dynamic rather than static.” And it seems no place is as static as the world of the university website.

For about a decade now the dominant model of the university website has been fixed: it’s basically a glossy pamphlet. You go to the home page, there’s the full-color photo of the most imposing building on campus –usually the memorial union, usually shot from below– and a few top-level links leading to information: descriptions of the departments and lists of faculty members. It’s usually quite beautiful & professional & easy to navigate.

These websites will usually tell you that the university has a stimulating intellectual environment. But it brings to mind rule #1 from creative writing school: “Show, don’t tell.”

There are so many tools available for web architects now, so many different kinds of content and content-delivery mechanisms, that there’s no excuse: a university website should be simply bristling & bustling with evidence of the daily work and discovery that goes on there.
[more to come…]

The secret lives of men

So it turns out the most popular talk radio network for men 18-35 is devoted almost entirely to ethics and morality. Men call in and vigorously debate issues such as workplace behavior, misogyny, homophobia, racism, and above all what it means to be a man.

This network of men debating how men should behave is called ESPN Radio. And there’s a catch: the men don’t talk about how they themselves would or should behave or feel; it’s all done via proxy. These men never talk about sports; they talk about how sports figures (that is, men) should behave.

Check it out some time. You’ll find that they’re never talking about what happened on the field (”sports”); instead they’re debating someone’s behavior during contract negotiations, or who’s “poison in the clubhouse”, or whether Antonio Davis should have jumped into the stands to protect his wife…

Very Short Fiction: So I got a call from Oprah

She wanted to make sure that everything I’d written was true. I asked her to define true. She emphasized that now was not the time for ‘coffeehouse sophistry’, she just wanted to know about truth in the everyday sense. I asked her if this included my resume and she said she didn’t care about my resume.

So I said we were cool, since I only wrote short fiction.

There was a long pause and then she said she was really sorry, she must have dialed the wrong number.