Posted on August 31, 2007 by Joel Potischman

Law of Unintended Consequences, Abbreviated

Do you accept Jesus Christ as your personal savior and LinkedIn contact? (Not photoshopped)

Permalink | Comments (1) | Technorati Tags :

Posted on August 21, 2007 by Avi Flax

Moviestar: Big Step Towards Flash on iPhone

I've believed for a while now that Flash is coming to the iPhone, sooner or later - emphasis on sooner. Today's announcement and beta release of Moviestar make me feel even more certain.

Here's why I think Flash is coming to the iPhone:

Apple wants it. Steve Jobs has referred to the Internet experience with the iPhone as "The Real Internet". For better or for worse, today that means Flash content. Until Flash is built-in to the iPhone, it only offers most of "The Real Internet". If it's not the same experience you can get with Firefox, IE, or Safari, it's not "The Real Internet". (Can you tell that I don't love that phrase?) Jobs knows this. Flash on the iPhone = more iPhones sold.

Adobe wants it. Flash's reach and market penetration are a bragging point, and a source of clout. They want people developing Flash sites and apps for the iPhone, so they can sell more copies of Flash and Flex Builder and so the patina of the iPhone rubs off on them. Everyone wants piece of the iPhone pie, and adobe isn't immune.

Apple and Adobe are tight. Their goals are aligned, and they know how to work together.

Walt Mossberg says so.

At launch, the iPhone version of the Safari browser is missing some plug-ins needed for playing common types of Web videos. The most important of these is the plug-in for Adobe's Flash technology. Apple says it plans to add that plug-in through an early software update, which I am guessing will occur within the next couple of months.

The technical hurdles are fixable. The primary hurdle is CPU usage, and along with it, battery life. This is fixable. H.264 encoding goes a long way toward fixing this, because the iPhone includes a hardward H.264 decoder. Hardware decoding is way more efficient than software decoding, and video is a large portion of usage of Flash in today's web. MobileSafari's JavaScript engine also demonstrates that some minor tweaks to a scripting engine can help prevent badly coded scripts from sucking precious watts. I wouldn't be surprised if Adobe made similar modifications to Tamarin for the iPhone.

The Flash player dev team is on a roll. Version 9 is a huge success, and ActionScript 3 is a great language. They haven't rested on their laurels either: since v9 was released for Mac and Windows, they've released a bevy of improvements, such as full screen support, today's H.264 support, and support for other platforms, such as Linux and the Wii. Do you really think it'd be a big deal for them to dev a iPhone build with some CPU-saving customizations? I think not. The iPhone, after all, is essentially a Mac running customized versions of OS X and Aqua and some novel hardware. For an example of the competence of the team members, see Tinic Uro's What just happened to video on the web? or Mike Melanson's blog Penguin.SWF.

Apple's Customers Want It. This is last because I think it's actually the least important - for better or for worse, Apple doesn't have a great track record of implementing features just because customers ask for them. Anyway, people who buy the iPhone so they can use "The Real Internet" are going to be annoyed when they find that some sites just don't work, or work partially, or look different. (Regular, non-geek people, that is. Geeks already know Flash isn't supported, so while they may be disgruntled, they aren't surprised.)

If there are so many reasons why, you might be wondering: what's taking so long? The basic answer: it's important enough to both Apple and Adobe that they're taking the time to do it right. While I've already explained why I think it'll happen, and why the hurdles are jumpable, I'm not saying it's easy. Apple in particular has a lot to lose. They need to tread lightly with iPhone stability and battery life. It's a phone, not a computer, and people have very high expectations of stability and availability for a phone - far more than a computer. One risky software update, a couple of hundred phone crashes, and the media could jump on the issue in an iFeedingFrenzy. (Yes, I know the iPhone technically is a computer, I use it here as it's used on the street, to mean a general-purpose system, which are historically not completely stable.)

So that's my prediction. And who knows, after Flash, we might even see two-click application installation on the iPhone with AIR.

Permalink | Comments (9) | Technorati Tags :

Posted on August 17, 2007 by Josh Diehl

Here Comes the Hammer

There's a problem with falling in love with a new technology: it starts to look like a hammer. And when you're holding a hammer everything starts to look like a nail. That was where I found myself after being introduced to Amazon's EC2 "cloud computing" technology at a recent NY Tech Meetup. I started to look at every software problem, and in fact every technical problem with an eye toward "how can I solve this with EC2?". Need a hosting solution? Do it with EC2. Rip some tracks from CDs? I'm sure there must be a way to do that with EC2. My internet connection at home seems slow...EC2 must be able to help me somehow. Sadly I don't think EC2 is going to help me download Lost episodes from abc.com faster any time soon, but what it can do is impressive.

I had heard EC2 and cloud computing mentioned in a few articles and blog posts but paid it no mind. "Cloud computing" to me was useful only for the kind of work done by huge computational efforts like SETI@home's search for extraterrestrial life or Folding@home's work on understanding disease. "Give me the square root of 853789548795598", etc. Egghead stuff. So it was a smart move on Amazon's part to fly their web service evangelist Jinesh Varia from Seattle to New York to make a 7 minute presentation on EC2, because without it who knows how long it would have been before I discovered the truth of EC2. In a nutshell, Amazon is giving you root access to a Virtual Private Server that can be customized and replicated on other EC2 VPS's at will. Login, install software, save system image, replicate. Wow. I've never seen app hosting so close to "just add water". I went home and immediately signed up for an Amazon web service account.

Signing up and getting started with EC2 was staggeringly easy. The first thing Amazon did right was to structure their pricing so as to have zero barrier-to-entry. The cost is essentially $0.10 per server-hour. No startup fee. If you want to see what the hype is all about, by all means set up an account and play around for three hours. Your bill? A staggering $0.30. The second thing they did right was to provide an extremely well-written getting started guide. Somebody at Amazon realized that a great service won't pick up adopters if learning how to use it is difficult. They also provide several pre-made system images (all running Fedora Core 4 Linux) which you can instantiate at will. Within 3 hours of signing up I had my own EC2 instance with it's own IP address running Apache and serving up a dinky page I had made.

So my original infatuation aside, what should EC2 be used for? Most obviously EC2 is perfect for scaling applications that require more bandwidth, memory, or CPU power than a single server could practically provide. This is the most obvious use for a distributed computing platform and the one that Amazon seems to be talking up the most. More interesting I think are the somewhat less obvious uses. I very quickly found myself using EC2 for software "what if" scenarios. Software installs, load testing, and architecture experiments are all perfect uses for EC2. I don't have to worry about doing things right the first time because a brand new instance is two minutes away. I can perfect installs, hit an app with a massive barrage of tests, and change system-level configuation all in a throw-away environment before doing it somewhere important.

The ability to pack up a server into a nice AMI (Amazon Machine Image) file also creates another opportunity: it takes all the work someone puts into configuring a server and wraps it up for others. Check out a slice of what Amazon lists on their public AMI directory: a Movable Type 4.0 server, an Ubuntu server configured for Ruby on Rails, a Helix DNA server for streaming media. Free software may be free but that doesn't mean it doesn't have associated cost. Amazon clearly recognizes this as their latest API release supports making your packaged AMIs available to others for a price. After spending hours installing software onto a server loaded from their standard bare Fedora images, I can testify that I'd pay for someone else's ready-to-go image so I can focus on the software I'm trying to write.

I'd say the primary limitation of EC2 isn't a limitation of EC2 at all but of the software you install on top. The technical hurdles to running instance after instance are essentially nil, it's the licensing that keeps you from ultimate server bliss. Run all the Linux with Apache you want but as soon as you add proprietary software to the mix the party ends, to the sound of the needle being pulled off a record player that has been used in every movie with a party in it since 1982. There's nothing technical stopping you from creating an image of a Windows server running your ColdFusion app and having it ready to deploy to n servers at a moment's notice in case of serious load. But done by the book the licensing costs of such a strategy quickly make it impractical. EC2 could end up being a huge boon to adoption of open source platforms. As developers and small businesses who have never had the resources to run more than one or two servers can now afford dozens, the choice of open source becomes all the more appealing.

Something else that bares consideration is that you are basing your app on a platform that could arbitrarily raise prices or close down tomorrow, although you face this risk with any traditional service provider. You could find yourself scrambling to buy some servers and get them set up at a colo facility if EC2 computing nirvana disappears with little warning. Still, if the business model is viable Amazon can expect to see competitors cropping up who could offer a place to go if they become less hospitable. This would actually be good for Amazon, as it would validate the investment they've made in the concept and create a sense of safety for those looking to move their apps to this hosting model.

There are other things I'd like to know about EC2. How will Amazon keep spammers and troublemakers from renting EC2 servers for their mischief? What happens in December when holiday shopping pushes Amazon to use more of their spare server resources, does my ability to use EC2 suffer? There are certainly unknowns at this point but everything I've seen with EC2 up to this point shows attention to detail and a clear sense of vision. I'm looking forward to seeing what direction EC2 takes over the next few months. Maybe they'll even figure out how to get me Lost season 4 episodes before they're even produced.

Permalink | Comments (3) | Technorati Tags :

Posted on August 06, 2007 by Joel Nagy

Sometimes you are truly better off starting from scratch

Reuse, Reuse, Reuse is a typical mantra these days, leaving me to wonder if any new ideas are ever written. Now of course I'm being a little sarcastic here, but it seems that the call to reuse code and use as much free code as you can get your hands on is the norm these days. I believe that there are very valid reasons to not only start from scratch but building certain code bases in-house.

The reasons why we often opt for prefab code (or previous incarnations) instead of coding from scratch are varied: our urge to rush to market, hesitation to throw away code, etc. Sometimes we feel that it would be a waste to not reuse old code, or even "why waste our time writing code that someone else already wrote?" Some good reasons why you should write from scratch:

1. Maintenance: Plugging 20 odd libraries from 20 separate sources into a single project can become a maintenance nightmare as they might try to step on each other and may not have been written with the most optimized or clean code.
2. Adding Features: Adding features to some prefab code bases can make the code unmanageable as hacks get frequently introduced to solve a simple issue.
3. Scalability: Do you know for a fact that the old code or the plugged in library will scale? Do you have the time to perform a thorough code walk through of the new code?  If you do you might actually have time to write new code.
4. Use the Right Tool (screwdrivers don't make good hammers): Using old code (especially from legacy platforms written with older languages, such as non-web languages used in a web platform) will result in trying to leap hurdles that newer languages were designed to perform.
5. Learning: There's nothing wrong with trying to figure out how to accomplish a task on your own, in the end you'll be rewarded with the new knowledge and firm understanding of how the code you are using actually works.

Don't take these reasons as "you should always" write from scratch, but sometimes it's just better than using <insert code here> into your next project.

Permalink | Comments (3) | Technorati Tags :

July 2007 | Main | September 2007