Concours - implémenter une itf simple de gestion d'agenda. [java/algo] - Java - Programmation
Marsh Posté le 04-01-2004 à 03:31:51
[ 1er concours proposé : implémentation d'une interface simple de gestion d'agenda ]
L'interface à implementer: Planning. L'idée de base est de pouvoir y gérer une liste de Period qui ne se recoupent pas, une Period représentant une periode/plage de temps d'activité déterminée par une Date de début, de fin, et une description.
Pour que les interessés puissent se mettre au boulot, voici les sources de l'interface à implémenter:
http://rien.a.dire.free.fr/concour [...] nning.html
Et le TestCase à faire passer:
http://rien.a.dire.free.fr/concour [...] tCase.html
Sources à télécharger:
http://rien.a.dire.free.fr/concour [...] _1-src.zip
Autres sources intéressantes à voir dans le répertoire:
http://rien.a.dire.free.fr/concours_java_1/
Quelques explications:
OverlapingPlanning: un exemple d'implementation de Planning, mais qui ne passe pas le test "testOverlap": c'est là que se trouve la majeure partie du défi (du moins j'espere, sinon va etre vite torché le concours), le but étant de gérer, d'empecher le fait que l'on ajoute plusieurs Period qui se chevauchent sur un meme Planning.
PlanningContestTestCase: c'est le TestCase à passer. Pour vous tests "à la maison", modifiez-les lignes 30 & 56 pour qu'elles retournent une nouvelle instance de votre implémentation. (ContestTestSuite.getInstance() renvoie une instance de l'implémentation en cours de test dans le système de gestion du concours). Faites le aussi étendre junit.framework.TestCase, simplement, au lieu de ContestTestCase, il s'agit aussi d'une astuce spécifique au framework que j'ai fait pour le concours.
(On pourra peut etre trouver quelque chose de plus convenant à l'avenir mais bon)
Concernant l'interface Period: réimplémentez-là à votre guise, ou utilisez BasicPeriod si celle-ci vous convient.
Il se peut que de nouveaux tests viennent s'ajouter aux deux présents actuellement, et peut etre même un petit test de performance, si l'inspiration est au rendez-vous.
A vos claviers!
ps: si la doc n'était pas suffisament complète ou que vous aviez des questions, n'hésitez surtout pas.
Marsh Posté le 04-01-2004 à 07:32:32
tiens, j'ai trouvé un truc marrant pour pour faire le test !
Marsh Posté le 04-01-2004 à 08:43:47
-- > pourquoi le TestCase il dérive de ContestTestCase ? c'est une classe à toi ça non ? on peut pas utiliser JUnit sans modifier le test alors.
Marsh Posté le 04-01-2004 à 14:47:38
nraynaud a écrit : -- > pourquoi le TestCase il dérive de ContestTestCase ? c'est une classe à toi ça non ? on peut pas utiliser JUnit sans modifier le test alors. |
ben oui, comme je l'ai écrit. y'a qu'a modifier l'extends et les lignes 30 & 56 (puisque de ttes façons, à moins d'imposer un nom pour l'implémentation, je ne peux pas deviner le nom de la classe à instancier dans le test)
Marsh Posté le 04-01-2004 à 16:28:11
Voilà, j'ai bougé le tout sur free, plus de pubs et le css est respecté.
Marsh Posté le 04-01-2004 à 21:24:21
the real moins moins a écrit : ben oui, comme je l'ai écrit. y'a qu'a modifier l'extends et les lignes 30 & 56 (puisque de ttes façons, à moins d'imposer un nom pour l'implémentation, je ne peux pas deviner le nom de la classe à instancier dans le test) |
Ben tu imposes le nom d'une factory ?
paske là, c'est nous qui ne pouveons pas utiliser les tests. J'ai fait du copier-coller vers ma propre classe.
Marsh Posté le 04-01-2004 à 21:33:07
nraynaud a écrit : Ben tu imposes le nom d'une factory ? |
certes, il faudrait une solution plus adéquate.
Marsh Posté le 05-01-2004 à 02:09:51
ReplyMarsh Posté le 05-01-2004 à 02:33:35
bon, 'faut que je me grouille de débugger alors.
Marsh Posté le 05-01-2004 à 02:54:19
putain, mais testOverlap et testBoundaries ne sont pas compatibles !
je pouvais toujours essayer de vérifier mon getPeriods() avec ça !!!
Marsh Posté le 05-01-2004 à 03:10:46
ReplyMarsh Posté le 05-01-2004 à 03:47:07
si testOverlap passe alors testBoundaries echoue (enfin, en considérant que le comportement du reste est normal).
Code :
|
donc forcément, les nombres calculés avec overlapping sont faux.
sinon, rien à voir, mais pour que les tests soient plus faciles à lire, j'ai fait un truc comme ça :
Code :
|
ce qui permet de lire l'ordre des dates et la tronche des périodes au premier coup d'oeuil.
Marsh Posté le 05-01-2004 à 03:55:37
nraynaud a écrit : |
ha ouais putain merde!!!
pas fait gaffe à ça moi! Au début j'avais ce test qui tournait pour mon OverlappingPlanning et je l'ai remis là comme un con
nraynaud a écrit : |
bien vu
si t'as une classe de TestCase à jour qui est plus correcte, on peut la changer
Marsh Posté le 05-01-2004 à 03:57:49
attention à tenir compte du fait que getPeriods doit retourner une Period meme si elle n'est pas intégralement dans l'intervalle donné (ie si elle commence avant la fin de l'intervalle mais termine apres, elle doit etre retournée, ainsi que si elle commence avant l'intervalle mais se termine dans ou apres l'intervalle)
Marsh Posté le 05-01-2004 à 04:01:55
the real moins moins a écrit : |
heu non, pas encore (je les écris et debugge au fil de l'eau). D'autre part, j'en ferais une un peu "strippée" car certains tests donnent des indications sur l'implémentation (car leur écriture est guidée par la couverture de code).
juste un petit bout :
Code :
|
Marsh Posté le 05-01-2004 à 04:02:54
the real moins moins a écrit : attention à tenir compte du fait que getPeriods doit retourner une Period meme si elle n'est pas intégralement dans l'intervalle donné (ie si elle commence avant la fin de l'intervalle mais termine apres, elle doit etre retournée, ainsi que si elle commence avant l'intervalle mais se termine dans ou apres l'intervalle) |
oué, je teste pas encore ça, d'où mes intervalles qui permettent pas de le faire.
Marsh Posté le 05-01-2004 à 04:04:13
bien vu!
bon, je verrai peut etre ça demain. J'espère que d'autres montreront un peu d'interet !
merci en tous cas.
Marsh Posté le 05-01-2004 à 06:06:33
bwalé, je suis sympa :
Code :
|
cette classe couvre *tout* sauf les assertions chez moi.
Marsh Posté le 05-01-2004 à 06:16:53
je met ça en place demain entre 2 vaisselles.
Marsh Posté le 05-01-2004 à 06:51:56
tu relis et tu vérifies d'abord stp, c'est la première fois que je fais ce type de tests.
Marsh Posté le 05-01-2004 à 11:04:38
pas mal comme sujet de concours
Mais c'est vrai qu'après faut avoir le temps de s'y mettre
Marsh Posté le 05-01-2004 à 17:31:03
merde ça a buggé et planté avant de s'occuper de la participation d'nraynaud
Marsh Posté le 05-01-2004 à 17:43:14
nraynaud, pourrais-tu re-uploader ton archive avec uniquement les sources?
Marsh Posté le 05-01-2004 à 22:26:54
je ne te félicite pas !
Marsh Posté le 05-01-2004 à 22:28:09
nraynaud a écrit : je ne te félicite pas ! |
pour le coup des sources, c'est juste que pour ce concours le nombre maxi de fichiers par archive est à 8
mais bon, de ttes manières, après avoir corrigé ça j'ai trouvé un bug dans la gestion des tar qui fait qu'il pourra plus compter le nombre de fichiers tant que ce bug est pas corrigé, donc...
Marsh Posté le 05-01-2004 à 22:32:26
chage le testcase aussi stp.
edit : en plus les sources sont accessibles avant la fin du concours, je vais me faire piquer mon idée pas-si-bonne-que ças !
Marsh Posté le 05-01-2004 à 22:35:27
je suis en train de le regarder:
la dernière methode de test n'est pas correcte: un Period n'est pas determiné que par ses Date de début et de fin, mais aussi par la description etc.
edit: et le 2e groupe d'assertions dans ce test, c'est specifique à ton implementation à base de Proxy non ? sinon je n'en vois pas bien l'interet
Marsh Posté le 05-01-2004 à 22:37:21
nraynaud a écrit : |
oui j'y ai pensé à ça. je les vire? ou bien on se dit que ça va permettre une émulation au sens du groupe et à chacun de progresser? (on peut dire qu'on permet de participer plusieurs fois )
Marsh Posté le 05-01-2004 à 22:48:04
the real moins moins a écrit : je suis en train de le regarder: |
1) j'ai fais ce que j'ai voulu, il n'y avait rien de marqué dans Period.java et mon seul but était de couvrir les testcases. Je vais modifier les tests et mon entrée alors.
2) si tu parles de ce que j'ai posé sur ton site, oui. Le test public est celui dans la page ici.
Marsh Posté le 05-01-2004 à 22:52:23
nraynaud a écrit : |
rassure-moi, c'est le meme avec juste une methode en moins ?
je suis en train de revoir ton testcase. j'ai remplacé les assertions sur l'iterator par des assertions sur la taille de la collection retournée et des coll.contains(...), histoire de ne pas dépendre de l'ordre de la collection retournée, vu que ce n'est pas précisé dans le contrat. (ça aurait pas été con de le faire, cela dit - mais si on fait ça, on peut ajouter une méthode de test specifique pour l'ordre, c'est meme mieux, on sépare ainsi les "concerns" )
Marsh Posté le 05-01-2004 à 22:56:53
encore un truc, d'apres ton test, qd on fait getPeriods sur t1,t2, ça ne devrait pas retourner une period qui commence à t2 ... or ça devrait, je pense
Marsh Posté le 05-01-2004 à 22:57:55
ah oui, bonne remarque.
Non, ne teste pas l'ordre, il est pas marqué dans l'interface.
edit :
heu oui, mais contains repose sur equals() qui n'est pas défini, assure-toi de l'identité.
Marsh Posté le 05-01-2004 à 23:15:39
the real moins moins a écrit : encore un truc, d'apres ton test, qd on fait getPeriods sur t1,t2, ça ne devrait pas retourner une period qui commence à t2 ... or ça devrait, je pense |
non, car si tu veux avoir tes réunions de 9h à 10h, tu ne veux pas celle qui comence justement à 10h.
Marsh Posté le 05-01-2004 à 23:20:05
nraynaud a écrit : non, car si tu veux avoir tes réunions de 9h à 10h, tu ne veux pas celle qui comence justement à 10h. |
auquel cas ton appli devrait demander de 9h a "10h moins un chouilla".
Marsh Posté le 05-01-2004 à 23:39:58
the real moins moins a écrit : auquel cas ton appli devrait demander de 9h a "10h moins un chouilla". |
j'ai pris le parti d'avoir des bornes qui se recouvrent, car l'utilisateur de base, les ensembles ouverts, il s'en fout. Et dans la mesure du possible, on parle le même vocabulaire dans et hors de l'application.
Maintenant, si t'insiste, ce n'est qu'une question de 2 '=' à virer dans mon entrée normalement.
Bon, ils arrivent ces nouveaux testcases ?
Marsh Posté le 05-01-2004 à 23:49:48
nraynaud a écrit : j'ai pris le parti d'avoir des bornes qui se recouvrent, car l'utilisateur de base, les ensembles ouverts, il s'en fout. Et dans la mesure du possible, on parle le même vocabulaire dans et hors de l'application. |
ben disons que ça me parait plus clair au niveau de l'api d'inclure dans tous les cas, que de commencer à jouer sur le fait qu'on inclut pour la borne du bas mais pas pour la borne du haut, non ?
et oui, les testcases arrivent. je modifie qques bricoles en meme temps.
Marsh Posté le 05-01-2004 à 23:56:34
the real moins moins a écrit : ben disons que ça me parait plus clair au niveau de l'api d'inclure dans tous les cas, que de commencer à jouer sur le fait qu'on inclut pour la borne du bas mais pas pour la borne du haut, non ? |
non on inclus pas la borne du bas.
quand l'utilisateur veut le planning de çh à 10h, on lui file pas les réunions qui finissent à 9h pile, ni celles qui commencent à 10h pile.
Marsh Posté le 04-01-2004 à 03:31:27
Hello les gens,
Topic concept, inspiré en partie par les concours des grapheux, et par un petit problème qui m'est tombé dessus lorsque j'ai voulu commencer un simple petit projet.
Pré-requis:
- un minimum de connaissance de Java et de la poo en général
- junit (http://www.junit.org, peut s'apprendre sur le tas en 5 minutes)
Le principe:
Je fournis les éléments suivants:
- une interface à implémenter
- un ou des testcases à passer
Bien entendu, si le concept fonctionne, j'espère ne pas être le seul à proposer des concours
Les participants du concours doivent donc, au minimum, implémenter cette interface de manière à ce que les tests soient positifs.
Chaque forumeur pourra "voter" pour 5 participations (en esperant qu'il y en ait assez), en fonction des critère de vote qui lui semblent importants. (voir ci-dessous)
Critères de vote:
- lisibilité du code
- élégande du code, des concepts, du design
- performance
- ...
Votes:
Si le temps le permet, ou si une bonne âme se dévoue, une interface ouaibe sera proposée pour recueiller les votes. Sinon, on fera comme les grapheux, à la mimine
Participation:
Ha! Évidemment! Comment qu'on participe moins moins!?
Bien, c'est là dessus que je buche depuis quelque jours. Maintenant j'ai un système entièrement automatisé qui marche. Du moins je crois.
Le principe est simple:
- on uploade son archive de participation sur un formulaire qui se trouve ici:
http://rien.a.dire.free.fr/concours_java_1/upload/, en remplissant quelques champs (votre nom et le nom de la classe principale en "fully qualified", c-à-d nom de package inclus, par example "fr.hardware.forum.concoursjava.MyAgenda" )
- toutes les 8 heures, le serveur analyse les archives, compile, lance les tests et génère un rapport pour chacune des participations, ici:
http://rien.a.dire.free.fr/concour [...] atest.html
Critères de validité:
Vous devez fournir votre participation sous la forme d'une archive tgz ou zip, contenant uniquement les sources.
Pour chaque concours, un nombre maximal de fichiers par archive, et une taille maximale d'archive est déterminé.
A la racine de votre archive doit se trouve votre package "root", c-a-d si vous travaillez dans le package com.pouet.machin, le premier niveau de l'archive doit comporter "com", pas de sous-repertoire "src" ou autre, sans quoi l'archive sera rejetée par le système. Si ceci s'averait etre une contrainte pour beaucoup d'entre vous, je pourrais toutefois adapter le système
Les licenses restrictives sur vos sources ne seront pas acceptées. Les licenses "classiques" du logiciel libre et open-source seront bien entendu acceptées, à condition qu'elles n'entrent pas en conflit avec les sources du concours lui-même.
edit du 1/2/2005 : phrase corrigée
Message édité par the real moins moins le 01-02-2005 à 01:28:43
---------------
Hey toi, tu veux acheter des minifigurines Lego, non ?