[Product-Developers] Re: Where does it hurt?

David Glick davidglick at onenw.org
Mon May 19 01:35:50 UTC 2008


On May 18, 2008, at 5:56 PM, Dylan Jay wrote:

> Martin Aspeli wrote:
>> Hi guys,
>> Following a long discussion with Dylan Jay (buried in another  
>> thread on Devilstick terminology), I thought I'd conduct an  
>> informal poll.
>> ==> As a customiser of Plone, or as someone wanting to build  
>> bespoke components that extend Plone, what do you find most  
>> confusing?
>> I think this could fall into a few categories:
>> - Areas where there's insufficient/poor documentation, but once you  
>> learn how to do something, it's clear how to proceed.
>> - Areas where there appears to be more than one approach, and it's  
>> not clear which one to choose
>> - Areas where Plone doesn't appear to have a good way to do something
>
> I think it hurts the most when something goes wrong. I write  
> something that I think should work, it doesn't, suddenly I'm faced  
> with understand everything I'm relying on.
> Debugging is a nightmare. Perhaps I'm not using the right tools. but  
> generally I try to read the code, which with the amount of  
> indirection these days is pretty hard to read. The fact thats its  
> not obvious where the definition the code I'm after is makes it  
> harder. For instance I was trying to find the schema definitions fot  
> ATCT the other day... and thats just z2. Trying to work out how to  
> the standard templates got connected in in plone.z3cform was even  
> harder.
> I'm not 100% sure how to fix this. A tutorial on how to read code?
> The slow startup time makes this worse of course because one way to  
> try and fix things is to try different stuff and see what happens.

FWIW, here are some cases from my experience that have seemed  
particularly hard to debug.  (Not trying to whinge here; just trying  
to catalog some possible areas for improvement)...
- Python scripts, since you can't see where you're at in pdb and it's  
hard to avoid stepping through z2 security stuff.  (Why do we still  
have these in the age of utilities and browser views, anyway?)
- Anything in a Quick Installer handler, since it seems to swallow  
exceptions
- When working with utilities and adapters, figuring out why you're  
failing to look up something that you *thought* you had registered  
properly.  (but I can't think of a good generalizable way to make this  
easier)
- Any code that has an outrageous inheritance tree (e.g. Archetypes/ 
ATContentTypes stuff in particular).  I think this is the least of our  
worries though, since after a few months I had a decent sense of where  
I might look for things, and z3 techniques will make this less of an  
issue.
- This last one is more about documentation than debugging, but it's  
related.  For my first couple months of working with Plone, I tried to  
rely on api.plone.org way too much.  Then I realized that I was much  
more productive working with the actual source code and pdb.  This is  
probably not terribly surprising, nor an unreasonable expectation for  
a serious product developer.  But for someone who's just getting  
started, would it be too much to ask to have some auto-generated API  
docs that don't leave out pieces of the puzzle?  (For starters, you  
could augment the existing api.plone.org by having class docs include  
docstrings from the z3 interfaces the class is known to be  
implementing, link in doctests for a module, etc.)

I'm sure there are other places for improvement too :)  just my two  
cents.

David Glick
Project Associate
ONE/Northwest

New tools and strategies for engaging people in protecting the  
environment

http://www.onenw.org
davidglick at onenw.org
(206) 286-1235 x32

Subscribe to ONEList, our email newsletter!
Practical advice for effective online engagement
http://www.onenw.org/full_signup







More information about the Product-Developers mailing list