¡Hola! Some of us over at ZopeZen.org (<URL:http://www.zopezen.org>) have been discussing the fenomena that is called ZopePrints. I'll give a brief explanation, and would appretiate feedback as to whether this a good idea or not. A ZopePrint is a document, or maybe a set of documents, which describes a part of, or the complete development process for a Zope application. This could include the whole process from when the customers tell you they want to do project X with you, till you actually finish it and it's up and running in the customers offices. Some points may be: * Problem definition * Problem analysis * Project management (Resource allocation) * Design phase * Zope design * Test phase (Have a looksy at <URL:http://www.zopezen.org/SDot/981475769/index_html> to check out all the suggestions, and my initial post.) The rationale behind this is that the community at large would benefit from this by having _real_life_ case studies so when their time has come to implement an application in Zope, they don't fall into the same traps and pitfalls we did. Instead of benchmarks, the Zope community would use implementation documents to decide whether Zope is up for the job or not, that's what really helps. I'm quite sure that it will also work as a tool for finding gaps and holes in either Zope or its tools and Products. We would like to start a project going in the Fishbowl which aims at creating the right tools to document a project as described above. Feel free to make suggestions!
On 12 Feb 2001, Erik Enge wrote:
The rationale behind this is that the community at large would benefit from this by having _real_life_ case studies so when their time has come to implement an application in Zope, they don't fall into the same traps and pitfalls we did. Instead of benchmarks, the Zope community would use implementation documents to decide whether Zope is up for the job or not, that's what really helps.
We would love to see this description from you. We inside DC have our own problem solving development process that is large, complex, slow, but often (IMO) accurate if done well. It is based partly on the "Rational" model developed by the Three Amigos: http://www.everything2.com/index.pl?node=the%20three%20amigos&lastnode_id=12... partly on chaos theory, Jim's three laws of engineering (1. F=MA, 2. You can't solve a problem unless you know the answer, 3. You can't push a rope) and on the abundance of Thai food. We also have a "fishbowl" experiment community process, a "dogbowl" content managment design process, a documentation process, and one horse-choking travel policy. I think it would be great to get examples of your problems in a case study format, but also in a higher-level, pattern like description. Your description sounds like it is based on the problem and the goals, which is really great.
I'm quite sure that it will also work as a tool for finding gaps and holes in either Zope or its tools and Products.
Indeed.
We would like to start a project going in the Fishbowl which aims at creating the right tools to document a project as described above.
The fishbowl is the perfect place to do this. In a conversation with other people including Brian who is the "keeper of the fishbowl" we realized that documentation artifacts come out of the fishbowl almost as much as the software. In fact, that's one of the whole reasons for the fishbowl, to come up with better software because we thought about it and wrote down some words before we started hacking code. Instant documentation. Good luck! -Michel
partly on chaos theory, Jim's three laws of engineering (1. F=MA, 2. You can't solve a problem unless you know the answer, 3. You can't push a rope) and on the abundance of Thai food.
Perhaps I need more beer but whats: F=MA? -- Andy McKay. ----- Original Message ----- From: "Michel Pelletier" <michel@digicool.com> To: "Erik Enge" <erik@esol.no> Cc: <zope-dev@zope.org> Sent: Tuesday, February 13, 2001 9:46 PM Subject: Re: [Zope-dev] Introducing ZopePrints.
On 12 Feb 2001, Erik Enge wrote:
The rationale behind this is that the community at large would benefit from this by having _real_life_ case studies so when their time has come to implement an application in Zope, they don't fall into the same traps and pitfalls we did. Instead of benchmarks, the Zope community would use implementation documents to decide whether Zope is up for the job or not, that's what really helps.
We would love to see this description from you. We inside DC have our own problem solving development process that is large, complex, slow, but often (IMO) accurate if done well. It is based partly on the "Rational" model developed by the Three Amigos:
http://www.everything2.com/index.pl?node=the%20three%20amigos&lastnode_id=12 5995
partly on chaos theory, Jim's three laws of engineering (1. F=MA, 2. You can't solve a problem unless you know the answer, 3. You can't push a rope) and on the abundance of Thai food.
We also have a "fishbowl" experiment community process, a "dogbowl" content managment design process, a documentation process, and one horse-choking travel policy.
I think it would be great to get examples of your problems in a case study format, but also in a higher-level, pattern like description. Your description sounds like it is based on the problem and the goals, which is really great.
I'm quite sure that it will also work as a tool for finding gaps and holes in either Zope or its tools and Products.
Indeed.
We would like to start a project going in the Fishbowl which aims at creating the right tools to document a project as described above.
The fishbowl is the perfect place to do this. In a conversation with other people including Brian who is the "keeper of the fishbowl" we realized that documentation artifacts come out of the fishbowl almost as much as the software. In fact, that's one of the whole reasons for the fishbowl, to come up with better software because we thought about it and wrote down some words before we started hacking code. Instant documentation.
Good luck!
-Michel
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
On Wed, 14 Feb 2001, Andy McKay wrote:
Perhaps I need more beer but whats: F=MA?
Force = Mass x Acceleration ie. the harder you kick the beer can the faster it will accelerate for any given amount of beer in it. a.k.a why kicking empty beers can hurt your toes less than kicking full ones. (why would you want to kick a full one...?) :) -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration
Ah that one. I was looking too deeply for something amusing there. -- Andy McKay. ----- Original Message ----- From: "Matt Hamilton" <matth@netsight.co.uk> To: "Andy McKay" <andym@activestate.com> Cc: "Michel Pelletier" <michel@digicool.com>; "Erik Enge" <erik@esol.no>; <zope-dev@zope.org> Sent: Wednesday, February 14, 2001 8:53 AM Subject: Re: [Zope-dev] Introducing ZopePrints.
On Wed, 14 Feb 2001, Andy McKay wrote:
Perhaps I need more beer but whats: F=MA?
Force = Mass x Acceleration
ie. the harder you kick the beer can the faster it will accelerate for any given amount of beer in it. a.k.a why kicking empty beers can hurt your toes less than kicking full ones. (why would you want to kick a full one...?)
:)
-Matt
-- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Hosting | Web Design | Domain Names | Co-location | DB Integration
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Michel Pelletier] | We would love to see this description from you. The description of such a system/model in a Fishbowl project? Or just a general description? Sorry for being slow :) | I think it would be great to get examples of your problems in a case | study format, but also in a higher-level, pattern like description. Yes, that's what I'm after. Patterns. | Good luck! Thanks! It's good to see others interested in this :)
All, I've got a Zope 2.3 server that's being used as a file server through webdav. It seems to work fine and I'm working on extending it through hookable_put. I've notice some strange behavior in the transactions when trying to 'undo' binary files upload through webdav. It throws an error and does not seem to undo anything... The error is: <!-- Traceback (innermost last): File /usr/lib/python1.5/site-packages/ZPublisher/Publish.py, line 222, in publish_module File /usr/lib/python1.5/site-packages/ZPublisher/Publish.py, line 187, in publish File /usr/share/zope/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: test.doc) File /usr/lib/python1.5/site-packages/ZPublisher/Publish.py, line 171, in publish File /usr/lib/python1.5/site-packages/ZPublisher/mapply.py, line 160, in mapply (Object: manage_undo_transactions) File /usr/lib/python1.5/site-packages/ZPublisher/Publish.py, line 112, in call_object (Object: manage_undo_transactions) File /usr/share/zope/lib/python/App/Undo.py, line 175, in manage_undo_transactions (Object: test.doc) File /usr/share/zope/lib/python/ZODB/DB.py, line 571, in undo File /usr/share/zope/lib/python/ZODB/FileStorage.py, line 831, in undo (Object: /var/zope/var/Data.fs) UndoError: (see above) --> There's nothing in here that suggests that the problem lies in the binary nature of the files, but I don't understand enough about ZODB to grok what's happening. I'm planning on moving the storage of these upload files to the filesystem soon, since I want to keep ZODB small. Perhaps this would fix the problem? Thx in advance. Chris. -- chris maresca internet systems architect -- www.chrismaresca.com "linux, only up 42 days, because a new electrical circuit was added..."
participants (6)
-
Andy McKay -
Chris Maresca -
Erik Enge -
Erik Enge -
Matt Hamilton -
Michel Pelletier