Discussion :

[0x4e84]

Et... l'heure fatidique est arrivée. Celle du couperet, ont imaginé quelques-uns. Le fait est que toutes les propositions étaient de qualité, bien que nous ayons dû sanctionner quelques manques de fonctionnalités, qui auraient pu être implémentées avec plus de temps. Mais c'est là aussi l'objectif d'un défi, finaliser une application dans les limites de temps imparties.

Trêve de vaines paroles, vous attendez tous probablement les résultats avec une impatience folle, concoctés dans nos marmites, avec quelques ingrédients de notre cru :

1. Amnell (57/60).
2. les geekologues (42,5/60).
3. 0x4e84 (29,75/60).

Toutes nos félicitations à Amnell !


Évidemment, tous les détails sont disponibles. N'hésitez pas à venir demander quelques explications supplémentaires sur certains commentaires s'ils ne sont pas clairs. Contrairement à l'année dernière, les sources sont disponibles participation par participation, exactement telles qu'elles ont été transmises par les participants.

Merci à tous pour cette édition, on se retrouve pour le troisième défi Qt !

Amnell, félicitations, et au plaisir de te croiser aux au Qt DevDays de Munich (je me suis inscrit la semaine dernière)!

Félicitations aux Geekologues aussi!

Et merci encore à l'équipe Qt de Developpez.com pour avoir organisé ce défi et avoir pris le temps d'évaluer nos projets.

0x4e84

[NassimKoceir]

Félicitations à tous les participants ! C'était pas facile ! :s

[LittleWhite]

Félicitations à Amnell (vous voyez, c'était sans surprise)

Bravo aux organisateurs.
Peut être au prochain défi :p

Notamment, le composant de logging utilisé n'a pas de documentation à part, bien que les sources soient commentées à cet effet - surtout que c'est le composant qui semble le plus prévu pour réutilisation

Ah oui O_o ... pourtant, y a un fichier .doxy pour cette partie. Et y a aussi la documentation de faite dans le .h

Quand il y a de la documentation, elle n'est pas mauvaise ; malheureusement, tous les fonctions, slots, classes, projets ne sont pas documentés.

Hum ... j'imagine que c'est à cause des fonctions vides de documentation (mais présente et vues par doxygen).
Je me suis toujours posé la question (depuis un an), à propos de l'histoire de documenter les fonctions fortement explicite (une fonction getNbOs(), on sait qu'elle retourne le nombre d'os).

Je remarque que moi, je n'ai eu le droit qu'à un retour du jury et non deux. Bon, je pense que j'ai de la chance sur ce point là

[Amnell]

Et bien, ça fait plaisir de trouver ceci après une longue journée !

Je n'ai d'ailleurs qu'un mot me venant aux lèvres : merci !

Merci aux responsables d'avoir permis à ce défi de voir le jour, aux participants pour avoir mis en place un esprit de compétition avec des soirées de codage plus ou moins intensif sur le chat de DVP, au jury d'avoir apporté ses commentaires - très attendus -, merci à tous, c'était un plaisir.

La partie fut longue mais ce fut pour moi un véritable... défi. L'occasion de valider les connaissances accumulées suite à une année de travail et d'appliquer des théories auxquelles je réfléchissais depuis longtemps (c'est-à-dire, le système template de la db, le système d'opcodes qui a entraîné quelques problèmes sous MSVC et le système de hooks - bien que finalement peu utilisé par rapport à ce que je prévoyais initialement : je n'avais pas prévu de donner un rôle si important au QML).

[ness522]

Félicitations à Amnell et autres aussi

[yan]

[johnlamericain]

Félicitation à tous !!!!

[Jerome S]

Petite question :
Savez-vous quand aura approximativement lieu le prochain défi ?
J'ai découvert aujourd'hui le principe, et j'apprécie énormément. J'ai déjà mon équipe prête à participer.

On est un petit peu impatient à vrai dire

[dourouc05]

Savez-vous quand aura approximativement lieu le prochain défi ?

Normalement, au troisième millénaire de notre ère .

[LittleWhite]

Félicitations à Amnell (vous voyez, c'était sans surprise)

Bravo aux organisateurs.
Peut être au prochain défi :p


Ah oui O_o ... pourtant, y a un fichier .doxy pour cette partie. Et y a aussi la documentation de faite dans le .h


Hum ... j'imagine que c'est à cause des fonctions vides de documentation (mais présente et vues par doxygen).
Je me suis toujours posé la question (depuis un an), à propos de l'histoire de documenter les fonctions fortement explicite (une fonction getNbOs(), on sait qu'elle retourne le nombre d'os).

Je remarque que moi, je n'ai eu le droit qu'à un retour du jury et non deux. Bon, je pense que j'ai de la chance sur ce point là

Hum, il y a toujours pas le rapport du deuxième juré, pour moi. J'ai vraiment besoin d'un code review (votre jugement sur la qualité de code) autre que pour le code du MedDatabase ...
Et il n'y a pas eu réponse à mes questions :s ; notamment face à vos critiques sur la Doxygen ...

[dourouc05]

À vrai dire, je ne vois pas ta documentation sur le système de log : dans le dossier Logger, on trouve bien un fichier .doxy, mais pas de documentation générée, au contraire du reste de l'application. En poursuivant un peu plus loin l'exploration, on retrouve facilement un dossier MedCenter, puis un dossier docs, puis une documentation HTML et LaTeX, qui correspond à celle de l'application. D'un point de vue positionnement, organisation du code, c'est assez spécial. Pour la documentation, vu qu'il n'y a pas de documentation générée, on peut facilement se dire qu'il n'y en a pas, bien qu'il y ait des commentaires style Doxygen : s'il n'a pas mis de documentation, c'est qu'il y a un problème pour la générer, peut-on alors penser.

(Sachant que de toute façon tu ne sauras pas qui est le deuxième juré, pour les raisons explicitées dans le document ).

Aussi, si tu n'as eu qu'une seule évaluation, ce n'est pas forcément une bonne chose, vu que tu n'as qu'un seul point de vue, tu pourrais te dire que c'est un juré qui ne t'aimait pas trop, alors que deux avis auraient été plus objectifs (c'est malheureux que tu n'y aies pas eu droit, mais on a subi un certain désistement de la part du jury, il n'était pas possible dans ces conditions de toujours respecter le timing pour offrir la place aux devdays...).

Pour la revue de code, il n'était humainement pas possible de passer sur tout le code de tout le monde (comme tu as pu le voir, deux personnes ont fait tout...), le choix des portions de code évaluées s'est donc fait soit au pifomètre soit à l'envie de voir la manière d'implémenter certaines choses, sans plus. Pour plus d'avis sur ton code, je pense qu'il serait bien d'ouvrir un sujet spécialement à sujet sur le forum, pour recueillir l'avis du plus grand nombre (s'il y a des émules, on pourra voir pour organiser ça d'une manière plus organisée).

Sinon, pour ta question sur la documentation : je dirais que toute méthode se doit d'avoir une explication, même sommaire. Il n'est rien de plus désolant que de voir une fonction sans un mot d'explication. Il n'est pas nécessaire d'avoir un pavé pour chaque fonction de base, simplement un mot pour expliciter ce qu'elle fait, pour ne pas se baser sur du potentiellement hypothétique, sur ce que toi tu penses qui va de soi. Exemple ? La documentation de symfony (http://www.symfony-project.org/api/1_4/). Franchement, par moment, je me demande vraiment pourquoi ils l'ont mise : l'autocomplétion d'un EDI correct donne un meilleur résultat ! Bon nombre de fonctions reposent sur de l'implicite, c'est-à-dire qu'on ne sait ce qu'elles font que quand on sait ce qu'elles font. Sinon, c'est de la lecture intensive de code pour comprendre ce que ça fait... Exemple : Qt (http://qt.developpez.com/doc/4.7/index/), plus particulièrement des méthodes comme QPoint::setX() (http://qt.developpez.com/doc/4.7/qpoint/#setx). Tu as un commentaire même si l'utilité de cette fonction est évidente.

En espérant avoir répondu au plus gros de tes interrogations .

[LittleWhite]

Alors, je n'aurais pas de deuxième juré Je suis vraiment déçu, car gbdivers m'avait beaucoup parlé sur le chat, semblait avoir beaucoup regardé les applications, mais si je n'ai aucun retour sur mon code, cela me tue. Je cherche à m'améliorer. Lors du premier défi Qt, on avait dit que je codais trop dans le style C. Je me demandais si c'était toujours le cas, ou non.
Après , qu'il n'y ai pas de poids dans le classement, cela ne m'importune guère, c'est juste qu'en plus gbdivers étant assez bon en C++ / design d'application, il pouvait m'apporter des indications sur ce que j'ai fait de mal (notamment, la gestion des messages réseau).
Et finalement (je me plains beaucoup), la seule partie de code qui a été commenté ... bah c'est la MedDatabase, qui est loin d'être centrale, ni même importante pour le programme que j'ai rendu.

On retrouve également pas mal de code commenté, ne laissant que très peu de code réellement compilé dans certaines fonctions, avec un résultat visiblement totalement différent de ce qui est annoncé par le commentaire

Et puis, que mon code soit commenté, c'est vraiment loin d'être important. Cela ne prendra aucune place dans l'exécutable final. Si je fais 20 essais d'un algorithme, j'aurais 19 fonctions d'essais, la vingtième qui fonctionne, donc les 19 autres commentés. Puis plus tard, il y aura un nettoyage.
Note: Le commentaire ne fait pas office de documentation ... d'ailleurs, ce fichier n'avait pas de documentation Doxygen si je me rappelle bien (Notez que vos liens sur nos archives ne fonctionnent plus)

Note 2: Je ne dis pas que la juré qui m'a noté

Sinon, pour la documentation, je vois et vous avez répondu à ma question.

[nicodmf]

Juste pour vous dire que le produit que vous développiez dans ce défi correspond à une demande réel du marché de la santé. En effet lors d'un entretient d'embauche dans l’hôpital de ma ville, un des recruteur m'a dit vouloir installer une solution de ce type .

Si vous voulez faire progresser votre soft, et pourquoi pas le commercialiser, je peux vous donner l'adresse d'un produit concurrent, qui pourrait vous inspirer quelques fonctionnalités supplémentaires...

Encore bravo tant aux organisateur qu'aux participants.

[johnlamericain]

Bonsoir à tous,

Juste un message pour vous indiquer le status des lots du défi.

J'ai récupéré le téléphone portable N9 (et non N900 comme annoncé) pour le vainqueur à savoir Amnell, il sera envoyé des que possible.

Le vainqueur ne pouvant pas participer au Qt Dev Days, j'y ai emmené le candidat le plus acharné de la deuxième équipe à savoir LittleWhite qui en à bien profiter et reviens avec des articles à écrire.

Pour l'ensemble des autres participants et jurys, des T-shirts sont en cours d'envois par le bureau de Qt à Oslo et vous pouvez espérer les recevoir la semaine prochaine.

A bientôt pour le défi n°3, ça commence à prendre forme