It had to happen.

I think I must be the only person in the PHP blogosphere who hasn’t said something about Ruby On Rails.  It seemed about time 🙂

We’ve been working for a while on a RoR project.  Originally it came in as a really high concept idea – the spec was more like a film treatment than a functional spec.  It came from the mind of an old friend of one of our biggest clients – he’s a high concept guy, who’s been amazingly successful with his out there ideas in the past.

So we set out to build a prototype in six weeks.  We are known as a PHP shop, although of our web dev, about half is in PHP and the other half in Perl.  At the time we had working for us a very talented Rails guru, so we thought we’d give it a try. 

Times change: the prototype turned into a production website, our Rails guru moved on to a pure Rails shop, and we now support this Rails app (served from lighttpd against PostgreSQL on Solaris).

Things I have learned about Rails:
– It makes getting started easy.  This is what it’s famous for.
– We had to do quite a bit of work to get everything working happily on Solaris (as part of our migration to doing most of our web dev in ZFS zones).  This included building custom packages of Ruby 1.8 on Solaris 10 resulting in numerous patches to Ruby’s build and configuration processes and building custom lighttpd for Linux and then Solaris 10.  We developed numerous patches addressing unexplained crashes, errors on large file uploads, and improper use of timezone localization.

– As things get more complicated, the ideal of convention over configuration starts to get in your way.  In several cases we have obtained huge performance improvements (up to twenty times) by hacking around the conventions.
– The documentation sucks.  This is however, improving.  I remember when I first started learning the language and platform there was an initiative on the Rails website to pay someone to write some, "because all the people that really know Rails are busy building apps or writing books about it".  This is indicative of another issue, namely:
– The community support is really immature.  Something I know as a long time user of lots of different Open Source technologies is that a good community can make or break a product.  For example, for a long time the MySQL community was much more supportive of new users than the PostgreSQL community.  I love Postgres and have been using it for years, long before I ever touched MySQL or wrote any books about it (although I have tech edited a Postgres book).  I am really pleased to say that the Postgres community has become seriously good in the last year or so.
– Learning to debug apps is really really hard to begin with.  All the magic that goes on makes it hard for the newbie to figure out what went wrong.  How I wish I had known more about script/console at the beginning. 
– Because of the state of the documentation, I bought a few Rails and Ruby books.  The first one I read was the Agile guide.  I found it interesting how this book is aimed at Java programmers.  All the arguments for switching to RoR are arguments for switching from Java.  It never occurred to me that people would be doing that.  This is a very readable book but I need more depth.
– What I want is a book on debugging, maintaining, and scaling RoR apps.  Recommendations welcome.  Worst comes to worst I guess we might have to write one.

The project is possibly the weirdest thing that’s ever been built with Rails – the functionality at its most basic is very very straightforward, but as my colleague put it "This site violates pretty much every rule of web UI design. The content
on the site is not information as much as it is a bunch of people
arguing about current events and the righteousness of public opinion….if you can survive the outright attack on the senses, it is clever and punchy on both the concept level and technical level".   That sums it up pretty well.

It’s been and continues to be an interesting journey.  The site is visible at

Footnote: Just as a note on the design – it’s entirely true to the client’s original vision and has been an interesting challenge for the UI designers (who have also been responsible for sites such as (our original designer, Amy Hoy) and (today’s designer, Dai Swengler).

3 thoughts on “It had to happen.”

  1. What you mentioned about issues with Solaris reminds me of something that’s bitten us in the ass many times: a lot of OSS devs seem to think UNIX == Linux, and make lots of assumptions about the Linux-ness of your OS. This is infuriating when you have not only a non-Linux UNIX, but are installing things in nonstandard dirs (I bet you thought that –prefix setting meant something, but not to MySQL 4! Ho ho ho!). Add in wanting to use the Sun dev tools instead of GNU, and it’s kind of a clusterfuck.

    More recently we’ve been running Gentoo on our internet app boxes, so this has been less of an issue, but Solaris 10 is tempting us, as is the idea of Sun continuing to sponsor us. The Sun Coolstack stuff looks like a step in the right direction:

  2. I’d love to know what build and configuration issues you hit on Solaris 10. I’ve hit some in the past, but nothing lately, and I run Solaris 10 + Sun Studio 11 here at work (next to my Windows box).

    Please submit these issues to either ruby-talk or ruby-core!



  3. First off I’m a PHP developer in that I’m paid to write PHP. I’ve been getting more and more into rails and ruby in general. I’ve noticed that a lot of the stuff I missed about PHP at first were just bad habits and crutches. I too was scared about the debugging problem. I was so used to writing some code, testing it in the browser, debugging, testing in the browser… rinse repeat. Then I realized how easy it was to use test driven development, it’s baked right into rails and I rarely worry about “debugging”.

    As far as the documentation and community support goes I’ve found that while there isn’t as much volume (compared to PHP) the quality is much better. I’ve never liked the community code snippets in the PHP manual, a lot are out of date and many of them display all of the bad ways one can write PHP. I’ve read the same Agile book a few times and I’ve never noticed anything specific about Java developers, not sure where you got that.

    In the end, I’ve found that RoR apps are easier to develop, are easier to be agile with, easier to test and in my experience take much less time to “ship” compared to the way I would do things in PHP. Plus Ruby is such a wonderful language! After I spend all day slugging through PHP I can’t wait to get home and work on a Rails project.

Leave a Reply

Your email address will not be published. Required fields are marked *