Ruby on Rails: Not as easy as it sounds

I've been making small database-backed web apps for years now, after learning how by reading the PHP code generated by Dreamweaver. For example, I made both Mary Anne's journal and the Strange Horizons fiction editors' submission-tracking system by starting with Dreamweaver-generated pages and gradually building on them with hand-written PHP.

But structurally, my apps have always been a mess. I had never heard of the Model/View/Controller structure when I started writing them; various parts of the submission-tracking system, for example, do direct hardcoded database queries right in the middle of rendering a page. And my development process often consisted of making a change in a file using BBEdit and saving the change directly to the server, then loading it in a browser to see if it worked.

So some months ago, when I decided it was time to put my movie ratings and notes into a database, I decided to do it using Ruby on Rails. I figured that would be a quick and easy way to set things up. I only knew a little bit of Ruby (picked up from reading a bit of Why's (Poignant) Guide to Ruby), but it seemed close enough to other languages I've used, and anyway everyone always talks about how awesomely easy Rails is.

At some point, I successfully went through Getting Started with Rails. Then I successfully went through the Rails for Zombies video tutorials, which I had some minor issues with (starting with not liking zombie stuff) but found overall useful.

I thought about just using what I'd learned from those resources to create a movie database. But then I thought maybe I should learn a little more first. So I embarked on Michael Hartl's Ruby on Rails Tutorial (which you can read online for free).

And I stalled.

Because Ruby on Rails turns out to be the most incredibly difficult-to-set-up, complicated, and messy "super-easy-to-use" system I've ever encountered.

The tutorial spends a great deal of time on setup, and claims that this is good because you should know your tools. But my impression of Rails was that a large part of the point of using it was that you didn't need to spend a lot of time or energy on setting things up.

(Note: The tutorial is, I think, primarily aimed at professional software developers rather than hobbyists like me, and is explicitly opposed to relying on the auto-generated Rails scaffolding; for more on this key point about audience, see below. It's entirely possible that I could do everything I want to do in Rails by just relying on the scaffolding and ignoring the tutorial. So my post here may well be more about the mismatch between me and the tutorial's target audience than about Rails actually being difficult.)

The tutorial suggests using an IDE, but the IDE-setup guide it points to is itself multiple layers deep, and explains how to install Ruby and Rails and on and on. I ran into insurmountable difficulties installing the IDE, so I went back to the tutorial, which says you don't need an IDE, and the author just uses a text editor and command line.

Next, the tutorial explains how to install Ruby. But I've already got Ruby on my Mac, so that's okay.

Then it explains how to install RVM, which apparently lets you manage multiple versions of Ruby. But it doesn't say why you might want multiple versions of Ruby. But I tried installing RVM anyway, and ran into insurmountable difficulties with that, and gave up.

All of this took hours and hours, and (a) I ended up unable to install any of the tools that were recommended, and (b) I hadn't even started on the tutorial itself.

At one point, the tutorial says “Since gems [libraries] with different version numbers sometimes conflict, it is often convenient to create separate gemsets, which are self-contained bundles of gems." For a super-simple framework, this whole thing seems hugely difficult. I'm left with the impression that Rails involves dozens of different pieces developed by different people, with each piece iterating quickly through many version numbers, and thus that a huge part of using Rails successfully involves figuring out which version numbers of a given tool are compatible with the specific versions that you're using of all the other tools (“Unfortunately, gem updates often cause minor but potentially confusing breakage...”), and meanwhile both Rails and Ruby itself are also coming out with new versions regularly.

Finally I just ignored all of that, since I seemed to have approximately the right versions of Ruby and Rails already installed on my Mac, and proceeded with the tutorial. Except that when I tried to run the most basic Rails command, rails new first_app, it had to install all sorts of stuff, and when it tried to install sqlite3 (which I'm pretty sure was already installed on my machine), it gave a clang error. I Googled the error message (which is the tutorial author's recommendation for dealing with Rails errors), and found that the solution was to use ARCHFLAGS=-Wno-error=unused-command-line-argument-hard-error-in-future gem install sqlite3. Obviously, right?

Oh, and by the way, at some point in all this I had tried following the tutorial using my web-hosting account at Pair, only to discover that I couldn't, because even though Pair has Rails installed, running that most basic Rails command (rails new) requires root access so it can install various things. Really, Rails? You can't create a new project without root access on your machine? I gather there are ways around this, but I couldn't figure out what they were. So I just stuck with doing the tutorial on my own Mac at home.

Eventually, I managed to get through all of chapter 1, including deploying the super-basic demo app to Heroku (which I had never heard of, but which I now like), but it was so exhausting and frustrating that I set the whole thing aside for a couple of months.

Why did I even bother continuing after that point? Only because I suspected that I could learn a lot from Rails's MVC approach, which I hoped to apply to future web apps regardless of language.

So a couple days ago, I picked up the tutorial again and went through chapter 2, which still seemed to portray a nightmare of versioning spaghetti, but was fairly straightforward to get through. And then I hit chapter 3, and there was one easy line that resulted in an error message, and sent me down a two-hour rabbit hole of trying to install nokogiri, brew, MacPorts, and the Xcode command-line tools. ~Yup, Rails sure is a nice easy simple way to get up and running quickly!~

But you know what? Suddenly, partway through section 3.2.1, a bunch of stuff started to click. Test-driven development: cool! I knew the concept before, but had almost never used it; here it seems clear and intuitive and easy. And the need to use bundle exec with rspec suddenly made sense: it means run rspec in the context of the current bundle, which is to say the current Gemfile, which is to say the currently specified set of libraries and version numbers.

And then I pushed to Github and deployed to Heroku with a single command-line each, and I opened a page in Heroku and there was my web app running in production on a hosting platform, and that was kind of magical.

Oh, and I've been using BBEdit for many years but only now learned that you can type bbedit . to open a whole directory with a nice browse-the-directory view. Super-cool.

So I'm cautiously optimistic about the rest of the tutorial. But I really can't recommend doing anything non-basic with Rails unless you're a whole lot more comfortable than I am with navigating through mazes of detailed installation and configuration issues. If you're a professional programmer or a Linux sysadmin, then you probably are more comfortable with that than I am, in which case go for it. But if you're a hobbyist like me, then Rails may not be the best tool for you.

Or possibly the real moral here is that this particular tutorial isn't the best option for hobbyists—or to put it the other way around, that I'm not part of its core audience. In chapters 2 and 3, it provides a fun and accessible entry point for test-driven development and Heroku, and those parts are certainly suitable for hobbyists; but in chapter 1, it provides an extraordinarily high barrier to entry. So maybe someone like me who just wants an easy way to set up a toy web app for my own use should stick with the more basic Rails tutorials, like the abovelinked Getting Started.

And I still haven't figured out how to use Rails on a system where I don't have root access. The answer to that may be that I have to deploy to Heroku, but I'd rather be able to run my apps in my own account on my own server. Maybe I can code on my home machine and then deploy to my Pair account? I'm not sure.

...I think after I get through the Rails tutorial, my next step will be to try php-mvc, which appears to be a skeleton app in PHP, giving you the MVC structure without having to learn a lot of new framework stuff. I might also try a real PHP framework—I've heard good things about Laravel, Yii, Symfony, and Phalcon. But I suspect that php-mvc is pretty much what I want: a light facade of structure on otherwise plain PHP. In fact, I downloaded it and started to set it up the other day, and I may put the Rails tutorial on hold and try out php-mvc first. We'll see.

2 Responses to “Ruby on Rails: Not as easy as it sounds”

  1. nchelluri

    Thanks for the perspective.

    Looking back on it, yeah, I’m pretty sure it’s easy for a new person to get lost in there.

    If someone were to ask me how to learn Rails, I think I’d probably point them to Dave Thomas’ book:

    I first learned Rails with a much earlier version of the book, in 2007 I believe. It was my first experience with Ruby and I found it pretty smooth. I am wondering if you would have had a better experience if you’d gone that route.

    • nchelluri

      Sorry, one other thought: I believe that when Rails was introduced it was pretty modern with the MVC structure and the file layout.

      That was in 2004, though, and I believe that many of the best practices to come out of Rails have made their way into lots of other frameworks in other languages, including PHP. I don’t really know any of the open-source PHP frameworks so I can’t comment too closely, but I am guessing that as at this point pretty much every MVC web framework has been influenced by/borrowed heavily from/flagrantly stolen from Rails.

      I guess what I’m trying to say is that you may do just fine with a similar framework in any language, especially one like PHP with a vibrant community. But, I know that when I’m trying to learn something for the first time and someone gives me lots of options, I get confused and so let me just say: If you want to learn how to write web applications, I am fairly certain Dave Thomas will not steer you wrong.


Join the Conversation