This is Joshua Wehner's archaic Blog

Why I Like Rails

Spurred by this discussion and a desire to see more of this kind of thing, what follows is an attempt to explain why I like using RubyOnRails (Rails) more than PHP or Perl.

A Brief History of Me (as a Web Developer)

I started writing HTML circa 1996, first on a personal site, later for the student newspaper at college. Later still, I got a job with the Web team at The Columbus Dispatch doing the same things. Now, at this point, I've been a computer geek for a long, long time but, while I had done some programming as a kid, I hadn't really gone past my high school comp sci course.

To the present day, I owe my career as a Web developer to one line of code. Circa 2001, every day, the Web team puts a new batch of articles up on the site by manually entering the HTML links into a number of index files. What really gets us, is that every now and then, someone forgets to re-label the date on the front page of the site. So, for the better half of our day, visitors might think that we haven't updated yet, because the page still says that it's yesterday.

One random weekend, I put some time into researching options. I was vaguely aware of technologies like Server-Side Includes and Perl, and this "date issue" suggested it was time to learn more. I don't remember the exact set of paramters that drew me to PHP, but I have hazy recollections of Perl being too slow and clutzy, ASP being too platform-specific (we were a Mac and Linux shop, anyway), and PHP being "just right" in a Baby Bear kinda way. (And I think it was already installed on the server.)

That Brings Us to Rails

Well, not chronologically, but I said this was about Rails, so that's as much time as I want to spend on non-Rails background right now. Except to say this: The thing I always really liked about PHP was that it wasn't an attempt to hide the quirks of the Web from me. I write HTML fluently; I know what HTTP headers are; I can add a virtual host to an Apache server. I kinda like Web quirks, actually. To make an analogy, working with PHP was like working with TiVo - it's still basically a VCR, just a lot smarter.

The First Rails Experience - Things Do Not Go Well

Okay... Rails. It's early 2005. I have been vaguely aware of Ruby for some time. I had heard great things about it, usually muttered by Paul Graham types, a half-breath away from Lisp, Smalltalk or Squeak. I was also vaguely aware of 37signals, because of their "Design Not Found" series (a blog-like series of articles and screenshots that preceded SvN by a few months). I took notice of Basecamp because of its similarity (okay, superiority) to something I'd developped for use around our office. When they said something like "Rails lets you use Ruby for Web apps", I said "I have to check this out".

For those of you who've come to Rails recently (in the near- or post-1.0 stage), trust me when I say: The early days were rough. Not impossible, but definitely not easy. Curt Hibbs' article for OnLAMP, the well-known "blog in 15 minutes" demo, and a ToDo list tutorial were my touchstones.

It didn't go well. So, for a while, I kind of gave up on Rails. I still sorta liked Rails, but it was too frustrating to use, too hard for my puny brain to figure out.

The Second Rails Experience - Better with Books

Last September, when I finally got Agile Web Development with Rails, things started to click. I also picked up The Ruby Way (a Ruby cookbook of sorts) and read more than just Programming Ruby (aka "The Pickaxe") online. Symbols became less confusing, I adapted to some of Ruby's quirks (aka "started appending .to_s" to everything in sight), and ran through another tutorial.

In a burst of serendipity, I had a client ask for a shopping cart (the example app walk-through in AWDwR) just after I finished reading the book. Perfect! So, I went back through the book's example app, paying a bit more attention this time, and filling in some of the blanks in the book's walk-through (payments, mostly).

...and then the client killed Rails. Sigh. Er, to be more specific, the client's host killed Rails. Still. We re-did the client's cart project in PHP, but I had the Rails taste in my mouth now, and I wanted more.

I started re-building some personal/utility projects in Rails - my D&D spellbook, for example. Shortly after that, I built a social micro-app (the one I demoed at DemoCamp6) for friends going to a gaming convention. And an app I use for tracking my time and invoicing my clients. And I did, finally, have a client with a project that was a perfect fit for Rails (and hosting wasn't an issue).

Why I Like Rails, or What Made Me Come Back (and Keeps Me Coming Back for More)

I walked away from Rails for a bit. Too hard, too frustrating. What made me come back? What do I like about Rails now? Why give up a system I was familiar with for the unknown (or lesser known)?

Ruby Rocks

This is sort of "Why I Like Rails #0" - it's not really Rails, it's Ruby. I mean, there's nothing inherently wrong with PHP, unless you want to use it to write programs. The creator gods gave us object-oriented programming languages a long, long time ago, as far as I'm concerned, because procedural programming is messy. Change one thing and another thing breaks, move one library and you have to re-link a dozen projects.

Until I saw Ruby, I had been disappointed with every other language's implementation of OO principles. (Though I've heard Smalltalk is lovely...) For example, in PHP the syntax for accessing an object's methods are different than for accessing its objects (obj.method() instead of obj.property - note the parens). That just drives me up the wall - encapsulation my ass!

Ruby combines this OO beauty with wacky dynamic language properties in a way that constantly amazes me. Try this explanation of metaprogramming in Ruby for a taste of what I'm talking about. If nothing else, you really must check out method missing.

But that's not all - there's also irb ("interactive ruby" - sort of like a ruby shell) is a great tool for debugging wonky applications. Sometimes, I just want to test out a new Regular Expression or string slicing, to make sure I'm matching what I think I'm matching. PHP doesn't have anything like irb, nor its sexier cousin "script/console" - a Rails-based adaptation of irb that's pre-loaded with all my app's objects.

As far as I'm concerned, Ruby is the frequently overlooked, not-so-secret ingredient in Rails.

Organization

I hate being surprised. Taking over someone else's code is guaranteed to generate a few surprises. Heck, I frequently surprise myself - there's no standard way of organizing PHP source files, so no incentive to keep things organized the same way among different projects. Are your library files in "include/" or "includes/"? Are they prefixed ("inc_file.php"), suffixed ("file_inc.php"), or neither?

All Rails apps are organized in a fairly standard way. Controllers are in "app/controllers", Models are in "app/models", Helpers are in "app/helpers". Images? "public/images" Stylesheets? "public/stylesheets" Javascripts? "public/javascripts".

That's not all. There's a naming convention. It's not written in stone, you can adapt it to your needs, but by default... Models are the singular form of the table name. Table called "users"? Look for "app/models/user.rb". Controllers are usually the first part of the URL. Want the controller for "myapp.com/events"? Look for "app/controllers/events_controller.rb".

The point is: I can pick up someone else's Rails code (or my own old, half-forgotten projects) and figure out the structure intuitively. I can't do that with PHP, Perl, or most Web languages.

Configuration

In some ways, this is a sub-set of the Organization perk, but I really like it, so I'm listing it twice.

Early-stage PHP apps put the configuration (like database passwords) in the source file. Most developers figure out quickly that this is a bad idea.

So the configuration goes into a separate file ("config.php" is popular). However, the lack of a structured organization stings here again - there's no default place to put the config file. I've seen dozens of attempts to trick PHP into finding the right file (usually revolving around $_SERVER['DOCUMENT_ROOT'] in some way).

Out of box, Rails creates three "environments" - test, development and production. There's a configuration file that maps each environment to a particular database configuration. In most cases, all you need to do to get your app configured is to set your database credentials for the appropriate environment. (You can also easily create new environments - "laptop" is one I've used a few times.)

These environments also define other settings. Production, for example, will limit the verbosity of error messages, while Development provides more details. Again, the organization is fairly intuitive and works without my having to write any code, and it works pretty much the same way on every Rails app.

Ajax

Alright, I'm not going to go into all the pros and cons of Ajax, but let's just say: I'm going to use some Ajax here and there, and I'd like the process to be user-friendly for the non-Ajax crowd, and easy for me to maintain. It's complicated enough already, right?

Rails has one trick that I find particularly well-suited to work with Ajax: Sub-templates called "partials". (Honestly, I was hugely confused by partials at first. But, once I "got it", it was like a light flicking on.)

A partial is like a template stub. You can use partials for any repetitive bit of output you like. A blog app might have a partial for each post, as well as each comment. A data-grid might use a partial for each line-item. So, when you build an Ajax response, you can send just the partial, but it's still effectively the same template code you're using in the non-Ajax part of the app. In other words, partials let you define the output once and send as much, or as little, as you need for the situation. It makes Ajax-based apps easier to use, as well as less of a headache to maintain.

Things I Don't Like So Much

Nothing's perfect, here's my (short) list of gripes:

Rails doesn't exactly play well with others

Let's say I've convinced you - you like Ruby, you like Rails, yadda yadda. You're going to start using Rails on your next project.

First, consider this: Rails is a complete framework, and that means it doesn't always play well with others. If you've been doing Web development for a reasonable period of time, you've got tools and procedures built around the Old Ones. There are reportedly ways to get Rails & PHP to co-exist but - while I the difficulties seem to be more often over-stated than not - it isn't exactly a walk in the park. Likewise with legacy database schemas - the reported difficulties are often over-blown, but it still isn't exactly easy

It's not that you have to go "all in" with Rails, but that it's hard not to. (Oh, and honestly, how valuable is standardized organization - my favorite Rails perk - if half of your clients are still on old PHP sites?)

Rails could be friendlier to Newbies

Honestly, the standard documentation isn't as useful as PHP's: There are places where it lags behind the actual code; it isn't version-coded; there are no user-comments. (Though, some other sites are taking up the slack here.) And, again, Rails is a complete and complex framework, that means that it makes some assumptions about your project - assumptions you can override, but you have to know what they are first. There are also conventions in Rails that aren't well explained in the standard docs (what's Capistrano? what's a component? how do you create a plugin?) - though the Wiki is filling in here.

Also: I'm a big fan of Web developers who know the Web. While Rails, like PHP, doesn't try to pretend that it's any old app, I'm not sure it's the environment to learn to program for the Web. "What's a cookie?" "What's a session?" "Why doesn't this form work?" If you've never done any Web development before, Rails is a hard way to learn these lessons.

On the other tentacle: I actually think Rails is a great first-step into programming for designers. There seems to be some contractual obligation where developers have to look down their noses at designers, but I like designers, I think they get short shrift in this field. If you're a designer - who knows HTML and forms and Javascript, and you're looking to learn this "back-end server stuff", I think there's no better place than Rails to learn this stuff.

One or two Ruby gripes

I like Ruby, but no language is perfect:

"1" != 1 (aka "IntegerStrings are not Integers")

The error I see most often in Rails - after "You have a nil object where you didn't expect it" - is "Cannot coerce String into Integer".This is usually because I have attempted to concatenate something that my pesky human brain perceives as an "number", whereas Ruby is convinced it is a String (that it happens to look like a number is just a coincidence.)

This drove me nuts the first few times, now it just kinda irks me - but it's really me irking me. It's not Ruby's fault. I actually understand why it happens - and how to structure my code (and my thinking) so as to avoid it becoming a problem, and I even like some of the fringe-benefits (semi-automatic foiling of injection attacks being the main one).

Time is lame

There is one core class for time in Ruby - Time. There's a class in the core library - Date - which is useful for time-agnostic date calculations. Then there's DateTime, another core library module for... um... dates and times? Okay... So, do all these classes easily convert from one to the other? No, not really.

I guess it's not a big deal, but it's weird for a language that is otherwise very organized.

It also bugs me that Ruby's time-formatting options are fairly limited. "May 5th, 9pm" isn't easy with the standard approach. ("May 5, 9PM" is easy enough. Still, not my point.) There are ways to do it, but they strike me as awkward. Maybe I do more date formatting than the average joe, but I miss PHP's capabilities here. It seems to bother some people that PHP's formatting options weren't standard C compatible, but that never bothered me - they were damn useful is all I know.

The Arguments That Don't Track

Call it hype, call it a lightning rod, Rails has attracted a lot of attention these days. Here are the Rails arguments I've heard that just don't track with me:

Pro:

It's Fast!

Damn scaffolding. Damn "blog in 15 minutes" screencast. I mean, it got Rails a lot of attention, really fast, sure. But... Nobody I know uses scaffolding in a serious app, which creates this mid-curve "scaffolding withdrawal" for the Newbies lured in by the hype. And it's an easy pile-on for would-be detractors: "You're just going to have to rip all that auto-generated code out, anyway."

Say it with me: "It isn't about scaffolding, it isn't about speed, it isn't about 15 minute apps." If that's what you think Rails is all about, you're missing the big picture.

Con:

Only for the Web

As in, "Ah, but with Java, I can create a desktop application from the same code without re-writing anything!" Me? I build Web apps. Period. So far, that's it. The day I write a desktop app, I'll check back in.

Just a scripting language

Yeah, okay. So? Seriously? Honestly, people who argue against Ruby on this basis strike me as language snobs, if that's the best they've got to go on.

Doesn't scale

This has been hashed and re-hashed in the Rails forums, over and over and over again. Usually, the argument comes from Java-friendlies who should instead say, "Rails doesn't scale in the same manner as Java," which is true. Conflating that into a criticism like "Rails doesn't scale" is like saying, "But carrots aren't fruit!"

Slow

This is related to the "scale" protest, usually. It's true, Rails apps are less responsive than PHP apps when running on my iBook. But then, everything is slower when running on my iBook! On decent hardware, Rails is not perceptibly slower than PHP for anything I've thrown at it so far. On the server-side, it is also true that Rails+Apache+MySQL is not the fastest combination available; if your Web server and database server are fixed constraints, Rails apps may be a little slower for you, but that's not entirely Rails' fault, yes?

If this is really about speed, how fast do you need it to be? Compiled C (or, better yet, Fortran) are faster than just about anything, except maybe Assembler. The point is: speed and human-friendliness are always at odds. Pick which one is more important for you, but please don't complain that Ruby isn't both.

 

Final Wrap

Here's the thing: I'm honestly not trying to convince anyone to use Rails. I'm software agnostic; I'm not out to rewrite how you write your software. I am interested in two things, which are related to each other:

  • Less FUD, less hype - Rails has had enough of both. I'm sick of the "us vs. them", "Java / Rails / Python / PHP - sucks" language zealot attitude I've seen in too many of these conversations. The sky isn't falling. Rails wasn't written by magical pixies who take away all bad coders. Let's all be a bit more honest about our work, eh?
  • More Web, More Rails - I really enjoy what I do, I have for a long time. I enjoy building Web sites - for other people, for myself, for free, for pay. For me, this is as much a hobby as a job. And, as is hopefully very clear by now, I enjoy working with Ruby and Rails. I'm not married to Rails or anything - heck, I'm eager to see what the next generation's minds are cooking up. I'm just sharing here, alright?

Permalink • Posted in: about me, ruby on rails, tech stuff, web