November 2009

Douglas McIlroy résume la philosophie UNIX en :
« This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. »
Source : Wikipedia

Cette philosophie de faire une seule chose mais de la faire bien pourrait être appliquée au web. Il faudrait sûrement arranger certains points : utiliser des flux HTML en UTF-8 plutôt que des flux textes ascii, remplacer le terme programme par application web, etc. Mais fondamentalement, rien ne nous empêche de concevoir le web de cette façon.

Pourtant, j'ai l'impression que le web actuel s'éloigne de plus en plus de cela pour fournir des applications complètes, complexes, mais qui ont du mal à communiquer entre-elles et dont le passage de l'une à l'autre manque de fluidité.

Bref, je pense que l'on aurait beaucoup à gagner à essayer de se ré-approprier la philosophie UNIX et à l'appliquer au web. Pour cela, il faudrait sûrement inventer des concepts similaires aux pipes UNIX (les WebHooks ?), aux flux standard, au principe "tout est fichier" ("tout est accessible par une URL" ?), aux permissions UNIX, etc. A suivre...

http://dev.af83.com/sites/default/files/logo_blockamp.jpg

L’association Ruby France, l’ESUG , l’INSIA et af83 ont le plaisir de vous annoncer l’organisation d’un BarCamp consacré à Ruby et Smalltalk dans les locaux de l’INSIA à Paris, le samedi 28 novembre 2009.

L’événement est gratuit et ouvert à tous, débutant ou expert. Il suffit de s’inscrire (attention à la limite maximum !) et toutes les explications et les informations pratiques (code d’accès pour entrer…) sont sur la page du wiki BarCamp.

Pour ma part, je vais y aller pour assister aux sessions Ruby, et j'espère pouvoir y discuter des implémentations Ruby (Ruby 1.9, JRuby, Rubinius, MacRuby, etc.), des techniques avancées (Refactoring, Metaprogramming, etc.), découvrir des gems/libs/framework sympas (quelqu'un pour une sessions Ruby + XMPP ?).

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 :

Retrospectiva est un outil de gestion de projets que nous utilisons depuis quelques semaines sur un de nos projets. Je souhaite vous faire partager un premier retour d'expérience sur cet outil