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 tests passent avant que le code soit mergé dans le dépôt.

Chacun peut garder sa copie de travail locale comme sauvegarde (git facilite cette approche). Mais dès qu’un produit est lancé, ne mergez jamais votre code avec la branche en cours d’utilisation tant que tous les tests ne passent pas.

Tous les problèmes corrigés sur un produit en production sont testés pour éviter les régressions.

La pire chose que vous pouvez faire dans votre business est d’avoir le même bug deux fois. Empêchez un problème de se reproduire grâce à des tests de régressions. Un utilisateur peut comprendre qu’un bug survienne une fois. Pas qu’il réapparaisse !

Le code des plugins installés est passé en revue (code review)

La plupart des plugins de la communauté Ruby on Rails sont généralement bien voir très bien écrits. Cependant, le nombre de plugins mal conçu va augmenter. Passez toujours en revue le code d’un plugin avant de l’utiliser en production. En général, plus le code est court, simple, testé et facile à comprendre, meilleur est le plugin !

Comprenez vous comment ça fonctionne ? Les impacts sur les performances ?

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 3 (0)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 2 (0)

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

La logique qui est dupliquée entre deux (ou plus) applications est transformée en plugin gemifié-

Maintenant que les plugins peuvent être gemifiés, il n’y a aucune raison de ne pas faire de plugins. Ils sont faciles à faire et désormais faciles à réutiliser et gérer entre les déploiements.

Contrairement à d’autres framework, les plugins dans Ruby On Rails sont très légers et faciles à coder. Il peut être intéressant de faire un plugin même si ce n’est que pour 5 ou 6 lignes de code.

Et plus généralement, votre code sera plus simple à migrer vers un autre framework Ruby comme Merb par exemple.

STI (Single Table Inheritance) n’est utilisée nulle part !

J’ai vu pas mal d’applications rails. Je n’ai jamais vu une application Rails ou l’utilisation de STI était une bonne décision. Je l’ai vu souvent lorsque quelqu’un est nouveau et pense que STI est une bonne manière de partager du code.

Mais avec Rails, il est tellement simple d’ajouter des colonnes à des tables et de partager du code entre des modèles … sans STI !

Il vaut mieux générer différents modèles et utiliser un module ou deux pour partager de la logique entre les deux. L’utilisation de partials communes permet également de partager le code des vues. Si vous utilisez STI, vous allez lier les deux modèles d’une manière dont il sera difficile de se défaire… une migration de données n’est jamais fun !

Les associations polymorphiques, en revanche, sont encouragées !

Chaque choix de design doit conduire au design le plus simple possible pour les besoins actuels. Ne faites pas d’hypothèses sur des futures fonctionnalités pour vos choix de design.

Ceci peut être résumé  tout simplement par : “The Rails Way”. Ce paradigme est aussi important pour les chefs de projets que pour les développeurs - ces deux types de personnes ont la responsabilité de s’assurer qu’il est bien suivi !

Le chapitre 4 de Getting Real l’explique très bien mais nous proposons ici un petit résumé. Si vous faites des suppositions au lieu de designer votre application selon les faits, inévitablement vos suppositions seront fausses.  Certaines seront peut être justes mais tous les designs et développements qui reposent sur des suppositions fausses rendent les choses plus complexes, plus difficiles à corriger et plus difficiles à améliorer.

Codez plutôt à partir des choses dont vous êtes sûrs, lancez rapidement une version, regardez les utilisateurs et itérez rapidement. C’est un des avantages majeurs des applications en lignes sur les applications clientes - utilisez le donc à son maximum !

Une couverture de tests quasi complète existe au plus haut niveau de l’application : sur et entre les actions des contrôleurs. La couverture est la plus complète pour le code le plus utilisé.

Même si les tests unitaires peuvent être importants pour le développement itératif, la plupart des applications Rails jeunes ont  un modèle assez simple. Vous devez faire attention que tous les points d’interactions pour les utilisateurs sont bien testés et restent fonctionnels release après release.

La méthode la plus simple pour choisir les priorités dans votre couverture de test ? Par le nombre d’utilisateurs finaux qui vont utiliser cette portion de code.

Articles relatifs

• 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 1 (1)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 2 (0)

L’image choisie pour illustrer cet article est volontairement provocatrice et vous l’aurez sûrement reconnue (elle n’est pas de moi - voir crédit en fin de billet). J’ai choisie cette image car je pense que grâce à Rails et à quelques autres outils, le déploiement n’est absolument pas quelque chose de difficile et stressant comme certains tendent à le montrer avec des applications PHP par exemple.

1 - Utiliser un outil de gestion de versions

Que ce soit Subversion, CVS, Git ou n’importe quel autre outil de gestion de version, ne faites jamais l’impasse sur cet outil. La plupart de ces outils sont gratuits et open-source et si vous décidez de ne pas laisser votre dépôt (repository) en local, il ne vous coûtera que quelques euros par mois pour profiter d’un service hébergé (j’utilise assembla.com par exemple). Même si vous êtes l’unique développeur du projet, la gestion de version vous permettra de revenir sans problème à une version stable du projet.

Idéallement vous pouvez travailler avec deux branches différents, une pour les développements en cours et un pour les releases. Lorsque vous avez fini une modification et qu’elle est prête à être déployée, vous n’avez qu’à merger votre branche de développement dans la branche de release. Ceci vous permet de faire des gros développements qui durent longtemps tout en assurant la maintenance régulières du projet.

Enfin n’oubliez pas, ne jamais déposer des modifications si celles-ci ne passent pas tous les tests (voir également point 4) !

2 - Utiliser Capistrano

Capistrano est un outil destiné à l’automatisation de tâches via SSH. Il est très connu et utilisé dans la communauté Ruby et Ruby On Rails car il permet notamment d’automatiser les déploiements d’une application.

Il permet de gérer un déploiement d’une application sur plusieurs serveurs (mongrel, base de données…) depuis un outil de gestion de versions (comme Subversion). En une seule ligne de commande (cap deploy par exemple) vous pourrez ainsi déployer une nouvelle version de votre application sans aucun soucis ! Les fichiers sont extraits du dépôt, les migrations exécutées etc… Si jamais un déploiement venait à mal se passer (?), il vous suffit de lancer la commande cap rollback et votre application sera remise dans son état précédent !

Vous l’aurez compris, Capistrano est la pierre centrale d’un déploiement simple, sûr et serein !

3 - Utiliser un serveur de pré-production

Même si vous pensez que votre machine de développement reproduit fidèlement votre environnement de production, il est très difficile d’en être sûr à 100% tout le temps. Investissez donc dans un serveur de pré-production qui sera une copie exacte de votre serveur de production. Avant de déployer en production une nouvelle version, déployez là en pré-production pour vous assurer que tout fonctionne comme prévu.

Capistrano dispose d’une extension “multiple-stages” pour vous obliger à définir lors du déploiement vers quel environnement vous souhaitez déployer votre application.

4 - Tester, tester, tester

Rails intègre tous les outils nécessaires à la réalisation de tests unitaires, fonctionnels et d’intégrations. Profitez-en ! J’en reparlerai dans un prochain billet mais je ne peux que vous recommander de faire du développement piloté par les tests (Test-driven development), vous dormirez mieux là nuit

5 - Non, rien d’autre !

Pas besoins de 15 conseils, si vous appliquez correctement les 4 conseils ci-dessus, vous êtes à l’abri de la plupart des problèmes et surtout, vous pouvez revenir en quelques secondes dans un état stable !

Crédit image : logo de Capistrano

Articles relatifs

• 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 1 (1)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 3 (0)

En plus de changer de job, je fais (enfin) mon retour sur Mac Os X. Ex possesseur d’un Powerbook G4 12″ (dernière release) puis d’un MacBook (première release), j’ai suivi avec beaucoup d’attention la keynote “spéciale portable” du 14 octobre. Autant dire que je n’ai pas été déçu !

Je vois déjà les nouveaux MacBook alu ce profiler comme les dignes successeurs de mon feu PowerBook 12″. Il ne fait aucun doute que ces machines sont idéales pour mon job de développeur Ruby On Rails.

Textmate reste à mon avis le meilleur IDE pour Rails et j’ai déjà replongé dans la logithèque Mac qui me fascine toujours autant par la qualité des réalisations. J’ai donc déjà préparé ma petite liste afin de patienter encore quelques jours :

Et j’ai bien sûr profité d’une visite récente à Dublin pour partir à en quête d’un nouveau MacBook que j’ai fini par découvrir chez un revendeur Apple assez bien fourni à côté de Trinity college (sur Nassau Street).

Je suis persuadé que ce sera le compagnon idéal de mon iPhone en attendant de réunir toute la famille (un nouveau clavier alu et un Cinema Display LED 24″).

Articles relatifs

• Déballage du MacBook Alu 2.4 Ghz (0)
• Protection pour iPhone 3G (0)
• Le parfait équipement du télétravailleur - Partie 4 : matériel informatique (0)

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)

Par défaut, lorsque qu’une erreur de votre application survient (erreur 500), Rails se contente d’afficher la page 500.html située dans le répertoire Public. Il est donc de votre ressort de remonter l’erreur afin de pouvoir la corriger afin qu’elle ne se reproduise plus.

Hoptoad est un service en ligne gratuit qui vous propose de se charger de vous informer des erreurs de votre application. Pour celà vous devez vous inscrire puis intégrer Hoptoad dans votre application. Pour celà vous devez tout d’abord installer le plugin hoptoad_notifier :

script/plugin install git://github.com/thoughtbot/hoptoad_notifier.git

Puis créer un fichier hoptoad.rb dans votre dossier /config/initiliazers/ contenant le code suivvant :

HoptoadNotifier.configure do |config|
  config.api_key = 'votre_cle_ici'
end

Enfin pour finir, il ne vous reste plus qu’à ajouter la ligne suivante dans votre fichier app/controllers/application.rb :

include HoptoadNotifier::Catcher

Désormais toutes les erreurs remontées par votre application apparaîtrons dans l’interface de Hoptoad. Hoptoad vous informe à votre convenance de ces erreurs par courriel ou directement dans son interface web et fait également office de suivi de bogues simplifié pour les erreurs qui lui sont remontées. Hoptoad dispose d’une API qui doit permettre de le connecter à d’autres services comme un outil de suivi de projet mais je ne connais pas encore d’intégration existante avec un outil comme Lighthouse par exemple.

Articles relatifs

• 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 1 (1)
• 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)

Un code HTML valide nécessite d’intégrer les fichiers javascripts et CSS uniquement entre les balises <header> de vos pages. Il arrive pourtant fréquemment que l’on ai besoin d’un fichier CSS ou javascript propre à une vue ou à un partial. Dans ce cas nous serions tenter de simplement intégrer les fichiers javascripts et CSS dans ce fichier. Pourtant il existe des alternatives simples et efficaces afin de s’assurer que ces inclusions soient bien faites entre les balises <header> de votre page.

Vous pouvez par exemple utiliser les plugins Styler et Javascripters qui vous demande de renommer vos fichiers en fonction des nom d’actions ou de contrôleurs ou vous voulez qu’ils soient inclus. Celui-ci présente à mon avis des gros inconvénients puisque si vous souhaitez inclure 2 fichiers CSS spécifiques, vous êtes obligé de les concaténer dans un seul fichier ce qui n’est, vous en conviendrez, pas toujours très “DRY” (Don’t Repeat Yourself - Ne vous répétez pas).

Needy controllers est un autre plugin qui vous permet de spécifier les fichiers javascripts et CSS à inclure directement dans vos contrôleurs. Il gère les propriétés :only et :except pour vous permettre de gérer finement les inclusions. Bien que ce plugin soit très souple, il ne me convient pas puisqu’il lie très fortement les vues (les fichiers CSS et javascript) aux contrôleurs. Il ne respecte donc pas les principes de séparation des couches du modèle MVC.

La solution que j’ai retenu repose sur des méthodes standards de Rails : content_for et yeld. La méthode content_for permet de spécifier un bloc qui sera stocké pour être ensuite affiché par la méthode yeld. Vous comprenez aisément que ces méthodes peuvent être mises en oeuvre pour intégrer vos fichiers javascripts et CSS en respectant les principes DRY et MVC.

Pratiquement, insérons un appel à yeld entre les balises <head> de notre layout :

<head>
	<%= stylesheet_link_tag 'demo' %>
	<%= yield "page_header" %>
</head>

puis dans les vues ou vous avez besoin d’utiliser des fichiers CSS ou javascript spécifiques, il ne vous plus qu’à utiliser le code suivant :

<% content_for("page_header") do %>
	<%= stylesheet_link_tag 'monfichier.css' %>
	<%= javascript_include_tag 'monfichier.js' %>
<% end %>

Cette méthode est bien sûr réutilisable dans beaucoup d’autres situations !

Articles relatifs

• 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 1 (1)
• Vérifier la qualité du code d’une application Ruby on Rails - Partie 3 (0)

Mon billet concernant les “méthodes de recrutement des compétences web” n’était pas anodin puisque je me basais complètement sur mon expérience personnelle pour étayer mon argumentation. En effet, malgré mes nombreux billets sur les technologies Internet (PHP, Ruby On Rails), je ne suis pas un travailleur du web dans la mesure ou mon emploi à plein temps n’a strictement rien à voir avec Internet (développement de logiciels de gestion).

A l’époque ou j’ai rédigé le billet concernant le recrutement, je venais de découvrir une annonce très intéressante mêlant e-commerce et Ruby On Rails avec, comble du comble, la possibilité pour moi de postuler “en un clic” grâce à mon profil sur profession-web.ch. Quelques échanges de courriels plus tard et une rencontre, me voilà donc entré définitivement dans la grande famille des travailleurs du web en tant que développeur Ruby On Rails !

Je vie donc mes dernières semaines d’intermittent du web. Je profite également de ce changement pour faire mon “back switch” sur Mac après deux ans d’absence. Mon retour sur Mac coïncide presque avec l’ouverture des premiers Apple Store en Suisse (jeudi à 17h pour Genève et vendredi 10h pour Zürich) ainsi que, je l’espère vivement, le renouvellement de la gamme des portables Apple.

Articles relatifs

• Le retour de vacances c’est … (0)
• Tags dans Wordpress, Simple Tagging (0)
• Refonte du blog, étape 1/2 terminée (0)

Combien de fois vous êtes vous déjà dit : “je n’ai pas vu le temps passer” ou “je n’ai rien eu le temps de faire” ? Si vous travaillez sur un ordinateur (Mac ou Windows), RescueTime va pouvoir vous aider à répondre en partie à ces éternelles questions !

Pour celà, il est nécessaire de s’inscrire sur le site rescuetime.com puis d’installer un client sur son ordinateur. Dernière étape, configurer ce client : saisir les identifiants de connexion et - fortemment conseillé - personnaliser la liste des adresses Internet que rescuetime intègre dans son suivi (pour éviter de polluer votre analyse).

Désormais RescueTime enregistre toute exécution d’une application avec la durée d’utilisation. Pour votre navigateur Internet, RescueTime enregistre également l’adresse Internet qui est visitée. En vous connectant sur RescueTime.com avec vos identifiants vous retrouvez des statistiques sur l’utilisation de votre ordinateur. Pour celà vous devez tagger vos différentes applications et, je vous le conseille, supprimer toutes les données inutiles. En effet, RescueTime enregistre absolument tout ce qui fait que vous vous retrouvez avec quelques secondes pour chaque petite application exécutée (une installation par exemple).

Une fois vos données assainies et taggées (ne vous perdez pas dans un trop grand nombre de tag, allez à l’essentiel !) vous pouvez préciser la productivité de chaque tag. Ceci permet à RescueTime de vous donner des indications sur votre efficacité et votre productivité.

Je n’ai pas eu l’occasion de tester cette fonctionnalité mais RescueTime propose un mode “groupe” qui permet de suivre la productivité et l’efficacité globale d’un groupe d’utilisateur ainsi que celle de chaque individu de ce dernier.

Moyennant quelques efforts de mise en place RescueTime vous permet donc d’obtenir assez facilement des informations intéressantes pour tenter d’améliorer votre productivité en chassant le temps perdu sur certains sites ou certaines applications.

Il existe des alternatives à RescueTime comme Wakoopa (service en ligne également et qui intègre une dimension sociale en permettant de partager des données avec des amis) ou Slife (application gratuite - MacOs X Leopard uniquement, version Windows en cours de développement).

Articles relatifs

• E-texteditor - Un ersatz de Textmate pour Windows (0)
• Windows Live Writer - Le retour des applications lourdes ? (0)
• Vers un retour aux serveurs centraux ? (3)