Ruby on Rails Review

  Ok, so I just finished the two pragmatic books, "Agile Development  
with Ruby on Rails" and "Programming Ruby". Thought I'd write up my  
impressions to share with the list. They're in no particular order:


  Background:

   I'm the Site Architect at www.marketocracy.com

   We probably have the most insanely complicated WO site in the  
world, developed in WO 4.5.x, which we've been successively patching  
to work with each new MacOSX release. I'm constantly looking at other  
web frameworks because my choices at some point are going to be:

    1. Port not just the portion of the site that is WO to Java, but  
all the other code as well (not a realistic option, we have many  
custom servers behind the scenes to deliver specific pieces of site  
functionality).
    2. Move to an Obj-C WO clone like SOPE.
    3. Move the Web UI to something else, which can bridge to all the  
ObjC code.

  Bottom line:

   Could I replicate Marketocracy in RoR?

   No.

   However, that's not RoR's fault. Marketocracy has extraordinarily  
heavy user sessions, something that RoR doesn't support very well. We  
also have a pretty complex data model, something that wouldn't  
interact well with "ActiveRecord", which is RoR's object to database  
layer.

   Could I do 99% of most websites in RoR?

   Yes. While RoR's preference is for lightweight sessions it does  
support a number of ways to distribute the session load for more  
complex websites. Marketocracy's sessions are just enormous so none  
of them would work very well. To be honest, WO doesn't work that well  
for us either; its just that nothing else would work any better. Lots  
of data is lots of data.

  Naive Apps:

   A naive RoR app is going to look and work better then a naive WO app.

   That is, a naive WO app is going to end up with a lot of regular  
actions. The "right" way to code a WO app is actually to use direct  
actions, and what we do at Marketocracy is we directly map page names  
to direct action names. We also rewrite the URL so that it is in  
canonical /key=value/ form, which makes our site searchable by Google  
etc. It's actually a trivial amount of code, but it makes everything  
much smoother.

   With RoR, you basically get that out of the box. You get a lot of  
stuff out of the box really; RoR is all about having "sensible  
defaults", so that you mostly have to only code the things that are  
unique.

   Given that even apps by "experts" (http://jobs.apple.com) have  
naive links, I think WO would benefit from having more sensible  
defaults. In fact, WO could be pretty easily tweaked to work a lot  
like Rails.

   MVC: (not!)

   Model/View/Controller really means "Model/View/Stuff" in my  
experience. That is, the "controller" code ends up being the place  
where "everything else" resides. It's kind of a test for me to see  
how frameworks that claim to be "MVC" deal with the "C" part.

   WO Tends to be Model/Component/Page/Session/Stuff. That is, your  
page or session often fulfill some of the controller duties.

   RoR has an explicit controller, which ends up being part of the  
URL chain. That probably ends up being a good thing. In my app, I  
tend to have root classes for certain pages where RoR would have a  
controller.

  On the other hand, its much more work to encapsulate "state" in a  
page in RoR, that ends up being the controller's duties instead. So  
that sort of implies that your "Views" are kind of stupid.

  Active Record vs. EOF:

    ActiveRecord is a little more advanced then "row=object" in that  
it understands objects, and ownership chains. But it doesn't do  
uniquing or change management like EOF does, and there's no editing  
context concept. So if you fetch the same row twice from two  
difference pieces of code, you get two different objects.

   Yet I suspect its fast. We find that adding EOF to a fetch makes  
everything 3x slower. So for simple to medium complexity object  
models, ActiveRecord will probably do just fine.

   There is one thing that AR does better then EOF: You can easily  
map a class to a column or set of columns. So if you have a value  
that can only be 1-5, you can write a class that both is stored as  
1-3, and returns the name: High,Medium,Low.

  The various template systems:

    I don't really like template systems that embed code. It's true  
as the book says that ruby makes most of that code trivial, and I'm  
not sure it's better to have:

<WEBOBJECT name=string></WEBOBJECT>

string: WOString { value = [email protected]; }

  in two files vs.

<%= list[1].name %>

  in one file.

But the real key with template systems is "How well do they play with  
Dreamweaver?" I feel that a key advantage of WO is that the HTML is  
separate enough that the artists can go off and design things without  
mucking up the code.  I don't know what the answer is for Ruby, but  
I'm not particularly happy with WO's template system either.

Then again, RoR supposedly is template system independent in that you  
can install other template systems. Ruby has an alternate template  
systems called Armita? where templates are legal HTML (it over uses  
the id="" field).

  None of these are perfect, and all could possibly fall down

  Scaffolding:

    The RoR scaffolding (basically a primitive direct to web) is good  
for Admin stuff. A little underwhelming otherwise though. There seems  
to be a penchant in the Ruby space for code generation...a lot of  
stuff in Ruby (like declaring accessors) is really generating code  
behind the scenes.

  Databases:

   RoR really, really, really likes MySQL, which I dislike. One of my  
compatriots has changes to get RoR working with Frontbase. I tried  
using RoR with sqlite only to find there were subtle issues: not  
RoR's fault.

  Caching:

  RoR has an interesting thing where you can cache fragments of a  
page. I could probably code up a WOComponent that did the same thing  
easily enough but caching seems to be well thought out in general.

  Unit Testing:

   The unit testing on the model side is well thought out. I  
especially like how you can bootstrap data into a "test" database for  
testing. However, I have yet to see a framework that tests the web  
side. :-)

  Scripted vs. Compiled

   Every year, this becomes less relevant. The reality is that the  
bandwidth to your web app is so much lower then the processor speed  
that a well designed scripted language might not make any speed  
difference at all. Still, garbage collection always makes me nervous...

   AJAX

  Ruby has some interesting stuff to encapsulate state built into the  
language, which I think helped the AJAX stuff immensely. WO has some  
of that (that's how 1.2.3.4 links work) but I think RoR is going to  
beat WO in this area for awhile.

  Final Verdict:

   I'd be very tempted to use RoR (with a real database) for my next  
app. It would have to have a reasonably simple data model though,  
without a bunch of strange interrelationships.

Pierce