Twitter4R 0.3.1 and the future

Written on 12:16:00 PM by S. Potter

Hi Twitter4R users, I know I have been rather absent in terms of my Twitter4R contributions and ongoing development, but despite my absence I have _finally_ officially released 0.3.1 with a lot more new features and a few bug fixes more than I initially expected to release 0.3.1 with. Some of the goodies included in the official 0.3.1 release are:

  • Added raw Twitter Search API support. Meaning you can use any of the HTTP parameters the Twitter HTTP-based Search API will expect. E.g. => "twitter4r", :rpp => 10) or => "twitter4r", :rpp => 15, :geocode => "40.112186,-88.207592,250km")
  • Profile, theme API coverage on Twitter REST API.
  • Social Graphing API. E.g. twitter.graph(:friends, user)
  • Added "reply" support at all levels (low-level to model-level)
  • Bugfix: the infamous URI.encode to CGI.escape change.
  • Rate limit information (still needs to be able to support the HTTP header method, which I actually suggested to Twitter developers some time back, but they only recently added it when my bandwidth for OSS contribution was minimal) :(
  • much more
Now the future of the Twitter4R project. I have made a LOT of mistakes with this Twitter4R OSS project venture, so I am going to try to fix a bunch of these things:
  • Create a new set of Git repos on GitHub that separates the education portions (screencast, etc.) from the core source code of the project so that people do not need to download ridiculous amounts of data to their local drive just to fork Twitter4R on GitHub as it required at present. Announcements about this will be coming soon!
  • Have a consistent issue tracking system for Twitter4R. Previously it has appeared inconsistent to users of the Twitter4R library where to submit defect reports or new feature requests to. So I have had to field these requests from the Google Groups mailing list to personal emails and also @twitter4r replies on Twitter. I plan on using GitHub's new issue tracking system for this as it seems a logical extension.
  • I plan on documenting things a little more obviously on the official website from now one. It appears many users did not want to go to the RDoc unless specifically pointed to it, even though a large majority of the library is fairly well documented in the RDocs.
Please be patient while I fix these process/marketing/workflow issues of the project and in the mean time I will also be tackling OAuth support as well. Again thanks for your patience thus far and tweet me on twitter at either @SusanPotter or @twitter4r if you have suggestions or questions about the direction. If you have specific queries on using the actual API, please join the twitter4r-users Google Groups mailing list and search the archives for a solution first and then if you can't find a solution, please post a message giving the group members your environment details and the version of Twitter4R you are using. Thanks! Susan Twitter4R Developer

If you enjoyed this post Subscribe to our feed


  1. Darius |

    Thanks susan! That does sound pretty good.

    I'm curious to know who / how people are using your gem these days? mostly for integration? That might be a nice paragraph for your "state of the plugin" address.

    On a related note, I'm wondering what the right approach for building a twitterbot would be. Are there any frameworks you can recommend with your superior knowledge of the domain? :)

  2. S. Potter |

    @Darius: Great question.

    It will really depend on what you want your twitterbot to do. If it will only be updating one or more account statuses (i.e. one use case of the Twitter API) and you want to strip out third-party dependencies, you might be better off writing your own Ruby bindings to the API with Net::HTTP. If you need a wider amount of API coverage, then you should choose a library that fits your needs and coding-style preference.

    As far as I know Twitter4R does have much more API coverage of the Twitter REST API than the twitter gem, but the twitter gem recently started supporting OAuth, which I am still working on.

    There is another Ruby gem that has twitter API bindings, but I do not remember the name of it and think it's primary selling point was that it was smaller and lighter weight and only supported the basics. So you should check that out to determine if it fits your needs.

    I am not 100% sure any more, but last time I dabbled with the twitter gem you couldn't easily change the "source" for HTTP Auth usage and Twitter4R has supported that (and HTTP proxy support) for a very long time already. In fact, it was one of the three reasons why I created Twitter4R (easy application customizability) instead of just using the primarily command-line tool (as it was then) twitter gem.

    The twitter gem has change significantly since then, but still doesn't appear to support some parts of the REST API and sugar coats the search API like you would expect a Java library to do. It is a matter of personal style whether you like that type of thing or not. I personally get the chills whenever I am reminded of my Java development days!:)

    Hope that summary helps,

  3. Darius |

    Thanks susan!

    For other people, I thought I would post some links: (based on twitter gem) (based on wonderful twitter4r gem)

    I myself have had trouble getting daemons working with both of these. Meh.

  4. nayeem |

    how is the oauth support coming along susan?

  5. Bora |

    Hi Susan. Thanks for the updates to twitter4r. Much appreciated. I was trying to use the search method, maybe I'm doing something wrong but it is not returning the user object or the username appended to the tweet when show_user is set to true as the twitter search api documentation states.

    Here is my code: => "search term here" , :rpp => 10, :show_user => true)

    Any thoughts?


  6. David Liwoch |

    looking forward to Oauth


Post a Comment