All posts tagged ‘APIs’

File Under: JavaScript, Location

‘Hyperlapse’ Turns Google Street View Into Beautiful Short Movies

Hyperlapse: turning Google Street View into movies. Image: Screenshot/Webmonkey.

Hyperlapse is quite simply the coolest thing we’ve seen on the web in quite a while. Not only is it creative and beautiful, it’s a great reminder that there are still a few APIs left out there that allow you to make cool stuff.

Hyperlapse is a JavaScript library that stitches together Google Street View imagery to create short “hyper-lapse” movies (time-lapse movies with movement).

The code behind Hyperlapse consists of Hyperlapse.js, Mr Doob’s Three.js and “a modified version of GSVPano.js“. The project is the brainchild of Teehan+Lax, the same design firm that built the interface for Medium.

The site uses WebGL, so you’ll need a modern browser like Firefox or Chrome to see it and create your own.

The only thing Hyperlapse is missing is an easy way to embed your custom Hyperlapses in another page. In lieu of an actual Hyperlapse, here’s a video showing what’s possible.

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:

File Under: Browsers, HTML5

Security Flaws Force Firefox, Opera to Turn Off WebSockets

Firefox and Opera have both disabled support for HTML5 WebSockets in the latest builds of their respective browsers. The move comes on the heels of a protocol vulnerability that could leave thousands of sites harboring malicious code.

New in HTML5, the WebSocket protocol enables a key mechanism found in modern web apps, allowing servers to independently send data to a client browser without the need for page refreshes or complex JavaScript. The most immediate use for WebSockets are apps that rely on full-duplex communication channels, like web-based chat tools and other real-time sharing apps.

Unfortunately, flaws in the WebSockets protocol also make the current spec easy to exploit.

The vulnerability was discovered by Adam Barth, who has demonstrated that a serious attack against the protocol could poison caches that sit in between the browser and the internet. That means, for example, a common JavaScript file like a Google Analytics script, could be replaced on a cache with a malware file.

As Mozilla’s Hacks Blog notes, the exploit doesn’t just affect browsers implementing WebSockets, but also Flash and Java. As the blog post says, “to avoid a lot of malware showing up without being easily traceable, we need to fix the protocol.”

Details of the exploit can be found in Barth’s paper [PDF link] and a series of messages to the Internet Engineering Task Force mailing list. Fortunately there appears to be a solution, but it will require rewriting some of the WebSockets spec.

However, until that solution is implemented both Mozilla and Opera have disabled support for WebSockets. Mozilla expects other browser to follow suit, though so far Opera is the only other browser to disable support. WebSocket support isn’t just a feature in desktop browsers either, the recent Mobile Safari upgrade in iOS 4.2 added support for WebSockets.

So far neither Adobe, which makes the Flash Player plug-in, nor Oracle, which oversees Java, have addressed the issue.

If you’ve been experimenting with WebSockets, be aware that the as of Firefox 4 Beta 8 (due in the next few days), Mozilla will no longer support your code. Neither will Opera 11. We really don’t expect this to be a long-term issue, so if you want to continue testing apps based on the nascent protocol, you can re-enable the features by changing a hidden preference in Firefox and Opera.

Photo by Andy Butkaj/Flickr/CC

See Also:

File Under: Databases

Open Data’s Access Problem, and How to Solve it

The recent Gov 2.0 summit in Washington D.C. saw several promising new announcements which will help government agencies share code and best practices for making public data available to developers.

The idea behind new projects like, the FCC’s new developer tools and the Civic Commons is that by giving developers access to data previously stored in dusty filing cabinets, they can create tools to give ordinary citizens greater access to that data.

Unfortunately, not everything open data project leads to good things. It is critical that if open data is made available on the web, it must be accompanied by some effort to ensure everyone can access it.

We’ve seen an explosion in creative hacks that use this newly available data to provide excellent online resources. Public data sites like EveryBlock, or the Sunlight Foundation’s Design for America contest have highlighted some of the amazing ways open data can make our lives better. Whether it’s finding out crime stats, real estate values, health hazards and business license statuses in your neighborhood, or visualizing how the government is spending your tax dollars through innovative maps, open data and what you can do with it is the current hotness among web developers.

Most of the benefits are close to home — in the U.S., just about everyone has access to online government resources thanks to web-enabled computers in free public libraries.

But extend that argument to the rest of the world and the number of people that really have access to the data drops significantly. If you don’t have an easy way to get online, you can’t benefit from open data.

Michael Gurstein, Executive Director of the Center for Community Informatics Research, recently highlighted some of the problems with open data accessibility.

Gurstein points out a number of assumptions about open data that are often overlooked by those most enthusiastic about making such data publicly available.

Worse, he shows how such data can be used against you.

Continue Reading “Open Data’s Access Problem, and How to Solve it” »

File Under: Fonts, Web Apps

Test Drive Your Type With Google Font Preview

Google launched a new web-based tool Wednesday that helps you configure, test and easily embed one of the company’s free fonts into your web pages.

The Font Previewer lets you pick one of the open source fonts from Google’s Font Library, then tweak the size, spacing and decorations using simple sliders and buttons. Once you have the type the way you like it, just copy the provided code and paste it into the CSS.

It’s so ridiculously easy, even I was able to use it to change the h1 style on my personal site in about 2 minutes. I chose Pablo Impallari’s Lobster.

Google first took the web font plunge back in May by releasing the Google Font API and publishing a collection of free, open source fonts anyone can use in their designs for free. It also joined up with Typekit (who released an API today) to put together a JavaScript library for designers to control how and when their fonts are loaded.

The fonts in the Font Previewer are the same ones available through the Google Font API. They are quite nice, with a range of script, serif, sans-serif and monospace typefaces. The various typefaces used on the Android devices (Droid), and the old-timey one from Mark Pilgrim’s Dive Into HTML5 site (IM Fell) are part of the package.

Here’s Google’s announcement with some more info.

See also: