I’ve been using Lighthouse since it’s inception, but now that I’m working with the ENTP folks I get to thinking about what to do with Lighthouse a lot more. I’ve had a few ideas on ways to play with the API and I finally got around to implementing one of those ideas with Burndown.

Burndown is a simple little app that adds a new dimension to Lighthouse – Time. It shows you a burndown chart for each milestone in your project, recording the number of open tickets each day so you can see the progress of your milestone. If you’re running in short iterations, it’s a good way to measure your team’s velocity all agile and whatnot. You can see an example for Tender’s current milestone. As a bonus, you can keep tabs on our development on Lighthouse and Tender for the sample install :)

Screenshot

Miniapps are fun

Burndown is what I’d call a miniapp — it can’t survive on it’s own, doesn’t have fancy permissioning, security or even the best code. It just gets the job done. For me, it was a way to play with a lot of new technologies I haven’t played with before. It’s currently running on Heroku, powered by Sinatra & Datamapper, with the front-end powered by jQuery & Raphael. I haven’t touched a single one of these, but the app still only took about a week to build.

If you want to try it out, I’d suggest opening up an account over at Heroku. From there, it should take a few minutes to get your own Burndown instance running.

Some thoughts on the tech

Since this was an all new experience I thought I might share some of my thoughts on the tech I used to build Burndown.

Heroku… rocks

I’d heard great things about Heroku, but never really had a need to play around with it. My first reaction: holy crap this is awesome. Getting the app up and deployed was easier than setting up Wordpress on Dreamhost. That says a lot. That being said, there were definitely some rough patches debugging the app, and I’m really not sure what was causing them. I’m guessing it’s whatever database they’re using, but can’t be certain. Weird ordering with my records.

Datamapper… I’ll take AR, thanks

Datamapper was definitely a struggle. I’m not down with the way conditions work at all. I understand what they’re trying to do here, but :age.gte => 15 is freakin weird lookin Ruby no matter how you slice it. I also ran into quite a few random bugs where my association finders weren’t getting scoped (want an example of a really hard bug to track down?). All in all, I’ll take my ActiveRecord over it any day.

Sinatra… rocks, reloading does not

Sinatra is an awesome little framework. I’ve played around with it in the past to the extent of hacking other people’s code, but never deployed something for myself. It’s a pretty rockin framework, and with PassengerPrefPane it exists seamlessly in my dev environment. Unfortunately the lack of code reloading is really a pain. Can’t tell you how many times I typed in touch tmp/restart.txt

Raphael is awesome, if a bit obfuscated

I wanted to play around with a more powerful graphing library, so I ended up choosing Raphael. The end result is smooth, awesomely extendable, and fast. Unfortunately the sample code is really hard to understand. A few comments in this file would have gone miles. So would have using regular hex color values instead of crazy hue math. There is also zero documentation from what I can tell. Yes, there’s a documentation page… it does not show you how to use it.

When you HTTParty, you must party hard!

My first turn when interacting with the Lighthouse code base was to turn to the Lighthouse API gem, but because of the ActiveSupport dependency — and quite frankly gem conflicts I didn’t want to deal with — I decided to go the HTTParty route. Honestly, it’s just too easy to use. It made dealing with the API a breeze.

Go forth and create Lighthouse miniapps!

Feel free to fork / steal the source (including the design!) and create more miniapps for Lighthouse. Everyone uses bug trackers differently, and sometimes the best idea is to just build the interface / chart / feature you need. This app should cover the basics of saving / validating API keys, as well as some simple examples of how to sync data locally through cron jobs.