[Rails] [ANN] Gusto.com Rails Site

Wed Mar 15 18:20:22 GMT 2006

Hi NIck -

Sure I would.

Essentially we had been actively designing the back end database for this
application which BTW, also includes a full-blown content management system
that controls all aspects of the front facing gusto.com website.   We had a
very large model (100+ tables) built up to support the business goals and
had started prototyping the web application using Hibernate + Tapestry .  I
arrived at Hibernate + Tapestry from a desire to develop something that was
"like" WebObjects because at the time there was a lot of uncertainty around
the fate of WebObjects and I was also concerned that the community was so
small I felt it would be hard to find skilled developers as we grew.
WebObjects, in my opinion is the best Java based tool for building database
driven sites but I couldn't risk using it since it was very poorly supported
by Apple at the time.    So after a pretty good amount of research  I
arrived at Tapestry + Hibernate being that me and my team were all Java
developers for the last 5+ years.

Tapestry is a very complex MVC framework that had some points that were
similar to WebObjects but it also had all sorts of bizarre baggage like the
"rewind" cycle that quickly became unacceptable to have to code around.
Also in Tapestry the push is to make everything a component and most of the
time, we weren't getting any reuse out of the components we were writing and
had the added complexity of having to write and wire up a component which
weren't trivial to code in most cases.   Also the much touted feature about
Tapestry that your  designers have the ability to preview your templates in
the browser without having to run the application also quickly became a
farce due to the fact that to make the design work you needed to have a
"fake data" in there.  I mean you can't design a page that requires a <ul>
and yet have no list items so essentially you end up creating all this yucky
fake template to be able to preview and in the end we ended up mocking
things up in static HTML and moving it back into the Tapestry templates.

As for HIbernate, well that was just a plain bad decision.    Hibernate
while it does do lots of things and maybe is important if you have a legacy
database that you need to code against, is also a very complex framework
with which to code your application.   All of the developers on my team were
very skilled programmers but everyone agreed Hibernate was not fun at all to
work with.     Having to write a ServletFilter to close a database
connection on the fly because otherwise Hibernate would throw
LazyLoadExceptions was a constant annoyance.  The other thing I found
irritating about Hibernate was the community.   Time after time when
researching something in the forums I came to the conclusion that core
developers were the most arrogant SOB's I'd ever come across.  It's one
thing to be frustrated with newbies of which there were a lot, but to have
many many threads that devolved into name calling by a committer was just
absurd.

So after 4-5 months of this, Ruby on Rails came to my attention as the news
surrounding it increased.   I had been a big fan of Python and used it
extensively when writing data mining code so I wasn't a stranger to
scripting languages although at the time  I hadn't written any ruby code
other then hello world a few years ago.
But after seeing the video, I was tempted to download the framework and test
it out.  It was clear pretty quickly that the framework had a lot of
potential but I wasn't sure how to go about things so I put in front of my
team an option to take 2 weeks off from further Java development to attempt
a port of our 25,000 lines of code to Rails and to see how far we got for
one and to also assess the flexibility and productivity increase if any.
Keep in mind that none of us had every coded any Ruby.   We armed ourselves
with copies of the PickAxe book, Agile Development with Rails and jumped
in.
The first decision made was to adhere to the naming conventions instead of
trying to force our singluar based model and do all the rails
workarounds.    That was one of the best decisions we made.   By writing
some scripts against the schema it took about 2 days to modify the schema
via a bunch of SQL scripts to support the Rails naming conventions.    Once
that was done, we quickly ported a huge section of the website in the first
2 weeks.   In all it took probably 4 weeks to port both the user site and
the CMS back office application to Rails and it was all done with smiles on
our faces.    No more Eclipse, no more XDoclet delays when making simple
changes to a database table.     By the end of the port we had significantly
improved the application while at the same time dropping roughly 15,000
lines of code from the system which lowered the complexity of our
application significantly.

At the end of the day, the risk that we took has paid off in spades.  My
team is happy at work every day and we are pumping out more code and
features then I ever could have imagined was possible with such a small
team.

I think a lot of people worry about performance as did I.   Until we
launched I was nervous about how this was going to scale but now I feel like
it's going to scale very well and easily.   As has been said, the LAMP issue
has been solved and with the application of a memcached our site was hit
with Siege with 50 simultaneous requests and was delivering the hugely
database centric pages in under 1 second all from one server.  But under a
more realistic heavy load situation of 5 simultaneuous users we are seeing
200-300 ms response times.

Thanks again to this great community for making development fun again!  :-)

Michael Engelhart
CTO- Gusto.com

On 3/15/06, Nick Sieger <nicksieger at gmail.com> wrote:
>
>
> On 3/14/06, Michael Engelhart <moosebrookfarm at gmail.com> wrote:
> >
> > Hello -
> >
> > I wanted to announce a very large  web application that was built with
> > Ruby on Rails and runs the site Gusto! http://www.gusto.com/ .   It was
> > deployed yesterday in a little over 4 months of development with 3
> > developers.   The origins of the site were being developed in Java using
> > Hibernate + Tapestry and the decision was made to port the 100+ table model
> > to Rails to see if there were improvements in productivity and job
> > satisfaction.
> >
>
> Mike, would you be able to share some details of the decision-making
> process around moving away from Java+Tapestry+Hibernate over to Rails?
> We're all looking for good case studies and stories that will help us sell
> Ruby and Rails into existing Java shops.
>
> Cheers,
> /Nick
>
>
>
> _______________________________________________
> Rails mailing list
> Rails at lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060315/d0c40495/attachment.html