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.

J'ai testé 7 !

J'ai été obligé d'installer et de tester 7 (c'est dingue, mais ça me fait systématiquement penser au film homonyme) pour mon boulot. Et, comment dire ? C'est... ce n'est pas... enfin... c'est Windows, quoi ! Je ne comprends pas trop tout le bruit qu'on fait autour de cette version. C'est toujours Windows. Les fans seront sûrement conquis, ceux qui n'aiment pas n'aimeront toujours pas, et les indécis se le verront imposé avec leur nouvelle machine. Pas de révolution, pas de réelle inovation, comme d'hab'. Tous les gadgets qui sont censés nous épater existent depuis des années. Quant à la simplicité, si cela correspond au fait de pouvoir cacher les menus dans lesquels on passe notre temps à se perdre, ou à une énième refonte du menu démarrer je ne vois pas trop non plus ce que ça apporte.

Bref, n'attendez pas un test complet ici. Juste le point de vue tout à fait subjectif d'un utilisateur de linux converti au Mac. 7 n'est que Windows. Même Microsoft n'y croit pas, si on en juge par la campagne de publicité la plus pourrie qu'on ait jamais vue pour un produit de cette firme. Même les vendeurs de lessive font mieux.

Oui, je sais, un article pour pas grand chose. Juste envie de donner mon sentiment. Surtout qu'il va falloir que j'aille plus loin avec ce nouveau venu. Alors il y aura peut-être une suite...