Slashdot Mirror

There are a lot of anti-Ruby/Rails memes out there, but I rarely see any evidence to support them. One of the most curious claims is that Rails has scaling problems. The oft-cited example is Twitter, though their scaling problems have nothing to do with Rails. DHH (creator of Rails, so admittedly biased) has a pretty compelling response to this: http://www.loudthinking.com/arc/000479.html My sense is that the Ruby/agile community has made critical insights into the fundamentals of development, which allow them to be substantially more productive then their counterparts in e.g. Java. I actually work at a PHP/XSLT shop, and while I think we've built a really nice platform, I often feel that we make huge fundamental mis-assessments of the relative importance of things like ease-of-development vs. "performance". Whenever I read Ruby/Rails blogs or books, I just feel overcome with the sense that these guys "get it", and understand the the human cost of development is so much larger than the mechanical cost (servers, bandwidth, etc.) I agree there's no magic bullet, and there's no framework or language that can stop developers from implementing bad solutions. But I think the typical warnings against Ruby are badly misinformed.

The trouble is that RoR does have some serious issues - for example, it's apparently impossible to deploy in a shared-hosting environment.. Supposedly, the solution is for Dreamhost to "Wipe the wah-wah tears off [their] chin" and realise that the RoR community just don't care about shared hosting.

As pointed out a few post up, their problem with database scaling was solved quite quickly i believe:

http://www.loudthinking.com/posts/3-scaling-to-multiple-databases-with-rails

Seems like this is just another shot in the feud between Spolsky and Heinimer Hansson?

Ah, I was talking about your reference to a query like this: INSERT INTO foo VALUES(NOW());

In that case, you CAN do it... http://wiki.rubyonrails.org/rails/pages/StoredProc edures

BUT! That's not the Rails way. See this entry on DHH's blog.

David Heinemeier Hansson of Ruby on Rails, 37 Signals, Basecamp, etc. fame recently commented on the notion that tech writers should do it for the love of tech. His take on the matter is that the conventional wisdom is wrong and that new school publishers like the Pragmatic Programmers, who split proceeds evenly with writers and deliver content to the market much more quickly are the future.

Ruby on Rails is actually a generalized/modularized version of the production code used by 37signals, authors of Basecamp. That's how it came to be. Their developer, David Heinemeier Hansson, chose Ruby as their primary development language (gutsy, I have no idea why). As a course of building all of their products, he abstracted the framework he created and released it to the public as Ruby on Rails.

(apologies on any inaccuracies on the story. this is how i understand it, corrections welcome)

Interesting to note also that this Google's first buyout of a Ruby on Rails shop -- and apparently MeasureMap's team includes a core Rails contributor according to DHH.

I'm increasingly of the opinion that for all but the simplest of sites, there just aren't any good "off the shelf" content management systems, unless you have no problem with your site looking like the default installation of whichever CMS you chose.

Here's the logic:
1. A very basic site (read: a blog) with a very basic CMS is generally not hard to set up.

2. The technical issue: as sites get more complicated, the level of sophistication required by the user to install and maintain them increases. (In the extreme case, I submit Xaraya, a CMS so complicated that trying to create a site as simple as "I just want a page with our contact information on it!" becomes an exercise capable of inducing intra-cranial hemmorage). Additionally, any templating system required grows more and more arcane, until it is essentially indistingushable from the actual programming language in which it's written.For example: the easiest way of getting a Drupal site laid out and usable quickly is to use the PHPTemplate plugin - in other words, to just write PHP code. David Heinemeier Hansson, no stranger to controversy, went a step further than this and labeled general-purpose CMSes "pipe dreams," and said "I believe the time has come to mark a date in the not too distant future for celebrating the death of the general-purpose content management system." (Not like he doesn't have his own thing to push, but that's as may be. See also Jeff Veen's frustration with open source CMSes

3. The social issue: as the content management system grows more and more complicated, they become more and more intractable for the average end user. Responsibility for day to day site updates is pushed to the IT department, which is absolutely not where it belongs. (Once again, I give you the one, the only, Jeffrey Veen.)

I consider Rails to be nothing more than a collection of programming "best practices". I try to use many of the same techniques in my own programs. Indeed, I had a home-brew Perl framework that used some of the same techniques that Rails' Action Pack uses and I considered it my "secret weapon" for rapid development (NOT "prototyping".. just fast coding that doesn't waste time). As others point out, Rails is not about the "scaffolding".. the abstractions are deeper and more general than that.

I've been doing this programming thing a while and I consider it perfectly natural to "write programs that create programs". It's NOT code generation (that's when one program spits out a text file containing another program).. it's just dynamic programming: meta-programming and late binding and lots of run-time decisions. Sure, if you're not experienced, or you're still learning Ruby syntax, you might feel frustrated with an abstract meta-language. You should use the opportunity to learn and dig deeper, in my opinion. So 9-to-5 Java grunts may not enjoy digging deep in Rails, but maybe an old-school Lisp hacker would. Which would you like working at your org, anyway?

Ruby and Rails are great examples of why all that "metaprogramming stuff" is good to have in a language.. even if you don't personally use them, someone can create something cool with them that you can use.

So Rails code is very concise and well-factored, which is good.

BUT.. there is an unfortunate dark side to Rails. The author may be very bright and have great insights in procedural programming, but he simply does not understand data modeling, or it was not taught to him in school, or he chose to ignore it when it was. He thinks the logical model exists only in his code, and advocates a 1960's pre-relational style of application-centric data management. In fact, the Rails theoretical model is nothing more than the old network "model" (navigational queries, universal meaningless object ids, and no high-level declarative abstractions.. the programmer does the work). The Rails community, containing many data management novices eager to avoid having to *think* (this is different than doing less work!), follows right along. Some of the stuff in the Rails mailing lists and blogs is quite silly and flies in the face of data management best practices.

I would like to see an RDBMS that uses Ruby syntax and Ruby attribute types.. it would be a perfect companion to Rails, and would be easy to use and understand. I really get tired of these object-to-SQL mapping anti-patterns. Until then, anyone starting a Rails (or any other app) would be best served by ignoring any data management advice from the Rails community and learning some basic skills FIRST.. so your apps sit on a firm foundation! Rails, being well-factored, thankfully doesn't get in your way if you choose to do this.

So to answer the question.. yes, RoR apps are highly maintainable, provided you 1) understand the Ruby language and the Rails codebase, and 2) properly create your logical model *first*. And if RoR turns out to be the wrong choice at your org, a solid foundation will let you build new apps in a different framework without fear of conflicting with your conceptual model. Yes, having to do #1 and #2 means you have to actually spend some time learning before diving in and developing that critical multi-million dollar e-commerce site.... no framework can be a substitute for knowledge!

As others have noted, what Rails generates for you are stubs. Even if the stubs are full-featured enough to let you add, edit, view, and delete objects, they're still stubs. It's just that RoR is succinct enough that generating 150 lines of code (including action views and layouts) is all that's necessary to provide all of that functionality in a very basic way.

But, two links for your consumption.

My article on the topic of what I call Scaffold Withdrawal
http://www.slash7.com/articles/2005/12/07/the-fall -from-scaffolding

Structure generation vs code generation (from the Rails' creator's blog)
http://www.loudthinking.com/arc/2005_10.html

It's true that "Ask Slashdot" is vehicle for enlightenment, but I didn't think it was a vehicle for the basest laziness. I don't understand why someone would go Ask Slashdot instead of looking at a couple F/OSS Rails app packages and deciding for himself whether or not they look "maintainable."

If the submitter did, he'd find that it's clear that maintaining Rails apps is no problem. You don't have to know much about a given app to even do serious "maintenance" on it. As long as the programmer hasn't tried really hard to break all the benefits Rails brings to the table (regular file structure, MVC separation, clean models, helper classes, etc), then you'll already know a lot about how the app is structured before you even unzip it.

Heh. The presenter is David Heinemeier Hannson. His blog can be found here.

The demo on that page is often referred to as the "whoops" demo for obvious reasons. ;)

That Rails programmer guy only suggests that Rails developers use MySQL. He seems to hate PostgreSQL, Oracle, and all databases that enforce CONSTRAINTS. How do we know that it works in PostgreSQL (properly) when the lead developer doesn't think you should even waste your time with silly constraints?

Django leaders love PostgreSQL. I want to try Rails but I don't trust MySQL (or fans of it).

Active Record is opinionated software, just like the rest of Rails... And the opinion goes as follows: I don't want my database to be clever!

In other words, I want a single layer of cleverness: My domain model. Object-orientation is all about encapsulating clever. Letting it sieve half ways through to the database is a terrible violation of those fine intentions. And I want no part of it.

How the hell do you know that they don't scale? Have you tried it? It's called the 'share nothing' approach. Livejounal and yahoo both use it.

http://www.loudthinking.com/arc/000479.html

The programmer of Ruby on Rails also got the 2005 "Best Hacker" award by O'Railly and Google.

This years OSCON was all about ruby.. amazing stuff.

http://www.loudthinking.com/arc/000479.html

In particular... "The point is that the cost per request is plummeting, but the cost of programming is not."

And the cost of deployment is not either. Or any other of the people-related tasks in development.

creator David Hansson was recently recognized for his work, but rails has arguably had the most rapid adoption (in terms of both cool uses and number of end users) of any new open source project.

ASP.net -- Some good ideas, but I like the OSS paradigm too much to go back to proprietary stuff.

perl, PHP -- Great for small to mid-range stuff. Both excel at library support. Perl with CPAN, PHP with the many built-in functions (yes, they're unorganized, get over it) and third-party modules available. But they don't naturally lend themselves to disciplined structure that a large app requires. I started to feel the stress at around 20k lines in my last web app.

I'm not sure I can put C and agile in the same sentence. Wow, I just did.

Java -- All around great once you get up to speed, but man do you have to learn a lot. If you're using a pretty standard "lightweight" stack, you might have to be intimately familiar with Hibernate, Spring, and Struts, all of which have a huge variety of configuration options, gotchas, etc. You try to simplify with AOP tools, and more gotchas. It feels like there's too much software to keep track of.

Ruby on Rails -- feels halfway between Java and PHP. You get the benefits of that huge Java stack, with more unity and cooperation (and all of the docs in the same place!). The language is very flexible. I'm definitely working it into my smaller web projects, and every time it works, then I feel comfortable using it on a bit larger project. Once I got past the gotchas, I became about 50-100% more productive than with PHP.

Downside to Rails is the lack of thrid-party libraries, when compared to perl, PHP, or Java. And since we're talking about large projects, its unproven when it comes to scaling. DHH argues that it's boring to scale with rails.

I have a large web project coming up, and at this point I intend to use Rails for it. I'm going to have to drop out into C, or maybe use web-services RPCs for some of the heavy stuff (notably PDF generation). But I anticipate that the productivity will outweigh the cons.

Read up his blog post:
http://www.loudthinking.com/arc/000471.html

So the RoR creator boasts that microsoft is late to adopting AJAX. Didn't Microsoft invent XMLHttpRequest?

I predict there will be basically two categories of posts about Rails.

Either, one, that Rails is so amazing that after you use it sex seems laughably trivial by comparison, even and especially you count the production value -- one can, after all, only have one child (on average) using sex, but with Rails, dude, I HAD TEN.

Or, two, that Rails is no big deal, it's just another MVC re-think, heck I rolled one of those myself one afternoon a coupla years back, yeah it ruled but, you know, I'm really into that Java thing now. Besides, Rails is no good for BIG projects, for that you need Hibernate and a crane.

So I'll post one for the middle-of-the-road. Rails rules. I love it. I've reimplemented, in a week-and-a-half, a fairly large application that took me two months to do with Python. It's not a fair comparison because with Python I used Webware but did everything, like user management and logging, with no starting point, and also the first time around I wasn't as familiar with the problem domain.

With Rails I used the Salted Hash Login Generator which got the basics of my user login and management done in one fell swoop, an hour or two of work. I also re-used the view code from the Python app.

But the rest of it was fun. I enjoyed it. Things were done quickly and the API is awesome. ActiveRecord is not Hibernate -- yes, Javapeople, we know, we know -- but it's good. It's really good and super easy. And while there's some magic going on behind the scenes with Rails, it's not hard to understand at all.

That said, yes, if you're an online payroll system for IBM, Rails won't cut it. There are flaws, but for day-to-day stuff, not too many. It's updated very frequently, too.

My only complaint is the ubermensch of Rails, Dave Heinemeier, who, while smart, is also all too aware of it, and frequently shoots his blog off about topics which go beyond Web frameworks and into areas of either glib tech-prejudice or, at times, more subtle see-how-smart-I-am dorkposts -- the most insufferable species of Geek.

Otherwise, I strongly encourage anyone to check Rails out. It's great and a *lot* of other frameworks in other languages could stand to pay attention to the innovations in Rails. These innovations aren't so much technical epiphanies, as they are the meeting of many good ideas in one place, along with enthusiastic support and a lot of glue. Ruby's fun, too.

Check out, also, the frameworks from other languages which are shamelessly stealing from Rails:

Subway (Python)
Catalyst (Perl)

"The language itself is just becoming mature - with big strides (generics, etc) in Java 1.5." - emphasis mine

It's funny you should use that word. Last month the creator of rails wrote a posting on the very subject. Read more at http://www.loudthinking.com/arc/000434.html

>It's when the user wants to send raw SQL to
>the database that security problems could
>exist.

And pretty much any web application worth its salt will need to sent raw SQL with Rails, or else you're going to get the N+1 speed issue with ActiveRecord.

http://www.loudthinking.com/arc/000235.html

The creator of Rails uses Mac OS X.

Rails doesn't use continuations, nor does it support the Seaside-style of development. Love it or hate it, the creator of Rails made a conscious decision to keep things "boring", so that people would be able to pick up the framework without bending their minds too far. Rails is boring.

Rails is a pretty incredible framework. It really makes developing webapps (at least the core functionality) a trivial procedure. While clearly not as "High performance" as a Java/hibernate app could potentially be, it can handle more than enough load for nearly all applications. It's certainly worth checking out - even if you can't use it in production, you can prototype an app *very* quickly. The author has a neat "contest" between a Hibernate app and the same concept developed in Rails on his blog.

I purchased the previously /. reviewed Code Generation in Action from Manning for half price. So far, I am finding this book to be a pleasant ebook to read, despite it being in pdf, which is due to the writing's conversational style. There are others who are enjoying this ebook and its half price availability. I don't think I would be as pleased if I were to read an ebook of something like A New Kind of Science. ebooks will only get better and become more available.