The extension is itself is pretty straightforward and tries to address a problem I’ve run into quite a few times. I’ll come across an interesting blogger or website via Hacker News or wherever, and want to add them to my circles on Google+. But first I actually have to find them on Google+. If I’m lucky, they have a visible link or Google+ badge somewhere on the site and I can just that. But some sites (like my own, currently) have only a non-visible link to the associated Google+ profile. This non-visible link is really all Google needs to power author information in search results or direct connect, but doesn’t do much for visitors to a site. And even with a visible link or badge, the design of some sites are so cluttered that the link may be difficult to find.

The +Profile Link extension scans pages as you browse the web looking for links to a Google+ profile. This can be a visible <a> or non-visible <link> element with a rel value of ‘me’, ‘author’, or ‘publisher’, or a Google+ badge. When it detects a link, a small icon appears in the Chrome address bar. When clicked, a popup window displays some basic profile data pulled from the public Google+ API, including a link to the full profile where you can add the person to your circles. I’ve toyed with adding a Google+ badge directly in the popup, but just haven’t been happy with the way it looks so far… that should be coming in the future.

But what about sites that don’t link to their Google+ profile at all? My goal with this plugin was to try and find the associated Google+ profile with a very high degree of certainty, so there’s only so much you can do. One experimental feature I added (which can be activated in the extension’s options page) is to use the Social Graph API to find the Google+ profile for a URL. This actually works pretty well for the very small percentage of people that have rel="me" links setup on their site. For example, this would allow the address bar icon to be displayed even on a user’s Twitter profile page as seen here for Tantek.

Unfortunately, the Social Graph API was recently deprecated and announced that it will be retired on April 20, 2012. If I can find an alternative solution by then I’ll migrate over, otherwise I’ll likely remove this feature. It’s not entirely practical anyway, since it fires off an API lookup for every URL you visit. This has both performance and potential privacy implications, so I’m not sure that I’d recommend that people leave it running all the time. It does provide a nice proof of concept, though.

I’m sure there are plenty of best practices I didn’t follow, but I’m generally pretty happy with how it all turned out. It demonstrates quite a few of the basic functions of a Chrome extension, including:

• background pages
• content scripts
• page actions with a popup window
• a very simple options page
• light use of the tabs and windows APIs
• message passing between the content script, popup window, and background page
• calling remote APIs like the Google+ and Social Graph APIs. Here, I actually just used jQuery to do a JSONP request rather than doing a true cross-origin XMLHttpRequest
• unit tests for much of the code using QUnit

The whole extension is released under the Apache 2.0 license, so hopefully it will be a useful example to a few folks. You can find the extension itself in the Chrome Web Store and the source code on GitHub at willnorris/plus-profile-link.

I’m not interested in building a community or a personal brand, so I really don’t care about capturing engagement here on my site. I do value a lot of the comments I get however, so I’m not looking to cut things off entirely. Instead, I’ve decided to outsource my comments to Google+.

Today we announced the launch of the Google+ API, starting with read access to public data. Using the new API together with the +1 button, I’ve added support to my snowflake to share my posts to Google+, and then to easily direct conversations from my blog to there. It allows me to keep my own home on the web dedicated to just my content, and at the same time leverage the great community that has formed around Google+.

Please try it out yourself, and let me know how it works for you. This was the work of a single evening, so I’m sure I’ll enhance it over time. Please file any bugs or feature requests you have.

https://github.com/willnorris/wordpress-snowflake

A couple of months ago, I mentioned how excited I was to reveal to family and friends what I’ve been working on at Google for the last year or so, Google+. Well, that was only partly true. What I’ve really been working on is the Google+ Platform, which we are finally starting to roll out today.

In many respects, today’s announcement is perhaps more exciting for myself and the team than it will be for some of you. The surface that we are launching today is small, just three methods focused on reading public data. That’s what we’re starting with. You won’t find the ability to post into the stream or +1 a post, or the ability to access a user’s circles. But what you will find is a small taste of what we’ve been working on for a long time. You’ll find a clean and simple API that should feel very natural because it follows RESTful designs and uses JSON data formats. You’ll find an API that uses industry standards like OAuth 2.0 and that is based on open formats like Activity Streams and Portable Contacts. You’ll find well-written documentation with in-line code samples and an in-line API explorer so you can play with every method, all hosted on our new Google Developers site that will redefine what it means to be Google developer. You’ll find an API that is relatively small, but one that is the start of something very, very big.

This is perhaps the most important project I’ve worked on in my professional life, and I’m incredibly proud of what we are beginning today. I’m excited to see what people will build with the API, and I’ll be sharing some of my own Google+ projects very soon.

With git, we’ve invented a new world where revision history, checksums, and branches don’t make your filesystem slower: they make it faster. They don’t make your data bigger: they make it smaller. They don’t risk your data integrity; they guarantee integrity. They don’t centralize your data in a big database; they distribute it peer to peer.

So just to prove that I don’t actually spend all of my time in the belly of the beast, I’m happy to announce a new project I’ve been working on – Hum. It’s a personal URL shortener for WordPress, inspired by Whistle. It’s important to note that this is not a traditional URL shortener like bit.ly or goo.gl that is designed for creating links to any arbitrary site on the web. Instead, a personal URL shortener is intended to link to your own content… your blog posts, your status updates, your photos. When pushing content from your site out to social networks, you often need the ability to link back to the original. Thanks to Twitter this means short URLs, and following DiSo principles, this means controlling those URLs. A URL shortener may not be sexy, but it’s necessary infrastructure for DiSo 2.0.

Hum is like Whistle in a lot of ways. It’s designed to be run on a personal domain. It use NewBase60 encodings to keep the URLs both short and human readable. And it uses the same content-type partitioning of the URL space. The key difference is in the use of database keys. One of the design principles of Whistle is to have algorithmically reversible URLs. That means that anyone who knows the algorithm can convert the short URL back to the fully expanded form without actually having to make an HTTP request. It also means that you don’t need any kind of datastore to lookup the mapping. You can easily store everything in flat files. This results in a more stable and overall faster system. But because we’re building on WordPress, which is tied to a database anyway, there wasn’t as much of a benefit in avoiding the use of database keys in the short URLs.

How it Works

Hum is actually pretty simple. It’s very lightweight and currently uses no data storage of its own, as there are no configuration options. It registers a few URL patterns like /b/* and then handles any requests to those paths. For example, the short URL for this blog post is http://wjn.me/b/FJ. It also hooks into the built-in WordPress shortlink functionality to expose these new shortlinks in the metadata for each page.

Doing nothing else, this should give you reasonably short URLs, depending on your domain name. But the real value comes when you couple it with a personal short domain, and it’s incredibly simple to do. Buy a short domain, and set it to redirect to your primary domain. I did this by putting the following in my .htaccess for my short domain:

RewriteEngine On
RewriteBase /
RewriteRule (.*) http://willnorris.com/$1 [L,R=permanent]

Then you want to tell Hum that you have a short domain that it should use for generating URLs. To do that, add something like the following to your theme’s functions.php file:

add_filter('hum_shortlink_base', create_function('', 'return "http://wjn.me/";'));

And that’s it. You now have simple short URLs for all of your WordPress content. Hum includes additional hooks to make it very easy to link to offsite content, which I’ll hopefully cover in a future post. In the meantime, read the source… it’s pretty well documented.

This is only the first step in what I’d like to build for a WordPress implementation of DiSo 2.0, but a necessary one. If you’re interested in this, please contact me. You should also consider coming to IndieWebCamp in Portand, Oregon where we’ll be discussing this stuff for a full weekend.

Download Hum on GitHub: https://github.com/willnorris/wordpress-hum
Also on WordPress Extend: http://wordpress.org/extend/plugins/hum/

Cached Commons was setup by Lance Pollard earlier this summer to provide a common repository of popular (and some not-quite-as-popular) javascript and CSS libraries. This is a great idea, and one I’m a little surprised hasn’t been done before, at least not quite like this. I do have a few random thoughts and concerns though that struck me as I debated whether or not to use Cached Commons’ hosted version of Modernizr:

1. I don’t know Lance Pollard. I’ve never heard of him before, and I have no real reason to trust him. Looking at his website and GitHub profile, he seems to be very active in the open source (and specifically ruby) community, which is a big credit. By relying on his hosted version of any of these libraries, I’m taking a risk that he could change the hosted files and do some nefarious things to my site. I have absolutely no reason to believe that he would, but it’s always possible. I don’t really have this worry with Google.

2. What happens if Lance loses interest in maintaining this project, or gets too busy to keep things up to date? Again, not something I worry about with a company like Google. Now in reality this isn’t really an issue for a number of reasons. First of all, it’s not likely that I would absolutely need the latest version of a given library sooner than Lance would get around to adding it to Cached Commons. And because all of his work is being done in the open, especially being hosted in GitHub, I or anyone else could make a complete copy of all his work in a matter of minutes and maintain it ourselves.

3. Cached Commons is powered by GitHub pages, which is certainly faster than pulling the files directly out of the git repository as Lance points out. However, I’m pretty sure it’s not actually a CDN in the traditional sense, so it’s not as likely to have the same speed or reliability over time. That being said, I have no reason to believe that GitHub would be any less reliable than my own site, which is hosted with Joyent.

4. One of the biggest benefits of using javascript libraries from the Google Libraries API has nothing to do with the speed at which the data can download, but rather the fact that it may not need to be downloaded at all. As more and more sites begin to use the same exact copy of a particular library, the higher the likelihood that a given user will already have the file in their browser cache. So if a user has visited any site in the last year or so that uses the Google Library API to host jQuery for example, there’s a decent chance that it won’t need to be downloaded again and your site will load all that much faster. This is really more in reply to Lance’s comment about jQuery loading faster from Cached Commons than from Google… it’s about more than just transfer speed. But for things like Modernizr that aren’t included on the Google CDN at all, Cached Commons is certainly a good potential alternative.

5. Another important principal when trying to optimize speed is to serve static content from a cookie-less domain. Cached Commons is not cookie-less because Lance uses Google Analytics on the site. Of course, the only way that a user would have a cookie set for Cached Commons is if they had visited the site directly, which for most users will be pretty unlikely. However, it is something to consider. This could be addressed by using different hostnames for the website and the file repository, but at this stage it’s probably not worth the effort.

6. Finally, I’m very curious how the folks at GitHub feel about this project. I’m sure they didn’t exactly intend for GitHub pages to serve as a blind file server for the world, but then again, maybe this is the kind of project they had in mind… GitHub pages is certainly optimized for hosting static files. But it’s still not quite the same as Google committing to support their Library API, and designing the service for exactly that purpose. GitHub is, without a doubt, one of my favorite services in recent years, and I certainly wouldn’t want to abuse that service in any way.

In the end, I’ll quite likely use Cached Commons for hosting various libraries like Modernizr… you have to find a balance in all these things, and the ease of just linking off to them is quite attractive. I’d love to see GitHub actually work with Lance and make this a real service that they offer similar to GitHub RubyGems (and others?). All in all, the work Lance has done on this is great… I’ve been wanting something like this for a long time, and am very pleased with what he’s come up with.

Instead of the long contemplative post on how this move is the next logical step in a career of working in Identity Management, I’ll keep it short. I start work next Monday, February 1st, and I’m a bit pre-occupied this week with getting moved from Portland, Oregon down to Half Moon Bay, California.

I expect great things from our team in 2010, and so should you.