Back On The Wagon

I haven’t written a blog post in almost three months! This must be rectified.

I’ve been doing a lot of reading lately (current materials: HPMoR, for the third time, and Conceptual Mathematics for the first), and a lot of dashing back and forth between job interviews, and truly spectacular amount of email-writing, but I’ve been doing far too little real programming, so I decided to dip my toes back in the water this evening with something small but useful.

One thing that I think is really cool: PredictionBook is a website that provides a place to record predictions about the future (or about anything unknown to the user) with specific likelihoods, and then track how accurate those predictions actually turn out to be. The results can be surprising! For example, I’m (apparently) more likely to be correct when I only feel 70% confident about a prediction than when I feel 90% confident, which may indicate a lack of self-awareness on my part - though I’m going to hold off judgment until I get a few more samples.

Anyway, PredictionBook is a great and useful website, but I find myself wishing I didn’t have to open a browser to get to it. I spend a lot of my time living in the terminal these days - it’s substantially less distracting - and if I could just type “predict rain 50% tomorrow” or something similar, it might save me a fair bit of time spent instinctively opening Facebook.

So why not? I wrote a super quick-and-dirty command-line tool to post predictions, which is now available for your self-quantifying pleasure. The process consisted, more or less, of inspecting the prediction submission form on the website to get all the field names, bemusedly trying to find my way through the Ruby codebase for the website (fact: I know roughly zilch about Ruby), and finally giving up and deciding to do it in Haskell after all. I’m glad I did! I hadn’t done any HTTP scripting in Haskell before, so this project ended up teaching me more than I’d expected. This is admittedly still a work in progress, for several reasons:

  1. Sometimes the UUID generator hangs for several times its normal running length, for no reason that I have been able to figure out yet. This is my first time working with random-extras and random-fu (I’ve previously only used System.Random for random number generation in Haskell) and I wonder if there is some subtlety I’m missing in the way /dev/random is being used… But at this point I can no longer get the bug to occur at all. I’m pretty sure that code elves did not come and fix my mistakes while I went to get coffee, so I have to have changed something relevant, but I have absolutely no idea what. Further tinkering to follow.
  2. The way that I’m dealing with authentication here is clearly non-ideal. Few people actually want to retype their username and password every single time. A better approach might be to encrypt it with gpg, then call gpg-agent whenever login info is needed; the choice of whether to leave the system keyring unlocked or retype passwords every time is a fairly personal one, but at least it’d be consistent across a single user’s system.
  3. That’s so many dependencies! How on earth did I write a 72-line program which includes ten lines of import statements? And I’m using fromJust to generate parse URIs from a string rather than constructing them properly. That’s a bit icky.
  4. As the inline comments mention, there are some constraints that should be checked on this side, rather than submitting them to the website and getting maybe-unexpected behavior.
  5. This would definitely not run at all on a Windows machine. Or anything without a /dev/random. I personally wouldn’t give up Linux for love, blood, or money at this point, but it’d still be better to be platform-independent…