Thinking in Zope

A list of (primarily php-based) open source CMS’s and web application platforms. It includes links to some php survey tools also.

A longish 5 page chapter excerpt from Ed Yourdon’s book, Death March. A death march project , for those of you don’t know, is one whose “project parameters” exceed the norm by at least 50 percent. Yourdon admits that death march projects aren’t all evil:

I’m not necessarily opposed to death march projects; I agree with my colleague Rick Zahniser that such projects can be an educational experience even if they fail. I’ve told you before, I think everyone should be on at least one of these projects. However, there are some other things that you should do at least once:

• Spend a night in jail.
• Get commode-hugging drunk
• Raise a boy
• Raise a girl
• Start your own business
• Climb Mount Fuji

This actually reminds me of Eric Raymond’s discussion of why open source programmers make better products. The freedom from time constraints makes them less likely to focus on schedules and more likely to focus on good product.

Bruce Eckel, one of my favorite programming gurus (and author of Thinking in Java, among other things) talks about python, zope and tool complexity. Complaining about Zope 2’s complexity (a complaint I share by the way), he says:

But after all this time, I don’t “Think in Zope” yet because I don’t do it all the time and there are too many conceptual hurdles to absorb if I don’t do it all the time. So while I’m sure I will not stop using Zope as an app server, I think I also need another Python-based app server running alongside which is much easier to program (possibly until Zope 3 finally appears and overwhelms me with its simplicity).

Then Eckel waxes philosophical on lowering the threshhold of complexity:

Part of what I’m trying to convey in this article is the subtle threshold beyond which a thing is just a bit too complicated to absorb into your toolbox, along with all the other tools. The subtlety is that it’s possible to use that tool, but beyond a certain vague point it’s just a little bit too hard to put down and then easily pick up again later, and for me, that’s the crux ? not whether it’s usable at all, but how easy is it to put down and pick up? If I have some fantastic wrench that requires me to consult an instruction manual every time I use it…, I’ll probably just hunt around for the plain old fixed-size wrench, ashamed that I’m not sophisticated enough to use the fancier tool. Making things effortless by lowering the complexity of accomplishment really does make a difference.

(Eckel also answers some questions about Python).

I’ve been reading Andy McKay’s book about developing with zope/plone and have been struck by the complexity of it and how ill-equipped I am for learning it. This is one of those things where you have to learn a process for creating something workable, testing it and making it go live. The actual coding part is not the hard part; the hard part is doing it in a way that doesn’t shut down the larger system (It may also help to have more experience working on a similar type of project; this is really my first kind of project like this).

My learning and technical progress continues in spurts. I can spend days or even weeks trying to figure something out, and then suddenly my mastery of something brings me technical competence to a new level. It’s a little like playing a video game where you can’t use the magic wand until you reach level 2. (The analogy of viewing this programming project like a video game iis helpful because it injects a bit of “hard fun” into the task).