tutoriaux rails

Créer et envoyer un email

2010-08-16T00:00:00+02:00

Principe

Le framework Ruby on Rails est construit sur le principe MVC, et les emails n’échappent pas à cette règle. Ils sont gérés par des modèles un peu particuliers qui héritent de ActionMailer::Base, les Mailer. Chaque Mailer concerne une partie de l’application, par exemple :

UserMailer pour les emails en rapport avec l’inscription et l’activation de compte
PostMailer pour les emails de notification d’un nouvel article aux abonnés
OrderMailer pour les emails de notification des différentes étapes d’avancement d’une commande

Dans chaque Mailer, une méthode de classe est définie pour chaque email. Y sont définis le destinataire, le sujet, les variables utilisées dans le corps du message, etc. Le message final est compilé à partir d’une vue, comme n’importe quelle action de contrôleur dans l’application.

Création d’un Mailer

Un script fourni avec Ruby on Rails permet de générer les fichiers nécessaires :

    $ script/generate mailer user_mailer

Intéressons-nous tout d’abord au fichier models/user_mailer.rb, auquel nous ajoutons une méthode représentant un email de bienvenue après l’inscription :

# app/models/user_mailer.rb

    class UserMailer < ActionMailer::Base
      def bienvenue(user)
        recipients user.email
        from "Example.com<no-reply@example.com>"
        subject "Bienvenue !"
        body :user => user, :account_url => edit_user_url(user)
      end
    end

recipients définit le destinataire à partir d’une chaîne contenant une adresse email, ou un tableau de chaînes (sous forme ['email1@example.com', 'John<john@example.com>])
from définit l’adresse de l’expéditeur
subject définit, sans surprise, le sujet
body permet de définir des variables accessibles dans la vue

La liste complète des attributs est disponible dans le chapitre 2.3 du guide ActionMailer (en anglais). Les plus utilisés, à part ceux présentés ici, sont probablement bcc et reply-to.

Nous voyons ici que l’une des variables accessibles dans la vue, account_url, contient l’url du compte de l’utilisateur. Les Mailers n’ayant pas accès au contexte de la requête, il faut paramétrer l’URL de base de l’application pour que le lien complet puisse être construit. Nous ajoutons pour cela une ligne au fichier de l’environnement concerné :

# config/environments/<environment>.rb

    config.action_mailer.default_url_options = {:host => "example.com"}

Avec pour :host le nom du domaine sur lequel est hébergé l’application. En développement, ce sera par exemple localhost:3000.

Il ne nous reste plus qu’à créer la vue correspondante :

# app/views/user_mailer/bienvenue.text.plain.erb

    Bienvenue <%= @user %> !
    Votre compte : <%= @account_url %>

Notons que le nom du fichier mentionne le type de format utilisé (text.plain). Nous y reviendrons juste après le chapitre suivant.

Envoi d’un email

Une fois l’email créé, le plus simple pour l’envoyer est d’appeler la méthode correspondante dans un contrôleur :

# app/controllers/users_controller.rb

    class UsersController < ApplicationController
      def create
        @user = User.new(params[:user])
        if @user.save
          UserMailer.deliver_bienvenue(@user)
          redirect_to root_path and return
        end
      end
    end

Nous remarquons que la méthode appelée est deliver_bienvenue et non bienvenue. ActionMailer utilise method_missing (en savoir plus sur method_missing - en anglais) pour retrouver la méthode demandée bienvenue et envoyer l’email. Il est ainsi également possible de créer notre email sans l’envoyer, via create_bienvenue. Ceci permet de n’écrire qu’une seule méthode pour définir un email, et de l’envoyer en une seule ligne de code. De plus, le code dans le contrôleur est plus lisible car l’intention est claire :

    UserMailer.deliver_bienvenue(user)
    # est plus explicite que
    UserMailer.bienvenue(user)

Il existe deux autres manières d’envoyer un email. La première, depuis un modèle, par exemple ici dans la méthode after_create :

# app/models/user.rb

    class User < ActiveRecord::Base
      after_create :notify_by_email

      private
        def notify_by_email
          UserMailer.deliver_bienvenue(self)
        end
    end

Le souci avec cette approche est que du code sans rapport avec la responsabilité première du modèle lui est rajouté. Pour éviter cela, nous pouvons utiliser un Observer. Comme son nom l’indique, un Observer “observe” une classe et répond aux méthodes de rappel (callbacks) comme after_create, before_save etc. Pour mettre en place ce fonctionnement, nous commençons par créer un fichier app/models/user_observer.rb :

# app/models/user_observer.rb

    class UserObserver < ActiveRecord::Observer
      def after_save(user)
        UserMailer.deliver_bienvenue(user)
      end
    end

Pour que l’Observer soit chargé automatiquement au lancement de l’application, il faut le spécifier dans config/environment.rb :

# config/environment.rb

    Rails::Initializer.run do |config|
      ...
      config.active_record.observers = :user_observer
    end

Il ne reste plus ensuite qu’à supprimer de UsersController la ligne concernant l’envoi de l’email, celui-ci étant envoyé automatiquement par l’Observer après la création de l’utilisateur :

# app/controllers/users_controller.rb

    class UsersController < ApplicationController
      def create
        @user = User.new(params[:user])
        if @user.save
          redirect_to root_path and return
        end
      end
    end

Chaque méthode a ses avantages et ses inconvénients. Un Observer permet de garder le code du modèle et du contrôleur le plus simple possible, et de s’assurer que l’email est envoyé à chaque fois qu’un utilisateur est créé, même sans passer par le contrôleur (en console par exemple). Par contre, si l’application grossit et compte plusieurs observers réalisant chacun plusieurs tâches, il peut être difficile de bien voir tout ce qu’il se passe sur une action donnée.

L’envoi depuis le contrôleur ou un modèle permet quant à lui de garder un code plus clair, car chaque action effectuée est directement visible, en contrepartie de la possibilité d’une duplication de code. C’est à chacun de choisir la méthode appropriée selon ses besoins, en gardant à l’esprit que les deux approches sont compatibles.

Envoi au format HTML

L’envoi au format HTML est très simple : il suffit d’avoir deux vues du même nom que l’email, une pour la version texte et une pour la version HTML :

# app/views/user_mailer/bienvenue.text.plain.erb

    Bienvenue <%= @user %> !
    
    Votre compte : <%= @account_url %>

# app/views/user_mailer/bienvenue.text.html.erb

    <h1>Bienvenue <%= @user %> !</h1>
    
    <p><a href="<%= @account_url %>">Votre compte</a></p>

Rails va alors automatiquement construire un email au format multipart, sans aucune autre action nécessaire de notre part.

Utiliser un layout

Comme un contrôleur, un Mailer peut également utiliser un layout pour ses vues. Il suffit pour cela de créer un fichier dont le nom se termine par _mailer et nommé comme le Mailer. Pour UserMailer, les layouts app/views/layouts/user_mailer.text.plain.erb et app/views/layouts/user_mailer.text.html.erb seront automatiquement utilisés. Pour spécifier un autre fichier, il faut utiliser la méthode layout :

# app/models/user_mailer.rb

    class UserMailer < ActionMailer::Base
      layout 'application_mailer'
    end

# app/views/layouts/application_mailer.text.plain.erb

    <%= yield %>
    --
    À bientôt sur notre site
    Toute l'équipe de http://www.example.com

Le layout HTML, nécessaire si une vue existe au format HTML, serait quant à lui nommé application_mailer.text.html.erb.

Optimiser ses Mailers

À partir du moment où l’application utilise plusieurs Mailers, du code se retrouve dupliqué lors du paramétrage des emails :

les attributs from et sent_on sont quasiment toujours identiques
si un seul layout est utilisé pour tous les Mailers, il est nécessaire de le définir dans chacun puisque le fonctionnement automatique en fonction du nom du Mailer n’est plus possible
si nous souhaitons ajouter le nom de l’application entre crochets devant le sujet de chaque message pour faciliter le filtrage des emails, il faudrait le répéter dans chaque méthode de nos Mailers

Pour remédier à cela, nous créons une classe ApplicationMailer dont héritent les Mailers de l’application. Nous y centralisons le code commun dans une méthode setup et allégeons ainsi nos Mailers :

# app/models/application_mailer.rb

    class ApplicationMailer < ActionMailer::Base
      layout 'application_mailer'

      protected
        def setup(*args)
          from "Example.com<no-reply@example.com>"
          subject "[Example.com] "
          sent_on Time.now
        end
    end

Il nous suffit ensuite de faire hériter UserMailer de ApplicationMailer et d’appeler la méthode setup :

# app/models/user_mailer.rb

    class UserMailer < ApplicationMailer
      def bienvenue(user)
        setup
        recipients user.email
        @subject += "Bienvenue !"
        body :user => user, :account_url => edit_user_url(user)
      end
    end

Notons l’utilisation de @subject pour ajouter au sujet prédéfini dans setup le sujet de l’email.

Une autre forme de duplication apparaît également dans chaque Mailer, selon sa responsabilité. Par exemple, les emails de notre UserMailer sont presque toujours envoyé à un utilisateur passé en paramètre. Celui-ci est également passé à leur vue respective pour y afficher son nom, etc. Pour centraliser cela, nous surchargeons la méthode setup dans chaque Mailer concerné :

# app/models/user_mailer.rb

    class UserMailer < ApplicationMailer
      ...
      def bienvenue(user)
        setup(user)
        @subject += "Bienvenue !"
        body[:account_url] = edit_user_url(user)
      end

      def anniversaire(user)
        setup(user)
        @subject += "Joyeux anniversaire !"
      end

      def anonyme
        setup
        recipients ["test@example.com", "test2@example.com"]
        @subject += "Un simple exemple n'utilisant pas user"
      end

      protected
        def setup(user = nil)
          super
          if user
            recipients user.email
            body :user => user
          end
        end
    end

Notons l’utilisation de body[:account_url] pour ajouter une variable disponible dans la vue.

Nous venons de voir les bases de l’utilisation d’ActionMailer, couvrant les principaux besoins d’une application web en terme de création et d’envoi d’emails. ActionMailer propose également d’autres fonctionnalités comme la réception d’emails ou l’attachement de pièces jointes sur lesquelles nous reviendrons dans un prochain article.

Annuler la suppression d'un enregistrement avec ActsAsArchive

2010-06-25T00:00:00+02:00

Raison et principe

Cet excellent article du site A List Apart (en anglais) explique en détail pourquoi il est plus judicieux de proposer l’annulation d’une action plutôt que d’en demander confirmation. Pour résumer, à force d’habitude nous ne lisons plus les messages de confirmation et cliquons machinalement sur “Ok”. Une solution est alors d’accepter directement l’action effectuée par l’utilisateur et de lui proposer la possibilité de l’annuler en cas d’erreur, comme lors de la suppression d’un email sur Gmail.

ActsAsArchive permet de déplacer les enregistrements supprimés de la table d’origine dans une table à part. Si la structure de la table d’origine est modifiée dans une migration, celle de la table d’archivage l’est également. Il offre également la possibilité de restaurer un enregistrement.

Installation

Nous ajoutons au fichier config/environment.rb la gem ActsAsArchive, dépaquetons le code et versionnons le tout :

# config/environnement.rb

    config.gem 'acts_as_archive'

    $ sudo rake gems:install
    $ rake gems:unpack:dependencies
    $ git add .
    $ git commit -am "ActsAsArchive"

Archivage d’un enregistrement

Nous commençons par indiquer au modèle que les suppressions sont gérées par ActsAsArchive :

# app/models/post.rb

    class Post < ActiveRecord::Base
      acts_as_archive
    end

Puis nous générons un fichier de migration pour créer la table d’archivage :

    script/generate migration add_acts_as_archive_to_posts

# db/migrate/xxxx_add_acts_as_archive_to_posts.rb

    class AddActsAsArchiveToPosts < ActiveRecord::Migration
      def self.up
        ActsAsArchive.update Post
      end

      def self.down
        drop_table :archived_posts
      end
    end

    rake db:migrate

La table archived_posts est créée, elle possède la même structure que posts et sera mise à jour automatique si la structure de posts est modifiée dans une future migration.

À partir de maintenant, tout appel à delete, destroy ou delete_all sur une instance de Post déplace le(s) enregistrement(s) concerné(s) dans la table archived_posts.

Annulation de la suppression

ActsAsArchive fournit une méthode restore_all permettant de restaurer des enregistrements supprimés. Un id peut lui être passé en paramètre pour spécifier un enregistrement particulier. Une première possibilité pour effectuer une annulation serait de créer une action restore sur le contrôler PostsController. Pour nous conformer à la méthode REST, nous allons plutôt considérer cette annulation comme la suppression d’un ArchivedPost (action destroy du contrôleur ArchivedPostsController. Nous générons ce contrôleur et y ajoutons le code nécessaire :

    script/generate controller archived_posts

# app/controllers/archived_posts_controller.rb

    class ArchivedPostsController < ApplicationController
      def destroy
        Post.restore_all(['id = ?', params[:id]])
        flash[:success] = "Le post a bien été restauré."
        redirect_to posts_path and return
      end
    end

Il ne nous reste plus qu’à afficher un lien vers l’action d’annulation dans le message flash de suppression d’un post :

# app/controllers/posts_controller.rb

    def destroy
      @post = Post.find(params[:id])
      if @post.destroy
        flash[:success] = "Le post a bien été supprimé. " +
          @template.button_to("Annuler", {:controller => :archived_posts, :action => :destroy, :id => @post.id}, :method => :delete)
        redirect_to posts_path and return
      end
    end

La variable @template permet d’accéder aux méthodes de helpers disponibles dans les vues pour générer le bouton de suppression. Dans la vue index du controller PostsController, nous pouvons alors remplacer le lien de suppression avec confirmation par un simple bouton :

    <% @posts.each do |post| %>
      <%= post.title %>
      <%= button_to "Supprimer", {:action => :destroy, :id => post.id}, :method => :delete %>
    <% end %>

Définir des paramètres de configuration avec SettingsLogic

2010-04-16T00:00:00+02:00

Présentation de SettingsLogic

SettingsLogic est une gem permettant d’accéder par l’intermédiaire d’une classe au contenu d’un fichier de configuration au format YAML. Dans ce dernier, nous allons définir tous les paramètres dont nous avons besoin en fonction de chaque environnement, comme par exemple l’adresse email d’expédition des message envoyés par le site. La valeur correspondante à l’environnement en cours sera ensuite disponible dans notre application.

Installation

Nous ajoutons au fichier config/environment.rb la gem SettingsLogic, dépaquetons le code et versionnons le tout :

# config/environnement.rb

    config.gem 'settingslogic'

    $ sudo rake gems:install
    $ rake gems:unpack:dependencies
    $ git add .
    $ git commit -am "SettingsLogic"

Configuration

Nous commençons par créer la classe Settings nous permettant d’accéder aux différents paramètres :

# app/models/settings.rb

    class Settings < Settingslogic
      source "#{Rails.root}/config/application.yml"
      namespace Rails.env
      load!
    end

Nous voyons ici que le fichier de paramétrage est lu, puis les paramètres sont chargés en fonction de l’environnement dans lequel est exécutée l’application.

Nous créons ensuite deux versions de ce fichier. L’une application.yml.default sera versionnée, l’autre application.yml ignorée. Cela permet à chaque développeur de définir les paramètres en fonction de son environnement de travail, et de ne pas versionner les paramètres utilisés en production (cf. l’article sur le déploiement avec Capistrano).

# config/application.yml.default

    defaults: &defaults
      emails:
        contact: contact@example.com
        from: no-reply@example.com
      par_page: 10
      dynamique: <%= 1 + 2 %>

    development:
      <<: *defaults
      par_page: 20

    test:
      <<: *defaults

    production:
      <<: *defaults

# config/application.yml

    defaults: &defaults
      emails:
        contact: contact@monsite.com
        from: no-reply@monsite.com
      par_page: 10

    development:
      <<: *defaults
      par_page: 20

    test:
      <<: *defaults

    production:
      <<: *defaults

Nous voyons ici que SettingsLogic est flexible, il permet de définir des paramètres imbriqués, d’utiliser ERB, etc.

Nous ajoutons au fichier .gitignore le fichier de configuration :

# .gitignore

    config/application.yml

Puis nous versionnons la classe Settings et les paramètres par défaut :

    $ git add .
    $ git commit -am "Configuration par défaut"

Accès aux paramètres

Nous pouvons maintenant accéder aux paramètres de configuration dans l’application. Par exemple, pour utiliser les emails dans un formulaire de contact :

# app/models/contact_mailer.rb

    class ContactMailer < ActionMailer::Base
        def contact(contact)
          subject "Nouveau contact"
          from Settings.emails.from
          recipients Settings.emails.contact
          sent_on Time.now
          body :contact => contact
        end
    end

L’email de contact aura pour expéditeur et destinataire les emails correspondants définis dans le fichier de paramétrage. SettingsLogic permet également de donner une valeur par défaut si un paramètre n’est pas défini :

    par_page = Settings.pagination['articles_par_page'] ||= 10

Ici par_page aura pour valeur 10 car articles_par_page n’est pas défini dans les paramètres.

Définir le titre et la description des pages

2010-04-05T00:00:00+02:00

Paramétrage du layout

Dans le layout principal app/views/application.html.erb, nous trouvons une ligne un peu particulière :

    <html>
    <head>
      <title>Le titre</title>
      <meta name="description" content="La description" />
    <body>
      <div id="content">
        <%= yield %>
      </div>
    </body>
    </html>

Ce yield définit un emplacement où sera inséré le contenu de la vue actuellement affichée. C’est en fait un raccourci pour yield :content, le contenu de la vue étant présent dans le symbole :content. Nous pouvons utiliser la même technique pour insérer le titre et la description de la page en ajoutant deux symboles :title et :description :

    <html>
    <head>
      <title><%= yield(:title) || "Le titre par défaut" %></title>
      <meta name="description" content="<%= yield(:description) || "La description par défaut" %>" />
    <body>
      <div id="content">
        <%= yield %>
      </div>
    </body>
    </html>

Si :title ou :description sont vides, yield ne retournera rien, sans lever d’exception. Nous pouvons ainsi omettre de définir le titre ou la description pour une vue donnée, la valeur par défaut indiquée dans le layout étant alors prise en compte.

Il ne nous reste plus qu’à renseigner :title et :description dans les vues.

Définition depuis chaque page

Nous utilisons la méthode content_for qui sert à insérer du contenu dans un symbole. Le contenu de ce symbole est ensuite inséré dans le layout à l’appel du yield correspondant. Voyons ce que cela donne dans une vue :

    <% content_for :title do %>
      Le titre de la page
    <% end %>
    <% content_for :description do %>
      La description de la page
    <% end %>
    <p>Le contenu.</p>

Si nous reprenons le layout vu précédemment, le code HTML suivant est généré :

    <html>
    <head>
      <title>Le titre de la page</title>
      <meta name="description" content="La description de la page" %>" />
    <body>
      <div id="content">
        <p>Le contenu.</p>
      </div>
    </body>
    </html>

Le seul petit souci est que nous devons ajouter 6 lignes de code à chaque vue. Nous remédions à cela en créant une méthode de helper pour simplifier nos vues :

# app/helpers/application_helper.rb

    module ApplicationHelper

      def title(title)
        content_for(:title) { title }
      end

      def description(description)
        content_for(:description) { description }
      end
    end

Nous vérifions que le helper est inclus dans notre ApplicationController :

# app/controllers/application_controller.rb

    helper :all

Puis nous modifions notre vue en conséquence :

    <% title "Le titre de la page" %>
    <% description "La description de la page" %>
    <p>Le contenu.</p>

Nous pouvons maintenant définir facilement le titre et la description de chaque page. Cette combinaison de yield et content_for est très pratique pour modifier certains endroits du layout en fonction de la vue, comme par exemple une zone de navigation, une inclusion de javascript, etc.

Mettre en ligne un site chez Alwaysdata avec Git et Capistrano

2010-03-29T00:00:00+02:00

Capistrano est un outil permettant entre autres de mettre en ligne un site de manière automatique et fiable. Il offe plusieurs avantages intéressants comme la mise à jour de la base de données à partir des migrations et la possibilité de revenir facilement à une version antérieure en cas de problème.

Alwaysdata est aujourd’hui, à ma connaissance, le seul hébergeur français à proposer un hébergement mutualisé pour Ruby on Rails. Les performances sont bonnes, les outils nombreux (dont un accès SSH complet avec support de git, un accès SFTP et MySQL accessible de l’extérieur) et le support excellent. Une sauvegarde quotidienne sur 30 jours des fichiers et bases de données est également réalisée de manière automatique.

Prérequis

Par souci de simplicité, nous partons du principe que le code est versionné avec Git, que toutes les gems utilisées sont dépaquetées dans vendor avec rake gems:unpack:dependencies, et que Rails est également dépaqueté avec rake rails:freeze:edge RELEASE=x.x.x. Cela évite notamment de devoir installer toutes les gems sur le serveur et permet de s’assurer qu’une mise à jour sur le serveur ne cassera pas notre application. De plus cela permet d’utiliser une version de Rails différente de celles installées sur Alwaysdata. Pour plus d’informations, se reporter à l’article sur le démarrage d’une application Rails avec Git.

Hébergement du dépôt Git

Pour commencer, il nous faut héberger notre dépôt à un emplacement accessible depuis le serveur pour que Capistrano puisse y récupérer la dernière version du code. Par souci de simplicité, nous allons l’héberger sur notre compte Alwaysdata puisque Git y est disponible.

Après avoir ouvert un compte, nous activons l’utilisateur SSH dans la partie “Accès Distant > SSH” de la console d’administration.

Pour ne pas avoir à saisir le mot de passe à chaque déploiement, nous allons générer une clé publique sur notre poste et la copier sur le serveur.

Des instructions pour Windows, Mac OS X et Linux sont disponibles sur le wiki d’Alwaysdata. Je reprends ici les indications pour Mac OS X.

# Génération de la clé

    $ mkdir -p ~/.ssh
    $ chmod 0700 ~/.ssh
    $ ssh-keygen -t dsa -f ~/.ssh/id_dsa

# Copie de la clé sur le serveur

    $ scp ~/.ssh/id_dsa.pub user@ssh.alwaysdata.com:/home/user
    $ ssh user@ssh.alwaysdata.com
    user@ssh:~$ mkdir -p ~/.ssh
    user@ssh:~$ chmod 0700 ~/.ssh
    user@ssh:~$ cat id_dsa.pub >> ~/.ssh/authorized_keys
    user@ssh:~$ chmod 600 ~/.ssh/authorized_keys
    user@ssh:~$ rm id_dsa.pub

Nous pouvons maintenant nous connecter sans mot de passe :

    $ ssh user@ssh.alwaysdata.com

Profitons d’être connectés pour créer le dépôt sur le serveur :

    user@ssh:~$ mkdir -p git/monsite.git
    user@ssh:~$ cd git/monsite.git
    user@ssh:~/git/monsite$ git init --bare

Nous venons de créer un dépôt vide prêt à recevoir notre code. Il nous faut maintenant indiquer dans notre dépôt local le chemin vers lequel envoyer le code sur le serveur. Ce dépôt distant est accessible en ssh à l’adresse ssh://user@ssh.alwaysdata.com/home/user/git/monsite.git. Nous ajoutons à notre dépôt local l’adresse du dépôt distant :

    $ cd ~/Code/monsite
    $ git remote add origin ssh://user@ssh.alwaysdata.com/home/user/git/monsite.git

Si nous tapons git remote -v nous voyons l’adresse du dépôt distant origin (appelé ainsi par convention). Il ne nous reste plus qu’à y envoyer notre code :

    $ git push origin master

Le site ProGit propose un chapitre sur les dépôts distants pour en savoir plus. Notre code est maintenant accessible, nous pouvons passer à son déploiement avec Capistrano.

Installation et configuration de Capistrano

Nous commençons par installer et versionner la gem Capistrano :

# config/environment.rb

    config.gem 'capistrano', :lib => false

    $ sudo rake gems:install
    $ rake gems:unpack:dependencies
    $ git add .
    $ git commit -am "Ajout de Capistrano"

Nous utilisons ici :lib => false pour indiquer que ces gems n’ont pas besoin d’être chargées au lancement du serveur de l’application. Elles ne sont utilisées qu’en local pour le déploiement, nous évitons d’alourdir la charge mémoire du serveur.

Nous préparons ensuite notre application à être déployée :

    $ capify .

Cette commande génère deux fichiers : Capfile et config/deploy.rb. Capfile permet à Capistrano de charger les fichiers contenant les tâches à effectuer pour le déploiement. config/deploy.rb va contenir les instructions de déploiement de notre site.

# config/deploy.rb

    set :user, "nom du user ssh"
    set :application, "monsite"
    set :branch, "master"
    set :domain, "ssh.alwaysdata.com"

    server domain, :app, :web
    role :db, domain, :primary => true
    set :runner, user

    ssh_options[:forward_agent] = true
    set :scm, :git
    set :repository, "ssh://user@ssh.alwaysdata.com/~/git/monsite.git"
    set :deploy_via, :remote_cache
    set :git_enable_submodules, 1
    set (:deploy_to) {"/home/user/rails/#{application}"}
    set :keep_releases, 5
    default_run_options[:pty] = true
    set :use_sudo, false

    after 'deploy:update_code' do
      run <<-CMD
        ln -nfs #{shared_path}/config/environments/production.rb #{release_path}/config/environments/production.rb
      CMD
      run <<-CMD
        ln -nfs #{shared_path}/config/database.yml #{release_path}/config/database.yml
      CMD
      %w(files sitemap.xml robots.txt dispatch.fcgi .htaccess).each do |file|
        run <<-CMD
          ln -nfs #{shared_path}/public/#{file} #{release_path}/public/#{file}
        CMD
      end
      run "cd #{release_path} ; rake RAILS_ENV=production gems:build"
    end
    after "deploy", "deploy:cleanup"
    after "deploy:migrations", "deploy:cleanup"

    namespace :deploy do
      task :cold do
        update
        load_schema
        start
      end

      task :load_schema, :roles => :app do
        run "cd #{current_path}; rake RAILS_ENV=production db:schema:load"
      end
    end

    deploy.task :start do
       # nothing
    end
    deploy.task :stop do
      # nothing
    end
    deploy.task :restart do
      # nothing
    end

La première partie définit un ensemble de variables, je vous invite à consulter la documentation des variables principales de Capistrano ainsi que celle sur les rôles pour en savoir plus. Ici nous déployons sur un seul serveur sur lequel se trouve également le dépôt Git, la configuration est donc assez simple. Nous noterons parmi ces variables repository, :deploy_to et :keep_releases

:repository indique où récupérer le code versionné
:deploy_to indique le répertoire propre où sera déployé le code
:keep_releases ici à 5 spécifie le nombre de versions du site que nous souhaitons conserver. Capistrano conserve les versions antérieures pour pouvoir revenir en arrière en cas de problème, il nous faut donc nettoyer les anciennes versions sous peine de voir notre espace complètement rempli au bout d’un certain nombre de déploiements.

La deuxième partie indique quoi faire à chaque étape du déploiement.

La tâche after 'deploy:update_code' est exécutée comme son nom l’indique une fois que le code a été récupéré depuis Git. Elle crée des liens symboliques vers des fichiers situés dans un répertoire shared_path. Pourquoi se donner cette peine ? Nous l’avons vu dans l’article sur le démarrage d’une application avec Git, nous ne versionnons pas les fichiers contenant des données de configuration, seulement une version “exemple”, ceci car :

nous souhaitons éviter d’enregistrer dans Git des données sensibles comme les mots de passe
nous ne souhaitons pas modifier le code versionné à chaque changement d’hébergement ou de configuration.

Nous allons donc devoir créer ces fichiers dans un répertoire spécial que Capistrano met à notre disposition. Il permet de stocker tous les fichiers qui ne sont pas versionnés mais dont l’application a besoin : fichiers de configuration, fichiers uploadés par les utilisateurs, etc. Nous y reviendrons dans un instant.

Nous lançons également à cette étape la compilation des gems avec rake gems:build au cas où certaines le nécessitent.

La tâche after "deploy", "deploy:cleanup" permet une fois le déploiement terminé de nettoyer les anciennes versions en ne gardant que le nombre indiqué pour :keep_releases.

Ensuite nous redéfinissons la tâche cold du namespace deploy. Celle-ci est exécutée pour le premier déploiement, nous lui faisons également charger la base de données à l’aide de la tâche rake db:schema:load avant de démarrer l’application.

Enfin les tâches deploy.task :start, deploy.task :stop et deploy.task :restart sont redéfinies vides car le redémarrage du serveur n’est pour le moment pas possible en ligne de commande chez Alwaysdata. Ce n’est pas très grave car il est facile de le faire depuis la console d’administration, l’équipe a de plus prévu de le rendre possible en ligne de commande par la suite.

Il ne nous reste plus qu’à paramétrer les répertoires nécessaires sur le serveur et vérifier que tout est bien en place avant le déploiement. Capistrano fournit pour cela deux tâches setup et check très pratiques que nous exécutons :

    $ cap deploy:setup
    $ cap deploy:check

Elles permettent de créer les répertoires nécessaires au fonctionnement de Capistrano et de vérifier que tout est installé correctement.

Paramétrage sur le serveur

Tout est prêt sur notre poste, il nous reste à créer sur le serveur les divers fichiers de configuration et répertoires partagés de notre application. Nous commençons par nous connecter au serveur et regardons ce qui a été créé par Capistrano :

    $ ssh user@ssh.alwaysdata.com
    user@ssh:~$ ls rails
    monsite
    user@ssh:~$ cd rails/monsite
    user@ssh:~/rails/monsite$ ls
    releases shared
    user@ssh:~/rails/monsite$ ls shared
    log pids system

Le répertoire releases va contenir les différentes version de notre application. Une fois déployée, un lien symbolique current pointant vers la version actuelle sera créé. À chaque nouveau déploiement, un nouveau répertoire sera créé dans releases et current sera modifié pour pointer sur la nouvelle version.

Le répertoire shared est utilisé pour stocker tous les fichiers conservés à chaque déploiement, comme les fichiers de logs. Nous avons vu dans config/deploy.rb une référence à une variable shared_path, elle correspond à ce répertoire. Nous y créons les répertoires nécessaires :

    user@ssh:~$ cd ~/rails/monsite/shared
    user@ssh:~/rails/monsite/shared$ mkdir public
    user@ssh:~/rails/monsite/shared$ mkdir -p config/environments

Il nous faut maintenant créer dans le répertoire shared de chaque environnement un certain nombre de fichiers dont voici la liste :

config/database.yml : la configuration de la base de données
config/environments/production.rb : la configuration de l’environnement
public/.htaccess : pour rediriger les requêtes sur le processus FCGI
public/dispatch.fcgi : nous allons en utiliser une version paramétrée pour Alwaysdata

Voici ci-dessous le contenu de chaque fichier, à saisir soit directement en éditant les fichiers sur le serveur avec un éditeur comme vi, soit en les copiant par SFTP.

Il faut également créer dans la console d’administration la base de données.

# config/database.yml

    production:
      adapter: mysql
      database: base
      host: mysql.alwaysdata.com
      username: login
      password: password
      encoding: utf8

# config/environments/production.rb

    config.cache_classes = true

    config.action_controller.consider_all_requests_local = false
    config.action_controller.perform_caching             = true
    config.action_view.cache_template_loading            = true

    config.action_mailer.default_url_options = {
      :host => 'www.monsite.com'
    }
    ActionMailer::Base.delivery_method = :smtp
    ActionMailer::Base.smtp_settings = {
      :address => "smtp.alwaysdata.com",
      :port => 25,
      :domain => "alwaysdata.net",
      :authentication => :login,
      :user_name => "login@alwaysdata.net",
      :password => "password"
    }

# public/.htaccess

    AddHandler fcgid-script .fcgi
    AddHandler cgi-script .cgi
    Options +FollowSymLinks +ExecCGI

    RewriteEngine On

    RewriteRule ^$ index.html [QSA]
    RewriteRule ^([^.]+)$ $1.html [QSA]
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

    ErrorDocument 500 "<h2>Application error</h2>Rails application failed to start properly"

# public/dispatch.fcgi

    #!/usr/bin/env ruby

    ENV['RAILS_ENV'] = 'production'
    require File.dirname(__FILE__) + "/../config/environment"
    require 'fcgi_handler'
    RailsFCGIHandler.process!

Dans dispatch.fcgi, nous ajoutons ENV['RAILS_ENV'] = 'production' pour définir avant le chargement de l’application l’environnement dans lequel elle doit s’exécuter.

Pour le mot de passe de la base de données, dans la console d’administration :

cliquer sur “MySQL” dans la partie “Base de données”
cliquer sur “Gestion des utilisateurs”
cliquer sur “Modifier” sur l’utilisateur du même nom que le pack
modifier le mot de passe et le reporter dans le fichier config/database.yml

Pour le mot de passe des emails, dans la console d’administration :

cliquer sur “Emails”
cliquer sur “Modifier” sur l’utilisateur du même nom que le pack dans la partie “alwaysdata.net”
modifier le mot de passe et le reporter dans le fichier config/environments/production.rb

Une fois ces fichiers créés, il faut rendre le fichier dispatch.fcgi exécutable :

    user@ssh:~$ chmod +x /home/login/rails/monsite/shared/public/dispatch.fcgi

Déploiement de l’application

Tout est prêt, nous pouvons lancer le premier déploiement depuis notre poste :

    cap deploy:cold

Cela prend un peu de temps car tout est initialisé pour la première fois ; les déploiements suivants seront plus rapides.

Pour accéder à notre site il faut maintenant faire pointer le domaine sur le répertoire public de l’environnement. Pour cela, nous nous rendons dans la console d’administration dans la rubrique “Domaines”. Si un domaine est enregistré, il faut faire pointer www sur /rails/monsite/current/public. Si aucun domaine n’est installé, il faut faire pointer le domaine nomdupack.alwaysdata.net sur /rails/monsite/current/public.

Nous pouvons alors nous rendre sur le site, et si tout s’est bien passé nous devrions voir la page d’accueil de notre application.

En cas d’erreur, une première piste est de se connecter au serveur en ssh et de lancer le fichier dispatch.fcgi pour voir si une erreur se produit :

    user@ssh:/rails/monsite/current/public$ ./dispatch.fcgi

Les erreurs FCGI sont également enregistrées dans shared/log/fastcgi.crash.log. Les autres erreurs sont enregistrées dans le fichier shared/log/production.log.

Et ensuite ?

Tout ceci semble peut-être représenter un gros travail pour une “simple” mise en ligne, mais les avantages sont déjà nombreux. Lors d’une mise à jour, il n’y a plus de risque d’oublier un fichier lors de grosses mises à jour ou de risquer qu’un visiteur se rende sur le site et rencontre une erreur.

Les déploiements suivants se font de manière très simple et entièrement automatique :

    $ git push origin master
    $ cap deploy

Lorsque par la suite des migrations ont eu lieu, il suffit de lancer cap deploy:migrations au lieu de cap deploy et elles seront appliquées sur la base en ligne. En cas d’erreur, cap deploy:rollback permet de revenir en arrière.

La seule chose qui reste aujourd’hui manuelle est le redémarrage du processus FCGI dans la console d’administration à la rubrique “Avancé > Processus” en cliquant sur “Terminer tous”. Lorsque le redémarrage sera possible en ligne de commande, il suffira de modifier la tâche deploy.task :restart.

Cette méthode est une base pouvant être améliorée en fonction des besoins. Par exemple, nous avons utilisé dans config/deploy.rb plusieurs liens symboliques qui seront vraisemblablement réutilisés pour chaque nouvelle application. Nous pouvons donc envisager de les regrouper dans un plugin versionné à part que nous incluerons ensuite dans nos applications pour en simplifier le déploiement. De même, une tâche s’occupant de créer les répertoires et fichiers dans shared serait un ajout utile à ce plugin. Avec quelques petites modfications, il est facile de déployer sur plusieurs environnements pour avoir également un site de test permettant la validation de modifications par le client avant leur passage en production. Ces sujets feront l’objet de prochains articles.

Réinitialiser le mot de passe d'un utilisateur avec Authlogic

2010-03-22T00:00:00+01:00

Cet article s’appuie sur le tutorial de Ben Johnson et fait suite aux précédents articles sur l’inscription et sur l’activation d’un compte utilisateur.

Le processus de réinitialisation d’un mot de passe suit les étapes suivantes :

l’utilisateur demande la réinitialisation de son mot de passe
un email contenant un lien de réinitialisation lui est envoyé
l’utilisateur clique sur le lien et arrive sur un formulaire où saisir son nouveau mot de passe
une fois le mot de passe modifié l’utilisateur est automatiquement connecté et le lien ayant servi à la réinitialisation est expiré

Vérification de la présence des champs nécessaires

Nous allons avoir besoin de deux champs email et perishable_token sur le modèle User. Si vous avez suivi le tutorial sur l’inscription d’un utilisateur ces champs sont déjà présents et vous pouvez passer à l’étape suivante. Sinon, ajoutons-les à l’aide d’une migration.

Commençons par générer le fichier de migration :

    script/generate migration add_users_passwords_reset_fields

Nous ajoutons ensuite au fichier les champs nécessaires :

# db/migrate/xxx_add_users_passwords_reset_fields.rb

    class AddUsersPasswordResetFields < ActiveRecord::Migration
      def self.up
        add_column :users, :perishable_token, :string, :default => '', :null => false
        add_column :users, :email, :string, :default => '', :null => false
        add_index :users, :perishable_token
        add_index :users, :email
      end

      def self.down
        remove_column :users, :perishable_token
        remove_column :users, :email
      end
    end

Appliquons enfin la migration :

    rake db:migrate

Le modèle User est maintenant prêt, nous pouvons passer à l’étape suivante.

Demande de réinitialisation du mot de passe

Nous allons avoir besoin d’un formulaire permettant à un utilisateur de saisir son email pour recevoir le lien de réinitialisation. Pour nous conformer à la méthode REST, nous allons créer une resource PasswordReset. Une demande de réinitialisation correspond alors à la création d’une PasswordReset (action create du contrôleur PasswordResetsController). Nous créons ce contrôleur :

    script/generate controller password_resets

Nous y ajoutons deux actions new et create correspondant respectivement à l’affichage du formulaire et à son traitement :

# app/controllers/password_resets_controller.rb

    class PasswordResetsController < ApplicationController
      def new
      end

      def create
        @user = User.find_by_email(params[:email])
        if @user
          @user.deliver_password_reset_instructions!
          flash[:succes] = "Les instructions vous permettant de réinitialiser votre mot de passe vous ont été envoyées par email."
          redirect_to root_url
        else
          flash[:avertissement] = "Aucun utilisateur n'a été trouvé avec cette adresse email."
          render :action => :new
        end
      end
    end

La méthode deliver_password_reset_instructions! initialise le champ perishable_token et envoie un email contenant le lien de réinitialisation. Voyons le code de cette méthode dans le modèle User :

# app/models/user.rb

    class User < ActiveRecord::Base
      def deliver_password_reset_instructions!
        reset_perishable_token!
        UserMailer.deliver_password_reset_instructions(self)
      end
    end

La méthode reset_perishable_token! est fournie par Authlogic, elle génère un nouveau perishable_token et sauvegarde l’enregistrement.

Nous ajoutons au UserMailer créé dans le précédent article sur l’inscription d’un utilisateur le code suivant :

# app/models/user_mailer.rb

    class UserMailer < ActionMailer::Base
      def password_reset_instructions(user)
        subject "Instructions pour la réinitialisation de votre mot de passe"
        from "no-reply@example.com"
        recipients user.email
        sent_on Time.now
        body :edit_password_reset_url => edit_password_reset_url(user.perishable_token)
      end
    end

L’adresse edit_password_reset_url correspond au formulaire de saisie de nouveau mot de passe que nous allons créer dans un instant. Il ne nous manque plus pour cette étape que le contenu de l’email, du formulaire et la route permettant d’accéder au différentes actions. Commençons par l’email :

# app/views/user_mailer/password_reset_instructions.erb

    Une demande de réinitialisation de mot de passe a été faite pour votre compte sur le site example.com.

    Si vous n'avez pas effectué cette demande, vous pouvez ignorer cet email

    Si vous avez effectué cette demande, il vous suffit de cliquer sur le lien ci-dessous pour indiquer votre nouveau mot de passe.

    <%= @edit_password_reset_url %>

    Si l'adresse ci-dessus ne fonctionne pas, tentez de la copier / coller directement dans votre navigateur.

    Si vous rencontrez un problème, n'hésitez pas à nous contacter.

Puis le formulaire :

# app/views/password_resets/new.erb

    <h1>Mot de passe oublié ?</h1>

    <p>Indiquez votre email ci-dessous et les instructions vous permettant de réinitialiser votre mot de passe vous seront envoyées.</p>

    <% form_tag password_resets_path do %>
      <div>
        <label>Email</label>
        <%= text_field_tag "email" %>
      </div>
      <div>
        <%= submit_tag "Réinitialiser mon mot de passe" %>
      </div>
    <% end %>

Et enfin les routes :

# config/routes.rb

    map.resources :password_resets

Un utilisateur peut maintenant demander la réinitialisation de son mot de passe vers laquelle nous pouvons créer un lien avec la méthode new_password_reset_url. Voyons maintenant ce qu’il se passe une fois l’email reçu.

Réinitialisation du mot de passe

Lorsque l’utilisateur clique sur le lien contenu dans l’email, il est envoyé sur l’action edit du contrôleur PasswordResets pour modifier son mot de passe. Nous lui ajoutons le code nécessaire :

# app/controllers/password_resets_controller.rb

    before_filter :load_user_using_perishable_token, :only => [:edit, :update]

    def edit
    end

    def update
      @user.password = params[:user][:password]
      @user.password_confirmation = params[:user][: password_confirmation]
      if @user.save
        flash[:notice] = "Le mot de passe a bien été modifié"
        redirect_to account_url
      else
        flash[:avertissement] = "Le mot de passe n'a pas pu être modifié"
        render :action => :edit
      end
    end

    private

    def load_user_using_perishable_token
      @user = User.find_using_perishable_token(params[:id])
      unless @user
        flash[:notice] = "Nous sommes désolés, nous n'avons pas pu retrouver votre compte. " +
        "Si vous rencontrez un problème, tentez de copier / coller l'adresse " +
        "depuis l'email dans votre navigateur, ou recommencez " +
        "le processus de réinitialisation du mot de passe"
        redirect_to root_url
      end
    end

La méthode load_user_using_perishable_token permet de retrouver l’utilisateur à partir du perishable_token contenu dans le lien. Elle utilise la méthode find_using_perishable_token fournie par Authlogic ; cette méthode s’assure que le token utilisé n’est pas vide et est toujours valide, Authlogic expirant automatiquement les tokens au bout de 10 minutes.

L’utilisateur est retrouvé avant l’appel aux deux actions edit et update grâce au before_filter. Si la modification du mot de passe réussit, l’utilisateur est automatiquement connecté grâce à Authlogic.

Nous créons le formulaire de réinitialisation du mot de passe :

# app/views/password_resets/edit.erb

    <h1>Modifier mon mot de passe</h1>

    <% form_for @user, :url => password_reset_path, :method => :put do |f| %>
      <%= f.error_messages %>
      <div>
        <%= f.label :password, "Mot de passe" %>
        <%= f.password_field :password %>
      </div>
      <div>
        <%= f.label :password_confirmation, "Saisissez à nouveau votre mot de passe" %>
        <%= f.password_field :password_confirmation %>
      </div>
      <div>
        <%= f.submit "Modifier mon mot de passe et me connecter" %>
      </div>
    <% end %>

Il ne nous reste plus qu’à restreindre l’accẻs en s’assurant que seul un utilisateur non connecté peut réinitialiser son mot de passe. Nous allons pour cela ajouter un autre before_filter appelant une méthode require_no_user présente dans ApplicationController :

# app/controllers/application_controller.rb

    def require_no_user
      if current_user
        store_location
        flash[:avertissement] = "Vous devez être déconnecté pour accéder à cette page"
        redirect_to root_url
        return false
      end
    end

    def store_location
      session[:return_to] = request.request_uri
    end

# app/controllers/password_resets_controller

    before_filter :require_no_user

Nos utilisateurs ont maintenant la possibilité de réinitialiser leur mot de passe de manière simple, sûre et conforme à la méthode REST.

Traduire les messages et les dates en français

2010-03-15T00:00:00+01:00

Récupération des traductions depuis GitHub

Rails utilise un système basé sur un fichier YAML ou ruby contenant les traductions de toutes les chaînes du cœur. Des traductions dans un grand nombre de langues dont le français sont disponibles dans un dépôt Git disponible sur GitHub. Nous commençons par cloner ce dépôt pour pouvoir facilement récupérer les mises à jour par la suite.

    cd ~/Code # ou tout autre répertoire de votre choix
    git clone git://github.com/svenfuchs/rails-i18n.git

Si vous ne disposez pas de Git, des explications pour l’installer sont disponibles pour Mac OS X, Windows et Linux Ubuntu.

Si nous regardons le code que nous venons de cloner, nous trouvons l’ensemble des traductions dans le répertoire rails/locale. Nous copions le fichier fr.yml qui nous intéresse dans le répertoire config/locales de notre application.

Configuration de l’application

Il nous faut maintenant indiquer à Rails que la locale par défaut est le français. Il nous suffit pour cela de modifier une ligne se trouvant à la fin du fichier config/environment.rb :

    config.i18n.default_locale = :fr

Une fois le serveur relancé, les messages et dates s’affichent en français. Simple, non ?

Avertir l'utilisateur grâce aux messages flash

2010-03-07T00:00:00+01:00

Nous allons définir deux types de messages : succès (vert) et avertissement (orange).

Création des messages

La création de messages est très simple, il suffit dans une action de contrôleur de stocker dans flash le contenu et le type de notre message :

    flash[:succes] = "L'article a bien été créé"

De même pour créer un message d’avertissement :

    flash[:avertissement] = "Tous les champs obligatoires ne sont pas remplis"

Nous aurons accès à flash[:succes] dans la vue lors de la requête suivante.

Affichage des messages

Nous ajoutons à notre gabarit un bloc affichant les messages présents dans flash :

# app/views/layouts/application.html.erb

    <% flash.each do |key, msg| %>
      <%= content_tag(:div, content_tag(:p, msg), :class => "message #{key}") %>
    <% end %>

Ce bloc va générer pour notre précédent message de succès le code HTML suivant :

    <div class="message">
      <div class="succes">
        <p>L'article a bien été créé</p>
      </div>
    </div>

Et pour le message d’avertissement :

    <div class="message">
      <div class="avertissement">
        <p>L'article a bien été créé</p>
      </div>
    </div>

Il ne nous reste plus qu’à styler ce bloc pour différencier les types de messages :

# public/stylesheets/<fichier css>

    .message {
      margin-bottom: 10px;
    }
    .message div {
      padding: 10px 10px 15px 50px;
    }
    .message .succes {
      border: 1px solid #2b8a0d;
      background: url(/images/succes.gif) 10px 5px no-repeat;
      color: #2b8a0d;
    }
    .message .avertissement {
      border: 1px solid #dd4f00;
      background: url(/images/avertissement.gif) 10px 5px no-repeat;
      color: #dd4f00;
    }
    .message p {
      font-weight: bold;
    }

Résultat

Messages :

Icônes :

Activation d'un compte utilisateur avec Authlogic

2010-03-04T00:00:00+01:00

Cet article est une traduction adaptée du tutorial de Matt Hooks et fait suite au précédent article sur l’inscription et la connexion d’utilisateurs.

Préparation du modèle User

Nous allons ajouter au modèle User une colonne actif qui indiquera si l’utilisateur a vérifié son adresse email. Nous commençons par créer une migration :

    script/generate migration add_actif_to_user actif:boolean

Rails reconnaît dans cette commande que nous souhaitons ajouter à la table users une colonne actif stockant un booléen. Il génère le fichier suivant :

# db/migrate/xxxx_add_actif_to_users.rb

    class AddActifToUsers < ActiveRecord::Migration
      def self.up
        add_column :users, :actif, :boolean
      end

      def self.down
        remove_column :users, :actif
      end
    end

Nous modifions la ligne add_column pour spécifier que la colonne est à false par défaut, et ne peut être nulle :

    add_column :users, :actif, :boolean, :default => false, :null => false

Nous appliquons la migration sur la base de données :

    rake db:migrate

Authlogic exécute automatiquement la méthode active? si elle est présente sur le modèle. Nous modifions le modèle User pour ajouter cette méthode, et nous en profitons pour empêcher l’assignation en masse des attributs sensibles. Cela évitera qu’un utilisateur puisse activer son compte en envoyant un formulaire créé de toute pièce (en savoir plus sur attr_accessible).

# app/models/user.rb

    class User < ActiveRecord::Base

      attr_accessible :email, :password, :password_confirmation

      def active?
        actif
      end
    end

Si nous essayons de nous connecter après nous être inscrit, nous recevons comme prévu un message nous indiquant que notre compte n’est pas actif.

Activation d’un compte utilisateur

Nous allons utiliser le perishable_token fourni par Authlogic pour le processus d’activation. Lorsqu’un utilisateur s’inscrit, il reçoit un email contenant un lien unique d’activation valable pendant un certain temps (ici une semaine). Ce lien contient le perishable_token de l’utilisateur et nous permet de le retrouver. Il n’a plus qu’à cliquer sur “Activer mon compte” pour pouvoir se connecter.

Nous commençons par modifier l’action create du contrôleur UsersController :

# app/controllers/users_controller.rb

    def create
      @user = User.new(params[:user])

      # le user n'est pas encore activé, on désactive le login automatique
      if @user.save_without_session_maintenance
       @user.deliver_activation_instructions!
       flash[:notice] = "Votre compte a bien été créé." +
         "Vous allez recevoir un email contenant les instructions pour l'activer."
       redirect_to root_url
      else
       render :action => :new
      end
    end

Puis nous créons un contrôleur ActivationsController chargé de gérer le processus d’activation. Il contient deux actions :

new retrouve l’utilisateur à partir du perishable_token et lui présente le formulaire “Activer mon compte”
create active l’utilisateur et lui envoie l’email de confirmation

Nous créons ce contrôleur :

    script/generate controller activations new create

Puis nous y ajoutons le code des deux actions :

# app/controllers/activations_controller.rb

    class ActivationsController < ApplicationController

      def new
        @user = User.find_using_perishable_token(params[:activation_code], 1.week) || (raise Exception)
        raise Exception if @user.active?
      end

      def create
        @user = User.find(params[:id])

        raise Exception if @user.active?

        if @user.activate!
          @user.deliver_activation_confirmation!
          redirect_to root_url
        else
          render :action => :new
        end
      end

    end

Les exceptions servent à empêcher l’activation d’un utilisateur déjà activé ou au perishable_token expiré. Vous voudrez certainement remplacer cette gestion d’erreur par quelque chose de plus élaboré, comme la possibilité pour un utilisateur dont le perishable_token a expiré d’en demander un nouveau.

Nous créons la vue correspondant à l’activation :

# app/views/activations/new.html.erb

    <h1>Activez votre compte</h1>

    <% form_for @user, :url => activate_path(@user.id), :html => { :method => :post } do |f| %>
      <%= f.error_messages %>
      <%= f.submit "Activer mon compte" %>
    <% end %>

Ces contrôleurs font appel à un certain nombre de méthodes du modèle User qui n’existent pas encore. Remédions à cela :

# app/models/user.rb

    def activate!
      self.actif = true
      save
    end

    def deliver_activation_instructions!
      reset_perishable_token!
      UserMailer.deliver_activation_instructions(self)
    end

    def deliver_activation_confirmation!
      reset_perishable_token!
      UserMailer.deliver_activation_confirmation(self)
    end

Il ne nous manque plus que les envois d’emails, nous générons pour cela UserMailer :

    script/generate user_mailer activation_instructions activation_confirmation

Puis nous ajoutons le code suivant au mailer :

# app/models/user_mailer.rb

    class UserMailer < ActionMailer::Base

      def activation_instructions(user)
        subject       "Veuillez confirmer la création de votre compte"
        from          "Mon Appli <noreply@example.com>"
        recipients    user.email
        sent_on       Time.now
        body          :account_activation_url => register_url(user.perishable_token)
      end

      def activation_confirmation(user)
        subject       "Votre compte a bien été créé"
        from          "Mon Appli <noreply@example.com>"
        recipients    user.email
        sent_on       Time.now
        body          :root_url => root_url
      end

    end

Nous ajoutons les routes utilisées dans le mailer :

# config/routes.rb

    map.register '/register/:activation_code', :controller => 'activations', :action => 'new'
    map.activate '/activate/:id', :controller => 'activations', :action => 'create'

Nous créons enfin les vues contenant les instructions d’activation :

# app/views/user_mailer/activation_instructions.html.erb

    Nous vous remercions d'avoir créé un compte. Veuillez cliquer sur le lien ci-dessous pour l'activer :

    <%= @account_activation_url %>

et de confirmation de l’activation :

# app/views/user_mailer/activation_confirmation.html.erb

    Votre compte a bien été activé.

    <%= @root_url %>

Dernière chose pour les emails, il faut indiquer à Rails quelle url de base utiliser pour la génération des liens :

# config/environments/development.rb

    config.action_mailer.default_url_options = {
      :host => 'localhost:3000'
    }

Vérifions maintenant que tout fonctionne. Nous nous rendons sur http://localhost:3000/users/new et créons un utilisateur. Nous voyons dans le log du serveur l’email envoyé avec le lien d’activation. Nous copions ce lien et nous rendons sur http://localhost:3000/user_session/new pour tenter de nous connecter. Nous obtenons bien un message d’erreur nous indiquant que le compte n’est pas actif.

Nous pouvons alors copier/coller dans notre navigateur l’adresse récupérée dans l’email (de la forme http://localhost:3000/register/:perishable_token). Nous voyons alors la page contenant le bouton “Activer mon compte” sur lequel nous cliquons. Nous voyons dans le log du serveur l’email de confirmation, il est maintenant possible de se connecter.

Tout cela est déjà bien pratique, mais ne serait-ce pas mieux si nous étions connecté dès l’activation du compte ? Voyons comment mettre en place ce processus.

Connexion dès l’activation

Authlogic connecte automatiquement l’utilisateur lors de la modification du mot de passe, or ici le mot de passe n’a pas été modifié. Nous allons donc modifier le processus pour ne demander que l’email à l’inscription et demander le mot de passe lors de l’activation, connectant ainsi l’utilisateur en même temps.

Nous commençons par indiquer à Authlogic de ne vérifier la longueur du mot de passe que si celui-ci est vide lors d’un update :

# app/models/user.rb

    acts_as_authentic do |c|
      c.validates_length_of_password_field_options = {
        :on => :update, :minimum => 4, :if => :has_no_credentials?
      }
      c.validates_length_of_password_confirmation_field_options = {
        :on => :update, :minimum => 4, :if => :has_no_credentials?
      }
    end

    def has_no_credentials?
      self.crypted_password.blank?
    end

Nous séparons ensuite l’inscription d’un utilisateur en deux processus :

signup! qui affecte l’email choisi et sauvegarde sans login automatique
activate! qui affecte le mot de passe choisi et sauvegarde avec login automatique

Nous modifions de nouveau le modèle User :

# app/models/user.rb

    def signup!(params)
      self.email = params[:user][:email]
      # Ces colonnes sont NOT NULL, on évite une erreur SQL
      self.crypted_password = ''
      self.password_salt = ''
      save_without_session_maintenance
    end

    def activate!(params)
      self.actif = true
      self.password = params[:user][:password]
      self.password_confirmation = params[:user][:password_confirmation]
      save
    end

Nous modifions ensuite la méthode create des contrôleurs ActivationsController et UsersController pour utiliser nos nouvelles méthodes signup! et activate!.

Nous commençons par UsersController :

# app/controllers/users_controller.rb

    def create
      @user = User.new

      if @user.signup!(params)
        @user.deliver_activation_instructions!
        flash[:notice] = "Votre compte a bien été créé." +
          "Vous allez recevoir un email contenant les instructions pour l'activer."
        redirect_to root_url
      else
        render :action => :new
      end
    end

Puis ActivationsController :

# app/controllers/activations_controller.rb

    def create
      @user = User.find(params[:id])

      raise Exception if @user.active?

      if @user.activate!(params)
        @user.deliver_activation_confirmation!
        flash[:notice] = "Votre compte a bien été activé."
        redirect_to root_url
      else
        render :action => :new
      end
    end

Il ne nous reste plus qu’à modifier les formulaires. Nous commençons par supprimer le mot de passe lors de l’inscription :

# app/views/users/new.html.erb

    <h1>Créer un compte</h1>

    <% form_for @user do |f| %>
      <%= f.error_messages %>
      <div>
        <%= f.label 'Email' %>
        <%= f.text_field :email %>
      </div>
      <%= f.submit "Créer mon compte" %>
    <% end %>

Puis nous l’ajoutons lors de l’activation :

# app/views/activations/new.html.erb

    <h1>Activez votre compte</h1>

    <% form_for @user, :url => activate_path(@user.id), :html => { :method => :post } do |f| %>
      <%= f.error_messages %>
      <div>
        <%= f.label :password, "Mot de passe" %>
        <%= f.password_field :password %>
      </div>
      <div>
        <%= f.label :password_confirmation, "Confirmer le mot de passe" %>
        <%= f.password_field :password_confirmation %>
      </div>
      <%= f.submit "Activer mon compte" %>
    <% end %>

Inscription et connexion d'un utilisateur avec Authlogic

2010-03-03T00:00:00+01:00

Authlogic est une solution simple et élégante pour gérer l’inscription et la connexion d’utilisateurs. Voyons comment l’intégrer à un site existant.

Installation

Nous commençons par indiquons dans config/environment.rb que notre application utilise la gem Authlogic :

# config/environment.rb

    Rails::Initializer.run do |config|
      # ...
      config.gem 'authlogic', :source => 'http://gemcutter.org'
      # ...
    end

Nous installons ensuite la gem et décompressons son code dans le répertoire vendor/gems :

    sudo rake gems:install
    rake gems:unpack:dependencies

Nous paramétrons ensuite notre application pour Authlogic. Une application exemple avec les instructions d’installation et des explications est disponible sur github. Nous en reprenons ici les différentes étapes.

Création du modèle UserSession

Authlogic permet de gérer des sessions gérées comme un modèle ActiveRecord. Elles peuvent êtres créées et détruites par un controller RESTful que nous allons créer par la suite. Nous créons le modèle UserSession grâce au générateur fourni :

    script/generate session user_session

Un fichier app/models/user_session.rb est créé et contient le code suivant :

    class UserSession < Authlogic::Session::Base
    end

Nous ajoutons enfin une route pour la création et destruction de la session :

# config/routes.rb

    map.resource :user_session

Création du modèle User

Avoir une gestion des sessions est pratique, mais encore faut-il avoir des utilisateurs à authentifier ! Créons un modèle User :

    script/generate model user

Plusieurs fichiers sont créés, dont un fichier de migration qui va nous servir à créer la table en base de données. Nous éditons ce fichier situé dans db/migrate pour ajouter les colonnes nécessaires au fonctionnement d’Authlogic :

# db/migrate/xxxxxxxxxxxxxx_create_users.rb

    class CreateUsers < ActiveRecord::Migration
      def self.up
        create_table :users do |t|
          t.string :email, :null => false
          t.string :crypted_password, :null => false
          t.string :password_salt, :null => false
          t.string :persistence_token, :null => false
          t.string :perishable_token, :null => false
          t.integer :login_count, :null => false, :default => 0
          t.integer :failed_login_count, :null => false, :default => 0
          t.datetime :last_request_at
          t.datetime :current_login_at
          t.datetime :last_login_at
          t.string :current_login_ip
          t.string :last_login_ip
          t.timestamps
        end
      end

      def self.down
        drop_table :users
      end
    end

Chacun des choix faits ici est configurable ou modifiable, Authlogic permettant une grande souplesse à ce niveau. Voyons à quoi sert chaque champ :

l’email de l’utilisateur est utilisé comme login.
crypted_password et password_salt sont utilisés pour le cryptage et le stockage du mot de passe
persistence_token sert à maintenir l’utilisateur connecté
perishable_token est utilisé pour identifier un utilisateur lors de la confirmation de son ouverture de compte et de la réinitialisation de son mot de passe.
login_count sert à stocker le nombre de fois où l’utilisateur s’est connecté
failed_login_count est utilisé pour la protection contre les attaques “brute force” (par défaut Authlogic suspend un utilisateur pour 2 heures au bout de 50 essais infructueux, ces valeurs étant bien sûr configurables.)
last_request_at sert à stocker la date de dernière action sur le site
current_login_at sert à stocker la date de dernière connexion
last_login_at sert à stocker la valeur de current_login_at avant qu’il ne soit réinitialisé
current_login_ip sert à stocker l’adresse IP de dernière connexion
last_login_ip sert à stocker la valeur de current_login_ip avant qu’il ne soit réinitialisé

Nous pouvons maintenant mettre à jour la base de données avec la migration :

    rake db:migrate

Configuration du modèle User

Nous allons maintenant indiquer qu’un utilisateur est identifié par Authlogic. Il suffit d’ajouter une ligne au modèle User :

# app/models/user.rb

    class User < ActiveRecord::Base
      acts_as_authentic
    end

Pour le moment nous conservons la configuration par défaut. Par la suite il sera facile de rajouter des options de configuration dans un bloc :

# app/models/user.rb

    class User < ActiveRecord::Base
      acts_as_authentic do |c|
        c.config_option = config_value
      end
    end

La documentation d’Authlogic donne la liste des options disponibles pour chaque module dans Authlogic::ActsAsAuthentic::<module>::Config.

Inscription des utilisateurs

Nos modèles sont prêts, nous pouvons démarrer la réalisation des différentes actions. Nous allons commencer par permettre aux utilisateurs de s’inscrire. Nous créons tout d’abord un contrôleur UsersController :

    script/generate controller users

Nous y ajoutons les actions REST new et create :

# app/controllers/users_controller.rb

    class UsersController < ApplicationController

      def new
        @user = User.new
      end

      def create
        @user = User.new(params[:user])
        if @user.save
          flash[:notice] = "Votre compte a bien été créé"
          redirect_to '/'
        else
          render :action => :new
        end
      end

    end

Nous créons ensuite la vue correspondante :

# app/views/users/new.html.erb

    <h1>Créer un compte</h1>

    <% form_for @user do |f| %>
      <%= f.error_messages %>
      <div>
        <%= f.label 'Email' %>
        <%= f.text_field :email %>
      </div>
      <div>
        <%= f.label 'Mot de passe' %>
        <%= f.password_field :password %>
      </div>
      <div>
        <%= f.label 'Confirmer le mot de passe' %>
        <%= f.password_field :password_confirmation %>
      </div>
      <%= f.submit "Créer mon compte" %>
    <% end %>

Nous ajoutons la route correspondante aux actions REST sur UsersController :

# config/routes.rb

    ActionController::Routing::Routes.draw do |map|
      map.resources :users
    end

Nous pouvons maintenant nous rendre sur http://localhost:3000/users/new et remplir le formulaire d’inscription. Une fois inscrit, nous lançons la console pour vérifier que l’utilisateur est bien enregistré :

    script/console
    y User.last

Nous voyons les informations de notre utilisateur s’afficher, nous pouvons maintenant nous intéresser à sa connexion.

Connexion et déconnexion des utilisateurs

Une fois l’utilisateur créé, nous devons lui permettre de se connecter. Nous commençons par créer une page d’accueil sur laquelle nous verrons :

un lien vers le formulaire de connexion si l’utilisateur n’est pas connecté
l’email de l’utilisateur connecté sinonNous créons pour cela un contrôleur

Nous ajoutons tout d’abord une route pour la page d’accueil :

# config/routes.rb

    ActionController::Routing::Routes.draw do |map|
      map.root :controller => :users, :action => :index
      map.resources :users
    end

ainsi que deux méthodes current_user et current_user_session à ApplicationController :

# app/controllers/application_controller.rb

    class ApplicationController < ActionController::Base
      helper :all # include all helpers, all the time
      protect_from_forgery # See ActionController::RequestForgeryProtection for details

      filter_parameter_logging :password, :password_confirmation
      helper_method :current_user_session, :current_user

      private
        def current_user_session
          return @current_user_session if defined?(@current_user_session)
          @current_user_session = UserSession.find
        end

        def current_user
          return @current_user if defined?(@current_user)
          @current_user = current_user_session && current_user_session.user
        end
    end

Nous ajoutons ensuite une action index à notre contrôleur UsersController :

# app/controllers/users_controller.rb

    class UsersController < ApplicationController

      def index

      end

      def new
        @user = User.new
      end

      def create
        @user = User.new(params[:user])
        if @user.save
          flash[:notice] = "Votre compte a bien été créé"
          redirect_to '/'
        else
          render :action => :new
        end
      end

    end

Puis nous créons la vue correspondante :

# app/views/users/index.html.erb

    <h1>Bienvenue</h1>
    <% if current_user %>
      <p><%= current_user.email %></p>
      <%= link_to "Déconnexion", user_session_path, :method => :delete %>
    <% else %>
      <p><%= link_to "Connexion", new_user_session_path %></p>
      <p><%= link_to "S'inscrire", new_user_path %></p>
    <% end %>

Nous créons maintenant le contrôleur UserSessions qui va gérer la création et la suppression de sessions :

    script/generate controller user_sessions new create destroy

Nous y ajoutons le code classique d’un contrôleur RESTful :

# app/controllers/user_sessions_controller.rb

    class UserSessionsController < ApplicationController

      def new
        @user_session = UserSession.new
      end

      def create
        @user_session = UserSession.new(params[:user_session])
        if @user_session.save
          flash[:notice] = "Vous êtes maintenant connecté"
          redirect_to root_path
        else
          render :action => :new
        end
      end

      def destroy
        current_user_session.destroy
        flash[:notice] = "Vous êtes maintenant déconnecté"
        redirect_to root_url
      end

    end

Puis nous créons la vue correspondant au formulaire de connexion :

# app/views/user_sessions/new.html.erb

    <h1>Connexion</h1>

    <% form_for @user_session, :url => user_session_path do |f| -%>
      <%= f.error_messages %>
      <div>
        <%= f.label 'Email' %>
        <%= f.text_field :email %>
      </div>
      <div>
        <%= f.label 'Mot de passe' %>
        <%= f.password_field :password %>
      </div>
      <div>
        <%= f.check_box :remember_me %>
        <%= f.label "Se souvenir de moi" %>
      </div>
      <%= f.submit "Connexion" %>
    <% end -%>

Nous pouvons maintenant nous rendre sur http://localhost:3000, nous y voyons “Bienvenue” ainsi que les liens de connexion et d’inscription. Une fois connecté, nous voyons apparaître l’email de l’utilisateur en cours ainsi que le lien de déconnexion.

Démarrer une nouvelle application Rails avec Git et un modèle

2010-03-02T00:00:00+01:00

Nous allons voir comment utiliser les modèles d’application pour générer un squelette incluant d’office les fonctionnalités couramment utilisées.

Les modèles d’application

Les modèles d’application sont de simple fichiers Ruby contenant du code permettant d’effectuer un certain nombre d’actions à la création d’une application. Différentes méthodes sont disponibles, permettant d’inclure une gem ou un plugin, de manipuler git, de créer une route, de lancer un script, etc.

Pour indiquer à Rails d’utiliser un fichier modèle, il suffit d’utiliser le paramètre - m lors de la création d’une application :

    rails mon-appli -m ~/rails-modele.rb

Il est également possible d’indiquer un fichier situé sur un serveur web :

    rails mon-appli -m http://gist.github.com/211697.txt

Nous allons créer un fichier modèle qui réalise les actions suivantes :

gestion de source avec Git
installation de gems et de plugins
configuration de la base de données

Gestion de source avec Git

Comme nous allons versionner notre code avec Git, nous profitons du modèle d’application pour exécuter les commandes permettant d’initialiser un dépôt et de le paramétrer pour ignorer les fichiers qui ne seront pas versionnés : fichiers de configuration, de logs, temporaires…

# ~/rails-modele.rb

    # Initialisation du dépôt
    git :init

    # Copie du fichier de configuration de la base de données vers une version d'exemple
    run "cp config/database.yml config/database.yml.default"

    # Ajout d'un fichier .gitignore dans chaque répertoire vide
    # Git ne versionne que le contenu des fichiers, un répertoire ou fichier vide est ignoré
    # Pour forcer la création des répertoires vides nous y insérons un fichier caché spécial
    run %{find . -type d -empty | xargs -I % touch %/.gitignore}

    # Ajout des fichiers à ignorer dans le fichier .gitignore principal
    file '.gitignore', <<-END
    log/*.log
    db/*.db
    db/*.sqlite3
    tmp/**/*
    config/database.yml
    END

La méthode git permet de répliquer le fonctionnement de l’utilitaire en ligne de commande.

La méthode run permet d’exécuter directement une commande shell.

La méthode file permet de créer un fichier avec un contenu donné.

Installation de gems et plugins

Une fois notre dépôt initialisé, nous allons pouvoir ajouter les gems et plugins couramment utilisés. Pour le moment nous nous en tiendrons au minimum : la pagination de résultats avec WillPaginate. Le plugin d’inscription et de connexion des utilisateurs nécessitant plus d’explications, il fera l’objet d’un prochain article.

Nous ajoutons les lignes suivantes à notre fichier modèle :

    gem 'will_paginate', :source => 'http://gemcutter.org'
    rake 'gems:install', :sudo => true
    rake 'gems:unpack:dependencies'

La méthode gem permet d’indiquer à Rails que l’application dépend d’une gem, en ajoutant au fichier config/environment.rb le nom et la version de la gem utilisée. Nous installons ensuite la gem grâce à rake avant d’en extraire le code dans le répertoire vendor/gems de l’application. Cela assure ainsi de versionner l’application avec l’ensemble de ses dépendances externes et d’éviter les mauvaises surprises lors du déploiement (gem non installée ou de version différente par exemple).

Nous allons également “freezer” Rails à la version utilisée dans l’application :

    rake 'rails:freeze:edge RELEASE=2.3.5'

Configuration de la base de données

Par défaut, Rails utilise en mode de développement la base de données SQLite. Or nous avons installé à l’étape précédente MySQL pour retrouver en développement la même configuration que sur notre futur serveur de production. Il nous faut donc modifier le fichier de configuration de la base de données pour y indiquer nos paramètres :

    # Création du fichier de configuration de la base de données
    file 'config/database.yml', <<-END
    development:
      adapter: mysql
      database: database
      host: localhost
      username: username
      password: password
      encoding: utf8
    END
    database = ask("Nom de la base ?")
    username = ask("Nom d'utilisateur ?")
    password = ask("Mot de passe ?")
    run "sed -e 's/database:.*/database: #{database}/' -e 's/username:.*/username: #{username}/' -e 's/password:.*/password: #{password}/' config/database.yml > config/database.yml.tmp"
    run "mv config/database.yml.tmp config/database.yml"

La méthode ask permet de demander des valeurs à l’utilisateur et de les utiliser ensuite. Il existe également les méthodes yes? et no? qui permettent d’effectuer ou non des actions suivant la réponse de l’utilisateur.

Finalisation

L’application est maintenant prête à être créée, il ne nous reste plus qu’à enregistrer le code dans le dépôt et commiter :

    # Ajout dans le dépôt Git
    git :add => '.'
    git :commit => "-m 'Commit initial'"

Nous pouvons maintenant créer notre application et le dépôt associé :

    rails mon-appli -m ~/rails-modele.rb

Le contenu du fichier rails-modele.rb est également disponible en ligne :

    rails mon-appli -m http://gist.github.com/211697.txt

Nous sommes maintenant prêts à démarrer le développement proprement dit.

Installation d'un environnement de développement Rails sur Windows XP

2010-03-01T00:00:00+01:00

J’utilise Mac OS X, les instructions pour Windows XP sont donc indicatives.

Installation de Git

La meilleure option pour installer Git sur Windows semble être par l’intermédiaire de msysGit. Nous téléchargeons la dernière version stable et lançons l’installation.

À l’étape où apparaît un message en rouge et 3 choix nous choisissions la troisième option (l’option 1 est recommandée au cas où vous utilisez les utilitaires natifs de Windows find.exe et sort.exe, ceux-ci étant remplacés par leur version Unix avec l’option 3).

À l’étape du choix de format de fin de ligne, tout dépend de votre environnement :

si vous travaillez avec des personnes sur Unix (Linux, Mac OS X), ou participez à des projets open source, choisissez l’option 1
si vous travaillez seul sous Windows ou avec d’autres personnes toutes sur Windows, choisissez l’option 2

Installation de MySQL

Nous téléchargeons la version Community Server de MySQL en choissisant Windows, Windows Essentials, Pick a mirror.

À la fin de l’installation nous choisissons “Configure MySQL now”, “Standard configuration”. Nous cochons ensuite la case “Include Bin Directory in Windows PATH” et saisissons le mot de passe root. Nous pouvons alors finir l’installation et vérifier que le serveur est bien installé en cliquant sur “Démarrer > Exécuter > cmd” puis en tapant

    mysql -u root -p
    show databases;

Nous voyons la liste des bases de données par défaut (information_schema, mysql et test), MySQL fonctionne.

Installation de Ruby et Rails

Nous téléchargeons le programme d’installation de Ruby 1.8.6 pour Windows et l’exécutons. Il faut ensuite cocher “Enable RubyGems” et “European Keyboard”.

En ligne de commande nous vérifions que Ruby est accessible :

    ruby -v # ruby 1.8.6 (2008-08-11 patchlevel 287) [i386-mswin32]

Nous mettons RubyGems à jour, la version livrée avec Ruby est ancienne :

    gem update
    gem -v # 1.3.5

Nous pouvons maintenant installer Rails et les gems nécessaires :

    gem install mysql rails --no-ri --no-rdoc

Dernière petite chose, il semble y avoir parfois des soucis avec la connexion MySQL qui sont résolus en téléchargeant une version plus ancienne de libmySQL.dll dans c:\Ruby\bin.

Nous voilà fin prêts pour démarrer le développement d’une application !

Autres outils

Voici une liste non exhaustive de logiciels facilitant le développement.

Éditeurs de texte et IDE

Komodo Edit : une version libre de l’IDE d’ActiveState
Aptana : une version d’Eclipse adapté au développement avec Ruby On Rails
E-Editor : un clone de TextMate pour Windows, compatible avec les bundles de TextMate

GUI pour MySQL

GUI pour Git

Nous reviendrons dans un prochain article sur l’utilisation de Git. En attendant, voici quelques outils pour en faciliter l’utilisation.

Git GUI : fourni avec msysGit

Installation d'un environnement de développement Rails sur Linux Ubuntu

2010-03-01T00:00:00+01:00

J’utilise Mac OS X, les instructions pour Ubuntu sont donc indicatives.

Installation de Git

Nous commençons par mettre à jour la liste des paquets disponibles pour apt-get :

    sudo apt-get update

puis nous installons Git grâce à apt-get :

    sudo apt-get install git-core

Installation de MySQL

Nous installons MySQL grâce à apt-get :

    sudo apt-get install mysql-server-5.1 mysql-client-5.1 libmysql-ruby libmysqlclient-dev

Vérifions que le serveur fonctionne :

    mysql -u root -p
    show databases;

Nous voyons la liste des bases de données par défaut (information_schema, mysql et test), MySQL fonctionne. Plusieurs outils de gestion des bases sont disponibles via le centre de téléchargement Ubuntu.

Installation de Ruby et Rails

Nous installons Ruby et RubyGems grâce à apt-get :

    sudo apt-get install ruby rubygems ruby-dev libopenssl-ruby

Nous installons ensuite les gems nécessaires :

    sudo gem install mysql rails --no-ri --no-rdoc

Pour accéder facilement aux différents exécutables fournis par les gems, nous ajoutons la ligne suivante au fichier ~/.bashrc :

    export PATH=/var/libs/gems/1.8/bin:$PATH

Puis nous regénérons l’environnement :

    source ~/.bashrc

Nous pouvons alors tester l’ensemble des programmes installés :

    ruby -v # ruby 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
    gem -v # 1.3.5
    rails -v # Rails 2.3.5

Nous voilà fin prêts pour démarrer le développement d’une application !

Autres outils

Voici une liste non exhaustive de logiciels facilitant le développement.

Éditeurs de texte et IDE

Komodo Edit : une version libre de l’IDE d’ActiveState
Aptana : une version d’Eclipse adapté au développement avec Ruby On Rails
un grand nombre d’autres éditeurs sont disponibles par apt-get ou par le Centre de logiciels : emacs, vi, bluefish…

GUI pour MySQL

MySQL GUI Tools et plusieurs autres sont disponibles sur le Centre de logiciels

GUI pour Git

Nous reviendrons dans un prochain article sur l’utilisation de Git. En attendant, voici quelques outils pour en faciliter l’utilisation.

Git GUI : fourni avec Git
d’autres GUI sont disponibles sur le Centre de logiciels

Installation d'un environnement de développement Rails sur Mac OS X

2010-03-01T00:00:00+01:00

Ruby et Ruby On Rails sont fournis sur les versions récentes (10.5 et 10.6) de Mac OS X. Nous allons cependant en installer nos propres versions, cela permettra de les mettre à jour plus facilement par la suite. Nous utilisons pour cela MacPorts.

Installation de MacPorts et Git

MacPorts est un système de gestion de paquets pour Mac, dans le même genre qu’apt-get sous Debian. Il permet d’installer et de maintenir facilement un grand nombre de logiciels Unix adaptés pour Mac OS X.

Git est un système de gestion de versions utilisé notamment pour le développement de Ruby on Rails.

Installation de MacPorts

MacPorts nécessite l’installation de XCode, fourni sur le CD de Mac OS X (répertoire Optional Installs) ou disponible sur le site de l’ADC Apple Developper Connection. Le téléchargement est gratuit, il suffit de créer un compte.

Une fois XCode installé, nous pouvons installer MacPorts. Il est disponible en téléchargement sur le site de MacPorts. Il suffit de télécharger l’image DMG correspondant à la version de Mac OS X et de lancer le programme d’installation fourni. MacPorts est alors installé dans /opt/local.

Nous mettons à jour MacPorts pour être sûr de disposer des dernières versions des paquets :

    sudo port -v selfupdate

Nous ajoutons au fichier .profile situé dans notre répertoire utilisateur le chemin vers les exécutables et la documentation MacPorts

# ~/.profile

    export PATH=/opt/local/bin:$PATH
    export MANPATH=/opt/local/share/man:$MANPATH

Puis nous rafraîchissons la session ouverte dans le terminal :

    source ~/.profile

Installation de Git

Une fois MacPorts installé, nous installons git :

    sudo port install git-core +bash_completion

Après un certain temps (MacPorts compile l’ensemble des dépendances nécessaires à Git) MacPorts et Git sont installés. Nous pouvons passer à l’installation des outils nécessaires au développement proprement dit.

Installation de MySQL

Nous installons MySQL :

    sudo port install mysql5-server

Une fois MySQL installé nous paramétrons les bases de données :

    sudo mysql_install_db5

En cas d’erreur, indiquer le bon utilisateur (merci à Denis pour avoir trouvé une solution ):

    sudo mysql_install_db5 --user=_mysql

Nous chargeons MySQL au démarrage de la session :

    sudo launchctl load -w /Library/LaunchDaemons/org.macports.mysql5.plist

Nous démarrons MySQL manuellement pour la première utilisation :

    sudo mysqld_safe5 &

Nous modifions le mot de passe root, en remplacant new-password par le mot de passe souhaité :

    sudo mysqladmin5 -u root password 'new-password'

Enfin nous vérifions le bon fonctionnement en ligne de commande :

    mysql5 -u root -p
    show databases;

Nous voyons la liste des bases de données par défaut (information_schema, mysql et test), MySQL fonctionne.

Installation de Ruby et Rails

Nous installons Ruby :

    sudo port install ruby

Nous installons maintenant RubyGems, le système de gestion de modules Ruby :

    sudo port install wget
    wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz
    tar -xzf rubygems-1.3.5.tgz
    cd rubygems-1.3.5 && sudo ruby setup.rb
    sudo gem update --system

Nous pouvons maintenant installer les gems nécessaires :

    sudo gem install mysql rails --no-ri --no-rdoc

Vérifions les chemins et versions de nos exécutables :

    which ruby # /opt/local/bin/ruby
    which rails # /opt/local/bin/rails
    ruby -v # ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10]
    rails -v # Rails 2.3.5

Nous voilà fin prêts pour démarrer le développement d’une application !

Autres outils

Voici une liste non exhaustive de logiciels facilitant le développement.

Éditeurs de texte et IDE

Textmate : l’éditeur que j’utilise, très puissant notamment grâce à son système de “snippets”
MacVim : une version mac du célèbre éditeur vim, très puissant également mais demande un temps d’adaptation assez long
Komodo Edit : une version libre de l’IDE d’ActiveState
Aptana RadRails : une version d’Eclipse adapté au développement avec Ruby On Rails

GUI pour MySQL

Sequel Pro : celui que j’utilise, très pratique pour les opérations courantes sur les bases de données (visualisation, modifications, import/export…)
MySQL GUI Tools
Navicat

GUI pour Git

Nous reviendrons dans un prochain article sur l’utilisation de Git. En attendant, voici quelques outils pour en faciliter l’utilisation.

GitX : celui que j’utilise, très pratique pour visualiser l’arborescence et l’historique d’un projet, gérer les commit etc
GitNub
Git GUI : fourni avec Git, offre sensiblement les mêmes fonctionnalités mais sans l’interface “Mac-like”. Se lance avec git gui.

GUI pour MacPorts

Porticus permet de visualiser, d’installer et de désinstaller des paquets