Zach Holman

Today I attended a virtual conference call for the Rubicon Project, a startup that's targeting web publishers in hopes to help ease the pain in the ass that we know as online advertising.

Basically what the Rubicon Project does is act like an OpenX, in that it handles which ads go on your site at any given time. The Rubicon Project aims to go a bit further than that, though, in that they optimize the inventory—they run optimizations based on eCPM, network performance, and so on. Better paying ads get run more often. They also centralize reporting across all your networks, too.

The last 4-5 years I've gone with the normal "chaining" of defaults: I run Tribal Fusion's ads on Good-Tutorials, when TF runs out of ads I send them to a different network like Casale Media, then to ValueClick, and so on. It's a good solution since it's pretty brain-dead easy for me after the initial setup, and it makes sure that I utilize all of the ads running. I still lose out on money though: what happens if ValueClick sometimes pays more than Casale Media? I could change things like this on a day-to-day basis, but, let's face it, it's a pain in the ass. So the Rubicon Project handles that for you.

I've been in the private beta for the last two months, and, though I was concerned at first about whether it would be worth my time, I'm quite happy. The bottom line's really what counts here, and that's simple enough to check: I'm making more money now than I was making a few months prior. And that's a good thing. Across their network, they claim that they see increases in revenue by 30-300% per site.

It was a private beta though, which meant there was some glitches, poor design decisions, and other irritations that I noticed along the way. Luckily the Rubicon Project just launched a new version that tackles some of those issues. And it's now something that you can use, too: today they launch a public beta.

Public and free

Probably one of the biggest new announcements from them today was that they're moving to a free ad management network. I think this could be pretty big. For the last four or five years, managing ad networks has been a huge pain for me. Handling defaults, consolidating reporting, verifying consistent performance, that type of thing. Something like OpenX just had always been a pain to use and seemed more setup towards direct sales rather than handling networks. It'll be interesting to see how having a good, free service like this will impact small publishers.

If you have any questions before signing up, feel free to shoot me an email or comment.

Facebook just launched their previously-rumored IM functionality. It offers the opportunity to chat with your facebook friends in real-time over the network in your browser.

The walled garden approach

Kottke mentioned in the past that Facebook is the new AOL. Over the last few years, they've taken increasingly greater steps towards the walled garden approach: sure, interact with our users, but only if you do it via our proprietary methods. AOL neglected HTML in favor of RAINMAN. For Facebook, you have to dive into a world of FBML and FQL. It's a tradeoff between consistency and flexibility, to be sure, but the discussion of the viability of a closed system like Facebook applications on an open system like the internet is rather substantial and best left to a different blog post entirely.

Facebook and AOL diverge

After an interesting few years of back-and-forth battling, AOL eventually ditched their walled-garden approach for their IM protocol and moved towards some openness by publishing guidelines to OSCAR for 3rd party projects like Pidgin or Trillian to use. It could be argued that the growth and ubiquity of the AIM network is sustained through the ability to run AIM over Trillian, Adium, iChat, and others. My entire generation (say, those in college right now) tends to use AIM nearly exclusively, with few of my personal friends using the official AIM client itself.

The thing that's interesting about today's development is that Facebook has diverged from AOL's model, albeit in a backwards way. Facebook Chat uses their existing web interface to deliver their new functionality. Whereas AOL moved from walled garden to tentative openness, Facebook moved from walled garden to, well, walled garden. You can only chat while on facebook.com, you can't use it via their Facebook iPhone/mobile apps, and you can't use a third-party app to interface with the network.

The limitations of a closed IM network

This is a relatively new thing, at least for me. I've dabbled on most major networks: AIM, MSN, Yahoo!, Jabber, and Bonjour. The common link between them all is that they're all based on relatively open protocols, at least to the point where you can use them in an Adium or a Trillian. If there was a closed IM network, they at least provided desktop functionality. Facebook doesn't. A straight web-only interface makes it difficult to really be a viable communication medium.

There are a few reasons why I enjoy Adium (though my arguments will likely apply to Pidgin or iChat or whatever your flavor of IM client). For one, I'm a habitual conversation history tracker. I have logs dating back six or seven years. It's helpful to me—I can't tell you how many times someone says something, I close the conversation and immediately forget which time I was supposed to meet them or the line of code I was supposed to check out. Facebook logs your conversations between sessions but not permanently, supposedly (Facebook, as its customary style, is fairly ominously-vague when it comes to your personal information and longevity).

Secondly, you lose out on the natural behavior of your operating system. I actually just received an IM from a friend right now. How did I know? I'm in a different Space in OS X, so my IM windows aren't visible. It's because of OS behaviors that, as a user, you grow accustomed to. Step one: I hear my normal IM ding. Step two: I get my Adium duck flapping its wings on my Dock, with a OS X-standard "1" icon superimposed on the Adium icon, signaling to me that I have one message to check out. Step three: I get a growl notification that tells me the sender and their message, if I want to bother to check that section of my screen before command+tabbing over to Adium to actually read or respond. Beyond that, there's a multitude of OS-specific behaviors you expect: on a Mac, I expect command+W to kill the current conversation tab, shift+command+]/shift+command+[ to tab between conversations, and hey, Adium does a great job with interacting with Address Book to grab user icons and first and last names. You don't get any of this with Facebook Chat.

Even the web interface isn't very standard. For one you have to remain on facebook.com to receive messages, you have to resist a stale session (after 10 minutes or so you're auto-logged out unless you visit another page), and some pages don't even work (try the "People You May Know") link on the main page.

Open and shut case

With these limitations, it might not surprise you to learn that I'm not too enthused about Facebook Chat's prospects. I can't really see it being much more than a "hey, I'm in a cluster on campus and can't get on AIM or MSN... here's the info you wanted". I don't necessarily see it as taking the place of existing networks, particularly because it's so closed. Not only is it web-only—you can't use it with Adium—but it's also Facebook-only—you can only use it with your Facebook friends. That kills prospects of those who want their IM handle public and don't want to have to befriend every user.

Google ran into similar circumstances with GTalk: they gave easy web access to GMail users to talk to existing email contacts, but at the same time pushed open and accessible Jabber standards to allow interoperability. If Facebook wants to really push Facebook Chat (which, since they tossed a floating div on the bottom of every one of their pages, seems to suggest this), they would be smart to take a move out of Google's handbook and add some open operability to their network.

For some reason, it looks like April's gearing up to be an exciting month for me in terms of entertainment excellence:

• April 10: The Office returns
• April 10: Scrubs returns
• April 21: House returns
• April 22: Nas' new album debuts (not a huge Nas fan, but enjoyed Hip Hop Is Dead)
• April 24: LOST returns
• April 27: Mario Kart Wii drops
• April 29: Grand Theft Auto IV drops

Can't say that I'll be very bored this month. Plus, depending on how engrossed I am in all of the new April goodies... there might even be some fun Good-Tutorials announcements tucked in there, too.

I ended up checking Good-Tutorials this afternoon and a JavaScript alert box popped up with the message "you fixed me big boy". Needless to say, I did not put this in. First thought was of being hacked... it looked like the site was running fine, so then I figured I must have missed a XSS hole somewhere that someone had exploited (though the message is an odd choice for a XSS attack). I tried to find the JavaScript alert code in my source to no avail. At this point I got a little more concerned since, well, I couldn't find where the alert was coming from and I had already received two emails in the last 15 minutes from visitors to the site that were hitting this immature alert box on every page load.

I opened WebKit's fantastic Web Inspector, did a search for "alert", and found out that it was coming from snaptalent.com. Snaptalent is a new startup that runs ads for job opportunities. I started a trial run of Snaptalent about a day or two ago to see how well it would perform on Good-Tutorials. Needless to say, I immediately pulled their ads from my site and will never go back.

It's one thing to leave debug code in—say, an alert with an inspection of an element in the DOM—but you still should be able to catch it before it goes live. If you're popping an alert box in every ad that you run, it's clear that you didn't test a thing before you pushed it live. That's just ineptitude.

If you're popping an alert that says "you fixed me big boy" on every ad load that goes out to tens or hundreds of sites, you're just a fucking moron.

restful_authentication is the backbone to Rails development; it's a generator that adds user functionality to a Rails app. It's worked great for me over the years (including its predecessor, acts_as_authenticated), though one thing that always bothered me is that it doesn't work cross-machine.

Take a gander, yourself: log into your Good-Tutorials account on one machine and then log in on another machine (or another browser). After you close out of the first session, even if you have "Remember me" checked you won't be able to auto sign-on with the first machine again. In effect, latter sign-on steals the cookie of the former.

I wanted to get my feet wet with this whole git craze, so I forked restful_authentication and made the changes to keep persistent sessions cross-browser. You can pull it from my GitHub account, or just make one quick change in your User model.