Yesterday, monday, was our first day in our new office after the move: yeah, great office space. Every one of us looked happy and content. I was merrily working throughout the afternoon and suddenly noticed that it was 17:45 (I had to go home at 17:00 in order to eat before people arrived)... I just didn't look at the time. I blame it on the nice building :-)

The old location started to get cramped (see last photo), so we needed the extension. Jean-Paul and Esther (=bosses) did manage to find a good office that they're rightfully mighty proud of. Three random things that I especially like:

• Two entire walls filled with whiteboards. I love whiteboards and have a big one at home. Zest's new office takes it to a new level. We immediately put the whiteboards to good use to plan out a new customer project.
• Big Window. One of the long walls is all glass. From floor to ceiling. The programmers are on the second floor: when you come up the stairs the first thing you see is a big open space and a wide view outside. Loads of light, loads of openness. Gives me a feeling I'm capable of more: more overview of projects, better architectures, less bugs, whatever :-)
• Dead next to the metro (=subway). On a day, it shaves 2x10=20 minutes off my commute compared to the old office location. If I manage to be more strict in my morning routine, this bit of margin ought to allow me to be home on a better time. I have a 1 hour 35 commute (one-way) now (was 1h45) three days a week (I work at home two days a week). So I mostly got home just when dinner was finished. Those 20 minutes might make quite a difference!

There's some work to be done on the office, of course. But the office is off to a good start, seeing everyone's enthousiasm on the first day!

The location? Right here , but it is a brand new building, so google maps doesn't have it on its satelite photo yet :-)

KSS best known for the inline editing in Plone. There's a lot more you can do with it. But most of the usage I've seen concerns modifying something. And if you modify something, you need a POST request in http land. The other request you can do, a GET request, is defined as something that you can do multiple times without changing anything. So you can press "reload" in your browser on ordinary pages just fine, but re-submitting a comment 20 times with POST results in 20 identical comments.

So KSS by default uses POST for its requests, as there's often a change involved. The downside is that POST requests aren't cacheable. So a simple KSS plugin that fetches a list of images from the server and that displays a random one from that list keeps on hitting the server. Even though that list of images changes only once a year or so.

Balasz Ree has a branch of KSS that allows GET requests. It only needs reviewing to land in KSS trunk. But we (= zest software ) needed it now, so Balasz cooked up kss.plugin.cacheability that allows GET to work in the current KSS version. It'll provide an easy migration path once the GET functionality itself has landed on trunk.

So if you have KSS requests that don't change a thing and that are expensive 'cause they're POST instead of GET: try it out!

Plone is rightfully known as a friendly community. We got some tasty proof of that at zest software this morning: we're moving our office later this week and got a congratulation cake from Goldmund, Wyldebeast & Wunderliebe, another plone company from the Netherlands. Thanks!

We've got a wonderful reason for our move: we're growing. It is getting too crowded in the office. We're staying in the same neighborhood near Rotterdam, just 200m closer to the metro. The office is about twice as big, so it ought to do for a while :-)

A couple of weeks ago I got triggered by a short article on working in project space . I've got a great project/todolist application (omnifocus) but there are days when I hardly look at it as I'm on the roll with a customer project. So I considered that a possible problem. The customer projects are managed in our extreme programming management website. No way I'm going to type over my tasks into omnifocus.

I'm now making a distinction:

• Projects that I want to work on for an extended period of time. It is   actually entirely ok to get into the flow of a customer project and spent a   full day on it. One day of focused work can make a huge difference on a   project. Getting into the flow is important.
• Loose tasks ("buy diapers") or projects that consist more of separate tasks   ("eventually I want to move my website from vanrees.org to   reinout.vanrees.org"). I can do those tasks anytime I want.

For me, omnifocus is great for the second type of tasks. I never have nothing to do if I want to do someting: just give me the list of things I want to brainstorm on or that I want to google.

An important note: maintaining the system you use for that second type of tasks is essential. Get all your commitments ("oh, I still have to ...") out of your head and put them in omnifocus/excel/paper. Only then can you really get into the project-flow, confident that you're not forgetting important things.

Part of my personal capabilities series .

A Belbin teamroles inventory (to me) is the most useful test you can do both as a team and as an individual that works in teams.

The basic summary is that, within a given group, people tend to fulfil one or more of 8 basic roles. If you miss a role in your group, you can be hampered; other roles have a one-person-only-please limit. Remember that person that always seems to end up taking charge? Are you the person that ties up the loose ends? Are you constantly spewing forth new ideas?

Each role comes with strengths and with weaknesses. I'll illustrate it by giving some personal examples. I've done the test a few times over the course of 6 years. Three times in a university setting, once just by myself on the internet and once at my current workplace Zest software .

My number one role: monitor/evaluator (Dutch: waarschuwer). Consistently the number one. In every test. And with a, for this role, ridiculous high score. I'm smart and I can analyse well. A definition of this role is "you have a capacity for shrewd judgements that take all factors into account and you seldom give bad advice". Not that I don't make mistakes, but if I really advice against something, I'm often right.

Some drawbacks that I notice in myself. I can be long winded: talking for a long time so that everybody loses my point. Critical and intelligent also equates often to distant and cold. And there's a risk of slamming an overly negative brake on creative discussions and processes.

A point about drawbacks: some drawbacks are allowed drawbacks. They're a package deal. If you want the benefits of a monitor/evaluator, you'll just have to learn to live with some of those attached drawbacks. At the same time, those drawbacks are something I want to be aware of so that I can limit their detrimental effect.

Numbers two and three: company worker/team worker (Dutch: bedrijfsman of teamwerker) and shaper (Dutch: vormer). In the earliest tests company worker was the clear number two, in the more recent ones the shaper takes that spot. I've got a story that illustrates I really have some shaper characteristics later on.

A company worker is loyal (something that's really strong in me). Perfectly willing to do nasty or menial tasks. I can translate goals or customer wishes into practical tasks. Brainstorming how to convert a goal into specific tasks is one of the things I like most.

As a company worker, the demands of practical work can make me a tad conservative. A finely honed system or work approach: don't throw it away before its time. And if I see no practical use in something, it is virtually impossible to motivate me (though loyalty goes a long way).

The second number two spot candidate: shaper. I totally do not fit the "nervous energy" and "aggressive extroverts" characteristics you often see in descriptions of this type! I do have a tendency and desire to technically structure the projects I'm working on or the processes I'm working with. Doing design work on the architecture. Writing programs/scripts that are used to manage the software. Keeping the overview, juggling tasks (and people to do them). If there are obstacles of if there is a looming deadline: I don't mind that much and I'll continue functioning, structuring and pushing myself (or others) along. A shaper is said to be one of the most effective members of a team in guaranteeing positive action.

One of the Belbin summaries I have lists the following three drawbacks that I recognize: prone to provocation, irritation and a tendency to offend others. Those are listed under the heading "allowable weaknesses" but I severely dislike them. Having a technical argument: OK. Being part of a war in a student club: OK, a long as you still can play on the same soccer team with the opponents. But offending persons: bah.

The story with the shaper-drawback that I mentioned. We did this Belbin test with a couple of PhD candidates and got split into two groups afterwards to do some task. We soon discovered that the groups were divided in the most sub-optimal way possible :-) In my group were 4 finishers: ready to do a lot of work and waiting for instructions. And I was the 5th member and my shaper role came front and center: 4 people waiting for structure and instructions. That's what they asked for and what they got. But in the feedback round afterwards I got some hefty feedback that I had given structure, but that I had also driven a 40 ton main battle tank over some quite sensitive feet. Ouch.

For projects, I can function well both as a shaper and as a company worker. In the first case, I try to maintain the overview and try to steer the process and try to have a lot of influence on the architecture. In the second case I'm a loyal team member that gets tasks done.

I got a new MacBook last week (thanks, boss !). I'm very happy with it:

• The speed, oh, the speed! The 2.5 year old powerbook pro (G4) started to show not so much its age but more especially the rightness of apple's decision to switch from power processors to intel processors. Starting/stopping zope instances is way more speedier now. Running tests too. And making an occasional movie.
• It has the 10.5 OS, Leopard. They just have to name the next one Leopard II as they've had the Panther and Tiger already... The leopard main battle tank might not be as well-known in the USA as in Europe, but everyone I've heard till now uses the German pronounciation :-) Leopard-the-OS is great, especially the improvements in spotlight. That's actually usable and useful now. I also enjoy the improvements in iMovie.
• The one thing I missed on the mac is now available in a usable form: the gimp. I mean the version at wilber loves apple . Grab a newer version of the x server that OSX uses from sourceforge (yes, the official OSX-used Xwindows version is on sourceforge); download the wilber-loves-apple package; install; be happy.
• The MacBook is noticably lighter than the old powerbook pro. And it has a better battery life (important for me as I blog a lot at conferences :-) ).

  Tags: plone, osx

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.

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.