Building With the Twitter API: Repeating Tweets From a Group

Final product image
What You'll Be Creating

This tutorial is part of a series related to the Twitter API. You can find the original Birdcage Twitter tutorial here or follow my author page to keep up with the latest additions to the series. This particular tutorial builds on Birdcage and the data models and code from the preceding tweet storm tutorial.

If you're a maker like me, you often use Twitter to share details about your creations. There's often more to say than you can fit in 140 characters, and most of your followers don't even see every individual tweet. Even if they see something you've posted about, they might favorite it and forget it. It's helpful to have a service that regularly shares different aspects of your announcement. The nature of the Twitter stream makes repetition useful, within reason; overdoing it is spammy and annoying.

This tutorial builds on my earlier tweet storm article to show you how to build a service that posts a randomly selected status update about your work on a recurring basis. This automates the task of repeating and creating variation over time to increase the likelihood that your Twitter followers will engage with your content.

Keep in mind that the Twitter API has limits on repetitive content. You'll be more successful if you offer a wide variety of variations and run the service on an account that you also use manually to share other content. Twitter will likely reject the repetitive tweets of pure marketing bots—and you'll likely run into this while testing.

Feature Requirements

The basic requirements for our feature are as follows:

  • Let the user write and store a "bunch" of tweets within a group.
  • On a recurring basis, randomly select one tweet from the group to post to our account.
  • Repeatedly post these items at user-configurable intervals with a random time shift.
  • Allow the user to set a maximum number of recurrences, e.g. 100.
  • Allow the user to reset groups to restart the repeating.

Building on the infrastructure for Groups that we built in the tweet storm tutorial requires only a modest amount of additional new code for recurring tweets.

The Database Model

We'll use migration to create the Group table, which is just slightly different from the one used in the tweet storm tutorial:

The code below builds the schema. Note the foreign key relation to link the group to a specific Twitter account:

The new fields include next_publish_time, interval, interval_random, max_repeats, and status.

We'll also use the same relational table called GroupStatus which tracks the Status tweets within each Group:

Building the Code

Use the tweet storm tutorial to see how to use Yii's Gii to create the scaffolding code for the Group Controller as well as the models for GroupStatus.

Here's what the "Create a Group" form looks like:

Create a new group for recurring tweets

Here's the view code for the form. Notice there is JQuery that shows and hides the additional settings when the user selects a recurring type of group (as opposed to a tweet storm group):

Here's what the Group controller index page looks like once you've added some groups:

Manage groups page

Here's the code that runs the index view. First, the Group controller index action:

Then the admin view code, which uses the Yii Gridview controller:

You can reach the Group view page by clicking on the leftmost "list" icon for any individual group. From there, you can add individual tweets:

Composing a future tweet for group recurring

The compose code is nearly identical to that in the Birdcage repository. Once you've added a handful of status tweets to your group, it will look something like this:

A Group of tweets for recurring

The more volume and variety of tweets you can provide, the more likely you'll be able to successfully repost automated tweets without running into Twitter's built-in limitations on bots.

Recurring groups don't actually begin tweeting until you activate them—notice the right-side menu options in the above image. Recurring groups run until the number of stages reaches the maximum number of posted tweets. The user can also reset a group to start the process over.

Here's the code for the activation and reset operations:

Publishing the Recurring Tweets

The DaemonController index method is called by cron in the background. This calls the Group model's processRecurring method. This runs through each account looking for groups that are overdue.

Then, we call publishRecurring. We use named scopes to look for recurring groups whose next_publish_time is overdue. We process by account to minimize the number of OAuth Twitter connections needed. The scopes are shown further below.

Here are the ActiveRecord scopes we use to find the overdue groups:

When we find a Group that needs to be updated, we use this code to randomly select a status tweet and update the next_publish_time:

We calculate recurrence by combining the delay interval and a random time shift which helps tweets appear in different time zones and slightly different periods for reaching different users:

The posted results over time will look something like this:

The results of recurring group tweets

Future Enhancements

You may wish to even out the distribution of tweets by logging the frequency each is used and choosing from the least-repeated items with each iteration.

You might also wish to allow groups to have a suffix of hashtags that can be randomly selected to vary content when you tweet.

In Closing

I hope you've found this interesting and useful. Again, you can find the original Birdcage Twitter tutorial here or follow my author page to keep up with the latest additions to the Twitter API series. 

Please feel free to post your own corrections, questions and comments below. I'm especially interested in your enhancements. I do try to stay engaged with the discussion thread. You can also reach me on Twitter @reifman or email me directly.

Tags:

Comments

Related Articles