ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p3306)
ça n'est pas tout à fait vrai: disons plutôt tant que les programmeurs php
ne contrôleront correctement ni leurs morceaux de code ni les droits des
fichiers & directories.
Mais au risque de me répéter, la meilleure parade reste d'inclure le code
"actif" dans la DB (procs stockées); mais je doute qu'à ce jour ce soit facile
(voire même possible à 100%) avec mysql.
ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p3306)
ça n'est pas tout à fait vrai: disons plutôt tant que les programmeurs php
ne contrôleront correctement ni leurs morceaux de code ni les droits des
fichiers & directories.
Mais au risque de me répéter, la meilleure parade reste d'inclure le code
"actif" dans la DB (procs stockées); mais je doute qu'à ce jour ce soit facile
(voire même possible à 100%) avec mysql.
ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p3306)
ça n'est pas tout à fait vrai: disons plutôt tant que les programmeurs php
ne contrôleront correctement ni leurs morceaux de code ni les droits des
fichiers & directories.
Mais au risque de me répéter, la meilleure parade reste d'inclure le code
"actif" dans la DB (procs stockées); mais je doute qu'à ce jour ce soit facile
(voire même possible à 100%) avec mysql.
Le cÅur même de PHP est totalement délirant en matièr e de bonnes pratiques :
â API hétérogènes et mouvantes,
â Intégration d'une foultitude de « librairies » d irectement dans le core
â Paramétrage hérétique (magic_quote_gpc ><),
â Aucun respect d'une quelconque de normes de codage,
Même le PHP Engine n'est pas thread-safe et plombe Apache (pre-fork au
lieu de worker) ou incite à l'ultra-crade-pas-sécurisé (fa st-cgi).
> Mais au risque de me répéter, la meilleure parade reste d'inc lure le code
> "actif" dans la DB (procs stockées); mais je doute qu'à ce jo ur ce soit
> facile (voire même possible à 100%) avec mysql.
C'est extrème comme solution, et totalement innapplicable sur une
application digne de ce nom, que cela soit en PHP ou non et MySQL ou non.
Tu imagines le nombre de stored-proc nécessaires ?
De toutes les
variantes de paramètres et/ou de sorties différentes ?
Du coût monstrueux de maintenance d'un tel système ?
Et qu'une telle application serait figée dans le marbre à jamai s, toute
évolution future étant vouée à l'échec ?
Le cÅur même de PHP est totalement délirant en matièr e de bonnes pratiques :
â API hétérogènes et mouvantes,
â Intégration d'une foultitude de « librairies » d irectement dans le core
â Paramétrage hérétique (magic_quote_gpc ><),
â Aucun respect d'une quelconque de normes de codage,
Même le PHP Engine n'est pas thread-safe et plombe Apache (pre-fork au
lieu de worker) ou incite à l'ultra-crade-pas-sécurisé (fa st-cgi).
> Mais au risque de me répéter, la meilleure parade reste d'inc lure le code
> "actif" dans la DB (procs stockées); mais je doute qu'à ce jo ur ce soit
> facile (voire même possible à 100%) avec mysql.
C'est extrème comme solution, et totalement innapplicable sur une
application digne de ce nom, que cela soit en PHP ou non et MySQL ou non.
Tu imagines le nombre de stored-proc nécessaires ?
De toutes les
variantes de paramètres et/ou de sorties différentes ?
Du coût monstrueux de maintenance d'un tel système ?
Et qu'une telle application serait figée dans le marbre à jamai s, toute
évolution future étant vouée à l'échec ?
Le cÅur même de PHP est totalement délirant en matièr e de bonnes pratiques :
â API hétérogènes et mouvantes,
â Intégration d'une foultitude de « librairies » d irectement dans le core
â Paramétrage hérétique (magic_quote_gpc ><),
â Aucun respect d'une quelconque de normes de codage,
Même le PHP Engine n'est pas thread-safe et plombe Apache (pre-fork au
lieu de worker) ou incite à l'ultra-crade-pas-sécurisé (fa st-cgi).
> Mais au risque de me répéter, la meilleure parade reste d'inc lure le code
> "actif" dans la DB (procs stockées); mais je doute qu'à ce jo ur ce soit
> facile (voire même possible à 100%) avec mysql.
C'est extrème comme solution, et totalement innapplicable sur une
application digne de ce nom, que cela soit en PHP ou non et MySQL ou non.
Tu imagines le nombre de stored-proc nécessaires ?
De toutes les
variantes de paramètres et/ou de sorties différentes ?
Du coût monstrueux de maintenance d'un tel système ?
Et qu'une telle application serait figée dans le marbre à jamai s, toute
évolution future étant vouée à l'échec ?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/09/2011 00:40, Jean-Yves F. Barbier a écrit :
> ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p33 06)
Ce qui n'est pas recommandable effectivement, mais qui ne semble pas le
vecteur de ce piratage.
> ça n'est pas tout à fait vrai: disons plutôt tant que les program meurs php
> ne contrôleront correctement ni leurs morceaux de code ni les droits des
> fichiers & directories.
Certes, mais PHP ne fait rien pour inciter à du code propre et à de
belles applications.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/09/2011 00:40, Jean-Yves F. Barbier a écrit :
> ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p33 06)
Ce qui n'est pas recommandable effectivement, mais qui ne semble pas le
vecteur de ce piratage.
> ça n'est pas tout à fait vrai: disons plutôt tant que les program meurs php
> ne contrôleront correctement ni leurs morceaux de code ni les droits des
> fichiers & directories.
Certes, mais PHP ne fait rien pour inciter à du code propre et à de
belles applications.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 17/09/2011 00:40, Jean-Yves F. Barbier a écrit :
> ben, d'après ce qu'il dit l'accès vers le svr mysql est ouvert (p33 06)
Ce qui n'est pas recommandable effectivement, mais qui ne semble pas le
vecteur de ce piratage.
> ça n'est pas tout à fait vrai: disons plutôt tant que les program meurs php
> ne contrôleront correctement ni leurs morceaux de code ni les droits des
> fichiers & directories.
Certes, mais PHP ne fait rien pour inciter à du code propre et à de
belles applications.
Moins que tu ne penses: je bosse ces temps-ci avec des procs polymorphes qui
effectuent elles-même leurs propres contrôles sur tables et colonnes
de l'autre on gagne une malléabilité énorme et l'abstraction par rapport
aux données;
La maintenance n'est pas plus lourde que pour un pgm en php, voire plus légère,
> De toutes les
> variantes de paramètres et/ou de sorties différentes ?
Non: il est relativement aisé d'écrire une proc polymorphe qui ne retourne que
les colonnes autorisées (ou renvoie une erreur si pas d'autorisation).
Pas plus que des centaines de petits morceaux de code d'un pgm en php, voire
même moins puisque chaque proc a une fonction bien déterminée (quitte à avoir
un peu de redondance dans le code afin d'éviter le morcellement).
Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre greper
dans des centaines de bouts de code php pour s'y retrouver et modifier ces
morceaux comme voulu, et modifier directement une ou des procs stockées dans
la DB?
À part les langages différents et surtout le fait que le contrôle total
des données soit dévolu à la DB et non-plus à du code externe, je ne vois pas
où se trouve le différentiel de maintenance.
Moins que tu ne penses: je bosse ces temps-ci avec des procs polymorphes qui
effectuent elles-même leurs propres contrôles sur tables et colonnes
de l'autre on gagne une malléabilité énorme et l'abstraction par rapport
aux données;
La maintenance n'est pas plus lourde que pour un pgm en php, voire plus légère,
> De toutes les
> variantes de paramètres et/ou de sorties différentes ?
Non: il est relativement aisé d'écrire une proc polymorphe qui ne retourne que
les colonnes autorisées (ou renvoie une erreur si pas d'autorisation).
Pas plus que des centaines de petits morceaux de code d'un pgm en php, voire
même moins puisque chaque proc a une fonction bien déterminée (quitte à avoir
un peu de redondance dans le code afin d'éviter le morcellement).
Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre greper
dans des centaines de bouts de code php pour s'y retrouver et modifier ces
morceaux comme voulu, et modifier directement une ou des procs stockées dans
la DB?
À part les langages différents et surtout le fait que le contrôle total
des données soit dévolu à la DB et non-plus à du code externe, je ne vois pas
où se trouve le différentiel de maintenance.
Moins que tu ne penses: je bosse ces temps-ci avec des procs polymorphes qui
effectuent elles-même leurs propres contrôles sur tables et colonnes
de l'autre on gagne une malléabilité énorme et l'abstraction par rapport
aux données;
La maintenance n'est pas plus lourde que pour un pgm en php, voire plus légère,
> De toutes les
> variantes de paramètres et/ou de sorties différentes ?
Non: il est relativement aisé d'écrire une proc polymorphe qui ne retourne que
les colonnes autorisées (ou renvoie une erreur si pas d'autorisation).
Pas plus que des centaines de petits morceaux de code d'un pgm en php, voire
même moins puisque chaque proc a une fonction bien déterminée (quitte à avoir
un peu de redondance dans le code afin d'éviter le morcellement).
Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre greper
dans des centaines de bouts de code php pour s'y retrouver et modifier ces
morceaux comme voulu, et modifier directement une ou des procs stockées dans
la DB?
À part les langages différents et surtout le fait que le contrôle total
des données soit dévolu à la DB et non-plus à du code externe, je ne vois pas
où se trouve le différentiel de maintenance.
Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
Je serais intéressé par un exemple, là comme ça je ne vois pasâ¦
Comment peut-on gérer par procédure stockée le fait que le s arguments
peuvent être variable (tri par date *OU* par nom), avoir des
comportements différents (nombre de post dans un topic, puis liste d es
topics, puis liste des posts du topic joint avec la table des auteurs),
ou retourner des valeurs différentes (dans les cas précéde nts, un
nombre, une liste de topic, une liste de (post + auteur)) ?
Sans exponentiation du nombre de stored-proc et/ou de leur complexità ©,
j'ai du mal à concevoirâ¦
> de l'autre on gagne une malléabilité énorme et l'abstrac tion par rapport
> aux données;
Là aussi, je bloqueâ¦
à la moindre modif des fonctionnalitées et/ou de la structure de
données, j'imagine assez mal comment on peut éviter un refactor ing
monstrueux du nombre tout aussi monstrueux des stored-proc.
Par exemple avec l'exemple des topics précédents, le fait de ra jouter
une date de publication à un post par exemple, nécessite a mini ma
d'ajouter encore X stored-procs pour pouvoir gérer les filtres et les
tris sur cette colonne, de refondre Y stored-procs pour ajouter cette
date en données de sortie, etc.
> La maintenance n'est pas plus lourde que pour un pgm en php, voire plus
> légère,
Si on arrive à m'expliquer les points ci-dessus, OK, pourquoi pas⠦
Pour l'avoir déjà expérimenté sur un projet où l a contrainte cliente
était de n'avoir aucune requête dans le code mais tout dans les
stored-procs, ça a été un échec total déjà sur la 1ère version du soft
(de mémoire, on manipulait plus de 500 SP), et un cuisant Armageddon le
jour où on a du refondre les fonctionnalités et les donnée s.
>> > De toutes les
>> > variantes de paramètres et/ou de sorties différentes ?
> Non: il est relativement aisé d'écrire une proc polymorphe qu i ne retourne
> que les colonnes autorisées (ou renvoie une erreur si pas d'autori sation).
Cf questions ci-dessus. J'ai du mal à me faire une idée de l'ex istence
de telles SP.
> Pas plus que des centaines de petits morceaux de code d'un pgm en php,
> voire même moins puisque chaque proc a une fonction bien déte rminée
> (quitte à avoir un peu de redondance dans le code afin d'évit er le
> morcellement).
Et donc à balayer d'un revers de la main toutes les bonnes pratiques de
développementâ¦
> Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre
> greper dans des centaines de bouts de code php pour s'y retrouver et
> modifier ces morceaux comme voulu, et modifier directement une ou des
> procs stockées dans la DB?
En PHP, je ne dis pas, mais même dans ce langage, un programme  « bien
conçu » (3-tiers, MVC, template, séparation forme/contenu â¦) est assez
facilement maintenable et évolutif.
> à part les langages différents et surtout le fait que le cont rôle total
> des données soit dévolu à la DB et non-plus à du co de externe, je ne vois
> pas où se trouve le différentiel de maintenance.
Il se trouve aussi du côté des outils.
Si je développe en Java, j'ai des outils de refacto automatique, de la
complétion automatique, des navigateurs de codeâ¦
Choses déjà passablement existantes en PHP (mais c'est possible ) mais
carrément inexistantes au niveau BDD et SP.
Je serais intéressé par un exemple, là comme ça je ne vois pasâ¦
Comment peut-on gérer par procédure stockée le fait que le s arguments
peuvent être variable (tri par date *OU* par nom), avoir des
comportements différents (nombre de post dans un topic, puis liste d es
topics, puis liste des posts du topic joint avec la table des auteurs),
ou retourner des valeurs différentes (dans les cas précéde nts, un
nombre, une liste de topic, une liste de (post + auteur)) ?
Sans exponentiation du nombre de stored-proc et/ou de leur complexità ©,
j'ai du mal à concevoirâ¦
> de l'autre on gagne une malléabilité énorme et l'abstrac tion par rapport
> aux données;
Là aussi, je bloqueâ¦
à la moindre modif des fonctionnalitées et/ou de la structure de
données, j'imagine assez mal comment on peut éviter un refactor ing
monstrueux du nombre tout aussi monstrueux des stored-proc.
Par exemple avec l'exemple des topics précédents, le fait de ra jouter
une date de publication à un post par exemple, nécessite a mini ma
d'ajouter encore X stored-procs pour pouvoir gérer les filtres et les
tris sur cette colonne, de refondre Y stored-procs pour ajouter cette
date en données de sortie, etc.
> La maintenance n'est pas plus lourde que pour un pgm en php, voire plus
> légère,
Si on arrive à m'expliquer les points ci-dessus, OK, pourquoi pas⠦
Pour l'avoir déjà expérimenté sur un projet où l a contrainte cliente
était de n'avoir aucune requête dans le code mais tout dans les
stored-procs, ça a été un échec total déjà sur la 1ère version du soft
(de mémoire, on manipulait plus de 500 SP), et un cuisant Armageddon le
jour où on a du refondre les fonctionnalités et les donnée s.
>> > De toutes les
>> > variantes de paramètres et/ou de sorties différentes ?
> Non: il est relativement aisé d'écrire une proc polymorphe qu i ne retourne
> que les colonnes autorisées (ou renvoie une erreur si pas d'autori sation).
Cf questions ci-dessus. J'ai du mal à me faire une idée de l'ex istence
de telles SP.
> Pas plus que des centaines de petits morceaux de code d'un pgm en php,
> voire même moins puisque chaque proc a une fonction bien déte rminée
> (quitte à avoir un peu de redondance dans le code afin d'évit er le
> morcellement).
Et donc à balayer d'un revers de la main toutes les bonnes pratiques de
développementâ¦
> Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre
> greper dans des centaines de bouts de code php pour s'y retrouver et
> modifier ces morceaux comme voulu, et modifier directement une ou des
> procs stockées dans la DB?
En PHP, je ne dis pas, mais même dans ce langage, un programme  « bien
conçu » (3-tiers, MVC, template, séparation forme/contenu â¦) est assez
facilement maintenable et évolutif.
> à part les langages différents et surtout le fait que le cont rôle total
> des données soit dévolu à la DB et non-plus à du co de externe, je ne vois
> pas où se trouve le différentiel de maintenance.
Il se trouve aussi du côté des outils.
Si je développe en Java, j'ai des outils de refacto automatique, de la
complétion automatique, des navigateurs de codeâ¦
Choses déjà passablement existantes en PHP (mais c'est possible ) mais
carrément inexistantes au niveau BDD et SP.
Je serais intéressé par un exemple, là comme ça je ne vois pasâ¦
Comment peut-on gérer par procédure stockée le fait que le s arguments
peuvent être variable (tri par date *OU* par nom), avoir des
comportements différents (nombre de post dans un topic, puis liste d es
topics, puis liste des posts du topic joint avec la table des auteurs),
ou retourner des valeurs différentes (dans les cas précéde nts, un
nombre, une liste de topic, une liste de (post + auteur)) ?
Sans exponentiation du nombre de stored-proc et/ou de leur complexità ©,
j'ai du mal à concevoirâ¦
> de l'autre on gagne une malléabilité énorme et l'abstrac tion par rapport
> aux données;
Là aussi, je bloqueâ¦
à la moindre modif des fonctionnalitées et/ou de la structure de
données, j'imagine assez mal comment on peut éviter un refactor ing
monstrueux du nombre tout aussi monstrueux des stored-proc.
Par exemple avec l'exemple des topics précédents, le fait de ra jouter
une date de publication à un post par exemple, nécessite a mini ma
d'ajouter encore X stored-procs pour pouvoir gérer les filtres et les
tris sur cette colonne, de refondre Y stored-procs pour ajouter cette
date en données de sortie, etc.
> La maintenance n'est pas plus lourde que pour un pgm en php, voire plus
> légère,
Si on arrive à m'expliquer les points ci-dessus, OK, pourquoi pas⠦
Pour l'avoir déjà expérimenté sur un projet où l a contrainte cliente
était de n'avoir aucune requête dans le code mais tout dans les
stored-procs, ça a été un échec total déjà sur la 1ère version du soft
(de mémoire, on manipulait plus de 500 SP), et un cuisant Armageddon le
jour où on a du refondre les fonctionnalités et les donnée s.
>> > De toutes les
>> > variantes de paramètres et/ou de sorties différentes ?
> Non: il est relativement aisé d'écrire une proc polymorphe qu i ne retourne
> que les colonnes autorisées (ou renvoie une erreur si pas d'autori sation).
Cf questions ci-dessus. J'ai du mal à me faire une idée de l'ex istence
de telles SP.
> Pas plus que des centaines de petits morceaux de code d'un pgm en php,
> voire même moins puisque chaque proc a une fonction bien déte rminée
> (quitte à avoir un peu de redondance dans le code afin d'évit er le
> morcellement).
Et donc à balayer d'un revers de la main toutes les bonnes pratiques de
développementâ¦
> Je ne comprends pas ta vue de la chose: quelle différence vois-tu entre
> greper dans des centaines de bouts de code php pour s'y retrouver et
> modifier ces morceaux comme voulu, et modifier directement une ou des
> procs stockées dans la DB?
En PHP, je ne dis pas, mais même dans ce langage, un programme  « bien
conçu » (3-tiers, MVC, template, séparation forme/contenu â¦) est assez
facilement maintenable et évolutif.
> à part les langages différents et surtout le fait que le cont rôle total
> des données soit dévolu à la DB et non-plus à du co de externe, je ne vois
> pas où se trouve le différentiel de maintenance.
Il se trouve aussi du côté des outils.
Si je développe en Java, j'ai des outils de refacto automatique, de la
complétion automatique, des navigateurs de codeâ¦
Choses déjà passablement existantes en PHP (mais c'est possible ) mais
carrément inexistantes au niveau BDD et SP.
> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langag e.
-> Par curiosité, peux-tu développer ce point stp ?
> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langag e.
-> Par curiosité, peux-tu développer ce point stp ?
> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langag e.
-> Par curiosité, peux-tu développer ce point stp ?
Bonjour,
>
> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
-> Par curiosité, peux-tu développer ce point stp ?
Bonjour,
>
> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
-> Par curiosité, peux-tu développer ce point stp ?
Bonjour,
>
> Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
-> Par curiosité, peux-tu développer ce point stp ?
Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
-> Par curiosité, peux-tu développer ce point stp ?
Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
-> Par curiosité, peux-tu développer ce point stp ?
Je n'ai jamais compris l'engouement vers PHP, qui est un mauvais langage.
-> Par curiosité, peux-tu développer ce point stp ?
kaliderus wrote on Sat, Sep 17, 2011 at 02:25:49PM +0200
> Bonjour,
> -> Par curiosité, peux-tu développer ce point stp ?
Aéris a donné quelques points ce matin dans son message posté à 0 1:07.
À chacun de vérifier s'il le souhaite.
Sans être ni spécialiste ni exhaustif je peux citer
http://opalang.org/
http://ocsigen.org/
http://hop.inria.fr/
http://kayalang.org/
mais il en existe d'autres.
kaliderus wrote on Sat, Sep 17, 2011 at 02:25:49PM +0200
> Bonjour,
> -> Par curiosité, peux-tu développer ce point stp ?
Aéris a donné quelques points ce matin dans son message posté à 0 1:07.
À chacun de vérifier s'il le souhaite.
Sans être ni spécialiste ni exhaustif je peux citer
http://opalang.org/
http://ocsigen.org/
http://hop.inria.fr/
http://kayalang.org/
mais il en existe d'autres.
kaliderus wrote on Sat, Sep 17, 2011 at 02:25:49PM +0200
> Bonjour,
> -> Par curiosité, peux-tu développer ce point stp ?
Aéris a donné quelques points ce matin dans son message posté à 0 1:07.
À chacun de vérifier s'il le souhaite.
Sans être ni spécialiste ni exhaustif je peux citer
http://opalang.org/
http://ocsigen.org/
http://hop.inria.fr/
http://kayalang.org/
mais il en existe d'autres.