Re: Ruby on Rails Review

On Apr 11, 2006, at 1:50 AM, Andrus Adamchik wrote:


> Hi Pierce,
>
> Thanks for the RoR review. This seems to be consistent with what I  
> am hearing from others. Hope you don't mind my comments on some of  
> the general architecture points (mostly not RoR related).
>

  Not at all. I'm kind of proud of what we've done at Marketocracy  
with such a small team, so its fun to talk about it with people who  
"get it".

>
>
>
>>   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.
>>
>
>
> I have no idea how your current system is architectured, so I may  
> be totally off (see below), but I'd say look at web services  
> (that's your #3 I guess). I've never advocated casual use of any  
> remoting technology (EJB, web services, etc.), but when  
> *complexity* and *legacy* are the keywords, web service wrappers  
> can save you from a full rewrite. After a recent project at a big  
> former WO shop in NYC (mainframes and other "cool" stuff, you  
> know), I started to really appreciate that.
>
> On the other hand, nothing is ever simple. Most of my own WO apps  
> are fairly "flat" - all potential "service logic" is evenly split  
> between WO components and enterprise objects. Migrating such flat  
> design to services is probably as bad as a full rewrite.
>

  True enough. Web services would work for some things, and we've  
considered them, but that's just at the interchange layer, the hard  
part is that the servers that support the main website have to do  
complex business logic. Its moving the business logic that would be  
hard, not the interchange layer.

  Plus we had to do all this stuff 6 years ago, when the web services  
stuff was much less mature.


>
>
>
>> 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.
>>
>
> Cayenne supports Java 1.5 enums as attribute types. Probably  
> possible to do that with EOF/Java as well.
>

That was just an example. Mapping NSDecimalNumber to a "Money" class  
might be another.


>
>
>
>
>> 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.
>>
>
> From my experience none of the templating systems out there play  
> well with Dreamweaver... Or rather there is a human factor -  
> graphic artists tend to mess your dynamic artifacts no matter what.
>

  We have a really good guy at Marketocracy who actually does a  
significant chunk of the dynamic stuff. He's even slapped Dreamweaver  
into shape.

>
> So here is one more Java-based web technology that is totally worth  
> checking as a WO frontend replacement:
>
> http://click.sourceforge.net/
>
> Click uses Velocity templates that are as good or as bad as  
> anything else (certainly less verbose than many alternatives).  
> Click has clean static-like URLs. It doesn't provide any special  
> session state management beyond what a servlet spec does, leaving  
> it up to the user. But this is much better than broken or half- 
> baked implemehtation in some other WO-like open source frameworks  
> that I've used.
>

Hmmm... #if. Doubt dreamweaver likes that...

Personally, I'd like to see something more like HoTMetaL from Zope.

All of these break down once you have components though, because each  
HTML editor only understands their own component system...

  Pierce