Archive for the ‘Java’ Category

Toys. With each generation, the number of toys per infantile capita is surely increasing. My nephews have so many toys they can barely keep track of them all. I was a relative toy pauper by comparison, but next to my dad, I was as rich as Croesus. In Dad’s childhood, money was scarce and toys were a luxury beyond his reach. But little boys want toys, so human innovation filled the gap – they made their own.

King of the home-made toys was the cotton reel tank, a wind-up automotive device made from a candle, a cotton reel, an elastic band, and two used matchsticks. Once the craft had been passed down from father to son, I too found joy in building and performance tweaking these little beauties. I’d discovered the pleasure of making something, however primitive, with my own hands.

cotton reel tank

In the spirit of the cotton reel tank, I sometimes have a hankering to knock up a little digital toy as a fun micro project. Something of little or no practical use. How about a Magic 8-Ball Twitter bot? A search revealed a handful of such bots already existed, but not one was still functional. Some tweeted their last in August 2010, no doubt victims of the Twitter OAuth Apocalypse. Another unfortunate example replied repeatedly every two minutes to any question, the only way to stop it being to delete the original tweet. A disappointing 8-Ball fail.

Having taken into account all of this prior art, I defined the requirements of my bot thus – it should:

The open source Twitter4J Java library supports OAuth, so no problems there. To ensure the bot only replies once meant persisting the ID of the most recent tweet replied to, for which I used Prevayler. I pass this persisted tweet ID as a parameter when querying the Twitter API (via Twitter4J) for new mentions, so the bot only “sees” each question once.

The maximum wait for a reply is determined by cron config. I scheduled the bot app to run every two minutes, which seems like a reasonable worst-case time to wait for the omniscient wisdom of the 8-Ball gods, plus I’m mindful of Twitter API rate limiting. Responses are read in at runtime from a simple text file populated with the standard 20 8-Ball responses, one of which is selected at random when creating a reply.


And that’s about it – a crude toy that was probably more fun to make than it is to play with, although I still get a kick out of asking it stuff once in a while. Take my cotton reel tank for a spin yourself by tweeting a yes/no question to @Wise8Ball; you may be surprised by how profound it can appear.

Read Full Post »

I’m currently reading the excellent Growing Object-Oriented Software, Guided by Tests. Although I have read less than half of it so far, this book has already changed the way I think about Test-Driven Development. It covers a broad range of TDD topics and their intersection with OO, but for now I want to focus on a very small part of this landscape – the naming of unit tests.

Names are important. Class names, method names, variable names – good names inform us, bad names mislead. I’m sure we all know that naming stuff can be tricky. However, a little discipline in choosing names can go a long way to improving the quality of unit tests.

Consider a tiny class I wrote recently while performing the leap year kata:

public class Year {

    public Year(int year) {
        // constructor type stuff

    public boolean isLeapYear() {
        // code to check for leap year

I could have made isLeapYear() static, and in fact I have done so in previous attempts. But it isn’t the design choices of the interface to Year that I want to discuss.


Read Full Post »