Bien que toutes sortes idées viennent immédiatement à un développeur pour réaliser cela lorsqu’on lui suggère, deux objections se présentent instantanément :

1. Ça n’a aucun intérêt.
2. Rien ne différencie un serveur d’une machine locale.

C’est ce second point que je voudrais clarifier aujourd’hui.

Un serveur est une application

La confusion courante est de croire que le serveur est une machine d’un genre spécial, qui ne fonctionne pas comme les autres. En un sens, c’est vrai, comme nous le verrons ensuite, mais pas d’un point de vue strict.

D’un point de vue strict, un serveur est une application : serveur web comme Apache, serveur ftp comme ProFTPd, serveur smtp/pop/imap (mail) comme Postfix, serveur svn comme Subversion, etc.

Installez l’une de ces applications sur votre machine locale, et vous avez un serveur.

Qu’est-ce qui fait qu’une application est un serveur?

La particularité d’une application de type serveur est de permettre à d’autres applications de se connecter à elle. D’un point de vue technique, cela passe par l’utilisation de sockets.

Un socket est une main tendue par votre application, une main qui attend d’être saisie pour pouvoir commencer une conversation. Le cas le plus courant est l’utilisation d’un socket utilisant le protocol TCP/IP. Cela signifie que la main sera tendue au travers d’une porte, les ports, que vous voyez partout lorsque vous configurez votre routeur ou votre pare-feu. Avec un tel type de socket, une application sur une machine distante pourra passer par internet pour serrer la main de votre application type serveur et commencer à dialoguer.

Néanmoins, un serveur ne passe pas nécessaire par un socket utilisant le protocol TCP/IP. Ainsi, il existe d’autres types de socket auquels on ne peut se connecter que depuis la machine qui execute le serveur, comme les socket de type UNIX.

Dans le monde des systèmes libres, nous possédons de nombreux exemples de ce type : le serveur graphique Xorg (qui permet de dessiner et manipuler les fenêtres), le serveur de son Jackd (qui permet d’accéder au système audio), le serveur DCOP pour KDE (qui permet aux applications KDE de discuter entre elles), etc.

Pour résumer, un serveur est simplement cela : une application qui permet à d’autres application de se connecter à elle.

Et pourtant, je loue un serveur dédié!

L’utilisation du terme serveur pour désigner la machine est donc un abus de langage. Sur une machine “serveur” tournent les même systèmes d’exploitation que sur une machine “locale”.

Cet abus de langage révèle pourtant une réalité concrète. Une machine “serveur” n’est pas une machine comme vous en avez chez vous. Ses composants ont été réduit au strict nécessaire, et les composants relatifs au réseau ont une qualité disproportionnée relativement à votre machine personnelle. Cette machine est sous tension en permanence et est en permanence connectée (si tout va bien) à un réseau permettant une bande passante en envoi sans comparaisons.

Pourtant, ce sont exactement les même composants : un processeur, un disque dur, de la ram, une carte réseau, etc. Ce qui fait la différence est que cette machine est optimisée pour un usage intensif de serveurs (au sens strict).

On retrouve la même chose au niveau du système d’exploitation. Ce qui fait la différence entre un Windows et un Windows Server, et entre une Ubuntu Desktop Edition et une Ubuntu Server Edition, c’est l’optimisation. Dans la version server de ces systèmes d’exploitation, tout a été pensé pour permettre un usage intensif de serveurs et un grand nombre de connexions.

Lorsqu’on compile un noyau Linux, on a ainsi le choix entre différentes politiques de planification de la priorité des processus, selon qu’on utilisera intensivement quelques processus qui devront avoir une grande priorité sur les autres (comme sur une machine optimisée bureau) ou qu’on aura un très grand nombre de processus qui devront être traités de manière égale (comme sur une machine optimisée serveur).

Rien ne vous empêche pourtant d’opter pour un tel type de configuration sur votre machine personnelle, et, d’un point de vue purement technique, une application est parfaitement incapable de savoir si elle se trouve sur un système optimisé serveur ou un système optimisé bureau.

Un petit bémol : bien entendu en informatique, rien n’est impossible. On pourra toujours trouver quelques bidouilles qui permettront de se faire une idée de quel type d’environnement nous utilisons. Cela n’a juste rien d’évident.

Je vous propose aujourd’hui un plugin de navigation locale pour typolight.

Ce qu’il fait

Le module de navigation de sous-menus de typolight m’a assez ennuyé parce qu’il nécessitait qu’on définisse le niveau de départ et de fin dans l’arborescence. Si vous voulez afficher un lien vers les sous-pages d’une page à, disons, deux niveaux de récursion, et d’une page à quatre niveau de récursion, vous devrez faire deux modules “navigation éléments de sous-menu” différents.

Le module que je vous propose à une fonctionnement de type “dans cette rubrique”. Il liste les enfants directs de la page dans laquelle vous vous trouvez.

Installation

Le module s’installe dans system/modules/ .

Vous pouvez l’installer par svn :

svn checkout svn://olivier-elmekki.com/typolight-modules/local_nav

Ou en téléchargeant l’archive.

Une fois le module en place, il sera accessible dans la liste des modules de frontend dans la rubrique navigation et sous le nom de “navigation locale”.

Mais si vous suivez à la trace vos visites réelles, qu’en est-il des visites qui ont été tentées alors que votre site était aux abonnés absents?

L’angoisse du downtime

Quand vous avez un site pro, vous êtes possédés par une angoisse : celle que votre site soit inaccessible. Vous êtes parti déjeuner, ou pire : vous surfez sur facebook. Une heure, deux heures (trois heures? ). Et soudain, vous réalisez que votre site n’est plus accessible. Combien de visiteurs et clients potentiels avez-vous perdus ainsi? Vous n’en savez rien.

La solution Kolibria

Kolibria Webservice vient de réaliser une application payante permettant de remédier à ce problème : monitoria. La cible est clairement les sites à revenus et offre un outil permettant d’envoyer des alertes par mail et par sms dès que le site est considéré come innaccessible ou franchement lent. De plus, des statistiques sont réalisées sur vos périodes de downtime. Je vous invite à voir la press release pour plus d’information.

La tâche va consister dès lors à écrire plus précisément vos modèles, et en particulier vos validations. Bien entendu, nous allons commencer par écrire les tests :]

• Maîtriser les fixtures
• Maîtriser les tests unitaires
• Maîtriser les tests fonctionnels
• Maîtriser les tests d’intégration

Introduction à Test:Unit

Test::Unit est en fait un framework de test intégré à la library standard de ruby. Pour mieux le comprendre, nous allons laisser Rails de côté quelques instants.

Test::Unit mêle quatre notions : les assertions, les testcases, les testsuites et les fixtures.

Une assertion est l’unité la plus élémentaire. Il s’agit d’une expression effectuant un test. Si le test est passé, rien de particulier ne se passe ; si le test échoue, une erreur sera affichée. La méthode de base est assert. Elle évalue si l’expression passée est vraie ou fausse. Vous pouvez spécifier un message personnalisé au cas ou le test échoue.

assert true
assert 1 < 2
assert false, "évidemment que non"

Les deux premières assertions passeront, la dernière échouera. Il existe tout un jeu de méthodes d’assertions intéressantes, comme assert_equal, assert_match, assert_not_same, assert_not_nil, assert_nothing_raised, etc. Je vous laisse regarder la doc officielle pour en faire le tour.

Un testcase est une classe dérivée de Test::Unit::TestCase qui regroupera les tests propres à une classe (ou pas : vous êtes libre, dans Test::Unit, d’en faire ce que vous voulez, mais il est conseillé de faire ainsi, et Rails en fait un par modèle).

require 'test/unit'
require 'Dog'
require 'Cat'
require 'Person'

class DogTest < Test::Unit::TestCase
  def test_should_create_tame_dog_and_feed_him
    doggy    = Dog.new
    grandma  = Person.new "rotten meat"
    assert grandma.dog = doggy, "grandma doesn't want a dog"
    assert_kind_of Animal, doggy, "that dog is weird"
    assert doggy.feed
  end

  def test_should_know_what_is_good_for_him
    doggy    = Dog.new
    kitty    = Cat.new
    grandma  = Person.new "rotten meat"
    assert doggy.feed( kitty )
    assert_raise { doggy.feed grandma }
  end
end

Il s’agit, concrètement, d’un ensemble de méthodes qu’on définira et qu’on nommera chacune test_quelquechose. Le préfixe test_ est obligatoire. On donne généralement un nom représentatif à ce test, étant donné que ce nom apparaîtra si le test échoue. On peut écrire des méthodes sans le préfixe test_ mais elles ne seront donc pas considéré comme des tests et ne seront pas exécutées automatiquement.

Car c’est l’intérêt de cette classe : lorsqu’on exécute un fichier qui require ‘test/unit’, il lance automatiquement les tests les uns après les autres et affiche un rapport à la fin.

Isoler ainsi les assertions dans des testcases a pour intérêt évident une plus grande sémantique et une meilleure organisation des tests, mais cela permet aussi de partager des fixtures. Contrairement à ce que nous avons vu dans l’article précédent, les fixtures de Test::Unit standard ne sont pas des fichiers YAML, c’est un ajout de Rails. Dans les tests standards, on gère les fixtures grâce à deux méthodes rajoutées dans le testcase : setup et teardown.

setup sera appelé avant l’exécution de chaque méthode du testcase. Cela signifie que les fixtures qui sont placés dedans sont réinitialisés entre deux tests. Si vous utilisez des destructeurs, teardown sera exécuté après chaque test (cela peut être intéressant dans une perspective de logging aussi). L’exemple précédent peut donc être simplifié ainsi :

require 'test/unit'
require 'Dog'
require 'Cat'
require 'Person'

class DogTest < Test::Unit::TestCase
  def setup
    @doggy    = Dog.new
    @kitty    = Cat.new
    @grandma  = Person.new "rotten meat"
  end

  def test_should_create_tame_dog_and_feed_him
    assert @grandma.dog = @doggy, "grandma doesn't want a dog"
    assert_kind_of Animal, @doggy, "that dog is weird"
    assert @doggy.feed
  end

  def test_should_know_what_is_good_for_him
    assert @doggy.feed( @kitty )
    assert_raise { @doggy.feed @grandma }
  end
end

Bien qu’utilisant son propre système de fixture, Rails sait aussi se servir de ce système-là, ce qui vous permet d’exécuter du code arbitraire avant et après chaque méthode de test.

Enfin, une testsuite regroupe plusieurs testcases. C’est principalement un outil de convenance pour vous empêcher de devoir exécuter tous vos tests manuellement les uns après les autres, ou de devoir les mettre dans le même fichier. Ainsi, il vous suffit de faire un fichier contenant :

require 'test/unit'
require 'my_tests/DogTest'
require 'my_tests/CatTest'
require 'my_tests/PersonTest'
# etc

Et tous les tests seront lancés à l’exécution de ce fichier.

Voilà, vous avez maintenant une connaissance solide des bases de Test::Unit, nous allons pouvoir revenir à Rails.

Test::Unit dans Rails

Peut-être faut-il lever tout de suite un quipropos. Dans le répertoire test/ d’une application Rails, vous pourrez voir unit/, functional/ et integration/. Le fait qu’un répertoire se nomme unit ne doit pas vous induire en erreur : tous trois utilisent Test::Unit (avec des ajouts propres à Rails), et plus particulièrement, Test::Unit::TestCase, ou dérivé.

On peut noter un changement de focalisation entre les trois, allant de unit/, très précis et particulier, à integration, très abstrait et dont les tests simulent des cas concrets de parcours dans l’application par un utilisateur.

• unit/ sert à tester les modèles
• functional/ sert à tester les contrôleurs (ce qui implique donc également un travail sur les modèles)
• integration/ sert à tester des scénarios, par exemple : un utilisateur se log, clique sur le lien “profil”, modifie ses pseudo de conversation, va sur une page de discussion et post un commentaire (ce qui implique un travail sur les vues, les contrôleurs et les modèles).

Pour lancer les tests, on peut utiliser une de ces formes de commande :

ruby test/unit/user_test.rb
rake test:units
rake test:functionals
rake test:integration
rake test

La première lance un unique testcase, ici celui du modèle User. Les trois suivants lance l’ensemble des testcases d’une des trois famille de tests. Le dernier lance tous les tests.

Comme je l’ai dit plus haut, Rails permet un gestion des fixtures plus sophistiquée que Test::Unit. Vous avez déjà écrit vos fixtures. Pour les charger dans vos tests, il suffit d’indiquer le nom du fixture que vous voulez charger dans la classe de votre testcase, par exemple :

class AccountTest < ActiveSupport::TestCase
  fixtures :accounts, :users
  # ...
end

Si vous désirez charger tous les fixtures, vous pouvez spécifier :

fixtures :all

Par Ailleurs, vous pouvez utiliser des helpers dans vos tests, que vous placerez dans test/test_helper.rb.

Enfin, Rails rajoute deux méthodes très utiles à Test::Unit::Assertions : assert_difference et assert_no_difference.

Voilà, le plus lourd est passé. Vous avez les bases pour vous servir de l’ensemble des tests de rails. Oui, c’est la petite surprise de la notion de test unitaire dans Rails : elle crée la confusion avec Test::Unit qui est en fait la base de tout.

Étant donné que le terme Test::Unit est peu mentionné dans Rails (il y a même une classe ActiveSupport::Testcase qui ne fait qu’hériter de Test::Unit::TestCase), je parlerai des tests relatifs à test/unit/ lorsque je parlerai de tests unitaires.

Au volant!

Voyons maintenant comment se servir des tests unitaires dans le contexte du test driven development.

L’implémentation MVC de Rails est fortement portée sur les modèles. Cela veut dire que vous devez avoir des modèles très chargés et des contrôleurs très maigres (je ne parviens pas à retrouver la citation exacte, désolé).

Pourtant l’écriture des tests des modèles, préalable à l’écriture des modèles même, n’est pas si conséquente que cela. La raison en est surtout que vous saurez de quoi à besoin votre modèle lorsque vous penserez vos contrôleurs.

Une première écriture de test de modèle se concentre donc généralement sur le test du CRUD et des validations. Un exemple typique sera donc :

require 'test_helper'

class AccountTest < ActiveSupport::TestCase
  fixtures :accounts, :users
  # create
  def test_should_create
    assert_difference 'Account.count' do
      Account.create :user => users( :quentin), :name => 'test_should_create_account_name'
    end
  end

  def test_validations
    assert_no_difference 'Account.count' do
      account = Account.create
      assert_not_nil account.errors.on( :user_id ), "Un compte appartient à un user"
      assert_not_nil account.errors.on( :name ), "Les comptes sont distingués par leur nom par les visiteurs"
    end
  end

  def test_name_should_be_unique
    assert_no_difference 'Account.count', "Les comptes sont distingués par leur nom par les visiteurs" do
      account = Account.create :user => users( :quentin), :name => accounts( :account1 ).name
      assert_not_nil account.errors.on( :name )
    end
  end

  # read
  def test_should_read
    account = Account.create :user => users( :quentin ), :name => "test_read_account_name"
    assert_nothing_raised do
      second = Account.find_by_name 'test_read_account_name'
      assert_equal second.id, account.id
    end
  end

  # update
  def test_should_update
   assert (accounts( :account1 ).update_attributes :name => "test_update_account_name")
  end

  # delete
  def test_should_delete
    assert_difference 'Account.count', -1 do
      users( :quentin ).destroy
    end
  end

  def test_all_clear
    flunk
  end
end

On test donc principalement ici les tâches classique du modèle et les validations. Ce n’est pas insignifiant. Lorsque vous vous enfoncerez dans le développement de votre application et que vous écrirez d’autres modèles, il y a de fortes chances pour que vous n’ayez plus bien en tête ce qui se passe dans ce modèle-ci. Lancer régulièrement les tests vous assurera de la solidité de votre modèle.

De plus, vous vous êtes sûrement déjà retrouvé dans le cas où des bugs sont apparus parce que vous avez modifié du code dont vous ne vous souveniez plus du sens. Pour éviter ça, je vous conseille d’abuser des messages personnalisés des assertions. Plutôt que de simplement répéter la raison pour laquelle le test échoue, et qui est déjà comprise dans le nom de la méthode de test, votre message personnalisé peut expliquer pour quelles raisons contextuelles le test doit passer. C’est le meilleur moyen pour vous rappeler ce que vous avez fait sur les fichiers précédents sans devoir aller les rouvrir, chercher d’où provient l’erreur et lire les éventuels commentaires que vous y avez laissé.

Revenons à la décortication de l’exemple.

Vous avez peut-être remarqué que l’expression passée à assert_difference ou assert_no_difference est un string. C’est indispensable. C’est fonction évalue bien une différence numérique, mais elle doivent avoir en paramètre un expression dans un string qui sera passé à eval. La raison de cela est que cette expression est évaluée deux fois : une fois au début, une fois à la fin. La soustraction est faite ensuite entre le résultat final et le résultat originel. assert_difference prend en second argument la valeur que doit avoir cette soustraction. Cela implique qu’on doit la spécifier si on veut ajouter un message personnel (troisième argument). La valeur par défaut est 1, ce qui veut dire que assert_difference test par défaut s’il y a eu un ajout sur l’expression, typiquement : le nouvel objet a-t’il été enregistré?

users( :quentin ) et accounts( :account1 ) permettent de retrouver des fixtures selon leur nom.

Un dernier détail à propos de ce code, la dernière méthode. flunk est une fonction permettant de faire échouer systématiquement le test. C’est en fait un raccourci pour assert false. Lors de la première écriture d’un test et de son modèle (ou autre), une dernière méthode avec un flunk permet de signifier qu’il y a encore des choses à écrire. Votre fichier de test, outre le fait d’être un observer et un reminder, est aussi une todo list. Lorsque vous aurez fini la première écriture de votre modèle et que son test passera sans problème, vous pourrez supprimer la méthode de flunk.

Conclusion

Vous venez d’avaler la partie la plus complexe pour qui découvre les outils de tests de Rails. Les tests d’intégration et fonctionnels seront plus complexes, mais il réutiliseront les même outils et structures, avec quelques méthodes ajoutées par Rails pour vous simplifier la vie.

Dans le cadre du Test Driven Development, vous aviez d’abord écrit les relations de vos modèles et vos migrations grâce aux fixtures, vous écrivez maintenant les validations et peut-être quelques méthodes de vos modèles grâce aux tests unitaires.

Vous reviendrez sur ces tests, lorsque vous vous attaquerez à vos contrôleurs et que vous voudrez ajouter de nouvelles méthodes à vos modèles. Vous créerez probablement d’autres modèles, également, en fonction des précisions que votre client vous fournira, des nouvelles requêtes et de tous les imprévus qui pimentent la vie d’un développeur. Notez d’ailleurs que dans le cadre d’un développement agile et des fameux phantasmes de “je suis en face du client, il me demande une modif, je change deux lignes, je lui montre, il n’en revient pas”, les tests vous seront d’un grand secour, afin que ça ne devienne pas “je suis en face du client, il me demande une modif, je change deux lignes, ça casse tout, je cherche le bug, il s’impatiente, je lui dis que ça prendra deux minutes, je comble le vide en baratinant du discours technique, je trouve pas, ça m’enerve”.

Ce qui compte, c’est que lorsque vous en aurez fini avec l’écriture de ces tests et des modèles qu’ils couvrent, vos modèles seront pleinement opérationnels et solides. Il est alors temps de s’attaquer aux contrôleurs (oui, vous avez fait tout ça en une journée, hormis la map initiale).

Il me semble qu’il est intéressant de commencer par les fixtures, car ce sont les données de bases des tests et surtout, parce que l’utilisation qui en est faite est souvent très basique, alors que les fixtures offrent des possibilités avancées qui facilitent grandement les tests.

Je vais d’abord revenir sur les bases des fixtures pour ceux qui découvrent les outils de test, et nous verrons ensuite ces sucreries.

• Maîtriser les fixtures
• Maîtriser les tests unitaires
• Maîtriser les tests fonctionnels
• Maîtriser les tests d’intégration

Au commencement, il y avait data

Eh oui l’informatique, c’est le traitement automatique de l’information. On pourrait décrire l’ensemble des entités informatiques sous l’expression : data + process. Les tests de Rails ne font pas défaut : il faut d’abord leur fournir des données à manipuler.

Si vous avez scrupuleusement suivi les tutoriels d’initiation à Rails, vous avez pris l’habitude de créer trois bases de données : development, production et test. Ce n’est pas anodin. Cela veut dire que chaque environnement possède son propre ensemble de données.

Vous l’aurez deviné, les outils de test utilisent la base de donnée test, qui ne recoupe pas les données des autres environnements (ce qui évite de laisser la base de donnée dans un état indéfini après avoir lancé les tests). Comment introduire des données dans cette base, alors? C’est le travail des fixtures.

Et son nom était YML

Il existe trois formats pour les fixtures, le plus courant étant YAML (ou YML). Son avantage est d’être supporté en builtin par Ruby. Si vous utilisez Ruby, vous l’avez sûrement déjà rencontré car il est abondamment utilisé pour serialiser des objets. C’est un peu l’équivalent de JSON pour le Javascript (bien que ce ne soit pas exclusif à js et que ce dernier pourrait utiliser d’autres formats). Et même sans être un rubyiste, vous vous en servez pour configurer la connexion à la base de donnée dans Rails, dans le fichier config/database.yml.

Son usage est relativement intuitif. On donne un nom à chaque fixture, et ses attributs sont placés en dessous, en étant indentés (attention : seulement des espaces, pas de tabulations!). Le nom est tout à fait arbitraire et pourra être utilisé dans les tests (et dans les fixtures eux-mêmes).

Chaque fichier de fixture correspond à un modèle. Ainsi, tous les éléments dans test/fixtures/comments.yml seront transformés en objets Comment, tels que définis dans app/models/comment.rb.

spam:
  id: 1
  user_id: 1
  created_at: "2008-10-12 18:50:10"
  content: "http://inpythonwetrust.com"
  status: 2

Cet exemple présuppose que vous avez par ailleurs un modèle User et un fixture dans users.yml avec un id = 1, par exemple :

troller:
  id: 1
  name: "persiffleur"
  mail: "nid2viper@gmail.com"
  created_at: "2008-10-12 18:50:10"

Les fixtures sont aussi simples à utiliser que ça : il suffit de donner un nom et de reprendre les champs SQL de la table à laquelle correspond le modèle. C’est sympa, mais on est en droit de s’attendre à un peu plus de magie de la part de Rails.

Et il dit : Que la lumière soit!

C’est bien-heureusement le cas. Pour commencer, il est inutile de préciser les champs created_at et updated_at. Rails leur donne automatiquement la valeur de Time.now.

Si vous désirez préciser une valeur autre que Time.now, Rails vous facilite la tâche en permettant d’utiliser erb dans les fixtures. Vous pouvez donc utiliser tous les helpers accessibles depuis vos vues, par exemple :

created_at: <%= 2.days.ago.to_s :db %>

Ensuite (et c’est mon feature préféré), vous pouvez également ne pas spécifier l’id. Un id est alors automatiquement généré par Rails à partir du nom du fixture. Ce qui permet d’écrire quelque chose comme ça:

# users.yml
troller:
  name: "persiffleur"
  mail: "nid2viper@gmail.com"

et

# comments.yml
spam:
  user: troller
  content: "http://inpythonwetrust.com"
  status: 2

Cette possibilité doit commencer à vous faire entrevoir l’intérêt en terme de Test Driven Development. À noter que les guillemets ne sont pas nécessaire pour marquer le début et la fin des strings, mais je préfère personnellement les utiliser quand même pour distinguer les strings des identifiers.

Enfin, le fait de pouvoir utiliser erb signifie également la possibilité d’introduire de la logique dans vos fixtures. Ne faites pas ces gros yeux, YAML ne définit pas de standard MVC :] . Cela a un intérêt majeur si vous voulez voir comment votre application tient le choc avec 5000 utilisateurs.

<% 5000.times do |i| %>
user_<%= i -%>:
  name: "user_<%= i -%>"
  mail: "user_<%= i -%>@gmail.com"
<% end %>

Le premier jour, il écrivit les fixtures

Personnellement, je commence toujours un projet par… inkscape. Je fais une map des différentes entités dont je pense avoir besoin dans l’immédiat, je dessine leur relation et je leur donne les quelques attributs qui me passent par la tête. Le dessin vectoriel est juste parfait pour ça.

L’étape suivante, pour tout développeur Rails, est de créer les modèles (juste la création même, par le biais des générateurs). Puis, ils écrivent généralement les migrations.

Du point de vue du test driven development, c’est une mauvaise idée. Les fixtures, dans leur usage avancé, permettent une écriture bien plus naturelle des schémas. Prenons l’exemple suivant de migration :

class CreateComments < ActiveRecord::Migration
  def self.up
    create_table :comments do |t|
      t.column  'article_id',   :integer,   :null => false
      t.column  'user_id',      :integer,   :default => 0
      t.column  'content',      :text,      :null => false
      t.timestamps
    end
  end

  def self.down
    drop_table :comments
  end
end

Cela est déjà très concret et implique un blocage réflexif sur l’implémentation de la base de donnée. En écrivant d’abord les fixtures, on peut se permettre d’écrire simplement ce qu’on attends du modèle en terme de structure :

ruvanche_comment:
  article: ruby
  user: ruvanche
  content: "301"

Cela permet de se faire une idée rapidement des attributs dont on a  réellement besoin et de voir comment les données sont reliées entre elles, nous faisant vite remarquer si une relation de notre map est défaillante (par exemple, un has_many qui devrait plutôt devenir un many_to_many, ou un attribut qui devrait plutôt devenir un modèle). On regagne donc le temps perdu à modifier/reset les migrations et réintroduire des données (ou à écrire des migrations de fix).

Une fois que ces données abstraites mais en action ont été écrites, on peut penser à écrire les migrations, qui sont des informations concrètes mais de réserve (dans le sens où on ne les pensera en action que quand on écrira les modèles, si on omet les tests). Puis, quasiment simultanément, les relations dans les modèles, c’est-à-dire les has_many, belongs_to et autres.

Les fixtures qu’on aura écrit permettront de tester rapidement s’il y a des problèmes dans le schémas de la base de donnée ou dans le jeu des relations. Pas même besoin d’écrire des tests, le simple test_truth qui aura été généré automatiquement dans les tests de vos modèles vous suffiront à mettre ce réseau de relations à l’épreuve. Lancez simplement :

rake test

Et vous pourrez fixer les bases de vos modèles et vos migrations avant même d’avoir commencé à écrire du code effectif, et surtout avant d’avoir chargé des données.

Pas besoin d’imaginer non plus cinq fixtures différents en différents états lors de la première écriture des fixtures. Il s’agit juste de se représenter à quoi peut ressemble une instance d’un modèle. Les états particuliers viendront d’eux-même lorsqu’on écrira effectivement les tests.

Ruby On Rails est un framework, ce qui implique une grosse infrastructure présente par défaut. De plus, le code est éclaté du fait de la séparation MVC. Cela, c’est la première bonne nouvelle pour vous, designers. Le seul endroit où vous devez agir est dans les vues, et dans le CSS. Mais revenons pas à pas sur le processus d’installation.

Cet article se concentre sur l’installation pour Windows, étant donné que c’est encore le système le plus courant. Si vous utilisez un système libre, il vous suffira de passer par votre gestionnaire de paquet. Si vous utilisez MacOSX, je ne peux vous dire où télécharger le nécessaire, mais il ne devrait pas y avoir de changements majeurs.

Installation du nécessaire

Ruby on Rails, comme son nom l’indique, est un framework utilisant le langage Ruby. Il vous faut donc, dans un premier temps, installer l’interpréteur de ce langage. Il existe un installeur pour ça. Lorsque vous l’installez, prenez bien soin de laisser l’option cochée par défaut qui propose d’installer RubyGem.

Gem est un gestionnaire de paquet pour ruby. Cela signifie que par son intermédiaire, vous pouvez installer, supprimer et mettre à jour des libraries ruby (Gem ira les chercher de lui-même sur le net). Rails fait partie de ces libraries.

Pour installer rails, ouvrez une invite de commande MS-DOS. Il faut d’abord mettre à jour la liste des paquets de gem, puis installer rails lui même, en lançant ces deux commandes successives :

gem update --system
gem install rails --include-dependencies

Ensuite, vous devez installer le moteur de base de donnée utilisé pour votre projet. Le plus courant est MySQL. Rails propose aujourd’hui par défaut l’utilisation de SQLite3, mais bien que ce soit une base de donnée que j’apprécie beaucoup, la library Rails qui en permet l’utilisation m’a causé de nombreux problèmes. Je vous conseille donc d’utiliser MySQL à la place (si néanmoins vos développeurs utilisent sqlite, son installation ne vous posera pas de problème, interrogez vos développeurs au cas où).

Téléchargez l’installeur de MySQL et suivez ses instructions. Vous pouvez accepter la plupart des choix par défaut, si ce n’est le charset par défaut. Demandez à vos développeurs quel charset ils utilisent, il y a de grandes chances pour qu’ils vous répondent : UTF-8. Dans ce cas, au moment du choix du charset, choisissez : Best Support For Multilinguism. Assurez-vous également, dans la fenêtre suivante, de cocher : Include BIN directory in Windows PATH.

Il ne reste plus qu’à installer l’application rails en elle-même. Les développeurs avec lesquels vous travaillerez utiliseront probablement SVN pour synchroniser votre travail commun. TortoiseSVN vous permettra de facilement utiliser ce protocole. Un peu de vocabulaire pour vous aider à vous y retrouver:

• checkout : sert à télécharger l’ensemble de l’application pour la première fois.
• commit : sert à envoyer vos modifications.
• update : sert à mettre à jour votre copie de travail en téléchargeant les modifications qui ont été faites depuis la dernière fois (assurez vous de le faire régulièrement si vous ne voulez pas avoir des conflits de version).
• add to ignore list : permet de faire ignorer un fichier ou un dossier et donc de ne pas l’envoyer dans les mises à jour. Vous voudrez probablement utiliser cela pour ne pas envoyer vos fichiers de logs et celui de la configuration de votre base de donnée.

Configuration

Lors de cette étape, il s’agit surtout de configurer la base de donnée. Si vos développeurs sont gentils, il vous auront fourni un fichier de configuration standard que vous pourrez adapter. Si ce n’est pas le cas, je vais vous en donner un.

Mais d’abord, il faut bien saisir qu’il existe, dans Rails, trois environnements : l’environnement de développement, l’environnement de production et l’environnement de test. Du point de vue du designer, vous ne vous servirez que du premier. C’est l’environnement classiquement utilisé pendant la conception d’une application. Lorsque l’application est publiée, on la place en environnement de production, ce qui joue principalement sur le fait que beaucoup plus d’éléments sont mis en cache. Cela permet d’aller plus vite, mais le caching, de par sa nature, pose des problèmes ennuyeux lorsqu’on fait de nombreuses et régulières modifications. L’environnement de test, quant à lui, ne sert qu’aux tests automatisés et n’ai pas utilisé manuellement.

Si j’insiste sur la distinction entre ces trois environnements, c’est que chacun possède sa propre base de donnée. Ainsi, un fichier de configuration standard pour MySQL sur Windows ressemble à ceci (notez que sur un système à base Unix, vous pouvez, pour augmenter la vitesse, utiliser le fichier de socket de mysql plutôt que de vous connecter à localhost) :

development:
  adapter: mysql
  encoding: utf8
  host: localhost
  database: projet_dev
  username: nom
  password: password

test:
  adapter: mysql
  encoding: utf8
  host: localhost
  database: projet_test
  username: nom
  password: password

production:
  adapter: mysql
  encoding: utf8
  host: localhost
  database: projet_prod
  username: nom
  password: password

N’ayant pas besoin du second et du troisième environnement, vous pouvez très bien omettre leur description. Placez ces informations dans un fichier nommé database.yml et rangez ce fichier dans config/ dans le répertoire de votre application rails.

Il faut ensuite créer les bases de données. Ouvrez une invite de commande MS-DOS et tapez dedans (en remplaçant le nom de votre projet, le nom de votre utilisateur et le mot de passe) :

mysql

Renseignez votre mot de passe, puis :

create database projet_dev ;
grant all on projet_dev.* to 'nom'@'localhost' identified by 'password' ;

Répétez cela avec projet_test et projet_prod si vraiment vous en avez besoin.

La base de donnée est maintenant créée, il reste une dernière fois à mettre les mains dans le cambouis pour créer sa structure (promis après, c’est fini). Avec votre invite de commande, rendez-vous dans le répertoire de l’application et tapez :

rake db:migrate

Cela créera automatiquement cette structure. Si vos développeurs ont vraiment été très gentils (mais ne rêvons pas, ce sont des développeurs), cette commande peuple même la db avec des données utilisables (en créant des utilisateurs, des produits, etc).

La configuration est maintenant terminée. Vous pouvez démarrer l’application en utilisant le serveur intégré de rails (où peut-être voulez-vous que nous voyions rapidement la configuration d’apache? ). Toujours dans le répertoire principal de l’application, dans l’invite de commande, tapez :

ruby script/server

Il ne vous reste plus maintenant qu’à vous rendre à l’adresse http://127.0.0.1:3000 . Tapez control-c dans l’invite de commande pour arrêter le serveur. Ce serveur est particulièrement lent et ne peut donc être utilisé en production, mais il a le mérite de permettre de tester rapidement une application.

Explication de l’architecture

Ruby on Rails est un framework reposant sur le MVC : Models, Views, Controllers. Cela signifie qu’il y a une distinction fondamentale entre ce qui relève de la gestion des entités (les modèles, la plupart du temps mappés sur des tables de la base de donnée), des actions exécutables par l’utilisateur (les contrôleurs) et du contenu renvoyé en échange (les vues).

Ce qui vous intéresse, en tant que designer ou frontend developer, ce sont ces vues. C’est là que résident les fichiers .html (ou plutôt, les fichiers html.erb, je vais revenir là dessus). Les models, views et controllers se trouvent dans le répertoire app/ .

Probablement encore plus important pour vous est le répertoire public/ . C’est en fait le seul répertoire visible de l’extérieur. Vous pourrez y placer vos fichiers CSS, javascript, audio, images et autres.

Et c’est à peu prêt tout ce que vous avez besoin de savoir sur l’architecture d’une application rails pour pouvoir travailler avec.

Je n’ai encore jamais rien vu dans le dossier doc/, mais si vos développeurs sont les nouveaux messies sur Terre, ils y auront placé toute sorte d’informations intéressantes. Les noms des dossiers config/ et log/ parlent d’eux-même. lib/ et vendor/ servent à placer des bouts de codes des plus utiles, db/ est le répertoire où l’on place les migrations, qui ont permis la création quasi-magique de la base de donnée tout à l’heure. script/ contient quelques utilités comme le serveur, et beaucoup de petits scripts facilitant la vie des développeurs. test/ est le répertoire où se trouvent les tests automatisés (et si vous voulez embêter vos développeurs, demandez leur pourquoi les fichiers dans test/functionals et test/units ont si peu de lignes). Enfin, Rakefile est un fichier permettant d’autres tours de magie de rails, tellement nombreux que je ne m’amuserai pas à les énumérer (ah, si : dans une invite de commande, tapez “rake stats” et demandez à vos développeurs comment il se fait que le Code to test ratio a une valeur si faible côté test).

html.erb ?

Vous vous êtes probablement déjà retrouvé confronté à du code PHP que vous avez dû tenter tant bien que mal de comprendre pour avoir une idée d’où placer vos id et vos class ( “mais d’où vient ce div?” ).

Du fait de la séparation MVC, cela est moins problématique en rails, mais il y a tout de même besoin de rajouter un peu de code dans le HTML. Le langage utilisé est Ruby. Si vos développeurs ont bien fait leur travail (je vais vraiment tous me les mettre à dos), ce code doit être parfaitement compréhensible, même si vous ne connaissez absolument pas Ruby.

La forme standard pour exécuter du code Ruby dans un template erb est :

<% code %>

Il y a néanmoins plusieurs variantes. La balise que je viens de vous montrer n’affiche normalement rien en sortie dans le HTML, sauf si une fonction le demande explicitement (ce qui doit normalement être évité, au profit de la balise suivante). Pour afficher du code, on utilise : <%= %>. Vous verrez ainsi souvent :

<%= @var %>

Cela signifie simplement qu’il faut écrire le contenu de la variable @var. Un autre modificateur est le signe moins ( - ) avant la fermeture de la balise, comme ceci :

<p>Nom: <%= @user.name -%></p>

Cela permet un formatage plus propre du code HTML : un balise sans “-” retourne à la ligne, une balise avec, non.

Le type de code le plus “complexe” que vous devrez voir est comme ceci :

<!-- exemple 1 -->
<% if @user.logged? %>
  <p>Salut <%= @user.name -%></p>
<% end %>

<!-- exemple 2 -->
<ul id"product_list">
<% @products.each do |prod| %>
   <li><%= prod.name -%></li>
<% end %>
</ul>

<!-- exemple 3 -->
<% form_for :vote, @vote do |f| %>
  <p><%= f.label :rate, "Rate this" -%> <%= f.rate_radio :rate -%></p>
  <p><%= f.label :username, "Your name" -%> <%= f.text_field :username -%></p>
  <p><%= f.submit -%></p>
<% end %>

L’exemple 1 est parfaitement compréhensible pour qui ne connaît pas Ruby, pour peu qu’on sache que if en anglais signifie si (condition). Si l’utilisateur est loggé, dire : salut son_nom.

L’exemple 2 se comprend très bien aussi, dès lors qu’on sait que each signifie chacun : pour chaque produit, écrire un li avec son nom.

Le troisième exemple est plus problématique. C’est un vrai plaisir pour nous les développeurs, mais ça peut être très ennuyeux pour les designers. Je ne doute pas que vous compreniez ce qu’il fait : il s’agit de créer un formulaire. En fait, cela fait bien mieux : cela crée un formulaire en se basant sur un modèle de la base de donnée et en facilitant son interprétation à l’envoi (un autre tour de magie de rails). Le vrai problème pour un designer est que si vous voulez rajouter une class ou un id aux éléments générés ainsi, vous devrez probablement demander à un développeur de le faire (mince, vous n’auriez peut-être pas dû leur poser toutes ces questions sur les tests :] ).

Ce type de fonction est ce qu’on appelle des helpers, et ils nous sont effectivement, à nous, d’une grande aide pour accélérer le développement. Rassurez-vous cependant : j’ai pris un exemple extrême, et vous ne devrez pas être ennuyés plus que cela par eux. En fait, vous retrouverez la plupart du temps les même, et vous saurez vite les modifier vous même. (mais bon, si les développeurs avaient bien fait leur boulot, vous n’auriez pas à les modifier…).

Conclusion

Je conclurai qu’il était vraiment temps de conclure. Oui, le premier contact avec ruby On Rails peut être un peu refroidissant, vis-à-vis du travail à faire pour le mettre en place, mais ce n’est pas peine perdue, vous en serez tout à fait satisfait (parole de développeur). Contrairement à ce que peut laisser penser l’installation, Ruby On Rails a été pensé pour tout accélérer.

Dans ce contexte d’effervecence de la production, vous apprécierez que chacun ait sa partie de l’application consacrée, ce qui permet de limiter les conflits de version svn. En plus comme ça, vous aurez moins à parler aux… Bon d’accord, j’arrête. :]

Je vous propose aujourd’hui l’interview de Evandro Myller, le créateur d’un nouveau framework javascript : UTM.

UTM est un framework qui se distingue sur ce qui constitue le point faibles des frameworks javascript : la vitesse d’exécution (de 40% à 60% plus rapide que JQuery sur les sélecteurs, selon mes benchmarks). Il offre déjà quelques effets intéressants (dans le domaine d’un scriptaculous ou d’un JQuery UI) dans un module qui ne demande qu’à être complété. Il propose un interface de construction du paquet lors du téléchargement en choisissant les composants et en proposant la compression, comme pour le téléchargement de JQuery UI. Mais laissons plutôt la parole à Evandro pour présenter UTM.

D’abord, peux-tu te présenter un peu et expliquer à nos lecteurs ce qu’est UTM?

Et bien, que dire à propos de moi… Je suis chrétien, développeur web se concentrant sur l’expérience utilisateur avec Javascript. J’ai commencé à apprendre ce langage il y a seulement deux ans, mais ça a été mes deux années les plus productives et amusantes.

À propos d’UTM, je suis dessus depuis un peu plus d’un an, quand j’ai commencé à développer quelques bouts de codes isolés pour m’aider (j’apprenais le JS, et je n’avais aucune idée qu’un jour, je construirai un library). Le projet à démarré réellement il y a quelques mois, sur cette idée d’il y a un an. Aujourd’hui, UTM (UlTiMate javascript library) est un projet dont le but est  de donner au programmeur (débutant ou expert) le pouvoir d’écrire des choses cool et puissantes avec quelques simples lignes de code.

Quelle est à ton avis la différence principale entre UTM et les autres framework/libraries?

Je crois que je peux répondre : ses performances. UTM peut faire ce que font les autres libraries, mais il a été conçu autour de conventions qui s’assurent que sa structure est réellement simple et rapide. Le core ne fait que le strict nécessaire pour fournir le bon résultat en moins de temps. C’est donc une bonne base pour tous les composants d’UTM (les effets, les modules supplémentaires, etc). Il a aussi quelque chose de différent et d’utile : un système de modules simple d’utilisation. Vous pouvez importer des modules et leur appliquer des thèmes externes d’un manière très simple : u.include(’your_module’) et, accessoirement, u.useTheme(’theme_name’).

Est-ce qu’UTM s’intègre avec d’autres framework?

Oui. Si vous avez vraiment besoin d’un autre library javascript sur votre site, il n’y a pas à s’en inquiéter. UTM conserve tout dans son namespace, ‘utm’. ‘u’ est un raccourci vers UTM lui-même. Il n’y a donc aucun problème pour travailler avec une autre library, parce qu’il ne change rien du code natif. Et, tu sais, ni ‘utm’ ni ‘u’ ne sont des noms de variables utilisés couramment, n’est-ce pas? =]

Peux-tu démontrer que UTM rox, en trois lignes de code?

Wow, c’est vraiment dur de choisir quoi montrer ici… Mais essayons. Peut-être…

1. u(’div#main p.text:contains(”some text”)’)
2. .append(’a.mainlink[href="page.html"]‘, ‘Some link’)
3. .pulsate(5);

Explications…

1 : C’est un sélecteur CSS3 qui récupère le paragraphe avec la classe ‘text’ et ’some text’ quelque part à l’intérieur, depuis le div qui à l’id ‘main’.

2: Ensuite, ça ajoute un nouveau lien à la fin du paragraphe. Oui, on peut utiliser un sélecteur CSS ici aussi, pour spécifier l’id, la classe et les attributs.

3: Rien qu’un effet. Le nouveau lien va maintenant pulser (fade out puis fade in) cinq fois. =]

Les sélecteurs de JQuery et de UTM sont vraiment plus rapides que ceux de Mootools, et les sélecteurs de UTM sont même encore plus rapide que ceux de JQuery. Peux-tu expliquer pourquoi?

Bien sûr. À la base, UTM tourne plus vite pour trois raisons : la structure du code, le cache et la réutilisation des données des sélecteurs.

Quand je récupère un élément avec un nom de tag depuis un contexte, UTM stock un pointeur vers l’ensemble; donc, si j’ai besoin du même ensemble plus tard, UTM va simplement s’en resservir (ne vous inquiétez pas si un élément a été ajouté ou retiré: HTMLCollection est un objet natif de JS et n’a pas besoin d’être récupéré à nouveau).

Quant à la réutilisation des données, une fois que vous donnez un sélecteur à UTM, il est traité pas à pas et stocké en tant qu’objet. Il sera donc réutilisé par l’ensemble du moteur de sélection sans devoir être retraité à nouveau.

Et tout le code lié aux sélecteurs se trouve au même endroit. C’est simple à lire, toutes les fonctions sont placées au meilleur endroit possible.

Tu m’as dit que la réponse à la question “quelle est la library la plus rapide” peut changer selon le navigateur et l’environnement. Peux-tu expliquer pourquoi et comment UTM gère ça?

Cela dépend de deux facteurs : quelles fonctions du navigateur la library utilise et comment le navigateur gère le code. Par exemple, certains navigateurs ont une fonction appelée ‘document.getElementsByClassName’. C’est réellement plus rapide que n’importe quelle autre manière de récupérer des éléments à partir d’un nom de classe, et donc UTM l’utilise quand le navigateur la connaît.

Le navigateurs peuvent aussi avoir des comportements différents sur les même fonctions. IE6, par exemple, gère les instructions switch beaucoup plus lentement que Firefox. UTM essaie de s’adapter au navigateur tout en ayant le code le plus simple possible.

Pourquoi UTM n’est pas entièrement orienté objet? Est-ce que ça a un impact sur les performances?

L’objet principal utm est entièrement orienté objet. Le prototype principal possède toutes les méthodes que nous pouvons utiliser sur des éléments du DOM. Quelques fonctions simples ne sont pas orientées objet parce qu’elle ne doivent vraiment pas l’être, pour des raisons de simplicité.

Prenons par exemple u.Window (objet provenant du module window) et u.scrollTo (fonction non orientée objet provenant du module scroll). Nous pouvons faire :

var myWindow = new u.Window({ title: ‘a sample window’ });

Cela a du sens, n’est-ce pas? Maintenant…

u(element).scrollTo(target);

Comment utiliserions-nous cela avec new? N’est-ce pas plus simple de cette façon? =]

La library est donc orientée objet quand c’est nécessaire pour des raisons d’usage/performance. Les fonctions les plus simples comme u.trim ou u.clean n’ont vraiment pas à être orientées objet, mais u.Request et u.Window le doivent.

Est-ce qu’il est difficile d’élargir UTM avec de nouveaux modules?

Non, c’est très simple. Il vous suffit d’ajouter une nouvelle fonction au core ou à la collection de ses méthodes d’éléments, ou d’écrire un module. En fait, il suffit d’ajouter du code dans le namespace utm, dans utm.methods, la collection de méthodes customs. Si vous écrivez un plugin, tout est déjà prévu pour que le code soit ajouté automatiquement au chargement.

As-tu besoin d’une quelconque forme d’aide? Apprécierais-tu d’être rejoint par des codeurs français, et que peuvent-ils faire?

Bien sûr! C’est un projet open-source qui a besoin de nous tous pour en faire le meilleur choix pour chacun. Je serai ravi si des codeurs français (et des gens de partout) étaient intéressés par le projet et commençaient à jouer avec. Tout type d’aide serait le bienvenu - opinions, suggestions, code, design de thèmes, tout.

Merci d’avoir sacrifié un peu de ton temps à cet exercice. Bon courage pour la suite

Merci pour cette opportunité de répandre UTM et de le montrer à tes lecteurs! J’espère que le projet sera de plus en plus utile à tous. =]

Staicu Ionut a récemment publié un article dans lequel il revient sur une “grosse erreur” dans la considération des performances des sélecteurs de JQuery : considérer que la sélection est plus rapide lorsque l’expression de recherche est plus spécifique.

Huge mistake!

Pour ceux qui ne saisissent pas bien le terme, être plus spécifique, c’est être plus précis. Soit le code HTML suivant :

<body>
  <ul id="menu">
    <li><a href="lien">lien</a></li>
    <li><a href="lien">lien</a></li>
    <li><a href="lien">lien</a></li>
  </ul>

  <p>paragraphe</p>
  <p>paragraphe</p>
</body>

On considérait que pour sélectionner les liens, il valait mieux utiliser :

$( "ul li a" )

Plutôt que le moins spécifique :

$( "a" )

Je soupçonne cette recommandation d’être dérivée des pratiques du CSS, où il est préférable de toujours être le plus spécifique possible si on ne veut pas avoir des surprises dans l’ordre de priorité des règles.

Selon les tests de Staicu, réalisés avec la fonction profile() de firebug, la seconde forme est pourtant significativement plus rapide.

La raison en est, après coup, évidente : dans la première forme, JQuery cherche d’abord tous les ul, puis tous les li internes, puis tous les a internes.

Les solutions

Pour commencer, il est toujours préférable d’utiliser un id ou une class plutôt qu’une chaîne de sélection. Ainsi, plutôt que de faire $( “#menu li a” ), il est préférable de donner la classe .menuLink aux a et de faire $( “.menuLink” ). Cela semble évident pour ce cas simple, ça l’est moins dans des chaînes complexes. Une règle simple à retenir : la chaîne la plus courte est toujours la meilleure.

Une autre possibilité d’optimisation apparaît alors. Si on place à la base de chaque sélecteur un id ou une class, pourquoi ne pas directement passer par les fonctions builtins de javascript? J’ai moi-même effectué des tests avec le profiler de firebug et j’ai obtenu des résultats significatifs me laissant penser ceci : il est plus rapide d’utiliser getElementById ou getElementsByClassName puis de s’en servir comme contexte dans un sélecteur JQuery, plutôt que de selectionner le tout en une expression JQuery.

Ainsi :

$( "#menu li" )

peut être remplacé, pour optimiser les performances, par :

var context = document.getElementById( "menu" ) ;
$( "li", $(context) ) ;

Voici les deux fonctions que j’ai utilisé dans firebug pour faire mes tests :

function a(){ for (var i=0;i<10;i++){ $( "#menu li" ) } }
function b(){ for (var i=0;i<10;i++){ var c=document.getElementById( "menu" ) ; $( "li", $(c) ) } }

Après avoir profilé ces deux fonctions individuellement une dizaine de fois, il s’avère que la fonction a() s’execute généralement dans le double du temps de la fonction b().

Plutôt refroidissant… Un petit bémol pourtant : nos machines double processeurs avec un giga de RAM peuvent très bien utiliser les techniques les plus lentes de sélection sans même que nous nous en rendions compte. Ce problème ne risque en fait que d’affecter les applications desktop-like de type web3 (comme greader, ou le promis google desktop), qui font un usage intensif de javascript. De quoi nous laisser le temps de voir venir, surtout qu’il y a…

Une bonne nouvelle

John Resig (le créateur de JQuery) travaille actuellement sur un nouveau moteur de sélection. Il estime qu’il sera quatre fois plus rapide que le moteur actuel. Time will tell…

Il y a plusieurs raisons qui causent la désaffection des outils de tests de ruby on rails :

• C’est un ensemble de méthodes nouvelles à prendre en mains. Ces méthodes ne sont jamais utilisées dans une application normale et il faut donc d’abord s’y familiariser.
• Dans une première approche, ces outils semblent particulièrement mal documentés.
• On ne voit pas l’intérêt de perdre du temps à écrire une batterie de test alors qu’on vient de tester manuellement son code au fur et à mesure qu’on l’écrivait. C’est tout sauf “DRY“-ant ou agile.

Cette dernière raison est particulièrement défendable et on en vient vite à se demander comment David Heinemeier Hansson peut à la fois répéter si souvent qu’il faut écrire des tests et en même temps souscrire aux recommandation du getting real.

Quand dois-je écrire mes tests?

C’est en effet des différentes réponses à cette question que vient le malentendu. Deux choix courants conduisent à rapidement négliger les tests :

• Écrire ses tests lorsqu’on a terminé son modèle ou son contrôleur.
• Écrire ses tests après avoir fini d’écrire une méthode.

Le premier choix décourage vite en face du laborieux travail à exécuter, qui se montre parfois plus conséquent que l’écriture première du code, particulièrement si on ne fait pas une application à base de CRUD. Le second choix est plus flexible, mais on se voit obligé de revenir souvent dans le code des tests parce qu’à l’écriture de la méthode suivante, on se rend compte qu’il faut finalement modifier un peu la précédente.

Il y a heureusement une troisième option, et c’est celle qui constitue le sujet de ce billet : le développement piloté par tests.

Le développement piloté par tests inverse radicalement la conception que nous avons des tests. Au lieu de les écrire a posteriori lorsque nous avons terminé un pan de code, il nous conseille d’écrire les tests préalablement à tout code.

Quel intérêt?

L’idée de tester du code qui n’existe pas encore peut paraître étrange, mais c’est pourtant une technique puissante de développement agile et solide.

Lorsque vous vous lancez dans l’écriture de votre code, vous devez déjà avoir une idée des différents éléments qui vont composer votre application et de la manière dont ils vont se comporter. Je ne parle bien sûr pas des nouvelles fonctionnalités qui viendront étendre votre application par la suite lorsque le besoin s’en fera ressentir, mais de la stricte base : mon application contient des User, des Article et des Comment ; chacun doit pouvoir être créé, montré, modifié et effacé, les Article doivent être rattachés à un User et les Comment à un Article. Rajoutez à cela les quelques fonctionnalités particulières à votre application.

Vous pouvez écrire ce design original dans un fichier texte, ou vous pouvez en faire des tests.

Et c’est là tout l’intérêt des tests : ils servent de todo list. En les écrivant avant le code, vous vous assurez:

• d’avoir une idée claire de ce que vous allez faire.
• de savoir précisément où vous en êtes dans votre processus de développement (en faisant signaler les fonctions non écrites ou en faisant échouer leur test).
• que la nouvelle méthode que vous avez implémentée ne casse pas les précédentes.

C’est donc bel et bien un atout pour le développement agile, car cela permet d’assurer la simplicité, l’abstraction et la cohérence de votre code sans devoir revenir sur chaque méthode chaque fois que vous ajoutez un nouveau block de code : les tests vous préviendront si vous devez modifier quelque chose en amont. Cela n’exclue bien sûr pas la nécessité de faire des vrais tests manuels lorsque vous avez terminé une version de votre application, cela permet juste de rendre le développement plus rapide.

Mais où est la documentation?

Si vous avez déjà jeté un bref regard au fonctionnement des tests, vous avez sûrement été frustré de ne pas trouver les méthodes dans la documentation officielle de rails. Où est cet assert partout utilisé? Il y a bien toute une collection de assert_* dans ActionController::Assertions, mais les fonctions de base sont introuvables.

La raison en est simple : les outils de tests font partie d’un framework de tests indépendant et intégré dans rails (et faisant aujourd’hui partie de la librairie standard de ruby), Test::Unit. Vous trouverez dans sa documentation tous les éléments de base dont vous avez besoin.

Rails étend ensuite ces tests avec ses propres ajouts, et particulièrement pour les tests fonctionnels (tests effectués sur les contrôleurs).

Je n’ai pas trouvé d’articles à jour et de qualité en français expliquant en détail la marche à suivre pour utiliser les tests dans rails, je reviendrai donc dessus par la suite avec deux articles, l’un sur les tests unitaires (pour tester les modèles) et l’autre sur les tests fonctionnels (pour tester les contrôleurs).

Dans un article récent faisant partie d’un ensemble d’articles d’initiation à JQuery, Dave Lizotte à fait une présentation rapide des sélecteurs. J’y reviens maintenant pour présenter les fonctionnalités avancées.

Le DOM, c’est quoi?

Au préalable, il est important que vous ayez saisi ce qu’est le DOM, car c’est sur lui qu’agissent les sélecteurs. Je ne vais pas réécrire ici la documentation du w3c, sachez simplement, si vous êtes étranger à cette notion, qu’il s’agit d’une structure représentant votre fichier HTML.

Imaginez-vous une vue en arborescence, avec l’élément html à la racine, et en enfants, les éléments head et body. En dépliant encore, vous trouverez les différents éléments enfants, par exemple un div dans le body, puis un p dans ce div, etc. Pour chacun, vous aurez accès à des attributs (title, id, class, etc) et à un contenu (le innerHTML).

Il vous suffit en fait de vous représenter ça, vous n’avez rien à apprendre. Le DOM n’est pas un langage, juste une interface. Au final, vous aurez l’impression d’agir directement sur le code HTML, et c’est ce que vous ferez, mais par l’intermédiaire du DOM.

Si vous voulez vous représenter cela plus visuellement et vous familiariser à la manipulation du DOM, je vous conseille l’excellente extension firefox qu’on ne présente plus : firebug.

On sélectionne quoi, au fait?

Les sélecteurs de JQuery servent à isoler des éléments du DOM. C’est en fait ce que font la plupart du temps les frameworks Javascript : modifier les éléments du DOM pour changer dynamiquement la page. Pour pouvoir faire cela, il est nécessaire de pouvoir cibler précisément un élément en particulier, ou un groupe d’éléments. C’est le travail du sélecteur.

Notez tout de suite qu’un sélecteur ne renvoie pas nécessairement un unique élément. Si vous utilisez le sélecteur $( ‘p’ ), vous obtiendrez en retour tous les <p> de la page. Il est possible d’itérer sur chacun grâce à la fonction each, mais si vous désirez un élément précis, soyez vous-même le plus précis possible dans votre code (la manière la plus simple étant de sélectionner un élément à partir de son id, comme par exemple $( ‘#footer’ ) ).

On avait pas dit : “avancé” ?

Si. Que ceux qui connaissaient déjà tout cela m’excusent, ce préambule me semblait indispensable pour être sûr que ce soit clair pour tout le monde.

Dans un usage basique, on se content de sélectionner un id, une classe ou un élément. Les sélecteurs JQuery permettent pourtant d’utiliser de puissantes et complexes expressions qui raviront les adeptes d’expressions régulières illisibles. Les outils de ces expressions se classent en deux familles : les selecteurs par hiérarchie et les sélecteurs par filtre. Le mélange savant de ces outils vous permettra de faire des sélections riches et précises.

La sélection par hiérarchie

Comme je l’ai dit plus haut, il faut penser le DOM sur le mode d’une arborescence. Il y a donc des nœuds enfants et des nœuds parents. JQuery permet de naviguer précisément dans cet arbre. Nous allons voir comment au travers de quelques exemples.

Note: j’ai d’abord pensé faire un fichier HTML d’exemple complexe auquel chaque exemple de sélecteur ferait référence, mais cela vous obligerait à remonter dans la page à chaque fois. Je vais donc dupliquer du code pour chaque exemple, au coût d’une page plus longue.

La sélection des descendants est la plus commune. Soit le code :

<div id="header">
  <img src="logo" />
  <ul>
    <li><a href="lien">lien1</a></li>
    <li><a href="lien2">lien2</a></li>
  </ul>
</div>
<div id="content">
  <ul>
    <li><img src="photo1.jpg" /></li>
    <li><img src="photo2.jpg" /></li>
  </ul>
</div>

(au passage, je signale qu’un img doit toujours avoir un attribut alt pour être valide en xhtml strict, et que chaque fois que vous utilisez un div inutile, vous tuez un chaton, mais j’utilise ici des raccourcis pour l’exemple).

Comment vais-je faire si je veux sélectionner les deux photos? Rien n’est plus simple :

$( '#content img' )

img placé après #content signifie qu’il faut selectionner tous les img descendant de #content. Ici, les img ne sont pas directement enfants de #content, mais puisqu’ils sont enfants de li eux-même enfants d’un ul lui-même enfant de #content, ils en sont descendants.

Si on ne veut pas sélectionner tous les descendants mais seulement les enfants directs, on utilise “>”. Ainsi :

<div id="content">
  <img src="viagra.jpg" />
  <ul>
    <li><img src="photo1.jpg" /></li>
    <li><img src="photo2.jpg" /></li>
  </ul>
</div>

Si je veux sélectionner la publicité pour l’envoyer aux oubliettes, mais pas les photos (de préférences), je peux utiliser ceci :

$( '#content > img' )

Cela ne prenant en compte que les enfants directs, les photos, à la charge des li, sont ignorées sur le testament.

Vous devez maintenant saisir un peu mieux la nature des sélecteurs, nous allons pouvoir aller un peu plus vite. Les deux sélecteurs hiérarchiques suivants sont plus amusants, mais je vous dois une mise en garde : ils sont aussi plus sensibles aux modifications de votre code et peuvent causer des bugs difficiles à repérer.

Le sélecteur par proximité permet de sélectionner un élément directement adjacent à un autre.

$( 'li + img' )

Cela permet de sélectionner un img directement adjacent à un li (attention: le li lui-même n’est pas sélectionné).

Le sélecteur de fratrie permet de sélectionner tous les éléments de même type ayant un même parent, situé directement après un frère de référence :

<ul id="famille">
  <li id="premier">enfant 1</li>
  <li id="second">enfant 2</li>
  <li id="troisieme">enfant 3</li>
  <li id="quatrieme">enfant 4</li>
<ul>

Ici, pour sélectionner tous les enfants qui ne sont pas l’ainé, on utilisera :

$( '#premier ~ li' )

Il faut aussi noter que certaines fonctions, ne relevant pas directement des sélecteurs, permettent d’aller encore plus loin, comme la fonction parent(), qui retourne le parent de l’élément sélectionné.

Vous savez donc maintenant traverser précisément l’arborescence du DOM. Des expressions complexes telles que $( ‘#content > ul p span + img’ ) sont tout à fait possible et vous permettent de manipuler des pages complexes. Mais ce n’est ici encore que de la sélection intermédiaire, JQuery nous offre encore d’avantage.

Les filtres

JQuery possède une très vaste collection de filtres permettant d’affiner vos sélections. Je ne vais pas tous les énumérer tant ils sont nombreux, mais je vais vous présenter ceux qui me semblent les plus utiles. Une fois que vous y serez familiarisés, et avec ce qui précède, la documentation officielle vous suffira à trouver votre chemin (oui, ce qu’on vient de voir ne représente pas un dixième de la page :] ).

:first est sans doute le filtre le plus utile lorsque vous voulez être certain de ne sélectionner qu’un seul élément. Il s’utilise ainsi : $( ‘#content ul:first’ ). Quelque soit le nombre de ul que contient #content, seul le premier sera sélectionné. Dans le même genre, il y a :last.

:eq(index) permet de sélectionner un élément comme si c’était l’élément d’un tableau (pour ceux qui ne sont pas familiarisés avec les tableaux en informatique, sachez qu’on compte à partir de 0). Je peux donc facilement sélectionner le troisième li du ul#items en faisant : $( ‘#items li:eq(2)’ ). De la même manière, il y a :gt(index) pour plus grand que (greater than) et :lt(index) pour plus petit que (lesser than).

:contains(text) permet de sélectionner un élément sur la base de son contenu. Ainsi, je peux sélectionner toutes mes notes en faisant : $( ‘p:contains(”N.B.”)’ ).

[attribut] permet de filtrer sur la base de l’existence d’un attribut. Cela prend tout son sens dans la forme [attribut=valeur]. Ainsi, je peux sélectionner toutes les images de ma maison en faisant : $( ‘img[src="images/maison.jpg"]‘ ). Une autre forme intéressante est [attribut*=valeur], le wildcard permettant de préciser une valeur qui ne soit pas exacte. Cela me permet par exemple de sélectionner tous les liens vers le site exemple.fr, quelque soit la page liée, ainsi : $( ‘a[href*="exemple.fr"]‘ ) .

Enfin, si vous codez du CSS, vous avez forcément déjà été ennuyé par l’impossibilité de faire référence à tous les titres en même temps, mais de devoir utiliser h1,h2,h3 ou encore ennuyé par le fait qu’un textfield et un submit sont tous les deux un élément input. JQuery facilite tout ça, grâce au filtre :heading et aux filtres de formulaire.

Pour sélectionner tous les titres, utilisez simplement $( ‘:heading’ ) . Pour sélectionner le bouton d’envoi d’un formulaire de commentaire, on utilise, par exemple : $( ‘#comment_form :submit’ ). Il existe un équivalent pour chaque type de input.

La cerise sur le gâteau : le contexte.

J’espère que vous avez digéré tout cela, c’était copieux. Après avoir joué un peu avec ces sélecteurs, vous devez entrevoir de vastes et complexes possibilités pour sélectionner précisément ce li caché au fin fond d’une série de div, et les div voisins ne vous ennuieront pas grâce à la puissante chaîne de filtres que vous avez organisée…

Oubliez tout.

JQuery, c’est la puissance, mais c’est aussi la simplicité. Pour éviter d’avoir à écrire des sélecteurs de trois lignes, un système de sélection en contexte a été développé. Imaginons le sélecteur suivant :

$( '#content ul:first > li:eq(3) > div.hilighted:gt(2) ul' )

Si je veux opérer sur plusieurs éléments dépendant de ces ul en plusieurs étapes, il serait fastidieux de réécrire ce sélecteur en le complexifiant encore. Le contexte permet de faire ceci :

var context = $( '#content ul:first > li:eq(3) > div.hilighted:gt(2) ul' ) ;
$( 'li:eq(3)', context ).hide() ;
$( 'li:first > a', context ).css( 'color', '#A37BCF' ) ;

Rien ne vous empêche ensuite de coder une fonction dont le contexte sera variable.

Voilà, j’espère que cette explication aura été éclairante, n’hésitez pas à me faire part de vos réactions.

Entraînez-vous à utiliser des selecteurs complexes puis, lorsque vous maîtriserez leurs différentes possibilités, vous pourrez passer à un autre niveau de compréhension. Paul Boag et Marcus Lillington ont avancé dans un podcast l’idée que lorsqu’une application correctement lancée s’approche de la maturité, elle connaît une période de stagnation et que pour sortir de cette stagnation, il faut simplifier. C’est ce que je vous propose dans un prochain article.