File Under: CSS, Humor, JavaScript

Blow Up the Web With ‘Font Bomb’

Wired.com Font Bombed. Image: Screenshot/Webmonkey.

We’ve already showed you how to turn any webpage into a game of Asteroids; now you can add Font Bomb to the list of ways to destroy text of the web.

Font Bomb is a fun little JavaScript bookmarklet you can use to plant bombs all around a webpage. Just drag the bookmarklet to your bookmarks bar and then head to a page you want to destroy. Click the bookmarklet and then start clicking anywhere on the page to plant bombs.

Then, thanks to a little magic from CSS 2D Transforms, the text starts flying — perfect for a little Friday afternoon amusement. (It’s also not a half-bad way to take out some frustration on trolls: Don’t feed them, just blow up what they wrote and move on.)

Font Bomb was created by Philippe-Antoine Lehoux. The code is available on GitHub (CoffeeScript) and there’s some discussion on Hacker News if you’d like to know more.

File Under: Browsers

Opera’s ‘SPDY’ Sense Tingling in Labs Release

Photo: dark_ghetto28/Flickr

The latest Labs release of Opera’s flagship desktop web browser adds support for the nascent SPDY protocol.

You can download the latest Opera Labs build for Windows 32-bit, Windows 64-bit, Mac and Linux from Opera.

SPDY, pronounced “speedy,” is a replacement for the HTTP protocol — the language currently used when your browser talks to a web server. When you request a webpage or a file from a server, chances are your browser sends that request using HTTP. The server answers using HTTP, too. This is why “http” appears at the beginning of most web addresses.

The SPDY protocol handles all the same tasks as HTTP, but SPDY can do it all about 50 percent faster.

SPDY started life as a proprietary protocol at Google and worked only in the company’s Chrome web browser. SPDY has since won support elsewhere, with Firefox and Chrome already shipping with SPDY built-in.

Opera hasn’t announced when SPDY support will arrive in the stable release, but when it does the majority of browsers on the web will support the SPDY protocol. The major missing player is Microsoft, which has proposed a slightly different take on the same ideas behind SPDY. Which one becomes an official standard is up to the Internet Engineering Task Force (IETF), which is in the process of creating HTTP 2.0, a faster, modern approach to internet communication.

To notice any SPDY-related speed improvements in the latest version of Opera Labs you’ll have to connect to SPDY servers. Although not yet widespread, SPDY is already enabled on some very large sites, including Google’s main search page, Gmail and Twitter among others. Also, note that you don’t need to type spdy://somesite.com. When the browser uses SPDY it all happens transparently behind the scenes.

If you’d like to get your own site serving over SPDY, check out mod_spdy, a SPDY module for the Apache server (currently a beta release) or read up on Nginx’s preliminary support.

Give Us 15 Minutes, and We’ll Give You Git

Git is in your browser, versioning your files. Image: Screenshot/Webmonkey

If you’ve got 15 minutes to spare you too can learn Git, the distributed version control system that powers everything from NASA code to Wired articles.

That’s the promise of a new collaborative effort between GitHub and Code School, who have partnered to create Try Git — a way for new users to try out both Git and GitHub right in the web browser, no software installation necessary.

Much of Git’s success is due in part to its awesome documentation and numerous extra free resources — like Scott Chacon’s Pro Git book — which explain Git in great detail. But nice as those resources are they still require installing software before you can get to the hands-on learning.

Try Git skips the installation and puts a Git prompt right in your browser. It’s still a command line prompt, which might scare away some users, but it’s paired with step-by-step instructions and a visual representation of a Git repository, along with some tips and tricks for figuring out Git.

The Try Git tool also neatly integrates with GitHub. There’s no need to use GitHub — though it does offer some great hosting tools — but the Try Git site interacts with GitHub via OAuth and will push your tutorial repository to your GitHub account as a repo named try_git.

File Under: Web Services

Google to Shut Down iGoogle

Image: THOR/Flickr

Google is cleaning house again. This time the company is shutting down five services.

Google has a long history of unceremoniously killing off its less-used services, having previously axed once-high-profile efforts like Wave, Buzz, Knol and Gears, among others.

The most notable Google service on the chopping block this time is iGoogle, the company’s customizable homepage. Similar to Netvibes, MyYahoo or the now defunct PageFlakes, iGoogle was a dashboard for the web, allowing users to embed gadgets like weather, email and news.

When iGoogle first launched in 2005 it was something of a me-too effort, duplicating features found in other services, but adding numerous Google-centric gadgets. Eventually iGoogle’s gadget selection grew to encompass everything from feed readers to web-based games.

Citing the growth of mobile and web apps that “put personalized, real-time information at your fingertips,” Google says “the need for iGoogle has eroded over time.”

Fans of iGoogle don’t need to panic just yet, Google doesn’t plan to completely shut the service down until November 1, 2013. Presumably Google sees Google+ as a replacement. Other alternatives include Netvibes and PageFlakes, which both offer similar widget-based dashboard home pages. [Update: PageFlakes ceased operation in January 2012. Other possible replacements for iGoogle include UStart and ProtoPage.]

The other four services on Google’s spring cleaning shortlist include a Symbian search app, Google Talk Chatback (an embeddable Google Talk widget), Google Video, which long ago stopped taking new uploads, and Google Mini, part of Google’s enterprise search service.

File Under: APIs, Web Services

It’s Time to Build a Twitter-Free Twitter

Image: Twitter.

Twitter dropped a bombshell on third-party application developers last Friday — the social network built on the backs of third-party developers and clever, innovative clients has decided it no longer needs them.

Twitter’s blog post is short on specific details, but the gist of it is that Twitter is tightening up its API access for third-party developers. The company has long viewed third-party apps as unnecessary and previously warned developers not to “build client apps that mimic or reproduce the mainstream Twitter consumer client experience.” But thus far it hasn’t enforced that guideline. Now it seems it will.

In a post on the Twitter developer blog titled Delivering a consistent Twitter experience, Michael Sippey, Twitter’s director of product, seems to say that the company wants its official clients — and only its clients — to be the way people use Twitter. Instead of building clients that pull out of Twitter, the company wants developers to “build into Twitter.” In other words, kiss your Tweetbot, Twicca or Hibari goodbye and get ready for some embedded widgets instead of good ol’ tweets.

Much digital ink was spilled over the weekend denouncing Twitter’s policy change or lamenting the potential loss of alternative Twitter clients. Of course Twitter is in charge of Twitter and when you use its service — or build apps on its API — you must suffer its whims.

But Twitter’s decision to start enforcing its API restrictions “more thoroughly” could end up a great thing if it inspires developers to take the essence of what makes Twitter great — succinct, timely messages to and from your friends — and free it from Twitter the company.

An independent and decentralized equivalent to Twitter is certainly not a new idea. The basic building blocks you’d need to build such a system have been with us for many years — a combination RSS, OPML and perhaps PubSubHubbub would cover of most of it — but until now there hasn’t been widespread client developer support for such a system. After all, why go to all the trouble of building a decentralized network on top of open web standards when using the Twitter API is so much easier?

Twitter’s third-party developers now have the answer to that question — because you can’t be locked out of the open web.

Developer Brent Simmons, perhaps best known for creating the Mac-based RSS reading app NetNewsWire, has a basic outline of how Twitter app developers could band together and make something that not only sidesteps Twitter’s coming API restrictions, but the service itself.

“The interesting (to geeks like us) part,” writes Simmons on his blog, is “what system that works like Twitter could exist without a company behind it?”

Simmons then proceeds to break Twitter down to its essentials: “under the hood, following somebody is really just subscribing to a feed of their statuses. Posting is really just updating a feed of your own statuses. So you standardize on a feed format. RSS would work great, of course, and there’s a ton of RSS reading and writing code out there already.”

Instead of Twitter clients, what you’d really be building is a real-time RSS client. That’s not a far-fetched idea. Dave Winer, the forefather of blogging and creator of RSS, has been building one for years. (He’s also been telling everyone to build a distributed Twitter-like publishing system for years.)

Simmons doesn’t address it directly, but it’s worth noting that building such a system doesn’t preclude using Twitter. It’s not either/or, it can be both. In this scenario you’d write a post in a client like Tweetbot and Tweetbot could automatically send it Twitter and to your own feed. Start with both and then a migration away from Twitter would be smoother. Those that want to dump Twitter immediately could do so, but still keep posting to anyone with a client that supports the open structure. Then, if Twitter really does cut out third-party apps completely, the infrastructure necessary to support an open alternative is already up and running.

Simmons has more details for developers on his blog and in a follow-up post that delves more into the logistical complexities, but the basic message to developers is simple: Twitter’s changes means you need to find a better network for your clients to use.

The better network is the one that’s always been there — the web. The advantage for app developers feeling threatened by Twitter’s API changes is obvious. As Simmons writes, “there’s a practical reason to use the open web: your app can’t be shut down.”

The question is, if there were an open alternative would disgruntled Twitter users embrace it? The main argument against any alternative is the so-called network effect: Everyone I know is on Twitter; why would I go somewhere else? But not too long ago no one used Twitter and everyone used Myspace. Everyone used Friendster. Everyone use AOL. People change; networks move. A distributed version of Twitter sans Twitter might well be the web to Twitter’s AOL, but there’s one certainty: We’ll never know until we build it.