Europython monday morning¶

Monday morning talks from the europython conference.

See also the complete write-up overview . Zope keynote - Tres Seaver

Tres Seaver created the Content Management Framework (CMF), which is the basis for most plone-like systems. Zope 3 (the upcoming new base zope release) learns a lot form CMF. A good thing about CMF is that it lets you replace almost any part of it with something else, making it extensible.

Last year at europython, there was a watershed moment for the cooperation between the various projects based on zope 2 (plone, silva, cps, etc.). Everybody acknowledged that they need not re-implement all sorts of things that ar really common for all of them. Since then, there's already been a bit of work on common parts. All this work has been aimed at zope 3, not zope 2.

The first effort was at creating infrastructure components for zope 3, but in the end there was instead a lot of focus on integrating zope 3 stuff into zope 2 (using the "Five" project). The important point is that this opens up a migration path for the existing customer sites.

CMF roadmap. The next CMF version (1.6 or 2.0) will require zope 2.8 as it will use lots of zope 3 stuff.

All the interested projects will share their framework components (so not the skin level) at http://z3lab.org/ .

Zope will move to a 6 month release cycle. Zope 2.9 and 3.2 ship together in december 2005. The latest 2.8 zope came out in may, included is the 3.4 zope object database with some very neat multi-concurrency-version-control.

In October 2005, the zope foundation will start, it will own the copyrights on the zope source code. According to what I've read about it the current situation (with Zope Corporation owning it all) was pretty safe, too. But this move makes it even better.

Architecture of a large zope 3 system - Steve Alexander

Steve works for canonical, which makes the Ubuntu linux distribution. One part of canonical is the launchpad, basically the organisation that manages and organises it all. And it's a big zope 3 project.

Launchpad: 30000 lines of code, 1 year work, 10-15 developers, 300 pages. With the next ubuntu version, launchpad will be used for mostly everything, so it must survive a slashdotting and it should be able to handle all the bug reports etc.

They can scale up a lot by making good use of the http semantics. Normal requests are GET requests. They should only read data, not change anything. These requests can safely be shipped out to a set of read-only replica databases (and they allow a lot of caching). The POST requests actually change things, so they need the read/write master database.

For their SQL databases they want the software to only use the custom wrappers, not the bare database access. So they put an "importfascist" around the bare database access modules, throwing an JackBootException when you try to use them directly...

They've build a set of custom TALES expressions to end up with less python code in their zope page templates. Looks good.

Astrid Hellwig - Who else hates selling? How to make your customer want to do business with you.

There's download material for this talk.

How to talk about business and how to feel about business? How do you feel about yourself. Business is about making others know what you know. Getting them interested in what you can do. Getting them enthousiastic about hiring you.

She saw as someone economic-like, not as a doctor. So no "you have a problem, how do we heal you?". But, why not? Try and see yourself, for a moment, not as a business person or a programmer or an expert, but as a doctor.

What do you do when you visit the doctor? You sit down and you explain. So, you're talking. So the customer is talking. The doctor's role is to ask more and more questions. That way the doctor creates in his mind an image of where the problem might be. Often the first problems to spring up are the perceived problems, not the real problems. So, keep asking.

Another important thing is to leave the choice to the customer. You can't force a patient to quit smoking, likewise you can't force a customer to go with solution x.y with z as an extra. You are giving your patient your opinion and your advice, but if the patient doesn't listen or makes a different choice: next patient. It is, in the end, the patient's choice.

Especially for freelancers, there's always the problem of your rates. How much are they going to pay you? If you think of yourself as an expert experienced doctor, your attitude can be different. You took care of a good atmosphere, talked a lot with your patient, got a good idea about the actual problem. Then, tell your idea to the patient, suggest a treatment and tell them how much that treatment is going to cost them. Point.

And if they say "I know somebody else that can do it for half the money", just let them go. Perhaps with an "you can always come back if it doesn't work". But if you describe their problem well and suggest a good-sounding treatment - it is a good reason for the "patient" to take your suggestion and the associated bill.

She at first disliked the analogy, but she now likes it a lot. So she encouraged us all to take a good look at it and think a bit more about it.

In response to a answer on how to get clients/patients to come to you: you're greatest asset is being a social being. Talk to them. Try to meet them. Talk with them over lunch. Forget brochures. Those can turn into excuses for not talking to people. "You just leave a brochure". If you've got some spare money, a brochure won't hurt. But don't use it exclusively.

Her recommendation: test this approach and see it as an additional possibility.

Comment that got postponed: make your code open source, it gives you visibility.

Martin Aspelli - Making Money on Plone - Why The Model Works

He's a student at a London management/economical school and does his dissertation on the plone community and the economical stuff behind it: why does the model work.

Plone started out as an open source project and it will always be open source. It's central to the attitude of the community. There are a lot of small consultancies and freelancers earning money with plone. There's a plone foundation and there are explicit strategies for marketing and branding and community building and it was always meant as a way to make money.

Plone is a community. When you start to contribute a bit, you'll soon start to feel like you're really a part of a community. At the same time, there's good leadership.

Plone developers get a lot of benefit out of the base platform. It's a lot easier to customise plone than it is to do everything yourself from scratch. You save a lot of time. Also, plone is a brand and it starts to get known, which is a benefit. As you get productivity rewards, there is a good reason to contribute back to make it even better and to keep the momentum going.

There's a concious effort at community building. Some people are actively shepherding for instance the discussions on the mailinglist, keeping them constructive. Also a very good thing is the sprints, where you can get to know other (including core) developers.

The whole process works because there's a good community. If there's a lot of friction, lots of programmers won't fix bugs because it's just no fun. With plone, it is fun to fix bugs!

What makes plone plone is not so much the technology, but more the community, the leadership, the businesss model, etc. You could try and create a new product, but it would take a lot of effort and a lot of special people to build something as good as the plone community.

Btw, the dissertation ought to be finished in september :-)

Theune - AlphaFlow: Background and Technical Details

The existing workflows for zope didn't fit in well with some of their client requirements, so they decided to make a completely new thing: alphaflow.

You've got process definitions: activities. And you've got process instances, attached to content objects, which contain workitems (instances of the process definition's activities).

One way to deal with process control is a central, monolithic process controller that controls the flow between activities all by itself. Another option is to have distributed process control. They used this. Initial work items are created by a small, simple process controller. Work items are generated by their activity (inside the process definition). Work items, in turn, are available for generating the subsequent parts of the process. So: distributed.

He did a live demo. Not much I can say here, but it looked good. After performing a first action on a document (for instance approving it), the workflow mechanism generated three new actions for three other needed review process. The current user could then assign reviewers to each of the three review actions. So it looked like alphaworkflow is much more customisable/steerable on the content level.

It is in production in a large intranet (100 editors, some 3000 anonymous users, multiple GB content).

Community and Cash panel

Martin Aspelli had a nice example about yes/no open source. He made two modules for a conference organising company. One contained a lot of knowledge of that company, which made it competetive; so he advised to not make it open source. The other was more of a job board thing that the company just needed to be draw equal with others; he advised to make that open source as it would enable him to draw on the help of other developers as it was of generic interest.

Rodrigo Senra said that it is very important for governments to be able to audit the software, so open source is a good fit in that regard.

Martijn Faassen's experience says many companies just don't care and you can contribute code back to the community all you want. Also, some almost force you to make it open source, some get scared when you start talking about open source.