While people still try to find some drama an in hypothetical war between rails and merb.

The Rails team and the Merb team announced working together on a joined version of the 2 frameworks. This is so exciting, nobody believed it could ever happen (I personally, had my serious doubt).

Yehuda had a great post laying down the plan and explaining things in details. Check out David’s post explaining why he wants us to work together and his vision of a better Ruby world.

I have to say that I have been impressed by the Rails core team and especially David (DHH).

I’ve known David for few years now and we had long/heated discussions on topics like i18n/l10n for Rails. David is known to be a very opinionated person. But if you come up with the right arguments, he can be convinced and when that happens, he is willing to move forward and shake things up.

This merge is a concrete example that David and the rest of the Rails team cares about Rails and the Ruby community more than we usually give them credit for. As a unified team, we are going to change the way web development in Ruby is done!

But what does it mean for you?

I put together a FAQ video here is the transcript:

Hi, I’m Matt Aimonetti from the merb core team and as you might have heard, a big announcement was made earlier today.

I did this video to hopefully answer the questions you might have.

Q: So what’s the big news?

• merb and rails team will work together on the next version of their frameworks
• merb 2.0 and rails 3.0 share the same common endpoint
• we realized we now have the same objectives and agreed on all the key principles.
• merb will provide Rails with agnosticism, modularity, improved performance and a public API.
• The end product will be called Rails 3.0 but what real matters is that it’s a huge gain for the entire community.

Q: What??? I thought there was a war going on between Rails and merb, what happened?

• There was no war between rails and merb
• We created merb because rails was not fitting us
• We wanted better performance, more choices/ more modularity and a Public API.
• The Rails team now embraces these concepts and want Rails to follow them, so why not work together?

Q: Wait, does that mean that merb is dead?

• Absolutely not!
• merb development won’t stop, we are going to keep on releasing updates until rails 3.0
• clear migration path, and upgrading to rails 3.0 will be as trivial as upgrading from rails 2.x to Rails 3.0

Q: What does the timeline look like?

We just started getting together and discuss the technical details. We are shooting for a release at RailsConf 2009. However it’s hard to estimate this kind of things so again, that’s just an estimate

Q: I just started a merb project, so what now?

I’m sure you had valid reasons to use merb, you needed modularity, performance and a solid API.

Keep on using Merb, we won’t let you down. The good news is that the next version of merb (rails 3.0) will be even awesomer!

Q: What about my client who was looking at using merb for his new project?

If your client is going to be using merb for valid reasons (and not, just because it’s not rails) he should still use merb, but with the full understanding that he/she will end up using Rails in 6 months or so. Again, Rails 3.0 will have what pushed you to use merb.

Q: I’ve been involved with the merb-book, what will happen with this project?

• rails 3.0 won’t get released right away
• still need awesome documentation
• if we look at rails 3.0 as merb 2.0, we can easily imagine how the current work can be extended to the new version.
• rails team will also include an evangelism team which I will be part of, so will be able to focus more on projects like the book.

Q: I’ve been working on a merb plugin, what should I do?

Keep working on it! We’ll assist you with the migration process and the new solid API.

Q: What if I still have questions?

Come talk with me, or any members from the new team. We’ll be open to hear your questions, worries, frustrations.

merb always valued its developers and we will continue to do so but at a bigger scale.

Lori Holden worked on merb_sequel and we should release a 1.0 release of the plugin in a few days.

I’m sure this news comes as a shock for many of you, but try to not see Rails 3.0 as the way Rails is right now. Imagine a version of Rails with true modularity and agnosticism (sequel, DM and AR will still be supported) and the same type of performance as what you get with Merb. In other words, the rails world is about to discover the power of merb!

Here is what Yehuda explicitly says in his blog post:

• Rails will become more modular, starting with a rails-core, and including the ability to opt in or out of specific components. [...]
• We will port all of our performance improvements into Rails. This includes architectural decisions that are big performance wins.[..]
• As of Rails 3, Rails will have a defined public API with a test suite for that API. [..]
• Rails will still ship with the “stack” version as the default (just as Merb does since 1.0), but the goal is to make it easy to do with Rails what people do with Merb today.
• Rails will be modified to more easily support DataMapper or Sequel as first-class ORMs. [..]
• Rails will continue their recent embrace of Rack, which [..] will improve the state of modular, sharable logic between applications.
• In general, we will take a look at features in Merb that are not in Rails (the most obvious example is the more robust router) and find a way to bring them into Rails.

Personal perspective

I’m personally really excited about this opportunity. I had a hard time believing that we could work together but I was proved wrong. We have many challenges in front of us, but watching the two teams working together is very reassuring.

I’m also glad to see that we will have a Rails Evangelism team that I will be part of. I strongly believe that one of the many reasons why merb has been so successful is because we work and listen to our community. We have put a tremendous amount of energy trying to understand what you guys need and what you like and dislike. In return, we saw many people working hard on the wiki and the merb-book.

Can you imagine doing that with almost 4 Million Rails developers?

I’m also looking forward to working with a team and reaching to even more people.

Other news related to the merge:

• The RubyOnRails website will keep a trace of this historical moment: http://rubyonrails.org/merb
• The merb training scheduled for Jan 19-21 in partnership with Integrum will still take place, and if you want to get a head start and learn about the things that will make Rails 3.0 totally kick ass, I’d suggest you join us.

If you have any questions, or if you want me to publicly answer questions on your blog please contact me. I’ll do my best to get back to everyone.

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

History

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.

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'

• V. write some specs against a Client model

• VI. Create the Model

• VII. create a factory

• IIX. run your specs

  

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

• X. run the 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.

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

• RailsConf 08. Great conference, probably my last Rails Conf though. I’ll be in Orlando for Ruby Conf 08 and I’ll focus on 1 or 2 local conferences (probably mountain west and another one).

• MerbCamp 08 in San Diego this Fall organized by SD Ruby. Details are not finalized yet but Yehuda Katz announced it during his Merb talk at RailsConf.

• Moved this blog to a new Joyent accelerator with git support and finally have the possibility to use Ambition! (planning on moving from Mephisto to Feather)

• Launched a client’s Merb app and getting around 3 million hits/day. Merb is just awesome. (more info when the client’s app gets out of beta)

• I’ll join Gregg Pollack from http://railsenvy.com/ during Qcon and take part in the Ruby for the Enterprise track. My talk will focus on Merb usage in real life.

• Renamed my github username, new repo url: http://github.com/mattetti (sorry about that)

Today I was working on cleaning up merb_helper a Merb plugin that brings a lot of the stuff Rails developers are used to. In Merb we aim for speed and try to avoid magic.

merb_plugin didn’t receive a lot of love from the main contributors but few features were added by different contributors and the code became hard to maintain.

Looking at the code I quickly found this bad boy:

(Old Merb Time DSL using metaprogramming)

module MetaTimeDSL

    {:second => 1,
     :minute => 60,
     :hour => 3600,
     :day => [24,:hours],
     :week => [7,:days],
     :month => [30,:days],
     :year => [364.25, :days]}.each do |meth, amount|
      define_method "m_#{meth}" do
        amount = amount.is_a?(Array) ? amount[0].send(amount[1]) : amount
        self * amount
      end
      alias_method "m_#{meth}s".intern, "m_#{meth}"
    end

  end
  Numeric.send :include, MetaTimeDSL

The above code looks awful to me and I decided to rewrite it a way I thought would be more efficient:

 module TimeDSL

    def second
      self * 1
    end
    alias_method :seconds, :second

    def minute
      self * 60
    end
    alias_method :minutes, :minute

    def hour
      self * 3600
    end
    alias_method :hours, :hour

    def day
      self * 86400
    end
    alias_method :days, :day

    def week
      self * 604800
    end
    alias_method :weeks, :week

    def month
      self * 2592000
    end
    alias_method :months, :month

    def year
      self * 31471200
    end
    alias_method :years, :year

  end
  Numeric.send :include, TimeDSL

To make sure I was right, I run the following benchmarks:

require 'benchmark'
TIMES = (ARGV[0] || 100_000).to_i

Benchmark.bmbm do |x|

  x.report("metaprogramming 360.seconds") do
    TIMES.times do
      360.m_seconds
    end
  end

  x.report("no metaprogramming 360.hours") do
    TIMES.times do
      360.seconds
    end
  end

  x.report("metaprogramming 360.minutes") do
    TIMES.times do
      360.m_minutes
    end
  end

  x.report("no metaprogramming 360.minutes") do
    TIMES.times do
      360.minutes
    end
  end

  x.report("metaprogramming 360.hours") do
    TIMES.times do
      360.m_hours
    end
  end

  x.report("no metaprogramming 360.hours") do
    TIMES.times do
      360.hours
    end
  end

  x.report("metaprogramming 360.days") do
    TIMES.times do
      360.m_days
    end
  end

  x.report("no metaprogramming 360.days") do
    TIMES.times do
      360.days
    end
  end

  x.report("metaprogramming 360.weeks") do
    TIMES.times do
      360.m_weeks
    end
  end

  x.report("no metaprogramming 360.weeks") do
    TIMES.times do
      360.weeks
    end
  end

  x.report("metaprogramming 18.months") do
    TIMES.times do
      18.m_months
    end
  end

  x.report("no metaprogramming 18.months") do
    TIMES.times do
      18.months
    end
  end

  x.report("metaprogramming 7.years") do
    TIMES.times do
      7.m_years
    end
  end

  x.report("no metaprogramming 7.years") do
    TIMES.times do
      7.years
    end
  end

end

 Rehearsal ------------------------------------------------------------------
metaprogramming 360.seconds      0.130000   0.000000   0.130000 (  0.133164)
no metaprogramming 360.hours     0.050000   0.000000   0.050000 (  0.042655)
metaprogramming 360.minutes      0.130000   0.000000   0.130000 (  0.133327)
no metaprogramming 360.minutes   0.040000   0.000000   0.040000 (  0.042401)
metaprogramming 360.hours        0.140000   0.000000   0.140000 (  0.134312)
no metaprogramming 360.hours     0.040000   0.000000   0.040000 (  0.043125)
metaprogramming 360.days         0.130000   0.000000   0.130000 (  0.134949)
no metaprogramming 360.days      0.050000   0.000000   0.050000 (  0.043745)
metaprogramming 360.weeks        0.130000   0.000000   0.130000 (  0.135581)
no metaprogramming 360.weeks     0.050000   0.000000   0.050000 (  0.043544)
metaprogramming 18.months        0.130000   0.000000   0.130000 (  0.135234)
no metaprogramming 18.months     0.050000   0.000000   0.050000 (  0.044354)
metaprogramming 7.years          0.140000   0.000000   0.140000 (  0.144062)
no metaprogramming 7.years       0.050000   0.000000   0.050000 (  0.044392)
--------------------------------------------------------- total: 1.260000sec

                                     user     system      total        real
metaprogramming 360.seconds      0.130000   0.000000   0.130000 (  0.132567)
no metaprogramming 360.hours     0.040000   0.000000   0.040000 (  0.042777)
metaprogramming 360.minutes      0.140000   0.000000   0.140000 (  0.132554)
no metaprogramming 360.minutes   0.040000   0.000000   0.040000 (  0.043193)
metaprogramming 360.hours        0.130000   0.000000   0.130000 (  0.133027)
no metaprogramming 360.hours     0.050000   0.000000   0.050000 (  0.042613)
metaprogramming 360.days         0.130000   0.000000   0.130000 (  0.138637)
no metaprogramming 360.days      0.050000   0.000000   0.050000 (  0.043213)
metaprogramming 360.weeks        0.130000   0.000000   0.130000 (  0.134049)
no metaprogramming 360.weeks     0.040000   0.000000   0.040000 (  0.043713)
metaprogramming 18.months        0.140000   0.000000   0.140000 (  0.134941)
no metaprogramming 18.months     0.040000   0.000000   0.040000 (  0.043980)
metaprogramming 7.years          0.150000   0.000000   0.150000 (  0.143389)
no metaprogramming 7.years       0.040000   0.000000   0.040000 (  0.044585)
 0.136591)

The metaprogramming version of the same implementation is almost 3 times slower!

Moral of the story: be careful when using metaprogramming, you might end up slowing down your code considerably.

Merb doesn’t really have a core team per say. It’s actually managed the same way Rubinius is managed meaning that few people such as Ezra, Wycats and Ivey lead the development while many other contributors have commit rights to the different repos.

Patches are handled via GitHub pull Request and LightHouse tickets. Read the following contribution documentation for more info.

Anyway, I’ve been working on a merb-more gem called merb-freezer.

We don’t have a logo for the plugin yet so I picked a “cool” star from the late 80′s to represent.

Vanilla Ice!

Right, so you might wonder what’s the connection between a kitsch white rapper and a new Merb Gem? Not much, apart that they are both cool (or kinda cool).

Let’s forget about “ice ice Baby” and focus on merb-freezer.

merb-freezer has a simple goal: let you “freeze” your application and run it without dependencies.

Why would you want to freeze your app?

(This is only valid for Merb 0.9.3 and 0.9.2 edge as of April 14)

• You might have multiple applications on the same server/slice/cluster. Different applications might require different versions of Merb or some other Merb gems.

• You might work with a team of developers and want everyone to be using the same version of the gems.

• You are using Merb Edge and want to make sure that your coworkers are developing/testing against the same revision.

How to freeze your app?

First thing, in your init.rb file you need to require merb-freezer

require 'merb-freezer'

Now that you required the plugin when you get new rake tasks:

1
2
3
4

  rake freeze:core            # Freeze core from git://github.com/wycats/merb...
  rake freeze:more            # Freeze more from git://github.com/wycats/merb...
  rake freeze:plugins         # Freeze plugins from git://github.com/wycats/m...

The rake freeze tasks use by default git submodules to freeze the various components. That means that you need to have your project under git to use that feature. However, if you didn’t switch to git yet, do no worry, we have a plan B.

When you run the freeze tasks a framework directory is created at the root of the folder and the gems are checked out there.

Not a git user? We thought of you and added an option for you to use rubygems.

1
2

  rake freeze:core MODE=rubygems

When doing that, you are freezing the latest version available on the rubygems server or installed locally.
Note that when using the default mode, you are pulling the latest version of Merb from the official git repo. If you want to do that using rubygems you will need to checkout the git repos locally and install the gems yourself before freezing them.

Also it’s worth noting that you can also do all of that manually, as long as you follow the same conventions you should be fine.

How to use the freezing gems?

If you are a Rails user, you might expect that Merb uses the frozen gems by default, at least that what I expected. Turns out, it’s not the case since Merb avoids too much magic and unless you ask for it, Merb will use the available system gems.

So how to start a frozen merb app? Easy enough:

frozen-merb

That’s it, you can uninstall merb-core from your system and as long as you froze merb-core, you can start your app.

How to update a frozen app?

simply re-freeze but with the UPDATE=true param

1
2

  rake freeze:core UPDATE=true

This option works for in both modes (rubygems and git submodules).

What’s next?

I’d like to add a locking mechanism that would allow you to force your app to only run on specific versions of few gems. The main advantage of this approach is that you wouldn’t need to freeze files in your repo as long as you have the required versions on your machine.

I would also like to extend the freezer to let you use the submodules to freeze other gems.

Other suggestions? Found a bug? Want to submit a patch? Leave me a comment or use the Merb LightHouse ticketing system

If you follow my blog, you already know what Merb is.

I love Rails and I truly believe it has changed web development. At least it has changed the way I do web development.

But Merb looks slick, apparently is way faster than Rails, and has less “fluff” and less magic.

Now that we are getting really close to a Merb 1.0 (scheduled for Rails Conf ’08) it’s time to evaluate if Merb is the good choice for some of my clients’ projects.

However, according to Merb’s author, Ezra, at MountainWest RubyConf 2008, Rails will get you there faster. In a client’s case, they don’t need to build a huge app but need a lot of speed and the ability to easily handle a heavy load right away without using caching. Also most of the traffic will go through an API so we won’t have to manage too many views.

Let’s see how fast Merb really is.

To test Merb’s speed, I built the very same prototype using Merb 0.9.2 and Rails Edge (pre 2.1). Both apps use ActiveRecord and are connected to a UTF8 MySQL database, both apps have exactly the same views. (Note that Merb would run way faster using DataMapper, but I don’t feel that DM 0.9x is production ready yet, also, using a rack handler would certainly be way faster but my goal was really to compare ActionPack vs Merb.)

Both apps use the same ActiveRecord class, their controllers are a bit different but basically do the same thing.

Here is what was tested:

• The Merb/Rails app should receive a GET request with a JSON object in the query.

• The Merb/Rails app should route the request to a controller and pass the JSON object to an AR class.

• The AR class should parse the JSON object (which contains an array of objects), extract each object, and try to find them in the database using one of the attributes. If the object isn’t found, it should be created, otherwise it should return the AR object. The amount of hits should be incremented by 1 and the object should be saved back to the database.

• A simple HTML view should be rendered

Quick Merb benchmark

I setup Merb to run locally on my MacBook 2.16Ghz Core Duo 2, 2Gb Ram. To test the raw performance, Merb is started in production mode.

I then used httperf to make 10000 connections to the server at a rate of 500 (–rate=500 –send-buffer=4096 –recv-buffer=16384 –num-conns=10000 –num-calls=1)

Here are the results:

Maximum connect burst length: 29
Total: connections 4377 requests 4221 replies 2932 test-duration 41.629 s
Connection rate: 105.1 conn/s (9.5 ms/conn, <=1022 concurrent connections)
Connection time [ms]: min 41.0 avg 1920.4 max 35390.8 median 898.5 stddev 4887.3
Connection time [ms]: connect 2118.1
Connection length [replies/conn]: 1.000

Request rate: 101.4 req/s (9.9 ms/req)
Request size [B]: 321.0

*Reply rate [replies/s]: min 0.0 avg 73.3 max 143.0 stddev 65.8 (8 samples)*
Reply time [ms]: response 809.0 transfer 18.1
Reply size [B]: header 121.0 content 557.0 footer 0.0 (total 678.0)
*Reply status: 1xx=0 2xx=2932 3xx=0 4xx=0 5xx=0*

CPU time [s]: user 0.35 system 36.54 (user 0.8% system 87.8% total 88.6%)
Net I/O: 78.4 KB/s (0.6*10^6 bps)

Errors: total 7068 client-timo 0 socket-timo 0 connrefused 0 connreset 1445
Errors: fd-unavail 5623 addrunavail 0 ftab-full 0 other 0

What we care about is the reply rate/s. We have an average of 73.3 requests per second with a standard deviation of 65.8 using 8 samples.

We also make sure that all the replies were successful. (status == 2xx)

I also checked the database, made sure my AR object was created and that the hits were increased. AR object hits: 2932, which matches the amount of replies reported by httperf.

We don’t care so much about the rest of the httperf. Let’s move on to the Rails benchmark.

Quick Rails benchmark

Rails is set the same way, running locally in production mode, same httperf settings.

Here are the results:

Maximum connect burst length: 44

Total: connections 2923 requests 2825 replies 1672 test-duration 37.418 s

Connection rate: 78.1 conn/s (12.8 ms/conn, <=1022 concurrent connections)
Connection time [ms]: min 382.7 avg 5635.4 max 36384.5 median 1887.5 stddev 10103.1
Connection time [ms]: connect 3631.2
Connection length [replies/conn]: 1.000

Request rate: 75.5 req/s (13.2 ms/req)
Request size [B]: 319.0

*Reply rate [replies/s]: min 0.0 avg 43.4 max 75.2 stddev 30.8 (7 samples)*
Reply time [ms]: response 1568.1 transfer 36.7
Reply size [B]: header 471.0 content 581.0 footer 0.0 (total 1052.0)
*Reply status: 1xx=0 2xx=1672 3xx=0 4xx=0 5xx=0*

CPU time [s]: user 0.25 system 31.31 (user 0.7% system 83.7% total 84.4%)
Net I/O: 69.4 KB/s (0.6*10^6 bps)

DB hits: 1672

First thing, the database object was created properly and the hits incremented to 1672 which matches the amount of replies reported by httperf.

Then, we notice that on this test, we only got 7 samples, that’s more than enough though. The standard deviation is 30.8 which is better than Merb’s 65.8. That means that in our benchmarks, the reply speed difference in Merb’s requests was bigger than Rails’. Not a big deal, this is not a scientific test but it’s good to acknowledge it.

What we really care about is the average reply rate: 43.4

Let’s also note that all the replies had a 2xx status, so everything went well.

Results

Based on this really basic benchmark, my Merb app had an average reply rate of 73.3 requests per second against Rails’ 43.4 requests per second.

That means that in this very specific case,

Merb is 69% faster than Rails! Sexy!

In other words, my Merb prototype could handle 69% more requests than the Rails prototype in the same amount of time.

I heard people reporting than Merb was 3 to 5 times faster than Rails. Honestly, it really depends on what you do. By using ActiveRecord on both prototypes, I limited the speed difference since AR is not multithread and therefore Merb can’t run as fast as it would using Sequel or DataMapper. By actually hitting the database on every single request, I also made sure to really compare ActionPack vs Merb.

Conclusion

The conclusion is simple, I recommended that my client go with Merb. Merb 1.0 is almost ready, the public API has been frozen. My client needs speed and simplicity. Using Merb I get exactly what I need and nothing more. Actually, we’ll probably increase the performance by writing a rack handler and bypassing the entire framework for API calls (that should be wicked fast!). Also, as soon as DataMapper becomes production ready, we’ll switch to DM and should get way better performance!

Am I suggesting to give up Rails and switch to Merb?
Absolutely not! First off, Merb is a “lower level” framework. It requires a deeper understanding of Web Development in general and being more than just ‘acquainted’ with the Ruby language. So, unless you are an advanced developer or have time to learn, I would suggest to keep on using Rails (start using Merb on personal projects, it’s a perfect way of learning).
If you have a lot of views and/or use loads of AJAX, RJS, built-in helpers, you probably want to stick to Rails and start looking at how you can do all of that from scratch. By default Rails uses nasty helpers that create inline javascript, and is something you really want to avoid. RJS is fun, but it goes against Merb’s philosophy, so you need to make sure you can live without it (note that you can reproduce the same behavior in Merb rendering JS, it just requries more work). If you rely a lot of Rails plugins, you might want to delay your switch, Merb is pretty new and doesn’t have a mass-load of plugins yet.

Finally, Merb doesn’t have a lot of documentation and changed a lot when 0.9 got released. To understand how Merb works, you will need to go through the source code, specs, Google, and ask on the Merb IRC channel.

It turns out that in our case we have experienced developers, a great need for speed, not too many views and are following Merb’s development really closely . I honestly think it’s the best choice for my client and I’m excited they accepted to use Merb.

Merb is addressing different issues than Rails and doing it well. I think there is a bright future for Merb. And don’t even think that Rails is going away, that won’t happen anytime soon!

Recently, Sony Playstation even posted a job post looking for a Rails/Merb developer. This is very promising for the Merb community!

I the previous post I covered few useful tips for Merb 0.9. The good news is that Merb should get its wiki setup over the week end!

Here is another batch of hopefully useful tips:

• In init.rb, you can define a dependency and specify a version number: dependency “merb_fu”, “>= 1.0″

• If you want to run your application from a subdirectory, once again, in your init.rb file, add: c[:path_prefix] = “/your_prefix” (note, that you can also do that in a specific environment file.)

• You feel like limiting a route to a specific request such as a DELETE? In your router.rb file add the following:

1
2

  r.match("/:bucket_id", :method => :delete).to(:controller => "buckets", :action => "destroy")

• Since we are talking about routes, what about an iPhone only route?

1
2

  r.match(%r[^/(.+)], :user_agent => /iPhone/).to(:controller => "mobile", :title => "Welcome Apple FanBoy", :action => "show")

• what about an admin section for my blogposts?

1
2
3
4

  r.match('/admin') do |admin|
    admin.resources :blogposts
  end

• To finish with the routes, look at the following merb-core spec

1
2
3
4
5
6
7
8
9

  it "should allow you to restrict routes based on protocol" do
    Merb::Router.prepare do |r|
      r.match(:protocol => "http://").to(:controller => "foo", :action => "bar")
      r.default_routes
    end
    route_to("/foo/bar").should have_route(:controller => "foo", :action => "bar")
    route_to("/boo/hoo", :protocol => "https://").should have_route(:controller => "boo", :action => "hoo")
  end

You can set custom routes to only work when connected via SSL, that’s just really nice!

• Other quick tip. Last time we saw how to install locally all the required gems. Well, you can also freeze merb by doing:

1
2

  merb-gen frozen-merb

• Another common IRC question, how do I use Merb’s logger. It’s really easy:

1
2

  Merb.logger.info('our stuff')

Where info is the debugging level you want to send your message to.

• Finally, today in IRC a Rails user asked how reset a session in Merb. Rails has a reset_session method that resets the session by clearing out all the objects stored within and initializing a new session object. Merb simply uses a hash to store sessions, so session.clear will do it

Feel free to add a comment with your Merb tips or leave a question regarding something you can’t seem to be able to do with Merb.

I’m working on a post reporting a recent benchmark I did comparing Rails vs Merb performances for a client’s app.

In the meantime, here are few tricks you might need when using Merb 0.9x

1. In the init.rb file, uncomment and rename c[:session_id_key] (in the Merb::Config.use block)

2. In the same block, add c[:log_level] = :debug to set a log level

3. By default, Merb logs to STDOUT, to log to a file, in the config block add c[:log_file] = Merb.log_path + ‘/development.log’ (note that you need to create the file yourself, Merb won’t do that)

4. to save your gems locally, do: sudo gem install gem_name -i gems

5. need basic HTTP auth? it’s now available in core

6. don’t forget to require any plugins, extra gems you need (such as merb_helpers or merb-assets)

7. don’t forget to select your ORM before using the generator( so your generated goodies will be adapted to your ORM)

8. routes are easy to use. In the console (merb -i) type merb.show_routes to see all your named routes

9. if you want to use linkto, install merbassets

10. nested routes example:

1
2
3
4
5
6

  r.resources :channels do |channels|
    channels.resources :shows do |shows|
     shows.resources :episodes
    end
   end

usage:

1
2
3
4

  url(:channel_shows, :channel_id => channel)

  link_to h(channel.description), url(:channel, :id => channel)

That’s it for today

In the meantime, check this Merb presentation by Ezra and this DataMapper presentation by Wycats