[ZDP] A Parallel Intro to Zope/Python/OO for Developers

Maik Roeder roeder@berg.net
Wed, 08 Mar 2000 21:01:11 +0100


Hi Loren !

Loren Stafford wrote:
> I'm afraid there were some clouds between me and your brainstorm, so I
> didn't quite follow. Could you give some examples? 

The nice thing is that you already gave an example of what I am
thinking of yourself, as you will see further down.

> But I think I agree, in that struggling developers can at least define the
> problems they run into. Their problem definitions can at least be converted
> into a "needs author" in the ZDP. If the developer thinks he has the answer,
> then he can be the author, and the tentative document section changes status
> to "needs reviewer". If a qualified reviewer can be found, then there is
> some assurance that the documentation will be solid.

Sounds ok.

<Elaboration mode=on>

Question driven approach for Gluebook:

1. Translate the topic into a question, hypothesis or thesis
   What is the question I want to answer ?

   How can I,as an experienced programmer develop a Zope product with some
   background in programming an web, but without the background in Python
   AND Zope AND OOP and Persistent Programming  toward the goal of becoming
   a capable Zope programmer ?

   Title: "A Parallel Intro to Zope/Python/OO for Developers".

   Once you have got the question right, this makes the rest of your writing
   much easier. You have an aim which you want to reach, which is to answer
   the question.

2. Split the Question into Question parts, and bring them into an order. This
   way you are structuring your thoughts, and make it possible to work
   on the questions in parallel. (You did that already.)

   1. Zope source. Explain the structure of Zope source. At the same time
   explain (or point to) the Python documentation on modules, packages,
   namespaces, etc. (e.g. http://www.python.org/doc/current/tut/node8.html)

   2. Persistence. Start with the Python examples of persistent objects
   (there's a good discussion in Lutz, Programming Python), then develop to the
   full Zope concept of persistence. Pointers to literature and research on
   persistence.

   3. OO programming. Emphasize the special method names of Python
   (http://www.python.org/doc/current/ref/specialnames.html), then show how
   these are used by Zope to (more or less transparently) implement
   persistence. It's the less transparent parts that the newbie developer
   stumbles over.

   4. Debugging.

> What I'm not sure about is how this kind of process can result in a document
> organized enough to serve as a tutorial (or perhaps curriculum) for newbie
> developers.

The result you will get is defined in step 2 "structuring". From there you
are making divide and conquer.

3. This follows the split of the questions into subquestions
4. Split chapters level by level of complexity into subchapters
5. Answer the problem at the highest possible level.
6. Answers would guide people to write the GlueBook chapters

I see one possibility to get from the mere questions to the answers:

Everyone who has just begun learning Zope should discuss everything they
know about the topic, and try to point out what is so important about it.
Then you may get some feedback which may help you to continue thinking
in a constructive way and to bring in new ideas into your thoughts.
Then while explaining further all you have found out, you will come
to a point where you can say "Exactly here is the problem at which I
want to work" You may have to find all kind of related documents in
the process and add some links to these. 

Another possibility is brainstorming. Making associations and finding
relations can really help.

1. Brainstorming

   1. Formulate the topic
   2. List all your ideas
   3. Rate all your ideas
   4. Select the best idea

2. Questions
  
   1. Name the topic
   2. Ask 5 questions for the topic: "What ?", "Who ?", "Where ?", "Why ?", "How ?"
   3. Summarize the questions to these questions in a text

The problem is now to find out what approach we want to take, and then to 
design the right tool. 

Greetings,

Maik Röder