I admit it, I was waiting for a flying car. Watching a live transcript, the lack of a camera was very disappointing. So much so that once it was clear, I lost interest and wandered away to watch some financial news. When I heard it was $499, I was surprised, and considerably less disappointed!

So I watched the keynote video as soon as it was available. During the video I selfishly realized that my life would be simpler if my mother, brother, sister, and mother-in-law had an iPad. Selfish because I was quite certain that my technical support load would drop dramatically if they were using an iPad.

I refined that thinking and shouted my first composed thoughts on the matter via Twitter:

@tmornini: In my memory the iPad is the first major Apple product announcement since the aqua iMac that essentially nobody thought was overpriced.

@tmornini: They sold A LOT of aqua iMacs! Even back then there were millions who wanted an inexpensive, easy to use, floppyless “internet computer”

@tmornini: How many millions of today’s unemployed have an outdated, clunky PC that will need to be updated quickly upon employment?

@tmornini: How many of those will turn that clunky PC into a backup station for their new iPad and begin using cloud backed applications?

And today I read a post by Caleb Elston. When I was reading it, I wanted to shout “People who aren’t technical aren’t stupid!” For some reason, a clearer, sharper image of what I was thinking when I wrote those tweets coalesced in my brain.

With a technically creative background going back to the TRS-80 and assembly language, I feel that today’s Macintoshes running OS X are the best technical tools ever created. Nearly every technically creative person I’ve ever respected is now using a Macintosh. The vast majority of the rest use Linux.

I believe the difference is Unix, and its many CLIs. Programmers love Unix because command lines are incredibly useful to programmers. It’s completely shocking that Microsoft has never improved or replaced the DOS shell. Yes, I know about Monad. That’s a really sad story.

How many times have we been told that Windows dominated because it had the best programs? That’s the exact problem Microsoft now faces, particularly -vs- iPhone OS: 140,000 apps and 3 billion downloads have been achieved VERY quickly! When it was clear Microsoft had won the first round, they had far smaller numbers!

Seems only browser-native web development stands a chance against those numbers. And it’s not difficult to argue that end-users prefer web connected native apps. Thank goodness many of these applications are being built with Ruby on Rails backends! :-)

It’s clear that computers are designed to serve technically creative individuals. Sure, they’ve gotten easier to use for technology consumers, particularly at the application level. Yet the user experience has changed only in ways that the technically creative crowd were willing to accept, often begrudgingly.

Think about it! Did the users of VisiCalc, Lotus Notes, and Excel ever need to manipulate files directly? In the day, yes, if only to do things like backup and organize their work. Yet iTunes, iPhoto, and every iPhone application tells me that they should never have been asked to! My crowd’s lack of imagination was the real limiting factor. What programmer could ever imagine a computer without end-user file system access? Impossible!

Have you ever noticed that the tools in a professional’s toolbox are different than their consumer grade counterparts? Think nail gun and hammer: massively different user experiences!

This has never really been the case with computers. Sure, powerful and expensive systems are marketed as “professional” models, the remainder as “consumer” models. Those differences are skin deep: even when watching them being used you probably cannot distinguish between the two! Not so much with the nail gun. :-)

That, I think, is where the iPad splits computing down the middle. It, like the iPhone before it, was built for consumers of technology, NOT creators of technology. I think it’s going to be a really big deal.

The flip side? We technical creators can now get user experiences designed entirely for us. How will our tools behave in a few years when they no longer need to (poorly!) fit the needs of technology consumers? It’s a mystery, but let me be the first to say “Bring it on!”, because it seems evident that they’re going to be considerably more productive, and hopefully more violently capable, like a nail gun! :-)

It does seem to me that they’ll have Apple logos on them for some time to come. Why? Because it appears that Apple now owns the entire chain: the best general purpose tools for the technically creative, and the ONLY general purpose tools for technical consumers.

P.S. Yes, Alan Kay was on this decades ago. He’s the Benjamin Franklin of the technical community, massively under-appreciated.

Why? Well, that’s simple: Of the foods I like, I like them all nearly equally. For some reason that a gourmet would never understand, there’s very little difference between a (really well made) PB&J at home and a really unique and terrific experience at one of San Francisco’s fabulous restaraunts.

My wife Elizabeth and son John are much the same, though Elizabeth has far more health cred than I do, and John, who enjoys and prefers spectacularly unhealthy food as much as I do, is fortunately largely fed a controlled diet by Elizabeth.

A few months ago, Elizabeth announced that she had some healthy frozen food in the freezer and she’d like my help ‘cooking’ it. This was weird because we rarely cook. Elizabeth and John eat healthy fresh meals while I largely eat something closer to the aforementioned PB&J.

The result of this bit of kitchen effort was a resounding success — so much so that I’ve mentioned it to several people. “It’s *easy*”, I’ve said, “there are 3 steps, Elizabeth says it’s healthy, and it really tastes great!”

We’ve had these for dinner occasionally ever since, and they’ve continued to result in nice tasty meals, prepared quickly and easily, and continue to impress my radically inferior command of the kitchen with their 3 step simplicity.

Tonight, it turns out, was frozen meal night once again. Elizabeth had already started preparing the meal, so I glanced over the instructions to see where I could help out.

Well, imagine my surprise when it dawned on my that’d I’d been getting duped the entire time!

Check out these instructions:

Question: How many steps are there in step 1? :-)

I’m going to make a wild guess: The vast majority of the audience that will read this are technical people. Being a technical person myself and spending as much time with technical people as I have in my life, I’m confident that many readers will expect me to begin a rant on how wrong, unfair, and deceitful this is.

Why? Because, again in my experience, most young technical people have a distaste for marketing and sales activities. They believe that they should make their decisions internally, without any outside interference, particularly obviously biased sources of information such as marketing materials and sales pitches. I’ve felt this way most of my life.

But, this silly little frozen meal has allowed me to see this from a different angle! If the packaging had enumerated the 12 (or so) steps required to actually prepare the meal, I don’t think Elizabeth would have picked them up to begin with.

If I’m wrong about that, I assure you that I would not have been as eager to help out. And I absolutely GUARANTEE YOU that I wouldn’t have told a bunch of people how easy it was to make.

So, while some readers may consider this wrong or deceitful, let me explain why I think it’s actually pretty cool: The packaging isn’t dishonest, as it does clearly state all the individual steps. But it also groups those many simple instructions into 3 larger steps, with step 1 clearly being the most difficult, and progressing onto a simpler step 2, and finishing with a really simple final step 3. I think that this progression gives the consumer a real sense of comfort. It makes the steps fly right by, since it’s obvious that once you’ve finished step 1, you’ve already completed most of the work.

But that’s the technical description of the sleight of hand that those nasty marketing folks used to deceive me, right?

Not for me. Instead, I see it as effective communication of the real message they were trying to get across: THIS IS EASY! Of course, everything is supposed to be easy these days — it seems that Apple computer is turning itself into one of the most powerful companies on the planet by making things easy!

But, making these meals really *is* easy, and communicated this way is, IMHO, far more effective than simply screaming “THIS IS EASY!” on the packaging.

I suppose my point is, itself, fairly simple: When it’s time to market and sell your product, it’s really important to find the best way to communicate about the product. Listing a long and detailed bunch of features really doesn’t cut it anymore; I’d like to think the days of feature checklists are behind us.

Instead of that, tell a story, and tell nearly the same story each and every time, but throw a bit of Darwinism into the mix, testing slightly different variations each time. Do this face to face with customers, and learn how to best communicate how your product will benefit them. When you get it right, you’ll see it in their faces.

Sometimes this survival of the fittest will make the difference, but sometimes it’s even simpler than that. A bad name can really take the wind out of your sales. A stellar example of this is an early product offering we had, semi-dedicated environments. We knew that customers wanted their own databases, and better isolation from other customers, so we created a product to fit their needs. Oddly, it was extremely difficult to sell, until we finally figured out what was wrong.

Would you guess our pricing was too high? From the input we received, and the intelligence we could gather on our competitors, that didn’t seem to be the problem at all. The fix, it turned out, was to rename the product. Instead of the glass-is-half-empty “semi-dedicated environment” we began calling them the glass-is-half-full “fractional clusters.” An identical technical product, with a better name, sold better.

“A rose, by any other name, would smell as sweet?” Absolutely, categorically, spectacularly not true. :-)

Why? I believe it’s because it told a better story — the customer could see themselves moving from slices, to a fractional cluster, then on to a dedicated cluster. They could, that is, AFTER we changed the name.

So, experiment a little. Don’t get too attached to early decisions, particularly so when your guts tell you something is amiss. Mostly importantly, stay focused on communicating a story that can be digested and understood by your customers.

If you’ve read it this far, I thank you for your attention, and request your indulgence in commenting. Did telling this as a story help to sell you on the ideas described? :-)

Tom

P.S. Enjoy!

P.P.S. For those of you who want more details on these meals, Associated Content has a video review, which backs up my statement that these means are really good, and fairly healthy as well.

Merb was created as a workaround for a very early and specific performance issue in Rails: uploading photos efficiently. Since then, it’s become a full framework that had many wondering why Engine Yard was supporting a Rails competitor. We *always* felt that Merb was complimentary to Rails: an extra tool in your Rails toolkit. Regardless, it has become increasing clear that Rails and Merb were on a collision course that was leading to a schism in the once unified community of Ruby developers. We’re delighted that the teams are working together to avoid such a schism, and as such we *fully* support the merger of the teams and code bases.

Engine Yard was *founded* as a Ruby on Rails deployment company. Nearly every one of our 400+ customers uses Ruby on Rails! Perhaps the thing that makes me happiest about this announcement is that we will now *directly* support the Ruby on Rails framework by placing existing Merb resources into directly improving Ruby on Rails. We find it very fitting that we’ll now directly support the framework that has supported Engine Yard’s very existence!

Enormous kudos *must* be bestowed upon the Ruby on Rails and Merb core teams for agreeing to work together for the betterment of the community. Now, rather than discuss the relative advantages of Rails -vs- Merb, we can get back to the real business of changing the world, one developer at a time, by freeing them from the shackles of less efficient development environments.

For some reason, Pratik Naik, the poster of the original Twitter message chose to respond to my post on my blog via the Phusion blog. Ninh Bui of Phusion has asked the discussion to be taken elsewhere, so here we are.

Count me as shocked at the angry and non-linear response to what I felt was a neutral response to the original Twitter message.

@Tom : It’s you who need to put down your weapons when *YOU* felt the need to reply to my simple twits (where there was no mention of you/your employees/your comany ) with a gigantic blog post.

What you say here, Pratik, is not entirely true, as Engine Yard is a host that “doesn’t let you use Passenger”. Basically you’re now saying that Engine Yard was collateral damage to an attack not aimed directly at us. Of course, collateral damage is unavoidable when you make statements of the sort you made. Perhaps you should aim more carefully in the future to avoid such confusion.

When you have to reply to me saying “PEOPLE spreading FUD about passenger”, the shoe must fit. Even your employee had to make a direct personal attack, which is a shame.

Actually, I didn’t respond to that, but I certainly did reference it. I’m unaware of any of our employees making a direct personal attack, but will take you at your word and apologize for that employee here and now. We certainly don’t condone such behavior, though know full well that in a company full of young technical people, mistakes will be made.

But it’s very apparent you weren’t replying to me, but you were replying to your customers justifying your position against the growing popularity of Passenger. And that’s fine. Just don’t pretend as if it’s all in a response to my twitter messages. My twit, clearly, was just a catalyst.

Please don’t put words in my mouth. As stated in my post, I was replying directly to you. There *are* valid reasons to not support Passenger, and I outlined a few of them. I also explained that there were very valuable and useful aspects of Passenger and most especially, Ruby Enterprise Edition. I think that I explained those reasons fairly clearly.

But forget all that. Let’s have a little history lesson, shall we :

** Feb 12 **
- Ezra Announces mod_rubinius http://brainspl.at/articles/2008/02/12/what-do-you-want-to-see-in-mod_rubinius.
- Comment #12 is EXACTLY what passenger is.
- And now mod_rubinius has been officially killed ? ( correct me if I’m wrong http://www.google.com/search?q=github+mod_rubinius )

Thanks for pointing out that mod_rubinius is not where it should be. I’m checking into that. Of course, since most of the code was written before the virtual machine was rewritten in C++, the code isn’t highly valuable at this point. :-(

It’s rather unfortunate, to be sure, that we needed to reduce the size of the Rubinius team here at Engine Yard. We still maintain two full time people working on that project, which we consider to be very important to the community. Some might think it’s impolite to bring this up, but since we have already discussed this in public, I will not hold it against you.

I am confused, however, how this is relevant to the issue at hand. Perhaps you could enlighten me?

** April 4 **
- Passenger is released to the public http://ninh.nl/blog/2008/04/04/the-moment-youve-probably-been-waiting-for-so-have-we
- If you notice the announcement, “Lastly, we’ve been approached by EngineYard..”. And we never heard about that ever again. Clearly, something went wrong there.

Are you surprised that there are contacts made, and discussions had, that don’t come to fruition?

Again, I’m at a total loss as to how this is relevant to the discussion.

After that, you guys CONSTANTLY tried to ignore/sideline Passenger, by saying it’s suitable only for shared hosting/VPS. COMPLETELY BASELESS as pointed out 100 times before. That’s pure FUD.

Well, stating it in ALL CAPS doesn’t make it any more true. What does the word constantly mean to you?

In fact, Ezra endorsed Passenger, with a few caveats! Is Ezra not allowed to state an opinion, and suggest that Passenger is currently state of the art for a historically problematic issue of hosting small sites? Was it true at that time that Ruby Enterprise Edition wasn’t stable on 64 bit systems, which we use exclusively here at Engine Yard?

Here’s an interesting part :

Tom says “Of course, you can reduce these disadvantages by cuting down a custom build and tweaking the included modules”
Ezra says “I think i;ve scaled a few ruby websites and I use nginx cuz is beats apache’s ass”

Clearly, those are contradictory statements and one of you doesn’t know what you’re talking about. Pick one. Period.

I’ve looked at those statements again and again and fail to see how they’re contradictory. I said that you can reduce these disadvantages, but I did not say you could eliminate them. Ezra said that nginx “beats apache’s ass” which, I must admit, lacks technical rigor, yet the two statements simply do not contradict each other.

When you start putting Apache/nginx and “Scaling” in the same sentence, you’re just trolling/spreading FUD.

Really? Why is that? Would it be FUD to say “Apache and nginx scale equally well”? Both words in the same sentence, but no FUD involved at all. Now I’m being ridiculous to make a couple of points. Ezra’s statement was clearly an opinion. To make it more than an opinion, benchmarks would be required. Additionally, there are many ways that nginx could “beat apache’s ass” (memory and CPU usage, for instance) that would not indicate that Apache couldn’t scale. Directly to the point, Ezra did not say that Apache doesn’t scale.

What seems clear to me, in the end, is that you have an issue with Engine Yard. I’d *love* to understand what that issue is. Because, at this point, you’re now suggesting that we’re FUDing Apache, which is well off the original subject of Passenger.

We’re a Ruby and Rails application deployment company. We sponsor several open source projects. We host several hundred Ruby on Rails websites, and work 24x7x365 to see that the needs of our customers are met. We’re working hard and employing a lot of hard working Rubyists to make Ruby application deployment a no brainer for current and future Ruby and Rails application owners. We have exciting new projects coming soon that will make deployment easier and simpler than ever before.

It’s clear that you also take an interest in Ruby and Rails application deployment.

Do we have to agree on what stack is ideal to be friends? I, for one, hope not.

This uptick in interest seems to be related to support and comments from DHH himself. We’re in 100% agreement and we’ve been living it for 2 years!

However, I think there are some issues that need to be discussed with respect to Passenger. I felt compelled to discuss them at this time due to this post to Twitter today.

First, if you’re running a single Rails application, Passenger in and off itself offers little advantage compared to other common deployment methods such as the nginx + mongrel stack that we’ve been using and developing for two years. It’s certainly not substantially faster or more efficient, thought it does offer simpler configuration, particularly so if you have access to a system where Apache is already up and running.

If you’re running multiple Rails applications, and are using Passenger’s ability to serve more applications than applications processes, you need to be aware of the performance of requests requiring an application process switch from one application to another. First requests are always slow, as a *lot* of code needs to be heated up, etc. Over ten years ago I learned personally that it’s far easier to manage static environments compared to dynamic environments for one simple reason: When things are changing dynamically, it’s hard to understand why things are behaving the way they are. The issues I’m discussing are generally acceptable in a situation where you have many low traffic applications, and you need to run those applications in a very limited environment. At Engine Yard, this is a very rare need for our customers, so this makes us less anxious to switch to something new -vs- something that is proven and works well.

With the additional of Ruby Enterprise Edition, however, it *does* offer the additional advantage of memory savings. Some of those advantages are lost by having to run Apache, which as commonly delivered, is considerably larger and less efficient than nginx. Of course, you can reduce these disadvantages by cuting down a custom build and tweaking the included modules, but once you’re headed down that road, the simplicity advantage has left the building. :-)

The reason that I felt compelled to respond to Pratik’s Twitter post is that it entirely ignores a few issues that prevent Engine Yard, and no doubt other companies from immediately supporting Passenger™ and/or Ruby Enterprise Edition.

First, Engine Yard uses 64 bit environments to allow our customers the highest performance virtual machines and access to large memory spaces when needed. Just today Phusion has introduced a version that should fix these issues. Before *today*, Engine Yard *could not* support this combination, it’s just that simple, no FUD intended.

Second, our customers choose Engine Yard for experience and expertise in hosting Rails applications. At this moment, we have no experience or expertise in Passenger™. That is a fact.

All in all, I think that Phusion’s Passenger and Rails Enterprise Edition products are interesting. So interesting, in fact, that we chose to investigate the same basic strategy with respect to Rubinius. I’m not yet certain that a substantially patched version of the Ruby source code, maintained independent from the core team, is something that can be supported in the near term, though it’s clear from the drumbeat and experiences of users that the trajectory is looking good.

I’m certainly hoping and encouraging the Ruby core team to work with Phusion to accept their GC patches into the mainline.