1. Zope : "Stable"
- en prod, il est autant stable qu'un apache+php en monoserveur
- en dev, tant que l'on ne développe pas des trucs trop ténu, Zope reste à peu près stable
2. Zope : "Rapide"
- Zope est tout sauf rapide : en cas de nécessité de gestion de forte charge, il faut des proxy-caches et distribuer Zope avec d'un ZoDB plus du ZEO et d'autres trucs dans le genre
- bizarrement, la stabilité en prend un coup, surtout si la ZoDBa un soucis puisque tout le systeme tombe ( d'où les proxy-caches ;) )
3. Zope : "Objet"
- je ne vais pas rentrer dans la polémique sur le fait que la grammaire "objet" de python est la meme que la fameuse grammaire "non objet" du perl objet
- par contre, Zope est objet selon le sens commun admis au meme sens que Java est objet
4. Zope : "Intuitif"
- la notion d'intuitivité est devenu une notion poubelle comme "code is design", comme "inter-opérabilité" comme "logiciels libres" [1]
- Zope est intuitif pour celui qui connait.
5. Zope : "Centralisé"
- la notion de centralisé est elle aussi devenu une notion poubelle
- Zope centralise les informations
- par contre, Zope est non uniforme au niveau des acces à l'information
6. Zope : "Diversité technologique"
- Zope n'est qu'un serveur de rendu ( au sens publication ) web d'objet
- le fait de décrire les contraintes de rendu nécessite son propre langage, cette apparente diversité est du meme ordre que
Zope -> python -> C -> asm => Zope -> C => Zope -> asm
- ne pas oublier que cette transitivité n'est pas inversable, cela est d'autant plus vrai au niveau des performances.
Par rapport à Java et les environnements J2EE, Java reste le plus bel equivalent de python sur le marché. cette équivalence se résume à : There is only one way to do it
ce qui fait que ce ne seront que des langages ( à contrario de la richesse des langues où la diversité des expressions font la personnalité du propos ).
[1]
par rapport au libre :
je rappelle que (cf ma signature actuelle tiré de http://www.fsf.org/news/freebios.html(...) ) la FSF parle in-extenso des libertés de l'utilisateur, et par conséquent le fameux "do it yourself" me semble choquant dans la communauté des libristes ( au hasard, comment coder sérieusement quand on a des problemes aux mains puisque le clavier est obligatoire ? )
par rapport à l'inter-opérabilité :
on nous bassine avec l'inter-opérabilité, les standards, etc ... perso, j'ai des cludges FireFox et KHTML car ils ne sont pas totalement standard ... mais bon passons ce détail. pour moi, l'inter-opérabilité de format et donc l'accessibilité au sens le plus large possible, repose essentiellement sur le fait qu'un document est accessible si il est possible d'opérer à l'interieur sans connaissance préalable du format utilisé.
Cela induit nécessairement que le format puisse être ouvert humainement parlant : cad qu'un être humain sans connaissance préalable puisse comprendre le contenu du document si il a connaissance des moyens d'acceder au contenu ( et non au format contenant le contenu ) . pour être plus clair, un document sxw en francais, devrait pouvoir être lisible de la meme maniere qu'un .txt ou un .html utilisant correctement les CSS.
Aujourd'hui, alors que le XML est inter-opérable avec une grammaire ultra minimaliste, les formats du genre OOo et autres XBRL sont incomprehensible pour un être humain ignorant XBRL ou OOo, ce qui fait perdre le total et unique interet de la verbosité du XML.
par rapport au "code is the design" :
Pour parler d'un autre lieu commun, oui, le code est le design réel d'une application ... effectivement, quand l'application est publié, le code représente ce qui a été réellement modélisé.
Ce qui induit la conséquence suivante, si certains codeurs contruisaient des maisons, personnellement, je ne voudrais pas y habiter.
Ce "certain" est une politesse, je vous rassure, cela concerne entre autres aussi grande majorité qui confonde l'eXtreme Programming avec Normalisation de la Bidouille, la Normalisation du Cludge et la Normalisation de l'Absence de Reflexion avant de coder.
# mon avis sur Zope compte tenu de ma vie avec Zope
Posté par Mouns . En réponse au journal Pourquoi Zope ? (possible troll inside). Évalué à 4.
- en prod, il est autant stable qu'un apache+php en monoserveur
- en dev, tant que l'on ne développe pas des trucs trop ténu, Zope reste à peu près stable
2. Zope : "Rapide"
- Zope est tout sauf rapide : en cas de nécessité de gestion de forte charge, il faut des proxy-caches et distribuer Zope avec d'un ZoDB plus du ZEO et d'autres trucs dans le genre
- bizarrement, la stabilité en prend un coup, surtout si la ZoDBa un soucis puisque tout le systeme tombe ( d'où les proxy-caches ;) )
3. Zope : "Objet"
- je ne vais pas rentrer dans la polémique sur le fait que la grammaire "objet" de python est la meme que la fameuse grammaire "non objet" du perl objet
- par contre, Zope est objet selon le sens commun admis au meme sens que Java est objet
4. Zope : "Intuitif"
- la notion d'intuitivité est devenu une notion poubelle comme "code is design", comme "inter-opérabilité" comme "logiciels libres" [1]
- Zope est intuitif pour celui qui connait.
5. Zope : "Centralisé"
- la notion de centralisé est elle aussi devenu une notion poubelle
- Zope centralise les informations
- par contre, Zope est non uniforme au niveau des acces à l'information
6. Zope : "Diversité technologique"
- Zope n'est qu'un serveur de rendu ( au sens publication ) web d'objet
- le fait de décrire les contraintes de rendu nécessite son propre langage, cette apparente diversité est du meme ordre que
Zope -> python -> C -> asm => Zope -> C => Zope -> asm
- ne pas oublier que cette transitivité n'est pas inversable, cela est d'autant plus vrai au niveau des performances.
Par rapport à Java et les environnements J2EE, Java reste le plus bel equivalent de python sur le marché. cette équivalence se résume à :
There is only one way to do it
ce qui fait que ce ne seront que des langages ( à contrario de la richesse des langues où la diversité des expressions font la personnalité du propos ).
[1]
par rapport au libre :
je rappelle que (cf ma signature actuelle tiré de http://www.fsf.org/news/freebios.html(...) ) la FSF parle in-extenso des libertés de l'utilisateur, et par conséquent le fameux "do it yourself" me semble choquant dans la communauté des libristes ( au hasard, comment coder sérieusement quand on a des problemes aux mains puisque le clavier est obligatoire ? )
par rapport à l'inter-opérabilité :
on nous bassine avec l'inter-opérabilité, les standards, etc ... perso, j'ai des cludges FireFox et KHTML car ils ne sont pas totalement standard ... mais bon passons ce détail. pour moi, l'inter-opérabilité de format et donc l'accessibilité au sens le plus large possible, repose essentiellement sur le fait qu'un document est accessible si il est possible d'opérer à l'interieur sans connaissance préalable du format utilisé.
Cela induit nécessairement que le format puisse être ouvert humainement parlant : cad qu'un être humain sans connaissance préalable puisse comprendre le contenu du document si il a connaissance des moyens d'acceder au contenu ( et non au format contenant le contenu ) . pour être plus clair, un document sxw en francais, devrait pouvoir être lisible de la meme maniere qu'un .txt ou un .html utilisant correctement les CSS.
Aujourd'hui, alors que le XML est inter-opérable avec une grammaire ultra minimaliste, les formats du genre OOo et autres XBRL sont incomprehensible pour un être humain ignorant XBRL ou OOo, ce qui fait perdre le total et unique interet de la verbosité du XML.
par rapport au "code is the design" :
Pour parler d'un autre lieu commun, oui, le code est le design réel d'une application ... effectivement, quand l'application est publié, le code représente ce qui a été réellement modélisé.
Ce qui induit la conséquence suivante, si certains codeurs contruisaient des maisons, personnellement, je ne voudrais pas y habiter.
Ce "certain" est une politesse, je vous rassure, cela concerne entre autres aussi grande majorité qui confonde l'eXtreme Programming avec Normalisation de la Bidouille, la Normalisation du Cludge et la Normalisation de l'Absence de Reflexion avant de coder.