Obie Fernandez

Adding a Counter Cache to Existing Records

Adding a counter cache to a has_many/belongs_to ActiveRecord relationship after the underlying records have been around awhile is one of those tasks that tends to trip up Rails newbies.

Here's an example migration showing the necessary steps.

1. Add the counter_cache column as an integer. (If following normal rails convention, name the column with the plural name of the has_many association followed by _count)
2. Make sure that the column is set to disallow null values and defaults to 0.
3. Reset the counters for existing records. The reset_counters method is not smart enough to take an array of ids, so you have to call it for each record you want updated.

class AddCommentsCountToNominations < ActiveRecord::Migration
  def self.up
    add_column :nominations, :comments_count, :integer, null:false, default: 0
    # reset cached counts for nominations with comments only
    ids = Set.new
    Comment.all.each {|c| ids << c.nomination_id}
    ids.each do |nomination_id|
      Nomination.reset_counters(nomination_id, :comments)
    end
  end
  def self.down
    remove_column :nominations, :comments_count
  end
end

The :counter_cache option is covered in detail on pages 195-196 of my book The Rails 3 Way, including some interesting gotchas.

Rendering Collections of Heterogeneous Objects in Rails

AKA the "Activity Stream Problem"

This is not meant to be a comprehensive post on the subject. (However, I plan to cover this topic extensively in my next book.) For now, I simply want to point out a hack that may alleviate some of the pain experienced when trying to use Rails' ability to render heterogeneous collections of objects by auto-magically determing which partial template to use.

Let's say you're trying to implement an activity stream, such as in the following screenshot (from my new startup RightBonus). If you look closely you'll notice that there are three different types of events portrayed. There's the core award nomination event at the top, but also an event logging Johanna's new profile picture and the join/starter pack event at the bottom.

 
I've chosen to implement my activity stream as a collection of event objects, all derived from a STI base Event class. Eventually I might transition to a more complex implementation involving message queues for scaling reasons, but for now one of the nicest aspects of doing it this way is how clean the view code can be. The company's dashboard view has something along the lines of (in HAML):

%ul.events
  = render company.events

The events method is an association which returns an assortment of different subclass types depending on the kind of event logged. There are a couple of problems with this approach and Rails' standard behavior:

1) The auto-magically determined partial paths suck.

NominationEvent.model_name.partial_path => "nomination_events/nomination_event"
ChangedProfileImageEvent.model_name.partial_path => "changed_profile_image_events/changed_profile_image_event" 

Ugh! Ugly and long. And every event partial would need its own subdirectory, for no good reason.

2) The partial rendering code prepends view.controller_path to the partial path, which means that this approach will not work cleanly across namespaces.

The best solution would be to make the Rails code that determines partial names smarter. If someone wants to help me determine what that might look like I'm happy to collaborate on a proposed patch.

Until then, what I've done is to monkey-patch ActionView::Partials::PartialRenderer in an initializer so that it does my bidding when I give it event objects. Evil? Certainly on some levels, but after going on 6+ years of programming in Ruby open classes is still one of the reasons that I love her so much.

Rending Collections of Heterogeneous Objects in Rails

AKA the "Activity Stream Problem"

This is not meant to be a comprehensive post on the subject. (However, I plan to cover this topic extensively in my next book.) For now, I simply want to point out a hack that may alleviate some of the pain experienced when trying to use Rails' ability to render heterogeneous collections of objects by auto-magically determing which partial template to use.

Let's say you're trying to implement an activity stream, such as in the following screenshot (from my new startup RightBonus). If you look closely you'll notice that there are three different types of events portrayed. There's the core award nomination event at the top, but also an event logging Johanna's new profile picture and the join/starter pack event at the bottom.

 
I've chosen to implement my activity stream as a collection of event objects, all derived from a STI base Event class. Eventually I might transition to a more complex implementation involving message queues for scaling reasons, but for now one of the nicest aspects of doing it this way is how clean the view code can be. The company's dashboard view has something along the lines of (in HAML):

%ul.events
  = render company.events

The events method is an association which returns an assortment of different subclass types depending on the kind of event logged. There are a couple of problems with this approach and Rails' standard behavior:

1) The auto-magically determined partial paths suck.

NominationEvent.model_name.partial_path => "nomination_events/nomination_event"
ChangedProfileImageEvent.model_name.partial_path => "changed_profile_image_events/changed_profile_image_event" 

Ugh! Ugly and long. And every event partial would need its own subdirectory, for no good reason.

2) The partial rendering code prepends view.controller_path to the partial path, which means that this approach will not work cleanly across namespaces.

The best solution would be to make the Rails code that determines partial names smarter. If someone wants to help me determine what that might look like I'm happy to collaborate on a proposed patch.

Until then, what I've done is to monkey-patch ActionView::Partials::PartialRenderer in an initializer so that it does my bidding when I give it event objects. Evil? Certainly on some levels, but after going on 6+ years of programming in Ruby open classes is still one of the reasons that I love her so much.

See the patch as a Gist

Hey Web Startups, Hire Consulting Firms On The Cheap!

So you're an entrepreneur and you're doing a lean web startup using Ruby on Rails. You're teaching yourself Rails and proud of yourself for going at it alone and not spending a bundle of cash. You know that you can't afford to hire a world-class shop like Hashrocket, Thoughtbot or Pivotal Labs to work on your project, because the minimum project budgets they are interested in are in the six figures.

Incidentally, this post is strictly my personal opinion is in no way endorsed by or representative of anyone at Hashrocket, ThoughtBot or Pivotal.

Well, allow me to let you in on a little secret. You can absolutely work with those firms and maximize the benefit provided to you for as low as a couple thousand dollars. Just not in the way that you might think. And it won't be the way that they would prefer to work with you, but they'll still do it.

See the jars above? Consider the container to be the size of the available billable hours in a month. The large rocks and pebbles are current projects. It is impossible to fully utilize the space available unless you start adding smaller rocks and pebbles and eventually, grains of sand. Even the busiest consulting shops always have small amounts of utilization available. It's the slack in the system, time for people to relax, the empty volume of the jars. Despite the importance of slack, the profits of a consultancy live and die by utilization. When I was in charge of Hashrocket, which was generally busy, do you think I stressed about utilization? Yes I did. Every fucking week of the year. It's one of the reasons I got out of the consulting business. Will most consultancies take advantage of opportunities to bump up their utilization with profitable small work? Yes! The trick is how to make them do it, even if they resist at first.

Before I describe that trick, let me explain the backstory that provoked this post: Last night I got to know a couple of young entrepreneurs from NYC, Chris and Philip. They are working on an interesting little web startup named Meeteor. It's technology driven. During a conversation about testing, Philip told me that he spends a couple hours manually testing the app everytime they're ready to do a deploy. They don't do any automated testing, because they don't have the time to figure out how to do it well. My ex-ThoughtWorks friend Kurt Schrader was present and we did the requisite head shaking and tsk-tsk-ing about their failure to test their code. But the truth is, if I were in these guy's shoes I would probably do the same thing. It takes years to get really good at TDD and integration testing to the point where it doesn't slow down your progress tremendously. Sure, without tests you'll build up technical debt to the ceiling and the whole project may eventually collapse under its craptastic weight, but in the meantime the perceived slowness of figuring out how to test your stuff will demoralize and destroy your productivity. It's a no-win situation for newbies.

My advice to the Meeteor guys (and to all of you in similar situations) is the secret alluded to above: Hire help from Hashrocket (or any other competent firm) but only for a day or two at most. And I'm going to tell you exactly how to do that:

1. Call the shop up and get a decision maker on the phone. Convey that you know exactly why you're calling them and what you need.
2. Request their top Rails (and/or testing) expert for 1 day. State right off the bat that you're willing to pay their full hourly rate for those 8 hours. If you can travel to where that person is then state that you're willing to do so. Otherwise offer to pay for reasonable travel expenses to get the expert on site with you for a day.*
3. Be insistent and don't lowball them on the price. Even if they want a substantial markup on their normal rates it will still be worth it. Be prepared to have to wait a few weeks for that person to be able to take a day off from their current project. Be prepared to wire half the money up front as a deposit or even pay in full upfront.
4. Make sure the contracting goes as smoothly as possible. Do not involve your lawyer in the paperwork or negotiate on price. Do not keep anyone on the phone for a long time answering questions. Anything that makes the sale time-consuming to close (read: expensive to handle) will make the whole gig unprofitable and they will rightly tell you to get lost.
5. Once you are working with your expert, sit as a pair at the computer with them but make them drive the entire 8 hours. Do not touch the keyboard at all. Your aim will be to get the expert to tackle as many sticky problems as possible in 8 hours. Dedicate the first hour to making them set your development environment up properly, because it the way you have it right now sucks. Don't let them try to teach you VIM if you use TextMate, like don't even spend 5 seconds on that, but let them use whatever they normally use. Do not do any storycarding or get any consulting about your consulting process whatsoever. Remember that you're not there to learn directly from your expert. What you are there for is to direct the work, answer questions about the domain and keep your expert focused and productive for the duration of the 8 hours. That includes getting coffee, snacks, cigarettes, whatever. You are there to get them to do as much work on your app as possible and you will learn later on from analyzing their work.

* Right now (Mar '11) a total budget of $3k is probably very reasonable for what I'm describing.

In the case of my friends at Meeteor, they'd want their expert to implement some cross-browser selenium integration test cases. All they need is one of their most difficult ones, because once they have the scheme setup and one or two examples to draw from, they're smart enough to figure out the rest themselves.

Remember that the point of this technique is to buy as much great coding as possible in a day or two. Then you can use the results for inspiration for your own hacking. This technique works with any superstar programmer whether they are coming from a shop like Hashrocket or not. Shop refuses to work with you? Hire one of their guys for a single-day side gig! In Europe and using Mongo? Throw a couple thousand at my friend Durran to pair with you for a day. You get the idea. Just make sure that the person you hire works full-time as a programmer every day. This scheme wouldn't work with someone like me; I have plenty of depth, but slow velocity since it's not what I'm doing everyday.

The productivity boost you can get as a newbie developer from working a true expert for just a day (or two) is exponentially more valuable than what it will cost you in cash.

Rails Up-and-Comers Contest Winners

Wow, did you all make it hard for me to choose winners! Over 60 entrants and almost everyone had a compelling story to share. I think the best thing about it all is seeing proof of the wonderful diversity and vibrance of our community. Everyone who entered is going to get a small token of appreciation from my publisher and I will announce that as soon as I get final confirmation. UPDATE: All contestants will receive complimentary access to the RoughCut of Russ Olsen's upcoming Eloquent Ruby title on Safari.

But without further ado, here are the winners:

Grand Prize

Jacob Richardson, a 19 year old developer from Des Moines, Iowa wins the top prize for his story about a successful project he started in high school and how he teaches Rails to high school students.

"About midway through the year Rails was so appealing to me that I decided to completely scratch the whole Skloop PHP product and rewrite it in Rails. This was a HUGE success! I was able to easily implement a group system that piggybacked on Twitter to use it as a delivery system. With our new system it allowed all students in the school to register for our product (via a web frontend) and allowed them to easily join teacher created groups to receive announcements and events.

Skloop is being heavily used in the high school today and is being hosted locally at the school. The product ended up being so useful that the school today, whenever the school is canceled due to weather or other events, will post the school closing on Skloop before ANY phone calls are made to anybody. Skloop was also presented at the Prometheus Awards to recognize outstanding contributions to technology in Iowa.

My contributions to Skloop, although I have graduated, have not ceased. Every week as a volunteer I will come to the club and teach the students about Ruby on Rails and how to improve the current Skloop product. I'm trying to become a better teacher and Rails expert so that I can impact these student's lives as much as I can to help them get their feet in the water. "

First Runner-up Prizes (2)

Josh Van Cleef was dealing with unemployment issues:

"Unfortunately, I was resoundingly unsuccessful at that and moved quickly down the scale from “self-employed” to “unemployed.” In the two years since then, I’ve applied for all manner of jobs, even crappy theme park jobs, with zero luck. I’ve tried my hand at some freelance sports writing (ok, blogging mainly), which did get me a press pass to a college bowl game, but no actual money.

Meanwhile, a good friend left his corporate job about the same time and started freelance web development in Rails. After about a year & a half of unemployment, it finally dawned on me to bug him about what he’s up to. He put me onto tryruby, and the rest is almost history."

Brandon Cordell has been a little overwhelmed at times:

Being new to Rails now that it's grown so big, is like being in the middle of a cave at night with 10,000 path surrounding you. It seems like everywhere you go in the Rails universe there are 5 different camps of people saying 5 different things, and they all claim they're right. Not that it's entirely a bad thing since it helps drive innovation, but as a newcomer it's easy to just run back to where you came from and vow to learn it later.

Second Runner Up Prizes (10)

The following entrants win a copy of the Ruby on Rails 3 Tutorial book.

• Adrian Pomilio needed a break after lots of troubles.
• Imre Mehesz 
• Adil Muhammad found Rails after being impressed by 37signals in Saudi Arabia.
• Oliver Dodd
• Jason Carpenter is the oldest guy in the office and also an intern.
• Arun Srini
• Michael Haddox-Schatz
• John Glass considers The Rails 3 Way to be the Kama Sutra of programming.
• Dale Hamill
• Roy Osherove quit his job as a CTO for a .NET startup to become an intern in a Ruby Shop.

Honorable Mentions

Even though they won't receive a book hard copy, I'm going to do my best to send the following entrants a special something for their great stories. (Wish I had more books to distribute!)

• Tony Wok
• Christian Mutesa
• Juan Capistran
• Samnang Chhun
• Nithin Bekal
• Michaël Sokol
• Ashish Dixit
• Axel Graff
• Dan Carper
• Daniel Lopes
• Neal Sales-Griffin
• Brian Pearce
• Jeffry Degrande
• Eduardo Mourao

If you're one of the winners, please keep an eye on your email this week for details on how to receive your prize. Thanks again to everyone who participated.

The Rails Up-And-Comers Contest

As the Series Editor of the Professional Ruby Series by Addison-Wesley, I am pleased to announce a contest specially for Rails up-and-comers. The idea is to support folks that are working hard towards entering the Rails job market, which as you might know, is currently suffering from severe talent shortages!

UPDATE: Thanks to a generous donation by Chad Fowler, his essential title: The Passionate Programmer: Creating a Remarkable Career in Software Development will be awarded to the top three winners!

The Fabulous Prize Packs

One (1) grand prize winner will receive the full stack of Pro Ruby Series books (pictured above), worth over $250, plus The Passionate Programmer:

• Ruby on Rails 3 Tutorial: Learn Rails by Example
• Rails 3 Way, The (2nd Edition)
• Rails AntiPatterns: Best Practice Ruby on Rails Refactoring
• Service-Oriented Design with Ruby and Rails
• Distributed Programming with Ruby
• The Merb Way
• The Passionate Programmer: Creating a Remarkable Career in Software Development

Two (2) first runner-up prize packs will be awarded, consisting of:

• Ruby on Rails 3 Tutorial: Learn Rails by Example
• Rails 3 Way, The (2nd Edition)
• Rails AntiPatterns: Best Practice Ruby on Rails Refactoring
• The Passionate Programmer: Creating a Remarkable Career in Software Development

Ten (10) second runner-up winners will receive a free copy of the Ruby on Rails 3 Tutorial book.

Contest Entry

I love hearing personal stories, especially from people that are working hard to succeed. The first and main part of your entry submission to the contest is the story of how you're working to succeed as a "Rails up-and-comer." Tell us who you are, where you come from and what you're about. Tell us why you picked Ruby and Rails over a myriad of other options and why you think you'll succeed. You may enter your story directly as a comment here or link to an entry on your own blog or elsewhere on the web.

The second part of the entry is based on what some people call an "honors system"; it's a promise that you'll write an honest Amazon review for at least one of the books (if you win). This point of this contest is most definitely not about drumming up reviews, but I figure that it is a good opportunity to get some so it'd be dumb to pass it up.

Deadline / Dates

You have until midnight EST on Sunday, January 23rd to enter your submission. I'll announce the winners sometime late on Monday, January 24th.

Judging

I'll be the sole judge of this contest and will rank the competitors subjectively at my discretion based on how much I like their story. I don't expect nor want a full biography, but if you're going to enter please do make it compelling reading. Hint: focus on obstacles overcome and aspects of your story that are unique to your personal context.

GOOD LUCK -- I can't wait to read your stories!

The Fine Print

I will announce the winners via an update to this blog post. This is not an official Addison-Wesley contest. The books I'm awarding are from my personal Series Editor stash and I'm paying for shipping the prizes myself, from my own personal funds. You should enter the contest from outside the USA only if you are willing and able to PayPal me the additional cost of shipping books to you if you win. (The cost in excess of 10USD). Obviously I don't know where you are so I have no idea what it will cost beforehand. Please don't email me asking for an estimate of shipping costs. I'll work on getting something of value for all contestants that don't win an official prize, but no promises until I see how many contestants participate.

What Is the Rails Way (To You)?

Back in 2007 as I was finishing the first edition of The Rails Way, I asked you to send me your thoughts on the meaning of the "rails way." I incorporated most of your responses into the book's Afterword, introducing it with the following paragraph:

I love the Ruby community. It’s vibrant, witty, and smart. Truly, our community is one of the best aspects of working with Rails and no small part of its success. As I was nearing completion of this book, I felt a strong urge to include the community in whatever way possible, to give readers a taste of what it’s like, and then it hit me. We all know that there is a Rails way, and yet it is an intensely personal experience, subject to interpretation and joyful exposition. What better way to end the book than with a collection of your thoughts!

Well, it's that time again. The Rails 3 Way is almost finished and I'd like to update the Afterword with new content culled from a much larger and diverse generation of Rails fanatics. Send me your thoughts, poetry, quips... whatever gets the idea across:

What Is the Rails Way (To You)?

Please make sure to get your submission in before July 31 to ensure consideration for the new edition. Thanks!

The Rails 3 Way Highlights: ActiveSupport's Class.class_attribute

As I'm wrapping up work on The Rails 3 Way, I'm coming across little nuggets of interesting content suitable for blogging. Time permitting, I'll publish them here over the course of the next few months.

---

In this case, I cover a new ActiveSupport core extension to Ruby's Class object. It allows creation of class-level attributes in a simple and powerful manner that I think is a lot clearer than the mess of cattr_ and class_inheritable_ methods that precede it.

class_attribute(*attrs)

The class_attribute method declaratively defines one or more class-level attributes whose value is inheritable and overwritable by subclasses and instances, like so:

class Base
  class_attribute :setting
end

class Subclass < Base
end

>> Base.setting = "foo"
=> "foo"

>> Subclass.setting
=> "foo"

>> Subclass.setting = "bar"
=> "bar"

>> Subclass.setting
=> "bar"

>> Base.setting
=> "foo"

This behavior matches normal Ruby method inheritance: think of writing an attribute on a subclass as overriding the parent's reader method. Instances may overwrite the class value in the same way. (Note that the following code samples create anonymous classes to illustrate usage in a more concise fashion.)

klass = Class.new { class_attribute :setting }
object = klass.new

>> klass.setting = "foo
=> "foo"

>> object.setting = "bar"
=> "bar"

>> klass.setting
=> "foo"

To opt out of the instance writer method, pass :instance_writer => false.

klass = Class.new { class_attribute :setting, :instance_writer => false }

>> klass.new.setting
=> NoMethodError

The class_attribute method also works with singleton classes, as can be seen in the following example.

klass = Class.new { class_attribute :setting }

>> klass.singleton_class.setting = "foo"
=> "foo"

For convenience, a query method is defined as well, which allows you to see if an attribute has been set on a particular class instance. 

klass = Class.new { class_attribute :setting }

>> klass.setting?
=> false

>> klass.setting = "foo"
=> "foo"

>> klass.setting?
=> true

My Reasoned Response about Scala at Twitter

I'm glad that Twitter is working to resolve its scaling issues. It's a service that I love and use on a daily basis and from which I have benefitted immensely. As far as I'm concerned, Twitter is a case-study in how Ruby on Rails does scale, even in their hands. Also, I know Alex Payne in person. Not very well, but enough that if I was in San Francisco and sat down to share a beer and discuss the Ruby/Scala debate, I imagine that it would be a fairly civil conversation.

My interest in the question of Ruby vs. Scala at Twitter had mostly consisted of curiosity and amusement, at least until last night. First I had an exchange of tweets with Alex which raised my warning levels, and second Alex wasted no time in creating for himself a virtual nintendo invincibility star for himself with this blog post: Mending The Bitter Absence of Reasoned Technical Discussion.

Who can disagree with the need for more reasoned technical discussion? Nobody, but frankly the timing of his essay made me throw up a little in my mouth. The nausea only grew this morning when I checked on how much it's being re-tweeted. Even though Alex's star is probably going to take a little while to wear off, here are some of the facts of this "debate" for your consideration and historical record:

First of all, my exchange with Alex last night, which I triggered by re-tweeting Jeremy McAnally:

RT @jm: If you have to use kind_of? all over your code to mimick a "type system," you're doing it wrong. (I had exactly the same thought!!!)

To which Alex responded:

@obie Indeed, using kind_of? in that way is "doing it wrong" in Ruby. But as our codebase grew, it became a necessity to combat bugs.

Hmm... A "necessity to combat bugs". What bugs, exactly? Bugs in Ruby or bugs in Twitter's codebase? Non-deterministic bugs? At this point I wasn't angry or anything, just curious and a little bit suspicious. So I asked:

@al3x Doesn't make sense. Do you mean non-deterministic bugs? An in-depth explanation of the bugs you're talking about would be enlightening

To which Alex quickly replied:

@obie Yes, I mean non-deterministic bugs in the giant, legacy, spaghetti parts of our system. Unexpected objects flying around.

Ah, suspicions confirmed. Alex is indeed scapegoating Ruby for Twitter's shitty legacy codebase and the mistakes that they made during what is unarguably a very steep growth curve that would have challenged even the most brilliant team of developers. But don't take my word for it, here are some direct quotes from Alex himself in the recent Artima interview:

Twitter continues today to be primarily a Rails application, with a bunch of Ruby daemons doing asynchronous processing on the backend.
Over time we found that although Rails works great for doing front-end web development, for doing heavy weight back-end processing, Rails had some performance limitations at runtime. And I think that—and this is more my personal opinion—the Ruby language lacks some things that contribute to reliable, high performance code, which is something we’re very interested in as we’re growing as a business. We want the code we write to be correct and maintainable. We want to keep our costs down—all the things most businesses want out of their stack. So that’s why we started looking at Scala.

Most damning:

I’d definitely want to hammer home what Steve said about typing. As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now.

Adding fuel to the fire, Alex seems to have created quite a negative impression about Ruby and Rails with his recent Web 2.0 talk in which he advocated usage of Scala. Tell me the impression you get from coverage of his talk in articles such as this one in MIT's Technology Review, which makes the following incendiary assertions:

The company is leaving behind a programming language that has caused it much pain in the past, and instead embracing a new and somewhat obscure language called Scala.

[...]

Right now Twitter's service is a hybrid of programming languages, Payne says. The user interface runs on Ruby on Rails, which is "fine for people clicking around Web pages," he says. But by the end of the year, Twitter hopes to have a set of services in the back end that are written entirely in Scala. And it's the company's plan to make sure that all the third-party services that connect to Twitter via the application programming interface (API) go through Scala code, bypassing Ruby on Rails completely. "When you're talking about a bunch of programs hitting the API rapidly," Payne says, "We found we can better optimize things...using Scala."

Did you actually say "fine for people clicking around Web pages", Alex? Maybe that Technology Review article is just sloppy journalism, a subject that Alex himself lamented not too long ago. But I don't think that's the case. I think that Alex is slyly pushing his Scala agenda forward, yet acting surprised when Ruby folks call him out for it.

What agenda? His agenda as an advocate of Scala and author O'Reilly's Programming Scala book. He said so himself in Recession Engineering:

I’m first to admit that I have something of an agenda with this prediction. I spend a fair bit of my time working with and writing about the Scala programming language, which provides the expressiveness and flexibility of dynamic and functional languages like Ruby, Python, and Lisp with the performance of C++ or Java. - Alex Payne

Have I been guilty of this stuff in my own past as a Rails advocate with a strong agenda? Yeah, probably so. Which is why I know it when I see it. :)

RMM Behind the Scenes

Rails Maturity Model (Behind the Scenes) from Hashrocket on Vimeo.

Take sneak peak at what Hashrocket is cooking up based on the ideas for RMM (Rails Maturity Model). It's not about certification, rather it's about having an objective and neutral way of tracking the behaviors that Rails shops consider their best practices and having those vouched for and endorsed by the community at large. We don't think this implementation controversial at all, but here's your chance to decide for yourself.