Il serait temps d'arrêter de faire du copier/coller... je m'explique...
Une part non négligeable de mes développement consiste à gérer des
formulaires pour entrées des informations et à mettre en place des
scripts permettant de retrouver les informations entrées dans la base de
données.
Concrêtement, je construit des formulaires dont les champs ont les mêmes
noms que ceux de la base de données, je les récupère et je les stoques.
De l'autre côté, je mets en place des requêtes (souvent les mêmes) pour
afficher les infos.
BREF : je fais beaucoup de copier/coller intelligents... enfin j'essaie
!
Il existe surement des outils logiciels pour gagner un peu de temps, non
? Je précise que je suis sur mac os x...
Merci.
--
Un moyen de garde pour vos enfants ?
http://www.easynounou.com
les insert. Lourd, mais redoutables. On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque
les classes PHP "mappant" les tables de la base sont épurées de tout code de gestion de la base. Je disais lourd pour la mémoire tout de même. On monte quasi toute la table
a chaque fois, c'est beaucoup plus gourmand en ressource qu'un système sql traditionnel programmé correctement...
Après c'est clair qu'il reste encore illusoire de vouloir mettre PHP et Java EE ou .NET au même niveau. Mais quand on voit ce qu'ils se prennent dans la tête face à des bolides comme Ruby on Rails... Ah ça....
J'aime bien Python, ceci dit. Ce serait moi, tout le monde en ferait au moins 6 mois durant leurs études. Ca leur apprendrait à indenter correctement : )))))))
Et surtout, ces technologies ont fait le choix de se comporter en serveur d'application : c'est à dire qu'une partie de l'application est constament en mémoire, ce qui évite par exemple de reloader la base pour chaque utlisateur. Cela comporte un certain nombre de conséquences. Mais il n'est pas certain que les avantages sous une plate-forme PHP soient équivalents. Qu'est-ce que tu entends par "conséquences" ?
La facon de programmer certaines choses n'est pas la même sous un "serveur d'application"..... Il y a quelques avantages à avoir accès à un espace mémoire commun à l'application, un autre au request, et un troisième à la session !
Quand aux perf, je n'en parlerais pas. Je réserverais même les commentaires sur mes crises de rire devant le temps mis pour développer certains écrans d'application J2EE n-tiers découpées à grand coup d'EJB, le tout en Localhost. C'est un autre problème. :))))
Je me prends pourtant parfois à rêver d'avoir accès a ce genre de technologies sans avoir à me prendre la tête à faire du boxing et du casting redondant en permanence. Pour cela, mon avis est tranché, PHP est le meilleurs. Le gain de temps est incomparable...... J'aime à dire que ce sont ses petits défauts qui font toute la richesse de
PHP :). Sa facilité d'accès mais son incroyable puissance quand on s'y penche de prêt.
Ah mais je suis ok ! Je suis tombé dedans depuis 1999, et à chaque fois, il n'y a rien à faire, j'y reviens......
comme tu sembles aimer voir ce qu'il se passe ailleurs.
Oui. Durant longtemps, j'ai été partisan du choix de préférer devenir expert dans une technologie que de prendre le risque de devenir moyen dans plusieurs. Je pense que c'était une erreur. Et puis "expert", hein, ça veut dire quoi.......
Il n'y a pas que Java et .NET de l'autre côté du rivage :)
C'est vrai. Mais c'est pas mal d'aller passer un peu de temps, parfois, pour voir les bonnes idées que forcément, ils ont parfois.... Très humblement, je pense que cela m'a fait beaucoup de bien. Je sais maintenant que j'ai encore plus de choses à apprendre et à compléter que je ne le pensais : )
@++
Stef
les insert. Lourd, mais redoutables.
On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque
les classes PHP "mappant" les tables de la base sont épurées de tout code
de
gestion de la base.
Je disais lourd pour la mémoire tout de même. On monte quasi toute la table
a chaque fois, c'est beaucoup plus gourmand en ressource qu'un système sql
traditionnel programmé correctement...
Après c'est clair qu'il reste encore illusoire de vouloir mettre PHP et
Java
EE ou .NET au même niveau. Mais quand on voit ce qu'ils se prennent dans
la
tête face à des bolides comme Ruby on Rails...
Ah ça....
J'aime bien Python, ceci dit. Ce serait moi, tout le monde en ferait au
moins 6 mois durant leurs études. Ca leur apprendrait à indenter
correctement : )))))))
Et surtout, ces technologies ont fait le choix de se comporter en
serveur d'application : c'est à dire qu'une partie de l'application
est constament en mémoire, ce qui évite par exemple de reloader la
base pour chaque utlisateur. Cela comporte un certain nombre de
conséquences. Mais il n'est pas certain que les avantages sous une
plate-forme PHP soient équivalents.
Qu'est-ce que tu entends par "conséquences" ?
La facon de programmer certaines choses n'est pas la même sous un "serveur
d'application"..... Il y a quelques avantages à avoir accès à un espace
mémoire commun à l'application, un autre au request, et un troisième à la
session !
Quand aux perf, je n'en parlerais pas. Je réserverais même les commentaires
sur mes crises de rire devant le temps mis pour développer certains écrans
d'application J2EE n-tiers découpées à grand coup d'EJB, le tout en
Localhost. C'est un autre problème. :))))
Je me prends pourtant parfois à rêver d'avoir accès a ce genre de
technologies sans avoir à me prendre la tête à faire du boxing et du
casting redondant en permanence. Pour cela, mon avis est tranché, PHP
est le meilleurs. Le gain de temps est incomparable......
J'aime à dire que ce sont ses petits défauts qui font toute la richesse de
PHP :). Sa facilité d'accès mais son incroyable puissance quand on s'y
penche de prêt.
Ah mais je suis ok ! Je suis tombé dedans depuis 1999, et à chaque fois, il
n'y a rien à faire, j'y reviens......
comme tu sembles aimer voir ce qu'il se passe ailleurs.
Oui. Durant longtemps, j'ai été partisan du choix de préférer devenir expert
dans une technologie que de prendre le risque de devenir moyen dans
plusieurs. Je pense que c'était une erreur. Et puis "expert", hein, ça veut
dire quoi.......
Il n'y a pas que
Java et .NET de l'autre côté du rivage :)
C'est vrai. Mais c'est pas mal d'aller passer un peu de temps, parfois, pour
voir les bonnes idées que forcément, ils ont parfois.... Très humblement, je
pense que cela m'a fait beaucoup de bien. Je sais maintenant que j'ai encore
plus de choses à apprendre et à compléter que je ne le pensais : )
les insert. Lourd, mais redoutables. On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque
les classes PHP "mappant" les tables de la base sont épurées de tout code de gestion de la base. Je disais lourd pour la mémoire tout de même. On monte quasi toute la table
a chaque fois, c'est beaucoup plus gourmand en ressource qu'un système sql traditionnel programmé correctement...
Après c'est clair qu'il reste encore illusoire de vouloir mettre PHP et Java EE ou .NET au même niveau. Mais quand on voit ce qu'ils se prennent dans la tête face à des bolides comme Ruby on Rails... Ah ça....
J'aime bien Python, ceci dit. Ce serait moi, tout le monde en ferait au moins 6 mois durant leurs études. Ca leur apprendrait à indenter correctement : )))))))
Et surtout, ces technologies ont fait le choix de se comporter en serveur d'application : c'est à dire qu'une partie de l'application est constament en mémoire, ce qui évite par exemple de reloader la base pour chaque utlisateur. Cela comporte un certain nombre de conséquences. Mais il n'est pas certain que les avantages sous une plate-forme PHP soient équivalents. Qu'est-ce que tu entends par "conséquences" ?
La facon de programmer certaines choses n'est pas la même sous un "serveur d'application"..... Il y a quelques avantages à avoir accès à un espace mémoire commun à l'application, un autre au request, et un troisième à la session !
Quand aux perf, je n'en parlerais pas. Je réserverais même les commentaires sur mes crises de rire devant le temps mis pour développer certains écrans d'application J2EE n-tiers découpées à grand coup d'EJB, le tout en Localhost. C'est un autre problème. :))))
Je me prends pourtant parfois à rêver d'avoir accès a ce genre de technologies sans avoir à me prendre la tête à faire du boxing et du casting redondant en permanence. Pour cela, mon avis est tranché, PHP est le meilleurs. Le gain de temps est incomparable...... J'aime à dire que ce sont ses petits défauts qui font toute la richesse de
PHP :). Sa facilité d'accès mais son incroyable puissance quand on s'y penche de prêt.
Ah mais je suis ok ! Je suis tombé dedans depuis 1999, et à chaque fois, il n'y a rien à faire, j'y reviens......
comme tu sembles aimer voir ce qu'il se passe ailleurs.
Oui. Durant longtemps, j'ai été partisan du choix de préférer devenir expert dans une technologie que de prendre le risque de devenir moyen dans plusieurs. Je pense que c'était une erreur. Et puis "expert", hein, ça veut dire quoi.......
Il n'y a pas que Java et .NET de l'autre côté du rivage :)
C'est vrai. Mais c'est pas mal d'aller passer un peu de temps, parfois, pour voir les bonnes idées que forcément, ils ont parfois.... Très humblement, je pense que cela m'a fait beaucoup de bien. Je sais maintenant que j'ai encore plus de choses à apprendre et à compléter que je ne le pensais : )
@++
Stef
slambert
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli python (principalement pour des problèmes de peur et/ou maintenance)
Moyennement d'accord. Ici, Python est très a la mode. Par exemple , Google l'utilise beaucoup. Il faut dire qu'ils ont embauché Guido van Rossum...... Mais ce sont loin d'etre les seuls !
Stef
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli
python (principalement pour des problèmes de peur et/ou maintenance)
Moyennement d'accord. Ici, Python est très a la mode. Par exemple , Google
l'utilise beaucoup. Il faut dire qu'ils ont embauché Guido van Rossum......
Mais ce sont loin d'etre les seuls !
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli python (principalement pour des problèmes de peur et/ou maintenance)
Moyennement d'accord. Ici, Python est très a la mode. Par exemple , Google l'utilise beaucoup. Il faut dire qu'ils ont embauché Guido van Rossum...... Mais ce sont loin d'etre les seuls !
Stef
Nicolas Le Gal
Peut-être en construisant une bibliothèque de tes requêtes et variables courantes, bref, par la programmation orientée objet. Même si ton script est pas très complexe, si tu dois retaper chaque fois, ça te permettrait déjà de réduire considérablement ton code. Une première classe (MySQL) pour te connecter à la base de donnée. La classe MySQLquery extends MySQL qui hérite des méthodes et variables de MySQL dont le constructeur déifnit tes variables de formule (qui sont aussi des champs de table MySQL).
Peut-être en construisant une bibliothèque de tes requêtes et variables
courantes, bref, par la programmation orientée objet.
Même si ton script est pas très complexe, si tu dois retaper chaque fois, ça
te permettrait déjà de réduire considérablement ton code.
Une première classe (MySQL) pour te connecter à la base de donnée.
La classe MySQLquery extends MySQL qui hérite des méthodes et variables de
MySQL dont le constructeur déifnit tes variables de formule (qui sont aussi
des champs de table MySQL).
Peut-être en construisant une bibliothèque de tes requêtes et variables courantes, bref, par la programmation orientée objet. Même si ton script est pas très complexe, si tu dois retaper chaque fois, ça te permettrait déjà de réduire considérablement ton code. Une première classe (MySQL) pour te connecter à la base de donnée. La classe MySQLquery extends MySQL qui hérite des méthodes et variables de MySQL dont le constructeur déifnit tes variables de formule (qui sont aussi des champs de table MySQL).
Lionel
slambert wrote:
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli python (principalement pour des problèmes de peur et/ou maintenance)
Moyennement d'accord. Ici, Python est très a la mode. Par exemple , Google l'utilise beaucoup. Il faut dire qu'ils ont embauché Guido van Rossum...... Mais ce sont loin d'etre les seuls !
J'aurais du préciser le type de client, car des exemples représentant 1/1000e des clients existants en France, tu peux m'en sortir plusieurs: celui qui héberge ton appli, achète ton code source et qui est susceptible (en cas de défaillance de ta part ou disparition de ta boite) de reprendre le bébé soit pour le maintenir en interne, soit pour le refiler à un autre presta. Et là, une boite classique (pas google ou IBM, hein) dont la moitié des codeurs fait du cobol, l'autre du VB, avec qq connaissances (pages perso) en php, refusera quasi systématiquement python. Déjà java ça passe pas toujours dans ce genre de cas, alors python, c'est meme pas la peine. Evidemment, dans le cas d'appli hébergée par le presta, la question ne se pose pas.
slambert wrote:
ce qui est un fait, c'est que beaucoup d'entreprises refusent les
appli python (principalement pour des problèmes de peur et/ou
maintenance)
Moyennement d'accord. Ici, Python est très a la mode. Par exemple ,
Google l'utilise beaucoup. Il faut dire qu'ils ont embauché Guido van
Rossum...... Mais ce sont loin d'etre les seuls !
J'aurais du préciser le type de client, car des exemples représentant
1/1000e des clients existants en France, tu peux m'en sortir plusieurs:
celui qui héberge ton appli, achète ton code source et qui est susceptible
(en cas de défaillance de ta part ou disparition de ta boite) de reprendre
le bébé soit pour le maintenir en interne, soit pour le refiler à un autre
presta.
Et là, une boite classique (pas google ou IBM, hein) dont la moitié des
codeurs fait du cobol, l'autre du VB, avec qq connaissances (pages perso) en
php, refusera quasi systématiquement python.
Déjà java ça passe pas toujours dans ce genre de cas, alors python, c'est
meme pas la peine.
Evidemment, dans le cas d'appli hébergée par le presta, la question ne se
pose pas.
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli python (principalement pour des problèmes de peur et/ou maintenance)
Moyennement d'accord. Ici, Python est très a la mode. Par exemple , Google l'utilise beaucoup. Il faut dire qu'ils ont embauché Guido van Rossum...... Mais ce sont loin d'etre les seuls !
J'aurais du préciser le type de client, car des exemples représentant 1/1000e des clients existants en France, tu peux m'en sortir plusieurs: celui qui héberge ton appli, achète ton code source et qui est susceptible (en cas de défaillance de ta part ou disparition de ta boite) de reprendre le bébé soit pour le maintenir en interne, soit pour le refiler à un autre presta. Et là, une boite classique (pas google ou IBM, hein) dont la moitié des codeurs fait du cobol, l'autre du VB, avec qq connaissances (pages perso) en php, refusera quasi systématiquement python. Déjà java ça passe pas toujours dans ce genre de cas, alors python, c'est meme pas la peine. Evidemment, dans le cas d'appli hébergée par le presta, la question ne se pose pas.
slambert
J'aurais du préciser le type de client, car des exemples représentant 1/1000e des clients existants en France, tu peux m'en sortir plusieurs:
Ah, désolé, je ne parlais pas du marché Francais.
Mais c'est vrai que Google n'est pas une entreprise "standard".
Les autres exemples qui me viennent tout de suite à l'esprit en ce qui concerne Python sont des entreprises développant leur propre SI en interne. Ce ne sont effectivement pas des prestataires....
Et oui, effectivement, Python n'est visiblement pas la technologie principale du marché du développement. Cela reste tout de meme assez minoritaire, meme si je vois régulièrement passer des offres d'emplois sur cette techno.
@++
Stef
J'aurais du préciser le type de client, car des exemples représentant
1/1000e des clients existants en France, tu peux m'en sortir plusieurs:
Ah, désolé, je ne parlais pas du marché Francais.
Mais c'est vrai que Google n'est pas une entreprise "standard".
Les autres exemples qui me viennent tout de suite à l'esprit en ce qui
concerne Python sont des entreprises développant leur propre SI en interne.
Ce ne sont effectivement pas des prestataires....
Et oui, effectivement, Python n'est visiblement pas la technologie
principale du marché du développement. Cela reste tout de meme assez
minoritaire, meme si je vois régulièrement passer des offres d'emplois sur
cette techno.
J'aurais du préciser le type de client, car des exemples représentant 1/1000e des clients existants en France, tu peux m'en sortir plusieurs:
Ah, désolé, je ne parlais pas du marché Francais.
Mais c'est vrai que Google n'est pas une entreprise "standard".
Les autres exemples qui me viennent tout de suite à l'esprit en ce qui concerne Python sont des entreprises développant leur propre SI en interne. Ce ne sont effectivement pas des prestataires....
Et oui, effectivement, Python n'est visiblement pas la technologie principale du marché du développement. Cela reste tout de meme assez minoritaire, meme si je vois régulièrement passer des offres d'emplois sur cette techno.
@++
Stef
Bruno Desthuilliers
J'aurais du préciser le type de client, car des exemples représentant 1/1000e des clients existants en France, tu peux m'en sortir plusieurs:
Ah, désolé, je ne parlais pas du marché Francais.
Mais c'est vrai que Google n'est pas une entreprise "standard".
Les autres exemples qui me viennent tout de suite à l'esprit en ce qui concerne Python sont des entreprises développant leur propre SI en interne. Ce ne sont effectivement pas des prestataires....
Et oui, effectivement, Python n'est visiblement pas la technologie principale du marché du développement. Cela reste tout de meme assez minoritaire, meme si je vois régulièrement passer des offres d'emplois sur cette techno.
<troll> Un des problèmes avec Python, c'est que vu la productivité moyenne comparée à une usine à gaz Java, les grosses SSII on du mal à justifier leurs tarifs (et les DRI leurs budgets - or chez les grands comptes, le plus important n'est pas le résultat mais la quantité de fric cramée).
Accessoirement aussi, Python n'étant encore que marginalement enseigné, les développeurs compétents dans ce langage sont non seulement des oiseaux rares, mais surtout des passionnés - donc pas *du tout* le type de profil que recrutent les grosses SSII (et d'ailleurs pas non plus le profil à vouloir travailler dans une grosse SSII). </troll>
Ceci étant, Python (et Ruby) gagnent du terrain petit à petit.
J'aurais du préciser le type de client, car des exemples représentant
1/1000e des clients existants en France, tu peux m'en sortir plusieurs:
Ah, désolé, je ne parlais pas du marché Francais.
Mais c'est vrai que Google n'est pas une entreprise "standard".
Les autres exemples qui me viennent tout de suite à l'esprit en ce qui
concerne Python sont des entreprises développant leur propre SI en interne.
Ce ne sont effectivement pas des prestataires....
Et oui, effectivement, Python n'est visiblement pas la technologie
principale du marché du développement. Cela reste tout de meme assez
minoritaire, meme si je vois régulièrement passer des offres d'emplois sur
cette techno.
<troll>
Un des problèmes avec Python, c'est que vu la productivité moyenne
comparée à une usine à gaz Java, les grosses SSII on du mal à justifier
leurs tarifs (et les DRI leurs budgets - or chez les grands comptes, le
plus important n'est pas le résultat mais la quantité de fric cramée).
Accessoirement aussi, Python n'étant encore que marginalement enseigné,
les développeurs compétents dans ce langage sont non seulement des
oiseaux rares, mais surtout des passionnés - donc pas *du tout* le type
de profil que recrutent les grosses SSII (et d'ailleurs pas non plus le
profil à vouloir travailler dans une grosse SSII).
</troll>
Ceci étant, Python (et Ruby) gagnent du terrain petit à petit.
J'aurais du préciser le type de client, car des exemples représentant 1/1000e des clients existants en France, tu peux m'en sortir plusieurs:
Ah, désolé, je ne parlais pas du marché Francais.
Mais c'est vrai que Google n'est pas une entreprise "standard".
Les autres exemples qui me viennent tout de suite à l'esprit en ce qui concerne Python sont des entreprises développant leur propre SI en interne. Ce ne sont effectivement pas des prestataires....
Et oui, effectivement, Python n'est visiblement pas la technologie principale du marché du développement. Cela reste tout de meme assez minoritaire, meme si je vois régulièrement passer des offres d'emplois sur cette techno.
<troll> Un des problèmes avec Python, c'est que vu la productivité moyenne comparée à une usine à gaz Java, les grosses SSII on du mal à justifier leurs tarifs (et les DRI leurs budgets - or chez les grands comptes, le plus important n'est pas le résultat mais la quantité de fric cramée).
Accessoirement aussi, Python n'étant encore que marginalement enseigné, les développeurs compétents dans ce langage sont non seulement des oiseaux rares, mais surtout des passionnés - donc pas *du tout* le type de profil que recrutent les grosses SSII (et d'ailleurs pas non plus le profil à vouloir travailler dans une grosse SSII). </troll>
Ceci étant, Python (et Ruby) gagnent du terrain petit à petit.
Bruno Desthuilliers
les insert. Lourd, mais redoutables.
On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque les classes PHP "mappant" les tables de la base sont épurées de tout code de gestion de la base.
Je disais lourd pour la mémoire tout de même. On monte quasi toute la table a chaque fois,
Alors mauvais ORM, à jeter. Le fonctionnement que tu décris n'est en rien constitutif d'un ORM - c'est juste une erreur de conception.
c'est beaucoup plus gourmand en ressource qu'un système sql traditionnel programmé correctement...
Insistons bien sur le "programmé correctement". J'ai vu pas mal d'horreurs dans des applis PHP/MySQL sans ORM (du genre "select * " suivi d'une boucle pour compter les enregistrements... Non non, je n'invente pas).
(snip)
les insert. Lourd, mais redoutables.
On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque
les classes PHP "mappant" les tables de la base sont épurées de tout code
de
gestion de la base.
Je disais lourd pour la mémoire tout de même. On monte quasi toute la table
a chaque fois,
Alors mauvais ORM, à jeter. Le fonctionnement que tu décris n'est en
rien constitutif d'un ORM - c'est juste une erreur de conception.
c'est beaucoup plus gourmand en ressource qu'un système sql
traditionnel programmé correctement...
Insistons bien sur le "programmé correctement". J'ai vu pas mal
d'horreurs dans des applis PHP/MySQL sans ORM (du genre "select * "
suivi d'une boucle pour compter les enregistrements... Non non, je
n'invente pas).
On parle d'Object Relational Mapping (ORM). C'est tout sauf lourd puisque les classes PHP "mappant" les tables de la base sont épurées de tout code de gestion de la base.
Je disais lourd pour la mémoire tout de même. On monte quasi toute la table a chaque fois,
Alors mauvais ORM, à jeter. Le fonctionnement que tu décris n'est en rien constitutif d'un ORM - c'est juste une erreur de conception.
c'est beaucoup plus gourmand en ressource qu'un système sql traditionnel programmé correctement...
Insistons bien sur le "programmé correctement". J'ai vu pas mal d'horreurs dans des applis PHP/MySQL sans ORM (du genre "select * " suivi d'une boucle pour compter les enregistrements... Non non, je n'invente pas).
(snip)
Bruno Desthuilliers
(snip)
Oui, RoR pour les démos c'est génial. Mais en prod, avec plus de deux utilisateurs simultanés, apparemment certains en reviennent... Je n'ai pas encore investigué personnellement, donc je ne ferai pas plus de commentaire. ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli python (principalement pour des problèmes de peur et/ou maintenance)
Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?
(snip)
Oui, RoR pour les démos c'est génial.
Mais en prod, avec plus de deux utilisateurs simultanés, apparemment
certains en reviennent...
Je n'ai pas encore investigué personnellement, donc je ne ferai pas plus de
commentaire.
ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli
python (principalement pour des problèmes de peur et/ou maintenance)
Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?
Oui, RoR pour les démos c'est génial. Mais en prod, avec plus de deux utilisateurs simultanés, apparemment certains en reviennent... Je n'ai pas encore investigué personnellement, donc je ne ferai pas plus de commentaire. ce qui est un fait, c'est que beaucoup d'entreprises refusent les appli python (principalement pour des problèmes de peur et/ou maintenance)
Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?
Lionel
Bruno Desthuilliers wrote:
Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?
Ils ont les mêmes qualités et les mêmes inconvénients qui font qu'il ne remplaceront pas java.
Bruno Desthuilliers wrote:
Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?
Ils ont les mêmes qualités et les mêmes inconvénients qui font qu'il ne
remplaceront pas java.
Heu... Tu nous expliquera le rapport entre *Ruby* on Rails et Python ?
Ils ont les mêmes qualités et les mêmes inconvénients qui font qu'il ne remplaceront pas java.
Lionel
Bruno Desthuilliers wrote:
Je disais lourd pour la mémoire tout de même. On monte quasi toute la table a chaque fois,
Alors mauvais ORM, à jeter. Le fonctionnement que tu décris n'est en rien constitutif d'un ORM - c'est juste une erreur de conception.
Ce n'est pas parce que l'on ne sait pas bien se servir d'un ORM qu'il est à jeter :)
Insistons bien sur le "programmé correctement". J'ai vu pas mal d'horreurs dans des applis PHP/MySQL sans ORM
Je pense qu'il y a autant d'horreurs avec ORM que sans ORM. Le problème est qu'avec un ORM, on peut très vite faire des choses pires qu'en SQL à la main sans le savoir.
Exemple avec hibernate: pour qu'une requete SQL se transforme en plusieurs milliers de requetes, il suffit de se planter dans la configuration d'un paramètre dans un fichier XML. Celui qui code sans regarder les requetes SQL exécutée ne le verra jamais.
Bruno Desthuilliers wrote:
Je disais lourd pour la mémoire tout de même. On monte quasi toute
la table a chaque fois,
Alors mauvais ORM, à jeter. Le fonctionnement que tu décris n'est en
rien constitutif d'un ORM - c'est juste une erreur de conception.
Ce n'est pas parce que l'on ne sait pas bien se servir d'un ORM qu'il est à
jeter :)
Insistons bien sur le "programmé correctement". J'ai vu pas mal
d'horreurs dans des applis PHP/MySQL sans ORM
Je pense qu'il y a autant d'horreurs avec ORM que sans ORM.
Le problème est qu'avec un ORM, on peut très vite faire des choses pires
qu'en SQL à la main sans le savoir.
Exemple avec hibernate: pour qu'une requete SQL se transforme en plusieurs
milliers de requetes, il suffit de se planter dans la configuration d'un
paramètre dans un fichier XML. Celui qui code sans regarder les requetes SQL
exécutée ne le verra jamais.
Je disais lourd pour la mémoire tout de même. On monte quasi toute la table a chaque fois,
Alors mauvais ORM, à jeter. Le fonctionnement que tu décris n'est en rien constitutif d'un ORM - c'est juste une erreur de conception.
Ce n'est pas parce que l'on ne sait pas bien se servir d'un ORM qu'il est à jeter :)
Insistons bien sur le "programmé correctement". J'ai vu pas mal d'horreurs dans des applis PHP/MySQL sans ORM
Je pense qu'il y a autant d'horreurs avec ORM que sans ORM. Le problème est qu'avec un ORM, on peut très vite faire des choses pires qu'en SQL à la main sans le savoir.
Exemple avec hibernate: pour qu'une requete SQL se transforme en plusieurs milliers de requetes, il suffit de se planter dans la configuration d'un paramètre dans un fichier XML. Celui qui code sans regarder les requetes SQL exécutée ne le verra jamais.
