Technology Archives - Page 35 of 40 - 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.

Facebook’s Deployment Record is Spinning but Seems Broken – Does it Need a Poke?

facebook-pic-1511247Facebook lately has been very good at providing regular and frequent updates to its service.  So much that it has often come under the gun for updating too much to the detriment of its user experience.  I have been last to critique them on this however, as I think it’s a good thing to be listening to your users like they have, releasing early, and releasing often as users give feedback towards the experience.  I think it’s a major reason Facebook is still growing and still surviving despite Social Network users being the type to easily get bored of new technology.  There have been several launches recently which, IMO have been very loud and powerful in the way they were announced and the affect they would have on users.  You probably read about them because they were talked about on almost every major Tech blog when they were announced.  There’s still one major problem though – myself and numerous other users still haven’t received these features.

Let’s start with the launch of  one, as a heavy FriendFeed user and strong advocate of real-time updates, hits near and dear to my heart.  The Facebook stream live updates were announced over 3 weeks ago, claiming to provide you with a live update of new posts in your stream when they appeared.  A simple click on the link should make those messages appear.  While not completely real-time, it’s a step forward, and something I’ve been really looking forward to for over 3 weeks.  You can see my profile, after over an hour of not refreshing on Safari here – note there is no link with new updates:

picture-3-4129198

Here’s how it should look, according to Facebook:

n20531316728_2555919_2644666-1548707

It should also be noted this looks the same if leaving Firefox stagnant, or running on Windows, or any other machine or browser.  This isn’t an OS or browser issue it would appear – it looks as though Facebook’s deployment routines simply haven’t gotten to my user account.  It would appear I’m not alone in this either.  Asking about this on Twitter about a week ago I got numerous responses from other Twitter and Facebook users who also were not yet seeing this in their stream.  A Facebook employee even kindly suggested I was supposed to be receiving this.  I responded saying I wasn’t, but still have not received any feedback in return from Facebook.

It would appear that’s not the only thing that is having trouble rolling out lately though.  Over a week ago, Luke Shepard, a developer at Facebook, announced a very welcome feature launching Facebook into a much more open era.  The feature enables users to link their Facebook accounts to their Gmail accounts and other OpenID providers, making Facebook an official OpenID provider.  Also, according to Shepard, users would be able to register for Facebook by simply entering their Gmail credentials.  “Now, users can register for Facebook using their Gmail accounts. This is a quicker, more streamlined way for new users to register for the site, find their friends, and start exploring,” he said.

The problem is that I still don’t see a way to do this on Facebook.  I can link my Facebook account with various OpenID providers and even Gmail, but that’s only if I have an existing account.  However, there is no option when I log into Facebook, or when I try to register with Facebook to login or register with my Gmail credentials or other OpenID credentials as he says.  Am I just the last person on their deployment list? I know I’m not the only one because this was pointed out by someone else with the same question.  If I can link my OpenID profile with my Facebook profile, but can’t login or register with it, what good is this announcement?

picture-21-300x134-9813043

Note there is no option to log in with Gmail or OpenID

Facebook registration

Note there is no option to register with Gmail or OpenID

It would appear something seems broken in the Facebook deployment process.  Either it’s just really slow, or not all users are getting the updates they’re supposed to be getting.  Or are we getting these announcements just to get the marketing spin machine going?  It would appear that this blogger is not on that list if it is the case!  Regardless, I’d really love to have the updates we were promised!

If you’re seeing the same issues, let it be known in the comments.  You can follow me on Facebook at http://jessestay.socialtoo.com.

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…

Universal Media Group Just Doesn’t Get It

This is a guest-post by my brother, Luke Stay.  Follow him on Twitter / FriendFeed.

umgredneck

I do a semi-regular segment on LukeStay.com called Favorite Video Friday in which I showcase 3 innovative or otherwise interesting music videos bound by a common theme. They’re my favorite posts to do and also my most well received. I’ve done 43 of them so far, all but a few of them containing 3 videos each, but every time I think I’ve run out of good videos, I stumble on a few more.

YouTube is my source of choice, mostly because of its popularity and massive database of artists both popular and obscure, but in my never-ending search for quality music videos I often come upon one with “embedding disabled by request.” Nine times out of ten, that video is claimed by Universal Media Group. This always puts me in a difficult position. Do I scrap the video that fits so perfectly with the weeks theme, or do I go elsewhere and find the video on a site not as regulated as YouTube?

Universal Media Group has completely missed the point of YouTube. YouTube is a social network. It is a place to discover interesting videos and discuss them. I’ve found that my meager number of regular readers are a lazy bunch. They don’t click on links to watch videos elsewhere. They want to watch the video then and there, embedded right within the site. If they like it, then they’ll seek out ways to share it with others, usually through YouTube. On the internet, you only have seconds to grab a reader’s attention, and external links do nothing to help you. I have to embed my videos.

I don’t know why they do it. They can’t claim they lose ad revenue when their videos are embedded externally. YouTube now allows embedded ads and most of Universal’s artists already have pop-ups to buy the track on Amazon or ITunes. Embedding does nothing to stop this. I’m not going to claim this practice hurts their business, Universal’s artists are mostly well known, but it certainly doesn’t help them. I don’t know how many times I’ve gotten comments on a post I’ve done telling me that a person had never heard of a band or a song and they were going to go buy the track. After the recent suggestion of Marina Martin, I even added links to buy the featured tracks on ITunes (If anyone knows an easy way to add graphical buttons, I’m listening). Allowing videos to be embedded only increases the scope of your visibility. How can that possibly hurt your business? I don’t get it.

I wish I could boycott Universal Music Group altogether, but they just represent too many artists. If I want to keep up 3 videos a post, I need as many videos to choose from as I can get. Instead, I’ll just be forced to keep finding their videos elsewhere, often bringing them no ad revenue whatsoever. It’s a mild pain in my butt, but (I just said butt but, hehe) I’m sure Universal spends massive amounts of money searching for copyright infringements that could be avoided by simply enabling embedding on YouTube. Get with the program, Universal!

Follow more of Luke on http://afrowhitey.com and http://lukestay.com.

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.

The Kindle Technology Will Be Disposable in The Future

Esquire E-Ink TechnologyToday the buzz of the tech blogosphere has been the coming launch of a new, bigger and thinner Kindle which will target newspapers in a way some are claiming will save the dying industry. MG Siegler is calling it a hail-mary, last-ditch pass that will most likely fail. Dave Winer and Robert Scoble think otherwise, stating the potential for networked devices, and the convenience of such devices to relieve the need to carry multiple books or papers while traveling, or visiting the beach.

I suggest this game is far from over for the Newspaper industry. When I worked at Media General, a large, Publicly-traded media organization that owns Newspapers and TV stations throughout the southeast, we were talking about technologies such as the Kindle even 5 years ago. This stuff isn’t new to them. They know this is the future.

Here’s why I think we’re far from the Newspaper industry going out of business: Paper. The Newspaper industry knows paper – they thrive on it, and their business is dependent on disposable forms of media. They have hundreds of years experience in paper. Media General itself has newspapers that root in the Civil War era. This is the paper you can have delivered to you, which you can throw away when you’re done. There’s something about the tangible feeling of paper that people enjoy. The problem is it’s wasteful and with the amount of paper used, it’s rather expensive. It’s also at times not very convenient.

Enter the Kindle. The Kindle brings the power of Ink technology to digital form, in a single box you can take around with you, download new content, and refresh that content daily as new content arrives. The problem with the Kindle though is it is Amazon’s brand. It’s their power to determine the formats papers need to be in, and what they look like. It’s their power to determine revenue models. Newspapers still have their own brand to maintain. Relying on one technology for that won’t work.

In addition, the Kindle still doesn’t quite hit that disposable paper niche that Newspapers are so good at. The power of the Newspaper industry is that they are local – they currently own the media distribution of entire cities and towns, and know those towns in a way no other media entity can know. For this reason, having a local paper-boy deliver a disposable paper to your door adds to that personal touch – nothing digital can replace that in-person relationship people have with their local Newspaper. Add to that the local relationships with local businesses and the ability to generate very personalized ads thanks to those relationships. It’s hard to beat that with a much larger, digital entity.

In essence, in a timeline of events, we have gone in our world’s history from tablet forms of writing – gold, brass, slate, and more, to paper form, to ink forms of writing on top of paper and mass distribution because of that via the printing press and computers. Now with the Kindle, we’re going back from Paper form, back to the tablet. It’s a non-disposable, re-usable form of writing.

I predict this cycle will repeat itself. We actually already have the technology in front of us. Last year we saw Esquire magazine release a magazine with a cover written in digital ink, along with a digital ad for Ford on the back. They’ve proven it’s possible, and they were able to fully maintain their brand by doing so.

What will happen is memory technology will get smaller and smaller for the amount of memory you can store content like Newspapers. Batteries are already getting smaller. The technology you see on the Kindle today will be able to be produced in tangible Paper form in 2 years I predict. At that time, you’ll see the News stands full of single sheets of paper, the dimensions of the new Kindle, but in disposable, paper form, with the Newspaper corporation’s brand and advertising all over it. You’ll be able to purchase it for not much more than the price of a single newspaper today (in theory, it ought to be cheaper to produce). It will integrate with Facebook. It will integrate with other viral technologies. It will even potentially have GPS, not just for networking and viral promotion, but for ad analytics and tracking, making the Newspapers valuable again.

While the newspapers are dying now, I predict they’ll be back. This technology is just around the corner in affordable measures from us. Will the Kindle survive? I think so, but I don’t think it will fully compete with the Newspapers. I think it’s Apples and Oranges – the Kindle is presenting an entirely new distribution mechanism that will manifest itself on many other devices as well. Paper itself is not going away. It is going digital.

Photo courtesy mstearne.