Archive

Archive for September, 2004

A Few Simple Rules

September 2nd, 2004
Comments Off

We held the post-mortem
for Helium this
morning. Lots of things went wrong, but many more went right—it was
a fun, productive summer.

Lots of things contributed to the fun, but much of the productivity
can be attributed to one thing: everyone learned to use modern tools,
and adopted good working practices. Many projects stumble or fail
because programmers aren’t willing to do this—far too many, young as
well as old, still insist on using Vim, Emacs, and other legacy tools.
This doesn’t just make them less productive; it also
handicaps the rest of the team, since it prevents people learning from
each other, sharing resources (such as useful keyboard macros),
doubling up to debug hard problems, and so on.

So, with that, the post-mortem,
and the Joel
Test in hand, here are the rules by which this fall’s projects
will be run:

1.    Everything important is versioned.
Source code, web pages… anything and everything that you need
to build, install, or debug the project goes into the Subversion
repository.
2.    Everyone uses Eclipse.
And Ant. And JUnit. And all the
other
tools
that are part of the environment. If you don’t, you are slowing
down your teammates, and making extra work for them.
3.    The build is automated.
And all tests are re-run by default every time the project is
built (which will be every 30 minutes, round the clock).
4.    Anything that isn’t done immediately goes into the issue
tracker.
Why? Because even if you would remember it a month from now,
teammates who weren’t sitting with you when you slapped your
forehead and said, “D’oh!” won’t.
5.    Everyone writes tests,
preferably before they write the code itself.
Take a look at Helium’s
progress
chart; one of the reasons the team go that far, that fast,
was that they tested early, and tested often. You owe it to
your successors to do the same.
6.    Everyone fixes bugs.
Code is done when it’s all typed in; code is done when it
works, and “working” means “working for everyone, everywhere,
every time”. (Yes, this means that most software is never
done…) When your tests turn up bugs, file ‘em and fix ‘em
before implementing more features. Experience shows that this
will make your work faster, since you won’t constantly be
doubling back to shore up the foundations.
7.    Every large piece of work is sanity checked before
code is written.
Thinking of reorganizing some of the data model classes?
About to write forty new classes to handle threading of
email conversations? Grab a teammate and a whiteboard, and
explain what you’re about to do, or send email to the list,
or fire up IM. Anything, just as long as someone else gets
a chance to tell you when you should switch back to decaf…
8.    Every meeting start with an agenda, and ends with minutes and
an action list.
Where possible, the agenda should be circulated before the
meeting begins; the minutes and actions must be
circulated soon after it’s over (and added to the project web
site).
9.    Have fun.
This is the most important rule of all. (“Floggings will
continue until morale improves…”) Your project isn’t just
about marks—it’s about learning new things, making new
friends, and building something you can be proud of. Most of
the students who’ve done projects in the past have had a lot
of fun—we hope you will too.

Uncategorized

Tasks for the Fall

September 1st, 2004
Comments Off

We’ve finalized the list of things we want to accomplish between now and December, in order to be ready for beta use in the Winter term:

Bug tracking system: we need to build a simple issue tracking system (like
Neon‘s) that
integrates with Subversion, the rest of Hippo’s user interface, and the
server-side scripting framework. UI, database work, testing—this has
it all. 3 people needed; one slot spoken for.

Server-side scripting: one of the big differences between Hippo and other
systems (like SourceForge and GForge) is that Hippo has to support dozens
(possibly hundreds) of more-or-less identical projects (for courses like
207, in which each student is working on their own version of each
assignment). Creating these one at a time through a web interface would
be painfully slow, so we need to build a Python library that can talk
directly to the data model classes in Hippo. That way, administrators and
profs can write little scripts to create projects, user accounts, bugs,
and so on. (Why Python? Because there’s a version written in Java,
called Jython, and since we’re teaching it in courses, we can reasonably
expect profs to know a little about it.) 2 people needed; both slots
open.

Email system: the Helium team made a good start on an email management
system, but lots more need to be done. Spam filtering, threading… it’s
a long list. 3 people needed, all slots open.

Testing frameworks: this team will *not* be responsible for testing Hippo
(each team will be required to test its own work). Instead, this team
will integrate and customize some open source testing tools, like HtmlUnit
and HttpUnit, so that everyone else can test the user interfaces they’re
building. I expect that some of the work this team does will be folded
back into the official releases of those tools, so if you’re looking for
an extra line on your resume… 2 people needed, both slots open.

Server-side subversion: David James is already at work cleaning up the
Java interface to Subversion, so that we can make it do what we need it to
do on the servr side. No more bodies are needed for this one.

Uncategorized