Obie Fernandez

The Rails Dilemma

This is a guest post by Rusty Zarse CTO of Search Discovery, spurred by a series of email conversations that we had regarding the difficulty of finding experienced Rails talent. Rusty leads the Atlanta iOS Developers meetup and is one of the better known technologists in our city.

Where'd Every RoR Go?

“Rails is hot,” ain’t no headline today. Five years ago, Ruby on Rails was an underdog, the somebody to watch, the next big thing. It's not news that the Rails community continues evolving and growing while its members do a good job protecting the integrity and quality of the platform. Rails 4 is visible on the horizon and looks better than ever. The growth of the Rails community worldwide appears to be relentless, but there's a dark underside to that growth that does not get enough attention: In terms of sheer numbers, there just doesn't appear to be enough Rails developers to properly serve the needs of the market.

Technical organizations (particularly at the CTO and Director level that I inhabit) are now faced with a stark decision of choosing the Rails platform on its virtues or reluctantly giving the nod to another technology that carries less staffing risk.

On the face of it, people might think that this situation is good for Rails developers because it means that they continue commanding astronomical billable rates, higher quality coding practices and standards for their professional ecosystem and the aura of elite superstars. But Rails remains a community-driven platform and so it's up to the community itself to identify the needs of the market and identify what can be done for our overall growth to continue to flourish.

Attracting Rails Talent

Our core product at SearchDiscovery does things that truly push the envelope. There's a lot of work remaining to be done, but we feel that it already does what nothing else in the world can do. We owe a lot to the exceptional genius of our Hashrocket team and the wizardry of the lead developer they provided to us. During my career I've led many projects and never seen a product reach this level of complexity without falling apart due to compromises and shortcuts made along the way. I attribute our success in no small part to the principles and practices that Rails embodies. It is the motivation that I had for choosing Ruby on Rails as our web development platform to begin with and continues to provide a level of quality and productivity that I believe is unmatchable.

Our dilemma is that in over 3 months of arduous searching, we have not been able to find even a single Rubyist in Atlanta interested in joining our team. I'm not talking about having to turn down interested applicants; I'm talking about not having any interested applicants to begin with.

Now we have new products in the pipeline and our CEO is pushing to choose an alternative platform. Some of us know PHP and I personally know .NET. My experience with PHP is that its a great hacky tool to tweak wordpress and everything else just becomes spaghetti soup. Microsoft .NET is the platform of choice for developers who like to write the same oil tanker full of plumbing code over and over again just to show how great they are at doing things "better" than everyone else. Here in Atlanta, a common alternative to Rails is .NET, given the large Microsoft contingent we have in town. In my opinion, .NET doesn't deliver quickly enough and PHP inevitably becomes a maintenance nightmare.

Why on earth would we consider switching off Rails? The painful truth is that we need a team of professionals more than we need the best technology. We don't even need to hire an entire army of engineers immediately. We're specifically looking to fill at least one senior position so that this individual can cultivate Ruby on Rails talent within our walls. Our long-term goal is to become that company everyone in Atlanta wants to work at. We admire companies who posses an organic energy and self-managed excellence within their development team and we're willing to invest the capital needed to get there. I feel  that we have the professional atmosphere and culture that would be attractive to Rails professionals, but where are they?

Rails in Atlanta

Obviously, timing is everything. I've tapped the local user group community and will continue to do so, but so far have not seen much interest in the position. When I do connect with a local Atlanta Rails expert, often the professional courteousness is not reciprocated. I don't want to complain about specific people, but c'mon it just isn't necessary to be rude when someone asks if you are available. Clearly I'm trying to recruit someone, but I'm a CTO not a recruiter. Is politeness too much to ask for? Most technical people in Atlanta are nice and as helpful but there are a handful of dudes with serious reputations that apparently forget that we're all in this together. Their dismissive attitudes are toxic to non programmers who just want to run a business.

Worse, these bad attitudes get back to my bosses. I can argue all day about the gazillion benefits that using Rails brings to the table, but I can’t argue against the facts of our recruiting problem!  

A Plea to the Community

I wrote this post at Obie's request when I asked him for advice. I'd failed to consider that this is more than just my problem, more than just a hiring problem: It's a Rails community concern. The Rails platform is not bleeding edge anymore. It's proven, mature, reliable, amazing and a proper choice for just about any web development problem domain you might encounter. I don't know what the solution is, but I do know that we need to ensure that it continues to be the platform of choice for innovation.  We’re committed enough in the concept to put our money where our mouth is.

What do you think? Is this actually a community problem? Let's get a greater dialogue going.

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. :)