Obie Fernandez

More About 3-2-1 Launch by Hashrocket

As most everyone that reads this blog knows, I recently announced formation of my new startup company named Hashrocket. (We are named after the ubiquitous key/value => operator in Ruby.) One of our two principal offerings is called 3-2-1 Launch, and this post aims to tell you a little bit more about what it means and how we came up with it.

The idea for 3-2-1 Launch was born during Rails Rumble. Our app, PretendPeople, won honorable mention and the team had a great time. Afterwards, none of us could shake the idea that working under the huge time constraints of a 48-hour deadline brought out the absolute best in us. It's like the 37signals Getting Real philosophy, charged up on adrenaline. As far as we're concerned, one of the best ways to only "build half a product", is to only give yourself enough time to do that and nothing else. Embrace constraints!

Instead of freaking out about these constraints, embrace them. Let them guide you. Constraints drive innovation and force focus. Instead of trying to remove them, use them to your advantage.

After Rails Rumble we especially wondered if institutionalizing the embrace of constraints in a consultancy would be commercially-viable -- an appealing option for other "Getting Real" believers wanting to quickly churn out 1.0 versions of their new web application ideas.

We put the concept through its paces on internal work, and came to the conclusion that a span of 3 days is just enough time to get a new project off the ground - enough to nail down some distinguishing functionality, without sacrificing quality and good looks. Of course, it's not applicable to all projects -- our team of developers is 4-6 people (mostly working in pairs) which limits the amount of complexity we can tackle in one 3-day iteration (which we've taken to calling "orbits").

Here's a quick list of factors that empower us be ultra-productive in 3 days:

• Expertise in Ruby, Rails and BDD (using RSpec)
• Heavy automation of common tasks (pretty much anything repeatable is automated, including our initial application bootstrap which includes basic functionality such as authentication)
• Smart use of web services such as Amazon's EC2 and S3
• Reliance on Rails-based web 2.0 tools such as Basecamp, Highrise, Lighthouse, and Beanstalk

The 3 scheduled days (always Mon-Wed) refers strictly to implementation work, specifically the first iteration, ending with a public release of the software. Prior to the 3 days, our contract specifies a time period of 3 weeks during which we agree on detailed specification (RSpec Stories ftw!) and high-fidelity mockups. What we're looking to achieve is a high level of confidence that we'll be able to launch in 3 days, and that necessarily involves locking down requirements prior to implementation. We've talked about an abort mechanism if anybody on the team thinks we're not going to achieve a successful launch (unveiling) on Thursday. If an abort were to occur, we'd postpone the launch for the next available date (probably the following week) at no additional charge to the client.

Right now we're doing Rails exclusively, although we're keeping our eyes on Merb and other up-and-coming competitors.

The cost model for the 3 weeks + 3 days (including deployment and post-support) is fixed-price: 30,000 USD. An essential value of the offering involves client mentoring: our curriculum, which will probably be marketed separately within a few months teaches new web entrepreneurs the essentials about the development process, recruiting and vetting technical people, as well as evaluating hosting options and costs. We want to give our clients everything they need to establish accountability from their technical resources and not get ripped off "in the ghetto".

Our first public 3-2-1 Launch is clean-undies.com and we are planning on blogging a more extensive description of what it is along with a feature roadmap later this week.

Are you using Haml?

If not, why? Seriously, take a moment to tell me in the comments. If you haven't had a chance to play with Haml yet, here is an easy opportunity to do so online.

All of Hashrocket's new projects are done in Haml, and we've now decided to transition everything else in our portfolio over to Haml as soon as possible. The indentation-based approach works wonders for generating clean, semantic markup and the way that you can see the structure of your markup in a way that easily maps to CSS rules is simply brilliant.

My initial impression of Haml was not as favorable. If you similarly gave Haml a try when it was originally released and couldn't get it to work in a stable fashion, you might want to try again.

Growth in Ruby Jobs Relative to Java

ruby, java Job Trends

ruby jobs - java jobs

A big thank you to Reg for linking to this graph. Update: Since David F. Glasser, one of DZone's preeminent Java bigots, was so easily threatened and flustered by a graph of this "relative" nature, here is the absolute version for comparison. Nobody is disputing the fact that there are significantly less jobs doing Ruby in the marketplace and no deception was intended in posting the relative version. In fact, I left off the commentary so that I would not be accused of "hyping". Guess that didn't work.

ruby, java Job Trends

ruby jobs - java jobs

Do you think we are stupid?

If there's a positive side to some of the anti-Ruby negativity, it's that new voices are joining the fray. In the must-read If Rails Is A Ghetto, Please, Let Me Be Ghetto, John Munsch sums up the current anti-Ruby sentiment pretty well:

Everybody who has seen the explosive growth of Ruby and Rails over the last couple of years eclipse their favorite language/framework (e.g. Python, Groovy, PHP, etc.) seems to be blogging or commenting this idea that Ruby and Rails isn't really that great, it's just hype. It's only a committed few who have something to gain from you adopting Rails (i.e. a book to sell, consultant hours, etc.) who are promoting something that is snake oil.

Seriously, how stupid do you think we all are? I've been doing professional development since 1985 and doing it full time since '87. Do you really think that I and thousands of others can't tell when something works and it doesn't? I did HTML when the only browser was NCSA Mosaic and ASP websites to build DevGames.com and then later GameDev.net in 1999. That was painful. I can tell the freaking difference people. This works and it works well. I might not pick it for building the next version of eBay because it wouldn't stand up to the load, but I would pick it for building the early versions of the next site that will become as big as eBay because it will offer that site lots of fast growth and flexibility.

What's This Crap About a Ruby Backlash?

Zed's rant triggered some patently false anti-Ruby memes that have now been bouncing around the programming blogsphere echo chamber for a few weeks. Disturbingly so. It's time to put a bullet to the head of the idea that Ruby is experiencing a widespread backlash, that it was just a fad, or that it is inferior to competing technologies such as Groovy. As far as I can tell, the originators of these ideas are people that betray agendas against the success of Ruby and/or Ruby on Rails. Specifically, I'm calling one of them out by name:

Daniel Spiewak (for being a liar)

His post, The End of the Ruby Fad? really set me off and was the final straw that made me write this post. As a community, I don't think we can just let the FUD and lies perpetuate unchecked. Daniel's post in question is full of wrong-headed opinions, but it also has lies in it that I believe are specific enough to be called out as willful deception:

Daniel: "Ruby posts to link sites like DZone or Reddit get voted down before they have a chance to see the light of day."

Simply browse the ruby links on programming.reddit.com or the list of over 2000 ruby-related links on DZone to disprove that lie. My contention, which I think is fairly obvious to people on this side of the Ruby/Anti-Ruby divide, is that the people echoing the Ruby backlash theme are all folks with entrenched anti-Ruby stances and agendas. There are no neutral observers chiming in on the matter.

It's the same old FUD, repackaged:

Daniel: "...while Ruby may not be suitable for an enterprise level, high-traffic web application,"

Peter Cooper of RubyInside calls him out on that one better than I could hope to do so:

Peter: "You say you don’t like the hype or the backlash, but then you come out with this sort of vague non-statement to keep the fire burning. Any language “may” or may not be suitable for any task, but you seem to be implying in the context here that Ruby is “not” suitable for developing enterprise level, high-traffic Web applications without actually going the whole hog and just saying it. In any case, this, of course, is not true. At least, it’s no more true for Ruby than it is for Python, Perl, PHP, or Scala, say."

What about the most general of facts, about the nature of Ruby itself as a programming language?

Daniel: "(Ruby is) hardly a general-purpose language, so it could never replace Java and company."

Ruby is by definition, a general-purpose language. (Wikipedia makes a contrast between domain-specific and general-purpose languages.)

You have to question the actual knowledge of someone making such blatantly wrong assertions. In other words, does Daniel know what the hell he's talking about? He answers that question himself in the comment trail:

Daniel: "It has been pointed out that my "Rails" example is quite foolish and naive. This is absolutely true."

Oh the irony! How folksy and cute to write blatant crap in your blog, enjoy the publicity and then admit that you knew it was crap to begin with. To that I say "UNACCEPTABLE!"

Even his rhetoric is faulty, like this plainly false categorization of developers:

Daniel: "Developers these days fall into two camps: those who have heard the hype and rejected what it stands for, and developers who are totally carried away by the emotion of the fad."

Maybe not technically a lie, more of an opinion, but certainly bad rhetoric. There is a huge third camp, that dwarfs the extremists on both sides, full of intelligent, pragmatic individuals that are choosing to use the tools available to us without prejudice. That includes Java, Ruby, Python, Scala, etc. There is no silver bullet, and all that jazz...

Oppression

Daniel's post led me to question, what is the motive for piling on to the heap of negativity started by Zed and perpetuated by Rick Hightower, Graeme Rocher and others? Why pick on the Ruby community? Is it simply a reaction to the hype cycle?

Daniel: "Perhaps now that the bubble has burst, we’ll finally get to see the popularity of Ruby in its proper place."

Aha! Above all, that sentiment is the common thread amongst the haters of the progressive Ruby community. Oppression! They want to keep Ruby (and by extension Rubyists) in our proper place! What is that proper place I wonder -- perhaps it is out of the mainstream, out of the limelight, out of the enterprise, out of the places where we threaten the status quo!

About Rails and Ghettos

This is a post that has been a couple weeks in the making (in my head), but the more that time passes by the less interested I am in writing it. Nevertheless, there are a couple of points I want to get out there both for the record and for possible discussion.

First of all, it is obvious that Zed was using that ugly word in its current derogatory sense, and I'll keep that sense in my writing as well. According to the dictionary one of the definitions of ghetto is "an isolated group" or "a situation that resembles a ghetto especially in conferring inferior status or limiting opportunity".

In the greater realm of IT?

Does that definition ring true of Rails in the greater realm of Information Technology, or even just the programming world? I don't think so. The Rails community is not an isolated group, having members across a wide, diverse, range of enterprises and groups of individuals, from the highest-paid professional consultants, to the humblest program-for-fun enthusiasts.

What about inferior status, or opportunity limitations? That doesn't ring true either. If anything, the mainstream fascination with dynamic languages was ignited by Ruby on Rails a couple of years ago, which gives popular Rails practitioners a disproportionate amount of influence (ahem) in the programming world, and a prominent voice in online conversations about the future of our craft.

From my own (admittedly-biased) viewpoint, Rails is continuing to explode in popularity. Among other things, my book The Rails Way is selling extremely well, and we just had to do a rush reprint because demand exceeded even our optimistic estimates. It's currently a top-seller on Safari (a good indicator of traditional corporate developer interest levels), and has been hovering in the hundreds ranking on all of Amazon.com.

But where are the jobs?

To those that would use the number of Rails-related listings on major job boards as evidence of opportunity limitations, I point out that due to extraordinary demand for Ruby talent in the marketplace, it is almost pointless to advertise Ruby job positions via conventional channels. The way to find Rails talent is via targeted Ruby job boards, word of mouth, and blogging. Counts on mainstream job boards are meaningless at best, misleading at worst.

Most Rails developers worth their salt are contracting, simply because it is very lucrative right now. Rates for premium Rails talent is now in the neighborhood of $200/hour and continuing to climb. Average Rails talent costs at least $100/hour.  The work is finding them, not vice-versa. Why are clients willing to pay so much? Because they know we are a cost-effective bunch, doing the same amount of work (as individuals) that would take multiple traditional programmers in other mainstream languages, and with higher-quality as the  "icing on the cake".

How about just in the Ruby community?

Considering Zed strictly within the confines of the Ruby community, and not in the much bigger sphere of programming, I think he's still wrong. Like a newbie OO programmer violating the rule prefer composition over inheritance, he made an is-a/has-a mistake. What is true perhaps, metaphorically, is that Rails has ghettos, and Zed made the mistake of attributing qualities of a ghetto to the whole.

What I"m trying to say is that there are groups of people that have come over to work in Rails, the city of Rails if you will, who have settled into neighborhoods that can be very dangerous (monetarily) to inexperienced clients.

But why can't Zed get a job then?

What put me off about Zed's rant was not so much the content, but rather that it achieved such wide circulation. It wasn't meant to be read so widely, and I don't believe that he had destructive intentions when he wrote it. I lived and worked with Zed for five months during 2007, a time in which we became (and remain) good friends. I swear to you that Zed is a good, friendly guy, in person. (His created, over-the-top, narcissist online persona is another story!) The rant was filled with tons of inside jokes and commentary that really only make sense to other clued-in Ruby people, stuff that comes across as just mean, stupid or crazy to everyone else.

For instance, a significant percentage of readers obviously understood from the rant that Zed is unemployed, starving, and/or stark-raving mad. All three could not be further from the truth. Zed is happily employed by a major, household-name financial institution in New York City, where he comes into work everyday with a nice shirt and tie, and leads a Rails (yes, Rails) development team. Of course, none of this is news to those of us that really know him, but the rest of the world got a totally different story.

I'm Done with JRoller

This weekend I've finally done what I've been meaning to do for the last couple of years: Get my blog off of tired, old JRoller.com hosting. First of all, Apache Roller software sucks. Second of all, the community is Java-oriented and I'm tired of catching flack every time I post anything Ruby-related.

Initially I went with hosted Wordpress, but it seems to have a lot of limitations in terms of themes and layout, which is why I chose TypePad.