Rails Blurs the Lines

By Deane Barker on August 2, 2005

I’ve been working with Rails for a few weeks now and it’s making “install” vs. “build” decisions much harder —

(We interrupt this post to get two things out of the way:

  1. Yes, Rails is as good as everyone is saying.

  2. And yes, that pisses me off too. I worked so hard at becoming a PHP ninja that I’m bitter about having to walk away from it to get this level of functionality and polish. But, time marches on, and so shall I.

Okay, back to my point…)

At its core, Rails lets you build good stuff fast. Really fast.

Say you come up with a data model for your church Web site. Let’s say you have a half-dozen tables for various things you want to manage: sermons, news articles, staff profiles, etc.

If you have the database built, Rails will give you a functional administrative interface for the five tables in…maybe two minutes (you have to run the same script five times — how fast can you do that?).

Since you probably have some relationships in there — foreign keys and stuff — give youself another five minutes to set up all the management for those. Then give yourself maybe two hours to really dial in the interface, add validation, file uploads, etc.

So, in just over two hours, you’ve gone from five database tables to finished app. Users will tweak of course, but the way Rails puts it all together, tweaking is a wonderfully simple and elegant affair. I can honestly say I’ve never written kludge with Rails (yet — I haven’t been coding it long).

What this means is that the line blurs between (1) using a pre-built system, and (2) rolling your own system. In the above example, we rolled our own CMS…or did we? Sure we coded some stuff, but Rails did all the real work. In the end, we did less work than if we installed and configured a pre-built content management system.

It just so happens that we’re looking for a CMS for our church. I’ve always been in the “use a system that’s already been built” camp, but with Rails, I don’t know if that still applies. I’m looking at all these systems and thinking, “I only need 10% of the functionality they offer, and I could built that functionality faster with Rails that I could wrestle it out of any of those systems.”

So, like I said, the line between “build it yourself” and “install and configure” really blurs. You could look at it that Rails is the CMS, it just doesn’t know it yet. It just needs to be…oh, I don’t know…installed and configured.

I don’t want to reinvent the wheel, but with Rails, the wheel is there, I just need to smooth it out a bit. And is that so bad?

Gadgetopia
What Links Here

Comments

  1. I, too, am in the Ruby camp. Not just Rails, but the Ruby language. I’ve been doing Java since ’96 and in that time, I haven’t seen a huge improvement in productivity from the language itself. Ruby is an elegant language and sits between Java and PHP – it has the agility of PHP as a scripting language, but the elegance of Java and Smalltalk.

    One thing to consider, however, in the build vs. buy discussion: although you may get away with building today, you need to continually review build vs. buy (or maintain vs. buy if you’ve released the app into the “wild”). What solved yesterday’s problem may be too much work to solve tomorrow’s problem. Be willing to cut loose and move on, using [Ruby, PHP, Java, Python] to migrate the data from the old system to the new one. Although the barrier to entry to get today’s application going is lower with Rails, it doesn’t mean the problem will remain as simple later, in which case a buy option may make sense. Especially if you don’t want to maintain your quick Rails app months and years down the road…

    James

  2. I, too, am in the Ruby camp. Not just Rails, but the Ruby language.

    Yes, Ruby is a gorgeous language — just beautiful. So clear, so concise, so powerful. I’ve started doing all my Windows scripting in it. It’s where Rails ultimately draws a lot of its power.

  3. Daggone it, Deane – just when I finally make the full leap onto the PHP bandwagon, there you go riding out of town with some babe named Ruby (made in Japan, no less!) and riding out of town on Rails…it gets hard to follow you if you don’t slow down long enough for us to catch up (grin)…

  4. just when I finally make the full leap onto the PHP bandwagon, there you go riding out of town with some babe named Ruby

    It’s totally Joe’s fault. He runs through the Internet with his hair on fire. I just follow the smoke.

    But (ahem, unlike Joe), I’m still quite committed to PHP. It’s a great language and I love coding with it. I’ll always use it to some extent.

  5. Just when I was getting acquainted with PHP I see this and, taking your hint since you’re usually right, I install it and check it out. Absolutely wonderful, and I hate it for it. Why does it have to be so good?

    On the other hand, my mom finally has that computerized recipe book she’s been wanting for a while, and it didn’t take long at all.

  6. Deane, how would Ruby be to learn for someone with no programming and intermediate PHP background? I only do web-based stuff and was thinking about trying some OOP. Would Ruby (and then Rails) be a good or bad place to start?

  7. i’m a web designer with good html/css skills and a bit of php and javascript experience. mostly i get how it works, and can do the copy/paste/tweak thing, but i’ve been debating lately whether to dive into php full on. i’m also wondering if i should just start getting to know ruby and working with rails. any suggestions from those more experienced?

    thanks.

  8. The difference between PHP and Rails is largely the difference between Model 1 and MVC programming.

    “Standard” (Model 1) PHP will feel much more at home to you — requests come in to pages, and they’re handled at the page level. Everything you need to do is in the page, just like HTML.

    Rails is wicked powerful, and very elegant, but it will stand everything you know on its head. It will be very alien to you, since you don’t come from a programming background. It’s hard to get a grip on MVC initially. You’ll be better off in the long-run, but expect some frustration up front.

    Unless you plan on building Web applications, I would stick with PHP actually. For simple, dynamic, content-based Web sites, I don’t think Rails is going to give you enough advantage to offset the work it will take to learn it.

Comments are closed. If you have something you really want to say, email editors@gadgetopia.com and we‘ll get it added for you.