Twitter Archives - Page 9 of 21 - Stay N Alive

Gmail is My FriendFeed Client

nano-logo-5581093A couple days ago I showed you my own unique way of managing Twitter. This method utilizes my e-mail client, Gmail, to track and force Twitter messages to come to me instead of myself needing to constantly check the site or my preferred Twitter client for new messages about me, my brand, or other topics I like to monitor. I’ve also spoken recently about my hiatus from RSS and how I’ve significantly reduced the number of feeds I monitor and instead I “media-snack” (as Robert Scoble calls it) on FriendFeed where I am still able to get as much, if not more information about the latest and greatest tech news as I have always done before. But how do I manage FriendFeed? You may be surprised to hear that I do it in almost the exact same way I do Twitter – I use Gmail. Here’s how I do it:

Native FriendFeed Notifications

Let’s start with the fact that FriendFeed actually provides its own useful ways of monitoring your conversations so you don’t have to keep coming back to the site, something Twitter and various Twitter clients have not been very good at doing (PeopleBrowsr seems closest to providing the ideal solution to this). On any page (except saved searches – we’ll get to that later), you’ll notice a new feature in the upper-right that says “E-mail/IM”. If you click on that it will drop down some more options. You can select it to deliver just new posts on the given page, new posts and just your friends’ comments, or new posts and all comments. You can then select any option to deliver those to either your e-mail, IM client, or FriendFeed’s own native desktop popup client (which you can download and install here). FriendFeed then uses the e-mail and IM settings you have set in your settings to deliver this information to your desired location. The great thing about this is that you can use it for any of your friend lists, any room on FriendFeed, or even your own discussions page (“My Discussions” on the right).

picture-2-3070109

So here’s what I do: I simply went to my “My Discussions” page, selected the option to deliver all new posts and all comments to my e-mail client, and now anything I comment on, or like, or any likes or comments on the posts that I import into FriendFeed now get delivered to my e-mail account. I don’t miss any of the conversation this way .  I think everyone should do this, even if you don’t participate on FriendFeed because it ensures you know, immediately, when anyone comments on one of the things you’re already importing into FriendFeed. If you’re not actively using FriendFeed, you should do this out of respect to those that are.

Now here’s where Gmail is important: if you actively like or comment on other members’ posts, you’ll then get every single comment on that post afterwards. Usually, that’s not so bad, if you’ve ever participated in one of Robert Scoble’s threads, or any other hot topic on FriendFeed, you’ll quickly notice that the number of comments can go into the hundreds at times. This will very quickly fill up your inbox!

Gmail solves this problem easily. On the thread in Gmail you’re tired of hearing from, simply click the “m” button on your keyboard. Instantly, the thread gets moved to your Archive folder and you’ll never see it again unless you click your “All Messages” folder. You’ll notice in that folder it now has a “muted” label next to it. Go to the thread and click “m” again and it will un-mute itself. There’s no better client for managing this. And if you know me, I’m religious about reading all my e-mail. Gmail makes this possible.

In addition, FriendFeed also enables users to respond to the conversation, right in their e-mail client. I simply hit “reply” on any conversation I want to add to right in Gmail, and my comment immediately (yes, in real-time) gets added to the conversation. Not only that, but you can easily DM me on FriendFeed, yes, via your e-mail client. Simply send any message, including photos (works great from my iphone!) to jessestay@friendfeed.com (my username@friendfeed.com – works the same for your username) and your message will go straight to my FriendFeed DM box. Or, send any message, or photos (again, works great from my iPhone!) to share@friendfeed.com and your message and/or photos will go straight to your public stream on FriendFeed. You never have to leave your e-mail client.

Now, what if you want to track what others are saying about your brand, and don’t want to have to keep checking back in your saved searches links on the right in FriendFeed? (you are using saved-searches, aren’t you?) Yes, there’s an app for that.

Introducing BackType

We’ll cover this in the next post in this series more thoroughly, but BackType is a service that tracks and reports comments around the web. FriendFeed is one of the sites it tracks comments for. To get notifications when your name is mentioned on FriendFeed, simply go to BackType, set up a saved search for your name, brand, or whatever other terms you want to track, enable e-mail alerts for those saved searches, and now you’ll get mention of everything anyone says about you on FriendFeed. I don’t miss a thing anyone says about me – try and mention my name somewhere and see!

By enabling users to manage their brand and conversation via e-mail, FriendFeed has just become the most manageable micro-blogging client and service on the internet. Now I get to treat my news like a newspaper – pick it up at my own leisure, “media-snack”, read what I like, and put it down. I don’t have to worry about missing anything, and most importantly, I don’t waste time needing to constantly check the site to see if someone has said something I need to know about.

So thus far I’ve managed my online identity through:

  1. Significantly reducing my Google Reader and RSS subscriptions by unsubscribing and “media snacking” on FriendFeed subscriptions
  2. Managing my Twitter brand through TweetBeep and my e-mail client
  3. Managing my FriendFeed brand through IM/E-mail notifications, BackType, and Gmail

My next installment of this series will be about how I subscribe to your blogs through Gmail.  Sure, I’ve talked about how I use Google Reader to manage the subscriptions I absolutely can’t miss, but what about the stuff that slips through the cracks?  I’ll show you how to use BackType, Google Alerts, and other tools to ensure this doesn’t happen.

GMail is My Twitter Client

TweetBeepI’ve mentioned multiple times I’m a fan of multiple Twitter clients. I’m a big fan of TweetDeck due to its Twitter and Facebook support, the TwitScoop support, and groups and saved searches support. It’s also pretty stable and doesn’t kill my computer when I use it. I’m a big fan of Seesmic Desktop because it has group support and multiple Twitter account support (along with Facebook support). I love Tweetie because of its simplicity, lack of memory usage, native support for the Mac, and the iPhone version I like for the same reason.  I also love CoTweet for its easy management of Twitter from a business perspective.  However, I think you’ll be surprised to learn that I rarely use any of them any more. My new preferred Twitter (and even FriendFeed) client: Gmail.

Let’s face it, whether I follow all those that follow me and segment out my favorites into groups (in a client like TweetDeck or Seesmic), or if I only follow a select few, my responsibility is still the same. I need to know what is said about me, my brand(s), and any other interesting things people are saying that I need to know about. Frankly, I can’t do this effectively while only tracking the small numbers of people I follow using one of the traditional Twitter clients. There would still be people talking about me, or the topics I’m interested in elsewhere, whether I follow them or not. The whole follow/friend game is incredibly ineffective for this reason, regardless of the method you use – it’s one of the reasons I just auto-follow. At least you can DM me if I let those that follow me do so by following them back. I decided I needed a better solution.

As it turns out, Twitter search (when it works) is fairly effective at catching what I want to hear on Twitter. I can search for @mentions of my name, my old Twitter account, misspellings of my name, my company, topics I’m interested in hearing about, and more. It returns the data I want. The problem with that is that I have to keep checking back for it, and there’s no really good way to save searches. I could do it in TweetDeck or Seesmic Desktop, but even with those I need to continue checking to be effective. I think that’s a waste of time. Why not make the Tweets come to me?

Yes, there’s an App for that. Michael Jensen (@mdjensen on Twitter), a Twitter, FriendFeed, and iPhone developer (and Perl developer!) is the author of a site called TweetBeep. Louis Gray turned me onto it, as this is also one of the ways he tracks mentions of his name. All that needs to be done is to sign up for an account on TweetBeep, provide your Twitter credentials, and specify search criteria you want it to search for on your behalf.  You can create as many alerts as you like, and it’s 100% free! Specify the frequency of the alert (hourly or daily), and now all mentions of the terms you want it to track, including mentions of your Twitter username, brand(s), name, and more will all be delivered to your e-mail inbox. It will also track domains, and automatically un-shorten various URL-shortening services so you can also track mentions of your domain name.

So now, with TweetBeep I am no longer regularly checking my Twitter client of choice to see if anyone else has said something I might be interested in. I have those delivered to me, in batch, via e-mail, and I have saved myself a ton of time doing so! Because of my use of Gmail and TweetBeep to manage Twitter for me I am very rarely needing to check Twitter any more. Now, if I could just break the habit of checking it anyway!  I guess you could say I now truly follow, and listen, to millions of people – I just now have a way to sift through the noise.

Tomorrow I’ll be sharing how Gmail is also my FriendFeed Client – you’ll like this one so stay tuned…

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.

Here’s How to Make #followfriday Work With the New Twitter Changes

#followfridayI mentioned on Tuesday in response to Twitter’s new changes that it could be impossible for anyone to see your suggestions on #followfriday if you started your Tweets with an “@”. Based on your responses, my assumption was part right, and part wrong. #followfriday is not going away (as long as Twitter users don’t want it to). You’re just going to have to do it a little differently, and perhaps that’s a good thing.

My point of Tuesday’s post about the changes was to point out Twitter’s attitude and seeming desire to make us use Twitter the way they (the founders and employees of Twitter) use it, rather than the way we like, and how that could affect the very democratically created tradition of #followfriday from week to week. I was amazed at your response! I believe this blog had a new record, currently standing at 101 comments on a single post, all of you sharing your opinions, sharing advice on how it could work, and what you thought of Twitter’s new decision. Twitter has since clarified the Kerfuffle (say that 5 times fast, and why won’t Safari count that as a real word?) in finally a manner that they should have done in the first place. While I would still like some more promise on how they’re going to warn developers of such changes in the future (since we were affected by this as well), I think they’re at least starting to approach this in the right manner.

So, let’s talk #followfriday. It can still work. It just needs to be done differently to work. Lately, while I appreciate all your suggestions and recommendations, I’m noticing a trend which I think these new changes by Twitter actually put an end to. That’s the trend of listing just a whole bunch of Twitter screen names, followed by the hashtag, “#followfriday”, and nothing else. You’ve just recommended me to all your friends, along with about 10 others, and no reason why they should follow you. Do you think anyone pays attention to that? And if they do, will they remember the people you have just recommended? It turns out that with the new Twitter changes those can’t work anyway, because they begin with an “@” sign.

Let’s start a new tradition. I suggest selecting no more than 2 individuals every Friday. They should technically be individuals on more than one service – that can be Twitter and FriendFeed, or Twitter and Facebook, or maybe even Twitter and LinkedIn or whatever other 2 services you want to think of. You should come up with a 140 character version of your tweet, 140 characters for each individual explaining why your followers should follow each of those individuals in as much detail as possible and then post it to a microblogging service (like Twitter) somewhere. Then, on a service that allows more than 140 characters, maybe even your blog, share much more about that individual. Explain what they do, how they got there, what makes them interesting, and better yet, include a picture!

I noticed this last week as my friend, Mari Smith, shared her #followfriday entry on Facebook. She included the name of the individual, a very detailed description of why she was suggesting we become friends with the individual, and she even included a picture! Mari then continued to endorse this individual in the comments.

I think this is a trend we should all continue. Again, your Tweets can’t start with “@” – sure some can in certain instances, but let’s just not confuse ourselves here. Either start your Tweet with #followfriday and a description with the screen name of the individual, or just start your description and include their screen name some where that makes sense. What’s important is that there is detail about the individual. It’s time we start some real dialog here. Let’s build real relationships and do it in style. Make your #followfridays count by doing fewer, but with more substance. Perhaps you could even start in the comments of this post!

Did Twitter Just Kill #followfriday?

TwitterYes, I believe Twitter has just become even less useful. In a very vague statement today that I guess Twitter doesn’t expect us to understand, Twitter removed, without warning or feedback from users it would seem, any and all Tweets in your stream that include @replies to people you are not following. Previously this was an option you could turn on or off, but Biz Stone, founder of Twitter, says in this “small settings update” that “receiving one-sided fragments via replies sent to folks you don’t follow in your timeline is undesirable. Today’s update removes this undesirable and confusing option.”

It would appear that Twitter again seems to think Twitter should be used in one way.

What it would appear just happened is in a single blog post, Twitter has killed the weekly phenomena, #followfriday. The tradition was to refer people your followers may not know, but you recommend following. With the removal of this feature, if I’m understanding correctly (please correct me if I’m wrong), you will no longer see #followfriday posts with names of users you don’t follow, rendering #followfriday completely useless.

Confused? Based on the last sentence of their post, it seems that Twitter doesn’t care.

UPDATE: Twitter has removed the last sentence that said “Confused? That’s understandable and exactly why we made the update.” and instead replaced it with the following clarification:

The Importance of Discovery

Spotting new folks in tweets is an interesting way to check out new profiles and find new people to follow. Despite this update, you’ll still see mentions or references linking to people you don’t follow. For example, you’ll continue to see, “Ev meeting with @biz about work stuff” even if you don’t follow @biz. We’ll be introducing better ways to discover and follow interesting accounts as we release more features in this space.

UPDATE 2: It would appear you still can’t see the above Tweet if it starts with @biz and you don’t follow @biz, removing many valuable discoverable Tweets from your stream.

Utah Republican DM Fails His Candidacy Announcement

Mark ShurtleffToday (about 2 hours ago), Utah Attorney General, and rumored Senate Candidate Mark Shurtleff, in an apparent “DM Fail” with what would appear to be Political Consultant Ben Cannatti, accidentally announced his candidacy for Senate. Attorney General Shurtleff has been rumored to be running against the current seated Senator Bob Bennett in the upcoming election, making this no surprise, but a solid confirmation it would seem.

Shurtleff recently appeared in a recent Fox 13 News segment on Facebook boasting his use of Social Media and its potential advantage it could give him in the pending run for Senate. Shurtleff ironically stated on Twitter his realization in what he thought was an SMS to Cannatti, “…I just realized that I was responding to a text from u. I’m going to pull it off immediately”. Other interesting Tweets, “…it will also be against Bennett and I’ll pick up his delegates when he drops off the first ballot. I’m announcing I’m running at 12”. He also shared he “would have no trouble raising up to $2 million”. The original Tweets have been removed but you can read the 140 character version of them (which is cut off) via Twitter search still.

It also comes on the heels of other mishaps by other Republicans. Just recently, Virginia State Senator Jeff Frederick posted on Twitter, “Big News coming out of Senate: Apparently one Dem is either switching or leaving the Dem caucus. Negotiations for power sharing underway.” The Virginia Senate Democrats saw the post and were able to secure their majority by closing the session early and convincing the State Senator Ralph Northam not to switch sides. The Republican party is no stranger to such mishaps.

In response to today’s Twitter DM failure by Shurtleff, he humorously responded, stating in a Tweet, “Thinking of “texting while drowsy” law after private 1AM tweet went public. Formal announcement on 5/20 about senate race and tweeting plans”. It will certainly be a lesson learned for him as he tries to obtain Bennet’s Senate seat through use of Social Media. Mark Shurtleff, contact me if you ever need help!

You can see the full conversation via Twitter search below:

Mark Shurtleff DM Fail

Oops, Twitter Does it Again

Oops I did it again - Britney SpearsI don’t think Twitter is listening. In fact, I remember a few of them mentioning they don’t read the news or blogs so that it doesn’t affect their work. Perhaps it’s about time they start. Today I blogged over on LouisGray about a cool new change to the e-mail notifications on Twitter where they now show a user’s profile image and follower/friend data along with the new follower e-mails they send to you. (and dang it – MG beat me to the news. He’s good!)

What is scary though is what actually happened behind the scenes in this change. Today Twitter, again without notice to developers, completely changed the format of both their new follower and DM e-mails from plain text, to HTML multi-part format, completely breaking any app that was relying on those formats to parse and process new follows or direct messages.

What’s funny is that the very apps I was saying Twitter was venturing into competing ground with, Topify, and Twimailer, are the very types of apps that would have been broken by this change. In addition, apps like Greg Lavallee’s addNetflix app are now broken because they were relying on the plain-text format of the new DM e-mails. In my previous post about Twitter doing this, Greg commented, stating, “When I first read this post last month I thought, “well, if you code your application well, it should take into account potential changes from Twitter.” I also thought that Twitter would warn us about bigger changes. Wrong on both counts.” Many apps are relying on these e-mails, some of them probably completely unaware their apps are broken at the moment.

This issue was brought up on the Twitter developers list this afternoon by TwitReport developer, “TjL” (“Can Twitter Please Pick a From, and Stick With It?”). Evidently the new format also broke the new follower statistics for his app, and has happened multiple times causing him to have to re-educate his users to re-do their filters every time. Matt Sanford, Twitter API Team member responded explaining,

“We had changed the from address to try and improve bounce reporting and prevent being marked as spam by major ISPs. When we added the HTML formatting we found that we needed a consistent address for the ‘always display images’ option in many clients so we changed things around again. Hopefully this will be the last change as it causes us a bunch of work as well. I’ll keep an eye out for future changes and try and let people know.”

The conversation went on to discuss further elements of the e-mail, and Sanford suggested they were going to change the e-mails again after the discussion. I think TjL reflected the developer community’s frustration exactly when he responded to the further changes,

“Seriously? I’ve already started telling people to change their filters
and now they’re going to break *again*.

This is why daddy drinks.

All kidding aside, I don’t understand how a change like this gets
pushed out without the left hand knowing WTF the right hand is doing —
which is what it looks like (from an outsider’s perspective) happened.

IMO/FWIW: You’ve gotten too big to make these sorts of changes without
more consideration and communication. It makes me look bad as a
developer, and it makes Twitter look bad.

The irony is that you’re a company built around communication.”

Twitter has got to change their ways – on my blog posts about this I’m seeing comment after comment of developers now refusing to develop on the Twitter development platform because of their lack of warning during changes like this. The thing is I’m not complaining about rate limits or Twitter scalability or anything like that at all when I’m complaining. As developers, we simply want a little bit of communication before changes go out. I actually like Twitter. I have a business with components built on it so I want it to succeed. I also think the Twitter dev team has done an outstanding job building out this amazing API. The only area they’re failing in right now is communication. We need a) a clear developer ToS, and b) warning before changes go in, or come out. Developers have been amazingly patient for the most part regarding this, but I know there is frustration.

I want to be clear that I love what the Twitter API team is doing. I really like and respect Alex and Matt and the rest of the team working extremely hard, often to the late hours of the night working on this stuff. I’m not sure where the fault lies, but I do hope they are listening. We need some warning on this stuff guys.

There is still no official announcement on the Developer mailing list, nor any official blog post by Twitter on the e-mail changes.

Is Twitter Seeing a New Form of Spam Attack?

Please note this in no way is inferring @nycgrl88 is in any way behind these attacks – it is simply an attempt to figure out why these bots are targeting her.

irobotMy friend Scott Lemon, who runs http://topfollowfriday.com pointed me to this.  It would appear that someone or something has hacked the Twitter sign up process and is creating hundreds of bot accounts, all with the same messages, including one linking @oprah, @mrskutcher, and someone named @nycgrl88 to #topfollowfriday as a recommendation.  You can see all the accounts via Twitter search result here.  They are all posting exactly the same Tweets, all prefixed by 1luv, and complain of things like not being able to upload a photo or background image, a problem Twitter was plagued with yesterday.

Since @oprah and @mrskutcher are obvious names, I naturally looked at the odd one out in the #topfollowfriday recommendation, @nycgrl88.  Her name is Jennifer Regan, and according to her bio, she goes to NYU and lives in New York.  Oddly enough, all of the @1luv spam accounts are owned by a girl named Jennifer (with bio pics that all kind of look similar, but brunette), who lives in New York and goes to NYU.

Could this be a new type of spam attack on Twitter?  I’m not saying @nycgrl88 is the one behind this, but it would not be very hard to game the sign up with a script, create hundreds to thousands of accounts, all that recommend @nycgrl88 to #followfriday, and benefit from top exposure on those sites to get more followers.  Are spammers really that desperate?

Again, let’s not put the blame on @nycgrl88 until we know what’s going on here, but something fishy is happening – I’m trying to figure out the purpose behind it all.  Am I missing anything here?

Mac Wins When it Comes to Twitter

PC or Mac? SurveyWith the launch of my new favorite Twitter app, Tweetie for the Mac yesterday, I wanted to see how successful it could be.  Damon Cortesi, who runs TweetStats.com, stated he was seeing Tweetie (the number one iPhone app for Twitter) give TweetDeck, the current number one Twitter client, a run for its money. (Literally, considering Tweetie costs $14.95 and TweetDeck is free)  After doing an informal poll via Twitter, I decided to create a SocialToo SocialSurvey around the question, and sent it to my Twitter followers.

From the poll, which is still running, at the time of this writing out of 138 people, 76 (55%) of people on Twitter use a Mac.  46 (33%) use a PC, a far drop behind.  15 (10%) use Linux, and just one uses another OS besides PC or Mac.  These stats would explain the popularity of a client like Tweetie, which runs just for Mac and iPhone.

We discussed this on FriendFeed.  The comments there ranged anywhere from those that were solely on a PC or a Mac, to those that used to be on a PC, but now were on a Mac.  Others use the iPhone or a Blackberry mostly to access Twitter.  Regardless, those that commented were still overwhelmingly Mac.

So it begs the question, with the new influx of celebrities and mainstream media on Twitter, will it continue to be this way?  Mac owners are often the early adopters, those willing to try new things out.  Will the PC eventually take over Twitter?  It will be interesting to watch, and maybe in a few months I’ll try this SocialSurvey again.  I’ll try a few other questions I think after this – what would you like to learn about Twitter users that we could poll on SocialToo?

In the meantime, please check out Tweetie Desktop for the Mac!  It’s clean, elegant, and very worth the price.  You can read more of Louis Gray’s review of it here.

I Should Have Heeded My Own Advice About Twitter

whale.pngAbout a full year ago, I wrote of developers leaving the Twitter development platform due to Twitter consistently removing features, making changes without warning developers, and effectively putting developers out of business with just a single change of policy.  I advised other developers to be careful building a business model around Twitter, adding that it was a risky move, much more risky than many of the other platforms out there.  It would seem I should have taken my own advice.

It was this time I started SocialToo, a service that originally we built around the auto-follow concept. I named it such because I did not want it to work solely on the Twitter platform.  It was clear Twitter was on an unstable architecture, and their relationship with developers was also quite shaky.  For this reason, I added in features like Facebook profile redirects at the time (a simple “yourusername.socialtoo.com” which redirects to your Facebook profile).  But Twitter, at the time, was the easiest solution to build around, and made the most sense for where we had started so I figured we had to make what we did with it perfect.  Here we are, one year later, and I’m still trying to make it work perfect, but not because our code sucks – it’s because Twitter keeps changing their system, and the rules that go with it!

Today Twitter pulled the rug out from under its developers once more by, with absolutely no notice, announcing that (paraphrased, in my words) since their way was the right way, they were discouraging auto-following, and would only allow a user to follow 1,000 people per day.  What Twitter neglected was that, while not many, myself and others were building business plans around the users that would need this.  A little notice would have been helpful, but is very consistent with the way developers have been treated over the past year or more by Twitter.  Yes, I’m a big boy and we’ll survive, but that’s besides the point.  You can read more about what developers are experiencing over on LouisGray.  Put lightly, I’m not happy.

Twitter Needs a Firm Terms of Service

I know I’m not only one to say this when I say that I don’t have a clue what to expect from Twitter any more.  Any developer out there is prone to this type of treatment, and I can pretty much guarantee it will affect every Twitter developer out there at some point until something is done about it.  The reason for this is that Twitter really has no firm Terms of Service around its platform.  I am not required to agree to any way of using their platform when I write software for them.

Some might see this as a good thing, but what they are neglecting to see is that a Terms of Service gives developers a vision of what to expect, something we don’t have now.  This needs to change, and soon – we as developers need to know what we can and can’t do on the platform.  Can we write apps that auto-follow?  Can we write apps that auto-DM?  What about mass-DM?  Can I store data and what data can I store on my servers and for how long?  What is the definition of spam? There are lots of rules for Twitter users that we agree to, but nothing a developer must agree to when writing apps.  This is why you’re seeing so many apps out there gaming the system, causing these ridiculous rules to have to be made, when it can realistically all be settled before-hand with a simple agreement all developers must agree to before developing apps for Twitter.

If I knew what I could or couldn’t do on Twitter I could avoid it in the first place.  Unfortunately Twitter hasn’t defined that and it’s pretty darn confusing, not to mention extremely risky, to write apps for the Twitter platform right now.  With Facebook, on the other hand, I’m required to agree to a very specific agreement, and they’re very clear when they’re going to change any of the terms, giving developers plenty of warning.  It’s well written out and well defined. It’s a platform with little risk and high reward for businesses because they give developers time to work with any changes they make to it.

We need notice, Twitter!

These “day of” announcements are very immature and something a 15 million user company with millions to billions in the bank shouldn’t be doing.  They were doing this type of stuff a full year ago, and even today they haven’t changed their ways, even though they said they would.  Twitter needs to start notifying developers of these changes or a lot more are going to be put out of business at the drop of a hat.

Every day on the developers mailing list I’m seeing other things like this happening – OAuth technology being removed without notice (I recognize it’s beta, but we still need to know!), no notice to developers on what’s happening when site slowness happens, when things are fixed on the platform, and when they’re broken, and more.  As a developer with 12-15 years of experience in these things, the entire Twitter platform is a joke!  You just don’t do these types of things in the real world of software development!  I worked at places I would have gotten fired for this type of activity!

Developers will continue to leave if this doesn’t change

I have to admit, I’m re-evaluating my strategy to stop working on what I was doing in the Twitter environment, and move more to other platforms at the moment.  When I do that, no, I won’t remove the existing Twitter technology, but I will admit it will be very easy for the users on my service to get the same value they’re currently getting on Twitter on other services, and as they experience similar treatment by Twitter they’ll be leaving as well (as I’m already seeing).  I know I’m not the only developer in this boat right now – there are a lot of frustrated developers out there with almost no signs of change from Twitter.  I know developers that now refuse to develop on the Twitter platform because of the way they were treated, and that will continue to happen.

I have to admit I had to send out e-mails to 20 or 50 or so of Twitter’s very top users today telling them that Twitter wasn’t allowing them to auto-follow.  Those are tough e-mails to write, especially considering the influence Twitter has allowed these individuals to have and the audiences these people are capable of engaging.  I’d like to make Twitter look good for these people, but Twitter isn’t making it very easy.

Twitter, it’s time to get your act together.  Hire some more smart people, get people in management that know how to make these decisions right, and make us believe, not by words alone, but by actual actions, that you’re going to do something about it.  If you don’t, as I’ve said before, when the developers leave, so will your users.

Come follow me over on FriendFeed over at http://beta.friendfeed.com/jessestay or over on Facebook at http://jessestay.socialtoo.com.