Re: Ruby on Rails?

On 28. Oct 2005, at 11:57 Uhr, Paul Lynch wrote:

> The biggest downside of RoR is the virtual impossibility of installing 
> Rails on MacOS X.  That makes it way too flakey for production use.  
> Yes, I am aware that some people seem to get it installed eventually 
> (I did once, too).

It's actually no problem to install an run RoR on OS X. Your options 
range from a fully automatic installer to building it from source.

http://www.rubygarden.org/ruby?RubyOnMacintosh
http://wiki.rubyonrails.com/rails/pages/HowtoInstallOnOSXTiger

> The third is one that applies to all of these web and database 
> frameworks, as well as the gurus that espouse them - "those who do not 
> study history are doomed to repeat it".  I am suspicious of any 
> technology that doesn't acknowledge WebObjects - although I should 
> point out that Ruby has a strong NeXT/Cocoa background.

RoR focus is slightly different from WO. EOF is sophisticated and 
mature but it's also very complex and has a steep learning curve. 
ActiveRecord (Ruby's persistence framework) is lightweight and by far 
easier to use than EOF. It supports the key concepts of ORM and it's 
more than sufficient for most real world applications.

I don't actually see the NeXT/Cocoa background of Ruby. Not everything 
that's cool must necessarily come from NeXT or Apple.

> For mid size and small projects, it isn't at all bad.  Rails has a lot 
> of quite rigid conventions about names (pluralised table names, id for 
> key, etc), which help a lot if you adopt them, but annoy if you can't.

These naming conventions are not cast in stone. They support a logical 
an pragmatic way of developing your app and tremendously reduce the 
amount of configuration code you need to write. If you like to depart 
from these conventions, feel free to do so, but be prepared that you'll 
have to write more configuration code. I wouldn't call that annoying.

> Rails embeds code in html.  This is evil.

As long as this code is completely view-related (such as formatting a 
date, for example) it is perfectly well placed in a template. If 
there's controller or model related code in the template, it's the 
developer who is evil. Not the framework.

It is also important to note that Rails comes with two templating 
systems (ERb and Builder templates) and that you can easily plug-in 
your own templating system if you like.

> Rails has the assumption that you are developing a CRUD app (the same 
> as the basic WO model), which is only rarely the case for commercial 
> web apps.  I am not sure how well it adapts to other models, as you 
> effectively have to ignore the generated code to do so.  The general 
> feeling I get from Rails is that it slots somewhere in between the 
> freeform flexibility of general WO programming and the rigidity and 
> complexity of D2.  I'd far rather take the former, and am very 
> suspicious of needless complexity.

Have you actually seen anything of RoR besides the intro video? Your 
remarks are completely unfounded and misleading. Just in short: Rails 
does not assume a CRUD app, it doesn't generate any code if not 
explicitly asked to and you don't have to ignore any generated code for 
that matter.

> On the whole, I am inclined to take a conservative approach and stick 
> to WO for larger applications.  I am very familiar with performance 
> optimisation and scaling for WO.  For smaller apps, I think it comes 
> down to the trade off between OSS and the greater refinement of WO.  
> As buggy as WOBuilder and EOModeller/Xcode may be, they still have a 
> lot of offer in productivity.  Compared with other web projects, RoR 
> has the advantage of both a reasonably strong OO language and 
> integration across templating, db access, etc; there's really no 
> choice.

If you take the effort to give RoR a little more attention and perhaps 
build a real application, you might be inclined to change your 
definition of productivity. I might have to reconsider my definition of 
conservative if it means to stick with what you know and easily dismiss 
what you haven't really looked at.

Cheers,
Andreas