ruby

Quill and ink well at the State House

RDoc

RDoc est l'outil utilisé par les développeurs Ruby pour générer une documentation à partir des commentaires dans le code. Il est très souvent décrié, car il oblige à mettre en forme les commentaires d'une certaine manière qui a tendance à rendre les commentaires difficilement lisibles directement dans le code. Il est également difficile de produire des templates différents pour la génération HTML de la documentation.

Il semblerait que 2010 soit l'année du grand changement pour cela. En 2008, la mode pour les développeurs Ruby était de faire son propre framework web, en 2009, ce fût les outils de tests/specs, et dans cette lignée, il semblerait que les outils de tests soient à la mode pour 2010. Je vais vous présenter les premiers candidats.

Yard

Yard n'est pas nouveau, mais revient en force. Il se place dans la continuité de RDoc en termes de fonctionnement, et cherche notamment à assurer la compatibilité avec RDoc. Il est ainsi utilisé par rdoc.info pour générer de jolies documentations à partir de dépôts git.

Mais Yard propose également une syntaxe alternative, en rupture avec celle de RDoc. Celle-ci est dans l'esprit de ce que javadoc ou doxygen propose : @param pour documenter un paramètre, @return pour la valeur de retour, @see pour faire une référence, etc.

Rocco

Rocco est un portage en Ruby de docco. Ce n'est pas exactement un outil de documentation, plus un outil de literate programming, mais il peut servir à documenter du code.

Son rendu HTML est sur deux colonnes. La colonne de droite affiche le code, coloré avec Pygments. La colonne de droite affiche les commentaires qui correspondent au code. La langage de markup utilisé pour les commentaires est Markdown, une syntaxe wiki généralement bien connue des développeurs.

TomDoc

Tom Preston-Werner, un des créateurs de Github, n'était pas satisfait par les solutions précédentes. Il cherchait un format qui soit facilement lisible directement dans le code, mais qui permette néanmoins de générer une documentation pour les utilisateurs qui leur conviennent : un template agréable, pas de méthodes privées... Il a donc proposé son propre format : TomDoc.

Je trouve que ce format convient pour lire les commentaires directement dans le code, mais je ne suis pas entièrement convaincu. Devoir marquer chaque méthode comme étant Public pour qu'elle apparaisse dans la documentation me semble contraignant, et remplacer attr_accessor par attr_reader plus attr_writer carrément casse-pieds.

Conclusion

Au final, ces différentes initiatives me paraissent intéressantes mais je ne sais pas trop laquelle choisir. Je pense que je vais attendre encore un peu que la situation se décante et que je puisse expérimenter les possibilités pour voir celle qui me convient le mieux.

Avec Ruby On Rails, il est assez aisé de faire des test unitaires. Il est donc encore plus fortement conseillé de faire des tests dans toutes ses applications Ruby On Rails.

Le soucis quand on teste beaucoupses applications est outre d'avoir moins de bugs, c'est d'avoir des temps de tests qui sont de plus en plus long.

En théorie, il est dit que tant que tous les tests ne font pas plus de 10 minutes, il n'est pas nécessaire de refactorer sont code de tests. Mais il peux quand même être intéressant de suivre le temps d'exécution de chaque tests pour limiter le temps d'un test.

Avec le framework Rspec, il est très simple de découvrir les tests qui sont les plus lent. Le formatteur "profile" (  spec --format profile spec/*_spec.rb ) retourne les 10 tests ( exemples ) qui prennent le plus de temps. Il est donc facile de savoir quels tests refactorer pour améliorer les performances globale de ceux-ci.

Mais avec Test::Unit, la partie était plus compliquée. Heureusement test_benchmarker est là pour nous aider. Grâce à ce gems, un simple require dessus et tout vos tests seront benchmarcké et trié par temps d'execution, par class et surtout par test.

Voici un exemple de sortie de test_benchmarker :

Logo
Chaque semaine, je publie une liste de liens vers des billets de blog, des articles et des annonces qui me semblent intéressants et en rapport avec l’activité d’AF83. N’hésitez pas à proposez vos liens. Voici la sélection de cette semaine :
Google Chrome Frame

    Logo
    Chaque semaine, je publie une liste de liens vers des billets de blog, des articles et des annonces qui me semblent intéressants et en rapport avec l’activité d’AF83. N’hésitez pas à proposez vos liens. Voici la sélection de cette semaine :
    OS & Navigateurs

      L'édition 2009 des Rencontres Mondiales du Logiciel Libre se tiendra du 7 au 11 juillet à Nantes. Comme chaque année, conférences, tables rondes, et ateliers seront proposés aux visiteurs durant 5 jours. Ceux-ci, qu’ils soient experts, novices, professionnels, ou simples curieux pourront trouver les interlocuteurs qui répondront à leurs questions au travers des nombreux thèmes abordés. Sans oublier bien entendu le village associatif où chacun pourra se promener.

      Logo
      Chaque semaine, je publie une liste de liens vers des billets de blog, des articles et des annonces qui me semblent intéressants et en rapport avec l’activité d’AF83. N’hésitez pas à proposez vos liens. Voici la sélection de cette semaine :
      Campagne Microsoft

      Logo
      Chaque semaine, je publie une liste de liens vers des billets de blog, des articles et des annonces qui me semblent intéressants et en rapport avec l’activité d’AF83. N’hésitez pas à proposez vos liens. Voici la sélection de cette semaine :
      Navigateurs

        Logo
        Chaque semaine, je publie une liste de liens vers des billets de blog, des articles et des annonces qui me semblent intéressants et en rapport avec l’activité d’AF83. N’hésitez pas à proposez vos liens. Voici la sélection de ces dernières semaines :
        Conditions d'utilisation