FAILCOUNT: Count the fail.

It’s been three week since I wrote an application in a day, and I’ve been chipping away at it since to get it to a properly usable state for many people.

I think I’ve spent around one full day’s worth of work on this, spread out into little chunks while doing other things. I carried my NC10 around with me at Redemption and pulled it out in the odd moments between panels to hack away at outstanding bugs, and I’ve poked away at it while sat on my sofa watching TV. It’s not exactly been what you’d call a dedicated and focussed effort.

But that’s okay, since it’s not exactly what you’d call an important or serious application. It’s just a way of tracking the amount of fail an organisation or group are exposed to throughout the day. It now supports multiple accounts so people other than the guys in my office can use it. It has an API so you don’t need to use a web browser to record fail or check the fail status. I’ve improved the calculation methods used for deciding the per-day thresholds for ‘amber’ and ‘red’ status alerts, and added an ‘unknown’ status for when there’s not been enough data to calculate on. (This is, I think, an improvement over my previous decision to just pick arbitrary hard-coded numbers.)

The test coverage is up near 90%, which I’m quite happy about. I think 100% coverage is possible with this small app, and I might even try for it later.

It’s not perfect – there’s some places that will obviously benefit from optimisation, and the tests need to be seriously refactored to have less dependence on fixtures. The styling is really primitive and probably needs to be entirely replaced at some point. There’s no account control options, too, which is going to be a problem.

It’s definitely a beta release, but it’s a release.

So, if you want to track the FAIL in your group, I recommend going to FAILCOUNT and making an account. All feedback is happily received.