[sur la facilité à maintenir et étendre Piwigo] Quand changer de SGBDR,
prend un temps pas possible et arrive à faire casser certains thème,
j'ai un doute sur ce dernier point.
Bon bon bon, ça devient de l'attaque un peu gratuite. Je me fais moinser sur mes messages et tu te fais plusser sur les tiens, donc j'ai tendance à croire que quoi je dise, je vais passer soit pour un méchant, soit pour un imbécile, soit pour un incapable :-/
Selon mon expérience, plus tu rajoutes d'intermédiaires, de fonctions qui appellent des classes, elles mêmes dérivées de plusieurs classes, etc.... plus ça devient compliqué à maintenir. Maintenir = corriger un bug. Maintenir != faire évoluer.
J'ai travaillé avec des développeurs qui se prenaient la tête à prévoir que peut-être un jour on voudra faire ceci ou cela avec le code et donc il fallait le prévoir dans l'architecture. Moi je dis stop. Soit on en a besoin tout de suite, soit on ne le prévoit pas et on reste simple dans son architecture. Code simple = code facile à maintenir. C'est d'autant plus important dans un projet libre et ouvert comme Piwigo que le développeur d'une fonctionnalité ne va pas forcément être celui qui va y corriger un bug 3 ans plus tard.
Quant à la capacité d'étendre Piwigo, je parle des thèmes et des plugins. Il y a plus de 200 plugins et plus de 100 thèmes. Pour un CMS "spécifique", c'est plutôt pas mal.
"Changer de SGBD" n'est en aucun cas un besoin récurrent. Et la problématique n'est pas de changer, mais d'être compatible multi-SGBD, ce qui n'est pas du tout la même chose. Si un jour on passe en MariaDB, ce sera bien plus simple que d'être compatible PostgreSQL/SQLite/Firebird/FuturSGBDopensourceAlamode.
Sinon vous avez eu temps de problème de performance pour que ça soit si
primordiale ? Tu nous en parle depuis le début et à toutes les sauces,
c'est une contraintes qui a était si forte que ça ? et dure à tenir ?
Disons que le premier retour que l'on a de la part de ceux qui passent de Coppermine ou Menalto Gallery à Piwigo, c'est la performance : avec Piwigo, quelque soit la quantité de photos, ça va vite. Bon, on a un utilisateur avec plus d'un million de photos qui nous a dit avoir des soucis pour synchroniser. Mais ceux qui sont à plusieurs centaines de milliers sont très contents et nous on dit qu'il n'existait pas d'autre galerie open source qui en soit capable. Je n'ai pas tout testé, je les crois sur parole, d'autant que ça fait plaisir à lire :-)
Oui, tenir la perf c'est difficile à tenir. Désolé d'en parler à toutes les sauces. Je vois tellement d'applications web qui prennent 100% du CPU pendant 2 secondes (grâce à une tripotée de framework MVC et multiple couche d'abstraction) pour afficher une page vide que j'ai à coeur de ne pas reproduire la même chose avec Piwigo.
[^] # Re: MediaGoblin, une petite demo n'aurait pas ete de trop
Posté par Pierrick Le Gall . En réponse à la dépêche Petites brèves : MediaGoblin, CloudStack, Walt Disney et G'MIC. Évalué à 10.
Bon bon bon, ça devient de l'attaque un peu gratuite. Je me fais moinser sur mes messages et tu te fais plusser sur les tiens, donc j'ai tendance à croire que quoi je dise, je vais passer soit pour un méchant, soit pour un imbécile, soit pour un incapable :-/
Selon mon expérience, plus tu rajoutes d'intermédiaires, de fonctions qui appellent des classes, elles mêmes dérivées de plusieurs classes, etc.... plus ça devient compliqué à maintenir. Maintenir = corriger un bug. Maintenir != faire évoluer.
J'ai travaillé avec des développeurs qui se prenaient la tête à prévoir que peut-être un jour on voudra faire ceci ou cela avec le code et donc il fallait le prévoir dans l'architecture. Moi je dis stop. Soit on en a besoin tout de suite, soit on ne le prévoit pas et on reste simple dans son architecture. Code simple = code facile à maintenir. C'est d'autant plus important dans un projet libre et ouvert comme Piwigo que le développeur d'une fonctionnalité ne va pas forcément être celui qui va y corriger un bug 3 ans plus tard.
Quant à la capacité d'étendre Piwigo, je parle des thèmes et des plugins. Il y a plus de 200 plugins et plus de 100 thèmes. Pour un CMS "spécifique", c'est plutôt pas mal.
"Changer de SGBD" n'est en aucun cas un besoin récurrent. Et la problématique n'est pas de changer, mais d'être compatible multi-SGBD, ce qui n'est pas du tout la même chose. Si un jour on passe en MariaDB, ce sera bien plus simple que d'être compatible PostgreSQL/SQLite/Firebird/FuturSGBDopensourceAlamode.
Disons que le premier retour que l'on a de la part de ceux qui passent de Coppermine ou Menalto Gallery à Piwigo, c'est la performance : avec Piwigo, quelque soit la quantité de photos, ça va vite. Bon, on a un utilisateur avec plus d'un million de photos qui nous a dit avoir des soucis pour synchroniser. Mais ceux qui sont à plusieurs centaines de milliers sont très contents et nous on dit qu'il n'existait pas d'autre galerie open source qui en soit capable. Je n'ai pas tout testé, je les crois sur parole, d'autant que ça fait plaisir à lire :-)
Oui, tenir la perf c'est difficile à tenir. Désolé d'en parler à toutes les sauces. Je vois tellement d'applications web qui prennent 100% du CPU pendant 2 secondes (grâce à une tripotée de framework MVC et multiple couche d'abstraction) pour afficher une page vide que j'ai à coeur de ne pas reproduire la même chose avec Piwigo.