Last year, in December, I held a 3 day Zope 3 training for about 10 Zope 2 and Python programmers. For this training I had prepared a 50 pages booklet with some tutorials and reference information (most of it written by me especially for this occasion). The feedback was pretty positive, but only time will tell if I was succesful or not with my training.

I have published the training material on Google Code in a project called z3ergo. My intention is to publish there more packages and tutorials, as they come. The beef of the tutorial was a simple but complete application called LearningJourney. My initial intention was to have an application where students could enter a log of the things that they learn, but it could be thought as a simple blog system as well. This is a full Zope 3 tutorial application, complete with a site, skin and registration process. I hope somebody can find it useful. The leaflet is published there in two languages (English and Romanian), in pdf format. You can find the source code for the docs in the LearningJourney docs folder.

The materials cover a lot of the Zope 3 landscape, as this training was for knowledgeable Zope 2/Plone programmers who were evaluating Zope 3 and also had access to other Zope 3 docs, such as Philipp's Zope 3 book. Keep this in mind when going through the docs and wonder why they're so slim.

The training itself was pretty non-formal. I've used the booklet and the sourcecode to guide them through what a Zope 3 application means. There were a lot of questions (practically, the training flow was more question based, with just a few interventions from me to guide it to a different direction), but many things that were covered mostly at surface. We didn't have any practical exercises, although I wish I was able to have them, it might have helped the students feel a little bit less lost. A more structured approach could have helped as well, who knows. It was both tiring and fun and I got to meet lots of cool people, with which I will hopefull colaborate in the future.

If there's an interest in getting more out of these docs, or you might need me as a Zope 3 trainer, feel free to contact me using this site's contact form.

A simple deployment of a Plone 2.5 site (I know, antiquated) means that the pages shown for anonymous users are loaded with JS and CSS content that they will not need. They are, usually, the biggest group of visitors, so it is important do make the pages load fast, to have a good impression for first time visitors. The introduction of the Resource Registry in Plone 2.5 makes it easy to set the order and the conditions to load each resource (and, as a result, the merging conditions between resource files), but there's no page to document what each JS file does, for example (AFAIK). Because of my recent need to optimize such a site, I've created a list of the javascript files loaded by Plone 2.5. Plone 3.x makes it even easier to make sure that you get the minimum number of merged resource files by having the "Automatic grouping" function, but for Plone 2.5 I had to rearange the files myself to get the best result (3 JS files: one for anonymous users, one for users that are authenticated and one that is loaded for Kupu).

Recently Martin Aspeli published a very nice buildout recipe that implements a complete setup for a production Zope/Plone server. One of the key components in that setup is the load balancer, which is implemented using the load balancer capabilities of nginx. Nginx might be a good load balancer, but it has a problem with the way Zope/Plone works: the first page loads, for a newly restarted Plone instance are very slow (especially if the site or the catalogs are big). It would be nice to have a way of telling nginx to take out one of the Zope instances from the cluster and then add it back once it's restarted and has its caches warmed. Sure, you could probably script something that would change the buildout options and reload nginx, but why bother when there's a load balancer that offers this and much more?

Crossroads (in its second version, at the moment 2.41) might lack the popularity when compared to perlball, pound or haproxy and may not even have the same features or performances (it's good enough for my needs and I haven't cross-benchmarked), but it's fast, easy to configure and, best of all, it can be configured to provide a web configuration/administration interface. This way, when a Zope server needs to be updated, I can take out the ZEO client from the balancer, restart it in supervisor, warm up the caches by calling the zope sites directly and then add it back to the cluster. The only faults that I could find to it is that the compilation mechanism is not very well tested (I couldn't complete an install with a specific destination prefix. Just checkout the Crossroads trunk or a tag and do a "make local", then you can use the xr binary from that folder). On the other hand, it's pretty well featured: it has sticky sessions, HTTP awarness (although its documentation recommends treating the http servers with the TCP algorithm), can use an external program to determine backend states (and could be plugged this way with Zope's ICP support), etc.

Below is a screenshot of the Crossroads administration interface, with Crossroads started with the following script:

#!/bin/sh

XR=/usr/sbin/xr
SERVER="-s http:127.0.0.1:7000"
BACKENDS="-b 127.0.0.1:9080 -b 127.0.0.1:9081"
ALGORITHM="-dl"
HTTP_FLAGS="-x -X"
TIMEOUTS="-t 10"
CHECK_CALLS="-c 10"
WEB_INTERFACE="-W 127.0.0.1:7020"
#DEBUGGING="-v"
DEBUGGING=""

$XR $SERVER $BACKENDS $ALGORITHM $HTTP_FLAGS $TIMEOUTS $CHECK_CALLS $WEB_INTERFACE $DEBUGGING