Two blog posts that outline what we're doing now:

• Splitting the buildout two ways about having stable/unstable.cfg for product configuration and devel/preview/production for server/instance configuration. Preview.cfg and production.cfg both extend stable.cfg; devel.cfg extends unstable.cfg. This keeps concerns separate.
• My brother Maurits' entry on creating repeatable buildouts which was mostly about pinning eggs in versions and how to do that reliably.

I was bothered by the long list of pinned versions in our buildout's [versions] part. Which are versions we picked ourselves and which are "just" currently used versions? To make the difference easier to spot, all you have to do is to make a small subdivision with comments. A quick "diff" will tell you what the difference between development and production is when you do that. Note that we've also started to pin versions in development.

In the unstable/development configuration:

 [versions]
 # Pin versions that we want to pin to a specific version
 SQLAlchemy = 0.4.5
 plone.recipe.plone = 3.1.1
 # Not specifically pinned versions.
 # List compiled 2008-07-07 by Reinout.
 # Remove this list and run buildout with '-n', afterwards run:
 # bin/buildout -vvvvv |sed -ne 's/^Picked: //p' | sort | uniq
 Products.CMFSquidTool = 1.5
 Products.CacheSetup = 1.2
 Products.PageCacheManager = 1.2
 Products.PolicyHTTPCacheManager = 1.2
 .....

In the stable configuration:

 [versions]
 # Current version numbers of our own products
 ren.app = 0.8
 ren.model = 0.8
 ren.theme = 0.8
 # Copied from the current unstable.cfg: specific pins.
 SQLAlchemy = 0.4.5
 plone.recipe.plone = 3.1.1
 # Copied from unstable.cfg: buildout-generated list.
 Products.CMFSquidTool = 1.5
 Products.CacheSetup = 1.2
 Products.PageCacheManager = 1.2
 Products.PolicyHTTPCacheManager = 1.2
 ...

This way, it is easy to spot what has to be copied where and which items you have to update yourself. In case you develop with the latest versions and only want to pin it in production, unstable/development would be just:

 [versions]
 # Pin versions that we want to pin to a specific version
 SQLAlchemy = 0.4.5
 plone.recipe.plone = 3.1.1

and stable/production:

 [versions]
 # Current version numbers of our own products
 ren.app = 0.8
 ren.model = 0.8
 ren.theme = 0.8
 # Copied from the current unstable.cfg: specific pins.
 SQLAlchemy = 0.4.5
 plone.recipe.plone = 3.1.1
 # Not specifically pinned versions.
 # Generate pin list by running the following command in development:
 # bin/buildout -vvvvv |sed -ne 's/^Picked: //p' | sort | uniq
 Products.CMFSquidTool = 1.5
 Products.CacheSetup = 1.2
 Products.PageCacheManager = 1.2
 Products.PolicyHTTPCacheManager = 1.2
 .....

I hope this gives some ideas to adapt it to your own situation!

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 :-)

bin/repozo is a zope script to make backups of your Data.fs. Looking up the settings can be a chore. And you have to pick a directory where to put the backups. collective.recipe.backup provides sensible defaults for your common backup tasks. Making backups a piece of cake is important!

• bin/backup makes a backup.
• bin/restore restores the latest backup.
• bin/snapshotbackup makes a full backup, separate from the regular backups. Handy for copying the current production database to your laptop or right before a big change in the site.

Just read the pypi page, especially the section on supported options, though you get perfectly decent backups by adding backup to your buildout's parts list and adding the following two lines:

  [backup]
  recipe = collective.recipe.backup

That's it!

Don't ask your technically educated husband (that is: me) to do that. Some people honestly don't believe there's such a thing as "overengineering". I took a solid piece of rope; attached three smaller cords to it; attached a short cocktail stick to the end; drilled nice round holes in a couple of cakes (with an apple drill); looped the cocktail stick through it.

The good thing is that we can reuse this every year. The other good thing is that I had fun.

As a first-year student at Delft University, I joined a student club . Feburary was the month in which the club's birthday was celebrated. One of the activities was a simple debating contest which I participated in. The first round was at the club itself, with just 15 people around or so, so that didn't scare me.

What did scare me was the second round: at the theater evening with some 80 people present, right dead smack center on the stage. That prospect scared me.

When I came on stage, they put the main spotlight on me and my opponent. The result: you were blinded and couldn't see the audience. Only the bright light. So I could concentrate on the debating contest. No fear as you couldn't see the audience anyway. So I noticed I could speak for 80 people without being eaten or getting shot at.

The realisation that I talked center-stage in front of 80 people helped me a lot. The number of people never bothered me anymore after that. A valuable life experience!

I'm naturally introvert: all the basics to be afraid. But my fear of spotlights was cured by spotlights :-)

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!

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 :-)

When starting up, all those translation files are loaded and information about them is stored in the zodb. That takes time and memory. A recent PTS release (at least included in plone 3.1.1) added a nifty trick to reduce that footprint in case you don't need those languages: a PTS_LANGUAGES=en,nl environment variable would make PTS use on the Dutch and English.

In case you use buildout, add the following to your instance part:

 [instance]
 recipe = plone.recipe.zope2instance
 ...
 environment-vars =
     PTS_LANGUAGES en, nl

I just discovered it in some mailinglist message last week and tried it out today. Great little feature. (Note that it seemed to want a comma AND a space when I tested it locally, might be a bug).

De discussie werd geleid door Anton Schippers van Kraan bouwcomputing . Hij had drie stellingen voorbereid waar een panel en de zaal op konden reageren

• Standaardisatie moet afgedwongen worden. Dat is de enige manier om ict toepassingen massaal doorgang te laten vinden in de bouw.
• Over twee jaar kan niemand in de sector meer om het BIM (bouw informatie model) heen.
• Veel bouwondernemingen hebben korte termijn strategiën. Er zijn dus geen noodzakelijke lange termijn investeringen in ict. Dat is funest voor innovatie door middel van ict.

Stelling 1: afdwingen standaardisatie

Ik maakte een opmerking over het ophakken in kleine stukken. Bestaande standaardisatieinitiatieven zijn eigenlijk allemaal groot en bouw-overkoepelend. De terminologie van de hele bouw moet erin gevangen worden. Dat krijg je toch nooit van de grond? Begin liever met kleine losse deelgebieden van de bouw en probeer het later aan elkaar te knopen. (Voordat ik het te lang maak: zie m'n proefschrift ).

Een andere probleem dat werd genoemd was wantrouwen. In de bouw wordt veel geregeld en gesjacherd: transparantie is dan niet gewenst. En als je je collega-bedrijven wantrouwt wil je ook niet dat ze bij "jouw" informatie kunnen. De informatie loopt op deze manier nooit de hele keten door.

Financiering is ook een probleem. "Maar er is toch genoeg geld in Bouwend Nederland?" "Tja, we zijn al zolang bezig... enige mogelijk is gewoon beginnen en proberen."

Er is een BIM case week geweest waar met 90 personen met BIM is gewerkt. Er ontstond vertrouwen en men begon beetje bij beetje samen te werken: ook qua ict communicatie.

ETIM is, refererende aan het ophakken in kleine stukjes, klein begonnen: met inkoopinformatie. Dat werkte en had success omdat het aantrekkelijk was. Omdat er geld mee verdiend kon worden. Belangrijk voor BIM: het moet ook gemakkelijk zijn, bijvoorbeeld voor de loodgieter. Bij Oranjewoud merkten ze dat het in de praktijk al lastig was om een website met wachtwoord voor de meest recente tekeningen gebruikt te krijgen.

Een ander probleem is dat men geen verdienmodel in de nieuwigheden ziet. De staandaard verdienpunten (uitknijpen, afdingen, enz) gaan weg zodra het transparant wordt. Eng.

Iemand kwam terecht met een bedrijfskundige kijk op de zaak: OF de ict toepassing is gewoon niet goed OF je krijgt van het goede product niet verkocht dat het goed is. In die redenatie hoor je geen enkele keer het woord standaardisatie: heeft dat er dan wel mee te maken? We keren in onszelf en komen met een oplossign waar geen behoefte aan is.

De samenvatting van Anton:

• Op deelprojecten kan je succes boeken. Goed punt om mee te beginnen.
• Vertrouwen is een belangrijke factor.
• De behoefte is er kennelijk niet direct.

Stelling 2: BIM over twee jaar onomkoombaar

Eigenlijk iedereen: nee. Voor wie is het het belangrijkste? Eigenlijk de hele bouw. Veel partijen hopen op goede data van het deel van de bouwketen dat voor hen zit (en hebben geen zin om zelf goede data aan de keten na hen te leven). Het enige dat lijkt te zorgen voor marktacceptatie is dwang van bijvoorbeeld de overheid (BIM door de USA overheid, STABU bestek door de NL overheid) of het verkopen van bouwmateriaal (zoals bij de succesvolle ETIM standaard).

Er zijn bedrijven die het nu, met bouwpartners, lekker BIM-achtig geïntegreerd doen en er 40% rendementsvoordeel uit krijgen. En langzaam wordt dat gekopieerd. Maar uiteindelijk heb je het nodig dat een grote partij het doet, niet een paar kleinere bedrijven die die 40% pakken. Concurrentie is iets waar je wakker van wordt. Ikea bouwt goedkope woningen in het Verenigd Koninkrijk: dan gaan UK aannemers echt wel even opletten.

Qua architecten moet je ze eerst allemaal van 2D naar 3D krijgen. Veel bureaus doen het trouwens al of zijn ermee bezig. Iemand uit de aannemerij zei trouwens dat hij graag standaardisatie en afspraken wilde: "steeds weer mooie paketten, maar ze sluiten niet op elkaar aan".

Anton: vroeger wilden automatiseerders niet samenwerken. Nu is het anders. Maar het zit ook op mensen vast: de wil moet er zijn.

Stelling 3: korte termijn visie, dus geen lange termijn ict investeringen

Voor veel bouwondernemers is het inderdaad zo. Veel kleine bedrijven zijn "gewoon aan het werk". Geen innovatie, zowel vakinhoudelijk als qua ict. Investeringen zijn vaak anti-cyclisch. Pas als het slecht gaat proberen ze te innoveren. Ze zijn er trouwens wel, de kleine bedrijven die innoveren. Een van de panelleden had er laatst 80 langs voor workshops.

Het zijn ook veelal juist de kleinere bedrijven die innoveren. Ze zijn van nature veel slagvaardiger.

De markt begint aan de leveranciers te zeggen dat ze het beter kunnen doen. De Rotterdamse havendienst die zaken aan de markt oplegt enzo. Er begint begrip te ontstaan dat er een mismatch is.

Het is een feit dat je tegenwoordig wat kan met BIM. Dat was 10 jaar geleden niet zo, daar moest je niet mee aankomen. Nu werkt het deels tenmiste! Onontkoombaar in twee jaar? Da's te snel, maar er begint wat te komen.

Slotopmerkingen

• Successen vieren zodat het niet te ontkennen is.
• BIM gaat er komen, maar het zullen meerdere BIMs zijn. Je kiest een leuke uit voor je project!
• BIM: leuke nieuwe uitdaging voor software bouwers.
• BIM kan sneller gaan dan we denken. Luister wel goed naar elkaar.
• Een BIM, da's gewoon de toekomst. Maar het is nog best lastig.

Maak het tastbaar, dan kan het groeien. En COMMUNICEER het.

Wow, plone.net now has a whopping 1186 sites from 255 providers. That's a lot. At the 2007 plone conference (half a year ago or so) we just got our 200th provider. So 55 more companies listed themselves. Those 1186 sites is what freaks me out, though :-) Thanks for everyone that lists their plone sites there. Prospective customers can get a real good impression of plone. For instance, sorted by provider , industry or country  . What more do you want when investigating whether to get yourself a plone website or not?

If you want to list yourself as a provider, just log in to the site with your plone.org username, read the short guidelines and submit yourself and your sites. Welcome!

Tags: plone

Boom, semi-automatic python docstring extraction failed with an import error (on Products.statusmessages, Products.Archetypes, etc.). Aha, those are not in the Products/ dir in parts/zope2/lib/python (which is linked) but in parts/plone/*. It took me quite some time, but in the end (after looking at zope's own code) I added the following near the top of my sphinx conf.py config file:

 import Products 
 # ^^^ From zope's lib/python.
 Products.__path__.append(os.path.abspath('../../parts/plone'))
 # ^^^ Relative path in my situation.

I did not know that individual modules also had a path, I only knew about sys.path. It works :-)

Tags: plone

What I noticed: sometimes those next actions are the wrong actions. After completing a few of them I noticed some actions further down the list that were actually more practical/easy/fitting to do first. I would have gotten earlier progress on my projects if I maintained them a bit better and spend more time on the order of next actions.

So: if a project lingers on your list for weeks or months: look at that first action and see if you'd rather pick another action as the next one.

Tags: gtd

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.

In that picture there's one spot of visible fire. Three meters to the side and one floor down (approximately, I don't remember the very exact floor) was where I had the meeting with the chairman of my PhD committee. And another floor down was the office of one of my supervisors. Yuck. And the office next to hers and the one next to that: both PhD colleagues that I met quite often. Yuck. It comes pretty close that way.

It was only little more than a year ago that I was inside the building for some small conference...

Update: ok, those rooms that I mentioned: that part of the building just collapsed. You can see the dangling floorplates in this photo . Update 2: and there's a video of the collapse (after 40 seconds).

Tags: bouwkunde, tudelft

If you see something like this, the cause is not in python code, but in some c library. Last week a colleague's laptop crashed because of some wrong sqlite library. I've seen it barf on a mysql lib, too.

Hard to figure out what's happening as you don't have any "nice" python traceback. If you look hard at the details provided by the osx dialog, you can often identify a likely culprit if you keep in mind that you have to look at some c library that your code interacts with (some _sqlite.so in my case). It does make you very appreciative of python as there's a whole class of programming problems that we don't have.