At 07:19 AM 6/5/2002 -0400, Simon Michael wrote:
Dan - for what it's worth, here's how my zope product learning curve went.
I probably had it easier than some - there was an existing product that was quite similar to mine - DTML Document. I copied this, changed the meta_type, and got it showing up in the ZMI etc. Then I started making modifications, tackling problems and gradually learned more about how it worked. I've kept doing that ever since.
Perfect example, Simon. How in the world do you "copy" DTML Document class? It doesn't show up in the Product Management Control Panel. Yet I know that to change its meta-type, I'm going to have to get into the Control Panel, no?
When I hit problems I would search for insights in the docs and would learn something, but never used them as my main guide (the books didn't exist then). I would also search the lists for clues (these days I would probably turn to #zope first).
I didn't have a really usable debug setup until recently (using ZEO). I would say this is a must, or failing that at least set up a comfortable way to print debug messages. When testing/debugging you end up using a complex cocktail of web browsers/code windows/editors/server control windows and you need to develop a feel for when things need refreshing, when you are really not looking at the code you thought you were because of a syntax error, etc.
I have learned that debugging is a borderline nightmare. I've read everything I can get my hands on and still it seems Zope debugging is primitive to non-existent. I'm sort of surprised that's the case given the relative maturity of the product.
It's still often frustrating, and makes me miss the relative simplicity of smalltalk, but for now I don't see any other platform providing what zope does, as well as it does.
Sigh. That's sort of where I am. I miss the power and simplicity of Smalltalk. I could even *choose* Smalltalk because I'm in complete charge of those decisions. But when the finished app has to work over the Internet, requires a remote object store, and needs to be deliverable in small enough chunks that dial-up users can use it, Smalltalk disappears as an option. I spent a LONG time looking at options before settling on Zope and I'm loath to give up on it. But programming in this environment is reminiscent of some of the labor-of-love languages and tools I used over the years that were always a bit short of commercial success and viability. The absence of an IDE for Zope makes the experience of building Zope apps so cumbersome that I feel confident much of the time that all of the time I'm saving coding because of the nice OO environment and the cool built-in ZODB is being lost in the procedural and mechanical details of getting even relatively simple product-type stuff to work. Periodically, I go into a fit of pique and I search to see if there's anything else out there I could use that would be better. There is, but not within the affordable range of my finances, system infrastructure, and time for learning. I guess I shouldn't be surprised but it is starting to make me believe that I should simply abandon the idea of creating real-world Web-based apps and services and just go back into my writing hole, leaving software development to younger, more agile and more patient minds.