The Fall from Scaffolding

I learned about Ruby on Rails because I was into Basecamp. Basecamp I heard about on a designer’s forum called YayHooray!, a long time ago, back when Basecamp was new and beta. If I hadn’t read that Rails was what was behind Basecamp, I probably never would have bothered looking into it.

But what really sucked me in, once I gave Rails a few minutes’ chance to impress me, was the video. I’d never seen anything like it. The demo dude—who I later learned was David Hansson himself—created a very simple, but functional, web app in a mere 10 minutes or less.

The Revelation!

Being as I was in the depths of PHP hell—working on custom components and hacks for Mambo—the Rails video felt like a divine vision. If a magical “ahhh!” and heavenly light had shone on my PowerBook screen, it wouldn’t have seemed out of place.

But no divine light appeared, and I had to go fetch some paper towels to wipe up the small puddle of drool that had accumulated on the floor. Even ten minutes of saliva production results in more volume than you might otherwise think.

The Practice!

So of course, once the floor was nice and clean—if a bit shinier than before—I did what any self-respecting geek would do: I went and scrounged up every installation tutorial I could, and pestered folks in the #rubyonrails IRC channel when I got stuck. (I’m fairly handy with a command-line, but really, it was a much tougher thing back then!)

Finally I got up and running, thanks to DarwinPorts and RubyGems. And lo and behold, magic was made. I had a simplistic CRUD-powered site going in no time.

What impressed me so was the scaffolding, the automatic views and code generated by Rails taking a peek into your database models and making some simple assumptions. The forms weren’t pretty, but they did work, and you could list, view, edit, and delete items with just a flick of the wrist.

Back then you started off your scaffolded web app like thus:

PeanutsController < ActionController::Base
    scaffold :modelname

In my first article on Rails, excited newbie I was, I mused that it would be fun to get ahold of the autogenerated code Rails uses to scaffold so I could get a better understanding of what was going on. It was cool, but very, very “magical” and not necessarily in a good way. At the time, I didn’t know that you could simply do this instead, and get editable code:

script/generate scaffold peanuts

You probably started out with this command, though, as the scaffold method has been phased out over time. So you’re probably familiar with the results—a peanuts_controller.rb file in the controllers directory, a peanut.rb file in the models directory, and a bunch of view files in the views/peanut directory.

The Chafing!

As soon as the initial delight wore off, though, I felt at odds. I realize that I’m not alone in this—it seems like most people have gone through Scaffold Withdrawal of a sort. It’s that cold, clammy realization that scaffolding can’t cut it forever and we don’t know what to do next.

We’d love everything to be just that easy, of course, but a nagging little voice somewhere says “Dude, you have to be able to actually create associations between your models. You can’t do this with scaffolding. You have to actually learn something.”

On the flip side, some people cope with their Scaffold Withdrawal by figuring that scaffolding must have magical properties they haven’t yet found. They ask people “How do I make scaffolding do x, y, and z?” They are in denial, but that is a normal part of the withdrawal/grieving process. Just don’t let yourself get stuck there forever.

You’ve gotta move on, man. Really. You’ll feel better.

The Solution!

The solution is a radical one, but bear with me:

You actually have to learn Rails.

The initial promise of no-work web apps is enticing, but unintentionally misleading. There’s a lot to learn about Rails. But it doesn’t have to be hard.

What you need to do, specifically, is learn how to write your own view templates—or expand/redesign the ones generated by scaffold—and add controller logic to take incoming data from view forms and mush ’em together where there are associations.

Here are some links to get you going:

And remember, the Rails community is a friendly one. There are lots of people out there happy to help you, including me.

But please leave behind bad habits developed in PHP-land, and don’t ask questions that have to do with specific tasks rather than outcomes. Don’t ask, “How do I write a forum?” because nobody wants to answer that question. Ask, “How do I link multiple models together in my controller code?” You’ll be much more likely to get assistance.

No Comments

  1. john athayde says:

    The thing that hit me hard (and I’m still migrating through) was the step after this… or maybe the end of this step. I can hack my views and models, and even my controllers a bit, but the hardcore ruby aspects of it I’m still wallowing through.

    I’d also make the suggestion of "start small with your web apps. Don’t try to climb K2 on the first day"

  2. bq. You actually have to learn Rails.

    @ πŸ˜€ @ This is the first blog post I’ve read in a while that has actually gotten me to LOL(Laugh Out Loud) arround the office

  3. cboone says:

    But damn wasn’t that invisible scaffold crazy? Pure magic: nothing there, but it all works anyway.

  4. Jonathan Telfer says:

    Scaffold Withdrawal is a superb way of putting it. I started my first (and currently) only Rails project recently, and I’d got going with invisible scaffold before I found out it could be generated, something I learned from the Ruby on Rails book.

    What I’ve done (rather than try and generate the scaffold into my existing project) is to create a new project that references the same database tables. I can then run a "script/generate scaffold xxxxx", take a look at what it created and copy over the pieces that I want. That seems to be working.

    I delved in and created my first link between two models a couple of nights back It was pure magic to finally be able to navigate around my model’s relationships a little more. I can’t wait to get stuck back in to it.

  5. I second John’s statement. You have to actually learn Ruby. I was halfway through the Rails book when I realized I could kind of build things by using what the book had taught me, but I didn’t really understand a lot of it. So I put down the Rails book and starting reading ‘Programming Ruby’. Once I skimmed through that, going back to Rails was a whole different thing. It made sense. I actually understood WHY things did what they did.

    Learn Ruby.

  6. David says:

    I think Rails is great, and I’ve really enjoyed getting over Scaffold Withdrawal to learn how to hack it. But it would be very cool if Scaffolding could also handle basic associations set up in your model – getting data from lookup tables, turning them into pull-down menus on scaffold edit views etc. Effectively, just taking a bit more heavy-lifting out of getting started.

  7. Oliver Rowlands says:

    I suggest you guys check out &lt;a href="; rel="nofollow"&gt;Django&lt;/a&gt;, Rails just gives you scaffolding, Django gives you the whole house!

  8. Eric says:

    Yeah, there’s definitely a bump in the Rails learning curve. Everything is so smooth for the first day or two, and then you need to digest (1) Ruby and (2) the shape of the framework. This takes a little while.

    Fortunately, once you figure out Ruby and Rails, the excitement of the first day comes back. And everything fits together really well. It’s definitely worth the effort to find out what’s really going on.

  9. Ferdinand Svehla says:

    Um, Oliver, Rails also gives you "the whole house", of course.

    My experiendes with Django are "rather bad" at best, I thought many times "why do I have to do this? It is just work for me that the framework should do" – like defining attributes in the model – with that Django-style creepy syntax.

    I just hate methods that start with an _.

  10. Ian Irving says:

    Amy, I think you have been reading too much "Why"…now move away from the "Chunky. Bacon"……even if I agree that the next step is, when you need more, to let go of the Scaffold and go down the Ruby brick road….Ack, now I’m doing it!

  11. Trix says:


    Imho, the ability to generate scaffolding is a major trap for someone’s learning Rails. It tends to encourage you to see your app as a web app before you’ve even thought out the basic specs.

    In my experience, that’s the best way to end up with basic controllers, mostly empty models, and overly complex views because you just spend your time making your web pages better.

    If you’re looking for suggestions for future articles, I’m sure a lot of intermediate railers would benefit from a good article on developping without firing up a browser. From what I’ve seen of advanced railers, they tend to develop a lot by developping their tests, and doing quick iterations between the console and their editor.

    A recent project has forced me to start concentrating on the console, and I’m starting to understand a lot more what Rails is all about.

  12. Amr Malik says:

    I would second Trix’s suggestion. It would be nice to see what ‘advanced’ developers are doing in terms of creating the system from the console/editor side.

    This is the reason, I’m switching back and forth between the ‘Pickaxe II’ and the Rails book with a heavy dose of "Why Why Why" . Scaffolding is good, but eventually, you gotta get your feet wet, and learning ruby is the way to do it.

    Sometimes I do wish there were more ruby books out there that dealt with advanced Ruby features like meta-programming etc. Right now its just the kindness of bloggers that keeps feeding my curiosity.

    Thanks for an excellent writeup.


  13. Garrett says:

    bq. You actually have to learn Rails.

    That line was the first time I’ve honestly laughed out loud in a long time. Thank you for that.

  14. The Entire Population of China says:

    PHP is just so much more useful and powerful than ruby (to me) and, frankly, I can bang out a rudimentary blog app in 10 minutes with PHP just fine. The challenge is adding the scale, security, features and functionality that you need to make the thing any good. To do that, I’ll stick with PHP (rather than learn a new and very different language like ruby).

    You mention you were working with Mambo, I think that would drive me nuts. The code is like a sprawling spahgetti monster. You ought to try working with a modern, well thought out PHP based system that is done correctly from the start as opposed to a beast like Mambo. Some of the Rails inspired PHP frameworks (like symfony) make use of the power of PHP 5 and object oriented programming and are structured in an intelligent, scalable and powerful way.

  15. DMoney says:

    Dear all of China (commenter above),

    I am at a loss to see how you support your argument that PHP frameworks are a better solution than Ruby frameworks, when fundamental aspects of the application development like scale, security, and other functionality are a "challenge". This will not be a PHP vs Ruby debate, but if you claim that PHP is "much more useful and powerful" than Ruby, your claims are not supported by citing Ruby/Rails knockoffs. At the most, you may claim that you are more comfortable working in PHP and not interested in learning a new language.

  16. Amy Hoy says:

    Let’s not start a flame war in my comments πŸ™‚ I don’t mind using PHP at OmniTI, where I work, because I get to write–and work on–intelligently written code. You can do it in PHP just fine, I just think that it’s not as easy in PHP as in Ruby.

    I said Mambo was the depths of PHP hell, though, and I stand by that. Only something like PHP-Nuke could be worse!

  17. God. I’m amazed because I understood exactly what you describe here, yesterday evening. And now your post πŸ™‚

    After quickly starting to read Agile Web development, and using scaffolding etc, I finally got back to Pickaxe II, and to learn the real stuff, as I had understood that I needed to start.. by the beginning.


  18. buggy fun bunny says:

    please folks. the future is Declarative Programming, Model Driven Architecture, Database Driven Design.

    face it: Scaffold is just a toe in the water implementation of those. we must embrace and extend Scaffolding if we truly want two things: coherent systems (one fact, one place, one time), and maintainable ones.

    this does mean that design is more important than coding; but get over it, that’s always been true.

    though java, have a look at middlegen and/or FireStorm/DAO for how the successful systems are being built.

  19. Loren Segal says:

    I must agree with buggy, there is much to be learned from scaffolding, rather than trying to rid ourselves of its simplicity right away.

  20. George B says:

    I could create the same thing (the so called WebLog application) with our homegrown PHP framework in 5 minutes. And the framework was built 2 years ago. I don’t see what’s so great about Rails, nothing is new. Ruby on the other hand is interesting. Rails? Oh well.

    The video was a good marketing tool. My only complain about it was David’s soft pitchy ‘WHOOPS’. It’s the most annoying thing ever. Other than that, hats off, mad props to DHH.

    The fact that people moving away from Scaffolding, and wanting to know how to build a Ruby based web application properly is a sign that Rails will eventually be designated for newbie anyway. Rails is just a set of conventions and helpers. Nothing is particularly new.

    Rails will someday end up as a bloated software anyway, let’s give it, say, 3 years?

  21. Loren Segal says:

    George B,

    And PHP is not a "bloated", "newbie" ridden language?

    If anything, the move away from scaffolding and the will to write proper ruby apps shows a disconnect from being the newbie idea.. not the other way around.

    I don’t see rails as a newbie playground– The rails design path is very formulated and organized over proper mvc design patterns, which are not a very beginner topic to begin with. Using Rails in its proper form has so far led to very high quality applications being released– which is really a lot better compared to the multitude of weak applications running on badly designed PHP frameworks

  22. RailsRoad says:

    Interestingly, I just posted on my blog a similar article. I’m trying to create a Rails Poll and I got hung up because I couldn’t get scaffold to work.

    I’m a total newbie, so I’m tryiing to record everything that I learn for the benefit of other Real Newbies. πŸ™‚

    I’m also working on an article of my experience setting up a Rails app on a live server. Right now I’m trying to figure out how to configure fastCGI.

    So much to learn. πŸ™‚

  23. Vivek says:

    Thats a really nice article..I am almost a month old into rails and would like to see how one goes about doing slightly more complex controller code has grown to about 200-250 lines and I think a good tuorial on how to organize code and make it reusable,DRY principle and especially smething on the application helpers would be useful. (still havent figured what they are,but I think they are some kind of container class for commonly used methods?)

  24. Sean Clark says:

    Loved this! I am actually having to learn rails now. Except I’m focusing more on Ruby and then Rails. I really got into rut trying to only learn the ruby that was necessary. I’ve made better progress since switching my emphasis to keep my ruby skills ahead of my Rails skills.

  25. Keith says:

    Great article. I too was looking for the no-work web app….. Still the less-work web app will do nicely for the time been

  26. Shaun says:

    I’m from a PHP (plus other languages) background of around 7 years and sadly I’ve only just started to learn RoR. I can already see however that I’m going to need more flexibility and control over the scaffolded code.

    Yet again you’ve been useful, now I’m inspired to start creating my own views from scratch to ‘learn me some more.’

    Thank you (again).

  27. Block 16 says:

    Very clear πŸ™‚

  28. dustin hoffman says:

    sure, but how do I target my triceps so I get that sculpted arm look?

  29. I was very dissapointed of this!

  30. Thanks for the write-up.

  31. I think it would be usefull for other users also!

  32. Thanks for the write-up πŸ™

  33. Ada Sign says:

    I was very dissapointed of this πŸ™‚

  34. Well done, nice instructions…

  35. I thout to do it in my local version.

  36. Thanks. Updated appropriately!

  37. i am not sure as to why πŸ™

  38. Thanks for the write-up πŸ™

  39. Thanks. Updated appropriately πŸ™‚

Hey, why not get a shiny
Freckle Time Tracking