Les pieds dans le code

Je viens de lire la traduction d’un article parlant des commantaires dans le code source sur le Framablog . C’est un article écrit par Esther Schindler que je ne connais pas. Son article original titré If the comments are ugly, the code is ugly parle donc de code source, de code source avec de vilain commentaires.

Elle signale que les commentaires doivent être irréprochable, sans faute d’orthographe, sans erreur de grammaire, à jour par rapport aux codes sources commenté…

Et bien j’ai trouvé une solution encore plus simple: je supprime les commentaires et j’essaie de rendre le code plus lisible. Les langages de programmations actuel sont assez expressif, utilise des mots anglais clair, certain langage apporte une structure permettant même d’écrire des presques phrases ! Un code propre n’est pas un code avec des commentaires à jour, mais un code lisible, clair et concis

De plus, tout les langages modernes (enfin j’espère) bénéficie d’une librairie de test unitaire, ce qui veut dire que l’on peut écrire un bout de code très simple qui montre l’intention du programme réel, qui montre comment il fonctionne, qui le documente en quelque sorte. Alors pourquoi écrire en plus des commentaires ? Je préfère voir un code lisible, et au pire devoir aller lire des tests unitaires pour comprendre son fonctionnement (voir ajouter des tests pour vérifier que j’ai bien compris).

Alors je ne sais pas qui est cette dame, mais, même si elle a en partie raison, pitié, éviter de faire du code illisible et sans test unitaire programmé sous pretexte que vous avez écrit des commentaire digne d’un grand roman.

Vous habitez prêt de Lille ?
Vous aimez coder ?
Vous aimez rencontrer ?

Un dojo s’ouvre prêt de chez vous, et je pense que vous pourriez bien apprecier et apporter votre pierre à l’édifice.

Muni d’un groupe sur google-group: nord-agile le prochain dojo semble être pour le 2 octobre, dans les locaux du campus Lille 1 (pour moi c’est du chinois, mais pour les Lillois, ça doit être parlant non ?)

Bon code à tous ! :)

Cela fait un moment qu’un nouveau troll à pointé son nez. Après vim versus emacs, gnome versus kde et tant d’autres, on a maintenant git versus mercurial.

Derrière ces deux noms se cache un outil de gestion de versions. Contrairement à CVS ou SubVersion ces deux là (et quelques autres) sont dit décentralisé. Ce mode permet de nouvelles possibilités dans la manière dont les équipes travaillent.

On trouve beaucoup de comparatif entre ces deux outils, et je ne suis pas convaincu par les uns ou les autres. Pour moi les seules différences que je vois aujourd’hui c’est:

• langage source : Git est écrit en C, Mercurial en Python
• Commande: Git utilise trois lettre git, Mercurial en utilise deux hg

Une des grandes forces de la communauté des utilisateurs de Git est d’avoir eu très rapidement accès à un outil d’hébergement : github . De plus, l’équipe du framework RubyOnRails ayant adopté Git, la communauté Rails l’a également adopté. Bien sur, beaucoup d’autres projets utilisent Git, notamment le noyau Linux.

Mais Mercurial n’est pas en reste (contrairement à ce que l’on pourrait croire).

La communauté d’utilisateur de Mercurial a également un outil d’hébergement: bitbucket ou encore freeHg, et pour ce qui est des projets phare ayant choisi mercurial on retrouve mozilla , NetBeans , OpenJDK , OpenSolaris, Xen , et beaucoup d’autres

Pour le moment mon choix c’est porté sur Mercurial (allez savoir pourquoi). Cependant, je crois qu’avant de faire un choix définitif, il me faut apprendre à me servir des deux. Je me suis donc créé un compte sur GitHub, un sur BitBucket et un sur freeHg. GitHub et BitBucket propose tout deux une utilisation de type premium. Par exemple:

• GitHub propose un nombre illimité de repository public associé à un nombre illimité de collaborateur le tout avec 100MB d’espace disque. Ensuite c’est une location par mois avec une augmentation des repository privée associé à un nombre restreint de collaborateur et une augmentation de l’espace disque disponible.

• BitBucket propose lui un repository privé et un nombre illimité de repository public le tout devant tenir sur 150 MB. Ensuite, ce sont des tarifs par MB et fonction du nombre de repository privée.

Ces deux là sont partis sur des offres payantes assez différentes. Chacune d’entre elle peut avoir sont intérêt selon les besoins.

• freeHg semble plus libre en apparence (je n’ai rien vu au sujet de ma carte bleu, à part un bouton donate). Par contre il impose l’utilisation de licence libre pour les projets hébergé, et décline toute responsabilité en cas de problème.

Pour être honnête, je viens de découvrir freeHg en écrivant ce billet… Je crois que tout ceci est un peu frais pour moi, je vous en dirais plus quand j’aurais manipulé un peu.

Voici un petit billet d’initiation au Développement piloté par les Test (dit TDD pour Test Driven Development) avec Ruby. Initialiement publié sur le site de l’association "RubyFrance":http://rubyfrance.org

Imaginons que nous ayons besoin d’un petit objet nous permettant d’afficher un nom. En bon développeur, nous allons d’abord écrire notre test.

require "test/unit"

class TestMonObjet < Test::Unit::TestCase
  def test_attribut
    monObjet = MonObjet.new("un titre")
    assert_equal "un titre", monObjet.nom
  end
end

Executons le test:

rubyFrance:~ $ ruby testMonObjet.rb
Loaded suite testMonObjet
Started
E
Finished in 0.001079 seconds.

  1) Error:
test_attribut(MonObjetTest):
NameError: uninitialized constant MonObjetTest::MonObjet
    testMonObjet.rb:6:in `test_attribut'

1 tests, 0 assertions, 0 failures, 1 errors

Mince une erreur. Vous allez me dire, c’était couru d’avance, on a encore rien codé. Bien. Allons-y alors. D’abord nous allons ajouter le fichier contenant l’objet que nous allons créer.

require "monobjet.rb"

Ensuite créons ce fichier:

rubyFrance:~ $ cat monobjet.rb
class MonObjet
end

Cela suffira largement pour empecher l’erreur précedente. C’est un point important dans l’univers TDD. Il ne faut rien faire de plus que ce que les tests nous demande. Cela rejoint également un autre concept: YAGNI (You Ain’t Gonna Need It).

Executons encore ce test:

rubyFrance:~ $ ruby testMonObjet.rb
Loaded suite testMonObjet
Started
E
Finished in 0.00193 seconds.

  1) Error:
test_attribut(MonObjetTest):
ArgumentError: wrong number of arguments (1 for 0)
    testMonObjet.rb:7:in `initialize'
    testMonObjet.rb:7:in `new'
    testMonObjet.rb:7:in `test_attribut'

1 tests, 0 assertions, 0 failures, 1 errors

Hmm, encore une erreur, mais cette fois ce sont les paramètres de notre objet qui pose problème. Bien, corrigeons notre objet.

class MonObjet
  def initialize un_nom
  end
end

Executons encore ce test:

rubyFrance:~ $ ruby testMonObjet.rb  
Loaded suite testMonObjet
Started
E
Finished in 0.001091 seconds.

  1) Error:
test_attribut(MonObjetTest):
NoMethodError: undefined method `nom' for #<MonObjet:0x80e4d100>
    testMonObjet.rb:8:in `test_attribut'

1 tests, 0 assertions, 0 failures, 1 errors

Encore une erreur. Mais cette fois c’est la method nom qui est manquante pour MonObjet. Ajoutons la:

class MonObjet
  def initialize un_nom
  end
  def nom
  end
end

Executons le test (oui, en tdd, on passe notre temps à tester ! :-)):

rubyFrance:~ $ ruby testMonObjet.rb  
Loaded suite testMonObjet
Started
F
Finished in 0.198677 seconds.

  1) Failure:
test_attribut(MonObjetTest) [testMonObjet.rb:8]:
<"un titre"> expected but was
<nil>.

1 tests, 1 assertions, 1 failures, 0 errors

Voilà qui deviens interessant. Cette fois, ce n’est pas une erreur, c’est un echec du test. La méthode “nom” ne renvoi pas la bonne valeur.
La situation d’echec dans le test unitaire est aussi appelé “la barre rouge”. Et quand il y a une barre rouge, le principe est de la faire redevenir verte le plus rapidement possible (en ajoutant très peu de code voir en enlevant du code).

Modifions donc rapidement notre code pour répondre au besoin du test:

class MonObjet
  def initialize un_nom
  end
  def nom
    "un titre"
  end
end

Doucement, doucement, je vous vois venir, oui j’ai mis une valeur en dur, executons le test (c’est barre rouge), nous en parlons juste après.

rubyFrance:~ $ ruby testMonObjet.rb  
Loaded suite testMonObjet
Started
.
Finished in 0.000902 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

Voilà, le test passe. Nous pouvons maintenant parler. J’ai mis une valeur en dur dans la méthode “nom”, cela vous dérange ? Et bien pas moi. Je répond ici au besoin exprimé dans le test. Mais je n’ai pas dit que nous allions nous arreter là ! Ajoutons un test pour bien préciser notre besoin.

require "test/unit"

class TestMonObjet < Test::Unit::TestCase
  def test_attribut
    monObjet = MonObjet.new("un titre")
    assert_equal "un titre", monObjet.nom
  end
  def test_attribut_autre
    monObjet = MonObjet.new("un autre titre")
    assert_equal "un autre titre", monObjet.nom
  end
end

Executons le test unitaire maintenant enrichi d’un test.

rubyFrance:~ $ ruby testMonObjet.rb  
Loaded suite testMonObjet
Started
.F
Finished in 0.024359 seconds.

  1) Failure:
test_attribut_autre(MonObjetTest) [testMonObjet.rb:12]:
<"un autre titre"> expected but was
<"un titre">.

2 tests, 2 assertions, 1 failures, 0 errors

Forcement, avec une valeur en dur, cela ne vas pas. Faisons passer la barre au vert avant de discuter:

rubyFrance:~ $ cat monobjet.rb
class MonObjet
  def initialize un_nom
    @nom = un_nom
  end
  def nom
    @nom
  end
end

Executons le test:

rubyFrance:~ $ ruby testMonObjet.rb  
Loaded suite testMonObjet
Started
..
Finished in 0.001734 seconds.

2 tests, 2 assertions, 0 failures, 0 errors

Parfait ! Barre verte !

Bien, maintenant, on peut laisser étaler nos connaissance en ruby pour effectuer un petit refactoring:

class MonObjet
  attr_reader :nom
  def initialize un_nom
    @nom = un_nom
  end
end

Executons le test a nouveau pour être sur que ce refactoring n’a pas changé la donne:

rubyFrance:~ $ ruby testMonObjet.rb  
Loaded suite testMonObjet
Started
..
Finished in 0.001734 seconds.

2 tests, 2 assertions, 0 failures, 0 errors

Un des interêt de faire un développement piloté par les tests c’est de tendre une sorte de filet de sécurité permettant de donnée plus de courage, ou au moins de tranquillité pour effectuer le refactoring. Mais il existe bien d’autre avantage à ce mode de développement. Notamment celui de ne pas faire plus que nécessaire.

Les tests ainsi écrit, modifié, mis à jour permette de disposer à tout moment d’une documentation sur l’execution du programme.

Jruby vous connaissez ? C’est l’implémentation Java du langage de programmation Ruby. Une implémentation qui à mon avis séduit ou séduira la plus part des entreprise ayant déjà une infrastructure basé sur la technologie Java.

Et bien cette semaine, c’est la dernière ligne droite, Tom a déclenché les hostilitées en annonçant la sortie d’ici la fin de semaine de la nouvelle version 1.1.3 de cette implémentation, et du coup propose à tous de signaler ce qu’ils souhaitent voir dans cette version (archives de l’annonce: JRuby 1.1.3 by end of week…Nominate problems here…. Charles Oliver Nutter a surenchéri en faisant suivre le message sur la mailing list User (The reason we’re pushing 1.1.3 now is so we can finally branch 1.1 into
full maintenance mode and start hitting Java integration hard.

Les demandes pleuvent, je vous prévient un peu tard peut-être pour participer, mais essayé toujours. Au pire on fera les tests sur cette nouvelle mouture.

On connait (ou pas) ce merveilleux petit framework d’interface graphique en Ruby : Shoes (une oeuvre signé _Why encore une fois !).

2 grandes rencontres virtuelles vont avoir lieu pour partager, tester, discuter, découvrir, documenter autour de ce framework: l’une à lieu en ce moment (vendredi 11 Juillet) et l’autre aura lieu dans 2 semaines (le vendredi 25 Juillet). C’est toute la journée, ça se passe sur IRC : #shoes@freenode.net , c’est ouvert à tous: développeur, testeur, documenteur, partageur, découvreur; du framework ou bien d’application l’utilisant. Vu le coté international, ça se passe en Anglais bien sur.

Si vous ne connaissez pas Shoes, c’est peut-être le moment d’aller découvrir ce framework. D’ailleurs, c’est un évènement qui précède la prochaine grosse release qui devrait avoir lieu à la fin du mois.

L’annonce officiel de l’évènement: 7/11 & 7/25 ShoesFests with Why The Lucky Stiff
L’annonce sur RubyInside: Join Why The Lucky Stiff (And Others) For an Online “ShoesFest”

Le courage fait parti des clefs de l’"eXtreme Programming [wikipedia]":http://fr.wikipedia.org/wiki/Extreme_programming. Il est nécessaire lors du refactoring. Bien trop souvent les développeurs n’osent pas modifier du code existant. Il existe plusieurs raisons à cela:

• C’est le code de… AAah et bien si c’est le code du grand guru maison, qui oserais modifier sont code. Il penserait surement que l’on critique son code, qu’on ne le trouve pas assez bien. Et c’est peut-être le cas, ou alors tout simplement, ce code à besoin d’évoluer. Et plutôt que d’ajouter de nouvelle chose, il faut reprendre, modifier une partie du code existant. Cela évitera les redondances, les erreurs, et le code mort. Je garde mon apologie du refactoring pour un autre billet.

• Trop compliqué à lire Justement ! C’est qu’il faut le reécrire ce code ! Quel horreur du code illisible. Source de bugs, peut-être que ce source fait beaucoup trop de chose par rapport au besoin. Simplifions le !

• Je n’ai pas le temps Je crois qu’il faut de temps à autre avoir le courage de prendre le temps, de perdre du temps. Cela pourrais s’avérer bénéfique par la suite. Si j’ajoute plutôt que de modifier, qui me dit que je ne vais pas devoir y revenir une fois, deux fois, n fois pour corriger un bug, un disfonctionnement, un effet de bord ?

On parle du courage du codeur, le courage de modifier du code, mais je voudrais juste aborder ici un autre courage, celui-ci c’est pour les divers responsables et autres chefs de services: le courage de revenir sur une décision quand elle s’avère être mauvaise.

Trop de projets sont ecrasé contre un mur (ou alors y vont tout droit) parce qu’_en haut_ personne n’ose, personne n’a le courage de tirer les leçons d’une série d’échecs, personnes n’ose revenir sur une méthodologie mauvaise.

Personnellement, je fais de l’informatique pour rendre service à des utilisateurs. Si je vois les utilisateurs heureux lors d’une livraisons, je le suis aussi. C’est un bon moyen de vérifier que nous sommes sur la bonne route. Mais justement, je m’égare de la route du courage dont je voulais parler :-)

N’ayons pas peur de modifier du code. Pour nous aider dans ce sens nous avons plusieurs outils à notre disposition:

• Outils de gestion de configuration (ou versioning): Ces outils nous permette de revenir à une version précédente avec une facilité déconcertante. Alors bien sur il faut en choisir un qui corresponde bien à nos besoin, mais je crois qu’aujourd’hui nous avons l’embarras du choix !

• Test unitaire: Les tests ! En voilà un outil. Avec une bonne batterie de test, nous sommes sur de ne rien casser. Comment ne pas oser un refactoring avec ça ? On modifie, on relance les tests, ça passe ? bien ça marche alors :)

• Langage et architecture: Tout cela est bien beau, mais c’est vrai qu’avec un langage et/ou une architecture ou tout élément et imbriqué dans l’autres, une architecture ou tout est lié, une architecture ou l’on gère plusieurs fonctionnalité dans un même source, c’est beaucoup plus effrayant de modifier un morceau. C’est une des raisons qui me font adorer l’Objet et les architectures associé. Un objet à une responsabilité, et une seul (enfin, il devrait). Pas de code cherchant à tout faire, souvent mal. Au moins c’est simple.

Courage et KISS DRY

Je viens de finir le livre de Véronique Messager Rota Gestion de projet – Vers les méthodes agiles .

Un très bon complément à mes précedentes lectures sur le sujet, ainsi qu’au divers informations lu de-ci de-là sur le web.

J’aimerais maintenant une chose, c’est pouvoir participer à un projet agile :-) En tant que développeur dans un premier temps, et pourquoi pas plus tard, avec plus d’éxpérience dans le domaine, en tant que coach agile.

Messieurs les coachs et autres chefs de projets, j’étudirais très sérieusement toute proposition de rejoindre une équipe agiles !

Et je vous conseil la lecture de ce bouquin

A force de placer mes fenêtres toujours au même endroit, avec la même taille (ou presque) et de repartir ces groupes sur les divers bureaux, je me suis dit qu’il étais peut-être temps de tester un autre gestionnaire de fenêtre.

Ion semblait un bon candidat, mais la configuration ne me donnais pas super envie, et les divers lectures au sujet de l’auteur et de la licence de l’application ont fini par me couper l’envie de l’adopté.

Alors j’ai continué à fouiller dans les gestionnaires de fenêtre accès clavier et simplicité. Sur la list misc@ d’"OpenBSD":http://www.openbsd.org il y avait eu une discussion sur le gestionnaire de fenêtre par défaut. Actuellement FVWM (premier du nom), certain voulais voir cwm prendre la place. Du coup, il fallait que je l’essaie.

Assez sympathique ma fois. Simple, avec quelque raccourci clavier rappelant Vi. Très rapide, et très agréable à utiliser.

Cependant, je n’etais pas encore convaincu. J’avais entendu parlé d’un autres gestionnaire qui pourrais remplacer Ion durant mes recherches: Wmii

Alors pour être dérouté, on peut l’être. C’est très interessant. Ici point de menu, d’icône, de boutons de fenêtre. Une petite barre, quelques touches et c’est parti. Un des concept est de ne pas avoir à gérer les fenêtre justement: on arrive sur une frame, une petite combinaison de touche et hop, un terminal en plein écran. On en lance un deuxième, pour voir, et voilà deux terminaux qui prenne chaucun une moitié d’écran, un troisième et … non, je vous laisse deviner. Une autre combinaison de touche plus loin et paf, c’est sur deux colonnes que ça se passe, royal. Plus la peine de placer les fenêtre ! :) Plus de place à force de lancer des applications ? Une petite combinaison et paf, je met la nouvelle appli sur une autre frame (on pourrais les apparentés à un bureau virtuel qui s’étend a mesure du besoin).

J’adore :)

Et pour ne rien gacher, je me rends compte qu’un figure du monde Ruby , Mauricio Fernandez aime et utilise (il me semble) lui aussi ce gestionnaire de fenêtre (il a d’ailleurs commencer à faire quelque script et autre bricole en ruby pour Wmii , mais c’est une autres histoire).

Et dans toute ces histoires de script et de config, je tombe sur encore une sommité du monde Ruby: Why qui apparemment aime et utilise Wmii ! (D’ailleurs, j’ai découvert qu’il utilisais DragonFlyBsd contrairement à tout les macaddict que l’on voit beaucoup dans le monde de Ruby sur les rails ;-) )

Finalement je ne suis pas trop surpris, je trouve que l’auteur de Wmii ressemble un peu à ces deux là. Anselm R Garbe est un doux dingue du petit code efficace, c’est d’ailleurs le concept du site dont il est fondateur sukless.org :

Dedicated to software which sucks less…

The upper boundary on the size of the software we accept is 10,000 source lines of code (SLOC).

J’ai encore plein de chose à découvrir, mais si vous voulez essayé un gestionnaire de fenêtre innovant, je vous conseil d’essayer Wmii

ps: j’allais oublié. le peu d’intérêt d’un screenshot avec ce genre de gestionnaire de fenêtre explique le manque d’image de ce billet :)

Pour ceux qui en doutais, les design pattern du GOF on bien une raison d’exister dans Ruby. Alors certes, mon article sur les motifs de conception en ruby sur le site de rubyFrance n’est peut-être pas top top, ma seul excuse est que cet exercice m’a permis de découvrir ruby. Mais toujours est-il que l’utilisation de pattern dans un langage objet est fortement recommandé !

D’ailleurs, un livre (en anglais) est sorti sur le sujet (Russ Olsen m’a piqué mon idée :-p): Design Pattern in Ruby. Je crois que malgré le tarif ($42.99) et mon faible niveau d’anglais, je vais me le commander. Peut-être que cela me permettra de refaire quelque exemple mal choisi sur le site de RubyFrance…

via "Ruby Inside":http://www.rubyinside.com/design-patterns-in-ruby-by-russ-olsen-695.html