tyPouypOblOg

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

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.

rubyFrance:~ $ cat monobjet.rb
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:

rubyFrance:~ $ cat monobjet.rb
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:

rubyFrance:~ $ cat monobjet.rb
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:

rubyFrance:~ $ cat monobjet.rb
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]. 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