Europython: eXtreme management, design by contract, bebop groupware¶

Maurits van Rees - eXtreme management of projects in plone

Maurits made an eXtreme management application to manage XP projects. Main element of his presentation is XP's planning game . The planning game is about having short (1 till 3 week) iterations, stories, tasks, etc. instead of One Big Project.

eXtreme management has separate roles: manager (can do everything), employee (can't mess up the project planning after start of an iteration) and the customer (can't change things after work has started).

At Zest software, we normally give managers and developers that role site-wide, customers are added locally to the projects, so that they can only view their own projects.

Stories can be added by both managers and customers. The initial workflow state is "draft", after the story is well-described, the customer can submit it for estimation.

Rough estimation (by the manager and the developers) is done on the story level and is measured in days. You get a more detailed estimate by adding tasks to the story, tasks are measured in hours. Developers add those tasks to the story and estimate them. The total of all tasks is the real estimate for the story.

There are a couple of checks in the system: you cannot activate a story without first adding tasks and estimating them. When you do activate something, everything inside it also gets activated and ends up on the to-do list of the developers.

Developers can book their hours directly on the tasks, which also shows up to the customer: an unknown level transparency for the customer.

Aaron Bingham - Design by contract in python: present and future

Why design by contract ? Precision and accuracy in documentation, so quality. The documentation cannot get out of sync with the code. A common question is "why do we need it, we already have unit tests". Design by contract adds to unit tests, does different things. It is stronger at catching integration issues. And it allows you to code less defensively, as any uncertainties are catched by the contract. Less defensive code means less code, which is good.

The three essential parts of design by contract:

Preconditions

Define client responsibility. The client is the program part that uses the class that defines the preconditions. "If you want to use me, you'll have to keep this contract".

Postconditions

Define provider responsibility. The provider is the class that defines the postcondition. "You can expect me to return a list. Not a dictionary, no, a list."

Invariants

Things that are always valid. "You can always call me and ask my length".

All three are checked before and after every call to a class method. In the original (eiffel) definition, it was qualified calls, but we don't have something like that in python.

Python's assert statement is handy, but it is "just" internal checking, it doesn't have anything to do with contracts.

There are some people who tried their hands at an implementation for python. He demoed his own prototype (aspects), pep 316 has something, Plösch, ipdbc, pydbc. In the end he compiled a table comparing all the approaches.

Conclusions on the state of implementations. A solution using decorators would be interesting for comparison. Only the PEP and Aspects are workable solutions right now.

Aaron's conclusion, in the end, is that we're not far off.

Uwe Oestermeier - Bebop, a zope3-based groupware

They packaged their zope3 server as an out-of-the-box downloadable application, which looked like a userfriendly way of distributing it.

One of the things that Bebob manages is documents. It keeps track of versions and the various users are notified that they have to download new versions if someone uploads a new one. There's also a blog, a wiki and a message server (I missed the first 5 minutes of the talk, so I might have missed some additional ones).

Bebop has a central catalog with indexes for authors, documents, versions, dates: who did what when?

Their current setup is a central ZEO server, the wxPython client connects via ZEO, the metadata is the zodb, the actual files are in the local filesystem. They are thinking of using twisted instead of ZEO.