Bonjour,
Je viens de mettre en ligne un tout petit projet entamé en décembre (non non, il m'a pas fallu tout ce temps pour coder, juste pour trouver la motivation nécessaire à l'achèvement d'une version utilisable) permettant de gérer les idées de cadeaux.
L'idée m'est venu au n-ième mail de ma sœur donnant une idée de cadeau pour l'un ou l'autre des membres de la famille, mail dont était en copie toute la famille sauf le destinataire du cadeau.
Trouvant l'organisation par mail assez chaotique et donc peu pratique, je décidais de coder une petite application PHP basée sur ce principe : tout les utilisateurs peuvent mettre des idées de cadeaux pour les autres, mais ils ne peuvent pas voir ce qui a été mis pour eux-même.
Je vous propose donc d'essayer ma première version fonctionnelle (j'ai jusqu'à noël prochain pour peaufiner, je suis large). Les utilisateurs peuvent ajouter des idées de cadeaux aux autres, les consulter, se les assigner (dire qu'ils vont faire telle idée de cadeau, pour ne pas être plusieurs à offrir la même chose), et commenter les idées de cadeau.
Plusieurs personnes peuvent s'assigner une même idée pour les cadeaux collectifs. (peut-être ajouterais-je une gestion du prix du cadeau à partager plus tard, mais c'est délicat car sensé n'être connu que par les donateurs)
Le tout est sous licence AGPLv3+.
Je suis ouvert à toutes remarques/critiques, et il y en a de nombreuses à faire je suppose, aussi je compte sur vous pour me donner un maximum de retours.
Que ce soit des soucis de conception, des bugs, des trous de "sécurité", des fautes d'anglais, des bouts de français dans mon code anglais (je sais qu'il y en a deux ou trois), des fautes de frappes, ...
Un bug tracker est en place et ne demande qu'à être rempli.
Au fait, le projet s'appelle PHPGiftIdeas
Page de téléchargement : http://projects.haxx.es/index.php/p/phpgiftideas/downloads/
# remarques/critiques
Posté par __o . Évalué à 10.
Bravo pour cette contribution.
Comme tu le demandes, j'ai quelques remarques :
- Tu affiches des données venant de l'utilisateur ($_GET, $_POST, et tout ce que tu n'as pas définie toi même) sans les échapper, il est donc possible d'y injecter du code javascript (et voler mots de passe, cookies, comptes, exploiter une faille du navigateur, etc).
- De la même manière tu met des données venant de l'utilisateur directement dans des requêtes SQL, ce qui permet d'injecter / modifier la requête, et ainsi faire un peu ce qu'on veut avec ta base de données.
Pour corriger ces deux problèmes je te conseil de chercher "injection SQL" et "cross site scripting" sur ton moteur de recherche préféré.
Sinon, c'est toujours une bonne idée d'utiliser un framework, si petite l'application soit elle; car ceux-ci ont déjà tout ce qu'il faut pour ce genre de problématiques.
[^] # Re: remarques/critiques
Posté par MCMic (site web personnel) . Évalué à 1.
[^] # Re: remarques/critiques
Posté par hervé Couvelard . Évalué à 5.
Je suis assez perplexe.
Disons que je veuille utiliser cette application et plutôt que d'avoir 3 fichiers pour un total de 15 Ko, je vais avoir 1 fichier (pour un total de probablement 15 Ko), à mettre dans une applis de 3 Mo. Et quel framework ? Cela tombera presque toujours sur celui que tu n'as pas chez toi.
J'aurais tendance à dire, si tu veux faire une "grosse" application, il est peut être interessant d'utiliser un framework parce qu'une grande partie du projet (sécurité, environnement, administration etc.....) peut être déjà intégré dans le framework, mais pour un script de 2 pages, devoir installer joomla ou un phpbb ou un truc compliqué ne me semble pas aller dans le sens "tout le monde fait et héberge sa petite applis."
Ensuite, si on regarde un peu plus loin, imaginons que tu veuilles 2 ou 3 petites applis pour t'aider dans ton quotidien, une sur spip, une sur joomla, une sur un_framework_la_mort, bonjour la mise de départ pour héberger ton truc sur ta machine.
Enfin, si on réfléchi à la problématique que benjamin Bayard pointe : "il faut chacun héberger ses applis pour éviter le minitel 2.0" , crois-tu que de devoir installer (et configurer !) un framework complet juste pour avoir les dates d'anniversaire des membres de la familles (disons 100 lignes de codes en standalone) pousse les personnes à ne plus utiliser les "outils" tous plus la mort qui tue de face book ou gogle truc ?
Par exemple, hp et hplip c'est vachement cool, on peut en convenir. La dernière mésaventure qui m'est arrivé, dans le style ma vie :
- on m'appelle au téléphone avant l'achat d'une imprimante (une deskjet F4580), je regarde sur internet, ne trouve rien (normal elle est assez récente) je vais chez hplip, je télécharge les sources de la dernière version, j'extrait le fichier ppd, je la fais installer avec le fichier ppd fournis, que pouic, il doit probablement falloir installer la dernière version _complète_ de hplip, bonjour l'angoisse sur un "vieux" système.
La moral ?
Parfois l'utilisation d'un framework complet pour juste un petit bout d'application, c'est pas une bonne idée. C'est la même chose que ceux qui font du logiciel libre en prenant le framework complet microsoft, tu peux pas porter ton applis sans réécrire ce qui est utilisé dans le framework.
[^] # Re: remarques/critiques
Posté par nomorsad . Évalué à 2.
As-tu déjà remarqué que ton /usr/lib était plein de fichier *.so qui ne sont pas tous forcement utilisés ;-)
Donc moi je dis absolument OUI au framework, rien que pour éviter les problèmes de sécurité et de performance. Car oui, des fois un framework, c'est gros, mais ça peut aller plus vite que du PHP brut (cache, pool de connexion, toussa). Et ça lui aurait éviter d'avoir à auditer son code à la recherche des failles connues (voir le premier commentaire!). Et ça permet de prévoir l'évolution (i18n, templates, ...)
La où je te rejoins, c'est que les framework sont souvent des usines à gaz, car les développeurs ont toujours un peu tendance à réinventé la même chose que le voisin...
Donc c'est sûr que ca serait pas mal si c'était parfois un peu plus modulaire...
[^] # Re: remarques/critiques
Posté par MCMic (site web personnel) . Évalué à 1.
Je trouverai ça un peu dommage de déployer symfony juste pour ça -_-
[^] # Re: remarques/critiques
Posté par nomorsad . Évalué à 1.
A vue de nez, les framework comme ROR, Symphony and co, sont justement fait pour des petits développements rapide, non?
Mais je pense qu'il faut au moins une lib de template, pour pouvoir faire un minimum evolutif.
Sans avoir jamais developpé avec, je connais au moins Smarty de nom.
[^] # Re: remarques/critiques
Posté par hervé Couvelard . Évalué à 1.
Il est même pas possible de compiler from source dessus car les pré-requis pour la compilation ne sont pas disponibles sauf a backporter une foultitude de truc...
juste pour un imprimante usb....
Rien n'est vraiment aussi simple dans la vie...
[^] # Re: remarques/critiques
Posté par __o . Évalué à 3.
Je parlais plutôt de choses comme Symfony ou Zend Framework (ou des trucs plus petits), qui peuvent simplement être installés en tant que bibliothèques sur le système et utilisés par n'importe quelle application (et même plusieurs d'entre elles en même temps). Ça n'ajoute aucun pré-requis pour ton application (pas de base de donnée propre au framework par exemple) , leur installation se limite à une copie de fichiers (si il n'y a pas déjà des paquets dans la distribution), et ça s'héberge très bien sur des petites machines.
# Le besoin est vraiment là !
Posté par Oliviergifteer . Évalué à -10.
C'est clair que le besoin est vraiment là ! Les cadeaux en famille, que ce soit pour Noël ou pour les anniversaires, c'est toujours la galère. Confrontés à ce problème, nous avons lancé le site [http://www.gifteer.com] qui est basé sur la même idée, mais sans avoir besoin d'installer le machin. Un peu plus facile pour les mamans qui veulent organiser les cadeaux !
Evidemment c'est gratuit...
Avec plusieurs milliers d'utilisateurs + appli Facebook, tu obtiens un effet réseau assez intéressant.
[^] # Re: Le besoin est vraiment là !
Posté par Deuterium . Évalué à 3.
[^] # Re: Le besoin est vraiment là !
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 7.
Dans l'esprit du partage cher à au logiciel libre ?
Blague à part, le code source du site est distribué ?
[^] # Re: Le besoin est vraiment là !
Posté par Kerro . Évalué à 10.
Oups pardon, pléonasme: pub de merde.
[^] # Re: Le besoin est vraiment là !
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
# Démo
Posté par hugo (site web personnel) . Évalué à 5.
ce qui aurait été bien, c'est des captures d'écrans, mieux, une démo histoire de voir à peu près à quoi ressemble...
++
[^] # Re: Démo
Posté par MCMic (site web personnel) . Évalué à 2.
Voilà une démo mise en ligne vite fait (j'ai release une beta pour l'occasion, pour pouvoir avoir les derniers bugfix dans la démo)
Au moins vous pouvez voir à quoi ça ressemble.
[^] # Re: Démo
Posté par hugo (site web personnel) . Évalué à 2.
Oui, il faut tout prémâcher sinon, l'utilisateur ne teste pas et part en ronchonnant.
[^] # Re: Démo
Posté par MCMic (site web personnel) . Évalué à 1.
[^] # Re: Démo
Posté par TBTB . Évalué à 3.
L'utilisateur pressé qui cherche une démo plus parlante que quelques copies d'écran ne souhaite pas créer un compte mais juste voir à quoi ça ressemble avec un login/password tout prêt
[^] # Re: Démo
Posté par hugo (site web personnel) . Évalué à 2.
# phpgiftregistry
Posté par nomorsad . Évalué à 4.
Je le trouve plutot bienfait mais il est juste très moche et pas d'i18n. On va voir si ton soft apporte un plus!
Comme dit ci-dessus, c'est un vrai besoin, et on manque de mutualisation sur le sujet.
[^] # Re: phpgiftregistry
Posté par MCMic (site web personnel) . Évalué à 1.
Je vais regarder ça.
l'i18n c'est pas en place mais c'est prévu pour mon soft.
[^] # Re: phpgiftregistry
Posté par B16F4RV4RD1N . Évalué à 4.
http://linuxfr.org/~selmak/27309.html
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: phpgiftregistry
Posté par Gilles Mocellin . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.