Salut tout le monde.Vous n'aurez pas manqué de remarquer l'arrivée d'un joli répertoire doc/livrable2/ qui est là pour vous faire souffrir quelques jours. Le L2, vous le savez ou pas, on le rend vendredi soir minuit, dernier délai.
Et comme d'hab, c'est cool d'avoir une beta avant. Comme ça, on donne à Eddy et il nous fait ses remarques. Et on rattrape le coup des machins qu'on a oublié.
Cependant, il me faut vous précisez quelques points :- Quand on dit la beta est à rendre pour le tant à telle heure, ça veut dire qu'on évite de commiter le fichier le tant à telle heure plus un. Bonnes ou mauvaises excuses à l'appui. Spéciale dédicace à thias. - On ne compte pas sur le gentil Sylvain pour relire son bout de livrable et suggérer ce qui va pas. Le gentil Sylvain, il le fait, parce que ça fait partie de son boulot, mais il s'agit d'une relecture d'ordre mineure, pour harmoniser, fignoler. Pas pour faire le gros du boulot que vous êtes censé faire. En particulier, un bout de livrable dans lequel la densité de fautes d'orthographe/grammaire/syntaxe est supérieure ou égale à 1 par mot ne peut en aucun cas me laisser de doutes sur le fait que vous n'avez pas fait votre boulot. Spéciale dédicace à standaba. - Il y a un pas entre faire et dire qu'on pourrait facilement faire. C'est une remarque qui vaut en toutes circonstances (en particulier en ce qui concerne le code que nous sommes censés pondre). Mais en la circonstance, je veux dire par là que, si vous êtes chargé de rédiger un truc dans le livrable, vous êtes vraiment chargé de le faire. Et le faire ne se réduit pas à me dire : « ben voilà : en fait, tu prends ce qui est écrit là, tu le recopies en mettant tout au singulier, puis tu prends ce qui est écrit là, tu vires le troisième paragraphe qui n'a plus lieu d'être, et tu rajoutes une phrase bidon de conclusion. ». Je suis content pour vous que ce soit aussi simple que ça à faire. Mais c'est justement à vous (petits veinards) qu'échoit cette tâche. Bilan : si vous devez faire un truc, vous le faites et en entier. Spéciale dédicace à smimou alias foys.
Cela étant, on a fait un beau boulot pour le L1, même si ça a pas été sans douleur. Je compte bien qu'on remette ça aujourd'hui.
Je propose une beta pour jeudi soir minuit. Oui, c'est bien ça : demain soir. Et comme j'ai cours à 8 heures le lendemain matin, on s'attardera pas trop au delà de minuit pour la beta. Donc rapidité et précision.
Petit état des lieux : cette fois, j'ai mis des includes, de façon à ce qu'on puisse paralléliser. Le fichier en lui même est livrable2.tex. Il fait des include pour chaque sous-projet. LEs fichiers qui vous concernent sont les SPn.tex où n est votre numéro de SP (cf livrable1). Vous faites des modifs là-dedans, et a priori exclusivement là-dedans, sauf si vous avez été mandaté par moi-même pour cela. C'est pour éviter les merge désastreux qui font perdre des heures.
Vous êtes priés de lire toute la partie avant les sous-projet aussi. Parce que mine de rien, j'y raconte des trucs, et il serait bon qu'il n'y ait pas de contradiction entre votre vision pointue de votre SP et ma vision plus vague de la chose. Par ailleurs, jetez un œil sur le source de livrable2.tex : des commandes y sont définies. Vous les utiliser à l'exclusion de toute autres (pour éviter des conflits) et vous ne dites jamais Savonet, IRC, FTP, C, OCaml, etc. sans passer par une commande. C'est pour des questions d'harmonisation. Donc prenez -en bien connaissance pour ne pas oublier par mégarde d'utiliser certaines commandes.
Il est possible de rajouter des commandes si vous le désirer, mais il vaudrait mieux éviter, afin de ne pas piétiner. Quand quelqu'un rajoute la commande \toto, il faut que tout le monde relise son bout de livrable pour corriger les totos. Donc on préfère éviter. Les commandes qui sont en, tête de fichier ont été débattues en petit comité et on est tombé d'accord sur ce qui est dans le fichier. Donc il ne devrait pas trop y avoir de raisons d'en changer.
IMPORTANT, POUR TOUS : Quelques remarques d'ordre générale sur l'emploi de certains mots : - Le terme librairie n'est pas français. On parle de bibliothèque en français. C'est pas facile d'éviter de l'écrire, parce que ça sort tout seul, mais faites un effort tout de même. Ça coûte rien de faire un search librairie quand vous avez fini votre bout de livrable. - On ne parle pas chan ou de channel IRC, mais de de canal IRC. Et IRC, c'est \irc, je vous rappelle. - Si vous devez citer une url, vous avez \url{http://mon_site_qui_tue_sa_mort.html} pour ça.
CE QUE VOUS DEVEZ FAIRE pour ce livrable:pour l'instant, je me suis contenté de recopier ce qu'il y avait dans le L1 pour chaque SP. À peu près tous les SP ont la structure suivante :
Équipe de développement
Description
Objectifs
Organisation/Détail d'architecture
Dépendances
Estimation de la durée de développement
A priori, l'équipe de développement, et la description ne devraient pas
changer. Vous pouvez retravailler votre description, si vous la trouvez
foireuse/incomplète/pas précise. Mais la règle du jeu, c'est que vous
avez promis, vous n'avez pas le droit de vous en défausser. Donc
ajout/amélioration oui, mais retrait, non.
Les objectifs, j'ai le sentiment que ça va peut-être faire mal à
certain d'entre vous quand ils vont voir leurs objectifs. Là idem, pas
trop le droit d'enlever des objectifs comme ça, en douce. Mais comme il
faudrait quand même pas que vous soyez acculés au suicide, vous avez le
droit de revoir à la baisse. MAIS À UNE CONDITION : que vous
mentionniez clairement que vous êtes en train de revoir à la baisse (il
vaut mieux être franc et expliquer que tenter d'arnaquer les gens
derrière leur dos : s'ils s'en aperçoivent, ils seront pas content, et
en plus, vous perdrez toute crédibilité sur le reste) ET que vous avez
de BONNES raisons de revoir à la baisse : typiquement, vous avez
réfléchi, et tel et tel points techniques difficiles et que vous
n'aviez pas vu (i.e. pas évoqué dans le L1) vous sont apparus. Vous
réévaluer alors le problème en terme de temps de développement et
essayez dans toute la mesure du possible de proposer un substitut que
vous pourrez rendre dans les temps.
Sur l'organisation/détail d'architecture, vous ajoutez la ou les rubriques si elle étaient inexistantes et vous agrémentez abondamment de commentaires sur la situation actuelle. Il faut qu'on voit que vous avez travaillé, que vous respectez relativement bien l'organisation proposée. Le cas échéant, vous précisez tel ou tel changement qui est apparu dans votre archi. Les problèmes que vous avez soulevés dans votre réflexion sur l'archi. Vous devez mettre en valeur le travail que vous avez fait. Il faut des choses concrètes, pas des vagues trucs du genre « ça, c'est quasiment implémenté. En fait, c'est extrêmement simple, il suffit de faire ça... Je ne l'ai pas encore totalement fait, mais je le ferai bientôt ». C'est à PROSCRIRE totalement (cf ma remarque au début du courriel). Vous pouvez faire une partie « État des lieux » si vous le jugez nécessaire, pour bien mettre en valeur ce qui est fait, en train de se faire, et ce qu'il vous reste à faire. DU CONCRET.
La partie dépendances doit devenir précise : qu'est-ce que vous attendez au juste de la part de tel et tel sous-projet. Si des dépendances sont apparues que vous n'aviez pas prévue, mentionnez-le. Montrez que vous pouvez quand même travailler en ce moment, bien que les autres sous-projet n'est pas encore résolus vos problèmes de dépendances, et que justement, vous faites pleins de trucs. Efforcez-vous aussi de montrer que vous avez pour priorité de résoudre les points de votre SP qui sont nécessaires aux autres SP. Soyez clairs et francs sur ces histoires de dépendances. Ça nous permettra de faire un point précis entre nous, pour recentrer notre travail.
Estimation de la durée de développement : ben vous mettez à jour, et vous montrez que, bien que vous ne teniez pas exactement votre emploi du temps, ça ne vous empêche pas de faire le travail à un rythme tout à fait acceptable, vis à vis du fait qu'il faudra fournir un produit fini dans un mois.
Bon courage à tous. Je veux une version demain à 23h30, de façon à balancer la beta à minuit dernier délai.
Sylvain
PGP.sig
Description: PGP signature
