Recette pour une catastrophe :

* Tester, ça marche bien moyennant X
* X est facile à résoudre on change une ligne de code
* Ne pas retester car la modif marche forcément
* Mettre en prod

Toute modif, si anodine soit-elle, introduit un bug dans un pourcentage non négligeable de cas.

Et tu n'as pas retesté avant la soutenance ? O_o

Rien de bien méchant, l'affaire d'une correction sur le FTP si FTP il y a, en espérant que ça ne vous a pas coûté des points.
(mais tu aurais du checker :3)

Vu me niveau du binôme que j'avais au premier semestre de L3, j'ai décidé de faire tous les projets tout seul je perdais moins de temps en débug. Après j'ai changé le binôme :)

Je connais des profs sadiques (bon peut-être pas en licence) qui ne t'autorisent pas à modifier ton projet le jour de la soutenance. Donc là, la bulle.
Remarque, j'avais fait pire : on avait fait un projet en découpant les tâches (un mec faisait l'interface, un autre le moteur de scan, un autre le compte-rendu du scan, ..., chacun dans son coin).
Sauf que la veille de la soutenance, on a tenté de remettre tout ça ensemble, mais pas moyen.
Résultat : on est allé à la soutenance à l'arrache, en disant "cette fonctionnalité ? si si, elle marche, sauf qu'on ne peut pas vous la montrer parcqu'on ne l'a pas encore intégrée".
On a eu 6/20, ce qui est beaucoup mieux que la bulle qu'on aurait du avoir (merci au prof d'avoir été aussi souple ce jour là).

C'était pas plus simple de remplacer toutes les chaines var_dump et echo par //var_dump et //echo avec notepad++? Ca prend 5 secondes, plus une minute pour vérifier que ca ne fait pas bug le script, du genre des

if($i > 42)
 //  echo "i = $i<br>";
 foo($bar); // fonction non concernée par le if

Bah j'ai mis CTLP.

Avant une soutenance, la moindre des choses c'est de vérifier que tout marche, au moins trois fois.
Faire confiance a son binome, ok. Tester, impératif. Tu l'as pas fait, bah tant pis pour toi, le prochain coup tu le feras.

(Je parle en connaissance de cause, j'ai fait quasiment le même coup pendant mes études. ça doit etre la chose la plus utile que j'ai appris: toujours tester avant de présenter.)

À faire le vendredi soir avant de partir en vacances, sur une machine dont on est le seul à avoir l'accès.

Il y a sans doute des echo qui ne sont pas à supprimer.

CTLP pour avoir fait du debug à l'écran plutôt que dans un fichier de logs

En effet, j'avais pas pensé à ce point la... C'est peut être radical de supprimer les echo. Par contre pour les var_dump ca doit pas être gênant.

Et en L2, vous n'êtes pas formés a l'utilisation d'un système de contrôle de versions ?

Shocking.

(Comment ça, ça marche mieux avec un flag de debug ? oui mais c'est pas trollable ça madame)

Et en prod.

En même temps vous l'aviez cherché ^^

J'hésite entre les deux votes.
Pour le BEDP:
- la nullité de ton binôme
Pour le CTLP:
- la non-vérification de ses modifications (un binôme, ça marche aussi pour vérifier le travail de l'autre)
- la méthode de visualisation des erreurs (je rejoins log sur ce point)

Alors pour vous répondre, la soutenance était le matin à 8h et j'ai demandé ça à 2h du mat' après 2 nuits blanches d'affilée. Donc non, je n'ai pas retesté.
Pas d'utilisation de FTP car pour lui "c'est pas pratique" (??) et surtout, l'application n'avait pas vocation à être mise en ligne/commercialisée.
Le binôme était assez sérieux, c'est pour ça que je lui faisais confiance... J'ai arrêté après ça.
Et enfin, non, on n'est pas formés à ça. Hélas. Ou alors on l'est, mais sans le savoir x)
Et finalement, le prof a été cool, ça l'a beaucoup fait rire d'ailleurs. L'application fonctionnait d'ailleurs très bien en-dehors de ça :)
Ah, et pourquoi Notepad++ ? jEdit ou KWrite marchent très bien et proposent aussi cette fonctionnalité x)

« à 2h du mat' après 2 nuits blanches »
Ce genre de conneries peut se comprendre… Quoi qu'un geek n'est pas sensé avoir besoin de dormir, il lui suffit de consommer plus de café qu'un chalutier ne consomme de fioul.

Et puis bon, un petit coup de find et rename, et tout est bon :
find -name *_finale.php -exec rename -f 's/_finale//' {} /;

OU (si l'organisation des fichiers s'y prête)

rename -f 's/_finale//' *_finale.php

Moralité ne pas commencer un projet l'avant-veille. :p
On l'a tous fait :)
L'utilisation d'un git, UML, etc. viendra surement avec les matières de type genie logiciel.

Je compatis, finir les projets à l'arrache en entraînant les nuits blanches ... vieux souvenirs... J'avais un binôme sérieux aussi, et pour éviter les problèmes genre mise en commun et autre, on se partageait plutôt les projets tout en se tenant au courant quand même de ce que faisait l'autre. Mais il faut avoir confiance en son binôme...

Pour le PEBKAC, j'ai votè BEDP. soit je considère la faute du binôme, soit je considère que tu aurais du tester et dans ce cas c'est un auto-pebkac

je fais avec le flag + fonction de debug. au moins pas besoin de tester le flag à chaque fois que je veux afficher une variable.

Sinon méthode d'un stagiaire encore plus furtif qu'un stagiaire de 3e (d'ailleurs penser à racheter du ciment et a trouver un canal dans le coin...), afficher le debug dans des divs avec classe css "debug" et ensuite mettre un display: none dans la feuille css ...

Loi de Murphy ça... Règle numéro 1 de la soutenance de projet : jamais d'optimisation la veille.
Si ça marche pas super tip top mais que ça marche, c'est toujours mieux qu'un projet tout cassé.

Et pour le debug comme cité plus haut il y a plusieurs solutions pour ne pas avoir à se prendre la tête, par exemple utiliser un flag ou loguer dans des fichiers.

Je réfute vos accusations éhontées, le projet était commencé depuis plus d'un mois. Mes nuits blanches n'avaient rien à voir avec la fac ou les études.
@Acorah : c'était pas de l'optimisation, car ça ne marchait pas. Bon, finalement, c'était tout con comme erreur, mais ça nous a bien fait suer pendant 2 ou 3 jours.
D'ailleurs, pour l'anecdote, le gars en question a recommencé depuis le début tout son projet d'UML de cette année une semaine avant la soutenance car "finalement, ce que j'ai fait ne me plaisait pas". Ce qu'il n'a pas présenté n'a pas beaucoup plus au prof d'ailleurs.

Je ne peux qu'abonder dans ton sens pour le contrôle de versions. Développer sans ça, même tout seul est soit criminel soit suicidaire. Je n'ai découvert cette merveille qu'en commençant à travailler et j'ai toujours trouvé ça inadmissible.

J'ai eu un coup du genre la veille de la remise de code la plus importante de mes études: on travaillait sur le compte de mon binôme et on faisait des copies sur le mien pour les backups. On décide de faire le dernier backup avant la nuit, j'efface l'ancien backup et mon binôme, au lieu de copier le code actuel, l'efface.... Tout perdu. (Précision pour les vieux: c'était sur OpenVMS)

En général, "Après les ultimes mises au point" le code est censé fonctionner correctement. Et là tu nous dit qu'en fait ça ne marchait pas ?
Le problème est apparu le jour de la soutenance, mais vous a fait suer pendant 2 ou 3 jours ? Chez nous une fois la soutenance passée c'était fini on avait pas de deuxième chance.

Sinon par rapport au projet UML, comment le prof a-t-il pu apprécier ou non ce qui ne lui a pas été présenté ??

Pour moi, les ultimes mises au point sont les dernières corrections à apporter.
Le problème n'est pas apparu lors de la soutenance, il existait déjà avant. On l'a corrigé avant la soutenance (d'où les var_dump et autres) mais mon binôme a pensé qu'enregistrer les pages corrigées sous un autre nom serait une bonne idée. Il a donc gardé les pages contenant les var_dump et autres sous le même nom.

Pour le projet UML, c'est de l'humour... Évidemment que le prof n'a pas apprécié de ne rien voir en face de lui, surtout pour cette raison. Il fallait le comprendre comme ça, mais je reconnaîs après coup que la forme de la phrase est foireuse.

En fait, après relecture, mon commentaire peut prêter à confusion. Je refais donc un historique :
Une semaine avant la soutenance, quelques problèmes existent encore. Environ 3 jours avant, il n'en reste plus qu'un, d'où le debuggage. Le problème est corrigé à 2h du matin, soit 6h avant la soutenance. Je demande à mon binôme, blablabla, cf PEBKAC.

Ah ok avec l'explication je comprends mieux :)

Je n'avais pas non plus saisi l'ironie pour le coup du projet UML. C'est sûr qu'une soutenance en mode "copie blanche" ça n'aide pas à gagner des points.

Pas grave, ça arrive à tout le monde. Et puis je reconnais que j'ai un style d'écriture assez lourd...
Et pour l'UML, le prof a demandé à voir ce qu'il avait fait avant du coup. Mais le gars a répondu (véridique, j'étais en train de me préparer dans la salle) :
"Bah vu que c'était de la merde, j'ai tout delete de partout, c'était pas la peine de le garder".

Tiens, personne ne relève ? Dire "AJAX et XML" c'est un peu redondant, sachant que AJAX signifie "Advanced Javascript And XML"... L'auteur aurait donc dit "Advanced Javascript And XML et XML". PEBKAC !

Pour ta gouverne, AJAX signifie Asynchronous Javascript And XML.
C'est qui le PEBKAC ? x)
Blague à part, c'est effectivement redondant, mais après tout, rien n'empêche de faire du XML uniquement avec le DOM de PHP. C'est plus pour indiquer les techniques à utiliser.