accolade.ch

Ce billet est issu de la traduction/adaptation de l’excellent billet de Matt Moore et a été repris avec son accord.

Tous les appels à la méthode find avec des paramètres personnalisés qui sont fait à plus d’un endroit utilisent les named_scope plutôt qu’une méthode spécifique. 

Les named_scope doivent changer votre manière d’utiliser la méthode find. S’il ne vous semble pas évident que cette règle apparaisse ici, vous devez revoir vos bases et comprendre parfaitement la puissance des named_scope. Les named_scope chaînés sont la méthode la plus lisible d’effectuer des finds avec des conditions. Vous devez les utiliser.

NdT : excellente introduction en français aux named_scope et aux autres nouveautés de Rails 2.1 ici.

.find et .find_by_ ne sont jamais utilisés dans vos vues ou dans vos helpers.

Si vous utilisez .find ou .find_by_ sur un de vos modèles dans une vue, il y a 99% de chance qu’il y ait une meilleure manière de faire ça - et vous devez le faire !

Dans le pire des cas, vous devez utiliser un named_scope et l’appeler depuis la base du modèle. Le plus souvent, vous devez appeler une association ou une méthode personnalisée de votre modèle (sur laquelle vous pouvez chaîner un named_scope).

Par exemple, si vous voulez trouver tous les articles récents pour les lister  dans une vue d’un billet (@post) vous avez sûrement écrit : Articles.find(:all, :conditions =>…). Mais vous devriez plutôt écrire : Articles.recent (named_scope) ou encore mieux @post.related.recent (named_scope chaînés).

Il n’y a aucun code personnalisé qui duplique une fonctionnalité intégrée à Rails.

Même si c’est une règle générale de la programmation, elle est encore plus importante avec Rails. Contrairement à d’autres frameworks ou langages, Ruby on Rails fournis beaucoup de helpers pour afficher les choses correctement et pour faire des tâches courantes. Mais elles sont disséminées dans plein de fichiers différents - des modules qui sont mis ensemble au moment opportun.

Heureusement, le code de base de Rails est très bien écrit, même aux endroit ou il manque de la documentation. Pour trouver les méthodes que vous pouvez utiliser, je vous suggère de garder une copie du code source de Rails dans votre éditeur de texte ou votre IDE - dès que vous en avez besoin, vous pouvez faire une recherche dans les sources de Rails.

Le code a été écrit sans répétition (Don’t Repeat Yourself - Ne vous répétez pas) durant tout le développement.

Etant donnée la manière dont Ruby a été conçu, il est très simple de ne pas répéter son code durant le développement. Créez des helpers, créez des modules, créez des plugins. Tout le temps, tout le temps, tout le temps !

Toutes les fonctionnalités utilisées dans deux modèles ou plus ont été transformées en module ou en librairie.

Peut être que le plus gros avantage de Ruby sur les langages du style Java est les mixins (modules). Ne l’ignorez pas et utiliser les à bon escient.

En orientation objet à la manière Java, pour partager une fonctionnalité entre des classes, vous devez généralement écrire une sous-classe. En Ruby ce n’est pas le cas, vous pouvez mélanger des fonctionnalités de plusieurs modules différent dans n’importe quelle classe ou objet, même durant l’exécution.

Prenez le temps de bien comprendre les modules et utilisez les pour partager du code (qui était dupliqué) entre des modèles (et des contrôleurs). !

Articles relatifs

• Vérifier la qualité du code d’une application Ruby on Rails - Partie 1 (1)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 4 (0)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 3 (0)

Ce billet et les trois prochains billets qui composent cette série sont issus de la traduction/adaptation de l’excellent billet de Matt Moore et ont été repris avec son accord.

Ruby On Rails est une des combinaisons langage/framework les plus difficiles à maitriser. Pour quelqu’un qui s’est formé avec C, C++ et Java, Ruby a une approche très différente (et meilleure !) de l’orientation objet et Rails est un framework qui repose beaucoup sur des bonnes pratiques à garder constamment à l’esprit.

Il est donc primordial que les développeurs qui se lancent dans ce couple Ruby/Ruby On Rails sortent du style Java pour produire un code qui respecte les bonnes pratiques de Ruby et de Ruby On Rails. Nous allons passer en revue les grands points qui font d’une application Ruby On Rails une application bien développée.

Chaque action d’un contrôleur contient un seul appel à une méthode du modèle autre qu’un appel à un Find ou à un Create initial. Faites des méthodes new et update personnalisées dans votre modèle avec tout le code nécessaire aux traitements.

Fat models and skinny controllers (gros modèles et contrôleurs épurés) est la méthodologie préconisée dans Rails. Dans presque tous les cas, vous pouvez placer toute la logique dans les modèles, ainsi les contrôleurs ressemblent comme deux gouttes d’eau aux contrôleurs générés par script/generate. Vous n’avez qu’à changer les appels aux méthodes génériques new et update_attributes par des méthodes personnalisées de votre modèle. Un exemple simple est le cas ou les attributs du modèles doivent être mis à jour par un utilisateur particulier :

@modele.update_attributes_by_user(params[:modele], current_user)

Le seul cas ou la logique doit être placée dans le contrôleur intervient si vous devez afficher une autre action ou effectuer une redirection spécifique.

Seules une ou deux variables d’instance sont partagées entre chaque contrôleur et la vue.

Il est très facile de partager beaucoup de variables d’instance entre les contrôleurs et les vues en Rails et ceci peu rapidement conduire à un code ingérable. Ceci est également potentiellement dangereux pour les performances puisque cela finira par faire double emploi avec des associations existantes. Vos contrôleurs doivent gérer uniquement une variable d’instance et  éventuellement une seconde pour le current_user. Ainsi, tous les appels vers des associations sont chargés “à la demande” et peuvent par exemple être mis en cache à un seul endroit.

Cette méthode fonctionne également très bien pour la mise en cache de fragments puisque vous pouvez vérifier le contenu du cache dans vos vues avant de charger les associations.

Par exemple, plutôt que de créer dans votre contrôleur Blog deux variables d’instance @post et @related_post, créer plutôt une seule variable @post et créez dans votre modèle Post une méthode related_posts afin de pouvoir appeler @post.related_posts dans vos vues. 

Tous les noms de modèles et de variables sont évidents (pour un nouveau développeur) et le plus court possible sans utiliser d’abréviations

Le nommage est difficile. Plus particulièrement pour les développeurs qui sont plongés dans une application : ce qui est évident pour vous qui avez le contexte de l’application bien en tête ne sera pas forcément évident plus tard ou pour un nouveau venu dans le projet.

Une des meilleures choses en Ruby et Ruby On Rails est justement que les noms sont cours et évidents. Ne détruisez pas cette immense force !

Si vous n’arrivez pas à trouver un nom ingénieux, clair et court immédiatement, finissez de coder votre méthode et mettez un TODO. En fin de journée, tentez de vous déconnecter complètement du contexte et renommez vos variables et méthodes.

Articles relatifs

• Vérifier la qualité du code d’une application Ruby on Rails - Partie 2 (0)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 4 (0)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 3 (0)

Heroku, présenté ici, permet non seulement de développer son application Rails dans un IDE en ligne mais également de récupérer localement l’application pour la modifier. Pour cela, le service utilise l’outil de contrôle de version à la mode : Git.

Pour utiliser Git sous Windows je vous conseille d’utiliser MsysGit et d’installer la version “If you only want to use Git”. Une fois installé il suffit de lancer “Git bash” puis de créer une clé SSH grâce à la commande :

ssh-keygen -C moi@mondomaine.net -t rsa

Vous pouvez ensuite accepter le chemin par défaut pour la clé (C:\Documents and Settings\Utilisateur\.ssh\) et saisir une passphrase.

Git est désormais installé et prêt à  être utilisé. MsysGit intègre une interface graphique pour utiliser Git mais elle reste bien moins évoluée que les interfaces que l’on trouve aujourd’hui pour Subversion. Si vous souhaitez utiliser GitHub, il suffit de recopier le contenu du fichier id_rsa (situé dans le répertoire C:\Documents and Settings\Utilisateur\.ssh\) créé par la commande ssh-keygen dans le champ “SSH Public Key” de l’interface GitHub.

Mais revenons en à Heroku ! Vous devez maintenant installer le gem heroku :

gem install heroku

puis vous pouvez ensuite profiter de toutes les fonctions fournies par celui-ci :

• heroku list : liste toutes les applications sur votre compte
• heroku create [nom] : créé une application avec le nom “nom”
• heroku clone [nom] : clone localement l’application nommée “nom”
• heroku destroy [nom] : détruit l’application nommée “nom”

En admettant que vous avez déjà créé votre application depuis l’interface d’Heroku, il vous suffit d’exécuter la commande :

heroku clone monapplication

afin d’obtenir une version locale de l’application. Vous pouvez ensuite l’éditer puis exécuter les commandes suivantes pour mettre vos modifications en ligne sur Heroku :

git add .
git commit -m "Description des changements"
git push

Lorsque vous exécutez git push, les migrations sont également exécutée sur Heroku.

Le fichier .gitignore à la racine de votre application locale contient tous les fichiers qui ne sont pas transmis à Heroku lorsque vous exécutez la commande git push. Ainsi le fichier config/database.yml local peut être modifié pour correspondre à votre serveur de développement sur votre poste sans risquer d’empêcher le fonctionnement de l’application sur Heroku. Vous pouvez modifier le fichier .gitignore suivant vos besoins.

Vous retrouvez toutes les révisions Git de votre application dans l’interface d’Heroku sous le lien Revisions (colonne de gauche). Lorsque vous récupérez localement votre application, c’est la dernière révision en ligne qui est récupérée. Si vous avez fait des modifications en ligne, vous devez donc les commiter (en cliquant sur le bouton Revisions) avant de pouvoir les récupérer localement. Soyez prudent car si vous modifiez votre application en ligne sans la commiter, puis vous commitez votre application locale, toutes les modifications faites en ligne seront perdues !

PS : vous trouverez une excellente “cheat sheet” pour Git ici.

Articles relatifs

• IDE pour Ruby On Rails (1)
• E-texteditor - Un ersatz de Textmate pour Windows (0)
• ASP.Net ou RoR ? (3)

Petite subtilité du langage Ruby qui est interprétée différemment dans ActiveRecord : le point d’exclamation. En Ruby, une méthode que l’on appelle sans point d’exclamation ne va pas modifier l’objet passé en paramètre :

irb(main):001:0> ligne = 'ma phrase avec un espace en fin de ligne '
=> "ma phrase avec un espace en fin de ligne "
irb(main):002:0> ligne.strip
=> "ma phrase avec un espace en fin de ligne"
irb(main):003:0> ligne
=> "ma phrase avec un espace en fin de ligne "

La méthode a donc édité l’objet puis a retourné l’objet édité sans modifier l’objet original. En appelant cette méthode avec un point d’exclamation, l’objet original est édité et sauvé :

irb(main):004:0> ligne.strip!
=> "ma phrase avec un espace en fin de ligne"
irb(main):005:0> ligne
=> "ma phrase avec un espace en fin de ligne"

Toutefois, l’utilisation du point d’exclamation dans ActiveRecord est différente puisque ActiveRecord va lever une exception en cas de problème lors de l’exécution de la commande appelée avec un point d’exclamation ou se contenter de returner true ou false si la méthode est appelée sans point d’exclamation.

Articles relatifs

• Vérifier la qualité du code d’une application Ruby on Rails - Partie 1 (1)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 2 (0)
• Utiliser Git avec Heroku sous Windows (0)