Wednesday, November 09, 2005

Zope 3 Project Starter

I recently posted a comment about the need for a Zope 3 structure generator that allows new users to quickly set up a working project instead of having to create a number of files and directories by hand. Well, Duncan McGreggor has just announced z3 Project Starter, which is a Python script that automatically generates a Zope 3 project structure. Good work, Duncan!

Now hoping for the other part of my wish: could something like this be part of the official Zope 3 distribution?

Thursday, November 03, 2005

Structure generation and Zope 3

Ruby on Rails has been (unfairly) criticized by some outsiders because of its use of code generation to create a project, but David Heinemeier Hansson explains that RoR, rather than generate lots of code at the start of a project, generates instead the complete structure of the project with barely a few lines of code.

He goes on to extol the virtues of what he calls structure generation, which in a way complement Rails mantra of convention instead of configuration with the corollary of convention through code instead of documentation.

Structure genaration is not anything new, of course. AppFuse is a very popular application that does just this for Java web applications. But still, I think he is right. It is much easier for a new developer to type generate model than to have to remember which files are needed and where to put each file.

Although Zope 3 does value configuration greatly (at the point of having a special language, ZCML, specifically for configuration), projects would really benefit from such an approach where initial project set up is concerned. Just look at the very helpful Benji York's Zope 3 Quick Start guide. There are several places in this document where he instructs the user to create a specific file or directory. Wouldn't it be a lot better if Zope 3 users could just type one command and have this structure generated for them?

There may be some third party scripts that do this already, but I think something like this should come with the core framework. It's not that Rails is so much better than every other web app framework (it isn't), but these little touches go a long way in reinforcing this perception with many developers.

Wednesday, November 02, 2005

Top ten things I hate about maintaining old Zope sites

Just to let off some steam from my almost exploding head, I have created the following list of Zope anti-patterns. The sad thing is that I have found lots of sites that have seven or more of these problems. Maybe I have incredibly bad luck finding these maintenance jobs or maybe this is the result of many Zope programmers getting stuck at the half point of the famed z-shaped learning curve and sticking to what worked for them from the beginning. Either way, it's not pretty.

  1. 800 line long python scripts that clearly should be products.
  2. Except clauses without defined exceptions in Python scripts. This is not just a Zope thing, but try finding an error in any of a dozen participating python scripts when all of them use this mechanism.
  3. Scripts that loop over the results of an object manager's objectValues comparing object properties to some other value to find matching objects. This is amazingly slow when the folder has many items. Why do so many Zope developers seem to be unaware of ZCatalogs?
  4. DTML Spaghetti code. Just try understanding a page with a bunch of nested dtml-if/dtml-else statements.
  5. One thousand ZPT pages that each repeat all headers, javascript menus and presentation tags. What should be the very simple task of modifying, for example, the company name, becomes an arduous chore. What is so complicated about define-macro and use-macro?
  6. Having one single ZSQL Method named generic_query or sql or some other name handle all SQL calls. The content of this method: <dtml-var query>.
  7. ZPT pages that have more python code than XHTML tags. Business logic should be in Python scripts.
  8. Folders littered with dozens of objects named copy_of_xxx or xxx.OLD and similar names which indicate the objects where copied to test some change or something of the sort and then never erased afterwards.
  9. All those damn .zexp files that need to be passed back and forth when the whole site is contained in a folder in the ZODB.
  10. Relative links that do not take acquisition into account, leading to URLs in the location field of the browser that look like:

Tuesday, November 01, 2005

The day Kildall took flying

Maybe you have heard that story about the IBM PC and how IBM wanted to use CP/M, an operating system created by Gary Kildall, as the operating system for their new personal computer back in 1980. The story goes that Kildall wasn't there when IBM's people arrived to meet him, because he was off flying a plane. The IBM people then turned to Bill Gates and gave Microsoft the deal that would make this company the ruler of the PC world and Gates the richest man on earth. Microsoft didn't even have an OS at this time, so they hastily bought QDOS from some other Seattle developer (Tim Patterson), turned it into Microsoft DOS and proceeded to make history.

It's a really good story, imagine losing all that fame and fortune just because you were not there when opportunity (literally) knocked. The only problem with this story is that it is not true. Gates was actually the first man IBM went to when they started looking for their OS, and he referred them to Kildall. Only when negotiations with Kildall stalled did IBM look to Microsoft again and the idea to buy QDOS surged. Also, the deal itself was not as definitive for Microsoft's success as people seem to think. It took many strategic moves by Gates and many blunders from the likes of IBM and Apple for Microsoft to position itself as the total leader of the industry.

I had read about the real story before, but this weekend I read it again in a more detailed and interesting account in the book In search of stupidity: over 20 years of high tech marketing disasters, by Merrill R. Chapman (published by Apress).

One of the claims of this book is that Microsoft has kept its place at the top mainly because they haven't made a really stupid mistake in all these years. If you think the talking paper clip, the Microsoft Network, ignoring the Internet for a long time, or [insert your favorite Microsoft blunder here] were very stupid moves, wait until you read the amazingly stupid mistakes made by companies like Micropro (Wordstar), Ashton-Tate (Dbase) and IBM, to name a few.

This is a book I heartily recommend. It's funny, well written and touches on subjects that are of interest to developers and computer lovers in general.