I’m very pleased to see that an interview I did a while ago with Dion Almaer is available now as Audible Ajax, Episode 9. Dion and I spent about thirty minutes one morning talking about one of the pillars of Ajax, JavaScript. In the interview I’m a little too mellow, so I’ll remember not to schedule my next interview so early in the day. :-)

There are some typical interview slips o’ the tongue, and there’s an editing gaffe during my discussion of JavaScript’s misbegotten overloading of the ‘+’ operator, but I’m pretty pleased with it, and I’m grateful to Dion and Ben for the opportunity. Give it a listen!

(This is a little overdue, but it’s been a crazy couple of weeks.)

I enjoyed reading Avi Bryant’s blog a few weeks ago about Mind Camp. He was delighted about getting a great compliment for Seaside from one of the Rails faithful: “I defy anyone to come up here and use any other framework to duplicate what we’re doing in Rails as quickly. Except Avi.”

That is certainly a great plug for Seaside, and well deserved. But Avi’s delight itself pays a great compliment to Rails; “Could anyone ask for a better plug?” asks Avi, and indeed praise from the Rails camp for another web framework is high praise.

Thinking of that reminded me of a few weeks prior, when I attended the Smalltalk BOF at OOPSLA. A Smalltalk newbie was there, and asked if Smalltalk had anything like Rails. There were snickers, and a few snide-ish responses of “better than Rails.”

I kept my mouth shut at the time, because it’s rude to show up to someone else’s party and upbraid them. But I think the question of whether Seaside or Rails is “better” is very much open for debate, and heavily dependent on your particular situation. (Disclaimer: I’m doing Rails work right now, but I’m a vocal fan of Seaside and have been introducing people to it in talks at NFJS symposiums for the past 14 months or so.)

Which brings me to the other incident Avi’s blog reminded me of. In early October, Daniel Steinberg sent me a note asking for “the 30-second reason someone would use Seaside and someone would use Rails.” Here’s what I wrote in response:

Seaside is much more advanced but not so mature. It contains core features that are well beyond what Rails can do, and those features attack some of the most difficult aspects of web development. Rails, on the other hand, has many, many more features that attack most of the many, many tedious and mundane aspects of web development [and some of the surrounding issues like packaging and deployment, database access, and testing], and it’s well documented, widely understood, and well supported.

So unless you are really comfortable with Smalltalk and/or are doing some very ambitious things with stateful web applications and complex control flow, choose Rails.

That’s overly simplistic, of course, but that’s what you get in 30 seconds. :-)

Oversimplified as it is, I think it’s a good summary. Seaside was starting to get some buzz at one point, and then Rails came along and (it seems to me) stole most of it, and I think there’s a reason for that. The reason isn’t that Rails is better – it is better in some ways, but Seaside is better in other ways. I think it’s just that Rails’ strengths address problems that are particularly frustrating to developers right now.

But there’s a funny thing about pain: when your worst pain goes away, it doesn’t take long to start being annoyed by the next worst. So it won’t be all that long before Seaside’s particular strengths start to look really attractive to developers who’ve grown accustomed to Rails’ niceties. And then it’ll be time for Seaside (or possibly some other continuation-based web framework inspired by it) to get the buzz again.

There are things Rails can learn from Seaside, certainly, but there are also thing Seaside can learn from Rails, and that learning will probably happen in both directions. As Avi pointed out in another blog this week, Smalltalk and Ruby are much more similar than they are different, so I see the two frameworks complementing (and, as above, complimenting) each other for some time to come.

A few weekends ago, in Chicago, Ted Neward asked me an interesting question. I had a kind of lame, generic response at the time; it took me a few hours to really think things through and work out what I really think about the issue. I’m finally getting around to blogging about it.

The occasion was a No Fluff, Just Stuff speakers’ panel. As is usual these days, there was a question about Rails: “What do you think it’ll take for Rails to hit the mainstream,” if I recall correctly. I answered that Rails is already on a path that will lead to very widespread use, but that it won’t necessarily be smooth. I predicted that the next year would see a highly publicized “Rails failure,” caused not by Rails itself but by a company that tried to do Rails with the wrong team.

That was when Ted, who was moderating the panel, asked his question. “What is the right team, Glenn? Does it have to have Dave Thomas on it?” Of course, Ted was deliberately overstating the question to be provocative; that’s part of a moderator’s job. But there’s a serious question there. If you want to experience the benefits that are being claimed for Rails, what kind of team should you have?

If I had to explain Rails’ secret sauce in one short sentence it would be this one: Rails makes it easy to do the right thing. “The right thing” there means the kind of basic software design and development practices that are widely known, but not so widely practiced because the typical team isn’t very disciplined. Things like

• Writing clean, expressive code
• Avoiding duplication
• Keeping responsibility well defined (in layers, components, classes, and methods)
• Testing thoroughly
• Aggressively employing automation for repetitive tasks

Others might see different things behind Rails’ success, but for me, making it easy to do the right thing is crucial. Things that take a lot of discipline in other languages and frameworks become much easier in Rails. In some cases they’re so easy that they’re actually the path of least resistance. In others they still take discipline, but the drudgery has been reduced dramatically.

The key to building a Rails team is to choose a team that’s prepared to exploit that characteristic.

A good Rails team will consist of programmers who know what they should be doing, and usually have the discipline to do it. They have a good, solid grounding in software design principles and development practices, and a good track record of sticking to them on real projects. Such a team will fall right into the Rails way of doing things, seeing an environment where many of the barriers and obstacles fall away and they can do good work with less effort. This kind of team will see big productivity increases once they get the hang of Rails.

If you feel like gambling, you might not do too badly with some less skilled teams: teams that understand what the right thing is, but aren’t quite disciplined enough to do it consistently. That kind of team may find that, with Rails making the job easy for them, they can be a little more disciplined and start doing much better work. (Just making the right thing easier wouldn’t be enough, but Rails also exploits the No Broken Windows effect: the skeleton application Rails gives you to start out with is in such good shape that it feels wrong to mess it up.) Again, it’s not a sure bet, and you’ll be much better off with a team that’s already strong.

The wrong Rails team is one that doesn’t understand those principles and practices. The fact that Rails makes things easy won’t be enough. In my experience, such teams expend amazing effort and ingenuity to do the wrong thing.

(On the other end of the spectrum, there’s a fourth kind of team that is the ideal Rails team. The truly great Rails team will understand not only what Rails gives them but how it does it, and the team won’t merely benefit from Rails but will build on it, carrying Rails’ design philosophies and techniques into the domain of the application being built. Expect these teams to create their own Ruby domain-specific constructs, extending Rails to meet their own needs and amplifying their own productivity through the course of the project.)

So (you might ask) how are Rails teams any different from any other project teams? The answer is that they’re not. An experienced, skilled team will, in all likelihood, find ways to be successful. An inexperienced one can find many ways to fail. Somewhere in the middle are the teams where each project is a gamble: they might fail, or succeed modestly, or even succeed spectacularly, but it’s very hard to predict the outcome. No tool, language, or framework—not even Rails, which I think is the best thing going—will change that. When you pick up a powerful tool, it doesn’t eliminate your weaknesses; rather, it amplifies whatever characteristics you bring to it, strengths and weaknesses alike.

Rails gives a team some great tools for success. But the team has to understand those tools and be prepared to exploit them.

Same as it ever was.

I have to admit that my first reaction to Ted Neward’s blog about Rails was the same as Dion’s and Justin’s: “Ted’s missing the point.” But his followup has mostly changed my mind. Ted’s still skeptical, which is a good thing, but what he thinks he sees in Rails, and what he’s looking for, is (to my mind) the right thing, and my belief is that he’ll find it there.

Ted writes: “Look, guys, at the end of the day, if Rails is about Ruby and the things that a scripting language can do that a compiled, statically-typed language can’t, then Rails definitely has a place in the world and I’ll take the time to learn it.” My position is that that’s precisely what Rails is about. Sure, some of the lessons that Rails teaches can be carried across to statically-typed languages just fine, but some of the most important ones simply won’t translate. Rails is a testament to the power of dynamic languages in general, and of Ruby in particular.

Here’s one example: it’s a mistake Ted did make in his first blog, and it’s a mistake others make as well. “I mean, I see a bunch of intelligent code-generation,” Ted wrote, and if you’re coming from a static language background it’s easy to look at Rails’ scaffolding support and default views and think that’s what you’re seeing. I thought so, too. If that’s what the scaffolds are, they aren’t too impressive—partly because that’s easy to do, but mostly because generated code like that eventually becomes a burden. Most of us have seen code generation tools before, and they’re great for getting started, but when you move beyond what the generated code will do for you you’re in a world of hurt, often having to throw away what’s built into the framework and supply your own versions of everything.

But Rails isn’t doing “intelligent code-generation”—unless what you mean by that is that it’s doing the least possible code generation. Crack open those scaffolds and look inside. They’re almost empty! Usually they’re just trivial class definitions, with no methods or fields. All of the behavior comes at runtime, through inherited reflective logic. Rails is generating structure, not behavior, and that turns out to be a huge win. Ruby makes that possible, partly through its rich support for runtime reflection, but mostly because its dynamic, open nature makes it a breeze to fill in those empty spaces incrementally, overriding and extending little by little the default behavior that’s built into the framework.

And that’s just one example of how a dynamic language makes Rails possible, and why some of Rails’ goodness is easy for we static-language types to miss at first glance.

What’s Rails about?

• It’s about Ruby and the things that a scripting language can do that a compiled, statically-typed language can’t.
• It’s about confirming some of the earliest thinking about frameworks: that they should be extracted from well-designed applications, rather than being designed on their own.
• It’s about demonstrating the fundamental importance of the DRY principle for software design. (Bruce Eckel calls it “the most fundamental concept in computing.”)
• Oh … and it’s about bringing the pendulum back away from the layers-upon-layers default approach in Java projects.

When Mike Clark was writing Pragmatic Project Automation, he and I conspired about a few things. A biggie was build scripts—in particular, the expressiveness and power thereof. We persuaded James Davidson to publicly admit that the choice of an XML format was … well, not a mistake exactly, but ultimately a limiting strategy. And we wanted to demonstrate the usefulness of having a real programming language at your disposal in a build script. A lot of this came from our interest in Ruby and our use of Rake, but in the context of a Java-focused book Mike decided to demonstrate by using Groovy to script Ant. That was cool, but it just touched the surface. Since it wasn’t really the main topic of the book, Mike wisely kept it short.

Today, Martin Fowler blogged an excellent article about the strengths of using Rake. Martin gives it the full treatment, explaining Rake, how it’s similar to both Make and Ant, and how it goes beyond both of those older tools. He demonstrates in several ways how powerful it is to have all of Ruby available in build scripts.

My favorite line: “After all, until we tried it I thought XML would be a good syntax for build files.”

Read it now.