Sorry for the long delay. I've been busy with a coup d'etat at work, putting down the reactionaries and writing a new constitution.

In my last job, I worked on the web front end for [link] I also have a video sharing app under development as a side project, and did an online version of a board game, also as a side project.

The best thing about Ruby on Rails is Ruby. It's an elegant, object oriented language that has become my favorite for just about any programming task. In particular, I like that it is object-oriented throughout and has closures.

Rails is pretty good too, though. It used the Model/View/Controller pattern to good effect, and it imposes a pleasing organization to a web application by default. And it has a choice of two really good testing frameworks, Test::Unit and Rspec. These sorts of testing frameworks are great aids to maintenance.

The object-relation mapping package in Rails, Active Record, is really easy to use. You can write statements like Dog.find_by_name_and_breed("Nutmeg", "Boston Terrier") and it will generate the correct SQL for you and then map the results into objects of class Dog. You can also tell it about the relationships between tables (has_many, belongs_to, that sort of thing) and it will write the joins for you.

As for performance, it's not the fastest web application environment around, but it does use a share-nothing architecture so that it's easy to add hardware to scale up to the point where your application servers aren't the bottleneck anymore.

Thanks, Rob. Teaser.I do love MVC, and faking that is a big part of what I want to do in the b.org code reorg.

I think I'll have to install RoR on one of the boxes at home and play.

Well, you can look around more at [link] I haven't put up much content yet, but you can get the idea.

Thanks.

Weirdly I suddenly had a flashback to RPG. It shares a "Well, we both know there are some fairly consistent things we can leave as subtext." Not to to mention the whole neat angle on data.

I came out of a Modula 2/C++ place with respect to data when I left school and bumped into the real world of code. I was so relieved to find out that I wouldn't need to be coding link lists 40 hours a week. Hell, the language automatically iterates through your datasets! That's a hell of a shared assumption. Which worked perfectly where we were using it.

But when you didn't want to? OY! I worry about RoR making everything looking like a nail.

RoR is quite narrowly focused. It's only useful for web applications with fairly simple database requirements and where you have good control over the deployment environment.

One of the weaknesses of RoR is that it spurns many useful features of relational databases. It has no support for using foreign key constraints or stored procedures, and if you try to use them anyway it can be quite painful.

Another weakness is deployment. You pretty much have to use FastCGI or something even fancier, like apache with mod_proxy fronting a cluster of mongrel web servers if you are going to host a largish number of users.

I'm surprised at the lack of support for foreign key constraints. That's one of the things I find annoying to duplicate when I'm trying to be a good little MVC girl.

But I can see the stored procedures thing. I want to use them to fake atomicity, but I can see where that might get in the way of their desired stratification.

Oh, and what's up with the web server reqs?

My understanding is that it's hard to get the update order correct automatically in the face of foreign key constraints. It could probably be done, but the authors of Rails don't feel like it's important enough to do. And it would probably be difficult to maintain across database servers.

The server requirements are due to the fact that a Rails app is expensive to load the first time. If you tried to run it via CGI and paid the load cost for each transaction it would be too slow. So you have to keep it resident, either via FastCGI or something like mongrel.

Rails is also a single-threaded framework, so each running instance of your application can only handle one request at a time. This usually means you need to run a couple of instances in a cluster to get quick enough response times.

This is changing, though, as someone has created an apache module (http://www.modrails.com/) that can host Rails applications.

God bless the geeks and the things they'll give away.

eta:

This usually means you need to run a couple of instances in a cluster to get quick enough response times.

How out of the box is this? I mean, if I install the RPMs on my box, have I gotten myself into the web server config business?

It has no support for using foreign key constraints or stored procedures, and if you try to use them anyway it can be quite painful.

OK lost me at no support for foreign key constraints. Maybe it is a matter of having written too many applications where FK contraints were critical. But I don't think I'd like the design philosophy of a system that considered foreign key constraints "not worth the trouble".

Not as strong on stored procedures. But really, there are occasions when they are critical too - as in you want to use a database, but you want to make sure you maintain security and integrity even if someone accesses it outside your application. Of course most databases have ways of turning stored procedures off.

Anyway, I admit there is more room for argument on stored procedures. But no foreign key contraints? Huh.