Early Signs of a Coder

What is the single question that is most predictive of dev ability?   The best coders come from a very disparate set of backgrounds, so it’s hard to group them on a single criteria.

However, one characteristic that I have seen be consistently predictive:  starting at a young age.  Gates, Woz, and even Jordan did it.

I am not in position to say whether I make for a good, great, or gruesome coder (1).  But I know that my history with computers is epic:

  • 1993: Age 13. Get our first computer, a Packard Bell 486SX/33 with 4MB of RAM.  It came with a San Diego Zoo App, an encyclopedia, and a really lame racing app of some sort (not to mention all the Win 3.1 niceties).  (2)
  • 1993: Learn how to use DOS, configure games to use extended memory, figure out how windows system config files work
  • 1993: Discover QBasic.  Disappointed to learn that it doesn’t compile to exes.  Decide to write a choose-your-own-adventure game with it anyway, complete with ASCII graphics.
  • 1994: Start a BBS (search for “Bill Harding” in the list), get the most calls in Poulsbo/Bremerton/Silverdale area (not saying much)
  • 1994: Enroll in the first of two computer programming courses at local community college (4.0).
  • 1995: Wrote VBBS scripts to emulate about five most popular BBS flavors (PCBoard, OBV/2, Renegade, etc).  To my knowledge, no one else accomplished this.  It was like carving a pumpkin with a butter knife.
  • 1995: Finish the community college computer programming courses with 3.9 average
  • 1996: Discover I prefer girls to computers

From 1996 until late-college were the dark ages of Bill programming, wherein I spent the better part of my teens having forgotten about that whole computer thing. (3)

But the reasons coding was so magnetic to me are the reasons it still is:   a chance for me to dream up whatever I could think of, and then make it become real to feel the rush of creation.

It’s like what businesses are supposed to be:  you decide what’s important to you, and then go make that vision into reality.  But in business, there is constant compromise and pragmaticism that ultimately rules the day, unless you’re Steve Jobs.  For a competent coder, they can at any time create the best program (of a certain type) across all human history.  It could be used by thousands or millions of people.  If it’s important enough to spend years on.

Even in the more pragmatic here and now, I know of few other jobs with a comparable opportunity to build something that matters with one’s own two hands.  This is why I latched onto programming so tightly & immediately at age 13.

Most of these characteristics are present by early teens:  the desire to build things, the capacity to solve problems, the joy of seeing a project completed… I think of them as “born qualities;” thus, my hunch is that if the teenager has access to a computer, they’ll probably figure out pretty quickly if they’re a programmer or not.

Update:  interviewed about 50 UW CS students today. The earliest coder of the bunch started in his late teens. The vast majority started when they entered the program (??!!).  So perhaps this theory is bunk, or these kids all suck.

(1) I suppose that having built Bonz is strong circumstantial evidence that I’m not gruesome

(2) Note how I remember the software that came with my first computer in as much detail as my first kiss

(3) Not entirely true; I did still fix old people’s computers at exorbitant prices (consistent with what other computer fixers charged). But mostly the cute girls beat the computers in this round.

Ubuntu, Dark Side of Simplicity

The following is my take on how the current passion for UI “simplicity” may be to blame for Unity, the downfall of Ubuntu as I’ve known & loved it. It’s wide-ranging, so I won’t be able to fully substantiate its every point, but if you simply click the area you’d like to know more about, I will wish that you were being shown detailed examples in support of my point. Many of the newly introduced usability issues in Unity are shared by Gnome3, so it seems that now is as good a time as ever for people who care to try to persuade some Linux distro to retain the high standard of developer usability we’ve become accustomed to.


Steve Jobs broke my OS, and I don’t even use a Mac. It began about 10 years ago, around the time Jobs had re-joined Apple, and the software industry was smitten with building UI that had every button and link you could need. “If they might need it, why not include it?” seemed to be the effective rationale.


Windows XP represented the pinnacle of the art; complete with a “Start” button, that, when clicked, exploded into two columns. These columns in turn had menu options like “All Programs” that could themselves balloon out to several more (overlapping) columns. In the case of the “All Programs” specifically, the user was treated to an unordered list of every program they had ever installed (often hundreds). It was so…terrible…yet quick to an advanced user (e.g., those that figured out how to sort it). For new users, well, you could probably figure out some of the basics within a week.*

But soon people began to decide this was arrangement was not ideal. Or even OK. I noticed this in full force with the release of the first iPhone. It was a device that was so stripped down that it didn’t include a feature (secure network access for business email) that would could have increased its user base significantly. It launched anyway, was quickly dubbed the “Jesus Phone,” and has managed to sell a couple gajillion units since.

Gone forever were the days of “the most commercially successful” products were “the most feature-full” ones.

This evolution, which I’d pin as starting around 2006 (first iPhone) has continued expanding its base of believers to present day. Now, in addition to the set of Apple devices, the default aesthetic for web consumer products has become “huge buttons / huge text / nothing that requires reading.”

In the context of the web, I think that this growing obsession with simple UI is usually a great thing. Like it or not, our attention is fragmented and life’s too short to read the manual for a product that I simply want to entertain me (see: Twitter, Instagram).

The problem is when the momentum for this trend** pushes it out to use cases where it makes no sense. Sometimes, a detail-rich interface is required to get the job done efficiently. In the case where an app is used by novice and sophisticated*** users, a balanced curve of “level of detail shown to user” vs “user expertise level” might look something like this


That is, this balanced approach would dictate that novice users were exposed only to the most essential 10-20% of all UI complexity. The UI should appear very basic to them. As the user’s needs become more sophisticated, the UI reveals contextual choices and/or configuration menus that accommodate their needs as power users of the product. Novice users are happy because they don’t see the complex pieces. Sophisticated users are happy because they can use it with maximum productivity so long as they’re willing to read a handful of configuration menus.

Products rarely end up this balanced. Windows XP threw the user in the deep end, both in terms of the learning complexity, and the vast sea of choices/links presented to even the notice user. OS X freed users from this soup of links and options, though before they got smart about context sensitivity, it often came at the expense of more clicks.

Ubuntu, pre-Unity, was arguably even worse than XP to the poor novice:


No oversized buttons or contextual UI reveal here. The reason the project thrived was only because the Ubuntu audience is made up largely of users who have advanced expectations for their OS. Many are programmers. They have to juggle IDEs, web browsers, web browser tools, and a smattering of terminal shells. Usually across multiple high resolution monitors, over multiple workspaces. To them, if complexity is the price that must be paid for configurability, then it shall be paid****.

This isn’t the sort of thing a novice will understand, let alone feel comfortable with, but the software did meet the needs of it sophisticated user base.

Then came tablets, the momentum of simplicity, and Ubuntu’s loving ode to it all: Unity.


Because this blog needs to get finished before tomorrow morning, I am forced to gloss over a detailed analysis of the functionality lost between pre- and post-Unity versions of Ubuntu. A couple salient examples include: well-integrated dual monitor support, multiple/configurable taskbar support, desktop customization, and ability to keep program menus within each program. For the quantitative-minded amongst you, the compared market share of Ubuntu vs. Mint makes the point more compellingly than my mini-list.

If it’s not already obvious, I love the trend toward simplicity. It was one of the main points of opportunity I saw in starting Bonanza back in 2008 — we sought to build a version of eBay that would be usable to busy people and non-experts. Simplicity continues to be something that I push for as often as anyone on my team, and I think it continues to be a big difference between our platforms.

But I don’t believe that “simplicity” should be the same thing as “dumbed down,” and I wonder if Unity’s pared down featureset could be a result of the Ubuntu designers mistakenly conflating “simple” and “feature-sparse”?

tl; dr

“Simple” and “effective” are closely related for novice users and for simple products. But they can be inversely related when “simple” gets in the way of “configurability,” which begets effectiveness for power users. In the case of Ubuntu, the users are largely geeks who use complex features to maximize productivity. Give the pared-down version of Ubuntu to novice users, but don’t let it rob the majority of your users the functionality they need.*****

Update: Finally inspired to post this to HN after reading Linus’ comments about Gnome3 being a detriment to usability. Given that Gnome3 has traveled a very similar path to Unity in terms of degrading the user experience (for sophisticated users) with its newest release, I am hoping that perhaps a sympathetic designer of Unity or Gnome3 might find this.


* Though as a computer repair guy, I often saw the concept take far longer to sink in. And don’t even get me started on trying to teach my grandparents exactly what a file system was and “what it did”

** Regarding use of “trend” to label the simplicity movement: I mean only that it is influencing all corners of design (web, native apps, mobile, and beyond) — not that it is ephemeral or irrational.

*** “Sophisticated” here means “more advanced,” or “more demanding,” not somuch the “better looking” or “more expensive” connotations of the word.

**** Of course, something doesn’t need to be complex to be configurable. Progressively revealed / contextual UIs can often deliver much of the best from both worlds. But it’s also easy to get implement rather intricate revealing schemes incorrectly and be worse off than if you had simply built a cluttered but static interface.

***** What makes it doubly insulting is that until Ocelot, we could get the functionality we needed by choosing the “Classic Ubuntu” login. What explanation is there to chop a feature that’s already been built…and provided the main lifeline to advanced users after Unity’s release?

Linux Mint Firefox & Chrome :: Remove Search Branding

I’m all for Mint Linux making some bucks via their Chrome and Firefox searchers, but not if it comes at the expense of basic usability. <quickie rant> If I were the Mint maintainers, I’d take a long look at whether it was desirable (let alone essential) that they hijack my CTRL-K functionality and replace standard Google results with their poorly formatted, functionality-impaired substitute.</quickie rant>

Anyhow, if you are here, you’re probably trying to figure out how to remove the Mint branded search from Firefox and/or Chrome. And I’m here to tell you how.

Remove Search Branding from Firefox

  1. Click on the Google search icon in your title bar
  2. Click “Manage Search Engines”
  3. Click the link to “Get more search engines”
  4. Choose a Google, any Google, from Mozilla’s choices. I chose Google SSL, which worked nicely.
  5. After you install your Google SSL (or other version of Mozilla version of Google), click “Manage Search Engines” again, and move your new Google Search to the top of the list.
  6. Voila!

Remove Search Branding from Chrome

There are probably an assortment of ways to accomplish this. I chose to Google “Chrome deb package” which led me to Google’s official distributions of Chrome, which can be found here. After following Google’s instructions to install my Chrome package, all was well (though that meant that I was running “Chrome” rather than “Chromium.” Whatevskis.)

Other than the annoying search stuff, so far Mint Linux seems to be an easy-to-setup iteration on the developer utopia that Ubuntu was built as, before it decided to go the way of the mandatory Unity.

Likes & Dislikes: The Product Edition

Anyone who has followed my blogs over the last couple years knows that I’m a very big fan of the like/dislike list. But I generally try to exclude products from my lists since they don’t have that “essence of life” quality that I’ve strived for in my lists.

But products are important, too. So here you have it: a like/dislike list dedicated to the products I use or have used. I’ll actually split this particular list into four levels of like because I can quantify more precision when it comes to products.


  • VMWare. Being able to seamlessly run Ubuntu & Win7 side-by-side (and have both of them performant) still feels like the coolest thing ever, even after doing it a year.
  • Rubymine. See: favorite Rails tools
  • New Relic. See: favorite Rails tools
  • Quora. Today it is very good. And if they don’t mess it up, next year it is going to be the oracle that has an intelligent answer for everything.
  • Google Search. So easy to take for granted, given how it is woven into every minute of our lives. But can you imagine a world without it? Try using any other search engine for solving programming problems if you want to remember why Google search deserves your love.


  • Windows 7. Terrible for programming Rails, great for UI/usability and productivity.
  • Ubuntu. Great for programming Rails, passable for usability and productivity (Gimp and Openoffice sure as hell ain’t no Photoshop and MS Office)
  • Microsoft Onenote. I have found no better tool for mapping whatever arbitrary structure/idea from my brain into tangible existence.
  • Firefox 4. It has Firebug.
  • Google Chrome. Introduced to the world the realization that we were browsing at half-speed. Low memory footprint.
  • Github. The world of open source programming could accurately be talked about in terms of “BG” and “AG”. It is not an overstatement to say that, along with Git (see below), Github has completely and utterly revolutionized the world’s ability to collaborate on complex projects. The residual impact of that change is hard to grasp.
  • Stackoverflow. Opportunity for them to move to “love” if ever they could build a half-decent search… I still use Google to find answers that I suspect are somewhere on Stackoverflow
  • Amazon. Like Google Search, above, it is such a part of our daily lives that it’s easy to take for granted. But also like Google, imagine shopping for commodities without it. Not to mention their efforts to lead the cloud computing movement.

Deeply Divided

  • Git. The “deeply divided” category exists specifically for git. On one hand, I love what it lets me do (effectively manage source control). On the other hand, I despise how unnecessarily arcane the syntax is, and how the documentation feels like it was written by a seemly unbathed newsgroup


  • Rhythmbox. Happy to remove them from this list if they can ever pull off the herculean feat of not considering the word “The” when sorting artists by name. Update: ho, shit! A hero!
  • Dell’s website. Inconsistent, buggy, hard to shop. Do like: Dell’s products, esp the pricing of them)
  • eMusic. Every company has a right to pivot and drop their early adopters — it is business. But the manner in which eMusic made this pivot (with an utter lack of advance notice and concerted effort to mask what was really happening) still rubs me the wrong way when I think about it.


  • Quicken. Everything feels like it takes 5x longer than necessary.
  • Microsoft Money. Try to use it sometime.
  • Playstation 3. Already hated their constant 45 minute system updates; and days after I wrote that blog post, they give away my CC and password to the Internet. Bang up job, guys.

Best of Rails GUI, Performance, and other Utilities

I’m all about putting order to “best of” and “worst of” lists, so why not give some brief props to the tools, plugins, and utilities that make life on Rails a wonderous thing to behold?

5. Phusion Passenger. OK, this would probably be first on the list, but it’s already been around so long that I think it’s officially time to start taking it for granted. But before we completely take it for granted, would anyone care to take a moment to remember what life was like in a world of round-robin balanced Mongrels web servers? You wouldn’t? Yah, me neither. But no matter how I try, I cannot expunge memories of repeatedly waking up to the site alarm at 7am to discover somebody had jammed up all the Mongrels with their stinking store update and now I’ve got to figure out some way to get them to stop.

4. jQuery / jRails. This probably deserves to score higher, as the difference between jQuery and Prototype is comparable to the difference between Rails and PHP. But since it’s not really Rails-specific, I’m going to slot it at four and give major props to John Resig for being such an attentive and meticulous creator. Without jQuery and jQuery UI, the entire web would be at least 1-2 years behind where it is in terms of interactivity, and I don’t think that’s hyperbole. (It even takes the non-stop frown off my face when I’m writing Javascript. With jQuery, it’s merely an intermittent frown mixed with ambivalence!)

3. Sphinx / Thinking Sphinx. There’s a reason that, within about six months time, Thinking Sphinx usurped the crown of “most used full text search” utility from “UltraSphinx.” And the reason is that it takes something (full text search) that is extremely complicated, and it makes it stupidly easy. And not just easy, but extremely flexible. Bonanzle has bent Sphinx (0.9.8) into doing acrobatics that I would have never guessed would be possible, like updating it in nearly-real time as users log in and log out. Not to mention the fact it can search full text data from 4 million records in scant milliseconds.

Sphinx itself is a great tool, too, though if I were going to be greedy I would wish that 0.9.9 didn’t reduce performance over 0.9.8 by around 50% in our testing, and I would wish that it got updated more often than once or twice per year. But in the absence of credible competition, it’s a great search solution, and rock solidly stable.

2. New Relic. OK, I’ll admit that I’ve had my ups and downs with New Relic, and with the amount of time I’ve spent complaining to their team about the UI changes from v1 to v2, they probably have no idea that it still ranks second in my list, ahead of Sphinx, as most terrific Rails tools. But it does, because, like all the members of this list, 1) the “next best” choice is so far back that it might as well not exist (parsing logs with pl-analyze? Crude and barely useful. Scout? Nice creator, but the product is still a tot. Fiveruns? Oh wait, Fiveruns doesn’t exist anymore. Thank goodness) and 2) it is perhaps the most essential tool for running a production-quality Rails site. Every time I visit an ASP site and get the infinite spinner of doom when I submit a form, I think to myself, “they must not know that every time I submit a form it takes 60 seconds to return. That would suck.” On a daily basis, I probably only use 10% of the functionality in New Relic, but without that 10%, the time I’d spend tracking logs and calculating metrics would make my life unfathomably less fun.

1. Rubymine. The team that created this product is insane. Every time that I hit CTRL-O and I type in “or/n” and it pops up all files in the “offers_resolution” folder starting with the letter “n,” I know they are insane, because having that much attention to productivity is beyond what sane developers do. Again, for context’s sake, one has to consider the “next best” choice, which, for Linux (or Windows) is arguably a plain text editor (unless you don’t mind waiting for Eclipse to load and crash a few times per day). But, instead of programming like cavemen, we have a tool that provides killer function/file lookup; impeccable code highlighting and error detection (I had missed that, working in a non-compiled language); a working visual debugger; and, oh yeah, a better Git GUI than any of five standalone tools that were built specifically to be Git GUIs.

Perhaps as importantly as what Rubymine does is what it doesn’t do. It barely ever slows down, it doesn’t make me manage/update my project (automatically detecting new files and automatically adding new files to Git when I create them from within Rubymine), and it handles tabs/spaces like a nimble sorcerer (something that proved to be exceedingly rare in my quest for a usable IDE).

Like New Relic, I probably end up using only a fraction of the features it has available, but I simply can’t think of anything short of writing my code for me that Rubymine could do that it doesn’t already handle like a champ. Two thumbs up with a mutated third thumb up if I had one.


Yes, it is a list of apples and oranges, but the commonality is that all five-ish of the lists members stand apart from the “second best” solution in their domain by a factor of more than 2x. All of them make me feel powerful when I use them. And all of them, except arguably New Relic, are free or bargain priced. Hooray for life after Microsoft. Oh how doomed are we all.

Rails Slave Database Plugin Comparison & Review


Based on the skimpy amount of Google results I get when I look for queries relating to Rails slave database (and/or the best rails slave database plugin), I surmise that not many Rails apps grow to the point of needing slave databases. But we have. So I’ve been evaluating the various choices intermittently over the last week, and have arrived at the following understanding of the current slave DB ecosystem:


Credibility: Was the first viable Rails DB plugin, used to rule the roost for Google search results. The first result for “rails slave database” still points to a Masochism-based approach.

Pros: Once-high usage means that it is the best documented of the Rails slave plugins. Seems pretty straightforward to initially setup.

Cons: The author himself has admitted (in comments) that the project has fallen into a bit of a state of disrepair, and apparently it doesn’t play nice with Rails 2.2 and higher. The github lists multiple monkey patches necessary to get it working. It only appears to work with one slave DB.


Credibility: It’s currently the most watched slave plugin-related project I can find on github (with about 90 followers). Also got mentioned in Ruby Inside a couple months ago. Has been updated in last six months.

Pros: Doesn’t use as much monkey patching to reach its goals, therefore theoretically more stable than other solutions as time passes.

Cons: Appears to only handle a connection to one slave DB. I’m not sure how many sites grow to the point of needing a slave DB, but then expect to stop growing such that they won’t need multiple slave DBs in the future? Not us. There’s also less support here than the other choices for limited use of the slave DB. This one assumes that you’ll want to use the slave for all SELECTs in the entire app, unless you’ve specifically wrapped it in a block that tells it to use the master.

Db Charmer

Credibility: Used in production by Scribd.com, which has about 4m uniques. Development is ongoing. Builds on acts_as_readonlyable, which has been around quite awhile.

Pros: Seems to strike a nice balance between the multiple database capabilities of SDP and the lightweight implementation of MSA. Allows one or more slaves to be declare in a given model, or for a model to use a different database entirely (aka db sharding). Doesn’t require any proprietary database.yml changes. Didn’t immediately break anything when I installed it.

Cons: In first hour of usage, it doesn’t work. It seems to route most of its functionality through a method called #switch_connection_to, and that method doesn’t do anything (including raise an error) when I try to call it. It just uses our existing production database rather than a slave. The documentation for this plugin is currently bordering on “non-existent,” although that is not surprising given that the plugin was only released a couple months ago. Emailed the plugin’s author a week ago to try to get some more details about it and never heard back.

Seamless Database Pool

Credibility: Highest rated DB plugin on Agile Web Development plugin directory. Has been updated in last six months.

Pros: More advertised functionality than any other slave plugin, including failover (if one of your slaves stops working, this plugin will try to use other slaves or your master). Documentation is comparatively pretty good amongst the slave DB choices, with rdoc available. Supports multiple slave databases, even allowing weighting of the DBs. And with the exception of Thinking Sphinx, it has “just worked” since dropping it in.

Cons: Tried to index Thinking Sphinx and ran into difficulty since this plugin redefines the connection adapter used in database.yml*. The changes needed to database.yml (which are quite proprietary), make me suspicious that this may also conflict with New Relic (which detects DB plugin in a similar manner to TS). Would be nice if it provided a way to specify database on a per-model basis, like Db Magic. Also, would inspire more confidence if this had a Github project to gauge number of people using this.


Unfortunately, working with multiple slave databases in Rails seems to be one of the “wild west” areas of development. It’s not uninhabited, but there is no go-to solution that seems ready to drop in and work with Rails 2.2 and above. For those running Rails 2.2+ and looking to use multiple slaves, Db Magic and Seamless Database Pool are the two clear frontrunners. I like the simpler, model-driven style plus lack of database.yml weirdness of Db Magic. But I really like the extra functionality of SDP. At this point, our choice will probably boil down to which one gives us the least hassle to get working, and that appears to be SDP, which worked immediately except for Thinking Sphinx.

I’ll be sure to post updates as I get more familiar with these plugins. Especially if it looks like there is any intelligent life out there besides me that is attempting to get this working.

Update 10/13: The more I use SDP, the more I’m getting to like it. Though I was initially drawn to the Db Magic model-based approach to databases, I now think that the SDP action-based approach might make more sense. Rationale: Most of the time when we’re rendering a page, we’ll be using data from models that are deeply connected, i.e., a user has user_settings and extend_user_info models associated with it. We could end up in hot water if the user model used a slave, while the user_settings used the master and extended_user_info used a different slave, as would be possible with a model-based slave approach. SDP abstracts away this by ensuring that every SELECT statement in the action will automatically use the same slave database from within your slave pool.

Also, though I didn’t notice it documented at first, SDP is smart enough to know that even if you marked an action to read from the slave pool, if you happen to call an INSERT/UPDATE/DELETE within the action, it will still use the master.

* Thinking Sphinx will still start/stop with SDP, it just won’t index. Luckily for us, we are already indexing our TS files on a separate machine, so I’ll just setup the database.yml on the TS building machine to not use SDP, which ought to solve the problem for us. If you know of a way to get TS to index with SDP installed, please do post to the comments below.

Rails 2.2 Connection Pools + Mongrel Handlers = Slow

Rails 2.2 doesn’t like Mongrel handlers. Specifically, the Rails 2.2 connection pool doesn’t. More specifically, the connection pool doesn’t like a bunch of random threads taking its connections and not giving them back.

After a day of head banging (yah!! rock on!!), I devised the following monkey patch solution to get our Mongrel handlers back on Rails’ good graces:

module ActiveRecord
module ConnectionAdapters
class ConnectionPool
def release_connection(conn_id = nil)
conn_id ||= current_connection_id
conn = @reserved_connections.delete(conn_id)
checkin conn if conn

class ConnectionHandler
def clear_my_connection!(conn_id)
@connection_pools.each_value {|pool| pool.release_connection(conn_id) }

After you paste that into a file in your initializers directory, you’ll just need to call the clear_my_connection! method whenever you exit a Mongrel handler (or other type of Rails thread) that has accessed an ActiveRecord find. We’re doing this like so:


Hope this saves someone else a day of unproductive Googling when they upgrade to 2.2 and their Mongrel handlers suddenly start taking 5 seconds each (the time until the Thread’s connection will naturally timeout) to execute.

If anyone else has solved this in a more elegant way, you speak up now, y’hear?

Oh Woe are We: Desecrating Rails for a Brighter Tomorrow

Rails programmer, how long do you think these glory days will last?

I first started thinking about this while attending Railsconf and talking to programmers who were creating Rails projects within gorillas such as AOL, LinkedIn, Monster, and of course Yellowpages (my apologies to AOL, LinkedIn, and Monster if any of those projects were supposed to be secret). After watching DHH’s keynote, it sunk in further. Now I hear that EngineYard just got $15m more funding, and the picture is crystal clear: the hobgoblins from years’ past that have kept Rails away from corporate use are melting away faster than polar ice cap.

This is a bad thing for those that like the competitive advantage Rails affords. With the advantage of RoR (and two tablespoons of Firebug), right now is one of those rare times in which a motivated programmer or two can compete technologically with legacy web companies that have payrolls 100x greater.

If Bonanzle could dig up an ounce of business savvy (still TBD) to go with our technology, I like to think we could be one of the seminal examples of this. Look down the list of our technological advantages vs the gorillas (real time offer making, integration with all major IM clients, image cropper, price guessers, pretty urls, 0-page-load item creation, real time messaging built into site, item importers for eBay/Craigslist, etc. etc.), and it’s clear that we’re living in an age where the possibilities for the underdog are as rife as ever.

But how long will that be the case? With a test-driven development environment like Rails, where metaprogramming and a solid MVC architecture can cut 125,000 lines of code to 20,000 lines (like Yellowpages did in moving to Rails), suddenly gorillas are nimbler, and order is restored to the world. Eventually, the gorillas might just figure this out. The horror.

In light of these facts, I have taken to pumping up the FUD on Rails whenever possible. I like my unfair Rails advantage, and would miss it if it were gone. In the interests of helping the reader perpetuate Rails FUD amongst their own social circle, I have created the following collection of sound bites to help you desecrate Rails:

  1. Rails Doesn’t Scale. C’mon, you know it’s true. I even preached this one myself. Tell them that “Ruby is the slowest programming language” ever. I mean, it’s slower than an excellent language like Python by a factor of 3x. It’s slower than C by about 70x! I can only imagine how much slower it is than x80 assembly. Visualize how screaming fast your assembly-driven site could be. If your listener happens to mention cloud computing, I recommend you retort with the thousands of dollars they’d have to spend on a server cloud for a heavily trafficked site. If they point out that those costs are a fraction of the development costs they’d incur otherwise, move on to point number two.
  2. No Big Sites Use Rails. Yes… yes… yes! In Rails’ history, excluding a couple one shot wonders like YellowPages and Twitter (don’t forget: Twitter is rumored to be leaving Rails), no “big” web site is running on Rails. Point out that both Facebook and Flickr run on PHP. Or better still, perhaps your listener would like to literally be the next MySpace and build on .NET? Hopefully they do not retort that almost none of the biggest sites were built when Rails existed, or that most new sites are built on RoR, or that any kind of bad Rails juju they encountered could be monkey patched since it’s all open source. It should suffice to say that if no big site has been built on Rails by now, no big site ever will be. Still not dissuaded?
  3. Google uses Python. Yes, they also use Ruby. But they use Python more. This one ought to work well when convincing a take-over-the-world CEO.
  4. Other Languages have More Libraries. This works sort of like number two… point out how many libraries PHP already has. Or .Net. Or Java, or C++. You can manipulate the hell out of an image with any of these choices. Or if you decided at the last minute that you wanted to make your web site into a PS3 game, you’d be glad you chose C++ and its PS3 libraries. Only the savviest enterprise-y tech guy will be able to discern between quantity and quality: think how many underdeveloped, crap libraries they’ve become accustomed to while dealing with Java.
  5. Open Source Software is Unsupported Software or Ruby on Rails Doesn’t Deploy on Windows or URLs Don’t Matter. Alright, if they still weren’t convinced after four points that terrific, you’re going to need to fire some scattershot. These arguments should close the case for the last few Windows types, and for others, hopefully they tilt in favor of Anything But RoR. But for the last few hard-to-budge listeners, you’ll need to pull out your ace in the hole…
  6. The Creator is an Ass. Have you ever listened to DHH talk? What an elitist snob. Thinks he is God’s gift to programming. The way he repeatedly cut off this nice Python fellow was disrespectful. Any framework created by this guy must be an elitist, disrespectful framework to use.

And that should about do it… double bonus points for anyone who can convince eBay to give ASP .NET a whirl!

(Note to busy/dense readers: #1-6 employ heavy use of irony)

Rails Performance: A Brief History of the Universe

After much ado, the time has finally come to get Bonanzle moved to real servers, with Capistrano and all the tricks the big boy Rails apps use. But as I started to look into the logistics of this, I ran into a quick interview with Alex Payne regarding Rails performance on Twitter that made me raise an eyebrow. A couple minutes later, I came to the realization that this “quick interview” actually represents the center of an impassioned web of controversy that has enveloped the Rails community regarding the scalability of Rails.

On one side of the argument are DHH and the programming purists, whose solution to the performance problem is to say any number of things other than, “yes, performance is an important issue to us, and we intend to make it better.” On the other side of the argument is people like Rob Conery and Joel Spolsky who write that maybe RoR developers should give some weight to these performance concerns, as they seem to be the only argument of substance against mainstream RoR love.

Judging by the responses to Rob’s article, methinks there is still quite a ways to go before the community will come to acknowledge the problem at hand. What makes me think it’s a problem? Um, how about objective data from reliable sources? Ruby is slow. Rails is slow and getting slower as time goes on. To be fair, I tend to agree with Joel that Rails can never be fast until Ruby is, so this isn’t all on DHH, as some have implied. At the same time, when some crazy Japanese guy (developer of YARV) with this web page is the supposed prophet of Ruby optimization, I am concerned. Even if the guy is crazy like a fox, the extent of what he will divulge about the future of YARV is that “YARV development is too HOT!” Better HOT! than cold, but something like an expected date of arrival would be a comforting piece of data to add to the development page.

Others data bits I’ve seen around:

* Some suggest JRuby is the answer to Ruby’s problems. But by all accounts, it isn’t the solution to Ruby’s performance problems. At least, not yet.

* A common argument I see being used to dilute the significance of performance is that “performance isn’t scalability.” What people mean when they say this is that poor performance doesn’t always mean you’re unequivocally screwed. And to the extent that you have developers that like to spend their time setting up caching and multi-database transactions, I suppose that is true. But as a programmer who knows a lot of other programmers, I can pretty confidently say that “how to implement a load balancer” is not the sort of problem that many programmers exalt to face. Esoteric details about how to implement Pound or a memcache or HTTP connections between multiple Mongrel processes and an Apache frontend — this is the punishment that Ruby on Rails developers bear for the joy that they experience programming their apps.

* Another common “solution” to the problem I see is to use something similar to RoR that makes an effort at better performance. Entries from this side of the arena include Grails and Merb. The question I’d be asking myself if I were a Rails evangelist that wanted to see the language thrive is, “why do these similar applications exist?” Partly because people are comfortable with legacy languages (in the case of Grails), but moreso because there are many practical people who love RoR as a language, but can’t stomach the performance trade-offs that go along with it.

I suspect that many Rails-evangelists may be quick to point out that if I don’t like it, I can go to hell or fix it myself. And if I won’t fix it, I am in no position to complain, blah blah blah. Whatever. The first step is admitting we have a problem. If there is any blemish upon Rails name, this is the one. Can we agree on that?

Oh my gosh that’s kind of evil

Who would have thought? Some 5 years after Google emerged in the public consciousness, and they have done their first kind-of-evil thing. When I logged into my Gmail this morning, there was a big, red stripe across the top of my Gmail account warning me that if I didn’t disable Firebug (web debugging software used by 99% of all web developers, 100% of all web developers in their right mind), than there could be severe performance penalties while I used Gmail.

I will admit that I was pretty disappointed that Google chose to try to make users change their habits, rather than taking the extra time (and yes, cost) to get Gmail to work with a tool so common amongst web developers. But at the same time, it made me re-realize just how seldom Google chooses to take the low road like this. In the pre-Google days, it was routine for applications to make me reboot my computer to install them. Or for applications to not include an uninstaller. And include spyware. And pester me with waits to use them if I didn’t pay.

Of course, many applications still do these things, and I don’t think that Google alone has turned the tide away from these annoying practices, but it has certainly risen public awareness that “don’t be evil” is a viable business strategy that can create both adoring users and a profitable bottom line. Katy recently pointed out that it should only be a matter of time until Starbucks’ insistence on charging users $6.00/hour to use the Internet could come back to hurt them. I hope she’s right. There is no need for these kinds of business practices, when righteous users now know to stand up to them.