Tutoriel Ruby on Rails

Apprendre Rails par l'exemple

Michael Hartl

Contenu

  1. Chapitre 1 De zéro au déploiement
    1. 1.1 Introduction
      1. 1.1.1 Commentaires pour les lecteurs différents
      2. 1.1.2 “Dimensionner” Rails
      3. 1.1.3 Conventions utilisées dans ce livre
    2. 1.2 Debout et au boulot
      1. 1.2.1 Environnements de développement
        1. IDEs
        2. Éditeurs de texte et lignes de commande
        3. Navigateurs
        4. Note à propos des outils
      2. 1.2.2 Ruby, RubyGems, Rails, et Git
        1. Installation de Rails (Windows)
        2. Installer Git
        3. Installer Ruby
        4. Installer RubyGems
        5. Installer Rails
      3. 1.2.3 La première application
      4. 1.2.4 Bundler
      5. 1.2.5 Le serveur rails (rails server)
      6. 1.2.6 Modèles-Vue-Contrôleur (MVC)
    3. 1.3 Contrôle de versions avec Git
      1. 1.3.1 Installation et réglages
        1. Initialisation des réglages système
        2. Initialisation des réglages du dépôt (repository)
      2. 1.3.2 Ajout et mandat de dépôt
      3. 1.3.3 Qu'est-ce que Git peut faire de bien pour vous ?
      4. 1.3.4 GitHub
      5. 1.3.5 Branch, edit, commit, merge
        1. Branch
        2. Edit
        3. Commit
        4. Merge
        5. Push
    4. 1.4 Déploiement
      1. 1.4.1 Réglages Heroku
      2. 1.4.2 Déploiement Heroku, première étape
      3. 1.4.3 Déploiement Heroku, seconde étape
      4. 1.4.4 Commandes Heroku
    5. 1.5 Conclusion
  2. Chapitre 2 Une application démo
    1. 2.1 Planifier l'application
      1. 2.1.1 Modéliser les utilisateurs
      2. 2.1.2 Modéliser les micro-messages
    2. 2.2 La ressource Utilisateurs (Users)
      1. 2.2.1 Un tour de l'utilisateur
      2. 2.2.2 MVC en action
      3. 2.2.3 Faiblesses de la ressource Utilisateurs (Users)
    3. 2.3 La ressource Micro-messages (Microposts)
      1. 2.3.1 Un petit tour du micro-message
      2. 2.3.2 Appliquer le micro aux micro-messages
      3. 2.3.3 Un utilisateur has_many micro-messages
      4. 2.3.4 Hiérarchie des héritages
      5. 2.3.5 Déployer l'application Démo
    4. 2.4 Conclusion
  3. Chapitre 3 Pages statiques courantes
    1. 3.1 Pages statiques
      1. 3.1.1 Pages HTML statiques
      2. 3.1.2 Les pages statiques avec Rails
    2. 3.2 Premiers tests
      1. 3.2.1 Outils de test
        1. Auto-test
      2. 3.2.2 TDD : Rouge, Vert, Refactor
        1. Spork
        2. Rouge
        3. Vert
        4. Refactor
    3. 3.3 Pages (un peu) dynamiques
      1. 3.3.1 Test d'un changement de titre
      2. 3.3.2 Réussir les tests de titre
      3. 3.3.3 Variables d'instance et Ruby embarqué
      4. 3.3.4 Supprimer les répétitions avec les layouts
    4. 3.4 Conclusion
    5. 3.5 Exercices
  4. Chapitre 4 Rails au goût Ruby
    1. 4.1 Motivation
      1. 4.1.1 Un helper pour le titre
      2. 4.1.2 Feuilles de styles (CSS — Cascading Style Sheets)
    2. 4.2 Chaines de caractères et méthodes
      1. 4.2.1 Commentaires
      2. 4.2.2 Chaines de caractères
        1. Impression
        2. Chaines de caractères « apostrophées »
      3. 4.2.3 Objets et passage de message
      4. 4.2.4 Définition de méthode
      5. 4.2.5 Retour à l'« helper » de titre
    3. 4.3 Autres structures de données
      1. 4.3.1 Tableaux et rangs
      2. 4.3.2 Blocs
      3. 4.3.3 Tables de hachage et symboles
      4. 4.3.4 CSS revisitées
    4. 4.4 Classes Ruby
      1. 4.4.1 Constructeurs
      2. 4.4.2 Héritages de classes
      3. 4.4.3 Modifier les classes d'origine
      4. 4.4.4 Classe de contrôleur
      5. 4.4.5 La classe utilisateur
    5. 4.5 Exercices
  5. Chapitre 5 Poursuivre la mise en page
    1. 5.1 Ajout de structure
      1. 5.1.1 Navigation du site
      2. 5.1.2 Personnalisation CSS
      3. 5.1.3 Partiels
    2. 5.2 Liens pour la mise en page
      1. 5.2.1 Test d'intégration
      2. 5.2.2 Routes Rails
      3. 5.2.3 Nommer les routes
    3. 5.3 Inscription de l'utilisateur : une première étape
      1. 5.3.1 Contrôleur Utilisateur
      2. 5.3.2 URL d'inscription
    4. 5.4 Conclusion
    5. 5.5 Exercices
  6. Chapitre 6 Modéliser et afficher les utilisateurs, partie I
    1. 6.1 Modèle utilisateur
      1. 6.1.1 Migrations de la base de données
      2. 6.1.2 Le fichier modèle
        1. Annotation des modèles
        2. Attributs accessibles
      3. 6.1.3 Créer des objets Utilisateur
      4. 6.1.4 Recherche dans les objets Utilisateurs
      5. 6.1.5 Actualisation des objets Utilisateurs
    2. 6.2 Validations utilisateur
      1. 6.2.1 Valider l'existence
      2. 6.2.2 Valider la longueur
      3. 6.2.3 Valider le format
      4. 6.2.4 Valider l'unicité
        1. L'avertissement d'unicité
    3. 6.3 Afficher les utilisateurs
      1. 6.3.1 Débuggage et environnements Rails
      2. 6.3.2 Modèle, Vue et Contrôleur Utilisateur
      3. 6.3.3 Ressource Utilisateurs
        1. Paramètres pour le déboggage
    4. 6.4 Conclusion
    5. 6.5 Exercices
  7. Chapitre 7 Modéliser et afficher les utilisateurs, partie II
    1. 7.1 Mots de passe non sécurisés
      1. 7.1.1 Valider le mot de passe
      2. 7.1.2 Migrer un mot de passe
      3. 7.1.3 Fonction de rappel dans l'Active Record
    2. 7.2 Sécuriser les mots de passe
      1. 7.2.1 Test de mot de passe sécurisé
      2. 7.2.2 Un peu de théorie sur la sécurisation des mots de passe
      3. 7.2.3 Implémenter la méthode has_password?
      4. 7.2.4 Méthode d'authentification
    3. 7.3 Meilleures vues d'utilisateurs
      1. 7.3.1 Tester la page de l'utilisateur (avec factories)
      2. 7.3.2 Un nom et un Gravatar
        1. Un « helper » de Gravatar
      3. 7.3.3 Une barre utilisateur latérale
    4. 7.4 Conclusion
      1. 7.4.1 Dépôt Git
      2. 7.4.2 Déploiement Heroku
    5. 7.5 Exercices
  8. Chapitre 8 Inscription
    1. 8.1 Formulaire d'inscription
      1. 8.1.1 Utiliser form_for
      2. 8.1.2 Le formulaire HTML
    2. 8.2 Échec de l'inscription
      1. 8.2.1 Test de l'échec
      2. 8.2.2 Un formulaire fonctionnel
      3. 8.2.3 Inscription : messages d'erreur
      4. 8.2.4 Filtrer les paramètres d'identification
    3. 8.3 Succès de l'inscription
      1. 8.3.1 Tester le succès de l'inscription
      2. 8.3.2 Le formulaire d'inscription finalisé
      3. 8.3.3 Le message « flash »
      4. 8.3.4 La première inscription
    4. 8.4 Test d'intégration RSpec
      1. 8.4.1 Tests d'intégration avec les styles
      2. 8.4.2 Un échec d'inscription ne devrait pas créer un nouvel utilisateur
      3. 8.4.3 Le succès d'une inscription devrait créer un nouvel utilisateur
    5. 8.5 Conclusion
    6. 8.6 Exercices
  9. Chapitre 9 Connexion, déconnexion
    1. 9.1 Les sessions
      1. 9.1.1 Le contrôleur de session
      2. 9.1.2 Formulaire d'identification
    2. 9.2 Échec de l'identification
      1. 9.2.1 Examen de la soumission du formulaire
      2. 9.2.2 Échec de l'identification (test et code)
    3. 9.3 Succès de l'identification
      1. 9.3.1 L'action create finalisée
      2. 9.3.2 Se souvenir de moi
      3. 9.3.3 Utilisateur courant
    4. 9.4 Déconnexion
      1. 9.4.1 Détruire la session
      2. 9.4.2 Connexion à l'inscription
      3. 9.4.3 Changement des liens de la mise en page
      4. 9.4.4 Test d'intégration de l'identification/déconnexion
    5. 9.5 Conclusion
    6. 9.6 Exercices
  10. Chapitre 10 Actualiser, afficher et supprimer des utilisateurs
    1. 10.1 Actualiser l'utilisateur
      1. 10.1.1 Formulaire de modification
      2. 10.1.2 Permettre les modifications
    2. 10.2 Protéger les pages
      1. 10.2.1 Utilisateurs identifiés requis
      2. 10.2.2 Nécessité du bon utilisateur
      3. 10.2.3 Redirection conviviale
    3. 10.3 Afficher les utilisateurs
      1. 10.3.1 Liste des utilisateurs
      2. 10.3.2 Exemples d'utilisateurs
      3. 10.3.3 Pagination
        1. Test de la pagination
      4. 10.3.4 Restructuration des partiels
    4. 10.4 Supprimer des utilisateurs
      1. 10.4.1 Utilisateurs administrateurs
        1. Révision de attr_accessible
      2. 10.4.2 L'action destroy (« supprimer »)
    5. 10.5 Conclusion
    6. 10.6 Exercices
  11. Chapitre 11 Micro-messages d'utilisateurs
    1. 11.1 Le modèle Micropost (« Micro-message »)
      1. 11.1.1 Le modèle initial
        1. Attributs accessibles
      2. 11.1.2 Associations Utilisateur/micro-messages
      3. 11.1.3 Affinements du micro-message
        1. Portée par défaut
        2. Dépendances de la suppression
      4. 11.1.4 Validations du micro-message
    2. 11.2 Afficher les micro-messages
      1. 11.2.1 Etoffement de la page de l'utilisateur
      2. 11.2.2 Exemples de micro-messages
    3. 11.3 Manipuler les micro-messages
      1. 11.3.1 Contrôle de l'accès
      2. 11.3.2 Créer des micro-messages
      3. 11.3.3 Une proto-alimentation
      4. 11.3.4 Supprimer des micro-messages
      5. 11.3.5 Test de la nouvelle page d'accueil
    4. 11.4 Conclusion
    5. 11.5 Exercices
  12. Chapitre 12 Suivi des utilisateurs
    1. 12.1 Le modèle Relation (Relationship model)
      1. 12.1.1 Un problème du modèle de données (et sa solution)
      2. 12.1.2 Associations Utilisateur/Relations
      3. 12.1.3 Validations
      4. 12.1.4 Auteurs suivis
      5. 12.1.5 Les Lecteurs
    2. 12.2 Une interface web pour les auteurs et les lecteurs
      1. 12.2.1 Exemple de donnée de suivi
      2. 12.2.2 Statistiques et formulaire de suivi
      3. 12.2.3 Pages d'auteurs suivis et de lecteurs
      4. 12.2.4 Un bouton de suivi standard
      5. 12.2.5 Un bouton fonctionnant avec Ajax
    3. 12.3 L'état de l'alimentation
      1. 12.3.1 Motivation et stratégie
      2. 12.3.2 Une première implémentation de peuplement
      3. 12.3.3 Champs d'application, sous-sélections et lambda
      4. 12.3.4 Nouvel état de l'alimentation
    4. 12.4 Conclusion
      1. 12.4.1 Extensions de l'application exemple
        1. Réponses
        2. Notification
        3. Notifications aux lecteurs
        4. Rappel du mot de passe
        5. Confirmation d'inscription
        6. Alimentation RSS
        7. REST API
        8. Recherche
      2. 12.4.2 Guide vers d'autres ressources
    5. 12.5 Exercices

Avant-propos

Ma précédente compagnie (CD Baby) fut une des premières à basculer intégralement vers Ruby on Rails, et à rebasculer aussi intégralement vers PHP (googlez-moi si vous voulez prendre la mesure du drame). On m'a tellement recommandé ce livre Michael Hartl que je n'ai pu faire autrement que de le lire. C'est ainsi que le Tutoriel Ruby on Rails m'a fait revenir à nouveau à Rails.

Bien qu'ayant parcouru de nombreux livres sur Rails, c'est ce tutoriel-là qui m'a véritablement « mis en possession » de Rails. Tout est fait ici « à la manière de Rails » — une manière qui ne m'avait jamais semblé naturelle avant que je ne lise ce livre. C'est aussi le seul ouvrage sur Rails qui met en place, d'un bout à l'autre, un Développement Dirigé par les Tests (Test-Driven Development), une approche que je savais hautement recommandée par les experts mais dont je n'avais jamais compris aussi bien la pertinence que dans ce livre. Enfin, en incluant Git, GitHub et Heroku dans les exemples de la démonstration, l'auteur vous donne vraiment le goût de ce qu'est le développement d'un projet dans la vie réelle. Et le exemples de code ne sont pas en reste.

La narration linéaire adoptée par ce tutoriel est vraiment un bon format. Personnellement, j'ai étudié Le Tutoriel Rails en trois longues journées, en faisant tous les exemples et les exercices proposés à la fin de chaque chapitre. C'est en lisant ce livre du début à la fin, sans sauter la moindre partie, qu'on en tire tout le bénéfice.

Régalez-vous !

Derek Sivers (sivers.org)
Précédemment : Fondateur de CD Baby
Actuellement : Fondateur de Thoughts Ltd.

Remerciements

Ce Tutoriel Ruby on Rails doit beaucoup à mon livre précédent sur Rails, RailsSpace, et donc à mon co-auteur Aurelius Prochazka. J'aimerais remercier Aure à la fois pour le travail qu'il a accompli sur ce précédent livre et pour son soutien pour le présent ouvrage. J'aimerais aussi remercier Debra Williams Cauley, mon éditeur pour les deux ouvrages ; aussi longtemps qu'elle jouera avec moi au baseball, je continuerai d'écrire des livres pour elle.

J'aimerais remercier une longue liste de Rubyistes qui m'ont parlé et inspiré au cours des années : David Heinemeier Hansson, Yehuda Katz, Carl Lerche, Jeremy Kemper, Xavier Noria, Ryan Bates, Geoffrey Grosenbach, Peter Cooper, Matt Aimonetti, Gregg Pollack, Wayne E. Seguin, Amy Hoy, Dave Chelimsky, Pat Maddox, Tom Preston-Werner, Chris Wanstrath, Chad Fowler, Josh Susser, Obie Fernandez, Ian McFarland, Steven Bristol, Giles Bowkett, Evan Dorn, Long Nguyen, James Lindenbaum, Adam Wiggins, Tikhon Bernstam, Ron Evans, Wyatt Greene, Miles Forrest, les gens bien de Pivotal Labs, le gang Heroku, les mecs de thoughtbot et l'équipe de GitHub. Enfin, tellement, tellement, tellement de lecteurs — beaucoup trop pour les citer tous — qui ont contribué par leur rapport de bogues et leurs suggestions durant l'écriture de ce livre, et je tiens à saluer leur aide sans laquelle ce livre ne serait pas ce qu'il est.

À propos de l'auteur

Michael Hartl est programmeur, éducateur et entrepreneur. Il est le co-auteur de RailsSpace, un tutoriel Rails publié en 2007, et a été co-fondateur et développeur en chef de Insoshi, une plateforme de réseau social populaire en Ruby on Rails. Précédement, il a enseigné la théorie et la physique informatique au California Institute of Technology (Caltech), où il a reçu le Lifetime Achievement Award for Excellence en enseignement. Michael est diplômé du Harvard College, a un Ph.D. en physique (un doctorat. NdT) de Caltech, et il est ancien élève du programme des entrepreneurs Y Combinator.

Copyright et license

Le Tutoriel Ruby on Rails : apprendre Rails par l'exemple. Copyright © 2010 par Michael Hartl. Tout le code source du Tutoriel Ruby on Rails est disponible sous la license MIT License et la licence Beerware License.

   Copyright (c) 2010 Michael Hartl

   Permission est accordée, à titre gratuit, à toute personne obtenant
   une copie de ce logiciel et la documentation associée, pour faire des 
   modification dans le logiciel sans restriction et sans limitation des
   droits d’utiliser, copier, modifier, fusionner, publier, distribuer,
   concéder sous licence, et / ou de vendre les copies du Logiciel, et à
   autoriser les personnes auxquelles le Logiciel est meublé de le faire, 
   sous réserve des conditions suivantes:

   L’avis de copyright ci-dessus et cette autorisation doit être inclus
   dans toutes les copies ou parties substantielles du Logiciel.

   LE LOGICIEL EST FOURNI «TEL QUEL», SANS GARANTIE D’AUCUNE SORTE, 
   EXPLICITE OU IMPLICITE, Y COMPRIS, MAIS SANS S’Y LIMITER, LES 
   GARANTIES DE QUALITÉ MARCHANDE, ADAPTATION À UN USAGE PARTICULIER ET
   D’ABSENCE DE CONTREFAÇON. EN AUCUN CAS LES AUTEURS OU TITULAIRES DU
   ETRE TENU RESPONSABLE DE TOUT DOMMAGE, RÉCLAMATION OU AUTRES
   RESPONSABILITÉ, SOIT DANS UNE ACTION DE CONTRAT, UN TORT OU AUTRE,
   PROVENANT DE, DE OU EN RELATION AVEC LE LOGICIEL OU L’UTILISATION OU
   DE TRANSACTIONS AUTRES LE LOGICIEL.
	
/*
 * ------------------------------------------------------------
 * "LA LICENCE BEERWARE" (Révision 42) :
 * Michael Hartl a écrit ce code. Aussi longtemps que vous
 * conservez cette note, vous pouvez faire ce que vous voulez
 * de ce travail. Si nous nous rencontrons un jour, et que vous
 * pensez que ce travail en vaut la peine, vous pourrez me
 * payer une bière en retour.
 * ------------------------------------------------------------
 */

chapitre 1 De zéro au déploiement

Bienvenue dans Le Tutoriel Ruby on Rails : Apprendre Rails par l'exemple. Le but de ce livre est d'être la meilleure réponse à la question : « Si je veux apprendre le développement web avec Ruby on Rails, par où dois-je commencer ? » Quand vous aurez achevé Le Turoriel Ruby on Rails, vous aurez toutes les connaissances nécessaires pour développer et déployer votre propre application web. Vous serez également en mesure de tirer profit de livre plus avancés, des blogs et des screencasts qui peuplent le écosystème Rails, prospère. Enfin, puisque le Tutoriel Ruby on Rails utilise Rails 3.0, la connaissance que vous acquiererez sera pleinement d'actualité avec la dernière et meilleure version de Rails.1

Le Tutoriel Ruby on Rails suit essentiellement la même approche que mon livre précédent,2 enseignant le développement web avec Rails en construisant un exemple d'application conséquente, depuis le tout départ. Comme Derek Sivers le souligne dans l'avant-propos, ce livre est structuré en narration linéaire, destinée en conséquence à être lue du début à la fin. Si vous avez l'habitude de survoler les livres techniques, suivre cette approche linéaire peut vous demander quelques ajustements, mais je ne saurais trop vous recommander d'essayer. Vous pouvez penser au Tutoriel Ruby on Rails comme un jeu vidéo dont vous êtes le héros, et où vous augmentez votre niveau de développeur Rails à chaque chapitre (les exercices sont comme des mini-boss).

Dans le premier chapitre, nous commencerons avec Ruby on Rails en installant tous les softwares nécessaires et en préparant votre environnement de développement (section 1.2). Nous créerons alors notre première application Rails, appelée (de façon assez pertinente ma foi) first_app (première_application). Le Tutoriel Rails met l'accent sur les bonnes pratiques de développement, aussi, immédiatement après avoir créé notre tout nouveau projet Rails nous le déposerons sous un contrôle de version avec Git (section 1.3). Et, croyez-le ou non, dans ce chapitre nous déploierons même notre première application en mode « production » (Section 1.4).

Au chapitre 2, nous créerons un second projet, dont le but sera d'illustrer les fonctions élémentaires d'une application Rails. De façon très rapide, nous construirons cette application démo (qui s'appellera demo_app) en utilisant le système d'échaffaudage (« scaffolding ») (Box 1.1) pour générer automatiquement le code ; comme ce code est aussi laid que complexe, le chapitre 2 se concentrera plutôt sur l'interaction avec l'application démo par le biais des URLs3 en utilisant un navigateur internet.

Au chapitre 3, nous créerons une application exemple (que nous appellerons sample_app), en écrivant cette fois tout le code à partir de (presque) rien. Nous développerons cette application exemple en utilisant le Test Dirigé par le Développement (« test-driven development », TDD), amorcé au chapitre 3 en créant des pages statiques puis en ajoutant un peu de contenu dynamique. Nous ferons un rapide détour au chapitre 4 pour en apprendre un peu plus sur le langage Ruby sous-jacent à Rails. Puis, du chapitre 5 au chapitre 10, nous complèterons les fondations de l'application exemple en fabricant un layout (une mise en page) pour le site, un modèle de données utilisateur (« user data model ») et un système complet et fonctionnel d'enregistrement et d'authentification. Enfin, aux chapitre 11 et chapitre 12 nous incorporerons des outils de micro-blogging (un système de mini-messages) et de réseau social pour faire un exemple de site tout à fait fonctionnel.

L'application exemple finale aura plus d'une ressemblance avec une certaine application sociale de micro-blogging — un site qui, est-ce un hasard, est également écrit en Rails. Bien que nos efforts se concentrent nécessairement sur cette application exemple spécifique, l'accent dans ce Tutoriel Rails sera mis sur des principes généraux, donc vous acquièrerez des notions fondamentales et solides qui vous permettrons de développer vos propres applications web, quels que soient leur genres.

1.1 Introduction

Depuis ses début en 2004, Ruby on Rails est rapidement devenu un des frameworks les plus populaires et les plus puissants pour construire des applications web dynamiques. Les utilisations de Rails couvrent un large éventail d'applications, depuis la start-up bagarreuse jusqu'aux énormes compagnies : Posterous, UserVoice, 37signals, Shopify, Scribd, Twitter, Hulu, the Yellow Pages (les Pages Jaunes) — la liste des sites utilisant Rails s'allongent de jour en jour. Il y a aussi de nombreux producteurs de développements web qui se spécialisent en Rails, tels que ENTP, thoughtbot, Pivotal Labs ou Hashrocket, sans compter les innombrables consultants indépendants, entraineurs et entrepreneurs.

Qu'est-ce qui rend Rails si fantastique ? Tout d'abord, Ruby on Rails est 100% en « open-source », accessible sous la licence MIT License, e qui signifie qu'il ne coûte rien de le télécharger et de l'utiliser. Rails doit également le plus gros de son succès à son design compact et élégant ; en exploitant la maléabilité de la sous-couche en langage Ruby, Rails crée de façon effective un langage de domaine spécifique pour écrire des applications web. Il en résulte que de nombreuse tâches courantes de programmation web — telles que générer du code HTML, faire des modèles de données ou rediriger les URLs — deviennent faciles avec Rails, et le code de l'application produit est concis et lisible.

Rails s'adapte également avec rapidité aux développements les plus récents de la technologie internet et à la conception par framework. Rails a par exemple été l'un des premiers frameworks à digérer et implémenter en totalité l'architecture de style REST pour structurer les applications web (ce que nous apprendrons à faire au cours de ce tutoriel). Et quand d'autres framewords développent avec succès de nouvelles technologies, le créateur de Rails, David Heinemeier Hansson ainsi que le cœur de l'équipe Rails n'hésite jamais à incorporer à Rails leurs nouvelles idées. Peut-être l'exemple le plus parlant est la fusion de Rails et de Merb, un framework concurrent, de telle sorte que Rails bénéficie maintenant de la conception modulaire de Merb, API stable et aux performances améliorées. Quiconque a assisté à la conférence donnée par le développeur de Merb et le noyau dur de l'équipe Yehuda Katz n'a pu faire autrement que de noter à quel point ce fut une extrêmement bonne idée de monter l'équipe de Merb à bord.

Enfin, Rails bénéficie d'une communauté exceptionnellement enthousiaste et diverse. Les résultats en sont des centaines de contributeurs open-source, des conférences largement suivies, un nombre considérable de plugins et des gems (solutions clé-en-main pour des problèmes spécifiques comme la pagination ou le téléchargement d'images), une riche variété de blogs d'information, et une corne d'abandonce débordant de forums de discussions et de canaux de discussion IRC. Le grand nombre de développeurs Rails rend également plus facile la résolution des erreurs inévitables de toute l'application : l'algorithme « Googlelisez votre message d'erreur » renvoie pratiquement toujours vers le message pertinent d'un blog ou un sujet de discussion dans un forum.

1.1.1 Commentaires pour la grande variété de lecteurs

Le Tutoriel Rails contient des « tutoriels intégrés » non seulement pour Rails, mais aussi pour le langage sous-jacent Ruby, aussi bien que pour HTML, CSS, un peu de JavaScript, et même un peu de SQL. Cela signifie que, quelles que soient vos connaissances en matière de développement web, en finissant ce tutoriel vous serez en mesure d'utiliser des ressources Rails plus avancées, et prêts de la même manière à approfondir de façon plus systématique tous les autres sujets abordés.

Rails titre une grande partie de son pouvoir de la « magic » — il en va ainsi des capacités du framework (telles que déduire automatiquement les attributs d'un objet à partir du nom des colonnes de la base de données) qui accomplissent des miracles mais dont les mécanismes peuvent rester plutôt obscures. Le Tutorial Ruby on Rails n'est pas destiné à expliquer cette magie — principalement parce que la plupart des développeurs d'applications Rails n'ont jamais besoin de savoir ce qui se passe en coulisses (après tout, le langage Ruby lui-même est écrit principalement en langage de programmation C, mais vous n'avez pas besoin de creuser dans le code source en C pour utiliser Ruby). Si vous êtes le genre de personne qui aime bien tirer les choses de derrière le rideau, je vous recommande la lecture de The Rails 3 Way par Obie Fernandez qui accompagnera avec profit ce Tutoriel Ruby on Rails.

Bien que ce livre ne nécessite pas de requis spéciaux, vous devez bien entendu posséder au moins quelque expérience des ordinateurs. Si vous n'avez même jamais utilisé d'éditeur de texte, ce ne sera pas facile pour vous d'avancer, mais avec un peu de détermination vous devriez pouvoir passer à travers. Si, d'un autre côté, votre fichier .emacs est tellement complexe qu'il pourrait faire pleurer un adulte, il vous restera toujours ici quelque défi à relever. Le Tutoriel Rails est destiné à enseigner le développement Rails quels que soient ses acquis propres, mais l'expérience que vous ferez de cette lectutre dépendra de vos aptitudes particulières.

À tous les lecteurs : une question classique en étudiant Rails est de savoir s'il faut étudier Ruby au préalable. La réponse dépend de la façon dont vous apprenez. Si vous avez une prédilection pour apprendre tout depuis la base, de façon systématique, alors apprendre le langage Ruby peut vous être utile ; plusieurs livres sont recommandés dans cette section pour vous faire débuter. D'un autre côté, de nombreux développeurs Rails débutants sont excités à l'idée de créer des applications web, et préfèreront ne pas se coltiner un livre de 500 pages en pur Ruby avant d'écrire la moindre page sur une simple page web. Plus encore, le sous-ensemble de Ruby nécessaire aux développeurs Rails est différent de ce que vous pourriez trouver dans une introduction sur du pur Ruby, tandis que le Tutoriel Rails se concentre exclusivement sur ce sous-ensemble. Si votre intérêt premier est de construire des applications Rails, je vous recommande de commencer par ce Tutoriel Rails et de lire des livres de pur Ruby ensuite. Ce n'est pas une proposition « tout ou rien », pour autant : si vous commencez à lire ce Tutoriel Rails et sentez votre manque de connaissance du Ruby vous ralentir, soyez libre de basculer vers un livre sur le langage Ruby avant de revenir au tutoriel lorsque vous vous sentirez plus à l'aise. Vous pouvez aussi vous contenter d'un goût de ce qu'est Ruby en suivant un court tutoriel en ligne, tels que ceux qu'on peut trouver sur les sites http://www.ruby-lang.org/ ou http://rubylearning.com/.

Une autre question classique concerne l'utilisation des tests dès le départ. Comme cela est indiqué dans l'introduction, ce Tutoriel Rails fait appel au « Test Dirigé par le Développement » (test-driven development, appelé aussi test-first development), qui selon moi est la meilleure façon de développer des applications Rails, mais le fait est que cette approche introduit une quantité substantielle de difficulté et de complexité. Si vous sentez que vous vous enlisez à cause des tests, sentez-vous libre de les sauter dans une première lecture.4 Vraiment, certains lecteurs se sentent dans un premier temps écrasés par l'inclusion de nombreux concepts et de pratiques nouvelles — telles que les tests, les contrôles de versions, le déploiement. Aussi, si vous vous rendez compte que vous dépensez une énergie excessive sur toutes ces étapes, n'hésitez pas à les passer. Bien que j'ai inclus seulement le matériel que je considère essentiel au développement d'un niveau professionnel d'une application Rails, seul le cœur du code de l'application est strictement nécessaire dans une première lecture.

Aux programmeurs non expérimentés (non-concepteurs) : ce Tutoriel Rails n'exige aucun autre background qu'une connaissance générale de l'ordinateur, donc si vous avez une expérience limitée de la programmation ce livre est une bonne façon de commencer. Gardez à l'esprit que c'est seulement la première étape d'un long voyage ; le développement web possède de nombreux aspects différents, parmi lesquels le HTML/CSS, JavaScript, les bases de données (et SQL), les contrôles de version et le déploiement. Ce livre contient de courtes introductions à ces sujets, mais il y a bien plus encore à connaitre.

Aux programmeurs non expérimentés (concepteurs) : vos aptitudes en matière de conception web vous donnent une longueur d'avance, puisque vous connaissez certainement déjà le HTML et les CSS. Après avoir fini ce livre, vous serez dans une excellente position pour travailler sur des projets Rails existants et pourrez probablement en amorcer un de votre propre chef. Vous pouvez trouver difficile tout ce qui concerne la programmation, mais le langage Ruby est exceptionnellement accessible aux débutants, tout spécialement ceux qui possèdent une fibre artistique.

Après avoir achevé la lecture du Tutoriel Ruby on Rails, je recommande aux nouveaux programmeurs la lecture de Beginning Ruby de Peter Cooper, qui partage la même philosophie pédagogique que ce Tutoriel Rails. Je recommande aussi The Ruby Way de Hal Fulton. Enfin, pour acquérir une compréhension plus profonde de Rails je recommande The Rails 3 Way de Obie Fernandez.

Les applications Web, même les relativement simples, sont de par nature assez complexes. Si vous êtes tout à fait nouveau dans la programmation web et trouvez trop complexe la lecture de ce Tutoriel Rails, c'est peut-être que vous n'êtes pas tout à fait prêts encore à développer des applications web. Dans ce cas, je vous suggère d'apprendre les bases du HTML et des CSS et de recommencer ensuite seulement la lecture de ce tutoriel (malheureusement, je n'ai pas de recommandations particulières ici, mais Head First HTML semble prometteur, et un des lecteurs recommande CSS: The Missing Manual de David Sawyer McFarland). Vous pouvez aussi lire avec profit les premiers chapitres de Beginning Ruby, qui débute avec l'exemple d'une application plus petite qu'une application web au sens fort du terme.

Aux programmeurs expérimentés découvrant le développement web : votre expérience signifie que vous comprenez probablement déjà les concepts de classes, de méthodes, de structures de données, etc., ce qui constitue un sérieux avantage. Soyez tout de même avertis, dans le cas où votre background est le C/C++ ou le Java, que vous pourriez trouver que le langage Ruby ressemble un peu à un canard boiteux, et sa prise en main pourrait vous prendre du temps ; familiarisez-vous juste avec lui, et tout devrait aller pour le mieux (Ruby vous autorise même à mettre des points-virgule à la fin des lignes s'ils vous manquent trop !). Ce Tutoriel Rails couvre toutes les idées spécifiques au développement web dont vous avez besoin, donc ne vous inquiétez pas si vous ne distinguez pas pour le moment une requête PUT d'une requête POST.

Aux développeurs web expérimentés découvrant Rails : vous avez une sérieuse longueur d'avance, tout spécialement si vous avez utilisé un langage dynamique tel que le PHP ou (encore mieux) le langage Python. Les bases de ce que nous couvrons vous seront pour le moins familières, mais le développement par le test (Développement Dirigé par le Test, ou TDD) sera peut-être nouveau pour vous, comme peut l'être aussi l'architecture REST préconisé par Rails. Ruby possède également sa propre idiosyncrasie, peut-être sera-t-elle aussi nouvelle pour vous.

Aux programmeurs Ruby expérimentés : l'ensemble des programmeurs Ruby ne connaissant pas Rails est très restreint de nos jours, mais si vous faites partie de ce groupe d'élite, vous pouvez survoler ce livre et vous diriger ensuite sur le livre The Rails 3 Way de Obie Fernandez.

Aux programmeurs Rails inexpérimentés : vous avez peut-être lu d'autres tutoriels et créé quelques petites applications Rails. En me basant sur le retour des lecteurs, je suis confiant sur le fait que vous pourrez tirer beaucoup de ce livre. Parmi d'autres choses, les techniques employées ici sont peut-être plus d'actualité que celles que vous avez abordés quand vous avez appris Rails.

Aux programmeurs Rails expérimentés : ce livre ne vous sera pas utile, et pourtant, de nombreux développeurs Rails expérimentés m'ont exprimé leur surprise quant à la quantité de choses qu'ils avaient tirés de ce livre, et vous pourriez être ravis d'aborder Rails sous un autre jour, dans une autre perspective.

Après avoir terminé ce Tutoriel Ruby on Rails, je recommande aux programmeurs (non Ruby) expérimentés la lecture de The Well-Grounded Rubyist de David A. Black, qui est une excellente et profonde discussion sur Ruby depuis la base, ou The Ruby Way de Hal Fulton, qui est tout aussi avancé mais adopte une approche plus actuelle. Passez ensuite à The Rails 3 Way pour approfondir encore votre expertise de Rails.

À la fin de ce processus, quel que soit d'où vous partiez, vous serez en mesure d'appréhender les ressources Rails plus avancées. Voilà celle que je recommande particulièrement :

  • Railscasts : d'excellents screencats gratuits sur Rails ;
  • PeepCode, Pragmatic.tv, EnvyCasts : d'excellent screencasters payants ;
  • Rails Guides : bonnes références sur Rails, d'actualité et actualisées. Ce Tutoriel Rails fait fréquemment référence au Rails Guides pour un traitement plus en profondeur de certains sujets ;
  • Rails blogs : trop de choses à énumérer, et quelles choses !

1.1.2 ¡ Mise à l'échelle » (Scaling) de Rails

Avant de poursuivre avec la suite de l'introduction, j'aimerais m'arrêter un moment sur un problème qui collait au framework Rails à ses tout débuts : sa supposée inaptitude à se « mettre à l'échelle » — pour, par exemple, absorber un trafic important. Une partie de cette question repose sur une idée tout à fait fausse ; vous mettez à l'échelle un site, pas un framework, et Rails, aussi intelligent soit-il, n'est qu'un framework. Donc la vraie question aurait dû être « Est-ce qu'un site construit en Rails peut se mettre à l'échelle ? ». Dans ce cas, la réponse est résolument « oui » : quelques uns des sites les plus lourds en trafic dans le monde utilisent Rails. En fait, rendre la mise à l'échelle possible va bien au-delà du champ d'application de Rails, mais soyez assurés que si votre application connait un trafic similaire à celui de Hulu ou des « Pages jaunes », Rails ne sera pas un handicap pour vous étendre au travers du monde.

1.1.3 Conventions utilisées dans ce livre

Les conventions de ce livre s'expliquent la plupart du temps d'elles-mêmes ; dans cette section, je mentionne celles qui ne le pourraient pas.

Les éditions HTML et PDF de ce livre sont riches en liens, vers des sections internes (telles que Section 1.2) aussi bien que des sites externes (tels que la page principale Télécharger Ruby on Rails).5

De nombreux exemples de ce livre utilisent la « ligne de commande ». Pour la simplicité, tous les exemples en ligne de commande utilisent l'invite classique Unix (un dollar), comme suit :

$ echo "bonjour le monde"
bonjour le monde

Les utilisateurs Windows doivent savoir que leur système utilisera l'invite analogue « > » :

C:\Sites>echo Salut le monde
Salut le monde

Sur les systèmes d'exploitation Unix, certaines commandes devront être exécutées avec sudo, qui signifie « substitute user do » (L'utilisateur de substition fait…). Par défaut, une commande exécutée avec sudo est jouée comme par un utilisateur-administrateur, qui a accès à des fichiers et des dossiers que les utilisateurs normaux ne peuvent pas toucher. Pour indiquer que l'utilisation de sudo dépendra de votre système, elle se présentera entre crochets quand elle peut être (ou ne pas être) nécessaire sur votre propre système, comme dans l'exemple de la section 1.2.2:

$ [sudo] ruby setup.rb

La plupart des systèmes d'exploitation Unix/Linux/Os X requièrent la commande sudo par défaut, sauf si vous utilisez le Ruby Version Manager comme cela est suggéré dans la section 1.2.2.3. Notez que vous ne devez pas utiliser les crochets ; vous devez utiliser soit…

$ sudo ruby setup.rb

soit…

$ ruby setup.rb

… en fonction de votre système d'exploitation.

Rails est fourni avec un grand nombre de commandes qui peuvent être jouées en ligne de commande. Par exemple, dans la section 1.2.5 nous lancerons un serveur web local en mode développement comme suit :

$ rails server

Comme pour l'invite de la commande en ligne, ce Tutoriel Rails utilise la convention Unix pour les séparateurs de dossiers (c'est-à-dire une balance /). Ma propre Application exemple développée dans ce tutoriel, par exemple, se trouve dans :

/Users/mhartl/rails_projects/sample_app

Sur Windows, l'adresse du dossier analogue devrait être :

C:\Sites\sample_app

Le dossier racine pour toute application donnée est connue comme la racine Rails (Rails root), et désormais tous les chemins d'accès seront relatifs à ce dossier (notez bien que la « racine Rails » n'est pas le dossier racine du framework Rails lui-même). Par exemple, le dossier config de mon application exemple est :

/Users/mhartl/rails_projects/sample_app/config

La racine Rails est ici ce qui se trouve avant config, c'est-à-dire :

/Users/mhartl/rails_projects/sample_app

Par souci de brièveté, quand nous ferons référence au fichier :

/Users/mhartl/rails_projects/sample_app/config/routes.rb

… nous omettrons la racine Rails et écrirons simplement config/routes.rb.

Pour finir, ce Tutoriel Rails montre souvent les sorties (les résultats) de programmes variés (commandes shell, état de contrôle de version, programmes Ruby, etc.). À cause des innombrables petites différences entre les différents systèmes d'exploitation, la sortie que vous obtiendrez ne coïncidera pas toujours avec ce qui sera montré dans le texte, mais il n'y a aucune raison de s'en pré-occuper. De surcroît, certaines commandes pourrons produire des erreurs en fonction de votre système ; plutôt que d'essayer la tâche Sisyphéenne de documenter tous ces types d'erreurs dans ce tutoriel, je délèguerai cette tâche à l'algorithme « Google le message d'erreur », qui est, parmi d'autres choses, une bonne pratique dans le développement grandeur nature de logiciel.

1.2 Debout et au boulot

Le temps est venu d'aborder l'environnement de développement Ruby on Rails et notre première application. Il y a quelques casse-têtes ici, spécialement si vous n'avez pas une expérience étendue de la programmation, donc ne vous découragez pas si cela vous demande un moment avant de pouvoir réellement démarrer. Ça ne vous concerne pas en particulier ; tout développeur doit en passer par là (et souvent plus d'une fois), mais soyez assuré que les efforts seront richement récompensés.

1.2.1 Les environnements de développement

En prenant en compte la grande variété des personnalisations possibles, il existe au moins autant d'environnements de développement que de programmeurs Rails, mais il se dégage tout de même deux méthodes principales : les environnements à base d'éditeur de texte/ligne de commande, et les environnements de développement intégrés (IDEs). Considérons d'abord le second.

IDEs

Les IDEs Rails ne manquent pas, incluant RadRails, RubyMine, et 3rd Rail. Tous sont « cross-platform » (utilisables sur n'importe quel système. NdT), et j'ai entendu dire du bien de quelques uns d'entre eux. Je vous encourage à les essayer s'ils fonctionnent pour vous, mais j'ai une confession à vous faire : je n'ai jamais trouvé un IDE qui me permette de satisfaire tous mes besoins en matière de développement Rails — et pour certains projets je n'ai pas même été capable de les faire fonctionner.

Éditeurs de texte et ligne de commande

Que devons-nous utiliser alors pour remplacer ces IDE tout-en-un ? Je parierai que la majorité des développeurs Rails ont opté pour la même solution que moi : utiliser un éditeur de texte pour éditer le texte, et une ligne de commande pour exécuter des commandes (Illustration 1.1). La combinaison que vous utiliserez dépendra de vos goûts et de votre plate-forme :

  • Macintosh OS X : comme beaucoup de développeurs Rails, j'ai une préférence pour TextMate. D'autres options incluent Emacs et MacVim (chargé par la commande mvim), l'excellente version Macintosh de Vim.6 J'utilise iTerm comme terminal de ligne de commande ; d'autres affectionnent l'application native « Terminal ».
  • Linux : vos options d'édition sont à la base les mêmes que pour les OS X, à l'exception de TextMate. Je recommande « graphical Vim » (gVim), gedit (avec le plugin GMate), ou Kate. En terme de ligne de commande, vous devez déjà être totalement équipés : toute distribution Linux est fournie avec une application terminal de ligne de commande (et même souvent plusieurs).
  • Windows : Certains éditeurs prometteurs sur Windows sont Vim, le E Text Editor, Komodo Edit, et Sublime Text. Pour les lignes de commande, je recommande d'utiliser l'invite fournie avec Rails Installer (Section 1.2.2.1).

Si vous avez une connaissance de Vim, assurez-vous de puiser dans la florissante communauté des Vim-using Rails hackers. Attardez-vous spécialement sur les améliorations de rails.vim et le projet à tiroir NERD tree.

editor_shell
Illustration 1.1: Un environnement de développement éditeur de texte/ligne de commande (TextMate/iTerm). (taille normale)

Navigateurs internet

Bien qu'on puisse choisir dans une large panoplie de navigateurs, la majorité des développeurs Rails font appel à Firefox, Safari ou Chrome pour développer leurs applications. Les copies d'écran dans ce tutoriel Rails proviennent en général de Firefox. Si vous utilisez Firefox, je vous suggère d'utiliser l'add-on Firebug, qui vous permet de faire tout un tas de choses magiques, comment inspecter dynamiquement (ou même modifier) la structure HTML et les règles CSS de n'importe quelle page. Pour ceux qui n'utilisent pas Firefox, Firebug Lite fonctionne avec la plupart des autres navigateurs, et Safari comme Chrome ont de façon native un outil d'inspection des éléments accessible en cliquant-droit sur n'importe quelle partie de la page. Quel que soit le navigateur utilisé, l'expérience démontre que le temps passé à apprendre à se servir d'un outil d'inspection est rapidement et richement récompensé.

Une note à propos des outils

En vous appliquant à rendre votre environnement de développement opérationnel, vous constaterez peut-être que vous dépensez beaucoup de temps à faire en sorte que les choses, simplement, fonctionnent. Le processus d'apprentissage des éditeurs et des IDEs est particulièrement long ; vous pourrez passer des semaines sur des tutoriels TextMate ou Vim. Si ce jeu est tout nouveau pour vous, je tiens à vous assurer que passer du temps à apprendre à connaître ses outils est normal. Tout le monde y passe. Parfois cela est frustrant, et il est facile de perdre patience quand vous avez en tête le projet d'une magnifique application web et que vous voulez juste apprendre Rails tout de suite, mais que vous avez à « perdre » une semaine sur un ancien et bizarre éditeur de texte Unix pour pouvoir ne faire que commencer. Mais un artisan se doit de connaître ses outils ; au bout du compte, soyez certain que le jeu en vaut la chandelle.

1.2.2 Ruby, RubyGems, Rails, et Git

Maintenant, il est temps d'installer Ruby et Rails. La source canonique et actualisée est la page de téléchargement de Ruby on Rails. Vous pouvez y aller dès à présent ; les parties de ce livre peuvent être lues avec profit sans être connecté à par celle-ci. Car je vais injecter certains commentaires personnels sur cette étape.

Installeur Rails (Windows)

L'installation de Rails sur Windows était auparavant une calamité, mais grâce aux efforts de bonnes personnes à Engine Yard — spécialement Dr. Nic Williams et Wayne E. Seguin — l'installation de Rails et des logiciels afférents sur Windows est maintenant incroyablement facilitée. Si vous êtes sous Windows, allez au Rails Installer (http://railsinstaller.org/) et téléchargez l'exécutable Rails Installer. Double-cliquez l'exécutable et suivez les instructions d'installation pour installer Git (vous pourrez donc passer la section 1.2.2.2), Ruby (passer la section 1.2.2.3), RubyGems (passez la section 1.2.2.4), et Rails lui-même (passez la section 1.2.2.5). Une fois l'installation terminée, vous pouvez directement passer à la création de la première application à la section 1.2.3.

Installation de Git

Le plus gros de l'écosystème Rails repose d'une manière ou d'une autre sur un système de contrôle de version appelé Git (couvert plus en détail dans la section 1.3). Puisque son usage est omniprésent, vous devriez installer Git même à ce point de départ ; je vous suggère de suivre les instructions d'installation propres à votre plate-forme que vous trouverez à cette adresse : Installing Git section of Pro Git.

Installer Ruby

L'étape suivante consiste à installer Ruby. Il est possible que votre système le possède déjà ; essayez d'exécuter la commande…

$ ruby -v
ruby 1.9.2

… pour voir le numéro de version de votre Ruby. Rails 3 requiert Ruby 1.8.7 ou plus récent et fonctionne mieux avec Ruby 1.9.2. Ce tutoriel pré-suppose que vous utilisez la dernière version de développent de Ruby 1.9.2, connu sous le nom Ruby 1.9.2-head, mais Ruby 1.8.7 devrait fonctionner tout aussi bien.

La branche Ruby 1.9 est en développement lourd, donc malheureusement installer la dernière version de Ruby peut relever du challenge. Vous devrez compter alors sur les instructions les plus actualisées qu'on trouve en ligne. Ce qui suit est une série d'étapes que j'ai exécutées pour le fonctionnement sur mon système (Macintosh OS X), mais vous aurez peut-être à chercher à droite et à gauche pour qu'elles fonctionnent sur le vôtre.

Dans le cadre de l'installation de Ruby, si vous utilisez OS X ou Linux je recommande fortement l'installation de Ruby en utilisant le Ruby Version Manager (RVM), qui vous permet d'installer et gérer plusieurs versions de Ruby sur la même machine (le projet Pik accomplit la même chose sous Windows). Cela est particulièrement important si vous voulez faire tourner Rails 3 et Rails 2.3 sur le même ordinateur. Si vous voulez emprunter cette voie, je vous suggère l'utilisation de RVM pour installer deux combinaisons Ruby/Rails : Ruby 1.8.7/Rails 2.3.10 et Ruby 1.9.2/Rails 3.0.5. Si vous rencontrez le moindre problème avec RVM, vous pouvez souvent trouver son créateur, Wayne E. Seguin, sur le canal IRC de RVM (#rvm on freenode.net).7

Après l'installation de RVM, vous pouvez installer Ruby de cette manière :8

$ rvm get head
$ rvm reload
$ rvm install 1.8.7
$ rvm install 1.9.2
<attendez un moment>

Les deux premières commandes actualisent et rechargent RVM lui-même, ce qui constitue une bonne pratique puisque RVM est fréquemment actualisé. Les deux commandes finales procèdent à l'installation de Ruby ; en fonction de votre système, cela peut prendre plus ou moins de temps pour télécharger et compiler les sources, donc ne vous inquiétez pas si ça vous semble une éternité (soyez également informé que beaucoup de peites choses peuvent aller de travers. Par exemple, sur mon système la dernière version de Ruby 1.8.7 ne voudra pas se compiler ; après bien des recherches et des lamentations, j'ai découvert que j'avais besoin du « patchlevel » numéro 174 :

$ rvm install 1.8.7-p174

Quand de telles choses surviennent, c'est toujours très frustrant (Oh que oui ! NdT), mais au moins, vous saurez que ça n'arrive pas qu'à vous.

Typiquement, les programmes Ruby sont distribués via des gems, qui sont des packages autonomes de code Ruby. Puisque des gems avec des numéros de versions différents peuvent parfois entrer en conflit, il est souvent pratique de créer des gemsets séparés, qui sont des faisceaux (bundles) autonomes de gems. En particulier, Rails est distribué comme un gem, et il y a des conflits entre Rails 2 et Rails 3, donc si vous voulez lancer plusieurs versions de Rails sur le même système vous aurez besoin de créer une gemset différent pour chacune d'elle :

$ rvm --create 1.8.7-p174@rails2tutorial
$ rvm --create use 1.9.2@rails3tutorial

La première commande crée le gemset rails2tutorial associé à Ruby 1.8.7-p174, tandis que la seconde commande crée le gemset rails3tutorial associé à Ruby 1.9.2 et l'utilise (via la commande use) en même temps. RVM supporte une large variété de commandes pour manipuler les gemsets ; voyez la documentation à l'adresse http://rvm.beginrescueend.com/gemsets/.

Dans ce tutoriel, nous voulons que notre système utilise Ruby 1.9.2 et Rails 3.0 par défaut, ce que nous pouvons définir comme suit :

$ rvm --default use 1.9.2@rails3tutorial

Cela définit simultanéement la version de Ruby par défaut à la version 1.9.2 et le gemset par défaut à rails3tutorial.

En passant, si vous vous retrouvez coincé avec RVM, exécuter des commandes telles que les suivantes devraient vous permettre de retrouver toutes vos facultés :

$ rvm --help
$ rvm gemset --help

Installation de RubyGems

RubyGems est un gestionnaire de packages pour les projets Ruby, et il y a légion d'excellentes librairies (Rails inclus) accessibles comme packages Ruby, ou comme gems. L'installation de RubyGems devrait être facile une fois Ruby installé. En fait, si vous avez installé RVM, vous avez déjà RubyGems, puisque RVM l'inclut automatiquement :

$ which gem
/Users/mhartl/.rvm/rubies/ruby-head/bin/gem

Si vous ne l'avez pas encore, vous devez télécharger RubyGems, l'extraire, puis aller dans le dossier rubygems pour lancer le programme d'installation :

$ [sudo] ruby setup.rb

Si RubyGems est déjà installé, vous pouvez vouloir actualiser votre système avec la dernière version :

$ [sudo] gem update --system

Pour finir, si vous utilisez Ubuntu Linux, vous devriez jeter un coup d'œil à the Ubuntu/Rails 3.0 blog post by Toran Billups pour des instructions complètes sur l'installation.

Installer Rails

Une fois RubyGems installé, l'installation de Rails 3.0 devrait être un jeu d'enfant :

$ [sudo] gem install rails --version 3.0.5

Pour vérifier si tout a fonctionné, exécutez la commande suivante :

$ rails -v
Rails 3.0.5

1.2.3 La première application

Grosso-modo, toutes les applications Rails commencent de la même manière, par une commande rails. Ce programme pratique crée un squelette de l'application Rails dans le dossier de votre choix. Pour commencer, faite un dossier pour votre projet Rails et exécutez la commande rails pour créer la première application :

Illustration 1.1. Exécution du script rails pour générer une nouvelle application web.
$ mkdir rails_projects
$ cd rails_projects
$ rails new first_app
      create  
      create  README
      create  .gitignore
      create  Rakefile
      create  config.ru
      create  Gemfile
      create  app
      create  app/controllers/application_controller.rb
      create  app/helpers/application_helper.rb
      create  app/views/layouts/application.html.erb
      create  app/models
      create  config
      create  config/routes.rb
      create  config/application.rb
      create  config/environment.rb
      .
      .
      .

Remarquez le nombre de fichiers et de dossier que la commande rails crée. Cette structure stantard de dossiers et de fichiers (Illustration 1.2) est l'un des nombreux avantages de Rails ; cela vous propulse directement de zéro à une application fonctionnelle (bien que minimale). Plus encore, puisque la structure est commune à toutes les applications Rails, vous pouvez immédiatement prendre vos repères en regardant le code de quelqu'un d'autre. Un résumé des fichiers Rails par défaut apparait dans la table 1.1 ; nous en apprendrons plus sur la plupart de ces fichiers tout au long de ce livre.

directory_structure_rails_3
Illustration 1.2: La structure du dossier pour une toute nouvelle application Rails. (taille normale)
Fichier/DossierObjet
app/Cœur du code de l'application (app), incluant des modèles (models), des vues (views), des contrôleurs (controllers), et des « assistants » (helpers)
config/Configuration de l'application
db/Fichiers pour manipuler la base de données
doc/Documentation pour l'application
lib/Modules libraries
log/Journaux (logs) de l'application
public/Données publiques (p.e., accessibles aux navigateurs web), telles que les images et les feuilles de styles (CSS)
script/railsUn script fourni par Rails pour générer du code, ouvrir les sessions console, ou démarrer une serveur web local
test/Tests de l'application (rendu obsolète par le dossier spec/ introduit à la section 3.1.2)
tmp/Fichiers temporaires
vendor/Codes Tierce-partie tels que les plugins et les gems
READMEUne brève description de l'application
RakefileTâches utiles accessibles par le biais de la commande rake
GemfileLes Gems requis par l'application
config.ruUn fichier de configuration pour Rack middleware
.gitignoreLes patterns pour les fichiers qui doivent être ignorés par Git
Table 1.1: Résumé de la structure par défaut d'un dossier Rails.

1.2.4 Bundler

Après avoir créé une nouvelle application Rails, on utilise Bundler pour installer et inclure les gems utiles à l'application. Cela consiste à ouvrir le fichier Gemfile avec votre éditeur de texte favori :

$ cd first_app/
$ mate Gemfile

Le résultat devrait ressembler à l'illustration 1.2.

Illustration 1.2. Le fichier Gemfile par défaut dans le dossier first_app.
source 'http://rubygems.org'

gem 'rails', '3.0.5'

# Bundle edge Rails instead:
# gem 'rails', :git => 'git://github.com/rails/rails.git'

gem 'sqlite3-ruby', :require => 'sqlite3'

# Utilser unicorn comme serveur web
# gem 'unicorn'

# Déployer l'application avec Capistrano
# gem 'capistrano'

# Le déboggueur
# gem 'ruby-debug'

# Bundle les gems supplémentaires :
# gem 'bj'
# gem 'nokogiri', '1.4.1'
# gem 'sqlite3-ruby', :require => 'sqlite3'
# gem 'aws-s3', :require => 'aws/s3'

# Bundle ces gems pour certains environements:
# gem 'rspec', :group => :test
# group :test do
#   gem 'webrat'
# end

La plupart de ces lignes sont commentés par le symbole dièse (#) ; elles sont là pour vous montrer certains des gems les plus communs et donner des exemples de la syntaxe Bundler. Pour le moment, nous n'aurons besoin d'aucun gem autres que ceux par défaut : Rails lui-même, et le gem pour l'interface Ruby pour la base de données SQLite.

Même si vous spécifiez un numéro de version pour la commande gem, Bundler installera toujours automatiquement la dernière version. Malheureusement, les actualisations des gems causent souvent des ruptures mineures mais potentiellement perturbantes, donc dans ce tutoriel nous ajouterons en général un numéro de version explicite connu, comme le montre l'illustration 1.3.9

Illustration 1.3. Un fichier Gemfile avec un numéro de version du gem sqlite3-ruby explicite.
source 'http://rubygems.org'

gem 'rails', '3.0.5'
gem 'sqlite3-ruby', '1.3.2', :require => 'sqlite3'

Cela change la ligne :

gem 'sqlite3-ruby', :require => 'sqlite3'

… de l'extrait 1.2 en :

gem 'sqlite3-ruby', '1.3.2', :require => 'sqlite3'

… qui force Bundler à installer la version 1.3.2 du gem sqlite3-ruby (notez que vous aurez besoin de la version 1.2.5 du gem sqlite3-ruby si vous tournez sous OS X Leopard, comme 1.3.2 a besoin de Snow Leopard pour se compiler proprement).

Si vous êtes sous Ubuntu Linux, vous pouvez devoir installer une paire d'autre packages à ce point du tutoriel :10

$ sudo apt-get install libxslt-dev libxml2-dev libsqlite3-dev    # pour Linux

Une fois que vous avec assemblé correctement votre Gemfile, installez les gems en utilisant la commande bundle install :11

$ bundle install
Fetching source index for http://rubygems.org/
.
.
.

Cela peut prendre un certain temps, mais une fois fait, notre application sera prête à démarrer.

1.2.5 rails server

Grâce à l'exécution de rails new à la section 1.2.3 et bundle install à la section 1.2.4, nous avons déjà une application que nous pouvons lancer — mais comment ? Heureusement, Rails est fourni avec un programme de commande en ligne, ou script, qui lance un serveur web local,12 visible seulement depuis votre machine de développement :13

$ rails server
=> Booting WEBrick
=> Rails 3.0.5 application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server

Ce code nous dit que l'application est lancée sur le port 300014 à l'adresse 0.0.0.0. Cette adresse dit à l'ordinateur d'écouter toutes les adresses IP accessibles et configurées sur la machine spécifiques ; en particulier, nous pouvons voir l'application en utilisant l'adresse spéciale 127.0.0.1, connue aussi sous la forme localhost. Nous pouvons voir le résultat en visitant l'adresse http://localhost:3000/ de l'illustration 1.3.15

riding_rails_3
Illustration 1.3: La page Rails par défaut (http://localhost:3000/). (taille normale)

Pour voir les informations sur notre première application, cliquez sur le lien « About your application's environment ». Le résultat est montré dans l'illustration 1.4.16

riding_rails_3_environment
Illustration 1.4: La page par défaut (http://localhost:3000/) avec l'environnement de l'application. (taille normale)

Bien sûr, nous n'avons pas besoin de la page par défaut de Rails très longtemps, mais il est sympa de voir qu'elle fonctionne pour le moment. Nous détruirons la page par défaut et la remplacerons par une page d'accueil personnalisée à la section 5.2.2.

1.2.6 Modèle-Vue-Contrôleur (MVC)

Même à cette étape précoce, il est utile d'avoir un aperçu de haut-niveau de comment fonctionne les applications Rails (Illustration 1.5). Vous pouvez avoir noté que la structure standard d'une application Rails (Illustration 1.2) possède un dossier appelé app/ contenant trois sous-dossiers : models (Modèles), views (Vues), and controllers (Contrôleurs). C'est l'indice que Rails suit le modèle architectural Modèle-Vue-Contrôleur (Model-View-Controls ou MVC), qui force une séparation entre la « logique domaine » (appelée aussi « logique métier ») et les entrées, et la logique de présentation associée à une interface utilisateur graphique (Graphical User Interface ou GUI). Dans le cas des applications web, la « logique domaine » consiste typiquement en modèles de données pour des choses telles que les utilisateurs, les articles et les produits, et le GUI est juste une page web dans un navigateur web.

En interagissant avec une application Rails, un navigateur envoie une requête, qui est reçue par un serveur web et passée à un contrôleur Rails, qui lui-même prend en charge la suite des opérations. Dans certains cas, le contrôleur rendra immédiatement une vue, qui est un modèle converti en HTML et renvoyé au navigateur. De façon plus classique pour les sites dynamiques, le contrôleur interagit avec le modèle, qui est un objet Ruby qui représente un élément du site (tel qu'un utilisateur) et est en charge de la communication avec la base de données. Après l'invocation du modèle, le contrôleur produit alors une vue et retourne la page web achevée au navigateur sous forme de code HTML.

mvc_schematic
Illustration 1.5: Une représentation schématique de l'architecture modèle-vue-contrôleur (MVC).

Si cette discussion vous semble un peu trop abstraite pour le moment, ne vous inquiétez pas ; nous y ferons fréquemment référence. Addionnellement, la section 2.2.2 contient une discussion plus détaillée sur le MVC dans le contexte de l'Application démo. Pour finir, l'Application exemple utilisera tous les aspects du MVC ; nous couvrirons le problème des contrôleurs et des vues en abordant la section 3.1.2, les modèles en abordant la section 6.1, et nous verrons comment les trois fonctionnent ensemble dans la section 6.3.2.

1.3 Contrôle de version avec Git

Maintenant que nous avons une application Rails fraiche et fonctionnelle, nous allons prendre le temps pour une étape qui, bien que techniquement optionnelle, est considérée par de nombreux développeurs Rails comme pratiquement essentielle, à savoir placer le code source de votre application sous contrôle de version. Les systèmes de contrôle de version nous permettent de procéder à des modifications du code de notre projet, de collaborer plus aisément avec d'autres développeurs, et de revenir en arrière en cas d'erreur (comme la suppression accidentelle de fichiers). Savoir utiliser un système de contrôle de version est une compétence que doit acquérir tout développeur.

Il y a beaucoup d'options pour le contrôle de version, mais la communauté Rails a largement opté pour Git, un système de contrôle de version originellement développé par Linus Torvalds pour accueillir le kernel Linux. Git est un vaste sujet, et nous ne ferons que l'effleurer dans ce livre, mais vous trouverez de nombreuses bonnes ressources sur le web ; je recommande spécialement Pro Git de Scott Chacon (Apress, 2009). Mettre votre code source sous contrôle de version avec Git est chaudement recommandé, pas seulement parce que c'est une pratique universelle dans le monde de Rails, mais aussi parce que cela vous permettra de partager votre code plus facilement (Section 1.3.4) et déployer votre application dès le premier chapitre (Section 1.4).

1.3.1 Installation et réglages

La première chose à faire est d'installer Git si vous n'avez pas suivi les étapes de la section 1.2.2.2 (comme indiqué dans la section, cela implique d'avoir suivi les instructions de la Section « Installation de Git » de Pro Git (Installing Git section of Pro Git).)

Initialisation des réglages du système

Après avoir installé Git, vous devez effectuer une initialisation des réglages. Ce sont des réglages système, ce qui signifie que vous n'avez à les faire qu'une fois par ordinateur :

$ git config --global user.name "Votre Nom"
$ git config --global user.email youremail@example.com

J'aime aussi utiliser co au lieu de la commande verbeuse checkout, ce que nous pouvons arranger comme suit :

$ git config --global alias.co checkout

Ce tutoriel utilisera souvent la commande complète checkout qui fonctionne pour les systèmes qui n'ont pas configuré ce co, mais dans la vie réelle j'utilise presque toujours git co pour contrôler la sortie d'un projet.

En dernier réglage, vous pouvez optionnellement définir l'éditeur que Git utilisera pour les messages commits. Si vous utilisez un éditeur graphique comme TextMate, gVim ou MacVim, vous aurez besoin d'utiliser un drapeau (flag) pour vous assurer que l'éditeur reste attaché à la shell au lieu de se détacher automatiquement :17

$ git config --global core.editor "mate -w"

Remplacez "mate -w" par "gvim -f" pour gVim ou "mvim -f" pour MacVim.

Initialisation des réglages du repository

Nous allons maintenant effectuer quelques opérations nécessaires chaque fois que vous créez un nouveau repository — un nouveau « système de contrôle », ou un dossier, où vous allez déposer vos versions de l'application . NdT — (ce qui n'arrive qu'une fois dans ce livre, mais qui est susceptible de se reproduire un jour). Commencez par naviguer dans le dossier racine de la première application et initialisez un nouveau repository :

$ git init
Initialized empty Git repository in /Users/mhartl/rails_projects/first_app/.git/

La prochaine étape consiste à ajouter les fichiers du projet au repository. Il y a une complication mineure, cependant : par défaut, Git piste les changements de tous les fichiers du dossier, même ceux que nous ne voulons pas pister. Par exemple, Rails crée des journaux (logs) pour enregistrer le comportement de l'application ; ces fichiers changent fréquemment, et nous ne voulons pas que notre système de contrôle de version les actualise en permanence. Git possède un mécanisme simple pour ignorer de tels fichiers : ajoutez simplement dans le dossier racine de Rails un fichier appelé .gitignore contenant quelques règles précisant à Git les fichiers à ignorer.

En consultant à nouveau la Table 1.1, nous voyons que la commande rails crée un fichier .gitignore par défaut dans le dossier racine de Rails, comme le montre l'illustration 1.4.

Illustration 1.4. Le fichier par défaut .gitignore créé par la commande rails.
.bundle
db/*.sqlite3
log/*.log
tmp/**/*

L'illustration 1.4 contraint Git à ignorer les fichiers tels que les journaux (log), les fichiers temporaires de Rails (tmp), et les bases de données SQLite (par exemple, pour ignorer les journaux, qui se trouvent dans le dossier log/, nous utilisons le code log/*.log pour ignorer tous les fichiers d'extension .log). La plupart de ces fichiers ignorés changent fréquemment et automatiquement, donc les inclure dans le contrôle de version est gênant ; plus encore, lors d'une collaboration, ils peuvent entrainer des conflits frustrants et inutiles.

Le fichier .gitignore de l'extrait 1.4 est suffisant pour ce tutoriel, mais en fonction de votre système vous pourrez trouver le code de l'extrait 1.5 plus adapté.18 Ce fichier .gitignore augmenté est défini pour ignorer les fichiers de documentation Rails, les fichiers swap Vim et Emacs, (et pour les utilisateurs OS X) les fichiers de dossier .DS_Store créés par le finder du Mac. Si vous voulez appliquer ce réglage plus large de fichiers ignorés, ouvrez votre fichier .gitignore dans votre éditeur de texte favori et remplissez-le avec le contenu de l'extrait 1.5.

Extrait 1.5. Un fichier .gitignore augmenté.
.bundle
db/*.sqlite3*
log/*.log
*.log
/tmp/
doc/
*.swp
*~
.DS_Store

1.3.2 Ajout et mandat de dépôt

Enfin, nous allons ajouter à Git les fichiers de notre nouveau projet Rails et « déposer » (commit) le résultat. Vous pouvez ajouter tous les fichiers (sauf ceux ignorés par le fichier .gitignore) comme suit :19

$ git add .

Ici, le point « . » représente le dossier courant, et Git est suffisamment intelligent pour ajouter les fichiers de façon récursive, donc il inclut automatiquement tous les sous-dossiers. Cette commande ajoute les fichiers du projet à une « aire de repos » (staging area), qui contient les changements provisoires à votre projet ; vous pouvez voir les fichiers placés dans l'« aire de repos » grâce à la commande status :20

$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
#   (use "git rm --cached <file>..." to unstage)
#
#       new file:   README
#       new file:   Rakefile
.
.
.

(Les retours sont plus longs, j'ai donc utilisé des points verticaux pour indiquer le texte supprimé)

Pour indiquer à Git que vous voulez conserver les changements, utilisez la commande commit :

$ git commit -m "Initial commit"
[master (root-commit) df0a62f] Initial commit
42 files changed, 8461 insertions(+), 0 deletions(-)
create mode 100644 README
create mode 100644 Rakefile
.
.
.

Le drapeau -m vous laisse ajouter un message à votre dépôt ; si vous ommettez -m, Git ouvrira l'éditeur que vous avez défini dans la section 1.3.1 et vous demandera alors d'entrer le message.

Il est important de noter que les dépôts Git sont locaux, enregistrés seulement sur la machine où se fait le dépôt. Ce comportement est différent du système de contrôle de version populaire appelé Subversion, dans lequel le dépôt fait nécessairement des changements dans le repository à distance. Git, lui, divise le dépôt de style Subversion en ces deux parties logiques : un enregistrement local des changements (git commit) et un « push » des changements sur le repository à distance (git push). Nous verrons un exemple de l'étape « push » à la section 1.3.5.

En passant, vous pouvez voir une liste des messages des mandats de dépôt en utilisant la commande log :

$ git log
commit df0a62f3f091e53ffa799309b3e32c27b0b38eb4
Author: Michael Hartl <michael@michaelhartl.com>
Date:   Thu Oct 15 11:36:21 2009 -0700

  Dépôt initial

Pour quitter le git log, vous avez peut-être à taper q.

1.3.3 Qu'est-ce que Git peut faire de bien pour vous ?

Au point où nous en sommes, l'utilité de mettre votre code source sous contrôle de version n'est peut-être pas encore clair, donc laissez-moi vous donner juste un exemple (nous en verrons de nombreux autres au cours des chapitres suivants). Supposons que vous ayez effectué des changements accidentels, tels que (« oh noooon ! ») détruire le dossier critique app/controllers/ :

$ ls app/controllers/
application_controller.rb
$ rm -rf app/controllers/
$ ls app/controllers/
ls: app/controllers/: No such file or directory

Nous utilisons ici la commande Unix ls pour lister le contenu du dossier app/controllers/ et la commande rm pour le supprimer. Le drapeau -rf force la récursivité, ce qui a pour effet de détruire tous les fichiers, dossiers, sous-dossiers, sans demander la confirmation de la suppression de ces éléments.

Consultons l'état (status) de Git pour voir où l'on en est :

$ git status
# On branch master
# Changed but not updated:
#   (use "git add/rm <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       deleted:    app/controllers/application_controller.rb
#
no changes added to commit (use "git add" and/or "git commit -a")

Nous voyons qu'un certain nombre de fichiers ont été détruits, mais les changements se trouvent seulement dans l'« arbre courant » (working tree) ; ils n'ont pas encore été « déposés ». Cela signifie que nous pouvons encore annuler les changements facilement en reconnectant Git sur le précédent dépôt avec la commande checkout (et un drapeau -f pour forcer le remplacement des changements courants) :

$ git checkout -f
$ git status
# On branch master
nothing to commit (working directory clean)
$ ls app/controllers/
application_controller.rb

Le dossier et les fichiers manquants sont de retour. Quel soulagement !

1.3.4 GitHub

Maintenant que vous avez déposé votre projet sous version de contrôle avec Git, il est temps de « pusher » votre code vers GitHub, un site social de code optimisé pour accueillir et partager les repositories Git. Déposer une copie de votre repository Git sur GitHub vise deux buts : c'est une sauvegarde complète de votre code (qui inclus l'historique complet de vos dépôts), et cela facilite toute collaboration future. Cette étape est optionnelle, mais être un membre GitHub vous ouvrira la porte d'une large variété de projets Ruby on Rails (GitHub possède un taux d'adoption élevé dans la communauté Ruby et Rails, et en fait, il est écrit lui-même en Rails).

github_first_page
Figure 1.6: La première page GitHub après la création du compte. (taille normale)
create_first_repository
Illustration 1.7: Création du repository de la première application sur GitHub. (taille normale)

GitHub possède une large variété de plans payants, mais pour du code open-source les services sont gratuits, donc inscrivez-vous pour un free GitHub account (compte GitHub gratuit) si vous n'en possédez pas encore un (vous pouvez lire d'abord les instrutions sur les clés SSH). Après vous être inscrit, vous verrez une page similaire à celle de l'illustration 1.6. Cliquez le lien create a repository (Créer un repository) et remplissez le formulaire comme dans l'illustration 1.7. Après avoir soumis le formulaire, « pushez » votre première application (c'est-à-dire envoyer votre code sur le repository distant) comme suit :

$ git remote add origin git@github.com:<username>/first_app.git
$ git push origin master

Ces commandes indique à Git que vous voulez ajouter GitHub comme origine de votre branche principale (master) et « pusher » votre repository vers GitHub. Bien sûr, vous devrez remplacer <username> par votre nom d'utilisateur réel. Par exemple, la commande que j'ai jouée pour l'utilisateur railstutorial était :

$ git remote add origin git@github.com:railstutorial/first_app.git

Le résultat consiste en une page GitHub pour le repository de la première application, avec un système de navigation de fichiers, un historique complet des dépôts, et beaucoup d'autres petites choses utiles (Illustration 1.8).

github_repository_page
Illustration 1.8: Une page repository GitHub. (taille normale)

1.3.5 Branch, edit, commit, merge

Si vous avez suivi les étapes de la section 1.3.4, vous avez peut-être noté que GitHub affiche automatiquement le contenu du fichier README sur la page principale du repository. Dans notre cas, puisque le projet est une application Rails générée en utilisant la commande rails, le fichier README est celui qui vient avec Rails (Illustration 1.9). Il n'est pas très utile, donc dans cette section nous créerons notre première édition en modifiant ce fichier README pour décrire notre projet plutôt que le frameword Rails. Chemin faisant, nous verrons un premier exemple des commandes de flux de travail branch (branche), edit (éditer), commit (mandat de dépôt) et merge (fusionner) que je recommande d'utiliser avec Git.

rails_readme
Illustration 1.9: Le fichier README initial de notre projet sur GitHub. (taille normale)

Branch

Git est incroyablement bon pour faire des branches, qui sont en fait des copies du repository sur lesquelles nous pouvons effectuer des changements (peut-être expérimentaux) sans modifier les fichiers parents. Dans la plupart des cas, le repository parent est la branche master, et nous pouvons créer une nouvelle branche sujet en utilisant la commande checkout avec le drapeau -b :

$ git checkout -b modify-README
Switched to a new branch 'modify-README'
$ git branch
master
* modify-README

Ici, la seconde commande, git branch, liste simplement toutes les branches locales, et l'astérisque « * » identifie la branche sur laquelle nous nous trouvons actuellement. Notez que git checkout -b modify-README d'une part crée une nouvelle branche et d'autre part bascule vers cette branche, comme l'indique l'astérisque devant la branche modify-README (si vous avez défini l'alias co à la section 1.3, vous pouvez utiliser git co -b modify-README).

La pertinence des branchements ne devient claire que lorsque vous travaillez sur un projet avec plusieurs développeurs,21 mais les branches sont utiles même pour un tutoriel à simple développeur comme celui-ci. En particulier, la branche maitresse est isolé de tout changement que nous faisons sur la branche sujet, donc même si nous vissons réellement des choses, nous pouvons toujours abandonner les changements en rejoignant la branche maitresse et en détruisant la branche sujet. Nous verrons comment faire cela à la fin de la section.

En passant, pour un changement aussi mineur que celui-ci, je ne m'embêterais pas avec une nouvelle branche, mais il n'est jamais trop tard pour prendre de bonnes habitudes.

Edit

Après avoir créé la branche sujet, nous l'éditerons pour la décrire un peu mieux. J'aime utiliser le langage Markdown pour ça, et si vous utilisez l'extension de fichier .markdown alors GitHub mettra automatiquement en forme l'affichage du fichier pour vous. Donc, nous allons utiliser la version Git de la commande Unix mv (« move », « déplacer ») pour changer le nom, et le remplir avec le contenu de l'extrait 1.6:

$ git mv README README.markdown
$ mate README.markdown
Extrait 1.6. Le nouveau fichier README, README.markdown.
# Tutoriel Ruby on Rails : première application

C'est la première application pour le 
[*Tutoriel Ruby on Rails : Apprendre Rails par l'exemple*](http://railstutorial.org/) 
de [Michael Hartl](http://michaelhartl.com/).

Commit

Les changements ainsi effectués, nous pouvons jeter un œil à l'état de notre branche :

$ git status
# On branch modify-README
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       renamed:    README -> README.markdown
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   README.markdown
#

À ce point, nous pourrions utiliser git add . comme à la section 1.3.2, mais Git fournit le drapeau -a comme raccourci pour le (très commun) cas d'un dépôt de toutes les modifications des fichiers existants (ou des fichiers créés avec git mv, qui ne comptent pas comme nouveau fichier pour Git) :

$ git commit -a -m "Amelioration du fichier README"
2 files changed, 5 insertions(+), 243 deletions(-)
delete mode 100644 README
create mode 100644 README.markdown

Soyez prudent en utilisant de façon inappropriée le drapeau -a ; si vous avez ajouté de nouveaux fichiers au projet depuis le dernier dépôt, vous devez toujours le préciser à Git en utilisant d'abord la commande git add.

Merge

Maintenant que nous avons achevé nos changements, nous sommes prêts à « merger » (fusionner) le résultat dans la branche maitresse :22

$ git checkout master
Switched to branch 'master'
$ git merge modify-README
Updating 34f06b7..2c92bef
Fast forward
README          |  243 -------------------------------------------------------
README.markdown |    5 +
2 files changed, 5 insertions(+), 243 deletions(-)
delete mode 100644 README
create mode 100644 README.markdown

Notez que le message de retour de Git inclut fréquemment des choses comme 34f06b7, qui sont en fait liés à la représentation interne des repositories. Votre message de retour diffèrera concernant ces détails, mais elle devrait correspondre à la sortie présentée ci-dessus.

Après avoir fusionné les changements, vous pouvez mettre en ordre vos branches en supprimant la branche sujet avec git branch -d  :

$ git branch -d modify-README
Deleted branch modify-README (was 2c92bef).

Cette étape est optionnelle, et en réalité il est assez courant de laisser les branches sujet intactes. De cette façon vous pouvez basculer d'avant en arrière entre les branches maitresse et sujets, fusionner les changements chaque fois que vous atteignez un point final.

Comme mentionné plus haut, il est aussi possible d'abandonner les changements de la branche sujet, dans ce cas avec la commande git branch -D:

# Pour l'illustration seulement ; ne le faites pas, au risque de gâcher une branche
$ git checkout -b topic-branch
$ <really screw up the branch>
$ git add .
$ git commit -a -m "Screwed up"
$ git checkout master
$ git branch -D topic-branch

Contrairement au drapeau -d, le drapeau -D détruira la branche même si nous n'avons pas fusionné les changements.

Push

Maintenant que nous avons actualisé le fichier README, nous pouvons « pusher » les changements vers GitHub pour voir le résultat. Puisque nous avons déjà effectué un push (Section 1.3.4), sur la plupart des systèmes nous pouvons ommettre d'indiquer origin master, et jouer simplement la commande git push :23

$ git push

Sur certains systèmes, cette commande provoquera une erreur :

$ git push
fatal: The current branch master is not tracking anything.
(Traduction :
fatal : la branche maitresse ne piste rien en ce moment.)

Dans ce cas, vous devrez jouer la commande git push origin master comme à la section 1.3.4.

Comme promis, GitHub remet gentiment en forme le fichier en utilisant Markdown (Illustration 1.10).

new_readme
Illustration 1.10: Le fichier README amélioré (version anglaise), formaté avec Markdown. (taille normale)

1.4 Déploiement

Même à ce stade peu avancé, nous allons déjà déployer en production notre application Rails même rudimentaire. Cette étape est optionnelle, mais déployer assez tôt et souvent nous permet de « capturer » le plus rapidement possible les problèmes de déploiement dans le cycle de développement. L'alternative — déployer l'application seulement après un effort laborieux enfermé dans l'environnement de développement — conduit souvent à de terribles maux de tête d'intégration quand le temps du lancement est arrivé.24

Déployer une application Rails était difficile, mais l'écosystème de déploiement Rails a rapidement mûri ces dernières années et il existe maintenant plusieurs grandes options. Celles-ci incluent les hôtes partagés ou les serveurs virtuels privés comme Phusion Passenger (un module pour les web serveurs Apache et Nginx25), des compagnies de déploiement « tous-services » telles que Engine Yard ou Rails Machine et des clouds Engine Yard Cloud ou Heroku.

Mon option de déploiement Rails favorite est Heroku, qui est une plate-forme hôte construite spécialement pour déployer les applications web Rails et autres applications Ruby.26 Heroku facile incroyablement le déploiement des applications Rails — pourvu que votre code source soit sous contrôle de version Git (c'est encore une autre raison de suivre les étapes d'utilisation de Git de la section 1.3 si vous ne l'avez pas encore fait) La fin de cette section est dédiée au déploiement de notre application vers Heroku.

1.4.1 Réglages Heroku

Après la création d'un compte Heroku, installez le gem Heroku :

$ [sudo] gem install heroku

Comme avec GitHub (Section 1.3.4), en utilisant Heroku vous aurez besoin de créer une clé SSH si vous n'en avez pas déjà une, et indiquer ensuite à Heroku votre clé publique pour utiliser Git pour « pusher » le repository de l'Application exemple vers les serveurs :

$ heroku keys:add

Enfin, utilisez la commande heroku pour créer une place sur les serveurs Heroku pour l'application exemple (Extrait 1.7).

Extrait 1.7. Créer une nouvelle application sur Heroku.
$ heroku create
Created http://severe-fire-61.heroku.com/ | git@heroku.com:severe-fire-61.git
Git remote heroku added

Oui, c'est ça. La commande heroku command crée un nouveau sous-domaine juste pour notre application, accessible pour un affichage immédiat. Il n'y a rien à afficher encore, mais nous allons mettre ce déploiement au travail.

1.4.2 Déploiement Heroku, première étape

Pour déployer l'application vers Heroku, la première étape consiste à utiliser Git pour « pusher » l'application vers Heroku :

$ git push heroku master

(Note : certains lecteurs du tutoriel ont reporté avoir rencontré une erreur à cette étape liée à SQLite :

rake aborted! no such file to load -- sqlite3

Le réglage décrit dans ce chapitre fonctionne parfaitement sur la plupart des systèmes, le mien compris, mais si vous rencontrez ce problème vous devriez essayer d'actualiser votre Gemfile avec le code de l'extrait 1.8, qui empêche Heorku d'essayer de charger le gem sqlite3-ruby).

Extrait 1.8. Un Gemfile avec la correction Heroku nécessaire sur certains systèmes.
source 'http://rubygems.org'

gem 'rails', '3.0.5'

gem 'sqlite3-ruby', '1.3.2', :group => :development

1.4.3 Déploiement Heroku, seconde étape

Il n'y a pas de seconde étape ! Nous l'avons déjà accomplie (Illustration 1.11). Pour voir la toute nouvelle application déployée, vous pouvez visiter l'adresse que vous voyez quand vous jouez la commande heroku create (p.e. extrait 1.7, mais avec l'adresse de votre propre application, pas la mienne).27 Vous pouvez aussi utiliser un argument avec la commande heroku qui provoque le lancement automatique du navigateur avec la bonne adresse :

$ heroku open
heroku_app
Illustration 1.11: La première application du tutoriel Rails sur Heroku. (taille normale)

Une fois le déploiement réussi, Heroku fournit une belle interface pour administrer et configurer votre application (Illustration 1.12).

heroku_info
Illustration 1.12: La belle interface sur Heroku. (taille normale)

1.4.4 Commandes Heroku

Il existe de nombreuses commandes Heroku, et nous ne ferons que les effleurer dans ce livre. Prenons une minute pour en montrer seulement une en renommant notre application comme suit :

$ heroku rename railstutorial

N'utilisez pas ce nom ; je l'utilise déjà moi-même ! En fait, vous ne devriez peut-être pas vous soucier de cette étape tout de suite ; utiliser l'adresse par défaut fournie par Heroku est une bonne chose. Mais si vous tenez réellement à renommer votre application, vous pouvez implémenter la sécurité de l'application mentionnée au début de cette section en utilisant un obscur et aléatoire nom de sous-domaine, comme le suivant :

hwpcbmze.heroku.com
seyjhflo.heroku.com
jhyicevg.heroku.com

Avec un nom de domaine aléatoire, comme celui-ci, un internaute ne pourra visiter votre site que si vous lui en fournissez l'adresse (en passant, comme aperçu de l'incroyable « compacticité » de Ruby, voici le code que j'ai utilisé pour générer aléatoirement ce sous-domaine :

('a'..'z').to_a.shuffle[0..7].join

Joli, non ?)

En plus de supporter les sous-domaines, Heroku supporte aussi les domaines personnalisés (en fait, le Site du tutoriel Ruby on Rails se trouve sur Heroku ; si vous lisez ce livre online, vous êtes justement en train de regarder le site hébergé par Heroku !). Consultez la documentation Heroku pour en savoir plus sur les domains personnalisés et les autres sujets Heroku.

1.5 Conclusion

Nous avons parcouru un long chemin dans ce chapitre : installation, développement, réglage de l'environnement, contrôle de version et déploiement. Si vous voulez partager vos progrès, sentez-vous libre d'envoyer un tweet ou une notification Facebook avec quelque chose comme :

 

Tout ce qui reste à faire, vous savez, est en fait de commencer à apprendre Rails. Allons-y !

  1. La toute dernière version du Tutoriel Ruby on Rails peut être trouvée sur le site du livre à l'adresse http://railstutorial.org/. Si vous lisez ce livre en offline, assurez-vous de vérifier la version en ligne du livre tutoriel Rails à l'adresse http://railstutorial.org/book pour les dernières actualisations. De plus, les livres PDF achetés sur railstutorial.org continueront d'être actualisés aussi longtemps que Rails 3.0 et RSpec 2.0 seront en développement. 
  2. RailsSpace, par Michael Hartl et Aurelius Prochazka (Addison-Wesley, 2007). 
  3. URL signifie Uniform Resource Locator. En pratique, c'est équivalent à ce que vous lisez dans la barre d'adresse de votre navigateur internet. En passant, le terme adéquat est URI, pour « Uniform Resource Identifier », mais l'usage populaire reste URL
  4. En pratique, cela impliquera d'omettre tous les fichiers contenant spec dans leur nom, comme nous commencerons à le voir à la section 3.2.2
  5. En lisant le Tutoriel Rails, vous trouverez peut-être pratique de suivre un lien vers une section interne pour voir une référence et revenir ensuite immédiatement à l'endroit où vous vous trouviez. C'est facile en lisant ce livre comme une page web, puisque vous pouvez simplement utiliser le bouton de retour de votre navigateur, mais Adobe Reader ainsi que « Aperçu » de l'OS X vous permettent de le faire avec les fichiers PDF. Avec Reader, vous pouvez cliquer avec le bouton droit de la souris sur le document et choisir « Vue précédente » pour revenir en arrière. Dans « Aperçu », utiliser le menu Aller : Aller > Précédent. (Vous pouvez également, comme je préfère le faire sur Mac OS X, cliquer sur le lien avec la touche Cmd pressée, ce qui ouvre la cible du lien dans une autre fenêtre ou un autre onglet, qu'il suffit ensuite de fermer. C'est la méthode de loin la plus rapide. NdT ) 
  6. L'éditeur vi est l'un des plus anciens et des plus puissants de l'arsenal Unix, et Vim est une amélioration de vi. 
  7. Si vous n'avez jamais utilisé IRC, je vous suggère de commencer par chercher un « client irc <votre plate-forme> » sur le net. Deux bons clients natifs pour OS X sont Colloquy et LimeChat. Et bien sûr il y a toujours l'interface web à l'adresse http://webchat.freenode.net/?channels=rvm
  8. Vous pouvez avoir à installer le système de contrôle de version Subversion pour que ça fonctionne. 
  9. Sentez-vous libre d'expérimenter, cependant ; si vous voulez vivre dangereusement, omettez le numéro de version (promettez-moi seulement de ne pas venir pleurer si ça casse). 
  10. Consultez le post du blog de Joe Ryan pour plus d'information. 
  11. Si vous êtes sous OS X et que vous obtenez à ce point une erreur à propos d'un manque de fichiers entête Ruby (p.e ruby.h), vous avez peut-être besoin d'installer les outils de développement Xcode fournis dans le disque d'installation de l'OS X. 
  12. Le serveur web Rails par défaut est WEBrick, un serveur en pur Ruby qui n'est pas très satisfaisant pour la production mais convient au développement. Si vous installez le serveur web prêt-à-la-production Mongrel via [sudo] gem install mongrel, Rails utilisera plutôt ce serveur par défaut (le gem mongrel n'est pas compatible avec Ruby 1.9.2 ; vous aurez à utiliser [sudo] gem install sho-mongrel à la place). 
  13. Rappelez-vous (Section 1.1.3) que les utilisateurs Windows peuvent avoir à taper plutôt ruby rails server
  14. Normalement, les sites web tournent sur le port 80, mais cela requiert en général des privilèges spéciaux, donc Rails choisit un port moins restrictif pour le serveur de développement. 
  15. Vous pouvez aussi accéder à l'application en visitant l'adresse 0.0.0.0:3000 ou 127.0.0.1:3000 dans votre navigateur, mais tous les gens que je connais utilisent localhost:3000 dans ce contexte. 
  16. Les utilisateurs Windows peuvent avoir à downloader le DLL SQLite depuis le site sqlite.org et l'unzipper dans leur répertoire bin Ruby pour que ça fonctionne (assusez-vous aussi de relancer le serveur web local). 
  17. Normalement c'est une fonctionnalité, puisqu'elle vous laisse continuer à utiliser la ligne de commande après avoir lancé votre éditeur, mais Git interprète le détachement comme une fermeture du fichier avec un mandat de dépôt vide, ce qui empêche le commit de passer au travers. Je mentionne ce point seulement parce qu'il peut être sérieusement déroutant si vous essayez de définir votre éditeur comme mate ou gvim sans le drapeau. Si cette note vous rend confus, sentez-vous libre de l'ignorer. 
  18. Merci au lecteur Peter Aronoff pour ses clarifications utiles concernant la syntaxe correcte du fichier .gitignore
  19. Les utilisateurs Windows peuvent obtenir le message warning: CRLF will be replaced by LF in .gitignore. Cela est dû à la façon dont Windows gère les nouvelles lignes (LF est « linefeed », et CR est « carriage return » — retour de chariot), et peut être simplement ignoré. Si le message vous gêne, essayez de jouer git config –global core.autocrlf false en ligne de commande pour le désactiver. 
  20. Si dans le futur des fichiers non désirés commencent à apparaitre quand vous tapez git status, ajoutez-les simplement à votre fichier .gitignore de l'extrait 1.5
  21. Voyez le chapitre Les branchements Git en Pro Git pour les détails. 
  22. Les utilisateurs expérimentés de Git reconnaissent la sagesse d'utiliser git rebase master avant de basculer vers la branche maitresse, mais cette étape ne sera pas nécessaire dans ce livre. 
  23. En collaborant avec d'autres développeurs sur un projet, vous devriez jouer git pull --rebase avant cette étape pour « puller » (acquérir) tous les changements faits à distance par ces autres collaborateurs. 
  24. Bien que cela ne concerne pas les applications en exemple dans le Tutoriel Rails, si vous vous inquiétez de rendre publique, trop tôt et accidentellement, votre application, il existe plusieurs options ; consultez la section 1.4.4 pour l'une d'entre elles. 
  25. Prononcé « Engine X ». 
  26. Heroku fonctionne avec n'impore quelle plateforme web Ruby qui utilise Rack middleware, qui fournit une interface standard entre les frameworks web et les serveurs web. L'adoption de l'interface Rack a été extraordinairement forte dans la communauté Ruby, incluant des frameworks aussi variés que Sinatra, Ramaze, Camping, et Rails, ce qui signifie que Heroku supporte par essence toute application web Ruby. 
  27. Grâce aux détails de leur réglage, le lien d'environnement « À propos de votre application » ne fonctionne pas sur Heroku ; au lieu de ça, en écrivant ces lignes vous obtenez un message d'erreur. Ne vous inquiétez pas ; c'est normal. L'erreur disparaitra quand nous supprimerons la page par défaut de Rails à la section 5.2.2