I think this is a great idea, but mainly because it provides a template for the best practices when implementing a particular item, like file uploading or infinite scrolling.
Given that, I'd love to see the code for these scaffolds directly on the site, with an explanation about what it's doing and why it's doing it that way, as well as the ability to comment on a particular implementation. I would think that type of community-driven peer-reviewed best practices for common feature implementations would be very valuable indeed.
As a fledgling rails developer, this is the thing that will make this site for me.
My reaction could go from "neat but I have no idea where to start or how to filter what is good here" to "Finally a place where I can learn how good rails people do various things and why they're done that way."
Great ideas.. thanks a lot. I thought about this sort of thing, but for now only had enough time to implement a "blog post" link on each scaffold page, allowing the author to link to more info on their blog about what the scaffold does, or how it works.
Granted my above idea would sort of overlap you with railscasts or asciicasts, however the one issue is that thoses casts go out of date. If your site or another site focused on idioms only, and the best practice to use those idioms, peer-reviewed with comments and maybe versioning, then it would easily become a go-to reference for developers, that would always contain the most up-to-date method of implementing said idiom.
For instance, you want to implement authentication. Right now the best thing you can do is head to railscasts, see what the latest screencast is for authenticaiton. Ah, november 2010. Might as well be ancient history! Perhaps there's a newer, easier, more-accepted authentication gem out there. Or maybe not! You just don't know. So what's next, maybe check some blogs, github, do some date-specific searches on google, etc.
If you or someone else had a site that basically said, "here's the current accepted practice for implementing authentication, and here's why", then that saves so much time!
Yea - there’s a lot of overlap with different things. Ryan’s screencasts on one hand, which are amazing even when out of date, and things like http://ruby-toolbox.com/, which give you a list of gems to look at/choose from on the other. Plus github itself is the best place to find actual code, and is peer reviewed in the sense of watch counts, etc...
All I can hope for is that with some community involvement, ScaffoldHub might become something useful in the middle: not in depth tutorials, not a code repository, but a series of helpful working examples.
Yes - this is an important concern, I agree. I hope that ratings/comments/reputation for scaffolds can help here. It's actually no different than installing a gem: you rely on the reputation of the gem author or else recommendations from other users to trust the gem will not do any harm when you try to use it.
In my experience, scaffolding is a crutch for people unfamiliar with Rails. In my connections with experienced Rails devs, I've hardly ever heard of anyone who uses it.
Only time scaffolding comes up in the irc channel, forums, etc, is when beginners ask how they can make scaffolding do X, and the answer is always that you don't, scaffolding is a temporary crutch, just like the name implies. And, experienced Rails devs don't use it, not even temporarily.
So it's probably a completely useless website for experienced Rails devs, while potentially being quite helpful to beginners. An important step towards becoming well versed in Rails is to drop that crutch, though. IMHO, focusing on scaffolding basically keeps you from really immersing yourself in Rails.
I think that most of the spots where scaffolding could be useful to experienced devs, a higher level abstraction that does its generating at runtime is much better. It can be difficult to get right, but you end up with more power, better reusability, and less code to maintain overall.
I think as community is growing there are more people turning towards RoR from other technologies, because:
1. Ruby is language of developers
2. With Rails building application is pretty fast.
I think I have attended a session 4 years back (when I was nuby) when one guy taken user requirements and generated rails app in few hours through scaffolds (and I must tell you it was very inspiring). Though it was just a skeleton and not at all production ready, but at least gives sponsors a feel of application what they envision and in turn they provide quick feedback.
So, I think scaffolds are still useful to provide you bunch of useful files, which otherwise you write by hand.
Scaffolds are a fine way to learn the Rails conventions, but in several years of doing security assessments in the codebases of some of the world's largest Rails apps, I have never once noticed one being used. Professional Rails developers seem to shun them as a rule.
I actually saw scaffolding as a crutch when I started learning Rails and therefore made the conscience decision to learn the framework without using it. I think the time investment paid back dividends, and I don't usually recommend that beginners (or anyone) use scaffolding. Instead, I recommend studying a simple, open source example app.
Long-time Rails developer here (since 2006). From the very beginning, the scaffolds that came with Rails were seen as code that was not production-ready. They were mainly for prototyping.
I still use scaffolds to this day as my first step when building a greenfield app. Of course, I always revisit the code before I consider it production-ready, but it saves me time when taking the first step.
I think we should be careful not to confuse the scaffolds that come with Rails with the more general idea of code generators. Code generators are not bad; it's how you use them. If you use them to generate code that you never intend to review or understand, then yes, they are a crutch. Otherwise, they are a time-saving head-start or a great learning tool.
what about cases where the functionality you need is such basic CRUD that scaffolding speeds up your workflow?
i can write scaffolding from scratch, but i appreciate it as a useful boilerplate for when i'm fleshing out an initial iteration. i can't tell if "i never scaffold" is just vogue or if there really are no use-cases for it if you want to claim proficiency.
the code it generates seems pretty basic, trivial, and even idiomatic. (not a fan of the view code, though)
It really depends. I don't use scaffolding if I would just replace it anyway. But: I do find it convenient for apps where I don't want to write (and therefore re-invent) data display views, like activescaffold provides (or used to provide?).
You know - scaffolding is what attracted many people to Rails in the first place. Well, not scaffolding per se, but the idea that it takes care of boilerplate for you.
This is two non sequitur points in two small grafs.
Lack of boilerplate is one of the things that attracts people to Rails and it is one of the things that keep people there. Scaffolding isn't what provides that benefit. Scaffolding is. boilerplate. What eliminates boilerplate is the "Convention Over Configuration" mentality behind Rails, which is in full force today.
Rails in 2011 is if anything less bloated than Rails was in 2007; post-Merb, it's been made modular and had much of its magic goop factored out.
I'm getting the feeling that you don't do much Rails dev.
A lot of people were attracted to Rails for a lot of different reasons, but it's pretty clear that people who stay with it and become proficient basically tend to ignore the scaffolding feature altogether.
The people you speak of maybe didn't stay with it because Rails doesn't really live up to those expectations.
I kind of dislike scaffolds. Often they generate crap you don't need. The stuff they do generate that you need is either A) totally generic, and should be tucked away in a library somewhere, or B) needs to be customized and the scaffold didn't get you anything.
On top of that, when the scaffold changes, there's no easy way to patch you code. I think in theory what you should do is maintain a log of all of the scaffolding you did, and which commit you did them in, and that way you can just check out that commit, re-run the scaffold, and then merge that back into your tree. But I never remember to do that.
What's the benefit over a well architected library? Especially in a language like Ruby where it's so easy to write DSLs, I don't see where you'd ever want a scaffold.
> What's the benefit over a well architected library? Especially in a language like Ruby where it's so easy to write DSLs, I don't see where you'd ever want a scaffold.
The benefit, I think, is that scaffolds:
* generate a pile of code that you feel free to hack away at, removing and adjusting as you see fit. I don't think scaffolded code is a good candidate for patches, really. It's a shortcut that writes code for you, not a library.
* generate code that is customized to your precise needs. For example, when you scaffold something using Rails' default scaffold generator, it creates a database migration and builds the appropriate form fields based on the columns you're using in the model.
* are great for generating the kind of code you tend to write over and over. For example, we do lots of custom website development, and a common requirement is the forms for CRUD related to the entities people are managing on these websites. The problem is, the entities are always changing. For an auto dealer, the entities are vehicles, makes, models; for a real estate brokerage they are brokers and properties; etc. We would previously cut and paste code and then modify it, but then we wrote a scaffold generator that builds all the forms for us with all of the appropriate structure and CSS classes and IDs to make them look beautifully integrated.
I see. So, sort of like a sculptural "chip away everything that's not an elephant" kind of approach. That makes some sense.
I think the "custom generated code to mee your precise needs" category is exactly where I think scaffold writers are just lazy library writers. If there's a way to parameterize the scaffold experience, there's a way to create a parameterized library that "scaffolds" your code without generating a bunch of boilerplate.
On the last point: I think that makes a lot of sense, especially if you're working for clients. They want to end up with a complete, hackable site that doesn't have some weird dependency on a meta library. (like a library with meta-forms, meta-models, etc)
I guess I'm biased because I work on one big piece of software, so that kind of duplication would be heresy.
That said, if you tried to write a unified framework that let you build sites like that without a bunch of generated scaffold... you might end up building the next Rails! Isn't that where Rails came from?
i thought that was the point of scaffolds. i hear people say things like "but don't use them in production", but all it does is generate some boilerplate code for me to shape into what i need.
I want to expand on my previous comment and tell you HOW I found it useful. My Rails learning typically falls into two categories. I'm either reading manuals/online tutorials OR I'm digging through GitHub to see how other people put things together. Both have been powerful. So, the reason I found scaffoldhub useful was not because I wanted to clone the scaffolds and use them, but simply as another way to identify specific functionality that interests me, and then browse through the associated code on GitHub. Hope that helps!
I think something like this really needs a rating or comment system. Would be nice to see what people thought of the code used in the scaffold you were downloading rather than having to create a scaffold and review it on your own. As the number of scaffolds grows, it would be hard to sort between clean, popular ones and ugly ones.
Is the purpose of scaffolding just for learning? When I was just starting, I built a twitter clone using a scaffold in about 5 minutes and ... I learned nothing. I then spent a week coding it by hand and learned rails.
I don't think I'd ever use a scaffold in a production app though. For that, I'd ether find an appropriate gem or write the code myself.
Yes, I think scaffolding is primarily a helpful learning tool... especially for learning how to wire/connect different gems, javascript libraries, etc., together into a working example. Often no single gem will provide everything you need.
But you have to take the time to learn from the example, or I agree you'll get nothing out of it.
Yes - but one thing that is important is some sort of indication that a scaffold is "good". I use Ryan Bates' nifty generator all the time, mostly because I know it will spit out good, basic code.
Some sort of voting mechanism, or other indication of popularity/quality would be very helpful. Allowing the best practices to bubble to the top would be very helpful to rails developers in my view.
As others have said, great for beginners or to developers implementing some feature for the first time.
I've done Rails consulting, full-time, for 5 years; I haven't used use scaffolds since probably 2006. Instead, most of my productivity gains have come from learning to use third-party gems, better understanding the framework's ever-evolving capabilities, and Texmate snippets & commands.
However, a site such as this, where popular scaffolds could be voted up to the top of a pile might produce some worthy projects.
I can imagine myself using scaffolding when using a gem for the first time, one of the more involved gems like carrierwave, uploadify, or devise. These gems can take a while to get working - you may be targeting a different version of rails than the blog post you find, or you're deploying to heroku and need some custom tweaks - the details can slow you down and make you reconsider whether to use the gem, especially if you're billing by the hour.
If, on scaffoldhub, I could find a scaffold for something quite specific ('rails 3.1 and compass on heroku' or 'devise, haml, coffeescript, simple_form') that would be really, really helpful.
I'd quickly get something working on my dev machine, which saves me frustration and gives the first charge of coding pleasure, an important component to our work. It would enable me to more liberally experiment with new libraries and coding practices.
Perhaps, also, a rake task to generate a scaffold from a working rails app. That way, a scaffold, once working, can be extended. For example, first I install the uploadify scaffold, verify that it's working both locally and in production, then I add compass and devise. I run rake scaffoldhub:snapshot rails_3.0_uploadify_compass_devise_heroku, then scaffoldhub:publish to upload my work.
Wow... fascinating idea about "rake scaffoldhub:snapshot"!
I really appreciate your feedback and encouragement. I definitely will continue working on scaffoldhub; probably my next step will be to open source the web site code (gem is already open) so others can help out on this. I really see this as a community resource - not a private project.
Great for beginners, or people who want to hack together a quick website! Personally, I stay away from scaffolds altogether though so I don't get stuff that I don't need being generated. Also.. as I continue to develop and my website designs become more complex, I find less and less of my projects needing the cookie cutter design of a scaffold.
I totally agree - however, I'm guessing even more experienced Rails developers might find scaffolding occasionally useful as a starting point... e.g. for learning how to use a certain JQuery plugin it's often hard to know even what JS files you need, where to find them, where to put them, etc.
Using scaffold code makes me feel uneasy. I'd much rather see things like this extracted into a gem and accompanied with a short tutorial or screencast explaining how to use the gem rather than code that may be overkill, can't be updated easily, and will quickly become stale.
Thanks everyone! Great suggestions and very encouraging... I'll have to sort out priorities/what to do next and find some more spare time to work on this :)
Great idea; thanks! I do now have the option for each scaffold to link to a blog post somewhere... but hosting HTML demos is an interesting thought too.
Do you guys remember when people used to create MS Access applications? They let the mdb running into a shared directory and screamed around the office to gain or release lock.
This is what both rails scaffolding and django admin means to me.
Given that, I'd love to see the code for these scaffolds directly on the site, with an explanation about what it's doing and why it's doing it that way, as well as the ability to comment on a particular implementation. I would think that type of community-driven peer-reviewed best practices for common feature implementations would be very valuable indeed.