Les pieds dans le code

Après avoir refermé ce nouveau bouquin de chez 37Signals, je suis un peu déçu. Rework n'est, de mon point de vue, qu'une version amélioré de Getting Real. C'étais peut-être le but, mais du coup, je n'ai rien appris de nouveau.

Beaucoup de chose relève du bon sens et sont courament faite dans quelques sociétés. D'autres sont moins évidente, et on voit peu d'entreprise les mettre en place. Je pense notamment au fait de rester petit. Je vois trop de personnes pour qui la taille d'une boite indique une certaine puissance, notoriété ou encore tranquillité...

Il y a par contre quelque choses avec lequel je ne suis pas d'accord: le fait de travailler à domicile, avec une équipe réparti. Je pense: pour pouvoir recruter les meilleurs des meilleurs il faut accepter de recruter à travers la planête. Pour moi, le fait de travailler en équipe, dans une même pièce est beaucoup plus efficace et important que de travailler avec la crème de la crème mondiale. Mon coté vert me dit que c'est pourtant bien de proner le travail à domicile... mais je préfère pouvoir discuter tout de suite avec quelqu'un quand j'ai besoin de le faire, et surtout voir quand son visage ce tord de douleur sur un bout de code, pour pouvoir lui venir en aide. Et j'aime à penser que les défaut de chaque membre de l'équipe servent a rendre l'équipe plus forte.

En gros, lisez Rework plutôt que Getting Real si vous devez en choisir un. Et surtout (c'est d'ailleur dit dans un des premiers chapitres) restez vous même !

Soap, on aime ou on aime pas. Je pense que Soap sur HTTP, c'est dommage, autant utiliser le protocole http correctement et proposer des services web en RESTful. Comme je l'ai lu quelque part, c'est comme "mettre une enveloppe dans une enveloppe". Toujours est-il que ça a quand même le mérite d'exister. Et nous nous sommes retrouvé à devoir faire appel à un webservice SOAP en ruby, j'aimerais vous faire part de la façon dont on a réalisé cela.

Après avoir jeté un coup d'oeil à soap4r nous avons voulu regarder ce qui existait déjà, et là, surprise, soap4r est intégré à la librairie standard de Ruby avec une base très riche pour l'utilisation de Soap et quelques outils bien pratique pour l'utilisation des fichiers WSDL.

Du coup, il ne reste plus qu'a générer les classes qui s'occuperont de l'appel "soap" à l'aide de l'objet WSDL2Ruby.

Pour cette génération, nous avons repris un script wsdl2ruby.rb trouvé dans les repertoires du Trac du projet soap4r (qui date un peu). En gros il ajoute quelque explication sur l'utilisation de la ligne de commande permettant de générer les classes Soap, et permet d'enchainer l'envoie du message run après avoir mis en place la location et placé quelque options bien choisi.

Voici LA méthode principale du wsdl2ruby.rb:

 def run
   @worker = WSDL::SOAP::WSDL2Ruby.new
   @worker.logger = @log
   location, opt = parse_opt(GetoptLong.new(*OptSet))
   usage_exit unless location
   @worker.location = location
   if opt['quiet']
     self.level = Logger::FATAL
   else
     self.level = Logger::INFO
   end
   @worker.opt.update(opt)
   @worker.run
   0
 end

En executant donc cette commande wsdl2ruby.rb --wsdl '[l'adresse du fichier wsdl de mon service soap qui tue]' --type client

Il existe pas mal d'option pour créer un webservice, mais ici nous voulions créer un client pour appeler un webservice soap existant.

Cette commande nous a donc générer deux fichiers: default.rb et defaultDriver.rb. Ce dernier s'occuper de la connexion au service, et défini les methodes que l'on peut utiliser ainsi que les paramètres qui vont bien avec. Le fichier default contient lui un objet par methode du service. Dans notre cas, nous avion un objet qui correspond à l'appel, et un pour la réponse. Bien sur, avant d'intégrer ce code généré, il faudrais faire un petit renomage, mais ça vous savez faire.

Notre service permet

Le defaultDriver.rb généré.

 require 'default.rb'
 require 'soap/rpc/driver'

 class Authentification < ::SOAP::RPC::Driver
   DefaultEndpointUrl = "http://example.com:8080/axis/services/authentification"
   MappingRegistry = ::SOAP::Mapping::Registry.new

   Methods = [
     [ "",
       "authentification",
       [ ["in", "parameters", ["::SOAP::SOAPElement", "http://auth.example.com/", "authentification"], true],
         ["out", "parameters", ["::SOAP::SOAPElement", "http://auth.example.com/", "response"], true] ],
       { :request_style =>  :document, :request_use =>  :literal,
         :response_style => :document, :response_use => :literal }
     ]
   ]

   def initialize(endpoint_url = nil)
     endpoint_url ||= DefaultEndpointUrl
     super(endpoint_url, nil)
     self.mapping_registry = MappingRegistry
     init_methods
   end

 private

   def init_methods
     Methods.each do |definitions|
       opt = definitions.last
       if opt[:request_style] == :document
         add_document_operation(*definitions)
       else
         add_rpc_operation(*definitions)
         qname = definitions[0]
         name = definitions[2]
         if qname.name != name and qname.name.capitalize == name.capitalize
           ::SOAP::Mapping.define_singleton_method(self, qname.name) do |*arg|
             __send__(name, *arg)
           end
         end
       end
     end
   end
 end

Le fichier généré default.rb

 require 'xsd/qname'

 class Authentification
   @@schema_type = "authentification"
   @@schema_ns = "http://auth.example.com"
   @@schema_qualified = "true"
   @@schema_element = [["login", "SOAP::SOAPString"], ["pwd", "SOAP::SOAPString"]]

   attr_accessor :login
   attr_accessor :pwd

   def initialize(login = nil, pwd = nil)
     @login = login
     @pwd = pwd
   end
 end

 class Response
   @@schema_type = "response"
   @@schema_ns = "http://auth.example.com/"
   @@schema_qualified = "true"
   @@schema_element = [["result", "SOAP::SOAPString"]]

   attr_accessor :result

   def initialize(result = nil)
     @result = result
   end
 end

Du coup, il ne reste plus qu'a créer un nouvelle objet proxy (qui porte le nom du service et que l'on retrouve dans le fichierdefaultDriver.rb), puis d'envoyer les messages qui vont bien avec les paramètres.

 require 'defaultDriver'
 auth_proxy = Authentification.new
 response = auth_proxy.authentification(:login => 'james', :pwd => 'bond')
 puts response.result

Au final, ça fonctionne plutôt bien et c'est en peut de temps que l'on a pu mettre en place cet appel. Soap est un protocole de communication verbeux, mais il a l'avantage d'être très bien intégré dans les divers langages et framework, et, dans notre cas, nous avons plusieurs technologie qui utilise ce service. On préfèrerais bien sur voir ici l'utilisation d'un service rest mais il faudrais dans ce cas que les autres technologie soit capable de l'utiliser, et pour certaine techno un peu vieillissante, c'est pas facile (de plus reprendre le code existant a un coût).

Je n'aime pas non plus le code généré pour plusieurs raison dont le manque de test. On sent aussi qu'avec les capacités dynamique de Ruby on pourrais ne pas générer du code, mais construire à la volé les appels au service soap.

Voici le nième billet que l'on peut trouver sur Git et Mercurial.

On pourrais énumérer les différences entre les deux pour pouvoir choisir, mais Why Git Is Better Than X le fait assez bien (quoique, on peut douter de l'impartialité ;-)).

On pourrais aussi choisir mercurial pour l'executable en deux lettres (hg) au lieu de git qui en contient trois (git)...

Un petit plus pour Mercurial, en tant que client en tout cas. effectivement, grace à ce plugin hg-git un utilisateur de mercurial pourra partager avec des utilisateurs de Git. Je en suis pas sur que l'inverse existe.

Un autre point me dit que finalement on peut très bien ce servir des deux dans un même projet. C'est une discussion dans un TGV de retour de Strasbourg et le billet MercurialSquashCommit de Martin Fowler qui eveil ma curiosité. J'ai l'impression que travailler par patch permet également d'utiliser n'importe quelle DVCS, à condition bien sur que celui-ci propose une création de patch facilité. Il me semble que Git propose avec la commande git-diff voir git-format-patch permet une gestion très interessante des patchs. Mercurial a également une gestion interessante par le biais de l'extension MQ.

Mais j'ai besoin de faire quelque essais avant d'être persuadé (pour l'un et/ou l'autre). Promis, je vous en reparle quand c'est fait.

Alors utiliser, Git, Mercurial ou un autre, peut importe tant que l'équipe arrive à trouver un rythme et un processus qui lui convient ;-)