Your way to abstract poetry stardom!

Ebooker is a service that will consume a Twitter stream and generate new text using Markov chains based on the text. This is nothing new: most people speculate @horse_ebooks came about this way (but I'm a believer it's just Markov-assisted and not truly botty). Excellent examples of Markov-based Twitter accounts are @kpich_ebooks, @RandomTEDTalks, and @markov_bible.

If you're new to Markov chains in text generation, I wrote a post on it trying to explain it in non-technical terms. Conversations with my non-technical friends who tried to read it give mixed reviews to how much they actually understood it.

Implemented in Go, because the gopher is cute and I was curious.

• sqlite3

That's pretty much it. We use it to store tweets and OAuth tokens.

Running make (and assuming the project root is in your $GOPATH) will generate two binaries: ebooker_server and ebooker_client. Both, when run with --help, will list their flags.

The server is what does all the work: it retrieves tweets from Twitter, generates Markov chain tweets, and posts them up on a schedule (by default, every 11 hours). The schedule was meant to be more configurable, but I decided to work on other things before I implemented it.

The client is your way of telling the server what to do: you call it with the appropriate flags to add, list, or delete bots. You can also just call it with sources to generate Markov tweet text, printed to stdout, and skip the bot business altogether.

Probably not! There are a few major faux pas that I note, now that it's been a few months. Just like ScrabbleCheat has elements of "Baby's First Erlang," this smacks of Baby's First Go. Notably:

• I got scoping all messed up. Many things are exported because I figured they had to cross file boundaries, when that really makes them public and exports them from the package.

• I got packaging all wrong too. If you go back in the repo enough revisions, you'll see that for a while, this was all one big package. When I started separating them out, I found many a boo-boo. This exacerbated the visibility issue above.

• Some structures that get thrown around a lot (OAuth1, LogMaster, etc.) just reek of needing some proper DI tool.

• I only tested what needed testing. Fail code coverage, test-first, etc. I'm obviously crying every night over this.

• SrPablo_ebooks Modeled after my Twitter account.
• laurelita_ebook Modeled after my girlfriend's.
• SrLaurelita Modeled after both of ours.
• love_that_lita Modeled after @laurelita and @love_that_goku

I hand-rolled my own OAuth1 for this. Like all my side projects, this was simply because it was more fun to do it that way. The relevant code is in the ebooker/oauth1 package. Both the client and the server use it: the server obviously for posting tweets, and the client for generating access tokens if you try to make a bot that needs to post to an account you don't have tokens for currently. If you retrieve tokens another way (say, with an HTML frontend and a proper "Sign in with Twitter" redirect) you can input them to the server directly.