Sunday's sprint wrapup! A nice day of sprinting. Everyone was busy, including all the new first-time sprinters. We had a great round of pastis before the wrapup thanks to AtReal :-) I really enjoyed the Good Stuff :-)

zodb benchmarking

Made some observations. Tried adding lots of simple objects in various batch sizes to get good metrics. Increasing the batch size made it detoriate exponentially. If you stay with a memory-only zodb you can get literally millions of insertions per minute. They suspected a big influence of the mac disk that they did the test on. They're going to continue tomorrow with plone content types, concurrent commits, etc. It also turned out that it is important to pack your Data.fs., as after adding 200k of objects some 30 percent of the database size was taken up with transaction info.

plone survey

Smallest team, 2.5 person. They can have both a 2.5 and 3.0 release out tomorrow. They're still working on KSS stuff to make it more usable, though. Fun to work on. Did a lot of internationalization work.

PrimaGIS

New buildout. Refactoring. Tilecache enable now, really fast now compared to what it is now. New demo creation on the way.

KSS

jquery problems: bugs in the jquery demo code. jQuery events started (success). "Back" button works better now. They tried working on "push" and have a working demo: it really worked, though I don't know how they managed it. Great great stuff.

Translation group

Lots of stuff working. Most of the fields. Hope to have most of it working tomorrow.

sqlalchemy

Bad day. Fighting the stack, including zopetestcase. Ported code to collective.lead (great as it is in Martin's book).

AT rest

Didn't get finished. Saw how to do it. Great help from Ramon: checked in plone.rest tonight. Also fighting against the stack.

getpaid

Completely converted to genericsetup. Got two bugs fixed. Got some 40 tests added, so ready for tomorrow's refactoring. Added some screencasts: they're going to market the hell out of this puppy.

KSS part 2

They've added Django support to kss! Within one day. (Big applause)

workflow tests

They've found out a lot of bugs in the basic product. Worked a lot on tests. Got them running. Now testing workflows is way easier. (Note to self

workflow

State workflow and activity workflow. Trying to switch between the two. Lots of work, but good to have the current results.

Functional tests

They have two new scenarios for generic reusable testing. And they now have a tutorial. Improved comments. Code cleanup. Buildout for selenium.

Vice

Less work for customizers needed, just override the adapter. Should make it easier. Functional tests have been greatly improved. Fixed some basic datetime tests. Polishing of the user interface.

New themes

ZopeSkel was fixed for windows. They worked on concrete designs and Spliter demoed them. They had a great working day. They thought the new guys to create good non-messy themes. And they created documentation for this. They even have disability support guys. The examples are at openplans , for example capri theme , napoli mock . Spliter seems to be doing a hell of a job of shepherding everyone towards good designs. One comment: document your CSS files lavishly with comments, they are filtered out by portal_css.

Commenting

They were stripped down to 2 people today and went over the generic concepts, which turned out to be a good idea. They coded some and can add comments programmatically. They also use parts of easycommenting for KSS and templates. Nothing is really finished, but they have a good foundation. Tomster is looking forward to continuing with this.

Archgenxml

It works. Plone 3.0 compatible, trunk is now safe again. Improvements to the generated tests.

Nuplone

Navigation tree improvements, for instance the whole active section now has a background. The livesearch has great css now. There's also good multi-resolution support, too, so it degrades quite gracefully. When changing position due to resizing of the window, the colors of for instance the calender portlet change. Wild applause because of that feature. Looked like the darkest magic that you can imagine. :-)

plone4artists

Continued with the tests and got most of the audio tests fixed. Audio was released today, Rocky released the video later this day. More translations added, the framework is ready for more translations. The p4a openplans page details the translation mechanism. Calendering added a nice day view, tomorrow they hope to improve the week view. Tomorrow they hope to get it over to plone4artists for a release. Something usable is on the horizon!

Extreme management

We worked on moving portlets to plone 3 portlets. Worked on the workflow (generic setup). Some KSS added for body texts and descriptions. Tried to get macros to work with KSS, but started to work on viewlets instead as that works better. Worked on splitting out bookings into a separate product, that'll be soon into the collective. Reusable for others!

blobfile support

They got conversion of regular files to blobs working. Demo failed as safari crashed :-) He assured it worked :-)

Schema extender

Lots of doc improvements in the doctest. Looks like excellent documentation. There's an additional adapter for modifying existing schemas. I questioned the difference with generic ISchema overriding: they answer was that this product allows you to plug those schema modifications in. No conflicts. Multiple products can do it at the same time.

Technorati tag: ploneconf2007

A real quick writeup of a real quick "what did we do today" session where everyone presented what they did. (Hard to write down so quickly, aargh! Probably made a few mistakes.)

getpaid

Cleanup of tests, new translations, more genericsetup. Excellent way to get everyone

kss

New tutorial which reflects plone 3.0-style development. People worked on resurrecting the event-push system. jQuery work. Django integration for kss: a new framework that they support.

sqlalchemy

Fixed copy/paste bug. New buildout recipe that makes it easier to set up. Lots of discussion about catalog integration. Better ideas about metadata fetching.

extreme management

Exchanged information about how we all handle projects in different organizations. Figuring out how to handle both. Slowly getting there code-wise. Backporting a KSS experiment to trunk. Looked at

ploneGIS

User documentation. A new buildout. Work on a new demo product. Work on layers.

syndication

Some success, some snags. A big timezone bug bit them again, but they made good progress. They can now tag an alpha, mostly due to their remote sprinter.

archgenxml

Polishing, bugfixing, finding a bug in archetypes itself (and fixing it). Documentation is now much better. Probably archgenxml works nice for 3.0 tomorrow. Ideas about breaking the dependency on archetypes.

Functional testing framework

Documentation update. Debugging code improved. Additional component for search testing. Started a buildout for selenium integration.

New themes for plone

Mostly setup today, making sure everyone the whole big team got set up. Worked out what should be handled in a theme. Their new theme has newtheme.pizza as a code name.

Commenting

Team of four, two architects, two coders. Figuring out how to handle comment spam filtering. New project page on openplans. They made a buildout for plone.commenting. They have their first tests running.

plone4artists

Tagging products for a 1.0 release. Fixing the last bugs and getting everything ready. Started on the translations. Working on plone 3.0 support. Work on blobfile support with especially nice handling for plone. The calender team has 10 bugs that need ironing out, 4 of them are done now. And they added a 1-minute screencast. They hope to get more of them done.

plone.relations

Work was done especially on plone.app.relations. Trying to tie into user objects. Adapter experiments and teaching people stuff.

Project name that I missed

Just getting started. Had lunch.

Blobfile support

Figuring how to best integrate it without breaking things. Did groundwork like adding a contenttype and a buildout. They hope to write migration scripts tomorrow morning for ATFile and ATImage. They idea is to add an add-on package for plone 3.0 which will hopefully end up in the next major release. When the 3.0 product is done, they plan a 2.5 product.

Internationalization

Trying to allow customization of translations through the web so that you can make small customizations.

Workflow

Unittesting for workflows basically sucks. They tried to work with Matt Hamilton's (?) idea for using a .csv file for testing.

archetypes schema extender

It is now out of proof-of-concept. Seems to be really working. Improving the interface and expanding the doctest. Will be the way for schema subtyping.

plonegov

They were too hungry to wait for this wrapup :-) Plonegov will merge the three projects that deal with openoffice integration.

With standard plone, you can put newsitems in a folder and treat it as a blog. That works pretty well. Quills adds a better archive display method, remote editing, etc. That's the status for 1.6, which will be released fairly soon. 2.0 will be a good plone citizen without any custom content types.

There are several external blog editors, most of them support the metaweblog API which quills also supports.

For commenting, we want to look at easycommenting. Comments can be stored in an annotation. Or somewhere global with plone.relations to tie it all together.

A problem with quills is the product page on plone.org as it is not clear which version you ought to use. Tom acknowledges that as a known problem. We probably ought to finalize 1.6.1 and market that as the definitive version till 2.0 comes around.

Vice is intended to be a zope3 syndication solution. They're close to a beta release.

At the upcoming sprint there'll also be work on the spam filtering of comments.

The new 2.0 quills' usecase will be to configure generic packages into a blog solution for plone. Quite a number of those generic packages are being extracted from Quills at the moment.

Technorati tag: ploneconf2007

While preparing his talk he re-walked his own path from through-the-web and CMF developer to zope3 and modern plone developer. Why do we do that? Why do we want to do that? There suddenly seems to be a lot of bureaucracy involved instead of "just hitting the customize button".

The archipelago sprint (where development of plone 3.0 was basically started) he was exposed for the first time to zope 3 views, viewlets and so. So as a through-the-web developer he had to learn all the zope3 stuff since.

Ye olde way of working was with portal_skins. That uses acquisition to find templates, so it can be hard to find out why your template modification isn't used (as there's a template somewhere else. You also have macros and slots to use common templates bits and to allow some later customization. Python scripts have security limitations (it isn't allowed to do quite a number of things) and they are cumbersome to debug. And, perhaps most importantly, you can't handily do a lot of standard python things like subclassing in python scripts. Testing is also hard: black-box testing only, not individual parts of the script.

Ye olde way had some good points. Very straightforward: copy, edit, reload. "Customize" button. It works right away.

The number one bad thing: a lot of implicit magic. $@%^ what is going on around here? What is getting called by whom? And loads of application logic in templates. Summary: messy. "Acquisition is a jealous mistress".

And then zope3 came. A re-write of zope2 from the ground up. Tom draws a parallel with MacOS OSX. That was a complete rewrite, too. And they added compatibility with OS9 products later on, just like happened with zope2/zope3 by means of five.

A core benefit of zope3 is that it makes it easy to write small, specific, easy to understand code. You see much more reusable products nowadays. And it is explicit: it never guesses, it actually raises an error when it cannot find something that ought to be there (zope2 would effectively search somewhere else where you didn't want to look).

As an illustration: Tom was able to find and fix a bug in a core plone component (statusmessages) because that was a small piece of code that only had to deal with the request and cookies. That was it. It didn't have to deal with an enormous pile of extra zope/cmf/plone libraries.

(Tom then gave a demo)

Technorati tag: ploneconf2007

Panel members: limi, jonstahl, optilude, zopepaul, wiggy.

What do we want?

Paul would like to have clarity whether Plone is a project or a framework; should we be a real humane CMS or a platform for further work by consultants? Martin thinks it is a bit hard to tell a good story about Plone nowadays as plone itself changes and so many layers below us change even harder. Limi's vision is to make Plone the Macintosh of the CMSs: easy to use, consistent. He wants to make it easy to get early successes with Plone, for instance by allowing plone to spit out static HTML so that it is usable with regular web hosting.

How can we know?

Jon emphasizes that many non-profits try had to be a listening organization. It is something that is hard. Hard, not because we're bad at it but just because it is hard. For organizing the 2006 conference he put a lot of effort in getting data out of previous organizers and out of the potential conference goers as he hadn't gone to any previous plone conference.

Influencing Plone

Limi's recommendation for people that want to give feedback: write a log. Just a one-line description in a text file every time you see a problem yourself or see someone have a problem. Joel Burton's whole "humane CMS" talk has just such a list as the basis. He keeps a huge text file and adds a line every time someone has a problem. Jon got a lot of initial influence by writing down, on his blog and in a non-confrontational way, what he ran into with plone.

Some comments from the room

Vincenzo: there's still some infrastructure problems in Plone. For instance, the versioning product lay around for a long time before it was added. Also linguaplone needs/needed to be pushed forward desperately. Shouldn't there be some foundation activity there? Pooling of resources/money? Limi added that linguaplone was a bootstrapping problem. Once the initial release was there, it became easier to get additional funding. Doing it as the foundation is hard: look at getpaid which is very transparent, but still you can get discussion about "whether we got our money's worth".

Limi also mentioned oxfam, that funded kupu, linguaplone and versioning. They got the right people to build it and invested a lot of money, but not a ridiculous amount. Paul adds that it can be hard to steer new development: on the Plone ship, everybody has a steering wheel. Goldegg was an "illuminating" experience. Godefroid added that we now have a lot of zope3 inside plone, for which goldegg was essential.

There is a gap between adding bugs and suggesting features. PLIPs are mostly administrative constructs. The gap is mostly "filled" by the plone developer mailinglist, where new developments are hashed out (and where perhaps the consensus boils up to add a PLIP).

Someone else said it was hard for them as a integrator company to make good choices with all the new functionality that's available. Archgenxml? Archetypes or formlib? Products/ or lib/python? Eggs? Various zope versions? How to make a good choice? Martin says it is impossible to make a top-down decision on this and enforce it on everybody. Limi says that it is perfectly OK to be conservative as an integrator. He himself uses archgenxml as it allows him to create products at google without being a good programmer. Archgenxml internally is a mess as so many people worked on it. But it does exactly what it promises to do and does it well. "Don't base your company on it, but do try to use it".

A good thing about goldegg was that the situation now is really different from when goldegg started. We as Plone developers got a lot more respect from the people lower down in the stack (zope, cmf) and we can now commit to cmf and zope and they cooperate with us. (Andreas Jung got a special round of big applause).

Supporting releases

More or less officially, the concept of separate infrastructure releases and UI releases has been left behind. Wichert mentions there's still a question of intermediate (like 3.1) releases. Do we want to do that? Martin would like it, but we have to make sure it is at most a 10-minute migration task. When we have both 2.5, 3.0 and 3.1, we really have to think about encouraging people to move from 2.5. Limi says we originally wanted to support older releases for one year. We're currently effectively doing more. One year is pretty good for an open source project. Vincenzo injects that the problem is more with the add-on products. Martin says we ought to have a discussion about this afterwards and not make any fixed-sounding announcements here.

Technorati tag: ploneconf2007

Rocky has a narrow classification of subtyping: allowing subclassification of an existing content type. An advantage is a delayed specification: you don't need to know exactly what you want to do with a more generic type ("I'm going to handle files, but I might want to do special things with them.")

You could for example let a content type have a different identity based on the situation. An *.ogg file could be just audio, but also video+audio. He's made p4a.subtyper, a minimal framework for dealing with this. It hooks up subtypes into the content menu (in a special "sub-types" menu next to the "actions" and "state" menu). A simple demo is at plone4artists .

p4a.subtyper allows you to specify an interface for the new subtype and hook it up with a custom view. There's a special ISubtypeAdded/ISubtypeRemoved event that is fired when you (description by Reinout:) "tag a basic type with a subtype".

Extra info at serverzen.com .

Technorati tag: ploneconf2007

If you're going to customize Plone, do it on the file system. Develop on the file system as it is repeatable, versionable, distributable, testable. Also it provides a few extra possibilities you don't otherwise have. For a new theme product, please use paster with the ZopeSkel templates.

Most of the rest of the talk was a demonstration. Creating a buildout with paster. Adding a theme with paster. So I'll restrict my summary to some quick notes (and URLs).

For interactive development, use firebug to edit the css files in your browser and to immediately see the difference. Afterwards, copy it back to your actual stylesheet (portal_css needs to be in debug mode for this). Also handy: aardvark .

Normally, you don't need to modify plone's xhtml output. The id and class attributes are generally both enough and smart. And there aren't too many. So just leave it alone as you otherwise need to customize virtually everything.

Much customization of the main template can now be done by viewlets. You hardly ever have to touch the main_template anymore. You can modify or add viewlet managers and you can add or modify viewlets to viewlet managers. To see how the page is build up out of all those viewlets, add @@manage-viewlets to your URL.

Viewlets have two methods: render() for rendering it (html, text, whatever) and update() for setting parameters. If you want to register a new viewlet for a viewlet manager, you'll have to look in plone/app/viewlets/configure.zcml for the correct interface for which to register the viewlet.

Technorati tag: ploneconf2007

He works for the open society institute and they've recently started a big intranet on Plone. They also discovered quite some parallels between their society work and the open source movement.

OSI follows the philosophy of Popper about an open society. They grew and evolved in a quite organic manner, expanding to 32 national foundations. One of the challenges is to connect those 32 independent foundations. Some key initiatives: advocacy, education, media, local government, human rights, justice, public health.

Some key overlaps between open society and open source. Knowledge is provisional and fallible. If just a few persons or one government agency produces a document, it is fallible. The more people or stakeholders have been involved, the greater the reliability. If a lot of things are fallible, you have to be much more tolerant. Tolerant of different opinions. It needs transparency. Transparency is normal in open source, it is an ideal for a society. OSI publishes statistics and data on a lot of subjects to improve transparency.

Open source is pluralistic and multi-cultural. Just look at the number of nationalities present at this conference! Open source is often also open. Social mobility is a good measure of openness: can you move "up" based on your capacity and achievements?

Their new intranet brings together the employees from all over the world. They added a lot of "web 2.0" functionality: everything can be tagged, people can have blogs, you can comment on entries, news listings everywhere. Especially the tagging mechanism works great for discovering content from all the various foundations.

Some future visions. OSI sees itself as a microcosm for the global potential of collaboration. And they hope that something like their system can be offered as a hosted service so that other foundations without the needed technical capacity/capability can also use it.

There is a lot of good stuff happening globally. There won't be a real global change till those people and initiatives start to connect and interact. Plone can really help to bring about collaboration.

Technorati tag: ploneconf2007

PloneHRM - Jean-Paul Ladage

Jean-Paul started in his father's fast food franchise organisation, but he's seen the light and is now running zest software. He demoed PloneHRM. You can use it for managing employee information like addresses, contracts (with a handy template system), short notes ("he came in late today"), job performance interviews, checklists, etc.

Will be release shortly! (It is already available in the collective, btw). Paul Everitt thanked Jean-Paul that Zest keeps adding useful products to plone and keeps releasing it as open source :-)

Quills and blogging - tomster

There's a new quills version out that also works nice on plone 3.0. An approach they're going to try for quills 2.0 is to use normal content types instead of using the current custom WeblogEntry type. This way, you can mark a regular folder with content-that-has-a-date (like newsitems) as a blog. You could to this also with audio content, for instance, to get an audio blog.

The goal is to be less invasive. There's a BOF tomorrow to talk about it.

GoReplace - Georg gogo Bernard

GoReplace = smart folders + regular expressions.

They had to copy over old content into plone. For that, they had to somehow massage the old content. So they had a smart folder that had two extra fields: "find" and "replace", both being regular expressions. The found text gets replaced by the "replace" text.

Integration with desktop applications - plonegov

A product to handle meetings. You can schedule them and make the meeting minutes afterwards. And you can maintain a decision list. They somehow managed to put self.Title() in an openoffice formula field in a regular document. Re-generating the same document again, the title was filled into the document. You can also add notes to sections of the document (like `do for each item in self.items()'.

Semantic indexing - Giovanni Tofoli

Part of a big European research project (INTEROP), largely implemented in plone for storing semantic knowledge inside that project ("kmap" or "knowledge map"). The plonesaurus product supports the creation, management and use of taxonomic data in plone. Is-a relationships and so. Handy: lexical variants, so different labels for the same concept.

The taxonomy can be used to browse or search the items in the knowledge map ("get me all 'actor models'", or just "get me all 'models'"). For that, you can add a link from items inside plone to taxonomic entities.

Another nice feature: similarity search, which takes the current object and finds and ranks the other objects that are somewhat similar. And you can generate a picture out of it that shows taxonomy terms and the strength of the relationship between those terms.

Grok - Luciano Ramalho

The main site about grok is http://grok.zope.org . http://paleosoft.org is a site with simple grok examples.

Bundleman

Bundleman is specifically designed to help with zope2 products and bundles. Bundleman's bm-product adds a few files (VERSION, CHANGES, HISTORY) and it adds a bundleman svn property. To a product.

If you release a bundleman-enabled product, it updates the version number and moves the data in CHANGES to HISTORY. With --archive it creates a .tgz file. And it renames VERSION to version.txt, for instance.

bm-bundle manages bundles. If a product that it manages is released it uses it, if not, it releases (=tags) the product with the number you gave to the release.

Repoze - Paul Everitt

Repoze is an effort to get plone to run nicely on standard python stuff like WSGI. For this they need to look at a number of existing things to get it to work. WSGI, eggs, paste, virtualenv: this is how they do it. Zope ought to be factored out into middleware. And it works. He demoed it.

Included in one of the demo setups is deliverance integration. Handy.

sqlalchemy - Godefroid Chapelle

He demoed a simple example archetypes field storage that stores its data in a relational database via sqlalchemy. It is a simple one-line change on your archetypes fields to use this new storage. (updated: corrected (contenttype to field) after comment by Godefroid, thanks!)

Extra configuration - Calvin

For a site with lots of non-technical content managers, they're going to add some extra configlets to the plone configuration. For instance for choosing layouts, picking site color schemes, etc. Real admins can add new color schemes and layouts.

Technorati tag: ploneconf2007

Plone can do a lot of things and makes a lot of things easier. Plone 3 even adds versioning, staging and locking. PDF indexing. Smart folders. Open ID support. All out-of-the-box. For free.

But. Number of times you can grab the default homepage per second: plone 8, zope 227, apache 750, nginx 7462. So Plone is not the best delivery platform, even though it is an excellent content management system. There are some solutions. Cachefu, CMFDeployment (which exports it as static pages), entransit, deliverance, etc.

For some classes of problems, plone might not be the right tool. You don't want to track downloads with plone, for intance. Writing to the ZODB upon every read: that's not what the ZODB database is optimized for. Just as an example. And, according to Calvin, there are no nice Plone ecommerce packages. PHP has an excellent one and they used that for the ecommerce part of a site a few times.

Another thing: sending out mails to mailing lists from Plone. There are some solutions inside Plone, but they were not happy with it. Tying plone into some external mail sending app is often a better choice. Also look at salesforce for CRM integration for example. Those people have a lot of experience in their field and tying plone into their system might give your plone a nice edge.

Same with storage. Some data is better suited to a relational database. Large files can often better be handled outside the zodb (via tramline, for instance).

Our time is valuable. Why waste it by trying to hammer a square peg in a round hole? Pick the right tools for the right job and let Plone do the things it is good at.

Handouts are at http://plonebootcamps.com/resources/high-performance-plone/view, so I'm not going to write anything down. If you're in need of a speedup of your plone site, watch last year's talk (quite a lot is the same, only info on the latest cachefu version and on memoize is missing). I do guess that we'll get a video of this year's talk, too. Here, I'll only highlight a few things.

Plone is pretty efficient. It just does a lot, like checking for authentication and finding all resources that are needed, creating the dynamic navigation, grabbing the right CSS bits. Most of these things cannot be made really faster. So the basic strategy is not to make plone faster, but to make plone do less. The everything-is-fresh default setting of Plone is the right choice, of course, as it would otherwise not meet your expectations and it would lead to loads of bugreports.

Sweet spot for performance: 2 zope threads at a time (instead of the default of 4).

Use zeo ALL THE TIME. Also on development boxes.

Especially on linux, default hardware parameters are often very conservative. hdparm for instance. Linux distributions are conservative as they want to run on all hardware. There's some serious opportunity for improvements here.

Think about caching right at the start when coding. Add a few ramcaches with obvious names (cache_per_user_for_5_minutes) and set the cache time to 0 seconds during development. RAMcaches: they gave discover magazine a 20-fold increase, which was more than they got out of cachefu and squid.

Question: aren't RAMcaches slowly going away? All those browser views? Python scripts shouldn't be used anymore. Answer: Joel loves python scripts. It was only recently that the new view classes and so were cachable with memoize. Before that, ramcached python scripts out-performed browser views by order of magnitudes. And ramcache have excellent security.

Memoize: new caching mechanism for zope3. Works great, completely tweakable. Drawback: not tweakable by the customizer/integrator. He expects that to change, though.

Useful strategy: focus on the tiny: microcaching is very helpful. 5 seconds to 5 minutes is often unlikely to be noticed. It can reduce work with 500x.

Plone can be made really fast. With ramcache, memoize, cachefu and apache/squid/varnish in front, it can be blazingly fast. (Reinout: That's also my own experience: you can make Plone a helluvalot faster). Cachefu is in need of more developers and especially documentation writers. Plone's caching story needs to get more well-known. Joel especially asked for more bloggers :-)

Technorati tag: ploneconf2007

There's a need in many institutes to share knowledge. For instance a project made by them that consists of some 100 plone websites that have to exchange documents and so about cultural heritage in Campania. Not all documents have the same document schema, so a common semantic web document model was made to share it all.

They've got a nifty system with which you can extend, content-based, content types with extra fields. Of course, you need zope3 technologies to pull it off. This makes for a very flexible system. The definition of the new content types is done with a small custom-made XML format, btw. Storage can also be specified (images on the filesystem, fields in postgresql, for inststance). They have a tool that can additionally convert the XML format to archetypes schemas.

Advantage of the component model: clear separation between data logic and the other layers.

Information is exchanged in XML. With adapters, you can export documents in various XML formats. A special contenttype called RemoteContent is a link to a remote document; the octapy semantic mechanism takes care of extracting the information and displaying it locally. With an RDF export, the basic data about a contenttype can be communicated in a structured way (with some rdf:subClassOf, rdf:label, etc.).

One question was whether they used RDF and semantic querying to discover/find content. The answer was that they had a lot of different document types. And to catch all those in a semantically meaningful taxonomy is hard. Searching also costs a lot of time. They're trying to get something working, though.

Technorati tag: ploneconf2007

Core question: do you want to be a recipient of other people's software or do you want to be a participant in the creation of the software that you use? In the first case, you'll be wrung out like a cow for milk for a better sales bonus for the salesman. In the second case, you're not consuming someone else's crap, you're participating and consuming your own crap :-)

Paul is part of a company with fellow grey-zope-beards Chris McDonough and Tres Seaver. One thing to read is Chris' lifestyle incorporated, see if it matches what you're thinking yourself.

The people behind Plone is what matters. Plone is a democracy. There's a mechanism, a process, in place for planning releases and what goes into it. "PLIP", plone improvement proposals. It is pretty through and works well. Much of the general coordination takes place electronically on irc and on mailing lists. Sprint meetings take care of the in-person contact and the personal cohesion.

Plone is extremely entrepreneur-driven. Small businesses that cannot get plone developers fast enough. Small businesses that are more entrepreneur-like than the big commercial companies.

A core challenge: mechanisms versus policy. Plone is getting big, do the existing mechanisms still work? One of the recent things that was tried was the framework team, which looks at the PLIPs' quality. (Paul asked who wanted Martin to continue as framework team lead; loads of hands went up; Paul's next sheet was, again, "plone is democracy"; and so Martin was suckered into being the framework team lead one more time).

The plone foundation's goal is to protect and to promote Plone. The goal is not to actually develop Plone: the community was doing fine as-is. The Plone foundation was started with seed money from Computer Associates. Stuff like trademark registration, code ownership, domain news, contributor agreement. The Plone market was estimated to be some 200 milion $ by someone a year ago. With so much money going around, you need a level playing field where someone cannot do dirty google tricks with plone domain names.

Plone looks a lot like us. We are Plone. And we get to kick the ass of big commercial CMS companies. And we have fun and purpose in doing the things we do. A purpose-driven community. Plone isn't software, it is the result of software. Plone is democracy, which is the worst form of government except for all the others. And it is said you normally get the type of government that you deserve. Well, we get the plone that we deserve :-)

Technorati tag: ploneconf2007

How to deal with integration for a large-scale website. Zest software (8 persons) made the intranet website for the 6000-person research department of Philips . Some of the biggest challenges had to do with the performance of the sites, the desired reliability of the service and especially the project management.

The site has only logged-in users and a few thousand actually log in every day. This is different from most of the plone sites, where you have a large majority of anonymous users. The users are authenticated against a 200000 user LDAP database. Plone's ldap story at that time still needed some work and manual patching. We made a small product that took care of all ldap configuration and patching. Wiggy recently released a new plone ldap product that does basically the same thing, only better, nicer and with a handy UI :-)

Single-sign-on (SSO) is handled by apache (set up by Philips itself with mod_nltm). Apache passes along a variable in the request with the username in it. We created apachepas that grabs the variable and tells PAS that it is that user.

The homepage was made with compositepack, which we cleaned up somewhat for ploen 2.5. Now the customer himself can modify the homepage layout.

Important was location dependency. Philips research has 7 lab locations (Eindhoven, Aachen, etc.). Content can be restricted to one or more of those locations so that users are not overwhelmed with unneeded information that is not relevant to their work location. Daniel Nouri made pluggablecatalog for us, which took care of transparently filtering all catalog query results. In our case, the filtering was done on the present user's location setting. This meant we didn't have to customize a lot of plone templates, everything was handled transparantly by the catalog.

Performance. Performance. Performance. Caching. When switching on the new website, we had to switch it right back to the old one within 30 minutes. It just wasn't able to cope. One of the things we improved was dropping some personalization, for instance by not showing the current user's name on the homepage. This way, you can vary the page based on the roles of the user instead of individually logged in users. This helped a lot compared to the default cachefu rules. (Also we added more zeo clients, did generic cachefu work, figured out an error in the apache single-sign-on setup, provided more detailed caching of page elements, etc.)

Feedfeeder was created to read in atom feeds from an exisiting news server and to create them as news items in the plone site. For several usecases, we needed extra data in addition to the title, description and text: start date, meeting location. For that, we added the extra information in a special microformat inside the feed items. Feedfeeder is able to extract that and handle it because of some zope3 adapter work.

Other extra contenttypes (all in the collective svn) included "link of the day" and "quote of the day". Also handy for more generic usage: azlinks, a simple a..z listing of links.

A special problem was the migration of the existing 50 small intranet websites into the one new site. The key is to do this gradually. A so-called "migration folder" could be gradually filled with the content of the old website. The migration folder has a URL pointing at the old site and a checkbox "migrated yes/no". The migration folder is shown in the dropdown menu (the dropdown menu is the main way of navigating the site). As long it is not fully migrated, the menu item links to the old website; when the checkbox is set to "yes", the menu item links to the migration folder instead. Works like a charm.

Project management was important for such a big project. We're using extreme programming for it, chopping up the project in 2-3 week iterations. At the end of the iteration we would go to Eindhoven for a day and close the iteration and write the stories and tasks for the next iteration. This way, you get regular feedback and the customer can change the direction of the project at regular intervals. Internally, standup meetings are essential to coordinate the work and to make sure that nobody is stuck and that everybody has all the info he needs.

Very cool: we were allowed to release much of our work as generic open source packages (see some of the links to products in the text above). That's something that's to be recommended for all integrators. We got bug reports from other users that improved the products, for instance. Releasing such products also improves the plone ecosystem as a whole.

First design patterns. KSS is different to most other ajax solutions in that it says that business logic should be computed on the server. They're not shipping data to the browser to let javascript compute things there. All computation is done on the server. It is so easy to let the normal python code and the javascript code drift apart: keeping everything in python is best. An extra advantage is that KSS integrates well with the current development process. And it limits the amount of javascript. Javascript is hell and the various implementatios differ a lot. Debugging is hell.

Core of the design is kinetic stylesheets: KSS. Such KSS files define the client-side binding of site elements to javascript behaviour. This way you have a generic set of javascript that can be tested independently from whatever you want to do with it. If you hand-code all javascript functionality, you have to test every page on all browsers. The generic client-side engine allows html snippet manipulation.

Next some development patterns. First create regular html-only pages: for accessibility and cross-browser reasons. Afterwards, you bind events to the html using css 3 selections.

Intermission: firekiss is an essential extension to firebug to debug KSS files. Godefroid demo'ed it and it looked great. The download link is http://kssproject.org/downloads/firekiss.xpi .

KSS has three "command sets", of which the client side only knows one: kss.core. The core knows about removing/adding html, popping up a message box, etc. The other two sets, one for zope and one for plone, are convenience sets. reloadPortletsByInterface() for instance.

Now test patterns. First things first: do not use selenium (unless you create a new javascript plugin). Instead check the commands in a KSS response and check the resulting html elements, classes and IDs. Look at some of tests inside KSS for examples.

Technorati tag: ploneconf2007

She's involved in plinkit that provided pre-build websites for small libraries. Currently, she's mostly integrating and customizing, not programming anymore. Here are 10 tips for non-developers to get involved in plone.

10: blog about plone. How you use it; what you like; comparison to other systems that you know. Promote plone improvements: talk about improvements that you want and you might get others to chime in. Read Jon Stahl's blog as an example ([Reinout:] or mine :-)). And get listed on http://planet.plone.org .

9: contribute a theme.

8: "Adopt" a product. Assist the developer by reporting bugs or by verifying already reported bugs. Offer to write documentation! A step further: become the product owner. There are orphaned products that nobody updates the product page for. No new releases are being made. A great way to get involved.

7: Marketing. Put your site on http://plone.net . For bonus points, write it up as a case study. Or tag sites on del.icio.us with plone-site .

6: Online participation. Mailinglists, irc.

5: Local user groups. Either join one or start one. Do take care of announcing them widely, as that's often forgotten.

4: Sprints. They're not just for developers! There's been a documentation sprint, for instance. If you're not a develooper: sponsoring is really valuable.

3: Beta/release candidate releases. Download them and play with it. Especially new plone releases. Report bugs and test by migrating sites. A good way to contribute is to determine documentation needs.

2: Documentation. Use it, comment on it. And write it!

1: Report bugs. Valuable feedback to the developers. Also if you're not sure: report it anyway.

Technorati tag: ploneconf2007

One piece of news: plone solution will be renamed in JARN (updated: that's jarN, not jarL, tnx limi for mailing the correction!).

Ok. The top 5 things he gets asked css-wise, with solutions.

Tip 5: centering the design. Many fixed-width sites center the design horizontally. For this, use the #visual-portal-wrapper, give it a fixed width and a margin-rigth and margin-left of auto. That's the css way of centering it.

Tip 4: styles for different internet explorers. Plone has a special IEfixes.css file for IE-specific fixes. That's for all IE browsers, it doesn't distinguish between various versions.

If you write styles for internet explorer, target IE7 first and hack it for other IE versions afterwards. For those IE6 versions, use the * html hack.

Tip 3: styles for different sections of your site. Plone marks the body text with a section-NAMEOFSECTION class, so you can use body.section-products to create a different layout to that section of the site. Likewise with templates. You also have a class that includes the template name. body.template-frontpage_view for instance.

Don't use these to change the whole layout of your site, just change small things like background colors or images.

Tip 2: dropdown menus. The best way is the so-called suckerfish-dropdowns. Denis made a handy plone3 product for it to make it an out-of-the-box experience: webcouturier-dropdownmenu . The good thing is that it works in all modern browsers.

Tip 1: rounded corners. Designers think they have to put rounded corners everywhere. Plone has xhtml hooks in portlets and so for the corners. With some simple (but not trivial) CSS you can make them round. There's a fixed set of images for the corners, so it is inflexible.

Another solution is a combination of javascript+css. The javascript reacts on a class you've put on your portal (for instance). Very flexible and the least intrusive for your html. Cross-browser support is hard, though. A suggestion Denis made was to look at http://www.curvycorners.net/usage.php .

Here also, he's got a product for plone3. collective.roundedcorners. He's going to put it online in a few days :-)

Technorati tag: ploneconf2007

I'm off to the plone conference tomorrow morning. A wishlist item I've had for a while was to migrate my website before the start of the conference.

I finally managed: not without some difficulty. It is an old site and it went through quite a number of migrations. Some of them being non-released svn versions. But I was still amazed at the errors I got when attempting migration. I mean, if you can't even get into the ZMI...

Eventual solution: move the parts I wanted to salvage to a "to_copy" folder and make a .zexp of it and import it in a fresh plone 3.0 site. With a bit of care, as you normally need the same products at both ends of the .zexp. An intermediary 2.5 plone site solved that.

I took the opportunity to remove most of the add-on products (except linguaplone and quills), so the site is fresh! It is also missing some bits and pieces here and there (like images and some external html content), which I'll sort out at leisure after the conference :-)

Technorati tag: ploneconf2007

For the 2007 plone conference, I've just added a flickr group: http://www.flickr.com/groups/ploneconf2007/ . At the Sorrento sprint, the flickr group was big and there was a huge overlap with the tag "sorrentosprint2007". So:

• There's now a max of 3 photos per member per day on the group. Just the best ought to go in there.
• Tag the rest of your photos with "ploneconf2007" and we'll still be able to see them all.

(Mentioning it here before we end up with 5 separate groups... :-) )

Technorati tag: ploneconf2007