March 13, 2007
"Ruby On Rails"

Rocky Mountain Internet Users Group Minutes of the 8 May 2007 meeting, "Ruby On Rails"


Microstaff (www.microstaff.com) provides refreshments

Copy Diva (www.copydiva.com) provides the audio-visual equipment

NCAR (www.ncar.ucar.edu) provides the facility

ONEWARE (www.ONEWARE.com) sponsors these minutes.


About 50 people attended tonight's meeting. Josh Zapin facilitated and Jeremy Kohler recorded the minutes.


Josh welcomes suggestions for topics for future meetings, please email Josh with your ideas.

Derailed is an RoR user's group in Denver, and there's also a Ruby user's group that meets at Collective Intellect. Google it to find out more.


Ruby On Rails (RoR) has taken the programming world by storm since it was released to the public in July 2004. RoR combines Ruby, an object oriented programming language with super-clean syntax, with Rails, an open-source Model-View-Controller (MVC) based framework that enables development, according to rubyonrails.org, ten times faster than typical frameworks. The two together enable programmers to create fully functioning websites in a fraction of the time. There are demos on rubyonrails.org allowing you to build five-minute websites.

Sounds too good to be true? Consider the following:

- The official RoR website features two almost-too-good-to-be-true demos: Creating a Weblog in 15 minutes and a Flickr interface in 5 minutes. (I've personally tried them and it's true)

- RoR has built in AJAX libraries such as Script.aculo.us to make very slick user experiences within a typical web browsers, enabling a high level of usability.

- Apple will be adding RoR as part of their next version of OS X (due in October).

- Apple will be adding RoR as part of their next version of OS X (due in October).


David Gustafson (dave.gustafson@wyantdata.com) is Vice President of Technology and Product Development for Wyant Data Systems, Inc. Dave joined WDS from his position as Founder and Chief Architect of Cold Mountain Software, a provider of software services and products for project management and enterprise knowledge management. Prior to Cold Mountain Software, Dave was Chief Architect and Co-Founder of Accumedia.com, Inc., a provider of hosted and managed content management, control, and delivery systems targeted to the media and entertainment industries. Dave holds a BA in Physics from Middlebury College and has done graduate study in Computer Science at Worcester Polytech and the University of Colorado.

Wyant Data Systems: wyantdata.com
Ruby On Rails: rubyonrails.org


Ruby on Rails in Context: Should we care?

Where does RoR fit in the context of the programming world at large? Yes, We should care. If you don't remember much of this presentation, or if you completely forget that you were even here, just remember these two things:

1. How to peel a banana. Seems absurd. Well, monkeys peel it differently. They pinch the bottom to split it open, and that's the proper way to peel a banana. Go try it, but do it first at home where no one can see...you might make a mess.

2. Ruby and Rails are Real! You can't just dismiss the hype, so make a small investment to see how it might fit in the context of your work.

I'm not an expert on RoR, but I manage complexity and risk. I deal with problem spaces and solutions. What I do for a living: last week I testified before the CO legislature, doing IV&V for a voter registration system. So I have to testify about how well millions of dollars are being spent on this system. Would I advocate using RoR for implementing voter registration? Forget about it. It's just not mature enough for that.

I have a passion for programming languages. I was managing a Java app and a .Net app. The Java was a disaster, .Net was working well. So I did some experiments comparing productivity of various apps, timing how long it took to do a mini project. I threw Ruby into the mix. The result: What took 2.5 hours in Java took 15 minutes in Ruby.

Philip Greenspun says, "Java is the SUV of programming tools" It's like driving your giant SUV just to go to a 7-11.

Risk: "There are old climbers, there are bold climbers, but there are no old bold climbers." Climbing gear is heavy. Are you going to carry 60 pounds of gear just go bouldering? So Java is too heavy for some stuff.

Why should we care about RoR?

- In the right circumstances it gives you a 5- to 10-fold increase in productivity.

- It is subject to programmer motivation. Linus's Law: programmers go through Survival, Social Life, and Entertainment (the highest pinnacle). RoR can help them get there.

- It is subject to business motivation: productivity = $$


Rails is a full-stack framework for developing database-backed web applications. This is what most web apps are now. Database, reports, and forms. That's it. Based on Model-View-Controller pattern, which came out of Smalltalk. It all happens in the browser as part of Ajax.

Convention over Configuration: this is controversial. Instead of having a way to configure everything under the sun, you have to follow conventions. But if you do follow the conventions, everything just falls into place.

Meta-programming: This is generating dynamic code on the fly (you never see it) to process the tables you tell it about. It finds all the columns, like magic.

A language for mapping: It's very easy to specify class relationships. Little statements like "has many pictures" tells it about a one-to-many relationship, which saves you a lot of time.


Ruby is an interpreted scripting language for quick and easy object-oriented programming. It was created by an amateur who put together some small stuff to make Ruby: combining features of Smalltalk, Perl, and Lisp.

"High-level languages are often all treated as equivalent. They're not" --Paul Graham.

Using Lisp, Graham said he could add new features faster than his competitors could announce them. This is a historical example of using a language as a "secret weapon" to gain significant competitive advantage.

What's it like?

Convention over Configuration: Say here's a table, and it will go off and find all the columns. Not like XML which you configure like crazy. Don't get me started about XML. You screw up there and you could be chasing down issues for days.

With Ruby, it just feels like configuration, but you're really writing code. Like Emacs.


Embedded DSLs.
Rails is a domain-specific language specifically in the domain of creating database web applications. Ruby is very well suited to creating DSLs. It's not like Python, where there is only one way to do things. Ruby gives you a zillion ways to do things. Totally object oriented. "33.multiplynext" for example, is an object in Ruby if you want it to be.

Thoughts on Languages: The highest correlation between implementations is the programmer. Wide range of skills and speed. The difference between programmers is larger than the difference between languages. Usually the guy that knows more languages is going to be more productive.


Productivity questions: performance, scalability, legacy integration, range of application. It can't handle multiple-column primary keys, so often you must create views to handle legacy integration. So that's a bit tricky.

Should I bet my job on RoR? Go to my boss and take a stand?


Marketing and selling disruptive products to mainstream customers: for high technology, any successful item must cross the chasm between the "early adopters" and the "early majority" starting to adopt the technology. It's very difficult for a language to cross that chasm. Fortran, Cobol, C, C++, Java all did it. Now what's the next language? Will Ruby cross the chasm?

It needs critical mass of a programmer community, people who will bet their jobs on learning this language. Or a "killer app" can do it. Is Rails the killer app that will help Ruby cross the chasm?

Before Rails, I thought Ruby lagged behind Python and Perl because of less complete and less mature libraries.

Ruby Risk vs. Java Risk.
Ruby risk is going down, and Java risk is going up (because of its increasing complexity over time). Java generates confusion over which framework to use. But it's very hard to sell Ruby to someone who has already bet their job and critical software on Java.


- JRuby: a jar you put into your Java application, to quickly map out business rules. Running Rails on top of Java should soon be an alternative.

- Ruby on the CLR (Microsoft common language runtime)

- Microsoft is joining the party by announcing Silverlight and DLR (Dynamic Language Runtime), based on Jim Hugunin's work with IronPython, faster than CPython, made a DLR on top of thatCLR, that runsin the future should be able to run Ruby in the browser: no more javascript!

Pitfalls and Opportunities

It's simple and easy to get started, but subtle to achieve the kind of power that Rails displays. See the Ruby Quiz on rubyonrails.org.

When you create a Rails application you could approach it in a variety of ways. #1(good) Build your application on top of the Rails framework. #2(great!) When you build a Rails app, think how to extend Rails to build your own dynamic language for your specific domain.

This might be the most valuable recommendation you hear tonight. Implement your app as a DSL that extends the Rails framework. Make a DSL for your business domain.

Get Started!

Learn Ruby!

Explore Rails as an implementation for internal tools.

Make quick demos to get early validation of your ideas.

Parallel Development: Go have a horse race. Race the Java team to get attention. Do it for free to start.

Embedding Ruby: Scripting inside of other apps, like JRuby inside Java. Helps you streamline your development.


JokeVision.com was a perfect opportunity to try RoR. They were producing comedy video, originally targeting the cable TV market. Lots of content, but no buyers. They needed a database-backed website to engage viewers and gather new content. So they did it with RoR. It remains to be seen whether JokeVision will succeed.

Remember the banana? We think we know how to do something, and we are creatures of habit. But try something different. RoR should be taken seriously. It's not a silver bullet, it hasn't crossed that chasm beyond the early adopters, and so has a lot of risk. But it's a lot of fun too.

Q & A

Q: Is it scalable?
A: It's more scalable for the size of apps that people would do in short order. But there are going to be integration problems with more complicated stuff. So I don't know. I was using an RoR based project management website called Basecamp (basecamphq.com): SomeoneI overloaded it because we they had too many milestones. The service was basically unavailable for a day. That hurt my confidence in its scalability. They did solve it, but you can find yourself outside RoR technology pretty quickly when trying to scale.

Q: You can break the conventions if you really want to.
A: Yes that's true, it requires some extra effort to do so.

Q: What doesn't scale well?
A: Adding functionality to apps and changing requirements tends to create scaling issues. Like when your requirements for performance, volume, etc. change. For example, suddenly you find you have to handle huge image files and suddenly there's no infrastructure to handle it. More people can be trouble too: things don't scale easily to handle more people working on a project.

Q: How do you use AJAX and libraries to make it look pretty?
A: I'm still exploring this stuff. Libraries like Prototype can give an object-oriented feel to the javascript. RoR doesn't necessarily have a clear advantage, library-wise.

Q: Any high-scale web apps out there?
A: Basecamp is big, and I hear Amazon and Yahoo are using it experimentally.

Q: When do you know something can't scale any more? Where is the limit point?
Audience Comment: Ruby is single-threaded, handles one request at a time. So user scaling backed people up quickly, and you have to deal with the single-threaded problem using other technology like ApacheLib. This could change in the future.
A: This is one of the interesting things: like starting up the Ruby interpreter in fast-cgi to solve problems, and this chips away at your 10x productivity. But the same tricks you've used before will work here.
Audience Comment: There are some evolving technologies and people are coming up with solutions for scaling issues. It's a hot issue about RoR scalability.

Q: How mature are the tools for developing Ruby, other than Emacs?
A: All the usual tools work pretty well. I use RadRails which is a module for Eclipse. TextMate in Mac OS is good. More and more environments are out there to help you be productive. Create the database, create a Rails app, then create a migration. It's very rapid. It automatically creates unit tests. So you're using standard extreme programming tools to build things.

Q: What do you use for Ruby development?
A: Emacs and Eclipse. And a lot of command lines.

Q: What about IntelliJ?
A: It's a great environment, so keep an eye on it. Rails generates a console for you to allow you interactively create instances of a class and manage them.

Q: Any famous Ruby failures?
Audience Comment: It's too new.
A: Worst I know of is my own experience with Basecamp, but that was just a blip. I don't know how they resolved it, but they did.

Q: How about Rails as a cost-effective beta?
A: It's all about evaluating market acceptance. If you try something and mess up, you get bad press and it's hard to come back. So you need to build enough foundation to get started and to stay ahead of it. It's risky.
Audience Comment: You can't afford to go dark for six months while you're rebuilding.

Q: After the database is developed, do you still have the 10x advantage?
A: No, not in my experience. In Java we had to build some code generation to get it to work like Rails. Do I just switch to RoR? It depends on how much pain you're experiencing in your current process. Right now you need be in quite a bit of pain before risking a switch. It's risky to do wholesale switches; better to ease into it with something new.

Audience Comment: We're building a public site to track all CO legislation. We'll see how it goes with scaling.

Audience Comment: I started a website starting in PHP and then JSP and then stopped because it was just too hard. Then we switched to Ruby and suddenly we found ourselves doing things we couldn't even have imagined before. It sure got us off a plateau.

Q: Can you call DLL's and other compiled things?
A: Yes, you can extend Ruby with C extensions, embed Ruby in C. It's a pretty good technology for building in those kinds of things.

Q: Any good books and tutorials?
A: That depends on your learning style. The "bible" is the Picaxe book by Dave Thomas. Typographically strange, but pretty good. Also "Ruby For Rails": good for understanding Ruby as you need it for working with Rails. Also "Enterprise Integration with Ruby".

Audience Comment: Check out tryruby.hobix.com. It's got interactive cartoon web pages on Ruby that guide you. It's very good.
Audience Comment: There are also good resources at rubyonrails.org.

A: Continuations and Closures and Blocks take some time for you to get your brain around.

Select a Year

2008 Minutes
2007 Minutes
2006 Minutes
2005 Minutes
2004 Minutes
2003 Minutes
2002 Minutes
2001 Minutes
2000 Minutes
1999 Minutes
1998 Minutes
1997 Minutes
1996 Minutes
1995 Minutes
1994 Minutes

Copyright 2005 RMIUG.org, All Rights Reserved