Flame Maker – Rendu intermédiaire

Le rendu concerne tous les fichiers Java créés lors des étapes 1 à 4 (incluse), à l'exception du contenu du paquetage ch.epfl.flamemaker.ifs et des classes principales (c-à-d possédant une fonction main), à une exception près : la classe nommée FlamePPMMaker du paquetage ch.epfl.flamemaker.flame. Sa méthode main doit produire les deux fractales d'exemple données dans l'énoncé de l'étape 4. Les images résultantes, au format PPM, doivent être écrites dans le dossier courant, dans des fichiers nommés respectivement shark-fin.ppm et turbulence.ppm.

Afin de rendre déterministes le calcul des images générées, veuillez utiliser la valeur 2013 comme graine (seed) du générateur aléatoire utilisé dans l'algorithme du chaos, en le créant ainsi :

Random rand = new Random(2013);

Faites aussi particulièrement attention à bien avoir 20 itérations avant d'accumuler les points. Le premier point accumulé doit être le 21^e généré par l'algorithme du chaos. Afin de tester votre code, nous vous fournissons une archive zip contenant l'image de la fractale Shark Fin, au format PPM. Votre version devrait y correspondre au pixel près.

L'outil que nous utilisons pour la détection de plagiat ne gérant pas les additions spécifiques à Java 7, vous ne devez utiliser que les éléments du langage Java 6 ou antérieur. Afin de vérifier que votre projet est compatible avec Java 6, ouvrez les options du projet dans Eclipse (entrée Properties du menu Project). Ensuite, cliquez sur Java compiler, désélectionnez Use compliance from execution environment… puis mettez le Compiler compliance level à 1.6. Si des erreurs apparaissent dans le projet, cela indique que des fonctionnalités de Java 7 sont utilisés. Ces erreurs doivent être corrigées avant la soumission.

Pour préparer votre rendu, nous vous fournissons un programme qui vérifie que tous les fichiers nécessaires existent et qui, si tel est le cas, les stocke dans un fichier d'archive que vous pouvez rendre via Moodle. Afin de pouvoir exécuter ce programme correctement, il vous faut suivre précisément les instructions ci-dessous.

Commencez par télécharger le fichier mid-term.zip. Ce fichier contient à la fois le programme de vérification et un script permettant de le lancer et de créer l'archive que vous devrez rendre sur Moodle.

Une fois le fichier téléchargé, faites un clic droit sur votre projet dans l'explorateur de paquetage (Package Explorer) d'Eclipse puis choisissez l'entrée Import dans le menu déroulant. Dans la boîte de dialogue d'importation, ouvrez le dossier nommé General puis faites un double clic sur Archive File. Ensuite, donnez le nom du fichier mid-term.zip puis cliquez sur Finish.

Une fois ces opérations terminées, vous devriez voir apparaître en bas de votre explorateur de paquetage un fichier nommé build.xml. En faisant un clic droit sur ce fichier, puis en choisissant Run As > Ant build, vous pouvez exécuter le programme de vérification et de création de l'archive. Si tout se passe bien, vous devriez voir s'afficher dans la console Eclipse un message ressemblant à ceci :

Buildfile: workspace/FlameMaker/build.xml
compile:
test:
     [java] Welcome to the API tester for the PTI project.
     [java] For any issue with the tool, please contact
            Michele Catasta (michele.catasta@epfl.ch).
     [java] All tests passed!
jar:
     [jar] Building jar: workspace/FlameMaker/pti.jar
BUILD SUCCESSFUL
Total time: 526 milliseconds

La ligne contenant le texte Building jar est celle qui vous indique l'endroit où trouver le fichier pti.jar à rendre sur Moodle.

Pour nous envoyer ce fichier, veuillez utiliser la page Moodle prévue pour ce rendu intermédiaire.

Merci de n'envoyer que des archives générées par le programme que nous vous fournissons. En cas de problème avec le processus de soumission, vous pouvez contacter Michele Catasta (michele.catasta@epfl.ch), par e-mail et en anglais.

Si pour une quelconque raison vous deviez rater le délai et qu'il ne vous soit donc plus possible d'effectuer votre rendu via Moodle, veuillez envoyer votre archive par courrier électronique à Michele Catasta (michele.catasta@epfl.ch). Attention : vos points seront réduits de 10% par heure entamée après 19:00, l'heure de réception de l'e-mail faisant foi. Par exemple un e-mail reçu entre 20:00:01 et 21:00:00 impliquera une réduction de 20% des points. Si vous envoyez l'e-mail après 5:00 du matin suivant, vous n'obtiendrez aucun point.

Pour éviter tout problème, nous vous recommandons fortement de soumettre une première version fonctionnelle de votre code dès que possible — idéalement durant la séance du 26 mars — et de la mettre éventuellement à jour par la suite, mais au plus tard à la date limite mentionnée plus haut.

Nous baserons l'évaluation du code pour 60% sur une évaluation automatique par tests unitaires. Pour garantir leur bon fonctionnement, les noms et signatures (ordre des paramètres et leur types) des fonctions publiques ainsi que leur modificateurs doivent correspondre à ceux décrits dans l'énoncé.

Les 40% restants des points seront attribués après une lecture attentive du code. 30% seront attribués en fonction des éventuelles erreurs dans les fonctionnalités qui n'auraient pas été détectées automatiquement et 10% porteront sur la qualité du code. A cet effet, nous avons compilé une liste de ce que nous estimons être les bonnes pratiques à respecter pour coder en Java. Cette liste n'est pas exhaustive et est principalement basée sur le guide de bonnes pratiques proposé par Oracle :

• Le code est proprement indenté. Eclipse peut indenter un fichier automatiquement en sélectionnant la totalité de son contenu (menu Edit > Select All) puis en le ré-indentant en sélectionnant l'entrée Correct Indentation du menu Source.
• Toutes les méthodes et classes sont commentées en utilisant la syntaxe de Javadoc. Vous pouvez choisir de le faire en français ou en anglais, mais n'utilisez qu'une langue dans tout votre projet. Eclipse peut vous aider à générer ces commentaires Javadoc en plaçant le curseur sur l'élément à commenter (classe, attribut ou méthode) puis en sélectionnant l'entrée Generate Element Comment du menu Source. Certains attributs sont automatiquement générés, à vous de compléter les commentaires judicieusement.
• Les parties de code complexes sont commentées afin de fournir des informations supplémentaires.
• Les composants des classes et interfaces apparaissent toujours dans l'ordre suivant :
  1. Les variables statiques triées par visibilité (les variables publiques en premier, puis les protégées, ensuite les variables sans modificateur de visibilité et enfin les variables privées).
  2. Les variable d'instance, également triées par visibilité.
  3. Les méthodes, triées par fonctionnalité et non par visibilité (p.ex. une méthode privée peut-être entre deux méthodes publiques si elle est utilisée uniquement par la première).
• Toutes les classes, variables et méthodes sont correctement nommées en anglais et en camel case, c-à-d que les mots qui forment un nom sont collés les uns aux autres et, à l'exception éventuelle du premier, commencent tous par une majuscule.
• Les noms de classes et d'interfaces commencent par une majuscule, les noms de variables et de méthodes par une minuscule. Les constantes sont nommées en majuscules avec des tirets bas "_" entre les mots. Les noms doivent avoir un sens, mais pas forcément être longs. Par exemple il est communément accepté de nommer i un index ou x et y des coordonnées.
• Le code est concis, clair et évite la duplication inutile. L'utilisation de variables pour les expressions se répétant plusieurs fois comme par exemple Math.pow(p.r(), 2) dans la variation Swirl est recommandée.
• Les exécution inutiles sont évitées. Par exemple, lors de la transformation d'un point, en vérifiant si le poids d'une variation est non nul avant de la calculer. Attention ce genre d'optimisation ne doit pas se faire au détriment des points ci-dessus.
• Les expressions booléenne sont utilisées de façon intelligente, par exemple :
  • if (e) return true; else return false;
    (remplacer par return e;),
  • if (e) return false; else return true;
    (remplacer par return !e;),
  • if (e == false) …
    (remplacer par if (!e) …).

Finalement, un entretien individuel sera effectué lors de la séance d'exercice du 9 avril. Les questions seront relatives à votre implémentation du projet et ne devraient pas poser de problèmes si les deux membres du groupes ont bien compris le fonctionnement du code qu'ils ont rendu.

Si vous ne parvenez pas à répondre de manière satisfaisante aux questions posées par les assistants, un malus individuel, pouvant aller jusqu'à une réduction de 50% des points, sera appliqué.

L'horaire de passage détaillé vous sera communiqué ultérieurement.