Contact: (801) 853-8339 or jesse@staynalive.com
Twitter, FriendFeed, LinkedIn, or Facebook

Learn More About Facebook With Upcoming WebCasts

Hi - you seem to be new here. If you like what you see, please give back by subscribing to my RSS feed!

You can check me out on Twitter, Facebook, or FriendFeed to see what I'm up to. Thanks for visiting!

I also consult, and am open to full or part-time work. If you are interested, please contact me - check out our services at http://staynalive.com/consulting

FacebookI’ve been invited to do 2 WebCasts in the next 2 weeks that I think you might be interested in.  As always I’ll try to post my slides on SlideShare if it makes sense to do so.  I really like an interactive presentation so most of the time my slides don’t make sense.

The first is for the Marketers in the Audience.  It’s about gaining Business value from Facebook, and I’ll discuss how to give your business legs using the Social Network.  I’ll cover how to create an effective Facebook Page for your business, when and how to use your personal Facebook Profile for networking, do’s and don’ts on the network, advertising, the tools you need, and more.  That Webinar is hosted by Marketing Coalition, and is $149 per individual, and $129 per individuals in groups of at least 3.  You can register here.  The Webinar takes place on Thursday at 1:30PM EST.

The second WebCast is free, and hosted by Safari Books Online.  It will target developers new to Facebook development, and in it I’ll cover the basics of what you need to get started in Facebook Development.  We did this last year and I think everyone really enjoyed it that attended.  The first people that register get a free Autographed copy of my book, FBML Essentials, and everyone else gets a free 45-day account on Safari Books Online to read FBML Essentials.  Did I mention how much I love O’Reilly?  You can register here.  My slides from the last one of these I did are up on SlideShare.

There will be a Q&A after each session, so come with your questions and I’ll do my best to answer!

Social Coding: How to Code Twitter’s OAuth Using Net::OAuth and Perl

OAuthFor the non-developers in my readership, I’m going to get a little geeky on you here. So you can either tune this one out, or pass it onto your IT staff for use in their applications. I promise much more on the “Social” side here shortly. Or, maybe you’ll learn a little Perl.

For those not in the loop, my company, SocialToo.com codes in Perl, a powerful language that gives me the ability to abstract what I need at a very high level, or get down to the nitty-gritty if needed to in order to improve speed or communicate with other core Unix libraries and tools. To me, it’s a very powerful and important language that enables me to get done what I need to do without having to hire developers that know multiple languages. It’s also an amazing scripting language, and powers many of the scripts we run on the backend of SocialToo.

One of Perl’s weaknesses however is that it has never been very strong in the marketing department. For this reason, it is some times (and some times not) one of the last on the priority list for companies like Twitter when developing libraries to integrate with their API. Fortunately it has a very strong group of developers contributing to its very unique directory of open source libraries, CPAN.

Recently we launched a beta OAuth implementation on our Forgot Password page on SocialToo, which uses Twitter OAuth to identify a user and allow them to change their password based on their Twitter authentication. Fortunately with Twitter, we were able to use Net::OAuth, Perl’s OAuth libraries on CPAN, to connect with Twitter’s OAuth implementation. There were some tricks, so I’d like to share that here. It’s my hope that maybe at some point I can package this up at a much higher level to make the process even easier for Perl developers to use Twitter’s OAuth to authenticate.

Perl and OAuth - the basics

First of all, you need to understand the basic flow of the Twitter OAuth process. There are official OAuth terms for this (consumer, service provider, etc.) supposedly to make understanding the process easier, but for our purposes those terms really don’t matter. If you really want to learn more about that stuff, go over to OAuth.net and take the tutorials. What matters is that you get the Access Token you need, which you can use any time later to make requests to Twitter, such as authenticating the user, getting the user’s timeline, their profile info, friends, followers, and more. The entire goal of Twitter OAuth from a development standpoint is to get that Access Token. So here are some basic terms you need to know:

Token - a string of hashed data given to you as a unique ID to identify your application, and the user trying to use your application by Twitter. See below for the types of tokens you’ll need to get from Twitter and when.

Request Token - The token you get from Twitter before redirecting the user to authenticate with Twitter. If the user’s authentication is successful, Twitter creates an access token which identifies the user and associates them with your application. You can then access that access token later by sending another request after the user has authenticated with the request token and the request token secret key (defined below).

Request Token Secret - A string of hashed text, which only you (the developer) will ever see or use. You retrieve this when you get your Request Token, and will need to pass it with your request token when you request to get an access token. Consider this your password when trying to get an access token. Your Request Token is your ID for Twitter to identify your request with to verify the user authenticated successfully and your application has permission to access Twitter.

Access Token - Once you have your Request Token, your Request Token secret, and the user has authenticated successfully, and assuming your application has been given permission by Twitter to access the Twitter API, you can then make a request to Twitter to get your Access Token. You send Twitter your Request Token and your Request Token Secret, and the response returns your Access Token and an Access Token Secret Key for access to the Twitter API. This is a permanent key at the moment that you can use any time later. Store this in your database or a file or elsewhere once the user has authenticated and you’ll be able to authenticate on their behalf from that point on (assuming you have set your app up to do such on Twitter.com). After you have your Access Token, you can make requests to Twitter, via Net::OAuth, which perform any of the methods found via the API by sending Twitter your Access Token and Access Token Secret with the request. Use JSON::Any to parse the resulting JSON returned.

Access Token Secret - The secret key to pass with an Access Token when making API calls to Twitter. Consider this the password that goes along with the ID, which is the Access Token. Twitter looks up the Access Token ID, verifies the user is authenticated, and then checks that you also have a valid Access Token Secret Key. If both are correct and valid Twitter will send back the data you need to access the Twitter API.

Twitter Consumer Key - The unique ID of your application as identified by Twitter - you can get this in your OAuth set up on Twitter. You use this when asking for your Request Token.

Twitter Consumer Key Secret - The “password” to go with your Twitter Consumer Key when asking for your Request Token from Twitter. Twitter looks up your application by it’s ID (Consumer Key), and verifies it’s you by checking your Consumer Key Secret.

Flow of a Simple Twitter OAuth App in Perl

To understand what we’re doing, you’ll need to understand the order of things you’ll need to do in order to fully access the Twitter API through OAuth. This Flow, in plain english, should outline that process, and from here you should be able to adapt the code I provide for any use:

  1. Send a GET request to http://twitter.com/oauth/request_token asking for a request token from Twitter, and passing your appropriate Consumer Key and Consumer Key Secret to identify your application.
  2. If Twitter identifies the Application as legit (and isn’t down), parse out the request token and request token secret from the content of the returned page by Twitter. Here you’ll want to store that request token and request token secret somewhere, as you’ll need to access it again after the user returns back to your site from Twitter.
  3. Redirect to http://twitter.com/oauth/authorize, appending “?oauth_token=YOUR_REQUEST_TOKEN_GOES_HERE” to the URL, replacing YOUR_REQUEST_TOKEN_GOES_HERE with the request token you just got from Twitter. There is no need to send the Request Token secret at this point - this is simply to identify that you have received a request token from Twitter, and so Twitter can identify the user’s authentication (successful or not) with that Request Token.
  4. The user authenticates on Twitter (if not already authenticated through Twitter - if they want to authenticate through a different user they can do so here as well by logging out and re-authenticating).
  5. The user is given the option to “Allow” or “Deny” the request by the Application to access their account information on Twitter.
  6. Twitter then redirects back to the Callback URL you set up in your OAuth set up on Twitter.com - you’ll want to note this so you can write code at the location Twitter redirects to that gets the response token.
  7. Your Callback URL takes the Request Token from earlier, and Request Token Secret from earlier, and sends them to http://twitter.com/oauth/access_token to try and get an Access token. Twitter verifies that the user has authenticated successfully, that they have allowed your application to access their account, and that your Application is valid. If so, you’re returned a successful response from Twitter.
  8. You’ll want to parse out the Access Token, and Access Token Secret from the returned page, and store them somewhere with that user so you can access Twitter on their behalf later. Or, do something right then and there! You have all you need now to use the Twitter API for that user under OAuth.
  9. At this time is when I would authenticate the user if needed, making an OAuth request to access http://twitter.com/account/verify_credentials.json. To do so just send the request via Net::OAuth, along with that user’s Access Key and Access Key Secret (which hopefully you can retrieve from somewhere since you stored it somewhere earlier), and Twitter returns the data back as JSON-formatted data (or XML if you specified verify_credentials.xml) you can then parse out as necessary. You can do the same with any method in the Twitter API.

Example Code

Alright, now onto the juicy details. Assuming you’ve already set up an OAuth Twitter App under your settings tab on Twitter.com, and have your Consumer Key and Secret, you should be set to go. You’ll need to install Perl’s Net::OAuth (and any dependencies) via:

perl -MCPAN -e "install Net::OAuth"

Now, let’s get the Request Token. To do so, I’ve created a simple OAuth Accessor method to do all my OAuth handling. I use Catalyst as my MVC Framework, so all the $c and $self references refer back to the Catalyst environment. I’ll leave that up to you to figure out, or you could always try out Catalyst! So first, let’s set up this method:

=head2 oauth_request

Sends a generic request to the specified url

=cut

sub oauth_request : Private {

 my $self = shift;
 my $c = shift;
 my $i = {
  ’type’ => ”,
  ’url’ => ”,
  ’extra_params’ => {},
  ’token’ => ”,
  ’token_secret’ => ”,
  ’method’ => ‘GET’,
  @_,
 };

 my $request = Net::OAuth->request($i->{’type’})->new(
  consumer_key => $c->config->{’twitter_consumer_key’},
  consumer_secret => $c->config->{’twitter_consumer_secret’},
  token => $i->{’token’},
  token_secret => $i->{’token_secret’},
  request_url => $i->{’url’},
  request_method => $i->{’method’},
  signature_method => ‘HMAC-SHA1′,
  timestamp => time,
  nonce => join(”, rand_chars(size=>16, set=>’alphanumeric’)),
  extra_params => $i->{’extra_params’},
 );

 $request->sign;
 $c->log->debug(”URL: “.$request->to_url);

 $c->log->debug(”Request: “.Dumper($request));

 my $ua = LWP::UserAgent->new;
 my $response = ”;
 if ($i->{’method’} eq ‘GET’) {
  $response = $ua->get($request->to_url);
 }
 else {
  $response = $ua->post($request->to_url);
 }
 $c->log->debug(”Response: “.Dumper($response));

 return $response;

}

Basically, all this does is create a new Net::OAuth request object, signs it, and then sends it via a GET or POST request (via LWP) back to the specified URL. This method will handle all our OAuth requests. You’ll need to modify it to match your environment and configuration variables (like the consumer key and secret).

The token and token_secret variables can be either a request token, or access token (and secret), or neither. You won’t need to pass either when you’re trying to get your request token obviously. “type” will define what type of request it is you’re making - it can be either “request token” (to ask for a request token), “access token” (to ask for an access token), or “protected resource” (when accessing private data for a user from the Twitter API on their behalf). The “url” variable specifies the Twitter URL to request, based on the type of the request. You can get these from your OAuth settings page for your app on Twitter.com. Dont’ worry about the rest - that’s all used to generate the signature sent to Twitter with all the data you just gave it.

Now that we have that, we can make our requests to Twitter.  We’ll need to start with getting our Request Token.  We’re of course assuming this is the user’s first time authenticating through your App.  Here’s how we’ll do that using the above method:


$c->log->debug(”getting request token…”);

my $res = $self->oauth_request($c,
 ’url’       => $c->config->{’twitter_request_url’},
 ’type’      => “request token”,
);

$c->user_session->{’oauth_redirect_url’} = uri_escape($c->req->param(”redirect_url”));

if ($res->is_success) {
 my $response = Net::OAuth->response(’request token’)->from_post_body($res->content);
 if (defined $response->token) {
  $c->user_session->{’request_token’} = $response->token;
  $c->user_session->{’request_token_secret’} = $response->token_secret;
  my $auth_url = $c->config->{’twitter_authorize_token_url’}.”?oauth_token=” . $response->token;
  $c->res->redirect($auth_url);
  $c->detach;
  return;
 }
}
else {
 $c->log->fatal(”Something went wrong.”);
 # expire request tokens each time they are used
 $c->user_session->{’request_token’} = ”;
 $c->user_session->{’request_token_secret’} = ”;
}

In this example, we ask for a simple request token from Twitter to the request token URL we were given by Twitter in our OAuth settings. In this particular example (it may not be needed by yours), we allow the user to pass a redirect URL to our application via a “redirect_url” parameter in the URL. We store that in the session for later use so we can pass the user onto somewhere else if needed. You could store this in a cookie, a session, a file, or database - it’s up to you, and won’t be necessary if you never need to redirect the user later.

Assuming your app has been authorized to connect to Twitter with the Consumer Key specified, you should get a successful (200 OK) response back from Twitter. You’ll then need to parse out the Request Token and Request Token Secret keys from the response. You can do so by passing the returned content through Net::OAuth->response(’request token’)->from_post_body() as specified.

Once you’ve got that token and a secret key for it, you’ll want to store it somewhere for later use. Twitter doesn’t give it back to your app later, so you’ll need to put it somewhere. In this example we store it in the Catalyst Session for the particular user’s session. You could store them in a cookie, session, file, or database, but you’ll need to put them somewhere. You’ll need this later.

Finally, we need to redirect the user to authenticate and authorize your App on Twitter. You send them to the authorize URL Twitter gives you in your App settings page when you set up OAuth, and append, “?oauth_token=”, followed by the Request Token you just received. Also note the error checking we do - don’t forget to cover your bases!

The user will get sent to Twitter, authenticate, and authorize your App. Finally Twitter will redirect the user back to your callback URL that you specified in your App’s settings when you set up OAuth on Twitter.com. In that URL’s logic, you’ll need to do something like the following:


$c->log->debug("request_token: ".$c->user_session->{'request_token'});
$c->log->debug("request_token_secret: ".$c->user_session->{'request_token_secret'});

my $res = $self->oauth_request($c,
 'url' => $c->config->{'twitter_access_token_url'},
 'type' => "access token",
 'token' => $c->user_session->{'request_token'},
 'token_secret' => $c->user_session->{'request_token_secret'},
);

if ($res->is_success) {
 my $response = Net::OAuth->response('access token')->from_post_body($res->content);
 $c->user_session->{'access_token'} = $response->token;
 $c->user_session->{'access_token_secret'} = $response->token_secret;

 $c->log->debug("redirect_url: ".$c->user_session->{'oauth_redirect_url'});
 $c->res->redirect(uri_unescape($c->user_session->{'oauth_redirect_url'}));
}
else {
 $c->log->fatal("Could not get an Access Token: " . $res->as_string);
}

# expire request tokens each time they are used
$c->user_session->{'request_token'} = '';
$c->user_session->{'request_token_secret'} = '';

At our callback URL, our main goal now is to get that Access Token. We’re assuming the user has authenticated and approved the app. We know the request token and request token secret, but do not yet have an Access Token for the user. Let’s hope you stored the Request Token and Request Token Secret for that user somewhere. You’ll need it here.

To get the Access Token, you’ll need to send an access token request to Twitter, to the URL specified in your settings where you set up OAuth for your App on Twitter.com. In addition, you’ll want to pass into it the Request Token, and Request Token Secret we stored earlier. In this case we stored it in the session, but you’ll need to retrieve it from wherever you stored it earlier.

If your request is successful, you’ll then need to parse the Access Token and Access Token secret from Twitter by passing the returned content to the Net::OAuth->response(’access token’)->from_post_body() method. You can then get your Access Token and Access Token Secret from the returned response, as shown in the example. You’ll then want to store those somewhere, often some place permanent to be accessed later on behalf of the user. In our specific case, since this is just a forgot password form, we only need to store it in the session for access later, which we do in the example.

Now, remember that redirect_url parameter we passed and stored in the session? Now we can retrieve that, and redirect the user wherever you intended them to go after starting the authentication process. In this case, we’ll probably pass them onto the Forgot password page for authentication verification and identification of the user. The code on the forgot password page will look something like this:


=head2 verify_credentials

Verifies the user's Twitter credentials and returns a user hashref if successful

=cut

sub verify_credentials : Private {

 my ($self, $c) = @_;

 if (!$c->user_session->{'access_token'}) {
  return q{Access token must be retrieved from Twitter before we can run verify_credentials.};
 }

 my $response = $self->oauth_request($c,
  'url' => 'http://twitter.com/account/verify_credentials.json',
  'token' => $c->user_session->{'access_token'},
  'token_secret' => $c->user_session->{'access_token_secret'},
  'type' => "protected resource",
 );

 my $retval = '';
 if ($response->is_success) {
  $retval = eval { JSON::Any->jsonToObj( $response->content ) };
  if ( !defined $retval ) {
   return q{Twitter returned success but parsing of the response failed: }.$response->content;
  }
 }
 else {
  return $response->code;
 }

 return $retval;

}

In this example we simply send a protected resource request to Twitter’s verify_credentials call. We parse out the returned JSON response, and voila, we have an authenticated user and all their information! This particular method will return the full user’s data if they are authenticated. We can then use that on the forgot password form to identify who the user is, if they’re a SocialToo user, and it will work regardless if we even have their Twitter username correct, because it relies on the Twitter user id.

So, the final full code you’ll want to use will look something like this (again, I’m using the Catalyst framework):


=head2 authenticate_twitter

Redirects to Twitter to get OAuth Token

=cut

sub authenticate_twitter : Local {

 my ($self, $c) = @_;

#This ensures we only run the following code the first time they authenticate - pass it ?init=1 in the "sign in to Twitter" link
 unless ($c->user_session->{'request_token'} && $c->user_session->{'request_token_secret'} && !$c->req->param('init')) {
  $c->log->debug("getting request token...");

  my $res = $self->oauth_request($c,
   'url' => $c->config->{'twitter_request_url'},
   'type' => "request token",
  );

  $c->user_session->{'oauth_redirect_url'} = uri_escape($c->req->param("redirect_url"));

  if ($res->is_success) {
   my $response = Net::OAuth->response('request token')->from_post_body($res->content);
   if (defined $response->token) {
    $c->user_session->{'request_token'} = $response->token;
    $c->user_session->{'request_token_secret'} = $response->token_secret;
    my $auth_url = $c->config->{'twitter_authorize_token_url'}."?oauth_token=" . $response->token;
    $c->res->redirect($auth_url);
    $c->detach;
    return;
   }
  }
  else {
   $c->log->fatal("Something went wrong.");
   # expire request tokens each time they are used
   $c->user_session->{'request_token'} = '';
   $c->user_session->{'request_token_secret'} = '';
  }
 }
 else {
  $c->log->debug("request_token: ".$c->user_session->{'request_token'});
  $c->log->debug("request_token_secret: ".$c->user_session->{'request_token_secret'});

  my $res = $self->oauth_request($c,
   'url' => $c->config->{'twitter_access_token_url'},
   'type' => "access token",
   'token' => $c->user_session->{'request_token'},
   'token_secret' => $c->user_session->{'request_token_secret'},
  );

  if ($res->is_success) {
   my $response = Net::OAuth->response('access token')->from_post_body($res->content);
   $c->user_session->{'access_token'} = $response->token;
   $c->user_session->{'access_token_secret'} = $response->token_secret;

   $c->log->debug("redirect_url: ".$c->user_session->{'oauth_redirect_url'});
   $c->res->redirect(uri_unescape($c->user_session->{'oauth_redirect_url'}));
  }
  else {
   $c->log->fatal("Could not get an Access Token: " . $res->as_string);
  }

  # expire request tokens each time they are used
  $c->user_session->{'request_token'} = '';
  $c->user_session->{'request_token_secret'} = '';
 }

}

=head2 oauth_request

Sends a generic request to the specified url

=cut

sub oauth_request : Private {

 my $self = shift;
 my $c = shift;
 my $i = {
  'type' => '',
  'url' => '',
  'extra_params' => {},
  'token' => '',
  'token_secret' => '',
  'method' => 'GET',
  @_,
 };

 my $request = Net::OAuth->request($i->{'type'})->new(
  consumer_key => $c->config->{'twitter_consumer_key'},
  consumer_secret => $c->config->{'twitter_consumer_secret'},
  token => $i->{'token'},
  token_secret => $i->{'token_secret'},
  request_url => $i->{'url'},
  request_method => $i->{'method'},
  signature_method => 'HMAC-SHA1',
  timestamp => time,
  nonce => join('', rand_chars(size=>16, set=>'alphanumeric')),
  extra_params => $i->{'extra_params'},
 );

 $request->sign;
 $c->log->debug("URL: ".$request->to_url);

 $c->log->debug("Request: ".Dumper($request));

 my $ua = LWP::UserAgent->new;
 my $response = '';
 if ($i->{'method'} eq 'GET') {
  $response = $ua->get($request->to_url);
 }
 else {
  $response = $ua->post($request->to_url);
 }
 $c->log->debug("Response: ".Dumper($response));

 return $response;

}

=head2 verify_credentials

Verifies the user's Twitter credentials and returns a user hashref if successful

=cut

sub verify_credentials : Private {

 my ($self, $c) = @_;

 if (!$c->user_session->{'access_token'}) {
  return q{Access token must be retrieved from Twitter before we can run verify_credentials.};
 }

 my $response = $self->oauth_request($c,
  'url' => 'http://twitter.com/account/verify_credentials.json',
  'token' => $c->user_session->{'access_token'},
  'token_secret' => $c->user_session->{'access_token_secret'},
  'type' => "protected resource",
 );

 my $retval = '';
 if ($response->is_success) {
  $retval = eval { JSON::Any->jsonToObj( $response->content ) };
  if ( !defined $retval ) {
   return q{Twitter returned success but parsing of the response failed: }.$response->content;
  }
 }
 else {
  return $response->code;
 }

 return $retval;

}

To run it, you’ll (assuming this is Catalyst) point your “Sign in With Twitter” link to /authenticate_twitter?init=1&redirect_url=http://yourdomain.com/forgot on your domain. Note that “init=1″ identifies the user is not yet authenticated. That gets the request token, and redirects the user to Twitter to authenticate. Twitter then sends the user back to /authenticate_twitter on your domain. You detect that the request_token session variable has been set along with the secret key, so then run the code to get an access token. You get the access token from Twitter, store that in the session, and then redirect the user to http://yourdomain.com/forgot (identified by the redirect_url parameter in your original sign in link). http://yourdomain.com/forgot accesses the verify_credentials() method above, which takes the user session variable with the access token, verifies the user’s Twitter credentials, and returns user data for the individual. You can then display user data appropriately, and in this case allow the user to reset their password because you have officially confirmed it is them.

SocialToo Forgot Password Form

Like on Socialtoo, your forgot password form, or other OAuth instance will have a “Sign in With Twitter” link like this one that points to code similar to what I featured.

If you want to learn more, the documentation is pretty scarce at the moment. Hopefully myself or someone else will put together a much more abstract set of libraries targeting the Twitter platform soon surrounding this. I do recommend checking out OAuth.net and understanding the OAuth protocol a little more, along with the Net::OAuth documentation. Hopefully many more of you can share your experiences in the comments, or in your own blogs as you come across new experiences with Twitter’s OAuth in a Perl environment.

UPDATE: Looks like someone already has added an abstraction layer around all this. To simplify things even further, check out Net::Twitter::OAuth. It might be helpful to read this first anyway so you know what’s going on there.

What Would You Like To Learn About Social Web Development?

Help is on the wayOne of my strongest expertise is developing web apps that utilize Social APIs and technologies.  My website, SocialToo is built all around these.  I’ve written a book on the subject, and reviewed others.  I’ve blogged about it, and written many apps myself, and consulted for many others.  I wrote one of the first howtos on Facebook Connect development, and wrote the very first Facebook Connect Wordpress plugin.

However, I’ve realized that I’m not sharing that much.  I have presentations I’ve shared via Slideshare, but those just don’t do it justice.  I’d like to share more here on this blog, do a few geeky howtos for the developers and coders out there, and hopefully help a few of you out.  I’m not quite sure where to start though.

So my question for you is, what would you like me to talk about?  What would you like to learn?  It can be any Social Network API, really.  If I don’t know it yet I’ll go learn it and share it with you.  I’d like to help you learn what you don’t already know though.  I figure I’m pretty good at this stuff, so I may as well share it.  So, what would you like me to talk about?  Trust me, it will be much more interesting if you tell me, than if I just guess myself.  How can I help you?

Image courtesy Cory Doctorow

Looking for a RockStar Facebook or OpenSocial Developer?

Robert Scoble - the original RockStarSocialToo.com has been a huge success for me so far. Just this last month we have gone from just less than 1,000 users to over 7,000 users, and that number shows no sign of slowing down. We’re starting to monetize the site, via one-time purchases of various services, advertising, and will be adding some premium features very soon. I’m slowly actually starting to monetize a service based on Social Media, and thus far, I’m proving it’s going to work.

However, I’ve just about exhausted my resources financially to continue supporting this on just my own savings alone, and have decided it’s time to find something full or part-time that can supplement SocialToo. I am also looking for financing and investment as an alternate source of income, but in tough economic times I have to put my eggs in multiple baskets to ensure something works out.

So, here’s what I have to offer. If you’re looking for a RockStar Facebook, OpenSocial, Twitter, YouTube, or you name the Social Media platform developer to take your app to the next level, I’m your man. I have a very strong software development background which you can see on my LinkedIn profile. I have written two books on Facebook, one on Facebook Development and FBML for O’Reilly (see those in the upper-right of the blog), and one on Facebook professional growth and marketing. I speak and teach others regularly on the subjects of Facebook, Twitter, Social Media, and related topics. I have a good following on multiple networks and a great platform to build your brand as an employee or consultant for your company. Any such relationship would be announced in full disclosure here and any other place it makes sense to mention the relationship. In addition, I am an entrepreneur at heart, which means I have passion in the products I help build. I love seeing these things grow to become successes!

I can develop software - I wrote SocialToo.com from the ground up, by myself (with thanks to some great advisors). I can market Social Media. I am learning to monetize Social Media. I have a successful business, and have helped businesses based on Social Media become successes. So, if you or your company are looking for someone with my skills, let’s talk. We can talk full time relationships, consulting relationships, temporary relationships. I’d love to help you out. Oh, and international is definitely an option - I speak fluent Thai, some Spanish, and even some Indonesian and am no stranger to learning new languages and cultures!

At the same time, if you know anyone looking for a good investment that will make money in the near future please forward them my way. In either scenario, SocialToo will continue to grow, will continue to be a focus (while if I work full time for you it will be a side-focus), and you can continue to expect to see the same growth you always have as we move forward. At the same time, I’m a hungry entrepreneur.

You can read my LinkedIn profile at http://linkedin.com/in/facebook

My contact info is in the upper-right of this blog.

Please Re-Tweet

Photo courtesy the talented Brian Solis

Remember When Your Followers Were Deleted? Twitter’s Done it Again!

whale.pngEarlier in the year you may remember Twitter “accidentally” deleting a large portion of a majority of their users’ followers and having to spend days restoring those from tape backup due to their mishap. Well, it would appear that Twitter has done it again. This time may not be as obvious to users.

On SocialToo.com I was noticing we were getting “Rate Limit Exceeded” errors for our whitelisted @socialtoo user. Such errors shouldn’t be happening for whitelisted users so I looked into it. Sure enough, on the Twitter development mailing list I noticed an email from the founder of MrTweet, Yu-Shan Fung, stating they too were seeing the same issue with their @mrtweet whitelited user.

Alex Payne, Twitter API Lead, confirmed the issue, stating, “It looks like some database maintenance inadvertently truncated our table of whitelisted users.” He then continued in a follow-up e-mail making the problem seem worse: ‘The updated estimate I’ve just received from our ops guys is “more
than 15 minutes and less than 12 hours”. They have to restore from a
nightly database backup. Said backups are quite large, and take some
time to get through.’ It would appear that Twitter has inadvertently deleted an entire table of all the whitelisted users - this is the table that enables many of the Twitter Apps you use to continue to talk to the API without breaking. This is what we as developers are relying on to work or our Apps go down.

It was the exact issue of database deletion and insecurity of Twitter being competent enough to not do it again that caused me to go on hiatus from Twitter earlier in the year. Problems like deleting an entire table from a database, especially twice in a year, are inexcusable Twitter! I recommend finding someone that can ensure this doesn’t happen again. It’s time to upgrade your Operations team. As developers, we simply can’t rely on this, and it’s why I called my service SocialToo and not TwitterToo.

In the meantime, many of the Twitter services you use until this gets resolved may have issues. This includes SocialToo.com autofollow being down until the table in the Twitter database is up again. I’ll keep you updated on the @socialtoo Twitter account when this comes up again.

Facebook Development for Beginners

This morning I had the opportunity to present via O’Reilly Webinar on Facebook development. I covered the basics of how to get started in Facebook development, and the resources that would get you going. I mentioned I’d post these slides online, so here they are. I was hoping to get audio attached to them, but we’re still waiting on that. Regardless, if you want me to present this to your organization or group, feel free to contact me.

Facebook Development for Beginners

The Flash plugin is required to view this object.

View SlideShare presentation or Upload your own. (tags: facebook fbml)

Looking for iPhone and Facebook Development and Consulting Shops

With my new work at i.TV (go visit the iTunes Store Home Page if you want to try us out - lower right-hand corner), I have started phasing out my consulting (which used to be my full-time job) and am putting my focus towards building (with a top-notch team and great CEO, of course!) one of the top Entertainment App companies out there. In the process, I am still getting 5-10 people a week contacting me asking if I know anyone that does iPhone or Facebook Development. Quite frankly, finding someone to refer to is not an easy task! That is what I used to do, so it wasn’t something I was looking for (and I know there just aren’t many out there, as well, even with the high demand).

So, if you or someone you know does either iPhone or Facebook development, or work for a company that does, I want to make a deal with you or your company. I’ll send you these referrals for a commission on the deal you make with them. This is a win-win for all - I now have someone to send referrals to. You get the referrals and regular business, and the Clients now have someone they can get help from. Having written books on Facebook, and working for a company that does iPhone App development, along with this blog growing considerably and guest blogging on some of the top blogs on the internet, I get these requests regularly - I’d really like someone to send them to.

If you’re a developer, perhaps you’re starting to see the demand of Facebook and iPhone development. This is an excellent area to have knowledge in, in particular in a down economy. If you’d like to learn I do recommend you look at my book, FBML Essentials, and at the end of this month I’ll be doing a free webinar for O’Reilly in which I’ll cover beginning Facebook development. Stay tuned to this blog and I’ll reveal more details soon.

Know a Facebook or iPhone development company or developer? Shoot me an e-mail (or comment below): jesse at staynalive dot com or call me at (801) 853-8339. Also, if your business is in need of such work, give me a ring and I’ll point you in the right direction!

Facebook Developers See 20-50% Drop From URL Change

Picture 8.pngFacebook developers are reporting 20-50% drops in their Application traffic due to an unannounced deprecation of the old apps.new.facebook.com URL by Facebook. Over the weekend, Facebook appears to have deprecated the apps.new.facebook.com domain, but some developers are reporting that users aren’t recognizing the new domain, apps.facebook.com, causing the drop in traffic.

The apps.facebook.com domain is the central location for all applications on Facebook. Developers are given a unique suffix to the apps.facebook.com domain, giving apps.facebook.com/appname a unique location for every application on the Facebook platform. Facebook created the domain, apps.new.facebook.com to accommodate apps trying to test in the new design as it was in the process of being released. Now that all users should be transitioned to the new design, it appears that Facebook has decided that the two URLs are no longer necessary.

Facebook (perhaps not as often as Twitter) is known for changes like this. While it’s been awhile, the early days of the Facebook Platform were prone to frequent changes by Facebook with little notification by the company. For this reason, Facebook implemented a beta testing ground before pushing changes so bugs like this would be revealed, but it appears Facebook is not using this testing ground in all cases. As one developer put it, “I was planning to go on a sailing trip today, but when I noticed all the problems had to cancel that to fix all the absolute urls I had.” Unannounced changes like this, with little testing, are bound to cause developer frustration and angst as we’re seeing now.

Facebook has put in place a Status Feed to announce such things, and just last week announced that over the weekend the new “api.new.facebook.com” would point to the same place as “api.facebook.com”. Being a backend process, Facebook mentioned nothing about a deprecation of the apps.new.facebook.com domain. Also, any user that previously had an apps.new.facebook.com domain bookmarked will now be sent to a 404 not found page.

We have yet to hear an announcement by Facebook on this matter.

UPDATE: For some reason the link to the forums above has been removed and the post is gone. The text of the main link is below (written by crimson), followed by a long list of other developers seeing the same thing:

I’ve been doing some testing with the recent DNS errors and it seems that for most users, apps.new.facebook is broken. It’s sporadic though, and only affects certain user accounts at random times. I haven’t heard any complaints about apps.facebook.com being broken though, so I would suggest putting a message on your about pages asking users to go to apps.facebook.com instead of apps.new.facebook.com. If you have any absolute links to apps.new especially in notifications, newsfeeds, or notifications, you should also get rid of those immediately since it will cause your users to end up on the new domain, which will rewrite all urls from apps.facebook.com to apps.new.facebook.com, and can lead to further problems.

It’s so annoying that Facebook decided to do this over the weekend, which means we have to work also on the weekends. I was planning to go on a sailing trip today, but when I noticed all the problems had to cancel that to fix all the absolute urls I had. I found I’m losing anywhere from 20-50% of new users simply because of this issue. It also seems that at times only apps.new.facebook is broken, and not www.new.facebook. Hmm, talk about double-standards.

UPDATE 2: Facebook appears to have fixed the problem - when I checked today, apps.new.facebook.com was again correctly redirecting to apps.facebook.com

UPDATE 3: It appears other developers are still seeing the issue, still no word from Facebook: http://staynalive.com/articles/2008/10/06/facebook-dns-blunders-take-down-obama-app/

Facebook Applications See Success On the New Platform

facebook_pic.pngRegardless of any complaints from developers surrounding the new Facebook platform redesign, many developers are seeing success. Looking at various statistics from sites such as Adonomics and the Facebook Developers Forum, it appears that those apps that are truly integrating the new Integration points that the Facebook Platform provides are truly seeing success with it. Those apps that remain stagnant will see a decline in behavior.

Apps That are Seeing a Decline

Reviewing the apps complaining of the new design and showing declines in their numbers, it appears that many of them aren’t integrating into the new design where they are supposed to. I’ll use my own app as an example. “We’re Catholic!”, one of the religious apps I wrote and run (I also run “We’re Baptist”, “We’re Protestant”, and wrote the app, “The LDS App”) at one point was getting up to 1,000 visits per day (DAU’s, or Daily Active Users) as it was taking off (it is still currently the largest single group of organized Catholics on Facebook). Users began to get used to the Facebook platform, and that leveled it off to about 2-300 DAU’s per day. At launch of the new design, that number has gone down 1-200 DAU’s per day. What’s not being told in this picture is that I have done absolutely nothing to integrate it with the new design due to lack of time. I have no doubt that with a little integration into the user’s profile with a tab, and maybe info section, along with some Feed Forms to give users the option for larger stories to share with their friends from the app, I could very well see my app stats increase to even more than they were before.

Picture 3.png

Pieces of Flair

app_1_3396043540_8126.gifThis seems to be the issue with some of the apps developers are complaining about. One example pointed out in the Facebook developer forums is the Pieces of Flair app, by RockYou. Looking at Adonomics statistics, it appears on September 4, the week the new design was put in place, Pieces of Flair took a dramatic turn from near 660,000 Daily Active Users down to around 350,000 DAU’s in just a matter of a day. They were stuck there until September 16, where their DAU’s went up to 570,000 in just a day, still far short from the 660,000 DAU’s they used to have. Then, on Sept 18, the DAU’s went back down to around 400,000. Looking at this statistic, it would appear that Pieces of Flair isn’t doing very well, and that the new Facebook Platform redesign is to blame. To know for sure though, you have to look at the timeline of events related to the App.

Picture 4.png

Facebook Platform Timeline

September 4th, 2008 - New design launches to all

Looking at the history of the new design rollout, the new Facebook redesign was rolled out right on the week of September 4th, which would make the sharp downturn very understandable. At that point users were getting used to the new design and learning where things were.

September 10th, 2008 - Applications link moves

Right around September 10th or 11th it seems Facebook moved the “Applications” menu from the top down to the lower-left panel on Facebook. In addition, users could “bookmark” their favorite apps. Could Pieces of Flair have been one of those users were bookmarking? Other apps were bound to have seen a decrease because of this change.

September 16th, 2008 - Pieces of Flair makes changes

September 16th took some research to figure out. Looking at the forums on the Pieces of Flair About Page, several users started commenting about how it was now possible to add the app’s profile box to their “wall tab”. It’s unclear if they added a specific application tab at that point or not, but there was definitely an increase at that point, and it looks like it may be because of a change put in place to adapt to the new design by Pieces of Flair.

September 17, 2008 - One-line feed stories consolidated

On September 17, Facebook consolidated one-line feed stories that happened frequently for a single user in a day into one item in a user’s news feed. This would have reduced the visibility of some apps that updated frequently, perhaps explaining the slight decrease on the 18th.

Is it a Facebook Problem?

So, analyzing by date, it would appear that the biggest drops for Pieces of Flair may just be that Pieces of Flair wasn’t yet built for the new design when it was rolled out to members. Perhaps the new design isn’t to blame, but rather unpreparedness by developers of apps that are to blame for the decrease in traffic. Facebook announced the new design back in May, and developers have had since then to prepare - it would seem that this is a developer, not Facebook problem.

Apps Seeing an Increase

Regardless of the complaints, there are apps seeing an increase. While names weren’t mentioned, several developers in the Facebook developer forums posted stats that show such. Even Pieces of Flair we see is starting to show a gradual increase since feed stories were implemented.

We’re Related

app_1_5388815661_964.gifSome have shown significant increase though. One of the most significant is We’re Related, which went from 180,000 DAU’s to 460,000 DAU’s when the Applications menu was moved, an all-time high for them. It seems the only decrease they ever saw was right after the redesign was launched. Some developers are claiming they’re spammy, but based on the stats in association with the time-line it appears regardless of spammy measures or not, they’re increasing because users like them and are bookmarking them as a favorite - they shot up more than any other on the date Facebook implemented bookmarking. (disclaimer: they were a client of mine and I trained some of their developers and helped design their initial release, so there is some bias there, but the stats do coincide with what I’m saying. I hold no equity in the company.)

Picture 34.png

Texas HoldEm Poker

app_1_2389801228_4683.gifAlso of note is the Texas HoldEm Poker game. One of the most popular apps on Facebook, it would seem they too have never seen much of a decrease in usage. They too saw a slight drop after the redesign, but, while not as significant as We’re Related, they are definitely higher in DAU’s than ever before.

Picture 13.png

WaterCooler, Inc. and (lil) Green Patch

Some other Apps to look at are WaterCooler, Inc. (a conglomeration of many smaller apps), and (lil) Green Patch, all which have continued to show an increase, even after the new design. Of course, Facebook’s native apps have also shown significant increase after the new design, but they may be the exception in the fact that they get special promotion by Facebook in areas developers do not have access to, and are default for many people on Facebook.

Reasons for the Increase

As “DesignerMichael” put it in the Developer Forums, “The golden days will return in about a month though by my estimate. Users will finally start getting used to the new platform again by around then… So all is well. smile Just no more ridiculous changes please… Changing the location of bookmarks once a week is not good for apps. lol…”. It appears, based on the common drop amongst all the apps, that the major issue for developers is that users just haven’t gotten used to the new design yet. Assuming Facebook does not put any more changes in place, things will get back to normal.

In a communication via e-mail with Facebook, I was given the following message about the current state of the platform:

“We’ve seen a number of areas with greater engagement and sharing across the site, both on our own applications and on Facebook Platform. Daily and weekly active usage for applications have been on a healthy growth track for the past six months. Since the cut over began, aggregate Platform usage has continued to increase. The apps that have made the greatest effort to take advantage of the new integration opportunities are starting to see the results.”

Facebook is monitoring this. Without their developers, Facebook is not nearly as powerful as they are now. Currently developers are doing the marketing for Facebook and I’m sure Facebook recognizes that. However, it appears that in the end, as we see with the success of those apps that are seeing an increase, that it involves some work on behalf of the developer to happen. Some areas Facebook suggests are bringing more traffic to apps, or have the potential to do so are:

  • Deeper integration into the profile
  • Greater distribution through feeds
  • Easier for users to discover new apps
  • More meaningful user engagement
  • Customized application tabs

For developers of apps, you can bring your application to even higher Daily Active Users than before by simply finding new ways to integrate with the different points mentioned above. It is very possible to be successful on the new design, and now is the opportunity for new developers to come forth. We’re in a new race for popularity, and those apps that embrace the new features most will see the most success.

In FBML Essentials (O’Reilly), I cover some of the points of the Facebook platform new design components. You can purchase and review it here on Amazon.

Is Your Company Having Success on the New Facebook Design?

I am looking for examples of companies and developers actually having success in the new Facebook design. If your app, or the app of someone you know on the Facebook platform is having proven results as a result of the new Facebook design, or if your traffic has not decreased from it, I want to hear from you. Those that respond have the chance of being featured here or as a guest post on LouisGray.com. Please feel free to share in the comments or send me an e-mail at jesse@staynalive.com with your stories. I want to hear from you! (And, please share this with others you may think would be in the know - this is a great opportunity for some exposure for your Facebook app!)