Ruby on Rails Archives

I recently had the pleasure of deploying a few Rails applications to the FCGI funhouse that is Dreamhost, and just to make matters more interesting, I decided to do the deploys using Capistrano 2.0, rather than its better documented predecessor. After fumbling around a bit trying to translate various Capistrano 1.* recipes, as well as reading a number of postings about some incredibly descriptive FCGI error messages (”FastCGI: incomplete headers (0 bytes) received from server “/home/…./public/dispatch.fcgi”), I finally came upon a couple of postings that, when combined, provided the magic formula:

Getting Started With Capistrano On Dreamhost was an extremely valuable resource. The only deviations I made from this entry were the fact that we already have SVN up, asking Dreamhost whereis ruby, rather than taking the shebang suggestion at face value and running the chmod suggestions contained in the following post: Application Error - Rails application failed to start properly. For whatever reason, FCGi required our tmp and log directories to have 755 permissions.

Thanks very much to those two authors for their helpful posts!!

Two interesting recent articles on the virtues of keeping things (products, projects, etc) small and simple. Be humble, think about your users, create great projects and better code.

Congratulations to all the folks over at Shopify for being chosen as a finalist for the Webware 100 Awards. Based on our recent implementation experience, I think the distinction is well-deserved. We’ll be sure to cast our votes.

We don’t often write about specific technologies here at Bust Out, as we tend to be fairly agnostic and pragmatic about such matters, but we recently sent a contingent off to Portland, OR to attend RailsConf 2007 and we are feeling pretty darn excited about the Rails framework and its future.

What’s the cause of this excitement?

Rails, or Rails adoption rather, is maturing, as was evidenced by the number of talks at RailsConf dealing with what we’ll call “big application” issues, such as server virtualization, scalability “without bounds” and large-scale caching. It was great listening to developers who are pushing the framework into new territory and are devising interesting and creative solutions to resolve whatever performance or scalability issues they run into. It was also interesting to hear how many times Erlang was mentioned during these talks as a very scalable, high performance language that can be leveraged in Rails environments (web servers, messaging etc) to potentially help improve solution scalability.

Now, we’re fans of the Pragmatic Programmers, we follow the trends, read plenty of other blogs and we’ve read (at least half) of The Tipping Point during various bathroom breaks, so we get that Erlang is growing in popularity as well as vaguely how that sort of growth would show itself in a venue like RailsConf.

As such, in anticipation of next years language du jour, we here at Bust Out Solutions feel there’s an intriguing opportunity looming on the horizon. Forget Haskell. And Scala. And Lua. And OCaml. It’s Java.

Got scalability issues with your JRuby on Rails application? You COULD use Erlang-based services, but that’s so last year. Throw it on a cluster of WebSphere App Servers running on some monster AIX boxes, fire up your Tibco ESB for some distributed JMS-ing, WS-ing, JBI-ing or straight up BPEL-ing, get a copy of Oracle Coherence for your distributed caching needs (you can even toss out the database with a big enough grid) and you’ll be all set. There are a lot of choices, which makes the whole experience all sort of infuriatingly fun and lucrative for others if you’re the generous type.

If anyone is interested, we’re open to speaking at next year’s conference. If we get rejected, even better, as I heard RejectConf was more stimulating than the real thing. Or maybe we can write a book….Java for Rails Developers?

As an aside, hats off to the community at RailsConf for donating over $30,000 to charity. It was a great idea and wonderful gesture from the community. Next year, we can surely do even better.

We recently launched an e-commerce section of the Point Clinic website. Play handled the graphic design and photography, and Bust Out Solutions implemented the e-commerce functionality. We used Shopify, a Ruby on Rails e-commerce engine built by the folks at Jaded Pixel. Shopify allows you to create a full-blown e-commerce store in literally a few minutes if you use one of their pre-built templates. If your company is like Point Clinic and has a specific look and feel to your website, Shopify provides a template engine called Liquid that allows you to create custom designs. The learning curve for Liquid is rather shallow so I was able to run through several design iterations with Play.

Shopify also comes with an impressive admin interface that allows users to maintain items and item attributes, set stock on hand, create collections, set promotions, define shipping and handling rates, manage orders and backorders, track demand, and even create a blog. All basic retail functionality is available via the Shopify admin pages, giving you full power to run your online store.

We’re now offering Shopify design and engineering services to anybody who wants to get a relatively cheap e-commerce site up and running in no time. Contact us if you’re interested in hearing more.

I dug around for a while yesterday looking into how to close prototype modal windows upon a successful ajax post while ensuring proper error handling. I discovered two excellent blog entries on the subject at javathehutt and richtextblog. Unfortunately, neither of them quite fit my case or fully addressed my issue. Of course, I could just avoid the use of modal windows for my forms, but then what else would I do with myself on a Saturday afternoon? As it turns out, with RJS, what I needed is quite easy.

render :update do |page|
   page.call 'top.Windows.close', 'window_id'
end