Archive for the ‘Web Apps’ Category

File Under: HTML5, Multimedia, Web Apps

Angry Birds Attacks Web … Web Wins

Angry Birds, currently one of the most popular games for iOS, Android and other platforms has made the leap to the web. Rovio, the company behind the game, has unveiled a web-based version of Angry Birds at Google’s I/O conference in San Francisco.

You can install the new Angry Birds for the web as an app in Google’s Chrome browser, or just play from the URL, chrome.angrybirds.com, which works just fine in any modern web browser. Just don’t hit that link if you’re planning to get any work done today.

Behind the scenes, the web incarnation of Angry Birds is powered primarily by HTML5. However, if you happen to have ditched Flash, you’ll notice that Angry Birds on the web won’t work.

What’s interesting is that the offending code appears to use gwt-voices, a cross-browser audio shim from Google. In theory gwt-voice only falls back to Flash when needed, but using the Aurora release of Firefox brings up a “You need to install Flash Player” message for Angry Birds (most likely because Firefox does not ship with mp3 support).

Calling Angry Birds an HTML5 app, is, in that regard, somewhat of a stretch.

Still, the primary rendering and logic of the game does use HTML5 elements like canvas, and HTML5 APIs like localStorage. The latter is interesting because it makes Angry Birds on the web hackable.

As per Rovio’s releases on other platforms, Angry Birds for the web offers in-app purchases for additional playing levels. But because Angry Birds uses the localStorage API, a clever dose of JavaScript will, at the time of writing, unlock the extra levels sans payment.

Welcome to the web, Angry Birds, where everything is hackable.

See Also:

Lessons From a Cloud Failure: It’s Not Amazon, It’s You

Chaos Monkey will eat your cloud.

Amazon’s cloud-hosted Web Services experienced a catastrophic failure last week, knocking hundreds of sites off the web. Some developers saw the AWS outage as a warning about what happens when we rely too much on the cloud. But the real failure of Amazon’s downtime is not AWS, but the sites that use it.

The problem for those sites that were brought down by the AWS outage is the sites’ own failure to implement the one key design principle of the cloud: Design with failure in mind.

That’s not to say that Amazon didn’t fail rather spectacularly, taking out huge sites like Quora, Reddit, FourSquare and Everyblock, but as Paul Smith of Everyblock admits, while Amazon bears some of the responsibility, Everyblock failed as well:

Frankly, we screwed up. AWS explicitly advises that developers should design a site’s architecture so that it is resilient to occasional failures and outages such as what occurred yesterday, and we did not follow that advice

But perhaps the most instructive lesson comes from those sites that were not affected, notably Netflix, SimpleGeo and SmugMug. Netflix published a look at how it uses AWS last year and, by all appearances, those lessons served the company well, because Netflix remained unaffected by the recent failure.

Among Netflix’s suggestions is to always design for failure: “We’ve sometimes referred to the Netflix software architecture in AWS as our Rambo Architecture. Each system has to be able to succeed, no matter what, even all on its own.”

To ensure that each system can stand on its own, Netflix uses something it calls the Chaos Monkey (no relation). The Chaos Monkey is a set of scripts that run through Netflix’s AWS process and randomly shuts them down to ensure that the rest of the system is able to keep running. Think of it as a system where the parts are greater than the whole.

The photo sharing site SmugMug has also detailed its approach to designing for failure and why SmugMug was largely unaffected by the recent AWS outage. SmugMug co-founder and CEO Don MacAskill, echos Netflix’s redundancy mantra, writing, “Each component (EC2 instance, etc.) should be able to die without affecting the whole system as much as possible. Your product or design may make that hard or impossible to do 100 percent — but I promise large portions of your system can be designed that way.”

MacAskill also has strong words for those who think the recent AWS outage is a good argument for sticking with your own data center: “[SmugMug's] data-center related outages have all been far worse … we’re working hard to get our remaining services out of our control and into Amazon’s.”

“Cloud computing is just a tool,” writes MacAskill, “Some companies, like Netflix and SimpleGeo, likely understand the tool better.”

If you’d like to learn more about how designing for cloud services differs from traditional data-center setups, check out this excellent post on O’Reilly. Also, be sure to read Netflix’s advice and learn from Everyblock’s downtime by following the guidelines in Amazon’s own documentation.

Photo: Technically not a monkey. (DBoy/Flickr/CC)

See Also:

File Under: HTML5, Multimedia, Web Apps

YouTube Begins Serving Up Native WebM Video

YouTube has announced it will begin offering HTML5 videos in the WebM codec to web browsers that support it. So far YouTube says that it has encoded 30 percent of its videos in WebM, which accounts for 99 percent of all traffic to the site.

YouTube’s move to WebM is no surprise; Google has already dropped the competing H.264 codec from its Chrome web browser and it was only a matter of time before YouTube began moving to WebM as well.

The WebM Project, a partnership between Google, Mozilla, Opera and dozens of other software and hardware makers, provides web developers a way of embedding video and audio in HTML5 pages without plug-ins, and without the need to pay the expensive licensing fees that surround the competing H.264 codec. Currently WebM video works in Firefox 4, Chrome, Opera and Internet Explorer (via a plugin). The other main HTML5 video codec, H.264, works on all Apple devices and in Internet Explorer 9.

While YouTube is adding WebM support, it isn’t following Chrome’s lead and dropping H.264. The site will continue to serve up H.264 video to those browsers that support it (in other words, Safari, Mobile Safari and Internet Explorer 9).

Despite the new WebM support, YouTube still isn’t serving up HTML5 videos by default. If you’d like to get in on the new WebM fun, you’ll still need to sign up for the opt-in HTML5 player.

See Also:

Thousand of APIs Paint a Bright Future for the Web

ProgrammableWeb's stat for API protocols and data formats

Once a novel idea that seemed limited to Flickr, the web-based API is now everywhere you turn — Twitter, Foursquare, Google Maps and thousands of other sites offer up their data in the form of an API.

APIs mean that third-party developers can build their own tools and mashups, which in turn helps to fuel the popularity of the web service. It’s hard to imagine where sites like Flickr and Twitter would be today without APIs.

In fact, these days some web services don’t even bother launching websites to go with their APIs — the API is the service. The SimpleGeo API, for example, doesn’t really have a corresponding website, it’s just an API that can be used anywhere, including inside mobile apps.

And APIs aren’t just something for external developers anymore. Increasingly web services are building their own sites and tools around their APIs — after all, why bother with an API if you aren’t going to use it yourself? Twitter is a good example of the “eat your own dog food” approach to APIs; Twitter’s website and its mobile clients are both developed off the same Twitter API that outside developers can tap into.

Former Webmonkey writer Adam DuVander, now Executive Editor at ProgrammableWeb, recently announced that ProgrammableWeb, an API tracking site, now lists some 3000 web-based APIs. To go along with that milestone DuVander breaks down some of the trends in today’s APIs.

It will come as no surprise to those actively developing or using APIs, but the overwhelming trend in APIs is moving toward serving JSON data over a REST interface. As DuVander notes in his post, how many “REST APIs” are truly RESTful is debatable, but certainly SOAP is on its way out and HTTP coupled with OAuth is the future.

When it comes to the data APIs serve up, XML is still the most used format, but JSON is hot on its heels and growing much faster. Even though there are still more XML APIs, the more recent the API, the more likely it’s serving JSON. In many cases — like Twitter’s streaming API and Foursquare’s updated API — companies are rapidly moving from XML to JSON.

The biggest thing that sticks out from ProgrammableWeb’s API trends is that the API, once a sort of “hey, that’s cool” option for progressive websites, is now a first class citizen of the web. Perhaps eventually something better than the REST/OAuth/JSON combo will come along, but the the API and the idea behind it — making data available to the entire web — isn’t going anywhere.

See Also:

Yahoo Plans to Kill Off Delicious Bookmarking Service

According to a leaked photo, Yahoo plans to close a number of services, including Yahoo Buzz, MyBlogLog and Delicious, the popular bookmarking site.

Most of the closing services are Yahoo projects that simply never went anywhere, but Delicious, which Yahoo acquired in 2005, was once the king of bookmarks and helped popularize many of the key elements of today’s social web.

Delicious (Del.icio.us in its original incarnation) popularized tags as a more flexible alternative to folders, introduced us to the idea of following other users and helped kick off the “share it with the world” trend that created today’s social websites like Twitter and Facebook.

Under Yahoo’s leadership Delicious ceased to be innovative. Delicious remains a useful service, but it hasn’t really improved on its original features in almost half a decade.

It’s unclear what will happen to Delicious. So far Yahoo hasn’t made any official announcement, nor has the company given any hint of when or how Delicious will head into the sunset, but one thing is for sure: the web will be poorer without it.

Fortunately for Delicious users its impending demise doesn’t mean your bookmarks will disappear forever. It’s actually quite easy to export your bookmarks, and there are dozens of services that can import them and replace Delicious in your workflow.

I’ve been a heavy Delicious user ever since the demise of its competitor Ma.gnolia. I bookmarked sites, scraped the API and stored the bookmarks on my own server (you can find the details of those scripts in our Django tutorial). I also relied on feeds from other people to find news, links and other tidbits for Webmonkey.

The first part of that workflow is easy to replace. I signed up for Pinboard.in, which lacks some of Delicious’ sharing features, but offers a mirror of the Delicious API. I imported my Delicious bookmarks into Pinboard, changed the root url in my scripts and effectively replaced Delicious in less than 10 minutes. If you don’t want to pay for Pinboard, Zootool, StumbleUpon and other services also make fine Delicious replacements.

But Delicious isn’t just a bookmarking service, it’s a fantastic resource for finding links, stories and the latest news about nearly anything that interested you. Its popularity make its reach extensive. You can easily tap into the minds of friends, colleagues and strangers to see what they’re reading on the web. The concept of tags makes it easy to find links related to any topic or combination of topics that interests you.

ReadWriteWeb’s Marshall Kirkpatrick likens the impending death of Delicious to “setting a museum on fire.” Where, asks Kirkpatrick, “are you going to find a reading list of the best collected written works and other multimedia about almost any given topic?”

Put simply: nowhere.

Twitter is a possibility. Delicious even used Twitter for some of its real-time search features. But Twitter isn’t dedicated to links the way Delicious is so you’ll have to put up with a lot more noise to find the same stories. Facebook may fill the gap for people. It’s also possible that Pinboard or another service will grow in the wake of Delicious’ collapse and come to offer a similar depth and breath of links.

Exactly what will happen to all those links currently stored on Delicious remains to be seen. It’s possible Yahoo may sell off Delicious, but in the absence of a statement from Yahoo, many users have already assumed the worst.

Hopefully Yahoo will at least keep the Delicious domain active, even if the service is not. Perhaps the Archive Team — which saved Geocities from death at the hands of Yahoo — can scrape and mirror Delicious.

For those that have only vaguely heard of Delicious and don’t see what the fuss is, just re-read the above replacing the word Delicious with the word Flickr or even Facebook. This is the template I’ll be using five years from now when Facebook meets the same fate.

See Also: