No URL-Shortening

Where I do URL-shortening (currently through TinyURL due to some down-time with Metamark, though I think they’re back up now), @cpanlive doesn’t. I believe that if the status message were to exceed 140 characters, Twitter would notice this and scan the message for URLs to shorten automatically. In the end, I suppose it’s a matter of taste– with @cpanlive you’ll see the actual URL the majority of the time.

Content

I usually provide two links, the second being to the “Changes” (Changes, ChangeLog, etc.) file, or the README if I can’t find a change-log. @cpanlive provides just the main link. I also include the author’s name. This goes back to the use of URL-shortening– I’m careful to keep my status under 140 characters, but having pre-shortened the links gives me more room to play with.

Hash-Tagging

I don’t use any hash-tags, currently. @cpanlive uses both “#Perl” and “#CPAN”. On the one hand, I probably wouldn’t have even known about this if it weren’t for the tagging, as I wouldn’t have seen it otherwise. On the other hand, this puts a lot of data from a single bot into the #perl search-stream. Most people know to follow a given bot if they want CPAN stream updates, and would prefer to not have them cluttering up #perl.

That said, I am considering adding #CPAN to the updates that @cpan_linked puts out, as well as the re-write that I’m (slowly) working on. I think that such data is more useful to users searching on #CPAN than those searching on #Perl.

Speed and Pacing

When @cpan_linked gets a cluster of several CPAN updates at once, it tries to spread them out over the next period between polls of search.cpan.org‘s RDF feed. Currently, I poll it every 15 minutes, so if I get 5 new items to post they get posted roughly 3 minutes apart. It looks like @cpanlive doesn’t do anything like this, as the updates seem be in “clumps”, which is what I was trying to avoid. Again, a matter of taste. I didn’t want the bot to suddenly spew 10-20 updates into my Twitter stream, pushing everything else “below the fold” as it were. Other followers might not care one way or the other.

Something I’ve noticed, though, is that @cpanlive seems to be about an hour or so behind @cpan_linked, on average. I assume that they’re polling the RDF source hourly, rather than the 15-minute interval I use.

Conclusion

Well, there’s no “conclusion” here, really. I mean, it’s not like I have an exclusive license to relay CPAN releases to Twitter. If such an exclusive right existed, it wouldn’t be mine in the first place! I do wonder about the reason for doing it over again, though it may just be someone’s project for learning how to use the Net::Twitter modules. It does push me to get cracking on my re-write, though, as I have other features planned that should make it even more useful.

I generally try to use these posts to highlight lesser-known modules, and I imagine that the Net::Twitter module is fairly higher-profile than most of my previous choices. But are you familiar with Net::Twitter::Lite, as well?

It’s not unusual for CPAN to offer more than one solution to a given problem. The wide range of XML parsers is a testament to this. And when a subject is popular, the odds are even greater that people may choose to “roll their own” rather than trying to contribute to an existing effort. Fortunately, the interface to the social messaging service Twitter has been spared this. Maybe it’s because the source code is hosted on GitHub, and thus it is easier for people to contribute. Whatever the reason, the only real competition to Net::Twitter for basic Twitter API usage is Net::Twitter::Lite. And it’s not actually a competitor in the general sense.

Rather than representing a competing implementation, Net::Twitter::Lite came about as an (almost completely) interface-compatible alternative to Net::Twitter after it was refactored to use Moose internally. While it doesn’t have 100% of the features that Net::Twitter has, both modules strive for 100% coverage of Twitter’s API. Where N::T::Lite runs without the additional requirement of Moose, N::T gives you finer-grained control over which parts of the API are loaded and made available to connection objects.

I’ve used both modules, and can attest to the fact that the interface is kept consistent between them. At $DAY_JOB I authored a tool to echo data to a Twitter stream, for which N::T::L was the best choice as it had the fewest dependencies and our needs did not call for the additional functionality of N::T. My Twitter-bot (cpan_linked) was written with N::T in the pre-Moose days, and has not had a single problem since I seamlessly upgraded N::T to the Moose-based version. As I work on the next generation CPAN-bot, I’ll be using the OAuth support, as well as possibly the search API. Since it will be a long-running daemon, I’ll stick with the more-featureful N::T for it. But thanks to the diligence of the modules’ authors, I could just as easily swap between them at will.

If you’re planning to interface to Twitter from Perl, these two modules should be your starting point. But be sure to look at the other Twitter-oriented modules, just to be sure. There’s a lot of activity around this API, and Perl developers have kept on top of it.