Making Harvest awesome! (My GSoC 2010 project) — Week 1(ish)

It is time that I babble about my project for Google Summer of Code 2010!

Over the summer, I will be working on Harvest with Daniel Holbach as my awesome mentor. Harvest is a neat web service, built with Django, that brings together opportunities (things that need doing), from many different places on the web. Those opportunities are all neatly linked to source packages, which are, themselves, nicely described by package sets like ubuntu-desktop, unr, xubuntu and kernel.

Suffice it to say, Harvest is a huge database with a lot of intricate detail. It can be really helpful to see all this stuff in one place. My task is to implement views that harness all that data and resist the temptation to throw it all at the user at once. The result should be really helpful, quick and fun to use. (This may be difficult; I can be a very wordy person).

The first stage to achieving that is filters.

I’m using an existing wiki page as a starting point, which has one very pretty mockup. I created a mockup of my own, full of crazy tangents and marked by the single worst green pencil I have ever used.

There are a few crazy and opinionated things I want to do. First of all, I want to go as far as possible without a numerical paging system. Numerical pages make no sense. The second thing I want to avoid is a detached searching system; I think searching could be integrated pretty smoothly with filtering, so everything on the site works under the same rules. Third, while I want this to work really well with Javascript, it has to work well without Javascript.

Last week I continued familiarizing myself with Harvest, and I made a start on the back-end for the filtering. I am building a generic structure that describes all the filters and what they do in terms of database queries. This way we can change the mechanics or add new filters quite easily (and have them do all sorts of neat things), and we’re secure from people executing arbitrary operations on Harvest; only filtering operations that we define can be run.

The actual visual portion of the filtering stuff is entirely detached, and it is non-existent at this point. I expect the rest will be easy to pop together once the back-end is in place.

So, yeah, not very exciting yet. It’s Harvest, and the list of packages is filtered. The URL format is, of course, not at all decided but it’s most likely going to carry parameters with GET. That way people can link straight to Harvest showing a particular query. The one for that screenshot is /opportunities/filter?pkg=name,set&pkg_name=ge&pkg_set=ubuntu-desktop,core, which describes a package with a name that starts with “ge” and belongs to the “ubuntu-desktop” or “core” package set. I would love to know if that looks sane to anyone but me :)

Exciting, eh?

This week I will be doing a bit more with the invisible half of the filtering system, then I’ll make a start on the user interface half. Still nothing pretty (yet), unless the urge overpowers me; just drawing the widgets and having them do the right thing when they are clicked. I want to test my approach before it’s stuck that way.