tyPouypOblOg

Au vu du tarif, je ne vais finalement pas me rendre à l’EuroBSDCon 2008 à Strasbourg. Tant pis. Je suis vraiment surpris par la grille de tarif : 255 € ça fait un peu chère.

Peut-être que je me consolerais en allant au JDLL (c’est le même week-end, à Lyon.

Pour vous evitez de vous prendre les pieds dans le tapis…

Je ne suis pas un grand utilisateur de wifi… Mais j’apprend maintenant que j’ai un petit portable de moins de 2 kilos que j’enmène partout :D

Quand je cherche un peu de doc sur comment ocnfigurer le wifi pour OpenBSD, je tombe souvent sur des articles qui parlent d’une comande wicontrol(8) . Mais voilà, impossible de l’avoir sur ma machine. J’ai beau chercher dans les paquets, les ports, je ne trouve rien.

Finalement, a force de fouiller, je suis tombé sur une petite phrase dans la doc des nouveautés de la version 4.0 d’OpenBSD:

La configuration sans-fil pour wi(4) est désormais totalement supportée par ifconfig(8). L’utilitaire wicontrol(8) est désormais obsolète et a été supprimé de l’arbre CVS.

(Mise à jour 3.9 -> 4.0 : Application userland)

Ne cherchez plus, tout est sur votre machine :)

ps: C’est quand même dommage que l’on ai toujours la commande disponible dans les pages “man” disponible en ligne

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.

J’ai lu il y a quelques jours un billet de Jean-François Helie: REST ou SOAP . J’aimerais ajouter ici mon petit piment, ma petite reflexion sur ces deux mode de communication.

Pour ce qui ne le savent pas encore, REST est une architecture basé sur ce qui fait le web: URI , HTTP et un concept d’object, ou plutôt de ressources bien pensé. C’est une architecture légère et relativement facile à mettre en place. Elle est de plus très ouverte et simple à utiliser.

Quant à SOAP, c’est un protocole de communication très utilisé (le seul?) dans la construction d’architecture de type SOA. Basé sur XML. Très verbeux, il est souvent opposé à REST (mêms si c’est plutôt la SOA qui s’oppose à REST).

Je rejoint Jean-François sur le fait que finalement, selon ce que nous voulons mettre en place, l’une ou l’autre des solutions s’adapte mieux. Mais j’ajouterais que pour moi, SOAP est interessant dans une architecture où les échanges sont asynchrone. Effectivement, REST, basé sur le protocole HTTP, donne une réponse immédiate. SOAP peut-être utilisé comme tel, mais finalement, SOAP utilisé sur le protocole HTTP, ça faut un peu double emploi: Une enveloppe dans une enveloppe. SOAP dans une utilisation asynchrone prend du sens. Utilisé sur un protocole spécifique (beurk ! je préfère les formats ouverts !) ou bien du type smtp/imap/pop cela devient légitime.

Donc pour moi, outre l’aspect gestion de sécurité (il me semble qu’avec une architecture REST, il existe des solutions pour la gestion de la sécurité), le choix entre l’utilisation de REST et l’utilisation de SOAP, c’est plutôt une question de timing :-)

Dans un mois environ, l’EuroBSDCon2008 aura lieu à Strasbourg. Pour une fois que ce n’est pas trop loin de chez moi, je vais y aller bien sur ! Un programme passionant même si je regrette un peu le manque de conf sur OpenBSD, j’ai l’impression que je vais encore apprendre plein de truc, voir, ne rien comprendre à pas mal de chose… A noter qu’il y a deux tutoriaux sur des système BSD embarqué. Je suis curieux de voir cela ;-)

Cette conf sera aussi l’occassion pour moi de voir Jean-mi de la comte et de revoir Zifro et ça vaut aussi le voyage.

Et vous vous y serez ?