Les pieds dans le code

Pour apprendre à programmer, le mieux est de metre les pieds dedans.

Participants

Yohann est en congé

Hafid peut-être libéré mardi, avec un CV actualisé.
Simon a fait une station météo avec un petit rapide.
Simon a utilisé du «ça tu la déjà fait avant», et ça a bien fonctionné avec ce gamin qui avait l’air de comprendre vite. A retester avec d’autre.
Hafid n’a pas fait de Lua
Mélanie a fait des entretiens, mais elle est là ce matin.
Mélanie à repris ses cours JavaScript sur «Code Academy».
Yannick à reparle de monkeypactching en Ruby.
Hafid à appris en Vim CTRL+f et CTRL+b, et :bdelete ou :bd

Pour explorer la structure d’un serveur, nous allons faire un kata jeu de nim en réseau.

Premier debrief

Finalement on déroule le jeu de nim en TDD pour le moment.
Refait fiche python, intéressant pour Mélanie, mais ça aurait été bien que ce soir Hafid et Simon qui la fasse (et pas Yannick).
Hafid à posé le setup des test unitaires plutôt rapidement.
«Nous n’avons peut-être pas fait assez d’objet» –Yannick.
«Relation entre une classe et un constructeur ? (Similitude ?, ressemblance ? Différence ?)» –Hafid.
Un peu le bordel pour Mélanie.
«les objects, c’est abstrait» – Mélanie.
Le but d’un object c’est de retenir plusieurs valeurs, contrairement à une variable qui ne contient qu’une seule valeur.
«Est-ce qu’on parle d’architecture là ?» –Hafid
L’architecture, c’est une sorte de hierarchie, d’organisation, c’est quand on assemble des pièces qui forme un programme.
Conclusion d’Hafid : «Oui, on fait de l’architecture quand on parle d’un objet»

Deuxieme debrief

On refait les deux tests du précédent round, mais sans objet, avec un variable et une fonction.
«Sentiment d’avoir perdu tout le monde ce matin» –Yannick.
Sauf peut-être Simon.
Rappel sur le fait que le paradigme Impératif inclu le paradigme Objet qui lui même inclu le paradigme Functionnel.
Python étant Impératif, on peut avoir un style de programmation orienté Objet ou orienté Functionnel.
Mélanie comprend mieux pourquoi le paradigme fait partie des éléments de la fiche langage.
Est-ce que le nombre de variable que l’on doit manipuler/stocker permet de savoir si nous devons faire de l’objet ou pas ?

Troisième debrief

On avance dans la version fonctionnelle.
On révise le fait qu’en TDD il faut plutôt penser au cas d’utilisation qu’à l’implémentation.
L’ordre d’écriture des tests influence la façon de résoudre un problème.
Ce dernier point rappel des choses à Simon.
Comme pour le kata bowling la dernière fois, c’est une bonne idée de réviser ce qu’on veux faire avant de travailler.
Faut-il lister toutes les choses à faire avant de les faires ?

On continue ce qu’on a fait ce matin.
Le constructeur permet d’embarquer un contexte particulier dans une instance d’un objet.
Hafid est beaucoup dans l’implémentation.

debrief

On a manipuler la version Objet du jeu de Nim.
C’est chouette de revisiter les objets.
Une classe et un conteneur de fonction (qu’on appel du coup méthode).
Différence entre attributs et méthodes pas clair.
Difficile de faire le rapport entre les objets JavaScript et les objets Python.
Haifd trouve qu’il y a un parallèle entre les objets et les bases de données.
Ce parallèle existe particulierement avec les base de données orienté document comme mongodb, couchdb, …
Développer un logiciel c’est faire des aller-retour sur les niveaux de zoom, comme entre voir la Terre vue du ciel, et la voir les pieds dessus.
Pour faciliter le travail, il faut décomposer le code d’un logiciel jusqu’à ces instructions.
Une instruction c’est une ligne de code (de commande ?), on peux pas faire plus bas.