Bisecting pathological code with Git

Sometimes, you end up with a bug in the code base and have no clue
where that bug was introduced...


Git has a "bisect" functionality that helps you determine which commit
introduced the pathology.


Once you've found where the problem lies, then Git can't replace your
worthy talent to fix it in the most elegant way human can think
of. Hey, your genius can't be cloned into a program (yet).


So here are the steps to follow when trying to use "git bisect" to
isolate the faulty commit that is responsible for breaking the feature
you've put so much time and effort implementing.

Using Git to help you

Now you wonder how Git can help you isolate the faulty commit, the
all-evil one that brought your program in regression? Here you go...

First step

Make sure you have a way, ideally systematic (read programmatic) to
make checks on the expected results. Having a script or a
semi-automatic way of proceeding might be very useful since you want
to have reproducible results easily, painlessly, reproduce these
results a given number of times.


The theory of complexity says that if you have N items among which to
proceed with a binary search, then you have roughly ceiling(log(N))
steps towards finding what you're looking for.


In practice, this may lead to about 10 iterations. So if you're as
lazy as I am, you'll want to automate the checking from iteration to
iteration.

Second step

To start the bisection search, and it's really a binary search among a
set of commits, you need to identify two edge commits, i.e. one where
it fails (usually the "HEAD" of the branch you're working on) and one
where the feature was working fine. These are the boundaries within
which the binary search will be made.

Third step

Now you can start using Git for the search. It can be initiated using the following command:


git bisect start


You have to tell bisect what are the boundaries of the search. You indicate the commit that is faulty by issuing the following command:


git bisect bad


Leaving the commit hash empty will tell Git to use the HEAD.
You indicate the commit where the functionality is working fine by
issuing the following command: 


git bisect good


From now on, Git will proceed by identifying the median commit in the
search space, check it out and let you proceed with the testing to
identify if the functionality is good/bad.


You can tell Git about that by issuing


git bisect good


or


git bisect bad


accordingly.

Final step

Once you're done, you can stop the "bisect" functionality with this
command:
git bisect reset

Further readings

You can see these web pages for further details:

• http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search 
• http://webchick.net/node/99 

La grève étudiante au Québec

Voici mon point de vue sur la grève étudiante au Québec.

Ma position: en faveur de la gratuité scolaire

Le principe d’utilisateur-payeur ne s’applique que sur certains concept au Québec. Par exemple, le domaine de la santé. Il est clair que mes impôts ne varient pas en fonction du nombre de visites à l’hôpital que je suis en mesure de faire au courant d’une année. C’est un choix de société qui implique que nous payons, tous ensemble, afin que les services soient offerts à tous. Aussi, les voies publiques sont payées non pas en fonction de l’utilisation que nous en faisons: est-ce que je paie à chaque fois et seulement pour les quelques fois que je passe sur le pont Champlain? Non. Est-ce que je paie à chaque fois que j’emprunte l’échangeur Turcot? Non. Ces infrastructures sont là et elles sont disponibles à notre société.

Les coûts des études supérieures, tant au niveau collégial qu’universitaire, peuvent être contrôlés en commençant tout d’abord avec le contrôle à l’accès selon le mérite. Durant mes études, j’ai pû cotoyer des étudiants dont les compétences, et on parle bien de compétences lorsqu’on fait des études supérieures, étaient en deçà de ce qui était attendu d’un étudiant universitaire. Par exemple, une étudiante en administration option comptabilité ne se souvenait pas du résultat de 3 x 8. Par exemple, les étudiants qui ne savent même pas comment conjuguer le verbe être convenablement. Il est clair que le niveau des étudiants universitaires n’est pas celui qui devrait être. On souhaite que l’éducation soit accessible à tous mais on devrait plutôt penser qu’il devrait être accessible au mérite. Par exemple, des directeurs au sein de grosses entreprises qui ne sont même pas capables de faire une phrase sujet, verbe, complément durant un exposé oral. On pourrait ainsi éviter d’avoir trop de diplômés qui sont incompétents, ce dont j’ai trop souvent eu l’occasion de croiser dans mon parcourt professionnel, et redonner aux diplômes la valeur qui leur est dûe.

Et les universités devraient peut-être coûter plus cher aux étudiants étrangers. Si les frais de scolarité pour les étudiants québécois sont gratuits, ce serait parce que c’est un service qu’on a décidé de s’offrir. Tout comme l’assurance-maladie. Et les étudiants étrangers devraient payer plus cher que ce qu’il leur en coûte actuellement. Au même titre que les malades étrangers doivent payer davantage pour les frais médicaux, même s’ils ne payent pas pour passer sur le pont Champlain, Laviolette ou prendre l’autoroute métropolitaine.

Est-ce que les universités dépensent trop peu judicieusement? Bien sûr. Moi-même, ne suis pas irréprochable dans ma façon de gérer mon budget domestique qui est beaucoup moins complexe et géré seulement par moi et ma conjointe. Mais on ne parle pas ici de budget de fonds publics mais bien de mes fonds personnels. Et mes quelques inepties budgétaires n’affectent en rien le bien commun.

Maintenant, on peut se questionner sur le déroulement de la grève et de la manière dont ceci a été géré de part et d’autre. Mais ce n’est pas là le débat.

Est-ce que les étudiants ont mal géré leur processus de grève et leurs négotiations? Bien sûr. J’ai été heureux de voir que des représentants syndicaux se sont portés volontaires pour aider au processus de négociations entre le gouvernement et les étudiants. Et j’aime à penser que leurs conseils ont été bien reçus.

Est-ce que le gouvernement a mal géré la situation? Bien évidemment et de façon lamentable à mon avis. Érudits aux stratégies de la négociation, ils ont manqué de respect envers la communauté étudiante, envers la société au sens large. Étant donné sa position de pouvoir et son rôle social, le gouverment est largement à blâmer dans toute cette histoire: il a la responsabilité de s’assurer que l’ordre social est maintenu. Bien sûr, il a été clair que les enjeux électoraux sont prédominents pour le gouvernement Charest. Et il est aussi clair qu’il a été une de ses priorités de se démarquer favorablement auprès du public, surtout lorsque de fortes (et très nauséabondes) allégations de corruption pèsent sur lui.

Verify the integrity of a file before / after download

Sometimes, transfering a file from one place to another can cause damage to the file. And this damage can be subtle enough that it seems fine but the data it contains is just slightly corrupted.

One rather simple way to perform a check is by computing a checksum on this file. An old checksum algorithm is MD5 and a more recent one is SHA1.

Let's suppose you would like to compute a hash key for the file "pet_names.txt" you would like to make available for downloading. The following line shows how to compute its hash key on the host:

user@boing:~$ sha1sum pet_names.txt > pet_sum.txt

Once downloaded, provided you have the file which encloses the sha1 hash key, you can simply check the integrity of the file like this:

user@boing:~$ sha1sum -c pet_sum.txt

Proceeding with MD5 hash key is done in a very similar way; just change sha1sum by md5sum and you're all set!

Hope this may be usefull.

D'un Ubuntu vers un autre

    Cela fait maintenant environ 3 ans que j'ai installé Kubuntu 8.04 LTS (long term support) sur mon ordinateur à la maison. J'ai bien tenté de faire des mises-à-jour de distribution avec "sudo apt-dist upgrade" mais disons que le résultat n'est pas très concluant. On dirait qu'une partie a été mise à jour alors que le reste ne est resté intact. Ce n'est pas exactement ce que j'avais en tête au moment de lancer la mise-à-jour...
    Comme une version de Ubuntu 10.04 LTS est maintenant disponible (depuis un moment déjà...), je pense à ré-installer cette version par-dessus l'ancienne. Mais avant toute chose, voici quelques petites choses que j'ai faites qui pourraient vous simplifier la vie:

1. Faire une sauvegarde de son répertoire "/home/";
2. faire une sauvegarde de cette sauvegarde;
3. faire une sauvegarde des configurations importantes (sécurisation des connexions ssh faites de l'extérieur, script de mise à jour de l'adresse IP dynamique DynDNS au démarrage de l'appareil, etc.)

    Ensuite, on peut passer aux choses sérieuses.

Sauvegarde de répertoire /home/

    On peut procéder avec la ligne de commande. Deux approches sont principalement utilisées pour effectuer une sauvegarde:

1. tar: créer une "tar-ball" qui comporte tout le dossier /home/. Mais après vérifications, cette approche est un peu trop pénible. Après plusieurs heures de calculs, l'opération ne s'est pas avérée complète...
2. rsync: créer un clone d'un répertoire vers une destination. rsync est utilisé pour faire du "remote synchronisation" de fichiers. La commande utilisées est la suivante:

 rsync -avxP /home/you /mnt/nfs/newhome  

    Ce qu'il y a de bien avec l'option 'P', c'est que rsync affiche un état de la progression; copier les données peut tout de même être assez long et nous évite de penser que l'opération est figée indéfiniment...

    On peut aussi procéder avec l'utilisation d'un outil graphique (GUI) qui réalise exactement la même chose que rsync mais pour ceux qui sont plus confiant avec une souris qu'un clavier. Sur mon système Ubuntu, on peut accéder à l'outil en choisissant le menu Système > Administration > File Backup Manager.

    Mais rien de tel qu'un peu de clavier pour se sentir en contrôle!

Agile... ou pas

Nous sommes dans une époque où être dans un environnement de développement de logiciel de type "Agile" est un mot magique, comme les expressions "lean manufacturing" ou "just in time" le sont dans le domaine de la production, par exemple. C'est tendance, comme on le dit dans les émissions télé qui transforment un salon grotesque en un salon à la mode mais qui deviendra aussi grotesque dans quelques années.

Être "Agile" est un concept qui met l'emphase sur le fait que le développement de logiciel doit pouvoir s'adapter aux besoins des clients. Ces besoins sont complexes et peuvent parfois mal se déclamer de manière succinte; ils sont clarifiés au fur et à mesure qu'un logiciel se développe, se précise. L'esprit d'équipe est au coeur des méthodes agiles: scrum (inspirée du rugby) et la méthode XP (Extreme programming) entre autres. Tout cela est louable et a prouvé ses mérites. Mais ce n'est qu'un concept cependant...

Dans certains cas, c'est une raison à portée de la main qui vise à justifier le fait que les documents nécessaires dans le contexte de développement logiciel ne sont pas maintenus ou simplement produits.

Par opposition à Agile, il y a la méthode "waterfall" (chute d'eau, en anglais) qui dit que toute la conception, l'analyse, la documentation, doivent être produites avant même de taper la plus solitaire ligne de code. C'est une autre extrême et il y a un juste milieu entre les deux.

Personnellement, j'ai travaillé dans une entreprise qui se réclamait de suivre des méthodes de développement dites Agile. Jamais je n'ai vu une entreprise où la documentation était aussi bâclée. J'ai même eu à consulter de la documentation sur des modules existants lors de mon entrée en fonction dans la compagnie. Plusieurs phrases étaient même incomplètes sur l'un de ces documents, pourtant enregistré comme version officielle dans le système de documentation ISO. Preuve que ce ne sont pas là des gages de qualité...

Par opposition, j'ai travaillé dans une entreprise qui se dit ne pas suivre les méthodes Agiles. Pourquoi? Tout d'abord pour des raisons historiques: cette entreprise a commencé à développer du code il y a environ quinze ans. À ce moment, les méthodes Agiles n'étaient pas tendance.

Ensuite, il y a des contraintes de respect de budget: les clients s'attendent à payer un certain prix, pré-déterminé, pour une modification à du code existant ou des nouvelles fonctionnalités. Pour évaluer convenablement ces coûts, il faut qu'une analyse soit faite au préalable afin de déterminer les embûches potentielles, les implications, les tests à effectuer, la traduction de certaines informations, etc. Mais Être Agile rend cette évaluation plutôt difficile, du moins du point de vue de la première entreprises décrite ci-haut, car

1) on ne peut se fier à documentation existante: on répète les erreurs déjà observées mais dont les solutions sont non-documentées.

2) on néglige l'aspect analyse du travail et on s'engage sur un terrain inconnu.

Notons que la mauvaise documentation peut être compensée par la formation croisée: au lieu de consigner l'information dans des documents, on la consigne dans le savoir collectif. Mais une entreprise qui se dit Agile souhaite réduire ses coûts. Et si elle mets de côté la production de documentation sur le code existant (mettons de côté les documents d'analyse pour l'instant), alors il y a fort à penser que les ressources humaines sont limitées...

Il faut se méfier de méthodes "à la mode"; elles peuvent représenter plusieurs aspects qui sont intéressants mais qui tentent de cacher l'essentiel. Dans le cas présent, il faut produire du logiciel. Le lecteur intrigué pourra lire l'essai de Paul Graham intitulé The Revenge of the Nerds qui parle aussi du problème de langages de programmation qui sont "à la mode".

Ideas are going in smoke...

Remember my post about good ideas in marketing? Well, there is a different idea or "concept" which did not produce the desired effects...

The The Vancouver Olympic torch was designed to inspire "skating", "skiing" and other cool stuff related to Olympic winter games to be held at Vancouver in 2010.

Unfortunately, its inspiration is more alike what Micheal Phelps and Ross Rebagliati were preaching by example in smoking drugs.

Anyways, please read this article for more information (and a picture of the torch!).

- Eric

When "security" does not mean "security for long"...

According to this article, it seems like WEP secured WiFi networks are not so secure at all... finally.

Most security mechanisms are safe until they are not safe anymore. But for the time being, one should rely on WPA2 for securing a WiFi network. Even more specifically at home.

I remember commuting by train with a laptop on my knees, trying to fix a bug in my source code. I did not notice but found my WiFi antenna was on. I was impressed to see so many WiFi networks popping-up on my radar screen as the train was rolling towards downtown. I would say about 50% of the networks were not secured at all.

Later on, I will try to tell more about this, even if I am not a network specialist. But for now, I just wanted to point this out.

Be told.

- Eric