Subscribe to my blog via email

I love FeedBurner. Every now and then, I check out features I’m not using and try a new one out. Tonight, I added the ability to subscribe to my blog via email using FeedBurner email. The form is permanently in my blog template now, but here’s what it looks like for all you RSS-only readers:

To subscribe to my blog via email, enter your email address below:

Delivered by FeedBurner

Enjoy.

Loads of new stuff from Yahoo! Developer Network for Open Hack Day

Lest you think our Yahoo! Open Hack Day was all about Beck (yes, it was really cool to have him), we also released an incredible stream of stuff for the hackers to play with while they were hanging out with us at Yahoo! There is nothing like a big event with a hacker rock star to mobilize the teams at Yahoo! to tackle the last 10% to get those releases pushed out! Here’s the list. This has been covered in many places already (I was happily buried with Open Hack Day stuff instead of blogging):

  • Browser-based authentication, or BBAuth: This is big. As Dave says, “If it’s easy to program, and delivers on what it says it does, this is a huge deal.” Agree or disagree with Dave, you have to listen. (see the YDN blog post and Dan Theurer’s post as well. It was Dan’s focus and tenacity that got this thing out. Thanks Dan!)
  • Yahoo! Photos API: combined with BBAuth, you can now write applications that have read/write access to users’ photos when they grant your application permission to work with their images. More on the YDN blog.
  • Upcoming PHP5 wrapper: Check out their post for all the details, but they delivered a PHP5 wrapper for their API and a couple of new method calls. Rock on (they’re hiring, too — Guitar Hero excellence preferred, but not required. Check out this photo of Beck with the giant Guitar Hero screen the Upcoming guys set up for Open Hack Day in the background).
  • Flickr support for JSON and Serialized PHP: Read all the details in Cal’s post to the yws-flickr group.
  • .NET Developer Center: A shout out to you Microsoft fans out there. Check it out.
  • Yahoo! Mail API: We gave everyone who came to Open Hack Day a crack at this API. Stay tuned for general release in a few months. This one is really exciting. Check out the News.com story for where things are headed.

The Yahoo! Developer Network team and our partners in the product teams around Yahoo! rocked harder than Beck did on Friday night to get this stuff out and put on our Open Hack Day, so the credit extends to hundreds of people inside Yahoo! for getting it done and to all the incredible hackers who jumped right in, built stuff (often side-by-side with the developers who built the APIs they were using), and gave us immediate feedback.

I’m totally sleep-deprived right now, so I’ll save any extended commentary for later — but the past few days have been among the most memorable and exciting in my life. It’s been that good.

Salesforce.com and API metrics

Although I’m not as engaged with the topics of software and services for the enterprise as I used to be, I’m still keeping up with what’s going on at Salesforce.com. I was a customer in my InfoWorld days and also wrote some nice things about their web services platform early on in its development. When it comes to APIs and “web as platform,” Salesforce has always been a trailblazer.

A recent post from Adam Gross on the sforce blog provides a glimpse of the mix of API usage vs. the web application itself and the numbers are really exciting:

. . . from our modest beginnings with Sforce 1.0, we’ve seen the Sforce Web service API grow to account for over 40% of all of salesforce.com’s total traffic. Think about that for a minute – the API is almost as heavily used as the salesforce.com Web application.

Wow.

(A hat tip to Charlie Wood for pointing this out in his blog)

First impressions of Measure Map from Adaptive Path

I got my invitation a few days ago to try out the alpha release of Measure Map, the blog stats service from the folks over at Adapative Path. After a few days of using it, I’m generally impressed. The quickest (but also crudest) way I can think of to describe the service is WebSideStory’s Hitbox or Omniture Site Catalyst for bloggers, since (like Measure Map) both of these services leverage the placement of Javascript code in a site’s pages to deliver reporting, freeing sites from the laborious crunching of log files, filtering out spider/robot traffic, and the many other annoyances of old-school methods of traffic reporting on the web. That being said, even if WebSideStory or Omniture decided to create a blogger offering, you can bet it wouldn’t be as simple, elegant, and useful as Measure Map. Even though it’s alpha, it looks like they’re building the right half of a product, but not a half-assed product. The tag line is “get to know your blog,” and that’s what Measure Maps is already helping me do.

Setup was easy for WordPress. I have no problem editing my templates based on rudimentary written instructions, but I still appreciated the clear visual guidance the Adaptive Path folks give in their instructions. Here’s an example:

Measure Map template editing

Almost immediately, the numbers started rolling in, and I found myself checking my Measure Map stats as often as I had grown accustomed to checking my Feedburner stats (incidentally, I consider these two services complementary at this point, since Measure Map measures non-RSS traffic, and Feedburner measures RSS traffic). Here’s a sample screen, the “Links” screen which tells me inbound links, outbound links (how else are you going to get that info without a bunch of ugly redirects and log crunching?), and search terms used to get to your site.

Measure Map links screen

The outbound links tracking is cool because it includes everything on your blog page, so you can see exactly which photos people are clicking on your Flickr badge, for example. The search terms section lets you know what words people are using to find you on search engines. Like everything else in Measure Map, the information is updated fairly instantly as activity occurs on your site.

Other stats I quickly learned:

  • the browser breakdown for my blog (58% Firefox, 26% IE, 12% Safari, 4% “other”)
  • the geographical distribution of visitors (73% U.S., 5% UK, 5% Canada, 5% Australia, 4% India, the rest spread among 12 other countries)
  • peak usage times (7-9am, 1pm, 5pm)
  • My top 10 posts (#1 is “Super-mashup with Yahoo! APIs: event browser“)

Bottom line: though only in alpha, Measure Map is already quite useful to me. Only one significant glaring hole that I noticed in the materials: no mention of an API on the Measure Map alpha status page under “feature set”: We’ve got a few great features coming soon, including stats for your RSS feed, tracking interesting events in your stats, and deeper tools for understanding search engine traffic. This might very well be on the way, but it would be nice to see it explicitly mentioned. After all, the service itself is being developed on top of some sort of API — why not start surfacing it early? It would be great to be able to do some remixing with the Feedburner API, for example.

Update (for those of you who don’t keep up with the comments): Jeff Veen from Adaptive Path writes: “We’re already working with Feedburner, with the intent of hooking your accounts together and merging the stats. Also, our first peek at a public API will be coming very soon now.”

Flock and WebOS

Now that I have Flock, I decided to test it out a little.  My first task, of course, was trying to post to my blog.  That’s what you’re seeing here (please forgive some of the wonky formatting).  I was hoping that the blog tool would allow for offline posting a la ecto, but that doesn’t appear to work.  When I tried to save a draft with no network connection (I turned off my wireless card and pulled my network cable for fun), the app went into a tailspin.  This inability to save locally in what is essentially an extension of the Firefox browser reminded me of Jason Kottke’s post about the WebOS way back in August.

Flock is perhaps the quintessential Web 2.0 company (technology and hype included), but after ten minutes with the application and some reflection on Kottke’s WebOS post, I think Flock could be more than simply “a Web 2.0 on-ramp” (as Kris Krug of Bryght calls it in this Wired story).  I think Flock might be thinking WebOS. From Kottke’s WebOS post:

So this is my best guess as to how an “operating system” based on the Web (which I will refer to as “WebOS”) will work. There are three main parts to the system:

  • The Web browser (along with other browser-ish applications like Konfabulator) becomes the primary application interface through which the user views content, performs services, and manages data on their
    local machine and on the Web, often without even knowing the difference. Something like Firefox, Safari, or IE…ideally browser agnostic.
  • Web applications of the sort we’re all familiar with: Gmail, Flickr, and Bloglines, as well as other applications that are making the Web an ever richer environment for getting stuff done. (And ideally
    all Ajaxed up to provide an experience closer to that of traditional desktop apps.)
  • A local Web server to handle the data delivery and content display from the local machine to the browser. This local server will likely be highly optimized for its task, but would be capable of running locally installed Web applications (e.g. a local copy of Gmail and all its associated data).

That’s it. Aside from the browser and the Web server, applications will be written for the WebOS and won’t be specific to Windows, OS X, or Linux. This is also completely feasible, I think, for organizations like Google, Yahoo, Apple, Microsoft, or the Mozilla Foundation to make happen (more on this below).

“Something like Firefox, Safari, or IE.”  “Web applications of the sort we’re all familiar with.”  “Won’t be specific to Windows, OS X, or Linux.” Pretty close to what Flock encapsulates.  The only area where Flock completely misses is the third point (basically running locally without loss of features), which is understandable given the constraints of current browser technology and the fact that Flock is a “developer preview.” I would still love to be able to save a draft blog post locally using Flock while disconnected on a plane, though.

Going back in the time machine to Kottke’s oh-so-long-ago post in August, he asks, “So who’s going to build these WebOS applications? Hopefully anyone with XHTML/JavaScript/CSS skills, but that depends on how open the platform is. And that depends on whose platform it is. Right now, there are five organizations who are or could be moving in this direction.”

Aside from the usual suspects (including my employer, where we are definitely doing lots of cool things as the post suggests), Kottke lists the Mozilla Foundation:

This is the most unlikely option, but also the most interesting one. If Mozilla could leverage the rapidly increasing user base of Firefox and start bundling a small Web server with it, then you’ve got the beginnings of a WebOS that’s open source and for which anyone, including Microsoft, Google, Yahoo, and anyone with JavaScript chops, could write applications. To market it, they could refer to the whole shebang as a new kind of Web browser, something that sets it apart from IE, a true “next generation” browser capable of running applications no matter where you are or what computer (or portable device) you’re using.

Flock isn’t the Mozilla Foundation and they are “completely independent,” but reading Flock CEO’s Bart Decrem post about how Flock will create “sustainable value” (the answer to all the what is your business model? questions) gives me pause. If you replace Mozilla with Flock in the Kottke quote above you might be tempted to think that Flock is working towards something a lot bigger than a cute Web 2.0 browser. Besides, who needs another browser anyway?

And who needed another search engine?

Want Akismet? Then download Flock. Huh?

(Note on 11/10/05: getting the API key was mildly painful, but Akismet is doing an EXCELLENT job of catching spam. I have zero problems now — it was well worth it!)

I ran across a mention of Akismet, the WordPress spam blocker, on the BusinessWeek blog and since I’ve been seeing a bit more spam these days, I decided to try it out. WordPress has been good to me, and this sounded like just the thing I needed to make my experience almost perfect.

I clicked over to the Akismet site, and see “Akismet is free for personal use.” Looked good. “All you need to start using it today is a WordPress.com API key. Sign up on WordPress.com to get an API key.” No big deal — I sign up for API keys all the time.

I followed the “Sign up on WordPress.com to get an API key” link over to WordPress.com and saw this message: “Want WordPress.com? Then download Flock. . . .”

want wordpress? download flock

Huh? I just want an API key so I can try out Akismet and I followed a link that promised me just that. What does Flock have to do with this? Why should I have to download Flock?

Frustrated, I downloaded Flock, but it was guesswork from there on how to get an API key. I clicked around on the “Five ways to. . .get started” on the Flock startup page (with the Flock app) and chose #2, “. . . get yourself a blog.”

five ways

I was presented with three choices: WordPress, TypePad, and Blogger. I chose the WordPress link and filled in the requisite information (note that “chad” was taken, so I used “chaddickerson,” but didn’t do another screen shot).

wordpress signup

At that point, I got an e-mail with my username and password to login to my WordPress.com blog. Yay. So I logged in to my WordPress.com blog, still not sure where this elusive API key existed. Randomly, I clicked around until I clicked on “Profile” in the main admin menu. And there it was! My API key!

WP API key

This process makes almost zero sense. I expected a lot more from WordPress, and getting siphoned through Flock to get an API key smacks of some backroom arm-twisting marketing deal. Getting an API key has never been so convoluted.

Fortunately, installing the Akismet plugin was as easy as any other WP plugin and I got it installed in a couple of minutes. I entered the API key with no problem. Whew. Now I’ll see how Akismet works.

Oddly enough, it wasn’t until the plugin was installed that I came across a reasonable link about the API key, found on the plugin manager page (yes, it’s a little hard to see below):

plugin manager

For those who don’t want to go through the aggravation I just did, here’s the text:

Akismet checks your comments against the Akismet web serivce to see if they look like spam or not. You need a WordPress.com API key to use this service. You can review the spam it catches under “Manage” and it automatically deletes old spam after 15 days. Hat tip: Michael Hampton and Chris J. Davis for help with the plugin.

What a strange process. I sure would like to know the thought process that went into it, because I certainly can’t make any sense of the actual process.

Update: Michael Hampton responds in the comments, and this post makes things clearer:

Last week I told you all about Automattic Spam Stopper, the new anti-spam solution for WordPress from Matt Mullenweg. There’s been some new news, and you’re going to hear it here first.

First off, the plugin has been renamed to Automattic Kismet, or Akismet for short.

Second, it now requires a WordPress.com API key, which you can find on your WordPress.com Profile page. (Click My Dashboard, then Profile.) If you don’t have a WordPress.com account, you won’t be able to use Akismet at this time, until you somehow finagle yourself an account. The fastest way is probably to use Flock. You don’t actually have to blog at WordPress.com to use Akismet, you just need the account to get the API key. You can use the API key at more than one blog, too.

Web 0.1 head-to-head: 37Signals' Backpackit vs. Gmail in Lynx

Last night, I decided to not-so-carefully run a couple of Web 2.0 apps through the old-school Web 0.1 Lynx browser to see which would work best, or work at all. It occurred to me that in the Web 2.0 world, Lynx might be thrown onto the trash heap of history, made useless by whiz-bang AJAX development. That would be a shame (though the life of Lynx could very well be extended by folks using the lynx -source [URL] command to dump the source from cool AJAX apps)

All this aside, I really just wanted to see what would happen when a Web 2.0 AJAX app got run through the Lynx HTML meat grinder — kind of the same impulse that led me to put various things in the microwave in my youth. For this test, I chose Gmail and 37Signals’ Backpackit.

For these tests, I used this version of Lynx:

Lynx Version 2.8.5rel.1 (04 Feb 2004)
libwww-FM 2.14, SSL-MM 1.4.1, GNUTLS 1.0.16

Let the games begin! First, the Gmail login screen was a bit of a mess under Lynx (username label off to the right, login on the second screen), but ultimately useable.

After login, I jumped through a series of redirects before ending up on this page:

And the experience ended there — no more redirects, just that raw screen. Game over, Google. Yes, I could cut and paste the long URL from the screen into a browser, but then I wouldn’t be testing Lynx any more, would I? Gmail is definitely NOT Lynx-certified. Stay away, Lynx fans.

Next, 37Signals’ Backpackit. The login screen in Lynx is very nice and simple with elegant alignment, all on one page so I didn’t have to resort to the dreaded space bar to advance to the next page:

I navigated a bit and decided to add a note using Lynx.

It worked, as you can see when I checked in Firefox:

The winner by a landslide: 37Signals’ Backpackit. Nice job. Through adequate support of Lynx, Jason and team are clearly practicing the “less is more” that they preach.

Update: In my cheekiness about Lynx, I didn’t think about one aspect that Eugene Chan has pointed out in the comments: “As Lynx goes so does screenreaders for the blind. So it does mean that web designers who are not thinking about web 0.1 may leave an important segment of users behind.” Very good point.

After the ping: how long it takes for blog search engines to find you

I’m launching a new blog with a specific focus very soon (more on that in a day or two). Since you only launch a new blog once, I decided to check my logs to see how long it took for various blog-specific search engines to find me after a ping to Ping-o-matic (and there’s no reason why I pinged ping-o-matic instead of another ping server other than it was set up as a default in WordPress).

Here’s the chronology, for what it’s worth:

23:54:56: pinged Ping-o-matic
23:55:26: A2B Location-Based Search Engine (+http://www.a2b.cc/search-url.a2b?url=http%3A%2F%2Fwww.my-new-blog.com")
23:55:28: BlogSearch/1.0 +IceRocket
23:56:42: Technoratibot/0.7 (from Technorati, of course)

. . . and bringing up the rear after I called it a night:
00:10:27: Feedster Crawler/1.0; Feedster, Inc.

Bonus link: Jon Udell takes a deeper look at future of ping notification infrastructure. Jon starts out by quoting a post on the subject from Cameron Marlow, who recently joined us at at Yahoo! much to everyone’s delight.

Update: (for those of you who don’t read the comments) Scott Johnson of Feedster posted in the comments to note that they were working through a large backlog when I was checking. To be honest, a roughly 15-minute delay after midnight is within the realm of acceptability to me anyway, regardless of the cause. In any case, Feedster wins the award for having the most responsive humans in this case.

Warning Bloglines subscribers: some feed changes

Now that I’ve written about the wrong way to work with your feeds if you use FeedBurner and have Bloglines subscribers, I decided to make another go at doing it right today.

First, this only affects about 25 subscribers — those who are subscribed to my “orphan” (i.e. non-FeedBurner) feeds in Bloglines. The majority of my Bloglines subscribers are subscribed to the “right” feed (the FeedBurner one). Later on tonight, after I’ve confirmed that Bloglines has pulled this post into those orphan feeds, I’m going to do a permanent 301 redirect over to FeedBurner. According to Mark Fletcher’s post in the comments at Russell Beattie’s blog, “301 redirects should automatically redirect/remove feeds in the system.” Here’s hoping none of you get hit by the “remove” side of the equation.

Looking at my logs, these are the URLs that are being requested that will soon have permanent 301 redirects to my FeedBurner feed (for the novices out there, here’s a document with the http status codes for your reading enjoyment):

Or, you can just ignore all that needlessly technical stuff and subscribe to the proper feed in Bloglines by clicking on the button below. If everything works as it should, you won’t even have to do that.

I’ll report back in a few days on how well the 301 redirects handled things.

Update, 7:48pm PT: The Bloglines bot visited one last time, and now the 301 redirects have been put in place.