Posted in Design, Development by MB on 01/16/08
Recent news followed by my pithy remarks.
The (ever) Daring Fireball and Paul Boutin at Slate are lamenting the fact that the newly announced Mac sub-notebook doesn’t have some manner of cellular EVDO type of use-anywhere-networking-just-like-the-iPhone support. A quote:
Like me, Boutin was hoping for ubiquitous wireless networking. The more I think about this, the more certain I am that it’s just silly that my phone always has a network and (as of yesterday) knows where it is, but my Mac doesn’t.
While, yes, it may in fact be technically feasible to incorporate a cellular card into a skinny little laptop and offer the same clever network switch-a-roo technology that is in the iPhone, that doesn’t mean it’s a good or profitable idea.
To rebut this point: It’s a laptop, not a phone! Do you need your TV to geo-locate? How about your printer? Maybe your microwave?
To rebut in a slightly more classy fashion, Consider the two following use cases:
I’m going to wager that case 1 is the most common. I can remember at least a few times I’ve been in just that predicament. This is why the iPhone has a Google Maps application with a location feature.
If case number 2 is happening to you often enough to consider a laptop upgrade, perhaps you need to switch to decaf.
Paul Boutin, in his article, posits the scenario where he’s riding shotgun in a car, and wants to help the driver with directions, so he wants to dig around in his bag and boot up his laptop instead of picking up a cellphone and calling for directions. This strikes me as an edge case.
I think that is what Apple thinks too. Yeah, they could do it. But why?
There are hard-core super road warriors who need connectivity everywhere. But these guys are (a) a small market and (b) are purchasing “pro” versions of laptops and plugging in whatever wireless provider’s card they need.
There’s a laundry list of other reasons why this is a dumb idea for this particular computer:
I see three big markets for the MacBook Air, in descending order:
It started here:
http://blog.dreamhost.com/2008/01/07/how-ruby-on-rails-could-be-much-better/
And went here:
http://www.al3x.net/2008/01/shared-hosting-is-ghetto.html
Link number one - the author, a tech at Dreamhost (where I host my web sites), writes a constructive article detailing the difficulties they encountered in trying to support the Ruby On Rails framework. Also, he articulates his opinion that if the Rails community could standardize their hosting and deployment practices - or at least provide a set of best practices that can be easily repeated - and make it easy to deploy in shared hosting environments, it would really benefit Rails developers (to provide cheap hosting environments for learning and development) and help promote Rails as a technology.
These are true statements, with which I agree completely. (They are also born out by tales of woe I’ve heard myself from folks who tried to manage their own Rails environment, on their own servers.)
Link number two: Rails dude gets snippy and calls shared hosting a ghetto (in reference to an article by an ex-Rails developer) and misses the point entirely. This second article makes points about how Java and Python have stayed away from shared hosting (not entirely true). He then proceeds to discuss his preference for the “nightmare” of setting up his own server versus the nightmare setting up a shared server (pick your poison, I suppose).
He concludes by incorrectly identifying a popular hosted PHP application as a Rails app and trying to argue that shared hosting wouldn’t make him any money. Oh. Well then. Point made, I guess.
Dallas Kashuba at the Dreamhost blog is correct. Rails is very troublesome to host and deploy. This problem - regardless of whether the hosting is in the shared hosting ghetto or in your personal server farm - is still a problem and a deal-breaker for a lot of people. It certainly was for me. Getting all snippy doesn’t change that fact.
The Michael Barrett Professional Opinionâ„¢ is that Ruby on Rails is all sizzle and no steak. The development problems it solves are only solved if you’re starting with a fresh, clean, empty database; have no legacy systems or data to integrate to, and have lots of time to babysit a server.
Call me when RoR reaches version 3, 4, or 5. Maybe we’ll try again.
No Responses