Quand un sp=E9cialiste de m=E9canique quantique s'int=E9resse =E0 Python cel=
a
donne 'web2py' (anciennement Gluon)
Nous avons d=E9j=E0 mentionn=E9 ce framework dans le fil de discussion sur
les 'app Google'.
Lorsqu'il s'agit d'installer un framework web comme
Django,Turbogears,Pylon,Appcelarator, et autres chez soi, cela ne pose
=E0 priori aucun probl=E8mes.
Par contre dans un environnement o=F9 seul le http est autoris=E9, cela
devient tr=E8s contraignant.
'web2py' est constitu=E9 d'un seul package et se t=E9l=E9charge via http
sans aucun probl=E8me.
A la limite on peut m=EAme l'installer sur une clef usb.
Ce qui est tr=E8s original dans ce framework c'est la facilit=E9 avec
laquelle on installe et on d=E9ploie des applications
'bytecoted'.
Tout ce fait =E0 travers l'interface web.
Si Rails vous tente alors n'h=E9siter en aucun cas =E0 utiliser web2py.
Si certains d'entre vous l'on test=E9, j'aimerais beaucoup conna=EEtre
leur point de vue
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Méta-MCI \(MVP\)
[HS]
Un problème, découlant de l'informatique quantique, c'est que les qubits peuvent avoir une infinité d'états. Donc, l'entropie (de Shannon) quantique peut avoir n'importe quelle valeur, entre deux fois l'entropie classique et l'infini ; mais, ces "n'importe quelle valeurs" peuvent aussi être simultanées (superposées). Cela est important, car si on ne peut pas copier/dupliquer un qubit, on peut transporter son entropie. Beaucoup d'algorithmes quantiques sont basés sur ça.
@+
Michel Claveau
[HS]
Un problème, découlant de l'informatique quantique, c'est que les qubits
peuvent avoir une infinité d'états. Donc, l'entropie (de Shannon)
quantique peut avoir n'importe quelle valeur, entre deux fois l'entropie
classique et l'infini ; mais, ces "n'importe quelle valeurs" peuvent
aussi être simultanées (superposées).
Cela est important, car si on ne peut pas copier/dupliquer un qubit, on
peut transporter son entropie. Beaucoup d'algorithmes quantiques sont
basés sur ça.
Un problème, découlant de l'informatique quantique, c'est que les qubits peuvent avoir une infinité d'états. Donc, l'entropie (de Shannon) quantique peut avoir n'importe quelle valeur, entre deux fois l'entropie classique et l'infini ; mais, ces "n'importe quelle valeurs" peuvent aussi être simultanées (superposées). Cela est important, car si on ne peut pas copier/dupliquer un qubit, on peut transporter son entropie. Beaucoup d'algorithmes quantiques sont basés sur ça.
@+
Michel Claveau
William Dode
On 15-04-2008, Salvatore wrote:
Ce qui est très original dans ce framework c'est la facilité avec laquelle on installe et on déploie des applications 'bytecoted'. Tout ce fait à travers l'interface web.
Je viens d'essayer, et effectivement c'est assez bluffant, mais je reste dubitatif sur l'intérêt de ces frameworks qui font tout.
L'intérêt d'un framework c'est surtout quand on a soit une grosse appli à faire soit pleins de petites. Du coup on gagne du temps sur les choses qui se répètent. Il faut bien amortir le temps passé à apprendre le framework.
L'inconvénient c'est que la moindre modification du framework peut casser toutes les applis et de même les applis ne peuvent évoluer qu'en concordance avec le framework. Ce qui fait qu'au bout d'un moment plus rien ne peut évoluer sous peine de s'arracher les cheveux.
Du coup, paradoxalement le framework n'est intéressant que pour peu de petites applications, c'est pour ça que les démos sont très impressionnantes. Mais dans ce cas là, où est l'intérêt ?
En revanche, si on construit ses applis brique par brique, on passe certe un peu plus de temps à les assembler à chaque fois, mais on a beaucoup plus de liberté par la suite. Enfin c'est mon expérience du moins...
-- William Dodé - http://flibuste.net Informaticien indépendant
On 15-04-2008, Salvatore wrote:
Ce qui est très original dans ce framework c'est la facilité avec
laquelle on installe et on déploie des applications
'bytecoted'.
Tout ce fait à travers l'interface web.
Je viens d'essayer, et effectivement c'est assez bluffant, mais je reste
dubitatif sur l'intérêt de ces frameworks qui font tout.
L'intérêt d'un framework c'est surtout quand on a soit une grosse appli
à faire soit pleins de petites. Du coup on gagne du temps sur les choses
qui se répètent. Il faut bien amortir le temps passé à apprendre le
framework.
L'inconvénient c'est que la moindre modification du framework peut
casser toutes les applis et de même les applis ne peuvent évoluer qu'en
concordance avec le framework. Ce qui fait qu'au bout d'un moment plus
rien ne peut évoluer sous peine de s'arracher les cheveux.
Du coup, paradoxalement le framework n'est intéressant que pour peu de
petites applications, c'est pour ça que les démos sont très
impressionnantes. Mais dans ce cas là, où est l'intérêt ?
En revanche, si on construit ses applis brique par brique, on passe
certe un peu plus de temps à les assembler à chaque fois, mais on
a beaucoup plus de liberté par la suite. Enfin c'est mon expérience du
moins...
--
William Dodé - http://flibuste.net
Informaticien indépendant
Ce qui est très original dans ce framework c'est la facilité avec laquelle on installe et on déploie des applications 'bytecoted'. Tout ce fait à travers l'interface web.
Je viens d'essayer, et effectivement c'est assez bluffant, mais je reste dubitatif sur l'intérêt de ces frameworks qui font tout.
L'intérêt d'un framework c'est surtout quand on a soit une grosse appli à faire soit pleins de petites. Du coup on gagne du temps sur les choses qui se répètent. Il faut bien amortir le temps passé à apprendre le framework.
L'inconvénient c'est que la moindre modification du framework peut casser toutes les applis et de même les applis ne peuvent évoluer qu'en concordance avec le framework. Ce qui fait qu'au bout d'un moment plus rien ne peut évoluer sous peine de s'arracher les cheveux.
Du coup, paradoxalement le framework n'est intéressant que pour peu de petites applications, c'est pour ça que les démos sont très impressionnantes. Mais dans ce cas là, où est l'intérêt ?
En revanche, si on construit ses applis brique par brique, on passe certe un peu plus de temps à les assembler à chaque fois, mais on a beaucoup plus de liberté par la suite. Enfin c'est mon expérience du moins...
-- William Dodé - http://flibuste.net Informaticien indépendant
Salvatore
Et le chat de Shrödinger alors, il est mort ou vivant :-)
Et le chat de Shrödinger alors, il est mort ou vivant :-)
Et le chat de Shrödinger alors, il est mort ou vivant :-)
Salvatore
Je te remercie pour tes remarques, William. Pour ce qui me concerne je trouve ces frameworks, et particulièrement web2py ou Karrigell très pratiques,dans un environemenent où tu dois déployer rapidement des applications telles que des appli. de supervision par exemple.
web2py est très stable selon Marco, et il n'y devrait pas y avoir de modification majeure. Si c'est le cas, les anciennes applis. devraient tourner sans problèmes, c'est une assurance de l'auteur.
Cordialement
Salvatore
Je te remercie pour tes remarques, William.
Pour ce qui me concerne je trouve ces frameworks, et particulièrement
web2py ou Karrigell
très pratiques,dans un environemenent où tu dois déployer rapidement
des applications telles que des appli. de supervision par exemple.
web2py est très stable selon Marco, et il n'y devrait pas y avoir de
modification majeure.
Si c'est le cas, les anciennes applis. devraient tourner sans
problèmes, c'est une assurance de l'auteur.
Je te remercie pour tes remarques, William. Pour ce qui me concerne je trouve ces frameworks, et particulièrement web2py ou Karrigell très pratiques,dans un environemenent où tu dois déployer rapidement des applications telles que des appli. de supervision par exemple.
web2py est très stable selon Marco, et il n'y devrait pas y avoir de modification majeure. Si c'est le cas, les anciennes applis. devraient tourner sans problèmes, c'est une assurance de l'auteur.
Cordialement
Salvatore
Encolpe Degoute
Et le chat de Shrödinger alors, il est mort ou vivant :-)
La boîte ne comporte pas d'aération, il est forcément mort d'asphyxie. Il ne faut pas essayer de me faire avaler des couleuvres (faute de python).
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Et le chat de Shrödinger alors, il est mort ou vivant :-)
La boîte ne comporte pas d'aération, il est forcément mort d'asphyxie.
Il ne faut pas essayer de me faire avaler des couleuvres (faute de python).
--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales
Et le chat de Shrödinger alors, il est mort ou vivant :-)
La boîte ne comporte pas d'aération, il est forcément mort d'asphyxie. Il ne faut pas essayer de me faire avaler des couleuvres (faute de python).
-- Encolpe DEGOUTE http://encolpe.degoute.free.fr/ Logiciels libres, hockey sur glace et autres activités cérébrales
Méta-MCI \(MVP\)
Bonsoir !
Je suis assez d'accord avec William.
AMHA, un problème des frameworks, c'est que de nombreux choix ont déjà été faits. Du coup, on est obligé de s'y adapter. C'est très bien pour un débutant, mais pour des développeurs qui ont déjà fait certains choix différents (ou ont leurs propres librairies) cela peut être péjoratif.
Perso, pour le web, j'aime bien CherryPy, justement parce qu'il ne fait qu'une seule chose (l'interface/serveur Web). Et, pour le reste, on choisit les éléments que l'on veut ajouter (gestionnaires de templates, SGBD et liaisons, logique générale, mailing, etc.)
@+ -- Michel Claveau
Bonsoir !
Je suis assez d'accord avec William.
AMHA, un problème des frameworks, c'est que de nombreux choix ont déjà
été faits. Du coup, on est obligé de s'y adapter.
C'est très bien pour un débutant, mais pour des développeurs qui ont
déjà fait certains choix différents (ou ont leurs propres librairies)
cela peut être péjoratif.
Perso, pour le web, j'aime bien CherryPy, justement parce qu'il ne fait
qu'une seule chose (l'interface/serveur Web). Et, pour le reste, on
choisit les éléments que l'on veut ajouter (gestionnaires de templates,
SGBD et liaisons, logique générale, mailing, etc.)
AMHA, un problème des frameworks, c'est que de nombreux choix ont déjà été faits. Du coup, on est obligé de s'y adapter. C'est très bien pour un débutant, mais pour des développeurs qui ont déjà fait certains choix différents (ou ont leurs propres librairies) cela peut être péjoratif.
Perso, pour le web, j'aime bien CherryPy, justement parce qu'il ne fait qu'une seule chose (l'interface/serveur Web). Et, pour le reste, on choisit les éléments que l'on veut ajouter (gestionnaires de templates, SGBD et liaisons, logique générale, mailing, etc.)
web2py est très stable selon Marco, et il n'y devrait pas y avoir de modification majeure.
Quelque part, pas de modification majeure ça signifie que ça n'évoluera pas... Autant ce n'est pas génant et même très bien quand il s'agit d'une brique autant c'est assez génant quand ça implique que le reste ne pourra pas évoluer.
Par exemple la brique serveur, c'est très bien qu'elle ne bouge pas, par contre les briques interface d'admin où orm ça parait difficile de les figer.
Ceci dit, un framework n'est finalement qu'un assemblage de briques à un instant T (d'ailleur web2py utilise le serveur de cherrypy), et je me régale et apprend beaucoup en les étudiant.
-- William Dodé - http://flibuste.net Informaticien indépendant
On 15-04-2008, Salvatore wrote:
web2py est très stable selon Marco, et il n'y devrait pas y avoir de
modification majeure.
Quelque part, pas de modification majeure ça signifie que ça n'évoluera
pas... Autant ce n'est pas génant et même très bien quand il s'agit
d'une brique autant c'est assez génant quand ça implique que le reste ne
pourra pas évoluer.
Par exemple la brique serveur, c'est très bien qu'elle ne bouge pas, par
contre les briques interface d'admin où orm ça parait difficile de les
figer.
Ceci dit, un framework n'est finalement qu'un assemblage de briques à un
instant T (d'ailleur web2py utilise le serveur de cherrypy), et je me
régale et apprend beaucoup en les étudiant.
--
William Dodé - http://flibuste.net
Informaticien indépendant
web2py est très stable selon Marco, et il n'y devrait pas y avoir de modification majeure.
Quelque part, pas de modification majeure ça signifie que ça n'évoluera pas... Autant ce n'est pas génant et même très bien quand il s'agit d'une brique autant c'est assez génant quand ça implique que le reste ne pourra pas évoluer.
Par exemple la brique serveur, c'est très bien qu'elle ne bouge pas, par contre les briques interface d'admin où orm ça parait difficile de les figer.
Ceci dit, un framework n'est finalement qu'un assemblage de briques à un instant T (d'ailleur web2py utilise le serveur de cherrypy), et je me régale et apprend beaucoup en les étudiant.
-- William Dodé - http://flibuste.net Informaticien indépendant
Thierry B.
--{ Salvatore a plopé ceci: }--
Et le chat de Shrödinger alors, il est mort ou vivant :-)
En fait, il a droit à 18 demi-vies....
-- Prolétaire peut être pris historiquement et étymologiquement par "celui qui ne possède que ses enfants pour toute richesse". Statut ancien - il remonte à la Rome antique -
--{ Salvatore a plopé ceci: }--
Et le chat de Shrödinger alors, il est mort ou vivant :-)
En fait, il a droit à 18 demi-vies....
--
Prolétaire peut être pris historiquement et étymologiquement par "celui qui
ne possède que ses enfants pour toute richesse". Statut ancien - il remonte
à la Rome antique -
Et le chat de Shrödinger alors, il est mort ou vivant :-)
En fait, il a droit à 18 demi-vies....
-- Prolétaire peut être pris historiquement et étymologiquement par "celui qui ne possède que ses enfants pour toute richesse". Statut ancien - il remonte à la Rome antique -
