Ca existe des patrons de site pratiquement prêt à l'emploi de pour faire un site pour une PME, non ? Vous auriez des idées ?
Oui, CPS par exemple: http://www.cps-project.org/ Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs. La liste des organismes qui l'utilisent: http://www.nuxeo.com/clients/ Il n'ont pas cité mais le gouvernement Sénégalais et les Mairies de Antananarivo (capitale de Madagascar) l'utilisent aussi.
C'est pret à l'emploi, mais faut pas rever, si tu veux l'ajuster à tes besoins, il faut bosser un peu dessus.
Ca existe des patrons de site pratiquement prêt à l'emploi de pour
faire un site pour une PME, non ? Vous auriez des idées ?
Oui, CPS par exemple: http://www.cps-project.org/
Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs.
La liste des organismes qui l'utilisent:
http://www.nuxeo.com/clients/
Il n'ont pas cité mais le gouvernement Sénégalais et les Mairies de
Antananarivo (capitale de Madagascar) l'utilisent aussi.
C'est pret à l'emploi, mais faut pas rever, si tu veux l'ajuster à tes
besoins, il faut bosser un peu dessus.
Ca existe des patrons de site pratiquement prêt à l'emploi de pour faire un site pour une PME, non ? Vous auriez des idées ?
Oui, CPS par exemple: http://www.cps-project.org/ Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs. La liste des organismes qui l'utilisent: http://www.nuxeo.com/clients/ Il n'ont pas cité mais le gouvernement Sénégalais et les Mairies de Antananarivo (capitale de Madagascar) l'utilisent aussi.
C'est pret à l'emploi, mais faut pas rever, si tu veux l'ajuster à tes besoins, il faut bosser un peu dessus.
Le Sat, 06 May 2006 15:40:38 +0200, R12y a écrit :
Oui, CPS par exemple: http://www.cps-project.org/ Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs.
C'est une sacrée usine à gaz, quand même... Il y a Plone aussi, en concurrent direct.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
Le Sat, 06 May 2006 15:40:38 +0200, R12y a écrit :
Oui, CPS par exemple: http://www.cps-project.org/
Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs.
C'est une sacrée usine à gaz, quand même... Il y a Plone aussi, en
concurrent direct.
--
Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est
carrément impossible. Si ça a l'air impossible, c'est un compilateur
Ada.
Théorème de Stockmayer.
Le Sat, 06 May 2006 15:40:38 +0200, R12y a écrit :
Oui, CPS par exemple: http://www.cps-project.org/ Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs.
C'est une sacrée usine à gaz, quand même... Il y a Plone aussi, en concurrent direct.
-- Si ça a l'air facile, c'est difficile. Si ça a l'air difficile, c'est carrément impossible. Si ça a l'air impossible, c'est un compilateur Ada. Théorème de Stockmayer.
talon
Emmanuel Florac wrote:
Le Sat, 06 May 2006 15:40:38 +0200, R12y a écrit :
Oui, CPS par exemple: http://www.cps-project.org/ Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs.
C'est une sacrée usine à gaz, quand même... Il y a Plone aussi, en concurrent direct.
Zope et Plone comme truc léger, c'est pas rééllement le pied. Parmi les frameworks qui sont à la mode actuellement, et qui sont justement beaucoup plus légers, il y a django en python, et évidemment ruby on rails en ruby. Ayant vu la tendance Sun lance un dispositif similaire en Java, qui permet là encore de faire le squelette d'un site en remplissant deux wizards. http://blogs.sun.com/roller/page/geertjan?entry=the_best_feature_of_the1 Evidemment s'il s'agit de supporter une forte charge Java est de loin préférable, et c'est bien pourquoi industriellement Java et C# sont les seules solutions rééllement utilisées, C# bien sûr dans les boites qui font confiance à Microsoft et Java ailleurs.
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Sat, 06 May 2006 15:40:38 +0200, R12y a écrit :
Oui, CPS par exemple: http://www.cps-project.org/
Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs.
C'est une sacrée usine à gaz, quand même... Il y a Plone aussi, en
concurrent direct.
Zope et Plone comme truc léger, c'est pas rééllement le pied. Parmi
les frameworks qui sont à la mode actuellement, et qui sont justement beaucoup
plus légers, il y a django en python, et évidemment ruby on rails en ruby.
Ayant vu la tendance Sun lance un dispositif similaire en Java, qui permet là
encore de faire le squelette d'un site en remplissant deux wizards.
http://blogs.sun.com/roller/page/geertjan?entry=the_best_feature_of_the1
Evidemment s'il s'agit de supporter une forte charge Java est de loin
préférable, et c'est bien pourquoi industriellement Java et C# sont les
seules solutions rééllement utilisées, C# bien sûr dans les boites qui font
confiance à Microsoft et Java ailleurs.
Le Sat, 06 May 2006 15:40:38 +0200, R12y a écrit :
Oui, CPS par exemple: http://www.cps-project.org/ Ca fait un moment que je l'étudie, j'ia fait un stage chez ses éditeurs.
C'est une sacrée usine à gaz, quand même... Il y a Plone aussi, en concurrent direct.
Zope et Plone comme truc léger, c'est pas rééllement le pied. Parmi les frameworks qui sont à la mode actuellement, et qui sont justement beaucoup plus légers, il y a django en python, et évidemment ruby on rails en ruby. Ayant vu la tendance Sun lance un dispositif similaire en Java, qui permet là encore de faire le squelette d'un site en remplissant deux wizards. http://blogs.sun.com/roller/page/geertjan?entry=the_best_feature_of_the1 Evidemment s'il s'agit de supporter une forte charge Java est de loin préférable, et c'est bien pourquoi industriellement Java et C# sont les seules solutions rééllement utilisées, C# bien sûr dans les boites qui font confiance à Microsoft et Java ailleurs.
--
Michel TALON
Emmanuel Florac
Le Sat, 06 May 2006 15:50:26 +0000, Michel Talon a écrit :
Evidemment s'il s'agit de supporter une forte charge Java est de loin préférable, et c'est bien pourquoi industriellement Java et C# sont les seules solutions rééllement utilisées, C# bien sûr dans les boites qui font confiance à Microsoft et Java ailleurs.
En quoi Java est préférable pour supporter une forte charge? Parce que son seul usage induit une forte charge, peut être ? :)
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
Le Sat, 06 May 2006 15:50:26 +0000, Michel Talon a écrit :
Evidemment s'il s'agit de supporter une forte charge Java est de loin
préférable, et c'est bien pourquoi industriellement Java et C# sont les
seules solutions rééllement utilisées, C# bien sûr dans les boites qui font
confiance à Microsoft et Java ailleurs.
En quoi Java est préférable pour supporter une forte charge? Parce que
son seul usage induit une forte charge, peut être ? :)
--
L'esprit qu'on veut avoir gâte celui qu'on a.
Jean-Baptiste Louis Grisset.
Le Sat, 06 May 2006 15:50:26 +0000, Michel Talon a écrit :
Evidemment s'il s'agit de supporter une forte charge Java est de loin préférable, et c'est bien pourquoi industriellement Java et C# sont les seules solutions rééllement utilisées, C# bien sûr dans les boites qui font confiance à Microsoft et Java ailleurs.
En quoi Java est préférable pour supporter une forte charge? Parce que son seul usage induit une forte charge, peut être ? :)
-- L'esprit qu'on veut avoir gâte celui qu'on a. Jean-Baptiste Louis Grisset.
talon
Emmanuel Florac wrote:
Le Sat, 06 May 2006 15:50:26 +0000, Michel Talon a écrit :
Evidemment s'il s'agit de supporter une forte charge Java est de loin préférable, et c'est bien pourquoi industriellement Java et C# sont les seules solutions rééllement utilisées, C# bien sûr dans les boites qui font confiance à Microsoft et Java ailleurs.
En quoi Java est préférable pour supporter une forte charge? Parce que son seul usage induit une forte charge, peut être ? :)
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Sat, 06 May 2006 15:50:26 +0000, Michel Talon a écrit :
Evidemment s'il s'agit de supporter une forte charge Java est de loin
préférable, et c'est bien pourquoi industriellement Java et C# sont les
seules solutions rééllement utilisées, C# bien sûr dans les boites qui font
confiance à Microsoft et Java ailleurs.
En quoi Java est préférable pour supporter une forte charge? Parce que
son seul usage induit une forte charge, peut être ? :)
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir
des performances relativement proches d'un programme compilé, là où
des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois
plus lents.
Le Sat, 06 May 2006 15:50:26 +0000, Michel Talon a écrit :
Evidemment s'il s'agit de supporter une forte charge Java est de loin préférable, et c'est bien pourquoi industriellement Java et C# sont les seules solutions rééllement utilisées, C# bien sûr dans les boites qui font confiance à Microsoft et Java ailleurs.
En quoi Java est préférable pour supporter une forte charge? Parce que son seul usage induit une forte charge, peut être ? :)
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
--
Michel TALON
R12y
On Sat, 06 May 2006 15:50:26 +0000, Michel Talon wrote:
Zope et Plone comme truc léger, c'est pas rééllement le pied.
Le critère initial n'était pas la légèreté. Mais oui, c'est du lourd. D'une manière vulgaire, on peut dire que c'est le fait qu'on passe par plusieurs couches logicielles qui alourdi la chose. Il y a la couche Zope de plus bas niveau, puis celle CMF [1], puis enfin celle CPS.
Et puis, pour avoir fréquenté l'équipe de dévelopement de CPS, c'est lourd, mais c'est pas "lourd pour rien". Les fonctionalités (pas forcément palpables par celui qui cliqouille un peu partout) sont multiples, et plusieurs mécanismes sont mis en oeuvre. Contrairement à ce qu'on peu croire, ça tient la charge, je l'ai vu. Et au vu de la puissance des machines que nous avons de nos jours, je pense que l'existence de telles usines à gaz est utile. Pourquoi? justement pour faire travailler ces beaux processeurs et aussi pour montrer jusqu'ou peut-on pousser "le calcul".
On Sat, 06 May 2006 15:50:26 +0000, Michel Talon wrote:
Zope et Plone comme truc léger, c'est pas rééllement le pied.
Le critère initial n'était pas la légèreté.
Mais oui, c'est du lourd.
D'une manière vulgaire, on peut dire que c'est le fait qu'on passe par
plusieurs couches logicielles qui alourdi la chose. Il y a la couche Zope
de plus bas niveau, puis celle CMF [1], puis enfin celle CPS.
Et puis, pour avoir fréquenté l'équipe de dévelopement de CPS, c'est
lourd, mais c'est pas "lourd pour rien". Les fonctionalités (pas forcément
palpables par celui qui cliqouille un peu partout) sont multiples, et
plusieurs mécanismes sont mis en oeuvre. Contrairement à ce qu'on peu
croire, ça tient la charge, je l'ai vu. Et au vu de la puissance des
machines que nous avons de nos jours, je pense que l'existence de telles
usines à gaz est utile. Pourquoi? justement pour faire travailler ces
beaux processeurs et aussi pour montrer jusqu'ou peut-on pousser "le
calcul".
On Sat, 06 May 2006 15:50:26 +0000, Michel Talon wrote:
Zope et Plone comme truc léger, c'est pas rééllement le pied.
Le critère initial n'était pas la légèreté. Mais oui, c'est du lourd. D'une manière vulgaire, on peut dire que c'est le fait qu'on passe par plusieurs couches logicielles qui alourdi la chose. Il y a la couche Zope de plus bas niveau, puis celle CMF [1], puis enfin celle CPS.
Et puis, pour avoir fréquenté l'équipe de dévelopement de CPS, c'est lourd, mais c'est pas "lourd pour rien". Les fonctionalités (pas forcément palpables par celui qui cliqouille un peu partout) sont multiples, et plusieurs mécanismes sont mis en oeuvre. Contrairement à ce qu'on peu croire, ça tient la charge, je l'ai vu. Et au vu de la puissance des machines que nous avons de nos jours, je pense que l'existence de telles usines à gaz est utile. Pourquoi? justement pour faire travailler ces beaux processeurs et aussi pour montrer jusqu'ou peut-on pousser "le calcul".
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM Java par exemple, ou même être converti en C++.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir
des performances relativement proches d'un programme compilé, là où
des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois
plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM
Java par exemple, ou même être converti en C++.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM Java par exemple, ou même être converti en C++.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando
Patrice Karatchentzeff
Emmanuel Florac writes:
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM Java par exemple, ou même être converti en C++.
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir
des performances relativement proches d'un programme compilé, là où
des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois
plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM
Java par exemple, ou même être converti en C++.
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM Java par exemple, ou même être converti en C++.
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM Java par exemple, ou même être converti en C++.
100 fois plus lent ça correspond à ce que j'ai mesuré sur quelques exemples. Oui il existe un convertisseur de python en C++ dont l'auteur prétend que ça permet de gagner un facteur de l'ordre de 100, ce qui est assez cohérent avec ce que je dis ... Outre ces questions python a un support assez rudimentaire des threads, ce qui fait que chaque fois qu'on rentre dans un module écrit en C il ne peut y avoir changement de thread. Autant dire qu'une machine avec beaucoup de processeurs ne va pas faire gagner grand chose. Je crois que c'est une des qualités de perl d'avoir un meilleur support dans ce domaine. Et bien sûr java d'autant plus.
--
Michel TALON
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir
des performances relativement proches d'un programme compilé, là où
des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois
plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM
Java par exemple, ou même être converti en C++.
100 fois plus lent ça correspond à ce que j'ai mesuré sur quelques exemples.
Oui il existe un convertisseur de python en C++ dont l'auteur prétend que ça
permet de gagner un facteur de l'ordre de 100, ce qui est assez cohérent avec
ce que je dis ...
Outre ces questions python a un support assez rudimentaire des threads, ce
qui fait que chaque fois qu'on rentre dans un module écrit en C il ne peut y
avoir changement de thread. Autant dire qu'une machine avec beaucoup de
processeurs ne va pas faire gagner grand chose. Je crois que c'est une des
qualités de perl d'avoir un meilleur support dans ce domaine. Et bien sûr
java d'autant plus.
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM Java par exemple, ou même être converti en C++.
100 fois plus lent ça correspond à ce que j'ai mesuré sur quelques exemples. Oui il existe un convertisseur de python en C++ dont l'auteur prétend que ça permet de gagner un facteur de l'ordre de 100, ce qui est assez cohérent avec ce que je dis ... Outre ces questions python a un support assez rudimentaire des threads, ce qui fait que chaque fois qu'on rentre dans un module écrit en C il ne peut y avoir changement de thread. Autant dire qu'une machine avec beaucoup de processeurs ne va pas faire gagner grand chose. Je crois que c'est une des qualités de perl d'avoir un meilleur support dans ce domaine. Et bien sûr java d'autant plus.
--
Michel TALON
JKB
Le 06-05-2006, à propos de Re: Template de site pour PME, Michel Talon écrivait dans fr.comp.os.linux.debats :
Emmanuel Florac wrote:
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM Java par exemple, ou même être converti en C++.
100 fois plus lent ça correspond à ce que j'ai mesuré sur quelques exemples. Oui il existe un convertisseur de python en C++ dont l'auteur prétend que ça permet de gagner un facteur de l'ordre de 100, ce qui est assez cohérent avec ce que je dis ... Outre ces questions python a un support assez rudimentaire des threads, ce qui fait que chaque fois qu'on rentre dans un module écrit en C il ne peut y avoir changement de thread. Autant dire qu'une machine avec beaucoup de processeurs ne va pas faire gagner grand chose. Je crois que c'est une des qualités de perl d'avoir un meilleur support dans ce domaine. Et bien sûr java d'autant plus.
J'utilise la JVM (la dernière) de monsieur Sun à la fois sur du Linux X86-64 (machines Sun/SMP) et sur du Solaris 10 (UltraSPARC/SMP). Je n'ai pour l'instant jamais vu une JVM occuper deux processeurs, et pourtant, cela m'arrangerait bien. Le support multithread est _interne_ à la JVM et ne concerne pas le système sous-jacent. Ou alors j'ai raté un truc dans la doc, mais je ne suis pas le seul.
JKB
Le 06-05-2006, à propos de
Re: Template de site pour PME,
Michel Talon écrivait dans fr.comp.os.linux.debats :
Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir
des performances relativement proches d'un programme compilé, là où
des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois
plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM
Java par exemple, ou même être converti en C++.
100 fois plus lent ça correspond à ce que j'ai mesuré sur quelques exemples.
Oui il existe un convertisseur de python en C++ dont l'auteur prétend que ça
permet de gagner un facteur de l'ordre de 100, ce qui est assez cohérent avec
ce que je dis ...
Outre ces questions python a un support assez rudimentaire des threads, ce
qui fait que chaque fois qu'on rentre dans un module écrit en C il ne peut y
avoir changement de thread. Autant dire qu'une machine avec beaucoup de
processeurs ne va pas faire gagner grand chose. Je crois que c'est une des
qualités de perl d'avoir un meilleur support dans ce domaine. Et bien sûr
java d'autant plus.
J'utilise la JVM (la dernière) de monsieur Sun à la fois sur du
Linux X86-64 (machines Sun/SMP) et sur du Solaris 10
(UltraSPARC/SMP). Je n'ai pour l'instant jamais vu une JVM occuper
deux processeurs, et pourtant, cela m'arrangerait bien. Le support
multithread est _interne_ à la JVM et ne concerne pas le système
sous-jacent. Ou alors j'ai raté un truc dans la doc, mais je ne suis
pas le seul.
Le 06-05-2006, à propos de Re: Template de site pour PME, Michel Talon écrivait dans fr.comp.os.linux.debats :
Emmanuel Florac wrote:
Le Sat, 06 May 2006 19:01:27 +0000, Michel Talon a écrit :
En ce que correctement utilisé sur une machine appropriée, il arrive à avoir des performances relativement proches d'un programme compilé, là où des interprètes comme perl, python, ruby, etc. sont au bas mot 100 fois plus lents.
100 fois plus lent faut pas pousser. Et puis python peut tourner sur la VM Java par exemple, ou même être converti en C++.
100 fois plus lent ça correspond à ce que j'ai mesuré sur quelques exemples. Oui il existe un convertisseur de python en C++ dont l'auteur prétend que ça permet de gagner un facteur de l'ordre de 100, ce qui est assez cohérent avec ce que je dis ... Outre ces questions python a un support assez rudimentaire des threads, ce qui fait que chaque fois qu'on rentre dans un module écrit en C il ne peut y avoir changement de thread. Autant dire qu'une machine avec beaucoup de processeurs ne va pas faire gagner grand chose. Je crois que c'est une des qualités de perl d'avoir un meilleur support dans ce domaine. Et bien sûr java d'autant plus.
J'utilise la JVM (la dernière) de monsieur Sun à la fois sur du Linux X86-64 (machines Sun/SMP) et sur du Solaris 10 (UltraSPARC/SMP). Je n'ai pour l'instant jamais vu une JVM occuper deux processeurs, et pourtant, cela m'arrangerait bien. Le support multithread est _interne_ à la JVM et ne concerne pas le système sous-jacent. Ou alors j'ai raté un truc dans la doc, mais je ne suis pas le seul.
