Campfire tray notifier application

At work, we use Campfire for intra-office communication. It’s been a real boon for keeping everyone up to speed one what’s happening, especially since many of us are separated geographically. It’s also great because we can properly manage our attention–if I’m in the zone, I’ll choose to ignore campfire, and at a later time I can catch up on the logs.

When we were first starting off incorporating Campfire into our process, though, the challenge was the social problem of getting everyone to learn a new habit of checking in on the chat and be there. The value of business chat is in the participation. Some of us needed Campfire to behave a little more like a desktop app that could provide invasive notifications to remind us to visit the web page.

For Mac, there is Pyro, which you can hook into Growl. But, since we were all on PC’s, that wasn’t viable. So, I turned to AutoIt and wrote a script that watches for changes in the web page title and pops up a balloon notification when there’s a new message. Recently, I got an email from someone requesting this, so I’m posting it here.

Here is the AutoIt script:

Opt("WinTitleMatchMode", 2)
Opt("WinWaitDelay", 500)
$isBalloon = 0
$last_title = ""
Do
    $title = WinGetTitle("Campfire: ")
    If WinGetTitle("") == $title Then
        $last_title = $title
        ContinueLoop
    EndIf
    If StringInStr($title, "(") AND $title <> $last_title Then
        $last_title = $title
        $parts = StringSplit($title, " ", 1)
        If ($isBalloon = 0) Then
            $isBalloon = 1
            TrayTip("New Campfire message!", "There are unread messages in the " & $parts[3] & " chatroom.", 10)
        EndIf
    Else
        $isBalloon = 0
    EndIf
Until 0

After downloading and installing AutoIt, you’ll be able to run this script (paste this into a text file and give it a “au3″ extension). You can also turn it into an exe using Aut2Exe and drop a shortcut into your Windows Startup folder so it will be there on bootup.

This script only works for IE (6 & 7, I think) because of how the web page title is formatted. That was sufficient for our needs, but I don’t think it would be hard to modify. I haven’t had a chance to test this, but here’s the code.

Collaborating with Mercurial

Now that you’ve got Mercurial running on your local machine, what if you want to collaborate with someone else? The easiest way to do this is to run “hg serve”, which starts a local http server that allows others to browse your repository, view changelogs, clone your repository and pull your changes. This is deemed an “informal” method of sharing because it provides unauthenticated read-only access to your repository. You wouldn’t use this to share your code with the public, but it works great within company walls if you’re trying to work with a coworker on something.

Again, it’s very simple and you’ll have it running in less than a second. Inside your repository, do:

hg serve

By default, you won’t see any output. You can verify things are working by navigating to http://localhost:8000/.

Now that you’re sharing your repository, Charlie can point his browser to http://[your machine name]:8000/ and browse your changelogs, files, tags. If he wants to start making changes, then he would:

hg clone http://[your machine name]:8000/ destination_directory

This will print out some status messages about what it’s doing. Now Charlie has a repository one his machine that he can start working with. If I make subsequent changes, Charlie can pull them into his repository by doing:

hg pull http://[your machine name]:8000/

And vice versa, if Charlie commited some changes, he would run “hg serve” and I would pull from his computer.

This is merely an introduction to doing some lightweight collaboration. In this scheme, since the “hg serve” provides read-only access, we are using a “pull only” model. This may not be practical depending on your project, but again, this is a quick and easy way of sharing and collaborating on code.

Sparklines

My friend Erik sent me some biostatistical data that he has been tracking over past few weeks. I decided to see what it would look like as a sparkline. There are a bunch of libraries and web services to generate these things, and I tried to find the simplest one implemented in Python. I found Matthew Perry’s module, installed PIL, and I was good to go. (I made a slight change to spark.py to expose the background color of the image as a parameter so the graphic would match my current theme.)

More data to visualize: I’ve been recording my gas mileage information since November, 2006. We can also note that gas prices have been steadily climbing since then (low: $2.10, high: $4.26). The simplicity and attractiveness of these graphics make them particularly compelling. I can think of a few places where using sparklines would be useful…

Enso lives on

Days after I lamented about Enso’s death, Atul posted a progress report, providing an overview of what’s been going on since open-sourcing Enso. I did suspect (and hope) that Enso was was, in fact, not dead – I poked around the code repostitory and browsed the developer’s forums and saw some healthy activity. I was glad to finally hear some direction for where the project is going. Enso is very much alive:)

While looking through the discussions, I came across a nifty Enso interface demo by Andreas Schuderer implemented in JavaScript. It’s a great example of “Show, Don’t Tell”.