Sucking tweets into a local database

A friend asked me yesterday if I could snap together a script to build a local database of tweets using the twitter search API.

This is what I came up with.

The script takes one argument – the term to search on – and creates a sqlite3 database in the current directory containing all the tweets that the twitter search API returns for that term.

It requires datamapper and twitter_search gems to be installed.

Have at it, make it better, bend it to your twitter-slurping needs.

Play IF in Campfire

Ruby is an excellent language for writing small scripts to glue stuff together. Here’s a script I knocked together that lets you play a zcode text adventure (interactive fiction) with your friends in Campfire.

You’ll need a room, account, etc. in Campfire; you’ll need to compile this version of dumb-frotz; and you’ll need a zcode file to play – plenty of those at the Interactive Fiction Database.

I only wrote about this because @lazyatom called me a genius for doing it. Which was nice.

Have fun.

Ruby on Rails popularity

Even seasoned IT professionals occasionally give blank stares when I tell them that we program in ruby, using ruby on rails.

What with a recent endorsement from Martin Fowler and this graph – spotted on Jason Huggins’ blog – it seems that ruby and rails are truly gaining the popularity they deserve.

Mock objects and life expectancy

For my sins, I’m a smoker and caffeine-addict. On a previous project, before I discovered the mock-objects religion, it took so long to run unit tests before a code check-in that I had time to nip downstairs, get a coffee, have a quick cigarette and be back upstairs before the green bar was halfway done. I knew things were bad when I realised I was on 20+ check-ins per day.

I think that the biggest advantage of using mock objects is that your tests run quicker. I find that the quicker I can run all the tests, the braver I become in fixing any broken windows that have crept into the code. But there are other significant advantages too: design decisions can be defered until you have more knowlege about the domain; classes tend to end up less tightly coupled; girls throw themselves at you in the street. Well, perhaps two of those three things are true.

An example from our codebase using the Schmock mock objects library that we developed while writing our code here.

Although we’re programming in Rails, our controller layer and model layer are separated by some service objects – one of which handles our wiki implementation. To test the wiki controller, we mock out the actual wiki using a SchMock:

class WikiControllerTest < Test::Unit::TestCase

In the setup method we create the mock_wiki and inject it into the application controller from which everything that uses it can access it.

  def setup
    @mock_wiki = SchMock.new
    ApplicationController.wiki = @mock_wiki
    @controller = WikiController.new
    @request    = ActionController::TestRequest.new
    @response   = ActionController::TestResponse.new
end

At the end of every test we verify that the mock_wiki has had all its expectations fulfilled.

  def teardown
    @mock_wiki.__verify
  end

Now the real meat of the test. We want to make sure that if we try to edit a non-existing page that we’re redirected to the ‘new’ action. We tell our mock_wiki to expect a call to page_exists? with a parameter ‘nonexistent’ and when it gets it to return false.

I find this simpler than using the built-in fixtures functionality in rails to set up the database to a known state, because the fixture appears right there in the code rather than derived from two-step removed database tables and I don’t have to remember to delete any pre-existing state from the database. It also runs much, much quicker.

  def test_should_redirect_to_new_page_form_if_asked_to_edit_nonexisting_page
     @mock_wiki.__expects(:page_exists?).with('nonexistent').returns(false)
     get :edit, { :page => 'nonexistent'}
     assert_redirected_to :action => 'new', :page => 'nonexistent'
  end
end

I think my life-expectancy has been greatly improved through the use of mock-objects and I thank the good chaps who wrote and promoted the original mock-objects – people like Steve Freeman, Nat Price, Ivan Moore and Joe Walnes – who write much more elegantly than me on the topic.