Rails on the Run

Rails experiments by Matt Aimonetti


That’s now finally official, MerbCamp 2008 registration are open! What an exciting time!


To understand why I’m excited, we need to go back few months back. Merb was first released by Ezra has an alternative tool to handle file uploads. Merb came to reality because Ezra needed something fast, light and flexible to handle something that, let’s be frank about it, Rails had a hard time dealing with. Rails was king but was not as popular as now. Merb started as a simple Mongrel handler, in other words an alternative for small, light limited actions. Most people started using Merb simply to handle uploads. But as few cool kids started using Merb, they thought, hey, this thing is super fast, maybe I can use it to build small standalone apps. After all, hardcore developers don’t need “cool ajax helpers” and form builders to create a simple site. [Geoffrey Grosenback]() aka topfunky even proudly used Merb to reduild his site!
That was just enough to convince me to start using Merb back at version 0.3.4.

I was an active Rails user and contributor. Having to use a bare bone Ruby web framework was quite refreshing however the lack of testing framework was a real show stopper :( (Being hooked up on RSpec by Josh Knowles I ended up only writing a small portion of a Rails app with Merb 0.3.x (uploader backend).)

Quite quickly Merb’s philosophy changed and switched. The Mongrel handler framework started dreaming of becoming an alternative to Rails. Merb took the best from Rails but targeted another audience: the Ruby hackers living on the edge.
Merb prides itself in being less opinionated than Rails(that can be argued tho), ORM agnostic (supporting ActiveRecord, Sequel and DataMapper), Javascript framework agnostic and truly modular. People like Yehuda Katz, Michael Klishin aka antares got involved, as more contributors joined the effort, rules were enforced to make sure the framework would be as fast as possible and easy to extend without monkey patching. (ohh and fully tested using RSpec ;)

Engine Yard decided to support the development effort and helped with Merb’s major rewrite (0.9 versions). Today, Merb is divided in 3 repositories, merb-core, merb-more and merb-plugins. By letting developers only choose what they want to use and by following a principle of isolation with private/public APIs, I believe Merb is today the most flexible yet powerful Ruby framework available.
Furthermore, even though many people don’t understand the purpose of rewriting a “new Rails” from scratch, the reality is that many progress made by the merb team were ported back to Rails and inspired others (DataMapper for instance)!

Anyway, this is not a sale’s speech and I’m not trying to convince you to use Merb. My point is that Merb is finally coming to a point where the public API is stable and where one would find most tools he needs to build production ready applications.
And, that’s basically a long sum up explaining why I wanted to organize something special to celebrate the 1.0 release and to create more awareness around Merb’s awesomeness!

The Team behind MerbCamp

I started getting involved with the SDRuby community a couple of years ago. As I got to know more people I realized that many people lead by Patrick Crowley (leader of SDRuby and one of the organizers of SD BarCamp) had the desire to organize a local Ruby conf/camp.

At the same time, while I was working daily with Merb and contributing back to Merb’s code, many other SDRuby fellows were also getting really excited about Merb (Rob Kaufman, Ryan Felton to mention a few).

Seeing the opportunity to host the very first Merb event in San Diego (host of RubyConf 2005!) I chatted with yehuda and the rest of the merb team. All the merb people were really excited, Leah Sibler from Engine Yard even offered her expertise to organize such an event (she’s totally awesome at planning/running conferences).

However, setting up such an event isn’t something one can do on his own. Before promising anything, I checked that Rubyists from San Diego would be interested and would help. In no time, I got a lot of people offering to help.

The key thing for me was to get someone with a good experience in organizing conferences. A person with resources and contacts. The only person I knew in San Diego who would be good enough to do that was Patrick Crowley. We had a quick chat Patrick and I and it turned out that Patrick was very excited about organizing the very first MerbCamp in his town.
Patrick quickly got a team together who agreed on working on the project. We got back to the Merb team and sealed the deal.

Patrick even found the awesome venue that many other cities will envy us! He’s been running the show, running here and there, making phone calls to make sure registration would open on time, setup the website etc…. Thanks Patrick!

The Conf

MerbCamp will be an hybrid between a BarCamp, a conference and an unconference. When the organization team got together, we all agreed that what we like the most during conferences is networking. We certainly also enjoy some good talks and definitely enjoyed the hack-room during the last Rails Conf. We therefore decided to organize a conf *we* would love to go.

  • 1 scheduled track with “official talks” to make sure we have some serious content and to motivate people to signup ;)
  • BBQ at the beach, because we live in San Diego and we love that! (plus, big open meals are the best way to network)
  • BarCamp type impromptu talks
  • hack-rooms so people can work together
  • friendly and small conference (we limited the amount of participants to 200)

To conclude, I hope the “history” of MerbCamp 08 wasn’t too boring. People seem quite excited about this event, we even have guys in London who would get together to watch the talks via a webcam we are going to setup for them.
We hope to see you there, if not, we hope you’ll organize your own conference and we will come have fun with you.

Like most people who started with Rails a while back, I first loved Rails fixtures and ended up hating them (slow, a pain to maintain etc…).

I went through different experiments, trying different existing libs, writing my own solutions etc… I wasn’t quite satisfied until I found factory_girl from thoughtbot.

You might not feel the need for a decent fixtures solution if you do a lot of mocking/stubbing, but I recently came back from my “mock everything you can outside of models” approach and I’m getting closer to the mock roles, not objects approach. So, I’m loosing my model/controller testing separation but I’m gaining by not having to maintain “dumb mocks” which don’t always represent the real API behind. I mean, how many times did I change a Model, messing up my app but all my specs were still passing. Anyway, that’s a long discussion, which will be covered by wycats during merbcamp

So here is a simple example of how I use factory girl in a Merb + DataMapper app. (you can do the same in a Rails app, there is nothing specific to Merb in factory_girl).

  • I. create an empty app, set the ORM etc…
  • II. git pull and install factorygirl from http://github.com/thoughtbot/factorygirl/tree/master. Or install thoughtbot-factory_girl gem using GitHub gem server.
  • III. create a spec/factories.rb file. (You might prefer to create a folder called spec/factories and add a factory per model)
  • IV. modify spec_helper.rb and add the following
  require 'factory_girl'
  require File.dirname(__FILE__) + '/factories/index.html'
  • V. write some specs against a Client model

  • VI. Create the Model

  • VII. create a factory

  • IIX. run your specs

    failing specs

  • IX. fix the model (note that I set dependencies "dm-validations" in my init.rb)

  • X. run the specs

    passing specs

  • XI. add more specs

As you can see, Factory.build(:client) only creates a new instance of the Object, while Factory(:client) creates, saves and loads the instance.

  • XII. get them to pass

Factory Girl makes fixtures simple and clean. Here is another example for creating associations:

Factory Girl also supports sequencing, check out FG read me

In conclusion, Factory Girl is a mature and solid factory solution which will take you less than 15 minutes to get used to. It will offer you loads of flexibility and less frustration than good old yaml fixtures. You can also use it with existing fixtures if you want to start using it in an existing app.

Wow, it’s been a while since I blogged. With all the cool kids saying that spending time reading RSS feeds is overrated (see Defunkt’s keynote for instance) I even wonder if people will ever read this post!

Anyways, I have been quite busy preparing courses for classes I gave to a bunch a great Engineers at one of the Fortune 100 companies based in San Diego. I was also planning my big vacation trip to Europe and wrapping up few projects.

However, during my exile overseas, I came to the conclusion that Rubyists don’t scale. Since Twitter became stable again, we don’t hear many people ranting about Rails not scaling anymore. With one of my clients’ app handling around 7 million requests/day I can tell you Ruby/Merb do scale quite well! But ruby developers don’t seem to scale for some reason.

Maybe saying that we(Rubyists) don’t scale isn’t technically correct but that’s basically what one of my client told me.

Let’s go back in time a little bit and follow my client who we will call clientX.

  • ClientX has a great concept and wants to conquer the internet.
  • ClientX hears that Rails is the way to go.
  • ClientX hires a contractor/mercenary/freelancer/guns for hire/consultant (aka Me)
  • Me builds a killer app using Merb (killing framework)

  • ClientX raises loads of $$$

  • ClientX wants to hire a team because Me doesn’t want to become a FTE

  • ClientX and Me look for Rubyists wanting to relocate and get a decent salary
  • ClientX *can’t find someone they consider good enough and who would accept their package

  • Many JAVA guys are available on location and accept lower packages

  • Ruby app gets ported over to JAVA
  • Me sad :(

So is it really the Rubyists’ fault if we don’t want to relocate and only accept higher packages? Should I blame Obie for telling people to charge more and teaching how to hustle? Or should we just tell clients that it’s time to get used to working remotely?

Honestly, I don’t think any of the above explanations are valid. Ruby is the new/hot technology and very few people have the skills and experience to lead major projects. These people make a good living and enjoy their “freedom” and dream of building their own products. Most of them/us value their work environment, family and are reluctant to move.


At the same time, companies do need people locally(at least a core team) and can’t always afford the cool kids.

ClientX, quite frustrated by the whole hiring process told me once: “you Ruby folks are too unavailable and difficult to work with! We need a committed team that actually cares about the company/product.”

That hurts when you worked hard on a project and just can’t satisfy the client by finding guys willing to relocate and work for them. It gets even more painful when your code gets entirely ported over to JAVA!

But at the same time I understand ClientX’s motivation, PHP guys are cheaper, JAVA guys are more available, why in the word did we go with Ruby and are now struggling finding people?

Once again, there is positive and negative side in everything, by choosing Ruby and a “great contractor” ClientX was able to catch up with the competition and even pass them in no time. They quickly raised good money and got everything they needed to become #1. I don’t believe it would have been possible to do the same thing so quickly with JAVA for instance. However choosing a cutting edge technology means you need to look harder for talented people.

It’s too bad the code gets rewritten in a different language but at the same time, I do my best to facilitate the process and to keep a good relation with my client. There was nothing personal in the decision, it’s just too bad we were not able to keep on using the latest/coolest/awesomess technology available :)

To finish on a positive note, here is the solution to scale your Ruby task force provided to you by the #caboose wisdom:

Based on my conversations with other #caboosers who hire other devs, the word in the street is that you just need to get one or two great ruby guys (who will probably cost you a lot) and find a bunch of smart people to train. You’ll end up with an awesome team of scalable rubyists ;)