[Zope] Re: Presentations Available
David H wrote: > I saw that in a few google hits but ... I figured that if a fair > population wants to view the presentations then the files should be in a > universal format - like pdf or rtf. > Its an interesting question: how many people who just wish to peruse > the files will feel compelled to google and download new apps just to be > able to read them? > Why download anything? You can do the conversion online at http://cdsconv.cern.ch/index.py/Simple?s_id=sxi I agree with you in general though that uploading them as pdf would have been a good idea especially since, unlike certain other office applications, the conversion is a built-in feature of OpenOffice. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Presentations Available
Thanks for posting this, Chris. Very interesting. I would've liked to have been at the conferences where you gave these. ;-) I think you make some good points. My main gripe with Plone is its such a moving target. Hopefully as it matures this will get better. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Presentations Available
Chris I agree that 2+ years should have produced maturity. Zope seems to be a lot more stable than Plone. Maybe the reason people focus on your Plone talk is you touch a chord with people who too are wrestling with Plone. Probably at least once a week the thought crosses our minds of ditching Plone and going back down to the Zope level, with some of our own stuff sitting on top of CMF. But then, Plone does provide some good things. If only these things would work consistently and not keep changing. Also while performance problems have been addressed in 2.1 there seem to still be migration problems and broken products which prevent people going to 2.1 yet. My colleague has spent a long time trying to migrate a Product he wrote, from Archetypes 1.2.5 to 1.3.4, due to the fact he had to hack around problems with references. My fear is as more features are added, what you describe as a shaky stack of complex fragile components will get ever more dependencies and therefore ever more complex and fragile. People often talk about the steep learning curve of Zope and Plone. When one is learning it, one tends to blame oneself for finding it difficult, and its a bad workman blames his tools. After a while though the question arises of why this seems to be harder to learn than say, some mathematical concept commonly considered hard to get your head around. The answer seems to be because its Plone's complexity and inconsistencies we are learning. This is not good and doesn't bode well for increasing mind share. This is not actually any worse than the J2EE / Java / class explosion world, but isn't one of the points of open source and collaboration that it should be much much better? It is great that so many people are willing to contribute their own free time, effort and resources, to write code that they freely share. It may well be that the quality of this code is miraculously good considering how its done by volunteers scattered geographically. That doesn't make the problems with Plone go away. It seems to me your recommendation to people to not use Plone at all, coming from someone who's been around in the Zope worldfor quite some time, is quite controversial but may in a roundabout way help if it forces people to make Plone more stable and mature. Well I guess I better don my asbestos clothing too. ;-) Regards Nick ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Presentations Available
Chris Withers wrote: Nick Davis wrote: there seem to still be migration problems and broken products which prevent people going to 2.1 yet. Yup. this strikes me as a bit unfair. to quote stefan holek from a post on plone-dev earlier today, most reported migration problems are due to: - Upgrading to Zope 2.8 without reading the release notes. - Third party products that are not yet fully compatible with Plone 2.1 and/or Zope 2.8. - Sites that have customized parts of Plone they shouldn't have touched in the first place. - Plone Team stupidity. thus, while it's true that we have made mistakes (and will continue to, no doubt), most of the problems are issues beyond our control. as for the broken products, that is a pandemic within the open source community, hardly unique to plone. how many zope products are out there of dubious quality, or that are poorly maintained? whenever you get a large community of developers, you get a mixed bag of talent and of follow-through. the suggestion you make in your talk of having a peer rating process for add-on products is a good one, certainly, and one that's been discussed before, but getting there takes some effort. My colleague has spent a long time trying to migrate a Product he wrote, from Archetypes 1.2.5 to 1.3.4, due to the fact he had to hack around problems with references. Archetypes is the chief sinner in all of this, I'm afraid. It's trying to solve a very difficult problem, and one which needs tackling with structure and upfront and intuitive design rather than the organic tacking on of new "bitz" whenever anyone felt like it that AT has suffered through... My fear is as more features are added, what you describe as a shaky stack of complex fragile components will get ever more dependencies and therefore ever more complex and fragile. Yup. yes, AT is in many ways a mess. but, as you say, it's tackling a very difficult problem, and, like most attempts at tackling difficult problems, the first iterations were somewhat less than perfect. the same can be said for zope itself... there's a reason z3 was a complete rewrite. AT's problems are entirely recognized by those of us who use it heavily, and i can assure you that the AT developer pool has no intention of continuing to pile more cruft on top of a shaky stack. instead, we're looking at how we can break the framework apart into components that can all be glued together in a nice z3 fashion. there are a great many tools available to us now that were not available when AT was originally developed (adapters, events, views, etc.), and we have every intention of making use of them to improve the stack (by making it leaner and more efficient, NOT by adding features willy-nilly!). ideally, you'll be able to pick and choose from the various AT features, using adapters to glue the functionality you need (and only what you need) into your own products. the first iterations of this will probably also have some warts. but please don't assume that plone/AT developers don't see the same problems that you see, and that they aren't willing and able to learn from their mistakes. -r ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Presentations Available
Hello Some thoughts : - Upgrading to Zope 2.8 without reading the release notes. I followed the release notes but this didn't fix catalog errors. I am not the only one. This is apparently fixed in Zope 2.8.2 but that doesn't look like it can be downloaded yet. - Third party products that are not yet fully compatible with Plone 2.1 and/or Zope 2.8. Should this perhaps be the other way around? If those products used the APIs correctly, perhaps a new release of Zope/Plone should still support old APIs and/or deprecate them gradually and with warning? This is a difficult problem to address but sometimes it may be better to hold back on releasing something new if it causes things that depend on it to break. On the other hand I can understand peoples desire to release something new and cool (even if not quite ready) . ;-) And its hard to know quickly what the bugs are if you don't release it to the real world. So hard to know what to do.. - Sites that have customized parts of Plone they shouldn't have touched in the first place. This is an important issue. It is difficult not to touch things that one shouldn't. A trivial example - If you want your breadcrumbs to just list the breadcrumbs instead of say "you are here" you have to copy across global_pathbar.pt and take out "you are here". There is not another easy way to do it that I can see. If you then migrate to 2.1, that .pt has changed so you have to copy the new one and re-do it otherwise nothing renders. If you want to add another logo on the right of the header you have to hack Plone's templates further. Each change is in itself trivial but they add up and when you migrate, you;re left with stuff that doesn't work and spend quite a while resolving it. And thats for those of us savvy enough to use the filesystem. Those who customised through the ZMI will have a bigger headache. as for the broken products, that is a pandemic within the open source community, hardly unique to plone. True. AT's problems are entirely recognized by those of us who use it heavily, and i can assure you that the AT developer pool has no intention of continuing to pile more cruft on top of a shaky stack. . the first iterations of this will probably also have some warts. but please don't assume that plone/AT developers don't see the same problems that you see, and that they aren't willing and able to learn from their mistakes. It would seem Archetypes has improved over time. My real worry is when we do have a new release of Plone sitting on top of Zope 3 we'll have a whole new set of bleeding edge code sitting on top of other bleeding edge code, while stuff that did work with a mature AT1.3.x (or 1.4.x or whatever) suddenly stops working. Hopefully this will prove to be an unjustified fear! Probably this is no-one's fault. It is the nature of open source. To compare, have to admit I tried to get Bricolage to work a while back, and ran into CPAN dependency hell. I wonder if perhaps the real problem is trying to do so much with so few resources. Linux has a very mature platform as much of its base, and a lot of commercial support which helps. Perl and the CPAN is quite mature now and also had quite a lot of commercial support. The good thing about commercial support is people being paid to do grunt work and run loads of tests and update documents. Both Linux and CPAN are very modular. It is relatively easy to change one part without knowing about other parts. I think it would be easier to find someone who could patch a broken CPAN module, than someone who could delve inside Zope and Plone. This is because many of us don't understand the various components of the underlying architecture, and a lot is changing for Zope 3. Also many Perl modules are widely used by many applications, whereas a lot of Zope code is only used by other Zope code. ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
[Zope] Re: Presentations Available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Davis wrote: >>> - Third party products that are not yet fully compatible >>> with Plone 2.1 and/or Zope 2.8. > > Should this perhaps be the other way around? If those products used the > APIs correctly, perhaps a new release of Zope/Plone should still support > old APIs and/or deprecate them gradually and with warning? Zope and CMF already adopt this practice for "public" APIS. Some of the incompatibilities people report come from reliance on non-public implementation details; others are bugs in Zope or CMF. I don't know what Plone's policy is about deprecating APIs / features. > This is a difficult problem to address but sometimes it may be better > to hold back on releasing something new if it causes things that > depend on it to break. On the other hand I can understand peoples > desire to release something new and cool (even if not quite ready) . > ;-) And its hard to know quickly what the bugs are if you don't > release it to the real world. So hard to know what to do.. > >>> - Sites that have customized parts of Plone they shouldn't >>> have touched in the first place. > > This is an important issue. It is difficult not to touch things that one > shouldn't. A trivial example - If you want your breadcrumbs to just list > the breadcrumbs instead of say "you are here" you have to copy across > global_pathbar.pt and take out "you are here". There is not another easy > way to do it that I can see. If you then migrate to 2.1, that .pt has > changed so you have to copy the new one and re-do it otherwise nothing > renders. If you want to add another logo on the right of the header you > have to hack Plone's templates further. Each change is in itself trivial > but they add up and when you migrate, you;re left with stuff that > doesn't work and spend quite a while resolving it. And thats for those > of us savvy enough to use the filesystem. Those who customised through > the ZMI will have a bigger headache. There are real tensions here, especially when dealing with UI code: - Maintainability is a virtue for the programmer, but often drives a factoring of the templates which make them useless for other stakeholders, such as designers. - Reusability is always confounded when policy and mechanism are mixed together: UI is very much policy-centric, which makes reusing its mechanisms *very* hard. > My real worry is when we do have a new release of Plone sitting on top > of Zope 3 we'll have a whole new set of bleeding edge code sitting on > top of other bleeding edge code, while stuff that did work with a mature > AT1.3.x (or 1.4.x or whatever) suddenly stops working. > Hopefully this will prove to be an unjustified fear! Zope3 itself will hardly be "bleeding edge" at that point; the path we are taking to get there (the "Goldegg initiative"), should make the size of each change set more manageable. > Probably this is no-one's fault. It is the nature of open source. To > compare, have to admit I tried to get Bricolage to work a while back, > and ran into CPAN dependency hell. > > I wonder if perhaps the real problem is trying to do so much with so > few resources. Linux has a very mature platform as much of its base, > and a lot of commercial support which helps. Perl and the CPAN is > quite mature now and also had quite a lot of commercial support. The > good thing about commercial support is people being paid to do grunt > work and run loads of tests and update documents. Both Linux and CPAN > are very modular. It is relatively easy to change one part without > knowing about other parts. I think it would be easier to find someone > who could patch a broken CPAN module, than someone who could delve > inside Zope and Plone. This is because many of us don't understand > the various components of the underlying architecture, and a lot is > changing for Zope 3. Also many Perl modules are widely used by many > applications, whereas a lot of Zope code is only used by other Zope > code. One of the major promises of Zope3 is that it makes for more modular code, because its component architecture makes it easy and natural to break apart monolithic classes into components related by well-defined interfaces. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDRnzC+gerLs4ltQ4RApayAJ9fvkj3rPFmM1wxl2agDOf+WFqvHwCeN7/I 4FwWQPNsmxo0Urxjq+52Q8A= =MgUC -END PGP SIGNATURE- ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/m
[Zope] Re: Presentations Available
Nick Davis wrote: Hello Some thoughts : - Upgrading to Zope 2.8 without reading the release notes. I followed the release notes but this didn't fix catalog errors. I am not the only one. This is apparently fixed in Zope 2.8.2 but that doesn't look like it can be downloaded yet. in some cases the problem will go away if you simply execute a 'len(catalog)' command, either from a script or from zopectl debug. YMMV. - Third party products that are not yet fully compatible with Plone 2.1 and/or Zope 2.8. Should this perhaps be the other way around? If those products used the APIs correctly, perhaps a new release of Zope/Plone should still support old APIs and/or deprecate them gradually and with warning? This is a difficult problem to address but sometimes it may be better to hold back on releasing something new if it causes things that depend on it to break. On the other hand I can understand peoples desire to release something new and cool (even if not quite ready) . ;-) And its hard to know quickly what the bugs are if you don't release it to the real world. So hard to know what to do.. the problem is not with the APIs... those we have taken care to deprecate. the problems lie within template code (such as the problem you describe below), where it's much harder to maintain backward compatibility and still move forward. - Sites that have customized parts of Plone they shouldn't have touched in the first place. This is an important issue. It is difficult not to touch things that one shouldn't. A trivial example - If you want your breadcrumbs to just list the breadcrumbs instead of say "you are here" you have to copy across global_pathbar.pt and take out "you are here". There is not another easy way to do it that I can see. If you then migrate to 2.1, that .pt has changed so you have to copy the new one and re-do it otherwise nothing renders. If you want to add another logo on the right of the header you have to hack Plone's templates further. Each change is in itself trivial but they add up and when you migrate, you;re left with stuff that doesn't work and spend quite a while resolving it. And thats for those of us savvy enough to use the filesystem. Those who customised through the ZMI will have a bigger headache. tres responded to this more eloquently than i'd be able to... as for the broken products, that is a pandemic within the open source community, hardly unique to plone. True. AT's problems are entirely recognized by those of us who use it heavily, and i can assure you that the AT developer pool has no intention of continuing to pile more cruft on top of a shaky stack. . the first iterations of this will probably also have some warts. but please don't assume that plone/AT developers don't see the same problems that you see, and that they aren't willing and able to learn from their mistakes. It would seem Archetypes has improved over time. My real worry is when we do have a new release of Plone sitting on top of Zope 3 we'll have a whole new set of bleeding edge code sitting on top of other bleeding edge code, while stuff that did work with a mature AT1.3.x (or 1.4.x or whatever) suddenly stops working. Hopefully this will prove to be an unjustified fear! as tres said, z3 isn't really bleeding edge any more. i'm not saying that there won't be migration bumps.. i expect there will be. but there are a lot of folks with a lot of working code dependent on this stack, and we'll all be working together to get to the next level. Probably this is no-one's fault. It is the nature of open source. To compare, have to admit I tried to get Bricolage to work a while back, and ran into CPAN dependency hell. I wonder if perhaps the real problem is trying to do so much with so few resources. this is, to me, the crux of the problem. there are a million things that could be better. i've got far more ideas for improvement than i have the time to give those ideas... we've all still got to get billable hours in. that being said, things are getting better with time, and i expect them to continue to do so. Linux has a very mature platform as much of its base, and a lot of commercial support which helps. Perl and the CPAN is quite mature now and also had quite a lot of commercial support. The good thing about commercial support is people being paid to do grunt work and run loads of tests and update documents. Both Linux and CPAN are very modular. It is relatively easy to change one part without knowing about other parts. I think it would be easier to find someone who could patch a broken CPAN module, than someone who could delve inside Zope and Plone. This is because many of us don't understand the various components of the underlying architecture, and a lot is changing for Zope 3. Also many Perl modules are widely used by many applications, whereas a lot of Zope code is only used by other Zope code. again, tres
[Zope] Re: Presentations Available
Rob, Tres, Thanks a lot for your helpful responses. I take Tres's point of the difficulty of making templates that work for the different interests of designers and programmers, and that migration headaches are often a consequence of this. Hadn't thought of it like that before. Also its good to hear that so much has been addressed in Zope 3 to make things modular. I will take more of a look at the Zope 3 book. I've not yet had the opportunity to go to any conferences and it is hard to know just how much has been addressed already and what problems are already being solved. One can easily live in ignorance and getting replies like this is very helpful. BTW Both Chris and I come from the UK where complaining about things is a national sport so please no-one take offence. ;-) Nick ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Presentations Available
Nick Davis wrote: Thanks for posting this, Chris. Very interesting. I would've liked to have been at the conferences where you gave these. ;-) With bricks or beer? ;-) I think you make some good points. thanks! My main gripe with Plone is its such a moving target. Hopefully as it matures this will get better. ...2+ years should have already produced some maturity, no? In any case, how come everyone's focussing on the Plone talk? Personally, the one on unit testing and the other one on Stepper and other cool Zope toys is much more important IMNSHO... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Presentations Available
Hi Nick, Nick Davis wrote: I agree that 2+ years should have produced maturity. Zope seems to be a lot more stable than Plone. Well, Zope has had about 10 years to stabilise, versus Plone's 2 ;-) Maybe the reason people focus on your Plone talk is you touch a chord with people who too are wrestling with Plone. *grinz* I can but hope... Probably at least once a week the thought crosses our minds of ditching Plone and going back down to the Zope level, with some of our own stuff sitting on top of CMF. But then, Plone does provide some good things. Yep, that's a point I made while giving that talk :-S If only these things would work consistently and not keep changing. You REALLY want them to stay as bad as they were? ;-) Also while performance problems have been addressed in 2.1 No they haven't... there seem to still be migration problems and broken products which prevent people going to 2.1 yet. Yup. My colleague has spent a long time trying to migrate a Product he wrote, from Archetypes 1.2.5 to 1.3.4, due to the fact he had to hack around problems with references. Archetypes is the chief sinner in all of this, I'm afraid. It's trying to solve a very difficult problem, and one which needs tackling with structure and upfront and intuitive design rather than the organic tacking on of new "bitz" whenever anyone felt like it that AT has suffered through... My fear is as more features are added, what you describe as a shaky stack of complex fragile components will get ever more dependencies and therefore ever more complex and fragile. Yup. People often talk about the steep learning curve of Zope and Plone. When one is learning it, one tends to blame oneself for finding it difficult, and its a bad workman blames his tools. After a while though the question arises of why this seems to be harder to learn than say, some mathematical concept commonly considered hard to get your head around. The answer seems to be because its Plone's complexity and inconsistencies we are learning. This is not good and doesn't bode well for increasing mind share. Indeed. This is not actually any worse than the J2EE / Java / class explosion world, but isn't one of the points of open source and collaboration that it should be much much better? Well, that's a different discussion, and one best had over much beer... It is great that so many people are willing to contribute their own free time, effort and resources, to write code that they freely share. ...but, and this may seem harsh, but that doesn't, in itself, mean they're any good at writing quality software... It seems to me your recommendation to people to not use Plone at all, coming from someone who's been around in the Zope worldfor quite some time, is quite controversial but may in a roundabout way help if it forces people to make Plone more stable and mature. Moi? Controlversial? i'd never do such a thing ;-) *grinz* Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Presentations Available
Rob Miller wrote: this strikes me as a bit unfair. to quote stefan holek from a post on plone-dev earlier today, most reported migration problems are due to: - Upgrading to Zope 2.8 without reading the release notes. *shrugs* I've not had need to read he release notes yet, what am I missing? - Third party products that are not yet fully compatible with Plone 2.1 and/or Zope 2.8. Well yes, see comments about the state of third party products, particularly for Plone elsewhere... - Sites that have customized parts of Plone they shouldn't have touched in the first place. Was there anything to tell them not to? People often code by copying and pasting and far too often Plone seems to give the impression "well, you shouldn't do this, but we have to, so we are" riding roughshod over their own APIs, not to mention those of Zope, and using some truly horrendous coding style which people who base their projects on Plone unfortunately learn from... - Plone Team stupidity. no comment ;-) as for the broken products, that is a pandemic within the open source community, hardly unique to plone. *shrugs* this is more philosophical and which I covered in the talk. Plone has been "all inclusive" in its welcoming to potential developers, this builds a a great community at the expense of software quality, imnsho... follow-through. the suggestion you make in your talk of having a peer rating process for add-on products is a good one, certainly, and one that's been discussed before, but getting there takes some effort. ...probably worth someone senior in the Plone community making that effort though ;-) AT's problems are entirely recognized by those of us who use it heavily, and i can assure you that the AT developer pool has no intention of continuing to pile more cruft on top of a shaky stack. Really? ;-) the first iterations of this will probably also have some warts. but please don't assume that plone/AT developers don't see the same problems that you see, and that they aren't willing and able to learn from their mistakes. Yes, but there are simple to fix bugs and horribleness in AT that have been there over multiple releases now, your comments don't really gel with that reality... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Re: [Zope] Re: Presentations Available
Hi Nick, Nick Davis wrote: BTW Both Chris and I come from the UK where complaining about things is a national sport so please no-one take offence. ;-) Nah, the Plone stuff is beyond mere national past time. The excruciating agony it's caused me on a fairly regular basis for a number of years now is what's behind it, and the talk I gave at the Plone conference is merely a more in depth look at why it makes my cry ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
