Proudcloud hosted the Philippine Ruby Users Group (PHRUG) last night where the highlight of the meetup was a talk given by Carl Coryell-Martin, Managing Director of Pivotal Labs Singapore.

Carl was introduced to us by Terence Pua, founder/CEO of insync and curator for the Manila edition of The Startup Digest.

Carl Coryell-Martin sharing the Pivotal development methodology, cerveza in hand.

A few months ago, I posted a video of Carl’s talk at Echelon 2010 on Real World Agile Development. I’ve been following Pivotal Labs for a while and am intrigued by how they’ve evolved their work methodology throughout their organization. Highlighted by pair programming, work-life-balance, and of course Test Driven Development, Agile the Pivotal Way has been borrowed and adopted by many Rails Development firms.

They’ve even publicly shared Pivotal Tracker, their SCRUM project management tool which (through a quick survey) was being used by roughly 80% of the RoR developers in attendance that night.

PHRUG listening to the talk with rapt attention

It’s no surprise then that Carl’s talk was eagerly anticipated and well received by the philippine Ruby community, which also welcomed Carl’s colleagues including Mike Mazur. (I forgot your business card at the office @amir, and no-joy on googling you so i’ll have to edit this post later

We’re here at Proudcloud to build things, and much of our driving force comes from the ideas we brew and transforming them into awesome apps.

To make sure we don’t lose touch with the innovative spirit we feed on, we’ve designated Thursdays and Fridays as Days of Thunder, when everyone is encouraged to build out our internal projects, develop new stuff, and go into full hacking mode.

DoT was designed to put structure into our R&D efforts so that ideas we have aren’t eternally kept in the icebox waiting for “when we’ve got free time”.

For good measure, Saturdays & Sundays are there for when the hacking velocity becomes too strong to quit.

During DoT though, we never ignore client work as all our project engineers are ready to heed our clients’ urgent call.

We’ve recently moved most of our projects to Engine Yard because of its rails centric awesomeness.

While Proudcloud codes with Rails 3.0.0, Ruby 1.9.2RC and the latest builds of MongoDB/Mongoid, being on the edge does have its drawbacks when using hosting providers who need to play it safe with stable package releases.

When deploying Rails 3 Mongoid based apps on EY’s AppCloud, we discovered that;

• EY does not support MongoDB out of the box and requires custom chef recipes;
• You need to create a custom cluster of instances with MongoDB installed on a utility instance;
• EY’s latest installed binary of  MongoDB version is 1.4.4 while Mongoid 2.beta.17 requires >= 1.6.0.
• There’s no documentation anywhere to help you with this issue.

Getting MongoDB on Engine Yard

As a backgrounder, Engine Yard has custom recipes that will allow you to install MongoDB (and other packages) on AppCloud. The recipes can be found on github, with specific instructions for MongoDB here.

Remember though to un-comment the reference to MongoDB in cookbooks/main/recipes/default.rb.

The ridiculously simple solution: Portage

Trying to make various Mongoid versions and dependencies play well with 1.4.4 and Rails 3.0.0 failed miserably. EY support suggested we tweak the emerge recipes to retrieve the desired build and have the package installed during the EY deploy.

Jason Torres, who has a black belt in rails app deployment, thought otherwise and discovered a simpler approach.

Going into your utility instance’s shell, you’ll find the various Gentoo Portage package definitions for MongoDB in /engineyard/portage/engineyard/dev-db/mongodb-bin/. We wanted the latest MongoDB build which was 1.6.2 at the time of this writing.

The trick is to have Portage retrieve the latest MongoDB build. To do this, Jason merely copied the .ebuild definition for the latest build to another file, making sure that the target filename included the desired build version number.

When you run the emerge command, Portage determines the build version from the filename. Given this, the next step would be to simply execute emerge on the .ebuild file with the –digest parameter. This would add it to the Portage tree.

The last step would be to restart MongoDB.

note If you had not yet installed any MongoDB version on your instance, you can start instead with the Portage steps (sans MongoDB restart) and then proceed to the instructions for custom recipes.

So go ahead and get rockin’ with the latest Mongodb+Mongoid on Engine Yard.