Tirons vers le haut

C'est la rentrée. Ça n'aura échappé à personne. Et la rentrée, ça implique tout un tas de réunions d'information aux parents, comme ils disent. Ce soir, j'ai assisté à celle des 4èmes. Le blabla habituel, pour l'essentiel. Les profs que je n'aurais probablement pas aimé avoir (et que je n'aime toujours pas, je crois), les profs sympathiques, ceux qui font juste leur boulot, et ceux qui sortent de l'ordinaire.

Et grâce à un de ces dernier, ee soir j'ai également assisté à quelque chose que je trouve très intéressant, et que je me sens obligé de partager.

Cela s'est produit pendant l'intervention du prof de physique/chimie. Il explique un peu ce qu'il vont faire, et comment il procède. En particulier, pour les parties pratiques, il répartit les élèves par groupes de 4. Tout le monde acquiesce. Puis il explique que pour évaluer les travaux réalisés en groupe, il prend un travail au hasard dans chaque groupe et que tous les élèves du groupe seront notés sur ce dernier.

Pendant les quelques secondes que je prenais pour réfléchir à cette méthode peu courante, une ou deux mamans commençaient à s'agiter. Puis finissent par exprimer leur malaise : "mais c'est injuste !".

Le prof feint un air surpris. Les mamans enchaînent pour essayer d'expliquer leurs craintes que des éléments qui ont des difficultés (forcément minoritaires, à les écouter) ne viennent pénaliser les bons élèves (lourdement sous-entendu : leurs enfants). Il ne faudrait pas que les mauvais élèves ne "tirent vers le bas" les bons.

J'ai beaucoup aimé la réaction de l'enseignant, qui, de toute évidence, pratique cette manière de faire depuis des années.

Avec un grand sourire, il explique posément que non, les "mauvais" ne tiraient pas les bons vers le bas, mais qu'on assistait plutôt à l'inverse. De plus, cette sorte de solidarité imposée poussait finalement les enfants à coopérer, s'organiser et à faire pression sur les perturbateurs pour qu'ils jouent le jeu. Bien entendu, en cas de comportement extrême de certains, le prof intervient.

Il a fini, toujours avec un grand sourire, sur le fait que tout "allait bien se passer", en enterrant en quelques minutes le mythe de la traction vers le bas des meilleurs par les moins bons si on les mélange.

Je précise que je vis dans une ville que l'on qualifie de "favorisée", loin des Zone d'Éducation Prioritaires et autres Zones Sensibles. La réaction de ces parents, est, à mon sens, assez emblématique d'une certaine façon de penser que certains aimerait bien voir se généraliser.

Mais j'ai pu constater ce soir avec plaisir qu'il y a encore des profs qui apprennent à nos enfants que ce n'est pas forcément la seule voie, et qu'il est possible de travailler ensemble, de coopérer pour l'intérêt du groupe.

Le temps

Je n'ai pas assez de temps ! Les journées ne sont pas assez longues pour tout caser. Il y a tellement de choses à apprendre, essayer, découvrir ! Et en parallèle, tellement d'autres à faire pour faire avancer le quotidien. Et il y a toujours trop d'imprévus pour pouvoir espérer planifier quoi que ce soit. Mener de front une vie familiale active, un travail et une vie de geek me paraît plus tenir de l'exploit qu'autre chose.

Bien entendu, il y a des méthodes pour mieux gérer son temps (GTD, Pomodoro, et j'en passe), mais je trouve qu'elles ne résistent pas bien aux aléas de la vie. Et, autant je trouve possible de limiter l'inattendu au niveau professionnel, en tous cas de le circonscrire, autant il est difficile à éviter dans la vie familiale quotidienne. De plus, elles demandent toutes une certaine rigueur que je n'arrive pas à tenir dans ma vie privée. Je ne sais pas pour vous, mais les listes de choses à faire qui s'allongent jusqu'à ce qu'on décide de ne plus les regarder pour éviter la dépression ne me réussissent pas. Les emplois du temps fixes et bien régulier sont trop tristes. La vie ne manquerait-elle d'ailleurs pas un peu de piquant si elle était trop strictement réglée.

Et encore, j'ai réussi à joindre l'utile à l'agréable en travaillant dans ce qui me passionne. En plus, mon boulot a pris une orientation qui me permet presque de geeker en travaillant. Ou de travailler en geekant. Je ne sais plus trop :-).

Pour le reste, cette soif, ce besoin proche de l'addiction de découvrir, d'apprendre, il me reste les nuits. Mais dormir n'est pas désagréable non plus, finalement.

Voilà. Un constat, une réflexion plus qu'autre chose. Des choses qui me trottent dans la tête et qui doivent sortir. Peut-être aussi une sorte d'appel aux trois lecteurs de ce blog : y a t'il des papas geeks dans la salle ?

C'est moi, ou bien il y a comme de l'écho par ici ?

Netbeans et CMake

Nombreux sont ceux qui demandent le support de Netbeans dans CMake. Je me demandais également comment intégrer CMake dans un développement utilisant Netbeans. En fait, la réponse est simple : CMake n'est pas capable de créer des projets Netbeans, mais ce dernier est capable d'importer des projets CMake. Il suffisait de se poser la question différemment, comme souvent, pour obtenir la réponse.

Pour importer un projet CMake, il suffit de créer un nouveau projet en choisissant d'importer un projet à partir de sources existantes, puis de sélectionner le mode de configuration automatique (en ayant bien pensé à supprimer les éventuels Makefiles qui auraient pu être générés). Un Makefile et un projet sont créés.

Par la suite, si des modifications sont faites dans CMakeLists.txt (ajout de fichier, de librairies, etc), il suffit d'aller faire un clic droit sur le projet dans Netbeans, puis de choisir Reparse Project dans Code Assistance (oui,  j'ai laissé mon environnement en anglais). Le projet est alors mis à jour en conséquence.

Plutôt simple, non ?

Tests unitaires et C++

Jusqu'à récemment, j'utilisais CppUnit pour implémenter mes tests unitaires en C++. Le choix avait été plus ou moins dicté par le fait qu'il était l'héritier direct de JUnit et qu'il proposait (enfin était sensé proposer) une méthode simple pour pouvoir afficher les résultats dans une fenêtre graphique (la liste des points verts ou rouges qui donne un aperçu rapide de l'état des tests).

Mais, à l'usage, CppUnit m'a semblé de plus en plus lourd à mettre en œuvre et à utiliser. Je passais trop de temps, à mon goût, sur l'écriture des tests (définition et implémentation des classes, principalement) par rapport au temps que je passais à réfléchir à l'essentiel, à savoir le code sur lequel je travaille. Je me suis donc mis en quête d'une infrastructure de tests unitaires plus lègère. Et je l'ai trouvée !

Il s'agit de UnitTest++. Ce que j'apprécie dans ce framework, c'est son extrème simplicité. Un test est de la forme :

TEST(MonTest)
{
    MaClasse monObjet;
    monObject.FaitUnTruc();
    CHECK(monObject.AFaitUntruc());
}


Et le main ressemble à :

int main()
{
    return UnitTest::RunAllTests();
}


Ici, donc, pas de classe à écrire, on entre tout de suite dans le vif du sujet. Bien entendu, il est possible d'aller un peu plus loin, en testant, par exemple, qu'une exception a bien été levée, ou en introduisant une classe permettant d'implémenter des tests avec fixture (je n'ai toujours pas trouvé de traduction valable pour ce terme... si quelqu'un en a une, je suis preneur). Il est même possible de vérifier que l'exécution d'un test ne dépasse pas une durée donnée. On peut utiliser une version surchargée de RunAllTests() si on veut utiliser une méthode particulière pour faire les rapports de tests, par exemple.

La documentation est un peu succinte mais suffisante pour une utilisation directe. Pour une utilisation avancée, une étude des sources (fournis) sera probablement nécessaire.

Pour le moment, je suis plutôt satisfait par UnitTest++. Je pense me plonger un peu plus dedans pour écrire un rapporteur de tests en xml. Ainsi, on pourra lancer automatiquement les tests unitaires sur un serveur, et afficher les résultats dans une page web avec un peu de mise en forme. On verra si c'est aussi simple que d'écrire un test unitaire :)

Réflexions sur le refactoring

Après avoir passé quelques semaines à remettre en état du code truffé de duplications et de problèmes de conception, j'en suis arrivé à quelques conclusions.

Celle qui me paraît la plus importante fait écho à un twit de Kent Beck : "if you want to eliminate duplication first make the similar code exactly identical, then eliminating duplication is trivial". J'en ai fait l'expérience : si des portions de code se ressemblent, il est aisé de les rendre les plus identiques possible et il devient effectivement trivial de faire disparaître la duplication. La première étape peut se faire à l'aide de méthodes simples de refactoring comme le renommage de variables ou de méthodes, ou en déplaçant des lignes de codes. Le risque est donc très faible.

Ensuite, un simple outil de diff (vim, par exemple :)) permet d'extraire les parties communes ou, tout simplement, de constater l'égalité de deux portions de code (voire de fichiers). À partir de là, les méthodes habituelles de refactoring s'appliquent le plus simplement du monde.

Il est inutile de vouloir reprendre l'intégralité du code en une seule fois. Il est plus facile de travailler par étapes, classe par classe, par exemple. Refactorer une classe, la valider, l'intégrer, et passer soit à la suivante, soit à une autre tâche. Il est toujours temps de revenir sur celles qui restent à faire.

Certaines améliorations impliquent des modifications en profondeur. Là encore, il est plus sûr et plus aisé de procéder par étapes. Par exemple, la factorisation de code au sein d'un ensemble de classes peut faire apparaître un nouveau niveau de factorisation ou mettre en évidence une nouvelle architecture de classes. Il est préférable d'aller au bout de la première factorisation avant de se lancer dans le second niveau. Sinon, le travail à effectuer sur le code peut devenir complexe et, finalement, difficile à maîtriser.

Voilà pour cette fois, j'espère que mon expérience pourra vous être utile.

3 ordinateurs, 4 écrans et...

... un élevage de souris. Et je ne parle même pas de l'enclos des claviers !

Bref, pour ceux qui, comme moi, sont parfois amenés à travailler en parallèle sur plusieurs machines, éventuellement avec des systèmes d'exploitation différents, la multiplication des périphériques d'entrée peut rapidement devenir problématique. Pour ne pas dire autre chose...

Eh bien il y a une solution : synergy+. Tout est expliqué sur la page du projet : un serveur sur lequel on utilise le clavier et la souris et des clients qui deviennent des sortes d'extensions du bureau du serveur. L'installation et le paramétrage sont simples, je ne m'étendrai pas là-dessus. On donne la liste des machines possibles et leur position relative. Il faut juste ne pas oublier de bien situer toutes les machines. Si A est à droite de B, il ne faut pas oublier d'indiquer que B est à gauche de A.

Ah, j'ai failli oublier de mentionner que ce merveilleux petit logiciel fonctionne sur Mac OS, Linux, Windows et probablement sur tous les BSD après compilation.

Suite des aventures avec mon Mac

Étant plutôt habitué à utiliser Linux sur mon PC personnel et Windows sur mon PC professionnel, il y a quelques habitudes que j'ai du mal à perdre. Surtout concernant les fonctionnalités dont j'ai besoin. Sous linux, un coup d'œil dans les dépôts, un petit "apt-get install" et le tour est joué ! Sous Windows, un coup de Google, et 3 heures de recherches et de tri plus tard, on a éventuellement l'application qu'il nous faut.

Sous Mac, comme il n'y a pas de dépôts centralisé de logiciels, mon premier réflexe est de faire comme sous Windows : mon pote Google, recherche, téléchargement, tout ça. Mais en fait, je me rends de plus en plus compte que ce que je cherche est déjà fourni.

Par exemple, j'étais à la recherche d'un moyen d'enregistrer des screencasts. Il y a effectivement des applications, les plus intéressantes étant payantes. Mais Quicktime X permet de le faire. Il prend forcément tout l'écran, mais iMovie permet de retailler le film pour ne garder que la partie qui nous intéresse.

Au boulot, des collègues pas habitués au Mac ont eu besoin d'en contrôler un à distance via le réseau. Leur premier réflexe : télécharger un serveur VNC. En fait le partage d'écran intégré au système en est un, tout à fait standard.

Je suppose qu'il y a encore pas mal d'autres exemples comme ça.

Il va falloir que je m'habitue à chercher d'abord sur mon Mac ce dont j'ai besoin avant d'aller voir ailleurs.