As a sequel to 2007's list, here's part one of my list of books I read in 2008.

History is a large part of my reading pile. Any links here are to related webpages, not to amazon, btw.

• A Distant Mirror (in Dutch: de waanzinnige 14e eeuw) by Barbara Tuchman. About the steaming pile of junk the 14th century had to deal with (first part of the 100 years war, black plague, efficiently suppressed peasant uprisings). Reads like a charm and gives you a lot of background.
• The agincourt war by Alfred Burne, bought 5 years ago in a second-hand English bookshop in Paris, followed chronologically. This is the second part of the 100 years war. The English had an effective, but relatively small, army so they won most of the clashes. Winning clashes means holding territory which means having an even smaller army. English success was tied a lot to either incompetence or in-fighting in the French royal family and the assorted nobles. In the end the French got their act together and English influence slowly came to an end in France. The book is a good read, especially as it concentrates mostly on the military affairs.
• The Dutch republic by Jonathan Israel. The rise, greatness and fall from 1477-1806 of what's now the Netherlands. This one fitted well chronologically after abovementioned agincourt war. France started to become united, which meant it became a real European force to recon with. They would give the Netherlands no small amount of grief later on. What's now Belgium and the Netherlands was under Spanish control. The economy here was booming. The Netherlands revolted, which meant 80 years of war with Spain. We didn't do too shabby. Especially economically. At the time, the Netherlands was the number one economic and financial superpower in the world. Only after the fourth war with England, did England gain the upper hand for a century. Anyway, the book is heavy reading material. I persevered. It gives a lot of background information and I found it very valuable for increasing my knowledge of Dutch history. But it is 1000 pages of heavy reading.
• Het lege land (in English: "the empty country") by Auke van der Woud. It describes the landscape, road systems, city/town/rural structure, economic climate etc. in the Netherlands from 1789 to 1848. So this book started where the previous one stopped. With just some 2 million people (now 16 million) it was indeed an empty country by current standards. The one thing that struck me most in the book was how many French laws and institutions we kept after we became independent from France again. (In the period of the French revolution and Napoleon, the Netherlands was occupied by the French for 20 years or so). Before, the NetherlandS was mostly a collection of individual provinces. In the French period and afterwards as the kingdom of the Netherlands, it was more a unified country. So borrowing some French centralized stuff was a natural move, in a way. A second surprising thing was the amount of grief they had with, ahem, global warming at that time. The 16th century is known as the small ice age, so around 1800 they noticed rising sea levels on the Dutch coast (which re-claimed some fertile ground for the sea) and ever-rising levels in the spring in the main rivers, which made floodings an almost yearly occurrence. If you can read Dutch, this is a wonderful book with lots of readable background material.

Yesterday, somehow my flash file (uploaded to plone as a regular file) wouldn't display itself. I was using the same embed and object tags as on a local filesystem test html file, so why oh why...

Some googling gave me a blog post that told me it was a recent flash 10 security feature that interacted badly with atcontenttype's default file content type. There's a easy fix that'll go into the next version of atcontenttypes.

I needed a fix Right Now, though, so I made the following quick patch. If you need it: add it as patch.py to your product and just do an import patch in your __init__.py. The patch:

  from Products.ATContentTypes.content.file import ATFile

  # This patch adds flash files as inline types.
  # See http://dev.plone.org/plone/ticket/8624
  ATFile.inlineMimetypes= ('application/msword',
                           'application/x-msexcel', # ?
                           'application/vnd.ms-excel',
                           'application/vnd.ms-powerpoint',
                           'application/pdf',
                           'application/x-shockwave-flash')

  print "PATCHED ATCT'S FILE FOR FLASH INLINE BUG"
  print "See http://dev.plone.org/plone/ticket/8624"

Normally I've got a summary ready in no time. This time around I'm a couple of days late in posting. I'm already glad I was able to type in a summary as I'm slowly (but succesfully) curing from severe back/shoulder/arm pain.

Jelmer Vernooij - how samba and openchange use python

Samba is basically a free implementation of microsoft's network and file sharing protocols. Traditionally written in C and it's extremely portable. Originally they had to resort to network analysis, but thanks to the European Union, microsoft has been forced to document it. Actually, samba testified against microsoft as virtually the only one as most companies were bought out by microsoft...

Openchange is a free implementation of the MAPI protocol that microsoft uses for outlook and exchange. Openchange builds on samba 4 (3 is the current stable version, 4 is the hopefully-released-this-year version). The next gnome version ships with a plugin for evolution.

Samba saw a need for a scripting language (read: something easier than C). They went with... javascript. Which wasn't successful (no debugger, no nice language, no exceptions, etc.).

Two years ago python was proposed. The biggest hurdle was that it wasn't sanely bundleable. It would be samba's first ever mandatory build dependency other than libc. They did it anyway, so python bindings exist for samba 4. Mainly for the administrative tools, but also some core items to make sure that the bindings are always up-to-date.

To create bindings, they looked at SWIG. In theory: very nice. portable code, bindings for multiple languages, etc. But the python bindings are very C-like and thus Not Nice.

Pyrex/Cython, a binding alternative, is very python-like. But it is an extra build dependency. And it doesn't support certain use cases.

So they did it by hand. Hand-coding it isn't too bad after all. And it is much more flexible than autogenerated bindings.

The python bindings are surprisingly popular amongst samba programmers for writing automated tests. Those are much handier and shorter in python.

Erik Groeneveld (cq2.nl) - generators and program decomposition

weightless.io is part of what he talks about. (.io is the domain of the British Indian ocean territories (someone asked)). They use it a lot for their meresco components that do a lot with networking. There's a lot of slack inside common networking components that you can take out by being intelligent about it. He was surprised about the number of requests he got out of a 6 year old laptop with it compared to apache.

An important thing: don't use threads. Weightless doesn't use threads. With bigger applications, you have relationships between the components and you have to configure them. Weightless helps you manage those relationships and the configuration of them. The configuration uses the observer pattern, something that's really easy and comfortable in python.

You can call self.any, self.all or self.do to tell your observers to do something. self.all() uses a generator.

Erik explained Jackson pipelines. A 30 year old problem about reading data from tape (that didn't fit in memory), doing something with it and writing it back to another tape. This is exactly the problem we can have today with web frameworks and loads of data. Interesting stuff.

Generalized generators, the needed basis for so-called coroutines, was introduced in python 2.5 (see pep 342). "yield" is used in generators to return data incrementally. With the 2.5 functionality, you can also pass data back to the generator when calling the next item by passing the data in your next() call. What Erik did builds on that: it means that you can yield a second iterator from inside the first iterator. Erik wrote a helper method to deal with that which "flattens" the nested yields. yield something_that_also_yields() returns not the second set of generated elements, but only the generator object. Erik's method (compose()) makes it yield the elements instead of the generator.

At the end he explained a traceback trick that he did by using the (apparently abandoned) "tbtools" packages. Neat.

They use it in live production code. The cool thing is that your entire component becomes one big generator that you can connect to a (network) socket on both ends. All without the headaches of threads.

Lightning talks

Christoper Butcher, Speech recognition extension library. Speech recognition: you say something and the computer does something. Dragonfly is a python app that takes care of creating grammars for exiting speech recognition programs and executing commands based on their output. So steer your programs with speech by defining everything in python.

Guido Wesdorp, functional testing of AJAX webapps. He's working on a quite complex xml editor written in javascript. Javascript is notoriously difficult to test. He wanted to do functional testing of javascript from the commandline. Part of what he used was the python-spidermonkey library. He builds a "fake" browser environment (window, document, dom) in javascript. Stuff that cannot be done in javascript is shipped to python for processing and then returned to javascript. It is not complete yet. He hopes to be able to support/mimick different browser versions. That's a lot of work, though. He needs to get a community in place. The demonstration worked.

Remco Wendt, 1 minute python tricks. Recently introduced any() and all() to return True if any or all elements in a list match a condition. 'from collections import defaultdict': defaultdict allows you to create a dictionary with one specific default value for non-existing keys.

Matthijs Kadijk, experiences with Google App engine and Django. Google app engine is easy to get started. You can develop an application and google will host it. They'll scale it up or down own on demand, so it works even if you're slashdotted. The app engine uses django by default. A tip: restart your application if strange errors occur. Advantages of google app engine: it is free, it is python (though he is a ruby on rails developer), it is google. Disadvantages: it is free (they can't pay for extra bandwidth), it is python (...), it doesn't use sql (but some google-internal datastore). For the slides, see http://tng.blogspot.com .

Wichert Akkerman, WSGI and repoze. Zope2 is a big framework. Zope3 is a complete refactoring, but it is still a big pile of libraries. In the meantime, a lot of smaller python web frameworks sprang up. WSGI is a standard way to talk to most of them and to tie bits and pieces of them together. WSGI allows you to tie pipelines to an incoming web request (sets of components making up the pipeline get to process the request one after the other, all the way up to the actual end-application and then the request goes all the way back). Repoze makes zope3's components available to your WSGI pipelines. All the good stuff that zope3 provides is now available in handy bits and pieces for your custom WSGI applications. For instance: zope's transaction machinery to do safe database transactions on the web request's boundaries. So: the power of zope for your own small web framework!

The last four years or so have been virtually only Plone for me. This last week I've been using Django for a customer project: a small project with no CMS functionality whatsoever. Just some authentication, some storage of data in sql and showing the data. My colleague had previous django experience and knew about a couple of django add-ons that we could re-use to get 50% of the functionality done for free, otherwise we would have probably tried our hand at Grok (which I can't wait to do a real project with!).

Here are some random comments about my first week of Django.

• Light-weight. That's really something completely different from the towering stack that is Plone. Change a .py file and django will just restart itself. It can do that as it just takes one or two seconds to reload. Real quick development that way.
• Simple customization mechanism, especially for templates. Basically what Plone had with the portal skins. With two differences that make it a bit more maintainable. (a) by convention, every add-on stores its templates in a subdirectory named after itself. So that does away with many name clashes and the one-global-namespace problem Plone had. Just a simple convention. (b) There's a list of template directories in the global config file. That's the order of directories in which Django searches for templates. I'd say that feels much more practical than anything that plone has right now. Genericsetup's skins.xml tries to make it configurable what the order of skin layers is, but you can stack them. And the order in which the various skins.xml files are executed matters. Unless you take it all into your own hand and do it in code. And don't get me started on the amount of effort needed to override a hardcoded template name that is called directly by some plone app's python code.
• Plone is much more out-of-the-box usable. That's a big advantage. And it is a quite specific kind of box with quite specific functionality. If that's not completely what you need, you need to modify the box. Django lets you start with nothing, but that also means you, well, start with nothing. If you need basic CMS functionality for your project with user login, common contenttypes, a ready-made UI and some workflow: take Plone.
• There's a field where plone (and zope3) play much nicer with the rest of the python world: easy_install. The 1.0 Django release isn't really on pypi. Lots of other stuff also isn't. I've basically given up using easy_install and eggs for this project. Which feels old-fashioned.
• By reading some Django documents and viewing some videos from the september django conference, I've noticed that in many ways Zope3 and Plone are actually closer to the rest of the python community than Django. Pypi is overflowing with plone, zope3, grok, buildout and generic eggs. If "we" need sql integration, we take sqlalchemy: Django has its own object-relational mapper that isn't used outside of Django.
• I've had fun last week. Closer to the bare metal. More python. (This doesn't mean I don't have fun while doing elaborate Plone projects! It just means that I also had fun with Django.)

James Tauber writes on how I view blogging . A good reason to introspect my own blogging routine a bit. I'll use James' points to give it a bit of structure.

• Blog to contribute to your tribe. Most of my blog posts in recent years have been on Python and especially Plone. That's really, as James says, a good way of contributing to the (Plone) community by sharing knowledge. And, yes, I heard the phrase "ah! you're the Reinout who writes that plone blog" at the last two Dutch plone user group meerings. But there's also a definitive contributution to the company I work for as blogging gets me into a habit of writing things down. If I overcome a certain Plone problem, I often blog about it. And a copy of that blog post goes directly into our internal guidelines document directory. So that everyone else sees it (and improves it). The same with my brother's blog who also works for Zest.
• Planetary effects. Yeah, being on planet plone gives you a lot of exposure. There's so much distilled knowledge to be gained by reading planet plone. Following all the relevant mailinglists can be a chore. Keeping up-to-date with planet plone is much more doable. The posts that get me the most comments are those who are practical for your day-to-day plone work (like posts on buildout, agile estimation, firefox addons).
• Why I blog. I have no idea why I started. I like writing and I'm comfortable doing it. I'm an introvert, but somehow I like this extrovert activity. Quite important to me: I use my skills this way. I'm good at writing and summarizing. If you have skills, use them. For instance conference blogging which I've been doing since 2003 .
• How I view blogging as reader. Knowledge gathering. From lots of different angles. From non-mainstream angles. Diversity.
• How I view blogging as writer**. Sharing knowledge freely. See some thoughts from 2004 . Freely you have received: freely give.

Wow, great progressive rock concert by Neal Morse last night in Zoetermeer. For a quick impression (of the type of music and of Neal Morse) I'd look at the youtube trailer of the new dvd . A couple of comments:

• Man, it looked like a plone conference. At least 3, possibly 4 Apple laptops on stage. And one behind the mixer table. Gotta give Apple credit for having a translucent white apple on the back side (and thus the audience-facing side) of the display :-)

• I got an email from a friend asking "what have you done to end up in the credits of the last CD?". I thought he was joking, but my name's really in there. Two photos were used in the special edition CD's booklet. That's the benefit you get from putting photos on flickr.com with a creative commonse attribution license .
• Elisa Krijgsman was last night's guitarist. Some simple chords on an accoustic guitar is all I manage. But I got asked by the pianist to help him with a youth service in church tonight. And two of the songs we'll sing are written by... Elisa Krijgsman. I like coincidences :-)
• I watched the "making of the DVD" section of the last live DVD. I was struck with the way Neal talks about his faith, practices his faith, lives his faith. It got me thinking. I take my faith seriously, but there's whole levels of seriousness I haven't taken yet. Especially time-wise, I've got to get more consistent.

Anyway, great concert!

Last week I added two extra options to the infrae.subversion buildout recipe. Update 2008-10-31: included in the current 1.4 release . First the small one, then the biggie:

• location allows you to set the target directory. So instead of BUILDOUT/parts/productcheckouts you can get BUILDOUT/our_products.
• as_eggs: add an as_eggs = true option to your infrae.subversion part and the checked out directories will get installed as development eggs. Woohoo!

We like to keep the configuration mostly in buildout, so one of the last things left was the BUILDOUT/src directory with its svn:externals. In the new situation, we use infrae.subversion for that:

 [buildout]
 ...

 [ourpackages]
 recipe = infrae.subversion
 urls = 
     https://svn......my.product/trunk my.product
     https://svn......my.theme/trunk my.theme
 location = src
 as_eggs = true

 [instance]
 ...
 eggs = 
     ${buildout:eggs}
     ${plone:eggs}
     ${ourpackages:eggs}

You can use it to advantage in a production checkout, too. It'll be virtually the same, apart from using a tag checkout instead of a trunk checkout. An alternative to setting up your own password-protected egg store and allowing username/password downloads from buildout.

We just finished estimating a new project at Zest software. With a new method that we all liked quite a lot. It was fun :-)

The basis is of course that you chop up the project in smaller parts. We're using extreme programming, so we call them stories. A story shouldn't be too big, definitively not more than 8 days. We all got a stack of post-its with 1, 2, 3, 5 and 8+ written on them. A story is read and we all put our estimate face-down on the table.

Show the estimate. If there's a big difference, discuss the story a bit more, telling why you think it takes just a day when the rest estimates 5. Or the other way around. Then put in your face-down estimates again, uncover them and take the average.

A fun way of doing estimations. And I think you get real good estimates this way. And yes, 1, 2, 3, 5 and 8+ mean you miss the 4 and so. It forces you to make choices. Which helps (according to my feeling).

Sometimes a small thing works out nicely: clear cache button adds a button (which you can drag to firefox' main toolbar) that empties your browser cache.

Yes, it is also there in a menu of the developer toolbar. Or down a few levels in the normal menus. But having it right there in your main toolbar is elegant. And more reliable than forced reloads and so.

(Source: Ricardo mentioned it on the cachefu mailinglist).

How on earth do you ever finish a big project? Last week I read some, as he calls it, blindingly obvious advice in Mark Forster's "Do it tomorrow" book: you need to do something.

Obvious, huh? To finish a big project, do something. Actually this is the key and it is easy to forget it. Mark mentions coaching PhD students that are stuck with their thesis. "When did you last do something on your thesis?". You can imagine the answer.

I managed to finish my own 250 page PhD thesis in January 2007. Mostly by writing at least something every single day for the last year. The going is slow, but it is amazing how many pages you fill by writing 1.5 page every single day. Same with collecting and checking addresses of the people you want to send the book. It is a daunting task to do in one go, but with a couple of addresses every day you probably get it done within two weeks. Without stress.

Applicable for many problems you might have.

Websites are always part of my community service (Dutch: vrijwilligerswerk). I've got skills there. "Community service" in my case most-times translates into "christian community service". At the moment:

• www.bijbelvereniging.nl, an inherited ancient frames website that I severely dislike from a technical viewpoint. I'll fix that one up within a few months. The bijbelvereniging itself distributes free bibles to hotels, hospitals, prisons, etc.
• www.ankergemeente.nl, a spanking new plone website that I really like from a technical viewpoint. It is for my local church.

There's a new one coming up:

• www.ngk.nl, which is currently still the old website. I had a meeting last week tuesday to kick off the development of a new one. The new logo is finished and someone has already done most of the layout in wordpress . I don't know anything about wordpress yet, but lots of technically adept people are using it for their blogs and it apparently functions fine. I'll undoubtedly manage to maintain that website technically (which I have, as the initial creator leaves for Australia at the start of 2009).

At Zest software, we had some problems getting both mysql and mysql's python binding to install reliably on everyone's development machine. The problems were mostly on the mac, as mysql gets installed into different locations by the official mysql distribution, macports and fink. And on the mac, the python binding needs a patch.

One solution: fix the underlying stuff and make mysql and mysql-python a dependency that has to be handled by the OS. Alternative solution: zest.recipe.mysql . Warning: rough edges. It is not a properly documented and tested package as it originally was a quick need-to-get-something-working-now job. But I got a question in twitter about it so here's a quick piece of buildout to get you started if you want to test it:

 [buildout]
 parts =
     mysql
     ...

 [mysql]
 recipe = zest.recipe.mysql
 mysql-url = http://downloads.mysql.com/archives/mysql-5.0/mysql-5.0.51a.tar.gz
 mysql-python-url = 
   http://switch.dl.sourceforge.net/sourceforge/mysql-python/MySQL-python-1.2.2.tar.gz 

 [plone]
 ...
 eggs =
     ...
     ${mysql:eggs}

• This ought to download and install mysql and mysql-python.
• Mysql and mysql-python end up in .../parts/mysql.
• mysql-python is installed as a development egg by buildout.
• The socket and the database are in .../var/mysql.
• No documentation, no tests. Did I warn already? We use it on the development machines, not on the server of course.
• Handy anyway for people with the same problem or looking for similar solutions to like problems.

Got a question in #plone about estimation in our extreme programming project management tool. Time for some quick pointers.

Extreme programming makes a difference between stories and tasks. A story is something the customer wants in language that the customer understands. Something like "migrate squishdot weblog to quills". Tasks are the specific programmer tasks that need to be done.

• Before starting an iteration (which lasts 1-3 weeks), make a rough estimate of all the stories in that iteration. Don't go down to the hour level, just estimate them in days. It is a rough estimate, after all. After a while you get pretty good at estimating. Preferably do it with two people, to make sure you don't severely underestimate a story that could turn out to be much more tricky than you yourself suspected.
• At the start of the iteration, you add tasks to the stories. This time, you go down to the hour level. "Fixing that bug takes 3 hours, adding an extra browserview ought to be just half an hour". You probably end up with a total number of hours that pretty much matches the story's rough estimate. From now on, the rough estimate is essentially uninteresting: the more detailed estimate in hours takes over.
• If you need to give a rough estimate for a whole project, for instance because you want to put in a bid for a project, I like the following approach that I had to do recently. Make a list of things you suppose that need doing. Take an existing list if possible. Migration projects could list all existing installed products. Or take the customer's document where he explains the request. Then do the same rough estimate exercise. They'll probably be even rougher than on the story level, but that's ok. Don't get too optimistic, put in some padding. For each of those estimates, also write down a risk estimate on a 1-5 scale. It is an extra safeguard when reviewing your estimates afterwards. An update of the plone version from 3.1 to 3.2 could be "risk 2", while a move from an external oracle database to a mysql database could be "risk 5". Watch out with those high-risk items and possibly add extra padding for them.

A good extra trick is to make two estimates. We got a detailed bid request and estimated the individual bid items. To make sure we didn't miss anything, we also wrote down the rough technical things that needed doing, including estimates. We multiplied with 1.5 for admin, testing, release management and so. And ended up with a mostly similar estimate (41 against 45). Things like that improve your confidence in your estimates.

For the second time in a few weeks I've been bitten by a UnicodeDecodeError in a collection (or smart folder or topic):

   Module Products.PluginIndexes.common.UnIndex, line 393, in _apply_index
 UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)

The error occurred to me in the following case:

• A catalog index (like some custom "organization" FieldIndex) contains both string and unicode values. So both "zest software" and u"Universit\xe9 de Paris".
• You have a criteria where you select that Université de Paris.
• You view the collection... boom!

In my case, I parsed an xml file and the parser returned everything perfectly as unicode. Afterward, I did some string processing on it, like organizations = orgfield.split(",") to split some string on commas. The result is, surprisingly, a mix of normal strings (the entries containing only ascii characters) and unicode (the university with the accented character).

The solution was to do an organization = organization.encode("utf-8") before giving it to plone.

This is the first time I'm posting an actual sermon here on my weblog. Last sunday's sermon (in Nieuwegein by Smelik) was full of sane reflection and practical advice, also quite readable I guess for the non-christians in the audience :-) Those with a bible might want to take a quick peek at Ecclesiastes 11:1-6 (Dutch: Spreuken 11:1-6). Any numbers below point to those verses.

Ecclesiastes, according to wikipedia emphatically proclaims all the actions of man to be inherently "vain", "futile", "empty", "meaningless", "temporary", "transitory", or "fleeting," depending on translation. There's so much in peoples' lives that suddenly pops after putting in a lot of effort. And to top it off: at the end you die, so how much use is there in your effort? Perhaps surprisingly, the second conclusion is "so make sure you enjoy yourself and enjoy life". Dare to live!

• (1) "Throw your bread in the water". Bread in this case means your living. Dare to invest. Invest money that you cannot really miss. Invest precious time in your children. You actually don't know if you get a return on your investment. Stocks can plummet; children can go off on bad ways.
• (2) "Divide it in 7 or 8". Spead your risk. In ye olde times you could store your grain in more than one granery. Store it in 7 or even 8 different ones: if one burns down, you still have the rest. Nowadays you could put your savings into separate accounts on different banks. There is a lot you cannot forsee or predict. Also there's absolutely no certainty that the good will do well and the bad will do bad. Ecclesiastes sees those facts.
• (3/4) Life is unpredictable. But don't let that stop you from living your life. And don't let that stop you from taking on tasks or starting new initiatives.
• (5) "You don't know tomorrow's weather or how a baby grows". Well, actually, we do know a lot about tomorrow's weather and about how babies grow in a mother's womb. But there's still a lot of detail and essence that we miss. And God also is an unknown factor (in case you factor Him in).
• (6) Well, actually, a lot of it is none of our business. Or none of our concern. So work! Do something. And don't restrict the doing and the working to those cases where you're sure of the outcome. Make a bold move and do something even if you're unsure of the outcome. Dare to live!

Jesus gave his life for people. That's quite the ultimate investment in others! Christians believe that even that deadly investment payed off: He got his investement money (=His life) back after three days and a Huge Whopping Interest on top of it: enough to pay for everyone's sins (on the provision that you accept that payment).

There's a saying in the bible that "those who wish to retain their life shall lose it and those that give it away shall keep it". Dare to live. Take some risk. "Know that your efforts are not in vain".

My colleague Mark van Lent is live blogging the plone conference 2008 . As he's not on http://planet.plone.org, this is easy to miss. So I'm mentioning it here :-)

Recommended!

Yeah, Jens is right . I'm so used to calling the breadcrumb navigation, well, breadcrumb navigation. I never paid attention to it. But of course Hans and Gretel's (Hans en Grietje in Dutch) breadcrumbs were eaten by birds so they couldn't find their way home. Poof goes the metaphore :-)

Three posts till now struck a chord in me regarding the current financial crisis. In increasing order of "we're screwed"-ness...

Tim Oren has a link to a great powerpoint by Tom Maguire that explains the whole mess. Two quotes from his own article:

If we get nothing else from this, we're going to have several decades supply of Econ 101 and 201 cases for perverse incentives, moral hazard, regulatory capture.

Since extensions of credit are de facto expansions of the money supply, we need to keep in mind that deleveraging the $11 trillion or so mortgage market [...] could have a notable deflationary monetary effect.

What happened to right and wrong is what L.E. Modesitt (my favourite writer) asks himself. And he's right. How on earth can a person sell mortgages that people cannot reasonably repay? Which morally depraved well-paid executive allows what amounts to fraud? (Probably the one that gets paid handsome bonuses when short-term successful and that gets paid handsome severance packages when unsuccessful). Two quotes:

Didn't anyone of importance say, "These kinds of mortgages are wrong."? "These appraisals are inflated."? Didn't any executive observe that the leverage requirements were so far out of line with banking and securities reserve requirements that they were in effect dangerous and fraudulent? Didn't any brokerage firm or executive crack down on naked short-selling?

So far as I can tell, none, or very few, did. Instead, they followed the "business model" of "the highest level of short-term profit possible by any means allowable under the law."

And for the jackpot: onwards to a hollow state by John Robb. One of his main topics is failing states. 10 years ago, Iraq was a state. Now what is left of central government is just a hollow shell. Pakistan could soon follow. Oh, and maybe something like the United States of America is next. A shift from still-functioning to already-failed can trigger quickly when there is a financial crisis. A quote on one of the common things you can observe in such a scenario:

Corporations and connected individuals systematically loot the nation-state of financial assets and natural resources through a series of insider/no cost deals. These deals are made to "save" the nation's economy or financial system from collapse.

It's instructive to view the US Treasury's plans for a bail-out of the global financial system through the lens of the hollow state. By this measure, the bailout as it stands today, is a form of financial looting of the US Treasury (it isn't socialism, since the government isn't nationalizing the financial system). Trillions of dollars in government monies ($700 billion to begin with) will be infused directly into the coffers of corporations and wealthy individuals (via hedge funds). [...] The national debt will likely grow 20-30% in a single year, with obligations extended to many trillions more in guarantees.

There's apparently a chinese curse: "may you live in interesting times". Well, we do live in interesting times.

The buildout backup recipe is almost at 1.0, the last wrinkles are being ironed out. One of the things you can do before a 1.0 is to change a default, which I just did. Every single one of our buildouts had a gzip = true line in their backup recipe configuration, so the default for collective.recipe.backup is now to gzip the backups.

If you've discovered things that need changing/fixing: speak up quickly before the 1.0 comes out :-)

I totally love the test-driven development that's possible with collective.recipe.backup's test coverage. Making absolutely sure everything works is of course essential for backup scripts!

(Credits for figuring it out go to colleague Fred van Dijk.)

Subversion 1.5 (the latest one) wreaks havoc in combination with python's setuptools. Accidentally I upgraded my macports subversion by upgrading a different package. And I could not find a way do get my 1.4 back. Fred found out how to downgrade something, assuming you have an older version still around.

• sudo port installed | grep subversion

That gives you something like:

  subversion @1.4.5_0
  subversion @1.4.6_0
  subversion @1.5.0_1 (active)

• sudo port deactivate subversion @1.5.0_1
• sudo port activate subversion @1.4.6_0

Now subversion is back at trusty old 1.4.

One thing we don't know yet: how to find a list of available ports? Can you still download an older version of a port somewhere? Is there a list? Please comment if you know :-)