A report from the first day at EuroPython

                       Europython conference report, day 1
                       ===================================


:Date: 2003/06/25
:Location: Charleroi, Belgium
:Author: Stéfane Fermigier, Nuxeo (http://www.nuxeo.com/)

Note: 

- Text is a transcription of what the speaker said, or what I read on the
  slides. Out of band comment are marked like this [SF: this is a comment]. 

- Most errors (including grammar and spelling) are mine, not the speakers.

- Since there were actually 3 tracks running at the same time, I only cover the
  talks I did attend.


Guido van Rossum: State of Zope 3
=================================

I'll be representing Jim Fulton who couldn't come here.

Many people in the audience are curious about what Zope 3 is, what are
Zope Corp's plans with Zope 3, etc.

Zope now has issues: you can get into Zope quickly, and do some basic work
really easily, but some people hit a brick wall after some time, unless they
reach "Zope Zen".

Zope 3 is a big redesign of Zope 2. All the good things are there, the not so
good things have been removed.

Zope 3 is a component archnitecture, but the notion of modules here is quite
different than the modules in Python.

A cool idea (IMO) is adaptation: you can ask Zope to "adapt" an object to an
interface, if it doesn't implement it already.

Zope 3 is more explicit, especially wrt acquisition.

There is flexible configuration, using XML (ZCML, in fact).

Other useful stuff are:

- schemas (interfaces that are able to also descibe the user interface to
the objects)
- a different approach to security (proxy based, more flexible (pluggable))
- filesystem development and TTW development can be done at the same
time, with synchronisation between the 2 of them

- The new TTW development model: in Zope 2, there is a special folder,
the "Control Panel", that contains site-wide managements stuff.
In Zope 3, you create (local) "control panels" anywhere in the site.

- Software packages should be much easier to install / uninstall using
bundles (still not done yet).

- Easier software customisation

- Sites can be nested.

Roadmap
-------

Zope X3: experimental platform for working out new ideas and architecture.
There is almost no focus on transition from Zope 2.
We try to create the best system that can be possibly built.

There should be a milestone release at the end of june, a beta1 in july (maybe)
and a final production-quality release by october 2003.  Zope Corp will be
using X2 for consulting and products projects by that time.

Notes: these are only estimates, since most of the development is happening
outside of Zope Corp. Of course, people, as it should be, are busy earning
a living with Zope 2. We have the luxury to take time to get things right,
since we stull have Zope 2.

Zope 3.0: will provide support for migration from Zope 2 applications.
Alpha 1 should be available in january 2004, beta 1 in march an final by
april.

Zope 3 in Zope 2: release thins fall with pretty much all the source code of
Zope 3. This should help migration from Zope 2 code to Zope 3.  Zope Corp is
already doing this (on an internal non open source project).  This will require
Python 2.2. ExtensionClass will be based on new-style classes.

ZODB 4: it was delayed recently to focus on Zope 3, so Zope 3 will 
initially use ZODB 3.3.

What have we done so far ? Zope 3 is running (in production applications).
Most basic infrastructure is in place. We've got a working ZMI. There
is a basic tutorial for developers. Zope 3 is really developed using
systematic unit tests (4500 of them).

What is still missing ? Default UI skin, filesystem synchronization, bundles,
move and copy (there are many deep issues), local interface services (similar
to types tool in CMF), i18n, something like the catalog, interface
classification (some interfaces are implementation details, other are important
for user interaction, so we need a way to sort it out), ZConfig integration
(ZConfig was initially started for Zope 2 and need to be ported), undo, cache
framework, local module service, security reorganization, WebDAV / XML-RPC,
process control, broken-objects support (objects that can't be safely loaded
from the databae after a software update), something roughly equivalent to
Python scripts (maybe modules), properties, persitent modules, documentation
)cookbook, online help, online component and interface browsing).

How can we get all of this done ? We have a core of people making
continuous progress, but new volonteers will certainly help.

Filesystem synchronisation
--------------------------

That's my own pet projet. You want to edit your site with your preferred
editor, not a text box in your browser.

The current solutions are: 

- use FTP or WebDAV, but many objects types don't map easily.

- use ExternalEditor, which is cool if it has been set up for your particular
type of objects.

- use fssync :)

Other motivating probl`mes are that you may want to use your favorite tools
like find or grep on your Zope content. You may want to store ZOpe content on
CVS (there are many cases were Zope undo is not sufficient). You may want to
transfer updates from a staging site to the real site.

You can do al of that with fssync (if you have the right imagination :-).

What does it do ? It mirrors ZoPe objects to the filesystem:
  
- folders <-> directories
- other objects <-> files with appropriate content

with a command line interface similar to cvs (fssync checkout / update / diff /
add / remove / commit / checkin ...). 

It uses "XML pickles", which are much easier to read (and edit) 
than standard (binary) Python pickles.


Steve Alexander: TTW development with Zope 3
============================================

[Paul Everitt: "When Jim Fulton is lost with Zope 3, he calles Steve".]

I'm going to talk about the kind of programming you can do with Zope 3 without
writing any Python code.

Zope 2 provides ZClasses that let do object oriented programming TTW (through
the web). Lots a people ask if that kind of work will be doable in ZOpe 3.

ZClasses are good because they are easy to get started with, and provide a
pointy-clicky interface. But they have several disavantages. The main problem
is that you can hit a brick wall (impossibility to change base classes, need to
move to real Python code) and need to start all over again. They also have a
poor user interface, are hard to distribute (they are basically binary .zexp
files, so you can't put them in CVS), and have poor ZCatalog support.

So ZClasses are not part of Zope 3: we need something better.

In Zope 3, you've got "marker interfaces". Using the "introspector" in the ZMI,
we can add (and later, remove) new interfaces to objects.  For instance a case
insensitive folder interface: the "friendly folder" product developped thin
week provides a special traversal component for marked folders. We can also
provide special views and special adapters.

In Zope 2, you can do "one-off" development with PropertySheets (in the
ZClasses) or by mixing in the PropertyManager class, so that you can add
arbitrary properties (from a fixed set of types) to your objects. This is in
opposition to "product development", where you want planned, generalized,
reusable code, built by "experts".

"One off" development is also important, because it is more pragmatic, so
we want to support in in Zope 3, using:

- Python scripts
- Pages with templating and scripting
- Properties and property sheets (using schemas and schema fields)
- Marker interfaces
- Through the web views and adpaters
- Relationships, queries and indexes (these are already in Zope 3, but
not customizable TTW yet)
- Fields, widgets and forms

The transition from "one-off" to "products" whould be smooth (no brick wall),
and human readable exports to the filesystem.

There will be a "default" propertysheet in Zope 3, similar to PropertyManager
in Zope 2 but without need to mixin.


Albertas Agejevas: Extreme Programming and Zope
===============================================

What is XP ? An agile process for small teams (less than 12 people) for wuickly
developing high quality software, in the context of unclear or changing
requirements. XP was invented by Kent Beck, Ward Cuningham, Ron Jeffries.

In XP, out of the 4 variables: quality, time, cost and scope, only scope is
allowed to slip.

XP is based on 4 values: communication, simplicity, feedback, courage
and 12 practices.

[End of talk skipped since this is a subject I knew already pretty well,
since we're already using some of the practices at Nuxeo.]


Thomas Reulbach: Zope in the public administration
==================================================

My personnal background: I work in the administration for the Bavarian
Government.  I came to Zope in 1999.

For me, Zope made it easy to create portal-like websites.

Zope can easily provide scenarios in eGovernement (A2C, A2E, etc.).

Steps into the future: collaboration between the different platforms (which are
mostly now "below the radar" for the decision makers), gain momentum, manage
anxious bosses and IT-departments, work on documentation to make it look
more professionnal ("use the source, Luke", is not an answer here).

Conclusion: public administration has the need to use software that is free.

[SF: Talk was a bit too short, due to some problems with the slides. The
subject is a very important one anyway. For those interested, and who can read
french, we wrote a white paper ( http://www.nuxeo.com/nuxeo/wp/zope4gov.pdf )
last year on the subject of Zope in the European Public Administration.]


Kit Blake, Silva environments
=============================

We develop open source software. Our customer pay for development and support.
Our main product is Silva.

Silva does authoring, management and publication of structured, versionned
content. Silva works as a delegation system: There is workflow to coordinate
the process from individual authors.

Users are managed in LDAP. There is an independent product to manage groups.

News features since last year: unicode support, metadata architecture, all
objects are catalog aware, messaging integrated in workflow, file system based
storage, high resolution image storage, image scaling, bulk import, integration
with external editors (Xopus, EditOnPro), etc. [SF: this was too fast or me to
keep up].

Silva metadata is an independent component that can be used by other projects.
It allows users to create and edit new metadata.

Docma (document maker) is a suite of applications that convert Silva XML to
other formats (XML and "round trip" to MS-Word).

OAI (Open Archive Initiative) is a protocole for metadata harvesting. We have a
Python harvester and and (independent) Zope product.

Forager is a tool that forages though CMF documents for structured text, and
converts it to Silva XML.

Future: we expect a browser-based WYSIWYG editor, reference management,
cataloged search and display functions using metadata, internationalized
interface.


Armin Rigo, PyPy
================

PyPy is a project to rewrite the Python interpreter in Python. Three questions
come immediately to mind: why ? how ? how slowly ? [:-)]

Why ? 
-----

Because it is fun (much more fun that writing Python in C); for improved
flexibility (it's much more flexible to write thing in Python than in C, for
instance you can subclass things, etc.).

How ? 
-----

You need a bytcode compiler (out of the scope of this project), an
interpreter main loop that goes through the bytecode step by step, and
something we call ""Object Space" (a nice name for a library) that contains the
semantic definitions of the language. For the interpreter, objects are like
boxes defined by Object Space.

There is standard Object Space, used to emulate the normal behavior of Python
objects. We have chosen not no mimick CPython implementation too closely. We
have introduced multimethods to define what is "an integer + an integer", or "a
float + a float", etc. This gives us much more flexibility than CPython which
uses methods in each type, that need to know about all the possible type
combinations. It is very slow (like 0.1 pystones).

There is also a native Object Space, that is very small but is cheating: is
uses the objects from the CPython implementation. It is faster, and still
flexible enough to do useful experimentations.

How slow ?
----------

We have an annotation Object Space whose goal is to run with some information
about the real objects, like "x is an integer" (whose value is unknown). It's
basically a kind of type inference engine.

Using this technique, we can accelerate PyPy by creating a "restricted Python
to C" compiler ("restricted" means that we can't do things that are too
dynamic).

Back to "why" ?
---------------

You could emit code in other languages than C, like Java, C# or OCAML.

We can use PyPy as an experimentation base for differents ways to do profiling,
memory management, data structures. 

The project started early this year. We've already done 3 one-week sprints.

[Laura Creighton: I would like to know if there is some Subversion developers
here, cause we would like to say "thank you!".]


Alex Martelli: Python Metaclasses
=================================

This talk is for people who want to know more about Python's OO underpinning,
metaclasses and custom metaclasses.

A key book is "Putting Metaclasses to Work" (out of print). It had a strong
influence on Python 2.2.

[SF: I had to stop taking notes at this points, but I highly recommend
that you check out Alex's slides on the EuroPython web site:
http://europython.org/Talks/Slides/ep03_meta.ppt ]


Francis Glassborow: Building a Sucessful Distributed Community
==============================================================

[Tim Couper: FG is the head of ACCU, which used to be the Association of C/C++
Users, and is now just the ACCU. He has read over 1000 books on programming,
which is probably a record !]

In ACCU, the fee is the same wherever you are in the world, even if it costs
more to send the publication to Australia that to the UK.

In ACCU, people said they wanted local meetings, so we set up local meetings,
and it didn't work out.

A community should have a common interest, a sense of responsibility, should be
caring (but you can't care if people don't let you care). 70 % of human
communication is gossips (the person matters). Communities are people.

How do you build a community ?

Comunication: publications that allow people to express themselves the way they
want to do (not academic journals), contact information (it's much harder now
to find email adresses of people because of spammers), meetings (internet
and virtual meetings are not a substitute for face to face meetings), internet
(newsgroups, emails...).

Publications: printed or electronic ? The problem with printed is deadlines.
But you have to do printed. How often ? No less often than every 2 months. A
quarterly publication is too long. Should it be peer reviewed or not ? At
ACCU, we have two publications, one peer-reviewed and one not. Only really
extremists or lunatics submissions are refused from the not-peer-reviewed one.
An advantage of peer-reviewed is that it encourages people to participate. The
content should be whatever people want to write.

Meetings: make sure you've got someone willing to organize things on location.

Internet: it has several advantages: it's worlwide, low cost, and
instantaneous. But it's not face to face, which can lead to enourmous
misunderstandings (many flame wars just come out of basic misunderstandings).

Leadership: it matters immensely. Try never to say "someone ought to do...".

How do you keep it ? How do you remove it ? For instance, if there is money
involved, you need someone good at handling it, not just a programmer.

Conferences: who organises ... the programme, the administration (you need
someone who understand that, for instance the importance of negociation), the
little things, the big things ? How do you find speakers ? A lot of people are
very timid. How do you find delegates ? It's a matter of intuition. You can use
your (electronic) signature for promotion.

What really matters is people. You need to trust the speakers and trust the
audience. 

People matter, that's the secret of distributed communities.