Bijôr, c'est kôr mwa ...
(environnement de déploiement : serveur mutualisé, Free pour ne pas le
nommer)
Je précise que j'ai bien vu que le code PHP, une fois uploadé, reste
sur le serveur et n'encombre pas les tuyaux. J'ai également conscience
que les grosses bêtises seront dues à une mauvaise coception des accès
BdB, et d'une façon plus générale des accès disque.
Néanmoins, ça reste du code interprété (domaine que je ne connais pas).
Il est clair qu'en compilé (ou en bytecodé), je vais favoriser la
lisibilité, la sécurité, la maintenabilité, et choisir s'il y a lieu un
compilateur correct.
J'utilise beaucoup de code copié/collé depuis des tutoriaux (pas
toujours indiscutable il me semble, je me "l'approprie" peu à peu en le
modifiant). Et également du free (GPL, LGPL etc.) comme spgm (galeries
photo), File_Archive + PEAR et pclzip. J'ai remarqué que certains de
ces codes sont pour plus de la moitié du commentaire (qui est quand
même parsé, non ?), et qu'il embarque des fonctions inutiles d'une
autre version (fonctions de trace semble-t-il).
Mes questions portent donc sur la stratégie (et mes droits) de
nettoyage et d'optimisation. Que faire ? Avec quelqs outils ? Comment
gérer s'il y a lieu une version de développement et une version
déployée ?
Je précise que même sur du code (invisible) à usage personnel, il n'est
pas dans mes intentions d'enlever tout cartouche donnant le nom de
l'auteur et éventuellement les modifs effectuées.
Je pose beaucoup de questions, alors qu'il me suffirait sans doute de
travailler un peu pour en trouver les réponses. C'est par souci de ne
pas trop accumuler de bêtises. Ce qui amène une dernière question :
quelles stratégies/outils sont communs pour centraliser des "briques"
de code, utilisées dans des sites différents, avec et sans Dremweaver ?
Merci d'avance pour votre patience.
--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo
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
John GALLET
Bonjour,
(environnement de déploiement : serveur mutualisé, Free pour ne pas le nommer) Mouais. Pour les pages statiques, ça va encore, mais parfois pour la
connexion sgbd, ça peut ramer (un peu, beaucoup, passionnément, à la folie, mais rarement pas du tout).
Je précise que j'ai bien vu que le code PHP, une fois uploadé, reste sur le serveur et n'encombre pas les tuyaux. Le code oui.
J'ai également conscience que les grosses bêtises seront dues à une mauvaise coception des accès BdB, et d'une façon plus générale des accès disque.
On va dire : des I/O de manière générale, mais moi j'irais même plus loin : bien 20% des lenteurs que j'aie constatées en production sont surtotu liées à un mauvais algorithme de traitement (on fait des trucs qui servent à rien).
Néanmoins, ça reste du code interprété (domaine que je ne connais pas). Oui dans la plupart des cas. Cf le chapitre 15 de la FAQ (je ne sais pas
si free a installé le zend optimiser).
Il est clair qu'en compilé (ou en bytecodé), je vais favoriser la lisibilité, la sécurité, la maintenabilité, et choisir s'il y a lieu un compilateur correct. Cela reste valable. Ce qui coûte le plus cher dans l'entreprise, c'est
le temps passé à faire la correctino et la maintenance évolutive. C'est pareil pour tes petits scripts perso. Quand tu vas revenir les lire après 6 mois, surtout tes premiers scripts qui seront parfois un peu dans le genre "bancal" sur les bords, tu seras bien content de retrouver tes commentaires.
photo), File_Archive + PEAR et pclzip. J'ai remarqué que certains de ces codes sont pour plus de la moitié du commentaire (qui est quand même parsé, non ?), Oui, tout le fichier est nécessaireemnt parsé.
et qu'il embarque des fonctions inutiles d'une autre version (fonctions de trace semble-t-il). Rares sont les bibliothèques (pardon : framework, ça fait mieux) qui
font pile poil ce dont tu as besoin sans fonctionnalités inutiles...
Mes questions portent donc sur la stratégie (et mes droits) de nettoyage et d'optimisation.
Droit : au cas par cas selon la license de distribution desdites applications et surtout selon ce que tu en fais (redistribution ou non).
Que faire ? Avec quelqs outils ? Comment gérer s'il y a lieu une version de développement et une version déployée ? C'est l'éternel problème de l'utilisation de librairies tierces ou du
redéveloppement de ses propres libs. Pour autant qu'il puisse y avoir une réponse autre que "à toi de voir ce qui te fait perdre le moins de temps", je pense que cette question, qui est commune à tous les langages de développement, trouvera plus une réponse sur fr.comp.developpement
Pour les outils, c'est clair : ça se gère majoritairement à la main.
quelles stratégies/outils sont communs pour centraliser des "briques" de code, utilisées dans des sites différents, avec et sans Dremweaver ?
Deux questions en une. 1) Dreamweaver utilise pour php des espèces de mini-templates appelés dans le clickodrome de génération. C'est une application en soit, si tu l'utilises, tu ne développes pas en php seulement, tu développes avant tout en dreamweaver 2) toute librairie s'organise en modules logiques, que l'on peut renforcer en créant des classes si cela apporte quelque chose au besoin, et en fichiers dans des répertoires. Tu peux mettre tous les fichiers de ta librairie perso dans un répertoire spécifique.
HTH JG
Bonjour,
(environnement de déploiement : serveur mutualisé, Free pour ne pas le
nommer)
Mouais. Pour les pages statiques, ça va encore, mais parfois pour la
connexion sgbd, ça peut ramer (un peu, beaucoup, passionnément, à la
folie, mais rarement pas du tout).
Je précise que j'ai bien vu que le code PHP, une fois uploadé, reste
sur le serveur et n'encombre pas les tuyaux.
Le code oui.
J'ai également conscience
que les grosses bêtises seront dues à une mauvaise coception des accès
BdB, et d'une façon plus générale des accès disque.
On va dire : des I/O de manière générale, mais moi j'irais même plus
loin : bien 20% des lenteurs que j'aie constatées en production sont
surtotu liées à un mauvais algorithme de traitement (on fait des trucs
qui servent à rien).
Néanmoins, ça reste du code interprété (domaine que je ne connais pas).
Oui dans la plupart des cas. Cf le chapitre 15 de la FAQ (je ne sais pas
si free a installé le zend optimiser).
Il est clair qu'en compilé (ou en bytecodé), je vais favoriser la
lisibilité, la sécurité, la maintenabilité, et choisir s'il y a lieu un
compilateur correct.
Cela reste valable. Ce qui coûte le plus cher dans l'entreprise, c'est
le temps passé à faire la correctino et la maintenance évolutive. C'est
pareil pour tes petits scripts perso. Quand tu vas revenir les lire
après 6 mois, surtout tes premiers scripts qui seront parfois un peu
dans le genre "bancal" sur les bords, tu seras bien content de retrouver
tes commentaires.
photo), File_Archive + PEAR et pclzip. J'ai remarqué que certains de
ces codes sont pour plus de la moitié du commentaire (qui est quand
même parsé, non ?),
Oui, tout le fichier est nécessaireemnt parsé.
et qu'il embarque des fonctions inutiles d'une
autre version (fonctions de trace semble-t-il).
Rares sont les bibliothèques (pardon : framework, ça fait mieux) qui
font pile poil ce dont tu as besoin sans fonctionnalités inutiles...
Mes questions portent donc sur la stratégie (et mes droits) de
nettoyage et d'optimisation.
Droit : au cas par cas selon la license de distribution desdites
applications et surtout selon ce que tu en fais (redistribution ou non).
Que faire ? Avec quelqs outils ? Comment
gérer s'il y a lieu une version de développement et une version
déployée ?
C'est l'éternel problème de l'utilisation de librairies tierces ou du
redéveloppement de ses propres libs. Pour autant qu'il puisse y avoir
une réponse autre que "à toi de voir ce qui te fait perdre le moins de
temps", je pense que cette question, qui est commune à tous les langages
de développement, trouvera plus une réponse sur fr.comp.developpement
Pour les outils, c'est clair : ça se gère majoritairement à la main.
quelles stratégies/outils sont communs pour centraliser des "briques"
de code, utilisées dans des sites différents, avec et sans Dremweaver ?
Deux questions en une.
1) Dreamweaver utilise pour php des espèces de mini-templates appelés
dans le clickodrome de génération. C'est une application en soit, si tu
l'utilises, tu ne développes pas en php seulement, tu développes avant
tout en dreamweaver
2) toute librairie s'organise en modules logiques, que l'on peut
renforcer en créant des classes si cela apporte quelque chose au besoin,
et en fichiers dans des répertoires. Tu peux mettre tous les fichiers de
ta librairie perso dans un répertoire spécifique.
(environnement de déploiement : serveur mutualisé, Free pour ne pas le nommer) Mouais. Pour les pages statiques, ça va encore, mais parfois pour la
connexion sgbd, ça peut ramer (un peu, beaucoup, passionnément, à la folie, mais rarement pas du tout).
Je précise que j'ai bien vu que le code PHP, une fois uploadé, reste sur le serveur et n'encombre pas les tuyaux. Le code oui.
J'ai également conscience que les grosses bêtises seront dues à une mauvaise coception des accès BdB, et d'une façon plus générale des accès disque.
On va dire : des I/O de manière générale, mais moi j'irais même plus loin : bien 20% des lenteurs que j'aie constatées en production sont surtotu liées à un mauvais algorithme de traitement (on fait des trucs qui servent à rien).
Néanmoins, ça reste du code interprété (domaine que je ne connais pas). Oui dans la plupart des cas. Cf le chapitre 15 de la FAQ (je ne sais pas
si free a installé le zend optimiser).
Il est clair qu'en compilé (ou en bytecodé), je vais favoriser la lisibilité, la sécurité, la maintenabilité, et choisir s'il y a lieu un compilateur correct. Cela reste valable. Ce qui coûte le plus cher dans l'entreprise, c'est
le temps passé à faire la correctino et la maintenance évolutive. C'est pareil pour tes petits scripts perso. Quand tu vas revenir les lire après 6 mois, surtout tes premiers scripts qui seront parfois un peu dans le genre "bancal" sur les bords, tu seras bien content de retrouver tes commentaires.
photo), File_Archive + PEAR et pclzip. J'ai remarqué que certains de ces codes sont pour plus de la moitié du commentaire (qui est quand même parsé, non ?), Oui, tout le fichier est nécessaireemnt parsé.
et qu'il embarque des fonctions inutiles d'une autre version (fonctions de trace semble-t-il). Rares sont les bibliothèques (pardon : framework, ça fait mieux) qui
font pile poil ce dont tu as besoin sans fonctionnalités inutiles...
Mes questions portent donc sur la stratégie (et mes droits) de nettoyage et d'optimisation.
Droit : au cas par cas selon la license de distribution desdites applications et surtout selon ce que tu en fais (redistribution ou non).
Que faire ? Avec quelqs outils ? Comment gérer s'il y a lieu une version de développement et une version déployée ? C'est l'éternel problème de l'utilisation de librairies tierces ou du
redéveloppement de ses propres libs. Pour autant qu'il puisse y avoir une réponse autre que "à toi de voir ce qui te fait perdre le moins de temps", je pense que cette question, qui est commune à tous les langages de développement, trouvera plus une réponse sur fr.comp.developpement
Pour les outils, c'est clair : ça se gère majoritairement à la main.
quelles stratégies/outils sont communs pour centraliser des "briques" de code, utilisées dans des sites différents, avec et sans Dremweaver ?
Deux questions en une. 1) Dreamweaver utilise pour php des espèces de mini-templates appelés dans le clickodrome de génération. C'est une application en soit, si tu l'utilises, tu ne développes pas en php seulement, tu développes avant tout en dreamweaver 2) toute librairie s'organise en modules logiques, que l'on peut renforcer en créant des classes si cela apporte quelque chose au besoin, et en fichiers dans des répertoires. Tu peux mettre tous les fichiers de ta librairie perso dans un répertoire spécifique.
HTH JG
Pierre Maurette
Bonjour, Bonjour,
et merci pour vos réponses.
[...]
J'ai pas mal avancé (à temps perdu, mais du temps quand même) depuis ce post. Je suis un peu tous azimuth, HTML, PHP, SQL (et MySQL), Dreamweaver MX 2004 en même temps. Je ne pourrai pas garder DW pour mes amusements (trop cher, mon fils), mais je le trouve pratique. En réfléchissant un peu, on distingue assez bien ce qu'il gère et doit gérer, et ce qu'on peut écrire tout seul. Le code PHP de DW est plus satisfaisant que beaucoup de codes de tuts jamais mis à jour. Pour finir, à partir d'une ébauche DW, on peut reprendre la main avec PSPad ou autre. J'ai utilisé pour compacter les fichiers en ligne la fonction php_strip_whitespace() de PHP 5 (en PHP 4 et avec la compatibilité par PEAR, uniquement en local). J'aurais eu aussi vite fait de me faire une moulinette en C (je dois l'avoir dans un coin), mais bon ... Le tout est de garder une stricte synchronisation entre le code source en local et le code obfusqué (c'est presque ça) en ligne.
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
Pierre Maurette
Bonjour,
Bonjour,
et merci pour vos réponses.
[...]
J'ai pas mal avancé (à temps perdu, mais du temps quand même) depuis ce
post. Je suis un peu tous azimuth, HTML, PHP, SQL (et MySQL),
Dreamweaver MX 2004 en même temps.
Je ne pourrai pas garder DW pour mes amusements (trop cher, mon fils),
mais je le trouve pratique. En réfléchissant un peu, on distingue assez
bien ce qu'il gère et doit gérer, et ce qu'on peut écrire tout seul. Le
code PHP de DW est plus satisfaisant que beaucoup de codes de tuts
jamais mis à jour. Pour finir, à partir d'une ébauche DW, on peut
reprendre la main avec PSPad ou autre.
J'ai utilisé pour compacter les fichiers en ligne la fonction
php_strip_whitespace() de PHP 5 (en PHP 4 et avec la compatibilité par
PEAR, uniquement en local). J'aurais eu aussi vite fait de me faire une
moulinette en C (je dois l'avoir dans un coin), mais bon ...
Le tout est de garder une stricte synchronisation entre le code source
en local et le code obfusqué (c'est presque ça) en ligne.
--
Pour répondre directement: enlever une lettre sur deux
wwaannaaddoooo -> wanadoo
J'ai pas mal avancé (à temps perdu, mais du temps quand même) depuis ce post. Je suis un peu tous azimuth, HTML, PHP, SQL (et MySQL), Dreamweaver MX 2004 en même temps. Je ne pourrai pas garder DW pour mes amusements (trop cher, mon fils), mais je le trouve pratique. En réfléchissant un peu, on distingue assez bien ce qu'il gère et doit gérer, et ce qu'on peut écrire tout seul. Le code PHP de DW est plus satisfaisant que beaucoup de codes de tuts jamais mis à jour. Pour finir, à partir d'une ébauche DW, on peut reprendre la main avec PSPad ou autre. J'ai utilisé pour compacter les fichiers en ligne la fonction php_strip_whitespace() de PHP 5 (en PHP 4 et avec la compatibilité par PEAR, uniquement en local). J'aurais eu aussi vite fait de me faire une moulinette en C (je dois l'avoir dans un coin), mais bon ... Le tout est de garder une stricte synchronisation entre le code source en local et le code obfusqué (c'est presque ça) en ligne.
-- Pour répondre directement: enlever une lettre sur deux wwaannaaddoooo -> wanadoo
