Ruby in the rough

As discussed in an earlier blog I've been doing some work with ruby recently and have been reasonable happy with the ease of generating results. That was up until yesterday when I finally published the web page to our outward facing server. The page actually loaded just fine, it just was stripped of all of it's formatting, ok no big deal right? Yea... this problem managed to generate a days worth of rabbit hole endeavors to fix it.

The actual solution to the problem was trivial if a bit of a hack. What necessitated the hack is a bit of an annoyance however and slightly disappointing considering the nature of ruby on rails and the mongrel server system trumpeted as one of the best ways to run a rails application.

The main problem was that you can't properly deliver public asset items thru a proxy server (the recommended way to deliver ruby pages thru apache). Thus making those site resources effectively invisible. This is because by default ruby on rails uses direct addressing of resources instead of a form of relative addressing. This can however be worked around in a variety of ways, in my case I decided to solve it by using an asset server. More accurately I decided to treat the apache servers public area as an asset server for the ruby instance. This unfortunately is a bit of a double edged sword as it breaks the everything in one area solution presented by ruby on rails because now the /public area has to bet moved to the public areas of your apache build. On the other hand you still have your insulated ruby site (that actually runs pretty quick) which still allows you to use the proxy load balancer features of apache if your feeling so inclined.

The Red Pill:

Ruby isn't always the way to go, but you can program some pretty powerful sites using it however the mongrel server that's trumpeted as being wonderful hits a wall pretty quick. Since starting this post I have actually replaced it with a newer server named 'thin', it's even faster; o it's also STABLE. This sadly isn't a claim that mongrel can make. The hacks above are still required and indeed are probably required for many of the more nonstandard configurations you can setup for servers (I actually don't address my server at root, my virtual servers access at 127.0.0.1:<port number>/<appname> which contributes to the delivering my public asset issues but also insulates my management code from direct execution).

The Blue Pill:

If you aren't trying to build the next massively integrated services system (google, yahoo, msn for example) and aren't expecting to be hit by thousands of a users a minute ruby will get you there and you'll probably enjoy the development gradient along the way. For the majority of people (read, those with English grammar skills) will find the use find the language to be a breeze and for serious developers there's solid IDE systems on Windows, Linux and Mac OSX so you can develop on any or all of the systems simultaneously and have a fairly even development experience wherever you are. As an added bonus RoR lends it self very well to agile development for those coding maniacs out there.