Week Two of Ruby on Rails: The Incredible Power of Rails

gistfile1.md

I have now hit my first "wow" moment with Rails, where I actually understood why it has the following it does. It has raised some questions for me about the pedagogy of Rails, but that is not the language's fault; it is a question for the community.

Rails is fast. Mind-blowingly fast. From my cursory looks at the framework, it is immediately apparent that this was designed from the ground up to give me everything I'm going to inevitably want in a basic web application. And yet, for some reason, it isn't immediately sold that way. It's instead sold with stuff like...

"I'm not even joking when I say this, but I think some of the resources out there make it intentionally hard for non-technical people to start learning."

The above line was from a class on Rails - not a Ruby class, but a Rails class. The class was designed so that you could have no coding experience whatsoever and build an MVP, and it advertises itself as such. I think learning to code, even at the lowest level of difficulty, is a fantastic exercise to pursue. But, like most things, when something is easy to do, it is also easy to watch it go awry.

As I've said before, most of my programming experience has been with Python and webapp2, with a bit of Django thrown in as well. With webapp2, you are close to the request itself (your application requires a webapp2 RequestHandler, which makes you write the responses to GET and POST requests manually). There is no way to automate database models, so you have to hand-code that as well. That is sloooooooow, but you learn the ins and outs of a web application because eventually you'll have to dig through the requests and responses to figure out what's going on. Requests are ugly - I get that - but someone has to deal with them. And for a long time, I was dealing with them manually.

So you can imagine my joy the first time I hit rails generate scaffold. I'm going through my tutorial, and it tells me to punch this command in. It then takes me through all the files this thing has modified, and I almost leaped in the air. This Python developer just watched hours upon hours of repetitive code, abstracted away in a single command. Everything I knew I was going to have to do eventually was suddenly all perfectly prepared for me. I was exceptionally excited.

I would be curious to know how developers who have started with Ruby on Rails have adapted to other languages, because scaffold is such a powerful tool that I'd be nervous to give it to an inexperienced programmer trying to learn code. Building an MVP or hacking something together is one thing, but actually learning to be a versatile programmer is something else entirely. In one fell swoop, you've abstracted away a lot of information about how the sausage of web applications is made. You've completely skipped over that.

And yes, I am aware that this occurs in Python as well. I am guilty of writing a lot of poorly constructed programs because I should have considered the code optimization I would have learned in dealing with C. But still, learning Python has enabled me to make this jump to Ruby without too many headaches. I wonder if it would be the same going the other way.

Thoughts? Anyone who has jumped from Ruby to Python, Java, C, Haskell, etc. out there? What were your issues when making the switch?

Scaffolds are terrible. But I will admit, it totally whet my appetite when I ran it the first time. It boggled my mind that it was actually saving to a database and everything. I could stop the server, and start it, and there it was still! It seems so basic to me now, but it was mind-blowing when it first happened and kept me wanting to learn more. So while I never, ever use scaffolds anymore, and don't personally use it when teaching Rails either, I do have a soft spot for the 'ah ha' moment it gave me. I think I'm the exception, not the rule, in that respect though.

And, for what it's worth, Rails does have magic but I've been surprised over time how thin the abstractions often are in the end. Like with routing, I had done PHP for years and never understood what HTTP methods (POST/GET/etc) actually were or how to use them properly. Rails taught me that. I finally understand HTTP. It took a while, but I feel like I understand "the web" in general better now than I ever did as a PHP programmer.

I find scaffolds crap. In the words of Kaplan-Moss, "I don't like how rails shits all over my project directory." I'd rather create the required files myself.

rails g resource. That's what I use instead of scaffold. It generates models, controllers, migrations and routes. But no views or controller actions. This is exactly what I need most of the times.

I wrote something similar to this and, having just looked it up, am alarmed to see I wrote it 5 years ago :-) In that time I have seen a number of new programmers completely at the whim of autogenerated code and unable to lose the training wheels - it remains a thorny issue.

Well, yes, the scaffolds do suck. But to be fair, no one is advocating shipping scaffolded code. Often you aren't entirely sure what the UI will look like when you start developing. There are many reasons you might want to rapidly prototype a crud-based UI before you can get a pretty design on top of it. Scaffold helps you do that. But if that code stays in your codebase for too long.... well, that's your own fault.

On learning Rails - railstutorial.org + railscasts.com + codeschool.com . I've dabbled in Django before (mainly templating the frontend for an app I was designing), but after an intense period of using Rails I wanted to go back to Django and learn how to do the same stuff I do in Ruby/Rails (to make me a better programmer). Found it very difficult to find accessible, modern, high-quality resources for learning Python/Django in the same was as I've found with Rails.

Having learned rails and django in that order I can say, you could benefit learning from both. Something like Django would seem lacking in the development speed category for a newbie Python programmer when compared to rails since scaffolding puts you at the seat immediately. Even though @russgray's article is old, it's spot-on for rails at that time. As he points out, the "training wheels" stay on long for a newbie rails/ruby programmer with rails because it's so easy to develop the basic functionality for most web applications without learning much Ruby. Other frameworks have this problem too, maybe to lesser degree or rather different extent and Django is no exception. Some Django newbies tend to abuse the Django admin - even going so far as to use it for front side applications with template overrides. That's on par or even far worse than the purported rails newbies who abuse scaffold code imo.
I still find rails scaffolding to be one of the best ruby on rails features for a web development newbie who learns by example.

@jongd: their documentation is at times not so user friendly. what parts were you struggling with?

I've been thinking for a while that there are two very different kinds of abstractions in computing. One kind hides away complexity so that you don't have to think about it—or even know about it or understand it. These kinds of abstractions need to not "leak" very often, but they're very important. The OSI model comes to mind as an example.

The other kind of abstraction, though, is for shorthand. This kind is actually harmful, or at least dangerous, if you don't have a solid understanding of the mechanics behind it. An example might be IDE's.

Many of the abstractions in Rails are just shorthand. They keep you from having to do repetitive work. They're designed for the expert first, not the newbie. Anything in there for the newbie was added on for marketing reasons, more or less, but it will probably never get in the way of the target use case—which is for the competent developer.

I'm not saying we shouldn't throw new devs right into the deep end of Rails. There's going to be pain getting up to speed, of course, but that's the case for all paths.

But if we mistake the purpose of these abstractions as being anything other than shorthand to avoid repetition, our discussion will end up going in wearisome circles.